Vehicle communication method and device, electronic equipment, storage medium and product

Abstract

The invention discloses a vehicle communication method and device, electronic equipment, a storage medium and a product. The method comprises the following steps: in response to a service event, determining a target service from a service library; determining a communication path of the service event according to a provider and a consumer of the target service and the electronic and electrical architecture; a corresponding packaging message is called from a matrix library based on the communication path, the matrix library is a CAN signal matrix library or an Ethernet matrix library, and the CAN signal matrix library or the Ethernet matrix library is used for packaging a CAN signal corresponding to the target service into a first message or packaging Ethernet data corresponding to the target service into a second message; and transmitting the packaged message according to the communication path. According to the scheme, the service is uniformly defined in the service library, the CAN signal or the Ethernet data corresponding to the service is packaged into the message, when the service is used, the packaged message is directly called to be transmitted according to the communication path, a communication process does not need to be designed for the CAN signal and the Ethernet separately, and the applicability and the expandability of vehicle communication are improved.

Description

Technical Field

[0001] The present invention relates to the field of vehicle communication technology, and in particular to a vehicle communication method, device, electronic device, storage medium and product. Background Technology

[0002] In the context of automotive intelligence, Service-Oriented Architecture (SOA) has become a key technology for realizing software-defined vehicles and even AI-defined vehicles. The core of SOA is to abstract functions into independent services, which are then made available to consumers through service interfaces. The communication network between in-vehicle controllers mainly consists of a Controller Area Network (CAN) and Ethernet. CAN communication is a serial communication protocol bus used for real-time applications, transmitting messages composed of several CAN signals. Ethernet, on the other hand, supports various protocols, such as Scalable Service-Oriented Middleware over IP (SOME / IP) and Data Distribution Service (DDS) protocols.

[0003] Currently, SOA communication between controllers in the industry is mainly based on Ethernet, while CAN communication is based on signal-based design logic. Therefore, SOA and CAN signal designs are based on two completely different design theories and cannot be integrated. This leads to the following problems: Existing CAN signal designs are difficult to reuse if the SOA architecture changes; it is difficult to maintain consistency between CAN signals and data on SOA, making it difficult to filter out redundant or inconsistent designs. Although there are methods to convert between CAN signals and Ethernet data, these two communication methods remain fundamentally isolated and cannot be uniformly defined. Furthermore, for Ethernet communication itself, there is no unified service design methodology that can be compatible with multiple communication protocols.

[0004] In summary, service-oriented vehicle communication has poor applicability and scalability. Summary of the Invention

[0005] This invention provides a vehicle communication method, device, electronic device, storage medium, and product to improve the applicability and scalability of vehicle communication.

[0006] In a first aspect, embodiments of this application provide a vehicle communication method, including:

[0007] In response to a service event, determine the target service from the service repository;

[0008] The communication path of the service event is determined based on the provider, consumer, and electrical / electronic architecture of the target service;

[0009] Based on the communication path, the corresponding encapsulated message is retrieved from the matrix library, wherein the matrix library is a CAN signal matrix library or an Ethernet matrix library, and the encapsulated message is a first message or a second message. The CAN signal matrix library is used to encapsulate the CAN signal corresponding to the target service into a first message, and the Ethernet matrix library is used to encapsulate the Ethernet data corresponding to the target service into a second message.

[0010] The encapsulated message is transmitted according to the communication path.

[0011] Secondly, embodiments of this application also provide a vehicle communication device, including:

[0012] The service determination module is used to determine the target service from the service library in response to service events;

[0013] The path determination module is used to determine the communication path of the service event based on the provider, consumer and electronic and electrical architecture of the target service;

[0014] The retrieval module is used to retrieve the corresponding encapsulated message from the matrix library based on the communication path, wherein the matrix library is a CAN signal matrix library or an Ethernet matrix library, and the encapsulated message is a first message or a second message. The CAN signal matrix library is used to encapsulate the CAN signal corresponding to the target service into a first message, and the Ethernet matrix library is used to encapsulate the Ethernet data corresponding to the target service into a second message.

[0015] A transmission module is used to transmit the encapsulated message according to the communication path.

[0016] Thirdly, embodiments of this application also provide an electronic device, including:

[0017] At least one processor;

[0018] A memory communicatively connected to the at least one processor; wherein,

[0019] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the vehicle communication method as described above.

[0020] Fourthly, embodiments of this application also provide a computer-readable storage medium having a computer program stored thereon, characterized in that the program, when executed by a processor, implements the vehicle communication method as described above.

[0021] Fifthly, embodiments of this application also provide a computer program product, including a computer program and / or instructions, characterized in that, when the computer program and / or instructions are executed by a processor, they implement the vehicle communication method as described above.

[0022] This application provides a vehicle communication method, apparatus, electronic device, storage medium, and product. The method includes: in response to a service event, determining a target service from a service library; determining a communication path for the service event based on the provider, consumer, and electronic / electrical architecture of the target service; retrieving a corresponding encapsulated message from a matrix library (either a CAN signal matrix library or an Ethernet matrix library) based on the communication path; the encapsulated message being a first message or a second message; the CAN signal matrix library encapsulating the CAN signal corresponding to the target service into a first message, and the Ethernet matrix library encapsulating the Ethernet data corresponding to the target service into a second message; and transmitting the encapsulated message according to the communication path. The above technical solution uniformly defines multiple services in the service library and pre-encapsulates the CAN signal or Ethernet data corresponding to the service into messages. When using a service, the encapsulated message can be directly retrieved and transmitted according to the communication path, eliminating the need to design separate request and response communication processes for CAN signals and Ethernet, thus improving the applicability and scalability of vehicle communication. Attached Figure Description

[0023] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0024] Figure 1 A flowchart illustrating a vehicle communication method provided in an embodiment of this application;

[0025] Figure 2 A schematic diagram illustrating a service deployment as provided in one embodiment;

[0026] Figure 3 This is a schematic diagram illustrating how a Topic is generated independently for each service interface, as provided in one embodiment.

