CN113190629B

CN113190629B - Method and device for realizing production monitoring management system

Info

Publication number: CN113190629B
Application number: CN202110446474.9A
Authority: CN
Inventors: 覃飞; 李昊夫; 王兆丰; 蔡琛; 刘玉琴; 常宁; 王俊华
Original assignee: Guoneng Zhishen Control Technology Co ltd
Current assignee: Guoneng Zhishen Control Technology Co ltd
Priority date: 2021-04-25
Filing date: 2021-04-25
Publication date: 2024-05-31
Anticipated expiration: 2041-04-25
Also published as: CN113190629A

Abstract

The embodiment of the application discloses a method and a device for realizing a production monitoring management system, wherein the method comprises the following steps: constructing equipment models and corresponding equipment examples of all equipment in a production monitoring management system in an equipment modeling center, and constructing logic structures of all equipment models and equipment examples; the equipment modeling center shares the relevant information of the equipment model and/or the equipment instance in the logic structure to each micro-service module according to the first request information initiated by each micro-service module, and sends the relevant information of the equipment instance to the subsystem instance according to the second request information initiated by the subsystem instance for the communication of the butt-joint bottom layer in the production monitoring management system, so that the subsystem instance can complete preset tasks according to the relevant information of the equipment instance. By the embodiment scheme, the system is operated on an organized model instead of based on scattered measuring points, and maintainability, flexibility, reusability and expansibility of the system are enhanced.

Description

Method and device for realizing production monitoring management system

Technical Field

The present disclosure relates to production management technologies, and in particular, to a method and an apparatus for implementing a production monitoring management system.

Background

The traditional production monitoring and management system is oriented to the measuring points, namely the system is organized and managed in a measuring point mode. All the information, data and the like from bottom to top are uploaded by taking the measuring points as carriers; all top-down instructions and controls are issued by taking the measuring points as carriers; all intermediate links are processed and calculated by taking the measuring points as carriers.

The method has the advantages that all information and data in the system are flat, one data corresponds to one measuring point, and the data is directly acquired, operated and calculated through roll calling, so that the method is simple, direct and visual. The disadvantage is also obvious, that is, all data are tiled, not organized, and have a lack of semantics, and it is quite difficult, if not impossible, to find other things associated with a certain thing, which is disadvantageous for the system to make larger or to realize higher-level functions. Meanwhile, all configurations in the system are seriously coupled with the measuring points, and once the name of the measuring point is changed, all relevant configurations are changed, so that the maintenance and the stability of the system are not facilitated.

Disclosure of Invention

The embodiment of the application provides a method and a device for realizing a production monitoring management system, which can ensure that the system is operated on an organized model instead of being based on scattered measuring points, thereby enhancing the maintainability, flexibility, reusability and expansibility of the system.

The embodiment of the application provides a method for realizing a production monitoring management system, which can comprise the following steps:

Constructing equipment models and corresponding equipment instances of all equipment in a production monitoring management system in the equipment modeling center, and constructing logic structures of all the equipment models and the equipment instances;

The equipment modeling center shares the equipment model and/or related information of the equipment instance in the logic structure to each micro-service module according to first request information initiated by each micro-service module in the production monitoring management system, and sends the related information of the equipment instance to a subsystem instance for interfacing with the underlying communication in the production monitoring management system according to second request information initiated by the subsystem instance, so that the subsystem instance can complete preset tasks according to the related information of the equipment instance.

In an exemplary embodiment of the present application, the building, at a preset device modeling center, a device model and corresponding device instances of all devices in a production monitoring management system may include:

Classifying all the devices in the production monitoring management system, and determining a device model of each type of device;

Determining the corresponding attribute and operation method of each device, and corresponding each device and the attribute and operation method of the device to the corresponding device model;

And adding equipment parameters of corresponding specific equipment in each equipment model, and generating the equipment instance according to the equipment parameters.

In an exemplary embodiment of the present application, the at least one attribute may include one or more sub-attributes; the at least one method of operation may include one or more sub-methods of operation;

both the attribute and the sub-attribute may include: simple attributes and computational attributes;

the simple attribute may refer to: attributes that can be directly associated with the device measurement points;

the calculated attribute may refer to: the attribute is obtained by carrying out preset operation on one or more attributes except the current attribute;

The operating method and the sub-operating method may each include: simple and complex methods;

the simple method may refer to: an operation method capable of directly operating the equipment measuring point;

The complex method may refer to: and calling one or more operation methods except the current operation method, and realizing the operation method through preset logic.

In an exemplary embodiment of the present application, the constructing a logical structure of all the device models and the device instances may include:

Determining a relation between equipment models, and organizing a logic structure between the equipment models according to the relation between the equipment models;

A relationship between the device instance and the device instance is determined, and a logical structure between the device instances is organized according to the relationship between the device instance and the device instance.

In an exemplary embodiment of the present application, the relationship between the device model and the device model may include: total score relationships and/or parent-child relationships;

The relationship between the device instance and the device instance may include: total score relationships and/or parent-child relationships;

the logical structure may comprise a tree structure.

In an exemplary embodiment of the present application, when the relationship between the device model and the device model includes a total score relationship, the device model may include a total model and a score model; the method may further comprise: expressing a reference to the sub-model on the total model, wherein the attribute and the operation method of the sub-model are all defined in the sub-model;

