Android system SOA communication middleware architecture, method and device based on vsomep, processor and storage medium thereof

Abstract

The invention relates to an Android system SOA (service oriented architecture) communication middleware architecture based on vsomep, which is integrated in an Android system, runs as an independent process, and communicates with one or more Android application processes on the upper layer through a Binder IPC (internet protocol computer); the architecture comprises: a vsomeip protocol stack layer, which is used for realizing an SOME / IP communication protocol; the vsomeipBinding adaptation layer adopts a dynamic and static combination mode to decouple the protocol stack and the upper layer application; ara: a com core layer used for realizing a service API, managing a service instance and providing a security mechanism; and the HIDL interface layer is used for realizing Binder IPC communication with the Android application layer. A Manifest dynamic configuration mechanism and a LockDelay concurrency control mechanism are further introduced, and the problem of cross-process dynamic loading of service configuration files in the Android environment and the problem of conflicts during multi-process concurrency creation of service instances are solved respectively. According to the technical scheme, the stability, adaptability and maintainability of the SOA middleware in the Android system are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of automotive electronic software architecture, and more particularly to a service-oriented architecture (SOA) communication middleware, specifically an Android system SOA communication middleware architecture, method, apparatus, processor, and computer-readable storage medium based on vsomeip. Background Technology

[0002] SOA stands for Service Oriented Architecture, a software architecture design model and methodology. It aims to build a service-oriented framework for service-oriented configuration, development, functionality, and user experience in the automotive field, and has become a popular development area for new energy vehicles in recent years. The concept of SOA stems from the idea that "service-oriented" is an efficient way to operate software business and a good model for software development. This concept has long existed in the IT field, with ubiquitous client / server architectures embodying this model or architecture. However, SOA is a new concept in the automotive field. Compared to the openness, high throughput, and good fault tolerance of networks, the automotive field is characterized by relatively closed and fixed business processes, complex software systems, and high security requirements. Therefore, SOA software systems applied to the automotive field cannot simply copy the methods used in the IT field and require targeted design and implementation.

[0003] In-vehicle SOA is a distributed service architecture typically used for inter-domain and inter-chip communication to achieve distributed service deployment, flexible service assembly and disassembly, and convenient service upgrades and expansions. In-vehicle SOA frameworks are usually used in conjunction with Ethernet and SOME / IP, which has become an industry standard. This is because Ethernet has high bandwidth and a rich protocol stack, while SOME / IP is an application layer protocol tailored for in-vehicle environments, based on IP networks and featuring service-oriented characteristics; the three are naturally compatible. SOME / IP stands for Scalable Service-Oriented Middleware over IP, meaning "IP-based scalable service-oriented architecture," and it is both a network protocol and middleware, a SOA-based communication protocol customized for the in-vehicle environment.

[0004] vsomeip is an open-source SOME / IP library implemented in GENIVI, written in C++. Currently, it primarily implements SOME / IP communication and service discovery functions, with some added security mechanisms. As an open-source project, vsomeip is widely used in the automotive industry. Besides providing learning and simulation resources for industry personnel, vsomeip can basically meet the requirements of simple non-core controllers and can even be deployed in mass-produced products. However, it struggles to meet the demands of core controllers or high-performance requirements. Deploying vsomeip on an Android system requires more than just the library itself; a HAL layer service, Binder IPC communication, and an application development SDK package need to be built on top. This technical solution was developed to address the need for an automotive Android system with an in-vehicle SOA framework and the construction of an SOA communication middleware system for this purpose. Due to the widespread use of vsomeip, the system solution designed based on it has considerable applicability and can be widely referenced and used; hence, this application is submitted. Summary of the Invention

[0005] The purpose of this invention is to overcome the shortcomings of the prior art and provide an Android system SOA communication middleware architecture, method, apparatus, processor and computer-readable storage medium based on vsomeip.

