Historical Context
The OPC Foundation is an organization that promotes a lot of different standards with the goal of improving interoperability of industrial software. The Foundation has over 1,000 members, ranging from small system integrators to some of the world's largest automation and industrial suppliers. The Foundation has also spawned other foundations or organizations that operate around OPC related work.
OPC UA is a massive specification. It defines a protocol and unifies together into a single specification the previous work of the OPC Foundation, which broadly falls under the of OPC Classic. Under this umbrella, there were three separate standards:
- one for live data or DA as it was called,
- one for historical data or HDA,
- and one for alarms and events.
OPC Classic did not have the concept of information models; it was essentially a or variable based protocol, and it was tightly coupled to windows.
(Currently, there are hundreds of thousands of OPC Classic , servers and clients, and those systems will continue to exist for years to come: although it's superseded by OPC UA, Classic will be around for a very long time.)
OPC UA addresses 3 fundamental things about OPC Classic
- First of all, decoupling from Windows. In order to operate in a more internet friendly way OPC UA has moved away from this very proprietary operating system to an implementation that can operate under different transport layers, which was an important goal.
- Next, there is so much overlap between the three aspects (live, historical, and alarms and events) that they wanted to unify these together into a single standard that allows doing all three.
- Lastly, OPC UA wanted to add the new capability of creating information models.
Information models can be thought of as a way to define and share types. OPC UA as a protocol specifies that types are stored in a file format called OPC UA node sets. These node sets can be thought of as templates. They are very powerful templates, and they look a lot like objects, but they don't support code, they don't support behavior out-of-the-box, and they don't support traits. They're not real objects in the programming sense of the word, but they are definitions of the shape of something.
OPC UA as a standard has thousands of pages but information models are described in OPC UA part 5 - chapter 5 - and this chapter is dedicated to describing how you create type definitions(templates).
One of the biggest challenges of OPC information models, and one of its big goals, is to allow groups of people to create reusable node sets, or libraries, for specific verticals. The intent is that they would be able to derive from each other: you would create a library, look at another library and pull in things from that library and specialize them, or enrich them. Currently, interaction with these libraries is limited to downloading existing node sets: there is no practical, functional way for end users to interact with or contribute to these libraries. There are no mechanisms to publish and to share node sets, apps or libraries, hence the cloud library.
Recall that OPC UA is a specification; there are dozens of tools that exist in the community that allow one to look at node sets, etcetera, but interaction is limited.
Cloud Libraries
There are two public organizations that run a cloud library: the OPC Foundation - and they follow rigorous rules about how something gets promoted and they have a life cycle of years - and CESMII. CESMII has a much less rigorous set of rules.
One of the capabilities of a cloud library is that you can have a parent cloud library and therefore can make all of the content of this cloud library available through it, and that is how CESMII’s cloud library operates. Everything that exists in the OPC Foundations’ cloud library also exists in the CESMII cloud library.
A cloud library contains types - or profiles. The term profile in CESMII’s world can refer to a set of types - a library -, or it can refer to an individual type, or it can refer to an individual type and a binding for data acquisition. Profiles are a bigger concept than just types. Today, the OPC Foundation is only types; CESMII has a future view of profiles being a bigger idea than just types.
CEMII is creating an environment where people can build their own content and share it. This is how real modelling happens. This is similar to what happens in ThinkIQ. In ThinkIQ, you can start building your types and you do not have to have a massive learning experience about ‘what are types’, necessarily. You can look at your factory and say “there are 5 things I care about” or you can just start with a library that presents you types in plain language like the ThinkIQ Smart Equipment library does. ThinkIQ allows rich types that can have behavior, and very importantly, CESMII’s cloud library is intended to encourage this practice. In order to achieve this not only did they stand up a cloud library, but they also created an editor for working on a cloud library.
ThinkIQ Libraries
ThinkIQ libraries have collections of types which can include implementation; we are moving towards the same goal as CESMII in terms of a profile being something that is more comprehensive than a type.
The Smart Equipment Library, for example, contains a valve type. When we look at a valve, we say ‘are you open or closed’; what's the difference? Perspective around what information is useful.
There is a ‘basic machinery’ OPC UA node set, and it has pump in it. It tells you everything about a pump from a pump motor manufacturer's perspective. There is a motor and a pump, and it has the motor bearing temperatures and the pump bearing temperatures and it has the RPM of the two things. It has a lot of information about what you need to know as a pump motor builder. What It doesn't have is pump pressure - inlet pressure or outlet pressure - or flow. In actual manufacturing end users need to know the pressures and flow of a pump. They need the data about how the pump is operating.
When building a ThinkIQ library, not only can you include ‘nameplate’ data like expected bearing temperatures, RPM, or capacity, you can also create attributes to store actual data about how the item is operating now. Attributes can be stored as time series data, so you can see how your pump or valve or mixer behaves over time. Additionally, types in a ThinkIQ library can have behavior. Scripts can be added that extend the usefulness and smartness of any type.
Building a type library in ThinkIQ doesn’t require specialized knowledge of OPC UA node sets or profiles: rather, types in the library are based on the basic ideas and concepts of object orientation: classes, methods, attributes, inheritance, interfaces, and more.
Further, building a ThinkIQ library is an iterative process. As you develop a library, you can create instances of the types, wire them to tags, and see immediately if they are providing all the information you need to run your process successfully. Types can be easily edited and specialized: you can create sub-types of existing types that add additional attributes or behavior, for example.
Relationships
Relationships are fundamentally different in OPC terminology to what they are in ThinkIQ. In ThinkIQ, we have determined that relationships are not part of an object type definition. They exist at a higher level. One can say this tank feeds this mixing machine and not have to think about that from a type perspective. Relationships exist outside of the object model, in the ThinkIQ Relationship model/graph.