A dual-mode heterogeneous CAN-SPI secure communication architecture of an intelligent cockpit CSC domain controller

Abstract

This application discloses a dual-mode heterogeneous CAN-SPI secure communication architecture for a smart cockpit CSC domain controller, relating to the field of vehicle secure communication. It is built on a dual-chip heterogeneous architecture of MCU+SOC and includes: a core functional module, a dual-mode communication channel, an intelligent routing unit, and an E2E functional safety protection unit. The core functional module includes a CtApSig2SOC master scheduler, a CANFwSpi CAN forwarding engine, an IPCL adaptation layer, an E2E protection module, a differentiated transmission module, and a CtApSocSigRx SOC-side receiver. The CtApSig2SOC master scheduler is the main scheduling core. The dual-mode communication channel includes a standard SPI mode channel and an IPCL high-speed mode channel, configured with dynamic switching based on handshake signals and automatic fault degradation. The intelligent routing unit has a built-in CAN ID attribute configuration table and correspondingly sets a three-level routing strategy for table lookup decisions. The E2E functional safety protection unit integrates a verification and protection mechanism. The dual-mode heterogeneous CAN-SPI secure communication architecture of the smart cockpit CSC domain controller is compatible with the AUTOSAR architecture and toolchain.

Description

Technical Field

[0001] This application relates to the field of vehicle safety communication, and in particular to a dual-mode heterogeneous CAN-SPI secure communication architecture for a smart cockpit CSC domain controller, a CAN-SPI adaptive routing method for a smart cockpit CSC domain controller, electronic devices, and storage media. Background Technology

[0002] With the rapid development of the "new four modernizations" of automobiles (electrification, intelligence, connectivity, and sharing), the intelligent cockpit has become a core area for vehicle differentiation. Traditional cockpits employ a distributed ECU architecture, with functions such as instrument clusters, infotainment, and air conditioning implemented by independent controllers. These ECUs communicate via CAN / LIN buses, resulting in a complex system with low resource utilization. Entering the domain controller era, the industry generally adopts a dual-chip intelligent cockpit domain controller (CSC) architecture, combining an MCU and a SOC.

[0003] MCU (Microcontroller Unit, Safety Domain): Typically, automotive-grade MCUs conforming to functional safety ASIL-B / D levels (such as Infineon TC3xx, Renesas RH850) are selected. They are responsible for high real-time and high-safety body control functions, manage multiple CAN / LIN buses (backbone CAN, information CAN, diagnostic CAN, etc.), and handle KL15 power management, network management, E2E secure communication, etc.

[0004] The System-on-Chip (SOC) (High-Performance Domain) utilizes high-performance MPUs (such as Qualcomm 8155 / 8295, SemiDrive X9SP, and ECARX Longying-1) to handle complex applications like infotainment, full LCD instrument clusters, AR-HUD rendering, and voice recognition, running a hybrid QNX / Android operating system. This heterogeneous architecture physically separates functional safety and performance requirements, but it presents significant challenges for cross-domain communication: a high-speed, reliable, and secure channel is needed between the MCU and the SOC to transmit massive amounts of CAN signals, which traditional communication solutions cannot meet. Traditional solutions force parsing and forwarding of all CAN signals at the signal level, requiring packet disassembly and reassembly for both diagnostic full-packet messages and OTA data volume scenarios, resulting in enormous processing overhead. Furthermore, platform reusability is poor, requiring underlying reconstruction for migration, significantly increasing the development cycle.

[0005] Therefore, there is an urgent need for a CAN-SPI adaptive routing strategy for a smart cockpit CSC domain controller. This strategy should be implemented through a modular SOC signal forwarding component, retaining standard SPI routing and being compatible with the original autosar architecture. It should automatically select full packet pass-through, signal-level parsing, or hybrid mode through a configuration table, and add functional safety mechanisms to ensure the real-time performance of critical signals. Summary of the Invention

[0006] The purpose of this invention is to provide a dual-mode heterogeneous CAN-SPI secure communication architecture for a smart cockpit CSC domain controller, a CAN-SPI adaptive routing method for a smart cockpit CSC domain controller, an electronic device, and a storage medium, thereby solving at least one of a number of technical problems.

[0007] Core technical challenges include: traditional communication solutions incurring huge processing overhead and high transmission latency; limited communication modes that fail to balance compatibility and high-speed transmission; lack of refined signal routing strategies leading to low resource utilization; poor platform reusability and long development cycles due to hard-coded design; lack of robust functional safety protection for cross-domain communication, failing to meet automotive-grade requirements; limited signal transmission strategies resulting in unreliable transmission of critical control signals; significant differences in interfaces across different chip platforms, making cross-platform adaptation difficult; and poor compatibility between new and old solutions, leading to high costs for upgrading and modifying existing projects.

[0008] This invention provides the following solution:

[0009] According to a first aspect of the present invention, a dual-mode heterogeneous CAN-SPI secure communication architecture for a smart cockpit CSC domain controller is provided, based on a dual-chip heterogeneous architecture of MCU+SOC. The dual-mode heterogeneous CAN-SPI secure communication architecture for the smart cockpit CSC domain controller includes:

[0010] Core functional modules, dual-mode communication channel, intelligent routing unit and E2E functional safety protection unit;

[0011] The core functional modules include the CtApSig2SOC master scheduler, CANFwSpi CAN forwarding engine, IPCL adaptation layer, E2E protection module, differentiated transmission module, and CtApSocSigRx SOC side receiver.

[0012] Among them, the CtApSig2SOC master scheduler is the main scheduling core;

[0013] The dual-mode communication channels include a standard SPI mode channel and an IPCL high-speed mode channel, with dynamic switching based on handshake signals and automatic fault degradation.

[0014] The intelligent routing unit has a built-in CAN ID attribute configuration table and a corresponding three-level routing strategy for table lookup decision-making;

[0015] E2E functional safety protection unit, integrating verification and protection mechanisms;

[0016] The intelligent cockpit CSC domain controller features a dual-mode heterogeneous CAN-SPI secure communication architecture that is compatible with the AUTOSAR architecture and toolchain.

