GB2620581A

GB2620581A - Controller area network (CAN) database cyclic redundancy check

Info

Publication number: GB2620581A
Application number: GB2210179.4A
Authority: GB
Inventors: Holmes Dave
Original assignee: JC Bamford Excavators Ltd
Current assignee: JC Bamford Excavators Ltd
Priority date: 2022-07-11
Filing date: 2022-07-11
Publication date: 2024-01-17
Also published as: GB202210179D0

Abstract

Configuring functional devices in a working machine, e.g., a digger, backhoe, by receiving (702) at first and second nodes of the working machine, a control area network (CAN) message database comprising identification information and configuration information, and a CAN message database check value based on data in the CAN message database. The first node generates (704) both a CAN message for the second node comprising information of desired configuration of the functional devices and a first CAN message check value, based on data within the CAN message. The first node transmits (706) the CAN message, the first CAN message check value and the CAN message database check value to the second node. The second node generates (710) a second CAN message check value from the received CAN message. A comparison (712) of check values at the second node made. A difference results in a fault signal (714). No difference results in configuration being implemented (716).

Description

Controller Area Network (CAN) database cyclic redundancy check

FIELD

The present teachings relate to a communication system for communicating between nodes in a vehicle, such that nodes, electronic controller units (ECUs) and/or system displays that communicate with one another over a controlled area network bus (CAN bus) are aligned such that they are operating using the same controlled area network (CAN) message layout and database, and a method for communicating between nodes in a vehicle.

BACKGROUND

Working vehicles or working machines (such as tractors, backhoe loaders, slew excavators, telescopic handlers, forklifts and skid-steer loaders, etc) include an engine system for providing power to the working machine.

Software developed for a working machine may be developed by multiple teams, or third parties. During development in order to ensure compatibility the development of the system, in particular configuration information about the vehicle, should be provided in the same format. Configuration information may include information as presented in the controlled area network database (CAN DBC) format. Such information may include information regarding the functionality of the vehicle, or components in the vehicle.

However, where multiple parties are involved inconsistencies in the programming process may occur resulting in incompatibilities between nodes, or unintended functionality. As new functions are added to the software, or more parties are involved in the programming of the vehicle, the possibility of a misalignment or incompatibility increases. In the prior art in order to decrease such events, updates can be manually checked by standard software development procedures e.g., code review, bench testing, integration testing.

As working machines develop and evolve, the complexity levels of functions and systems within the working machine continue to increase. For example, consider a programmable joystick feature that may be present in the working machine. These programmable joysticks can have a large number of programmable buttons and toggles and an even larger number of functions that can be associated with said programmable buttons and toggles. Data is often stored within the display or ECUs of the working machine, the data is defined by two separate enumerations i.e. programmable buttons/toggles and functions. The problem that arises with the vast number of possible combinations of programmable buttons/toggles and functions, and the different programming teams, is that the likelihood of two enumerations becoming misaligned between the display and ECUs increases. This could occur when either the display/ECU team enter the data incorrectly in the code, use the wrong version of database, or the nodes are updated at different times. If the values are misaligned, then the user could be at risk of experiencing incompatibilities between nodes, or unintended functionality of the working machine with serious consequences.

The present teachings seek to overcome or at least mitigate one or more problems

associated with the prior art.

SUMMARY

The present invention provides a method and system according to the appended claims.

A first aspect of the teachings provides a method of configuring a plurality of functional devices or nodes in a working machine, the method comprising any or all of the following: receiving, at a first node and a second node of a working machine, a CAN message database, wherein the CAN message database includes identification information and configuration information for the functional devices, and a CAN message database check value based on data in the CAN message database, generating, at the first node, a CAN message for the second node, the CAN message including information indicative of a desired configuration of one or more of the plurality of functional devices and generating a first CAN message check value, based on data within the CAN message, transmitting the CAN message, the first CAN message check value and the CAN message database check value to the second node, receiving the CAN message, CAN message check value and CAN message database check value at the second node and generating a second CAN message check value from the received CAN message, comparing the first and second CAN message check values; and comparing the CAN message database check values received directly at the second node and received via the first node; and if there is a difference in the first and second CAN message check values or the CAN message database check values generating a fault signal; or if there is no difference in the first and second CAN message check values and no difference in the CAN message database check values, implementing the desired configuration in the second node.

In this arrangement, the method provides the advantage of ensuring that the functional devices or nodes within a working machine are all in alignment and compatible with one another even as software development of the working machine occurs by different parties that may change the functionality of the working machine. This has the advantage of reducing the risk of incompatibilities and misalignments between nodes caused by using the wrong iteration of CAN message database or differences in CAN message layout etc. Therefore, the likelihood of unintended functionality is reduced, protecting both the vehicle, associated systems and the user.

The CAN message database check value, which is received at the first node, may be transmitted from the first node to the second node separately from the CAN message.

The CAN message database check value may be transmitted from the first node when the first node and second node are powered-on.

The comparison of the CAN message database check values may be carried out when the first and second nodes are powered-on at working machine start-up.

The CAN message database and CAN message database check value may be received from a server.

The CAN message check value and CAN message database check value may include a checksum or a CRC.

Transmitting of the CAN message, the first CAN message check value and the CAN message database check value to the second node may follow an operator configuring a machine controller, and, wherein, the operator configures the controller using a display, and/or wherein, optionally, the controller is a joystick.

The CAN messages may be controlled by a CAN bus, wherein the fault signal may cause the CAN bus to disable one or more nodes and/or may cause the CAN bus to issue a shutdown signal.

In response to the fault signal the method may revert to a default state and/or may revert to a previous state where the first and second CAN message check value and the first and second CAN message database check value matched.

If the first and second CAN message check values and the first and second CAN message database check value match the working machine may start.

The first and second nodes may be electronic control units of the working machine. The first and second nodes may be displays of the working machine.

When comparing a received CAN message to a threshold length, if the received CAN message length is outside a threshold range a fault signal may be generated.

The CAN message may be generated by parsing the CAN message database to identify an attribute identification information and configuration information for the attribute and extracting the identified information as configuration information.

The CAN message, for the second node, may be generated by parsing the CAN message database containing the plurality of CAN messages from one or more nodes in the working machine.

