How you use it, configure it and set up authorizations varies slightly from one version of Microsoft Windows to the next. The other problem is the deficiencies that come with dependency on Microsoft and Windows.
It runs only on Microsoft platforms. Not Linux, not VxWorks, not anything else. Microsoft has a well-deserved negative reputation, especially in Industrial Automation. In this industry, we generally build automation processes to last.
There are the hardware setup and labor and the ongoing labor to maintain it. The data must be carefully managed all the way from the RFID reader to the Server to make sure that the different systems use the correct data types, that resolution is maintained, the endian order which byte is first is proper for that system.
Lastly, OPC Classic was vulnerable. Even though OPC Classic was wildly successful and worked well when managed right, there was enough dissatisfaction with the security issues, platform issues and data inconsistencies that a successor was planned for it. Subscribe to our Automation Education email series to learn the ins and outs of the top industrial protocols in a byte-size weekly format!
Most other technologies are designed for a specific application. OPC UA is more flexible in that it provides connectivity advantages for all levels of the automation architecture. OPC UA is designed to be well-suited for connecting the factory floor to the enterprise. Servers can support the transports used in many traditional IT type applications. That way, if additional transports are defined in the future, the same OPC UA Information Model, object model, and messaging services can be applied to that new transport.
OPC UA truly is future proof. Many of the common Industrial Automation IA protocol technologies limit the available transports. Devices that want to communicate with Programmable Controllers must use the transport that is defined for the communication technology supported by that brand of Programmable controller PLC. The technology space where OPC UA operates is much more extensive and requires support for many different transports and the capability to add new transports in the future.
Transports are about how an OPC UA message is moved from your node to some other node on the network. Transports are the low-level mechanisms for moving those serialized messages from one place to another. OPC UA operates in very broad technology space and the devices can support multiple transports or even custom or proprietary transports. A rich set of support transports are required to support the OPC UA mission of being a completely scalable solution. It all starts with an object.
An object that could be as simple as a single piece of data or as sophisticated as a process, a system or an entire plant. It might be a combination of data values, meta-data, and relationships. Take a dual loop controller. The dual loop controller object would relate variables for the setpoints and actual values for each loop. Those variables would reference other variables that contain meta-data like the temperature units, high and low setpoints, and text descriptions. The object might also make available subscriptions to get notifications on changes to the data values or the meta-data for that data value.
A client accessing that one object can get as little data as it wants single data value or an extremely rich set of information that describes that controller and its operation in detail. OPC UA is, like its factory floor cousins, composed of a client and a server. The client device requests information. The server device provides it. An OPC UA server models data, information, processes, and systems as objects and presents those objects to clients in ways that are useful to vastly different types of client applications.
OPC UA server is a data engine that gathers information and presents it in ways that are useful to various types of OPC UA client devices, devices that could be located on the factory floor like an HMI, a proprietary control program like a recipe manager, or a database, dashboard or sophisticated analytics program that might be located on an enterprise server.
Data is not necessarily limited to a single physical node. Objects can reference other objects, data variables, data types and more that exist in nodes off someplace else in the subnet or someplace else in the architecture or even someplace else on the Internet.
Similarly, Subscribers express interest in specific types of data, and process messages that contain this data, without a need to know where it originated from.
This multi-layered approach accomplishes the original design specification goals of: Functional equivalence: all COM OPC Classic specifications are mapped to UA Platform independence: from an embedded micro-controller to cloud-based infrastructure Secure: encryption, authentication, and auditing Extensible: ability to add new features without affecting existing applications Comprehensive information modeling: for defining complex information Functional Equivalence Building on the success of OPC Classic, OPC UA was designed to enhance and surpass the capabilities of the OPC Classic specifications.
Platform Independence Given the wide array of available hardware platforms and operating systems, platform independence is essential. Security One of the most important considerations in choosing a technology is security. OPC UA is firewall-friendly while addressing security concerns by providing a suite of controls: Transport: numerous protocols are defined providing options such as the ultra-fast OPC-binary transport or the more universally compatible JSON over Websockets, for example Session Encryption: messages are transmitted securely at various encryption levels Message Signing: with message signing the recipient can verify the origin and integrity of received messages Sequenced Packets: exposure to message replay attacks is eliminated with sequencing Authentication: each UA client and server is identified through X certificates providing control over which applications and systems are permitted to connect with each other User Control: applications can require users to authenticate login credentials, certificate, web token etc.
OPC UA also defines the necessary access mechanisms to information models. Look-up mechanism browsing to locate instances and their semantic Read and write operations for current data and historical data Method execution Notification for data and events For Client-Server communication the full range of information model access is available via services and in doing so follows the design paradigm of service-oriented architecture SOA , with which a service provider receives requests, processes them and sends the results back with the response.
OPC Unified Architecture extends the highly successful OPC communication protocol, enabling data acquisition and information modeling and communication between the plant floor and the enterprise reliably and securely.
Using MatrikonOPC UA technology securely broadens your connectivity horizons, open new market shares, and enables you to achieve ultimate scalability in the automation world today. Whether your product is engineered for minimum unit cost or maximum performance we have the right solution for you.
0コメント