Iot middleware and system

Abstract

The application provides an Internet of Things middleware and system, and relates to the technical field of Internet of Things. The middleware comprises a device management and adaptation module and an asynchronous message framework. The asynchronous message framework is used for providing a preset function set, and the preset function set is used for concurrently processing business data or business instructions. The device management and adaptation module is used for transmitting a business instruction from an application layer to an Internet of Things device or transmitting business data from the Internet of Things device to the application layer according to a communication mode of the Internet of Things device by calling a function in the preset function set, wherein the business instruction is used for controlling the Internet of Things device to perform a corresponding operation, and the business data is used for the application layer to manage the Internet of Things device. Thus, by optimizing the communication mode between the application layer and the underlying Internet of Things device, the application layer and the underlying Internet of Things device are decoupled, and when the underlying Internet of Things device is replaced or upgraded, the software of the application layer does not need to be modified, recompiled and tested, thereby reducing the development and maintenance costs.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and more particularly to an IoT middleware and system. Background Technology

[0002] With the rapid development of IoT technology, the number of IoT devices has surged, and the types of IoT devices and the communication protocols used have diversified.

[0003] Currently, in IoT systems, the application layer is usually tightly coupled with the underlying IoT devices and their drivers. Applications may directly call the application programming interface (API) of a specific port or network port driver to communicate with IoT devices.

[0004] However, in the above approach, if the underlying IoT device is replaced or upgraded, its driver will also change. Developers must make extensive modifications, recompile, and test the application layer software to adapt to the new driver, which is time-consuming and labor-intensive, greatly increasing development and maintenance costs. Summary of the Invention

[0005] This application provides an IoT middleware and system to address the problem that when the underlying IoT devices are replaced or upgraded, their drivers also change, requiring developers to make extensive modifications, recompiles, and tests to adapt the application layer software to the new drivers. This is time-consuming, labor-intensive, and greatly increases development and maintenance costs. By optimizing the communication method between the application layer and the underlying IoT devices, the application layer and the underlying IoT devices are decoupled. When the underlying IoT devices are replaced or upgraded, there is no need to modify, recompile, or test the application layer software, thus reducing development and maintenance costs.

[0006] In a first aspect, this application provides an Internet of Things (IoT) middleware, which includes: a device management and adaptation module and an asynchronous message framework;

[0007] The asynchronous message framework is used to provide a preset function set, which is used to concurrently process business data or business instructions;

[0008] The device management and adaptation module is used to transmit business instructions from the application layer to the IoT device according to the communication method of the IoT device by calling functions in the preset function set, or to transmit business data from the IoT device to the application layer. The business instructions are used to control the IoT device to perform corresponding operations, and the business data is used by the application layer to manage the IoT device.

[0009] In one possible design, the communication method includes a specific protocol communication method and a general communication method. The specific protocol communication method includes MODBUS protocol communication, Serial Peripheral Interface (SPI) protocol communication, Integrated Circuit Bus (IIC) protocol communication and proprietary protocol communication. The general communication method includes serial port communication and input / output (I / O) communication.

[0010] In one possible design, the preset function set includes standardized functions, buffered functions, and threaded functions, and the asynchronous message framework includes a message module, a buffered module, and a threaded module.

[0011] The message module is used to provide the standardization function, which defines a standardized message format so that messages passing through the middleware include message source, destination, data payload, and timestamp.

[0012] The buffer module is used to provide the buffer function, which is used to create one or more circular buffers or first-in-first-out (FIFO) queues.

[0013] The thread module is used to provide the thread function and send multiple worker threads to the operating system for scheduling. The multiple worker threads are created by the device management and adaptation module according to the thread function. The worker threads are used to process business messages, which include business instructions and business data.

[0014] In one possible design, the device management and adaptation module includes: a specific protocol adaptation layer and a general device abstraction layer;

[0015] The specific protocol adaptation layer is used to call the thread function to create a worker thread corresponding to the business message when the IoT device communicates through the specific protocol communication method, call the standardization function, and convert the business instruction into a protocol instruction or the business data into protocol data through the first preset function and the communication method corresponding to the IoT device, and call the buffer function to transmit the protocol instruction to the IoT device or the protocol data to the application layer through the buffer function.

