Cross-device-level communication adaptation method, system and chip

Abstract

The invention discloses a cross-device-level communication adaptation method, system and chip, the cross-device-level communication adaptation method is applied to a high-level device, and the cross-device-level communication adaptation method comprises the following steps: starting a lightweight SDK (Software Development Kit) on a low-level device, registering a service instance through the lightweight SDK, and sending the service instance to the low-level device; obtaining a service instance agent of the low-level equipment through a soft bus; initiating a service calling request to the low-level equipment according to the service instance proxy; and after the low-level equipment obtains an execution result according to the service calling request, receiving the execution result sent by the low-level equipment through a soft bus. According to the invention, low-delay, high-compatibility and low-overhead communication between low-level equipment and high-level equipment can be realized, a developer does not need to manually process protocol conversion and resource optimization, and the cross-equipment communication efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a cross-device-level communication adaptation method, system, and chip. Background Technology

[0002] In related technologies, L2 devices (such as smartphones and tablets) can directly communicate using the soft bus SDK, but L0 devices (such as low-resource sensors) require protocol conversion to connect. The drawbacks of these technologies include: protocol fragmentation (L0 devices natively only support CoAP / UDP lightweight protocols, while L2 devices need to use the soft bus for communication, requiring developers to manually develop and convert communication protocols for L0); high resource overhead (the standard soft bus SDK uses ≥2MB of memory, making it unsuitable for some low-resource and low-power L0 sensor devices); and low development efficiency (currently, cross-level communication requires writing separate device-side code (e.g., C for L0, JS for L2), resulting in a code reuse rate of <30%). Therefore, the soft bus is designed for resource-rich L2 devices and cannot efficiently adapt to L0 devices, leading to inefficient cross-level communication.

[0003] Therefore, existing technologies still need to be improved and developed. Summary of the Invention

[0004] The main objective of this invention is to provide a cross-device-level communication adaptation method, system, and chip, aiming to solve the problem that cross-device communication efficiency is low because developers need to manually develop and convert communication for L0 devices in the prior art.

[0005] To achieve the above objectives, the present invention provides a cross-device-level communication adaptation method, applicable to high-level devices, the cross-device-level communication adaptation method comprising the following steps: After starting the lightweight SDK on the low-level device and registering the service instance through the lightweight SDK, the service instance proxy of the low-level device is obtained through the soft bus. The service instance proxy initiates a service call request to the lower-level device; After the lower-level device obtains the execution result according to the service call request, it receives the execution result sent by the lower-level device through the soft bus.

[0006] Optionally, in the cross-device-level communication adaptation method, obtaining the service instance proxy of the lower-level device specifically includes: The high-level device is queried for the required services via the soft bus. When the service instance of the low-level device meets the service provision requirements, a service instance proxy corresponding to the service instance is created.

[0007] Optionally, the cross-device-level communication adaptation method, wherein initiating a service call request to the lower-level device based on the service instance proxy specifically includes: The request to invoke the service instance proxy is encoded to obtain request data; The request data is transmitted to the lightweight SDK of the lower-level device via a soft bus, thus completing the service call request initiated by the higher-level device to the lower-level device.

[0008] Optionally, in the cross-device-level communication adaptation method, the execution result is decoded data; The step of receiving the execution results sent by the lower-level device via the soft bus specifically includes: Receive response-encoded data sent by the lower-level device via the soft bus; After successfully verifying the response encoded data using the public key, the response encoded data is decoded to obtain the decoded data.

[0009] Furthermore, to achieve the above objectives, the present invention also provides a cross-device-level communication adaptation method, applied to low-level devices, wherein the cross-device-level communication adaptation method includes: Start the lightweight SDK and register a service instance through the lightweight SDK; Receive service call requests initiated by high-level devices; The service required by the high-level device is executed according to the service call request, the execution result is obtained, and the execution result is sent to the high-level device via the soft bus.

