Automotive Embedded System Timing

Abstract

The present disclosure relates to automotive embedded system timing, including systems and methods for improving vehicle functionality. Systems and methods are provided that provide a customization tool that automatically generates a set of software agents that allow the system to separate the processing, transmission, and reception of messages for better synchronization. The disclosure herein also provides a simplified method for key configuration by designating one client as a server and assigning a symmetric key to each other client permanently established between the client and the server. Systems and methods for predicting faults in a vehicle are also provided. Systems and methods for retaining data in the event of a system crash are also provided. Systems and methods are also provided in which the operating system of the vehicle detects the presence of a new peripheral device and pulls the relevant interface file for the new peripheral device. Additionally, a data synchronization solution is provided herein that provides an optimized level of synchronization.

Description

[0001] Cross - Reference to Related Applications

[0002] This disclosure claims the benefit of U.S. Provisional Application No. 63 / 240,190, filed Sep. 2, 2021, the entire disclosure of which is incorporated herein by reference. SUMMARY OF THE INVENTION

[0003] This disclosure relates to systems and methods for improving vehicle functionality.

[0004] Typical vehicles include systems that perform functions that need to be synchronized. In many such systems, some tasks have priorities that allow preemption of other tasks, thus pausing the first task to support another task. Some typical vehicle systems also run end - to - end checks and unpacking of data. In these tasks, signal data and end - to - end result data must be synchronized to ensure that the end - to - end results correspond to the correct data. However, if a second task preempts the end - to - end check, the data will not correctly correspond. Data mismatches can lead to problems that require additional cycles to fix and may even cause system crashes. Accordingly, a system for ensuring synchronization between tasks is needed. According to the present disclosure, systems and methods are provided that provide custom tools that automatically generate a set of software agents that allow the system to separate the handling, transmission, and reception of messages for better synchronization. In some embodiments, a pre - selected text - based descriptor file format (e.g., a DBC file in a special format) is used to describe the vehicle's network through multiple file segments for each bus. The descriptor file format may require a certain style of annotation or stub sections that provide the required information but are not executed. In another specific implementation, the descriptor file format may require data to be provided in a specific order and using specific tags (e.g., using predefined variable names). In some embodiments, the code - automatic - generation software knows the file format and can add signals that will compile without problems or additional processing.

[0005] Some embodiments include a method that includes: accessing a file that includes information for decoding bus data; generating a plurality of software agents based on the file, where the software agents are configured, when executed, to receive a raw message via a bus, unpack the raw message to generate signal values, and generate a security protection value for the raw message; and providing synchronized access to the signal values and the security protection values in response to a request for the signal values from an instance of an application executing based on instructions in a protected memory location. In some embodiments, generating the plurality of software agents includes: generating a first instruction set for execution from a first unsecure memory partition, where the first instruction set is configured, when executed, to receive a raw message from the bus; generating a second instruction set for execution from a protected memory partition, where the second instruction set is configured, when executed, to unpack the raw message to generate signal values, perform verification to generate a security protection value for the raw message, store the signal values and the security protection values, and synchronously transmit the signal values and the security protection values to an instance of the application; generating a third instruction set for execution from a second unsecure memory partition, where the third instruction set is configured, when executed, to unpack the raw message to generate signal values and transmit the signal values to an instance of the application. In some embodiments, the bus is a Controller Area Network (CAN) bus. In some embodiments, the file is a Database (DBC) file that includes instructions for decoding CAN bus data from at least one sensor. In some embodiments, the first unsecure memory partition is a Quality Management (QM) partition. In some embodiments, the protected memory partition is an Automotive Safety Integrity Level (ASIL) partition. In some embodiments, generating the security protection value includes generating an end-to-end (E2E) status.

[0006] Some embodiments include a non-transitory computer-readable medium having instructions encoded thereon that, when executed by a control circuit, cause the control circuit to: access a file that includes information for decoding bus data; generate a plurality of software agents based on the file, wherein the software agents, when executed, are configured to receive a raw message via a bus, unpack the raw message to generate signal values, generate a security protection value for the raw message; and in response to a request for the signal values from an instance of an application executing based on instructions in a protected memory location, provide synchronized access to the signal values and the security protection value. In some embodiments, the control circuit causes the plurality of software agents to be generated by: generating a first instruction set for execution from a first unsecure memory partition, wherein the first instruction set, when executed, is configured to receive a raw message from the bus; generating a second instruction set for execution from a protected memory partition, wherein the second instruction set, when executed, is configured to unpack the raw message to generate signal values, perform verification to generate a security protection value for the raw message, store the signal values and the security protection value, and synchronously transmit the signal values and the security protection value to an instance of the application; generating a third instruction set for execution from a second unsecure memory partition, wherein the third instruction set, when executed, is configured to unpack the raw message to generate signal values and transmit the signal values to an instance of the application. In some embodiments, the bus is a Controller Area Network (CAN) bus. In some embodiments, the file is a Database (DBC) file that includes instructions for decoding CAN bus data from at least one sensor. In some embodiments, the first unsecure memory partition is a Quality Management (QM) partition. In some embodiments, the protected memory partition is an Automotive Safety Integrity Level (ASIL) partition. In some embodiments, generating the security protection value includes generating an end-to-end (E2E) status.

[0007] Some embodiments include a vehicle system that includes: a sensor connected to at least one bus; and a control circuit configured to access a file that includes information for decoding bus data received from the sensor via the bus, and generate a plurality of software agents based on the file, wherein the software agents, when executed, are configured to receive a raw message via the bus, unpack the raw message to generate signal values, generate a security protection value for the raw message, and in response to a request for the signal values from an instance of an application executing based on instructions in a protected memory location, provide synchronized access to the signal values and the security protection value. In some embodiments, the control circuit is configured to generate the plurality of software agents by:

[0008] Generate a first instruction set for execution from a first insecure memory partition, where the first instruction set is configured to receive a raw message from a bus when executed; generate a second instruction set for execution from a protected memory partition, where the second instruction set is configured to unpack the raw message to generate a signal value when executed, perform verification to generate a security protection value for the raw message, store the signal value and the security protection value, and synchronously transmit the signal value and the security protection value to an instance of an application; generate a third instruction set for execution from a second insecure memory partition, where the third instruction set is configured to unpack the raw message to generate a signal value when executed and transmit the signal value to an instance of the application. In some embodiments, the bus is a Controller Area Network (CAN) bus. In some embodiments, the file is a Database (DBC) file that includes instructions for decoding CAN bus data from at least one sensor. In some embodiments, the first insecure memory partition is a Quality Management (QM) partition. In some embodiments, the protected memory partition is an Automotive Safety Integrity Level (ASIL) partition.

[0009] Typical vehicle systems include hardware or software modules that may need to exchange one or more cryptographic keys (e.g., ephemeral keys) to encrypt messages sent between each other. Existing systems are cumbersome, with each module requiring many keys and certificates to provide a private key or a public key for each security transaction. An improved, simplified key setup method is needed. The present disclosure provides such a method by designating one client as a server and assigning a symmetric key to each other client permanently set up between the client and the server. This symmetric key minimizes the need for permanent keys and can be used to leverage ephemeral keys. In some embodiments, during the exchange, one client can initiate communication with a second client. In some embodiments, the second client can then request an ephemeral key from the server, which is created for this transaction. The server can also verify that the first client did indeed request communication. The server can respond to client 2 using the ephemeral key. In some embodiments, client 1 and client 2 now have a shared key and can communicate securely. This method reduces the number of keys required and simplifies secure communication.

[0010] Some embodiments include a method for establishing secure communication between a first node and a second node within a vehicle, the method comprising the steps of:

[0011] Receive a first message from a first node of a vehicle, the first message including information identifying a second node of the vehicle; in response to receiving the first message, generate an encryption key using a processing circuit of the vehicle; transmit information identifying the encryption key to the first node of the vehicle; receive a second message from a second node of the vehicle, the second message including information identifying the first node of the vehicle; determine, using the processing circuit, that the second message is valid based on the first message; and transmit information identifying the encryption key to the second node of the vehicle. In some embodiments, the first message further includes a random number generated by the first node of the vehicle. Some embodiments include transmitting a hash of the random number to the first node of the vehicle. In some embodiments, the second message further includes a random number generated by the second node. Some embodiments include transmitting a hash of the random number to the first node of the vehicle. In some embodiments, the first node of the vehicle and the second node of the vehicle are located on a shared bus in the vehicle. In some embodiments, the transmission to the first node of the vehicle and the transmission to the second node of the vehicle are accomplished via the shared bus.

[0012] Some embodiments include a system for establishing secure communication between a first node and a second node within a vehicle, the system including: a first message from a first node of the vehicle, the first message including information identifying a second node of the vehicle; a second message from a second node of the vehicle, the second message including information identifying the first node of the vehicle, wherein the second message is determined to be valid based on the first message; and an encryption key, wherein the encryption key is identified to the first node and the second node. In some embodiments, the first message further includes a random number generated by the first node of the vehicle. Some embodiments include a hash of the random number, wherein the hash is transmitted to the first node of the vehicle. In some embodiments, the second message further includes a random number generated by the second node. Some embodiments include a hash of the random number, wherein the hash is transmitted to the first node of the vehicle. In some embodiments, the first node of the vehicle and the second node of the vehicle are located on a shared bus in the vehicle. In some embodiments, the encryption key is identified to the first node and the second node via communication on the shared bus.

[0013] Some embodiments include a non-transitory computer-readable medium having non-transitory computer-readable instructions encoded thereon that, when executed by a processor, cause the processor to: receive, from a first node of a vehicle, a first message including information identifying a second node of the vehicle; in response to receiving the first message, generate an encryption key using a processing circuit of the vehicle; transmit information identifying the encryption key to the first node of the vehicle; receive a second message from a second node of the vehicle, the second message including information identifying the first node of the vehicle;

[0014] Use a processing circuit to determine that a second message is valid based on a first message; and transmit information identifying an encryption key to a second node of the vehicle. In some embodiments, the first message further includes a random number generated by a first node of the vehicle. Some embodiments include transmitting a hash of the random number to the first node of the vehicle. In some embodiments, the second message further includes a random number generated by the second node. In some embodiments, the first node of the vehicle and the second node of the vehicle are located on a shared bus in the vehicle. In some embodiments, the transmission to the first node of the vehicle and the transmission to the second node of the vehicle are completed via the shared bus.

[0015] Throughout the life of a vehicle, malfunctions will be encountered. Malfunctions in a vehicle not only cause inconvenience, such as affecting the vehicle's performance, but may also endanger the safety of the vehicle, thus creating hazards. They may also lead to other malfunctions with additional problems. Given these complexities, it is advantageous to detect malfunctions as quickly as possible in order to address them before dangerous or costly complications arise. Specifically, a system that predicts malfunctions before they occur is needed. According to the present disclosure, systems and methods for predicting malfunctions in a vehicle are provided. In some embodiments, the system includes a fleet of vehicles where all vehicles are connected to a server. The server can receive data regarding the measurements and conditions of the vehicles from multiple vehicles in the fleet. The server can also analyze the received measurements and determine the frequency at which specific problems occur. The server can store this information and continue to monitor the vehicles. Another vehicle can report measurements that are similar to or have a shown correlation with a specific problem, and the server can provide early failure detection to that vehicle. In some embodiments, the server can transmit an early warning to the vehicle, urging repair or other action. In this way, the present disclosure provides a means for predicting malfunctions and mitigating the damage they may cause.

[0016] Some embodiments include a method for predicting a fault event in a vehicle, the method comprising: monitoring, using a processing circuit, a plurality of operating parameters of the vehicle and the geographical location of the vehicle; using the processing circuit to determine, based on a model trained using the corresponding values of the operating parameters for a set of vehicles and the corresponding geographical locations of the set of vehicles that have experienced corresponding fault events, that the values of the operating parameters and the geographical location may be related to a fault event; and using the processing circuit to cause an action to be performed in response to the determination. Some embodiments further include transmitting the operating parameters and the geographical location of the vehicle to a remote server, wherein determining that the values of the operating parameters and the geographical location may be related to a fault event includes receiving information indicating the correlation from the remote server. In some embodiments, the model is located at the remote server. In some embodiments, causing the action to be performed includes causing a notification indicating the fault event to be provided. In some embodiments, causing the action to be performed includes causing at least one of the plurality of operating parameters to be changed to avoid the occurrence of a fault event. In some embodiments, causing the action to be performed includes causing an action to be performed at the remote server, wherein the action is performed within the vehicle. In some embodiments, the model is repeatedly updated based on new data provided by the set of vehicles.

[0017] Some embodiments include a system for predicting a fault event in a vehicle, the system comprising: a plurality of operating parameters of the vehicle, the geographical location of the vehicle, a model trained using the corresponding values of the operating parameters for a set of vehicles and the corresponding geographical locations of the set of vehicles that have experienced corresponding fault events, the values of the operating parameters and the geographical location being determined to be possibly related to a fault event, wherein based on the model and the action performed in response to the determination, the values of the operating parameters and the geographical location are determined to be possibly related to a fault event. Some embodiments include providing information indicating the correlation of the operating parameters and the geographical location of the vehicle with a fault event. In some embodiments, the model is located at the remote server. Some embodiments include a notification indicating a fault event. In some embodiments, the action includes changing at least one of the plurality of operating parameters to avoid the occurrence of a fault event. In some embodiments, the action is performed by the remote server, and wherein the action is performed within the vehicle. In some embodiments, the model is repeatedly updated based on new data provided by the set of vehicles.

