Multi-ECU (Electronic Control Unit) node parallel flashing architecture and AUTOSAR-based flashing architecture

Abstract

The invention discloses a multi-ECU (electronic control unit) node parallel flashing architecture and an AUTOSAR (advanced open time synthetic aperture radar)-based flashing architecture. The architecture comprises a flashing control module, a diagnosis module and a protocol data unit layer. And the flashing control module dynamically updates the flashing process function of each ECU node according to the polling result of the diagnosis module, generates protocol data in combination with the flashing context function, and sends the protocol data to the diagnosis module. And the diagnosis module encapsulates the protocol data into a plurality of interaction protocol data and sends the interaction protocol data to each ECU node in parallel. The diagnosis module comprises a parallel state machine bound with the ECU node state, a service packaging interface and a node diagnosis configuration list, and supports multi-protocol adaptation and heterogeneous ECU parallel flashing. By implementing the invention, the flashing efficiency and compatibility of the vehicle-mounted system can be improved.

Description

Technical Field

[0001] This invention relates to the field of automotive communication, and in particular to a multi-ECU node parallel flashing architecture and an AUTOSAR-based flashing architecture. Background Technology

[0002] In modern automotive electronic systems, with the increasing complexity of the vehicle's electronic architecture, the vehicle typically contains multiple ECUs (Electronic Control Units), such as the engine control unit, body control module, ABS controller, and battery management system. To improve vehicle performance, fix software defects, or add new functions, these ECUs need to be updated (i.e., "re-flashed").

[0003] Traditional ECU flashing methods typically employ serial flashing, meaning that each ECU node is flashed one by one. This method has the following problems: low efficiency: each ECU must wait for the previous one to complete before it can begin, resulting in a long overall flashing time; low resource utilization: CAN bus or Ethernet communication resources are not fully utilized; slow system response: it is difficult to meet the high-efficiency requirements of OEMs in production line flashing or after-sales OTA upgrades. Summary of the Invention

[0004] This invention provides a multi-ECU node parallel flashing architecture and an AUTOSAR-based flashing architecture, which can realize independent management of the status of each ECU node, dynamic scheduling of the flashing process, and parallel encapsulation of communication protocols, thereby improving flashing efficiency and system stability.

[0005] To achieve the above objectives, a first aspect of this application provides a multi-ECU node parallel flashing architecture, comprising:

[0006] Flashing control module, diagnostic module, and protocol data unit layer;

[0007] The flashing control module updates the flashing process function corresponding to each ECU node based on the polling results of each ECU node of the diagnostic module; the flashing control module generates protocol data based on several flashing process functions and flashing context functions, and sends the protocol data to the diagnostic module; the input parameters of the flashing process functions are the ECU node state machine parameters; the flashing context functions are set according to a preset flashing process.

[0008] The diagnostic module encapsulates the protocol data into several types of interactive protocol data and sends these types of interactive protocol data in parallel to the protocol data unit layer; each type of interactive protocol data corresponds to an ECU node.

[0009] In one possible implementation of the first aspect, the diagnostic module includes several parallel state machines, service encapsulation interfaces, and a node diagnostic configuration list bound to the flashing state of a corresponding ECU node; the node diagnostic configuration list includes flashing parameter items for each ECU node.

[0010] The diagnostic module generates polling results for each ECU node based on the polling results of the plurality of state machines;

[0011] The diagnostic module encapsulates the protocol data into several types of interactive protocol data based on the node diagnostic configuration list.

[0012] In one possible implementation of the first aspect, the service encapsulation interface includes a diagnostic session service unit, a request download unit, a data transmission unit, and a secure access unit.

[0013] In one possible implementation of the first aspect, the node diagnostic configuration list includes Tx channel parameters, Rx channel parameters, and timeout parameters for each node.

[0014] In one possible implementation of the first aspect, the flashing context function includes the current state of each ECU node, the next state of each ECU node, the flashing function pointer of each ECU node, and the BIN file data address of each ECU node.

[0015] In one possible implementation of the first aspect, the write control module updates the status of the corresponding node or executes the next write process based on the response results of each node.

[0016] In one possible implementation of the first aspect, the write control module updates the state of the corresponding node or executes the write process for the next state based on the response results of each node, specifically including:

