Requirements from the perspective of functional safety · 2020-03-20 · Requirements from the perspective of functional safety ASQF SW-Test: ASQF Requirements Day 2016 Marc Henke,

Requirements from the perspective of functional safety

ASQF SW-Test: ASQF Requirements Day 2016Marc Henke, Braunschweig, 2016-09Acknowledgments to David Dieckow (IAV) and Matthias Bruns (ZF).

ISO26262

IAV

What about?Agenda

© IAV · 2016-09 · VD-D2 · Marc Henke · 2016-09-28_ASQF_RequirementsDay_BS_Henke__FunctionalSafety_and_Requirements.pptx 2

• Functional safety & requirements in general

• Layers of abstraction

• Decomposition & allocation

• Requirements for requirements

• Traceability

• And what is around?

• “Thou shall not miss the failed test result”

• Discussion & open topics

IAV

OM

D

Safety requirements in ISO 26262Theoretic excursus


General handling of safety requirements in ISO 26262

8-6 Specification and management of safety requirements

The second objective is to ensure consistent management of safety requirements

throughout the entire safety lifecycle.

During the safety lifecycle, safety requirements are specified and detailed in a

hierarchical structure. The structure and dependencies of safety requirements used in

ISO 26262 are illustrated in Figure 8-2. The safety requirements are allocated or

distributed among the elements.

The management of safety requirements includes managing requirements, obtaining agreement on the requirements, obtaining commitments from those implementing

the requirements, and maintaining traceability.

� Interaction between requirements, concept and architecture!

Safety requirementson different levels of abstraction


Levels of abstraction

• SG: Safety goals (3-7)

Defining the safe system

• FSR: Functional Safety Requirements (3-8)

How do I want to achieve my safety goals?

Which functional allocation over the

systems/subsystems do I choose?

• TSR: Technical Safety Requirements on

System/Subsystem level (4-6)

Which technical solutions do I choose to fulfill

the functional safety requirements?

Which technical allocation do I choose for the

system/subsystem between HW and SW?

• HWSR: Hardware Safety Requirements (5-6)

• SWSR: Software Safety Requirements (6-6)ISO26262-8:2011, Figure 8-2

Choosing an adequate level of abstractionGood example from Bernhard Kaiser on VDA SYS 2012

5© IAV · 2016-09 · VD-D2 · Marc Henke · 2016-09-28_ASQF_RequirementsDay_BS_Henke__FunctionalSafety_and_Requirements.pptx

Decomposition & allocationof safety requirements


Decomposition: Decomposingsafety requirements according

to rules in Figure 9-2

(e.g. QM(B) + B(B))

Goal: Concentrating high effort

for high ASIL levels to dedicated

components / units and their

development

ISO26262-9:2011, Figure 9-2

IAV AK-P, 5_UAK5_Struktursynthese

Allocation: Mapping of safety requirements to structural blocks in safety architecture

Requirements towards requirementsin general

7

Compliance towards the general criteria:

• Adequacy – What is intended by the sponsor?

• Completeness – Is anything missing to fulfill the sponsor’s intention?

• Unambiguousness – Specified in clear words, leaving no doubt about the intention.

• Understandable – Understandable for the sponsor, for the developers, for the

testers, etc.

• Testable – To allow the check, if the realized system does perform according to the

specification.

• Internal consistency – The safety requirements do not contradict each other at this

level. In particular, no requirement contradicts itself.

• External consistency – The safety requirements do not contradict the surrounding

safety requirements at the other levels.

• Comprehensible – Origin and history of the requirement shall be documented.

© IAV · 2016-09 · VD-D2 · Marc Henke · 2016-09-28_ASQF_RequirementsDay_BS_Henke__FunctionalSafety_and_Requirements.pptx

ASPICE

ISO26262-8:2011, 8-6.4 � Good, that you have reviewed your reqs!

Requirements towards requirementsfrom functional safety’s point of view

8

Compliance towards the criteria of functional safety:

• Traceability upwards towards its origin,

Traceability downwards towards its refinement and/or realization in the designTraceability to the right side of the V-model into the test specification.

• Allocation of the corresponding ASIL level to each safety requirement.

• Allocation towards the components of the architectural design

Constraints in relation to the ASIL level:

• Notation: informal notation (A, B) or semi-formal notation (C, D)

Note: Informal aka textual, semi-formal with syntax & semantic e.g. requirements

building scheme or UML

• Verification: Walkthrough (A), Inspection (B, C, D), semi-formal verification (C, D)

Impact onto the safety architecture:

• Clarify early!


ISO26262-8:2011, 8-6.4

Traceability


How to plan traceability?

• Example of planning document

VDD-BP_CM_TracebilityConcept.docx

How to achieve traceability?

• Manually? E.g. traceability matrix in XLS

• Tool-supported? E.g. links in DOORS

• How to handle a model-based representation?

� And with how much effort for the creation of the links?

� And with how much effort for the maintenance of the links?

What is around?


Interaction of safety requirements with

• Safety analyses

– No direct linkage. Safety analyses may lead to safety measures,

and safety measures may be placed into safety requirements

• Decomposition

– Direct linkage. Decomposition is done on (safety) requirements and safety

requirements are linked. Where do you place your justification? And how to link?

Specialties of safety requirements

• Justification: Why did you choose to use this safety measure / architecture?

What is your justification for the level of independence sufficient for decomposition?

• Constraints: If your safety concept can only be realized in a restricted environment,

you can (and should) name your constraints towards the owner of the environment.

• Reflection on „something goes wrong“: The non-safety requirements mostly

