SOA application implementation method, device and equipment

Abstract

The invention discloses an SOA application realization method, device and equipment, and relates to the technical field of communication application, the method comprises the following steps: realizing cross-Domain support based on initialization of a bottom layer RPMsg and establishment of a communication link; based on initialization of bottom PCIe equipment and establishment of a cross-chip communication link, support of cross-chip communication is realized; according to the libbinder, extension is carried out to realize communication protocol support for the DDS and the SOME / IP; according to the method, an SOA application based on Android Binder is constructed, an Android Service APP calls an AIDL JAVA SDK, and a Binder Server end application is generated. According to the method, the complexity of an operating system can be effectively reduced, and the use scene of the SOA is widened.

Description

Technical Field

[0001] The present application relates to the field of communication application technology, and in particular to a method, device and equipment for implementing SOA applications. Background Art

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

[0003] The cockpit is currently mainly based on Android OS (Operating System), and the Android SOA (Service-Oriented Architecture) framework is mainly based on Binder (a cross-process communication mechanism of the Android platform) IPC (inter-process communication). The intelligent driving field is usually dominated by OS such as Linux (an operating system) / QNX (a real-time operating system). Unlike the cockpit, such operating systems usually do not use Binder IPC, but use SOME / IP (extensible middleware based on IP-oriented services), DDS (a data-centric distributed communication protocol), RPMsg (inter-core communication protocol for multi-core systems), UDS (unified diagnostic service) and other IPC methods. Under the trend of cabin-driving business integration, the use of a unified SOA framework is of great benefit to improving the reusability and ecological compatibility of vehicle-mounted software. However, the current SOA software frameworks of the cockpit and intelligent driving domain are not consistent.

[0004] At the same time, the cockpit business and intelligent driving business are usually divided into two SoCs (System on Chip) or different domains of a SoC. The inconsistency of the underlying communication methods and the upper-level middleware between the two have caused problems such as inconsistent vehicle software development paradigms and poor compatibility of vehicle software. Summary of the invention

[0005] The present application provides a method, apparatus and device for implementing SOA applications, which can effectively reduce the complexity of the operating system and expand the application scenarios of SOA.

[0006] In a first aspect, an embodiment of the present application provides a method for implementing an SOA application, and the method for implementing an SOA application includes: Based on the initialization of the underlying RPMsg and the establishment of communication links, cross-domain support is achieved; Support for cross-chip communication is achieved based on initialization of underlying PCIe devices and establishment of cross-chip communication links; Based on libbinder, extend the communication protocol support for DDS and SOME / IP; Build a SOA application based on Android Binder. The Android Service APP calls the AIDL JAVA SDK to generate a Binder Server application.

[0007] In combination with the first aspect, in one implementation, the cross-Domain support is implemented based on the initialization of the underlying RPMsg and the establishment of the communication link, wherein the initialization of the underlying RPMsg 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; Initialize 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.

[0008] In combination with the first aspect, in one implementation, the cross-Domain support is implemented based on the initialization of the underlying RPMsg and the establishment of the communication link, wherein the establishment of the communication link specifically includes: Configure the publisher, create a Topic, set the publisher's QoS policy, allocate a buffer for the data to be sent, and register the corresponding callback function; Configure the subscriber, match the created Topic, set the subscriber's QoS policy, allocate a buffer for receiving data, and register a data listener; Entering the discovery and matching phase, the publisher broadcasts the discovery message, the subscriber receives and responds to the discovery request, the publisher and the subscriber exchange QoS parameters for negotiation, and a communication link is established after the negotiation is successful.

[0009] In combination with the first aspect, in one implementation, the support for cross-chip communication is implemented based on the initialization of the underlying PCIe device and the establishment of the cross-chip communication link, wherein the initialization of the underlying PCIe device specifically includes: Scan the PCIe bus, discover and enumerate all PCIe devices, and allocate memory space and interrupt resources to each PCIe device; Configure the BAR area of ​​the PCIe device, establish the 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 processing function, and complete the initialization of the PCIe device; Initialize 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 unique identifiers for each chip, set QoS parameters required for cross-chip communication, and complete the initialization of the publish / subscribe service.