[0017] When the write control module receives a negative response from a node, it resets the node state of the corresponding node.

[0018] In one possible implementation of the first aspect, the flash control module updates the state of the corresponding node or executes the next flash process based on the response results of each node, specifically including:

[0019] The write control module receives a successful response from the node and the corresponding node's state is ready to proceed, then executes the write process for the next state.

[0020] In one possible implementation of the first aspect, before the write control module updates the corresponding node status or executes the next write process based on the response results of each node, it further includes:

[0021] According to the ECU node sending message information and the ECU node receiving message information, the response result of the ECU node is obtained.

[0022] The second aspect of the embodiment of the application provides a brush writing architecture based on AUTOSAR, which comprises an application layer comprising the brush writing control module, an interaction layer comprising the diagnostic module and the protocol data unit layer, a network layer, a data link layer and a physical layer; the application layer, the interaction layer, the network layer, the data link layer and the physical layer are sequentially connected end to end.

[0023] Compared with the prior art, the brush writing control module dynamically updates the brush writing process function corresponding to each ECU node according to the polling result of the diagnostic module on each ECU node, and then generates protocol data by combining the brush writing process function and the preset brush writing context function, and sends the protocol data to the diagnostic module. Since the brush writing process function is dynamically updated according to the polling result of each ECU node, the architecture supports dynamic interruption of single-node brush writing and retains the failure state thereof for subsequent diagnosis or rebrushing. Moreover, the brush writing process is dynamically adjusted based on real-time polling results, so that it can adapt to state changes in complex scenarios; the node state and data pointer are managed by the brush writing context function, so that intelligent process jumping and resource binding are realized.

[0024] The diagnostic module encapsulates the protocol data generated by the brush writing control module into a plurality of interactive protocol data and sends them to the protocol data unit layer in parallel; each interactive protocol data corresponds to an ECU node and adapts to the communication protocol and parameter configuration thereof. Each interactive protocol data is independent, so that in the parallel brush writing process, any node exception (such as response timeout or verification failure) will not affect the brush writing process of other ECU nodes. In addition, the diagnostic module can modify the internal service encapsulation interface, thereby supporting multi-protocol adaptation (such as UDS, DoIP, etc.) and being compatible with ECU nodes of different manufacturers. BRIEF DESCRIPTION OF DRAWINGS

[0025] Figure 1 is a structural schematic diagram of a multi-ECU node parallel brush writing architecture provided by an embodiment of the application;

[0026] Figure 2 is a structural schematic diagram of a brush writing architecture based on AUTOSAR provided by an embodiment of the application. DETAILED DESCRIPTION

[0027] With reference to the accompanying drawings, the technical solutions in the embodiments of the present application will be described clearly and completely. Obviously, the described embodiments are only a part of the embodiments of the present application, but not all the embodiments of the present application. Based on the embodiments in the present application, all the other embodiments obtained by a person of ordinary skill in the art without creative work fall within the protection scope of the present application.

[0028] To solve the above problems, please refer to Figure 1 An embodiment of the present application provides a multi-ECU node parallel flashing architecture, comprising a flashing control module 1, a diagnosis module 2 and a protocol data unit layer 3.

[0029] The flashing control module 1 updates the flashing process function corresponding to the ECU node according to the polling result of each ECU node of the diagnosis module 2; the flashing control module 1 generates protocol data according to a plurality of flashing process functions and a flashing context function, and sends the protocol data to the diagnosis module 2; the input parameter of the flashing process function is an ECU node state machine parameter; the flashing context function is set according to a preset flashing process.

[0030] The diagnosis module 2 encapsulates the protocol data into a plurality of interactive protocol data, and sends the plurality of interactive protocol data to the protocol data unit layer 3 in parallel; each interactive protocol data corresponds to an ECU node.

