Service-Oriented Architecture Based on Binder

Abstract

A service-oriented architecture implemented based on Binder. It is compatible with cross-domain / chip communication methods based on the existing Android binder driver, effectively reducing system complexity and expanding the usage scenarios of SOA; it extends cross-domain and cross-chip communication methods at the Android binder driver layer, directly leveraging the underlying inter-core / inter-chip communication mechanism, without relying on SOA communication frameworks such as DDS and SOME / IP, and is compatible with usage in different scenarios such as the automotive field and the IOT field.

Description

Technical Field

[0001] This application relates to the field of vehicle technologies, and more particularly to a service-oriented architecture implemented based on Binder. Background Art

[0002] Currently, the cockpit mainly uses Android OS, and the Android SOA framework is mainly built on the basis of Binder IPC. In the field of intelligent driving, Linux / QNX and other operating systems are usually used. Different from the cockpit, such operating systems usually do not use Binder IPC, but use SomeIP / DDS complex message queue middleware for communication. In the trend of the integration of in-vehicle software and IoT (Internet of Things) software, using a unified SOA framework is of great benefit to improving the reusability and ecological compatibility of in-vehicle software. However, the current SOA software frameworks in the cockpit and intelligent driving domains are not consistent, and there is no unified SOA framework for business interaction with the IoT system.

[0003] In addition, the cockpit business and the intelligent driving business usually belong to two different SOCs or different domains of one SOC. The non-uniformity of the underlying communication methods and the non-uniformity of the upper-layer middleware between the two have caused problems such as inconsistent in-vehicle software development paradigms and poor in-vehicle software compatibility. Summary of the Invention

[0004] To solve the above technical problems, this application provides a service-oriented architecture implemented based on Binder.

[0005] In a first aspect, an embodiment of this application provides a service-oriented architecture implemented based on Binder. The service-oriented architecture implemented based on Binder includes a Binder core processing module, an extended Binder driver module, a cross-domain implementation module, and a cross-chip implementation module, where:

[0006] The Binder core processing module is used to implement the basic Binder inter-process communication function, manage the Binder reference count and object mapping, and process the serialization and deserialization of Binder transmission data;

[0007] The extended Binder driver module inherits from the Binder core processing module and extends its functions. It determines whether a service call is a local call or a cross-domain / cross-chip call. For local calls, it is processed through the native Binder mechanism, and for cross-domain / cross-chip calls, it is handed over to the transmission management sub-module for processing;

[0008] The transmission management sub-module in the extended Binder driver module manages multiple transmission channels, realizes the registration, destruction, and status management of the transmission channels, and is responsible for message routing and forwarding;

[0009] The channel management sub-module in the extended Binder driver module is responsible for channel management, including channel lifecycle management, channel connection status monitoring, and channel data transceiver processing;

[0010] The cross-domain implementation module, based on the inter-domain communication mechanism, realizes the inter-domain transmission channel, provides reliable message transmission, and supports the asynchronous communication mode;

[0011] The cross-chip implementation module, based on the inter-chip communication mechanism, realizes the inter-chip transmission channel, supports high-bandwidth data transmission, and realizes DMA transmission optimization.

[0012] Combined with the first aspect, in one implementation, the extended Binder driver module inherits from the Binder core processing module and extends its functions, specifically including:

[0013] Inherit the basic inter-process communication mechanism and interfaces of the Binder core processing module;

[0014] Maintain compatibility with the native Binder;

[0015] Through the transmission management sub-module and the channel management sub-module, extend and implement the cross-domain / cross-chip communication capabilities;

[0016] Add the transmission channel management function.

[0017] Combined with the first aspect, in one implementation, the cooperation relationship between the modules is as follows:

[0018] The extended Binder driver module is responsible for intercepting and identifying cross-domain / cross-chip call requests based on the Binder core processing module interface, calling the transmission management sub-module for routing and forwarding. The transmission management sub-module returns the processing result to the extended Binder driver module, and the extended Binder driver module returns the result to the application layer;

