Vehicle cross-domain communication method, device and system and functional domain controller

By building a protocol software development toolkit in the functional domain controller of smart cars, direct communication between functional domain controllers of different programming languages ​​is solved, and the communication complexity between the smart cockpit domain and the smart driving domain is reduced, and the difficulty of development and debugging is reduced.

CN120075308APending Publication Date: 2025-05-30VOYAH AUTOMOBILE TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510001010.5
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-01-02
Publication Date
2025-05-30

AI Technical Summary

Technical Problem

In smart car design, the communication between the smart cockpit domain and the smart driving domain needs to be adapted using middleware due to different programming languages, which increases the difficulty of development and debugging.

Method used

Direct communication between functional domain controllers in different programming languages ​​is achieved by building protocol software development kits, including Json conversion modules and messaging library modules.

Benefits of technology

It reduces the use of middleware, reduces the difficulty of development and debugging for functional domain developers, and improves development efficiency and direct communication.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120075308A_ABST
    Figure CN120075308A_ABST
Patent Text Reader

Abstract

The invention discloses a vehicle cross-domain communication method, a vehicle cross-domain communication device, a vehicle cross-domain communication system and a functional domain controller. The first message data in the first format is converted into first Json data through a first Json conversion module of a first protocol software development kit in a first functional domain controller of the vehicle, and the first Json data is sent to a second functional domain controller through a first message passing library module; and monitoring second Json data through the first message passing library module under the condition that it is determined that the message needs to be subscribed and responded, and converting the second Json data into second message data in the first format through the first Json conversion module after the second Json data is monitored. According to the scheme, direct communication between functional domain controllers using different programming languages is realized, and the difficulty of functional domain development and debugging is reduced.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application belongs to the technical field of vehicle communication, and particularly relates to a method, device, system and functional domain controller for vehicle cross-domain communication. Background Art

[0002] In the design of intelligent vehicles, with the introduction of technologies such as intelligent driving and intelligent cockpits, multiple functional domains including a gateway domain, an intelligent driving domain, and an intelligent cockpit domain have been formed inside the vehicle, and the communication requirements between these functional domains have become increasingly complex.

[0003] Taking the communication between the intelligent driving domain and the intelligent cockpit domain as an example, Android applications in the domain controller of the intelligent cockpit domain are usually written in the Java language, while programs in the domain controller of the intelligent driving domain are usually written in the C++ language or the C language. To achieve communication between the intelligent cockpit domain and the intelligent driving domain, middleware written in a language other than the Java language (such as JNI middleware) needs to be used in the intelligent cockpit domain to adapt the programming languages, which increases the development and debugging difficulties for developers on the intelligent cockpit domain side. Summary of the Invention

[0004] Embodiments of this application provide a method, device, system and functional domain controller for vehicle cross-domain communication, thereby realizing direct communication between functional domain controllers using different programming languages, which can reduce the use of middleware and the development and debugging difficulties for functional domain developers.

[0005] Other features and advantages of this application will become apparent through the following detailed description, or be learned in part through the practice of this application.

[0006] According to the first aspect of the embodiments of this application, a method for vehicle cross-domain communication is provided, which is applied to the first functional domain controller of a vehicle. It is characterized in that the programming language types of the first functional domain controller and the second functional domain controller of the vehicle are different. The first functional domain controller is built-in with a first protocol software development kit, and the second functional domain controller is built-in with a second protocol software development kit. The first protocol software development kit includes a first Json conversion module and a first message passing library module. The method includes:

[0007] When it is determined that a request message and a publish message are needed, convert the first message data in the first format into first Json data through the first Json conversion module, and send the first Json data to the second functional domain controller through the first message passing library module;

[0008] In the case of determining that message subscription and response messages are required, the second Json data is listened to through the first message passing library module, and after the second Json data is listened to, the second Json data is converted into second message data in the first format through the first Json conversion module, where the second Json data is obtained by converting third message data in the second format by the second protocol software development kit.

[0009] In some embodiments, before converting the first message data in the first format into the first Json data through the first Json conversion module or listening to the second Json data through the first message passing library module, the vehicle cross-domain communication method further includes:

[0010] Create a message request instance and a message subscription instance corresponding to the second functional domain controller according to the IP address and port number of the second functional domain controller;

