SPI bridge-based doip-to-docan protocol conversion and function distributed processing method and system

Abstract

This invention provides a DoIP to DoCAN protocol conversion and functional distributed processing method and system based on SPI bridging, belonging to the field of vehicle network diagnostic service technology. The method includes: acquiring a DoIP diagnostic message sent by a DoIP diagnostic instrument, unpacking it to obtain a UDS request message, parsing the UDS request message to obtain a service identifier; if the service identifier is session control, security access, or communication control, processing the UDS request message according to the UDS request message, updating the current diagnostic session and security access level status maintained internally by the SoC, and synchronizing the updated session status and security level to the MCU; if the service identifier is not session control, security access, or communication control, encapsulating the UDS request message according to a private SPI protocol, and sending the UDS request message encapsulated according to the private SPI protocol to the MCU; when a UDS response message encapsulated according to the private SPI protocol is acquired from the MCU, unpacking it to obtain a UDS response message, encapsulating the UDS response message and sending it back to the DoIP diagnostic instrument.

Description

Technical Field

[0001] This invention relates to the field of vehicle network diagnostic service technology, and in particular to a method and system for DoIP to DoCAN protocol conversion and functional distributed processing based on SPI bridging. Background Technology

[0002] As the level of intelligence and connectivity in automobiles continues to increase, their electronic and electrical architecture is undergoing a profound transformation from distributed domain control to centralized computing. In this evolution, in-vehicle networks exhibit a typical hybrid architecture characterized by the long-term coexistence of multiple communication protocols: on the one hand, automotive Ethernet, with its advantages of high bandwidth and low latency, is gradually becoming the backbone network between high-performance domain controllers in intelligent cockpits and autonomous driving systems; on the other hand, CAN / CAN FD buses, due to their mature technology, low cost, and high reliability, still dominate in the underlying execution areas such as body control and powertrain systems.

[0003] As a key technology for vehicle lifecycle management, the Unified Diagnostic Service (UDS) protocol needs to adapt to this hybrid network architecture. Currently, there are two main, but each limited, technical approaches to implementing the UDS protocol:

[0004] 1. CAN bus-based diagnostics (DoCAN) solution: This solution is mature and stable, and has been widely deployed in a large number of traditional ECUs. However, its inherent shortcomings are becoming increasingly apparent: First, its limited bandwidth (usually ≤1Mbps) cannot meet the stringent efficiency requirements of modern ECU large-scale software reprogramming, severely restricting production line cycle time and user experience; second, its physical interface is not directly compatible with the new generation of Ethernet-based DoIP diagnostic instruments, forming a communication barrier due to technological generation gap.

[0005] 2. Ethernet-based Diagnostic Instructions for Internet (DoIP) Solution: While this solution addresses the bandwidth bottleneck, it introduces new challenges. Implementing full DoIP node functionality requires a high-performance system-on-a-chip (SoC). However, SoCs typically lack integrated non-volatile memory (such as EEPROM). If diagnostic fault codes (DTCs) need to be stored, external storage chips must be added, increasing material costs and design complexity. More importantly, fully implementing all diagnostic functions on the SoC side requires integrating a large TCP / IP and DoIP protocol stack, consuming significant CPU and memory resources that could be used for advanced applications. Furthermore, it prevents the reuse of well-proven, mature diagnostic code from existing microcontrollers (MCUs), resulting in resource waste and increased software development costs and risks.

[0006] Therefore, the industry urgently needs an innovative technical solution that can effectively bridge the two major technology systems of DoIP and DoCAN without sacrificing efficiency or significantly increasing costs. Summary of the Invention

[0007] This invention aims to solve at least one of the aforementioned problems in the prior art, and through an innovative solution, simultaneously achieves the following objectives: supports seamless diagnosis of nodes with only DoCAN capability via the DoIP diagnostic tool; makes full use of existing hardware resources and avoids redundant investment; and maintains the simplicity and scalability of the system architecture.

[0008] In a first aspect, embodiments of the present invention provide a method for DoIP to DoCAN protocol conversion and distributed functional processing based on SPI bridging, including:

[0009] Obtain the DoIP diagnostic message sent by the DoIP diagnostic instrument, unpack the DoIP diagnostic message to obtain the UDS request message, and parse the UDS request message to obtain the service identifier.

[0010] If the service identifier is session control, security access or communication control, the UDS request is processed according to the UDS request message, the current diagnostic session and security access level status maintained in the SoC are updated, and the updated session status and security level are synchronized to the MCU via SPI.

