Abstract:
Network buses in vehicles and other assets are monitored in order to obtain information and calculate alternate values of parameters relating to components connected to the bus and to send them to a management server. The device includes main code, which is common to the different vehicles or assets in a group, and a script, which is specific to each type of vehicle or asset. The script, which may be customizable, is responsible for defining the parameters to obtain and for defining how the values of the parameters are to be calculated. The script compensates for differences in the way different buses and components operate in different assets, which means that the values of like parameters obtained from different sources are all in conformance with each other. The script can be updated without interrupting the operation of the main code and the monitoring of the bus.

Description:
FIELD OF THE INVENTION 
       [0001]    This invention relates to the field of remote asset monitoring. In particular, it relates to automatically calculating alternate values of parameters to override those that are generated on the bus of a vehicle, or to calculate values of parameters that are not directly present on the bus. 
       BACKGROUND OF THE INVENTION 
       [0002]    Since the advent of wireless networks and GPS (Global Positioning System) satellites, specialized wireless devices have been installed in vehicles to facilitate fleet operations management. Such devices have also been installed in virtually anything that moves or is moved to enable asset tracking. These monitoring devices may interface with many kinds of other vehicular-based devices and systems to collect information and/or data and to transmit this to a remote server and/or fleet manager. When used by fleet operators, the monitoring devices provide a wealth of useful information such as driver behaviour, compliance with traffic rules, compliance with government regulations, and detailed time tracking. 
         [0003]    To enhance use of vehicle buses in a vehicle electronic network, standards have been developed that describe mainly the data link layer and some aspects of the physical layer. Other protocol layers are left to a network designer&#39;s choice. Each vehicle manufacturer may be provided with parameter group numbers for their own proprietary use. As such, a vehicle bus standard may define a large number of parameters that may or may not be available on a bus installed on a particular vehicle. Vehicle manufacturers and equipment manufacturers for vehicles decide which parameters to support. Vehicle manufacturers and equipment manufacturers for vehicles may also add unique proprietary parameters. Internal calculations based on sensed values of parameters may be different from manufacturer to manufacturer, and there are no specific standards to which these calculations must adhere. As a result, this introduces limitations for vehicle owners and asset managers seeking to consistently monitor a number of vehicles of different models and/or makes that may have varying operation and performance criteria. Proprietary standards may therefore affect the usefulness of a remote asset monitoring system. 
         [0004]    U.S. Pat. No. 8,751,098 to Faus discloses a method of monitoring CANbus (Controller Area Network bus) information. Original parameters associated with sensors are converted into virtual sensors to provide selective vehicle information to an equipment management system. A terminal may then apply logic to the virtual sensor by performing calculations indicating a comparison against a threshold, validations, and alert generations, for example. 
         [0005]    U.S. Patent Application Publication No. 2008/0140278 to Breed discloses providing a vehicle with software to enable it to operate and interact with components thereof. Updating the vehicle software occurs via a wireless transmission from one or more remote locations, e.g., a location maintained by a dealer or manufacturer of the vehicle. The software may be diagnostic software for a diagnostic module, which diagnoses the operability of components of the vehicle. 
       SUMMARY OF THE INVENTION 
       [0006]    A parameter calculation unit connected to a vehicle bus has a main code that is common to different vehicles and a script that is specific to each different vehicle. The script can be updated independently of the main code. 
         [0007]    Disclosed herein is a device for obtaining a value of a parameter from information present on a network bus of an asset, the device comprising: a processor operably connected to a network bus of the asset; a computer readable memory operably connected to the processor; a main code stored in the memory, the main code being asset agnostic; and a script stored in the memory, the script being asset specific. The processor, upon execution of the main code, requests a parameter to obtain; upon execution of the script, receives the parameter to obtain; and also upon execution of the script, obtains a value of the parameter from information present on the network bus. The processor, upon execution of the script, can receive an algorithm for calculating the value of the parameter and can obtain the value of the parameter by performing the algorithm on the information. 
         [0008]    Also disclosed is a method for obtaining a value of a parameter from information present on a network bus of an asset, the method comprising: executing, by a processor, an asset agnostic main code and thereby requesting a parameter to obtain; executing, by the processor, an asset specific script and thereby receiving the parameter to obtain; and executing, by the processor, said script and thereby obtaining a value of the parameter from information present on the network bus. The method may further comprise: executing, by the processor, said script and thereby receiving an algorithm for calculating the value of the parameter; and obtaining the value of the parameter by the processor performing the algorithm on said information. 
         [0009]    Still further disclosed is a system for obtaining a value of a parameter from information present on a network bus of an asset, the system comprising: a server; a processor operably connected to a network bus of the asset; a computer readable memory operably connected to the processor; a main code stored in the memory, the main code being asset agnostic; and a script stored in the memory, the script being asset specific. The processor, upon execution of the main code, requests a parameter to obtain; upon execution of the script, receives the parameter to obtain; upon execution of the script, obtains a value of the parameter from information present on the network bus; and upon execution of the main code, transmits the value of the parameter to the server over the air. It is possible that the asset is a vehicle in a group of vehicles of different make, model, year and/or specification; the main code is agnostic to all vehicles within the group; and the value of the parameter conforms, in a way in which it is calculated, with other values of like parameters received by the server from all said vehicles, such that post-processing by the server to conform it to said other values is unnecessary. 
         [0010]    The subject matter disclosed herein allows proprietary and vehicle-specific calculations for vehicle bus parameters to be performed in the vehicle rather than by a remote management server. It allows for the definitions of the calculations and the corresponding algorithms to be sent over the air to the vehicle, without interruption of the monitoring of the vehicle bus by the main code. Results of the vehicle-specific calculations are sent from the vehicle over the air to the management server instead of the raw values of the parameters obtained directly from the vehicle bus. This removes the requirement for post-processing at the server. The separation of the script defining the vehicle-specific calculations from the main code allows for easy and fast updating of the parameter calculation definitions. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0011]    A better understanding of the present invention can be obtained when the following detailed description is considered in conjunction with the following drawings, which should not be construed as restricting the scope of the invention in any way. 
           [0012]      FIG. 1  is a schematic diagram of a vehicle bus parameter calculation system according to an exemplary embodiment of the present invention. 
           [0013]      FIG. 2  is a flowchart illustrating the operation of the main code and its interaction with the script according to an exemplary embodiment of the present invention. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
     A. Glossary 
       [0014]    Alternate Parameter Calculation—If a parameter is not available on the bus of a vehicle, a value for it may nevertheless be calculated based on other parameters that are available. It may also refer to a Parameter Override Calculation 
         [0015]    Asset—Typically a vehicle or automobile, such as a car, truck, bus, coach, motorbike, motorized tricycle, quad bike, snowmobile, emergency vehicle, delivery vehicle, service vehicle, taxi, train, boat or aeroplane, but can also include static or mobile excavators, back-hoes, construction machinery, other heavy machinery, cranes, farming equipment or any other self-powered equipment. An asset can be part of a fleet of assets, a group of assets, or a group of assets within a fleet. An asset may be referred to as a host. 
         [0016]    Asset Agnostic—Device agnosticism is the capacity of a computing component to work with various different systems without requiring any special adaptations. Herein, we refer to the ability of a computing module (the main code) to work with various different assets without needing any special adaptation or configuration. 
         [0017]    Bus or System Bus—For example, a bus in a controller area network, such as a CANbus. A bus connects all devices in the network together. 
         [0018]    Engine—Typically an internal combustion engine, such as gasoline or diesel powered, but may also include dual fuel engines, hybrid engines, electrical motors, fuel cell engines, pressurized air engines, multiple engines within the same vehicle and other types of engine. 
         [0019]    Module—Can refer to any component in this invention and its network and to any or all of the features of the invention without limitation. 
         [0020]    Network—Can include, for example, both a mobile network and data network without limiting the terms meaning, and includes the use of wireless (2G, 3G, 4G, WiFi, WiMAX™, Wireless USB (Universal Serial Bus), Zigbee™, Bluetooth™ and satellite), and/or hard wired connections such as internet, Ethernet, ADSL (Asymmetrical Digital Subscriber Line), DSL (Digital Subscriber Line), cable modem, T1, T3, fibre, dial-up modem, etc. 
         [0021]    Parameter Override Calculation—When a value of a parameter is retrieved from a bus it is modified using a calculation or algorithm, resulting in a different value of the parameter. This may be useful if it is considered that errors are present in the raw value of the parameter as received from the bus, or merely if a different methodology of determining the value of the parameter is required. 
         [0022]    Parameter Calculation System—Used to describe the system of the present invention as a whole. In other words, it is an abbreviated form for an asset-agnostic framework with asset-specific module for alternate bus parameter calculation. 
         [0023]    Processor—Refers to any electronic circuit or group of circuits that perform calculations, and may include, for example, single or multicore processors, an ASIC (Application Specific Integrated Circuit), and dedicated circuits implemented, for example, on a reconfigurable device such as an FPGA (Field Programmable Gate Array). The processor performs the steps in the flowchart, whether they are explicitly described as being executed by the processor or whether the execution thereby is implicit due to the steps being described as performed by code or a module. 
         [0024]    Server—Refers to any computing device, or group of devices, that provide the functions described herein as being provided by one or more servers. 
       B. Exemplary Embodiment 
       [0025]    Referring to  FIG. 1 , an exemplary parameter calculation system  10  is shown, according to an embodiment of the present invention. The parameter calculation system  10  monitors and overrides bus parameters in a vehicle  12 , which is typically equipped with engine  14 , engine control unit (ECU)  16 , one or more vehicle components  18  and a vehicle bus  20 , which connects to the ECU and vehicle components. Attached to the bus  20  is a parameter calculation unit  30 , which includes a processor  32  operably connected to a random access memory (RAM)  34 , a memory  36  storing computer readable instructions that form the main code  38  and computer readable instructions that form a script  42 . Memory  36  may be, for example, be a hard disk drive or solid-state memory. Alternately, memory  36  may be divided into one or more individual memories. Also present in the calculation unit  30  is a communications module  60  that permits communication of data, requests and/or instructions to and from the calculation unit. 
         [0026]    In operation, the processor  32  loads the main code  38  and the script  42  into the RAM  34 , and then proceeds to process the computer readable instructions of the main code, referring, when required, to the script, both of which are now in the RAM. The main code  38  and the script  42  are responsible for the main functionality of the parameter calculation unit  30 , this being to monitor the vehicle bus  20  for data, to override one or more parameters obtained from the vehicle bus, to calculate parameters not directly available from the bus and to update itself without needing to undergo a reboot or restart. A further function of the parameter calculation unit  30  is to transmit the resulting values of the parameters to a remote monitoring location. The script  42  is vehicle specific in that it defines the specific parameters that the main code  38  looks for, while the main code is asset agnostic and acts as a framework for parameter value collection that is common to different vehicles. The script  42  is typically a small file, and may be significantly smaller than the main code  38 . 
         [0027]    The parameter calculation unit  30  is connected from its communications module  60 , via wireless connection  62 , network  64 , and wired and/or wireless connection  66  to a management server  70 . The management server  70  is separate from and located remotely from the vehicle. The network  64  may be or include the internet, and may be or include a cellular or satellite telecommunications network. The management server  70  typically includes a processor  72  and one or more computer readable memories  74  connected thereto, the memories including computer readable instructions  76  and computer readable data  78 . The management server  70  is used for sending the script  42  and/or updates of the script to the vehicle  12 , and for receiving and storing parameter values from the vehicle, whether they be obtained directly from the vehicle bus  20  or result from alternate parameter calculations performed by the script. 
         [0028]    Referring to  FIG. 2 , a flowchart shows the main steps in the operation of the parameter calculation system  10 , in relation to the main code  38  and the script  42 . At step  100 , the process starts when the ignition of the vehicle is turned on, or when the vehicle is otherwise powered up. Next, in step  102 , the main code  38  is loaded into the RAM  34  by the processor  32 , and then, in step  104 , the script  42  is also loaded into the RAM by the processor  32 . After the main code  38  and the script  42  have been loaded into RAM, the main code in step  110  queries the script on the parameters it should replace/reproduce. These are the parameters that can be obtained directly from the bus  20  and that do not need to be subject to an alternate parameter or override calculation. In response, the script  42 , which stores a list  112  of the parameters that need to be reproduced, provides them to the main code  38 . Once the parameters have been received from the bus, which occurs in step  129 , the main code  38  passes them down to the script  42  for further processing (see below). The system  10  is configured to read all or certain parameters either by means of listening for broadcasts, or by sending a request via the bus to the ECU to obtain a certain parameter at certain intervals or with a certain frequency, or using a combination of the two. 
         [0029]    The script  38  can be customized to a specific vehicle or specific make and model of a vehicle, without the need to customize the main code  42 . Also, the script  42  can be updated in both the memory  36  and the RAM  34  without needing to update or replace the main code  38 , which means that the main code can continue to function without having to restart it or reboot the parameter calculation unit  30  after the script has been updated. During a script update, the main code  38  runs without interruption and does what it needs to do, but the processing of parameters that need to be reproduced will temporarily be paused for the script update, the duration of which is typically a fraction of a second. 
         [0030]    In step  120 , the main code requests the acceptable alternate parameters to be calculated. These parameters are either those that are not obtainable directly from the bus  20 , or those that are obtainable directly from the bus but for which an alternate calculation is desired, i.e. a parameter override value. In this step, the main code  38  requests the script  42  to supply the alternate parameters to be reproduced. In response, the script  42 , which stores a list  122  of the alternate parameters that need to be reproduced, provides them to the main code  38 . Once the necessary data has been received from the bus, which occurs in step  129 , the main code  38  passes it down to the script  42  for further processing (see below). As above, the script  38  can therefore be customized to a specific vehicle or specific make and model of a vehicle, without the need to customize the main code  42 . The final value of the parameter that is obtained is therefore different to a raw value, if any, of the parameter that would be obtainable from the information from the bus without performing an algorithm. 
         [0031]    Communication between the main code  38  and the script  42  can be implemented using any suitable protocol, and only a simple protocol is sufficient. 
         [0032]    In some embodiments, there may be more than one alternate way of calculating an alternate parameter, such as fuel consumption. For example an engineer for a fleet management company may want to use a different calculation or algorithm than one created by an engineer that has designed the calculation override system  10 . Some or all ways or algorithms for calculating the alternate parameter may be included in the script, and they may be ranked according to which should be used in priority. For example, in some situations, it may not be possible for the main script to calculate the value of the alternate parameter using a particular way, due to lack of underlying data from the bus. In such a case, a lower-ranked way to calculate the alternate parameter will be used. Application of the various algorithms to the data on the bus may be attempted in order of their rankings until one of them yields a value for the parameter. As such, the parameter calculation unit  30  is effectively and automatically self-configuring. The rankings in the script  42  may be customizable by the fleet manager, via interaction with the management server  70 . 
         [0033]    After the main code  38  has been loaded into RAM  34 , in step  102 , the process splits into a second channel in which the vehicle bus  20  is monitored, in step  126 . This step repeats itself continually, regularly or intermittently in order to capture activity that occurs on the bus  20 . Data that is read from the bus is stored in a queue  128 , from which it is read by the main code in step  129 , in which the parameters are obtained from the bus. Such activity includes data produced by the ECU  16  and components  18 , which serves directly as parameter values or as parameter values that are subject to parameter override calculations or alternate parameter calculations. 
         [0034]    In step  130 , the main code  38  requests the calculation of a value of an alternate parameter. The request may be generated by a timer in the override unit  30 , and may be generated every 0.5 sec or every 5 sec, for example, and such time interval can be dynamically adjusted and/or set by a fleet manager through the management server  70 . 
         [0035]    In other cases, the request may be made as a result of a communication from the management server  70 . The request, which includes values from the bus, is passed by the main code  38  to the script  42 , where, in step  132 , the alternate value of the parameter is calculated. The script  42  then returns the calculated parameter value to the main code  38 . 
         [0036]    In step  140 , the calculated alternate value of the parameter is then reposted to the management server  70 , either immediately or as and when a communications channel is opened between the communications module  60  and the management server. If the alternate value is not immediately transmitted, it may be stored in memory in the override unit  30  until it can be transmitted. 
         [0037]    Steps  130  and  140  are repeated as and when a request is generated for the calculation of an alternate parameter value. As well as the parameter calculation unit  30  calculating the alternate parameters, it may also retrieve and transmit parameters that do not need to be subjected to an override calculation. 
         [0038]    A possible benefit of the parameter calculation system  10  is that parameter values arriving at the management server  70  conform with each other in the way they are calculated. They may not have the same numerical value, but they will have been calculated based on common principles. Differences in the algorithms present in different types of vehicle compensate for differences in the way that the buses and/or components in the vehicles provide information to the bus. Values for a given parameter obtained from a group of different types of vehicle are therefore uniform and consistent, and do not need to be subjected to further amendment, calculation or correction. This is important because different calculations would need to be made at the management server  70  for different makes, models and/or year of the vehicles in a fleet, and this post-processing may consume excessive computing resources, especially for fleets with hundreds or thousands of vehicles, each with multiple parameters that need to be overridden. 
         [0039]    Another possible benefit of the parameter calculation system is that the vehicle bus  20  may continue to be monitored during an update of the script  42 , i.e. without requiring any downtime. Updates to the script  42  may be initiated automatically by the management server  70  or another, update server, they may be initiated by a fleet manager via the management server, or they may be initiated in response to a check for updates that is made by the main code  38 . Updates may be made by FTP (File Transfer Protocol), for example, and once the update has been received by the parameter calculation unit  30 , step  104  is invoked to load the new script into the RAM  34 . Following this, steps  110  and  120  are repeated. By only updating the script  42  and not the combination of the script and the main code  38 , then the updating process is more efficient and takes less time. Also, there are many more opportunities to update the script  42  than if the main code  38  had to be updated at the same time, which would entail interruption of monitoring of the vehicle bus  20 . 
         [0040]    Another possible benefit of the parameter calculation system is that fleet managers using it can customize it according to their particular needs. 
       C. Example of Alternate Parameter Calculation 
       [0041]    Not all vehicles provide SPN250 data, which represents total fuel consumption for a vehicle. Instead, those vehicles report 0. In recent years, some manufacturers have stopped reporting SPN250 data. Alternate parameters that can be used are SPN183 (Engine Fuel Rate—amount of fuel consumed by engine per unit time) and SPN185 (Engine Average Fuel Economy—Average of instantaneous fuel economy for the segment of vehicle operation of interest). TABLE 1 gives an example of some of the data obtained from the bus of a test vehicle, which does report SPN250. The Data column gives the values of the total fuel consumption, either obtained directly from the bus as in SPN250, or calculated from the other bus parameters. 
         [0000]    
       
         
               
               
               
               
               
             
               
               
               
               
               
             
           
               
                   
                 TABLE 1 
               
               
                   
                   
               
               
                   
                 SPN (Suspect 
                   
                   
                   
               
               
                   
                 Parameter 
               
               
                   
                 Number) 
                 Data 
                 Difference 
                 % Difference 
               
               
                   
                   
               
             
             
               
                   
               
             
          
           
               
                   
                 250 
                 397 
                   
                   
               
               
                   
                 183 
                 391.871 
                 5.129 
                 1.29 
               
               
                   
                 185 
                 394.705 
                 2.295 
                 0.58 
               
               
                   
                   
               
             
          
         
       
     
         [0042]    Test systems were run for several months, both in trucks and in the lab. Either the SPN183 or the SPN185 bus parameter is suitable for the alternate calculation of the total fuel consumption, and each may be made more accurate by multiplying by a simple correction factor. More complex, alternate parameters may be calculated by the use of one or more algorithms. 
       D. Variations 
       [0043]    The various parts of the parameter calculation system  10 , such as the parameter calculation unit  30  and the management server  70 , may also provide additional functionality not described herein. This additional functionality may be that known in the art or it may be further functionality. The parameter calculation system  10  may also be incorporated as part of a more general asset locator system, and/or a tachograph. 
         [0044]    While total fuel consumption has been given as a parameter for which an alternate value is calculated, other parameters can be subject to alternate or override calculations, such as speed, acceleration, geographic location, idling time, trip time, trip distance, total fuel, trip fuel, fast braking, sharp braking, etc. 
         [0045]    As well as being useful for fleets of vehicles, the parameter calculation system  30  may be used for a single vehicle. 
         [0046]    It is foreseeable that the main code  38  may on occasion need to be updated, perhaps to add further functionality, to make it more resistant to cyber attacks or to remove bugs. In this case, the update of the main code  38  may require the parameter calculation unit  30  to be rebooted or restarted. 
         [0047]    In general, unless otherwise indicated, singular elements may be in the plural and vice versa with no loss of generality. 
         [0048]    Throughout the description, specific details have been set forth in order to provide a more thorough understanding of the invention. However, the invention may be practiced without these particulars. In other instances, well known elements have not been shown or described in detail to avoid unnecessarily obscuring the invention. Accordingly, the specification and drawings are to be regarded in an illustrative, rather than a restrictive, sense. 
         [0049]    The detailed description has been presented partly in terms of methods or processes, symbolic representations of operations, functionalities and features of the invention. These method descriptions and representations are the means used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. A software implemented method or process is here, and generally, understood to be a self-consistent sequence of steps leading to a desired result. These steps require physical manipulations of physical quantities. Often, but not necessarily, these quantities take the form of electrical or magnetic signals or values capable of being stored, transferred, combined, compared, and otherwise manipulated. It will be further appreciated that the line between hardware and software is not always sharp, it being understood by those skilled in the art that the software implemented processes described herein may be embodied in hardware, firmware, software, or any combination thereof. Such processes may be controlled by coded instructions such as microcode and/or by stored programming instructions in one or more tangible or non-transient media readable by a computer or processor. The code modules may be stored in any computer storage system or device, such as hard disk drives, optical drives, solid state memories, etc. The methods may alternatively be embodied partly or wholly in specialized computer hardware, such as ASIC or FPGA circuitry. 
         [0050]    It will be clear to one having skill in the art that variations to the specific details disclosed herein can be made, resulting in other embodiments that are within the scope of the invention disclosed. Steps in the flowchart may be performed in a different order, other steps may be added, or one or more may be removed without altering the main function of the system. All values and configurations described herein are examples only and actual values of such depend on the specific embodiment. Accordingly, the scope of the invention is to be construed in accordance with the substance defined by the following claims.