A vehicle-mounted communication system, a vehicle-mounted communication method, an electronic device, a storage medium, and a program product

Abstract

The application provides a vehicle-mounted communication system, method, device, medium and product, which comprises a central computing platform, a central Ethernet gateway, an edge network processing unit and an edge node; the central computing platform is connected with the central Ethernet gateway, the central Ethernet gateway is connected with the edge network processing unit to form an Ethernet backbone network; the edge network processing unit and the edge node are connected through a branch bus network; the central computing platform encapsulates a bottom layer control target as a remote control message and forwards the remote control message through the central gateway routing; the edge network processing unit uses a hardware acceleration circuit to complete flow switching of the message from the Ethernet backbone to the branch bus; finally, the edge node directly analyzes the message into a physical driving signal to accurately drive a bottom layer actuator to perform an action.

Description

Technical Field

[0001] This application relates to the field of communication technology, specifically to an in-vehicle communication system, an in-vehicle communication method, an electronic device, a storage medium, and a program product. Background Technology

[0002] As automotive electronic and electrical architectures evolve towards a "central + edge" integration, control logic is gradually shifting upwards, with the central computing platform handling algorithm processing and edge nodes responsible for drive and sensing execution. However, existing architectures often employ service-based communication between different regions / domains. Command transmission from the central to the edge typically requires multiple levels of conversion—"service-based communication + service-to-edge communication"—resulting in communication latency often exceeding 5ms, failing to meet high real-time control requirements. Furthermore, traditional edge nodes heavily rely on local microcontroller units (MCUs) for software scheduling and protocol parsing. This not only increases the hardware cost and software complexity of edge nodes but also introduces uncontrollable scheduling latency due to the CPU-based software processing, significantly limiting efficient and direct calls from the central to the underlying driver layer of edge nodes. Therefore, how to achieve efficient, low-latency, direct, and MCU-free collaborative calls from the central computing platform to the underlying edge actuators with microsecond-level latency, while reducing edge node wiring and hardware costs, is a pressing technological challenge. Summary of the Invention

[0003] One of the purposes of this application is to provide an in-vehicle communication system, in-vehicle communication method, electronic device, computer-readable storage medium, and computer program product, so as to reduce the cost of edge node wiring harnesses and hardware, while enabling the central computing platform to quickly and efficiently coordinate with the underlying edge actuators with low latency, either without MCU or with weak MCU.

[0004] To achieve the above objectives, the technical solution adopted in this application is as follows: An in-vehicle communication system includes a central computing platform, a central Ethernet gateway, an edge network processing unit, and edge nodes. The central computing platform is connected to the central Ethernet gateway, and the central Ethernet gateway is connected to the edge network processing unit to form an Ethernet backbone network. The edge network processing unit and the edge nodes are connected via a branch bus network. The central computing platform is used to determine the control target of the underlying driving object for the edge node and encapsulate the control target into a remote control message and send it to the central Ethernet gateway. The central Ethernet gateway is used to route the remote control message to the edge network processing unit. The edge network processing unit is used to perform flow switching and allocation from the Ethernet backbone network to the branch bus network through a built-in hardware acceleration conversion circuit, and distribute the allocated remote control message to the branch bus network. The edge nodes are used to convert the control target in the remote control message received from the branch bus network into a target physical drive signal, so that the corresponding underlying actuator performs the target physical action according to the target physical drive signal.

[0005] Based on the aforementioned technical means, the edge network processing unit incorporates a hardware acceleration conversion circuit, achieving a conversion latency of 100µs between Ethernet and the branch bus. This successfully controls the network link latency between the central and edge nodes to the millisecond level, ensuring high real-time control performance. Simultaneously, the control logic of the edge nodes is directly moved to the central computing platform, performing only pure drive execution and sensor data acquisition. This not only simplifies the hardware structure of the edge nodes and reduces chip costs but also allows edge nodes to be regionally deployed in various locations within the vehicle based on proximity, thereby reducing the length of the drive harness and significantly lowering vehicle harness costs. Furthermore, the central computing platform can directly determine the control target of the underlying drive object and encapsulate it into remote control messages. Control commands are directly targeted at the underlying drive and directly decomposed and converted at the underlying hardware level, eliminating the need for intermediate translation through multiple layers of software protocol stacks. This truly achieves direct and efficient invocation of computing power centralized at the central level and execution decentralized to the edge.

[0006] Furthermore, the central computing platform is divided into a physical interface layer, a data link layer, a protocol intermediate layer, a communication interface layer, a driver logic layer, and an application layer; the physical interface layer connects to the edge network processing unit through a target interface, which includes at least one of a physical layer interface and a media-independent interface.

[0007] Based on the aforementioned technical means, a clear vertical software stack is constructed by strictly dividing the central computing platform into the application layer, driver logic layer, communication interface layer, protocol intermediate layer, data link layer, and application layer. The communication interface layer, through the encapsulation of traditional driver communication interfaces, maximizes the reuse of driver layer software on the central computing platform, significantly improving the modularity and portability efficiency of the control software. At the same time, the physical interface layer introduces target interfaces, supporting at least one of the physical layer interfaces and media-independent interfaces for access. This enables the central computing platform to achieve direct access to long-distance high-speed vehicle Ethernet buses via the 100 / 1000 Base-T1 physical layer interface, and to achieve compact board-level chip interconnection via serial media-independent interfaces or simplified media-independent interfaces. This greatly enhances the adaptability and data transmission bandwidth of the central integrated electronic and electrical architecture to different physical communication scenarios.

[0008] Furthermore, the protocol middleware layer includes a remote communication protocol stack and a service-oriented communication protocol stack; wherein, the remote communication protocol stack is used to process the remote control messages; and the service-oriented communication protocol stack is used to process other control messages.

[0009] Based on the aforementioned technical means, by deploying a remote communication protocol stack and a service-oriented communication protocol stack in parallel within the protocol middle layer, the remote communication protocol stack is specifically responsible for processing remote control messages. This eliminates redundant software-level service addressing and scheduling processes, significantly reducing the processing time within the protocol stack and ensuring high real-time performance and ultra-low latency (hundreds of microseconds) for the underlying hardware control of edge nodes. Simultaneously, the service-oriented communication protocol stack is specifically responsible for processing other control messages, ensuring full compatibility of the vehicle with existing conventional service-oriented communication commands. In this way, the collaborative and isolated operation of the remote communication protocol stack and the service-oriented communication protocol stack within the protocol middle layer enables the central computing platform to achieve efficient and concurrent processing of ultra-low latency underlying hardware control and conventional service call commands on a unified vehicular Ethernet backbone network.

[0010] Furthermore, the communication interface layer is used to encapsulate the original driver communication interface to obtain a standardized driver control protocol interface; the driver logic layer is used to perform driver control logic processing based on the driver control protocol interface and the execution requirements issued by the application layer to obtain control information, and then transmit the control information to the communication interface layer; or, based on the driver control protocol interface, to perform state processing on the acquired physical state data to obtain state data, and then report the state data to the application layer.

[0011] Based on the aforementioned technical means, the communication interface layer encapsulates the original driver communication interface and generates a standardized driver control protocol interface, decoupling the upper-layer control algorithm from the lower-layer network physical hardware. This ensures that the driver layer software can be reused as much as possible during the architectural evolution process of moving the control logic to the central computing platform, solving the technical problems of extremely low reusability of lower-layer driver software and high development and reconstruction costs in existing technologies. Simultaneously, the driver logic layer, based on the standardized driver control protocol interface, uniformly processes the execution requirements issued by the application layer and the collected physical status data, realizing the standardized and modular layered processing of uplink and downlink data streams, and improving the system's execution efficiency in processing control information and status data.

[0012] Furthermore, the hardware acceleration conversion circuit includes a local routing module and a data routing module; the local routing module is used to perform communication routing forwarding between bus interfaces based on communication protocol routing relationships to realize local data transmission; the data routing module is used to perform forwarding between bus communication in the branch bus network and Ethernet communication in the Ethernet backbone network to realize cross-network data transmission.

[0013] Based on the aforementioned technical means, by deploying a local routing module and a data routing module in parallel within the hardware acceleration conversion circuit, the architectural bottleneck of relying on a single central processing unit to execute unified software routing in existing technologies is broken. The local routing module independently handles communication routing and forwarding between bus interfaces based on communication protocol routing relationships, achieving low-overhead local data transmission. The data routing module focuses on forwarding bus communication in the branch bus network and Ethernet communication in the Ethernet backbone network, achieving cross-network data transmission. Simultaneously, the division of labor and collaboration between the local routing module and the data routing module constructs a differentiated hardware traffic distribution mechanism for different network layers, greatly reducing the processing latency caused by heterogeneous network conversion and comprehensively improving the real-time performance and throughput of high-frequency data interaction in vehicle communication.

[0014] Furthermore, the data routing module includes a flow identification module, a routing module, and a direct memory access module; the flow identification module is used to determine the target Ethernet interface group to which the remote control message needs to be forwarded after acquiring the remote control message; the routing module is used to determine the physical destination port corresponding to the remote control message in the Ethernet backbone network based on the target Ethernet interface group; the direct memory access module is used to send the remote control message to the Ethernet backbone network based on the physical destination port.

[0015] Based on the aforementioned technical methods, a pure hardware pipeline processing mechanism is constructed within the data routing module, comprising a flow identification module, a routing module, and a direct memory access module. This completely eliminates the performance bottleneck of existing technologies that rely on the central processing unit (CPU) for software routing and data copying. The flow identification module and the routing module work together to achieve precise hardware-level addressing of remote control messages from the macroscopic target Ethernet interface group to the microscopic physical destination port. The direct memory access module independently completes data transmission based on the determined physical destination port, achieving hardware-level zero-copy when sending data to the Ethernet backbone network. This hardware-level hierarchical processing logic greatly releases the computing power of the CPU, solving the technical defects of existing technologies such as memory bandwidth congestion and huge microscopic transmission latency caused by deep software involvement in cross-network transmission. This ensures high throughput and ultra-fast physical forwarding of high-frequency cross-network segment data in the vehicle system.

[0016] Furthermore, the data routing module also includes an Ethernet data buffer, and the routing module is further configured to send the remote control message to the Ethernet data buffer; the direct memory access module is further configured to send the remote control message in the Ethernet data buffer to the Ethernet backbone network based on the physical destination port.

[0017] Based on the aforementioned technical methods, by introducing an Ethernet data buffer within the data routing module and constructing an asynchronous and collaborative data transmission and reception mechanism between the routing module and the direct memory access module, the hardware pipeline stalls caused by the mismatch between addressing rate and physical transmission rate, as well as packet loss defects under extreme network congestion conditions, are resolved in existing technologies. The Ethernet data buffer physically isolates upstream high-speed routing actions from downstream physical interface transmission actions. This allows the routing module to immediately release its internal computing resources to process the next network packet after sending a remote control message to the Ethernet data buffer. The direct memory access module then elastically reads the remote control message from the Ethernet data buffer and sends it to the Ethernet backbone. This enhances the hardware circuitry's ability to absorb transient network traffic, ensuring data integrity and continuous throughput stability of the vehicle network system under high-concurrency control scenarios.