[0031] The flashing control module 1 dynamically updates the flashing process function corresponding to each ECU node according to the polling result (such as the current state, the communication state, the flashing progress, etc.) of each ECU node of the diagnosis module 2; the protocol data is generated by combining a plurality of flashing process functions and a preset flashing context function, and the protocol data is sent to the diagnosis module 2. The input parameter of the flashing process function can be the state machine parameter (such as the current state, the communication state, etc.) of the ECU node, which is used to define the operation (such as jumping to the Bootloader, data transmission, etc.) to be performed by the current node; the flashing context function can be set based on the preset flashing process, and contains the context information of each ECU node, such as the current state, the next state, the flashing function pointer, the BIN file data address, etc., which is used to dynamically maintain the binding of the node state and the resource.

[0032] The diagnostic module 2 receives the protocol data generated by the flashing control module 1, encapsulates the protocol data into a plurality of interactive protocol data, and then sends the encapsulated interactive protocol data to the protocol data unit layer 3 in parallel, each interactive protocol data corresponding to an ECU node, and the communication protocol (such as UDS, KWP2000, etc.) and node corresponding parameter configuration (such as Tx / Rx channel parameter, timeout time) adopted by the ECU node. It should be noted that the diagnostic module 2 can use the configurable mechanism of the AUTOSAR structure, and the configuration unit is the ECU node, that is, each ECU node can be independently configured to support the UDS service, transmission parameter, retry strategy and flashing process template.

[0033] Finally, the protocol data unit layer 3 receives the interactive protocol data encapsulated by the diagnostic module 2, and transmits it to the corresponding ECU node through the underlying communication protocol (such as CAN, Ethernet, etc.), and completes the parallel flashing operation.

[0034] In summary, the embodiment realizes the concurrent flashing of multiple ECU nodes through independent state machines and multi-thread scheduling, which significantly improves the efficiency. Among them, the flashing control module dynamically adjusts the flashing process based on the real-time polling result, and adapts to the state changes in complex scenarios. The diagnostic module supports multi-protocol adaptation (such as UDS, DoIP, etc.), and is compatible with ECU nodes of different manufacturers. Moreover, in the flashing control module, the node state and data pointer are managed through the flashing context function, realizing intelligent process jumping and resource binding.

[0035] Exemplarily, the diagnostic module 2 includes a plurality of state machines 20, service encapsulation interfaces 21 and node diagnostic configuration lists 22 bound to the flashing state of a corresponding ECU node and in parallel; the node diagnostic configuration list 22 includes flashing parameter items of each ECU node;

[0036] The diagnostic module 2 generates the polling result of each ECU node according to the polling result of the plurality of state machines 20;

[0037] The diagnostic module 2 encapsulates the protocol data into a plurality of interactive protocol data according to the node diagnostic configuration list 22.

[0038] The DiagService can be regarded as a lightweight diagnostic service encapsulation module independent of the AUTOSAR standard. The state machine 20 drives the flashing state transition of the corresponding ECU node, and supports but is not limited to the following state machine states:

[0039] Idle (idle): waiting for the start of the flashing task;

[0040] ProcessTx (process transmission): generating and sending protocol data;

[0041] Wait_Rx (Wait for Receive) : Wait for ECU node response;

[0042] ProcessRx (Process Receive) : Parse ECU response result;

[0043] Wait_TX_Confirmation (Wait for Transmission Confirmation) : Wait for underlying communication confirmation.

[0044] In summary, the state machine 20 separates the upper-layer flashing control instruction (such as request download, transmission data) from the underlying ECU node state, supports binding of an independent state machine for each ECU node, realizes lock-free concurrent control, and decouples the service request logic from the flashing process. The flashing process is dynamically updated by the state machine polling result to adapt to state changes in complex scenarios, thereby improving the flexibility of the architecture.

[0045] Exemplarily, the service encapsulation interface 21 includes a diagnostic session service unit, a request download unit, a transmission data unit, and a security access unit.

[0046] In the embodiment of the application, the service encapsulation interface module 21 of the diagnostic module 2 adopts a modular design, integrates standardized diagnostic service units, supports multi-protocol adaptation and heterogeneous ECU compatibility. The interface includes the following core functional units:

[0047] The diagnostic session service unit (DiagService_Request_DiagnosticSession) is used to establish / terminate a diagnostic session connection with an ECU node; so that the diagnostic module 2 supports multiple diagnostic session modes (such as default session, extended session, programming session).

