Vehicle communication method and system, vehicle and computer-readable storage medium

Abstract

Disclosed in the present application are a vehicle communication method and system, a vehicle and a computer-readable storage medium. The vehicle communication method comprises: creating a unified service layer interface, the service layer interface being used for communications within each domain controller in a service domain, communications between a plurality of domain controllers in the service domain, and communications between each domain controller in the service domain and a signal domain; by means of the service layer interface, receiving a service request sent by an initiation application in a request domain controller; if the service request is an intra-service-domain request, creating intra-domain communications between the initiation application and a first receiving application in the request domain controller; if the service request is an inter-service-domain request, creating inter-domain communications between the initiation application and a second receiving application in a receiving domain controller corresponding to the request domain controller; and, if the service request is a cross-domain request, creating cross-domain communications between the initiation application and the signal domain. The present application improves communication efficiency and stability.

Description

Vehicle communication method, system, vehicle and computer-readable storage medium

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to the Chinese patent application filed with the China Patent Office on March 14, 2024, with application number 202410290676.2 and invention name “A vehicle communication method, system, vehicle and computer-readable storage medium”, the entire contents of which are incorporated by reference into this application. Technical Field

[0003] The present application relates to the field of vehicle communication technology, and in particular to a vehicle communication method, system, vehicle, and computer-readable storage medium. Background Art

[0004] A vehicle is a communication network composed of multiple controllers. Each controller is physically connected to other controllers (sensors, power / ground, actuators, etc.) via wiring harnesses and communication protocols to perform specific logical functions, as shown in Figure 1. The increasing number of controllers, increasingly complex communication methods, increasing communication content, and rising communication costs have driven the evolution of electronic and electrical architectures (EEA). As shown in Figure 2, a proposed E / E architecture based on high-speed and low-speed networks is currently being proposed. The basic concept is to use a basic vehicle interface unit (a controller) to logically divide the vehicle's controllers into high-speed and low-speed communication areas. The low-speed communication area uses the widely established CAN / CANFD (Controller Area Network / CAN with Flexible Data-Rate) bus for communication, known as the signal domain. The high-speed communication area uses high-speed buses, such as Ethernet (a relatively mature communication technology in the communications industry), and uses SOA (a software design and service-oriented architecture) services in the high-speed communication area, known as the service domain. Based on this, controllers exchange data via CAN / CANFD within the signal domain, known as communication. The following issues need to be addressed:

[0005] (1) How do applications (referring to independent application entities existing in each domain controller; often there are multiple applications in one domain controller) exchange data, that is, communication, within the service domain? Specifically, it is divided into 1) how do applications exchange data, that is, communication, within the domain controller; 2) how do applications exchange data, that is, communication, between domain controllers; (2) how do applications exchange data, that is, communication, between the service domain and the signal domain; (3) how to complete the conversion of signals and services within the signal domain to support SOA service calls.

[0006] In the existing design scheme, there are more and more domain controllers and interface units, and the communication data is increasing. Due to differences in communication interfaces and communication protocols, and large deployment resource consumption, communication is restricted and the interaction cost is high.

[0007] Therefore, the existing technology still needs to be improved and developed. Summary of the Invention

[0008] The main purpose of this application is to provide a vehicle communication method, system, vehicle and computer-readable storage medium, aiming to solve the problem of limited communication in the prior art due to differences in communication interfaces, communication protocols and high deployment resource consumption.

[0009] The first aspect of the present application provides a vehicle communication method, comprising the following steps: creating a unified service layer interface, wherein the service layer interface is used for communication within each domain controller within a service domain, communication between multiple domain controllers within a service domain, and communication between each domain controller within a service domain and a signal domain; receiving a service request issued by an initiating application within the requesting domain controller through the service layer interface, wherein the requesting domain controller is a domain controller within the service domain; if the service request is an intra-service domain request, creating intra-domain communication between the initiating application and a first receiving application within the requesting domain controller; if the service request is an inter-service domain request, creating inter-domain communication between the initiating application and a second receiving application within the receiving domain controller corresponding to the requesting domain controller; if the service request is a cross-domain request, creating cross-domain communication between the initiating application and the signal domain.

[0010] According to the above-mentioned technical means, the embodiment of the present application uses a unified service layer interface, processes various service requests based on the service layer interface, and creates intra-domain communication, inter-domain communication or cross-domain communication accordingly, which can effectively manage and control the communication process within the vehicle, shield the differences in communication interfaces and communication protocols, reduce deployment resource consumption, thereby improving communication efficiency and stability, and reducing communication costs.

[0011] Optionally, in one embodiment of the present application, if the service request is an intra-service domain request, intra-domain communication is created between the initiating application and the first receiving application in the requesting domain controller, specifically including: if the service request is initiated by the initiating application in the requesting domain controller to the first receiving application in the requesting domain controller, then the service request is judged to be an intra-service domain request; establishing a first communication between the communication layer of the initiating application and the communication layer of the first receiving application, and based on the first communication, controlling the first receiving application to perform a service response to the service request issued by the initiating application.

[0012] According to the above-mentioned technical means, the embodiment of the present application supports SOA communication of multiple communication protocols through a unified service layer interface (first interface, second interface, third interface), shields the differences in communication interfaces, shields the differences in communication protocols, reduces deployment resource consumption, isolates communications within and outside the domain, and enhances security.

[0013] Optionally, in one embodiment of the present application, controlling the first receiving application to perform a service response to the service request issued by the initiating application specifically includes: identifying the first data corresponding to the service request; controlling the initiating application to subscribe to changes in the first data from the first receiving application through the first interface; when the first data changes, controlling the first receiving application to notify the initiating application through the first interface, and controlling the initiating application to request the latest first data from the first receiving application through the second interface; controlling the first receiving application to send the latest first data back to the initiating application.

[0014] According to the above technical means, the embodiment of the present application defines a unified service layer interface, so that APP1 and APP2 can communicate without knowing each other's internal implementation. This abstraction makes the interaction between services more standardized and reduces the complexity of system integration; the unified service layer interface supports multiple communication protocols, so no matter what protocol is used at the bottom layer, it is transparent to the application layer, making it easier for the system to adapt to different communication technologies and improving the flexibility and scalability of the system; because the unified interface shields the differences in communication protocols, it can reduce dependence on specific protocols during development and deployment, thereby reducing the demand for hardware and software resources; through the service layer interface, the communication within the domain controller and the external communication can be better controlled and managed, and this isolation Distancing can enhance the security of the system and prevent potential security threats; unified interface and protocol shielding can reduce the possibility of security vulnerabilities because they provide an additional layer of abstraction, making it more difficult for malicious attacks to directly target the underlying protocol; improving development efficiency, developers can use a unified API set for programming without having to worry about the underlying communication details, which simplifies the development process and allows for rapid iteration and deployment of new services; facilitating maintenance and upgrades, when the underlying communication protocol needs to be updated or replaced, since the upper-layer application does not directly depend on a specific protocol, maintenance and upgrade operations can be performed more easily without affecting the operation of the entire system; improving user experience, through efficient service calls and data communication, it can ensure that the vehicle system responds quickly and stably, thereby providing a better user experience.

[0015] Optionally, in one embodiment of the present application, controlling the first receiving application to send the latest first data back to the initiating application further includes: controlling the initiating application to publish the latest first data through the third interface.

[0016] Based on the above technical means, in this embodiment of the application, an initiating application subscribes to changes in vehicle status information from a first receiving application via a first interface call. When the vehicle status changes, the first receiving application notifies the initiating application via the first interface call. The initiating application requests the latest vehicle status information from the first receiving application via a second interface call. The first receiving application returns the latest vehicle status information to the initiating application, which then publishes the latest vehicle status information via a third interface call. This ensures data security and reliability.

[0017] Optionally, in one embodiment of the present application, if the service request is an inter-domain service request, then an inter-domain communication is created between the initiating application and the second receiving application in the receiving domain controller, specifically including: if the service request is initiated by the initiating application in the requesting domain controller to the second receiving application in the receiving domain controller, then the service request is judged to be an inter-domain service request; a second communication is established between the initiating application and the first gateway in the requesting domain controller, a third communication is established between the first gateway in the requesting domain controller and the second gateway in the receiving domain controller, and a fourth communication is established between the second gateway and the second receiving application; based on the second communication, the third communication and the fourth communication, the second receiving application is controlled to perform a service response to the service request issued by the initiating application.

[0018] According to the above technical means, the embodiment of the present application uses a unified service layer interface (first interface, second interface, third interface) to complete the conversion of internal and external communication protocols by the gateway. In logical communication, the service layer interface is kept consistent, and the gateway is used to isolate internal and external domain communications on the physical link, shielding the differences in communication interfaces and communication protocols, reducing deployment resource consumption, isolating internal and external domain communications, and enhancing security.

[0019] Optionally, in one embodiment of the present application, controlling the second receiving application to provide a service response to the service request issued by the initiating application specifically includes: identifying the second data corresponding to the service request; controlling the initiating application to subscribe to changes in the second data to the second receiving application through the first interface; and when the second data changes, controlling the second receiving application to process the second data.

