A method, apparatus and device for implementing an SOA application

Abstract

The present invention discloses a method, apparatus and device for implementing an SOA application, relating to the technical field of communication applications. The method includes implementing cross-Domain support based on the initialization of the underlying RPMsg and the establishment of a communication link; implementing cross-chip communication support based on the initialization of the underlying PCIe device and the establishment of a cross-chip communication link; extending the implementation of communication protocol support for DDS and SOME / IP according to libbinder; constructing an SOA application based on Android Binder, and an Android Service APP calls the AIDL JAVA SDK to generate a Binder Server-side application. This application can effectively reduce the complexity of the operating system and broaden the usage scenarios of SOA.

Description

Technical Field

[0001] This application relates to the technical field of communication applications, and particularly to a method, device, and equipment for implementing an SOA application. Background Art

[0002] In modern intelligent cockpit systems, the Android system is widely used as the main operating system platform. With the continuous enrichment of cockpit functions and the increasing complexity of the operating system architecture, cross-domain (Cross-Domain) and cross-chip (Cross-Chip) service call requirements often exist in the operating system. This distributed service architecture requires the operating system to have efficient and reliable cross-process communication capabilities.

[0003] Currently, the cockpit mainly uses the Android OS (Operating System), and the Android SOA (Service-Oriented Architecture) framework is mainly based on Binder (a cross-process communication mechanism in the Android platform) IPC (Inter-Process Communication). In the field of intelligent driving, Linux (an operating system) / QNX (a real-time operating system) and other operating systems are usually used. Different from the cockpit, such operating systems usually do not use Binder IPC, but use IPC methods such as SOME / IP (service-oriented extensible middleware based on IP), DDS (a data-centric distributed communication protocol), RPMsg (an inter-core communication protocol for multi-core systems), and UDS (Unified Diagnostic Services). In the trend of integrating cockpit and driving services, using a unified SOA framework is of great benefit to improving the reusability and ecological compatibility of in-vehicle software. However, the current SOA software frameworks in the cockpit and intelligent driving domains are not consistent.

[0004] At the same time, cockpit services and intelligent driving services usually belong to two different SoCs (System on Chip) or different Domains of one SoC. The non-uniformity of the underlying communication methods and the non-uniformity of the upper-layer middleware between the two have caused problems such as inconsistent in-vehicle software development paradigms and poor in-vehicle software compatibility. Summary of the Invention

[0005] This application provides a method, device, and equipment for implementing an SOA application, which can effectively reduce the complexity of the operating system and expand the usage scenarios of SOA.

[0006] In a first aspect, an embodiment of this application provides a method for implementing an SOA application, and the method for implementing an SOA application includes:

[0007] Based on the initialization of the underlying RPMsg and the establishment of the communication link, cross-Domain support is achieved;

[0008] Based on the initialization of the underlying PCIe device and the establishment of the cross-chip communication link, cross-chip communication support is achieved;

[0009] According to libbinder, the communication protocol support for DDS and SOME / IP is extended and implemented;

[0010] Build an SOA application based on Android Binder. The Android Service APP calls the AIDL JAVA SDK to generate the Binder Server-side application.

[0011] Combined with the first aspect, in one implementation, the cross-Domain support is achieved based on the initialization of the underlying RPMsg and the establishment of the communication link. Among them, for the initialization of the underlying RPMsg, it specifically includes:

[0012] Configure the RPMsg virtual device, establish a dedicated communication channel between different software domains, allocate a shared memory area for data transmission, initialize the interrupt handling mechanism, establish an endpoint mapping table, and complete the initialization of RPMsg;

[0013] Perform the initialization of the DDS transport layer, register the DDS transport plug-in to the RPMsg layer, create and manage the transport resource pool, initialize the message queue, and start the discovery service thread;

[0014] Create domain participants, configure a unique identifier for each software domain, set QoS parameters according to actual requirements, complete the initialization of the publish / subscribe service, and register the corresponding data types.

[0015] Combined with the first aspect, in one implementation, the cross-Domain support is achieved based on the initialization of the underlying RPMsg and the establishment of the communication link. Among them, for the establishment of the communication link, it specifically includes:

[0016] Perform the configuration of the publisher, create a Topic, set the QoS policy of the publisher, allocate a buffer for the data to be sent, and register the corresponding callback function;

[0017] Perform the configuration of the subscriber, match the created Topic, set the QoS policy of the subscriber, allocate a buffer for receiving data, and register a data listener;

[0018] Enter the discovery and matching process. The publisher broadcasts a discovery message, the subscriber receives and responds to the discovery request. The publisher and the subscriber exchange QoS parameters for negotiation. After successful negotiation, the communication link is established.

[0019] In combination with the first aspect, in one embodiment, the support for cross-chip communication is achieved based on the initialization of the underlying PCIe device and the establishment of a cross-chip communication link. Among them, for the initialization of the underlying PCIe device, it specifically includes:

[0020] Scan the PCIe bus, discover and enumerate all PCIe devices, and allocate memory space and interrupt resources for each PCIe device;

