Handling Indirection Safely on a PLC

I’ve seen my share of indirection errors on a PLC. I developed the method I describe here because I was sick of seeing people scratching their heads, wondering where the weirdness came from.

There are many reasons to use indirection, or the value of a register in another register. There may be a need for automated sequencing and staging of large assets, such as pumps. So for example, a low time pump might be in the lead and the strategy might be to even out all the run times. There may also be non-linear lookup tables, or perhaps a queue of assets to be handled.

In most PLCs I don’t see any facility to handle out of bounds indices for arrays. I’m not sure if they check the array boundaries and set a flag somewhere, fault, or what. In any case, I developed a method for handling arrays of indirection so that the operation stays safe.

This is something I suggest using Instruction List (IL) programming for. The feature can be turned in to a few function blocks and possibly even reused for other applications.

First, figure out how large the array has to be and then choose the next size up on a binary scale. So for example, if you have a need for 12 registers, define an array of 16.

Next, take the index value, add an offset to it, and then AND it with a mask that equals the array size. In this case the mask would be 0x0F.

Your offset can be 1 or it can be higher. The point is that at index 0 of the array, there should be a value that is invalid –such as -1 or 65535. This is what I call the poisoned end. Likewise, at the last elements of the array you do the same.

Then, before doing the check, record the value of the indirect address. Compare it to the value after you have done the AND mask. If it is different, then you know something is wrong. Raise a software quality alarm. Then, check the indirection value. If it is a poisoned value, you should raise another software quality alarm. This is an indication of a fence-post error.

The goal is to trap unusual situations instead of letting the PLC go off in to the weeds addressing weird things. This will help you quickly determine if the problem is an attack or if it’s just another PEBKAC instance. It also prevents problems, where the array index on PLC accidentally overwrites something it should not have.

Automate Securely and Safely!

http://www.infracritical.com

With more than 30 years experience at a large water/wastewater utility and extensive experience with control systems, substation design, SCADA, RF and microwave telecommunications, and work with various standards committees, Jake still feels like one of those proverbial blind men discovering an elephant. Jake is a Registered Professional Engineer of Control Systems. Note that this blog is Jake's opinion ONLY. No Employers, past or present were ever consulted with regard to these posts. These are Jake's notions. Don't blame anyone else for them.