[0020] According to the above technical means, the embodiment of the present application enables APP1 and APP3 located in different domain controllers to communicate seamlessly through the first gateway and the second gateway, thereby enhancing the overall collaborative working ability of the system; the gateway is responsible for handling the communication protocol differences that may exist between different domain controllers. It can convert requests from the first interface, the second interface, the third interface, etc. from one protocol to another, logically maintaining the consistency of the service layer interface and simplifying the development work of the application layer; the use of a unified service layer interface and gateway reduces the dependence on specific hardware, thereby reducing deployment costs. The same service can run under different hardware and network conditions without major modifications; the gateway acts as a firewall, which can prevent unauthorized access, protect internal services from external threats, and improve the security of the entire vehicle communication network; using the gateway for communication isolation can effectively prevent potential security risks from spreading to other service domains. Even if a service domain is attacked, it will not affect the stability of the entire system; as the vehicle system functions increase, more services and applications may need to be added. By using the gateway to manage communication, the integration of new services becomes simpler, and the maintenance and upgrade of the system are also easier; the gateway can perform data preprocessing, such as data compression and filtering, to reduce network bandwidth usage, thereby improving the performance of the entire vehicle communication system.

[0021] Optionally, in one embodiment of the present application, when the second data changes, controlling the second receiving application to process the second data further includes: controlling the initiating application to request the second receiving application for updated second data through the second interface.

[0022] According to the above technical means, when an initiating application needs to send status information to a second receiving application, the embodiment of the present application first sends a request to the first gateway, which then forwards the request to the second gateway, which finally passes the request to the second receiving application. The second receiving application processes the received information and returns the result to the initiating application or other subscribers in the form of the first interface, the second interface, and the third interface. This allows for efficient information transmission and processing.

[0023] Optionally, in one embodiment of the present application, if the service request is a cross-domain request, cross-domain communication is created between the initiating application and the signal domain, specifically including: if the service request is initiated by the initiating application in the requesting domain controller to the signal domain, then the service request is judged to be a cross-domain request; a second communication is established between the initiating application and the first gateway in the requesting domain controller, a fifth communication is established between the first gateway in the requesting domain controller and the proxy service in the service domain, a sixth communication between the proxy service and the signal domain, and an internal communication between the proxy service and the service gateway in the service domain; based on the sixth communication, the signal of the signal domain is converted into a target service for a service call interface; based on the second communication, the fifth communication and the internal communication, the service gateway is controlled to provide a service response to the service request issued by the initiating application to the target service.

[0024] According to the above-mentioned technical means, the embodiment of the present application completes the SOA service call through the proxy service gateway of the signal domain through a unified service layer interface (first interface, second interface, third interface). In logical communication, the service layer interface is kept consistent. In the physical link, the gateway is used to isolate the communication within and outside the domain, and the complexity of the signal domain is abstracted and simplified through the gateway; the differences in communication interfaces and communication protocols are shielded, the deployment resource consumption is reduced, the communication within and outside the domain is isolated, and the security is enhanced.

[0025] Optionally, in one embodiment of the present application, the conversion of the signal in the signal domain into a target service for a service call interface specifically includes: using a communication module to synchronize the signal in the signal domain with itself; establishing a signal list corresponding to the signal after self-synchronization in the proxy service, and establishing a mapping relationship between the signal list and the object group; based on the mapping relationship, providing a service call interface to the outside through the interface function of the object group, and establishing a function call relationship between the service gateway and the service call interface to provide the target service to the outside.

[0026] According to the above technical means, the embodiment of the present application enables different services and applications to communicate in a standardized manner through a unified interface definition; communicating through a unified service interface reduces the coupling between system components, and each service only needs to care about how to interact with the service interface without having to understand the implementation details of other services; the unified service interface promotes the reusability of services, and services with the same interface can be reused by different applications in different places, improving development efficiency; in the system integration stage, the unified interface reduces the complexity of integration because all services follow the same communication rules, simplifying the testing and verification process; when a service needs to be updated or replaced, due to the use of a unified interface, such The changes have little impact on other parts of the system, making system maintenance simpler and faster; as system requirements grow, new services can be easily added to the bus without making extensive modifications to the existing system; communication isolation through the gateway can prevent the spread of security issues, and even if a service is attacked, it will not affect the stability of the entire system; the use of unified interfaces and gateways can reduce the redundant use of hardware resources, thereby reducing the cost of the entire system; the proxy service gateway can handle multiple communication protocols and provide a unified service call method for upper-level applications, so that application developers do not need to worry about the specific communication details of the underlying layer; the gateway can implement additional security measures such as authentication, authorization and encryption to ensure the secure transmission of data.

[0027] The second aspect of the present application provides a vehicle communication system, which includes: an interface creation module for creating a unified service layer interface, wherein the service layer interface is used for communication within each domain controller in the service domain, communication between multiple domain controllers in the service domain, and communication between each domain controller in the service domain and the signal domain; a request receiving module for receiving a service request issued by an initiating application in the requesting domain controller through the service layer interface, wherein the requesting domain controller is a domain controller in the service domain; an intra-domain communication module for creating intra-domain communication between the initiating application and a first receiving application in the requesting domain controller if the service request is an intra-service domain request; an inter-domain communication module for creating inter-domain communication between the initiating application and a second receiving application in the receiving domain controller corresponding to the requesting domain controller if the service request is an inter-service domain request; and a cross-domain communication module for creating cross-domain communication between the initiating application and the signal domain if the service request is a cross-domain request.

[0028] Optionally, in one embodiment of the present application, the intra-domain communication module includes: an intra-domain request judgment unit, used to judge that the service request is an intra-domain service request if the service request is initiated by the initiating application in the requesting domain controller to the first receiving application in the requesting domain controller; an intra-domain service response unit, used to establish a first communication between the communication layer of the initiating application and the communication layer of the first receiving application, and based on the first communication, control the first receiving application to perform a service response to the service request issued by the initiating application.

[0029] Optionally, in one embodiment of the present application, the intra-domain service response unit includes: an intra-domain data identification sub-unit, used to identify the first data corresponding to the service request; an intra-domain notification sub-unit, used to control the initiating application to subscribe to changes in the first data to the first receiving application through the first interface; an intra-domain update request sub-unit, used to control the first receiving application to notify the initiating application through the first interface when the first data changes, and control the initiating application to request the latest first data from the first receiving application through the second interface; an intra-domain update data return sub-unit, used to control the first receiving application to send the latest first data back to the initiating application.

[0030] Optionally, in one embodiment of the present application, the inter-domain communication module includes: an inter-domain request judgment unit, used to judge that the service request is an inter-domain service request if the service request is initiated by the initiating application in the requesting domain controller to the second receiving application in the receiving domain controller corresponding to the requesting domain controller; an inter-domain communication establishment unit, used to establish a second communication between the initiating application and the first gateway in the requesting domain controller, a third communication between the first gateway in the requesting domain controller and the second gateway in the receiving domain controller, and a fourth communication between the second gateway and the second receiving application; an inter-domain service response unit, used to control the second receiving application to perform a service response to the service request issued by the initiating application based on the second communication, the third communication and the fourth communication.

[0031] Optionally, in one embodiment of the present application, the inter-domain service response unit includes: an inter-domain data identification sub-unit, used to identify the second data corresponding to the service request; an inter-domain notification sub-unit, used to control the initiating application to subscribe to changes in the second data to the second receiving application through the first interface; and an inter-domain data processing sub-unit, used to control the second receiving application to process the second data when the second data changes.

[0032] Optionally, in one embodiment of the present application, the cross-domain communication module includes: a cross-domain request judgment unit, used to judge that the service request is a cross-domain request if the service request is initiated by the initiating application in the requesting domain controller to the signal domain; a cross-domain communication establishment unit, used to establish a second communication between the initiating application and the first gateway in the requesting domain controller, a fifth communication between the first gateway in the requesting domain controller and the proxy service in the service domain, a sixth communication between the proxy service and the signal domain, and an internal communication between the proxy service and the service gateway in the service domain; a signal service conversion unit, used to convert the signal of the signal domain into a target service for a service call interface based on the sixth communication; an inter-domain service response unit, used to control the service gateway to perform a service response to the service request issued by the initiating application to the target service based on the second communication, the fifth communication and the internal communication.

[0033] Optionally, in one embodiment of the present application, the inter-domain service response unit includes: a signal synchronization sub-unit, which uses a communication module to synchronize the signal within the signal domain; a mapping establishment sub-unit, which is used to establish a signal list corresponding to the signal after self-synchronization in the proxy service, and establish a mapping relationship between the signal list and the object group; a service call providing sub-unit, which is used to provide a service call interface to the outside through the interface function of the object group based on the mapping relationship, and establish a function call relationship between the service gateway and the service call interface to provide the target service to the outside.

[0034] Optionally, in one embodiment of the present application, the vehicle communication system further includes: an intra-domain data publishing sub-unit, used to control the initiating application to publish the latest first data through the third interface; and an inter-domain data publishing sub-unit, used to control the initiating application to request the updated second data from the second receiving application through the second interface.

