Presentation is loading. Please wait.

Presentation is loading. Please wait.

Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 Towards a methodology for rigorous development of generic requirements patterns.

Similar presentations


Presentation on theme: "Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 Towards a methodology for rigorous development of generic requirements patterns."— Presentation transcript:

1 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 Towards a methodology for rigorous development of generic requirements patterns Colin Snook, Mike Poppleton - University of Southampton Ian Johnson - AT Engine Controls (ATEC)

2 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 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

3 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 Failure Management

4 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 Overview of Process instantiate generic model verify instantiation specific application requirements specific model consistent specific model domain analysis domain engineering first-cut generic model validated generic model previous product experience for each new application once for the domain

5 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 Domain Analysis instantiate generic model verify instantiation specific application requirements specific model consistent specific model domain analysis domain engineering first-cut generic model validated generic model previous product experience for each new application once for the domain

6 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 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

7 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 Some Typical Requirements Value testedHigh limit Low limit Rate limitConditions for test ESa* 120%0%100%/secEngine Stood 120%10%100%/secEngine Starting 120%50%100%/secEngine Running ESb* 120%0%100%/secEngine Stood 120%10%100%/secEngine Starting 120%50%100%/secEngine Running ESa – ESb5%-5%-ESa >30% or ESb >30% Table 2. Remedial Actions Value failedProcedureCode ESaSelect ESb if availableES1 otherwise switch to backup system ESbSelect ESa if availableES2 ESa - ESbUse highest of ESa and ESbES3 Table 1. Failure Detection *ESa – Engine speed (main input), ESb – Engine speed (alternative input)

8 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 Taxonomy of requirements INP input (to the failure management subsystem) CONDcondition for a test DETfailure detection mechanism CONFconfirmation of suspected failure ACTan action taken OUToutput (from the failure management subsystem)

9 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 First-cut model in UML UML class diagram representation of relationships between kinds of functional requirements

10 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 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.

11 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 Instantiation of spec.

12 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 Domain Engineering instantiate generic model verify instantiation specific application requirements specific model consistent specific model domain analysis domain engineering first-cut generic model validated generic model previous product experience for each new application once for the domain

13 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 Model revised for U2B

14 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 Validating generic model

15 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 Validated generic model

16 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 Defining a specific application instantiate generic model verify instantiation specific application requirements specific model consistent specific model domain analysis domain engineering first-cut generic model validated generic model previous product experience for each new application once for the domain

17 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 Instance model

18 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 Verifying the specific model instantiate generic model verify instantiation specific application requirements specific model consistent specific model domain analysis domain engineering first-cut generic model validated generic model previous product experience for each new application once for the domain

19 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 Verifying specific application says which law is broken but not who broke it

20 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 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

21 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 Adding verification of rationale instantiate generic model domain analysisdomain 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 abstract domain engineering

22 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 Validation of Specific model instantiate generic model verify instantiation specific application requirements specific model consistent specific model generic model (verified) for each new application validate instantiation validated specific model

23 Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 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


Download ppt "Engine Controls Rodin EU project IST511599 REFT’05 – Newcastle, July 2005 Towards a methodology for rigorous development of generic requirements patterns."

Similar presentations


Ads by Google