When the relationship between the device model and the device model includes a parent-child relationship, the device model may include a parent model and a child model; the method may further comprise: expressing inheritance relation with the child model on the parent model, and expressing increment of the parent model on the child model; the delta includes both additions and modifications.

In an exemplary embodiment of the present application, the method may further include:

when the attribute comprises a computational attribute and the method of operation comprises a complex method, expressing the computational attribute and the complex method on the device model and the device instance in the form of a function call; and/or the number of the groups of groups,

When the attribute comprises a simple attribute, the operation method is a simple method, a communication point table is imported into the equipment modeling center or generated in the equipment modeling center, and the communication point table is a measurement point list used by the equipment instance for communicating with the bottom layer measurement point.

In an exemplary embodiment of the present application, the first request information may include: a configuration file of the current micro service module; any one or more of the following may be included in the configuration file: device model ID (unique identity), device instance ID, communication point table ID, and desired function.

In an exemplary embodiment of the present application, the method may further include any one or more of the following:

In the subsystem example, simple attributes and simple methods in the acquired related information of the equipment example are arranged, mapping relations between equipment models and measuring points are listed, and a model measuring point mapping table is acquired;

In the subsystem example, all the calculation attributes in the acquired related information of the equipment example are arranged, and the functions corresponding to each calculation attribute are listed to acquire a calculation task table;

in the subsystem example, taking the sub-equipment in the tree structure of the equipment example as a unit, acquiring a plurality of attribute sequence tables required by issuing real-time data, wherein the attribute sequence tables are internally sequenced according to preset fields of attributes.

In an exemplary embodiment of the present application, the preset tasks may include any one or more of the following: the method comprises the steps of bottom communication, value updating in a logic structure of a device instance, real-time data issuing and instruction monitoring.

In an exemplary embodiment of the present application, when the preset task includes an underlying communication, the completing, by the subsystem instance, the preset task according to the related information of the device instance may include: periodically acquiring original real-time data taking measuring points as an organization form according to the communication point table, and storing the real-time data into a real-time data buffer pool taking the measuring points as indexes;

When the preset task includes updating a value in a logical structure of the device instance, the completing, by the subsystem instance, the preset task according to the related information of the device instance may include: periodically taking out real-time data from the real-time data buffer pool according to the model measuring point mapping table, and filling the real-time data into simple attributes of the equipment instance; calculating the calculation attribute on the equipment instance according to the calculation task table, and filling the obtained result into the relevant calculation attribute of the equipment instance;

when the preset task includes real-time data publishing, the completing, by the subsystem instance, the preset task according to the related information of the device instance may include: the method comprises the steps of reserving a real-time data transmission mode taking a measuring point as a unit, periodically transmitting real-time data taking the measuring point as a unit of a subsystem instance, taking out related data from a tree structure of the equipment instance according to a plurality of attribute sequence tables, and packaging the related data into a plurality of real-time data packets according to a preset sequence to be issued to the outside;

When the preset task includes instruction monitoring, the completing, by the subsystem instance, the preset task according to the related information of the device instance may include: periodically, according to the received instruction, judging whether the format of the received instruction is based on a measuring point or equipment, and respectively making different operations according to different judging results; when the format of the instruction is based on the measuring point, the original existing instruction control mode is directly adopted; when the format of the instruction is based on the equipment, the related operation method is called on the logic structure of the equipment model, so that the indirect control of the measuring point is realized.

The embodiment of the application also provides a device for realizing the production monitoring management system, which can comprise a processor and a computer readable storage medium, wherein the computer readable storage medium stores instructions, and when the instructions are executed by the processor, the method for realizing the production monitoring management system is realized.

Compared with the related art, the embodiment of the application can comprise the following steps: constructing equipment models and corresponding equipment instances of all equipment in a production monitoring management system in the equipment modeling center, and constructing logic structures of all the equipment models and the equipment instances; the equipment modeling center shares the equipment model and/or related information of the equipment instance in the logic structure to each micro-service module according to first request information initiated by each micro-service module in the production monitoring management system, and sends the related information of the equipment instance to a subsystem instance for interfacing with the underlying communication in the production monitoring management system according to second request information initiated by the subsystem instance, so that the subsystem instance can complete preset tasks according to the related information of the equipment instance. By the embodiment scheme, the system is operated on an organized model instead of based on scattered measuring points, and maintainability, flexibility, reusability and expansibility of the system are enhanced.

Additional features and advantages of the application will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the application. Other advantages of the application may be realized and attained by the structure particularly pointed out in the written description and drawings.

Drawings

The accompanying drawings are included to provide an understanding of the principles of the application, and are incorporated in and constitute a part of this specification, illustrate embodiments of the application and together with the description serve to explain, without limitation, the principles of the application.

FIG. 1 is a flow chart of an implementation method of a production monitoring management system according to an embodiment of the present application;

FIG. 2 is a schematic diagram of an embodiment of the present application when a device model forms a tree structure;

FIG. 3 is a schematic diagram showing the overall relationship between a device model and a device instance according to an embodiment of the present application;

FIG. 4 is a schematic diagram illustrating inheritance relationships between a device model and a device instance according to an embodiment of the present application;

FIG. 5 is an exemplary relationship diagram of a device model and a device instance according to an embodiment of the present application;

