Diagnostic message protocol conversion method of vehicle-mounted gateway under multi-core system

Abstract

The invention relates to a diagnosis message protocol conversion method of a vehicle-mounted gateway under a multi-core system, which comprises an Ethernet bus module, a CAN bus module and an LIN bus module, the diagnosis message protocol conversion between the Ethernet bus module and the CAN bus module comprises DoIp to CAN and CAN to DoIp, and the diagnosis message protocol conversion between the nodes of the Ethernet bus module and the CAN bus module comprises DoIp to CAN and CAN to DoIp. Diagnostic message protocol conversion between the Ethernet bus module and the LIN bus module node comprises DoIp to LIN and LIN to DoIp, the diagnosis message protocol conversion between the Ethernet bus module and the Ethernet bus module node identifies and forwards a data frame through an MAC address and is completed by hardware equipment of a switch, and the switch is connected with a main MCU of the gateway controller. By adopting the technical scheme, the invention provides the diagnosis message protocol conversion method of the vehicle-mounted gateway under the multi-core system, Ethernet, CAN and LIN are mixed, and mutual conversion among different communication protocols is realized through combination of software and hardware, so that cross-core communication in a gateway controller is realized, and high-performance intelligent routing among vehicle networks is realized.

Description

Technical Field

[0001] This invention relates to the field of communication technology for vehicle electronic devices, and in particular to a diagnostic message protocol conversion method for vehicle gateways in multi-core systems. Background Technology

[0002] With the increasing involvement of software in automotive electronic components, software is gradually becoming a crucial factor redefining real-world vehicle performance, and its electronic and electrical architecture is undergoing a fundamental transformation from distributed ECUs to domain control / centralized computing. In this transformation, the role of the in-vehicle gateway has evolved from a simple data forwarder and protocol converter to a "smart transportation hub" for vehicle communication. The complexity, stability, and real-time performance of its internal network require stringent guarantees. This is based on the following profound technical background: The demand for high-speed, high-volume data transmission: Applications such as autonomous driving sensors (cameras, LiDAR), high-definition infotainment systems, and remote vehicle upgrades generate massive amounts of data that traditional low-speed buses (such as CAN and LIN) cannot handle. High-speed automotive Ethernet (100 / 1000BASE-T1) has become the inevitable choice for backbone networks. Gateway nodes must simultaneously connect multiple channels and various types of hardware channels to establish physical connections with multiple nodes, enabling the establishment of a network topology between the in-vehicle high-speed Ethernet OTA master node or the external Ethernet remote diagnostic device, the gateway, and multiple in-vehicle low-speed CAN and LIN slave nodes. On the one hand, the gateway needs to accurately identify, parse, and reassemble message data between different protocols, and accurately select the destination routing channel for forwarding. On the other hand, current gateway devices also integrate many domain control functions, such as BCM, thermal management, and VCU modules. This highly integrated gateway control system often uses multi-core processors to improve computing and execution efficiency. CAN (Controller Area Network), LIN (Local Interconnect Network), and Ethernet are deployed on different CPU cores and run independently. Cross-core routing processing, data caching to prevent route loss, and conflicting access to shared route cache data by multiple cores are all significant factors affecting routing performance. Secondly, as a critical component, especially with the high involvement of Ethernet, gateway security and protection against unauthorized data traffic attacks are also essential considerations for successful routing. Summary of the Invention

[0003] The purpose of this invention is to overcome the shortcomings of the prior art. This invention provides a diagnostic message protocol conversion method for vehicle gateways in multi-core systems, which combines Ethernet, CAN, and LIN. Through a combination of software and hardware, it realizes the mutual conversion between different communication protocols carried on these bus communication methods, thereby achieving cross-core communication in the gateway controller and realizing high-performance intelligent routing between vehicle networks.

[0004] The first aspect of this invention provides a scheme for implementing diagnostic message protocol conversion between Ethernet and CAN nodes in an in-vehicle gateway, including: The vehicle gateway node receives DoIP diagnostic requests from OBD or OTA Master nodes via their Ethernet physical channel. The OBD interface is an on-board diagnostic interface that can connect to external diagnostic tools for remote or instrument-based diagnostics. The OTA Master is a core electronic control unit responsible for managing and executing over-the-air (OTA) software updates for the entire vehicle; it can be an Ethernet node within the vehicle. A DoIP request is a diagnostic communication protocol based on the traditional TCP / IP stack, carrying the ISO 13400 Internet Protocol at its application layer. It is a commonly used protocol for diagnostic communication of on-board devices.

[0005] When a remote diagnostic or OTA initiator sends a DoIp diagnostic request, the gateway receives the DoIp request in the Ethernet frame, processes it through its software, identifies the destination logical address of the DoIp, determines whether it is equal to the gateway's own logical address, and decides whether to perform diagnostics on this gateway or on other in-vehicle nodes.

