Multi-application scene Internet of Things test box based on swan gap system

Abstract

The invention discloses a multi-application scene Internet of Things test box based on a swan gap system, and the box comprises a swan gap operation system module which is used for providing IPC communication between processes; the client process module is used for sending a data reading request to the near-end server; the near-end server module is used for collecting sensor data after receiving the data reading request, performing JSON coding on the sensor data, generating JSON format coded data, synchronizing the JSON format coded data to the client process module for display through IPC communication, and uploading the JSON format coded data to the far-end server module for storage through an Internet of Things protocol; and the far-end server module is used for storing data from different sensors in different application scenes. According to the invention, Internet of Things simulation under different application scenes, different Internet of Things protocols and different sensors can be flexibly supported.

Description

Technical Field

[0001] The present invention relates to the technical field of Internet of Things, and specifically, to a multi-application scenario Internet of Things test box, a data processing method, an electronic device and a storable medium based on the Hongmeng system. Background Art

[0002] With the improvement of chip computing power and network bandwidth, technologies such as digital twins and big data processing have been further developed. The Internet of Things technology based on "end", "edge" and "cloud" can provide data acquisition and remote control support for digital twins and big data processing, while also improving the efficiency of industrial management and control. Therefore, the Internet of Things technology based on "end", "edge" and "cloud" has attracted the attention of more and more scientific researchers and industry practitioners.

[0003] However, many students and even researchers often do not have the opportunity to directly contact the actual industrial production site. In addition, it is not easy to verify directly online during the solution design and demo verification stage. Therefore, a simulation experiment box that can include multiple scenarios, support different sensors, and support multiple physical network communication protocols can solve the needs of early verification and teaching experiments for students or researchers. From a functional perspective, the simulation test box needs to solve the following technical problems:

[0004] The "edge" can provide a flexible set of software and hardware implementations to support communications with different IoT protocols: the hardware can provide a rich set of interfaces to support control of different devices in different scenarios; the software also needs to be compatible with the unified processing, real-time display, and uploading of data from different IoT protocols to the "cloud" server.

[0005] In the prior art, for example, patent applications with application numbers CN201910488895.0 and CN202010979025.6 both disclose an IoT experiment box, but they simply support data transmission of different IoT protocols and the collection of different sensor information, mechanically providing the function of data collection, and do not perform a higher-level scenario simulation of sensor information in combination with actual application scenarios. They do not provide experimental simulation support for different modal data collection and application in different IoT application scenarios, resulting in a lack of profound application scenario experience in the use process of the experiment box. Summary of the invention

[0006] One of the purposes of the embodiments of the present invention is to provide a multi-application scenario Internet of Things test box, data processing method, electronic device and storable medium based on the Hongmeng system, which can flexibly support Internet of Things simulation under different application scenarios, different Internet of Things protocols and different sensors.

[0007] In order to solve the above technical problems, in a first aspect, an embodiment of the present invention provides a multi-application scenario IoT test box based on the Hongmeng system, and the test box includes:

[0008] Hongmeng operating system module, used to provide IPC communication between processes;

[0009] The client process module is used to send a data read request to the near-end server;

[0010] The near-end server process module is used to collect sensor data after receiving the data reading request, and perform JSON encoding on the sensor data to generate JSON format encoded data, synchronize the JSON format encoded data to the client process module for display through IPC communication, and upload it to the remote server module for storage through the Internet of Things protocol;

[0011] The remote server module is used to store data from different sensors in different application scenarios.

[0012] Preferably, the Hongmeng operating system module includes:

[0013] The system capability manager is used to receive the registration of the Binder service based on IPC communication by the proximal server process module, so that the client process module can obtain the Binder service by requesting and thus communicate between processes;

[0014] The system call interface is used to provide a data interface for devices based on the Internet of Things protocol. The remote server process obtains device data through the system call interface. The device includes sensors in various application scenarios.

[0015] Preferably, the proximal server process module includes:

[0016] A data acquisition unit, used to collect data from sensors in different application scenarios through a system call interface;

[0017] An encoding unit, used to perform JSON encoding on the collected data to generate JSON format encoded data, wherein the JSON format encoded data enables the application to distinguish different application scenarios and sensor sources corresponding to the data;

[0018] The first IPC communication unit is used to transmit the JSON format encoded data to the client process through the Binder service; so that the JS interface front-end program on the client process can obtain the sensor data through the CPP interface;

[0019] The data uploading unit is used to synchronize the JSON format encoded data to the remote server in real time.

[0020] Preferably, the client process module specifically includes:

[0021] A data request unit, used to send a data read request to the proximal server process module;

[0022] A second IPC communication unit, used to obtain the JSON format encoded data through a Binder service;

[0023] The JS interface front end is used to call the sensor CPP program interface through the JS engine to obtain sensor data, and display the sensor data in real time through the UI interface. The CPP program interface accesses the JS engine through the interface of the NAPI framework to obtain the JS running context and return the result.

[0024] In a second aspect, in order to solve the technical problem, the embodiment of the present invention further provides a data processing method for a multi-application scenario IoT test box based on the Hongmeng system, the method comprising:

[0025] The client process module sends a data read request to the proximal server;

[0026] After receiving the data reading request, the near-end server process module collects the sensor data, and performs JSON encoding on the sensor data to generate JSON format encoded data;

[0027] Synchronize the JSON format encoded data to the client process module for display through IPC communication;

[0028] The near-end server process module synchronously uploads the JSON format encoded data to the remote server module for storage through the Internet of Things protocol.

[0029] Furthermore, the method further comprises:

[0030] The Hongmeng operating system module receives the registration of the Binder service based on IPC communication from the proximal server process module, so that the client process module obtains the Binder service by requesting and thus communicates between processes.

[0031] Preferably, the proximal server process module collects sensor data specifically including:

[0032] Data is collected from sensors in different application scenarios through the system call interface of the Hongmeng operating system. The system call interface provides a data interface for devices based on the Internet of Things protocol, and the devices include sensors in various application scenarios.

[0033] Preferably, the client process module calls the sensor CPP program interface through the JS engine to obtain sensor data, and displays the sensor data in real time through the UI interface, wherein the CPP program interface accesses the JS engine through the interface of the NAPI framework to obtain the JS running context and return the result.

[0034] In a third aspect, an embodiment of the present invention further provides an electronic device, comprising a processor and a memory, wherein the memory is used to store a computer program, the computer program comprises program instructions, and the processor is configured to call the program instructions to execute the method as described above.

[0035] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, wherein the computer program includes program instructions, and when the program instructions are executed by a processor or a computer, the processor executes the method as described above.

[0036] Compared with the prior art, the multi-application scenario IoT test box based on the Hongmeng system provided by the embodiment of the present invention has at least the following beneficial effects:

[0037] The embodiment of the present invention adopts JSON to organize data and is compatible with the parsing and processing of different Internet of Things protocols. It adopts binder to realize inter-process communication, thereby ensuring higher communication efficiency, thereby supporting the collection and display of sensor data of different modalities in different multiple scenarios, and realizing the separation of interface client process and server-side process of data collection, with higher robustness; as well as the control of terminal devices in multiple scenarios, it can flexibly support Internet of Things simulation under different scenarios, different Internet of Things protocols, and different sensors; it supports "end", "edge" and "cloud" collaboration: data is collected on the "server side", data is displayed in real time on the "client side", and commands of the "cloud" are executed. The "remote server cloud" stores data, and supports the web backend. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The preferred implementation modes will be described below in a clear and understandable manner with reference to the accompanying drawings to further illustrate the above-mentioned characteristics, technical features, advantages and implementation methods of the present invention.

[0039] Figure 1 This is a schematic diagram of a multi-application scenario Internet of Things test box based on the Hongmeng system according to an embodiment of the present invention;