[0035] A third aspect of the present application provides a vehicle, comprising: a memory, a processor, and a vehicle communication program stored in the memory and executable on the processor, wherein the vehicle communication program, when executed by the processor, implements the steps of the vehicle communication method as described in the above embodiment.

[0036] A fourth aspect of the present application provides a computer-readable storage medium, which stores a vehicle communication program. When the vehicle communication program is executed by a processor, the steps of the vehicle communication method described in the above embodiment are implemented.

[0037] Beneficial effects of this application:

[0038] (1) The embodiments of the present application use a unified service layer interface, process various service requests based on the service layer interface, and create intra-domain communication, inter-domain communication, or cross-domain communication accordingly. This can effectively manage and control the communication process within the vehicle, shield the differences in communication interfaces and communication protocols, reduce deployment resource consumption, thereby improving communication efficiency and stability and reducing communication costs.

[0039] (2) The embodiment of the present application supports SOA communications of multiple communication protocols through a unified service layer interface, shields the differences in communication interfaces, shields the differences in communication protocols, reduces deployment resource consumption, isolates communications within and outside the domain, and enhances security.

[0040] (3) In the embodiment of the application, the gateway completes the conversion of internal and external communication protocols through a unified service layer interface. In terms of logical communication, the service layer interface is kept consistent. In terms of physical links, the gateway is used to isolate internal and external domain communications, shield the differences in communication interfaces, shield the differences in communication protocols, reduce deployment resource consumption, isolate internal and external domain communications, and enhance security.

[0041] (4) In the embodiment of the present application, the proxy service gateway of the signal domain completes the SOA service call through a unified service layer interface. In terms of logical communication, the service layer interface is kept consistent. In terms of physical links, the gateway is used to isolate the communication inside and outside the domain, and the complexity of the signal domain is abstracted and simplified through the gateway; the differences in communication interfaces and communication protocols are shielded, the deployment resource consumption is reduced, the communication inside and outside the domain is isolated, and the security is enhanced.

[0042] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0044] FIG1 is a connection diagram of a typical controller on a vehicle in the prior art;

[0045] FIG2 is a typical electronic and electrical architecture diagram of a vehicle in the prior art;

[0046] FIG3 is a schematic structural diagram of a preferred embodiment of the vehicle of the present application;

[0047] FIG4 is a service call logic diagram of each application APP in the service domain in an embodiment of the present application;

[0048] FIG5 is a service call deployment diagram of each application APP in the service domain in an embodiment of the present application;

[0049] FIG6 is a service call flow diagram of an application APP in a service domain according to an embodiment of the present application;

[0050] FIG7 is a service call flow diagram of the service domain application APP in an embodiment of the present application

[0051] FIG8 is a call deployment diagram between the service domain APP and the service APP provided by the signal domain in an embodiment of the present application;

[0052] FIG9 is a logic diagram of calling between the service domain APP and the service APP provided by the signal domain in an embodiment of the present application;

[0053] FIG10 is a call flow diagram between the service domain APP and the service APP provided by the signal domain in an embodiment of the present application

[0054] FIG11 is a diagram illustrating signal and service conversion in an embodiment of the present application;

[0055] FIG12 is a schematic structural diagram of a preferred embodiment of the vehicle communication system of the present application;

[0056] FIG13 is a schematic structural diagram of a preferred embodiment of the vehicle of the present application.

[0057] Among them, 10-vehicle communication system; 100-interface creation module; 200-request receiving module, 300-intra-domain communication module, 400-inter-domain communication module; 500-cross-domain communication module; 501-memory, 502-processor and 503-communication interface. DETAILED DESCRIPTION

[0058] The following describes in detail embodiments of the present application, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0059] In the existing overall architecture, automotive electrical and electronic systems are composed of multiple ECUs (electronic control units), which implement various functions through data exchange. However, as the functions of automotive electronic components increase, each controller needs to process more and more information and communicate with other controllers, which leads to an increase in the amount of communication data and higher interaction costs. To solve this problem, a new solution has been proposed: the DCU (Domain Control Unit). The core development of the domain controller is the rapid increase in chip computing power. It uses multi-core CPU / GPU chips to relatively centrally control each domain, replacing the current distributed electrical and electronic architecture.

[0060] Based on the electronic and electrical architecture of high-speed and low-speed networks, the communication architecture is divided into the signal domain and the service domain; the service domain is divided into the domain inside and outside the service domain; and the mutual conversion between signals and services. The reasons for setting this communication architecture are divided into three aspects:

[0061] If the communication architecture is entirely in the signal domain, that is, the communication architecture of the current vehicle. When an application is developed, the signals it requires: (1) have different signal interfaces, some are CAN / CANFD interfaces, some are Ethernet interfaces, and some are LIN interfaces, and their signals are bound to specific physical interfaces; (2) their signal protocols are different, often custom protocol packages, and signal parsing needs to be performed according to specific protocols;

[0062] If the communication architecture is entirely service domain, there will be two problems: (1) Some embedded controllers cannot deploy service protocols due to resource limitations, such as small MCU main chips; (2) Some embedded controllers (such as SOC chips) can deploy service protocols, but if they do not distinguish between in-domain and out-of-domain service protocols and are not isolated by a gateway (GW), then all applications will need to deploy a complete protocol stack, which will consume a lot of duplicate resources. In addition, due to the lack of isolation, the communication security is relatively low.

[0063] Utilizing existing mature technologies in the signal domain can reduce the cost increase due to the use of new technologies.

[0064] Under this communication architecture, the problems to be solved corresponding to the above contents are: (1) through a unified service layer interface (NTF, PRC, PUB / SUB), SOA communication of multiple communication protocols is supported, shielding the differences in communication interfaces; (2) through a unified service layer interface (NTF, PRC, PUB / SUB), the gateway completes the conversion of internal and external communication protocols, keeps the service layer interface consistent in logical communication, and isolates the communication between the internal and external domains through the gateway on the physical link; (3) through a unified service layer interface (NTF, PRC, PUB / SUB), the proxy service gateway of the signal domain completes the SOA service call, keeps the service layer interface consistent in logical communication, and isolates the communication between the internal and external domains through the gateway on the physical link, and abstracts and simplifies the complexity of the signal domain through the gateway.

[0065] The following describes the vehicle communication method, system, vehicle and computer-readable storage medium of the embodiments of the present application with reference to the accompanying drawings. In response to the problem of limited communication due to differences in communication interfaces, communication protocols and high deployment resource consumption in the related technologies mentioned in the above background technology, the present application provides a vehicle communication method, in which, by using a unified service layer interface and processing various service requests based on the service layer interface, and creating intra-domain communication, inter-domain communication or cross-domain communication accordingly, the communication process inside the vehicle can be effectively managed and controlled, the differences in communication interfaces and communication protocols are shielded, the deployment resource consumption is reduced, thereby improving communication efficiency and stability, and reducing communication costs. As a result, the technical problem of limited communication due to differences in communication interfaces, communication protocols and high deployment resource consumption in the related technologies is solved.

[0066] In an embodiment of the present application, a unified service layer interface is established between the requesting domain controller, the receiving domain controller and the signal domain within the service domain. Through this interface, it is possible to receive and process service requests issued by the initiating application within the requesting domain controller. Based on the content of the service request, it is determined whether it is an intra-service domain request, an inter-service domain request or a cross-domain request, and intra-domain communication, inter-domain communication or cross-domain communication is created accordingly.

[0067] At the same time, some terms that may be involved in the embodiments of this application are explained as follows:

[0068] The signal domain typically refers to an area that communicates using the CAN / CANFD bus, primarily responsible for transmitting highly real-time signals such as engine speed and vehicle speed. The service domain, on the other hand, uses SOA services within the high-speed communication area. This improves the system's flexibility and scalability by designing different functional units as independently deployable services and communicating using standardized interfaces. Specifically, service-oriented computing makes the capabilities of each domain available to others, allowing them to freely use these services as long as permissions allow. This speeds up software updates or upgrades, as only one service needs to be updated or upgraded. Furthermore, since services communicate through interfaces, the system's flexibility and scalability can be improved.

[0069] CAN (Controller Area Network) is a communications protocol used in automotive and other applications. It allows information to be exchanged between different vehicle components without the need for complex wiring. CAN FD (CAN with Flexible Data-Rate) is an enhanced version of CAN that offers higher data rates and longer data frame lengths.

[0070] Service-Oriented Architecture (SOA) is a software design and architecture pattern that combines the different functional units (services) of an application through well-defined interfaces and protocols to enable reuse and interaction of business functions. These services are independent, reusable, and can be used across multiple systems and organizations. In SOA, services are defined as units with clear callable interfaces that can be called over the network.

[0071] Specific to SOA service interfaces, they have different types, including:

[0072] NTF (Notifier): This is a notification interface used by service providers to send notifications to service consumers. When a specific event occurs, the service provider will send a notification to the service consumer through the NTF interface.

[0073] PRC (Proxy): The PRC interface is a proxy interface that allows a service consumer to call a service on behalf of a service user. This type of interface is often used when data conversion or caching is required between the client and the server.

[0074] PUB / SUB (Publish / Subscribe): The PUB / SUB interface is a publish / subscribe interface that allows service providers to publish messages to specific topics, and service consumers to subscribe to these topics to receive related messages. This type of interface is often used to implement event-driven communication patterns.

