SW Dev Process Community - S-CORE Safety Team - Meeting Minutes

[masc2023]

Meetings Minutes of S-CORE Safety Team.

[masc2023]

Dec-02, 09-10 o'clock

Agenda:
Introduction
Check participants
Align on Agenda for today

Scope Definition, compare https://github.com/orgs/eclipse-score/discussions/2226
eclipse-score/process_description#81
#2259
eclipse-score/process_description#422
#2056

• Deal with open PR for Safety Management:

  • Safety management update - PMP #2215 - content approved, conflicts could be solved by @FScholPer - merged
  • Safety management update - Process process_description#398 - (some) open findings, new PR or try to solve problems in the existing?

• (Module) Safety Manager Election Piloting: see Safety Manager Election #2261,
  Platform: maybe only after we have some Module Safety Managers to vote?

• Safety Audit agenda/timeline, see comment in Prepare Audit #6 process_description#77 - please check your slots (availability, feasibility) and prepare

  • Feature Request issue template not used, see Improvement: Feature Request Template #887 - what to do (see also open points in EPIC: Change Management, ML2 process_description#53) ?

Time permitting (process topics):

• 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
• "Versioned Links": To support change impact analysis we wanted tooling as in https://eclipse-score.github.io/process_description/main/process_areas/change_management/guidance/change_management_reqs.html - one impementation for this could be based on "Versioned Links". This means that every needs element would also have an attribute "version" and one could link to this from another need by "needs_id@version" instead of only by "needs_id". If the version of a need is changed and the derived needs links are not, a documentation build would issue an warning (configurable if the warning is breaking the build). UseBlocks may contribute this to S-CORE.
• We currently have no process/tool requirements to check for tracing to "invalid" work products. Should decide these alternatives: 1. remove the "invalid" status and delete the work product instead 2. create automated checks like for the ASIL attribute: "linking a valid element to an invalid element shall not be possible". Also take into account https://eclipse-score.github.io/process_description/main/process_areas/requirements_engineering/guidance/requirements_process_reqs.html#gd_req__req_validity

Participants:
@masc2023
@RolandJentschETAS
@aschemmel-tech
@antonkri
@arsibo
@odra
@PandaeDo
Paul Sherwood
Holger Modler (ETAS)
@pahmann
@alekseyborisyukvalidas
@hoe-jo
Karthik Vanka (Qorix)
@PhilipPartsch

Meeting Minutes:

Define Scope of the working group

Technical aspects safety related, Features, Module, (Requirements, Architecture, Analysis, Verification/Tests) ->Safety Engineer
Process, Compliance topics
Tools, Infrastructure, Evaluation
Driving Awareness, Following-up Safety Issues -> Safety Manager

@aschemmel-tech volunteers to take over moderation this working stream

#398 will be reviewed by @masc2023 , findings will be recorded, and solved in another PR by @aschemmel-tech

Decision: Safety Managers will be elected for the Platform, For Modules, Safety Managers are selected from the Platform Safety Managers Pool

Audit Plan showed. Everybody should check, if the schedule is feasible and feedback to @aschemmel-tech , if changes are required.
@aschemmel-tech , @PandaeDo will participate all the time and will take notes

Discussed, #2259, Agreed to change for competence management for PLs

#2056, @aschemmel-tech will have an additional review

[aschemmel-tech]

Dec-09, 09-10 o'clock

Agenda:
Introduction
Check participants
Align on Agenda for today

Participants:
@aschemmel-tech
@masc2023
@PandaeDo
@alekseyborisyukvalidas
@odra

Meeting Minutes:

• Approval for agenda safety audit: Prepare Audit #6 process_description#77 - @aschemmel-tech will take over the "safety management" process slot. Small modification to timing. Approved by the participants.

• (S-CORE Platform) Safety Manager election status: https://eclipse-score.github.io/score/main/platform_management_plan/role_assignment/platform_safety_manager.html - now we have pool of three. Successive nominations by PR on this document.

• Safety Manager assignment to Modules:

  • @aschemmel-tech for Baselibs and Communication: Safety Managers for Modules #2297
  • @masc2023 for FEO
  • @PandaeDo for Persistency and Orchestration
    Approved by the community

