Improved target unit testing

Abstract

The present disclosure relates to systems and methods aimed at 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 handling, transmission, and reception of messages for better synchronization. The disclosure herein also provides a simplified method of key configuration by designating one client as a server and assigning symmetric keys for each other client that is permanently set between the client and the server. Systems and methods are also provided that predict failures in a vehicle. Systems and methods are also provided that preserve data in the event of a system crash. Systems and methods are also provided in which the operating system of a vehicle detects the presence of a new peripheral device and pulls the relevant interface file for the new peripheral device. Furthermore, a data synchronization solution is provided herein that provides a level of synchronization that is optimized.

Description

[0001] Cross-references to related applications

[0002] This disclosure claims the benefit of U.S. Provisional Application No. 63 / 240,190, filed September 2, 2021, the entire contents of which are incorporated herein by reference. Summary of the Invention

[0003] This disclosure relates to systems and methods designed to improve vehicle functionality.

[0004] Typical vehicles include systems that perform functions requiring synchronization. In many such systems, some tasks have priorities, allowing preemption of other tasks, thus pausing the first task to support another. Some typical vehicle systems also perform 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 result corresponds to the correct data. However, if a second task preempts the end-to-end check, the data will not correspond correctly. Data mismatches can lead to problems requiring additional cycles to fix, or even system crashes. Therefore, a system is needed to ensure synchronization between tasks. According to this disclosure, systems and methods are provided that provide custom tools that automatically generate a set of software agents that allow the system to separate message processing, transmission, and reception for better synchronization. In some embodiments, a pre-selected text-based descriptor file format (e.g., a specially formatted DBC file) is used to describe the vehicle's network through multiple file fragments per bus. The descriptor file format may require some style of annotations or stub sections that provide 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 implementations, the code generation software is aware of the file format and can add signals that will compile without problems or require additional processing.

[0005] Some implementations include a method comprising: accessing a file containing information for decoding bus data; generating a plurality of software agents based on the file, wherein the software agents, when executed, are configured to receive raw messages via the bus, unpack the raw messages to generate signal values, generate security protection values ​​for the raw messages; and providing synchronous access to the signal values ​​and security protection values ​​in response to a request for the signal values ​​from an instance of an application executing instructions in a protected memory location. In some embodiments, generating multiple software agents includes: generating a first instruction set for execution from a first insecure memory partition, wherein the first instruction set, when executed, is configured to receive raw messages from a 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 messages to generate signal values, perform verification to generate security protection values ​​for the raw messages, store the signal values ​​and security protection values, and synchronously transmit the signal values ​​and security protection values ​​to an instance of the application; and generating a third instruction set for execution from a second insecure memory partition, wherein the third instruction set, when executed, is configured to unpack the raw messages 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 insecure 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 implementations, generating security protection values ​​includes generating end-to-end (E2E) states.

[0006] Some implementations include a non-transitory computer-readable medium having instructions encoded thereon that, when executed by controlled circuitry, cause the control circuitry to: access a file containing 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 raw messages via the bus, unpack the raw messages to generate signal values, generate security protection values ​​for the raw messages; and provide synchronous access to the signal values ​​and security protection values ​​in response to a request for the signal values ​​from an instance of an application executing instructions in a protected memory location. In some embodiments, the control circuitry causes multiple software agents to be generated by: generating a first instruction set for execution from a first unsafe memory partition, wherein the first instruction set, when executed, is configured to receive raw messages 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 messages to generate signal values, perform verification to generate security protection values ​​for the raw messages, store the signal values ​​and security protection values, and synchronously transmit the signal values ​​and security protection values ​​to an instance of the application; and generating a third instruction set for execution from a second unsafe memory partition, wherein the third instruction set, when executed, is configured to unpack the raw messages 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 unsafe 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 implementations, generating security protection values ​​includes generating end-to-end (E2E) states.

[0007] Some embodiments include a vehicle system comprising: a sensor connected to at least one bus; and control circuitry configured to access a file including information for decoding bus data received from the sensor via the bus, and to generate a plurality of software agents based on the file, wherein the software agents, when executed, are configured to receive raw messages via the bus, unpack the raw messages to generate signal values, generate security protection values ​​for the raw messages, and provide synchronous access to the signal values ​​and security protection values ​​in response to requests for the signal values ​​from instances of applications executing based on instructions in protected memory locations. In some embodiments, the control circuitry is configured to generate the plurality of software agents by:

[0008] A first instruction set is generated for execution from a first unsafe memory partition, wherein the first instruction set, when executed, is configured to receive raw messages from the bus; a second instruction set is generated for execution from a protected memory partition, wherein the second instruction set, when executed, is configured to unpack the raw messages to generate signal values, perform verification to generate security protection values ​​for the raw messages, store the signal values ​​and security protection values, and synchronously transmit the signal values ​​and security protection values ​​to an instance of the application; a third instruction set is generated for execution from a second unsafe memory partition, wherein the third instruction set, when executed, is configured to unpack the raw messages 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 unsafe 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., temporary keys) to encrypt messages sent between them. Existing systems are cumbersome, requiring numerous keys and certificates for each module to provide a private or public key for each secure transaction. An improved, simplified key setup method is needed. The disclosure of this paper provides such a method by designating a client as a server and assigning a symmetric key to each other client permanently set up between that client and the server. This symmetric key minimizes the need for permanent keys and can be used to leverage temporary keys. In some implementations, during the exchange, a client can initiate communication with a second client. In some implementations, the second client can then request a temporary key from the server, which was 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 temporary key. In some implementations, client 1 and client 2 now possess a shared key and can communicate securely. This method reduces the number of keys required and simplifies secure communication.

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

[0011] The system receives a first message from a first node of the vehicle, the first message including information identifying a second node of the vehicle; in response to receiving the first message, generates an encryption key using the vehicle's processing circuitry; transmits information identifying the encryption key to the first node of the vehicle; receives a second message from the second node of the vehicle, the second message including information identifying the first node of the vehicle; determines, using the processing circuitry, that the second message is valid based on the first message; and transmits information identifying the encryption key to the second node of the vehicle. In some embodiments, the first message also 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 also 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 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 and the transmission to the second node of the vehicle are performed 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 comprising: a first message from the first node of the vehicle, the first message including information identifying the second node of the vehicle; a second message from the 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 acknowledged to the first node and the second node. In some embodiments, the first message also 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 also 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 and the second node of the vehicle are located on a shared bus within the vehicle. In some embodiments, the encryption key is acknowledged 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, which, when executed by a processor, cause the processor to: receive from a first node of a vehicle information including a first message identifying a second node of the vehicle; generate an encryption key using the vehicle's processing circuitry in response to receiving the first message; transmit information identifying the encryption key to the first node of the vehicle; and receive from the second node of the vehicle a second message including information identifying the first node of the vehicle.

[0014] The processing circuitry determines the validity of the second message based on the first message and transmits information identifying the encryption key to the second node of the vehicle. In some embodiments, the first message also 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 also includes a random number generated by the second node. In some embodiments, the first node and the second node of the vehicle are located on a shared bus within the vehicle. In some embodiments, the transmission to the first node and the transmission to the second node of the vehicle are performed via the shared bus.

[0015] Failures will occur throughout the lifespan of a vehicle. Vehicle failures not only cause inconvenience, such as affecting vehicle performance, but can also jeopardize vehicle safety, thus creating danger. They can also lead to further failures with additional problems. Given these complexities, it is advantageous to detect failures as quickly as possible to address them before they become dangerous or costly complications. Specifically, there is a need for a system to predict failures before they occur. According to this disclosure, systems and methods for predicting failures in vehicles are provided. In some embodiments, the system includes a fleet of vehicles, all connected to a server. The server can receive data on vehicle measurements and conditions from multiple vehicles in the fleet. The server can also analyze the received measurements and determine the frequency of a particular problem. The server can store this information and continue to monitor the vehicles. Another vehicle can report measurements similar to or having the indicated correlation with a particular problem, and the server can provide that vehicle with early failure detection. In some embodiments, the server can transmit early warnings to the vehicles, urging maintenance or other actions. In this way, this disclosure provides a means to predict failures and mitigate their potential damage.

[0016] Some implementations include a method for predicting malfunction events in a vehicle, the method comprising: monitoring multiple operating parameters of the vehicle and the vehicle's geographic location using processing circuitry; determining, using the processing circuitry, that the values ​​of the operating parameters and the geographic location may be associated with the malfunction event based on a model trained using corresponding values ​​of the operating parameters for a group of vehicles and corresponding geographic locations of the group of vehicles experiencing the corresponding malfunction event; and causing an action to be performed in response to the determination using the processing circuitry. Some implementations also include transmitting the vehicle's operating parameters and geographic location to a remote server, wherein determining that the values ​​of the operating parameters and the geographic location may be associated with the malfunction event includes receiving information indicating the correlation from the remote server. In some implementations, the model is located at a remote server. In some implementations, causing an action includes causing a notification indicating a malfunction event to be provided. In some implementations, causing an action includes causing a change in at least one of multiple operating parameters to avoid a malfunction event. In some implementations, causing an action includes causing an action to be performed at a remote server, wherein the action is performed within the vehicle. In some implementations, the model is repeatedly updated based on new data provided by the group of vehicles.

