How to Do State-Based Control Well

In today’s competitive climate, everyone wants Faster, Cheaper, and Better, which can be viewed as constraints:

• Time
• Cost
• Quality

Typically, it is impossible to do all three throughout a project, but we can strategically focus on each at various stages to achieve all three. By the same token, an efficient and effective state-based control (SBC) work process has three key elements:

• Agile methodology
• Object-oriented programming
• Iterative testing

Agile Programming Methodology

Agile methodology uses a set of principles or value comparisons as a guide to help speed us through; thus, the focus is on faster. The agile manifesto is as follows:

While there is value in the items listed on the right, the items on the left have more value. Each of these has a consequence in terms of time.

Individuals and interactions over processes and tools

When projects are confined to detailed processes or are generating all the work using specific tools and methods, we find the 80/20 rule in play – 80% of the work takes 20% of the time, while the other 20% of the work takes 80% of the time. To better handle this 20% of the work, we can let individuals have decision-making power through team interactions.

Working software over comprehensive documentation

SBC projects are often bogged down in documentation. While we want to be accurate and complete, we need to get a sense for just how so. As more detail is put into strategic development, the more we find ourselves going down rabbit trails. This is human nature. We think in pictures. If I say “dog,” you don’t think D-O-G, you get the image of a dog in your mind. If I say, “fast brown agility dog,” the image gets clearer, but that’s because a picture says a thousand words. So, we must focus more on working software and see what the program does to get the picture.

Responding to change over following a plan

Now that we see the general concept, let’s apply the 80/20 rule. Because change happens, plans change; thus, we can see how constantly reworking the plan consumes time while having a set of guard rails saves time.

Customer collaboration over contract negotiation

Because of the complexity of SBC projects, they are challenging to estimate. Spelling out all the details in a contract becomes time consuming. By collaborating and setting boundaries, we can apply the 80/20 rule.

In doing so, we benefit from the first of our three constraints, time.

Object-Oriented Programming

SBC lends itself to object-oriented programming. Basic intelligence is built into the templates (library objects) and then leveraged by instancing these objects for each specific use. Thus, each device has both basic intelligence from its library object and specific intelligence from its connected logic.

For example, an Analog Input Object can be called from a template library to build a Level object. The template would contain configuration that allows various levels of alarms (high, low, high-high, low-low), as well as Instrument Fault and Out of Service calculations. In this way, template objects can be configured to match the field devices that they represent. One standard object can be instanced (reused by naming it after each specific device, such as LT-10101) repeatedly.

Each unit then becomes a collection of intelligent objects, each containing its own information and instructions.

In this example, we also have an SFC (step diagram) with Step objects. The information in the steps can be used to operate the other objects in the unit and information from the other objects can be used to transition the steps.

The code might look something like this:

Step.heat IF RxLt.meas > RxLt.AlmL_Sptp AND Step.fill
MixerDO.cmd IF Step.mix AND not RxLT.almLL

The Step Transition object takes information from the Level object, namely its measured value and low alarm setpoint. This tells the process to move from the Fill Step to the Heatup Step. Once the process reaches temperature it moves from heatup to Mix. The Mixer see the step movement AND that the Reactor Low-Low level alarm is not on and turns itself on.

Object-oriented programming:

• Modularizes code making it reusable
• Allows templates and libraries to be leveraged
• Allows intelligence to be built into devices, equipment and units

These attributes benefit the second of our constraints, cost.

Iterative Testing

Iterative testing uses a layered recycling concept. Layered testing refines the product with independent protection layers, improving the quality. This requires simulation. A medium fidelity simulation with dynamic responses such as emulating feedback signals and process values based on device actions is sufficient. For example, to calculate a tank level, you accumulate the differences between flow in and out, where each flow depends on the position of the valve controlling it.

The first layer of testing is the initial debug where the programmer works the process through the steps (states) to fix any programming issues. The next layer of testing is with the manufacturing representative to determine what changes need to be made to fit the needs of the facility. Each of these first two layers may take several cycles to complete. The final layer is with operations to refine the program.

Additional modifications can and should be made during startup, as it is often discovered that what we thought we wanted it to do and what we actually want it to do are not always the same. This iterative or multilayered recycling approach to testing allows:

• bugs to be fixed
• intentions to be clarified
• refining of the program

These attributes benefit the last of our constraints, quality.

A Competitive Advantage

State-based control projects quickly pay for themselves, giving you a competitive advantage with better asset utilization and improved quality and safety. Using the three-phased approach of agile methodology, object-oriented programming and iterative testing can make for an amazing project completed on time, on budget and with superior quality.