Method and apparatus for developing internet of things components

Abstract

The application discloses a kind of development method and device of internet of things component, and the present application relates to internet of things and communication field, including: according to the interactive mode and data format of the communication data interface agreed by internet of things equipment and cloud platform, the protocol description file corresponding to the internet of things equipment is built;According to the protocol description file and the business rules involved in each internet of things component between the internet of things equipment and the cloud platform, the business code corresponding to each internet of things component is generated;According to the communication mode and data flow direction of communication data in each internet of things component, the data flow code corresponding to each internet of things component is determined;The business code and the data flow code are merged, and the function of each internet of things component is realized.By applying the technical solution of the present application, the business processing logic and data flow processing logic of internet of things component can be decoupled, so that the development efficiency of internet of things component can be improved.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) and communications, and more specifically, to a method and apparatus for developing IoT components. Background Technology

[0002] As of 2020, there were 11.7 billion IoT devices worldwide, surpassing non-IoT devices for the first time. Although the "Internet of Everything" has entered a period of rapid development, the IoT as a whole still exhibits fragmented characteristics. This fragmentation is mainly reflected in the long data transmission chain between IoT devices and cloud platforms, which involves multiple IoT components.

[0003] Currently, in the development of IoT components, business logic is typically embedded within data stream processing logic. However, because this approach results in tight coupling between business logic and data stream processing logic, changes to the data stream processing logic necessitate the redevelopment of the business logic as well, making reuse impossible and leading to low development efficiency for IoT components. Summary of the Invention

[0004] This invention provides a method and apparatus for developing Internet of Things (IoT) components, which mainly decouples the business processing logic and data flow processing logic of IoT components, thereby improving the development efficiency of IoT components.

[0005] According to a first aspect of the present invention, a method for developing an Internet of Things (IoT) component is provided, comprising:

[0006] Based on the interaction method and data format of the communication data interface agreed upon by the IoT device and the cloud platform, construct the protocol description file corresponding to the IoT device;

[0007] Based on the protocol description file and the business rules involved in each IoT component between the IoT device and the cloud platform, generate the business code corresponding to each IoT component;

[0008] Based on the communication method and data flow direction within each IoT component, determine the data flow code corresponding to each IoT component;

[0009] The business code and the data flow code are merged to realize the functions of each IoT component.

[0010] According to a second aspect of the present invention, an apparatus for developing Internet of Things (IoT) components is provided, comprising:

[0011] The construction unit is used to construct the protocol description file corresponding to the IoT device according to the interaction method and data format of the communication data interface agreed upon by the IoT device and the cloud platform.

[0012] The generation unit is used to generate business code corresponding to each IoT component based on the protocol description file and the business rules involved in each IoT component between the IoT device and the cloud platform.

[0013] The generation unit is also used to determine the data flow code corresponding to each IoT component based on the communication method and data flow direction of the communication data within each IoT component;

[0014] The merging unit is used to merge the business code and the data flow code to realize the functions of each IoT component.

[0015] According to a third aspect of the present invention, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, performs the following steps:

[0016] Based on the interaction method and data format of the communication data interface agreed upon by the IoT device and the cloud platform, construct the protocol description file corresponding to the IoT device;

[0017] Based on the protocol description file and the business rules involved in each IoT component between the IoT device and the cloud platform, generate the business code corresponding to each IoT component;

[0018] Based on the communication method and data flow direction within each IoT component, determine the data flow code corresponding to each IoT component;

[0019] The business code and the data flow code are merged to realize the functions of each IoT component.

[0020] According to a fourth aspect of the present invention, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to perform the following steps:

[0021] Based on the interaction method and data format of the communication data interface agreed upon by the IoT device and the cloud platform, construct the protocol description file corresponding to the IoT device;

[0022] Based on the protocol description file and the business rules involved in each IoT component between the IoT device and the cloud platform, generate the business code corresponding to each IoT component;

[0023] Based on the communication method and data flow direction within each IoT component, determine the data flow code corresponding to each IoT component;

[0024] The business code and the data flow code are merged to realize the functions of each IoT component.

[0025] The innovative aspects of this invention include:

[0026] 1. Decoupling the business processing logic and data flow processing logic of each IoT component to avoid repetitive development is one of the innovations of this invention.

[0027] 2. When business changes occur, the business code of each component can be automatically generated according to the protocol description file of the IoT device, eliminating the need for manual coding and improving development efficiency. This is one of the innovations of this invention.

[0028] 3. Using simulation tools to load the same protocol description file to generate simulated IoT devices and simulated cloud platforms, and realizing the embedded decoupled development of cloud platforms and IoT devices through simulated IoT devices and simulated cloud platforms is one of the innovations of this invention.