[0021] Configure the BAR area of the PCIe device, establish an address mapping relationship, and for DMA transmission, initialize the DMA controller, create a descriptor list, and allocate DMA buffers;

[0022] Configure the MSI / MSI-X interrupt vector, register an interrupt handling function, and complete the initialization of the PCIe device;

[0023] Initialize the DDS transport layer, register the DDS transport plugin to the PCIe transport layer, create and manage a transport resource pool, initialize a message queue, and start a discovery service thread;

[0024] Create a domain participant, configure a unique identifier for each chip, set the QoS parameters required for cross-chip communication, and complete the initialization of the publish / subscribe service.

[0025] In combination with the first aspect, in one embodiment, the support for cross-chip communication is achieved based on the initialization of the underlying PCIe device and the establishment of a cross-chip communication link. Among them, for the establishment of the cross-chip communication link, it specifically includes:

[0026] Configure the publisher, create a Topic for cross-chip communication, allocate a DMA send buffer based on the publisher QoS policy for PCIe transmission, and register a DMA completion callback function;

[0027] Configure the subscriber, match the created Topic, set the QoS policy of the subscriber, allocate a DMA receive buffer, and register a data arrival callback function;

[0028] Enter the discovery and matching phase. The publisher broadcasts discovery messages through the PCIe bus. Subscribers on different chips receive and respond to the discovery requests. Both the publisher and the subscriber negotiate QoS parameters through PCIe transmission to determine the establishment of a cross-chip communication link.

[0029] In combination with the first aspect, in one embodiment,

[0030] According to libbinder, extend the implementation to support the communication protocols of DDS and SOME / IP, specifically including the initialization of the SOME / IP protocol stack and the establishment of services;

[0031] For the initialization of the SOME / IP protocol stack, it specifically includes:

[0032] Load the SOME / IP configuration file and parse the service interface description, including the definitions of methods, events, and fields;

[0033] Initialize the SOME / IP runtime environment, including creating a service lookup table, creating a message routing table, initializing a serializer, and configuring transmission parameters. Among them, for cross-domain / cross-chip scenarios, it is necessary to identify the network topologies of different domains / chips, establish network connections, and configure multicast addresses and port mappings;

[0034] Start the SD module of SOME / IP and start service registration.

[0035] Combined with the first aspect, in one implementation, for the establishment of services, it specifically includes:

[0036] The service provider registers the service with the SD module and publishes service provider information, including service ID, instance ID, major version number, and network endpoints;

[0037] Start the event manager of the service provider to prepare for handling subscription requests. The service consumer discovers available services through the SD module, matches the required service interface version, parses the service endpoints information, and when a matching service is found, sends a service request to the service provider, and a communication session is established between the service provider and the service consumer;

[0038] Handle the subscription management of services, including event group registration and event subscription request handling.

[0039] Combined with the first aspect, in one implementation, for building an SOA application based on Android Binder, the Android Service APP calls the AIDL JAVA SDK to generate the Binder Server-side application, specifically including:

[0040] Define service interfaces based on the AIDL standard;

[0041] Generate the code for the Server and Client sides based on Android AIDL, and the code is the interface code for implementing SOA cross-domain / cross-chip communication;

[0042] The Android Server registers the SOA service into the Android system and selects the communication protocol through the libbinder transact interface;

[0043] On the cross - domain and cross - chip Client side, the generated code is selected according to requirements to generate the Binder Client - side application;

[0044] The Binder Client accesses the Android Server - side service for Inner Domain / Cross Domain / Cross - Chip.

[0045] In a second aspect, an embodiment of the present application provides a SOA application implementation device, and the SOA application implementation device includes:

[0046] A establishment module, which is used to realize cross - Domain support based on the initialization of the underlying RPMsg and the establishment of the communication link;

[0047] A creation module, which is used to realize cross - chip communication support based on the initialization of the underlying PCIe device and the establishment of the cross - chip communication link;

[0048] An extension module, which is used to extend the communication protocol support for DDS and SOME / IP according to libbinder;

[0049] An execution module, which is used to build a SOA application based on Android Binder. The Android Service APP calls the AIDL JAVA SDK to generate the Binder Server - side application.

[0050] In a third aspect, an embodiment of the present application provides a SOA application implementation device, and the SOA application implementation device includes a processor, a memory, and a SOA application implementation program stored on the memory and executable by the processor. When the SOA application implementation program is executed by the processor, the steps of the above - mentioned SOA application implementation method are realized.

[0051] The beneficial effects brought by the technical solutions provided by the embodiments of the present application include:

[0052] While realizing the SOA application inside the Android system based on the existing Android Binder, the cross - domain and cross - chip SOA solutions based on DDS and SOME / IP are realized, effectively reducing the complexity of the operating system, expanding the usage scenarios of SOA, and realizing the unified SOA framework application for the cockpit and intelligent driving. Description of the Drawings

[0053] Figure 1 It is a schematic flowchart of the implementation method of the SOA application in this application;

