formalATC_287

8/7/2019 formalATC_287

1/10

Ubiquitous Computing and Communication Journal 1

DESIGN OF FORMAL AIR TRAFFICCONTROL SYSTEM THROUGH UML

Shafeeq AhmadAzad Institute of Engineering & Technology, INDIA

[email protected]

Vipin SaxenaDr. B. R. Ambedkar University, INDIA

[email protected]

ABSTRACTIn recent years, UML has become most popular among modeling languages and is

commonly used to drive the design and implementation of system and softwarearchitectures. UML models help to achieve functional and non-functional requirementsof system. Furthermore, UML tools have enabled the creation of source code fromUML diagrams in order to initiate the programming phase of building software.However, due to lack of clearly defined semantics, it has been challenging to createsource code from UML models. The main objective of the paper is to model Air TrafficControl system by the use of UML. An activity of Air Traffic Control i.e. departureprocess which only covers part of the Air Traffic Control functionality has beenconsidered in this paper. The UML models created using formal naming semantics helpthem to convert into source code and also help to achieve functional and non-functionalrequirements. The complexity of Air Traffic Control System is also measured whichmakes the design simple and visibly understandable.

Keywords : UML model, formal semantics, source code, Air Traffic Control.

1 INTRODUCTION

Nowadays Object Oriented softwaredevelopment process is widely used in the SoftwareIndustry. The emergence of Object-Orientedprogramming has heavily contributed toward astandardized method of modeling known as theUnified Modeling Language (UML). In recent years,UML has become synonym for software modelingand is commonly used to model the softwarearchitecture problems. Source code can be easily begenerated with the help of different UML diagramsfor building the software. To generate the correctsource code, the main problem is lack of clearlydefined semantics and code generation can only be

done if the UML specification is standard, complete,precise, and unambiguous. The present work is basedupon the ATC system which is explained below:

1.1 ATC SystemATC system is a service that gives guidance to

aircraft, prevents collisions and manages safe &orderly traffic flow. It is a vast network of people &equipment that ensures safe operation of aircrafts.

The first air traffic control (ATC) system wasoriginally built in the 1960s; since then, air traffichas increased immensely, and has becomeincreasingly more difficult to maintain safety in thesky. As air travel has become an essential part of modern life, the ATC system has become strainedand overworked. The ATC system has been in aprocess of continuous improvement / change. In theearliest days of aviation, few aircraft were in theskies that there was little need for automated controlof aircraft. As the volume of air traffic increased andthe control was still fully manual; the system wasconsidered unsafe as human error has been cited as amajor factor in the majority of aviation accidents andincidents.

In todays Air Traffic Control system, air trafficcontrollers are primarily responsible for maintainingaircraft separation. Every aircraft follows severalactivities during a flight. These activities are shownbelow in Fig.1:(i) Preflight -This portion of the flight starts on the

ground and includes flight checks, push-back from the gate and taxi to the runway.


2/10


(ii) Takeoff - The pilot powers up the aircraft andspeeds down the runway.

(iii) Departure - The plane lifts off the ground andclimbs to a cruising altitude.

(iv) En route - The aircraft travels through one ormore center airspaces and nears the destinationairport.

(v) Descent - The pilot descends and maneuvers theaircraft to the destination airport.

(vi) Approach - The pilot aligns the aircraft with thedesignated landing runway.

(vii) Landing - The aircraft lands on the designatedrunway, taxis to the destination gate and parks atthe terminal.

LandingApproach

DescentEn Route

Departure

TakeoffPreflight

Figure 1: Activities of Aircraft [6]

1.2 Drawbacks of Current ATC SystemATC systems are highly complex pieces of

machinery, they employ standard verification andmodeling technique to coordinate, distribute andtrack aircraft as well as weather information. Thecurrently used systems need to employ procedures

for improved safety and efficiency which includeflexibility, potential cost savings & reduction instaffing. This means that there is a lack of advancedtechnology and desire to support the controller. Thusthere is a need to build ATC system based on amethod which can handle increased air trafficcapacity/congestion to provide a safety criticalinteractive system. The following are the majordrawbacks of current ATC system:(i) Lack of well-defined human/software interface

The idea of full automation or minimum humanintervention of the ATC system still remainsunfulfilled. The existing systems do requirehuman interaction as the system only guides butactual decision is taken by the controllers in-charge (ground, local).

(ii) Need for high maintenance Maintenance of thesystem is also an issue which can cause problemas discussed by Matthew L. Wald [23] about anincidence in which voice communicationbetween the pilot & controllers broke down &the reason behind this was found to be a lack of maintenance.