[0019] The transmission management sub-module maintains the global routing policy, calls the channel management sub-module for specific channel operations. The channel management sub-module registers the channel information with the transmission management sub-module and notifies the transmission management sub-module of the channel status change;

[0020] The channel management sub-module manages specific transmission channel instances, calls the cross-domain implementation module / cross-chip implementation module to perform data transmission. The cross-domain implementation module / cross-chip implementation module notifies the channel management sub-module of the message arrival through callbacks, and the channel management sub-module delivers the message to the upper layer for processing.

[0021] In combination with the first aspect, in one implementation, the direction of the downlink data stream is: from the application layer to the Binder core processing module, from the Binder core processing module to the extended Binder driver module, from the extended Binder driver module to the transmission management sub-module, from the transmission management sub-module to the channel management sub-module, and from the channel management sub-module to the cross-domain implementation module / cross-chip implementation module;

[0022] The direction of the uplink data stream is: from the cross-domain implementation module / cross-chip implementation module to the channel management sub-module, from the channel management sub-module to the transmission management sub-module, from the transmission management sub-module to the extended Binder driver module, from the extended Binder driver module to the Binder core processing module, and from the Binder core processing module to the application layer.

[0023] In combination with the first aspect, in one implementation, when the extended Binder driver module detects a cross-domain call request, it forwards the cross-domain call request to the transmission management sub-module for processing; the transmission management sub-module is responsible for managing and scheduling the inter-domain transmission channels, including maintaining the creation and destruction of the inter-domain channels, monitoring the connection status of the channels, handling channel exceptions and recovery, and implementing message distribution and forwarding; the transmission management sub-module interacts with the extended Binder driver module through a unified interface, and the unified interface includes a channel management interface, a message sending and receiving interface, and a channel status query and notification interface;

[0024] The channel management sub-module is responsible for maintaining the routing relationship between domains, including assigning a unique identifier to each domain, establishing a mapping relationship between the domain identifier and the physical channel, and maintaining a routing table in the kernel shared memory;

[0025] The channel management sub-module provides a management interface for routing information, including the transmission management sub-module obtaining the transmission channel corresponding to the target domain through the query interface, the cross-domain implementation module obtaining the next-hop information of the message through the query interface, and supporting dynamic update of the routing table entries;

[0026] The channel management sub-module implements routing status monitoring, including detecting the channel connection status, updating the routing table when the channel is abnormal, and notifying the transmission management sub-module to perform channel switching.

[0027] In combination with the first aspect, in one implementation, the cross-domain implementation module implements endpoint management based on the virtio mechanism, including allocating virtio endpoint resources during channel creation, assigning a unique endpoint identifier to each domain, maintaining the status information of the endpoints, and releasing the endpoint resources when the channel is closed;

[0028] The cross-domain implementation module implements message queue management, including creating sending and receiving message queues, implementing memory management of the queues, handling situations such as queue full / empty, and implementing priority-based queue scheduling;

[0029] The cross - domain implementation module provides reliable transmission guarantees, including implementing flow control based on a sliding window, using sequence numbers and acknowledgment mechanisms, supporting timeout retransmission, and implementing congestion control;

[0030] The cross - domain implementation module completes cross - domain message routing, including obtaining routing information from the channel management sub - module, selecting the next hop based on the target domain, forwarding data through the virtio endpoint, and handling exceptions during the forwarding process.

[0031] In one implementation manner in combination with the first aspect, when the extended Binder driver module detects a cross - chip call request, it transfers the cross - chip call request to the transmission management sub - module for processing; the transmission management sub - module is responsible for managing and scheduling the inter - chip transmission channels, including maintaining the creation and destruction of the inter - chip transmission channels, monitoring the connection status of the channels, handling channel exceptions and recovery, and implementing message distribution and forwarding; the transmission management sub - module interacts with the extended Binder driver module through a unified interface, and the unified interface includes a channel management interface, a message sending and receiving interface, and a channel status query and notification interface;

[0032] The channel management sub - module is responsible for maintaining the routing relationship between chips, including assigning a unique identifier to each chip, establishing a mapping relationship between the chip identifier and the inter - chip transmission channel, and maintaining a routing table in the kernel shared memory;