[0011] If the service identifier is not session control, security access and communication control, the UDS request message is encapsulated according to the private SPI protocol, and the UDS request message encapsulated according to the private SPI protocol is sent to the MCU through SPI;

[0012] When a UDS response message encapsulated according to the private SPI protocol is received from the MCU via SPI, the UDS response message encapsulated according to the private SPI protocol is unpacked to obtain the UDS response message, and the UDS response message is encapsulated into a DoIP protocol data unit and sent back to the DoIP diagnostic instrument.

[0013] The UDS request message encapsulated according to the private SPI protocol includes: the UDS request message and context state information; the UDS response message encapsulated according to the private SPI protocol includes: the UDS response message and context state information.

[0014] In a preferred embodiment, the method further includes: establishing a communication link between the SoC and the MCU according to a predefined private SPI protocol.

[0015] In a preferred embodiment, the step of establishing a communication link between the SoC and the MCU according to a predefined private SPI protocol includes:

[0016] Configuration parameters, including: SPI clock frequency, data bit order, and communication mode;

[0017] Send a specific synchronization word to the MCU and receive a response word from the MCU.

[0018] In a preferred embodiment, the method further includes: after sending the UDS request message encapsulated according to the private SPI protocol to the MCU via SPI, starting a timer; if no UDS response message encapsulated according to the private SPI protocol is received from the MCU via SPI within a set time, the UDS request message encapsulated according to the private SPI protocol is resent to the MCU via SPI or a negative response is returned to the DoIP diagnostic instrument.

[0019] In a preferred embodiment, the method further includes: when a retransmission notification is received from the MCU via SPI, retransmitting the UDS request message encapsulated according to the private SPI protocol to the MCU via SPI.

[0020] In a preferred embodiment, the request frame format of the UDS request message encapsulated according to the private SPI protocol is as follows: frame header, command word, data length, session state, security level, UDS request data, and checksum.

[0021] In a preferred embodiment, the response frame format of the UDS response message encapsulated according to the private SPI protocol is: frame header, command word, data length, status, UDS response data, and checksum.

[0022] In a second aspect, embodiments of the present invention provide a DoIP to DoCAN protocol conversion and functional distributed processing system based on SPI bridging, the system being configured to implement any of the methods described in the first aspect, the system comprising:

[0023] The message receiving and analysis module is used to obtain DoIP diagnostic messages sent by the DoIP diagnostic instrument, unpack the DoIP diagnostic messages to obtain UDS request messages, and parse the UDS request messages to obtain service identifiers.

[0024] The preprocessing module is used to process the UDS request according to the UDS request message when the service identifier is session control, security access or communication control, update the current diagnostic session and security access level status maintained in the SoC, and synchronize the updated session status and security level to the MCU through SPI.

[0025] The SPI protocol encapsulation and transmission module is used to encapsulate the UDS request message according to the private SPI protocol when the service identifier is non-session control, security access and communication control, and send the UDS request message encapsulated according to the private SPI protocol to the MCU through SPI.

[0026] The response return module is used to, when it receives a UDS response message encapsulated according to the private SPI protocol sent by the MCU via SPI, unpack the UDS response message encapsulated according to the private SPI protocol to obtain a UDS response message, encapsulate the UDS response message into a DoIP protocol data unit and send it back to the DoIP diagnostic instrument.

[0027] The UDS request message encapsulated according to the private SPI protocol includes: the UDS request message and context state information; the UDS response message encapsulated according to the private SPI protocol includes: the UDS response message and context state information.

[0028] Thirdly, embodiments of the present invention provide an electronic device, including:

[0029] One or more processors;

[0030] Memory, used to store one or more programs;

[0031] When the one or more programs are executed by the one or more processors, the one or more processors implement any of the methods described in the first aspect.

[0032] Fourthly, embodiments of the present invention provide a computer-readable medium storing a computer program that, when executed by a processor, implements the steps of any of the methods described in the first aspect.

[0033] Beneficial effects of this invention:

[0034] 1. Excellent compatibility: This invention enables complete access to the functions of the underlying controller that only supports the DoCAN protocol through a single DoIP diagnostic interface, without the need to modify the original MCU diagnostic core.

[0035] 2. Resource Optimization and Cost Savings: This invention avoids implementing complex, storage-related diagnostic modules on the SoC side, significantly reducing the software complexity of the SoC and the occupation of CPU and ROM resources. It fully utilizes the existing EEPROM resources and storage diagnostic functions of the MCU, avoiding the additional material costs and board space required for external EEPROMs on the SoC.