[0017] Furthermore, including:

[0018] The CtApSig2SOC master scheduler runs periodically and switches the working mode of the dual-mode communication channel according to the handshake flag.

[0019] The CANFwSpi CAN forwarding engine has corresponding CAN signal attribute tables for DLC8 and DLC16 specifications, which are used to store CANID attribute information and routing configuration parameters.

[0020] Furthermore, including:

[0021] The IPCL adapter layer encapsulates the differences in communication interfaces and unifies the CAN-SPI transmission interface;

[0022] Hardware-level transmission of CAN data is performed based on DMA zero-copy technology.

[0023] The CtApSocSigRx SOC-side receiver is used to parse the TypeID of the SPI frame and distribute the parsed commands to each software component (SWC).

[0024] Furthermore, including:

[0025] The standard SPI mode channel communication path is CddCan2Spi→CddSpiServer, and the conversion and transmission of CAN-SPI signals are completed through the PduR, Com, and CanIf layers.

[0026] The IPCL high-speed mode channel fills CAN data into the IPCL shared memory, and the data transfer is completed by DMA.

[0027] Furthermore, including:

[0028] The dual-mode communication channel employs a dynamic switching mechanism:

[0029] When the IPCL driver is not initialized or compatibility is prioritized, the standard SPI mode is enabled by default.

[0030] After successful handshake signal detection, switch to IPCL high-speed mode;

[0031] When an IPCL high-speed mode fault is detected, it automatically degrades to standard SPI mode.

[0032] Furthermore, including:

[0033] The architecture supports multi-channel QoS hierarchical protection, dividing different transmission channels according to the security level and real-time requirements of CAN signals, realizing the separate transmission of E2E signals, non-E2E signals, diagnostic messages, and body control signals, thus avoiding signal blockage.

[0034] The MCU is an automotive-grade MCU that meets the functional safety level ASIL-B / D, and the SOC is a high-performance MPU that supports a hybrid QNX / Android operating system.

[0035] According to a second aspect of the present invention, a CAN-SPI adaptive routing method for a smart cockpit CSC domain controller is provided, based on a dual-mode heterogeneous CAN-SPI secure communication architecture of the smart cockpit CSC domain controller. The CAN-SPI adaptive routing method for the smart cockpit CSC domain controller includes:

[0036] S1, Architecture Initialization;

[0037] Among them, the CtApSig2SOC master scheduler starts and periodically monitors the IPCL driver initialization status and PpHandshake_DeHandshake() handshake signal, and selects the standard SPI mode or IPCL high-speed mode to establish a communication channel.

[0038] S2, CANFwSpi CAN forwarding engine reads the preset CAN ID attribute configuration table and performs attribute identification on the CAN signals entering the architecture;

[0039] S3. The intelligent routing unit selects a three-level routing strategy (full packet transparent transmission, signal-level parsing, or mixed mode) from the CAN ID attribute configuration table based on the attributes of the CAN signal to perform routing processing on the CAN signal.

[0040] The S4 and E2E functional safety protection units perform triple verification protection processing on CAN signals that require safety protection. Among them, the differentiated transmission module adopts a hybrid trigger transmission mechanism to transmit the CAN signals after routing processing.

[0041] The S5 and CtApSig2SOC master schedulers monitor the status of the communication channels in real time.

[0042] If an IPCL high-speed mode fault is detected, the channel dynamic degradation mechanism is triggered, switching to standard SPI mode.

[0043] S6, SOC and MCU complete bidirectional forwarding and interaction of CAN-SPI signals based on the communication channels and routing strategies in steps S1 to S5, realizing cross-domain communication of the intelligent cockpit.

[0044] Furthermore, the processing flow of the E2E functional safety protection unit in step S4 is as follows:

[0045] Step S41 Transmitter MCU: Enable E2E configuration for the CAN signal that needs protection, call the function to calculate the CRC value and fill it into the specified position of the CAN data frame, and at the same time fill the LiveCounter count value into the 0th byte of the CAN data frame and complete the auto-increment;

[0046] Step S42 Receiver SOC: Extract the LiveCounter count value and verify its continuity through the CtApSocSigRx SOC-side receiver, recalculate the CRC value and compare it with the received value;

[0047] Step S43 Fault Handling: If CRC check or LiveCounter check errors are detected continuously, immediately trigger the security degradation channel and switch to fault protection transmission mode.

[0048] Furthermore, it also includes the SPI to CAN signal forwarding sub-step from SOC to MCU, specifically:

[0049] S61 and SOC sides: After the application layer triggers a control event, the middleware encapsulates the control signal into a custom SPI frame.

[0050] An SPI frame includes a typeid, a length, and a data field. The data field stores the signal ID and control data.

[0051] S62, the MCU side receives SPI frames through the RTE interface, parses the signal ID and control data in the frame, and matches the corresponding body control function;

[0052] S63. The mapping of control signals to CAN messages is completed through the CAN ID attribute configuration table. The COM layer assembles the control signals into the specified bits of the specified CAN message according to the preset parameters.

[0053] S64. The assembled CAN message is sent to the corresponding body control module through the CANIf layer to complete the transmission of control commands.

[0054] Furthermore, including:

[0055] The CAN ID attribute configuration table is a gMcuForwardCANattri array, which includes the routing attributes, E2E configuration, timeout threshold and platform adaptation parameters for each built-in CAN ID;

[0056] This involves modifying parameters in the configuration table for vehicle model adaptation or platform migration.

[0057] According to a third aspect of the present invention, an electronic device is provided, comprising: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus;

[0058] The memory stores a computer program that, when executed by the processor, causes the processor to perform steps such as the CAN-SPI adaptive routing method of the Smart Cockpit CSC domain controller.

[0059] According to a fourth aspect of the present invention, a computer-readable storage medium is provided, comprising: storing a computer program executable by an electronic device, wherein when the computer program is run on the electronic device, the electronic device causes the electronic device to perform steps such as the Smart Cockpit CSC Domain Controller CAN-SPI Adaptive Routing Method.