[0016] The general device abstraction layer is used to call the thread function to create a worker thread corresponding to the business message when the IoT device communicates through the general communication method, read the business data from the IoT device or write the business instruction to the IoT device through the device file descriptor, the device file descriptor is used to indicate the IoT device corresponding to the business data or the IoT device corresponding to the business instruction, and call the buffer function to transmit the business instruction to the IoT device or the business data to the application layer through the buffer function.

[0017] In one possible design, the general device abstraction layer is also used for:

[0018] When transmitting the service instruction to the IoT device through the buffer function, the service instruction is decapsulated; or when transmitting the service data to the application layer through the buffer function, the service data is encapsulated.

[0019] In one possible design, the specific protocol adaptation layer is further used for:

[0020] A mutex lock is created for each communication port corresponding to the IoT device. The mutex lock is used to set the communication port to a first flag when communication is being performed and to a second flag when the port is idle.

[0021] In one possible design, the middleware further includes: a protocol plugin management module;

[0022] The protocol plugin management module is used to realize communication between the application layer and the server through a preset dynamic link library. The preset dynamic link library includes application programming interface (API) functions corresponding to multiple server communication protocols.

[0023] In one possible design, the middleware further includes: a log management module;

[0024] The log management module is used to collect, store, and output runtime logs generated during the middleware's runtime.

[0025] In one possible design, the middleware also includes: a tool library module;

[0026] The tool library module is used to provide general tool functions for the middleware.

[0027] Through the middleware provided in the first aspect, a bidirectional data transmission channel is established through the collaboration of the device management and adaptation module and the asynchronous message framework. When it is necessary to transmit business instructions or business data, business data is transmitted from the IoT device to the application layer, or business instructions are transmitted from the application layer to the IoT device, based on the communication method of the IoT device. This shields the differences between different IoT devices, eliminating the need to write different application layer software to adapt to different IoT devices, thereby reducing development and maintenance costs.

[0028] Secondly, this application provides an Internet of Things (IoT) system, which includes: an application layer, IoT devices, and middleware as described in the first aspect and any possible design of the first aspect.

[0029] The beneficial effects of the Internet of Things system provided in the second aspect and the various possible designs of the second aspect can be found in the first aspect and the various possible implementations of the first aspect, and will not be repeated here.

[0030] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of the embodiments of this application and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of this application are described below. Attached Figure Description

[0031] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0032] Figure 1 This is a schematic diagram of the structure of an Internet of Things (IoT) system provided in an embodiment of this application.

[0033] Figure 2 This is a schematic diagram of the structure of an Internet of Things middleware provided in an embodiment of this application.

[0034] Figure 3 This is a schematic diagram of the structure of an asynchronous message framework provided in an embodiment of this application.

[0035] Figure 4 This is a schematic diagram of the structure of a device management and adaptation module provided in an embodiment of this application.

[0036] Figure 5 This is a schematic diagram of the structure of an Internet of Things middleware provided in an embodiment of this application.

[0037] Figure 6 This is a schematic diagram of the structure of an Internet of Things middleware provided in an embodiment of this application.

[0038] Figure 7 This is a schematic diagram of the structure of an Internet of Things middleware provided in an embodiment of this application. Detailed Implementation

[0039] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c alone can mean: a alone, b alone, c alone, a combination of a and b, a combination of a and c, a combination of b and c, or a, b, and c, where a, b, and c can be single or multiple. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0040] The terms “center,” “longitudinal,” “lateral,” “up,” “down,” “left,” “right,” “front,” and “rear,” etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application.

[0041] The terms "connected" and "connected" should be interpreted broadly. For example, in circuit structures, "connected" or "connected" can refer not only to physical connections but also to electrical or signal connections. This could be a direct connection (physical connection) or an indirect connection via at least one intermediate component, as long as the circuit is connected. It could also refer to the internal connection between two components. Similarly, a signal connection can refer to a connection via a circuit or a medium, such as radio waves. Those skilled in the art will understand the specific meaning of these terms in this application based on the specific circumstances.

