Ubiquitous object interaction interface method for pan-manufacturing and edge computing

Abstract

The present invention provides a method for connecting ubiquitous objects to data and networks to support electronic and networked access control and edge computing. Here, ubiquitous objects refer to personnel, objects, instruments and equipment, electronic data, and computer software that are intended to be connected to an information system for operational access. Using this method, an interface in software form, hardware form, or a hybrid of software and hardware can be constructed and applied to the Internet of Things, Industrial Internet, intelligent control, pan-manufacturing, and edge computing. This method implements various functions required for operational access to ubiquitous objects based on message and event processing, and separates the processing logic into three description methods: basic logic, message generation, and message scheduling. Through the dynamic combination of hooks, the network communication, status publishing, data publishing, service provision, behavioral intelligent control, collaborative-based pan-manufacturing, and edge computing of ubiquitous objects are realized. Business logic.

Description

Technical Field

[0001] The invention belongs to the field of software engineering and relates to a construction method of a supporting environment and tools for Internet of Things applications. Background Art

[0002] With the advent of Industrial Revolution 4.0, new requirements have been put forward for information technology. Standards and technologies such as Industrial Internet, intelligent manufacturing, intelligent robots, Industry 4.0, and Industry 2025 have received attention. To support these new demands, pan-manufacturing is the main way.

[0003] Ubiquitous manufacturing is an important business system realized by the hybridization of ubiquitous objects. In short, ubiquitous objects can be summarized as people, things, machines, numbers, and software. Among them, people and things refer to objects without electronic data interfaces, which belong to "things not connected to the Internet" objects. Machines refer to instruments, equipment and tools that can carry electronic digital interfaces, numbers refer to electronic data, and software refers to computer software systems, which are generally presented in the form of services. The interconnection of all things refers to the interaction, collaboration, and integration of ubiquitous objects to form a hybrid system of multiple intelligent agents to realize business logic.

[0004] Pan-manufacturing refers to all behaviors and work that can produce materialized results. Materialized results refer to things that exist in the form of materials and objects, including traditional directly visible tangible things and products, as well as originally intangible things that exist in a certain medium, such as various plans, literary and artistic works, computer software, integrated circuit diagrams, etc.

[0005] Therefore, the pan-manufacturing here includes not only the manufacturing of products and items in the traditional manufacturing industry, but also the research, design and creative work in the production and service industries as well as other industries.

[0006] Pan-manufacturing is manufacturing that expands the scope of manufacturing, and includes production affairs that were previously included in the service industry or other industries into the manufacturing category. The fundamental reason is that with the development of the manufacturing industry, people have deeply realized that many production affairs that do not belong to traditional manufacturing are essentially in the manufacturing category, such as the creation of various technical solutions, the research and development of various scientific and technological fields, the creation of various literary and artistic works, the development of computer software, talent training, etc. These types of "manufacturing" and "manufacturing" processes and methods are very different from traditional manufacturing, but the purpose is the same: to produce "materialized" results, that is, to produce something that is directly or indirectly visible. Including these non-traditional manufacturing in the manufacturing category is conducive to unified treatment and complementary development.

[0007] Therefore, pan-manufacturing is far more extensive than traditional manufacturing, and its scope of application is also wider than traditional manufacturing, so it also has broader and deeper demands and markets.

[0008] In the fourth industrial revolution, the traditional industrial classification (first to third industries) will no longer exist, and the boundaries between industry, production, manufacturing, and services will be eliminated. Industry will appear in a comprehensive form, which is mainly reflected in two aspects: the objects of "manufacturing / production" will be unified, and the implementers of "manufacturing / production" will be unified. Therefore, the concept of pan-manufacturing should be one of the basic requirements of the fourth industrial revolution.

[0009] Edge computing refers to a computing mode in which computing processing is performed close to the edge devices and systems. It can be generally regarded as a close computing mode. Edge devices and systems include instruments and equipment, data sources, and system implementation ends. Computing is a broad term that includes data information processing, storage, and transmission. Edge computing is essentially a distributed computing mode. In edge computing, the goal is to enable edge devices and systems to receive control, participate in computing, and send out computing results. Therefore, edge devices are required to have computing capabilities, networking capabilities, and service provision capabilities.

[0010] Therefore, whether it is edge computing or ubiquitous manufacturing, the most basic requirement is to connect ubiquitous objects to the network.

[0011] For the access of objects, the focus in the Internet of Things was previously on the access of devices, and there was a lack of standardized methods for the access of objects other than devices. For the access of devices, an interface is generally used. The basic components of the interface include: A) Input port: used to connect to the sensor point of the device to realize the reading of the status; B) Output port: connected to the control point of the device to realize the output of control commands; C) Network connection: communication connection with other objects. Software in the interface; C) Controller: used to read the input data of the interface from the input port of the interface, process it according to the established logic, form output data, and send it out from the output port. In addition, the controller also sends and receives data through the communication port.

[0012] For example, the ECU in a modern car is a typical interface.