[0018] Some embodiments include a non-transitory computer-readable medium having non-transitory computer-readable instructions encoded thereon that, when executed by a processor, cause the processor to: monitor a plurality of operating parameters of a vehicle and a geographical location of the vehicle using a processing circuit; determine, using the processing circuit, that a value of an operating parameter and a geographical location may be associated with a fault event based on a model trained using corresponding values of the operating parameters for a set of vehicles and corresponding geographical locations of the set of vehicles that have experienced corresponding fault events; and cause, using the processing circuit, an action to be performed in response to the determination. Some embodiments include transmitting the operating parameters and geographical location of the vehicle to a remote server, wherein determining that a value of an operating parameter and a geographical location may be associated with a fault event includes receiving information indicating the association from the remote server. In some embodiments, the model is located at the remote server. In some embodiments, causing the action to be performed includes causing a notification indicating the fault event to be provided. In some embodiments, causing the action to be performed includes causing at least one of the plurality of operating parameters to be changed to avoid a fault event from occurring. In some embodiments, causing the action to be performed includes causing an action to be performed at the remote server, wherein the action is performed within the vehicle. In some embodiments, the model is repeatedly updated based on new data provided by the set of vehicles.

[0019] System crashes are a common problem in vehicle systems. For example, the system may become unresponsive. In these cases, the system is at risk of losing data because some information may be irreparable or unrecoverable. Data loss can result in functions not operating properly or information not being recorded correctly, both of which can lead to various problems. Accordingly, a system for preserving data is needed. In accordance with the present disclosure, systems and methods for preserving data in the event of a system crash are provided. In some embodiments, the system includes a backup memory. In some embodiments, the system can acquire one or more snapshots of system information and save them in the backup memory. In some embodiments, the memory is not cleared between startups. In this way, the disclosed system provides a means for preserving data in the event of a crash.

[0020] Some embodiments include a method for storing information about a vehicle, the method comprising: detecting, by a processing circuit, a fault event; and in response to the detection: generating, by the processing circuit, information about the vehicle at the time of the fault event; generating, by the processing circuit, integrity data based on the information; causing, by the processing circuit, the information about the vehicle and the integrity data to be stored in a portion of volatile memory, wherein the portion of the volatile memory is configured to retain the stored data during a restart of the vehicle's operating system; causing, using the processing circuit, a restart of the vehicle's operating system; after the restart, verifying, using the processing circuit, the information stored in the volatile memory based on the integrity data; and in response to the verification, causing the information about the vehicle to be stored in non-volatile memory. In some embodiments, the integrity data includes a cyclic redundancy check (CRC). In some embodiments, the volatile memory includes random access memory (RAM). In some embodiments, the portion of the volatile memory is a dedicated portion of the volatile memory reserved for the information and the integrity data. In some embodiments, detecting the fault event includes detecting a system crash. In some embodiments, the information includes a snapshot of the software state in the vehicle. In some embodiments, generating the information, generating the integrity data, and causing the storage of the information and the integrity data are performed by an emergency stack, which is programmed to execute in the event of a fault event. Some embodiments include a system for storing information about a vehicle, the system comprising: an operating system of the vehicle; a fault event; information about the vehicle at the time of the fault event; integrity data generated based on the information about the vehicle at the time of the fault event; a portion of volatile memory, which is configured to retain the stored data during a restart of the vehicle's operating system, wherein the information about the vehicle and the integrity data are stored in the portion of the volatile memory in response to the fault event;

[0021] non-volatile memory, wherein in response to a restart of the vehicle's operating system, the information about the vehicle is verified based on the integrity data, and wherein in response to the verification, the information about the vehicle is stored in the non-volatile memory. In some embodiments, the integrity data includes a cyclic redundancy check (CRC). In some embodiments, the volatile memory includes random access memory (RAM). In some embodiments, the portion of the volatile memory is a dedicated portion of the volatile memory reserved for the information and the integrity data. In some embodiments, detecting the fault event includes detecting a system crash. In some embodiments, the information includes a snapshot of the software state in the vehicle. Some embodiments include an emergency stack, which is programmed to generate the information, generate the integrity data, and cause the storage of the information and the integrity data in the event of a fault event.

[0022] Some embodiments include a non-transitory computer-readable medium having non-transitory computer-readable instructions encoded thereon that, when executed by a processor, cause the processor to: detect a fault event by a processing circuit; and in response to the detection: generate information about a vehicle by the processing circuit when the fault event occurs; generate integrity data by the processing circuit based on the information; cause the processing circuit to store the information about the vehicle and the integrity data in a portion of volatile memory, wherein the portion of the volatile memory is configured to retain the stored data during a restart of an operating system of the vehicle; use the processing circuit to cause a restart of the operating system of the vehicle; after the restart, use the processing circuit to verify the information stored in the volatile memory based on the integrity data; and in response to the verification, cause the information about the vehicle to be stored in non-volatile memory. In some embodiments, the integrity data includes a cyclic redundancy check (CRC). In some embodiments, the volatile memory includes random access memory (RAM). In some embodiments, the portion of the volatile memory is a dedicated portion of the volatile memory reserved for the information and the integrity data. In some embodiments, detecting the fault event includes detecting a system crash. In some embodiments, the information includes a snapshot of a software state in the vehicle.

[0023] Typical vehicles include peripheral parts such as pump brakes. Many manufacturers offer multiple models of peripheral parts. Generally, interface files are dedicated to handling specific files from specific peripheral devices. If the peripheral hardware changes, the existing interface files cannot communicate with the new peripheral device and new interface hardware is required. This is cumbersome and can cause delays in the system. However, many peripheral devices, regardless of the hardware, share common components. Therefore, it is advantageous to provide a system that is consistent regardless of the peripheral hardware. Specifically, a system that uses the same application code across different hardware is needed. According to the present disclosure, a system is provided in which an operating system of a vehicle detects the presence of a new peripheral device and pulls a relevant interface file for the new peripheral device. In some embodiments, the system provides an abstraction layer between the peripheral files and the application that receives peripheral data. In some embodiments, all software related to the peripheral device may be able to directly or indirectly rely on the abstraction layer, which can translate data from any peripheral device with common functionality. Thus, the peripheral device can now be changed without replacing the existing software.

[0024] Some embodiments include a method for updating a vehicle when installing a new hardware component, the method comprising: detecting the new hardware component using a processing circuit in the vehicle; identifying, using the processing circuit, an association between data generated by the new hardware component and at least one software component of the vehicle; and generating, using the processing circuit, an updated interface for interpreting data from the hardware component, wherein the updated interface converts data provided by the hardware component into abstract information, and wherein the updated interface provides the abstract information to at least one software component of the vehicle. In some embodiments, the data generated by the new hardware component includes a database (DBC) file. Some embodiments include storing the updated interface in an interface library, wherein generating the updated interface includes accessing the updated interface from the library. In some embodiments, the updated interface is selected from the library based on the identification of the new hardware component. Some embodiments include processing the abstract information by at least one software component of the vehicle without regard to the data generated by the new hardware component. In some embodiments, the updated interface is used for two-way communication between at least one software component and the new hardware component. In some embodiments, generating the updated interface includes modifying an existing interface.

[0025] Some embodiments include a system for updating a vehicle when installing a new hardware component, the system comprising: the new hardware component; an association between data generated by the new hardware component and at least one software component of the vehicle; and an interface configured to convert data from the hardware component into abstract information, wherein the interface provides the abstract information to at least one software component of the vehicle. In some embodiments, the data generated by the new hardware component includes a database (DBC) file. Some embodiments include an interface library, wherein the updated interface is stored. Some embodiments include an identification of the new hardware component, wherein the updated interface is selected from the library based on the identification of the new hardware component. In some embodiments, the abstract information is processed by at least one software component of the vehicle without regard to the data generated by the new hardware component. In some embodiments, the updated interface is used for two-way communication between at least one software component and the new hardware component. In some embodiments, the updated interface is a modification of an existing interface.

[0026] Some embodiments include a non-transitory computer-readable medium having non-transitory computer-readable instructions encoded thereon that, when executed by a processor, cause the processor to: detect a new hardware component using processing circuitry in a vehicle; identify an association between data generated by the new hardware component and at least one software component of the vehicle using the processing circuitry; and generate an updated interface for interpreting data from the hardware component using the processing circuitry, wherein the updated interface converts data provided by the hardware component into abstract information and wherein the updated interface provides the abstract information to at least one software component of the vehicle. In some embodiments, the data generated by the new hardware component includes a database (DBC) file. Some embodiments include causing the processor to store the updated interface in an interface library, wherein generating the updated interface includes accessing the updated interface from the library. In some embodiments, the updated interface is selected from the library based on the identification of the new hardware component. Some embodiments include causing the processor to process the abstract information by at least one software component of the vehicle without regard to the data generated by the new hardware component. In some embodiments, the updated interface is used for two-way communication between at least one software component and the new hardware component.

[0027] Key components of a vehicle management system include periodic data transfer. Sometimes, multiple nodes on the same bus must have the ability to transfer data. Additionally, for vehicle functions, some of these transfers must be synchronized. While some nodes may operate in basic or loose synchronization, other nodes require very precise synchronization. However, precise synchronization relies on many messages going back and forth between the client and the server, and precisely synchronizing each node can overload the system, saturating the bus and reducing performance. A hybrid solution that can accommodate both loose and tight synchronization is needed. As described in this disclosure, a hybrid solution is provided herein that offers the advantage of providing tight synchronization when needed and loose synchronization when tight synchronization is not required. As disclosed, the server of the system can continuously transmit its internal time. Then, the receiving node can compare the time it received the message from the server with the server's internal time and calculate the difference. The node can then adjust its internal time to match the server's internal time, thus achieving loose synchronization. For tight synchronization, the node can request precise synchronization and can include its own timestamp in the request. The server can respond with the time it received the request (which reflects any latency between the server and the client) and its response time. The node can calculate the latency between server reception and server transmission, as well as the latency between node transmission and node reception, and subtract these values. The node can also calculate the clock offset by creating an average of the time difference between the node clock and the server clock. The offset value can be used by the node to modify its local clock to closely match the server clock (e.g., by adding the round-trip latency and the clock offset to its internal clock).

[0028] Additionally, in some embodiments, the node can store a history of the calculated clock offset and round-trip latency. If the history indicates a stable pattern, the node can reduce the frequency of its requests for tight synchronization or stop sending requests for tight synchronization and can rely on the historical values to perform synchronization. Advantageously, if two nodes are synchronized with each other, they can use the same message from the server to perform server tight synchronization because their transmission values will be the same.

[0029] Some embodiments include a system for tight synchronization between a first client, a second client, and a time server (each of the first client, the second client, and the time server being associated with a respective local clock), the system comprising: a time server connected to a bus; a first client connected to the bus; a second client connected to the bus, wherein the first client is configured to request tight synchronization with the time server by transmitting a synchronization message on the bus, wherein the time server is configured to generate periodic synchronization messages transmitted on the bus,

[0030] The time server client is configured to adjust a periodic synchronization message based on a tight synchronization request from a first client by adjusting the next periodic synchronization message to include: (a) a first time indicating when the first client transmitted the synchronization message; (b) a second time indicating when the server received the tight synchronization request; and (c) a third time indicating when the time server transmitted the periodic synchronization message. The first client is configured to perform tight synchronization based on the adjusted periodic synchronization message, and the second client is configured to perform loose synchronization based on the adjusted periodic synchronization message. In some embodiments, the first client is further configured to perform tight synchronization based on the content of the adjusted periodic synchronization message and the reception time of the adjusted periodic synchronization message. In some embodiments, the synchronization message includes data indicating the first time. Some embodiments include a memory for storing information about the latency between the time server and the first client. Some embodiments include circuitry for determining a latency pattern and causing synchronization to occur between the first client and the time server based on the pattern.

[0031] Some embodiments include a method for tight synchronization between a first client, a second client, and a time server (each of the first client, the second client, and the time server being associated with a respective local clock and each connected to a bus), the method including: generating, by the time server, a periodic synchronization message to be transmitted over the bus; receiving, at the time server over the bus, a synchronization message including a request for tight synchronization from the first client; in response to receiving the synchronization message, adjusting, by the time server, the periodic synchronization message based on the tight synchronization request by adjusting the next periodic synchronization message to include: (a) a first time indicating when the first client transmitted the synchronization message; (b) a second time indicating when the server received the tight synchronization request; and (c) a third time indicating when the time server transmitted the periodic synchronization message; performing, by the first client, tight synchronization based on the adjusted periodic synchronization message; and performing, by the second client, loose synchronization based on the adjusted periodic synchronization message. Some embodiments include performing tight synchronization based on the content of the adjusted periodic synchronization message and the reception time of the adjusted periodic synchronization message. In some embodiments, the first client, the second client, and the time server are located on a vehicle. In some embodiments, the synchronization message includes data indicating the first time. Some embodiments include storing information about the latency between the time server and the first client in a memory. Some embodiments include causing, by processing circuitry, synchronization to occur between the first client and the time server based on a latency pattern and the pattern.