• Election of Safety Engineer roles (similar to Safety Manager). Who? As I have seen @masc2023 and @PandaeDo would qualify. - @PandaeDo will do this election/documentation.

• Module CODEOWNER skill checking as in https://eclipse-score.github.io/score/main/platform_management_plan/safety_management.html#functional-safety-management-organization "Skills" - this is a task for the assigned safety managers. @aschemmel-tech will pilot the "process" for Communication and Baselibs modules.

• Revisit: We currently have no process/tool requirements to check for tracing to "invalid" work products. Should decide these alternatives:

  1. remove the "invalid" status and delete the work product instead
  2. create automated checks like for the ASIL attribute: "linking a valid element to an invalid element shall not be possible".
     Also take into account https://eclipse-score.github.io/process_description/main/process_areas/requirements_engineering/guidance/requirements_process_reqs.html#gd_req__req_validity

  Discussion see PR for the proposed document life cycle model: add document lifecylce model process_description#436. We may have different lifecycles/status for different work products (e.g. Safety Analysis WPs vs. inspection documents). Everybody invited to comment in the PR.

eclipse-score/process_description#72 approved proposal and assigned eclipse-score/process_description#212 to @masc2023

Naming conventions, https://eclipse-score.github.io/score/main/contribute/general/naming.html, Issue detected by implementing baselibs-rust and baselibs-cpp, possible solution: module name in ID (not feature), but then ID length increased. Discuss how to treat the component requirements (which would also be the same for the cpp and Rust implementations) - @aschemmel-tech to discuss in the Baselibs Feature Team.

Release v1.4.0 planned for scorev0.5-beta-release
https://github.com/eclipse-score/process_description/releases, Planned for 9.12, latest 10.12 - release ok, have another one for the audit as the safety mgt and implementation findings are not fully resolved.

[aschemmel-tech]

Dec-16, 09-10 o'clock

Agenda:
Introduction
Check participants
Align on Agenda for today

Participants:
@aschemmel-tech
@RolandJentschETAS
@masc2023
@PandaeDo
@odra
@arsibo
@alekseyborisyukvalidas
@pahmann
@PhilipPartsch

Minutes of Meeting:

• last "Safety Management" processes meeting for 2025, Thursday "Processes" meeting is still planned.

• v0.5 qualifiable release is planned in March.

• Status of our "ML2" epics: PRC - Process Development Community (view) - update proposal for https://eclipse-score.github.io/process_description/main/ : Improvement: Process Overview update status new process_description#460 - Updates to ML definition approved, also change Doc Mgt and Work Products to ML2.

• @arsibo: Proposal for new S-CORE metamodel / distribution and linking of work products between score repo and module repos (and possibly the integration repo) incl. architecture and AoU - see EPIC: Metamodel Usability Adaptions process_description#450 - presented: process: add DR-005 for independent feature delivery #2346, further discussion in the PR, the alternative 2 shall be proposed for the "decision". Target for decision is middle of January. The proposal already also discussed in architecture community, but this needs to be repeated with more participants.

• @aschemmel-tech: Feedback from Baselibs team on naming conventions topic: Feature Team is planning to merge the Rust and C++ development in one module repository in the future.

• @pahmann : found some wrong linking from Baselibs team verification items to "requirements". Will raise tickets and may also present this to the FT.

• @RolandJentschETAS:

• Linking of component to feature or interface to feature. See https://eclipse-score.github.io/process_description/main/_images/score_building_blocks_meta_model.drawio.svg versus https://eclipse-score.github.io/process_description/main/_images/metamodel_architectural_design.drawio.svg versus https://github.com/eclipse-score/docs-as-code/blob/c87cd898ef63ce15daec434dc5ea161651cefe97/src/extensions/score_metamodel/metamodel.yaml#L401
• Is an architecture static view still an "architectural element" element ? - Agreement that the Feature and the Component currently will only be added as a architectural element (and no change to the others like architecture static view).

Post-Poned:
Open PRs:
eclipse-score/process_description#436
eclipse-score/process_description#460
eclipse-score/process_description#461
eclipse-score/process_description#462

[aschemmel-tech]

Jan-13, 09-10 o'clock

Agenda:
Introduction
Check participants
Align on Agenda for today