FIG. 6 is a schematic diagram of a multi-version coexistence scheme for a device model or device instance according to an embodiment of the present application;

Fig. 7 is a block diagram of an implementation device of the production monitoring management system according to an embodiment of the present application.

Detailed Description

The present application has been described in terms of several embodiments, but the description is illustrative and not restrictive, and it will be apparent to those of ordinary skill in the art that many more embodiments and implementations are possible within the scope of the described embodiments. Although many possible combinations of features are shown in the drawings and discussed in the detailed description, many other combinations of the disclosed features are possible. Any feature or element of any embodiment may be used in combination with or in place of any other feature or element of any other embodiment unless specifically limited.

The present application includes and contemplates combinations of features and elements known to those of ordinary skill in the art. The disclosed embodiments, features and elements of the present application may also be combined with any conventional features or elements to form a unique inventive arrangement as defined by the claims. Any feature or element of any embodiment may also be combined with features or elements from other inventive arrangements to form another unique inventive arrangement as defined in the claims. It is therefore to be understood that any of the features shown and/or discussed in the present application may be implemented alone or in any suitable combination. Accordingly, the embodiments are not to be restricted except in light of the attached claims and their equivalents. Further, various modifications and changes may be made within the scope of the appended claims.

Furthermore, in describing representative embodiments, the specification may have presented the method and/or process as a particular sequence of steps. However, to the extent that the method or process does not rely on the particular order of steps set forth herein, the method or process should not be limited to the particular sequence of steps described. Other sequences of steps are possible as will be appreciated by those of ordinary skill in the art. Accordingly, the particular order of the steps set forth in the specification should not be construed as limitations on the claims. Furthermore, the claims directed to the method and/or process should not be limited to the performance of their steps in the order written, and one skilled in the art can readily appreciate that the sequences may be varied and still remain within the spirit and scope of the embodiments of the present application.

The embodiment of the application provides a method for realizing a production monitoring management system, as shown in fig. 1, the method can comprise the steps of S101-S102:

S101, constructing equipment models and corresponding equipment examples of all equipment in a production monitoring management system in the equipment modeling center, and constructing logic structures of all the equipment models and the equipment examples;

S102, the equipment modeling center shares the relevant information of the equipment model and/or the equipment instance in the logic structure to each micro-service module according to the first request information initiated by each micro-service module in the production monitoring management system, and sends the relevant information of the equipment instance to the subsystem instance according to the second request information initiated by the subsystem instance for communicating with the bottom layer in the production monitoring management system, so that the subsystem instance can complete preset tasks according to the relevant information of the equipment instance.

In the exemplary embodiment of the application, compared with the traditional production monitoring management system based on measuring points, the production monitoring management system based on equipment modeling is the biggest difference in that the organization mode of the system to data and information is changed from the original traditional measuring point mode to the equipment mode, and the flat unstructured information and data in the original traditional system are organized into a meaningful real-world model according to the association relation between the data and the data.

In the exemplary embodiment of the application, the production monitoring management system based on equipment modeling can be used for constructing a complete equipment modeling implementation scheme by 1) constructing an equipment model, 2) constructing an equipment instance, 3) analyzing and designing 9 aspects of equipment model and equipment model, equipment instance and equipment instance, relation between equipment model and equipment instance, 4) representing and storing the equipment model, equipment instance and relation, 5) binding between underlying communication and equipment model, 6) calculating functions and custom functions, 7) equipment modeling related interfaces, 8) introducing the whole operation flow of the system after equipment modeling, 9) thermally updating the equipment model and the equipment instance and the like.

In the exemplary embodiment of the application, the scheme ensures that the operation of the system is not based on scattered measuring points, but operates on an organized model, so that the acquisition, operation and operation of each part inside and outside the system are based on the model, the maintainability, flexibility, reusability and expansibility of the system are enhanced, the semanteme of the system is enhanced more remarkably, and the logic and relationship inside and outside the system are clearer and more visual through the semanteme data representation and operation mode, and the system is more stable and robust.

The following describes in detail how a production management system based on equipment modeling can be implemented, taking an actual production monitoring management system as an example.

1. Location of device modeling center in overall architecture

In the exemplary embodiment of the present application, the device concept is introduced, which is a big change to the data organization manner in the system, so each module related to the data (such as each micro-service module) is affected by the change, that is, corresponding modification and adjustment are needed to be made to the data organization manner of the device concept.

In the exemplary embodiment of the present application, in order to enable all modules related to the device concept in the system to uniformly and orderly obtain consistent device information, so as to ensure that the subsequent operation based on the device is normal and consistent, an independent place is required to uniformly distribute the device information for all the related modules of the device, so that a device modeling center can be established based on the original modules (such as each micro-service module) of the system.

2. Function and implementation of device modeling center

In an exemplary embodiment of the present application, functions of the device modeling center mainly include: creating and managing a device model; generating and managing equipment instances; and configuring and managing the communication point table and distributing the various information.

21. Expression and various relations between equipment model and equipment instance

In an exemplary embodiment of the present application, the core of the device concept is to build models of all devices in a system and generate instances of corresponding devices, so that organization of data is achieved through the device models and the device instances.

In an exemplary embodiment of the application, the so-called device model and device instance are somewhat similar to the concept of classes and objects in object-oriented ideas. The equipment model is the generalization and abstraction of some equipment, which is equivalent to the class of some equipment; the device instance is a specific device of a certain type of device, is an instantiation of a device model, and is equivalent to an object.

