From 653a0a4db38607d75ecb935e493ac7d67a3ad5da Mon Sep 17 00:00:00 2001 From: aschemmel-git Date: Thu, 7 May 2026 10:53:58 +0200 Subject: [PATCH 1/2] Results comp FMEA Refers: #2490 --- .../result/docs/architecture/index.rst | 13 ++ .../result/docs/safety_analysis/fmea.rst | 136 +++++++++++++++--- 2 files changed, 130 insertions(+), 19 deletions(-) diff --git a/docs/modules/baselibs/result/docs/architecture/index.rst b/docs/modules/baselibs/result/docs/architecture/index.rst index 0a38ab8d7ab..b82ddf7d3ce 100644 --- a/docs/modules/baselibs/result/docs/architecture/index.rst +++ b/docs/modules/baselibs/result/docs/architecture/index.rst @@ -59,6 +59,19 @@ Static Architecture {{ draw_component(need(), needs) }} +Dynamic Architecture +-------------------- + +.. comp_arc_dyn:: Result Dynamic view + :id: comp_arc_dyn__baselibs__result + :security: YES + :safety: ASIL_B + :status: valid + :fulfils: comp_req__result__error_handling, comp_req__result__set_result, comp_req__result__domain_error_information, comp_req__result__type_safety, comp_req__result__std_integration, comp_req__result__deterministic_behavior, comp_req__result__exception_free_operation + :belongs_to: comp__baselibs_result + + No need for sequence diagram. Simple caller callee flow. + Interfaces ---------- diff --git a/docs/modules/baselibs/result/docs/safety_analysis/fmea.rst b/docs/modules/baselibs/result/docs/safety_analysis/fmea.rst index 9ef70672a18..bae0034c32e 100644 --- a/docs/modules/baselibs/result/docs/safety_analysis/fmea.rst +++ b/docs/modules/baselibs/result/docs/safety_analysis/fmea.rst @@ -18,33 +18,131 @@ FMEA (Failure Modes and Effects Analysis) .. document:: result FMEA :id: doc__result_fmea - :status: draft + :status: valid :safety: ASIL_B :security: NO :realizes: wp__sw_component_fmea -.. note:: Use the content of the document to describe e.g. why a fault model is not applicable for the diagram. - - Failure Mode List ----------------- -.. code-block:: rst +Fault Models for sequence diagrams + .. list-table:: Fault Models for sequence diagrams + :header-rows: 1 + :widths: 10,20,10,20 + + * - ID + - Failure Mode + - Applicability + - Rationale + * - MF_01_01 + - message is not received (is a subset/more precise description of MF_01_05) + - no + - If set result was not received before the get value/error are called, this will lead to an exception/terminate. In case of the get value user defined defaults are provided. + * - MF_01_02 + - message received too late (only relevant if delay is a realistic fault) + - no + - Do not see this as a problem for result lib, would lead to the same consideration as in MF_01_01 + * - MF_01_03 + - message received too early (usually not a problem) + - no + - No problem for result lib + * - MF_01_04 + - message not received correctly by all recipients (different messages or messages partly lost). Only relevant if the same message goes to multiple recipients. + - no + - No multiple recipients (maybe from different threads?) + * - MF_01_05 + - message is corrupted + - yes + - Error message string is destroyed before accessing it by the user - see :need:`comp_saf_fmea__result__error_message_unavail` + * - MF_01_06 + - message is not sent + - yes + - Value or error are not returned - see :need:`comp_saf_fmea__result__no_return` + * - MF_01_07 + - message is unintended sent + - no + - not applicable for a library + * - CO_01_01 + - minimum constraint boundary is violated + - yes + - Used enum types may not match - see :need:`comp_saf_fmea__result__enum_type_mismatch` + * - CO_01_02 + - maximum constraint boundary is violated + - yes + - same as above + * - EX_01_01 + - Process calculates wrong result(s) (is a subset/more precise description of MF_01_05 or MF_01_04). This failure mode is related to the analysis if e.g. internal safety mechanisms are required (level 2 function, plausibility check of the output, …) because of the size / complexity of the feature. + - no + - Due to low complexity of the component this error is completely eliminated by testing. Low complex architecture according to criteria in :need:`gd_chklst__arch_inspection_checklist` ARC_03_03 and design complexity below numbers as in :need:`gd_req__impl_complexity_analysis` + * - EX_01_02 + - processing too slow (only relevant if timing is considered) + - no + - Due to the small functionality, being too slow is no likely issue. + * - EX_01_03 + - processing too fast (only relevant if timing is considered) + - no + - Get functions only deliver data when called, no "too fast" is possible. + * - EX_01_04 + - loss of execution + - yes + - Loss of execution leads to the same error as MF_01_06 + * - EX_01_05 + - processing changes to arbitrary process + - no + - Not a problem of result lib as this is a libray and not a process + * - EX_01_06 + - processing is not complete (infinite loop) + - yes + - User gives back a function as return which induces stop of user execution - see :need:`comp_saf_fmea__result__stop_user` + +FMEA +---- +For all identified applicable failure initiators, the FMEA is performed in the following section. + +.. comp_saf_fmea:: Result Enum Type Mismatch + :violates: comp_arc_dyn__baselibs__result + :id: comp_saf_fmea__result__enum_type_mismatch + :fault_id: CO_01_01 + :failure_effect: User would understand a wrong error type (based on different error domains) + :mitigation_issue: https://github.com/eclipse-score/score/issues/2880 + :sufficient: no + :status: valid + + Only if the user would use the error information not only for debug reasons but for selecting the + type of error reaction this error may have an error impact. We need to make the user aware of this. + +.. comp_saf_fmea:: Result Error Message Unavailability + :violates: comp_arc_dyn__baselibs__result + :id: comp_saf_fmea__result__error_message_unavail + :fault_id: MF_01_05 + :failure_effect: Accessing error message could result in undefined behaviour + :mitigated_by: aou_req__result__resource_lifetime + :mitigation_issue: https://github.com/eclipse-score/score/issues/2880 + :sufficient: no + :status: valid + + The linked AoU cares about unavailability of other return objects, but also the error message may be unavailable. - .. comp_saf_fmea:: - :violates: <Component architecture> - :id: comp_saf_fmea__<Component>__<Element descriptor> - :fault_id: <ID from fault model :need:`gd_guidl__fault_models`> - :failure_effect: "description of failure effect of the fault model on the element" - :mitigated_by: <ID from Component Requirement | ID from AoU Component Requirement> - :mitigation_issue: <ID from Issue Tracker> - :sufficient: <yes|no> - :status: <valid|invalid> +.. comp_saf_fmea:: Result No Return + :violates: comp_arc_dyn__baselibs__result + :id: comp_saf_fmea__result__no_return + :fault_id: MF_01_06 + :failure_effect: Accessing value object could result in undefined behaviour (e.g. usage of wrong value) + :mitigated_by: aou_req__result__value_handling, aou_req__result__error_reaction + :sufficient: yes + :status: valid -.. note:: argument is inside the 'content'. Therefore content is mandatory + If a value or a error is not returned this will be noticed by the user and reacted upon. This is ensured + additionally by the provided AoU. -.. attention:: - The above directive must be updated according to your component FMEA. +.. comp_saf_fmea:: Result Stop User + :violates: comp_arc_dyn__baselibs__result + :id: comp_saf_fmea__result__stop_user + :fault_id: EX_01_06 + :failure_effect: User could be stopped by a function provided as a result from another user + :mitigated_by: aou_req__platform__flow_monitoring + :sufficient: yes + :status: valid - - The above "code-block" directive must be updated - - Fill in all the needed information in the <brackets> + Stopping its own execution has to be managed by the user via program flow monitoring, see AoU. From 7a44acebf472791ff7aec7aefb468afe911b51ff Mon Sep 17 00:00:00 2001 From: aschemmel-git <alexander.schemmel@bmw.de> Date: Mon, 11 May 2026 15:08:17 +0200 Subject: [PATCH 2/2] Results comp FMEA - updates Refers: #2490 --- .../result/docs/safety_analysis/fmea.rst | 48 +++++++++++-------- 1 file changed, 27 insertions(+), 21 deletions(-) diff --git a/docs/modules/baselibs/result/docs/safety_analysis/fmea.rst b/docs/modules/baselibs/result/docs/safety_analysis/fmea.rst index bae0034c32e..1989c41813c 100644 --- a/docs/modules/baselibs/result/docs/safety_analysis/fmea.rst +++ b/docs/modules/baselibs/result/docs/safety_analysis/fmea.rst @@ -54,11 +54,11 @@ Fault Models for sequence diagrams * - MF_01_05 - message is corrupted - yes - - Error message string is destroyed before accessing it by the user - see :need:`comp_saf_fmea__result__error_message_unavail` + - The error message carried within the error object does not own the underlying data. If the data source is destroyed before the error message is accessed by the user, the message reference becomes invalid (see :need:`comp_saf_fmea__result__error_message_life`). * - MF_01_06 - message is not sent - yes - - Value or error are not returned - see :need:`comp_saf_fmea__result__no_return` + - Value or error are not returned - see :need:`comp_saf_fmea__result__unchecked` * - MF_01_07 - message is unintended sent - no @@ -66,7 +66,7 @@ Fault Models for sequence diagrams * - CO_01_01 - minimum constraint boundary is violated - yes - - Used enum types may not match - see :need:`comp_saf_fmea__result__enum_type_mismatch` + - The error code returned is not bound to a specific error domain at the type level. A user may interpret the code against the wrong domain, violating the constraint that error codes are only meaningful within their originating domain (see :need:`comp_saf_fmea__result__error_code`). * - CO_01_02 - maximum constraint boundary is violated - yes @@ -90,59 +90,65 @@ Fault Models for sequence diagrams * - EX_01_05 - processing changes to arbitrary process - no - - Not a problem of result lib as this is a libray and not a process + - Not a problem of result lib as this is a library and not a process * - EX_01_06 - processing is not complete (infinite loop) - yes - - User gives back a function as return which induces stop of user execution - see :need:`comp_saf_fmea__result__stop_user` + - The Result library accepts user-provided operations for value and error transformation. If such an operation does not complete, the calling execution is halted (see :need:`comp_saf_fmea__result__stop_user`). FMEA ---- For all identified applicable failure initiators, the FMEA is performed in the following section. -.. comp_saf_fmea:: Result Enum Type Mismatch +.. comp_saf_fmea:: Result Error Code Cross-Domain Misinterpretation :violates: comp_arc_dyn__baselibs__result - :id: comp_saf_fmea__result__enum_type_mismatch + :id: comp_saf_fmea__result__error_code :fault_id: CO_01_01 - :failure_effect: User would understand a wrong error type (based on different error domains) + :failure_effect: When retrieving error information, the error code is returned as a domain-agnostic integer. If the user interprets this code under a different error domain than the one that produced it, the error is misidentified, potentially leading to incorrect error reaction. :mitigation_issue: https://github.com/eclipse-score/score/issues/2880 :sufficient: no :status: valid - Only if the user would use the error information not only for debug reasons but for selecting the - type of error reaction this error may have an error impact. We need to make the user aware of this. + If the user relies on the error code not only for diagnostic purposes but for selecting an error reaction path, + misinterpreting the code under a wrong domain could lead to an incorrect safety-relevant decision. + An Assumption of Use shall ensure the user verifies the error domain before interpreting the error code. -.. comp_saf_fmea:: Result Error Message Unavailability +.. comp_saf_fmea:: Result Error Message Lifetime Violation :violates: comp_arc_dyn__baselibs__result - :id: comp_saf_fmea__result__error_message_unavail + :id: comp_saf_fmea__result__error_message_life :fault_id: MF_01_05 - :failure_effect: Accessing error message could result in undefined behaviour + :failure_effect: The error message provided during error construction is stored as a non-owning reference. If the referenced data is no longer valid when the user retrieves the error message, accessing it results in undefined behavior. :mitigated_by: aou_req__result__resource_lifetime :mitigation_issue: https://github.com/eclipse-score/score/issues/2880 :sufficient: no :status: valid - The linked AoU cares about unavailability of other return objects, but also the error message may be unavailable. + The existing Assumption of Use for resource lifetime addresses the validity of error domain objects + and referenced resources. However, it does not explicitly cover the user-provided error message, + which is equally subject to lifetime constraints. The AoU should be extended to explicitly include the error message data, + or a separate AoU should be established for it. -.. comp_saf_fmea:: Result No Return +.. comp_saf_fmea:: Result Unchecked Value or Error Access :violates: comp_arc_dyn__baselibs__result - :id: comp_saf_fmea__result__no_return + :id: comp_saf_fmea__result__unchecked :fault_id: MF_01_06 - :failure_effect: Accessing value object could result in undefined behaviour (e.g. usage of wrong value) + :failure_effect: If the user calls value without the result containing a value, or calls error without the result containing an error, the program will terminate. This may occur when the user does not check the state of the result before accessing it. :mitigated_by: aou_req__result__value_handling, aou_req__result__error_reaction :sufficient: yes :status: valid - If a value or a error is not returned this will be noticed by the user and reacted upon. This is ensured - additionally by the provided AoU. + If the user accesses the value or the error without first verifying the state of the result, + the program will deterministically terminate. The provided Assumptions of Use require the user to check and handle both states before access. .. comp_saf_fmea:: Result Stop User :violates: comp_arc_dyn__baselibs__result :id: comp_saf_fmea__result__stop_user :fault_id: EX_01_06 - :failure_effect: User could be stopped by a function provided as a result from another user + :failure_effect: The user provides a transformation or error handling operation to the Result library. If this operation does not terminate (e.g., infinite loop), the calling execution is blocked indefinitely. :mitigated_by: aou_req__platform__flow_monitoring :sufficient: yes :status: valid - Stopping its own execution has to be managed by the user via program flow monitoring, see AoU. + The Result library invokes user-provided operations synchronously during transformation of values or errors. + Ensuring these operations terminate is outside the scope of the library and is the responsibility of the user via program flow monitoring, + as covered by the referenced platform-level Assumption of Use.