[0017] Some implementations include a system for predicting malfunction events in a vehicle, the system comprising: multiple operating parameters of the vehicle, the vehicle's geographic location, a model trained using corresponding values ​​of the operating parameters for a set of vehicles and corresponding geographic locations of the set of vehicles experiencing the corresponding malfunction event, wherein the values ​​of the operating parameters and the geographic location are likely associated with the malfunction event, wherein the values ​​of the operating parameters and the geographic location are determined to be likely associated with the malfunction event based on a model and actions performed in response to this determination. Some implementations include providing information indicating the correlation between the vehicle's operating parameters and geographic location and the malfunction event. In some implementations, the model resides at a remote server. Some implementations include notification indicating a malfunction event. In some implementations, the action includes changing at least one of the multiple operating parameters to avoid the occurrence of a malfunction event. In some implementations, the action is performed by a remote server, and wherein the action is performed within the vehicle. In some implementations, 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, which, when executed by a processor, cause the processor to: monitor multiple operating parameters of the vehicle and the vehicle's geographic location using processing circuitry; determine, based on a model trained using corresponding values ​​of the operating parameters for a set of vehicles and corresponding geographic locations of the set of vehicles experiencing corresponding fault events, that the values ​​of the operating parameters and the geographic location may be related to the fault events; and cause an action to be performed in response to the determination using the processing circuitry. Some embodiments include transmitting the vehicle's operating parameters and geographic location to a remote server, wherein determining that the values ​​of the operating parameters and the geographic location may be related to the fault events 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 a fault event to be provided. In some embodiments, causing the action to be performed includes causing a change in at least one of multiple operating parameters to avoid 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 implementations, the model is repeatedly updated based on new data provided by the group of vehicles.

[0019] System crashes are a common problem in vehicle systems. For example, a system may become unresponsive. In these situations, there is a risk of data loss because some information may be irrecoverable or unrecoverable. Data loss can lead to malfunctions or the inability to properly record information, both of which can cause various problems. Therefore, a system for data retention is needed. According to this disclosure, a system and method for retaining data in the event of a system crash are provided. In some embodiments, the system includes a backup storage device. In some embodiments, the system can take one or more snapshots of system information and store them in the backup storage device. In some embodiments, the storage device is not cleared between startups. In this way, the disclosed system provides a means of retaining data in the event of a crash.

[0020] Some embodiments include a method for storing information about a vehicle, the method comprising: detecting a fault event by processing circuitry; and in response to the detection: generating information about the vehicle by the processing circuitry upon the occurrence of the fault event; generating integrity data by the processing circuitry based on the information; causing the processing circuitry 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; causing the processing circuitry to restart the vehicle's operating system; after the restart, verifying the information stored in the volatile memory based on the integrity data by the processing circuitry; 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 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 information and integrity data. In some embodiments, detecting a fault event includes detecting a system crash. In some embodiments, the information includes a snapshot of the software state in the vehicle. In some implementations, the generation of information, the generation of integrity data, and the storage of information and integrity data are performed by an emergency stack programmed to execute in the event of a fault event. Some implementations include a system for storing information about a vehicle, the system comprising: a vehicle operating system; 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; and 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 that portion of the volatile memory in response to the fault event.

[0021] Non-volatile memory, wherein in response to restarting the vehicle's operating system, information about the vehicle is verified based on integrity data, and wherein in response to this verification, the information about the vehicle is stored in the non-volatile memory. In some embodiments, the integrity data includes Cyclic Redundancy Check (CRC). In some embodiments, the volatile memory includes Random Access Memory (RAM). In some embodiments, this portion of the volatile memory is a dedicated portion of the volatile memory reserved for information and integrity data. In some embodiments, detecting fault events includes detecting system crashes. In some embodiments, the information includes a snapshot of the software state in the vehicle. Some embodiments include an emergency stack programmed to generate information, generate integrity data, and cause the storage of information and 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, which, when executed by a processor, cause the processor to: detect a fault event by processing circuitry; and in response to the detection: generate information about the vehicle by the processing circuitry when the fault event occurs; generate integrity data by the processing circuitry based on the information; cause the processing circuitry to store the vehicle-related information and 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; cause the processing circuitry to restart the vehicle's operating system; after the restart, verify the information stored in the volatile memory based on the integrity data by the processing circuitry; and in response to the verification, cause the vehicle-related information to be stored in non-volatile memory. In some embodiments, the integrity data includes 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 information and integrity data. In some embodiments, detecting a fault event includes detecting a system crash. In some implementations, the information includes snapshots of the software state in the vehicle.

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

[0024] Some embodiments include a method for updating a vehicle upon installation of a new hardware component, the method comprising: detecting the new hardware component using processing circuitry in the vehicle; identifying an association between data generated by the new hardware component and at least one software component of the vehicle using the processing circuitry; and generating an updated interface for interpreting data from the hardware component using the processing circuitry, wherein the updated interface converts the 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 the abstract information being processed by at least one software component of the vehicle, regardless of the data generated by the new hardware component. In some embodiments, the updated interface is used for bidirectional 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 implementations include a system for updating a vehicle upon installation of new hardware components, 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 implementations, the data generated by the new hardware component includes a database (DBC) file. Some implementations include an interface library storing updated interfaces. Some implementations include identification of the new hardware component, wherein an updated interface is selected from the library based on the identification of the new hardware component. In some implementations, the abstract information is processed by at least one software component of the vehicle, regardless of the data generated by the new hardware component. In some implementations, the updated interface is used for bidirectional communication between at least one software component and the new hardware component. In some implementations, 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, which, when executed by a processor, cause the processor to: detect a new hardware component using processing circuitry in the 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 the 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, regardless of the data generated by the new hardware component. In some embodiments, the updated interface is used for bidirectional communication between at least one software component and the new hardware component.

[0027] Key components of a vehicle management system include periodic data transmissions. Sometimes, multiple nodes on the same bus must be capable of transmitting data. Furthermore, some of these transmissions must be synchronized for vehicle functionality. While some nodes may operate with basic or loose synchronization, others require very precise synchronization. However, precise synchronization relies on numerous messages traveling back and forth between the client and server, and precisely synchronizing each node can overwhelm the system, saturating the bus and degrading performance. A hybrid solution is needed that can accommodate both loose and tight synchronization. As described in this disclosure, a hybrid solution is provided that offers the advantage of providing tight synchronization when needed and loose synchronization when not required. As disclosed, the system's server can continuously transmit its internal time. A receiving node can then compare the time it receives a 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, a 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 client) and its response time. A node can calculate and subtract the latency between server receive and server transmit, as well as the latency between node transmit and node receive. A node can also calculate a clock offset by creating an average of the time difference between its 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 round-trip latency and clock offset to its internal clock).

[0028] Additionally, in some implementations, nodes can store a history of calculated clock skew and round-trip delays. If the history indicates a stable pattern, a node can reduce the frequency of its close synchronization requests or stop sending close synchronization requests altogether, and can rely on historical values ​​to perform synchronization. Advantageously, if two nodes are synchronizing with each other, they can perform server close synchronization using the same messages from the server, since their transmitted values ​​will be identical.

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

[0030] A time server client is configured to adjust periodic synchronization messages 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 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 sends 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 also configured to perform tight synchronization based on the content of the adjusted periodic synchronization message and the time of receipt of the adjusted periodic synchronization message. In some embodiments, the synchronization message includes data indicating the first time. Some embodiments include memory for storing information about the delay between the time server and the first client. Some embodiments include circuitry for determining a delay pattern and causing synchronization between the first client and the time server based on that pattern.

[0031] Some implementations include a method for tight synchronization between a first client, a second client, and a time server (each associated with a corresponding local clock and each connected to a bus), the method comprising: generating a periodic synchronization message to be transmitted via the bus by the time server; receiving the synchronization message via the bus at the time server, the synchronization message including a request for tight synchronization from the first client; in response to receiving the synchronization message, adjusting the periodic synchronization message based on the tight synchronization request by the time server, 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 sends the periodic synchronization message; performing tight synchronization by the first client based on the adjusted periodic synchronization message; and performing loose synchronization by the second client based on the adjusted periodic synchronization message. Some implementations include performing tight synchronization based on the content of the adjusted periodic synchronization message and the time of receipt of the adjusted periodic synchronization message. In some implementations, the first client, the second client, and the time server are located on the vehicle. In some implementations, the synchronization message includes data indicating a first time. Some implementations include storing information about the delay between the time server and the first client in memory. Some implementations include having processing circuitry determine a pattern based on the delay and causing synchronization between the first client and the time server based on that pattern.