1) Structure and combination relationship of equipment model (or equipment instance)

the logical structure may comprise a tree structure.

In an exemplary embodiment of the present application, the device model and the device instance may each be organized in a tree structure, the logical structure of which is shown in fig. 2.

In an exemplary embodiment of the present application, each device may contain its own attributes, its own operation method, and sub-devices, as shown in fig. 2. The sub-device is also a device, so that the sub-device may continue to contain attributes, methods of operation, and sub-devices. Until the bottommost child device no longer contains smaller child devices, only the attributes and methods of operation. The relationship between the parent device and the child device, which is not inherited, is a combined or contained relationship.

In an exemplary embodiment of the present application, if a certain attribute is directly associated with a certain measurement point, it may be referred to as a simple attribute. If a certain operating method is to directly operate a certain measuring point, it can be called a simple method. For simple attributes and simple methods, the associated measurement points do not belong to the equipment model, but rather belong to the specific equipment instance instantiated by the model, so the simple attributes and simple methods are defined and stored in the equipment instance. The name of the measurement point associated with the simple attribute can be stored in a measurement point field set under the simple attribute; the measurement point operation information associated with the simple method can be stored in a function field set under the simple method, the expression form can be a form of function call, and the parameter can be a certain measurement point, for example, set_1 (pnt _1).

In an exemplary embodiment of the present application, an attribute may be referred to as a calculated attribute if it is required to be obtained by a certain operation through other attributes. A complex method may be referred to as a method if the implementation of an operation method requires the invocation of other operation methods and the implementation of certain logic. For computational properties and complex methods, the logic is part of the device model, so they can be defined and saved in the device model. The saved location may be a function field set under the attribute and method of operation. The expression form may also be in the form of a function call, and the parameter may be other attribute names of the same layer or lower layer, such as add (model_1. Pore_1, model_2. Prop_2).

In an exemplary embodiment of the present application, the attribute and the operation method may further have a layer of child nodes as child attributes. Different types of attributes and methods of operation may have different types of sub-attributes. For a simple attribute, its sub-attributes may be: sequence number, value, default value, quality, time scale, type, unit, description, measurement point; for a computational attribute, its sub-attributes may be: sequence number, value, default value, type, unit, description, function, measurement point; for a static attribute, its sub-attributes may be: value, unit, description, whether modifiable; for a simple method, its sub-attributes may be: describing and functioning; for complex methods, its sub-attributes may be: description, function.

In the exemplary embodiment of the present application, the above design can effectively express the composition relation and hierarchy of the devices in the real world.

2) The combined relationship (total-score relationship, or called total-score relationship) of the equipment model (or equipment instance)

In an exemplary embodiment of the present application, when the relationship between the device model and the device model includes a total score relationship, the device model may include a total model and a score model; the method may further comprise: a reference to the sub-model is expressed on the total model, the properties and methods of operation of the sub-model itself being defined entirely within itself.

In an exemplary embodiment of the present application, for the expression of the combination relationship between the total model and the split model, only the reference to the split model may be expressed on the total model based on the principle of decoupling, and the specific content of the split model itself may be defined in its own interior.

In an exemplary embodiment of the present application, as shown in FIG. 3, the left side is the total model model_1:1, and the right side is a sub model model_2:1 used by the total model. The contents of the sub_device_1 field of model_1:1 represent that its sub-device 1 is a model_2:1 type of sub-model. In the manner shown in FIG. 3, the reference of the overall model model_1:1 to the split model model_2:1 is implemented, and the representation of the combination relationship between model_1:1 and model_2:1 is further implemented.

3) Inheritance relationship of device model (father-son relationship)

In an exemplary embodiment of the present application, when the relationship between the device model and the device model includes a parent-child relationship, the device model may include a parent model and a child model; the method may further comprise: expressing inheritance relation with the child model on the parent model, and expressing increment of the parent model on the child model; the delta includes both additions and modifications.

In an exemplary embodiment of the present application, there are inheritance relationships among the device models in addition to the most intuitive combination relationships. As one of the object-oriented core concepts, inheritance relationships express the process of gradual refinement and gradual clarity of the device model.

In the exemplary embodiment of the present application, since the inheritance relationship is equivalent to further refinement, further clear description and modification of the child model on the basis of the parent model in a sense, the inheritance relationship between the parent model and the child model is regarded as an increment of the child model relative to the parent model (for inheritance, the increment should be increased and modified only, and should not be deleted) for expression and storage.

In an exemplary embodiment of the present application, as shown in FIG. 4, the left side is the parent model model_1:1 and the right side is the child model model_3:1 derived from model_1:1. It can be seen that only the part of model_3:1 that is expressed in model_3:1 changes relative to model_1:1, thus representing the inherited meaning, while avoiding the repeated expression and storage of common parts. The representation of the inheritance relationship of the child model model_3:1 to the parent model model_1:1 is achieved in the manner shown in FIG. 4.

4) Instantiation relationship of a device model to a device instance

In an exemplary embodiment of the application, between the device model and the device instance is an instantiation relationship similar to that between the class and the object. The instantiation relationship is in a sense a process of supplementing some information related to a specific device on the device model, so the representation of the instantiation relationship can refer to the manner in which objects are instantiated out of a class in an object-oriented manner, namely, the manner of transferring references.