[0011] Create a message publishing instance and a message response instance corresponding to the first functional domain controller according to the IP address and port number of the first functional domain controller;

[0012] Create socket ports for the message request instance, the message subscription instance, the message publishing instance, and the message response instance respectively through the first message passing library module.

[0013] In some embodiments, sending the first Json data to the second functional domain controller through the first message passing library module includes:

[0014] In the case of determining that a message request is required, send the first Json data to the second functional domain controller through the socket port of the message request instance;

[0015] In the case of determining that a message needs to be published, send the first Json data to the second functional domain controller through the socket port of the message publishing instance.

[0016] In some embodiments, in the case of subscribing to messages and response messages, listening to the second Json data through the first message passing library module includes:

[0017] In the case of determining that a message subscription is required, listen to the second Json data through the socket port of the message subscription instance;

[0018] In the case of determining that a response message is required, listen to the second Json data through the socket port of the message response instance.

[0019] In some embodiments, the programming language type of the first functional domain controller includes the Java language, the programming language type of the second functional domain controller includes the C++ language or the C language, the first message data in the first format is Java data, and the third message data in the second format is structure data.

[0020] In some embodiments, the first message passing library module includes the jeromq library, the second protocol software development kit includes the second message passing library module, and the second message passing library module includes the cppzmq library or the libzmq library.

[0021] According to a second aspect of the embodiments of the present application, there is provided a vehicle cross-domain communication device, which is applied to the first functional domain controller of a vehicle. The programming language types of the first functional domain controller and the second functional domain controller of the vehicle are different. The first functional domain controller is built-in with a first protocol software development kit, and the second functional domain controller is built-in with a second protocol software development kit. The first protocol software development kit includes a first Json conversion module and a first message passing library module. The device includes:

[0022] A first message processing module, configured to, when it is determined that a request message and a publish message are required, convert the first message data in the first format into first Json data through the first Json conversion module, and send the first Json data to the second functional domain controller through the first message passing library module;

[0023] A second message processing module, configured to, when it is determined that a subscription message and a response message are required, listen for second Json data through the first message passing library module, and after the second Json data is listened to, convert the second Json data into second message data in the first format through the first Json conversion module, where the second Json data is obtained by the second protocol software development kit converting the third message data in the second format.

[0024] According to a third aspect of the embodiments of the present application, there is provided a functional domain controller, including a processor and a memory. The memory stores computer program instructions that can be executed by the processor. When the processor executes the computer program instructions, the steps of the method according to any one of the above first aspects are implemented.

[0025] According to the fourth aspect of the embodiments of the present application, a vehicle cross-domain communication system is provided, which includes the functional domain controller of the above-mentioned third aspect and the second functional domain controller of the vehicle. The programming language types of the functional domain controller and the second functional domain controller are different. The first functional domain controller is built-in with a first protocol software development kit, and the second functional domain controller is built-in with a second protocol software development kit. The first protocol software development kit includes a first Json conversion module and a first message passing library module, and the second protocol software development kit includes a second Json conversion module and a second message passing library module.

[0026] In some embodiments, the functional domain controller is an intelligent cockpit domain controller, and the second functional domain controller is a gateway domain controller, an intelligent driving domain controller or an instrument controller.

[0027] In the present application, when it is determined that a request message and a publish message are needed, the first Json conversion module of the first protocol software development kit in the first functional domain controller of the vehicle converts the first message data in the first format into first Json data, and the first message passing library module sends the first Json data to the second functional domain controller; when it is determined that a subscription message and a response message are needed, the first message passing library module listens for the second Json data, and after the second Json data is detected, the first Json conversion module converts the second Json data into the second message data in the first format. Through the above solution, functional domain controllers using different programming languages can directly communicate with each other using protocol software development kits written in their respective programming languages, without the need to use middleware written in other programming languages on the functional domain side, reducing the development and debugging difficulties for functional domain developers.

[0028] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present application. Description of the Drawings

[0029] The drawings here are incorporated into the specification and form a part of the specification, showing embodiments consistent with the present application, and are used together with the specification to explain the principles of the present application. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts. In the drawings:

[0030] Figure 1 Shows a schematic structural diagram of a vehicle cross-domain communication system using middleware;

[0031] Figure 2 Shows a schematic structural diagram of a vehicle cross-domain communication system according to some embodiments of the present application;

[0032] Figure 3 A flowchart showing a method for vehicle cross - domain communication according to some embodiments of the application;

[0033] Figure 4 Shows Figure 3 A detailed schematic diagram of the first protocol software development kit in;

[0034] Figure 5 Shows Figure 3 A detailed schematic diagram of the second protocol software development kit in;

[0035] Figure 6 A block diagram showing a device for vehicle cross - domain communication according to some embodiments of the application;

[0036] Figure 7 A schematic structural diagram showing a functional domain controller according to some embodiments of the application. Detailed implementation manners

[0037] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without making creative efforts belong to the scope of protection of the present application.

[0038] In addition, the described features, structures or characteristics can be combined in any suitable manner in one or more embodiments. In the following description, many specific details are provided to give a full understanding of the embodiments of the present application. However, those skilled in the art will realize that the technical solutions of the present application can be practiced without one or more of the specific details, or other methods, components, devices, steps, etc. can be adopted. In other cases, well - known methods, devices, implementations or operations are not shown or described in detail to avoid obscuring various aspects of the present application.

[0039] The block diagrams shown in the drawings are only functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software form, or in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.

[0040] The flowcharts shown in the drawings are only exemplary illustrations, not necessarily including all the contents and operations / steps, nor necessarily executed in the described order. For example, some operations / steps can be decomposed, and some operations / steps can be combined or partially combined, so the actual execution order may change according to the actual situation.

[0041] It should also be noted that the terms "first", "second", etc. in the description, claims and the above-mentioned drawings of this application are used to distinguish similar objects, and do not necessarily have to be used to describe a specific order or sequence. It should be understood that the objects so used can be interchanged under appropriate circumstances, so that the embodiments of this application described here can be implemented in an order other than those illustrated or described.

[0042] To enable those skilled in the art to better understand this application, first, taking the first functional domain as the intelligent cockpit domain and the second functional domain as the intelligent driving domain as an example, the application scenarios involved in this application will be briefly described. It should be noted that the first functional domain controller in this application is not limited to the intelligent cockpit domain controller, and the second functional domain controller is not limited to the intelligent driving domain controller either. The first functional domain controller and the second functional domain controller can be any two functional domain controllers using different programming languages in a vehicle.

[0043] Figure 1 shows a schematic structural diagram of a system for vehicle cross-domain communication using middleware. As Figure 1 shown, Android applications in the domain controller (first functional domain controller) of the intelligent cockpit domain are usually written in the Java language, and programs in the domain controller (second functional domain controller) of the intelligent driving domain are usually written in the C++ language or the C language. To achieve communication between the intelligent cockpit domain and the intelligent driving domain, it is necessary to use the JNI middleware in the intelligent cockpit domain to adapt the programming languages. During the development and joint debugging of the intelligent cockpit domain, developers who know the Java language and developers who know the C++ language need to be equipped on the intelligent cockpit domain side. This makes the communication time cycle long, the development and debugging process slow, and the difficulty high.

[0044] Figure 2 shows a schematic structural diagram of a system for vehicle cross-domain communication according to some embodiments of this application. As Figure 2As shown, the programming language types used by the first functional domain controller and the second functional domain controller are different. The programming language of the Android application in the first functional domain controller is the Java language, and the programming language of the program in the second functional domain controller is the C++ or C language. The first functional domain controller is built-in with a first protocol software development kit, and the second functional domain controller is built-in with a second protocol software development kit. The first protocol software development kit includes a first Json conversion module and a first messaging library module, and the second protocol software development kit includes a second Json conversion module and a second messaging library module. Through this vehicle cross-domain communication system, the Android application layer can directly communicate with the counterpart components, reducing the use of middleware. During the development and joint debugging of the intelligent cockpit domain, only developers who know the Java language need to be equipped on the intelligent cockpit domain side, reducing the time cycle and difficulty of functional domain developers' development and debugging.

[0045] Figure 3 FIG. shows a schematic flow chart of a method for vehicle cross-domain communication according to some embodiments of the application. As Figure 3 shown, a method for vehicle cross-domain communication is provided. Taking the first functional domain controller in Figure 2 as an example for illustration, the method may include the following steps:

[0046] Step 301, when it is determined that a request message and a publish message are needed, convert the first message data in the first format into the first Json data through the first Json conversion module, and send the first Json data to the second functional domain controller through the first messaging library module;

[0047] Step 302, when it is determined that a subscription message and a response message are needed, listen for the second Json data through the first messaging library module, and after the second Json data is detected, convert the second Json data into the second message data in the first format through the first Json conversion module, where the second Json data is obtained by the second protocol software development kit converting the third message data in the second format.

[0048] Among them, the first functional domain controller may be an intelligent cockpit domain controller, and the programming language type of the first functional domain controller includes the Java language; the first functional domain controller may be a gateway domain controller, an intelligent driving domain controller, an instrument controller, etc., and the programming language type of the second functional domain controller includes the C++ language or the C language.

[0049] When the programming language type of the first functional domain controller includes the Java language, and the programming language type of the second functional domain controller includes the C++ language or the C language, the first message data in the first format is Java data, and the third message data in the second format is structure data. Correspondingly, in the case of determining that a request message and a publish message are needed, the first Java data can be converted into the first Json data through the first Json conversion module, and the first Json data can be sent to the second functional domain controller through the first message passing library module; in the case of determining that a response message and a subscribe message are needed, the second Json data can be listened for through the first message passing library module, and after the second Json data is listened for, the second Json data can be converted into the second Java data through the first Json conversion module; wherein, the second Json data is obtained by the second protocol software development kit converting the structure data. In addition, when the third functional domain controller subscribes to the messages of the first functional domain controller and the Java data of the first functional domain controller changes, the first functional domain controller can call back the changed Java data to the third functional domain controller.

[0050] The data formats returned by the request of the Json data protocol and the response of the protocol are globally common. The specific service parameters can be defined in data, and the parameters in data can be defined with reference to the protocol matrix table (Table 1):

[0051] Table 1

[0052]

[0053] In some embodiments, the first message passing library module includes the jeromq library, and the second message passing library module includes the cppzmq library or the libzmq library.

[0054] It can be understood that the jeromq library, the cppzmq library, and the libzmq library are all developed by the same company. By selecting the libraries developed by the same company, the communication compatibility and stability can be improved. Using the jeromq library for data transmission on the Java language side and using the cppzmq library or the libzmq library for data transmission on the C++ or C language side can meet vehicle communication scenarios such as request / response and publish / subscribe.

[0055] In some embodiments, the first Json conversion module can be implemented using a plugin, and this plugin can implement the mutual conversion between Json data and Java data; the second Json conversion module can also be implemented using a plugin, or can be implemented through a Python script, and the Python script is used to automatically implement the mutual conversion between the structure defined by the ECU and Json data.

[0056] In some embodiments, a message request instance and a message subscription instance corresponding to the second functional domain controller can be created according to the IP address and port number of the second functional domain controller; a message publishing instance and a message response instance corresponding to the first functional domain controller can be created according to the IP address and port number of the first functional domain controller; socket ports of the message request instance, the message subscription instance, the message publishing instance, and the message response instance can be respectively created through the first message passing library module.

[0057] It can be understood that all functional domain controllers can be connected to a local area network through Ethernet. This design allows all functional domain controllers to communicate through a unified IP address and port number, simplifies network configuration, and improves the efficiency and reliability of communication.

[0058] Figure 4 Shows Figure 3 A detailed schematic diagram of the first protocol software development kit in. As Figure 4 shown, the first protocol software development kit can be divided into an application layer, a proxy interface layer, a function implementation layer, and a network communication layer. Among them, the application layer includes a first Json conversion module and a communication IP management module. The first Json conversion module is used for Json data conversion, and the communication IP management module is used to manage the IP addresses and port numbers of all communication functional domain controllers; the function implementation layer includes a message request instance (MessageRequest), a message subscription instance (MessageSubscriber), a message publishing instance (MessagePublisher), and a message response instance (MessageResponse); the network communication layer includes the jeromq library, and each instance can create a corresponding socket interface through the jeromq library.

[0059] In some embodiments, in the case of a request message, the first Json data is sent to the second functional domain controller through the socket port of the message request instance; in the case of a published message, the first Json data is sent to the second functional domain controller through the socket port of the message publishing instance. In this way, the message is accurately sent to the corresponding functional domain controller.

