After 20 or 30 years of faithful service, it’s certain any safety instrumented system (SIS) will need some updates and upgrades, if not an outright replacement. The trick is identifying and implementing all the advances and innovations that likely emerged during the SIS’s long tenure.
“An SIS usually needs modernization when it, or part of it, is facing obsolescence. But it’s important to step back and think about what needs to be done,” said Steve Lindsay, solutions leader in competitive displacement at Honeywell. “Ongoing compliance is a given, but are there valuable lessons learned that should be considered in advance of any migration? What hard-earned intellectual property (IP) do you want to capture and document for future use?”
Lindsay presented “Retain IEC 61511 compliance while modernizing an SIS” this week at the Honeywell User Group meeting in Madrid.
Back to SIS basics
Whether an SIS is being upgraded or implemented for the first time, Lindsay reported there are several directives and procedures that should be closely followed. These include completing a risk assessment (RA) and process hazards analysis (PHA). There are several options for performing these, but one of the best known is the IEC 61151 process safety summary, which includes:
- Initial assessment employing a HazOp and PHA, and using those results to do a layers of protection analysis (LOPA) and assign protection layers.
- Draft a safety requirement specification (SRS) and design safety integrity functions (SIFs) that provide safety integrity levels (SILs) consistent with the needs indicated by the initial assessment.
- Implement the SIS and validate via factory assessment test (FAT) or site assessment test (SAT).
- Operate and maintain, with proof testing as indicated.
“If your SIS or emergency shutdown (ESD) system has been operating for 20-30 years, you need to determine what steps to take before you migrate it,” explained Lindsay.
Realign as-is and as-designed
Lindsay reported that an effective SIS migration begins with a high-level walk of the facility and its legacy applications. This allows users to bring their function block logic back into an as-is definition; conduct offline and virtual tests; repeatedly emulate, migrate and verify their SRS design specifications as needed; and push it to a safety management system such as Honeywell’s Safety Manager SC (SMSC) software.
The next step is reverse engineering to retain IP and produce an as-is state on an evaluation platform. Some considerations are:
- What format is my existing application in, such as ladder logic?
- How well is my existing application defined, and is it well commented?
- Does it meet new requirements and best practices?
- Have I fully documented all my requirements, and are they 100% covered?
“Users can manage their reverse engineering by leveraging assisted migration services with tools such as iDefine to automate application retrieval and replication; put the running application in formats consistent with IEC 61131 function block diagrams; and minimize human error when revising old applications,” explained Lindsay.
To emulate an SIS application offline and verify its as-is state compared to its as-designed state, Lindsay added there are several steps for benchmarking to the original design. These include:
- Verify the application against the SRS by documenting gaps, new or updated requirements, such as regulatory expectations or best practices.
- Evaluate gaps and establish closure actions by asking if original requirements or assumptions are still valid, and reevaluate and update safety requirements as indicated. For example, reevaluate original safety integrated function (SIF) designs to determine if they’re too optimistic or too pessimistic.
- Leverage digitalization capabilities to connect data. Feed iDesign results to tools such as Honeywell’s Process Safety Workbench (PSW) software to connect as-tested functions to as-designed ones and enable dynamic functional safety management (FSM) capabilities.
- Test and document safety requirements achieved, and record automated testing scripts for reuse for easier, future FSM activities.
“Users can add cause-and-effects, step changes and what-ifs, such as if a pump isn’t running, did its logic still behave in the right way?” said Lindsay. “It’s important to determine whether operations diagrams were OK before the actual migration.”
Next, perform offline emulation and verify as-is state against the “to-produce, as-desired” state before migrating. This involves capturing as-operated requirements by asking:
- Is the original design fully operational? Follow-up questions may include: Can proof testing be easily done while running? Are actual demand rates captured? Are bypass assumptions acceptable? Has the process changed enough to create a different steady state?
- Was equipment availability suitably accounted for? Follow-up questions may include: Is field equipment consolidated in too few controllers? Are there significant amounts of non-safety interlocks in the SIS?
- Were shutdown and restart conditions accurately captured? Plus, can the process be easily shut down and restarted? Are startup overrides accurate? And do interlocks affect how some equipment restarts?
To connect as-is to as-designed digitally, and employ lifecycle analysis tools like PSW and Honeywell’s Process Safety Analyzer (PSA), Lindsay advised;
- Digitally connect SIS data;
- Use assisted FSM;
- Minimize human effort, and reduce manual effort;
- Use Dynamic Safety Lifecycle enablement;
- Update, adjust and verify requirements with all stakeholders; and,
- Track demand rates and bypassing.
No time like now to migrate SIS
“If an SIS has been running in its box for 20-30 years, and it’s not documenting well, or its running OK but no wants to touch it, now may be the time when you have to touch it,” added Lindsay. “One relatively recent innovation that can help is Honeywell’s Universal I/O (UIO) and Safety UIO. These solutions incorporate operational lessons learned into migrated solutions, remove workarounds, and are often a preferred option for operations and maintenance teams. UIO and Safety UIO remove constraints such as homerun cables driving I/O allocations; assigning critical equipment across multiple systems or controllers; increase availability without decreasing reliability with Safety UIO; and provide hardware conversion kits to reduce footprint in existing equipment rooms and cabinets.”
Finally, Lindsay reported that users can migrate their legacy logic to new logic and test functions. “For instance, when migrating from a typical, legacy Triconex one-out-of-two (1oo2) voting safety system to SMSC with 1oo2 voting, users can leverage the standard functional logic library.
“This allows a standard Experion PKS to display SIS status right out of the box. Maintenance is also easy via a publish function, and users can remove peer control data interface (PCDI) and Modbus arrays,” he concluded. “We had one customer with 100 PLCs they wanted to modernize, but now they no longer had to wait. They could pull years of logic in advance and add what they needed and wanted. The were ready ahead of time and got their SIS migration off the critical path.”
