SOA architecture vehicle-cloud integrated communication middleware system and deployment method

Abstract

The invention provides an SOA architecture vehicle-cloud integrated communication middleware system and a deployment method, and the system comprises a unified communication interface module which is used for providing a Topic-based publishing / subscribing model communication interface for an application layer, and providing a Method-based client / server model remote service calling interface; the communication abstraction and adaptation module is used for performing unified abstraction and protocol conversion on various heterogeneous physical buses and communication protocols in the vehicle and among vehicle clouds; the system configuration and management module is used for carrying out centralized configuration and management on definition of communication interfaces, mapping relations of communication channels and system operation parameters; the system receives a communication request of an application layer through the unified communication interface module, obtains configuration information through the system configuration and management module, and adapts the communication request to a specific physical bus or a network protocol for transmission through the communication abstraction and adaptation module. According to the system and the deployment method provided by the invention, the service logic of the application layer and the complex communication of the bottom layer are thoroughly decoupled.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to an SOA architecture vehicle-cloud integrated communication middleware system and deployment method. Background Technology

[0002] With the rapid development of automotive intelligence, Software-Defined Vehicle (SDV) has become an industry consensus. In-vehicle software systems are becoming increasingly complex, exhibiting a heterogeneous distributed computing paradigm with multiple operating systems (such as QNX, Linux, and Android) coexisting and multiple domain controllers (such as the driving domain, cockpit domain, and body domain) working collaboratively. Simultaneously, Vehicle-to-Everything (V2X) collaboration has become crucial for achieving advanced autonomous driving, intelligent cockpits, and continuous functional upgrades.

[0003] However, the current in-vehicle communication system faces severe challenges. First, communication media and protocols are highly fragmented. This includes traditional in-vehicle buses (such as CAN and LIN), emerging high-speed in-vehicle networks (such as in-vehicle Ethernet and fiber optics), and wireless communications (4G / 5G), as well as inter-core communication within and between SoCs (such as shared memory, SPI, and IPCF). Second, heterogeneous operating systems and hardware platforms result in deep coupling between upper-layer application development and lower-layer communication. Developers must have a thorough understanding of various bus characteristics, network protocol stacks, and operating system interfaces, leading to low development efficiency, poor code portability, and excessive repetitive work. Summary of the Invention

[0004] This invention provides an SOA architecture vehicle-cloud integrated communication middleware system and deployment method to solve the defects of existing vehicle communication systems, such as complex development, low efficiency, and poor software reusability caused by the high heterogeneity of media, protocols, and platforms. It achieves complete decoupling of business logic and underlying communication, and provides a unified communication infrastructure that is efficient, reliable, secure, and flexibly portable for software-defined vehicles.

[0005] This invention provides an SOA architecture vehicle-cloud integrated communication middleware system, the system comprising: The unified communication interface module is used to provide the application layer with a topic-based publish / subscribe model communication interface, as well as a method-based client / server model remote service call interface; The communication abstraction and adaptation module is used to perform unified abstraction and protocol conversion of various heterogeneous physical buses and communication protocols within the vehicle and between the vehicle and the cloud. The system configuration and management module is used to centrally configure and manage the definition of the communication interface, the mapping relationship of the communication channel, and the system operating parameters; The system receives communication requests from the application layer through the unified communication interface module, obtains configuration information through the system configuration and management module, and adapts the communication requests to a specific physical bus or network protocol for transmission through the communication abstraction and adaptation module, thereby decoupling the application layer business logic from the underlying communication implementation details.

[0006] According to the system provided by the present invention, the unified communication interface module includes: The Topic library component is used to define data transmission links and provide a communication interface based on the publish / subscribe model for the application layer. The interface identifies communication endpoints with a Topic and carries business data with standardized Message data entities. The Method library component is used to provide the application layer with a remote service call interface based on a client / server model. The interface identifies the remotely called service using a Method and encapsulates the request and response using the Message data entity.

[0007] According to the system provided by the present invention, the Message data entity includes two parts: a Header and a Payload. The Header contains identifying information representing the characteristics of the physical communication link, and the Payload is a data structure carrying service information. The structure of the Payload adopts different encapsulation rules according to the type of the two communicating parties. When both communicating parties are microcontroller units (MCUs), the signals are encapsulated into a structure generated by the AUTOSAR XML description file according to the AUTOSAR software component interface definition. When both communicating parties are on-chip system-on-a-chip (SoC) or one of them is in the cloud, the variable field structure is encapsulated according to the Protocol Buffer method. When one party to the communication is an MCU and the other party is an SOC, the data types defined by the Service-Oriented Architecture (SOA) service interface are encapsulated into a structure that conforms to the SOMEIP protocol standard.

[0008] According to the system provided by the present invention, the Message data entity predefines a data structure covering various fields of the whole vehicle, including cloud, body domain, intelligent driving domain, cockpit domain, power domain, chassis domain, vehicle basic information and diagnostic information.

[0009] According to the system provided by the present invention, the system further includes: A QoS policy management component is used to implement end-to-end quality of service guarantee policies for communications initiated through the Topic library component and the Method library component. The quality of service (QoS) assurance strategy includes at least one of the following: redundancy QoS strategy, time-limited QoS strategy, best-effort QoS strategy, reliable QoS strategy, and end-to-end QoS strategy.

