Requirements Engineering and Modelling "Object oriented requirements engineering for the development - PowerPoint PPT Presentation

1 / 47
About This Presentation
Title:

Requirements Engineering and Modelling "Object oriented requirements engineering for the development

Description:

Centre d' tudes et de Recherches de Toulouse. Requirements ... DOTA. context: studies with industrials (Airbus, Dassault Aviation) research community ... – PowerPoint PPT presentation

Number of Views:74
Avg rating:5.0/5.0
Slides: 48
Provided by: jf187
Category:

less

Transcript and Presenter's Notes

Title: Requirements Engineering and Modelling "Object oriented requirements engineering for the development


1
Requirements Engineering and Modelling"Object
oriented requirements engineering for the
development avionics system"
  • Frédéric Boniol, Jack Foisseau

DTIM/MIB
2
Plan
  • 1. Context elements
  • 2. The PRISME project
  • 3. Requirements modelling
  • 4. Traceability
  • 5. Conlusion

3
1.Context elements
  • Avionics
  • Integrated Modular Avionics vs Classical avionics
  • Certification

4
1.1 Avionics
  • Basic notions (domain ontology)

A/C FUNCTION
SYSTEM
EQUIPMENT
5
1.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

6
1.2 "IMA" vs "Classical avionics"
  • Reasons for evolution
  • increasing complexity and number of A/C functions
  • increasing interdependence between systems
  • cost of avionics

7
1.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

8
Illustration ARINC-429 architecture
9
Illustration IMA-based architecture
10
1.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.)

11
1.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)

12
1.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

13
2 - 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

14
2.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)

15
2.2 PRISME focus
SYSTEM
HAEDWARE
SOFTWARE
16
2.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.)

17
2.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)

18
2.4 PRISME Models
Item system subsystem function
resource ...
item
item
19
Illustration
20
2.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

21
2.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)
22
2.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

23
2.8 Msqltconc and MDA
  • MDA Application development process

Core Model
PIM
instanceof
PSM Meta-Model
PSM
instanceof
24
Illustration
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)
25
Illustration
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)
26
Illustration
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)
27
2.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

28
2.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

29
2.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

30
3. 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

31
3.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

32
3.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
33
3.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)
34
3.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)
35
3.2 ME-1 Formalisation
Proposal of a textual notation for ME-1
36
3.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
37
3.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,..
38
3.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)
39
4 Traceability
  • 1 Requirements flowing
  • 2 The NP model
  • 3 Coupling NP with ME
  • 4 Coupling ME-MArg
  • 5 The PRISME models jungle

40
4.1 Requirements flowing
41
4.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
42
4.2 The NP model - definition of a design
solution
43
4.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
44
4.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
45
4.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)
46
4.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
47
5 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)
Write a Comment
User Comments (0)
About PowerShow.com