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

Introduction

Historical Perspective

Environment Description

Environment Assumptions

Altitude information is available from intruders with a
minimum precision of 100 feet.

All aircraft have legal identification numbers.

Environment Constraints

The behavior or interaction of non-TCAS equipment with TCAS
must not degrade the performance of the TCAS equipment.

System Functional Goals

Provide affordable and compatible collision avoidance system
options for a broad spectrum of National Airspace System users.

High-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).

Design 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

System Limitations

L.5 TCAS provides no protection against aircraft with
nonoperational or non-Mode C transponders.

Operator Requirements

OP.4 After the threat is resolved the pilot shall return promptly
and smoothly to his/her previously assigned flight path.

Human-Interface Requirements

Hazard and other System Analyses

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

Alt-Reporting is in the state Lost and Bearing-Valid is false,

or Alt-Reporting is Lost and Range-Valid is false,

or 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

or 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: