CN116709265A

CN116709265A - Vehicle-mounted communication method, device, equipment and storage medium

Info

Publication number: CN116709265A
Application number: CN202310695813.6A
Authority: CN
Inventors: 于政洋; 白平; 马光晖
Original assignee: Ecarx Hubei Tech Co Ltd
Current assignee: Ecarx Hubei Tech Co Ltd
Priority date: 2023-06-12
Filing date: 2023-06-12
Publication date: 2023-09-05

Abstract

The embodiment of the application provides a vehicle-mounted communication method, a device, equipment and a storage medium. The method comprises the following steps: transmitting a message of a target application program of the plurality of application programs to a service agent process based on the inter-process communication; encapsulating the message into a first SOME/IP message through a service agent process, and determining a first client among a plurality of clients, the first client being a client capable of sending the SOME/IP message from the target application; and sending a first SOME/IP message to a first service end through the first client, wherein the first service end is a service end which establishes connection with the first client, and the first service end operates in second vehicle-mounted equipment. Therefore, the deployment of SOME/IP is simplified, and memory resources occupied by configuration information generated by deploying SOME/IP are reduced.

Description

Vehicle-mounted communication method, device, equipment and storage medium

Technical Field

The present application relates to the field of vehicle ethernet technologies, and in particular, to a vehicle communication method, device, equipment, and storage medium.

Background

The service oriented architecture (service oriented architecture, SOA for short) can be applied to a vehicle system, and the SOA can enable communication and services among a plurality of vehicle-mounted devices in a vehicle to be more flexible and convenient. In an SOA, in-vehicle communication between in-vehicle devices may be performed through an IP-based extensible service-oriented middleware (soap/IP) protocol.

In SOME implementations, when a message of an application program is transmitted between the vehicle-mounted devices through a SOME/IP protocol, the vehicle-mounted devices need to convert the message of the application program into a SOME/IP message, transmit the SOME/IP message to a corresponding server (or client) through the SOME/IP protocol, and then transmit the SOME/IP message to other vehicle-mounted devices through the server or the client.

However, in the above implementation, the application program installed in the vehicle-mounted device needs to be preconfigured with a Server (Server) and a Client (Client) for transmitting the SOME/IP message, and also needs to preconfigured with information that the application program communicates with a corresponding Server or Client through the SOME/IP protocol, so that the configuration is complex, and the configuration information needs to occupy a large amount of memory resources.

Disclosure of Invention

The embodiment of the application provides a vehicle-mounted communication method, a device, equipment and a storage medium, which simplify the deployment of SOME/IP and lead the memory resources occupied by configuration information to be less.

In a first aspect, an embodiment of the present application provides a vehicle-mounted communication method, applied to a first vehicle-mounted device, where a service agent process, a plurality of application programs, a plurality of clients, and a plurality of service terminals are running in the first vehicle-mounted device, where the number of clients and the number of service terminals are both less than the number of application programs, the vehicle-mounted communication method includes:

transmitting a message of a target application program of the plurality of application programs to the service agent process based on inter-process communication;

encapsulating the message into a first SOME/IP message by the service proxy process, and determining a first client among a plurality of clients, the first client being a client that can send SOME/IP messages from the target application;

and sending the first SOME/IP message to a first service end through the first client, wherein the first service end is a service end which establishes connection with the first client, and the first service end operates in second vehicle-mounted equipment.

In a possible implementation manner, the first vehicle-mounted device stores a corresponding relationship between a client in the first vehicle-mounted device and an identifier of an application program; the determining a first client among a plurality of clients includes: and determining the first client from a plurality of clients in the service agent process according to the identification of the target application program carried in the message.

In a possible implementation manner, the first vehicle-mounted device stores first information, the first information includes first data and a first program, the first data and the first program are used for generating Protobuf messages from messages of the plurality of application programs, the first data and the first program are both generated by Protobuf files, and a program language of the Protobuf messages generated by the first data and the first program is preset.

In one possible implementation, the message is a Protobuf message.

In a possible implementation manner, after the first client sends the first SOME/IP message to the first service end, the method includes: and receiving a second SOME/IP message by the first client, wherein the second SOME/IP message is a message returned by the second vehicle-mounted equipment through the first server in response to the first SOME/IP message.

In a possible implementation manner, after the receiving, by the first client, the second SOME/IP message, the method includes: analyzing the second SOME/IP message to obtain a target Protobuf message and the identification of a target application program; according to the identification of the target application program, calling back the target application program based on inter-process communication, and transmitting the target Protobuf message to the target application program; analyzing the target Protobuf message through target information corresponding to the target Protobuf message to obtain message content, wherein the target information comprises a target program for analyzing the target Protobuf message, and the target program is generated by a Protobuf file.

In a possible implementation manner, a third SOME/IP message is received through a second server, where the third SOME/IP message is sent by a third vehicle device through a second client, and the second server establishes a connection with the second client.

In a possible implementation manner, when detecting that there is a new application program, generating and storing a corresponding relation between an identifier of the new application program and a third server side and a third client side in the first vehicle-mounted device;

And/or the number of the groups of groups,

when the newly added application program is detected, generating and storing second information, wherein the second information comprises second data and a second program, the second data and the second program are used for generating Protobuf information from the information of the newly added application program, and the second data and the second program are generated by Protobuf files.

In a second aspect, an embodiment of the present application provides an in-vehicle communication apparatus including:

the transmission module is used for transmitting the information of the target application program in the plurality of application programs to the service agent process based on the inter-process communication;

the processing module is used for packaging the message into a first SOME/IP message through the service agent process and determining a first client from a plurality of clients, wherein the first client is a client capable of sending the SOME/IP message from the target application program;

the transmission module is further configured to send, through the first client, the first SOME/IP message to a first service end, where the first service end is a service end that establishes a connection with the first client, and the first service end operates in a second vehicle-mounted device.

In a possible implementation manner, the first vehicle-mounted device stores a corresponding relationship between a client in the first vehicle-mounted device and an identifier of an application program; the processing module is specifically configured to determine the first client from a plurality of clients in the service proxy process according to the identifier of the target application program carried in the message.

In one possible implementation, the message is a Protobuf message.

In a possible implementation manner, the apparatus further includes a receiving module, configured to receive, by the first client, a second SOME/IP message, where the second SOME/IP message is a message returned by the second on-board device through the first server in response to the first SOME/IP message.

In a possible implementation manner, the processing module is further configured to parse the second SOME/IP message to obtain a target Protobuf message and an identifier of a target application program; according to the identification of the target application program, calling back the target application program based on inter-process communication, and transmitting the target Protobuf message to the target application program; analyzing the target Protobuf message through target information corresponding to the target Protobuf message to obtain message content, wherein the target information comprises a target program for analyzing the target Protobuf message, and the target program is generated by a Protobuf file.

In a possible implementation manner, the receiving module is further configured to receive a third SOME/IP message through a second server, where the third SOME/IP message is sent by a third vehicle device through a second client, and the second server establishes a connection with the second client.

In a possible implementation manner, the processing module is further configured to generate and store a correspondence between an identifier of the newly added application program and a third server and a third client in the first vehicle-mounted device when the newly added application program is detected; and/or when the newly added application program is detected, generating and storing second information, wherein the second information comprises second data and a second program, the second data and the second program are used for generating Protobuf information from the information of the newly added application program, and the second data and the second program are both generated by Protobuf files.

In a third aspect, an embodiment of the present application further provides an electronic device, including: a processor, and a memory communicatively coupled to the processor;

the memory stores computer-executable instructions;

the processor executes computer-executable instructions stored in the memory to implement the method as described in any one of the possible implementations of the first aspect.

In a fourth aspect, an embodiment of the present application further provides a computer readable storage medium, where computer executable instructions are stored, and when executed by a processor, implement the method described in any one of the possible implementation manners of the first aspect.

In a fifth aspect, embodiments of the present application further provide a computer program product comprising a computer program which, when executed by a processor, implements a method as described in any one of the possible implementations of the first aspect.

It can be seen that the embodiments of the present application provide a vehicle-mounted communication method, apparatus, device and storage medium, where the vehicle-mounted communication method is applied to a first vehicle-mounted device, and a service agent process, a plurality of application programs, a plurality of clients and a plurality of service terminals are running in the first vehicle-mounted device, and the number of clients and the number of service terminals are less than the number of application programs, and the vehicle-mounted communication method may include: transmitting a message of a target application program of the plurality of application programs to a service agent process based on the inter-process communication; encapsulating the message into a first SOME/IP message through a service agent process, and determining a first client among a plurality of clients, the first client being a client capable of sending the SOME/IP message from the target application; and sending a first SOME/IP message to a first service end through the first client, wherein the first service end is a service end which establishes connection with the first client, and the first service end operates in second vehicle-mounted equipment. Since the number of clients and the number of servers are smaller than the number of applications, the plurality of applications in the first device may use the same client or the same server to communicate. And the communication between the first devices is realized through inter-process communication without SOME/IP protocol, so that the deployment of SOME/IP is simplified, and the memory resources occupied by the configuration information of the vehicle-mounted communication can be reduced.

Drawings

Fig. 1 is a schematic structural diagram of a vehicle-mounted communication SOA architecture according to an embodiment of the present application;

FIG. 2 is a schematic diagram of another vehicle-mounted communication SOA architecture according to an embodiment of the present application;

fig. 3 is a schematic flow chart of a vehicle-mounted communication method according to an embodiment of the present application;

fig. 4 is a schematic diagram of a constitution of a SOME/IP message header according to an embodiment of the present application;

FIG. 5 is a schematic workflow diagram of a first vehicle-mounted device according to an embodiment of the present application;

fig. 6 is a schematic structural diagram of a vehicle-mounted communication device according to an embodiment of the present application;

fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Specific embodiments of the present disclosure have been shown by way of the above drawings and will be described in more detail below. These drawings and the written description are not intended to limit the scope of the disclosed concepts in any way, but rather to illustrate the disclosed concepts to those skilled in the art by reference to specific embodiments.

Detailed Description

In order to facilitate the clear description of the technical solutions of the embodiments of the present application, the following simply describes some terms and techniques involved in the embodiments of the present application:

SOA: loosely coupled coarse-grained application components may be distributed deployed, combined, and used across a network as desired.

SOME/IP: the method can be used for middleware in the automobile industry and one of the protocols of the SOA is realized.

Automobile open system architecture (Automotive Open System Architecture, autoSar for short): a standardized automobile software architecture developed mainly consists of an application layer (Applincation layer), an operating environment (Run TimeEnvironment, RTE), a service operating system layer (Basic Software layer, BSW layer), and electronic control unit hardware (Electronic Control Unit hardware, ECU hardware).

Google remote procedure call (google Remote Procedure Call, abbreviated as GRPC): a high-performance, generic, open-source remote procedure call (Remote Procedure Call, RPC) framework, designed primarily for mobile application development and based on the HTTP/2 protocol standard, while supporting most popular programming languages.

Protobuf: is a short name of Protocol Buffers, a data description language, for describing a lightweight and efficient structured data storage format.

Inter-process communication (Inter-Process Communication, IPC): refers to the interaction that occurs between the data of two processes.

Remote procedure call (Remote Procedure Call, RPC for short): inter-process handling method procedure calls on two independent Operating systems (OS for short).

An electronic control unit (Electronic Control Unit, ECU for short): the computer is also called as a travelling computer, a vehicle-mounted computer and the like, and consists of a microcontroller and a peripheral circuit.

In-vehicle infotainment system (In-Vehicle Infotainment, abbreviated to IVI): the vehicle-mounted comprehensive information processing system is formed by adopting a vehicle-mounted special central processing unit based on a vehicle body bus system and Internet service.

A vehicle body control computing system (Car Central Computing, CCC for short): for controlling and monitoring the state of the vehicle body, for example, the opening and closing state of the door, the opening and closing state of the window, and the like.

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples are not representative of all implementations consistent with the present disclosure. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present disclosure as detailed in the accompanying claims.

