A Functional Safety Development Process Example

White Paper
exida
80 N. Main St.
Sellersville, PA
[Link]

Revision 1.1
August 2025

exida White Paper Library

[Link]

Copyright [Link] L.L.C. 2025

 excellence in dependable automation

Abstract
This paper describes an example new product development process designed to meet
requirements of IEC 61508:2010 [1], the Basic Safety Standard for Functional Safety with a
Systematic Capability Level 3 (SC 3). The example was done in the context of a microcomputer-
based product which includes hardware and software done with a Full Variability Language (FVL)
like C, C++, etc. This development process is meant to provide an example of well accepted
design procedures used to create quality designs. Requirements of IEC 61508 and most
functional safety standards were written to achieve this high-quality goal.

These design procedures have been shown to be quite effective in reducing design faults as they
are based on the principles of established quality systems [2] and software engineering [3,4].
Therefore, many companies follow a similar development process for all development work, not
just devices that used in critical / safety systems. A similar development process (or equivalent)
can achieve Functional Safety Certification [5].

We believe that most of the tasks shown in this example are already well known to those who
have created a quality development process. But perhaps there are good ideas to be added that
members of various functional safety standard teams have contributed to our current functional
safety standards.

An Introduction to Functional Safety

Functional Safety is a term that describes a set of requirements and a philosophy. At exida we
have interpreted the requirements of IEC 61508 to simply mean that we must strive to create
procedures and designs to achieve reliable systems that work properly or fail in a predictable
manner. The scope of Functional Safety includes all devices (electrical, electronic,
programmable-electronic, and mechanical) used in a system that provide automatic safety
protection and all system level design procedures from risk analysis to operations and
maintenance.

Probabilistic failure performance analysis is a fundamental concept in the IEC 61508 family of
functional safety standards. Four, quantitative, order of magnitude levels (Table 1) called safety
integrity levels (SIL) are defined. In the design process for end user custom projects (bespoke
systems), quantitative failure targets are established based on risk reduction needed by each
identified hazard (a potentially dangerous condition). System designers choose equipment and
define test procedures following the safety manuals of the equipment. Then failure probability
calculations are performed on any given set of equipment used protect against an identified
hazard. The calculation output is used to verify that each safety function design meets its target
risk reduction [6]. This performance-based approach allows the standard to avoid prescriptive
design rules that often become obsolete soon after they are published.

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 2
 excellence in dependable automation

Table 1. Safety Integrity Levels

Functional Safety Certification

There are independent organizations performing third party functional safety assessments to
certify systems / products / components as compliant at specific levels of SIL capability. Such
independent organizations are called a Certification Body when accredited by a national
Accreditation Body (Figure 1). In the United States, ANAB (ANSI National Accreditation Body) is
the Accreditation Body. In the Federal Republic of Germany, the Deutsche Akkreditierungsstelle
(DAkkS) is the national Accreditation Body. Accreditation is awarded when a company passes a
detailed multi-day audit where requirements of the referenced product certification standard
are successfully met. Accreditation Bodies that are members of the International Accreditation
Forum (IAF) provide Certification Bodies with global certificate acceptance based on the IAF
Multilateral Recognition Arrangement.

Figure 1. exida Accreditation Certificate.

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 3
 excellence in dependable automation

Development Process Overview

Design engineering processes are defined with objectives to reduce design errors. This results in:
A. Lower design/development cost as rework is reduced,
B. Shorter Time to Market (reduced re-work),
C. And better compliance with market / product requirements.
Most processes define a series of activities to be taken along with the input documents required
to perform each activity, output documents created during the activity, and needed verification
steps as shown in Figure 2.

Figure 2. General Construction of a Development Process

Release to
Hazard and Production
Risk Analysis
HARA)

Validation
Project Product
Testing
Planning Specification

System
Architecture Integration
Design Testing

Hardware Software
Architecture Architecture Integration
Design Design Testing

Hardware Software
Implementation Implementation Unit Testing

Figure 3. Overview of the Development Process

Figure 3 shows an example development process in the classical V-model. However, a real
project does not just flow from step to step as shown. Development evolves during the natural,
hierarchical, iterative refinement process commonly used. Many cycles may be present (some
shown with dotted lines). One objective of the verification steps is to reduce the number of
cycles (rework).

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 4
 excellence in dependable automation

Testing steps are on the right side of the drawing. Unit testing is focused on detail sections of
the implementation to verify that each “unit” performs its intended function. Thus, test plans
are made by understanding the functionality of each unit in isolation.

Integration testing is done to verify that each unit correctly provides the output(s) needed by
connected units. Integration test planning requires a knowledge of each unit functionality and
unit inter-connectivity. Integration test objectives are typically defined and documented during
the architecture design review (DFMEA/DDMA) when clear knowledge of unit functionality and
inter-connectivity is presented.

