An Object Oriented Analysis Of Air Traffic Control

3.1 ATC

This section describes the scope of study for the ATC domain model, motivates the selection of subjects and classes through a brief review of the genesis of air traffic control, and presents the ATC model.

Because of size limitations of the printed page, the figures in sections 3 and 4 which contain parts of models show only class and object names and not attributes and services. Attributes and services are described in the model specification appendices.

3.1.1 Scope of the ATC Model

The broad scope of study is ATC in the AERA 2 timeframe, i.e., the year 1999 and approximately 10 years beyond. The scope is limited by the following:

• The amount of resources (time and staffing) available - For example, the depth of study in any one area is limited.

• A (subjective) consideration of I-Lab objectives - For example, horizontal (across application) details are emphasized over vertical (within application) details. Applications such as the following which are unlikely to be the subject of experiments within I-Lab were omitted:

  • Research and development (e.g., activities of the Research and Development Computer Complex), except that prototypes or models resulting from research and development might be considered at some future time as legacy software

  • Maintenance(e.g., the Remote Maintenance Monitoring System)

  • Backup(e.g., facility backup, hardware backup provided for reliability)

  • Training(e.g., activities carried out by the FAA Academy or at facilities, or functionality of the dynamic simulator [DYSIM])

  • Testing(e.g., activities directed toward system testing and verification)

  • Military ATC (i.e., functionality unique to facilities operated by the military services)

  • Foreign ATC (i.e., ATC services provided by foreign countries)

  • Supervisory (i.e., non-operational) duties

  • Weather (i.e., the provision of wind and weather sensors and the collection and processing of weather data from sensors), except that weather products and meteorologist support to ATC are included

Figure 3-1 categorizes NAS elements and subelements as in the domain, partially in the domain, or not in the domain of study, subject to the restrictions noted above.

In performing the analysis of the ATC domain, it was desirable to eliminate design from the resulting model. That is, the model should document what the ATC system does rather than how it is or will be implemented. However, at this stage of development of the ATC system, almost every component is the result of some past design decision. These decisions were not necessarily explicit design decisions in today's sense of designing an automated system, but rather were practical approaches to solving urgent problems. For example, flight plans were devised fifty years ago to provide information concerning the planned route of an aircraft in flight (as well as other information). The flight strip was created as the automatically printed version of the clearance associated with the flight plan, and will have evolved into an electronic flight strip during the time period of interest. All of these components of ATC - the flight plan, the printed flight strip, and the electronic flight strip - represent design. The analysis attempted to extract the requirement ("what") from the design ("how"). However, the decision was made to keep a small number of components of ATC, even though they represent design to some extent, because they are now an integral part of ATC and are unlikely to change much during the time period of interest. (Changes are more likely to occur in the form of the component than in the concept supporting it.) Some examples of retained design are the flight plan, the clearance, and the route. (Each of these classes are described in later sections.)

It was also desirable, in performing the analysis of the ATC domain, to make the resulting model as modular as possible. While the ATC model is forced by its structures to be cohesive, thus increasing modularity, it also contains close coupling between its subjects, thus decreasing modularity. An alternative to the tight coupling would be to eliminate one of the subjects, subsuming the services of its classes into the second subject. However, the tight coupling in this case is a better reflection of the ATC system.

3.1.2 Evolution of ATC from Air Traffic

In a narrow sense, ATC is, as the name implies, the control of air traffic. Before ATC was created, the air traffic world consisted of aircraft to transport passengers and goods, the air (space) in which the aircraft flew, and the airports or fields (ground) which provided a surface for takeoffs, landings, and storage of the aircraft, and for the loading and unloading of the passengers and goods. A representation (model) of this air traffic world showing subjects and structures with two levels of classes is given in figure 3-2. Because the collection of aircraft airborne at the same time was not considered traffic, in the same sense that pedestrians or vehicles along a walkway or street are considered traffic, the class Aircraft is used instead of a class more representative of an organized stream or collection of aircraft. Nevertheless, the model is called an air traffic model to distinguish it from the ATC model described later in this paper.

There are three subjects in the air traffic model, divided in the figure by shaded lines:

• Manager, represented by the class Pilot

• Resource, represented by the classes Airspace, Ground and Aircraft

• User, represented by the classes Passenger, Goods, and Aircraft

An Aircraft object is both a user (of the resources airspace and ground) and a resource (for the users passenger and goods). The pilot is the manager of the aircraft.

Figure 3-1. NAS Elements vs. ATC Model

Figure 3-2. Air Traffic Model: Subjects

Because the aviation world has changed over time, its representation must also change from the simple air traffic model. The control aspects of ATC added many classes to air traffic, to represent functionality such as the following:

• Planning, monitoring, and control responsibilities of human specialists

• Communications between human specialists and aircraft, to transmit information and control instructions

• Surveillance of air traffic, to determine the location, altitude, and speed of aircraft

• Weather product availability, to assist in planning aircraft movement between locations

The addition of air traffic control also resulted in the demarcation of airspace and ground into well-defined smaller subsets because of human limitations in controlling large numbers of aircraft. Some pieces of airspace were defined for special purposes, to allow for military training activities without endangering civilian aircraft. With more humans involved, a greater communications network was needed to support coordination between individual controllers.

The navigation of the aircraft itself became more sophisticated, taking advantage of navigation aids in flying between defined locations.

3.2 THE ATC MODEL

The ATC model also contains only three subjects: User, Resource, and Manager. Each subject contains a structure with a base class of the same name as the subject. In addition, the Manager subject is contained in the User subject. Figure 3-3 shows the three subjects of the ATC model; only the second level of classes is shown.

In general, the following definitions apply to objects of user-, resource-, and manager-type classes (and to specializations of such classes):

• A user is a person or inanimate object which avails itself of a resource, or carries out a purpose or action by means of a resource.

• A resource is a source of supply or support, or a source of information or expertise.

• A manager is a person or inanimate object which handles or directs with a degree of skill, or one that alters by manipulation, or a supervisor, executive, or administrator.

3.2.1 The User Subject

The User subject (see figure 3-3 again) contains two structures: one headed by the Manager class (i.e., the Manager subject) and the other headed by the Traffic class. The Manager class and its structure is discussed in section 3.2.3 below. The remainder of this section concentrates on the Traffic class structure.

The Traffic class of the ATC model (see figure 3-4) is an expansion of the Aircraft class of the air traffic model. Because of the shift in emphasis from air traffic (i.e., the aircraft) to air traffic control, the other user classes of the air traffic model (the Passenger class and the Goods class) do not appear in the ATC model, and the aircraft is no longer considered to be a resource. In other words, the user in the ATC model is a user of resources from an air traffic control viewpoint, rather than a user of the Aircraft as a resource.

Figure 3-3. ATC Model Subjects

Figure 3-4. ATC Model: User Subjects (Traffic)

3.2.1.1 The Aircraft Class

Because an Aircraft object is no longer considered a resource, a Pilot object is no longer considered a manager and becomes instead a part of the Aircraft object. Other parts are added to the Aircraft object to reflect its interaction with air traffic control resources, including the Vehicle Surveillance System object, the Vehicle Navigation System object, and the Vehicle Communications System object. The Transponder class is provided as a specialization of the Vehicle Surveillance System class, because the term "transponder" is a more common term for that equipment.

3.2.1.2 The Ground Vehicle Class

ATC at an airport applies to ground vehicles, such as fuel trucks and baggage carts, as well as to aircraft. As with an Aircraft object, the parts of an Ground Vehicle object reflect interaction with air traffic control resources. These parts include the Ground Vehicle Operator object (analogous to the Pilot object), the Vehicle Surveillance System object, the Vehicle Navigation System object, and the Vehicle Communications System object. The Transponder class is still appropriate as a specialization of the Vehicle Surveillance System class.

3.2.1.3 The Flight and Vehicle Classes

Because control has been introduced for vehicles, the simple Aircraft and Ground Vehicle classes are not sufficient by themselves. The Flight class and the Vehicle class are added to reflect new functionality, taking into account the following factors:

• The type of vehicle and its location (in the air or on the ground) when control applies. An aircraft, when it is on the ground, is considered a vehicle as well as part of a flight. (Stated in object-oriented terms, an Aircraft object can simultaneously have a whole-part relationship with both a Flight object and a Vehicle object.)

• The formality inherent in control when it exists (the planning initiated for the movement of a vehicle, as reflected by a plan, and the approval to move as planned, as reflected by a clearance). A Flight object is considered to have three intrinsic parts: zero to many Aircraft objects, at most one Flight Plan object, and at most one Flight Clearance object. Similarly, a Vehicle object has three parts: an Aircraft object or a Ground Vehicle object, a Ground Vehicle Route object, and a Ground Clearance object.

The Flight Class. The rationale for the whole-part relationship between a Flight object and its parts (Aircraft object, Flight Plan object, and Flight Clearance object) is most easily understood for an en route instrument flight rules (IFR) flight. In this case, by necessity, there is an aircraft (at least one), a filed (perhaps amended) IFR flight plan, and an en route clearance (perhaps changed several times) to fly according to the flight plan. (On the other hand, for an en route visual flight rules [VFR] flight, there must be an aircraft, there may be a VFR flight plan, and there is no en route clearance.) Throughout the flight, the attributes of the Flight Plan object and the Flight Clearance object are updated to reflect the current values for the flight plan and clearance, as amended during flight.

A Flight Clearance object can also have three parts, a Departure Clearance object, an En Route Clearance object, and an Arrival Clearance object, although probably not all three at the same time. For most of the duration of a flight, the Flight Clearance object has only an En Route Clearance part. The Flight Clearance object usually has at most two parts: either a Departure Clearance object and an En Route Clearance object when the flight is awaiting departure (from a controlled airport) or is in the process of departing, or an En Route Clearance object and an Arrival Clearance object when the flight is about to begin its approach procedures (to a controlled airport). Thus, an IFR flight which has pushed back from the gate and is awaiting takeoff, and which has received instructions to use a Standard Instrument Departure (SID) in takeoff, is represented by a Flight Object with the parts Aircraft object, Flight Plan object, and Flight Clearance; the Flight Clearance object itself has the parts En Route Clearance object and Departure Clearance object.

The Vehicle Class. On the other hand, the Vehicle object always has three parts, since a vehicle can be present on the airport movement area only when the vehicle operator has a plan for its movement (its route) and a human specialist has cleared it to follow this route. The plan for vehicle movement is not a formal instrument in the same sense as the flight plan, but the planned route of the vehicle must be known before movement (even if only seconds before) to the human specialist and the vehicle operator. The ground clearance also might only be given minute-by-minute and not completely specified from source to destination. However, at any point in the vehicle movement, a Ground Vehicle Route object reflects the currently-planned route through the airport movement area and a Ground Clearance object reflects the currently-issued clearance.

3.2.1.4 The Clearance Class

A clearance is an authorization for flight or vehicle movement. In this ATC model, a clearance is the accumulation from the present time of all outstanding clearances and control instructions (those not yet carried out and those in the process of being carried out). ATC instructions (e.g., "turn left heading nine zero," or "clear the runway") issued to a flight (or vehicle) are considered to be amendments to the flight clearance (or ground clearance, respectively) when such instructions change the route, altitude, or speed to be used (where route, altitude, and speed refer to dimensions of movement rather than only to fields in a flight plan).

The Clearance class was created as a convenience to be the generalization class for all other clearance-type classes. The specialization classes of the Clearance class are the Flight Clearance, Ground Clearance, Departure Clearance, En Route Clearance, and Arrival Clearance classes. Although a clearance is not a user, it is part of a user and therefore clearance-type classes are placed in the User subject.

3.2.1.5 The Air Traffic, Ground Traffic, and Traffic Classes

An Air Traffic object allows a grouping of different Flight objects, so that a distinction can be made between when control applies to many flights versus one flight. An Air Traffic object is a whole object in a whole-part relationship, with Flight objects as part objects. A particular Air Traffic object has a defined criterion or set of criteria which determine the Flight object parts. The Air Traffic class is flexible enough that an Air Traffic object can be defined to represent only a few flights, or all the flights in a sector of airspace, or all the flights currently under control in the ATC system. Similarly, a Ground Traffic object forms a whole-part relationship with Vehicle objects. Finally, the Traffic class is a generalization class with the Air Traffic and Ground Traffic classes as specialization classes. The Traffic class is a specialization of the User class.

3.2.2 The Resource Subject

The Resource subject (see figure 3-3) contains one structure, headed by the Resource class. The Resource subject of the ATC model is an expansion of the Resource class of the air traffic model, with the exception that (as stated above) the Aircraft class is removed from the Resource subject. The Resource class is a generalization class with five specialization classes: the Airspace/Ground Resource class, the Surveillance Resource class, the Navigation Resource class, the Communications Resource class, and the Aviation Weather Resource class. The last four classes are not found in the air traffic model.

Each of these five specialization classes is further decomposed into a whole-part structure, rather than a generalization-specialization structure, because the user of the ATC system typically looks at each of these resources as one entity and is not always concerned with exactly which lower-level part is being used. For example, a flight may fly out of one sector and into another, and may be aware of this change in sectors because a radio frequency must be changed, but the flight is not otherwise impacted by the knowledge of exactly which sector it occupies. Similarly, when a flight leaves one area control facility for another with a change in radio frequency, the flight is not impacted by a change in the radio transmitter/receiver used by the ATC ground station (the Air/Ground Communications System object).

Although whole-part decomposition has been used for conceptual clarity, it might be useful to introduce generalization-specialization relationships in addition for ease of implementation. For example, many of the classes in the structures beneath the Airspace/Ground Resource class have the common attributes Capacity, Demand, and Load. Creating a generalization-specialization structure in which each of these classes is a specialization of the Airspace/Ground Resource class would permit such attributes to be inherited directly. With only whole-part structures, the attributes must be redefined for each pert.

The Airspace/Ground Resource class heads a more detailed structure than the Surveillance Resource, Navigation Resource, Communications Resource, or Aviation Weather Resource classes, because it is expected to receive more emphasis in experimentation. The bottom of the Aviation Weather Resource structure is a whole-part decomposition into products and the management of these products. The management is represented by objects separate from the product objects because the management is automated in some cases and manual (human) in others. The Surveillance Resource, Navigation Resource, and Communications Resource structures could also have lowest-level whole-part decompositions into product and management objects. These decompositions were not done because the management of the products is expected to be automated and hence are subsumed as services of the lowest-level objects (i.e., the lowest-level object contains both product and management).

3.2.2.1 The Airspace/Ground Resource Class

The Airspace and Ground classes of the air traffic model are renamed the Controlled Airspace and Airport Movement Area classes, respectively, to reflect the formalization of the structure of the airspace and of the ground. A new Airspace/Ground Resource class (see figure 3-5) is introduced to head the structure; an Airspace/Ground Resource object is a whole object with Controlled Airspace and Airport Movement Area objects as its part objects. (Figure 3-5 is a two part figure; the two parts have the Route and Terminal Route classes in common.)

When the new airspace system is in effect (c. 1995), airspace structure in the contiguous 48 states will be designated by letters (Luffsey, 1990). Luffsey defines the new airspaces as follows:

Airspace A. For airspace at 18,000 feet and above; replaces positive control airspace.

Airspace B. Identical to current Terminal Control Areas.

Airspace C. Identical to current Airport Radar Services Areas, typically covering airspace from the surface to 4,000 feet above the surface.

Figure 3-5. ATC Model: Resource Subject (Airspace/Ground Resource) (Part 1)

Figure 3-5. ATC Model: Resource Subject (Airspace/Ground Resource) (Part 2)

Airspace D. This replaces current Airport Traffic Areas and Control Zones. All Class D airspace will have a common ceiling at 4,000 above the surface.

Airspace E. It replaces all other control airspace ..., including transition areas, controlled areas (airways), and the continental control area. It will be shown on charts. Covers the airspace between the surface and Flight Level 180, or the ceiling of uncontrolled airspace and FL 180.