In embodiments of the present application, "at least one" means one or more, and "a plurality" means two or more. "and/or", describes an association relationship of an association object, and indicates that there may be three relationships, for example, a and/or B, and may indicate: there are three cases, a alone, a and B together, and B alone, wherein a, B may be singular or plural. In the text description of the present application, the character "/" generally indicates that the front-rear associated object is an or relationship.

The Some/IP protocol is a communication protocol of the vehicle-mounted Ethernet proposed by AutoSar. SOME/IP can send messages when the receiver has a need, which is a service-oriented data communication mode. The Some/IP is applied to the SOA in the vehicle, so that the vehicle-mounted communication is more convenient. The open source project vsomeip in the open source community can realize the name/IP protocol, the automation tool of the vsomeip can automatically generate corresponding codes according to the name/IP matrix, and a large number of name/IP protocol stack suppliers also appear in the market.

In SOME implementations, when a message of an application program is transmitted between the vehicle-mounted devices through a SOME/IP protocol, the vehicle-mounted devices need to convert the message of the application program into a SOME/IP message, transmit the SOME/IP message to a corresponding server (or client) through the SOME/IP protocol, and then transmit the SOME/IP message to other vehicle-mounted devices through the server or the client. Thus, the related personnel need to configure the communication inside the device and the SOME/IP communication between the devices in advance through the vsomeip. For example, a Server and a Client (Client) for performing SOME/IP message transmission are preconfigured for each application in the device, and information that an application communicates with its corresponding Server or Client through the SOME/IP protocol is also required to be preconfigured.

However, the configuration process by vsomeip is complex, and multiple applications may be included in the device, so that the configuration of the SOME/IP communication by vsomeip is more complex, and a large amount of configuration information may be generated, which occupies more memory resources and may affect the operation of the device.

Based on this, the embodiment of the application provides a vehicle-mounted communication method, communication between devices, namely communication between an application program and a service agent process in the device is performed through inter-process communication IPC, and a fixed connection can be established between a server side and a client side of two vehicle-mounted devices in a vehicle, so that a plurality of application programs can use the same server side or the same client side to communicate with another vehicle-mounted device. Therefore, communication between devices is realized through IPC, communication between devices is realized through SOME/IP protocol, a corresponding service end and a corresponding client end are not required to be configured for each application program, when new application programs are added, the newly added application programs can also use the original client end and service end to communicate with other vehicle-mounted devices, so that the deployment of SOME/IP is simplified, and the memory resources occupied by configuration information are reduced.

It should be noted that, the vehicle-mounted communication method provided by the embodiment of the present application is applied to a first vehicle-mounted device of a vehicle-mounted communication system, and the vehicle-mounted communication system may further include a plurality of vehicle-mounted devices such as a second vehicle-mounted device and a third vehicle-mounted device. Different vehicle-mounted communication systems can run different operating systems for realizing different functions, for example, a vehicle-mounted device A of the vehicle-mounted communication system is used for realizing an entertainment function, a vehicle-mounted device B user realizes a vehicle body control function, and a vehicle-mounted device C user realizes a vehicle navigation function. The embodiment of the application does not limit the functions realized by the vehicle.

Fig. 1 is a schematic structural diagram of a vehicle-mounted communication SOA architecture according to an embodiment of the present application.

As shown in fig. 1, the in-vehicle apparatus 1 operates an in-vehicle infotainment system IVI, and the in-vehicle apparatus 2 operates a vehicle body control computing system. The vehicle-mounted device 1 is provided with a service agent process serviceproxyService1, a service management module Servers Manager1, an application program A, an application program B, an application program C, a client 1, a client 2, a server 1 and a server 2. The vehicle-mounted device 2 is provided with a service agent process serviceproxyService2, a service management module Servers Manager2, an application program D, an application program E, an application program F, a client 3, a client 4, a server 3 and a server 4.

The serviceproxyService1 is used for encapsulating the message of the application program in the vehicle-mounted device 1 into a SOME/IP message, and the serviceproxyService2 is used for encapsulating the message of the application program in the vehicle-mounted device 2 into a SOME/IP message. The Servers Manager1 may be used to manage correspondence between the Servers, clients, and application programs in the in-vehicle apparatus 1. The Servers Manager2 may be used to manage correspondence between the Servers, clients, and application programs in the in-vehicle apparatus 2.

The function of the application program in the in-vehicle device is related to the system installed in the in-vehicle device, and if the IVI is installed in the in-vehicle device, the application program in the in-vehicle device may be an application program of in-vehicle entertainment, for example, a music application program, a telephone application program, etc., which is not particularly limited in the embodiment of the present application. If the vehicle-mounted device is provided with the CCC system, the application program in the vehicle-mounted device may be an application program of a vehicle body control type, for example, window control, door control, etc., and the embodiment of the application is not particularly limited.

The client side in the vehicle-mounted equipment is used for calling the message, and the server side in the vehicle-mounted equipment is used for sending the feedback message.

As shown in fig. 1, a connection is established between a client 1 and a server 3, a connection is established between a client 2 and a server 4, a connection is established between a client 3 and a server 1, and a connection is established between a client 4 and a server 2.

Illustratively, client 1 and server 1 may be configured to transmit information related to application A and application B, and client 2 and server 2 may be configured to transmit information related to application C. The client 3 and the server 3 may be configured to transmit information related to the application D and the application E, and the client 4 and the server 4 may be configured to transmit information related to the application F.

It can be understood that the correspondence between the client, the server and the application may be preconfigured by related personnel, or may be automatically generated by the vehicle-mounted device according to information of the client, the server and the application, for example, the plurality of applications may be set to sequentially set the correspondence according to serial numbers of the server and the client, so when there are 5 applications in the vehicle-mounted device and 2 clients and two servers are set, two clients use the same client and the same server, and another 3 applications use the same client and the same server. The embodiment of the application does not limit the corresponding relation of the client, the server and the application program in detail.

In fig. 1, an application program a, an application program B and an application program C can all communicate with ServiceProxyService1 through an IPC interface, and an application program D, an application program E and an application program F can all communicate with ServiceProxyService2 through an IPC interface.

Based on the illustration in fig. 1, when the in-vehicle device 1 sends the message of the application program a to the in-vehicle device 2, the message of the application program a may be transmitted to the ServiceProxyService1 through the IPC interface, and the ServiceProxyService1 may package the message into an SOME/IP message, and may query the server Manager1 for the client 1 or the server corresponding to the application program a.

