Functional Safety Implementation
Functional safety is the part of overall safety that depends on the correct functioning of safety-related systems and external risk reduction facilities. In electronic systems, functional safety ensures that safety-critical functions perform correctly under all conditions, including when faults occur. This discipline has become increasingly important as electronic control systems have replaced mechanical and hydraulic systems in safety-critical applications ranging from automobiles and aircraft to medical devices and industrial machinery.
The implementation of functional safety requires a systematic approach that spans the entire product lifecycle, from initial concept through design, development, manufacturing, operation, maintenance, and eventual decommissioning. International standards such as IEC 61508 provide the foundational framework, while sector-specific standards like ISO 26262 for automotive, IEC 62061 for machinery, and IEC 60601 for medical devices adapt these principles to particular application domains. Understanding and correctly applying these standards is essential for developing safety-critical electronic systems.
Functional safety differs from intrinsic safety in an important way. Intrinsic safety eliminates hazards through inherent design choices, such as limiting energy levels to prevent ignition in explosive atmospheres. Functional safety, by contrast, relies on active systems to detect potentially dangerous conditions and take appropriate action to achieve or maintain a safe state. Both approaches contribute to overall system safety, but functional safety requires ongoing vigilance to ensure that safety functions operate correctly throughout the product's service life.
Safety Lifecycle Management
Understanding the Safety Lifecycle
The safety lifecycle provides the framework for all functional safety activities, defining the phases through which a safety-related system progresses from initial concept to decommissioning. IEC 61508 defines this lifecycle in detail, establishing requirements for each phase and specifying the documentation and verification activities needed to demonstrate compliance. Understanding the safety lifecycle is fundamental to implementing functional safety effectively.
The overall safety lifecycle begins with concept development, where the scope of the safety-related system is defined and initial hazard and risk analysis is performed. This phase establishes the foundation for all subsequent work by identifying the hazards to be addressed, the risk reduction required, and the allocation of safety functions to different systems or technologies. Decisions made during concept development have profound implications for the entire project, making this phase critically important despite its early position in the lifecycle.
Following concept development, the safety lifecycle branches into three parallel paths addressing the overall safety requirements, the E/E/PE (electrical/electronic/programmable electronic) safety-related systems, and other technology safety-related systems. Each path has its own requirements and verification activities, but they must be coordinated to ensure that the overall safety requirements are met. The E/E/PE path is typically the most complex for electronic systems developers, encompassing both hardware and software development activities.
The operational phase of the safety lifecycle covers installation, commissioning, operation, and maintenance of the safety-related system. This phase often receives less attention than development, but it is equally important for maintaining functional safety throughout the system's service life. Proper installation and commissioning verify that the system as built meets its specifications. Operation and maintenance procedures ensure that the system continues to function correctly as components age and conditions change. Finally, modification and decommissioning activities must be managed to prevent the introduction of new hazards or the loss of safety function.
Phase Gates and Management Reviews
Effective safety lifecycle management requires formal phase gates where work products are reviewed before proceeding to the next phase. These reviews serve multiple purposes: they verify that phase objectives have been met, they ensure that documentation is complete and correct, and they provide opportunities for management to assess progress and resource requirements. Phase gate reviews should involve personnel independent of the development team to provide objective assessment.
Management commitment to functional safety is essential for successful implementation. Management must provide adequate resources, establish appropriate organizational structures, and create a culture that prioritizes safety. This commitment must be visible and consistent throughout the project, not just at major milestones. When schedule or cost pressures arise, management must resist the temptation to compromise safety activities, recognizing that shortcuts in functional safety can have severe consequences.
Documentation is a critical aspect of safety lifecycle management. Every phase of the lifecycle produces work products that must be documented, reviewed, and maintained. This documentation serves multiple purposes: it guides development activities, it provides evidence of compliance with standards, it supports verification and validation, and it enables effective maintenance and modification during operation. The documentation burden can be substantial, but attempts to reduce it by skipping or combining documents often lead to gaps that are difficult to address later.
Configuration management ensures that all safety-related items, including hardware designs, software, documentation, and test procedures, are properly identified, controlled, and tracked throughout the lifecycle. Changes to safety-related items must be evaluated for their impact on safety functions and approved through appropriate channels before implementation. Without rigorous configuration management, it becomes impossible to ensure that the system as built matches the system as designed and analyzed.
Competence and Training Requirements
Functional safety standards require that personnel involved in safety-related activities possess appropriate competence for their roles. This competence encompasses education, training, and experience in both the relevant technical domains and in functional safety principles and practices. Organizations must assess competence requirements, evaluate personnel against these requirements, and provide training or supervision to address gaps.
Competence requirements vary by role and responsibility. Engineers designing safety-related hardware need different competencies than those developing safety-related software, and both differ from those conducting safety analyses or managing safety projects. Assessment should consider not only technical knowledge but also understanding of the specific application domain, familiarity with relevant standards, and awareness of organizational safety processes. Documentation of competence assessments and training records provides evidence of compliance with standards requirements.
Training programs for functional safety should cover both general principles and organization-specific procedures. General training addresses concepts like safety integrity levels, fault tolerance, diagnostic coverage, and verification methods. Organization-specific training covers the particular standards applicable to the organization's products, the organization's safety management system, and the tools and techniques used for safety analysis and documentation. Regular refresher training ensures that knowledge remains current as standards evolve and personnel change roles.
For roles requiring specialized expertise, such as conducting formal methods analysis or assessing compliance with complex standard requirements, organizations may need to engage external specialists or develop internal experts through intensive training and mentoring programs. The investment in developing this expertise pays dividends through more effective safety analysis, reduced rework, and more efficient certification processes.
Safety Requirements Specification
Deriving Safety Requirements
Safety requirements specification transforms the results of hazard and risk analysis into specific requirements for safety functions and their implementation. This process bridges the gap between identifying what could go wrong and defining what the system must do to prevent or mitigate hazardous events. Well-specified safety requirements provide clear guidance for design and unambiguous criteria for verification.
Safety requirements typically fall into several categories. Functional safety requirements specify what the safety function must do, such as detecting a fault condition and initiating shutdown. Safety integrity requirements specify how reliably the function must perform, typically expressed as a Safety Integrity Level (SIL) with associated failure rate targets. Interface requirements define how the safety function interacts with the equipment under control and with other systems. Timing requirements specify how quickly the safety function must respond to detected conditions.
The derivation of safety requirements must maintain traceability to the hazard and risk analysis that motivated them. Each safety requirement should be traceable to one or more hazards it addresses, and the risk analysis should show that implementation of the safety requirements reduces risk to tolerable levels. This traceability enables assessment of the impact when changes occur and provides evidence that the safety concept is complete and consistent.
Safety requirements must be written with sufficient precision to guide design and enable verification. Ambiguous requirements lead to inconsistent implementations and inconclusive verification. Each requirement should be verifiable through testing, analysis, or inspection. Requirements that cannot be verified cannot be demonstrated to be met, potentially creating gaps in the safety argument. The effort invested in writing clear, verifiable requirements is repaid many times during design, verification, and certification.
Safety Functions and Safe States
A safety function is a function implemented by a safety-related system whose purpose is to achieve or maintain a safe state when a potentially hazardous condition is detected. Understanding safety functions and safe states is fundamental to functional safety implementation. The safety requirements specification must clearly define each safety function, the conditions under which it operates, and the safe state it achieves.
Safe state definition requires careful analysis of the equipment under control and its operating environment. A safe state is a state of the EUC (equipment under control) where safety is achieved. For some systems, the safe state is simply de-energization; removing power prevents the hazardous motion or process from continuing. For other systems, the safe state may require active control, such as applying brakes or maintaining cooling. Some systems have multiple safe states depending on the nature of the detected fault or the phase of operation.
The time available to reach the safe state, called the process safety time, constrains the design of safety functions. If a hazardous event can develop quickly, the safety function must detect the dangerous condition and transition to the safe state within the available time. This timing requirement drives decisions about sensor selection, processing architecture, and actuator characteristics. Safety requirements must specify both the required response time and the allowable tolerance on this time.
Some applications require maintaining operation rather than simply shutting down when faults occur. These fault-tolerant architectures continue operating in a degraded mode after detecting certain faults, providing time for orderly shutdown or repair. The requirements for such systems are particularly complex, as they must specify not only the normal safety function but also the degraded operating modes, the transitions between modes, and the criteria for eventual shutdown if the fault cannot be addressed.
Allocation of Safety Requirements
Safety requirements allocation assigns portions of the overall safety function to specific subsystems or components. This allocation must ensure that the combined contributions of all allocated elements meet the overall safety requirement. Allocation decisions consider the capabilities of different technologies, the interfaces between subsystems, and the practical constraints of the application.
When safety functions are allocated across multiple subsystems, the reliability of the overall function depends on how the subsystems are combined. Series combinations, where all subsystems must function correctly for the overall function to succeed, require each subsystem to have high reliability. Parallel combinations, where any one of several subsystems can provide the function, can achieve high overall reliability even with less reliable individual subsystems. Most practical systems combine series and parallel elements, requiring careful analysis to determine overall reliability.
The allocation of Safety Integrity Levels to subsystems follows specific rules defined in functional safety standards. When subsystems are in series, the SIL of the combination is limited by the lowest SIL among the subsystems. When subsystems are in parallel with diverse designs, the combination can achieve a higher SIL than any individual subsystem. However, common cause failures that affect multiple parallel subsystems can defeat this improvement, necessitating analysis of common cause vulnerability.
Interface requirements between subsystems are critical safety requirements that are sometimes neglected. The interface specification must define not only the normal data exchanged but also the behavior when communication is lost, corrupted, or delayed. Failure to properly specify interfaces can create gaps where neither subsystem recognizes a fault condition, defeating the safety function. Interface requirements should address signal characteristics, timing, error detection, and behavior in fault conditions.
Hardware Fault Tolerance
Fault Tolerance Concepts
Hardware fault tolerance refers to the ability of a system to continue performing its safety function correctly despite hardware failures. Achieving fault tolerance requires architectures that can detect failures and either continue operating with reduced capability or transition to a safe state. The degree of fault tolerance required depends on the Safety Integrity Level and the consequences of safety function failure.
A system with hardware fault tolerance of N (abbreviated HFT = N) can tolerate N hardware faults before losing the ability to perform the safety function. A system with HFT = 0 has no tolerance for hardware faults; any single failure can cause loss of the safety function. A system with HFT = 1 can tolerate one hardware fault while maintaining the safety function. Higher levels of fault tolerance provide greater protection against hardware failures but require more complex and costly architectures.
Fault tolerance is typically achieved through redundancy, where multiple elements perform the same function so that failure of one element does not cause loss of function. Redundancy can be implemented at various levels: component redundancy uses duplicate components within a subsystem, channel redundancy duplicates entire processing channels, and system redundancy provides complete backup systems. The appropriate level of redundancy depends on the failure modes to be tolerated and the required fault tolerance.
Simply adding redundancy does not automatically achieve fault tolerance. The system must be able to detect that a failure has occurred and respond appropriately. Comparison of redundant channels can detect discrepancies that indicate failures. Diagnostic testing can identify specific failed components. The response to detected failures may involve switching to a backup element, reconfiguring the system, or transitioning to a safe state. Without effective detection and response, redundant elements can fail silently, accumulating hidden failures that eventually defeat the safety function.
Redundancy Architectures
The 1oo1 (one out of one) architecture represents a single-channel system with no hardware redundancy. This architecture can achieve HFT = 0 and is appropriate for lower safety integrity levels where the consequences of failure are limited. Safety is achieved through high component quality, extensive diagnostics, and appropriate proof test intervals. While simple and cost-effective, 1oo1 architectures have limited capability to detect and tolerate random hardware failures.
The 1oo2 (one out of two) architecture uses two parallel channels, either of which can perform the safety function. This architecture provides high availability because the safety function continues operating if either channel remains functional. However, it has reduced safety compared to voting architectures because a single dangerous failure in either channel can compromise the safety function until detected. The 1oo2 architecture is sometimes used where availability is more important than safety integrity.
The 2oo2 (two out of two) architecture requires both channels to agree before taking action. This architecture provides excellent safety because both channels must fail dangerously for the safety function to fail. However, it has lower availability because any single channel failure causes the system to take safety action, potentially resulting in spurious trips. The 2oo2 architecture is often used where spurious trips are acceptable and safety integrity is paramount.
The 2oo3 (two out of three) architecture uses three channels with majority voting. The safety function operates when at least two of three channels agree. This architecture provides both high safety integrity (two channels must fail dangerously) and high availability (one channel can fail safely without causing a spurious trip). The third channel also enables continued operation after a single failure, allowing time for repair without shutting down. The 2oo3 architecture is commonly used for high-integrity applications where both safety and availability are important.
Architectural Constraints
Functional safety standards impose architectural constraints that limit the achievable Safety Integrity Level based on the hardware fault tolerance and diagnostic coverage of the architecture. These constraints recognize that analytical reliability calculations alone cannot adequately account for all potential failure modes, particularly systematic failures and unknown failure mechanisms. The architectural constraints provide additional assurance through design diversity and redundancy.
IEC 61508 Route 1H allows claiming higher SILs with lower hardware fault tolerance when the Safe Failure Fraction is high enough. The Safe Failure Fraction represents the proportion of failures that are either safe failures or dangerous failures detected by diagnostics. Systems with high diagnostic coverage can detect most dangerous failures quickly enough to take safety action, compensating for lower redundancy. However, this route requires extensive analysis and justification of the diagnostic coverage claims.
IEC 61508 Route 2H specifies minimum hardware fault tolerance requirements based on the target SIL. This route is more prescriptive, requiring specific architectural features regardless of calculated reliability metrics. Route 2H is often considered more straightforward to apply because it avoids debates about diagnostic coverage calculations, but it may require more complex architectures than Route 1H would permit for the same SIL.
Sector-specific standards may modify or elaborate on these architectural constraints. ISO 26262 for automotive applications uses a different approach based on ASIL decomposition and hardware metrics. IEC 62061 for machinery safety defines subsystem architectures with associated PFH (probability of dangerous failure per hour) limits. Understanding the specific architectural constraints in the applicable standards is essential for selecting appropriate system architectures.
Diagnostic Coverage Requirements
Understanding Diagnostic Coverage
Diagnostic coverage (DC) measures the effectiveness of diagnostics in detecting dangerous failures before they can cause a hazardous event. High diagnostic coverage enables rapid detection of failures, limiting the time during which a fault can accumulate undetected and allowing prompt corrective action. Diagnostic coverage is a key parameter in functional safety calculations and influences both the achievable safety integrity and the required proof test interval.
Diagnostic coverage is defined as the ratio of dangerous failures that are detected by diagnostics to the total dangerous failure rate. A DC of 90% means that diagnostics detect 90% of dangerous failures, leaving 10% undetected until the next proof test. The undetected failures accumulate over time, increasing the probability that the system is in a failed state. Higher diagnostic coverage reduces this accumulation rate, enabling longer intervals between proof tests while maintaining the required probability of failure on demand.
Functional safety standards define categories of diagnostic coverage. IEC 61508 defines low DC as 60% to 90%, medium DC as 90% to 99%, and high DC as 99% or greater. These categories are used in determining the achievable SIL under the architectural constraints. Achieving high diagnostic coverage requires comprehensive diagnostics that test all significant failure modes of safety-related components.
The diagnostic test interval is the time between successive diagnostic tests. Shorter intervals provide faster detection of failures but may impact system performance and availability. The interval must be short enough that a dangerous failure is likely to be detected before a demand on the safety function occurs. For continuous demand applications, diagnostics may need to run continuously or at very short intervals. For low demand applications, longer intervals may be acceptable if the demand rate is correspondingly low.
Diagnostic Techniques
Self-test diagnostics use the system's own processing capabilities to test its components without external equipment. Microprocessors can execute instruction set tests, memory tests, and register tests. Analog circuits can be tested by applying known stimuli and verifying expected responses. Self-tests are convenient because they require no external equipment and can be performed during operation, but they may not detect all failure modes, particularly those affecting the test mechanisms themselves.
Comparison diagnostics detect failures by comparing the outputs of redundant elements. Dual-channel architectures can compare processing results, sensor readings, or output commands. Discrepancies indicate that at least one channel has failed, triggering fault handling actions. Comparison diagnostics are highly effective for detecting random failures but may not detect systematic failures that affect both channels identically. The comparison mechanism itself must be designed to avoid single points of failure that could mask discrepancies.
Watchdog timers detect software execution failures by requiring periodic communication from the monitored processor. If the processor fails to communicate within the required interval, the watchdog takes safety action, typically resetting the processor or activating outputs to a safe state. Simple watchdogs only detect complete processor failure or code execution that fails to reach the watchdog update point. More sophisticated watchdogs require specific communication patterns or cryptographic tokens, providing better coverage of software execution errors.
Output monitoring verifies that actuator commands are correctly executed by sensing the actual output state. Valve position sensors verify that commanded valve positions are achieved. Current monitoring verifies that output drivers are functioning. This monitoring detects failures in the output path that comparison of redundant processing channels would not reveal. Output monitoring is particularly important because output failures directly affect the ability to achieve the safe state.
Diagnostic Coverage Calculation
Calculating diagnostic coverage requires systematic analysis of failure modes and the diagnostic tests that detect them. For each component in the safety function, the analysis identifies possible failure modes, categorizes them as safe or dangerous, estimates their failure rates, and determines which diagnostics detect each failure mode. The diagnostic coverage is then calculated as the sum of detected dangerous failure rates divided by the total dangerous failure rate.
Failure Modes, Effects, and Diagnostic Analysis (FMEDA) is the standard method for calculating diagnostic coverage. FMEDA extends traditional FMEA by adding analysis of diagnostic detection for each failure mode. For each failure mode, the analyst records the failure rate (typically from component databases), the failure mode category (safe, dangerous detected, dangerous undetected), and the diagnostic that detects it if applicable. Summing across all failure modes yields the total failure rates and the diagnostic coverage.
Functional safety standards and industry publications provide typical diagnostic coverage values for common diagnostic techniques. These published values can be used when detailed FMEDA is not practical, but they should be applied with caution. The actual diagnostic coverage depends on the specific implementation and the specific failure modes of the components used. Published values represent typical achievable coverage under favorable conditions; actual coverage in a specific implementation may be lower.
Validation of diagnostic coverage claims requires testing that demonstrates the diagnostics actually detect the failure modes they are claimed to detect. Fault injection testing simulates failures by introducing faults into the system and verifying that diagnostics detect them correctly. This testing should cover representative samples of the failure modes included in the FMEDA. Fault injection can be performed at various levels, from simulation of component failures to physical injection of faults in prototype hardware.
Common Cause Failure Analysis
Understanding Common Cause Failures
Common cause failures (CCF) are failures of multiple elements that result from a single cause or shared vulnerability. These failures are particularly dangerous in redundant systems because they can defeat the fault tolerance that the redundancy is intended to provide. A redundant system that would easily survive random independent failures of its elements may fail when a common cause simultaneously affects all elements. Effective functional safety implementation must identify and manage common cause vulnerabilities.
Common cause failures can arise from many sources. Shared physical environment can cause multiple elements to fail from common stresses such as temperature extremes, humidity, vibration, or electromagnetic interference. Shared manufacturing processes can introduce systematic defects that manifest as simultaneous failures when stressed. Shared design errors affect all elements based on that design. Shared maintenance procedures can introduce errors that affect multiple elements. Shared operating procedures can lead to common human errors affecting redundant channels.
The probability of common cause failure is characterized by the beta factor, which represents the fraction of failures that affect multiple redundant elements simultaneously. A beta factor of 0.1 (10%) means that one-tenth of failures are common cause failures affecting all redundant elements. Typical beta factors range from 1% to 10% depending on the degree of diversity and separation between redundant elements. Lower beta factors indicate better protection against common cause failures.
In reliability calculations for redundant systems, the common cause failure contribution often dominates the total probability of failure. Consider a dual redundant system where each channel has a failure probability of 0.01 (1%). If failures were independent, the probability of both failing would be 0.0001 (0.01%). But with a beta factor of 0.1, the probability of common cause failure of both channels is 0.001 (0.1%), ten times higher than the independent failure contribution. This example illustrates why common cause analysis is essential for redundant systems.
Common Cause Defense Measures
Diversity is the primary defense against common cause failures. By making redundant elements different, the likelihood that a single cause can fail all elements simultaneously is reduced. Diversity can be implemented at multiple levels: component diversity uses different component types or manufacturers; design diversity uses different implementation approaches; functional diversity uses different methods to achieve the same goal; and software diversity uses independently developed software. Each type of diversity addresses different categories of common cause.
Physical separation reduces the probability that environmental stresses affect multiple redundant elements. Separating channels in different enclosures, different rooms, or different buildings reduces their exposure to localized physical threats such as fire, flooding, or physical damage. Electrical separation through isolated power supplies and signal paths prevents faults from propagating between channels. Separation requirements should be based on analysis of the physical threats relevant to the installation environment.
Independent design and development for redundant elements helps prevent systematic design errors from affecting multiple channels. When different teams develop different channels without sharing designs, they are less likely to make the same errors. However, truly independent development is expensive and may be impractical for all but the highest integrity applications. Partial independence, such as using different development tools or different design reviews, provides some benefit with lower cost.
Defensive measures against human error common causes include independent verification of maintenance and operational activities, physical interlocks that prevent simultaneous access to redundant elements, and procedural controls that separate work on different channels in time. Training and awareness programs help personnel understand the importance of maintaining independence between redundant elements. Audit and monitoring activities verify that independence is actually maintained in practice.
Beta Factor Calculation
Quantifying common cause vulnerability requires estimating the beta factor based on the defensive measures implemented. Several methods exist for this estimation. The IEC 61508 beta factor calculation uses a checklist approach where points are assigned based on the presence or absence of specific defensive measures. The sum of points determines the beta factor. This method is straightforward but may not capture all relevant factors for a specific application.
The beta factor checklist in IEC 61508 considers factors including separation and segregation, diversity and redundancy, complexity and design analysis, assessment and test procedures, competence and training, environmental control, and operational testing. Each factor has associated points that are summed to yield a score. The score is then mapped to a beta factor through a defined relationship. Higher scores indicate better protection against common cause failures and lower beta factors.
Industry-specific standards may provide alternative methods for common cause quantification. ISO 26262 for automotive applications uses a different approach based on analysis of potential common cause initiators and the effectiveness of defenses against each. Process industry standards may reference other methods developed for their specific technology base. The chosen method should be appropriate for the application domain and consistent with the overall safety analysis approach.
Regardless of the quantification method used, the analysis should be documented to show the basis for the claimed beta factor. This documentation supports review and assessment activities and provides a foundation for re-evaluation when changes occur. If the implemented defensive measures differ from those assumed in the beta factor calculation, the calculation should be updated to reflect the actual implementation.
Software Safety Requirements
Software in Safety Systems
Software plays an increasingly central role in safety-related electronic systems, implementing safety functions, processing diagnostic information, and managing system configuration. The flexibility and power of software enable sophisticated safety functions that would be impractical with hardware alone. However, software also introduces unique challenges for functional safety because it does not fail randomly like hardware; software failures are systematic, resulting from design errors that may remain dormant until specific conditions trigger them.
The systematic nature of software failures means that traditional hardware reliability analysis methods do not directly apply. A software bug that causes failure will cause that failure every time the triggering conditions occur, not with some statistical probability. Redundant software copies running on redundant hardware will all fail simultaneously when the triggering conditions occur, defeating the fault tolerance of the hardware architecture. This characteristic drives the emphasis on systematic methods for software development rather than statistical reliability analysis.
Functional safety standards specify software development processes designed to minimize the probability of introducing errors and maximize the probability of detecting any errors that are introduced. These processes become more rigorous at higher Safety Integrity Levels, reflecting the greater consequences of failure. The standards do not guarantee error-free software but provide assurance that appropriate effort has been applied to achieve software quality commensurate with the criticality of the application.
The interface between software and hardware requires particular attention in safety systems. Software relies on hardware to execute correctly, while hardware behavior is controlled by software. Failures at this interface, such as memory corruption, processor exceptions, or communication errors, can have unpredictable effects on safety function behavior. The software architecture must anticipate potential hardware failures and respond appropriately, while the hardware must provide the reliability and diagnostic visibility that the software requires.
Software Development Lifecycle
The software safety lifecycle mirrors the overall safety lifecycle, with phases for specification, design, coding, testing, and maintenance. Each phase has specific requirements and produces documented outputs that feed into subsequent phases and into verification and validation activities. Rigorous adherence to the lifecycle processes is essential for achieving the systematic capability required for safety-related software.
Software safety requirements specification defines what the software must do to implement the allocated safety functions. These requirements must be traceable to the system safety requirements and must be written with sufficient clarity and completeness to guide design and enable verification. Software safety requirements include not only functional requirements but also performance requirements, interface requirements, and constraints on implementation choices. Requirements management tools and processes ensure that requirements are tracked, changes are controlled, and impacts are assessed.
Software architecture design defines the structure of the software, including the major components, their responsibilities, and their interactions. The architecture should support the required safety properties by providing appropriate isolation, error handling, and diagnostic capabilities. Architectural patterns such as partitioning, diversity, and monitoring architectures have known properties that support functional safety. The architecture design is reviewed to verify that it can implement the safety requirements and that it is suitable for the required SIL.
Detailed design and coding translate the architecture into implementable modules. Coding standards define practices that reduce the probability of introducing errors and that support analysis and testing. These standards typically restrict language features that are error-prone or that impede analysis, require specific patterns for common operations, and mandate documentation and commenting practices. Code reviews and static analysis verify compliance with coding standards and identify potential errors.
Software Verification and Testing
Software verification demonstrates that the software correctly implements its requirements. Verification activities occur throughout the development lifecycle, with different techniques applied at different levels. Unit testing verifies individual modules against their detailed specifications. Integration testing verifies interactions between modules and compliance with architecture design. System testing verifies the complete software against the software safety requirements.
Test coverage measures the thoroughness of testing by determining what portion of the software has been exercised by tests. Structural coverage measures, such as statement coverage, branch coverage, and MC/DC (Modified Condition/Decision Coverage), indicate what portions of the code have been executed during testing. Higher Safety Integrity Levels require higher coverage levels, with SIL 3 and SIL 4 typically requiring MC/DC coverage demonstrating that each condition independently affects decision outcomes.
Requirements-based testing verifies that the software meets each specified requirement. Test cases are derived from requirements, and each requirement must have associated tests that verify its implementation. Traceability between requirements and tests demonstrates completeness of testing. Negative testing verifies correct behavior when inputs are out of range, interfaces fail, or other abnormal conditions occur. Stress testing and boundary testing explore behavior at the edges of specified operating ranges.
Static analysis complements dynamic testing by examining code without executing it. Static analysis tools can detect potential errors such as uninitialized variables, buffer overflows, dead code, and violations of coding standards. Data flow analysis identifies potential problems in how data moves through the software. Control flow analysis identifies unreachable code and structural anomalies. The findings from static analysis must be reviewed and addressed, with justification documented for any findings that are determined to be acceptable.
Verification and Validation
Verification Activities
Verification answers the question "Did we build the product right?" It demonstrates that each phase of development has correctly implemented the outputs of the preceding phase. Verification is performed throughout the lifecycle, not just at the end, to catch errors as early as possible when they are easiest and least expensive to correct. Comprehensive verification activities are essential for achieving the systematic capability required for safety-related systems.
Reviews are fundamental verification activities that examine work products for correctness, completeness, and consistency. Requirements reviews verify that safety requirements are complete, unambiguous, and traceable to hazard analysis. Design reviews verify that designs correctly implement requirements and comply with relevant standards. Code reviews verify that code correctly implements designs and follows coding standards. The formality and independence of reviews should match the SIL, with higher SILs requiring more formal processes and greater reviewer independence.
Analysis uses systematic examination and calculation to verify properties that cannot be efficiently demonstrated through testing. Timing analysis verifies that the system meets its timing requirements, including response time to detected faults. Worst-case execution time analysis supports timing analysis by bounding how long software execution can take. Stack analysis verifies that memory usage remains within allocated limits. Safety analysis techniques such as FMEA and FTA verify that hazards are adequately addressed.
Testing verifies that the implemented system behaves correctly when operated. Hardware testing verifies electrical characteristics, environmental performance, and functional behavior. Software testing verifies correct execution under various conditions. Integration testing verifies interactions between components. System testing verifies the complete system against system requirements. Testing should include both normal conditions and fault conditions to verify correct behavior in the presence of detected faults.
Validation Activities
Validation answers the question "Did we build the right product?" It demonstrates that the complete system achieves its intended purpose in its intended environment. While verification focuses on internal consistency between lifecycle phases, validation focuses on external adequacy for the actual application. Validation activities confirm that the safety function actually reduces risk as intended.
Validation planning defines what must be demonstrated and how. The validation plan identifies the safety requirements to be validated, the validation methods to be used, the acceptance criteria for each requirement, and the responsibilities and schedule for validation activities. The plan should address validation in the intended operational environment or a suitable simulation of that environment. Validation planning should begin early in the lifecycle to ensure that validation needs are considered in design and that validation resources are available when needed.
Validation testing exercises the complete safety-related system in conditions representative of actual operation. This testing should include both normal operating conditions and the abnormal conditions that trigger safety function activation. Where practical, validation testing should be performed in the actual installation environment. Where this is not practical, laboratory testing should simulate the relevant aspects of the operational environment, with justification for any differences between test and operational conditions.
Customer acceptance testing may be part of validation, particularly when the safety-related system is customized for a specific installation. The customer verifies that the system meets their requirements and is suitable for their application. Installation testing verifies correct installation and integration with the equipment under control. Commissioning testing verifies correct operation in the actual installation before the system enters operational service. These activities complete the validation process and transition the system to the operational phase of its lifecycle.
Functional Safety Assessment
Functional safety assessment is an investigation, based on evidence, to judge the functional safety achieved by a safety-related system. Assessment may be performed by the developer's own personnel, by independent personnel within the developer's organization, or by an external assessment body. The independence and rigor of assessment should match the SIL, with higher SILs requiring greater assessor independence from the development team.
Assessment activities include review of safety documentation, verification of compliance with applicable standards, evaluation of safety analyses, and confirmation that verification and validation activities have been completed. The assessor examines not only whether required activities have been performed but also whether they have been performed competently and whether the results adequately support the safety claims. Assessment may identify findings that require corrective action before the system can be accepted.
Assessment planning defines the scope, depth, and timing of assessment activities. Assessment may be performed at phase gate reviews throughout the lifecycle or as a comprehensive assessment at the end of development. Ongoing assessment allows earlier identification of problems, while end-of-project assessment allows evaluation of the complete body of evidence. Many projects combine both approaches, with phase gate assessments for critical items and comprehensive final assessment.
The assessment report documents the assessor's findings and conclusions. This report provides evidence that appropriate assessment has been performed and records any conditions or limitations on the assessment conclusions. Assessment reports are typically required by regulatory authorities and may be referenced in the safety case. The report should be clear about what was assessed, what evidence was examined, and what conclusions were reached.
Safety Case Preparation
Purpose and Structure of Safety Cases
A safety case is a documented body of evidence that provides a convincing and valid argument that a system is adequately safe for a given application in a given operating environment. The safety case collects and organizes the evidence from all functional safety activities into a coherent argument that the safety requirements have been met. Regulatory authorities and customers rely on the safety case to understand and evaluate the safety of the system.
The structure of a safety case typically includes a description of the system and its operating environment, identification of the hazards and the safety functions that address them, evidence that the safety functions have been correctly implemented, and arguments linking the evidence to the safety claims. Various structuring approaches exist, including Goal Structuring Notation (GSN), which represents the argument graphically as a network of goals, strategies, and evidence.
The safety case should be proportionate to the risk. Higher-risk applications require more comprehensive evidence and more rigorous arguments. Lower-risk applications may be adequately addressed with simpler safety cases. However, even simple safety cases should clearly identify what claims are being made, what evidence supports those claims, and how the evidence demonstrates that the claims are satisfied. A thin but well-structured safety case is better than a large collection of documents without clear organization.
Safety cases evolve throughout the product lifecycle. Initial safety cases may be developed during concept development to support allocation decisions and procurement activities. Development safety cases document the evidence generated during design and implementation. Operational safety cases incorporate installation-specific information and operational experience. Each evolution of the safety case should be complete and self-contained, building on but not merely referencing earlier versions.
Evidence Collection and Management
Evidence for the safety case comes from all phases of the safety lifecycle. Requirements documents, design specifications, analysis reports, test results, assessment reports, and operational records all contribute to the body of evidence. This evidence must be collected, organized, and maintained in a way that supports both current use and long-term reference. Configuration management ensures that evidence can be correlated to specific system configurations.
The quality of evidence matters as much as its quantity. Evidence should be relevant to the claims it supports, accurate in its content, complete in its coverage, and credible in its provenance. Evidence generated by qualified personnel following defined processes carries more weight than evidence of uncertain origin. Independent evidence, such as assessments by parties not involved in development, provides additional assurance. The safety case argument should address the quality of the evidence it cites.
Traceability links evidence to the requirements and claims it supports. Comprehensive traceability enables evaluation of completeness (are all requirements supported by evidence?) and impact analysis (what evidence is affected by a change?). Traceability tools and databases help manage these relationships for complex systems. Manual traceability management is acceptable for simpler systems but becomes error-prone as complexity increases.
Evidence management throughout the operational lifecycle ensures that the safety case remains valid as the system operates and evolves. Operational records may provide evidence of reliability performance, while incident reports may identify previously unrecognized hazards. Changes to the system must be evaluated for their impact on the safety case, with new evidence generated as needed. Eventually, decommissioning activities close out the safety case with evidence that the system has been safely removed from service.
Argumentation Strategies
The argument component of a safety case links evidence to claims through a logical structure. A well-constructed argument makes explicit the reasoning by which the evidence supports the conclusion that the system is safe. Different argumentation strategies are appropriate for different types of claims and evidence. Understanding these strategies helps in constructing convincing and complete safety case arguments.
Decomposition arguments break down top-level safety claims into sub-claims that are easier to support with direct evidence. A claim that the system is safe might decompose into claims about each identified hazard being adequately controlled. Each hazard control claim might further decompose into claims about the effectiveness of the safety function and the reliability of its implementation. This decomposition continues until claims are reached that can be directly supported by available evidence.
Standards compliance arguments claim safety based on compliance with recognized standards. If an applicable standard represents accepted good practice for achieving safety, then evidence of compliance with that standard supports a claim of safety. This argument is strengthened when the standard is specifically applicable to the system type and operating environment. The argument should address any gaps between the standard's requirements and the specific application's needs.
Elimination arguments systematically identify potential causes of hazardous failure and provide evidence that each cause has been eliminated or adequately controlled. This strategy is particularly effective for demonstrating coverage; if all identified causes are addressed, then the hazard is controlled. The strength of this argument depends on the completeness of the cause identification, which should be supported by systematic analysis techniques such as fault tree analysis.
Proven-in-Use Arguments
Basis for Proven-in-Use Claims
Proven-in-use arguments claim that a component or system has demonstrated adequate safety through extended operational experience. If a product has operated in comparable applications without safety-relevant failures for a sufficient time, this operational history provides evidence of safety that complements or, in some cases, substitutes for development process evidence. Proven-in-use arguments are particularly valuable for mature products where complete development documentation may not be available.
The validity of proven-in-use arguments depends on several conditions. The operational environment must be comparable to the intended application; experience in a benign environment does not demonstrate safety in a harsh environment. The operational history must include sufficient demands on safety functions; if safety functions were rarely exercised, the experience provides little evidence about safety function reliability. The operational history must be documented reliably enough to support claims about failure-free operation or low failure rates.
Functional safety standards define specific requirements for proven-in-use claims. IEC 61508 requires evidence of operating experience including the number of items in service, the duration of service, and the number and nature of any failures. The standard provides guidance on the amount of experience needed based on the claimed Safety Integrity Level. Sector-specific standards may have additional requirements tailored to their specific application domains.
Proven-in-use evidence can support claims at different levels. Component-level claims address the reliability of individual components such as relays, sensors, or microprocessors. Subsystem-level claims address the reliability of assemblies such as safety controllers or valve assemblies. System-level claims address complete safety-related systems. Higher-level claims require that the operational experience cover the integration and interaction of lower-level elements, not just the elements in isolation.
Documenting Operational Experience
Supporting proven-in-use claims requires comprehensive documentation of operational experience. This documentation must establish the identity and configuration of the products for which experience is claimed, the operating environments and applications in which they have been used, the duration and extent of operation, and the failure history including both safety-relevant and non-safety-relevant failures.
Product identification and configuration documentation ensures that the experience applies to the specific version of the product being considered. Manufacturing changes, design revisions, and software updates can affect safety-relevant behavior. The proven-in-use claim is valid only for the specific configuration that has accumulated the operational experience. Changes from the proven configuration require evaluation to determine whether the experience remains applicable.
Operating environment documentation characterizes the conditions under which experience has been accumulated. Environmental factors such as temperature range, humidity, vibration, and electromagnetic environment should be documented. Operational factors such as duty cycle, demand rate, and maintenance practices should also be recorded. This documentation enables comparison with the intended application to determine whether the experience is applicable.
Failure history documentation records all failures that have occurred, including failures that were not safety-relevant. The nature of each failure, its root cause, and its relationship to safety functions should be analyzed. Failures that could have been safety-relevant under different circumstances are particularly important to understand. The absence of documented failures does not necessarily mean no failures occurred; the failure recording and reporting processes should be evaluated to assess the completeness of failure records.
Calculating Proven-in-Use Confidence
Statistical methods can quantify the confidence provided by proven-in-use experience. Given the number of device-hours of operation and the number of failures observed, statistical analysis can bound the failure rate with specified confidence. If no failures have been observed, the analysis provides an upper bound on the failure rate; if failures have occurred, the analysis provides an estimate and confidence interval for the failure rate.
The chi-squared distribution is commonly used for these calculations. For zero observed failures in T device-hours, an upper bound on the failure rate at confidence level C is given by a formula involving the chi-squared distribution with specific degrees of freedom. This bound decreases as operating experience increases, reflecting the increased confidence that extensive experience provides. Similar formulas apply for non-zero observed failures.
The required operating experience depends on the target Safety Integrity Level and confidence level. Higher SILs have lower target failure rates, requiring more operating experience to demonstrate compliance. IEC 61508 provides tables showing required operating experience for different SILs under various assumptions. These requirements can be substantial; demonstrating SIL 3 performance may require hundreds of millions of device-hours of failure-free operation.
Combining proven-in-use evidence with development process evidence can strengthen the overall safety argument. Development evidence addresses systematic failures through process quality, while operational evidence addresses random failures through demonstrated reliability. Together, they provide more comprehensive assurance than either alone. The safety case should explain how the different types of evidence complement each other and address any gaps or inconsistencies.
Modification Impact Analysis
Managing Change in Safety Systems
Modifications to safety-related systems require careful analysis to ensure that safety is maintained. Changes may be necessary for many reasons: correcting discovered defects, adapting to changed requirements, improving performance, or addressing obsolescence. Each change introduces the possibility of degrading safety by introducing new faults, defeating existing safety measures, or invalidating the basis for safety claims. Rigorous change management is essential for maintaining functional safety throughout the operational lifecycle.
The modification process begins with identification and documentation of the proposed change. This documentation should describe what is being changed, why the change is needed, and what the expected impact will be. The change request should identify all affected items including hardware, software, documentation, and procedures. Formal change request processes ensure that changes are tracked and that nothing is modified without appropriate authorization.
Impact analysis evaluates the effect of the proposed change on safety. This analysis considers both direct impacts on safety function behavior and indirect impacts on safety arguments, test coverage, and validation status. A change that appears minor may have significant safety implications if it affects a safety-critical path or invalidates assumptions underlying the safety case. The impact analysis should involve personnel with expertise in both the technical aspects of the change and the safety aspects of the system.
Classification of changes determines the appropriate level of review and approval. Minor changes with no safety impact may proceed through streamlined processes. Changes with potential safety impact require more thorough analysis and higher-level approval. Changes that affect Safety Integrity Level claims or significantly alter safety function behavior may require re-assessment by independent assessors. The classification criteria should be defined in advance and applied consistently.
Re-verification and Re-validation
Modifications that affect safety-related elements require re-verification to demonstrate that the change has been correctly implemented and does not introduce new faults. The extent of re-verification depends on the nature and scope of the change. Localized changes may require only re-verification of the modified element and its interfaces. Broader changes may require re-verification of larger portions of the system or even complete system re-verification.
Regression testing verifies that modifications have not adversely affected functionality that was previously verified. The test suite should include tests covering the modified functionality, the interfaces with modified elements, and a representative sample of other functionality that could potentially be affected. Complete regression testing of all functionality is often impractical for significant systems; test selection should be based on analysis of potential impact areas.
Re-validation may be required when modifications affect the system's ability to achieve its intended purpose in its operational environment. Changes to safety function behavior, performance characteristics, or operational constraints may necessitate re-validation to ensure continued adequacy for the application. Re-validation scope should be determined based on analysis of what the change affects and what validation evidence remains valid after the change.
Documentation updates must accompany modifications to maintain the currency and accuracy of safety documentation. Requirements documents, design specifications, test procedures, and the safety case all require review and potential update when modifications occur. Configuration management ensures that documentation versions align with system versions and that the current documentation accurately describes the current system configuration.
Long-term Safety Management
Maintaining functional safety throughout an extended operational life requires ongoing attention to safety management activities. Systems may operate for decades, during which technology evolves, personnel change, and organizational structures shift. Without deliberate effort to maintain safety focus, the rigorous practices established during development may gradually erode, increasing safety risk over time.
Periodic safety reviews examine whether the system continues to meet its safety requirements as conditions change. These reviews consider operational experience, including any incidents or near-misses that may indicate emerging safety concerns. They evaluate whether the assumptions underlying the safety case remain valid as the operational environment evolves. They assess whether maintenance and inspection activities continue to be performed effectively. Periodic reviews provide opportunities to identify and address safety degradation before it results in incidents.
Obsolescence management addresses the challenge of maintaining safety-related systems when components become unavailable. Electronic components have limited manufacturing lifetimes, and replacement components may not be identical to originals. Obsolescence management includes monitoring component availability, qualifying replacement components, and managing inventory of critical components. When substitutions are necessary, impact analysis ensures that the replacement maintains safety function integrity.
Knowledge management preserves the understanding necessary to maintain safety throughout the system lifecycle. As original designers and operators retire or move to other positions, their knowledge of safety-critical aspects of the system may be lost. Documentation alone may not capture all relevant knowledge, particularly the rationale behind design decisions. Systematic knowledge management through documentation, training, and mentoring helps ensure that safety-critical knowledge is preserved and transferred to successor personnel.
Conclusion
Functional safety implementation ensures that safety-critical electronic systems perform their intended functions correctly and reliably throughout their operational life. The systematic approach defined by international standards like IEC 61508 and its sector-specific derivatives provides a comprehensive framework for achieving this goal. From initial hazard analysis through design, development, validation, and ongoing operation, each phase of the safety lifecycle contributes to the overall safety argument.
Hardware fault tolerance and diagnostic coverage provide the technical foundation for safety-related system reliability. Redundant architectures enable systems to continue functioning despite component failures, while comprehensive diagnostics detect failures before they can cause hazardous events. Common cause failure analysis ensures that systematic vulnerabilities do not defeat the protection provided by redundancy. Together, these elements enable achievement of the target Safety Integrity Level.
Software safety requires particular attention because software does not fail randomly but fails systematically due to design errors. Rigorous development processes, comprehensive verification, and independent assessment provide assurance that software implements safety functions correctly. While no process can guarantee error-free software, the systematic approach provides confidence proportionate to the criticality of the application.
The safety case collects and presents the evidence that the system achieves adequate safety. Well-structured arguments link evidence to claims, demonstrating that hazards have been identified and addressed. Proven-in-use arguments leverage operational experience to supplement development evidence. The safety case evolves through the lifecycle, maintaining a current representation of the system's safety status.
Finally, effective modification management maintains safety as systems change over their operational lifetime. Impact analysis identifies potential safety effects of proposed changes. Re-verification and re-validation confirm that modifications have not degraded safety. Long-term safety management addresses obsolescence, knowledge preservation, and ongoing safety monitoring. Through these activities, functional safety is maintained from initial deployment through eventual decommissioning.