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