[0013] At present, the controller mainly has the following forms:

[0014] 1) PC interface board: Several special-purpose interface cards are inserted into a PC (usually an industrial computer) to form an interface. Input, output and network communication are all performed by the PC card, and the controller is a software module running on the PC.

[0015] 2)PLC: A programmable logic controller dedicated to control, with its own port, supporting the writing of controller programs in a dedicated language.

[0016] 3) Single-board computer: Single-board computer system is used as the interface device, and the required ports are generally integrated. The ECU widely used in automobiles belongs to the single-board computer system. Single-board computer systems are divided into standard and special types. The standard one provides standard ports and programming environment. Users can write their own control programs with the support of the programming environment without designing hardware. Special ones are designed according to specific needs from software to hardware, and the control method of the hardware is also not open.

[0017] Currently popular standard single-board computer interfaces mainly include NodeMCU and Arduino

[0018] Arduino was successfully developed by a European development team in the winter of 2005, including Massimo Banzi, David Cuartielles, Tom Igoe, Gianluca Martino, David Mellis and Nicholas Zambetti. Arduino was originally positioned as an open source electronic prototyping platform, including two parts: Arduino board and Arduino IDE. Arduino board is used to connect various devices and networks through the board, and control these connected devices through the application embedded in the Arduino board.

[0019] The control of the Arduino board is achieved through the Arduino application. The Arduino application is based on the Wiring-based Arduino programming language and is supported by the Arduino Development Environment (IDE). The Arduino program is compiled into binary code under the ArduinoIDE and fixed on the Arduino board.

[0020] Arduino IDE is based on Processing. Processing is a Java-based development environment that is based on "Sketch". It treats a computer program as a sketchbook of code and is oriented towards image generation and data display. In Arduino, Processing can be used to easily display the sensor data transmitted by the Arduino board. In addition, Processing can also do most of the things that Java can do.

[0021] According to the NodeMCU R&D team, NodeMCU is an open source IoT platform. In fact, NodeMcu is also an IoT object access technology that uses the Lua scripting language for programming. The platform is based on the embedded Lue (eLua) open source project. Lua is a small scripting language designed to be embedded in applications, providing flexible expansion and customization capabilities for applications. Lua scripts can be easily called by C / C++ code, and can also call C / C++ functions in turn, which makes Lua widely used.

[0022] Lua supports both procedure-oriented programming and functional programming, supports automatic memory management, and provides a universal type: table, which can be used to implement arrays, hash tables, sets, and objects. The language has built-in pattern matching. It supports the concept of closure, so that functions can also be regarded as values, and also supports collaborative processes.

[0023] The content of the present invention is to provide a new single-board interface according to the defects of the current standard single-board interface, and the focus is on the system and development method of the control software of the interface. Summary of the invention

[0024] 1. Basic Content

[0025] The present invention provides a network access method and an access control method for ubiquitous objects, which can be applied in fields such as the Internet of Things, industrial Internet and edge computing.

[0026] Ubiquitous objects refer to various objects that want to join the network and participate in information system activities, including people, objects, machines, numbers, and software. Here, "people" refers to the staff participating in the activities, and they are generally connected to the Internet in the "non-network of objects" way; "objects" refer to items without control and working capabilities, and they are also connected to the Internet in the non-network of objects way; "machines" refer to tools and equipment with control and automatic working capabilities, including computer systems, which can be connected to the Internet through control interfaces (interfacers); "numbers" refer to electronic data storage, which is generally accessed through computer systems; "software" refers to computer software, which can be operated and accessed by other objects.

[0027] The access method and control method given are implemented by an object called an interface UOC. The interface consists of input ports, output ports, communication ports and monitors. The input and output ports connect ubiquitous objects, the communication ports establish network connections, and the monitor is responsible for the operation access of ubiquitous objects and coordinates various functions required by various parts to implement the interface.

[0028] The monitor is responsible for controlling the work of the interface. The monitor works in the mode of ubiquitous object driven widget assembly. When the monitor detects the action of the ubiquitous object, it calls the message processor to dynamically assemble the message processing logic. The basic component of the assembly is the widget. The widget is a standardized software module written by the user to implement specific business logic and logically attached to the monitor.

[0029] Edge computing service, based on the service-oriented interface, makes the interface a service node. First, define your own service request instruction in the request instruction of the extraction instruction, set up the service request processing widget and method library, and attach the service request processing widget to the message engine; set up storage, processing, query and other services in the interface, and support the ubiquitous object represented by the interface to participate in edge computing as a service node.

[0030] 2. Interface Composition

[0031] The interface is mainly composed of input port, output port, communication port and monitor. The main components are described as follows:

[0032] ■ Input port: used to read data from ubiquitous objects, generally connecting the ubiquitous object's sensor and output data channel. Implemented by a mixture of software and hardware, it has the functions of reading control and data conversion.