[0010] Optionally, the cross-device-level communication adaptation method, wherein registering a service instance through the lightweight SDK specifically includes: Obtain the equipment information and service information of the lower-level equipment; The device information and service information are registered on the soft bus using the lightweight SDK, forming a service instance of the low-level device.

[0011] Optionally, in the cross-device-level communication adaptation method, the lightweight SDK has a circular buffer, and the service call request is request data; The specific steps for receiving service call requests initiated by high-level devices are as follows: After a higher-level device initiates a service call request to a lower-level device, the request data is read from the circular buffer using zero-copy.

[0012] Optionally, the cross-device-level communication adaptation method, wherein executing the service required by the higher-level device according to the service call request and obtaining the execution result specifically includes: Identify the service identifier corresponding to the request data, and determine the actual processing function of the low-level device based on the service identifier; The actual processing function is executed, and the execution result is obtained.

[0013] Furthermore, to achieve the above objectives, the present invention also provides a cross-device-level communication adaptation device, wherein the cross-device-level communication adaptation device includes: The service instance proxy acquisition module is used to start the lightweight SDK on the low-level device, and after registering the service instance through the lightweight SDK, obtain the service instance proxy of the low-level device through the soft bus. The call request module is used to initiate a service call request to the low-level device based on the service instance proxy. The service invocation module is used to receive the execution result sent by the low-level device via the soft bus after the low-level device obtains the execution result according to the service invocation request.

[0014] Furthermore, to achieve the above objectives, the present invention also provides a cross-device-level communication adaptation device, wherein the cross-device-level communication adaptation device includes: The service instance registration module is used to start the lightweight SDK and register service instances through the lightweight SDK; The request receiving module is used to receive service call requests initiated by high-level devices; The execution module is used to execute the services required by the high-level device according to the service call request, obtain the execution result, and send the execution result to the high-level device through the soft bus.

[0015] In addition, to achieve the above objectives, the present invention also provides a cross-device-level communication adaptation system, wherein the cross-device-level communication adaptation system includes low-level devices and high-level devices; The high-level device is used to implement the steps of the cross-device-level communication adaptation method as described in any of the above schemes; The lower-level device is used to implement the steps of the cross-device-level communication adaptation method as described in any of the above schemes.

[0016] Furthermore, to achieve the above objectives, the present invention also provides a chip, wherein the chip includes: a memory, a processor, and a cross-device-level communication adapter program stored on the memory and executable on the processor, wherein when the cross-device-level communication adapter program is executed by the processor, it implements the steps of the cross-device-level communication adapter method as described in any of the above solutions, or implements the steps of the cross-device-level communication adapter method as described in any of the above solutions.

[0017] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a cross-device-level communication adaptation program, which, when executed by a processor, implements the steps of the cross-device-level communication adaptation method as described in any of the above embodiments.

[0018] Beneficial effects: This application provides a cross-device-level communication adaptation method, system, and chip. By implementing a simplified SDK on L0 devices (lower-level devices), this application reduces memory usage and optimizes performance through zero-copy buffering and a unified calling interface. Specifically, it uses a circular buffer of the L0 device to directly map physical addresses, reducing data copy overhead. When L2 devices (higher-level devices) call L0 capabilities, they use standardized APIs. Regardless of the L0 device type, this application can achieve low-latency, high-compatibility, and low-overhead communication between L0 and L2 devices, eliminating the need for developers to manually handle protocol conversion and resource optimization. This application improves cross-device communication efficiency. Attached Figure Description

[0019] Figure 1 A flowchart illustrating a preferred embodiment of the cross-device-level communication adaptation method of the first embodiment of this application; Figure 2 This is a schematic diagram of lightweight distributed soft bus communication in a preferred embodiment of the cross-device-level communication adaptation method of this application; Figure 3 A flowchart illustrating a preferred embodiment of the cross-device-level communication adaptation method of the second embodiment of this application; Figure 4 This is a structural diagram of a preferred embodiment of the chip in this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and effects of this application clearer and more explicit, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. The described embodiments are only possible technical implementations of this application and not all possible implementations. Based on the embodiments in this application, those skilled in the art can obtain other embodiments without creative effort, and these embodiments are also within the protection scope of this application.