[0075] In general, SOA defines different types of service interfaces, allowing different services to interact and integrate in a unified, flexible, and scalable manner, thereby improving the flexibility, scalability, and maintainability of the software system.

[0076] GW_1 and GW_2 stand for gateway, which is the abbreviation of Gateway. A gateway is a device that implements network interconnection above the network layer. It is the most complex network interconnection device and is only used to interconnect two networks with different high-level protocols.

[0077] SOA_Proxy_ON_SOC is an abbreviation that stands for "Service Oriented Architecture (SOA) Proxy on System on Chip (SoC)." In the computer field, SOA (Service-Oriented Architecture) is a software architectural style that combines different functional units of an application (called services) through well-defined interfaces and protocols to enable reuse and interaction of business functions. These services can be independently deployed, reused, and integrated. System on Chip (SoC) refers to a system-on-chip (SoC) that integrates multiple electronic components onto a single chip. An SoC typically includes a processor, memory, input / output interfaces, and other peripherals. Therefore, SOA_Proxy_ON_SOC represents a service-oriented proxy implemented on a system-on-chip. This proxy acts as an intermediary between different services, enabling them to communicate and interact with each other. Implementing an SOA proxy on an SoC can improve system performance, efficiency, and integration while reducing system complexity and power consumption.

[0078] Services X, Y, and Z represent services provided by the SOA_Proxy_ON_SOC deployed on the domain controller. These services may be designed to meet specific business needs or accomplish specific tasks. For example, X may represent a user management service, handling all user-related operations such as registration, login, and permission control. Y and Z may represent other services, such as data storage services and report generation services, depending on the actual business needs and system design. These services interact through unified SOA service interfaces (NTF, PRC, PUB / SUB) to achieve service reuse and efficient operation.

[0079] At the same time, in order to facilitate understanding of the present application, the embodiments of the present application are briefly described here:

[0080] In this embodiment, intra-domain communication within a service domain, i.e., communication between apps within a controller domain within a service domain, supports SOA communication across multiple communication protocols through a unified service layer interface (NTF, PRC, PUB / SUB), shielding differences in communication interfaces. This shields differences in communication interfaces and protocols, reduces deployment resource consumption, isolates intra-domain and extra-domain communications, and enhances security.

[0081] In this embodiment of the application, inter-domain communication in a service domain, that is, communication between APPs in the controller domain within a service domain, is achieved by using a unified service layer interface (NTF, PRC, PUB / SUB). The gateway completes the conversion of internal and external communication protocols. In terms of logical communication, the service layer interface remains consistent, and the gateway isolates internal and external communication on the physical link. This shields differences in communication interfaces and protocols, reduces deployment resource consumption, isolates internal and external communication, and enhances security.

[0082] In the embodiment of the present application, the communication between the service domain and the signal domain, that is, the communication between the APPs on each domain controller in the service domain and the service APPs on the signal domain, is as follows: through a unified service layer interface (NTF, PRC, PUB / SUB), the proxy service gateway of the signal domain completes the SOA service call, keeps the service layer interface consistent in logical communication, isolates the communication inside and outside the domain in physical links through the gateway, and abstracts and simplifies the complexity of the signal domain through the gateway. This shields the differences in communication interfaces and communication protocols, reduces deployment resource consumption, isolates the communication inside and outside the domain, and enhances security.

[0083] The signal-to-service communication on the signal domain of the embodiment of the present application completes the SOA service call through the proxy service gateway deployed on the domain controller. The abstract object definition is performed through the proxy service gateway, and the objects are mapped to signals and their operations, and the service is provided through the service interface (NTF, PRC, PUB / SUB).

[0084] Any application within a service domain that includes multiple domain controllers (e.g., two, three, or four) can initiate communication simultaneously. The following example illustrates the communication process involving a requesting domain controller, a receiving domain controller, and a signaling domain:

[0085] Specifically, FIG3 is a flow chart of a vehicle communication method provided in an embodiment of the present application.

[0086] As shown in FIG3 , the vehicle communication method includes the following steps:

[0087] In step S101, a unified service layer interface is created, wherein the service layer interface is used for communication within each domain controller in the service domain, communication between multiple domain controllers in the service domain, and communication between each domain controller in the service domain and the signal domain.

[0088] Specifically, multiple domain controllers within a service domain communicate with the signal line through a unified service layer interface. Communication between multiple applications within each domain controller through the service layer interface is intra-domain communication. Communication between applications within multiple different domain controllers through the service layer interface is inter-domain communication. Communication between applications within each domain controller within the service domain and the signal domain through the service layer interface is cross-domain communication.

[0089] In step S102, a service request sent by an initiating application in the requesting domain controller is received through the service layer interface.

[0090] In one possible implementation, the requesting domain controller is a domain controller within the service domain, and a unified service layer interface is established between the requesting domain controller, the receiving domain controller, and the signaling domain within the service domain. This operation is performed by the server. In a computer network, a domain controller is an important hardware device that is responsible for managing various user permissions on the network, including logging on to the network, account authentication, and access to directories and shared resources. The first domain controller is the primary domain controller by default, running the AD DS domain service. This service is the same as a normal service application and can be managed through the "Services" console. At the same time, the relationship between the first domain controller and the second domain controller (also known as the additional domain controller) is that they serve as backups for each other. They manage the same domain and the data in the Active Directory is exactly the same. Therefore, whether establishing a unified service layer interface between domain controllers or with the signaling domain, it needs to be completed through the configuration server. The setup and management of these interfaces are all to ensure the normal operation of the network and the security of the data.

[0091] In one possible implementation, the service layer interface includes a first interface, a second interface, and a third interface, and the first interface, the second interface, and the third interface are different. Specifically, the first interface is an NTF interface, the second interface is a PRC interface, and the third interface is a PUB / SUB interface; however, the first interface, the second interface, and the third interface may also be other communication protocol interfaces.

[0092] The embodiments of the present application can flexibly add or update services without affecting the stability of the entire system, thereby improving flexibility. Since services communicate with each other through well-defined interfaces and protocols, new services can be easily added or the functionality of existing services can be expanded as needed. This supports horizontal and vertical expansion of the system, enabling the system to handle more user requests and more complex business logic, thereby improving scalability. The system can be used across multiple applications and organizations, thereby improving reusability. By providing a unified communication method, the SOA service interface makes the interaction between services more efficient and reliable, better meeting the needs of modern software development, especially in complex systems such as vehicle controllers.

[0093] Optionally, NTF is a notification interface; PRC is a proxy interface; and PUB / SUB is a publish / subscribe interface. That is, the embodiments of the present application, by using a unified service layer interface (NTF, PRC, PUB / SUB), can support SOA communications of multiple communication protocols. In terms of logical communication, the service layer interface remains consistent, and intra-domain and extra-domain communications are isolated. Through this service layer interface, service requests (such as service requests) issued by applications (such as initiating applications) within domain controllers (such as requesting domain controllers) within the service domain can be received and processed.

[0094] The advantages and effects of SOA service interfaces (NTF, PRC, and PUB / SUB) primarily lie in improving system flexibility, scalability, and reusability. Specifically, the SOA architecture allows services to operate independently, meaning they can be added or updated flexibly without affecting the stability of the entire system. This modular design enables the system to quickly adapt to changes, whether internal requirements or external environmental changes. Scalability: Because services communicate through well-defined interfaces and protocols, it's easy to add new services or expand the functionality of existing services as needed. This design supports both horizontal and vertical system expansion, enabling the system to handle more user requests and more complex business logic. Reusability: The SOA architecture encourages service reuse. Once services are created, they can be used across multiple applications and organizations. This not only reduces development time and costs but also improves overall code quality, allowing developers to leverage existing services to build new applications without having to start from scratch. Consequently, SOA service interfaces provide a unified communication method, making interactions between services more efficient and reliable. These combined advantages enable SOA-based systems to better meet the demands of modern software development, especially in complex systems like vehicle controllers. In step S103, if the service request is an intra-service domain request, intra-domain communication is established between the initiating application and a first receiving application in the requesting domain controller.

[0095] In one possible implementation, if the service request is initiated by the initiating application in the requesting domain controller to the first receiving application in the requesting domain controller, the service request is judged to be an intra-service domain request; a first communication is established between the communication layer of the initiating application and the communication layer of the first receiving application, and based on the first communication, the first receiving application is controlled to provide a service response to the service request issued by the initiating application.

[0096] It should be noted that, as shown in Figure 4, within a service domain, various apps deployed on different controllers use a unified SOA service interface (NTF, PRC, PUB / SUB) to complete service calls between each other. This unified SOA service interface forms a unified SOA service logic bus. As shown in Figure 5, in terms of physical deployment, based on the specific controller deployment of each application app, it is divided into intra-domain service calls and inter-domain service calls. Intra-domain communication occurs between APP1 (the initiating application) and APP2 (the first receiving application), and between APP3 (the second initiating application) and APP4. The physical communication link does not need to pass through the gateway (GW_1 / GW_2) to complete the SOA service call.