[0029] The present invention provides a development method and apparatus for IoT components. Compared with the existing technology of embedding business processing logic and data flow processing logic in IoT components, this invention can construct a protocol description file corresponding to the IoT device based on the interaction method and data format of the communication data interface agreed upon by the IoT device and the cloud platform. Based on the protocol description file and the business rules involved in each IoT component between the IoT device and the cloud platform, business code corresponding to each IoT component is generated. At the same time, based on the communication method and data flow direction of the communication data within each IoT component, the data flow code corresponding to each IoT component is determined. Finally, the business code and the data flow code are merged to realize the function of each IoT component. Therefore, this invention decouples the business processing logic and data flow processing logic of each IoT component by generating separate data flow code and business code for each IoT component. This avoids the need to redevelop business code when the data flow changes, thereby improving the development efficiency of IoT components. At the same time, this invention uses a protocol description file to define the communication data format between IoT devices and the cloud platform, which standardizes the data interface of IoT devices and enables interconnection between IoT devices. Furthermore, this invention can automatically generate the business code of each IoT component based on the protocol description file, avoiding manual coding when business changes occur, thereby further improving development efficiency.

[0030] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

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

[0032] Figure 1 A schematic diagram of a development method for an Internet of Things (IoT) component provided by an embodiment of the present invention is shown.

[0033] Figure 2 A schematic diagram of the communication protocol data format provided in an embodiment of the present invention is shown;

[0034] Figure 3 A schematic diagram of the data flow and service separation architecture provided by an embodiment of the present invention is shown;

[0035] Figure 4 A schematic diagram of the middleware workflow provided in an embodiment of the present invention is shown;

[0036] Figure 5 This diagram illustrates the middleware data receiving execution flow provided in an embodiment of the present invention.

[0037] Figure 6 This diagram illustrates the middleware encapsulation and data synchronization process provided in an embodiment of the present invention.

[0038] Figure 7 A schematic diagram of the storage structure of the setting frame provided in an embodiment of the present invention is shown;

[0039] Figure 8 This diagram illustrates the front-end and back-end component architecture provided in an embodiment of the present invention.

[0040] Figure 9 This diagram illustrates the joint development of a cloud platform and IoT devices according to an embodiment of the present invention.

[0041] Figure 10 This diagram illustrates the association between the simulated device and the real device provided in an embodiment of the present invention.

[0042] Figure 11 This diagram illustrates the decoupling development of cloud platform and IoT devices provided in an embodiment of the present invention.

[0043] Figure 12 This diagram illustrates the data flow of a simulated Internet of Things (IoT) device according to an embodiment of the present invention.

[0044] Figure 13 A schematic diagram of the operating interface of a simulated Internet of Things (IoT) device provided in an embodiment of the present invention is shown;

[0045] Figure 14 This diagram illustrates the data flow of a simulated cloud platform provided in an embodiment of the present invention.

[0046] Figure 15 A schematic diagram of the operating interface of the simulated cloud platform provided in an embodiment of the present invention is shown;

[0047] Figure 16 The diagram shows a structural schematic of a development apparatus for an Internet of Things (IoT) component provided in an embodiment of the present invention. Detailed Implementation

[0048] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0049] It should be noted that the terms "comprising" and "having," and any variations thereof, in the embodiments and drawings of this invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0050] Currently, due to the severe coupling between the business processing logic and data stream processing logic of IoT components, when the data stream processing logic changes, the business processing logic also needs to be redeveloped and cannot be reused, which leads to low development efficiency of IoT components.

[0051] To address the aforementioned problems, embodiments of the present invention provide a method for developing Internet of Things (IoT) components, such as... Figure 1 As shown, the method includes:

[0052] Step 101: Construct the protocol description file corresponding to the IoT device based on the interaction method and data format of the communication data interface agreed upon by the IoT device and the cloud platform.

[0053] Among them, IoT devices use binary protocols in the network, and the protocol description file is used to describe the binary protocols of IoT devices.

[0054] This invention is primarily applicable to scenarios where business processing logic and data stream processing logic are decoupled during the development of IoT components. The executing entity of this invention is a device or equipment capable of generating IoT components.

[0055] Due to the diversity of IoT devices, it is difficult to achieve a unified interface and programming environment for upper-layer software development based on different operating systems. When multiple devices want to interconnect across systems, significant integration difficulties arise. Therefore, this embodiment of the invention uses protocol description files to standardize the interfaces of various IoT devices on the network. Furthermore, since IoT devices typically use binary protocols in networks, which suffer from drawbacks such as unreadableness and poor scalability, this embodiment of the invention uses protocol description files to describe the binary protocols of IoT devices, thus overcoming these problems.

