Communication method, device, electronic equipment and system based on SOA (Service Oriented Architecture)

Abstract

The invention provides a communication method and device based on an SOA architecture, electronic equipment, a chip and a medium, and relates to the technical field of software architecture and communication. The method comprises the following steps: receiving a first request message, and analyzing the first request message into a first service request through a first communication protocol; performing protocol mapping on the first service request to convert the first service request into a second service request; generating a first service interface by using the second service request, and executing the first service request by using the first service interface to generate first response data; converting the first response data into a first response message through protocol mapping, wherein the first response message supports a first communication protocol; and sending a first response message to the service consumer based on the first communication protocol. Through the technical scheme provided by the invention, the problems of poor compatibility, high coupling degree and low development efficiency of existing vehicle inter-domain communication are solved, a uniform interface is provided for the vehicle inter-domain communication, the communication performance is improved, the coupling degree is reduced, and the development efficiency of vehicle software is improved.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the field of software architecture and communication technology, in particular to a communication method and device based on SOA architecture, electronic equipment and system. BACKGROUND

[0002] With the increasing richness of automobile functions, the requirement for interaction performance is getting higher and higher. The current automobile software structure is complex, the underlying operating systems are different, and even different operating systems are carried in a single controller. On this basis, the communication protocol is also evolving. In the mainstream service-oriented architecture (SOA), the current mainstream inter-domain communication has Scalable service-Oriented Middleware over IP (SOME / IP) and Data Distribution Service (DDS) based on IP, and the inter-process communication (IPC) in the domain is also different for each operating system. Under such a heterogeneous underlying framework, the inter-domain communication compatibility of the vehicle is poor, the coupling degree between the application layer and the communication protocol layer is high, and the development efficiency of the vehicle software is low. SUMMARY

[0003] The present disclosure provides a communication method and device based on SOA architecture, electronic equipment, chip and medium to solve the problems of poor compatibility, high coupling degree and low development efficiency of the existing vehicle inter-domain communication. A unified interface is provided for vehicle inter-domain communication, the communication performance is improved, the coupling degree is reduced, and the development efficiency of vehicle software is improved.

[0004] The first aspect embodiment of the present disclosure provides a communication method based on SOA architecture, applied to a service provider, the method comprising:

[0005] receiving a first request message and parsing it into a first service request through a first communication protocol, wherein the first service request is an SOA service interface request initiated by a service consumer;

[0006] mapping and converting the first service request into a second service request, the second service request being a request recognizable by the service provider;

[0007] generating a first service interface using the second service request and executing the first service request using the first service interface to generate first response data;

[0008] converting the first response data into a first response message through protocol mapping, the first response message supporting the first communication protocol;

[0009] sending a first response message to the service consumer based on the first communication protocol.

[0010] In an embodiment of the present disclosure, before receiving the first request message and parsing the first service request through the first communication protocol, the method further comprises:

[0011] registering the first service using a preset service interface;

[0012] configuring a protocol binding between the first request message and the first service request using a preset interface protocol file;

[0013] publishing the first service to the service consumer.

[0014] In an embodiment of the present disclosure, the preset service interface comprises a service name, a service version, an interface name, an interface-associated Qos, an interface-associated parameter, and a parameter definition.

[0015] In an embodiment of the present disclosure, registering the first service using a preset service interface comprises:

[0016] importing the preset service interface into a registration center in the form of an interface description language to register the first service, the registration center being configured to save the first service, and the preset service interface comprising one or more of a service name, a service version, an interface name, an interface-associated Qos, an interface-associated parameter, and a parameter definition.

[0017] In an embodiment of the present disclosure, publishing the first service to the service consumer comprises:

[0018] creating service publishing information in response to a service version of the first service being marked as an active state, wherein the service publishing information comprises a publisher of the first service, a subscriber, a publisher of an Event interface, a publisher of a Method request, and a subscriber of a Method response;

[0019] encapsulating the service publishing information into a first publishing message and sending the first publishing message to a multicast address;

[0020] in a case where a message feedback sent by the service consumer is received, marking a publishing state of the first service, the message feedback being configured to identify whether the service consumer receives the first publishing message, and the publishing state comprising published and unpublished.

[0021] A second aspect embodiment of the present disclosure provides a communication method based on an SOA architecture, the method comprising:

[0022] generating a first service request;

[0023] converting the first service request into a first request message through protocol mapping;

[0024] sending a first request message to a service provider based on a first communication protocol;

[0025] receiving a first response message and parsing the first response message into second response data based on the first communication protocol, the first response message being generated by the service provider based on the first request message;

[0026] converting the second response data into first response data through protocol mapping for use by a service consumer.

[0027] In an embodiment of the present disclosure, before the first service request is generated, the method further comprises:

[0028] obtaining a first service published by the service provider;

[0029] checking a publication state of the first service;

[0030] if the publication state of the first service is not published, determining a service version mark of the first service;

[0031] checking the service version mark of the first service;

[0032] if the service version mark of the first service is in an inactive state, creating service search information and encapsulating the service search information into a first search message and sending the first search message to a multicast address, wherein the service search information includes a publisher of the first service, a subscriber, a publisher of an Event interface, a publisher of a Method request, and a subscriber of a Method response;

[0033] determining a search result of the first search message, the search result being obtained by the service provider using the first search message.

[0034] A third aspect embodiment of the present disclosure provides a communication device based on an SOA architecture, the device comprising:

[0035] a parsing module configured to receive a first request message and parse the first request message into a first service request based on a first communication protocol, wherein the first service request is an SOA service interface request initiated by a service consumer;

[0036] a mapping module configured to convert the first service request into a second service request through protocol mapping, wherein the second service request is a request recognizable by a service provider;

[0037] an execution module configured to generate a first service interface using the second service request and execute the first service request using the first service interface to generate first response data;

[0038] a conversion module configured to convert the first response data into a first response message through protocol mapping, wherein the first response message supports the first communication protocol;

[0039] The sending module is configured to send a first response message to the service consumer based on a first communication protocol.

[0040] A fourth aspect of the present disclosure provides a communication device based on an SOA architecture, applied to a service consumption method, and the device comprises:

[0041] The generating module is configured to generate a first service request.

[0042] The mapping module is configured to convert the first service request into a first request message through protocol mapping.

[0043] The sending module is configured to send the first request message to a service provider based on a first communication protocol.

[0044] The parsing module is configured to receive the first response message and parse the first response message into second response data through the first communication protocol, the first response message being generated by the service provider based on the first request message.

[0045] The conversion module is configured to convert the second response data into the first response data through protocol mapping for use by the service consumer.

[0046] A fifth aspect of the present disclosure provides a communication system based on an SOA architecture, comprising a service provider and a service consumer, the service provider comprising a first SOA middleware, and the service consumer comprising a second SOA middleware; the first SOA middleware comprising a first service interface, a first protocol mapping module and a first communication middleware, the second SOA middleware comprising a second protocol mapping module and a second communication middleware, the service provider and the service consumer being connected through a network.

[0047] The first SOA middleware receives a first request message of a service consumption application through the first communication middleware, parses the first request message into a first service request according to a communication protocol of the first communication middleware, and converts the first service request into a second service request by using the first protocol mapping module; the first service interface generates a first service interface using the second service request; the service provider application uses the first service interface to execute the first service request and generate first response data; the first protocol mapping module converts the first response data into a first response message supported by the communication protocol of the first communication middleware; and the first communication middleware sends the first response message to the second SOA middleware based on the communication protocol.

[0048] The second SOA middleware receives the first response message through the second communication middleware; parses the first response message into second response data through a communication protocol of the second communication middleware; and the second protocol mapping module of the second SOA middleware converts the second response data into the first response data, which can be used by the service consumption application.

[0049] In a sixth aspect, an electronic device is provided, comprising at least one processor, and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform any of the methods of the first aspect.

[0050] In a seventh aspect, a non-transitory computer-readable storage medium storing computer instructions is provided, wherein the computer instructions are configured to cause a computer to perform the method of the first aspect and / or the second aspect.

[0051] In an eighth aspect, a chip is provided, comprising at least one processor and a communication interface; the communication interface is configured to receive a signal input into the chip or output a signal from the chip, and the processor is in communication with the communication interface and implements any of the methods of the first aspect and the second aspect through a logic circuit or execution of code instructions.

[0052] In a ninth aspect, a vehicle is provided, comprising the communication device based on the SOA architecture of the third aspect or the fourth aspect, and / or a communication system based on the SOA architecture of the fifth aspect.

[0053] In summary, according to the communication method based on the SOA architecture of the present disclosure, a first request packet is received and parsed into a first service request through a first communication protocol, wherein the first service request is an SOA service interface request initiated by a service consumer, forming the starting data of data transmission and processing in the SOA architecture; the first service request is protocol-mapped and converted into a second service request, which is a request recognizable by a service provider, and the second service request is a unified interface data in the SOA architecture, which improves the compatibility of vehicle domain communication and reduces the coupling degree with the underlying communication protocol layer; the second service request is used to generate a first service interface, and the first service request is executed using the first service interface to generate first response data, which realizes the response of the service provider to the service request; the first response data is converted into a first response packet through protocol mapping, and the first response packet supports the first communication protocol, providing a unified interface for the service provider to feedback the response packet adapted to the underlying communication protocol; and the first response packet is sent to the service consumer based on the first communication protocol, completing the response to the service request of the service consumer. A unified interface is provided for vehicle domain communication, improving the communication performance, reducing the coupling degree, and improving the development efficiency of vehicle software.