In an exemplary embodiment of the present application, as shown in FIG. 5, the left side is the device model_1:1 and the right side is the device instance instance_1:1 instantiated from model_1:1. Only the parameters of the model_1:1 that need to be instantiated into the corresponding model model_1:1 need be expressed in instance_1:1.In actual operation, the device model model_1:1 uses these parameters to generate a truly complete device instance instance_1:1.

5) Concurrent multiple versions of a device model (or device instance)

In an exemplary embodiment of the present application, if the device model (or device instance) itself is modified, the modification may be expressed and stored in a multi-version concurrent manner. The multi-version coexistence is that the version before modification does not disappear and is still stored in the system; and the modified new version is also stored in the system as an updated version. Multiple new and old versions of the same equipment model (or equipment instance) coexist in the system. After a certain model or instance is updated, other equipment models or equipment instances using old versions of the equipment model or equipment instance cannot be affected, and unpredictable effects are avoided. Meanwhile, if other equipment models or equipment instances want to apply the change of a certain equipment model or equipment instance, the equipment model or equipment instance can be explicitly updated to generate a new version of the equipment model or equipment instance so as to apply the change of the equipment model or equipment instance. The multi-version coexistence may be as shown in fig. 6.

In an exemplary embodiment of the present application, as shown in FIG. 6, the left side is the device model model_1:1 (this representation represents version 1 of model_1), the right side is the modified model model_1:2 (version 2 of model_1), and both models_1:1 and model_1:2 will coexist in the system and be fully stored. The presence of model_1:2 does not affect the model or instance originally inherited or combined or instantiated from model_1:1. If the device model or device instance from model_1:1 wants to apply the changes brought by model_1:2, explicit re-inheritance, combination, or instantiation of model_1:2 is required.

In the exemplary embodiment of the present application, it should be noted that, two program modules in any one of fig. 3, fig. 4, fig. 5, and fig. 6 are embodiments for indicating the representation modes of different device models, and the specific content is not limited to the solution of the embodiment of the present application, and whether the specific content is clear does not affect the disclosure of the embodiment of the present application.

22. Storage of device models and device instances

In an exemplary embodiment of the present application, the device model and the device instance may both be represented and used in a system in a tree structure (dictionary form), and both may be stored in a relational database in a persistent manner in the device modeling center. While various relationships between device models or device instances may also be recorded and expressed through a relational database.

In an exemplary embodiment of the present application, two tables, one device model table and one device instance table, may be established for storing device models and device instances.

1) The device model table structure may be as follows:

Wherein the Id field represents the model number, type int, self-increment;

The Name field represents the model Name, type str;

The Content field represents the model Content, type str; the Content stored in the Content field can be a JSON format character string after serialization of the device model;

the Version field represents the Version of the model, type int;

the Parent field represents the Parent model id inherited by the model, and the type int can be used for representing inheritance relationship;

the Compose field indicates the list of upper model ids used by the model, type str, which can be used to indicate the upper models to which it is referenced, and the upper model ids can be separated by commas;

The Member field represents a list of all Member model ids of the model, types str, which may be used to indicate all Member models that make up the model, and Member model ids may be separated by commas.

2) The device instance table structure is as follows:

wherein, id field represents the instance number, type int, self-increment;

The Name field indicates the instance Name, type str;

The Content field represents instance Content, the type str and the Content stored in the Content field can be a JSON format character string after instance serialization;

the Version field indicates the Version of the instance, type int;

The Model field represents the Model id to which the instance belongs, and the type int can be used for representing the Model corresponding to the instance;

The version_m field represents the Version of the model to which it corresponds, type int;

compose field indicates the upper layer instance id to which the instance belongs, type int;

the Member field indicates a list of all Member instances of an instance, a type str, which may be used to indicate all Member instances that make up the instance, member instance ids may be separated by commas;

the PntTable field indicates the name of the communication point table corresponding to the instance, and the type str.

23. Custom function library

when the attribute comprises a computational attribute and the method of operation comprises a complex method, the computational attribute and the complex method are expressed on the device model and the device instance in the form of a function call.

In an exemplary embodiment of the present application, the expression of the computing task and the operation method on the device model and the device instance may take the form of function call, that is, the form of add (model_1. Pore_1, model_2. Prop_2). The original purpose of this design is to meet the complex demands of computational attributes and complex methods. The implementation principle is as follows: when the system finds that a certain attribute is a calculation attribute or a certain method is a complex method, a corresponding function calling expression can be called, and a function corresponding to the function calling expression can be preset locally on a user or in a device modeling center if the function calling expression is more general, and can be customized in the device modeling center by a user if the function calling expression is more specific. The functions, whether preset by the system or user-defined, can be stored in a custom function library in the device modeling center. After other modules (such as each micro-service module) load the device model and the device instance, the user-defined function is traversed, and then the user-defined function body is loaded in the past by an RPC (Remote Procedure Call Protocol-remote procedure call protocol) mode, so that all requirements of users can be flexibly met.

In the exemplary embodiment of the present application, based on the implementation of the custom function library, various custom functions can be saved in the form of a database. The custom function table structure may be as follows:

wherein, id field represents the function label, type int, self-increment;