[0042] The term "embodiment" as used herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of the phrase "embodiment" in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0043] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0044] For example, this application provides an IoT middleware and system. By setting up a device management and adaptation module and an asynchronous message framework, the asynchronous message framework provides a set of preset functions for processing business data or business instructions. The device management and adaptation module uses the preset function set to transmit business instructions from the application layer to the IoT device or from the IoT device to the application layer, depending on the different communication methods of the IoT device. In this way, the middleware acts as a "translator" between the application layer and the underlying IoT device, shielding the differences between different IoT devices. This eliminates the need to write different application layer software to adapt to different IoT devices, thereby reducing development and maintenance costs.

[0045] First, we introduce the Internet of Things (IoT) system provided in the embodiments of this application.

[0046] Please see Figure 1 , Figure 1 This is a schematic diagram of the structure of an Internet of Things (IoT) system provided in an embodiment of this application. Figure 1 As shown, the Internet of Things (IoT) system includes IoT middleware 10, application layer 20, and IoT devices 30.

[0047] The application layer 20 is connected to the IoT middleware 10, and the IoT device 30 is connected to the IoT middleware 10.

[0048] Application Layer 20 is the topmost software layer of the IoT system. It is used to implement functions such as business decision-making, data processing, and data visualization. Application Layer 20 can be, for example, a cloud platform, an application (APP), a webpage, or a data analytics engine.

[0049] The Internet of Things (IoT) device 30 is located at the bottom layer of the IoT system. It is a physical entity embedded with sensors, actuators, or communication modules, capable of exchanging data with other devices or systems via wired or wireless networks to achieve automated operation or remote management. IoT devices possess unique identifiers, network connectivity, and data interaction capabilities. Examples of IoT devices include smart meters, temperature sensors, smart light bulbs, or programmable logic controllers (PLCs).

[0050] The IoT middleware 10 is located between the application layer 20 and the IoT device 30. The IoT middleware 10 is used to perform data standardization processing, protocol adaptation, etc., so as to transmit data to the application layer 20 or the IoT device 30.

[0051] In an IoT system, the uplink data flow is: IoT device 30 → IoT middleware 10 → application layer 20. For example, in a smart industrial scenario, a temperature sensor reports a temperature value, which is then converted into a temperature signal. The IoT middleware receives the temperature signal, processes it to obtain temperature data, and the application layer receives the temperature data and can display the current temperature to the user based on the temperature data.

[0052] In an IoT system, the downlink data flow is: Application Layer 20 → IoT Middleware 10 → IoT Device 30. For example, in a smart home scenario, a smart light fixture is controlled via an app. The app sends a light-on command, the IoT middleware receives the command, converts it into a light-on signal, and the IoT device receives the signal to control the light bulb in the smart light fixture to turn on.

[0053] Below, in conjunction with Figures 2 to 7 This application provides a detailed description of the IoT middleware provided.

[0054] Please see Figure 2 , Figure 2 This is a schematic diagram of the structure of an IoT middleware provided in one embodiment of this application. Figure 2 As shown, the IoT middleware 10 includes a device management and adaptation module 11 and an asynchronous message framework 12.

[0055] Among them, the asynchronous message framework 12 is used to provide a set of preset functions, which are used to concurrently process business data or business instructions.

[0056] The asynchronous messaging framework 12 decouples the producers and consumers of business data and business instructions. Producers refer to the data providers or sources, while consumers refer to the data receivers or processors. For business data, the data provider or source is the IoT device, and the data receiver or processor is the application layer. For business instructions, the data provider or source is the application layer, and the data receiver or processor is the IoT device.

[0057] Among them, business instructions refer to instructions that control IoT devices to perform corresponding operations. Business instructions are used to control IoT devices to perform corresponding operations. They are input by the user to the application layer and then sent down to the IoT middleware. For example, in the scenario of temperature sensor measurement, business instructions can be "turn on sensor", "start temperature measurement" and "turn off sensor", etc.