[0048] The request download service unit (DiagService_Request_Download) is used to trigger the ECU node to enter a flashing preparation state (Bootloader mode); and is also used to negotiate data transmission parameters (such as block size, transmission rate).

[0049] The transmission data service unit (DiagService_Request_TransferData) is used to block transmission of BIN file data to the ECU node; so that the diagnostic module 2 supports a breakpoint resume transmission and a data verification mechanism.

[0050] The security access service unit (DiagService_Request_SecurityAccess) is used to process flashing permission verification (Seed-Key authentication) of the ECU node; and supports multiple security access levels (Level 1- Level 63).

[0051] The service encapsulation interface 21 can call a diagnostic session service unit (DiagService_Request_DiagnosticSession) to enter a programming session mode; if the ECU node enables security access, a security access service unit (DiagService_Request_SecurityAccess) is called to complete Seed-Key authentication; then, a request download service unit (DiagService_Request_Download) is called to trigger the ECU to enter a Bootloader mode; then, a transfer data service unit (DiagService_Request_TransferData) is called to block transfer a BIN file; and finally, a dynamic adjustment is made to a flashing process (such as retrying a failed node or advancing a successful node) according to an ECU response result.

[0052] Embodiments of the application improve system compatibility by modularly designing and integrating UDS core service units; support multiple underlying communication protocols such as CAN and Ethernet, and adapt to heterogeneous ECUs; and guarantee authority control of flashing operations by embedding a Seed-Key authentication process.

[0053] Exemplarily, the node diagnostic configuration list 22 includes Tx channel parameters, Rx channel parameters, and timeout time parameters corresponding to each node.

[0054] The diagnostic module 2 realizes dynamic binding and differential configuration of communication parameters of each ECU node through the node diagnostic configuration list 22 (DiagService_ECU_Node). The configuration list defines independent communication attributes for each ECU node, and ensures flexible adaptation of diagnostic services to underlying hardware.

[0055] The DiagService_ECU_Node configuration array can be defined in the configuration file DiagService_Cfg.c of the node diagnostic configuration list 22, and each element corresponds to a communication parameter item of an ECU node.

[0056] Configuration structure body example:

[0057]

[0058]

[0059] In the node diagnostic configuration list 22, important parameters include Tx / Rx channel parameters and timeout time parameters. TxChannel: specifies a transmission channel identifier (such as a CAN channel number or an Ethernet port number) of the current ECU node;

[0060] RxChannel: specifies the receive channel identifier of the current ECU node (e.g. CAN channel number, Ethernet port number).

[0061] Supports multi-channel binding, for example: ECU_A uses CAN channel 0 for sending and CAN channel 1 for receiving; ECU_B uses Ethernet port 0 for bidirectional communication.

[0062] Isolates the communication paths of different ECU nodes through channel parameters, avoiding data conflicts. This enables independent management of the communication channels of multiple ECU nodes and improves bus resource utilization.

[0063] Timeout parameters include:

[0064] P2Timeout: UDS service response timeout (unit: ms), used to control the response waiting time of the ECU node to the diagnostic request;

[0065] P2StarTimeout: Programming session extension timeout (unit: ms), used for long-period waiting scenarios in the Bootloader phase;

[0066] SendTimeout: Single data sending timeout (unit: ms), used to determine whether the underlying communication has failed.

[0067] In actual applications, the parameter values of the timeout parameters can be dynamically configured according to the hardware characteristics of the ECU node, for example: a high-speed CAN node is set to a small timeout value (e.g. P2Timeout = 50 ms); a low-speed LIN node is set to a large timeout value (e.g. P2Timeout = 500 ms). This enables the timeout mechanism to work in conjunction with the state machine, accurately triggering the retry or error handling process.

[0068] The introduction of the node diagnostic configuration list 22 enables the diagnostic module 2 to adapt to different ECU nodes without modifying the core flashing logic, only needing to configure DiagServiceECUConfigList; adapts to the communication performance differences of different ECU nodes, improving the structural robustness; avoids blocking the overall process due to single-node communication delays.