[0033] ■Output port: used to output data and control commands to ubiquitous objects, implemented by a mixture of software and hardware, with data output control and conversion functions.

[0034] ■Communication port: used for data communication with external objects and to achieve connection with network objects.

[0035] ■Monitor: It is used to support the status release, data release, service provision, behavior intelligent operation control and edge computing of ubiquitous objects, as well as external users to control ubiquitous objects through network access. From the port perspective, the monitor includes three functions:

[0036] A) Port control, the focus is to read data from the input port, analyze and process it according to the user's control logic, generate output data or instructions, and send it to the output port;

[0037] B) Network communication: On the one hand, it monitors network messages. When a message that meets the specifications arrives, it accepts the message and transfers it to the corresponding message processor for processing; on the other hand, it sends messages at the request of the message processor.

[0038] C) Dynamic assembly of business logic: Use port data, local database, method library and other defined widgets as data sources and service sources, set up new widgets, combine and coordinate these data sources and service sources for business logic implementation, form new widgets, and implement the established business logic.

[0039] 3. Composition and structure of the monitor

[0040] The monitor of the interface device is composed of a message engine, an event engine, a transceiver engine, a processing widget, a method library, a message queue, a sending queue, an event definition table, a widget configuration table, and an object interaction image; the input port is used to read the data of the ubiquitous object, and generally connects the sensor of the ubiquitous object and the output data channel. It is implemented by a mixture of software and hardware, and has the functions of reading control and data conversion; the output port is used to output data and control commands to the ubiquitous object, and is implemented by a mixture of software and hardware, and has the functions of data output control and conversion; the communication port is used for data communication with external objects. The method for completing the functions of ubiquitous object network connection, data and status publishing, service provision, behavior intelligent control, edge computing, etc. is that the message engine, event engine, and transceiver engine work according to the following mechanism:

[0041] Message engine: The message engine keeps monitoring the message queue. When a new message to be processed is found, it takes out the message and calls the corresponding message processor to process the message. According to the needs of business logic, users can attach corresponding message processing widgets for business logic processing to the message engine. The attachment is implemented through widget description files. The widget is responsible for organizing the execution of messages. The specific message processing is implemented by the widget calling the method library. At this time, users need to set the method library module for the message processor to call.

[0042] Transceiver engine: monitors network request messages and sending queues. When a network message that meets the standards arrives, it receives the message and stores it in the message queue. It also checks the sending queue. When there is a network message to be sent, it executes the message sending work, presets the message processor for processing network requests, and hangs it on the message engine. If data needs to be sent, a sending message is generated in the sending processing widget and stored in the sending queue.

[0043] Event engine: The event engine is responsible for periodically checking the event definition table. When an event occurs, it calls the event generator widget to generate data and operations for the event. Then, it stores the event as a message in the message queue so that the message engine can start processing the event. The event definition table is defined according to business requirements, and the event generator widget and event processor widget are preset. The event definition table describes the occurrence conditions of each event and indicates which widget is called after the event occurs to generate event data and operations.

[0044] The communication protocol of the transceiver engine is the telegram mode, and the network message communication is realized by carrying the pumping instruction through the transmission protocol. The transmission protocol only needs to support one-way transmission. The pumping instruction includes three types: request instruction, send instruction and response instruction, which are used to request data or user-defined services, send data and request result feedback respectively. The transceiver engine contains a transmission protocol determiner to identify the type of protocol for transmitting the pumping instruction and call the corresponding transmission protocol module to receive the instruction.

[0045] The structure of the event definition table is: event occurrence condition, event generator widget ID, event generator widget execution mode, and event generator widget execution status. The event occurrence condition logic expression, when the value is "true", starts the corresponding event generator widget during event engine monitoring. The event generator widget execution mode indicates whether the event is a thread ignition mode that runs continuously after startup, a module blocking call mode, or a module non-blocking return mode to start the event transmitter. The event generator widget execution status is used to indicate the execution status of the last started event generator: thread running, blocking running, non-blocking running, completed, or faulty.

[0046] The data and status publishing, service provision, ubiquitous object collaborative manufacturing and intelligent control of ubiquitous objects are all implemented based on message processing widgets; the data and status publishing is carried out by setting up data publishing widgets; the data publishing widget is composed of data extraction widgets, data transmission widgets, and data injection widgets in sequence, which respectively realize the acquisition of incremental data, the transmission of incremental data, and the target injection of incremental data; the intelligent control is implemented by setting up intelligent control widgets, which are composed of ubiquitous object state recognition widgets, ubiquitous object behavior decision widgets, ubiquitous object state recognition learning widgets, and ubiquitous object behavior decision learning widgets; the state recognition widget gives the state category of the ubiquitous object group based on the current state and historical state of the ubiquitous object group, and the decision learning widget gives the optimal control command sequence based on the current state category and work tasks of the ubiquitous object group, and the decision is issued to the specified ubiquitous object for execution by setting events;

