Towards MDA for Safety Critical Systems

1
Towards MDA for Safety Critical Systems

• (With an emphasis on transformation and analysis)
• Richard F. Paige
• Dimitrios S. Kolovos
• Philippa M. Conmy
• The University Of York

2
The Context MDD and MDA

• Model-Driven Development (MDD) is a set of
  principles for systems development.
• Use different models, at different levels of
  abstraction for capturing system characteristics
  of interest.
• Models should be machine readable, and amenable
  to analysis.
• Model-Driven Architecture (MDA) is a set of
  standards for MDD.
• Provides a common metamodelling infrastructure.
• A philosophy/style in which business
  concepts/logic can be modelled independently of
  (system) platforms.
• Notions of successive transformation, merging,
  and embellishment to produce executable system
  models.

3
The Domain Avionics Systems

• Both civil and military systems must be built to
  rigorous certification standards and guidance
• e.g., DO-178B/C, DefStan 00-56
• Generally, the process must deliver evidence that
  the system meets a set of functional and safety
  requirements
• Evidence required depends on the nature of the
  application.
• Tools used must also be qualified.
• Avionics software is becoming more modular.
• e.g., Integrated Modular Avionics (IMA)
• This seems like a good opportunity to apply MDA.
• But can MDA be used to build IMA, and satisfy
  external certification/guidance standards?

4
IFPCS Example IMA Architecture

• Integrated Flight and Propulsion Control System
  (IFPCS).
• Each rack had a processor running a single copy
  of each of the applications.
• A voting system was used to consolidate data.

5
Can MDA support IMA?

• Three general questions to address
• Can the design artifacts (models,
  transformations) of MDA be shown to produce an
  IMA system that is acceptably safe?
• Can the MDA process deliver evidence useful to
  produce a safety case?
• How do we evaluate the artifacts of MDA, with an
  eye towards providing an optimum process?
• e.g., what is a good model, metamodel,
  transformation, etc., for IMA?
• These are general questions for safety critical
  systems as a whole, not just IMA.

6
Model Analysis for IMA

• Can model transformation and model analysis help
  to deliver acceptably safe IMA?
• What we did
• Developed models and metamodels for IFPCS.
• Determined what type of evidence wed need for
  building acceptably safe IMA.
• Used model analysis to deliver initial evidence.
• Transformed models into new formats to deliver
  different evidence (e.g., failure behaviour).
• Assessed how useful that evidence really was.
• Made some observations about what is needed in
  state-of-the-art MDA tooling for building IMA
  systems.

7
What Evidence?

• For IMA systems, reconfiguration is very
  important.
• Reconfiguration occurs, e.g., on failure.
• e.g., a processor fails move affected tasks to a
  different processor within well-defined resource
  and safety constraints.
• We wanted to assess state-of-the-art MDA tools
  for analysing reconfigurability of IMA.
• Determine the tolerance to loss by seeing how
  many failures can occur before constraint
  violation.
• Alternatively, generate all possible valid
  configurations (i.e., those that satisfy all
  constraints).
• Additionally, wed like to transform valid
  configurations into a form for additional
  analysis (e.g., failure propagation).
• Use model transformation for this.

8
Tools and approach

• Used the Eclipse development environment with two
  frameworks.
• AMMA, including the Atlas Transformation Language
• Epsilon, including the Epsilon Object Language
  and Epsilon Transformation Language
• Metamodels for avionics system and bespoke tool
  created using Eclipse Modeling Framework plugins
• Complete model of IFPCS created for
  transformation and analysis.
• We have also created a metamodel for additional
  external analysis, i.e., FPTC.

9
Using AMMA

• Use the framework to generate valid
  configurations
• i.e., processor/process configurations that
  obeyed safety constraints.
• used the Atlas Transformation Language (ATL) part
  of AMMA.
• Enforcement of constraints is extremely complex
  due to syntax/semantics of ATL
• Required multiple complex list/sequence
  processing variable declarations
• Complex to backup reference model elements for
  comparison
• Resultant code difficult to read and maintain
• Code also inefficient

10
ATL - Selecting New Processor

• helper def getNextFreeProcessor(failedProcNameSt
  ring)String
• let failedProc IFPCS1!Processor
• IFPCS1!Processor-gtallInstances()-gtasSequence()
• -gtselect(ee.PId failedProcName)-gtfirst(
  ) in
• let possibles Sequence(IFPCS1!Processor)
  
• IFPCS1!Processor-gtallInstances()-gtasSequence(
  )
• -gtselect(e(not (e.PId failedProcName)) and
  
• e.StateRUNNING and e.MemOk(failedProc) and
• e.MixOk(failedProc) and e.ScheduleOk(failedPro
  c)) in
• let possiblesSize Integer
• possibles-gtsize().debug('SIZE') in
• if possiblesSize gt 0 then
• possibles-gtfirst().PId.debug('MOVING TO')
• else failedProcName.debug('CANT MOVE')
  endif

11
Using ATL

• Prohibitively difficult to create multiple output
  models from single input model
• Required for this experiment as wanted to
  simulate multiple failures to examine tolerance
• Over 3 million possible transformations
• Limited to matching input model items only once -
  means can only output transformed item once
• Use of lazy rules to get around limitation led to
  multiple error messages
• No easy command line automation of tool.

12
Epsilon

• A framework for creating task-specific languages
  for MDD/MDA.
• EOL provides generic navigation and modification
  facilities

13
Using Epsilon for Reconfiguration Analysis

• EOL was easy to use to generate valid
  configurations.
• Avoids ATL problems and can generate multiple
  output models for one input model.
• Constraints simple to implement as EOL has
  imperative operations as well as declarative
  constructs.
• Much more readable code
• Automation now possible due to ability to specify
  output file in program code and also ability to
  reset input model and re-use.

14
Epsilon Check Location Operation

• operation IFPCSModel!Processor
• checkLocation(oldProc IFPCSModel!Processor)
  Boolean
• for (t in oldProc.childTasks)
• if (t.TType ltgt IFPCSModel!TaskTypeINPUT)
• for (s in self.childTasks)
• if (s.TType t.TType)
• 'sametypes'.println()
• return false
• else
• if (s.TTypeIFPCSModel!TaskTypeFCS and
• t.TType IFPCSModel!TaskTypePCS)
• 'fcs and pcs'.println()
• return false
• else ...
• ...
• return true

15
Observations

• A mixture of declarative and operational styles
  is useful for these kinds of analysis.
• Despite AMMA having more mature tool support it
  was very difficult to use.
• A lack of documentation is currently the main
  problem, but this is improving.
• The Epsilon code took approximately 3
  person-hours to write, compared with 3
  person-days for the ATL code.
• Our view is that the ATL code is quite difficult
  to maintain.

16
Observations

• Epsilon provides DSL capabilities.
• Being able to use several different languages
  (EOL, ETL) meant that simplifications were
  possible.
• AMMA could provide such capabilities, but it is
  generally restricted to declarative
  specifications.
• We need many analyses for building safety
  critical systems.
• The ability to build custom analysis techniques,
  and use them with existing techniques, is
  critical.
• We need a best practice guide for using MDA,
  transformation, and analysis for safety critical
  systems.

17
Questions Feedback
?
?
?
?
?