[0027] Figure 4 This is a schematic diagram illustrating a method for merging similar service interfaces (Topics) serving the same objective, as provided in one embodiment.

[0028] Figure 5 This is a schematic diagram illustrating a method for merging similar service interfaces of the same type that serve different objectives, as provided in one embodiment.

[0029] Figure 6A schematic diagram of a target service based on SOME / IP binding is provided as an embodiment;

[0030] Figure 7 This is a schematic diagram of the structure of a vehicle communication device provided in an embodiment of this application;

[0031] Figure 8 A schematic diagram of an SOA service architecture provided for an embodiment of this application;

[0032] Figure 9 A schematic diagram of the structure of an electronic device that can be used to implement embodiments of this application is shown. Detailed Implementation

[0033] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the application and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present application, not the entire structure.

[0034] Before discussing the exemplary embodiments in more detail, it should be noted that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe the steps as sequential processes, many of these steps can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the steps can be rearranged. The process can be terminated when its operation is complete, but may also have additional steps not included in the figures. The process can correspond to a method, function, procedure, subroutine, subroutine, etc.

[0035] It should be noted that the concepts of "first" and "second" mentioned in the embodiments of this application are only used to distinguish different devices, modules, units or other objects, and are not used to limit the order of functions performed by these devices, modules, units or other objects or their interdependencies.

[0036] Furthermore, the embodiments and features described in this application may be combined with each other, unless otherwise specified.

[0037] The acquisition, storage, use, and processing of data in this application all comply with the relevant provisions of national laws and regulations.

[0038] In the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, they do not mean that the applicant has used or necessarily used the relevant content of the solution.

[0039] Figure 1This is a flowchart illustrating a vehicle communication method provided in an embodiment of this application. This embodiment is applicable to situations requiring real-time voice recognition. Specifically, the vehicle communication method can be executed by a vehicle communication system, which can be implemented through software and / or hardware and integrated into an electronic device. The electronic device can refer to a user-end device or a server-end device, including but not limited to in-vehicle systems, Electronic Control Unit (ECU) computers, in-vehicle intelligent terminals, smartphones, or cloud servers.

[0040] like Figure 1 As shown, the method specifically includes the following steps:

[0041] S110. In response to a service event, determine the target service from the service database;

[0042] In this context, a service can be understood as an independent, discrete functional unit that provides a standard service interface, allowing remote access, independent execution, and updates. All services are uniformly defined and collectively constitute a service library. For example, services may include seat control services (specifically, seat heating, seat ventilation, and / or seat adjustment services), air conditioning control services, body control services, audio control services, and / or autonomous driving control services. The service library can be understood as a collection of services, often referred to as an SOA service library. The SOA service library is the largest collection of vehicle services; all functional requirements are based on it, and it serves as the design source for all communication signals. The unified definition of various services allows for high reusability across different architectural components. When defining a service, it must at least be defined based on its name or type and service interface information (e.g., service interface type, service interface definition, and service interface parameters). A target service can be understood as the service that is currently triggered, requested, executed, or generates CAN signals or Ethernet data.

[0043] Service events can refer to events that use or trigger a service. For example, a user may give a command to heat the seat via a mobile app, and the corresponding target service could be the seat heating service. Service events can also be control signals or commands generated inside the vehicle's infotainment system. For example, a command to monitor the vehicle's speed in real time while the vehicle is in motion could be the vehicle speed monitoring service. Or a command to check for any abnormalities in the vehicle's functions and hardware whenever the vehicle is started could be the vehicle self-check service.

[0044] It is understandable that the main principles for the unified definition of services in the service repository include:

[0045] The provider and consumer sides are decoupled, meaning that adding a consumer side does not affect the service implementation on the server side;

[0046] Services are decoupled from each other, meaning that there is no strong correlation between services, and a change in one service does not affect other services;

[0047] Decoupling services from protocols means that when designing services, data transmission protocols are not considered, and only capabilities are extracted.

[0048] The parameters should be set to the actual range of values. This is so that the actual transmission length can be configured according to the actual range of values ​​when binding the protocol, thus saving network resources.

[0049] When designing parameters, consider weak compatibility and use simple data types whenever possible. This is also to ensure compatibility with as many communication protocols as possible and avoid unnecessary changes.

[0050] Adopt a unified naming principle to ensure that service names are compatible with communication protocols. Generally, the following principles can be followed when naming services:

[0051] Naming conventions (e.g., camelCase, etc.);

[0052] Characters not allowed in the name (such as Chinese characters, special characters, sensitive words, etc.);

[0053] Name characters have a length limit.

[0054] S120. Determine the communication path of the service event based on the provider, consumer, and electronic / electrical architecture of the target service;

[0055] In this context, the provider can be understood as the provider of the functions related to the target service, and the consumer can be understood as the user or invoker of the functions related to the target service. For example, for a user invoking a seat heating service through a mobile app, the provider could be the seat heating controller, and the consumer could be the mobile app. Similarly, for a vehicle speed monitoring service, the provider could be a sensor that monitors vehicle speed, and the consumer could be the vehicle's infotainment system controller or the software used to display real-time vehicle speed. The Electrical / Electronic Architecture (EEA) encompasses all the hardware, software, sensors, actuators, and electronic / electrical distribution systems in the vehicle. These components are integrated using system integration tools, representing the integration of the entire vehicle's electronic / electrical functional solutions. The communication path can be understood as the path through which signals or data of the target service are transmitted from the provider to the consumer; this path can be determined in conjunction with the EEA.

[0056] S130. Based on the communication path, retrieve the corresponding encapsulated message from the matrix library, wherein the matrix library is a CAN signal matrix library or an Ethernet matrix library, and the encapsulated message is a first message or a second message. The CAN signal matrix library is used to encapsulate the CAN signal corresponding to the target service into a first message, and the Ethernet matrix library is used to encapsulate the Ethernet data corresponding to the target service into a second message.

