Safety Manuals AoUs sharpening

process/folder_templates/modules/module_name/docs/manual/safety_manual.rst

@@ -28,7 +28,7 @@ Safety Manual
 .. attention::
     The above directive must be updated according to your Module.
 
-    - Modify ``Your Module Name`` to be your Module Name
+    - Modify ``Your Module Name`` to be your Module Name or put "Platform"
     - Modify ``id`` to be your Module Name in upper snake case preceded by ``doc__`` and succeeded by ``safety_manual``
     - Adjust ``status`` to be ``valid``
     - Adjust ``safety`` and ``tags`` according to your needs
@@ -40,15 +40,15 @@ Introduction/Scope
 Assumed Platform Safety Requirements
 ------------------------------------
 | For the <Project platform / module name> the following safety related stakeholder requirements are assumed to define the top level functionality (purpose) of the <Project platform / module name>. I.e. from these all the feature and component requirements implemented are derived.
-| <List here all the stakeholder requirements, with safety not equal to QM, the module's components requirements are derived from.>
+| <List here all the stakeholder requirements, with safety not equal to QM, the module's components requirements are derived from. For the platform all are relevant.>
 
 Assumptions of Use
 ------------------
 
 Assumptions on the Environment
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 | Generally the assumption of the project platform SEooC is that it is integrated in a safe system, i.e. the POSIX OS it runs on is qualified and also the HW related failures are taken into account by the system integrator, if not otherwise stated in the module's safety concept.
-| <List here all the OS calls the project platform expects to be safe.>
+| <List here all the OS calls the project platform resp. module expects to be safe.>
 
 List of AoUs expected from the environment the platform / module runs on:
 
@@ -71,7 +71,11 @@ Assumptions on the User
 | 1. There are assumption which need to be fulfilled by all SW components, e.g. "every user of an IPC mechanism needs to make sure that he provides correct data (including appropriate ASIL level)" - in this case the AoU is marked as "platform".
 | 2. There are assumption which can be fulfilled by a safety mechanism realized by some other project platform component and are therefore not relevant for an user who uses the whole platform. But those are relevant if you chose to use the module SEooC stand-alone - in this case the AoU is marked as "module". An example would be the "JSON read" which requires "The user shall provide a string as input which is not corrupted due to HW or QM SW errors." - which is covered when using together with safe project platform persistency feature.
 
-List of AoUs on the user of the platform features or the module of this safety manual:
+List of AoUs on the user of the platform or the module of this safety manual:
+
+Note: Platform safety manual collects all platform wide AoU (have to be fulfilled by the user for any feature).
+Module safety manual collects all AoUs specific to a feature and its realizing components.
+This means for every feature the user selects, the platform safety manual and the related module manual has to be considered.
 
 .. needtable::
    :style: table

process/general_concepts/score_building_blocks_concept.rst

@@ -37,13 +37,13 @@ enabling of feature integration for different use cases and domains. This includ
 safety-critical applications. Thus the intention is, that the platform can be developed
 as a Safety Element out of Context (**SEooC**) and it can be delivered as part of a
 Delivery Container (green box, top, 1st column). The objectives of the platform are
-expressed as concrete **Stakeholder Requirements** (blue box, top, 2nd column), which
+expressed as concrete **Stakeholder Requirements** (blue box, top, 4th column), which
 can be tested by provided **Platform Integration Tests** (blue box, top, 6th column)
 for reference hardware platforms. A **Platform Safety/Security Analysis**
-(blue box, top, 6th column) is required to verify the Feature Architectures, whereby
+(blue box, top, 7th column) is required to verify the Feature Architectures, whereby
 violations of safety/security requirements must be documented. Potential faults
-may mitigated by updating the Stakeholder Requirements or by the **SW-platform
-Assumptions of Use** (blue box, top, 7nd column).
+may mitigated by updating the Stakeholder Requirements or by **Assumptions of Use**
+(white box, 8th column).
 
 The platform consists of **Features** (yellow box, middle, 2nd column).
 
@@ -57,39 +57,46 @@ In this sense a Dependable Element is the highest abstraction level in our model
 delivered in a Delivery Container represents e.g. executable code or a library.
 The **Dependable Element View** (red box, middle, 1st column) documents the mapping of
 components to a Dependable Element. Note that the term "Dependable" hints that the
-element can have safety and/or security relevance (but also non of these).
+element can have safety and/or security relevance (but also none of these).
 
 .. attention::
    Throughout the process description workspace, the term "Module" or "SW  Module" is
    used for convenience reason as a synonym for "Dependable Element".
 
 Components are the major building blocks of the platform. Components consists of **Units**