[0054] It should be understood that the foregoing general description and the following detailed description are only exemplary and explanatory, and are not limiting to the present disclosure. BRIEF DESCRIPTION OF DRAWINGS

[0055] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments consistent with the present disclosure and, together with the description, further serve to explain the principles of the present disclosure and, do not limit the present disclosure.

[0056] Figure 1 A schematic diagram of a SOA model in the related art;

[0057] Figure 2 A schematic diagram of a Method type SOA service interface call interaction in the related art;

[0058] Figure 3 A schematic diagram of an Event type SOA service interface call interaction in the related art;

[0059] Figure 4 A schematic diagram of a DDS communication model in the related art;

[0060] Figure 5 A flowchart of a communication method based on a SOA architecture according to an embodiment of the present disclosure;

[0061] Figure 6 A schematic diagram of a scalable automotive SOA architecture Method call process compatible with DDS according to an embodiment of the present disclosure;

[0062] Figure 7 A schematic diagram of a scalable automotive SOA architecture Method request message compatible with DDS according to an embodiment of the present disclosure;

[0063] Figure 8 A schematic diagram of a scalable automotive SOA architecture Method response message compatible with DDS according to an embodiment of the present disclosure;

[0064] Figure 9 A schematic diagram of a scalable automotive SOA architecture Event subscription process compatible with DDS according to an embodiment of the present disclosure;

[0065] Figure 10 A schematic diagram of a scalable automotive SOA architecture Event subscription message compatible with DDS according to an embodiment of the present disclosure;

[0066] Figure 11 A schematic diagram of a scalable automotive SOA architecture Event data message compatible with DDS according to an embodiment of the present disclosure;

[0067] Figure 12 A flowchart of a publishing service according to an embodiment of the present disclosure;

[0068] Figure 13 A flowchart of registering a first service using a preset service interface according to an embodiment of the present disclosure;

[0069] Figure 14 A flow chart of publishing a first service to a service consumer according to an embodiment of the present disclosure;

[0070] Figure 15 A schematic diagram of a service publishing process of an extendable automotive SOA architecture compatible with DDS according to an embodiment of the present disclosure;

[0071] Figure 16 A schematic diagram of a service publishing message of an extendable automotive SOA architecture compatible with DDS according to an embodiment of the present disclosure;

[0072] Figure 17 A flow chart of a communication method based on an SOA architecture according to an embodiment of the present disclosure;

[0073] Figure 18 A flow chart of finding a service according to an embodiment of the present disclosure;

[0074] Figure 19 A schematic diagram of a service finding process of an extendable automotive SOA architecture compatible with DDS according to an embodiment of the present disclosure;

[0075] Figure 20 A schematic diagram of a service finding message of an extendable automotive SOA architecture compatible with DDS according to an embodiment of the present disclosure;

[0076] Figure 21 A communication system based on an SOA architecture according to an exemplary embodiment;

[0077] Figure 22 A schematic diagram of a method for developing each module and a calling relationship of an SOA architecture according to an embodiment of the present disclosure;

[0078] Figure 23 A schematic diagram of an interaction flow between each software module of an SOA architecture according to an embodiment of the present disclosure;

[0079] Figure 24 A schematic diagram of a communication apparatus based on an SOA architecture according to an embodiment of the present disclosure;

[0080] Figure 25 A schematic diagram of a communication apparatus based on an SOA architecture according to an embodiment of the present disclosure;

[0081] Figure 26 A block diagram of an electronic device for implementing a communication method based on an SOA architecture according to an exemplary embodiment of the present disclosure;

[0082] Figure 27 A schematic diagram of a chip according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0083] The embodiments of the present disclosure are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar notations identify the same or similar elements or elements having the same or similar functions throughout. The embodiments described below by reference to the drawings are exemplary and are intended to explain the present disclosure, and cannot be understood as a limitation of the present disclosure.

[0084] First, the related terms in the present disclosure are briefly introduced:

[0085] SOA: In the present disclosure, SOA is a component model that splits different functional units (called services) of an application program and connects them through well-defined interfaces and protocols between the services. The interface is defined in a neutral way, which should be independent of the hardware platform, operating system and programming language that implements the service. This allows services built in various systems to interact in a unified and universal way.

[0086] Figure 1 A schematic diagram of the SOA model in the related art is shown. As shown in the figure, there are mainly three roles in the SOA model, namely service provider, service consumer and service registry center. Among them, the service provider is the owner of the service, responsible for defining and implementing the service, publishing its own service to the service registry center for service consumers to find and call. The service consumer is the user of the service, which finds and calls the service. The service registry center is used to store service information and provide service registration and discovery. There are mainly three operations between the three roles, namely publishing service, finding service and binding and calling, wherein publishing service means that the service provider publishes service description, including service name, service ID, service version, service address and other information, so that the service consumer can find it. Finding service means that the service consumer queries the required service in the service registry center. Binding and calling means that the service consumer locates, contacts and calls the service according to the information in the service description.

[0087] The SOA service interface can be roughly divided into two types of Method and Event. Among them, Method is called by the service consumer input parameter, and the service provider completes the instruction and returns the result according to the calling request, and Event is the service provider actively sending data to the subscribed service consumer.

[0088] Figure 2 A schematic diagram of the Method type SOA service interface calling interaction in the related art is shown. As shown in the figure, the service provider publishes the service description to the service registry center, and the service consumer finds the service through the service registry center, and then binds and calls the service. Figure 2As shown, the service consumer initiates a Method request to the service provider when the service is needed, the service provider processes the request, and provides a Method response to the service consumer, completing the interaction of the Method type SOA service interface call.

[0089] Figure 3 A schematic diagram of the interaction of the Event type SOA service interface call in the related art is shown. Figure 3 As shown, the service consumer subscribes to the service provided by the service provider through subscribing to the service interface of the Event type, and the service provider sends the service interface of the Event type to the service consumer when the service is needed, completing the interaction of the Event type SOA service interface call.

[0090] SOME / IP: In the present disclosure, SOME / IP refers to IP-based scalable service-oriented middleware, which is a mainstream protocol for inter-domain communication in the vehicle field. In 2011, BMW announced the SOME / IP protocol to implement the SOA model on the car controller, and subsequently SOME / IP was integrated by AUTOSAR and rapidly used in the automotive industry.

[0091] DDS: In the present disclosure, DDS refers to data distribution service, which is a distributed real-time communication middleware protocol that adopts a publish / subscribe architecture and emphasizes data-centricity. Data is identified by Topic, so that the publisher publishes data according to the topic, and the subscriber subscribes to data according to the topic of interest.

[0092] Figure 4 A schematic diagram of the DDS communication model in the related art is shown. Figure 4 As shown, the publisher (DataWriter) writes and publishes data, and the subscriber (DataReader) subscribes to the data published by the publisher, i.e., reads the data already published by the publisher, thereby completing the communication of the data of the subscriber and the publisher.

[0093] The current automotive software structure is complex, the underlying operating systems are different, and even different operating systems are carried inside a single controller, and on this basis, the communication protocol is also evolving. The current mainstream inter-domain communication is SOME / IP and DDS, and the intra-domain IPC communication is also different for different operating systems. Under such a heterogeneous underlying framework, if the application layer is directly coupled with the communication protocol layer, then with the change of the interface of the communication protocol, the application layer also needs to be changed, which will increase a lot of development work, making the automotive software development inefficient.

[0094] The mainstream SOA middleware SOME / IP in the industry has the disadvantages of low throughput and insufficient real-time performance. With the increasing demand for interaction performance of automotive functions, SOME / IP cannot meet the performance requirements of businesses in certain fields (such as intelligent driving and vehicle control). DDS, which has high throughput and low latency performance, has become a new middleware option. However, DDS is a protocol based on the publish / subscribe model, which is inconsistent with the Client / Server model of SOA. SOME / IP and DDS are two major SOA communication middleware in the automotive industry, each with its own characteristics. SOME / IP protocol is simple and requires less resources, but has high latency in large data transmission.

[0095] From the perspective of upper-layer application iteration, the smaller the granularity of services, the higher the flexibility of application calls. However, from the perspective of communication resources, DDS resource consumption and Topic quantity are positively correlated, so it is necessary to reduce the number of Topics to save controller resources, that is, the Topic granularity should be as large as possible. That is, there is a contradictory demand in the granularity selection of upper-layer software interface and communication protocol interface.

[0096] RPC is a core technology for implementing SOA, and the current DDS protocol does not have a clear implementation plan. DDS-based RPC is designed and developed by DDS protocol vendors to support OEMs in implementing SOA architecture. This may lead to inconsistencies, and changes to the protocol stack may affect the performance and stability of basic functions.

