S1E52 12.4

The SIS is built, tested, and waiting on the factory floor. Now comes installation and commissioning, where new problems can surface.

During the Factory Acceptance Testing (FAT), you're going to find issues.  You can’t fix them on the spot— you need to trace each one back to wherever it originated in the safety lifecycle and correct everything downstream from that point.

Factory Acceptance Testing is where Ed Marszal picks up in Clause 13, starting with an admission: the clause title may be wrong, since 13.2 is called Recommendations when every other point-two clause in the standard states requirements. Scope matters here FAT applies to the SIS logic solver, the engineered, customized subsystem, not off-the-shelf field devices like a pressure transmitter. Ed works through the objective's three notes, then the twelve-bullet planning list in 13.2.2: black box functionality, performance, environmental, and power-failure testing, plus test cases, dependencies on other systems, personnel competency, hazard assessment, and documenting results, with a nod to using Kenexis® Open-PHA® checklists or Kenexis® Open-Audit™ to run it. The episode ends at 13.2.3's one-sentence requirement to test a defined version, with 13.2.4 through 13.2.7 held for next week.

Clause 12.5 closes out the software section with the meat of application program testing: verification planning tied back to Clause 7, an independent competent-person review, and nine bullet points covering conformance testing, exercising all parts of the program, representative data ranges, negative testing, timing and sequence checks, communication overload stress tests, and integration with the actual logic solver hardware. Ed Marszal walks through each one, then covers I/O data mapping verification, impact analysis for mid-testing fixes, and the seven-item documentation requirement that insists on recording passing tests, not just failures. Clause 12.6 closes with methodology and tools: complying with vendor safety manuals, and five purposes your methods, techniques, and tools must serve. Throughout, Ed threads a running argument for automating this testing with tools like ProLyTx, tied to the newly rebranded Kenexis SIS software.

The best and safest way to write software is to break things down into tested reusable modules...

At the risk of saving you from hours of unnecessary work, in our latest episode, we tackle a surprisingly common habit: trying to do application program design and implementation at the exact same time. Tune in to hear why this happens, why it's a problem, and how to stop doing it!Grab your headphones and let's streamline your workflow!

Designing software comes before writing it. We're still inthe design phase and will be for a bit…Listen in to this episode as the discussion of this topic continues.

To clarify, the standard separates application program design from its actual implementation.  It feels like a bit much…Join us for our 50th episode as this is discussed in more detail!

The startup sequence of a Safety Instrumented System (SIS)represents a critical vulnerability phase, as it triggers initialization code that rarely executes during steady-state operation.Join us as this important topic is discussed in this episode.

The first technical safety standard ISA84 didn’t talk about programming in it at all.  So, we decided when we added it, wewould wildly over complicate the situation…