[0060] The above solution achieves the following beneficial technical effects:

[0061] This application skips the protocol conversion layer through IPCL high-speed mode, reducing cross-domain communication latency by 3ms, thus meeting the transmission requirements of high real-time signals such as vehicle body control and instrument display.

[0062] This application uses DMA zero-copy technology to enable CAN data to be transmitted directly by the hardware controller without the CPU performing memcpy() operations, achieving zero CPU intervention and significantly reducing the processor resource overhead of MCU / SOC;

[0063] This application avoids the unpacking and repackaging operations of diagnostic messages and OTA data volumes by using the whole-packet transparent transmission mode, and directly encapsulates the original CAN frame for transmission, thus improving data processing efficiency several times.

[0064] This application achieves 99.9% CRC check coverage through a triple E2E protection mechanism. LiveCounter effectively prevents message loss, out-of-order delivery and replay attacks. Independent timeout monitoring blocks invalid signals, which can meet the functional safety requirements of ASIL-D (the highest automotive grade).

[0065] This application achieves fault tolerance and degraded operation by triggering a security degradation channel through continuous errors and automatically degrading to standard SPI mode within 100ms of IPCL failure, ensuring the continuity of cross-domain communication and avoiding communication interruption caused by single point of failure.

[0066] This application uses a hybrid mode to process E2E / non-E2E signals in parallel through separate channels, avoiding the blocking of high-safety-level signals and ensuring the reliability of transmission of critical vehicle body control signals.

[0067] This application is compatible with the AUTOSAR toolchain and existing communication solutions through a dual-mode architecture, allowing existing projects to be upgraded without reconstructing the underlying layer, which greatly reduces the transformation cost and upgrade risk.

[0068] This application uses a configuration table-driven routing design to allow vehicle model adaptation to only require modification of the CAN ID attribute configuration table, eliminating the need for hard-coding development, reducing the development cycle by more than 80%, and significantly improving platform reusability.

[0069] This application decouples the functional modules through modular component design, supports independent debugging and upgrades, and significantly improves the efficiency of solution maintenance and iteration.

[0070] This application uses a hybrid trigger transmission mechanism to immediately send signals when they change, ensuring the real-time nature of manual operation signals such as seat heating and air conditioning control; when there is no change, the signals are periodically retransmitted to avoid abnormal vehicle control caused by signal interruption and to ensure signal validity.

[0071] This application achieves rapid switching of communication modes through a periodic master scheduler, meeting the real-time requirements of mode switching and adapting to dynamic changes in vehicle body control scenarios.

[0072] This application encapsulates the interface and driver differences of platforms such as ECARX / Qualcomm through the IPCL layer, providing a unified and standardized communication interface. When developing CSC domain controllers for different platforms, there is no need to redesign the underlying communication layer, reducing cross-platform adaptation costs by more than 70%.

[0073] This application adapts to the transmission requirements of different types and security levels of signals through a multi-channel QoS hierarchical design, and can be directly reused in vehicle projects of different brands and configurations, significantly improving the versatility and industrialization value of the solution.

[0074] This application achieves on-demand allocation of communication resources through a three-level routing strategy: diagnostic messages are transmitted as whole packets, vehicle control signals are parsed at the signal level, and mixed safety level signals are transmitted through separate channels, thereby avoiding the ineffective occupation of communication resources and improving the overall resource utilization rate.

[0075] This application's solution supports the SOC platform with a hybrid QNX / Android operating system, and can adapt to the signal transmission needs of various smart cockpit scenarios such as infotainment, full LCD instrument panel, and AR-HUD rendering, achieving full coverage with one solution. Attached Figure Description

[0076] Figure 1 This is a structural diagram of a dual-mode heterogeneous CAN-SPI secure communication architecture for a smart cockpit CSC domain controller provided in one or more embodiments of the present invention.

[0077] Figure 2 This is a flowchart of a CAN-SPI adaptive routing method for a smart cockpit CSC domain controller provided in one or more embodiments of the present invention.

[0078] Figure 3 This is a schematic diagram of CAN signal routing SPI data stream provided in a specific embodiment of the present invention. Figure 1 .

[0079] Figure 4 This is a schematic diagram of CAN signal routing SPI data stream provided in a specific embodiment of the present invention. Figure 2 .

[0080] Figure 5This is an electronic device structure block diagram of an intelligent cockpit CSC domain controller CAN-SPI adaptive routing method provided in one or more embodiments of the present invention. Detailed Implementation

[0081] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. 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.

[0082] Figure 1 This is a structural diagram of a dual-mode heterogeneous CAN-SPI secure communication architecture for a smart cockpit CSC domain controller provided in one or more embodiments of the present invention.

[0083] like Figure 1 The dual-mode heterogeneous CAN-SPI secure communication architecture of the intelligent cockpit CSC domain controller shown is built on a dual-chip heterogeneous architecture of MCU + SOC. The dual-mode heterogeneous CAN-SPI secure communication architecture of the intelligent cockpit CSC domain controller includes:

[0084] The core functional modules, dual-mode communication channels, configuration table-driven intelligent routing units, and E2E functional safety protection units interact with each other through automotive-grade buses and software interfaces.

[0085] The core functional modules include the CtApSig2SOC master scheduler, CANFwSpi CAN forwarding engine, IPCL adaptation layer, E2E protection module, differentiated transmission module, and CtApSocSigRx SOC side receiver.

[0086] Among them, the CtApSig2SOC main scheduler is the main scheduling core and establishes signal interaction connections with the other core functional modules.

[0087] The dual-mode communication channels include a standard SPI mode channel and an IPCL high-speed mode channel, supporting dynamic switching based on handshake signals and automatic fault degradation.

[0088] The intelligent routing unit includes a built-in CAN ID attribute configuration table, supporting a three-level routing strategy that makes decisions based on the table lookup.

[0089] The E2E functional safety protection unit integrates a triple verification protection mechanism to provide full-process safety protection for CAN signals transmitted across CAN-SPI domains.