[0058] Business data refers to status data acquired by IoT devices, which can be used for application-layer management of IoT devices. Business data is generated by IoT devices; for example, in a temperature sensor scenario, business data could be "25℃" or "the temperature at 18:00 on January 1, 2025 is 25℃".

[0059] Among them, the device management and adaptation module 11 is used to transmit business instructions from the application layer to the IoT device by calling functions in the preset function set and according to the communication method of the IoT device.

[0060] The device management and adaptation module 11 is also used to transmit business data from the IoT device to the application layer by calling functions in a preset function set and according to the communication method of the IoT device.

[0061] The communication methods of IoT devices include specific protocol communication methods and general communication methods.

[0062] Specific protocol communication refers to communication types that require a dedicated protocol stack for parsing, such as MODBUS protocol communication and Serial Peripheral Interface (SPI) protocol communication.

[0063] General communication methods refer to basic data transmission methods that do not require protocol parsing, such as serial communication and input / output (I / O) communication.

[0064] For uplink data streams, the device management and adaptation module 11 can create buffers and worker threads by calling functions in the asynchronous message framework 12. It can also pre-confirm the communication method of the IoT device. Based on the communication method of the IoT device, the device management and adaptation module 11 uses the function corresponding to the communication method to obtain business data from the IoT device. It then calls functions in the asynchronous message framework 12 to encapsulate the business data into a standard format business data message and pushes it into the buffer. The worker thread pulls the business data message from the buffer and executes the corresponding processing logic. Thus, the device management and adaptation module 11 can transmit business data from the IoT device to the application layer.

[0065] For downlink data streams, the device management and adaptation module 11 also creates a buffer and worker threads by calling functions in the asynchronous message framework 12, and pre-confirms the communication method of the IoT device. The device management and adaptation module 11 obtains business instructions from the application layer, and calls functions in the asynchronous message framework 12 to encapsulate the business instructions into standard format business instruction messages, and then pushes them into the buffer. The worker thread pulls the business instruction messages from the buffer, executes the corresponding processing logic, and writes the business instructions to the IoT device based on the communication method of the IoT device using the function corresponding to the communication method. Thus, the device management and adaptation module 11 can transmit business instructions from the application layer to the IoT device.

[0066] Taking MODBUS protocol communication as an example, for uplink data streams, the device management and adaptation module 11 creates a buffer and worker thread by calling functions in the asynchronous message framework 12. It confirms that the communication method of the device is MODBUS protocol communication, uses the function corresponding to the MODBUS protocol, which obtains the business data in the IoT device according to the MODBUS protocol, and calls the function in the asynchronous message framework 12 to encapsulate the business data into a standard format business data message, and then pushes it into the buffer. The worker thread pulls the business data message from the buffer and executes the corresponding processing logic, so that the device management and adaptation module 11 can transmit business data from the IoT device to the application layer.

[0067] In this embodiment, a bidirectional data transmission channel is established through the collaboration of the device management and adaptation module 11 and the asynchronous message framework 12. When business instructions or business data need to be transmitted, business data is transmitted from the IoT device to the application layer, or business instructions are transmitted from the application layer to the IoT device, based on the communication method of the IoT device. This shields the differences between different IoT devices, eliminating the need to write different application layer software to adapt to different IoT devices, thereby reducing development and maintenance costs.

[0068] Based on the above exemplary description, the communication methods of IoT devices include specific protocol communication methods and general communication methods.

[0069] Specific protocol communication methods include MODBUS protocol communication, SPI protocol communication, inter-integrated circuit (IIC) protocol communication, and proprietary protocol communication. Proprietary protocol communication refers to communication methods based on non-public protocol standards, mainly used for data transmission within an enterprise or between specific systems.

[0070] Common communication methods include serial communication and I / O communication.

[0071] Based on this, IoT middleware can be compatible with a variety of different communication methods, thereby improving the compatibility of IoT systems.

[0072] Based on the above exemplary description, the preset function set in the asynchronous message framework 12 includes standardized functions, buffered functions, and thread functions. The following section will combine... Figure 3 This describes the detailed structure of the asynchronous messaging framework 12.