-(grey box, bottom, 2nd column), the lowest level in our model. The represent the source code,
-which implements the Unit. Units has a **Detailed Design** (grey box, middle, 3rd column),
-which is also implemented by the **Source Code** (grey box, bottom, 3rd column).
-The Detailed Design is verified by **Unit Tests** (grey box, middle, 5th column).
-
-Components are defined by **Component Requirements** (green box, middle, 3rd column) and
-the **Component Architecture** (green box, middle, 4th column).
-A **Component Safety/Security Analysis** (green box, middle, 6th column) is required to
+(grey box, bottom, 2nd column), the lowest level in our model. It represents the source code,
+which implements the Unit. Units have a **Detailed Design** (grey box, middle, 4th column),
+which is also implemented by the **Source Code** (grey box, bottom, 4th column).
+The Detailed Design is verified by **Unit Tests** (grey box, middle, 6th column).
+
+Components are defined by **Component Requirements** (green box, middle, 4th column) and
+the **Component Architecture** (green box, middle, 5th column).
+A **Component Safety/Security Analysis** (green box, middle, 7th column) is required to
 verify the Component Architecture, whereby violations of safety/security requirements
 must be documented. Potential faults may mitigated by updating the Component Requirements
-or by the **Component Assumptions of Use** (green box, middle, 8nd column). The latter
+or by **Assumptions of Use** (white box, 8th column). The latter
 one must be considered by the user of the Component. **Component Integration Tests**
-(green box, middle, 5th column) verify the Component  requirements, and the Component
+(green box, middle, 6th column) verify the Component  requirements, and the Component
 Architecture as well as the Integration of multiple Units to a Component.
 
 Features consists of components and are defined by **Feature Requirements**
-(yellow box, middle, 3rd column) and the **Feature Architecture** (yellow box, middle, 4th column).
-A **Feature Safety/Security Analysis** (yellow box, middle, 6th column) is required to
+(yellow box, middle, 4th column) and the **Feature Architecture** (yellow box, middle, 5th column).
+A **Feature Safety/Security Analysis** (yellow box, middle, 7th column) is required to
 verify the Feature Architecture, whereby violations of safety/security requirements must
 be documented. Potential faults may mitigated by updating the Feature Requirements or by
-the **Feature Assumptions of Use** (yellow box, middle, 8nd column). The latter one must
+**Assumptions of Use** (white box, 8th column). The latter one must
 be considered by the user of the Feature. **Feature Integration Tests**
-(yellow box, middle, 5th column) verify the Feature Requirements and the Feature
+(yellow box, middle, 6th column) verify the Feature Requirements and the Feature
 Architecture.
-Feature has **Logical Architecture Interfaces** (green box, middle, 3th column), which
-are implemented by the components.
+Features have **Logical Architecture Interfaces** (green box, middle, 3rd column), which
+are implemented (and can be used) by the components.
+
+**Assumptions of Use** are not specific for a level as it is not fixed where they will be
+fulfilled and verified, so they are depicted "white". In the picture one can also see two
+variants of Assumptions of Use: "own" AoU required by the own element towards other elements and
+the "other" AoU asked from other element towards the own element and fulfilled by it.
+Generally the metamodel refers only within own architecture element (=component/feature), but
+AoUs need the fulfills link own -> other.
 
 .. figure:: _assets/score_building_blocks_meta_model.drawio.svg
   :width: 100%

process/process_areas/requirements_engineering/guidance/requirements_guideline.rst

@@ -206,19 +206,23 @@ Following roles should be included in the review:
 Workflow for Creating and Linking Assumption of Use (AoU)
 =========================================================
 
