A sensor assembly service encapsulation method and sensor

Abstract

The application provides a sensor assembly service encapsulation method and a sensor. The method comprises the following steps: constructing a target sensor module, the target sensor module comprising a plurality of sub-function modules; connecting to a dynamic library, and constructing a dynamic link relationship between functions in the dynamic library and I / O interfaces of the sub-function modules; and performing Restful style encapsulation on an application program interface of the target sensor module after the dynamic link relationship is generated, to obtain a target sensor module after encapsulation. The method greatly reduces the development difficulty of the function block by linking the external library. The universality of the sensor function block is improved by using the basic function block to create the sensor function block, and the resource utilization of the sensor is reasonably optimized. In addition, the scheme realizes access to the output result by the component service method, changes the API, changes the function block parameters, and then realizes different sensor functions and working modes, and can be widely applied to the technical field of sensors.

Description

Technical Field

[0001] This invention relates to the field of sensor technology, and in particular to a sensor component service packaging method and a sensor. Background Technology

[0002] Currently, the physical scale and functionality of manufacturing plants are constantly increasing, and the computing power provided by PLCs cannot meet the demands. Controlling such automation systems with a central PLC is generally not feasible. Instead, better performance can be achieved if the control logic is distributed across multiple cooperating PLCs. However, the architecture of the IEC 61131-3 standard is not suitable for distributed system architectures. To address the shortcomings of IEC 61131-3, another international standard, IEC 61499, was published in 2005 and revised in 2012 to assist in the development of distributed automation systems. The difference between the protocols of these two industries lies in the nature of the communication they need to support. On the Internet, stateless communication plays a more significant role because communication is mostly ephemeral and more unpredictable than in a confined industrial environment. However, this technological gap at the heart of the Internet of Things (IoT) can be overcome. We demonstrate that through a simple extension of the standard, OPC UA can support the popular RESTful web service style, the foundation of many popular web technologies.

[0003] One related technical solution presents a case study of an airport baggage handling system based on a component architecture and the IEC 61499 standard. This solution assigns a software component type to each device, such as a conveyor belt, which is extracted and instantiated from a library. While utilizing a component-based architecture and the IEC 61499 standard, this approach binds hardware and software components; one hardware facility corresponds to one software component type. This allows specific functional blocks to be applied to specific hardware, reducing the versatility of functional blocks to some extent. Furthermore, each functional block can only represent one sensor. In this large-scale project, there are many sensor functional blocks, making the component composition exceptionally complex and reducing readability. Another related technical solution proposes a component-based distributed control software framework, also using the IEC 61499 standard. This framework introduces new software components, called automation components, which can be layered and embedded to generate new components. Through the encapsulation of multi-layered automation components, a hierarchical system structure is proposed. Because it conforms to IEC 61499, this framework is platform-independent, but it demonstrates how applications developed using this framework can be executed on an IEC 61499 platform. This solution can effectively realize the development of component-based distributed control software. Its sensor module can only perform the function of querying the hardware status, and cannot perform certain operations on its I / O ports. Its status needs to be controlled by the control function block. Summary of the Invention

[0004] In view of the above, based on the technical problems or defects mentioned in the background art, the purpose of this embodiment of the invention is to provide a sensor component service packaging method and a sensor, so as to reduce the development difficulty of components in the control process control system, and at the same time improve the reusability of components and the utilization rate of embedded resources.

[0005] On the one hand, the technical solution of this application provides a service-oriented packaging method for sensor components, including the following steps:

[0006] Construct a target sensor module, which includes several sub-functional modules;

[0007] Connect to the dynamic library and establish a dynamic link relationship between the functions in the dynamic library and the I / O interface of the sub-functional module;

[0008] The application programming interface of the target sensor module after generating the dynamic link relationship is encapsulated in a RESTful style to obtain the encapsulated target sensor module.

[0009] The target sensor module has at least one of the following operating modes: difference-based operating mode, time-based operating mode, automatic operating mode, and default operating mode;

[0010] The sub-functional modules include: a selection function block, a sensor integration function block, an output function block, an event loop function block, and an event merging function block.