[0010] In combination with the first aspect, in one implementation, the support for cross-chip communication is implemented based on the initialization of the underlying PCIe device and the establishment of the cross-chip communication link, wherein the establishment of the cross-chip communication link specifically includes: Configure the publisher, create a topic for cross-chip communication, set the publisher QoS policy based on PCIe transmission, allocate a DMA send buffer, and register a DMA completion callback function; Configure the subscriber, match the created Topic, set the subscriber's QoS policy, allocate DMA receiving buffer, and register the data arrival callback function; Entering the discovery and matching phase, the publisher broadcasts the discovery message through the PCIe bus, and the subscribers on different chips receive and respond to the discovery request. The publisher and subscriber negotiate QoS parameters through PCIe transmission to determine the establishment of a cross-chip communication link.

[0011] In combination with the first aspect, in one implementation, The expansion implements the communication protocol support for DDS and SOME / IP based on libbinder, specifically including the initialization of the SOME / IP protocol stack and the establishment of services; The initialization of the SOME / IP protocol stack includes: Load the SOME / IP configuration file and parse the service interface description, including the definition of methods, events, and fields; Initialize the SOME / IP runtime environment, including creating a service lookup table, creating a message routing table, initializing the serializer, and configuring transmission parameters. For cross-domain / cross-chip scenarios, it is necessary to identify the network topology 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.

[0012] In conjunction with the first aspect, in one implementation, establishing a service specifically includes: The service provider registers the service with the SD module and publishes the service provider information, including service ID, instance ID, major version number, and network endpoints; The service provider's event manager is started to prepare to process subscription requests. The service user discovers available services through the SD module, matches the required service interface version, and parses the service endpoints information. When a matching service is found, a service request is sent to the service provider. The service provider and the service user establish a communication session. Handles subscription management of services, including event group registration and event subscription request processing.

[0013] In combination with the first aspect, in one implementation, the construction of an Android Binder-based SOA application, where the Android Service APP calls the AIDL JAVA SDK to generate a Binder Server application, specifically includes: Define the service interface based on the AIDL standard; Generate server and client codes based on Android AIDL, which are interface codes for implementing SOA cross-domain / cross-chip communication; Android Server registers the SOA service to the Android system and selects the communication protocol through the libbinder transact interface; On the cross-domain and cross-chip client side, select the generated code according to the needs to generate the Binder Client application; The Binder Client accesses the Android Server service through Inner Domain / Cross Domain / Cross-Chip.

[0014] In a second aspect, an embodiment of the present application provides a SOA application implementation device, the SOA application implementation device comprising: Establish a module, which is used to implement cross-domain support based on the initialization of the underlying RPMsg and the establishment of communication links; Create a module for supporting cross-chip communication based on initialization of underlying PCIe devices and establishment of cross-chip communication links; Extension module, which is used to extend the communication protocol support for DDS and SOME / IP based on libbinder; The execution module is used to build a SOA application based on Android Binder. The Android Service APP calls the AIDL JAVA SDK to generate a Binder Server application.

[0015] In a third aspect, an embodiment of the present application provides a SOA application implementation device, comprising a processor, a memory, and a SOA application implementation program stored in the memory and executable by the processor, wherein when the SOA application implementation program is executed by the processor, the steps of the above-mentioned SOA application implementation method are implemented.

[0016] The beneficial effects brought by the technical solution provided in the embodiments of the present application include: While implementing SOA applications within the Android system based on the existing Android Binder, cross-domain and cross-chip SOA solution applications based on DDS and SOME / IP are realized, which effectively reduces the complexity of the operating system, broadens the usage scenarios of SOA, and realizes a unified SOA framework application for cockpit and intelligent driving. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 This is a flowchart of the SOA application implementation method for this application; Figure 2 This is a schematic diagram of the architecture of the SOA application for this application; Figure 3 This is a schematic diagram of the functional modules of the SOA application implementation device of this application; Figure 4 This is a schematic diagram of the hardware structure of the SOA application implementation device for this application. DETAILED DESCRIPTION

[0018] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0019] In order to make the objectives, technical solutions and advantages of the present application clearer, the implementation methods of the present application will be further described in detail below with reference to the accompanying drawings.

[0020] On the first aspect, an embodiment of the present application provides a SOA application implementation method that can meet the needs of cross-domain and cross-chip use of cockpit services and intelligent driving services.