[0056] For the protocol description file construction process of IoT devices, step 101 specifically includes: determining the message reporting method corresponding to different types of messages based on the interaction method of the communication data interface jointly agreed upon by the IoT device and the cloud platform; defining the identifier, position, data type, decoding function, and encoding function corresponding to each field in the different types of messages based on the data format of the communication data interface jointly agreed upon by the IoT device and the cloud platform; and constructing the protocol description file corresponding to the IoT device based on the message reporting method and the identifier, position, data type, decoding function, and encoding function corresponding to each field in the different types of messages.

[0057] Specifically, message classification and message fragmentation are the most critical parts in designing a custom binary protocol. For message classification, the message header format is consistent across different message types. The message header mainly includes four parts: message length, message ID, destination / source device ID, and type, such as... Figure 2 As shown, the part before the vertical line is the message header, which is... Figure 2 It can be observed that the message header formats of data frames, setting frames, and command frames are identical. Since the middleware used for receiving and forwarding messages employs a message queue, as long as the message length does not exceed the metadata limit, it can be parsed according to its actual length. Figure 2 The message length, target / source device ID, and type are not currently displayed.

[0058] Furthermore, the business modules were analyzed to determine the protocol content (fields), frame attributes (control, read, write, etc.), and upload frequency involved in different message types. This determined the message reporting methods corresponding to different message types, as shown in Table 1.

[0059] Table 1. Message reporting methods for different message types

[0060]

[0061] Furthermore, based on the data format of the communication data interface agreed upon between IoT devices and the cloud platform, the data format of each field involved in different types of messages is defined, that is, the unique ID, position (off, length), data type (type), decoding function (pro2ui), and encoding function (ui2pro) of each field are defined, as shown in Tables 2 and 3. Table 2 is... Figure 2 The data format descriptions corresponding to the data frames in Table 3 are as follows: Figure 2 The data format description corresponding to the frame is set in the middle.

[0062] Table 2 describes the data format corresponding to the data frames.

[0063]

[0064]

[0065] Table 3 describes the data format corresponding to the data frames.

[0066]

[0067] Furthermore, for message fragmentation, the data format defined above forms a message fragmentation mechanism. Different types of messages correspond to different fragmentation mechanisms. When an IoT component receives a message, it can send it to the correct message fragmentation mechanism according to the message ID in the message header. For example, if the message ID in the message header of a certain message is 70, it will be sent to the fragmentation mechanism defined in Table 2.

[0068] Therefore, by defining the message reporting methods and data format descriptions corresponding to different types of messages in the above manner, it is possible to construct the protocol description files corresponding to IoT devices, so as to standardize the interfaces of IoT devices and realize the interconnection between IoT devices.

[0069] In addition, embodiments of the present invention can also use software tools, such as lucky-Tools, to edit and manage the protocol description files of IoT devices. Through the protocol description files and software tools, unreadable binary protocols can be visualized.

[0070] Step 102: Generate the business code corresponding to each IoT component based on the protocol description file and the business rules involved in each IoT component between the IoT device and the cloud platform.

[0071] Among them, the various IoT components between IoT devices and the cloud platform include middleware, storage components, and front-end and back-end components (cloud platform components).

[0072] To avoid repetitive development, this embodiment of the invention decouples the implementation functions of middleware, storage components, and front-end and back-end components. Specifically, it separates the data flow code and business logic code of each IoT component. This separation can be achieved by generating separate data flow code and business logic code for each component. The data flow code primarily implements the logical flow and changes of data within the system from the perspective of data transmission and processing, without involving data business logic. The business logic code, on the other hand, focuses on the actual data business logic and is responsible for the functions the entire system must implement, such as setting the sampling frequency; it does not involve the logical flow of data. By merging the separately generated data flow code and business logic code, the component functions can be realized. Figure 3 A separate architecture for data flow and business logic.

[0073] For business code, since simple business additions and deletions can be reflected in the protocol description file, the protocol description file can be used to automatically generate business code corresponding to each IoT component. Based on this, the method includes: generating business code corresponding to the middleware according to the protocol description file and the format conversion rules of the middleware; generating business code corresponding to the storage component according to the protocol description file and the CRUD rules of the storage component; and generating business code corresponding to the front-end and back-end components according to the protocol description file and the page operation rules of the front-end and back-end components.

[0074] Specifically, the middleware's functions mainly include two parts: first, receiving status frames, data frames, and setting / read frames from IoT devices, parsing them, and then storing them in the storage component; second, receiving control commands and setting / write commands from the cloud platform, encapsulating them, sending them to various IoT devices, and synchronizing the setting commands to the storage component, such as... Figure 4 As shown. The business logic code is primarily responsible for converting binary data to text-formatted data (JSON data).

[0075] In specific application scenarios, when the middleware receives a message from an IoT device, it automatically identifies the corresponding data format from the protocol description file using the message ID in the message header. It then parses the binary message into text format according to this format and writes it to the database. The backend service can then obtain the latest data by querying the business logic. The overall process is as follows: Figure 5 As shown. In this process, the data format is identified through the message header, and the binary message is parsed into text format according to this data format. This is the processing logic for the business agent, and the data is written to the database as the processing logic for the data flow code. The code for the overall middleware processing flow is as follows:

[0076]

[0077] The above overall process is the processing logic of the data flow code. During the execution of the data flow code, the business code module protocol_dict[protocalID] is called. Therefore, it can be seen that the middleware's business code is not embedded in the data flow code, but is called by the data flow code as a whole module.

[0078] Furthermore, the middleware can also receive control commands and write commands in text format from the cloud platform. On one hand, it identifies the data format through the message header, encapsulates the text-formatted data into binary data according to the specified format, and sends it to different IoT devices. On the other hand, it synchronizes the text-formatted data to the database. The overall process is as follows: Figure 6 As shown. In this process, the data format is identified through the message header, and the text-formatted data is encapsulated into binary data according to this format—this is the processing logic of the business code. The encapsulated data is sent to different IoT devices, and the text-formatted data is synchronized to the database—this is the processing logic of the data stream code. The overall middleware processing flow code is as follows:

[0079]

[0080] The above overall process is the processing logic of the data flow code. During the execution of the data flow code, the business code module protocol_dict[protocolID] is called. Therefore, it can be seen that the middleware's business code is not embedded in the data flow code, but is called by the data flow code as a whole module.

[0081] Furthermore, for storage components, the business logic involved mainly includes table creation, querying, insertion, batch insertion, modification, and historical data processing strategies. The content that needs to be stored between the cloud platform and IoT devices primarily consists of read / write frames, namely data frames and setting frames.

[0082] For the business code that creates tables, since the data format description of the setup frame corresponds one-to-one with the table fields of the setup frame, the database table structure corresponding to the setup frame can be automatically generated through the protocol description file, including field names and field types. Taking MySQL database as an example, the database table information corresponding to the setup frame is generated using the data format of the setup frame, such as... Figure 7 As shown. Because the data format description of the data frame does not correspond one-to-one with the table fields of the corresponding data frame, the business code cannot directly generate data table information based on the data format of the data frame. Further parsing and calculation are required to obtain the table results.

[0083] For query business code, the query process for both data frames and setting frames is the same as in regular BI. For insertion business code, when inserting, setting frames call the middleware to insert according to the destination ID primary key, while data frames call the middleware to insert according to both the destination ID and time. For batch insertion business code, the reporting method of setting frames during batch insertion is not periodic and does not involve batch insertion. Data frames, during batch insertion, are used as an insertion strategy for some storage components, such as HBase, where accumulated data is inserted all at once when a certain amount or time has passed. For modification business code, when modifying, setting frames modify the parameters under the primary key according to the primary key; data frames do not support modification.

[0084] By automatically generating business code for storage components through device description files, storage components can provide a consistent interface to the outside world. On the one hand, it can effectively utilize the user's existing framework for storage and management and adapt to its storage components; on the other hand, it can easily switch storage engines according to the number of user devices.

[0085] Furthermore, for the front-end and back-end components, the code involves many pages and interfaces, mainly including three parts: the device list page / interface, the data list page / interface, and the data access page / interface. The overall architecture is as follows: Figure 8 As shown.

[0086] The main functions of the device list page / interface include: list display, echo, and setting sub-settings. List display primarily involves transmitting structured setting data from the backend storage component to the frontend for visualization. This mainly includes two interfaces: a database access interface and a frontend-backend API interface. The database access interface uses a data generation database, while the frontend-backend API interface uses a JSON text protocol, representing the device list using a dynamic table structure. Echoing is primarily handled by the frontend. When setting sub-settings, the frontend sends user adjustments (control operations) to the backend in text format. The backend synchronizes this text data to the database and also encapsulates it before sending it to the IoT devices. This part mainly uses the backend to control the frontend's control display. Based on the received control descriptions, the frontend generates dynamic sub-setting interfaces for the available device list.

[0087] For the data list page / interface, its functions include list display, dropdown navigation, and control delivery. Data list display is the same as device list display and will not be described further. Dropdown navigation allows users to navigate to dropdown interfaces obtained from the front-end. Control delivery involves the front-end sending user control commands (control operations) to the back-end in text format. The back-end synchronizes this text data to the database and simultaneously encapsulates it before sending it to the IoT device. The operation of the control commands is the same as the settings section and is dynamically displayed.

[0088] Step 103: Determine the data flow code corresponding to each IoT component based on the communication method and data flow direction of the communication data within each IoT component.

[0089] In this embodiment of the invention, the data flow code of each IoT component can be determined from the perspective of data transmission and data processing, based on the logical flow direction and communication method of data within each IoT component. This data flow code does not involve business operations.