The message of the application a may be a request message, for example, a Method message, a subscription request message, or the like, or may be a feedback message, for example, a subscription feedback message, a request feedback message, or the like, which is not limited in the embodiment of the present application. Thus, there may be two possible implementations of the method in which the in-vehicle apparatus 1 transmits the message of the application program a to the in-vehicle apparatus 2:

in a possible implementation, when the message of the application program a is a request message, the vehicle-mounted device 1 may query the Servers Manager1 for the client 1 corresponding to the application program a through the ServiceProxyService1, and transmit the SOME/IP message to the server 3 of the vehicle-mounted device 2 through the client 1, so as to request the vehicle-mounted device 2 for the required information.

In another possible implementation, when the message of the application program a is a feedback message, the vehicle-mounted device 1 may query the server Manager1 for the service end 1 corresponding to the application program a through the ServiceProxyService1, and transmit the SOME/IP message to the client 3 of the vehicle-mounted device 2 through the service end 1, so as to feed back the required information to the vehicle-mounted device 2.

It is to be understood that, the method for the application program in the in-vehicle apparatus 2 to send the message to the in-vehicle apparatus 1 is similar to the method for the application program in the in-vehicle apparatus 1 to send the message to the in-vehicle apparatus 2, and will not be described herein.

The in-vehicle apparatus 1 in fig. 1 may be one ECU in the vehicle, and the in-vehicle apparatus 2 may be one ECU in the vehicle.

In order to facilitate understanding of the above-described vehicle-mounted communication SOA architecture shown in fig. 1, a system IVI is installed in one vehicle-mounted device, and a system CCC is installed in another vehicle-mounted device, for example, to describe the vehicle-mounted communication SOA architecture in detail. Fig. 2 is a schematic diagram of another communication SOA architecture according to an embodiment of the present application.

As shown in FIG. 2, the system IVI runs a music Server, a phone Server, a video Server, a Vehicle HAL, a ServiceProxyService, a Servers Manager, an IVI Server1, an IVI Server2, a CCC Client1, and a CCC Client2. The system IVI is operated with windows Server, dos Server, seats Server, HAV Server, serviceProxyservice, server Manager, IVI Client1, IVI Client2, CCC Server1, CCC Server2.

The Vehicle HAL is a hardware abstraction layer module of Android Automotive OS, which can be used for setting and receiving Vehicle body control related signals. The music Server, phone Server, video Server, vehicle HAL, windows Server, dos Server, services Server, HAV Server may be regarded as different applications, respectively. IVI Server1 and IVI Server2 are the servers in system IVI for transmitting SOME/IP messages into system CCC, CCC Client1 and CCC Client2 are the clients in system IVI for calling information in system CCC. IVI Client1 and IVI Client2 are clients in the system CCC for calling information in the system IVI, and CCC Client1 and CCC Client2 are servers in the system CCC for transmitting SOME/IP messages into the system IVI.

As shown in fig. 2, 4 paths which can be double in and double out are fixedly established between the IVI and the CCC, and the SOME/IP communication between the IVI and the CCC is realized through the four established paths.

The SOME/IP communication between IVI and CCC may be described with reference to the SOME/IP communication between the first and second vehicle-mounted devices in FIG. 1 and will not be described again.

For example, AAA Client and BBB Client in system IVI may be newly added applications, XXX Client1 and YYY Client2 may be newly added clients, or clients used in interacting with other in-vehicle devices. XXX Server in system CCC can be newly added application program, XXX Client1 and YYY Client2 can be newly added Client, or Client used when interacting with other vehicle-mounted equipment. The newly added application programs, clients and the like are newly added application programs needed in the vehicle use process, and when the number of the application programs is large, the newly added client can be configured for the newly added application programs. Of course, a server may be added to the system, which is not limited in the embodiment of the present application.

When an application program, a client or a server is newly added in the system, the vehicle-mounted equipment can generate a corresponding relation related to the newly added application program, the newly added client or the newly added server, and the newly added corresponding relation is managed through Servers Manager.

It should be noted that, the system IVI in fig. 2 may be one ECU in the vehicle, and the system CCC may be one ECU in the vehicle.

It should be noted that, the vehicle-mounted communication SOA architecture shown in fig. 1 and fig. 2 may include a plurality of vehicle-mounted devices, and fig. 1 and fig. 2 only illustrate that the vehicle-mounted communication SOA architecture includes 2 vehicle-mounted devices, which is not limited in number.

Based on the above-mentioned vehicular communication SOA architecture shown in fig. 1 and fig. 2, the vehicular communication method provided by the present application will be described in detail below through a specific embodiment. It is to be understood that the following embodiments may be combined with each other and that some embodiments may not be repeated for the same or similar concepts or processes.

Fig. 3 is a schematic flow chart of a vehicle-mounted communication method according to an embodiment of the present application. The in-vehicle communication method may be performed by software and/or hardware means, for example, the hardware means may be an in-vehicle communication device, which may be a first in-vehicle apparatus in an SOA architecture or a processing chip in the first in-vehicle apparatus.

In the embodiment of the application, the first vehicle-mounted device is provided with a service agent process, a plurality of application programs, a plurality of clients and a plurality of service terminals, wherein the number of the clients and the number of the service terminals are less than the number of the application programs. For example, the first vehicle-mounted device may be the vehicle-mounted device 1 or the vehicle-mounted device 2 in fig. 1 described above, or the vehicle-mounted device in fig. 2 in which the system IVI is installed, or the vehicle-mounted device in which the system CCC is installed, which is not limited by the embodiment of the present application.

As shown in fig. 3, the vehicle-mounted communication method may include:

s301, transmitting a message of a target application program in a plurality of application programs to a service agent process based on inter-process communication.

The application program may be a music application program, a telephone application program, a car body control application program, etc., and the embodiment of the application is not limited thereto.

The message of the target application may be a request message, such as a Method message or a subscription request message, in which the target application requests information from other in-vehicle devices. The message of the target application may also be an event message. The message of the target application program is not particularly limited in the embodiment of the application.

