FSD303: Techniques and measures

Header

Title	FSD303: Techniques and measures
Current version	V5
Products	Safety Simplifier
Requirements	61508-1 clause 6.2.12
Purpose	Specify more detailed requirements for documentation, and explain how those requirements are met.

Table of contents

Description

The techniques and measures which are applied are described in this document.

Requirements

Requirement: Techniques and measures REQ_303_001

status: PASS Derived: TEST_303_001 Nested: TEST_303_001

The techniques and measures used shall be those specified as HR and R in the SIL 3 column. TEST: Techniques and measures for SIL3 TEST_303_001 status: PASS Derived: RESULT_303_001 Source: REQ_303_001 Parent: REQ_303_001 Nested: RESULT_303_001 Verify that the techniques and measures used are those specified as HR and R in the SIL 3 column in the tables below. RESULT: Techniques and measures for SIL3 RESULT_303_001 status: PASS Source: TEST_303_001 Parent: TEST_303_001 See tables in FSD303: Techniques and measures.

Techniques and measures

61508-2 Table A.15: Techniques and measures to control systematic failures caused by hardware design

Technique/measure	See 61508-7	SIL3	Deviation	Comment	Use
Program sequence monitoring	A.9	HR	N	Watch-dogs.	Internal watch-dog with separate time base are used. Also, capacitive coupling for major enable signal requires active/working SW to enable it.
Failure detection by on-line monitoring	A.1.1	R	N	Digital I/O: redundant monitoring. Relay: redundant monitoring of safety relays.	Measures from both redundant branches shall be feasible, within a given range, and shall agree. For outputs, measured monitored value shall be same as output control.
Tests by redundant hardware	A.2.1	R	N	Redundant hardware for safety functions.	See schematics. Redundant signals for inputs, digital outputs, relay outputs, logic (2 CPUs) etc. Also see FSD304.
Standard test access port and boundary-scan architecture	A.2.3	R	Y	Not available on microcontrollers. Also not required.
Code protection	A.6.2	R	Y
Diverse hardware	B.1.4	R	N	Measuring branches, logic, digital outputs.	Input/monitoring measuring uses different resistor value for divider. CPUs are different types, different software. Digital Output has one main transistor + individual transistors.

61508-2 Table A.16: Techniques and measures to control systematic failures caused by environmental stress or influences

Technique/measure	See 61508-7	SIL3	Deviation	Comment	Use
Measures against voltage breakdown, voltage variations, overvoltage, low voltage etc.	A.8	M	N	Several stages for power supply, monitored. Both CPUs monitor each others voltage. Reverse polarity protection, brown-out enabled in CPUs.	See schematics and SW.
Separation of electrical energy lines from information lines	A.11.1	M	N	Separation considered in the hardware design.	See PCB layout, including DRC in PCB software.
Increase of interference immunity	A.11.3	M	N	Filtering in the hardware design.	See schematics and PCB layout, also check test reports. Capacitive filters have been added to analog inputs for application stability.
Measures against physical environment (temperature, humidity, water, vibration, dust, corrosive substances)	A.14	M	N	Hardware and software are developed to withstand the required environmental conditions, and have undergone extensive tests in these conditions in test labs and during development.	See test reports for temperature test, rotating barrel, drop test, IP test, etc.
Program sequence monitoring	A.9	HR	N	Watch-dogs.	For usage of watch-dogs, see schematics and source code.
Measures against temperature increase	A.10	HR	Y	Online temperature monitoring.	Source code measures temperature and shuts down if too high. See Overheating shut off (DREQ_17D).
Spatial separation of multiple lines	A.11.2	HR	N	Considered during PCB layout.	See PCB layout.
Idle current principle (where continuous control is not needed to achieve or maintain a safe state of the EUC)	A.1.5	R	N	The system will enter a safe state when power to the unit is cut.	See PCB layout.
Measure to detect breaks and shorts in signal lines	R	N		Possibility to detect some open-circuits and short-circuits of stop button.	See schematics and comparison between redundant signals.
Failure detection by on-line monitoring	A.1.1	R	N	Will be used wherever relevant.	See FSD304-system architecture description. See also schematics and source code.
Tests by redundant hardware	A.2.1	R	N	Redundant hardware for safety-related functions.	For redundant online tests, and startup tests of redundant HW, see source code, see FSD300: Software Module Tests, and schematics.
Code protection	A.6.2	R	N	Code protection is enabled in all safety CPUs. All firmware is encrypted with a private key during build, and decrypted in bootloader.	See Booty (new bootloader) (FSWP0001).
Antivalent signal transmission	A.11.4	R	N/A	Not used and not required.
Diverse hardware	B.1.4		N	Measuring branches, logic, digital outputs.	Input/monitoring measuring uses different resistor value for divider. CPUs are different types, different software. Digital Output has one main transistor + individual transistors.
Software architecture	See 61508-3, 7.4.3	See 61508-8.3, table A.2

61508-2 Table A.17: Techniques and measures to control systematic operational failures

