update on aadl requirements annex - confluence on aadl requirements annex dominique blouin1, skander...

Open-PEOPLEOpen Power and Energy Optimization

PLatform and Estimator

Update on AADL Requirements AnnexDominique BLOUIN1, Skander TURKI2, Eric SENN1

1Lab-STICC, Université de Bretagne Sud, Lorient, FRANCE2Taif University, Taif, Saudi Arabia

AADL Standards Meeting, April 16–19, 2012

Update on Requirements Annex 2

OUTLINE

• Status of Work

• Analyses of RDAL Specifications

• Quantitative Analysis Modeling Language

• Future Work

AADL Standards Meeting, April 16–19 2012

Language

Purpose of latest work has been to improve RDAL in order to formalize some of the FAA Requirements Engineering Management Handbook (REMH) best practices:


STATUS OF WORK


1.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.7.Identify System Modes.8.Develop the Detailed Behavior and Performance Requirements.9.Define the Software Requirements.10.Allocate System Requirements to Subsystems.11.Provide Rationale.

Language Emphasis has been put on the specification of the language instead of the tool.

RDAL currently allows to formally represent:1. System Overview

Including Goals, Operational Contexts (with AADL).2. System Boundary

Set of monitored and controlled variables linked to features of system architecture components declared in the system overview.

3. Use Cases with traceability from functional requirements to use-case steps. Thanks to the Use-Case Maps (UCM) part of the User Requirements Notation (URN).

4. Environmental Assumptions Requirements on the environment.

5. Functional Architecture High level functional requirements traced to data flow diagrams represented with AADL2 subprograms.


STATUS OF WORK


Language6. Design Revision to Meet Implementation Constraints

Needs further study. Reuse the concept of Domain Properties.

7. System Mode Identification RDAL traces AADL system operation modes. AADL used to define the mode transitions.

8. Detailed Behavior and Performance Requirements Needs further study. Expression of requirements in terms of PSL, BLESS...

9. Define the Software Requirements Needs further study?

10.System Requirements to Subsystems Allocation. Needs further study?

11.Rationale Through RDAL Rationale elements.

Today: Overview of Analyses of RDAL Models.


STATUS OF WORK


RDAL Tool Environment

Migration to OSATE2 started and nearly completed.

Current Issues: Cyclic resolution of lazy links error when opening RDAL diagrams.

Occurs when the diagram refer to AADL elements using timing properties. Fixed by adding “with AADL_Project” clause in “Timing_Properties” property set.

ComponentInstance.acceptsProperty needed to be implemented. Stack trace overflow with EMF change recorder and getInModes() that returns a notifying list.

Workaround: return an empty list for now. Save of Xtext Resources does not work. Need to migrate the AADL Property View.

Fixed a null pointer exception problem (PropertyAssociationItemProvider.getText()). Instance Editor and changes conflict management.


STATUS OF WORK


RDAL Tool Environment (continued) Settings model management implemented.

Defines allowed types per modeling language for traceability properties.

No other significant evolution.Main efforts spent on GLASSES and Open-PEOPLE Software Platform.

We will be able to spend significant effort RDAL soon. Internship starting in May.

First task is to integrate LUTE (REAL). Update the tool to implement the latest changes in the language.

Definition of textual syntax being studied by Skander. I will take care of

REMH practice 6 and 7. Implement analyses. Complete example. SAE Document.


STATUS OF WORK



OUTLINE

• Status of Work



• Future Work


General Considerations

A requirements specification allows to differentiate a correct from an incorrect system.

Correct: All requirements of the specification are verified by the system. Incorrect: At least one requirement of the specification is not verified.Goal analysis used to quantify quality of systems.

Precondition: The requirements specification is correct itself.

Two categories of analyses: Requirements specification alone:

Ensure that the problem is formulated correctly (consistency, completeness, etc.).

Requirements specification with system architecture specification. Ensure that the system architecture specification actually solves the problem.


ANALYSES OF RDAL SPECIFICATIONS


Analysis of Requirements Specification Alone IEEE Standard 830-1998:

Recommended Practice for Software Requirements Specifications

Define informal properties representing correctness of requirements specifications:

1. Correctness2. Unambiguity3. Completeness4. Consistency5. Stability/Importance Ranking6. Verifiability7. Modifiability8. Traceability

How can these properties be quantified from analysis of RDAL specifications?




Objectives

For every IEEE 830 correctness property try to define a quantity computable automatically from RDAL specifications.

Some analyses are complex (consistency, completeness) and it may not be possible to do this for all properties.

At least implement the simple ones in a first step.