Validation testing is done specifically to verify product specification requirements. That may be
done via testing, inspection, or analysis. Validation test planning requires a detailed knowledge
of the product requirements. Validation test objectives are created and documented during the
requirements review.

Figure 4 shows the example development process in more detail including some of the
important design verification activities outlined in bold/red.
Hazard and Risk
Analysis (specific
application)
New Product Idea
Create and Review Create Validation
Market Requirements Requirements Review
System Requirements Test Objectives

Create Functional Create Configuration

Safety Management Management Plan
Plan Create System
Architecture Design System Architecture Configuration
Functional Safety
Review Management Plan
Management Plan
Review Review
Safety Concept Audit
Development Tool
Justification
Report(s) * Done for complex
System Architecture designs and new
DFMEA / DDMA* technology

Allocate
Functions to
Hardware and
Software Create Hardware Hardware Create Software
Architecture Architecture Review Architecture

Perform Hardware Software

DFMEA/DDMA Perform Software Architecture Review
DFMEA / DDMA

Updated Create Updated Update Validation

Requirements Review Safety Requirements Test Plan
Create Integration Integration Test Plan
Test Plan Review
Validation Test Plan
Detailed Hardware Create Detailed Review
Design Review Hardware Design
Write Software Code
Software Code
Perform Component Review
FMEDA Perform Static Source
Create Safety Manual Safety Manual Review Code Analysis
Perform Fault
Injection Testing
Unit Test Code

Perform Integration
Perform Final Testing Perform Validation
Verification Testing
Release to Production

Figure 4. Detail View of the Development Process

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 5
 excellence in dependable automation

Table 2 shows a list of possible documents depending on the complexity of the project. Often,
multiple documents can be merged into one.

Table 2. Potential Document List

Phase Number Description Typical Source
Planning D1.1 FSM-plan – Functional Safety Management Plan Template
D1.2 Review Minutes/Checklist (done for all work products) Template
D1.3 Development Tool Justification Report(s) Template
D1.4 Configuration Management Plan Template
Requirements D2.1 Hazard & Risk Analysis Report (specific applications only) Design Tool
D2.2 Market Specification – Defines customer and commercial goals Company Specific
System requirement specifications – System/Device/Product specific
D2.3A*
requirements based on customer and commercial goals. Requirements Tool
Safety requirements spec. – Documents safety functions and safety
D2.3B*
integrity requirements Requirements Tool
D2.4 Safety Manual Template
Validation Planning D3.1 Validation Test Objectives / Test Plan Requirements Tool
D3.2 Traceability report - requirements to validation tests Requirements Tool
Architecture Design description - a (multi-level) drawing showing all
D4.1
Architecture Design architecture blocks with functions for each block and interface context Design Tool
D4.2 System Architecture (Safety Concept) Review Report/Minutes Template
D4.3 System-DFMEA/DDMA (when required for complex systems) Design Tool
D4.4 Forward and backward traceability report - requirements / architecture Design Tool
D4.5 Integration Test Objectives / Plan Design Tool
Hardware Design D5.1 Circuit diagrams/descriptions as needed Design Tool
D5.2 HDL Source Code Design Tool
D5.3 Layouts, part lists Design Tool
D5.4 FMEDA Report Design Tool
D5.5 Fault insertion test specificaton/results Template/Tool
D5.6 Communications Analysis (if relevant) Template
D6.1 ASIC Architecture Description - Functions and Self-test plan Design Tool
D6.2 HDL Inspection Report Template
D6.3 Design Rule Check Results Design Tool
Software Design D7.1 Source Code - design description and comments Design Tool
D7.2 Static Analysis Results Design Tool
D7.3 Unit Test Plans/Results Design Tool
Integration D4.5A Integration Test Plan/Report Design Tool
Validation D3.1A Safety Validation Test Plan / Report Design Tool
D3.3 Environmental Stress and EMC / EMI Test report Test Lab Report
Production Release D9.1 Production Release Authorization Company Specific
D9.2 Archive Production Configuration Documentation Company Specific
Lifetime Maintenance D10.1 Field Failure Records Company Specific
D10.2 Root Cause Analysis Reports Company Specific
D10.3 Engineering Change Requests Company Specific
D10.4 Impact Analysis Reports Company Specific
D10.5 Change Control Board Approvals Company Specific
D10.6 Updated Production Configuration Documentation Company Specific

Project Planning
A project plan commonly contains rough estimates of cost, staff requirements, skills needed,
development tool requirements, and schedule. Functional Safety standards do not require much
beyond the common items. The name of the project plan is the “Functional Safety Management
(FSM)” plan. A few items specific to functional safety are identified. Figure 5 shows an example

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 6
 excellence in dependable automation

planning process with input and output documents. Note that verification tasks and verification
output documents are outlined in red.

FSM Plan Template