[0006] The routing scheme of the present invention includes pre-establishing a logical correspondence between the destination address of DoIp and the CAN physical channel in the Ethernet gateway software.

[0007] If the gateway itself needs to be diagnosed, and routing forwarding is not required, the diagnostic part of the Ethernet frame is extracted through parsing and processing, and then passed to the gateway's diagnostic protocol module for processing and response.

[0008] If the destination logical address is another node, routing forwarding is required. The diagnostic data is extracted from the Ethernet frame through parsing and processing, and then reassembled into a CAN format diagnostic frame. The frame is then sent through the routing path pre-configured by the software. The destination physical channel is determined by the destination logical address.

[0009] The reassembly process involves protocol conversion, which involves extracting the valid diagnostic request data from the DoIp protocol, splitting the DoIp data blocks according to ISO 15765-2 (Road vehicles, Controller Area Network-based Diagnostic Communication - Part 2: Transport Layer Protocols and Network Layer Services), turning them into small fragments that conform to the CAN diagnostic format, adding the diagnostic request ID of the destination CAN channel, and then sending them.

[0010] This process also includes an implicit logical relationship: the logical destination address of DoIp corresponds to an actual CAN physical channel, and this actual CAN physical channel also corresponds to this set of specific diagnostic request and response IDs.

[0011] The above process occurs during the reception, processing, and forwarding of data message requests. It also includes the reverse routing process after the corresponding CAN channel receives the diagnostic request and responds. This includes: after the DoIp request is converted into CAN diagnostics and transmitted to the in-vehicle CAN slave node via the bus, the CAN node makes a diagnostic response, and the response request is detected on the corresponding CAN physical channel of the gateway.

[0012] The gateway processes the received CAN node requests according to the CAN message format, identifies the diagnostic data within, and reassembles them into Ethernet-format DoIp frames via the routing path configured in the gateway software. This completes the entire diagnostic routing process from DoIp to CAN and from CAN to DoIp.

[0013] The second aspect of this invention provides a diagnostic message protocol conversion scheme between Ethernet and CANFD (Controller Area Network with Flexible Data-Rate, an extension of CAN communication with higher communication rates) nodes in an in-vehicle gateway. Its basic principle is essentially the same as that described in the first aspect, but with the following differences: During the DoIp to CANFD protocol conversion routing process, the maximum length of a CANFD data frame is 64 bytes, while the maximum length of a CAN data frame is 8 bytes. When transmitting large amounts of data, such as during OTA upgrades, CANFD and CAN need to match different CANTP (CAN Transport Protocol) to split long DoIp diagnostic messages (such as downloading software packages) into multiple smaller fragment frames that conform to the CAN / CANFD frame format.

[0014] Correspondingly, the diagnostic routing process for CANFD to DoIp is similar to that for CAN to DoIp, including the establishment of a routing path relationship between the diagnostic response CANFD ID and the destination Ethernet physical channel in advance in the Ethernet gateway software.

[0015] It also includes the gateway node collecting multiple diagnostic fragment frames from CANFD, reassembling them into a larger DoIp frame, and then sending it out from the corresponding Ethernet channel by the gateway.

[0016] A third aspect of this invention provides a solution for implementing diagnostic message protocol conversion between Ethernet and LIN nodes in an in-vehicle gateway, including: The routing path description for DoIp to LIN is as follows: After receiving the DoIp request of the Ethernet frame, the vehicle gateway software processes and identifies the destination logical address of the DoIp. After identifying that the destination address needs to be forwarded to a certain LIN channel, the DoIp protocol processes and intercepts the valid diagnostic data. After passing through the routing path pre-configured by the software, the data is reassembled into a LIN format diagnostic frame and sent to the physical LIN channel corresponding to the destination logical address.

[0017] The implicit logical relationship in this process is that the logical destination address in the DoIP message of the diagnostic request corresponds to an actual LIN physical channel, and this actual LIN physical channel also corresponds to a LIN node ID, i.e., NAD, which will be carried in the LIN diagnostic request and response messages to distinguish which specific LIN physical channel.

[0018] This transmission process also includes unpacking and reassembling the large diagnostic data blocks carried in the DoIp protocol into LIN diagnostic format message data according to the format requirements of LIN TP (ISO17987-2 (LIN Transport Protocol and Network Layer Services)).

[0019] This process also includes requiring software to trigger a switch in the LIN scheduler, switching to the diagnostic scheduler to trigger the issuance of the LIN diagnostic frame header.

