Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "SWE 623Duminda Wijesekera1 Requirements, their Consistency and Completeness RSML Formulation of TCAS II Discussed as an example of a precise and formal."— Presentation transcript:

1 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)

2 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 10-30 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.

3 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.

4 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.

5 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.

6 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.

7 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

8 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

9 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

10 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.

11 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.

12 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

13 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

14 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)

15 SWE 623Duminda Wijesekera15 Format of RSML State Machines

16 SWE 623Duminda Wijesekera16 Example RSML State-chart

17 SWE 623Duminda Wijesekera17

18 SWE 623Duminda Wijesekera18

19 SWE 623Duminda Wijesekera19 Encoding States

20 SWE 623Duminda Wijesekera20 Example State Definition

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

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

23 SWE 623Duminda Wijesekera23 Example: Table vs. Logic

24 SWE 623Duminda Wijesekera24 Example: Table vs. Logic

25 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.

26 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)

27 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.

28 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.

29 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.

30 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.

31 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.


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

Similar presentations


Ads by Google