The document discusses challenges with current functional safety processes for embedded systems. It presents a new method for defining functional requirements that aims to address weaknesses in existing approaches. The key steps in the new method include: (1) defining the expected behavior and solution for each high-level requirement, (2) describing the behavior of the ECU and each function for all input states, and (3) determining the dominant behavior for any combination of inputs. This information is then used to automatically generate testable functional requirements and traceability diagrams. The goal is to reduce errors and verification effort compared to manual methods.

1. Smart Requirement Engineering
Unrestricted © Visioneer GmbH, 2022
v2.0

2. 2
FUNCTIONAL SAFETY PROCESS
The todays
Functional Safety
Process has
achieved great
improvements in
Safety!
But even if Functional
Safety is implemented,
SW errors often remain in
Embedded Systems!!!
Unrestricted © Visioneer GmbH, 2022

3. 3
ROOT CAUSE FOR MISSING SAFETY
It is NOT secured, that the Functional
Requirements resulting from the Functional
Safety Process are implemented
clearly (unambiguously),
with all necessary details (consistency)
and for any potential situation (completely)
The weakest point in the
safety process
“As this is so far an unsolved challenge in the SW Requirement Engineering Process generally”
Unrestricted © Visioneer GmbH, 2022

4. Supplement function
4
WHAT IS THE ROOT CAUSE ?
Any concurring requirement (that can be defined somewhere else in the Requirement
Specification) is affecting the safety of that function, e.g by disabling functions
Even if the defined requirements are safe implemented in a function, it is NOT excluded that:
ECU
Expected
behavior
Driver
HW Button
pressed
Passenger-Airbag
shall be off
Battery
Low
Battery
Don‘t trust HW
signals
Safety critical function
e.g:
Realtime-systems must often handle a high number of expected behaviors in parallel
→ This is currently not solved methodically in the functional safety process
Unrestricted © Visioneer GmbH, 2022

5. 5
EXAMPLE Airbag on/off LED
The following requirements are assigned to the
ECU:
Sys Req1 : If SWITCH_STATE is ON, then
the LED shall be ON
Sys Req2: In CAR_PRODUCTION_MODE
the LED shall be ON
Sys Req3: If BATTERY_STATE is LOW, then
the HW signals are not reliable
→ The challenge is to define all combinations completely and
unambiguously as functional requirements
The customer has designed the following system:
Unrestricted © Visioneer GmbH, 2022

6. 6
HOW IS IT SOLVED TODAY?
The requirement engineer often starts to create the combinations as text: E.g.
FuncReq1: If SWITCH_STATE is ON or CAR_PRODUCTION_MODE is ACTIVATED and BATTERY_STATE is FULL,
then the LED shall be ON
FuncReq2: If SWITCH_STATE is OFF and CAR_PRODUCTION_MODE is NOT ACTIVATED and BATTERY_STATE is
FULL, then the LED shall be OFF
FuncReq3: If CAR_PRODUCTION_MODE is NOT ACTIVATED and BATTERY_STATE is LOW,
then the LED shall be OFF
→ The verification if all IO combinations are clearly defined, can be performed
- manually e.g. with IO Tables
- automatically through simulation e.g. requirement in the loop tests
Unrestricted © Visioneer GmbH, 2022

7. 7
Manual verification with IO Table
The created requirements can also be described in a logic table
(x = don’t care → Outputs are independent from that state)
→ This allows a systematic or formal verification to detect missing combinations or logical errors
Unrestricted © Visioneer GmbH, 2022

8. 8
Verification results:
Error corrected: The combination of BATTERY_STATE is LOW and CAR_PRODUCTION_MODE is
ACTIVATED wasn’t logically covered (Note: X also covers ACTIVATED)
Manual verification with IO Table
Unrestricted © Visioneer GmbH, 2022