[0054] Figure 2 It is a schematic architecture diagram of the SOA application in this application;

[0055] Figure 3 It is a schematic diagram of the functional modules of the SOA application implementation device in this application;

[0056] Figure 4 It is a schematic hardware structure diagram of the SOA application implementation device in this application. Specific embodiments

[0057] In order to enable those skilled in the art to better understand the solution of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of this application. Obviously, the described embodiments are only a part of the embodiments of this application, rather than all the embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of this application.

[0058] To make the purpose, technical solution and advantages of this application clearer, the embodiments of this application will be further described in detail below with reference to the drawings.

[0059] In a first aspect, the embodiments of this application provide a method for implementing an SOA application, which can meet the requirements of using cockpit services and intelligent driving services across domains and across chips.

[0060] In one embodiment, referring to Figure 1 , Figure 1 It is a schematic flowchart of the implementation method of the SOA application in this application. As Figure 1 shown, the method for implementing the SOA application includes:

[0061] S1: Based on the initialization of the underlying RPMsg and the establishment of the communication link, cross-Domain support is achieved;

[0062] S2: Based on the initialization of the underlying PCIe device and the establishment of the cross-chip communication link, cross-chip communication support is achieved;

[0063] S3: According to libbinder, the communication protocol support for DDS and SOME / IP is extended and implemented;

[0064] S4: Build an SOA application based on Android Binder. The Android Service APP calls the AIDL JAVASDK to generate the Binder Server-side application. libbinder is the core implementation library of the Binder inter-process communication mechanism in the Android system. Binder is an inter-process communication mechanism for the Android platform. AIDL is the Android Interface Definition Language. JAVA is an object-oriented programming language. SDK is the Software Development Kit. Service represents a service, and APP represents an application program.

[0065] While implementing the internal SOA application of the Android system based on the existing Android binder, this application is compatible with cross-domain and cross-chip SOA frameworks based on communication methods such as DDS and SOME / IP, effectively reducing the complexity of the operating system and expanding the usage scenarios of SOA.

[0066] Further, in one embodiment, cross-Domain support is implemented based on the initialization of the underlying RPMsg and the establishment of a communication link. Among them, for the initialization of the underlying RPMsg, it specifically includes:

[0067] S101: Configure the RPMsg virtual device, establish a dedicated communication channel between different software domains, allocate a shared memory area for data transmission, initialize the interrupt handling mechanism, establish an endpoint mapping table, and complete the initialization of RPMsg;

[0068] S102: Initialize the DDS transport layer, register the DDS transport plug-in to the RPMsg layer, create and manage a transport resource pool, initialize the message queue, and start the discovery service thread;

[0069] S103: Create a domain participant, configure a unique identifier for each software domain, and set QoS (Quality of Service) parameters according to actual needs, complete the initialization of the publish / subscribe service, and register the corresponding data types.

[0070] Specifically, when the operating system starts, the initialization of the underlying RPMsg needs to be completed. In this step, the RPMsg virtual device is first configured to establish a dedicated communication channel between different software domains, allocate a shared memory area for data transmission, initialize the interrupt handling mechanism, establish an endpoint mapping table, and complete the initialization of RPMsg. After the initialization of RPMsg is completed, the initialization of the DDS transport layer begins. The DDS transport plug-in is registered with the RPMsg layer, a transport resource pool is created and managed, the message queue is initialized, the discovery service thread is started, and then domain participants are created. A unique identifier is configured for each software domain, and QoS parameters are set according to actual requirements to complete the initialization of the publish / subscribe service and register the corresponding data types.

[0071] Further, in one embodiment, cross-Domain support is implemented based on the initialization of the underlying RPMsg and the establishment of a communication link. Specifically, for the establishment of the communication link, it includes:

[0072] S111: Configure the publisher, create a Topic (a communication method), set the QoS policy of the publisher, allocate a buffer for the data to be sent, and register the corresponding callback function;

[0073] S112: Configure the subscriber, match the created Topic, set the QoS policy of the subscriber, allocate a buffer for receiving data, and register a data listener;

[0074] S113: Enter the discovery and matching phase. The publisher broadcasts a discovery message, the subscriber receives and responds to the discovery request, and the publisher and the subscriber exchange QoS parameters for negotiation. After successful negotiation, the communication link is established.

[0075] Specifically, after the initialization of the underlying RPMsg is completed, the communication link establishment phase is entered. In this phase, first, the publisher needs to be configured. Specifically, a Topic is created, the QoS policy of the publisher is set, a buffer is allocated for the data to be sent, and the corresponding callback function is registered. Then, the subscriber is configured to match the created Topic, set the QoS policy of the subscriber, allocate a buffer for receiving data, and register a data listener, etc. Subsequently, the discovery and matching phase is entered. The publisher broadcasts a discovery message, the subscriber receives and responds to the discovery request, and the publisher and the subscriber exchange QoS parameters for negotiation. After successful negotiation, a stable communication link can be established.