[0097] Specifically, as shown in Figure 6, APP1 (i.e., the initiating application) and APP2 (i.e., the first receiving application) belong to the same domain controller (i.e., the requesting domain controller). APP1 initiates NTF, PRC, PUB / SUB requests and completes data communication through the underlying communication layer. As shown in communication 1 (i.e., the first communication) in Figure 6, APP2 performs NTF, PRC, PUB / SUB responses to complete an SOA service call.

[0098] In other words, through a unified service layer interface (NTF, PRC, PUB / SUB), SOA communication of multiple communication protocols is supported, which shields the differences in communication interfaces and communication protocols, reduces deployment resource consumption, isolates communications within and outside the domain, and enhances security.

[0099] It can be understood that completing a service call in a SOA (Service-Oriented Architecture) involves communicating between different service units within the system via network protocols to implement specific business functions. These service units are independent, reusable, and have well-defined, callable interfaces. In a service-oriented architecture, the system is typically divided into different service units, each of which may contain multiple functions. For example, in an automotive electrical and electronic system, there may be a controller unit for controlling the windows, another for controlling the lights, and so on. Each controller unit can be considered a service unit, and they interact and communicate through well-defined interfaces. Specifically, when a service call is required, such as opening a window, this operation is converted into a call to the window control service. This service call is sent via a network protocol to the window control service unit, which then processes the call according to the defined interface and returns the result, thus enabling the window to be controlled through the service call. Overall, completing a service call in an SOA involves communicating and exchanging data between different service units via well-defined interfaces and network protocols to implement specific business functions.

[0100] In a possible implementation, during an intra-domain communication to complete an SOA service call, the first data corresponding to the service request is identified; the initiating application is controlled to subscribe to changes in the first data from the first receiving application through the NTF; when the first data changes, the first receiving application is controlled to notify the initiating application through the NTF, and the initiating application is controlled to request the latest first data from the first receiving application through the PRC; and the first receiving application is controlled to send the latest first data back to the initiating application.

[0101] It's important to note that service layer interfaces refer to the standardized communication methods defined within the service layer, including NTF (Notification), PRC (Procedure Call), and PUB / SUB (Publish / Subscribe). These interfaces define how services interact and communicate with each other. For example, NTF is used to send notification messages, RRC is used for remote procedure calls, and PUB / SUB is used for publishing and subscribing to messages. Invocation refers to the actual interaction between services, namely the process of one service sending a request or message to another service using the NTF, PRC, or PUB / SUB interfaces. For example, an NTF invocation involves a service sending a notification to another service via the NTF interface, an RRC invocation involves making a remote call via the PRC interface, and a PUB / SUB invocation involves publishing messages to specific topics and having subscribers receive these messages. In other words, service layer interfaces define standard methods for communication between services, and invocations are the actual use cases of these interfaces.

[0102] Specifically, let's assume App1 is a vehicle monitoring system application that needs to obtain vehicle status information and update it to the dashboard in real time. To achieve this, App1 initiates a series of calls to App2. First, App1 subscribes to changes in vehicle status information from App2 via an NTF call. Then, when the vehicle status changes, App2 notifies App1 via an NTF call. Next, App1 requests the latest vehicle status information from App2 via a PRC call. Finally, App2 returns the latest vehicle status information to App1.

[0103] It is understood that the first receiving application sends the latest first data back to the initiating application, and then controls the initiating application to publish the latest first data through the PUB / SUB call. Optionally, after APP2 returns the latest vehicle status information to APP1, APP1 then publishes the latest vehicle status information to the dashboard through PUB / SUB. In the above process, the interaction between APP1 and APP2 is carried out through the network protocol; in addition, to ensure the security and reliability of the data, encryption and authentication and other technical means can also be used to protect the data transmission process.

[0104] That is to say, by defining a unified service layer interface (such as NTF, PRC, PUB / SUB), APP1 and APP2 can communicate without knowing each other's internal implementation. This abstraction makes the interaction between services more standardized and reduces the complexity of system integration; the unified service layer interface supports multiple communication protocols, so no matter what protocol is used at the bottom layer (such as CAN, LIN, Ethernet, etc.), it is transparent to the application layer, making it easier for the system to adapt to different communication technologies and improving the flexibility and scalability of the system; because the unified interface shields the differences in communication protocols, it can reduce dependence on specific protocols during development and deployment, thereby reducing the demand for hardware and software resources; through the service layer interface, domain control can be better controlled and managed The internal communication of the device is isolated from the external communication. This isolation can enhance the security of the system and prevent potential security threats. The shielding of unified interfaces and protocols can reduce the possibility of security vulnerabilities because they provide an additional layer of abstraction, making it more difficult for malicious attacks to directly target the underlying protocol. It improves development efficiency. Developers can use a unified API set for programming without having to worry about the underlying communication details, which simplifies the development process and allows for rapid iteration and deployment of new services. It facilitates maintenance and upgrades. When the underlying communication protocol needs to be updated or replaced, since the upper-level application does not directly depend on a specific protocol, maintenance and upgrade operations can be performed more easily without affecting the operation of the entire system. It improves user experience. Through efficient service calls and data communications, it can ensure that the vehicle system responds quickly and stably, thereby providing a better user experience.

[0105] In step S104, if the service request is an inter-domain service request, an inter-domain communication is established between the initiating application and a second receiving application in a receiving domain controller corresponding to the requesting domain controller.

[0106] In one possible implementation, if the service request is initiated by the initiating application in the requesting domain controller to the second receiving application in the receiving domain controller, the service request is determined to be an inter-service domain request; a second communication is established between the initiating application and the first gateway in the requesting domain controller, a third communication is established between the first gateway in the requesting domain controller and the second gateway in the receiving domain controller, and a fourth communication is established between the second gateway and the second receiving application; based on the second communication, the third communication and the fourth communication, the second receiving application is controlled to perform a service response to the service request issued by the initiating application.

[0107] It should be noted that, as shown in Figure 5, in terms of physical deployment, according to the specific controller deployment of each application APP, it is divided into intra-domain service calls and inter-domain service calls. The communication between APP1 (i.e., the initiating application) and APP3 (i.e., the second receiving application) and APP4, as well as between APP2 (the third initiating application) and APP3 and APP4 is inter-domain communication. The physical link needs to pass through the gateway (GW_1 / GW_2) to complete the SOA service call.

[0108] Specifically, as shown in Figure 7, APP1 and APP3 belong to different domain controllers. APP1 initiates NTF, PRC, PUB / SUB requests, which will be sent to GW_1 (i.e., the first gateway) through communication 2 (i.e., the second communication) in Figure 7, and the data forwarding is completed by communication 4 (i.e., the third communication) between GW_1 and GW_2 (i.e., the second gateway). After that, it is passed to APP3 (i.e., the second receiving application) through communication 5 (i.e., the fourth communication) in Figure 7, and NTF, PRC, PUB / SUB responses are performed, thereby completing an SOA service call.

[0109] That is to say, through the unified service layer interface (NTF, PRC, PUB / SUB), the gateway completes the conversion of internal and external communication protocols. In logical communication, the service layer interface is kept consistent. On the physical link, the gateway is used to isolate internal and external domain communications, mask differences in communication interfaces, mask differences in communication protocols, reduce deployment resource consumption, isolate internal and external domain communications, and enhance security.

[0110] In one possible implementation, during an SOA service call completed by inter-domain communication, the second data corresponding to the service request is identified; the initiating application is controlled to subscribe to changes in the second data to the second receiving application through the NTF; and when the second data changes, the second receiving application is controlled to process the second data.

[0111] Specifically, for example, in a vehicle monitoring system, APP1 is responsible for collecting vehicle status information (such as speed and location) and publishing this information in the form of NTF, PRC, PUB / SUB; APP3 is responsible for receiving this information and performing corresponding processing as needed (such as updating the display on the dashboard). When APP1 needs to send status information to APP3, it first sends the request to GW_1, which then forwards the request to GW_2, and finally GW_2 passes the request to APP3. On APP3, it processes the received information and returns the results to APP1 or other subscribers in the form of NTF, PRC, PUB / SUB. This allows for efficient information transmission and processing.

[0112] Optionally, when the second data changes, after the second receiving application processes the second data, the initiating application is controlled to request the second receiving application for updated second data through the PRC.

[0113] In other words, the first and second gateways enable APP1 and APP3, located in different domain controllers, to communicate seamlessly, enhancing the overall interoperability of the system. The gateway is responsible for handling potential differences in communication protocols between different domain controllers. It can convert requests such as NTF, PRC, and PUB / SUB from one protocol to another, logically maintaining the consistency of the service layer interface and simplifying application layer development. The use of a unified service layer interface and gateway reduces dependence on specific hardware, thereby reducing deployment costs. The same service can run under different hardware and network conditions without major modifications. The gateway acts as a firewall, blocking unauthorized access, protecting internal services from external threats, and improving the security of the entire vehicle communication network. Using the gateway for communication isolation can effectively prevent potential security risks from spreading to other service domains. Even if a service domain is attacked, it will not affect the stability of the entire system. As the functionality of the vehicle system increases, more services and applications may need to be added. By using the gateway to manage communication, the integration of new services becomes simpler, and the system maintenance and upgrades are also easier. The gateway can perform data preprocessing, such as data compression and filtering, to reduce network bandwidth usage, thereby improving the performance of the entire vehicle communication system.