[0010] According to the system provided by the present invention, the system further includes: A serialization / deserialization component is used to automatically identify and perform serialization and deserialization operations on communication data according to the configuration of the system configuration and management module; The serialization / deserialization components support the following serialization methods: Protocol Buffer serialization for cross-operating system communication, binary memory copy serialization for high-performance communication within the same operating system, and AUTOSAR serialization to meet the AUTOSAR specification.

[0011] According to the system provided by the present invention, the communication abstraction and adaptation module supports communication methods including physical bus and communication protocol; The physical bus includes automotive Ethernet, fiber optic, Controller Area Network (CAN), PCIe (PCIe), Serial Peripheral Interface (SPI), and Inter-core Communication Framework (IPCF). The communication protocols include Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Service-Oriented Internet Protocol (SOMEIP), Data Distribution Service (DDS), Message Queuing Telemetry Transport (MQTT), and Hypertext Transfer Protocol Secure (HTTPS).

[0012] According to the system provided by the present invention, the system further includes: The scheduling center component is used to dynamically orchestrate and schedule communication tasks in the system according to a variety of predefined scheduling strategies; The scheduling strategy includes at least one of the following: high-concurrency scheduling strategy, persistent scheduling strategy, pipelined scheduling strategy, and periodic scheduling strategy.

[0013] According to the system provided by the present invention, the configuration items of the system configuration and management module include Topic name, Method name, communication channel configuration, and serialization method configuration for each Topic or Method; The communication channel configuration includes the channel identifier, communication method, and corresponding parameters.

[0014] The present invention also provides a communication configuration and deployment method based on the system, the method comprising: The system acquires and parses the AUTOSAR-based communication service interface definition file from the microcontroller unit (MCU) side, and the service interface definition file containing Topic communication data structure from the system-on-chip (SoC) side. Based on the parsed interface information, a mapping relationship is established between the Topic sender and receiver. Depending on the type of the sender and receiver, the AUTOSAR-based data structure is determined and adapted for communication, or communication is based on serialized data types and pre-set message data. Based on the established mapping relationship and adaptation results, a unified configuration file for the middleware system is generated; Based on the unified configuration file, the application is deployed and run, enabling the application to communicate by calling the unified communication interface of the middleware system.

[0015] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the communication configuration and deployment method as described above.

[0016] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the communication configuration and deployment method as described above.

[0017] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the communication configuration and deployment method as described above.

[0018] The SOA architecture vehicle-cloud integrated communication middleware system and deployment method provided by this invention completely decouples application-layer business logic from the complex underlying communication implementation by constructing a service-oriented unified communication abstraction layer. This system provides upper-layer software with standard communication interfaces independent of programming languages ​​and operating systems, allowing developers to focus on functional development without worrying about the specific details of heterogeneous in-vehicle buses, network protocols, and inter-core communication, thus significantly improving development efficiency and code maintainability.

[0019] Meanwhile, the system achieves unified management and intelligent routing of multiple communication media such as CAN, automotive Ethernet, and 5G through an extensible protocol adaptation mechanism. Furthermore, it optimizes and monitors communication resources across the entire vehicle and the vehicle-to-cloud through centralized configuration management. This system enables in-vehicle software to achieve one-time development and multi-platform deployment, significantly improving software reusability and portability, and providing a highly reliable, secure, and flexibly evolving integrated communication infrastructure for software-defined vehicles. Attached Figure Description

[0020] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0021] Figure 1 This is one of the structural diagrams of the SOA architecture vehicle-cloud integrated communication middleware system provided by the present invention.

[0022] Figure 2 This is the second structural schematic diagram of the vehicle-cloud integrated communication middleware system provided by the present invention.

[0023] Figure 3 This is the third structural schematic diagram of the vehicle-cloud integrated communication middleware system provided by the present invention.

[0024] Figure 4 This is a flowchart illustrating the communication configuration and deployment method provided by the present invention.

[0025] Figure 5 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0027] The embodiments of the present invention can be applied to scenarios that require unified communication across platforms, protocols, and networks, such as communication between intelligent vehicle domain control systems, vehicle-cloud collaborative computing, and integration of heterogeneous in-vehicle software components.

[0028] Figure 1 This is one of the structural diagrams of the SOA architecture vehicle-cloud integrated communication middleware system provided by the present invention, such as... Figure 1 As shown, the system includes: The unified communication interface module 110 is used to provide the application layer with a Topic-based publish / subscribe model communication interface and a Method-based client / server model remote service call interface; The communication abstraction and adaptation module 120 is used to perform unified abstraction and protocol conversion of various heterogeneous physical buses and communication protocols within the vehicle and between the vehicle and the cloud. The system configuration and management module 130 is used for centralized configuration and management of the definition of communication interfaces, the mapping relationship of communication channels, and system operating parameters; The system receives communication requests from the application layer through the unified communication interface module, obtains configuration information through the system configuration and management module, and adapts the communication requests to specific physical buses or network protocols for transmission through the communication abstraction and adaptation module, thereby decoupling the application layer business logic from the underlying communication implementation details.

[0029] Specifically, the unified communication interface module is the single, standardized set of programming interfaces (APIs) exposed by the middleware system to upper-layer applications. This module encapsulates all the complex communication details at the underlying level, providing developers with two mainstream, high-level communication paradigms (publish / subscribe and request / response), allowing developers to focus solely on the business logic itself without worrying about how data is transmitted across networks, buses, or operating systems.