(iii) Outdated design/technology Obsolete softwaredesign and programming language [11] aremajor barriers to upgrades and efficient softwaremaintenance of the currently used ATC systemsbecause of which improved capacity andefficiency cant be achieved with the currentsystem. The current computer software limits the

number of aircraft that can be tracked at anygiven time, and the dated architecture makesenhancements, troubleshooting and maintenancemore difficult. Computer outages, planned orunplanned, are covered by a backup system thatcannot handle the same level of air traffic as themain system. The result is significantly limitedcapacity during backup mode.

(iv) Mixed communication The communicationbetween the controllers & pilot currently is acombination of voice & datalink. The results of test conducted [18] show that the mixedcommunication leads to slow speed which canbe overcome only when the wholecommunication takes place in a well definedmanner .

2 RELATED WORK

The ATC system consists of controllers &technology. The various controllers involved havedifferent tasks assigned to them which have beenvery well described in [15], [16], [19], [20]. TheATC real-time system [19] is characterized ascomplex, time-driven and potentially distributed. It iscomposed from multiple sub-systems, which mustcooperate in order to complete its real time targets.ATC employs the approach of Parallel Applications

in which the simultaneous execution of somecombination of multiple instances of programmedinstructions and data on multiple processors areperformed in order to obtain results faster. Meilander[4] has proposed a solution for problems arising dueto parallel processing used in ATC but itsimplementation needs reliable software. The reasonfor system failure discussed in [8] was found to belack of maintenance. For the efficient softwaremaintenance, [11] emphasizes changes particularlyon the technology front which means modernizingthe current air traffic control system by replacing thesoftware used in the current ATC systems. The studydone by Verma[18] by implementing changes in theprocedures, roles and responsibilities of thecontrollers for redistribution of workload andcommunications among them, has also stressed onthe introduction of new automated technologies forthe controllers.

For a critical system like ATC an extremely lowprobability of failure is needed as if the system failsany related type of hazard can occur. The reports onincidences at non-controlled airports [5] show that


3/10


pilots cant entirely rely on vision to avoid collision& also it is necessary to get all the air-traffic relatedinformation correctly. So it is crucial that in suchlarge and extremely complex systems the software isdesigned with a sound architecture A goodarchitecture not only simplifies construction of theinitial system, but even more importantly, readily

accommodates changes forced by a steady stream of new requirements. This architectural construct can bederived from modeling concepts by using thepowerful extensibility mechanisms of UML [1]. TheUML model-based approach helps to manage criticalsystems, since the model support the necessaryanalysis activities in several ways:

The formalized structural and behavioral systemdescription gives the necessary basis forcriticality analysis.

Providing behavior is expressed in simple statecharts or English-like pseudo code, thebehavior should at least be explainable to end-users.

The model gives an excellent basis for fault-tolerance analysis, since the model includes thedependency structure.

The size and complexity of the ATC systemdemand a considerable initial development effort,typically involving large development teams, that isfollowed by an extended period of evolutionarygrowth. During this time new requirements areidentified and the system is modified incrementallyto meet them. Under such circumstances anoverriding concern is the architecture of the software.This refers to the essential structural and behavioralframework [1] on which all other aspects of the

system depend. Any change to this foundationnecessitates complex and costly changes tosubstantial parts of the system. Therefore, a well-designed architecture is not only one that simplifiesconstruction of the initial system, but moreimportantly, one that easily accommodates changesforced by new system requirements.

To facilitate the design of good architecture thedomain-specific usage can be implemented using theUML. Object-oriented requirements analysis usingmodular and decomposable use cases provide to bevery powerful method for the analysis of large-scaleATC systems [6]. It is extremely useful to defineboth the static semantics (i.e., the rules for well-formedness) and the dynamic (run-time) semanticsof the ATC system. These semantic rules fullydefined and consistent, and in conjunction with anaction specification language that is also completeand consistent can be used to specify the details of state-transition (Activity diagram of UML) actions,Interaction (Sequence diagram of UML) and objectmethods (class diagram of UML) and the resultingmodels will be executable. Furthermore, if all the

necessary detail is included in a model, such modelcan be used to automatically generate completeimplementations.

The role of software architecture is similar innature to the role architecture plays in buildingconstruction. Building architects look at the buildingfrom various viewpoints useful for civil engineers,

