In developing a solution with a programmable logic controller (PLC), there is an infinite number of approaches that can be taken to solve any problem. No two people will ever produce the same solution. Everyone has their own style, resulting from years of experience, development, and collaboration with others when creating a solution. This begs the question, isn’t there a global standard for how these problems should be tackled? The answer is yes, through the use of the ISA88 and PackML
S88 & PackML
The International Society of Automation (ISA) has a technical standard that serves as a guide for implementing batch processing systems. Within this standard, commonly referred to as S88, are definitions and models which can be adopted universally by machine and equipment manufactures.
PackML is the international standard put forth by the Organization for Machine Automation and Control (OMAC) to help homogenise automation systems across the world, through open and modular program development.
The goal of both S88 and PackML is simple - machines should seem familiar and operate in a similar way when you ‘look under the hood’ regardless of location and function. As a result, these shared vision overlaps were hard to avoid, and now the two standards are all but homogenized.
FSM and Predefined States
A key component of PackML is the concept of finite state machines (FSM). An FSM is easy to understand, easy to implement, and yet often overlooked. Essentially, your machine has a set of predefined states it can be in, and it can only ever be in one at any time. This PackML state machine concept has been integrated into the S88 standard in recent years and by combining the two standards, allows for very robust coding solutions.
Using either standard, you will find seventeen states that are recommended for use, as shown below. The states have defined characteristics detailing how they should operate and what transitions are available from one state to another. For more information on how to implement a PackML solution, please refer to the OMAC implementation guide, which can be found here.
To enter or exit a state, a list of conditions must be met. The completion of one state is the trigger to move into the next state, and this process continues. States can be skipped or bypassed. The duration that a state is active can be used to detect faults. For example, if a startup state does not turn into a running state after an elapsed period of time, there might be a startup fault. If so, the machine will enter into a faulted state.
Examples of an FSM
A basic example of an FSM is shown below, though rarely would one be as simple.
In this example, the machine is in an idle state, waiting for a command to trigger the starting state. This then leads to the running state. When the stop button is pressed, the machine begins halting its action in a controlled sequence, eventually leading to the stopped state.
While sounding similar, stop and idle are distinct states. If you think of a process that needs some sort of cooldown or time delay between completing one job and starting the next, this is a perfect example of a stop state. On the other hand, the Idle state may be when a machine has just been turned on and is yet to start moving; it’s ready to go and just waiting for a command. If you were to use a car as an analogy, the engine would be off, and the car would be stopped when you got home. But your car waiting at a set of traffic lights is in an idle state, ready to go. Just because something is not currently running, it doesn't mean that it is stopped.
Another good analogy for the state machine example just discussed is going for a jog. Firstly, you may be sitting on the couch, idle. The internal monologue in your head tells you to go for a run, so you stand up and start stretching. Once done stretching, you start your run. Towards the end, you slow down, before eventually coming to a stop. And note you are not idle, you are stopped, you are recovering. Similarly, states are in a logical order, and you wouldn’t go from on the couch to slowing down. However, if you stretch and pull a muscle, you may skip the run and go straight to recovery.
It's very easy to see how an FSM can run virtually any process, from robots to packaging equipment and conveyor systems, to name a few examples. It feels natural as a logical way of completing a task, but the implications of using this type of program architecture in industrial controls are profound.
Benefits of using FSM’s:
- Familiarity: When working on a new system, it can be a daunting task to figure out how it works. Using a standard program set up with FSM methodology allows for a quicker understanding by following a logical sequence of events.
- Quicker Development: Starting from scratch is no longer required for a project. Using an FSM as the starting template for a project means that the conditions in which it operates are already predefined, correctly interlocked, and sequenced. All that needs to be added are the project specifics.
- Predictability: By using an FSM, the equipment can only transition into a limited number of states. As a result, any equipment that uses the same FSM will exhibit the same behavior as any other equipment.
- Reliability: There is only one state active at any one time, which drastically reduces the chance of unforeseen errors or unexpected behavior in the system. In real-world scenarios, it is not uncommon for errors to occur, especially during commissioning. A familiar example to many is a motor that fails to turn off after a stop button is pressed. Using an FSM, if the machine is not in the correct state, it should be impossible for a motor to spontaneously come on or stay on incorrectly.
- Safety: It becomes a lot easier to manage the outputs on a system to prevent or accidents during commissioning. By preventing a state transition, for example, starting, it is easier to interlock operations and prevent unexpected behavior.
- Functionality: What happens when someone presses stop halfway through a startup cycle? Should it even be possible to press this button? Easily decided and changed using an FSM. If the machine is starting, then the next state is not stop. Therefore an attempt to stop the machine will be unsuccessful. Or, if it is desired, stop could be a priority at any point in the process; therefore, it can be set up as a dominant state to the others. Rather than meticulously modifying the operating conditions of hundreds of lines of code, with FSM, you simply modify what ‘stopping’ is defined as in the program.
- Monitoring: Overall equipment effectiveness (OEE) is a useful metric for companies, both big and small, to see how a machine is operating. FSM’s can be used to easily query success, failure, or waste in a system. How long did the machine spend running? How many times did it go into a fault state? How much time was it sitting in the Idle state not getting used? Counts and durations are easily converted into performance statistics allowing easy tracking and comparison between machines.
- Communication: Systems integrators are often required to have multiple machines of various origins controlled by a single overarching system. Actions such as starting, stopping, resetting, and waiting are often totally different from one system to the next, making it an arduous process to connect these machines. Intellectual property may become an issue when a change needs to be made to a proprietary system. Many machine manufacturers refuse to give open access to their code in fear of theft. FSM methodology allows for this to be simplified. If each machine is state-driven, then changing from one mode to another to the next is as simple as turning on a single bit. We are now a step closer to speaking the same language, meaning that modifications don’t need to be made to individual machines, keeping intellectual property safe.
FSM Nesting, Sequencing, and Coding
FSM’s can be nested, allowing for individual zones to be operated in a controlled and predictable manner. At a plant level, we may enter a starting state, and as part of the plant-wide sequence, we may start zone 1, with zone 2 following once it is running. Within each of these zones may be a separate FSM nestled within, allowing the needs of that zone to be met.
FSM’s can be tied in with sequence engines, making fault finding easier. By using a state and step in the program, faults can be quickly identified and corrected. Say we were to see a timeout in step seven during the ‘startup’ state of a machine. Without knowing the specific system, an engineer could quickly navigate to the exact location in the code where the error has occurred to rectify the situation.
FSM’s can be a difficult concept to grasp initially, but this simple approach to programming creates a flexible, robust system to manage all aspects of the automation process.
Need a Hand?
Crossmuller excels at implementing state-driven solutions across a variety of platforms with a focus on the PackML and S88 standards. If you would like to improve your application, get in contact with us today.
