What’s an Information Model and how it’s used to organize data.

The factory floor is a place where none of us expected to have to process massive amounts of data. But that is exactly where we now find ourselves. Not only do our factory floor systems collect more data than we ever expected, we have requirements to move that data to unexpected destinations. Machine status must be moved to the cell phones of control engineers. Diagnostic data to the maintenance organization’s servers. Production data to the enterprise business systems and applications. And archived quality data to the cloud.

Adopting IT practices
Capturing all that data, securing it, moving it, storing it, and analyzing it: that’s now a reality for those of us architecting manufacturing systems. And we can’t accomplish that effectively without better mechanisms for organizing all that data. The flat file systems that factory floor controllers and systems used in the past just aren’t adequate for this explosion in data. It’s time we adopted the technologies and practices of the people who have being doing it for all these years: our friends over in the IT department. Organizing all that data as an Information Model is the difference between swimming in all that data and drowning in it.

What is an Information Model?
An Information Model is nothing more than a logical representation of the constraints, rules and data relationships applied to a physical process or data set. An Information Model can represent something as tiny as a screw, a component of a process like a pump, or something as complex and large as an entire filling machine. The Information Model is simply a digital entity that defines the component, devoid of any information on how process variables or meta-data within that structure can be accessed.

And that last part is the important point. The Information Model has nothing to do with how that information is stored or made available. There are languages designed specifically for Information Modeling like the Unified Modeling Language (UML). In OPC UA, Information Models are XML files – highly structured files that can represent anything from a variable to a device to a machine, or even a plant. That XML file is implemented as an OPC UA Address Space and there are specific mechanisms to browse that address space, access the nodes that comprise it, and encode, secure, and transport the information it contains.

All of that is important, but in OPC UA those mechanisms are distinct and separate from the how the information is modeled. OPC UA is the first technology to separate this functionality. Other technologies exist that model information. Other technologies exist that represent data in an electronic system. None I’ve seen do both as well as OPC UA.

The first thing you do when creating an Information Model is to decide what is of interest and what isn’t. A filling machine has all kinds of devices; valves, pumps, motors, controllers, and sensors which we can call entities in the model. Each of these entities are modeled by more specialized entities. A motor might consist of motor and drive entities. And those entities can be modeled by other, more specialized entities. As you do this, a hierarchy of entities is developed that forms the Information Model for the system.

For each of those entities you define their specific characteristics and set up the relationships between them. And this will vary with the application. The Information Model for an asset tracking application might contain color, case style and part number. For a process application it might contain the current RPMs and operating hours. Or it might contain both.

You can get as complex or as basic as you’d like with an Information Model. It has infinite flexibility to describe your process in whatever way serves you best. When complete, you can document your process using a standard language and symbology that conveys to everyone exactly what each entity is and what relationship exists between those entities.

But what have we really done? Your Information Model is only that – your Information Model. You may have modeled a pump with the characteristics speed and RPM. Someone else might have used a pump model that includes the current flow rate. Since you’ve both modeled the pump differently there is no saving in labor or productivity for any of your customers. You may have given them a model using some open standard but they still have to incorporate your proprietary characterizations of the pump. That leaves us where we’ve always been: repeating the integration again if we have to use a different pump in the next application.

It’s actually worse than that. We haven’t even begun to talk about common Transports, Data Encoding, and access to the data contained in the Information Model. It’s one thing to define a nice Information Model for your device, your machine or production line but if there isn’t any standardized way for others to know that you are using that model, to know what’s in it, and to easily access it, it doesn’t save anybody any time or money.

And that’s the problem that many of us have faced over the years. Yes, there have been people that have created very elegant Information Models. But the big problem in the past was that a lot of the models were tightly integrated with a specific technology or communication protocol. In other cases, the Information Model was designed specifically to solve problems in one particular application domain. And when there was a mechanism to create a flexible Information Model, there wasn’t a standardized way to deploy the model in an actual system.

OPC UA actually solves both these problems. OPC UA is the first technology to provide system architects with a common infrastructure for modeling data and providing the transport, encoding, and security to employ it. Information Modeling in OPC UA provides enhanced organization, flexibility, and scalability.

OPC UA Information Modeling is different than other technologies in several important ways:

• There is a consistent structure and standardized definitions for many application domains

• There is a consistent and standardized structure to the documentation of the model

• There is a mechanism for translating the model into an address space

• There is a standard mechanism for Clients to identify the model and its component definitions at run time.

• The encoding, securing, and transporting of values in the address space are entirely disconnected from the Information Model

This is particularly important to trade associations, which understand that integration costs can be dramatically lowered if everyone uses a standard definition for entities specific to an industry. This kind of extensible Object Typing, Data Typing, and Object Modeling are some of the reasons why the undersea oil and gas trade association, the building automation trade association, along with major vendors like Emerson, Honeywell, Invensys, and others, are standardizing on OPC UA.