The service agent process may be ServiceProxyService in fig. 1 or fig. 2 described above.

For example, the first vehicle device may transmit the message of the target application to ServiceProxyService through the IPC interface based on the IPC interface of ServiceProxyService. The internal IPC interface can be adapted on the ServiceProxyService through data message transfer processing, so that the interface developed by the upper application layer has uniformity.

S302, the message is packaged into a first SOME/IP message through a service agent process, and a first client is determined from a plurality of clients.

The first client is a client that can send a SOME/IP message from the target application.

For example, a pre-configured program for encapsulating a message into a SOME/IP message may be included in a service broker process of the first on-board device, such that the first on-board device encapsulates the message into the first SOME/IP message via the pre-configured program in the service broker process.

In the embodiment of the application, the first vehicle-mounted equipment stores the corresponding relation between the client in the first vehicle-mounted equipment and the identification of the application program.

For example, a service management module server Manager may be running in the first vehicle device, and a correspondence between the client in the first vehicle device and the identifier of the application program may be stored in the service management module server Manager.

In one possible implementation, the message of the target application may carry the identifier of the target application. When the first on-board device determines the first client from among the plurality of clients, the first on-board device may determine the first client from among the plurality of clients in the service broker process according to the identification of the target application program carried in the message. For example, the target application program identifier carried in the message is ABC, and the corresponding relationship between ABC and the first client X is stored in the first vehicle-mounted device, so that the first client X can be determined from a plurality of clients according to ABC.

Therefore, the related personnel only need to preset the corresponding relation between the identification of the application program and the client, and personalized configuration is not needed for each application program, so that SOME/IP configuration can be simplified. And when the newly added application program exists, the pairing of the newly added application program and the client can be realized only by registering the identification of the newly added application program and the corresponding service management module server Manager of the client in the first vehicle-mounted equipment.

S303, sending a first SOME/IP message to the first service terminal through the first client terminal.

The first server is a server which establishes connection with the first client, and the first server operates in the second vehicle-mounted device.

Illustratively, the first on-board device may send a first SOME/IP message to the first server via the first client based on a SOME/IP protocol.

Based on the above, the vehicle-mounted communication method provided by the embodiment of the application can realize that a plurality of application programs use the same client or the same server, personalized configuration is not needed for the application programs, and the application programs and the service agent processes are carried out through IPC interfaces. Therefore, the SOME/IP configuration is simplified, the system memory resources occupied by personalized configuration of the application program are reduced, and when the vehicle-mounted devices communicate with each other, the consumption of the system resources can be effectively reduced, and the network data for maintaining communication in the network is reduced, so that the consumption of network bandwidth is reduced.

In the embodiment of the application, the message body of the Method message or the Event message transmitted by SOME/IP communication can use a variable-length binary message body. Fig. 4 is a schematic diagram of a constitution of a SOME/IP message header according to an embodiment of the present application.

As shown in fig. 4, the Message ID is used to uniquely identify the Message, and may be composed of a Service ID (identification of an application program) or a Message ID Method when the Message is of a Method type, or a Service ID or a Message ID Event when the Message is of an Event type. 32 bits are the length of the Message ID. The SOME/IP message of the embodiment of the application is not limited by the fact that the message is a Method type message only in FIG. 4.

Length represents the message Length. The Request ID is a different call that can be used by the Service provider Service and caller Client to distinguish the same message, and consists of a Client ID and a Session ID. The Client ID is a Client ID, distinguishes clients or subscribers, and has uniqueness in the whole vehicle. Session ID is a Session ID that distinguishes multiple requests or messages for the same client or subscriber.

Version is a protocol Version number, and MessageType is used to indicate the type of message or the type of message, in AUTOSAR, 5 types are used: REQUEST, REQUEST _NO_ RETURN, NOTIFICATION, RESPONSE, ERROR. Return code is the event return code. Payload is a Payload or data segment containing the relevant data that needs to be transmitted.

In the embodiment of the present application, first information may be stored in the first vehicle-mounted device, where the first information includes first data and a first program, the first data and the first program are used to generate Protobuf messages from messages of a plurality of application programs, the first data and the first program are both generated by Protobuf files, and a program language of the Protobuf messages generated by the first data and the first program is preset.

Since the protobuf item of the open source supports multiple languages, a code of a preset program language can be automatically generated. Therefore, the related personnel can preset the programming language of the Protobuf project, generate the first information by using the Protobuf file in the Protobuf project, and store the first information in the first vehicle-mounted device.

The first program may be a program that generates a protobuf message, and the first data may be related data used by the first program in converting a message of the application program into the protobuf message. The embodiment of the present application does not specifically limit the first data and the first program.

For example, the content in the Payload may be generated by the first information. The first program may generate a Protobuf message from the first data and the message of the application program.

Therefore, the Protobuf project of the open source automatically generates the message of the application program into the Protobuf message of the preset program language, the user is not required to manually process the message, the technical requirements on related personnel are low, and the development cost can be reduced.

In the embodiment of the application, after the first vehicle-mounted device sends the first SOME/IP message to the first service end through the first client, the first vehicle-mounted device can receive the second SOME/IP message through the first client, and the second SOME/IP message can be a message returned by the second vehicle-mounted device through the first service end in response to the first SOME/IP message.

For example, the first SOME/IP message may be a message requesting for the window status, and the second vehicle device determines that the window status is in the open state based on the message requesting for the window status, and then the second vehicle device feeds back the second SOME/IP message that the window is in the open state to the first client through the first service end.

As another example, the first SOME/IP message may be a message subscribing to a door status. And each time the second vehicle-mounted equipment detects that the state of the vehicle door changes, the second vehicle-mounted equipment can feed back a second SOME/IP message of the state of the vehicle door changes to the first client through the first service end, so that the first vehicle-mounted equipment can timely understand the state of the vehicle door and can display the state of the vehicle door on a screen of the vehicle-mounted equipment.

In this way, the first vehicle-mounted device may receive the message fed back by the second vehicle-mounted device, and enable SOME/IP communication between the first vehicle-mounted device and the second vehicle-mounted device.