The Name field represents the function Name and the type str, and the function Name is used as a unique identifier of the function in the system, and a parameter list is not carried, so that the function with a heavy Name cannot be carried out in the system, and meanwhile, if the function Name is overloaded, the function names are ensured to be different as much as possible, so that the system is simplified;

The Content field indicates the Content of the function, type str, in which the string of the function Content is held (not compressed, format characters are also held).

24. Communication point table

In an exemplary embodiment of the present application, the communication point table is a list of measurement points for the subsystem instance to communicate with the bottom layer, and the simple attribute and the measurement point filled in the simple method on the device instance are all from the communication point table. The communication point list is preferably also imported or generated in the equipment modeling center and then distributed to the relevant subsystem instance.

In an exemplary embodiment of the present application, the communication point table is generally represented and stored in the form of a csv file, and its table structure may be defined according to requirements of subsystem instance when in use. No specific structure is given here.

25. Model measurement point mapping table and calculation task table

1) Mapping table of model measuring points

In the subsystem example, the obtained simple attribute and simple method in the related information of the equipment example are arranged, the mapping relation between the equipment model and the measuring point is listed, and the model measuring point mapping table is obtained.

In an exemplary embodiment of the application, the model site mapping table is not generated at the device modeling center, but is organized in the subsystem instance according to simple attributes and simple methods on the device instance. The method has the effect of more intuitively arranging the mapping relation between the model and the measuring points, and conveniently updating the relevant attribute on the model after the values of the relevant measuring points are taken. The table structure design can be as follows:

Wherein, the id field is the number, type int;

the Name field is a simple attribute Name, the type str, and the attribute names can be represented by a dot number separation mode, such as model sub_model prop;

The Pnt field is a measurement point, and the type str indicates the measurement point corresponding to the attribute.

2) Computing task table

In an exemplary embodiment of the application, the calculation task table is also sorted in the subsystem instance according to the function sub-attributes of the calculation attributes on the device instance. The method has the effect of sorting all the calculation attributes in the equipment instance, and is convenient for executing all calculation tasks in each period. The order of computing tasks in the computing task table may be arranged in the order of traversing the device instance tree back root. The table structure is designed as follows:

wherein, the id field is the number, type int;

the Name field is a calculated attribute Name, the type str is represented by a dot number separation mode, such as model sub_model prop;

The Func field is a function, a type str, which represents a calculation function corresponding to the calculation attribute, and the representation of the calculation function is represented by a form of function call, wherein real parameters are represented by a point number separation manner, for example, add (model. Prop1, model. Prop2).

3. Slight change of overall operation flow of system after equipment modeling center is introduced

31. The user first completes the design of the equipment model, the generation of the equipment instance and the configuration of the communication point table in the equipment modeling center.

32. Before other modules are started, the required equipment model names, equipment instance names, communication point table names and the like need to be written in the configuration files in advance.

33. After other modules are started, first request information is sent to the equipment modeling center, and corresponding equipment models, equipment instances, communication point tables and related custom functions are requested to the equipment modeling center in an RPC mode of the MQ according to the content in the configuration items.

The first request information may include: a configuration file of the current micro service module; any one or more of the following may be included in the configuration file: device model ID, device instance ID, communication point table ID, and desired function.

34. After the related model, instance or point table in the equipment modeling center is changed, the equipment modeling center informs the related module in an RPC mode of the MQ, and asks the equipment modeling center to acquire related equipment information again, and the related equipment information is loaded thermally and dynamically changed.

4. Device modeling center related interface

41. RPC interface for device information request

42. RPC interface for notifying after device information change

5. Related operational flow for introducing device modeled subsystem instance

In the exemplary embodiment of the present application, after device modeling is introduced, the greatest effect on subsystem instances is that the data organization mode is changed from the original measurement point form to the device form, or the form that the measurement points coexist with the device. Because the subsystem instance is a first gateway for communication with the bottom layer, and is also a module with the closest relationship with the real-time data, such as real-time data uploading, instruction issuing and the like, the operation flow of the subsystem instance can be greatly influenced after equipment modeling is introduced.

In an exemplary embodiment of the present application, specifically, the operation flow of the subsystem instance may include:

51. the subsystem instance may first request (i.e., via the aforementioned second request information) from the device modeling center, after being started, its own related device instance (complete tree structure) and communication point table.

52. After the equipment related information (mainly equipment instance) is obtained, the equipment instance can be traversed, a model measuring point mapping table and a calculation task table are arranged according to each attribute and measuring point or function of an operation method, and a user-defined function is obtained from an equipment modeling center in an RPC mode.

53. According to the tree structure of the device instance, the sub-devices are used as units to sort out a plurality of attribute sequence tables to be used when real-time data are released, and the attribute sequence tables can be ordered according to the seq fields of the attributes.

54. The first thread can be responsible for the communication of the bottom layer, the mode is unchanged, the most original real-time data taking the measuring points as an organization form is periodically obtained according to the communication point table, and the real-time data are put into the original real-time data buffer pool taking the measuring points as an index.

55. The second thread can be responsible for updating the value on the equipment instance tree, and periodically, firstly, according to the model measuring point mapping table, real-time data is taken out of the real-time data buffer pool and is filled into the simple attribute of the equipment instance; and calculating the calculation attribute on the equipment instance according to the calculation task table, and filling the obtained result into the related calculation attribute of the equipment instance.