Airspace G. Corresponds to uncontrolled airspace. Reaches from the ground to the indicated floor of controlled airspace.

With respect to the ATC model, the En Route Controlled Airspace object corresponds to the union of Airspace A and Airspace E, a Terminal Control Area object to a terminal control area (TCA) of Airspace B, an Airport Radar Service Area object to an airport radar services area (ARSA) of Airspace C, and an Airport Traffic Area to an airport traffic area (ATA) of Airspace D.

The Controlled Airspace Class. A Controlled Airspace object is made up of Oceanic Controlled Airspace, En Route Controlled Airspace, and Terminal Controlled Airspace objects as parts. The whole-part structure was chosen because it emphasizes, better than the generalization-specialization structure, the physical decomposition of airspace (even though, as specialization classes, the three classes could have inherited attributes and services from the Controlled Airspace class).

The Oceanic Airspace Class. An Oceanic Controlled Airspace object is made up of Oceanic Airway objects. Non-radar methods are used by ATC for separation purposes, because position reporting rather than radar surveillance must be used for locating aircraft. Hence, for ATC purposes, oceanic airspace is composed of airways rather than of volumes of airspace. (Oceanic airspace volumes might be used in the future if satellite-based surveillance were to be used.) Two types of oceanic airway are the track and the route. A track is a high-altitude one-way airway defined by whole degrees of latitude and longitude. A route is a low-altitude one-way airway defined (as are en route airways) by NAVAIDs. The airspace occupied by a route is defined by its fixes (e.g., VORs, NDBs) and route segments. Thus, the Oceanic Airway class has two specialization classes, the Track class and the Oceanic Route class. An Oceanic Route object has Fix/Waypoint and Route Segment objects as parts, as does a Track object.

The En Route Controlled Airspace Class. The En Route Controlled Airspace object is made up of Route objects and Airspace Volume objects. In some senses, this whole-part relationship introduces redundancy, because any route must occupy airspace (i.e., the intersection of the airspace represented by a Route object and the airspace represented by the appropriate Airspace Volume object is not empty). An alternative representation would be to place the Route class as a specialization of the Airspace Volume class, which only defers the redundancy problem to a lower level in the structure. However, the whole-part structure is believed to be closer to the ATC perspective. An implication for design is that any third object connected to a Route object (by an instance connection) may need to be connected also to the appropriate Airspace Volume object, and vice versa.

The Route class is involved in two structures: a whole-part relationship between a Route object and Fix/Waypoint and Route Segment objects (as does the Oceanic Route object, above) and a generalization-specialization relationship between the Route class and the Jet Route, Airway, Area Route, and Military Training Route classes. While the specialization classes do not add attributes or services to distinguish them from the generalization class, these classes are included because they are commonly differentiated from each other in the ATC world on the basis of aircraft equipage and performance (which, in turn, affects a manager's ability to perform certain services).

The Airspace Volume class was introduced to permit the definition of any arbitrarily-defined volume of airspace. The list of its specialization classes (ACF Airspace [to represent the airspace of an area control facility], Sector, Protected Airspace Volume, and Holding Pattern Airspace) is not meant to be exhaustive, but includes commonly-defined airspace types. Note that an ACF Airspace object has a whole-part relationship with Sector objects, while the Sector class is also a specialization of the Airspace Volume class.

The Terminal Controlled Airspace Class. A Terminal Controlled Airspace object, similar to an En Route Controlled Airspace object, is made up of Terminal Route and Terminal Airspace Volume objects.

The Terminal Route class is involved in two structures: a whole-part relationship between a Terminal Route object and Fix/Waypoint and Route Segment objects (as does the Oceanic Route object, above) and a generalization-specialization relationship between the Terminal Route class and the Standard Terminal Arrival Route (STAR), Standard Instrument Departure Route (SID), and Preferential Route classes. The Preferential Route class has three specialization classes: the Preferential Departure Route (PDR) class, the Preferential Arrival Route (PAR) class, and the Preferential Departure and Arrival Route (PDAR) class. A STAR object can have a whole-part relationship with a PAR object (with the PAR as the part), and a SID object can have a whole-part relationship with a PDR object (with the PDR as the part).

The Terminal Airspace Volume class has three specialization classes: the Terminal Control Area (TCA) class, the Airport Radar Services Area (ARSA) class, and the Airport Traffic Area (ATA) class. While the specialization classes do not add attributes or services to distinguish them from the generalization class, these classes are included because they are commonly differentiated from each other in the ATC world. In addition, this decomposition of a Terminal Controlled Airspace object does not represent all of the airspace around an airport, but instead focusses on those types of airspace for which capacity and saturation are of interest. Note that a particular PDAR usually is physically contained in more than one terminal airspace volume.

The Preferred IFR Route class is introduced here, although it is related to both en route airspace and terminal airspace. A Preferred IFR Route object has a whole-part relationship with the part objects Route, PDR, and PAR.

The Airport Movement Area Class. The Airport Movement Area class represents the ground surface used by ground vehicles and aircraft at an airport. For consistency, a helicoptor that is taxiing around an airport (whether ground taxiing, hover taxiing, or air taxiing) is considered to be using the Airport Movement Area. A particular Airport Movement Area object can have a whole-part relationship with one or more Runway objects, none to several Taxiway objects, and none to several Holding Area objects.

3.2.2.2 The Surveillance Resource Class

Figure 3-6 contains the structures for the following four specializations of the Resource class: the Surveillance Resource class, the Navigation Resource class, the Communications Resource class, and the Aviation Weather Resource class. As described in section 3.2.2, these structures are less detailed than the Airspace/Ground Resource structure, because the corresponding resources are expected to receive less emphasis in I-Lab experimentation. This section discusses the Surveillance Resource class.

Figure 3-6. ATC Model: Resource Subject (Other Resources)

A Surveillance Resource object, made up of Surveillance System objects, represents the equipment for the tracking of aircraft positions and the management of the information provided (e.g., the reporting of positions). Here, "management" means "management of the product" or "management information system" rather than "equipment maintenance." In addition, the Surveillance System class refers only to the surveillance functionality of the ATC system: surveillance capabilities of an individual Aircraft object used in interacting with a Surveillance System object (e.g., the ability of an aircraft transponder to reply to interrogation by surveillance radar) are included in the Vehicle Surveillance System object that is a part of the Aircraft object.

Specializations of the Surveillance System class include the Airspace Surveillance System class and the Ground Surveillance System class. While the specialization classes do not add attributes or services to distinguish them from the generalization class, these classes are included because they are commonly differentiated from each other in the ATC world.

3.2.2.3 The Navigation Resource Class

A Navigation Resource object (see figure 3-6), made up of Navigation System objects, represents the navigation aids provided by the ATC system to assist aircraft in navigating between points and the management of the information provided (e.g., the broadcasting of a NAVAID position by radio signal). Again,"management" means "management of the product" or "management information system" rather than "equipment maintenance." Again, the Navigation System class refers only to the navigation functionality of the ATC system: navigation capabilities of an individual Aircraft object used in interacting with a Navigation System object (e.g., the ability of an aircraft VOR/DME-based RNAV unit to receive, interpret, and use radial and distance information from a VOR/DME facility) are included in the Vehicle Navigation System object that is a part of the Aircraft object. Also, the Navigation System class refers only to those navigation systems certified by the FAA to be a primary navigation system, for example, VOR-DME systems and LORAN-C systems, but not VLF/OMEGA systems. When satellite-based navigation is certified as primary, it can be added to the model.

The Navigation System class has one specialization, the Landing Navigation System class. The primary reason for including a Landing Navigation System class is that many landing navigation systems can provide elevation information to an aircraft whereas most navigation systems used in en route or terminal airspace do not. Thus, a Landing Navigation System object might provide the additional service Transmit Elevation but the more general Navigation System object can provide only the inherited services.

3.2.2.4 The Communications Resource Class

A Communications Resource object (see figure 3-6), made up of Communications System objects, represents the communications media provided by the air traffic control system for the transfer of information between the ATC system and aircraft (e.g., the transfer of a clearance amendment by radio from a human specialist to an aircraft) and among ATC system components (e.g., for coordinating a handoff). Again,"management" means "management of the product" or "management information system" rather than "equipment maintenance." Again, the Communications System class refers only to the communications functionality of the ATC system: communications capabilities of an individual Aircraft object used in interacting with a Communications System object (e.g., the ability of an aircraft to receive the radio transmission of clearance information) are included in the Vehicle Communications System object that is a part of the Aircraft object.

Specializations of the Communications System class include the Interfacility Communications System class, the Intrafacility Communications System class, and the Air/Ground Communications System class. While the specialization classes do not add attributes or services to distinguish them from the generalization class, these classes are included because they are commonly differentiated from each other in the ATC world.

3.2.2.5 The Aviation Weather Resource Class

An Aviation Weather Resource object (see figure 3-6), made up of Aviation Weather System objects, represents the wind and weather products available to users of the ATC system (e.g., an area forecast, a surface aviation weather report) to assist in flight planning, and the management of basic wind/weather products in the creation of specialized products. (e.g., a preflight weather briefing). Again,"management" means "management of the product" or "management information system" rather than "equipment maintenance."

An Aviation Weather System object has two parts: Wind/Weather Product object(s) and Aviation Weather System Manager object(s). The Aviation Weather System Manager class is included in this ATC model for convenience, but the Aviation Weather System Manager class, strictly speaking, does not belong in this ATC model: the functionality represented by this class (e.g., the duties of a meteorologist) is not a function of ATC. For this model, the services of an Aviation Weather System Manager object are restricted to creating standard wind and weather reports and to creating specialized reports at the request of a Flight Manager object or a Traffic Manager object.

3.2.3 The Manager Subject

As stated in section 3.2.1 and illustrated by figure 3-3, the Manager structure belongs to both the Manager subject and the User subject.

The Manager subject (see figure 3-7) contains one structure, headed by the Manager class. Because the Pilot class has moved from the Manager subject of the air traffic model to the User subject of the ATC model, the Manager subject of the ATC model is completely different from the Manager subject of the air traffic model.

The structure and classes beneath the Manager class are closely coupled to the structure and classes beneath the Traffic class of the User subject, which is made obvious by the class names within both subjects.

The Manager class is a generalization of the Traffic Manager class, the Flight Manager class, and the Vehicle Manager class. The class names were selected to emphasize that the traffic manager manages traffic, the flight manager manages flights, and the vehicle manager manages vehicles. The Traffic Manager class is a generalization of the Air Traffic Manager Class and the Ground Traffic Manager class. As above, the air traffic manager manages air traffic, and the ground traffic manager manages ground traffic.

The manager classes are not synonymous with today's positions (e.g., air traffic controller, flight service station specialist, traffic management specialists, CARF specialists , traffic management coordinator). Rather, each manager class encapsulates the services inherent in managing a particular type of user (e.g., vehicle) and the airspace/ground resources it needs (e.g., airport movement area). However, any existing position can be characterized as a specialization of one or more of the manager classes. For example, the local controller could be considered a specialization of both the Flight Manager class (by accepting control of a flight and delivering a landing clearance to that flight) and the Vehicle Manager class (by controlling an aircraft's use of a runway resource).