[0020] The LIN to DoIp routing path is described as follows: After the LIN node makes a diagnostic response, it sends a LIN diagnostic message to the bus, which is received by the gateway node. The gateway node obtains the valid diagnostic data part through the protocol processing of the LINTP module, and reassembles it into a DoIp message through the preset routing path and sends it to the corresponding Ethernet physical path.

[0021] This enables data routing and protocol conversion between Ethernet and LIN.

[0022] This invention also specifically points out the need to add a spinlock mechanism for cross-core communication, which is used to prevent data contention, ensure data consistency and integrity, and prevent data corruption when multiple cores jointly access shared resources, such as a CAN / LIN data receive buffer.

[0023] This invention also proposes a queue depth and caching mechanism in the routing forwarding mechanism to solve the problem of caching when a large amount of data that needs to be routed is interrupted and cannot be routed out in time, thereby avoiding the loss of routing data.

[0024] Furthermore, a fourth aspect of the present invention provides a diagnostic message routing scheme between Ethernet and Ethernet nodes in an in-vehicle gateway, comprising: Unlike the three aspects mentioned above, where the destination IP and MAC address in the received DoIP frame are from the gateway node, indicating that protocol conversion and routing forwarding need to be completed at the Ethernet gateway, DoIP diagnostic routing between Ethernet connections is implemented through direct Layer 2 pass-through. Data frames are identified and forwarded via MAC addresses, requiring no special software processing; this is handled by the switch's hardware.

[0025] The vehicle gateway integrates a dedicated hardware switch device, which is interconnected with the main MCU of the gateway controller. The switch integrates multiple Ethernet communication ports, which can be connected to multiple vehicle Ethernet nodes.

[0026] A static routing table is configured in the dedicated switch, which is a mapping table between MAC and port, so that it can determine which port of the switch should be sent from based on the destination MAC.

[0027] In addition, the routing and forwarding table mentioned above will limit which VLAN IDs (Virtual Local Area Network Identifier) ​​the destination port supports, thereby filtering packets that can be passed through and realizing the function of an in-vehicle local area network.

[0028] In addition, the switch configuration mentioned above sets up a rule table (ACL whitelist) for each port to specify which Ethernet packets are allowed to pass through and which should be dropped, which can also filter non-business packets and attack packets.

[0029] In summary, this invention provides communication solutions for vehicle gateways, including routing, forwarding, filtering, and protocol conversion. It mainly covers the processing of several message types: CAN / CANFD with Ethernet, LIN with Ethernet, and Ethernet with Ethernet. The intelligent solution provided by this invention improves the overall vehicle communication performance, establishes a foundational platform for remote vehicle diagnostics and rapid parallel OTA upgrades, and provides security filtering against illegal attacks using Ethernet messages.

[0030] The diagnostic messages mentioned in this invention refer to diagnostic frames in the ISO 14229 format. ISO 14229, or Unified Diagnostic Service, is the international standard for diagnostic communication of automotive electronic control units (ECUs). It establishes a unified set of rules for how external diagnostic tools and on-board ECUs should "ask" and "respond". Attached Figure Description

[0031] Figure 1 This is a schematic diagram illustrating the application scenario and network topology of the present invention; Figure 2This is a schematic diagram illustrating the cross-core routing implementation between Ethernet and CAN / CANFD nodes in the vehicle gateway provided by the present invention. Figure 3 A schematic diagram illustrating the cross-core routing implementation between Ethernet and LIN nodes in the vehicle gateway provided by this invention; Figure 4 This is a schematic diagram illustrating the routing implementation between Ethernet and Ethernet nodes in the vehicle gateway provided by the present invention. Detailed Implementation

[0032] The technical solutions in this embodiment will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0033] Furthermore, the technical solutions of the various embodiments of the present invention can be combined with each other, but only if they are feasible for those skilled in the art. If the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.

[0034] like Figure 1 As shown: The main application scenario of this invention is diagnosis and upgrades. Automakers need to perform remote fault diagnosis or OTA firmware parallel upgrades on vehicles via the cloud (backend server). During the R&D or after-sales phases, local diagnosis and upgrades can also be performed by connecting diagnostic equipment through the onboard OBD diagnostic interface. The number and range of diagnostic and upgradeable nodes are related to the number of CAN / CANFD / LIN physical channels supported by the gateway and the number of 100M / 1000M Ethernet channels used by the switch.

[0035] It should be stated that the software modules mentioned in this invention are all derived from the Autosar (Automotive Open System Architecture) definition in the automotive industry standard.

[0036] Taking the OTA refresh process as an example, in the OTA upgrade process, the gateway node does not act as the initiator of the upgrade command, but only handles the reception and routing of the upgrade command.