[0060] In the case of subscribing to a message, the second Json data is listened for through the socket port of the message subscription instance; in the case of a response message, the second Json data is listened for through the socket port of the message response instance. In this way, the subscription and response to messages from other functional domain controllers are realized.

[0061] The following takes the first functional domain controller as the intelligent cockpit domain controller, the IP address of the network communication of the intelligent cockpit domain controller is 172.168.10.3, the port number as the server (responder) is 50000, and the port number as the client (publisher) is 50010; the second functional domain controller is the gateway domain controller, the IP address of the network communication of the gateway domain controller is 172.168.10.2, the port number as the server (responder) is 50000, and the port number as the client (publisher) is 50010 as an example, combined with Figure 4 to illustrate the communication process of the first functional domain controller.

[0062] S1: During initialization, according to the IP addresses and port numbers corresponding to each functional domain, different array containers (RequestList, PublishList, SubscriberList, ResponseerList) are created respectively to load the IP addresses and port numbers of the corresponding functional domain controllers.

[0063] S2: According to the IP addresses and port numbers in the array containers, if the functional domain controller is a client, a message request instance (MessageRequest) and a message subscription instance (MessageSubscriber) are created; if it is a server, a message publishing instance (MessagePublisher) and a message response instance (MessageResponse) are created.

[0064] S3: The corresponding instances use the jeromq library to create socket ports, specifically as follows:

[0065] 1. The message request instance establishes a communication network request-response connection with the gateway domain through createSocket(SocketType.REQ) and connect 172.168.10.2:50000;

[0066] 2. The message subscription instance creates 172.168.10.2:50010, and subscribes to the message publishing of the gateway domain through createSocket

[0067] (SocketType.Sub) and connect 172.168.10.2:50010;

[0068] 3. The message response instance processes requests from other functional domains, and creates a response server through createSocket

[0069] (SocketType.Rep) and bind 172.168.10.3:50010 to wait for connections from other functional domain clients;

[0070] 4. The message publishing instance creates a message publishing server through createSocket(SocketType.Pub) and bind

[0071] to 172.168.10.3:50010 and waits for other functional domain clients to connect.

[0072] S4: According to business requirements (for example, the cockpit user turns on the air conditioner), the service end finds the message request instance corresponding to the request gateway domain through the communication IP management module;

[0073] S5: According to business requirements (for example, publish the current navigation information), the service end finds the corresponding message publishing instance through the communication IP management module. After the message is published, the instrument, gateway domain, and intelligent driving domain can all subscribe to this message;

[0074] S6: Through the socket interface created by the message request instance and the message publishing instance, the request message of the intelligent cockpit domain controller can be sent and the transmitted message can be published;

[0075] S7: Continuously monitor the socket port created by the message subscription instance and the message response instance;

[0076] S8: Callback the monitored Json data to the first Json conversion module;

[0077] S9: Convert the Json data into the corresponding Java data through the first Json conversion module.

[0078] Figure 5 shows Figure 3 a detailed schematic diagram of the second protocol software development kit in. As Figure 5 shown, the second protocol software development kit includes a second Json conversion module, a communication address management module, a module responsible for communicating with the intelligent cockpit domain, a module responsible for communicating with the intelligent driving domain, and the cppzmq library.

[0079] In the second functional domain controller, the communication protocol matrix file can be obtained, the structure data type can be determined from the communication protocol matrix file, and the mapping relationship between the structure data type and the Json data type can be established to convert the structure data into Json data.

[0080] The following takes the first functional domain controller as the intelligent cockpit domain controller and the second functional domain controller as the intelligent driving domain controller as an example, and combines Figure 5 to illustrate the communication process and steps of the second functional domain controller:

[0081] S1: Define the communication address: std::vector <std::string>pubList, subList, repList, reqList; and add the IP address and port number of the corresponding functional domain controller;

[0082] S2: According to the IP address and port number in the vector container corresponding to each functional domain controller, if the functional domain controller acts as a client, create a message request instance (MessageReq) and a message subscription instance (MessageSub); if the functional domain controller acts as a server, create a message publication instance (MessagePub) and a message response instance (MessageRep);