[0021] In one embodiment, referring to Figure 1 , Figure 1 This is a flowchart of the SOA application implementation method of this application. Figure 1 As shown, the SOA application implementation method includes: S1: Based on the initialization of the underlying RPMsg and the establishment of the communication link, cross-domain support is achieved; S2: Support for cross-chip communication is achieved based on the initialization of the underlying PCIe device and the establishment of cross-chip communication links; S3: Based on libbinder, extend the communication protocol support for DDS and SOME / IP; S4: Build SOA application based on Android Binder. Android Service APP calls AIDL JAVASDK to generate Binder Server application. ‌libbinder‌ is the core implementation library of Binder inter-process communication mechanism in Android system. Binder is a cross-process communication mechanism of Android platform. AIDL is Android interface definition language, JAVA is object-oriented programming language, SDK is software development kit, Service means service, and APP means application.

[0022] While implementing SOA applications within 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 use scenarios of SOA.

[0023] Furthermore, in one embodiment, based on the initialization of the underlying RPMsg and the establishment of a communication link, cross-domain support is achieved, wherein the initialization of the underlying RPMsg specifically includes: 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 processing mechanism, establish an endpoint mapping table, and complete the initialization of RPMsg; S102: Initialize 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; S103: Create domain participants, configure a unique identifier for each software domain, set QoS (Quality of Service) parameters according to actual needs, complete the initialization of the publish / subscribe service, and register the corresponding data type.

[0024] Specifically, the initialization of the underlying RPMsg needs to be completed when the operating system starts. In this step, the RPMsg virtual device is first configured, a dedicated communication channel is established between different software domains, a shared memory area is allocated for data transmission, the interrupt handling mechanism is initialized, an endpoint mapping table is established, and the initialization of RPMsg is completed; after the RPMsg initialization is completed, the initialization of the DDS transport layer begins, the DDS transport plug-in is registered to the RPMsg layer, the 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 needs. The initialization of the publish / subscribe service is completed, and the corresponding data types are registered.

[0025] Furthermore, in one embodiment, based on the initialization of the underlying RPMsg and the establishment of the communication link, cross-domain support is achieved, wherein the establishment of the communication link specifically includes: S111: Configure the publisher, create a Topic (a communication method), set the publisher's QoS policy, allocate a buffer for the data to be sent, and register the corresponding callback function; S112: Configure the subscriber, match the created Topic, set the subscriber's QoS policy, allocate a buffer for receiving data, and register a data listener; S113: Entering the discovery and matching phase, the publisher broadcasts the discovery message, the subscriber receives and responds to the discovery request, the publisher and the subscriber exchange QoS parameters for negotiation, and a communication link is established after the negotiation is successful.

[0026] Specifically, after completing the initialization of the underlying RPMsg, the communication link establishment phase begins. In this phase, the publisher must first be configured, specifically creating a Topic, setting the publisher's QoS policy, allocating a buffer for the data to be sent, and registering the corresponding callback function. The subscriber is then configured to match the created Topic, set the subscriber's QoS policy, allocate a buffer for receiving data, register a data listener, etc., and then enters the discovery and matching phase. The publisher broadcasts a discovery message, the subscriber receives and responds to the discovery request, and the publisher and subscriber exchange QoS parameters for negotiation. After a successful negotiation, a stable communication link can be established.

[0027] It should be noted that when the communication link is established, the actual data transmission phase begins. When sending data, the application layer first writes the data to be transmitted, and the DDS transport layer serializes the data. If the amount of data is large and needs to be transmitted in fragments, the message will be fragmented, and then the data will be sent out through the RPMsg layer, and wait for the confirmation 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, and a confirmation response is sent to the sender, and finally the complete data is delivered to the application layer. In order to ensure the reliability of communication, the SOA application will assign a sequence number to each message, maintain the sending and receiving windows, implement a timeout retransmission mechanism, perform flow control, and monitor the link status through heartbeat detection.

[0028] For exception handling, SOA applications also need to handle various exceptions during the entire communication process. When a heartbeat timeout is detected, indicating a link interruption, the SOA application will immediately suspend data transmission, temporarily store the newly generated data in the buffer, and try to re-establish the connection, and then continue data transmission after the connection is restored; in addition, it is necessary to monitor memory usage in real time, release unused resources in a timely manner, and dynamically adjust the memory pool size to prevent memory leaks. When an error occurs, the SOA application will record a detailed error log, save the fault site information, execute the predetermined recovery strategy, and notify the application layer in a timely manner.