[0047] The object interaction image is used as a snapshot of the interactive activities of the ubiquitous object. On the one hand, it records the status, data, and commands sent by the ubiquitous object to other objects, and on the other hand, it records the status, data, and commands sent by other objects to the ubiquitous object. The access of the processing widgets attached to the message engine to the ubiquitous object is an operation to access the interaction image of the ubiquitous object, and the binding of the interaction image and the ubiquitous object is completed through the read widget and write widget of the ubiquitous object.

[0048] 4. Interface Host Form

[0049] The hardware support required for the specific implementation of UOC is divided into the following situations:

[0050] A) Computer System

[0051] The hardware is a computer system in which the UOC software runs. This is applicable to situations where the ubiquitous object is data storage in a computer system. For example, databases as ubiquitous objects and software services as ubiquitous objects are both examples of this situation.

[0052] B) Computer system + interface card

[0053] The hardware is a computer system plus a computer system interface card (such as PCI), which is directly connected to the hardware ubiquitous object. The UOC software runs in the computer system. This situation is applicable to industrial computer control. For example, motion control cards and some other A / D cards can be used as interface cards.

[0054] C) Single Board Computer + Interface

[0055] The hardware is the interface between the single-board computer and the device it carries. The UOC software runs on the single-board computer system. This situation is applicable to the situation where the single-board computer is directly used to control the device. Examples of single-board computers include Arduino and NodeMCU;

[0056] D) PLC

[0057] The hardware is PLC, and the UOC software runs in the PLC or is connected to a computer system. This situation is applicable to PLC control.

[0058] 5. Monitor composition and working method

[0059] The core of the interface is the monitor software. Figure 1 .

[0060] Monitoring software consists of three components: engine, widgets, method library, and data structure.

[0061] (1) Widgets and method libraries

[0062] A widget is a software module with standardized structure, which is called or started by a message processor or event transmitter to process a specified message or generate a specified event. The description of this "specified" relationship is done through a configuration file, which is called a "hook".

[0063] The method library is a user-defined standardized program module for widgets to call to implement complex widget functions.

[0064] (2) Data Structure

[0065] It includes message queue, sending queue, event description table, widget configuration table, and ubiquitous object interaction map UOB. The message queue stores various messages with processing in the system; the sending queue stores messages sent through the network; the event description table defines the conditions for the occurrence of events; the widget configuration table defines the mapping relationship between message processor widgets and messages. The ubiquitous object interaction map UOB is used to buffer the data sent by the ubiquitous object to the outside.

[0066] (3) Engine

[0067] The engine is software that works in a cyclic detection and monitoring mode. After it is started, it will continue to work in a cyclic manner. The engine includes a message engine, an event engine, and a transceiver engine. Figure 2 shown.

[0068] 6. Working Mechanism of Monitor

[0069] The working mechanism of the monitor is described as follows.

[0070] ■ Message engine operation: The message engine keeps monitoring the message queue. When a new message to be processed is found, it takes out the message and calls the corresponding message processor to process the message. The main work that users need to cooperate with is that users attach corresponding message processing widgets for business logic processing to the message engine according to the needs of business logic. The attachment is realized through the widget description file. The widget is responsible for organizing the execution of messages. The specific message processing is realized by the widget calling the method library. At this time, users need to set the method library module for the message processor to call.

[0071] The description of the message engine execution process is as follows:

[0072] [1] Initialization;

[0073] [2] Check whether there are any pending messages in the message queue;

[0074] [3] If there is no pending message, go to [1];

[0075] [4] (Messages to be processed) Take out the message;

[0076] [5] Analyze the message and find the message processing widget corresponding to the message;

[0077] [6] Start the found message processing widget;

[0078] [7]Transfer[1]

[0079] ■The work of the transceiver engine: monitor network request messages and the sending queue, and when a network message that meets the standards arrives, receive the message and store it in the message queue. At the same time, the sending queue is also checked. When there is a network message to be sent, the message sending work is performed. The main work that users need to cooperate with is to preset the message processor that processes network requests and attach it to the message engine; if data needs to be sent, a sending message is generated in the sending processing widget and stored in the sending queue.

[0080] The description of the transceiver engine execution process is as follows:

[0081] [1] Initialization;

[0082] [2]Monitor network ports;

[0083] [3] If a valid network request message arrives, go to

[10] ;

[0084] [4] Check whether there are any pending messages in the sending queue;

[0085] [5] If there is no pending message, go to [];

[0086] [6] (There are messages waiting to be processed in the sending queue) Take out the message;

[0087] [7] Analyze the message and find the message processing widget corresponding to the message;

[0088] [8] Start the found message processing widget;

[0089] [9] Go to [2];

[0090]

[10] (A legitimate network request message arrives) Receive message instructions;

[0091]

[11] Analyze the message instructions and check the legality. If it fails, discard the message and go to

[13] ;

[0092]

[12] Generate a network request message and store it in the message queue;

[0093]

[13] Go to [4];