[0076] It should be noted that after the communication link is established, the actual data transmission phase begins. When sending data, first the application layer writes the data to be transmitted, and the DDS transport layer serializes the data. If the data volume is large and needs to be fragmented for transmission, message fragmentation will be performed, and then the data will be sent through the RPMsg layer and wait for the acknowledgment response from the receiving end. At the receiving end, after the RPMsg layer receives the data, if it is a fragmented message, it needs to be reassembled, and then the data is deserialized, a confirmation response is sent back to the sending end, and finally the complete data is delivered to the application layer. To ensure the reliability of communication, the SOA application assigns sequence numbers to each message, maintains the send and receive windows, implements the timeout retransmission mechanism, performs flow control, and monitors the link status through heartbeat detection.

[0077] For exception handling, during the entire communication process, the SOA application also needs to handle various exception situations. When it detects that the heartbeat timeout indicates a link interruption, the SOA application will immediately suspend data transmission, temporarily store the newly generated data in the buffer, and at the same time try to re - establish the connection. After the connection is restored, the data transmission will continue. In addition, it is necessary to monitor the memory usage in real - time, release the resources that are no longer used in a timely manner, dynamically adjust the size of the memory pool to prevent memory leaks. When an error occurs, the SOA application will record detailed error logs, save the fault scene information, execute the predefined recovery strategy, and notify the application layer in a timely manner.

[0078] For resource release, finally, when the communication needs to be closed, the SOA application will release resources in an orderly manner. First, it is necessary to ensure that all unsent data has been transmitted and confirmed. Then, the data channel is closed, and then various resources are cleaned up, including deleting Topics, destroying domain participants, releasing the allocated memory, closing interrupts, etc. Finally, the necessary configuration information is saved, all connections are disconnected, and the device resources are released to complete the exit of the entire process.

[0079] Furthermore, in one embodiment, based on the initialization of the underlying PCIe device and the establishment of the cross - chip communication link, the support for cross - chip communication is realized. Among them, for the initialization of the underlying PCIe device, it specifically includes:

[0080] S201: Scan the PCIe (Peripheral Component Interconnect Express, a high - speed serial computer expansion bus standard) bus, discover and enumerate all PCIe devices, and allocate memory space and interrupt resources for each PCIe device;

[0081] S202: Configure the BAR area of the PCIe device, establish the address mapping relationship, and for DMA transfer, initialize the DMA controller, create a descriptor linked list, and allocate DMA buffers; BAR stands for Base Address Register, that is, the base address register; DMA stands for Direct Memory Access, that is, direct memory access;

[0082] S203: Configure the MSI / MSI-X interrupt vectors, register the interrupt handling function, and complete the initialization of the PCIe device; MSI stands for Message Signaled Interrupts, that is, message signaled interrupts; MSI-X stands for Extended Message Signaled Interrupts, that is, extended message signaled interrupts;

[0083] S204: Initialize the DDS transport layer, register the DDS transport plugin to the PCIe transport layer, create and manage the transport resource pool, initialize the message queue, and start the discovery service thread;

[0084] S205: Create a domain participant, configure a unique identifier for each chip, set the QoS parameters required for cross-chip communication, and complete the initialization of the publish / subscribe service.

[0085] Specifically, when the operating system starts, it needs to complete the initialization of the underlying PCIe device. The operating system will scan the PCIe bus, discover and enumerate all PCIe devices, then allocate memory space and interrupt resources for each PCIe device, then configure the BAR area of the PCIe device, establish the address mapping relationship, and for DMA transfer, it is necessary to initialize the DMA controller, create a descriptor linked list, and allocate DMA buffers; at the same time, it is also necessary to configure the MSI / MSI-X interrupt vectors, register the interrupt handling function, and complete the initialization of the PCIe device. After the PCIe initialization is completed, start the initialization of the DDS transport layer, register the DDS transport plugin to the PCIe transport layer, create and manage the transport resource pool, initialize the message queue, start the discovery service thread, and then create a domain participant, configure a unique identifier for each chip, set the QoS parameters required for cross-chip communication, and complete the initialization of the publish / subscribe service.

[0086] Further, in an embodiment, based on the initialization of the underlying PCIe device and the establishment of the cross-chip communication link, the support for cross-chip communication is realized. Among them, for the establishment of the cross-chip communication link, it specifically includes:

[0087] S211: Configure the publisher, create a Topic for cross-chip communication, allocate a DMA send buffer based on the publisher QoS policy for PCIe transmission, and register a DMA completion callback function;

[0088] S212: Configure the subscriber, match the created Topic, set the subscriber QoS policy, allocate a DMA receive buffer, and register a data arrival callback function;

[0089] S213: Enter the discovery and matching phase. The publisher broadcasts a discovery message via the PCIe bus. Subscribers on different chips receive and respond to the discovery request. The publisher and subscriber negotiate QoS parameters via PCIe transmission to determine the establishment of a cross-chip communication link.