[0021] First, let's introduce the terms used in the embodiments of this application: OpenHarmony, the name of the open-source HarmonyOS (a distributed operating system project). SDK, Software Development Kit. L0, Level 0 (refers to low-level equipment with limited resources); L1, Level 1 (Intermediate Level Equipment); L2, Level 2 (High-level equipment with abundant resources); CoAP, Constrained Application Protocol (IoT Lightweight Communication Protocol). UDP, User Datagram Protocol (a connectionless transport layer protocol). JS, JavaScript (a scripting programming language).

[0022] This application belongs to the field of OpenHarmony soft bus communication technology, specifically relating to a cross-device level (L0 / L1 / L2) communication adaptation method based on the OpenHarmony distributed system, which is particularly suitable for low-latency and high-compatibility data interaction between resource-constrained L0 devices and resource-rich L2 devices.

[0023] In related technologies, L0 devices natively support lightweight protocols, while L2 devices use soft bus protocols. Cross-level communication requires developers to manually perform protocol conversion and business logic adaptation, increasing development complexity. The standard soft bus SDK consumes ≥2MB of memory, which is excessively high for L0 devices (such as low-power sensors, which typically have only hundreds of KB of memory), rendering them unusable. Cross-level communication requires writing separate code for L0 devices (commonly C) and L2 devices (commonly JS / Java), resulting in a code reuse rate of less than 30% and making debugging difficult.

[0024] To address the issue of low cross-device communication efficiency caused by developers manually developing and converting communication protocols for L0 devices, this application implements a simplified SDK on L0 devices (lower-level devices), reducing memory usage and optimizing performance through zero-copy buffering and a unified calling interface. Specifically, the L0 device's circular buffer directly maps to the physical address, reducing data copy overhead. When L2 devices (higher-level devices) call L0 capabilities, a standardized API is used. Regardless of the L0 device type, this application achieves low-latency, high-compatibility, and low-overhead communication between L0 and L2 devices, eliminating the need for developers to manually handle protocol conversion and resource optimization. This application significantly improves cross-device communication efficiency. The advantages of this application are as follows: low latency (end-to-end communication latency is less than 10ms, meeting real-time interaction requirements (such as industrial control); high compatibility (unified interface supports all L0 device types, improving code reusability); low resource overhead (minimal SDK memory usage and reduced CPU usage, extending L0 device battery life); improved development efficiency (developers use the same API to write code, reducing adaptation workload); and security and reliability (lightweight authentication maintains security while reducing computational burden).

[0025] The technical solutions of this application will be described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0026] First embodiment: Specifically, Figure 1 This is a flowchart illustrating a cross-device-level communication adaptation method provided in an embodiment of this application.

[0027] like Figure 1 As shown, this cross-device-level communication adaptation method is applied to high-level devices, and includes the following steps: In step S101, after starting the lightweight SDK on the low-level device and registering a service instance through the lightweight SDK, the service instance proxy of the low-level device is obtained through the soft bus.

[0028] It should be noted that, as Figure 2 As shown, a lightweight distributed soft bus communication SDK is implemented on the L0 side, which registers an interface with the L0 device service instance. After the service instance registration is completed, the L2 device first obtains the L0 service instance proxy, and then initiates capability calls to the L0 device through the service instance proxy. In this application, zero-copy buffering is used, and a circular buffer is used to directly map the physical address, reducing the memory copy overhead of the L0 device; a unified calling interface is used, so when the L2 device calls the L0 capability, regardless of which L0 device it is, the capability call can be performed in a unified way; it can also call the capabilities of peer L2 devices; and code reusability is improved.