[0030] For the implementation of the unified communication interface module, a standalone software development kit (SDK) is provided, which includes API libraries for different programming languages ​​(such as C++, Python, and Java). Within the API, the factory pattern can be used to create communication entities such as Publisher, Subscriber, Client, and Server. The unified communication interface module and the communication abstraction and adaptation module exchange data and instructions efficiently through internal message queues, shared memory, or inter-process calls, thus decoupling interface calls from underlying data transmission.

[0031] The communication abstraction and adaptation module is the protocol conversion and adaptation engine of the middleware system. Its core function is to translate and convert communication requests with standard formats issued by the unified communication interface module into specific data frames or network protocol packets that can be recognized and processed by the target underlying physical channel (such as CAN bus, Ethernet, 4G module, etc.), and vice versa. This module bridges the gap between the unified communication semantics and the diversity of physical implementations.

[0032] The communication abstraction and adaptation module can be implemented using a plug-in / driver architecture. Independent protocol adapter plug-ins are written for each supported communication medium (such as CAN, SOME / IP over Ethernet, DDS-RTPS, MQTT over 5G). Internally, a unified data model is implemented as an intermediate language for conversion between various protocols.

[0033] The communication abstraction and adaptation module may include a routing engine, which determines which specific adapter plugin to send data packets to for processing and transmission based on the mapping table provided by the system configuration and management module.

[0034] The system configuration and management module is the central configuration and control system of the middleware. This module is responsible for centrally managing all static configurations, such as which services are available, how topics are defined, and who publishes to whom, before or during system startup, as well as dynamic parameters such as Quality of Service (QoS) policies, security policies, and routing rules.

[0035] For the implementation of the system configuration and management module, a graphical configuration tool and / or a domain-specific language can be provided for architects or developers to define communication models. The configuration tool compiles user-defined configurations into a machine-readable unified configuration file. During middleware runtime, a persistent configuration management service is responsible for loading and parsing this configuration file, and distributing the rules within it to the corresponding components of the unified communication interface module and the communication abstraction and adaptation module. This module can also integrate a service discovery mechanism to achieve dynamic management and updating of communication endpoint addresses.

[0036] The system provided in this invention completely decouples application-layer business logic from complex underlying communication by constructing a service-oriented unified communication abstraction layer. This system provides upper-layer software with standard communication interfaces independent of programming languages ​​and operating systems, freeing developers from the specific details of heterogeneous in-vehicle buses, network protocols, and inter-core communication. This allows them to focus on functional development, significantly improving development efficiency and code maintainability. Simultaneously, the system achieves unified management and intelligent routing of multiple communication media such as CAN, in-vehicle Ethernet, and 5G through an extensible protocol adaptation mechanism. Furthermore, centralized configuration management optimizes and monitors communication resources across the entire vehicle and the vehicle cloud. Ultimately, this system enables in-vehicle software to achieve one-time development and multi-platform deployment, greatly improving software reusability and portability, and providing a highly reliable, secure, and flexibly evolving integrated communication infrastructure for software-defined vehicles.

[0037] Based on the above embodiments, the unified communication interface module 110 specifically includes: Topic library component 111 is used to define data transmission links and provide a communication interface based on the publish / subscribe model for the application layer. The interface identifies the communication endpoint with Topic and carries business data with standardized Message data entities. Method library component 112 is used to provide the application layer with a remote service call interface based on the client / server model. The interface identifies the remotely called service with a Method and encapsulates the request and response using the Message data entity.

[0038] Specifically, the Topic library component is the core of the unified communication interface module, responsible for implementing the publish / subscribe (Pub / Sub) communication model. A Topic is a logical identifier for a communication endpoint, used to distinguish different data streams, such as vehicle speed information and battery status. The Message data entity is a standardized data structure used to carry business data (such as JSON, Protobuf, etc.) to ensure data compatibility between different systems.

[0039] The Topic library contains key characteristic values ​​for different communication methods, encapsulated into standardized API interfaces and implemented at the interface layer. The Topic library defines the core data structure related to communication and also refers to a specific data transmission link. In the context of a Topic, the two parties actually transmit messages based on the negotiated terms. A message refers to the data transmitted in this communication link, used to carry different business information.

[0040] The unified communication interface module also includes a Method library component. This component provides a client / server model, supporting remote service calls (RPC). A Method is a unique identifier for a remote service, such as retrieving vehicle status or controlling door locks. Clients trigger server-side logic by invoking a Method. Requests and responses are encapsulated with input parameters and return results using Messages, enabling cross-process and cross-device service calls.

[0041] The Method library component is responsible for implementing the Client / Server communication model. It provides a standardized API to the application layer at the interface layer. The Method identifies the remote call to a service / function, supporting the commonly used SOMEIP and DDS SOA implementations. The Method uses messages to transmit requests and responses. The client sends a request message to the server. After receiving the request, the server processes it (executes the remote call) and encapsulates the structure in a message before returning it to the client, completing a closed-loop RR message exchange.

[0042] In some embodiments, the Message data entity comprises two parts: a Header and a Payload. The Header is a message header added by the communication bus, containing some identifying information that represents the characteristics of the physical communication link. The Payload is a data structure that carries business information, and the structure of the Payload adopts different encapsulation rules according to the type of the two communicating parties. When both communicating parties are microcontroller units (MCUs), the signals are encapsulated into a structure generated by the AUTOSAR XML description file according to the AUTOSAR software component interface definition. When both communicating parties are on-chip system-on-a-chip (SoC) or one of them is in the cloud, the variable field structure is encapsulated according to the Protocol Buffer method. When one party to the communication is an MCU and the other party is an SOC, the data types defined by the Service-Oriented Architecture (SOA) service interface are encapsulated into a structure that conforms to the SOMEIP protocol standard.