Create Functional
Safety Management FSM Plan
Plan D1.1
Policies / Procedures
Configuration
Management Plan
D1.4
Functional Safety
Management Plan Review Minutes
Review D1.2

Development Tool Tool Justification

Justification Reports
Report(s) D1.3

Figure 5. Detail Tasks in the Project Planning Process

The items contained in a FSM plan include details about the procedures that will be used in
development (typically by referencing the development procedures), design tools to be used,
documentation formats / templates to be used, document control method, input/output
documents, and responsible personnel / competency. Once the plan has been created it is
reviewed and documented with minutes of the review meeting. Justification of all design tools
used on the project is needed. Design tool justification is done to make certain all those using
any tool understand how the tool works including what can go wrong.

Product Requirements
Figure 6 shows an example of product requirements tasks. The requirements come from
marketing goals and commercial goals which is quite normal. Note that a Hazard and Risk
Analysis (HARA) is done when a device is developed for a specific application where hazards can
be identified. For example, if an embedded micro-computer device is designed to charge a
specific type battery, the hazards in that process can be identified and the corresponding safety
functions can be defined. The HARA output will define the risk reduction requirement for each
safety function.

Hazard and Risk

Analysis Report System Requirements
D2.1 Create System
Requirements Specification
Market Requirements D2.3
Commercial Goals
D2.2
Requirements Review Review Minutes
D1.2

System Requirements Create Draft Safety Safety Manual

Specification Manual
D2.3 D2.4

Figure 6. Detail Tasks in the Requirements Creation Process

When a device is designed for many applications, the HARA is done by the system designer not
the device designers. For example, a general-purpose programmable logic controller (PLC) will

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 7
 excellence in dependable automation

be used in many applications where hazards for each application cannot be known in advance.
In that case risk reduction capabilities for the device are a market requirement and must be
published in the device datasheet. The system designer checks the datasheet to make sure the
device capability meets system risk reduction needs.

Requirements are typically organized in a hierarchal manner as shown in the tree structure of
Figure 7.

Figure 7. Example Requirements Categories from the REQx Tool

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 8
 excellence in dependable automation

A requirements management tool is commonly used. The benefits of requirements

management include:
• Tracking of the relationship between hierarchical requirements,
• Explanation of the rational for each requirement,
• Tracking of the relationship between requirements and validation tests, and
• Tracking of the relationship between requirements and design implementation.
Any requirements management tool used in a functional safety qualified process should have
the capability to do the tracking between requirements, testing, and software design. IEC 61508
does not require tracking of requirements to the hardware implementation but design
implementation tracking can be very useful when changes are required during the process. The
impacted design units can be quickly identified.

Safety Manual
An essential document for functional safety is called the “Safety Manual.” A template is often
used as this document must contain all information needed for the user of a device to maintain
safety. The Safety Manual can be started when requirements are complete as some of the
needed contents may be defined in the requirements. The Safety Manual will be
expanded/updated during the development process and certainly is not expected to be
complete until validation testing is ready to begin.

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 9
 excellence in dependable automation

Validation Test Planning

Validation test planning is done after requirements are created. This is done to find out if
requirements can be "tested." Validation methods include a test, an inspection, or an analysis.
At this point in a project it is not the intent to create a full, detailed validation test plan. For each
requirement, document a test objective. Figure 8 shows the test objective editor from the OEMx
tool. The entry fields show the extent of the needed information for a test objective. This is
expended into a full test plan later where details such as the test procedure, test equipment
used, date, personnel performing the test and test results are added.

Figure 8. Test Objective Editor example from OEMx

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 10
 excellence in dependable automation

Figure 9 shows the detailed steps in validation test planning.

System Requirements Create Validation Validation Test

Specification Test Objectives Objectives
D2.3 D3.1
Traceability Report
Requirements to Validation Test
D3.2
Validation Test Review Minutes
Objectives Review
D1.2

Figure 9. Detail Tasks in the Validation Test Planning Process

The verification process for the validation test plan consists of a validation test plan review.
When the review team agrees that the tests can be done practically and each requirement can
be tested (test, analysis or inspection), the minutes are done to document the meeting results.

Requirements – Validation Test Tracking

An important requirement of functional safety is that there be one or more tests to validate that
requirements have been implemented. This must be proven by bidirectional links that show
which requirements are validated by each test and which show which tests validate each
requirement (Figure 10).

Design Requirements
Tested by
Safety Requirements Validation Test
Traceable Forwards and Backwards
Often split into
Non-safety Requirements

Figure 10. Requirements - Validation Tracking

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 11
 excellence in dependable automation

Requirement-Validation tracking is often implemented within the requirements management

tool as shown in the Associated Objects of Figure 11 where two validation tests are listed for the
requirement ARC1.1.

Figure 11. Requirements - Validation Tracking Tool

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 12
 excellence in dependable automation

Architecture Design
Architecture design is typically done in a top-down structured, hierarchical process. Figure 12
shows an example process for a design including hardware and software including input and
output documents.