[0033] The channel management sub - module provides a management interface for routing information, including the transmission management sub - module obtaining the corresponding transmission channel of the target chip through the query interface, the cross - chip implementation module obtaining the next - hop information of the message through the query interface, and supporting dynamic update of the routing table entries;

[0034] The channel management sub - module implements routing status monitoring, including detecting the channel connection status, updating the routing table when the channel is abnormal, and notifying the transmission management sub - module to perform channel switching.

[0035] In one implementation manner in combination with the first aspect, the cross - chip implementation module provides standard interfaces, including a DMA channel management interface, a shared memory operation interface, an interrupt registration interface, and a message sending and receiving interface; the extended Binder driver module completes the control and data transmission of cross - chip communication through the standard interfaces provided by the cross - chip implementation module.

[0036] In one implementation manner in combination with the first aspect, the cross - chip implementation module is used to implement DMA transmission channel management, shared memory management, interrupt processing mechanism, and circular buffer management, where:

[0037] DMA transfer channel management, including the creation of DMA channels, the DMA transfer process, and channel status management; the creation of DMA channels includes: applying for DMA resources, configuring the DMA controller, initializing DMA descriptors, and establishing transfer channels; the DMA transfer process includes constructing a DMA descriptor chain, configuring transfer parameters, starting DMA transfer, and waiting for transfer completion; channel status management includes monitoring channel status, handling transfer errors, and implementing channel reset;

[0038] Shared memory management, including memory area mapping and memory access control; memory area mapping includes allocating continuous physical memory, establishing BAR mapping, and configuring MMU mapping; memory access control includes implementing memory barriers, handling cache coherence, and protecting shared data;

[0039] The interrupt handling mechanism includes an interrupt registration process, an interrupt handling process, and interrupt optimization. The interrupt registration process includes applying for interrupt resources, registering an interrupt handling function, and configuring the interrupt controller; the interrupt handling process includes receiving an interrupt signal, identifying the interrupt type, calling the corresponding handling function, and clearing the interrupt status; interrupt optimization includes implementing interrupt aggregation, reducing the number of interrupts, and optimizing the response latency;

[0040] Ring buffer management, including buffer initialization, data read and write operations, and memory management. Buffer initialization includes allocating buffer memory, initializing read and write pointers, and configuring buffer parameters; data read and write operations include implementing lock-free read and write, handling buffer full / empty, and ensuring data continuity; memory management includes optimizing memory usage, implementing memory reuse, and handling memory fragmentation.

[0041] Combined with the first aspect, in one implementation, the service-oriented architecture based on Binder is built based on Android AIDL.

[0042] The beneficial effects brought by the technical solutions provided in the embodiments of this application include:

[0043] Based on the existing Android binder driver, it is compatible with cross-domain / chip communication methods, effectively reducing system complexity and expanding the usage scenarios of SOA; by using the Android binder driver layer to extend cross-domain and cross-chip communication methods, directly leveraging the underlying inter-core / inter-chip communication mechanism, it does not rely on SOA communication frameworks such as DDS and SOME / IP, and is compatible with usage in different scenarios such as the automotive field and the IOT field. Brief Description of the Drawings

[0044] Figure 1 It is a schematic diagram of the functional modules of an embodiment of the service-oriented architecture based on Binder of this application. Detailed Embodiments

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

[0046] First, some technical terms in this application are explained to facilitate the understanding of this application by those skilled in the art.

[0047] SOA: Service-Oriented Architecture, service-oriented architecture;

[0048] DPC: Inter-Domain Communication, where Domain means domain, referring to an independently operating unit in a network;

[0049] CPC: Inter-Chip Communication;

[0050] Binder: An inter-process communication (IPC) mechanism on the Android platform;

[0051] AIDL: Android Interface Definition Language, that is, Android Interface Definition Language;

[0052] IoT: Internet of Things, Internet of Things;

[0053] SHM: Shared Memory, shared memory;