Figure 3-7. ATC ModelL Manager Subject

As stated above, a manager-type object manages the use of an airspace/ground-type resource. The decision to place these resource management services in a manager-type object was made because, in the timeframe of interest, such management services will be shared by the human and automation. The services of a manager-type object do not make a distinction between the human and automation.

In contrast, the management of the other types of resources, which is expected to remain automated, is left encapsulated within the resource-type object. An Aviation Weather System Manager object, which does contain services performed by the human, is not properly within the ATC model (i.e., is not an ATC manager) and is left as a part of an Aviation Weather System object.

As part of the User subject, a manager-type object uses resources, including communications systems and aviation/weather systems. A manager-type object needs to use an Air/Ground Communications System object in order to talk with a Pilot object, an Intrafacility Communications System object to talk with another manager-type object in the same facility, and an Interfacility Communications object to talk with a manager-type object in another facility. A manager-type object needs to use aviation weather reports and the services of an aviation/weather system manager in order to get wind and weather information to assist flights in flight planning and weather avoidance.

3.2.4 INSTANCE CONNECTIONS

Because a relationship between a class (or an object) and another class (or object) in the same subject tends to be represented by a generalization-specialization structure or a whole-part structure, the instance connections in the ATC model (with one exception) represent relationships between objects in different subjects. The one exception is that two or more Flight objects (both in the User subject) might be connected by instance connections, as described in section 3.2.4.4 below.

Figure 3-8 summarizes the instance connections of the ATC model. The attributes shown in the figure are those used in establishing specific instance connections. The structure beneath the Traffic class and object (which does not represent the entire structure) is provided only as a convenient framework to facilitate understanding the various relationships.

The figure also clarifies exactly which classes and objects are "user-type" or "manager-type" classes and objects. A "user-type" object is any user of a resource. User-type refers to the following classes and objects: Traffic, Air Traffic, Ground Traffic, Flight, Vehicle, Aircraft, Ground Vehicle, Vehicle Surveillance System, Vehicle Navigation System, Vehicle Communications System, and all the classes and objects in the Manager subject.

A "manager-type" object is any manager of a resource, in the sense of planning the usage of the resource or granting permission to use it. Manager-type refers to the following classes and objects: Traffic Manager, Air Traffic Manager, Ground Traffic Manager, Flight Manager, and Vehicle Manager. The names of the manager-type classes parallel the names of the user-type classes. Notice that there are no managers for Surveillance System, Navigation System, or Communications System objects, because such objects are essentially first-come first served with no explicit requests for usage. The management of such objects is assumed to be a service of the resource itself.

A "resource-type" class or object is any class or object from the structure headed by the Resource class and object; an "airspace resource-type" class or object is any class or object from the structure headed by the Controlled Airspace class and object; and a "ground resource-type" class or object is any class or object from the structure headed by the Airport Movement Area class and object.

The following sections describe the instance connections in the ATC model and are organized by subject pairs. The views in section 3.2.6 provide specific examples.

Figure 3-8. ATC Model: Instance Connections

3.2.4.1 User-Manager Instance Connections

The instance connections between user-type objects and manager-type objects reflect the close coupling between users and managers in the ATC model. In each case, the instance connections exist because the user-type object is in the area of responsibility of the manager-type object. Typically, the instance connection between a Flight object and a Flight Manager object is created when the flight manager assumes control responsibility for the flight (e.g., via handoff) and deleted when control responsibility is given up. Before a flight is active, an instance connection might exist based on the fact that the Flight Manager is providing flight planning assistance; here, control responsibility may or may not be involved. An instance connection between a Vehicle object and a Vehicle Manager object typically exists to show control responsibility.

An instance connection between a traffic-type object (Traffic, Air Traffic, or Ground Traffic object) and a traffic manager-type object (Traffic Manager, Air Traffic Manager, or Ground Traffic Manager object) exists to facilitate the planning and management of airspace/ground-type resource usage. Such an instance connection is defined by that grouping of Flight objects or Vehicle objects with which the manager is concerned. Two different traffic-type objects, with instance connections to different traffic manager-type objects, might have Flight objects in common. For example, one Air Traffic Manager object might be interested in the planned airspace usage by all Flights in a given Area Control Facility (ACF), while another Air Traffic Manager object might be interested in all Flights in that ACF as well as in the adjacent ACFs.

3.2.4.2 Manager-Resource Instance Connections

An instance connection exists between a manager-type object and an airspace/ground resource-type object to show that the resource is in the manager's area of responsibility. The instance connection is created when the resource-type object is created, deleted when the resource-type object is deleted, and typically not otherwise changed. There are no instance connections between manager-type objects and objects of other types of resources (e.g., surveillance system objects) because the management of these other resources is encapsulated as services within the resource-type objects.