[0057] The matrix library can be understood as a database storing encapsulated messages. These encapsulated messages can be stored in memory in matrix form, effectively improving read / write speed and supporting high-concurrency access. The matrix library can include two types: a CAN signal matrix library and an Ethernet matrix library. In this embodiment, the target service can be invoked via CAN signals or via Ethernet data. CAN is a serial communication protocol bus used for real-time applications. CAN communication adopts a static sending and receiving method. The first message is mainly a message encapsulated from several CAN signals. In this embodiment, the sender and receiver of each CAN signal can be determined, forming a CAN matrix (also called a CAN communication matrix) for each architecture, thus completing the encapsulation of the CAN signals.

[0058] The CAN signals or Ethernet data corresponding to the service are pre-encapsulated into messages. When using the target service, the corresponding encapsulated message can be directly retrieved from the CAN signal matrix library or the Ethernet matrix library for transmission. It should be noted that this embodiment does not exclude the possibility that the target service is invoked through both CAN signals and Ethernet data. In this case, the first message for the CAN signal part is retrieved from the CAN signal matrix library, and the second message is retrieved from the Ethernet matrix library.

[0059] It should be noted that the CAN in the embodiments of this application can also be a variable rate controller area network (CAN with Flexible Data-Rate).

[0060] S140. Transmit the encapsulated message according to the communication path.

[0061] Specifically, when using a target service, the corresponding encapsulated message of the target service is retrieved from the CAN signal matrix library or Ethernet matrix library and transmitted according to the determined communication path, so that the provider can provide the corresponding function and the consumer can use the corresponding function.

[0062] The vehicle communication method provided in this application adopts a service-oriented architecture, uniformly defines services, and completes service abstraction. Upper-layer applications no longer need to pay attention to the underlying communication protocols, and application software can be reused to the greatest extent. Moreover, services can be called in the form of CAN signals and Ethernet data, unifying the design of CAN and Ethernet. Furthermore, the service design is not affected by changes in electronic and electrical architecture and can be reused across electronic and electrical architectures. The decoupling of service design and communication protocol mapping can ensure good protocol scalability, and the flexible protocol binding configuration can save controller resources and network bandwidth.

[0063] In one embodiment, it further includes:

[0064] S1010. For each service, the service's interface parameters are encapsulated in a CAN signal and stored in the CAN signal library. The CAN signal is encapsulated into a message according to the communication path and the transmit / receive relationship, and the first message after encapsulation is stored in the CAN signal matrix library. Alternatively, the Ethernet data corresponding to the service's interface parameters is encapsulated into a second message according to the corresponding communication protocol and stored in the Ethernet database.

[0065] Interface parameters can be understood as parameters configured in the service interface to control a certain function. For example, for the seat heating service, the interface parameter can be "Open" or "Close", which are used to indicate whether the seat heating function is turned on or off, respectively. For the vehicle speed monitoring service, the interface parameter can be "Frequency", which is used to indicate the frequency at which the sensor reports vehicle speed data, or "mode", which is used to indicate the mode of monitoring vehicle speed, such as periodic, non-periodic, or triggered monitoring.

[0066] For each service, during the service definition process, its interface parameters can be encapsulated as CAN signals and stored in a CAN signal library, which can be understood as a collection of CAN signals. Based on the provider, consumer, and transmit / receive relationship (in different scenarios, the provider can be either a sender or receiver of the CAN signal, and correspondingly, the consumer can be either a receiver or sender of the CAN signal), the CAN signals are encapsulated into a first message using the appropriate communication protocol (e.g., the CAN protocol) and stored in the CAN signal matrix library. The service's interface parameters can also be used as Ethernet data, encapsulated into a second message using the appropriate communication protocol (e.g., DDS or SOME / IP) and stored in the Ethernet database.

[0067] It should be noted that when the interface parameters are mapped to CAN signals, the CAN signals are automatically generated based on the service interface. The service interface can be divided into two main categories: event interfaces and method interfaces. Events are initiated by the provider actively reporting data, while methods require the consumer to send a data request first, and then the provider provides a response. It can be seen that the interface parameters may be sent from the provider to the consumer or from the consumer to the provider. Therefore, the sender-receiver relationship also needs to be considered during the message encapsulation process.

[0068] Based on this, by predefining each service and encapsulating and storing the interface parameters, when using the target service, the encapsulated message can be directly retrieved according to the communication path and transmitted according to the communication path, thus realizing automatic CAN or Ethernet calls. There is no need to design a communication process to distinguish between CAN signals and Ethernet, nor is there a need to temporarily map interface parameters and encapsulate messages when using services. This improves the applicability and scalability of vehicle communication, while also improving communication efficiency and reducing communication latency.

[0069] In one embodiment, the method further includes: for each service,

[0070] S1210. Determine the software unit and hardware unit based on the service provider and consumer;

[0071] S1220. Determine the communication protocol for the service based on the software unit and the hardware unit;

[0072] The communication protocol includes at least one of the following: CAN protocol, IP-based scalable service-oriented middleware SOME / IP, and data distribution service DDS protocol.

[0073] In this context, for a single service, software and hardware units can be understood as the software algorithms and hardware controllers actually used by the provider and consumer to perform the corresponding functions of the service and during communication. For specific software and hardware units, corresponding communication protocols can be specified.

[0074] When the interface parameters are mapped to CAN signals, the corresponding communication protocol is the CAN protocol; when the interface parameters are mapped to Ethernet data, Ethernet communication supports mapping to multiple communication protocols, including but not limited to SOME / IP and DDS.

[0075] Figure 2 This is a schematic diagram illustrating a service deployment as provided in one embodiment. For example... Figure 2 As shown, taking two target services (service A and service B) as an example, the service deployment process mainly includes:

[0076] ① Assign a provider and a consumer for each service, where service A corresponds to provider A1, consumer A2, and consumer A3, and service B corresponds to provider B1 and consumer B2;

[0077] ② Specify the software unit (APP) and hardware controller (ECU) to be carried by the provider and the consumer. In terms of software, consumer A2 and consumer B2 can jointly carry APP2, and provider B1 and consumer A3 can jointly carry APP3. In terms of hardware, provider A1, consumer A2 and consumer B2 jointly carry ECU1, and provider B1 and consumer A3 jointly carry ECU2.