[0069] For example, the flashing control module 1 can assign an independent flashing process function (such as Uds_Client_ECU1FlashProcess()) to each ECU node, and combine it with several state machine drivers from the diagnostic module 2 to achieve non-blocking parallel flashing. This mechanism ensures that the state transitions of each ECU node are independent of each other, avoids global blocking, and improves system concurrency efficiency. The flashing process proceeds in a state machine manner, without relying on global blocking waits, and the state transitions between nodes are independent of each other. For example: 1. Switch diagnostic sessions; 2. Request seed and send key; 3. Write DID and download request transmission data blocks; 4. Execute routine control or restart.

[0070] For example, the flashing control module 1 binds state machines and flow functions to ECU1 and ECU2 respectively:

[0071] FlashingContext[ECU1].FlashingFunc=Uds_Client_ECU1FlashProcess;

[0072] FlashingContext[ECU2].FlashingFunc=Uds_Client_ECU2FlashProcess;

[0073] The scheduler periodically calls the process functions of each ECU node:

[0074]

[0075] The state transition of ECU1 is as follows:

[0076] STATE_SESSION_SWITCH → STATE_SECURITY_ACCESS →STATE_DOWNLOAD_REQUEST → STATE_TRANSFER_DATA →STATE_ROUTINE_CONTROL

[0077] The state transition of ECU2 is as follows:

[0078] STATE_SESSION_SWITCH → STATE_DOWNLOAD_REQUEST (Skip security access) → STATE_TRANSFER_DATA → STATE_FINISHED

[0079] For example, the flashing context function includes the current state of each ECU node, the next state of each ECU node, the flashing function pointer of each ECU node, and the BIN file data address of each ECU node.

[0080] The flashing context function can dynamically maintain the flashing state and resource binding of each ECU node through the structure body UDS_Client_Node[], realize intelligent process scheduling and abnormality processing. The structure body saves independent context information for each ECU node, ensures the stability and high efficiency of multi-node parallel flashing.

[0081] Structure body definition example:

[0082]

[0083]

[0084] In the context structure body, the current state (Process_PreState) records the current flashing state (such as idle, downloading, verification completion, etc.) of each ECU node. The state value is defined by enumeration type (such as STATE_IDLE, STATE_DOWNLOADING, STATE_VERIFYING); the state update is triggered by the polling result of the diagnostic module 2. In this way, the flashing context function supports dynamic state transition, and can better adapt to the state change requirements in complex scenarios.

[0085] The next state (Process_NextState) predefines the next state target corresponding to the current state, which is used to guide the process advancing direction. The state transition rules are stored in the state transition table (such as StateTransitionTable[CurrentState]=NextState); since the state transition logic is configurable, it supports multi-version flashing process (such as standard process, safety mode process). In this way, the modular design of the flashing process is realized, and the system expandability is improved.

[0086] The flashing function pointer (FlashProcess) points to the specific operation function (such as jumping Bootloader, transmitting data) corresponding to the current state. The process jump is realized through the function pointer, which improves the code reuse rate and execution efficiency.

[0087] The BIN file data address (BIN_DataAddress) stores the firmware file data address (such as memory offset, data block pointer) to be flashed of the current ECU node. Through supporting segmented flashing (such as dividing the BIN file according to sectors) and dynamically updating the address information (such as automatically offsetting after transmitting the data block), the efficient management of large-capacity BIN files is realized, and the memory occupation is reduced.

[0088] When the flashing context function is started, the flashing context function initializes the state of all ECU nodes to STATE_IDLE, and binds the default function pointer (such as idle processing function).

[0089] After the diagnostic module 2 polls the state of each ECU node, the flashing control module 1 obtains the corresponding operation function from the function pointer table according to the current state and executes it; after the execution is completed, the next state is updated according to the response result (such as advancing from STATE_DOWNLOADING to STATE_VERIFYING).

[0090] In the data transmission phase, the flashing context function binds the BIN file data address to ensure that the data block is loaded as needed; after the process is completed, the resources are automatically released (such as closing the communication channel and clearing the cache).

[0091] In this embodiment, through the linkage of the current state and the next state, the real-time dynamic adjustment of the flashing process is realized, which adapts to complex scenarios (such as abnormal interruption and multi-protocol switching). The function pointer mechanism is used to realize process jumping, which replaces the traditional conditional judgment logic, improves the code execution efficiency and maintainability. Due to the binding of the BIN file address and the state machine, global variable pollution is avoided, and resource isolation is supported when multiple ECU nodes are flashed in parallel. The state transition rules and function pointers are separated, which facilitates the extension of new flashing processes (such as adding an OTA verification process).

