engine controls rodin eu project ist511599 reft’05 – newcastle, july 2005 towards a methodology...
Post on 15-Jan-2016
217 views
TRANSCRIPT
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
Towards
a
methodology for rigorous
development
of
generic requirements
patterns
Colin Snook, Mike Poppleton - University of SouthamptonIan Johnson - AT Engine Controls
(ATEC)
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
Background
•Rodin project - Case study• Fault tolerant systems + rigorous methods• Failure Management Subsystem of aircraft engine control• Re-use at specification level (formal v & v)• Re-use within project - Domain specific language• Product line engineering - produce variants
•Tools at University of Southampton:• UML-B = UML profile for formal UML (based in B)• U2B = translates UML-B into B • ProB = animator and model checker for B
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
Failure
Management
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
Overview
of
Process
instantiate generic model
verifyinstantiation
specific application requirements
specific model
consistent specificmodel
domain analysisdomain
engineering
first-cut generic model
validated generic model
previous product experience
for each new application
once for the domain
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
Domain
Analysis
instantiate generic model
verifyinstantiation
specific application requirements
specific model
consistent specificmodel
domain analysisdomain
engineering
first-cut generic model
validated generic model
previous product experience
for each new application
once for the domain
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
Domain
Analysis
•Identify common requirements *• Taxonomy for domain
•Requirement rationale (the why)• Justify reasoning behind requirement decisions
•Relationships between elements• A first-cut model of the domain
•Nat.lang. generic spec. (semi-rigorous style)
• rationale – explanation• precise statement of requirement
* Lam: Achieving Requirements Reuse: A Domain- specific Approach from Avionics, J.Systems Software 1997 38:197-209
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
Some
Typical
Requirements
Value tested High limit
Low limit
Rate limit Conditions for test
ESa*
120% 0% 100%/sec Engine Stood
120% 10% 100%/sec Engine Starting
120% 50% 100%/sec Engine Running
ESb*120% 0% 100%/sec Engine Stood
120% 10% 100%/sec Engine Starting
120% 50% 100%/sec Engine Running
ESa – ESb 5% -5% - ESa >30% or ESb >30%
Table 2. Remedial Actions
Value failed Procedure Code
ESa Select ESb if available ES1
otherwise switch to backup system
ESb Select ESa if available ES2
ESa - ESb Use highest of ESa and ESb ES3
Table 1. Failure Detection
*ESa – Engine speed (main input), ESb – Engine speed (alternative input)
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
Taxonomy
of requirements
INP input (to the failure management subsystem)
COND condition for a test
DET failure detection mechanism
CONF confirmation of suspected failure
ACT an action taken
OUT output (from the failure management subsystem)
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
First-cut
model in
UML
UML class diagram representation of relationships between kinds of functional requirements
INPCOND test 0..*0..*
+input
0..*0..*0..* 1
+cond
0..* 1
DET CONF
11 11
OUT
ACT
0..*
1 +tAct0..*
1
0..*
1
+pAct
0..*
1
0..*1
+hAct
0..*1
1..*
1..*
+out 1..*
+act 1..*
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
Example
of format
Rationale:
The subsystem needs to be tolerant to isolated errors, which may be transient, so as to maintain stability in the control system. In order to achieve this, a failure confirmation mechanism is employed to confirm when a firm fault has been established.
CONF2 A sensor input will have been determined to have failed, only if a failure confirmation mechanism has confirmed it.
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
Instantiation
of
spec.
Ref. value tested
Name dir limit [MAG2]
Freq mS
Condition Confirm
MAG1.1 INP2.1 ET1 up 1900 24 COND1 CONF4.4 MAG1.2 INP2.1 ET1 lo -100 24 COND1 CONF4.4 MAG1.3 INP2.2 ET2 up 1900 24 COND1 CONF4.4 MAG1.4 INP2.2 ET2 lo -100 24 COND1 CONF4.4 MAG1.5 INP2.3 ET3 up 1900 24 COND1 CONF4.4 MAG1.6 INP2.3 ET3 lo -100 24 COND1 CONF4.4 MAG1.7 INP2.4 ET4 up 1900 24 COND1 CONF4.4 MAG1.8 INP2.4 ET4 lo -100 24 COND1 CONF4.4 MAG1.9 INP2.5 ET5 up 1900 24 COND1 CONF4.4 MAG1.10 INP2.5 ET5 lo -100 24 COND1 CONF4.4 MAG1.19 INP2.10 Esa up 130 24 COND1 CONF4.1 MAG1.20 INP2.10 Esa lo 10 24 COND5.2 CONF4.1 MAG1.21 INP2.10 Esa lo 45 24 COND5.3 CONF4.1 MAG1.22 INP2.11 Esb up 130 24 COND1 CONF4.1 MAG1.23 INP2.11 Esb lo 10 24 COND5.2 CONF4.1 MAG1.24 INP2.11 Esb lo 45 24 COND5.3 CONF4.1 MAG1.25 INP2.12 EP up 200 24 COND1 CONF4.1 MAG1.26 INP2.12 EP lo 1.5 24 COND5.4 CONF4.1 MAG1.27 INP2.12 EP lo 1.3*AP 24 COND5.5 CONF4.1 MAG1.28 INP2.13 AP up 20 24 COND1 CONF4.4 MAG1.29 INP2.13 AP lo 4 24 COND1 CONF4.4 MAG1.30 INP2.14 Apo up 20 24 COND1 CONF4.1 MAG1.31 INP214 Apo lo 4 24 COND2.6 CONF4.1 MAG1.32 INP2.15 EQ up 140 24 COND1 CONF4.5 MAG1.33 INP2.15 EQ lo -10 24 COND2.7 CONF4.5 MAG1.34 INP2.16 Eqo up 140 24 COND1 CONF4.5
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
Domain
Engineering
instantiate generic model
verifyinstantiation
specific application requirements
specific model
consistent specificmodel
domain analysisdomain
engineering
first-cut generic model
validated generic model
previous product experience
for each new application
once for the domain
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
Model revised for
U2B
INP
<<create>> addInp(detset : POW1(DET))
DET
<<create>> addDet(cd : COND, cf : CONF)
1..*
1..*
1..*
+dets1..*
CONF
<<create>> addConf(haSet : POW1(ACT), taSet : POW1(ACT), paSet : POW1(ACT))
1
1
+conf1
1
OUT
<<create>> addOut()
COND
<<create>> addCond()10..*
+dCond
10..*
ACT
<<create>> addAct(out : OUT, cd : COND)
1..*0..*
+tAct
1..*0..*0..*0..* +pAct 0..*0..*
0..*0..*
+hAct0..*0..*
1
1..*
+aOut 1
1..*
1
0..*
+aCond 1
0..*
INVARIANTunion(ran(hAct)) \/ union(ran(tAct)) \/ union(ran(pAct)) = ACT
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
Validating
generic
model
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
Validated
generic
model
OUT
CONDDET
10..*
+dcond
10..*
ACT
1
1..*
+aOut 1
1..*
1
0..*
+aCond 1
0..*
INP
CONF
1
1..*
1
+dets 1..*
1..*0..* +tAct 1..*0..*
0..*0..*
+pAct
0..*0..*
0..*0..*+hAct
0..*0..*
1
1
+input1
1
INVARIANT union(ran(hAct)) \/ union(ran(tAct)) \/ union(ran(pAct)) = ACT
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
Defining
a
specific
application
instantiate generic model
verifyinstantiation
specific application requirements
specific model
consistent specificmodel
domain analysisdomain
engineering
first-cut generic model
validated generic model
previous product experience
for each new application
once for the domain
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
Instance
model
OUT
CONDDET
10..*
+dcond
10..*
ACT
1
1..*
+aOut1
1..*
1
0..*
+aCond 1
0..*
INP
CONF
1
1..*
1
+dets 1..*
1..*0..* +tAct 1..*0..*
0..*0..*
+pAct
0..*0..*
0..*0..*
+hAct
0..*0..*
1
1
+input1
1
INSTANCES {act52,act55,act82,act83,act84,act810,act132,act133,act...
INSTANCES cd1,cd523,cd524,cd529,cd530,cd27,cd52,cd53}
INSTANCES {o0,o33,o52,o61,o612}
INITIALISATION$aCond:={act52 |-> cd1,act55 |-> cd1,act82 |-> cd1,act83 |-> cd523,act84 |-> cd524,act810 |-> cd1,act132 |-> cd529,act133 |-> cd530,act134 |-> cd1,act1310 |-> cd1 }
INITIALISATION$aOut:={act52 |-> o52,act55 |-> o33,act82 |-> o52,act83 |-> o52,act84 |-> o0,act810 |-> o33,act132 |-> o52,act133 |-> o61,act134 |-> o...
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
Verifying the
specific
model
instantiate generic model
verifyinstantiation
specific application requirements
specific model
consistent specificmodel
domain analysisdomain
engineering
first-cut generic model
validated generic model
previous product experience
for each new application
once for the domain
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
Verifying
specific
application
says which law is broken but not who broke it
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
Future
Work
• Behaviour• validate specific application • need behaviour to animate with ProB• behaviour should be in generic model
• Thoughts:•…behaviour should come via abstraction•…rationale (key issues) abstract reqmts.•…refine and verify in generic model
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
Adding
verification
of rationale
instantiate generic model
domain analysis domain engineering
first-cut generic model
validated generic model
(with behaviour)
previous product experience
for each new application
once for the domain
verify key issues
generic model(verified)
requirements rationale
abstract generic model
abstractdomain engineering
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
Validation
of
Specific
model
instantiate generic model
verifyinstantiation
specific application requirements
specific model
consistent specificmodel
generic model(verified)
for each new application
validateinstantiation
validated specificmodel
Engine Controls
REFT’05 – Newcastle, July 2005
Rodin EU project IST511599
Summary
•RE process for generic domains (early stages of) • rigorous but friendly• close mapping to problem domain• re-usable components… (DSL for RE)• product line method for complex domains
•Current Tools• UML-B enables visualisation of models• ProB animation - validation of generic model• ProB model checker - verification of specific
• but could be difficult to find offending data
• Future work• Add behaviour• Provide tool support for instantiation phase