#SiriusCon 2015: Functional Modelling Tool for the Avionics Domain

Avionics Systems Hosted on a distributed modular electronics Large scale dEmonstrator for multiple tYpe of aircraft
1
This documentis producedunder the Grant Agreement605442.
It is the property of theASHLEY consortium andshall not bedistributed or reproduced withouttheformal approval of the ASHLEY Steering Committee.
Presented by
Prepared by
“UnrestrictedPUBLIC Access”
Ståle Walderhaug, PhD, Research Manager, SINTEF ICT - Norway
Erlend Stav (SINTEF) and Ståle Walderhaug
Function Modelling Tool for the avionics domain
SiriusCon December 3, 2015
Paris, France

Preface
2
This publication only reflects the view of the ASHLEY Consortium or selected
participants thereof. Whilst the ASHLEY Consortium has taken steps to
ensure that this information is accurate, it may be out of date or incomplete,
therefore, neither the ASHLEY Consortium participants nor the European
Community are liable for any use that may be made of the information
contained herein.
This document is published in the interest of the exchange of information and
it may be copied in whole or in part providing that this disclaimer is included in
every reproduction or part thereof as some of the technologies and concepts
predicted in this document may be subject to protection by patent, design
right or other application for protection, and all the rights of the owners are
reserved.
The information contained in this document may not be modified or used for
any commercial purpose without prior written permission of the owners and
any request for such additional permissions should be addressed to the
ASHLEY co-ordinator (Thales Avionics S.A., 105 Av. du General Eisenhower,
BP 63647, 31036 Toulouse, FRANCE, for the attention of the ASHLEY Project
Manager) in the first instance.

3
§ Background and motivation
§ Tool Requirements and design challenges
§ Methods
§ Evaluations
§ 6C quality goals for a DSL
§ Verification and validation
PresentationContent

4
Integrated ModularAvionics - IMA

5
q Motivation for having a Function Modelling Tool
Ø enable the platform architect to provide a centralized
architecture definition with a unified information
model.
Ø Support for different viewpoints and abstraction
levels
q Modelling
Ø saves time
Ø replaces or complements core configuration
documents
Ø improves validation and traceability in initial design
q Eclipse as a common platform
Background and motivation

6
q Initial requirements from airframer
(system designer) and function supplier
Ø Support system designerin creating
ü Overall system architecture
ü (Sub)system resource needs
Ø Support established design processes
Ø Integrate with existing toolchain
Ø Fulfil documentation and version control
requirements for the domain
Ø Replace well-established excel-
based configuration spreadsheet
ü Cannot show due to IPR
Tool Requirements

7
Toolchain interfaces
More tools...

8
qHeterogeneous user group
Ø Different companies
Ø Abstraction levels
Ø Design phase
qMany interface to other tools
qIntellectual Property Rights (IPR)
Ø Challenges when sharing important input to
design
Ø Integration testing
qScepticism
Ø Prior experience with Model-Driven Development
Design challenges

9
Overall structure Function Model
Fct 1
ATAxx
Fct 2
ATAxx
Fct 3
ATAxx
Fct 4
ATAxx
pwr
signal
pwr
signal
signal
Fct 1
ATAxx
Fct 2
ATAxx
Fct 3
ATAxx
Fct 4
ATAxx
DSI
28V
DSI
28V
28V
28V
Fct 1
ATAxx
Fct 2
ATAxx
Fct 3
ATAxx
Fct 4
ATAxx
CAN
PCI
28V
DSI
28V
28V
28V
DSO
Module Type A,
Inst 1
Module Type B,
Inst 2
Valve Type A,
Inst 1
Functional
Blocks
Physical
Functional
Blocks
Instantiated
Functional
Blocks
LogicalFunction Model PhysicalFunction Model Architecture Model
CAN
DSO
DSO
Location A
Fct Type X
Location A
Fct Type Y
Location B
Fct Type Y
Location B
Fct Type: N/A
HW Segregation
Allocations

10
q Biweekly workshops with
Ø Airframer
Ø Other tool developers
Ø System DesignerExpert
q First version with satisfying GUI developed
early with Sirius
q Integration testing with tool developers
Ø Common and relevant example
q Evaluation with Nord-Micro GmbH & Co. OHG.
Methods

11
Results: FMT Tool architecture