electricians, plumbers, carpenters and so on. Thisallows the architects to see a complete picture beforeconstruction begins. Similarly, architecture of asoftware system is described as different viewpointsof the system being built. These viewpoints arecaptured in different model views. UML provides anumber of diagram types for creating models. UMLdoes not specify what diagrams should be created orwhat they should contain, only what they can containand the rules for connecting the elements. SomeUML diagrams can have different uses andinterpretations. The result of this has been thatbehavioral and/or run-time semantics are not welldefined for standard UML modeling elements. Thesemantics problems have made it difficult to achievemodel-based programming using standard UML.Hence semantically correct UML models [12], [17]are needed to achieve code. Also the UML modelsenhance communication as they provide a better wayto understand and communicate among analysts,designers, developers, testers and with domainexperts for designing a system. Creating anddebugging software code has been and continues tobe a very labor-intensive and expensive process buthaving an accurate UML model can ease the work asif any problem comes and modification is requiredthen instead of modifying the code the models can be

modified, even the extensibility can be done byadding new constructs to address new developmentissue.

To meet the non-functional requirements [13] suchas modifiability, testability and reliability, the designand analysis of a system at the architecture designlevel must be done. Non-functional requirementshave a critical role in the development of a softwaresystem as they can be used as selection criteria tohelp designers with rational decision-making amongcompeting designs, which in turn affects a systemsimplementation .Thus the ATC system needs toprovide a sufficient amount of dependability andshould support a survivability architecture [10].

In this paper we examine the most importantmodeling constructs used for representing the ATCsystem handling departure and also describe howthey are captured and rendered using UML. Themodels are based on the work presented by Saxena &Ansari [21].The operations, phases and controllersinvolved during departure of an aircraft have beendescribed in [2], [3], [7], [9], [10], [14], [15], [19] &


4/10


[20] which have been used as base for designingvarious UML models.

3 PROPOSED APPROACHED

The existing systems are quite complex andinefficient. To adapt to the changing demands of

speed and efficiency a reliable software system forATC is required to be developed. Softwarearchitecture based on UML models will help inhandling complexities and drawbacks of existingATC systems and also help to better understand thedomain. UML is the de-facto standard visualmodeling language which is a general purpose,broadly-applicable tool supported, industry-standardized modeling language which offers anextensive set of diagrams for modeling. Thecomplexity of the problem domain requires extensiveefforts for the clarification of the initial problemstatement. Moreover, due to the extremely longlifespan of ATC systems, stable and robust analysismodels enabling the integration of new operationalscenarios are needed which can be efficientlyobtained using UML models. In the design of adeparture activity of ATC system UML will help tomeet safety, reliability, availability, and robustnessdemands in an environment of steadily increasing airtraffic density. The code obtained using the UMLmodels is highly optimized which is one of the mainrequirements for the design of a cooperative ATCsystem.

4 DESIGN OF ARCHITECTURE

System architecture is a set of design decisions.These decisions are technical and commercial innature. To meet the functional and nonfunctionalrequirements of the above said ATC system it isnecessary to model the complete ATC system by theuse of UML. Different types of diagrams aredesigned and described below in brief:

4.1 UML Activity DiagramActivity diagram describes the workflow behavior

of a system. It illustrates the dynamic nature of asystem by modeling the flow of control from activityto activity. An activity represents an operation of aclass, resulting in system state change.

The informal activity diagram for departure of anaircraft is given below in Fig. 2. It simply describesthe main activities performed during departure by thecontroller and the aircraft object. In this diagramsome semantic problems are present like if anyclearance has not been granted then what will bedone is not clear i.e. use of decision box hasnt been

done. Further all the activities have been shown in asingle step and no refinements have been done tosimplify the activities. These loose semantics of thediagram make this model unable to be executable,therefore the formal activity diagram for departure of an aircraft is defined and shown in Fig. 3

Formal activity diagram [fig.3] contains fiveobjects aircraft, Gate_controller, Local_ controller,Ramp_controller & Ground_controller. It describesvarious activities which are performed by all theobjects. While these activities/operations are beingdone, it also shows in which state the system is likeready for departure, taxiing etc. There is a request bythe pilot of the aircraft to the gate controller to assign

Aircraft Controller

Request pushbackclearance

Grant pushbackclearance

Pushbackfrom gate

Leave ramparea

Request taxiclearance

Grant taxiclearance

Taxiing

Request departureclearance

Grant departureclearance

Depart

Figure 2 : Informal UML activity diagram of departure activity of a flight


5/10


Figure 3: Formal UML activity diagram of departure activity of a flight