[0073] Please see Figure 3 , Figure 3 This is a schematic diagram of the structure of an asynchronous message framework provided in an embodiment of this application. Figure 3 As shown, the asynchronous message framework 12 includes: a message module 121, a buffer module 122, and a thread module 123.

[0074] The message module 121 is used to provide standardized functions, which define standardized message formats so that messages passing through the IoT middleware include message source, destination, data payload, and timestamp.

[0075] Since different IoT devices have different message formats, the message module 121 can provide standardized functions. The IoT middleware calls the standardized functions to process the messages passing through the IoT middleware, thereby giving the messages passing through the IoT middleware a standardized message format. The standardized message format defines the message source, destination, data payload and timestamp, which facilitates processing by the IoT middleware and improves the efficiency of message transmission.

[0076] For example, if the application layer sends a service instruction with the content "Start temperature measurement" at 18:20:32 on July 15, 2025, and the destination is the communication port with the address 111.11.1, the message module 121 can convert the service instruction into the format "Application layer, 111.11.1, Start temperature measurement, 18:20:32 on July 15, 2025".

[0077] Among them, the buffer module 122 is used to provide buffer functions, which are used to create one or more circular buffers or first-in-first-out (FIFO) queues.

[0078] The thread module provides thread functions and sends multiple worker threads to the operating system for scheduling.

[0079] Among them, multiple worker threads are created by the device management and adaptation module 11 according to the thread function. The worker threads are used to process business messages, which include business instructions and business data.

[0080] The device management and adaptation module 11 can call the buffer function to create one or more circular buffers or FIFO queues, and call the thread function to create multiple worker threads, so that concurrent processing can be achieved through buffers or FIFO queues and multiple worker threads when transmitting business instructions or business data.

[0081] Based on this, when multiple IoT devices simultaneously receive business instructions or send business data, multiple worker threads, as well as buffers or FIFO queues, can process this data concurrently, avoiding system blockage due to waiting for a certain input / output operation, thus solving the problem of low concurrency. At the same time, asynchronous communication between modules further reduces the coupling between the application layer software and the underlying IoT devices.

[0082] Based on the above exemplary description, the following, in conjunction with Figure 4 This describes the detailed structure of the device management and adaptation module 11.

[0083] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of a device management and adaptation module provided in one embodiment of this application. Figure 4 As shown, the device management and adaptation module 11 includes: a specific protocol adaptation layer 111 and a general device abstraction layer 112.

[0084] Among them, the specific protocol adaptation layer 111 is used to call the thread function to create the worker thread corresponding to the business instruction when the IoT device communicates through the specific protocol communication method, call the standardized function, and convert the business instruction into the protocol instruction or the business data into the protocol data through the first preset function and the communication method corresponding to the IoT device, and call the buffer function to transmit the protocol instruction to the IoT device or the protocol data to the application layer through the buffer function.

[0085] The first preset function refers to the function corresponding to the communication method of the IoT device.

[0086] For example, when the communication method corresponding to the IoT device is MODBUS protocol communication, the first preset function may include: device_modbus_read_registers(), device_modbus_write_registers(), etc.

[0087] Among them, the general device abstraction layer 112 is used to call the thread function to create the worker thread corresponding to the business instruction when the IoT device communicates through the general communication method, read business data from the IoT device or write business instructions to the IoT device through the device file descriptor, and call the buffer function to transmit business instructions to the IoT device or transmit business data to the application layer through the buffer function.

[0088] The device file descriptor is used to indicate the IoT device corresponding to the business data or the IoT device corresponding to the business instruction.

[0089] The general device abstraction layer 112 abstracts the common elements of the general communication method, namely, the operation of reading business data or writing business quality using the device file descriptor, the operation of calling the buffer function, and the operation of calling the thread function when communicating through the general communication method. Therefore, the general device abstraction layer 112 can perform corresponding processing according to these common elements when IoT devices communicate through the general communication method.