[0094] ■Event engine work: The event engine is responsible for periodically checking the event definition table. When an event occurs, it calls the event generator widget to generate data and operations for the event. Then, it stores the event as a message in the message queue so that the message engine can start processing the event. The main work that users need to cooperate with is to define the event definition table according to business requirements, and preset the event generator widget and event processor widget. The time definition table describes the occurrence conditions of each time, and indicates which widget is called after the time occurs to generate the data and operations of the time.

[0095] The event engine execution process is described as follows:

[0096] [1] Initialization: Use the first definition item in the event definition table as the current event definition item;

[0097] [2] Check whether the current event definition item meets the event occurrence conditions;

[0098] [3] If the event occurrence conditions are not met, go to [5];

[0099] [4] (The current event definition item meets the event occurrence conditions) If the event generation widget corresponding to the current event definition item is not started or is suspended due to a fault, start the widget, which will generate corresponding data for the event and generate an event message to be stored in the message queue;

[0100] [5] If the current event definition item is the last item, the first event item is used as the new current event definition item; otherwise, the next event definition item is used as the new current event definition item and go to [2];

[0101] 7. Main data structure of the monitor

[0102] The work of the monitor is based on the main data structures including message queue, sending queue, event definition table, widget configuration table and object interaction image.

[0103] ■Message queue: stores the messages currently to be processed, including network request (receive) messages and event messages. Network request messages are generated by the transceiver engine when it monitors the arrival of network requests; event messages are generated by the event generation widget after the event engine detects the occurrence of an event.

[0104] ■Send queue: stores the network send messages that are currently waiting to be sent. This type of message can be generated by various widgets and stored in this queue. This queue is detected by the send and receive engine, and after the message to be sent is sent, it is sent out;

[0105] ■Event definition table: It is a sequence table, where a certain item defines an event occurrence condition and the corresponding event generator widget association. It is manually configured by the user or automatically set by the work widget. The table is detected by the event engine. If an event that meets the conditions is found, the event generator is started to prepare for the event processing;

[0106] ■ Widget configuration table: used to describe the association of message processors, that is, to establish a mapping between messages that can appear in the message queue and the corresponding processor widgets. It is manually configured by the user or automatically set by the work widget. This table is detected by the message engine, and the message engine finds the corresponding message processor widget through this table when analyzing the message;

[0107] ■ Ubiquitous Object Interaction Image UOB: used as a data cache for interaction between ubiquitous objects. The data sent by a ubiquitous object to other objects is stored in the UOB, and then actively read from the UOB by other related widgets. The UOB is mainly composed of queues, including:

[0108] Status queue: stores status data read from the object;

[0109] Command code queue: stores control commands to be sent to the object;

[0110] Data object: caches data from objects or external sources;

[0111] Each data item listed above has a data header attached to it, indicating the source and destination of the data. The data of UOB is transparent to user programmers, and users access UOB through the system-set UOB-API.

[0112] 8. Specifications of Widgets and System Widgets

[0113] PIPs are divided into temporary and permanent ones based on their operation modes. Temporary PIPs only run once each time they are started, and automatically terminate and return after running; permanent PIPs are always in the running state after they are started, similar to services, usually in the form of threads, until external intervention or the total internal time limit is completed.

[0114] Widgets are classified into message processor widgets and event generation widgets based on the objects they are attached to. Message processor widgets are attached to the message processing engine, and the message processing engine is started. Event processing widgets are attached to the event engine, and the event engine is started.

[0115] Widgets are divided into system widgets and user widgets according to the objects they belong to. User widgets are user-defined and used to implement user logic; system widgets are a type of special-purpose widget that completes the functions required for the normal operation of the monitor. The main system widgets include:

[0116] Network receiving widget: receive network messages;

[0117] Network Send Widget: Send messages from the network;

[0118] System event generation widget: Widget for system internal events;

[0119] In terms of form, a widget is an object. A widget is a programming language object.

[0120] Each widget object must have a startup method and several specified properties. The specific model is:

[0121]

[0122]

[0123] IX. Basic usage of the interface

[0124] To connect ubiquitous objects using an interface, there are the following basic steps:

[0125] Step 1: Connect the interface. If the interface is hardware, connect the device to the interface port; if the interface is software, deploy the interface to the interface container.

[0126] Step 2: If necessary, set up a method library for PIP to call;

[0127] Step 3: Write the connection PIP: According to the requirements of the specific device, write the message processor PIP and its implementation module to realize the connection between the device and other objects;

[0128] Step 4: Write the communication connection PIP: According to the communication requirements, write the PIP and its implementation module for processing communication messages;

[0129] Step 5: Deploy PIP: Write a PIP configuration table file to associate each PIP with the preset message.

[0130] Step 6: Write the client: Write the client of the application according to the application requirements. If the client needs to access the feed, it uses the request OAI to access the integrated feed and retrieve the access result.

[0131] 10. Monitor network transmission protocol