[0097] DDS provides a wide range of Qos to ensure communication performance, which is certainly a good thing. However, SOME / IP or operating system IPC do not support these Qos, which means that the dependence of these Qos on the application and DDS is bound together, and the protocol will be modified as soon as the function logic is changed. Of course, there is another way to customize the development of the corresponding Qos in the new protocol, but protocol switching is actually a relatively frequent thing in architecture evolution. Many OEMs in the automotive industry are also developing their own communication protocols, which has brought a lot of repetitive work. Moreover, it requires developers to be familiar with each communication protocol and to implement Qos, which is obviously not a good choice.

[0098] In summary, the inter-domain communication of vehicles is different for different operating systems. In this heterogeneous underlying framework, the compatibility of inter-domain communication of vehicles is poor, the communication performance is low, the coupling degree between the application layer and the communication protocol layer is high, and the development efficiency of vehicle software is low.

[0099] The method proposed in the present disclosure is applied to communication tasks based on the SOA architecture, which has a wide range of applications. For the problems of non-uniform inter-domain communication of vehicles, software incompatibility, and low software development efficiency in ECUs, the overall design of the communication protocol based on the SOA architecture unifies the interfaces of different devices and different applications in inter-domain communication, reduces the coupling degree of the application layer and the communication protocol layer, and improves the development efficiency of vehicle software, which can be widely used in:

[0100] Full vehicle intelligence: The application of SOA service enables intelligent interconnection of various parts of the vehicle, thereby promoting the intelligent development of the entire vehicle.

[0101] Software updating and upgrading: Based on the design of the SOA architecture, the updating and upgrading of vehicle software can be faster and more efficient, because the high cohesion between services makes software easier to reuse and replace.

[0102] Functional modularity: Vehicle functions are designed as different service components, which have unique identity and can be independently published and subscribed to realize communication with other services, which improves the flexibility and scalability of the system.

[0103] Vehicle-to-Everything communication: With the introduction of vehicle Ethernet and domain controllers, the SOA architecture can support communication between vehicles and external networks, providing technical support for vehicle-to-Everything.

[0104] Optimization of electronic and electrical architecture: SOA optimizes the electronic and electrical architecture of the vehicle from the software level, which complements the electronic and electrical architecture from the hardware level, and together improves the performance of the electronic and electrical system of the vehicle.

[0105] Scenario engine application: Through SOA, various open capabilities of the vehicle can be defined as services, so that the scenario engine can access other vehicle services such as perception, map, and body data, and control vehicle behavior such as lights and music in real time according to the configuration.

[0106] In summary, the application of SOA architecture in vehicles helps to improve the intelligence level of vehicles, optimize the use of software and hardware resources, enhance the flexibility and scalability of vehicle functions, and support the development of vehicle-to-Everything technology. With the continuous progress of automotive technology, the application of SOA architecture in vehicles will become more and more widespread. The application scenarios in the embodiments of the present disclosure are not limited.

[0107] The SOA architecture-based communication method provided by the present disclosure will be described in detail below with reference to the accompanying drawings.

[0108] Figure 5 A flowchart of an SOA architecture-based communication method according to an embodiment of the present disclosure. The SOA middleware is applied to the service provider, such as Figure 5In the illustrated embodiment, the SOA architecture-based communication method includes:

[0109] In step 501, a first request message is received and parsed into a first service request through a first communication protocol, wherein the first service request is an SOA service interface request initiated by a service consumer.

[0110] In this embodiment, the first request message refers to a service request message initiated by a service consumer to a service provider. The first communication protocol refers to a communication protocol followed by in-vehicle domain communication. Optionally, the first communication protocol includes SOME / IP, DDS, IPC, etc. The first service request refers to a service request parsed from the first request message through the first communication protocol, which is an SOA service interface request initiated by the service consumer. The service provider takes the first request message as the starting data for data transmission and processing in the SOA architecture.

[0111] In step 502, the first service request is protocol-mapped and converted into a second service request, which is a request recognizable by the service provider.

[0112] In this embodiment, protocol mapping refers to associating or binding the protocol between the first communication protocol and the service interface, for example, the first service request is in the DDS protocol, and the first service request is converted into a service interface compatible with the DDS protocol, i.e., the second service request. The second service request is a unified interface data in the SOA architecture, which is a request recognizable by the service provider. Preferably, when the first communication protocol is the DDS protocol, the performance of communication can be provided.

[0113] In step 503, a first service interface is generated using the second service request, and the first service request is executed using the first service interface to generate first response data.

[0114] In this embodiment, the first service interface refers to an application interface related to the second service request obtained from an Application Programming Interface (API) set. The first response data refers to feedback data generated after the first service interface executes the first service request. After obtaining the second service request, the first service interface is generated using the second service request, and the first service request is executed using the first service interface, i.e., the first response data is generated. Thus, the service provider can respond to the first service request.

[0115] In step 504, the first response data is converted into a first response message through protocol mapping, and the first response message supports the first communication protocol.

[0116] The first response message refers to a data message adapted to the first communication protocol for transmission after the first response data is converted by protocol mapping in the embodiment. The feedback response message for the service provider provides a unified interface adapted to the underlying communication protocol.

[0117] In step 505, the first response message is sent to the service consumer based on the first communication protocol.

[0118] In the embodiment, the first response message is sent to the service consumer through the first communication protocol, thereby completing the response to the service request of the service consumer.

[0119] In one embodiment of the embodiment, Figure 6 A schematic diagram of the Method calling process of the scalable automobile SOA architecture compatible with DDS of the embodiment is shown. As shown in the figure, Figure 6 The service consumer application of the Method calling service consumer initiates, and since the service consumer application needs to use the service, the Method request is initiated. The service related to the Method request is determined in the API set in the business interface, and the Method request is processed into a request interface containing the service name, service version, Method name and Method request. The request interface is converted into a first request message (Method request message) adapted to the underlying communication protocol for transmission by the protocol mapping module, and the first request message contains the service name, service version, Method name, Method request and service provider address. The first request message is sent to the service provider through the communication protocol. The data is sent to the service provider in the form of an Ethernet message or shared memory.

[0120] The service provider receives the first request message, parses the first request message into a first service request through a communication protocol, and the first service request includes a service name, a service version, a Method name, and a Method request. The first service request is converted into a second service request through a protocol mapping module, and the second service request includes a service name, a service version, a Method name, and a Method request. The second service request generates a first service interface through a service interface, and the first service interface includes a Method request and an API required by the request. The service implementation application processes the Method request after receiving the first service interface, executes the first service request, generates first response data, and arranges the APIs used in the service interface to obtain a service name, a service version, a Method name, a Method response, and a service consumer address for the first response data. The first response data is extended and converted into a first response message through protocol mapping, and the first response message includes a service name, a service version, a Method name, a Method response, and a service consumer address. The first response message is adapted to the underlying communication protocol. Based on the underlying communication protocol, the first response message is sent to the service consumer according to the service consumer address. The data is sent to the service consumer in the form of an Ethernet message or shared memory.

[0121] The communication protocol of the service consumer receives and parses the first response message, obtains a service name, a service version, a Method name, and a Method request as second response data, converts the second response data into first service interface data through a protocol mapping module, and the first service interface data includes a service name, a service version, a Method name, and a Method response. After determining the interface that can support the service consumer application in the API set of the service interface, the Method request of the service consumer application is responded to.

[0122] In the embodiment, the API in the service interface is independent of a specific deployment environment and a programming language, and is generally selected in the form of an interface definition language (Interface Definition Language, IDL) for interface definition. After definition, an interface program in a service interface generation response environment is generated, and the interface provided by the service interface can be directly used when the service is called.

[0123] In an embodiment of the embodiment, Figure 7 A schematic diagram of a Method request message of an extensible automobile SOA architecture compatible with DDS in the embodiment. As shown in FIG. 1, the Method request message includes a service name, a service version, a Method name, and a Method request. Figure 7As shown, the SOA architecture Method request realizes compatibility with DDS, and includes seven fields, an Ethernet header, a DDS header, and a DDS payload including five fields, wherein the DDS payload includes five fields of a Method request flag, a service name, a service version, a Method name, and a Method request.

[0124] In an embodiment of the present embodiment, Figure 8 A schematic diagram of a Method response message of an extendable automotive SOA architecture compatible with DDS according to the present embodiment is shown in FIG. 6. As shown, Figure 8 As shown, the SOA architecture Method response realizes compatibility with DDS, and includes seven fields, an Ethernet header, a DDS header, and a DDS payload including five fields, wherein the DDS payload includes five fields of a Method request flag, a service name, a service version, a Method name, and a Method response. Figure 7

[0125] In an embodiment of the present embodiment, Figure 9 A schematic diagram of an Event subscription process of an extendable automotive SOA architecture compatible with DDS according to the present embodiment is shown in FIG. 7. As shown, Figure 9 As shown, a service consumer subscribes to a service of a service provider, and a service consumption application of the service consumer initiates a subscription request including a service name and an Event name. A service required in the subscription request is determined in a set of APIs in a business interface, and the subscription request is processed into a request interface including a service name, a service version, and an Event name. The request interface is converted into a first request message (Event subscription message) suitable for transmission of a bottom-layer communication protocol by a protocol mapping module, and the first request message includes a service name, a service version, an Event name, and a receiving Event address. The first request message is sent to the service provider through the communication protocol. The data is sent to the service provider in the form of an Ethernet message or shared memory.