concentrate on the positive functional path. Safety requirements sometimes have to

handle the path of negative outcome (failure with/without violation of safety goal).

• Disclaimer/non-goal: Make explicitly clear, what is outside the scope of your concept

And what about the results?


Justification:

• For the justification of compliance towards the top-level safety requirements

you have to consolidate the verification results of the refined safety requirements.

Violation:

• It would be uncool to overlook the one failed test results, that proves later to be

the responsible point of weakness leading to the violation of a safety goal.

Challenge:

• With the refinement over several levels of abstraction (and the handling of several

participating development partners), how do you ensure the adequate and completeverification?

Proposals for solutions to consolidate the verification results:

• A) Consolidation of verification results against their safety requirements “offline”, e.g.

aggregation of test results to test specs and mapping to safety requirements in XLS

• B) Importing of verification results into the test specification

followed by analysis of fulfillment in the requirements management tool

A) Consolidation of verification resultsagainst their safety requirements “offline”


Detailed test report mapped from result of test case towards req

� One way not to miss the one failed result. (At least at one requirement level)

Req ID Req Text TestResult TestSpec Chapter

SwR_2737 Battery Voltage Monitoring Start Green 2.4.2.1.2.0-1

SwR_2738 Battery Voltage Monitoring End Green 2.4.2.1.2.0-2

SwR_11322 Battery Voltage monitoring debouncing Red 2.4.2.1.2.0-5

ID SW-Release TestSpez Chapter TestResult Text Requirements Tracking ID Comments

<no> 0081 2.4.1.3.1.1 Red <FAILURE TEXT> SwR_836, SwR_837

CRQ_2082 event state DEH_EV_CAN_BUS_OFF not OK

Condensed summary of failed test results mapped from req to tracking ticket

Test spec Test resultrequirement

ticket

Script for mapping

If at least one test step is negative, than the

whole result for this req. is rated as failed.

B) Importing of verification results into the test specification


� It’s worth a shot, if you choose to import the test results into DOORS.

L3_HWIT-6: failedUups, found a bug in this example

Recursive following of

refinements until test spec including

test result

Easy following of direct links

Final manual rating from Safety Manager

Résumé


Take care

• to pick up the safety aspects in an early stage into the requirements

• to cumulate all requirements (and make them distinguishable via attribute) from

the points of view of: Functional behaviour, non-functional constraints, safety

aspects, security aspects, …

• to deal with the (combined) impact on the (integrated) architecture

• to nurse your requirements and their traceability throughout the whole lifecycle

• to validate the potential effectiveness in the design phase via safety analyses

• to verify the compliance of the implementation at the right side of the V-model

Good safety requirements do not lead alone to a safe system, but without good safety

requirements the evidence and - therewith - the justification of the chain of arguments

will be difficult.

� Go, Safety Requirements, go!

Thank you, vielen Dank, bedankt.

Marc Henke

IAV GmbH

Rockwellstraße 16, 38518 GifhornTelefon +49 5371 80-53618

[email protected]

www.iav.com


ww

w.v

ecto

rca

st.

co

m

Thanks to the contributing partners David Dieckow (IAV) and Matthias Bruns (ZF).

What is Functional Safety about?

16

Functional Safety according to ISO 26262

• “Absence of unreasonable risk due to hazards caused by malfunctioningbehaviour of E/E electrical/electronical safety-related systems”

• Including interaction of these systems… (safe parts do not guarantee safe systems)

• Focuses on the prevention of personal injuries (not damage to/loss of property)

• Focuses on the series development & production of passenger cars

• ISO 26262 has been released as specification in November 2011 (2Ed in 2018)

• To develop according the state of the art, following ISO 26262 can lead to a safe

product – safe in the sense of ISO 26262 –

• The safe product shall prevent/reduce personal injuries of passengers & harm of

environment

• By developing according to the guidelines of ISO 26262 one can argue well to have

developed with sufficient care and not acted grossly negligent


Safety requirementson different levels of abstraction 2/2

17

Safety Goals

• Fault Tolerant Time Interval

• Safe State

• … (more attributes requested)

Functional Safety Requirements

• Take care of fault detection and

failure mitigation

• Take care how to change the system state into a safe state (degradation concept)

Technical Safety Requirements

• Take care to address safety-related dependencies to other systems/items

• Take care to address the avoidance of latent faults

• Take care to address the quantitative hardware target values


ISO26262-3:2011, Figure 2-2

DXL inside DOORS


Usage of DOORS features: Specialized columns to import linked information

• Creation: DOORS > Analysis > Wizard: Inlinks, Object Identifier + TestResult, …

• Improvement of speed: DOORS > Tools > Support Tools > Convert Layout DXL to

Attribute DXL

• Update of improvement: DOORS > Tools > Refresh DXL Attributes

Working with DXL attributes

• For some activities, the exclusive edit to this formal module is necessary.

• Usage of external editor is recommended (line numbers to track errors, anti crash, …)

• View DXL: DOORS > Edit > Attributes > Edit: ‘Browse’ near ‘DXL attribute’ > Current

• Create DXL without Wizard: DOORS > Edit > Attributes > New: Activate ‘DXL

attribute’, ‘Browse’, choosing one of the examples, change to Current: Copy from

external editor

� Debugging is a pain, but the results can be valuable.

Hint from IAV Req Day: Try sodius.com

Choosing an adequate formulationGood example from Simon Fürst on Safety Workshop in BS


Documents

Requirements from the perspective of functional safety · 2020-03-20 · Requirements from the perspective of functional safety ASQF SW-Test: ASQF Requirements Day 2016 Marc Henke,