[0132] The monitor's transceiver engine is responsible for the system's network communication. Its basic function is to monitor network reception and transmission of messages. After monitoring the transmission and reception of messages, it receives or sends messages according to the transmission protocol and calls the system PIP to implement network reception or network transmission. It sends and receives data according to the monitor's network transmission protocol.

[0133] The monitor network transmission protocol is built on the network communication protocol and can be performed on multiple protocols, including TCP / IP, MQTT, HTTP and EIIP.

[0134] The monitoring network transmission protocol is carried out in telegram mode. Both parties of the network communication must start the transceiver engine in advance and be in the monitoring state. The sender sends a command, and after the receiver listens, a transmission connection is established, and then the command is received. After the reception is completed, the communication is completed and the connection is disconnected.

[0135] 11. Message Instructions

[0136] Monitor message instructions are divided into three types: request instructions, send instructions and response instructions.

[0137] (1) Request instruction

[0138] The request command is used to convey the user's (command sender's) request message to the specified monitor. The specific request content and processing method are interpreted by the widget of the provider.

[0139] Format:

[0140] "Request" <requestid> <messageno> <object> <permit>[resMode][parameters]

[0141] illustrate:

[0142] This command is used to send a request command to the specified monitor. The semantics of the request is interpreted by the corresponding widget. The monitor is only responsible for receiving the command and calling the corresponding widget to process it.

[0143] The sub-command word requestID is specified by the user and is used to further classify or distinguish the request instruction.

[0144] Parameters are used to specify the parameters required for the request, which are determined by the user and interpreted by the widget.

[0145] The way the request result is sent back is specified by resMode

[0146] Permit is the sender's pass. The receiver will check the validity of the pass and control the scope and content of the request according to the permissions indicated in the pass.

[0147] messageNo is the message sequence number, which is an integer value, described by a 64-bit binary number, and is the number of milliseconds from 00:00 on January 1, 2017 to the time the message was sent. Each message in the supply has a corresponding message sequence number. The message sequence number is generated by the message requester. If multiple messages are generated at the same time, they are generated in the order in which they were generated, and each subsequent message is based on the previous one plus 1.

[0148] objectID: The identifier of the object to which the feed is connected. A monitor can be connected to multiple objects, and different objects define different object identifiers.

[0149] Parameters: Parameters of the message.

[0150] (B) Sending instructions

[0151] The send command is used by the user to send data to the monitor.

[0152] Format:

[0153] "Send" <sendid> <messageno> <object> <permit>[resMode][parameters]

[0154] illustrate:

[0155] This command is used to send data to the specified supply. The monitor is only responsible for receiving the command and the data carried in the command. Other matters, such as processing or storing the received data, are the responsibility of the corresponding widget.

[0156] The command word of the command is determined by the user, which is a further distinction of the meaning of Send. For example, it can indicate the encoding, format and type of the data to be sent.

[0157] The data to be sent is contained in parameters.

[0158] The way to send back the processing result or status is specified by resMode

[0159] The meanings of other parameters are the same as Request

[0160] (C) Response Instructions

[0161] The response instruction is used to send back the execution status or result of the requester's instruction to the requester.

[0162] Format:

[0163] "Respond" <replayid> <messageno> <object> <permit>[resMode][parameters]

[0164] illustrate:

[0165] This command is used to send a response message to the specified monitor. If a monitor A previously sent a request message or a send message to monitor B, and the resMode in the message indicates that B needs to send back a response message, then B uses this command to send back a response message after processing the message.

[0166] There are two types of response messages: status response and data response, corresponding to the sub-command replayID "StatusReplay" and "DataReplay" respectively. The first parameter in the status response is a JSON string, while the data response carries a JSON-formatted status in the first parameter and a data block in the second parameter.

[0167] object and messageNo are the address and message number of the responded message, which are the information carried in the previously received responded message.

[0168] The monitor is only responsible for receiving the command and the data carried in the command. Other matters, such as processing or storing the received data, are the responsibility of the corresponding widgets.

[0169] The sub-command word of the command is determined by the user and is a further distinction of the meaning of Send. For example, it can indicate the encoding, format and type of the data to be sent.

[0170] The data to be sent is contained in parameters.

[0171] The way to send back the processing result or status is specified by resMode BRIEF DESCRIPTION OF THE DRAWINGS

[0172] Figure 1 This is a diagram of the Ubiquitous Object Interface architecture

[0173] Figure 2 Schematic diagram of the drive architecture

[0174] Figure 3 This is the schematic diagram of the OAA board composition DETAILED DESCRIPTION

[0175] An implementation example of the method and system provided in the present invention is given here to further illustrate the implementation technology of the method provided in the present invention and an implementation example of the system, but other implementation technologies and implementation methods are not excluded.

[0176] The relevant algorithms and data structures are described in C++;

[0177] 1. Implementation of main data structures

[0178] (1) Queue element structure

[0179]

[0180] (2) Queue Object

[0181] Both the message queue and the send queue are instances of this class.

[0182]

[0183] (3) Widget configuration table structure