[0126] ​The service provider receives the first request message, parses the first request message into a first service request through a communication protocol, and the first service request includes a service name, a service version, an Event name, and a receiving Event address. The first service request is converted into a second service request through a protocol mapping module, and the second service request includes a service name, a service version, and an Event name. The second service request generates a first service interface through a service interface, and the first service interface includes a service name, a service version, an Event name, and an API required by the request. The service implementation application processes the subscription request after receiving the first service interface, executes the first service request to generate first response data (Event), and arranges the API used in the service interface to obtain a first response data including a service name, a service version, an Event name, Event data, and a receiving Event address. The first response data is converted into a first response message through protocol mapping, and the first response message includes a service name, a service version, an Event name, Event data, and a receiving Event address. The first response message is adapted to the underlying communication protocol. Based on the underlying communication protocol, the first response message is sent to the service consumer according to the service consumer address. The data is sent to the service consumer in the form of an Ethernet message or shared memory.

[0127] The communication protocol of the service consumer receives and parses the first response message to obtain a service name, a service version, an Event name, Event data, and a receiving Event address as second response data. The second response data is converted into first service interface data through a protocol mapping module, and the first service interface data includes a service name, a service version, an Event name, and Event data. After determining the interface that can support the service consumer application in the API set of the service interface, the Event data subscribed by the service consumer application is obtained.

[0128] When the service consumer application needs to use a certain Event, an Event subscription request is sent to the service interface module of the service consumer application. The Event subscription request includes a service name, a service ID, a service version, and an Event name (multiple can be subscribed together). The service interface is sent to the protocol mapping module, and the protocol mapping module adds a receiving Event network address and then sends it to the underlying communication protocol, for example, a communication protocol module, which sends it to the service provider using DDS.

[0129] The service provider receives the Event subscription request and transmits it layer by layer in the order of the protocol mapping module, the service interface module, and the service implementation application. The service implementation application receives the Event subscription request and sends the Event according to the sending mechanism defined by the Event, and then sends it to the consumer layer by layer.

[0130] The event subscription should be valid in this power-on cycle, so the consumer does not need to repeatedly send the subscription message. When the consumer no longer needs the event, the subscription can be stopped by sending a stop subscription request.

[0131] In an embodiment of the present embodiment, Figure 10 An event subscription message diagram of an extendable automotive SOA architecture compatible with DDS is provided in the present embodiment. As shown in the figure, Figure 10 The SOA architecture event subscription is compatible with DDS, and includes seven fields, an Ethernet header, a DDS header, and a DDS payload including five fields. The DDS payload includes an event subscription flag, a service name, a service version, an event name, and an event receiving address.

[0132] In an embodiment of the present embodiment, Figure 11 An event data message diagram of an extendable automotive SOA architecture compatible with DDS is provided in the present embodiment. As shown in the figure, Figure 11 The SOA architecture event subscription is compatible with DDS, and includes seven fields, an Ethernet header, a DDS header, and a DDS payload including five fields. The DDS payload includes an event subscription flag, a service name, a service version, an event name, and an event receiving address. Figure 10

[0133] In summary, according to the communication method based on the SOA architecture provided in the present disclosure, a first request message is received and parsed into a first service request through a first communication protocol, wherein the first service request is an SOA service interface request initiated by a service consumer, forming the starting data for data transmission and processing in the SOA architecture. The first service request is protocol-mapped and converted into a second service request, which is a request recognizable by a service provider. The second service request is a unified interface data in the SOA architecture, improving the compatibility of vehicle domain communication and reducing the coupling degree with the underlying communication protocol layer. The second service request is used to generate a first service interface, and the first service request is executed using the first service interface to generate a first response data, realizing the response of the service provider to the service request. The first response data is converted into a first response message through protocol mapping, and the first response message supports the first communication protocol, providing a unified interface for the service provider to adapt to the underlying communication protocol. The first response message is sent to the service consumer based on the first communication protocol, completing the response to the service request of the service consumer. A unified interface is provided for vehicle domain communication, improving the communication performance, reducing the coupling degree, and improving the development efficiency of vehicle software. ​

[0134] Figure 12 A flowchart of a publishing service according to an embodiment of the present disclosure. Figure 12 is a further explanation of step 501 of Figure 5 According to the embodiment shown in Figure 12 includes the following steps:

[0135] Step 1201, registering the first service using a preset service interface.

[0136] In this embodiment, the preset service interface refers to an interface supported by a pre-configured service in a service interface API set. The first service refers to different functional units of an application program. By registering the first service using the preset service interface, the first service can be registered as a service to be published.

[0137] Step 1202, performing protocol binding of the first request message and the first service request using a preset interface protocol configuration file.

[0138] In this embodiment, according to the preset interface protocol configuration file, a code supporting the communication protocol of the first request message and the first service request is generated using a special tool. Thus, the first request message and the first service request are protocol-bound.

[0139] Step 1203, publishing the first service to a service consumer.

[0140] In this embodiment, after the first service is registered at the service provider, the first service is published to the service consumer. The registration of the service at the service provider is completed, and the service is dynamically registered. This helps the service consumer to use the service provided by the service provider in time, and improves the development efficiency of the vehicle software.

[0141] Figure 13 A flowchart of registering a first service using a preset service interface according to an embodiment of the present disclosure. Figure 13 is a further explanation of step 1201 of Figure 12 According to the embodiment shown in Figure 13 includes the following steps:

[0142] Step 1301, importing the preset service interface in the form of an interface description language into a registration center to register the first service, the registration center being used to save the first service, and the preset service interface including one or more of a service name, a service version, an interface name, an interface associated Qos, an interface associated parameter, and a parameter definition.

[0143] In the embodiment, the interface description language refers to a specification language for defining the interface of a software component, and is used for communication between programs written in different programming languages. It provides a standard way to describe the interface of an object, including methods, properties, and events, etc. Through the IDL, programming language-specific code stubs and skeletons can be generated, which can help developers establish a communication mechanism between the client and the server. The registry refers to a module for storing and classifying services in the service provider or the service consumer. The preset service interface is statically registered, that is, the preset service interface is imported into the registry, so that the registration of the first service is completed. The preset service interface includes one or more of the service name, the service version, the interface name, the Quality of Service (Qos) associated with the interface, the interface associated parameter, and the parameter definition. The Qos refers to a measure of the ability of a system to meet user needs and performance standards, and involves performance, reliability, scalability, security, interoperability, etc., which helps to improve user experience and overall system performance.

[0144] Figure 14 A flowchart for publishing a first service to a service consumer according to an embodiment of the present disclosure. Figure 14 is a specific description of step 1202 of Figure 12 , based on the embodiment shown in Figure 14 , including the following steps:

[0145] Step 1401, in response to the service version of the first service being marked as an active state, creating service publishing information, wherein the service publishing information includes the publisher, the subscriber, the publisher of the Event interface, the publisher of the Method request, and the subscriber of the Method response of the first service.

[0146] In the embodiment, the service publishing information refers to the publication information for facilitating the service consumer to discover the service provided by the service provider, and includes the publisher, the subscriber, the publisher of the Event interface, the publisher of the Method request, and the subscriber of the Method response of the first service. When the service version of the first service is marked as an active state, it indicates that the first service can be published, and then the service publishing information is created.

[0147] Step 1402, encapsulating the service publishing information into a first publishing message and sending it to a multicast address.

[0148] In the embodiment, the first publishing message refers to a data message containing service publishing information, which is used to notify the service consumer through multicast. The multicast address refers to a specified network address for IP multicast communication. After the service publishing information is encapsulated into the first publishing message, the first publishing message is published to all addresses in the multicast address by using multicast communication.

[0149] Step 1403: When receiving the message feedback sent by the service consumer, mark the publishing status of the first service. The message feedback is used to identify whether the service consumer has received the first publishing message. The publishing status includes published and unpublished.

[0150] In this embodiment, when a message feedback is received from a service consumer, the publishing status of the first service is marked. The message feedback is an identifier indicating whether the service consumer has received the first publishing message. The publishing status of the first publishing message includes published and unpublished.

[0151] In this embodiment, the service provider publishes the service to the service consumer and provides service information that can be called, thereby improving the development efficiency of the in-vehicle software service.

[0152] In one implementation of this embodiment, Figure 15 FIG. 1 is a schematic diagram of a DDS-compatible and extensible automotive SOA architecture service publishing process of this embodiment. Figure 15 As shown, the purpose of service publishing is to inform other applications that the published service is available and to inform the other party of the address provided by the service. After the service is available, the service implementation application calls the service publishing interface provided by the service registration center to publish the service. The input accepted by the service publishing interface includes the service name, service version, service interface information, and interface QoS information. After receiving it, the service registration center will mark the corresponding service version status as activated. The service registration center passes the service publishing information to the protocol mapping module. After receiving it, the protocol mapping module will call the create publisher interface provided by the communication protocol module. Preferably, the communication protocol module supports the DDS communication protocol, inputs the service name, service version, service interface information, interface QoS, service address and other information into the publisher interface, creates the publisher of the service publishing, subscribers of the service search, publishers of the event interface in the service, publishers of the method request in the service, and subscribers of the method response in the service. After the creation is completed, the communication protocol module (supporting the DDS communication protocol) will encapsulate the service publishing information into a service publishing Topic message and send it to the multicast address. All potential service consumers will listen to this multicast address.