Participants:
@aschemmel-tech
@RolandJentschETAS
@masc2023
@PandaeDo
@odra
@arsibo
@alekseyborisyukvalidas
@pahmann
@PhilipPartsch
@4og
@basheerFZ
@kroehnd
@vevmaki
@antonkri
@hoe-jo
@attilio

Agenda:

• Safety Audit Jan-14 to Jan-16: Last open questions, look at the agenda (e.g. goals) last time
  There is a PR pending in architecture area: Improvement move details from getstarted to concept process_description#491 should be merged before a "interim" release for the audit. But there is still open PR in docs-as-code: fix: update type checks for component and module in UML drawing functions docs-as-code#338 which would be needed to make the architecture views right (after introduction of component needs). This is currently stuck due to missing reviewer.
• Feedback on process: add DR-005 for independent feature delivery #2346 ? see https://eclipse-score.github.io/score/pr-2346/design_decisions/DR-005-process.html - discussion started including use of reference architecture, post poned to Jan-13, 14:30 - 15:30

[aschemmel-tech]

Jan-20, 09-10 o'clock

Agenda:
Introduction
Check participants
Align on Agenda for today

Participants:
@aschemmel-tech (joined 20 min. late)
@RolandJentschETAS
@masc2023
@odra
@alekseyborisyukvalidas
@arsibo
@pahmann
@kroehnd

Minutes of Meeting:

Safety Audit Jan-14 to Jan-16: Feedback and next steps

• A good next step in the process definition and execution
• Many findings could be resolved, but not all, some new were found
• Updated Audit report is expected on Jan-30, will be published for v0.5
• Planned follow-up audit for next finding resolutions on Apr-14
• Planned audit for v1.0 changes on Nov-4 to Nov-6

Information from https://github.com/orgs/eclipse-score/discussions/516
https://github.com/orgs/eclipse-score/discussions/434
https://github.com/orgs/eclipse-score/discussions/2383

Feedback on #2346:

• Meeting @arsibo, @aschemmel-tech, @antonkri, @4og, @masc2023, @RolandJentschETAS on Jan-13
• agreement to implement alternative 2b, @aschemmel-tech added two comments to the PR to reflect needed updates identified in the meeting
• @arsibo agreed to prepare a proof of concept for 2b - planned to present next week Jan-27

Planning for v0.5 final - what do we want to have in this release (to do in the next two weeks):

• no changes and shifting around process documentation so the auditors still find what we showed last week (until the report on Jan-30)
• additions are fine, e.g. all the missing platform level safety documents from the safety plan (at least in draft state)
• do not do the "feature docs in module repos" change
  Info from Project Lead circle: No v0.5 final planned any more. We will do "milestone releases" about every six weeks so the new milestone v0.6 will be planned for Feb-22 (last date of the "sprint").

Removal/Addition of persons from/to CODEOWNERS (e.g. @PhilipPartsch) - update to be done by @aschemmel-tech for score repo and @masc2023 will do for process_description repo (maybe include @RolandJentschETAS after his committer election)

Planning for v1.0: eclipse-score/process_description#240 : show/discuss proposal by @aschemmel-tech

• Please everybody check the "score_v1.0_plan" for: what is missing? what would you like to take over? Is the priority (top to bottom) ok? - so we can discuss again on Thursday
• Added Docs-As-Code "Bug fixing" topic as proposed by @RolandJentschETAS
• Agreed to create Epics to document the "headlines" in the "score_v1.0_plan", @masc2023 for process_decription and @aschemmel-tech for process_execution (if not already existing), as preparation for Thursday
• @aschemmel-tech will take over "Draft docs" topic within Platform Safety Plan - need to align with @attilio who will join as future safety manager
• @odra will share his insights on the OS / QNX integration in Thursday meeting
• @aschemmel-tech shared updated "score_v1.0_plan" in score_v1.0_plan_discusssed.drawio

Info: eclipse-score/tooling#95 - work on automation to create SEooC documentation

@RolandJentschETAS : Proposed to modify the current approach how to document component archtitecture (only shows components within the componentes and not the internal interfaces) to align with the feature architecture (external and internal interfaces/ relations between components) - community agreed and @RolandJentschETAS will create a PR for this (and eventually present next Tuesday).