[0184] The widget configuration table is described in XML.

[0185]

[0186] MsgType and MsgName must correspond to the message type and name defined by the client. Procesor corresponds to the name used to specify the message processor widget.

[0187] (4) Event definition table

[0188] The description is similar to the widget configuration table, except that logical expressions are used instead of message names and types.

[0189] (5) Object Interaction Imaging

[0190] The ubiquitous object interaction image is logically a data structure that stores the concerned states, data and control instructions of the ubiquitous objects.

[0191] The state is the working state of the ubiquitous object, including the current state and the historical state. There are two types of data: one is the data output by the ubiquitous object, and the other is the data or control command input from the external object to the internal ubiquitous object. The control command is the control command sent from the outside to the ubiquitous object.

[0192] The interactive images of all ubiquitous objects in the system are based on the data arrival

[0193] The following describes the logical structure of these three types of data and related data.

[0194] (A) Mapping table

[0195] Assume that a ubiquitous object has multiple states, each of which is identified by a natural number starting from 1 (ID)

[0196] A state can retain multiple historical states, using integers starting from 0 as IDs, 0 represents the current state, 1 represents the previous state, and so on.

[0197] (B) Command

[0198] A command is a control command sent to a device. Different devices have different control commands. Here, the command structure model is specified. The specific command format, semantics, etc. are determined by the specific device.

[0199] Each device has a corresponding command queue, which sequentially stores the commands currently to be executed by the device. After the command is executed, it will be removed from the queue. The format of the command in the queue is as follows:

[0200] Command word parameter 1 parameter 2...

[0201] There are spaces between command words and parameters, and between parameters. If a parameter contains multiple fields, the fields are separated by commas.

[0202] (C) Data

[0203] There are two types of data: input data and output data. Input data is data transmitted to the device from the outside, and output data is data output by the device to the outside. The format and semantics of the data are determined by the device.

[0204] Two queues are used to store input and output data respectively. The data elements in the queues are of variable length and the data types support Java data types.

[0205] Device Image Interface Definition

[0206]

[0207]

[0208]

[0209] 1. Implementation Method of Monitoring Engine Here we use Java-like language to describe the relevant implementation methods. (1) Implementation Model of Engine Main Program OAAE()

[0210]

[0211]

[0212] (2) Event Queue Design

[0213] Event queues are divided into three types: network events, object events, and internal events.

[0214] Network event queue: stores messages from or to the network;

[0215] Object event queue: stores messages from ubiquitous objects in internal ports;

[0216] Internal event queue: stores messages from user-defined internal events;

[0217] The APIs for each queue are similar. The main API member functions are as follows:

[0218] getEven(queue ID): extract an element (head of queue) from the queue indicated by "queue ID";

[0219] readEven(queue ID): extract an element (head of queue) from the queue indicated by "queue ID";

[0220] addEvent(queue ID, event, priority): adds the specified event to the specified queue according to its priority. Normal priority events are added to the end of the queue.

[0221] killEvent(queue, event ID): delete the specified event in the specified queue;

[0222] 2. Hardware Implementation Method of Interface

[0223] The current OAA boards are divided into two types: single-bus structure and dual-bus structure, which are suitable for high-end applications and general applications respectively.

[0224] The CPU, RAM and each device interface module of the single-bus OAA board are directly connected through the system bus. The CPU, RAM and each device interface module of the dual-bus structure have separate connection buses.

[0225] The interfaces of the OAA board are divided into two categories: communication connection and device monitoring connection.

[0226] The purpose of communication connections is to implement networking between objects, including device communication and software object communication. In particular, communication connections also implement connections between OAAs. Figure 3 As shown. The main communication interface modules include (optional) the following:

[0227] ■Ethernet module: used for network access of equipment

[0228] ■NB-IoT module: cellular-based Narrow Band Internet of Things (NB-IoT), mainly used for network access of devices;

[0229] ■LoRa: long-distance wireless transmission based on spread spectrum technology; mainly used for network access of devices;

[0230] ■WIFI: Wireless LAN; mainly used for network access of devices;

[0231] ■Bluetooth: short-range wireless communication, mainly used for short-range communication between devices, and also for device monitoring connection

[0232] ■CAN: Fieldbus, mainly used for equipment networking;

[0233] Device monitoring connections are mainly used to connect monitored devices, which generally have no or weak communication and computing capabilities. The main interface modules include:

[0234] ■Infrared: Infrared transmission information communication, mainly used to control home appliances

[0235] ■COM: Support RS232 and 485 serial communication;

[0236] ■USB: serial communication supporting hot-swap;

[0237] ■SPI: High-speed synchronous serial communication

[0238] ■GPIO: general purpose input and output interface;

[0239] ■PWM: Pulse Width Modulation, digital encoding of analog signal levels;

[0240] ■A / D, D / A: analog-to-digital and digital-to-analog conversion; mainly used in analog signal acquisition, analog control, etc.