[0018] Furthermore, the edge node has a built-in time synchronization module; the time synchronization module is used to provide a global time synchronization reference to support time synchronization between target components, wherein the target components include at least one of the following: the central computing platform, the central Ethernet gateway, the edge network processing unit, and the edge node.

[0019] Based on the aforementioned technical means, target components such as edge nodes, central computing platforms, central Ethernet gateways, and edge network processing units can perform time synchronization based on a global time synchronization benchmark. This enables the computing center within the vehicle architecture to share the same microsecond-level time coordinate system with the most peripheral drive and sensor actuators. This provides a solid time synchronization benchmark for zero-delay, high-precision collaborative control between edge nodes and between edge nodes and the central computing platform, significantly improving the deterministic control response and overall vehicle collaborative safety of the MCU-free vehicle control system under high-speed driving conditions.

[0020] This application provides an in-vehicle communication system, including a central computing platform, a central Ethernet gateway, an edge network processing unit, and edge nodes. The central computing platform is connected to the central Ethernet gateway, and the central Ethernet gateway is connected to the edge network processing unit to form an Ethernet backbone network. The edge network processing unit and the edge nodes are connected via a branch bus network. The edge nodes are used to collect sensing and execution feedback information from the underlying devices connected to the edge nodes through a built-in sampling module; and are also used to encapsulate the sensing and execution feedback information into uplink feedback messages and send the uplink feedback messages to the branch bus network. The edge network processing unit is used to receive uplink feedback messages from the branch bus network through a built-in hardware acceleration conversion circuit; and is also used to perform flow switching and allocation from the branch bus network to the Ethernet backbone network through the hardware acceleration conversion circuit, and distribute the allocated uplink feedback messages to the Ethernet backbone network. The central Ethernet gateway is used to route the uplink feedback messages to the central computing platform. The central computing platform is used to extract sensing and execution feedback information based on the received uplink feedback messages and upload the sensing and execution feedback information to the driver logic layer for sampling and calculation.

[0021] Based on the aforementioned technical means, by constructing a closed-loop topology consisting of a central computing platform, a central Ethernet gateway, edge network processing units, and vertically interconnected edge nodes, and deploying dedicated hardware acceleration conversion circuits within the edge nodes and edge network processing units, the dependence of peripheral edge nodes on microprocessors in traditional distributed architectures is eliminated, significantly reducing the hardware cost and wiring complexity of the vehicle control system. Simultaneously, the hardware acceleration conversion circuit performs flow switching and allocation from the branch bus network to the Ethernet backbone network, achieving microsecond-level pure hardware ultra-fast inter-conversion between heterogeneous network protocols. Combined with direct memory access and direct routing mechanisms, this eliminates scheduling latency caused by multi-level software protocol stacks. Finally, the drive logic layer of the central computing platform can accurately perform sampling calculations based on high-frequency feedback from sensor execution to obtain the current physical state parameters of the underlying actuators. This establishes a deterministic, ultra-low latency uplink feedback physical channel, perfectly ensuring the high real-time performance and high security of the vehicle's collaborative control under the central integrated drive-control separation architecture.

[0022] Furthermore, the hardware acceleration conversion circuit includes a flow identification module, a routing module, an Ethernet data buffer, and a direct memory access module; the flow identification unit is used to determine the target Ethernet interface group corresponding to the uplink feedback message after acquiring the uplink feedback message; the routing unit is used to determine the physical destination port corresponding to the uplink feedback message in the Ethernet backbone network based on the target Ethernet interface group, and send the uplink feedback message to the Ethernet data buffer; the direct memory access module is used to send the uplink feedback message in the Ethernet data buffer to the Ethernet backbone network based on the physical destination port.

[0023] Based on the aforementioned technical means, the flow identification module and routing module significantly improve the target port retrieval rate of uplink feedback messages through two-level hardware addressing. The direct memory access module directly reads and sends based on the physical destination port, achieving zero-copy-level high-speed forwarding at the physical layer, ensuring that the central computing platform can quickly obtain the sensing and execution feedback information of the last-line execution device. At the same time, an Ethernet data buffer is introduced inside the hardware acceleration conversion circuit as a physical isolation relay station. This allows the routing module to immediately release computing hardware resources after sending uplink feedback messages to the Ethernet data buffer, effectively mitigating the traffic impact when low-speed bus networks converge to high-speed backbone networks at the physical layer, eliminating hardware pipeline stalls and data packet loss in sudden high-traffic scenarios, and significantly enhancing the determinism and data integrity of the high-frequency data collected from the entire vehicle.

[0024] Furthermore, the central computing platform includes at least a driver logic layer and a communication interface layer; the communication interface layer is used to encapsulate the original driver communication interface to obtain a standardized driver control protocol interface for the driver logic layer to call; the driver logic layer is used to generate corresponding control commands based on the sensor execution feedback information in the uplink feedback message through the driver control protocol interface; wherein, the control commands are used to send to the underlying driver object to control the underlying actuator connected to the underlying driver object to perform the target physical action.

[0025] Based on the aforementioned technical means, the core control algorithm integrated in the driver logic layer can be directly called by the driver logic layer without being aware of changes in the external network topology or differences in heterogeneous hardware. This ensures the high reusability of the upper-layer control software during network architecture evolution and significantly reduces the development cost of system reconfiguration. At the same time, through a standardized driver control protocol interface, the driver logic layer can directly calculate and generate corresponding control commands within the central controller based on the sensor execution feedback information in the real-time uplink feedback messages, and then send the control commands to the underlying driver objects. This eliminates the scheduling delay caused by multi-level software protocol stack translation, enabling the system to control the underlying actuators connected to the underlying driver objects across the network with extremely high precision and agility in executing target physical actions. This perfectly guarantees the high real-time closed-loop collaborative requirements of the distributed driver-control separation system.

[0026] This application provides a vehicle-mounted communication method, implemented through a vehicle-mounted communication system. The vehicle-mounted communication system includes a central computing platform, a central Ethernet gateway, an edge network processing unit, and edge nodes. The central computing platform is connected to the central Ethernet gateway, and the central Ethernet gateway is connected to the edge network processing unit to form an Ethernet backbone network. The edge network processing unit and edge nodes are connected via a branch bus network. The method includes: determining the control target of the underlying driving object for the edge node through the central computing platform, encapsulating the control target in a remote control message and sending it to the central Ethernet gateway; routing the remote control message to the edge network processing unit through the central Ethernet gateway; performing a flow switching and allocation from the Ethernet backbone network to the branch bus network through the edge network processing unit based on a built-in hardware acceleration conversion circuit, and distributing the allocated remote control message to the branch bus network; and converting the control target in the remote control message received from the branch bus network into a target physical driving signal through the edge nodes, so that the corresponding underlying actuator performs the target physical action according to the target physical driving signal.

[0027] Based on the aforementioned technical means, built-in hardware acceleration conversion circuits are introduced at the edge network processing unit and edge nodes, enabling pure hardware-level flow switching and control target extraction throughout the downlink control flow across the Ethernet backbone network to the branch bus network and from the branch bus network to the physical pin interface. This reduces the overhead of software protocol stack parsing and task scheduling by the edge node microprocessor (MCU) in traditional communication architectures, successfully compressing the end-to-end downlink control latency across networks to the microsecond level, perfectly ensuring high determinism and agile response in vehicle control. Simultaneously, the control target in the remote control message is converted into a target physical drive signal, allowing the corresponding underlying actuator to directly execute the target physical action based on the target physical drive signal. This significantly reduces vehicle manufacturing costs, simplifies the physical wiring harness topology, and substantially improves the synchronization accuracy of the centralized control of the vehicle's drive-control separation.

[0028] This application provides a vehicle-mounted communication method, implemented through a vehicle-mounted communication system. The vehicle-mounted communication system includes a central computing platform, a central Ethernet gateway, an edge network processing unit, and edge nodes. The central computing platform is connected to the central Ethernet gateway, and the central Ethernet gateway is connected to the edge network processing unit to form an Ethernet backbone network. The edge network processing unit and edge nodes are connected via a branch bus network. The method includes: acquiring sensing and execution feedback information from underlying devices connected to the edge nodes using a built-in acquisition module at the edge nodes; and encapsulating the sensing and execution feedback information into an uplink feedback message and transmitting the uplink feedback... The message is sent to the branch bus network; the edge network processing unit receives the uplink feedback message from the branch bus network based on the built-in hardware acceleration conversion circuit; and, based on the hardware acceleration conversion circuit, performs flow switching and allocation from the branch bus network to the Ethernet backbone network, and distributes the allocated uplink feedback message to the Ethernet backbone network; the uplink feedback message is routed to the central computing platform through the central Ethernet gateway; and the central computing platform extracts the sensor execution feedback information based on the received uplink feedback message, and uploads the sensor execution feedback information to the driver logic layer for sampling and calculation to obtain the current physical state parameters of the underlying actuator.

[0029] Based on the aforementioned technical means, by deploying built-in hardware acceleration conversion circuits at edge nodes and edge network processing units, the entire process of sensor execution feedback information, from the final physical capture and message encapsulation to the cross-heterogeneous network stream switching, allocation, and distribution, is executed through a solidified hardware state machine pipeline. This achieves zero-copy-level high-speed forwarding at the physical layer, successfully controlling the uplink end-to-end communication latency to the microsecond level, ensuring the central computing platform's extremely fast response and ultra-high determinism in obtaining the status of underlying devices. Simultaneously, the central computing platform can seamlessly receive sensor execution feedback information through standardized interfaces at the communication interface layer and obtain the current physical state parameters of the underlying actuators through sampling calculations at the driver logic layer. This hardware-software collaborative architecture, which highly concentrates complex engineering dimensional calculations and control algorithms such as anti-pinch and position determination at the central computing platform while stripping the pure physical signals to the final hardware layer through encapsulation and forwarding, significantly reduces the cost of peripheral execution node components and the complexity of the vehicle wiring harness, while establishing a microsecond-level high-determinism state feedback channel, meeting the high real-time and high-security collaborative requirements of the central integrated distributed closed-loop system.

[0030] An electronic device, the electronic device comprising: Memory is used to store executable instructions or computer programs. The processor, when executing computer-executable instructions or computer programs stored in the memory, implements the above-described vehicle communication method.

[0031] A computer-readable storage medium storing computer-executable instructions or computer programs for implementing the above-described vehicle communication method when executed by a processor.

[0032] A computer program product includes computer-executable instructions or a computer program, which, when executed by a processor, implement the above-described vehicle communication method.