[0114] In step S105 , if the service request is determined to be a cross-domain request, a cross-domain communication is established between the initiating application and the signaling domain.

[0115] In one possible implementation, if the service request is initiated by the initiating application in the requesting domain controller to the signal domain, the service request is determined to be a cross-domain request; a second communication is established between the initiating application and the first gateway in the requesting domain controller, a fifth communication is established between the first gateway in the requesting domain controller and the proxy service in the service domain, a sixth communication is established between the proxy service and the signal domain, and an internal communication is established between the proxy service and the service gateway in the service domain; based on the sixth communication, the signal in the signal domain is converted into a target service for a service call interface; based on the second communication, the fifth communication and the internal communication, the service gateway is controlled to provide a service response to the service request issued by the initiating application to the target service.

[0116] It should be noted that, as shown in FIG8 , through the service proxy gateway (SOA_Proxy_ON_SOC) deployed on the domain controller, all signals in the signal domain are “translated” into services that can be used for service call interfaces (as described in FIG11 below, how to “translate” signals into services). In this way, all signals provided by the signal domain are provided in the form of services in the service domain, and its basic communication process is consistent with the inter-domain communication within the above-mentioned service domain.

[0117] Specifically, as shown in Figure 9, first, by using a unified SOA service interface (NTF, PRC, PUB / SUB), mutual service calls are completed. Through this unified SOA service interface, a unified SOA service logic bus is formed, including services X, Y, and Z (i.e., target services) provided by SOA_Proxy_ON_SOC (i.e., proxy service) deployed on the domain controller. Secondly, here, the basic communication process is explained using the service call between APP1 and services X, Y, and Z shown in Figure 10. APP1 initiates an NTF, PRC, PUB / SUB call, and sends data to GW_1 (i.e., the first gateway) through communication 2 (i.e., the second communication) in Figure 10. Then, through communication 9 (i.e., the fifth communication) in Figure 10, the data is sent to SOA_Proxy_ON_SOC, and the data is given to services X, Y, and Z through internal communication. This link then performs an NTF, PRC, PUB / SUB response, completing an SOA service call.

[0118] That is to say, through the unified service layer interface (NTF, PRC, PUB / SUB), the proxy service gateway of the signal domain completes the SOA service call. In terms of logical communication, the service layer interface is kept consistent. In terms of physical links, the gateway is used to isolate the communication within and outside the domain, and the complexity of the signal domain is abstracted and simplified through the gateway; the differences in communication interfaces and communication protocols are shielded, the deployment resource consumption is reduced, the communication within and outside the domain is isolated, and security is enhanced.

[0119] In one possible implementation, in the process of converting the signal in the signal domain into a target service for a service call interface, a communication module is used to synchronize the signal in the signal domain with itself (to ensure coordination and consistency between the various signals. Specifically, by adopting the CAN / CANFD protocol, efficient data transmission and processing can be achieved, thereby ensuring the stable operation of the automotive electronic control system); a signal list corresponding to the self-synchronized signal is established in the proxy service, and a mapping relationship is established between the signal list and the object group; based on the mapping relationship, a service call interface is provided to the outside through the interface function of the object group, and a function call relationship is established between the service gateway and the service call interface to provide the target service to the outside.

[0120] It should be noted that the steps of "translating" the signals in the signal domain into services include: establishing a communication connection. First, it is necessary to establish a CAN / CANFD communication connection between the signal domain (basic vehicle interface unit) and the SOA_Proxy_ON_SOC software deployed in the service domain, which is achieved through hardware equipment and network configuration; synchronizing the signal, and then synchronizing the signal in the signal domain with it through the module CAN / CANFD, so as to ensure the coordination and consistency between the various signals; establishing a mapping relationship, establishing a signal list in the SOA_Proxy_ON_SOC software, which corresponds one-to-one to the signal in the signal domain, and then establishing a mapping relationship between this list and the Object_1 object, so as to convert the signal into an object that can be processed by the software; providing a service call interface, and finally providing a service call interface to the outside through the interface functions PUB / SUB_Obj_Attr_1(bool):bool and RPC / NTF_Obj_Attr_1(bool):bool of Object_1, and through the service gateway, after establishing a function call relationship with the above interface, providing services to the outside, so that other systems or devices can call these services through the network.

[0121] Specifically, Figure 11 describes how signals within the signal domain are "translated" into services via the SOA_Proxy_ON_SOC software deployed on the domain controller. First, a CAN / CANFD communication connection is established between the signal domain (the base vehicle interface unit, such as communication 10 (the sixth communication) in Figure 8 ) and the SOA_Proxy_ON_SOC software deployed in the service domain. The signals within the signal domain are synchronized with the SOA_Proxy_ON_SOC software via the CAN / CANFD module (signals x, y, z, ...) in Figure 11 . Based on the direction of data flow, synchronization is divided into downlink synchronization of control messages (signals from the SOA_Proxy_ON_SOC software to the base vehicle interface unit software) and uplink synchronization of status messages.

[0122] It can be understood that "Services X, Y and Z" refer to a set of services that APP1 needs to call. These services may be provided by different applications or systems to complete specific functions or tasks; "SOA_Proxy_ON_SOC" is a service-oriented architecture (SOA) proxy located on the service hosting environment. This proxy serves as the entry point of the service, responsible for processing client requests and forwarding them to the corresponding services. In this way, when APP1 needs to call services X, Y and Z, it can send the request to SOA_Proxy_ON_SOC, and then SOA_Proxy_ON_SOC forwards the request to the corresponding service.

[0123] As an example, the control message in Figure 11 is sent once during the regular cycle. Downlink synchronization is required at this time, so the SOA_Proxy_ON_SOC software actively sends a CAN / CANFD message, synchronizes its control signal to the base vehicle interface unit, and further sends the signal down to the specific controller unit. In this way, a signal list is established in the SOA_Proxy_ON_SOC software, which corresponds one-to-one with the signals in the signal domain. Secondly, a mapping relationship is established between the established signal list and the Object_1 object (for example, a one-to-one mapping relationship, or other mapping relationships). Finally, a service call interface is provided externally through Object_1's interface functions PUB / SUB_Obj_Attr_1(bool):bool and RPC / NTF_Obj_Attr_1(bool):bool. After establishing a function call relationship with the above interface through the module service gateway (service x, y, z...) as shown in Figure 11, the service is provided externally. This completes the mapping relationship between signals and services.

[0124] Optionally, in order to ensure the synchronization of signals and services under abnormal circumstances such as power-on and reset, mechanisms such as power-on synchronization and request synchronization are provided to ensure that signals and services are synchronized within a certain time; in order to reduce the amount of data transmitted between signals and services under normal working conditions, differential synchronization is performed during the synchronization process of services and signals, that is, synchronization is performed only when there are changes, so as to ensure the reliability, determinism and stability of communication.

[0125] In other words, a unified interface definition enables different services and applications to communicate in a standardized way; communicating through a unified service interface reduces the coupling between system components, and each service only needs to care about how to interact with the service interface without having to understand the implementation details of other services; a unified service interface promotes the reusability of services, and services with the same interface can be reused by different applications in different places, improving development efficiency; in the system integration phase, a unified interface reduces the complexity of integration because all services follow the same communication rules, simplifying the testing and verification process; when a service needs to be updated or replaced, such changes have little impact on the system due to the use of a unified interface. The impact on other parts is relatively small, making system maintenance simpler and faster; as system requirements grow, new services can be easily added to the bus without making extensive modifications to the existing system; communication isolation through the gateway can prevent the spread of security issues, and even if a service is attacked, it will not affect the stability of the entire system; the use of unified interfaces and gateways can reduce the redundant use of hardware resources, thereby reducing the cost of the entire system; the proxy service gateway can handle multiple communication protocols and provide a unified service call method for upper-level applications, so that application developers do not need to worry about the specific communication details of the underlying layer; the gateway can implement additional security measures such as authentication, authorization and encryption to ensure the secure transmission of data.

[0126] In one possible implementation, a second service request issued by a second initiating application in a requesting domain controller is received, wherein the second initiating application and the first receiving application are the same application or different applications; if the second service request is an intra-service domain request, intra-domain communication is created between the second initiating application and a third receiving application in the requesting domain controller.

[0127] It is understood that, as shown in Figures 4 and 8, while or after receiving the service request issued by the initiating application within the requesting domain controller, a second service request issued by a second initiating application (APP2 or other application within the requesting domain controller) to another application within the requesting domain controller may be received. The intra-domain communication created by the service intra-domain request is similar to the above steps and will not be repeated here. Specifically, Figure 8 shows the intra-domain communication between APP1 (issuing) and APP2 (receiving), and between APP3 (issuing) and APP4 (receiving).