[0090] The dual-mode heterogeneous CAN-SPI secure communication architecture of the intelligent cockpit CSC domain controller is compatible with the AUTOSAR architecture and toolchain, and achieves cross-chip platform interface unification through the IPCL adaptation layer.

[0091] In this embodiment, it includes:

[0092] The CtApSig2SOC master scheduler runs with a 10ms cycle and switches the working mode of the dual-mode communication channel according to the handshake flag.

[0093] The CANFwSpi CAN forwarding engine maintains 67 DLC8 and 10 DLC16 CAN signal attribute tables, which are used to store CAN ID attribute information and routing configuration parameters.

[0094] In this embodiment, it includes:

[0095] The IPCL adapter layer encapsulates the communication interface differences between ECARX and Qualcomm chip platforms, providing a unified CAN-SPI transmission interface and supporting DMA zero-copy technology to achieve hardware-level transmission of CAN data.

[0096] The CtApSocSigRx SOC-side receiver is used to parse the TypeID of the SPI frame and distribute the parsed commands to each software component (SWC).

[0097] In this embodiment, it includes:

[0098] The standard SPI mode channel communication path is CddCan2Spi→CddSpiServer, which follows the AUTOSAR architecture layering specification and completes the conversion and transmission of CAN-SPI signals through the PduR, Com, and CanIf layers.

[0099] The IPCL high-speed mode channel skips the protocol conversion layer and directly fills the CAN data into the IPCL shared memory. The data transmission is automatically completed by the DMA engine, reducing cross-domain communication latency by 3ms.

[0100] In this embodiment, it includes:

[0101] The dual-mode communication channel employs a dynamic switching mechanism:

[0102] When the IPCL driver is not initialized or compatibility is prioritized, the standard SPI mode is enabled by default.

[0103] After successful handshake signal detection, switch to IPCL high-speed mode;

[0104] When an IPCL high-speed mode fault is detected, it automatically downgrades to standard SPI mode within 100ms.

[0105] The DMA zero-copy technology is implemented by directly passing the CAN receive buffer address to the DMA controller without executing the memcpy() operation, thus achieving data transmission with zero CPU intervention.

[0106] In this embodiment, it includes:

[0107] The configuration and execution rules for the Level 3 routing policy include:

[0108] Full packet transparent transmission: For diagnostic messages, whose CAN ID is in the 0x7XX segment, mE2EType=FALSE is configured to directly encapsulate the original CAN frame. The original CAN frame contains ID, DLC, Data and timestamp information, without signal-level parsing and processing.

[0109] Signal-level analysis: For body control signals, configure mFwSupAndroid=TRUE to extract physical signal values ​​from CAN frames and complete cross-component signal transmission through the RTE interface;

[0110] Hybrid mode: For scenarios where the same CAN frame contains both E2E and non-E2E signals, the E2E signals use the CRC protection channel, while the non-E2E signals use the standard channel, allowing for parallel processing of both signals without blocking.

[0111] In this embodiment, it includes:

[0112] The E2E functional safety protection unit's triple-check protection mechanism includes CRC check, LiveCounter continuity check, and independent timeout monitoring, specifically:

[0113] CRC check: The CRC-8 lookup table method is used, which includes the CAN ID in the calculation range and excludes the CRC itself from the data bits, achieving a check coverage of 99.9%.

[0114] LiveCounter continuity check: The 0th byte of each CAN data frame is filled with an automatically incrementing count value. The SOC side checks the continuity of the count value. A difference of ≤1 indicates that the check has passed.

[0115] Independent timeout monitoring: Configure an independent timer for each CAN signal. The timeout threshold can be customized. When a signal times out, only an error status is sent, and invalid signals are blocked.

[0116] In this embodiment, it includes:

[0117] The differentiated transmission module adopts a hybrid triggering transmission mechanism of data change detection + periodic retransmission. When a change in CAN signal data is detected, signal transmission is triggered immediately; when there is no change in signal data, retransmission is performed according to a preset period, taking into account both the real-time performance and effectiveness of signal transmission.

[0118] In this embodiment, it includes:

[0119] The architecture supports multi-channel QoS hierarchical protection, dividing different transmission channels according to the security level and real-time requirements of CAN signals, realizing the separate transmission of E2E signals, non-E2E signals, diagnostic messages, and body control signals, thus avoiding signal blockage.

[0120] The MCU is an automotive-grade MCU that meets the functional safety level ASIL-B / D, and the SOC is a high-performance MPU that supports a hybrid QNX / Android operating system.

[0121] Figure 2 This is a flowchart of a CAN-SPI adaptive routing method for a smart cockpit CSC domain controller provided in one or more embodiments of the present invention.

[0122] like Figure 2 The illustrated CAN-SPI adaptive routing method for a smart cockpit CSC domain controller is based on a dual-mode heterogeneous CAN-SPI secure communication architecture of the smart cockpit CSC domain controller. The CAN-SPI adaptive routing method for the smart cockpit CSC domain controller includes:

[0123] S1, Architecture Initialization;

[0124] Among them, the CtApSig2SOC master scheduler starts and periodically monitors the IPCL driver initialization status and PpHandshake_DeHandshake() handshake signal, and selects the standard SPI mode or IPCL high-speed mode to establish a communication channel.

[0125] S2, CANFwSpi CAN forwarding engine reads the preset CAN ID attribute configuration table and performs attribute identification on the CAN signals entering the architecture;

[0126] S3. The intelligent routing unit selects a three-level routing strategy (full packet transparent transmission, signal-level parsing, or mixed mode) from the CAN ID attribute configuration table based on the attributes of the CAN signal to perform routing processing on the CAN signal.

[0127] The S4 and E2E functional safety protection units perform triple verification protection processing on CAN signals that require safety protection. Among them, the differentiated transmission module adopts a hybrid trigger transmission mechanism to transmit the CAN signals after routing processing.

[0128] The S5 and CtApSig2SOC master schedulers monitor the status of the communication channels in real time.

[0129] If an IPCL high-speed mode fault is detected, the channel dynamic degradation mechanism is triggered, switching to standard SPI mode.