[0036] 3. Functional Decoupling and Enhanced Scalability: This invention decouples high-speed interface processing (DoIP), high-level state management (session, security), and low-level execution and data storage functions, resulting in a clear system architecture. Future expansion with new diagnostic services or protocols only requires incremental development in the corresponding modules, facilitating maintenance and upgrades.

[0037] 4. Maintaining reliability: The diagnostic processing flow on the MCU side remains unchanged in this invention, and it fully inherits the original verified and highly reliable DoCAN function, ensuring the correctness and stability of diagnostic execution. Attached Figure Description

[0038] Figure 1 This is a schematic diagram of a distributed diagnostic processing flow based on the division of labor between SoC and MCU, provided in an embodiment of the present invention.

[0039] Figure 2 This is one of the flowcharts illustrating a DoIP to DoCAN protocol conversion and functional distributed processing method based on SPI bridging, provided in an embodiment of the present invention.

[0040] Figure 3 This is the second schematic diagram of a DoIP to DoCAN protocol conversion and functional distributed processing method based on SPI bridging provided in an embodiment of the present invention.

[0041] Figure 4 This is the third flowchart illustrating a DoIP to DoCAN protocol conversion and functional distributed processing method based on SPI bridging, provided as an embodiment of the present invention.

[0042] Figure 5 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0043] To enable those skilled in the art to better understand the technical solutions of the present invention, exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0044] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.

[0045] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0046] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0047] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art and the invention, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined herein.

[0048] In the technical solution of this invention, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information all comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations (e.g., the "Information Security Technology - Personal Information Security Specification"). For example: appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identity targeting is eliminated when using personal information to avoid precisely locating a specific individual.

[0049] The abbreviations and key terms of this invention are defined as follows:

[0050] UDS, Unified Diagnostic Services.

[0051] DoIP, Diagnostics over Internet Protocol, is a diagnostic tool based on the Internet Protocol.

[0052] DoCAN, Diagnostics over Controller Area Network, is a diagnostic tool based on the controller area network.

[0053] SoC, System on a Chip.

[0054] MCU, Microcontroller Unit.

[0055] SPI, Serial Peripheral Interface.

[0056] ECU, Electronic Control Unit.

[0057] DTC stands for Diagnostic Trouble Code.

[0058] SID, Service Identifier.

[0059] CRC, Cyclic Redundancy Check.

[0060] One existing related technology is a standalone DoCAN (UDS over CAN) implementation. The process of this technology is as follows: Request transmission (diagnostic instrument -> ECU); CAN driver receives a series of CAN frames (one FF and multiple CF); CAN driver passes the frame to CANIf; CANIf passes it to the CAN TP module; CAN TP reassembles the frame according to the ISO 15765-2 protocol to obtain the complete UDS request message; CAN TP sends the reassembled message to DCM via PduR; DCM parses and executes the services requested by the UDS request; DCM generates a UDS response and sends it back to CAN TP via PduR; CAN TP segments the response message (if needed) into FF and CF; CAN TP sends the segmented CAN frame to the bus via CANIf and the CAN driver. The drawbacks of this technology are: 1. 1. Slow speed and severely insufficient bandwidth: The classic CAN bus bandwidth is typically only 500kbps, and even with CAN FD, the peak speed is only around 2-8Mbps. For large-scale data operations common in modern automobiles, such as ECU software reprogramming, transmitting a firmware package of several hundred MB or even GB can take tens of minutes or even hours, resulting in extremely low efficiency and failing to meet the pace of modern production lines and user experience requirements. 2. Poor connectivity and difficulty in remote access: CAN is a typical in-vehicle local area network, and physically, it usually requires connection via the OBD-II interface, making remote access difficult. It cannot directly support modern service functions such as remote diagnostics and over-the-air (OTA) updates, limiting innovation in after-sales service models. 3. Incompatibility with next-generation DoIP diagnostic tools: It only supports the CAN physical interface and cannot directly respond to modern diagnostic requests initiated through the vehicle's Ethernet interface. This forces production line off-line and after-sales maintenance to rely on traditional CAN diagnostic tools, preventing the use of high-speed DoIP channels to improve efficiency.