[0043] Specifically, a message is a standard data unit transmitted between two ends of a communication, and it is the smallest complete package carrying information. It typically contains two parts: a header and a payload, to ensure that the data can be correctly identified, routed, and interpreted in complex heterogeneous environments.

[0044] The header is not the application business data itself, but rather control information automatically added by the communication middleware based on the actual physical transmission path (bus or network). Physical communication links include, for example, CAN bus information (transmitter / receiver network segment information, CAN ID information, etc.) and automotive Ethernet information (MAC address, IP address, VLAN, TCP / IP information, etc.). Flag information is used to indicate message priority, source / destination address, timestamp, data format version, checksum, etc., to ensure the reliability and real-time performance of message transmission on a specific link.

[0045] The payload is the data structure that actually carries the business information of the upper-layer application. In this embodiment, the payload's structure encapsulation rules are dynamically adaptable, and its format depends on the device types at both ends of the communication, thereby achieving seamless integration between different computing platforms and communication paradigms.

[0046] When both communicating parties are traditional automotive microcontrollers (MCUs), the software component interface description file (ARXML) defined in the AUTOSAR standard is used to generate strict, static C language structures. This approach meets the deterministic and real-time requirements of traditional automotive electronics, as the signal layout is completely determined at compile time.

[0047] When communication involves high-performance computing platforms (SoCs) or the cloud, an efficient, platform-independent serialization protocol is used. It encapsulates data into a compact binary format and supports forward / backward compatible field expansion, making it ideal for service-oriented, complex business scenarios that require frequent iterations.

[0048] When communication occurs between a traditional MCU and a high-performance SoC, a service-oriented architecture (SOA) interface definition is used. Typically based on the SOME / IP (Scalable Service-Oriented Middleware over IP) protocol standard, it encapsulates service interfaces, methods, events, etc., into a standard format that can be transmitted over automotive Ethernet, acting as a translator between traditional signal-oriented communication and service-oriented communication.

[0049] This embodiment breaks down the communication barriers between traditional in-vehicle networks (signal-oriented) and new service-oriented networks (service-oriented). Through a unified message model, coupled with three intelligently adaptable encapsulation rules, it enables communication using the same language from the lowest-level sensors / actuators (MCUs) to high-performance domain controllers / central computing units (SoCs) and the cloud, achieving true vehicle-cloud integration.

[0050] Furthermore, optimal packaging methods are used for different platforms. In resource-constrained MCU environments with extremely high real-time requirements, the compile-time determined AUTOSAR structure is used, resulting in minimal overhead and latency. In resource-rich SoC / cloud environments with flexible and varied services, Protobuf is used, achieving excellent flexibility and compatibility while maintaining high performance. This differentiated strategy is far superior to compromise solutions using a single format in terms of overall efficiency.

[0051] Based on the above embodiments, the Message data entity predefines a data structure covering all areas of the vehicle, including cloud, body domain, intelligent driving domain, cockpit domain, power domain, chassis domain, vehicle basic information and diagnostic information.

[0052] Specifically, the Message data entity is a structured data model used in vehicle networking systems to uniformly abstract and define data from different domains of the vehicle. It predefines a standardized format covering multiple functional domains such as cloud, body domain, intelligent driving domain, cockpit domain, powertrain domain, chassis domain, vehicle basic information, and diagnostic information, ensuring that data from each domain has consistent semantics and structure during transmission and processing.

[0053] Applications can communicate with each other using the pre-built message entity in the system, enabling functions such as subscription and remote calls. The information contained in a message is as follows: Basic information: VIN code, vehicle model, etc.; Intelligent driving domain: radar and vision-related information; Vehicle body domain: control signal information for doors, windows, locks, lights, etc.; Cockpit area: Vehicle infotainment system, DMS and other information; CarCloud: Information such as TSP, encrypted links, and IoT protocols; Diagnostics: Onboard automatic diagnostic system, emissions-related DTC / DID information, etc.

[0054] In practical implementation, dedicated data structure templates can be established for each domain. For example, the power domain includes fields such as vehicle speed and battery level, while the intelligent driving domain includes parameters such as sensor status and path planning. Cross-domain data interfaces are defined using interface description languages ​​or protocol buffers, such as Protobuf, to achieve seamless integration between different software and hardware modules. A publish / subscribe mechanism for data is implemented based on automotive-grade message middleware to ensure real-time and reliable distribution and synchronization. By reserving extended fields or modular plugins, flexible access to new domains or data types can be supported, adapting to vehicle model iterations or functional upgrades.

[0055] In some embodiments, the middleware system further includes: QoS policy management component 140 is used to implement end-to-end quality of service guarantee policies for communications initiated through Topic library component and Method library component; Quality of Service (QoS) assurance strategies include at least one of the following: redundancy QoS strategy, time-limited QoS strategy, best-effort QoS strategy, reliable QoS strategy, and end-to-end QoS strategy.

[0056] Specifically, the QoS policy management component uses predefined policy rules to dynamically control key indicators such as latency, reliability, and redundancy during data transmission, ensuring that communication quality requirements are met in different business scenarios.

