In the complex landscape of modern industrial facilities, spanning oil and gas production and processing, chemical and pharmaceutical production, mining, and the emerging hydrogen sector, the reliability of a high-performing plant often hinges on the integrity of its logic.
For experienced engineers, the transition from general control systems to functional safety requires a fundamental shift in perspective. While standard control logic focuses on operational efficiency and process optimisation, functional safety software is governed by a rigorous life-cycle intended to retain simplicity and robust testing capability.
At the heart of these systems is the safety logic solver, often a Safety PLC (Programmable Logic Controller). However, a Safety PLC is only as robust as the instructions it executes. Writing a comprehensive software specification (formally referred to in international standards as the "application program safety requirements”) is perhaps the most critical step in ensuring that a system performs its intended functional safety tasks without introducing new risks.
This blog explores the practical aspects of drafting software specifications in accordance with IEC 61511, the international standard for safety instrumented systems (SIS) in the process industry.
The Systematic Challenge: Why Software Fails Differently
To write an effective specification, one must first understand how failure occurs in the digital realm. For safety instrumented system hardware, we primarily design against "random hardware failures" - the physical degradation of components over time.
Software, by contrast, does not "wear out." Software can only fail due to systematic errors resulting from pre-existing faults introduced by human error during the specification, design, implementation, or modification stages.
A Safety PLC application program that contains a logical error has that error "built in" from the moment it is compiled, even if that error only displays under a specific, rare set of process conditions.
According to IEC TR 61511-4, a common misconception among project teams is focusing solely on hardware reliability (SIL calculations) while neglecting the systematic rigour required for software. The software specification is your primary defence against built-in errors. If the specification is clear, precise, and verifiable, the likelihood of a programmer introducing a dangerous bug is significantly reduced.
Integrating Software into the SIS Safety Life-cycle
In the IEC 61511 framework, functional safety is managed through a structured Safety Life-cycle. The development of the application program is not an isolated task; it is a dedicated phase that begins only after three critical precursors are established:
1. Hazard and Risk Assessment (H&RA): The process of identifying hazardous events and determining the necessary risk reduction.
2. Allocation of Safety Functions: The decision of which independent protection layers (such as a relief valve or a Safety Instrumented Function (SIF)) will provide that risk reduction.
3. Safety Requirements Specification (SRS): The general SRS for each safety instrumented function should be developed as far as possible before considering logic solver software. Although the overall SRS can include both hardware and software, it’s a good idea to control them separately while keeping them fully interlinked.
Key Elements of the Application Program (AP) safety requirements
A high-quality specification must move beyond generalities. IEC 61511-1, Clauses 10.3.2 to 10.3.6, provide detailed guidance on AP safety requirements, whereas Clause 12 and its sub-clauses list additional requirements for AP development, design, implementation, and testing.
Key elements include:
1. Functional Relationship and SIF Identification
The specification must clearly identify every SIF supported by the application program and its associated Safety Integrity Level (SIL). For each function, you must describe the exact functional relationship between process inputs and outputs, including the required logic, mathematical functions (if any), and any necessary "permissives" (conditions that must be satisfied before another step can start or restart).
2. Real-Time Performance and Scan Times
A Safety PLC must be able to act before a process upset escalates into a hazardous event. The SRS must define the "process safety time" for each SIF, so it is essential to specify that the application program scan time is sufficient to complete the safety action within this window, even in the presence of faults.
3. Fault Behaviour and "Bad PV" Handling
One of the most critical sections of the software SRS should define how the system responds when it detects internal failures or field-device faults. One must specify the exact action to take for a "Bad PV" (bad process variable), such as an out-of-range sensor, a frozen value, or a detected short circuit. Typically, the system is designed to move the process to a "safe state" upon detection of such failures.
4. Modes of Operation and Reset Philosophy
Safety logic often requires different behaviours during plant start-up, normal operation, and shutdown. The specification must address all relevant operating modes, as history shows that most industrial incidents occur outside of normal operation. Furthermore, the reset philosophy must be explicitly defined: once a SIS has placed a process in a safe state, it must generally remain in that state until a deliberate, manual reset is initiated.
5. Interfaces, Bypasses, and Security
The specification must detail the data exchanged between the Safety PLC and external systems, such as the Basic Process Control System (BPCS) and any Operator Interface. Crucially, it must define how bypasses are managed. If a SIF is bypassed for maintenance, the software must ensure this state is alarmed to the operator and administratively controlled to prevent it from being forgotten. Additionally, given modern connectivity, the spec should include security requirements to protect the SIS from cyber threats.
The Philosophy of "Simple and Modular"
To minimise systematic errors, the process industry tends to use Limited Variability Languages (LVL). These are languages like Function Block Diagram or Ladder Logic, designed to be easily understood by technicians and engineers rather than computer science specialists.
When drafting your functional safety software specification, you should advocate for:
- Modularity: Separating logic into self-contained, repetitive modules (like a standard valve sequence). This makes the code easier to test and reduces the risk of "side effects" where a change in one area breaks a function in another.
- Simplicity: Avoiding "clever" or unnecessarily complex code. Every requirement in the specification should be "testable", meaning it provides clear criteria for a pass/fail verification.
Verification: The Necessity of Independent Review
Writing the specification is only the first half of the systematic integrity journey. You must also prove that the resulting code matches the specification. This is the verification phase.
A common pitfall is the "checklist mentality," where teams check off project deliverables without ensuring their effectiveness. To combat this, IEC 61511-1 requires that the application program be reviewed by a competent person who was not involved in the original development. This independent review checks for unintended functions and ensures that the logic meets every requirement defined in the specification without any negative side effects.
Conclusion
Drafting a software specification for a Safety PLC is a specialist engineering task that requires a deep understanding of the system being configured and its capabilities and restrictions. By following the structured requirements of IEC 61511 and the specific Safety PLC manufacturer’s safety manual, you ensure that your safety system is not just a collection of hardware, but a reliable safeguard that will perform as intended when the process is at risk.
The complexity of these requirements is why we established the eFunctionalSafety INSIDER community. We understand that experienced engineers value practical, cross-industry insights that go beyond the dry text of a standard. Whether you are modifying a legacy facility or designing a greenfield plant, having a network of peers to discuss these "real-world" design challenges is invaluable.
Subscribe to eFunctionalSafety INSIDER and join a collaborative community of like-minded professionals. Register below to receive our technical deep dives.