[0078] ③ Specify the communication protocol (such as CAN, SOME / IP, DDS, etc.) for service interaction based on the deployed software and hardware information.

[0079] It is understandable that while services are uniformly defined, for the same service, the actual providers and consumers, as well as the actual software units, hardware controllers, and communication protocols used, can be determined based on the specific circumstances in different operating systems, vehicles, or application scenarios. This process can be understood as the service deployment or orchestration process. The functional design and definition of the service determine the supply and demand relationship (provider and consumer), while the electronic and electrical architecture determines the actual software and hardware units used, as well as the communication paths for encapsulating messages. The deployment results may vary depending on functional requirements and the electronic and electrical architecture. Based on this, the service is decoupled from the software, hardware, and communication protocols, making the communication method of this embodiment applicable to any software, hardware, and communication protocol.

[0080] In one embodiment, before encapsulating the interface parameters of the service in a CAN signal, the method further includes: S1001, for each service, generating a CAN signal based on the service's interface parameters; wherein, generating a CAN signal based on the service's interface parameters specifically includes:

[0081] For the Event interface, at least one CAN signal is generated according to the data type of the service interface parameters. For data types of first complexity (simpler), the name of the generated CAN signal is determined according to the Event interface name. For data types of second complexity (more complex), a corresponding CAN signal is generated for each data element of the service. The name of the CAN signal is determined according to the Event interface name and the data element name.

[0082] For the request data of the Method interface, at least one CAN signal is generated according to the data type of the service interface parameters. For data types of first complexity, the name of the generated CAN signal is determined according to the Event interface name and the request character. For data types of second complexity, a corresponding CAN signal is generated for each data element of the service. The name of the CAN signal is determined according to the Event interface name, the request character, and the data element name.

[0083] For the response data of the Method interface, at least one CAN signal is generated according to the data type of the service interface parameters. For data types of first complexity, the name of the generated CAN signal is determined according to the Event interface name and the response character. For data types of second complexity, a corresponding CAN signal is generated for each data element of the service. The name of the CAN signal is determined according to the Event interface name, the response character, and the data element name.

[0084] The second complexity is higher than the first complexity.

[0085] When service data is mapped to CAN signals, the CAN signals can be automatically generated based on the service interface. For example, a single service can generate one or more CAN signals, which can then be used by software units and hardware controllers to control the vehicle and achieve the corresponding functions. Service interfaces can be divided into two main categories: event interfaces and method interfaces. When generating CAN signals, the number of CAN signals, their names, and whether data elements are distinguished can be determined based on the interface type and the complexity of the data.

[0086] For example, for the Event interface, the name of the generated CAN signal for simpler data types is the Event interface name, and for more complex data types, a corresponding CAN signal is generated for each data element of the service, with the CAN signal name being the Event interface name + data element name. For the request data of the Method interface, the name of the generated CAN signal for simpler data types is the Event interface name + request character, and for more complex data types, a corresponding CAN signal is generated for each data element of the service, with the CAN signal name being the Event interface name + request character + data element name. For the response data of the Method interface, the name of the generated CAN signal for simpler data types is the Event interface name + response character, and for more complex data types, a corresponding CAN signal is generated for each data element of the service, with the CAN signal name being the Event interface name + response character and data element name. In some embodiments, there may be data types that do not support CAN protocol binding, such as strings, complex nested data types, or data whose actual length exceeds the data limits of CAN and CANFD.

[0087] Based on this, the corresponding data is mapped to CAN signals according to the service interface type, providing a basis for calling services via CAN signals. It should be noted that the naming method in this embodiment is merely an example, and actual applications are not limited to the naming methods listed above.

[0088] In one embodiment, before encapsulating the CAN signal according to the communication path and the transmit / receive relationship in accordance with the corresponding communication protocol, the method further includes: S1002, determining the transmit / receive relationship of the CAN signal;

[0089] Specifically, determining the transmission and reception relationship of the CAN signals includes: for the Event interface, determining that the sender of the CAN signal is the provider and the receiver of the CAN signal is the consumer; for the request data of the Method interface, determining that the sender of the CAN signal is the consumer and the receiver of the CAN signal is the provider; and for the response data of the Method interface, determining that the sender of the CAN signal is the provider and the receiver of the CAN signal is the consumer.

[0090] In cases where interface parameters are mapped to CAN signals, the CAN signals are automatically generated based on the service interface. Considering that the interaction methods between consumers and providers may differ for different types of service interfaces, the CAN signal transmission and reception relationship can be determined based on the service deployment before message encapsulation. For example, for an Event interface request, the CAN signal sender is the provider of the target service, and the CAN signal receiver is the consumer of the target service; for a Method interface request, the CAN signal sender is the consumer of the service, and the CAN signal receiver is the provider of the target service; and for a Method interface response, the CAN signal sender is the provider of the target service, and the CAN signal receiver is the consumer of the target service. Based on this, the transmission direction of the encapsulated message is accurately determined, ensuring the reliability of the encapsulated message transmission and making the vehicle communication method applicable to different interface types.

[0091] Optionally, during the encapsulation of CAN signals, data from the SOA service library can be referenced for design (layout) to specify the data start bit, signal length, unsigned / signed, precision, and offset for each signal.

[0092] In one embodiment, before encapsulating the Ethernet data corresponding to the interface parameters of the service into a second message according to the corresponding communication protocol, the method further includes:

[0093] S1003. For each service, generate the Ethernet data corresponding to the interface parameters of the service; wherein, the Ethernet data corresponding to the interface parameters of the service includes one of the following:

[0094] 1) When the communication protocol is DDS protocol, Ethernet data of the corresponding topic is generated for each service interface of a single service. The generated Ethernet data includes the interface parameters of the corresponding service, and the sender and receiver of each topic are determined according to the supply and demand relationship of the service. Specifically, one topic is generated for the Event interface and at most two topics are generated for the Method interface.

