OPC and OPC UA

What is the OPC protocol?

In order to facilitate the exchange of data between equipment and applications from different manufacturers in the automation industry, a unified interface function is defined, which is the OPC protocol specification (OLE for Process Control) . With OPC, you can use a unified method to access product data from different equipment manufacturers.

The OPC Foundation has successively stipulated different interface definitions, as follows:

OPC DA (Data Access, exchange of real-time values) 

OPC A&E (Alarms & Events, exchange of alarms and events) 

OPC HDA (Historical Data Access, exchange of historical values) 

OPC XML DA (XML-based exchange of real-time values)

All the above interface definitions are now collectively referred to as OPC. OPC is specified based on WINDOWS COM/DOM interface technology.

For example, we can understand the interface definition of OPCGroup as follows:

//*********************************************************
// IOPCGroup Interface
[
object,
dual,oleautomation,
uuid(28E68F96-8D75-11d1-8DC3-3C302A000000),
helpstring("OPC Group Object"),
pointer_default(unique)
]
interface IOPCGroup : IDispatch
{
// Properties
[propget,helpstring("Returns the parent OPCServer")]
HRESULT Parent([out, retval] IOPCAutoServer ** ppParent );
[propget]
HRESULT Name([out, retval] BSTR * Name );
[propput]
HRESULT Name([in] BSTR Name );
[propget,helpstring("True if this group is public")]
HRESULT IsPublic([out, retval] VARIANT_BOOL * IsPublic );
[propget,helpstring("True if this group is active")]
HRESULT IsActive([out, retval] VARIANT_BOOL * IsActive );
[propput]
HRESULT IsActive([in] VARIANT_BOOL IsActive );
[propget,helpstring("True if this group will get
asynchronous data updates")]
HRESULT IsSubscribed([out, retval] VARIANT_BOOL * IsSubscribed );
[propput]
HRESULT IsSubscribed([in] VARIANT_BOOL IsSubscribed );
[propget]
HRESULT ClientHandle([out, retval] LONG * ClientHandle );
[propput]
HRESULT ClientHandle([in] LONG ClientHandle );
[propget]
HRESULT ServerHandle([out, retval] LONG * ServerHandle );
[propget]
HRESULT LocaleID([out, retval] LONG * LocaleID );
[propput]
HRESULT LocaleID([in] LONG LocaleID );
[propget]
HRESULT TimeBias([out, retval] LONG * TimeBias );
[propput]
HRESULT TimeBias([in] LONG TimeBias );
[propget]
HRESULT DeadBand([out, retval] FLOAT * DeadBand );
[propput]
HRESULT DeadBand([in] FLOAT DeadBand );
[propget,helpstring("Rate data can be returned to an
application (in mSec)")]
HRESULT UpdateRate([out, retval] LONG * UpdateRate );
[propput]
HRESULT UpdateRate([in] LONG UpdateRate );
[id(0),propget,helpstring("Returns the OPCItems
collection")]
HRESULT OPCItems([out, retval] OPCItems ** ppItems );
// Methods
HRESULT SyncRead(
[in] SHORT Source,
[in] LONG NumItems,
[in] SAFEARRAY(LONG) * ServerHandles,
[out] SAFEARRAY(VARIANT) * Values,
[out] SAFEARRAY(LONG) * Errors,
[out,optional] VARIANT * Qualities,
[out,optional] VARIANT * TimeStamps);
HRESULT SyncWrite(
[in] LONG NumItems,
[in] SAFEARRAY(LONG) * ServerHandles,
[in] SAFEARRAY(VARIANT) * Values,
[out] SAFEARRAY(LONG) * Errors);
HRESULT AsyncRead(
[in] LONG NumItems,
[in] SAFEARRAY(LONG) * ServerHandles,
[out] SAFEARRAY(LONG) * Errors,
[in] LONG TransactionID,
[out] LONG * CancelID);
HRESULT AsyncWrite(
[in] LONG NumItems,
[in] SAFEARRAY(LONG) * ServerHandles,
[in] SAFEARRAY(VARIANT) * Values,
[out] SAFEARRAY(LONG) * Errors,
[in] LONG TransactionID,
[out] LONG * CancelID);
HRESULT AsyncRefresh(
[in] SHORT Source,
[in] LONG TransactionID,
[out] LONG * CancelID);
HRESULT AsyncCancel(
[in] LONG CancelID);
};

What is OPC UA?

In order to cope with the trend of standardization and cross-platform, and to better promote OPC, the OPC Foundation has launched a new OPC standard-OPC UA in recent years based on the successful application of previous OPC . The OPC UA interface protocol includes the previous A&E, DA, OPC XML DA or HDA. It can access all previous objects using only one address space and is not restricted by the WINDOWS platform because it is defined from the transport layer Scoket . This will be mentioned later, resulting in improved flexibility and security compared to previous OPC.

Advantages of OPC UA:

1. A common interface integrates all previous OPC features and information, A&E, DA, OPC XML DA or HDA

2. More open, platform-independent, compatible with both WINDOWS and LINUX

3. Expanded object types to support more complex data types such as variables, methods and events

4. Integrated security functions at the protocol and application layers, making it safer

5. Easy to configure and use

The core difference is that the TCP layers used by the OPC and OPC UA protocols are different, as follows:

OPC is based on DOM/COM, the top layer of the application layer; OPC UA is based on the TCP IP scoket transport layer.

Some other differences:

Although OPC provides data encryption and signature functions by configuring COM/DOM, configuring firewalls, and user permissions to make data access more secure, it will increase additional workload, especially for non-IT engineers; for OPC UA , data encryption and signature, firewall, etc. are all default functions. For example, the dynamic port allocation used by DOM-based OPC is not fixed, making it difficult for the firewall to determine. However, the ports of OPC UA are unique. For example, SINUMERIK 840D is PORT 4840, and SIMATIC S7 is PORT 4845. DOM/COM can also generate event logs of different levels, but the log content is not detailed enough and only provides "who connected to the server". For OPC UA, it is the default function, and the generated log content is more comprehensive.

A DEMO of OPC UA will be posted later.

Reference: https://blog.csdn.net/wfx7414/article/details/50629480 


【Foreword】

OPC is an industrial standard, and its international organization is the OPC Foundation. It currently has more than 220 members, including all major automation control system, instrumentation and process control system companies in the world.

[Classic OPC]
The classic OPC specification is based on the COM/DCOM technology provided by Microsoft Windows system and is used for data exchange between software. The OPC specification defines several different version specifications for accessing process data, alarm information and historical data: The
OPC Real-Time Data Access Specification (OPC DA) defines relevant standards including data values, update times and data quality information.
The OPC Historical Data Access specification (OPC HDA) defines methods for querying and analyzing historical data and data with time stamps.
The OPC Alarm Event Access Specification (OPC AE) defines alarm and time type message information, as well as related standards such as status change management.

[Why OPC UA should be developed]
COM/DCOM-based technology has shortcomings that cannot be eradicated. Therefore, with the advancement of technology and the increasing demand for data exchange in all aspects, the OPC Foundation released a new specification in 2008: OPC UA.

[Technical characteristics of OPC UA]

The OPC UA specification is no longer based on COM/DCOM technology, so OPC UA can be implemented not only on the Windows platform, but also on Linux and other embedded platforms. Like the traditional OPC specification, OPC UA also has the same design goals: 1. Functional equivalence: All functions in the COM-based OPC specification are mapped to OPC UA. 2. Multi-platform support: Supports everything from embedded microcontrollers to cloud-based distributed control architectures. 3. Security: information encryption, mutual access authentication and security monitoring functions. 4. Scalability: New functions can be added without affecting existing applications. 5. Rich information modeling: Complex information can be defined instead of single data.

[Changes of OPC UA compared to traditional OPC]

1. In terms of functions, OPC UA not only supports all functions of traditional OPC, but also supports more new functions: 1. Network discovery: Automatically query the OPC Server available in this PC and the current network . 2. Address space optimization: All data can be defined in hierarchical structures, allowing the OPC Client to not only read and utilize simple data, but also access complex structures. 3. Mutual access authentication: All reading and writing data/message activities must have access permission. 4. Data subscription: Provides data/message monitoring and change reports when values ​​change for different configurations and standards of OPCClient. 5. Methods function: OPC UA defines methods to allow the OPC client to execute specific programs by defining methods in OPCServer.

2. In terms of platform support, since it is no longer based on COM/DCOM technology, the OPC UA standard provides more supported hardware or software platforms. Hardware platforms such as traditional PCs, cloud-based servers, PLCs, ARM and other microprocessors; software platforms can support Microsoft Windows, Apple's OSX, Android, and other Linux-based distributed operating systems.

3. In terms of security, the biggest change is that OPC UA can communicate through any single port (after being opened by the administrator), which makes OPC communication no longer subject to a lot of restrictions due to firewalls.

[Technical details of OPC UA]

1. OPC UA can be transmitted in XML format or binary format, and can be selected and compatible with more common IT communication protocols, such as HTTPS. At the same time, when encrypting, it can also reach an encryption depth of 128 or 256 bits. In terms of client-server communication permissions, OPC UA uses an OpenSSL license to specify which applications or systems can use OPC to connect to the other end. 2. In terms of modeling, OPC UA expands the modeling architecture from "data modeling" to "information modeling". The OPC UA specification not only provides complete object-oriented data modeling, but also can define complex multi-level structures. Data types or structures are defined in profiles. Not only can existing types in the traditional OPC specification be defined, but they can also be extended to add new types defined by other vendors or organizations.

How far away is smart manufacturing? --Talk about why we should adopt OPC UA?

Some time ago, I discussed the PLCopen education cooperation project with Mr. Yan Yi, Chairman of PLCopen. According to Mr. Yan’s preliminary research, it was found that there are very few teaching materials related to motion control . Even many university teachers do not understand PLCopen Motion. This is unacceptable because , as far as we talk about "intelligence", the accuracy and speed of motion control are related to the quality and production efficiency of the product, and control engineering network. All rights reserved. Through flexible parameter settings, motion control can make production more flexible. We don't care how the upper-level architecture performs intelligent analysis and optimization, but at the manufacturing execution level, if there is a lack of precise and flexible execution of the motion control system, then the so-called "intelligence" cannot be achieved - execution is an important component of intelligence, which is quite The corporate strategy is great, but it cannot be implemented.

In the same way, we always discuss high-end cloud platforms, big data analysis, artificial intelligence, and the Internet of Things. However, data interconnection is the first obstacle. In the same way, OPC UA, as the basic standard and specification of data interconnection , is It seems that many people do not understand, and even many people who do so-called factory integration are not very clear. During data collection , transmission and production operations, we will need to conduct on-site machine status, production energy consumption, quality-related, and production-related parameters. Collection, however, if there is a lack of unified standards and information models, we will encounter very big difficulties.

The bright future of intelligent manufacturing requires underlying technical support, standards and specifications first. Otherwise, we will be far away from intelligent manufacturing—far beyond our imagination.

1. Dilemma of data collection

Although everyone believes that big data analysis will bring us huge manufacturing optimization potential and improve our production and operation efficiency and asset management levels, there are many difficulties when it comes to interconnecting smart factories in reality, whether it is IIoT or big data. Analyzing various concepts gives us a vision of an infinitely bright future, but the reality is so skinny.

(1). A large amount of connection work consumes energy

All companies and system integrators working on smart factories, including MES manufacturers, know how much work it takes just to collect on-site data. For a small project, various communication buses must be connected and various communication buses must be configured. Many of the parameters of the machine are not open to the public due to technical confidentiality. Therefore, a lot of data of low value is collected. Many companies from the IT industry that have come to explore the industrial Internet of Things are very depressed, because the money they make is really huge. It was so hard that they became pessimistic about the matter. It's okay for those doing automation, because they originally encountered these problems, but it's very bad for IT because it consumes too much engineering resources.

(2). It is not very clear what data to collect.

This is a difficulty. Regarding how to operate a production system, many IT professionals often lack understanding of machines, production processes and processes, and cannot clearly define what kind of data needs to be collected? How is this data used?

Many times, people just say "collect the data first and then talk about it." As for what this data can do, that is a matter for later. Let the data not be lost or wasted first. However, if you don't know the purpose of the data, then how do you know what you collected? Is the data correct? If you collect a lot of data and find that one piece of data is missing and cannot be used to analyze the impact of the process on energy consumption, wouldn't all the data you collected become useless?

(3). It is not clear what the data is to be used for.

This is another embarrassment, what is the use of this data? How to use this data is no longer a technical issue, but involves the company's operational management level. If we can achieve high precision data management and have an advanced management model, then this matter will become more important. It is easy to understand, because first it knows what data needs to be collected, and if the operation management level is average, the data collected by the third-party system integrator will be entrusted and the data collected does not know how to use it, which involves the strategic issues of the company's digital operation.

2. Why use OPC UA?

Including mainstream automation manufacturers, as well as Huawei, Microsoft, CISCO in the IT world, etc., have become supporters of OPC UA, as well as associations and organizations such as OMAC, Euromap, Automation ML, ISA, FDT/DTM, MTConnect, BacNet, and major global Fieldbus foundations such as PI, EPSG, ETG, and SERCOSIII all support integration and development with OPC UA. Why do these international automation, IT, foundation organizations, and industry associations focus on OPC UA?

Figure 4 is a self-designed diagram combined with the standard document of OPC UA to illustrate the eight reasons for adopting OPC UA.

Industrial communication is divided into several levels: interconnection (connection of hardware interfaces), interoperability (data formats and specifications at the software level), and semantic interoperability (definition and specification of semantics). Various buses solve connection problems, and interoperability solves The application layer is matched, while OPC UA solves the semantic interoperability between different systems - including application behavior and dynamic functions.

Independence, security, international standards, modeling and information models, and plug-and-play are all reasons why OPC UA has become the focus of everyone's attention from a technical perspective.

3. Establishment of information model

How to understand the information model?

What is an information model? It may not be easy to understand if we use OPC UA technology to introduce it. However, if we want to realize collaborative work between robots and injection molding machines, we must know what data they need to ensure the consistency of their work. Woolen cloth? This is the application problem of data. In the same way, we hope to realize the statistics of OEE. Then the calculation of OEE is an information model. We need data related to it. The information model of vertical industries lies in specific packaging, plastics, and printing. The objects collected vary by industry.

Figure 5-Making data standardized and standardized

A simple understanding of the information model is the standard encapsulation of data in order to achieve specific tasks. OPC UA provides a standard for how to encapsulate the information model, in addition to PackML, MTConnect, Euromap, Automation ML, etc. that have been included in the OPC UA architecture. In addition, OPC UA also supports industry-customized information models. OPC UA adopts object-oriented thinking to make these developments simple.

Figure 6-OPC UA architecture

Figure 6 is the architecture of OPC UA. It includes basic information model, industry information model, and manufacturer-customized information model. Providing transmission services and discovery functions are basic, and the information model is a cross-platform and cross-industry application. need.

4. What are the application benefits of OPC UA?

4.1 What are the benefits of OPC UA for system integration?

We must ensure that we have a unified model for parameters such as quality, efficiency, energy, maintenance, etc., which allows us to do the following:

(1). Software reuse: Application modules formed through data modeling, such as PackML, allow us to uniformly encapsulate the data related to the packaging machine and MES, and the relevant data can be called by calling a module. This is just like the PackML and Euromap software modules in B&R's mapp.

(2). Separation of concerns and software modularization: Through the shared information model, OPC UA enables service-oriented (SoA) applications. Due to the adoption of the design idea of ​​separation of concerns, HMI and applications can be separated CONTROL ENGINEERING China All rights reserved, and the separation of data and applications allows different applications to read the shared information model to analyze and display the applications in their own way.

Like early Android, many field applications have similar problems. All rights reserved. Control Engineering Network. You must develop corresponding graphics for each different screen because it is impossible to adapt to these sizes, especially those with non-standard specifications. On the other hand, a large number of programmers also face troubles caused by the complex coupling relationship between HMI and applications.

There is also such a problem in program development. When one party is modified between the HMI and the application program, the other party must also be modified. On the other hand, different screen designs are required for different screen sizes. For OEM manufacturers, this means that in order to customize the machine, screens and programs must be repeatedly modified, and HMIs of different sizes must be redesigned.

Figure 7-mappVIEW uses OPC UA to achieve separation of concerns

The mappVIEW technology shown in Figure 7 realizes the separation of concerns between HMI and programs through OPC UA, so that the configuration interface and process of modifying the HMI screen have nothing to do with the application, and the modification of the application program will not affect the HMI screen. Moreover, HMI and smart terminals of any size can adaptively access machine data.

Of course, separation of concerns is also the main way to implement modular software, which can be included in the same description of advantages as software modularity.

(3). Save a lot of engineering time: due to the adoption of a standard data model, the data only needs to be configured without a large number of programming operations www.cechina.cn. In addition, the standard data package allows task-related data to be stored in one go be read without having to call different parameters many times, which also saves engineering time.

(4). Maximize data application: Design, production, maintenance, etc. can exchange data under the same architecture, realizing enterprise data sharing and maximizing data value. Just like Automation ML, data from the engineering design platform to the process assistance platform, MES, and control layer can be connected and shared under a unified standard.

OPC UA as a whole enables transparent interaction of horizontal and vertical data in all aspects of the factory. Moreover, configuration efficiency is higher, and programs and applications are more modular, making factory organization more convenient. Even in the face of complex changes, Quick switching can also be achieved.

4.2 Industry information model brings rapid data configuration and collection

(1). It doesn’t matter who owns the PLC: If I don’t have to care about whose controller developed the injection molding machine and robot system, but can directly access the machine through the standard configuration of the data, is that very convenient?

Obviously, this is the best idea of ​​people doing factory integration projects today, but in reality it is not the case. It can also be connected. They need to configure different software programs for different controllers, and also need different interface modules to support them. , but if no matter what brand of controller you use and what fieldbus you use, as long as you use OPC UA, we can access and configure the parameters of the machine with each other, then will this make the work of the factory integrators much simpler? ?

Euromap 77 is an injection molding machine communication model designed based on OPC UA standards. It includes injection molding machine information, configuration, status, mold, and driver data objects, as well as data models for job and data set management, as shown in Figure 8.

Figure 8-Euromap 77 injection molding machine information model development based on OPC UA

For PackML, it aims to provide corresponding capabilities to connect MES and quality data. In fact, for PackML, the machine status in Figure 9 makes machine time statistics simple, and PackML follows the OPC UA standard. and specifications.

Figure 9-PackML device status

Through the status and display screen shown in Figure 9, the time will be recorded for each button press. Finally, the time related to the equipment OEE statistics will be used to achieve statistical analysis of production and operation efficiency.

(3). Realize data fusion of OICT fusion

The integration of OICT will inevitably lead to the semantic integration of cross-platform IT and OT systems. Everyone must understand the meaning of each word spoken by another person, and adopt unified standard data formats and unit standards (kilograms, watts, meters). , seconds, hours), unification of energy collection standards and data sets.

Edge computing is connecting field devices to implement data applications, and OPC UA is a standard and specification used to realize the interconnection of IT and OT. As shown in Figure 10, the parameters of the injection molding machine are managed through the Euromap standard, read by the analysis system and passed OPCUA releases production tasks to machines.

Figure 10 - Integration of new injection molding machine factory and old factory based on OPC UA

In fact, various industries are promoting smart manufacturing with great fanfare. However, in terms of basics, standardization work such as OPC UA and PLCopen must be carried out first. Of course, this also includes functional safety technical standards based on IEC 61508 and ISO 10218 for robots. wait.

This is what I want to say: "How far is smart manufacturing from us?" - We should do the basic work well. Not only in the industry www.cechina.cn, including in university courses, issues regarding interconnection and interoperability are still stuck in the long-standing fieldbus, regardless of the fact that the industry has adopted a large number of real-time Ethernet technology, and the new TSN will also be integrated with OPC in the near future. UA integration has become a foreseeable future interconnection integration solution.

Reprinted from: https://blog.csdn.net/xiaoliu0515_0515/article/details/89442498

Guess you like

Origin blog.csdn.net/fuhanghang/article/details/132841767