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-001 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-001 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
@RolandJentschETAS
@masc2023
@arsibo
@pahmann
@attifunel
@hossam
@odra
@ANegm-ETAS
@alekseyborisyukvalidas

MoM:

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.

Tool List PR #2497 to get merged/ check the open items.

#2346 (revisited) - proposal how to distribute feature artefacts to score and module repositories derived by @aschemmel-tech, @arsibo, @RolandJentschETAS - no veto, but should be presented also in Thursday meeting. PR needs to be updated to show the actual proposal - @arsibo will update the PR and @RolandJentschETAS will do the technical implementation of metamodel changes if decided.

OS integration topic, present: #2515 (also answers the next point) - improvement proposals: tag and mark as "external" component, create a process requirement to cover the checking of used OS functions.

How to handle coding guidelines as enforced by the Operating System. Related to: #536 (added by @attifunel and @pahmann) - proposal to use safety manual numbering like in our standard section.

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. - @pahmann proposed to use a test set calling all the "partial" tests testing one requirement completely, @aschemmel-tech hinted that there is also a attribute foreseen in the requirements process (https://eclipse-score.github.io/process_description/main/process_areas/requirements_engineering/guidance/requirements_process_reqs.html#gd_req__req_attr_test_covered). - we will revisit this next Tuesday.

@masc2023 and @aschemmel-tech to resolve questions on eclipse-score/process_description#572

[aschemmel-tech]

Feb-24, 09-10 o'clock

Agenda:
Introduction
Check participants
Align on Agenda for today

Participants:
@aschemmel-tech
@RolandJentschETAS
@hoe-jo
@masc2023
@ravi
@alekseyborisyukvalidas

MoM:

Audit news, eclipse-score/process_description#518, Asked Exida for corrections in report and also the "publishable" one.

Thursday meeting will be moderated by @aschemmel-tech.

open PR:

(Change) Tickets: eclipse-score/.github#36 and #2481 - no progress on the open comments, discusss remark of @AlexanderLanin in Thursday meeting again if the colleagues are present. @RolandJentschETAS to inquire @anmittag if he needs input to resolve the comments.

Symbol report tool evaluation: #2544 - unclear what is the next step, are all compiler usecases (also structural coverage and unit testing) covered by the tool evaluation by Ferrocene.

Safety Mgt templates: eclipse-score/process_description#574 and #2600 - need to check updates if the comments are now solved

Design decision linking:
Reviews (like Architecture reviews) should consider if previous agreed design decisions are considered and fulfilled (for example in the architecture). To support that, an linking of the design decision to the affected work products/element (for example feat, component, static architecture, maybe also requirements) would be good. In "docs as code" is already a type "dec_rec" (decision record) which already contains an optional link "affects", which can link to anywhere. Nevertheless the link direction must be considered to avoid cyclic links again (link on same level/repo are ok). -> Currently the "Design Decision" template is not described by any process description. One possibility would be to link the "DD" to a change request in case it breaks the current architecture or any other work products in S-CORE. We need an epic to work on this. @aschemmel-tech will create.

[aschemmel-tech]

Mar-03, 09-10 o'clock

Agenda:
Introduction
Check participants
Align on Agenda for today

Participants:
@aschemmel-tech
@PandaeDo
@RolandJentschETAS
@odra
@hoe-jo
@masc2023
@alekseyborisyukvalidas
@ANegm-ETAS
@pahmann
@attifunel
Hossam

MoM:

Audit news, eclipse-score/process_description#518, corrected report received, the "publishable" one pending. Can start working on eclipse-score/process_description#518 - if you need the report now, ask @aschemmel-tech to send (confidentially).

Handling QNX safety manual restrictions within S-Core @ANegm-ETAS @pahmann @attifunel
#536 (comment) - use QNX restriction IDs as in standards. Need to find out about which QNX version to use e.g. 8.0.3. The list should be a "AoU needs" document containing a selection of the ones which are relevant for S-CORE. This could only be done by persons having access to the Safety Manual. Arguments for tailoring should probably be in a separate "private" repository. Also need to discuss this with QNX and our technical leads before. POC for this should be done and created a PR for it. @ANegm-ETAS will drive this.

Aligning S-Core FMEA Process with AIAG & VDA FMEA Handbook @ANegm-ETAS - Would we want to base our FMEA process on this - no, because we only do SW level dvelopment. The process is based on Exida guidance about SW safety analysis. No need to change for the moment.

open PR:

Symbol report tool evaluation: #2544 - feedback @alekseyborisyukvalidas - waiting on Ferrocene confirmation and documentation of the TÜV approval on their argumentation.

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. - @pahmann proposed to use a test set calling all the "partial" tests testing one requirement completely, @aschemmel-tech hinted that there is also a attribute foreseen in the requirements process (https://eclipse-score.github.io/process_description/main/process_areas/requirements_engineering/guidance/requirements_process_reqs.html#gd_req__req_attr_test_covered). - waiting for discussion in the testing community by @pahmann

Design decision process epic: #2625 - who volunteers? - @pahmann on the condition it is not for the next audit slot in April

Process requirements implementation: eclipse-score/process_description#589 - solution proposed by @PandaeDo - this applies to process requirements not fulfilled by docs-as-code but another tool of S-CORE (e.g. github), just check the two associated PRs. If you encounter missing docs-as-code implementation please contact @MaximilianSoerenPollak and the infrastructue community for other new needed tools.

Safety Mechanisms rework: https://eclipse-score.github.io/score/pr-2635/requirements/stakeholder/index.html#stkh_req__dependability__safety_features_1 ff and https://eclipse-score.github.io/score/pr-2635/requirements/platform_assumptions/index.html#aou_req__platform__hardware_safety - @aschemmel-tech will set the PR to review for this.

Extension of README with safety/security relevance
#2642 - information if the module is safety and/or security relevant could be derived from the according sphinx needs element - @RolandJentschETAS will propose this to @FScholPer. Discussion about representation of tool repositories and what should be "safety relevant" - should include also the "FFI" modules.

[aschemmel-tech]

Mar-10, 09-10 o'clock

CANCELLED - due to parallel "S-CORE Release 0.6 - Lessons Learned"

[aschemmel-tech]

Mar-17, 09-10 o'clock

Agenda:
Introduction
Check participants
Align on Agenda for today

Participants:
@aschemmel-tech
@PandaeDo
@RolandJentschETAS
@odra
@hoe-jo
@masc2023
@alekseyborisyukvalidas
@ANegm-ETAS
@pahmann
Hossam
@MaximilianSoerenPollak

MoM:
#2346 - merged, @RolandJentschETAS will start implementing together with @MaximilianSoerenPollak. @masc2023 will add the picture showing the distribution of work products to repositories as an example to our general process descriptions.

Release Lessons Learned meeting: https://github.com/orgs/eclipse-score/discussions/1595#discussioncomment-15998223 - open PMP rework: #2671 - lost of comments still open, all FT leads have to approve, will be discussed in "release team" meeting. @PandaeDo made an amendment to the process_description to align with the detailed S-CORE project process.

eclipse-score/process_description#599 - merged, linking of AoU - feature requirements can not be linked to component level AoU without creating cyclic dependencies (as soon as DR-001 is implemented). Addition after meeting: The described use case is very unlikely, so we do not work on an improvement for now.

eclipse-score/process_description#609 - When to write AoU? @pahmann suggested that all PR adding an AoU would need safety manager/engineer review, maybe by an automated process. @aschemmel-tech : safety manager should be involved latest in a inspection of the requirement/AoU

Symbol report tool evaluation: #2544 - feedback @alekseyborisyukvalidas - waiting on Ferrocene confirmation and documentation of the TÜV approval on their argumentation. - Ferrocene comment in #2544 (comment) may need breakout sesssion as proposed by @pawelrutkaq in his comment. @alekseyborisyukvalidas will get in contact and organize a meeting including @masc2023 and @aschemmel-tech.

Verification Report tooling (#2521) Pilot implementation in https://eclipse-score.github.io/persistency/main/persistency/kvs/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. - @pahmann proposed to use a test set calling all the "partial" tests testing one requirement completely, @aschemmel-tech hinted that there is also a attribute foreseen in the requirements process (https://eclipse-score.github.io/process_description/main/process_areas/requirements_engineering/guidance/requirements_process_reqs.html#gd_req__req_attr_test_covered). - waiting for discussion in the testing community by @pahmann, continue this week after absence of @pahmann

eclipse-score/process_description#535 - preview by Useblocks provided, solution may already be available next week, we need to think if/how we can use this solution for our "Impact analysis tool".

#2684 - @anmittag was asked to also make sure the decision about the new issue templates is now also implemented in the S-CORE repositories. For this maybe a common decision is needed in the Tech Leads Alignment meeting next week (@masc2023 will put it on the agenda there).

Proof of Concept for QNX safety manual restrictions @ANegm-ETAS - shown local PoC - will be created a PR from this to review.
Improvement proposal for FMEA layout @ANegm-ETAS - maybe covered also in @PandaeDo new PR #2667.

[aschemmel-tech]

Mar-24, 09-10 o'clock

Agenda:
Introduction
Check participants
Align on Agenda for today

Participants:
@aschemmel-tech
@odra
@alekseyborisyukvalidas
@ANegm-ETAS
@attifunel
Hossam
@clemens-k
@antonkri

MoM:

Publishable audit report arrived. Is only "management level", no actual findings contained, will be published in v0.7 release notes.

Open topics for Audit on April-14 (three weeks minus Easter) - see eclipse-score/process_description#518
Post-poned to next Thursday meeting due to the mostly non availability of assignees.

eclipse-score/process_description#535 - Versioned links implemented by UseBlocks: https://sphinx-needs.readthedocs.io/en/stable/changelog.html#release-8-0-0 - shown the updated functionality for sphinx-needs, @aschemmel-tech will consider this as a way to implement the impact analysis tool

post-poned to Thursday: eclipse-score/process_description#618, based on eclipse-score/process_description#418

#2702 - QNX restrictions proposal: commented in PR, discussed what to link this to, proposal was to architecture elements fulfilling the restrictions or test cases checking the fulfilment.

Discussion on Heap strategy @clemens-k: there is currently no written down/consolidated guideline how to deal with dynamic memory (only shall be avoided in runtime and is allowed in startup) - @aschemmel-tech recommended to address this to the architecture community.

@odra proposed to add a link to https://github.com/eclipse-score/os_images to the OS module information in S-CORE (including the documentation temlate). Will create a PR to propose this.

@alekseyborisyukvalidas asked @pawelrutkaq to arrange a meeting with Ferrocene on the Symbol report tool evaluation.

[aschemmel-tech]

Mar-31, 09-10 o'clock

Agenda:
Introduction
Check participants
Align on Agenda for today

Participants:
@aschemmel-tech
@masc2023
@ANegm-ETAS
@attifunel
Hossam
@RolandJentschETAS
@hoe-jo
Kishore
@OliverHeilwagen

MoM:

@aschemmel-tech : absent on Apr-7 - @masc2023 will moderate the meeting

Open topics for Audit on April-14 - see eclipse-score/process_description#518 - priority on "development processes", agenda proposal to be done based on this by @aschemmel-tech

eclipse-score/process_description#618, based on eclipse-score/process_description#418 need to discuss eclipse-score/process_description#621 link Component Req to Feature Architecture needed? @RolandJentschETAS to consider, @aschemmel-tech will create a change request issue to plan this, because this is a scope change, this is also related to the improvement to move the process examples (eclipse-score/docs-as-code#392 (comment))

Component architecture views not as expected, see e.g. https://eclipse-score.github.io/score/main/modules/baselibs/json/docs/architecture/index.html and need to discuss if "fulfils" and "belongs_to" are somehow redundant. @RolandJentschETAS will check how to correct the view generation, the "belongs_to" should stay in, because the component architecture views may not exist if there is no "sub-component" and thus no need for these views.

Introduction of platform architecture view needs - already in the deployment example: https://eclipse-score.github.io/process_description/main/_images/score_building_blocks_meta_model_deployment_example.drawio.svg - @RolandJentschETAS to include in metamodel and the process description. We may consider also a drawing function, but not at the moment.

#2702 - QNX restrictions coverage discussion, @aschemmel-tech to incorporate the "link to a coding guideline" approach.

RolandJentschETAS: How we go on with requirements for tooling addressed from feature requirements? For example for flatbuffer tooling (flatc) . See https://github.com/eclipse-score/score/pull/2720/changes#r2993400962 - should be documented as "tool_req", for this the need shall be also linkable to "feat_req" and the description in tool management process adapted (@RolandJentschETAS), please also add the tool to the tool list in score repository (@OliverHeilwagen).

eclipse-score/process_description#619 - open review comments, @masc2023 to reset @pahmann review if he is not available, @aschemmel-tech to approve

[aschemmel-tech]

Aug-04, 09-10 o'clock

Participants:
@aschemmel-tech
@PandaeDo
@RolandJentschETAS

MoM:

check items from Thursday meeting (e.g. turn around includes link)

Linking of log_arc_int_op to requirements. Mentioned in process requirements but not visible in drawings and mentioned in process. Also not in docs_as_code (@RolandJentschETAS ) - decision to remove from process requirements as also not used/in metamodel currently

Also discuss the optional "includes" link from logic_arc_int to logic_arc_int_op (see https://eclipse-score.github.io/process_description/main/process_areas/architecture_design/guidance/architecture_process_reqs.html#gd_req__arch_build_blocks_corr). What is it needed for? Usage example in https://eclipse-score.github.io/score/main/features/lifecycle/architecture/index.html#logic_arc_int__lifecycle__lifecycle_if - decided to remove the "includes", to do @RolandJentschETAS

#3137 - code coverage tooling, see also https://eclipse-score.github.io/score/main/platform_management_plan/software_verification.html#tools - llvmcov is the better tool, also used in S-CORE already widely, open issues: "QNX" only code could currently not be covered by llvmcov - for this we will introduce a (generic) checkpoint in the implementation inspection, also we need to plan for toolevaluation/qualification. @aschemmel-tech suggested to also put this on the agenda of the PL/FT synch on Monday (also due to the needed change in the Verification Plan).

Verification report proposal to have a look: eclipse-score/persistency#330 - maybe a bit hard to read.

[aschemmel-tech]

Aug-11, 09-10 o'clock

Participants:
@aschemmel-tech
@RolandJentschETAS
@masc2023
@AlexanderLanin
@ANegm-ETAS
@alekseyborisyukvalidas
@FScholPer

MoM:

Restructured module template starting page: eclipse-score/module_template#131 - already merged, folder structure to change in https://eclipse-score.github.io/module_template/main/template/index.html? - accepted by the community, @aschemmel-tech to update, @AlexanderLanin : to check why there are two "examples" entries

@AlexanderLanin to explain and discuss "code near" documentation support in docs-as-code v7.0.0 - as "expected" in the module template. - This works with "docs_bundle", changed the module template repo and one example which is in the lifecycle. Baselibs will use this soon. See also module_template/score/component_example/BUILD at main · eclipse-score/module_template and module_template/BUILD at main · eclipse-score/module_template

Discuss in case @aschemmel-tech and @FScholPer are present: eclipse-score/docs-as-code#682 and eclipse-score/docs-as-code#661 on inspection records/reports - @FScholPer will look into the comments and also create an example in one module repo.

Broken links (e.g. in https://eclipse-score.github.io/process_description/main/process_areas/architecture_design/guidance/architecture_inspection_checklist.html) ?
need to adapt the html links "manually" (we introduced this to get rid of the cyclic dependencies). todo @RolandJentschETAS

eclipse-score/.github#84 - should be a issue template for all inspection types and be described in the PMP. @aschemmel-tech will care for this.

#3137 - re-discuss after PL round. - There are two main questions:

1. Can S-CORE adopt the approach to do host unit testing and structural coverage analysis (on the host) plus target unit testing with the same (passed) test results but without structural coverage measurement?
2. Is it ok to not determine any structural coverage for the "QNX only" code in mixed or in seperate directories (and leave this to the distributor).
   There was no consent on these two questions, need to post-pone to Thursday meeting.

Question on file structure. why do we want the "src" folder? In include paths it is a bit inconvenient as it would have the "# include score/component_name/src" needed always. - from the process and tooling community members there were no blocking arguments against this. @aschemmel-tech will pursue this further, e.g. present/diacuss in the architecture community.

How could we avoid name conflicts in the include path? FTs would need to check in all other repositories in reference integration if the component name already exists. Could we automate this? - not covered

[aschemmel-tech]

Aug-18, 09-10 o'clock

Participants:
@aschemmel-tech
@RolandJentschETAS
@masc2023
@alekseyborisyukvalidas
@pahmann
@CryptoNutcase
@PandaeDo

Mom:

Revisit #3137
1. resolved on Aug-13: ask auditors for their opinion: Exida answer already given: see https://github.com/orgs/eclipse-score/discussions/407#discussioncomment-18018143
2. Is it ok to not determine any structural coverage for the "QNX only" code in mixed or in seperate directories (and leave this to the distributor).
Proposal from the PL meeting: for both topics: leave it to the distributor/user, write an AoU, use llvmcov instead of gcov in S-CORE. - process community agrees to the proposal. @pahmann and @RolandJentschETAS will work together to document this in the process description.

DFA has no failures list in the template https://eclipse-score.github.io/module_template/main/components/component_example/safety_analysis/dfa.html like for Platform/Feature Level - @PandaeDo to resolve.

Component Request and Component Architecture both have a "comp" needs in the template - where to delete? https://eclipse-score.github.io/module_template/main/components/component_example/index.html vs. https://eclipse-score.github.io/module_template/main/components/component_example/architecture/component_architecture.html - let's have it in the component request. @RolandJentschETAS to adapt

Agreed in PL sync: <module_root>/score/<component_name>/ instead of <module_root>/score/<component_name>/src is ok. Will update process description. New request from the PL/FT link: can we give up a common file structure in modules entirely or should it stay - aligned between the FTs. @aschemmel-tech to start with the discussion in FTs and write a DR for this.
Connected to this: @RolandJentschETAS will write a DR which discusses the use of /include folder (but the outcome will be: no "/include" will be used).

How could we avoid name conflicts in the include path? FTs would need to check in the list of existing components (derived from bazel registry) if the component name already exists. Could we automate this? - @AlexanderLanin answer: currently not feasible - process community currently this does not see as a severe risk, so would not write a process requirement for this.

Complying with naming conventions:
eclipse-score/process_description#776 - align the bazel module name with the repository name - agreed the PR proposed and merged.

Discussion on Clippy configuration (for Rust static code analysis). There is already an analysis available outside of S-CORE but it seems this is proprietary and we cannot use it. Therefore the PR of @RolandJentschETAS is blocked. See #2984 and
eclipse-score/score_rust_policies#11. The Rust coding rules S-CORE adopts is defined in the PMP / SW Development Plan and points to https://coding-guidelines.arewesafetycriticalyet.org/ - which is open source but work in progress and it also lacks a Clippy configuration. Proposal is for @RolandJentschETAS to try to map the Clippy configuration to this guideline as it is (based mainly on the headlines).

@aschemmel-tech in holidays next three weeks. @masc2023, @RolandJentschETAS and @pahmann will share the meeting hosting.

[masc2023]

Sep-01, 09-10 o'clock

Participants

@AlexanderLanin
@RolandJentschETAS
@pahmann
@chetanb-qorix
@rakcs
@masc2023

Agenda

Request: documents should link what they document

Clarify: versioning

Clarify Ownership of Module Verification Report Template

Meeting Notes:

Documentation topic:
Currently documentation only links to the work product it realizes, https://eclipse-score.github.io/process_description/main/process_areas/process_management/guidance/process_management_templates.html

Compare also https://eclipse-score.github.io/docs-as-code/main/reference/metamodel/#document

Request: documents should link what they document wants to have an additional link to the e.g. module/component/feature it belongs to.
Decision: Add optional link "belongs_to" to the document directive. Update the relevant places in the documentation.: What to change in process_description (https://eclipse-score.github.io/process_description/main/process_areas/process_management/guidance/process_management_templates.html) ? module_template? (@RolandJentschETAS ) -> doc-as-code changes ( @AlexanderLanin)

Versioning topic: Clarify: versioning
Versioning of individual "elements" is required for requirements only. Is that correct?

Rephrase the question, Versioning of individual sphinx-needs elements, is that required. Currently only defined for requirements. https://eclipse-score.github.io/process_description/main/process_areas/requirements_engineering/guidance/requirements_process_reqs.html#gd_req__req_attr_version.
As long as they are dependencies, e.g. Module Safety Plan depends on Platform Safety Plan, versioning is wanted. But Reports just collect data for at a certain time, e.g. Module Verification Report, so they do not need versioning.

Currently Versioning of individual sphinx-needs elements in process_description is not correct defined, needs to be updated and e.g. Reports are excluded (@masc2023 ), module_template, -> doc-as-code changes ( @AlexanderLanin), Will talk again on thursday meeting, if reports only is agreed.

Regarding Code Coverage, Measure on Target:
#3137

Discussion needed again, what is the potential target? Wait until @aschemmel-tech is back to discuss the topic again.

Discuss Template Ownerships:
E.g.
Clarify Ownership of Module Verification Report Template

Now templates are part of doc-as-code, e.g. Module Verification Report. So the existing template can be removed, but the content should be formulated as requirements. Follow-up with that on thursday, discuss also potential maintainers, proposed https://github.com/eclipse-score/module_template/blob/main/.github/CODEOWNERS#L25

[CryptoNutcase]

Sep-08, 09-10 o'clock

Participants

@chetanb-qorix
@rakcs
@CryptoNutcase
@alekseyborisyukvalidas
Olaf Franke
Rakesh
@Janis-dev

Meeting Notes:

No new points were discussed.
For next meeting (Sep-15), discussion points captured from Sept-01 meeting to be continued.

[RolandJentschETAS]

Sep-15, 9:00-10:00 o'clock

Participants:

@RolandJentschETAS
@PandaeDo
@alekseyborisyukvalidas
@janis-qorix
@MaximilianSoerenPollak
@rakcs
Olaf Franke
@aschemmel-tech
@chetanb-qorix

Agenda:

See last meetings (nothing done due lack of participants):

• General: https://github.com/orgs/eclipse-score/discussions/407?sort=new#discussioncomment-18234097
• Safety: https://github.com/orgs/eclipse-score/discussions/2234?sort=new#discussioncomment-18215139

Raised by @FScholPer: Question what should be the ground truth list of verification report items: https://eclipse-score.github.io/reference_integration/main/process_methods_tools/score_process_description/process_areas/verification/verification_workproducts.html#wp__verification_module_ver_report or https://eclipse-score.github.io/module_template/main/verification_report/module_verification_report.html?

Rust certification in S-CORE: gap analysis and plan (September 2026)
https://github.com/orgs/eclipse-score/discussions/3254#discussion-10812157

Open PRs:

eclipse-score/module_template#176

#3137 (comment)

• plus: https://eclipse-score.github.io/process_description/main/process_areas/verification/guidance/verification_methods.html#structural-coverage has to be updated.
• also it is not quite clear in the process/project documentation if we do execute the unit tests on the target at all. Pro: https://eclipse-score.github.io/score/main/requirements/platform_assumptions/index.html#aou_req__platform__testing, https://eclipse-score.github.io/process_description/main/process_areas/verification/guidance/verification_guideline.html#tailoring; Con: no mention in the verification process / test report template, or is it covered in https://eclipse-score.github.io/score/main/platform_management_plan/software_verification.html#test-execution-environment-and-reference-hardware?

Other topics

MoM:

• General: https://github.com/orgs/eclipse-score/discussions/407?sort=new#discussioncomment-18234097
  Currently Versioning of individual sphinx-needs elements in process_description is not correct defined, needs to be updated and e.g. Reports are excluded (@masc2023 ), module_template, -> doc-as-code changes, reports only is agreed.
  Action Item: Create a list, where versioning is used in the process description, currently it is only define in requirements engineering for requirements, https://eclipse-score.github.io/process_description/main/process_areas/requirements_engineering/guidance/requirements_process_reqs.html#gd_req__req_attr_version, @aschemmel-tech will prepare a proposal

New standard to be added, @rakcs will implement it, tracked here, eclipse-score/process_description#789, starting only with folder creation first

Discussed concern from @FScholPer above,
official work product is in process_description, it describes only the required content, so it is the ground truth,
https://eclipse-score.github.io/reference_integration/main/process_methods_tools/score_process_description/process_areas/verification/verification_workproducts.html#wp__verification_module_ver_report

verification report is automatically generated using this template here: https://github.com/eclipse-score/docs-as-code/blob/main/src/needs_templates/module_verification_report.need

Compare:
The verification report is generated automatically by the codeblock above by the tools and contains all the needed information for the module verification. The report is based on the module verification plan and workproduct module verification product

Example here:
https://eclipse-score.github.io/lifecycle/main/verification_report/index.html

Is based only one https://github.com/eclipse-score/lifecycle/edit/main/docs/verification_report/index.rst

which is also described here.
[(wp__verification_module_ver_report) and covers all the components of the module.](https://eclipse-score.github.io/module_template/main/verification_report/module_verification_report.html)

@AlexanderLanin raised a concern, that the module_template repo is a mix of templates, and guidelines, @RolandJentschETAS will make a proposal for better usability for the Module Verification Report Template

Checkout latest discussion on Rust, Safety Certification
Rust certification in S-CORE: gap analysis and plan (September 2026)
https://github.com/orgs/eclipse-score/discussions/3254#discussion-10812157

Discussed #3137: @RolandJentschETAS proposed three approaches for coverage analysis of the "target only" code by unit tests:

• generally the unit tests will be exacuted by S-CORE on host (plus coverage measurement) and (reference) target, so unit tests must exist for this target code (to explain this better in the documentation @aschemmel-tech will setup a meeting with @RolandJentschETAS next week to find a solution)
• If the code part is small we could do a manual analysis
• clang could be used to also compile for QNX OS reference target (would need to be clarified if already possible)
• Coverage measurement by using gcov to include in S-CORE for these parts only

[aschemmel-tech]

Sep-22, 09-10 o'clock

Participants:
@aschemmel-tech
@RolandJentschETAS
@alekseyborisyukvalidas
@PandaeDo
@janis-qorix
@AlexanderLanin
@chetanb-qorix
@pahmann

MoM:

• Clarify: versioning process_description#785: see content added by @aschemmel-tech - but see @masc2023 input via email. - general opinion is to rather have less versioning (manually) especially for documents. Currently we would want to have the versions only where it supports our impact analysis. To remove the versions from documents again we could make these optional. @masc2023 needes to be involved in the decision still.
• Handling of "inspection review checklist" including status "valid (inspected)". @aschemmel-tech provided example https://eclipse-score.github.io/baselibs/main/baselibs/components/bitmanipulation/requirements/chklst_req_inspection.html and will add the PR which additionally show how it was done. @aschemmel-tech to ask infrastructure team to implement the valid(inspected) state.
• Feature integration tests in the reference integration repository (these could include the "originals" and not the copies from the module). See also Feature integration test in our example module communication#546. Both ways make sense, Currently the decision is based on "who creates the test" - integration/test team or module team. Should be discussed with integration and testing communities by @pahmann.
• tool verification/classification/qualification - @AlexanderLanin need someone for discussing it. https://eclipse-score.github.io/docs-as-code/pr-831/how-to/perform_tool_verification.html - @alekseyborisyukvalidas to review the PR and @aschemmel-tech will team up with @AlexanderLanin to answer his questions and improve the process description.

[aschemmel-tech]

Sep-29, 09-10 o'clock

Participants:
@aschemmel-tech
@antonkri
@masc2023
@RolandJentschETAS
@alekseyborisyukvalidas
@PandaeDo
@AlexanderLanin
@pahmann
@a-zw
@rakcs
@MaximilianSoerenPollak

MoM:

• Outcome versioning discussion @masc2023 / @aschemmel-tech : see Clarify: versioning process_description#785 (comment) - @aschemmel-tech to create the PR Nr. 1 - @pahmann may have additional proposal around testcase to requirement version linking.
• Question: Do we have something as a list to show which work products are QM and which are safety related?
  (e.g. inspection is only for safety-crticial, but we also have QM components who do not need it) - maybe the answer is here: https://eclipse-score.github.io/score/main/platform_management_plan/quality_management.html#quality-management-generic-work-products (but maybe this is also outdated as it contains safety artefacts) - no, this is a list of all documents QM would check. This includes all safety "only" workproducts. Proposal is to have this information given in the module template like https://eclipse-score.github.io/module_template/main/template/index.html. @pahmann will create a ticket to resolve. @aschemmel-tech to create a ticket to correct/update the quality-management-generic-work-products list.
• How to trace "satisfies" of component requirements for sub components process_description#534: Do we have to add sub-components for complex components? - Conclusion was that we do not have additional requirements levels but link the component requirements (maybe modified) to the "sub" component we generated.
• Asked again by the baselibs feature team: how can we use the testcovered attribute (as part of which process ...)? See also this older discussion: https://github.com/orgs/eclipse-score/discussions/2234#discussioncomment-17335819
  • See also this idea: https://github.com/orgs/eclipse-score/discussions/3292 - please read this proposal and comment in it, probably including the versioning "problem". Maybe we even have better ideas how to do it. Will re-discuss next week Tuesday.
  • Here it is described in the verification process: https://eclipse-score.github.io/process_description/main/process_areas/verification/verification_workflows.html#wf__verification_req_test_coverage
• Split of feature integration tests. See split feature integration test place process_description#793 (from @RolandJentschETAS) - general agreement, PR to be merged
• Teams want to discuss if additional requirements stated "post_poned" or "not_planned" for component requirements (from @RolandJentschETAS) - no, we already have the Valid-From/Until attttribute for this, @aschemmel-tech to add in the process description the component level and that it always relates to the platform level versions.

[aschemmel-tech]

Oct-06, 09-10 o'clock

Participants:
@aschemmel-tech
@antonkri
@masc2023
@RolandJentschETAS
@alekseyborisyukvalidas
@PandaeDo (only for first agenda item)
@pahmann
@a-zw
@MaximilianSoerenPollak

MoM:

• Document mgt process states that the Doc Mgt Plan as part of the PMP shall contain all documents and their status (see https://eclipse-score.github.io/process_description/main/process_areas/documentation_management/guidance/documentation_guideline.html). Since the split and restucturing into score/modules directories - is it complete in the reference integration? See https://eclipse-score.github.io/reference_integration/main/process_methods_tools/score_platform/platform_management_plan/documentation_management.html#docs-modules which contains also module repo docs. Could we structure this better? - @PandaeDo will make a proposal - to have one DMP containing every document plus better structure. Also there should be a document list. But this relies on folder structure as defined in https://eclipse-score.github.io/score/main/contribute/general/folder.html#module-folder-structure - we should remove the "However if there are good reasons the structure can be adapted."

• From FT Lifecycle (performing feat arch inspection): ARC_02_04 has questions about error returns and input/output, this is currently unclear how to answer/resolve due to the "logical" nature of interface definitions - what is the expectation for feature level? Example answer see: https://eclipse-score.github.io/baselibs/main/features/architecture/chklst_arc_inspection.html - What about the input/output topic? Should we differentiate the checklist instructions feat/comp? Need to define what should be described in IF definition and possibly also dynamic view. - Interface definition expects "General Interface Description" (https://eclipse-score.github.io/process_description/main/folder_templates/platform/features/feature_name/architecture/index.html#logical-interfaces) - should be improved, ticket for @RolandJentschETAS.

• How do we show in the verification report the coverage of "non-functional" requirements or other requirements which we do not test but "analyze" (currently to be documented in the requirement inspection, see REQ_08_02 in https://eclipse-score.github.io/module_template/main/components/component_example/requirements/chklst_req_inspection.html#checklist)? Example: https://eclipse-score.github.io/baselibs/main/verification_report/module_verification_report.html#bit-manipulation : proposals: create a test case rst file or combine this with the solution for the "fully verified" - ticket to create for @pahmann

• volunteers for tool evaluation? - no additional, but maybe good candidate for a AI support.

• PR used the "version" instead the "tool version" attribute - pytest tool verification report #2717 needs to be corrected. And also the process description has to be updated (https://eclipse-score.github.io/process_description/main/process_areas/tool_management/guidance/tool_management_reqs.html#gd_req__tool_attr_version).

• reference_integration: DR-008 reloaded: what exactly does the "process community" require to be (re-)run in the reference_integration?

  • Platform and Feature Tests? Yes - that is already clearly stated in the DR-008, plus Feature tests stored in the module repo.
  • Documentation? Yes - because only in reference_integration can the back-links be established
  • Component/Unit Test? ???
  • Stuctural Coverage? ???
  • Static Code Analysis? ???
    General opinion is that the Component/Unit Test and structural coverage analysis have to be performed with the dependencies as defined in the reference_integration (as also explained in DR-008 Option 4, the "selected" one). Also there should be a consistent set of test results for one platform release created. And the best place for this is the reference_integration. We should describe better in the process description (or the PMP) what the use of this repository is.

[aschemmel-tech]

Oct-06, 09-10 o'clock

Participants:
@aschemmel-tech
@RolandJentschETAS
@alekseyborisyukvalidas
@PandaeDo
@antonkri
@a-zw
@CryptoNutcase
@janis-qorix
@rakcs

MoM:

• Question of @antonkri : would it be ok to use special needs type for module and platform verification report (instead document): general agreement.

opened issues:

• Improve guidance on interface documentation process_description#812
• Verification coverage of non-functional requirements process_description#813

Prepare Audit Agenda (work in progress): eclipse-score/process_description#828

• Wednesday, Nov-04: Supporting Processes (fixes)
  • Status, which modules shall be "safe" for v1.0
  • Safety Mgt (plus "qualification of software components") - Fix Safety Mgt Audit findings process_description#556 @aschemmel-tech - 1 deviation, 5 action, 19 open (maybe shift two on "safety anomaly" to Problem Mgt?)
  • Problem Mgt - @masc2023 - Fix Problem Mgt Audit Findings process_description#557 - 4 action
  • Quality Mgt - @masc2023 - Fix Quality Mgt Audit findings process_description#562 - 1 action
  • Change Mgt - @masc2023 - Fix Change Mgt Audit findings process_description#567, 1 deviation, 1 action, 5 open
  • Release Mgt - @aschemmel-tech - Fix Release Mgt Audit findings process_description#558 - 3 open
• Thursday, Nov-05: Development Processes (fixes, updated process definitions, process execution examples)
  • Requirements - no major updates, example module, inspection status - @aschemmel-tech - no findings
  • Architecture - no major updates, example module, inspection status - @RolandJentschETAS - no findings
  • Safety Analysis - show analysis improvements (root cause, safety relevance) @PandaeDo - Resolve #7 Audit Findings (14.04.2026) process_description#652 - 2 action
  • Implementation (update: optional DD) - @PandaeDo & @RolandJentschETAS - Resolve #7 Audit Findings (14.04.2026) process_description#652 - 2 action
  • Verification - @pahmann - Resolve #7 Audit Findings (14.04.2026) process_description#652 - 3 action
• Friday, Nov-06: Supporting Processes (fixes)
  • Tool Mgt - @aschemmel-tech - Audit preparation: Tool management process_description#81 - 3 action, 13 open
  • S-CORE AI concept - DR docs: add DR-011 AI agent context packaging tooling selection #3188, @masc2023 proposal Pilot for AI supported development process execution in safe context process_description#805, AI team Ai platform update #3260, docs: Complete AI tooling evaluation and selection for S-CORE #3307 - agreement is to show the "concept" but need to agree on who and what exactly.

Discussion about how to make the checklist template updates - proposal is not to only rely on versions but use AI instead.

[aschemmel-tech]

Oct-20, 09-10 o'clock

Participants:
@aschemmel-tech
@alekseyborisyukvalidas
@PandaeDo
@a-zw
@janis-qorix
@AdhamN861

MoM:

discuss eclipse-score/process_description#556 Action_70 - we agree that we think it sufficient that the distributor and the user of S-CORE will check the quality of testing, and we have test reporting for coverage ... Maybe add a role description for the test expert already active in requirements inspections.

https://github.com/orgs/eclipse-score/discussions/434#discussioncomment-19035366 TL-meeting: show in the audit that the process is complete and some "end-to-end" examples. It is not a goal to show all our (safety) v1.0 module's work products. @aschemmel-tech and @PandaeDo invited to Oct-22 TL meeting (14:00).

The current Coding Guidelines reference MISRA C++, but they do not identify the specific rules or restrictions that should be enforced. Do we plan to adopt a defined subset of MISRA rules and align CodeQL checks with that ruleset? - @RolandJentschETAS, @pahmann and @FScholPer were involved in this and should be contacted for current status - we are sure there is some work on this already started but not finished.

[aschemmel-tech]

Oct-27, 09-10 o'clock

Participants:
@aschemmel-tech
@alekseyborisyukvalidas
@PandaeDo
@masc2023
@janis-qorix
@AdhamN861
@RolandJentschETAS
@chetanb-qorix
@rakcs
@CryptoNutcase
@AlexanderLanin

MoM:

discuss #3341 - needextend ok if used in one file, also checked by docs_as_code that this is the case (see https://eclipse-score.github.io/docs-as-code/main/how-to/write_docs.html#needextend)

Audit Agenda revisit, see eclipse-score/process_description#828 - no additional points

What to do with (very valuable) detailed design documentation, which is optional in our process, but not documented by sphinx needs, e.g. https://github.com/eclipse-score/baselibs/blob/main/score/result/README.md - put in "the right folder", modify to "sphinx needs"? Outcome: we do not need to have "sphinx needs" elements. If one wants to add the md file in the documentation this is possible via "sphinx" and putting the file in a "documentation" folder. But we do not require this.

"component requests" - alignment needed? are we happy with what is in the template? https://eclipse-score.github.io/module_template/main/components/component_example/index.html - https://eclipse-score.github.io/persistency/main/components/kvs/index.html - https://eclipse-score.github.io/baselibs/main/baselibs/components/bitmanipulation/index.html - overall opinion: we should strive to unify the documentation. Contentwise maybe we want to add a "Motivation" section. @janis-qorix will try to make a proposal.

please review/merge release notes eclipse-score/process_description#833

Proposal Contributor Training:
• Fictive Training_Module: real template, process, tooling
• Seeded defects; every task an issue, closed by PR with green CI
• Stages: 0 environment + ECA · 1 Git · 2 build · 3 process · 4 review · 5 module (template update, rebase) · 6 cross-review, FDR
• Tracks: Developer · Quality · Safety · Security
• About one week, self-paced
Need to create eclipse-score/contributor_training for that. No support on it. Will be created and maintained by @PandaeDo and @janis-qorix if agreed. - general agreement that we want this in S-CORE, @AlexanderLanin will support setting up the repo.

Short look at https://github.com/orgs/eclipse-score/discussions/3311

Discussion on coding rules: Ruleset should be defined on S-CORE project level. Topic was discussed in TL/FT sync: agreement was to use the existing setup from https://github.com/eclipse-score/communication/blob/main/quality/static_analysis/misra_gep.md - ruleset PR to be created by @AdhamN861 in sync with @LittleHuba

[janis-qorix]

Analysis and proposal in PR #231

[masc2023]

Nov-03, 09-10 o'clock

Participants:
@aschemmel-tech
@PandaeDo
@RolandJentschETAS
@alekseyborisyukvalidas
@masc2023
@anmittag
@janis-qorix
@CryptoNutcase
@chetanb-qorix
@rakcs
@a-zw

MoM:
Merge of open PR, eclipse-score/process_description#853,
-> Patch-Release required, also need some Basline for Audit - @masc2023 intends to do a process_description, score, module_template release today EOB
-> should be merged today as @RolandJentschETAS and @pahmann already agreed on the open topics.

Timeplan Audit ok? - yes

Status/Location mismatches safety analysis: https://eclipse-score.github.io/persistency/main/ - persistency&kvs in name, security labels, status safety analysis fdr

@anmittag : is there any procedure of breaking down the safety relevant stakeholder requirements e.g. a)safe_communication -> e2e_communication protection etc? - No there isn't, it could be derived from a platform level safety concept which we do not have at the moment. Only the list of Safety Mechanisms

eclipse-score/docs-as-code#943 is about changing the decision record linking - might be problematic as it requires a mandatory requirement link for the DR, @RolandJentschETAS blocked it.

[aschemmel-tech]

Nov-10, 09-10 o'clock

Participants:
@aschemmel-tech
@PandaeDo
@RolandJentschETAS
@alekseyborisyukvalidas
@masc2023
@pahmann
@janis-qorix
@a-zw

MoM:
Planning safety tasks for v1.0:

• Epic: Implement Platform Safety Plan #2465
• Tool Verification for S-CORE v1.0 #3418
  these are part of the "product increment" for v1.0 - PL's say there will be the release for this also with open audit findings and missing work products. We will state this in the release.

Feedback from the Audit last week - @aschemmel-tech will update/create respective tickets for finding resolution. It is planned to get a publishable audit report until end of November.

common directory folder for source code files, which are used in multiple components. Is it possible to use this code from ASIL and QM components, if this code is developed according to ASIL? - process community approves this. Is it necessary (for FFI) to generate an own component for the wrapper (interface) in such a case ? - opinion in the process community is: no

@RolandJentschETAS will make the structure proposal in the project lead / Feature Team Lead sync so that all FTs can approve.

• remove module folder structure from score main and maintain the folder structure in the module template only (replace module folder structure in score main by link to module template) ? - as this is currently maintained twice, process community agrees

• src subfolder below score folder - @aschemmel-tech thinks we already had a discussion an decision about this, will check and come back to @RolandJentschETAS with the info.

src/ is used in several S-CORE repos, but it is not a consistent convention across them. Some use it for production code; others keep C++ sources directly under score/... or use a directory named code.

show-github-search-result

src/ is used in several S-CORE repos, but it is not a consistent convention across them. Some use it for production code; others keep C++ sources directly under score/... or use a directory named code.

Module	Is src/ used for source?	Example
ai_platform	Yes	src contains the component’s .cpp and .hpp files. The root src/ is only an empty Bazel package.
baselibs	Not in the C++ paths found	Files such as score/os/grp.cpp are directly under score.
communication	Not in the C++ paths found	Files such as score/mw/com/runtime.cpp and score/memory/shared/map.cpp are directly under score.
config_management	No for component code	Component code uses score/.../code/; the root src/BUILD is empty.
feo	Yes	Rust crates use paths such as src/feo/src/ and src/feo-time/src/.
inc_ecu_model	Yes, in a limited area	Python generator code is under score/generators/src/; most Python modules are organized directly under score.
inc_security_crypto	Yes	C++ files include score/crypto/src/daemon/src/daemon.cpp.
kyron	Yes	Rust crates use src/<crate>/src/.
lifecycle	Yes	Examples include score/health_monitor/src/cpp/ and score/launch_manager/src/daemon/src/.
logging	Yes	C++ source includes score/datarouter/src/; other code is also outside src/.
persistency	Not in the C++ component paths found	C++ files such as score/kvs/kvs.cpp are directly under score/kvs/.
scrample	Yes	C++ sources are under root src/; generated application examples also use src/.
time	Yes	Components include score/time/clock/src/ and score/time_daemon/src/.

This supports the earlier assessment: src/ is a valid pattern to document in the template, but it should be presented as the template’s chosen layout, not as a universal existing S-CORE module convention. The repo checks were against the public main branches; for the “not found” cases, I’m referring to the primary C++ component-source paths, not claiming there can be no unrelated src/ directory anywhere in each repository.

• Process requirement (for infrastructure) to visualize the test techniques (component verification report addon) - process community agrees this would be a nice thing to have (see example in docs-as-code as shown in audit). @pahmann to propose a solution which should avoid to clutter too much the already full module verification reports.
• ...

Invalid and expired requirements – #864

Combined proposal; #865 and #866 are merged into it.

Problem

• Valid requirements and tests can link to invalid requirements, and no check stops it (e.g. comp_req__kvs__snapshot_max_num)
• A requirement with valid_until: vN is not part of vN, but its status stays valid

Proposal

• status: invalid = withdrawn for all releases, so all references are removed in the same PR
• valid_from / valid_until = in force only for some releases, status stays valid
  • in release vN ⇔ valid_from ≤ vN < valid_until; a comp_req inherits the range via derived_from
  • once valid_until is reached, the requirement may be deleted from main; earlier releases keep it in their branch or tag
  • coverage and completeness checks only count requirements in the release; future requirements only get formal checks (this resolves the TBD in gd_req__req_validity)

Tool support (docs-as-code 8.6.0)

• Check that valid needs link only to valid needs exists, but only warns, so it needs to fail the build
• Validity ranges along links
• Tests may only verify valid requirements
• report_version filters on valid_from; valid_until and status still need to be added

Decision needed: Agree on the proposal, then open the matching tool requirements in docs-as-code.

Discussed in the process community. We agree that invalid status should still be allowed. Also valid_from/until needs to be taken in to account. Maybe a solution is to copy only valid work products into the reference_integration (for one release). So the community members are encouraged to comment @PandaeDo's proposal, but it may need re-discussion in the plenum.

@pahmann proposes to have some checklist for "standard" PR checks, e.g. "Was the version of work products properly updated?" - so we have some guideline also for QM/walkthrough type reviews. - proposal to be created as a PR.

[aschemmel-tech]

Nov-17, 09-10 o'clock

Participants:
@aschemmel-tech?
@PandaeDo?
@RolandJentschETAS?
@alekseyborisyukvalidas?
@masc2023?
@pahmann?
@janis-qorix?
@a-zw?

Agenda:

Discuss mandatory :mitigated_by: see eclipse-score/baselibs#774 (comment)