[0029] This application adopts a device virtualization mapping mechanism to abstract L0 devices into virtual sub-devices of L2 nodes, and identifies the devices by deviceId (device identifier, i.e., device ID); L2 devices directly call L0 services through virtual IDs without needing to perceive the differences in physical devices; 3. Simplified security authentication; a lightweight authentication method is adopted, which uses a pre-set asymmetric key pair, and the private key is burned into the secure storage area of ​​the L0 device.

[0030] In one possible implementation, the services required by the high-level device are queried via a soft bus; when the service instance of the low-level device meets the service provision requirements, a service instance proxy corresponding to the service instance is created.

[0031] Understandably, the role of L2 devices in the entire communication process is that of a scheduler, and their workflow is proactive and initiating.

[0032] Specifically, when an L2 device launches its application or business logic, and the business requires a certain capability, the L2 device doesn't directly know which L0 device can provide that service. Instead, it queries the entire network for the required service via the distributed soft bus (e.g., querying all instances providing temperature data services). During the service instance proxy acquisition process, the soft bus network responds to the L2's query, returning a list of all L0 service instances that can provide the service, along with their information (including their deviceId and communication channel information). The L2 device's SDK creates a service instance proxy for each discovered L0 service instance. It's important to note that this service instance proxy is a local object (in L2's memory), and its interface is completely identical to the actual capabilities provided by the L0 device. However, the L2's business code is completely unaware of which specific physical device is behind this proxy.

[0033] In step S102, a service call request is initiated to the low-level device according to the service instance proxy.

[0034] In one possible implementation, the request to invoke the service instance proxy is encoded to obtain request data; the request data is then transmitted via a soft bus to the lightweight SDK of the low-level device to complete the service call request initiated by the high-level device to the low-level device.

[0035] Understandably, during the unified interface call process of L2 devices, the business logic code of L2 calls the service instance proxy method just like calling a local method. This is the embodiment of the unified interface call: regardless of whether the underlying L0 device is a temperature and humidity sensor from manufacturer A or a PLC from manufacturer B, the calling method of L2 is exactly the same, which greatly reduces the development complexity of upper-layer applications.

[0036] Specifically, after receiving this call request, the L2 SDK is responsible for encoding the call information (method name, parameters, etc.). The encoded data is then efficiently written to a circular buffer shared with the target L0 device using a zero-copy buffering mechanism. The underlying soft bus mechanism is responsible for routing this data to the correct L0 device.

[0037] It's important to note that L0 and L2 devices use two different forms or configurations of the same "distributed soft bus communication SDK," rather than two completely independent and unrelated SDKs. The SDK on the L0 device is lightweight, specifically manifested in zero-copy buffering, directly reducing memory operations; and using pre-defined keys instead of complex dynamic negotiation, significantly reducing the computational burden on the L0 device. The L2 device, on the other hand, is resource-rich and typically plays the role of coordinator, control center, or super terminal in distributed systems. The SDK on the L2 device is full-featured; it can be understood as a communication scheduling center. It is responsible for discovering all devices, creating service proxies for each device, and providing a unified API for upper-layer applications to call. When an application calls the proxy, the SDK is responsible for finding the actual device and communicating using a lightweight protocol it understands.

[0038] In step S103, after the low-level device obtains the execution result according to the service call request, it receives the execution result sent by the low-level device through the soft bus.

[0039] In one possible implementation, the execution result is decoded data. The system receives response encoded data sent by the lower-level device via a soft bus; after successfully verifying the response encoded data using a public key, it decodes the response encoded data to obtain decoded data.

[0040] Specifically, the L2 device enters a waiting state, listening for responses from the L0 device. Once the L0 device completes its task and returns a result, the response data is transmitted back to the L2 SDK via the soft bus. The SDK reads the response data from the circular buffer with zero copy, decodes it, and converts it into a format that the L2 business logic can understand. The SDK then returns the decoded result to the L2 business logic code, thus completing a full call-response process.

[0041] When an L2 device receives registration information or response data from an L0 device, it uses a pre-configured public key to verify the L0 device's digital signature. Only verified L0 devices and their data are trusted and processed by the L2. This ensures that the L2 does not communicate with counterfeit or tampered devices.

[0042] Second embodiment: Specifically, Figure 3This is a flowchart illustrating a cross-device-level communication adaptation method provided in an embodiment of this application.

[0043] like Figure 3 As shown, this cross-device-level communication adaptation method is applied to low-level devices, and the cross-device-level communication adaptation method includes: In step S201, the lightweight SDK is started, and a service instance is registered through the lightweight SDK.

[0044] It should be noted that the role of the L0 device in the entire communication process is that of a service provider. Its work mainly focuses on the stages of startup, registration, waiting for calls, execution, and return.

[0045] In one possible implementation, the device information and service information of the low-level device are obtained; the device information and service information are registered on the soft bus through the lightweight SDK to form a service instance of the low-level device.

[0046] Specifically, upon powering on the L0 device, the application on the device initializes and starts the lightweight distributed soft bus communication SDK. The SDK utilizes a zero-copy buffering mechanism to create and initialize a circular buffer in the L0 device's memory. This buffer is used for efficient data transmission and reception, avoiding multiple memory copies. During service instance registration, the L0 device registers its capabilities (services) with the local L0 device service instance registry through the SDK. This registration process includes key information: service identifier (a unique ID indicating the service); interface description (describing the methods / functions provided by the service); communication channel information (a pointer or handle to the previously created circular buffer for subsequent data transmission); and device ID (deviceId), the unique identifier of the L0 device.

[0047] In step S202, a service call request initiated by a higher-level device is received.

[0048] In one possible implementation, the lightweight SDK has a circular buffer, and the service call request is request data. After a higher-level device initiates a service call request to the lower-level device, the request data is read from the circular buffer using zero-copy.

[0049] Specifically, the SDK of the L0 device enters a listening state, using the soft bus mechanism to detect whether other devices (mainly L2 devices) are querying services in the network. This process is transparent to the L0 device itself and is automatically completed by the SDK and the underlying soft bus. When an L2 device (through its agent) initiates a capability call, the request reaches the SDK of the L0 device through the soft bus. The SDK reads the request data from the circular buffer with zero copy. Because the buffer is a mapped physical address, the data does not need to be copied between kernel space and user space, greatly improving efficiency.

[0050] In step S203, the service required by the high-level device is executed according to the service call request, the execution result is obtained, and the execution result is sent to the high-level device through the soft bus.

[0051] In one possible implementation, the service identifier corresponding to the request data is identified, and the actual processing function of the low-level device is determined based on the service identifier; the actual processing function is executed to obtain the execution result.

[0052] Specifically, the SDK parses the request, identifies the service ID and method to be called, and finds the corresponding local processing function on the L0 device based on the registration information. Then, it executes this local function. This is the core step where the L0 device acts as the execution entity, utilizing its local hardware capabilities (sensors, actuators, etc.) to complete the task. After the local function finishes execution, it returns the result (e.g., temperature value 25.6) to the SDK. The SDK writes the result data to a circular buffer with zero copy as a response. The soft bus mechanism then transmits the response data back to the L2 device that initiated the request.

[0053] Throughout the entire communication process (especially during the registration and invocation phases), the security mechanism remains online. The L0 device uses a pre-set private key to sign important communication data (such as registration information and sensitive control commands). The L2 device holds the corresponding public key, which can verify the validity of the signature and ensure that the request does indeed come from the claimed L0 device and has not been tampered with. This process is imperceptible to the business logic of the L0 device and is usually completed automatically by the SDK at the underlying level, hence the name lightweight authentication.

[0054] The specific implementation of this application will be described below with reference to a specific application scenario.

[0055] Phase 1: Preparation and Registration (Interaction between L0 devices and the soft bus): L0 device power-on and SDK initialization: The L0 device starts up, and the lightweight SDK on it begins to work.

[0056] The SDK uses a pre-configured private key to identify itself to the soft bus network.

[0057] Service instance registration: L0 devices register their capabilities (services) and device information (deviceid) with the distributed soft bus via the SDK.

[0058] The role of the soft bus is to receive, store, and manage information about these service instances, forming a service registry, which is like an address book that records who (deviceid) can do what (service interface).

[0059] Phase Two: Discovery and Agent Acquisition (Interaction between L2 Devices and the Soft Bus): L2 device service triggering: An application on an L2 device needs a capability (e.g., reading temperature).

[0060] Service Query and Discovery: L2 devices initiate service query requests to the distributed soft bus through their SDK.

[0061] The role of the soft bus: to query its own service registry and return a list of matching L0 service instances (including deviceid and communication information) to the L2 device.

[0062] Create a service instance proxy: The SDK for L2 devices creates a local proxy object for each L0 service instance based on information obtained from the soft bus.

[0063] Key point: This proxy object is generated by the L2-side SDK and implements the exact same interface as the L0 service. At this point, the L2 business code interacts with this local proxy and is completely unaware of the existence of the remote L0 device.

[0064] Phase Three: Invocation and Execution (Interaction between L2, Soft Bus, and L0): L2 initiates a unified call: L2's business logic calls the proxy object's interface just like calling a local method.

[0065] Softbus routing and communication: The L2 SDK receives the call request and encodes it.

[0066] The zero-copy buffering mechanism efficiently sends the requested data to the distributed soft bus.

[0067] The role of the soft bus: Routing: Based on the target deviceid in the request, find the correct L0 device in the vast network.

[0068] Transmission: The SDK responsible for reliably delivering the requested data to the target IoT device.

[0069] L0 device execution and response: When the SDK of an L0 device receives a request from the soft bus, it is decoded and found to be calling a specific local capability.

[0070] The L0 device performs this capability (such as reading data from a sensor) and returns the result to its SDK.

[0071] The L0 SDK encodes the results and sends them back to the L2 device via the soft bus.

[0072] This application provides a cross-device-level communication adaptation system, wherein the cross-device-level communication adaptation system includes low-level devices and high-level devices; The high-level device is used to implement the steps of the cross-device-level communication adaptation method as described in any of the first embodiments above; The lower-level device is used to implement the steps of the cross-device-level communication adaptation method as described in any of the second embodiments above.

[0073] Figure 4 This is a schematic diagram of the chip structure provided in an embodiment of this application. The chip includes: a memory, a processor, and a cross-device-level communication adapter program stored in the memory and executable on the processor. When executed by the processor, the cross-device-level communication adapter program implements the steps of the cross-device-level communication adapter method as described in any of the first embodiments above, or implements the steps of the cross-device-level communication adapter method as described in any of the first embodiments above.

[0074] The chip may include: The memory 501, the processor 502, and the computer program stored on the memory 501 and capable of running on the processor 502.

[0075] When the processor 502 executes the program, it implements the cross-device-level communication adaptation method provided in the above embodiments.

[0076] Furthermore, the terminal also includes: Communication interface 503 is used for communication between memory 501 and processor 502.

[0077] The memory 501 is used to store computer programs that can run on the processor 502.

[0078] Memory 501 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0079] If the memory 501, processor 502, and communication interface 503 are implemented independently, then the communication interface 503, memory 501, and processor 502 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EIS) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 4 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0080] Optionally, in a specific implementation, if the memory 501, processor 502, and communication interface 503 are integrated on a single chip, then the memory 501, processor 502, and communication interface 503 can communicate with each other through an internal interface.