Correctness

IEEE 830: Every requirement is one that the software shall meet. No procedure exists to ensure correctness.

RDAL Analysis: Verify that requirements represent a Stakeholder need.

Check that every Requirement and Goal is eventually linked to a Stakeholder, through decomposition tree.

Verify that requirements have a Rationale. Check that every Requirement, Goal and Assumption is eventually linked to a Rationale.

Metric: TBD




Correctness (continued)




How, WhenWho

What

Why

UncertaintyWhen

Unambiguity

IEEE 830: Every requirement has only one possible interpretation. Ambiguous requirements cannot be verified.

RDAL Analysis: Check that every leaf of RDAL Contractual Elements tree is either:

Attached to an element of a system architecture model and expressed formally (OCL, REAL, PSL, etc.). Or linked to a Verification Activity element.

Metric: Ratio of leaf elements satisfying the rule over the total number of leaf elements? Distinguish between Goal, Requirement and Assumption?




Completeness IEEE 830:

a)The requirements specification includes all significant requirements, whether relating to functionality, performance, design constraints, attributes, or external interfaces.

b)The requirements specification defines responses of the system to all realizable classes of input data in all realizable classes of situations (including valid and invalid input values).

This is the definition in the FAA REMH. All controlled variables must be assigned for all conditions (modes and condition on system variables).




Completeness (continued) RDAL Analysis:

a)From composition coverage of decomposed elements. Identify contractual elements whose composition coverage is not complete (1.0). Metric?



How to measure the impact of RDAL uncertainty? An uncertain requirements specification cannot be complete.


Completeness (continued)b)Assignment of controlled variables (REMH):

For all possible (mode, condition and controlled variable), verify that there is a requirement defining the assignment of the variable.

Modes: externally visible discontinuities in system behavior. Added traceability links for AADL system operation modes from RDAL System Context and Contractual Element. Added a condition expression to Contractual Element.



Traceability of assigned and condition variables (derived from expressions). Easy to check completeness for (mode, controlled variable).

Completeness of conditions? Depends on the language used to express it? Needs further investigation...


Consistency IEEE 830: There exists at least one system that can satisfy the requirements specification.

The specified characteristics of real world do not conflict. In the REMH, controlled variable assignment do not conflict (logically and temporally).

RDAL Analysis: Like for completeness, analysis will depend on the language used to express the requirements. Logically:

Depends on the language used to express it? Needs further investigation...

Real Time: Work of Post et al. (rt-inconsistency: a new property for real-time requirements).

Express the requirements in terms of Duration Calculus Use UPPAAL model checker. Also detect vacuous requirements (duplicated or logically equivalent).




Ranking for Importance and/or Stability IEEE 830:

1. Stability: Expected change.

2. Necessity: Essential: Implies that the software will not be acceptable unless these requirements are provided in an agreed manner.

Conditional: Implies that these are requirements that would enhance the product, but would not make it unacceptable if they are absent.

Optional: Implies a class of functions that may or may not be worthwhile. This gives the supplier the opportunity to propose something that exceeds the SRS.




Ranking for Importance and/or Stability (continued) RDAL Analysis:

1. Stability: Refer to uncertainty analysis of Nolan et al. (Managing Requirements Uncertainty in Engine Control Systems Development). Volatility: “Represents the engineer’s best judgment as to the probability the requirement will change through the course of the project (subjective judgment).” Precedence: “Incorporates multiple variables to indicate heritage in providing solutions that address this attribute for a similar application, environment, and context of use.” Metric: Composition of volatility and precedence? TBD




Ranking for Importance and/or Stability (continued)

2. Necessity: Represented in RDAL using the time criticality property. Metric: Use derived risk index from uncertainty analysis to prioritize requirements.

RI = Volatility * Impact * Precedence * TimeCriticality




Verifiability IEEE 830: There exists some finite cost-effective process with which a person or machine can check that the product meets the requirement.

Preconditions: No ambiguity. Requirements must be quantifiable. If no method can be devised for verifying the requirement, then revise the requirement.



RDAL Analysis: Identify leaf requirements that do not meet one of the following conditions: Expressed formally (through requirements decomposition). A verification activity element is assigned to the requirement. Metric?


Modifiability

IEEE 830: The structure and style of the requirements specification are such that any changes to the requirements can be made easily, completely, and consistently while retaining the structure and style.

REMH: Organize System Functions Into Related Groups (high cohesion/low coupling design principle).

Minimize dependencies between functions by ensuring that the information shared between functions represent stable, high-level concepts from the problem domain that are unlikely to change.