Technique/measure	See 61508-7	SIL3	Deviation	Comment	Use
Modification protection	B.4.8	HR	N	Start-up test, safety-related failure detection, CRC, memory check etc.	Protection against hardware modifications: Start-up tests, see source code Various hardware failure detection, see table A.17 CRC, see source code Flash memory check, see source code RAM memory check, see source code
Failure detection by on-line monitoring	A.1.1	R	N	Will be used wherever relevant.	See table A.16.
Input acknowledgement	B.4.9	R	Y	Not practical in this kind of product. Also not required.
Failure assertion programming	C.3.3	R	N	Preconditions are asserted at the top in all function. Postconditions are asserted at the end of all functions. Return values are asserted for all function calls that have return values. If an assertion fails, the system enters safe state.	See source code.

61508-2 Table B.1: Recommendations to avoid mistakes during specification of E/E/PE system requirements (see 7.2)

Technique/measure	See 61508-7	SIL3	Deviation	Comment	Use
Project management	B.1.1	HR	N	Project management in accordance with EN 61508:2010.	See FSD002: Management of functional safety.
Documentation	B.1.2	HR	N	Functional safety documentation in this project in accordance with EN 61508:2010.	See FSD001: Documentation structure and FSD002: Management of functional safety.
Separation of E/E/PE system safety functions from non-safety functions	B.1.3	HR	N	Separated in both hardware and software.	See Nonsafe code/hardware affec... (HAZARD_21) and derived requirements. For separation in hardware design, see schematics and FMEDA report. For separation in software design, see source code. Static analysis tools are used to show the separation of safety and non-safety functions.
Structured specification	B.2.1	HR	N	In accordance with EN 61508:2010.	See FSD114: 61508-1 E/E/PE system safety requirements specification.
Inspection of the specification	B.2.6	HR	N	In accordance with EN 61508:2010.	See FSD107: System verification plan, validation test specifications and results phase 10.1.
Semi-formal methods	B.2.3	HR	Y	No actual semi-formal methods are used, but compensated with: 1) Overall block diagram of the design. 2) Block diagram in E/E/PE system architecture description.	For usage of block diagrams, see FSD304: System architecture description.
Checklists	B.2.5	R	N	The E/E/PE system verification plan is used as a check list, and contain verification procedures to check the E/E/PE system safety requirement specification.	See FSD107: System verification plan, validation test specifications and results phase 10.1.
Computer aided specification tools	B.2.4	R	N	Requirements management tool (Sphinx-needs) is used together with Git for version control. Redmine for issue tracking, doxygen as software documentation tool.	See FSD001: Documentation structure.
Formal methods	B.2.2	R	Y	Not used and not required.

61508-2 Table B.2 - Recommendations to avoid introducing faults during E/E/PE system design and development (see 7.4)

Technique/measure	See 61508-7	SIL3	Deviation	Comment	Use
Observance of guidelines and standards	B.3.1	HR	N	EN 61508:2010, MISRA C, IPC-standards.	For usage of MISRA, see FSD307: Software Integration Tests.
Project management	B.1.1	HR	N	Project management in accordance with EN 61508:2010.	See FSD002: Management of functional safety.
Documentation	B.1.2	HR	N	Functional safety documentation in this project in accordance with EN 61508:2010.	See FSD001: Documentation structure and FSD002: Management of functional safety.
Structured design	B.3.2	HR	N	Both hardware and software, by using flow charts etc.	For usage of structured design, see: 1) Schematics 2) PCB layout 3) Flow charts for software design
Modularisation	B.3.4	HR	N	Used wherever relevant, both in hardware and software.	See schematics and source code.
Use of well-tried components	B.3.3	HR	N	relay considered as well-tried component.
Semi-formal methods	B.2.3	HR	N	See 61508-3, table B.7.	Logic/function block diagrams, sequence diagrams, and state diagrams are extensively used to model the system. See FSD304: System architecture description.
Checklists	B.2.5	R	N	The E/E/PE system verification plan is used as a check list.	See FSD107: System verification plan, validation test specifications and results phase 10.1.
Computer aided design tools	B.3.5	R	N	Eagle (Cadsoft) used for hardware design.
Simulation	B.3.6	R	N	Both for hardware and software. Simulation tests of configurations are performed during development as part of the test suite.	See FSD124: GUI and Compiler function requirements, module tests and integration tests for simulation tests of configuration.
Inspection of the hardware or walkthrough of the hardware	B.3.7, B.3.8	R	N	Internal design reviews and RISE hardware calculations.
Formal methods	B.2.2	R	Y	Not used and not required.

61508-2 Table B.3 - Recommendations to avoid faults during E/E/PE system integration (see 7.5)

Technique/measure	See 61508-7	SIL3	Deviation	Comment	Use
Functional testing	B.5.1	HR	N	The following functional tests will be performed: 1) Safety-related functionality 2) Overall functionality 3) Safety-related functionality in extreme conditions	See FSD124: GUI and Compiler function requirements, module tests and integration tests, FSD150: Validation tests of modes, power supply, and configuration, and FSD300.
Project management	B.1.1	HR	N	Project management in accordance with EN 61508:2010.	See FSD002: Management of functional safety.
Documentation	B.1.2	HR	N	Documentation in accordance with ISO 9000 and EN 61508:2010.	In general, functional safety documentation in this project follows the 61508 guidelines.
Black-box testing	B.5.2	R	N	Mainly used as integration test from PC	See FSD124: GUI and Compiler function requirements, module tests and integration tests, FSD150: Validation tests of modes, power supply, and configuration, and FSD300.
Field experience	B.5.4	R	Y	Not planned and not required.
Statistical testing	B.5.3	R	Y	Not planned and not required.