[0037] The OTA remote upgrade process is described as follows: The cloud sends the upgrade package (containing upgrade package data for multiple ECUs) to the OTA Master initiating node; the OTA Master node receives the upgrade package, accesses the vehicle network via high-speed Ethernet, and initiates a diagnostic refresh DoIp request for the node to be upgraded.

[0038] Use the same source logical address, i.e., the logical address of the OTA Master, in Ethernet DoIP messages, and set the corresponding logical destination address according to the different CAN / LIN / Ethernet nodes to be refreshed.

[0039] CAN / CANFD / LIN nodes cannot directly receive Ethernet frames because these controllers are not equipped with corresponding physical Ethernet channels. Diagnostic requests need to be transmitted through gateway nodes to convert the Ethernet diagnostic data into a parseable CAN / LIN diagnostic format.

[0040] When upgrading these nodes, the destination address of the Ethernet DoIP request is the IP and MAC address of the gateway node.

[0041] Upgrading Ethernet nodes also requires passing through the gateway node, but it does not go through the software processing in the gateway node's MCU; it is only passed through in the Ethernet gateway's switch device.

[0042] When the OTA Master node recognizes the need to refresh the CAN / LIN node, it first attempts to establish a TCPIP connection with the gateway node, and then initiates an Ethernet DoIp activation request. The gateway node processes the TCPIP protocol stack layer by layer, extracts useful DoIp information, identifies the corresponding destination logical address, and searches for the routing channel corresponding to the logical address in the Pdur Routing Table of the PDUR module, thereby determining the physical channel to be routed and forwarded.

[0043] Once the routing path is determined, the diagnostic message will be reassembled via a software link and sent to the corresponding CAN / CANFD / LIN physical path.

[0044] Similarly, after the physical path of CAN / CANFD / LIN receives the request and responds, it is received by the gateway node. If the received message is a CAN / CANFD message, a routing path in the Pdur Routing Table of the PDUR needs to be selected based on the received CANID. If the received message is a LIN message, a path in the Pdur Routing Table of the PDUR needs to be selected based on the node ID (NAD) in the LIN diagnostic message.

[0045] The processing of received CAN / CANFD diagnostic response messages is handled by the CANTP module, which can perform depacketizing and repacketizing according to ISO 15765-2. For example, when a DoIp to CAN / CANFD message is received, CANTP typically needs to depacket it, splitting the large DoIp frame into the first CAN / CANFD diagnostic frame and subsequent frames for transmission. CAN / CANFD responses are small single-frame data that can be directly reassembled for the DoIp. If the response consists of multiple frames including the first frame and subsequent frames, CANTP needs to handle the repacketizing. After collecting and reassembling frames, they are sent to DoIP, then encapsulated in Ethernet frame format and sent out.

[0046] The principle for receiving LIN diagnostic response messages is basically the same as described above, except that LINTP is required to perform packet unpacking and repacking.

[0047] When the OTA Master node needs to upgrade an Ethernet node, the gateway acts as an intermediary, receiving Ethernet packets. The OTA Master node directly performs TCP / IP handshakes and DoIP route activation with the Ethernet node. The MAC and IP addresses in the Ethernet frames belong to the Ethernet node to be upgraded, not the gateway node. However, in terms of hardware connectivity, the OTA Master node and other Ethernet nodes are not directly physically connected; instead, they are connected via a gateway switch. (See reference [link to relevant documentation]). Figure 2 Indication.

[0048] When Ethernet traffic flows into the gateway node, the SWITCH in the gateway node identifies the destination MAC address and looks up the routing table, i.e., the forwarding table of the L2 layer, to determine the correspondence between the destination MAC address and the egress PORT. Finally, the Ethernet DoIP frame is sent out from the PORT connected to the corresponding Ethernet node.

[0049] To achieve this function, the vehicle control device where the gateway is located needs to support multiple physical channels such as CAN, LIN, and Ethernet in its hardware design. During the design, an automotive-grade MCU that supports multiple CAN / LIN controllers was selected. The multiple physical channels of Ethernet are integrated on a dedicated switch chip. Both the switch and the MCU are laid out in the PCB board of the controller and connected by wiring.

[0050] Figure 2 A schematic diagram of the routing implementation between Ethernet and CAN / CANFD nodes of the vehicle gateway provided by the present invention: In a specific embodiment of the present invention, the main MCU chip of the Ethernet gateway controller supports 4 cores. The relevant software component modules of Ethernet are laid out in Core0, the software module of CAN is laid out in Core3, and the software module of LIN is laid out in Core1. Unlike single-core routing, the routing between Ethernet and CAN / LIN is directly completed by a PDUR.

[0051] In this invention, a PDUR software module needs to be allocated to each of the Ethernet core0, CAN core3, and LIN core1 to store the routing table and the data that needs to be routed.

[0052] The specific process of DoIp to DOCAN / CANFD is described as follows: When a T01 Ethernet frame is received by the gateway node, the SWITCH identifies whether the destination MAC address in its TCP / IP packet belongs to the gateway. If it does, the data is transmitted through the SWITCH to the MCU's SGMII connection, and the MCU generates an Ethernet frame receive interrupt.

[0053] Next, basic hardware-level checks (such as CRC checks) will be performed. Then, the Ethernet type field in the Ethernet frame header will be parsed. If EtherType == 0x8000, it indicates that this is an IPv4 packet. This packet will be passed up to the TCP / IP stack module. Then, the IP packet header will be parsed to check if the destination IP address is the address of this ECU. The protocol field in the IP header will be parsed to check if the port number is the 13400 port used by DoIp. Finally, it will reach the DoIp service layer processing module. If it is a diagnostic request, the DoIp module will extract the original UDS diagnostic message from the packet payload.

[0054] It's important to note that the Ethernet gateway requires prior configuration of the gateway's TCP / IP protocol stack parameters in the software configuration. This includes the local machine's IP address, MAC address, supported Ethernet types, static ARP table, supported DoIP protocol version, port number, logical destination address, and logical source address for the DoIP. Crucially, the logical destination address for the DoIP needs to be mapped to the routing source in the PdurRouting Table of the PDUR (Package Directional Access Registry).

[0055] If the logical destination address detected when DoIp route activation is a gateway node, DoIp will be directly established, and the DCM module will handle the diagnostic service and respond. If the logical destination address is another CAN node, the extracted UDS diagnostic message data will be passed to the PDUR module for destination route selection. The PDUR module will then pass it to the CANTP module. After passing through the PDUR module's mapping routing table, the CANTP module will contain the data content, length, CANID, and corresponding CAN channel ID of the CAN message to be sent, which can then be sent through the underlying CAN module driver.

[0056] The T02 process demonstrates how the received CAN diagnostic request response frame is routed into a DoIP message, specifically as follows: The gateway CAN controller receives the corresponding CAN diagnostic data from the bus and notifies the CAN Driver via an interrupt. The CAN Driver reads the data and passes it to the CANIf module. The CANIf module determines whether the frame is a diagnostic frame based on the CAN ID (usually an 11-bit or 29-bit function / physical address diagnostic ID).

[0057] CANIf passes the frame to the CAN Tp module. If multiple frames are received, it reassembles all frames into a complete UDS diagnostic message and passes it up to PduR.

[0058] PduR Module: This is the core decision point in the entire routing process. PduR has an internal routing table. It queries this table based on the source-PDU-ID (i.e., CAN ID) of the received message. It performs a routing decision, queries the PduR Routing Table, and finds that "this diagnostic request from the CAN bus needs to be routed to the DoIp module." Therefore, PduR calls the DoIp module's send interface to pass the complete UDS diagnostic message to the DoIp module.

[0059] The DoIp module is crucial for protocol conversion. Upon receiving the original UDS diagnostic message, the DoIp module encapsulates it with a DoIp header. This header includes: the DoIp protocol version, payload type 0x8001 (diagnostic message), source address (the logical address of the gateway ECU), and destination logical address (the logical source address of the DoIp diagnostic request). The DoIp module then concatenates the DoIp header and the UDS diagnostic message payload into a complete DoIp protocol message.

[0060] Next, the DoIp module passes the assembled DoIp packet to the SoAd module; it then passes the DoIp packet as a payload down to the TCP / IP stack; and instructs the TCP / IP stack to use the target IP address and target port 13400.

[0061] Encapsulate the data transmitted from SoAd with a TCP header (source / destination port = 13400) and an IP header (source / destination IP address).

[0062] Ethernet encapsulation may be added (and a VLAN tag will be added if VLAN is required).

[0063] Ultimately, EthIf calls EthDriver, which writes the data frame into the Ethernet controller's transmit buffer. The Ethernet controller converts the data frame into a bit stream, modulates it using the PHY chip, and then sends it to the vehicle's Ethernet network.

[0064] Figure 3 The schematic diagram of the routing implementation between Ethernet and LIN nodes of the vehicle gateway provided by the present invention is as follows: The specific process is similar to the process of Ethernet DoIp and CAN nodes mentioned above. The main differences are the switching of the LIN scheduling table and the LINTP processing.

[0065] Because LIN communication is controlled and scheduled by the master node, which sends the frame header, the slave node only needs to fill in the missing data. The LIN diagnostic response from the slave node also requires the LIN master node on the gateway to send the diagnostic response frame header. This is also true for subsequent consecutive frames from the slave node, which require the LIN master node on the gateway to continuously send LIN diagnostic response frame headers to continuously respond with data. Therefore, properly controlling the LIN scheduling table becomes a key factor affecting routing.