An instance connection between a traffic manager-type object (e.g., a Ground Traffic Manager) and an airspace/ground resource-type object (e.g., an Airspace Movement Area object) shows that the traffic manager-type object is responsible for the capacity planning and general usage planning of the resource-type object. An instance connection between another type of manager object (e.g., a Vehicle Manager object) and an airspace/ground resource-type object (e.g., a Taxiway object) shows that the manager-type object is responsible for the specific usage planning (by a Vehicle object or Flight object) and the granting of permission to use the resource-type object.

3.2.4.3 User-Resource Instance Connections

Instance connections between user-type objects and resource-type objects are created for different reasons, depending on whether the resource-type object is an airspace/ground resource-type object or another type.

Instance Connections Between a User and an Airspace/Ground-Type Resource. An instance connection between a user-type object and an airspace/ground resource-type object is based on either demand (i.e., the user-type object plans to use the airspace/ground resource-type object) or load (i.e., the user-type object is using the airspace/ground resource-type object). A Flight object that plans to use an airspace resource-type object has an instance connection with it and contributes to the value of its Demand attribute. Similarly, a Vehicle object that plans to use an ground resource-type object has an instance connection with it and contributes to the value of its Demand attribute. On the other hand, an Aircraft object with Location attribute value contained in the Location attribute value of an airspace resource-type object has an instance connection with that resource-type object and contributes to the value of its Load attribute. Similarly, a Vehicle object with Location attribute value contained in the Location attribute value of a ground resource-type object has an instance connection with that resource-type object and contributes to the value of its Load attribute.

Instance Connections Between a User and Another Type of Resource. An object of a Surveillance System class, Navigation System class, or Communications System class (or one of its specializations) has an instance connection with an object of a Vehicle Surveillance System class, Vehicle Navigation System class, or Vehicle Communications System class (respectively) when the Equipment Type attributes of the former and latter objects are compatible, the value of the Status attribute of each (when it exists) is "active" or "operational" or is otherwise appropriate, and the latter object is in the area of coverage of the former object. This relationship is somewhat like the "load" relationship above, but there is no corresponding "demand" relationship.

A manager-type object has an instance connection with an object of the Communications System class (or one of its specializations) when the manager-type object is in the area of coverage of the communications system and the status of the communications system is "operational."

3.2.4.4 User-User Instance Connections

A Flight object represents only a flight segment, that is, the flight from departure at one airport to arrival at the next airport. However, it is of interest sometimes to examine a sequence of flight segments. Instance connections between pairs of Flight objects can be created to define, for example, a flight itinerary or an airframe itinerary. A flight itinerary describes a "continuing flight" with stops en route (e.g., a flight known to passengers by a particular flight number) and can be used to study accumulated flight delay. An airframe itinerary describes the use of a particular aircraft ("airframe") during flight segments and can be used to track and schedule maintenance for that aircraft.

More than one instance connection is possible between the same two Flight objects, and other associations are possible. Of course, different attributes and rules are needed to represent each kind of instance connection. For example, the instance connection between two Flight objects of the same flight itinerary is based upon the following:

• The two flights have the same aircraft callsign (Aircraft Identification attribute of the Flight Plan object).

• The arrival airport (Destination attribute of the Flight Plan object) of the first Flight object is the same as the departure airport (Departure Point attribute of the Flight Plan object) of the second Flight object.

• The estimated arrival time (based on the Departure Time and Estimated Time En Route attributes of the Flight Plan object) of the first Flight object reasonable precedes the estimated departure time (Departure Time attribute of the Flight Plan object) of the second Flight object.

3.2.5 Message Connections

Message connections are not as easily depicted in one figure as are instance connections, and are described in appendix A. The views in section 3.2.6 provide examples of services.

3.2.6 Views

This section contains a small set of views, some considered to be of special interest and others merely illustrative, but all in line with the task scope to emphasize horizontal details over vertical details. Other views can easily be constructed. In one case, an object state diagram is provided because the view illustrates a change in object state.

The following views are included in this section:

• Clearance to enter airport movement area event

• Handoff to flight manager (flight state change) event

• Problem detection and resolution events

  • Aircraft-to-aircraft conflict event

  • Aircraft-to-airspace conflict event

  • Flow instruction problem event

• Airspace/ground saturation detection and resolution event

• Clearance delivery (communications) event

• NAVAID use (navigations) event

• Tracking (surveillance) event

• Weather events

  • Preflight briefing event

  • Weather area event

3.2.6.1 Clearance to Enter Airport Movement Area Event

Figure 3-9 is the view of an event in which a vehicle (in this case, an aircraft) is given permission ("clearance") to enter an airport movement area. At the beginning of the event, the Vehicle object is made up of only an Aircraft object (i.e., there is no Ground Vehicle Route object or Ground Clearance object). The Aircraft object has two parts of interest, a Pilot object and a Vehicle Communications System object. The Vehicle object has an instance connection with the Airport Movement Area object because the vehicle plans to use the airport movement area, but the Vehicle object does not yet have any instance connections with any other part of the airport movement area (e.g., taxiway) at this time because the vehicle has no plan for or permission for the use of any particular part of the airport movement area. The Airport Movement Area object, in turn, has instance connections with one or more Vehicle Manager objects, because any vehicle wishing to enter the Airport Movement Area must receive permission from a Vehicle Manager object. The instance connection between the Vehicle object and the appropriate Vehicle Manager object is created dynamically (shown by the dashed line) based on these other two connections and upon the fact that the Vehicle and the Vehicle Manager must use the same communications frequency.

Figure 3-9. Clearance to Enter Airport Movement Area Event

Typically, a user-type object from the traffic hierarchy, an airspace/ground resource-type object, and a manager-type object exist as a triad connected by instance connections. The airspace/ground resource-type object needs an instance connection with a manager-type object to indicate which manager has the authority to grant permission to use the resource. The user-type object needs an instance connection with a manager-type object to request permission to use an airspace/ground resource. The airspace/ground resource-type object needs an instance connection with the user-type object to indicate that the demand by the user is accounted for.

The three instance connections are created as needed. The instance connection between an airspace/ground resource-type object and a manager-type object is created when the airspace/ground resource-type object is created, and is determined by the area of responsibility of the manager. When a Vehicle object is first created, an instance connection is created between the Vehicle object and the appropriate Airport Movement Area object. No other instance connections between the Vehicle object and parts of the Airport Movement Area object are possible until permission for use is granted and recorded in a Ground Vehicle Route object. Similarly, when a Flight object is first created, an instance connection is created between the Flight object and the Controlled Airspace object. Other instance connections can be made only after a Flight Plan is created. The instance connections between the user and the resource, and between the manager and the resource, typically exist first, and the appropriate instance connection between the user and the manager is determined based upon the first two connections and other appropriate information.

Although communications are deliberately not emphasized here, the pilot must use a frequency of an air/ground communications system and the active frequency of the vehicle communications system must be that same frequency. (See the clearance delivery [communications] event in section 3.2.6.5 also.) In this example, the Vehicle object already had an instance connection with an Airport Movement Area object, and a Vehicle Manager object already had an instance connection with the same Airport Movement Area object. Thus an instance connection could be created by the Vehicle class between the Vehicle object and the Vehicle Manager object once the common frequency was known, allowing the Pilot object to send messages to the correct Vehicle Manager object. The Pilot object, in performing the service Request Movement, sends a message to the Vehicle Manager object with which the Vehicle object has an instance connection requesting a pushback clearance. The Vehicle Manager, in performing its service Generate & Deliver Clearance, must first determine the availability of a taxiway for use by the aircraft: this the Vehicle Manager does by accessing the Configuration attribute of the Airport Movement Area (to see what taxiways are appropriate) and the attributes of the appropriate Taxiways objects (to see if any can be used). The Vehicle Manager object has instance connections with the Taxiway objects within its area of responsibility. When an appropriate taxiway is planned to be available (i.e., capacity is predicted to be available to meet the new demand), the Vehicle Manager object returns a response to the Pilot object with the pushback clearance.