[0033] The beneficial effects of this application are: The edge network processing unit incorporates hardware acceleration conversion circuitry, achieving a 100µs-level conversion latency between Ethernet and the branch bus. This successfully controls the network link latency between the central and edge nodes to the millisecond level, ensuring high real-time control performance. Simultaneously, the control logic of the edge nodes is directly moved to the central computing platform, focusing solely on pure drive execution and sensor feedback. This not only simplifies the hardware structure of the edge nodes and reduces chip costs but also allows edge nodes to be regionally deployed across the vehicle based on proximity, thereby reducing drive harness length and significantly lowering vehicle wiring harness costs. Furthermore, the central computing platform can directly determine the control target of the underlying drive object and encapsulate it in remote control messages. Control commands are directly targeted at the underlying drive and directly deconstructed and converted at the underlying hardware level, eliminating the need for intermediate translation through multiple software protocol stacks. This truly achieves direct and efficient invocation of computing power centralized at the central level and execution decentralized to the edge. Attached Figure Description

[0034] Figure 1 This is a schematic diagram of the vehicle communication system provided in the embodiments of this application; Figure 2 This is a flowchart illustrating the vehicle communication method provided in the embodiments of this application. Figure 1 ; Figure 3 This is a schematic diagram of the protocol layer encapsulation and message frame structure provided in the embodiments of this application; Figure 4 This is a schematic diagram of the software layered architecture of the central computing platform provided in the embodiments of this application.

[0035] Figure 5 This is a schematic diagram of the internal hardware acceleration conversion circuit of the edge network processing unit provided in the embodiments of this application; Figure 6 This is a schematic diagram of the connection structure between the micro-hardware circuit and external devices of the edge node provided in the embodiments of this application; Figure 7 This is a schematic diagram of the two-way data interaction and control closed-loop logic of the vehicle communication system provided in the embodiments of this application; Figure 8 This is a flowchart illustrating the vehicle communication method provided in the embodiments of this application. Figure 2 ; Figure 9 This is a flowchart illustrating the protocol conversion process of the edge network processing unit for processing uplink feedback data streams, as provided in this embodiment of the application. Figure 10 This is a flowchart illustrating the vehicle communication method provided in the embodiments of this application. Figure 3 ; Figure 11 This is a flowchart illustrating the vehicle communication method provided in the embodiments of this application. Figure 4 ; Figure 12 This is a schematic diagram of the electronic device provided in the embodiments of this application. Detailed Implementation

[0036] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0037] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0038] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0039] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0040] The technical solutions of the embodiments of this application will be described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0041] The vehicle communication system provided in this application embodiment can be applied to vehicles. Vehicles can also be referred to as transportation vehicles, mobile vehicles, electric vehicles, hybrid vehicles, plug-in hybrid vehicles, fuel cell vehicles, autonomous vehicles, intelligent connected vehicles, driverless vehicles, etc.

[0042] In this application's embodiments, the vehicle can be a sedan, SUV, truck, electric vehicle, motorcycle, tricycle, special vehicle (such as an ambulance, fire truck, police car, etc.), driverless taxi, intelligent connected bus, autonomous logistics vehicle, electric truck, etc. Furthermore, this method is also applicable to various special-purpose vehicles, such as agricultural vehicles, mining vehicles, forestry vehicles, airport vehicles, port vehicles, etc. This application does not impose specific limitations in this regard.

[0043] See Figure 1 , Figure 1This is a schematic diagram of the structure of the vehicle communication system provided in the embodiments of this application, based on Figure 1 The vehicle communication system provided in this application embodiment includes a central computing platform 100, a central Ethernet gateway 200, an edge network processing unit 300, and an edge node 400; wherein, the central computing platform 100 is connected to the central Ethernet gateway 200, and the central Ethernet gateway 200 is connected to the edge network processing unit 300 to form an Ethernet backbone network; the edge network processing unit 300 and the edge node 400 are connected through a branch bus network.

[0044] It should be noted that the central computing platform 100 (such as SOC / MCU) is responsible for handling the vehicle's functional logic, complex algorithm calculations, and high real-time control processing. Under the true "drive-control separation" concept, the original control logic of the edge nodes is completely "moved up" here. It directly calculates and determines the control target for the specific underlying drive object (such as the speed, forward and reverse rotation, and running time of a motor), and then packages it into a dedicated remote control message and sends it out.

[0045] The Central Ethernet Gateway 200 acts as a switching node between the central computing platform and multiple peripheral edge network processing units. Based on the high-speed routing and forwarding capabilities of standard Layer 2 Ethernet, it is responsible for securely, losslessly, and point-to-point distributing remote control messages issued by the central authority to designated backbone network links.

[0046] The edge network processing unit 300 is used for flow switching and hardware conversion. Specifically, flow switching refers to the fact that the edge network processing unit is connected to a 100M / 1000M high-speed backbone network and also manages bus networks such as 10M Ethernet. Therefore, it is responsible for performing flow switching between different rates and different network mechanisms (for example, introducing a PLCA collision avoidance mechanism for time slot allocation on a 10M bus network). Hardware conversion is achieved through built-in hardware acceleration conversion circuit. Specifically, by bypassing CPU software scheduling, it directly completes bidirectional encapsulation and standardized conversion between Ethernet protocol and traditional vehicle bus (CAN / LIN / UartCAN, etc.) within hundreds of microseconds through pure hardware circuit, thereby ensuring ultra-low latency of the whole vehicle link at the millisecond level.

[0047] Edge node 400, also known as a purely MCU-free or weakly MCU-free low-level execution / sensing unit, eliminates the need for complex software scheduling by relying on a high-cost local MCU, thus achieving MCU-free or weakly MCU-free operation and low cost. Simultaneously, edge nodes can incorporate pure hardware conversion circuits or low-computing-power, low-cost microcontrollers (such as Cortex-M0+ / 8-bit MCUs). Upon receiving remote control messages via the branch bus, the hardware state machine or microcontroller directly modulates and converts the control target in the message into a target physical drive signal (such as commonly used low-level SPI, I2C, PWM, high / low-side drives, etc.) without delay. This target physical drive signal can then directly drive the underlying actuators, motors, switches, and other devices to perform corresponding physical actions, thereby establishing a direct call link between the central and low-level hardware.

[0048] The Ethernet backbone network is formed by point-to-point connections using high-speed automotive Ethernet (usually 100M or 1000M Base-T1), and is responsible for carrying the core algorithms, control logic, and high-throughput, high-bandwidth data transmission of the entire vehicle. The branch bus network, on the other hand, is formed by relatively low-speed, long-distance bus network connections. For example, depending on the cost and bandwidth requirements of the nearest deployment, buses such as 10M automotive Ethernet (10Base-T1s), CAN / CANFD, LIN, or UartCAN can be flexibly adopted.

[0049] For ease of understanding, the functions of the vehicle communication system provided in this application will be described in detail below with reference to the accompanying drawings.

[0050] See Figure 2 , Figure 2 This is a flowchart illustrating the vehicle communication method provided in the embodiments of this application. Figure 1 ,based on Figure 2 The vehicle communication method provided in this application embodiment is implemented through the following steps.

[0051] Step 101: The central computing platform is used to determine the control target of the underlying driver object for the edge node and encapsulate the control target into a remote control message and send it to the central Ethernet gateway.

[0052] Here, the remote control message is a dedicated data packet generated by the central computing platform and encapsulated in the standard automotive Ethernet frame format. This remote control message directly carries configuration information for the underlying hardware driver circuits and actuators, serving as a communication carrier for the central computing platform to remotely invoke edge nodes without a local MCU. Therefore, control commands can be transmitted to the edge nodes via the Ethernet backbone and directly act on the underlying driver, without requiring protocol conversion or secondary processing by the edge-side MCU.

[0053] In actual implementation, the central computing platform performs sampling and control calculations based on the current vehicle control requirements or on the sensor data collected from the uplink, generating control targets for the underlying driven objects (such as specific actuator motors). These control targets include operating parameters or physical state targets. Subsequently, the protocol middleware layer of the central computing platform calls the Remote Communication Protocol Stack (RCP) to encapsulate the control target according to its underlying drive attributes, such as interface types like SPI, I2C, or PWM. For example, when the control target corresponds to a motor object connected to an edge node, the RCP protocol stack encapsulates the motor's driving force, forward / reverse state, running time, and required underlying SPI communication parameters (including but not limited to SPI transmission direction SPI_Direction, SPI operating mode SPI_Mode, chip select signal CS / SS, etc.) as a payload within the data field of a standard Layer 2 Ethernet message, and configures a subtype field in the message header to identify that the message is an Ethernet-encapsulated SPI communication type. After encapsulation, the remote control message is sent to the central Ethernet gateway via the physical interface layer through the 100 / 1000Base-T1 vehicle Ethernet physical interface or the SGMII / RMII chip interface, and then routed by the gateway to the target edge network processing unit.

[0054] In some embodiments, the central computing platform is divided into a physical interface layer, a data link layer, a protocol intermediate layer, a communication interface layer, a driver logic layer, and an application layer; the physical interface layer accesses the edge network processing unit through a target interface, which includes at least one of a physical layer interface and a media-independent interface.

[0055] It should be noted that the physical interface layer is the lowest layer of the entire architecture, responsible for handling the physical connection and electrical signal conversion between the controller chip and the external communication network, and determining the hardware interface and transmission medium used to send data out. Here, it can be directly connected to the vehicle Ethernet bus through a physical layer interface (such as the PHY interface), or it can be interconnected at the board level with gateways and switching chips through a media-independent interface (such as SGMII / RMII).

[0056] Among them, the physical layer interface refers to the hardware interface and physical transceiver that conforms to the specific automotive network physical layer industry standard (such as the IEEE automotive Ethernet standard). It is used to connect the data link layer (MAC) and the real physical transmission medium (such as twisted pair). It is responsible for modulating digital signals into high-frequency analog electrical signals that can be transmitted on the vehicle wiring harness, or restoring the received analog signals. Here, the physical layer interface typically refers to a 100Base-T1 or 1000Base-T1 automotive Ethernet physical interface, supporting high-speed point-to-point data transmission of 100Mbps or 1000Mbps via a pair of twisted-pair cables. In a branch network, it may refer to a 10Base-T1s (10M automotive Ethernet) interface, supporting bus-style multi-node mounting and PLCA scheduling. The media-independent interface (MII) is a standardized digital interface used to connect the automotive Ethernet media access control sublayer and the physical layer transceiver, facilitating data signal transmission between them. Here, the MII serves as an optional interface type in the physical interface layer of the central computing platform, connecting the media access control chip within the central computing platform to the peripheral transceiver hardware, enabling high-speed data interaction between the central computing platform and the edge network processing unit. For example, the MII can be in the form of a Serial Media Independent Interface (SGMII) or a Simplified Media Independent Interface (RMII) to achieve high-speed data communication at the chip or board level between the central computing platform and the edge network processing unit.