[0061] The second existing related technology is a standalone DoIP (UDS over IP) solution. The process of this solution is as follows: the diagnostic tool and the ECU's DoIP module establish a TCP connection; both parties complete DoIP route activation; the Ethernet driver receives the Ethernet frame and hands it over to the TCP / IP stack; the TCP / IP stack unpacks the frame and transmits the data to the DoIP module via the Socket adapter; the DoIP module parses the DoIP header, verifies its validity, and extracts the internal UDS request message; the DoIP module sends the UDS request message to the DCM via PduR; the DCM parses and executes the UDS service; the DCM generates a UDS response and sends it back to the DoIP module via PduR; the DoIP module encapsulates the response into a DoIP message and sends it out via the Socket adapter and TCP / IP stack. The drawbacks of this solution are: 1. It consumes a large amount of SoC software resources: a complete TCP / IP protocol stack and DoIP protocol stack need to be integrated and run on the SoC side, consuming a significant amount of valuable CPU processing power. 1. Limited capabilities and memory (ROM / RAM) resources, crowding out resources for other advanced functions (such as smart cockpit applications). 2. Redundancy in non-volatile memory access design: For ECUs that need to store DTCs or data, if the SoC does not have built-in EEPROM, a separate EEPROM chip must be added externally. This results in a waste of hardware resources compared to the MCU solution, as the MCU usually already has this storage resource. 3. Inability to reuse existing mature and reliable MCU diagnostic functions: The fully verified and stable DoCAN diagnostic application layer software on the MCU side is abandoned. All diagnostic functions need to be developed or ported from scratch on the SoC side, introducing additional development costs, testing risks, and software licensing fees. 4. Imbalance in cost-effectiveness (for simple ECUs): For ECUs that perform simple control functions and only need to report a small amount of data (such as sensor actuators), deploying a complete DoIP solution is a typical case of "overkill." The high hardware and software costs do not bring commensurate functional benefits.

[0062] In summary, under the current in-vehicle network architecture where automotive Ethernet (DoIP) and traditional CAN / CAN FD (DoCAN) coexist, the design of diagnostic systems for automotive electronic control units (ECUs) faces the following three core technical contradictions and challenges:

[0063] 1. Communication barriers between DoIP diagnostic tools and traditional CAN nodes

[0064] New-generation diagnostic equipment generally uses high-speed DoIP interfaces, but these cannot directly access the underlying ECUs in vehicles that only support the DoCAN protocol. This forces technicians to carry and frequently switch between multiple diagnostic tools, severely reducing diagnostic efficiency and preventing "one-stop" full-domain diagnostics, which contradicts the demands of modern efficient manufacturing and after-sales maintenance processes.

[0065] 2. High-performance SoC resource overhead and cost control issues

[0066] To support DoIP (DoIntegration of Product) technology, OEMs tend to use highly integrated system-on-a-chip (SoC). However, such SoCs typically lack integrated non-volatile memory (such as EEPROM). Adding dedicated memory chips to store data such as diagnostic fault codes (DTCs) increases material costs and board space. Furthermore, implementing a complete diagnostic application layer parallel to the MCU on the SoC side leads to redundant software development, consuming significant amounts of valuable CPU and memory resources, resulting in high system costs and low resource utilization.

[0067] 3. Issues related to the reuse of existing hardware resources and system scalability.

[0068] Traditional ECUs typically have microcontrollers (MCUs) with mature DoCAN diagnostic frameworks and directly connected EEPROMs. However, these resources are often abandoned during the evolution to DoIP, resulting in a waste of existing reliable hardware investments and software assets. Furthermore, the existing diagnostic architecture is rigid, with DoIP isolated from the DoCAN protocol stack, lacking a flexible and scalable mechanism to adapt to new automotive network protocols that may emerge in the future, thus limiting the system's lifespan.

[0069] Therefore, the present invention aims to solve the above-mentioned technical problems, namely: how to break down the communication barrier between the DoIP diagnostic instrument and the DoCAN ECU without increasing additional hardware costs and reusing existing mature diagnostic resources on the MCU side, and build an efficient, low-cost and easily scalable hybrid network diagnostic solution.

[0070] Figure 1 The flowchart of the distributed diagnostic processing based on the division of labor between SoC and MCU provided in the embodiments of the present invention is as follows: Figure 1 The distributed diagnostic processing flow shown includes:

[0071] Phase 1: System Initialization and Link Establishment

[0072] 1. SoC and MCU power-on initialization:

[0073] On the SoC side: The operating system boots up, loads and initializes the DoIP protocol stack and the SPI host controller driver. After the DoIP protocol stack completes its initialization, it starts listening on the TCP port (default 13400) and waits for the diagnostic tool to connect.

[0074] On the MCU side: Initialize the CAN controller, CAN TP protocol stack, UDS diagnostic application layer, SPI slave controller driver, and non-volatile memory (EEPROM) interface. The MCU-side diagnostic framework enters a ready state, waiting for diagnostic requests from the CAN bus or SPI bus.

[0075] 2. Initialization of the private SPI communication protocol:

[0076] The SoC and MCU establish a communication link based on a predefined private SPI communication protocol. This protocol requires pre-configuration of key parameters, such as: SPI clock frequency (usually 10-20Mbps), data bit order (MSB / LSB), and communication mode (usually Mode 0 or Mode 3).

[0077] Both parties complete a synchronization handshake (for example, the SoC sends a specific synchronization word 0xAA55A55A, and the MCU replies with an acknowledgment word 0x55AA5AA5), confirming that the physical link is working and the protocol stack is ready.

[0078] Phase Two: DoIP Diagnostic Request Processing and Forwarding

[0079] 3. DoIP connection establishment and message reception:

[0080] The external DoIP diagnostic tool establishes a TCP connection with the SoC via Ethernet and completes the DoIP vehicle declaration and route activation process.

[0081] The SoC's DoIP protocol stack receives the DoIP diagnostic message sent by the diagnostic tool, and after unpacking, obtains the complete UDS request message (e.g., a 0x22 ReadDataByIdentifier request).

[0082] 4. SoC-side request analysis and preprocessing:

[0083] The diagnostic routing module in the SoC parses the UDS request message and reads the service identifier (SID).

[0084] Session and security management:

[0085] If the SID is Session Control (0x10) or Security Access (0x27), the request is processed locally by the SoC. The SoC updates its internally maintained current diagnostic session and security access level states.

[0086] Subsequently, the SoC must immediately synchronize the latest session state and security level to the MCU via SPI (see step 6).

[0087] For other service requests (such as 0x22, 0x2E, 0x19, etc.), the SoC is prepared to forward them.

[0088] 5. SPI Protocol Encapsulation and Transmission:

[0089] The SPI adaptation layer on the SoC side encapsulates the UDS request message to be forwarded according to the proprietary SPI protocol frame format. A typical request frame format can be designed as follows:

[0090] Fields Frame header command word Data length (N) Session state Security level UDS request data (N bytes) CRC32 check illustrate Fixed value 0x5A5A 0x01 (represents a request) N Current Session Current security level raw UDS message Cyclic Redundancy Check length 2 bytes 1 byte 2 bytes 1 byte 1 byte N bytes 4 bytes

[0091] After packaging, the SoC sends the entire frame to the MCU via the SPI bus.

[0092] Phase 3: MCU-side diagnostic processing and execution

[0093] 6. MCU Reception and SPI Unpacking:

[0094] After receiving a complete frame, the MCU's SPI slave controller first performs a CRC check. If the check fails, the frame is discarded, and the SoC can be notified to retransmit it.

[0095] After successful verification, the MCU parses the frame content and extracts the session status, security level, and UDS request data.

[0096] 7. State synchronization and diagnostic execution:

[0097] The MCU updates the internal state of its UDS diagnostic application layer based on the session state and security level carried in the SPI frame, ensuring complete consistency with the SoC side.

[0098] The MCU directly sends the extracted UDS request message into its existing DoCAN diagnostic protocol stack for processing. At this point, the diagnostic stack behaves as if it has received a request from the CAN bus and will execute the standard procedure:

[0099] Verification: Checks whether the current session and security level allow the service to be executed.

[0100] implement:

[0101] For service 0x22, read the data corresponding to the specified data identifier from the local EEPROM.

[0102] For the 0x2E service, data is written to the local EEPROM.

[0103] For service 0x19, read the DTC and its snapshot information from the EEPROM.

[0104] For service 0x14, retrieve relevant fault information from the EEPROM.

[0105] Response: Generate a standard UDS response message (such as a positive response code 0x62 or a negative response code 0x7F).

[0106] Phase 4: Response Return

[0107] 8. MCU response encapsulation and transmission:

[0108] The MCU will re-encapsulate the generated UDS response message using its proprietary SPI protocol. The response frame format is as follows:

[0109] Fields Frame header command word Data length (M) state UDS response data (M bytes) CRC32 check illustrate Fixed value 0x5A5A 0x02 (represents a response) M 0x00 (Success) Original UDS response Cyclic Redundancy Check length 2 bytes 1 byte 2 bytes 1 byte M bytes 4 bytes

[0110] The MCU sends the response frame back to the SoC via the SPI bus.

[0111] 9. SoC forwards to diagnostic tool:

[0112] After receiving the SPI response frame, the SoC performs CRC check and unpacking to extract the UDS response message.

[0113] The SoC's DoIP protocol stack encapsulates this UDS response message into a DoIP protocol data unit and sends it back to the external DoIP diagnostic tool through the established TCP connection.

[0114] Phase 5: Error Handling and Timeout Management

[0115] 10. End-to-end reliability assurance:

[0116] Timeout mechanism: The SoC starts a timer after sending an SPI request. If no SPI response is received from the MCU within the set time, the SoC can choose to resend the request or return a negative response to the diagnostic tool (such as 0x7F, 0x78 - Request was received correctly, but the response is pending).

[0117] Error retransmission: Based on CRC check, a simple Automatic Repeat Request (ARQ) mechanism is established to ensure the reliability of SPI transmission.

[0118] Status anomaly handling: If an anomaly occurs during MCU processing (such as receiving an unrecognized service), the generated UDS negative response code will be returned through the normal path. The SoC will not perform any additional processing and will directly forward it to the diagnostic tool to maintain the purity of the diagnostic protocol.

[0119] In the following embodiments of the present invention, for ease of description, a System-on-a-Chip (SoC) is used as the execution subject. The execution subject can be a software module or other electronic devices capable of performing the following functions.

[0120] Figure 2 This is one of the flowcharts illustrating a DoIP to DoCAN protocol conversion and functional distributed processing method based on SPI bridging provided in an embodiment of the present invention; as shown below. Figure 2 As shown, the method includes:

[0121] Step S1: Obtain the DoIP diagnostic message sent by the DoIP diagnostic instrument, unpack the DoIP diagnostic message to obtain the UDS request message, and parse the UDS request message to obtain the service identifier (SID).

[0122] Step S2: If the service identifier is session control, security access or communication control, process the UDS request according to the UDS request message, update the current diagnostic session and security access level status maintained internally by the SoC, and synchronize the updated (latest) session status and security level to the MCU via SPI.

[0123] Step S3: If the service identifier is not session control, security access and communication control, the UDS request message is encapsulated according to the private SPI protocol, and the UDS request message encapsulated according to the private SPI protocol is sent to the MCU through SPI.

[0124] Step S4: When the UDS response message encapsulated according to the private SPI protocol sent by the MCU via SPI is obtained, the UDS response message encapsulated according to the private SPI protocol is unpacked to obtain the UDS response message, and the UDS response message is encapsulated into the DoIP protocol data unit and sent back to the DoIP diagnostic instrument.

[0125] The UDS request message encapsulated according to the private SPI protocol includes: the UDS request message and context state information; the UDS response message encapsulated according to the private SPI protocol includes: the UDS response message and context state information.

[0126] The MCU updates the internal state of its UDS diagnostic application layer based on the session state and security level carried in the SPI frame sent by the SoC, ensuring complete consistency with the SoC. The MCU directly sends the UDS request message extracted from the SPI frame sent by the SoC into its existing DoCAN diagnostic protocol stack for processing. At this point, the diagnostic stack behaves as if it has received a request from the CAN bus, executing the standard procedure: for service 0x22, it reads the data corresponding to the specified data identifier from the local EEPROM; for service 0x2E, it writes the data to the local EEPROM; for service 0x19, it reads the DTC and its snapshot information from the EEPROM; for service 0x14, it retrieves relevant fault information from the EEPROM. The MCU generates a standard UDS response message (such as a positive response 0x62 or a negative response code 0x7F), encapsulates it again via its proprietary SPI protocol, and sends it back to the SoC.

[0127] The present invention achieves the following functions and effects through the above steps:

[0128] 1. Distributed Functional Processing Architecture: Diagnostic functions, traditionally performed within a single controller, are strategically split based on the hardware characteristics of the SoC and MCU. The SoC handles high-bandwidth, high-complexity communication and state management (DoIP protocol, TCP / IP stack, diagnostic sessions, security algorithms), while the MCU handles lower-level functions requiring direct hardware access (DTC storage, data read / write, and actual execution of diagnostic services). This is not a simple protocol conversion, but a redistribution of functions.

