#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

1This document is produced under the Grant Agreement 605442.

It is the property of the ASHLEY consortium and shall not be distributed or reproduced without the formal approval of the ASHLEY Steering Committee.

Presented by

Prepared by

“Unrestricted PUBLIC 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, 2015Paris, France

Preface


It is the property of the ASHLEY consortium and shall not be distributed or reproduced without the formal approval of the ASHLEY Steering Committee.“Unrestricted PUBLIC Access”

This publication only reflects the view of the ASHLEY Consortium or selectedparticipants thereof. Whilst the ASHLEY Consortium has taken steps toensure that this information is accurate, it may be out of date or incomplete,therefore, neither the ASHLEY Consortium participants nor the EuropeanCommunity are liable for any use that may be made of the informationcontained herein.This document is published in the interest of the exchange of information andit may be copied in whole or in part providing that this disclaimer is included inevery reproduction or part thereof as some of the technologies and conceptspredicted in this document may be subject to protection by patent, designright or other application for protection, and all the rights of the owners arereserved.The information contained in this document may not be modified or used forany commercial purpose without prior written permission of the owners andany request for such additional permissions should be addressed to theASHLEY co-ordinator (Thales Avionics S.A., 105 Av. du General Eisenhower,BP 63647, 31036 Toulouse, FRANCE, for the attention of the ASHLEY ProjectManager) in the first instance.



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

Presentation Content



Integrated Modular Avionics - IMA



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



q Initial requirements from airframer(system designer) and function supplier

Ø Support system designer in 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



Toolchain interfaces

More tools...



qHeterogeneous user groupØDifferent companies ØAbstraction levelsØDesign phase

qMany interface to other toolsqIntellectual Property Rights (IPR)

ØChallenges when sharing important input to design

Ø Integration testingqScepticism

ØPrior experience with Model-Driven Development

Design challenges



Overall structure Function Model

Fct 1ATAxx

Fct 2ATAxx

Fct 3ATAxx

Fct 4ATAxx

pwr

sign

al

pwr

sign

al

sign

al

Fct 1ATAxx

Fct 2ATAxx

Fct 3ATAxx

Fct 4ATAxx

DSI

28V

DSI

28V

28V

28V

Fct 1ATAxx

Fct 2ATAxx

Fct 3ATAxx

Fct 4ATAxx

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

PhysicalFunctional

Blocks

InstantiatedFunctional

Blocks

Logical Function Model Physical Function Model Architecture Model

CAN

DSO

DSO

Location AFct Type X

Location AFct Type Y

Location BFct Type Y

Location BFct Type: N/A

HW Segregation

Allocations



q Biweekly workshops with Ø AirframerØ Other tool developersØ System Designer Expert

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



Results: FMT Tool architecture



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



Results: logical model example



Results: physical and architecture model example



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



6C model quality goals for DSL

identified modifiability of language as a practice that helps achiev-ing validity and completeness [P15].

6C goals. We call the above quality goals collectively for the 6C(model quality) goals. Fig. 2 shows the 6C goals and their relationsto other elements involved in modelling. Compared with the Lind-land et al.’s framework in [P22], we have added modelling rulesand organization (defining the goals of modelling) to theframework.

Fig. 3 is another view of the 6C goals that shows when in thedevelopment process they are important. The figure is inspiredby the idea of viewing modelling as a set of transformations[P26]. A model is a representation of a system and should be com-plete relative to the system it wants to represent and according tothe modelling goals defined by the organization. It should also con-tain correct relations between elements and correct meanings. Allthese properties depend on the perception of the modeller of thedomain and the purpose of modelling. The developed models arerequired to be correct relative to the language and modelling rulesor conventions, and be comprehensible for interpretation by hu-mans or by tools for the purpose of generation, simulation or anal-ysis. Of course precise definition of quality goals depends on the

context and the purpose of modelling, especially whether modelsare used for implementation, testing and maintenance of systems.

Finally, we mean that other quality goals discussed in literaturecan be satisfied if the 6C goals are in place. For example a modelthat is correct, complete and consistent does not allow multipleinterpretations and all of the above goals are important in orderto support reusability of models. The 6C goals are identified basedon the analysis of literature covered in this review and the list maytherefore be modified or extended if new requirements aredetected.

In the next section we present the proposed approaches forimproving the quality of models which are referred to as ‘‘prac-tices” in our quality model, together with the reported empiricalevidence.

5. Practices proposed to improve the quality of models (RQ2 andRQ3)

In this section we discuss the practices proposed in the studiesto be applied during modelling to improve the quality of models.Most practices are concerned with error prevention, while somealso facilitate error detection. We have identified six classes of prac-tices which are presented throughout this section together withexamples of empirical work. We also discuss their impact on the6C goals introduced in Section 4. The six practices are divided intwo groups:

(a) The first group is related to ‘‘modelling process” and covershaving a model-based development process, using model-ling conventions and the single-diagram approach8;

(b) The second group is related to ‘‘formal approaches and auto-mation” and covers formal models, domain-specific solu-tions and generating models from models.

Table 2 shows an overview of the studies covered in this reviewordered after the proposed practice. The impact of practices onquality goals, the name of tool used or developed and the type ofempirical evidence is also given. There are four studies that coverquality models in general and refer to most or all of the qualitygoals; i.e., [P15,P22,P26,P38]. In Table 2 there is a column called‘‘Demo or Empirical approach” where the values are:

! ‘‘–” for studies that are pure discussion. This covers threestudies.

! ‘‘Example” which shows that the proposed practice is applied onan example application to demonstrate its usefulness. An exam-ple is not empirical evidence. 16 studies include such examples.

! ‘‘Student experiment” indicates that a controlled experiment isperformed with students as subjects; described in 9 studies.

! ‘‘Industrial case” refers to describing experience from applying apractice in industry. Industrial cases detected in this review donot have the level of formality required of a ‘‘case study” asdefined in [20] such as a precise definition of research questions,context, data collection methods and results. We found descrip-tion or reference to industrial cases in 14 studies.

The sum is 42 since two studies cover both student experimentsand industrial cases; i.e., [P35,P19]. Although the focus of this sys-tematic review has not been on collecting evidence and appraisingapproaches, the data provide examples for evaluation and future

Environment(Domain,

Organization)

comprehensibility

ModelLanguage &Modelling

Rules

Tools

Human-users

completenesscorrectness

consistency

comprehensibility

confinement

correctness

changeability

Fig. 2. The 6C model quality goals.

Analysis &generation

tools

Real World (domain and organization)

Model

Modellinglanguage

Modelling tool

Modeller

<perceives><elicits & develops>


confinementchangeability

Rules&

guidelines

<uses> <uses>

Codecomprehensibility

com

preh

ensi

bilit

y

correctnesscorrectness

<uses> <generates>

Human users(customers,

developers, etc.)

<uses>

<uses>

<develops>

consistency

Fig. 3. Model-based software development with transformation of real world torunning software.

8 Selecting a single-diagram approach depends on the modelling language.However, we chose to group it under modelling process since selecting suitablelanguages and diagrams is often a step of modelling processes as discussed later.

1652 P. Mohagheghi et al. / Information and Software Technology 51 (2009) 1646–1669

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.



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



Correctness Validation



q Completeness is defined as havingall the necessary informationthat is relevant and beingdetailed enough according to the purpose of modelling

q AvionicsØ Depends on user role

ü system designer, function supplier, module integrator, ...

Ø Depends on design phaseq Sirius

Ø Allows for layersØ Different types of diagramsØ Mandatory fields etc..

Completeness



q Consistency is defined as nocontradictions in the model. Ø It covers consistency between views

or diagrams that belong to the same level of abstraction or developmentphase (horizontal consistency)

Ø And between models or diagrams thatrepresent the same aspect, but at different levels of abstraction or in different development phases (verticalconsistency).

q AvionicsØ Many different actorsØ Require documentation and versioning

with traceabilityq Sirius

Ø Model-View separationü Several diagram(types) illustrate same

model/element across abstraction leveland..

Consistency



q Comprehensiblity is defined as being understandable by theintended 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 insufficientwrt useability and modellingefficiency

Comprehensiblity



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



q Changeability is defined as supportingchanges or improvements so thatmodels can be changed or evolvedrapidly 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



Goal/ Sirius feature

Correct-ness

Complete-ness

Consist-ency

Compre-hensibility

Confine-ment

Change-ability

Model-Viewseparation X X

EMF base X XValidation XEEF X X XEcorestable X X X

oDesignproperties X

Layering X X XDifferent diagram types

X X X X

6C quality goal summary



ASHLEY: Avionics and 6C goals

identified modifiability of language as a practice that helps achiev-ing validity and completeness [P15].

6C goals. We call the above quality goals collectively for the 6C(model quality) goals. Fig. 2 shows the 6C goals and their relationsto other elements involved in modelling. Compared with the Lind-land et al.’s framework in [P22], we have added modelling rulesand organization (defining the goals of modelling) to theframework.