[0128] In one possible implementation, a third service request issued by a third initiating application within a receiving domain controller is received, wherein the third initiating application and the second receiving application are the same application or different applications; if the third service request is an intra-service domain request, intra-domain communication is created between the third initiating application and the fourth receiving application within the receiving domain controller; if the third service request is an inter-service domain request, inter-domain communication is created between the third initiating application and the fifth receiving application within the requesting domain controller; wherein the fifth receiving application and the first receiving application are the same application or different applications; if the third service request is a cross-domain request, cross-domain communication is created between the third initiating application and the signal domain.

[0129] It is understandable that, as shown in Figures 4 and 8, while or after receiving the service request issued by the initiating application in the requesting domain controller, a third service request issued by a third initiating application (APP3 or APP4 or other application in the receiving domain controller) to other applications in the requesting domain controller or other domain controllers can be received. The inter-domain communication created by the request within the service domain is similar to the above steps and will not be repeated here. Specifically, in Figure 8, the inter-domain communication between APP1 (issuing) and APP3 (receiving), APP1 (issuing) and APP4 (receiving), APP2 (issuing) and APP3 (receiving), and APP2 (issuing) and APP4 (receiving) are shown.

[0130] The embodiment of the present application uses a unified service layer interface, and while the service request is in progress, other applications in the requesting domain controller can issue a second service request, thereby achieving efficient intra-domain information transmission; according to the above-mentioned technical means, the embodiment of the present application uses a unified service layer interface, and while the service request is in progress, the application in the receiving domain controller can issue a third service request, thereby achieving efficient intra-domain, inter-domain or cross-domain information transmission and processing.

[0131] In summary, this application uses a unified service layer interface, processes various service requests based on the service layer interface, and creates intra-domain communication, inter-domain communication, or cross-domain communication accordingly. It can effectively manage and control the communication process within the vehicle, shield the differences in communication interfaces and communication protocols, reduce deployment resource consumption, thereby improving communication efficiency and stability and reducing communication costs.

[0132] Next, the vehicle communication system proposed according to the embodiment of the present application is described with reference to the accompanying drawings.

[0133] FIG12 is a block diagram of a vehicle communication system according to an embodiment of the present application.

[0134] As shown in FIG. 12 , the vehicle communication system 10 includes: an interface creation module 100 , a request receiving module 200 , an intra-domain communication module 300 , an inter-domain communication module 400 and an inter-domain communication module 500 .

[0135] Specifically, the interface creation module 100 is used to create a unified service layer interface, wherein the service layer interface is used for communication within each domain controller within the service domain, communication between multiple domain controllers within the service domain, and communication between each domain controller within the service domain and the signal domain; the request receiving module 200 is used to receive a service request issued by an initiating application within the requesting domain controller through the service layer interface; the intra-domain communication module 300 is used to create intra-domain communication between the initiating application and the first receiving application within the requesting domain controller if the service request is an intra-service domain request; the inter-domain communication module 400 is used to create inter-domain communication between the initiating application and the second receiving application within the receiving domain controller if the service request is an inter-service domain request; the cross-domain communication module 500 is used to create cross-domain communication between the initiating application and the signal domain if the service request is a cross-domain request.

[0136] Optionally, in one embodiment of the present application, the intra-domain communication module 300 includes: an intra-domain request determination unit and an intra-domain service response unit. The intra-domain request determination unit is configured to determine that the service request is an intra-domain service request if the service request is initiated by the initiating application in the requesting domain controller to the first receiving application in the requesting domain controller; and the intra-domain service response unit is configured to establish a first communication between the communication layer of the initiating application and the communication layer of the first receiving application, and based on the first communication, control the first receiving application to provide a service response to the service request issued by the initiating application.

[0137] Optionally, in one embodiment of the present application, the intra-domain service response unit includes: an intra-domain data identification sub-unit, an intra-domain notification sub-unit, an intra-domain update request sub-unit and an intra-domain updated data return sub-unit; wherein, the intra-domain data identification sub-unit is used to identify the first data corresponding to the service request; the intra-domain notification sub-unit is used to control the initiating application to subscribe to the changes of the first data to the first receiving application through the NTF; the intra-domain update request sub-unit is used to control the first receiving application to notify the initiating application through the NTF when the first data changes, and control the initiating application to request the latest first data from the first receiving application through the PRC; the intra-domain updated data return sub-unit is used to control the first receiving application to send the latest first data back to the initiating application.

[0138] Optionally, in one embodiment of the present application, the inter-domain communication module 400 includes: an inter-domain request judgment unit, an inter-domain communication establishment unit and an inter-domain service response unit; wherein the inter-domain request judgment unit is used to judge that the service request is an inter-domain service request if the service request is initiated by the initiating application in the requesting domain controller to the second receiving application in the receiving domain controller; the inter-domain communication establishment unit is used to establish a second communication between the initiating application and the first gateway in the requesting domain controller, a third communication between the first gateway in the requesting domain controller and the second gateway in the receiving domain controller, and a fourth communication between the second gateway and the second receiving application; the inter-domain service response unit is used to control the second receiving application to perform a service response to the service request issued by the initiating application based on the second communication, the third communication and the fourth communication.

[0139] Optionally, in one embodiment of the present application, the inter-domain service response unit includes: an inter-domain data identification sub-unit, an inter-domain notification sub-unit, and an inter-domain data processing sub-unit; wherein, the inter-domain data identification sub-unit is used to identify the second data corresponding to the service request; the inter-domain notification sub-unit is used to control the initiating application to subscribe to the changes of the second data to the second receiving application through the NTF; the inter-domain data processing sub-unit is used to control the second receiving application to process the second data when the second data changes.

[0140] Optionally, in one embodiment of the present application, the cross-domain communication module 500 includes: a cross-domain request judgment unit, a cross-domain communication establishment unit, a signal service conversion unit and an inter-domain service response unit; wherein the cross-domain request judgment unit is used to judge that the service request is a cross-domain request if the service request is initiated by the initiating application in the requesting domain controller to the signal domain; the cross-domain communication establishment unit is used to establish a second communication between the initiating application and the first gateway in the requesting domain controller, a fifth communication between the first gateway in the requesting domain controller and the proxy service in the service domain, a sixth communication between the proxy service and the signal domain, and an internal communication between the proxy service and the service gateway in the service domain; the signal service conversion unit is used to convert the signal of the signal domain into a target service for a service call interface based on the sixth communication; the inter-domain service response unit is used to control the service gateway to perform a service response to the service request issued by the initiating application to the target service based on the second communication, the fifth communication and the internal communication.

[0141] Optionally, in one embodiment of the present application, the inter-domain service response unit includes: a signal synchronization sub-unit, a mapping establishment sub-unit and a service call providing sub-unit; wherein the signal synchronization sub-unit is used to use a communication module to synchronize the signal within the signal domain; the mapping establishment sub-unit is used to establish a signal list corresponding to the signal after self-synchronization in the proxy service, and establish a mapping relationship between the signal list and the object group; the service call providing sub-unit is used to provide a service call interface to the outside through the interface function of the object group based on the mapping relationship, and establish a function call relationship between the service call interface and the service gateway to provide the target service to the outside.

[0142] Optionally, in one embodiment of the present application, the vehicle communication system 10 further includes: a second service request unit and a second intra-domain communication unit; wherein, the second service request unit is used to receive a second service request issued by a second initiating application in the requesting domain controller, wherein the second initiating application and the first receiving application are the same application or different applications; the second intra-domain communication unit is used to create intra-domain communication between the second initiating application and a third receiving application in the requesting domain controller if the second service request is an intra-service domain request.

[0143] Optionally, in one embodiment of the present application, the vehicle communication system 10 further includes: a third service request unit, a third intra-domain communication unit, a second inter-domain communication unit and a second cross-domain communication unit; wherein the third service request unit is used to receive a third service request issued by a third initiating application in the receiving domain controller, wherein the third initiating application and the second receiving application are the same application or different applications; the third intra-domain communication unit is used to create intra-domain communication between the third initiating application and the fourth receiving application in the receiving domain controller if the third service request is an intra-service domain request; the second inter-domain communication unit is used to create inter-domain communication between the third initiating application and the fifth receiving application in the requesting domain controller if the third service request is an inter-service domain request; wherein the fifth receiving application and the first receiving application are the same application or different applications; the second cross-domain communication unit is used to create cross-domain communication between the third initiating application and the signal domain if the third service request is a cross-domain request.

[0144] Optionally, in one embodiment of the present application, the vehicle communication system 10 further includes: an intra-domain data publishing subunit and an inter-domain data publishing subunit; wherein, the intra-domain data publishing subunit is used to control the initiating application to publish the latest first data through the PUB / SUB; the inter-domain data publishing subunit is used to control the initiating application to request the updated second data from the second receiving application through the PRC.

[0145] It should be noted that the aforementioned explanation of the vehicle communication method embodiment is also applicable to the vehicle communication system of this embodiment and will not be repeated here.

[0146] The vehicle communication system proposed in the embodiments of the present application can effectively manage and control the communication process within the vehicle by using a unified service layer interface and processing various service requests based on the service layer interface, and accordingly creating intra-domain communication, inter-domain communication, or cross-domain communication. This shields differences in communication interfaces and communication protocols, reduces deployment resource consumption, thereby improving communication efficiency and stability, and reducing communication costs. This solves the technical problem in related technologies of limited communication due to differences in communication interfaces and communication protocols, as well as high deployment resource consumption.