System Requirements Create System Architecture Design

Specification Architecture Design Specification
D2.3 D4.1

System Architecture Architecture-Safety Concept

Safety Concept Report
Review D4.2

System Architecture System DDMA Report

DFMEA/DDMA D4.3

Create Hardware Hardware Architecture Create Software Software Architecture

Architecture Description Architecture Description
D4.1 D4.1

Hardware Review Minutes Software Review Minutes

Architecture Review Architecture Review
D1.2 D1.2

HW Subsystem
Subsystem DDMA Report SW Subsystem Subsystem DDMA Report
Architecture
Architecture DFMEA
DFMEA/DDMA D4.3 D4.3

Create Integration Integration Test Objectives

Test Plan
D4.5
Traceability Report
Requirements to Integration Test Plan Review Minutes
Implementation Review
D4.4 D1.2

Figure 12. Detail Tasks in Architecture Design Process

Architecture design steps can vary significantly depending on the project. Multi-levels of
hierarchy may result in one or more sub-systems. Figure 13 shows a the process where a device
has a single sub-system level.

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 13
 excellence in dependable automation

Create and Review

System Architecture
Design

Safety Concept Review

System Architecture/
DFMEA Level 1*

Create and Review

Sub-system
Architecture Design
Create and Review
Sub-System Integration Test Plan
Architecture/ DDMA
Level 2

Allocate Functions to
Hardware and
Software

Create and Review

Update Validation Test
Updated Safety
Plan
Requirements

Figure 13. Architecture Design with one sub-system level

There is often a question of how many levels of hierarchy are needed. This is a decision done by
the development team based on the question, “How many levels are useful in this design?” One
good rule for hardware is to stop at the lowest level of functionality that can be implemented
with electronic or mechanical components. For software, stop at the level that can be coded.

10/100 Mbps Link

24VDC Power Dual 24VDC Power Supply Ethernet

AIN, DIN
24V sources
Loop Sources RUN_OK output
4-20 mA input
4-20 mA Inputs mA in
24V 1A output
4-20 mA input
24V digital input 24V 1A output
24V digital input
Micro- 24V 1A output
24V Digital Inputs 24V digital input
computer
w/r to GND 24V digital input 24V 1A output
Digital in
24V digital input
Indicator LEDs
24V digital input
for DI, DO,
24V digital input Traffic,
24V digital input Main/Backup,
FAULT
24V Sources,
RUN_OK status Digital Out
outputs

Power Input
Conditioning

Figure 14. Hardware Architecture Design with one sub-system

Figure 14 shows one sub-system level where the power supply block is divided into five blocks.
The functionality of each block must be described and references to related requirements are
made. With that information each block can be implemented in the electronic schematic.

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 14
 excellence in dependable automation

If digital communications are used in the design, the binary protocol must be analyzed per
functional safety requirements. A set of qualitative requirements are combined with a
quantitative probability of an undetected dangerous message.

Architecture Design Verification – DFMEA/DDMA

A common and well proven technique for architecture design verification is Design Failure
Modes and Effects Analysis (DFMEA). This method was developed decades ago to identify design
issues caused by functional failures. Finding a problem in architecture design verification can
save a lot of rework. But DFMEA can be time consuming and does not meet all needs of
functional safety projects. A variation of the DFMEA method for functional safety is called
DDMA – Design Deviation and Mitigation Analysis [7].

Many design tools are available for DFMEA or DDMA. Figure 15 shows the Load Unit Knowledge
screen from ARCHx, a DexDMA tool.

Figure 15. Load Unit Knowledge screen from ARCHx

The outputs of the architecture design phase include:

1. The Architecture Design Description with all drawings, a good functional description of
each block, and references to the requirements implemented.
2. Minutes / Report of the architecture design reviews (with Actions Items if needed)
3. The Architecture design verification report which is typically A Design Failure Modes and
Effects Analysis (DFMEA) with additional descriptions of needed automatic testing, start-
up testing, latent fault testing and actions taken when failures are detected.
Alternatively, a Design Deviation and Mitigation Analysis (DDMA) [7] which includes all
information for functional safety can be done.
4. Integration Test Objectives
5. Review Meeting Minutes

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 15
 excellence in dependable automation

Hardware Design
Hardware design is done with goals to make the design robust against hardware design faults,
environmental stress, random component failures, operator mistakes, and foreseeable
maintenance errors. Figure 16 shows an example hardware design process.

Circuit Diagrams /
Description
D5.1

HDL Source Code

Requirements D5.2
Specification Create Detailed
D2.3 Layouts, Parts Lists
Hardware Design
Hardware Architecture D5.3
Description
D4.1
Detailed Hardware Review Minutes
Design Review D1.2

Perform Component FMEDA Report

FMEDA D5.4

Fault Insertion Test Perform Fault Fault Insertion Test