6/10


it a gate which is the initial state & the final state isnamed as depart. When the next activity is performedthe system is taken to the next state that means atransition causes the change of state. Against thetransitions various conditions are listed whichactually cause the transition. Also the use of decisionbox is applied which is required to check whether the

various clearances like pushback, taxiing & finaldeparture clearance has been granted or not. If clearance has been granted then only the aircraftstarts pushing back or departing else if because of some reason clearance could not be granted then itwill again go to the request clearance state where itwill be seen & tracked until it is safe for pushback ordeparture. During the whole departure activity thepossibilities of any emergency condition is also takeninto consideration and shown in the diagram. Hencethe solid and well organized semantics likeconditions for transitions, use of swimlanes, fork,

join, method calls from objects i.e. able to callmethods from other objects, decision conditionspecification etc. have been used in this diagramwhich make this model executable.

4.2 UML Use Case DiagramThe use case diagram captures system

functionality as seen by users. It shows an outside-inview of the procedures available in the use of thesystem i.e. all the available functionality of thesystem is represented at a high level. The UMLmodels can package the most relevant activities inuse cases and identify important actors. The UMLuse case diagram for departure activity of ATCsystem is shown in Fig.4.

This diagram consists of two actors namelycontroller and aircraft. The use-cases consistsrepresent the functionality of both actors. But thisuse case diagram provides an informal viewpoint as

it lacks concrete, well defined semantics which makeit impossible to help it in bringing to a computationalconsistency, therefore formal use case diagram isdrawn for departure activity of a flight and shownbelow in Fig. 5.

Gate_controller

Departure

assign gate

Local_controller

Monitor runway incursions

Ground_controller

departure

Sequencing at holding points

Sectorization

Aircraft

Ramp_controller

clearance to leave ramp

Govern ramp area

sequencing at ramp

pushback

enter and leave ramp

Taxiing

Departure queue sequencing

Taxi-plan

Departure

clearance for takeoff

gate freeing

grant pushback fromgate

clearance for taxiing

Tracking

Detect actual runway exit

Handle surface movement

Information of weather, speedand direction

Maintaining safe distancebetween planes

select for departure

Figure 5: Formal UML use case diagram of departure activity of a flight

In the above model there are all five actors namelyAircraft, Ground_controller, Ramp_controller,Gate_controller & Local_ controller which interactwith various use cases. The use cases clearlydescribe various main functions during departure andwhether they are dependent on each other directly orindirectly denoted by extended or included keywords.It explains actually which functions are governed bywhich actors. This diagram provides the functionalbasis for creating the remainder of the diagramsneeded to arrive at an executable diagram as it haswell defined semantics like identifying every actorinvolved during departure of a flight, specifying allthe functions performed by each actor and use of

extend or include keyword to identify how onefunction of an actor is related to another. This formaluse case diagram also drives the design of the classdiagram, and sequence diagram.

4.3 UML Class DiagramClass diagram identifies & describes the static

structure of the system i.e. the system architecture.

ControllerAircraft

Monitoring

Grant Clearances

Tracking & Maintainingsafe distance

Handle aircraftmovement

Provide information

Taxiing

Pushback

Departure

Aircraft sequencing

Figure 4: Informal UML use case diagram of departure activity of a flight


7/10


The following Fig.6 shows the informal classdiagram of the departure activity of a flight.

This diagram gives a general view of the classesinvolved during departure namely the controller andthe aircraft class. In this diagram only the name of the attributes and the operations of the classes havebeen specified. Even the attribute type or the returntype of the methods hasn't been described. Theseloose semantics make this model impossible to

compile and execute. Now let us examine a formalclass diagram of departure activity of a flight shownbelow in Fig.7

This class diagram of the departure activity of aflight described in Fig. 7 focuses on the main objectsand associations (relation) between them. Duringdeparture main objects are Gate_controller,Ramp_controller, Ground_controller,Local_controller and Aircraft itself. TheLocal_controller in turn consists of theClearance_delivery_controller which gives the finaldeparture clearance. Also a controller calledRamp_controller is present which is just a type of ground controller which is responsible for operationsat ramp (parking) area. All the objects in turn have

some distinct attributes (properties) and someoperations which are listed in the 2nd and 3rd sectionrespectively of the class diagram. The type of attributes and return type of operations have beenclearly specified in the diagram. This class diagramhas covered almost all the explicitly definedsemantics like class relationships, multiplicities,