[0153] After receiving a Topic message published by a service, a node listening on a multicast address reports the service release information to the protocol mapping module within its own node. The service release information includes the service name, service version, service interface information, interface QoS, service address, and other information. The protocol mapping module then uploads it to the service registration center, which marks the service status as active and then reports the service release information to the service consuming application. After receiving the service release information, the service consuming application considers the service available for use.

[0154] In one implementation of this embodiment, Figure 16 This is a schematic diagram of a DDS-compatible and scalable automotive SOA architecture service publishing message in this embodiment. Figure 16 As shown in the figure, the SOA architecture achieves compatibility with DDS. The service publishing message contains seven fields, Ethernet header, DDS header and DDS payload containing five fields. Among them, the DDS payload includes five fields: publishing flag, service name, service version, service interface information and QoS configuration.

[0155] Figure 17 The flowchart of a communication method based on SOA architecture in the embodiment of the present disclosure is shown in FIG. Figure 17 In the embodiment shown, the communication method based on the SOA architecture includes:

[0156] Step 1701: Generate a first service request.

[0157] In this embodiment, the first service request refers to a service that a service consumer needs to implement a certain function and is a request initiated to obtain the service.

[0158] Step 1702: Convert the first service request into a first request message through protocol mapping.

[0159] In this embodiment, the first request message refers to a data message sent by the service consumer to the service requester to obtain a service. Protocol mapping is used to convert the first service request into the first request message. This conversion is performed using a dedicated conversion tool to generate the code for the first request message from the first service request. Step 1703: Send the first request message to the service provider based on the first communication protocol.

[0160] In this embodiment, the first request message is sent to the service provider using the first communication protocol to obtain the service.

[0161] Step 1704: Receive a first response message, and parse the first response message into second response data through the first communication protocol, where the first response message is generated by the service provider based on the first request message.

[0162] Step 1705: Convert the second response data into first response data through protocol mapping for use by the service consumer.

[0163] In this embodiment, after determining the second response data, the second response data is converted into the first response data through protocol mapping. The first response data supports the first communication protocol and can be used by the service consumer. Protocol mapping reduces the coupling between the application layer and the protocol layer, improving the communication performance and compatibility of the in-vehicle software.

[0164] In this embodiment, the first response message refers to a response message fed back by the service provider in response to the first service request. The first response message corresponds to the first request message, and the first response message is a response message provided by the service provider according to the first request message of the service consumer. The second response data refers to data obtained after the first response message is parsed through the first communication protocol. After the service consumer sends the first request message to the service provider, the feedback of the service provider, that is, the first response message, is received. The second response data is obtained after the message is parsed through the first communication protocol. The service request and response of the service consumer to the service provider are completed. A unified interface is provided for vehicle inter-domain communication, the coupling degree of the communication application layer and the protocol layer is reduced, the compatibility of vehicle inter-domain communication is improved, and the development efficiency of vehicle software is improved. Figure 18 A flowchart for finding a service according to an embodiment of the present disclosure. Figure 18 is a specific description before step 1701 of Figure 17 based on the embodiment shown in Figure 18 includes the following steps:

[0165] In step 1801, the first service published by the service provider is obtained.

[0166] In this embodiment, when the service consumer uses the service, it needs to determine whether the target service (the first service) has been published. The service consumer obtains the first service through the registration center.

[0167] In step 1802, the publishing state of the first service is checked.

[0168] In this embodiment, the state of the first service is checked according to the obtained first service.

[0169] In step 1803, if the publishing state of the first service is not published, the service version mark of the first service is determined.

[0170] In this embodiment, if the publishing state of the first service is the not published state, the service version mark of the first service is further determined.

[0171] In step 1804, the service version mark of the first service is checked.

[0172] In this embodiment, the service version mark of the first service is checked to be in an active state or an inactive state.

[0173] In step 1805, if the service version mark of the first service is in the inactive state, service finding information is created, and the service finding information is encapsulated as a first finding message and sent to a multicast address, wherein the service finding information includes the publisher of the first service, the subscriber, the publisher of the Event interface, the publisher of the Method request, and the subscriber of the Method response.

[0174] In this embodiment, the first search message refers to the message data obtained by encapsulating the service search information. If the service version of the first service is marked as inactive, then service search information is created to provide a basis for searching the service. The service search information includes information such as the publisher, subscriber, publisher of the Event interface, publisher of the Method request, subscriber of the Method response, etc. of the first service. The service search information is encapsulated into a first search message, and the first search message is sent to the multicast address to determine whether the first service exists at the multicast address.

[0175] Step 1806: Determine the search result of the first search message, where the search result is obtained by the service provider using the first search message.

[0176] In this embodiment, the search result of the first search message is determined, and the search result is obtained after the service provider uses the first search message to search the registration center.

[0177] In one implementation of this embodiment, Figure 19 FIG. 1 is a schematic diagram of a DDS-compatible and extensible automotive SOA architecture service search process according to this embodiment. Figure 19 As shown, when a service consumption application needs to use a certain service but has not received the service publication of the service, it will send a service search request to the service registration center. The service registration center will search for the status of the service and feedback to the service consumption application if it is in the active state. If the service registration center's search result is inactive, it will send a service search request to the protocol mapping module. After receiving it, the protocol mapping module will call the publisher / subscriber creation interface provided by the communication protocol module (DDS) to create a publisher for service search, a subscriber for service publication, a subscriber for the Event interface in the service, a publisher for the Method request in the service, and a subscriber for the Method response in the service. After the creation is completed, the communication protocol module will encapsulate the service search information into a service search Topic message and send it to the multicast address.

[0178] After receiving the service lookup Topic message, the server-side communication protocol module (DDS) reports the service lookup information to the protocol mapping module within its own node. The protocol mapping module then uploads it to the service registration center, which in turn reports it to the service implementation application. After receiving the service lookup information, the service implementation application sends a service release message if the service is available. If the service is unavailable, it reports the service unavailable, and then passes it to the service consumer layer by layer.

[0179] In one implementation of this embodiment, Figure 20 This is a schematic diagram of a DDS-compatible and scalable automotive SOA architecture service search message in this embodiment.Figure 20 As shown, the SOA architecture service lookup implementation is compatible with DDS, and the service lookup message includes seven fields, an Ethernet header, a DDS header, and a DDS payload including five fields, wherein the DDS payload includes five fields, a lookup flag, a service name, a service version, service interface information, Qos configuration, and a consumer address.

[0180] Figure 21 A SOA architecture-based communication system according to an exemplary embodiment is shown. The system includes a service provider and a service consumer, the service provider including a first SOA middleware; the service consumer including a second SOA middleware;

[0181] The first SOA middleware includes a first service interface, a first protocol mapping module, and a first communication middleware, and the second SOA middleware includes a second protocol mapping module and a second communication middleware, and the service provider and the service consumer are connected through a network;

[0182] The first SOA middleware receives a first request message of a service consumer application through the first communication middleware, parses the first request message into a first service request according to a communication protocol of the first communication middleware, converts the first service request into a second service request using the first protocol mapping module, and generates a first service interface using the second service request; the service provider application uses the first service interface to execute the first service request and generate first response data; the first protocol mapping module converts the first response data into a first response message supported by the communication protocol of the first communication middleware; and the first communication middleware sends the first response message to the second SOA middleware based on the communication protocol.

[0183] The second SOA middleware receives the first response message through the second communication middleware; parses the first response message into second response data through a communication protocol of the second communication middleware; and the second protocol mapping module of the second SOA middleware converts the second response data into the first response data, which can be used by the service consumer application.

[0184] In this embodiment, the first protocol mapping module and the second protocol mapping module are software components with the same function, the first communication middleware and the second communication middleware are software components with the same function, the first service interface is used to generate a service interface according to a service interface file, which is called by a service implementation application or a service consumption application. The protocol mapping module is used to map the interaction data generated in the service calling process to the communication protocol of the first communication middleware or the second communication middleware. The first communication middleware and the second communication middleware are used to realize the access and adaptation of multiple communication protocols, and provide interface calling for the SOA middleware, wherein the communication protocols include DDS, SOME / IP and IPC; the service provider and the service consumer are connected through a network connection, and the network connection includes Wifi, mobile network (5G, 4G, 3G), data transmission line and the like. The first SOA middleware and the second SOA middleware further include a registration center and a QoS management with the same function, the registration center is used to register and store the services provided by the service implementation application, and provide the service consumer with the publishing and searching of the services. The service interface of the second SOA middleware is used to generate a service interface according to a service interface file, which is called by a service implementation application or a service consumption application. The QoS management is used to realize and manage the QoS of the service interface, and the protocol mapping module is further used to provide the registration center and the service interface with a standard interface that shields the protocol differences.

