Dipl.-Ing. Jörg Hermes
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 2
Who is the lecturer?
3Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016
• Education: Information technology• Study: Electrical engineering• Domain experience: Medical devices, automotive • Professional experience: >15 years of safety critical product development• Own company HSQ: Founder, since 2012, 1 employee 2013
4Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016
© F
elix
Jor
k-
Foto
lia.c
om
Consulting••Functional safety processes, methods
••Quality management processes, methods
Contribution••Functional safetymanagement
••Functional safetyengineering
••System engineering
Training / Mentoring••Standards
••Processes
••Methods
••Techniques
5Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016
What are the benefits to invest in safety requirementsengineering?
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 6
Investment benefits
Company level
Reduction of product
safety risks
Increase of safety
competence
Project level
Planning
Reduction of elicitation
efforts
Improvement regarding
planning commitments
Development
Reduction of design
efforts
Faster stabilization of
safety functions
Testing
Reduction of test case
creation efforts
Increase in the test
goal evidence
Supporting processes
Reduction of change
management efforts
Safety case
Easier safety case
argumentation
Reduction of creation
efforts
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 7
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 8
Source: © yahyaikiz – fotolia.com
Benefits
Effortreduction
Improvementregardingplanning
commitments
Reduction ofproduct
safety risks
Source: © Brad Thompson – fotolia.com
Source: © Schlierner – fotolia.com
Where to invest for the greatest benefit ?
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 9
Source: © beeboys
Which are the 3 most frequent safety requirements challenges?
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 10
Imprecise separation of requirements engineering responsibilities
Deficient description of requirements resulting in an unclear goal of a requirement
The wrong interpretation that a requirement has to be developed
solution-independently in every case
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 11
© hikdaigaku86 – Fotolia.com
© Anatoly Maslennikov- Fotolia.com
© Anatoly Maslennikov- Fotolia.com
How to improve: Proper management of responsibilities
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 12
Functionalinterface &
characteristics
Tier 1 Tier 2
Competence: ECU incl. BSWCompetence: E/E architectureincl. application SW
The ECU needs a secondary safety controller with ASIL C integrityRequires a specific design
The APPL-SW shall get the PWM converted speed signal with ASIL C
imprecisefunctionalinterface & design decision
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 13
Improvements:
1. Increasing requirement types understanding
§ What kind of requirement type can be used for behaviour?
§ What kind of requirement type can be used for characteristics?
2. Elicitation of requirements according to the functional interfaces
§ Responsible person for E/E-architecture describes functional and non-functional interfaces of the system element behaviour in accordance to a rule set.
§ Responsible person for ECU and BSW derives functional and non-functionalrequirements in accordance to the interfaces
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 14
Requirementtypes
Functionalrequirements
Standaloneactivity
If the ECU shall execute an activity without external ECU
involvement
Interaction activity
If the ECU and APPL. SW needsa functional interaction with a
user
Interface activityIf the Appl. SW shall execute an activity based on a BSW trigger
or event
Non-functionalrequirements
Property characteristics
Environmental characteristics
If the design of a technicalcharacteristics is in the
responsibility of the supplier
Processcharacteristics
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 15
§ Identification of signal andactor error handling by theAutosar error handlingclasses
§ Standardization of therequirement types accordingto the Autosar error handlingclasses
§ Requirements development supported by requirementtypes checklists to reducerisk of missing requirements
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 16
Signal 1
Signal 2
1oo2D
Normaloperation
Safe state
Degradedoperation
Core 1
Core 2
Compare
Normaloperation
Safe state
Appl. SW BSW
How to improve: Writing meaningful safety requirements
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 17
Examples:
§ The speed signal is required with an ASIL C integrity.
§ The device shall measure current and internal temperature for internal calculation with ASIL B integrity.
§ The result shall be compared with 18094 with ASIL B integrity.
§ The ECU shall detect single-point faults in storage and addressing ofprogram code, e.g. by ECC, with ASIL B integrity.
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 18
Why is it so difficult to write meaningful safety requirements?
§ People are not aware of the consequences, if requirements are not meaningful
§ The workload of the safety manager is too high and he is also expected to write requirements
§ An established supporting process or workflow for the derivation ofrequirements does not exist
§ One already has a solution in mind
§ The knowledge about the elicitation of meaningful requirements ismissing
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 19
Improvement: Usage of a standardized requirements stencil
<condition> <system>
will
should
shall
be able to
Provide<actor> withthe ability to
-
<processverb> [object]
Standalone activitiy User Interaction activity Interface activity
20Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016
What shall thisbox do ?
y=f(x)
Property stencil Environmental
stencil
Process
stencil
Quality requirements X
Technologyrequirements
X X
Human machineinterface requirements
X
Other deliveries X
Project task /methodsrequirements
X X
Contract requirements X X
Source: Sophist „Schablonen für alle Fälle“
21Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016
<[componentof the
subjectmatter]>
will
should
shall
bedesignedin a way
[condition]
Environmental
<object> can beoperated
<characteristic>
[<qualifier]<value>
22Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016
<[condition]>
will
should
shall
be
Property
<subjectmatter><characteristic> [<qualifying
expression>] <values>
Tier 1: E/E-architecture behaviour:
§ In case that the receiver of the message "message name" detects a failure, theECU shall debounce the faulty message.
§ The message debouncing shall be designed in a way that the confirmation of a faulty message is faster than <xx> ms.
§ In case that the ECU debounces a faulty message, the ECU shall work with thelast correct message.
§ In case that the faulty message is confirmed, the ECU shall open the contactorfaster than <xx> ms in a defined worst case situation.
Tier 1: Interface requirements for ECU + BSW supplier
§ The CAN message sending shall be designed in a way that a "message repetition" can be detected.
§ The CAN message sending shall be designed in a way that "message corruption" with a HD=3 can be detected.
§ The CAN message sending shall be designed in a way that "message delay" of <xx> ms can be detected.
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 23
How to improve: Elicitation of safety requirements withina given design decision
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 24
§ Feedback of developers aboutreasons:¡ Unspecific requirements are
the way to write solutionindependent requirements
¡ Unspecific requirements do not interfere with thedeveloper‘s solution finding
¡ The main thing is that I do write requirements. Betterbad ones than none at all.
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 25
Adhere to the sequence: first functional requirementsthen non-functional requirements.
§ When I am on a specific abstraction level (e.g. black box system level) I look at the already defined/derived interfacesand then the first thing I formulate are questions like: „Whatis going to happen at the output interface, if…?
§ Did I consider all defined/derived interfaces within thefunctional requirements development?
§ After I completed all these, I take care of the non-functionalrequirements.
§ I formulate characteristics requirements of a function or a defined/derived interface.
§ I formulate expectations to a function that has to bederived yet.
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 26
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 27
TSR 1:
The ECU shall detect faults in safety-related non-volatile data with ASIL C integrity.
TSR 1: Functional requirement
In case that the ECU detects a confirmed safety-related NV datafault, the ECU shall inhibit the CAN communication. ASIL C
TSR 2: Non-functional requirement
The NV RAM fault detection shall bedesigned in a way, that 99% of all safety-related faults shall bedetected. ASIL C
What is the required behaviour ?
What is required on a more
detailed level?
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 28
Guiding Questions:
What shall ECU2 do in case of a wrong CAN
communication?
What does wrong CAN communication mean?
Create specific functionaland non-functional safetyrequirements by stencilapproach in respect of
existing interfaces
The speed signalshall be protectedagainst disturbancewith ASIL C integrity
Identification ofwhat is
important on thisabstraction level
Improvements
Starting point: Target point:
Identification ofrequirements that
need to be improved
Conclusion and next steps
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 29
§ The investment into§ Standardization of functional
interfaces§ Usage of requirements stencils
for different requirementstyles
§ Increasing awareness tointegrate design decisions in the requirements development
§ leads to§ Effort reduction during the
development§ Improvement regarding the
planning commitments§ Reduction of safety risks
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 30
Source: © beeboys
Source: © yahyaikiz – fotolia.com
Source: © Brad Thompson – fotolia.com
Source: © Schlierner – fotolia.com
If you are interested in a moredetailed discussion on this topic, you might want to submit a FS requirements session to the nextFS-barcamp / RE-barcamp in 2017.
Visit http://fs-barcamp.com toget all the information.
Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016 31
Among the first 10 subscribers tomy Online Safety Library therewill be a prize draw. Win a 45 minutes Q&A session for yourteam and get your questions on safety requirements answered in a webinar setting.
Subscribe at http://savetimeandsavelives.com
Thank you for your attention!
32Dipl.-Ing. Jörg Hermes - ASQF Fachgruppen Treffen - Oktober 2016