[0090] Step 104: Merge the business code and the data flow code to realize the functions of each IoT component.

[0091] In one embodiment of the present invention, after separating the business code and data stream code of each IoT component, when the processing logic of the data stream changes (such as a change in the communication method), only the data stream code of each IoT component needs to be modified, without reconstructing the business code. Based on this, the method includes: updating the data stream code of each IoT component when the communication method of the IoT device changes; and merging the updated data stream code with the business code to realize the function of each IoT component.

[0092] For example, if the communication method of an IoT device is changed from RS-485 communication to MQTT communication, since only the communication method is changed and the business logic remains the same, only the data stream code needs to be modified and the same business logic code needs to be called.

[0093] In one embodiment of the present invention, since the addition or deletion of services can be represented by changes in the protocol description file, when services change, the present invention can automatically generate protocol description files for each IoT component based on the updated protocol description file, without the need to manually edit the service code of each IoT component sequentially. Based on this, the method includes: updating the protocol description file corresponding to the IoT device when the services of the IoT device change; regenerating the service code corresponding to each IoT component based on the updated protocol description file and the service rules involved in each IoT component; and merging the regenerated service code with the data flow code to realize the function of each IoT component.

[0094] For example, when adding a sampling frequency setting function to an IoT device, since it only involves changes to the business logic, the data stream processing logic does not need to be modified. When regenerating the business code, the IoT software needs to add a sampling period for the acquisition channel adjusted according to the sampling frequency; the middleware needs to convert the data frames corresponding to the sampling frequency between binary and text formats; the database needs to add storage for the sampling frequency; the backend needs to add CRUD operations and send data related to the sampling frequency; and the frontend needs to add sampling frequency setting and echoing at the corresponding locations.

[0095] Currently, cloud platforms and IoT devices typically adopt a joint development model, such as... Figure 9 As shown, the cloud platform requires IoT devices to provide complete data interfaces and verifies the correctness of commands and settings issued by them. In turn, the IoT devices need the cloud platform to visualize and analyze their data, and control and configure them through the cloud platform. During development, the cloud platform and IoT devices jointly agree on the interaction method and data format of the data interface, then implement parallel development of the front-end and back-end. After the basic functions are completed, joint debugging and testing begin, followed by functional testing. Because the above joint development process relies entirely on verbal agreements, numerous inconsistencies and version issues are prone to occur during joint debugging.

[0096] To overcome the above problems, embodiments of the present invention, during the development process, load the protocol description file of an IoT device using simulation software to form a simulated cloud platform and a simulated IoT device, such as... Figure 10As shown, cloud platform developers can develop for the cloud platform by simulating IoT devices as data sources without hardware, while embedded developers can debug the IoT devices to be developed by simulating the cloud platform. This enables decoupled development of IoT components and the cloud platform. Figure 11 As shown, since the simulated IoT devices and the simulated cloud platform use the same protocol description file during decoupled development, their interfaces are consistent. This ensures that the real IoT devices and the real cloud platform can be matched during joint debugging, and there will be no version inconsistency issues.

[0097] In the process of independently developing a cloud platform, the method includes: using a simulation tool to load the protocol description file corresponding to the IoT device to generate a simulated IoT device; the simulated IoT device pushes data to the middleware in each IoT component; the simulated IoT device receives messages from the middleware and parses and displays the messages; and develops the cloud platform based on the data push results and message display results.

[0098] The specific simulation tool can be lucky-Tools. By enabling the Simulator function of lucky-Tools and loading the protocol description file of the IoT device, the network interface of the IoT device can be simulated, enabling rapid development of protocol cloud platforms, desktop software, or third-party software.

[0099] In the process of developing a cloud platform using simulated IoT devices, the simulated IoT devices have the same external interface as real IoT devices. The simulated IoT devices provide data sources for the development of other components and verify the parsing of messages sent by other components.

[0100] Simulate data flow of IoT devices, such as Figure 12 As shown, the shaded area represents the loaded protocol description file. The simulated IoT device mainly consists of one process (the main process) and two threads (the receiving thread and the sending thread). The receiving thread receives messages from the middleware, then calls back to the main process's parsing module, sending the parsed text-formatted data to the main process's visualization module. The sending thread receives the text data to be sent from the main process's visualization module, encapsulates the text data into binary data through the encapsulation module, and then sends it to the message middleware. The main process primarily handles the management of the management thread and the protocol visualization. Protocol visualization mainly involves visualizing the protocol content, including numerical visualization and control visualization.

