General

In the last 10 years, the term “Functional Safety” has found its way into many development departments. This goes along with the increasing popularity of electronic systems. For mechanical devices and systems, there are decades of experience, how to design and build it, so that there is no danger for the user and the environment because of the function of these systems and devices. For example, there are provisions, which mechanical protection devices must be installed, so that an operator of a saw can’t push his fingers into the blade.

The dangers that may result from the function of electronic systems are usually not immediately to see and recognize. Nevertheless, they are naturally present.

With the increasing use of software for example in: cars, airplanes, trains, medical technology or industrial automation technology, it became obvious that rules had to be created to minimize the hazards that could result from the operation of such systems.

Therefore, standards have been created such as ISO26262 or they have practiced a significant progression like IEC61508. In the field of engineering in Germany there is a tight coupling between the standards of functional safety and product liability law. According to this law, every product manufacturer is liable for the safety of the system he places on the market.

For products with a high portion of programmable electronic systems the essential aspect is, the adequately consideration of all aspects of functional safety. In some industries, such as rail or aviation, the correct implementation of functional safety is even a part of the approval process, which is required to place the system on the market.

How is “Functional Safety” defined?

If you split a classic embedded system in the 4 main components like: housing, software, hardware and mechanics, it comes to the first containment. Functional safety only considers the software and hardware part. The IEC61508 uses the term electrical, electronic and programmable electronic systems. But it is quite possible and common, that there several software and hardware systems are part of a functional safety assessment. An example is the car. It contains multiple electronic and programmable electronic systems. Therefore a holistically Functional Safety assessment is done. The goal of all functional considerations is to start form the highest system level. Subsystems are mainly considered because it is methodologically and technically not possible to judge all the necessary aspects on the highest system level.

The term “functional” defines a further restriction. The danger is considered, that might arise from the functions of a system. The function is the starting point of all considerations. The term “safety” further clarifies the topic. Security aspects are not part of functional safety considerations. All aspects which could arise from a conscious, malicious attack from outside (Security) on the system, are not part of functional safety. However, as a lot of embedded Systems are today already connected to the Internet, Security will play an increasing role in future.

Standards

Because functional safety is a fairly complex issue, there was an early desire to standardize the requirements arising in the development and operation of such systems by standards. Therefore, the Edition 1 of IEC61508 was already created about 20 years ago. With this standard, a procedure was established, which should apply to all industries which has no independent standard for functional safety.

Therefore IEC 61508 often is more general and doesn’t cover the specific requirements of individual industries ideal. In the meantime, however, almost all industries in which software / hardware systems play an important role in safety-critical systems have their own standards. These standards are based on the IEC 61508:

1. Automotive (ISO 26262)
2. Railway (EN 5012x)
3. Medical (IEC 62304)
4. Agricultural Machinery (ISO 25119)
5. Nuclear power (IEC 61513)
6. Mechanical engineering (ISO 13849)
7. etc.

An exception is the aerospace industry. These standards (RTCA DO 178 C, DO 254, ARP ARP 4754 and 4761) have been developed in depended of IEC 61508. In aerospace systems software and hardware systems have a central role in achieving safety for a long time. The standard RTCA DO 178, in particular responsible for the software, is even older than the first edition of IEC 61508

All functional safety standards have in common, that they define practices, procedures and measures for the development and operation of electrical and electronic such as programmable electronic systems. The starting point is always a risk- and hazard analysis to determine the level of criticality of the system. Most standards set 4-5 levels of criticality. The applicable procedures and measures in each phase of the development are determined by the level of criticality. Furthermore, almost all standards in common is that considerations of hardware, software, and the resulting system will be made.

The major lifecycle phases which are considered are:

1. Planning
2. Specification
3. Architecture / Design
4. Implementation
5. Verification

Conclusion

In summary it can be stated: Functional safety is concerned with all the risks that can arise from the use of the functionality of hardware / software systems. There are standards, mostly industry-specific, which set practices, procedures and measures to achieve functional safety. Everybody who places a product on the market which includes electronic hardware and/or software should know the standards, because he can be held liable in case of damage, if he ignores the standards.

Related HEICON Blog posts

• Good safety development process – What is it?
• Functional safety and pragmatism is that possible?
• Functional Safety Basic Standard IEC 61508
• RTCA DO 178C – Software quality in aerospace!
• EN 50128 Functional Safety in the railway industry
• ISO 25119 Software Development for Tractors and Machinery for agriculture and forestry
• ISO 13849 Safety of machinery – Software development

Are you ready for a functional safety workshop, to analyse improvement potentials in your development process, then send a mail to: info[at]heicon-ulm.de or call +49 (0) 7353 981 781.