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…

Do not incorporate human failure into your SIL verification calculations, it will actually lead you to do the wrongthing.

In this episode, this important topic is covered by our industry expert as he discusses these sections and shares his vast knowledge and experience.

When it comes to SIL verification calculations, we look at Clause 11.9. It’s appropriately titled 'Quantification of Random Failures'…putting the focus on 'random' right there in the name.