[0241] ■NFC: IC near field communication, mainly used for connection and communication based on IC card.< / permit> < / object> < / messageno> < / replayid> < / permit> < / object> < / messageno> < / sendid> < / permit> < / object> < / messageno> < / requestid>

Claims

1. A ubiquitous object interaction interface method for ubiquitous manufacturing and edge computing, characterized in that: An interface is provided, which is composed of an input port, an output port, a communication port and a monitor, and is used for monitoring and network connection of ubiquitous objects including people, objects, instruments and equipment, computer systems, computer software and data, supporting data and status publishing, service provision, ubiquitous object collaborative manufacturing and intelligent control of ubiquitous objects, and supporting ubiquitous objects as edge computing service nodes; The input port of the interface is realized by a mixture of software and hardware, and is used to read the data of the ubiquitous object, connect the sensor of the ubiquitous object with the output data channel, and perform reading control and data conversion; The output port of the interface is realized by a mixture of software and hardware, and is used to output data and control commands to the ubiquitous object, and to perform data output control and conversion; the communication port of the interface is responsible for data communication with external objects; the monitor of the interface is composed of a message engine, an event engine, a transceiver engine, a processing widget, a method library, a message queue, a sending queue, an event definition table, a widget configuration table, and an object interaction image; The event definition table is defined by the user according to business requirements, defines the conditions for the occurrence of each event, and indicates which widget is called after the event occurs to generate event data and operations; The structure of the event definition table is: event occurrence condition, event generator widget ID, event generator widget execution mode, and event generator widget execution status; when the event engine monitors the event occurrence condition logic expression value as "true", the corresponding event generator widget is started; The event generator widget execution mode indicates the running mode of the event generator: thread ignition mode that runs all the time after startup, module blocking mode, module non-blocking mode; the event generator widget execution status is used to indicate the execution status of the event generator started last time: thread running, blocking running, non-blocking running, completion, failure; The object interaction image is used as a snapshot of the interactive activities of the ubiquitous object. On the one hand, it records the status, data, and commands sent by the ubiquitous object to other objects, and on the other hand, it records the status, data, and commands sent by other objects to the ubiquitous object. The access of the processing widgets attached to the message engine to the ubiquitous object is to operate the interaction image of the ubiquitous object, and the binding of the interaction image and the ubiquitous object is completed through the read widget and the write widget of the ubiquitous object. The data and status publishing, service provision, ubiquitous object collaborative manufacturing and intelligent control of ubiquitous objects are all implemented based on message processing widgets; the data and status publishing is carried out by setting up data publishing widgets; the data publishing widget is composed of data extraction widgets, data transmission widgets, and data injection widgets in sequence, which respectively realize the acquisition of incremental data, the transmission of incremental data, and the target injection of incremental data; the intelligent control is implemented by setting up intelligent control widgets, which are composed of ubiquitous object state recognition widgets, ubiquitous object behavior decision widgets, ubiquitous object state recognition learning widgets, and ubiquitous object behavior decision learning widgets; the state recognition widget gives the state category of the ubiquitous object group based on the current state and historical state of the ubiquitous object group, and the decision learning widget gives the optimal control command sequence based on the current state category and work tasks of the ubiquitous object group, and the decision is issued to the specified ubiquitous object for execution by setting events; Edge computing service, based on the service-oriented interface, makes the interface a service node, defines its own service request instruction in the request instruction of the extraction instruction, sets the service request processing widget and method library, and attaches the service request processing widget to the message engine; sets storage, processing, and query services in the interface, and supports the ubiquitous object represented by the interface to participate in edge computing as a service node.

2. The method according to claim 1, wherein: The working method and process of the monitor are as follows: the message engine monitors the message queue all the time, and after finding a new message to be processed, takes out the message and calls the corresponding message processor to process the message; the transceiver engine monitors the network request message and the sending queue, and after finding that a network message that meets the standards arrives, receives the message and stores it in the message queue, and also checks the sending queue. When there is a network message to be sent, the message sending work is executed, and the message processor that processes the network request is preset and attached to the message engine; If data needs to be sent, a send message is generated in the send processing widget and stored in the send queue; the event engine periodically checks the event definition table, and after discovering an event, calls the event generator widget to generate data and operations for the event, and then stores the event as a message in the message queue for the message engine to start processing the event. Users define the event definition table according to business needs, and preset the event generator widget and event processor widget; The event definition table describes the conditions for each event to occur, and indicates which widget is called after the event occurs to generate event data and operations.

3. The method according to claim 2, wherein: The communication protocol of the transceiver engine is the telegram mode, and network message communication is realized by carrying the extraction instruction through the transmission protocol; the transmission protocol only needs to support one-way transmission; the extraction instruction includes three types: request instruction, send instruction and response instruction, which are used to request data or user-defined services, send data and send back the request results respectively; the transceiver engine includes a transmission protocol determiner to identify the type of protocol for transmitting the extraction instruction and call the corresponding transmission protocol module to receive the instruction.

Images