-An AoU is a category of requirement which originates from a safety concept of an architectural element (and thus it is confirmed by a safety analysis).
-This is different for AoU created on SW-platform level, these are also coming from the scope of the project (i.e. the knowledge which safety activities are not part of a project).
-As it can not be fulfilled by the architecture element (e.g. component) itself, it needs to be fulfilled by the user of the element.
-In Safety Elements out of Context (SEooC) the AoUs will normally be part of the safety manual.
-In this process description (as it describes SEooC development) these AoUs are created both internally and externally - the latter if existing SEooCs are integrated into the platform (e.g. a qualified Operating System).
-For AoU which arise internally (i.e. from project specific architecture) the template is almost identical to the one for feature/component requirements. The only difference is that it is defined such that the attribute "satisfies" is replaced with the attribute "mitigates" (see picture below).
-For externally provided AoUs of course the sentence template cannot be taken into account, as these are only imported from an external safety manual. It is also not possible to link it to other development artifacts via the attribute "mitigates".
+An AoU is a category of requirement which is part of a safety concept of an architectural element (and thus it is confirmed by a safety analysis).
+As an AoU can not be fulfilled by the architecture element (e.g. component) itself, it needs to be fulfilled by the user of the element.
+AoU created on SW-platform level are also coming from the scope of the project (i.e. the knowledge which safety activities are not part of a project)
+or are defining general assumptions every user and/or every module in the platform has to fulfill.
+
+In Safety Elements out of Context (SEooC) the AoUs are part of the safety manual.
+
+In this workflow (as it describes SEooC development) these AoUs are created both project internal and project external
+
+- internal:  For AoU which arise internally (i.e. from project specific architecture), the template is almost identical to the one for feature/component requirements. The only difference is that it is defined such that the attribute "satisfies" is replaced with the attribute "mitigates" (see picture below).
+- external:  if externally provided SEooCs are integrated into the platform (e.g. a qualified Operating System). For these AoUs the sentence template cannot be taken into account, as these may be imported from an external safety manual. It is also not possible to link those to other platform development artifacts via the attribute "mitigates".
 
 AoUs can be of different class and shall be handled by tracing those
 
-* to Feature/Component Architecture (via satisfies), if those are on Component Level and can be fulfilled there
+* to Feature/Component (via satisfies), if those are on (external) Component Level and can be fulfilled by (internal) Feature/Component
 * to Stakeholder Requirements (via satisfies), if AoU are of general nature and can be fulfilled by platform
-* or by containing those in Platform Safety Manual, if AoU cannot be fulfilled by platform but need to be satisfied by the user of the platform
+* or by containing those in Platform(s) Safety Manual(s), if AoU cannot be fulfilled by platform or its components (alone) but need to be satisfied by the user of the platform
 
 
 .. figure:: ../_assets/aou_traceability.drawio.svg
@@ -228,7 +232,16 @@ AoUs can be of different class and shall be handled by tracing those
 
    AoU Traceability
 
-:numref:`aou_traceability` is an extension of the workproduct traceability to show the handling of (external) AoU. Note that the component level displayed in green shows two components - on the right the one exporting AoU to be fulfilled by others, left the component which fulfills and exports AoU (but without the traceability shown on the right to reduce complexity).
+:numref:`aou_traceability` is an extension of the workproduct traceability to show the handling of AoU.
+Note that the component level displayed in green shows two components - on the right (dark green) the one which is exporting AoU to be fulfilled by others,
+on the left (light green) the component which fulfills and exports AoU.
+Internal component's AoU can also be fulfilled (and linked) by other internal components, this is not depicted here, but would be quite the same with one exception:
+External component's AoUs which cannot be fulfilled by the platform alone are contained in the platform Safety Manual, whereas the internal component's AoUs
+are part of the Module Safety Manual.
+
+Like other requirements also an AoU needs to be verified - but by the user of the feature/component.
+To improve the usability of a feature/component, its responsible team should already provide
+integration tests the user has to run to prove the fulfillment of the AoU(s).
 
 Special cases
 =============

process/process_areas/safety_management/safety_management_workproducts.rst

@@ -93,8 +93,9 @@ Safety Management Work Products
 
    * The Assumed Platform Requirements (Safety related);
    * the safety concept of the SEooC (i.e. which faults are taken care of);
-   * the Assumptions of Use (of the features);
-   * a link to the user manual;
+   * the Assumptions of Use (of the platform level), including AoU of external components to be fulfilled also by the user;
+   * links to all the module safety manuals of the platform integration;
+   * a link to the (platform) user manual;
    * the reactions of the implemented functions under anomalous operating conditions; and
    * a description of known anomalies with corresponding workaround measures.
 
@@ -110,8 +111,9 @@ Safety Management Work Products
 
    * The Assumed Platform Requirements (Safety related);
    * the safety concept of the SEooC (i.e. which faults are taken care of);
-   * the Assumptions of Use (of the modules's components);
-   * a link to the user manual;
+   * the Assumptions of Use (of the modules's components and of the associated feature);
+   * a link to the platform safety manual (containing the general AoUs every user has to obey additionally);
+   * a link to the (module) user manual;
    * the reactions of the implemented functions under anomalous operating conditions; and
    * a description of known anomalies with corresponding workaround measures.