9. 9
Current Requirements Linking Method
Any System Requirement shall be linked with one or more Functional Requirements → Traceability verification is passed
Problem: This method is not identifying, if the requirements are just fulfilled
intentionally (brown links)
Unrestricted © Visioneer GmbH, 2022
FuncReq1: If SWITCH_STATE is ON or CAR_PRODUCTION_MODE
ACTIVATED and BATTERY_STATE is FULL, then the LED shall be ON
FuncReq2: If SWITCH_STATE is OFF and CAR_PRODUCTION_
MODE is NOT ACTIVATED and BATTERY_STATE is FULL, then the
LED shall be OFF
FuncReq3: If BATTERY_STATE is LOW, then the LED shall be OFF
Sys Req1 : If SWITCH_STATE is ON, then the LED
shall be ON
Sys Req2: In CAR_PRODUCTION_MODE the LED
shall be ON
Sys Req3: If BATTERY_STATE is LOW, then the HW
signals are not reliable
Links

10. To achieve these expectations, any FuncReq its relation to all SysReqs must be verified manually:
Full Requirements Linking Method
FuncReq1: If SWITCH_STATE is ON or CAR_PRODUCTION_MODE ACTIVATED and BATTERY_STATE is FULL,
then the LED shall be ON
contains
logically
excluded
Sys Req1 : If SWITCH_STATE is ON, then the LED
shall be ON
Sys Req2: In CAR_PRODUCTION_MODE the LED
shall be ON
Sys Req3: If BATTERY_STATE is LOW, then the
HW signals are not reliable
FuncReq2: If SWITCH_STATE is OFF and CAR_PRODUCTION_MODE is NOT ACTIVATED and BATTERY_STATE is FULL,
then the LED shall be OFF
Sys Req1 : If SWITCH_STATE is ON, then the LED
shall be ON
Sys Req2: In CAR_PRODUCTION_MODE the LED
shall be ON
Sys Req3: If BATTERY_STATE is LOW, then the
HW signals are not reliable
contains
logically excluded
logically
excluded
logically
excluded
→ Verification is passed
→ Verification is failed: Separate Req for SWITCH_STATE = OFF needed
Unrestricted © Visioneer GmbH, 2022

11. 11
Full Requirements Linking Method
11
FuncReq3: If BATTERY_STATE is LOW, then the LED shall be OFF
contradictory unclear
Sys Req1 : If SWITCH_STATE is ON, then the LED
shall be ON
Sys Req2: In CAR_PRODUCTION_MODE the LED
shall be ON
Sys Req3: If BATTERY_STATE is LOW, then the
HW signals are not reliable
logically excluded
→ Verification is failed:
1. SysReq1 is not excluding FuncReq3:
It is unclear which of the reqs is dominant and therefore it is unclear if the (silently?) chosen
behavior (LED shall be OFF) is correct
→ Separate Req about their dominance needed
2. It is unclear, if SysReq3 is really relevant for FuncReq3:
→ Clear assignment required, if it is relevant for this component (Switch)
3. It is unclear, if the (silently?) chosen behavior (LED shall be OFF) is the expected solution
→ Separate Req about its specific solution needed
Unrestricted © Visioneer GmbH, 2022

12. 12
CONCLUSION
Independently if the requirements are defined with or without MBSE:
There is a High-Danger of false or missing behavior-requirements, that undermine the
complete quality process, so the customer will find it ..
Many specification errors exist because with current tools, it is not clearly defined:
• what behavior and what solutions are expected for every input signal state separately
• what functional-entities are affected by what High-Level Requirement
• which of the parallel expected behaviors shall be dominant in any situation
Additionally, it is an enormous effort and an error-prone activity to perform the described process
manually due to the fact, that a high number of System- and Functional-Reqs are normal for ECUs.
Unrestricted © Visioneer GmbH, 2022

13. 13
SOLUTION
Visioneer GmbH has invented a very simple method, which is a script-based add
on for common RE Tools (e.g. Doors, Polarion, Word,..)
• which reduces the requirement engineering efforts drastically
• and which excludes the described weaknesses of the current process
fundamentally
→ The next pages explain the necessary steps of this innovative method
Unrestricted © Visioneer GmbH, 2022

