Is Functional Safety of Software Relevant in Practice?
In recent years, the use of electronic, programmable systems for functional safety has emerged as a trend in various industries. In the future, it is expected that there will be an even higher tendency to use purely software-based solutions for safety-related functionality.
In the last few decades, functional safety was relevant only for hardware. Safety-related functionality revolved around using reliable components and/or reliable hardware architectures. Functional safety requirements used to be listed only in the respective product safety standards and various other safety group standards.
New Focus: Safety-related Software
The ongoing evolution of electronic components allows them to be increasingly flexible and programmable. Safety-related software is being increasingly used in sectors such as automotive, machinery, process industry, household and similar applications, rolling stock/railway and aerospace. As a consequence, the requirements for these systems have been steadily increasing and relevant authorities around the world have released various standards covering the functional safety of software.
Requirements, designed to avoid systematic failures during development and production, are not only related to hardware, but also to software, thus making software quality requirements an intrinsic part of new safety standards.
Diverse Software RequirementsDepending on the relevant Safety Integrity Level (SIL) or software class, new requirements may be stringent; for example, for characteristics of microprocessors and embedded software in household and similar applications or as in other industry sectors, they may allow a certain degree of freedom, depending on the chosen programming language and tooling.
Software requirements in safety-related standards include: Functional safety management Functional safety planning (including validation) Specification of safety-related software requirements Selection of appropriate software tools (compilers, test environment) Documentation of testing (including results) Independent software assessment and certification How to Navigate Through the Standards Standards initiatives like Automotive Open System Architecture (AUTOSAR) are meant to increase software quality and to harmonize interfaces between software components delivered by different sub-contractors. These initiatives define “non safety-related requirements” for the software, and the “safety-related requirements” have to be considered in addition to these. Some industry sectors already use high-level standardized processes, e.g. Capability Maturity Model Integration (CMMI) or Software Process Improvement and Capability Determination (SPICE), in combination with respective safety standards.
The multitude of standards and standardized processes make it hard for both first time and experienced users to find the right path through the various functional safety requirements. The SGS Center for Quality Engineering, an accredited assessment center with qualifications in the fields of protocol testing and functional safety of software, can help ensure compliance with the standards and requirements. SGS CQE also offers reliability calculation services.
For more information, please contact:
Gudrun Neumann SGS Senior Qualification Engineer
Functional Safety of Software, SGS CQE
t: +49 89 787475 216
Email SGS CQE Web: www.ee.sgs.com The SGS Group is the global leader and innovator in inspection, verification, testing and certification services. Founded in 1878, SGS is recognized as the global benchmark in quality and integrity. With more than 56,000 employees, SGS operates a network of over 1,000 offices and laboratories around the world.