[0040] Figure 2 This is a schematic diagram of another multi-application scenario IoT test box based on the Hongmeng system according to an embodiment of the present invention;

[0041] Figure 3This is a schematic diagram of the process of a proximal server accessing sensor data in a multi-application scenario IoT test box based on the Hongmeng system in an embodiment of the present invention;

[0042] Figure 4 This is a schematic diagram of the format of data encoding performed by a proximal server in a multi-application scenario IoT test box based on the Hongmeng system according to an embodiment of the present invention;

[0043] Figure 5 It is a schematic diagram of the process of data communication between the client and the proximal server based on the Binder service in a multi-application scenario IoT test box based on the Hongmeng system in an embodiment of the present invention;

[0044] Figure 6 This is a schematic diagram of a process for a proximal server to request sensor data in a multi-application scenario IoT test box based on the Hongmeng system according to an embodiment of the present invention;

[0045] Figure 7 This is a flow chart of a data processing method for a multi-application scenario IoT test box based on the Hongmeng system according to an embodiment of the present invention;

[0046] Figure 8 The figure is a schematic diagram of the structure of an electronic device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0047] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the specific implementation methods of the present invention will be described below with reference to the accompanying drawings. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings and other implementation methods can be obtained based on these drawings without creative work.

[0048] In order to simplify the drawings, only the parts related to the invention are schematically shown in each figure, and they do not represent the actual structure of the product. In addition, in order to simplify the drawings and facilitate understanding, in some figures, only one of the parts with the same structure or function is schematically drawn or marked. In this article, "one" not only means "only one", but also means "more than one".

[0049] The following mainly takes some specific embodiments as examples to describe in detail the implementation of the technical solution of the present invention.

[0050] like Figure 1 As shown, in order to achieve the purpose of the invention, an embodiment of the present invention provides a multi-application scenario IoT test box based on the Hongmeng system, including:

[0051] Hongmeng operating system module, used to provide IPC communication between processes;

[0052] The client process module is used to send a data read request to the near-end server;

[0053] The near-end server process module is used to collect sensor data after receiving the data reading request, and perform JSON encoding on the sensor data to generate JSON format encoded data, synchronize the JSON format encoded data to the client process module for display through IPC communication, and upload it to the remote server module for storage through the Internet of Things protocol;

[0054] The remote server module is used to store data from different sensors in different application scenarios.

[0055] Among them, the Hongmeng operating system module includes:

[0056] The system capability manager is used to receive the registration of the Binder service based on IPC communication by the proximal server process module, so that the client process module can obtain the Binder service by requesting and thus communicate between processes;

[0057] The system call interface is used to provide a data interface for devices based on the Internet of Things protocol. The remote server process obtains device data through the system call interface. The device includes sensors in various application scenarios.

[0058] Preferably, the proximal server process module includes:

[0059] A data acquisition unit, used to collect data from sensors in different application scenarios through a system call interface;

[0060] An encoding unit, used to perform JSON encoding on the collected data to generate JSON format encoded data, wherein the JSON format encoded data enables the application to distinguish different application scenarios and sensor sources corresponding to the data;

[0061] The first IPC communication unit is used to transmit the JSON format encoded data to the client process through the Binder service; so that the JS interface front-end program on the client process can obtain the sensor data through the CPP interface;

[0062] The data uploading unit is used to synchronize the JSON format encoded data to the remote server in real time.

[0063] Preferably, the client process module specifically includes:

[0064] A data request unit, used to send a data read request to the proximal server process module;

[0065] A second IPC communication unit, used to obtain the JSON format encoded data through a Binder service;

[0066] The JS interface front end is used to call the sensor CPP program interface through the JS engine to obtain sensor data, and display the sensor data in real time through the UI interface. The CPP program interface accesses the JS engine through the interface of the NAPI framework to obtain the JS running context and return the result.

[0067] The OpenHarmony operating system module provides support for underlying hardware drivers and upper-layer basic services, especially IPC communication protocol support;