[0011] In one feasible embodiment of the present application, the method further includes: when the working mode is a difference-based working mode, the target sensor module outputs a first difference between the first measurement value at the current moment and the second measurement value at the previous moment, or outputs a second difference between the first measurement value at the current moment and a first preset value.

[0012] In one feasible embodiment of the present application, the method further includes: when the working mode is a time-based working mode, the target sensor module outputs a third measurement value according to a preset first time frequency.

[0013] In one feasible embodiment of the present application, the method further includes: triggering an automatic working mode when the second difference falls within a preset threshold range;

[0014] The working mode is determined to be automatic working mode. The target sensor outputs a fourth measurement value according to a preset second time frequency. The third difference between the fourth measurement value and the first preset value is kept within the threshold range.

[0015] In one feasible embodiment of the present application, the method further includes:

[0016] The selection function block obtains the working mode parameters and outputs the target event based on the working mode parameters.

[0017] The working mode corresponding to the working mode parameter is activated based on the target event.

[0018] In one feasible embodiment of the present application, the method further includes:

[0019] The sensor category parameter is obtained, and the sensor integrated function block loads the sensor function implementation logic according to the sensor category parameter.

[0020] In one feasible embodiment of the present application, the method further includes:

[0021] The event loop function block obtains the time frequency parameter and executes the target event cyclically according to the time frequency parameter.

[0022] In one feasible embodiment of this application, the application programming interface of the target sensor module after generating the dynamic link relationship is encapsulated in a RESTful style to obtain the encapsulated target sensor module, including:

[0023] The request and response messages of the application interface are defined according to the target management command;

[0024] Data collection and service reconfiguration for RESTful services are performed through the defined application programming interface (API).

[0025] In one feasible embodiment of the present application, the request message includes synchronous requests and asynchronous requests; when the request message is an asynchronous request, defining the request message and response message of the application interface according to the target management command includes:

[0026] A plurality of asynchronous requests that share the same element are identified by parameter identifiers; the element in the asynchronous request includes at least one of the following: device name, resource name, application name, function block instance name, and variable name.

[0027] On the other hand, the present application also provides a sensor, which includes:

[0028] The selection function block is used to obtain working mode parameters, output target events according to the working mode parameters, and start the working mode corresponding to the working mode parameters according to the target events;

[0029] A sensor integration function block is used to obtain sensor category parameters and load sensor function implementation logic according to the sensor category parameters;

[0030] An output function block is used to process the sensor output according to the operating mode parameters;

[0031] The event loop function block is used to obtain time frequency parameters and execute the target event cyclically according to the time frequency parameters.

[0032] The event merging function block is used to generate event output when at least one of the two input events is triggered.

[0033] The advantages and beneficial effects of the present invention will be set forth in part in the following description, and the rest will become apparent from the specific embodiments thereof:

[0034] The sensor component service-oriented encapsulation method provided in this application achieves direct API calls to existing libraries by linking to external libraries. This eliminates the need to refactor the code from the root and write corresponding code libraries. Furthermore, it can draw upon existing embedded I / O control source code, significantly reducing the development difficulty of functional blocks. By using basic functional blocks to create sensor functional blocks, multiple modes can be created to suit different application environments, improving the versatility of the sensor functional blocks. Simple data processing functions are added to the sensor functional blocks, reasonably optimizing sensor resource utilization, and the automatic mode can reduce resource consumption to a certain extent. In addition, through the component service-oriented approach, the output results can be accessed through the front end, and the parameters of the functional blocks can be changed by modifying the corresponding APIs, thereby achieving different sensor functions and different modes. Attached Figure Description

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

[0036] Figure 1 This is a flowchart illustrating the steps of a sensor component service-oriented packaging method provided in the technical solution of this application;

[0037] Figure 2 This is a schematic diagram of the four modes of the sensor module in the technical solution of this application;

[0038] Figure 3 This is a schematic diagram of the interface of the multi-mode sensor in the technical solution of this application;

[0039] Figure 4 This is a flowchart of the internal logic of the multi-mode multi-functional sensor component in the technical solution of this application;

[0040] Figure 5 This is a schematic diagram of the service-oriented encapsulation of components in the technical solution of this application;

[0041] Figure 6 This is a schematic diagram illustrating the reading of composite function block parameters in the technical solution of this application. Detailed Implementation