[0129] 2. State Synchronization Mechanism: The SoC acts as the master manager of diagnostic sessions and security states, and proactively synchronizes critical diagnostic session states and security access levels to the MCU in real time via a private SPI protocol. This is the core of ensuring the consistency of behavior throughout the distributed system and avoiding state chaos.

[0130] 3. Transparent Transmission Bridge Based on Private SPI Protocol: A dedicated SPI communication protocol for diagnostic information transmission was designed. This protocol not only transmits the original UDS message but also carries critical context state information (session, security level), ensuring that the execution context of the UDS message is maintained when crossing the SoC-MCU boundary, making it "transparent" to the diagnostic stacks at both ends and the remote diagnostic instrument.

[0131] 4. Seamless reuse of the MCU's existing DoCAN framework: No modifications are required to the MCU's mature diagnostic application layer. UDS requests from the SoC, transmitted via SPI, are directly injected into the MCU's existing diagnostic processing flow, as if received from the CAN bus, greatly ensuring system reliability and stability and reducing development and verification costs.

[0132] In some embodiments, such as Figure 3 As shown, it also includes: step S0, establishing a communication link between the SoC and the MCU according to a predefined private SPI protocol.

[0133] In some embodiments, step S0, establishing a communication link between the SoC and the MCU according to a predefined private SPI protocol, includes:

[0134] Configuration parameters, including: SPI clock frequency, data bit order, and communication mode;

[0135] Send a specific synchronization word to the MCU and receive a response word from the MCU, so that the SoC and the MCU can complete a synchronization handshake to confirm that the physical link is open and the protocol stack is ready.

[0136] In some embodiments, such as Figure 4 As shown, it also includes: step S5, after sending the UDS request message encapsulated according to the private SPI protocol to the MCU via SPI, start a timer. If no UDS response message encapsulated according to the private SPI protocol is received from the MCU via SPI within the set time, the UDS request message encapsulated according to the private SPI protocol is resent to the MCU via SPI or a negative response is returned to the DoIP diagnostic instrument.

[0137] In some embodiments, such as Figure 4 As shown, it also includes: Step S6, when a retransmission notification is received from the MCU via SPI, the UDS request message encapsulated according to the private SPI protocol is retransmitted to the MCU via SPI. The retransmission notification is generated by the MCU after the received UDS request message encapsulated according to the private SPI protocol fails to be verified based on the checksum.

[0138] In some embodiments, the request frame format of the UDS request message encapsulated according to the private SPI protocol is: frame header, command word, data length, session state, security level, UDS request data (original UDS message), and checksum.

[0139] In some embodiments, the response frame format of the UDS response message encapsulated according to the private SPI protocol is: frame header, command word, data length, status, UDS response data (original UDS response), and checksum.

[0140] Based on the same inventive concept, embodiments of the present invention also provide a DoIP to DoCAN protocol conversion and functional distributed processing system based on SPI bridging, the system being configured to implement any of the methods described in the above embodiments, the system comprising:

[0141] The message receiving and analysis module is used to obtain DoIP diagnostic messages sent by the DoIP diagnostic instrument, unpack the DoIP diagnostic messages to obtain UDS request messages, and parse the UDS request messages to obtain service identifiers.

[0142] The preprocessing module is used to process the UDS request according to the UDS request message when the service identifier is session control, security access or communication control, update the current diagnostic session and security access level status maintained in the SoC, and synchronize the updated session status and security level to the MCU through SPI.

[0143] The SPI protocol encapsulation and transmission module is used to encapsulate the UDS request message according to the private SPI protocol when the service identifier is non-session control, security access and communication control, and send the UDS request message encapsulated according to the private SPI protocol to the MCU through SPI.

[0144] The response return module is used to, when it receives a UDS response message encapsulated according to the private SPI protocol sent by the MCU via SPI, unpack the UDS response message encapsulated according to the private SPI protocol to obtain a UDS response message, encapsulate the UDS response message into a DoIP protocol data unit and send it back to the DoIP diagnostic instrument.

[0145] The UDS request message encapsulated according to the private SPI protocol includes: the UDS request message and context state information; the UDS response message encapsulated according to the private SPI protocol includes: the UDS response message and context state information.