[0032] Some embodiments include a non-transitory computer-readable medium having non-transitory computer-readable instructions encoded thereon that, when executed by a processor, cause the processor to: generate, by a time server, periodic synchronization messages to be transmitted over a bus; receive, at the time server over the bus, a synchronization message that includes a request for tight synchronization from a first client; in response to receiving the synchronization message, adjust, by the time server, the periodic synchronization messages based on the tight synchronization request by adjusting the next periodic synchronization message to include: (a) a first time that indicates when the first client transmits the synchronization message; (b) a second time that indicates when the server receives the tight synchronization request; and (c) a third time that indicates when the time server transmits the periodic synchronization message; perform tight synchronization by the first client based on the adjusted periodic synchronization message; and perform loose synchronization by a second client based on the adjusted periodic synchronization message. Some embodiments include causing the processor to perform tight synchronization based on the content of the adjusted periodic synchronization message and the reception time of the adjusted periodic synchronization message. In some embodiments, the first client, the second client, and the time server are located on a vehicle. In some embodiments, the synchronization message includes data indicating the first time. Some embodiments include causing the processor to store information about the latency between the time server and the first client in a memory. Some embodiments further include causing the processor to determine a latency pattern and cause synchronization to occur between the first client and the time server based on the pattern.

[0033] Unit testing is an integral part of any software system, including those that operate vehicle components. In a typical vehicle system, software functions can use inputs received from a second function. To ensure results, it is advantageous to use a mock version of the second function that provides these values and test the first function with every possible input from the second function. However, many functions are written in a programming language where providing a mock version of the function requires a separate function. Then, the separate function needs to be tediously replaced in the test environment. A solution is needed to integrate mock functions into the main function for functions written in a language independent of the mock function. According to the disclosure herein, a solution is provided that compiles all functions separately into assembly code, which is stitched together into a super image. During stitching, each sub-image is adjusted to accommodate the fact that they now reside in different address spaces. The images to be compiled are fed into a Mega Image Creation Program (MICP). For each image, the MICP locates the position of the image in memory such that it does not conflict with the memory requirements of other images. Then, for each image, the MICP adjusts the machine instructions therein to reflect the new final address location. Next, as part of the final mega image creation, the MICP creates an entry point table for each sub-image and the unit test framework that enters the mega image, which is a combination of all sub-images. Then, a single file can be flashed onto a drive that can be used for testing and production. In this way, mock functions are provided in the functions for testing, regardless of the programming language used.

[0034] Some embodiments may include a method for function overloading that includes: compiling a first image of a first version of a function; compiling a second image of a second version of the function; and generating a stitched super image by placing the code defining the first version of the function and the code defining the second version of the function into memory partitions, where the code defining the second version of the function is adjusted to not conflict with the code of the first version of the function, and generating a table for selectively calling either the first version of the function and the second version of the function. In some embodiments, the first version and the second version of the function are written in code that does not allow function overloading. In some embodiments, the first version and the second version of the function are written in C code. In some embodiments, the memory partitions are located within a vehicle. In some embodiments, the table defines corresponding memory addresses for each of the first version and the second version of the function. In some embodiments, the first image of the first version of the function includes first assembly code, while the second image of the second version of the function includes second assembly code. Some embodiments further include calling each version of the function in the stitched super image based on the table.

[0035] Some embodiments include a function overloading system that includes:

[0036] A memory partition that includes code defining a first version of a function and code defining a second version of the function, wherein the code defining the second version of the function is adjusted to not conflict with the code of the first version of the function; a table configured to selectively call either the first version of the function or the second version of the function; and a stitched superimage generated from the table and the memory partition. In some embodiments, the first version and the second version of the function are written in code that does not allow function overloading. In some embodiments, the first version and the second version of the function are written in C code. In some embodiments, the memory partition is located within a vehicle. In some embodiments, the table defines corresponding memory addresses for each of the first version and the second version of the function. In some embodiments, a first image of the first version of the function includes first assembly code, and a second image of the second version of the function includes second assembly code. In some embodiments, each version of the function in the stitched superimage is called based on the table.

[0037] Some embodiments include a non-transitory computer-readable medium having non-transitory computer-readable instructions encoded thereon that, when executed by a processor, cause the processor to: compile a first image of a first version of a function; compile a second image of a second version of the function; and generate a stitched superimage by placing the code defining the first version of the function and the code defining the second version of the function into a memory partition, wherein the code defining the second version of the function is adjusted to not conflict with the code of the first version of the function, and generate a table for selectively calling either the first version of the function or the second version of the function. In some embodiments, the first version and the second version of the function are written in code that does not allow function overloading. In some embodiments, the first version and the second version of the function are written in C code. In some embodiments, the memory partition is located within a vehicle. In some embodiments, the table defines corresponding memory addresses for each of the first version and the second version of the function. In some embodiments, a first image of the first version of the function includes first assembly code, and a second image of the second version of the function includes second assembly code. Some embodiments further include causing the processor to call each version of the function in the stitched superimage based on the table. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The above and other objects and advantages of the present disclosure will be apparent from the following detailed description when considered in conjunction with the accompanying drawings, in which like reference characters always refer to like parts, and in which:

[0039] Figure 1 A block diagram showing components of a vehicle according to some embodiments of the present disclosure,

[0040] Figure 2 A block diagram showing a system for operating a vehicle (e.g., from Figure 1 ) according to some embodiments of the present disclosure,

[0041] Figure 3 Showing according to some embodiments of the present disclosure Figure 1 The exemplary architecture of a vehicle,

[0042] FIG. 4a shows an exemplary occurrence of preemption causing a synchronization problem according to some embodiments of the present disclosure,

[0043] FIG. 4b shows an exemplary data flow diagram of a generated software agent according to some embodiments of the present disclosure,

[0044] Figure 5 Showing an exemplary software agent created by a build system for automatically generating software from code according to some embodiments of the present disclosure,

[0045] Figure 6 Showing a replacement version of an exemplary software agent created by a build system for automatically generating software from code according to some embodiments of the present disclosure,

[0046] Figure 7 Showing according to some embodiments of the present disclosure Figure 5 Details of an exemplary implementation of the signal reception check described in

[0047] Figure 8 Showing according to some embodiments of the present disclosure Figure 5 Details of an exemplary implementation of the transmission process described in

[0048] Figure 8 FIG. 4a shows a flowchart of exemplary steps of a method for synchronizing data according to some embodiments of the present disclosure,

[0049] Figure 9 Showing an exemplary key exchange scenario according to some embodiments of the present disclosure,

[0050] Figure 10 Showing an improved key setup protocol based on symmetric keys according to some embodiments of the present disclosure,

[0051] Figure 11 Showing the state machine of a node in an encryption algorithm according to some embodiments of the present disclosure,

[0052] Figure 12Shows the state machine of a key server in an encryption algorithm according to some embodiments of the present disclosure,

[0053] Figure 12 a shows a flowchart of exemplary steps of a method for establishing secure communication between a first node and a second node in a vehicle according to some embodiments of the present disclosure,

[0054] Figure 13 Shows an exemplary system for improving failure detection in a circuit or component of a vehicle according to some embodiments of the present disclosure,

[0055] Figure 13 a shows a flowchart of exemplary steps of a method for predicting a fault event in a vehicle according to some embodiments of the present disclosure,

[0056] Figure 14 Shows an exemplary system for facilitating crash recovery according to some embodiments of the present disclosure,

[0057] Figure 14 a shows a flowchart of exemplary steps of a method for storing information about a vehicle according to some embodiments of the present disclosure,

[0058] Figure 15 Shows an exemplary system for managing the version of a database file of a microcontroller, such as the microcontroller of a vehicle depicted in any of the figures, according to some embodiments of the present disclosure, Figures 1 to 3 in any of the figures,

[0059] Figure 15 a shows a flowchart of exemplary steps of a method for updating a vehicle when installing a new hardware component according to some embodiments of the present disclosure,

[0060] Figure 16 Shows an exemplary system for managing time synchronization of different modules connected via a single bus according to some embodiments of the present disclosure,

[0061] Figure 17 Shows the interaction between a node and a server that requires tight synchronization according to some embodiments of the present disclosure,

[0062] Figure 18 Shows an exemplary interaction showing round-trip delay according to some embodiments of the present disclosure,

[0063] Figure 18 a shows a flowchart of exemplary steps of a method for performing tight synchronization between a first client, a second client, and a time server according to some embodiments of the present disclosure,

[0064] Figure 19Exemplary code of a second unit for testing a first unit according to some embodiments of the present disclosure,

[0065] Figure 20 Exemplary code of a first unit being used in testing according to some embodiments of the present disclosure,

[0066] Figure 21 Exemplary results of creating Figure 19 and Figure 20 a superimage of the code according to some embodiments of the present disclosure,

[0067] Figure 21 a shows a flowchart of exemplary steps of a method for function overloading according to some embodiments of the present disclosure. Detailed Description

[0068] Vehicle Overview

[0069] According to the present disclosure, systems and methods are provided for improving the operation of a vehicle (or multiple vehicles) by making various improvements to the configuration of the hardware and / or software of the vehicle, multiple vehicles, and / or one or more servers configured to communicate with one or more vehicles.

[0070] Figure 1 A block diagram of components of vehicle 100 according to some embodiments of the present disclosure is shown. In some embodiments, vehicle 100 may include any of a variety of suitable systems for controlling and operating the vehicle. For example, vehicle 100 may include one or more engine systems, battery systems, autonomous driving systems, one or more steering systems, pump braking systems, ventilation systems, and other suitable systems or any combination thereof. In some embodiments, the vehicle may include one or more electronic control units (ECUs) or circuits (e.g., microcontrollers) for controlling some or all of the above systems. In some embodiments, the vehicle may include internal connection or network components required to link the vehicle's systems.

[0071] In some embodiments, the vehicle may include one or more processors 105 (e.g., a central processing unit and / or processors dedicated to its subsystems). The processor may include a hardware CPU for executing commands stored in the memory 103 or software modules 112, 113, or a combination thereof. In some embodiments, the vehicle 100 may include one or more transient memory units and / or one or more non-transistor memory units. In some embodiments, the memory 103 may be part of the vehicle circuitry. In some embodiments, the memory 103 may include hardware elements for non-transitory storage of commands or instructions which, when executed by the processor 105, cause the processor 105 to operate the vehicle 100 according to the embodiments described above and below.

[0072] In some embodiments, the processor 105 may be communicatively coupled to sensors 106, 107, networking components, and one or more user interface components. The sensors 106, 107 may include video sensors, audio sensors, gas sensors, pressure sensors, GPS sensors, radio antennas, cameras, microphones, pressure sensors, weight sensors, gas sensors, sensors specific to the vehicle's capabilities, other sensors, or any combination thereof.

[0073] In some embodiments, the processor 105 may use data from the sensors 106, 107 to operate the vehicle 100 and / or perform other functions. In some embodiments, the processor 105 may receive user input via the user interface 102. In some embodiments, the user interface 102 may include a screen. In some embodiments, the processor 105 may communicate with user devices and other data sources via a network, which may be accessed via the networking component 104.

[0074] In some embodiments, vehicle 100 may include a plurality of software modules (e.g., software modules 1-N) 112, 113. In some embodiments, each of the software modules 1-N 112, 113 may be controlled by processor 105. In some embodiments, vehicle 100 may include a plurality of hardware modules (e.g., hardware modules 1-N) 114, 115. In some embodiments, each of the hardware modules 1-N 114, 115 may be controlled by processor 105 or operated by its own processor. In some embodiments, vehicle 100 may include circuitry and software specific to the operating functions of vehicle 100. For example, vehicle 100 may include one or more of an electronic control module (ECM) or an electronic control unit (ECU) 111 for controlling one or more motors of vehicle 100. Each ECM 111 may access various sensors such as: MAP: Manifold Absolute Pressure, IAT: Intake Air Temperature, MAF: Mass Air Flow, CKP: Crankshaft Position, CMP: Camshaft Position, ECT: Engine Coolant Temperature, O2: Oxygen Sensor, TP: Throttle Position, VSS: Vehicle Speed Sensor, Knock Sensor, APP: Accelerator Pedal Position, Refrigerant Sensor, any other suitable sensor or any combination thereof. Vehicle 100 may include a transmission control module (TCM) 108, a vehicle dynamics module (VDM) 109, and a central gateway module (CGM) 110 for one or more transmissions of the vehicle. The vehicle may also include any other suitable hardware or software system.

[0075] Networking Overview

[0076] Figure 2 FIG. shows a block diagram of a system for operating a vehicle (e.g., from Figure 1 ) according to some embodiments of the present disclosure. The system may include a plurality of vehicles, including vehicle 210 (e.g., Figure 1 ) and other vehicles 220 and 230, and a server 250.