[0147] Figure 13 is a schematic diagram of the structure of a vehicle provided in an embodiment of the present application. The vehicle may include: a memory 501, a processor 502, and a computer program stored in the memory 501 and executable by the processor 502. When the processor 502 executes the program, the vehicle communication method provided in the above embodiment is implemented.

[0148] Optionally, the vehicle also includes: a communication interface 503 for communication between the memory 501 and the processor 502; the memory 501 is used to store computer programs that can be run on the processor 502; the memory 501 may include a high-speed RAM memory, and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.

[0149] If the memory 501, processor 502, and communication interface 503 are implemented independently, the communication interface 503, memory 501, and processor 502 can be interconnected via a bus to enable communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EIS) bus. Buses can be categorized as address buses, data buses, control buses, and the like. For ease of illustration, FIG5 shows only one thick line, but this does not imply that there is only one bus or only one type of bus.

[0150] Alternatively, in a specific implementation, if the memory 501, processor 502, and communication interface 503 are integrated on a single chip, the memory 501, processor 502, and communication interface 503 may communicate with each other through an internal interface. The processor 502 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application.

[0151] This embodiment also provides a computer-readable storage medium having a computer program stored thereon, which implements the above vehicle communication method when executed by a processor.

[0152] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or N embodiments or examples in a suitable manner. In addition, those skilled in the art can combine and combine different embodiments or examples described in this specification and features of different embodiments or examples without contradiction.

[0153] In addition, the terms "first" and "second" are used for descriptive purposes only and are not to be understood as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of the features. In the description of the present application, "N" means at least two, such as two, three, etc., unless otherwise clearly and specifically defined. Any process or method description in the flowchart or otherwise described herein may be understood to represent a module, fragment or portion of a code comprising one or N executable instructions for implementing the steps of a custom logical function or process, and the scope of the optional embodiments of the present application includes additional implementations, in which functions may be performed not in the order shown or discussed, including in a substantially simultaneous manner or in the opposite order according to the functions involved, which should be understood by those skilled in the art to which the embodiments of the present application belong.

[0154] The logic and / or steps represented in the flowcharts or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing the logical functions, and can be embodied in any computer-readable storage medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (e.g., a computer-based system, a system including a processor, or other system that can fetch and execute instructions from an instruction execution system, apparatus, or device). For purposes of this specification, a "computer-readable storage medium" can be any device that can contain, store, communicate, propagate, or transport a program for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable storage media include the following: an electrical connection having one or N wires (electronic devices), a portable computer disk cartridge (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable and programmable read-only memory (EPROM or flash memory), a fiber optic device, and a portable compact disc read-only memory (CDROM). In addition, the computer-readable storage medium may even be paper or other suitable medium on which the program is printed, since the program can be obtained electronically by optically scanning the paper or other medium and then editing, interpreting or processing it in other suitable ways as necessary, and then storing it in a computer memory.

[0155] It should be understood that various parts of the present application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiment, the N steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented using hardware, as in another embodiment, any one of the following technologies known in the art or a combination thereof can be used to implement: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application-specific integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0156] Those skilled in the art will understand that all or part of the steps in the method of the above embodiment can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiment.

[0157] In addition, the functional units in the various embodiments of the present application may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into a module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium.

[0158] It should be understood that the application of this application is not limited to the above examples. For ordinary technicians in this field, they can make improvements or changes based on the above description. All these improvements and changes should fall within the scope of protection of the claims attached to this application.

Claims

1. A vehicle communication method, characterized in that: The vehicle communication method includes: Creating a unified service layer interface, wherein the service layer interface is used for communication within each domain controller in the service domain, communication between multiple domain controllers in the service domain, and communication between each domain controller in the service domain and the signal domain; receiving, through the service layer interface, a service request from an initiating application in a requesting domain controller, wherein the requesting domain controller is a domain controller in the service domain; If the service request is an intra-service domain request, then establishing intra-domain communication between the initiating application and a first receiving application in the requesting domain controller; if the service request is an inter-service domain request, then establishing inter-domain communication between the initiating application and a second receiving application in the receiving domain controller corresponding to the requesting domain controller; If the service request is a cross-domain request, a cross-domain communication is established between the initiating application and the signal domain.

2. The vehicle communication method according to claim 1, wherein: If the service request is an intra-service domain request, establishing intra-domain communication between the initiating application and the first receiving application in the requesting domain controller specifically includes: If the service request is initiated by the initiating application in the requesting domain controller to the first receiving application in the requesting domain controller, then determining that the service request is an intra-service domain request; A first communication is established between the communication layer of the initiating application and the communication layer of the first receiving application, and based on the first communication, the first receiving application is controlled to perform a service response to the service request issued by the initiating application.

3. The vehicle communication method according to claim 2, characterized in that: The controlling the first receiving application to perform a service response to the service request issued by the initiating application specifically includes: identifying first data corresponding to the service request; Controlling the initiating application to subscribe to changes of the first data from the first receiving application through a first interface; When the first data changes, control the first receiving application to notify the initiating application through the first interface, and control the initiating application to request the latest first data from the first receiving application through the second interface; Control the first receiving application to send the latest first data back to the initiating application.

4. The vehicle communication method according to claim 3, characterized in that: The step of controlling the first receiving application to send the latest first data back to the initiating application further includes: Control the initiating application to publish the latest first data through a third interface.

5. The vehicle communication method according to claim 1, wherein: If the service request is an inter-domain service request, establishing inter-domain communication between the initiating application and a second receiving application in a receiving domain controller corresponding to the requesting domain controller specifically includes: If the service request is initiated by the initiating application in the requesting domain controller to a second receiving application in a receiving domain controller corresponding to the requesting domain controller, then determining that the service request is an inter-service domain request; Establishing a second communication between the initiating application and a first gateway in the requesting domain controller, a third communication between the first gateway in the requesting domain controller and a second gateway in the receiving domain controller, and a fourth communication between the second gateway and the second receiving application; Based on the second communication, the third communication, and the fourth communication, the second receiving application is controlled to perform a service response to the service request issued by the initiating application.

6. The vehicle communication method according to claim 5, characterized in that: The controlling the second receiving application to perform a service response to the service request issued by the initiating application specifically includes: identifying second data corresponding to the service request; Controlling the initiating application to subscribe to changes of the second data from the second receiving application through the first interface; When the second data changes, the second receiving application is controlled to process the second data.

7. The vehicle communication method according to claim 6, characterized in that: When the second data changes, controlling the second receiving application to process the second data further includes: The initiating application is controlled to request the second receiving application for updated second data through the second interface.

8. The vehicle communication method according to claim 1, wherein: If the service request is a cross-domain request, establishing cross-domain communication between the initiating application and the signal domain specifically includes: If the service request is initiated by the initiating application in the requesting domain controller to the signaling domain, determining that the service request is a cross-domain request; establishing a second communication between the initiating application and a first gateway within the requesting domain controller, a fifth communication between the first gateway within the requesting domain controller and a proxy service within the serving domain, a sixth communication between the proxy service and the signaling domain, and an internal communication between the proxy service and a serving gateway within the serving domain; Based on the sixth communication, converting the signal in the signal domain into a target service for a service call interface; Based on the second communication, the fifth communication, and the internal communication, the service gateway is controlled to perform a service response to the service request sent by the initiating application to the target service.

9. The vehicle communication method according to claim 8, characterized in that: The converting of the signal in the signal domain into a target service for a service call interface specifically includes: Synchronizing the signals within the signal domain with each other using a communication module; A signal list corresponding to the signal synchronized with itself is established in the proxy service, and a mapping relationship is established between the signal list and the object group; based on the mapping relationship, a service call interface is provided to the outside through the interface function of the object group, and a function call relationship is established between the service gateway and the service call interface to provide the target service to the outside.

10. A vehicle communication system, characterized in that: The vehicle communication system comprises: An interface creation module, configured to create a unified service layer interface, wherein the service layer interface is used for communication within each domain controller within a service domain, communication between multiple domain controllers within a service domain, and communication between each domain controller within a service domain and a signaling domain; a request receiving module, configured to receive, through the service layer interface, a service request from an initiating application in a requesting domain controller, wherein the requesting domain controller is a domain controller in the service domain; an intra-domain communication module, configured to establish intra-domain communication between the initiating application and a first receiving application in the requesting domain controller if the service request is an intra-service domain request; an inter-domain communication module, configured to establish inter-domain communication between the initiating application and a second receiving application in a receiving domain controller corresponding to the requesting domain controller if the service request is an inter-domain service request; A cross-domain communication module is configured to establish cross-domain communication between the initiating application and the signal domain if the service request is a cross-domain request.

11. A vehicle, characterized in that: The vehicle includes: a memory, a processor, and a vehicle communication program stored in the memory and executable on the processor. When the vehicle communication program is executed by the processor, the steps of the vehicle communication method according to any one of claims 1 to 9 are implemented.

12. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a vehicle communication program, and when the vehicle communication program is executed by a processor, the steps of the vehicle communication method according to any one of claims 1 to 9 are implemented.

Images