[0054] rpmsg: Remote Processor Messaging, a lightweight, message-driven communication mechanism for communicating between different processors;

[0055] PCIe: Peripheral Component Interconnect Express, a high-speed serial computer expansion bus standard for providing high-speed and reliable communication between internal components of a computer.

[0056] To make the purpose, technical solutions, and advantages of this application clearer, the embodiments of this application will be further described in detail below in conjunction with the accompanying drawings.

[0057] In a first aspect, an embodiment of this application provides a service-oriented architecture implemented based on Binder.

[0058] In one embodiment, referring to Figure 1 , Figure 1 This is a schematic diagram of the functional modules of an embodiment of the service-oriented architecture implemented based on Binder in this application. As Figure 1 shown, the service-oriented architecture implemented based on Binder includes a Binder core processing module 10, an extended Binder driver module 20, a cross-domain implementation module 30, and a cross-chip implementation module 40, where:

[0059] The Binder core processing module 10 is used to implement the basic Binder inter-process communication function, manage the Binder reference count and object mapping, and process the serialization and deserialization of Binder transmission data;

[0060] The extended Binder driver module 20 inherits from the Binder core processing module 10 and extends its functions. It works in coordination with the transmission management sub-module 201 to determine whether a service call is a local call or a cross-domain / cross-chip call. For local calls, it is processed through the native Binder mechanism, and for cross-domain / cross-chip calls, it is handed over to the transmission management sub-module 201 for processing;

[0061] Furthermore, in one embodiment, the extended Binder driver module 20 inherits from the Binder core processing module 10 and extends its functions, specifically including:

[0062] Inheriting the basic inter-process communication mechanism and interfaces of the Binder core processing module 10;

[0063] Maintaining compatibility with the native Binder;

[0064] Extending and implementing cross-domain / cross-chip communication capabilities through the transmission management sub-module 201 and the channel management sub-module 202;

[0065] Adding a transmission channel management function.

[0066] The transmission management sub-module 201 in the extended Binder driver module 20 manages multiple transmission channels, implements the registration, destruction, and status management of transmission channels, and is responsible for message routing and forwarding; among them, the multiple transmission channels include inter-domain transmission channels and inter-chip transmission channels;

[0067] The channel management sub-module 202 in the extended Binder driver module 20 is responsible for channel management, including channel lifecycle management, channel connection status monitoring, and channel data sending and receiving processing;

[0068] The cross-domain implementation module 30 provides reliable message transmission based on the inter-domain transmission channel implemented by the inter-domain communication mechanism and supports the asynchronous communication mode;

[0069] In this embodiment, the inter-domain communication mechanism is selected based on actual needs, such as rpmsg, SHM, etc.

[0070] The cross-chip implementation module 40, based on the inter-chip transmission channel implemented by the inter-chip communication mechanism, supports high-bandwidth data transmission and realizes DMA transmission optimization.

[0071] In this embodiment, the inter-chip communication mechanism is selected based on actual needs, such as PCIe, ETH, etc.

[0072] Furthermore, in one embodiment, the cooperation relationship between the modules is as follows:

[0073] The extended Binder driver module 20 is responsible for intercepting and identifying cross-domain / cross-chip call requests based on the Binder core processing module interface, and calls the transmission management sub-module 201 for routing and forwarding. The transmission management sub-module 201 returns the processing result to the extended Binder driver module 20, and the extended Binder driver module 20 returns the result to the application layer;

[0074] The transmission management sub-module 201 maintains the global routing policy, calls the channel management sub-module 202 for specific channel operations. The channel management sub-module 202 registers channel information with the transmission management sub-module 201 and notifies the transmission management sub-module 201 of channel status changes;

[0075] The channel management sub-module 202 manages specific transmission channel instances, calls the cross-domain implementation module 30 / cross-chip implementation module 40 to perform data transmission. The cross-domain implementation module 30 / cross-chip implementation module 40 notifies the channel management sub-module 202 of message arrival through callbacks, and the channel management sub-module 202 delivers the message to the upper layer for processing.