[0057] Furthermore, the data link layer is responsible for providing reliable data transmission, addressing, and media access control over the physical medium. It handles network addressing and frame assembly, and in automotive Ethernet architectures, this layer primarily functions as Ethernet Media Access Control (MAC). It adds source MAC address, destination MAC address, Virtual LAN tag (VLAN VID), and a subtype field indicating the communication type to the data packets transmitted from the upper layer, packaging them into standard Layer 2 Ethernet frames.

[0058] The protocol middleware layer is a core protocol stack set responsible for the encapsulation, parsing, and routing of in-vehicle network packets. It includes a variety of heterogeneous communication protocol stacks, mainly the Remote Communication Protocol Stack (RCP) and the Service-Oriented Communication Protocol Stack (SOC). RCP is used to directly encapsulate low-level parameters such as motor control and SPI / I2C into Ethernet packets to enable direct remote calls, while SOC is based on the traditional TCP / IP protocol stack and is responsible for compatibility with conventional service-oriented communication under the existing architecture.

[0059] The communication interface layer is an abstract encapsulation layer between the control software and the network communication protocol stack. It is used to encapsulate the functions of the original traditional driver communication interface. In this way, when the control logic is moved to the central computing platform, the encapsulation of this layer can ensure that the upper driver software can be reused as much as possible without major modifications, thereby achieving decoupling of software and hardware.

[0060] The driver logic layer is a layer specifically designed to integrate the actuator control algorithms of peripheral nodes (such as edge nodes). It is responsible for receiving macro-level control commands from the application layer and translating them into sampling calculations or control calculations for specific underlying hardware objects. For example, it might translate the application layer's "window up" command into the driving force, forward and reverse rotation states, and precise running time of a specific motor.

[0061] The application layer is at the top of the entire architecture, directly facing the specific functional business logic of the vehicle, and is responsible for the highest-level decision-making and processing of the entire vehicle. For example, autonomous driving path planning, window raising and lowering logic in vehicle body control, and headlight flashing control are all calculated at the application layer to determine the final business objectives.

[0062] In actual implementation, during the operation of the vehicle communication system, the central computing platform is divided into an application layer, a driver logic layer, a communication interface layer, a protocol intermediate layer, a data link layer, and a physical interface layer according to the vertical architecture. Data transmission and control logic interaction between each layer are carried out through defined standardized interfaces.

[0063] First, the application layer generates vehicle control commands based on the current vehicle's functional logic and sends these commands to the drive logic layer. The drive logic layer integrates the control logic of the relevant drivers at the edge nodes, performs sampling calculations or control calculations on the vehicle control commands, and produces control targets for the underlying drive objects at the edge nodes.

[0064] Secondly, the communication interface layer receives the control target and uses preset encapsulation rules to encapsulate the traditional driver communication interface, then transmits the encapsulated control target to the protocol middleware layer. The middleware layer determines whether a remote underlying call needs to be initiated based on the control target's attributes: if the determination is yes, meaning the control target is for remote control of an edge node, the middleware layer initiates a remote communication protocol stack to encapsulate the control target into a remote control message; if the determination is no, meaning the control target is for regular service-oriented communication, the middleware layer initiates a service-oriented communication protocol stack based on the Transmission Control Protocol / Internet Protocol stack to package standard service-oriented data.

[0065] Next, the data link layer receives remote control messages. The data link layer primarily uses Ethernet media access control and configures the source media access control address and destination media access control address for the remote control messages.

[0066] Finally, the physical interface layer calls the target interface to send the remote control message to the edge network processing unit. During the transmission process, the physical interface layer performs a network access type matching determination: if it determines that the current network topology belongs to direct physical layer access via the backbone vehicle Ethernet, the physical interface layer calls the physical layer interface to perform network access, and the physical layer interface sends the remote control message to the edge network processing unit in 100 / 1000 Base-T1 physical layer interface format; if it determines that the current network topology belongs to inter-controller chip-level or board-level interconnection access, the physical interface layer calls the media-independent interface to perform network access, and the media-independent interface sends the remote control message to the edge network processing unit in either serial media-independent interface or simplified media-independent interface format. In actual implementation, the protocol middleware layer includes a remote communication protocol stack and a service-oriented communication protocol stack; the remote communication protocol stack is used to process remote control messages; and the service-oriented communication protocol stack is used to process other control messages.

[0067] It should be noted that the remote communication protocol stack refers to a set of protocol processing software modules located inside the protocol middle layer, which are specifically used to process data frames with extremely low latency requirements that directly affect the underlying hardware execution of peripheral nodes. Here, the remote communication protocol stack is specifically used to process remote control messages, realizing the rapid encapsulation and parsing of underlying drive control commands. For example, through the remote communication protocol stack, specific motor running time and steering parameters are packaged into remote control messages that support direct Ethernet transmission. A service-oriented communication protocol stack refers to a collection of protocol processing software modules located inside the protocol middle layer for routine business logic data interaction. Here, the purpose of the service-oriented communication protocol stack is to process other control messages (i.e., control messages other than remote control messages). For example, the service-oriented communication protocol stack can be used to process other control messages such as volume adjustment or screen brightness adjustment in an in-vehicle infotainment system.

[0068] In actual implementation, the protocol middle layer receives control commands from upper-layer functional modules, parses the service attributes and latency requirements of the received control commands, and then determines whether the received control command is a remote hardware control request for the underlying execution device based on the parsed service attributes and latency requirements. If the determination result is yes, that is, the control command is a direct hardware control request for the edge node, the protocol middle layer calls the internal remote communication protocol stack to execute the processing logic. Specifically, the remote communication protocol stack strips away the complex conventional service addressing mechanism, directly packages and encapsulates the physical drive parameters in the control command according to the preset underlying hardware communication format, generates the corresponding remote control message, and transmits the generated remote control message to the lower-layer link module for subsequent high-speed transmission. If the judgment result is negative, it means that the control command is not a direct hardware control request, but a regular application layer service call logic. The protocol intermediate layer calls the internal service-oriented communication protocol stack to execute the processing logic. Specifically, the service-oriented communication protocol stack performs state encapsulation and routing addressing of the control command according to the standard service-oriented transport protocol mechanism, generates other corresponding control messages, and passes the generated other control messages to the lower-layer link module for subsequent network transmission.

[0069] For example, see Figure 3 , Figure 3 This is a schematic diagram of protocol layer encapsulation and message frame structure provided in the embodiments of this application, based on Figure 3 This application designs a standardized Ethernet multi-layer nested frame structure for compatible forwarding of heterogeneous underlying data on a unified automotive Ethernet backbone. The outer layer of the message adopts the standard Layer 2 Ethernet format, including fields such as DMAC, SMAC, Type, PRI, VID, Length, and Subtype, Version, and Payload Length as defined in this application; the Subtype field is used to identify the underlying communication protocol type carried by the subsequent Data field. The Data field (37~1495 bytes) serves as the relay payload for heterogeneous data, dynamically nesting three types of subframes according to the underlying driver object: CAN format (including Bus id, identifier, DLC, and 8~64 byte payload), SPI format (including transmission direction, mode, chip select, clock polarity / phase, baud rate, and register data), or IIC format (including mode, device address, register address, and feedback data), enabling the central platform to directly access the end devices across layers.

[0070] In actual implementation, the communication interface layer is used to encapsulate the original driver communication interface to obtain a standardized driver control protocol interface; the driver logic layer is used to perform driver control logic processing based on the driver control protocol interface and the execution requirements issued by the application layer to obtain control information and then transmit the control information to the communication interface layer; or, based on the driver control protocol interface, to perform state processing on the acquired physical state data to obtain state data and then report the state data to the application layer.

[0071] It should be noted that a standardized driver control protocol interface refers to a unified software calling channel generated by the communication interface layer after abstracting and encapsulating the underlying heterogeneous driver communication interfaces. Here, the purpose of the standardized driver control protocol interface is to shield the differences between the underlying network and physical lines, providing a unified data transmission and reception interface for the driver logic layer.

[0072] Execution requirements refer to the macro-level business objectives and action instructions generated by the application layer based on the vehicle system's functional logic or external environmental inputs. Here, execution requirements are functional requests and have not yet been transformed into specific physical parameters at the underlying level. For example, an autonomous driving assistance system might generate a "vehicle decelerates" command based on environmental perception calculations, or a smart cockpit system might generate a "driver's side window rises" command.

[0073] Drive control logic processing refers to the data processing process in which the drive logic layer performs control calculations on macroscopic execution requirements issued by the application layer, or samples and calculates raw data collected from underlying edge nodes. It is the core computational link for mapping vehicle macroscopic business logic to underlying hardware execution parameters. For example, using a specific closed-loop control algorithm, the execution requirement of "raising the driver's side window" is accurately calculated and converted into the target pulse width modulation duty cycle value required by the corresponding window raising motor.

[0074] Control information refers to the set of underlying parameters calculated and generated by the drive control logic processing stage, used to precisely guide the underlying edge node drive modules to execute specific physical actions. It is a data payload generated by the drive logic layer and transmitted down to the communication interface layer. For example, specific parameters such as the total motor running time, forward and reverse rotation status identifiers, and target torque value calculated for a specific edge node.

[0075] Physical state data refers to the raw electrical signals or raw feedback parameters collected by hardware conversion circuits or microcontrollers without undergoing conversion processing by upper-layer business logic. Here, it is used to reflect the actual physical operation of the underlying execution device. It is collected by hardware conversion circuits or microcontrollers and provided to the drive logic layer for engineering value conversion processing. For example, the raw analog-to-digital conversion voltage value of the motor phase current collected by the hardware conversion circuit.

[0076] State processing refers to a set of processing steps performed by the driver logic layer on the raw physical signals (i.e., physical state data) collected and reported by the underlying hardware conversion circuits or microcontrollers. These steps involve data parsing, numerical calculation, signal optimization, and protocol format conversion. State processing aims to eliminate hardware differences in electrical characteristics and acquisition methods between different sensors or actuators at the underlying level. It transforms and maps the dimensionless raw electrical signals specific to the underlying hardware into standardized engineering data or macroscopic logical identifiers (i.e., state data) that can be directly recognized and invoked by the application layer functional logic and have actual physical meaning.

[0077] State data refers to the standardized numerical values ​​that the application layer can directly call after the driver logic layer performs engineering dimension conversion, filtering, and other calculations on the raw physical state data (such as unprocessed voltage levels and current pulse signals) obtained from the hardware conversion circuit. For example, the raw Hall sensor pulse count values ​​obtained from the edge node are processed to obtain results such as "current window actual position percentage" or "current motor actual speed" for subsequent decision-making.