[0006] To achieve the above objectives, the present invention provides an Android system SOA communication middleware architecture, method, apparatus, processor, and computer-readable storage medium based on vsomeip, as follows: This Android system SOA communication middleware architecture based on vsomeip is characterized by the fact that it is integrated into the Android system and runs as an independent process, communicating with one or more upper-layer Android application processes via BinderIPC. The architecture, from bottom to top, includes: vsomeip protocol stack layer, used to implement SOME / IP communication protocol; The vsomeipBinding adaptation layer, coupled above the vsomeip protocol stack layer, provides a unified operation interface to the upper layer that is decoupled from the underlying specific protocol stack. The ara::com core layer, coupled above the aforementioned vsomeipBinding adaptation layer, serves as the business core of the architecture, used to implement service-oriented application programming interfaces, manage the lifecycle of service instances, and provide service routing. The HIDL interface layer, implemented by the ara::com core layer, serves as the formal contract interface for Binder IPC communication with the Android application process. The dynamic configuration module, integrated into the ara::com core layer and the vsoispBinding adaptation layer, is used to receive service configuration information from the Android application process transmitted through the HIDL interface layer and dynamically configure it into the runtime environment of the vsoisp protocol stack layer. The concurrency control module, integrated within the ara::com core layer and located at the logical entry point for creating service instances, controls the concurrent access frequency of instance creation requests to the vsoiPbinding adaptation layer and the vsoiP protocol stack layer.

[0007] Preferably, the vsoiPbinding adaptation layer adopts a dynamic-static combined design pattern. Its static part provides a general interface for protocol stack initialization and runtime acquisition, while its dynamic part provides adaptation logic for the client and the service respectively, so as to decouple the ara::com core layer from the vsoiP protocol stack layer.

[0008] Preferably, the ara::com core layer adopts a management model that combines static entry points and dynamic instances, wherein, The static entry point, running in singleton mode, is used to manage the global initialization and configuration of the architecture and manages the lifecycle of all dynamic instances through a container. The aforementioned dynamic instance corresponds one-to-one with each Android application process requesting communication and is used to handle all communication transactions related to the corresponding process.

[0009] Preferably, the operating mechanism of the dynamic configuration module includes: During initialization, the Android application process reads its local service configuration manifest file and converts it into a string format. The configuration string is passed to the ara::com core layer through the HIDL interface layer. The configuration string is passed from the ara::com core layer to the vsomeipBinding adapter layer; The vsomeipBinding adaptation layer writes the configuration string to the read-write runtime directory specified by the vsomeip protocol stack layer, and triggers the vsomeip protocol stack layer to reload the configuration.

[0010] Preferably, the concurrency control module employs a LockDelay interval mechanism, the operation of which includes: Set a mutex lock at the logical entry point for creating service instances within the core layer of ara::com; The Android application process requesting to create an instance must compete for and acquire the mutex lock before it can execute the subsequent creation process; The mutex lock automatically starts a countdown timer when it is acquired, and automatically releases itself after a preset delay time. By combining the mutex lock with automatic delayed release, a certain time interval is forced between multiple creation requests.

[0011] Preferably, it also includes a two-way stabilization mechanism for monitoring the health status of the Binder communication link, which includes: By utilizing the Death_Recipient mechanism of Binder, the system passively monitors whether the Binder object of the aforementioned Android application process has died, and performs resource cleanup upon death; and Before initiating communication through Binder, actively call the Binder's ping() interface to check if the Android application process on the other end is alive.

[0012] Preferably, the dynamic instance holds a Binder callback object provided by its corresponding Android application process, and all communication transactions related to service discovery, method invocation, and event notification related to that process are handled through its dedicated dynamic instance.

[0013] The main feature of this Android system SOA communication middleware method based on vsomeip, which utilizes the architecture described above, is that the method includes the following steps: (1) Integrate the vsomeip protocol stack into the Android system and complete its basic compilation configuration; (2) Build a vsomeipBinding adaptation layer on top of the vsomeip protocol stack to achieve encapsulation and decoupling of the protocol stack; (3) Build the ara::com core layer on top of the aforementioned vsoiPinding adaptation layer to realize the lifecycle management of service APIs and service instances, as well as the routing function of service messages; (4) Based on the functions of the ara::com core layer, define and implement the HIDL interface to provide SOA service APIs for Android applications and connect to the ara::com core layer. (5) Implement a dynamic configuration module for dynamically loading service configuration in the ara::com core layer and vsomeipBinding adaptation layer; (6) Integrate a concurrency control module in the core layer of ara::com to control the creation concurrency frequency of service instances; (7) Integrate the communication middleware with the upper-layer Android application and other vehicle nodes to build a complete SOA demonstration system.