[0066] The LIN master node is mounted on the gateway, and the slave nodes represent various small electronic switching devices inside the vehicle. Typically, the LIN scheduler operates on the application function's scheduler; however, a diagnostic request requires switching to the diagnostic scheduler.

[0067] After the DoIP request arrives at the PDUR, the LIN diagnostic message cannot be sent directly. Instead, a special software strategy is needed to trigger a LIN scheduler switch request first. The LIN diagnostic message can only be sent after it switches from the application function scheduler to the diagnostic function scheduler. Therefore, the routing time is longer than that of CAN routing.

[0068] The triggering logic for the LIN diagnostic scheduling table here can be as follows: The gateway's PduR module routes the request to the LIN interface (LINIf) or the directly associated LIN transport layer (LINTp) based on the target address. The LINIf / LINTp module notifies the LIN state manager (e.g., LINSM) or the master node scheduler: "There is a diagnostic request to the LIN slave node pending processing." At this point, the LIN master node triggers a scheduling table switch, switching from the normal scheduling table to the diagnostic scheduling table.

[0069] The other differences between LIN and CANTP are also mainly due to the scheduling table mechanism. Unlike CAN, LIN's diagnostic data flow control cannot be achieved by issuing flow control frames to control the transmission of consecutive frames; it also requires the gateway master node to maintain the diagnostic scheduling table. Specifically: Step LINTP_001: The LIN master node, acting as the scheduler, issues a diagnostic request frame header according to the timing of the diagnostic scheduling table. The frame header contains the protected ID and NAD of the frame, fills the diagnostic request data (data packaged by the LINTp module group) into the data field of the frame, and sends it to the bus.

[0070] Step LINTP_002: The slave node receives and processes the request; all slave nodes on the bus receive the complete frame (frame header + data); the target slave node (by matching the NAD address) recognizes that this is a diagnostic request sent to it; the slave node's diagnostic handler prepares the diagnostic response data.

[0071] Step LINTP_003: Gateway Master Node Scheduling Diagnostic Response; After sending the master request frame, the master node immediately (according to the time interval defined in the scheduling table) publishes the header of the slave response frame. This is a crucial "switch": the master node switches from "speaking mode" to "listening mode." Its publishing of the header essentially notifies the slave node that it is its turn to speak.

[0072] Step LINTP_004: The slave node publishes a response. The target slave node identifies the frame header of its own response frame slot. As the publisher of the frame, it fills the diagnostic response data (data packaged by the LINTp module group) into the data field of the frame and sends it to the bus. The master node receives this response data.

[0073] Step LINTP_005: If the diagnostic session needs to be performed continuously (for example, to transmit a long diagnostic data), the master node will execute this diagnostic schedule in a loop, repeating the process from step 1 to step 4 until the entire multi-frame transmission is completed.

[0074] Step LINTP_006: When the diagnostic session ends, the LIN master node will switch back to the normal scheduling table and close the diagnostic window.

[0075] Figure 2 and Figure 3 The routing and forwarding diagram also indicates the data area protected by the spinlock.

[0076] The above example illustrates a multi-core communication layout. In an AUTOSAR gateway running a multi-core OS, PduR is the core of data routing and also the "hotspot" for concurrent contention. The proper application of spinlocks here is crucial for ensuring system performance and stability.

[0077] In a multi-core system, each core runs independently. When executing a routing task, it needs to wait for the corresponding core's task to finish, such as waiting for the PDUR software module to be ready before processing the routing task. When high-speed DoIp transmits large amounts of diagnostic and upgrade data, the core running CAN may not have enough time to switch out the data protocol stack and send it out. Therefore, PDUR allocates some buffers to temporarily store data to be routed. These buffers need to be allocated reasonably based on the maximum data block size that DoIp can transmit, avoiding either excessively large buffers that waste RAM resources or excessively small buffers that result in lost routing data.

[0078] The specific implementation details are as follows: Configuration is done in the Pdur module. Each routing table can reference one source data and one destination data. The source data and destination data each correspond to a software component module, for example, DoIp TO DOCAN. The source data module can originate from DoIp, and the destination data module is associated with CANTP. A Gateway routing relationship is set between the two modules. Appropriate critical protection functions are also set to prevent unexpected interruptions when processing critical data. Finally, the aforementioned buffer settings are also included.

[0079] Each routing table can be associated with a Queue, which contains parameters such as depth, buffer size, and trigger limit. Specifically, the depth indicates how many buffers can temporarily store data, the buffer size indicates how many bytes each buffer can temporarily store, and the trigger limit indicates the maximum amount of data collected that can trigger a transmission to the destination address.

