Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Tech Meeting 2015 06 1@CEAList
Contents
Present
- Matthieu Perin (CEA List)
- Jonathan Dumont (All4tec)
- Anne-Catherine Vie (All4tec)
Minutes
Objectives
Check already made decision (Safety Element Abstract Layer & Architecture Package)
Advance on ESF Metamodel, specifically on the Safety Object : focus on SafetyConcepts and SafetyMethods Packages
Priority given on SafetyConcepts definition.
Meeting
Decision D1 All name are in plural (except for some exception?)
Decision D2 SafetyConcepts are separated into packages : SEnvironments, SInteractions, SRecommandations, SRequirements, SBehaviors, SProperties
Decision D3 Change the link between Part & PortRole from Aggregation to Shared as the PortRole is to be analysis in the context of the part and do not belong to it (ownership is to be the Block)
Proposition P1 For shared safety object among package a solution might be to have Intefaces in both package, and Implementation only on one to simplify both coding and usability of the concept.
Proposition P2 SRequirement & SRecommendation might have some shared objects & concepts.
Proposition P3 SInteractions Inputs and Outputs might have some shared objects & concepts.
Proposition P4 SInteractions and SBehaviors might have some shared objects & concepts.
Proposition P5 SPorperties will have some shared objects & concepts with other Packages.
Proposition P6 Use of DataType for criterion and property associated to SafetConcepts in the SProperties Package
Proposition P7 Clean the MetaModel from old proposition.
The concept of library is interesting but it is not meant to be added inside the safety related meta model.
Question Q1 about the separation between SInteractions & SBehaviors because there is a lot of common concepts between them, e.g. FailureEvents & Events). A solution might be to merge them but some elements will cause issues (e.g. Causes in SInteractions & Gates in SBehaviors). Another solution is to place in SBehaviors only basic mathematical concepts and to keep all Safety concepts in SInteractions. Idea of putting SBehaviors & SPorperty outside SafetyConcepts because they are more generic. To investigate
Metamodel extracts (Meeting result)
Here are some extracts of the metamodel, focused on the part changed during this meeting.