[0014] The main feature of this Android system SOA communication middleware device based on vsomeip is that the device includes: A processor is configured to execute computer-executable instructions; The memory stores one or more computer-executable instructions, which, when executed by the processor, implement the steps of the above-described Android system SOA communication middleware method based on vsomeip.

[0015] The main feature of this vsomeip-based Android system SOA communication middleware processor is that the processor is configured to execute computer-executable instructions, and when the computer-executable instructions are executed by the processor, the steps of the vsomeip-based Android system SOA communication middleware method described above are implemented.

[0016] The computer-readable storage medium is characterized in that it stores a computer program that can be executed by a processor to implement the steps of the above-described Android system SOA communication middleware method based on vsomeip.

[0017] The Android system SOA communication middleware architecture, method, device, processor, and computer-readable storage medium based on vsomeip of this invention have a clear hierarchical structure, good multi-service coordination and management, and good resource release; the static deployment and dynamic use of the service manifest are well coordinated, facilitating development and operation; the concurrent creation of services by multiple processes is safe and orderly, and no abnormal problems have been encountered; it has process keep-alive function and service reconnection function; the conversion of header information between upper layer messages and vsomeip protocol stack is correct and reliable, and no abnormal messages appear. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the Android system SOA communication middleware architecture based on vsomeip of the present invention.

[0019] Figure 2 This is a detailed structural diagram of the ara::com core layer of the present invention.

[0020] Figure 3 This is a schematic diagram of the Manifest transmission and dynamic configuration mechanism of the present invention.

[0021] Figure 4 This is a schematic diagram of the LockDelay interval mechanism of the present invention. Detailed Implementation

[0022] To more clearly describe the technical content of the present invention, the following description is provided in conjunction with specific embodiments.

[0023] Before describing the embodiments of the present invention in detail, it should be noted that, in the following, the terms “comprising,” “including,” or any other variations are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed or inherent to such process, method, article, or apparatus.

[0024] The components constructed in this invention, together with another component, constitute the main body of the SOA system. These two components are: an Android application that provides / consumes SOA services (the number is unlimited); and an SOA middleware module that provides communication functions, typically named ara::com in AUTOSAR (Automotive Standard). To connect these two components, the ara::com API interface and configuration file need to be deployed on the Android application side and customized. The ara::com API interface is implemented on the communication middleware side, enabling communication between the two components via IPC. The communication middleware ara::com forms its own system, decoupled from the application through the HIDL (Hardware Interface Description Language) interface. This technical solution focuses on the system design of the ara::com middleware.

[0025] To make the architecture clear, different positioning layers are separated, such as Figure 1 As shown, the ara::com solution designed in this paper is internally divided into three layers, from bottom to top: the vsoisp protocol stack layer, the vsoispBinding adaptation layer, and the ara::com core layer (containing the implementation of the ara::com API). This structural design meets the functional requirements, has good scalability, and facilitates the addition of new mechanisms. To improve the structural quality, stability, and scalability, several special mechanisms are introduced based on the above hierarchical structure and functional allocation.

[0026] Among them, such as Figure 2 As shown, the design of ara::com is detailed below.

[0027] 1) The vsomeip protocol stack layer integrates the open-source protocol stack into the Android system as an implementation of the SOME / IP communication protocol, and can be configured or replaced independently.

[0028] 2) The vsomeipBinding layer is an adaptation and decoupling layer that decouples its upper layers from the communication protocol stack below. This allows vsomeip to be replaced with other SOME / IP implementations or DDS protocol implementations, while its upper layers can face the same interface and data structure without significant changes. This adaptation layer adopts a "static and dynamic combination" design pattern (detailed below), combining static and dynamic components. The dynamic mode adapts the client and service sides separately.