[0095] 2) When the communication protocol is DDS, Ethernet data for a single service interface of the same type is generated. The generated Ethernet data includes the interface parameters of the corresponding service. The sender and receiver of each topic are determined according to the supply and demand relationship of the service. Specifically, one topic is generated for all Event interfaces of the service, and at most two topics are generated for all Method interfaces of the service. The sender and receiver of each topic are determined according to the supply and demand relationship of the service.

[0096] 3) When the communication protocol is DDS protocol, Ethernet data of a topic is generated for the same service interface of different services. The generated Ethernet data includes the interface parameters of the corresponding service, and the sender and receiver of each topic are determined according to the supply and demand relationship of the service. Specifically, one topic is generated for all Event interfaces of different services, and at most two topics are generated for all Method interfaces of different services.

[0097] 4) When the communication protocol is SOME / IP, Ethernet data is generated based on the service identifier and service interface identifier of the service. The generated Ethernet data includes the interface parameters of the corresponding service. The service identifiers of different services are different, and the service interface identifiers of different service interfaces of the same service are different.

[0098] For example, considering that the DDS protocol does not involve the concept of services, Ethernet data can be generated for various service interfaces according to topics, thereby realizing the mapping between service interface parameters and Ethernet data. However, for the Ethernet DDS protocol (as described in 1) to 3) above, the DDS communication model differs significantly from SOA services. Since DDS does not have the concept of services, this embodiment introduces services for the core of DDS communication, namely data (DDS Topic). This requires defining service topics and specifying a sender (Writer) and a receiver (Reader) for each topic.

[0099] Figure 3 This is a schematic diagram illustrating an embodiment of generating a Topic independently for each service interface. For example... Figure 3 As shown, one Topic is generated for an Event, with the Topic name equal to the Event name; a maximum of two Topics are generated for a Method, where the Topic name composed of input parameters (in) = Method name + Request, and the Topic name composed of output parameters (out) = Method name + Response. Topic sending and receiving are automatically associated based on the service provider and consumer; out data is sent from the provider to the consumer, and in parameters are sent from the consumer to the provider.

[0100] Figure 4 This is a schematic diagram illustrating the merging of Topics for the same type of service interfaces, as provided in one embodiment. Figure 4As shown, all Events under the same service generate one Topic, with the Topic name = Service name + Status; all Methods under the same service generate a maximum of two Topics, where the Topic name composed of input parameters (in) = Service name + Request, and the Topic name composed of output parameters (out) = Service name + Response. Topic sending and receiving are automatically associated based on the service provider and consumer; out data is sent from the provider to the consumer, and in parameters are sent from the consumer to the provider. Data encapsulation must not disrupt the data structure of a single interface.

[0101] Figure 5 This is a schematic diagram illustrating how to merge similar service interfaces from different services into a single embodiment. Figure 5 As shown, a new Topic is created for each service interface. A Topic can be associated with the corresponding service interfaces of at least two services. Topic sending and receiving is a collection of the service providers and consumers of the associated services. Out data is sent from the provider to the consumer, and in parameters are sent from the consumer to the provider. By merging Topics with the same type of service interfaces across services, communication resources can be further saved.

[0102] Figure 6 This is a schematic diagram illustrating a SOME / IP binding service as an embodiment. Figure 6 As shown, Ethernet's SOME / IP protocol is a scalable communication protocol based on a service model, supporting Event and Method interface types. Therefore, when mapping Ethernet data, only the service identifier (ID) and service interface identifier (ID) need to be specified. Notably, service IDs for different services cannot be duplicated, and service interface IDs for the same service cannot be duplicated.

[0103] Based on this, the service-oriented vehicle communication method provided in this application can cover all forms of vehicle communication, including intra-domain communication and inter-domain communication. Communication development can be carried out based on this application, which can break down the barriers between CAN and ETH, making the communication design more standardized and more unified.

[0104] The method of mapping SOA service interface parameters to CAN signals unifies and automatically associates the target service and CAN signals—two communication methods that will exist in automotive networks for a long time to come—in the design, providing support for the comprehensive implementation of SOA architecture and providing underlying theory for functional design. This method improves the scalability of service-oriented vehicle communication. Furthermore, it proposes multiple service merging methods for DDS protocol mapping, ensuring sufficient automation while also providing solutions to potential controller resource constraints, thus laying the foundation for the integration of SOA and DDS.

[0105] Furthermore, the service-oriented vehicle communication method provided in this application can guide the optimization of communication design processes, the design of SOA software architecture, and the development of related toolchains. Its flexible protocol binding method can maximize the saving of hardware and network resources. The design method and implementation path provide design support for the overall vehicle SOA architecture, laying the foundation for achieving software-software decoupling and software-hardware decoupling. Based on the above, functional development can be applied to the entire vehicle, and upper-layer applications no longer need to focus on the underlying communication protocols and communication matrices. The responsibilities of each participant in functional design are clearer, and the boundaries between functional modules are more distinct. Basic functions can be reused across architectures as services, improving the efficiency of overall vehicle development and shortening the vehicle development cycle.

[0106] This application also provides a vehicle communication device. It should be noted that technical details not described in detail in this embodiment can be found in any of the above embodiments. Figure 7 This is a schematic diagram of the structure of a vehicle communication device provided in an embodiment of this application. Figure 7 As shown, the vehicle communication device includes:

[0107] Service determination module 210 is used to determine the target service from the service library in response to a service event;

[0108] The path determination module 220 is used to determine the communication path of the service event based on the provider, consumer and electronic and electrical architecture of the target service;

[0109] The retrieval module 230 is used to retrieve the corresponding encapsulated message from the matrix library based on the communication path, wherein the matrix library is a CAN signal matrix library or an Ethernet matrix library, and the encapsulated message is a first message or a second message. The CAN signal matrix library is used to encapsulate the CAN signal corresponding to the target service into a first message, and the Ethernet matrix library is used to encapsulate the Ethernet data corresponding to the target service into a second message.

[0110] The transmission module 240 is used to transmit the encapsulated message according to the communication path.