56. The third thread can be responsible for real-time data release, periodically, i.e. a binary real-time data transmission mode taking the measuring point as a unit is reserved, real-time data (forward compatibility) taking the measuring point as a unit of the whole transmission subsystem instance is simultaneously taken out of the equipment instance tree according to a plurality of attribute sequence tables, and the related data are sequentially packed into a plurality of binary real-time data packets and are released outwards through a topic mode of an MQ (message queue). Namely, the real-time data organized by taking the measuring point as a unit and the real-time data organized by taking the equipment as a unit are sent simultaneously. When the device is released, if a measuring point which cannot be summarized on the device tree exists, the measuring point can be directly hung on root equipment, and the attribute name is roll call, so that mixed transmission of the device and the measuring point is realized by phase change.

57. The fourth thread may be responsible for instruction snooping, periodically, based on the received instructions, determining whether the format of the instructions is station-based or device-based, and performing different operations, respectively. If the control is based on the measuring point, the original existing instruction control mode is directly carried out; if the method is based on the equipment, calling a related method on the equipment tree, and indirectly realizing the control of the measuring point.

58. After receiving the real-time data, the subscriber of the real-time data can request the subsystem instance through the RPC mode of the MQ if no corresponding point table (measuring point mode) or attribute sequence table (equipment mode) is found, then analyze the real-time data and buffer the real-time data into a local real-time data buffer pool (for the measuring point mode) or synchronously update the data into an equipment instance tree (for the equipment mode).

6. Method for hot updating equipment model and equipment instance

In the exemplary embodiment of the present application, the thermal updating of the device model and device instance is an important matter, because during the system operation, the device model and device instance may inevitably undergo changes during operation, so how to dynamically and atraumatically update the modules used to the device model and device instance is an important issue.

In an exemplary embodiment of the present application, in particular, a difficulty with device model and device instance updates is how to retain previously meaningful statistics. Because if the original equipment tree is real-time data and real-time calculation, and certain statistical data which needs to be reserved does not exist, the model, the instance and the point table can be completely replaced directly, and the next period is completely started from the new one. But if some statistics on the original device tree need to be migrated to the new device tree, the problem that the data cannot be lost needs to be considered.

In an exemplary embodiment of the present application, a specific implementation may include: and generating a migration table of data attributes to be reserved at the same time when each equipment instance is changed, wherein the migration table can be expressed and stored in the form of a csv file. The migration table format may be as follows:

wherein, the id field represents the number, the type int and the self increment;

The Source field represents a Source attribute name to be migrated on the original equipment tree, and the type str can be represented in a point number separation mode, such as model sub_model prop;

the Target field indicates the name of the Target attribute to be migrated on the new device tree, and the type str can be also indicated by a dot-number separation mode, such as model.

When the equipment model or the equipment instance is subjected to thermal updating, the data retention requirement in the thermal updating can be met by copying the value of the source attribute on the old equipment tree into the target attribute of the new equipment according to the migration entry recorded in the migration table.

In an exemplary embodiment of the application, the embodiment of the application is based on a production monitoring management system of equipment modeling, introduces the equipment modeling concept into production monitoring management, and provides an implementation scheme of the equipment modeling in the field of production monitoring management. The whole system is semantically modeled through the device modeling idea, semantic organization is carried out on data and information in the system, digital twin virtual devices which are in one-to-one correspondence with real devices in the real world are built in the system, and a complete virtual system which is twin with the real system in the real world is further built.

In an exemplary embodiment of the present application, a plant modeling based production monitoring management system includes at least the following advantages over conventional site based production monitoring management systems:

1. The system quality and convenience are better. The production monitoring management system based on equipment modeling enables the design and the use of the system to be more fit with the real world, the system designed by taking the real world as a model has better quality, is more convenient to realize more complex and advanced functions, and is more natural and convenient in the use process.

2. The operation efficiency and the stability are better. The production monitoring management system based on equipment modeling enables the operation of the system to be more fit with the real world, and the system operated according to the rules of the real world has higher efficiency and is more stable and robust.

3. The maintainability is better. The production monitoring management system based on equipment modeling has the advantages that all information in the system is organically integrated together to form real equipment corresponding to the real world one by one, when the system needs to be modified or maintained, the corresponding equipment can be positioned quickly, the maintenance is limited to a local part, the maintenance efficiency is improved, and the maintenance cost is reduced.

4. The flexibility, reusability and expansibility are better. The production monitoring management system based on equipment modeling organizes information in an equipment mode and has the characteristics of high cohesion and low coupling. When the combination is needed to be changed among the system devices, the combination can be more flexibly carried out; when some equipment needs to be multiplexed, multiplexing can be more conveniently performed; meanwhile, when the system needs to be expanded, new equipment can be more conveniently created and added in the same equipment modeling mode.

In an exemplary embodiment of the application, the production monitoring management system based on equipment modeling reorganizes information in a manner conforming to the real world, enables the system to work and operate in a manner conforming to the real world, enables the outside world to interact with the system in a manner conforming to the real world, is more convenient to maintain and realize higher-level functions, and provides a better implementation manner for the traditional production monitoring management system.

