Title: Requirements Engineering and Modelling "Object oriented requirements engineering for the development
1Requirements Engineering and Modelling"Object
oriented requirements engineering for the
development avionics system"
- Frédéric Boniol, Jack Foisseau
DTIM/MIB
2Plan
- 1. Context elements
- 2. The PRISME project
- 3. Requirements modelling
- 4. Traceability
- 5. Conlusion
31.Context elements
- Avionics
- Integrated Modular Avionics vs Classical avionics
- Certification
41.1 Avionics
- Basic notions (domain ontology)
A/C FUNCTION
SYSTEM
EQUIPMENT
51.1 Avionics
- Avionics ?
- Set of equipment (software, hardware, sensors,
actuators and communications buses)
performing the required aircraft functions,
satisfying real time constraints satisfying
criticality constraints (certification) - Systems ?
- Abstract entities, introduced by a
standardisation authority (ATA 100) - defined as a set of equipment
61.2 "IMA" vs "Classical avionics"
- Reasons for evolution
- increasing complexity and number of A/C functions
- increasing interdependence between systems
- cost of avionics
71.2 "IMA" vs "Classical avionics"
- Main characteristics of Classical avionics
- dedicated hardware within equipment (LRUs)
- use of mono-emitter bus (ARINC 429)
- descriptive information attached to LRUs (inputs,
outputs, etc.)("equipment view") - high costs for maintenance
- Main characteristics of IMA
- on board installation of shared computing
resources - on board installation of shared communication
resources - requires an additional view, at system level (ex
inter systems data flows, system configuration,
etc.) - reduction in maintenance
8Illustration ARINC-429 architecture
9Illustration IMA-based architecture
101.3 Certification
- Airworhiness Authority
- Compliance to requirements must be shown before
the commercial aircraft is allowed to be operated
- " The aircraft systems and associated
components, considered separately and in relation
to other systems, must be designed so that the
occurrence of any failure condition which would
prevent the continued safe flight and landing is
extremely improbable and the occurrence of any
other failure condition which would reduce the
capability of the aircraft or the ability of the
crew to cope with adverse operating conditions is
improbable" - FAA-FAR 25 / JAA-JAR 25
- Risks are classified by severity
(catastrophic/hazardous/major/minor) and
probability of occurrence are quantified by
authorities ("extremely improbable" is less than
10-0 per operational flight hour, etc.)
111.3 Certification
- Safety demonstration by airframer
- for each safety requirement, the airframer has to
provide aviation authority with - the safety objectives
- the computed objectives
- and details of computations
- Airframers, aviation authorities have defined a
recommended process (SAE ARP 4754) incorporating
the principles of system engineering into the
certification process. It is based on three
major safety analyses (FHA, PSSA and SSA)
121.4 IMA - MDA
- Core concept of MDA
- separation of
- specification of system functionality
- specification of the implementation of that
functionality - "the same functional model should be able to run
on several implementation platforms, by defining
appropriate mappings" - Impacts of IMA
- specification of systems functionality
- specification of the shared computing and
communications resources - choice of implementation (LRUs, IMA) and
definition of the mappings on the shared
resources
132 - The PRISME Project
- 1 Objective and constraints
- 2 Focus
- 3 Approach and Hypotheses
- 4 The PRISME models
- 5 Abstraction levels
- 6 The PRISME Core Description (skeleton)
- 7 The Core Description models Msql_conc
- 8 Msql_conc and MDA
- 9 PRISME main results
- 10 Summary of the PRISME models
- 11 PRISME evaluation and exploitation
142.1 PRISME objective and constraint
- Project identity card
- 4 years, 1997-2000
- 10 ing. (5 full time per year)
- 3 ONERA departments
- DTIM
- DCSD
- DOTA
- context
- studies with industrials (Airbus, Dassault
Aviation) - research community (VERIMAG, LaBRI, IRCyN)
- Objective
- To define a global approach (A/C level) for
the definition, the validation, the integration
and qualification of classical and IMA avionics
systems (information processing part) - Constraints
- Taking into account three system view points
- functional
- real time performance
- safety
- Taking into account emerging system engineering
recommendations (EIA-632)
152.2 PRISME focus
SYSTEM
HAEDWARE
SOFTWARE
162.3 Approach and hypotheses
- Approach
- to develop avionics based on a set of models at
different abstraction levels - Hypotheses
- H1 there exists a core description - to be
found! - basis for the domain descriptions of
avionics (functional, real time performance and
safety) - H2 no development of new specification
languages (use of Lustre, Esterel, SDL, etc.) - H3 no development of new evaluation tools (use
of existing tools SES/Workbench, Modline,
FIABEX, etc.)
172.4 PRISME models
- Conceptual model
- set of concepts and relations between theses
concepts dedicated to the representation of
information about a system or about some
abstraction of this system - Required conceptual models for PRISME
- description of requirements defining an avionics
(ME) - description of a design solution for this
avionics (MSol) - description of evaluations of this solution (MR)
- description of evidences for requirements
satisfactions (MArg) - (NB interdependent conceptual models)
182.4 PRISME Models
Item system subsystem function
resource ...
item
item
19Illustration
202.5 PRISME abstraction levels
- Level types
- abstract (1..n) - informal / formal
specifications - concrete (1) - formal specifications
- Level contents
- 4 information sets modelled according to ME,
MSol, MR et Marg - instances of models are executable
- Conceptual models are the same for each level
except Msol - Msolabs ltMsqltabs, Mfctabs, MPTRabs, MSdFabsgt
- Msolconc ltMsqltconc, Mfctconc, MPTRconc,
MSdFconcgt
212.6 PRISME Core Description
- At an abstract level Msqlttabs
- primitive building block component
- several types of component
- functional component
- computing and communication component
- service component
- mixed component
- At the concrete level
- ltMsqltconc, Mfctconc, MPTRconc, MSdFconcgtwith
Msqltconc ltML, MA, MIgt (3 additional
conceptual models)
Safety View
RT View
Fct View
Core (skeleton)
222.7 PRISME Msqltconc
- ML
- a conceptual model for describing a functional
item in terms of "computation" and "logical data" - MA
- a conceptual model for describing a computing
and/or communication item in terms of "computing
resource" and "bus" - MI
- a conceptual model for describing the mapping of
functional items on a computing and/or
communication items, in terms of "partitions",
"channel", "data packages" (based on ARINC 653)
Msqltconc is used for building a structural
definition of a system (semantics will be added
througth the domain models MFct, MPTR, MSdF
232.8 Msqltconc and MDA
- MDA Application development process
Core Model
PIM
instanceof
PSM Meta-Model
PSM
instanceof
24Illustration
Virtual channel
from this channel
put on this channel
this data
this data
Data
consumes
produces
on port
Computation
on port
n
occurrence de
1
Input Parameter
Output parameter
Computation type
ML (extract)
25Illustration
CPU
Gateway
Emitting Unit
Receiving Unit
1
1
Resource
n
n
1
offre
n
n
n
Virtual CPU
connected to
1
connected to
1
Bus
MA (extract)
26Illustration
n
groups
Data
Packet
n
1
n
executes
n
1
Computation
Partition
Virtual CPU
n
implements
n
Virtual channel
Bus
n
n
implements
n
Reception Unit
implements
Gateway
Emission Unit
n
MI (extract)
272.9 PRISME main results
- The definitions of the various conceptual models
(UML class diagrams, TELOS-like formal
specifications)
- A proposal of a modelling approach
- A software platform
- a data base storing information modelled
according to the conceptual models - couplings with specification languages (Esterel,
Lustre, Altarica, SdL)and with evaluation tools
(functional and disfunctional simulations, model
checking for properties verification, etc.
- An hardware platform
- Unix RT workstations interconnected with a FDDI
bus allowing to emulate avionics architectures,
avionics communication protocols (Arinc 629,
AFDX, etc.)
- A tool chain between the two platforms
- A case study for demonstration
- a representative subset of the A340 avionics
282.10 PRISME Summary of models
NP model
- ME representation of requirements
- MSolAbs representation of an abstract design
solution - MSolConc representation of a concrete design
solution
- MSqlAbs representation of the core of an
abstract design solution - MFctAbs, MPTRAbs, MSdFAbs abstracts
behaviours
- MSqlConc representation of the core of a
concrete design solution - MA physical view
- ML logical view
- MI mapping logical onto physical
- MFctConc, MPTRConc, MSdFConc concrete
behaviours
- MR representation of evaluation results
- MArg representation of requirements
satisfaction argumentations
292.11 PRISME Evaluation and Exploitation
- Evaluation
- works done in the project has been evaluated by
an external panel - industrial representatives Airbus, Dassault
Aviation - academic representatives Univ of La Rochelle,
Univ. Of Nantes/ERCCyN - Exploitation
- in research projects
- current CEE projects ESACS and VICTORIA
- in an internal ONERA new project on military
avionics system engineering - in industrial context
- part of the PRISME model act as foundation for an
AIRBUS software tool dedicated to the management
of numerical exchanges between systems
303. REQUIREMENTS ENGINEERING
- 1 PRISMEcontext and objective
- 2 The ME-1 model for requirements representation
- 3 The ME-2 model for requirements representation
- 4 Requirements flowing
313.1 PRISME context and objective
- Current practice at the beginning of the project
- requirements are listed in some documents,
essentially for the equipment level - demands for
- more structured documents (--gt requirements
types) - requirements at A/C level, system level and
equipment level - traceability
- requirements management ("requirement as object")
- PRISME objective
- to work on the representation of (the contents
of) requirements - to propose dedicated notations and models
- 2 proposals ME-1, ME-2
323.2 ME-1
- Approach
- analysis of requirements documents from Airbus
- analysis of proprietary standards (ABD 100, ABD
200) dealing with the production of design
documents - Basis of proposal
- "atomic requirement" considered as the definition
of one and only one constraint on something
Ext-2
Entity of Interest
Ext-1
Ext-3
333.2 ME-1 basis
under
REQUIREMENT
CONDITION
Name lt
idgt
Name lt
idgt
Modality lt
modgt
Statement lt
txtgt
Constraint lt
expgt
- Modality
- strength of a requirement (shall, will, )
- Condition
- validity domain of a requirement
- Additional concepts
- source
- assumption
- rationale
on
on
Imposed_on
RELATION
ATTRIBUTE
Name lt
idgt
Name lt
idgt
Statement lt
txtgt
Statement lt
txtgt
characterises
links
ENTITY
Name lt
idgt
Statement lt
txtgt
ME-1 (extract)
343.2 ME-1 adaptation to avionics abstraction levels
- Typology for system level entities
- the systems we are interested in
- the services they provide
- their interfaces with external systems
- some internal design elements already known
(components, communication means, etc.)
ME-1 (extract)
353.2 ME-1 Formalisation
Proposal of a textual notation for ME-1
363.2 ME-1 Use
-
Manual translation
"The OIS shall permit to retrieve fastly the
available documentation and to display and/or
print it
The same expressed in ME-1 language
Original format
373.2 ME-1 Use
Informal statements
representation with patterns
Syntactic analysis
Type semantics
Set of declarations
compilation
Set of logical assertions (PROLISP)
decompilation
Consistancy, integrity,
analysis, querying,..
383.3 ME-2
- Modification of ME-1
- to be able to associate requirements with design
objects - an atomic requirement is seen as a constraint on
a parameter of an entity, or on a parameter on
some characteristic (sub-characteristic,
sub-sub-, etc) of an entity - parameters correspond to targets of evaluation
CONDITION
under
REQUIREMENT
decomposedInto
on
of
CHARACTERISTIC
PARAMETER
of
of
ENTITY
ME-2 (extract)
394 Traceability
- 1 Requirements flowing
- 2 The NP model
- 3 Coupling NP with ME
- 4 Coupling ME-MArg
- 5 The PRISME models jungle
404.1 Requirements flowing
414.2 The NP model - declaration of a component
developpement
Has_def-envt
Produces/consumes/provides
contains
COMP_USE statement
DEF_ENV statement
INTERFACE statement type
Is a use of
transports / connected_to
DEVCOMP level statement
produces / consumes / offers
COMPONENT type
target
NP-dc declaration of a component development
424.2 The NP model - definition of a design
solution
434.3 Coupling NP and ME
satisfies
Refined-into
allocated-to
Derives from
REQUIREMENT
Allocated-to
ASSEMBLAGE
Implemented-by
COMPONENT
design solution for
Realised-by
INTERFACE
justifies
HYPOTHESE
DECISION
NP-ME associations for connecting development
states at different levels
444.3 Coupling NP with ME targets of requirements
dans
CONDITION
REQUIREMENT
constraints
Decomposed-into
of
PARAMETER
CHARACTERISTIC
of
of
ENTITY
COMP_USE
ENVIRt
DEVCOMP
COMPONENT
INTERFACE
produces/consumes requires/has
transports
454.4 ME-MArg
REQUIREMENT
Is_a
DESIGN_REQ
SR_REQ
SR_ASSMNT_REQ
GNRL_REQ
Is_a
CLASS_REQ
SEG_REQ
DET_REQ
PROP_REQ
argument_of
REQUIREMENT
CLASS_REQ
argument_by_result
argument_by_subarg
contains
RESULT
ARGUMENTATION
SEV_REQ
OBJ_REQ
CAUSE_REQ
composed_with_law
COMB_LAW
Specialisation of ME for safety requirements
argument_by_aff
AFFIRMATION
MArg conceptual model (extract)
464.5 The PRISME models jungle
NP
allouéeA
ME
dans
CONDITION
EXIGENCE
découleDe
contraint
allouéeA
seDécomposeEn
de
PARAMETRE
CARACTERISTIQUE
de
de
ENVIRt
contient
COMP_USE
ITEM
estUneUtilisationDe
COMPOSANT
réaliséePar
DEVCOMP
INTERFACE
HYPOTHESES
produit/consomme nécessite/possède
MPTRabs
transporte
justifie
MSolabs
contient
ENVIRt-SOL
MFCTabs
solutionDe
contient
ASSEMBLAGE
MODE
ACTIVITE
concerne
DECISION
FDATA
ARCH_MAT
ARCH_LOG
ACTIVITE-PTR
MSolconc
COMPUTATION
Lustre, Esterel
475 Conclusion
- The PRISME models capture information handled in
avionics system development with many
dependencies between information - The models define an integrated information
framework defining a global avionics (system of
systems, subsystems, equipment, IMA architecture,
etc.) - multi-domain integration (functional, real time
performances, safety) - integration of requirements-design-evaluation
results-argumentation - integration of abstraction levels
- integration of functional view and physical view
(MDA)