[0092] Illustratively, the flashing control module 1 updates the corresponding node state or executes the next flashing process according to the response result of each node.

[0093] Illustratively, the flashing control module 1 updates the corresponding node state or executes the next flashing process according to the response result of each node, specifically including:

[0094] The flashing control module 1 receives a negative response from the node, and resets the node state of the corresponding node.

[0095] Illustratively, the flashing control module 1 updates the corresponding node state or executes the next flashing process according to the response result of each node, specifically including:

[0096] The flashing control module 1 receives a successful response from the node and the state of the corresponding node is advanceable, and executes the next flashing process.

[0097] Illustratively, before the flashing control module 1 updates the corresponding node state or executes the next flashing process according to the response result of each node, it further includes:

[0098] According to the ECU node sending message information and the ECU node receiving message information, the response result of the ECU node is obtained.

[0099] The flashing control module 1 updates the node status or promotes the flashing process by analyzing the response result (success / negative response) of the ECU node. This mechanism is based on the analysis result of the message sending and receiving information, and realizes intelligent process scheduling and error recovery by combining state machine driving.

[0100] Before updating the node status or promoting the process, the flashing control module 1 needs to analyze the response result according to the sending message information (Tx) and the receiving message information (Rx) of the ECU node.

[0101] If the service encapsulation interface 21 of the diagnosis module 2 encapsulates the protocol as UDS, the message analysis function is:

[0102]

[0103]

[0104] The response result determination rule is as follows: success response (Positive Response): receiving UDS positive response frame (such as 0x7F+service ID+positive response code); negative response (Negative Response): receiving UDS negative response frame (such as 0x7F+service ID+NRC error code). The accurate determination of the response result is realized by the message analysis function, which provides the basis for state update.

[0105] When the flashing control module 1 receives the negative response of the ECU node, the DiagService_Reset_ECUStatus() function is called to reset the node status.

[0106] State reset function example:

[0107]

[0108]

[0109] In other words, when the flashing control module 1 receives a negative response (such as NRC 0x7F service not supported, NRC 0x22 condition not met), it will reset the node status. Single node exception only affects its own state and does not affect the parallel flashing process of other ECU nodes.

[0110] On the other hand, when the flashing control module 1 receives the success response of the ECU node and the current state is the promotable state, it automatically executes the next state process.

[0111] It should be noted that the legal state transition path (e.g., STATE_DOWNLOADING→STATE_VERIFYING) can be defined according to the state transition table; if there is no legal next state for the current state (e.g., STATE_FINISHED), the process is terminated. The state transition table can be obtained by recording the state machine of the node.

[0112] Take one possible workflow of the flashing control module 1 as an example:

[0113] The diagnosis module 2 calls UDS_Client_RxIndication() to parse the ECU response message and determines that it is a negative response (NRC 0x22); and calls UDS_Client_TxConfirmation() to confirm the sending timeout.

[0114] The flashing control module 1 detects the negative response, calls DiagService_Reset_ECUStatus() to reset the ECU1 state to STATE_IDLE; and other ECU nodes (e.g., ECU2) continue to promote the process. ECU2 returns a successful response, and the current state is STATE_TRANSFER_DATA;

[0115] The flashing control module 1 updates the state to STATE_ROUTINE_CONTROL and calls the corresponding flashing function to perform the verification process.

[0116] The above embodiment updates the node state in real time based on the response result, and adapts to complex scenarios (e.g., network fluctuations, ECU response delays). A single node negative response only triggers local state reset, without affecting the flow of other nodes, improving system robustness. If a node successfully responds, the next state is automatically executed, reducing manual intervention and shortening the overall flashing time. In summary, since the message parsing, state updating, and process promotion functions are decoupled, it is easy to extend new error codes or process steps.