Upon receiving the pushback clearance, describing at least part of the approved route (e.g., which taxiway to follow), the Pilot object requests the Ground Vehicle Route class to instantiate a Ground Vehicle Route object with appropriate values for the Ground Route attribute, and requests the Ground Clearance class to instantiate a Ground Clearance object with appropriate values of the Route attribute. The Ground Vehicle Route object then requests the Vehicle class to establish an instance connection (shown by dotted line) between the original Vehicle object and the Taxiway object. The purpose of this instance connection is to establish that this particular Vehicle object is to be accounted for in determining the value of the Taxiway attribute Demand; in fact, the Vehicle object then sends a message to the Taxiway object requesting the Update Demand service of the Taxiway object be performed. None of these instance connections are needed after the Vehicle object is deleted, which can happen once the vehicle leaves the airport movement area (e.g., the aircraft leaves the ground on takeoff).

This view looks at an Aircraft object as part of a Vehicle object. Considering the Aircraft object as part of a Flight object, a view of (say) a predeparture clearance could be constructed with Flight Manager, En Route Controlled Airspace, Flight, Aircraft, Flight Plan, and Flight Clearance objects. Thus an Aircraft object can be viewed simultaneously as part of both a Vehicle object and a Flight object.

3.2.6.2 Handoff to Flight Manager (Flight State Change) Event

The Flight object has five states (see figure 3-10): predeparture, departure, en route, arrival, and postarrival. The following short description applies to the usual flight; some details differ for particular flights (e.g., a VFR flight without a flight plan, a flight that files its flight plan after it is airborne). The predeparture state corresponds to that time before the aircraft makes use of the airport movement area of an airport; during this time period, the initial flight planning, including the receipt of weather briefings and the filing of the flight plan, is completed. The departure state corresponds to that time spent on the airport movement area of the departure airport for taxiing and takeoff and in the air until handed off to an en route controller. (There is no en route state for a tower en route flight.) The en route state lasts until the flight is given the arrival clearance for its destination airport. The arrival state lasts until the aircraft lands and leaves the airport movement area of the destination airport. The postarrival state exists essentially to allow for flight plan closing (although an IFR flight plan is considered closed upon arrival at a controlled airport). The states of a flight are defined to correspond to the assignment of the manager rather than to the airspace/ground resource used (although this is a fine point, because the managers and the airspace/ground resources are also closely related). That is, a change in flight state is associated with a change in manager rather than with a change in resource usage.

Figure 3-11 is a view of an event causing a change in flight state from departure to en route. At the beginning of the event, a Flight object exists with three parts of interest: an Aircraft object, a Flight Plan object, and a Flight Clearance object. The Flight Clearance object has two parts: a Departure Clearance object and an En Route Clearance object. The Flight object has an instance connection with a Flight Manager object, called here "Flight Manager 1." Flight Manager 1, in performing its service Monitor Flight Location, compares the boundary and altitude limits of the Terminal Control Area (TCA) to the aircraft location and determines that the flight is about to leave the TCA. From the flight plan, Flight Manager 1 infers that the aircraft is following its planned route and decides to attempt to transfer control responsibility to the flight manager ("Flight Manager 2") associated with the en route sector to which the flight is headed. Flight Manager 1 sends a message to Flight Manager 2 requesting the acceptance of control responsibility for the flight. Flight Manager 2 accesses the Capacity, Demand, Load, Saturation Threshold, and Usage Restriction attributes of the Sector object to determine if control of the flight should be accepted, replying to Flight Manager 1's message that control is accepted. Flight Manager 1 then performs its Direct Transfer of Communications service to request the Pilot object to send future communications to Flight Manager 2. The Pilot object sends a message to the Vehicle Communications System object requesting that the Active Frequency attribute be updated. The Vehicle Communications System object, in turn sends a message to the Flight object requesting it to delete the instance connection between the Vehicle object and Flight Manager 1 and to create an instance connection between the Vehicle object and Flight Manager 2. The Pilot object also sends a message to the Departure Clearance class requesting it to delete the Departure Clearance object.

Figure 3-10. Flight States

Figure 3-11. Handoff to (En Route) Flight Manager Event

At the beginning of the event, there are instance connections between the Flight object and the Flight Manager object called Flight Manager 1 (because Flight Manager 1 controls the flight), between the Flight object and the Terminal Control Area object (because the flight still contributes to the value of the Demand attribute of the Terminal Control Area object), and between the Flight object and the Sector object (because the Flight object also contributes to the value of the Demand attribute of the Sector object). As a result of the transfer of control responsibility ("handoff"), the Flight class can delete the instance connection between the Flight object and Flight Manager 1, delete the instance connection between the Flight object and the Terminal Control Area object, and add an instance connection between the Flight object and Flight Manager 2. As a consequence of deleting the instance connection between the Flight object and the Terminal Control Area object, the Flight class also sends a message to the Terminal Control Area objectrequesting it to update the value of its Demand attribute.

The instance connections between the Flight object and airspace/ground resource-type objects are created as soon as the Flight Plan object part of the Flight object exists, are based on the resources to be used by the flight (as documented by the flight plan), and are used to update the Demand attribute of each applicable resource object. Each of these instance connections is updated with each update of the Flight Plan object and can be deleted as soon as the planned use of the resource-type object is no longer in the future. When the Flight class deletes an instance connection between a Flight object and an airspace/ground resource-type object, the Flight class must also send a message to the airspace/ground resource-type object requesting it to update the value of its Demand attribute.

The instance connection between the Aircraft object and the Terminal Control Area object indicates that the aircraft is occupying the TCA and that the aircraft is being taken into account in the Load attribute of the Terminal Control Area object. This instance connection is maintained by the Aircraft class upon request by the appropriate Surveillance System object (not shown here). The Aircraft class can delete the instance connection between the Aircraft object and the Terminal Control Area object as soon as the surveillance system detects that the aircraft has left the TCA, and, as above, the Aircraft class must send a message to the Terminal Control Area object to update the valus of its Load attribute.

Throughout the event, there is an instance connection between Flight Manager 1 and the Terminal Control Area object, and between Flight Manager 2 and the Sector object, indicating that each of the airspace resource-type objects is in the area of responsibility of the appropriate manager-type object.

Note that services performed by the manager-type objects in this view (e.g., offering and accepting handoff, checking for availability of resources) might be performed by automation or by humans.

3.2.6.3 Problem Detection and Resolution Events

The following three types of problems in the AERA 2 timeframe are of interest:

• Aircraft-to-aircraft conflict: the actual or predicted violation of separation minima between two aircraft

• Aircraft-to-airspace conflict: the actual or predicted violation of separation minima between an aircraft and a protected airspace volume

• Flow instruction problem: the actual or predicted noncompliance of an aircraft with a flow instruction

This section contains a view illustrating an event involving each type of problem.

Figure 3-12. Aircarft-to-Aircraft Conflict Detection and Resolution Event

Aircraft-to-Aircraft Conflict Detection and Resolution Event. Figure 3-12 is a view of an aircraft-to-aircraft conflict event. At the beginning of the event, a Flight Manager object (called "Flight Manager 1") with an instance connection with the En Route Controlled Airspace object has been performing its service Detect, Predict & Report Separation Violation. In this event, a violation of separation minima is predicted between two IFR flights that are planned to be in the same sector at the same time (put another way, two Flight objects with type IFR and with instance connections to the same Sector object in the same time period are predicted to have locations closer than separation minima). (This situation might arise because of earlier uncertainty in prediction, because neither flight would likely be granted permission to plan to cause an aircraft-to-aircraft conflict.) For this example, it is assumed that the two Flight objects now have instance connections to the same Flight Manager object, called "Flight Manager 2." Flight Manager 1 sends a message to Flight Manager 2, requesting the performance of the Separate IFR Flights service. In carrying out this service, Flight Manager 2 also performs the general service Generate & Deliver Clearance, requesting the pilot of one of the two Flight objects ("Flight 2") to perform its service Plan Flight. (If Flight Manager 2 had decided to move both aircraft, then a message would be sent to the Pilot object of Flight 1 as well.) If the Plan Flight service determines that the proposed change to the flight plan and clearance cannot be accepted, then a negative response is returned to Flight Manager 2; otherwise, a positive response is returned and the Pilot object requests the Flight Plan object to amend itself and requests the En Route Clearance object to amend itself. The attributes of the Flight Plan which are affected by the Amend Flight Plan service are determined by the actual amendment. Similarly, the affected En Route Clearance attributes are determined by the actual amendment.