[0078] In practical implementation, the communication interface layer pre-encapsulates the existing driver communication interface to generate a standardized driver control protocol interface. This standardized driver control protocol interface is then provided to the driver logic layer. The driver logic layer listens for data transmission tasks within the system and determines whether the currently received task is a downlink control task. If the determination is yes, meaning the currently received task is an execution requirement issued by the application layer, then based on the standardized driver control protocol interface, the driver control logic processing steps are executed according to the execution requirement issued by the application layer. For example, the driver logic layer calculates and converts the window raising requirement issued by the application layer into specific motor torque parameters to obtain control information. Subsequently, the driver logic layer transmits the control information down to the communication interface layer for subsequent network transmission. If the determination is no, meaning the currently received task is an uplink data acquisition task, then based on the standardized driver control protocol interface, the driver receives physical state data acquired by the hardware conversion circuit or microcontroller, and then performs state processing steps on the physical state data. For example, the driver logic layer performs filtering and physical dimension calculations on the original analog-to-digital conversion voltage value to obtain status data. Finally, the driver logic layer reports the status data to the application layer (such as APP) so that the application layer can make subsequent business decisions.

[0079] For example, see Figure 4 , Figure 4 This is a schematic diagram of the software layered architecture of the central computing platform provided in the embodiments of this application, based on Figure 4This application vertically decouples the central computing platform software into six layers: the application layer (APP) is responsible for macro-level business decisions; the driver logic layer runs high-frequency closed-loop algorithms to calculate precise control information; the communication interface layer (CAN / SPI / PWM / UART, etc.) uniformly encapsulates heterogeneous driver interfaces, so that the upper layer does not need to be aware of the underlying bus type, thus achieving hardware and software decoupling; the protocol intermediate layer adopts a dual-track parallel mechanism, namely, the remote communication protocol stack processes ultra-low latency remote control messages at the microsecond level, and the SOC / TcpIp protocol stack processes regular service-oriented communication messages; the data link layer (MAC) and the physical interface layer (100 / 1000Base-T1 or SGMII / RMII) are responsible for backbone network data acquisition and physical transmission and reception, establish high-speed vehicle Ethernet connections, and support bidirectional high-speed routing of data across the backbone network.

[0080] Step 102: The central Ethernet gateway is used to route remote control messages to the edge network processing unit.

[0081] In practice, remote control messages are sent from the upstream central computing platform via a point-to-point transmission method on the backbone network and then transmitted to the ingress port of the central Ethernet gateway via the vehicle-mounted high-speed Ethernet physical link. Upon receiving the remote control message, the central Ethernet gateway uses its built-in high-speed switching chip or network routing module to parse the standard Layer 2 Ethernet header in the message. For example, based on a preset static routing table or MAC address forwarding table, the gateway retrieves the destination MAC address in the message, matches it to the corresponding destination Ethernet port, and then accurately and losslessly routes and forwards the remote control message to the edge network processing unit mounted on the corresponding link via the 100M or 1000M vehicle-mounted Ethernet backbone network.

[0082] Step 103, the edge network processing unit is used to perform stream switching and allocation from the Ethernet backbone network to the branch bus network through the built-in hardware acceleration conversion circuit, and distribute the allocated remote control messages to the branch bus network.

[0083] Here, flow switching and allocation refers to the data allocation process by which the network processing unit, when connecting to networks with different speeds and topologies (such as switching from a point-to-point 100 / 1000M high-speed automotive Ethernet backbone to a bus-type 10M low-speed automotive Ethernet or traditional automotive bus), achieves smooth packet transition and prevents network congestion and collisions through internal flow control, queue management, and dynamic bus allocation mechanisms (such as the PLCA physical layer collision avoidance mechanism). Specifically, flow switching and allocation refers to the process of standardizing and converting data from a high-speed point-to-point Ethernet backbone (such as 100M / 1000M automotive Ethernet) and smoothly allocating it to a low-speed bus-type network (such as a 10M Ethernet bus, CAN, or LIN bus).

[0084] In actual implementation, remote control messages awaiting flow switching and allocation can be obtained in the following way: received in real time from the Ethernet backbone by the high-speed vehicle-mounted Ethernet physical interface (such as a 100 / 1000Base-T1 interface) of the edge network processing unit, and temporarily stored in the on-chip Ethernet data buffer. The specific processing procedure for remote control messages will be explained below.

[0085] In some embodiments, the hardware acceleration conversion circuit includes a local routing module and a data routing module; the local routing module is used to perform communication routing forwarding between bus interfaces based on communication protocol routing relationships to realize local data transmission; the data routing module is used to perform forwarding between bus communication in the branch bus network and Ethernet communication in the Ethernet backbone network to realize cross-network data transmission.

[0086] It should be noted that the local routing module is an integrated logic unit within the hardware acceleration conversion circuit, specifically designed for direct hardware-level addressing and forwarding of data flows between physical bus interfaces with the same or compatible underlying protocols. It is used to handle direct forwarding in homogeneous networks (e.g., directly routing data from the CAN1 interface to the CAN2 interface) without complex protocol encapsulation, thus achieving local data transmission. The data routing module, also integrated within the hardware acceleration conversion circuit, is a hardware logic execution unit with cross-protocol parsing and packet reassembly capabilities. It is responsible for handling cross-segment conversions in heterogeneous networks (e.g., between CAN / LIN buses and Ethernet). It utilizes its internal DMA (Direct Memory Access) mechanism for rapid data transfer and a dedicated hardware engine to perform protocol header swapping, thereby enabling cross-network data transmission.

[0087] In practice, the hardware acceleration conversion circuit continuously monitors the packet reception status of the network port. When the hardware acceleration conversion circuit receives a packet to be forwarded, it parses the header identifier field of the packet to extract the destination address information and source protocol type. Then, based on the destination address information and a preset routing table, it determines whether the packet needs to undergo a cross-protocol network hop. If no cross-protocol network hop is needed, meaning both the source and destination ports of the packet belong to bus interfaces within the branch bus network, the local routing module is called. The local routing module performs communication routing forwarding between bus interfaces based on the communication protocol routing relationship. For example, the local routing module directly maps the data stream received by the first bus interface to the second bus interface, thereby achieving local data transmission bypassing the main network protocol stack. If a cross-protocol network hop is needed, meaning the packet needs to interact between the branch bus network and the Ethernet backbone network, the data routing module is called. The data routing module performs forwarding between bus communication in the branch bus network and Ethernet communication in the Ethernet backbone network. Specifically, during the forwarding process, the data routing module extracts the protocol payload and reassembles and encapsulates the Ethernet frames to establish a physical layer data mapping, thereby enabling seamless cross-network data transmission.

[0088] It's important to note that hardware-accelerated conversion circuits refer to digital circuit modules that use dedicated physical hardware logic (such as Application-Specific Integrated Circuits (ASICs) or Field-Programmable Gate Arrays (FPGAs) to replace traditional general-purpose central processing unit (CPU) software algorithms, enabling them to perform specific data processing or protocol conversion tasks at extremely high speeds. In related technologies, traditional gateway nodes, upon receiving a packet, need to trigger a CPU interrupt, move the data to memory, run the software protocol stack to parse the packet, repackage and encapsulate it, and finally drive the network port to send it. This series of CPU-based software scheduling and execution processes inevitably introduces latency fluctuations of several milliseconds to tens of milliseconds. Here, when the network port receives an electrical signal, the data stream directly enters a dedicated data format engine and routing module. The stripping of the packet header, the reading of internal fields, and the addition of new protocol headers are all completed instantaneously at the underlying physical circuitry, without any intervention from the CPU software program.

[0089] In actual implementation, the data routing module includes a flow identification module, a routing module, and a direct memory access module. The flow identification module is used to determine the target Ethernet interface group to which the remote control message needs to be forwarded after it is acquired. The routing module is used to determine the physical destination port of the remote control message in the Ethernet backbone network based on the target Ethernet interface group. The direct memory access module is used to send the remote control message to the Ethernet backbone network based on the physical destination port.

[0090] It should be noted that the flow identification module refers to a logic circuit integrated inside the data routing module, specifically used to parse the header features of the input data packet and perform preliminary routing domain classification at the pure hardware level. Here, the flow identification module is used to perform preliminary filtering and matching after obtaining the remote control message, thereby determining the target Ethernet interface group to which the remote control message needs to be forwarded.

[0091] The routing module refers to the core hardware logic unit integrated inside the data routing module, which is specifically responsible for performing second-level micro-addressing based on accurate address matching algorithms and forwarding tables (such as the media access control address forwarding table). Here, the routing module receives the macro-level packet information output by the flow identification module, and then performs pure hardware logic retrieval and comparison on the specific destination address (such as the destination MAC address) of the remote control message within the interface range defined by the target Ethernet interface group, thereby calculating and determining which specific hardware gate the remote control message must ultimately leave the chip from.

[0092] A target Ethernet interface group refers to a set of logical interfaces with the same data forwarding attributes, pre-divided within an edge network processing unit or central Ethernet gateway that has multiple network interfaces, based on service priority, security isolation level, or Virtual Local Area Network (VLAN) tags. It represents the first-level macro-filtering result for cross-network segment routing. Specifically, the flow identification module quickly narrows down remote control messages to a smaller logical group (i.e., the target Ethernet interface group) by initially parsing the protocol header characteristics of the remote control message. By identifying the target Ethernet interface group, the system avoids blind broadcasting or global searching across all ports, significantly reducing the scope of subsequent precise addressing and improving addressing efficiency.

[0093] The physical destination port refers to the actual underlying hardware transmission channel or pin set on the network switching chip or edge network processing unit that is directly connected to a specific physical transmission cable (such as a twisted pair). It is the final destination and output terminal of the entire hardware-level addressing process. Here, the physical destination port serves as the target endpoint for the data transfer channel established by the direct memory access module. The direct memory access module directly transfers the remote control message to the corresponding transmission register of the physical destination port, thus completing the transmission of the remote control message to the electrical signal of the physical network medium.

[0094] A direct memory access module (DMI) is a low-level hardware control unit that operates independently of the central processing unit and is specifically designed for high-speed data transfer between the system's internal memory and network physical sending peripherals. Here, the purpose of the DMI is to establish a low-level data transfer channel based on the physical destination port determined by routing resolution, and to send remote control messages directly to the Ethernet backbone.

[0095] In practice, the flow identification module extracts the protocol feature field of the message to be processed from the input buffer. If the protocol feature field determines that the message contains a valid cross-segment remote control protocol identifier, after acquiring the remote control message, it determines the target Ethernet interface group to which the remote control message needs to be forwarded by matching it with a pre-set hardware flow table, and passes the index information of the target Ethernet interface group to the routing module. If the protocol feature field determines that the message to be processed is a corrupted message or illegal probe data, the message to be processed is directly discarded at the hardware level to block invalid data from occupying bandwidth. Next, the routing module receives the index information of the target Ethernet interface group, and then performs a precise address lookup table search within the interface range defined by the target Ethernet interface group to accurately determine the physical destination port corresponding to the remote control message in the Ethernet backbone network, and sends the configuration parameters of the physical destination port to the hardware transfer channel. Finally, the direct memory access module receives the configuration parameters of the physical destination port, starts the bus master mode based on the physical destination port, automatically reads the temporarily stored remote control message from the data storage, and sends the remote control message to the Ethernet backbone network.