[0029] As for resource release, when communication needs to be closed, SOA applications will release resources in an orderly manner. First, ensure that all unsent data has been transmitted and confirmed, then close the data channel, and then clean up various resources, including deleting topics, destroying domain participants, releasing allocated memory, closing interrupts, etc. Finally, save the necessary configuration information, disconnect all connections, release device resources, and complete the exit of the entire process.

[0030] Further, in one embodiment, based on the initialization of the underlying PCIe device and the establishment of the cross-chip communication link, the support of cross-chip communication is realized, wherein the initialization of the underlying PCIe device specifically includes: S201: Scan the PCIe (high-speed serial computer expansion bus standard) bus, discover and enumerate all PCIe devices, and allocate memory space and interrupt resources to each PCIe device; S202: 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; BAR stands for Base Address Register; DMA stands for Direct Memory Access; S203: Configure the MSI / MSI-X interrupt vector, register the interrupt processing function, and complete the initialization of the PCIe device; MSI, the full name is Message Signaled Interrupts, that is, message signal interrupt; MSI-X, the full name is Extended MessageSignaled Interrupts, that is, extended message signal interrupt; S204: Initialize 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; 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.

[0031] 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, and then allocate memory space and interrupt resources for each PCIe device. Then, it will configure the BAR area of ​​the PCIe device and establish an address mapping relationship. For DMA transmission, it is necessary to initialize the DMA controller, create a descriptor list, and allocate a DMA buffer. At the same time, it is also necessary to configure the MSI / MSI-X interrupt vector, register the interrupt processing function, and complete the initialization of the PCIe device. After the PCIe initialization is completed, the DDS transport layer will be initialized, the DDS transport plug-in will be registered to the PCIe transport layer, the transport resource pool will be created and managed, the message queue will be initialized, the discovery service thread will be started, and then the domain participants will be created. A unique identifier will be configured for each chip, and the QoS parameters required for cross-chip communication will be set to complete the initialization of the publish / subscribe service.

[0032] Furthermore, in one embodiment, based on the initialization of the underlying PCIe device and the establishment of the cross-chip communication link, the support of cross-chip communication is implemented, wherein the establishment of the cross-chip communication link specifically includes: S211: Configure the publisher, create a Topic for cross-chip communication, set the publisher QoS policy based on PCIe transmission, allocate a DMA send buffer, and register a DMA completion callback function; S212: Configure the subscriber, match the created Topic, set the subscriber's QoS policy, allocate a DMA receiving buffer, and register a data arrival callback function; S213: Entering the discovery and matching phase, the publisher broadcasts the discovery message through the PCIe bus, and the subscribers on different chips receive and respond to the discovery request. The publisher and the subscriber negotiate QoS parameters through PCIe transmission to determine the establishment of a cross-chip communication link.

[0033] Specifically, in the stage of establishing a cross-chip communication link, the publisher is first configured, including creating a topic for cross-chip communication, a publisher QoS policy based on PCIe transmission, allocating a DMA send buffer, and registering a DMA completion callback function. Then the subscriber is configured, matching the created topic, setting the subscriber's QoS policy, allocating a DMA receive buffer, and registering a data arrival callback function. Then, the discovery and matching phase begins. The publisher broadcasts discovery messages through the PCIe bus, and subscribers on different chips receive and respond to discovery requests. The publisher and subscriber negotiate QoS parameters through PCIe transmission to determine the establishment of a stable cross-chip communication link.

[0034] It should be noted that after the cross-chip communication link is established, the actual data transmission begins. When sending data, after the application layer writes the data, the DDS transport layer first performs serialization processing. Due to the high bandwidth characteristics of PCIe, DMA will be used first for large-block data transmission. At this time, a DMA descriptor chain will be constructed, the DMA transfer engine will be started, and the data will be directly transferred to the memory of the target chip through the PCIe bus. At the same time, the target chip will be notified of the arrival of data through the 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 a confirmation message, and finally delivers the data to the application layer. To ensure transmission reliability, the SOA application will maintain the sending and receiving windows, implement a PCIe-based flow control mechanism, and monitor the cross-chip link status through heartbeat detection.

