An Interference-Free component, either as an interface or a defined functional area, is a system component that is neither safety critical (C3) nor safety relevant (C2), but interfaces with such subsystems. 

If a component has been shown to be interference free (C1), then it has been demonstrated that no failure of that component can cause a failure of any of the safety functions of the product. Therefore, such a component is not subject to be developed with an IEC 61508 compliant development process. 

Independence between components is the key.  This is usually easier to show in hardware than in software due to physical separation techniques. 

Now what about those “C” numbers?  It’s just a grading system that makes it easier to discuss the distinctions.  It’s an exida term; you won’t find it in IEC 61508.

• C3 - safety critical component that is directly involved in the safety function; a single failure can result in loss of the safety function.
• C2- safety relevant component that is involved as a diagnostic function but not directly in the safety function; a single failure cannot cause a loss of the safety function… it takes at least 2 failures.
• C1 - a non-safety component that is not involved in the safety function or diagnostic functions, but may have interfaces to such functions.

Let’s talk about software for a bit. 

According to IEC 61508, all software must be considered to have the same criticality unless it can be shown that a component has no direct influence on the safety function or it cannot interfere with any component of higher criticality.  This criticality level is not directly related to the Safety Integrity Level, but it is relative to the highest SIL to be met.  All C3 software must be designed and implemented for the highest Systematic Capability you’re trying to meet.  But C2 software only needs to meet the requirements of the next lower Systematic Capability, or SC-1. 

For example, if your C3 software must meet SIL 3 Systematic Capability, your C2 software only needs to meet SIL 2.  And any C1 software is not subject to the IEC 61508 requirements. The effort needed to develop C1 software is generally less than to develop C3 and even C2 software.  This saves development time, effort, and resources.  But you can’t just apply C1 to the software without some justification.  

The key is to use a structured methodology (e.g., SW HAZOP) to do the criticality analysis.  All the software components must be identified and classified (usually at an architecture level), and then analyzed for possible and likely failure modes that affect the safety function.  This is similar to a FMEA and design review.  Once this analysis is completed, you’ll have updated classifications (because the initial classifications are rarely 100% right) and you’ll have a to-do list of improvements and changes to make the software better.  When you reduce software complexity and keep C3 code functionally separated from C2 and C1 code, it will be easier to implement and test.