[0077] In some embodiments, the system may include a network 240 communicatively interconnecting vehicles 210, 220, 230, and server 250. In some embodiments, network 240 may be the Internet, an intranet, a Bluetooth network, a LAN, a WAN, a Wi-Fi network, any other wired or wireless network, or any combination thereof.

[0078] In some embodiments, each of vehicles 210-230 may include processing circuitry for performing the functions of a vehicle as described in various embodiments of the present disclosure. In some embodiments, each of vehicles 210-230 may include transient and non-transient memories for storing data and instructions required for vehicle operation. In some embodiments, each of vehicles 210-230 may include communication circuitry for communicating with server 250 via network 240. In some embodiments, the processing circuitry of each of vehicles 210-230 may be capable of collecting data from sensors or hardware or software modules (e.g., as shown in Figure 1 ). Vehicles 210-230 may be consumer vehicles, or in some embodiments represent a fleet of commercial vehicles.

[0079] In some embodiments, server 250 may include a single server. In some embodiments, server 250 may include multiple servers distributed across one or more facilities. In some embodiments, server 250 may collect information from vehicles 210-230 via network 240 (e.g., information generated by sensors of vehicles 210-230). In some embodiments, server 250 may send information to vehicles 210-230 via network 240 according to the embodiments described above and below.

[0080] Core Architecture Overview