[0076] Furthermore, in one embodiment, the direction of the downstream data flow is: application layer → Binder core processing module 10 → extended Binder driver module 20 → transmission management sub-module 201 → channel management sub-module 202 → cross-domain implementation module 30 / cross-chip implementation module 40;

[0077] The direction of the upstream data flow is: cross-domain implementation module 30 / cross-chip implementation module → channel management sub-module 202 → transmission management sub-module 201 → extended Binder driver module 20 → Binder core processing module 10 → application layer.

[0078] Further, in one embodiment, when the extended Binder driver module 20 detects a cross-domain call request, it forwards the cross-domain call request to the transmission management sub-module for processing 201; the transmission management sub-module 201 is responsible for managing and scheduling the inter-domain transmission channels, including maintaining the creation and destruction of the inter-domain channels, monitoring the connection status of the channels, handling channel exceptions and recovery, and implementing message distribution and forwarding; the transmission management sub-module 201 interacts with the extended Binder driver module 20 through a unified interface, and the unified interface includes a channel management interface, a message sending and receiving interface, and a channel status query and notification interface;

[0079] The channel management sub-module 202 is responsible for maintaining the routing relationships between domains, including assigning a unique identifier to each domain, establishing a mapping relationship between the domain identifier and the physical channel (i.e., the inter-domain transmission channel), and maintaining a routing table in the kernel shared memory;

[0080] The channel management sub-module 202 provides a management interface for routing information, including the transmission management sub-module 201 obtaining the corresponding transmission channel of the target domain through the query interface, the cross-domain implementation module 30 obtaining the next-hop information of the message through the query interface, and supporting dynamic update of the routing table entries;

[0081] The channel management sub-module 202 implements routing status monitoring, including detecting the channel connection status, updating the routing table when the channel is abnormal, and notifying the transmission management sub-module 201 to perform channel switching.

[0082] Further, in one embodiment, the cross-domain implementation module 30 implements endpoint management based on the virtio mechanism, including allocating virtio endpoint resources at channel creation, assigning a unique endpoint identifier to each domain, maintaining the status information of the endpoints, and releasing the endpoint resources when the channel is closed;

[0083] The cross-domain implementation module 30 implements message queue management, including creating send and receive message queues, implementing memory management of the queues, handling situations such as queue full / empty, and implementing priority-based queue scheduling;

[0084] The cross-domain implementation module 30 provides reliable transmission guarantees, including implementing flow control based on a sliding window, using sequence numbers and acknowledgment mechanisms, supporting timeout retransmission, and implementing congestion control;

[0085] The cross-domain implementation module 30 completes cross-domain message routing, including obtaining routing information from the channel management sub-module 202, selecting the next hop according to the target domain, forwarding data through the virtio endpoint, and handling exceptions during the forwarding process.

[0086] Further, in one embodiment, when the extended Binder driver module 20 detects a cross-chip call request, it forwards the cross-chip call request to the transmission management sub-module 201 for processing; the transmission management sub-module 201 is responsible for managing and scheduling the inter-chip transmission channels, including maintaining the creation and destruction of the inter-chip transmission channels, monitoring the connection status of the channels, handling channel exceptions and recovery, and implementing message distribution and forwarding; the transmission management sub-module 201 interacts with the extended Binder driver module 20 through a unified interface, and the unified interface includes a channel management interface, a message sending and receiving interface, and a channel status query and notification interface;

[0087] The channel management sub-module 202 is responsible for maintaining the routing relationships between chips, including assigning a unique identifier to each chip, establishing a mapping relationship between the chip identifier and the inter-chip transmission channel, and maintaining a routing table in the kernel shared memory;

[0088] The channel management sub-module 202 provides a management interface for routing information, including the transmission management sub-module 201 obtaining the transmission channel corresponding to the target chip through the query interface, the cross-chip implementation module 40 obtaining the next-hop information of the message through the query interface, and supporting dynamic update of the routing table entries;

[0089] The channel management sub-module 202 implements routing status monitoring, including detecting the channel connection status, updating the routing table when a channel exception occurs, and notifying the transmission management sub-module 201 to perform channel switching.