[0029] 3) The core layer of ara::com first provides the implementation of the ara::com API interface, serving as a stub for communication with applications. Secondly, it provides the core functionalities of ara::com, including communication routing, providing communication instances for each application process, instance management, and security mechanisms. This layer also adopts a "static-dynamic" design pattern, corresponding to the vsomeipBinding layer, where the dynamic parts are adapted for the Proxy and Skeleton sides of the upper-layer API interface.

[0030] 4) ara::com employs a static entry point + dynamic instance design pattern. The static part serves as the backbone, providing functions such as initializing the protocol stack, obtaining the runtime singleton, loading configuration files, and creating dynamic instances through static interfaces. A container stores all dynamic instances and manages their lifecycle. The dynamic part consists of the created instance objects. An independent instance is created for each application layer process that communicates with ara::com, storing the application layer process's callbackBinder instance. All subsequent functions of ara::com and this application layer process run within this dedicated instance. Each dynamic instance is created by the static part when the application layer request is initialized and destroyed when the application layer request ends or an exception occurs. Its creation and destruction are managed by the static part. This distinguishes between common and dedicated functions and facilitates the management of each instance.

[0031] 5) Two-way stability mechanism. As a communication hub, the ara::com communication middleware needs high reliability. Besides ensuring correct communication, it must also minimize crashes caused by exceptions. There are two main causes of ara::com crashes: internal coding problems and IPC communication anomalies. The location of internal coding problems is uncertain and requires multiple avoidance methods. Here, a mechanism is used to prevent crashes caused by IPC communication anomalies. In Android, the main IPC method is Binder. To improve security, both listening and active polling methods (concurrency control) are employed. The former utilizes Binder's `Death_Recipient` mechanism to listen for exceptions from the application layer process's Callback Binder, mainly used for handling cleanup after Binder crashes; the latter actively detects Binder status through Binder's `ping()` interface to ensure safe communication each time (avoiding timing issues associated with listening). With both working together, except in extreme cases, ara::com crashes are generally not caused by IPC communication anomalies.

[0032] In practical use, vsomeip has encountered some performance issues. While modifying the protocol stack source code could solve these problems, this is too costly and the results may not be satisfactory. Therefore, it's better to add a new mechanism within the self-developed ara::com to address these issues. This technical solution addresses the mechanisms and shortcomings of the vsomeip protocol stack through targeted designs in several areas to ensure the system's stability and convenience. These targeted designs are as follows: Manifest delivery and dynamic configuration mechanisms. vsomeip has a mechanism that requires application processes to provide their SOA service configuration manifests in a specified directory within the vsomeip protocol stack. However, as application processes, this manifest is integrated and deployed in the application's directory, and each process manages it separately—a distributed deployment. Typically, configuration files are read using environment variables. The `export` method in the running script sets the Manifest path to environment variables, and the process reads the environment variables using the `getenv()` interface, then reads the configuration file based on the obtained file path. In the current scenario, the middleware process needs to read configuration files from various applications, which spans process spaces, and each application needs to provide different environment variables to avoid conflicts. Therefore, using environment variables is insufficient.

[0033] Therefore, an adaptation needs to be made between the two mechanisms to simultaneously meet the requirements of both. For example... Figure 3As shown, this mechanism works as follows: Before requesting the creation of the underlying vsoyip app instance, the application process reads the Manifest deployed in its respective directory, integrates it in String format, and passes it to the vsoyipBinding layer through the static interface provided by the ara::com API. The vsoyipBinding layer, as the operator of the vsoyip protocol stack, writes the obtained String-formatted Manifest to the vsoyip runtime directory through its provided static interface, and performs effective management and cleanup. This directory is then reassigned to a read-write partition to enable dynamic reading and writing. This simultaneously satisfies the independence of service file management and the configuration limitations of the existing vsoyip mechanism, achieving Manifest transmission and dynamic configuration. If the ara::com process crashes and restarts, it can directly read the configuration file without requiring the application process to provide it again.