[0090] Based on this, the specific protocol adaptation layer 111 processes the business data and business instructions corresponding to IoT devices with specific protocol communication methods, and the general device abstraction layer 112 processes the business data and business instructions of IoT devices with general communication methods. This shields the differences between different IoT devices, eliminating the need to write different application layer software to adapt to different IoT devices and reducing development and maintenance costs.

[0091] Furthermore, by using buffer functions and thread functions, resource efficiency under high concurrency can be ensured, effectively reducing the system overhead caused by thread context switching and frequent memory allocation, and improving overall throughput.

[0092] Based on the above exemplary description, the general device abstraction layer 112 is also used to decapsulate the business instructions when transmitting business instructions to the Internet of Things device through the buffer function, or to encapsulate the business data when transmitting business data to the application layer through the buffer function.

[0093] The general device abstraction layer 112 can establish a first function pointer and a second function pointer as data processing hooks. The first function pointer is used for data encapsulation processing, and the second function pointer is used for data decapsulation processing.

[0094] Encapsulation processes include adding check bits, while decapsulation processes include stripping data frame headers.

[0095] Based on this, the encapsulation and decapsulation mechanism can improve data parsing efficiency and prevent malicious data injection.

[0096] Based on the above exemplary description, the specific protocol adaptation layer 111 is also used to create a mutex lock for each communication port corresponding to the IoT device. The mutex lock is used to set the first identifier when the communication port is communicating and to set the second identifier when it is idle.

[0097] In this context, each communication port corresponding to an IoT device refers to all communication ports in the IoT system.

[0098] For example, the first identifier can be "1" and the second identifier can be "0".

[0099] Based on this, mutex locks can ensure that only one IoT device can communicate on the same communication port at any given time, thereby ensuring that no access conflict occurs when IoT devices share the bus.

[0100] Based on the above exemplary description, the IoT middleware also includes: a protocol plugin management module 13. The following section combines... Figure 5 This describes the detailed structure of the protocol plugin management module 13.

[0101] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of an IoT middleware provided in one embodiment of this application. Figure 5 As shown, the IoT middleware also includes: Protocol Plug-in Management Module 13.

[0102] The protocol plugin management module 13 is used to realize communication between the application layer and the server through a preset dynamic link library. The preset dynamic link library includes API functions corresponding to multiple server communication protocols.

[0103] Among them, multiple server communication protocols may include: Message Queuing Telemetry Transport (MQTT) protocol and Modbus TCP protocol, etc.

[0104] The API functions can include: connect(), disconnect(), publish(), subscribe(), etc.

[0105] The protocol plugin management module 13 calls these API functions to realize communication between the application layer and the server. The application layer does not need to care about the relationship between the data generated during communication and the communication protocol, but the IoT middleware handles it.

[0106] Based on the above exemplary description, the IoT middleware also includes: a log management module 14. The following, in conjunction with... Figure 6 This describes the detailed structure of the log management module 14.

[0107] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of an IoT middleware provided in one embodiment of this application. Figure 6 As shown, the IoT middleware also includes a log management module 14. The log management module 14 is connected to the device management and adaptation module 11, the asynchronous message framework 12, and the protocol plugin management module 13.

[0108] The log management module 14 is used to collect, store, and output runtime logs generated during the operation of the IoT middleware.

[0109] Specifically, the log management module 14 can perform operations such as initializing the log system, setting log levels, adding log file output, and cleaning up the log system. It supports outputting runtime logs to files and the console, ensuring thread safety.

[0110] Based on this, users can access the operation logs, which facilitates the management of the IoT system, thereby improving the system's maintainability and operational traceability.

[0111] Based on the above exemplary description, the IoT middleware also includes: a tool library module 15. The following, in conjunction with... Figure 7 This describes the detailed structure of the tool library module 15.

[0112] Please see Figure 7 , Figure 7 This is a schematic diagram of the structure of an IoT middleware provided in one embodiment of this application. Figure 7 As shown, the IoT middleware also includes a tool library module 15. The tool library module 15 is connected to the device management and adaptation module 11, the asynchronous message framework 12, and the protocol plugin management module 13, respectively.

[0113] Among them, the tool library module 15 is used to provide general tool functions for IoT middleware.