[0090] Further, in one embodiment, the cross-chip implementation module 40 provides standard interfaces, including a DMA channel management interface, a shared memory operation interface, an interrupt registration interface, and a message sending and receiving interface; the extended Binder driver module 20 completes the control and data transmission of cross-chip communication through the standard interfaces provided by the cross-chip implementation module.

[0091] Further, in one embodiment, the cross-chip implementation module 30 is used to implement DMA transmission channel management, shared memory management, an interrupt processing mechanism, and circular buffer management, where:

[0092] DMA transmission channel management includes the creation of a DMA channel, the DMA transmission process, and channel status management; the creation of a DMA channel includes: applying for DMA resources, configuring the DMA controller, initializing the DMA descriptor, and establishing a transmission channel; the DMA transmission process includes constructing a DMA descriptor chain, configuring transmission parameters, starting the DMA transmission, and waiting for the transmission to complete; channel status management includes monitoring the channel status, handling transmission errors, and implementing channel reset;

[0093] Shared memory management, including memory region mapping and memory access control; memory region mapping includes allocating continuous physical memory, establishing BAR mapping, and configuring MMU mapping; memory access control includes implementing memory barriers, handling cache coherence, and protecting shared data;

[0094] The interrupt handling mechanism includes an interrupt registration process, an interrupt handling process, and interrupt optimization. The interrupt registration process includes applying for interrupt resources, registering an interrupt handling function, and configuring an interrupt controller; the interrupt handling process includes receiving an interrupt signal, identifying the interrupt type, calling the corresponding handling function, and clearing the interrupt status; interrupt optimization includes implementing interrupt aggregation, reducing the number of interrupts, and optimizing the response latency;

[0095] Ring buffer management, including buffer initialization, data read / write operations, and memory management. Buffer initialization includes allocating buffer memory, initializing read / write pointers, and configuring buffer parameters; data read / write operations include implementing lock-free read / write, handling buffer full / empty, and ensuring data continuity; memory management includes optimizing memory usage, implementing memory reuse, and handling memory fragmentation.

[0096] Further, in one embodiment, the service-oriented architecture based on Binder is built based on Android AIDL.

[0097] In this embodiment, the method of using Android AIDL to generate the Service side and the Client side can, at the bottom layer, call the inter-domain transmission channel / chip-to-chip transmission channel according to requirements for cross-domain (inter-domain) and cross-chip (cross-chip) SOA. Of course, the inter-domain communication mechanism here is not limited to rpmsg, and the chip-to-chip communication mechanism is not limited to PCIe. Other communication methods can also be integrated according to this embodiment.

[0098] The embodiment of this application is compatible with cross-domain / chip communication methods based on the existing Android binder driver, effectively reducing the system complexity and expanding the usage scenarios of SOA; using the Android binder driver layer to extend cross-domain and cross-chip communication methods, directly leveraging the underlying inter-core / chip-to-chip communication mechanism, without relying on SOA communication frameworks such as DDS and SOME / IP, and being compatible with usage in different scenarios such as the automotive field and the IOT field.

[0099] It should be noted that the serial numbers of the embodiments of this application above are only for description and do not represent the advantages or disadvantages of the embodiments.

[0100] In the description of the specification, claims and the above-mentioned drawings of this application, the terms "comprising", "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally further include steps or units not listed, or may optionally further include other steps or units inherent to these processes, methods, products or devices. Descriptions such as "first", "second" and "third" are used to distinguish different objects, etc., and do not represent a sequence, nor do they limit that "first", "second" and "third" are different types.

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

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

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

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

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

Claims

