DFA (Dependent Failure Analysis)#
Baselibs DFA
|
status: valid
security: YES
safety: ASIL_B
|
||||
Dependent Failure Initiators#
The DFA for the feature baselibs is performed. To show evidence that all failure initiators are considered, the applicability has to be filled out in the following tables. For all applicable failure initiators, the DFA has to be performed.
Dependent Failure Initiators#
Communication between the two elements#
Receiving function is affected by information that is false, lost, sent multiple times, or in the wrong order etc. from the sender.
ID |
Violation cause communication between elements |
Applicability |
Rationale |
|---|---|---|---|
CO_01_01 |
Information passed via argument through a function call, or via writing/reading a variable being global to the two software functions (data flow) |
no |
According to its architecture shown in Baselibs Static View (feat_arc_sta__baselibs__static_view_arch) baselibs do not rely on common input. |
CO_01_02 |
Data or message corruption / repetition / loss / delay / masquerading or incorrect addressing of information |
no |
Baselibs are not sending messages between their components. |
CO_01_03 |
Insertion / sequence of information |
no |
Baselibs are not sending messages between their components. |
CO_01_04 |
Corruption of information, inconsistent data |
no |
Baselibs are not sending messages between their components. Data eventually shared by function calls are covered by FMEA already. |
CO_01_05 |
Asymmetric information sent from a sender to multiple receivers, so that not all defined receivers have the same information |
no |
Asymmetric information sending is not done in baselibs. |
CO_01_06 |
Information from a sender received by only a subset of the receivers |
no |
This is not done in baselibs. |
CO_01_07 |
Blocking access to a communication channel |
no |
There are no communication channels in baselibs. |
Unintended impact#
Unintended impacts to function due to various failures.
ID |
Violation cause unintended impact |
Applicability |
Rationale |
|---|---|---|---|
UI_01_01 |
Memory miss-allocation and leaks |
no |
Not a specific baselibs topic, therefore covered at platform DFA. |
UI_01_02 |
Read/Write access to memory allocated to another software element |
yes |
As baselibs are in context of a application, they may access their memory, memory access (feat_saf_dfa__baselibs__memory_access) |
UI_01_03 |
Stack/Buffer under-/overflow |
no |
Not a specific baselibs topic, therefore covered at platform DFA. |
UI_01_04 |
Deadlocks |
yes |
shared memory or file access may lead to deadlock, locked ressource (feat_saf_dfa__baselibs__locked_ressource) |
UI_01_05 |
Livelocks |
no |
Should be covered together with deadlock. |
UI_01_06 |
Blocking of execution |
yes |
As baselibs are in context of a application, they may block execution, blocked execution (feat_saf_dfa__baselibs__blocked_execution) |
UI_01_07 |
Incorrect allocation of execution time |
no |
Execution time allocated by (external) OS on platform level, should be covered centrally at platform level. |
UI_01_08 |
Incorrect execution flow |
no |
Execution flow controlled by (external) OS on platform level, should be covered centrally at platform level. |
UI_01_09 |
Incorrect synchronization between software elements |
no |
There is no need for synchronization for baselibs. |
UI_01_10 |
CPU time depletion |
yes |
Baselibs may deplete or suffer from depletion, CPU starvation (feat_saf_dfa__baselibs__cpu_starvation) |
UI_01_11 |
Memory depletion |
no |
Not a specific baselibs topic, therefore covered at platform DFA. |
UI_01_12 |
Other HW unavailability |
no |
No special HW used for baselibs. |
DFA#
For all identified applicable failure initiators, the DFA is performed in the following section.
memory access
|
status: valid
|
||||
All the baselibs components have to be developed to ASIL_B standard to maintain Freedom From Interference, out of bounds access should be detected by unit testing/sanitizers. |
|||||
locked ressource
|
status: valid
|
||||
Only components “filesystem” and “memory_shared” should have the problem (“bitmanipulation” should not be affected due to shortness of execution) “memory_shared” cares for this by above linked feature requirement and Atomic Operations in Shared... (comp_req__memory__atomic_ops). “filesystem” component may fail on this but this is covered by common platform aou linked above. |
|||||
concurrent file access
|
status: valid
|
||||
The user has to care for concurrent file access. This is not covered by the filesytem library. |
|||||
concurrent memory access
|
status: valid
|
||||
The user has to care for concurrent memory access. This is not covered by the bitmanipulation library. |
|||||
blocked execution
|
status: valid
|
||||
All the baselibs components have to be developed to ASIL_B standard to maintain Freedom From Interference, all blocks should be detected by unit testing. |
|||||
CPU starvation
|
status: valid
|
||||
Some care is taken to avoid using too much CPU time, but this cannot be covered fully. Platform level AoU asks applications with timing requirements to cover this by program flow monitoring. |
|||||