[0042] The embodiments of the present invention are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention. The step numbers in the following embodiments are set only for ease of explanation, and there is no limitation on the order between the steps. The execution order of each step in the embodiments can be adaptively adjusted according to the understanding of those skilled in the art.

[0043] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0044] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0045] As noted in the background section, IEC 61499 is a new automation standard serving as a reference architecture for distributed industrial process measurement and control systems. It defines a graphical programming language in the form of function blocks. Each function block consists of an event interface, event execution control, a data interface, and encapsulation. The event handling mechanism is a key difference from IEC 61131-3 function blocks; according to the IEC 61499 standard, all control logic must be encapsulated within function blocks. A function block is a software component that can be reused by mapping its interface. The paradigm shift is towards building automation programs from a standard library, rather than starting from scratch each time. Automation programs can be generated by configuring the required software components.

[0046] IEC 61499 defines three types of function blocks: ① Simple function blocks: function blocks that implement a single function. ② Service function blocks: function blocks used to establish communication between devices to access specific parts of hardware. ③ Composite function blocks: function blocks used to access specific parts of hardware.

[0047] Currently, traditional manufacturing and the information and communication technology (ICT) industry are converging in the so-called Internet of Things (IoT). Both industries have brought their preferred protocols. On one hand, this includes web-centric protocols such as application-level protocols with HTTP transport, Message Queuing Telemetry Transport (MQTT), and Constrained Application Protocol (CoAP). On the other hand, this includes protocols from industrial networks. These protocols are either fieldbus-based or Ethernet-based application-level protocols such as OLE (OPC Classic) for process control and the latest OPC Unified Architecture (OPC UA).

[0048] The difference between the protocols in these two industries lies in the nature of the communications they need to support. On the internet, stateless communication plays a more significant role because communication is mostly ephemeral and more unpredictable than in a confined industrial environment. However, this technological gap at the heart of the Internet of Things (IoT) can be overcome. We demonstrate that, through a simple extension of the standard, OPC UA can support the popular RESTful web service style, the foundation of many popular web technologies.

[0049] The purpose of this invention is to propose a novel component-based process control system equipment integration method to reduce the development difficulty of components in process control systems, while improving component reusability and embedded resource utilization. In the development of previous process control systems, sometimes multiple sensors in an embedded device do not operate in parallel. One sensor is in use while others are idle, but it cannot be removed from the component's control system. This results in multiple sensor function blocks deployed in the same embedded device within a project, which is detrimental to project management and readability. Therefore, the main objectives of this application's technical solution are as follows:

[0050] 1) Optimize resource utilization in process control. In process control systems, resource allocation can easily affect the system's operation.

[0051] 2) Improve the versatility and reusability of components in process control. Component reusability is a significant advantage of the IEC 61499 standard and is also one of the standards we use to develop components.

[0052] 3) Implement service-oriented architecture for components. Enable read and write operations on component resources from the front end through a defined unified API.

[0053] Regarding the shortcomings of the prior art pointed out above, firstly, such as Figure 1 As shown, the technical solution of this application provides a service-oriented packaging method for sensor components, the method including steps S01-S03:

[0054] S01. Construct a target sensor module, which includes several sub-functional modules;

[0055] In this embodiment, developing using Forte's own functions within the current open-source Forte development environment would be an extremely large undertaking, especially developing the service interface functional blocks. This would require interpreting the source code and then creating the corresponding library functions, a very complex process. Therefore, this method was not used in this embodiment. Firstly, in this embodiment, dynamic libraries can be linked using CMakeLists, allowing for the calling of mature function libraries from embedded devices during Forte runtime, enabling read and write operations on hardware I / O ports. Secondly, in the IEC 61499 standard, each composite functional block can be composed of multiple simple functional blocks. Each simple functional block has its own state machine and algorithm logic; upon reaching a new state, the corresponding algorithm logic is executed, and a corresponding event is output.

[0056] In addition, the multi-mode multi-functional sensor in this embodiment has four operating modes: difference-based operating mode, time-based operating mode, automatic operating mode, and default operating mode.