[0068] The near-end server process module collects sensor data through the data collection unit, encodes the sensor data in JSON through the encoding unit, synchronizes the collected sensor data to the JS interface front-end display of the client process module through the first IPC communication unit, and uploads the data to the remote server module for storage through the data upload unit using the Internet of Things protocol (such as MQTT);

[0069] The client process module provides a JS interface front end, implements the terminal interface based on JavaScript, supports calling the CPP interface, and displays the real-time status of different modal sensors in different scenarios in real time;

[0070] The remote server module implements the support of database and web backend, stores data from sensors of different modalities in different scenarios, and provides remote interface call support for the web frontend.

[0071] like Figure 2 As shown, a multi-application scenario IoT test box based on the Hongmeng system according to an embodiment of the present invention operates as follows:

[0072] The near-end server process module registers services with the System Ability Manager on the OpenHarmony system, so that other processes can request System Ability Manager to communicate with the near-end server process through Binder;

[0073] The client process module obtains services from the SystemAbility Manager on OpenHarmony, so that the second IPC communication unit of the client process module can communicate with the proximal server process through the Binder through the obtained services;

[0074] The data acquisition unit of the proximal server process module obtains the device data files of the IoT protocol modules such as Zigbee, Lora, Wifi, BLE, and NBIOT through the system call interface of the OpenHarmony operating system. The data of these devices includes the sensor data in various task scenarios.

[0075] The encoding unit of the proximal server process module encodes the data obtained from the IoT protocol module into JSON to generate Figure 4 The JSON format encoding data shown can make it easier for upper-layer applications to distinguish different mission scenarios and different types of sensor data sources;

[0076] The data upload unit of the near-end server process module synchronizes the encoded JSON format data to the remote server in real time through the MQTT protocol, and stores it in the database of the remote server to achieve persistence of sensor data;

[0077] The near-end server process module passes the encoded JSON format data to the client process through Binder, so that the JS interface front-end program on the client process can obtain the sensor data through the CPP interface;

[0078] like Figure 6 As shown in the figure, the JS interface front-end program of the client process calls and executes the CPP program interface through the JS engine. The CPP program accesses the JS engine through the interface of the NAPI framework to obtain the JS running context and return the result. After the JS interface front-end program obtains the data, it displays the real-time sensor data through the UI interface. The JS interface here is an interactive Web page built based on JavaScript.

[0079] Among them, NAPI and CPP program interfaces are both in the client program, because the client program is developed in two different programming languages ​​(CPP and JavaScript). The NAPI interface implements cross-language calls between JavaScript and CPP. The CPP program interface provided here is mainly used to communicate with the local server and request sensor data from the local server. The JS engine is located in the client module and provides the function of interpreting and executing JavaScript. The JS running context refers to the function context under JavaScript semantics, such as the parameter list of the function, the address of the return value, etc. Because it involves cross-language calls, the function calling conventions and underlying logic (registers, memory management) of JavaScript and CPP are different. Therefore, to implement cross-language calls, function calls between different languages ​​need to be compatible.

[0080] That is, NAPI is Node.js API, which is a layer of encapsulation of V8 engine API by Node.js in order to realize mutual calls between JavaScript and C++ libraries. It is an API for network data processing, mainly used to improve network processing efficiency, especially when processing large amounts of data. NAPI can use interrupt mode when the data volume is low and polling mode when the data volume is high, thereby optimizing processing efficiency.

[0081] The data interaction between the proximal server and the client in the simulation experiment box hardware platform of the embodiment of the present invention is based on the Binder service, and the data processing interaction process can be as follows: Figure 5 As shown, the OpenHarmony operating system module, the server process module, and the client process module all run on the test box device.

[0082] In terms of sensor data collection, the data collection unit of the proximal server process module is written based on CPP, and sensor data collection based on different protocols is realized based on the OpenHarmony system. The process of sensor data collection is as follows Figure 3 shown.