[0034] The LockDelay interval mechanism addresses a concurrency issue with vsomeip. If multiple application processes concurrently request the creation of a vsomeip app instance (i.e., an app instance for vsomeip) from the vsomeip protocol stack, it may lead to creation anomalies, causing application processes to receive SOME / IP messages that do not belong to them. To address this, the LockDelay mechanism is designed to mitigate the concurrency of vsomeip app instance creation and avoid this problem. As its name suggests, LockDelay provides a mutex lock; processes requesting instance creation must compete for this lock, thus changing concurrency to serialization. Since this mechanism is suitable for deployment at the ara::com API implementation level, enabling interception as close to the edge as possible, and vsomeip app instance creation occurs two layers below in the vsomeip protocol stack, intermediate steps can introduce many uncertainties. Therefore, a delay mechanism is introduced on top of the mutex lock. Figure 4 As shown, when a lock is called using `lock()`, a countdown automatically starts, and the lock is automatically released after the countdown ends. This limits the lock's effective time without waiting for the previous process to finish executing, and also eliminates the need for application processes to manage the lock, thus avoiding synchronization and resource release issues. The combination of locks and delay mechanisms results in the `LockDelay` mechanism. In this way, each application process requests to create an instance, which is queued, and there is at least a specified time interval between two requesting processes. This time interval allows the process to maintain the lock without waiting for the former to release it, thereby resolving issues caused by the performance limitations of the vsoiip protocol stack itself.

[0035] By utilizing the above original and targeted design mechanisms, a clear and high-quality framework code has been built, which is convenient to read, use, and extend. It is stable and reliable and can run stably for a long time.

[0036] In one specific embodiment of this invention, an SOA function demonstration system is built, including an instrument panel (Linux system), a vehicle infotainment system (Android system), and a mobile phone (Android system). The SOA communication middleware system proposed in this paper is deployed on the vehicle infotainment system, including air conditioning services, multimedia services, ambient lighting services, etc.; other SOA solutions are deployed on the instrument panel, including vehicle information services. The deployed services are orchestrated into scene modes such as a rest mode and a welcome mode, triggered according to certain conditions. The mode orchestration can be set on the vehicle infotainment system or remotely on the mobile phone.

[0037] The entire system is based on the SOA communication middleware architecture deployed on the Android system proposed in this technical solution, and works with protocols such as MQTT and HTTP to achieve communication functions.

[0038] In a preferred embodiment of the present invention, following the above configuration, the vsoisp protocol stack is first integrated into the Android system. Based on its provided header file interfaces, a vsoispBinding layer is built on top of it, adapting downwards to the communication protocol stack and decoupling upwards from the underlying implementation. Then, an ara::com layer is built on top of vsoispBinding, implementing the corresponding modules AraComProxy and AraComSkeleton in ara::com, respectively. The creation, destruction, and management of application instances ProxyModel and SkeletonModel are implemented in Proxy and Skeleton, respectively. Based on the interfaces provided by vsoispBinding, an Android HIDL interface is defined and implemented in ara::com, interfacing downwards with the vsoispBinding interface and providing API interfaces for application layer programs upwards. Downlink call interfaces and uplink callback interfaces are connected between each layer, fully enabling connectivity between them.

[0039] The system receives a configuration string (all configuration information is aggregated into a single string) from the application layer process and passes it to the vsoiipBinding layer via the HIDL interface layer. This layer then implements the operation of writing the Manifest file based on the configuration string. Static singletons of LockDelay are introduced into AraComProxy and AraComSkeleton to limit the concurrent creation frequency of ProxyModel and SkeletonModel. Debugging and verification are then performed.

[0040] Once the communication middleware system is built, it will be gradually integrated with the application layer program and other modules to eventually connect the entire SOA system.

[0041] In practical applications, through the above implementation methods, this technical solution successfully built an SOA middleware communication system on the Android system, meeting the requirements for SOA function demonstration. Based on this SOA system, four services and seven clients were successfully deployed at the application layer, successfully building application scenarios such as welcome mode and rest mode, running continuously for more than a week. 1. The success rate of SOA communication between application layer processes reaches 100%; 2. SOA service discovery success rate is 100%; 3. The success rate of concurrent application instance initialization using ara::com reaches 100%; 4. No issues related to reading configuration files were encountered; 5. The number of times the ara::com middleware process crashed due to application layer program crashes or IPC exceptions was 0.