This view makes use of two (possibly) different Flight Manager objects, called Flight Manager 1 and Flight Manager 2. Flight Manager 1, which is connected to the En Route Controlled Airspace object, is given the responsibility (the service) of determining aircraft conflicts, even though the conflict itself, in this example, is occurring in a lower-level part of the object. (It is not sufficient to have each sector checked independently for conflicts, because conflicts can occur between flights in two different sectors.) During the design phase, Flight Manager 1 and Flight Manager 2 may be defined to be the same object by placing an instance connection between Flight Manager 2 and each sector in its area of responsibility and each adjacent sector.

Note that the Flight Manager object is not necessarily a human being: the services of a Flight Manager object could be carried out partly by automation and partly by a human.

Aircraft-to-Airspace Conflict Detection and Resolution Event. Figure 3-13 is a view of an aircraft-to-airspace conflict event. In this case, the conflict is a detected violation of separation minima rather than a predicted violation (as in the previous view). At the beginning of the event, a Flight Manager object (called "Flight Manager 1") connected with a Protected Airspace Volume object (by instance connection) has been monitoring the actual locations of aircraft in the vicinity of the protected airspace volume as part of its service Monitor Flight Location. This monitoring is done by assessing the Location attribute of Aircraft objects within or adjacent to Flight Manager 1's area of responsibility. The service Detect, Predict & Report Separation Violation (using the attributes Type, Boundary, Altitude Limits, Schedule, and Separation Minima) determines that the location of an aircraft is within a separation minima distance of the airspace, and the aircraft has not been granted an exemption to enter the airspace (according to the attribute Exemptions). Flight Manager 1 determines that the Aircraft object is part of a specific Flight object which has an instance connection to a specific Flight Manager object (called "Flight Manager 2"). Flight Manager 1 then sends a message to Flight Manager 2 requesting the service Separate IFR Flights. In performing that service, Flight Manager 2 uses the service Generate & Deliver Clearance to request (by message to the pilot of the Flight object) that the Flight adhere to its existing clearance (which did not permit flying closer to the airspace than the separation minima). (Note: If the clearance had permitted flying close to or through the protected airspace volume, the permission would have been reflected in the Exemptions attribute of the Protected Airspace Volume object. Alternatively, Flight Manager 1 could have accessed the Flight Plan object or the En Route Clearance object of each aircraft of interest.)

As in the previous view, Flight Manager 1 and Flight Manager 2 might be the same object. When a Protected Airspace Volume object is physically contained within more than one Airspace Volume object, the Flight Manager objects might be different objects.

Figure 3-13. Aircraft-to-Airspace Conflict Detection and Resolution Event

In this view, the triggering event was related to the activity of an Aircraft object. An alternative airspace conflict view could be constructed to illustrate the result of a change to a Protected Airspace Volume object. Here, it would be necessary to determine the instance connections between the Protected Airspace Volume object and all appropriate Flight objects (creating instance connections if the Protected Airspace Volume object is just being created) in order to predict violations of separation minima as well as to detect violations of separation minima (as above).

Flow Instruction Problem Detection and Resolution Event. Figure 3-14 is a view of a flow instruction problem event, in this case a predicted noncompliance with a flow instruction recorded in the Usage Restrictions attribute of a Route object. At the beginning of the event, the Pilot object wants to change the Route attribute of the Flight Plan object in such a way that the flight will use the Route object. The Flight object is connected by an instance connection to a Flight Manager object (called "Flight Manager 2"). The Pilot object sends a message to Flight Manager 2 requesting approval of the change in route. Flight Manager 2, in turn, determines that the Route object is connected by instance connection with another Flight Manager object, called "Flight Manager 1." Flight Manager 2 sends a message to Flight Manager 1 requesting permission for the Flight object to use the Route object. Flight Manager 1 performs its service Detect, Predict & Report Restriction Violation. Comparing the Route attribute of the Flight Plan object with the Usage Restrictions attribute of the Route object, Flight Manager 1 determines that a noncompliance with a flow instruction would exist if the route change were approved, and so informs Flight Manager 2. Flight Manager 2 then performs its service Ensure Restriction Compliance to determine if a feasible alternative exists, and finding none (in this example), returns a response to the Pilot object denying the request.

For simplicity in this view, only one Route object is shown as the new resource to be used. Most likely, a proposed route change would involve several resources, and Flight Manager 2 would need to find out the impact of the change on each before responding to the Flight object.

Also for simplicity, the view shows Flight Manager 1 only checking for restriction violations; in fact, separation violations would also be checked for by the Flight Manager service Detect, Predict & Report Separation Violation.

3.2.6.4 Airspace/Ground Resource Saturation Detection and Resolution Event

Figure 3-15 illustrates an event in which a ground-type resource (an Airport Movement Area object) is predicted to become saturated at a future time. The Airport Movement Area object is connected to a Ground Traffic Manager object by an instance connection. The Ground Traffic Manager, in performing its service Detect, Predict & Report Saturation, compares the value of the Airport Movement Area object's attribute Demand with the values of its attributes Saturation Threshold and Capacity and finds that demand for a particular future time period is no longer less than the saturation threshold for that same time period. The Ground Traffic Manager object then performs its service Resolve Ground Saturation Problem. In performing that service, the Ground Traffic Manager object has several alternatives available; for this example, the Ground Traffic Manager object decides to request the Air Traffic Manager object associated, by instance connection, with a particular Fix/Waypoint object to perform its service Determine Airspace Capacity by placing restrictions for a corresponding time period on the usage of the Fix/Waypoint object by Flight objects. The Air Traffic Manager object approves the request and in turn requests the Fix object to update the value of its Usage Restrictions attribute (i.e., access the attribute to set a new valus).

Figure 3-14. Flow Instruction Problem Detection and Resolution Event

Figure 3-15. Airspace/Ground Resource Saturation Detection and Resolution Event

While the event pictured stops here, there will be a ripple effect as Flight Manager objects now perform their services Detect, Predict & Report Restriction Violation and Ensure Restriction Compliance, leading to changes to Flight Plan objects and Clearance objects, leading to changes in demand for airspace/ground resource-type objects, leading to reassessments of saturation, and so on.

3.2.6.5 Clearance Delivery (Communications) Event

Figure 3-16 illustrates the use of communications in delivering a clearance. In fact, for all events involving clearance delivery, there is a communications event. However, in order to keep the previous event views simple, the communications part of the event has not been shown.

During a flight, it is not physically possible for a flight manager to talk directly with a pilot; some communications media must be available. Specifically, the Flight Manager object "talks with" a Communications System object, a Pilot object talks with a Vehicle Communications System object, and the Communications System object and the Vehicle Communications System object talk with each other. In fact, the instance connection between a Flight Manager object and a Flight object is defined in terms of the communications frequency of the interfacing communications systems. (The instance connection exists to reflect the control responsibilities of the Flight Manager object with respect to the Flight object, but can be defined in terms of the communications frequency because a change in communications frequency and a handoff of control responsibilities normally occur at the same time.)

In this event, a Flight Manager object wishes to deliver a clearance amendment to a Pilot object. The Pilot object is part of an Aircraft object which is part of a Flight object. The other part of interest of the same Aircraft object is a Vehicle Communications System object. The Flight Manager object is connected with the Flight object by an instance connection. The Flight Manager object knows what communications frequency to use, as well as the ATC communications systems, because the frequency is the basis of the instance connection. In this view, the ATC communications system is represented by an Air/Ground Communications System object. The Flight Manager object sends a message to that Air/Ground Communications System object requesting that object to perform its service Transmit Message in sending the clearance amendment to the Vehicle Communications System object. The Air/Ground Communications System object then sends the message as requested, the Vehicle Communications System object makes the message contents available to the Pilot object, and (assuming the clearance amendment is acceptable) the Pilot object requests the Vehicle Communications System object to return an acknowledgement, the Flight Plan object to amend itself, and the En Route Clearance object to amend itself. The acknowledgement to the clearance is returned by the Vehicle Communications System object via the Air/Ground Communications System object to the Flight Manager object, using the return paths implicit in the original messages.

