Architectural constraints are limitations that are imposed on the hardware selected to implement a safety-instrumented function, regardless of the performance calculated for a subsystem. Architectural constraints are specified (in) according to the required of the subsystem, type of components used, and of the subsystem’s components. (Type A components are simple devices not incorporating microprocessors, and Type B devices are complex devices such as those incorporating microprocessors.)

So, what does that actually mean? There are tables in the standards that puts a limit on how much risk you can say each subsystem reduces. Architectural constraints will prevent people from claiming that 7 orders of magnitude of risk have been removed by only 1 set of equipment, or subsystem. The tables will make mandatory redundancy for higher SIL ratings. 

The Architectural Constraints for the product is achieved when Failure mode effects and diagnostic analysis (FMEDA) evaluates the product through the rules of Route 1H or Route 2H. 

IEC 61508 enables users to take credit for good safety engineering practices, i.e. SIF level diagnostics, through Route 1H, and IEC 61508-2010 also provides for the alternative, ROUTE 2H, if data quality can be shown. Route 1H involves calculating the Safe Failure Fraction for the element, while Route 2H will evaluate the products history.  A valve is typically one component of the final element of a safety instrumented function (SIF).

The Architectural Constraints for each device is listed on its certification. You will see for example:

This little piece of the certificate has a lot of information. It lets us know that this product is a Type A device, (simple mechanical valve), and its Architectural constraints were evaluated through 2H, and the 2H tables from the standard must be used to determine the SIF’s redundancy. 

Fun facts:

  • Architectural constraints puts a limit on redundancy in a SIF
  • The architectural constraints of a product is one of the 3 design barriers that must be met for certification. 
  • Is a limiting factor in SIL. So if your architectural constraints meets a SIL 2, it can only go into a SIL 2 SIF or lower (SIL 1 or no SIL). It cannot be a part of SIL 3 SIF.
  • Architectural constraints protect against bad failure data, unrealistic proof test intervals and unrealistic parameter estimates in the PFDavg/PFH calculation
  • Applies to each “element” separately.  (An element is commonly defined as a subsystem, ex. A final element assembly) 
  • Must be met from one of the several charts in either IEC 6158 or IEC 61511.

If you wish to see if a product is certified, and what its architectural constraints are, you can search on the SAEL.

Related Items

Back to Basics 01 - Functional Safety

Back to Basics 02 - Safety Integrity Level (SIL)

Back to Basics 03 - Safety Instrumented Function (SIF)

Back to Basics 04 - Safety Instrumented System (SIS)

Back to Basics 05 - What is a Safety Function?

Back to Basics 06 – IEC 61508

Back to Basics 07– Safety Lifecycle – IEC 61508

Back to Basics 08 – IEC 61511

Back to Basics 09 – Safety Lifecycle – IEC 61511

Back to Basics 10 – How Does a Product Get a SIL?

Back to Basics 11 – How is SIL Used by an End User?

Back to Basics 12 – What is IEC 61508 Certification?

Back to Basics 13 - How Do I Start IEC 61508 Certification?

Back to Basics 14 - Systematic Capability

Tagged as:     SIF     Route 1H     Loren Stewart     IEC 61508     FMEDA     back to basics     Architectural Constraints  

Other Blog Posts By Loren Stewart