[0080] The size of each buffer needs to be determined based on the actual application. For example, during OTA upgrades, the requirement is that the maximum DoIP data transmitted at one time should not be less than 32K in order to speed up the OTA upgrade. Based on this, at least one 32K buffer should be set to adapt to this, or a slightly smaller buffer can be set to match the case of non-large data blocks.

[0081] The collection of buffer data and the timing of triggering the destination module's limit settings are also important factors affecting forwarding performance. Since the entire OTA process involves commands of varying sizes, it's necessary to comprehensively consider which data size is used most frequently and choose an appropriate value. An excessively large value may lead to slow route triggering, while an excessively small value may trigger too frequently, resulting in untimely processing. After selecting an appropriate value, necessary stress tests should be conducted to ensure the stability and reliability of its forwarding performance.

[0082] The existence of a cache buffer can lead to situations where it is accessed by different cores simultaneously. For example, DoIp needs to continuously store DoIp diagnostic requests in Core0, while CAN in Core3 also needs to retrieve the temporarily stored DoIp diagnostic information and release the buffer. This access conflict may result in data corruption.

[0083] The spinlock mechanism works by having the core that acquires control of the buffer set a flag indicating that it is currently accessing the buffer, and clearing this flag after the access is complete. Other cores then check if any other core is using the buffer before accessing it; if so, they stop accessing it and wait until they are idle before accessing the data in the buffer.

[0084] The resulting latency is allowed to prioritize data integrity and reliability, while PDUR tasks are placed in shorter cycles to improve routing speed.

[0085] Figure 4 A schematic diagram illustrating the Ethernet-to-Ethernet routing implementation of the vehicle gateway provided by this invention: In this embodiment, the VLAN IDs supported by the ports mounted on the switch are limited. After configuration using the switch firmware configuration tool provided by the switch chip manufacturer, the firmware is burned into the switch chip of the gateway. This means that only data traffic from these specific VLANs can be supported on these ports.

[0086] In this embodiment, the VLAN of the PORT port is based on the TRUNK port, which can also be called Port-based. The Ethernet data traffic received by this Port will not be re-labeled with different VLAN IDs; only the traffic of unsupported VLANs will be filtered.

[0087] On the other hand, in this embodiment, the L2 layer forwarding table is left static. Since the network topology for in-vehicle nodes is pre-planned, the IP and MAC addresses of the in-vehicle nodes are also static. The in-vehicle nodes connected to the gateway switch's ports will not change. The correspondence between MAC addresses and ports is thus fixed. Disabling automatic learning of the forwarding table ensures that the routing paths and behaviors between in-vehicle nodes are fixed, and also prevents Ethernet attacks from unauthorized nodes.

[0088] When a DoIP packet whose destination MAC address and IP address are not from the gateway node is received by a gateway Ethernet port, the gateway switch will check the source MAC address and the VLAN ID of the frame to confirm that the VLAN is received by the port. It will then look up the MAC address forwarding table to find the destination port corresponding to the MAC address and confirm that the VLAN is also supported by the destination port. In this case, the VLAN can be successfully forwarded to the destination port.

[0089] In this example, the switch also requires ACL configuration. ACLs are security policies applied to the switch ports to filter and control data flow. Multiple filtering rules can be set for each switch port in the switch's configuration tool, allowing or dropping specific Ethernet traffic. After configuration, switch firmware can be generated and flashed into the switch. The switch will read and execute these configurations each time it is powered on again.

[0090] ACL rules can specify the action to be taken after matching a combination of conditions such as MAC address, IP address, protocol type, VLAN ID, and port number on each switch port, namely, whether to allow passage or to drop it.

[0091] In summary, by combining the strategies mentioned above, such as VLAN, ACL, and fixed forwarding table, effective switch pass-through routing can be achieved, as well as effective security protection against Ethernet attack packets.

Claims

