Tech Meeting 2015 04 30@CEAList

Present

• Yupanqui Munoz (CEA List)
• Natalya Yakymetz (CEA List)
• Matthieu Perin (CEA List)
• Jonathan Dumont (All4tec)
• Anne-Catherine Vie (All4tec)

Minutes

Objectives

Decision D1 Focus on safety concepts to be able to generate our first metamodel implementation soon ! End of may !

Naming conventions

We are using concepts similar to UML and SysML. For example a Block in ESF and a Block of SysML. But they are different. Using a prefix might be a solution ? But users uses objects by their names so prefixing might be confusing...

Decision D2 Confirmed Prefix "S" must be use for all ESF concepts (SBlock, SModel, etc.). 'S' corresponds to Safety and Security also. 
Decision D3 The nature prefix 'Abstract', 'I', etc. is preemptive on the 'S' prefix. We should have 'AbstractSElement' for example.

ESFCore

Decision D4 AbstractArchitecturalElement and AbstractSafetyElement must be in ESFCore and not in the dedicated model.
The goal of this is to ease their reuse and avoid dependencies between the specific models

Decision D5 The 'references' association between safety and architectural element is not the 'owner' link but just a reference.

Decision D6 ESFCore must stay abstract and minimalist : it's made to open and communicate with other tools / models

Decision D7 AbstractSafetyElement must be renamed AbstractSafetyConcept 

Decision D8 ESFCore will contain an AbstractSafetyMethod object, used as a general parent for the method implementations

Decision D9 AbstractSafetyMethod 'uses' 0..* AbstractSafetyConcept, and the AbstractSafetyConcept must not know the methods which use them

Discussion  We need to create a safety object or component to own the others safety concepts, and to be linked to architectural elements. 
Not all the safety concepts need to be linked to architecture

SafetyConcepts

Decision D10 Local analysis may not be in SafetyConcepts, it's a method, not a concept. 

Decision D11 SafetyConcepts must be a core model to be understood by everybody. It must contain only 10-15 elements, general and agnostics. 

Decision D12  'Mode' is problematic (static ? life phase ? ) ... must not be created now, not enough mature

Concepts from brainstorming :

Goal of the brainstorming : Find the general concepts and the right names for the elements to create in the SafetyConcepts model. This brainstorming has been done in two steps : find all the potential concepts linked to the safety, and then classify them by high level categories or concepts.

- 1) Configuration of the context and environment. What is outside the system :

 - Mode
 - State
 - Mission
 - Environment
 - Scenario
 => Proposition, Package System behaviour

- 2) What can 'append' on the system, from/to the environment, or from/to my system. What are the potential interactions :

- 2.1) 'inputs' of the system, what can impact the system from the environment :
 - Causes
 - Failure mode 
 - Harm (!)
 => Proposition, Package Cause

- 2.3) 'outputs' of the system, what are the impacts of the system on the environment :
 - System effects
 - Hasard
 - Risk (characteristic of an event, defined by its severity, occurrence)
 - Harm (!)
 - Feared events
 - Accident
 - Incident
 => Proposition, Package Consequences

- 3) The recommandations concepts :

 - Recommandations
 - Action / Preventive action (May be redundant with 'recommendation')
 - Mesure (ie: mitigation, etc.)
 - Barrier
 => Proposition, Package Recommandations

- 4) How can we describe the system behaviour, in case of failure. This corresponds to the failure propagation :

 - Property (occurence, probability, etc.)
 - Assumption / Hypothesis
 - Leaf
 - Gate / Operation
 - Propagation link
 - Safety Requirement
 - Common cause / mode / events
 - Internal failure (Error, Fault, etc.)
 => Proposition, Package Internal behaviour

- 5) How can we specify the system :

 - Requirements

- 6) What are the safety criteria, made by human judgement. It corresponds to Property of our concepts. How can be called the safety objectives to respect by the system :

 - Severity
 - Diagnostability
 - Criticality (not a real criteria, it's calculated from frequency and severity : it's a score !)
 => S/D/C are columns in AMDE

- Rejected concepts :

 - Probability
 - Matrix
 - Safety / Security
 - Dependability / Maintainability / Availability / Reliability : Not used at this time
 - Occurrence

- Not classified :

 - Minimal cut set
 - Tree
 - Basic event
 - SIL / ASIL
 - Event
 - Top event

ESFCore metalmodel (Meeting result)

Architectural Concepts metamodel (Meeting result)

• Overview of all elements of the Architectural Concepts metamodel

• Relation between all elements of the Architectural Concepts metamodel