12
q A function model describes the set of functions a system
consists of and how they are organized
q Function Blocks:
Ø Properties
ü type of function, position where equipment is mounted, power feeds,
and needs for resources such as memory and computation.
Ø Topology
ü communication lines, types of busses and IO used, and power
connections
Ø Constraints
ü for segregation of the hardware function blocks can be deployed on
ü segregation of power feeds and mounting zones
ü required dissimilarity of hardware for function blocks
q Library model referred to by design model
Ø Standard values for properties such as power, ATA,routes, bus
speed
Metamodels for Function Model DSL

13
Results: logical model example

14
Results: physical and architecture
model example

15
q Internal evaluation
Ø Local testing with airframer and other tool developer
q External evaluation
Ø Workshop with Function Supplier (Nord-Micro)
ü Installation of tool on FS computers
ü Modelling of real FS system
Ø Review of feedback and updating.
q Domain Specific Language
Ø Quality evaluation:6C goals
Evaluation

16
6C model quality goals for DSL
or conventions, and be comprehensible for interpretation by hu-
mans or by tools for the purpose of generation, simulation or anal-
ysis. Of course precise deﬁnition of quality goals depends on the
In this section we dis
to be applied during m
Most practices are con
also facilitate error detec
tices which are present
examples of empirical w
6C goals introduced in
two groups:
(a) The ﬁrst group is
having a model-b
ling conventions
(b) The second group
mation” and cov
tions and generat
Table 2 shows an ove
ordered after the propo
quality goals, the name
empirical evidence is al
quality models in gene
goals; i.e., [P15,P22,P26
‘‘Demo or Empirical app
‘‘–” for studies that
studies.
‘‘Example” which sho
an example applicatio
Environment
(Domain,
Organization)
comprehensibility
Model
Language
Modelling
Rules
Tools
Human-
users
completeness
correctness
consistency
comprehensibility
confinement
correctness
changeability
Fig. 2. The 6C model quality goals.
Analysis
generation
sibility
Parastoo Mohagheghi, Vegard Dehlen, Tor Neple, ”Definitions and approaches to model quality in model-based software
development –A review of literature”, Information and Software Technology, Volume 51, Issue 12, December 2009, Pages
1646-1669, ISSN 0950-5849, http://dx.doi.org/10.1016/j.infsof.2009.04.004.

17
q Correctness is defined as
Ø Including right elements and correct relations between them, and
including correct statements about the domain;
Ø Not violating rules and conventions;for example adhering to language
syntax (well-formedness or syntactic correctness according to), style rules,
naming guidelines or other rules or conventions.
q Avionics
Ø Formal specifications is key,but Excel is used for core specification
documents
Ø Well established routines for definitions of ”core configuration documents”
Ø Domain terminology
q Sirius Pros
Ø Building upon EMF
Ø Built in support for validation
Ø Library support (ecore)
Ø EEF enables efficient property editing
Correctness

18
Correctness Validation

19
q Completeness is defined as having
all the necessary information
that is relevant and being
detailed enough according to
the purpose of modelling
q Avionics
Ø Depends on user role
ü system designer, function supplier,
module integrator, ...
Ø Depends on design phase
q Sirius
Ø Allows for layers
Ø Different types of diagrams
Ø Mandatory fields etc..
Completeness

20
q Consistency is defined as no
contradictions in the model.
Ø It covers consistency between views
or diagrams that belong to the same
level of abstraction or development
phase (horizontal consistency)
Ø And between models or diagrams that
represent the same aspect, but at
different levels of abstraction or in
different development phases (vertical
consistency).
q Avionics
Ø Many different actors
Ø Require documentation and versioning
with traceability
q Sirius
Ø Model-View separation
ü Several diagram(types) illustrate same
model/element across abstraction level
and..
Consistency

21
q Comprehensiblity is defined as
being understandable by the
intended users; either human
users or tools
q Avionics
Ø Different roles
Ø Many tools in a toolchain
q Sirius
Ø Layers
Ø Ecore-based
Ø Separation of concerns
ü Different diagram types
Ø Intergration with EEF is powerful
ü Sirius property editors insufficient
wrt useability and modelling
efficiency
Comprehensiblity

22
q Confinement is defined as being in agreement with the
purpose of modelling and the type of system; such as
including relevant diagrams and being at the right
abstraction level.
Ø A model is a description from which detail has been removed
intentionally.
Ø A confined model does not have unnecessary information and is
not more complex or detailed than necessary.
q Avionics
Ø Thousands of configuration parameters
ü Need to hide details
q Sirius
Ø Layering
Ø Diagram types
Confinement

23
q Changeability is defined as supporting
changes or improvements so that
models can be changed or evolved
rapidly and continuously
q Avionics
Ø Relatively stable ”metamodel”
Ø Strong interest in improving
design/definition process
ü Tool harmonisations
q Sirius
Ø Stable base in ecore
Ø User interface design
ü Odesign
Ø EEF enables effective creation of
structures
Ø EEF poses challenges to rapid
updates of metamodel
Changeability

24
Goal/ Sirius
feature
Correct-
ness
Complete-
ness
Consist-
ency
Compre-
hensibility
Confine-
ment
Change-
ability
Model-View
separation
X X
EMF base X X
Validation X
EEF X X X
Ecore
stable
X X X
oDesign
properties
X
Layering X X X
Different
diagram
types
X X X X
6C quality goal summary

25
ASHLEY:Avionics and 6C goals
ordered after the proposed p
quality goals, the name of too
empirical evidence is also give
quality models in general and
goals; i.e., [P15,P22,P26,P38].
‘‘Demo or Empirical approach”
‘‘–” for studies that are p
studies.
‘‘Example” which shows tha
an example application to d
ple is not empirical evidence
‘‘Student experiment” indica
performed with students as
‘‘Industrial case” refers to de
practice in industry. Industr
not have the level of form
deﬁned in [20] such as a pre
context, data collection met
tion or reference to industri
The sum is 42 since two stu
and industrial cases; i.e., [P35,P
tematic review has not been on
approaches, the data provide
Tools
Fig. 2. The 6C model quality goals.
Analysis
generation
tools
Real World
(domain and
organization)
Model
Modelling
language
Modelling
tool
Modeller
perceives
elicits
develops
completeness
correctness
confinement
changeability
Rules

guidelines
uses uses
Code
com
prehensibility
com
prehensibility
correctness
correctness
uses generates
Human users
(customers,
developers, etc.)
uses
uses
develops
consistency
Fig. 3. Model-based software development with transformation of real world to
running software.
8
Selecting a single-diagram appro
However, we chose to group it unde
languages and diagrams is often a step
Airbus, Nord-Micro
Thales
System designer,
System integrator
Module integrator
Function Supplier
Platform Configuration
Early ValidationAVIONICS
CPIOM Configuration

26
q Eclipse provides a mature and solid
basis for tool development
Ø Plugins can easily be integrated
q Sirius makes it easier to fulfil core
model quality goals
Ø Layering
Ø Visual layout
Ø Model-View separation
q Real-life evaluation is still necessary
to validate
Ø Domain, organizationaland tool
appropriateness
Why Sirius helped us

27
q Initial requirements
Ø Support system designerin creating
ü Overall system architecture (component topology)
ü (Sub)system resource needs
Ø Support established design processes
Ø Integrate with existing toolchain
Ø Replace well-established excel-based configuration spreadsheet
Ø Fulfil documentation and version control requirements for the domain
Verification: is the tool correct?

28
q The main motivation for having a function modelling tool is to
Ø enable the platform architect to provide a centralized architecture definition
with a unified information model.
Ø Support for different viewpoints and abstraction levels
q Modelling:
saves time
replaces or complements the Configuration Control Document(CCD)
improves validation and traceability in initial design
Validation: is it the correct tool?

29
Iterate on tool
-Evaluate
-Update
Future work

30
Ståle Walderhaug (SINTEF)
Email:
stale.walderhaug@sintef.no
Phone:
+47 90766069
Thank you for your attention

31
Call identifier: FP7-AAT-2013-RTD-1
Project co-funded by the European Commission within the
Seventh Framework Programme (2013-2017)
Avionics Systems Hosted on
a distributed modular electronics Large scale dEmonstrator
for multiple tYpe of aircraft

#SiriusCon 2015: Functional Modelling Tool for the Avionics Domain

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie #SiriusCon 2015: Functional Modelling Tool for the Avionics Domain

Ähnlich wie #SiriusCon 2015: Functional Modelling Tool for the Avionics Domain (20)

Mehr von Obeo

Mehr von Obeo (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

#SiriusCon 2015: Functional Modelling Tool for the Avionics Domain