associations, properly labeled relationships, strictnaming of classes, attributes, and methods, explicitparameters/return values which are necessary inorder to allow the model to be computationallyexecutable.

4.4 Sequence DiagramA sequence diagram is an interaction diagram that

details how operations are carried out, whatmessages are sent and when. Sequence diagramshave a temporal focus so they are organizedaccording to time which means what happens when.

The informal sequence diagram of departureactivity of a flight is shown below in Fig 8. It simplygives a sequence of messages between the controller

and the aircraft objects. But this model doesntinclude the semantics necessary for making itexecutable as no parameter values are specified, noguards have been used for any decision point, eventhe class definition is not necessarily present in thecalled class. Hence this model can not be compiledand executed, therefore a formal sequence diagram isdefined & shown in Fig.9.

Controllercontrollernamelocationarea

monitor()

grantclearance()tracking()movementhandling()

Aircraftaircraftnameairlinenamedeparturetime

pushback()taxi()depart()

Figure 6: Informal UML class diagram of

departure activity of a flight

Clearance_delivery_controlleraircraft : Stringclearancelimit : Longdeparturefrequency : Integerrouteassigned : Variantaltitudeassigned : Double

routechecking()finaldepartureclearance() : Boolean

Ground_controllerlocation : Variantarea : Integerinactiverunwayname : Stringmonitoringdevice : String

holdingareas()controlgroundtraffic()protectcriticalareas()departurequeuesequencing()handleemergencies()taxiclearance() : Boolean

Local_controllersector : Stringlocation : Variantactiverunwayname : Stringradarcoverage : Long

givinginformation() : Variantclearance()selectfromqueue()handleemergencies()sectorization()runwayassignment()monitorrunwayincursions()holdingpointsequencing()

11

consistsof

Gate_controllergatename : Variant

gateassignment()makegateavailable()pushbackclearance() : Boolean

Aircraftairlinename : Stringaircraftnumber : Variantairplanetype : Stringposition : Variantaltitude : Integerdeparturetime : Datedepartureairport : Stringspeed : Integerdistance : Integerroute : Variantcallsign : Stringtrajeventlist : Variantlatitude : Integerlongitude : Integer

depart()

taxiing(taxi-out-plan, assigned-runway)pushback()getdeparturetime()assignflightcreww()maneuvering()delayflight(number of minutes)setcallsign(string callsign value)getcallsign(string callsignvalue)addtrajevent()

0..*1

+assigned aircraft0..*

+taxi clearance granting1 controls

10..*

+departure clearance granting1

+assigned aircraft0..* controls

1

0..*+assigned aircraft

1+gate clearance granting

0..*

controls

Ramp_controllerramparea : Long

controlrampoperations()sequencingatramp()aircraftservicing()aircraftloading()rampclearance(): Boolean

0..*

1

+assigned aircraft0..*

+ramp clearance granting1

controls

Figure 7: Formal UML class diagram of departure activity of a flight Figure 8: Informal UML sequence

diagram of departure activity of a flight


8/10


Figure 9: Formal UML sequence diagram of departure activity of a flight


9/10


In Fig.9 complete departure activity of a flight canbe seen at a glance. The messages are communicatedbetween the five main objects; aircraft,Gate_controller, Ramp_controller, Local_controllerand Ground_controller. It clearly describes theinteraction between the objects and gives the order orsequence in which the actions take place i.e. in what

order messages have been send. The solid linesrepresent the call messages while the dotted linesrepresent the messages returned between the objects.The tags are added to clearly specify about theoperation. This model consists of all the clearsemantics like use of tags, explicit parameter values,explicit return values, combinedfragments(alternatives and parallel), guards neededfor decision points and all the class definitions existin the called class. Thus this formal sequencediagram with well defined and solid semantics makesit able to be compiled and computationallyexecutable.

5 CONCLUDING REMARKS

From the above work it is concluded that thedescribed software architecture design process fullycovers the departure activity of an aircraft. UMLmodeling has been used for making the variousmodels (class, use-case, activity & sequence) usinginformal and formal semantics. These designedmodels are essential part of architecture of ATCsoftware system and that can help to achieveexecutable code and other functional and non-functional requirements of software system.

6 REFERENCES [1] B. Selic, and J. Rumbaugh, Using UML for

Modeling Complex Real-Time Systems, March1998. Available: http://www.ibm.com/ developerworks/rational/library/content/03July/ 1000/1155/1155_umlmodeling.pdf

