Blog Post

State Based Control – Super Charges Your Front End Loading

Tom Nolan, ProSys

Front end loading has a tremendous effect on a project budget and completion time. Front end loading is also crucial for hitting the mark on quality with safety, performance, environmental, and economic constraints for the completed project. This is in the face of ever more complex assets and an aging workforce. Plants should be able to come up on day one compliant with alarm loading standards like ISA 18.2 and safety instrument system like ISA 84.01. These standards have tremendous safety and economic implications. Plants should also hit the ground running by making the pounds with the quality and reliability they were designed for.

How can state based control help?

One key point is knowledge capture and transfer. Sometimes, plants are not started up, commissioned, or operated exactly the way they were designed to be. This has a tremendous impact on safety and loss prevention, especially when bringing in new equipment or even a new technology that operations personnel are not familiar with. People are working long hours under high stress in an environment that is new to them. This may be compounded by confusing alarm showers. The involvement of control engineers, process engineers and equipment subject matter experts can capture, during the initial front end loading, how the equipment is designed to be operated into the automation.

A well designed and maintained safety instrument function will prevent the targeted scenario from occurring within the designed for probability of failure on demand. The firing of the safety instrumented function may also cause a significant process upset with implications within the unit as well as up and down stream units that the operator will need to deal with. Knowledge capture and transfer to automation helps in knowing how to deal with these scenarios.

We know that 70% of incidents occur on startup or shutdown of the plant. A safety instrumented function working alone may well be a contributing factor to the next thing that goes wrong. Through knowledge capture of the design, team degradation scenarios are automated into the design of the control system. The unit with the problem automates its response and communicates its diminished capabilities, in terms of what it can provide to the process or needs from the process, to up and down stream units that will respond by straying at the highest state of readiness possible with the current degradation, in automatic. This leaves the operator with their heads up managing the process through the upset instead of tied up controlling many loops in manual.

When equipment is started up according to automated procedures and dynamic alarm management, it is going to work better and last longer with fewer unplanned events. This is a great time to capture the knowledge of the design team and transfer it into the automation where it is always available for use and for continuous improvement throughout the life time of the facility.

Instrumentation justification and dynamic alarm rationalization can be integrated into the front end loading process. Instrumentation is expensive. It has to be purchased, installed, maintained, added to the graphics and configured in the DCS.  Instrumentation should be justified for its intended use. If the instrumentation is not deliberately justified for use early in the front-end loading, it causes problems. You may end up with instruments that are not needed, causing unnecessary expense and cost of ownership. Worse yet, instruments that should be there and are not, lead to operability issues. Adding these instruments later on in the project adds much more expense and rework into the project. Before the end of FEL-2, there should be a good list of the instruments that are needed.  You can take this information forward to the next cost estimate. If justified for use, there should be minimal creep through the process. Justification based on the level of automation can include, control, alarming, safety, reliability, accounting, troubleshooting and others. Since alarms are a justification for instruments, this is the point where alarm rationalization needs to take place. The alarms that are needed should be a factor in determining the instrumentation list, not “here we have instruments, now let's put alarms on them”.

The work process for doing state based control can be taken from the process flowsheet to develop an instrument list which takes into account the preliminary hazard analysis, required alarms, start up / shutdown and degradation scenarios that should not need to change much past the FEL 2 stage.

Non-state based control is optimized for the running state. It makes sense in terms of time, but not in terms of risk since 70% of incidences occur starting up and shutting down. These are the states where operators have the least experience, and the non-state based control and alarming system may be a hindrance rather than a help. The startup / shut down and commissioning out states have advantages for an instrument list that is less likely to change but also identifies operability and reliability issues early in the project when they are a lot easier to deal with. It allows for a layered approach to developing the control and safety system narratives for each stage of the front end loading with the appropriate level of detail.

Following a good state based control design process in the front end loading will:

  • Give you an instrument list that you can hang your hat on with less creep
  • Identify operability and reliability issues early, preventing scope creep
  • Capture and transfer knowledge to the control system and build it in to the control narratives for the DCS and safety system
  • Provide a solid foundation for knowledge capture and continuous improvement for the operating life of the facility
  • Provide a solid foundation for the creation of operating procedures and the user’s manual

Whitepaper