Monitoring industrial processes isn’t exactly new. In fact, it’s not new at all. We’ve always been moving data to Enterprise systems. Thirty years ago, operators would record the values of mechanical counters to report what passed for KPIs (Key Performance Indicators) in that era: simple things like production counts, scrap counts and downtime. These daily shift tally sheets would go to the “IBM room” – called that because that’s where the IBM mainframe was – where a keypunch operator would put those values onto punched cards; those cards would be loaded up and transferred to a magnet tape. The tape would be mounted to print daily, weekly, monthly and yearly reports that someone hand carried around the plant. Days or weeks later, other copies would be mailed to the head office for analysis.
If this kind of remote monitoring sounds archaic to you, if it sounds like something from Fred Flintstone’s Slate Rock and Gravel Company, no one would argue with you. But it’s exactly how remote monitoring was done for nearly forty years.
Over the years, manufacturers endeavored to build computer systems to more easily monitor production systems. Recently, with the advent of new Internet communication technologies and Cloud data storage, those systems have improved to the point that monitoring industrial data is easier than ever.
First, apply thought and foresight
In fact, it’s now so uncomplicated that it’s being done with little thought and even less foresight. In fact, there are any number of companies committing one or more of the 6 ½ sins of remote monitoring:
Sin #1: Not starting with your KPIs.
Because it is so easy to move data to the Cloud, many companies just jump right to implementation. I have a hammer so I might as well just start pounding. The first step of a remote monitoring project should always be identify WHY you want to do remote monitoring in the first place. Do you need to understand your scrap numbers? Monitor your energy usage? Track downtime more closely? Start with your KPIs, identify what you need and what you are going to do with the data.
Sin #2: Confusing transport technologies with communication solutions.
Technologies like HTTP, HTTPS, MQTT, AMQP and other technologies that move data are simply transports. All they do is move data from point A to point B. They do not provide an architecture for secure, reliable communication. These transports lack the contextual information which identifies that data, indicates how it’s formatted and other metadata. Pretending that these technologies provide end-to-end solutions is a house of cards that is going to cost you time and money in the future.
Sin #3: Thinking that just adding TSL (the standard encryption mechanism) to a transport provides you with security.
Yes, TSL adds a measure of security to a packet being transported over the Internet. But are you getting end-to-end security? Many of the standard transports use brokers and, even though your data is encrypted in and out of the broker, it might be unencrypted on the broker. Many people underestimate just how vulnerable data can be in a broker.
Sin #4: Believing you own the data.
Many companies are adding Internet of Things (IoT) type communications to their industrial devices. They envision selling those devices to the GMs, P&Gs and other big manufacturers to provide a platform where they can harvest that data and monetize it. The question to ask is “Do you own that data?” If I’m a large manufacturer and I buy a measuring system, paint sprayer or quality analysis tool from you, my position is that I own the data it generates. Why would any manufacturer let you monetize their data?
Sin #5: Not knowing the “how” of monetizing data.
Even if you own the data, you need to ask, “OK, what can we do with it?” And it turns out, this is often a very difficult question. It’s the question everyone avoids while they’re busy getting the bytes moving from A to B. What’s our business model for monetizing this data? Who are we going to sell it to? What problem are we solving for them? And how much are they willing to pay for solving that problem? These questions should all be resolved long before that first byte is transmitted.
Sin #6: Storing your Cloud data in a server within your physical plant.
This is a mind bender. Can you really provide better physical security, hardware infrastructure, electrical backup and all the rest than the people who are in the business of maintaining server infrastructures? Yes, it feels better knowing that your data is back there in that locked room, but do you have the same argument for not using offsite data applications like Dropbox, Gmail and MS Office?
Sin #6.5: Believing you need to build your own analytics package.
If you’re one of these people that believe you can build a vastly superior analytics package that will be the envy of the world, then go ahead. Most likely you’re not going to be smarter, more dedicated and better-resourced than the analytics teams at Google, Microsoft and Amazon, so just use an off-the-shelf package.
The greatest problem with remote monitoring today is that it is now so much easier to accomplish it, which means many of us are jumping into it too fast and without a lot of thought. Don’t let that happen to you on your next remote monitoring project.
Everyone at RTA is saddened by the loss of Dick Morley, the “father” of the programmable controller (PLC). There are not many people that come to be known for founding entire industries, but Dick was one of those people. At just 34 years old, he turned a problem – the difficulty applying 1960 era minicomputers to logic tasks – into an industry. Sadly, Dick lost a son many years ago and his wife, Shirley, in recent years. Dick was known for his devotion to Shirley and suffered greatly at her passing. Our condolences to the Morley family.