[0101] Furthermore, the operating interface of simulated IoT devices, such as Figure 13As shown, using simulated IoT devices can mimic the status frames and data frames sent by real edge computing devices, enabling cloud platforms or desktop software to receive and verify the data. Furthermore, simulated IoT devices can also be used to verify commands issued by cloud platforms or desktop software. Figure 13 In the table, button A1 is used to load protocol description files for different IoT devices. After loading a protocol description file, its contents will appear in the table area on the right. Button A2 can be used to input the middleware to be connected and add the simulated IoT device to the network. Button B1 is used to control the activation and deactivation of the simulated IoT device. Button B2 is used to send trigger frames from the protocol description file (the frequency column is the trigger), such as setting the frame reading. Button C1 is used to edit the transmission process of each frame of data of the IoT device (such as whether to transmit, whether to transmit periodically) and the reporting frequency (the transmission frequency when transmitting periodically). The C2 area is used to display the messages received by the simulated IoT device.

[0102] In the process of independently developing IoT devices, the method includes: using a simulation tool to load the protocol description file corresponding to the IoT device to generate a simulated cloud platform; displaying the transmission data of the online IoT device in the running interface of the simulated cloud platform; sending a setting command to the online IoT device according to the running interface of the simulated cloud platform; and developing the online IoT device based on the display result of the transmission data and the sending result of the setting command.

[0103] The simulation tool can be lucky-Tools. By enabling the PollTest function of lucky-Tools to load the protocol description file of the IoT device, data visualization, display, and settings can be performed on a single IoT device or multiple IoT devices according to the single-frame protocol.

[0104] In the process of developing IoT devices using a simulated cloud platform, the simulated cloud platform has the same external interface as the real cloud platform, and the simulated cloud platform can realize all the native functions of the real cloud platform. It can visualize the status and data of different IoT devices, and can issue commands and settings to different IoT devices.

[0105] Data flow of the simulated cloud platform, such as Figure 14As shown, the shaded area represents the loaded protocol description file. The simulated cloud platform mainly consists of one main process and two threads (the receive thread and the send thread). The receive thread receives messages from the middleware, then calls back to the main process's parsing module to send the parsed text data to the main process's visualization module. The send thread receives the text format data to be sent from the main process's visualization module, encapsulates the text format data into binary data through the encapsulation module, and then sends it to the middleware. The main process primarily handles the management of the management thread and the protocol visualization. Protocol visualization mainly involves visualizing the protocol content, including numerical visualization, control visualization, and image visualization.

[0106] Furthermore, the simulated cloud platform's operating interface is as follows: Figure 15 As shown, Figure 15 (A) is used to display all protocol frames after the loading protocol description file, where the active column is used to display the number of devices sending messages under this frame; Figure 15 (B) is Figure 15 (A) A drop-down page at a certain setting frame contains all the controls for setting the write frame. Different IoT devices can be selected as setting or command targets by using the B.2 device switching button, and settings or commands can be issued by using the B.3 button. Figure 15 (C) is Figure 15 (A) The drop-down page at a certain data frame contains a visualization of all the metrics and data of that data frame. The device switching button in C.2 allows you to select different IoT devices to display the settings and reading information. The refresh data button in C.3 allows you to refresh the latest metrics of different IoT devices. Figure 15 (E) is Figure 15 (C) On the page below a certain Data location, the binary block Data can be parsed, calculated, and visualized; Figure 15 (D) is Figure 15 (A) The drop-down page at a certain data frame contains all the controls for setting the write frame. The device switching button D.2 can be used to select different IoT devices to display the settings and read information. The refresh data button D.3 can be used to refresh the latest settings of different IoT devices.

[0107] By using simulation tools and protocol description files, this invention can quickly simulate the interface functions of IoT devices, enabling complete decoupling of cloud platform and IoT device development and avoiding numerous inconsistencies during joint debugging.

[0108] It should be noted that the entity used for decoupling development from IoT devices in this embodiment of the invention is not limited to cloud platforms, but can also be other desktop software.

[0109] This invention provides a method for developing IoT components. By generating separate data flow code and business code for each IoT component, the business processing logic and data flow processing logic of each IoT component can be decoupled. This avoids the need to redevelop business code when the data flow changes, thereby improving the development efficiency of IoT components. Simultaneously, this invention uses a protocol description file to define the communication data format between IoT devices and the cloud platform, which standardizes the data interface of IoT devices and enables interconnection between them. Furthermore, this invention can automatically generate the business code of each IoT component based on the protocol description file, avoiding manual editing when business logic changes, thereby further improving development efficiency.

[0110] Furthermore, as Figure 1 In specific implementation, embodiments of the present invention provide a development apparatus for Internet of Things (IoT) components, such as... Figure 16 As shown, the device includes: a construction unit 31, a generation unit 32, and a merging unit 33.

[0111] The construction unit 31 can be used to construct the protocol description file corresponding to the IoT device according to the interaction method and data format of the communication data interface agreed upon by the IoT device and the cloud platform.

[0112] The generation unit 32 can generate business code corresponding to each IoT component based on the protocol description file and the business rules involved in each IoT component between the IoT device and the cloud platform.

