Skip to main content

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.

Jump to: navigation, search

Tech Meeting 2015 06 1@CEAList

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.

Architectural concepts

ESFArchitecturalConcepts.png

Safety concepts

ESFSafetyConcepts.png

Interactions packages

ESFInteractions.png

Back to the top