3.2.6.6 NAVAID Use (Navigation) Event

Figure 3-17 illustrates the use of a NAVAID in the navigation of an aircraft. The NAVAID is considered to be an object of the Navigation System class. The view would also be valid were the NAVAID an object of the Landing Navigation System class.

For this example, it is assumed that the NAVAID is a VOR/DME station and that the aircraft is equipped with a VOR receiver and DME unit. To illustrate the functioning of the VOR receiver as distinguished from the DME unit, an object was created for each as an instantiation of the Vehicle Navigation System class, called (for convenience) "Vehicle Navigation System 1" and "Vehicle Navigation System 2," respectively. Although not done for this view, it would have been possible to use two Navigation System objects to separate out the VOR and DME parts of the navigation system.

Figure 3-16. Clearance Delivery (Communications Event)

Figure 3-17. NAVAID Use (Navigation) Event

This view shows two independent events in the navigation of an aircraft: the acquisition of azimuth information (the radial of a NAVAID) and the acquisition of distance information (the slant-range distance from the NAVAID).

The Navigation System object sends the message Offer Azimuth Information to represent the signals transmitted by the VOR transmitter. This message is sent not just to the Aircraft object in particular (as shown here), but is available for any appropriate receiver. Upon receiving the message, the service Accept Navidational Guidance Data of Vehicle Navigation System 1 (the VOR receiver) is performed.

Independently of the VOR receiver, Vehicle Navigation System 2 (the DME Unit) sends the message Request Distance Information in performing its service Interrogate Navigational Aid. The Navigation System object returns information from which the DME unit can calculate the distance to the VOR/DME station.

This view also illustrates some subjective decisions made in constructing the ATC model. The VOR/DME station is considered an object of the Navigation System class. For this example, a Navigation System object could easily be shown in a whole-part relationship with two parts named, for example, VOR System object and DME System object. Similarly, a Vehicle Navigation System object could easily have appeared in this example as a whole-part relationship with two parts named, say, VOR Receiver and DME Unit. However, in each case, the decision of what parts to add depends upon having more knowledge than is available from a generic class, and would necessitate a proliferation of specialization classes beneath the more generic Navigation System class and Vehicle Navigation System class. Adding so much detail did not seem appropriate at this time, but could be necessary in other situations (e.g., during the design phase). Instead of creating many specialization classes, the existing classes were made flexible for use as in this view.

This view is unlike the previous views because it does not include a manager-type object. As discussed in section 3.2.3, the management aspects of a navigation system resource are left within the resource itself in the ATC model and hence do not appear as services for manager-type objects within the Manager subject.

3.2.6.7 Tracking (Surveillance) Event

Figure 3-18 illustrates the use of an ATC surveillance system in locating an aircraft. As in the previous example, the view does not involve a Manager object. This view would also be valid for any specialization of the Surveillance System class.

It is assumed for this view that the Surveillance System object can detect, identify, track, and predict aircraft targets laterally and longitudinally, as well as vertically when the aircraft has an altitude-encoding transponder. This view also assumes that the vehicle surveillance system is an altitude-encoding transponder (i.e., a Transponder object with the inherited service Report Altitude is appropriate).

The Air Traffic object in this view has, as its part objects, each Flight that meets the selection criteria that its Aircraft object part has its Location attribute value within the Area of Coverage attribute value of the Surveillance System object.

Figure 3-18. Tracking (Surveillance) Event

The Surveillance System object performs the service Locate, Identify & Report Flight. The Surveillance System object locates an aircraft by transmitting a radar pulse and interpreting the returned pulse (the echo), identifies the aircraft by comparing the computed location of the aircraft with the Location attribute of an existing Aircraft object, acquires the altitude of the aircraft by sending the message Request Altitude Report to the Transponder object, and then sends a message to the Aircraft object requesting it to update its Location attribute. Note that the value of the Location attribute of an Aircraft object is the value determined by the ATC system, which is not necessarily the real location of the aircraft.

The Transmit & Receive Radar Pulse message is shown as a message from the Surveillance System object to itself. An alternative way to show this is to introduce another part object for the Aircraft object to represent the physical hull of an aircraft, so that the radar pulse could be sent to the hull, and the hull could return the echo. This alternative was not taken because the response to the pulse seemed to be more a passive response than the active performance of a service.

A surveillance system tracks aircraft and manages the information provided (e.g., identifies the aircraft and reports their positions). A Surveillance System object subsumes the surveillance sensors (radars) and the automation that processes that data. It would be possible to define a new whole-part structure for each object of the Surveillance System class by adding the parts "Sensor" and "Manager." For this view, two Sensor objects would be needed, one for the primary radar and one for the secondary radar. However, only the Surveillance System object is used in this view.

3.2.6.8 Weather Events

As discussed in section 3.2.2, aviation weather is represented in the ATC model only as reports and report managers. This section describes the following two weather events:

• A VFR flight receives a preflight briefing from a Flight Service Station.

• A weather area becomes significant enough that it is defined to be a protected airspace volume.

Preflight Briefing (Weather) Event. Figure 3-19 illustrates a preflight briefing event. In this view, a pilot for a VFR flight needs a preflight briefing. A Pilot object (part of an Aircraft object which is part of a Flight object in the predeparture state) sends a message to a Flight Manager object requesting a standard preflight briefing. Because the Flight object is in the predeparture state, and because no Flight Plan object with Departure Point attribute is available, there is no obvious recipient Flight Manager object. Thus the Flight Manager object selected to receive the message must be identified by the Pilot object itself. The Flight Manager object provides the preflight briefing as part of the service Assist in Flight Planning. Part of the standard preflight briefing is a summary of forecast en route and destination weather. To get this information, the Flight Manager object accesses appropriate Area Forecasts and the Terminal Forecast for the destination airport. The view shows messages to Wind/Weather Product objects for Area Forecasts as part of the Aviation Weather System object with the Area of Coverage of the National Aviation Weather Advisory Unit (NAWAU) and a message to a Wind/Weather Product object for a Terminal Forecast as part of an Aviation Weather System with the Area of Coverage of a particular Weather Service Forecast Office (WSFO). This information is put together with other information and returned to the Pilot object.

Of course, much more information than that contained in Area Forecasts and a Terminal Forecast is made available in a preflight briefing, but only these forecasts are shown in this view for simplicity.

This view also illustrates that the Flight Manager class represents functionality rather than existing positions, as discussed in section 3.2.3. In usual terminology, the functionality described above is that performed by an Automated Flight Service Station Specialist in the Preflight Position.

Figure 3-19. Preflight Briefing (Weather) Event

Weather Area Event. Figure 3-20 illustrates an event in which a weather area is determined to be significant enough that active measures should be taken to prevent aircraft from entering it. In this view, an Aviation Weather System Manager object, in performing the service Monitor, Forecast & Report Weather, predicts that thunderstorm activity in the object's area of responsibility will increase in size and intensity. The Aviation Weather System Manager object sends a message to the Air Traffic Manager object with area of responsibility containing the thunderstorm to inform that object of the prediction. The Air Traffic Manager object, in performing its service Assist in Weather Avoidance, decides that a Protected Airspace Volume object should be created to enclose the thunderstorm, and sends a message to the Protected Airspace Volume class requesting that this be done. The Protected Airspace Volume class creates such an object.

Although not shown in this view, once the Protected Airspace Volume object is created, the alternative view described in the Aircraft-to-Airspace Conflict Detection and Resolution Event of section 3.2.6.3 (above) applies.

3.2.7 Model Specification

The model specification for the ATC model is contained in appendix A.

Figure 3-20. Weather Area Event