[0057] Redundant QoS Strategy: The communication receiver retains N (configurable, default value 1) samples. When more than N communication data are received, the oldest sample is overwritten to ensure that communication is not lost and is traceable. This strategy is suitable for intelligent driving domain communication with high confidence requirements. Redundant QoS strategies are used to transmit critical data (such as sensor fusion results) via multiple paths, improving the system's fault tolerance.

[0058] Time-limited QoS strategy: For periodic communication scenarios, if no data is received within a set periodic threshold, an error is immediately reported. This QoS strategy provides another layer of guarantee for real-time communication. For example, applying a time-limited QoS strategy to autonomous driving control commands strictly limits end-to-end latency and prevents control failure due to communication delays.

[0059] Best-effort QoS strategy: In communication scenarios where UDP lacks protocol-layer reliability guarantees, it relies on network capabilities to transmit data in the best possible way. For non-critical data (such as log uploads), a best-effort QoS strategy is employed to avoid consuming excessive network bandwidth and balance the overall system load.

[0060] Trustworthy QoS strategy: In TCP scenarios, reliable communication transmission is achieved by relying on network L2 / L3 configuration.

[0061] End-to-end QoS strategy: For inter-core communication scenarios, E2E profile 6 is used to protect communication data. By combining end-to-end QoS strategy and trusted QoS strategy, the entire link from sensors and computing units to actuators is guaranteed to meet functional safety and information security requirements, supporting the stable operation of advanced autonomous driving and intelligent cockpits.

[0062] In some embodiments, the middleware system further includes: The serialization / deserialization component 150 is used to automatically identify and perform serialization and deserialization operations on communication data according to the configuration of the system configuration and management module. The serialization / deserialization component supports the following serialization methods: ProtocolBuffer serialization for cross-operating system communication, binary memory copy serialization for high-performance communication within the same operating system, and AUTOSAR serialization to meet the AUTOSAR specification.

[0063] Specifically, the serialization / deserialization component is a key data processing module in the vehicle-to-everything (V2X) middleware system. Its function is to automatically identify the format and communication scenario of the communication data based on instructions from the system configuration and management module, and perform corresponding data serialization (converting structured data into a byte stream) and deserialization (restoring the byte stream back to structured data) operations. It supports multiple serialization methods to adapt to different system integration and performance requirements.

[0064] The vehicle-cloud integrated communication middleware system automatically identifies the serialization method through configuration files, decoupling the underlying serialization / deserialization implementation from the application layer. When the serialization method changes, the application does not need to be modified. The system automatically calculates the optimal serialization method based on the application's deployment location (operating system, network topology, etc.), supporting the following serialization implementations: A. ProtoBuf: Decoupled from programming languages ​​and hardware platforms, it is used for communication scenarios between different operating systems. As a cross-platform, cross-language serialization protocol, Protocol Buffer serialization ensures strict consistency and efficient parsing of data structures between heterogeneous operating systems on the vehicle side (such as QNX, Linux, Android) and during vehicle-to-cloud communication, reducing integration problems caused by data format mismatches.

[0065] B. Binary: Serialization transmission via memory copying results in fewer copy operations and higher performance; used for high-performance communication scenarios between different applications within the same operating system. For inter-process communication within the same operating system, direct memory copying achieves extremely low latency and high throughput data exchange, meeting the real-time communication needs of modules in the intelligent driving domain, chassis domain, and other applications.

[0066] C. AutoSAR Serialization: Communication serialization that meets the AutoSAR specification, satisfying traditional ECU communication scenarios based on the CAN bus. By supporting serialization methods compliant with the AutoSAR specification, it ensures that middleware can be seamlessly integrated into traditional ECUs that conform to the AutoSAR standard, protecting existing investments and promoting the integration of new and old architectures. It is an important support for achieving a unified vehicle software architecture.

[0067] The transceiver application selects different serialization / deserialization methods based on the chip type information in the Topic: for example, MCU-to-MCU communication uses the AUTOSAR standard COM method; MCU-to-SOC communication uses the SOMEIP standard serialization method; SOC-to-SOC communication uses the protobuf serialization method; and vehicle-to-cloud communication uses the JSON standard serialization method.

[0068] In some embodiments, the communication abstraction and adaptation module supports communication methods including physical bus and communication protocols; The physical bus includes automotive Ethernet, fiber optics, Controller Area Network (CAN), PCIe (PCIe), Serial Peripheral Interface (SPI), and Inter-core Communication Framework (IPCF). Communication protocols include Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Service-Oriented Internet Protocol (SOMEIP), Data Distribution Service (DDS), Message Queuing Telemetry Transport (MQTT), and Hypertext Transfer Protocol Secure (HTTPS).

[0069] Specifically, the function of the communication abstraction and adaptation module is to uniformly encapsulate and abstract the diverse underlying physical transmission media (physical bus) and communication protocols. This module provides a standardized communication interface to the application layer, enabling upper-layer software to use different underlying communication mechanisms in a consistent manner without needing to concern itself with their specific implementation details.

[0070] This module incorporates various heterogeneous buses, such as automotive Ethernet, CAN, PCIe, fiber optic, SPI, and IPCF, into a unified abstract framework. This enables software components from different vendors and running on different hardware platforms (such as domain controllers, sensor nodes, and actuators) to discover, connect, and exchange data with each other, effectively shielding the complexity of the underlying hardware.