[0057] ① Difference-based working mode: This mode can output the difference between the measured value at the current moment and the previous measured value, as well as the value at the current moment. It can also output the difference between the measured value at the current moment and a set value. This is used for measuring the fluctuation range of sensor measurements and setting thresholds for sensor data.

[0058] ② Time-based working mode: Outputs measurement values ​​according to the time frequency set by the user.

[0059] ③ Automatic working mode: When the difference between the sensor measurement value and the set value is within a set range (threshold), the time-based working mode will be triggered, and the sensor measurement value will be quickly output according to the set time frequency, so that the controller can run quickly and the sensor measurement value can be quickly stabilized at the set value.

[0060] In some feasible implementations, when developing sensor modules, some simple data processing capabilities are integrated into the sensors to make full and reasonable use of the resources in the embedded devices. In traditional function block development, service interface function blocks are used to realize interaction with embedded hardware, but it is difficult to implement some data processing functions using service interface function blocks. Therefore, in this embodiment, composite function blocks are used to develop sensor function blocks, that is, sensor modules.

[0061] Specifically, in the embodiments, such as Figure 2 As shown, the sensor module has four operating modes: difference-based mode; time-based mode; automatic mode; and default mode. In difference-based mode, the sensor outputs the difference between the current value and the previous measurement. In time-based mode, the sensor block provides outputs at given time intervals. The automatic mode of the sensor block uses both difference-based and time-based modes simultaneously. Specifically, when the difference between the sensor reading and the set value is relatively small, the time-based mode is activated to help the control system increase the frequency of value readings, achieving a more precise reading and stabilizing the value at the set reference value more quickly.

[0062] In normal operating mode, the embodiment functions like a regular sensor, with an interface such as... Figure 3 As shown; the “Mode” interface indicates the selected mode. Numbers 1, 2, 3, and 4 represent difference-based working mode, time-based working mode, automatic working mode, and default working mode, respectively. “PIN1,” “PIN2,” and “PIN3” represent I / O port codes; different values ​​represent different I / O ports, and their corresponding values ​​depend on the actual physical I / O ports connected to the sensor. “SetValue” represents the set reference value, used in automatic working mode. “D_value” represents the deviation error value, used in difference-based mode and automatic mode. When the absolute value of the difference between the sensor value and the previous value is greater than this value, the sensor value and the difference are output. In automatic mode, when the absolute value of the difference between the sensor value and the set value is less than or equal to this value, time-based mode is activated to increase the sensor's measurement frequency. “DT1” indicates a fixed time interval for output. “Sensor” indicates the type of sensor, using integers 1, 2, and 3 to represent ultrasonic ranging sensor, temperature sensor, and humidity sensor, respectively. “OUTPUT” indicates unprocessed data, “s_differ” indicates the difference between the current value and the set reference value, “p_differ” indicates the difference between the current value and the previous data, and “Error” indicates an exception.

[0063] Furthermore, the composite functional block of the multi-mode multi-functional sensor constructed in the embodiment mainly consists of a selection functional block, a sensor integration functional block, an output functional block, an event loop functional block (E_CYCLE functional block), and an event merging functional block (E_MERGE functional block).

[0064] Furthermore, the collaborative processing logic between the various functional blocks is described as follows: Figure 4 As shown: the `option` function block processes the input `Mode` parameter (operating mode parameter), outputs the event corresponding to the `mode` parameter, and starts the corresponding operating mode. The `mutisensor` function block processes the input `Sensor` parameter (sensor type parameter), achieving different states through the `Sensor` parameter to implement different algorithm logics (sensor function implementation logic), thus achieving the function of a multi-functional sensor. The `output` function block can process the sensor output according to the input `Mode` parameter (also within the algorithm logic). The `E_CYCLE` function block is used to set the time interval for outputting events based on the externally input `TD1` parameter (time frequency parameter). The `E_MERGE` function block is an event merging function block; an event will be output if at least one of the two input events is triggered.

[0065] In this embodiment, the "Mode" interface in the option function block is used to select the mode. The four integers 1-4 represent four modes. Different numbers trigger different operating modes. Then, "Out" outputs the integer corresponding to the selected operating mode, which is convenient for the "output function block" to perform the corresponding data processing later.

