Typically, integrated circuits are developed to either IEC 61508 or ISO 26262. In addition, there are sometimes additional requirements in the level two and level three standards. Developing and assessment to the functional safety standards are what give the confidence that these sometimes complex integrated circuits are sufficiently safe. When IEC 61508 was written it was targeted at bespoke systems, as opposed to open market mass produced integrated circuits.
This article will review and comment on the known functional safety requirements for integrated circuits. While the article concentrates on IEC 61508 and its application in industrial sectors, much of the material is relevant to applications such as automotive, avionics, and medical.
Functional Safety
Functional safety is the part of safety that deals with confidence that a system will carry out its safety related task when required to do so. Functional safety is different from other passive forms of safety such as electrical safety, mechanical safety, or intrinsic safety.
Functional safety is an active form of safety; for example, it gives confidence that a motor will shut down quickly enough to prevent harm to an operator who opens a guard door or that a robot will operate at a reduced speed and force when a human is nearby.
Standards
The key functional safety standard is IEC 61508.1 The first revision of this standard was published in 1998 with revision two published in 2010 and work beginning in 2017 to update to revision three with a probable completion date of 2022. Since the first edition of IEC 61508 was published in 1998, the basic IEC 61508 standard has been adapted to suit fields such as automotive (ISO 26262), process control (IEC 61511), PLC (IEC 61131-6), IEC 62061(machinery), variable speed drives (IEC 61800-5-2), and many other areas. These other standards help interpret the very broad scope of IEC 61508 for these more limited fields.
Some functional safety standards such as ISO 13849 and D0-178/D0-254 have not been derived from IEC 61508. Nevertheless, anybody familiar with IEC 61508 and reading these standards would not be too surprised by the contents.
Within a safety system, it is the safety functions that perform the key functional safety activities when the system is running. A safety function defines an operation that must be carried out to achieve or maintain safety. A typical safety function contains an input subsystem, a logic subsystem, and an output subsystem. Typically, this means that a potentially unsafe state is sensed, and something makes a decision on the sensed values and, if deemed potentially hazardous, instructs an output subsystem to take the system to a defined safe state.
It is rather reserved for applications like nuclear and rail where hundreds or even thousands of people can be hurt. There are also other functional safety standards such as automotive, which uses ASIL (automotive safety integrity levels) A, B, C, and D and ISO 13849. Its performance levels a, b, c, d, and e can be mapped to the SIL 1 to SIL 3 scale.
The author is not convinced that a claim of greater than SIL 3 is possible for a single IC. However, it is noted that the tables in Annex F of IEC 61508-2:2010 show a SIL 4 column.
Requirement 3—Be Fault Tolerant
No matter how reliable the product, bad things will sometimes still happen. Fault tolerance accepts this reality and then addresses it. Fault tolerance has two main elements. One is the use of redundancy and the other is the use of diagnostics. Both accept that failures will occur no matter how good the reliability of the ICs or the development process used to develop the IC.
Redundancy can be identical or diverse, and it can be on-chip or off-chip. Annex E of IEC 61508-2:2010 offers a set of techniques to demonstrate that sufficient measures have been taken to support claims for on-chip redundancy in digital circuits using nondiverse redundancy. Annex E appears to have been targeted at dual lock-step microcontrollers and no guidance is given for on-chip independence for
Analog and mixed-signal integrated circuits
Between an item and its on-chip diagnostics
Digital circuits employing diverse redundancy
However, in some cases Annex E can be intelligently interpreted for these cases. An interesting item within Annex E is the βIC calculation, which is a measure of on-chip common cause failures. It allows a judgment of sufficient separation provided the sources of common cause failure represent a β of less than 25%, which is high in comparison to the 1%, 5%, or 10% found in the tables of IEC 61508-6:2010.
Diagnostics are an area in which integrated circuits can really shine. On-chip diagnostics can
Be designed to suit the expected failure modes of the on-chip blocks
Add no PCB space due to the limited requirement for external pins
Operate to a high rate (minimum diagnostic test interval)
Obviate the need for redundant components to implement diagnostics by comparison
This means that on-chip diagnostics can minimize the system cost and area. Generally the diagnostics are diverse (different implementation) to the item they monitor on-chip and so it is unlikely they will fail in the same way and at the same time as the item they are monitoring. When they do, it is likely that they would have the same issues (often related to EMC, power supply issues, and over temperature) even if the diagnostics were implemented in a separate chip. While the standard does not contain the requirement, there are concerns related to using on-chip power supply monitors and watchdog circuits, which are diagnostics of last resort. Some external assessors will insist on such diagnostics being off-chip.
Generally, the diagnostics on simpler integrated circuits will be controlled by a remote microcontroller/DSP with measurements done on-chip but the results shipped off-chip for processing.
IEC 61508 requires minimum levels of diagnostic coverage given as SFF (safe failure fraction), which considers safe and dangerous failures and is related but different from DC (diagnostic coverage), which neglects safe failures. The measure of success of the implemented diagnostics can be measured using a quantified FMEA or FMEDA. However, the diagnostics implemented within an IC can also cover components external to the IC and items within the IC can be covered by system-level diagnostics. When an IC developer performs the FMEDA, the assumption must be given that the IC developer doesn’t generally know the details of the final application. In ISO 26262 terminology, this is known as an SEooC (safety element out of context). For end users to make use of the IC-level FMEDA, they must satisfy themselves that the assumptions still hold for their system.
While Table A.1 (and indeed Tables A.2 to A.14) of IEC 61508-2:2010 give good guidance on the IC faults that should be considered when analyzing an IC, an even better discussion of the topic is given in Annex H of IEC 60730:2010.5
Development Options for an Integrated Circuit
There are several options for developing integrated circuits to be used in functionally safe systems. There is no requirement in the standard to only use compliant integrated circuits, but rather the requirement is that the module or system designers satisfy themselves that the chosen integrated circuit is suitable for use in their system.
The available options include
- Developing fully in compliance to IEC 61508 with an external assessment and safety manual
- Developing in compliance to IEC 61508 without external assessment and with a safety manual
- Developing to the semiconductor companies’ standard development process but publish a safety data sheet
- Developing to the semiconductor companies’ standard process
- Note—for parts not developed to IEC 61508, the safety manual may be called a safety data sheet or similar to avoid confusion with parts developed in compliance to a safety manual.
Option 1 is the most expensive option for semiconductor manufacturers, but also offers potentially the most beneficial to module or system designers. Having such a component where the application shown in the safety concept for the integrated circuits matches that of the system reduces the risk of running into problems with the external assessment of the module or system. The extra design effort for a SIL 2 safety function can be on the order of 20% or more. The extra effort would probably be higher, except that semiconductor manufacturers typically already imply a rigorous development process even without functional safety.
Option 2 saves the cost of external assessment but otherwise the impact is the same. This option can be suitable where customers are going to get the module/system externally certified anyway and the integrated circuit is a significant part of that system.
Option 3 is most suitable for already released integrated circuits where the provision of the safety data sheet can give the module or system designer access to extra information that they need for the safety design at the higher levels. This includes information such as details of the actual development process used, FIT data for the integrated circuit, details of any diagnostics, and evidence of ISO 9001 certification for the manufacturing sites.
Option 4 will, however, remain the most common way to develop integrated circuits. Use of such components to develop safety modules or systems will require additional components and expense for the module/ system design because the components will not have sufficient diagnostics requiring dual-channel architecture with comparison as opposed to single-channel architectures. Without a safety data sheet, the module/ system designer will also need to make conservative assumptions and treat the integrated circuit as a black box.
In addition, semiconductor companies need to develop their own interpretations of the standards and the author’s own company has developed internal documents ADI61508 and ADI26262 for this purpose. ADI61508 takes the seven parts of IEC 61508:2010 and interprets the requirements in terms of an integrated circuit development.
A SIL 2/3 Development
Sometimes an integrated circuit can be developed to all the systematic requirements per SIL 3. This means all of the relevant items from table F.1 of IEC 61508-2:2010 for SIL 3 are observed and that all of the design reviews and other analyses are done to a SIL 3 level. However, the hardware metrics may only be good enough for SIL 2. Such a circuit could be identified as a SIL 2/3 or more typically SIL M/N, where the M represents the maximum SIL level that can be claimed in terms of the hardware metrics and the N the maximum SIL level that can be claimed in terms of the systematic requirements. Two SIL 2/3 integrated circuits can be used to implement a SIL 3 module or system because having two SIL 2 items in parallel upgrades the combination to SIL 3 in terms of hardware metrics, but each item is already at SIL 3 in terms of the systematic requirements. If instead the integrated circuits were only SIL 2/2, putting two such integrated circuits in parallel would still not make it SIL 3 as it would be SIL 3/2 at the best.
Applying the Hardware Metrics to an Integrated Circuit
Except in cases where almost the entire safety function is implemented by an integrated circuit, it is very hard to specify SFF, DC, or PFH limits to a semiconductor. Taking SFF as an example, while the SFF is required to be greater than 99% for SIL 3, this applies to the entire safety function rather than the integrated circuit. If the integrated circuit comes in at 98%, it can still be used to implement a SIL 3 safety function, but other parts of the system will need to achieve a higher coverage to compensate. The safety manual or safety data sheet for the integrated circuit needs to publish the λDD, λDU, and λ for use in the system-level FMEDA.
Ideally, the IC requirements would be derived for a system-level analysis, but often this is not the case and the development is effectively an SEooC (see ISO 26262) or a safety element out of context. In the case of an SEooC, the IC developer needs to make assumptions about how the IC will be used in systems. The system or module designer must then compare these assumptions to their real system to see if the functional safety of the IC is sufficient for their system. These assumptions can decide whether a diagnostic is implemented on the IC or at the system level and so impact on IC-level features and capabilities.
Security
A system cannot be safe unless it is also secure. Presently the only guidance in IEC 61508 or ISO 26262 related to security is to refer the reader to the IEC 62443 series.6 However, IEC 62443 appears to be more targeted at larger components, such as entire PLC components, rather than to individual ICs. The good news is that most of the requirements in the functional safety standards to eliminate systematic faults also apply to security. The lack of any references is interesting because, in some cases, hardware can supply a hardware root of trust and features like a PUF (physically unclonable function), which is important for safety and security.
Conclusions
The existing IEC 61508 covers everything from developing an integrated circuit to an oil refinery. While there are dedicated sector specific standards for such areas as machinery and process control, and, while there is some guidance in IEC 61508 revision two for integrated circuits, there is no standard specific to integrated circuits. The lack of specific requirements leaves the requirements open to interpretation and therefore conflicts can arise between the expectations of multiple customers and external assessors.
This means that sectors will be inclined to make sector specific requirements for integrated circuits in their higher level standards. Such requirements can already be seen in standards such as EN 50402,7 but most especially in the 2016 draft of ISO 26262,8 where a new part, part 11, deals specifically with integrated circuits.
It is the author’s hope that revision 3 of IEC 61508, due to be published sometime around 2021, will expand and clarify the guidance on integrated circuits. The author is lucky to be part of IEC TC65/SC65A MT61508-1/2 and MT 61508-3, and so will, therefore, get a chance to participate in such endeavors. Perhaps a future revision might have a part 8 dedicated just to semiconductors so that there is consistency across the sectors, allowing integrated circuits to be developed that meet the requirements of all the sectors.
Even then it is unlikely that the standard will contain everything that an IC manufacturer needs to design an IC with functional safety requirements. Requirements related to security, EMC, etc., will still need to be derived from systems application knowledge.