[0111] The vehicle communication device in this embodiment adopts a service-oriented architecture. Multiple services are uniformly defined in the service library, and the CAN signals or Ethernet data corresponding to the services are pre-encapsulated into messages. Based on this, for service events, the encapsulated messages can be directly retrieved and transmitted according to the communication path. There is no need to design different request and response communication processes for CAN signals and Ethernet, which improves the applicability and scalability of vehicle communication.

[0112] In one embodiment, the device further includes:

[0113] An encapsulation module is used to encapsulate the interface parameters of each service in a CAN signal and store them in a CAN signal library; to encapsulate the CAN signal according to the communication path and transmit / receive relationship, and to encapsulate the first encapsulated message according to the corresponding communication protocol; and to store the first encapsulated message in a CAN signal matrix library; or...

[0114] The Ethernet data corresponding to the interface parameters of the service is encapsulated into a second message according to the corresponding communication protocol and stored in the Ethernet database.

[0115] In one embodiment, the device further includes:

[0116] A software and hardware determination module is used to determine the software unit and hardware unit for each service based on the service provider and consumer.

[0117] A protocol determination module is used to determine the communication protocol of the service based on the software unit and the hardware unit;

[0118] The communication protocol includes at least one of the following: CAN protocol, IP-based scalable service-oriented middleware SOME / IP, and data distribution service DDS protocol.

[0119] In one embodiment, the device further includes:

[0120] A signal generation module is used to generate a CAN signal for each service based on the interface parameters of the service before encapsulating the interface parameters of the service in a CAN signal;

[0121] Specifically, generating a CAN signal based on the interface parameters of the service includes:

[0122] For the Event interface, at least one CAN signal is generated according to the data type of the interface parameters of the service. For data types of first complexity, the name of the generated CAN signal is determined according to the Event interface name. For data types of second complexity, a corresponding CAN signal is generated for each data element of the service. The name of the CAN signal is determined according to the Event interface name and the data element name.

[0123] For the request data of the Method interface, at least one CAN signal is generated according to the data type of the interface parameters of the service. For data types of first complexity, the name of the generated CAN signal is determined according to the Event interface name and the request character. For data types of second complexity, a corresponding CAN signal is generated for each data element of the service. The name of the CAN signal is determined according to the Event interface name, the request character, and the data element name.

[0124] For the response data of the Method interface, at least one CAN signal is generated according to the data type of the interface parameters of the service. For data types of first complexity, the name of the generated CAN signal is determined according to the Event interface name and the response character. For data types of second complexity, a corresponding CAN signal is generated for each data element of the service. The name of the CAN signal is determined according to the Event interface name, the response character, and the data element name.

[0125] The second complexity is higher than the first complexity.

[0126] In one embodiment, the device further includes:

[0127] The transmit / receive relationship determination module is used to determine the transmit / receive relationship of the CAN signal before encapsulating the CAN signal into a message according to the corresponding communication protocol based on the communication path and transmit / receive relationship.

[0128] Specifically, determining the transmit / receive relationship of the CAN signals includes:

[0129] For the Event interface, the sender of the CAN signal is determined to be the provider, and the receiver of the CAN signal is determined to be the consumer.

[0130] For the request data of the Method interface, the sender of the CAN signal is the consumer, and the receiver of the CAN signal is the provider;

[0131] For the response data of the Method interface, the sender of the CAN signal is the provider, and the receiver of the CAN signal is the consumer.

[0132] In one embodiment, the apparatus further includes: a data generation module, configured to generate Ethernet data corresponding to the interface parameters of the service for each service before encapsulating the Ethernet data corresponding to the interface parameters of the service into a second message according to the corresponding communication protocol;

[0133] Specifically, the Ethernet data corresponding to the interface parameters of the service includes one of the following:

[0134] When the communication protocol is DDS protocol, Ethernet data corresponding to a topic is generated for each service interface of a single service, and the Ethernet data includes the interface parameters of the service; and the sender and receiver of each topic are determined according to the supply and demand relationship of the service, wherein one topic is generated for the Event interface and at most two topics are generated for the Method interface;

[0135] When the communication protocol is DDS, Ethernet data for a single service interface of the same type is generated for a single service. The Ethernet data includes the interface parameters of the service. The sender and receiver of each topic are determined according to the supply and demand relationship of the service. Specifically, one topic is generated for all Event interfaces of the service, and at most two topics are generated for all Method interfaces of the service. The sender and receiver of each topic are determined according to the supply and demand relationship of the service.

[0136] When the communication protocol is DDS protocol, Ethernet data of a topic is generated for the same service interface of different services. The Ethernet data includes the interface parameters of the service. The sender and receiver of each topic are determined according to the supply and demand relationship of the service. Specifically, one topic is generated for all Event interfaces of different services, and at most two topics are generated for all Method interfaces of different services.

[0137] When the communication protocol is SOME / IP, Ethernet data is generated based on the service identifier and service interface identifier of the service. The Ethernet data includes the interface parameters of the service. The service identifiers of different services are different, and the service interface identifiers of different service interfaces of the same service are different.

[0138] Figure 8 This is a schematic diagram of an SOA service architecture provided in an embodiment of this application. Figure 8 As shown, the SOA service architecture includes:

[0139] Service Library 10 is a collection of services that serves as the key to implementing service-oriented vehicle communication. It is responsible for isolating the physical and logical worlds, shielding upper-layer applications from differences in architecture, basic software, communication protocols, and hardware, thereby providing a stable system similar to a vehicle operating system (OS). The SOA service library is a large and comprehensive library, independent of architecture, and does not reflect architecture, ECU, or other information; it only provides functional abstractions.

[0140] Service deployment module 20 is used to determine the supply and demand relationship of services, as well as the software and hardware units and communication protocols for service deployment;

[0141] CAN signal library 30 is a collection of CAN signals. CAN signals can be automatically generated based on the service interface of the service, or they can be added manually.