[0083] S3: The corresponding instance uses the cppzmq library to create a socket port, specifically as follows:

[0084] 1. The message request instance creates zmq::socket_t req_socket(context, ZMQ_REQ) and connects to 172.168.10.3:50000 to establish a communication network request-response connection with the intelligent cockpit domain;

[0085] 2. The message subscription instance creates zmq::socket_t req_socket(context, ZMQ_SUB) and connects to 172.168.10.3:50010 to subscribe to the message publications of the intelligent cockpit domain;

[0086] 3. The message response instance processes requests from other functional domains through zmq::socket_t

[0087] req_socket(context, ZMQ_REP) and binds to 172.168.10.2:50010 to create a response server and wait for connections from other functional domain clients;

[0088] 4. The message publication instance creates a message publication server through createSocket(SocketType.Pub) & bind

[0089] 172.168.10.2:50010 and waits for connections from other functional domain clients.

[0090] S4: The inter-process communication module receives messages from other functional domain controllers using the same programming language through inter-process communication. The messages and the Json data automatically generated using a Python script can be converted through the nlohmann / json C++ version library. Then, the server instance of the opponent part is found by traversing the addresses in the vector container for data sending. Meanwhile, other functional domains listen for Json data through the socket ports created by the corresponding message subscription instances and message request instances. After the Json data is detected, the data is parsed according to the message protocol and forwarded and processed.

[0091] Through the above steps and designs, a complete communication solution such as communication IP management, communication link connection, data request / response, data publication / subscription, and data parsing can be achieved for direct communication among multiple functional domains. The Android application in direct contact with the user can directly communicate with the opponent part using the protocol software development kit written in the Java language, without modifying the framework and HAL layers on the Android side, which speeds up the development and debugging time cycle. Also, there is no need to use middleware written in other programming languages on the functional domain side, reducing the development and debugging difficulty for functional domain developers and achieving agile development.

[0092] The following describes the device embodiments of the present application, which can be used to execute the vehicle cross-domain communication method in the above embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the embodiments of the vehicle cross-domain communication method above.

[0093] Figure 6 A block diagram of a vehicle cross-domain communication device according to some embodiments of the application is shown. As Figure 6 As shown in the figure, the vehicle cross-domain communication device according to the embodiment of the present application is applied to the first functional domain controller of the vehicle. The programming language types of the first functional domain controller and the second functional domain controller of the vehicle are different. The first functional domain controller is built-in with a first protocol software development kit, and the second functional domain controller is built-in with a second protocol software development kit. The first protocol software development kit includes a first Json conversion module and a first message passing library module. The vehicle cross-domain communication device includes: a first message processing module 601, configured to, when it is determined that a request message and a publish message are required, convert first message data in a first format into first Json data through the first Json conversion module, and send the first Json data to the second functional domain controller through the first message passing library module; a second message processing module 602, configured to, when it is determined that a subscription message and a response message are required, listen for second Json data through the first message passing library module, and after the second Json data is listened for, convert the second Json data into second message data in a first format through the first Json conversion module, where the second Json data is obtained by converting third message data in a second format by the second protocol software development kit.

[0094] In some embodiments, the vehicle cross-domain communication device further includes a port creation module (not shown in the figure), configured to create a message request instance and a message subscription instance corresponding to the second functional domain controller according to the IP address and port number of the second functional domain controller; create a message publish instance and a message response instance corresponding to the first functional domain controller according to the IP address and port number of the first functional domain controller; create socket ports for the message request instance, the message subscription instance, the message publish instance, and the message response instance respectively through the first message passing library module.

[0095] In some embodiments, the first message processing module 601 is further configured to, when it is determined that a request message is required, send the first Json data to the second functional domain controller through the socket port of the message request instance; when it is determined that a publish message is required, send the first Json data to the second functional domain controller through the socket port of the message publish instance.

[0096] In some embodiments, the first message processing module 602 is further configured to, when it is determined that a subscription message is required, listen for second Json data through the socket port of the message subscription instance; when it is determined that a response message is required, listen for second Json data through the socket port of the message response instance.

[0097] In some embodiments, the programming language type of the first functional domain controller includes the Java language, the programming language type of the second functional domain controller includes the C++ language or the C language, the first message data in the first format is Java data, and the third message data in the second format is structure data.