1. A service-oriented architecture based on Binder, characterized in that: The service-oriented architecture based on Binder implementation includes a Binder core processing module, an extended Binder driver module, a cross-domain implementation module and a cross-chip implementation module, wherein: Binder core processing module, used to implement basic Binder inter-process communication functions, manage Binder reference counts and object mappings, and handle serialization and deserialization of Binder transmission data; The extended Binder driver module inherits from the Binder core processing module and extends its functions to determine whether the service call is a local call or a cross-domain / cross-chip call. Local calls are processed through the native Binder mechanism, and cross-domain / cross-chip calls are processed by the transmission management submodule; The transmission management submodule in the extended Binder driver module manages multiple transmission channels, implements the registration, destruction and status management of transmission channels, and is responsible for message routing and forwarding; The channel management submodule in the extended Binder driver module is responsible for channel management, including channel lifecycle management, channel connection status monitoring, and channel data sending and receiving processing; The cross-domain implementation module is based on the inter-domain transmission channel implemented by the inter-domain communication mechanism, provides reliable message transmission, and supports asynchronous communication mode; Cross-chip implementation module, inter-chip transmission channel based on inter-chip communication mechanism, supports high-bandwidth data transmission and realizes DMA transmission optimization; The collaborative relationship between the modules is as follows: The extended Binder driver module is responsible for intercepting and identifying cross-domain / cross-chip call requests based on the Binder core processing module interface, calling the transmission management submodule for routing and forwarding, and the transmission management submodule returns the processing results to the extended Binder driver module, and the extended Binder driver module returns the results to the application layer; The transmission management submodule maintains the global routing strategy, calls the channel management submodule to perform specific channel operations, the channel management submodule registers channel information with the transmission management submodule, and notifies the transmission management submodule of channel status changes; The channel management submodule manages specific transmission channel instances, calls the cross-domain implementation module / cross-chip implementation module to implement data transmission, and the cross-domain implementation module / cross-chip implementation module notifies the channel management submodule of the arrival of the message through callback, and the channel management submodule delivers the message to the upper layer for processing.

2. The service-oriented architecture based on Binder as claimed in claim 1, characterized in that: The extended Binder driver module inherits from the Binder core processing module and extends its functions, specifically including: Inherit the basic inter-process communication mechanism and interface of the Binder core processing module; Maintain compatibility with native Binder; Achieve cross-domain / cross-chip communication capabilities through transmission management submodule and channel management submodule expansion; Added transmission channel management function.

3. According to the service-oriented architecture based on Binder implementation according to claim 1, it is characterized in that: The direction of the downlink data flow is: application layer to Binder core processing module, Binder core processing module to extended Binder driver module, extended Binder driver module to transmission management submodule, transmission management submodule to channel management submodule, channel management submodule to cross-domain implementation module / cross-chip implementation module; The direction of the upstream data flow is: cross-domain implementation module / cross-chip implementation module to the channel management submodule, the channel management submodule to the transmission management submodule, the transmission management submodule to the extended Binder driver module, the extended Binder driver module to the Binder core processing module, and the Binder core processing module to the application layer.

4. The service-oriented architecture based on Binder as claimed in claim 1, characterized in that: When the extended Binder driver module detects a cross-domain call request, it transfers the cross-domain call request to the transmission management submodule for processing; the transmission management submodule is responsible for managing and scheduling inter-domain transmission channels, including maintaining the creation and destruction of inter-domain channels, monitoring the connection status of channels, handling channel exceptions and recovery, and implementing message distribution and forwarding; the transmission management submodule interacts with the extended Binder driver module through a unified interface, which includes a channel management interface, a message sending and receiving interface, and a channel status query and notification interface; The channel management submodule is responsible for maintaining the routing relationship between domains, including assigning a unique identifier to each domain, establishing a mapping relationship between the domain identifier and the physical channel, and maintaining the routing table in the kernel shared memory; The channel management submodule provides a management interface for routing information, including a transmission management submodule that obtains the transmission channel corresponding to the target domain through a query interface, a cross-domain implementation module that obtains the next hop information of the message through a query interface, and supports dynamic update of routing table entries; The channel management submodule implements routing status monitoring, including detecting channel connection status, updating the routing table when the channel is abnormal, and notifying the transmission management submodule to switch channels.