[0142] The CAN signal matrix library 40 is used for message encapsulation based on CAN signals in the CAN signal library. The encapsulated fields may include message name, ID, message length, description, sender and receiver. It can also be used to encapsulate CAN signals, reference data in the SOA service library and perform layout, and specify the data start bit, signal length, unsigned / signed, precision and offset of each signal. It is also used to determine the CAN signal transmission and reception relationship according to the service deployment. The transmission and reception relationship of the message is determined by the service deployment module 20. The message encapsulation and transmission and reception relationship are strongly correlated and can change with the electronic and electrical architecture.

[0143] Ethernet matrix library 50 is used to map the interface parameters of the service to Ethernet data according to the topic based on the service interface, and to complete the message encapsulation according to the corresponding communication protocol. The message sending and receiving relationship is determined by the service deployment module 20, which is strongly associated with the electronic and electrical architecture and communication protocol, and can change with the electronic and electrical architecture.

[0144] like Figure 8 As shown, the SOA service library, as the largest collection of services across architectures, achieves a reuse rate of up to 90% across different architectures. The service deployment module can be used to determine the target supply and demand relationships of services and related hardware and software information. The CAN signal library, as the largest collection of CAN signals across architectures, allows most CAN signals to be automatically generated by the service interface. The CAN encapsulation module matrix can encapsulate messages based on CAN signals in the CAN signal library, mapping them to form a CAN matrix. The send / receive relationship can be determined by the service deployment module, and the message encapsulation and send / receive relationship are strongly correlated with the architecture and can change with the architecture. The Ethernet encapsulation module can encapsulate the corresponding communication protocol according to the service interface, mapping it to form an Ethernet matrix. The send / receive relationship of Ethernet data is determined according to the service deployment, and it is strongly correlated with the architecture and communication protocol, and can change with the architecture. In addition, by designing an automated tool from service to communication, the development and management of services and communication are realized, thereby reducing the management difficulty brought about by the increasingly complex vehicle communication and improving design efficiency and quality.

[0145] This application also provides a toolchain for rapidly implementing the above design and development, in order to maximize the degree of automation. The toolchain includes:

[0146] ①SOA Service Library Design

[0147] a) Requirements Introduction: Connecting with the interaction requirements and logical interfaces generated during the functional design process.

[0148] b) Interface design: Complete the service and interface design based on interaction requirements and logical interfaces.

[0149] c) Service review: Conduct online review of the completed service design.

[0150] d) Service Database: Supports the generation of service interface files (IDL, XML) and service code (provider and consumer).

[0151] e) Service deployment: Deployment and management of service design matrix, interface files, and service code.

[0152] ②Service Deployment

[0153] a) Supply and demand relationship: Determine the providers and consumers based on the distribution of functions and services across the architecture.

[0154] b) Deployment location: Specify the software and hardware carriers for the provider and the consumer.

[0155] c) Communication path: Specifies the communication protocol for communication between the service provider and the service consumer.

[0156] ③CAN matrix design

[0157] a) Automatic signal generation: Automatically generate a signal library based on the service design.

[0158] b) Signal addition: If one signal per interface cannot meet the functional requirements, signals can be added manually. The added signals must also be associated with the service interface.

[0159] c) Message design: CAN Message and layout design.

[0160] d) CAN Database: Generates the interface files (DBC / ARXML) required for CAN communication.

[0161] e) CAN Matrix Publishing: Publishing CAN matrix and database.

[0162] ④ Ethernet Matrix Design

[0163] DDS:

[0164] a) Automatic Topic Generation: Automatically generate topics and send / receive relationships according to established rules based on service design and service deployment.

[0165] b) Manual Topic Adjustment: Match a custom Topic to the service interface. The parameter definitions under the Topic cannot be adjusted.

[0166] c) QoS Configuration: Configure QoS for the Topic.

[0167] d) DDS Communication Matrix: Summarize all Topic and QoS correspondences to form an SOA matrix.

[0168] e) DDS Database: Generates the interface files and interface code required for SOA communication.

[0169] f) DDS Matrix Publishing: Publishing and managing DDS communication matrices and databases.

[0170] SOME / IP:

[0171] a) Automatic service binding: Automatically generate SOME / IP service IDs and interface IDs according to the service design and established rules, and generate SOME / IP service supply and demand relationships based on service deployment.

[0172] b) Manual Service Adjustment: Manually adjust the service ID and interface ID. Parameter definitions under the interface cannot be adjusted.

[0173] c) SOME / IP Communication Matrix: This matrix summarizes all SOME / IP service definitions and communication configurations to form a SOME / IP matrix.

[0174] d) SOME / IP Database: Generates the interface files and interface code required for SOME / IP communication.

[0175] e) SOME / IP Matrix Publishing: Publishing and managing SOME / IP communication matrices and databases.

[0176] Furthermore, this application also provides an electronic device that can be used to execute the vehicle communication method of any of the above embodiments. This electronic device may be, for example, an on-board controller, an ECU, or a vehicle infotainment system. Figure 9 A schematic diagram of an electronic device that can be used to implement embodiments of this application is shown. Electronic device 100 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic device 100 may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, user equipment, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the application described and / or claimed herein.

[0177] like Figure 9As shown, the electronic device 100 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 can also store various programs and data required for the operation of the electronic device 100. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0178] Multiple components in electronic device 100 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of monitors, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 100 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks and wireless networks.

[0179] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above.

[0180] In some embodiments, the methods described above can be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program can be loaded and / or installed on electronic device 100 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the methods described above can be performed. Alternatively, in other embodiments, processor 11 can be configured to perform the methods of any of the embodiments described above by any other suitable means (e.g., by means of firmware).

[0181] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0182] Computer programs used to implement the methods of this application may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0183] In the context of this application, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium can be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0184] To provide interaction with a user, the systems and techniques described herein can be implemented on electronic device 100, which includes: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to electronic device 100. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0185] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0186] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0187] This application also provides a computer program product, including a computer program and / or instructions, which, when executed by a processor, implement the vehicle communication method as described in any of the above embodiments.

[0188] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this application can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this application can be achieved, and this is not limited herein.