[0130] S6, SOC and MCU complete bidirectional forwarding and interaction of CAN-SPI signals based on the communication channels and routing strategies in steps S1 to S5, realizing cross-domain communication of the intelligent cockpit.

[0131] In this embodiment, the processing flow of the E2E functional safety protection unit in step S4 is as follows:

[0132] Step S41 Transmitter MCU: Enable E2E configuration for the CAN signal that needs protection, call the E2E_Calculate() function to calculate the CRC value and fill it into the specified position of the CAN data frame, and at the same time fill the LiveCounter count value into the 0th byte of the CAN data frame and complete the auto-increment;

[0133] Step S42 Receiver SOC: Extract the LiveCounter count value and verify its continuity through the CtApSocSigRx SOC-side receiver, and call the E2E_Check() function again to calculate the CRC value and compare it with the received value;

[0134] Step S43 Fault Handling: If CRC check or LiveCounter check errors are detected three times consecutively, the security degradation channel is immediately triggered, and the system switches to fault protection transmission mode.

[0135] In this embodiment, the SPI to CAN signal forwarding sub-step from SOC to MCU is also included, specifically as follows:

[0136] S61 and SOC sides: After the application layer triggers a control event, the middleware encapsulates the control signal into a custom SPI frame.

[0137] An SPI frame includes a typeid, a length, and a data field. The data field stores the signal ID and control data.

[0138] S62, the MCU side receives SPI frames through the RTE interface, parses the signal ID and control data in the frame, and matches the corresponding body control function;

[0139] S63. The mapping of control signals to CAN messages is completed through the CAN ID attribute configuration table. The COM layer assembles the control signals into the specified bits of the specified CAN message according to the preset parameters.

[0140] S64. The assembled CAN message is sent to the corresponding body control module through the CANIf layer to complete the transmission of control commands.

[0141] In this embodiment, it includes:

[0142] The CAN ID attribute configuration table is a gMcuForwardCANattri array, which includes the routing attributes, E2E configuration, timeout threshold and platform adaptation parameters for each built-in CAN ID;

[0143] This involves maintaining the original underlying code while modifying the parameters in the configuration table for vehicle model adaptation or platform migration.

[0144] It is worth noting that although this system / device only discloses the above-mentioned modules / units, it does not mean that this system / device is limited to the above-mentioned basic functional modules. On the contrary, what this invention intends to express is that, based on the above-mentioned basic functional modules, those skilled in the art can add one or more functional modules in combination with the prior art to form an infinite number of embodiments or technical solutions. That is to say, this system is open rather than closed. It cannot be assumed that the scope of protection of the claims of this invention is limited to the above-disclosed basic functional modules just because this embodiment only discloses a few basic functional modules.

[0145] In one specific embodiment, a dual-mode heterogeneous CAN-SPI secure communication architecture and adaptive routing method for a smart cockpit CSC domain controller are disclosed. This is implemented through a modular SOC signal forwarding component, retaining standard SPI routing and being compatible with the original autosar architecture. It automatically selects full packet transparent transmission, signal-level parsing, or a hybrid mode through a configuration table, adding functional safety mechanisms to ensure the real-time performance of critical signals. Figure 3 , 4 The core modules are explained, including... Figure 3 It's a Qualcomm platform. Figure 4 It is the ECARX platform:

[0146] CtApSig2SOC: The main scheduler runs in 10ms cycles and switches working modes based on handshake flags.

[0147] CANFwSpi: CAN forwarding engine, maintaining signal attribute tables for 67 channels of DLC8 and 10 channels of DLC16, etc.

[0148] IPCL layer: encapsulates the differences between ECARX and Qualcomm platforms, provides a unified sending interface, and supports DMA zero-copy;

[0149] E2E Protection Module: Integrates triple protection including CRC calculation, LiveCounter management, and timeout monitoring;

[0150] Differentiated transmission module: Implements a hybrid strategy of data change detection and periodic retransmission;

[0151] CtApSocSigRx: SOC-side receiver, which parses the TypeID and distributes commands to each SWC.

[0152] In this embodiment, a dual-mode channel switching mechanism is established, wherein the mode selection logic includes:

[0153] Standard SPI mode: When the IPCL driver is not initialized or compatibility is prioritized, the traditional CddCan2Spi→CddSpiServer path is followed to ensure the availability of the AUTOSAR toolchain;

[0154] IPCL High-Speed ​​Mode: After a successful handshake, CAN data is directly filled into the IPCL shared memory, and the DMA engine automatically transfers the data, skipping the protocol conversion layer and reducing latency by 3ms.

[0155] Dynamic switching: Real-time monitoring via the PpHandshake_DeHandshake() signal; Automatically downgrades to standard mode within 100ms in case of IPCL failure.

[0156] Zero-copy implementation: In IPCL mode, the CAN receive buffer address is directly passed to DMA without the need for memcpy() operation, and the CPU intervenes zero.

[0157] In this embodiment, an intelligent routing decision algorithm is run, including a three-level routing strategy:

[0158] Full packet transparent transmission: The diagnostic message (ID0x7XX) is configured with mE2EType=FALSE, directly encapsulating the original CAN frame (ID+DLC+Data) and retaining the timestamp information;

[0159] Signal-level analysis: The vehicle control signal (such as BCM1_1) is configured with mFwSupAndriod=TRUE to extract physical signal values ​​such as vehicle speed and engine speed, and send them through the RTE interface;

[0160] Hybrid mode: E2E signals (such as 0x120) within the same frame use the CRC protection channel, while non-E2E signals (such as 0x208) use the standard channel, allowing for parallel processing without blocking;

[0161] Configuration table driven: The attributes of each CAN ID are preset in the gMcuForwardCANattri array, and the decision is made by looking up the table at runtime. No hard coding is required, and vehicle model adaptation only requires modifying the configuration table.

[0162] In this embodiment, an E2E functional safety protection mechanism is provided, including a triple verification design:

[0163] CRC check: CRC-8 lookup table method is used, CAN ID is involved in the calculation, and the data bits exclude the CRC itself, with a coverage rate of 99.9%;