The CAN message may include one or more of the following data values: a CAN message layout; encoder/decoder identification; signal scaling value; enumeration value; and range information.

A second aspect of the teachings provides a system of functional devices or nodes in a working machine, the system comprising any or all of the following features: a first and second node, the first and second nodes being configured to receive, a CAN message database, wherein the CAN message database comprises identification information and configuration information for the functional devices, and a CAN message database check value based on the data in the CAN message database. The first node being further configured to generate a CAN message for the second node, the CAN message comprising information indicative of a desired configuration of one or more of the functional devices and generating a first CAN message check value, based on the data within the CAN message and transmitting the CAN message, the first CAN message check value and the CAN message database check value to the second node, the second node being further configured to: receive the CAN message, CAN message check value and CAN message database check value and generate generating a second CAN message check value from the received CAN message, comparing the first and second CAN message check value; and comparing the CAN message database check values received directly at the second node and received via the first node, if there is a difference in the first and second CAN message check values or the CAN message database check values generating a fault signal; or if there is no difference in the first and second CAN message check values and no difference in the CAN message database check values, implementing the desired configuration in the second node.

The CAN message database check value, received at the first node, may be transmitted from the first node to the second node separately from the CAN message.

The CAN messages may be controlled by a CAN bus.

The fault signal may cause the CAN bus to disable one or more nodes and/or may cause the CAN bus to issue a shutdown signal.

In response to the fault signal the system may revert to a default state and/or may revert to a previous state where the first and second CAN message check value and the first and second CAN message database check value matched.

If the first and second CAN message check value and the first and second CAN message database check values match the working machine may start.

The first and second nodes may be electronic control units and/or may be displays of the working machine.

The second node may be further configured to compare the received CAN message to a threshold length, and if the received CAN message has a length outside a threshold range, may generate a fault signal.

The first node may be further configured to generate the CAN message, by parsing the CAN message database to identify attribute identification information and configuration information for the attribute and extracting the identified information as configuration information.

The first node may be further configured to generate the CAN message, for the second node, by parsing the CAN message database containing a plurality of CAN messages from one or more nodes in the working machine.

A third aspect of the teachings provides a device for use with a working machine comprising a plurality of functional devices or nodes, the device comprising any or all of the following features: a server, wherein the server is in communication with a CAN Bus network of the working machine, the server being configured to: update a CAN message database, wherein the CAN message database comprises identification information and configuration information for the functional devices, execute a script to convert one or more entries in the CAN message database, into a format for use by the functional device or node; and generate a CAN message database check value based on the contents of the CAN message database, transmitting the CAN message database and the CAN message database check value to a first and second node of the working machine.

In this arrangement, the device provides the advantage of ensuring that the CAN message database is contained in a separate device to the working machine. Therefore, in the event of incompatibilities being introduced during software updates or configuration changes the device can provide a backup database where the software and configuration of the working machine is known.

The CAN message database check value may comprise a checksum or a CRC.

The first and second nodes of the working machine may be electronic control units and/or displays.

The script may convert the one or more entries in the CAN message database into an executable code.

The script may convert the one or more entries in the CAN message database by parsing the one or more entries in the CAN message database to create one or more outputs.

The outputs may be one or more of the following data values: a CAN message layout; encoder/decoder identification; signal scaling value; enumeration value; and range information.

A fourth aspect of the teachings provides a method of configuring a device for use with a working machine comprising a plurality of functional devices or nodes, the method comprising any or all of the following features: updating a CAN message database, on a server, wherein the CAN message database comprises identification information and configuration information for the functional devices or nodes, executing, a script to convert one or more entries in the CAN message database, into a format for use by the functional device or node; generating a CAN message database check value based on the processed CAN message database, transmitting the CAN message database and CAN message database check value to a first and second node of the working machine.

The CAN message database check value may comprise a checksum or a CRC.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments will now be described with reference to the accompanying drawings, in which: Figure 1 is a side view of a working machine comprising an engine system and associated controller according to the present teachings; Figure 2 is a block diagram of an engine system of the working vehicle including the associated controller of Figure 1; Figure 3 is a simplified system diagram of a typical node or ECU including the controller of Figure 2, as implemented in the working vehicle; Figure 4 is a simplified system diagram of the CAN bus network containing a plurality of ECUs as in Figure 3, as implemented in the working vehicle; Figure 5 is a script flow diagram performed by the system of functional devices as implemented in the working vehicle; Figure 6 is an application flow diagram performed by the system of functional devices as implemented in the working vehicle.

Figure 7 is a system flow diagram performed by the system of functional devices, as implemented in the working vehicle.

DETAILED DESCRIPTION OF EMBODIMENT(S)

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of various embodiments and the inventive concepts of the present teachings. However, those skilled in the art will understand that: the present invention may be practiced without these specific details or with known equivalents of the specific details; that the present invention is not limited to the described embodiments; and, that the present invention may be practiced in a variety of alternative embodiments. It will also be appreciated that well known methods, procedures, components, and systems may have not been described in detail.

Referring firstly to Figure 1, a working machine is indicated generally at 10. In the illustrated embodiments, the working machine 10 is a backhoe loader. In alternative embodiments, the working machine 10 is a different type of working machine, e.g., a tractor, an excavator, a forklift, a telehandler or a skid steer loader.

The working machine 10 includes a body 102 supported on a ground engaging structure in the form of wheels 104, and a cab 106 for an operator. The body mounts a plurality of working arms. Specifically, a pair of front loader arms 108 (one shown) are pivotable about a horizontal axis to mount a working implement 110, in this embodiment a shovel 110. A rear backhoe includes a boom 112a pivotably mounted to the body 102 for movement about a vertical and horizontal axis at one end, and itself mounts a dipper 112b for pivotable movement about a further horizontal axis. The free end of the dipper 112b mounts a bucket 114 for performing excavating functions. The shovel 110 and the bucket 114 may however be exchanged for alternate attachments (not shown) such as forks, pallet forks, breaker hammers and the like, as is well known.