For example, because the messages transmitted between the vehicle-mounted devices are processed through the Protobuf file, after the first vehicle-mounted device receives the second SOME/IP message, the first vehicle-mounted device can analyze the second SOME/IP message to obtain the target Protobuf message and the identification of the target application program; according to the identification of the target application program, calling back the target application program based on inter-process communication, and transmitting a target Protobuf message to the target application program; analyzing the target Protobuf message through target information corresponding to the target Protobuf message to obtain message content, wherein the target information comprises a target program for analyzing the target Protobuf message, and the target program is generated by a Protobuf file.

It will be appreciated that the second on-board device may be configured to convert the message of the application program into a target Protobuf message by the relevant information stored therein and send a second SOME/IP message carrying the target Protobuf message to the western medicine on-board device. The information on the second in-vehicle device may be referred to as the first information described in the above embodiment, which is not particularly limited in the embodiment of the present application.

For example, in addition to the relevant data and the program for converting the message of the application program into the Protobuf message, the first vehicle-mounted device may also store a program for parsing the Protobuf message sent by other vehicle-mounted devices, for example, the target program may be generated in a similar manner to that of the first program in the foregoing embodiment, and the used programming language may also be the same, which is not limited in the embodiment of the present application.

It should be noted that, the program for parsing the Protobuf message sent by the other vehicle-mounted devices may be stored in the same module as the relevant data and the program for generating the Protobuf message, or may be stored separately, which is not limited in the embodiment of the present application.

In this way, when the vehicle-mounted devices communicate with each other, the vehicle-mounted devices can parse out the content of the Protobuf message so as to perform operations related to the content of the message, such as displaying the content of the message on a display screen of the vehicle-mounted devices.

In the embodiment of the application, the vehicle-mounted communication SOA architecture can also comprise a third vehicle-mounted device, and the third vehicle-mounted device can perform SOME/IP communication with the first vehicle-mounted device and also can perform SOME/IP communication with the second vehicle-mounted device. The structure between the third in-vehicle device and the other in-vehicle devices may be referred to the structure between the two in-vehicle devices in fig. 1 or fig. 2, and will not be described herein.

In an exemplary embodiment, when the first on-board device and the third on-board device perform SOME/IP communication, the first on-board device may receive a third SOME/IP message through the second server, where the third SOME/IP message is sent by the third on-board device through the second client, and the second server establishes a connection with the second client.

In one possible implementation, the third SOME/IP message sent by the third in-vehicle device to the first in-vehicle device through the second client may be a request message.

In this way, the first in-vehicle device may communicate SOME/IP with the plurality of in-vehicle devices.

Based on the above embodiments, the user can install a new application in the first vehicle-mounted device. When the first vehicle-mounted device detects that the new application program exists, a corresponding relation between the identification of the new application program and a third server side and a third client side in the first vehicle-mounted device can be generated and stored; and/or when the first vehicle-mounted device detects that the new application program exists, second information can be generated and stored, the second information comprises second data and second programs, the second data and the second programs are used for generating Protobuf information from the information of the new application program, and the second data and the second programs are generated by Protobuf files.

The second information is similar to the first information, and reference is made to the description of the first information, and is not limited again.

In a possible implementation, the second information may further include a program for parsing other vehicle-mounted devices to send to the newly added application program, which is similar to the target application program described in the above embodiment, and the embodiment of the present application is not limited in particular.

It can be appreciated that the correspondence between the identifier of the newly added application program and the third server and the third client in the first vehicle-mounted device may be stored in a service management module Servers Manager of the first vehicle-mounted device.

In this way, when the first vehicle-mounted device has the new application program, the first vehicle-mounted device can automatically generate the related corresponding relation, so that the message of the new application program can be sent to other vehicle-mounted devices through the SOME/IP protocol, and personalized configuration is not required by related personnel.

In order to facilitate understanding of the vehicle-mounted communication method provided by the embodiment of the present application, a description is given below of a workflow of the first vehicle-mounted device. Fig. 5 is a schematic workflow diagram of a first vehicle-mounted device according to an embodiment of the present application.

As shown in fig. 5, the workflow of the first in-vehicle device may include the steps of:

S501, starting.

For example, the first vehicle-mounted device may be activated simultaneously when the vehicle is started.

S502, starting a local IPC service.

For example, the local IPC service may be started according to information related to the IPC service originally configured by the relevant person, so that IPC communication may be performed between the application program and the ServiceProxyService in the first vehicle device.

S503, monitoring a local IPC message.

The local IPC message is a message of an application program, and may be transmitted by the application program in the first vehicle device through an IPC interface.

The first in-vehicle device may monitor local IPC messages through serviceproxyseervice.

S504, remote calling.

Illustratively, the first in-vehicle device may make a remote call to invoke a SOME/IP client that transmits the message. The method of remote invocation by the first in-vehicle device may include step S505 described below.

S505, inquiring the SOME/IP client according to the message header.

The message header may be as shown in fig. 4, and may be a message defined by a Protobuf file.

The first vehicle-mounted device can query the SOME/IP client corresponding to the identification of the application program according to the identification of the application program in the message header.

S506, the request message is sent through the SOME/IP client.

For example, before sending the request message through the SOME/IP client, the received message may be encapsulated into a SOME/IP message, which is then sent through the SOME/IP client. The first vehicle device sends the request message through the SOME/IP client may be described in the above embodiments, and will not be described herein.

S507, registering the node.

For example, the first vehicle-mounted device may register the node when there is an additional application or an additional client, etc. The registration node may include step S508 described below.

S508, updating the service list and callback.

The service list may be a list including an identification of the application program, a correspondence between the client and the server.

For example, when the first in-vehicle device detects that there is an newly added application, the service list and callback may be updated. The update service list and the callback may be described in the above embodiments, and will not be described herein.

For example, a service of an SOA is added, that is, a first vehicle device with an application program is newly added and registered in a service list, and relevant data and programs generated through Protobuf files corresponding to all messages in the service are defined. The client and the server can generate code for serialization of the data packet through the Protobuf file and support multiple languages. Thus, the complex configuration of related personnel is not needed, and the development difficulty is reduced.

S509, message notification.

The message notification may be a notification of an Event message.