[0164] LiveCounter: The 0th byte of each data frame is automatically incremented, and the SOC side checks the continuity to prevent message loss or out-of-order delivery.

[0165] Timeout monitoring: Each signal has an independent timer, and the timeout threshold is configurable (e.g., 2 seconds). Error status is only sent after the timeout.

[0166] In another specific embodiment, an embodiment 1 is disclosed: a full-process verification of the E2E security protection mechanism, specifically including:

[0167] Test signal: ASIL-D level 0x120 (EGSM_1), period 10ms, DLC=8 bytes;

[0168] Solution execution process:

[0169] 1. Transmitter MCU Configuration

[0170] {TRUE,TRUE,FALSE,0u,0u,100u,0u,2u,0u,FALSE,0x120u,8u};

[0171] / / Meaning: E2E enabled, supports forwarding, QNX only, 2-second timeout, 20ms check cycle

[0172] 2. CRC calculation injection (E2ECAN_Forward_SPI() lines 650-680):

[0173] Receive CAN data: uint8_tcan_data[8]={0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08};

[0174] Calling E2E_Calculate(0x120,can_data,8) returns CRC=0x3B;

[0175] Fill to gMcuForwardE2ECANStDlc8[INDEX_EGSM_1].mData[7]=0x3B;

[0176] LiveCounter is populated with mData[0] and incremented;

[0177] 3. Receiver SOC verification (CtApSocSigRx component):

[0178] Extract LiveCounter and verify its continuity (difference should be ≤1).

[0179] Call E2E_Check() to recalculate the CRC and compare it with the received value;

[0180] Error rate statistics: Three consecutive errors trigger the security downgrade channel.

[0181] In another specific embodiment, an embodiment 2 is disclosed: an example of SOC→MCUSPI forwarding routing (signal to CAN), which specifically includes:

[0182] Scenario: When a user clicks the "seat heating switch" on the SOC-side central control screen, the control signal needs to be sent to the MCU via SPI. The MCU then converts the signal into a CAN message and sends it to the seat control module.

[0183] Step 1: SOC-side signal encapsulation. When the user triggers the SEAT_HEATER_ON event at the Android application layer, the SOC middleware encapsulates it into an SPI frame:

[0184] / / SPI data frame generated on the SOC side

[0185] IdtSpiData_14soc_cmd_frame={

[0186] .typeid=0xF9, / / SOC→MCU signal type

[0187] .length=10, / / Signal ID (2 bytes) + data (4 bytes) + padding

[0188] .data={0x3A,0x45,0x01,0x00,0x00,0x00,0x00,0x00,0x00,0x00}

[0189] / / Signal ID=0x3A45 (seat heating request), Data=0x01 (on)

[0190] };

[0191] struct structure definition:

[0192] typedef struct {

[0193] uint8mHead;

[0194] uint16mLength;

[0195] uint8mTypeId;

[0196] uint16mSignalId; / / 0x3A45

[0197] uint32mSignalData; / / 0x01

[0198] }spi_fw_can_data_struct;

[0199] Step 2: MCU Reception and Parsing

[0200] booleanSpiRxQnx2McuFE_8_Proc(void){

[0201] IdtSpiData_14st;

[0202] Std_ReturnTypere;

[0203] while(TRUE){

[0204] re=Rte_Receive_PpAppSocSig2McuSpiData_FE_8_FrameData(&st);

[0205] if (re != RTE_E_OK) break;

[0206] uint16signal_id=st.data[0]|(st.data[1]<<8);

[0207] if(signal_id==0x3A45){ / / seat heating request

[0208] uint32signal_data=st.data[2]|(st.data[3]<<8)|...;

[0209] Rte_Write_PpWriteSeatHeater_DeWriteSeatHeater(signal_data);

[0210] }

[0211] }

[0212] }

[0213] Step 3: Signal to CAN Router

[0214] The configuration table defines the mapping of signals to CAN:

[0215] {0x3A45,0u,Rte_Write_PpHU_1_CSC_CAN1_Tx_DeSeatHeaterReq_CSC_CAN1_Tx}

[0216] Step 4: COM layer packet assembly and CAN transmission

[0217] The RTE interface Rte_Write_PpHU_1_CSC_CAN1_Tx_DeSeatHeaterReq() writes the signal value to the COM module. The COM module assembles the signal into the second byte bit0 of the CAN message 0x280(HU_1) according to the configuration (SeatHeaterReq:startbit=16,length=1,byteOrder=Intel), and finally sends it to the seat module via CANIf.

[0218] In the above embodiments, a dual-mode heterogeneous communication architecture is adopted, configuration table-driven intelligent routing is implemented, E2E protection is natively integrated into the transport layer, a hybrid triggering transmission mechanism is used, multi-channel QoS hierarchical protection is provided, and a bidirectional decoupled cross-platform design is employed.

[0219] Through the above embodiments, 1) Dual-mode system: standard SPI + high-speed IPCL, attribute table automatically selects whole packet / parsing mode; 2) Routing method: lookup table decision three-level path, with additional E2E protection; 3) Hybrid transmission: change trigger + periodic retransmission + timeout monitoring; 4) Multi-channel QoS classification and cross-platform dual system support.

[0220] The technical problems that this application may solve through the above embodiments are:

[0221] 1. Traditional communication solutions have huge processing overhead and high transmission latency: all CAN signals are forcibly parsed and forwarded at the signal level. Diagnostic messages and OTA large data scenarios require repeated packet disassembly and reassembly. MCU / SOC processor resources are heavily utilized, and there are no hardware-level transmission optimization methods. Cross-domain communication latency cannot meet the high real-time requirements.

[0222] 2. Single communication mode, unable to balance compatibility and high-speed transmission: Traditional solutions only support standardized SPI communication, which is compatible with AUTOSAR but has low transmission efficiency, no high-speed communication adaptation solution, and no automatic degradation mechanism in case of failure, resulting in poor communication reliability.

[0223] 3. Lack of refined signal routing strategy and low resource utilization: The transmission needs of diagnostic messages, vehicle control signals and signals of different safety levels are not distinguished. All signals take the same transmission path, which is prone to mutual blockage and makes it impossible to allocate communication resources on demand.