As illustrated in Figures 1 and 2, the working machine 10 includes an engine system 20 with an engine 202 incorporating fuel injector(s) 204 (typically one per cylinder), an aftertreatment system 206 and a thermal management system 208. The engine system 20 also includes a fuel pump (not shown), in fluid communication with a fuel tank 210, and a coolant circulation system 212 including a coolant pump (not shown), a heat exchanger 214 and a fan 216. It shall be appreciated that any combination of the components of the engine system may be included or omitted.

The after-treatment system 206 includes an exhaust duct 118.

In the working vehicle, the engine 202 is a diesel internal combustion (IC) engine 202, however it shall be appreciated that in alternative embodiments the engine 202 may comprise one or more of a diesel fuelled engine, a petrol fuelled (gasoline) engine, a gas fuelled engine (e.g. hydrogen or compressed natural gas) and/or an electric motor. The engine 202 runs at a range of operational speeds during operation of the working machine 10 and may also run at an idle speed. The idle speed is generally in the range 750rpm to 800rpm. In alternative embodiments, any suitable idle speed may be used.

The engine 202 provides propulsion to the wheels 104 via a suitable transmission and drivetrain (not shown). The engine 202 also powers a hydraulic pump (not shown) that via a suitable spool valve (not shown) linked to operator controls enable the operator to selectively supply hydraulic fluid to one or more hydraulic actuators 116 to manipulate the working arms 108, 112a, 112b and thereby perform working operations. In alternative working machines, the engine may additionally or alternatively power electrical generators, power take-offs, lifting booms, tipping mechanisms or the like.

The fuel injector 204 is controlled by an electrically controlled valve (not shown) at its tip or nozzle that is supplied with pressurised fuel from the fuel tank 210 by the fuel pump and when energised, atomises the fuel into a fine mist so that it can burn in the engine 202 such that the engine runs at a required speed of the engine. In some embodiments, the fuel injector 204 may be provided with an internal cooling system forming part of the coolant circuit to allow coolant to circulate around the fuel injector 204 so that the coolant can transfer heat away from the fuel injector 204.

The coolant pump pumps coolant around the coolant circulation system 212. The coolant circulation system or fan 212 removes heat energy from the engine system 20 and expels it to atmosphere, thereby cooling the engine system 20. It shall be appreciated that any suitable arrangement of coolant circulation system may be used to cool the components of the engine system 20. The operation of the cooling system may at least partially be driven by the engine 202. For example, the coolant system may be provided with a coolant reservoir, galleries in an engine block, cylinder head etc of the engine and one or more heat exchangers 214 and a coolant pump that is driven by the engine 202 and circulates the coolant through the galleries where heat is transferred from the engine and then into the heat excha nger.

The fan 216 is used to force air past the heat exchanger containing the coolant to cool it before it returns to the galleries. The fan 216 may also cool the engine 202 directly by drawing air past it within an engine compartment or canopy during operation of the working machine and during extended engine shutdown. In this embodiment, the fan 212 is powered directly or indirectly by the engine 202, and a speed of the fan 212 is proportional or influenced by the speed of the engine 202.

The controller 218 or engine controller 218 may be a microprocessor or a microcontroller that is part of, or incorporated into, an existing electronic control unit of the working machine, for example an Engine electronic control unit (EECU).

In this case the engine controller 218 is configured to control the operation of the engine, such as to receive an engine shutdown signal from the user operating an engine shutdown device 220 or startup signals, or configured to derive, infer or receive a temperature parameter of the engine system 20 and to determine whether the temperature parameter is above a first predetermined threshold etc. The controller 218 may indicate to the operator, for example via a device such as a display 222. The controller 218 is further configured to be in connection with a device 224. This device could be a plurality of components for controlling the working vehicle, such as a foot pedal etc. The controller 218 is also in connection with a sensor arrangement 226; in the case of the engine system 20 the sensors could include a coolant temperature sensor 226a, a fuel temperature sensor 226b, an exhaust temperature sensor 226c, an ambient temperature sensor 226d and an engine speed sensor 226e among many others.

