dipl.-ing. jörg hermes - asqf...improvements: 1. increasing requirement types understanding § what...

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


© 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


What are the benefits to invest in safety requirementsengineering?


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



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 ?


Source: © beeboys

Which are the 3 most frequent safety requirements challenges?


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


© hikdaigaku86 – Fotolia.com

© Anatoly Maslennikov- Fotolia.com

© Anatoly Maslennikov- Fotolia.com

How to improve: Proper management of responsibilities


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


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


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


§ 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


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


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.


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


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


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“


<[componentof the

subjectmatter]>

will

should

shall

bedesignedin a way

[condition]

Environmental

<object> can beoperated

<characteristic>

[<qualifier]<value>


<[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.


How to improve: Elicitation of safety requirements withina given design decision


§ 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.


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.



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?


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


§ 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


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.


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!


dipl.-ing. jörg hermes - asqf...improvements: 1. increasing requirement types understanding § what...

Documents