[0081] Processor 502 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0082] This embodiment also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described cross-device-level communication adaptation method.

[0083] One embodiment of this application provides a computer program product, including a computer program that, when executed by a processor, implements the features described in this application. Figure 1 or Figure 3 The corresponding embodiments provide cross-device-level communication adaptation methods.

[0084] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," 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 this application. In this specification, the 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. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0085] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0086] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application 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 should be understood by those skilled in the art to which embodiments of this application pertain.

[0087] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable storage medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable storage medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable storage medium could be paper or other suitable media on which the program can be printed, since the program can be obtained electronically by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0088] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0089] 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.

[0090] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0091] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

[0092] It should be understood that the application of this application is not limited to the examples above. Those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

[0093] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A cross-device-level communication adaptation method, characterized in that, For high-level devices, the cross-device-level communication adaptation method includes: After starting the lightweight SDK on the low-level device and registering the service instance through the lightweight SDK, the service instance proxy of the low-level device is obtained through the soft bus. The service instance proxy initiates a service call request to the lower-level device; After the lower-level device obtains the execution result according to the service call request, it receives the execution result sent by the lower-level device through the soft bus.

2. The cross-device-level communication adaptation method according to claim 1, characterized in that, The process of obtaining the service instance proxy for the low-level device specifically includes: The high-level device is queried for the required services via the soft bus. When the service instance of the low-level device meets the service provision requirements, a service instance proxy corresponding to the service instance is created.