[2] I. Anagnostakis, H. R. Idris, J. P. Clarke, E.Feron, R. J. Hansman, A. R. Odoni, and W. D.Hall, "A Conceptual Design of A DeparturePlanner Decision Aid", 3 rd USA/Europe AirTraffic Management R & D Seminar, June 13-16, 2000. Available: http://dspace.mit.edu/ bitstream/1721.1/37321/1/paper68.pdf ,

[3] H. Idris, J. P. Clarke, R. Bhuva, and L. Kang,

Queuing Model for Taxi-Out Time Estimation,Sep 2001. Available: http://dspace.mit.edu/ bitstream/1721.1/37322/1/TaxiOutModel.pdf

[4] W. C. Meilander, M. Jin, and J. W. Baker,Tractable Real-time Air Traffic ControlAutomation, International Conference onParallel and Distributed Computing Systems, pp.477-483, November 4-6, 2002.

[5] G. Brown, Remote Intelligent Air TrafficControl Systems for Non-controlled Airports,Jan. 2003. Available: ww4.gu.edu.au:8080/adt-root/uploads/approved/adt-QGU20040225.084516/ public/02Whole.pdf,

[6] J. Whittle, J. Saboo, and R. Kwan, FromScenarios to Code: An Air Traffic Control Case

Study, 25th International Conference onSoftware Engineering (ICSE'03), pp. 490, 2003[7] Safety Regulation Group, Air Traffic Services

Information Notice, ATS StandardsDepartment, Civil Aviation Authority, no. 50,Aug. 2004.

[8] M. L. Wald, Maintenance Lapse Blamed forAir Traffic Control Problem The New York Times, Sep 2004. Available:http://www.nytimes.com/2004/09/16/politics/16airports.html

[9] M. Axholt, and S. Peterson, Modelling Trafficscenarios for Realistic Air Traffic ControlEnvironment Testing, Linkoping UniversityPress, Department of Science & Technology,Linkoping University Sweden, Nov. 2004.

[10] R. D. Lemos, C. Gacek, and A. Romanovsky,Architecting Dependable Systems II,Springer-Verlag Berlin Heidelberg, 2004.

[11] ATCA Air traffic Control Association, AirTraffic Control Computer Modernization is EnRoute, Feb 2005. Available:http://www.atca.org/news.asp

[12] Object management Group, "Unified ModelingLanguage: Superstructure", Version 2.0,Formal/05-07-04, Aug 2005, Available: http://www.omg.org/docs/formal/05-07-04.pdf

[13] L. Dai, and K. Cooper, Modeling and Analysisof Non-functional Requirements as Aspects in aUML Based Architecture Design, Proceedingsof the Sixth International Conference onSoftware Engineering, Artificial Intelligence,Networking and Parallel/Distributed Computingand First ACIS International Workshop on Self-Assembling Wireless Networks(SNPD/SAWN05) , IEEE 2005.

[14] European Organisation For The Safety Of AirNavigation (Eurocontrol), WP 5.2 Add NFRTo Use Cases And Interaction diagrams NFRMapping Report, June 2006.

[15] P. A. Bonnefoy, "Airport Operations ", MIT, AirTraffic Control, MIT International Center forAir Transportation, Sep 2006

[16] R.J. Hansman, Air Traffic Control Overview,MIT Department of Aeronautics andAstronautics, MIT ICAT, Available:http://ocw.mit.edu/NR/rdonlyres/Aeronautics-and-Astronautics/16-72Fall-2006/11CD67DE-29C1-4AB9-A7DD-004BB1897CB9/0/ lec1.pdf

[17] R. Campos," Model Based Programming:Executable UML With Sequence Diagrams ", AThesis Presented to The Faculty of the Computer


10/10


Science Department, California State University,Los Angeles, June 2007

[18] S. Verma, T. Kozon, V. Cheng, and D. Ballinger,Changes In Roles/Responsibilities of AirTraffic Control Under Precision Taxiing, 26 th IEEE/AIAA Digital Avionics SystemsConference, Oct 2007

[19] Wikipedia, Air traffic control, October 2007.Available:http://en.wikipedia.org/wiki/Air_traffic_control

[20] L. Brim, Fundamentals of Air Traffic Control,ParaDise Seminar, Feb 2008, Available:http://www.fi.muni.cz/paradise/Seminar/2008-spring/0225-prezentace.pdf

[21] V.Saxena, and G.A.Ansari, UML Models of Aircraft System, ICFAI Journal of Systemsmanagement, Vol. 6, No.2, PP. 68-74, May 2008

Documents

formalATC_287