5. The service-oriented architecture based on Binder as claimed in claim 4, characterized in that: The cross-domain implementation module implements endpoint management based on the virtio mechanism, including allocating virtio endpoint resources when a channel is created, assigning a unique endpoint identifier to each domain, maintaining endpoint status information, and releasing endpoint resources when a channel is closed; The cross-domain implementation module implements message queue management, including creating send and receive message queues, implementing queue memory management, handling queue full / empty situations, and implementing priority-based queue scheduling; The cross-domain implementation module provides reliable transmission guarantee, including implementing flow control based on sliding windows, using sequence numbers and confirmation mechanisms, supporting timeout retransmission, and implementing congestion control; The cross-domain implementation module completes cross-domain message routing, including obtaining routing information from the channel management submodule, selecting the next hop according to the target domain, forwarding data through the virtio endpoint, and handling exceptions during the forwarding process.

6. The service-oriented architecture based on Binder as claimed in claim 1, characterized in that: When the extended Binder driver module detects a cross-chip call request, it transfers the cross-chip call request to the transmission management submodule for processing; the transmission management submodule is responsible for managing and scheduling the inter-chip transmission channel, including maintaining the creation and destruction of the inter-chip transmission channel, monitoring the connection status of the channel, handling channel exceptions and recovery, and implementing message distribution and forwarding; the transmission management submodule interacts with the extended Binder driver module through a unified interface, which includes a channel management interface, a message sending and receiving interface, and a channel status query and notification interface; The channel management submodule is responsible for maintaining the routing relationship between chips, including assigning a unique identifier to each chip, establishing a mapping relationship between the chip identifier and the transmission channel between chips, and maintaining the routing table in the kernel shared memory; The channel management submodule provides a management interface for routing information, including a transmission management submodule that obtains the transmission channel corresponding to the target chip through a query interface, a cross-chip implementation module that obtains the next hop information of the message through a query interface, and supports dynamic update of routing table items; The channel management submodule implements routing status monitoring, including detecting channel connection status, updating the routing table when the channel is abnormal, and notifying the transmission management submodule to switch channels.

7. The service-oriented architecture based on Binder as claimed in claim 6, characterized in that: The cross-chip implementation module provides standard interfaces, including DMA channel management interface, shared memory operation interface, interrupt registration interface and message sending and receiving interface; the extended Binder driver module completes the control and data transmission of cross-chip communication through the standard interface provided by the cross-chip implementation module.

8. The service-oriented architecture based on Binder as claimed in claim 7, characterized in that: The cross-chip implementation module is used to implement DMA transmission channel management, shared memory management, interrupt processing mechanism and ring buffer management, including: DMA transmission channel management, including DMA channel creation, DMA transmission process and channel status management; DMA channel creation includes: applying for DMA resources, configuring DMA controller, initializing DMA descriptors and establishing transmission channels; DMA transmission process includes constructing DMA descriptor chain, configuring transmission parameters, starting DMA transmission and waiting for transmission completion; channel status management includes monitoring channel status, handling transmission errors and implementing channel reset; Shared memory management, including memory region mapping and memory access control; memory region mapping includes allocating continuous physical memory, establishing BAR mapping, and configuring MMU mapping; memory access control includes implementing memory barriers, handling cache consistency, and protecting shared data; The interrupt handling mechanism includes interrupt registration process, interrupt handling process and interrupt optimization. The interrupt registration process includes applying for interrupt resources, registering interrupt handling functions and configuring interrupt controllers. The interrupt handling process includes receiving interrupt signals, identifying interrupt types, calling corresponding handling functions and clearing interrupt status. Interrupt optimization includes realizing interrupt aggregation, reducing the number of interrupts and optimizing response delays. Ring buffer management includes buffer initialization, data read and write operations, and memory management. Buffer initialization includes allocating buffer memory, initializing read and write pointers, and configuring buffer parameters; data read and write operations include implementing lock-free reading and writing, handling buffer full / empty, and ensuring data continuity; memory management includes optimizing memory usage, implementing memory reuse, and handling memory fragmentation.

9. The service-oriented architecture based on Binder as claimed in any one of claims 1 to 8, characterized in that: The service-oriented architecture based on Binder implementation is built on Android AIDL.

Images