[0071] By integrating low-latency, high-reliability real-time communication protocols such as DDS and SOME / IP, lightweight IoT messaging protocols such as MQTT, and general-purpose internet protocols such as TCP, UDP, and HTTPS, the communication abstraction and adaptation module can simultaneously meet the communication needs of different dimensions, including in-vehicle, vehicle-to-vehicle, and vehicle-to-cloud communication. For example, DDS and SOME / IP can meet the deterministic and low-latency requirements of intelligent driving control commands; while MQTT and HTTPS are suitable for cloud interaction scenarios such as vehicle status data reporting and remote diagnostics.

[0072] In some embodiments, the middleware system further includes: The scheduling center component is used to dynamically orchestrate and schedule communication tasks in the system according to a variety of predefined scheduling strategies; Scheduling strategies include at least one of the following: high-concurrency scheduling strategy, persistent scheduling strategy, pipelined scheduling strategy, and periodic scheduling strategy.

[0073] Specifically, the scheduling center component is responsible for dynamically managing the execution flow of communication tasks. By parsing task requirements, matching scheduling strategies, and allocating resources (such as threads, connections, and computing nodes), it achieves full lifecycle management of tasks from pending execution to completion.

[0074] Here, dynamic orchestration refers to flexibly adjusting the execution order, dependencies, and resource allocation of tasks based on real-time system status, such as load, resource availability, task priority, and predefined rules, rather than a fixed process. Scheduled execution refers to allocating the orchestrated tasks to specific execution units, such as thread pools or service instances, monitoring the execution process, handling exceptions, and ensuring task completion.

[0075] Among them, the high-concurrency scheduling strategy refers to executing communication tasks concurrently to the maximum extent based on the priority carried by the tasks. For scenarios where a large number of tasks flood in within a short period of time, mechanisms such as resource pooling, task fragmentation, and traffic shaping are used to increase the amount of tasks processed per unit time and avoid system overload.

[0076] Persistent scheduling strategy refers to binding tasks to a designated thread, and through the system interface, specifying that the bound thread exclusively uses system scheduling resources to ensure the determinism of high-priority communication tasks.

[0077] Pipeline scheduling strategy refers to ensuring that multiple types of communication tasks are executed fairly, like a pipeline.

[0078] Periodic scheduling strategy refers to a communication mechanism used to schedule the period in a specific scenario.

[0079] In some embodiments, the configuration items of the system configuration and management module include Topic name, Method name, communication channel configuration, and serialization method configuration for each Topic or Method; wherein, the communication channel configuration includes channel identifier, communication method and its corresponding parameters.

[0080] Specifically, configuration items refer to the set of key parameters that the system depends on for operation. In this embodiment, configuration items include: Topic Name: The name passed in when creating a Topic in the communication sender / receiver code, uniquely identifying a Topic. The Topic name is a unique identifier for a communication topic, used to classify and manage communication tasks, similar to a Topic in a message queue. Producers send tasks to a specified Topic, and consumers subscribe to the corresponding Topic to receive tasks.

[0081] Method Name: Passed in when creating the Method in the communication transceiver code, corresponding to the service method called via SOMEIP or DDS remote invocation. The Method name is the identifier of the specific communication method, defining the operation type of the task and clarifying the specific behavioral logic of the task.

[0082] Communication Channel Configuration: This section defines the communication channel's communication method and parameters, defining the channel attributes for task transmission. It includes two parts: the channel identifier and the communication method and its parameters. The channel identifier is a unique ID used to distinguish different channels (e.g., HTTP channel, MQTT channel, RPC channel). The communication method and its parameters include: UDP communication: source IP address, source port number, destination IP address, destination port number, etc. TCP communication: source IP address, source port number, destination IP address, destination port number, etc. Shared memory communication: shared memory block size, number of shared memory blocks, maximum number of subscriptions, etc.; IPCF communication: Consumer ID, Provider ID, Multi-core Multiprocessor partition name, etc.; Car-Cloud Communication: Jason or URI description, MQTT and HTTPS types, TLS configuration, etc.

[0083] The configuration options also include the serialization method used for each Topic or Method. The serialization method configuration specifies the encoding / decoding rules (such as JSON, Protobuf, Avro, Hessian) during data transmission, used to convert objects into byte streams (serialization) or reverse them (deserialization), ensuring data compatibility across systems / languages.

[0084] In this embodiment of the invention, communication details such as Topic, Method, Channel, and Serialization method are abstracted into configuration items. Business logic only needs to focus on which Topic / Method to call, without the need to hardcode the communication protocol or data format, thereby decoupling business and communication logic and improving flexibility.

[0085] Figure 2 This is the second structural schematic diagram of the vehicle-cloud integrated communication middleware system provided by the present invention. Figure 3 This is the third structural schematic diagram of the vehicle-cloud integrated communication middleware system provided by the present invention, as shown below. Figure 2 and Figure 3 As shown, the vehicle-cloud integrated communication middleware system provides consistent encapsulation for different chip architectures, operating systems, physical buses, and network communication protocols, and performs abstraction and mapping through channel management.

[0086] Different channels contain different physical characteristics and protocol features. These features are described using a model language and are guaranteed to be loaded by the vehicle-cloud integrated communication middleware at runtime in an independent configuration file.

[0087] like Figure 2 As shown, the vehicle-cloud integrated communication middleware system supports mainstream communication methods within the vehicle and between the vehicle and the cloud, covering all communication methods in the current R&D and design process, and providing the following types of communication service interfaces: Inter-process / inter-thread communication interfaces within the same operating system; The vehicle-to-cloud communication interface is based on 4G / 5G and abstracts MQTT and HTTPS. The inter-core communication between the A core and the M core in a heterogeneous core SoC abstracts the IPCF communication interface of their respective physical media and implementation methods (SPI, UART, Shared Memory, etc.); The communication interface between SOMEIP and DDS is abstracted based on services between different chips; Chip-to-chip communication is based on a bus and abstracts communication interfaces such as CAN and PCIe.