[0096] In actual implementation, the data routing module also includes an Ethernet data buffer, and the routing module is also used to send remote control messages to the Ethernet data buffer; the direct memory access module is also used to send remote control messages in the Ethernet data buffer to the Ethernet backbone network based on the physical destination port.

[0097] It should be noted that the Ethernet data buffer is a volatile hardware storage unit integrated inside the data routing module for short-term high-speed temporary data storage. Here, the Ethernet data buffer acts as a physical data relay station between the routing module and the direct memory access module, used to temporarily store remote control messages processed by the routing module, thereby isolating the time difference between upstream logical addressing operations and downstream network physical transmission operations.

[0098] In actual implementation, the routing module sends remote control messages to the Ethernet data buffer for queuing and temporary storage, and synchronously updates the write status pointer of the Ethernet data buffer; then, the direct memory access module automatically reads and extracts the remote control messages in the Ethernet data buffer based on the physical destination port, and sends the remote control messages to the Ethernet backbone network.

[0099] For example, see Figure 5 , Figure 5 This is a schematic diagram of the internal hardware acceleration conversion circuit of the edge network processing unit provided in the embodiments of this application, based on... Figure 5The hardware-accelerated conversion circuit is divided into a local homogeneous forwarding layer and a heterogeneous cross-network data routing layer. The local layer consists of CAN / LIN routing modules, which handle direct hardware routing between network segments of the same protocol (such as CAN1 to CAN2) without heterogeneous conversion. The cross-network layer uses RX Channel and RX DMA to move data to the ETHData Buffer without CPU intervention; the Data Format Engine parses header features to perform flow identification and protocol conversion (such as swapping bus headers and Ethernet headers); the Routing module retrieves the hardware forwarding table, locks the physical destination port, and writes the data to the corresponding target buffer (CAN / LIN / ETH Data Buffer); finally, TX DMA reads from the buffer and sends it via TX Channel, realizing a fully CPU-free cross-network data transmission process.

[0100] Step 104, edge node, is used to convert the control target in the remote control message received from the branch bus network into a target physical drive signal, so that the corresponding underlying actuator can perform the target physical action according to the target physical drive signal.

[0101] In practice, edge nodes can use built-in hardware conversion circuits or low-computing-power, low-cost microcontrollers (such as Cortex-M0+ / 8-bit MCUs) to convert the control target in the remote control message received from the branch bus network into a target physical drive signal, so that the corresponding underlying actuator can perform the target physical action according to the target physical drive signal.

[0102] Here, the target physical drive signal refers to a low-level hardware control signal that can directly drive on-board physical actuators (such as motors, switching elements, etc.). This signal is directly output by the hardware conversion circuit or microcontroller inside the edge node, and is usually manifested as a pulse width modulation waveform with a specific duty cycle, high and low side drive levels, or specific inter-chip serial bus signals, etc. This application does not limit the specific manifestation of this signal.