[0035] For exception handling, during cross-chip communication, SOA applications need to handle various exceptions. When a PCIe link interruption is detected, the SOA application will immediately suspend data transmission, cache new data locally, and try to restore the connection through mechanisms such as PCIe link training. For errors that may occur during DMA transmission, the SOA application will reset the DMA engine and reconstruct the descriptor for retransmission. In addition, it is necessary to monitor PCIe bandwidth usage in real time, reasonably allocate DMA channel resources, and prevent transmission congestion. When a serious error occurs, the SOA application will record detailed error information, save the current PCIe device status, and try to reset the device for recovery.

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

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

[0038] Furthermore, the initialization of the SOME / IP protocol stack specifically includes: S301: Load the SOME / IP configuration file and parse the service interface description, including the definition of methods, events, and fields; 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. For cross-domain / cross-chip scenarios, it is necessary to identify the network topology of different domains / chips, establish a network connection, and configure multicast addresses and port mappings. S303: Start the SD module of SOME / IP and start service registration. SD stands for Service Discover.

[0039] Specifically, when the operating system starts, the initialization of the SOME / IP protocol stack needs to be completed. First, the SOME / IP configuration file is loaded, and the service interface description is parsed, including the definition of methods, events, fields, etc. Then, the SOME / IP runtime environment is initialized, including creating a service lookup table, creating a message routing table, initializing the serializer, configuring transmission parameters, etc. For cross-domain / cross-chip scenarios, it is necessary to identify the network topology of different domains / chips, establish a network connection, and configure the multicast address and port mapping. After the initialization is completed, the SD module of SOME / IP is started and service registration begins.

[0040] Furthermore, the establishment of services specifically includes: S311: The service provider registers the service with the SD module and publishes the service provider information, including service ID, instance ID, major version number, and network endpoints. S312: The event manager of the service provider is started to prepare to process the subscription request. The service user discovers available services through the SD module, matches the required service interface version, and parses the service endpoints information. When a matching service is found, a service request is sent to the service provider. The service provider and the service user establish a communication session. S313: Processing service subscription management, including event group registration and event subscription request processing.

[0041] Specifically, when entering the service establishment phase, the service provider first registers the service with the SD module and publishes the service provider information, including service ID, instance ID, major version number, network endpoints, etc., and then starts the service provider's event manager to prepare to process subscription requests. The service user discovers available services through the SD module, matches the required service interface version, and parses the service endpoints information. When a matching service is found, a service request is sent to the service provider. The service provider and service user establish a communication session and also handle service subscription management, including event group registration and event subscription request processing.

[0042] It should be noted that after the service is established, in the data transmission stage, for method calls, the service user will construct a SOME / IP request message, including a message header (service ID, method ID, session ID, etc.) and a serialized payload, and then send 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, and constructs a response message after serializing the result and sends it back. For event notifications, when an event is triggered, the service provider will construct a SOME / IP notification message and send it to all subscribers. To ensure communication reliability, SOA applications implement functions such as retransmission mechanisms, timeout processing, and session management.

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

[0044] As for resource release, when closing the communication, resources need to be released in an orderly manner. First, stop all event notifications, clean up subscription relationships, then close the service session, unregister the service from the SD module, then release the message buffer, close the network connection, clean up the routing table, etc. Finally, save the necessary statistical information to complete the service exit process.

[0045] Furthermore, in one embodiment, a SOA application based on Android Binder is constructed, and the Android ServiceAPP calls the AIDL JAVA SDK to generate a Binder Server application, which specifically includes: S401: Define the service interface based on the AIDL standard; S402: Generate Server and Client codes based on Android AIDL, where the codes are interface codes for implementing SOA cross-domain / cross-chip communication; That is, based on Android AIDL, JAVA / C++ / C code is generated for Server and Client. 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), including unified interface definition and support for multi-language implementation (both Native interface and C / C++ interface are supported); 2. Communication abstraction. This code hides the underlying details, such as whether the underlying communication mechanism uses DDS, SOME / IP, or native Binder call, because DDS / SOME / IP has been integrated into the libbinder layer.