[0098] In some embodiments, the first message passing library module includes the jeromq library, the second protocol software development kit includes the second message passing library module, and the second message passing library module includes the cppzmq library or the libzmq library.

[0099] Based on the same inventive concept, an embodiment of the present application further provides a functional domain controller. Refer to Figure 7 , which shows a schematic structural diagram of the functional domain controller in the embodiment of the present application. The functional domain controller includes one or more memories 704, one or more processors 702, and at least one computer program (computer program instructions) stored on the memory 704 and executable on the processor 702. When the processor 702 executes the computer program, the method described above is implemented.

[0100] Among them, in Figure 7 , the bus architecture (represented by bus 700), bus 700 may include any number of interconnected buses and bridges. Bus 700 links various circuits including one or more processors represented by processor 702 and memories represented by memory 704 together. Bus 700 can also link various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art, and thus will not be further described herein. The bus interface 705 provides an interface between the bus 700 and the receiver 701 and the transmitter 703. The receiver 701 and the transmitter 703 can be the same element, that is, a transceiver, which provides a unit for communicating with various other devices on the transmission medium. The processor 702 is responsible for managing the bus 700 and general processing, while the memory 704 can be used to store data used by the processor 702 when performing operations.

[0101] Based on the same inventive concept, an embodiment of the present application provides a computer-readable storage medium. Computer program instructions are stored in the computer-readable storage medium. When the computer program instructions are executed by a processor, the processor is caused to implement the steps of the method described above.

[0102] Based on the same inventive concept, an embodiment of the present application provides a computer program product, including a computer program. When the computer program product is executed by a processor, the processor is caused to implement the steps of the method described above.

[0103] Based on the same inventive concept, the embodiments of the present application provide a vehicle cross-domain communication system, including the above-mentioned functional domain controller and the second functional domain controller of the vehicle. The programming language types of the functional domain controller and the second functional domain controller are different. The first functional domain controller is built-in with a first protocol software development kit, and the first functional domain controller is built-in with a second protocol software development kit. The first protocol software development kit includes a first Json conversion module and a first message passing library module, and the second protocol software development kit includes a second Json conversion module and a second message passing library module.

[0104] In some embodiments, the functional domain controller is an intelligent cockpit domain controller, and the second functional domain controller is a gateway domain controller, an intelligent driving domain controller, or an instrument controller.

[0105] Through the above vehicle cross-domain communication system, the communication architecture between multiple domains inside the vehicle is simplified, the use of middleware is reduced, the complexity and maintenance cost of the system are avoided from being reduced, and the application layer of the first functional domain controller can directly communicate with the counterparty across functional domains, reducing the communication participants, thereby reducing the communication difficulty and making signal troubleshooting more direct and efficient.

[0106] The functions described herein can be implemented in hardware, software executed by a processor, firmware, or any combination thereof. If implemented in software executed by a processor, the functions can be stored on or transmitted via a computer-readable medium as one or more instructions or codes. Other examples and implementations are within the scope and spirit of the present application and the appended claims. For example, due to the nature of software, the functions described above can be implemented using software executed by a processor, hardware, firmware, hardwiring, or any combination of these. In addition, each functional unit can be integrated in one processing unit, or can exist physically separately for each unit, or two or more units can be integrated in one unit.

[0107] In several embodiments provided in the present application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are merely illustrative. For example, the division of the units can be a logical function division. In actual implementation, there can be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection to each other can be through some interfaces, and the indirect coupling or communication connection of units or modules can be in an electrical or other form.

[0108] The unit described as a separation component may or may not be physically separated. The component serving as a control device may or may not be a physical unit, that is, it may be located in one place or may be distributed over multiple units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0109] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of this application. The foregoing storage medium includes: various media such as USB flash drives, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), mobile hard disks, magnetic disks, or optical discs that can store computer program instructions.

[0110] The above are only the embodiments of this application and are not used to limit this application. For those skilled in the art, this application can have various changes and modifications. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this application shall be included within the scope of the claims of this application.< / std::string>

Claims