[0090] Specifically, in the cross-chip communication link establishment phase, first configure the publisher, including creating a Topic for cross-chip communication, allocating a DMA send buffer based on the publisher QoS policy for PCIe transmission, and registering a DMA completion callback function. Then configure the subscriber, match the created Topic, set the subscriber QoS policy, allocate a DMA receive buffer, and register a data arrival callback function. Subsequently, enter the discovery and matching phase. The publisher broadcasts a discovery message via the PCIe bus. Subscribers on different chips receive and respond to the discovery request. The publisher and subscriber negotiate QoS parameters via PCIe transmission to determine the establishment of a stable cross-chip communication link.

[0091] It should be added that after the cross-chip communication link is established, actual data transmission begins. When sending data, after the application layer writes the data, the DDS transport layer first performs serialization processing. Since PCIe has high bandwidth characteristics, DMA mode will be preferentially used for large-block data transmission. At this time, a DMA descriptor chain will be constructed, the DMA transmission engine will be started, and the data will be directly transmitted to the memory of the target chip via the PCIe bus. At the same time, the target chip will be notified of the data arrival via MSI-X interrupt; at the receiving end, after the PCIe device receives the interrupt, it processes the DMA completion event, deserializes the received data, sends an acknowledgment message, and finally delivers the data to the application layer. To ensure transmission reliability, the SOA application will maintain send and receive windows, implement a flow control mechanism based on PCIe, and monitor the cross-chip link status via heartbeat detection.

[0092] For exception handling, during cross-chip communication, the SOA application needs to handle various exception situations. When a PCIe link interruption is detected, the SOA application immediately pauses data transmission, caches new data locally, and attempts to restore the connection through mechanisms such as PCIe link training. For errors that may occur during DMA transmission, the SOA application resets the DMA engine and reconstructs descriptors for retransmission. In addition, it is necessary to monitor the PCIe bandwidth usage in real time, reasonably allocate DMA channel resources, and prevent transmission congestion. When a serious error occurs, the SOA application records detailed error information, saves the current PCIe device status, and attempts to reset the device for recovery.

[0093] For resource release, first ensure that all DMA transmissions are completed, stop the PCIe device, then clean up DMA descriptors and buffers, release interrupt resources, then delete Topics, destroy participants, release memory, etc., and finally save configuration information, reset the PCIe device, and complete the exit process.

[0094] In this application, based on libbinder, the communication protocol support for DDS and SOME / IP is extended, specifically including the initialization of the SOME / IP protocol stack and the establishment of services.

[0095] Furthermore, for the initialization of the SOME / IP protocol stack, it specifically includes:

[0096] S301: Load the SOME / IP configuration file and parse the service interface description, including the definitions of methods, events, and fields;

[0097] S302: Initialize the SOME / IP runtime environment, including creating a service lookup table, creating a message routing table, initializing a serializer, and configuring transmission parameters. Among them, for cross-domain / cross-chip scenarios, it is necessary to identify the network topologies of different domains / chips, establish network connections, and configure multicast addresses and port mappings;

[0098] S303: Start the SD module of SOME / IP and start service registration. SD, the full name is Service Discover, that is, service discovery.

[0099] Specifically, when the operating system starts, it is necessary to complete the initialization of the SOME / IP protocol stack. First, load the SOME / IP configuration file, parse the service interface description, including the definitions of methods, events, fields, etc., and then initialize the SOME / IP runtime environment, including creating a service lookup table, creating a message routing table, initializing the serializer, configuring transmission parameters, etc. Among them, for cross-domain / cross-chip scenarios, it is necessary to identify the network topologies of different domains / chips, establish network connections, and configure multicast addresses and port mappings. After initialization, start the SD module of SOME / IP and start service registration.

[0100] Furthermore, for the establishment of services, it specifically includes:

[0101] S311: The service provider registers the service with the SD module and publishes service provider information, including the service ID, instance ID, major version number, network endpoints;

[0102] S312: Start the event manager of the service provider to prepare for handling subscription requests. The service consumer discovers available services through the SD module, matches the required service interface version, parses the service endpoints information. When a matching service is found, send a service request to the service provider, and a communication session is established between the service provider and the service consumer;

[0103] S313: Handle service subscription management, including event group registration and event subscription request handling.

[0104] Specifically, when entering the service establishment stage, the service provider first registers the service with the SD module and publishes service provider information, including the service ID, instance ID, major version number, network endpoints, etc., and then starts the event manager of the service provider to prepare for handling subscription requests. The service consumer discovers available services through the SD module, matches the required service interface version, parses the service endpoints information. When a matching service is found, send a service request to the service provider, and a communication session is established between the service provider and the service consumer. At the same time, it is also necessary to handle service subscription management, including event group registration, event subscription request handling, etc.

[0105] It should be noted that after the service is established, during the data transmission phase, for method calls, the service consumer constructs a SOME / IP request message, including the message header (service ID, method ID, session ID, etc.) and the serialized payload, and then sends the request through the underlying transport layer (TCP / UDP). The service provider receives the request, parses the message header, deserializes the parameters, executes the method call, serializes the result, and constructs a response message to send back. For event notifications, when an event is triggered, the service provider constructs a SOME / IP notification message and sends it to all subscribers. To ensure communication reliability, the SOA application implements functions such as retransmission mechanism, timeout handling, and session management.