[0146] Based on the same inventive concept, embodiments of the present invention also provide an electronic device. Figure 5 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Figure 5 As shown, an embodiment of the present invention provides an electronic device including: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement any of the methods described in the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0147] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0148] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0149] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0150] Based on the same inventive concept, embodiments of the present invention also provide a computer-readable medium. This computer-readable medium stores a computer program, wherein, when executed by a processor, the program implements the steps of any of the methods described in the above embodiments. The computer-readable storage medium may be a volatile or non-volatile computer-readable storage medium.

[0151] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0152] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0153] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0154] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0155] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0156] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0157] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0158] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0159] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0160] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A method for DoIP to DoCAN protocol conversion and distributed functional processing based on SPI bridging, characterized in that, include: Obtain the DoIP diagnostic message sent by the DoIP diagnostic instrument, unpack the DoIP diagnostic message to obtain the UDS request message, and parse the UDS request message to obtain the service identifier. If the service identifier is session control, security access or communication control, the UDS request is processed according to the UDS request message, the current diagnostic session and security access level status maintained in the SoC are updated, and the updated session status and security level are synchronized to the MCU via SPI. If the service identifier is not session control, security access and communication control, the UDS request message is encapsulated according to the private SPI protocol, and the UDS request message encapsulated according to the private SPI protocol is sent to the MCU through SPI; When a UDS response message encapsulated according to the private SPI protocol is received from the MCU via SPI, the UDS response message encapsulated according to the private SPI protocol is unpacked to obtain the UDS response message, and the UDS response message is encapsulated into a DoIP protocol data unit and sent back to the DoIP diagnostic instrument. The UDS request message encapsulated according to the private SPI protocol includes: the UDS request message and context state information; the UDS response message encapsulated according to the private SPI protocol includes: the UDS response message and context state information.

2. The method according to claim 1, characterized in that, Also includes: A communication link is established between the SoC and the MCU based on a predefined private SPI protocol.

3. The method according to claim 2, characterized in that, The steps for establishing a communication link between the SoC and the MCU according to a predefined private SPI protocol include: Configuration parameters, including: SPI clock frequency, data bit order, and communication mode; Send a specific synchronization word to the MCU and receive a response word from the MCU.

4. The method according to claim 1, characterized in that, Also includes: After the UDS request message encapsulated according to the private SPI protocol is sent to the MCU via SPI, a timer is started. If no UDS response message encapsulated according to the private SPI protocol is received from the MCU via SPI within the set time, the UDS request message encapsulated according to the private SPI protocol is resent to the MCU via SPI or a negative response is returned to the DoIP diagnostic instrument.

5. The method according to claim 4, characterized in that, Also includes: When a retransmission notification is received from the MCU via SPI, the UDS request message encapsulated according to the private SPI protocol is retransmitted to the MCU via SPI.

6. The method according to claim 1, characterized in that, The request frame format of the UDS request message encapsulated according to the private SPI protocol is as follows: frame header, command word, data length, session state, security level, UDS request data, and checksum.

7. The method according to claim 1, characterized in that, The response frame format of the UDS response message encapsulated according to the private SPI protocol is as follows: frame header, command word, data length, status, UDS response data, and checksum.

8. A distributed processing system for DoIP to DoCAN protocol conversion and function based on SPI bridging, characterized in that, The system is configured to implement the method as described in any one of claims 1 to 7, the system comprising: The message receiving and analysis module is used to obtain DoIP diagnostic messages sent by the DoIP diagnostic instrument, unpack the DoIP diagnostic messages to obtain UDS request messages, and parse the UDS request messages to obtain service identifiers. The preprocessing module is used to process the UDS request according to the UDS request message when the service identifier is session control, security access or communication control, update the current diagnostic session and security access level status maintained in the SoC, and synchronize the updated session status and security level to the MCU through SPI. The SPI protocol encapsulation and transmission module is used to encapsulate the UDS request message according to the private SPI protocol when the service identifier is non-session control, security access and communication control, and send the UDS request message encapsulated according to the private SPI protocol to the MCU through SPI. The response return module is used to, when it receives a UDS response message encapsulated according to the private SPI protocol sent by the MCU via SPI, unpack the UDS response message encapsulated according to the private SPI protocol to obtain a UDS response message, encapsulate the UDS response message into a DoIP protocol data unit and send it back to the DoIP diagnostic instrument. The UDS request message encapsulated according to the private SPI protocol includes: the UDS request message and context state information; the UDS response message encapsulated according to the private SPI protocol includes: the UDS response message and context state information.

9. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1 to 7.

10. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 7.

Images