[0066] In this embodiment, the "sensor" in the multisensor function block represents the parameters of different sensors. It uses integers 1, 2, 3, etc. (the specific numbers depend on the number of integrated sensors) to indicate the use of sensors such as ultrasonic ranging sensors, temperature sensors, and humidity sensors. This function block is a basic function block, and its multiple algorithms represent different sensor implementations. Different "sensors" execute different algorithms, indicating different sensors performing different functions. "PIN1", "PIN2", and "PIN3" represent different I / O pin numbers; generally, "PIN1" and "PIN2" pins are used preferentially. "OUTPUT" indicates output.

[0067] In this embodiment, within the output function block, "SetValue" represents the user-defined value, "Mode" indicates the selected mode number, "INPUT" represents the data received from the sensor, and "TimeBase" indicates that in automatic mode, an output event based on the time mode is triggered when the value approaches a certain range from the set value. "OUTPUT" represents normal, unprocessed sensor output, "p_differ" represents the difference between the sensor value and the previous value, and "s_differ" represents the difference between the sensor value and the set value. "QO" indicates whether the output was successful, and "Error" indicates an exception.

[0068] The “E_MERGE” function block is an event merging function block that will output an event as long as any one of the input events is triggered.

[0069] S02. Connect to the dynamic library and establish a dynamic link relationship between the functions in the dynamic library and the I / O interface of the sub-functional module;

[0070] Specifically, in this embodiment, since embedded device applications have been developed for a long time, much of the code for controlling I / O ports is quite mature, and there are many dedicated function libraries available. Therefore, when loading the functional blocks for hardware interaction, this embodiment links to the function libraries suitable for the embedded device, and then directly calls the relevant functions within the functional blocks to achieve writing and reading from the response I / O ports, realizing the corresponding functions of the sensors and actuators. Simultaneously, in the control decision functional blocks, for complex algorithms and models, complex control functions can also be implemented by linking the corresponding dynamic libraries. In this way, this embodiment does not require the development of dedicated library functions, and some of the code running on the sensors and actuators can be directly utilized, requiring only some simple splitting and modification.

[0071] In addition, during component development, custom functions for controlling general I / O ports can be defined and then called when creating function blocks, enabling the creation of sensor function blocks using basic function blocks. Furthermore, a REST-style API is extended based on the OPC UA transport protocol.

[0072] S03. Perform RESTful encapsulation on the application programming interface of the target sensor module after generating the dynamic link relationship to obtain the encapsulated target sensor module.

[0073] Specifically, in the embodiments, such as Figure 5As shown, since REST is a resource-oriented architecture rather than an actual protocol, RESTful must be implemented using other standards such as HTTP, URI, JSON, and XML. Because IEC 61499 defines a set of management commands for performing online device management and reconfiguration services, this patent will use IEC 61499 Management Commands (MGT) to implement data acquisition and reconfiguration services based on RESTful services.

[0074] In some feasible implementations, method step S03 may include steps S031-S032:

[0075] S031. Define the request and response messages of the application interface according to the target management command;

[0076] S032. Collect data and reconfigure services for RESTful services through the defined application programming interface.

[0077] In this embodiment, the target management command is the IEC61499 management command. The IEC61499 management command consists of a pair of XML-formatted request and response messages. The request message is defined as:

[0078] <Request ID=””Action=””>

[0079] ...Request Context...

[0080]

[0081] The ID serves as a unique identifier between the request message and the corresponding response message; the action refers to the management commands for creating, deleting, starting, stopping, terminating, querying, reading, writing, and resetting. This embodiment only uses the read and write actions.

[0082] When the Device Manager processes a request message, it will write a response message according to the IEC 61499 management command definition to return a result. The response message is defined as follows:

[0083] <Response ID=””Reason=””>

[0084] ...Response Context...

[0085]

[0086] Where ID refers to the request message ID; Reason may be one of the following: not ready, unsupported command, unsupported type, overflow, no such object, invalid object, invalid operation, and invalid state.

[0087] For request and response contexts, the elements managed by the Device Manager can be one of the following: FB, connection, FB Type, adapter type, data type, and parameters. In this embodiment, the elements managed by the Device Manager are function blocks.

