Update on AADL Requirements Annex

Size: px

Start display at page:

Download "Update on AADL Requirements Annex"

Norma Baker
5 years ago
Views:

1 Open-PEOPLE Open Power and Energy Optimization PLatform and Estimator Update on AADL Requirements Annex Dominique BLOUIN* *Lab-STICC, Université de Bretagne Sud, Lorient, FRANCE AADL Standards Meeting, October 18-21, 2011

2 OUTLINE 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 AADL Standards Meeting, October

Modeling of a common requirements specification with language / method of choice (afternoon).

3 RDAL at ModRE 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 of choice (afternoon). Did not work out well since most participants were not prepared. Main RE Conference Participation Opportunity to meet the RE community. A lot of interesting work. Update on Requirements Annex AADL Standards Meeting, October

4 Start from set of Best Practices in RE for Real-Time Embedded Systems with Isolette Thermostat example. 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. Models becomes central artifacts. Documentation ideally generated from the models. Keep the language generic enough to be usable with other approaches. Update on Requirements Annex AADL Standards Meeting, October

Other ideas from: Requirements Engineering (van

User Requirements Notation (URN) (ITU-T, Recommendation

Requirements change uncertainty modeling and analysis.

Systems Development, Nolan et al., at RE 2011.

time criticality to develop requirements.

5 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 particular. Requirements change uncertainty modeling and analysis. from Managing Requirements Uncertainty in Engine Control Systems Development, Nolan et al., at RE Take into account volatility, impact, precedence and time criticality to develop requirements. Study on projects conducted at Rolls Royce. Update on Requirements Annex AADL Standards Meeting, October

6 REMH s best practices overview: 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. Update on Requirements Annex AADL Standards Meeting, October

7 Best Practice Isolette Thermostat Example 1. Develop the System Overview Develop System Overview Early. 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. Update on Requirements Annex AADL Standards Meeting, October

8 Use AADL as context diagram. ISOLATE THERMOSTAT EXAMPLE RDAL Elements Update on Requirements Annex AADL Standards Meeting, October

2. Identify the System Boundary 1. Identify the System Boundary Early. 2. Choose Environmental Variables. 1. Variables that would exists even is the systemto-be would not. 3.

9 2. Identify the System Boundary 1. Identify the System Boundary Early. 2. Choose Environmental Variables. 1. Variables that would exists even is the systemto-be would not. 3. Choose Controlled Variables. 1. Data types identified ifi d from features on systemto-be with out or provides directions. 4. Choose Monitored Variables. 1. Data types identified from features on system- to-be with in or requires directions. 5. Ensure Environmental Variables are Sufficiently Abstract. 6. Avoid Presentation Details in Environmental Variables. 7. Define All Physical Interfaces. 1. Use AADL Type Declarations Update on Requirements Annex AADL Standards Meeting, October

Include How the System is Used in its Operating

Employ the Use Case Goal as its Title. 4.

10 Use UML Use Case Diagrams. ISOLATE THERMOSTAT EXAMPLE 3. Develop the Operational Concepts 1. Document Sunny Day System Behavior. 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. Update on Requirements Annex AADL Standards Meeting, October

11 Use UML Activity / Sequence Diagrams for Scenarios. ISOLATE THERMOSTAT EXAMPLE 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). 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). Update on Requirements Annex AADL Standards Meeting, October

12 Or use UCM (Use Case Maps ) diagrams (sublanguage g of URN ITU standard). Use Case Pre/post conditions Primary Actors Exception/ Use Cases Stubs Steps Update on Requirements Annex AADL Standards Meeting, October

13 4. Identify the Environmental Critical when integrating systems developed by Assumptions different teams. 1. Define the Type, Range, Precision, and Units 2. Provide Rationale for the Assumptions. 3. Organize Assumptions Constraining a Single Entity 4. Organize Assumptions Constraining Several Entities 5. Define a Status Attribute for Each Monitored Variable (valid/invalid + possibly others). Integration scenario: Each team uses a copy of the AADL system overview model. Each team provides AADL component implementation e + associated requirements specification (including formal assumptions). Assumptions for every requirements specifications are verified for the complete AADL model at model integration time. Update on Requirements Annex AADL Standards Meeting, October

14 Assumption Decomposition Formal Assumption Declare Status Properties Rationale Update on Requirements Annex AADL Standards Meeting, October

15 5. 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. 3. Minimize i i Dependencies Between Functions (low coupling). 1. Flows represent stable high level concept from the domain (less subject to change). 2. Volatile dependencies pushed down into the function hierarchy. 4. Define Internal Variables. 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 Requirements. Start with functions from use cases. Organize functions related to operator interface together (likely to change together, cohesive). Update on Requirements Annex AADL Standards Meeting, October

16 Requirements groups represent system functions. Nested functions (sub-functions) as requirement decomposition. Verify this requirements organization. Update on Requirements Annex AADL Standards Meeting, October

17 Trace Use Case Steps Update on Requirements Annex AADL Standards Meeting, October

18 Use AADL to represent data flow diagrams. AADL flows are relevant. How should functions and their hierarchy be modeled? Nested Functions Update on Requirements Annex AADL Standards Meeting, October