1. A diagnostic message protocol conversion method for a vehicle gateway under a multi-core system, characterized in that, Ethernet bus module, CAN bus module and LIN bus module, The diagnostic message protocol conversion between the Ethernet bus module and the CAN bus module node includes DoIp to CAN and CAN to DoIp, The diagnostic routing path of DoIp to CAN is as follows: The Ethernet material channel of the vehicle gateway node receives the DoIp diagnostic request sent by the OBD or OTA Master node; After the gateway receives the DoIp diagnostic request of the Ethernet frame, the destination logical address of the DoIp is processed and identified, the logical address is judged, and the diagnostic object is determined; If the diagnostic object is the gateway itself, it is not necessary to route and forward, the diagnostic part is extracted by analyzing and processing the Ethernet frame, and is transmitted to the diagnostic protocol module of the gateway for processing and response; If the destination logical address is other node, routing and forwarding are needed, the diagnostic data in the Ethernet frame is extracted by analyzing and processing, and is reassembled into a CAN format diagnostic frame, which is sent through the pre-configured routing path, and the destination physical channel is determined by the destination logical address; In the reassembly process, the effective diagnostic request data of the DoIp protocol is extracted, and the DoIp data is split, the small pieces conforming to the CAN diagnostic format are added with the diagnostic request ID of the destination CAN channel, and are sent; The diagnostic routing path of CAN to DoIp is as follows: After the CAN channel receives the diagnostic request and responds, the DoIp request is converted into a CAN diagnostic and transmitted to the in-vehicle CAN slave node through the bus, and the CAN node makes a diagnostic response, which is detected by the corresponding CAN physical channel of the gateway; The gateway processes the received CAN node request according to the CAN message format, identifies the diagnostic data therein, and reassembles the Ethernet format DoIp frame through the routing path and sends it to the corresponding Ethernet physical channel; The diagnostic message protocol conversion between the Ethernet bus module and the LIN bus module node includes DoIp to LIN and LIN to DoIp, The diagnostic routing path of DoIp to LIN is as follows: The Ethernet material channel of the vehicle gateway node receives the DoIp diagnostic request sent by the OBD or OTA Master node; After the vehicle gateway receives the DoIp diagnostic request of the Ethernet frame, the destination logical address of the DoIp is processed and identified, and the logical address is judged; After identifying that the destination address needs to be forwarded to the LIN channel, the effective diagnostic data is intercepted through the DoIp protocol processing, reassembled into a LIN format diagnostic frame through the pre-configured routing path, and sent to the physical LIN channel corresponding to the destination logical address; The diagnostic routing path of LIN to DoIp is as follows: After the LIN node makes a diagnostic response, a LIN diagnostic message is sent to the bus and received by the gateway node, the effective diagnostic data is obtained through the protocol processing of the LIN TP module, and is reassembled into a DoIp message and sent to the responding Ethernet physical channel through the pre-set routing path; The diagnostic message protocol conversion between the Ethernet bus module and the Ethernet bus module node is identified and forwarded by MAC address, and is completed by the hardware device of the switch. The switch is connected with the main MCU of the gateway controller. The switch is integrated with multiple Ethernet communication PORT ports, which are connected with multiple vehicle-mounted Ethernet nodes respectively. The switch is configured with a static routing forwarding relationship table, so as to determine from which port of the switch the message should be sent according to the destination MAC.

2. The method of claim 1, wherein the diagnostic message protocol conversion of the in-vehicle gateway in the multi-core system is performed by a processor of the in-vehicle gateway. In the diagnostic routing path from DoIp to CAN, the logical correspondence between the destination address of DoIp and the physical channel of CAN is established in advance in the Ethernet gateway software.

3. The method of claim 2, wherein the diagnostic message protocol conversion of the in-vehicle gateway in the multi-core system is characterized by, In the diagnostic routing path from DoIp to CAN, the logical destination address of DoIp corresponds to an actual CAN physical channel, and the actual CAN physical channel also corresponds to specific diagnostic request and response IDs.

4. The method of claim 1, wherein the diagnostic message protocol conversion of the in-vehicle gateway in the multi-core system is characterized by, In the diagnostic routing path from DoIp to LIN, the logical destination address of DoIp corresponds to an actual LIN physical channel, and the actual LIN physical channel also corresponds to the node ID of LIN, which is carried in the diagnostic request and response messages of LIN and used to distinguish specific LIN physical channels.

5. The method of claim 4, wherein the diagnostic message protocol conversion of the in-vehicle gateway in the multi-core system is characterized by, In the diagnostic routing path from DoIp to LIN, the sending process includes unpacking and assembling the large diagnostic data block carried in the DoIp protocol into LIN diagnostic format message data according to the format requirements of LIN TP.

6. The method of claim 1, wherein the diagnostic message protocol conversion of the in-vehicle gateway in the multi-core system is characterized by, The spin lock module is also included, which is used for preventing data competition, ensuring data consistency and integrity, and preventing data disorder when multiple cores access the shared resource room.

7. The method of claim 1, wherein the diagnostic message protocol conversion of the in-vehicle gateway in the multi-core system is performed by a processor. The switch is configured with a static routing forwarding relationship table for the correspondence between MAC and PORT.

8. The method according to claim 7, wherein, The routing forwarding relationship table can limit the VLAN ID supported by the destination port to filter the transmittable messages.

9. The method of claim 7, wherein the diagnostic message protocol conversion of the in-vehicle gateway in the multi-core system is performed by a processor. The switch is configured to set the rule table of the Ethernet allowed to pass and needed to be discarded for each PORT, so as to filter non-service messages and attack messages.

Images