Home > Products > Specifications                                Features Specifications Pricing Demo Support
  Intent Specifications
SpecTRM assists in building intent specifications. Developed by Professor Nancy Leveson, an intent specification is, itself, a tool for safety-driven system design. The intent specification is a prescribed format for writing system specifications. How information is presented makes a great deal of difference in how successful engineers are at problem-solving. Intent specifications support the cognitive efforts required for system requirements specification and design.

Intent specifications are very readable and reviewable documents. Their format can bridge between disciplines, allowing engineering specialists and domain experts to share information more effectively. The same format supports the cognitive efforts required for human problem-solving. Traceability is an integral part of intent specifications, ensuring the the rationale for decisions is available at every step. Intent specifications support upstream safety efforts by emphasizing requirements, where the majority of decisions impacting safety are made. By integrating safety information into the system specification, safety information is presented in the decision-making environment; this avoids the problem of safety work being done "out of sight, out of mind".

Intent specifications are hierarchical abstractions based on why (design rationale) as well as what and how. Traditionally, specifications are levelized. Every level of a specification describes what the level below does. Each level, in turn, also describes how the level above is accomplished. This refinement abstraction continues down through the specification until very specific design details are fleshed out. These specifications leave out rationale, however. One of the most important questions users of a specification have is why something was done the way it was. Often, systems cannot evolve smoothly because engineers are afraid to make any changes. They cannot remember why something was done and are afraid that changing it may have a disastrous impact on the system. The intent specification preserves information about why decisions were made, easing system review and evolution.

At each stage, design decisions are mapped back to the requirements and constraints they are derived to satisfy. Earlier stages of the process are mapped to later stages. The organization of the specification results in a record of the progression of design rationale from high-level requirements to component requirements and designs.

Each level of the intent specification supports a different type of reasoning about the system. Mapping between levels provide relational information necessary to reason across hierarchical levels.

We can demonstrate part of an intent specification by excerpting from the intent specification for TCAS. TCAS is a collision avoidance system used on aircraft. If aircraft violate a minimum separation, the pilot is advised to execute an escape maneuver that will move the aircraft to safe separation.

Level 1: System Purpose

bulletIntroduction
bulletHistorical Perspective
bulletEnvironment Description
bulletEnvironment Assumptions
bulletAltitude information is available from intruders with a minimum precision of 100 feet.
bulletAll aircraft have legal identification numbers.
bulletEnvironment Constraints
bulletThe behavior or interaction of non-TCAS equipment with TCAS must not degrade the performance of the TCAS equipment.
bulletSystem Functional Goals
bulletProvide affordable and compatible collision avoidance system options for a broad spectrum of National Airspace System users.
bulletHigh-Level Requirements
[1.2] TCAS shall provide collision avoidance protection for any two aircraft closing horizontally at any rate up to 1200 knots and vertically up to 10,000 feet per minute.
Assumption: Commercial aircraft can operate up to 600 knots and 5000 fpm during vertical climb or controlled descent (and therefore the planes can close horizontally up to 1200 knots and vertically up to 10,000 fpm).
bulletDesign and Safety Constraints
[SC5] The system must not disrupt the pilot and ATC operations during critical phases of flight nor disrupt aircraft operation.
[SC5.1] The pilot of a TCAS-equipped aircraft must have the option to switch to the Traffic-Advisory-Only mode where TAs are displayed but display of resolution advisories is prohibited.
Assumption: This feature will be used during final approach to parallel runways when two aircraft are projected to come close to each other and TCAS would call for an evasive maneuver.
SC-7 TCAS must not create near misses (result in a hazardous level of vertical separation) that would not have occurred had the aircraft not carried TCAS.
SC-7.1 Crossing maneuvers must be avoided if possible.
v 2.36, 2.38, 2.48, 2.49.2

SC-7.2 The reversal of a displayed advisory must be extremely rare.

v 2.51, 2.56.3, 2.65.3, 2.66

SC-7.3 TCAS must not reverse an advisory if the pilot will have insufficient time to respond to the RA before the closest point of approach (four seconds or less) or if own and intruder aircraft are separated by less than 200 feet vertically when 10 seconds or less remain to closest point of approach.

v 2.52
bulletSystem Limitations
L.5 TCAS provides no protection against aircraft with nonoperational or non-Mode C transponders.
bulletOperator Requirements
OP.4 After the threat is resolved the pilot shall return promptly and smoothly to his/her previously assigned flight path.
bulletHuman-Interface Requirements
bulletHazard and other System Analyses
bullet 

To this point, hazards have been a central focus of the description of system safety. The process has supported the goals of identifying and eliminating hazards. It has been emphasized that hazards are not potential failures, however, but states in the system that, combined with the environment, lead to accidents. The hazard list for TCAS is provided as an example below.

H1: Near midair collision (NMAC): An encounter for which, at the closest point of approach, the vertical separation is less than 100 feet and the horizontal separation is less that 500 feet.