Specification/Results Injection Testing Specification/Results
D5.5 D5.5

Figure 16. Hardware Design Process

The concept of fail-safe design is normally followed by using the principle of “De-energize To
Trip” which means that discrete inputs used to sense a dangerous condition should use logic
zero (no energy) to indicate a hazard. Deenergize to trip also means that outputs used to
annunciate an internal failure or implement a protection function use logic zero (no energy) as
well. Fail-safe is usually accomplished by the removal of energy. If the design must use
“Energize to Trip” then power systems (electric or hydraulic) must be carefully reviewed. These
will likely need to be redundant to meet dangerous probability metrics.

Hardware designs must consider hardware implementation of automatic diagnostics.

Capabilities such as ECC for memory, Windowed Watchdog Timers with independent clocks,
pulse testing / readback for inputs and outputs, and voltage/current/position/temperature
measurements. Often hardware must be designed to implement extensive start-up testing
which can detect failures undetectable during operation. Latent Fault tests (Proof tests) may
need hardware support as well. If digital communications are used for safety critical variables, a
quantitative analysis [8] must be done to show a high probability that potentially dangerous
messages are detected.

The completed hardware design should achieve a low failure rate by having a strong margin on
design strength. The use of parts with specifications higher than any expected stress level
(temperature, voltage, current, etc.) is evaluated in the quantitative failure analysis on the

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 16
 excellence in dependable automation

hardware design called Failure Modes, Effects and Diagnostic Analysis (FMEDA). The hardware
design must meet electro-magnetic emission limits and susceptibility levels defined by IEC
61326-3-1 [9].

Hardware Detail Design

Hardware detail design may have different steps depending on the tool set used and the
component technology. An example set is shown in Figure 17.

Component Selection

Simulation

Schematic Capture

Netlist Checking

Board Layout

Test Suite Generation

Figure 17. Detailed Hardware Design Example Tasks

Electronic and mechanical components must be justified and chosen. Components are typically
chosen from an approved company component list. New components are added to the list when
they are evaluated by analysis and testing. Avoid new unproven technology. ULA packing is
strongly recommended for VLSI components. Be careful to evaluate the useful life parameter to
make sure the component is designed for the needed lifetime of the device under development.

Other tasks in the Hardware detail design depend on the design tools used and technologies
employed. Functional safety requirements are focused on the use of qualified and integrated
tool sets.

Failure Modes, Effects and Diagnostic Analysis (FMEDA)

An FMEDA [10] is performed on hardware designs to predict a set of reliability metrics used for
safety integrity level verification. The FMEDA looks at each component (or section of a
component). The failure rate and failure modes for that component are obtained for a specific
design strength and environmental stress level [11].

The FMEDA method was created to determine the impact of on-line automatic diagnostics on
the reliability metrics of a design [12]. The automatic diagnostic functions are listed in the
requirements and must have a validation test. This is often done by specifying a “fault injection
test.” A hardware failure is simulated for each automatic diagnostic and the action taken
specified in the requirement of the DDMA is validated.

An FMEDA may be done with a spreadsheet or an FMEDA tool. Figure 18 shows the Component
Node Editor of FMEDAx where component failure modes are mapped to unit failure mode. The
component failure rates for each component failure mode and the Useful Life of the component
are automatically loaded and displayed from a database [13]. This tool uses the functional

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 17
 excellence in dependable automation

failure mode FMEDA method [14] which has been proven to be more effective in iterative
design environments.

Figure 18. FMEDAx Tool Component Node Editor

A component database is the most important part of any FMEDA tool. That database must
contain for each component:
• Failure rates for various design profiles and operating environments
• Failure modes and distributions (not just 50%/50% safe-dangerous assumptions)
• Useful life for various design profiles and operating environments
• The impact of analog drift in electrical components
• The impact of integrated circuit soft error rates (SER)
• The impact of dynamic operation in mechanical components

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 18
 excellence in dependable automation

To be useful for field failure prediction, the database must be compared with actual field failure
data [15]. Any differences in FMEDA predictions and actual field results are used to adjust the
formulas in the database. Given the advances in technology, the database should be updated at
least once per year.

Software Design
Functional safety has many requirements for software design. Figure 19 shows an example
process.

Requirements
Specification
D2.3
Write Software Code Source Code
Software Architecture D7.1
Description
D4.1
Review Minutes
Software Code D1.2
Review
Perform Static Source
Code Analysis Static Analysis Results
D7.2

Unit Test Code Unit Test Plan/Results

D7.3

Figure 19. Detailed Software Design Example Tasks

Functional safety requires a programming language to “be completely and unambiguously

defined or restricted to unambiguously defined features” and “contain features that facilitate
the detection of programming mistakes.” A practical interpretation is that our most commonly
used languages, C and C++, must have a defined subset for functional safety. The MISRA C [16]
and C++ Coding Standards have done a good job defining those language restrictions.