The engine controller 218 is in communication with other ECUs, otherwise known as nodes, throughout the working vehicle or working machine, via the larger EECU which it communicates with via CAN messages utilising a CAN bus. There are a plurality of further ECUs or nodes connected to the same CAN bus, that are performing different operations. Most notably there will be a Display ECU and a Machine ECU connected to the CAN bus. The plurality of ECUs in the working vehicle are also in communication with a central server that the ECUs communicate with via CAN message on the CAN bus. In the present disclosure, these ECUs will be used within the working machine, along with the central server, to ensure that participating ECUs are operating using the same databases. If these ECUs find that there is an error or misalignment between ECUs or central server, such that different databases may be being used, then alarms and warnings will be operated, and primary functions of the working vehicle would be disabled. For example, in reference to Figures 1 and 2, the Display ECU or Machine ECU would communicate with the [ECU or engine controller 218 via the CAN bus and prevent an engine startup command or any other function start command, such that it can prevent the system from unexpected or unintended functionality.

Figure 3 shows a simplified system diagram for a typical ECU or node, as could be implemented in the working machine. In this case, it can be considered that the ECU 30 could be the Engine ECU as discussed in relation to Figure 2. The ECU 30 comprises of a controller 218, analog and digital inputs 302, a power supply 304, a CAN communication port 306, a memory 308 such as FLASH or RAM and output ports 310. The controller 218 is the engine controller as discussed in Figure 2 and thus shows how the controller 218 fits into an ECU 30.

The controller 218 executes many different functions during operation, this is shown in Figure 3 through the applications 2182, control software 2184 and database alignment script 2186. The ECU will be associated with a CAN message database, which in some embodiments is stored in the memory 308, or in further embodiments is stored separately to, but is accessible by, the ECU. In some embodiments each ECU in the working vehicle has an individual associated database, in further embodiments two or more ECUs may share a database (not shown).

The database alignment script 2186 will be used to ensure the CAN message databases used by different ECUs throughout the working vehicle are aligned. Moreover, the database alignment script 2186 will be used to ensure that the ECUs on the working machine are using the same CAN message database that is present on the central server (not shown). As described in detail below, the database alignment script 2186 at a first ECU will receive a CAN message database and a CAN message database check value or checksum, from an external, central, database at the server i.e. a database that is not associated with the ECU.

The database alignment script 2186 will in turn generate a CAN message comprising the information indicative of a desired configuration of one or more of the plurality of functional devices and generate a first CAN message check value or checksum, based on data within the CAN message. The generated CAN message, CAN message check value and the CAN message database check value or checksum will then be transmitted to a second ECU. The second ECU will then receive the CAN message, CAN message check value and CAN message database check value from the first ECU and then generate a second CAN message check value from the received CAN message.

This second ECU will have already received a CAN message database and a CAN message database check value from the external or central server. At the second ECU, the first and second CAN message check values will be compared and the CAN message database check values from the first ECU and the central server will be compared. If there is a difference between the first and second CAN message check values or the CAN message database check values then a fault signal is generated, if there is no difference between the first and second CAN message check values and the CAN message database check values then the desired configuration is implemented on the second ECU.

This process prevents any unexpected incompatibility or unexpected functionality as a result of errors or offline updates to the overall working vehicles software or functions. During operation the database alignment script 2186 will create the database alignment code 21862 as part of the process in order to confirm alignment of CAN message database use and CAN message layout across all participating ECUs in the working vehicle. The plurality of analog and digital inputs 302 will be connected to a plurality of different sensor arrangements 226. The power supply 304 would be connected to an external power supply such as a battery 312, for example. The CAN communication port 306 will be connected to the CAN bus 314, such that the ECU can communicate with the other ECUs in the working vehicle and the external/central server. The ECU 30 will send and receive CAN messages via the CAN bus 314 and via the CAN communication port 306. The memory 308 will store a plurality of different system data such as the CAN message database details and CAN message data that will be used during the database alignment processing by the database alignment script 2186 and database alignment code 21862. The output ports 310 will be connected to multiple different actuation points in order to actuate different functions of the working vehicle such as engine 202 shutdown, engine 202 startup, activation of lights, activation of cameras etc. Figure 4 illustrates a simplified system diagram of the CAN bus communication network 40 as implemented in the working machine or working vehicle. In this first embodiment, the CAN bus communication network 40 contains a Display ECU 402, the Controller ECU 404, the Engine ECU 30, the Machine ECU (MECU) 408, a Transmission ECU 410 and a central server 412 are all connected to the CAN bus 314. This is just for illustrative purposes and there would be a plurality of further ECUs connected to and communicating on the CAN bus 314. All messages on the CAN bus 314 are stored in the database on the central server 412. Whilst the central server 412 is shown in Figure 4 for ease of reference, the server and associated database may be stored elsewhere, for example at another location in the vehicle or even off-vehicle.

In this scenario, the key nodes or ECUs connected to the CAN bus are the Display ECU 402 and the MECU 408. The Display ECU 402 and the MECU 408 can communicate and update each other despite the other nodes or ECUs being connected on the CAN bus by the process described below with reference to Figures 5 and 6. Briefly, the central server transmits a CAN message database and a first CAN message database check value or checksum to all participating ECUs, nodes or functional devices in the system. CAN messages are generated at a first ECU using the data indicative of a desired configuration of one or more of the plurality of functional devices. The CAN message consists of relevant entries related to the ECUs which are parsed from the CAN message database to find the data indicative of a desired configuration of one or more of the plurality of functional devices and formatted in a consistent manner. A CAN message check value or CRC value is determined for the CAN message, said CRC value (or other form of check value or checksum, such as a hash function) being generated from the data within the CAN message. The generated CAN message, CAN message check value and CAN message database check value are transmitted to a second relevant node or ECU -in this example from the Display ECU 402 to the MECU 408. The CAN message is decoded, and the second node or ECU generates a second CAN message check value or CRC value. If the first CAN message CRC value and the second CAN message CRC value match, and the CAN message database check values received from the first ECU and the central server match, then it is an indication that the system configurations and databases are in alignment.

Figure 5 illustrates the script flow diagram 50 of the system of functional devices, used by the central server 412to perform analysis on the associated central CAN message database, before using the outputs of the analysis to ensure that the data in the associated ECU CAN message databases is aligned with that in the central database at the central server 412.

In step 502, the CAN message database of the central server 412 is updated. The central server 412 and associated database may be external to the working vehicle or stored in a memory on the working vehicle. Importantly, the central database on the central server 412 is separate to any of the databases accessed by the nodes. Thus, the central database at the central server 412 is a store of data relating to identification information and configuration information for the functional devices.

At step 504, the process begins to prepare the CAN message data from the CAN message database for analysis. Firstly, a script parses the CAN data in the CAN message database that was updated in step 502. The CAN data in the CAN message database is parsed such that the information relevant to the participating nodes or ECUs (messages of interest) is extracted and the string of information can be separated into components that are more easily processed by other components of the system i.e. the script converts the CAN message database, or at least one or more entries in the CAN message database, into a format for use by the participating nodes, ECUs, functional devices etc of the working machine. In other words, this step will highlight the messages of interest to the participating ECUs from the plurality of CAN messages that are present in the CAN message database.

This is the case as not all messages on the CAN message database are relevant to the Display ECU 402 and MECU 40, as mentioned previously. Such messages may be identified by their contents, or functionality e.g., any message relating to engine parameters would be of interest to the engine ECU, or by reindicated user preference. In one example the system has a CAN receive spreadsheet which details which messages, or types of messages, are of interest to a node or ECU.

At step 506, the CAN receive spreadsheet relating to the associated CAN data is optionally edited to define, rearrange, or distil the parameters relating to the CAN messages of interest that were acquired during the parsing of the database in step 504.

At step 508, a further or second script is actioned to convert the data associated with the messages of interest, as highlighted in step 504, into code. The script automatically converts the messages of interest into the code without manual input. Thus, the data within the messages of interest will be converted into a.cpp file. This is advantageous as it ensures that no human error can be introduced at this stage. From this code, data of interest from the associated messages is extracted.

For example, the data of interest could be the CAN message structure (step 510), the CAN encode/decode function (step 512), the data scaling/enumeration/offset/range etc. (step 514).

The step of converting the CAN message data into code can occur defining 20 predefined message structures and syntax and parsing the message to automatically convert the message into the desired format. Other known suitable techniques may also be used.

At step 510, the CAN message structure is extracted from the code, as highlighted in step 508. The CAN message structure relates to various parameters that are captured within the formatting of the CAN message. This structure can include, the start of frame (SOF), the arbitration field, the control field, the data field, acknowledgement field, end of frame (EOF) and so on.

At step 512, the CAN encode/decode function is generated from the code, to enable any receiving node to decode the message. Any suitable known function may be 30 used.

At step 514, various data forms are extracted from the code, as highlighted in step 508. This could include data signal scaling values, enumeration values, offset values and range information.

At step 516, the script generates a CAN message database check value or 32-bit checksum or cyclic redundancy check (CRC) value of the central database at the central server 412 within the code i.e. the CRC is stored with the CAN database message. Moreover, the central database information will relate to configuration changes across the entire system, and not just the nodes, or ECUs, of interest.

Therefore, the CAN message database check value or CRC value generated will be dependent on all CAN messages in the system. As the central database at the central server 412 is updated with all CAN messages relating to the features of all functional devices, should a database associated with a node be updated separately, or miss an update, a comparison of the central database's CAN message database check value or CRC value generated at step 516 received directly at a node with the CAN message check value or CRC value received from a separate a node would provide a different result and thus be an indication of incompatibility or misalignment. Thus, the CAN message database checksum or CRC value and the CAN message database checksum or CRC value of other ECUs in the working vehicle will be used to compare. This comparison between other ECUs within the overall system will ensure that all participating ECUs are aligned and using the same CAN message database.

In a further step, the script then outputs the CAN message structure (as from step 510), encoder/decoder (as from step 512), and any other associated information such as signal scaling, enumeration values, range information (as from step 514) along with the 32-bit CRC value (as from step 516) into a source code file, or.cpp file for the Display ECU 402 and MECU 408 applications.

In a further embodiment, the script for completing checks to confirm that there is CAN message database and CAN message alignment, may include a further step wherein CAN messages in the database that are addressed to one or more of the plurality of nodes or ECUs are identified. A configuration message and first checksum value is then generated from the CAN messages which were identified as being addressed to one or more of the nodes.

In a further embodiment, the script for completing checks to confirm that there is CAN message and CAN message database alignment, may include a further step wherein the received CAN message will be compared at the ECU against a threshold length value. If the received CAN message length exceeds or is outside the range of the defined threshold length value or range, then a fault signal will be generated.

In a further embodiment, the script for completing checks to confirm that there is database alignment, may include a further step wherein the configuration message, which is created from the information indicative to changes in the control configuration, is generated by parsing the CAN message in order to identify attribute identification information and configuration information for the attribute and extracting the identified information as configuration information.

Figure 6 illustrates the application flow diagram 60 of the system of functional devices as implemented in the working vehicle.

At step 602, the user of the working machine or working vehicle switches on the ignition of the working machine or working vehicle. The signal is received in response to the user actuating the system ignition (e.g. a button, switch or key) to the on position. This is the first step in the start up of the working vehicle and associated systems.

At step 604, the Display ECU 402, the MECU 408 and other participating ECUs will startup or be powered-on. In other words, the first and second nodes will be powered-on at working machine start-up. Generally, the startup of an ECU is controlled by the ECU manager. The ECU manager is responsible for both the initialisation and deinitialisation of the ECU, as well as dictating the transition between ECU states such as startup, run, shutdown, sleep, wakeup and off. The main task during startup of the ECUs is to initialise basic software modules. Further, during startup the participating ECUs will receive the CAN message database and a CAN message database check value from the central server 412. The CAN message database will database comprise identification information and configuration information for the functional devices and the CAN message database check value will be based on the data in the CAN message database.

At step 606, the MECU 408 or first node will communicate with the Display ECU 402 or second node and send the CAN message database checksum or CRC which was received from the central server 412 on startup, this CRC value is the value generated by the database processing performed by the database conversion script as described with reference to Figure 5.

At step 608, the Display ECU 402 receives the CAN message database check value. The CAN message database check values received directly from the central server 412 and the MECU 408 will be compared. If the CAN message database check values received directly from the central server 412 and the MECU 408 match, then the CAN message databases are aligned. When the CAN message databases are aligned the system will move to step 612. If the CAN message database check values received from the MECU 408 and central server 412 do not match, then the CAN message databases used at the Display ECU 402 and the MECU 408 may be misaligned, and the system will move to step 610.

At step 610, it has been confirmed that the CAN message databases used at the Display ECU 402 and the MECU 408 are misaligned, as the CAN message database check values associated with these teams did not match. As a result, the ECU will create a fault signal and the system reverts the data back to the last CAN message database where the CAN message database check values associated with the Display ECU 402, the MECU 408 and central server 412 did match. Further communications between the Display ECU 402 and the MECU 408 are disabled until the system is reverted back to a set of data that is aligned. In the meantime, an alarm is raised on the display to alert the user and primary systems of the working vehicle are shutdown.

At step 612, it has been confirmed that the CAN message databases currently used at nodes, ECUs and central server 412 are aligned, as the CAN message database check values associated with these teams did match. Therefore, the system can continue with operation. In this case, the Display ECU 402 will load data provided via the user into the display. This user data could include changing certain functions associated to programmable buttons or toggles to customise the operation of the working machine or it could be a manual upload of a large system update or alike. From these changes, information that is indicative to the changes of configuration are highlighted. This information relating to configuration changes will form a CAN message, which will be used to compare the CAN message check values or CRC values or checksum values with other ECUs in the working vehicle.

At step 614, once the user has made all the changes to the system that they require as in step 612, the user must confirm that they have completed loading any user data or control configuration changes into the system. This is confirmed by the actuation of a button or toggle or alike. Once the changes are confirmed, the CAN message containing the configuration data is created and an associated first CAN message check value is created.

At step 616, the CAN message and first CAN message check value or CRC value for the user data inputted at the display, is communicated to the MECU 408 via the CAN bus 314.

At step 618, the MECU 408 will receive the CAN message and CAN message check value from the Display ECU 402 and will perform a similar operation as performed by the Display ECU 402 in step 608. This step regards comparing the CAN message check value or CRC value or checksum generated at the Display ECU 402 with the second CAN message check value or CRC value which will now be generated at the MECU 408 based on the data in the CAN message. This will ensure that the changes implemented by the user during the changes in control configuration have not introduced any errors or caused any problems to the associated databases and that the layout of the CAN message is correct. If the first and second CAN message check values or CRC values of the Display ECU 402 and the MECU 408 match, then the CAN message layouts are aligned, and the system will move to step 622. If the first and second CAN message check values or CRC values of the Display ECU 402 and the MECU 408 do not match, then the CAN message layouts are misaligned, and the system will move to step 620.

At step 620, it has been confirmed that the CAN message layouts are misaligned, as the first and second CAN message check values associated with these teams did not match. As a result, the ECU will create a fault signal and the system reverts the data back to the last CAN message database where the checksum or CRC values associated with the Display ECU 402 and the MECU 408 did match. Further communications between the Display ECU 402 and the MECU 408 are disabled until the system is reverted back to a set of data that is aligned, and the CAN message is discarded. In the meantime, an alarm is raised on the display to alert the user and primary systems of the working vehicle are shutdown.

At step 622, it has been confirmed that the CAN message layouts and the CAN message databases currently used at the Display ECU 402 and the MECU 408 are aligned, as the first and second CAN message check values and the CAN message database check values received from the MECU 408 and central server 412 in step 608, associated with these teams did match and thus the CAN message databases and CAN message layouts are aligned. Therefore, the system can continue with operation. The control configuration changes that were present in the CAN message will be implemented. Further, in this case, the system will act to bring all primary systems active and ready to use. The user will now be able to control the working vehicle as defined in the control configurations.

Figure 7 is a system flow diagram 70 performed by the system of functional devices, as implemented in the working vehicle.

In step 702, the steps completed in Figure 5 have been completed on the central database at the server 412. Therefore, a CAN message database check value has been generated and transmitted, along with the current central CAN message database, to the first and second node of the working machine. The check value could also be a checksum value or CRC value. The first and second node of the working machine could be the Display ECU 402 and the MECU 408. The first and second node receive the CAN message database and CAN message database file. The CAN message database comprises identification information and configuration information for the functional devices, and the CAN message database check value is based on data in the CAN message database.

In step 704, the first node generates a CAN message, where the CAN message comprising information indicative of a desired configuration of one or more of the plurality of functional devices. The first node also generates a first CAN message check value based on the data within the CAN message.

In step 706, the first node transmits the CAN message, first CAN message check value and CAN message database check value to second node.

In step 708, the second node receives the CAN message, first CAN message check value and CAN message database from the first node.

In step 710, the second node generates a second CAN message check value, based on the data within the CAN message which was received from the first node.

In step 712, the second node completes two comparisons. The second node compares the first and second CAN message check values to confirm that the CAN message layout is correct. The second node also compares the CAN message database check value received in step 702 and the CAN message database check value received from the first node in step 708, to confirm that the CAN message databases being used by the first and second nodes are up to date. If either of the comparisons show that one or more of the check values do not match the system will move to step 714. If both of the comparison show that all the check values match, then the system will move to step 716.

In step 714, either the first and second CAN message check values or the CAN message database check value received in step 702 and the CAN message database check value received from the first node in step 708 did not match and hence the CAN message layout and/or the CAN message databases are misaligned. To prevent unexpected functionality of the working machine the CAN message database is reverted back to the last instance when the CAN message database check value received in step 702 and the CAN message database check value received from the first node in step 708 matched. All primary systems are also disabled again to prevent unexpected functionality.

In step 716, the first and second CAN message check values and the CAN message database check value received in step 702 and the CAN message database check value received from the first node in step 708 did match. Thus, the CAN message layout and the CAN message databases are aligned and working as expected. Any control configuration changes that are present in the CAN message are implemented on the second node. Then, the system goes live and the working machine is ready to be used.

As stated previously, where multiple parties are involved inconsistencies in the programming process may occur resulting in incompatibilities between nodes, or unintended functionality. As new functions are added to the software, or more parties are involved in the programming of the vehicle, the possibility of a misalignment or incompatibility increases. In the prior art in order to decrease such events, updates can be manually checked by standard software development procedures e.g., code review, bench testing, integration testing. This can be time consuming. In particular, the present embodiment is advantageous in overcoming or at least mitigating against these highlighted challenges as it ensures that all CAN message layouts and databases between different working vehicle ECUs operating on the CAN bus are the same across the different nodes attached to a network. This prevents the working machine from being used in scenarios where different databases or CAN message layouts at present at different ECUs and therefore protects the working machine and the user from incompatibilities and unexpected functionality. Further, the use of the script and code to complete checks relating to the alignment of databases or CAN message layouts is advantageous in overcoming or at least mitigating against the challenges highlighted in the prior art, by ensuring that no human error can be added to the working machine system at that stage.

More generally, the communication network on the working machine consists of a plurality of nodes or ECUs. Each node within the network is capable of both transmitting and receiving multiple CAN messages over the CAN bus. Each of these CAN messages contains multiple signals. Additionally, each of these messages can be multiplexed which results in giving each message multiple further meanings.

Due to the magnitude of different messages, message signals and therefore data; the layout of the data within these messages becomes crucial. The message layout is crucial such that the decoders and encoders can easily and reliably extract the relevant data for the relevant function.

In this embodiment, the software developed on the working machine consists of 2 teams, nodes or ECUs, the embedded ECU team and the Display team. Each team must ensure that they are accurately developing to the same requirements to avoid any errors/mistakes where possible. Each CAN message that is sent between nodes must be correct to avoid unintended operation. Both, the transmitting node must encode the message correctly, and the receiving node must decode the message correctly. There are some common practices which already happen to ensure the robustness of the system. For example, the message length is considered, and we add a checksum to ensure the data we send matches the data we receive. If the message length is incorrect or the checksum does not match, the message is discarded. However, there is no check regarding the order or layout of the data as the project evolves and changes.

Once the systems encoders and decoders have extracted the relevant data for the relevant functions into a CAN DBC, the database is further processed. A script, which can run on the display and the embedded ECU, takes the data contained within the CAN DBC and converts it into code. It is important that the script converts the database into code to ensure that no human error is possibly introduced at this stage. The script, which is written in Qt(C++), converts the database file into C/C++ code or an executable code. The script will also parse the database, which incorporates a list of messages of interest to the application as defined by the user.

The messages of interest are of importance as the display and MECU do not listen to all messages on the CAN bus. The script then outputs the CAN message structure, encoder/decoder, and any other associated information such as signal scaling values, enumeration values, range information into a source code file, or.cpp file for the display and MECU applications. The script will also generate a 32-bit CRC from the database. This 32-bit CRC is copied into the display/MECU application. The system software actions the sending of the 32-bit CRC from the display to the MECU in the control configuration message and the hierarchical task analysis (HTA) sequence message. The MECU decodes the message and validates that the 32-bit CRC value received from the database for the display, matches the 32-bit CRC value generated from the database used by the MECU, or other participating ECUs. If the 32-bit CRC values do not match, then validation fails.

Subsequently, the MECU will discard any communications and raise an alarm on the working machine. Further, the MECU will disable all primary systems if the 32-bit CRC values do not match, such that systems relating to engine start and alike cannot be performed until the problem is rectified. This process can be seen further in Table 1 and Table 2. Table 1 shows the steps performed by the database script using the FASTRAC MASTER database as an example. Table 2 shows the steps performed by the system software to compare the 32-bit CRC values of participating ECUs and the associated actions R#001 The _FASTRAC_MASTER_.dbc file shall be used to define all CAN communications on the Fastrac network R#002 A script shall be written in Qt(C++) to convert the FASTRAC MASTER.dbc file into C/C++ code R#003 The script shall also parse a spreadsheet which will list the messages of interest to the application as defined by the user (as the display/MECU does not listen to all messages on the CANbus).

R#004 The script shall then output the CAN message structure, encoder/decoder, and any other associated information (e.g signal scaling, Enumeration values, range information) into a.cpp file for the display/MECU/FECU applications R#005 The script shall also generate a 32bit CRC from the FASTRAC MASTER.dbc file R#006 The 32bit CRC shall be copied into the display/MECU/FECU application.

R#007 The display application shall send the generated 32bit CRC value to the MECU in the Control Configuration message and HTA sequence message (OxEFOO MUX 2 and 3) R#008 The MECU shall decode OxEFOO MUX 2 and 3 and validate that the CRC is correct R#009 The MECU shall discard any communications and raise an alarm if the 32 bit CRC is invalid.

R#010 The MECU shall disable all primary systems if the 32 bit CRC is invalid.

R#011 The MECU application shall send the generated 32bit CRC value to the display in PGN OxEFOO MUX 5 Once the display has booted, it shall validate the CRC sent by the R#012 MECU at startup before loading in any user stored data The display shall discard any communications and raise an alarm if R#013 the 32 bit CRC is invalid.

In other words, a plurality of data which define all the CAN communications in the vehicle network such as all the different functions and control systems of the working vehicle are stored within a central database which could be an external server. The central database is processed using the script as discussed above. This script parses the CAN message database file and its associated data to convert it into code such as C/C++ code.

The script will preferably further process this data in order to find messages of interest e.g., messages that a certain ECU would require, or messages that relate to configuration information. This process is completely autonomous by the script/code and thus there is no chance of human error being added to the contents of the external database during processing and programming. The automation of the process also helps ensure that the output of the script, the CAN message, is in a consistent format.

As the process utilises a CAN message check value or checksum to validate the data the creation of the messages in a consistent format aide this process. The script will then output the CAN message structure, encoder/decoder function information and information such as signal scaling, enumeration values, ranger information. A further checksum or 32-bit CRC value is generated by the script for all the data within the external database.

The generated outputs and CAN message database checksum/32-bit CRC value are sent to the display and other ECUs such as the MECU. The Display ECU, for example, which receives the generated outputs and CAN message database checksum/32bit CRC value will decode the message in order to access the generated outputs and checksum/32-bit CRC of the external database. The Display ECU, or node, will complete similar processing on the CAN message database or Display ECU/node database and generate a CAN message and CAN message check value or checksum/32-bit CRC value in relation to the configuration data received at the Display ECU or node. It is worth noting, that the first external database and second node database are separate, however, the second database may be used at multiple nodes. The CAN message, CAN message check value and CAN message database check value will then be transmitted to the second node for example the MECU. The MECU will generate a second CAN message check value, based on the CAN message received from the Display or first node. The first and second CAN message checksum or 32-bit CRC values and the CAN message database check values received from the central server and the first node should be identical in order to show that both the databases are the same, the CAN message layouts are consistent and the systems of the working machine are aligned. Thus, ensuring inconsistencies in the programming process do not occur or are highlighted before they result in incompatibilities between nodes, or unintended functionality of the To check for alignment, the CAN message check value or checksum value or 32-bit CRC values calculated from the first node and the second node are compared. The CAN message database check values received at the second node from the first node and the central server are also compared. If the CAN message check values/CAN message database check values or checksums/32-bit CRC values match, then the systems are aligned and working off the same version of the CAN message database with the correct CAN message layout. If the CAN message check values/CAN message database check values or checksums/32-bit CRC values do not match then the systems are misaligned and a fault signal will be raised, in turn causing alarms, suspension of primary functions etc. As noted above, conventional working machines include machine controllers for controlling the various functional devices on the working machine. The controllers maybe configurable to allow control of, for example: power take-offs; propulsive devices (e.g. for driving and steering); external cameras; GPS information; cab environmental controls including remote operation of a mobile phone, radio, air conditioning, lighting; displaying of vehicle data; etc, and can include the capacity to programme sequences of events for use with the work machine generally or a trailed implements when carrying out repetitive tasks, for example. These machine controllers can include programmable joysticks of various types, buttons, levers, toggle switches and tough screen displays. Touch screen displays may be additionally be used for configuring the different machine controllers. It may also be possible to load user profiles so the work machine and controllers can be automatically configured when a user enters the cab to start work.

If we consider a machine controller, for example, a programmable joystick feature which is present in the working machine, the programmable joystick feature can comprise of a plurality of programmable buttons, levers, toggles etc. These programmable buttons, levers, toggles, etc can be programmed to assign a plurality of different functions of the working machine to that button. This feature allows the user to assign multiple different functions to any number of programmable buttons. The data regarding the functions assigned to the programmable buttons is stored in the display and sent to the MECU at start-up of the working machine to enable the systems. The data is defined in two separate enumerations -buttons and functions. Hence, the problem arises of data misalignment between the two different enumerations of the MECU and display. This misalignment could occur where multiple parties are involved in the programming process and inconsistencies may occur resulting in incompatibilities between nodes, or unintended functionality. As new functions are added to the software, or more parties are involved in the programming of the vehicle, the possibility of a misalignment or incompatibility increases. The misalignment could occur due to one team entering the data incorrectly in the code or using the wrong version of the CAN message database, for example. If the data becomes misaligned, then the user could be at risk of activating a function that they were not expecting to be activated by using that programmable button on the programmable joystick. Thus, it becomes important to control and mitigate against misalignment, and if misalignment does occur to be able to recognise it and warn the user/stop the working machine. The use of the CAN message database processing and the independent generation of CAN message and CAN message database CRC values at differing ECUs, such as the display and the MECU, ensures the system can spot when misalignment has occurred. In this scenario, this may be a function programmed to one of the joystick buttons that has been updated by one team offline and has not been synced with the overall system. In this case, the CAN message/CAN message database check values or CRC values from the display, MECU and central server would differ and thus the system would alarm and prevent the primary systems from operating. This will remain the case until it can be confirmed that all participated ECUs are operating with the correct revision.

Although the teachings have been described above with reference to one or more preferred embodiments, it will be appreciated that various changes or modifications may be made without departing from the scope as defined in the appended claims.

For example, the teachings may be applied to enhancing the reliability and reducing the likelihood of system incompatibilities and preventing unexpected functionality in other vehicles or systems and the like which may also be affected by changes in control configuration information.

Claims

Claims 1. A method of configuring a plurality of functional devices or nodes in a working machine, the method comprising: receiving, at a first node and a second node of a working machine, a CAN message database, wherein the CAN message database comprises identification information and configuration information for the functional devices, and a CAN message database check value based on data in the CAN message database; generating, at the first node, a CAN message for the second node, the CAN message comprising information indicative of a desired configuration of one or more of the plurality of functional devices and generating a first CAN message check value, based on data within the CAN message; transmitting the CAN message, the first CAN message check value and the CAN message database check value to the second node; receiving the CAN message, CAN message check value and CAN message database check value at the second node and generating a second CAN message check value from the received CAN message; comparing the first and second CAN message check values; and, comparing the CAN message database check values received directly at the second node and received via the first node; and if there is a difference in the first and second CAN message check values or the CAN message database check values generating a fault signal; or if there is no difference in the first and second CAN message check values and no difference in the CAN message database check values, implementing the desired configuration in the second node.
2. The method of claim 1, wherein the CAN message database check value, received at the first node, is transmitted from the first node to the second node separately from the CAN message.
3. The method of any preceding claim, wherein the CAN message database check value is transmitted from the first node when the first node and second node are powered-on.
4. The method of claim 3, wherein the comparison of the CAN message database check values is carried out when the first and second nodes are powered-on at working machine start-up.
5. The method of any preceding claim, wherein the CAN message database and CAN message database check value is received from a server.
6. The method of any preceding claim, wherein the CAN message check value and CAN message database check value comprises a checksum or a CRC. 10
7. The method of any preceding claim wherein the transmitting of the CAN message, the first CAN message check value and the CAN message database check value to the second node follows an operator configuring a machine controller, and, wherein, the operator configures the controller using a display, and/or wherein, optionally, the controller is a joystick.
8. The method of any preceding claims, wherein the CAN messages are controlled by a CAN bus, wherein the fault signal causes the CAN bus to disable one or more nodes and/or causes the CAN bus to issue a shutdown signal.
9. The method of any preceding claims, wherein in response to the fault signal reverting to a default state and/or reverting to a previous state where the first and second CAN message check value and the first and second CAN message database check value matched.
10.The method of any preceding claims, wherein if the first and second CAN message check values and the first and second CAN message database check value match starting the working machine.
11.The method of any preceding claims, wherein the first and second nodes are electronic control units of the working machine.
12.The method of any preceding claims, wherein the first and second nodes are displays of the working machine.
13.The method of claim 1, wherein the method further comprises comparing a received CAN message to a threshold length, and if the received CAN message length is outside a threshold range generating a fault signal.
14. The method of claim 1, wherein the CAN message is generated by parsing the CAN message database to identify an attribute identification information and configuration information for the attribute and extracting the identified information as configuration information.
15.The method of any preceding claims, wherein the CAN message, for the second node, is generated by parsing the CAN message database containing the plurality of CAN messages from one or more nodes in the working machine.
16.The method of any preceding claims, wherein the CAN message consists of one or more of the following data values: a CAN message layout; encoder/decoder identification; signal scaling value; enumeration value; and range information.
17.A system of functional devices or nodes in a working machine, the system comprising: a first and second node; the first and second nodes being configured to complete the method steps as in claims 1 to 16.
18.A method of configuring a device for use with a working machine comprising a plurality of functional devices or nodes, the method comprising: updating a CAN message database, on a server, wherein the CAN message database comprises identification information and configuration information for the functional devices or nodes; executing, a script to convert one or more entries in the CAN message database, into a format for use by the functional device or node; generating a CAN message database check value based on the processed CAN message database; and transmitting the CAN message database and CAN message database check value to a first and second node of the working machine.
19.The method of claim 18, wherein the CAN message database check value comprises a checksum or a CRC.
20.The method of any of claims 18 to 19, wherein the first and second nodes of the working machine are electronic control units and/or displays.
21.The method of any of claims 18 to 20, wherein the script converts the one or more entries in the CAN message database into an executable code.
22.The method of any of claims 18 to 21, wherein the script converts the one or more entries in the CAN message database by parsing the one or more entries in the CAN message database to create one or more outputs.
23.The method of claim 22, wherein the outputs are one or more of the following data values: a CAN message layout; encoder/decoder identification; signal scaling value; enumeration value; and range information.
24.A device for use with a working machine comprising a plurality of functional devices or nodes, the device comprising: a server, wherein the server is in communication with a CAN Bus network of the working machine; the server being configured to complete the method steps as in claims 18 to 23.