19 6. Revise the Architecture to Meet Implementation ti Constraints t 1. Modify the Architecture to Meet Implementation Constraints. 2. Keep Final System Architecture Close to Ideal Functional Architecture. 1. Ideal functional architecture (domain) is less subject to change. 3. Revise the System Overview 4. Revise the Operational Concepts 5. Develop Exception Use Cases. 6. Link Exception Cases to Use Cases 7. Revise the System Boundary (new environment variables). 8. Document Changes to Environmental Assumptions. 9. Revise Dependency Diagrams. 10. Revise High Level Requirements. Typical constraints: safety, performances, integration with legacy systems, etc Compare Functional Hazard Assessment with obstacles analysis in van Lamsweerde. Introduced safety requirements are flagged as derived. Update on Requirements Annex AADL Standards Meeting, October

20 7. Identify System Modes Modes introduced to handle externally 1. Identify Major System Modes. visible discontinuities in system behavior. 2. Define How the System Transitions Between Modes. 3. Introduce Modes Only for Externally Visible Discontinuities iti Simplify requirements specifications by 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? Update on Requirements Annex AADL Standards Meeting, October

21 8. Develop the Detailed Behavior and Performance Requirements 1. Specify the Behavior of Each Controlled Variable. 2. Specify the Requirement as a Condition and an Assigned Value. 3. Ensure that the Detailed Requirements are Complete. 4. Ensure that Detailed Requirements are Consistent. 5. Ensure that the Detailed Requirements are not Duplicated. 6. Organize the Requirements. 7. Define Acceptable Latency for Each Controlled Variable. 8. Define Acceptable Tolerance for Each Controlled Variable. 9. Do not Define Latency and Tolerance for Internal Variables. The detailed behavior defines relationships between controlled and monitored variables that must be imposed by the system. If condition, assignment and mode can be identified from requirement s expression, we can verify that every controlled variable is assigned, for every mode (using the unspecified status value when not relevant), and that assignments are consistent and not duplicated. Use AADL flows to define latencies. Trace latency and tolerance specification by a requirement and set rationale. Update on Requirements Annex AADL Standards Meeting, October

9. Define the Software Requirements Derive software requirements from 1. Specify the Input Variables. system requirements. 2. Specify the Accuracy of Each Input Variable. 3.

Specify the function that defines how the status variable is set. 6. Flag Design Decisions as Derived Requirements. 1. The requirements specifying how the status s is set is a derived ed requirement.

22 9. Define the Software Requirements Derive software requirements from 1. Specify the Input Variables. system requirements. 2. Specify the Accuracy of Each Input Variable. 3. Specify the Latency of Each Input Variable. 4. Specify IN Relationships for Each Monitored Variable. 5. Specify the Status of Each Monitored Variable. 1. Specify the function that defines how the status variable is set. 6. Flag Design Decisions as Derived Requirements. 1. The requirements specifying how the status s is set is a derived ed requirement. TODO: derived from which requirement?? Two different specs because the system variables do not exactly match the software variables (syst. Var. translated into software inputs/outputs. Variant of 4 variables model. Update on Requirements Annex AADL Standards Meeting, October

23 10. Allocate System Requirements to Subsystems 1. Identify Subsystem Functions. 2. Duplicate Overlapping System to Subsystem Functions. 3. Develop a System Overview for Each Subsystem 4. Identify the Subsystem Monitored and Controlled Variables. 5. Create New Monitored and Controlled Variables. 6. Specify the Subsystem Operational Concepts. 7. Identify Subsystem Environmental Assumptions Shared with Parent System 8. Identify Environmental Assumptions of the New Monitored and Controlled Variables. 9. Complete the Subsystem Requirements Specification. Systems decomposed into subsystems that can be developed independently. How are overlapping system to subsystem functions linked? Duplicate or just trace requirements located in a different specification? Identify variables that are shared and must be consistent with those of the parent system. They are the subsystem interface for integration. Update on Requirements Annex AADL Standards Meeting, October

24 11. Provide Rationale 1. Provide Rationale to Explain why a Requirement Exists. 2. Avoid Specifying Requirements in the Rationale. ISOLATE THERMOSTAT EXAMPLE 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. 7. 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. Update on Requirements Annex AADL Standards Meeting, October

25 Requirements analyses that can be performed: ISOLATE THERMOSTAT EXAMPLE 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 assignments. Formal requirements verification by architecture model. Formal assumptions verification (especially at system architecture models integration). 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. Same as latency. Update on Requirements Annex AADL Standards Meeting, October

26 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 g evolutions. 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 AADL Standards Meeting, June

27 Language g FUTURE WORK Finalize Isolette Thermostat Example modeling and documentation. Use GCPA Pump as second example? Define a textual concrete syntax. ReqIF: New RMF (Requirements Modeling Framework) project in Eclipse lead by Itemis. See how we could contribute. Tool Finish REAL integration. Implement language g evolutions discovered with examples. Rebuild diagram with Obeo Designer? Migrate to OSATE V2. Update on Requirements Annex AADL Standards Meeting, October

28 NOTES Update on Requirements Annex AADL Standards Meeting, October

AADL Requirements Annex Review

AADL Requirements Annex Review Dominique Blouin Lab-STICC Université de Bretagne-Occidentale Université de Bretagne-Sud Bretagne, France 1 AADL Standards Meeting, April 23 th, 2013 Agenda Comments from Annex Document Review Motivations