It’s a Messy, Messy World – Part 2

messy world pt 2

In my last article, I described what we all know – the world is not a nicely organized, well-defined and structured place. We don’t even measure things in the same way. On our side of the big pond, we measure things using the Imperial system while on the other they measure those same things using the Metric system. Of course, that’s odd because the Imperial system used in the US was created by the British two hundred years ago, who abandoned it after giving it to us.

But I digress. Not only are there multiple measuring systems used around the world, but we saw in my last article how many different sensor types are capturing data. Those sensors provide data using different data types (sometimes inventing their own data types), use different engineering units and scale data differently. All of this is a nightmare for data scientists and control engineers that need to study data and look for ways to improve manufacturing operations. Machine learning and analytics tools also don’t function well when fed data that is slightly different.

What’s needed is a way to capture and normalize data from all these sources so that it can be coherently studied and results derived from it. Manufacturing data that is properly normalized should provide the following:

  • a set of standard types (Int15, Unsigned 32, IEEE Float…etc.)
  • an organized hierarchy for related data values
  • a capability to attach meta-data (related explanatory data) to data values (last updated, data quality, engineering units, scale…etc.)
  • a mechanism to allow groups to create new data types specific to a common application (certain engineering disciplines define data variables that represent specific and esoteric data values)
  • a mechanism for users to electronically discover this organization

There is only one technology that can meet this need: OPC UA. The premise of the OPC UA data typing system is that clients can’t process data when they don’t know how that data is formatted. When an OPC UA Client device can identify the type of data in a data variable, it can process it, manipulate it and properly store it. OPC UA data typing is characterized by these important features:

  1. OPC UA is a strongly-typed technology. Strongly-typed in this context means that variables have well-defined types, and one type cannot be used in place of another type.
  2. There is a predefined set of standard data types that all Clients and Servers must inherently understand.
  3. Data variables are typed as one of these standard data types or as a type derived from one or more of the standard types.
  4. The composition of types unknown to a Client is discoverable either locally in the Server or remotely using a URI (Uniform Resource Identifier).
  5. A Client device can identify and match types from different Server devices as being identical types with the same origins and derivations.
  6. The OPC UA typing system is extensible, and new types can be created by vendors, trade groups and other third parties to meet the requirements of a particular application domain.

OPC UA supports the standard data types found in many other technologies or computer languages. That standard type list consists of types you’ll recognize like 16-bit Unsigned Integer, Double, Float and all the other ones you would expect to find in a standard type list. Derived types, specific to certain applications, can be created from these base types. More importantly, definitions of these derived types are either available locally in the device using the type or there is some location information specifying where the definition can be located. OPC UA also provides a unique data organization that allows a client to traverse a device’s data structure and identify data variables.

Yes, it’s a messy world and it’s never going to get more organized and easier to manage. But with OPC UA, we have a tool to deal with the problem.

To read part one of the is blog series, click here.