[0113] The generation unit 32 can also be used to determine the data flow code corresponding to each IoT component based on the communication method and data flow direction of the communication data within each IoT component.

[0114] The merging unit 33 can be used to merge the business code and the data flow code to realize the functions of each IoT component.

[0115] In a specific application scenario, the construction unit 31 includes: a first determining module, a defining module, and a construction module.

[0116] The first determining module can be used to determine the message reporting method corresponding to different types of messages based on the interaction method of the communication data interface agreed upon by the IoT device and the cloud platform.

[0117] The definition module can be used to define the identifier, position, data type, decoding function, and encoding function corresponding to each field in the different types of messages, according to the data format of the communication data interface agreed upon by the IoT device and the cloud platform.

[0118] The construction module can be used to construct the protocol description file corresponding to the IoT device based on the message reporting method and the identifier, position, data type, decoding function and encoding function corresponding to each field in the different types of messages.

[0119] In specific application scenarios, the various IoT components include middleware, storage components, and front-end and back-end components. The generation unit 32 can be specifically used to generate business code corresponding to the middleware according to the protocol description file and the format conversion rules of the middleware; generate business code corresponding to the storage component according to the protocol description file and the CRUD rules of the storage component; and generate business code corresponding to the front-end and back-end components according to the protocol description file and the page operation rules of the front-end and back-end components.

[0120] In specific application scenarios, the device further includes an update unit.

[0121] The update unit can be used to update the data stream code of each IoT component when the communication method of the IoT device changes.

[0122] The merging unit 33 can also be used to merge the updated data stream code with the business code to realize the functions of each IoT component.

[0123] In specific application scenarios, the update unit can also be used to update the protocol description file corresponding to the IoT device when the business of the IoT device changes.

[0124] The generation unit 32 can also be used to regenerate the business code corresponding to each IoT component based on the updated protocol description file and the business rules involved in each IoT component.

[0125] The merging unit 33 can also be used to merge the regenerated business code and the data flow code to realize the functions of each IoT component.

[0126] In specific application scenarios, the device further includes a display unit, a transmission unit, and a development unit.

[0127] The generation unit can also be used to load the protocol description file corresponding to the IoT device using a simulation tool to generate a simulated cloud platform.

[0128] The display unit can be used to display the transmission data of online IoT devices in the operating interface of the simulated cloud platform.

[0129] The sending unit can be used to send setting commands to the online IoT devices according to the operating interface of the simulated cloud platform.

[0130] The development unit can be used to develop the online IoT device based on the display results of the transmitted data and the sending results of the setting command.

[0131] In specific application scenarios, the generation unit can also be used to load the protocol description file corresponding to the IoT device using a simulation tool to generate a simulated IoT device.

[0132] The sending unit can also be used to push data from the simulated IoT device to the middleware in each IoT component.

[0133] The display unit can also be used for the simulated IoT device to receive messages from the middleware, and to parse and display the messages from the middleware.

[0134] The development unit can also be used to develop the cloud platform based on the data push results and message display results.

[0135] It should be noted that other corresponding descriptions of the functional modules involved in the development apparatus for an IoT component provided in this embodiment of the invention can be found in [reference needed]. Figure 1 The corresponding description of the method shown will not be repeated here.

[0136] Based on the above, Figure 1 Accordingly, this embodiment of the invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the following steps: constructing a protocol description file corresponding to the IoT device based on the interaction method and data format of the communication data interface jointly agreed upon by the IoT device and the cloud platform; generating business codes corresponding to each IoT component based on the protocol description file and the business rules involved in each IoT component between the IoT device and the cloud platform; determining the data flow code corresponding to each IoT component based on the communication method and data flow direction of the communication data within each IoT component; and merging the business code and the data flow code to realize the function of each IoT component.

[0137] Based on the above, Figure 1 The method shown and as Figure 16According to the embodiment of the device shown, this embodiment of the invention also provides an electronic device, which includes: a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein both the memory and the processor are mounted on a bus. When the processor executes the program, it performs the following steps: constructing a protocol description file corresponding to the IoT device according to the interaction method and data format of the communication data interface agreed upon by the IoT device and the cloud platform; generating business codes corresponding to each IoT component according to the protocol description file and the business rules involved in each IoT component between the IoT device and the cloud platform; and determining the data flow code corresponding to each IoT component according to the communication method and data flow direction of the communication data within each IoT component.

[0138] The business code and the data flow code are merged to realize the functions of each IoT component.

[0139] This invention, by generating separate business code and development data flow code for each IoT component, decouples the business processing logic and data flow processing logic of each IoT component. This avoids the need to redevelop business code when the data flow changes, thereby improving the development efficiency of IoT components. Simultaneously, this invention uses a protocol description file to define the communication data format between IoT devices and the cloud platform, standardizing the data interfaces of IoT devices and enabling interconnection between them. Furthermore, this invention automatically generates the business code for each IoT component based on the protocol description file, avoiding manual editing when business logic changes, further improving development efficiency.