H2: TCAS causes controlled maneuver into ground, such as a descend command near terrain.

H3: TCAS causes pilot to lose control of the aircraft.

TCAS interferes with other safety-related systems, such as interfering with ground proximity warnings.

Causes of these hazards can be uncovered by techniques such as qualitative fault tree analysis (FTA). An excerpt from the TCAS FTA is shown below. The fault tree is not presented in its traditional box and line format because it was too hard to fit the text into boxes, but the tree structure should still be apparent.

In an intent specification, links are made from the leaf nodes in the fault tree to constraints in the design that control the risk those faults present. For example, the "Uneven terrain" box in the fault tree above links down to an entry in level two of the intent specification. That entry is reproduced; notice that traceability is maintained in both directions because the entry links back up to the fault tree. This traceability information allows changes to be easily evaluated for their impact on safety.

2.19 When below 1700 feet AGL, the CAS logic uses the difference between its own aircraft pressure altitude and radar altitude to determine the approximate elevation of the ground above sea level (see the figure below). It then subtracts the latter value from the pressure altitude value received from the target to determine the approximate altitude of the target above the ground (barometric altitude - radar altitude + 180 feet). If this altitude is less than 180 feet, TCAS considers the target to be on the ground (^ 1.SC4.9). Traffic and resolution advisories are inhibited for any intruder whose tracked altitude is below this estimate. Hysteresis is provided to reduce vacillations in the display of traffic advisories that might result from hilly terrain (^ FTA-320). All RAs are inhibited when own TCAS is within 500 feet of the ground.

Below is another example of level two of an intent specification. The design is influenced by the safety constraints from level one and are linked back to provide a rationale for the design.

SENSE REVERSALS vReversal-Provides-More-Separationm-301

2.51 In most encounter situations, the resolution advisory sense will be maintained for the duration of an encounter with a threat aircraft (^ SC-7.2). However, under certain circumstances, it may be necessary for that sense to be reversed. For example, a conflict between two TCAS-equipped aircraft will, with very high probability, result in selection of complementary advisory senses between the two aircraft because of the coordination protocol between the two aircraft. However, if coordination communications between the two aircraft are disrupted at a critical time of sense selection, both aircraft may choose their advisories independently (^FTA-1300). This could possibly result in selection of incompatible senses (^FTA-395).
2.51.1 [Information about how incompatibilities are handled.]

 

Through levels one and two, conceptual design, high-level goals, and safety-related constraints are translated down into system design. Level three of an intent specification continues from levels one and two, including a black box model of the system. The model is based on automata theory, so it is formal enough that the model can be analyzed and executed. However, the language used for the model is understandable enough that it can be used as the specification. It is readable and reviewable by domain experts, and it can be used by software engineers as a specification.

An example from level three of the intent specification for TCAS follows. Notice that it links back up to level two to preserve the intent behind the choices made in the black box model. It also links down to level four where that level is influenced by the model. This particular example is a model of the INTRUDER.STATUS state element. TCAS considers any other aircraft to be an intruder. Some may be harmless, and some may require advisories. This state classifies an intruder. This state element can be in the state Other-Traffic, Proximate-Traffic, Potential-Threat, or Threat.

The table in the model specification describes the transition from Threat to Other-Traffic. The transition is described by an AND/OR table. If the table is true, then the transition takes place. If the table is not true, then the transition does not take place. The table is an OR of the columns. So if any one column is true, the whole table is true. The rows are AND, conditions, so a column is true if every row in that column is true. The expressions in the first column are all either true or false. They are compared to other cells in the table. A true first column expressions matches against a "T" or an "*"; a false first column matches against "F" or an "*". The "*" represents "don't care."

So, to read the table below, threat will transition to Other-Traffic if

bulletAlt-Reporting is in the state Lost and Bearing-Valid is false,
bulletor Alt-Reporting is Lost and Range-Valid is false,
bulletor Alt-Reporting is Lost and the bearing and range are valid, but neither the conditions are not met for the intruder to be proximate traffic or a potential threat
bulletor the other aircraft is on the ground.

With just a few moments, most people are able to pick up how to read these tables. Domain experts without engineering experience or mathematical training can review the specification and point out problems. Despite the ease of use and readability, these kinds of descriptions of systems can be simulated and analyzed as well.

At the time this web page was written, models had been or were being built for:

bulletTCAS II
bulletNASA industrial robot
bulletFMS (Flight Management System) for Draper autonomous helicopter
bulletFMS for MD-11
bulletFMS for experimental NASA aircraft
bulletHETE satellite attitude control
bulletAdvanced concepts in ATC:
CTAS PFAST (final approach spacing tool)
MTCD (Eurocontrol Conflict Detection Tool)
STARS (Raytheon): only small parts so far

 

Home Products Services Publications White Papers About Us

Copyright 2003 Safeware Engineering Corporation. All rights reserved