SWE 623Duminda Wijesekera1 Requirements, their Consistency and Completeness RSML Formulation of TCAS II Discussed as an example of a precise and formal.

Slides:



Advertisements
Similar presentations
Component Oriented Programming 1 Chapter 2 Theory of Components.
Advertisements

Introducing Formal Methods, Module 1, Version 1.1, Oct., Formal Specification and Analytical Verification L 5.
Giving a formal meaning to “Specialization” In these note we try to give a formal meaning to specifications, implementations, their comparisons. We define.
Software Engineering 1. Software development – the grand view 2. Requirements engineering.
Requirement Analysis and Specification Mr. Manoj Kumar Kar.
Background information Formal verification methods based on theorem proving techniques and model­checking –to prove the absence of errors (in the formal.
Formal Methods in Software Engineering Credit Hours: 3+0 By: Qaisar Javaid Assistant Professor Formal Methods in Software Engineering1.
© Betty HC Cheng. This presentation is available free for non-commercial use with attribution under a creative commons license. Acknowledge: S.
University of Toronto Department of Computer Science © Steve Easterbrook. This presentation is available free for non-commercial use with attribution.
CSC 402, Fall Requirements Analysis for Special Properties Systems Engineering (def?) –why? increasing complexity –ICBM’s (then TMI, Therac, Challenger...)
School of Computer ScienceG53FSP Formal Specification1 Dr. Rong Qu Introduction to Formal Specification
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 1 Systems engineering 1.
Equivalence Class Testing
What is it? A mobile robotics system controls a manned or partially manned vehicle-car, submarine, space vehicle | Website for Students.
[ §6 : 1 ] 6. Basic Methods II Overview 6.1 Models 6.2 Taxonomy 6.3 Finite State Model 6.4 State Transition Model 6.5 Dataflow Model 6.6 User Manual.
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
Reduction and Slicing of Hierarchical State Machines Mats Heimdahl et al. University of Minnesota Presented by Tom McMullen For CISC836 1.
Formal Methods 1. Software Engineering and Formal Methods  Every software engineering methodology is based on a recommended development process  proceeding.
Software Requirements Specification (SRS) Complete description of external behavior of software system Complete description of external behavior.
1 Chapter 2 Socio-technical Systems (Computer-based System Engineering)
REAL-TIME SOFTWARE SYSTEMS DEVELOPMENT Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Topics Covered: Software requirement specification(SRS) Software requirement specification(SRS) Authors of SRS Authors of SRS Need of SRS Need of SRS.
Negotiation and Specification Process
Mathematical Modeling and Formal Specification Languages CIS 376 Bruce R. Maxim UM-Dearborn.
CS4730 Real-Time Systems and Modeling Fall 2010 José M. Garrido Department of Computer Science & Information Systems Kennesaw State University.
Introduction to Formal Methods Based on Jeannette M. Wing. A Specifier's Introduction to Formal Methods. IEEE Computer, 23(9):8-24, September,
SOFTWARE DESIGN.
Overview of Formal Methods. Topics Introduction and terminology FM and Software Engineering Applications of FM Propositional and Predicate Logic Program.
WXGE6103 Software Engineering Process and Practice Formal Specification.
REAL-TIME SOFTWARE SYSTEMS DEVELOPMENT Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
Requirements Specification. Welcome to Software Engineering: “Requirements Specification” “Requirements Specification”  Verb?  Noun?  “Specification”
Communicating Real-Time State Machines (CRSM) State machines that communicate synchronously Unique unidirectional channels are used for the communication.
1 Introduction to Software Testing. Reading Assignment P. Ammann and J. Offutt “Introduction to Software Testing” ◦ Chapter 1 2.
CMSC 345 Fall 2000 Requirements Overview. Work with customers to elicit requirements by asking questions, demonstrating similar systems, developing prototypes,
1 Quality Attributes of Requirements Documents Lecture # 25.
Formal Methods.
Author: Alex Groce, Daniel Kroening, and Flavio Lerda Computer Science Department, Carnegie Mellon University Pittsburgh, PA Source: R. Alur and.
CS4730 Real-Time Systems and Modeling Fall 2010 José M. Garrido Department of Computer Science & Information Systems Kennesaw State University.
CSCI1600: Embedded and Real Time Software Lecture 7: Modeling II: Discrete Systems Steven Reiss, Fall 2015.
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
Formal Specification: a Roadmap Axel van Lamsweerde published on ICSE (International Conference on Software Engineering) Jing Ai 10/28/2003.
Finite State Machines (FSM) OR Finite State Automation (FSA) - are models of the behaviors of a system or a complex object, with a limited number of defined.
Chapter 19: Building Systems with Assurance Dr. Wayne Summers Department of Computer Science Columbus State University
Formal Verification. Background Information Formal verification methods based on theorem proving techniques and model­checking –To prove the absence of.
Software Engineering Lecture 8: Quality Assurance.
Requirement Analysis SOFTWARE ENGINEERING. What are Requirements? Expression of desired behavior Deals with objects or entities, the states they can be.
1 Specification A broad term that means definition Used at different stages of software development for different purposes Generally, a statement of agreement.
CS3320-Chap21 Office Hours TR 1:00-2:15 PM W 2:30-3:30 PM By appointment.
1 CEN 4020 Software Engineering PPT4: Requirement analysis.
SENG521 (Fall SENG 521 Software Reliability & Testing Fault Tolerant Software Systems: Techniques (Part 4a) Department of Electrical.
1 Software Requirements Descriptions and specifications of a system.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 10Slide 1 Chapter 5:Architectural Design l Establishing the overall structure of a software.
 System Requirement Specification and System Planning.
I&C Lab Seminar Procedure for the Software Requirements Specification for Safety Critical Systems Seo Ryong Koo Korea Advanced Institute Science.
From requirements to specification Specification is a refinement of requirements Can be included together as Software Requirements Specifications (SRS)
The Software Lifecycle Stuart Faulk. Definition Software Life Cycle: evolution of a software development effort from concept to retirement Life Cycle.
Formal Specification.
Chapter (12) – Old Version
An Overview of Requirements Engineering Tools and Methodologies*
Lec 6: Practical Database Design Methodology and Use of UML Diagrams
ADVANTAGES OF SIMULATION
Graph Coverage for Specifications CS 4501 / 6501 Software Testing
Chapter 19: Building Systems with Assurance
Information Analysis, Organization, and Presentation
Subject Name: SOFTWARE ENGINEERING Subject Code:10IS51
Practical Database Design and Tuning Objectives
Presented by KARRI GOVINDA RAO ,
Presentation transcript:

SWE 623Duminda Wijesekera1 Requirements, their Consistency and Completeness RSML Formulation of TCAS II Discussed as an example of a precise and formal capturing of a real-world software engineering specifications SWE 623 (Thanks to Prof. Mats P. E. Heimdahl for references)

SWE 623Duminda Wijesekera2 TCAS II Traffic alert and collision avoidance system. Airborne device functioning independent of ground based traffic control. All commercial and larger commuter and business aircrafts (with seats) must have this on aboard. TCAS I provided proximity warning (traffic advisories) and assist the pilot in visualizing intruder aircrafts. TCAS II recommends escape maneuvers (resolution advisories) in a vertical direction to avoid collusions.

SWE 623Duminda Wijesekera3 Brief History Collision avoidance systems are 25 years old. Minimal Operational Performance Standards Document (MOPS-1983) was written in a combination of English and pseudocode. – –Revised extensively six times. –Had difficulty in certification, so Government started rewriting the document and UCI started an experimental formal specification and safety analysis.

SWE 623Duminda Wijesekera4 System View System = Collection of components working together. Process control= input output behavior in the presence of disturbances. –Disturbances due to chemical, aerodynamic, thermal or physical laws. Operating Constraints –Range constraints for input/output variables. –Operating conditions. –Limits design choices –May be results of quality control, resource bounds, physical limitations, process characteristics etc.

SWE 623Duminda Wijesekera5 TCAS Examples Maintain minimum separation between aircrafts Constraints –No interfering with ground based air traffic control (ATC) functions. –Acceptably low level of unwanted alarms. –Minimizing deviation from ATC assigned tracks.

SWE 623Duminda Wijesekera6 Difference between Goals and Requirements Goal= Avoid near misses = (I.e. aircrafts violating minimum separation distance) A legitimate goal, but cannot determine if it is achievable in a given operating environment. Therefore cannot be a requirement of the system design. The system can strive to minimize near misses.

SWE 623Duminda Wijesekera7 Basic Process Control Model Control variables ( V c ) –Process monitored through these Manipulated variables ( V m ) –Controlled through these Sensors ( F s ) –Monitor actual behavior of process Actuators ( F a ) –Devices designed to manipulate process behavior Controller ( F c ) –Device used to implement control function Process F p Controller Fc ActuatorSensors Disturbances Controlled Variables Manipulated Variables Command Signal

SWE 623Duminda Wijesekera8 RSML Approach Black-box behavior specified using state machine model –Outputs of the controller specified with respect to state change in the model as information received about current state via controlled variables V c. –Control function F c specified using a model of the state of all other aircraft within host’s space. Desired process control behavior Black-box specification of controller behavior Implementation Specifying Controller Design Based on functional decomposition

SWE 623Duminda Wijesekera9 Basic Definitions Input Variables: I s,, Output Variables: O s Controlled Vars: V c ManipulatedVars: V m Disturbances: D Process Function: F p : V m x I s x D x t  O s x V c Sensor Function: F s : V c x t  I s Actuator Function: F A : O s x t  V m Control Function: F c : I s x V c x t  O s

SWE 623Duminda Wijesekera10 F c : Controller Function Modeled as a state machine –Iteratively refined during requirements specification. An abstraction of the current understanding of real world control loop. Most control functions are non-linear equations. Modeling errors represent mismatches between real world view and state machine view.

SWE 623Duminda Wijesekera11 Design Criteria Need black-box behavior, not internal design information. Minimality and simplicity. Formal, concise, coherent notation. Readability, reviewability Best use of graphics, tables and symbolic. Ability to formally analyze safety, completeness and consistency.

SWE 623Duminda Wijesekera12 Properties of Statecharts And/Or hierarchies. Conditions (conditional connectives in RSML) –I.e. guard determines which Or state to transition as a consequence of an even triggering. Arrays of state machines. –Example: array of other aircraft (statechart) Additions: –Directed communication (unidirectional explicit FIFO queue) between state charts –Broadcast mechanisms with some limitations

SWE 623Duminda Wijesekera13 Interface Definitions and Communication Mechanisms State-charts modeled components, hence had to write interface definitions between models. Communication –Sending machine execute SEND(msg, destination) - I.e. receivers name –Triggers RECEIVE event in destination machine. –No synchrony hypothesis in communication

SWE 623Duminda Wijesekera14 State Machine Descriptions Input variables, output variables and graphical state machines Attributes of variable include –Location (machine name), –Source/destination (external component, eg Altimeter) –Type (eg integer), Expected Range 9eg 1 to 1000, –Granularity (10s), Units meters), Load (frequency of change) –Exception handling (what to do for out of range) –Traceability information (MOPS document reference)

SWE 623Duminda Wijesekera15 Format of RSML State Machines

SWE 623Duminda Wijesekera16 Example RSML State-chart

SWE 623Duminda Wijesekera17

SWE 623Duminda Wijesekera18

SWE 623Duminda Wijesekera19 Encoding States

SWE 623Duminda Wijesekera20 Example State Definition

SWE 623Duminda Wijesekera21 Transitions TRANSITION: North East North East Had a notation for locations such as Location: Other_aircraft  Tracked > Intruder_status_52

SWE 623Duminda Wijesekera22 Notation for Guarding Conditions Conditions written in disjunctive normal form and tabulated

SWE 623Duminda Wijesekera23 Example: Table vs. Logic

SWE 623Duminda Wijesekera24 Example: Table vs. Logic

SWE 623Duminda Wijesekera25 Analysis Completeness: Robustness –Responsiveness to every possible input and input sequence. –Logical OR of transition condition is a tautology. –Every state having a timeout transition behavior. Consistency –Free of conflicting requirements. –Free of undesired non-determinism.

SWE 623Duminda Wijesekera26 Completeness: D-completeness D-Completeness: –The system must respond in real time to any input and input sequence. Involves following steps –At atomic states, all behaviors are defined (I.e. all external input changes are accounted for) and There are no conflicting requirements (source of non- determinism)

SWE 623Duminda Wijesekera27 Completeness: OR States Cont.. –At OR (Union) states, Transition conditions are disjoint. –Guards of transitions triggered by the same event are mutually exclusive. Entire domain is covered (OR of conditions is True) –OR of all guards of conditions triggered by same event is TRUE. (I.e. one and ONLY ONE satisfiable transition out of every state) AND/OR tabular representation of guards is very helpful for analysis. In general, this problem is NP complete (3-sat is NP hard), but Used BDD’s to manipulate conditions.

SWE 623Duminda Wijesekera28 Completeness: OR - Continued –At OR (Union) states: Problems Encountered, BDD’s are only good for symbolic manipulations, hence a lot of potential errors in the specifications are reported. Conversely, theorem proving approach will cover some of these problems, but is VERY expensive to do by itself. Would like a hybrid of BDD’s talking to theorem provers, but such things do not exist yet! See Heimdahl, Czerney article in High Assurance Systems Engineering Conference 1999 on this point.

SWE 623Duminda Wijesekera29 Completeness: AND States Two transitions in parallel AND state triggers by same event If truth value of the guard of one component affects the truth value of the other guards, then non-determinism may result. So RSML check for such dependencies. Costly to check, but rare in TCAS specifications.

SWE 623Duminda Wijesekera30 Completeness: Serial Composition Transition triggering one event may trigger another event. In order to achieve this effect, the the domain of the second must be included in the range of the first. Thirdly, if an event is generated as a consequence of some action, and it is never caught any where else, then the specification is incomplete.

SWE 623Duminda Wijesekera31 Consequences RSML specs are now the official specs for TCAS II. There are some tools to check d-completeness. Many incomplete specifications were detected during analysis phase. It is difficult to provide guidance in eliminating incompleteness's and inconsistencies. Sensitivity of the TCAS system: How close an intruder is allowed to get? RSML specifications can be parametrized on sensitivity levels. – Sensitivity analysis.