14. 14
Step 1: HL Requirements its Solutions
Unrestricted © Visioneer GmbH, 2022
ReqID System Requirements Solution
Assigned Functional-
Entities
SysReq1 If SWITCH_STATE is ON, then the LED shall be ON Mode = SWITCH_STATE LED_Handler
SysReq2 In CAR_PRODUCTION_MODE the LED shall be ON
Mode =
CAR_PRODUCTION_MODE
LED_Handler
SysReq3 If BATTERY_STATE is LOW, then HW signals are not reliable Mode = BATTERY_STATE ECU
It must be clearly defined, what solution is expected for any HL Requirement
and by whom: Note: Blue text is created automatically
Red text is defined by the requirement engineer
Step 2: ECU Behavior Description
For any ECU_Mode its States, the Entry Condition, the Expected ECU Behavior, the ECU
Behavior Solutions and the Assigned Functions shall be defined
ECU Mode State Entry Condition Expected ECU Behavior ECU Behavior-Solution Assigned Funct.-
Entities
BATTERY_STATE
FULL BATTERY_STATE is FULL Full operation All functions shall be activated any Function
LOW BATTERY_STATE is LOW No HW signal shall be trusted Last valid HW signal shall be used any Function
Unrestricted © Visioneer GmbH, 2022

15. 15
Unrestricted © Visioneer GmbH, 2022
Step 3: FNCT- and assigned ECU-Behavior Description
In the same way for any FNCT_Mode of the Function LED_Handler shall be defined
FNCT Mode State Entry Condition Expected FNCT-Behavior FNCT Behavior Solution
CAR_PRODUCTION
_MODE
ACTIVATED
CAR_PRODUCTION_MODE is
ACTIVATED
LED shall show its el. connection LED_OUT shall be ON
NOT ACTIVATED
CAR_PRODUCTION_MODE is
NOT ACTIVATED
LED is a function of the switch state LED_OUT is a function of the switch state
SWITCH_STATE
ON SWITCH_STATE is ON LED shall be ON LED_OUT shall be ON
OFF SWITCH_STATE is OFF LED shall be OFF LED_OUT shall be OFF
For the assigned dominant ECU behaviors, the Function its specific Solutions shall be defined
Assigned ECU Behavior Assigned ECU Behavior-Solution Function specific Behavior-Solution
No HW signal shall be trusted Last valid signal shall be used LED_OUT state shall be frozen

16. 16
Step4: Dominant FNCT-Behavior Definition
Unrestricted © Visioneer GmbH, 2022
Expected ECU Behavior:
BATTERY_STATE
[Full operation,
No HW signal shall be trusted]
Expected FNCT-Behavior:
Dominant
FNCT Behavior
CAR_PRODUCTION_MODE
[LED shall show its el. connection,
LED is function of the switch state]
SWITCH_STATE
[LED shall be ON,
LED shall be OFF]
Full operation LED is function of the switch state
LED shall be ON LED shall be ON
LED shall be OFF LED shall be OFF
No HW signal shall be trusted LED is function of switch state x No HW signal shall be trusted
x LED shall show its el. connection x LED shall show its el. connection
The dominance of the Assigned ECU- and the FNCT-Behaviors shall be clearly defined:
Automatic verification if all pot.
Combinations are defined

17. 17
Unrestricted © Visioneer GmbH, 2022
Step5: Perform Automatism
This is what the Requirement Engineer can do
now (for instance), as he already has done his job:
• Any High-Level Requirement is clearly assigned to a
functional entity
• The expected behavior is described for any input signal
in any state
• It is clearly defined in any situation, which of the
parallel expected-behaviors is dominant
• Any pot. combination of the parallel expected-
behaviors is unambiguously defined
→Automatic generation and linking of testable
Functional Requirements