[0185] In this embodiment, after the service provider completes the response to the first request message of the service consumer, the protocol mapping is used to realize the coupling degree of the software modules in the vehicle domain communication, provide a unified interface and improve the communication performance. The service consumer receives the first response data of the service provider, and through analysis and protocol mapping, the first response data that can be directly used is obtained, the coupling degree of each module in the vehicle domain communication is reduced, the communication performance is improved, and the development efficiency of the vehicle software is improved.

[0186] Figure 22 is a schematic diagram of a development method and calling relationship of each module based on the SOA architecture according to an embodiment of the present disclosure. As shown in Figure 22 After the SOA service design is completed, a service interface file needs to be generated, which can be in the form of IDL or Extensible Markup Language (XML), and contains all the service definition information, including: service name, service version, interface name, interface type, interface parameter, parameter definition, Qos configuration and the like. After the interface file is generated, professional code generation tools can be used to generate the interface code of the provider and the consumer respectively.

[0187] The service implementation application and the service consumption application can respectively call the interface code of the provider and the consumer to implement the logic operation related to the service. The purpose of doing so is to decouple the application and the lower communication protocol, so that the protocol is changed without changing the application, and the application is updated without affecting the communication protocol.

[0188] The interaction data generated by the service registry center and the service interface is finally transmitted through the underlying communication protocol, and the mapping between them is completed by the protocol binding module. The mapping relationship between them is also embodied by the configuration file, and the code of this module can be directly generated by using a professional code generation tool. Multiple interfaces are allowed to be mapped to the same DDS Topic, and in this way, the controller resources and network bandwidth can be saved.

[0189] After the protocol binding, a specific protocol is needed to complete the communication, and the interface of the protocol is configured through the protocol interface document, and the software code of the protocol layer is generated through a professional tool.

[0190] Figure 23 is a schematic diagram of the interaction process between various software modules based on the SOA architecture according to an embodiment of the present disclosure. As shown in Figure 23 The interaction between various software modules based on the SOA architecture can be divided into three stages: service discovery, Method calling, and Event subscription.

[0191] The first stage is service discovery, and the service discovery includes service registration, service publishing, and service lookup.

[0192] The service registration and the service publishing are initiated by the service provider, and the service lookup is initiated by the service consumer.

[0193] The service registration includes dynamic registration and static registration. The dynamic registration is the service registration performed by the service provider application calling the interface provided by the service registry center, and the service name, the service version, the interface name, the Qos associated with the interface, the interface associated parameter, the parameter definition and the like need to be transmitted. The service registry center stores these information after receiving the information. The static registration can be registered by importing in the form of IDL.

[0194] The purpose of service publishing is to tell other applications that the published service is in available state, and to tell the address of the service to the other party. The service implementation application calls the service publishing interface provided by the service registry center after the service is available, and the service registry center marks the corresponding service version state as active after receiving it. The service registry center delivers the service publishing information to the protocol binding module, which calls the create publisher interface provided by the communication protocol module after receiving it, to create the publisher of the service publishing, the subscriber of the service lookup, the publisher of the Event interface in the service, the publisher of the Method request in the service, and the subscriber of the Method response in the service. After the creation is completed, the communication protocol module encapsulates the service publishing information into a service publishing Topic message and sends it to the multicast address, and all potential service consumers listen to the multicast address.

[0195] The node listening to the multicast address reports the service publishing information to the protocol binding module in its own node after receiving the service publishing Topic message, and the protocol binding module uploads it to the service registry center. The service registry center marks the service state as active, and then reports the service publishing information to the consumer application. The consumer application considers that the service can be used after receiving the service publishing information.

[0196] Service lookup refers to that when a consumer application needs to use a certain service but does not receive the service publishing of the service, it sends a service lookup request to the service registry center, which looks up the state of the service and feeds back to the consumer application if it is in active state. If the lookup result of the service registry center is not active, it sends a service lookup request to the protocol binding module, which calls the create publisher / subscriber interface provided by the communication protocol module after receiving it, to create the publisher of the service lookup, the subscriber of the service publishing, the subscriber of the Event interface in the service, the publisher of the Method request in the service, and the subscriber of the Method response in the service. After the creation is completed, the communication protocol module encapsulates the service lookup information into a service lookup Topic message and sends it to the multicast address.

[0197] The service end communication protocol module reports the service lookup information to the protocol binding module in its own node after receiving the service lookup Topic message, and the protocol binding module uploads it to the service registry center, which continues to report it to the service implementation application. The service implementation application sends the service publishing information if the service is available at this time, and feeds back that the service is not available if the service is not available at this time, and then passes it to the consumer end layer by layer.

[0198] It should be noted that the above method of creating DDS publisher / subscriber is not unique, most of the time DDS publisher / subscriber has been created according to the XML file required by DDS, and the service interaction can be directly used. The above method only adds a dynamic creation method.

[0199] Method and Event calls are through the service interface module. In order to make the interface definition independent of the specific deployment environment and programming language, we generally choose to define the interface in the form of IDL. After definition, the interface program under the response environment will be generated in the service interface module, which can be directly used when calling the service.

[0200] The second stage is the Method call. The Method call is initiated by the consumer application. When calling, the Method request is passed to the service interface module, which is passed to the protocol binding module after receiving it. The protocol binding module is passed to the communication protocol module, which sends it to the service provider in the form of Ethernet message or shared memory. It should be noted here that the address of the service provider is sent by the service publishing message to the service consumer.

[0201] After receiving the Method request message, the service provider will pass it layer by layer in the order of protocol binding module, service interface module and service implementation application. After receiving the Method request, the service implementation application will execute the request and feedback the Method response, and then pass it to the consumer end layer by layer.

[0202] The third stage is Event subscription. When the service consumer application needs to use a certain Event, it will send an Event subscription request to its own service interface module. The Event subscription request includes service name, service ID, service version, Event name (multiple can be subscribed together). The service interface module sends it to the protocol binding module, which adds the network address of the received Event and then gives it to the communication protocol module, such as sending it to the service provider through DDS. After receiving the Event subscription request, the service provider will pass it layer by layer in the order of protocol binding module, service interface module and service implementation application. After receiving the Event subscription request, the service implementation application will send the Event according to the sending mechanism defined by the Event, and then send it to the consumer end layer by layer.

[0203] Event subscription is valid within this power-on cycle, so the consumer does not need to repeatedly send subscription messages. When the consumer no longer needs the Event, it can stop subscribing by sending a stop subscription request.

[0204] The communication method based on the SOA architecture receives a first request message, and parses the first request message into a first service request through a first communication protocol, wherein the first service request is an SOA service interface request initiated by a service consumer, and forms starting data for data transmission and processing in the SOA architecture; the first service request is converted into a second service request through protocol mapping, the second service request is unified interface data in the SOA architecture, the compatibility of inter-vehicle domain communication is improved, and the coupling degree with a lower communication protocol layer is reduced; the second service request is used to generate a first service interface, and the first service request is executed by using the first service interface to generate first response data, and the response of a service provider to the service request is realized; the first response data is converted into a first response message through protocol mapping, the first response message supports the first communication protocol, and a unified interface for adapting to a lower communication protocol is provided for the service provider to feed back a response message; and the first response message is sent to the service consumer, and the response to the service request of the service consumer is completed. A unified interface is provided for inter-vehicle domain communication, the communication performance is improved, the coupling degree is reduced, and the development efficiency of vehicle software is improved.

[0205] Corresponding to the method provided in the above several embodiments, the communication device based on the SOA architecture is also provided in the present disclosure. Since the device provided in the embodiments of the present disclosure corresponds to the method provided in the above several embodiments, the implementation of the method is also applicable to the device provided in the present embodiments, and will not be described in detail in the present embodiments.

[0206] Figure 24 A structure schematic diagram of the communication device 2400 based on the SOA architecture is provided in the embodiments of the present disclosure. The SOA middleware applied to the service provider is as shown in the figure, and the communication device based on the SOA architecture comprises: Figure 24 As shown in the figure, the communication device based on the SOA architecture comprises:

[0207] The parsing module 2410 is configured to receive a first request message, and parse the first request message into a first service request through a first communication protocol, wherein the first service request is an SOA service interface request initiated by a service consumer;

[0208] The mapping module 2420 is configured to convert the first service request into a second service request through protocol mapping, and the second service request is a request recognizable by a service provider;

[0209] The execution module 2430 is configured to generate a first service interface by using the second service request, and execute the first service request by using the first service interface to generate first response data;

[0210] The conversion module 2440 is configured to convert the first response data into a first response message through protocol mapping, and the first response message supports the first communication protocol;

[0211] The sending module 2450 is configured to send the first response message to the service consumer based on the first communication protocol.

[0212] In some embodiments, the parsing module 2410 is further configured to, before receiving the first request message and parsing the first service request through the first communication protocol, perform the following steps:

[0213] register the first service using a preset service interface;

[0214] perform protocol binding of the first request message and the first service request using a preset interface protocol profile;

[0215] publish the first service to the service consumer. In some embodiments, the parsing module 2410 registers the first service using a preset service interface by using the following method:

[0216] import the preset service interface into a registration center in the form of an interface description language to register the first service, the registration center being configured to store the first service, and the preset service interface including one or more of a service name, a service version, an interface name, an interface-associated Qos, an interface-associated parameter, and a parameter definition.

[0217] In some embodiments, the parsing module 2410 publishes the first service to the service consumer by using the following method:

[0218] in response to a service version flag of the first service being marked as an active state, create service publishing information, wherein the service publishing information includes a publisher, a subscriber, a publisher of an Event interface, a publisher of a Method request, and a subscriber of a Method response of the first service;

[0219] encapsulate the service publishing information into a first publishing message and send the first publishing message to a multicast address;

[0220] in a case where a message feedback sent by the service consumer is received, mark a publishing state of the first service, the message feedback being used to identify whether the service consumer receives the first publishing message, and the publishing state including published and unpublished.

[0221] Figure 25 FIG. 25 is a structural schematic diagram of a communication device 2500 based on an SOA architecture according to an embodiment of the present disclosure. The SOA middleware applied to the service consumer is shown in FIG. 25, and the communication device based on the SOA architecture includes: Figure 25

[0222] The generating module 2510 is configured to generate the first service request.

[0223] The mapping module 2520 is configured to convert the first service request into the first request message through protocol mapping.

[0224] ​The sending module 2530 is configured to send a first request message to the service provider based on a first communication protocol;

[0225] The parsing module 2540 is configured to receive a first response message and parse the first response message into second response data based on the first communication protocol, the first response message being generated by the service provider based on the first request message;

[0226] The second response data is converted into first response data through protocol mapping for use by the service consumer.

[0227] In some embodiments, the generating module 2510 is further configured to, before generating the first service request:

[0228] Obtain a first service published by the service provider;

[0229] Check a publishing state of the first service;

[0230] If the publishing state of the first service is not published, determine a service version mark of the first service;

[0231] Check the service version mark of the first service;

[0232] If the service version mark of the first service is in an inactive state, create service lookup information and encapsulate the service lookup information into a first lookup message and send the first lookup message to a multicast address, wherein the service lookup information includes a publisher of the first service, a subscriber, a publisher of an Event interface, a publisher of a Method request, and a subscriber of a Method response;

[0233] Determine a lookup result of the first lookup message, the lookup result being obtained by the service provider using the first lookup message.

[0234] In summary, by applying the SOA architecture-based communication device for the service provider, a first request message is received and parsed into a first service request based on a first communication protocol, the first service request being an SOA service interface request initiated by a service consumer; the first service request is converted into a second service request through protocol mapping, the second service request being a request recognizable by the service provider; a first service interface is generated using the second service request, and the first service request is executed using the first service interface to generate first response data; the first response data is converted into a first response message through protocol mapping, the first response message supporting the first communication protocol; and the first response message is sent to the service consumer based on the first communication protocol. The device solves the problems of poor compatibility, high coupling, and low development efficiency in existing vehicle inter-domain communication, provides a unified interface for vehicle inter-domain communication, improves communication performance, reduces coupling, and improves the development efficiency of vehicle software.

[0235] The method comprises the following steps: generating a first service request by applying a communication device based on a SOA architecture to a service consumer; converting the first service request into a first request message through protocol mapping; sending the first request message to a service provider based on a first communication protocol; receiving a first response message, and parsing the first response message into second response data through the first communication protocol, wherein the first response message is generated by the service provider based on the first request message. The device solves the problems of poor compatibility, high coupling degree and low development efficiency of the existing vehicle inter-domain communication, provides a unified interface for vehicle inter-domain communication, improves the communication performance, reduces the coupling degree, and improves the development efficiency of vehicle software.

[0236] In the embodiments of the present disclosure, the method and device provided by the embodiments of the present disclosure are introduced. In order to realize the functions of the method provided by the embodiments of the present disclosure, the electronic device can include a hardware structure, a software module, and the functions can be realized in the form of hardware structure, software module, or hardware structure plus software module. Some of the above functions can be executed in the form of hardware structure, software module, or hardware structure plus software module.

[0237] Figure 26 FIG. 26 is a block diagram of an electronic device 2600 for implementing the above-mentioned SOA architecture-based communication method according to an exemplary embodiment.

[0238] For example, the electronic device 2600 can be a mobile phone, a computer, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, and the like.

[0239] Referring to Figure 26 The electronic device 2600 can include one or more of the following components: a processing component 2602, a memory 2604, a power supply component 2606, a multimedia component 2608, an audio component 2610, an input / output (I / O) interface 2612, a sensor component 2614, and a communication component 2616.

[0240] The processing component 2602 usually controls the overall operation of the electronic device 2600, such as operations associated with display, telephone calling, data communication, camera operation and recording operation. The processing component 2602 can include one or more processors 2620 to execute instructions to complete all or part of the steps of the above-mentioned method. In addition, the processing component 2602 can include one or more modules to facilitate interaction between the processing component 2602 and other components. For example, the processing component 2602 can include a multimedia module to facilitate interaction between the multimedia component 2608 and the processing component 2602.

[0241] The memory 2604 is configured to store various types of data to support the operation of the electronic device 2600. Examples of such data include instructions for any application or method operating on the electronic device 2600, contact data, phonebook data, messages, pictures, videos, and the like. The memory 2604 can be implemented by any type of volatile or nonvolatile memory, or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disc, or optical disc.

[0242] The power component 2606 provides power to the various components of the electronic device 2600. The power component 2606 can include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power for the electronic device 2600.

[0243] The multimedia component 2608 includes a screen providing an output interface between the electronic device 2600 and a user. In some embodiments, the screen can include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes the touch panel, the screen can be implemented as a touch screen to receive an input signal from a user. The touch panel includes one or more touch sensors to sense a touch, a slide, and a gesture on the touch panel. The touch sensor can not only sense a boundary of a touching or a sliding action, but also detect duration and pressure related to the touching or sliding action. In some embodiments, the multimedia component 2608 includes a front camera and / or a rear camera. The front camera and / or the rear camera can receive external multimedia data when the electronic device 2600 is in an operation mode, such as a photographing mode or a video mode. Each of the front camera and the rear camera can be a fixed optical lens system or have a focal length and optical zoom capability.

[0244] The audio component 2610 is configured to output and / or input an audio signal. For example, the audio component 2610 includes a microphone (MIC) configured to receive an external audio signal when the electronic device 2600 is in an operation mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signal can be further stored in the memory 2604 or transmitted via the communication component 2616. In some embodiments, the audio component 2610 also includes a speaker for outputting an audio signal.

[0245] The I / O interface 2612 provides an interface between the processing component 2602 and peripheral interface modules, which can be a keypad, a click wheel, buttons, and the like. The buttons can include, but are not limited to, a home button, a volume button, a start button, and a lock button.

[0246] The sensor component 2614 includes one or more sensors for providing status assessments for various aspects of the electronic device 2600. For example, the sensor component 2614 can detect an open / closed position of the electronic device 2600, relative positioning of components, such as a display and a keypad of the electronic device 2600, a change in position of the electronic device 2600 or a component of the electronic device 2600, the presence or absence of user contact with the electronic device 2600, the orientation or acceleration / deceleration / g-force and a temperature change of the electronic device 2600. The sensor component 2614 can include a proximity sensor configured to detect presence of a nearby object without any physical touch. The sensor component 2614 can further include a light sensor (e.g., a CMOS or CCD image sensor) configured to capture images in an imaging application. In some embodiments, the sensor component 2614 can further include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0247] The communication component 2616 is configured to facilitate wired or wireless communication between the electronic device 2600 and other devices. The electronic device 2600 can access a wireless network based on a communication standard, such as WiFi, 2G or 3G, 4G LTE, 5G NR (New Radio), or a combination thereof. In an example embodiment, the communication component 2616 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In an example embodiment, the communication component 2616 further includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on Radio Frequency Identification (RFID) techniques, infrared data association (IrDA) techniques, ultra-wideband (UWB) techniques, Bluetooth (BT) techniques, and other techniques.

[0248] In an example embodiment, the electronic device 2600 can be implemented with one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, micro-controllers, microprocessors, or other electronic elements to perform the above-described methods.

[0249] In an example embodiment, a non-transitory computer-readable storage medium including instructions, such as the memory 2604 including instructions, is also provided, which can be executed by the processor 2620 of the electronic device 2600 to complete the above-described methods. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disc, and an optical data storage device, etc.

[0250] The embodiment of the present disclosure also provides a non-transitory computer readable storage medium storing computer instructions, wherein the computer instructions are used to make a computer execute the SOA architecture based communication method described in the above embodiment of the present disclosure.

[0251] The embodiment of the present disclosure also provides a computer program product, comprising a computer program, wherein the computer program is used to make a processor execute the SOA architecture based communication method described in the above embodiment of the present disclosure.

[0252] The embodiment of the present disclosure also provides a vehicle, comprising the SOA architecture based communication device and / or the SOA architecture based communication system described in the above embodiment of the present disclosure.

[0253] Figure 27 FIG. 27 is a structural schematic diagram of a chip 2700 for implementing the SOA architecture based communication method described above according to an exemplary embodiment.