[0081] Figure 3 depicted Figure 1 exemplary architecture of a vehicle (e.g., one of the processor cores in the vehicle's processor core, such as the core of the ECM). For example, Figure 3 the architecture shown in Figure 1 may be implemented using the processors and memories shown. Although a specific implementation of a single core is shown, a vehicle may include any number of cores connected by a bus or networking elements.

[0082] In some embodiments, the press mechanism may be implemented using microcontroller 301. Microcontroller 301 may access hardware abstraction module 307, operating system kernel 302 (with inter-core communication capabilities), and self-test library 303. Additional security and confidentiality modules may include end-to-end (E2E) protection module 304, monitoring module 305, and redundancy module 306. Some or all of these modules may use shared memory. The core may also execute portions dedicated to performing interval tasks.

[0083] In some embodiments, the architecture includes a controller abstraction layer 308 that can access a Controller Area Network (CAN) 309, Serial Peripheral Interface (SPI) 310, Inter-Integrated Circuit bus (I2C) 311, Universal Asynchronous Receiver-Transmitter (UART) 312, Local Interconnect Network (LIN) 313, and Digital Input / Output (DIO) 314 buses. The microcontroller 301 may also include a chipset driver 315, a bootloader 316, a Controller Area Network Advanced First-In-First-Out (FIFO) queue 317, and an Ethernet component 318. Additional networking modules may also be included (e.g., including a gateway 319 for FreeRTOS communication 320, Unified Diagnostic Services (UDS) communication 321, Universal Measurement and Calibration Protocol (XCP) communication 322, Internet Protocol Diagnostic (DoIp) communication 323, ISO Transport Layer (ISOTP) communication 324, VX1000 communication 325, etc.). The microcontroller 301 may also include an ECU peripheral driver 326, a hardware abstraction module 307, and a diagnostic event manager 327. Then, the kernel 302 can be used to execute application code stored in the memory. In some embodiments, the core architecture may include any other suitable hardware or software modules.

[0084] The core enables the vehicle to access various functions and capabilities, including communication, synchronization, and data collection. For example, the vehicle can transfer information (such as diagnostic or fault codes) between an external test equipment and an automotive control unit (ECU) (using the ECU peripheral driver 326) via DoIP 323. For example, this allows the vehicle system to track and analyze diagnostic information to improve failure detection. The core can also receive files via the Controller Area Network (CAN) bus or the Unified Diagnostic Services (UDS) protocol and send the files to an external system (such as a cloud server). For example, these files may come from peripheral devices (e.g., signals from a pump brake module, from an engine module (such as an ECM), or any other core or peripheral device or sensor of the vehicle), or go to other modules, its own applications, or other cores. This communication enables the function of consolidating data from different parts of the vehicle (i.e., the brake communicating with the display unit, or storing a data snapshot after an ECU failure) or from different systems (i.e., reporting data to an external server).

[0085] In some embodiments, the vehicle (e.g., as Figure 1 depicted) system (e.g., as Figure 3The core shown may be able to receive messages and signals from external modules (e.g., from sensors, other modules of the vehicle such as the TCM or VDM). A DBC file can be used to define the communication method between modules (e.g., the pump brake module, the engine module such as the ECM, or any other core, peripheral device, or sensor of the vehicle). The system of the vehicle (e.g., as shown in Figure 3 the core 300 shown) may also need to transmit data (e.g., transmit data to other modules, to its own applications, or to other cores of other systems).

[0086] In one method, the system includes a separately programmed interface for receiving and interpreting data, and / or an application for transmitting data. In some embodiments, the system can be executed in a real-time operating system (RTOS). In an RTOS, tasks have priorities and are allowed to preempt each other. Due to preemption, one task may suspend its execution while another task with a higher priority is executed. Preemption may lead to data consistency failures.

[0087] Figure 4A An exemplary occurrence of preemption that causes synchronization problems is shown. For example, both Task0_5ms and Task0_100ms can be scheduled to run on the system (e.g., the core) at t = 0 ms. Since task0_5ms has a higher priority, it is allowed to execute first and thus starts execution at time t = 0 ms. When task0_5ms ends (e.g., at t = 2 ms), task0_100ms is allowed to execute on the core (e.g., at t = 2 ms), but task0_100ms may not have enough time until the second call to task0_5ms is needed again (at t = 5 ms). The operating system of the system will "preempt" task0_100ms to support the higher-priority task task0_5ms and run the second instance of task0_5ms until completion (e.g., until t = 7 ms), and then switch back to complete the task0_100ms task (e.g., t = 7 ms). The problem is that this preemption cannot guarantee that the communication between task0_5ms and task0_100ms will be synchronized.

[0088] For example, task0_5ms can be responsible for the end-to-end (E2E) inspection and unpacking of signal data (e.g., data received via the CAN bus). In this example, task0_100ms may need to receive: (a) signal data; and (b) the E2E inspection result of this signal (to be provided by task0_5ms). For example, task0_100ms can call a function during the 2ms - 5ms part of its execution to obtain the signal data, and then call a different function during the 7ms - 8ms part of its execution to obtain the E2E status. However, since the second instance of task0_5ms is executed between the 5ms - 7ms time period, the E2E status received by task0_100ms during the 7ms - 8ms time period will not correspond to the signal data received by task0_100ms during the 2ms - 5ms time period. If task0_100ms runs on a different core from task0_5ms, this problem will become more serious. Data mismatch may lead to programming problems such as out-of-sync during the execution of task0_100ms, which may require additional cycles to remedy and may even cause the system to crash.

[0089] Previous solutions to this problem would perform E2E calculations in the same partition where the application code that requires the data is executed. This provides synchronization of E2E and message data with the code because all information runs in the same context. However, these solutions have drawbacks. On the one hand, it is necessary to synchronize the message data between the context of the communication stack and the above context. This is usually handled by involving the operating system or queues with lower portability and resource intensity. Additionally, if there is code running in other partitions, redundant calculations are required. These solutions also require the code to run synchronously with the incoming data.

[0090] Therefore, a solution to ensure synchronization between tasks is provided. For example, a method to ensure synchronization of E2E data with signal processing and data transmission is provided. Specifically, custom tools (e.g., a set of programming scripts) are provided that automatically generate a set of software agents (e.g., in the C programming language), and this set of software agents allows the system (e.g., including one or more cores) to separate the processing, transmission, and reception of messages to achieve better synchronization. Specifically, the E2E calculation for receiving signals can occur within a single task, while the software architecture of the core and the application (which will receive or send signals and E2E status) performs the necessary actions to ensure synchronous reception of information when needed. This can save CPU cycles on the core (e.g., Figure 3 the core 300 shown)

[0091] Figure 4BExemplary data flow diagrams showing the generated software agents. In some embodiments, each application in a vehicle (e.g., as shown in Figures 1 to 3 ) needs to receive and send thousands of signals. Additionally, some messages need to be routed through many networks to various endpoints in the vehicle system. Some messages need to be verified (e.g., using E2E status). Manually generated code for handling message reception and for E2E verification is error-prone and may incorporate errors into the system. Thus, the systems herein automatically generate code based on DBC data, where the resulting code enables a custom software agent to provide signal and E2E status synchronization. For example, code can be automatically generated for the following tasks: gateway for messages between networks; unpacking / packing of signals between raw bytes and engineering values; handling of end-to-end protection for message / signal integrity; handling of message scheduling; variant management of communication networks; setting of communication-related DTCs (diagnostic trouble codes); enabling / disabling of communication through networks / messages; and any other suitable communication-related tasks.

[0092] In some specific implementations, a preselected text-based descriptor file format (e.g., a DBC file in a special format or other serialized format) is used to describe the vehicle's network through multiple file segments for each bus. For example, the descriptor file format may require a certain style of annotation or stub portions that provide the required information but are not executed. In another specific implementation, the descriptor file format may require data to be provided in a specific order and using specific tags (e.g., using predefined variable names). A DBC file or any other suitable preselected descriptor file format can be used by code automatic generation software that uses the details of the descriptor file format. The code automatic generation software can use segments or fragments of these descriptor files to generate source code. In this way, signals or messages can be transmitted, and it is guaranteed that the code will compile and that the kernel and applications will be able to access the values of the messages or signals through a specified application programming interface (API) without any further work or integration. The code automatic generation software can also handle variant management (e.g., as described later in connection with Figure 15 ). In some embodiments, the code automatic generation software can include a framework for providing automatic message redundancy (e.g., by switching message sources on a temporary basis when there are multiple message sources available). In some embodiments, the code automatic generation software can include a schema for a new file format to replace the DBC file.

[0093] The output of the code auto-generation software can be a set of programming files intended to run on top of and / or with an application in the application stack of a core (e.g., the core of an ECU). The generated programming files, which are composed of one or more programming languages (e.g., C, C++, Javascript, etc.), can be responsible for processing data (e.g., by generating files containing actually usable values), performing E2E verification on signal data, and sending the signal data to other cores or applications. The E2E check module can be configured to verify a single message given the running state of past messages. The E2E library can be written according to the Automotive Open System Architecture (AUTOSAR) specification. The E2E check can provide one of the values of "error", "normal", "duplicate", "no new data", or "error sequence" required to verify a signal message.

[0094] In some examples, the build system of the code auto-generation software can receive a source DBC file (e.g., in the form of fragments including common parts and variants). Then, the build system can use a network framer aggregator to perform variant processing and DBC deserialization. The build system can use predefined network objects (e.g., the network is described by multiple file fragments for each bus) and the provided templates to generate runtime environment objects (e.g., software agents described in more detail below in Figures 5 to 8 . The build system can also create an aggregated DBC file.

[0095] The resulting software agents can provide memory protection and a secure execution environment. For example, all data received from peripheral devices needs to be executed in a secure environment. Additionally, memory protection needs to be active to protect the memory required for critical tasks (e.g., any unqualified processes need to be prohibited from accessing the protected memory). To this end, the memory (e.g., as Figure 1 shown) can be divided into several parts (e.g., defined according to the ISO 26262 standard): a QM memory part, which can be memory of an unprotected unqualified level; and various levels of ASIL parts (e.g., ASIL A-D), where each level of ASIL memory is more protected. The code auto-generation software generates the code further explained in Figures 5 to 8 .

[0096] Figure 5 Illustrates exemplary software agents created by the build system of the code auto-generation software, which, when executed together, automatically provide E2E protection processing for received signals.

[0097] Specifically, the tasks in the upper rectangle are executed by Core 1 (e.g., at the top of the application stack of Core 1). The lower-level tasks are executed by the higher-level application tasks that depend on the signal. As explained above in Figure 4A , the application tasks need to be synchronized with the E2E protection tasks (to avoid the application receiving an E2E status corresponding to an error message). To this end, when a message is received (e.g., from Core 0), the message is read by the E2E task 502 on Core 1 (e.g., using the E2E library 503). Then, the E2E task 502 on Core 1 writes both the signal and the E2E status of the signal in a form that the application can use. Then, the E2E status can be read by software using the ASIL B 504 or ASIL D 505 memory protection levels, while the signal itself can be accessed by software using the ASIL B 504, ASIL D 505, or QM 506 protection levels. Advantageously, all cross-core communications for each E2E message (e.g., as an E2E check) occur at Core 1, which allows for supporting a higher level of memory protection (e.g., at the ASIL D level). Since all E2E calculations occur within one task, the application will also perform the necessary actions to ensure synchronization of the received information when needed.

[0098] Figure 6 Another version of the exemplary software agents created by the build system of the code auto-generation software is shown, which, when executed together, automatically provide E2E protection processing for the received signals. Contrary to the Figure 5 specific implementation, the E2E check is handled by the application. For example, the E2E calculation can be performed in the same context as the code that consumes the calculation but requires the task to run at the same rate as the message.

[0099] Specifically, the task 601 in the upper layer 607 is executed by Core 1 (e.g., at the top of the application stack of Core 1). The tasks in the lower layer 608 are executed by the higher-level application tasks that depend on the signal. To this end, when a message is received (e.g., from Core 0), the message is read by Core 1, and Core 1 writes the message for use by the application. In this specific implementation, software using the ASIL B 602, ASIL D 603, or QM 604 levels or protection can access the message. Then, software using ASIL B 602 and software using ASIL D 603 can both access the E2E library 605 and generate E2E messages (e.g., as an E2E check). In such embodiments, the application can perform an E2E check during each message cycle.

[0100] Figure 7 Shows Figure 5Details of an exemplary specific implementation of the signal reception check described in. The dashed fields represent code created by a build system for code-generated software. As shown, different code agents can reside in the ASIL B 701, ASIL D 702, and QM 703 partitions and can execute together to ensure synchronization between the app task and the Com task (which can correspond to the Figure 4A tasks described in). In this case, the code in the QM partition running the Com task receives messages via the FIFO 704 buffer and writes the signals or messages in a format accessible by the code in the ASIL B 701, ASIL D 702, and QM 703 partitions. The code in the ASIL B partition 701 can unpack the message and write the signal data as well as the E2E status. Then, the application can access both values in a synchronized manner. The code in the ASIL D 702 partition can similarly unpack the message and write the signal data as well as the E2E status. Then, the application can access both values in a synchronized manner. Additionally, the code in the ASIL D 702 can perform security tasks. The code in the QM partition 703 may only make the signal data available to the application, not the E2E data.

[0101] Figure 8 Shows Figure 5 Details of an exemplary specific implementation of the transmission process described in. The dashed fields represent code created by a build system for code-generated software. As shown, different code agents can reside in the ASIL B 801, ASIL D 802, and QM 803 partitions and can execute together to ensure synchronization between the app task and the Com task (which can correspond to the Figure 4A tasks described in). In this case, the code in the QM partition 803 running the Com task writes messages to the FIFO buffer 804 based on signals provided by the code in the ASIL B 801, ASIL D 802, and QM 803 partitions. The code in the ASIL B partition 801 can pack the message by combining the signal data and the E2E status. The code in the ASIL B partition 801 can also pack the message by combining the signal data and the E2E status. Additionally, the code in the ASIL D 802 can perform security tasks. The code in the QM partition can only send the signal data (not the E2E status) to the Com task.

[0102] Some embodiments include as Figure 8The method shown in a), the method comprising: in step 810, accessing a file comprising information for decoding bus data; in step 820, generating a plurality of software agents based on the file, wherein the software agents are configured, when executed, to receive a raw message via a bus, unpack the raw message to generate a signal value, generate a security protection value for the raw message; and if in step 830 a request for the signal value is received from an instance of an application executing based on an instruction in a protected memory location, then in step 840 providing synchronous access to the signal value and the security protection value. If no request is received at step 830, the method moves to step 850 and takes no action. In some embodiments, generating a plurality of software agents comprises: generating a first instruction set for execution from a first unsecure memory partition, wherein the first instruction set is configured, when executed, to receive a raw message from the bus; generating a second instruction set for execution from a protected memory partition, wherein the second instruction set is configured, when executed, to unpack the raw message to generate a signal value, perform verification to generate a security protection value for the raw message, store the signal value and the security protection value, and synchronously transmit the signal value and the security protection value to an instance of the application; generating a third instruction set for execution from a second unsecure memory partition, wherein the third instruction set is configured, when executed, to unpack the raw message to generate a signal value and transmit the signal value to an instance of the application. In some embodiments, the bus is a Controller Area Network (CAN) bus. In some embodiments, the first unsecure memory partition is a Quality Management (QM) partition. In some embodiments, the protected memory partition is an Automotive Safety Integrity Level (ASIL) partition. In some embodiments, generating a security protection value comprises generating an end-to-end (E2E) status.

[0103] In some embodiments, different hardware or software modules may need to exchange one or more cryptographic keys (e.g., ephemeral keys) to encrypt messages sent between each other. For example, the vehicle's TCM, VDM, and CGM (e.g., as Figures 1 to 3 shown) may need to establish secure communication channels between each pair of modules. However, the same techniques can be used between any software or hardware modules that need to exchange keys.

[0104] In one method, each module or node can have its own private key / public key pair for secure communication. However, this can be cumbersome, especially when certificates are required to verify the key source. To overcome this drawback, an exemplary method for an improved key setup process is provided.

[0105] Figure 9Describe an exemplary prior art key exchange scenario. In this example, 4 nodes create pairwise symmetric communication keys (e.g., DEC keys, although any other suitable keys can be used). As described above, pairwise key generation typically requires 6 key exchanges, which is cumbersome. For example, for 20 nodes, 190 key pairs are required. To overcome the problems of these prior methods, a scheme is provided for generating ephemeral symmetric keys between nodes by leveraging a pre-shared key between one node and a server. The technique will be described for any two nodes and a server. In some examples, the CGM can act as the server, and the TCM, VDM can be the nodes. However, any other suitable server and any other suitable nodes can be used. In some embodiments, the process can be repeated for other nodes that need to share the set keys.

[0106] Figure 10 Depicts an improved key setup protocol based on symmetric keys that can be used to set up new symmetric keys between multiple nodes at runtime (or at any other time). The solution allows for the secure setup of new symmetric keys using only a prior symmetric key. The technique protects against eavesdropping and man-in-the-middle attacks. To deploy the solution, one node in the network can be designated as the key server, and the remaining nodes as key clients. As a first step, each client permanently sets a symmetric key between itself and the server. This minimizes the need for permanent keys. For example, for 20 nodes, only 20 keys are needed instead of 190 key pairs. The pre-shared key allows the nodes to communicate with the server node and can also be exploited to create ephemeral keys for encrypting communication between the nodes.

[0107] As Figure 10 shown, Client 1 wishes to create a secure channel with Client 2 by sharing an ephemeral symmetric key. Client 1 requests a symmetric key (e.g., a newly created ephemeral key) 1001 from the key server. In some embodiments, the request includes the address of the target node for channel creation (e.g., the IP address of Client 2) and a random number generated by Client 1 (e.g., a 16-digit number). The random number can be used as a challenge question for the server. For example, when using the key to reply, it is expected that the server retransmits the reply based on that number to help Client 1 verify the server by checking the received challenge response. This message can be sent unencrypted or encrypted using the pre-shared key between Client 1 / server.

[0108] Before the expiration of a certain preset time period, the server can reply to client 1 1002 with a message that includes the newly set key and the response to the challenge. Any suitable key creation technique (e.g., as defined in the IEEE Std 1363-2000 standard) can be used to create the newly set key. The response to the query can be the hash of the random number sent by client 1 (e.g., a password-based message authentication code hash). The message can also be padded to conform to the encryption block size. The entire message can be encrypted using the key pre-shared for the client 1 / server pair (e.g., using a password). In some embodiments, the random number created by client 1 can be used as the initialization vector for the encryption algorithm.

[0109] Then, client 1 can check the hash before proceeding. After the hash check, client 1 can send a message to client 2 to notify client 2 that client 1 wishes to initiate secure communication with client 2 1003. This can be an unencrypted (e.g., User Datagram Protocol (UDP)) message. The message can notify client 2 (e.g., via a bit field) whether the channel requires encryption, authentication, or both. Client 2 now learns that the server has generated a temporary key for this transaction. Client 2 can now send a message to the server to request a copy of the newly set temporary key for itself 1004.

[0110] Client 2 can now send a request for the temporary key to the server 1004. The request can include the address of the desired node (e.g., the IP address of client 1) and a random number generated by client 2 (e.g., a 16-digit number). This message can be sent unencrypted or encrypted using the key pre-shared for the client 2 / server pair.

[0111] The server can verify that client 1 did indeed previously request a channel with client 2 before responding to client 2. The response message 1005 to client 2 can include: (a) the response to the random number challenge (e.g., the hash of the random number generated by client 2); and (b) the same key set at the request of client 1. The message can also be padded to conform to the encryption block size. The entire message can be encrypted using the key pre-shared for the client 2 / server pair (e.g., using a password). In some embodiments, the random number created by client 2 can be used as the initialization vector for the encryption algorithm.

[0112] Client 2 can check the response hash before proceeding 1006. Thereafter, since client 1 and client 2 have the same key, they can use that key for secure communication (e.g., for signing or encrypting messages with each other). In some embodiments, the communication can be performed via normal UDP or Transmission Control Protocol (TCP) messages or any other suitable messages.

[0113] Figure 11 Illustrates the state machine 1100 of the nodes in the algorithm. For example, starting from the "idle" state 1101, a node can send a key request 1102 (e.g., send to the TCM) and wait for a predetermined number of retries. In the initiator mode, when a key reply is received 1103 (and if authentication does not fail), the node can query the peer for a secure connection 1104. If a peer reply is received, the state returns to "idle" 1101, and communication with the peer can begin. In the receive mode, the node will reply to the peer to indicate that the same communication is allowed 1105.

[0114] Figure 12 Illustrates the state machine of the key server in the algorithm. Starting from the "idle" state 1201, the server can receive an initiation request 1202. In response, the server sends a reply 1203 or times out 1204, and returns to the "idle" state 1201.

[0115] Some embodiments include a method for establishing secure communication between a first node and a second node within a vehicle (as shown in Figure 12 a), the method including the following steps:

[0116] Receiving, from a first node of a vehicle, a first message including information identifying a second node of the vehicle 1210; in response to receiving the first message, generating an encryption key using a processing circuit of the vehicle 1220; transmitting, to the first node of the vehicle, information identifying the encryption key 1230; receiving, from a second node of the vehicle, a second message including information identifying the first node of the vehicle 1240; using the processing circuit to determine that the second message is valid based on the first message 1250; and transmitting, to the second node of the vehicle, information identifying the encryption key 1260. In some embodiments, the first message further includes a random number generated by the first node of the vehicle. Some embodiments include transmitting a hash of the random number to the first node of the vehicle. In some embodiments, the second message further includes a random number generated by the second node. Some embodiments include transmitting a hash of the random number to the first node of the vehicle. In some embodiments, the first node of the vehicle and the second node of the vehicle are located on a shared bus in the vehicle. In some embodiments, the transmission to the first node of the vehicle and the transmission to the second node of the vehicle are completed via the shared bus.

[0117] Figure 13 Depicts an exemplary system for improving failure detection in a circuit or component of a vehicle (e.g., Figure 1 the vehicle depicted in), for example, failure detection can be performed by a server 1300 (e.g., as shown in Figure 2Execute as depicted. In some embodiments, the server can access measurement data from multiple vehicles 1301, 1302, 1303, 1304 within a commercial fleet environment, or vehicles 1301, 1302, 1303, 1304 can represent a group of consumer vehicles communicating with a server associated with a vehicle manufacturer. For example, the server can communicate continuously or periodically with each vehicle in the fleet using the server's and the fleet's networking circuitry (e.g., via a cellular network or any other suitable type of network). The server can collect data 1305 from all lines of the vehicles in the fleet. In one example, the server can collect ECU measurement data from all vehicles in the fleet.

[0118] After the server collects ECU measurements from a group of vehicles, the server can store the measurement data in its database. The server can perform a comparative analysis of the measurements with thresholds and determine the frequency of occurrence of a certain problem (e.g., a fault) across the entire fleet and the correlation of that fault with the measurements. By tracking this information, the server may be able to provide early failure detection in the vehicles. In some embodiments, the server can transmit an early warning 1306 to the vehicle, which indicates the fault and urges repair or another appropriate action.

[0119] For example, the server can collect sensor data for each ECU of each vehicle to record motor load, battery state or charging, coolant temperature, motor temperature, motor RPM, air flow, any other suitable metrics, or any combination thereof. Further complex ECU metrics can include current and average processor load, any processor faults, RAM and non-volatile memory utilization (average and current), ECU core temperature (current and average), network load (average and current), available time history, any other suitable processor metrics, or any combination thereof. The server can also collect health information for any component of the motor, such as the age and performance of any part of the motor. The server can also receive software crash or fault reports from each vehicle in the fleet. The server can correlate the occurrence of the crash with the state and metric history of the vehicle at the time of or prior to the crash. This correlation may become stronger as more crash or malfunction reports are received from other vehicles. For example, the aging or poor performance of a particular motor part may be related to an impending failure. In some embodiments, the vehicle can report information to the server in order to both analyze the findings of the correlation and receive a fault warning of the correlation itself. That is, the vehicle can both contribute to system knowledge and benefit from the system itself. When the server determines a correlation (e.g., the correlation exceeds a certain threshold), the server can transmit an impending failure warning to the vehicle whose part condition is related to the failure. In some embodiments, the warning can be sent based on the correlation of any metric or combination of metrics with a particular failure. The warning can include a notification of which part of the vehicle needs repair or replacement. The server can similarly collect and generate data for any other module of the vehicle.

[0120] In some embodiments, the server can utilize a machine learning model (e.g., a neural network) to predict faults. In such embodiments, the server trains the machine learning model with known metric states that cause faults. Once trained, the machine learning model can accept the current metrics of the vehicle (e.g., ECU metrics) as input and output whether an impending failure is likely to occur. If a failure is likely to occur, the server can send an appropriate notification to the vehicle. In some embodiments, the model is repeatedly updated as the server collects new data. In some embodiments, the model is located at a remote server.

[0121] In some embodiments, a notification to a vehicle may indicate an impending failure. In some embodiments, the notification may indicate the range within which the impending failure may occur. This range may be in miles, hours, or any other relevant unit. For example, the server may warn the vehicle that it may overheat within 20 miles based on the detected status of the battery or motor components. In another example, the server may warn the vehicle that the headlights may go out within 12 hours based on the identified status of the lights or other circuits associated with the vehicle. In some embodiments, the notification may describe the relevance. For example, this may indicate that the vehicle has traveled 65,000 miles, suggesting that the motor likely needs maintenance.

[0122] In some embodiments, the notification may include the percentage likelihood that the failure will occur. For example, the server may warn the vehicle that there is a 40% chance of battery failure. In some embodiments, the notification may include an indication of severity, such as a color change or animation on a vehicle display that the driver can see, or the indication may be relayed to a mobile device associated with the user (e.g., a mobile phone on which a mobile application associated with the server is installed). For example, an urgent risk may be displayed as red and flashing, while a minor risk may be displayed as yellow. The severity may be evaluated, for example, based on the likelihood and the potential danger or inconvenience. In some embodiments, the server may cause a change to the vehicle's operating parameters to avoid or mitigate the failure. Such a change may be performed wirelessly on the vehicle by a remote server using software or other updates.

[0123] In some embodiments, the server may receive data from sources other than the vehicle. For example, the server may communicate with systems that provide data such as weather, traffic patterns, vehicle geographical location, altitude, routes, and driver profiles. The server may then incorporate this additional data into the fault correlation analysis. For example, the server may find that a certain fault (such as battery performance) is related to the external temperature. Then, after receiving a weather forecast for the next few hours, the server may warn the vehicle that a fault may occur. For example, in the case where battery performance is related to temperature, the server may learn that the temperature may drop below a threshold at which point the temperature will degrade battery performance. The server may then warn the vehicle of the upcoming change or the likelihood of upcoming performance degradation. Alternatively, the server may find that another fault, for example, is common during frequent stops and may receive information about upcoming traffic. The server may learn that the upcoming traffic may cause frequent stops. In that case, the server may similarly warn the vehicle of a possible failure. In another example, the server may find that vehicles in a certain geographical location have a higher correlation with a specific fault and may issue a warning for the specific fault only to the vehicles in that location. In some embodiments, the server may recommend an action. For example, in a scenario where traffic patterns may increase the risk of failure, the server may communicate to the system a recommended alternative route.

[0124] Some embodiments include a method for predicting fault events in a vehicle (as shown in Figure 13 a), the method comprising, in step 1310, using a processing circuit to monitor a plurality of operating parameters of the vehicle and the geographical location of the vehicle. In step 1320, when it is determined using the processing circuit that the values of the operating parameters and the geographical location may be related to a fault event, wherein the correlation is based on a model trained using the values of the operating parameters for a set of vehicles and the corresponding geographical locations of the set of vehicles that have experienced the corresponding fault events, in step 1330, using the processing circuit to cause an action to be performed in response to the determination. If no correlation is detected, the method moves to step 1340 and no action is taken. Some embodiments also include transmitting the operating parameters and geographical location of the vehicle to a remote server, wherein determining that the values of the operating parameters and the geographical location may be related to a fault event includes receiving information indicating the correlation from the remote server. In some embodiments, the model is located at the remote server. In some embodiments, causing the action to be performed includes causing a notification indicating the fault event to be provided. In some embodiments, causing the action to be performed includes causing at least one of the plurality of operating parameters to be changed to avoid the occurrence of a fault event. In some embodiments, causing the action to be performed includes causing an action to be performed at the remote server, wherein the action is performed within the vehicle. In some embodiments, the model is repeatedly updated based on new data provided by the set of vehicles.

[0125] Figure 14 depicts an exemplary system for facilitating crash recovery (e.g., crash of an ECU) through a vehicle system (e.g., as shown Figure 1 ). For example, the system can handle the situation when the ECU locks up and becomes unresponsive, so the system can prevent data loss after an irrecoverable trap or another module resets the entire core (e.g., as shown Figure 3 ). In these cases, the system avoids a hard power cycle and instead suffers a "soft" or "thermal" crash. Thus, the volatile memory content can be retained.

[0126] As shown Figure 14 , an exemplary system of a vehicle can include a core having a processor 1401, a conventional random access memory (RAM) memory 1402 (labeled "main memory" in Figure 14 ) and a dedicated spare RAM memory 1403 (labeled "spare memory" in Figure 14 ). In some embodiments, the spare RAM memory can be part of a conventional RAM memory. In some embodiments, the spare RAM memory can be a dedicated circuit. The operating system (OS) of the vehicle can include instructions dedicated to low-level faults (e.g., low-level ECU failure), bad code or memory protection failure, or watchdog trigger events. The processor can take a snapshot of the system information and save it in the spare RAM memory. To this end, the system can reserve a portion of the RAM in the linker structure that is not erased between startups.

[0127] In some embodiments, the processor can protect the data by calculating a cyclic redundancy check (CRC) code 1404 for the snapshot block fetched and stored in the spare RAM 1403 after a crash. Thus, after a restart, the CRC check 1404 can be performed to check whether the data is valid. The data can then be reported via a Controller Area Network (CAN) bus or a Unified Diagnostic Services (UDS) protocol. The system can also set a "new" flag in the spare memory to indicate the presence of new data. The crash data in the spare RAM can later be copied to a non-volatile memory and / or an external system (e.g., another core or microcontroller).

[0128] In some embodiments, a non-volatile memory (NVM) can be used to store the snapshot. Thus, the buffer containing the crash information is not erased during subsequent startups but is copied to the non-volatile memory. For example, the core can include an emergency stack for performing additional functions in a locked state. During a crash, the system can set a pointer to the emergency stack and call a new function to take a snapshot. In some embodiments, a stack overflow in the watchdog module can be redirected to a non-maskable interrupt handler.

[0129] In some embodiments, a snapshot may include a stack trace. For example, the system may access a pre-allocated list of unsigned integers 20 deep, each integer holding a jump-back instruction address. In some embodiments, a snapshot may include a software git hash. In some embodiments, a snapshot may include a trap identifier. In some embodiments, a snapshot may include a watchdog state. In some embodiments, a snapshot may include a free-running system timer value. In some embodiments, a snapshot may include any data of interest (stack pointer, status register, timestamp, etc.).

[0130] In some embodiments, when the bootloader starts, a snapshot of the crash data may be dumped to the CAN bus via a heartbeat frame. The bootloader may then operate normally. In some embodiments, the data dump may be recorded by a data logger attached to the bus (e.g., attached to the CAN bus).

[0131] In some embodiments, a snapshot may be a packed binary file that can be obtained using a UD client via a service such as the Unified Diagnostic Services (UDS) protocol. The binary file may include a header file with defined functions. The data can then be unpacked into a human- or system-readable format using a python tool. In some embodiments, the system may acquire snapshots during normal operation (e.g., periodically or based on a system or user request) to provide added management tools. In some embodiments, snapshot data may be collected from an entire fleet and used to predict failures in other vehicles, e.g., as Figure 13 described.

[0132] Some embodiments include a method for storing information about a vehicle (such as Figure 14As shown in FIG. a, the method includes: detecting, by a processing circuit, a fault event 1410; and in response to the detection: generating, by the processing circuit, information 1420 about the vehicle at the time of the fault event; generating, by the processing circuit, integrity data 1430 based on the information; causing, by the processing circuit, the information about the vehicle and the integrity data to be stored in a portion of volatile memory, wherein the portion of the volatile memory is configured to retain the stored data during a restart of the vehicle's operating system 1440; using the processing circuit to cause a restart of the vehicle's operating system 1450; after the restart, using the processing circuit to verify the information stored in the volatile memory based on the integrity data 1460; and in response to the verification, causing the information about the vehicle to be stored in non-volatile memory 1480. In some embodiments, the integrity data includes a cyclic redundancy check (CRC). In some embodiments, the volatile memory includes random access memory (RAM). In some embodiments, the portion of the volatile memory is a dedicated portion of the volatile memory reserved for the information and the integrity data. In some embodiments, detecting the fault event includes detecting a system crash. In some embodiments, the information includes a snapshot of the software state in the vehicle. In some embodiments, generating the information, generating the integrity data, and causing the storage of the information and the integrity data are performed by an emergency stack programmed to execute in the event of a fault event.

[0133] Some embodiments include a system for storing information about a vehicle, the system including: an operating system of the vehicle; a fault event; information about the vehicle at the time of the fault event; integrity data generated based on the information about the vehicle at the time of the fault event; a portion of volatile memory configured to retain the stored data during a restart of the vehicle's operating system, wherein the information about the vehicle and the integrity data are stored in the portion of the volatile memory in response to the fault event;

[0134] non-volatile memory, wherein in response to restarting the vehicle's operating system, the information about the vehicle is verified based on the integrity data, and wherein in response to the verification, the information about the vehicle is stored in the non-volatile memory. In some embodiments, the integrity data includes a cyclic redundancy check (CRC). In some embodiments, the volatile memory includes random access memory (RAM). In some embodiments, the portion of the volatile memory is a dedicated portion of the volatile memory reserved for the information and the integrity data. In some embodiments, detecting the fault event includes detecting a system crash. In some embodiments, the information includes a snapshot of the software state in the vehicle. Some embodiments include an emergency stack programmed to generate the information, generate the integrity data, and cause the storage of the information and the integrity data in the event of a fault event.

[0135] Some embodiments include a non-transitory computer-readable medium having non-transitory computer-readable instructions encoded thereon that, when executed by a processor, cause the processor to: detect a fault event by a processing circuit; and in response to the detection: generate information about a vehicle by the processing circuit when the fault event occurs; generate integrity data by the processing circuit based on the information; cause the processing circuit to store the information about the vehicle and the integrity data in a portion of volatile memory, wherein the portion of the volatile memory is configured to retain the stored data during a restart of the vehicle's operating system; use the processing circuit to cause a restart of the vehicle's operating system; after the restart, use the processing circuit to verify the information stored in the volatile memory based on the integrity data; and in response to the verification, cause the information about the vehicle to be stored in non-volatile memory. In some embodiments, the integrity data includes a cyclic redundancy check (CRC). In some embodiments, the volatile memory includes random access memory (RAM). In some embodiments, the portion of the volatile memory is a dedicated portion of the volatile memory reserved for the information and the integrity data. In some embodiments, detecting the fault event includes detecting a system crash. In some embodiments, the information includes a snapshot of the software state in the vehicle.

[0136] Figure 15 An exemplary system for managing versions of a database (DBC) file for a microcontroller (e.g., the microcontroller of a vehicle depicted in any of the figures Figures 1 to 3 is depicted). The DBC file can be a definition file compliant with the SAE J1939 standard. The DBC file can also be a definition file in a special format, as described in FIGS. 4 through Figure 8 The DBC file can be used to provide data from peripheral devices (e.g., from a pump brake module, an engine module (such as an ECM), or any other peripheral device or sensor of the vehicle) over a controller area network (CAN) bus. DBC typically comes in a form that must be decoded. For example, data from a DBC may be displayed in the format shown in Table 1:

[0137] 0 18FE6900 X 8 9C 27DC 29FF FF F3 23 49.745760 R

[0138] Table 1

[0139] This data can be decoded to receive values of certain defined parameters. For example, a DBC file received from a pump braking system can define a declination angle value. In another example, a DBC file received from an engine system can define values including manifold temperature, revolutions per minute of the motor. The conversion from binary DBC data to available values can be performed by an interface file that accepts data over a CAN or Ethernet bus.

[0140] In one method, a single interface file is dedicated to handling a certain DBC file from a certain peripheral device (e.g., from a pump brake module). However, if physical modifications are made to the pump brake hardware using different pump brakes, this requires a complete replacement of the interface file to handle the new version of the peripheral device. This method cannot take advantage of the commonalities between different versions of the DBC files of the peripheral device, so the common parts of the interface files that can still be used cannot be utilized, and instead, completely new interface files are required, which may result in heavy delays in obtaining and installing the new interface files. In addition, changes in the interface file may also require changes to the entire system, which rely on data from the DBC file interpreter. Therefore, changes to a single peripheral device may require changes to the entire architecture of the vehicle (or another system).

[0141] To overcome the problems of the above method, a specific implementation of a vehicle architecture is provided, which keeps the application code the same on the board of the entire system, while providing different interfaces according to the vehicle type, vehicle architecture, or replacement based on a specific peripheral device. For example, different versions of the vehicle may require different interfaces. In another example, replacing a peripheral device may result in the need for a new version of the DBC interpreter interface. In one example, the vehicle can receive, for example, new pump brake hardware that requires a new interface file.

[0142] In some embodiments, the operating system of the vehicle can detect the presence of a new peripheral device (e.g., a new pump brake) by detecting a build configuration event. Then, the operating system can pull in the new interface file to flash into the vehicle's hardware. For example, the operating system can identify the association between the source file and the vehicle software component (e.g., the association between data from the new pump brake and the application that processes the pump brake input and / or any application that operates using data from the pump brake). Then, the operating system can combine the associated source files in the root directory and generate at least one interface abstraction layer for the vehicle software component (e.g., an ECU that may require pump brake data).

[0143] For example, a pump brake module may provide a DBC file that provides a depression angle value for the brake pedal. However, since different brakes have different "give", other parts of the vehicle (e.g., the ECU or TCM) may process the same angular change in the brake depression angle value in completely different ways. To address this issue, the system can provide an abstraction layer 1506 between the DBC interpretation via the associated interface and the applications executed for other modules in the system. For example, the abstraction layer can provide the system with an "expected speed change" value instead of the raw angle value. For example, for one type of pump brake, a 5-degree change represents an expected decrease of 5 MPH, while for another type of pump brake, a 5-degree change represents an expected decrease of 7 MPH. If all the software associated with the braking action is programmed to rely on the expected speed change metric, an abstraction layer can be provided that converts the DBC data from the pump brake into the expected speed change metric and then provides this data to other applications. In this way, the interface version of the pump brake can be easily changed without any other changes to the rest of the system. Similar abstractions can be used for any other values provided by the DBC file. Thus, the abstract information can be processed without considering the data generated by the new hardware component.

[0144] The update of the interface version can be performed by Figure 15 the system shown. For example, a vehicle may include a Unified Diagnostic Services (UDS) server 1501 that allows external devices to perform UDS operations (e.g., setting runtime controls, retrieving runtime controls, and erasing runtime controls). These operations may be CRC protected. The UDS server enables a computer 1502 (e.g., a computer or a dedicated tester tool) referred to as a UDS client to be connected to the vehicle (e.g., via a UDS interface). The UDS client 1502 can be set up (e.g., via an external network such as the Internet) using the vehicle's encoded runtime configuration file. The encoded runtime configuration file 1503 can be sent to the UDS server 1501, which can then write it to a variant library 1504 in the vehicle's memory. The vehicle can use non-volatile memory and optionally one or more additional libraries (such as a power-down recovery application) to decode the runtime configuration file 1503. As a result, additional decoded runtime configurations 1505 can be added to the variant library memory. Then, an application (e.g., an ECM application) can request the required configuration from the library during runtime. Optionally, there may be an abstraction layer available to the application that can access abstract data rather than the raw values from the DBC file.

[0145] In some embodiments, instead of discrete versions, a variant library can define the differences in the runtime instructions for different versions. For example, certain parts of the code may be obfuscated in the code to achieve different versions. In some specific implementations, the build system can access vehicle generation information and use this information to identify hardware differences. For example, different interface IDs of the battery or HVAC can be accessed. Conversely, if a configuration specific to a certain vehicle model is used, the system may identify which parts of the vehicle are different. For example, if two vehicles have different HVAC systems, the software module used to control the HVAC can be switched in the configuration without affecting the rest of the configuration (this can be achieved by using abstractions). A new Local Interconnect Network (LIN) table can be used to implement this functionality. In another embodiment, a scheduling table can be used to switch to at runtime. For example, the same binary file can be loaded into all vehicles, and the system can select the correct code during operation and ignore the code related to other configurations.

[0146] In some embodiments, runtime configuration options can be used instead of build-time configuration options. For example, in this way, for all vehicle variants, only a single binary can be used. This variant library can set all other configuration options. The variant library can also be used to store user-configurable or selectable variant options for the vehicle. As another example, selectable variants can be defined by the wheel size on the vehicle. Since the wheel size has an impact on vehicle dynamics, the wheel size has a predefined impact on the vehicle dynamics module software, and all software may be affected. The wheel size can be abstracted in the software and provided to all modules that rely on the wheel size to perform their functions.

[0147] In some embodiments, similar techniques can be used for CAN interface handling. For example, a configuration file can represent software or hardware differences. Based on the string value representing the differences, the build system can select the correct DBC file from a directory in memory.

[0148] In some embodiments, runtime software variants can be processed at runtime in each module (e.g., in an ECU) based on the configuration set in the vehicle. When the configuration in the vehicle changes, even though the software on the module remains the same, the module software operates differently based on the new configuration. By using "if / then" or "switch" statements (e.g., in the C programming language), runtime software variants can be traced in the ECU source code. Build-time software variants can be generated by a software build system using compile-time flags. Multiple binary files can be made for the same module to support different vehicle configurations. To change the software operation on the vehicle, after a vehicle configuration change, the module (e.g., ECU) can be flashed with a different software. Build-time variants can be traced and controlled through a variant configuration graph. The variant configuration graph can be stored in the vehicle's memory (e.g., in a software GitHub repository) as part of a build script. During software build, the generated binary codes are structured according to their variants within the vehicle software package and then uploaded and stored in a variant library.

[0149] In some embodiments, vehicle-generated IDs can be defined as revisions of a particular platform. To handle variants, multiple DBC files can be combined based on those IDs defined in the build configuration of the project. The DBC files may be broken down by platform, and then each bus is combined into a DBC file and placed in memory before build based on fields defined in the build configuration. The operating system can generate an interface abstraction file based on interface variants. In this way, folders can be generated that are defined to handle the common interface for DBC files from multiple peripherals and vehicle model-specific commonalities. For example, there may be a folder for the common DBC interface and variant folders for interfaces of models using different versions of hardware. As the commonalities between platforms decrease, the folder structure may eventually change to a format that no longer uses a common folder.

[0150] Some embodiments include a method for updating a vehicle when a new hardware component is installed (such as Figure 15As shown in a), the method includes: detecting a new hardware component in step 1510 using a processing circuit in the vehicle; identifying, using the processing circuit, an association between data generated by the new hardware component and at least one software component of the vehicle in 1520; determining in step 1530 whether an updated interface is needed; and if so, generating, in step 1540, an updated interface using the processing circuit for interpreting data from the hardware component, where the updated interface converts data provided by the hardware component into abstract information, and where the updated interface provides the abstract information to at least one software component of the vehicle. If an updated interface is not needed in step 1520, the method moves to step 1540 and takes no action. In some embodiments, the data generated by the new hardware component includes a database (DBC) file. Some embodiments include storing the updated interface in an interface library, where generating the updated interface includes accessing the updated interface from the library. In some embodiments, the updated interface is selected from the library based on the identification of the new hardware component. Some embodiments include processing the abstract information by at least one software component of the vehicle without regard to the data generated by the new hardware component. In some embodiments, the updated interface is used for two-way communication between at least one software component and the new hardware component. In some embodiments, generating the updated interface includes modifying an existing interface.

[0151] Some embodiments include a system for updating a vehicle when a new hardware component is installed, the system including: the new hardware component; an association between data generated by the new hardware component and at least one software component of the vehicle; and an interface configured to convert data from the hardware component into abstract information, where the interface provides the abstract information to at least one software component of the vehicle. In some embodiments, the data generated by the new hardware component includes a database (DBC) file. Some embodiments include an interface library where updated interfaces are stored. Some embodiments include identification of the new hardware component, where the updated interface is selected from the library based on the identification of the new hardware component. In some embodiments, the abstract information is processed by at least one software component of the vehicle without regard to the data generated by the new hardware component. In some embodiments, the updated interface is used for two-way communication between at least one software component and the new hardware component. In some embodiments, the updated interface is a modification of an existing interface.

[0152] Some embodiments include a non-transitory computer-readable medium having non-transitory computer-readable instructions encoded thereon that, when executed by a processor, cause the processor to: detect a new hardware component using a processing circuit in a vehicle; identify an association between data generated by the new hardware component and at least one software component of the vehicle using the processing circuit; and generate an updated interface for interpreting data from the hardware component using the processing circuit, wherein the updated interface converts data provided by the hardware component into abstract information, and wherein the updated interface provides the abstract information to at least one software component of the vehicle. In some embodiments, the data generated by the new hardware component includes a database (DBC) file. Some embodiments include causing the processor to store the updated interface in an interface library, wherein generating the updated interface includes accessing the updated interface from the library. In some embodiments, the updated interface is selected from the library based on the identification of the new hardware component. Some embodiments include causing the processor to process the abstract information by at least one software component of the vehicle without regard to the data generated by the new hardware component. In some embodiments, the updated interface is used for two-way communication between at least one software component and the new hardware component.

[0153] Figure 16 An exemplary system for managing time synchronization of different modules (e.g., hardware and / or software) connected via a single bus (e.g., a CAN bus) is depicted. Specifically, the technique can be applied to any kind of multi-master bus-based protocol (e.g., when there are many bus master nodes on the bus). Such buses can be used when multiple nodes on the bus must have the ability to initiate data transfers. For example, a multi-master bus can be used to transfer data between a peripheral device and a memory without using a CPU.

[0154] In an exemplary vehicle (e.g., as Figures 1 to 3 depicted), multiple nodes (e.g., ECUs) can be connected to bus 1600 (e.g., a CAN bus or any other multi-master bus), as Figure 16 shown. Figure 16 Each circle in

[0155] However, this prior solution does not account for the time delay between the point at which the time server sets the time on the bus message and the time at which the receiving node ultimately receives and processes the message. This delay can be caused by several variable delay sources. The delay sources can include the time it takes for the time synchronization broadcast to pass through the server's software stack before it can be transmitted over the hardware bus. The delay sources can include the time it takes for the message to propagate over the lines of the bus (which can be indeterminate in a bus management system using an arbitration protocol). The delay sources can include the time it takes for the client's software stack to process the received message before the client can access the time value. For these reasons, when the client updates its internal clock to the time it has just received in the bus message, it is synchronizing with a past time. In this method, the client's internal clock will lag behind the time of the time server node. Some nodes may not care about this relatively small time difference (e.g., nodes 1602 and 1603), whereas other nodes may desire precise and tight time synchronization with the server node (1601) (e.g., node 1604).

[0156] Another time synchronization method is described by the Simple Network Time Protocol (SNTP) (RFC 1769, https: / / datatracker.ietf.org / doc / html / rfc1769), which is incorporated herein by reference in its entirety. In this method, the client sends its local time in a synchronization message to the time server. The server replies using a synchronization message that includes both the client's local time and the server's local time. The client can then calculate the delay between the client and the server (e.g., by subtracting the timestamps) and adjust its clock by the delay value to achieve tighter synchronization. The disadvantage of this method is that it requires point-to-point communication between each node and the time server. A large number of such messages can saturate the bus and degrade bus performance. Additionally, some nodes may not require tight synchronization, in which case they will still fill the bus with completely unnecessary synchronization messages.

[0157] Figure 17 and Figure 18 illustrates a hybrid solution for node synchronization that can achieve loose synchronization and tight synchronization according to the requirements of multiple nodes with different needs on the same bus. This method provides the ability for nodes to select their level of time synchronization. By passively listening for time updates, a sub-standard level of synchronization can be maintained. By actively requesting time updates, a high level of synchronization can be maintained without affecting other nodes on the network. As Figure 17As shown, the server node can continuously (e.g., periodically or at other specific intervals) transmit (e.g., by broadcasting on the bus) a message including the internal time of the server. For example, the message can include a "Transmit" field that includes the time value of the server's internal clock when the message was created. For example, the transmission timestamp can have a value of "47.5 ms".

[0158] Before being processed by the time client node, the message can experience server stack latency, line latency, and client stack latency, and the time client node can modify the message by adding a destination timestamp when receiving the message. For example, the destination timestamp can have a value of "60 ms". Then, the node can calculate the difference between the transmission timestamp and the destination timestamp to adjust its clock. For example, the node can adjust its clock to "47.5 ms" to achieve loose synchronization. Whenever it is appropriate for the client node (e.g., each time it receives a synchronization message from the server or only uses some broadcast messages), the client node can perform this synchronization.

[0159] Figure 17 The interaction between a node requiring tight synchronization and the same server is shown. In this case, the server can also continuously (e.g., periodically or at other specific intervals) transmit (e.g., by broadcasting on the bus) a message including the internal time of the server. However, the server can consider synchronization requests sent by the node via the bus.

[0160] For example, in Figure 17 a node requiring tight synchronization can send a synchronization request using the node's internal clock, and the synchronization request includes a timestamp 1701 at the time of transmission. For example, the transmission field can include a value of "56.5" (which is the local time of the node). The node can save a local copy of the transmission field for verification.

[0161] When the time server receives such a request, it can modify its next periodically sent time update message. In some embodiments, the server can receive several tight synchronization requests before the next update message. In this case, the server can process only one of these requests (e.g., the first request, or a randomly selected request). Specifically, the server can create the next synchronization update message by placing the transmission value of the received message into the "Origin" field. For example, the "Origin" field can include a value of "56.5". The server can also include a timestamp 1702 that indicates when the message sent by the node was received by the server using the server's clock. For example, the "Received" file can have a value of "60". Then, the server will send an update message (e.g., at the originally scheduled time or immediately), and the update message will include the transmission time based on the server clock. For example, the transmission value can be set to "60.5".

[0162] When the client receives a synchronization message, it can modify the synchronization message by adding a timestamp to the destination field based on its own clock. When the client receives a synchronization message from the server with a non-zero "origin" value, the client can compare the "origin" field with the initial "transmission" time of the message sent (and stored in the node's memory) by the node. If the fields do not match, the node can still use the message received from the server for loose synchronization (e.g., as described with respect to Figure 16 . If the fields match, the client can perform tight synchronization.

[0163] Specifically, tight synchronization can be performed by calculating the round-trip delay 1801, e.g., where the round-trip delay = ("destination" value 1802 - "origin" value 1803) - ("received" value 1804 - "transmitted" value 1805), as Figure 18 shown. That is, the client node can calculate the delay between server reception and server transmission, the delay between node transmission and node reception, and subtract these values. The node can also calculate the clock offset 1806 by averaging: (a) the time difference between the "origin" value 1803 (node clock) and the reception time 1804 (server clock); and (b) the time difference between the "transmitted value" 1805 (server clock) and the "destination" 1802 (node clock). The round-trip delay and offset values can be used by the node to modify its local clock to closely match the server clock (e.g., by adding the round-trip delay and clock offset to its internal clock). Advantageously, if two nodes are synchronized with each other, they can use the same message from the server to perform server tight synchronization (since their transmitted values will be the same).

[0164] Additionally, in some embodiments, the node can store a history of the calculated clock offset and round-trip delay. If the history indicates a stable pattern, the node can reduce the frequency of its requests for tight synchronization or stop sending requests for tight synchronization, and can rely on the historical values to perform synchronization. This can further reduce congestion on the bus (e.g., a CAN bus).

[0165] Some embodiments (such as Figure 18AThe method (as shown) for achieving tight synchronization among a first client, a second client, and a time server (where the first client, the second client, and the time server are each associated with a respective local clock and each connected to a bus) includes the following steps: generating, by the time server, a periodic synchronization message 1810 to be transmitted via the bus; receiving, at the time server via the bus, a synchronization message that includes a request for tight synchronization 1820 from the first client; in response to receiving the synchronization message, adjusting, by the time server, the periodic synchronization message based on the tight synchronization request by adjusting the next periodic synchronization message to include: (a) a first time indicating when the first client transmits the synchronization message; (b) a second time indicating when the server receives the tight synchronization request; and (c) a third time indicating when the time server transmits the periodic synchronization message 1830; performing, by the first client, tight synchronization based on the adjusted periodic synchronization message 1840; and performing, by the second client, loose synchronization based on the adjusted periodic synchronization message 1850.

[0166] Figures 19 to 21 An example of stitching together assembly code for a test device (e.g., an integrated circuit) is depicted. Specifically, systems and methods are provided for creating compiled machine-readable code (e.g., assembly code) for testing multiple versions of a function compiled from a language that does not allow function overloading operations (e.g., the C language). The device can be any circuit of a vehicle as Figures 1 to 3 shown. In some embodiments, the device can be any suitable electronic device.

[0167] Unit testing is an integral part of secure software development. For example, the ISO26262 standard strongly recommends that safety-critical software be unit-tested on the target device or circuit where the code is intended to run. To this end, during testing, the software is provided to the device for compilation and / or loading on existing hardware. Such testing ensures that any compiler- or hardware-specific characteristics are properly accounted for in device testing.

[0168] In some specific implementations, the circuit under test (e.g., an embedded circuit of a vehicle) can receive and install an entire application as a single compiled binary code in assembly language. For example, for all applications, the drivers and necessary libraries can be compiled into a single image within a single memory space of the circuit. However, such a requirement makes it difficult to exhaustively test all inputs for certain functions.

[0169] In one example, a first function on a first device may require the output of a second function produced by a second device. In this case, to exhaustively test the operation of the first function on the first device, it would be beneficial to test each possible output provided by the second function produced by the second device. To achieve this, the second device can be flash programmed with a code where the second function is replaced with a fake function (also known as a stub function or mock function) that only provides values set by programming, or runs through each possible output without providing the real functionality. For example, a TCM may have a function that requires revolutions per minute (RPM) values from an ECM. In this case, when testing the TCM software, it may be beneficial to fake the RPM setting function on the ECM that iterates through each possible RPM value. However, this means that the ECM used to test the TCM must ultimately be re-flashed with an image for testing other functions or a real image that includes a real function that returns real RPM values. This process of creating and re-flashing multiple binary images can be cumbersome and may lead to errors if the wrong image is used.

[0170] In one approach, function overloading can be used. In this case, multiple versions of a function can exist and the system can distinguish which function to call (e.g., based on the input to the function call). However, multiple embedded systems do not accept code compiled from such languages and may accept code from a language that does not support overloading (e.g., the C programming language).

[0171] When using such languages, there may be only one copy of a function for any given image. This means that if a function needs to be stubbed for a fake test function to test another function, that stub function is the only copy in the entire image. For example, if the next unit under test is the stub function, it cannot coexist with the previous unit in the same image. In practice, this means that multiple images must be compiled for different units under test. The process of flashing these multiple images onto the target hardware and collecting the results is very cumbersome.

[0172] To overcome this problem, a method is provided to separately compile all the required images (including the real image and all images with stub functions) into assembly code. Then, the assembly code is stitched together into a single super image. During stitching, each sub-image is adjusted to accommodate the fact that they now reside in different address spaces. This allows for a single file that can be flashed for all testing and production.

[0173] This solution does not require any additional technology on top of the language, nor does it require function overloading (e.g., the C programming language), and it does not impose any constraints on the target hardware. For example, the solution does not require the use of a memory management unit, a new operating system, or a different programming language. The solution is widely applicable to all types of suitable hardware and can greatly improve the efficiency of target unit testing. In addition, the solution promotes isolation between unit tests, which is a core responsibility of proper unit testing and has been difficult to achieve with languages without function overloading.

[0174] The method for creating a super image based on compiled images can be performed using the following steps. Each unit test code that requires the use of stub functions is compiled into a single image. Then, as many different images as possible required for the final test suite are compiled. All the compiled images are fed into a large image creator program (MICP). For each image, the MICP locates the position of the image in memory so that it does not conflict with the memory requirements of other images. Then, for each image, the MICP adjusts the machine instructions therein to reflect the new final address location. Next, as part of the final large image creation, the MICP creates an entry point table for each sub-image and the unit test framework that goes into the large image, which is a combination of all the sub-images.

[0175] Next, the large image is flashed onto the target hardware. At this point, hardware tests can be run to collect test data. The ability to execute target unit tests quickly reduces their entry barriers, making it easier to obtain ISO26262 ASIL certification and allowing for faster production of ASIL-level software.

[0176] Figure 19 Exemplary code for testing a second unit by a first unit is shown. The code for the second unit can include the code for function Function 2, which is a real function that can produce variable outputs.

[0177] Figure 20 Exemplary code for the first unit being used in the test is shown. It can be seen that the function unit 32_t_to_test_one includes a function call to Function 2 on line 111. As described above, it may be advantageous to replace the real function Function 2 with a stub function or a mock function that returns values set by the programmer (e.g., iterating through all possible outputs).

[0178] Figure 21 An exemplary result produced by the MICP is shown, which the MICP will Figure 19 image of the code of Figure 20The images of the code are stitched within a single large image 2101. Notably, the large image 2101 includes a jump table that enables the function Function 1 in sub-image one 2102 (at line 105) to call the real function Function 2 at line 246 in addition to calling a pseudo-function at line 193. The line numbers of the function Function 2 may have been changed by MICP to avoid memory conflicts. Those skilled in the art will note that while Figures 19 to 21 a C language code is shown, any other programming language may have been used (e.g., an assembly language specific to the hardware being tested).

[0179] The systems and methods described herein are not limited to use in testing. The system can be used wherever function overloading is beneficial, including for readability or saving memory space, and for other uses.

[0180] Some embodiments may include a method for function overloading (as Figure 21 shown in a), the method including: compiling a first image 2110 of a first version of a function; compiling a second image 2120 of a second version of the function; and generating a stitched super-image by placing the code defining the first version of the function and the code defining the second version of the function into memory partitions, wherein the code defining the second version of the function is adjusted to not conflict with the code of the first version of the function, and generating a table for selectively calling either the first version or the second version of the function 2130. In some embodiments, the first version and the second version of the function are written in code that does not allow function overloading. In some embodiments, the first version and the second version of the function are written in C code. In some embodiments, the memory partitions are located within a vehicle. In some embodiments, the table defines corresponding memory addresses for each of the first version and the second version of the function. In some embodiments, the first image of the first version of the function includes first assembly code, while the second image of the second version of the function includes second assembly code. Some embodiments also include calling each version of the function in the stitched super-image based on the table.

[0181] The foregoing is merely illustrative of the principles of the present disclosure, and various modifications may be made by those skilled in the art without departing from the scope of the present disclosure. The above embodiments are presented for purposes of illustration and not of limitation. The present disclosure may take many forms other than those explicitly described herein. Accordingly, it should be emphasized that the present disclosure is not limited to the explicitly disclosed methods, systems, and devices, but is intended to include variations and modifications within the substance of the following paragraphs.

Claims

1. A system for synchronization among a first client, a second client, and a time server, where the first client, the second client, and the time server are each associated with a respective local clock, the system comprising: The time server connected to the bus, The first client connected to the bus, The second client connected to the bus, where the first client is configured to request a first type of synchronization with the time server by transmitting a synchronization message on the bus, wherein: The time server is configured to generate periodic synchronization messages to be transmitted on the bus, The time server client is configured to adjust the periodic synchronization messages based on the first type of synchronization request from the first client by adjusting the next periodic synchronization message to include: (a) a first time indicating when the first client transmits the synchronization message; (b) a second time indicating when the server receives the first type of synchronization request; and (c) a third time indicating when the time server transmits the periodic synchronization message, The first client is configured to perform the first type of synchronization based on the adjusted periodic synchronization message, and The second client is configured to perform a second type of synchronization based on the adjusted periodic synchronization message.

2. The system according to claim 1, wherein the first client is further configured to perform the first type of synchronization based on the content of the adjusted periodic synchronization message and the reception time of the adjusted periodic synchronization message.

3. The system according to claim 1, wherein the first client, the second client, and the time server are located on a vehicle.

4. The system according to claim 1, wherein the synchronization message includes data indicating the first time.

5. The system according to claim 1, further comprising a memory for storing information about the delay between the time server and the first client.

6. The system according to claim 5, further comprising a processing circuit that determines a delay determination mode based on the delay and causes synchronization to occur between the first client and the time server based on the mode.

7. A method for synchronization among a first client, a second client, and a time server, where the first client, the second client, and the time server are each associated with a respective local clock and each connected to a bus, the method comprising: Generating, by the time server, periodic synchronization messages to be transmitted through the bus; Receiving, at the time server through the bus, a synchronization message including a request for a first type of synchronization from the first client; In response to receiving the synchronization message, the time server adjusts the periodic synchronization message based on the first type of synchronization request by adjusting the next periodic synchronization message to include: (a) a first time indicating when the first client transmitted the synchronization message; (b) a second time indicating when the server received the first type of synchronization request; and (c) a third time indicating when the time server transmitted the periodic synchronization message; The first client performs a first type of synchronization based on the adjusted periodic synchronization message; and The second client performs a second type of synchronization based on the adjusted periodic synchronization message.

8. The method according to claim 7, further comprising performing the first type of synchronization based on the content of the adjusted periodic synchronization message and the reception time of the adjusted periodic synchronization message.

9. The method according to claim 7, wherein the first client, the second client, and the time server are located on a vehicle.

10. The method according to claim 7, wherein the synchronization message includes data indicating the first time.

11. The method according to claim 7, further comprising storing information about the delay between the time server and the first client in a memory.

12. The method according to claim 11, further comprising a processing circuit determining a mode based on the delay and causing synchronization to occur between the first client and the time server based on the mode.

13. A non-transitory computer-readable medium having non-transitory computer-readable instructions encoded thereon that, when executed by a processor, cause the processor to: Generate, by a time server, a periodic synchronization message to be transmitted over a bus; Receive, at the time server over the bus, a synchronization message including a request for a first type of synchronization from a first client; In response to receiving the synchronization message, the time server adjusts the periodic synchronization message based on the first type of synchronization request by adjusting the next periodic synchronization message to include: (a) a first time indicating when the first client transmitted the synchronization message; (b) a second time indicating when the server received the first type of synchronization request; and (c) a third time indicating when the time server transmitted the periodic synchronization message; The first client performs the first type of synchronization based on the adjusted periodic synchronization message; and The second client performs a second type of synchronization based on the adjusted periodic synchronization message.

14. The computer-readable medium according to claim 13, further causing the processor to perform the first type of synchronization based on the content of the adjusted periodic synchronization message and the reception time of the adjusted periodic synchronization message.

15. The computer-readable medium according to claim 13, wherein the first client, the second client, and the time server are located on a vehicle.

16. The computer-readable medium according to claim 13, wherein the synchronization message includes data indicating the first time.

17. The computer-readable medium according to claim 13, further comprising causing the processor to store information about a delay between the time server and the first client in a memory.

18. The computer-readable medium according to claim 13, further comprising causing the processor to determine a mode based on the delay and causing synchronization to occur between the first client and the time server based on the mode.

Images