[0224] 4. Hard-coded design leads to poor platform reusability and long development cycle: The signal routing and transmission logic of traditional solutions are implemented by hard coding. When adapting to vehicle models or migrating platforms, the underlying code needs to be reconstructed, resulting in high development costs and long development cycles, which cannot meet the rapid iteration needs of vehicle manufacturers.

[0225] 5. Cross-domain communication lacks comprehensive functional safety protection and cannot meet automotive-grade requirements: CAN signals are prone to message loss, out-of-order delivery, and tampering during SPI cross-domain transmission. There is no targeted security verification mechanism, and it cannot meet automotive-grade functional safety level requirements such as ASIL-B / D.

[0226] 6. The signal transmission strategy is too simple and the transmission of key control signals is not guaranteed: It only supports a single mode of periodic transmission or trigger transmission. When the signal changes, it cannot be transmitted in real time, and when there is no change, invalid signals are easily sent continuously. It cannot take into account both the real-time performance and effectiveness of the vehicle body control signals.

[0227] 7. Significant differences in interfaces between different chip platforms, making cross-platform adaptation difficult: The communication interfaces and driver logic of mainstream SOC platforms such as ECARX and Qualcomm are not unified, requiring the development of dedicated communication solutions for different platforms, which increases the development and maintenance costs of the solutions.

[0228] 8. Poor compatibility between new and old solutions, and high cost of upgrading existing projects: Traditional solutions have no compatible interfaces with new high-speed communication solutions. Upgrading existing CSC projects based on the AUTOSAR architecture requires significant modifications to the original code, resulting in high costs and risks.

[0229] Figure 5 This is an electronic device structure block diagram of an intelligent cockpit CSC domain controller CAN-SPI adaptive routing method provided in one or more embodiments of the present invention.

[0230] like Figure 5 As shown, this application provides an electronic device, including: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0231] The memory stores a computer program that, when executed by the processor, causes the processor to perform the steps of a smart cockpit CSC domain controller CAN-SPI adaptive routing method.

[0232] This application also provides a computer-readable storage medium storing a computer program executable by an electronic device, which, when run on the electronic device, causes the electronic device to perform the steps of the Smart Cockpit CSC Domain Controller CAN-SPI Adaptive Routing Method.

[0233] This application also provides a cross-domain communication test platform for a dual-chip CSC domain controller (MCU+SOC), including:

[0234] Electronic devices for implementing the CAN-SPI adaptive routing method of a smart cockpit CSC domain controller;

[0235] The processor runs a program that, when running, executes the steps of the intelligent cockpit CSC domain controller CAN-SPI adaptive routing method based on data output from electronic devices.

[0236] Storage medium for storing programs that, when running, execute the steps of the Smart Cockpit CSC Domain Controller CAN-SPI Adaptive Routing Method for data output from electronic devices.

[0237] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not indicate that there is only one bus or one type of bus.

[0238] The electronic device comprises a hardware layer, an operating system layer running on top of the hardware layer, and an application layer running on the operating system. The hardware layer includes hardware such as a central processing unit (CPU), a memory management unit (MMU), and memory. The operating system can be any one or more computer operating systems that control the electronic device through processes, such as Linux, Unix, Android, iOS, or Windows. Furthermore, in this embodiment of the invention, the electronic device can be a smartphone, tablet computer, or other handheld device, or a desktop computer, portable computer, or other electronic device; there is no particular limitation in this embodiment.

[0239] In this embodiment of the invention, the executing entity for electronic device control can be an electronic device itself, or a functional module within an electronic device capable of calling and executing a program. The electronic device can obtain the firmware corresponding to the storage medium. This firmware is provided by the supplier, and different storage media may have the same or different firmware; no limitation is made here. After obtaining the firmware corresponding to the storage medium, the electronic device can write this firmware into the storage medium; specifically, it burns the firmware corresponding to the storage medium into the storage medium. The process of burning the firmware into the storage medium can be implemented using existing technology, and will not be elaborated upon in this embodiment of the invention.

[0240] Electronic devices can also obtain reset commands corresponding to the storage media. The reset commands corresponding to the storage media are provided by the supplier. The reset commands corresponding to different storage media can be the same or different, and no restrictions are imposed here.

[0241] At this time, the storage medium of the electronic device is a storage medium on which the corresponding firmware has been written. The electronic device can respond to the reset command corresponding to the storage medium on which the corresponding firmware has been written, thereby resetting the storage medium on which the corresponding firmware has been written according to the reset command. The process of resetting the storage medium according to the reset command can be implemented by existing technology and will not be described in detail in this embodiment of the invention.

[0242] For ease of description, the above devices are described separately by function as various units and modules. Of course, in implementing this application, the functions of each unit and module can be implemented in one or more software and / or hardware.

[0243] It will be understood by those skilled in the art that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the meaning consistent with their meaning in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined.

[0244] For the sake of simplicity, the method embodiments are described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0245] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0246] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A dual-mode heterogeneous CAN-SPI secure communication architecture for a smart cockpit CSC domain controller, built on a dual-chip heterogeneous architecture of MCU+SOC, characterized in that, The dual-mode heterogeneous CAN-SPI secure communication architecture of the intelligent cockpit CSC domain controller includes: Core functional modules, dual-mode communication channel, intelligent routing unit and E2E functional safety protection unit; The core functional modules include the CtApSig2SOC master scheduler, CANFwSpi CAN forwarding engine, IPCL adaptation layer, E2E protection module, differentiated transmission module, and CtApSocSigRx SOC side receiver. Among them, the CtApSig2SOC master scheduler is the main scheduling core; The dual-mode communication channel includes a standard SPI mode channel and an IPCL high-speed mode channel, and is configured to dynamically switch based on handshake signals and automatically degrade in case of failure. The intelligent routing unit has a built-in CAN ID attribute configuration table and a corresponding routing strategy for table lookup decision. The E2E functional safety protection unit integrates a verification and protection mechanism; The intelligent cockpit CSC domain controller features a dual-mode heterogeneous CAN-SPI secure communication architecture that is compatible with the AUTOSAR architecture and toolchain.

