Update on AADL Requirements Annex - Confluence · PDF fileShort presentation sessions ... (query, use cases languages) ... •Transform the informal textual document into

OpenOpen--PEOPLEPEOPLEOpen Power and Energy Optimization Open Power and Energy Optimization

PLatformPLatform and Estimatorand Estimator

Update on AADL Requirements AnnexDominique BLOUIN*

*Lab-STICC, Université de Bretagne Sud, Lorient, FRANCE

AADL Standards Meeting, October 18-21, 2011

OUTLINE

• Publication of annex at ModRE workshop• Publication of annex at ModRE workshop.

• Modeling of the Isolette Thermostat Example.

• Progress on Requirements Definition and Analysis Tool.

• Future Work.

Update on Requirements Annex 2AADL Standards Meeting, October 18-21 2011

RDAL at ModRE

Requirements annex presented at ModRE (Model-Driven Requirements Requirements annex presented at ModRE (Model Driven Requirements Engineering) workshop.

Short presentation sessions (10 min + 5 min questions). Modeling of a common requirements specification with language / method ofModeling of a common requirements specification with language / method of choice (afternoon). Did not work out well since most participants were not prepared.

Main RE Conference ParticipationOpportunity to meet the RE community. A lot of interesting work A lot of interesting work.


ISOLATE THERMOSTAT EXAMPLE•Start from set of Best Practices in RE for Real-Time Embedded Systems with Isolette Thermostat example.

P id h i l f RDAL•Provide a comprehensive example of RDAL usage with AADL + other formalisms (query, use cases languages) in the SAE annex document.

•The REMH is a very nice complement of the requirements annex.

•Goals of presented approach:•Transform the informal textual document into formal models using a set of dedicated languages.languages.•Models becomes central artifacts.•Documentation ideally generated from the models.

Update on Requirements Annex 4

•Keep the language generic enough to be usable with other approaches.

AADL Standards Meeting, October 18-21 2011

ISOLATE THERMOSTAT EXAMPLE

Other ideas from:

•Requirements Engineering (van Lamsweerde)•KAOS language / method.

•User Requirements Notation (URN) (ITU-T, Recommendation Z.151 (11/2008).

•UCM (Use Case Maps) in particularUCM (Use Case Maps) in particular.

•Requirements change uncertainty modeling and analysis.

•from Managing Requirements Uncertainty in Engine Control Systems Development, Nolan et al., at RE 2011.•Take into account volatility impact precedence•Take into account volatility, impact, precedence and time criticality to develop requirements.•Study on projects conducted at Rolls Royce.



REMH’s best practices overview:

1 Develop the System Overview1.Develop the System Overview.2.Identify the System Boundary.3.Develop the Operational Concepts.4.Identify the Environmental Assumptions.5.Develop the Functional Architecture.6.Revise the Architecture to Meet Implementation Constraints.p7.Identify System Modes.8.Develop the Detailed Behavior and Performance Requirements.9 Define the Software Requirements9.Define the Software Requirements.10.Allocate System Requirements to Subsystems.11.Provide Rationale.



Best Practice Isolette Thermostat Example1. Develop the System Overview

1. Develop System Overview Early.P id S t S i

Best Practice Isolette Thermostat Example

2. Provide System Synopsis.3. Identify System Contexts.4. Use Context Diagrams.5. Describe External Entities.6. Capture Preliminary System Goals.7. Maintain System Goal Information.


ISOLATE THERMOSTAT EXAMPLEUse AADL as context diagram.

RDAL Elements



2. Identify the System Boundary1. Identify the System Boundary Early.

Ch E i t l V i bl2. Choose Environmental Variables.1. Variables that would exists even is the system-

to-be would not.3. Choose Controlled Variables.

D id ifi d f f1. Data types identified from features on system-to-be with “out “or “provides” directions.

4. Choose Monitored Variables.1. Data types identified from features on system-

to be with “in” or “requires” directionsto-be with in or requires directions.5. Ensure Environmental Variables are Sufficiently

Abstract.6. Avoid Presentation Details in Environmental

VariablesVariables.7. Define All Physical Interfaces.

1. Use AADL Type Declarations



Use UML Use Case Diagrams.

3. Develop the Operational Concepts1. Document Sunny Day System Behavior.

g

2. Include How the System is Used in its Operating Environment.3. Employ the Use Case Goal as its Title.4. Trace Each Use Case to System Goals.5. Identify Primary Actor, Preconditions, and Postconditions.


ISOLATE THERMOSTAT EXAMPLE Use UML Activity / Sequence Diagrams for Scenarios.

6. Ensure Each Use Case Describes a Dialogue between Primary Actor, System and other Actors.

7. Link Use Case Steps to System Functions (know where the function is used in case of changes).p y (8. Consolidate Repeated Actions Into a Single Use Case.9. Describe Exceptional Situations as Exception Cases.10. Describe Alternate Ways to Satisfy Postconditions as Alternate Courses.11. Use Names of External Entities or Environmental Variables.12. Avoid Operator Interface Details.13. Update the System Boundary (add new variables discovered during use cases definition).



Or use UCM (Use Case Maps ) diagrams (sublanguage of URN ITU standard).

Use Case Pre/post conditions Primary Actors

( p ) g ( g g )

Exception/ Use Cases Stubs

Steps



4. Identify the Environmental Critical when integrating systems developed byyAssumptions

1. Define the Type, Range, Precision, and Units

2. Provide Rationale for the

Critical when integrating systems developed by different teams.

Integration scenario:2. Provide Rationale for the Assumptions.

3. Organize Assumptions Constraining a Single Entity

4. Organize Assumptions Constraining

g Each team uses a copy of the AADL system overview model.

Each team provides AADL component implementation + Several Entities

5. Define a Status Attribute for Each Monitored Variable (valid/invalid + possibly others).

ac tea p o des co po e t p e e tat oassociated requirements specification (including formal assumptions).

Assumptions for every requirements specifications are verified for the complete AADL model at model integration time.



Assumption Decomposition

Formal Assumption

Declare Status Properties

Rationalep


ISOLATE THERMOSTAT EXAMPLE5. Develop the Functional Architecture

1. Organize System Functions Into Related Groups (robust in face of change, cohesion).

2. Use Data Flow Diagrams to Depict System Functions and their Dependencies.Mi i i D d i B t F ti3. Minimize Dependencies Between Functions (low coupling).1. Flows represent stable high level

concept from the domain (less subject to change)

Start with functions from use cases. Organize functions related to operator interface together (likely to change together,

h i )change).2. Volatile dependencies pushed down into

the function hierarchy.4. Define Internal Variables.5 Nest Functions and Data Dependencies for

cohesive).

5. Nest Functions and Data Dependencies for Large Specifications.

6. Provide High Level Requirements that are Really High Level.

7. Do Not Incorporate Rationale Into the pRequirements.


ISOLATE THERMOSTAT EXAMPLE Requirements groups represent system functions. Nested functions (sub-functions) as requirement decomposition. Verify this requirements organization.



Trace Use Case Steps


ISOLATE THERMOSTAT EXAMPLE Use AADL to represent data flow diagrams.

AADL flows are relevant. How should functions and their hierarchy be modeled?

Nested Functions


ISOLATE THERMOSTAT EXAMPLE6. Revise the Architecture to Meet

I l t ti C t i t Typical constraints: safety,

Implementation Constraints1. Modify the Architecture to Meet Implementation

Constraints.2. Keep Final System Architecture Close to Ideal

performances, integration with legacy systems, etc…

C F ti l H dFunctional Architecture.1. Ideal functional architecture (domain) is less

subject to change.3. Revise the System Overview

Compare Functional Hazard Assessment with obstacles analysis in van Lamsweerde.

4. Revise the Operational Concepts5. Develop Exception Use Cases.6. Link Exception Cases to Use Cases7. Revise the System Boundary (new environment

Introduced safety requirements are flagged as derived.

variables).8. Document Changes to Environmental

Assumptions.9. Revise Dependency Diagrams.10. Revise High Level Requirements.


ISOLATE THERMOSTAT EXAMPLE7. Identify System Modes Modes introduced to handle externally

1. Identify Major System Modes.2. Define How the System Transitions Between

Modes.3. Introduce Modes Only for Externally Visible

Di ti iti

visible discontinuities in system behavior.

Simplify requirements specifications by b ki th l ti b t it dDiscontinuities breaking the relations between monitored and controlled variables into pieces for each mode.

Mode declared in requirement condition part of requirement expression.

Add trace facility from requirement to system mode?


ISOLATE THERMOSTAT EXAMPLE8. Develop the Detailed Behavior and

P f R i t The detailed behavior defines

Performance Requirements1. Specify the Behavior of Each Controlled

Variable.2. Specify the Requirement as a Condition and an

relationships between controlled and monitored variables that must be imposed by the system.

Assigned Value.3. Ensure that the Detailed Requirements are

Complete.4. Ensure that Detailed Requirements are

Consistent

If condition, assignment and mode can be identified from requirement’s expression, we can verify that every Consistent.

5. Ensure that the Detailed Requirements are not Duplicated.

6. Organize the Requirements.7 Define Acceptable Latency for Each Controlled

p , y ycontrolled variable is assigned, for every mode (using the unspecified status value when not relevant), and that assignments are consistent and not duplicated7. Define Acceptable Latency for Each Controlled

Variable.8. Define Acceptable Tolerance for Each

Controlled Variable.9 Do not Define Latency and Tolerance for

are consistent and not duplicated.

Use AADL flows to define latencies.9. Do not Define Latency and Tolerance for

Internal Variables. Trace latency and tolerance specification by a requirement and set rationale.


rationale.

ISOLATE THERMOSTAT EXAMPLE9. Define the Software Requirements Derive software requirements from

1. Specify the Input Variables.2. Specify the Accuracy of Each Input Variable.3. Specify the Latency of Each Input Variable.4. Specify IN’ Relationships for Each Monitored

system requirements.

Two different specs because the t i bl d t tl t hVariable.

5. Specify the Status of Each Monitored Variable.1. Specify the function that defines how

system variables do not exactly match the software variables (syst. Var. translated into software inputs/outputs.

the status variable is set.6. Flag Design Decisions as Derived

Requirements.1. The requirements specifying how the

stat s is set is a deri ed req irement

Variant of 4 variables model.

status is set is a derived requirement. TODO: derived from which requirement??


ISOLATE THERMOSTAT EXAMPLE10. Allocate System Requirements to

S b t Systems decomposed into sub-

Subsystems1. Identify Subsystem Functions.2. Duplicate Overlapping System to Subsystem

Functions.

systems that can be developed independently.

H l i t t3. Develop a System Overview for Each Subsystem4. Identify the Subsystem Monitored and Controlled

Variables.5. Create New Monitored and Controlled Variables.

How are overlapping system to subsystem functions linked? Duplicate or just trace requirements located in a different specification?

6. Specify the Subsystem Operational Concepts.7. Identify Subsystem Environmental Assumptions

Shared with Parent System8. Identify Environmental Assumptions of the New

p

Identify variables that are shared and must be consistent with those of the

Monitored and Controlled Variables.9. Complete the Subsystem Requirements

Specification.

parent system. They are the subsystem interface for integration.


ISOLATE THERMOSTAT EXAMPLE11. Provide Rationale

1. Provide Rationale to Explain why a Requirement Exists.2. Avoid Specifying Requirements in the Rationale.

1. Rationale is not contractually binding as opposed to requirement elements.3. Provide Rationale when the Reason a Requirement Exists is not Obvious.4. Provide Rationale for Environmental Assumptions.5. Provide Rationale for Values and Ranges.6. Keep Rationale Short and Relevant.

1. Refer to a document instead of copying long statements.py g g7. Capture Rationale as Soon as Possible.

1. Ensure that it is captured by the requirement author at the same time the requirement is created so that it can be reviewed by others.


Requirements analyses that can be performed:

ISOLATE THERMOSTAT EXAMPLEq y p Consistency: for a given (mode, condition and controlled variable), verify that assignments are consistent. Completeness: for a given (mode, condition and controlled variable), verify that assignments exist. Duplication and vacuity: for a given (mode, condition and controlled variable), verify that assignments are not duplicated or that a requirement assignment is equivalent to combined requirements assignmentscombined requirements assignments.

Formal requirements verification by architecture model. Formal assumptions verification (especially at system architecture models Formal assumptions verification (especially at system architecture models integration).

Latency verification for each controlled variable Latency verification for each controlled variable. Latency of entire flow (including software) meets the maximum latency defined as non functional requirement at system level.

Tolerance verification. Tolerance verification. Same as latency.


PROGRESS ON TOOL

REAL integration started about a month ago but stopped. Use reimplementation of REAL from Steve’s team (Lute) instead of Ocarina. Includes language evolutions.g g Released as an Eclipse plugin. Has been made public.

Other development planned to implement modifications discovered by modeling the Isolette thermostat example.

Update on Requirements Annex 26AADL Standards Meeting, June 06-09 2011

FUTURE WORKLanguageg g Finalize Isolette Thermostat Example modeling and documentation. Use GCPA Pump as second example? Define a textual concrete syntax Define a textual concrete syntax. ReqIF:

New RMF (Requirements Modeling Framework) project in Eclipse lead by ItemisItemis. See how we could contribute.

Tool Finish REAL integration. Implement language evolutions discovered with examples.p g g p Rebuild diagram with Obeo Designer? Migrate to OSATE V2.


NOTES


Documents

Update on AADL Requirements Annex - Confluence · PDF fileShort presentation sessions ... (query, use cases languages) ... •Transform the informal textual document into