The embodiment of the present application further provides an implementation apparatus 1 of a production monitoring management system, as shown in fig. 7, may include a processor 11 and a computer readable storage medium 12, where the computer readable storage medium 12 stores instructions, and when the instructions are executed by the processor 11, implement a method of implementing any one of the production monitoring management systems described above.

In the exemplary embodiment of the present application, any of the foregoing method embodiments are applicable to the device embodiment, and are not described herein in detail.

Those of ordinary skill in the art will appreciate that all or some of the steps, systems, functional modules/units in the apparatus, and methods disclosed above may be implemented as software, firmware, hardware, and suitable combinations thereof. In a hardware implementation, the division between the functional modules/units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be performed cooperatively by several physical components. Some or all of the components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software may be distributed on computer readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media). The term computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data, as known to those skilled in the art. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computer. Furthermore, as is well known to those of ordinary skill in the art, communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media.

Claims

1. A method for implementing a production monitoring management system, the method comprising:

Constructing equipment models and corresponding equipment examples of all equipment in a production monitoring management system in a preset equipment modeling center, wherein the equipment models and the corresponding equipment examples comprise: classifying all the devices in the production monitoring management system, and determining a device model of each type of device; determining the corresponding attribute and operation method of each device, and corresponding each device and the attribute and operation method of the device to the corresponding device model; adding equipment parameters of corresponding specific equipment in each equipment model, and generating the equipment instance according to the equipment parameters;

Constructing a logical structure of all the device models and the device instances, including: determining a relation between equipment models, and organizing a logic structure between the equipment models according to the relation between the equipment models; determining a relation between equipment instances and organizing a logic structure between the equipment instances according to the relation between the equipment instances;

2. The method of claim 1, wherein the at least one attribute comprises one or more sub-attributes; the at least one method of operation includes one or more sub-methods of operation;

The attributes and the sub-attributes each include: simple attributes and computational attributes;

The simple attribute refers to: attributes that can be directly associated with the device measurement points;

the calculated attribute refers to: the attribute is obtained by carrying out preset operation on one or more attributes except the current attribute;

The operation method and the sub-operation method each include: simple and complex methods;

The simple method is as follows: an operation method capable of directly operating the equipment measuring point;

The complex method is as follows: and calling one or more operation methods except the current operation method, and realizing the operation method through preset logic.

3. The method of claim 1, wherein the relationship between the equipment model and the equipment model comprises: total score relationships and/or parent-child relationships;

The relationship between the equipment instance and the equipment instance comprises: total score relationships and/or parent-child relationships;

the logical structure comprises a tree structure.

4. The method of implementing a production monitoring management system according to claim 3, wherein when the relationship between the equipment model and the equipment model includes a total score relationship, the equipment model includes a total model and a score model; the method further comprises the steps of: expressing a reference to the sub-model on the total model, wherein the attribute and the operation method of the sub-model are all defined in the sub-model;

when the relationship between the equipment model and the equipment model comprises a father-son relationship, the equipment model comprises a father model and a son model; the method further comprises the steps of: expressing inheritance relation with the child model on the parent model, and expressing increment of the parent model on the child model; the delta includes both additions and modifications.

5. The method of implementing a production monitoring management system of claim 2, further comprising:

6. The method of implementing a production monitoring management system according to claim 5, further comprising any one or more of:

7. The method for implementing a production monitoring management system according to claim 6, wherein the preset tasks include any one or more of the following: the method comprises the steps of bottom communication, value updating in a logic structure of a device instance, real-time data issuing and instruction monitoring.

8. The method for implementing a production monitoring and management system according to claim 7, wherein,

When the preset task includes the communication of the bottom layer, the subsystem instance completing the preset task according to the related information of the equipment instance includes: periodically acquiring original real-time data taking measuring points as an organization form according to the communication point table, and storing the real-time data into a real-time data buffer pool taking the measuring points as indexes;

When the preset task includes updating a numerical value in a logic structure of an equipment instance, the subsystem instance completes the preset task according to the related information of the equipment instance, and the method includes: periodically taking out real-time data from the real-time data buffer pool according to the model measuring point mapping table, and filling the real-time data into simple attributes of the equipment instance; calculating the calculation attribute on the equipment instance according to the calculation task table, and filling the obtained result into the relevant calculation attribute of the equipment instance;

When the preset task includes real-time data release, the subsystem instance completing the preset task according to the related information of the device instance includes: the method comprises the steps of reserving a real-time data transmission mode taking a measuring point as a unit, periodically transmitting real-time data taking the measuring point as a unit of a subsystem instance, taking out related data from a tree structure of the equipment instance according to a plurality of attribute sequence tables, and packaging the related data into a plurality of real-time data packets according to a preset sequence to be issued to the outside;

When the preset task includes instruction monitoring, the subsystem instance completing the preset task according to the related information of the equipment instance includes: periodically, according to the received instruction, judging whether the format of the received instruction is based on a measuring point or equipment, and respectively making different operations according to different judging results; when the format of the instruction is based on the measuring point, the original existing instruction control mode is directly adopted; when the format of the instruction is based on the equipment, the related operation method is called on the logic structure of the equipment model, so that the indirect control of the measuring point is realized.

9. An implementation device of a production monitoring management system, comprising a processor and a computer readable storage medium, in which instructions are stored, characterized in that the implementation method of the production monitoring management system according to any one of claims 1-8 is implemented when the instructions are executed by the processor.