[0117] Compared with the prior art, the flashing control module 1 dynamically updates the flashing process function corresponding to each ECU node according to the polling result of the diagnosis module 2 for each ECU node, and then generates protocol data in combination with a plurality of flashing process functions and a preset flashing context function, and sends the protocol data to the diagnosis module 2. Since the flashing process function is dynamically updated according to the polling result of each ECU node, the architecture supports dynamic interruption of single node flashing and preservation of its failure state for subsequent diagnosis or re-flashing. Moreover, the flashing process is dynamically adjusted based on real-time polling results, which can adapt to state changes in complex scenarios; and the node state and data pointer are managed by the flashing context function, realizing intelligent process jumping and resource binding.

[0118] The diagnostic module 2 encapsulates the protocol data generated by the flashing control module into several interactive protocol data, and sends them to the protocol data unit layer in parallel; each interactive protocol data corresponds to an ECU node, and adapts to the communication protocol and parameter configuration thereof. Each interactive protocol data is independent, so that in the parallel flashing process, the flashing process of other ECU nodes will not be affected when any node abnormally occurs (such as response timeout, check failure). In addition, the diagnostic module 2 can modify the internal service encapsulation interface 21, thereby supporting multi-protocol adaptation (such as UDS, DoIP, etc.), and being compatible with ECU nodes of different manufacturers.

[0119] Please refer to Figure 2 Another embodiment of the present application provides an AUTOSAR-based flashing architecture, which comprises an application layer comprising the flashing control module as described above, an interactive layer comprising the diagnostic module as described above and the protocol data unit layer as described above, a network layer, a data link layer, and a physical layer; the application layer, the interactive layer, the network layer, the data link layer, and the physical layer are sequentially connected end to end.

[0120] Compared with the traditional AUTOSAR flashing architecture, the main improvement of the embodiment is in the application layer and the interactive layer. The application layer (Application Layer)

[0121] The application layer integrates the flashing control module 1 as described above, and is used for realizing parallel flashing scheduling and process management of multiple ECU nodes. The flashing control module 1 runs in the AUTOSAR application layer, and calls the underlying service through a standard interface (such as Com_Signal, RTE); overall, the application layer adopts a modular design, and supports cooperative operation with a vehicle control system (such as a body control, a power domain control).

[0122] The interactive layer comprises the diagnostic module 2 and the protocol data unit layer 3, and is responsible for diagnostic service encapsulation and protocol adaptation. The diagnostic module 2 realizes UDS service encapsulation (such as DiagnosticSessionControl, SecurityAccess), integrates a node diagnostic configuration list (DiagService_ECU_Node), and supports multi-protocol adaptation (UDS on CAN / Ethernet).

[0123] The protocol data unit layer 3 realizes encapsulation and routing of protocol data based on the AUTOSAR communication stack (such as CANTP, DoIP); and supports multi-channel parallel transmission (such as parallel flashing of CAN channel 0 and Ethernet port 0).

[0124] The general cooperative working process of the improved AUTOSAR-based flashing architecture is as follows:

[0125] The brush writing control module 1 calls the diagnosis service (such as DiagService_Request_Download()) through the RTE interface, and starts the brush writing task.

[0126] The diagnosis module 2 generates the UDS protocol frame according to the node diagnosis configuration list (DiagService_ECU_Node); and the protocol data unit layer 3 encapsulates the protocol data into the underlying communication format (such as CAN frame or Ethernet frame).

[0127] The network layer distributes the data packet to the target ECU node according to the routing table; the data link layer completes the frame formatting and flow control, and ensures the transmission reliability. The physical layer sends the data to the target ECU node through the CAN controller or the Ethernet PHY.

[0128] The ECU node returns the response message, which is parsed layer by layer through the physical layer, the data link layer and the network layer; the diagnosis module 2 calls the UDS_Client_RxIndication() to parse the response result; and the brush writing control module 1 updates the node state or promotes the process according to the response type.

[0129] Compared with the prior art, the brush writing control module dynamically updates the brush writing process function corresponding to each ECU node according to the polling result of the diagnosis module for each ECU node, and then generates the protocol data by combining the brush writing process function and the preset brush writing context function, and sends the protocol data to the diagnosis module. Since the brush writing process function is dynamically updated according to the polling result of each ECU node, the architecture supports dynamic interruption of single-node brush writing and retains the failure state thereof, which is used for subsequent diagnosis or rebrushing. Moreover, the brush writing process is dynamically adjusted based on the real-time polling result, so that the state change in a complex scene can be adapted; the node state and the data pointer are managed by the brush writing context function, so that intelligent process jumping and resource binding are realized.