[0088] Based on the above embodiments, Figure 4 This is a flowchart illustrating the communication configuration and deployment method provided by the present invention, as shown below. Figure 4 As shown, this method is based on the above-mentioned SOA architecture vehicle-cloud integrated communication middleware system, and the deployment method includes the following steps 410 to 440.

[0089] Step 410: Obtain and parse the AUTOSAR-based communication service interface definition file from the microcontroller unit (MCU) side, and the service interface definition file containing Topic communication data structure from the system-on-chip (SoC) side. Step 420: Based on the parsed interface information, establish a mapping relationship between the Topic sender and receiver, and determine and adapt whether to use AUTOSAR-based data structure for communication or based on serialized data type and preset message data according to the type of sender and receiver. Step 430: Based on the established mapping relationship and adaptation results, generate a unified configuration file for the middleware system; Step 440: Based on the unified configuration file, deploy and run the application, enabling the application to communicate by calling the unified communication interface of the middleware system.

[0090] Specifically, the communication service interface definition file on the MCU side follows the AUTOSAR standard .arxml or other format files, describing information such as the communication service names, signal list, data types, and message layout supported by the MCU.

[0091] The communication service interface definition file on the SoC side is a message format description file for the publish / subscribe model. It may be IDL, JSON Schema, Protobuf .proto, etc., and defines the Topic name, fields, nesting structure, and serialization method.

[0092] The communication capability descriptions of the MCU and SoC are obtained separately to form a unified input data source. Interface files of different formats are converted into internal data structures that the middleware can recognize, in preparation for subsequent mapping.

[0093] The mapping relationship between the sender and receiver of a Topic refers to a logical correspondence, such as mapping a specific AUTOSAR signal from an MCU to a specific field of a Topic in a SoC. The purpose of establishing cross-domain mapping is to allow MCU signals to be mapped to SoC Topics via middleware, and vice versa. Adapting the communication mode means selecting the appropriate transmission data structure based on the endpoint type; for AUTOSAR endpoints, the native AUTOSAR format is used; for Topic endpoints, a serialized format is used. This achieves seamless integration between the AUTOSAR and Topic communication paradigms. Adding a new endpoint only requires updating the mapping table, and the middleware will automatically adapt to the communication method.

[0094] The unified configuration file of the middleware system is a centralized configuration read by the middleware runtime. It can be in JSON / YAML / XML format and contains information such as all topics, methods, channels, serialization methods, and mapping rules. AutoSAR applications are then developed based on this configuration, allowing applications to directly call the encapsulated unified standard communication interface.

[0095] In other embodiments, the deployment steps of the vehicle-cloud integrated communication middleware system include: 1. Configure the communication service interface on the MCU side and import it into its application SWC. The service interface contains the mapping relationship between CAN signals and data structures. After the configuration is completed, generate the Arxml code for S2S communication configuration. 2. The SOC side is configured with a communication service interface, which includes a Topic communication data structure. In addition, the communication system has pre-defined messages, which define commonly used vehicle data structures. 3. Configure the mapping relationship and define the receiver and sender of the Topic. If the sender or receiver is an MCU, use data structures for communication. If the sender or receiver is an SOC or cloud, use serialized data types and preset message data for communication. 4. After completing the mapping configuration, generate the configuration file, and then develop AutoSAR applications based on it.

[0096] Figure 5 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 5 As shown, the electronic device may include a processor 510, a communications interface 520, a memory 530, and a communication bus 540, wherein the processor 510, communications interface 520, and memory 530 communicate with each other via the communication bus 540. The processor 510 can call logical instructions in the memory 530 to execute a communication configuration and deployment method. This method includes: acquiring and parsing an AUTOSAR-based communication service interface definition file from the microcontroller unit (MCU) side and a service interface definition file containing Topic communication data structures from the system-on-a-chip (SoC) side; establishing a mapping relationship between the Topic sender and receiver based on the parsed interface information, and determining and adapting the communication method to use an AUTOSAR-based data structure or a serialized data type and preset message data, depending on the type of the sender and receiver; generating a unified configuration file for the middleware system based on the established mapping relationship and adaptation results; and deploying and running an application based on the unified configuration file, enabling the application to communicate by calling the unified communication interface of the middleware system.

[0097] Furthermore, the logical instructions in the aforementioned memory 530 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0098] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the communication configuration and deployment methods provided by the above methods. The method includes: acquiring and parsing an AUTOSAR-based communication service interface definition file from the microcontroller unit (MCU) side and a service interface definition file containing a Topic communication data structure from the system-on-chip (SoC) side; establishing a mapping relationship between the Topic sender and receiver based on the parsed interface information, and determining and adapting the use of an AUTOSAR-based data structure for communication, or communication based on a serialized data type and preset Message data, according to the types of the sender and receiver; generating a unified configuration file for the middleware system based on the established mapping relationship and adaptation results; and deploying and running an application based on the unified configuration file, so that the application communicates by calling the unified communication interface of the middleware system.

