Understanding the IEC 61508 Functional Safety Lifecycle – Part 3

09 Sep 2026

Safety Requirements and System Design

In the previous blog in this series, we explored hazard and risk assessment as the starting point of the IEC 61508 functional safety lifecycle. We looked at how techniques such as HAZOP, FMEA, FTA, and LOPA are used to identify hazardous events, assess risk and determine the level of risk reduction required.

However, identifying hazards alone does not make a system safe. At some point, the results of the hazard and risk assessment must be translated into clear, measurable and implementable engineering requirements.

This is where the lifecycle begins to move from risk identification into system realisation. Within IEC 61508, this transition occurs through the development of safety requirements and the subsequent design of the safety-related system. It is one of the most critical stages of the entire lifecycle because it defines exactly what the safety system must do, how it must behave, and the level of integrity it must achieve under both normal and fault conditions.

From Hazard Analysis to Safety Functions

The hazard and risk assessment carried out earlier in the lifecycle becomes the direct input into safety requirements development. Each identified hazardous event must now be evaluated to determine:

• what safety function is required
• what initiates the function
• what action the system must take
• how quickly it must respond
• what integrity level is required
• and under what operating conditions the function must remain effective

This is one of the areas where strong traceability becomes essential within IEC 61508. The lifecycle expects a clear engineering link between: Hazard, Risk Reduction Requirement, Safety Function Allocation, Safety Requirement Specification and Design Implementation. Without this traceability, it becomes difficult to demonstrate that all identified risks have been properly addressed.

The Role of the Safety Requirements Specification (SRS)

Within IEC 61508, the primary document used to define these requirements is the Safety Requirements Specification, commonly referred to as the SRS. The SRS becomes one of the most important documents within the entire functional safety lifecycle because it defines exactly what the safety-related system is expected to achieve. A well-developed SRS typically includes:

• description of each safety function
• safe state definition
• operating modes
• trip conditions and initiators
• response times
• SIL requirements
• fault reaction behaviour
• diagnostics expectations
• environmental constraints
• proof test requirements
• reset and restart behaviour
• interfaces with other systems
• assumptions and dependencies

The objective is to create requirements that are clear, measurable, testable and unambiguous. Poorly written safety requirements are one of the most common root causes of later lifecycle failures.

System Architecture and Design

Once the safety requirements have been established, the lifecycle moves into system design and architecture development. This is the point where the safety concept begins to take physical and logical form within the system.

The final design may include sensors, programmable logic systems, safety relays, communication networks, software applications, final control elements and diagnostic functions. The exact architecture depends heavily on the complexity of the application and the level of risk reduction required. At this stage, the outputs from the SRS begin driving detailed engineering decisions. Engineers must determine how the system will achieve the required safety function, how failures will be detected, how the system transitions to a safe state and how sufficient integrity will be maintained throughout the operational life of the equipment.

It is also at this point within the lifecycle that IEC 61508 branches more deeply into the separate realisation requirements found within IEC 61508-2 for hardware and IEC 61508-3 for software. Hardware activities may focus heavily on areas such as redundancy, diagnostics, fault tolerance and reliability analysis. Software activities, meanwhile, are typically centred around systematic fault prevention through structured development methods, defensive design techniques, verification activities and configuration control.

The separation is important because hardware and software failures behave very differently. IEC 61508 therefore approaches each using different engineering methods while still integrating both into the same overall safety lifecycle.

Final Thoughts

Safety requirements and system design represent the point where functional safety moves from risk assessment into implementation. The hazards identified earlier in the lifecycle are now translated into defined safety functions, measurable engineering requirements and ultimately real-world hardware and software architectures intended to reduce risk to a tolerable level.

This stage of the IEC 61508 lifecycle is often where the long-term success or failure of a project is determined. Strong safety requirements provide clarity for designers, software developers, integrators and assessors throughout the remainder of the lifecycle. Weak or ambiguous requirements, however, frequently lead to redesign, inconsistent implementation, validation failures and costly project delays later in development.

In the next blog in this series, we will explore verification and validation within IEC 61508, including how organisations confirm that safety-related systems have been implemented correctly, tested appropriately and are capable of achieving the required level of functional safety in practice.