[0140] Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of one embodiment, and the modules or processes shown in the drawings are not necessarily essential for implementing the present invention.

[0141] Those skilled in the art will understand that the modules in the apparatus of the embodiments can be distributed in the apparatus of the embodiments as described in the embodiments, or they can be located in one or more devices different from this embodiment with corresponding changes. The modules of the above embodiments can be combined into one module, or they can be further divided into multiple sub-modules.

[0142] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention 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; and these 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 the present invention.

Claims

1. A method for developing an Internet of Things (IoT) component, characterized in that, include: Based on the interaction method and data format of the communication data interface agreed upon by the IoT device and the cloud platform, construct the protocol description file corresponding to the IoT device; Based on the protocol description file and the business rules involved in each IoT component between the IoT device and the cloud platform, generate the business code corresponding to each IoT component; Based on the communication method and data flow direction within each IoT component, determine the data flow code corresponding to each IoT component; The business code and the data flow code are merged to implement the functions of each IoT component; The step of constructing a protocol description file corresponding to the IoT device based on the interaction method and data format of the communication data interface jointly agreed upon by the IoT device and the cloud platform includes: Based on the interaction method of the communication data interface agreed upon by the IoT device and the cloud platform, the message reporting method corresponding to different types of messages is determined; Based on the data format of the communication data interface agreed upon by the IoT device and the cloud platform, define the identifier, position, data type, decoding function, and encoding function corresponding to each field in the different types of messages; Based on the message reporting method and the identifier, location, data type, decoding function, and encoding function corresponding to each field in the different types of messages, construct the protocol description file corresponding to the IoT device.

2. The method according to claim 1, characterized in that, The various IoT components include middleware, storage components, and front-end and back-end components. The step of generating business code corresponding to each IoT component based on the protocol description file and the business rules involved in the various IoT components between the IoT device and the cloud platform includes: Based on the protocol description file and the format conversion rules of the middleware, generate the business code corresponding to the middleware; Based on the protocol description file and the CRUD rules of the storage component, generate the business code corresponding to the storage component; Based on the protocol description file and the page operation rules of the front-end and back-end components, the corresponding business code of the front-end and back-end components is generated.

3. The method according to claim 1, characterized in that, The method further includes: When the communication method of the IoT device changes, the data stream code of each IoT component is updated; The updated data stream code is merged with the business code to implement the functions of each IoT component.

4. The method according to claim 1, characterized in that, The method further includes: When the services of the IoT device change, the protocol description file corresponding to the IoT device is updated; Based on the updated protocol description file and the business rules involved in each IoT component, the business code corresponding to each IoT component is regenerated; The regenerated business code and the data flow code are merged to implement the functions of each IoT component.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: A simulated cloud platform is generated by loading the protocol description file corresponding to the IoT device using a simulation tool. The simulated cloud platform displays the transmission data of online IoT devices in its operating interface; Based on the operating interface of the simulated cloud platform, setting commands are sent to the online IoT devices; The online IoT device is developed based on the display results of the transmitted data and the sending results of the setting command.

6. The method according to any one of claims 1-4, characterized in that, The method further includes: The protocol description file corresponding to the IoT device is loaded using a simulation tool to generate a simulated IoT device; The simulated IoT device pushes data to the middleware in each IoT component; The simulated IoT device receives messages from the middleware, and parses and displays the messages from the middleware; The cloud platform was developed based on the data push results and message display results.

7. A development apparatus for an Internet of Things (IoT) component, characterized in that, include: The construction unit is used to construct the protocol description file corresponding to the IoT device according to the interaction method and data format of the communication data interface agreed upon by the IoT device and the cloud platform. The generation unit is used to generate business code corresponding to each IoT component based on the protocol description file and the business rules involved in each IoT component between the IoT device and the cloud platform. The generation unit is also used to determine the data flow code corresponding to each IoT component based on the communication method and data flow direction of the communication data within each IoT component; A merging unit is used to merge the business code and the data flow code to realize the functions of each IoT component; The construction unit includes: a first determining module, a defining module, and a construction module; The first determining module is used to determine the message reporting method corresponding to different types of messages based on the interaction method of the communication data interface agreed upon by the IoT device and the cloud platform. The definition module is used to define the identifier, position, data type, decoding function and encoding function corresponding to each field in the different types of messages according to the data format of the communication data interface agreed upon by the IoT device and the cloud platform. The construction module is used to construct the protocol description file corresponding to the IoT device based on the message reporting method and the identifier, position, data type, decoding function and encoding function corresponding to each field in the different types of messages.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images