We have entered the era of AI big data, whether it is an industrial automation system or an Internet of Things system. The collection, storage and analysis of big data are very important. Big data is called the oil of industry, and the continuous improvement of the future manufacturing industry is inseparable from big data.
In traditional applications, the storage of historical data is based on a specific data structure to store historical data. Different manufacturers and different applications have different data storage formats. In industrial control and Internet of Things application projects, the workload of the database occupies a large part of the design work
From the viewpoint of open automation, system data should adopt an open, standard data model, such as OPC UA information model. Based on a standardized data model, devices and software from different manufacturers are interoperable.
In an open system, it is very important to construct a common, model-based historical database. This blog post explores topics related to the OPCUA historian.
On the other hand, the OT field attaches great importance to system security, and it is risky to completely expose OT to IT systems. A safer approach is to have a unified access point to access OT data. This requires aggregating field data to an aggregation server.
In the previous blog post, I have introduced aggregation server and historical data server, you can read:
OPCUA aggregation server and historical data server
In this article we further explore the specifics of implementing a historian and aggregation server.
Access content of OPCUA historical data
Historical data access is mentioned in various parts of the OPC UA specification.
- OPC 10000-5: UA Part 5: Information Model 5.3 Variables
- OPC 10000-11: UA Part 11: Historical Access
- OPC 10000-4: UA Part 4: Services
Historizing property
In the UA Part5 5.3 variable specification, it is pointed out that each variable in the information model can have a Historizing attribute. When the attribute is true, it means that the variable has historical data.
This shows that the value of this attribute is related to the server, and I don't know what it means. This is how the historizing attribute is set in Open62541.
UA_VariableAttributes attr = UA_VariableAttributes_default;
UA_UInt32 myUint32 = 0;
UA_Variant_setScalar(&attr.value, &myUint32, &UA_TYPES[UA_TYPES_UINT32]);
attr.description = UA_LOCALIZEDTEXT("en-US","myUIntValue");
attr.displayName = UA_LOCALIZEDTEXT("en-US","myUIntValue");
attr.dataType = UA_TYPES[UA_TYPES_UINT32].typeId;
/* We set the access level to also support history read
* This is what will be reported to clients */
attr.accessLevel = UA_ACCESSLEVELMASK_READ | UA_ACCESSLEVELMASK_WRITE | UA_ACCESSLEVELMASK_HISTORYREAD;
/* We also set this node to historizing, so the server internals also know from it. */
attr.historizing = true;
Reading and writing of historical data
HistoryRead and HistoryUpdate are specified in OPC 10000-4: UA Part 4: Services
Allows clients to read node values and events.
Allows the Server to update historical data and events.
Details of the parameters are specified in OPC 10000-11: UA Part 11: Historical Access.
maxAge
timesStampsTo Return Returns the timestamp format.
In Open62641, use UA_Client_HistoryRead_raw call
UA_StatusCode
UA_Client_HistoryRead_raw(UA_Client *client, const UA_NodeId *nodeId,
const UA_HistoricalIteratorCallback callback,
UA_DateTime startTime, UA_DateTime endTime,
UA_String indexRange, UA_Boolean returnBounds, UA_UInt32 numValuesPerNode,
UA_TimestampsToReturn timestampsToReturn, void *callbackContext)
Integration of OPCUA Server and Historical Database
Where is historical data stored? What kind of data format is used to store it in the database? This is not the content of the OPCUA specification, it is related to the system architecture and products. They are roughly divided into two types:
Historian embedded in field devices
The historical data storage function embedded in many industrial controllers and instruments, for example, in smart meters, will store hundreds of waveform data values, and the upper layer software can analyze the waveform data, analyze malicious load and other phenomena. Industrial controllers generally use a small SD card to store on-site data, which has a relatively small capacity and a short storage time. Usually, a special format file system is used instead of a database for data storage. The advantage of this embedded historical data storage is that the stored data is very block. The disadvantage is that the upper layer software is relatively slow to read historical data. And reading a large amount of historical data will disturb the normal operation of the real-time control. Especially when the historical data of multiple devices needs to be read at the same time, the occupied network bandwidth is intolerable.
Also, not all field devices support embedded storage.
Build historical data storage in the cloud or edge devices
Another way is to set up an independent database device in the cloud or on site. For example, install influxDB, MySQL, mongoDB and other databases on a separate computer. All field devices send updated data to the historian database. Application software can directly access the historical database.
This architecture is similar to the well-known OSISoft (now part of Schneider AVEVA) PI Server. OSISoft's PI server has a history of more than 30 years. OSIsoft's business is mainly oriented to six core markets: oil and gas, public utilities, life sciences and biopharmaceuticals, metals and mining, pulp and paper, and water.
PI Server is based on two parts called Asset Framework (AF) Server and PI Database. The so-called AF is a model library. By accessing the AF server, you can find the corresponding data pointer and read the historical data in PI.
But it is a pity that the AF model of the PI system is not the OPCUA model. If you design a historical data server similar to PI System and support OPCUA, you can use the OPCUA information model to replace the AF asset architecture. In this way we can build an open historical database system.
The implemented system architecture is as follows:
Note: Historian server and Database can be deployed on the same computer or in the cloud. This computer provides three interfaces:
OPC UA Client
Data read via on-site OPC UA Server
OPCUA Server
Application software can access real-time data from industrial sites as well as historical data.
database access interface
In order to make the access of historical data more efficient, the interface of the database can directly access the data. At the same time, it can prevent the access to the historical database from affecting the real-time performance of the field network.
aggregation server
Historical databases are often combined with aggregation servers. Aggregation server + history server form a complete large-scale model of an industrial site. It is a panoramic snapshot of the control scene. They are all data that TI applications can access to control the field.
From the specifications of the OPCUA aggregation server, it seems very complicated to realize the aggregation of servers. The basic model is as follows:
Multiple Aggregated Servers are included in the aggregation server. Some applications create a Servers folder and put all source servers inside. They include parameters such as ServerUrl and EndPoint. In each Server, contains the objects that need to be aggregated. The names of these objects should be the same as the corresponding objects in the origin server. When it is necessary to read the values of these objects, read them from the source server through OPCUA Client.
In the figure below, the aggregation server is on the left and the source server is on the right
aggregation method
Implemented using configuration files
Using the user's configuration file, the objects to be aggregated can be fully described, including the server's URI and Endpoint parameters. Some projects also specify which objects need to be polled, which need to be subscribed, and which need to be Monitored. Generally use json as the configuration file format.
Implementation by Prosys
Create a replica server instance for all on-site source servers in the aggregation server. For example, in the figure below, two copies of the source server are established:
’Prosys OPC UA Sample Console Server
’Prosys OPC UA Simulation Server
algorithm
The program scans the variables and attributes in Servers to access the value in the source server with the same name. Write it into the corresponding variable of the aggregation server.
But this will encounter a problem, such as objects with the same name in two server instances, such as MyDevice in the above figure. The way they take is to use different address space Index.
In the above figure, ns=20 of one MyDevice and ns=26 of the other.
Of course, there is also the issue of aggregation of events and methods. It must be solved in a similar way.
In addition, all server entries (Endpoints) should be reserved in the aggregation server. Information such as the IP address and port of the source server is saved.
database data format
In order to implement a common database format, it is necessary to design a common database format, including the necessary tags. The following items are required:
source server
- The browserName of the object
- DisplayName of the object
- Object's NodeId
- show path
- time stamp
- value
Example:
The application software obtains the complete information of the historical data by means of these tags and the information model in the OPCUA server.
The database can use various databases such as influxDB, mongoDB, and MySQL. I prefer to use influxDB.
Advantages of OPCUA Large Model Architecture
In practical applications, it is very effective to construct a UPCUA large model system that aggregates OPCUA servers of field devices. its advantages
- Establish a unified access point for all data
- Build an IT/OT interface
- Simple and uniform access to historical data
The safety and reliability of the automation line are very important, a small operation error may cause huge property damage and death of personnel. Therefore, the production line can only be opened to IT without affecting the safe and reliable operation of the production line. Simply interconnecting production equipment with cloud services is an unsafe approach. A more appropriate method is to combine it with IT through a public and secure node.
experimental project
is being written.
Write an OPCUA Server and build an aggregation server model.
The client adopts a multi-threaded approach. Connect with field devices.
conclusion
OPCUA is important and complex. There is still a long way to go to realize Open Automation and Industry 4.0. How to adopt these technologies that are prepared for tomorrow to solve the current problems, and adopt a gradual approach to promote the realization of open automation is a feasible path.