Audit preparation: Architecture

[aschemmel-tech]

"not started" topics:

• 7.4.3 Architecture principles - covered by review: https://eclipse-score.github.io/process_description/main/process_areas/architecture_design/guidance/architecture_inspection_checklist.html ARC_02_05, ARC_03_01, ARC_03_02, ARC_03_03 and DFA https://eclipse-score.github.io/process_description/main/process_areas/safety_analysis/guidance/dfa_failure_initiators.html#gd_guidl__dfa_failure_initiators SR_01_xx
• 7.4.6 SSR allocation to components - see https://eclipse-score.github.io/process_description//main/process_areas/architecture_design/guidance/architecture_process_reqs.html#gd_req__arch_traceability and example https://eclipse-score.github.io/score/main/modules/baselibs/json/docs/requirements/index.html#comp_req__json__deserialization
• 7.4.7 Pre-existing SW - covered in safety management: Audit preparation: Safety Management #78
• 7.4.8 Coexistence - Safety Stakeholder req and AoU addition score#1976 adds relevant Stakekolder req and Platform AoU
• 7.4.9 FFI - provided by QNX, see also Safety Stakeholder req and AoU addition score#1976 and memory protection topics in https://eclipse-score.github.io/score/main/requirements/stakeholder/index.html#stkh_req__dependability__safety_features
• 7.4.13 resource estimation - only measured by integration testing and only on reference HW, see https://eclipse-score.github.io/process_description/main/process_areas/verification/workproducts.html#wp__verification_feat_int_test - no example values

Actions and Deviations:

• Deviation_10: The use of UML shall be specified in order to limit the definition of UML to a useful subset. - see https://eclipse-score.github.io/score/main/process/process_areas/architecture_design/architecture_concept.html#specification-of-the-architectural-design
• Action_29: It’s not specified at which level dynamic views are expected. (Trivial views (e.g., function call) may be excluded. - see https://eclipse-score.github.io/score/main/process/process_areas/architecture_design/guidance/architecture_guideline.html
• Action_30: It should be specified that negative cases in dynamics views should be documented. - see https://eclipse-score.github.io/score/main/process/process_areas/architecture_design/architecture_concept.html#dynamic-view,
  See https://github.com/eclipse-score/process_description/pull/414/files, line 229
• Deviation_11: The traceability concept description shall take the traceability of the requirement to the design into account. - see for example https://eclipse-score.github.io/process_description//main/_images/score_traceability_model_feat_overview.drawio.svg ("fulfills" link)
• Action_31: The ASIL allocation of the architectural elements shall be visible in the diagrams - see https://eclipse-score.github.io/score/main/process/process_areas/architecture_design/architecture_concept.html#comp_arc_sta__archdes_component_2,
  See https://github.com/eclipse-score/process_description/pull/414/files, line 113
• Action_32: Is there a traceability between the architectural models? (not only on requirements level). - yes, see in metamodel: link between Feature and Component (https://eclipse-score.github.io/process_description/main/general_concepts/score_building_blocks_concept.html#building-blocks-meta-model), in practice click on a component in https://eclipse-score.github.io/process_description/main/process_areas/architecture_design/_assets/architecture_modeling_example.html
• Action_33: Criteria shall be defined, in which cases dynamic views are required on Feature (and Component) level. (same as 2nd finding above) - see https://eclipse-score.github.io/score/main/process/process_areas/architecture_design/guidance/architecture_guideline.html
• Action_34: It shall be defined what a sub-component is. - sub-components are removed from concept, see https://eclipse-score.github.io/score/main/process/general_concepts/score_building_blocks_concept.html and https://eclipse-score.github.io/score/main/_images/score_traceability_model_cmp_overview_2.drawio.svg
• Action_35: The caption of Fig. 19 “Definition of the static model architecture” should be changed as the architecture is based on components (and not on modules). - Fig. 19 is now the "feature 1" example, modules are only the top-level components in a repository, see https://eclipse-score.github.io/score/main/process/process_areas/architecture_design/architecture_concept.html#definition-of-architectural-viewpoints
• Deviation_12: Traceability from/ to the architecture to/ from the code is not given yet. - Architecture: see https://eclipse-score.github.io/score/main/process/process_areas/architecture_design/architecture_concept.html#definition-of-architectural-viewpoints examples
• Action_36: Formal Inspection Reviews shall be defined for the Software Design. - see https://eclipse-score.github.io/score/main/process/general_concepts/score_review_concept.html and implementation process (VolkerH)
• Action_37: The complexity criteria (e.g. number of interfaces, size of interfaces) shall be specified (ARC_03_03). - see https://eclipse-score.github.io/score/main/process/process_areas/architecture_design/guidance/architecture_inspection_checklist.html
• Action_38: Review checklist questions shall not only be answered by yes / no. - see https://eclipse-score.github.io/score/main/process/general_concepts/score_review_concept.html
• Recommendation_3: Checklists consist of a ASIL/ QM classification which should be removed. see https://eclipse-score.github.io/score/main/process/process_areas/architecture_design/guidance/architecture_inspection_checklist.html
• Action_39: There shall be a thorough description of how to work with checklists (../process/process_model/guidance/architecture/checklists/architecture_inspection_checklist.html) - see https://eclipse-score.github.io/score/main/process/general_concepts/score_review_concept.html
• Action_40: Checklist shall be listed in the directory (document management) (solved, doc indexing tool issue)

[RolandJentschETAS]

Jentsch Roland (ETAS-ECM/XPC-Hi) wurde zu der Besprechung eingeladen.

"not started" topics:

• 7.4.3 Architecture principles - covered by review: https://eclipse-score.github.io/process_description/main/process_areas/architecture_design/guidance/architecture_inspection_checklist.html ARC_02_05, ARC_03_01, ARC_03_02, ARC_03_03 and DFA https://eclipse-score.github.io/process_description/main/process_areas/safety_analysis/guidance/dfa_failure_initiators.html#gd_guidl__dfa_failure_initiators SR_01_xx

• 7.4.3. Table 3 - 1a, 1b, (1c), 1f, 1i not covered. -> 1a guideline and meta model explains lower level components. 1b -> add requirement and link to implementation and architecture checklist (shall be part of the SW verification report) 1c -> not required for ASIL B. 1f -> added as process requirement. 1i -> now part of architecture checklist
  See add linking to iso26262 and add requirements according to ISO #470 -> merged

• 7.4.6 SSR allocation to components - see https://eclipse-score.github.io/process_description//main/process_areas/architecture_design/guidance/architecture_process_reqs.html#gd_req__arch_traceability and example https://eclipse-score.github.io/score/main/modules/baselibs/json/docs/requirements/index.html#comp_req__json__deserialization

• Second part missing. There is no requirement or check that the ASIL rating of derived elements is hold, so that the each software component will be developed in compliance with the highest ASIL of any of the requirements allocated to it. Maybe indirectly. Currently only linked to req that each element have ASIL/QM. -> It is now stated that QM elements could not be linked to ASIL requirements https://eclipse-score.github.io/process_description/main/process_areas/architecture_design/guidance/architecture_process_reqs.html#gd_req__arch_linkage_requirement

• 7.4.7 Pre-existing SW - covered in safety management: Audit preparation: Safety Management #78 -> still open in the linked process description -> now PR is closed and pre-existing software parts are described in https://eclipse-score.github.io/process_description/main/standards/aspice_40/swe/swe.2.html

• 7.4.8 Coexistence - Safety Stakeholder req and AoU addition score#1976 adds relevant Stakekolder req and Platform AoU

• CRQ is for project, not for process and does not cover 7.4.8 fully (i.e. resource conflicts are QM/ASIL not covered) -> maybe covered by DFA -> see Improvement safety linkage and checklist improvement #438 -> covered by DFA and additional check requirement

• 7.4.9 FFI - provided by QNX, see also Safety Stakeholder req and AoU addition score#1976 and memory protection topics in https://eclipse-score.github.io/score/main/requirements/stakeholder/index.html#stkh_req__dependability__safety_features

• Shared resources are not covered (at least not mentioned in the PR). Maybe covered by DFA? -> see Improvement safety linkage and checklist improvement #438 -> covered by Safety analysis, DFA and architecture checklist
  See https://eclipse-score.github.io/process_description/main/folder_templates/features/feature_name/architecture/chklst_arc_inspection.html

• 7.4.13 resource estimation - only measured by integration testing and only on reference HW, see https://eclipse-score.github.io/process_description/main/process_areas/verification/verification_workproducts.html#feature - no example values

Actions and Deviations:

• Deviation_10: The use of UML shall be specified in order to limit the definition of UML to a useful subset. - see https://eclipse-score.github.io/process_description/main/process_areas/architecture_design/guidance/architecture_guideline.html#uml-diagram-selection

• Action_29: It’s not specified at which level dynamic views are expected. (Trivial views (e.g., function call) may be excluded. - see https://eclipse-score.github.io/process_description/main/process_areas/architecture_design/guidance/architecture_guideline.html#uml-diagram-selection

• Action_30: It should be specified that negative cases in dynamics views should be documented. - see https://eclipse-score.github.io/process_description/main/process_areas/architecture_design/architecture_concept.html#dynamic-view
  and https://eclipse-score.github.io/process_description/main/process_areas/architecture_design/architecture_concept.html#id3

• Deviation_11: The traceability concept description shall take the traceability of the requirement to the design into account. - see for example https://eclipse-score.github.io/process_description//main/_images/score_traceability_model_feat_overview.drawio.svg ("fulfills" link)

• Action_31: The ASIL allocation of the architectural elements shall be visible in the diagrams - see https://eclipse-score.github.io/process_description/main/process_areas/architecture_design/architecture_concept.html#static-view and https://eclipse-score.github.io/process_description/main/process_areas/architecture_design/architecture_concept.html#id2

• Action_32: Is there a traceability between the architectural models? (not only on requirements level). - yes, see in metamodel: link between Feature and Component (https://eclipse-score.github.io/process_description/main/general_concepts/score_building_blocks_concept.html#building-blocks-meta-model), in practice click on a component in https://eclipse-score.github.io/process_description/main/process_areas/architecture_design/_assets/architecture_modeling_example.html

• Action_33: Criteria shall be defined, in which cases dynamic views are required on Feature (and Component) level. (same as 2nd finding above) - see https://eclipse-score.github.io/process_description/main/process_areas/architecture_design/guidance/architecture_guideline.html#uml-diagram-selection

• Action_34: It shall be defined what a sub-component is. - sub-components are removed from concept, see https://eclipse-score.github.io/process_description/main/general_concepts/score_building_blocks_concept.html#building-blocks-meta-model and https://eclipse-score.github.io/process_description/main/_images/score_traceability_model_cmp_overview_2.drawio.svg

• Action_35: The caption of Fig. 19 “Definition of the static model architecture” should be changed as the architecture is based on components (and not on modules). - Fig. 19 is now the "feature 1" example, modules are only the top-level components in a repository, see https://eclipse-score.github.io/process_description/main/process_areas/architecture_design/architecture_concept.html#relations-between-the-architectural-elements

• Deviation_12: Traceability from/ to the architecture to/ from the code is not given yet. - Architecture: see https://eclipse-score.github.io/score/main/process/process_areas/architecture_design/architecture_concept.html#specification-of-the-architectural-design examples or https://eclipse-score.github.io/process_description/main/general_concepts/score_traceability_concept.html -> currently in discussion in the implementation team. Partly in Enhance description of Implementation / Detailed Design #429 -> Done by Improvement: Implementation process description ML#2 #465

• Action_36: Formal Inspection Reviews shall be defined for the Software Design. - see https://eclipse-score.github.io/process_description/main/general_concepts/score_review_concept.html# and implementation process (VolkerH)

• Action_37: The complexity criteria (e.g. number of interfaces, size of interfaces) shall be specified (ARC_03_03). - see https://eclipse-score.github.io/process_description/main/folder_templates/modules/module_name/component_name/docs/architecture/chklst_arc_inspection.html#doc__component_name_arc_inspection

• Action_38: Review checklist questions shall not only be answered by yes / no. - see https://eclipse-score.github.io/process_description/main/general_concepts/score_review_concept.html

• Recommendation_3: Checklists consist of a ASIL/ QM classification which should be removed. see https://eclipse-score.github.io/process_description/main/folder_templates/modules/module_name/component_name/docs/architecture/chklst_arc_inspection.html

• Action_39: There shall be a thorough description of how to work with checklists (../process/process_model/guidance/architecture/checklists/architecture_inspection_checklist.html - see https://eclipse-score.github.io/process_description/main/general_concepts/score_review_concept.html

• Action_40: Checklist shall be listed in the directory (document management) (solved, doc indexing tool issue): See https://eclipse-score.github.io/process_description/main/general_concepts/score_review_concept.html

Inspection Checklist Template — Process Description documentation

[RolandJentschETAS]

See https://github.com/eclipse-score/process_description/pull/414/files for Action_30 and Action_31