Based on the foregoing embodiments, other vehicle-mounted devices may subscribe to the Event message on the first vehicle-mounted device, and when the first vehicle-mounted device receives the notification of the Event message, the following step S510 may be executed.

S510, the local SOME/IP server sends the Event message.

Illustratively, a Server Manager on ServiceProxyService can send its own Server information to all subscribers through Event messages. The subscriber may be an in-vehicle device subscribing to the Event message, or a client on the in-vehicle device.

S511, channel inquiry.

For example, serviceproxyService may provide a variety of channel selection mechanisms such that serviceproxyService may subscribe to the event of the Servers Manager it proxies with serviceproxyService in all connected other in-vehicle devices.

S512, SOME/IP path information and a service list are generated.

The SOME/IP path information may be a path between a client in the first in-vehicle device and a server of the other in-vehicle device, and a path between a server in the first in-vehicle device and a client of the other in-vehicle device. For example, the connection relationship between the two in-vehicle devices described in fig. 1 or fig. 2 is described above.

The SOME/IP path information and the service list may be generated automatically or according to configuration information input by a user, and the embodiment of the application is not limited.

S513, returning to the processing result.

For example, after the first vehicle-mounted device sends the request message, after the service list is generated, after the service list and the callback are updated, the processing result can be returned after the Event message is sent, but the processing results returned by different stages are different. For example, the processing result returned after the service list is generated may be a result of whether the service list is generated successfully. The processing result returned after the Event message is sent may be a result of whether the Event message is sent to completion.

S514, starting the SOME/IP client according to the SOME/IP configuration.

SOME/IP configuration is a configuration by the relevant personnel.

S515, starting the local SOME/IP service according to the SOME/IP configuration.

By way of example, the initiation of the local SOME/IP service may be a service that initiates communication between the vehicle-mounted devices, and embodiments of the present application are not specifically limited to SOME/IP services.

S516, the SOME/IP client is connected with SOME/IP servers of other vehicle-mounted devices.

The connection of the SOME/IP client to the SOME/IP server of the other vehicle-mounted device may be automatically performed based on the configuration of the relevant personnel, and the connection between the SOME/IP client and the SOME/IP server of the other vehicle-mounted device may be referred to as the connection shown in FIG. 1 or FIG. 2.

S517, subscribing Event information to the SOME/IP service.

For example, subscribing Event messages to the SOME/IP server may be described in the above embodiments, and will not be described herein.

S518, monitoring SOME/IP messages.

For example, the first in-vehicle device may monitor SOME/IP messages in real-time.

S519, receiving Event information.

For example, the Event message received by the first vehicle-mounted device may be received after the first vehicle-mounted device sends a subscription Event message to the other vehicle-mounted device.

S520, calling a callback corresponding to the callback list.

For example, the first electronic device may call back the corresponding application program according to the identifier of the application program in the Event message, so as to transmit the Event message to the application program.

S521, receiving a Method message.

For example, the Method message received by the first in-vehicle device may be sent by another in-vehicle device.

S522, calling the callback in the callback list.

Callbacks in the call callback list can be referred to in the above embodiments, and will not be described herein.

S523, returning SOME/IP message.

For example, the first on-board device may return a SOME/IP message based on the received Method message and send the SOME/IP message to the on-board device from which the Method message originated.

It should be noted that, the steps S502-S505, S507, S509, S511, S513, S519-S522 may be implemented by the first vehicle device through a Protobuf file and an IPC service, and the steps S506, S508, S510, S512, S514-S518, S523 may be implemented through a SOME/IP service.

It will be appreciated that the above steps are not intended to represent the order of steps performed during operation of the first vehicle device, and that steps may be performed concurrently with each other.

In summary, the embodiment of the application can simplify the deployment work of SOME/IP, isolate the function service implementation from SOME/IP, lower the development difficulty and reduce the memory resources occupied by configuration information.

Fig. 6 is a schematic structural diagram of an in-vehicle communication device 60 according to an embodiment of the present application, for example, please refer to fig. 6, the in-vehicle communication device 60 may include:

the transmission module 601 is configured to transmit a message of a target application program of the plurality of application programs to the service proxy process based on the inter-process communication.

A processing module 602 is configured to encapsulate the message into a first SOME/IP message by the service proxy process, and determine a first client among the plurality of clients, the first client being a client capable of sending the SOME/IP message from the target application.

The transmission module 601 is further configured to send, through the first client, a first SOME/IP message to a first server, where the first server is a server that establishes a connection with the first client, and the first server operates in the second in-vehicle device.

In a possible implementation manner, a corresponding relation between a client in the first vehicle-mounted device and an identifier of an application program is stored in the first vehicle-mounted device; the processing module 602 is specifically configured to determine a first client from a plurality of clients in the service proxy process according to the identification of the target application program carried in the message.

In a possible implementation manner, the first vehicle-mounted device stores first information, the first information includes first data and first programs, the first data and the first programs are used for generating Protobuf messages from messages of a plurality of application programs, the first data and the first programs are generated by Protobuf files, and a programming language of the Protobuf messages generated by the first data and the first programs is preset.

In one possible implementation, the message is a Protobuf message.

In a possible implementation manner, the vehicle-mounted communication apparatus further includes a receiving module 603, where the receiving module 603 is configured to receive, by using the first client, a second SOME/IP message, where the second SOME/IP message is a message returned by the second vehicle device through the first server in response to the first SOME/IP message.

In a possible implementation manner, the processing module 602 is further configured to parse the second SOME/IP message to obtain a target Protobuf message and an identifier of the target application program; according to the identification of the target application program, calling back the target application program based on inter-process communication, and transmitting a target Protobuf message to the target application program; analyzing the target Protobuf message through target information corresponding to the target Protobuf message to obtain message content, wherein the target information comprises a target program for analyzing the target Protobuf message, and the target program is generated by a Protobuf file.

In a possible implementation manner, the receiving module 603 is further configured to receive a third SOME/IP message through the second server, where the third SOME/IP message is sent by the third vehicle device through the second client, and the second server establishes a connection with the second client.