[0114] Among them, utility functions include number system conversion functions, system timestamp functions, and maximum value calculation functions.

[0115] Based on this, the device management and adaptation module 11, asynchronous message framework 12, protocol plugin management module 13, and log management module 14 in the IoT middleware can meet common requirements through the tool library module 15.

[0116] Those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments, combinations of features from different embodiments are intended to be within the scope of this application and form different embodiments. For example, in the claims, any of the claimed embodiments can be used in any combination.

[0117] The above-described 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 of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. An Internet of Things (IoT) middleware, characterized in that, The middleware includes: a device management and adaptation module and an asynchronous message framework; The asynchronous message framework is used to provide a preset function set, which is used to concurrently process business data or business instructions; The device management and adaptation module is used to transmit business instructions from the application layer to the IoT device according to the communication method of the IoT device by calling functions in the preset function set, or to transmit business data from the IoT device to the application layer. The business instructions are used to control the IoT device to perform corresponding operations, and the business data are used by the application layer to manage the IoT device. The communication methods include specific protocol communication methods and general communication methods. The specific protocol communication methods include MODBUS protocol communication, Serial Peripheral Interface (SPI) protocol communication, Integrated Circuit Bus (IIC) protocol communication and private protocol communication. The general communication methods include serial port communication and input / output (I / O) communication. The preset function set includes standardized functions, buffer functions, and thread functions, and the asynchronous message framework includes a message module, a buffer module, and a thread module. The message module is used to provide the standardization function, which defines a standardized message format so that messages passing through the middleware include message source, destination, data payload, and timestamp. The buffer module is used to provide the buffer function, which is used to create one or more circular buffers or first-in-first-out (FIFO) queues. The thread module is used to provide the thread function and send multiple worker threads into the operating system for scheduling. The multiple worker threads are created by the device management and adaptation module according to the thread function. The worker threads are used to process business messages, and the business messages include the business instructions and the business data. The device management and adaptation module includes: a specific protocol adaptation layer and a general device abstraction layer; The specific protocol adaptation layer is used to call the thread function to create a worker thread corresponding to the business message when the IoT device communicates through the specific protocol communication method, call the standardization function, and convert the business instruction into a protocol instruction or the business data into protocol data through the first preset function and the communication method corresponding to the IoT device, and call the buffer function to transmit the protocol instruction to the IoT device or the protocol data to the application layer through the buffer function. The general device abstraction layer is used to call the thread function to create a worker thread corresponding to the business message when the IoT device communicates through the general communication method, read the business data from the IoT device or write the business instruction to the IoT device through the device file descriptor, the device file descriptor is used to indicate the IoT device corresponding to the business data or the IoT device corresponding to the business instruction, and call the buffer function to transmit the business instruction to the IoT device or the business data to the application layer through the buffer function.

2. The middleware according to claim 1, characterized in that, The general device abstraction layer is also used for: When transmitting the service instruction to the IoT device through the buffer function, the service instruction is decapsulated; or when transmitting the service data to the application layer through the buffer function, the service data is encapsulated.

3. The middleware according to claim 1, characterized in that, The specific protocol adaptation layer is also used for: A mutex lock is created for each communication port corresponding to the IoT device. The mutex lock is used to set the communication port to a first flag when communication is being performed and to a second flag when the port is idle.

4. The middleware according to any one of claims 1 to 3, characterized in that, The middleware also includes: a protocol plugin management module; The protocol plugin management module is used to realize communication between the application layer and the server through a preset dynamic link library. The preset dynamic link library includes application programming interface (API) functions corresponding to multiple server communication protocols.

5. The middleware according to any one of claims 1 to 3, characterized in that, The middleware also includes: a log management module; The log management module is used to collect, store, and output runtime logs generated during the middleware's runtime.

6. The middleware according to any one of claims 1 to 3, characterized in that, The middleware also includes: a tool library module; The tool library module is used to provide general tool functions for the middleware.

7. An Internet of Things (IoT) system, characterized in that, The Internet of Things (IoT) system includes: an application layer, IoT devices, and middleware as described in any one of claims 1-6.

Images