[0042] This effectively provides strong support for the development and verification of in-vehicle SOA.

[0043] Compared with existing technologies, this technical solution has the following significant advantages: Highly adaptable: It perfectly solves the integration problem of vsomeip in the Android system and breaks down the barrier between the C++ communication stack and the Java application layer.

[0044] Stable and reliable: Through the LockDelay mechanism and the two-way stabilization mechanism, the crash problem caused by concurrency exceptions and process exceptions is effectively solved. In actual tests, the middleware process can achieve stable operation for a long time.

[0045] Flexible and scalable: Through the abstraction of the vsomeipBinding adaptation layer, the system is no longer tightly dependent on vsomeip, laying the foundation for future adaptation to other communication protocols (such as DDS).

[0046] Facilitates development and deployment: The Manifest dynamic configuration mechanism simplifies the application deployment process. Developers do not need to worry about the final location of the configuration file in the system, which is in line with Android application development habits.

[0047] Verification shows that the SOA demonstration system built on this solution successfully deployed multiple services and clients, ran continuously for a week without failure, and achieved a 100% service communication success rate.

[0048] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0049] It should be understood that various parts of the present invention can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution device.

[0050] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0051] The storage media mentioned above can be read-only memory, disk, or optical disk, etc.

[0052] In the description of this specification, references to terms such as "an embodiment," "some embodiments," "example," "specific example," or "embodiment," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0053] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

[0054] The Android system SOA communication middleware architecture, method, device, processor, and computer-readable storage medium based on vsomeip of this invention have a clear hierarchical structure, good multi-service coordination and management, and good resource release; the static deployment and dynamic use of the service manifest are well coordinated, facilitating development and operation; the concurrent creation of services by multiple processes is safe and orderly, and no abnormal problems have been encountered; it has process keep-alive function and service reconnection function; the conversion of header information between upper layer messages and vsomeip protocol stack is correct and reliable, and no abnormal messages appear.

[0055] In this specification, the invention has been described with reference to specific embodiments thereof. However, it will be apparent that various modifications and variations can be made without departing from the spirit and scope of the invention. Therefore, the specification and drawings should be considered illustrative rather than restrictive.

Claims

1. An Android system SOA communication middleware architecture based on vsomeip, characterized in that, The architecture described is integrated within the Android system and runs as an independent process, communicating with one or more upper-layer Android application processes via Binder IPC; the architecture, from bottom to top, includes: vsomeip protocol stack layer, used to implement SOME / IP communication protocol; The vsomeipBinding adaptation layer, coupled above the vsomeip protocol stack layer, provides a unified operation interface to the upper layer that is decoupled from the underlying specific protocol stack. The ara::com core layer, coupled above the aforementioned vsomeipBinding adaptation layer, serves as the business core of the architecture, used to implement service-oriented application programming interfaces, manage the lifecycle of service instances, and provide service routing. The HIDL interface layer, implemented by the ara::com core layer, serves as the formal contract interface for BinderIPC communication with the Android application process. The dynamic configuration module, integrated into the ara::com core layer and the vsoispBinding adaptation layer, is used to receive service configuration information from the Android application process transmitted through the HIDL interface layer and dynamically configure it into the runtime environment of the vsoisp protocol stack layer. The concurrency control module, integrated within the ara::com core layer and located at the logical entry point for creating service instances, controls the concurrent access frequency of instance creation requests to the vsoiPbinding adaptation layer and the vsoiP protocol stack layer.

2. The Android system SOA communication middleware architecture based on vsomeip according to claim 1, characterized in that, The aforementioned vsoiPbinding adaptation layer adopts a dynamic-static combined design pattern. Its static part provides a general interface for protocol stack initialization and runtime acquisition, while its dynamic part provides adaptation logic for the client and the service respectively, so as to decouple the ara::com core layer from the vsoiP protocol stack layer.