[0046] S403: Android Server registers the SOA service to the Android system and selects the communication protocol through the libbindertransact interface; S404: Select the generated code according to the requirements on the cross-domain and cross-chip client to generate a Binder Client application; that is, select the above-generated JAVA / C++ / C code SDK to generate the Binder Client application; S405: The Binder Client accesses the Android Server service through Inner Domain / Cross Domain / Cross-Chip.

[0047] Similarly, based on the above implementation steps, the Android end can also act as a client to remotely access related services of other SoCs and other Domains.

[0048] See also Figure 2 As shown, this is a schematic diagram of the architecture of the SOA application of this application. Figure 2 In the figure, HAL stands for hardware abstraction layer, User stands for user layer, Driver stands for driver layer, HW stands for hardware layer, CPU stands for central processing unit, GPU stands for graphics processing unit, NPU stands for network processing unit, and VPU stands for video processing unit.

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

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

[0051] In one embodiment, referring to Figure 3 , Figure 3 This is a functional module diagram of the SOA application implementation device of this application. Figure 3 As shown, the SOA application implementation device includes: a building module, a creation module, an extension module, and an execution module.

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

[0053] In a third aspect, an embodiment of the present application provides a SOA application implementation device, which may be a personal computer (PC), a laptop computer, a server, or other device with data processing capabilities.

[0054] Reference Figure 4 , Figure 4 The hardware structure diagram of the SOA application implementation device involved in the embodiment of the present application is shown in FIG. 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.

[0055] The communication bus may be of any type and is used to interconnect the processor, the memory, and the communication interface.

[0056] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces, which are used to interconnect devices within SOA application implementation devices, and interfaces used to interconnect SOA application implementation devices with other devices (such as other computing devices or user devices). Physical interfaces can be Ethernet interfaces, optical fiber interfaces, ATM interfaces, etc.; user devices can be display screens (Display), keyboards (Keyboard), etc.

[0057] 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 storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

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

[0059] Those skilled in the art will understand that Figure 4 The hardware structure shown in the figure does not constitute a limitation on the present application, and may include more or less components than shown in the figure, or combine certain components, or arrange the components differently.

[0060] The terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned drawings are intended to cover non-exclusive inclusions. 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 includes steps or units that are not listed, or optionally includes other steps or units inherent to these processes, methods, products or devices. The terms "first", "second" and "third" are used to distinguish different objects, etc., and do not represent a sequence, nor do they limit "first", "second" and "third" to different types.

[0061] In the description of the embodiments of the present application, "exemplary", "for example" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary", "for example" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary", "for example" or "for example" is intended to present related concepts in a specific way.

[0062] In the description of the embodiments of the present application, unless otherwise specified, “ / ” means or, for example, A / B can mean A or B; the “and / or” in the text is merely a description of the association relationship of associated objects, indicating that three relationships may exist, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in the description of the embodiments of the present application, “multiple” refers to two or more than two.

[0063] In some processes described in the embodiments of the present application, multiple operations or steps that appear in a specific order are included, but 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 in parallel, and the sequence number of the operation is only used to distinguish the different operations, and the sequence number itself does not represent any execution order. 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.

[0064] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on such an understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, disk, CD) as described above, and includes a number of instructions for a terminal device to execute the methods described in each embodiment of the present application.

[0065] The above are only preferred embodiments of the present application, and are not intended to limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A method for implementing SOA application, characterized in that: The SOA application implementation method comprises: Based on the initialization of the underlying RPMsg and the establishment of communication links, cross-domain support is achieved; Support for cross-chip communication is achieved based on initialization of underlying PCIe devices and establishment of cross-chip communication links; Based on libbinder, extend the communication protocol support for DDS and SOME / IP; Build a SOA application based on Android Binder. The Android Service APP calls the AIDL JAVA SDK to generate a Binder Server application.

2. A method for implementing SOA applications as claimed in claim 1, characterized in that: Based on the initialization of the underlying RPMsg and the establishment of the communication link, cross-Domain support is achieved, wherein the initialization of the underlying RPMsg 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; Initialize 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.