[0254] With reference to Figure 27 The chip 2700 comprises at least one communication interface 2701 and a processor 2702; the communication interface 2701 is used to receive a signal input into the chip 2700 or output a signal from the chip 2700, and the processor 2702 communicates with the communication interface 2701 and implements the SOA architecture based communication method described in the above embodiment through a logic circuit or an execution code instruction.

[0255] It should be noted that the terms "first", "second", and the like in the description of the specification and claims of the present disclosure and the above-described drawings are used to distinguish similar objects, and do not necessarily indicate a specific order or a chronological sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present disclosure described herein can be implemented in an order other than that illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all the embodiments consistent with the present disclosure. Rather, they are merely examples of devices and methods consistent with some aspects of the present disclosure as detailed in the appended claims.

[0256] In the description of the present specification, the description of the terms "one embodiment", "some embodiments", "exemplary embodiment", "example", "specific example", or "some examples" and the like means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present disclosure. In the present specification, the exemplary description of the above terms does not necessarily mean the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

[0257] Any processes or methods described in the flowcharts or otherwise described herein can be understood as representing code modules, segments, or portions of code which include one or more executable instructions for implementing specific logic functions (or steps) of the processes. The various embodiments of the present disclosure can include additional or fewer steps or processes, and the order of the steps or processes can be altered, as will be appreciated by those skilled in the art, as the described embodiments of the present disclosure can be implemented in a variety of ways.

[0258] The logic and / or steps represented in the flowcharts or otherwise described herein, for example, can be embodied in non-transitory computer-readable media, which can be executed by an instruction execution system, apparatus, or device such as a computer-based system, a system including a processing module, or other systems that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. For purposes of this specification, a "computer-readable medium" can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The computer-readable medium can be a computer- readable storage medium. A "computer-readable storage medium" can include any non-transitory medium that can be considered a computer storage medium, including but not limited to the following: an electronic connection (an electronic circuitry having one or more wires), a portable computer diskette (a magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or a flash memory), an optical fiber, and a portable compact disc read-only memory (CDROM). Additionally, the computer-readable medium can even be paper or another suitable medium upon which the program can be printed, as the program can be electronically captured, for example, by optically scanning the paper or other suitable medium, then electronically converted into a form that can be edited, compiled, or interpreted, or otherwise processed in electronic form into an electronically stored form ready to be further processed by or used in combination with a computer system.

[0259] It should be understood that portions of the present disclosure can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, a number of steps or methods can be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented in hardware, and as in another embodiment, any of the following technologies known in the art or their combinations can be used: discrete logic circuitry having logic gates for implementing logic functions on data signals, application specific integrated circuits having appropriate combinational logic gates, programmable gate arrays (PGA), field programmable gate arrays (FPGA), etc.

[0260] Those skilled in the art of the present technology can understand that all or part of the steps carried out by the above-mentioned embodiment method can be completed by a program instructing the relevant hardware, and the program can be stored in a computer readable storage medium. When the program is executed, it includes one of the steps of the method embodiment or a combination thereof.

[0261] In addition, each functional unit in various embodiments of the present disclosure can be integrated into one processing module, or each unit can exist physically independently, or two or more units can be integrated into one module. The integrated module can be realized in the form of hardware or in the form of a software functional module. If the integrated module is realized in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer readable storage medium. The storage medium mentioned above can be a read-only memory, a magnetic disk or an optical disk, etc.

[0262] Although the embodiments of the present disclosure have been shown and described above, it should be understood that the above-mentioned embodiments are exemplary and should not be construed as limiting the present disclosure, and those skilled in the art can make changes, modifications, replacements and variations to the above-mentioned embodiments within the scope of the present disclosure.

Claims

1. A communication method based on SOA architecture, characterized in that, The method comprises: receiving a first request message and parsing it into a first service request through a first communication protocol, wherein the first service request is an SOA service interface request initiated by a service consumer; protocol mapping the first service request into a second service request recognizable by a service provider; generating a first service interface using the second service request and executing the first service request using the first service interface to generate first response data; protocol mapping the first response data into a first response message supporting the first communication protocol; sending the first response message to the service consumer based on the first communication protocol.

2. The method of claim 1, wherein, Before the receiving a first request message and parsing it into a first service request through a first communication protocol, comprising: registering a first service using a preset service interface; protocol binding the first request message and the first service request using a preset interface protocol configuration file; publishing the first service to the service consumer.

3. The method of claim 2, wherein, The registering a first service using a preset service interface comprises: importing the preset service interface into a registration center in the form of an interface description language to register the first service, the registration center being used to save the first service, the preset service interface including one or more of a service name, a service version, an interface name, an interface-associated Qos, an interface-associated parameter and a parameter definition.

4. The method of claim 2, wherein, The publishing the first service to the service consumer comprises: in response to a service version mark of the first service being in an active state, creating service publishing information, wherein the service publishing information includes a publisher, a subscriber, an Event interface publisher, a Method request publisher and a Method response subscriber of the first service; encapsulating the service publishing information into a first publishing message and sending it to a multicast address; in the case of receiving a message feedback sent by the service consumer, marking a publishing state of the first service, the message feedback being used to identify whether the service consumer has received the first publishing message, the publishing state including published and unpublished.

5. A communication method based on SOA architecture, characterized in that, The method comprises: generating a first service request; protocol mapping the first service request into a first request message; sending the first request message to a service provider based on a first communication protocol; receiving a first response message and parsing it into second response data through the first communication protocol, the first response message being generated by the service provider based on the first request message; protocol mapping the second response data into first response data for a service consumer.

6. The method of claim 5, wherein, Before the generating a first service request, comprising: obtaining a first service published by the service provider; checking a publishing state of the first service; if the publishing state of the first service is unpublished, determining a service version mark of the first service; checking the service version mark of the first service; If the service version of the first service is marked as an inactivated state, service lookup information is created and encapsulated into a first lookup message and sent to a multicast address, wherein the service lookup information includes a publisher of the first service, a subscriber, a publisher of an Event interface, a publisher of a Method request, and a subscriber of a Method response; A lookup result of the first lookup message is determined, and the lookup result is obtained by the service provider using the first lookup message.

7. A communication apparatus based on SOA architecture, characterized in that, The apparatus comprises: The parsing module is configured to receive a first request message and parse the first request message into a first service request through a first communication protocol, wherein the first service request is an SOA service interface request initiated by a service consumer; The mapping module is configured to convert the first service request into a second service request through protocol mapping, wherein the second service request is a request recognizable by a service provider; The execution module is configured to generate a first service interface using the second service request and execute the first service request using the first service interface to generate first response data; The conversion module is configured to convert the first response data into a first response message through the protocol mapping, wherein the first response message supports the first communication protocol; The sending module is configured to send the first response message to the service consumer based on the first communication protocol.

8. A communication apparatus based on SOA architecture, characterized in that, The apparatus comprises: The generation module is configured to generate a first service request; The mapping module is configured to convert the first service request into a first request message through protocol mapping; The sending module is configured to send the first request message to a service provider based on a first communication protocol; The parsing module is configured to receive a first response message and parse the first response message into second response data through the first communication protocol, wherein the first response message is generated by the service provider based on the first request message; The conversion module is configured to convert the second response data into first response data through the protocol mapping for use by a service consumer.

9. A communication system based on SOA architecture, characterized by, A service provider and a service consumer are included, the service provider includes a first SOA middleware, and the service consumer includes a second SOA middleware; the first SOA middleware includes a first service interface, a first protocol mapping module, and a first communication middleware, the second SOA middleware includes the second protocol mapping module and the second communication middleware, and the service provider and the service consumer are connected through a network; The first SOA middleware receives a first request message of a service consumption application through the first communication middleware, parses the first request message into a first service request according to a communication protocol of the first communication middleware, and converts the first service request into a second service request using the first protocol mapping module; The first service interface generates a first service interface using the second service request; a service provision application executes the first service request using the first service interface to generate first response data; The first protocol mapping module converts the first response data into a first response message supported by the communication protocol of the first communication middleware; The first communication middleware sends the first response message to the second SOA middleware based on the communication protocol; The second SOA middleware receives the first response message through the second communication middleware; The first response message is parsed into second response data through the communication protocol of the second communication middleware; The second protocol mapping module of the second SOA middleware converts the second response data into first response data, which can be used by the service consumption application.

10. An electronic device, comprising: Comprising: at least one processor; and a memory in communication with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1-4, claims 5-6.

11. A non-transitory computer-readable storage medium having stored thereon computer instructions, wherein, The computer instructions are used to enable the computer to perform the method according to any one of claims 1-4, claims 5-6.

12. A chip, characterized by Comprising at least one processor and a communication interface; the communication interface is used to receive the signal input into the chip or the signal output from the chip, the processor is in communication with the communication interface and realizes the method according to any one of claims 1-4, claims 5-6 through logic circuit or execution of code instructions.

13. A vehicle characterized by comprising: Comprising the SOA architecture-based communication device according to claim 7 or claim 8, or comprising the SOA architecture-based communication system according to claim 9.

Images