[0106] For exception handling, during the communication process, the SOA application needs to handle various exception situations. When a network failure is detected, the service will be rediscovered through the SD module and an attempt will be made to restore the connection. For failed message sending, the SOA application will resend the message according to the configured retransmission policy. In addition, it is also necessary to handle exception situations such as service instance failure, version incompatibility, and network congestion. The SOA application will monitor the service status and network quality in real time and dynamically adjust the transmission parameters to ensure communication quality. When a serious error occurs, an error log will be recorded, the on-site information will be saved, and the application layer will be notified for processing.

[0107] For resource release, finally, when closing the communication, the resources need to be released orderly. First, all event notifications are stopped, the subscription relationships are cleared, then the service session is closed, the service is unsubscribed from the SD module, then the message buffer is released, the network connection is closed, the routing table is cleared, etc., and finally the necessary statistical information is saved to complete the service exit process.

[0108] Furthermore, in one embodiment, an SOA application based on Android Binder is constructed. The Android ServiceAPP calls the AIDL JAVA SDK to generate a Binder Server-side application, which specifically includes:

[0109] S401: Define a service interface based on the AIDL standard;

[0110] S402: Generate the code for the Server and Client (customer) sides based on Android AIDL. The code is the interface code for implementing SOA cross-domain / cross-chip communication;

[0111] That is, generate JAVA / C++ / C code for the Server and Client sides based on Android AIDL. This code is the interface code used to implement SOA cross-domain / cross-chip communication and has the following functions: 1. Service abstraction (related SOA services use this code interface for service abstraction), specifically including unified interface definition and support for multi-language implementation (both Native interfaces and C / C++ interfaces are supported); 2. Communication abstraction. This code hides the underlying details, such as hiding whether the underlying communication mechanism uses DDS, SOME / IP, or native Binder calls, because DDS / SOME / IP has been integrated into the libbinder layer.

[0112] S403: The Android Server side registers the SOA service into the Android system and selects the communication protocol through the libbindertransact interface;

[0113] S404: On the cross-domain / cross-chip Client side, select the generated code according to the requirements to generate a Binder Client-side application; that is, select the above-generated JAVA / C++ / C code SDK to generate a Binder Client-side application;

[0114] S405: The Binder Client side accesses the Android Server side service for Inner Domain (its own domain) / Cross Domain (cross-domain) / Cross-Chip (cross-chip).

[0115] Similarly, based on the above implementation steps, the Android side can also act as a Client to remotely access the relevant services of other SoCs and other Domains.

[0116] See Figure 2 shown in the architecture diagram of the SOA application of this application. Figure 2 In it, HAL represents the hardware abstraction layer, User represents the user layer, Driver represents the driver layer, HW represents the hardware layer, CPU represents the central processing unit, GPU represents the graphics processing unit, NPU represents the network processing unit, and VPU represents the video processing unit.

[0117] The SOA application implementation method of this application embodiment realizes the application of cross-domain / cross-chip SOA solutions based on DDS and SOME / IP while implementing the SOA application within the Android system based on the existing Android Binder, effectively reducing the operating system complexity, expanding the SOA usage scenarios, and realizing the unified SOA framework application for the cockpit and intelligent driving.

[0118] In a second aspect, an embodiment of the present application further provides an SOA application implementation device.

[0119] In one embodiment, referring to Figure 3 , Figure 3 is a schematic diagram of the functional modules of the SOA application implementation device of the present application. As Figure 3 shown, the SOA application implementation device includes: a establishment module, a creation module, an extension module, and an execution module.

[0120] The establishment module is used to achieve cross-Domain support based on the initialization of the underlying RPMsg and the establishment of a communication link; the creation module is used to achieve cross-chip communication support based on the initialization of the underlying PCIe device and the establishment of a cross-chip communication link; the extension module is used to extend the communication protocol support for DDS and SOME / IP according to libbinder; the execution module is used to build an SOA application based on Android Binder, and the Android Service APP calls the AIDL JAVASDK to generate a Binder Server-side application.

[0121] In a third aspect, an embodiment of the present application provides an SOA application implementation device, and the SOA application implementation device can be a device with data processing functions such as a personal computer (PC), a laptop computer, a server, etc.

[0122] Referring to Figure 4 , Figure 4 is a schematic diagram of the hardware structure of the SOA application implementation device involved in the solution of the embodiment of the present application. In the embodiment of the present application, the SOA application implementation device may include a processor, a memory, a communication interface, and a communication bus.

[0123] Among them, the communication bus can be of any type and is used to interconnect the processor, the memory, and the communication interface.