There are many other requirements for software design and implementation from the software
engineering community. Items like:

• Suggested Software Unit Size Limit (e.g. 100 lines of code, 4 screens, a cyclomatic
complexity < 10). However, you decide the limit.
• One entry/one exit point in subroutines and functions
• Variables encapsulated at lowest possible scope; avoid use of global variables
• Units communicate with each other only through their interfaces which are fully
defined.

Software Implementation - Test Tracing

Some functional safety standards require implementation tracking between software
architecture and unit implementation. The purpose of this is to understand dependencies on the
design. This is most useful when making changes to the unit implementation. Some architecture

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 19
 excellence in dependable automation

design verification tools provide tracing capability between architecture and software
implementation as well as between software units and unit tests. Figure 20 shows an example
of a software unit to unit test link.

Figure 20. Link between a Software Unit and its Unit Test

Code Review
Code Review is intended to find potential issues. The objective is to have an independent review
to see if the source code:

• Is readable, understandable and testable;

• Conforms to the software architecture design;
• Satisfies the Coding Standard requirements not enforced by the static source code
analysis tool; and
• Is maintainable.

Static Source Code Analysis

Static Source Code Analysis (SSCA) is a method of detecting issues in source code automatically
using a tool. The SSCA tool is “tuned” to the Source Code Standard and is used to identify
violations. “Tuning” can greatly impact the usefulness of the method as some have experienced
“thousands” of warning messages – most of which the developer will reject – not good.

Even a well-tuned SSCA can have false positives and false negatives. Warning messages must be
reviewed by the developer. Even with these limitations, an SSCA tool has been shown to provide
cost effective error checking.

Unit Testing
Unit testing is focused on each software unit (or module) to verify that each unit performs its
intended function. The focus is on understanding the functionality of each unit in isolation. Test

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 20
 excellence in dependable automation

plans are created with input suites for each module and expected results. Input equivalence
testing and boundary value analysis must be done as part of the input suite definition. Unit
testing must consider the structure of each unit with 100% entry point coverage, 100%
statement coverage, and 100% branch coverage. Unit Test results are usually put into the test
plan and must be documented.

Integration
Integration testing is done for hardware units, software units and hardware to software. In the
integration testing the focus is on the information exchanged between units. For hardware this
might be voltage levels, current levels, digital communication, etc. For software this is typically
blocks of data. The purpose is to make sure the output from one unit matches the expected
inputs of units receiving that output. Do all units operate as designed? Figure 21 shows the
process.

Integration Test Objectives Add Integration Test

Plan Details
D4.5

Integration Test Objectives / Perform Integration

Plan Integration Test Report
D4.5A Testing D4.5B

Figure 21. Integration Test Example Tasks

Integration testing is done per a test plan. As most integration test objectives are defined during
the architecture design review / verification, detail information about the test environment,
specific expected results, tester, test date, and version tested is typically added to the
integration test objective report to complete the test plan (D4.5A). When the test is done,
results are recorded in the document with a pass / fail indication (D4.5B). All failures must be
tracked to resolution. An Action Item system is often used for that purpose. Figure 22 shows an
example of an Action Item Editor.

Figure 22. Action Item Editor from OEMx used to track test failure

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 21
 excellence in dependable automation

Validation
Validation testing is done per the Validation test plan to show that all requirements have been
implemented. Detail test information is typically added to the validation test objective report to
complete the test plan (D3.1A). When each test is done, results are recorded in the document
with a pass / fail indication (D3.1B). An example process is shown in Figure 23.

Validation Test Add Validation Test

Objectives Plan Details
D3.1

Validation Test Objectives /

Plan
D3.1A Perform Validation
Validation Test Report
Testing
D3.1B
Safety Manual
D2.4

Figure 23. Validation Test Example tasks

Any updates to the Validation test plans are done at this time. If changes impact the Traceability
Report (D3.2) it is important to update that report as well. Any test and measurement
equipment used in the validation test must be calibrated against a standard traceable to a
recognized procedure. Version numbers must be recorded for the hardware and software under
test as well as all test software.

A careful inspection of the Safety Manual is part of validation testing. The manual information
must be clear, complete, and correct. All information needed for installation, environmental
constraints, overall safe operation, calibration, repair, and latent fault testing must be available.
The field failure reporting process must be described along with requirements for return of
suspected defective devices. The Safety Manual may contain the information or refer to other
documents as needed.

As with integration testing, all failures should be tracked to resolution. If changes need to be
made to the device design, an impact analysis must be made to determine what steps in the
development process must be repeated. Documents produced in each step used for the change
must be updated.

Production Release
Production release procedures are common and usually well established. Functional safety
requirements include a check that all verification steps in the project have been completed with
required documents. All Action Items must be resolved. The Safety Manual must be complete
and approved.