3. The cross-device-level communication adaptation method according to claim 2, characterized in that, The step of initiating a service call request to the lower-level device based on the service instance proxy specifically includes: The request to invoke the service instance proxy is encoded to obtain request data; The request data is transmitted to the lightweight SDK of the lower-level device via a soft bus, thus completing the service call request initiated by the higher-level device to the lower-level device.

4. The cross-device-level communication adaptation method according to claim 3, characterized in that, The execution result is decoded data; The step of receiving the execution results sent by the lower-level device via the soft bus specifically includes: Receive response-encoded data sent by the lower-level device via the soft bus; After successfully verifying the response encoded data using the public key, the response encoded data is decoded to obtain the decoded data.

5. A cross-device-level communication adaptation method, characterized in that, For use with lower-level devices, the cross-device-level communication adaptation method includes: Start the lightweight SDK and register a service instance through the lightweight SDK; Receive service call requests initiated by high-level devices; The service required by the high-level device is executed according to the service call request, the execution result is obtained, and the execution result is sent to the high-level device via the soft bus.

6. The cross-device-level communication adaptation method according to claim 5, characterized in that, The process of registering a service instance through the lightweight SDK specifically includes: Obtain the equipment information and service information of the lower-level equipment; The device information and service information are registered on the soft bus using the lightweight SDK, forming a service instance of the low-level device.