[0124] The communication interface includes input / output (I / O) interfaces, physical interfaces, and logical interfaces, etc., which are used to implement the interconnection of components inside the SOA application implementation device, and interfaces for implementing the interconnection of the SOA application implementation device with other devices (such as other computing devices or user devices). The physical interface can be an Ethernet interface, an optical fiber interface, an ATM interface, etc.; the user device can be a display screen (Display), a keyboard (Keyboard), etc.

[0125] The memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical memory, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0126] The processor can be a general-purpose processor, which can call the SOA application implementation program stored in the memory and execute the SOA application implementation method provided in the embodiments of the present application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the SOA application implementation program is called can refer to the various embodiments of the SOA application implementation method of the present application, which will not be elaborated here.

[0127] Those skilled in the art can understand that Figure 4 the hardware structure shown in

[0128] does not constitute a limitation to the present application, and may include more or fewer components than shown in the figure, or combine some components, or have different component arrangements. The terms "including" and "having" and any variations thereof in the specification and claims of the present application and the above-mentioned drawings are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but optionally further includes steps or units not listed, or optionally further includes other steps or units inherent to these processes, methods, products or devices. The descriptions of terms such as "first", "second" and "third" are used to distinguish different objects, etc., and do not represent a sequence, nor do they limit that "first", "second" and "third" are different types.

[0129] In the description of the embodiments of the present application, "exemplary", "for example" or "for instance" are used to represent examples, illustrations or explanations. Any embodiment or design solution described as "exemplary", "for example" or "for instance" in the embodiments of the present application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, the use of words such as "exemplary", "for example" or "for instance" is intended to present relevant concepts in a specific manner.

[0130] In the description of the embodiments of the present application, unless otherwise specified, " / " means "or". For example, A / B may mean A or B. The "and / or" in the text is only a description of the association relationship between associated objects, indicating that there can be three relationships. For example, A and / or B may mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of the present application, "a plurality of" means two or more than two.

[0131] In some of the processes described in the embodiments of the present application, there are a plurality of operations or steps that appear in a specific order. However, it should be understood that these operations or steps may not be executed in the order in which they appear in the embodiments of the present application or may be executed in parallel. The serial numbers of the operations are only used to distinguish different operations, and the serial numbers themselves do not represent any order of execution. In addition, these processes may include more or fewer operations, and these operations or steps may be executed in sequence or in parallel, and these operations or steps may be combined.

[0132] Through the description of the above embodiments, those skilled in the art can clearly understand that the above-described embodiment methods can be implemented by means of software plus a necessary general hardware platform. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disc) as described above and includes several instructions for causing a terminal device to execute the methods described in the various embodiments of the present application.

[0133] The above are only the preferred embodiments of the present application, and do not limit the patent scope of the present application accordingly. Any equivalent structure or equivalent process transformation made by using the content of the specification and drawings of the present application, or directly or indirectly applied in other related technical fields, shall be equally included in the patent protection scope of the present application.

Claims

1. A method for implementing an SOA application, characterized in that The described SOA application implementation method includes: Based on the initialization of the underlying RPMsg and the establishment of the communication link, cross-Domain support is achieved; Based on the initialization of the underlying PCIe device and the establishment of the cross-chip communication link, cross-chip communication support is achieved; According to libbinder, the communication protocol support for DDS and SOME / IP is extended and implemented; Build an SOA application based on Android Binder. The Android Service APP calls the AIDL JAVA SDK to generate the Binder Server-side application; Among them, the cross-Domain support is achieved based on the initialization of the underlying RPMsg and the establishment of the communication link. Among them, for the initialization of the underlying RPMsg, it specifically includes: Configure the RPMsg virtual device, establish a dedicated communication channel between different software domains, allocate a shared memory area for data transmission, initialize the interrupt handling mechanism, establish an endpoint mapping table, and complete the initialization of RPMsg; Perform the initialization of the DDS transport layer, register the DDS transport plug-in to the RPMsg layer, create and manage the transport resource pool, initialize the message queue, and start the discovery service thread; Create domain participants, configure a unique identifier for each software domain, set QoS parameters according to actual needs, complete the initialization of the publish / subscribe service, and register the corresponding data types.

2. The method for implementing an SOA application according to claim 1, wherein The cross-Domain support is achieved based on the initialization of the underlying RPMsg and the establishment of the communication link. Among them, for the establishment of the communication link, it specifically includes: Configure the publisher, create a Topic, set the QoS policy of the publisher, allocate a buffer for the data to be sent, and register the corresponding callback function; Configure the subscriber, match the created Topic, set the QoS policy of the subscriber, allocate a buffer for receiving data, and register a data listener; Enter the discovery and matching phase. The publisher broadcasts a discovery message, the subscriber receives and responds to the discovery request, and the publisher and the subscriber exchange QoS parameters for negotiation. After successful negotiation, the communication link is established.