[0083] like Figure 5 As shown, the Zigbee, Lora, and Nbiot communication protocol modules are connected to the test box device SOC through the serial port, while Ble and Wifi use the Bluetooth and wireless communication modules integrated on the test box device SOC.

[0084] Communication modules such as Zigbee, Lora, Nbiot, Ble, Wifi, etc. are each connected to different sensor devices (such as light, temperature and humidity, infrared sensors, etc.) or other terminal devices (such as relays, LEDs, etc.).

[0085] The OpenHarmony operating system kernel is based on the open source Linux Kernel, supports driver modules such as Uart, Wlan, Bluetooth, and provides interfaces to user-mode processes through the device file system.

[0086] like Figure 3 As shown, the proximal server process module accesses the device file system to obtain sensor data through C library interfaces (system call interfaces) such as open() / read() / write() / ioctl().

[0087] When the data acquisition unit of the proximal server process module reads the sensor data, the sensor device encodes the sensor data according to the scene, sensor type, and numerical value and sends it to the server process module.

[0088] The near-end server process module encodes the sensor data read from Uart / Wlan / Bluetooth and generates JSON format encoded data. The basic format is as follows Figure 4 As shown, the JSON format encoded data defines the scenario and sensor category of the sensor data, which is used to distinguish different IoT scenarios (such as intelligent underground temperature and humidity monitoring, intelligent underground harmful gas monitoring, underground intelligent fire monitoring, intelligent agricultural monitoring, etc.).

[0089] The local server process module synchronizes the processed JSON format encoded data to the client process module through IPC (Binder) communication, and sends it to the remote server module for persistence through the mqtt Internet of Things protocol.

[0090] The proximal server process module registers the service with the SystemAbility Manager on OpenHarmony, and the SystemAbilityManager records that the proximal server process module has the IPC communication capability to provide sensor data;

[0091] The client process module requests the SystemAbility Manager (system capability manager) on OpenHarmony for the object (IPC file handle) for communicating with the proximal server process module.

[0092] After the client process module obtains the object, it sends the data read request to the proximal server process module through the Binder mechanism.

[0093] The proximal server process module responds to the data reading request, starts collecting the sensor data, performs JSON encoding, and returns the JSON format encoded data to the client process module through Binder.

[0094] The client process module includes a front-end interface based on JavaScript to display the sensor status in real time, and an IPC communication module based on CPP.

[0095] When the proximal server process module responds to the data reading request of the client process module, the sensor data CPP interface returns the result to the JavaScript front-end program according to the JavaScript running context.

[0096] After the client process module obtains the sensor data returned by the server process module, it displays the data in real time through the JavaScript interface front end.

[0097] The cross-language calling process between the client process module JavaScript and CPP is as follows Figure 6 shown.

[0098] The client process module parses and executes JavaScript through the JS engine. When executing the logic related to sensor data acquisition, the JS engine will call the implemented sensor data request CPP program interface and initiate a data request to the server process module through the Binder mechanism.

[0099] The implemented sensor data request CPP interface accesses the JS engine through the NAPI interface to obtain the JavaScript running context.

[0100] The near-end server process module and the remote server module support multiple Internet protocol communications (such as the Internet of Things protocol MQTT), which can be selected through the web front-end.

[0101] Among them, the server process module publishes messages to the proxy of the remote server module through the Internet of Things protocol MQTT, and the relevant web front-end subscribes to the message from the proxy of the remote server module. The web front-end can request the sensor information published by all server process modules through the remote server module and display it synchronously on the web front-end interface.

[0102] Second, as Figure 7 As shown, in order to solve the technical problem, the embodiment of the present invention also provides a data processing method for a multi-application scenario Internet of Things test box based on the Hongmeng system, and the method includes:

[0103] S1, the client process module sends a data read request to the proximal server;

[0104] S2, after receiving the data reading request, the proximal server process module collects sensor data, and performs JSON encoding on the sensor data to generate JSON format encoded data;

