It's Critical To Standardize Your IoT System

I was recently working on an IoT system for an equipment rental company. They want to monitor all of the pieces of equipment that they rent out like generators, compressors, earth movers, cranes, etc.

My client’s needs were fairly straightforward: they need to know the device location and operating parameters. They need to know the location not just because the equipment gets stolen occasionally, but because the customer sometimes moves the equipment to places it shouldn’t be, like across the border where it is hard to get back.

They need to know operating parameters because customers don’t always follow the periodic maintenance guidelines and tend to run equipment until it breaks. With this new system, they can monitor the operating hours and either require the customer to bring back the equipment when maintenance is required or visit the site and perform the maintenance there.

To be fair to their customers, they are typically on tight deadlines and may not even know how hard or long they have run the equipment. Giving them a tool to help manage this is supported by many customers because they don’t want the liability of ruining an expensive piece of equipment.

The large units like generators and compressors are powered by large engines made by one of the big players like Caterpillar, Cummins, or Volvo. All of these have CAN (Controller Area Network) bus interfaces, so to look at operating parameters either for alarms or normal operations is a straightforward interrogation of the CAN bus controller.

CAN bus was developed in the early 1980s by the German firm Bosch to control its electronics in automobile applications. This vehicle bus standard was designed to allow microcontrollers and devices to communicate with each other in applications without a host computer. Not surprisingly, a German automobile manufacturer, BMW was the first production vehicle to feature a CAN bus.

CAN bus is one of the protocols used in the on-board diagnostics (OBD)-II vehicle diagnostics standard. This is the port that your dealer plugs in to see what is wrong when you take your car in for service.

While the majors use CAN bus, some engine manufacturers only use Modbus. Modbus precedes CAN bus as a standard but is very similar. It is a serial communication protocol developed by Modicon to communicate with its PLCs (programmable logic controllers). Unlike CAN bus where the devices can directly communicate with each other, Modbus has a Master/Dependent architecture where there is one Master and up to 247 Dependent devices.

Modbus is an open protocol and is perfect for monitoring many elements on heavy equipment from a single controller.

Monitoring devices is not easy

With the open and published standards driving communications on these devices, you'd think monitoring all this equipment would be a piece of cake.

Wrong.

The tricky part is that all of these standards is that they really only standardize the communication component, not always the data. Manufacturers use these standards, but intentionally make it difficult to extract the data. This allows them to control access to sensitive information.

Why is this critical? The recent example of hackers gaining access through a wireless monitoring system and then controlling the braking, steering, and engine operation of several car models has made manufacturers a lot more sensitive to these issues.

Hackers showed how they could gain access of and control the bus, which would then allow them to do things like unlock the doors, turn on the engine, and drive away, or worse, issue a remote command to shut down the engine while you are driving 60 miles an hour down the highway.

With this level of threat in mind, proprietary, secure systems seem like not such a bad idea. But, if you are an equipment rental company that has 50 different pieces of equipment that you want to deploy to your customers, you don’t necessarily want to have 50 different proprietary systems that you have to log into to track your assets. It would be much nicer to have a single platform that could monitor all of your assets and give you consolidated map views of their location and alarm views of any issues.

But the manufacturers don’t really like granting this access because there is a loss of control of security. So they carefully control access to API platform or restrict them all together. Even when they give you access to their API they do their best to conceal where the data is coming from and won’t let you know which registers hold what data.

If you want to figure this out so you can monitor something independent of their API’s set of controls, the only way to do this is sample the data and then start trying to figure out what the values mean.

For example, if you rev the engine and you see a value go from a steady state of 20 to increasingly large numbers and then back down to increasingly smaller numbers to finally return to a level of 20, then you can guess that the field contains RPM data. If you know steady state data, you can guess which fields are which, but with a large number of fields, it is virtually impossible to reverse engineer.

So what is the answer?

Standardize your IoT system and control access

The current system of proprietary platforms doesn’t scale well as users start to want to combine data for multiple devices into systems of systems platforms. This is not just limited to heavy equipment. The same could be said for smart building applications. Honeywell and others have for years had closed standards and point to the Target hack of an HVAC monitoring system that allowed entry into Target’s corporate network as a reason for keeping systems closed.

What is needed is not just an API that allows you to securely get this data, but a standardized approach to controlling access to the API so that you can be identified as a white hat, trusted, user of the API and the data. There are many potential architectures for this based on some version of secure contract architectures (Etherium, etc).

While this may seem like over kill, with billions of devices looking to be connected, we do have to control access to IoT systems. Otherwise, the whole network viability collapses.