Eclipse S-CORE
General SW Dev Process Community - Meeting Minutes #407
Replies: 86 comments 20 replies
|
Time: Agenda: Warnings stopping doc build Participants: Meeting Minutes: |
|
Time: Agenda: General Traceability Concept, #343 Participants: Meeting Minutes: |
|
Time: Agenda: Participants: Meeting Minutes: Release Management Ticket #313 may have to be taken over by other person, to be discussed on next Process Community Meeting Alignment Eclipse Safety Process / Trustable SW / S-CORE / … Alex gave Feedback from AUTOSAR workshop, outcomes: #809 Verification Process Tickets: https://github.com/eclipse-score/score/pulls?q=is%3Aopen+is%3Apr+label%3Acommunity%3Atesting |
|
Mar-25, 9-10 o'clock Participants: Agenda:
Meeting Minutes:
|
|
Apr-15, 9-10 o'clock Participants: Agenda: Quality Management, #835 Meeting Minutes: Discussed topics for the up-coming workshop at BMW on 23.04/24.04.2025 Discussed latest proposal: link implementation to architecture Discussed Quality Management, Follow-Up Planned for 15.04.2025, 14:15-15:15, @PandaeDo will invite |
|
Apr-29, 9-10 o'clock Participants: Agenda: Meeting Minutes: Create Ticket to create TSF in Sphinx-Needs, and link to S-CORE processes initially to find gaps and vice versa, @masc2023 As example see here: https://gitlab.com/CodethinkLabs/safety-monitor/safety-monitor/-/tree/main/trustable/safety-monitor-expectations?ref_type=heads Release Management shall be released as next. |
|
May-06, 9-10 o'clock Participants: Agenda: Meeting Minutes: Planning Update for Next Milestone done, Quality Management Review Meeting, 07.05.2025, 9-10, @aschemmel-tech , @masc2023 , @PandaeDo will invite Feedback Pilot Projects: (EPIC Process Pilots #760) @aschemmel-tech presented some review findings, improvement tickets to be created, topics: Renaming of Concept Description, e.g. to Process Description, improvement of Change Management Request, more explicit description about responsibilities for different Requests, Rework of Contribution, remove word "Contribution Request", Discussed about FMEA/DFA, separate Meeting will be setup, considering from the begin Safety/Security |
|
May-20, 9-10 o'clock Participants: Agenda: Decide to delete now process folder in doc to avoid inconsistencies, not merged PRs, which have input for process folder in doc should be separated
Meeting Minutes: Max will try a bugfix for #1103 proposed by Jochen today Alexander will prepare the PR to delete the score/docs/process folder if Volker can build locally Decision for eclipse-score/process_description#13 : Max will disable the check for all foldernames below process_description/process Question on the "Platform DFA" - what do we link it to:
Alexander presented his work on the folder templates |
|
May-27, 9-10 o'clock Participants: Agenda:
Meeting Minutes: Audit Findings discussed, Tickets assigned Template folder will be updated with document header by @aschemmel-tech, Process Requirements implementation, @aschemmel-tech will discuss with @MaximilianSoerenPollak , @AlexanderLanin |
|
June-03, 9-10 o'clock Participants: Agenda: Meeting Minutes: Tool Requirements will be created, Prototype as Doc-as-code, How to link Tool Requirements: Link will be done from Tool-Repo to the Process_Description, Where to locate the Tool Verification Report is not clear yet, must be defined -Bazel check "link the same issue" means that we have to generate an issue for every wp. Do we want this? NO -Platform DFA question from last meeting Safety Analysis and Quality Management are now pushed to process_description, ready-for-review Reviewer for Pilot Persistency needed: @kroehnd Folder Template is missing "Implementation Template", @aschemmel-tech will updated it, done, with eclipse-score/process_description#29 |
|
June-10, 9-10 o'clock Participants: @PandaeDo Agenda: Meeting Minutes: |
|
June-17, 9-10 o'clock Participants: @PandaeDo Agenda: Meeting Minutes: |
|
June-24, 9-10 o'clock Participants: Agenda:
Meeting Minutes:
|
|
July-01, 9-10 o'clock Participants: Agenda: Discuss Bugfix Template: eclipse-score/communication#25 Meeting Minutes: @hoe-jo proposed problem, improvement templates, will be used as basis for score Component Folder in Score discussed (Component Register), audience would propose to follow up with that Implementation Checklist IMPL_01_02 possible removal/update discussed, shall be removed @aschemmel-tech |
|
No meeting on 09.07.2026 due to absence of many people (vacation season) |
July-16, 9:30-10:30 o'clockParticipants:@PandaeDo Agenda:module_templates, is not the version required also for all templates? it seems yes, found version attribute here: https://github.com/eclipse-score/module_template/blob/eff55fcdcfe410bffc11ec35077b9989ccddd25b/score/component_example/docs/requirements/chklst_req_inspection.rst MoM:Discussed #3085 Discussed: eclipse-score/process_description#748 Generally the updated process is agreed, some details still needs to be discussed in the open PRs, but no blocker |
July-23, 9:30-10:30 o'clockParticipants:@PandaeDo Agenda:Planning update: S-CORE Roadmap (view) eclipse-score/process_description#742 Information from https://github.com/orgs/eclipse-score/discussions/1595#discussioncomment-17712934 Try-run of Checklist and verification needs type draft Follow-up Safety Topics, e.g. Implementation MoM:Informed about Roadmap, consider feasibility due to vacation Discussed proposal of Checklist and verification needs type draft, Main idea is to monitoring of the execution of the tasks, split verification report and inspection for now, setup a new POC for baselibs inspections @aschemmel-tech asked questions about specific issue template in Baselibs, must be removed and placed in the .github |
July-30, 9:30-10:30 o'clockParticipants:@aschemmel-tech Agenda:
MoM:module_template repo needs release - @masc2023 to do, done, https://github.com/eclipse-score/module_template/releases/tag/v0.0.1 available review #3139 turning around the linkage from feat to logic_ar_if should be done but planned what else has to be changed based on this. Score, process, module_template, module repos ... Also the color of the logic_arc_if should be "orange" as it belongs to the feature. @RolandJentschETAS to look into it, @aschemmel-tech may support Binärtype (library/executable) to components: Proposal is to have it as an automatically filled attribute in the component. @RolandJentschETAS to create ticket for eventual realization. callback functions and virtual interfaces: how to describe better in architecture guideline - proposal to be done by @RolandJentschETAS - one practical example is in the lifecycle feature already at the moment. Linking of log_arc_int_op to requirements: discuss in next meeting, participants to make up their mind. Rename "modules" in score main to "platform architecture" ? Yes - check also the CODEOWNER file which asks for a "architecture" folder already. |
Aug-6, 9:30-10:30 o'clockParticipants:@aschemmel-tech MoM:eclipse-score/.github#84 - issue templates - also on the agenda for PL sync on Monday. doc build warning: logic_arc_int__lifecycle__lifecycle_if : Implementing Component not specified! - but https://eclipse-score.github.io/lifecycle/pr-374/docs/features/lifecycle/architecture/index.html#mod_view_sta__lifecycle__all shows that actually we request the user application to implement the interface. How to model? Shall we create a "user application" component? - First: the check will never be enforced (as most of the interfaces are defined in the score repo). second: this was already discussed in last weeks meeting. Current plan is to add a "user" application need (as the component could not really be used as it is not part of any feature). Now that most of the module documentation is moved to the module repositories, should we try to align the "look-and-feel", e.g. the menu bar (at least this was a wish from lifecycle FT meeting including Frank): see https://eclipse-score.github.io/persistency/main/ - https://eclipse-score.github.io/baselibs/main/ - https://eclipse-score.github.io/lifecycle/main/ - @aschemmel-tech to create a proposal PR within the module template repository. Support of feature flags. This is defined in the feature template, but it is unclear how this works and if this is supported by infra. - Currently not implemented in process and infrastructure. Discuss this in next Mondays PL sync Please also review the proposal eclipse-score/docs-as-code#682 about an inspection report. This extends the verification report proposal. Discussion about tool qualification effort. Current list of tools is just manually maintained: https://eclipse-score.github.io/score/main/score_tools/score_tools_evaluation_list.html. @FScholPer asked for an automated way to collect all the tools. In our process this is part of the security process https://eclipse-score.github.io/process_description/main/process_areas/security_management/security_management_workflow.html#wf__cr_mt_security_sbom - for this already a tooling proposal exists in S-CORE: https://github.com/eclipse-score/sbom-tool. @FScholPer tries to find out how to integrate into the reference_integration. |
Aug-13, 9:30-10:30 o'clockParticipants:@aschemmel-tech Agenda:
MoM:Reviewed PRs, @aschemmel-tech will review #3180, #3139, @anmittag check #3182 Discussed Feature Architecture and Inspections, @anmittag and @RolandJentschETAS will have follow-up for the linking topic, as it is currently as intented Discussed Linkage of tests to architecture, https://eclipse-score.github.io/process_description/main/process_areas/verification/guidance/verification_process_reqs.html#gd_req__verification_link_tests does not mention link to architecture, @pahmann will check and update it @RolandJentschETAS informed about https://eclipse-score.github.io/score/main/contribute/general/folder.html, Platform Architecture @RolandJentschETAS informed about discussion to change score/ into middleware/, Community asked for DR, before it can discussed and decided In process_description, some changes lead to format topics, https://eclipse-score.github.io/process_description/main/general_concepts/score_review_concept.html, @MaximilianSoerenPollak will check Discussed Will pass the question to the auditors in the next session planned 4-6.11.2026 |
|
Correction to Roland's information "informed about discussion to change score/ into middleware ...": The request is whether it is a valid option to use the path "mw" symbolizes that this component has a state. |
|
Regarding the point "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": First of all this is relevant only if S-CORE intends to provide deliverables that are already confirmed to be compliant for a specific, concrete reference platform (target HW, compiler, OS). If the end user uses a different platform, namely a different target or a different compiler or OS it will be up to the end user to measure the coverage on that different platform or provide an rational why it is sufficient not to measure the coverage on the target as mentioned below in 2 and b)
In the specific case only part of whole unit testing activity would be performed (namely running the unit tests on the target), but part of it would not be performed (namely measuring the coverage) - the unit test framework differs on host and target with respect to coverage measurement. What does this mean for compliance to ISO 26262 to be judged in an assessment? There are different cases a) if (1) is applied (and sufficient coverage is achieved or deviations are argued) this is an "easy" case - compliance to the corresponding requirements in ISO 26262 is clear. b) If (2) is applied, a thorough analyis to provide sufficient evidence needs to be performed by the project for compliance to ISO 26262. In the end the cases (a) and (b) differ with regard to effort on S-CORE side but also with regard to the risk to pass/fail an assessment For case (a) the effort is to measure and argue test coverage on the (reference) target. This is some effort but not unreasonable. It requires some tooling but no deep expert knowledge. The risk to fail an assessment due to this point is quite low, though. For case (b) the effort is more to do a thorough analysis. Again the effort is not unreasonable, however, to do it well it does require significant expert knowledge because such differences can be very subtle (not unlikely, though) - see below for some background. Most likely such an analysis will contain additional requirements of which language constructs shall not be used, an analysis of the target and host hardware and the configuration differences. Overall this is probably doable, but not as straight forward as case (a). Experience tells that usually (a) is the most efficient approach and well doable with existing tools. Again - there may be exceptions, for example if the SW has low complexity and small size and uses only a specific, limited set of operations that are easier to judge. Some background: They key questions is: Is is possible (and likely) that there is a fault affecting the control flow (and hence structural coverage) differently on the host and on the target despite the test would pass on both, on the host and the target? So the scenario we have to consider is that the structural coverage is fine on the host and the test result is correct on the target, but nevertheless not all source code is covered on the target. At first glance this looks unlikely or even impossible. Let´s be clear: We assume that a qualified compiler is used, and that the HW is compliant to ISO 26262 as well with regard to both, random HW faults and systematic HW faults. This is given ... we are not hunting for compiler faults nor HW faults with this approach. Nevertheless ... there are quite a number of nasty possibilities for such behaviour, and most likely every experienced embedded developer has seen them: The reason is that both, C and C++ have quite a number of constellations with "undefined behaviour". This area of "undefined behaviour" is where host and target can behave differently, and even data differences may lead to different control flow. Many of them are detected by MISRA and/or compiler warnings, but static code analysis does not detect them all. More strict rules detect more (how strict is S-CORE?) ... however there are quite some that escape those mechanisms. And let´s be clear: "undefined behavior" is something known in principle, and they are not "faults" ... neither in the SW code, nor in the compiler nor on the HW. The only fault is not to know these traps ... but it is very hard to know them all. Very well known are the typical differences of floating point representations ... in many cases they don´t represent the mathematically correct number but deviate slightly ... due to correct but different approximation algorithms ... and the deviations are unavoidable ... and their impact is hard to forsee. A similar one: Did you know that NaN may be represented differently on different HW? ... that not always all bits are defined? Other well known topics are alignment differences, endianess, data structure representations (enum, struct), etc. These are just a few examples. This is a can of worms ... if you are interested search for "undefined behaviour" ... you´ll find a lot. And typically these differences are data dependent corner cases ... the best way to find them is in unit tests, not so easy in integration tests ... even though they can be triggered by SW higher levels under specific (realistic) conditions. And you cannot simply avoid them by avoiding specific language constructs ... this would constrain by far too much. And all these cases are really not unlikely ... they do happen once and then ... and they are very hard to debug in the integrated system. Will we detect them always with unit tests on targets? No ... there is no 100% solution ... but there is a good chance. Making a long story short: Knowing an avoiding such traps of "undefined behaviour" under specific data conditions is quite hard ... it is by far easier, to run tests on target HW (going into corners and boundaries as seen from equivalence classes ;-)) ... and measure the coverage ... if the coverage is not achieved on the target while on the host it is ... then there is something ugly and strange. Better investigate. This is why we recommend to go for option (a) ... run the unit test on the target and measure the coverage - the easierst way. (p.s.: C/C++ has many more cases of "undefined behaviour" than RUST ...) |
Aug-20, 9:30-10:30 o'clockParticipants:@PandaeDo Agenda:
Open PRs:
Other topics
MoM:Discussed Release Notes for v0.9, process_description (@masc2023), module_template (@masc2023, @RolandJentschETAS), sbom (@masc2023), nhlohmann (@aschemmel-tech, will check with baselibs team) Discussed, #3194, @pahmann will discuss it with testing team, @anmittag, please check, communicate it in the CT/FT Team Meeting, @aschemmel-tech will add a link from the folder structure and update the folder structure @aschemmel-tech will check with @anmittag concerning eclipse-score/module_template#137, update of components documentation? @RolandJentschETAS will check with architecture team about settings of the defined compiler, and how to document them For feature and components, ID will be derived from Bazel Module Name, compare https://eclipse-score.github.io/.github/#naming, |
Aug-27, 9:30-10:30 o'clockParticipants:@PandaeDo Agenda:
Open PRs:
Other topics
MoM:1. Information of Qorix-Newjoiner: Janis Schöntges will start on September 1st as Safety Manager and support @PandaeDo in this activities
2. Philipp added as quality manager #32133. Code Coverage with llvm-cov: #3137
PR restructuring contrib and intro #3224
PR (DRAFT) Automatically create Module Verification Report eclipse-score/baselibs#491
Other topics: Meta model graphical rendering prepared by infrastructure team
|
Sep-10, 9:30-10:30 o'clockParticipants:@RolandJentschETAS Agenda:Continue on discussion, started in https://github.com/orgs/eclipse-score/discussions/2234#discussioncomment-18215139 Open PRs:eclipse-score/module_template#166 Other topics
MoM:
|
Sep-24, 9:30-10:30 o'clockParticipants:@PandaeDo Agenda:
MoM:
|
|
Thank you for inviting me to present the SRAC proposal. I noticed that the agenda for tomorrow's Process Community Meeting is already listed. Could you please add the following agenda item? Safety Relevance Assertion Capability (SRAC) integration proposal — Devashri Datta (10–15 minutes) I will briefly introduce SRAC, its alignment with SPDX and CycloneDX, and the proposed first-step pilot with Eclipse S-CORE. |
|
added to agenda |
Oct-01, 9:30-10:30 o'clockParticipants:@masc2023 Agenda:
open Points from last meeting: volunteers for tool evaluation? Open PRs#2717, Checked, no feedback from @AlexanderLanin, @anmittag , please check again #3296, Discussed, agreed for now, will be approved OthersDiscussed eclipse-score/docs-as-code#891 |
Agenda proposal: SRAC proof-of-concept update (5–10 minutes)I would like to give a short update and demonstration of the portable safety-metadata flow implemented in reference_integration PR #370:
I would also appreciate feedback on the next PoC steps, particularly portable SEooC semantics, Assumptions of Use, and the Dependable Element / Component / Unit abstraction levels. |
Oct-08, 9:30-10:30 o'clockParticipants:@masc2023 Agenda:Epic created for AI development process "safety" piloting: (to be added by @masc2023) - who could do it? Is a module an architectural element? #3313 - Add section about reference integration in SW Verification Plan. nlohman_json is replaced by vajson in baselibs. Shall we keep, archive or delete the repository https://github.com/eclipse-score/nlohmann_json ? - it is our example for application of TSF. MoM:General discussion about "communication" Module, as it does not follow S-CORE process. A dedicated Workshop is planned for that. Pull is opened by @anmittag , most likely will happen 13.10.2026, check out https://github.com/orgs/eclipse-score/discussions/3311 nlohman_json is replaced by vajson in baselibs. Shall we keep, archive or delete the repository https://github.com/eclipse-score/nlohmann_json ? - it is our example for application of TSF. @aschemmel-tech request to keep it, as it has the TSF framework example applied to qualify software components. Get in contact with the maintainer of nlohmann, d-fine to get their feedback, @aschemmel-tech will contact them. Is a module an architectural element? -> Module name is kept, but means now Dependable Element In this sense a Dependable Element is the highest abstraction level in our model. A Dependable Element, delivered in a Delivery Container represents e.g. executable code or a library. The Dependable Element View (red box, middle, 1st column) documents the mapping of components to a Dependable Element. Note that the term “Dependable” hints that the element can have safety and/or security relevance (but also none of these). It is not a architecture element, so it is removed from the process requirement: gd_req__arch_build_blocks https://github.com/eclipse-score/process_description/pull/815/changes Epic created for AI development process "safety" piloting: (to be added by @masc2023) - who could do it? @masc2023 explained the intent, link to related PR here, eclipse-score/process_description#809 |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Time:
Feb-18, 9-10 o'clock
Agenda:
Check participants
Align on Agenda for today
Planning - are we confident for Audit slot 3
Unique ID #180 - exception for standard requirements (question from Markus Schu) - no
Do we want to have safety/security attribute for roles? And also others like workflows and workproducts? See #329 - no, can be removed from roles, also only optional "security" attribute for stakeholder requirements.
Process description template (define what is in "concept", "getting-started" ...?
Other discussions from open PRs (e.g. #399)
Participants:
@aschemmel-tech
@hoe-jo
@kroehnd_mbg
@PandaeDo
@pahmann
@markert-r
@PhilipPartsch
Meeting Minutes:
Planning:
Present Requirement Process: #377 - findings documented in PR
Process description template - not for now to be able to do some improvements on the way, but "Requirement Process" should be used as an example.
All reactions