The Different Levels of Intent Specifications:
Analysis and Guidelines on Tracing
by
William J. Meldndez Diaz
Submitted to the Department of Electrical Engineering and Computer Science
in Partial Fulfillment of the Requirements for the Degree of
Master of Engineering in Electrical Engineering and Computer Science
at the Massachusetts Institute of Technology
May 23, 2001 N
iy7-
0
Copyright 2001 William J. Meldndez Diaz. All rights reserved.
The author hereby grants to M.I.T. permission to reproduce and
distribute publicly paper and electronic copies of this thesis
and to grant others the right to do so.
Author
-
,Aiepartment of4l66tric4afEgIneering and Computer Science
May 23, 2001
Certified by.
Professor Nancy Leveson
Thesis Supervisor
Accepted by
Arthur C. Smith
Chairman, Department Committee on Graduate Theses
OF TECHNOLOGY
.PMKER
JUL11 2001
LIBRARIES
The Different Levels of Intent Specifications:
Analysis and Guidelines on Tracing
by
William J. Mel6ndez Diaz
Submitted to the Department of Electrical Engineering and Computer Science
in Partial Fulfillment of the Requirements for the Degree of
Master of Engineering in Electrical Engineering and Computer Science
at the Massachusetts Institute of Technology
May 23, 2001
Abstract
The increase in the use of computers to control complex systems in which a failure can result in the
loss of life and property has led to new safety issues, particularly when control processes are the
joint responsibility of humans and machines. Intent specifications provide a clear, step-by-step
process to developing systems allowing safety and human factors issues to be integrated into the
design from the early stages of development. Additionally, the levels of an intent specification are
tied to each other through tracing, which links design and implementation decisions to their
underlying reasons and vice versa. An intent specification for the minimum safe altitude warning
(MSAW) function of a new air traffic control system was successfully created, and it is compared to
the function's existing specification documents. Furthermore, described is a step-by-step guide to
tracing between the levels of intent specifications as well as guidance on distinguishing between what
type of design and implementation information goes into each particular level.
Thesis Supervisor: Nancy G. Leveson
Title: MIT Professor of Aeronautics and Astronautics
3
4
Table of Contents
INTRODUCTION
7
RELATED WORK
11
BACKGROUND
13
TEST CASES
19
STANDARD TERMINAL AUTOMATION REPLACEMENT SYSTEM (STARS)
MATTERHORN BOBSLED RIDE
20
ANALYSIS
23
CURRENT
STARS/MSAW DOCUMENTATION
DISTINGUISHING THE LEVELS OF INTENT SPECIFICATIONS
23
TRACING
27
CONCLUSION
39
FUTURE WORK
41
APPENDIX A - MSAW SOFTWARE DESCRIPTION
43
APPENDIX B - MSAW INTENT SPECIFICATION
51
LEVEL I - SYSTEM PURPOSE
LEVEL 11 - SYSTEM DESIGN PRINCIPLES
51
LEVEL III - BLACKBOX BEHAVIOR
78
19
26
64
BIBLIOGRAPHY
173
5
6
Introduction
Over the course of the past few decades, a technological boom has occurred in the field of
computers. They have become increasingly more powerful, and their usefulness has provided
humans with a tool that can be used in a wide range of applications. Computers have provided
humans the ability to design, build and manage a wider range of systems with increased complexity.
This increased complexity has led increasingly to the use of computers to control complex systems.
Great things have come from this use of computers, such as the ability to produce better, more
useful aircraft and space systems. However, a down side to automating the control processes of
systems where a failure can result in the loss of life and property is that safety might be affected.
Failure does not necessarily come from software errors. Given the complexity of a system, failures
usually come from incomplete requirements or erroneous requirements. Furthermore, the vast
majority of systems are not fully automated. Rather, they utilize humans to manage some tasks and
to mitigate and/or resolve problems. This fact creates further problems because the operator and
the automation might not be in sync. In other words, the operator thinks the system is doing one
thing, while the automation is doing something else. Thus, understanding of the system processes
and of the interfacing between the automation and operator are also of crucial importance.
To solve these issues, safety needs to be considered from the very beginning stages in the
design of a system. When doing this, requirements can be drawn up to eliminate or minimize
possible hazards. Afterwards, design decisions are made to satisfy these requirements and ensure a
high-level of safety. If a procedure such as this is not followed, changing the design requirements at
a later stage to solve a safety issue that could have been taken into consideration at the beginning
proves to be very costly, and sometimes comers are cut (e.g. safety) to not undertake those costs.
Failure to do this also adds costs due to time spent changing the system, and the quality of the
7
design might be degraded. When taking safety into consideration early, requirements for the system
and the human/computer interface can prevent, to a certain extent, any hazardous conditions in the
system, and therefore limit any accidents that might occur. Additionally, all people that will need to
understand the system should do so in the same manner. For example, the operators need to know
how the system works exactly the same way as the designers intended it. When the models of the
system are the same for everybody involved, problems can be prevented more easily because all
parties understand the system in the same manner. This is where intent specifications and the
Specifications Tools and Requirements Methodology (SpecTRM) requirements language Prof.
Nancy Leveson has developed play a role.
Intent specifications are meant to provide system and software engineers a way to perform
"requirement analysis, software design, review for correctness, debugging, maintenance and
evolution, and reengineering" [1]. Intent specifications help designers be in sync with builders, as
well as builders with maintainers or operators. In other words, they "help the designer, builder,
tester, debugger, or maintainer understand the system well enough to create a physical form, or to
find problems in or change the physical form" [1].
Secondly, SpecTRM is a formal specification language under development that can be used to model
a system, and to analyze it for completeness. It is also intended to be readable to all parties involved
in the system, which allows for everybody to have a clear model of the system at hand. Prof.
Leveson's Safeware Corporation is developing software that would allow users to specify the
requirements using the SpecTRM-RL form, to execute the specification to check it for completeness
among other things. Both of these, intent specifications and SpecTRM, are designed to be humancentered, that is, the fact that humans will be using and operating the system is of primary concern
at all stages of development. In combination, these are a powerful mix that has the potential to
improve the world of system design and implementation.
8
The research for this particular project involves an analysis of SpecTRM, which was
performed using the STARS ATC Minimum Safe Altitude Warning (MSAW) subfunction as an
example. MSAW detects whether an aircraft is flying below a safe altitude for the area. This
subfunction was modeled using the SpecTRM Requirements Language. The MSAW function of
STARS provides a good test case because a failure in such a function can lead to the loss of life and
property. It also includes a human/machine interface between the function and the air traffic
controller. Additionally, as part of the analysis, the SpecTRM model for the Matterhorn Bobsled
Ride developed for the System and Software Safety class (16.358), and the process leading to the
model, was used.
The project described herein involves two main issues in addition to providing an analysis of
MSAW and its current documentation. The main part of the project involved analyzing the current
tracing techniques used in intent specifications for linking the different elements to each other.
The second part of the project involved a problem that has been encountered in the use of
intent specifications. The problem is that people encounter some trouble distinguishing between the
five levels that encompass these specifications, primarily determining what goes between the second
and fourth levels (See Background section for descriptions of the different levels of intent
specifications). This project, in addition to analyzing and modeling the two systems mentioned
above, explores this problem and attempts to further explain how a person can utilize intent
specifications without having as much trouble. The project provides a discussion on performing
analyses and dividing the information of a current system into the different levels of intent
specifications, or defining and creating level by level a new system without going into unnecessary
detail. With a clear knowledge of the differences between the levels, the task of tracing is expected to
become easier because there is no interleaving of information, no redundancy between the levels.
That way people will clearly get the "Whys?" and "Hows?" of the system being specified. Currently,
9
the five levels of the intent specifications are clearly defined in theory as part of previous work by
Prof. Leveson and her colleagues, and there are several examples of them being applied to real
systems, but a more general and practical view of the specifications is a good next step that will
hopefully lead to even more solid and robust intent specifications. In this manner, anybody would
be able to use the specifications to their advantage.
10
Related Work
Professor Nancy Leveson has worked on several proofs of concept for her modeling
language SpecTRM-RL. The most significant one was the intent specifications created for the
Traffic Collision and Avoidance System (TCAS) II, which was done with Jon Damon Reese [3].
TCAS II provides collision avoidance help for aircraft by interrogating the transponders of aircraft
in its vicinity. If the aircraft has the potential to collide with the other aircraft, or it is predicted to do
so in the near future, TCAS II would alert the pilot of the fact. TCAS II outputs two types of
advisories, a preventive advisory in the case there are many aircraft in the vicinity telling the pilot not
to climb, descent or adjust vertical speed, and a corrective advisory telling the pilot to climb, descent,
etc., to ensure a safe separation between aircraft in the case of an imminent hazard.
A complete example of intent specifications was created for TCAS II encompassing the
different levels mentioned above. From this work several papers were written to further develop the
modeling language as well as the intent specification methodology as defined by our research. See [3]
for the intent specifications.
Additionally, work has been performed on systems such as the Center-TRACON
Automation System (CEAS) and Eurocontrol (Europe's ATC).
11
12
Background
In its most basic form, intent specifications are "an approach to building human-centered
specifications" [1]. Given the complexity of today's engineered systems, human operators and
maintenance technicians need to be a primary focus when developing any system because the
complexity of these systems, particularly those where automation takes on a primary role, can lead to
new kinds of human error that are not dealt with by the automation. These errors are usually due to
differences between the state of the system and the perceived state of the system by the operator.
This confusion can lead to wrong decisions on the part of the operator. These mistakes, which can
lead to deadly accidents, are frequently attributed to human error when in reality they are caused by
flaws in the overall system design. Therefore, system engineering nowadays needs to be humancentered, not just technology-centered.
Intent specifications take into consideration the psychological processes humans go through
when performing a task or solving a problem using the specifications of the system. Intent
specifications include the "Whys" and "Hows" of the system so that users understand the processes
behind that which he or she must control or oversee. It "captures the meaning and assumptions
behind the problem-solving process modeled in the system" [2]. Given a clear understanding of the
system, its true intentions and the specifics of how it works, users will have a clear model of the
system, will be able to handle their tasks more easily and be able to mitigate and resolve any
problems they might encounter with more precision.
An intent specification encompasses four key elements, which provide its foundation. First is
the process of the system. Any system contains a process, which is the underlying manner in which
a system is developed from its early stages to its full implementation. The "process provides a logical
structure for problem solving" [1]. All parts of the development process, as stated before, are to be
13
mapped to each other, thus tracing hazard analysis results to system and software requirements to
design decisions to how they were implemented in the actual system.
Another key facet of intent specifications is that they take into consideration issues revolving
around the interactions between humans and the machine. The interface between the system and
any human operator is to be carefully designed and implemented to satisfy any requirements brought
about in the hazard analysis of the system. Therefore, given the difficulties of integrating computer
and human control, features can be implemented in the system with the intent specifications
methodology that can prevent human error.
The next three elements of intent specifications are what separate them, in a way, from the
commonly used specification methodologies used in industry and government. These elements are
content, structure and form. They are important because they can deal with the psychological
processes people go through when looking through specifications, and can improve readability so
that everybody can have a clear understanding of the system, and thus prevent any problems that
might result from misinterpretations.
Content deals with what is contained within the system, and what needs to be presented at
each stage of development. Inputs, outputs, system boundaries, and the system environment are
specified. Additionally, content should be complete, presenting the system clearly in its entire form.
Third, structure is the way the content is organized. The structure should present the
information thoroughly, clearly and in a coherent manner for the user can carry on with his
problem-solving task. All information on a system should not be hard to find, so organization is
crucial. Intent specifications, as defined by our research, structure information into five hierarchical
levels as explained below.
Last but not least, form "is the presentation of the content to the user in the specified
structure". Every system to be developed will require a specific notation and language for its
14
description. This notation and language used needs to be addressed with respect to human
perceptual and cognitive capabilities so that they are usable by the user for his/her problem-solving
task.
Through these four key elements, intent specifications provide a way to build systems that
can easily be changed since all implementation decisions are traced to design decisions and
requirements, which in turn are traced to hazards through hazard analysis. So, if a requirement needs
to change, people will know what parts of the system the changes will affect, and re-validation of
requirements is easier. The ability to easily change system requirements is beneficial to systems with
properties such as safety and security because they are of primary importance in many systems, and
they must be built in from the beginning of the development process, not afterwards. Through
intent specifications, these qualities can be tracked throughout the design process from its
beginning, providing a way to include these properties without as much cost. Clear traceability
between all these stages of development simply makes the evolution of a system efficient.
Intent specifications, as defined by our research, consist of dividing the development of a
system into five different levels. Design and implementation decisions at each level are mapped to
the goals, requirements and constraints they were conceived to satisfy. This is done throughout all
the levels. Vice versa, high-level requirements are traced down to the implementation, or physical
form. As proof of concept, Prof. Leveson worked out the intent specifications of the Traffic
Collision and Avoidance System II (TCAS II) [3]. The different levels and their description follow
(emphasis is given to the first three levels):
+ Level I, System Purpose: The first level of the intent specifications encompasses
the purpose of the system. In this level, the system and its history are described as well as its
environment. The environment is basically all of the components the system being designed has. For
15
example, as part of the environment one can include the interface, the operator and the setting in
which the system will operate. With a clear picture of the environment, the boundaries of the system
are drawn, which will ease its development. In addition, and extremely important, the first level
includes a hazard analysis of the system. With a thorough understanding of the hazards and their
causes, a system engineer will then derive high-level goals, requirements, and constraints for the
system, software, operator and interface among others. These requirements and constraints are used
to mitigate the hazards that are inherent in the system, providing a way to make them minimal or
non-existent. Any assumptions related to the system, its conditions and the environment are also
documented in this level so as to provide a clear understanding of the reasons why some design
decisions were made in the lower levels.
* Level II, System Design Principles: The basis of level two is the design of the
system itself, and the description of all the system design principles. System engineers take all the
requirements and constraints of the first level and make design decisions that satisfy these
requirements, or minimize any hazard that may come from not fully satisfying it. Included in this
level is the logic and algorithms that drive the functions of the system, but only taking into
consideration inputs and outputs, which are described in this level. The logic and algorithms
describe what input combinations are required for all outputs that the system will contain, never the
inside workings of the system.
The interface design is also part of this level, which must also satisfy the interface
requirements derived from the hazard analysis in the first level. Yet another part of this level is the
testing and validation of the design. Validation of requirements is essential to the next stage of
implementing the system because requirements should be complete, thus helping minimize any
16
potential hazards. Still, this portion of the level is usually system specific, which may include, but is
not limited to, simulations and experiments.
* Level III, Blackbox Behavior: The third level analyzes the black box behavior of
the system as specified by the logic and algorithms of the second level. All of the components of the
system are described in terms of inputs and outputs, and the interfaces between these components.
This level also includes the human components of the system. The behavior of the system is
described "only in terms of externally visible variables, objects, and mathematical functions" [1].
These components can be built using hardware or software, and such decisions are usually made in
the lower levels, if they have not been made yet. Having such a blackbox behavior available for the
system, without having implemented it yet, allows for the testing of the requirements, thus making
sure they are correct, unambiguous and complete for the system being developed. If a system has
been implemented already, it is costly to modify it due to changes in requirements. Doing such
testing at this stage allows system engineers to add, modify and delete requirements as needed
without the added monetary, resource and time costs of having to change any implementation.
This level can also include things like operator tasks and procedures, descriptions of the
interfaces and the message formats, as well as the specific testing requirements for the system.
+ Level IV, Physical and Logical Design Representations: This level contains the
design representation of the system. It contains information about the physical and logical
implementation of the components, usually in a language very familiar to software and hardware
engineers. This level contains information such as specific software design, and the design of other
components. Not all of the information in this level can be traced to the upper levels given that it
allows the implementers to design the actual system with performance enhancing features that are
17
not required for the safe operation of the system. Other examples are the decision to use a specific
communications protocol over another or the decision to use C instead of Java. "Knowing that
these decisions are not linked to higher level purpose is important during software maintenance and
evolution activities" [1].
This level can also include operator manuals, human-computer interface design specification
(e.g. the actual screens the operator sees and its options for operation), and verification requirements
for those design decisions made at this level.
* Level V, Physical Realization: The last level is the actual physical representation of
the system, which includes, but is not limited to, "the software itself, hardware assembly
instructions, [and] training requirements (plan)" [1].
As explained before, all of these levels are connected through tracing. All of the
requirements of the first level will trickle down to the lower levels until they are fully satisfied. For
example, a requirement may be eliminated altogether via a general design decision in the second
level. On the other hand, it might be dealt with through the design, modeled in a black box form,
and then coded to satisfy the requirement. With this method, a reviewer or any other person will be
able to work through the specification document with relative ease because of this tracing, and be
able to draw the intentions of every decision along the way, with the possible exception of
optimization decisions made at the fourth level.
18
Test Cases
This section explains in detail the test cases used in this project. Being the main test case,
STARS goes into more depth than the Matterhom Bobsled Ride, which is used as an additional
example. These two test cases give us different perspectives on intent specifications. MSAW was
conceived in a backwards approach, from already existing documents, while the Matterhorn was
conceived from scratch.
Standard Terminal Automation Replacement System (STARS)
STARS is a project undertaken by Raytheon Corporation to provide an upgrade to air traffic
control automation systems. STARS provides automation to support air traffic control functions at
FAA Terminal Radar Approach Control (TRACON) and DOD Terminal Control regions [4].
STARS will fully replace the current air traffic control system after extensive testing for reliability
and safety [4]. STARS is currently deployed in two sites and no major problems have been reported
as of this moment [8]. Human air traffic controllers will use STARS to perform ATC functions as
defined by the FAA Handbook 7110.65 named "Air Traffic Control", which includes, but is not
limited to, radar separation, processing handoffs between controllers, and checking for conflicts and
minimum safe altitude violations [4].
Although some of the functions of STARS were developed fully by Raytheon, portions of it
came from commercially available software as well as from Non-Developmental Item (NDI) ATC
automation systems that have been fielded in other nations [4]. Many players have been involved in
the design and implementation of the STARS systems. The FAA provides the key high-level
requirements for the system, and Raytheon then carried out and implemented the system to satisfy
those requirements. There was no specific process to deal with human factors in the development of
19
STARS, even while the FAA provided a lot of input. Additionally, although controllers and other
people involved in the daily operations of an air traffic control system participated in this
development, their feedback was not sought or heard at different points in the development process.
This fact led to several late changes in the system because it was not up to the standards controllers
wanted the system to be, particularly the interface requirements. Furthermore, there was not much
time dedicated to human usability testing. However, in the end, the controllers requirements for the
systems were satisfied, which cleared the way for its deployment as part of the testing phase. [8]
The Minimum Safe Altitude Warning (MSAV) subfunction of STARS will be used as a test
case. This module checks whether an aircraft has flown below an altitude in which it can collide with
an object in the environment, such as a mountain or building. MSAW also checks for minimum safe
altitude issues when the aircraft is in a landing approach. An extensive description of the MSAW
software design is in Appendix A.
As part of the overall STARS/SERL project, the Conflict Alert and Sector Handoffs
subfunctions are also being modeled. Please refer to ... for these models.
Matterhom Bobsled Ride
The Matterhorn Bobsled Ride is a replica of the Swiss Matterhorn Mountain. It was
constructed in California by Disney and provides a fun attraction for Disney park goers. The ride
takes passengers up the mountain in specially made cars, and then they ride down the mounting
driven only by gravity.
As part of the System and Software Safety class of the Spring 2001 academic term, students
were asked to design this ride after only being given a basic description of the ride. Students went
through the intent specifications process, level by level, down to the third level, blackbox behavior.
The intent specifications for the Matterhorn Bobsled Ride was limited, however, to the control
20
system given the complexity and amount of time required to develop such a ride from scratch.
Additionally, students had to design the control interface.
A number of safety issues were addressed as part of the development of this replica and that
is why the lessons learned while performing this task provide a good deal of information for this
project. For example, the control system was designed to maintain the cars at a safe distance from
each other. A collision can result in injury, or even death, for guests. Therefore, ensuring that cars
are kept at a safe distance by designing in this property from the beginning of the development
process is efficient and cost effective.
21
22
Analysis
Current STARS/MSAW Documentation
Before talking about the results of applying intent specifications to the MSAW function of
the STARS systems, the actual specifications of the system must be analyzed in more detail.
Raytheon provided two major documents on the system, which provided the vast majority of the
information needed to evaluate the system and understand it. These documents are [4] and [5].
The way these specifications have been made had many strengths. The top requirements for
the system were clearly defined and easy to read. These appeared in [4] and was each listed with a
relevant heading such as Altitude Source for those requirements that dealt with what wiln be
providing the data on which to detect low altitude violations. These provided a pretty clear, concise
starting point in the development of the system. For the intent specifications created for MSAW,
these high-level system requirements were used as such in the first level (See Appendix B 4 Level I
4 System Requirements).
Other parts of the specifications, however, were not as clear, particularly the reasons behind
the many design and implementation decisions. The majority of the reasons and assumptions behind
the system design principles seem to have vanished in the years since the FAA specified MSAW
through the NAS-MD-644 [7]. Raytheon followed the NAS-MD-644 in its design and
implementation of MSAW. When asked questions about certain of the functions and ways MSAW
was implemented, such as the Windows Processing section (See Appendix A - Fine MSAW Filter
+
Window Processing), Raytheon engineers said to look at the NAS-MD-644. Nevertheless, all the
NAS-MD-644 contained was information as to what MSAW must do and the principles behind the
functional algorithms, not the reasons behind them. A lot of the intentions, assumptions and
reasons can be drawn by sheer common sense, but when dealing with safety-critical systems that can
23
result in the loss of life and property, everything must be stated in a clear way to make the
specifications complete. Different people will draw different conclusions when presented with the
same information, so it is crucial that reviewers as well as maintainers of the system be able to know
the why's and how's of the system. Although work still needs to be done in its full development, an
intent specification provides this critical aspect. Therefore, inclusion of all relevant information is a
point to be reconsidered in a full specification of MSAW.
Another important point is regarding inputs to the system. The SRS document [5] provides
information on the blackbox behavior of the system, but some of the inputs are ambiguous in the
sense that it is hard to figure out their necessary descriptive information. The SRS includes a list of
variables (which include the different inputs) in a form that is used inside the code (i.e. FPData,
MSAWCA Parms, switchovermessage), and there is no exact description of the variables. So, if
there is any document describing these variables in detail, since there is nothing to link the SRS to
such document, a reader will be left with questions that can be easily answered through Level III of
an intent specification. Indeed some details can be extracted from reading the SRS, but it is no
substitute for a clear, separate description of each input variable, or any other variable for that
matter. See [10] for more information on the way intent specifications specify inputs and variables.
The outputs have similar issues as those of the inputs.
One key aspect of the research performed by Prof. Nancy Leveson is the fact that most
system errors are in the requirements and not in the actual software. That is the reason why
completeness in requirements is a crucial step before the actual software design and implementation
of a system. The first three levels of an intent specification provide a way to validate requirements
before the software design and implementation commences, thus providing a less costly path in the
case an error in the requirements is found. Once implementation begins, it is often harder to do this.
Additionally, only specifying the system in terms of inputs and outputs initially provides
24
implementers with the freedom to build the guts of it as they see fit, optimizing it for better
performance. As long as outputs are triggered by the same combination of input conditions, the
insides do not really matter.
The SRS document is a mixture of requirements and software design. The requirements are
listed as they were in the SSS, but a lot of software design decisions are made as well. As seen in the
intent specification created for MSAW, some of these software design decisions were not included
given they are not necessary to specify output to input relations. The main point in mentioning this
is that given the importance of validating requirements and checking them for completeness before
making software design decision, it might be a good idea to review the current methodology that
produced the SRS.
Traceability is another issue that was a little problematic across the different documents
Raytheon used to specify MSAW. The SSS document contained the high-level requirements for the
system. The SRS contained the system design, and how it was to be implemented. The design
principles of the system and their blackbox behavior were not overtly traced back to the high-level
requirements of the SSS. So, there was no direct connection between the documents, which are
related to each other. However, the biggest issue was that of tracing the design and implementation
to the NAS-MD-644. There is no mention of the NAS-MD-644 anywhere on the SRS or the SSS.
Therefore, a reviewer of these specifications will be left with unnecessary questions about the
reasons behind the decisions made in the SRS until he or she asks the designers and implementers as
we did in our meeting with Raytheon [8].
Another issue in tracing was the following. The MSAW part of the SRS talks about some
conditions it checks. For example, MSAW checks whether an aircraft is within an airport area, which
is a geometric figure that extends up to a certain altitude. However, there is nothing mentioned as to
the principles and equations for doing this. These are found on another section of the document but
25
there is no link between the MSAW part and this external function that does this checking. It was by
chance that this section was found and the information was incorporated into the intent
specification for MSAW.
Despite some trouble, overall, the system documents were clear enough to create a
SpecTRM model of the system as seen in Appendix B, Level III.
Finally, the possibility that some of the analysis provided herein is incorrect exists. However,
the very fact that this review of the requirements and design of MSAW can yield such
misrepresentations proves that there is always work that needs to be done in the organization,
traceability and clarity of the system documents provided, even with the short time between the start
and end of the review. Therefore, future reviews will be easier and more productive.
Distinguishing the Levels of Intent Specifications
As mentioned in the Introduction, distinguishing what parts of a system goes in which level
can sometimes prove to be somewhat problematic, primarily distinguishing between the second and
fourth levels. A reason for this is that engineers are often taught that when they are to design a
system, it must be done with attention to detail and specifics.
As a result, when they are to design a system as part of Level II, people might dive into specifics that
belong in Level IV. The concept that the design in Level II is as a blackbox somehow becomes lost
in the process because of that notion of "design" people have been taught. This section provides a
discussion of this issue.
In the process of developing a system using the methodology of intent specifications, after
going through the first level, what the system engineer must realize is that the design to be done in
the second level is as a blackbox, mapping outputs to the inputs that cause them.
26
In the system design, there should never be anything that says how the system turns an input into an
output, but only the principles behind how it is done. For example, for MSAW an alert is raised if
the track falls below the glideslope when it is in a landing approach. The output is the alert, while the
inputs are the variables used to calculate whether it falls below the glideslope or not. The
engineering principle behind the output is an equation that determines that condition (See Appendix
B - Level II
Equation (1)). In the fourth level, where the actual software design is created, one
can write pseudocode of when and how this equation will be applied.
The same kind of behavioral examples can be seen throughout [3] (See items 2.29 through
2.34). For example, look at the following principle:
[ 2.29] The dhwt detetion eiteria nsists ofa rane test and an altitude test Both rust be satisfied to deiam the
intrudera thmat A so, dh stimnte of the intrder's zrtical rate nrrste&er b of high cmgdexe orhbxndedsud>
thatan escape rrnmeris jud d safe dspitea rane ofunxrtainty OQhruise,the intmder is not dedareda that
(I Threat-Cndition...)
This principle states the conditions in which an intruder aircraft can be considered a threat
and the inputs necessary for it, but not how the system does it.
This section is to be taken as a short guide to differentiating the levels of intent specification,
primarily between levels two and four. Future work should expand on this for more clarity and
added value.
Tracing
Tracing is an extremely important part of intent specifications for many reasons. It provides
the linkages between the different levels of the specifications, making it relatively easier to search
through them, as well as modifying them because of a change in system goals or requirements, or if
27
a new hazard that needs to be dealt with is found. This section contains a step-by-step approach to
tracing the different parts of an intent specification, along with two ideas on how it can evolve from
its current form (as done in [3). These ideas are not incorporated into the intent specification of
MSAW or the Matterhorn Bobsled Ride.
Tracing is done throughout the development of a system, from Level I on. The path it takes
is similar to the path in creating the intent specifications themselves. The steps for clearly tracing the
different parts of a document to their why's and how's follow. The specifics on how to create each
part of the specification can be found in [1], [9] and [10]. examples drawn from MSAW and the
Matterhom Bobsled Ride which differ in the sense that the intent specifications of each were
conceived differently. For MSAW it was pieced together, while for the Matterhorn it was from
scratch. This gives us two perspectives on tracing. The steps are:
1) The goals and assumptions of the system are identified and labeled. Additionally, the
system environment is defined along with any assumptions and constraints it may have. For
example, the two high-level goals for MSAW were:
[G.1] MSA W shall pnide acuirateand tinly detetion of amvnt orprdictalninium safe altitudezdations to
pwrent cxlisions uth the surnundingeminnvwrt and alert the cntmler f the stuaton
[ G.2] MSA Wshall detwt ninimm safe altitudezidations zhen an ainraftis in a landingappmi.
The goals for the Matterhorn were:
[ G. 1] Ensmure thatguests mmin in a safe, contdled, eminwrnt zhile on, unitingfor,or nearby the Mattehorn
[ G.2] Proidean echilaratingsinlationof the e>peiiercecf trazellingdoun a tall nruntainin a bobsled
[ G.3] Prozidea capacity to sernix a nunier qfpeople TBD in a day
28
As you can see, high-level goals are labeled with a G and numbered. Assumptions related to
a goal would just be stated below it and not labeled.
2) After this, a preliminary hazard analysis and a preliminary task analysis are done in order
to consider safety and human factors from the very beginning of system development. For the
hazard analysis, a fault tree is created. For MSAW a fault tree was not created, nor was one available
in the documentation, so all requirements were tied to the hazards. The hazards for MSAW were:
[ H.1] A iraftfalls to an altitude,or its amy trajc
uill take it to a point in uhid> it dates ninirum
separationmqunvnts wth sonEthing in the emiimmnt (ie nrrntain,building, nvmnrnt, etc..).
[ H.2] Landingapprnahpath too steepforproperlanding.
[ H.3] A inTraft amrntlyat a safe altitude, but uill not be able, or zill not hba ernaih tin, to nrwn er auayfrm
a cllision uith sonrthingin the enidrnmn.
A key hazard for the Matterhorn, and part of that hazard's partial fault tree follow:
[H.7] Restraintsfail
3.2
3.2.1
3.2.1.1
3.2.1.2
Restrai fail
OR Wearand tear of traintsstoem
OR Poornuinteranxof straintsystem
Pooiy dsigr estraints(i.e poor nuteials)
3.2.2
rgs toofast, certingtoo nb pmssue on nstraints
3.2.2.1
OR Brakes fail
3.2.2.2
3.2.2.3
-
D2
Exxssi Weeight in zhide
Pawsfail, xerting too ndhfoze onwhide
29
Here we see that a restraint failure can be caused by either wear and tear of the restraint
system or if the car goes too fast, exerting too much pressure on restraints. Each of these is further
refined as shown above.
3) Requirements (system, maintenance, management, operator and interface) are conceived
to minimize or eliminate all the hazards encountered in the hazard analysis through the fault tree.
Although not all requirement types are shown here, they are labeled in the following manner: SR for
system, 0 for operator, etc.
To continue the previous example, here is one important requirement that can be derived, at
least, from the MSAW hazards list, given there is no fault tree available:
[ S& 13] Ifa track is amently orpmdiaa to he blowa nininiumsafe altitude, the system shall be able to raisean
alert(-+ H.1, -> H.2, -+ H.3).
In the case of the Matterhorn, the following requirements were written to eliminate or
minimize the causes of the hazard where restraints fail presented above:
[S R.9] Then shall oistprimrynstraints on ead skd that ill dthstandalad of200% of the cpeta1
rmxirmmpassengerzegt (-- FT 3.1, -> FT 3.2)
As you can see in both examples, they contain arrows pointing to the hazards or partial fault
tree cause they are meant to eliminate or minimize. A -+ arrow signifies that it is pointing to an
element within the same level. This type of arrow usually implies a "why", the reason why the
current item is there. It is recommended to be used only in the first level of intent specifications
given the information contained therein (i.e. PHA, requirements, etc.) In addition, a tarrow signifies
that it is pointing to an element the level above, while a I arrow obviously points to an element in
30
the level below. The former also implies a "why'. The latter implies a "how", the way the current
item is implemented.
The first idea relates to the presentation of these pointers, particularly when linking items
within the same level. If for some reason we need to point to an item within the same level, to keep
the order of things, the links can be written in the following form:
(Links Up; Links Down)
In this case, a reviewer would automatically know that in the flow of items, the links to the
left of the semi-colon point to items before or above, while those links to the right point to items
after or below. If there are no links in one direction, a simple dash is put in place. This enhancement
can serve a good purpose especially on the first level where requirements satisfy items in the partial
fault tree. It can also be used in other levels. This methodology does not take away from what is
currently being used, but rather adds a new feature with the potential to enhance clarity and
reviewability across the document.
4) At the same time as requirements are generated, design constraints are also generated.
There are general system constraints (labeled with a C and a number) as well as safety-related
constraints (labeled with an SRC and a number). An example of constraints generated for the
Matterhorn that come from the hazard and fault tree example above, which will be later shown to be
satisfied in the design, follow:
[ SRC.6] The system nust tranitionto safety nre ia rstraintfailed (-+ FT 3.0.3, ->FT 3.2,
-
FT 3.3,
-
FT 3.4, -+ FT 3.5)
[SRC.7] The system nust Axek that all mtraintsare inpla befor allozinga w>ide to be nvzi (-+FT 3.0.3,
--* FT 3.2, -+ FT 3.3, -+ FT 3.4, -+ FF 3.5)
31
5) The next step in the system development process is the design of the system itself as a
blackbox, that is, mapping the outputs needed from the system for their triggering input
combinations. Design principles, as seen in Level II in Appendix B, are labeled with a 2 followed by
a numbering scheme in progressive order as principles are written in the document. Additionally,
refinement of principle 2.4, for example, into two others would be labeled as 2.4.1 and 2.4.2. This is
a simple way of stating that any pointer to a 2.?? somewhere else on the intent specifications, that
item (principle) can be found in Level II, specifically in the section on the system logic.
The second idea deals with the actual labeling of items. A key aspect of tracing is that this
numbering scheme can be limited to the system logic. Other sections of Level II may be labeled
differently depending on the title of the subsection. For example, the principles of a subsection on
Operator Tasks and Procedures (0TP) can be labeled with a 2.OTP. followed by a corresponding
number. This ensures that a reviewer that wants to look for something because he was pointed to it
by this type of label, he or she, with a table of contents, will look in Level II in the OTP subsection
instead of trying to search through the pages until the right number is found (i.e. the 71 in 2.71.4).
For really complex systems, this method might be better and more productive.
Following is the continuation of our examples of tracing. Here are the MSAW design
principles that satisfy the requirement mentioned above:
[ 2.12 ] A acnntpositionaLert is raised ithin theA ppmh nxde uhen thefdlozeing conditions am net (T SR 13).
[ 2.14] A pmdikted position alt is raised uithin the A pprub nxle uhen thefdlouing conditions am nzt (I
SR. 13).
[2.19] Fora arwntposition alert to be raisedin this nxle, any of the track's arentpcsitionpoints nust be zithin
the space of the terrainnup elenrnt eacb track pcsitionpoint is amrntly in (I SR 13).
[ 2.20.2] The pndTaedpcsition alen is raisedifany of the t=o pmdicte lines offlight is zithin the space, 1oze; a
terrainnup elenrnt eacb nwy pass thmugb
(T SR 13).
32
[2.21.2] Ifany p4ected lines
fflight a vuithin a terrainnup eenrnt space each ny pass thbrh, ewn zith the
angie jfasxn?4 a prqctedpaitionaletis raised(T SR 13).
All of these design principles can be found in Appendix B. The first two, 2.12 and 2.14, are
refined with the specific conditions that are needed to raise the alert (See Appendix B), but for the
sake of being concise, they are not included above. As you can see, all of these point upwards to
system requirement SR.13.
For the Matterhorn requirements, the corresponding design principles follow, but not
including SR.9 because the project was focused on the automation. SR.9 would be dealt with simply
by choosing strong enough materials to withstand 200% of the maximum weight chosen for the
ride. The principles are:
[2.1] Once the cont system is satisfil that ide is safe based on the system dx s, it den gi
the operatorthe
sewn options ntom axe It is also inportantto ncte that the system il1 not prxess the operator's?sponse in
less than 22 savnds. This is the ninimum tine that has xen detemimd to assume that ninirum separationof
whids is rminaind (T SR.38, T SR.39, T SR.42, I SRC7, T SRC8, T SRC9, T SRC11)
[2.2] The contnd system zil transitionto Safety Mode if the mstraintsfaiL
(T SRC 6)
These Matterhorn design principles are arbitrarily labeled, as the final intent specifications
document is not finished.
In addition to pointing up to the requirements, design principles may point down to the
blackbox behavior model created in Level III. For the sake of clarity, this should always be the case.
6) The next step is to trace all the design principles to their respective parts in the SpecTRM
model created in Level III of the intent specifications. From this point on, tracing becomes easier
33
given that we have a design of the system and all that is needed is to point at where they are satisfied
directly. For every specification in the SpecTRM-RL model, there is a line called References:, which
is used to trace that variable up to its intent and down to its implementation. The same arrow
convention is used to do this tracing.
To follow in the example of MSAW, on the next three pages appear the output
specifications that satisfy the requirements we are tracing down:
34
Output Message
Current-Alert
Destination: Terminal Controller Positions (TCP), Situation Data Displays (SDD), Data Recording Facilities (DRF) and
Control and Monitoring Displays (CMD)
Acceptable Values: True/False
Initiation Delay:
Completion Deadline:
Exception Handling:
Feedback Information:
Variables:
Values
Relationship:
Min. time (latency):
Max. time:
Exception Handling:
Reversed By:
Description: This output message alerts the controller that an aircraft is in current low altitude warning. The message
contains all relevant alert information such as track position and altitude.
Comments:
References:
Contents
Triggering Condition
Control-Mode(i) = Approach
Control-Mode(i) = General-Terrain
Track-Eligibility(i)
Track-in-Approach-Monitor-Inhibit-Area(i)
Track-below-Glideslope(i)
Track-in-General-Terain-Inhibit-Region(i)
T
F
T
F
T
*
Track-in-Terrain-Map-Element()
*
35
F
T
T
*
F
T
Output Message
Predicted-Alert
Destination: Terminal Controller Positions (TCP), Situation Data Displays (SDD), Data Recording Facilities (DRF) and
Control and Monitoring Displays (CMD)
Acceptable Values: True/False
Initiation Delay:
Completion Deadline:
Exception Handling:
Feedback Information:
Variables:
Values
Relationship:
Min. time (latency):
Max. time:
Exception Handling:
Reversed By:
Description: This output message alerts the controller that an aircraft is in a predicted low altitude warning. The
message contains all relevant alert information such as track position and altitude.
Comments:
References:
Contents
Triggering Condition
Control-Mode(i) = Approach
Control-Mode(i) = General-Terrain
Track-Eligibility(i)
Track-in-Approach-Monitor-Inhibit-Area(i)
Track-below-Glideslope(i)
Track-Predicted-Po sition-below- Glide slope (i)
Track-in-General-Terrain-Inhibit-Region(i)
Predicted-Lines-of-Flight-in-Terrain-Map-Element()
T
F
T
-F
F
T
T
*
F*
T*
*
*
36
F
T
Output Message
Projected-Alert
Destination: Terminal Controller Positions (TCP), Situation Data Displays (SDD), Data Recording Facilities (DRF) and
Control and Monitoring Displays (CMD)
Acceptable Values: True/False
Initiation Delay:
Completion Deadline:
Exception Handling:
Feedback Information:
Variables:
Values
Relationship:
Min. time (latency):
Max. time:
Exception Handling:
Reversed By:
Description: This output message alerts the controller that an aircraft is in a projected low altitude warning. The
message contains all relevant alert information such as track position and altitude.
Comments:
References:
Contents
Triggering Condition
Control-Mode(i) = General-Terrain
Track-Eligibility(i)
Track-in-General-Terrain-Inhibit-Region(i)
Projected-Lines-of-Flight-in-Terrain-Map-Element(i)
T
T
F
T
37
For the Matterhorn example, the output specification is similar to the ones for MSAW, but
stating that if the input from the sensors indicates that the restraints have failed, the control mode
will be changed to Safety. Additionally, if the restraints have failed, the controller will not be given
the option to advance the cars, and add/remove vehicles.
The fourth and fifth levels are specified in the same manner, with pointers up to the
previous levels and down to the actual system itself, be it to the code or the hardware, and using two
special labels, Reference: and Appears In:, as in the third level. Pointes appear in the former while
the functions that use a given SpecTRM-RL element appear in the latter. Given that this project did
not involve writing the fourth and fifth levels of the intent specifications of neither MSAW nor the
Matterhorn Bobsled Ride, examples cannot be given. Please refer to [3] since that is a complete
intent specification, and provides examples of tracing to and from the fourth and fifth levels.
After all tracing on a system is done, a tree can be constructed to point the way from a
requirements to all the elements in the levels below that are used to satisfy those requirements, and
vice versa. A reviewer will then have a visual component of tracing.
38
Conclusion
Intent specifications provide a human-centered, safety-driven design process for systems
which failure can result in the loss of life or property. The project described herein uses a real,
safety-critical system, STARS, and evaluates it as a proof of concept for intent specifications. The
Matterhorn Bobsled Ride class project is also used to a lesser extent. As for STARS, after a long
process of reading documents provided by the Raytheon Corporation, the intent specification for
the MSAW function was created with relative success, allowing us to perform an analysis on it.
Additionally, some features of intent specifications were described and analyzed, the different levels
and tracing, providing some new enhancement ideas for possible future review and use. Hopefully
the value the work contained herein has provided will be helpful in the endeavor of ensuring that
safety and human factors become commonplace in the design and implementation of real-life
systems.
39
40
Future Work
Given that the methodology of intent specifications, along with SpecTRM, is relatively new
and state-of-the-art, further work is needed to enhance it and its features. There are two things that
would need to be worked on given the work contained herein. First, an expansion of the section of
how to practically differentiate between the levels of intent specifications is necessary for those who
start to use our methodology. Second, test the ideas on tracing presented with different kinds of
people, such as reviewers, maintainers, operators among others. These tests would try to prove
whether these ideas do enhance the reviewability of intent specifications, making it easier for all
parties involved.
41
42
Appendix A - MSAW Software Description
In this appendix appears an extensive description of the STARS MSAW Software based on
[5]. This description follows their specifications and can be contrasted to the MSAW Intent
Specifications also included in Appendix B.
MSAW
The MSAW software is composed of three main components: the Coarse MSAW Filter
(a.ka. COARSEMSAWFILTER), the Fine MSAW Filter (a.ka. FINEMSAWFILTER), and the
Generate MSAW Alert Module. Details of these systems follow shortly.
Fine MSAW Filter is further subdivided into other sub modules. These are Airport
Monitoring, General Terrain Monitoring, and Windows Processing. Airport Monitoring has a sub
function within it called Runway Processing. General Terrain contains the following sub functions:
Current MSAW Violation Processing, First Segment Processing, Second Segment Processing, and
Mosaic Tile Processing. Windows Processing is a function on its own. In addition to these, the
Generate MSAW Alert Module is stand-alone function as well.
Below are descriptions of all these components and their respective sub components,
including the logic of how they work.
43
GenerateMinimum Safe Altitude (MSA) Violation Candidate Track
List
MSAW first processes all tracks at a periodicity of about 5 seconds with a sub function called
COARSEMSAW FILTER. This filter takes valid Mode-C data for all tracks, and if valid C mode
data is not available, then altitude data manually entered by the pilot is used. If no data is available,
the track is not eligible for MSAW processing and no alert is raised.
MSAW processing requires that tracks be within an eligibility volume that extends up to an
adaptable altitude. If tracks are not within this volume, they will not be processed. Additionally,
tracks must not be frozen.
Tracks that are processed and at an altitude higher than the system's largest MSA, which is
1000 feet above the highest point in each position tile, are not placed in the track candidate list. All
others are placed in this list and further processed by FINEMSAW FILTER.
Under each heading, the requirements are explained in writing and then listed for
traceability. Those requirements listed are those in Raytheon's SRS document unless otherwise
noted.
Minimum Altitude Violation Tests
FINE_MSAWFILTER takes the candidate list created by COARSE _MSAW FILTER
and keeps tracking the altitude of the tracks on this list. This sub function has two monitoring
elements that process the tracks on the candidate list, Airport Monitoring and General Terrain
Monitoring. Each track goes through Airport Monitoring, and then General Terrain Monitoring.
The former produces Approach violations while the latter produces General Terrain violations.
44
A irpartMonitoring
Each track first passes through Airport Monitoring. A track is checked to see if it is within
an adapted airport volume, checking each of at most 12 airports, one primary and at most 11 satellite
airports. If a track is not at a specific airport, the next airport will be checked. If the track is at no
airport, it will be passed on to General Terrain Monitoring.
If a track is within an airport area, a check is performed to see if it is departing within a
departure inhibit volume (up to 5 for each airport). If so, it is exempt from all MSAW alerts. If the
track is in the approach monitor inhibit box (a runway section in which the aircraft is almost about
to touchdown), no alerts will be generated. If none of these conditions are met, that is, not about to
land nor taking off, Runway Processing further processes the track.
Runway Processing
Runway Processing monitors a tracks descent to see if it falls below an adaptable approach
path altitude (a system generated glideslope below the normal glideslope) based on its current and
predicted altitude.
Tests are performed to see whether a track is within a Runway Capture Box, an area that
includes the runway, and its used to aid the aircraft into proper descent to the airport. Also, the
track's altitude must be below the RCB's altitude ceiling parameter. A track can be in different RCBs
at any single point, so Runway Processing checks to see which is the primary, or best fit, RCB for
the track being processed. If the track is not in an RCB, it is passed on to the next airport for
MSAW processing, and if this is the last airport on the list, it is passed on to General Terrain
processing.
An RCB contains two segments, Approach Inhibit Box (AIB) and Approach Monitor Box
(AMB). If a track is in the AIB, it is exempt from further processing and any alerts. If the track is in
45
AMB, it is eligible for MSAW approach alerts only, and it is exempt from General Terrain alerts.
After eligibility is determined, a glideslope (imaginary approach heading plane) is used to check low
altitude violations for the current track. If the track's altitude is below the glideslope at the current
aircraft's position minus an approach monitor current alert pad, an alert is raised and the track is
sent to the Window Processing Section (WPS).
If the track is not currently violating MSA, the software will check for a predicted violation
at an adapted look ahead time, usually 15 seconds. If the predicted future point in which the track
falls below a MSA while the track is inside the RCB, but in the AIB and not the AMB, an alert will
not be raised. If the predicted point is within the AMB, an alert is raised if it is below the glideslope.
In that case, the track is sent to WPS for further processing. If no MSA is violated or will be
violated, the track is returned from Runway Processing.
General TerrainMontonng
General Terrain Monitoring consists of areas divided into tiles of
nautical miles by '/2
nautical miles. Each track is always at a specific tile. Each tile possesses a MSA that is used to detect
current and predicted MSAW alerts. The tiles MSA are updated if necessary.
Tracks are placed, based on heading, along a two-segment path, and a MSAW alert is raised
if it falls below a MSA anywhere along that path.
Current MSAW Violation Processing
If the track is in violation of MSA in its current tile, or the altitude is less than the MSA of
any of the surrounding 8 tiles, all increased by the general terrain current alert pad, a MSAW alert
will be raised.
46
First Segment Processing
A segment is created in this part that extends from the track's current position to the
position it will be at an adapted look ahead time. If the track is at a MSA at the end of the segment,
no alert will be raised, and it will be scissored off at that altitude. The track's current altitude will
then be sent to Mosaic Tile Processing. If the track falls below MSA increased by the general terrain
current alert pad along this segment, it will be sent to WPS.
Second Segment Processing
Second Segment Processing occurs when the first segment projection was not scissored off
or if an alert was not raised along the first segment.
Here, a second segment is created after the first segment using an adapted look ahead time
and an adapted ascent angle (about 5 degrees). If between the first segment and the end of the
second segment, the track's projection violates any tile's MSA, even if the track ascends at this
adapted angle starting at the beginning of this second segment, an alert will be raised and WPS will
be invoked.
Mosaic Tile Processing
Mosaic Tile Processing takes two points creating a sort of segment. First, at a crossing from
one tile to another, if a track's projected altitude is lower than the tile's altitude or any of its 8
surrounding tiles, an alert is raised. If no violation occurs, it checks the new set of 9 tiles that the
track enters, raising an alert if it violates a MSA. Then, if no alerts have been raised, the software rechecks for MSA violations first with the tile it is projected to enter, then with the current tile and its
surrounding 8 tiles, then again with the projected tile it is to enter and its surrounding 8 tiles.
47
Windos PxssingSection
WPS assigns a design parameter value to any MSAW condition with values according to the
following table:
Center Tile
Surrounding Tile
No violation
0
0
Predicted
3
1
Current
5
3
Type of Alert
The weighted sum of a MSAW alert condition is given by:
S = 9V±+8V 2 +7V +6V 4 + V + V6 + V7
+ V8
+V
V1 is the most recent stored alert value and V9 is the oldest. If S is larger than the threshold value
(44), Generate MSAW Alerts will be called with the track's information so that an alert message be
created and delivered. WSP will continue delivering the S of the track that raised the alert until that
value falls below the threshold value. Once it falls below the threshold value, the track is not in alert
and Generate MSAW Alerts will be called off. If S reaches 0, it is taken of the candidate list
generated by COARSE MSAW FILTER.
GeneratingMSAWAlerts
This module takes alerts generated by the previous sub functions and formats messages that
are sent to the SDDs and to the DRF. An Error Status Information Report is sent to the SMC for
display containing information on the message. Additionally, this function will be on regardless of
48
MSAW's on-off switches. The only difference is that when MSAW is OFF, no alert messages will be
sent.
Messages contain all relevant information about the track and also indicate whether an alert
should be displayed, that is, whether the track is currently suppressed for MSAW or not. All alert
messages are sent identically to all SDDs and DRFs. If any condition is new, it is sent as such.
There can be from 0 to 8 general terrain inhibit volumes and if a track is within it, no alert
message will be generated. Status changes due to entering or leaving these volumes generate alerts to
SDDs of volume changes by a track
A timer is set for every track under alert. If the alert has been reported for longer than a predetermined time, the software will send a warning message of termination. The vice-versa occurs as
well.
A ural A larm
Aural alarms will only sound if the track is within on of at most eight aural alarm volumes
that each system has. Tracks not in an aural alarm volume will not generate aural alarms. If a track
transitions in status where aural alarm is enabled, the software updates the alert message to indicate
that an aural alarm is to sound.
Supprssinby Figt
MSA WPefomunce
The minimum safe altitude warning nuisance alert rate is to be less than 4% when the
probability of detection is 45% for warning time >30 seconds and 94% for warning time >0
seconds but <= 30 seconds.
49
50
Appendix B - MSAW Intent Specification
Included herein are the MSAW intent specifications, levels one through three.
Level I - System Purpose
Introduction to Minimum Safe Altitude Warning (MSAW)
MSAW generates alerts whenever a tracked aircraft falls below a minimum safe altitude or is
predicted to fall below within an adapted amount of time. This function performs MSAW tests on
all aircraft within the system at every time interval. Different rules apply when an aircraft is in an
airport area and when it is outside an airport area. Current violators are in more danger than
predicted violators, so priority is assigned to these. When an alert is raised on a violating aircraft, a
formatted message with all of the tracks information is generated and then sent to the controller at
Terminal Controller Positions (TCP), to Situation Data Displays (SDD), to the Data Recording
Facilities (DRF) for backup, and to the Control and Monitoring Displays (CMD). With this
information, controllers can prevent a possible accident by informing the pilot that a maneuver is
warranted.
Historical Perspective
The detection low altitude violations by aircraft have been an important safety issue ever
since the first years of human flight. Advances in aircraft technologies since that time have led to
larger and faster aircraft, creating the need for timely detection of low altitude violations. Previously
pilots relied on visual contact of the terrain, or in terrain maps with respective altitudes to determine
51
whether they were flying too low. However, towards the latter part of the last century, this process
of determining low altitude violations was moved to computers.
For years now, the Federal Aviation Administration has specified how low altitude violations
are to be detected by computers through a document titled NAS-MD-644. The contents of this
document has been modified and improved through the years, making the low altitude detection
algorithms stronger in the process. Raytheon Corporation created the STARS MSAW function
satisfying the NAS-MD-644.
Methodology
Specifics on the methodology used to create this intent specification can be found in [1], [9]
and [10].
Environment Description
The environment of MSAW consists of three main components: (1) the main processing
subsystem, which performs the checks of all aircraft being tracked by the system and executes the
algorithms for selecting tracks under a threat, (2) the interface between controller and system, i.e. the
display, which relays information about the status of tracks to the controller, and (3) the aural alarm,
which alerts the controller to imminent danger in the case the controller is not looking at the
monitor. All of these reside in a ground station.
Mode C data and the altitude entered manually by a pilot, as well as flight plans and radar
information, among others, are considered inputs to MSAW. Additionally, the system takes in
airport and terrain area information as inputs. Furthermore, there are many random parameters that
MSAW uses that are crucial for some MSAW-related calculations.
52
Outputs of the system are the alerts shown to the controller regarding the possible
hazardous condition of a track. The controller may then tell the pilot to perform a maneuver to
avoid the danger due to low altitude. Aural alarms are considered as part of the environment due to
their importance for safety, that of alerting the controller of important low altitude violations.
In addition to the high-level inputs and outputs above, the system delegates some small
computations to outside functions. One such computation is that of whether an aircrafts is within a
specific area. However, these are considered within the MSAW environment given they are part of
the STARS software.
Environment Assumptions
Several assumptions are made about the environment:
[EA.1] The operator has enough experience and training that he or she will know how to handle an
emergency by giving appropriate instructions to the pilot after an alert is shown by the system.
[E A.2] The pilot will be able to perform the proper maneuver as directed by the controller, or if he
or she senses or sees imminent danger, even if he or she can't communicate with the controller.
[EA.3] There will not be more than 1,350 tracks in the system at any single point in time.
[E A4] Aircraft not being tracked by the system (i.e. has no flight plan) will abide by FAA's Visual
Flight Rules (VFR).
[EA.5] High-integrity communications exist between aircraft and ground station.
[EA.6] The controller uses all information available to him or her to ensure safety, not just MSAW
generated data.
53
Environment Constraints
[EC.1] Altitude data must have a precision of 100 feet or less.
A ssuniptioirA pnxasion ofnw than 100 feet is zdde enrgh so that alerts am na nitigatedconatly.
[E C.2] Altitude data, whether it is from Mode C or the pilot must be either sea level defined or
ground level defined. Ground station and pilot need to use the same reference altitude data.
Ratinomle Ifthe diffemnty defi data is usec4 conatize nurnews suggested by the contnileror
undertaken by thepilot night not h cornt
[EC.3] The behavior of other components of the STARS ATC system must not degrade
performance of MSAW.
Ratiomale Inrfe
wrby oher cwoonas canpnzent MSA W to conatlyalert the contnilerofa low
altitude idation, thus increasingthe d&anxs ofan aaident
[EC.4] The controller must not have any outside distractions not pertinent to the system and his
duties so that alerts have a higher degree of visibility.
A ssunption:Noise or cther similardistrationshindes the peformnx qc
jntdleis.
High Level Functional Goals
High-level functional goals are the basic functions that MSAW provides.
[G.1] MSAW shall provide accurate and timely detection of current or predicted minimum safe
altitude violations to prevent collisions with the surrounding environment, and alert the controller of
the situation.
[G.2] MSAW shall detect minimum safe altitude violations when an aircraft is in a landing approach.
54
System Requirements
Most of the following system requirements came from Raytheon's STARS
System/Subsystem Specification [4], and the reason behind them is that it appeared on the FAA's
NAS-MD-644 [7]. The NAS-MD-644 gives specifications for what MSAW must do and the
principles behind it. This document has been refined for the last 21 years, but the rationale and
assumptions behind its content have not been included in the document. After each requirement
below, I try to provide a rationale for each in the interest of completeness of the intent specification.
If no solid rationale is found, I just point the requirement to the FAA NAS-MD-644. When doing
so, it must be noted that each one must have some purpose behind it but it was not clearly stated in
the available documentation. The high-level system requirements are:
[SR.1] The system shall process all eligible tracks within the system after checking for MSAW
eligibility at a TBD interval of time.
RationaleFAA oquirenz. A dditionally,prxssingall tracks at a tinrly rate ensums lowaltitude
zidatims am detetedfastenogh to he dealt wth wnatdy
[SR.2] Mode C tracked aircraft shall be monitored for conflict with terrain and obstructions.
Rationale A iraft uith Mode C data am the only
s being handled by the system, so they must be dxkeal
for any sidatims, indudingMSA W
[SR.3] The altitude data used by the MSAW function shall be generated from the Mode C reported
altitude or from the manually entered pilot-reported altitude when Mode C data from the aircraft is
not available.
Rationale-Ifnoml radardata is net aailable,the system can still dAk for low altitude wnflicts using the
altitudea pit can ?mnually enter
55
[SR.4] Tracked aircraft shall be monitored along a two-segment path using the track's current and
predicted altitude to compute a vertical profile and compare the profile against an adapted terrain
map (-> H.1, --+ H.3).
[SR.5] The first segment shall begin at the track's current position and extend to a position
predicted using the track's estimated altitude change rate and an adapted time parameter (-+ H.).
[SR.6] The second segment shall begin at the end of the first segment, extend to the altitude of the
highest terrain or to an adapted time parameter, whichever occurs first and project the track's
altitude assuming an adapted climb angle (-- H.1, -+ H.2).
Rationale If an airraftcanma dinb erigh zithin a certainantnt oftin to pvwnt a crlision ze haze
a seris hazard Themfo, ifve dAk for this condii nell aheadof tinr, the wntrdlercan adzise the pilot to
corrtthe situation by peformrng sonr rmruwr.
[SR.7] The resolution of the terrain map shall be adaptable to 0.5 nm, 1 nm, or 2 nm.
Rationale: The FA A specifi 2 mn but the purpcse of this is forjlaibility
[SR.8] The source of terrain map data shall be a grid of government furnished elevation data
oriented to true north x-y offsets referenced to a site specific latitude/longitude location as defined
by the SIFA.
Rationale FAA nqui'nrnr
[SR.9] Tracked aircraft altitude shall be monitored for conflict with terrain or obstructions along
adaptable approach paths (-+ G.1, -+ G.2).
[SR.10] The system shall handle only a TDB number of airport areas for processing approach or
departure violations.
Rationale The pnxessing Icud f the s)stemat a giwn site mst not he cxcssize Therfo, liniting the
nunir(f airportsto be prcessed leads to a nve ef5cient, faster and saferprassingof airraft
56
[SR.11] The system shall be able to determine whether an aircraft is within an airport area, and if
landing, where it is landing (i.e. what runway) (-+ H.1, -+ H.2).
Rationale-The system rust hae a wry ofdeternaning hether an airraftis in low altitude zidationzhen
inside an airportareaand landing 7eo,
it nust be able to know vhat nnzeuy it is landingto aauratelypreit
a zidationfor thatpartialarnnuay aea.
[SR.12] Tracked aircraft altitude on adaptable approach paths shall be monitored for descent below
an adaptable altitude using the track's current and predicted altitude (-+ G.2).
[SR.13] If a track is currently or predicted to be below a minimum safe altitude while coming within
a TBD distance of something in the terrain, the system shall be able to raise an alert (-+ H.1, -* H.2,
-- H.3).
[SR.14] An aural alarm shall sound for a low altitude violation on associated aircraft within an
adaptable geographic volume unless inhibited (-+SRC.1).
Rationale Som? gegraphic egions equie inm'diateattentionso the cntrdlernust be alertd in a diemnt
fashion A uralalanm do just that A dditioaly son
gions
' do
euir't auralalarrm5so any track in thse can
be inhbikedfrom auralalarrms. Therefo, the contrdleruill not be bhed with these alarnszhen it's not e-ssary
(FAA requirenttoo)
[SR. 15] The aural alarm shall be inhibited for low altitude violation on tracks within an adaptable
geographic volume (-+ SRC.1).
Ratioale-See rationaleof SR. 14 (FAA mnnnt too)
[SR.16] Reports of low altitude violations shall be inhibited for tracks within an adaptable
geographic volume (-+ SRC.2).
Ratiomale FAA rnquirrnnt
[SR.17] Tracked departure aircraft in an adaptable departure inhibit geographic volume shall be
suppressed from MSAW alert display if they are departures from the associated airport (-* SRC.2).
57
Rationale-FAA requimnvn
[SR.18] Reports of low altitude violations shall be made available for display (-+ H.1, -+ H.2,
-
H3).
Ratiomnale Contnilets nust know zhen dtw is a lowaltitude zidation
[SR 19] Low altitude alerts displayed at multiple Terminal Controller Positions (TCP) shall be
identical at all positions (-+ G.1).
A ssunption:Dffeent infonmtion at dferent key locations can lead to isconmncationand enonews
handlingjalers.
[SR.20] Once a low altitude alert has been displayed at a TCP, it shall remain until the violation
condition ceases (-+ H.1,
-+
H.2, -+ H.3).
Rationale The cantwilernust know that an alert has not ben nsdiu etso that he or she ny deal ith it
appvprately
[SR21] An alert shall persist for an adapted minimum time duration (-+ G.1).
Rationale-Ezen f the zidation is nsdzd quicly zithwt contnilerinrention, the antnlershould know
abwt it in the casefurtherpmzentize aaionis nquired
[SR.22] Reports of low altitude violations shall be inhibited for tracked aircraft with an adaptable
beacon code, code segment or code block (--> SRC.2).
Rationale FAA
qauinanit
[SR.23] Reports of low altitude violations shall be made available for ATC operational display at the
MCP, and to all those with a need-to-know, SDDs and DRFs (-- G.1).
Ratioale Unknon
[SR.24] The system shall change adapted values when it receives notification that a new value is
available, and the system shall process the track at the next processing interval with the new values
(-+ SRC.5).
58
[SR.25] The minimum safe altitude warning nuisance alert rate shall be less than 4% when the
probability of detection is 45% for warning time more than 30 seconds, and 94% for warning time
more than 0 seconds but less than 30 seconds. (T SRC.2)
Ratioale: No masonforthis ws spafW in the danrntspvzidad Houezer,the nurietspvuidad nigbt
confrom studies that 7-seanrdd ubat lezel <ffalsealerts wnadd wntndles tderate wtht wpvnsing wal alerts
because cffalse-alert induced indnferr
[SR.26] An aircraft with a firmness of less than a TBD firmness value shall not be eligible for
MSAW processing.
Ratioale-FAA nequimEnt Reason unk non
[SR.27] To be eligible for MSAW processing, an aircrafts reported altitude must fall within a TBD
range.
Ratiomnale-FAA mquirenvit Reason unknonu
System Constraints (General and Safety Related)
[C.1] The MSAW function must comply with all applicable FAA and FCC policies, rules, and
philosophies.
Rationle FAA rquest
[SRC.1] The system must not disrupt the pilot, controller and other ATC operations unnecessarily,
including communications.
[SRC.2] The system must work with a low level of unwanted, false and nuisance alarms, so as to
not cause indifference by controllers. A low level is defined as no more than TBD alarms in a TBD
period.
59
Rationale-If them is an ocxssize amrmt cffalse alarnm, the contdler night hewnE indifewnt to then,
causinghim to ignore al alers.
[SRC.3] The design of the controls and displays must not contribute to safety-critical controller
errors.
[SRC.4] Alerts and alert handling must not interfere with the controllers' ability to perform their
normal duties.
Rationale-A n air trafficcantd systen crntains nunyfinctio that aresafety critical. Theefore, the
operatornrst be able to handle a/ens wth relati ease and the aherA TCfitions as zeL
[SRC.5] Input values must be updated as soon as new values are available.
Rationale-Outdated input ulues can mdt in a lowaltitude udation to be rmissed or wported too latefor
the situation to be dealt zith.
System Limitations
Limitations on the systems are accepted hazards that cannot be prevented in the design of
MSAW. The main ones that have been thought of are:
[L.1] MSAW provides no alert for aircraft that have not filed a flight plan.
Rationale-Ifa trad is notflight planassociate, then no airtraffic contwdler is awzm
f its presenx
Thus
te safety ofthe ainraftis no the mponsibility fthe contder
[L.2] MSAW is dependent on the accuracy of input data about each track, primarily on altitude data.
A ssunptiorr Inacuratedata yiels imauratea/ers.
[L.3] The aircraft itself can prevent certain maneuvers from being executed, thus constraining what
the pilot may do after the controller announces a threat.
60
Interface Requirements
The interface provides the link between the processing subsystem and the controller,
allowing the latter to determine any necessary course of action. The basic requirements for the
interface are the following:
[IR.1] The interface shall be able to provide all available information on a track, as given by the
system's input, to the controller.
Rationale In orderto deal wth a lowaltitude zdation qffectizdy dhe contnlernmst haw all pertinent data
on the situationawidable to him
[IR.1.1] Information needs to be identical anywhere it is delivered.
[IR.1.2] Predicted MSA violation points shall be visible to the controller.
[IR.2] The interface shall provide a way for the controller to set the MSAW on and off.
Rationale-MSA W nny he nulfunctioning,uhidh umwd distrac the wntrdler #not disabled In sonr
intanxs, disablingthe MSA Wfurctionfor sonr dinNtanxs zwld ilux the nurirerjffalse alerts.
[IR.3] There shall be a way of telling the controller there is a failure in the system.
Rationale A
failure in the system can lead tofalse alers or missed alerts. If the cuntdler is awnv
of this
situation,he uill know to ignore MSA W alets, and deal wth low altitude zidations in ancther rmnr
[IR.4] Aural alarms shall be audible enough for controller to notice them at all times, and last a
TBD amount of time.
Rationale A uralalanndurationshoud not le too long as to cause indiffeme by the cOntdler
[IR.5] Visual alerts shall be noticeable, in the primary field of view of the controller, and include all
pertinent information about the threat, including an indication that it is an MSAW alert.
61
Ratiomnale Them il be infmtion ab
all airaftin the stordpla)ed on thscen, thus lats of data
for a contnlertoprwxss at any gien tirnr L owaltitude idatior must take a hig pnority to mdw, andthus
shudd be deariydiTguishedfmotherirfomution
[IR.5.1] If the track is off the screen, an adequate notice shall be given to the controller.
Ratiomle Gizen the high pioritylow altitude idations haze, and thefact that wntles can zoom into
dffennt amas of the terrainrmp in his scren, zidating aircraftoutside his feld ofziew ust be notieble so that the
wntdler nny deal wth the situationaaoingly
[IR.6] The interface shall include controls (i.e. keyboard and/or trackball) that are satisfactory to the
controllers.
A ssunption Unsatisfactorywnditio for wntrdles lead to in4etize handlingjalerts.
[IR.7] Aural alarms shall be of a specific duration TBD.
A ssunptiwn 7he contrdlernotics the auralalannzthin this duration tine
[IR.8] Inhibited tracks shall be distinguishable under all conditions from non-inhibited tracks.
Ratiomle-If these types of traks am dstinguishable, the wcntdler canpay num attentionto thcse with
MSA Wprioty, zhid, am the non-inbibted tracks.
[IR.8] There shall be a way provided by the interface to turn off MSAW processing for landing
aircraft.
Ratiomle-FAA nquirenrnt
Hazards List
The following hazards related to low altitude have been identified for aircraft within the air
traffic control system:
62
[H.1] Aircraft falls to an altitude, or its current trajectory will take it to a point in which it violates
minimum separation requirements with something in the environment (i.e. mountain,building,
monument, etc...).
[H.2] Landing approach path too steep for proper landing.
[H.3] Aircraft currently at a safe altitude, but will not be able, or will not have enough time, to
maneuver away from a collision with something in the environment.
Partial Fault Tree
A Preliminary Hazard Analysis, PHA, is used in the early life cycle stages to identify critical
system functions and broad system hazards; it is the heart of any system safety program. It should be
started early so that the information can be used in trade-off studies and selection among design
alternatives. However, this process is not done once: it is iterative, with the PHA being updated as
more information about the design is obtained and as changes are made.
No partial fault tree for the hazards listed was readily available.
Verification and Validation
I am not aware of any specific procedures undertaken for verification and validation other
than the 21 years of refinement of the FAA NAS-MD-644 document Raytheon used as the initial
specification for MSAW.
63
Level II - System Design Principles
General Description
As seen in Figure 1 below, MSAW relies on inputs regarding track data, areas to be checked
and other variables to be used in calculations to run effectively. After processing these inputs, our
system uses internal logic to determine how to react. MSAW takes these inputs to produce a number
of outputs. Not all inputs and outputs are listed on the figure below, but they are all described as
part of the design principles that follow.
The sections of the Level 2 description will describe why we made our design
Figure 1: MSAW Environment with Inputs and Outputs
64
decisions and discuss any basic underlying principles. Level 2 will also describe how the system
requirements will be achieved and how the system constraints will be enforced. The design
presented is only in terms of inputs and outputs, that is, in blackbox terms. For all outputs of the
system, the design describes what combination of inputs determines these outputs.
These design features are traced upwards to the requirements specified in Level I and
downwards to the SpecTRM model in Level III. In this manner, we can see the reasons for some
of these decisions, and how they might be implemented. Those design principles that are not traced
upwards are only part of the design and not specifically used to satisfy safety-critical requirements.
MSAW System Components
The MSAW system is composed of three main modes: Main, Approach, General Terrain,
and Stopped.
Main is the initial mode the system is in at the beginning of processing each track In
Approach mode, minimum safe altitude violations are checked for aircraft on a landing approach.
The General Terrain mode is used when the aircraft is not in a landing approach and is outside an
airport area. The Stopped mode is for when MSAW is turned off.
MSAW Logic
General Principles
[2.1] Aural alarms are turned on when the following conditions are met (I Enable-AuralAlarm): [2.1.1] an alert has been raised, [2.1.2] the given track is not within an aural alarm inhibit
volume (input to the system) (I SR.15), and [2.1.3] the track position falls within an aural alarm
65
volume (input to the system) (t SR.14). [2.1.4] The length of time an aural alarm is to sound is a
TBD input to the system (T IR.4; I Aural-Alarm-Time-Duration).
[2.2] The system will process all tracks in the system one by one at an adapted time interval
TBD
(I SR.1,
1 Scan-Time). An adapted time interval is one that may be changed during the normal
operation of the system. At each interval, [2.2.1] a track will begin in the Main mode.
[2.3] Any variable with an adaptable value may change upon request, and its new value will
be used at the next processing interval (I SR.24).
[2.4] Whenever an alert is raised by any of the operating modes, a message is constructed
with the track information and the alert information. This message is sent to the controller and is
made to all other personnel with a need-to-know, particularly at SDDs and DRFs (I SR. 18, T SR.23;
I Current-Alert,
4 Predicted-Alert, 4 Projected-Alert).
[2.4.1] An Error Status Information Report
indicating the event message is sent to SMC for display by the QvID CSG (T IR.1). [2.4.2] All alert
messages are to be formatted to contain identical MSAW alert data so that all SDDs will display
identical MSAW alerts
(T SR.19, T IR.1.1)
tracked is no longer in violation
(t
and are to remain at these locations until the aircraft being
SR.20). [2.4.3] If a track's display status changes as a result of
entering or exiting an inhibit volume, the system sends an MSAW-CA alert message to all SDDs
alerting them of the display status change (T SR.23, T SR.24). [2.4.4] If a track has an assigned SSR
code that is adapted as MSAW inhibited and is not in a code mismatch condition (via the FP Data),
the track is therefore exempt from MSAW alert display even though it may be in an MSAW alert
situation (T SR.22).
[2.5] An MSAW-CA alert of any type that is to be displayed is only sent if a track is in alert
status, as determined by each mode, for a number of times TBD (input to the system) out of the last
TBD number of processing intervals (input to the system) (1 SRC.2). This ensures that alerts are
raised with good reliability.
66
[2.6] Rather than only using the aircraft's actual altitude value, the system uses that value
minus an adapted amount in all instances where the system is checking whether an aircraft is
violating a minimum safe altitude
(I Alert-Pads).
[2.6.1] This adapted amount is called an alert pad,
and each type of alert can have different alert pad values, which are inputs to the system. [2.6.2]
Alert pads are used to adjust the sensitivity of the algorithm. Reducing the values of these
parameters will reduce the chance of an alert.
[2.7] Suspended flights that are in current or predicted MSAW violation are unsuspended,
clearing the way for an alert to be generated in the same manner as any other alerts (I SR.2, T
SR.13). These are to be treated as normal inputs to MSAW with no designation that they may be
suspended.
[2.8.1] If the alert for the track has been reported for a longer time duration than the given
MSAW alert duration variable (input to the system), a terminate warning message is sent to all
SDDs, and DRFs
(T SR.21,
T SRC.2). [2.8.2] If the alert for the track has not been reported for a
longer time duration than the given MSAW alert duration variable, warning messages are sent to all
SDDs, and DRFs for the track until the reported duration time for the track does exceed the MSAW
alert duration (t SR.18, T SR.23).
Main Mode Logic
[2.9] The system starts in the Main mode at power on. [2.10] All aircraft within the system
are checked for MSAW processing eligibility (1 SR.1; 1 Track-Eligibility).
[2.10.1] To be eligible for approach monitoring or general terrain monitoring, tracks must
have either Mode-C data
(4 Track-Data) or a pilot-reported
manually entered altitude
(4 Manual-
Altitude) available for processing (I SR.2). [2.10.2] Both of these types of data are inputs to the
system and are used to compute possible low altitude violations (I SR.3). [2.10.3] The track firmness
67
(input to system, I Track-Firmness) must be less than a general firmness value, which is a general
system parameter (input to system, I Track-Firmness-Parameter)
(T SR.26).
[2.10.4] In addition,
tracks must not be frozen. The reason for this condition is unknown to me. Therefore, frozen tracks
are considered outside the environment, and for the purposes of this design, they are not fed into
the system. [2.10.5] The track's altitude, Mode C or manually entered altitude, must not be less than
a gross low altitude value (input to system), and not be above a gross high altitude value (input to
system) (t SR.27).
Approach Mode Logic
[2.11] Approach monitoring will determine whether a minimum safe altitude alert needs to
be raised for the given track when it is in a landing approach
(I SR.9).
[2.11.1] Tracks must be eligible for approach MSAW processing. [2.11.1.1] First, tracks must
be outside any approach monitor inhibit area (input to the system, I AMI-Areas), which is also
within the given airport volume
(I SR.16).
[2.11.1.2] Second, an input switch provided to turn
approach monitoring on and off must be turned on (t IR.8;
. AM-ON).
[2.11.2] The Approach mode can raise two types of alerts: a current position alert or a
predicted position alert (--+ 2.5).
[2.12] A current position alert is raised within the Approach mode when the following
conditions are met
(T SR.13; 4 Current-Alert).
[2.12.1] First, the track falls within a runway capture
box (RCB; See Figure 2 on the next page; I RCB-Regions), which is a landing approach volume
linked to a particular airport runway
(I SR.11).
[2.12.1.1] Runway capture boxes are inside airport
areas, so they are inputs to the system, and each system is limited to a TBD number of runway
capture box areas
(T SR.10).
[2.12.1.2] These boxes are divided into two sections, an approach
monitor box and an approach inhibit box (See Figure 2 on the next page). [2.12.1.3] To be
68
considered in an RCB, the track heading must be within a parameter number of degrees TBD of the
runway landing direction (See 8 on Figure 2 on the next page; I Landing-Direction). This parameter
may be different for different RCBs. [2.12.1.4] Additionally, the track is not departing and the RCB
is not enabled as a Departure Inhibit Area (T SR.17; 1 Inhibit-MSAW-Departure). [2.12.1.5] Aircraft
may be in multiple RCBs at a time so a check is made to see which RCB best fits the aircraft's path
of descent. If the aircraft satisfies the angle condition for multiple RCBs, the one with the smallest
angle difference is chosen (I SR. 11).
[2.12.2] Second, the track must be within the approach monitor box for the given runway
capture box, and not the approach inhibit box (T SR.16). [2.12.3] Lastly, the track's altitude is below
the glidescope, which is given by the following equation (I SR.12):
Z < Zg + (b - D) tan(O)
(1)
[2.12.4] Z is the track's altitude (I Position, I Manual-Altitude), 0 is the glideslope angle
(equation for angle is (2) below), and Zg is the altitude of the beginning of the glideslope
(I
Beginning-Glideslope-Altitude). Additionally, D is the distance from the beginning of the runway to
the AMB/AMA boundary
(I D-Distance) and b is the distance
from the track to the beginning of
the runway. These parameters, except the glideslope angle, are inputs to the system and are shown in
Figure 3 on the next page.
69
Appzo ach Inhibit Am a
Approach Moniitor Box
~V
-- - b
-
b
L
Figure 2: Runway Capture Box divided into the AMB and the AIA - Top View.
[2.12.5] R is the runway (input, I X-Coordinate, I Y-Coordinate) and L is the distance from
the beginning of the runway to the end of the AMB (input, I L-Distance). Inside the AMB, T is the
aircraft's position
(I Position), V is the velocity vector
(4 Velocity), and g is the perpendicular
distance from the track to the runway centerline. Also in the AMB, gdot and bdot are the velocity
components of V along g and b respectively. W is the semi-width of the RCB (input, I W-Distance).
[2.13] The glidescope is defined as seen in Figure 3 below. The four corners of the AMB
make up the four corners of the glideslope. Another picture of the glideslope as part of the Runway
Capture Box is shown in Figure 4 on the next page.
70
r
j
Ze
B
:Zg
b
L
Figure 3: Glideslope - Side View. Ze is the altitude at the end of the glideslope (input, 4 EndingGlideslope-Altitude).
Ahirudk Monh r
ALtitude Momntor
Intitc Point
Cutoff Point
Ahtude At
Monitor Cmtott
F
abihiit BoxT
-
Approach Mofo r tox
A
M
Final Approach Fix
Runway
nude at
nit
ate
Approach Violation Area
Figure 4: Another view of the Runway Capture Box divided into its components, and also showing
the Glideslope.
[2.13.1] The glideslope angle is given by the following equation:
71
0
= tan- (
z)
(2)
L-D
[2.14] A predicted position alert is raised within the Approach mode when the following
conditions are met
(T SR.13; 4 Predicted-Alert).
[2.14.1] First, a track is also within a runway capture
box, which must not be a Departure Inhibit Area (DIA) (T SR. 11, T SR.16;
4 RCB-Regions,
I
Inhibit-MSAW-Departure). [2.14.2] Additionally, the tracks current position must not be below the
glidescope, but its future position, determined by the aircraft's landing trajectory, its heading and
velocity with basic physics equations, after an adaptable lookahead time (T(ampap) on equation (3)
below; input to the system, I AM-Prediction-Time) falls below the glidescope (I SR.9, T SR.15).
This condition is satisfied with the following equation (I SR.12):
Z+ZT
<Zg+(b-D-bTPAmp, ) tan(O)
(3)
[2.14.3] This future position must be within the approach monitor box in the runway capture box
and not in the approach inhibit box. This condition is true if both Th and Tg are greater than the
adaptable lookahead time for approach predicted alert situations
parameters are given by the following equations
(4 AM-Prediction-Time).
These
(T SR.16):
Tb = (b-D) If b dot is positive
b
(4)
Tb = (L -b)
-b
If b dot is negative
(5)
Tg = (W+g) If g dot is positive
(6)
Tg = (W-g) If g dot is negative
(7)
-g
72
General Terrain Mode Logic
[2.15] General terrain processing is a mode that determines whether a minimum safe altitude
alert needs to be raised when an aircraft is outside airport areas, in other words, not in a landing
approach
(t SR.9),
monitoring tracks along a two-segment path over a terrin map as described
below (I SR.4). [2.15.1] The General Terrain Monitor can raise three types of alerts: current
position, predicted position and projected position alert (- 2.5).
[2.16] Aircraft that are eligible for general terrain minimum safe altitude violation alerts and
not for approach MSA violation alerts are handled by the General Terrain mode (I SR. 1, T SR.2).
[2.16.1] To be eligible for general terrain alerts, tracks must not be within a general terrain inhibit
region (input to system, I GTI-Areas), which are volumes in the terrain that extend up to an adapted
altitude (t SR.16). [2.16.2] A track must also meet one of the two following conditions. [2.16.2.1]
First, tracks must be ineligible for approach alerts (these are determined only by the Approach
mode), which is true when approach monitoring is turned off (I AM-ON). [2.16.2.2] Or, second,
the track is not within an RCB while in Approach mode
[2.17] A terrain map element
(
(I RCB-Regions).
MSAW-Terrain-Map), provided by the government, is
defined as follows: the terrain surrounding a track is divided into a square grid of an adaptable
resolution between 0.5 nm, 1 nm or 2 nm oriented to true north x-y offsets
(. X-Grid-Number, 4
Y-Grid-Number) referenced to a site specific latitude/longitude location as defined by the SIFA
(See Figure 5 on the next page)
(T SR.7,
minimum safe altitude for the square
T SR.8). Each square has an associated altitude, which is the
(1 SR.8; I MSAW-Terrain-Map.Altitude)).
A terrain map
element is each square with its associated altitude, and the system checks to see if the given aircraft
presently or in the future will violate the minimum safe altitude on any of the squares of this grid
(I
SR.13). [2.18] The tracks position is defined, not as its exact position in space, but as two points at a
distance B from it, one to the right and one to the left (See Figure 5 on the next page, points Al and
73
A2 are those right and left points). [2.18.1] This allows for the determination of whether a track
comes laterally within the space of a terrain map element (I SR. 13). They are like cushion pads
around the aircraft so that it doesn't get too close to any element on the terrain. [2.18.2] The points
are perpendicular to the trajectory of the aircraft, and are at a distance given by the following
equation:
B=T*
R 2 +r 2A
2
(8)
[2.18.3] All of these parameters (T,R, r, and A) are inputs to the system and defined as
follows: T, coefficient to account for other factors (I Other-Factors-Coefficient); R, range standard
deviation of the sensor providing the data
deviation of the sensor
(I Range-Standard-Deviation);
(I Azimuth-Standard-Deviation);
A, azimuth standard
r, track range from sensor from which data
was received (I Track-Range). [2.18.4] The latter variable is due to the fact that as the track moves
away from the radar the accuracy of the tracks coordinate data decreases. Therefore, it is safer to
give it more of a cushion in this instance (i.e. have a larger B).
B33
B14
815
[316
B17
DI
81.
DZ
7
37
38
69
5
4
B311.11
B10
B.112
AZ
B1
B2
83
34
[5
B6
Figure 5: Example of General Terrain Map divided into Elements. A is the aircrafts current position.
V is the velocity. Al and A2 are the left and right position points respectively. Al->C1 and A2->C2
are the left and right predicted lines of flight respectively (described below). C1+)D1 and C2-*D2
are the left and right projected lines of flight respectively (described below).
74
[2.19] For a current position alert to be raised in this mode, any of the track's current
position points must be within the space of the terrain map element each track position point is
currently in (I SR.13; 1 Current-Alert). [2.19.1] If both track position points are above the current
terrain map element, the aircraft is flying at a current safe altitude, and therefore no alert is raised.
[2.20] A predicted position alert is raised in the following manner (I Predicted-Alert).
[2.20.1] First, two predicted lines of flight are created given the aircraft's two current position points
(the right and left one as described above), speed, trajectory and acceleration using basic physics
mechanics equations (T SR.5). The predicted lines of flight are created from the tracks current
position up to a future point in time determined by an input look ahead time (See Figure 5 on the
previous page and Figure 6 on the next page) (t SR.5; I GT-Prediction-Time-I). [2.20.2] The
predicted position alert is raised if any of the two predicted lines of flight is within the space, below,
a terrain map element each may pass through
(I SR.13).
[2.20.2.1] An external sectorization
function to MSAW takes in the current position points, the track's velocity, and end points of the
segment and it returns a list of tiles the segment goes through. MSAW feeds it the inputs, and
receives the outputs for further processing (See Section B.10.4 of [5]). [2.20.2.2] The General
Terrain mode then takes this list of tiles and checks whether the aircraft is below the minimum safe
altitude of each of the tiles at the time the track is to pass through that tile.
[2.21] The last type of alert is the projected position alert
(4 Projected-Alert).
[2.21.1] Two
projected lines of flight are created similarly to the predicted lines of flight. However, the projected
lines begin at the end of their respective right and left predicted lines. The other difference is that
the projected lines either rise from this point at an adaptable angle of ascent (input to system, I
Ascent-Angle) to a point given by another look ahead time (4 GT-Prediction-Time-II), or rise at an
angle that the track is already rising at if this angle is larger than the adaptable angle of ascent (T
75
SR.6). See Figure 6 below. [2.21.2] If any projected lines of flight are within a terrain map element
space each may pass through, even with the angle of ascent, a projected position alert is raised (I
SR.13). [2.21.2.1] This check is done in the same manner as for the predicted lines of flight (-+
2.20.2.1,
-+
2.20.2.2).
A
D
Figure 6: Side View of General Terrain Map. Point A is the aircraft's current position. Point B is the
end of the predicted lines of flight and beginning of projected lines of flight. Point D is a point of
projection alert. Point F is the end of the projected lines of flight. (D is the adapted ascent angle (]
Ascent-Angle).
[2.22] If an alert is generated when in General Terrain mode, the mode is changed to
Approach at the next interval. [2.23] If no alert is raised by the track, the mode is changed to the
Main mode.
Performance Monitoring
There were no specifications available on how the system will monitor performance.
76
Controller-MSAW Interface
The interface between the controller and the MSAW system is designed, as part of the
broader interface, in the following fashion (CMID can refer to Controller-MSAW Interface Design):
[2.24] Tracks and data blocks for aircraft in current or predicted MSAW violation are displayed on
the screen in flashing red color, the Alert color. (I IR.1, T IR.5)
[2.25] The abbreviation "LA" appears on the top of the line of the track's data block
(I IR.5)
[2.26] For predicted MSAW alerts, CIvD.1 and CID.2 apply, but in addition, a vector is drawn
from the current point of the track to the point of predicted violation. (I IR. 1.2)
[2.27] If the point of violation is currently off the controller's screen, the vector is drawn to the edge
of the screen and the track's ACID or beacon code is displayed next to the vector. (T IR.5. 1)
[2.28] If a track in MSAW violation is currently off the controller's screen, the track's entry on the
Off-Screen List is highlighted in red. (T IR.5.1)
[2.29] The abbreviations "XL" and "XA" are shown for tracks in which MSAW alerts are disabled.
(T IR.8)
Testing and Validation
There is no information on how the design principles contained herein were tested and
validated. Raytheon tool the NAS-MD-644 and implemented what was contained there. The reasons
for the principles in the NAS-MD-644 are also not available.
77
Level III - Blackbox Behavior
Environment
This section would include the behavior of non-MSAW (external) components that are part
of the already defined environment, including failure behavior if necessary. Given that the MSAW
environment, as defined in Level I, does not include any external components as it only receiving
certain crucial inputs, nothing is included here.
Controller-MSAW Interface
Section 2.15.3 of [6] would be included here.
Communication and Interfaces
Included in this section is the input and output messages to MSAW.
Input Messages: The following messages are inputs to the system. Some of these are separated
into several variables.
MSAW-ON
(
)
MSAW-OFF(
}
Approach-Monitoring-ON
(
)
Approach-Monitoring-OFF
(
78
)
Track-Info (
Track-ID,
Position,
Velocity,
Acceleration,
Manual-Altitude,
Track-Firmness
)
Other-System-Parameters-Info (
Scan-Time,
Aural-Alarm-Time-Duration,
MSAW-Gross-High-Altitude,
MSAW-Gross-Low-Altitude
Track-Firmness-Parameter
)
Alert-Pads-Info (
GTCAP,
GTPAP,
GTProAP,
AMCAP,
AMPAP
Lookahead-Times-Info (
GT-Prediction-Time-I,
GT-Prediction-Time-II,
AM-Prediction-Time
)
Lines-of-Flight-Parameters-Info (
Range-Standard-Deviation,
Azimuth-Standard-Deviation,
Other-Factors-Coefficient,
Track-Range,
Ascent-Angle
)
Type- 1/2-Regions (
RCB-Name,
Airport-Name,
Runway-Name,
X-Coordinate,
Y-Coordinate,
L-Distance,
79
D-Distance,
W-Distance,
Landing-Direction,
Runway-Length,
Beginning- Glideslope-Altitude,
Ending-Glideslope-Altitude,
Arrival-Angle,
Inhibit-MSAW-Departure
)
MSAW-General-Terrain-Inhibit-Areas
GTIA-Region-Name,
Geometry,
Point-Type,
Shape,
Enable-GTI-Area
(
MSAW-Approach-Monitor-Inhibit-Areas
AMIA-Region-Name,
Geometry,
Point-Type,
Shape
(
)
IFR-Aural-Alarm-Inhibit-Areas
AAIA-Region-Name,
Geometry,
Point-Type,
Shape,
Inhibit-MSAW
(
Remote-Aural-Alarm-Areas (
RAAA-Region-Name,
Geometry,
Point-Type,
Shape,
Enable-MSAW
)
Terrain-Map-Info (
TME-Name,
X-Grid-Number,
Y-Grid-Number,
Altitude
80
)
Output Messages:
Current-Alert
(
)
Predicted-Alert(
Projected-Alert(
)
Enable-Aural-Alarm(
)
MSAW Behavior
Following is the SpecTRM-RL specification of the MSAW function. It is correct to the best
of the information provided. There is only one thing that is currently missing and that is design
principle [2.5]. In this model, alerts are raised every time their conditions are satisfied. Additionally,
as mentioned before, frozen tracks are not input into MSAW, so they stay exempt from MSAW
processing.
81
I
Modes
Control-Mode(i)
Possible Values: {Main, Approach, General-Terrain, Stopped}
Description: The system starts in Main. It transitions to Approach if the variable Approach-Monitoring-ON is true. If
not, it goes to General-Terrain. The system also goes to General-Terrain if while in Main that variable is
false. If while in Approach, the track is inside an airport area but is not in alert status, it will return to Main.
Additionally, if while in Approach, the track is within an AMIA or a DIA, it returns to Main. When in
General-Terrain, it will automatically transition to Main mode after processing the track within it. The
system transitions to Stopped when MSAW is turned off.
Comments:
References: T2.2.1,
T 2.9, T 2.11, T 2.11.1, t 2.15
Appears In:
Definition
= Main
Previous (Control-Mode(i)) = Approach
Previous (Control-Mode(i)) = General-Terrain
*
T
T
T
*
*
*
*
*
*
T
T
T
T
Received MSAW-ON
Received MSAW-OFF
T
F
F
F
F
F
F
F
F
F
F
F
F
F
F
F
AM-ON
Track-in-Approach-Monitoring-Inhibit-Area(i)
Track-in-DIA(i)
Track-in-RCB(i)
Sent Current-Alert
Sent Predicted-Alert
Sent Projected-Alert
*
*
*
*
*
F
F
F
*
T
*
*
*
*
*
*
*
*
T
*
*
*
*
*
*
*
*
T
*
*
*
*
*
F
*
*
*
*
*
*
F
*
*
*
*
T*
*
T
*
FT
F
*
F
*
= Approach
Previous (Control-Mode(i)) = Main
Previous (Control-Mode(i)) = General-Terrain
T
*
*
*
T
T
T
Received MSAW-OFF
AM-ON
Track-in-Approach-Monitoring-Inhibit-Area(i)
F
T
F
F
T
F
F
T
F
Sent Current-Alert
Sent Predicted-Alert
Sent Projected-Alert
*
F
T
F
T
*
*
*
*
T
*
*
*T
= General-Terrain
Previous (Control-Mode(i)) = Main
Previous (Control-Mode(i)) = Approach
Track-in-RCB(i)
T
*
*
Received MSAW-OFF
*
T
F
F
AM-ON
F
*
*
82
Received MSAW-OFF
=
Stopped
83
State Value
AM-ON
Obsolescence:
Exception Handling:
Description: This variable states whether a track is to be processed for approach alerts or not. It is on by default at
startup, but can be turned on and off by the controller during the normal operation of MSAW.
Comments:
References:
T 2.11.1.2, T 2.16.2.1
Appears In:
Definition
= True
Received Approach-Monitoring-ON
Received MSAW-ON
T
*
*
T
= False
Received Approach-Monitoring-OFF
T
= Unknown
Received MSAW-OFF
T
84
Output Message
Current-Alert
Destination: Terminal Controller Positions (TCP), Situation Data Displays (SDD), Data Recording Facilities (DRF) and
Control and Monitoring Displays (CMD)
Acceptable Values: True/False
Initiation Delay:
Completion Deadline:
Exception Handling:
Feedback Information:
Variables:
Values
Relationship:
Min. time (latency):
Max. time:
Exception Handling:
Reversed By:
Description: This output message alerts the controller that an aircraft is in current low altitude warning. The message
contains all relevant alert information such as track position and altitude.
Comments:
References:
T 2.4, t
2.11.2,
T 2.12, t 2.19
Contents
Triggering Condition
Control-Mode(i) = Approach
Control-Mode(i) = General-Terrain
Track-Eligibility(i)
Track-in-Approach-Monitor-Inhibit-Area(i)
Track-below-Ghdeslope(i)
Track-in-General-Terrain-Inhibit-Region(i)
Track-in-Terrain-Map-Element(i)
T
F
T
F
T
*
*
85
F
T
T
*
_
F
T
Output Message
Predicted-Alert
Destination: Terminal Controller Positions (TCP), Situation Data Displays (SDD), Data Recording Facilities (DRF) and
Control and Monitoring Displays (CMD)
Acceptable Values: True/False
Initiation Delay:
Completion Deadline:
Exception Handling:
Feedback Information:
Variables:
Values
Relationship:
Min. time (latency):
Max. time:
Exception Handling:
Reversed By:
Description: This output message alerts the controller that an aircraft is in a predicted low altitude warning. The
message contains all relevant alert information such as track position and altitude.
Comments:
References: T 2.4,
T 2.11.2, T 2.14, T 2.20
Contents
Triggering Condition
Control-Mode(i) = Approach
Control-Mode i = General-Terrain
Track-Eligibility(i)
Track-in-Approach-Monitor-Inhibit-Area(i)
Track-below-Glideslope(i)
Track-Predicted-Position-below-Glideslope(i)
Track-in-General-Terrain-Inhibit-Region(i)
Predicted-Lines-of-Flight-in-Terrain-Map-Element(i)
T
F
T
F
F
T
F
T
T
*
*
F
T
*
86
*
*
i
Output Message
I
Projected-Alert
Destination: Terminal Controller Positions (TCP), Situation Data Displays (SDD), Data Recording Facilities (DRF) and
Control and Monitoring Displays (CMD)
Acceptable Values: True/False
Initiation Delay:
Completion Deadline:
Exception Handling:
Feedback Information:
Variables:
Values
Relationship:
Min. time (latency):
Max. time:
Exception Handling:
Reversed By:
Description: This output message alerts the controller that an aircraft is in a projected low altitude warning. The
message contains all relevant alert information such as track position and altitude.
Comments:
References:
1 2.4, T 2.21
Contents
Triggering Condition
Control-Mode(i) = General-Terrain
Track-Eligibility(i)
Track-in-General-Terrain-Inhibit-Region(i)
Projected-Lines-of-Flight-in-Terrain-Map-Element(i)
T
T
F
T
87
Output Message
Enable-Aural-Alarm
Destination: Situation Data Display's (SDDs) Aural Alarm unit, which creates the alarm sound.
Acceptable Values: True/False
Initiation Delay:
Completion Deadline:
Exception Handling:
Feedback Information:
Variables:
Values
Relationship:
Min. time (latency):
Max. time:
Exception Handling:
Reversed By:
Description: This output message states whether an aural alarm is to sound when an alert is raised.
Comments:
References: 12.1
Contents
Triggering Condition
Control-Mode(i) = Approach
T
T
*
*
*
Control-Mode(i) = General-Terrain
Sent Current-Alert
*
*
T
T
T
T
*
*
T
*
*
Sent Predicted-Alert
T
*
T
*
Sent Projected-Alert
*
*
*
Track-in-Aural-Alarm-Inhibit-Volume(i)
Track-in-Aural-Alarm-Volume(i)
F
T
F
T
F
T
F
T
T
F
T
88
Macro
Track-Eligibility(i)
Description: This macro simple determines whether a track is eligible for MSAW processing. The track must have
Mode-C data available or a pilot manually entered altitude to be eligible. This data must be current. In
other words, it can't be obsolete. Additionally, the tracks firmness must not be below the general track
firmness parameter, and their altitude must be within the Gross Altitude parameters.
Comments:
References:
T 2.10
Appears In: Current-Alert, Predicted-Alert and Projected-Alert
Definition
Track-Data(i).Position= Obsolete
Track-Data(i).Manual-Altitude = Obsolete
Track-Data(i).Track-Firmness < Track-Firmness-Parameter
Other-System-Parameters.MSAW-Gross-Low-Altitude <= Track-Data(1).Position(z) <= OtherSystem-Parameters.MSAW-Gross-High-Altitude
Other-System-Parameters.MSAW-Gross-Low-Altitude <= Track-Data(1).Manual-Altitude <=
Other-System-Parameters.MSAW-Gross-igh-Altitude
89
F
*
F
T
*
F
F
F
T
*
F
*
F
F
*
*
*
*
T
T
Function
i
L
Track-in-DIA(track)
Description: This function determines whether the given track is inside a Departure Inhibit Area (DIA). It also
determines whether the track is departing. If both are true, it returns a true.
Comments:
References:
T 2.14.1
Appears In: Control-Mode
Definition
90
Function
Track-in-RCB (track)
Description: This function determines whether the given track is inside a Runway Capture Box (RCB).
Comments:
References:
1 2.14.1
Appears In: Control-Mode
Definition
91
Function
Track-below-Glideslope(track)
Description: This function takes in as input the track that MSAW is currently processing and determines in which
Runway Capture Boxes (RCB) it is currently in. If the track is in a Departure Inhibit Area inside an RCB,
that RCB is not considered further. The function then determines which RCB does the track fit best if it is
within more than one RCB. The function then takes this best fit RCB and if the track is in the Approach
Monitor Box of that RCB, it determines whether the tracks current position is below the.glideslope of the
given RCB.
Comments:
References:
T 2.6, 1 2.12.1, 1 2.12.2, T 2.12.3, 1 2.14.1
Appears In: Current-Alert and Predicted-Alert
Definition
The function first determines which RCB the track is in, say
performed:
Ze = RCB-Regions(j).Ending-Glideslope-Altitude
Zg = RCB-Regions(j).Beginning-Glideslope-Altitude
L = RCB-Regions(j).L-Distance
D = RCB-Regionsj).D-Distance
b = Distance from track to beginning of runway
AMCAP = Alert-Pads.AMCAP
0=
tan(Ze -Zg
L-D
Z + AMCAP < Zg + (b - D) tan(O)
92
j. Afterwards,
the following calculations are
Function
Track-in-Terrain-Map-Element(track)
Description: This function takes in a track and determines whether, given the track's current position, it is below its
current terrain map element square.
Comments:
References:
T 2.6, T 2.19
Appears In: Current-Alert
Definition
To calculate whether this violation is occurring, this function simply takes the tracks current position points, as
given by 2.18.2, and checks whether they are below the present terrain map element square (input). First, the following
algorithm determines in which grid tile the track is in. Afterwards, it checks whether the track's altitude is below that
tile's altitude as given by MSAW-Terrain-Map(i).Altitude. The algorithm, which appears in Section B.10.4.1.2 of [5], is:
Input:
1. Given point (XY) in the system coordinate and within the mosaic tile structure.
2. The adaptation data
GTIN_X_COR: Number of grid tile along the X coordinate
TL : The size of grid tile.
X_root, Yroot: The system coordinate of the grid tile structure respect to the system plane
origin.
Output:
1. The grid tile ID
2. The corresponding number in X coordinate, ID_X
3. The corresponding number in Y coordinate, IDY
Process:
Step 1: Compute
IDX = Integer((X-Xroot)/TL)
IDY = Integer((Y-Y-root)/TL)
Step 2: Compute
ID = IDY * GT_IN_X_COR + ID_X
93
Function
Track-Predicted-Position-below-Glideslope(track)
Description: This function takes in as input the track that MSAW is currently processing and determines in which
Runway Capture Boxes (RCB) it is currently in. If the track is in a Departure Inhibit Area inside an RCB,
that RCB is not considered further. The function then determines which RCB does the track fit best if it is
within more than one RCB. Then, the function performs two things. It determines whether the track's
predicted position given the lookahead time is below the given RCB's glideslope, and whether the track's
predicted position is inside the Approach Monitor Box (AMB) area of the RCB. If both are true, the
function returns a True. Otherwise, a False is returned.
Comments:
References: 12.6,
1 2.14.1,
T 2.14.2, T 2.14.3
Appears In: Predicted-Alert
Definition
The function first determines which RCB the track is in, say
performed:
j. Afterwards, the
following calculations are
Ze = RCB-Regions(j).Ending-Glideslope-Altitude
Zg = RCB-Regions(j).Beginning-Glideslope-Altitude
L = RCB-Regions(j).L-Distance
D RCB-Regions(j).D-Distance
b = Distance from track to beginning of runway
Z dot = z component of Track-Data(track).Velocity
b dot velocity component along b
T(ampap) = Lookahead-Times.AM-Prediction-Time
AMPAP = Alert-Pads.AMPAP
0=
Ze - Zg)
tan 1 ( L-D
+AMPAP<Zg+(b-D-bTAp
Z+ZT,
)tan()
Th and Tg must be greater than Lookahead-Times.AM-Prediction-Time for the track's predicted position to be
within the AMB of the given RCB. Th and Tg are given by the following equations:
Tb = (b
-D)
If b dot is positive
b
Tb = (L - b)
-b
If b dot is negative
94
(W + g)
Tg-=
g
Tg = (W-g)
-9
If g dot is positive
If g dot is negative
95
Function
Predicted-Lines-of-Flight-in-Terrain-Map-Element(track)
Description: This function takes in a track, creates the track's predicted lines of flight, and then determines whether at
any point they fall below a terrain map element square.
Comments:
References: T 2.6, T 2.20.2
Appears In: Predicted-Alert
Definition
This function uses the algorithm of B.10.4.1.3 of [5] to determine low altitude violations. This algorithm takes
in a track's current position points and their corresponding end points after Lookahead-Times.GT-Prediction-Time-I
and determines all the tiles this segment passes. Position points are determined with:
B=T* R 2 +r2 A 2
T = Lines-of-Flight-Parameters. Other-Factors-Coefficient
R = Lines-of-Flight-Parameters.Range-Standard-Deviation
A = Lines-of-Flight-Parameters.Azimuth-Standard-Deviation
r = Lines-of-Flight-Parameters.Track-Range
The algorithm that returns the grid tiles follows. After these tiles are determined, the predicted altitude of the
tiles is compared to the altitude component of the tiles to see if the track will violate a minimum safe altitude. The
algorithm is:
Input:
1. ID__XlID_Y : The corresponding number in X,Y coordinate for point (X1,Y1)
2. ID_X2,ID_Y2: The corresponding number in XY coordinate for point (X2,Y2)
3. Vx,Vy : velocity or Delta value (X2-Xl,Y2-Yl)
4. X1,Y1 : the starting point of the segment.
5. ID(1),ID(2) : The corresponding grid tiles for ponit (X1,Y1) and (X2,Y2)
6. NGT : Number of grid tile, initialize to 2
7. The adaptation data
GTIN_X_COR: Number of grid tile along the X coordinate
TL : The size of grid tile.
X_root, Yroot : The system coordinate of the grid tile structure respect to the system plane
origin.
Output:
1. ID :The list of grid tiles (No duplicated).
2. NGT: Number of grid tiles. (No duplicated)
Process:
Step 1: Set index K = NGT
Step 2: Perform computation based on the following cases:
For (ID_X1 = IDX2) and (ID_Y1 = IDY2) : No processing is required.
96
For (ID_X1 = IDX2) and (ID Y /= IDY2):
Loop
If (Vy >0) then
ID(K+1) =ID(K) - GTIN_X_COR
Else
ID(K+1) =ID(K) +GTIN_ X_COR
K =K +1
Until ID(K) = ID(1)
For (ID_X1
IDX2) and (IDY1 = IDY2):
Loop
If (Vx >0) then
ID(K +1) = ID(K) - I
Else
ID(K+1) = ID(K) +1
K =K +1
Until ID(K) = ID(1)
For (IDX1 /= IDX2) and (ID Y1 / = IDY2):
If (ABS(Vx) . ABS(Vy)) then
SLOPE = Vy/Vx
If (Vx . 0) then
STEP = 1
TEMP = ID_X1 + STEP
Else
STEP =- 1
TEMP =ID_X1
Value = (TEMP * TL-(X1-X root)) * SLOPE + Y1-Yroot
DET = integer(Value/TL)
ID(K+1) = DET * GTINX_COR + TEMP
K =K +1
ID(K+1) =ID(K) -1
K =K + 1
While TEMP /=IDX2 and TEMP-1 /= IDX2
TEMP = TEMP + STEP
Value = Value + TL * SLOPE * STEP
DET = integer(Value/TL)
ID(K+1) = DET * GTIN_X_COR +TEMP
K =K + 1
ID(K+1) = ID(K) - 1
K=K+1
End While
Else
SLOPE = Vx/Vy
If (Vy. 0) then
STEP =1
TEMP =IDY1 +STEP
Else
STEP = - 1
TEMP =IDY1
Value = (TEMP * TL-(Yl-Y root)) * SLOPE + X1 - X root
DET = integer(Value/TL)
ID(K+1) = DET + GTIN_X_COR " TEMP
K =K +1
ID(K+1) = ID(K) - GTIN_X_COR
K =K +1
While TEMP /=IDY2 and TEMP-1 /=IDY2
TEMP = TEMP + STEP
Value = Value + T * SLOPE * STEP
97
DET = integer(Value/TL)
ID(K+1) = DET + GTIN X COR * TEMP
K =K +1
ID(K+1) = ID(K) - GTIN X_COR
K =K +1
End While
Step 3: Delete the duplicated grid tile ID
3-1:SetL = 1
3-2 : For I = 2,K
3-3 : For J = 1,L
If (ID(I) = ID()) Go to Step 3-4
End inner loop
ID(L+1) = ID(I)
L =L +1
3-4 : End outer loop
3-5 : Set NGT = L
98
Function
Projected-Lines-of-Flight-in-Terrain-Map-Element(track)
Description: This function takes in a track, creates the track's projected lines of flight, and then determines whether at
any point they fall below a terrain map element square.
Comments:
References:
T 2.6, T 2.21.2
Appears In: Projected-Alert
Definition
This function does exactly the same as Predicted-Lines-of-Flight-in-Terrain-Map-Element(track) but using the
initial position points of the track as those at the end of the predicted lines of flight as given by GT-Prediction-Time-I.
The end position points for this function are given by GT-Prediction-Time-II.
99
Function
Track-in-Approach-Monitor-Inhibit-Area(track)
Description: This function determines whether the given track is within any Approach Monitor Inhibit Area.
Comments:
References: T 2.11.1.1
Appears In: Current-Alert and Predicted-Alert
Definition
This function does an extensive search of all Approach Monitor Inhibit Areas that are in AMI-Areas(i). The
track information of Track-Data(track) is used for these calculations. The following algorithm for determining this was
directly taken from Section B.10.4.1.1 of [5]:
Input:
1. system coordinate (X,Y)
2. starting and ending address (S1,S2) of the given polygon vertex information data base
Output:
IN/OUT
Process:
Step 1 : Get X1, Y1, Typel from the database at address S1, Initialize COUNT to zero
Step 2 : Increment S1 by 3
Step 3 : Check S1 against S2.
If S1 + 3 > S2 then go to step 7
Step 4: Based on the value of Typel, fetch the following data:
For Circle type
Get Xc, Yc, Rc from the database at address S1
For Arc type
Get Xc, Yc, Rc from the database at address S1
Increment S1 by 3
Get X2, Y2, Type2 from the database at address S1
For straight line type
Get X2, Y2, Type2 from the database at address S1
Step 5 : Based on the value of Typel, perform the following computations:
For Circle type
Compute
RSLT = (X - Xc)2 + (Y - Yc)2 - Rc * Rc
If RSLT < 0 then set COUNT to 1
Goto Step 7
For straight line type
If (Y1 > Y2) and (Y1 . Y > Y2)
Compute
RSLT = (X2 - X1) * (Y - Y1) - (Y2 - Y1) * (X - X1)
100
If the result 3 zero then
Increment COUNT by 1
If (Y1 <Y2) and (Y2. Y >Y1) then
Compute
RSLT = (X2 - X1) * (Y - Y1) - (Y2 - Y1) * (X - X1)
If the result . zero then
Increment COUNT by 1
For Arc type
If (Y1 . Y2) and Type1 = clockwise then
Type1 = Right arc
Max_X = X1
Max_Y = Y1
Min_X = X2
MinY = Y2
If (Y1 . Y2) and Typel = counter-clockwise then
Type1 = Left arc
Max_X = X1
Max_Y = Y1
Min_X = X2
Min_Y = Y2
If (Y1 <Y2) and Type1 = clockwise then
Type1 = Left arc
MaxX = X2
Max_Y = Y2
Min_X = X1
MinY = Y1
If (Y1 <Y2) and Typel = counter-clockwise then
Type1
=
Right arc
Max_X = X2
MaxY = Y2
Min_X = X1
Min_Y = Y1
For Left arc type:
If (Yc+Rc >Y>MaxY) then
If (MaxX >Xc) then
Compute
RSLT = (X - Xc)2 + (Y - Yc)2 - Rc *Rc
If the result 3 zero Then
Increment COUNT by 1
If MinY. Y >Yc - Rc) then
If MinX >Xc) then
Compute
RSLT = (X - Xc)2 + (Y - Yc)2 - Rc * Rc
If the result 3 zero Then
Increment COUNT by 1
If (MaxY . Y >Min Y) then
Compute
RSLT = (Max x - Min x) * (Y - Miny) - (Maxy - Miny) * (X - Min x)
If the result . zero then
Compute
RSLT = (X - Xc)2 + (Y - Yc)2 - Rc * Rc
If RSLT. zero
Increment COUNT by 1
For Right arc type:
If (Yc +Rc >Y >MaxY) then
If (MaxX <Xc) then
Compute
101
RSLT = (X - Xc)2 + (Y If the result 3 zero Then
Increment COUNT by 1
If (Min_Y. Y >Yc - Rc) then
If (MinX <Xc) then
Compute
RSLT = (X - Xc)2 + (Y If the result 3 zero Then
Increment COUNT by 1
If (Max_Y. Y >MinY) then
Compute
RSLT = (Max x - Min x)
If the result . zero then
Increment COUNT by 1
Else
Compute
RSLT = (X - Xc)2 + (Y If RSLT 3 zero
Increment COUNT by 1
Yc)2 - Rc * Rc
Yc)2 - Rc *Rc
* (Y - Miny) - (Maxy - Miny) * (X - Minx)
Yc)2 - Rc *Rc
Step 6: Set X1 = X2
Y1 =Y2
Type1 = Type2
Then Go back to Step 2
Step 7 : If COUNT is even Then return NO
Else return Yes.
102
Function
Track-in-General-Terrain-Inhibit-Region(track)
Description: This function determines whether the given track is within any General Terrain Inhibit Region.
Comments:
References:
t 2.16.1
Appears In: Current-Alert, Predicted-Alert and Projected-Alert
Definition
This uses the same algorithm as in Track-in-Approach-Monitor-Inhibit-Area(track) but using GTI-Areas(i).
103
Function
Track-in-Aural-Alarm-Inhibit-Volume(track)
Description: This function determines whether the given track is within any Aural Alarm Inhibit Volume.
Comments:
References: T 2.1.2
Appears In: Enable-Aural-Alarm
Definition
This uses the same algorithm as in Track-in-Approach-Monitor-Inhibit-Area(track) but using AAI-Areas(i).
104
I
Function
Track-in-Aural-Alarm-Volume(track)
Description: This function determines whether the given track is within any Aural Alarm Volume.
Comments:
References: T 2.1.3
Appears In: Enable-Aural-Alarm
Definition
This uses the same algorithm as in Track-in-Approach-Monitor-Inhibit-Area(track) but using RAA-Areas(i).
105
Input Value
Track-Data(i)
IL> Track-ID
Source:
Type: characters
Possible Values (Expected Range): {102, 1902, 008, etc}
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence:
Exception Handling:
Description: This input is the ID number of an aircraft in the system. This ID will be used for checking whether the
corresponding aircraft is in a low altitude alert condition or not.
Comments:
References:
T 2.10.1
Appears In:
Definition
= FIELD (Track-ID in Track-Info message)
T
Received Track-Info
PREV Flght-ID = Obsolete
T
= PREV Track-ID
= Obsolete
106
Input Value
Track-Data(i)
I>
Position
Source:
Type: integer
Possible Values (Expected Range):
{
... x; ... y; ... z}
Exception Handling:
Units: {Nautical Miles (NM), NM, feet}
Granularity: {1 NM, 1 NM, 1 foot}
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence:
Exception Handling:
Description: This input value is the XYZ position of the given aircraft in space (Z is the altitude).
Comments:
References:
T 2.10.1, T 2.12.4, T 2.12.5
Appears In:
Definition
FIELD (Position in Track-Info message)
Received Track-Info
T
Track-Info.Track-ID = Track-Data(i).Track-ID
T
= PREV Position
= Obsolete
107
Input Value
Track-Data(i)
IL> Velocity
Source:
Type: integer
Possible Values (Expected Range):
{
x; ... y;
z}
Exception Handling:
Units: feet/ second
Granularity: 1 foot/second
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence:
Exception Handling:
Description: This value is the velocity of the track in all directions XYZ.
Comments:
References: T 2.10.1, T 2.12.5
Appears In:
Definition
= FIELD (Velocity in Track-Info message)
Received Track-Info
T
Track-Info.Track-ID = Track-Data(i).Track-ID
T
= PREV Velocity
= Obsolete
108
Input Value
Track-Data(i)
LL> Acceleration
Source:
Type: integer
Possible Values (Expected Range):
{ ...
y; ... z}
Exception Handling:
Units: feet/seconds 2
Granularity: 1 foot/seconds 2
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence:
Exception Handling:
Description: This input gives the acceleration of the given aircraft, if any, in all directions.
Comments:
References:
T 2.10.1
Appears In:
Definition
= FIELD (Acceleration in Track-Info message)
Received Track-Info
Track-Info.Track-ID = Track-Data(i).Track-ID
= PREV Acceleration
= Obsolete
109
T
T
Input Value
Track-Data(i)
LL> Manual-Altitude
Source:
Type: integer
Possible Values (Expected Range): { ... z}
Exception Handling:
Units: feet
Granularity: 1 foot
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence:
Exception Handling:
Description: This is the pilot manually entered altitude, if any, that is used if regular track data (Mode C) is not available
for processing and detecting possible MSAW alerts.
Comments:
References:
T 2.10.1, T 2.12.4
Appears In:
Definition
FIELD (Manual-Altitude in Track-Info message)
Received Track-Info
Track-Info.Track-ID = Track-Data(i).Track-ID
= PREV Manual-Altitude
= Obsolete
110
T
T
Input Value
Track-Data(i)
1> Track-Firmness
Source:
Type: integer
Possible Values (Expected Range): Unknown
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence:
Exception Handling:
Description: If this value is less than the Track-Firmness-Parameter, the given track is not eligible for MSAW
processing.
Comments:
References: T 2.10.3
Appears In:
Definition
= FIELD (Track-Firmness in Track-Info message)
Received Track-Info
Track-Info.Track-ID = Track-Data(i).Track-ID
= PREV Track-Firmness
= Obsolete
111
T
T
Input Value
Other-System-Parameters
Ik> Scan-Time
Source:
Type: decimal
Possible Values (Expected Range): {2 ... 14}
Exception Handling:
Units: seconds
Granularity: 0.01 seconds
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until new value is input to the system via the Other-System-Parameters-Info message. It is only
obsolete when the system is turned off.
Exception Handling:
Description: MSAW processes all tracks in the system every Scan-Time seconds. This is the time it takes the radar to
revolve 360 degrees.
Comments: This variable is known as SCANQ on the NAS-MD-643. Typical value = 4.75 seconds.
References:
1 2.2
Appears In:
Definition
= FIELD (Scan-Time in Other-System-Parameters-Info message)
Received Other-System-Parameters-Info
T
= PREV Scan-Time
Received Other-System-Parameters-Info
F
= Obsolete
Received MSAW-OFF
T
112
Input Value
Other-System-Parameters
IL> Aural-Alarm-Time-Duration
Source:
Type: integer
Possible Values (Expected Range): {0 ... 60}
Exception Handling:
Units: seconds
Granularity: 1 second
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until new value is input to the system via the Other-System-Parameters-Info message. It is only
obsolete when the system is turned off.
Exception Handling:
Description: When initially enabled, an aural alarm will sound for this time only unless it is disabled first.
Comments: This variable is known as CMSTDISQ on the NAS-MD-644. Typical value
= 5 seconds.
References: T 2.1.4
Appears In:
Definition
= FIELD (Aural-Alarm-Time-Duration in Other-System-Parameters-Info message)
Received Other-System-Parameters-Info
T
= PREV Aural-Alarm-Time-Duration
Received Other-System-Parameters-Info
F
= Obsolete
T
Received MSAW-OFF
113
Input Value
Other-System-Parameters
LL> MSAW-Gross-figh-Altitude
Source:
Type: integer
Possible Values (Expected Range): {-10000 ... 99900}
Exception Handling:
Units: feet
Granularity: 1 foot
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until new value is input to the system via the Other-System-Parameters-Info message. It is only
obsolete when the system is turned off.
Exception Handling:
Description: This parameter is used to determine whether a track is eligible for MSAW processing. If a given track has a
an altitude more than this value, it is not eligible.
Comments: This variable is known as CMS_GHALTQ on the NAS-MD-643 (3.18.17). Typical value = 39000 feet.
References:
Appears In:
Definition
= FIELD (MSAW-Gross-High-Altitude in Other-System-Parameters-Info message)
Received Other-System-Parameters-Info
T
= PREV MSAW-Gross-High-Altitude
Received Other-System-Parameters-Info
F
= Obsolete
Received MSAW-OFF
T
114
Input Value
Other-System-Parameters
IL> MSAW-Gross-Low-Altitude
Source:
Type: integer
Possible Values (Expected Range): {-10000 ... 99900}
Exception Handling:
Units: feet
Granularity: 1 foot
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until new value is input to the system via the Other-System-Parameters-Info message. It is only
obsolete when the system is turned off.
Exception Handling:
Description: This parameter is used to determine whether a track is eligible for MSAW processing. If a given track has a
an altitude less than this value, it is not eligible.
Comments: This variable is known as CMSGLALTQ on the NAS-MD-643 (3.18.18). Typical value = 100 feet.
References:
Appears In:
Defnition
= FIELD (MSAW-Gross-lligh-Altitude in Other-System-Parameters-Info message)
Received Other-System-Parameters-Info
T
= PREV MSAW-Gross-High-Altitude
Received Other-System-Parameters-Info
F
= Obsolete
T
Received MSAW-OFF
115
Input Value
Other-System-Parameters
LL> Track-Firmness-Parameter
Source:
Type: integer
Possible Values (Expected Range): {0 ... 37}
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until new value is input to the system via the Other-System-Parameters-Info message. It is only
obsolete when the system is turned off.
Exception Handling:
Description: This parameter is used to determine whether a track is eligible for MSAW processing. If a given track has a
firmness less than this value, it is not eligible.
Comments: This variable is known as CMFIRM on the NAS-MD-644. Typical value =
References:
1.
T 2.10.3
Appears In:
Definition
= FIELD (Track-Firmness-Parameter in Other-System-Parameters-Info message)
Received Other-System-Parameters-Info
T
PREV Track-Firmness-Parameter
Received Other-System-Parameters-Info
F
= Obsolete
Received MSAW-OFF
T
116
Input Value
Alert-Pads
LL> GTCAP
Source:
Type: integer
Possible Values (Expected Range): {-1000 ... 2000}
Exception Handling:
Units feet
Granularity: 1 foot
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until new value is input to the system via the Alert-Pads-Info message. It is only obsolete when
the system is turned off.
Exception Handling:
Description: The General Terrain Current Alert Pad (GTCAP) is used for determining current general terrain alerts.
The value is added to the track's actual altitude, and this value is used instead of the track's actual altitude
alone.
Comments: This variable is known as CMPAD1 on the NAS-MD-644. Typical value = -500 feet.
References:
T 2.6
Appears In:
Definition
= FIELD (GTCAP in Alert-Pads-Info message)
T
Received Alert-Pads-Info
= PREV GTCAP
F
Received Alert-Pads-Info
= Obsolete
T
Received MSAW-OFF
117
Input Value
Alert-Pads
IL> GTPAP
Source:
Type: integer
Possible Values (Expected Range): {0 ... 2000}
Exception Handling:
Units: feet
Granularity: 1 foot
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until new value is input to the system via the Alert-Pads-Info message. It is only obsolete when
the system is turned off.
Exception Handling:
Description: The General Terrain Predicted Alert Pad (GTPAP) is used for determining predicted general terrain alerts.
The value is added to the altitude of the predicted lines of flight, and this value is used instead of the lines
of flight's actual altitudes alone.
Comments: This variable is known as CMPAD2 on the NAS-MD-644. Typical value = -300 feet.
References:
T 2.6
Appears In:
Definition
= FIELD (GTPAP in Alert-Pads-Info message)
Received Alert-Pads-Info
T
= PREV
Received Alert-Pads-Info
F
= Obsolete
Received MSAW-OFF
T
118
Input Value
Alert-Pads
L> GTProAP
Source:
Type: integer
Possible Values (Expected Range): {0 ... 2000}
Exception Handling:
Units: feet
Granularity: 1 foot
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until new value is input to the system via the Alert-Pads-Info message. It is only obsolete when
the system is turned off.
Exception Handling:
Description: The General Terrain Projected Alert Pad (GTProAP) is used for determining projected general terrain
alerts. The value is added to the projected lines of flight actual altitude, and this value is used instead of the
lines of flight's actual altitudes alone.
Comments: This variable is known as CMPAD3 on the NAS-MD-644. Typical value = -300 feet.
References:
T 2.6
Appears In:
Definition
= FIELD (GTProAP in Alert-Pads-Info message)
T
Received Alert-Pads-Info
= PREV GTProAP
F
Received Alert-Pads-Info
= Obsolete
T
Received MSAW-OFF
119
Input Value
Alert-Pads
LL> AMCAP
Source:
Type: integer
Possible Values (Expected Range): {0 ... 20001
Exception Handling:
Units: feet
Granularity: 1 foot
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until new value is input to the system via the Alert-Pads-Info message. It is only obsolete when
the system is turned off.
Exception Handling:
Description: The Approach Monitoring Current Alert Pad (AMCAP) is used for determining current approach alerts.
The value is added to the track's actual altitude, and this value is used instead of the track's actual altitude
alone.
Comments: This variable is known as CMPAD4 on the NAS-MD-644. Typical value = 0 feet.
References:
1 2.6
Appears In:
Definition
= FIELD (AMCAP in Alert-Pads-Info message)
Received Alert-Pads-Info
T
= PREV AMCAP
Received Alert-Pads-Info
F
= Obsolete
Received MSAW-OFF
T
120
Input Value
Alert-Pads
Lk> AMPAP
Source:
Type: integer
Possible Values (Expected Range): {0 ... 2000}
Exception Handling:
Units: feet
Granularity: 1 foot
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until new value is input to the system via the Alert-Pads-Info message. It is only obsolete when
the system is turned off.
Exception Handling:
Description: The Approach Monitoring Predicted Alert Pad (AMPAP) is used for determining predicted approach
alerts. The value is added to the track's predicted position, and this value is used instead of the track's
actual altitude alone.
Comments: This variable is known as CMPAD5 on the NAS-MD-644. Typical value = 100 feet.
References:
T 2.6
Appears In:
Definition
= FIELD (AMPAP in Alert-Pads-Info message)
T
Received Alert-Pads-Info
= PREV AMPAP
F
Received Alert-Pads-Info
= Obsolete
T
Received MSAW-OFF
121
Input Value
Lookahead-Times
IL> GT-Prediction-Time-I
Source:
Type: integer
Possible Values (Expected Range): {0 ... 2000}
Exception Handling:
Units: seconds
Granularity: 1 second
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until new value is input to the system via the Lookahead-Times-Info message. It is only obsolete
when the system is turned off.
Exception Handling:
Description: The first General Terrain Prediction Time is used for calculating the prediction lines of flight for the given
aircraft. It marks the end of these lines and the beginning of the projection lines of flight.
Comments: This variable is known as CMTIMi on the NAS-MD-644. Typical value = 30 seconds.
References: T 2.20.1
Appears In:
Definition
= FIELD (GT-Prediction-Time-I in Lookahead-Times-Info message)
Received Lookahead-Times-Info
T
= PREV GT-Prediction-Time-I
Received Lookahead-Times-Info
F
= Obsolete
Received MSAW-OFF
T
122
Input Value
Lookahead-Times
LL> GT-Prediction-Time-II
Source:
Type: integer
Possible Values (Expected Range): {0 ... 480}
Exception Handling:
Units: seconds
Granularity: 1 second
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until new value is input to the system via the Lookahead-Times-Info message. It is only obsolete
when the system is turned off.
Exception Handling:
Description: The second General Terrain Prediction Time is used for calculating the projection lines of flight for the
given aircraft. It marks the end of these lines.
Comments: This variable is known as CMTIM2 on the NAS-MD-644. Typical value = 60 seconds.
References:
T 2.21.1
Appears In:
Definition
= FIELD (GT-Prediction-Time-II in Lookahead-Times-Info message)
Received Lookahead-Times-Info
T
= PREV GT-Prediction-Time-II
Received Lookahead-Times-Info
F
= Obsolete
T
Received MSAW-OFF
123
Input Value
Lookahead-Times
LL> AM-Prediction-Time
Source:
Type: integer
Possible Values (Expected Range): {0 ... 100}
Exception Handling:
Units: seconds
Granularity: 1 second
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until new value is input to the system via the Lookahead-Times-Info message. It is only obsolete
when the system is turned off.
Exception Handling:
Description: The Approach Monitoring Prediction Time is used for calculating the predicted point of an aircraft while
in descent to a runway.
Comments: This variable is known as CM_TIM3 on the NAS-MD-644. Typical value = 15 seconds.
References: T 2.14.2, T 2.14.3
Appears In:
Defnition
FIELD (AM-Prediction-Time in Lookahead-Times-Info message)
Received Lookahead-Times-Info
T
= PREV AM-Prediction-Time
Received Lookahead-Times-Info
F
= Obsolete
Received MSAW-OFF
T
124
I
Input Value
Lines-of-Flight-Parameters
IL> Range-Standard-Deviation
Source:
Type: decimal
Possible Values (Expected Range): {0 ... 0.25}
Exception Handling:
Units: Nautical Miles (NM)
Granularity: 0.0001 NM
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until new value is input to the system via the Lines-of-Flight-Parameters-Info message. It is only
obsolete when the system is turned off.
Exception Handling:
Description: This value is used for creating an aircraft's lines of flight. It accounts for errors in the radar and other
factors.
Comments: This variable is known as CMSIGR on the NAS-MD-644. Typical value = 0.07 NM.
References: T 2.18.3
Appears In:
Definition
FIELD (Range-Standard-Deviation in Lines-of-Flight-Parameters-Info message)
Received Lines-of-Flight-Parameters-Info
T
= PREV Range-Standard-Deviation
Received Lines-of-Flight-Parameters-Info
F
= Obsolete
Received MSAW-OFF
T
125
Input Value
Lines-of-Flight-Parameters
L> Azimuth-Standard-Deviation
Source:
Type: decimal
Possible Values (Expected Range): Unknown
Exception Handling:
Units: radians
Granularity: Unknown
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until new value is input to the system via the Lines-of-Flight-Parameters-Info message. It is only
obsolete when the system is turned off.
Exception Handling:
Description: Its exact purpose is unknown to me.
Comments: This variable is known as CMSIGTH on the NAS-MD-644. Typical value = 0.00436 radians.
References:
T 2.18.3
Appears In:
Definition
= FIELD (Azimuth-Standard-Deviation in Lines-of-Flight-Parameters-Info message)
Received Lines-of-Flight-Parameters-Info
T
= PREV Azimuth-Standard-Deviation
Received Lines-of-Flight-Parameters-Info
F
=
Obsolete
T
Received MSAW-OFF
126
Input Value
Lines-of-Flight-Parameters
ILL> Other-Factors-Coefficient
Source:
Type: coefficient
Possible Values (Expected Range): Unknown
Exception Handling:
Units: N/A
Granularity: Unknown
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until new value is input to the system via the Lines-of-Flight-Parameters-Info message. It is only
obsolete when the system is turned off.
Exception Handling:
Description: This coefficient is used to account for other factors. It provides flexibility in the calculation of the lines of
flight.
Comments: This variable is known as CMT on the NAS-MD-644. Typical value = 1.0.
References:
T 2.18.3
Appears In:
Definition
= FIELD (Other-Factors-Coefficient in Lines-of-Flight-Parameters-Info message)
Received Lines-of-Flight-Parameters-Info
T
= PREV Other-Factors-Coefficient
Received Lines-of-Flight-Parameters-Info
F
= Obsolete
T
Received MSAW-OFF
127
Input Value
Lines-of-Flight-Parameters
L> Track-Range
Source:
Type: integer
Possible Values (Expected Range): Unknown
Exception Handling:
Units: Nautical Miles (NM)
Granularity: Unknown (Possibly 1 NM)
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until new value is input to the system via the Lines-of-Flight-Parameters-Info message. It is only
obsolete when the system is turned off.
Exception Handling:
Description: Used in the calculation of an aircraft's lines of flight. Comes from sensor from which track data was
received. Its used because it is assumed that the farther away a track is from a sensor, the less accurate data
it receives from that sensor.
Comments:
References:
T 2.18.3
Appears In:
Definition
= FIELD (Track-Range in Lines-of-Flight-Parameters-Info message)
Received Lines-of-Flight-Parameters-Info
T
= PREV Track-Range
Received Lines-o f-Flight-Parameters-Info
F
= Obsolete
Received MSAW-OFF
T
128
Input Value
Lines-of-Flight-Parameters
I> Ascent-Angle
Source:
Type: decimal
Possible Values (Expected Range): Unknown
Exception Handling:
Units: Tangent 5 degrees
Granularity: Unknown
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until new value is input to the system via the Lines-of-Flight-Parameters-Info message. It is only
obsolete when the system is turned off.
Exception Handling:
Description: Used for calculating the projected lines of flight. These lines are elevated at this angle from the end of the
predicted lines of flight to their end as given by the GT-Prediction-Time-II.
Comments: This variable is known as CMTANCA on the NAS-MD-644. Typical value = 0.0874887 degrees.
References: T 2.21.1
Appears In:
Definition
= FIELD (Ascent-Angle in Lines-of-Flight-Parameters-Info message)
Received Lines-of-Flight-Parameters-Info
T
= PREV Ascent-Angle
Received Lines-of-Flight-Parameters-Info
F
= Obsolete
Received MSAW-OFF
T
129
Input Value
RCB-Regions(i)
LL> RCB-Name
Source:
Type: characters
Possible Values (Expected Range): {JFK, SJU, BOS; followed by a number (1 to MAX)}
Exception Handling:
Units: N/A
Granularity: N /A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until redefinition of input region though a new Type-1 /2-Regions message. It is only obsolete
when MSAW is turned off.
Exception Handling:
Description: This variable is the name (ID) of a given Runway Capture Box. The name includes the airport ID followed
by the RCB number.
Comments: The variable is known as REGIONNAME_22 in the NAS-MD-643 (3.19.16), which specifies that it
belongs to a table named Type 1/2 Airport Regions (CAMTYPE2 NAMES).
References: T 2.12.1, T 2.14.1, T 2.16.2.2
Appears In:
Definition
= FIELD (RCB-Name in Type-1 /2-Regions message)
Received Type-1/2-Regions
T
= PREV RCB-Name
Received Type-1/2-Regions
F
= Obsolete
Received MSAW-OFF
T
130
Input Value
RCB-Regions(i)
LL> Airport-Name
Source:
Type: characters
Possible Values (Expected Range): {JFK, SJU, BOS, SFO}
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until redefinition of input region though a new Type-1 /2-Regions message. It is only obsolete
when MSAW is turned off.
Exception Handling:
Description: This is the airport name for the given Runway Capture Box.
Comments: The variable is known as CAPATAPTNAME2 in the NAS-MD-643 (3.19.15), which specifies that it
belongs to a table named Type 1/2 Airport Regions (CAMTYPE2_NAMES).
References:
Appears In:
Definition
= FIELD (Airport-Name in Type-1/2-Regions message)
Received Type-1 /2-Regions
Type-1/2-Regions.RCB-Name = RCB-Regions(i).RCB-Name
T
T
Received Type-1/2-Regions= PREV Airport-Name
F
= Obsolete
T
Received MSAW-OFF
131
Input Value
RCB-Regions(i)
IL> Runway-Name
Source:
Type: characters
Possible Values (Expected Range): {260, 51, 02}
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until redefinition of input region though a new Type-1 /2-Regions message. It is only obsolete
when MSAW is turned off.
Exception Handling:
Description:
Comments: The variable is known as CAPATRUNWAYNAME in the NAS-MD-643 (3.19.29), which specifies
that it belongs to a table named Type 1/2 Airport Regions (CAM TYPE2_NAMES).
References:
Appears In:
Definition
= FIELD (Runway-Name in Type-1 /2-Regions message)
Received Type-1 /2-Regions
Ty e-1/2-Regions.RCB-Name = RCB-Regions(i).RCB-Name
T
= PREV Runway-Name
Received Type-1/2-Regions
F
= Obsolete
Received MSAW-OFF
T
132
Input Value
RCB-Regions(i)
Lk> X-Coordinate
Source:
Type: decimal
Possible Values (Expected Range): {-1000 ... 1000}
Exception Handling:
Units: Nautical Miles (NM)
Granularity: 0.01 NM
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until redefinition of input region though a new Type-1 /2-Regions message. It is only obsolete
when MSAW is turned off.
Exception Handling:
Description: This is the X coordinate value of the beginning of the runway inside the given Runway Capture Box.
Comments: The variable is known as APATX in the NAS-MD-643 (3.19.12), which specifies that it belongs to a table
named Type 1/2 Airport Regions (CAMTYPE2_NAMES). Typical value = 0.5.
References:
T 2.12.5
Appears In:
Definition
FIELD (X-Coordinate in Type-1 /2-Regions message)
Received Type-1 /2-Regions
Type-1/2-Regions.RCB-Name = RCB-Regions(i).RCB-Name
T
T
=PREV X-Coordinate
F
Received Type-1/2-Regions
= Obsolete
T
Received MSAW-OFF
133
Input Value
RCB-Regions(i)
LL> Y-Coordinate
Source:
Type: decimal
Possible Values (Expected Range): {-1000 ... 1000}
Exception Handling:
Units: Nautical Miles (NM)
Granularity: 0.01 NM
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until redefinition of input region though a new Type-1 /2-Regions message. It is only obsolete
when MSAW is turned off.
Exception Handling:
Description: This is the Y coordinate value of the beginning of the runway inside the given Runway Capture Box.
Comments: The variable is known as APATY in the NAS-MD-643 (3.19.13), which specifies that it belongs to a table
named Type 1/2 Airport Regions (CAMTYPE2_NAMES). Typical value -0.5.
References:
1 2.12.5
Appears In:
Definition
= FIELD (Y-Coordinate in Type-1/2-Regions message)
Received Type-1 /2-Regions
T
Ty e-1/2-Regions.RCB-Name = RCB-Regions(i).RCB-Name
T
= PREV Y-Coordinate
Received Type-1/2-Regions
F
= Obsolete
Received MSAW-OFF
T
134
Input Value
RCB-Regions(i)
IL> L-Distance
Source:
Type: decimal
Possible Values (Expected Range): {0 ... 50}
Exception Handling:
Units: Nautical Miles (NM)
Granularity: 0.01 NM
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until redefinition of input region though a new Type-1/2-Regions message. It is only obsolete
when MSAW is turned off.
Exception Handling:
Description: This value is the distance from the beginning of the runway, in a direction opposite to the landing
direction, to the far end of the Type 2 area (Approach Monitor Box).
Comments: The variable is known as CAPAT_L in the NAS-MD-643 (3.19.3), which specifies that it belongs to a
table named Type 2 Area Dimensions (CAMTYPE2_DIMEN). Typical value = 5 NM.
References:
T 2.12.5
Appears In:
Definition
= FIELD (L-Distance in Type-1 /2-Regions message)
Received Type-1/2-Regions
Type-1/2-Regions.RCB-Name = RCB-Regions(i).RCB-Name
T
T
= PREV L-Distance
Received Type-1/2-Regions
F
= Obsolete
Received MSAW-OFF
T
135
Input Value
RCB-Regions(i)
IL> D-Distance
Source:
Type: decimal
Possible Values (Expected Range): {0 ... 30}
Exception Handling:
Units: Nautical Miles (NM)
Granularity: 0.01 NM
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until redefinition of input region though a new Type-1 /2-Regions message. It is only obsolete
when MSAW is turned off.
Exception Handling:
Description: This value specifies the distance from the beginning of the given runway, in the direction opposite to the
landing direction, to the Type 1/Type 2 boundary, which is the Approach Inhibit Area/Approach
Monitor Box boundary.
Comments: The variable is known as CAPAT_.D in the NAS-MD-643 (3.19.4), which specifies that it belongs to a
table named Type 2 Area Dimensions (CAMTYPE2_DIMEN). Typical value = 2 NM.
References:
T 2.12.4
Appears In:
Definition
FIELD (D-Distance in Type-1/2-Regions message)
Received Type-1/2-Regions
Ty e-1/2-Regions.RCB-Name = RCB-Regions(i).RCB-Name
T
T
= PREV D-Distance
Received Type-1/2-Regions
F
= Obsolete
Received MSAW-OFF
T
136
Input Value
RCB-Regions(i)
LL> W-Distance
Source:
Type: decimal
Possible Values (Expected Range): {0 ... 5}
Exception Handling:
Units: Nautical Miles (NM)
Granularity: 0.01 NM
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until redefinition of input region though a new Type-1 /2-Regions message. It is only obsolete
when MSAW is turned off.
Exception Handling:
Description: This is the semi-width of the Runway Capture Box, the distance on each side of the runway.
Comments: The variable is known as CAPAT_W in the NAS-MD-643 (3.19.10), which specifies that it belongs to a
table named Type 2 Area Dimensions (CAMTYPE2_DIMEN). Typical value is 1 NM for single runways,
and for parallel runways equal to (1 + 0.5x), where x is the distance between the parallel runways.
References: T 2.12.5
Appears In:
Definition
= FIELD (W-Distance in Type-1/2-Regions message)
Received Type-1/2-Regions
Type-1/2-Regions.RCB-Name = RCB-Regions(i).RCB-Name
T
T
= PREV W-Distance
F
Received Type-1/2-Regions
= Obsolete
Received MSAW-OFF
T
137
Input Value
RCB-Regions(i)
L!> Landing-Direction
Source:
Type: integer
Possible Values (Expected Range): {0 ... 360}
Exception Handling:
Units: degrees
Granularity: 1 degree
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until redefinition of input region though a new Type-1 /2-Regions message. It is only obsolete
when MSAW is turned off.
Exception Handling:
Description: This input specifies the direction of landing for the runway inside the given Runway Capture Box.
Comments: The variable is known as APATTHETA in the NAS-MD-643 (3.19.8), which specifies that it belongs to a
table named Type 2 Area Dimensions (CAMTYPE2_DIMEN). Typical value = 10 degrees.
References:
T 12.12.1.3
Appears In:
Definition
= FIELD (Landing-Direction in Type-1 /2-Regions message)
Received Type-1 /2-Regions
Tye-1/2-Regions.RCB-Name = RCB-Regions(i).RCB-Name
T
T
= PREV Landing-Direction
Received Type- 1 / 2-Regions
FT7
= Obsolete
Received MSAW-OFF
T
138
Input Value
RCB-Regions(i)
LL> Runway-Length
Source:
Type: decimal
Possible Values (Expected Range): {0 ... 50}
Exception Handling:
Units: Nautical Miles (NM)
Granularity: 0.01 NM
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until redefinition of input region though a new Type-1 /2-Regions message. It is only obsolete
when MSAW is turned off.
Exception Handling:
Description: This input specifies the length of the runway of the given Runway Capture Box.
Comments: The variable is known as CAPATR in the NAS-MD-643 (3.19.9), which specifies that it belongs to a
table named Type 2 Area Dimensions (CAMTYPE2_DIMEN).
References:
Appears In:
Definition
= FIELD (Runway-Length in Type-1/2-Regions message)
Received Type-1/2-Regions
Type-1/2-Regions.RCB-Name = RCB-Regions(i).RCB-Name
T
T
= PREV Runway-Length
F
Received Type-1/2-Regions
= Obsolete
T
Received MSAW-OFF
139
Input Value
RCB-Regions(i)
L> Beginning-Glideslope-Altitude
Source:
Type: integer
Possible Values (Expected Range): {0 ... 50000}
Exception Handling:
Units: feet
Granularity: 1 foot
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until redefinition of input region though a new Type-1/2-Regions message. It is only obsolete
when MSAW is turned off.
Exception Handling:
Description: This value is used for creating the imaginary glideslope for checking for approach alerts. It defines the
altitude at the beginning of the glideslope, that is, the closest point to the beginning of the runway.
Comments: The variable is known as CAPATGSALT_1 in the NAS-MD-643 (3.19.14), which specifies that it
belongs to a table named Type 2 Miscellaneous (CAMTYPE2_MISC). Typical value = 1000 feet.
References:
T 2.12.4
Appears In:
Definition
FIELD (Beginning-Glideslope-Altitude in Type-1 /2-Regions message)
Received Type-1 /2-Regions
Ty e-1/2-Regions.RCB-Name = RCB-Regions(i).RCB-Name
T
T
= PREV Beginning-Glideslope-Altitude
Received Type-1/2-Regions
F
= Obsolete
Received MSAW-OFF
T
140
Input Value
RCB-Regions(i)
IL> Ending-Glideslope-Altitude
Source:
Type: integer
Possible Values (Expected Range): {0 ... 50000}
Exception Handling:
Units: feet
Granularity: 1 foot
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until redefinition of input region though a new Type-1/2-Regions message. It is only obsolete
when MSAW is turned off.
Exception Handling:
Description: This value is used for creating the imaginary glideslope for checking for approach alerts. It defines the
altitude at the end of the glideslope, that is, the farthest point from the beginning of the runway.
Comments: The variable is known as CAPATGSALT_2 in the NAS-MD-643 (3.19.18), which specifies that it
belongs to a table named Type 2 Miscellaneous (CAMTYPE2_MISC). Typical value = 2000 feet.
References:
Appears In:
Definition
= FIELD (Ending-Glideslope-Altitude in Type-1 /2-Regions message)
Received Type-1/2-Regions
Type-1/2-Regions.RCB-Name = RCB-Regions(i).RCB-Name
T
T
= PREV Ending-Glideslope-Altitude
F
Received Type-1/2-Regions
= Obsolete
Received MSAW-OFF
T
141
Input Value
RCB-Regions(i)
LL> Arrival-Angle
Source:
Type: decimal
Possible Values (Expected Range): {0 ... 180}
Exception Handling:
Units: degrees
Granularity: 0.01 degrees
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until redefinition of input region though a new Type-1 /2-Regions message. It is only obsolete
when MSAW is turned off.
Exception Handling:
Description: This is the angle that is used to determine whether an aircraft is within the given Runway Capture Box.
The track is within the RCB if the angle between its velocity vector and the runway is less than this value.
Comments: The variable is known as CAPATARRIVANGLE in the NAS-MD-643 (3.19.25), which specifies that it
belongs to a table named Type 2 Miscellaneous (CAMTYPE2_MISC). Typical value = 90 degrees. A value
of 0 will cause that a track never be found inside this RCB. A value of 180 will cause that a track always be
determined to be within this RCB.
References:
Appears In:
Definition
= FIELD (Arrival-Angle in Type-1/2-Regions message)
Received Type-1 /2-Regions
Tye-1/2-Regions.RCB-Name = RCB-Regions(i).RCB-Name
T
T
= PREV Arrival-Angle
Received Type-1/2-Regions
F
= Obsolete
Received MSAW-OFF
T
142
Input Value
RCB-Regions(i)
LL> Inhibit-MSAW-Departure
Source:
Type: boolean
Possible Values (Expected Range): {True, False}
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: Valid until redefinition of input region though a new Type-1/2-Regions message. It is only obsolete
when MSAW is turned off.
Exception Handling:
Description: This value specifies whether a given Runway Capture Box is to become a Departure Inhibit Area.
Comments: The variable is known as CAPATDEPINH in the NAS-MD-643 (3.19.24), which specifies that it
belongs to a table named Type 2 Miscellaneous (CAMTYPE2_MISC). Typical value = False.
References:
T 2.12.1.4, T 2.14.1
Appears In:
Definition
= FIELD (Inhibit-MSAW-Departure in Type-1/2-Regions message)
Received Type-1 /2-Regions
Type-1/2-Regions.RCB-Name = RCB-Regions(i).RCB-Name
T
T
= PREV Inhibit-MSAW-Departure
Received Type-1 /2-Regions
F
= Obsolete
T
Received MSAW-OFF
143
Input Value
GTI-Areas(i)
IL> GTIA-Region-Name
Source:
Type: characters
Possible Values (Expected Range): {GTM followed by a number (1 to Max)}
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the MSAW-General-Terrain-Inhibit-Areas message. It becomes
obsolete only when MSAW is turned off.
Exception Handling:
Description: For every defined General Terrain Inhibit Region, this is its name. It is used for searching whether an
aircraft is within this region.
Comments: The variable is known as REGIONNAME_28 in the NAS-MD-643 (3.65.13), which specifies that
it belongs to a table named MSAW General Terrain Inhibit Regions (TER.GTIINH).
References:
1 2.16.1
Appears In:
Definition
= FIELD (GTIA-Region-Name in MSAW-General-Terrain-Inhibit-Areas message)
Received MSAW-General-Terrain-Inhibit-Areas
T
= PREV GTIA-Region-Name
Received MSAW-General-Terrain-Inhibit-Areas
F
= Obsolete
Received MSAW-OFF
T
144
Input Value
GTI-Areas(i)
LL> Geometry
Source:
Type: Depends on Shape
Possible Values (Expected Range): Depends on Shape - Polygon = (1 to Max number of points)
Rectangle = (center point, orientation, half side X, half
side Y)
Circle = (center point, radius)
3 Range/Azimuth = (center point, 2 o 3 vectors with max
range)
2 Range/Azimuth = (center point, start azimuth, end
azimuth, start range, end range)
6 Range/3 Azimuth = (center point, 3 sectors with start
and end range)
Exception Handling:
Units: Depend on Shape
Granularity: Unknown
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the MSAW-General-Terrain-Inhibit-Areas message. It becomes
obsolete only when MSAW is turned off.
Exception Handling:
Description: This input describes the parameters for the type of shape the given region has in order to be used in
determining whether an aircraft falls inside this region.
Comments: The variable is known as REGIONGEOMETRY_28 in the NAS-MD-643 (3.65.12), which specifies that
it belongs to a table named MSAW General Terrain Inhibit Regions (TERGTI_INI).
References:
1 2.16.1
Appears In:
Definition
FIELD (Geometry in MSAW-General-Terrain-Inhibit-Areas message)
Received MSAW-General-Terrain-Inhibit-Areas
MSAW-General-Terrain-Inhibit-Areas.GTIA-Region-Name = GTI-Areas(i).GTIA-Region-Name
145
T
T
= PREV Geometry
Received MSAW-General-Terrain-Inhibit-Areas
F
= Obsolete
Received MSAW-OFF
T
146
Input Value
GTI-Areas(i)
1> Point-Type
Source:
Type: characters
Possible Values (Expected Range): {POLAR, CART, LATLON}
Exception Handling:
Units: N/A
Granularity: N /A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the MSAW-General-Terrain-Inhibit-Areas message. It becomes
obsolete only when MSAW is turned off.
Exception Handling:
Description: This defines what the coordinate type is for the given region, whether it is in polar, Cartesian or
latitude/longitude coordinates.
Comments: The variable is known as REGIONPOINTTYPE_28 in the NAS-MD-643 (3.65.14), which specifies
that it belongs to a table named MSAW General Terrain Inhibit Regions (TERGTIINI-1).
References: T 2.16.1
Appears In:
Definition
= FIELD (Point-Type in MSAW-General-Terrain-Inhibit-Areas message)
Received MSAW-General-Terrain-Inhibit-Areas
MSAW-General-Terrain-Inhibit-Areas.GTIA-Region-Name = GTI-Areas(i).GTIA-Region-Name
T
T
= PREV Point-Type
Received MSAW-General-Terrain-Inhibit-Areas
F
= Obsolete
T
Received MSAW-OFF
147
Input Value
GTI-Areas(i)
IL> Shape
Source:
Type: characters
Possible Values (Expected Range): {NONE, POLY, RECT, CIRC, RNG3, RNG2, RNG6}
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the MSAW-General-Terrain-Inhibit-Areas message. It becomes
obsolete only when MSAW is turned off.
Exception Handling:
Description: This input defines whether the given region is polygon, rectangle, circle, 3 range/azimuth, 2
range/azimuth or 6 range/3 azimuth.
Comments: The variable is known as REGION_SHAPE_28 in the NAS-MD-643 (3.65.15), which specifies that
it belongs to a table named MSAW General Terrain Inhibit Regions (TER.GTIINH). Typical value
NONE.
References:
1 2.16.1
Appears In:
Definition
= FIELD (Shape in MSAW-General-Terrain-Inhibit-Areas message)
Received MSAW-General-Terrain-Inhibit-Areas
MSAW-General-Terrain-Inhibit-Areas.GTIA-Region-Name = GTI-Areas(i).GTIA-Region-Name
= PREV Shape
Received MSAW-General-Terrain-Inhibit-Areas
T
T
F
= Obsolete
Received MSAW-OFF
T
148
Input Value
GTI-Areas(i)
I> Enable-GTI-Area
Source:
Type: boolean
Possible Values (Expected Range): {True/False}
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the MSAW-General-Terrain-Inhibit-Areas message. It becomes
obsolete only when MSAW is turned off.
Exception Handling:
Description: This determines whether the given region is active. If so, an aircraft within it is exempt from General
Terrain alerts.
Comments: The variable is known as CGTREQ in the NAS-MD-643 (3.65.1), which specifies that it belongs to a
table named MSAW General Terrain Inhibit Regions (TERGTIINH). Typical value = True.
References: T 2.16.1
Appears In:
Definition
= FIELD (Enable-GTI-Area in MSAW-General-Terrain-Inhibit-Areas message)
Received MSAW-General-Terrain-Inhibit-Areas
MSAW-General-Terrain-Inhibit-Areas.GTIA-Region-Name = GTI-Areas(i).GTIA-Region-Name
T
T
= PREV Enable-GTI-Area
Received MSAW-General-Terrain-Inhibit-Areas
F
= Obsolete
T
Received MSAW-OFF
149
Input Value
AMI-Areas(i)
1!> AMIA-Region-Name
Source:
Type: characters
Possible Values (Expected Range): {JFK, SJU, BOS; followed by a number (1 to Max)}
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the MSAW-Approach-Monitor-Inhibit-Areas message. It
becomes obsolete only when MSAW is turned off.
Exception Handling:
Description:
Comments: The variable is known as REGIONNAME_26 in the NAS-MD-643 (3.65.3), which specifies that it
belongs to a table named MSAW Approach Monitor Inhibit Regions (TERAPMINH).
References:
1 2.11.1
Appears In:
Definition
= FIELD (AMIA-Region-Name in MSAW-Approach-Monitor-Inhibit-Areas message)
Received MSAW-Approach-Monitor-Inhibit-Areas
T
= PREV AMIA-Region-Name
Received MSAW-Approach-Monitor-Inhibit-Areas
F
= Obsolete
Received MSAW-OFF
T
150
Input Value
AMI-Areas(i)
LL> Geometry
Source:
Type: Depends on Shape
Possible Values (Expected Range): Depends on Shape - Polygon = (1 to Max number of points)
Rectangle = (center point, orientation, half side X, half
side Y)
Circle = (center point, radius)
3 Range/Azimuth = (center point, 2 o 3 vectors with max
range)
2 Range/Azimuth = (center point, start azimuth, end
azimuth, start range, end range)
6 Range/3 Azimuth = (center point, 3 sectors with start
and end range)
Exception Handling:
Units: Depends on Shape
Granularity: Unknown
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the MSAW-Approach-Monitor-Inhibit-Areas message. It
becomes obsolete only when MSAW is tumed off.
Exception Handling:
Description: This input describes the parameters for the type of shape the given region has in order to be used in
determining whether an aircraft falls inside this region.
Comments: The variable is known as REGIONGEOMETRY_26 in the NAS-MD-643 (3.65.2), which specifies that
it belongs to a table named MSAW Approach Monitor Inhibit Regions (TERAPMINI-1).
References:
t 2.11.1
Appears In:
Definition
= FIELD (Geometry in MSAW-Approach-Monitor-Inhibit-Areas message)
Received MSAW-Approach-Monitor-Inhibit-Areas
MSAW-Approach-Monitor-Inhibit-Areas.AMIA-Region-Name = AMI-Areas(i).AMIA-Region-Name
151
T
T
= PREV Geometry
Received MSAW-Approach-Monitor-Inhibit-Areas
F
= Obsolete
Received MSAW-OFF
T
152
Input Value
AMI-Areas(i)
IL> Point-Type
Source:
Type: characters
Possible Values (Expected Range): {POLAR, CART, LATLON}
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the MSAW-Approach-Monitor-Inhibit-Areas message. It
becomes obsolete only when MSAW is turned off.
Exception Handling:
Description: This defines what the coordinate type is for the given region, whether it is in polar, Cartesian or
latitude/longitude coordinates.
Comments: The variable is known as REGIONPOINTTYPE_26 in the NAS-MD-643 (3.65.4), which specifies that
it belongs to a table named MSAW Approach Monitor Inhibit Regions (TERAPMINH).
References:
T 2.11.1
Appears In:
Definition
= FIELD (Point-Type in MSAW-Approach-Monitor-Inhibit-Areas message)
Received MSAW-Approach-Monitor-Inhibit-Areas
MSAW-Approach-Monitor-Inhibit-Areas.AMIA-Region-Name = AMI-Areas(i).AMIA-Region-Name
T
T
= PREV Point-Type
F
Received MSAW-Approach-Monitor-Inhibit-Areas
= Obsolete
T
Received MSAW-OFF
153
Input Value
AMI-Areas(i)
LL> Shape
Source:
Type: characters
Possible Values (Expected Range): {POLY, RECT, CIRC, RNG3, RNG2, RNG6}
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the MSAW-Approach-Monitor-Inhibit-Areas message. It
becomes obsolete only when MSAW is turned off.
Exception Handling:
Description: This input defines whether the given region is polygon, rectangle, circle, 3 range/azimuth, 2
range/azimuth or 6 range/3 azimuth.
Comments: The variable is known as REGIONSHAPE_26 in the NAS-MD-643 (3.65.5), which specifies that it
belongs to a table named MSAW Approach Monitor Inhibit Regions (TERAPMIN-I).
References:
2.11.1
Appears In:
Definition
= FIELD (Shape in MSAW-Approach-Monitor-Inhibit-Areas message)
Received MSAW-Approach-Monitor-Inhibit-Areas
MSAW-Approach-Monitor-Inhibit-Areas.AMIA-Region-Name = AMI-Areas(i).AMIA-Region-Name
T
T
= PREV Shape
Received MSAW-Approach-Monitor-Inhibit-Areas
F
= Obsolete
Received MSAW-OFF
T
154
Input Value
AA-Inhibit-Areas(i)
LL> AAIA-Region-Name
Source:
Type: characters
Possible Values (Expected Range): {REM followed by a number (1 to Max)}
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the IFR-Aural-Alarm-Inhibit-Areas message. It becomes
obsolete only when MSAW is turned off.
Exception Handling:
Description: This names the given region to be able to identify it from others.
Comments: The variable is known as REGIONNAME_35 in the NAS-MD-643 (3.18.4), which specifies that it
belongs to a table named IFR Aural Alarm Inhibit Regions (CAMAURALIFR).
References:
Appears In:
Definition
= FIELD (AAIA-Region-Name in IFR-Aural-Alarm-Inhibit-Areas message)
Received IFR-Aural-Alarm-Inhibit-Areas
T
= PREV AAIA-Region-Name
Received IFR-Aural-Alarm-Inhibit-Areas
F
= Obsolete
Received MSAW-OFF
T
155
Input Value
AA-Inhibit-Areas(i)
IL> Geometry
Source:
Type: Depends on Shape
Possible Values (Expected Range): Depends on Shape - Polygon = (1 to Max number of points)
Rectangle = (center point, orientation, half side X, half
side Y)
Circle = (center point, radius)
3 Range/Azimuth = (center point, 2 o 3 vectors with max
range)
2 Range/Azimuth = (center point, start azimuth, end
azimuth, start range, end range)
6 Range/3 Azimuth = (center point, 3 sectors with start
and end range)
Exception Handling:
Units: Depends on Shape
Granularity: Unknown
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the IFR-Aural-Alarm-Inhibit-Areas message. It becomes
obsolete only when MSAW is tumed off.
Exception Handling:
Description: This input describes the parameters for the type of shape the given region has in order to be used in
determining whether an aircraft falls inside this region.
Comments: The variable is known as REGIONGEOMETRY_35 in the NAS-MD-643 (3.18.3), which specifies that it
belongs to a table named IFR Aural Alarm Inhibit Regions (CAMAURALIFR).
References:
Appears In:
Definition
= FIELD (Geometry in IFR-Aural-Alarm-Inhibit-Areas message)
Received IFR-Aural-Alarm-Inhibit-Areas
IFR-Aural-Alarm-Inhibit-Areas.AAIA-Region-Name = AA-Inhibit-Areas(i).AAIA-Region-Name
156
T
T
= PREV Geometry
F
Received IFR-Aural-Alarm-Inhibit-Areas
= Obsolete
T
Received MSAW-OFF
157
Input Value
AA-Inhibit-Areas(i)
LL> Point-Type
Source:
Type: characters
Possible Values (Expected Range): {POLAR, CART, LATLON}
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the IFR-Aural-Alarm-Inhibit-Areas message. It becomes
obsolete only when MSAW is turned off.
Exception Handling:
Description: This defines what the coordinate type is for the given region, whether it is in polar, Cartesian or
latitude/longitude coordinates.
Comments: The variable is known as REGIONPOINTTYPE_35 in the NAS-MD-643 (3.18.5), which specifies that
it belongs to a table named IFR Aural Alarm Inhibit Regions (CAMAURALIFR).
References:
Appears In:
Definition
= FIELD (Point-Type in IFR-Aural-Alarm-Inhibit-Areas message)
Received IFR-Aural-Alarm-Inhibit-Areas
IFR-Aural-Alarm-Inhibit-Areas.AAIA-Region-Name = AA-Inhibit-Areas(i).AAIA-Region-Name
T
T
= PREV Point-Type
Received IFR-Aural-Alarm-Inhibit-Areas
F
= Obsolete
Received MSAW-OFF
T
158
Input Value
AA-Inhibit-Areas(i)
IL> Shape
Source:
Type: characters
Possible Values (Expected Range): {NONE, POLY, RECT, CIRC, RNG3, RNG2, RNG6}
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the IFR-Aural-Alarm-Inhibit-Areas message. It-becomes
obsolete only when MSAW is turned off
Exception Handling:
Description: This input defines whether the given region is polygon, rectangle, circle, 3 range/azimuth, 2
range/azimuth or 6 range/3 azimuth.
Comments: The variable is known as REGIONSHAPE_35 in the NAS-MD-643 (3.18.6), which specifies that it
belongs to a table named IFR Aural Alarm Inhibit Regions (CAMAURALIFR).
References:
Appears In:
Definition
= FIELD (Shape in IFR-Aural-Alarm-Inhibit-Areas message)
Received IFR-Aural-Alarm-Inhibit-Areas
IFR-Aural-Alarm-Inhibit-Areas.AAIA-Region-Name = AA-Inhibit-Areas(i).AAIA-Region-Name
T
T
PREV Shape
Received IFR-Aural-Alarm-Inhibit-Areas
F
= Obsolete
T
Received MSAW-OFF
159
Input Value
AA-Inhibit-Areas(i)
IL> Inhibit-MSAW
Source:
Type: boolean
Possible Values (Expected Range): {True/False}
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the IFR-Aural-Alarm-Inhibit-Areas message. It becomes
obsolete only when MSAW is turned off.
Exception Handling:
Description:
Comments: The variable is known as CAURLACAIFR_1 in the NAS-MD-643 (3.17.18), which specifies that it
belongs to a table named IFR Aural Alarm Inhibit Regions (CAMAURALIFR).
References:
Appears In:
Definition
FIELD (Inhibit-MSAW in IFR-Aural-Alarm-Inhibit-Areas message)
Received IFR-Aural-Alarm-Inhibit-Areas
IFR-Aural-Alarm-Inbibit-Areas.AAIA-Region-Name = AA-Inhibit-Areas(i).AAIA-Region-Name
T
T
= PREV Inhibit-MSAW
Received IFR-Aural-Alarm-Inhibit-Areas
F
= Obsolete
Received MSAW-OFF
T
160
Input Value
RAA-Areas(i)
IL> RAAA-Region-Name
Source:
Type: characters
Possible Values (Expected Range): {REM followed by a number (1 to Max)}
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the Remote-Aural-Alarm-Areas message. It becomes obsolete
only when MSAW is turned off.
Exception Handling:
Description: This names the given region to be able to identify it from others.
Comments: The variable is known as REGIONNAME_12 in the NAS-MD-643 (3.18.9), which specifies that it
belongs to a table named Remote Aural Alarm Regions (CAMAURALREM).
References:
Appears In:
Definition
= FIELD (RAAA-Region-Name in Remote-Aural-Alarm-Areas message)
Received Remote-Aural-Alarm-Areas
T
= PREV RAAA-Region-Name
Received Remote-Aural-Alarm-Areas
F
= Obsolete
T
Received MSAW-OFF
161
Input Value
i
RAA-Areas(i)
LL> Geometry
Source:
Type: Depends on Shape
Possible Values (Expected Range): Depends on Shape - Polygon = (1 to Max number of points)
Rectangle = (center point, orientation, half side X, half
side Y)
Circle = (center point, radius)
3 Range/Azimuth = (center point, 2 o 3 vectors with max
range)
2 Range/Azimuth = (center point, start azimuth, end
azimuth, start range, end range)
6 Range/3 Azimuth = (center point, 3 sectors with start
and end range)
Exception Handling:
Units: Depends on Shape
Granularity: Unknown
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the Remote-Aural-Alarm-Areas message. It becomes obsolete
only when MSAW is turned off.
Exception Handling:
Description: This input describes the parameters for the type of shape the given region has in order to be used in
determining whether an aircraft falls inside this region.
Comments: The variable is known as REGIONGEOMETRY_12 in the NAS-MD-643 (3.18.8), which specifies that it
belongs to a table named Remote Aural Alarm Regions (CAMAURALREM).
References:
Appears In:
Definition
= FIELD (Geometry in Remote-Aural-Alarm-Areas message)
Received Remote-Aural-Alarm-Areas
Remote-Aural-Alarm-Areas.RAAA-Region-Name = RAA-Areas(i).RAAA-Region-Name
162
T
T
= PREV Geometry
F
Received Remote-Aural-Alarm-Areas
= Obsolete
T
Received MSAW-OFF
163
Input Value
RAA-Areas (i)
L> Point-Type
Source:
Type: characters
Possible Values (Expected Range): {POLAR, CART, LATLON}
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the Remote-Aural-Alarm-Areas message. It becomes obsolete
only when MSAW is turned off
Exception Handling:
Description: This defines what the coordinate type is for the given region, whether it is in polar, Cartesian or
latitude/longitude coordinates.
Comments: The variable is known as REGIONPOINT__TYPE_12 in the NAS-MD-643 (3.18.10), which specifies
that it belongs to a table named Remote Aural Alarm Regions (CAMAURALIFR).
References:
Appears In:
Definition
= FIELD (Point-Type in Remote-Aural-Alarm-Areas message)
Received Remote-Aural-Alarm-Areas
Remote-Aural-Alarm-Areas.RAAA-Region-Name = RAA-Areas(i).RAAA-Region-Name
T
T
= PREV Point-Type
Received Remote-Aural-Alarm-Areas
F
= Obsolete
Received MSAW-OFF
T
164
Input Value
RAA-Areas (i)
IL> Shape
Source:
Type: characters
Possible Values (Expected Range): {NONE, POLY, RECT, CIRC, RNG3, RNG2, RNG6}
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the Remote-Aural-Alarm-Areas message. It becomes obsolete
only when MSAW is turned off.
Exception Handling:
Description: This input defines whether the given region is polygon, rectangle, circle, 3 range/azimuth, 2
range/azimuth or 6 range/3 azimuth.
Comments: The variable is known as REGIONSHAPE_12 in the NAS-MD-643 (3.18.11), which specifies that it
belongs to a table named Remote Aural Alarm Regions (CAMAURALIFR).
References:
Appears In:
Definition
= FIELD (Shape in Remote-Aural-Alarm-Areas message)
Received Remote-Aural-Alarm-Areas
Remote-Aural-Alarm-Areas.RAAA-Region-Name = RAA-Areas(i).RAAA-Region-Name
T
T
= PREV Shape
Received Remote-Aural-Alarm-Areas
F
= Obsolete
T
Received MSAW-OFF
165
Input Value
RAA-Areas(i)
LL> Enable-MSAW
Source:
Type: boolean
Possible Values (Expected Range): {True, False}
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the Remote-Aural-Alarm-Areas message. It becomes obsolete
only when MSAW is turned off.
Exception Handling:
Description: If true, it specifies that the given Aural Alarm Area applies to MSAW.
Comments: The variable is known as CAURLACAREM_1 in the NAS-MD-643 (3.17.19), which specifies that it
belongs to a table named Remote Aural Alarm Regions (CAMAURALIFR).
References:
Appears In:
Definition
FIELD (Enable-MSAW in Remote-Aural-Alarm-Areas message)
Received Remote-Aural-Alarm-Areas
Remote-Aural-Alarm-Areas.RAAA-Region-Name = RAA-Areas(i).RAAA-Region-Name
= PREV Enable-MSAW
Received Remote-Aural-Alarm-Areas
T
T
F
= Obsolete
Received MSAW-OFF
T
166
Input Value
MSAW-Terrain-Map(i)
LL> TME-Name
Source:
Type: characters
Possible Values (Expected Range): {MSAW followed by a number (1 ... 16)}
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the Terrain-Map-Info message. It becomes obsolete
only when MSAW is turned off.
Exception Handling:
Description: This names each Terrain Map Element square, given by its coordinates and altitude, so that it can be used
to detect low altitude violations.
Comments: The variable is known as REGIONNAME_39 in the NAS-MD-643 (3.64.4), which specifies that it
belongs to a table named Miscellaneous MSAW Parameters (TERMISC). Supplied by NOAA.
References:
T 2.17
Appears In:
Definition
= FIELD (TME-Name in Terrain-Map-Info message)
T
Received Terrain-Map-Info
= PREV TME-Name
F
Received Terrain-Map-Info
= Obsolete
T
Received MSAW-OFF
167
Input Value
MSAW-Terrain-Map(i)
[L> X-Grid-Number
Source:
Type: integer
Possible Values (Expected Range): {0 ... 256}
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the Terrain-Map-Info message. It becomes obsolete
only when MSAW is turned off.
Exception Handling:
Description: This is the column number for the given Terrain Map.
Comments: The variable is known as GTMCOL in the NAS-MD-643 (3.64.2), which specifies that it belongs to a
table named MSAW Terrain Map (TERMAP). Supplied by NOAA.
References:
T 2.17
Appears In:
Definition
= FIELD (X-Grid-Number in Terrain-Map-Info message)
Received Terrain-Map-Info
T
Terrain-Map-Info.TME-Name = MSAW-Terrain-Map(i).TME-Name
T
= PREV X-Grid-Number
Received Terrain-Map-Info
F
= Obsolete
Received MSAW-OFF
T
168
Input Value
MSAW-Terrain-Map(i)
LL> Y-Grid-Number
Source:
Type: integer
Possible Values (Expected Range): {0 ... 256}
Exception Handling:
Units: N/A
Granularity: N/A
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the Terrain-Map-Info message. It becomes obsolete only when
MSAW is turned off.
Exception Handling:
Description: This is the row number for the given Terrain Map.
Comments: The variable is known as GTMROW in the NAS-MD-643 (3.64.3), which specifies that it belongs to a
table named MSAW Terrain Map (TERMAP). Supplied by NOAA.
References:
T 2.17
Appears In:
Definition
= FIELD (Y-Grid-Number in Terrain-Map-Info message)
Received Terrain-Map-Info
Terrain-Map-Info.TME-Name = MSAW-Terrain-Map(i).TME-Name
T
T
= PREV Y-Grid-Number
F
Received Terrain-Map-Info
= Obsolete
T
Received MSAW-OFF
169
Input Value
MSAW-Terrain-Map(i)
I> Altitude
Source:
Type: integer
Possible Values (Expected Range): {-1000 ... 25000}
Exception Handling:
Units: feet
Granularity: 1 foot
Arrival Rate (Load):
Min-Time-Between-Inputs:
Max-Time-Between-Inputs:
Obsolescence: This value is valid until redefinition via the Terrain-Map-Info message. It becomes obsolete only when
MSAW is turned off.
Exception Handling:
Description: This is the row number for the given Terrain Map.
Comments: The variable is known as GTMALT in the NAS-MD-643 (3.64.1), which specifies that it belongs to a
table named MSAW Terrain Map (TERMAP). Supplied by NOAA.
References: T 2.17
Appears In:
Definition
FIELD (Altitude in Terrain-Map-Info message)
Received Terrain-Map-Info
T
Terrain-Map-Info.TME-Name = MSAW-Terrain-Map(i).TME-Name
T
= PREV Altitude
F
Received Terrain-Map-Info
=
Obsolete
Received MSAW-OFF
T
170
Testing Requirements
Any requirements for testing the system are not included here. Documents were not
available at the time.
171
172
Bibliography
[1] Leveson, Nancy. "Intent Specifications: An Approach to Building Human-Centered
Specifications". IEEE Transaaionson Scftwre E nginring,January 2000.
[2] Lai, Danny. "Extending a Formal Specification & Requirements Language: A Case Study". MIT
Masters of Engineering Degree Thesis Project Proposal. December, 2000.
[3] Leveson, Nancy, and Reese, Jon Damon. "Sample TCAS Intent Specification".
[4] Raytheon Corporation. Standard Terminal Automation Replacement System (STARS):
System/Subsystem Specification (SSS) Rev F. CDRL Sequence No. E001-006.
[5] Raytheon Corporation. Software Requirements Specification for the Radar Data Processing
Sytem (RDPS) CSC[-1 Revision: Feb. 5, 2001.
[6] Raytheon Corporation. STARS Full Service Tower Display Workstation/Terminal Controller
Workstation Software User's Manual. Feb. 9, 2001.
[7] U.S. Department of Transportation, Federal Aviation Administration. "Computer Program
Functional Specification (CPFS) MSAW and Altitude Tracking". NAS-MD-644, A6.05/A2.09. May
1998.
[8] Meeting with Raytheon Officials.
[9] Nancy Leveson, Maxime de Villepin, Mirna Daouk, John Bellingham, Jayakanth Srinivasan,
Natasha Neogi, and Ed Bachelder. "A Safety and Human-Centered Approach to Developing New
Air Traffic Management Tools". (This is a work in progress)
[10] Leveson, Nancy. "Completeness in Formal Specification Language Design for Process-Control
Systems". FormdMethods in StzumPraai, August 2000.
[11] U.S. Department of Transportation, Federal Aviation Administration. "Computer Program
Functional Specification (CPFS) Site Adaptation". NAS-MD-643, A6.05/A2.09. May 1998.
173