[0189] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A vehicle communication method, characterized in that, include: In response to a service event, determine the target service from the service repository; The communication path of the service event is determined based on the provider, consumer, and electrical / electronic architecture of the target service; Based on the communication path, the corresponding encapsulated message is retrieved from the matrix library, wherein the matrix library is a CAN signal matrix library or an Ethernet matrix library, and the encapsulated message is a first message or a second message. The CAN signal matrix library is used to encapsulate the CAN signal corresponding to the target service into a first message, and the Ethernet matrix library is used to encapsulate the Ethernet data corresponding to the target service into a second message. The encapsulated message is transmitted according to the communication path.

2. The method according to claim 1, characterized in that, Also includes: For each service, The interface parameters of the service are encapsulated in CAN signals and stored in a CAN signal library. The CAN signals are then encapsulated into messages according to the communication path and transmit / receive relationship, following the corresponding communication protocol. The first encapsulated message is then stored in a CAN signal matrix library. Alternatively... The Ethernet data corresponding to the interface parameters of the service is encapsulated into a second message according to the corresponding communication protocol and stored in the Ethernet database.

3. The method according to claim 2, characterized in that, It also includes: for each of the services, The software and hardware units are determined based on the service provider and consumer. The communication protocol corresponding to the service is determined based on the software unit and the hardware unit; The communication protocol includes at least one of the following: CAN protocol, IP-based scalable service-oriented middleware SOME / IP, and data distribution service DDS protocol.

4. The method according to claim 2, characterized in that, Before encapsulating the interface parameters of the service in a CAN signal, the following is also included: For each of the services, a CAN signal is generated based on the interface parameters of the service; The generation of CAN signals based on the interface parameters of the service includes: For the Event interface, at least one CAN signal is generated according to the data type of the interface parameters of the service. For data types of first complexity, the name of the generated CAN signal is determined according to the Event interface name. For data types of second complexity, a corresponding CAN signal is generated for each data element of the service. The name of the CAN signal is determined according to the Event interface name and the data element name. For the request data of the Method interface, at least one CAN signal is generated according to the data type of the interface parameters of the service. For data types of first complexity, the name of the generated CAN signal is determined according to the Event interface name and the request character. For data types of second complexity, a corresponding CAN signal is generated for each data element of the service. The name of the CAN signal is determined according to the Event interface name, the request character, and the data element name. For the response data of the Method interface, at least one CAN signal is generated according to the data type of the interface parameters of the service. For data types of first complexity, the name of the generated CAN signal is determined according to the Event interface name and the response character. For data types of second complexity, a corresponding CAN signal is generated for each data element of the service. The name of the CAN signal is determined according to the Event interface name, the response character, and the data element name. The second complexity is higher than the first complexity.

5. The method according to claim 4, characterized in that, Before encapsulating the CAN signal into a message according to the communication path and the transmit / receive relationship and the corresponding communication protocol, the method further includes: determining the transmit / receive relationship of the CAN signal; Determining the transmit / receive relationship of the CAN signal includes: For the Event interface, the sender of the CAN signal is determined to be the provider, and the receiver of the CAN signal is determined to be the consumer. For the request data of the Method interface, the sender of the CAN signal is the consumer, and the receiver of the CAN signal is the provider; For the response data of the Method interface, the sender of the CAN signal is the provider, and the receiver of the CAN signal is the consumer.

6. The method according to claim 2, characterized in that, Before encapsulating the Ethernet data corresponding to the interface parameters of the service into a second message according to the corresponding communication protocol, the process also includes: For each of the services, generate Ethernet data corresponding to the interface parameters of the service; The Ethernet data that generates the interface parameters for the service includes one of the following: When the communication protocol is DDS protocol, for each service interface of a single service, Ethernet data of a corresponding topic is generated. The Ethernet data includes the interface parameters of the service, and the sender and receiver of each topic are determined according to the supply and demand relationship of the service. Specifically, one topic is generated for the Event interface and at most two topics are generated for the Method interface. When the communication protocol is DDS, Ethernet data for a single service interface of the same type is generated for a single service. The Ethernet data includes the interface parameters of the service, and the sender and receiver of each topic are determined according to the supply and demand relationship of the service. Specifically, one topic is generated for all Event interfaces of the service, and at most two topics are generated for all Method interfaces of the service. The sender and receiver of each topic are determined according to the supply and demand relationship of the service. When the communication protocol is DDS protocol, Ethernet data of a topic is generated for the same service interface of different services. The Ethernet data includes the interface parameters of the service, and the sender and receiver of each topic are determined according to the supply and demand relationship of the service. Specifically, one topic is generated for all Event interfaces of different services, and at most two topics are generated for all Method interfaces of different services. When the communication protocol is SOME / IP, Ethernet data is generated based on the service identifier and service interface identifier of the service. The Ethernet data includes the interface parameters of the service. Different services have different service identifiers, and different service interfaces of the same service have different service interface identifiers.

7. A vehicle communication device, characterized in that, include: The service determination module is used to determine the target service from the service library in response to service events; The path determination module is used to determine the communication path of the service event based on the provider, consumer and electronic and electrical architecture of the target service; The retrieval module is used to retrieve the corresponding encapsulated message from the matrix library based on the communication path, wherein the matrix library is a CAN signal matrix library or an Ethernet matrix library, and the encapsulated message is a first message or a second message. The CAN signal matrix library is used to encapsulate the CAN signal corresponding to the target service into a first message, and the Ethernet matrix library is used to encapsulate the Ethernet data corresponding to the target service into a second message. A transmission module is used to transmit the encapsulated message according to the communication path.

8. An electronic device, characterized in that, include: At least one processor; A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor to enable the at least one processor to perform the vehicle communication method as described in any one of claims 1-6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by the processor, the program implements the vehicle communication method as described in any one of claims 1-6.

10. A computer program product comprising a computer program and / or instructions, characterized in that, When the computer program and / or instructions are executed by the processor, they implement the vehicle communication method as described in any one of claims 1-6.

Images