3. The Android system SOA communication middleware architecture based on vsomeip according to claim 1, characterized in that, The core layer of ara::com adopts a management model that combines static entry points and dynamic instances. The static entry point, running in singleton mode, is used to manage the global initialization and configuration of the architecture and manages the lifecycle of all dynamic instances through a container. The aforementioned dynamic instance corresponds one-to-one with each Android application process requesting communication and is used to handle all communication transactions related to the corresponding process.

4. The Android system SOA communication middleware architecture based on vsomeip according to claim 1, characterized in that, The operating mechanism of the dynamic configuration module includes: During initialization, the Android application process reads its local service configuration manifest file and converts it into a string format. The configuration string is passed to the ara::com core layer through the HIDL interface layer. The configuration string is passed from the ara::com core layer to the vsomeipBinding adapter layer; The vsomeipBinding adaptation layer writes the configuration string to the read-write runtime directory specified by the vsomeip protocol stack layer, and triggers the vsomeip protocol stack layer to reload the configuration.

5. The Android system SOA communication middleware architecture based on vsomeip according to claim 1, characterized in that, The concurrency control module employs a LockDelay interval mechanism, the operation of which includes: Set a mutex lock at the logical entry point for creating service instances within the core layer of ara::com; The Android application process requesting to create an instance must compete for and acquire the mutex lock before it can execute the subsequent creation process; The mutex lock automatically starts a countdown timer when it is acquired, and automatically releases itself after a preset delay time. By combining the mutex lock with automatic delayed release, a certain time interval is forced between multiple creation requests.

6. The Android system SOA communication middleware architecture based on vsomeip according to claim 1, characterized in that, It also includes a two-way stabilization mechanism for monitoring the health of the Binder communication link, which includes: By utilizing the Death_Recipient mechanism of Binder, the system passively monitors whether the Binder object of the aforementioned Android application process has died, and performs resource cleanup upon death; and Before initiating communication through Binder, actively call the Binder's ping() interface to check if the Android application process on the other end is alive.

7. The Android system SOA communication middleware architecture based on vsomeip according to claim 3, characterized in that, The dynamic instance holds the Binder callback object provided by its corresponding Android application process. All communication transactions related to service discovery, method calls, and event notifications related to this process are handled through its dedicated dynamic instance.

8. A method for SOA communication middleware for Android systems based on vsomeip using the architecture described in any one of claims 1 to 7, characterized in that, The method includes the following steps: (1) Integrate the vsomeip protocol stack into the Android system and complete its basic compilation configuration; (2) Build a vsomeipBinding adaptation layer on top of the vsomeip protocol stack to achieve encapsulation and decoupling of the protocol stack; (3) Build the ara::com core layer on top of the aforementioned vsoiPinding adaptation layer to realize the lifecycle management of service APIs and service instances, as well as the routing function of service messages; (4) Based on the functions of the ara::com core layer, define and implement the HIDL interface to provide SOA service APIs for Android applications and connect to the ara::com core layer. (5) Implement a dynamic configuration module for dynamically loading service configuration in the ara::com core layer and vsomeipBinding adaptation layer; (6) Integrate a concurrency control module in the core layer of ara::com to control the creation concurrency frequency of service instances; (7) Integrate the communication middleware with the upper-layer Android application and other vehicle nodes to build a complete SOA demonstration system.

9. A VsomeIP-based Android system SOA communication middleware device, characterized in that, The device includes: A processor is configured to execute computer-executable instructions; The memory stores one or more computer-executable instructions, which, when executed by the processor, implement the steps of the Android system SOA communication middleware method based on vsomeip as described in claim 8.

10. A VsomeIP-based Android system SOA communication middleware processor, characterized in that, The processor is configured to execute computer-executable instructions, which, when executed by the processor, implement the steps of the Android system SOA communication middleware method based on vsomeip as described in claim 8.

11. A computer-readable storage medium, characterized in that, It stores a computer program that can be executed by a processor to implement the steps of the Android system SOA communication middleware method based on vsomeip as described in claim 8.

Images