Push volatile dependencies as far down in the function hierarchy as possible.

This creates firewalls that help to prevent changes from rippling throughout the specification.




Modifiability (continued)

RDAL Analysis:

How to measure this from the requirements specification?

Requirements are linked to AADL subprograms, and to controlled variable.

Need the designer to identify which variables are stable concepts of the domain?

Needs more thinking….




Traceability

IEEE 830: The origin of each requirement is clear and it facilitates the referencing of each requirement in future development or enhancement documentation.

RDAL Analysis: Verify that Assumptions and Requirements are actually verified by components of the environment and the systemToBe respectively.

Possible because RDAL formalizes the system boundary.

Value based on the ratio of valued RDAL traceability Points.

Metric? TDB.




Traceability (continued)



Class Property Usage Weight

SystemOverview systemToBe •The system component of the system architecture language representing the system to build at the highest level of abstraction.

SystemContext globalSystem •The system component of the system architecture language representing the details of the system to build in terms of its subcomponents and their interaction for the given context of operation. In AADL, this is an implementation of the system to be.

Variable feature •A feature of components of the language used to model the system overview.

Actor images •Actors from different languages (e.g.: URN actors).

ContractualElement satisfiedBy •And / Or decomposition.•Link to design components.

rationales •The reason why this element exists.

stakeholders •Who wants this element to be honoured.

derivedFrom •Use case actions,

contactInformation • The requirements engineers who created and worked on this element.

evolvedTo •The new element that replaces this one.

droppingReason •The reason why this element wan abandoned.

sources •Documents from which this element comes from.

tracedTo •Generic usage.

AbstractRequirement verifiedBy •An activity that when performed verifies the requirement.

Requirement assumptions •The requirements on the environment that must be met for this requirement to be verifiable.

imageAssumption •The assumption from another requirements specification that corresponds to this requirement.

Assumption requirements •The requirements that rely on this assumption for being verifiable.

imageRequirement •The requirement from another requirements specification that corresponds to this assumption.



OUTLINE

• Status of Work



• Future Work



QAML

Recall Consumption Analysis Toolbox (CAT) SPICES project.

Provides power consumption estimations in MBE.

Sufficient for SPICES, but several weaknesses:Own meta-model (PADL) providing power analysis oriented view of the system. Pros: independent of any system architecture modeling tool. Cons: model synchronization needed between AADL and PADL.

Complex and resource consuming. Eclipse plug-in developer needed to integrate new power consumption models in the tool.

ConsumptionAnalysisToolbox

SW AADL HW AADL

AADL PSM

Power Estimation Services

PADL



QAML To solve these problems, introduce QAML:

Quantitative Analysis Modeling Language

Goal: define a formalism to represent data sheets of hardware components so that they are interpretable by a machine.

Users can define any Quantitative Evaluation Models (QEML) with user friendly editors and store them in libraries. Expressed as:

Mathematical relationships. Lookup tables. Composition models. Calls to external tools.

QEML models must be reusable with specifications of any system architecture modeling language (AADL, MARTE, SysML, SDL,…).



QAML

Once plugged (woven) to a system architecture model, a QEML model (becoming a QAML model ) is interpretable to provide results valued in properties of the system architecture model.

Generalization to arbitrary quantities CAT QuATE, integrated in OPSWP with OSATE and RDAL.

QAML analysis result are used by RDAL requirements to constrain the design. Formal language expressions testing the properties.



QAML

Multi-Paradigm Modeling (MPM) QAML follows a separation of concerns principle for MPM.

Every aspect of a problem should be formalized with Domain Specific Languages to avoid misinterpretation of implicit information. DSLs of independent domains should remain independent of each other for reuse.

Avoid accidental complexity that occurs with general purposes languages. E.g.: using a programming language to represent mathematical expressions. Using UML profiles.



QAML

QAML Architecture



QAML

Tool Support

Supported by the Open-PEOPLE Software Platform (OPSWP). Eclipse IDE

Language specified at Lab-STICC UBS. Editors developed at Loria INRIA Nancy.

Integration with OSATE2 in progress...



OUTLINE

• Status of Work



• Future Work



FUTURE WORK

RDAL Complete migration of tool to OSATE 2. Update the tool to reflect the latest language changes. Define textual syntax. Integrate LUTE. Complete modeling of Isolette Thermostat. Complete the SAE annex document.

QAML Create a Builder to ensure properties having an analysis model are correct as the models change. Implement markers identifying incorrectly bound QAML models. Implement quantity model editor for external tools. Implement uncertainty management.