[0130] The diagnosis module encapsulates the protocol data generated by the brush writing control module into a plurality of interactive protocol data, and sends the interactive protocol data to the protocol data unit layer in parallel; each interactive protocol data corresponds to an ECU node, and is adapted to the communication protocol and parameter configuration thereof. Each interactive protocol data is independent, so that in the parallel brush writing process, any node exception (such as response timeout or verification failure) will not affect the brush writing process of other ECU nodes. In addition, the diagnosis module can modify the internal service encapsulation interface, so as to support multi-protocol adaptation (such as UDS, DoIP, etc.), and be compatible with ECU nodes of different manufacturers.

[0131] The above is the preferred embodiment of the present application. It should be noted that, for those skilled in the art, without departing from the principle of the present application, a number of improvements and refinements can be made, which are also considered within the protection scope of the present application.

Claims

1. A multi-ECU node parallel flashing architecture, characterized in that, include: Flashing control module, diagnostic module, and protocol data unit layer; The flashing control module updates the flashing process function corresponding to each ECU node based on the polling results of each ECU node of the diagnostic module; the flashing control module generates protocol data based on several flashing process functions and flashing context functions, and sends the protocol data to the diagnostic module; the input parameters of the flashing process functions are the ECU node state machine parameters; the flashing context functions are set according to a preset flashing process. The diagnostic module encapsulates the protocol data into several types of interactive protocol data and sends these types of interactive protocol data in parallel to the protocol data unit layer; each type of interactive protocol data corresponds to an ECU node.

2. The multi-ECU node parallel flashing architecture as described in claim 1, characterized in that, The diagnostic module includes several parallel state machines, service encapsulation interfaces, and a node diagnostic configuration list, each bound to the flashing status of a corresponding ECU node; the node diagnostic configuration list includes flashing parameter items for each ECU node. The diagnostic module generates polling results for each ECU node based on the polling results of the plurality of state machines; The diagnostic module encapsulates the protocol data into several types of interactive protocol data based on the node diagnostic configuration list.

3. The multi-ECU node parallel flashing architecture as described in claim 2, characterized in that, The service encapsulation interface includes a diagnostic session service unit, a request download unit, a data transmission unit, and a secure access unit.

4. The multi-ECU node parallel flashing architecture as described in claim 2, characterized in that, The node diagnostic configuration list includes the Tx channel parameters, Rx channel parameters, and timeout parameters for each node.

5. The multi-ECU node parallel flashing architecture as described in claim 1, characterized in that, The flashing context function includes the current state of each ECU node, the next state of each ECU node, the flashing function pointer of each ECU node, and the BIN file data address of each ECU node.

6. The multi-ECU node parallel flashing architecture as described in claim 2, characterized in that, The write control module updates the status of the corresponding node or executes the next write process based on the response results of each node.

7. The multi-ECU node parallel flashing architecture as described in claim 6, characterized in that, The write control module updates the status of the corresponding node or executes the write process for the next status based on the response results of each node, specifically including: When the write control module receives a negative response from a node, it resets the node state of the corresponding node.

8. The multi-ECU node parallel flashing architecture as described in claim 6, characterized in that, The flash control module updates the status of the corresponding node or executes the next flash process based on the response results of each node, specifically including: The write control module receives a successful response from the node and the corresponding node's state is ready to proceed, then executes the write process for the next state.

9. The multi-ECU node parallel flashing architecture as described in claim 6, characterized in that, Before updating the status of the corresponding node or executing the next flashing process based on the response results of each node, the flashing control module also includes: The response result of the ECU node is obtained based on the message information sent and received by the ECU node.

10. A write architecture based on AUTOSAR, characterized in that, It includes an application layer containing the write control module as described in claim 1, an interaction layer containing the diagnostic module as described in claim 1 and the protocol data unit layer as described in claim 1, a network layer, a data link layer, and a physical layer; the application layer, the interaction layer, the network layer, the data link layer, and the physical layer are connected end to end in sequence.

Images