[0032] Some embodiments include a non-transitory computer-readable medium having non-transitory computer-readable instructions encoded thereon, which, when executed by a processor, cause the processor to: generate a periodic synchronization message to be transmitted via a bus by a time server; receive the synchronization message via the bus at the time server, the synchronization message including a request for tight synchronization from a first client; in response to receiving the synchronization message, adjust the periodic synchronization message by the time server 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 sends 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 time of receipt of the adjusted periodic synchronization message. In some implementations, the first client, the second client, and the time server are located on the vehicle. In some implementations, the synchronization message includes data indicating a first moment. Some implementations include causing the processor to store information about the delay between the time server and the first client in memory. Some implementations also include causing the processor to determine a delay pattern and, based on that pattern, cause synchronization between the first client and the time server.

[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 test the first function using a simulated version of the second function that provides these values, utilizing every possible input from the second function. However, many functions are written in programming languages ​​where providing simulated versions of functions requires separate functions. These separate functions then require tedious replacements in the test environment. A solution is needed to integrate the simulated functions into the main function for functions written in a language independent of the simulated functions. According to the disclosure in this paper, a solution is provided that compiles all functions separately into assembly code, which is then 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 large image creation program (MICP). For each image, the MICP locates its position 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 within it to reflect the new final address location. Next, as part of the creation of the final large image, MICP creates a table of entry points for each sub-image within the large image, as well as an entry point table for the unit test framework. The large image is a combination of all the sub-images. A single file can then be flashed to a drive that can be used for testing and production. In this way, mock functions are provided within functions for testing, regardless of the programming language used.

[0034] Some implementations may include a method for function overloading, the method comprising: compiling a first image of a first version of a function; compiling a second image of a second version of a function; and generating a stitched superimage by: placing code defining the first version of the function and 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 generating a table for selectively calling either the first version or the second version of the function. In some implementations, the first version and the second version of the function are written in code that does not allow function overloading. In some implementations, the first version and the second version of the function are written in C code. In some implementations, the memory partition is located within a vehicle. In some implementations, the table defines a corresponding memory address for each of the first version and the second version of the function. In some implementations, the first image of the first version of the function includes first assembly code, and the second image of the second version of the function includes second assembly code. Some implementations also include calling each version of the function in the stitched superimage based on the table.

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

[0036] A memory partition, comprising 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 defining the first version of the function; a table configured to selectively call either the first version 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 the vehicle. In some embodiments, the table defines a corresponding memory address 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, which, 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 a function; and generate a stitched super-image by: placing code defining the first version of a function and code defining the second version of a 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 generating a table for selectively calling either the first version 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 a corresponding memory address 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, and the second image of the second version of the function includes second assembly code. Some embodiments also include causing the processor to call each version of the function in the stitched super-image based on the table. Attached Figure Description

[0038] The above and other objects and advantages of this disclosure will become apparent from the following specific embodiments taken in conjunction with the accompanying drawings, wherein similar reference characters always refer to similar parts, and wherein:

[0039] Figure 1 Block diagrams showing components of a vehicle according to some embodiments of the present disclosure are provided.

[0040] Figure 2 This illustration shows some embodiments of a vehicle for operation (e.g., from...) according to this disclosure. Figure 1 A block diagram of the system.

[0041] Figure 3 Some embodiments according to this disclosure are shown. Figure 1 An exemplary architecture of the vehicle,

[0042] Figure 4a illustrates an exemplary occurrence of preemption causing synchronization problems according to some embodiments of this disclosure.

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

[0044] Figure 5 This illustration shows an exemplary software agent created by a code-automatic software build system according to some embodiments of this disclosure.

[0045] Figure 6 This illustration shows alternative versions of exemplary software agents created by a code-automatic software build system according to some embodiments of this disclosure.

[0046] Figure 7 Some embodiments according to this disclosure are shown. Figure 5 Details of an exemplary implementation of the signal reception check described herein.

[0047] Figure 8 Some embodiments according to this disclosure are shown. Figure 5 Details of an exemplary specific implementation of the transmission process described herein.

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

[0049] Figure 9 Exemplary key exchange scenarios according to some embodiments of this disclosure are shown.

[0050] Figure 10 An improved key setting protocol based on symmetric keys according to some embodiments of this disclosure is illustrated.

[0051] Figure 11 This diagram illustrates the state machine of a node in an encryption algorithm according to some embodiments of the present disclosure.

[0052] Figure 12This diagram illustrates the state machine of a key server in an encryption algorithm according to some embodiments of the present disclosure.

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

[0054] Figure 13 Exemplary systems for improving failure detection in the circuitry or components of a vehicle, according to some embodiments of this disclosure, are shown.

[0055] Figure 13 a flowchart illustrates exemplary steps of a method for predicting malfunction events in a vehicle according to some embodiments of the present disclosure.

[0056] Figure 14 Exemplary systems for facilitating crash recovery are shown according to some embodiments of the present disclosure.

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

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

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

[0060] Figure 16 An exemplary system for managing time synchronization of different modules connected via a single bus is shown according to some embodiments of the present disclosure.

[0061] Figure 17 This illustrates the interaction between nodes and a server that requires close synchronization according to some embodiments of this disclosure.

[0062] Figure 18 Exemplary interactions illustrating round-trip travel delays according to some embodiments of this disclosure are shown.

[0063] Figure 18 a flowchart illustrates exemplary steps of a method for 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 for testing a second unit of a first unit is shown according to some embodiments of this disclosure.

[0065] Figure 20 Exemplary code showing a first unit being tested according to some embodiments of this disclosure is illustrated.

[0066] Figure 21 This illustrates the creation of some embodiments according to this disclosure. Figure 19 and Figure 20 An example result of the code for a super-image.

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

[0068] Vehicle Overview

[0069] According to this disclosure, systems and methods are provided to improve 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 illustrating components of a vehicle 100 according to some embodiments of the present disclosure is shown. In some embodiments, the vehicle 100 may include any of a variety of suitable systems for controlling and operating the vehicle. For example, the vehicle 100 may include one or more engine systems, battery systems, autonomous drive systems, one or more steering systems, pump-brake 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 aforementioned systems. In some embodiments, the vehicle may include internal connectivity or networking components required for systems linking the vehicle.

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

[0072] In some implementations, processor 105 may be communicatively connected to sensors 106, 107, networking components, and one or more user interface components. 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, vehicle-specific sensors, other sensors, or any combination thereof.

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

[0074] In some embodiments, vehicle 100 may include multiple 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 multiple 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 electronic control unit (ECU) 111 for controlling one or more motors of vehicle 100. Each ECM 111 can access various sensors, such as: MAP (Manifold Absolute Pressure), IAT (Intake Air Temperature), MAF (Mass Airflow), 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 sensors, 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 systems.

[0075] Internet Overview

[0076] Figure 2 This illustration shows some embodiments of a vehicle for operation (e.g., from...) according to this disclosure. Figure 1 A block diagram of a system. The system may include multiple vehicles, including vehicle 210 (e.g., Figure 1 220 and 230 vehicles and 250 servers.

[0077] In some embodiments, the system may include a network 240 that communicatively interconnects 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 vehicle 210-230 may include processing circuitry for performing vehicle functions as described in the various embodiments of this disclosure. In some embodiments, each of vehicles 210-230 may include transient and non-transient memory 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 able to receive data from sensors or hardware modules or software modules (e.g., such as…) Figure 1 (As shown) Data is collected. Vehicles 210-230 can be consumer vehicles, or in some implementations, 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 (e.g., information generated by sensors of vehicle 210-230) from vehicles 210-230 via network 240. 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 Depicting Figure 1 An exemplary architecture of a vehicle (e.g., a processor core within the vehicle's processor cores, such as the core of the ECM). For example, Figure 3 The architecture shown can be used Figure 1 The processor and memory shown are used for implementation. Although a specific implementation of a single core is shown, a vehicle may include any number of cores connected by bus or networking elements.

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

[0083] In some implementations, the architecture includes a controller abstraction layer 308 that can access a Controller Area Network (CAN) 309, a Serial Peripheral Interface (SPI) 310, an Integrated Circuit Bus (I2C) 311, a Universal Asynchronous Receiver / Transmitter (UART) 312, a Local Interconnect Network (LIN) 313, and a Digital Input / Output (DIO) bus 314. The microcontroller 301 may also include a chipset driver 315, a bootloader 316, a Controller Area Network First-In-First-Out (FIFO) queue 317, and an Ethernet component 318. Additional networking modules may also be included (e.g., a gateway 319 for FreeRTOS communication 320, Unified Data System (UDS) communication 321, Universal Measurement and Calibration Protocol (XCP) communication 322, Internet Protocol Diagnostics (DoIP) communication 323, ISO Transport Layer Protocol (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. The kernel 302 can then be used to execute application code stored in memory. In some implementations, the kernel 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 transmit information (such as diagnostic or fault codes) between external test equipment and the vehicle control unit (ECU) (using ECU peripheral driver 326) via DoIP 323. This allows vehicle systems to track and analyze diagnostic information to improve failure detection, for example. The core can also receive and send files to external systems (such as cloud servers) via the Controller Area Network (CAN) bus or the Unified Diagnostic Services (UDS) protocol. For example, these files may originate from peripheral devices (e.g., signals from the pump brake module, from engine modules (such as the ECM), or from any other core or vehicle peripheral device or sensor), or go to other modules, their own applications, or other cores. This communication enables the merging of data from different parts of the vehicle (i.e., brakes communicating with the display unit, or data snapshots stored after an ECU failure) or from different systems (i.e., reporting data to an external server).

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

[0086] In one approach, the system includes a separate programming interface for receiving and interpreting data, and / or an application for transmitting data. In some implementations, the system may run within a real-time operating system (RTOS). In an RTOS, tasks have priorities and preemption is allowed. Due to preemption, one task may suspend its execution while another task with a higher priority executes. Preemption can lead to data inconsistency.

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

[0088] For example, task0_5ms might be responsible for end-to-end (E2E) checking and unpacking of signal data (e.g., data received via the CAN bus). In this example, task0_100ms might need to receive: (a) the signal data; and (b) the E2E check result of that signal (which will be provided by task0_5ms). For example, task0_100ms might call a function to acquire the signal data during its 2ms-5ms execution period, and then call a different function to acquire the E2E status during its 7ms-8ms execution period. However, since the second instance of task0_5ms executes 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. This problem becomes even more severe if task0_100ms runs on a different core than task0_5ms. Data mismatch may cause programming problems such as desynchronization during the execution of task0_100ms, which may require additional cycles to remedy, or may even cause system crashes.

[0089] Previous solutions to this problem performed E2E computations within the same partition where the application code requiring the data resided. This provided synchronization between the E2E and message data with the code, as all information ran within the same context; however, these solutions had drawbacks. Firstly, message data needed to be synchronized between the communication stack context and the aforementioned context. This was typically handled through operating system-dependent or less portable and resource-intensive queues. Secondly, redundant computations were required if code was running on other partitions. These solutions also required the code to run synchronously with the incoming data.

[0090] Therefore, a solution is provided to ensure synchronization between tasks, such as a method to ensure synchronization of E2E data with signal processing and transmission data. Specifically, a custom tool (e.g., a set of programming scripts) is provided that automatically generates a set of software agents (e.g., in the C programming language) that allows the system (e.g., including one or more cores) to separate message processing, transmission, and reception for better synchronization. Specifically, E2E computation for receiving signals can occur within a single task, while the software architecture of the cores and applications (which will receive or transmit signals and E2E states) performs the necessary actions to ensure synchronized information reception when needed. This can save CPU cycles on the cores (e.g., Figure 3 Core 300 shown

[0091] Figure 4BAn exemplary data flow diagram of the generated software agent is shown. In some implementations, each application in the vehicle (e.g., such as...) Figures 1 to 3 (As shown) thousands of signals need to be received and sent. Furthermore, some messages need to be routed across numerous networks to various endpoints within the vehicle system. Some messages require authentication (e.g., using E2E status). Manually generated code for handling message reception and E2E authentication is error-prone and can incorporate errors into the system. Therefore, this paper's system automatically generates 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 tasks such as: gatewaying messages between networks; unpacking / packing signals between raw bytes and engineered values; handling end-to-end protection for message / signal integrity; message scheduling; variant management of communication networks; setting communication-related DTCs (Diagnostic Trouble Codes); enabling / disabling communication via network / message; and any other suitable communication-related tasks.

[0092] In some implementations, a pre-selected text-based descriptor file format (e.g., a specially formatted DBC file or other serialization format) is used to describe the vehicle's network through multiple file fragments per bus. For example, the descriptor file format may require styled comments or stub sections that provide necessary information but are not executed. In another 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). The DBC file or any other suitable pre-selected descriptor file format can be used by code generation software that utilizes the descriptor file format details. The code 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 the kernel and applications will be able to access the values ​​of messages or signals through a specified application programming interface (API) without any further work or integration. The code generation software can also handle variant management (e.g., as combined later). Figure 15 (As described). In some implementations, the code generation software may include a framework for providing automatic message redundancy (e.g., temporarily switching message sources when multiple sources are available). In some implementations, the code generation software may include patterns for replacing DBC files with new file formats.

[0093] The output of automatic code generation software can be a set of programming files designed to run on top of the application stack of a core (e.g., the core of an ECU) and / or run alongside the application. The generated programming files, written in one or more programming languages ​​(e.g., C, C++, Javascript, etc.), can be responsible for processing data (e.g., by generating files containing actual usable values), performing E2E verification on signal data, and sending signal data to other cores or applications. An E2E inspection module can be configured to verify individual messages given the running state of past messages. The E2E library can be written according to the Automotive Open Systems Architecture (AUTOSAR) specification. E2E inspection can provide one of the following values ​​required to verify signal messages: “error,” “normal,” “repeated,” “no new data,” or “error sequence.”

[0094] In some examples, the build system of the code auto-generation software can receive source DBC files (e.g., in fragment form including common parts and variants). The build system can then use a network framing aggregator to perform variant processing and DBC deserialization. The build system can use predefined network objects (e.g., describing the network through multiple file fragments per bus) and provided templates to generate runtime environment objects (e.g., as shown below). Figures 5 to 8 (The software agent is described in more detail in the text). The build system can also create aggregated DBC files.

[0095] The resulting software agent 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 memory required for performing critical tasks (e.g., preventing any unauthorized processes from accessing protected memory). For this purpose, memory (e.g., such as...) Figure 1 The code (as shown) can be divided into several parts (e.g., as defined according to ISO 26262): a QM memory section, which can be an unprotected, non-compliant level memory; and various levels of ASIL sections (e.g., ASIL AD), where each level of ASIL memory receives more protection. The code is automatically generated by the software. Figures 5 to 8 The code is explained further below.

[0096] Figure 5 The diagram illustrates exemplary software agents created by a code-generating software build system, which, when executed together, automatically provide E2E protection processing for received signals.

[0097] Specifically, tasks within the upper rectangle are executed by core 1 (e.g., at the top of the application stack on core 1). Lower-level tasks are executed by higher-level application tasks that depend on this signal. (As mentioned above...) Figure 4A As explained, the application task needs to be synchronized with the E2E protection task (to prevent the application from receiving E2E states corresponding to error messages). To this end, when a message is received (e.g., from core 0), it is read by the E2E task 502 on core 1 (e.g., using E2E library 503). The E2E task 502 on core 1 then writes both the signal and its E2E state in a form usable by the application. The E2E state can then be read by software using ASIL B 504 or ASIL D 505 memory protection levels, while the signal itself can be accessed by software using ASIL B 504, ASIL D 505, or QM 506 protection levels. Advantageously, all cross-core communication for each E2E message (e.g., as E2E checks) occurs on core 1, allowing support for higher levels of memory protection (e.g., at ASIL D level). Since all E2E computations occur within a single task, the application will also perform necessary actions to ensure that received information is synchronized when needed.

[0098] Figure 6 This illustrates another version of an exemplary software agent created by a build system for automated code generation software. These software agents, when executed together, automatically provide E2E protection processing for received signals. Figure 5 In contrast to the specific implementation of E2E, E2E checks are handled by the application. For example, E2E computations can be performed in the same context as code that consumes computation but requires tasks to run at the same rate as messages.

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

[0100] Figure 7 Show Figure 5Details of an exemplary implementation of the signal reception check described herein. Dashed fields represent code created by the build system of the code generation software. As shown, different code agents can reside in ASIL B701, ASIL D 702, and QM 703 partitions and can be executed together to ensure the app task and COM task (which may correspond to...) Figure 4A Synchronization between tasks described in the diagram. In this case, the code in the QM partition running the COM task receives messages via the FIFO 704 buffer and writes signals or messages in a format accessible to the code in the ASIL B 701, ASIL D 702, and QM 703 partitions. The code in ASIL B partition 701 can unpack the message and write signal data and E2E status. The application can then access these two values ​​synchronously. Similarly, the code in ASIL D 702 partition can unpack the message and write signal data and E2E status. The application can then access these two values ​​synchronously. Additionally, the code in ASIL D 702 can perform security tasks. The code in QM partition 703 may only make signal data available to the application, instead of E2E data.

[0101] Figure 8 Show Figure 5 The details of an exemplary implementation of the transfer process described herein. Dashed fields represent code created by the build system of the code generation software. As shown, different code agents can reside in ASIL B 801, ASIL D 802, and QM 803 partitions and can execute together to ensure the app task and COM task (which may correspond to...) Figure 4A Synchronization between tasks described in the diagram. In this case, the code in QM partition 803 running the COM task writes messages to FIFO buffer 804 based on signals provided by the code in ASIL B 801, ASIL D 802, and QM 803 partitions. The code in ASIL B partition 801 can package messages by combining signal data and E2E states. The code in ASIL B partition 801 can also package messages by combining signal data and E2E states. In addition, the code in ASIL D 802 can perform safety tasks. The code in the QM partition can only send signal data (not E2E states) to the COM task.

[0102] Some implementation schemes include, for example Figure 8The method shown in step a includes: in step 810, accessing a file containing information for decoding bus data; in step 820, generating a plurality of software agents based on the file, wherein the software agents, when executed, are configured to receive raw messages via the bus, unpack the raw messages to generate signal values, and generate security protection values ​​for the raw messages; and in step 840, if a request for the signal values ​​is received in step 830 from an instance of an application executing instructions in a protected memory location, providing synchronous access to the signal values ​​and security protection values. If no request is received at step 830, the method proceeds to step 850 and takes no action. In some implementations, generating multiple software agents includes: generating a first instruction set for execution from a first insecure memory partition, wherein the first instruction set, when executed, is configured to receive raw messages from a 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 messages to generate signal values, perform verification to generate security protection values ​​for the raw messages, store the signal values ​​and security protection values, and synchronously transmit the signal values ​​and security protection values ​​to an instance of the application; and generating a third instruction set for execution from a second insecure memory partition, wherein the third instruction set, when executed, is configured to unpack the raw messages to generate signal values ​​and transmit the signal values ​​to an instance of the application. In some implementations, the bus is a Controller Area Network (CAN) bus. In some implementations, the first insecure memory partition is a Quality Management (QM) partition. In some implementations, the protected memory partition is an Automotive Safety Integrity Level (ASIL) partition. In some implementations, generating security protection values ​​includes generating end-to-end (E2E) status.

[0103] In some implementations, different hardware or software modules may need to exchange one or more cryptographic keys (e.g., temporary keys) to encrypt messages sent between them. For example, vehicle TCM, VDM, and CGM (e.g., as...) Figures 1 to 3 As shown, it may be necessary to establish a secure communication channel between each pair of modules. However, the same technique can be used between any software or hardware modules that need to exchange keys.

[0104] In one approach, each module or node can have its own private / 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 9An exemplary prior art key exchange scenario is depicted. In this example, four nodes create pairwise symmetric communication keys (e.g., DEC keys, although any other suitable key can be used). As mentioned above, pairwise key generation typically requires six key exchanges, which is cumbersome. For example, for 20 nodes, 190 key pairs are needed. To overcome the problems of these existing methods, a scheme is provided based on generating temporary symmetric keys between nodes using a pre-shared key between a node and a server. This technique will be described for any two nodes and one server. In some examples, the CGM can act as the server, and the TCM and VDM can act as nodes. However, any other suitable server and any other suitable node can be used. In some implementations, the process can be repeated for other nodes that need to share the set key.

[0106] Figure 10 An improved key setting protocol based on symmetric keys is described, which can be used to set new symmetric keys among multiple nodes at runtime (or at any other time). This solution allows for the secure setting of new symmetric keys using only the previously established symmetric keys. This technique prevents eavesdropping and man-in-the-middle attacks. To deploy this solution, one node in the network can be designated as the key server, while the remaining nodes are designated 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 nodes to communicate with the server node and can also be used to create temporary keys for encrypting communication between nodes.

[0107] like Figure 10 As shown, Client 1 wishes to establish a secure channel with Client 2 by sharing a temporary symmetric key. Client 1 requests a symmetric key (e.g., a newly created temporary key) 1001 from a key server. In some implementations, this request includes the address of the target node for channel creation (e.g., Client 2's IP address) and a random number generated by Client 1 (e.g., a 16-bit number). The random number can be used as a challenge question for the server. For example, when responding using the key, the server can be expected to retransmit the response based on this number to help Client 1 verify the server by examining the received challenge response. This message can be sent unencrypted or encrypted using a pre-shared key between Client 1 and the server.

[0108] Before a predetermined time period expires, the server can respond to client 1 (1002) with a message including the newly set key and a response to the challenge. The newly set key can be created using any suitable key creation technique (e.g., as defined in the IEEE Std 1363-2000 standard). The response to the challenge can be a hash of the random number sent by client 1 (e.g., a hash of a password-based message authentication code). The message can also be padded to fit the encryption block size. The entire message can be encrypted using a pre-shared key for client 1 / server (e.g., using a password). In some implementations, the random number created by client 1 can be used as an 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 inform Client 2 that Client 1 wishes to initiate secure communication with Client 2 1003. This may be an unencrypted message (e.g., User Datagram Protocol (UDP)). This message can inform Client 2 (e.g., via bit fields) whether the channel requires encryption, authentication, or both. Client 2 now knows 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 1004 to the server for a temporary key. This request may 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-bit number). This message can be sent unencrypted or encrypted using a pre-shared key between Client 2 and the server.

[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 may include: (a) a response to a random number challenge (e.g., a hash of a random number generated by client 2); and (b) the same key set at client 1's request. The message may also be padded to conform to the encryption block size. The entire message may be encrypted using a pre-shared key (e.g., using a cipher) for client 2. In some implementations, the random number created by client 2 may be used as an initialization vector for the encryption algorithm.

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

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

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

[0115] Some implementations include a method for establishing secure communication between a first node and a second node within the vehicle (e.g., Figure 12 As shown in a), the method includes the following steps:

[0116] The system receives a first message from a first node of the vehicle, the first message identifying information about a second node of the vehicle 1210; in response to receiving the first message, generates an encryption key using the vehicle's processing circuitry 1220; transmits information identifying the encryption key to the first node of the vehicle 1230; receives a second message from the second node of the vehicle, the second message including information identifying the first node of the vehicle 1240; determines the validity of the second message based on the first message using the processing circuitry 1250; and transmits information identifying the encryption key to the second node of the vehicle 1260. In some embodiments, the first message also 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 also 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 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 and the transmission to the second node of the vehicle are performed via the shared bus.

[0117] Figure 13 Depicting methods for improving vehicles (e.g., Figure 1 An exemplary system for detecting failures in the circuits or components of a vehicle (as depicted in the image). For example, failure detection can be performed by a server 1300 (e.g., such as...). Figure 2(As depicted in the image) In some implementations, 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 the vehicle manufacturer. For example, the server can communicate continuously or periodically with each vehicle in the fleet using the network circuitry of the server and the fleet (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 collecting ECU measurements from a group of vehicles, the server can store the measurement data in its database. The server can then analyze the measurements against thresholds and determine the frequency of a particular problem (e.g., a fault) occurring throughout the fleet, as well as the correlation between that fault and the measurement. By tracking this information, the server may be able to provide early failure detection in the vehicles. In some implementations, the server may transmit an early warning 1306 to the vehicles, indicating a fault and urging repair or another appropriate action.

[0119] For example, a server can collect sensor data for each ECU of each vehicle to record motor load, battery status or charging, coolant temperature, motor temperature, motor RPM, airflow, any other suitable metrics, or any combination thereof. Further sophisticated ECU metrics may include current and average processor load, any processor failures, 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 components of the motor, such as the age and performance of any motor parts. The server can also receive software crash or malfunction reports from each vehicle in the fleet. The server can correlate the occurrence of a crash with the vehicle's status and metric history at or before the crash. This correlation may become stronger as more crash or malfunction reports are received from other vehicles. For example, aging or poor performance of a motor component may be correlated with an impending failure. In some implementations, vehicles can report information to the server to both analyze the findings of correlations and receive fault warnings about the correlations themselves. That is, vehicles 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), it can transmit an impending fault warning to the vehicle whose part condition is relevant to the fault. In some implementations, warnings can be sent based on the correlation of any metric or combination of metrics with a specific fault. Warnings may include notifications about which part of the vehicle requires repair or replacement. The server can similarly collect and generate data for any other module of the vehicle.

[0120] In some implementations, the server may utilize a machine learning model (e.g., a neural network) to predict faults. In such implementations, the server trains the machine learning model with known metric states that lead to faults. Once trained, the machine learning model can take the vehicle's current metrics (e.g., ECU metrics) as input and output whether an impending fault is likely. If a fault is likely, the server can send an appropriate notification to the vehicle. In some implementations, the model is repeatedly updated as the server collects new data. In some implementations, the model resides on a remote server.

[0121] In some implementations, the notification to the vehicle can indicate an anticipated malfunction. In some implementations, the notification can indicate the range within which the anticipated malfunction may occur. This range can be in miles, hours, or any other relevant unit. For example, a server could warn the vehicle that it may overheat within 20 miles based on the detected state of battery or motor components. In another example, a server could warn the vehicle that its headlights may go out within 12 hours based on the identified state of lights or other circuitry associated with the vehicle. In some implementations, the notification can describe a correlation. For example, this could indicate that the vehicle has traveled 65,000 miles, suggesting that the motor is likely to require maintenance.

[0122] In some implementations, the notification may include a percentage probability of a failure occurring. For example, the server may warn of a 40% chance of battery failure in a vehicle. In some implementations, the notification may include an indication of severity, such as a color change or animation visible to the driver on a vehicle display, or the indication may be transmitted to a user-associated mobile device (e.g., a mobile phone with a mobile application associated with the server installed). For example, an urgent risk might be displayed as red and flashing, while a minor risk might be displayed as yellow. Severity can be assessed, for example, based on probability and potential hazard or inconvenience. In some implementations, the server may cause changes to the vehicle's operating parameters to avoid or mitigate the failure. Such changes may be performed wirelessly on the vehicle by a remote server using software or other updates.

[0123] In some implementations, the server can receive data from sources other than the vehicle. For example, the server can communicate with a system that provides data such as weather, traffic patterns, vehicle geolocation, altitude, route, and driver profiles. The server can then incorporate this additional data into a fault correlation analysis. For example, the server might discover that a fault (such as battery performance) is correlated with external temperature. Then, after receiving a weather forecast for the next few hours, the server might warn the vehicle of a potential fault. For example, in cases where battery performance is temperature-dependent, the server might learn that the temperature may drop below a threshold that would damage battery performance. The server could then warn of the impending change or the likelihood of impending performance degradation. Alternatively, the server might discover, for example, that another fault is common during frequent stops and receive information about upcoming traffic. The server can learn that traffic ahead may lead to frequent stops. In that case, the server could similarly warn of a potential vehicle failure. In another example, the server might discover that vehicles at a particular geographic location are highly correlated with a specific fault and only issue a warning for that specific fault to vehicles at that location. In some implementations, the server can suggest an action. For example, in scenarios where traffic patterns might increase the risk of failure, the server might communicate a recommended alternative route to the system.

[0124] Some implementation schemes include a method for predicting malfunction events in a vehicle (such as...) Figure 13 (As shown in a), the method includes, in step 1310, using processing circuitry to monitor multiple operating parameters of the vehicle and the vehicle's geographic location. In step 1320, when the processing circuitry determines that the values ​​of the operating parameters and the geographic 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 group of vehicles and the corresponding geographic locations of those vehicles experiencing the corresponding fault event, in step 1330, the processing circuitry causes an action to be performed in response to the determination. If no correlation is detected, the method proceeds to step 1340 and takes no action. Some embodiments also include transmitting the vehicle's operating parameters and geographic location to a remote server, wherein determining that the values ​​of the operating parameters and the geographic 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 an action includes causing a notification indicating a fault event to be provided. In some embodiments, causing an action includes causing a change in at least one of multiple operating parameters to avoid a fault event. In some embodiments, causing an action 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 group of vehicles.

[0125] Figure 14 Depicting for use with vehicle systems (e.g., such as Figure 1 (As shown) An exemplary system that facilitates crash recovery (e.g., ECU crash). For example, the system can handle situations where the ECU locks up and becomes unresponsive, thus preventing the entire core from being reset in an unrecoverable trap or by another module (e.g., as shown). Figure 3 (As shown) Data is subsequently lost. In these cases, the system avoids hard-powered cycles and instead suffers "soft" or "hot" crashes. Therefore, the contents of volatile memory can be preserved.

[0126] like Figure 14 As shown, an exemplary system for a vehicle may include a core having a processor 1401, a conventional random access memory (RAM) memory 1402 (in... Figure 14 (labeled as "main memory") and dedicated spare RAM memory 1403 (in Figure 14 (This is labeled "backup memory"). In some implementations, the backup RAM may be part of the conventional RAM. In some implementations, the backup RAM may be dedicated circuitry. The vehicle's operating system (OS) may include instructions specifically for low-level faults (e.g., low-level ECU failure), bad codes, memory protection failures, or watchdog trigger events. The processor may take a snapshot of system information and store it in the backup RAM. To this end, the system may retain a portion of the RAM within the linker structure that is not cleared between startups.

[0127] In some implementations, the processor can protect data by calculating a Cyclic Redundancy Check (CRC) code 1404 for snapshot blocks acquired and stored in spare RAM 1403 after a crash. This allows the CRC check 1404 to be performed upon reboot to verify the data's validity. The data can then be reported via the Controller Area Network (CAN) bus or the 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 non-volatile memory and / or external systems (e.g., another core or microcontroller).

[0128] In some implementations, non-volatile memory (NVM) can be used to store snapshots. This way, a buffer containing crash information is not erased on subsequent boots, but instead copied to NVM. For example, the kernel may 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 implementations, stack overflows in the watchdog module can be redirected to a non-maskable interrupt handler.

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

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

[0131] In some implementations, snapshots may be packaged binaries obtainable via a service such as the Unified Diagnostic Services (UDS) protocol using a UD client. The binary file may include header files with defined functions. The data can then be unpacked into a human- or system-readable format using Python tools. In some implementations, the system may acquire snapshots during normal operation (e.g., periodically or based on system or user requests) to provide additional management tools. In some implementations, snapshot data may be collected from the entire fleet and used to predict failures in other vehicles, for example, as... Figure 13 As stated above.

[0132] Some implementation schemes include a method for storing information about the vehicle (e.g.) Figure 14(as shown in a), the method includes: detecting a fault event 1410 by processing circuitry; and in response to the detection: generating information about the vehicle by processing circuitry 1420 when the fault event occurs; generating integrity data 1430 by processing circuitry based on the information; causing processing circuitry to store the information about the vehicle and integrity data in a portion of volatile memory, wherein the portion of volatile memory is configured to retain the stored data during a restart of the vehicle's operating system 1440; causing the vehicle's operating system to restart using processing circuitry 1450; after the restart, verifying the information stored in volatile memory based on the integrity data using processing circuitry 1460; and in response to the verification, causing information about the vehicle to be stored in non-volatile memory 1480. In some embodiments, the integrity data includes 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 information and 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 implementations, the generation of information, the generation of integrity data, and the storage of information and integrity data are performed by an emergency stack, which is programmed to perform in the event of a failure.

[0133] Some implementations include a system for storing information about a vehicle, the system comprising: an operating system for the vehicle; a fault event; information about the vehicle at the time the fault event occurs; integrity data generated based on the information about the vehicle at the time the fault event occurs; and 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 that 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, information about the vehicle is verified based on integrity data, and wherein in response to this verification, the information about the vehicle is stored in the non-volatile memory. In some embodiments, the integrity data includes Cyclic Redundancy Check (CRC). In some embodiments, the volatile memory includes Random Access Memory (RAM). In some embodiments, this portion of the volatile memory is a dedicated portion of the volatile memory reserved for information and integrity data. In some embodiments, detecting fault events includes detecting system crashes. In some embodiments, the information includes a snapshot of the software state in the vehicle. Some embodiments include an emergency stack programmed to generate information, generate integrity data, and cause the storage of information and 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, which, when executed by a processor, cause the processor to: detect a fault event by processing circuitry; and in response to the detection: generate information about the vehicle by the processing circuitry when the fault event occurs; generate integrity data by the processing circuitry based on the information; cause the processing circuitry to store the vehicle-related information and 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; cause the processing circuitry to restart the vehicle's operating system; after the restart, verify the information stored in the volatile memory based on the integrity data by the processing circuitry; and in response to the verification, cause the vehicle-related information to be stored in non-volatile memory. In some embodiments, the integrity data includes 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 information and integrity data. In some embodiments, detecting a fault event includes detecting a system crash. In some implementations, the information includes snapshots of the software state in the vehicle.

[0136] Figure 15 Describes the use of microcontrollers for managing microcontrollers (e.g., Figures 1 to 3 The example system is a version of the database (DBC) file of the microcontroller of the vehicle depicted in any of the figures. The DBC file can be a definition file conforming to the SAE J1939 standard. The DBC file can also be a definition file in a special format, as shown in Figures 4 to 5. Figure 8 The DBC file can be used to provide data from peripheral devices (e.g., from the pump brake module, engine module (such as the ECM), or any other peripheral device or sensor in the vehicle) via the Controller Area Network (CAN) bus. DBCs are typically in a format that must be decoded. For example, data from a DBC might be displayed in the format shown in Table 1:

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

[0138] Table 1

[0139] This data can be decoded to receive values ​​for certain defined parameters. For example, a DBC file received from a pump brake system can define a depression angle value. In another example, a DBC file received from an engine system can define values ​​including manifold temperature and motor revolutions per minute. The conversion from binary DBC data to usable values ​​can be performed by an interface file that accepts data via a CAN or Ethernet bus.

[0140] In one approach, a single interface file is dedicated to processing a specific DBC file from a peripheral device (e.g., a pump brake module). However, if a physical modification to the pump brake hardware is required to handle a different pump brake, this necessitates a complete replacement of the interface file to accommodate the new version of the peripheral device. This approach fails to leverage the commonalities between different versions of the peripheral device's DBC files, thus preventing the use of shared portions of still-usable interface files and necessitating entirely new interface files. This can lead to significant delays in acquiring and installing the new interface file. Furthermore, changes to the interface file may require system-wide modifications that depend on data from the DBC file interpreter. Therefore, a change to a single peripheral device may necessitate changes to the entire architecture of the vehicle (or another system).

[0141] To overcome the problems of the above methods, a specific implementation of a vehicle architecture is provided that maintains identical application code across the entire system board while providing different interfaces based on vehicle type, vehicle architecture, or replacement of specific peripherals. For example, different versions of vehicles may require different interfaces. In another example, replacing peripherals may result in the need for a new version of the DBC interpreter interface. In one example, the vehicle may receive, for example, new pump brake hardware that requires a new interface file.

[0142] In some implementations, the vehicle's operating system can detect the presence of a new peripheral device (e.g., a new pump brake) by detecting build configuration events. The operating system can then pull in a new interface file to flash into the vehicle's hardware. For example, the operating system can identify associations between source files and vehicle software components (e.g., associations between data from the new pump brake and applications that process pump brake input and / or any applications that operate using data from the pump brake). The operating system can then combine the associated source files in the root directory and generate at least one interface abstraction layer for vehicle software components (e.g., an ECU that may require pump brake data) based on the combined source files.

[0143] For example, a pump brake module can provide a DBC file that provides the brake pedal depression angle value. However, because different brakes have different "yields," other parts of the vehicle (e.g., the ECU or TCM) may handle the same angle change of the brake depression angle value in completely different ways. To address this issue, the system can provide an abstraction layer 1506 between DBC interpretation via an associated interface and 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 instance, for one type of pump brake, a 5-degree change represents an expected reduction of 5 MPH, while for another type of pump brake, a 5-degree change represents an expected reduction of 7 MPH. If all software related to braking action is programmed to depend on the expected speed change measure, an abstraction layer can be provided that converts the DBC data from the pump brake into the expected speed change measure before providing that data to other applications. This allows for easy changes to the pump brake interface version without requiring any additional changes to the rest of the system. Similar abstraction can be used for any other values ​​provided by the DBC file. Therefore, abstract information can be processed without considering data generated by new hardware components.

[0144] Interface version updates can be provided by Figure 15 The system is executed as 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 up runtime controls, retrieving runtime controls, and erasing runtime controls). These operations may be protected by CRC. The UDS server enables a computer 1502 (e.g., a computer or a dedicated tester tool) referred to as a UDS client to connect to the vehicle (e.g., via the UDS interface). The UDS client 1502 can be configured (e.g., via an external network such as the Internet) using the vehicle's coded runtime profile. The coded runtime profile 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 may use non-volatile memory and optionally one or more additional libraries (such as a power-down recovery application) to decode the runtime profile 1503. As a result, additional decoded runtime configurations 1505 can be added to the variant library memory. Applications (e.g., ECM applications) can then request the required configuration from the library during runtime. Optionally, an abstraction layer may exist that is available to the application and can access abstract data instead of the raw values ​​from the DBC file.

[0145] In some implementations, instead of discrete versions, variant libraries can define differences in runtime instructions across different versions. For example, certain parts of the code might be obfuscated to implement different versions. In some specific implementations, the build system can access vehicle generation information and use that information to identify hardware differences. For example, different interface IDs for the battery or HVAC might be accessible. Conversely, if a vehicle model-specific configuration is used, the system might identify which parts of the vehicle differ. 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 using abstractions). This functionality can be achieved using a new Local Interconnect Network (LIN) table. In another implementation, a scheduler table can be used for runtime switching. For example, the same binary can be loaded into all vehicles, and the system can select the correct code at runtime and ignore code that is relevant to other configurations.

[0146] In some implementations, runtime configuration options can replace build-time configuration options. For example, in this way, a single binary can be used for all vehicle variants. This variant library can set all other configuration options. A 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. Because wheel size affects vehicle dynamics, it has a predefined impact on the vehicle dynamics module software, potentially affecting all software. Wheel size can be abstracted in the software and made available to all modules that rely on wheel size to perform their functions.

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

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

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

[0150] Some implementations include a method for updating a vehicle when installing new hardware components (such as...). Figure 15(as shown in a), the method includes: detecting a new hardware component using processing circuitry in the vehicle in step 1510; identifying an association between data generated by the new hardware component and at least one software component of the vehicle using the processing circuitry in step 1520; determining in step 1530 whether an updated interface is needed; and if so, generating an updated interface for interpreting data from the hardware component using the processing circuitry in step 1540, wherein the updated interface converts the 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. If an updated interface is not needed in step 1520, the method proceeds 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, 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 having at least one software component of the vehicle process the abstract information without considering the data generated by the new hardware component. In some embodiments, the updated interface is used for bidirectional communication between at least one software component and the new hardware component. In some implementations, generating an updated interface involves modifying an existing interface.

[0151] Some implementations include a system for updating a vehicle upon installation of new hardware components, 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 implementations, the data generated by the new hardware component includes a database (DBC) file. Some implementations include an interface library storing updated interfaces. Some implementations include identification of the new hardware component, wherein an updated interface is selected from the library based on the identification of the new hardware component. In some implementations, the abstract information is processed by at least one software component of the vehicle, regardless of the data generated by the new hardware component. In some implementations, the updated interface is used for bidirectional communication between at least one software component and the new hardware component. In some implementations, 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, which, when executed by a processor, cause the processor to: detect a new hardware component using processing circuitry in the 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 the 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, regardless of the data generated by the new hardware component. In some embodiments, the updated interface is used for bidirectional 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 described. Specifically, this 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 a bus 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 peripheral devices and memory without using a CPU.

[0154] In an exemplary vehicle (e.g., such as) Figures 1 to 3 As depicted in the diagram, multiple nodes (e.g., ECUs) can be connected to the bus 1600 (e.g., CAN bus or any other multi-master bus), such as... Figure 16 As shown. Figure 16 Each circle in the diagram can represent node 1601, 1602, etc. Typically, individual nodes (e.g., ECUs) may need to know a time metric that is consistent across the bus. In one approach, a single node can be designated (e.g., randomly) as a "time server." This time server node can then broadcast its internal clock across the bus. All other nodes then receive this broadcast message and synchronize their internal clocks with it.

[0155] However, this previous solution did not consider the time delay between the point at which the time server sets the time on the bus message and the time when the receiving node finally receives and processes that message. This delay can be caused by several variable sources of delay. Sources of delay can include the time required for time synchronization broadcasts to pass through the server's software stack before they can be transmitted via the hardware bus. Sources of delay can include the time spent propagating the message along the bus line (which may be indeterminate in a bus management system using an arbitration protocol). Sources of delay can include the time required for the client's software stack to process the received message before the client can access the time value. For these reasons, when a client updates its internal clock to the time it just received in the bus message, it is synchronizing with a past time. In this approach, 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), however, other nodes may want precise and tight time synchronization with the server node (1601) (e.g., node 1604).

[0156] Another time synchronization method is described using the Simple Network Time Protocol (SNTP) (RFC 1769, https: / / datatracker.ietf.org / doc / html / rfc1769), the full text of which is incorporated herein by reference. In this method, the client sends its local time to the time server in a synchronization message. The server responds with 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 a timestamp) and adjust its clock accordingly for 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. Furthermore, some nodes may not require tight synchronization, in which case they can still clutter the bus with completely unnecessary synchronization messages.

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

[0158] The message may experience server stack latency, line latency, and client stack latency before being processed by the time client node, which can modify the message by adding a target timestamp when it is received. For example, the target timestamp could have a value of "60ms". The node can then calculate the difference between the transmission timestamp and the target timestamp to adjust its clock. For example, the node could adjust its clock to "47.5ms" for loose synchronization. The client node can perform this synchronization whenever appropriate (e.g., every time it receives a synchronization message from the server or when only some broadcast messages are used).

[0159] Figure 17 The diagram illustrates the interaction between nodes requiring close synchronization and the same server. In this scenario, the server may also continuously (e.g., periodically, or at other specific intervals) transmit (e.g., by broadcasting on the bus) messages including the server's internal time. However, the server may also consider synchronization requests sent by nodes via the bus.

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

[0161] When a time server receives such a request, it can modify its next periodically sent time update message. In some implementations, the server may receive several closely spaced synchronization requests before the next update message. In this case, the server may 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 "originating" field. For example, the "originating" field could include the value "56.5". The server may also include a timestamp 1702, which indicates when a message sent by a node was received by the server using the server's clock. For example, the "received" field could have the value "60". The server will then send the update message (e.g., at the originally scheduled time or immediately), where the update message will include the transmission time based on the server's clock. For example, the transmission value could be set to "60.5".

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

[0163] Specifically, tight synchronization can be performed by calculating the round-trip delay 1801, for example, where the round-trip delay = ("target" value 1802 - "originating" value 1803) - ("receive" value 1804 - "transmit" value 1805), as follows. Figure 18 As shown. That is, the client node can calculate and subtract the delays between server reception and server transmission, and between node transmission and node reception. The node can also calculate the clock offset 1806 by averaging the following: (a) the time difference between the "originating" 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). Round-trip delays 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 perform close server synchronization using the same messages from the server (because their transmitted values ​​will be identical).

[0164] Additionally, in some implementations, nodes can store a history of calculated clock skew and round-trip delays. If the history indicates a stable mode, the node can reduce the frequency of its close synchronization requests or stop sending close synchronization requests altogether, and can rely on historical values ​​to perform synchronization. This can further reduce congestion on the bus (e.g., a CAN bus).

[0165] Some implementation schemes (such as) Figure 18AThe diagram shows a method for tight synchronization between a first client, a second client, and a time server (each of which is associated with a corresponding local clock and connected to a bus), the method comprising the steps of: generating a periodic synchronization message 1810 to be transmitted via the bus by the time server; receiving the synchronization message via the bus at the time server, the synchronization message including a request for tight synchronization from the first client 1820; in response to receiving the synchronization message, adjusting the periodic synchronization message based on the tight synchronization request by the time server, by adjusting the next periodic synchronization message to include: (a) a first time, the first time indicating when the first client transmits the synchronization message; (b) a second time, the second time indicating when the server receives the tight synchronization request; and (c) a third time, the third time indicating when the time server sends the periodic synchronization message 1830; performing tight synchronization by the first client based on the adjusted periodic synchronization message 1840; and performing loose synchronization by the second client based on the adjusted periodic synchronization message 1850.

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

[0167] Unit testing is an integral part of safety software development. For example, the ISO 26262 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 considered during device testing.

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

[0169] In one example, a first function on a first device might require the output of a second function generated by a second device. In this case, to thoroughly test the operation of the first function on the first device, it would be beneficial to test every possible output that the second function, generated by the second device, can provide. To achieve this, the second device could use code flashing, where the second function is replaced with a dummy function (also called a stub function or mock function) that only provides the value set by programming, or runs through each possible output without providing the real functionality. For example, a TCM might have a function that requires the revolutions per minute (RPM) value from the ECM. In this case, it might be beneficial to spoof the RPM setting function on the ECM when testing the TCM software, which iterates through each possible RPM value. However, this means that the ECM used to test the TCM must eventually re-flash images with images used for testing other functions, or real images including real functions that return real RPM values. This process of creating and re-flashing multiple binary images can be tedious and can lead to errors if the wrong images are used.

[0170] One approach is to use function overloading. 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, many embedded systems do not accept code compiled from such languages ​​and may accept code from languages ​​that do not support overloading (e.g., the C programming language).

[0171] When using such languages, for any given image, there may only be one copy of a function. This means that if a function needs to be stubbed for a dummy 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 a stub function, it cannot coexist in the same image as the previous unit. In practice, this means that multiple images must be compiled for different units under test. The process of flashing these multiple images to the target hardware and collecting the results is very cumbersome.

[0172] To overcome this problem, a method is provided to compile all the necessary images (including real images and all images with stub functions) separately into assembly code. The assembly code is then 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 flash memory to be used for a single file across all testing and production environments.

[0173] This solution requires no additional technologies on top of the language, no function overloading (e.g., in the C programming language), and imposes no constraints on the target hardware. For example, it does not require a memory management unit, a new operating system, or a different programming language. This solution is broadly applicable to all types of suitable hardware and can significantly improve the efficiency of target unit tests. Furthermore, this solution promotes isolation between unit tests, a core responsibility of proper unit testing and one that has been difficult to achieve to date using languages ​​without function overloading.

[0174] The following steps can be used to perform a method for creating a superimage based on compiled images. Each unit test code that requires stub functions is compiled into a single image. Then, as many different images as possible are compiled for the final test suite. All compiled images are fed into a large image creation program (MICP). For each image, MICP locates its position in memory so that it does not conflict with the memory requirements of other images. Then, for each image, MICP adjusts the machine instructions within it to reflect the new final address locations. Next, as part of the final large image creation, MICP creates an entry point table for each sub-image within the large image, as well as for the unit test framework, 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 quickly execute target unit tests lowers their entry barriers, making it easier to obtain ISO26262 ASIL certification and allowing for faster production of ASIL-level software.

[0176] Figure 19 The example code for the second unit used to test the first unit is shown. The code for the second unit may include code for function 2, which is a real function that can produce variable output.

[0177] Figure 20 The example code for the first unit being tested is shown. It can be seen that function unit 32_t_to_test_one includes a function call to Function 2 at line 111. As mentioned above, it might be advantageous to replace the real function Function 2 with a stub function or a pseudo function that returns a value set by the programmer (e.g., iterating through all possible outputs).

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

[0179] The system and methods described in this article are not limited to testing applications. The system can be used wherever function overloading is beneficial, including for readability, memory saving, and other purposes.

[0180] Some implementations may include a method for function overloading (such as...) Figure 21 (as shown in figure a), the method includes: compiling a first image 2110 of a first version of a function; compiling a second image 2120 of a second version of a 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 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 generating a table 2130 for selectively calling either the first version of the function or the second version of the function. In some embodiments, the first version of the function and the second version of the function are written in code that does not allow function overloading. In some embodiments, the first version of the function 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 a corresponding memory address for each of the first version of the function 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 this disclosure, and various modifications can be made by those skilled in the art without departing from the scope of this disclosure. The above embodiments are presented for illustrative purposes and not for limitation. This disclosure may also take many forms other than those expressly described herein. Therefore, it should be emphasized that this disclosure is not limited to the methods, systems, and apparatus expressly disclosed, but is intended to include variations and modifications thereof, which are within the spirit of the following paragraphs.

Claims

1. A method for function overloading, the method comprising: Compile a first image including first assembly code, the first assembly code defining a first version of the function stored at a first memory address; Compile a second image including second assembly code, the second assembly code defining a second version of the function stored at a second memory address; as well as The stitched super-image is generated through the following operations: The first assembly code and the second assembly code are placed in a memory partition, wherein the second assembly code is adjusted to not conflict with the first assembly code, and a table is generated in the memory partition for selectively calling either the first version or the second version of the function.

2. The method according to claim 1, wherein the first version of the function and the second version of the function are written in code that does not allow function overloading.

3. The method of claim 1, wherein the first version of the function and the second version of the function are written in C code.

4. The method of claim 1, wherein the memory partition is located inside the vehicle.

5. The method of claim 1, wherein the table defines a corresponding memory address for each of the first version and the second version of the function.

6. The method of claim 1, wherein the stitched super-image within the memory partition is configured for all testing and production.

7. The method of claim 1, further comprising invoking each of the first version and the second version of the function in the stitched superimage based on the table.

8. A system for function overloading, the system comprising: The memory, including memory partitions, Processing circuitry, coupled to the memory and configured to: Compile a first image including first assembly code, the first assembly code defining a first version of the function stored at a first memory address; Compile a second image including second assembly code, the second assembly code defining a second version of the function stored at a second memory address; as well as The stitched super-image is generated through the following operations: The first assembly code and the second assembly code are placed in the memory partition, wherein the second assembly code is adjusted to not conflict with the first assembly code, and Generate a table for selectively invoking either the first version or the second version of the function.

9. The system of claim 8, wherein the first version of the function and the second version of the function are written in code that does not allow function overloading.

10. The system of claim 8, wherein the first version of the function and the second version of the function are written in C code.

11. The system of claim 8, wherein the memory partition is located within the vehicle.

12. The system of claim 8, wherein the table defines a corresponding memory address for each of the first version of the function and the second version of the function.

13. The system of claim 8, wherein the stitched super-image within the memory partition is configured for all testing and production.

14. The system of claim 8, wherein the processing circuitry is further configured to invoke each of the first version and the second version of the function in the stitched superimage based on the table.

15. A non-transitory computer-readable medium for function overloading, the non-transitory computer-readable medium having non-transitory computer-readable instructions encoded thereon, the non-transitory computer-readable instructions causing the processor, when executed by a processor, to: Compile a first image including first assembly code, the first assembly code defining a first version of the function stored at a first memory address; Compile a second image including second assembly code, the second assembly code defining a second version of the function stored at a second memory address; as well as The stitched super-image is generated through the following operations: The first assembly code and the second assembly code are placed in a memory partition, wherein the second assembly code is adjusted to not conflict with the first assembly code, and Generate a table for selectively invoking either the first version or the second version of the function.

16. The non-transitory computer-readable medium of claim 15, wherein the first version of the function and the second version of the function are written in code that does not allow function overloading.

17. The non-transitory computer-readable medium of claim 15, wherein the first version of the function and the second version of the function are written in C code.

18. The non-transitory computer-readable medium of claim 15, wherein the memory partition is located within the vehicle.

19. The non-transitory computer-readable medium of claim 15, wherein the table defines a corresponding memory address for each of the first version and the second version of the function.

20. The non-transitory computer-readable medium of claim 15, wherein the stitched super-image within the memory partition is configured for all testing and production.

Images