[0103] The target physical action refers to the actual spatial displacement, state deformation, or mechanical work process generated by the underlying actuator (such as an actuator motor, solenoid valve, switching device, etc.) through its internal electromagnetic, mechanical, or physical mechanisms after receiving the aforementioned physical drive signal. For example, it can be the mechanical rotation of a motor (such as an actuator motor rotating at a specific speed according to the duty cycle of a PWM waveform, or rotating clockwise / counterclockwise according to the forward and reverse control level, thereby driving the window regulator to rise, the rearview mirror to fold, or the seat position to adjust), the opening switching or engagement of a valve (such as a solenoid valve coil generating electromagnetic force after receiving a high or low side drive level, overcoming spring resistance to perform opening or closing actions, thereby regulating the vehicle's brake hydraulic pressure, air suspension airflow, or air conditioning pipeline flow), or the switching of circuit states (such as contacts or power relays performing physical closing or opening actions to realize the power supply switching of high-power vehicle electrical appliances (such as defrosting heating wires, headlights), etc. This application embodiment does not limit this.

[0104] In actual implementation, the communication module inside the edge node (such as one containing a 10M Ethernet PHY chip, MAC core and gPTP time synchronization module, or traditional bus transceiver) listens and receives data in real time from the branch bus network (such as a 10M vehicle Ethernet bus or traditional vehicle branch bus).

[0105] Then, the process of converting the control target into the target physical drive signal specifically includes the following: after receiving the remote control message, the hardware conversion circuit (including the protocol parsing module and the hardware conversion module) built into the edge node or the microcontroller directly decomposes and parses the standard Layer 2 Ethernet message layer by layer based on the pure hardware circuit or the microcontroller. Here, the parsing circuit first identifies the subtype field in the message. After identifying the type of remote control protocol it carries (such as Ethernet encapsulated SPI type), the data conversion engine automatically extracts the low-level parameters in the control target (such as SPI_Direction, SPI_Mode, the chip select pin corresponding to CS / SS, the clock polarity CPOL, and the specific drive payload).

[0106] Subsequently, the hardware conversion module or microcontroller module bypasses the CPU software scheduling and processing in the traditional architecture, directly mapping and modulating the extracted control target parameters into physical signals on the corresponding hardware pins through a dedicated hardware state machine or logic conversion gate circuit. For example, the logic circuit directly outputs the target PWM waveform for adjusting the motor speed or the level of the pull-up / pull-down high / low side drive circuit, thereby enabling the actuator motor or underlying actuator connected to the edge node port to accurately execute the corresponding physical action according to the physical drive signal.

[0107] In some embodiments, the edge node also has a built-in time synchronization module; the time synchronization module is used to provide a global time synchronization reference to support time synchronization between target components, wherein the target components include at least one of the following: a central computing platform, a central Ethernet gateway, an edge network processing unit, and an edge node.

[0108] It should be noted that the time synchronization module refers to a hardware logic control unit built into the hardware node, which implements clock signal capture, clock deviation calculation and local clock frequency compensation based on the high-precision clock protocol stack standard; here, it is used to establish a unified clock reference source at the bottom layer of the decentralized edge node, and provide a global time synchronization reference to support time synchronization between target components.

[0109] The global event synchronization benchmark refers to a unique, highly consistent standard time coordinate source that is followed by all heterogeneous nodes participating in data interaction and control coordination within the entire vehicular network communication architecture. Here, the global time synchronization benchmark serves as a unified time measurement for the entire network, used to eliminate time deviations between different communication levels and heterogeneous network nodes. For example, it is the system master clock timestamp counter value, uniformly maintained within the entire vehicular communication network, with an accuracy down to the microsecond level.

[0110] In practical implementation, the time synchronization module captures time synchronization protocol messages containing the master clock timestamp via the branch bus network, extracts the current value of the local clock counter, and calculates the phase deviation and frequency drift coefficient between the local clock and the global master clock based on a bidirectional time calibration algorithm. Next, the time synchronization module determines whether the local clock and the global master clock have reached a preset synchronization lock threshold based on the calculated phase deviation: if the phase deviation is within the preset threshold range, the current local clock frequency compensation state is maintained, and a global time synchronization reference is continuously provided; if the phase deviation exceeds the preset threshold range, the value of the local clock counter is directly corrected at the underlying level, and the crystal oscillator frequency is compensated until the local clock is aligned with the global master clock, thereby updating the global time synchronization reference. Finally, after the local clock is locked, the time synchronization module provides a global time synchronization reference to support time synchronization between target components.

[0111] For example, see Figure 6 , Figure 6 This is a schematic diagram of the micro-hardware circuit and external device connection structure of the edge node provided in the embodiments of this application, based on Figure 6The edge nodes employ a pure hardware pipeline architecture without MCUs, excluding general-purpose CPU software scheduling. On their left side, physical interfaces such as LIN, CAN, and 10M Ethernet are deployed to connect to the branch bus, and gPTP hardware logic is integrated to provide high-precision time synchronization. Remote control messages from the central control unit are parsed by a parsing module using a physical state machine to decompose the frame header and lock the payload. The conversion module directly converts the digital parameters into heterogeneous hardware bus levels such as SPI / ADC / PWM / I2C based on the configuration register. The drive module receives this level and converts it into a physical drive signal, which directly drives the motor or switch to execute the target action through a bridge drive circuit (HSD / LSD / PWM) or digital I / O, completing the all-hardware high-speed control and data acquisition closed-loop.

[0112] It should be noted that, as Figure 7 As shown, Figure 7 This is a schematic diagram of the two-way data interaction and control closed-loop logic of the vehicle communication system provided in this application embodiment, based on Figure 7 The preceding text describes the complete process in a distributed electronic control system where the central computing platform generates low-level control commands and transmits them to edge execution nodes via in-vehicle Ethernet. The following will explain how, after the central commands reach the edge network, bandwidth adaptation and protocol conversion are performed, ultimately driving the actuators directly through pure hardware circuitry at the very edge nodes. For details, see [link to relevant documentation]. Figure 8 , Figure 8 This is a flowchart illustrating the vehicle communication method provided in the embodiments of this application. Figure 2 ,based on Figure 3 The vehicle communication method provided in this application embodiment can also be implemented through the following steps.

[0113] Step 201, the edge node is used to collect sensing and execution feedback information from the underlying devices connected to the edge node through its built-in acquisition module; and is also used to encapsulate the sensing and execution feedback information into an uplink feedback message and send the uplink feedback message to the branch bus network.

[0114] Here, the data acquisition module is a low-level hardware inside the edge node dedicated to status monitoring and signal acquisition. It is directly connected to the low-level actuators (such as motors and solenoid valves) or external sensors to record the physical status of the low-level devices (including low-level actuators and external sensors) in real time and accurately, and convert them into raw digital signals that can be read by the edge node.

[0115] As mentioned earlier, the process of encapsulating sensor feedback information into uplink feedback messages and sending them to the branch bus network can be achieved through built-in hardware conversion circuits or low-computing-power, low-cost microcontrollers (such as Cortex-M0+ / 8-bit MCUs). The hardware conversion circuit is a protocol processing unit internal to the edge node, implemented using pure physical logic gates (state machines), and possessing high-speed message decomposition and reassembly capabilities. The uplink feedback message refers to a dedicated network data packet generated by a de-MCUized or weakly MCU-based edge node, encapsulated using a standardized Ethernet frame structure or a specific bus protocol, and carrying the latest physical state of the underlying devices. Here, it serves as the carrier for the edge node to transmit data upwards, enabling the raw data collected by the sensors or the physical action feedback of the actuators to be reported to the central computing platform with high real-time performance across the branch bus network.

[0116] In practical implementation, the process of collecting sensing and execution feedback information from the underlying devices connected to the edge node can be achieved by the built-in acquisition module of the edge node, which continuously captures and monitors the electrical parameters of the sensors or actuators located near the vehicle through a pin-level hardware interface (such as an analog-to-digital conversion channel, an input capture pin, or a general-purpose input / output interface). This results in the acquisition of sensing and execution feedback information from the underlying devices connected to the edge node (such as the actual speed of the motor, the original digital voltage of the sensor, etc.).

[0117] Step 202, the edge network processing unit is used to receive uplink feedback messages from the branch bus network through the built-in hardware acceleration conversion circuit; and is also used to perform flow switching and allocation from the branch bus network to the Ethernet backbone network through the hardware acceleration conversion circuit, and distribute the allocated uplink feedback messages to the Ethernet backbone network.

[0118] It should be noted that the built-in hardware acceleration conversion circuit is as described above, and will not be repeated in this embodiment. The stream switching and allocation here refers to the process of standardizing and converting the multiple concurrent data streams from low-speed bus networks (such as 10M Ethernet bus, CAN or LIN bus) and smoothly allocating them to the transmission queue of a high-speed point-to-point Ethernet backbone (such as 100M / 1000M automotive Ethernet).

[0119] In practice, the uplink feedback messages received from the branch bus network are flow-configured and then distributed to the Ethernet backbone network.

[0120] In some embodiments, the hardware-accelerated conversion circuit includes a flow identification module, a routing module, an Ethernet data buffer, and a direct memory access module. The flow identification module is used to determine the target Ethernet interface group corresponding to the uplink feedback message after acquiring it. The routing module is used to determine the physical destination port of the uplink feedback message in the Ethernet backbone network based on the target Ethernet interface group and send the uplink feedback message to the Ethernet data buffer. The direct memory access module is used to send the uplink feedback message in the Ethernet data buffer to the Ethernet backbone network based on the physical destination port.

[0121] It should be noted that the flow identification module, routing module, Ethernet data buffer, and direct memory access module are as described above, and will not be repeated in this embodiment. Furthermore, the processes of determining the target Ethernet interface group corresponding to the uplink feedback message, determining the physical destination port of the uplink feedback message in the Ethernet backbone network, and sending the uplink feedback message in the Ethernet data buffer to the Ethernet backbone network based on the physical destination port are similar to the processes described above: determining the target Ethernet interface group to which the remote control message needs to be forwarded, determining the physical destination port of the remote control message in the Ethernet backbone network, and sending the remote control message in the Ethernet data buffer to the Ethernet backbone network based on the physical destination port. Therefore, these processes will also not be repeated in this embodiment.

[0122] For example, see Figure 9 , Figure 9 This is a flowchart illustrating the protocol conversion process of the edge network processing unit handling uplink feedback data streams, as provided in this embodiment of the application. Figure 9 The protocol conversion process for the edge network processing unit to process the uplink feedback data stream is implemented through steps 901 to 907. Specifically, after receiving the CAN uplink message, the flow identification module extracts the identifier and searches the hardware feature table to determine whether cross-network forwarding is required. If not, local routing is performed; if so, the target Ethernet interface group is determined and directed to the Data Format Engine. The latter uses a hardware state machine to strip the CAN header, extract the payload, and encapsulate it into a standard Layer 2 automotive Ethernet frame. The Routing module searches the MAC address table based on the target interface group to determine the physical destination port and writes the message to the corresponding Ethernet data buffer. Finally, the DMA module polls the buffer, directly extracts the message when the port is idle, and transports it to the Ethernet link, completing the high-speed backhaul to the central computing platform with zero copy.

[0123] Step 203: The central Ethernet gateway is used to route uplink feedback messages to the central computing platform.

[0124] It should be noted that, as mentioned above, the central computing platform here is divided into a physical interface layer, a data link layer, a protocol middleware layer, a communication interface layer, a driver logic layer, and an application layer. Meanwhile, the protocol middleware layer includes a remote communication protocol stack and a service-oriented communication protocol stack, which will not be elaborated on in this embodiment.

[0125] Step 204: The central computing platform is used to extract sensor execution feedback information based on the received uplink feedback message, and upload the sensor execution feedback information to the driver logic layer for sampling and calculation to obtain the current physical state parameters of the underlying actuator.

[0126] Here, sampling calculation refers to a series of processing steps performed by the driving logic layer on the sensor execution feedback information sampled from the uplink, such as data filtering, dimension conversion, physical modeling, and logic state mapping. These processes are used to convert the dimensionless underlying electrical signals into deterministic physical state parameters that can be directly recognized by the upper-layer application, i.e., the current physical state parameters of the underlying actuator.

[0127] In actual implementation, after the physical interface layer and data link layer of the central computing platform capture the uplink feedback message, they deliver it to the protocol middleware layer. The remote communication protocol stack within the middleware layer disassembles the uplink feedback message into a standard Layer 2 Ethernet frame structure, identifies the subtype field in the message, and extracts the corresponding sensor execution feedback information (such as data payloads containing raw phase current analog-to-digital conversion values, encoder pulse count values, or hardware diagnostic source code) based on the communication type indicated by this field (e.g., Ethernet-encapsulated SPI or Ethernet-encapsulated CANFD). Subsequently, the middleware layer uploads the extracted sensor execution feedback information to the driver logic layer through the standardized encapsulation mapping of the driver control protocol interface at the communication interface layer. The drive logic layer first removes high-frequency electromagnetic noise from the original signal using a digital low-pass filtering algorithm. Then, it determines the physical type of the sensor feedback information. If it is a digital quantity of current sampling, it calculates the actual current value of the underlying actuator using a preset linear mapping formula. If it is a pulse count, it calculates the current actual speed and precise displacement of the actuator motor using a timer frequency formula. Finally, it obtains the current physical state parameters of the underlying actuator and uploads the current physical state parameters (i.e., state data) to the application layer (APP) for processing by functional logic or algorithms to make vehicle control decisions for the next cycle.

[0128] It should be noted that the entire process of how the central computing platform generates low-level control commands and transmits them to the edge execution nodes via the vehicle Ethernet is considered the downlink processing process. The entire process of how the central commands, after reaching the edge network, undergo bandwidth adaptation and protocol conversion, and finally drive the actuators directly through pure hardware circuits at the very end edge nodes, is considered the uplink processing process. The process described above, which involves processing the drive control logic based on the execution requirements issued by the application layer according to the drive control protocol interface to obtain control information and then transmitting the control information down to the communication interface layer, is executed during the downlink processing process. On the other hand, the process of processing the physical state data collected by the hardware conversion circuit or microcontroller based on the standardized drive control protocol interface to obtain state data and then reporting the state data to the application layer, is executed during the uplink processing process.

[0129] In some embodiments, the central computing platform includes at least a driver logic layer and a communication interface layer; the communication interface layer is used to encapsulate the original driver communication interface to obtain a standardized driver control protocol interface for the driver logic layer to call; the driver logic layer is used to generate corresponding control commands based on the sensor execution feedback information in the uplink feedback message through the driver control protocol interface; wherein, the control commands are used to send to the underlying driver object to control the underlying actuator connected to the underlying driver object to perform the target physical action.

[0130] It should be noted that, as mentioned earlier, a standardized driver control protocol interface refers to a unified software calling channel generated by the communication interface layer after abstracting and encapsulating the underlying heterogeneous driver communication interfaces. Here, the purpose of the standardized driver control protocol interface is to shield the differences between the underlying network and physical lines, providing a unified data transmission and reception interface for the driver logic layer.

[0131] The underlying driver object refers to the hardware driver integrated circuit or specific physical pin port located at the end of the vehicle network, which directly receives specific protocol control commands and converts them into electrical control loads. It serves as the final physical receiver of control commands issued by the central computing platform, used to receive control commands and directly control the operation of the underlying actuators electrically connected to it. For example, it is a full-bridge power driver chip or pulse width modulation control pin located at the edge node port of the door, which directly operates the window motor.

[0132] Meanwhile, as mentioned above, the target physical action refers to the actual spatial displacement, state deformation, or mechanical work process generated by the internal electromagnetic, mechanical, or physical mechanism of the underlying actuator (such as an actuator motor, solenoid valve, switching device, etc.) after receiving the electrical energy or control level excitation of the aforementioned physical drive signal. For example, it can be the mechanical rotation of a motor (such as an actuator motor rotating at a specific speed according to the duty cycle of the PWM waveform, or rotating clockwise / counterclockwise according to the forward and reverse control level, thereby driving the window regulator to rise, the rearview mirror to fold, or the seat position to adjust), the opening switching or engagement of a valve (such as a solenoid valve coil generating electromagnetic force after receiving the high and low side drive level, overcoming the spring resistance to perform opening or closing actions, thereby regulating the vehicle's brake hydraulic pressure, air suspension airflow, or air conditioning pipeline flow), or the switching of circuit states (such as contacts or power relays performing physical closing or opening actions to realize the power supply switching of high-power vehicle electrical appliances (such as defrosting heating wires, headlights), etc. This application embodiment does not limit this.

[0133] In some embodiments, see Figure 10 , Figure 10 This is a flowchart illustrating the vehicle communication method provided in the embodiments of this application. Figure 3 ,based on Figure 10 The vehicle communication method provided in this application embodiment is implemented through the following steps.

[0134] Step 301: Through the central computing platform, determine the control target of the underlying driver object for the edge node, and encapsulate the control target into a remote control message and send it to the central Ethernet gateway.

[0135] Step 302: The remote control message is routed to the edge network processing unit through the central Ethernet gateway.

[0136] Step 303: The edge network processing unit performs a flow switching and allocation from the Ethernet backbone network to the branch bus network based on the built-in hardware acceleration conversion circuit, and distributes the allocated remote control message to the branch bus network.

[0137] Step 304: Through the edge node, the control target in the remote control message received from the branch bus network is converted into a target physical drive signal, so that the corresponding underlying actuator can perform the target physical action according to the target physical drive signal.

[0138] It should be noted that the processes of steps 301 to 304 correspond to the processes of steps 101 to 104 described above. Therefore, the processes of steps 301 to 304 can be referred to the processes of steps 101 to 104 described above. Here, the embodiments of this application will not be described in detail.

[0139] In some embodiments, see Figure 11 , Figure 11 This is a flowchart illustrating the vehicle communication method provided in the embodiments of this application. Figure 4 ,based on Figure 11 The vehicle communication method provided in this application embodiment is implemented through the following steps.

[0140] Step 401: Collect sensing and execution feedback information from the underlying devices connected to the edge node using the built-in back sampling module at the edge node; and encapsulate the sensing and execution feedback information into an uplink feedback message and send the uplink feedback message to the branch bus network.

[0141] Step 402: The edge network processing unit receives uplink feedback messages from the branch bus network based on the built-in hardware acceleration conversion circuit; and, based on the hardware acceleration conversion circuit, performs flow switching and allocation from the branch bus network to the Ethernet backbone network, and distributes the allocated uplink feedback messages to the Ethernet backbone network.

[0142] Step 403: The uplink feedback message is routed and transmitted to the central computing platform through the central Ethernet gateway.

[0143] Step 404: Through the central computing platform, based on the received uplink feedback message, the sensor execution feedback information is extracted and uploaded to the driver logic layer for sampling and calculation to obtain the current physical state parameters of the underlying actuator.

[0144] It should be noted that the processes of steps 401 to 404 correspond to the processes of steps 201 to 204 described above. Therefore, the processes of steps 401 to 404 can be referred to the processes of steps 201 to 204 described above. Here, the embodiments of this application will not be described in detail.

[0145] In some embodiments, see Figure 12 , Figure 12 This is a schematic diagram of the electronic device provided in the embodiments of this application, based on Figure 12 The electronic device includes, but is not limited to, a processor 1201 and a memory 1202. The memory 1202 is used to store executable instructions of the processor 1201. It is understood that the processor 1201 is configured to execute instructions to implement the vehicle communication method in the above embodiments.

[0146] It should be noted that those skilled in the art will understand that Figure 12 The electronic device structure shown does not constitute a limitation on the electronic device; the electronic device may include, but is not limited to, other electronic devices. Figure 12 This may indicate more or fewer components, or combinations of certain components, or different component arrangements.

[0147] Processor 1201 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in memory 1202, and by calling data stored in memory 1202, it performs various functions and processes data, thereby providing overall monitoring of the electronic device. Processor 1201 may include one or more processing units. Optionally, processor 1201 may integrate an application processor and a modem processor. The application processor mainly handles the operating system, user interface, and applications, while the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into processor 1201.

[0148] The memory 1202 can be used to store software programs and various data. The memory 1202 may primarily include a program storage area and a data storage area. The program storage area may store the operating system, application programs required by at least one functional module (such as a determination unit, processing unit, etc.), etc. Furthermore, the memory 1202 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0149] This application provides a computer program product, which includes computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the processor will execute the vehicle communication method provided in this application.

[0150] This application provides a computer-readable storage medium storing computer-executable instructions or computer programs. When the computer-executable instructions or computer programs are executed by a processor, the processor will execute the vehicle communication method provided in this application.

[0151] In some embodiments, the computer-readable storage medium may be a read-only memory (ROM), random access memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, magnetic surface memory, optical disk, or CD-ROM, etc.; or it may be a device that includes one or any combination of the above-mentioned memories.

[0152] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0153] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hypertext Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0154] As an example, computer-executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0155] It should be noted that in the embodiments of this application, data related to obtaining execution requirements is involved. When the embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0156] The above embodiments are merely preferred embodiments provided to fully illustrate this application, and the scope of protection of this application is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on this application are all within the scope of protection of this application.

