|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
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.
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
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:
Copyright © 2003 Safeware Engineering Corporation. All rights reserved