18. 18
Automatic Functional Requirements Generation
Unrestricted © Visioneer GmbH, 2022
1. The expected Behaviors are replaced by its Entry Criteria
2. The dominant FNCT Behaviors are replaced by its FNCT Behavior Solutions
Erwartetes ECU Verhalten:
BATTERY_STATE
Erwartetes FNCT-Verhalten: Soll-
FNCT Verhalten
CAR_PRODUCTION_MODE SWITCH_STATE
Full operation
BATTERY_STATE is FULL
LED is function of the switch state
CAR_PRODUCTION_MODE is NOT ACTIVATED
LED shall be ON
SWITCH_STATE is ON
LED shall be ON
LED_OUT shall be ON
LED shall be OFF
SWITCH_STATE is OFF
LED shall be OFF
LED_OUT shall be OFF
No HW signal shall be trusted
BATTERY_STATE is LOW
LED is function of the switch state
CAR_PRODUCTION_MODE is NOT ACTIVATED
x
No HW signal shall be trusted
LED_OUT state shall be frozen
x
LED shall show its el. Connection
CAR_PRODUCTION_MODE is ACTIVATED
x
LED shall show its el. Connection
LED_OUT shall be ON

19. 19
Automatic Functional Requirements Generation
Unrestricted © Visioneer GmbH, 2022
The following Functional Requirements are then generated automatically out of that table
→ The red parts are false defined or missing requirements in the example (created with todays methods)
FuncReq1: If SWITCH_STATE is ON and CAR_PRODUCTION_MODE is NOT ACTIVATED and
BATTERY_STATE is FULL, then the LED_OUT shall be ON
FuncReq2: If SWITCH_STATE is OFF and CAR_PRODUCTION_MODE is NOT ACTIVATED and
BATTERY_STATE is FULL, then the LED_OUT shall be OFF
FuncReq3: If CAR_PRODUCTION_MODE is NOT ACTIVATED and BATTERY_STATE is LOW, then
the LED_OUT shall be FROZEN
FuncReq4: If CAR_PRODUCTION_MODE is ACTIVATED, then the LED_OUT shall be ON

20. 20
FuncReq1: If SWITCH_STATE is ON and CAR_PRODUCTION_MODE is NOT ACTIVATED and BATTERY_STATE is FULL,
then the LED_OUT shall be ON
contains excluded
Sys Req1 : If SWITCH_STATE is ON, then the LED
shall be ON
Sys Req2: In CAR_PRODUCTION_MODE the LED
shall be ON
Sys Req3: If BATTERY_STATE is LOW, then HW
signals are not reliable
Solution1.1: If the
SWITCH_STATE is ON,
then LED_OUT shall
be ON
derived from
Solution1.2: If the
SWITCH_STATE is OFF,
then LED_OUT shall be
OFF
Solution2.1: If CAR_PROD-
UCTION_MODE is
ACTIVATED, then
LED_OUT shall be ON
Solution2.2: If CAR_PROD-
UCTION_MODE is NOT
ACTIVATED, then
LED_OUT is a function of
the switch state
subdominant
Solution3.1: If the battery
is LOW, then the last valid
HW signal shall be used
Solution3.1.1: If the battery is LOW,
then LED_OUT state shall be frozen
Solution3.2: If the battery
is FULL, then all functions
shall be activated
sub-
dominant
derived from
Automatic Generation of Requirements Diagram
excluded
excluded
derived from derived from derived from derived from derived from
The diagrams are in the same way gererated for the FuncReq2-4…
Unrestricted © Visioneer GmbH, 2022

21. 21
The benefits of complete and clear Functional Requirements:
Unrestricted © Visioneer GmbH, 2022
Requirement
Engineer
Quality
Assurance
Test
Engineer
Functional
Safety
Customer
More Information:
www.visioneer.info
Contact:
Gerhard Schilling
Tel. +49 179 3245588
schilling@visioneer.info