Claims

1. A vehicle-mounted communication system, characterized in that, It includes a central computing platform, a central Ethernet gateway, an edge network processing unit, and edge nodes; the central computing platform is connected to the central Ethernet gateway, and the central Ethernet gateway is connected to the edge network processing unit to form an Ethernet backbone network; The edge network processing unit is connected to the edge node via a branch bus network; The central computing platform is used to determine the control target for the underlying driver object of the edge node, and encapsulate the control target into a remote control message and send it to the central Ethernet gateway. The central Ethernet gateway is used to route the remote control message to the edge network processing unit; The edge network processing unit is used to perform flow switching and allocation from the Ethernet backbone network to the branch bus network through a built-in hardware acceleration conversion circuit, and to distribute the allocated remote control messages to the branch bus network. The edge node is used to convert the control target in the remote control message received from the branch bus network into a target physical drive signal, so that the corresponding underlying actuator performs the target physical action according to the target physical drive signal.

2. The system according to claim 1, characterized in that, The central computing platform is divided into a physical interface layer, a data link layer, a protocol intermediate layer, a communication interface layer, a driver logic layer, and an application layer. The physical interface layer is connected to the edge network processing unit via a target interface, which includes at least one of a physical layer interface and a media-independent interface.

3. The system according to claim 2, characterized in that, The protocol middleware layer includes a remote communication protocol stack and a service-oriented communication protocol stack. The remote communication protocol stack is used to process the remote control messages; the service-oriented communication protocol stack is used to process other control messages.

4. The system according to claim 2 or 3, characterized in that, The communication interface layer is used to encapsulate the original driver communication interface to obtain a standardized driver control protocol interface. The driving logic layer is used to perform driving control logic processing based on the driving control protocol interface and the execution requirements issued by the application layer to obtain control information, and then transmit the control information to the communication interface layer. Alternatively, based on the drive control protocol interface, the acquired physical state data can be processed to obtain state data, and the state data can be reported to the application layer.

5. The system according to any one of claims 1 to 4, characterized in that, The hardware acceleration conversion circuit includes a local routing module and a data routing module; The local routing module is used to perform communication routing forwarding between bus interfaces based on communication protocol routing relationships in order to realize local data transmission; The data routing module is used to perform forwarding between bus communication in the branch bus network and Ethernet communication in the Ethernet backbone network to achieve cross-network data transmission.

6. The system according to claim 5, characterized in that, The data routing module includes a flow identification module, a routing module, and a direct memory access module; The flow identification module is used to determine the target Ethernet interface group to which the remote control message needs to be forwarded after acquiring the remote control message; The routing module is used to determine the physical destination port corresponding to the remote control message in the Ethernet backbone network based on the target Ethernet interface group. The direct memory access module is used to send the remote control message to the Ethernet backbone network based on the physical destination port.

7. The system according to claim 6, characterized in that, The data routing module further includes an Ethernet data buffer, and the routing module is also used to send the remote control message to the Ethernet data buffer; The direct memory access module is also used to send the remote control message in the Ethernet data buffer to the Ethernet backbone network based on the physical destination port.

8. The system according to any one of claims 1 to 7, characterized in that, The edge node has a built-in time synchronization module; The time synchronization module is used to provide a global time synchronization reference to support time synchronization between target components, wherein the target components include at least one of the following: the central computing platform, the central Ethernet gateway, the edge network processing unit, and the edge node.

9. A vehicle-mounted communication system, characterized in that, It includes a central computing platform, a central Ethernet gateway, an edge network processing unit, and edge nodes; the central computing platform is connected to the central Ethernet gateway, and the central Ethernet gateway is connected to the edge network processing unit to form an Ethernet backbone network; The edge network processing unit is connected to the edge node via a branch bus network; The edge node is used to collect sensing and execution feedback information from the underlying devices connected to the edge node through a built-in acquisition module. Furthermore, it is also used to encapsulate the sensing execution feedback information into an uplink feedback message and send the uplink feedback message to the branch bus network; The edge network processing unit is configured to receive the uplink feedback message from the branch bus network through a built-in hardware acceleration conversion circuit; and is also configured to perform flow switching and allocation from the branch bus network to the Ethernet backbone network through the hardware acceleration conversion circuit, and distribute the allocated uplink feedback message to the Ethernet backbone network. The central Ethernet gateway is used to route the uplink feedback message to the central computing platform; The central computing platform is used to extract the sensor execution feedback information based on the received uplink feedback message, and upload the sensor execution feedback information to the driver logic layer for sampling and calculation to obtain the current physical state parameters of the underlying actuator.

10. The system according to claim 9, characterized in that, The hardware acceleration conversion circuit includes a stream identification module, a routing module, an Ethernet data buffer, and a direct memory access module; The flow identification module is used to determine the target Ethernet interface group corresponding to the uplink feedback message after acquiring the uplink feedback message; The routing module is used to determine the physical destination port corresponding to the uplink feedback message in the Ethernet backbone network based on the target Ethernet interface group, and send the uplink feedback message to the Ethernet data buffer. The direct memory access module is used to send the uplink feedback message in the Ethernet data buffer to the Ethernet backbone network based on the physical destination port.

11. The system according to claim 9 or 10, characterized in that, The central computing platform includes at least a driver logic layer and a communication interface layer; The communication interface layer is used to encapsulate the original driver communication interface to obtain a standardized driver control protocol interface for the driver logic layer to call. The drive logic layer is used to generate corresponding control commands based on the sensor execution feedback information in the uplink feedback message through the drive control protocol interface. The control command is used to send to the underlying driver object to control the underlying actuator connected to the underlying driver object to perform the target physical action.

12. A vehicle-mounted communication method, characterized in that, The vehicle-mounted communication method is implemented through a vehicle-mounted communication system, which includes a central computing platform, a central Ethernet gateway, an edge network processing unit, and edge nodes. The central computing platform is connected to the central Ethernet gateway, and the central Ethernet gateway is connected to the edge network processing unit to form an Ethernet backbone network. The edge network processing unit and the edge node are connected via a branch bus network; the method includes: The central computing platform determines the control target of the underlying driver object for the edge node, and encapsulates the control target into a remote control message and sends it to the central Ethernet gateway. The remote control message is routed to the edge network processing unit via the central Ethernet gateway; The edge network processing unit performs a flow switching and allocation from the Ethernet backbone network to the branch bus network based on the built-in hardware acceleration conversion circuit, and distributes the allocated remote control messages to the branch bus network. The edge node converts the control target in the remote control message received from the branch bus network into a target physical drive signal, so that the corresponding underlying actuator performs the target physical action according to the target physical drive signal.

13. A vehicle-mounted communication method, characterized in that, The vehicle-mounted communication method is implemented through a vehicle-mounted communication system, which includes a central computing platform, a central Ethernet gateway, an edge network processing unit, and edge nodes. The central computing platform is connected to the central Ethernet gateway, and the central Ethernet gateway is connected to the edge network processing unit to form an Ethernet backbone network. The edge network processing unit and the edge node are connected via a branch bus network; the method includes: Through the edge node, based on the built-in back sampling module, the sensing and execution feedback information of the underlying devices connected to the edge node is collected; and the sensing and execution feedback information is encapsulated into an uplink feedback message and the uplink feedback message is sent to the branch bus network. The edge network processing unit receives the uplink feedback message from the branch bus network based on the built-in hardware acceleration conversion circuit; and, based on the hardware acceleration conversion circuit, performs flow switching and allocation from the branch bus network to the Ethernet backbone network, and distributes the allocated uplink feedback message to the Ethernet backbone network. The uplink feedback message is routed to the central computing platform through the central Ethernet gateway. The central computing platform extracts the sensor execution feedback information based on the received uplink feedback message and uploads the sensor execution feedback information to the driver logic layer for sampling and calculation to obtain the current physical state parameters of the underlying actuator.

14. An electronic device, characterized in that, include: Memory is used to store executable instructions or computer programs. A processor, when executing computer-executable instructions or computer programs stored in the memory, implements the vehicle communication method of claim 12 or 13.

15. A computer-readable storage medium, characterized in that, It stores computer-executable instructions or computer programs for inducing the processor to execute and implement the vehicle communication method of claim 12 or 13.

16. A computer program product comprising computer-executable instructions or a computer program, characterized in that, When the computer-executable instructions or computer program are executed by the processor, the vehicle communication method of claim 12 or 13 is implemented.

Images