1. A vehicle cross-domain communication method, applied to a first functional domain controller of a vehicle, characterized in that: The first functional domain controller and the second functional domain controller of the vehicle have different programming language types, the first functional domain controller has a built-in first protocol software development kit, the second functional domain controller has a built-in second protocol software development kit, the first protocol software development kit includes a first Json conversion module and a first message passing library module, and the method includes: In the case where it is determined that a request message and a publish message are required, the first message data in the first format is converted into first Json data through the first Json conversion module, and the first Json data is sent to the second functional domain controller through the first message delivery library module; When it is determined that subscription messages and response messages are required, the second Json data is listened to through the first message passing library module, and after listening to the second Json data, the second Json data is converted into the second message data in the first format through the first Json conversion module, wherein the second Json data is obtained after the second protocol software development kit converts the third message data in the second format.

2. The vehicle cross-domain communication method according to claim 1, characterized in that: Before converting the first message data in the first format into the first Json data by the first Json conversion module or monitoring the second Json data by the first message delivery library module, the method further includes: According to the IP address and port number of the second functional domain controller, create a message request instance and a message subscription instance corresponding to the second functional domain controller; According to the IP address and port number of the first functional domain controller, create a message publishing instance and a message response instance corresponding to the first functional domain controller; The socket ports of the message request instance, the message subscription instance, the message publishing instance and the message response instance are respectively created through the first message passing library module.

3. The vehicle cross-domain communication method according to claim 2, characterized in that: The sending the first Json data to the second functional domain controller through the first message transfer library module includes: In the case where it is determined that a request message is needed, the first Json data is sent to the second functional domain controller through the socket port of the message request instance; When it is determined that a message needs to be published, the first Json data is sent to the second functional domain controller through the socket port of the message publishing instance.

4. The vehicle cross-domain communication method according to claim 2, characterized in that: In the case where it is determined that a subscription message and a response message are required, monitoring the second Json data through the first message delivery library module includes: When it is determined that a message subscription is required, the second Json data is listened to through the socket port of the message subscription instance; When it is determined that a response message is needed, the second Json data is listened to through the socket port of the message response instance.

5. The vehicle cross-domain communication method according to any one of claims 1 to 4, characterized in that: The programming language type of the first functional domain controller includes Java language, the programming language type of the second functional domain controller includes C++ language or C language, the first message data in the first format is Java data, and the third message data in the second format is structure data.

6. The vehicle cross-domain communication method according to claim 5, characterized in that: The first message passing library module includes a jeromq library, the second protocol software development kit includes a second message passing library module, and the second message passing library module includes a cppzmq library or a libzmq library.

7. A vehicle cross-domain communication device, applied to a first functional domain controller of a vehicle, characterized in that: The programming language type of the first functional domain controller is different from that of the second functional domain controller of the vehicle. The first functional domain controller has a built-in first protocol software development kit, and the second functional domain controller has a built-in second protocol software development kit. The first protocol software development kit includes a first Json conversion module and a first message passing library module. The device includes: A first message processing module is used to convert the first message data in the first format into first Json data through the first Json conversion module when it is determined that a request message and a publish message are required, and send the first Json data to the second functional domain controller through the first message delivery library module; The second message processing module is used to monitor the second Json data through the first message delivery library module when it is determined that subscription messages and response messages are needed, and after monitoring the second Json data, convert the second Json data into the second message data in the first format through the first Json conversion module, wherein the second Json data is obtained after the second protocol software development kit converts the third message data in the second format.

8. A functional domain controller, comprising a processor and a memory, characterized in that: The memory stores computer program instructions that can be executed by the processor, and when the processor executes the computer program instructions, the steps of the method according to any one of claims 1 to 6 are implemented.

9. A vehicle cross-domain communication system, characterized in that: It includes a functional domain controller according to claim 8 and a second functional domain controller of a vehicle, wherein the functional domain controller and the second functional domain controller have different programming language types, the first functional domain controller has a built-in first protocol software development kit, the first functional domain controller has a built-in second protocol software development kit, the first protocol software development kit includes a first Json conversion module and a first message passing library module, and the second protocol software development kit includes a second Json conversion module and a second message passing library module.

10. The vehicle cross-domain communication system according to claim 9, characterized in that: The functional domain controller is an intelligent cockpit domain controller, and the second functional domain controller is a gateway domain controller, an intelligent driving domain controller or an instrument controller.