61508-2 Table B.4 - Recommendations to avoid faults and failures during E/E/PE system operation and maintenance procedures (see 7.6)

Technique/measure	See 61508-7	SIL3	Deviation	Comment	Use
Operation and maintenance instructions	B.4.1	HR	N	Requirements for operation and maintenance instructions are derived from identified risks and hazards.	See FSD011: Hazard and risk analysis, FSD114: 61508-1 E/E/PE system safety requirements specification, FSD120: System design requirements specification and derived requirements relating to operating instructions.
User friendliness	B.4.2	HR	N	User interface, configurations, functionality etc. based on customer validations and many years of experience from similar functional safety products.	See requirements derived from Downloading of configuratio... (HAZARD_11) Failure to download (HAZARD_12), and Unauthorized access (malici... (HAZARD_17).
Maintenance friendliness	B.4.3	HR	N	Experience from earlier functional safety products.	No hardware maintenance required. In case of a hardware failure, the unit is replaced. All software related maintenance is done through the configuration tool, which is user friendly and easy to use. See requirements derived from Downloading of configuratio... (HAZARD_11) Failure to download (HAZARD_12), and Unauthorized access (malici... (HAZARD_17).
Project management	B.1.1	HR	N	Project management in accordance with EN 61508:2010.	See FSD002: Management of functional safety.
Documentation	B.1.2	HR	N	Documentation in accordance with EN 61508:2010.	In general, functional safety documentation in this project follows the guidelines in EN 61508:2010.
Limited operation possibilities	B.4.4	HR	Y	As this is a PLC, flexible configuration is a part of the product definition.	Configuration is defined via a reduced complexity function block diagram language, which simplifies the use of safety functions to the user.
Protection against operator mistakes	B.4.6	HR	N	Only trained personel allowed to make changes to operation. Once operational, no UI to adjust functionality.	See manual regarding requirement of trained personel.
Operation only by skilled operators	B.4.5	R	N/A	Not required.

61508-2 Table B.5 - Recommendations to avoid faults during E/E/PE system safety validation (see 7.7)

Technique/measure	See 61508-7	SIL3	Deviation	Comment	Use
Functional testing	B.5.1	HR	N	According to E/E/PE system safety validation.	See FSD107: System verification plan, validation test specifications and results Phase 10.2.
Functional testing under environmental conditions	B.6.1	HR	N	According to E/E/PE system safety validation.	See FSD107: System verification plan, validation test specifications and results Phase 10.2.
Interference surge immunity testing	B.6.2	HR	N	Surge test performed.	See IEC 61000-6-7 (EMC) (CERT_0003).
Fault insertion testing (when required diagnostic coverage ≥ 90%)	B.6.10	HR	N	If required by FMEDA.
Project management	B.1.1	HR	N	Project management in accordance with EN 61508:2010.	See FSD002: Management of functional safety.
Documentation	B.1.2	HR	N	Documentation in accordance with EN 61508:2010.	In general, functional safety documentation in this project follows the guidelines in EN 61508:2010.
Static analysis, dynamic analysis and failure analysis	B.6.4, B.6.5, B.6.6	R	N	If required by FMEDA
Simulation and failure analysis	B.3.6, B.6.6	R	N	If required by FMEDA
Worst-case analysis, dynamic analysis and failure analysis	B.6.7, B.6.5, B.6.6	R	N	If required by FMEDA
Static analysis and failure analysis	B.6.4, B.6.6	NR	N	If required by FMEDA
Expanded functional testing	B.6.8	HR	N	The unit is tested with extreme or unrealistic scenarious, i.e. all pins connected together.	See FSD307: Software Integration Tests, FSD124: GUI and Compiler function requirements, module tests and integration tests, and FSD150: Validation tests of modes, power supply, and configuration.
Black-box testing	B.5.2	R		Done for function blocks	See FSD307: Software Integration Tests, FSD124: GUI and Compiler function requirements, module tests and integration tests.
Fault insertion testing (when required diagnostic coverage ≥ 90%)	B.6.10	R	N	According to E/E/PE system safety validation.	See FSD107: System verification plan, validation test specifications and results Phase 10.2.
Statistical testing	B.5.3	R		Not used and not required
Worst-case testing	B.6.9	R		Not used and not required
Field experience	B.5.4	R		Not used and not required

61508-3 Table A.1 - Software safety requirements specification (see 7.2)

No.	Technique/measure	See 61508-7	SIL3	Deviation	Comment	Use
1a	Semi-formal methods	Table B.7	HR	Y	No Semi-Formal methods are used in the requirements specification phase due to the fact that the amount of requirements is very limited.
1b	Formal methods	B.2.2, C.2.4	R
2	Forward traceability between the system safety requirements and the software safety requirements		HR	N	Requirements management tool (Sphinx-needs) is used for traceability between all requirements, specifications and tests. All requirements in 61508 are mapped to requirements specified in this documentation.	See FSD001: Documentation structure, 61508-1, 61508-2, 61508-3.
3	Backward traceability between the safety requirements and the perceived safety needs		HR	N	Requirements management tool (Sphinx-needs) is used for traceability between all requirements, specifications and tests. All requirements in 61508 are mapped to requirements specified in this documentation.	See FSD001: Documentation structure, 61508-1, 61508-2, 61508-3.
4	Computer aided specification tools to support appropriate techniques/measures above	B.2.4	HR	N	Requirements management tool (Sphinx-needs) is used together with Git for version control. Redmine for issue tracking, doxygen as software documentation tool.	See FSD001: Documentation structure.

61508-3 Table A.2: Software design and development: software architecture design (see 7.4.3)

Technique/measure	See 61508-7	SIL3	Deviation	Comment	Use
Fault detection and diagnosis	C.3.1	HR	N	Two redundant processors monitoring each other. Watch dogs. Sanity checks / assertions. Active pulses to enable output power.	See source code and HW circuit diagram.
Error detecting and correcting codes	C.3.2	R	N	Communication errors are detected and handled (ignored).	Cryptograph hash functions (8 round chaskey), 32 bit CRC, sanity checks, boundary checks. See source code.
Failure assertion programming	C.3.3	R	N	Preconditions are asserted at the top in all function. Postconditions are asserted at the end of all functions. Return values are asserted for all function calls that have return values. If an assertion fails, the system enters safe state.	See source code.
Diverse monitor techniques (with independence between the monitor and the monitored function in the same computer)	C.3.4	R
Diverse monitor techniques (with separation between the monitor computer and the monitored computer)	C.3.4	R
Diverse redundancy, implementing the same software safety requirements specification	C.3.5
Functionally diverse redundancy, implementing different software safety requirements specification	C.3.5	R
Backward recovery	C.3.6
Stateless software design (or limited state design)	C.2.12	R	N
Re-try fault recovery mechanisms	C.3.7
Graceful degradation	C.3.8	HR	N	Implemented	When faults are detected in subsystems, there are options to shut down only that function. Examples are: several nodes, only one shut down xPulses/OSSD/simultanency errors gives error codes which can trigger configurable graceful shutdown
Artificial intelligence - fault correction	C.3.9	NR	N	Not used.	Not used.
Dynamic reconfiguration	C.3.10	NR	N	Not used.	Not used.
Modular approach	Table B.9	HR	N	SW modules are used.	See source code.
Use of trusted/verified software elements (if available)	C.2.10	HR	N/A	All code in the software safety application is designed/developed from scratch, thus this section is not applicable.
Forward traceability between the software safety requirements specification and software architecture	C.2.11	HR	N	Software safety requirements are specified as sphinx-needs, and have full forward and backward traceability.	See FSD304: System architecture description and FSD310: Software Flow Charts.
Backward traceability between the software safety requirements specification and software architecture	C.2.11	HR	N	Software safety requirements are specified as sphinx-needs, and have full forward and backward traceability.	See FSD304: System architecture description and FSD310: Software Flow Charts.
Structured diagrammatic methods	C.2.1	HR	N	Flowcharts are used during software design work. Further the purpose of many of the methods described in 61508-7, section C.2.1, are to explain this. Function blocks are also documented in detail, which are the main interface to real world. Software requirements are split into specific detailed requirements as sphinx-needs, with easily testable and verifiable pass criteria.	See FSD304: System architecture description and FSD310: Software Flow Charts.
Semi-formal methods	Table B.7	HR	N	Yes, see B.7.	See table A.4.
Formal design and refinement methods	B.2.2, C.2.4	R	Y	Mathematical models is not considered relevant for this small type of embedded software. In addition, the concurrency model is extremely simple, with very strict layered structure. There are no threads.
Automatic software generation	C.4.6	R	N/A	Automatic software generation tools not used.
Computer-aided specification and design tools	B.2.4	HR	N	Software safety requirements are specified as sphinx-needs, and have full forward and backward traceability.	See FSD001: Documentation structure.
Cyclic behaviour, with guaranteed maximum cycle time	C.3.11	HR	N	Critical safety calculations are done at either 16kHz or 1kHz (fast or slow ticks). CPUs have HW timer checks. If time between ticks or average frequency deviates from specification, unit is shut down.	See module tests.
Time-trigger architecture	C.3.11	HR	N	There is no scheduler (no multitasking/threads) in the SW. Critical safety calculations are done at either 16kHz or 1kHz (fast or slow ticks). CPUs have HW timer checks. If time between ticks or average frequency deviates from specification, unit is shut down.	See module tests.
Event-driven, with guaranteed maximum response time	C.3.11	HR	N	The extremely strict tick setup gives guaranteed maximum response time.	See module tests.
Static resource allocation	C.2.6.3	HR	N	Heap is completely forbidden/not used. All memory and variables are statically allocated by linker (ie at startup). The same applies for others resources, like GPIO-pins and peripherals.
Static synchronisation of access to shared resources	C.2.6.3	R	N	Sharing data between interrupts is strictly defined.

61508-3 Table A.3 - Software design and development - support tools and programming language (see 7.4.4)

No.	Technique/measure	See 61508-7	SIL3	Deviation	Comment	Use
1	Suitable programming language	C.4.5	HR	N	C subset. Pre and post conditions are asserted in all functions.	Used for the source code
2	Strongly typed programming language	C.4.1	HR	N	C with the MISRA-C subset can be considered to be strongly typed.	Used for the source code
3	Language subset	C.4.2	HR	N	MISRA-C.	Used for the source code
4a	Certificated tools and certified translators	C.4.3	HR	N	No tools except for the compiler (class T3) have responsibility to construct parts of the software. The large number of auxiliary tools (versioning, analyzers, editors, …) are not as critical since they do not have any impact on the code (class T2).	GCC for Cortex M3 is used. It is used in numerous safety developments.
4b	Tools and translators: increased confidence from use	C.4.4	HR	N	See above	GCC for Cortex M3 is used. It is used in numerous safety developments.

61508-3 Table A.4 - Software design and development - detailed design (see 7.4.5 and 7.4.6)

No.	Technique/measure	See 61508-7	SIL3	Deviation	Comment	Use
1a	Structured methods	C.2.1	HR	N	Flowcharts and finite state diagrams are used during software design work. The level of detail in the design model is such that it is actually possible to implement all logic directly from the model. Hardware close thing, such as how to configure GPIO etc is defined by circuit diagram.	See design model.
1b	Semi-formal methods	Table B.7	HR	N	Yes, see B.7.	See table B.7.
1c	Formal design and refinement methods	B.2.2, C.2.4	R	Y	Mathematical models is not considered relevant for this small type of embedded software. In addition, the concurrency model is extremely simple, with very strict layered structure. There are no threads.
2	Computer aided design tools	B.3.5	HR	N	Software safety requirements are specified as sphinx-needs, and have full forward and backward traceability.	See table B.7.
3	Defensive programming	C.2.5	HR	N	Uses both intrinsically error-safe and fault tolerance techniques. Input data from external interfaces is thoroughly checked for errors.	See design model and source code.
4	Modular approach	Table B.9	HR	N	See table B.9.	See table B.9.
5	Design and coding standards	C.2.6, Table B.1	HR	N	See table B.1.	See table B.1.
6	Structured programming	C.2.7	HR	N	Standard practice.	See source code.
7	Use of trusted/verified software modules and components (if available)	C.2.10, C.4.5	HR	N/A	No existing modules will be used.
8	Forward traceability between the software safety requirements specification and the software design	C.2.11	HR	N	Which software requirements that each flowchart (function) in the model fulfills, are listed in the design model. Software safety requirements are specified as sphinx-needs, and have full forward and backward traceability.	See design model.

61508-3 Table A.5: Software design and development - software module testing and integration (see 7.4.7 and 7.4.8)

	Technique/measure	See 61508-7	SIL3	Deviation	Comment	Use
1	Probabilistic testing	C.5.1	R	N	Continuously done during development, and also in integration tests.	See integration tests
2	Dynamic analysis and testing	B.6.5, Table B.2	HR	N	See table B.2.	See table B.2.
3	Data recording and analysis	C.5.2	HR	N	Tests and logs are part of the safety assessment for this product.
4	Functional and black-box testing	B.5.1, B.5.2, Table B.3	HR	N	Also see table B.3.	integration tests
5	Performance testing	Table B.6	HR	N	See table B.6.	See table B.6.
6	Model based testing	C.5.27	HR	Y	Simplicity and low level nature of this product does not justify using model based testing.
7	Interface testing	C.5.3	HR	N	Part of integration tests	integration tests
8	Test management and automatic tools	C.4.7	HR	N	Integration tests have a automatic tool to test the unit.	See FSD124: GUI and Compiler function requirements, module tests and integration tests and FSD150: Validation tests of modes, power supply, and configuration.
9	Forward traceability between the software design specification and the module and integration test specifications	C.2.11	HR	N	Software safety requirements are specified as sphinx-needs, and have full forward and backward traceability.	See FSD124: GUI and Compiler function requirements, module tests and integration tests, FSD150: Validation tests of modes, power supply, and configuration, FSD304: System architecture description and FSD310: Software Flow Charts.
10	Formal verification	C.5.12	R	Y	Formal verification does not map well to this type of product.

61508-3 Table A.6: Programmable electronics integration (hardware and software) (see 7.5)

#	Technique/measure	See 61508-7	SIL3	Deviation	Comment	Use
1	Functional and black-box testing	B.5.1, B.5.2, Table B.3	HR	N	Also see table B.3.	See FSD124: GUI and Compiler function requirements, module tests and integration tests, FSD150: Validation tests of modes, power supply, and configuration.
2	Performance testing	Table B.6	HR	N	See table B.6.	See table B.6.
3	Forward traceability between the system and software design requirements for the hardware/software integration and the hardware/software integration test specifications	C.2.11	HR	N	Software safety requirements are specified as sphinx-needs, and have full forward and backward traceability.	See “Software safety requirements specification”, FSD124: GUI and Compiler function requirements, module tests and integration tests, FSD150: Validation tests of modes, power supply, and configuration, FSD300: Software Module Tests.

61508-3 Table A.7: Software aspects of system safety validation (see 7.7)

#	Technique/measure	See 61508-7	SIL3	Deviation	Comment	Use
1	Probabilistic testing	C.5.1	R	N	Continuously done during development, and also in integration tests.	integration tests
2	Process simulation	C.5.18	HR	N	Tests performed on a stand alone prototype system, equivalent to the final product.	The unit is heavily tested without connecting it to a real (dangerous) application.
3	Modelling	Table B.5	HR	N	Testing is made on broken down basic functionality to model the different combinations of functionality	See integration tests
4	Functional and black-box testing	B.5.1, B.5.2, Table B.3	HR	N	Also see table B.3	See integration tests
5	Forward traceability between the software safety requirements specification and the software safety validation plan	C.2.11	HR	Y	Skipped according to clause 7.7.2.1 as small application where all software aspects can be covered when doing validation test on the complete system.
6	Backward traceability between the software safety validation plan and the software safety requirements specification	C.2.11	HR	Y	Skipped according to clause 7.7.2.1 as small application where all software aspects can be covered when doing validation test on the complete system.

61508-3 Table A.8: Modification (see 7.8)

No.	Technique/measure	See 61508-7	SIL3	Deviation	Comment	Use
1	Impact analysis	C.5.23	HR	N	As described in FSD002 Management of functional safety: Software configuration management. This is also part of the “Modification of safety function” document.
2	Reverify changed software module	C.5.23	HR	N	Reverify according to the verification plan and the techniques in table A.5. This is also part of the “Modification of safety function” document.
3	Reverify affected software modules	C.5.23	HR	N	Reverify according to the verification plan and the techniques in table A.5, if required. This is also part of the “Modification of safety function” document.
4a	Revalidate complete system	C.5.23	HR	N	Revalidate according to the validation plan and the techniques in table A.6 and A.7, if required. This is also part of the “Modification of safety function” document.
4b	Regression validation	C.5.25	HR		Handled in the “Modification of safety function” document.
5	Software configuration management	C.5.24	HR	N	Managed with GIT.
6	Data recording and analysis	C.5.2	HR	N	Managed with GIT.
7	Forward traceability between the software safety requirements specification and the software modification plan (including reverification and revalidation)	C.2.11	HR	N	Handled in the “Modification of safety function” document. FSD002.
8	Backward traceability between the software modification plan (including reverification and revalidation) and the software safety requirements specification	C.2.11	HR	N	Handled in the “Modification of safety function” document. FSD002.

61508-3 Table A.9: Software verification (see 7.9)

#	Technique/measure	See 61508-7	SIL3	Deviation	Comment	Use
1	Formal proof	C.5.12	R	Y	Impractical in full variability languages.
2	Animation of specification and design	C.5.26	R	Y	Overkill for an application of this limited size.
3	Static analysis	B.6.4, Table B.8	HR	N	See table B.8.	See table B.8.
4	Dynamic analysis and testing	B.6.5, Table B.2	HR	N	See table B.2.	See table B.2.
5	Forward traceability between the software design specification and the software verification (including data verification) plan	C.2.11	HR	N	Tests and verification shall be traceable.
6	Backward traceability between the software verification (including data verification) plan and the software design specification	C.2.11	HR	N	Tests and verification shall be traceable.
7	Offline numerical analysis	C.2.13	HR		Not applicable.
	Software module testing and integration	Table A.5
	Programmable electronics integration testing	Table A.6
	Software system testing (validation)	Table A.7

61508-3 Table A.10: Functional safety assessment (see clause 8)

#	Assessment/technique	See 61508-7	SIL3	Deviation	Comment	Use
1	Checklists	B.2.5	R		RISE
2	Decision/truth tables	C.6.1	R
3	Failure analysis	Table B.4	HR
4	Common cause failure analysis of diverse software (if diverse software is actually used)	C.6.3	HR
5	Reliability block diagram	C.6.5	R
6	Forward traceability between the requirements of Clause 8 and the plan for software functional safety assessment	C.2.11	HR

61508-3 Table B.1: Design and Coding Standards (referenced by table A.4)

#	Technique/measure	Ref	SIL3	Deviation	Comment	Use
1	Use of coding standard to reduce likelihood of errors	C.2.6.2	HR	N	MISRA-C.	See source code.
2	No dynamic objects	C.2.6.3	HR	N	No dynamic objects, no heap allocator exists in this safety software.
3a	No dynamic variables	C.2.6.3	HR	N	No dynamic variables, no heap allocator exists in this safety software.
3b	Online checking of the installation of dynamic variables	C.2.6.4	HR	N/A	No dynamic variables used.
4	Limited use of interrupts	C.2.6.5	HR	N	Very limited use of interrupts.	See design model and source code.
5	Limited use of pointers	C.2.6.6	HR	N	Regulated by MISRA-C. Very limited use of pointers in safety software.	See design model and source code.
6	Limited use of recursion	C.2.6.7	HR	N	No recursion at all.	See design model and source code.
7	No unstructured control flow in programs in higher level languages	C.2.6.2	HR	N	Prohibited by MISRA-C.	See source code and Software integration test regarding MISRA compliance.
8	No automatic type conversion	C.2.6.2	HR	N	Not used	See source code.

61508-3 B.2: Dynamic Analysis and Testing (referenced by tables A.5 and A.9)

#	Technique/measure	Ref	SIL3	Deviation	Comment	Use
1	Test case execution from boundary value analysis	C.5.4	HR	N	In module testing.	See FSD300: Software Module Tests and FSD304: System architecture description.
2	Test case execution from error guessing	C.5.5	R	N	Error guessing as test method applied.	See FSD300: Software Module Tests and FSD304: System architecture description.
3	Test case execution from error seeding	C.5.6	R	N	Error seeding as test method applied.	See FSD300: Software Module Tests and FSD304: System architecture description.
4	Test case execution from model-based test case generation	C.5.27	HR	N	PC application that generates many 10 thousand tests is used.	See FSD124: GUI and Compiler function requirements, module tests and integration tests.
5	Performance modelling	C.5.20	R	N	Online check of performance need	See FSD300: Software Module Tests and FSD304: System architecture description.
6	Equivalence classes and input partition testing	C.5.7	R	Y	The limited (and coherent) set of input data does not justify this test method.
7a	Structural test coverage (entry points) 100%	C.5.8	HR	N	Applied.	See FSD124: GUI and Compiler function requirements, module tests and integration tests and FSD150: Validation tests of modes, power supply, and configuration.
7b	Structural test coverage (statements) 100%	C.5.8	HR	N	Applied.	See FSD124: GUI and Compiler function requirements, module tests and integration tests and FSD150: Validation tests of modes, power supply, and configuration.
7c	Structural test coverage (branches) 100%	C.5.8	HR	N	Applied.	See FSD124: GUI and Compiler function requirements, module tests and integration tests and FSD150: Validation tests of modes, power supply, and configuration.
7d	Structural test coverage (conditions, MC/MD) 100%	C.5.8	R	Y	Done as part of design review.

61508-3 Table B.3 - Functional and black-box testing (referenced by tables A.5, A.6 and A.7)

#	Technique/measure	Ref	SIL3	Deviation	Comment	Use
1	Test case execution from cause-consequence diagrams	B.6.6.2	R	Y	Only done as part of general test setups.
2	Test case execution from model-based test case generation	C.5.27	HR	N	PC application that generates many 10 thousand tests is used.	See FSD124: GUI and Compiler function requirements, module tests and integration tests.
3	Prototyping/animation	C.5.17	R	Y	Experience from other products is used. Integration tests are performed as black box tests from the end user perspective. Customer criteria are modeled as market requirements, which tests are performed against.	See FSD124: GUI and Compiler function requirements, module tests and integration tests.
4	Equivalence classes and input partition testing, including boundary value analysis	C.5.7, C.5.4	HR	Y	The limited (and coherent) set of input data does not justify this test method in a general case. Boundary values (time) is analysed in requirements and verified.	See FSD300: Software Module Tests.
5	Process simulation	C.5.18	R	N	Several tests make with simulated applications.	tested with input/outputs to sensors/gates, but not applied in a machine. See integration tests.

61508-3 Table B.4 - Failure analysis (referenced by table A.10)

#	Technique/measure	Ref	SIL3	Deviation	Comment	Use
1a	Cause consequence diagrams	B.6.6.2	R		RISE
1b	Event tree analysis	B.6.6.3	R		RISE
2	Fault tree analysis	B.6.6.5	R		RISE
3	Software functional failure analysis	B.6.6.4	R		RISE

61508-3 Table B.5 - Modelling (referenced by table A.7)

#	Technique/measure	Ref	SIL3	Deviation	Comment	Use
1	Data flow diagrams	C.2.2	R	N		See FSD310: Software Flow Charts.
2a	Finite state machines	B.2.3.2	HR	N	Software state machines are modeled in detail. The tool sm_gen also generates mermaid state diagrams for verification. Stateful function blocks are specified using state machine diagrams, which is directly translated to code.	See FSD304: System architecture description and FSD310: Software Flow Charts, and FSD124: GUI and Compiler function requirements, module tests and integration tests.
2b	Formal methods	B.2.2, C.2.4	R	Y	The low complexity of the software does not justify using formal methods. See 2a.	N/A.
2c	Time Petri nets	B.2.3.3	HR	Y	Not used. See 2a.	N/A.
3	Performance modelling	C.5.20	HR	N	State and timing diagrams to prove the response time performance of the system. Processing time is measured during normal operation. Processing time is correlated with the complexity of the user configuration. If the user configuration is too complex and does not have enough time to run, the system will enter safe state.	See FSD310: Software Flow Charts.
4	Prototyping/animation	C.5.17	R	N	Done during development for new functionality. Product is already tested in real applications.
5	Structure diagrams	C.2.3	R

61508-3 Table B.6 - Performance testing (referenced by tables A.5 and A.6)

#	Technique/measure	Ref	SIL3	Deviation	Comment	Use
1	Avalanche/stress testing	C.5.21	HR	N	Tests with changing data extremely often are performed.	See FSD300: Software Module Tests, FSD124: GUI and Compiler function requirements, module tests and integration tests, and FSD150: Validation tests of modes, power supply, and configuration.
2	Response timings and memory constraints	C.5.22	HR	N	Response time is measured during normal operation. Memory is statically allocated.	See FSD319: Software Safety Requirements Specification.
3	Performance requirements	C.5.19	HR	N	Several requirements regarding this. All tested and verified.	See FSD319: Software Safety Requirements Specification, FSD300: Software Module Tests, FSD124: GUI and Compiler function requirements, module tests and integration tests, and FSD150: Validation tests of modes, power supply, and configuration.

61508-3 Table B.7 - Semi-formal methods (referenced by tables A.1, A.2 and A.4)

#	Technique/measure	Ref	SIL3	Deviation	Comment	Use
1	Logic/function block diagrams	See note in standard	HR	N	Flowcharts show the execution in software, and also which modules that exist.	See FSD310: Software Flow Charts.
2	Sequence diagrams	See note in standard	HR	N	As not threads, sequence diagrams are not suitable.	See FSD310: Software Flow Charts.
3	Data flow diagrams	C.2.2	R	N	Applied.	See FSD310: Software Flow Charts.
4a	Finite state machines/state transition diagrams	B.2.3.2	HR	N	Used for all functional blocks and state machines.	See FSD124: GUI and Compiler function requirements, module tests and integration tests and FSD310: Software Flow Charts.
4b	Time Petri nets	B.2.3.3	HR	Y	Due to the simplicity of the safety application, this is not considered necessary.	N/A.
5	Entity-relationship-attribute data models	B.2.4.4	R
6	Message sequence charts	C.2.14	R
7	Decision/truth tables	C.6.1	HR	N	Used for function blocks.	See FSD124: GUI and Compiler function requirements, module tests and integration tests.
8	UML	C.3.12	R	Y	UML is more appropriate for big object oriented designs (C++/Java etc). This embedded design uses C with a functional design.	N/A.

61508-3 Table B.8 - Static analysis (referenced by table A.9)

#	Technique/measure	Ref	SIL3	Deviation	Comment	Use
1	Boundary value analysis	C.5.4	HR	N	As in C.5.4.	See FSD300: Software Module Tests.
2	Checklists	B.2.5	R	N	Various checklists used.	Several used, mainly from 61508, but also documented in manual regarding verification of application.
3	Control flow analysis	C.5.9	HR	N	CPPCheck and doxygen is used.	See CPPCheck and doxygen reports.
4	Data flow analysis	C.5.10	HR	N	Compiler and CPPCheck	See compiler and CPPCheck reports.
5	Error guessing	C.5.5	R	N	As in C.5.5.	See FSD124: GUI and Compiler function requirements, module tests and integration tests, FSD150: Validation tests of modes, power supply, and configuration, FSD300: Software Module Tests.
6a	Formal inspections, including specific criteria	C.5.14	HR	N	Covered by the other verification activities: Planning and preparation are covered by the Management of functional safety. Inspection, rework and followup are covered by the design reviews.	See FSD002: Management of functional safety.
6b	Walk-through (software)	C.5.15	HR	N	This is done during discussions between the code/design reviewer and the designer after the code/design has been reviewed. The activity to perform a code and design review is handled in “Software verification plan”.
7	Symbolic execution	C.5.11	HR	Y	Due to the limited size of this application and the extensive use of other dynamic and static testing, this method is not considered beneficial.
8	Design review	C.5.16	HR	N	Continously done during development.	See FSD002: Management of functional safety.
9	Static analysis of run time error behaviour	B.2.2, C.2.4	R	Y	Due to the limited size of this application and the extensive use of other dynamic and static testing, this method is not considered beneficial.
10	Worst-case execution time analysis	C.5.20	R	N	Defined by requirements and tested.	See FSD319: Software Safety Requirements Specification and FSD310: Software Flow Charts.

61508-3 Table B.9 - Modular approach (referenced by table A.4)

#	Technique/measure	Ref	SIL3	Deviation	Comment	Use
1	Software module size limit	C.2.9	HR	N	The application is quite small and simple, and modules are therefore very limited in size.	See FSD310: Software Flow Charts.
2	Software complexity control	C.5.13	HR	N	A function/module that becomes too large is a good indication that it is too complex. It is then split in several functions/modules. Complexity is also controlled by RAM and flash constraints.	See FSD310: Software Flow Charts.
3	Information hiding/encapsulation	C.2.8	HR	N	Standard practice. As in C.2.8. Functions that are not to be reached from outside the module is “static” declared, and not part of header-file. Some variables are declared globally, but usage is limited.	See design and source code.
4	Parameter number limit/fixed number of subprogram parameters	C.2.9	R	N	As “C” does not work well with huge parameter lists, this is handled at the language level. Functions which require many parameters are be split into several functions, or use a struct to pass parameters.	See source code.
5	One entry/one exit point in subroutines and functions	C.2.9	HR	Y	One entry point: yes. Code analysis shows that writing code with only one exit point makes much more error prone code, so this requirement is considered to be wrong for “C”. Ie, for deeply nested if-statements instead of a simple return. However, early-exit is clearly shown and documented.	See source code and Software integration test regarding MISRA compliance.
6	Fully defined interface	C.2.9	HR	N	Standard practice. As in C.2.9.	See source code.