In a possible implementation manner, the processing module 602 is further configured to generate and store, when detecting that there is a new application, a correspondence between an identifier of the new application and a third server and a third client in the first vehicle-mounted device; and/or when the newly added application program is detected, generating and storing second information, wherein the second information comprises second data and a second program, the second data and the second program are used for generating Protobuf information from the information of the newly added application program, and the second data and the second program are generated by the Protobuf file.

The vehicle-mounted communication device provided by the embodiment of the application can be any vehicle-mounted equipment in fig. 1 or fig. 2, and can execute the technical scheme of the vehicle-mounted communication method in any embodiment, and the implementation principle and beneficial effects of the vehicle-mounted communication device are similar to those of the vehicle-mounted communication method, and can be seen from the implementation principle and beneficial effects of the vehicle-mounted communication method, and the detailed description is omitted herein.

Fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the present application. As shown in fig. 7, the electronic device 700 may include: at least one processor 701 and a memory 702.

A memory 702 for storing programs. In particular, the program may include program code including computer-operating instructions.

The memory 702 may comprise high-speed RAM memory or may further comprise non-volatile memory (non-volatile memory), such as at least one disk memory.

The processor 701 is configured to execute computer-executable instructions stored in the memory 702 to implement the vehicle-mounted communication method described in the foregoing method embodiment. The processor 701 may be a central processing unit (Central Processing Unit, abbreviated as CPU), or an application specific integrated circuit (Application Specific Integrated Circuit, abbreviated as ASIC), or one or more integrated circuits configured to implement embodiments of the present application. Specifically, in implementing the vehicle-mounted communication method described in the foregoing method embodiment, the electronic device may be, for example, an electronic device having a processing function, such as a terminal or a server. In implementing the vehicle-mounted communication method described in the foregoing method embodiment, the electronic device may be, for example, a vehicle-mounted device on a vehicle, such as an electronic control unit.

Optionally, the electronic device 700 may also include a communication interface 703. In a specific implementation, if the communication interface 703, the memory 702, and the processor 701 are implemented independently, the communication interface 703, the memory 702, and the processor 701 may be connected to each other and perform communication with each other through buses. The bus may be an industry standard architecture (Industry Standard Architecture, abbreviated ISA) bus, an external device interconnect (Peripheral Component, abbreviated PCI) bus, or an extended industry standard architecture (Extended Industry Standard Architecture, abbreviated EISA) bus, among others. Buses may be divided into address buses, data buses, control buses, etc., but do not represent only one bus or one type of bus.

Alternatively, in a specific implementation, if the communication interface 703, the memory 702, and the processor 701 are implemented on a single chip, the communication interface 703, the memory 702, and the processor 701 may complete communication through internal interfaces.

The present application also provides a computer-readable storage medium, which may include: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk or an optical disk, etc., in which program codes may be stored, and in particular, the computer-readable storage medium stores program instructions for the methods in the above embodiments.

The present application also provides a program product comprising execution instructions stored in a readable storage medium. The at least one processor of the electronic device may read the execution instructions from the readable storage medium, and execution of the execution instructions by the at least one processor causes the electronic device to implement the vehicle-mounted communication method provided by the various embodiments described above.

Finally, it should be noted that: the above embodiments are only for illustrating the technical solution of the present application, and not for limiting the same; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some or all of the technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the application.

Claims

1. The vehicle-mounted communication method is applied to a first vehicle-mounted device, wherein a service agent process, a plurality of application programs, a plurality of clients and a plurality of service terminals are operated in the first vehicle-mounted device, and the number of the clients and the number of the service terminals are smaller than the number of the application programs, and is characterized by comprising the following steps:

2. The method of claim 1, wherein the first on-board device has stored therein a correspondence of clients in the first on-board device to identifications of applications;

the determining a first client among a plurality of clients includes:

and determining the first client from a plurality of clients in the service agent process according to the identification of the target application program carried in the message.

3. The method according to claim 1 or 2, wherein the first vehicle-mounted device stores first information, the first information includes first data and a first program, the first data and the first program are used for generating Protobuf messages from messages of the plurality of application programs, the first data and the first program are both generated by Protobuf files, and a programming language of the Protobuf messages generated by the first data and the first program is preset.

4. A method according to claim 3, characterized in that the message is a Protobuf message.

5. The method of claim 4, wherein after sending the first SOME/IP message to the first service by the first client, comprising:

and receiving a second SOME/IP message by the first client, wherein the second SOME/IP message is a message returned by the second vehicle-mounted equipment through the first server in response to the first SOME/IP message.

6. The method of claim 5, wherein after receiving a second SOME/IP message by the first client, comprising:

analyzing the second SOME/IP message to obtain a target Protobuf message and the identification of the target application program;

according to the identification of the target application program, calling back the target application program based on inter-process communication, and transmitting the target Protobuf message to the target application program;

analyzing the target Protobuf message through target information corresponding to the target Protobuf message to obtain message content, wherein the target information comprises a target program for analyzing the target Protobuf message, and the target program is generated by a Protobuf file.

7. The method according to claim 5 or 6, characterized in that the method further comprises:

and receiving a third SOME/IP message through a second server, wherein the third SOME/IP message is sent by third vehicle-mounted equipment through a second client, and the second server establishes connection with the second client.

8. The method according to claim 2 or 6, characterized in that the method further comprises:

when detecting that a new application program exists, generating and storing a corresponding relation between an identifier of the new application program and a third server side and a third client side in the first vehicle-mounted equipment;

and/or the number of the groups of groups,

and when the newly added application program is detected, generating and storing second information, wherein the second information comprises second data and a second program, the second data and the second program are used for generating Protobuf information from the information of the newly added application program, and the second data and the second program are generated by Protobuf files.

9. A vehicle-mounted communication device, characterized by comprising:

10. An electronic device, comprising: a processor, and a memory communicatively coupled to the processor;

the memory stores computer-executable instructions;

the processor executes computer-executable instructions stored in the memory to implement the method of any one of claims 1-8.

11. A computer readable storage medium having stored therein computer executable instructions which when executed by a processor are adapted to carry out the method of any one of claims 1-8.

12. A computer program product comprising a computer program which, when executed by a processor, implements the method of any of the preceding claims 1-8.