3. A method for implementing SOA applications as claimed in claim 2, characterized in that: Based on the initialization of the underlying RPMsg and the establishment of the communication link, cross-Domain support is achieved, wherein the establishment of the communication link specifically includes: Configure the publisher, create a Topic, set the publisher's QoS policy, allocate a buffer for the data to be sent, and register the corresponding callback function; Configure the subscriber, match the created Topic, set the subscriber's QoS policy, allocate a buffer for receiving data, and register a data listener; Entering the discovery and matching phase, the publisher broadcasts the discovery message, the subscriber receives and responds to the discovery request, the publisher and the subscriber exchange QoS parameters for negotiation, and a communication link is established after the negotiation is successful.

4. A method for implementing SOA applications as claimed in claim 1, characterized in that: The support for cross-chip communication is achieved based on the initialization of the underlying PCIe device and the establishment of the cross-chip communication link, wherein the initialization of the underlying PCIe device specifically includes: Scan the PCIe bus, discover and enumerate all PCIe devices, and allocate memory space and interrupt resources to each PCIe device; Configure the BAR area of ​​the PCIe device, establish the 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 processing function, and complete the initialization of the PCIe device; Initialize 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 unique identifiers for each chip, set QoS parameters required for cross-chip communication, and complete the initialization of the publish / subscribe service.

5. A method for implementing SOA application as claimed in claim 4, characterized in that: Based on the initialization of the underlying PCIe device and the establishment of the cross-chip communication link, the cross-chip communication support is realized, wherein the establishment of the cross-chip communication link specifically includes: Configure the publisher, create a topic for cross-chip communication, set the publisher QoS policy based on PCIe transmission, allocate a DMA send buffer, and register a DMA completion callback function; Configure the subscriber, match the created Topic, set the subscriber's QoS policy, allocate the DMA receiving buffer, and register the data arrival callback function; Entering the discovery and matching phase, the publisher broadcasts the discovery message through the PCIe bus, and the subscribers on different chips receive and respond to the discovery request. The publisher and subscriber negotiate QoS parameters through PCIe transmission to determine the establishment of a cross-chip communication link.

6. A method for implementing SOA applications as claimed in claim 1, characterized in that: The expansion implements the communication protocol support for DDS and SOME / IP based on libbinder, specifically including the initialization of the SOME / IP protocol stack and the establishment of services; The initialization of the SOME / IP protocol stack includes: Load the SOME / IP configuration file and parse the service interface description, including the definition of methods, events, and fields; Initialize the SOME / IP runtime environment, including creating a service lookup table, creating a message routing table, initializing the serializer, and configuring transmission parameters. For cross-domain / cross-chip scenarios, it is necessary to identify the network topology 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.

7. A method for implementing SOA applications as claimed in claim 6, characterized in that: The establishment of services specifically includes: The service provider registers the service with the SD module and publishes the service provider information, including service ID, instance ID, major version number, and network endpoints; The service provider's event manager is started to prepare to process subscription requests. The service user discovers available services through the SD module, matches the required service interface version, and parses the service endpoints information. When a matching service is found, a service request is sent to the service provider. The service provider and the service user establish a communication session. Handles subscription management of services, including event group registration and event subscription request processing.

8. A method for implementing SOA applications as claimed in claim 1, characterized in that: The construction of SOA application based on AndroidBinder, Android Service APP calls AIDL JAVA SDK to generate Binder Server application, specifically including: Define the service interface based on the AIDL standard; Generate server and client codes based on Android AIDL, which are interface codes for implementing SOA cross-domain / cross-chip communication; Android Server registers the SOA service to the Android system and selects the communication protocol through the libbinder transact interface; On the cross-domain and cross-chip client side, select the generated code according to the needs to generate the Binder Client application; The Binder Client accesses the Android Server service through Inner Domain / Cross Domain / Cross-Chip.

9. A SOA application implementation device, characterized in that: The SOA application implementation device comprises: Establish a module, which is used to implement cross-domain support based on the initialization of the underlying RPMsg and the establishment of communication links; Create a module for supporting cross-chip communication based on initialization of underlying PCIe devices and establishment of cross-chip communication links; Extension module, which is used to extend the communication protocol support for DDS and SOME / IP based on libbinder; The execution module is used to build a SOA application based on Android Binder. The Android Service APP calls the AIDL JAVA SDK to generate a Binder Server application.

10. A SOA application implementation device, characterized in that: The SOA application implementation device includes a processor, a memory, and a SOA application implementation program stored in the memory and executable by the processor, wherein 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 8 are implemented.

Images