Let’s Get Normalized!

We live in a much more complicated world. A world full of uncertainty. Just look around. There’s Brexit, the Hong Kong situation, trade issues, a Peak Car (some think we’ve reached the maximum number of miles per person in the world), a US election in 12 months and a possible impeachment of a president. Lots of reasons for people with money to sit on it and not invest. Despite all those challenges, the economy is still humming but manufacturing is weak.

In our manufacturing world, we have a lot of serious challenges. German manufacturing is in a recession, and the productivity growth in manufacturing is way behind a lot of other industries. Many of us are trying to change that with IoT, but that’s often a cumbersome and slow process fraught with problems.

One of the biggest I see is the lack of anyone really interested in normalization, standardization, and contextualization. Normalization is the process of converting all your data to the same scaling, data type and format so that it’s useful. It’s just not helpful to have glue tanks reporting the same value in centigrade, Fahrenheit and a percentage of full scale. Standardization is the process of deciding on what that reporting should look like – should it be centigrade or Fahrenheit across the entire business – and then developing the systems and processes that enforce that standardization. Contextualization is adding the context for the data. In OPC UA we call that adding metadata. The context for temperature would be adding naming information, location, last update time, maximum value and so forth.

We didn’t think much about these problems when we just moved EtherNet/IP and Profinet IO data from a device into a PLC. The PLC programmer just managed it. Modbus registers were all just unsigned integers; they would get pulled into a PLC, and the data was standardized by the PLC application logic. The PLC ladder programmer was the authority that decided on the standards and enforced them in logic. The PLC programmer needed the data to be standardized so he took care of it.

Now, with IoT systems, in a lot of companies, I don’t see anyone who is responsible for creating and enforcing these kinds of standards. The Control Engineer may put in a system to collect the data, but his only task is to make sure the data moves from the ControlLogix PLC, drive, meter, temperature sensor and so on to the database, wherever that may be. Someone else uses the data. That person cares a lot about data normalization, standardization, and contextualization but has no opportunity, or no ability, to affect how the data is collected. He or she may be thousands of miles away from the collection point and have no input to the process.

On top of the fact that few recognize this as a problem or that even fewer people care about normalization, most of the off-the-shelf IoT products today wave their hands over this messy part of IoT. You can read their websites and it says “ANY” device, “ANY” factory, “ANYWHERE” and they’ll just magically grab your data and send it to the Cloud. It’s magical. Very much like the salesmen of the 19th century that would ride into town with their magical elixir that would cure any problem you had or thought you had.

At RTA we are very concerned about this problem and are treating it seriously. Our Raptor Connectivity Platform provides several different ways for people to solve the normalization, standardization and contextualization problem. You can easily normalize a single point, normalize a set of points or normalize all your points. The normalization, standardization, and contextualization are designed in from the ground up. We’ll soon be launching this platform for OEMs who need to add connectivity to their machines, but in the meantime, you can just contact an RTA Application Engineer on 800-249-1612 to learn more.