[0088] In addition, the request messages in the embodiments include synchronous requests and asynchronous requests; furthermore, the process of defining in step S031 may also include step S0311: identifying several asynchronous requests that have the same element by means of parameter identifiers; wherein, the element in the asynchronous request includes at least one of the following: device name, resource name, application name, function block instance name, and variable name.

[0089] Specifically, in this embodiment, the data acquisition service provides direct HTTP access to ERP, MES, and SCADA / HMI systems. To read one or more variables from the industrial controller, the HTTP GET method is used. Since HTTP URIs can only accept text, the IEC 61499MGT request message must be converted from XML to a string. For example... Figure 6 As shown, to read variables from a function block instance on an IEC61499 resource, the following URI is used:

[0090] GET / READ / Parameter? Name= <dev> <res> <app> <fb> <var>&ID= <1>

[0091] in, <dev>Refers to the equipment name. <res>Refers to the resource name in the device. <app>This refers to the name of the application deployed to this resource. <fb>, refers to the function block instance name, <var>Refers to the variable name. <1> ID refers to a unique identifier.

[0092] Parameter names follow the standard IEC 61499 variable naming convention, and parameter IDs are positive integers. Since HTTP requests can be synchronous or asynchronous, parameter IDs must be used in asynchronous mode to identify multiple read requests for the same element. If an FB instance is encapsulated in a composite FB type or a sub-application type, then "." is used to indicate a nested FB structure. For example, as... Figure 6 As shown, in order to read the input IN1 value from device DEV1, resource RES1, application APP1, and FB FB2 in the composite FB FBI, the URI consists of the following:

[0093] GET

[0094] / READ / Parameter? Name=DEV1.RES1.APP1.FB1.FB2.IN1&ID=1

[0095] RESTful services provide several response message formats, including XML, JSON, and even plain text. Since IEC61499MGT commands are defined in XML, these commands can be directly mapped. The response message for IN1 is read from FB DEV1. RES1.APP1.FB1.FB2 is:

[0096] <Response ID=”1”Reason=”OK”>

[0097] <Parameter Reference=”DEV1.RES1.APP1.FB1.FB2.IN1”

[0098] Value = "10" / >

[0099]

[0100] DEV1.RES1.APP1 needs to be filled in according to the actual situation, and the final variable should be filled in according to the actual needs, and the corresponding ID should be changed. In the QUERY function, Type indicates the type of function block, and information such as the current FB instant list, connection list, parameters, and data input / output can be accessed through RESTful services.

[0101] In this embodiment, data acquisition is required from the multi-functional sensor, and its URI is shown in Table 1:

[0102] Table 1

[0103]

[0104] On the other hand, the present application also provides a sensor, which includes:

[0105] The selection function block is used to obtain working mode parameters, output target events according to the working mode parameters, and start the working mode corresponding to the working mode parameters according to the target events;

[0106] A sensor integration function block is used to obtain sensor category parameters and load sensor function implementation logic according to the sensor category parameters;

[0107] An output function block is used to process the sensor output according to the operating mode parameters;

[0108] The event loop function block is used to obtain time frequency parameters and execute the target event cyclically according to the time frequency parameters.

[0109] The event merging function block is used to generate event output when at least one of the two input events is triggered.

[0110] From the above specific implementation process, it can be concluded that the technical solution provided by the present invention has the following advantages or strengths compared with the prior art:

[0111] (1) It reduces the development difficulty of functional blocks and achieves high code reusability. By linking external libraries, it is possible to directly call the APIs in the existing libraries, so there is no need to refactor the code from the root and write the corresponding code library. At the same time, it is also possible to refer to some existing embedded IO control source code, which greatly reduces the development difficulty of functional blocks.

[0112] (2) Improved resource utilization and reusability of functional blocks: By using basic functional blocks to create sensor functional blocks, multiple modes can be created to meet different application environments, improving the versatility of sensor functional blocks. At the same time, some simple data processing functions are added to the sensor functional blocks, which reasonably optimizes the utilization of sensor resources. Meanwhile, its automatic mode can reduce resource consumption to a certain extent.