3. The SOA application implementation method according to claim 1, characterized in that, The cross-chip communication support is achieved based on the initialization of the underlying PCIe device and the establishment of the cross-chip communication link. Among them, for the initialization of the underlying PCIe device, it specifically includes: Scan the PCIe bus, discover and enumerate all PCIe devices, and allocate memory space and interrupt resources for each PCIe device; Configure the BAR area of the PCIe device, establish an address mapping relationship, and for DMA transmission, initialize the DMA controller, create a descriptor list, and allocate a DMA buffer; Configure the MSI / MSI-X interrupt vector, register the interrupt handling function, and complete the initialization of the PCIe device; Perform the initialization of the DDS transport layer, register the DDS transport plug-in to the PCIe transport layer, create and manage the transport resource pool, initialize the message queue, and start the discovery service thread; Create domain participants, configure a unique identifier for each chip, set the QoS parameters required for cross-chip communication, and complete the initialization of the publish / subscribe service.

4. The method for implementing an SOA application according to claim 3, wherein Based on the initialization of the underlying PCIe device and the establishment of the cross-chip communication link, support for cross-chip communication is implemented. Among them, for the establishment of the cross-chip communication link, it specifically includes: Configure the publisher, create a Topic for cross-chip communication, allocate a DMA send buffer based on the publisher QoS policy for PCIe transmission, and register a DMA completion callback function; Configure the subscriber, match the created Topic, set the QoS policy of the subscriber, allocate a DMA receive buffer, and register a data arrival callback function; Enter the discovery and matching process. The publisher broadcasts discovery messages through the PCIe bus. Subscribers on different chips receive and respond to the discovery requests. The publisher and the subscriber negotiate QoS parameters through PCIe transmission to determine the establishment of a cross-chip communication link.

5. The method for implementing an SOA application according to claim 1, wherein: According to libbinder, extend to implement support for the communication protocols of DDS and SOME / IP, specifically including the initialization of the SOME / IP protocol stack and the establishment of services; For the initialization of the SOME / IP protocol stack, it specifically includes: Load the SOME / IP configuration file and parse the service interface description, including the definitions of methods, events, and fields; Initialize the SOME / IP runtime environment, including creating a service lookup table, creating a message routing table, initializing a serializer, and configuring transmission parameters. Among them, for cross-domain / cross-chip scenarios, it is necessary to identify the network topologies of different domains / chips, establish network connections, and configure multicast addresses and port mappings; Start the SD module of SOME / IP and start service registration.

6. The method for implementing an SOA application according to claim 5, wherein For the establishment of services, it specifically includes: The service provider registers the service with the SD module and publishes service provider information, including service ID, instance ID, major version number, and network endpoints; Enable the event manager of the service provider to prepare for handling subscription requests. The service consumer discovers available services through the SD module, matches the required service interface version, parses the service endpoints information. When a matching service is found, it sends a service request to the service provider, and a communication session is established between the service provider and the service consumer; Handle the subscription management of services, including event group registration and event subscription request handling.

7. The SOA application implementation method according to claim 1, characterized in that, Build an SOA application based on AndroidBinder. The Android Service APP calls the AIDL JAVA SDK to generate a Binder Server-side application, specifically including: Define service interfaces based on the AIDL standard; Generate the code for the Server and Client sides based on Android AIDL. The code is the interface code for implementing SOA cross-domain / cross-chip communication; The Android Server registers the SOA service into the Android system and selects the communication protocol through the libbinder transact interface; On the cross-domain and cross-chip Client side, the generated code is selected according to requirements to generate the Binder Client-side application; The Binder Client accesses the Android Server service for Inner Domain / Cross Domain / Cross-Chip.

8. An SOA application implementation device, characterized in that, The SOA application implementation device includes: A setup module, which is used to implement cross-Domain support based on the initialization of the underlying RPMsg and the establishment of the communication link; A creation module, which is used to implement cross-chip communication support based on the initialization of the underlying PCIe device and the establishment of the cross-chip communication link; An extension module, which is used to extend and implement the communication protocol support for DDS and SOME / IP according to libbinder; An execution module, which is used to build an SOA application based on Android Binder. The Android Service APP calls the AIDL JAVA SDK to generate the Binder Server-side application; Among them, the cross-Domain support is implemented based on the initialization of the underlying RPMsg and the establishment of the communication link. Among them, for the initialization of the underlying RPMsg, it specifically includes: Configuring the RPMsg virtual device, establishing a dedicated communication channel between different software domains, allocating a shared memory area for data transmission, initializing the interrupt handling mechanism, establishing an endpoint mapping table, and completing the initialization of RPMsg; Initializing the DDS transport layer, registering the DDS transport plug-in to the RPMsg layer, creating and managing the transport resource pool, initializing the message queue, and starting the discovery service thread; Creating domain participants, configuring a unique identifier for each software domain, setting QoS parameters according to actual requirements, completing the initialization of the publish / subscribe service, and registering the corresponding data types.

9. An SOA application implementation device, characterized in that, The SOA application implementation device includes a processor, a memory, and an SOA application implementation program stored on the memory and executable by the processor. When the SOA application implementation program is executed by the processor, the steps of the SOA application implementation method according to any one of claims 1 to 7 are implemented.

Images