7. The cross-device-level communication adaptation method according to claim 6, characterized in that, The lightweight SDK has a circular buffer, and the service call request is request data. The specific steps for receiving service call requests initiated by high-level devices are as follows: After a higher-level device initiates a service call request to a lower-level device, the request data is read from the circular buffer using zero-copy.

8. The cross-device-level communication adaptation method according to claim 7, characterized in that, The step of executing the service required by the high-level device according to the service call request and obtaining the execution result specifically includes: Identify the service identifier corresponding to the request data, and determine the actual processing function of the low-level device based on the service identifier; The actual processing function is executed, and the execution result is obtained.

9. A cross-device-level communication adaptation system, characterized in that, The cross-device-level communication adaptation system includes low-level devices and high-level devices; The higher-level device is used to implement the steps of the cross-device-level communication adaptation method as described in any one of claims 1-4; The lower-level device is used to implement the steps of the cross-device-level communication adaptation method as described in any one of claims 5-8.

10. A chip, characterized in that, The chip includes: a memory, a processor, and a cross-device level communication adapter program stored in the memory and executable on the processor. When executed by the processor, the cross-device level communication adapter program implements the steps of the cross-device level communication adapter method as described in any one of claims 1-4, or implements the steps of the cross-device level communication adapter method as described in any one of claims 5-8.

Images