[0105] S3. Synchronize the JSON format encoded data to the client process module for display through IPC communication;

[0106] S4. The proximal server process module synchronously uploads the JSON format encoded data to the remote server module for storage through the Internet of Things protocol.

[0107] Furthermore, the method further comprises:

[0108] The Hongmeng operating system module receives the registration of the Binder service based on IPC communication from the proximal server process module, so that the client process module obtains the Binder service by requesting and thus communicates between processes.

[0109] Preferably, the proximal server process module collects sensor data specifically including:

[0110] Data is collected from sensors in different application scenarios through the system call interface of the Hongmeng operating system. The system call interface provides a data interface for devices based on the Internet of Things protocol, and the devices include sensors in various application scenarios.

[0111] Preferably, the client process module calls the sensor CPP program interface through the JS engine to obtain sensor data, and displays the sensor data in real time through the UI interface, wherein the CPP program interface accesses the JS engine through the interface of the NAPI framework to obtain the JS running context and return the result.

[0112] In the method embodiment, its implementation method is the same as the system implementation method, and will not be described in detail here.

[0113] In a third aspect, an embodiment of the present invention further provides an electronic device, comprising a processor and a memory, wherein the memory is used to store a computer program, the computer program comprises program instructions, and the processor or calculator is configured to call the program instructions to execute the method as described above.

[0114] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, wherein the computer program includes program instructions, and when the program instructions are executed by a processor or a computer, the processor or the computer executes the method as described above.

[0115] like Figure 8 As shown, an electronic device provided by an embodiment of the present application, the vehicle-mounted device 1000 includes a processor or a calculator (not shown in the figure) 1001 and a memory 1002, and the processor or calculator 1001 and the memory 1002 can be interconnected through a communication bus 1003. The communication bus 1003 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus 1003 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the memory 1002 is used to store a computer program, and the computer program includes program instructions. The processor 1001 is configured to call the program instructions, and the above program includes a method for executing some or all of the steps in the aforementioned method.

[0116] The processor 1001 may be a general purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of the above program.

[0117] The memory 1002 may be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory may exist independently and be connected to the processor via a bus. The memory may also be integrated with the processor.

[0118] The electronic device 1000 may further include a communication module 1004 and a display 1005. The communication module 1004 may be connected to the optical tracking device for communication. The communication module 1004 may be a wireless communication module (eg, a WiFi module, a Bluetooth module, etc.) or a wired communication module.

[0119] In addition, the electronic device 1000 may also include common components such as a communication interface (eg, a USB interface, a microphone interface, etc.), an antenna, etc., which will not be described in detail here.

[0120] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.

[0121] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0122] In the several embodiments provided in the present application, it should be understood that the disclosed device can be implemented in other ways. For example, the device embodiments described above are only schematic, such as the division of the units, which is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, and the indirect coupling or communication connection of devices or units can be electrical or other forms.

[0123] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0124] In addition, the functional units in the various embodiments of the application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated units may be implemented in the form of hardware or in the form of software program modules.