[0113] (3) By using a component-based service approach, the output results can be accessed through the front end, and the parameters of the functional blocks can be changed by modifying the corresponding APIs, thereby achieving different sensor functions and different modes. Furthermore, although the invention has been described in the context of functional modules, it should be understood that, unless otherwise stated, one or more of the functions and / or features can be integrated into a single physical device and / or software module, or one or more functions and / or features can be implemented in a separate physical device or software module. It is also understood that a detailed discussion of the actual implementation of each module is unnecessary for understanding the invention. Rather, considering the properties, functions, and internal relationships of the various functional modules in the device disclosed herein, the actual implementation of the module will be understood within the scope of conventional technology for an engineer. Therefore, those skilled in the art can implement the invention as set forth in the claims using ordinary techniques without excessive experimentation. It is also understood that the specific concepts disclosed are merely illustrative and are not intended to limit the scope of the invention, which is determined by the full scope of the appended claims and their equivalents.

[0114] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0115] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0116] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

[0117] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.< / var> < / fb> < / app> < / res> < / dev> < / var> < / fb> < / app> < / res> < / dev>

Claims

1. A method for service-oriented packaging of sensor components, characterized in that, Includes the following steps: Construct a target sensor module, which includes several sub-functional modules; Connect to the dynamic library and establish a dynamic link relationship between the functions in the dynamic library and the I / O interface of the sub-functional module; The application programming interface of the target sensor module after generating the dynamic link relationship is encapsulated in a RESTful style to obtain the encapsulated target sensor module. The target sensor module has at least one of the following operating modes: difference-based operating mode, time-based operating mode, automatic operating mode, and default operating mode; The sub-functional modules include: a selection function block, a sensor integration function block, an output function block, an event loop function block, and an event merging function block; The automatic working mode uses both a difference-based working mode and a time-based working mode simultaneously. The method further includes: When the working mode is the difference-based working mode, the target sensor module outputs the first difference between the first measurement value at the current moment and the second measurement value at the previous moment, or outputs the second difference between the first measurement value at the current moment and the first preset value. When the second difference falls within the preset threshold range, the automatic working mode is triggered; The working mode is determined to be an automatic working mode, and the target sensor outputs a fourth measurement value according to a preset second time frequency. The third difference between the fourth measurement value and the first preset value is kept within the threshold range. The method further includes: The selection function block obtains the working mode parameters and outputs the target event based on the working mode parameters. The working mode corresponding to the working mode parameter is activated based on the target event; The sensor category parameter is obtained, and the sensor integrated function block loads the sensor function implementation logic according to the sensor category parameter.

2. The sensor component service packaging method according to claim 1, characterized in that, The method further includes: when the working mode is a time-based working mode, the target sensor module outputs a third measurement value according to a preset first time frequency.

3. The sensor component service packaging method according to claim 1, characterized in that, The method further includes: The event loop function block obtains the time frequency parameter and executes the target event cyclically according to the time frequency parameter.

4. The sensor component service packaging method according to claim 1, characterized in that, The step of encapsulating the application programming interface of the target sensor module after generating the dynamic link relationship in a RESTful style to obtain the encapsulated target sensor module includes: The request and response messages of the application interface are defined according to the target management command; Data collection and service reconfiguration for RESTful services are performed through the defined application programming interface (API).

5. A sensor component service packaging method according to claim 4, characterized in that, The request message includes synchronous requests and asynchronous requests; when the request message is an asynchronous request, the definition of the request message and response message of the application interface according to the target management command includes: A plurality of asynchronous requests that share the same element are identified by parameter identifiers; the element in the asynchronous request includes at least one of the following: device name, resource name, application name, function block instance name, and variable name.

6. A sensor, characterized in that, The sensor is implemented using the sensor component service packaging method as described in any one of claims 1 to 5, and the sensor includes: The selection function block is used to obtain working mode parameters, output target events according to the working mode parameters, and start the working mode corresponding to the working mode parameters according to the target events; A sensor integration function block is used to obtain sensor category parameters and load sensor function implementation logic according to the sensor category parameters; An output function block is used to process the sensor output according to the operating mode parameters; The event loop function block is used to obtain time frequency parameters and execute the target event cyclically according to the time frequency parameters. The event merging function block is used to generate event output when at least one of the two input events is triggered.

Images