[aschemmel-tech]

Jan-27, 09-10 o'clock

Agenda:
Introduction
Check participants
Align on Agenda for today

Participants:
@aschemmel-tech
@PandaeDo
@RolandJentschETAS
@masc2023
@odra
@alekseyborisyukvalidas
@arsibo
@pahmann
@antonkri
@chidananda
@hoe-jo

MoM:

Feedback on #2346: - @arsibo agreed to prepare a proof of concept for 2b - postponed to Feb-3 due to technical problems in implementation

Planning milestones as in eclipse-score/process_description#240 - can be planned on releases via the "S-CORE Roadmap"

• Possible assignee as in EPIC: Define and Align Tools with Process Requirements process_description#520 (comment) - @masc2023 and @aschemmel-tech to do a separate meeting to explain better the scope to @chidananda on Jan-28 9:00

@odra to share his insights on the "OS / QNX integration" (planned in #536)

Detailed Design representation discussion:

• @RolandJentschETAS: "detail design as UML is only required for ASIL D, therefore to remove or tag it for ASIL D." (this is not fully correct, it is required from ASIL C onwards)
• @RolandJentschETAS: "real operation design by UML is to complicated -> remove ?"
• @aschemmel-tech : "No change to this can be expected for Iso 26262 Ed3"
• @aschemmel-tech : "But the "++" is also only required for semi-formal architecture representation and I think we agree we want to keep the static/dynamic views there? Anyway I am not sure we really can claim UML adherance so anyway this rather falls in the category "Informal Notations""
• @aschemmel-tech : "In S-CORE the detailed design views anyway do only show the break down of components into units, which can be seen as part of the SW architecture according to Iso 26262 and not of the detailed design (see requirements 6-7.4.4 and 6-8.4.4)."

Discussion result: Process community agreed to not model Units, Real Operations, Real Interfaces and Unit Tests as Sphinx needs - only use references but still allowing ULM pictures also for the Detailed Design documentation. @RolandJentschETAS to create a ticket documenting the need changes to metamodel, Implementation Process, Verification Process and cares for the presentation of this in the upcoming v1.0 safety audit.

Naming, OS Module, contains again SW Platform but means OS, where S-CORE also is called SW Platform
#2266 - agreed to use "Operating System" or "OS SW-Platform" instead of "Software Platform" as this is the "S-CORE SW Platform" as already discussed in #1740. @odra presented the content of the "AutoSD" PR, @aschemmel-tech will comment how to best document.

Present bazel link to workproducts / metamodel - eclipse-score/tooling#95 - first presentation by @hoe-jo

[aschemmel-tech]

Feb-03, 09-10 o'clock

Agenda:
Introduction
Check participants
Align on Agenda for today

Participants:
@aschemmel-tech
@PandaeDo
@RolandJentschETAS
@masc2023
@alekseyborisyukvalidas
@arsibo
@pahmann
@hoe-jo
@attilio
@anmittag
@hossam

MoM:

Audit feedback - no reply from Exida, @aschemmel-tech to remind (for eclipse-score/process_description#518)

Feedback on #2346: - @arsibo agreed to prepare a proof of concept for 2b

• process: DR-005 POC logging#52
  -> @arsibo presented the pull request, no turn around of feature -> stakeholder requirements, due to fear from cyclic dependencies and the stability of the stakeholder requirements.
  -> discussion about what shall be the content of the feature architecture - shall it answer the question "What components are used to implement a feature?" or only describe the external interface you can use for a feature. -> we will look at the PR and document our remarks, to hopefully resolve this next Tuesday meeting.

Planning milestones as in eclipse-score/process_description#240 - can be planned on releases via the "S-CORE Roadmap" - check PIM - Process Implementation Community (view) and PRC - Process Development Community (view) -> for the latter view, please all assignees make up their mind for wich release 0.7, 0.8, ... their epics should be planned and comment this in the epic - @masc2023 will set the right attributes then.

Detailed Design representation:

@RolandJentschETAS : ticket created? eclipse-score/process_description#540 assignee(s)? - assigned now

Verification Report tooling (#2521)? Do we model integration tests (and unit tests) as sphinx-needs elements? Better only in report? - not discussed, post poned

Crosscheck Security versus Safety Activities: eclipse-score/process_description#542 - @aschemmel-tech to review

PMP updates: #2481 -> describes planning, please review and learn!
eclipse-score/module_template#41

Initial Tool List: #2497 (See https://eclipse-score.github.io/score/pr-2497/score_tools/eclipse_score_tools_safety_evaluation_list.html) - not discussed, post poned

eclipse-score/process_description#524, Update for Dependable Element, https://github.com/orgs/eclipse-score/discussions/407#discussioncomment-15605348 -> removal of "Modules" need to be planned (for process and metamodel) - to be presented by @masc2023 again on Thursday Feb-05
eclipse-score/process_description#547

[aschemmel-tech]

Feb-10, 09-10 o'clock

Agenda:
Introduction
Check participants
Align on Agenda for today

Participants:
@aschemmel-tech
@PandaeDo
@RolandJentschETAS
@masc2023
@arsibo
@pahmann
@attilio
@anmittag
@hossam
@ravi
@kroehnd
@odra
@ramzy

MoM:

Audit report arrived, some documentation unclear - need to be resolved, "publishable report" still to be delivered by Exida - open findings documented in eclipse-score/process_description#518 sub-issues - we want to wait for the corrected report before starting the rework. @masc2023 : Proposal to prioritize the Project Planning related findings and work on this together in the community. So we will collect these actions and deviations in one task and discuss/resolve in the next meeting.

eclipse-score/logging#52 and #2346 - resolve open topics (e.g. how to link component requirements from other modules to feature requirements, inclusion of relevant platform work products, what to show in feature/platform architecture) @aschemmel-tech presented solution for this using new links via "Component AoU", @arsibo proposed to use the linking from Component Requirements to be able to say this "belongs to" an external "Component" - the last proposal shall be used to modify the Decision Record in a joint effort. The second topic: collecting all the artefacts relevant for a Delivery Container to be used as a SEooC is resolved by the proposal by @ramceb. Maybe also related is #2560. So in the end the main driver for this proposal is for the teams to be able to work independently from score platform repository (and from each other).

Verification Report tooling (#2521)? Do we model integration tests (and unit tests) as sphinx-needs elements? Better only in report? Pilot implementation in https://eclipse-score.github.io/persistency/main/persistency/kvs/docs/requirements/statistics.html suggests the following: the sphinx needs elements for the integration tests are created by tooling (currently only "testcase" element exists for this. In the metamodel this is depicted by the "dotted lines" starting from all the integration test boxes. Open topic: How do we deal with requirements which are only partly verified in this report - this is currently not covered by the implementation, but the requirements process foresees an attribute manually filled which documents that the currently linked testcases in sum verify a requirement completely.

Post-Poned to Thursday meeting Feb-12:

OS integration topic, present: #2515

Symbol report verification report is updated and waiting for checks if findings are solved #2544

#2497

[aschemmel-tech]

Feb-17, 09-10 o'clock

Agenda:
Introduction
Check participants
Align on Agenda for today

Participants:
@aschemmel-tech?
@PandaeDo?
@RolandJentschETAS?
@masc2023?
@arsibo?
@pahmann?
@attifunel?
@anmittag?
@hossam?
@ravi?
@kroehnd?
@odra?
@ramzy?

Agenda:

Audit news, eclipse-score/process_description#518 sub-issues are done, inconsistencies do not affect documented findings and deviations, separate ticket about Project Planning related findings not done, there is only one related finding in Safety Mgt. Asked Exida for corrections in report and also the "publishable" one.

OS integration topic, present: #2515 (maybe also answers the next point)

How to handle coding guidelines as enforced by the Operating System. Related to: #536 (added by @attifunel and @pahmann)

Verification Report tooling (#2521) Pilot implementation in https://eclipse-score.github.io/persistency/main/persistency/kvs/docs/requirements/statistics.html suggests the following: the sphinx needs elements for the integration tests are created by tooling (currently only "testcase" element exists for this. In the metamodel this is depicted by the "dotted lines" starting from all the integration test boxes.
Open topic: How do we deal with requirements which are only partly verified in this report - this is currently not covered by the implementation, but the requirements process foresees an attribute manually filled which documents that the currently linked testcases in sum verify a requirement completely.