These functional safety requirements are often simply added to the existing production release
checklist items which depend on the technology and production methods.

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 22
 excellence in dependable automation

Lifetime Maintenance
Functional Safety standards recognize the need for a lifecycle approach. A few key activities
need to be done but these are not much different from the product stewardship requirements
of most regulatory bodies.

Device/product performance during operation must be monitored, typically by a field failure

reporting system. Any failures that might result in a dangerous condition are traced to root
cause and if needed, the design is improved. Safety notification may be required. This depends
on the regulatory situation in the geographical areas served by the manufacturer.

Field Failure Reporting System

The field failure reporting system is important for functional safety to verify probabilistic
performance predictions and identify potential design weaknesses. A process must be
established for customers to report problems, especially safety issues to the design source /
manufacturer. The end user must be able to report symptoms and any relevant operating
conditions. The root cause analysis is done to discover the reason(s) for the failure to the best of
the team ability. If design weaknesses are discovered, changes will be needed to increase the
design strength or lower the specified operating conditions.

Field operational hours need to be estimated. If each device has a built-in “operating hours”
counter, that is the best source of the data. Otherwise, estimates can be made from shipping
records, installation dates, and other end user data.

Latent Fault Testing / Proof Testing

The designers of devices / products for functional safety applications used in applications where
dangerous conditions are infrequent (low demand) can specify tests that can be done
automatically, semi-automatically or manually. These are done to identify potentially dangerous
internal failures not detected by automatic diagnostics done during safety operation. The
FMEDA can identify what these component failures might be. The objective is to create a test
that can detect those specific failures not detectable during operation. A “start-up” test is a
good example.

In devices designed for a specific application, the test frequency may be determined to meet the
risk reduction (SIL level) requirements. That test frequency and/or the method used to
determine that result must be available to the end users. For devices designed for general
purpose usage, the test frequency must be determined by the System designer.

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 23
 excellence in dependable automation

Definitions & Acronyms

Automatic Diagnostic – a test to detect failures in a device that is run automatically on a periodic
schedule (known as the Diagnostic Test Interval, DTI) with an annunciation mechanism to
indicate when a failure occurs.

DDMA – Design Deviation and Mitigation Analysis, a DFMEA optimized for functional safety by
eliminating duplicate work and adding required functional safety parameters

DexDMA – Design expert Deviation and Mitigation Analysis, a DDMA done with expert
knowledge

DFMEA – Design Failure Mode and Effect Analysis

FMEA – Failure Mode and Effect Analysis

FMEDA – Failure Modes, Effect and Diagnostic Analysis

FSM – Functional Safety Management

Latent Fault Test – a test to detect failures in a device that is operated when the safety function
is not operating. It can be automatic (a power-up test), semi-automatic, or manual.

PLC – Programmable Logic Controller

ULA – Ultra Low Alpha: molding compound, solder paste, epoxy material that are monitored for
Alpha particle emission. A count per hour must be less than 0.002 cph/cm2

References
1. IEC 61508, Functional safety of electrical/electronic/programmable electronic safety-related
systems, International Electrotechnical Commission, Geneva, Switzerland (2nd Edition),
2010
2. Juran, J.M., Juran on Quality by Design: The New Steps for Planning Quality into Goods and
Services, Free Press, May 4, 1992
3. Pressman, Roger S, Maxim, Bruce R., Software Engineering - A Practitioner’s Approach,
McGraw-Hill, 9th Edition, 2019
4. Humphrey, Watts S., Managing the Software Process, Addison-Wesley, 1989
5. The exida IEC 61508- Functional Safety and IEC 62443 – Cybersecurity Certification
Programs, White Paper, exida, Sellersville, PA, [Link], Rev. 1.1, November 2017
6. Safety Instrumented Function Verification: The Three Barriers, White Paper, exida,
Sellersville, PA, [Link], Rev 2.1, November 2017
7. The Essential DFMEA Process – Maximum Value / Optimal Cost, White Paper, exida,
Sellersville, PA, [Link], Rev. 1.0, July 31,2024
8. IEC 61784-3, Functional safety fieldbuses – General rules and profile definitions, Edition 4.1,
2024-04, International Electrotechnical Commission, Geneva, Switzerland

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 24
 excellence in dependable automation

9. IEC 61326-3-1, Industrial communication networks - Profiles - Part 3: Functional safety

