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.