[0125] If the integrated unit is implemented in the form of a software program module and sold or used as an independent product, it can be stored in a computer-readable memory. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a memory, including a number of instructions to enable a computer device (which can be a personal computer, server or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned memory includes: U disk, read-only memory (ROM), random access memory (RAM), mobile hard disk, magnetic disk or optical disk and other media that can store program codes.

[0126] A person of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable memory, which can include: a flash drive, a read-only memory, a random access memory, a magnetic disk or an optical disk, etc.

[0127] The embodiments of the present application are introduced in detail above. Specific examples are used in this article to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core idea of ​​the present application. At the same time, for general technical personnel in this field, according to the idea of ​​the present application, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present application.

[0128] It should be noted that the above embodiments can be freely combined as needed. The above are only preferred embodiments of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be regarded as the protection scope of the present invention.

Claims

1. A multi-application scenario IoT test box based on Hongmeng system, characterized in that: The test box comprises: Hongmeng operating system module, used to provide IPC communication between processes; The client process module is used to send a data read request to the near-end server; The near-end server process module is used to collect sensor data after receiving the data reading request, and perform JSON encoding on the sensor data to generate JSON format encoded data, synchronize the JSON format encoded data to the client process module for display through IPC communication, and upload it to the remote server module for storage through the Internet of Things protocol; The remote server module is used to store data from different sensors in different application scenarios.

2. The multi-application scenario IoT test box based on Hongmeng system as claimed in claim 1 is characterized in that: The Hongmeng operating system module includes: The system capability manager is used to receive the registration of the Binder service based on IPC communication by the proximal server process module, so that the client process module can obtain the Binder service by requesting and thus communicate between processes; The system call interface is used to provide a data interface for devices based on the Internet of Things protocol. The remote server process obtains device data through the system call interface. The device includes sensors in various application scenarios.

3. The multi-application scenario IoT test box based on Hongmeng system as claimed in claim 2 is characterized in that: The near-end server process module includes: A data acquisition unit, used to collect data from sensors in different application scenarios through a system call interface; An encoding unit, used to perform JSON encoding on the collected data to generate JSON format encoded data, wherein the JSON format encoded data enables the application to distinguish different application scenarios and sensor sources corresponding to the data; The first IPC communication unit is used to transmit the JSON format encoded data to the client process through the Binder service; so that the JS interface front-end program on the client process can obtain the sensor data through the CPP interface; The data uploading unit is used to synchronize the JSON format encoded data to the remote server in real time.

4. The multi-application scenario IoT test box based on Hongmeng system as claimed in claim 3 is characterized in that: The client process module specifically includes: A data request unit, used to send a data read request to the proximal server process module; A second IPC communication unit, used to obtain the JSON format encoded data through a Binder service; The JS interface front end is used to call the sensor CPP program interface through the JS engine to obtain sensor data, and display the sensor data in real time through the UI interface. The CPP program interface accesses the JS engine through the interface of the NAPI framework to obtain the JS running context and return the result.

5. A data processing method for a multi-application scenario IoT test box based on Hongmeng system according to claim 1, characterized in that: The method comprises: The client process module sends a data read request to the near-end server; After receiving the data reading request, the near-end server process module collects the sensor data, and performs JSON encoding on the sensor data to generate JSON format encoded data; Synchronize the JSON format encoded data to the client process module for display through IPC communication; The near-end server process module synchronously uploads the JSON format encoded data to the remote server module for storage through the Internet of Things protocol.

6. The data processing method of the multi-application scenario Internet of Things test box based on the Hongmeng system as claimed in claim 5 is characterized in that: The method further comprises: The Hongmeng operating system module receives the registration of the Binder service based on IPC communication from the proximal server process module, so that the client process module obtains the Binder service by requesting and thus communicates between processes.

7. The data processing method of the multi-application scenario Internet of Things test box based on the Hongmeng system as claimed in claim 6 is characterized in that: The near-end server process module collects sensor data specifically including: Data is collected from sensors in different application scenarios through the system call interface of the Hongmeng operating system. The system call interface provides a data interface for devices based on the Internet of Things protocol, and the devices include sensors in various application scenarios.

8. The data processing method of the multi-application scenario Internet of Things test box based on the Hongmeng system as claimed in claim 7 is characterized in that: The client process module calls the sensor CPP program interface through the JS engine to obtain sensor data, and displays the sensor data in real time through the UI interface. The CPP program interface accesses the JS engine through the interface of the NAPI framework to obtain the JS running context and return the result.

9. An electronic device, characterized in that: The electronic device comprises a processor and a memory, wherein the memory is used to store a computer program, the computer program comprises program instructions, and the processor is configured to call the program instructions to execute the method according to any one of claims 5 to 8.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program includes program instructions, and when the program instructions are executed by a processor, the processor or the computer executes the method according to any one of claims 5 to 8.

Images