2. The dual-mode heterogeneous CAN-SPI secure communication architecture of the intelligent cockpit CSC domain controller according to claim 1, characterized in that, include: The CtApSig2SOC master scheduler runs periodically and switches the working mode of the dual-mode communication channel according to the handshake flag. The CANFwSpi CAN forwarding engine has corresponding CAN signal attribute tables of DLC8 and DLC16 specifications, which are used to store CANID attribute information and routing configuration parameters.

3. The dual-mode heterogeneous CAN-SPI secure communication architecture of the intelligent cockpit CSC domain controller according to claim 1, characterized in that, include: The IPCL adapter layer encapsulates the differences in communication interfaces and unifies the CAN-SPI transmission interface; Hardware-level transmission of CAN data is performed based on DMA zero-copy technology. The CtApSocSigRx SOC-side receiver is used to parse the TypeID of the SPI frame and distribute the parsed commands to each software component (SWC).

4. The dual-mode heterogeneous CAN-SPI secure communication architecture of the intelligent cockpit CSC domain controller according to claim 1, characterized in that, include: The communication path of the standard SPI mode channel is CddCan2Spi→CddSpiServer, and the conversion and transmission of CAN-SPI signals are completed through the PduR, Com, and CanIf layers. The IPCL high-speed mode channel fills CAN data into the IPCL shared memory, and the data transmission is completed by DMA.

5. The dual-mode heterogeneous CAN-SPI secure communication architecture of the intelligent cockpit CSC domain controller according to claim 1 or 4, characterized in that, include: The dual-mode communication channel employs a dynamic switching mechanism: When the IPCL driver is not initialized or compatibility is prioritized, the standard SPI mode is enabled by default. After successful handshake signal detection, switch to IPCL high-speed mode; When an IPCL high-speed mode fault is detected, it automatically degrades to standard SPI mode.

6. The dual-mode heterogeneous CAN-SPI secure communication architecture of the intelligent cockpit CSC domain controller according to claim 1, characterized in that, include: The architecture supports multi-channel QoS hierarchical protection, dividing different transmission channels according to the security level and real-time requirements of CAN signals, realizing the separate transmission of E2E signals, non-E2E signals, diagnostic messages, and body control signals, thus avoiding signal blockage. The MCU is an automotive-grade MCU that meets the functional safety ASIL-B / D level, and the SOC is a high-performance MPU that supports a hybrid QNX / Android operating system.

7. A CAN-SPI adaptive routing method for a smart cockpit CSC domain controller, based on the dual-mode heterogeneous CAN-SPI secure communication architecture of the smart cockpit CSC domain controller according to any one of claims 1 to 6, characterized in that, The intelligent cockpit CSC domain controller CAN-SPI adaptive routing method includes: S1, Architecture Initialization; Among them, the CtApSig2SOC master scheduler starts and periodically monitors the IPCL driver initialization status and PpHandshake_DeHandshake() handshake signal, and selects the standard SPI mode or IPCL high-speed mode to establish a communication channel. S2, CANFwSpi CAN forwarding engine reads the preset CAN ID attribute configuration table and performs attribute identification on the CAN signals entering the architecture; S3. The intelligent routing unit selects a three-level routing strategy (full packet transparent transmission, signal-level parsing, or mixed mode) from the CAN ID attribute configuration table based on the attributes of the CAN signal to perform routing processing on the CAN signal. The S4 and E2E functional safety protection units perform triple verification protection processing on CAN signals that require safety protection. Among them, the differentiated transmission module adopts a hybrid trigger transmission mechanism to transmit the CAN signals after routing processing. The S5 and CtApSig2SOC master schedulers monitor the status of the communication channels in real time. If an IPCL high-speed mode fault is detected, the channel dynamic degradation mechanism is triggered, switching to standard SPI mode. S6, SOC and MCU complete bidirectional forwarding and interaction of CAN-SPI signals based on the communication channels and routing strategies in steps S1 to S5, realizing cross-domain communication of the intelligent cockpit.

8. The CAN-SPI adaptive routing method for a smart cockpit CSC domain controller according to claim 7, characterized in that, The processing flow of the E2E functional safety protection unit in step S4 is as follows: Step S41 Transmitter MCU: Enable E2E configuration for the CAN signal that needs protection, call the function to calculate the CRC value and fill it into the specified position of the CAN data frame, and at the same time fill the LiveCounter count value into the 0th byte of the CAN data frame and complete the auto-increment; Step S42 Receiver SOC: Extract the LiveCounter count value and verify its continuity through the CtApSocSigRx SOC-side receiver, recalculate the CRC value and compare it with the received value; Step S43 Fault Handling: If CRC check or LiveCounter check errors are detected continuously, immediately trigger the security degradation channel and switch to fault protection transmission mode.

9. The CAN-SPI adaptive routing method for a smart cockpit CSC domain controller according to claim 7, characterized in that, It also includes the SPI to CAN signal forwarding sub-step from SOC to MCU, specifically: S61 and SOC sides: After the application layer triggers a control event, the middleware encapsulates the control signal into a custom SPI frame. The SPI frame includes a typeid, a length, and a data field, where the data field stores the signal ID and control data. S62, the MCU side receives SPI frames through the RTE interface, parses the signal ID and control data in the frame, and matches the corresponding body control function; S63. The mapping of control signals to CAN messages is completed through the CAN ID attribute configuration table. The COM layer assembles the control signals into the specified bits of the specified CAN message according to the preset parameters. S64. The assembled CAN message is sent to the corresponding body control module through the CANIf layer to complete the transmission of control commands.

10. The CAN-SPI adaptive routing method for a smart cockpit CSC domain controller according to claim 7 or 9, characterized in that, include: The CAN ID attribute configuration table is a gMcuForwardCANattri array, which includes the routing attributes, E2E configuration, timeout threshold and platform adaptation parameters for each CAN ID. Specifically, the parameters of the configuration table are modified for vehicle model adaptation or platform migration.

Images