Fig. 3 is another view of the 6C goals that shows when in thedevelopment process they are important. The figure is inspiredby the idea of viewing modelling as a set of transformations[P26]. A model is a representation of a system and should be com-plete relative to the system it wants to represent and according tothe modelling goals defined by the organization. It should also con-tain correct relations between elements and correct meanings. Allthese properties depend on the perception of the modeller of thedomain and the purpose of modelling. The developed models arerequired to be correct relative to the language and modelling rulesor conventions, and be comprehensible for interpretation by hu-mans or by tools for the purpose of generation, simulation or anal-ysis. Of course precise definition of quality goals depends on the

context and the purpose of modelling, especially whether modelsare used for implementation, testing and maintenance of systems.

Finally, we mean that other quality goals discussed in literaturecan be satisfied if the 6C goals are in place. For example a modelthat is correct, complete and consistent does not allow multipleinterpretations and all of the above goals are important in orderto support reusability of models. The 6C goals are identified basedon the analysis of literature covered in this review and the list maytherefore be modified or extended if new requirements aredetected.

In the next section we present the proposed approaches forimproving the quality of models which are referred to as ‘‘prac-tices” in our quality model, together with the reported empiricalevidence.

5. Practices proposed to improve the quality of models (RQ2 andRQ3)

In this section we discuss the practices proposed in the studiesto be applied during modelling to improve the quality of models.Most practices are concerned with error prevention, while somealso facilitate error detection. We have identified six classes of prac-tices which are presented throughout this section together withexamples of empirical work. We also discuss their impact on the6C goals introduced in Section 4. The six practices are divided intwo groups:

(a) The first group is related to ‘‘modelling process” and covershaving a model-based development process, using model-ling conventions and the single-diagram approach8;

(b) The second group is related to ‘‘formal approaches and auto-mation” and covers formal models, domain-specific solu-tions and generating models from models.

Table 2 shows an overview of the studies covered in this reviewordered after the proposed practice. The impact of practices onquality goals, the name of tool used or developed and the type ofempirical evidence is also given. There are four studies that coverquality models in general and refer to most or all of the qualitygoals; i.e., [P15,P22,P26,P38]. In Table 2 there is a column called‘‘Demo or Empirical approach” where the values are:

! ‘‘–” for studies that are pure discussion. This covers threestudies.

! ‘‘Example” which shows that the proposed practice is applied onan example application to demonstrate its usefulness. An exam-ple is not empirical evidence. 16 studies include such examples.

! ‘‘Student experiment” indicates that a controlled experiment isperformed with students as subjects; described in 9 studies.

! ‘‘Industrial case” refers to describing experience from applying apractice in industry. Industrial cases detected in this review donot have the level of formality required of a ‘‘case study” asdefined in [20] such as a precise definition of research questions,context, data collection methods and results. We found descrip-tion or reference to industrial cases in 14 studies.

The sum is 42 since two studies cover both student experimentsand industrial cases; i.e., [P35,P19]. Although the focus of this sys-tematic review has not been on collecting evidence and appraisingapproaches, the data provide examples for evaluation and future

Environment(Domain,

Organization)

comprehensibility

ModelLanguage &Modelling

Rules

Tools

Human-users


consistency

comprehensibility

confinement

correctness

changeability

Fig. 2. The 6C model quality goals.

Analysis &generation

tools

Real World (domain and organization)

Model

Modellinglanguage

Modelling tool

Modeller

<perceives><elicits & develops>


confinementchangeability

Rules&

guidelines

<uses> <uses>

Codecomprehensibility

com

preh

ensi

bilit

y

correctnesscorrectness

<uses> <generates>

Human users(customers,

developers, etc.)

<uses>

<uses>

<develops>

consistency

Fig. 3. Model-based software development with transformation of real world torunning software.

8 Selecting a single-diagram approach depends on the modelling language.However, we chose to group it under modelling process since selecting suitablelanguages and diagrams is often a step of modelling processes as discussed later.

1652 P. Mohagheghi et al. / Information and Software Technology 51 (2009) 1646–1669

Airbus, Nord-MicroThales

System designer,System integratorModule integratorFunction Supplier

Platform ConfigurationEarly Validation AVIONICS

CPIOM Configuration



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, organizational and tool

appropriateness

Why Sirius helped us



q Initial requirementsØ Support system designer in 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?



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?



Iterate on tool-Evaluate-Update

Future work



Ståle Walderhaug (SINTEF)

Email:[email protected]

Phone:+47 90766069

Thank you for your attention

31

Call identifier: FP7-AAT-2013-RTD-1Project co-funded by the European Commission within the

Seventh Framework Programme (2013-2017)

Avionics Systems Hosted ona distributed modular electronics Large scale dEmonstrator

for multiple tYpe of aircraft

This document is produced under the Grant Agreement 605442. It is the property of the ASHLEY consortium and shall not be distributed or reproduced without the formal approval of the ASHLEY Steering Committee.

“Unrestricted PUBLIC Access”