[0099] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the communication configuration and deployment methods provided by the above methods. The method includes: acquiring and parsing an AUTOSAR-based communication service interface definition file from the microcontroller unit (MCU) side and a service interface definition file containing a Topic communication data structure from the system-on-a-chip (SoC) side; establishing a mapping relationship between the Topic sender and receiver based on the parsed interface information, and determining and adapting the use of an AUTOSAR-based data structure for communication, or communication based on a serialized data type and preset Message data, according to the types of the sender and receiver; generating a unified configuration file for the middleware system based on the established mapping relationship and adaptation results; and deploying and running an application based on the unified configuration file, so that the application communicates by calling the unified communication interface of the middleware system.

[0100] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

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

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

Claims

1. A vehicle-cloud integrated communication middleware system based on SOA architecture, characterized in that, The system includes: The unified communication interface module is used to provide the application layer with a topic-based publish / subscribe model communication interface, as well as a method-based client / server model remote service call interface; The communication abstraction and adaptation module is used to perform unified abstraction and protocol conversion of various heterogeneous physical buses and communication protocols within the vehicle and between the vehicle and the cloud. The system configuration and management module is used to centrally configure and manage the definition of the communication interface, the mapping relationship of the communication channel, and the system operating parameters; The system receives communication requests from the application layer through the unified communication interface module, obtains configuration information through the system configuration and management module, and adapts the communication requests to a specific physical bus or network protocol for transmission through the communication abstraction and adaptation module, thereby decoupling the application layer business logic from the underlying communication implementation details.

2. The system according to claim 1, characterized in that, The unified communication interface module includes: The Topic library component is used to define data transmission links and provide a communication interface based on the publish / subscribe model for the application layer. The interface identifies communication endpoints with a Topic and carries business data with standardized Message data entities. The Method library component is used to provide the application layer with a remote service call interface based on a client / server model. The interface identifies the remotely called service using a Method and encapsulates the request and response using the Message data entity.

3. The system according to claim 2, characterized in that, The Message data entity comprises two parts: a Header and a Payload. The Header contains identifying information representing the characteristics of the physical communication link, while the Payload is a data structure carrying service information. The Payload structure uses different encapsulation rules depending on the type of the communicating parties. When both communicating parties are microcontroller units (MCUs), the signals are encapsulated into a structure generated by the AUTOSAR XML description file according to the AUTOSAR software component interface definition. When both communicating parties are on-chip system-on-a-chip (SoC) or one of them is in the cloud, they are encapsulated into a variable field structure according to the Protocol Buffer method. When one party to the communication is an MCU and the other party is an SOC, the data types defined by the Service-Oriented Architecture (SOA) service interface are encapsulated into a structure that conforms to the SOMEIP protocol standard.

4. The system according to claim 2, characterized in that, The Message data entity predefines a data structure covering various domains of the vehicle, including the cloud, body domain, intelligent driving domain, cockpit domain, power domain, chassis domain, vehicle basic information, and diagnostic information.

5. The system according to claim 1, characterized in that, The system also includes: A QoS policy management component is used to implement end-to-end quality of service guarantee policies for communications initiated through the Topic library component and the Method library component. The quality of service (QoS) assurance strategy includes at least one of the following: redundancy QoS strategy, time-limited QoS strategy, best-effort QoS strategy, reliable QoS strategy, and end-to-end QoS strategy.

6. The system according to claim 1, characterized in that, The system also includes: A serialization / deserialization component is used to automatically identify and perform serialization and deserialization operations on communication data according to the configuration of the system configuration and management module; The serialization / deserialization component supports the following serialization methods: ProtocolBuffer serialization for cross-operating system communication, binary memory copy serialization for high-performance communication within the same operating system, and AUTOSAR serialization to meet the AUTOSAR specification.

7. The system according to claim 1, characterized in that, The communication abstraction and adaptation module supports communication methods including physical bus and communication protocols. The physical bus includes automotive Ethernet, fiber optic, Controller Area Network (CAN), PCIe (PCIe), Serial Peripheral Interface (SPI), and Inter-core Communication Framework (IPCF). The communication protocols include Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Service-Oriented Internet Protocol (SOMEIP), Data Distribution Service (DDS), Message Queuing Telemetry Transport (MQTT), and Hypertext Transfer Protocol Secure (HTTPS).

8. The system according to claim 1, characterized in that, The system also includes: The scheduling center component is used to dynamically orchestrate and schedule communication tasks in the system according to a variety of predefined scheduling strategies; The scheduling strategy includes at least one of the following: high-concurrency scheduling strategy, persistent scheduling strategy, pipelined scheduling strategy, and periodic scheduling strategy.

9. The system according to claim 1, characterized in that, The configuration items of the system configuration and management module include Topic name, Method name, communication channel configuration, and serialization method configuration for each Topic or Method. The communication channel configuration includes the channel identifier, communication method, and corresponding parameters.

10. A communication configuration and deployment method based on the system according to any one of claims 1 to 9, characterized in that, The method includes: The system acquires and parses the AUTOSAR-based communication service interface definition file from the microcontroller unit (MCU) side, and the service interface definition file containing Topic communication data structure from the system-on-chip (SoC) side. Based on the parsed interface information, a mapping relationship is established between the Topic sender and receiver. Depending on the type of the sender and receiver, the AUTOSAR-based data structure is determined and adapted for communication, or communication is based on serialized data types and pre-set message data. Based on the established mapping relationship and adaptation results, a unified configuration file for the middleware system is generated; Based on the unified configuration file, the application is deployed and run, enabling the application to communicate by calling the unified communication interface of the middleware system.

Images