fieldbuses - General rules and profile definitions, Edition 4.0, February 16, 2021,
International Electrotechnical Commission, Geneva, Switzerland
10. FMEDA Development, White Paper, exida, Sellersville, PA, [Link], Rev. 2.0,
October 2021
11. Environmental Impact on Failure Rates, White Paper, exida, Sellersville, PA,
[Link], Rev. 1.0, June 28, 2024
12. Goble, W.M. and Brombacher, A.C. “Using a Failure Modes, Effects and Diagnostic Analysis
(FMEDA) to Measure Diagnostic Coverage in Programmable Electronic Systems,” Reliability
Engineering and System Safety, Vol. 66, No. 2, November 1999.
13. Got (Good) Data? – Using the exida Component Reliability Database for New Product
Design & Development, White Paper, exida, Sellersville, PA, [Link] , July 2021
14. Chalupa, R. P., Get Your FMEDA Done Faster - Use Functional Effects, White Paper, exida,
Sellersville, PA, [Link], Rev. 1.1, July 2024
15. Comparing FMEDA Predicted Failure Rates to OREDA Estimated Failure Rates for Sensor
and Valve Assemblies, White Paper, exida, Sellersville, PA, [Link], September
2019
16. MISRA C:2023, Third Edition, Second Revision, [Link]

Revision History
Draft Revision 0.2 September 30, 2024 William Goble
Release Revision 1.0 October 2024 William Goble
Addressed comments made in reviews
Release Revision 1.1 August 2025 William Goble
Added more details in the architecture design, hardware design sections

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 25
 excellence in dependable automation

exida – Who we are.

exida is one of the world’s leading accredited certification and knowledge
companies specializing in automation system cybersecurity, safety, and
availability. Founded in 2000 by several of the world’s top reliability and safety
experts from assessment organizations, manufacturers, and end user companies,
exida is a global company with offices around the world. exida offers training,
project-oriented consulting services, standalone and internet-based safety and
cybersecurity engineering tools, detailed product assurance and certification
analysis, and a collection of online safety, reliability, and cybersecurity resources.
exida maintains a comprehensive failure rate and failure mode database on
electrical and mechanical components, as well as automation equipment based on
failure data sets representing over 400-billion-unit operating hours.
The exida team of industry leading engineers with extensive experience in
Chemical, Petro-Chemical, Oil & Gas, Subsea, Metals and Mining,
Pharmaceutical, Pulp & Paper, Power Utilities, Automotive, Robotics, and
Machinery applications. This unique combination of technical depth and hands-on
experience enables exida to provide practical solutions to address your most
difficult challenges.
exida Certification is an ANSI (American National Standards Institute) accredited
certification organization that performs functional safety (IEC 61508 family of
standards) and cybersecurity (IEC 62443 family of standards) certifications.
Knowledge Products
exida has made the process of designing, installing, and maintaining a safety and
high availability automation system easier, as well as providing a practical
methodology for managing cybersecurity. Years of experience in the industry have
allowed a crystallization of the combined knowledge that is converted into useful
tools and documents, called knowledge products. Knowledge products include
procedures for implementing cybersecurity, the Safety Lifecycle tasks, alarm
rationalization, software tools, and templates for all phases of design.
Training
exida believes that safety, high availability, and cybersecurity are achieved when
more people understand the topics. Therefore, exida has developed a successful
training suite of online, on-demand, and web-based instructor-led courses and on-
site training. The course content and subjects range from introductory awareness
to advanced detailed engineering topics. The exida website lists the continuous
range of courses offered around the world.

Tools and Products for End User Support

• exSILentia® – Integrated Safety Lifecycle Tool
o PHAx™ (Process Hazard Analysis)
o LOPAx™ (Layer of Protection Analysis)
o SILAlarm™ (Alarm Management and Rationalization)

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 26
 excellence in dependable automation

o SILect™ (SIL Selection and Layer of Protection Analysis)

o Process SRS (PHA based Safety Requirements Specification
definition)
o SILver™ (SIL verification)
o Design SRS (Conceptual Design based Safety Requirements
Specification definition)
o Cost (Lifecycle Cost Estimator and Cost Benefit Analysis)
o SIS Logic (Application Program Generation)
o PTG (Proof Test Generator)
• exSILentia® Cyber- Integrated Cybersecurity Lifecycle Tool
o CyberPHAx™ (Cybersecurity Vulnerability and Risk Assessment)
o CyberSL™ (Cyber Security Level Verification)
• IEC 61511 Compliance Templates
• Cybersecurity Process Templates
• CFSE Study Guide
• CACE Study Guide

Tools and Products for Manufacturer Support

OEMx- Integrated Product Development Tool
o REQx (Requirements Organization and Tracking Tool)
o FMEDAx (FMEDA tool including the exida EMCRH database)
o ARCHx (System Analysis tool; Hardware and Software Failure,
Dependent Failure, and Cyber Threat Analysis)
• CFSE Study Guide
• CACE Study Guide
• IEC 61508 Compliance Templates
• IEC 62443 Compliance Templates
For any questions and/or remarks regarding this White Paper or any of the services
mentioned, please contact exida:
[Link] LLC
80 N. Main Street
Sellersville, PA, 18960
USA
+1 215 453 1720
+1 215 257 1657 FAX
info@[Link]

A Functional Safety Development Process Example, Copyright © exida. LLC 2025 Page 27