d implementation challenges of a web based air...

SE690 GRP

DESIGN AND IMPLEMENTATION

CHALLENGES OF A WEB-BASED

AIR TRAFFIC CONTROL TRAINING

TECHNOLOGY

CHRISTOPHER SHANNON

EMBRY-RIDDLE AERONAUTICAL UNIVERSITY

GRADUATE RESEARCH PROJECT

11/21/17

VERSION 1.0

Name Signature Date

Student Christopher Shannon 11/21/2017

GRP Advisor Dr. Shafagh Jafer

11/22/2017

MSE Coordinator / Department Chair

Dr. Massood Towhidnejad

SE690 GRP

REVISION HISTORY Date Version Description

11/5/17 0.1 Initial document with Abstract, 1. Introduction, and References

11/12/17 0.2 Added Abbreviations/Acronyms and 2. Literature Review

11/17/17 0.3 Added 3. Methodology

11/19/17 0.4 Initial implementation of 4. Architectural Design; Added 5. Conclusions

11/20/17 0.5 Finished 4. Architectural Design; Made first draft edits

11/21/17 1.0 Final edits

SE690 GRP

ACKNOWLEDGEMENTS I wish to extend my deepest gratitude to Dr. Jafer for all the help and support she has given me. From

when I first had SE 300 with her to now, she has pushed me farther than I ever thought possible and stuck

with me at times when I faltered. I owe this achievement to her.

SE690 GRP

ABSTRACT The En Route Automation Modernization (ERAM) is the primary interface for En Route controllers and

associates to manage air traffic. It consists of three interfaces, the radar, Voice Switching and Control

System (VSCS), and ERAM Decision Support Tool (EDST). The FAA Academy is the training center for Air

Traffic Controllers (ATC) and currently challenged with the lack of a practice environment for ATC trainees.

Through a recent project for the FAA Academy, an ATC Scenario Training Technology (ASTT) is being

developed at Embry-Riddle to provide Academy students with an online tool to practice various En Route

scenarios specified by the FAA. This research project investigates the challenges in designing and

developing the underlying ASTT software technology as a computationally-intensive and multifaceted

system, specifically in the domains of the technology stack selection and development environment

creation. In addition, the overall project design as well as the proposed architecture for project execution

will be addressed.

SE690 GRP

TABLE OF CONTENTS Revision History ............................................................................................................................................ 2

Acknowledgements ....................................................................................................................................... 3

Abstract ......................................................................................................................................................... 4

Table of Contents .......................................................................................................................................... 5

List of Figures ............................................................................................................................................ 7

List of Tables ............................................................................................................................................. 8

List of Abbreviations/Acronyms ................................................................................................................ 9

1. Introduction ............................................................................................................................................ 11

2. Literature Review .................................................................................................................................... 15

Summary ................................................................................................................................................. 17

3. Methodology ........................................................................................................................................... 19

3.1. Development Environment .............................................................................................................. 19

3.1.1. Technology Stack ...................................................................................................................... 19

3.1.1.1. Choosing a Web Application Server Platform .................................................................... 19

3.1.1.2. Entity Framework ............................................................................................................... 20

3.1.2. Configuration Management Pipeline ........................................................................................ 22

3.1.2.2. Linux VM ............................................................................................................................ 23

3.1.2.2. Docker ................................................................................................................................ 24

3.2. Reactive Framework ........................................................................................................................ 26

3.2.1. Framework Selection ................................................................................................................ 27

3.2.2. Vue.js ......................................................................................................................................... 28

4. Architectural Design ................................................................................................................................ 30

4.1. Server Application Design ................................................................................................................ 31

4.2.1. Application Classes .................................................................................................................... 32

4.2.1.1. User .................................................................................................................................... 32

4.2.1.2. Scenario .............................................................................................................................. 33

4.2.1.3. FlightManager ....................................................................... Error! Bookmark not defined.

4.2.1.4. Flight...................................................................................... Error! Bookmark not defined.

4.2.1.5. JSBSim ................................................................................... Error! Bookmark not defined.

4.2.1.6. PortManager ......................................................................... Error! Bookmark not defined.

SE690 GRP

4.2.1.7. FlightSimulator ...................................................................... Error! Bookmark not defined.

4.2.1.8. Aircraft .................................................................................. Error! Bookmark not defined.

4.2.1.9. AircraftType........................................................................... Error! Bookmark not defined.

4.2.1.10. AircraftState ........................................................................ Error! Bookmark not defined.

4.2.1.11. DepartureFlight ................................................................... Error! Bookmark not defined.

4.2.1.12. ActiveFlight ......................................................................... Error! Bookmark not defined.

4.2.1.13. Altitude ............................................................................... Error! Bookmark not defined.

4.2.1.14. Speed .................................................................................. Error! Bookmark not defined.

4.2. Database Schema Design ................................................................................................................. 34

4.3 Front-End Design ............................................................................................................................... 35

4.2.1. R-Position .................................................................................................................................. 35

4.2.2. RA-Position ................................................................................................................................ 36

5. Conclusions ............................................................................................................................................. 37

5.1. Summary .......................................................................................................................................... 37

5.2. Future Work ..................................................................................................................................... 38

6. References .............................................................................................................................................. 39

SE690 GRP

LIST OF FIGURES Figure 1: R-Position Interface...................................................................................................................... 11

Figure 2: RA-Position EDST Interface .......................................................................................................... 12

Figure 3: (Metacraft.com, 2017) VSCS Air-to-Ground Interface ................................................................. 13

Figure 4: Mockup of the ASTT Simulation Interface ................................................................................... 14

Figure 5: High-Level Overview of ORM ....................................................................................................... 20

Figure 6: Example of the Data Mapper Pattern .......................................................................................... 21

Figure 7: (Docs.microsoft.com, 2013) Example of Repository and Unit of Work Patterns in the Entity

Framework .................................................................................................................................................. 21

Figure 8: Entity Framework Class Architecture ........................................................................................... 22

Figure 9: VirtualBox VM Development Environment Architecture ............................................................ 24

Figure 10: Docker Creation Workflow ........................................................................................................ 25

Figure 11: ASTT Docker Development Environment Architecture ............................................................. 26

Figure 12: MVVM Architecture ................................................................................................................... 29

Figure 13: ASTT High-Level Architecture & Data Flow ................................................................................ 30

Figure 14: Application and XML Architecture ............................................................................................. 31

Figure 15: User class ................................................................................................................................... 32

Figure 16: Scenario Class ............................................................................................................................. 33

Figure 17: Database Schema Design ........................................................................................................... 34

Figure 18: Simulation & Context components ............................................................................................ 35

Figure 19: R-Position components .............................................................................................................. 35

Figure 20: R-Position: Radar components .................................................................................................. 36

Figure 21: RA-Position components............................................................................................................ 37

Figure 23: FlightManager Class ................................................................................................................... 41

Figure 24:Flight class ................................................................................................................................... 42

Figure 25: JSBSim class ................................................................................................................................ 43

Figure 26: PortManager class ..................................................................................................................... 44

Figure 27: FlightSimulator class .................................................................................................................. 44

Figure 28: Aircraft class ............................................................................................................................... 45

Figure 29: AircraftType class ....................................................................................................................... 45

Figure 30: AircraftState class ...................................................................................................................... 45

Figure 31: DepartureFlight class ................................................................................................................. 46

Figure 32: ActiveFlight class ........................................................................................................................ 46

Figure 33: Altitude class .............................................................................................................................. 47

Figure 34: Speed class ................................................................................................................................. 47

Figure 35: RA-Position: DL View components............................................................................................. 48

Figure 22: RA-Position: ACL View components ........................................................................................... 49

SE690 GRP

LIST OF TABLES Table 1: Comparison of ColdFusion and ASP.NET Core Platforms .............................................................. 20

Table 2: Front-End Reactive Technology Comparison ................................................................................ 27

Table 3: Front-End Reactive Technology Comparison, continued .............................................................. 28

Table 4: User Class Description ................................................................................................................... 32

Table 5: Scenario class description ............................................................................................................. 33

Table 6: FlightManager class description .................................................................................................... 41

Table 7:Flight class description ................................................................................................................... 42

Table 8: JSBSim Class Description ............................................................................................................... 43

Table 9: PortManager Class Description ..................................................................................................... 44

Table 10: FlightSimulator Class Description ................................................................................................ 44

Table 11: Aircraft Class Description ............................................................................................................ 45

Table 12: AircraftType Class Description .................................................................................................... 45

Table 13: AircraftState Class Description .................................................................................................... 45

Table 14: DepartureFlight Class Description ............................................................................................... 46

Table 15: ActiveFlight Class Description ..................................................................................................... 46

Table 16: Altitude Class Description ........................................................................................................... 47

Table 17: Speed Class Description .............................................................................................................. 47

SE690 GRP

LIST OF ABBREVIATIONS/ACRONYMS

Abbreviation Term

ATC Air Traffic Control

FAA Federal Aviation Administration

ATM Air Traffic Management

ERAM En Route Automation and Modernization

EDST ERAM Decision Support Tool

CHI Computer-Human Interface

GUI Graphical

VSCS Voice Switching and Control System

NextGen Next Generation Air Transportation System

ASTT ATC Scenario Training Technology

ASDL Aviation Scenario Definition Language

NPM Node Package Manger

VM Virtual Machine

JVM Java Virtual Machine

CI Continuous Integration

VM Virtual Machine

RHEL Red Hat Enterprise Linux

JSON JavaScript Object Notation

XML Extensible Markup Language

SQL Structured Query Language

SE690 GRP

ORM Object Relational Mapping

CRUD Create, Read, Update, and Delete

EF Entity Framework

SASS Syntactically Awesome Stylesheet

CSS Cascading Stylesheet

MVC Model-View-Controller

SPA Single-Page Application

JS JavaScript

HTML Hypertext Markup Language

DOM Document Object Model

JSX JavaScript Syntax Extension

MVVM Model-View-ViewModel

SE690 GRP

1. INTRODUCTION The En Route Automation and Modernization (ERAM) replaced the 40-year-old En Route Host computer

in 2015 and is “the heart of the Next Generation Air Transportation System (NextGen)” (www.faa.gov,

2015). The system allows En Route controllers to track 1900 aircraft simultaneously and can process data

from up to 64 radars. The ERAM is operated by two controllers, collaboratively managing a sector of

airspace. The ERAM system is comprised of two contexts, the Radar-Position (R-Position) and the Radar

Associate-Position (RA-Position).

The R-Position, typically operated by the senior controller, consists of a single-monitor radar interface.

This interface displays the data blocks, trailing lines, and flight plan projections for all the flights within

the sector of airspace as well as the immediately adjacent airspace. Other flight metadata such as current

airspeed, remarks, and aircraft ID can be displayed at will. An image of the R-Position interface can be

seen in Figure 1.

The RA-Position, run by the associate, provides a graphical user interface (GUI) for the ERAM Decision

Support Tool (EDST). This interface and manages the flight plans in the associated airspace. The EDST

Figure 1: R-Position Interface

http://www.faa.gov/

SE690 GRP

provides several sub-interfaces for viewing and managing flight, direction, altitude, remark, and route

data. It also provides warnings to the user of several levels of conflict alerts as well as emits warnings to

address issues such as Mode C Intruder (MCI) alerts and Visual Flight Rule Conflicts. An image of the RA-

Position EDST interface can be seen in Figure 2.

Both controllers directly communicate with pilots using the Voice Switching and Control System (VSCS) to

facilitate their transit through the sector. The interface can provide air-to-ground as well as ground-to-

ground communication, with dedicated sub-interfaces for each. An image of the air-to-ground view of the

VSCS can be seen in Figure 3.

Figure 2: RA-Position EDST Interface

SE690 GRP

The Federal Aviation Administration (FAA) Academy is responsible for training future Air Traffic Control

(ATC) employees and has several training ERAM installations onsite. A typical training environment

consists of the student in the EDST seat, accompanied by a senior controller on the R-Side, with an

instructor standing behind. Because of the amount of setup involved in configuring the training ERAM for

a given scenario and logistics in scheduling a senior controller and instructor, lab sessions with the actual

ERAM are typically sparsely scheduled and do not allow for the student to practice on the ERAM outside

of specified lab times. Thus, the FAA is looking to provide a tool to the students to practice En Route

scenarios outside the allotted lab time to gain further proficiency.

The ATC Scenario Training Technology (ASTT) will be a Web-based training tool designed to provide a

recreation of the ERAM’s core functionality with the ability to load scenarios. The tool will allow for

students to select an instructor-provided scenario and switch between the R-Side and EDST contexts in

real time. Starting a scenario will spawn simulated aircraft modeled in an instance of JSBSim, an open-

source flight dynamics model that defines the movement of an aircraft under the forces and moments

applied to it using the various control mechanisms and from the forces of nature (JSBSim Open Source

Flight Dynamics Model, 2017). The telemetry generated by the simulated aircraft will be sent back to the

Figure 3: (Metacraft.com, 2017) VSCS Air-to-Ground Interface

SE690 GRP

scenario processor. The specialized ERAM mouse and keyboard will be simulated on-screen so the user

experience will be as close to that of the real ERAM system as possible, while being run from a minimum

of an iPad up to several devices/monitors simultaneously. As students attempt scenarios, their responses

to scripted events will be recorded and graded automatically. Admins will be able to monitor, in real time,

the student’s participation as well as assess compiled scenario reports to better tailor the in-class

curriculum. A mockup of the proposed design can be seen in Figure 4.

The challenges of designing such a system are mainly constrained to the team development environment,

interface design, scenario simulation, and user response processing domains, but the overall architecture

needs to be considered closely. The ASTT must be developed in a modular format such that future features

and improvements can be easily added without incurring a system-wide redesign. This research project

outlines the design challenges and solutions for creating the ASTT.

Figure 4: Mockup of the ASTT Simulation Interface

SE690 GRP

2. LITERATURE REVIEW The literature relevant to this project, in terms of the software description, development environment,

architecture, and reactive front-end code organization is discussed in this chapter.

EAA121L0 En Route Automation Modernization (ERAM) Air Traffic Manual (ATM): R-Position User

Manual [PDF]. (2009, April 28). William J. Hughes Technical Center, Atlantic City International Airport,

New Jersey 08405: Program Operations, ATO Office of En Route and Oceanic Services (ATO-E), Federal

Aviation Administration.

And

EAC11000 En Route Automation Modernization (ERAM) Air Traffic Manual (ATM): RA-Position User

Manual [PDF]. (2012, August 1). William J. Hughes Technical Center, Atlantic City International Airport,

New Jersey 08405: En Route and Oceanic Services, Federal Aviation Administration.

These two manuals were published in 2009 and 2012 respectively and outline the interface and

functionality requirements for the ERAM R-Side and RA-Side positions. The manuals serve as the

fundamental requirement sources for the ERAM recreation. Within them, the various menus, contexts,

and functionalities are described in detail. The R-Side consists of a single monitor, with a large radar view.

On this, flights are depicted by data blocks and icons and the user can make point outs and handoffs to

other sector controllers. The interface for the RA-Side has a deep menu system with many interfaces for

managing and revising flight plans for the flights in the sector. Both positions have access to the VSCS

allowing them to directly communicate with pilots.

Spuy, R. v. d., & SpringerLink (Online service). (2015). Advanced game design with HTML5 and

JavaScript. Berkeley, CA: Apress.

This book was published in 2015 and presents insight into developing browser-based simulations using

HTML5 and JavaScript. It is broken up into ten topics, including working with the canvas drawing API, asset

management, animation, and collision detection. It is written such that each chapter builds upon the

material presented in previous chapters and provides tools and examples for scaffolding an online

simulation using ES6 JavaScript (useful for integrating into reactive frameworks like Vue.js). Some of the

useful solutions include how to load and draw graphics onto the screen and create reusable components

from them, responsive design, and how to implement drag-and-drop functionality.

Bainomugisha, E., Carreton, A. L., Cutsem, T. V., Mostinckx, S., & Meuter, W. D. (2013). A survey on

reactive programming. ACM Computing Surveys (CSUR), 45(4), 52.

Published in 2013, this paper provides a taxonomy of 15 language examples of reactive programming

according to six metrics: representation of time-varying values, push- and pull-based evaluation models,

lifting operations where the programmer wishes to manually track values instead of relying purely upon

behavior, multidirectional change propagation, glitch avoidance, and distributed reactive programming.

It determined the reactive programing paradigm is well-suited to creating event-driven applications which

would otherwise be unwieldy if developed with conventional programming methods and techniques. It

SE690 GRP

also concluded there are still unresolved challenges with reactive programming, specifically in the areas

of multidirectionality and the subtle issue of glitch avoidance.

Kambona, K., Boix, E. G., & De Meuter, W. (2013). An Evaluation of Reactive Programming and Promises

for Structuring Collaborative Web Applications.

Also published in 2013, this paper provides an evaluation of the reactive programming methodology as it

relates to developing Web applications and how it coupled with the use of promises can organize

distributed applications and reduce callback hell. They describe callback hell, or the pyramid of doom as

a situation where an application relies heavily upon asynchronous operations and dependent return

values are deferred until the asynchronous event completes. This leads to nested callbacks that make

sequential programming next to impossible and the resulting operation chain becomes difficult to trace.

Promises provide the ability to organize several dependent callbacks in a user-friendly manner that result

in the effect of a single asynchronous operation. Promises can be passed around the code, an activity not

possible with the nature of callbacks. They utilized the Q library to realize promises in their demo

application, but found not all promise implementations provide the same functionality, specifically

promise chaining.

They developed a distributed drawing program where one or more users could perform operations on the

same graphical nodes. Their program did not use an existing reactive framework, rather they

implemented the Q library for its promise features and generally followed the reactive pattern found in

AngularJS. This proved problematic as they found prebuilt frameworks such as Scala.React provide

significant features such as next and delay methods for managing dataflow. Their implementation also

ran into the issue of requiring nested promise declaration, which recreated the callback hell scenario,

which they named the promise hell. They also determined support for distributed reactive programming

is lacking in today’s frameworks and is a subject for further study. Interestingly, their drawing application

utilized the HTML5 canvas tag for drawing the shapes on-screen. The side effect of this is the JavaScript

Document Object Model (DOM) engine was not able to traverse deeper than the canvas tag itself and

required the use of event streams to model end-user operations.

Machisa, M. (2005). Object Relational Mapping for Enterprise Application Architecture.

This paper written in 2005 breaks down the patterns found in object relational mapping (ORM) and

highlights the intrinsic benefits of leveraging this type of architectural solution. The ORM patterns were

categorized into three groups, data source, behavioral, and structural patterns.

Data source patterns can be further categorized into gateways or mappers. The paper identified four,

table data gateway, row data gateway, active record, and data mapper. In the table data gateway, each

table has an associated class for managing all rows and is sometimes considered a data access gateway.

In contrast, the row data gateway only manages one row per each object instance. The active record

encapsulates the data, data, access, and domain logic. This pattern exhibits a high degree of coupling and

is best suited to simple logic and a low number of involved tables. The last data source pattern discussed

was the data mapper. This pattern abstracts the data manipulation methods from the objects and the

database from the domain model using identity maps.

SE690 GRP

The second category of ORM patterns discussed were the behavioral patterns and are intended to

mitigate issues presented in the data source patterns through management of transactions and in-

memory objects. The three patterns investigated were the unit of work, identity map, and lazy load. Unit

of work allows database request queueing for the sake of reducing repeated requests. Identity map caches

data in memory so that each object only gets loaded once. The last behavior pattern is the lazy load. This

pattern prevents the high-level request from loading all the child data at once.

The last category discussed were the structural patterns and were introduced to bridge the gap between

in-memory objects and database tables/rows. The six patterns discussed in this category are the identity

field, foreign key mapping, single table inheritance, class table inheritance, concrete table inheritance,

and inheritance mappers. In the identity field pattern, database rows identified via primary keys whereas

objects in-memory use an internal memory address to be identified. Foreign key mapping is like the

identity field pattern in that objects do not need the foreign keys associated with the actual database row.

Single table inheritance is sometimes compared to de-normalizing database data in the pursuit of

promoting higher data redundancy for increased performance. Class table inheritance creates one-to-one

mappings of classes to database tables and objects track key data. Concrete table inheritance reduces the

level of abstraction and is like the single table inheritance in that it provides the ancillary data upon object

instantiation. Lastly, inheritance mappers handle inheritance properties. In the hierarchy, each concrete

and abstract class uses a mapper to manage CRUD database operations.

This paper determined using ORM patterns, the technology promoted rapid prototyping and was used to

prototype a bank account system. Her prototype utilized the active record and single table inheritance

patterns as the application to be developed was simple in nature and mapping to a single table was more

desirable to a high level of normalization.

SUMMARY This project’s focus can be divided into three domains initially addressed with the literature review. The

first two manuals, (EAC11000 En Route Automation Modernization (ERAM) Air Traffic Manual (ATM): RA-

Position User Manual, 2012) and (EAA121L0 En Route Automation Modernization (ERAM) Air Traffic

Manual (ATM): R-Position User Manual, 2009), outline the functionality of the ERAM system and provide

a firm set of requirements that will be used to define the expected functionality of the ASTT. The game

design paper (Spuy, R. v. d., & SpringerLink, 2015) helps identify programmatic solutions to recreating the

interface simulation. This project will take advantage of the HTML5 canvas, sprites, scene graph,

interactivity, and collision detection solutions as inspiration moving forward.

Due to the GUI and ERAM complexity, it will be easy to create a solution exhibiting callback hell. It is a

high priority to organize the frontend code. The solution will be unwieldy if developed with conventional

JavaScript methodologies. Thus, we will look toward a more reactive approach to building the JavaScript

solution. As the two papers, (Bainomugisha, E., et Al, 2013) and (Kambona, K., Boix, E. G., & De Meuter,

W., 2013), on reactive programming indicated, choosing a premade framework is a wiser choice than

building it from scratch. Later we will compare various libraries and frameworks to determine the best

suited to this project.

SE690 GRP

Lastly, due to the experimental nature of the ASTT project, it is desirable to go with a prototype-friendly

approach to data architecture. The last paper (Machisa, M., 2005) talked about various patterns used

when developing an ORM implementation. The ASTT will take advantage of the row data gateway, identity

map, class table inheritance, and inheritance mappers when designing the data architecture. The Entity

Framework, the ORM solution bundled with DOT.NET Core, utilizes these patterns with an entity design

that maps directly to their corresponding tables and maintain foreign key relationships between related

entity hierarchies.

SE690 GRP

3. METHODOLOGY This section describes the methodology followed when designing the ASTT project. Section 3.1 pertains

to development environment, specifically choosing the software stack and configuration management

pipeline. Section 3.2 pertains to the front-end framework selection and technology exploration.

3.1. DEVELOPMENT ENVIRONMENT There are two focal areas to designing the development environment discussed in this paper. The first

pertains to the technology stack, or the layers of software components that provide functionality to the

project. The second area of concern is the configuration management pipeline. Depending on the

implementation, this can be considered a continuous integration (CI) solution.

3.1.1. TECHNOLOGY STACK

Setting up a good development environment first is vital to developing a large-scale project. Because the

ASTT is required to be a Web-based solution, only Web-based languages were considered. This project

requires Visual Studio, ASP.NET Core, MSSQL Server, and Node Package Manager (NPM). The platform

selection process and database integration overview via Object Relational Mapping (ORM) are discussed

below.

3.1.1.1. CHOOSING A WEB APPLICATION SERVER PLATFORM

Two Web application server platforms were assessed, namely ColdFusion (Helpx.adobe.com, 2017) and

ASP.NET Core (Quick Overview - EF Core, 2016). Each platform has its benefits and drawbacks which were

weighed to determine the best choice for the ASTT project.

ColdFusion, developed by Adobe, is a rapid development platform is well-suited to prototyping and is

designed to quickly create solutions with many powerful built-in features. These include a served admin

Web GUI, integrated ORM, and an interpreted runtime environment running on top a Java Virtual

Machine (JVM) which automatically recompiles the project upon saving. Internal ColdFusion libraries are

always accessible and do not need to be imported, allowing for leaner templates with less boilerplate

code. The code is loosely typed, allowing for a fluid coding approach. A developer version of the

ColdFusion server is free, but a standard single license is $1,499.

ASP.NET Core, developed by Microsoft, is a Web framework for the C# language. Because it is written in

C#, it provides a more conventional programming environment to that of ColdFusion. Where ColdFusion’s

internal libraries are always accessible and add to the application memory overhead, C# templates only

include libraries utilized within the template, allowing for a more optimized execution. ASP.NET Core has

an ORM package, Entity Framework, which while requiring significant bootstrapping and setup, provides

a highly tunable solution. When developing in ASP.NET Core, the integrated development environment

(IDE) of choice is Visual Studio which offers automated solution scaffolding, versioning software

integration, debugging, and IntelliSense, providing insight into the language features as well as the

available user-defined code. The IDE typically used for ColdFusion development is ColdFusion Builder, is

not well supported by Adobe, buggy, and lacks an equivalent feature to IntelliSense. Lastly, ASP.NET Core

does not have a pricing structure and is free for development and production deployments.

SE690 GRP

ASP.NET Core was the chosen platform for several reasons. First, while ColdFusion offers a powerful

prototyping environment, the benefits are outweighed by the learning curve required to develop in it.

Without a good code introspection/completion feature like IntelliSense, this learning curve is worsened.

Second, the ability to performance tune solutions outweighed the easy built-in features of ColdFusion.

The ASTT solution must be able to handle 200 simultaneous actively running scenarios with up to 20

simulated aircraft, so performance tuning is an important consideration. Lastly, the fact that ASP.NET Core

is free to deploy in production.

Table 1: Comparison of ColdFusion and ASP.NET Core Platforms

3.1.1.2. ENTITY FRAMEWORK

ORM is a database design pattern in which the actual database is abstracted from the codebase and its

tables are represented as entities, objects with create, read, update, and delete methods encapsulating

entity relationships. The database tables are defined as classes in the code and maintain relational joining

between the other tables in the schema. This enables developers to remove SQL queries from the

application to create a separation of concerns. It also decouples the database technology from the

application and allows for faster migrations.

ColdFusion ASP.NET Core

Dependent Language Java (via JVM) C#

Rapid Development Yes No

Strongly Typed No Yes

IDE ColdFusion Builder Visual Studio

C++ Library Support Partial Yes

Price $1,499 for server, $0 for dev $0 for server, $0 for dev

Language Documentation Yes Yes

Solution Documentation Partial, 3rd Party Yes

Integrated ORM Yes Through implementation

Code Introspection Partial Yes, with IntelliSense

Figure 5: High-Level Overview of ORM

SE690 GRP

Under the umbrella of ORM, there are many patterns that can be mix and matched to create a unique

solution (Machisa, M. 2005). Because the ASTT project will be using the Entity Framework (EF), this paper

identifies which ORM patterns are utilized to better understand the technology. As Machisa, M. described,

there are three categories of ORM patterns from which an implementation, Data Source, Behavior, and

Structural. An ORM solution must draw from each as the categories work together.

From the Data Source patterns, the EF uses Data Mapper as no SQL code is involved and the domain

codebase is separated from the database’s existence. The entity model classes from which the entities

are invoked do not contain SQL, rather they follow a declarative pattern and describe the functionality

instead of specifying every operation. The SQL is generated on the fly per request by the EF, and is not

seen by the developer.

The Repository and Unit of Work Behavior Patterns are not inherent characteristics of the EF, but are

often implemented to insulate the application from changes to the data store. The majority of this comes

in the form of object caching and transaction management, which is handled within the DbContext class.

A Repository and Unit of Work pattern example used in the EF is shown below.

Figure 6: Example of the Data Mapper Pattern

Figure 7: (Docs.microsoft.com, 2013) Example of Repository and Unit of Work Patterns in the Entity Framework

SE690 GRP

For the Structural patterns, EF implements Class Table Inheritance, or Table Per hierarchy. This is a highly-

normalized pattern in which each entity maps to the associated database row. In contrast to the Single

Table Inheritance pattern, the class relationship is preserved and the data is not returned in a flattened

object. While it makes the entities more complex, it is also more efficient as the domain model is directly

mapped. It also is beneficial as querying a parent entity will have the foreign key relationships associated

as child entities for iterative operations.

A fully realized EF environment contains Model, Controller, and Migration layers which work together to

manage the data model. The Migration layer is responsible for table maintenance and schema

restoration/versioning through snapshots. The Model layer defines the schema and entity relationships

and is responsible for the database integration. The Controller layer realizes the Model layer and provides

CRUD functionality for application consumption.

Figure 8: Entity Framework Class Architecture

3.1.2. CONFIGURATION MANAGEMENT PIPELINE

Choosing the right technology stack is a challenge, but ensuring it’s properly configured is just as

important as it dictates the production pipeline and creates a homogeneous workspace for the team to

reduce inconsistencies and potential roadblocks. The dependent architecture must be configured

identically for the project to run in a dependable fashion. The method most prone to problems is to

SE690 GRP

develop an environment reliant upon the host computer. The first issue is each developer must manually

install each dependent technology and configure it to work with their workstation. Unfortunately, each

workstation is usually running a different OS and may have outdated versions of installer software.

Secondly, if a development environment change is made, the specific update instructions must be

communicated to the other members of the team.

To prevent these issues, the goal was to create an instance that included the preconfigured software stack

in a sandboxed environment which each team member could run with minimal per-host configuration.

The other goal was to create a deployable environment that could be migrated to a production server

without having to reinstall and configure the software. Two methods were explored, the first was to create

a virtual machine (VM) within VirtualBox with the application and database server preconfigured. The

second method was to use Docker to create containers for each of the servers. In both methods, the

codebase is versioned using Git, with the repository hosted on GitLab. These methods, implementation

strategy, challenges, benefits, and negative aspects are discussed in the following subsections.

3.1.2.2. LINUX VM

The initial plan was to create an environment utilizing a VirtualBox VM to contain the platform

dependencies. Attempts to build a working environment were made using the distros Linux Mint, Fedora,

and Ubuntu. Finally, the Linux distro Red Hat Enterprise Linux (RHEL) was chosen for its compatibility with

ASP.NET Core and MSSQL Server and feature-rich toolset. The ASP.NET Core and MSSQL Server

technologies had to be installed and configured manually to realize the environment’s creation.

The host computer required a couple configurations to run the application within the VM. First, the project

directory was mapped to the VM’s filesystem within VirtualBox. This placed the codebase within the VM

to be run by the ASP.NET Core server. Second, the hosts file and network ports in VirtualBox had to be

configured to route localhost traffic on port 5000 (the port used by ASP.NET Core) to the VM. In the end,

we were not able to get this component working, though with additional research a solution may have

been found.

After the VM was fully setup and functional, it had to be exported as an “appliance” to be distributed to

the team along with the host computer configuration instructions. The same setup process was required

to configure the production server, which would not be running VirtualBox. If changes were required to

SE690 GRP

the VM, the entire process had to be repeated. Ultimately, an alternative to the manual configuration

management was sought after finding how troublesome the setup and maintenance proved to be.

3.1.2.2. DOCKER

Docker is a modular container-based platform intended to standardize project environment instances

along the development pipeline. In contrast to the VM pipeline where the environment configuration

must be manually distributed to the development team and managed on production, use of Docker can

provide version control and automated setup and configuration. The Docker software acts like VirtualBox

in that it runs VM’s in a sandboxed environment, but the compiled images can be deployed to any platform

with a running Docker instance.

Figure 9: VirtualBox VM Development Environment Architecture

SE690 GRP

Docker has several advantages over a typical VM configuration. First, the compiled images are not

versioned within VirtualBox manually, rather GitLab remotely manages the image versioning alongside

the codebase, allowing other developers and production environments to leverage changes

automatically. This eliminates the necessity to reinstall appliances or duplicate effort with configuration

updates. Second, the initial setup of a docker image with the desired technology stack in many cases has

already been completed by the technology developer. In the case of ASP.NET Core and MSSQL Server,

Microsoft provides pre-built versioned images. Using the Dockerfile and docker-compose.yml

configuration files (versioned within the code base), the custom per-project configuration changes are

abstracted and maintainable, something not easily performed in a VM. The Dockerfile file is run as a build

script to create custom images from existing base images using the command “docker build”. The docker-

compose.yml file is used to generate containers, running instances of images, with injected environment

settings such as port mapping and volume creation.

Figure 10: Docker Creation Workflow

SE690 GRP

Lastly, the custom configuration is abstracted from the base image updates. The Dockerfile (and docker-

compose.yml if creating containers directly from base images) specify which version of an image to use,

or “tag”. This non-destructive forking pattern is like the relationship between Cascading Stylesheets (CSS)

and Syntactically Awesome Stylesheets (SASS) projects. As a library developer like Bootstrap makes

changes to their CSS library, the SASS template contains the custom styles and the SASS build process

compiles the SASS and base CSS into a new CSS template to be used by the application.

3.2. REACTIVE FRAMEWORK Section 3.1 focused on the back-end architecture and the configuration management pipeline, but given

the ASTT project is a complex Web-based GUI solution, the front-end technology must be considered

carefully before designing the architecture. While a large portion of the project follows a typical Model-

View-Controller (MVC) Web architecture with dedicated pages and minimal JavaScript (JS) dependencies

for managing the model, the simulation interface is a Single-Page-Application (SPA) with a large amount

of data input/output and state management using JS. As such, the JavaScript code base can become unruly

with nested callbacks and imperative blocks (where the code describes the computational logic instead of

the application control flow) unless a framework is implemented.

Reactive programming is well-suited to SPAs because the interface can be broken into the parts which

comprise the application. JS is written to pertain to the concerns of the part, or component, to allow it to

be a self-contained entity which reacts to environmental changes without polluting the global scope. The

Figure 11: ASTT Docker Development Environment Architecture

SE690 GRP

following sections explore the reactive framework selection process and the inner-workings of the

selected framework.

3.2.1. FRAMEWORK SELECTION

A review was performed of the popular JS frameworks and libraries used for reactive programming. The

selection criteria focused on the technology’s division of concern and whether it was object-oriented.

Libraries and frameworks which had a clear separation of templates from the scripts were desired. Also,

the technology needed to have an integral state management feature.

Because learning a new framework can be time-consuming and may result in poor maintainability if the

framework support is dropped, libraries were first considered. Libraries are more easily replaced in the

event of loss of support. Of the libraries, RxJS and jQuery were rejected due to their non-functional non-

object-oriented architecture as well as their inability to manage self-contained entities as components.

Redux and MobX were rejected due to their reliance upon React.js as well as a poor separation of JS from

the CSS and Hypertext Markup Language (HTML). Unfortunately, no suitable library was found for the

ASTT project, so attention was turned to selecting a suitable framework.

Of the frameworks, Ember also had a poor separation of content as well as a deep reliance upon React.js

for the actual reactive functionality. The decision came down to deciding between React.js, Vue, and

Angular. Angular was eliminated due to its full-stack architecture as the back-end platform was already

decided to be ASP.NET. React.js relies upon the JS templates to define the HTML markup and CSS

application and does not have an integrated data management feature, which is necessary for caching

and routing shared data among the components.

Ultimately, Vue was found to be the best reactive programming solution to build the front-end of the

ASTT project.

Table 2: Front-End Reactive Technology Comparison

Library Type Separation

of JS from

CSS and

HTML

Pure

View

Integrated Data

Management

State

Management

React.js Framework X * X *

Vue Framework * * * *

Angular Framework X X * *

Redux Library X * * *

RxJS Library * * ? *

jQuery Library * * X X

MobX Library X * X *

Ember Framework X * * *

SE690 GRP

Table 3: Front-End Reactive Technology Comparison, continued

Library Object-

Oriented

ES5

Compatible

Self-

Contained

Uses

Components

Extensible

React.js * * * * *

Vue * * * * *

Angular * / * * *

Redux * * X * *

RxJS X * * X X

jQuery X * * X *

MobX * * X * X

Ember X X / * *

3.2.2. VUE.JS

Vue.js is a reactive framework that embraces classic Web technologies to provide organization and

functionality to SPAs. While it has full support of the JavaScript Syntax Extension (JSX) syntax, which allows

for HTML definition from within the JS template, it is not required to build solutions, as is the case with

React.js. Vue.js is designed around declarative rendering, which allows developers to specify what to

render, rather than how to render it. This key characteristic makes Vue.js templates highly organized and

reduces the need for boilerplate code. This paper doesn’t cover all the functionality of Vue.js, but provides

a high-level overview of its architecture and functionality.

While Vue.js represents an organizational framework within the application’s view layer, it is inspired by

the Model-view-viewmodel (MVVM) architectural pattern (vuejs.org, 2017). Within the MVVM pattern,

the Model represents the domain model, or real state content derived from the data access layer. The

View “defines the structure, layout and appearance of what the user sees on the screen”

(MSDN.microsoft.com, 2012). The View Model manages view logic for the application and acts as an

intermediary between the model and the view. This pattern provides compartmentalization of the

codebase, which allows developers to isolate component functionality, developing and releasing

SE690 GRP

components as features. In Agile SCRUM, projects are divided into backlogged features to be developed,

so a framework that plays into the SCRUM methodology is a bonus benefit.

Vue applications are instantiated with a Vue Instance which “can be organized into a tree of nested

reusable components”. In Vue, components encapsulate reusable code by extending the set of basic

HTML elements. These appear as custom HTML elements to which the Vue compiler can attach behaviors.

Components can be self-contained, or contain a tree of sub-components, or “child components”. Parent

components pass “props” down to its child components and listen for events emitted from the child

components.

Components and elements listen for events through data binding. This pattern is different from a retrieval-

based pattern found in vanilla JS and libraries like jQuery where an operation contains a callback function

to imperatively obtain property’s state. Above the standard DOM events like onChange, onBlur, etc...,

there are events triggered and managed within Vue which can be applied to more than just HTML DOM

elements. This is made possible through Vue’s Virtual DOM. Elements or properties dependent upon other

element’s state or properties have hooks defined as data binding statements. For example, a button tag

may have the parameter: v-bind:disabled=”isButtonDisabled”. This hooks into the global variable

“isButtonDisabled” and toggles the disabled attribute depending on the value in the variable. As the

variable is changed, the button automatically follows suit without the need to expressly define an

attribute change.

Figure 12: MVVM Architecture

SE690 GRP

4. ARCHITECTURAL DESIGN The ASTT application is comprised of four technologies. The application built in ASP.NET Core houses the

ASTT logic, processing telemetry from JSBSim instances and input from the SPA. JSBSim is instanced to

provide a simulated flight environment for the aircraft in the scenario, which interfaces with the app via

socket connections for real-time I/O. The SPA provides the scenario simulation view, rendering scenario

and telemetry data sent from the app and sending input commands back to be processed by the

Application Specific Domain Language and sent to the simulation instances. As scenario attempts

progress, simulation telemetry and user input are recorded in the database for future reporting and

grading.

This section will define the architectural design of the ASTT project and has been divided into two areas

of concern. Section 4.1 covers the design of the ASP.NET Core server application, specifically the functional

class design. Section 4.2 considers the interface architecture for the scenario simulation SPA.

Figure 13: ASTT High-Level Architecture & Data Flow

SE690 GRP

4.1. SERVER APPLICATION DESIGN The ASP.NET Core application design is comprised of two main categories of entities, the application class

structure and the scenario XML data structure. In figure 10, the overall application architecture is defined

with the green entities pertaining to the entities found in the parsed scenario XML. When appropriate,

the relationship between the application classes and their XML entity sources will be identified. Since the

XML is only consumed once and is provided by the FAA, the data structure will not be analyzed in this

project.

Figure 14: Application and XML Architecture

SE690 GRP

4.2.1. APPLICATION CLASSES

The application classes represent the functionality of the ASTT application, the Controller in MVC. Data

processing and manipulation is isolated to this domain to provide a clear-cut division of concern and a

maintainable extensible environment.

4.2.1.1. USER

The user class is used to create the in-session user object and handles the initialization and termination

of scenario attempts. There is also an ORM entity class for user that manages the database CRUD

operations.

Figure 15: User class

Table 4: User Class Description

Attribute/Method Description

activeScenario Contains the active scenario

attempt object.

role Contains an array of roles

attributed to the user.

createUser Creates a new User object.

killScenario Emits the scenario end

command for the scenario

attempt object to end the

simulation.

runScenario Creates a new scenarioAttempt

object and assigns it to the

activeScenario attribute

SE690 GRP

4.2.1.2. SCENARIO

The Scenario class houses the parsed data from the XML in an easily interfaceable object for reference

and attempt instancing. This class is also tied to the ORM equivalent entity class Scenario which saves the

data to the database.

Figure 16: Scenario Class

Table 5: Scenario class description


airspace Contains the airspace

element, derived from the

scenario XML

scenarioElement Specifies the parent node

in the scenario XML that

corresponds to this object

events An array of timestamped

events that will occur

during the scenario’s

execution

flights An array of flight objects

used to generate JSBSim

instances

sectors An array of sector objects

used to generate the map

view

createEvent Creates a new event object

from the scenario XML

createFlight Creates a new flight object

from the scenario XML

createScheduler Creates a new scheduler

instance to handle and fire

the scenario events

readScenarioFile Performs file I/O and sends

to the XML parser

These two classes are an example of the application structure of the ASTT solution. The rest of the

application classes with their properties and methods are defined in Appendix A: Application Classes.

SE690 GRP

4.2. DATABASE SCHEMA DESIGN The database is managed through the ORM implementation of the EF and the tables are defined in the

code base. As changes to the database schema are made in code, ORM updates the actual database upon

running the reload command. The entity classes are responsible for managing database I/O and no user-

defined SQL is required, though for complex operations this can be overridden.

The scenario-related tables follow a typical item/order/ordered item pattern found in online shopping

databases. The UserScenarioAttempt copies the pertinent scenario columns to save the scenario specifics

at the time the attempt was taken. While this may appear to be a duplication of data,

UserScenarioAttempt holds a history of the Scenario configuration at that time. The same pattern goes

for the relationship between UserEvent and Event where a UserEvent is created to show a history of user

responses to events triggered in the scenario attempt.

The security-related tables are designed to reduce the amount of per-user configuration required upon a

site-wide access change. Each user has one role, which in-turn has many permissions. The role-permission

mapping is done in the RolePermission table. This pattern was found to be the most flexible as it not only

provides the ability to make global permission changes due to the user-permission abstraction, but in the

case of special users, unique roles can be created to meet their needs. The benefit of abstracting

permissions from roles is that roles can now share access, a convenient feature when a page or widget

needs to be accessible by more than one role. Instead of updating the code base every time a new role is

created, access can be granted through data configuration.

Figure 17: Database Schema Design

SE690 GRP

4.3 FRONT-END DESIGN The ASTT simulation interface developed in Vue.js is comprised of a large component tree, separated into

two branches for the ERAM contexts. As was seen in the simulation mockup in Figure 4, the user can

choose which context to set as active. The highest level Vue component, Simulation, contains these

toggles and listens for a context change event and pushes the active context state down its tree via props.

The Simulation component is the only component in the application with a server connection, so as state

changes are pushed down through the socket connection and user events are triggered in the application,

this traffic is routed to this component to isolate I/O operations and easily manage the scenario state.

4.2.1. R-POSITION

The R-Position context components are parented under the RPositionGrid component. As visual

components are toggled on and off from the control panel in the Simulation component, the components

are added and removed from the grid. The toggleable components are the Radar, Keyboard, Keypad, and

Trackball, which each extend the canvas tag and contain child button components.

Figure 18: Simulation & Context components

Figure 19: R-Position components

SE690 GRP

The Radar component simulates the radar view for the R-Position and its component tree reflects the

features and visual elements contained. As previously stated, the Radar component extends the canvas

tag, so its child components are drawn elements and do not correlate to standard HTML markup.

4.2.2. RA-POSITION

Like the R-Position grid component, the RAPositionGrid acts as the parent for the R-Position context and

is toggled via the Simulation component context inputs. It should be noted that the two grids are not

destroyed upon toggling, so the nested user GUI configuration persists until the browser window is closed.

Also, like the RPositionGrid component, it has child components for the Keyboard, Keypad and Trackball.

In an encapsulated manner, these components are developed to be instanced multiple times in a single

Vue application but only the parent component intercepts the instance’s triggered events, stopping event

propagation.

The RA-Position Computer-Human Interface (CHI) component is the EDST launchpad for all the sub-

interfaces, managed from the RAPositionToolbar component. There are 13 sub-interfaces, like the Aircraft

List View, that can be toggled from the RAPositionToolbar. The Vue component tree for each of these can

be found in Appendix B: Vue.js Architectural Map of the RA-Position EDST Sub-Interfaces.

Figure 20: R-Position: Radar components

SE690 GRP

5. CONCLUSIONS

5.1. SUMMARY Recreating the ERAM environment in a Web environment is a large undertaking, let alone wrapping it in

a highly configurable training environment. The system itself has two roles actively engaged and

performing actions, but the instructor’s needs also must be satisfied for an online scenario-based training

application (ATC Scenario Training Technology – ASTT) to be a viable training platform for the FAA. This

project explored the team development practices and full-stack application architecture required to

realize such a project. The technology stack selected was ASP.NET Core; chosen for its price, tunability,

IDE, and ORM functionality. Due to the application’s complexity and experimental nature of the ASTT’s

first iteration, ORM was chosen to act as the I/O layer between the application and the database, allowing

the schema to be flexible when the application’s data requirements shift in the future. Two versions of

the CI pipeline were explored, with the Docker implementation being chosen for its automatic

configuration management features. Lastly, the front-end architecture was discussed, focusing on

selecting a suitable reactive programming framework to organize the JavaScript and HTML code base. The

realization of the ASTT architecture was thoroughly defined, focusing on the ASP.NET Core application, EF

database schema, and the Vue.js implementation of the scenario simulation SPA interface.

Figure 21: RA-Position components

SE690 GRP

5.2. FUTURE WORK Moving forward, performance and usability will be important topics to address. Due to the high-level of

data I/O between the JSBSim instances, ASP.NET Core app, Vue.js SPA, and the MSSQL database, packet

creation, in-memory/file caching, load balancing, and server clustering will need to be investigated. On

the interface area of concern, a human factors study on the viability of the grid, layout, and navigation

will be topics of import as the ASTT application needs to provide an environment to students that feels

close to what they will experience on the live ERAM system in the field.

SE690 GRP

6. REFERENCES En Route Automation Modernization (ERAM). (2015, April 29). Retrieved November 05, 2017, from

https://www.faa.gov/air_traffic/technology/eram/

EAC11000 En Route Automation Modernization (ERAM) Air Traffic Manual (ATM): RA-Position User

Manual [PDF]. (2012, August 1). William J. Hughes Technical Center, Atlantic City International

Airport, New Jersey 08405: En Route and Oceanic Services, Federal Aviation Administration.

EAA121L0 En Route Automation Modernization (ERAM) Air Traffic Manual (ATM): R-Position User Manual

[PDF]. (2009, April 28). William J. Hughes Technical Center, Atlantic City International Airport, New

Jersey 08405: Program Operations, ATO Office of En Route and Oceanic Services (ATO-E), Federal

Aviation Administration.

(2017). Metacraft.com. Retrieved 21 November 2017, from

http://www.metacraft.com/Assets/Images/Products/Lightbox/VSCSAG.png

JSBSim Open Source Flight Dynamics Model. (2017). Jsbsim.sourceforge.net. Retrieved 21 November

2017, from http://jsbsim.sourceforge.net/

Kwak, Y. H., & Stoddard, J. (2004). Project risk management: Lessons learned from software development

environment. Technovation, 24(11), 915-920. doi:10.1016/S0166-4972(03)00033-6

Spuy, R. v. d., & SpringerLink (Online service). (2015). Advanced game design with HTML5 and JavaScript.

Berkeley, CA: Apress.

Bainomugisha, E., Carreton, A. L., Cutsem, T. V., Mostinckx, S., & Meuter, W. D. (2013). A survey on

reactive programming. ACM Computing Surveys (CSUR), 45(4), 52.

Kambona, K., Boix, E. G., & De Meuter, W. (2013). An Evaluation of Reactive Programming and Promises

for Structuring Collaborative Web Applications.

Klein, J., & Morey, S. (2011, May). Use of ERAM SWIM for NAS system enhancements. In Integrated

Communications, Navigation and Surveillance Conference (ICNS), 2011 (pp. E1-1). IEEE.

Rising, L., & Janoff, N. S. (2000). The scrum software development process for small teams. IEEE Software,

17(4), 26-32. doi:http://dx.doi.org.ezproxy.libproxy.db.erau.edu/10.1109/52.854065

Machisa, M. (2005). Object Relational Mapping for Enterprise Application Architecture.

Torres, A., Galante, R., Pimenta, M. S., & Martins, A. J. B. (2017). Twenty years of object-relational

mapping: A survey on patterns, solutions, and their implications on application design.

Information and Software Technology, 82, 1-18. doi:10.1016/j.infsof.2016.09.009

Quick Overview - EF Core. (2016). Docs.microsoft.com. Retrieved 12 November 2017, from

https://docs.microsoft.com/en-us/ef/core/

Implementing the Repository and Unit of Work Patterns in an ASP.NET MVC Application (9 of 10). (2013).

Docs.microsoft.com. Retrieved 16 November 2017, from https://docs.microsoft.com/en-

SE690 GRP

us/aspnet/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-

the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application

Modern Web Development using ASP.NET Core template, Vue.js and Webpack | DotNetCurry . (2017).

Dotnetcurry.com. Retrieved 12 November 2017, from

http://www.dotnetcurry.com/aspnet/1383/modern-web-dev-aspnet-core-webpack-vuejs

Quickstart: Compose and ASP.NET Core with SQL Server. (2017). Docker Documentation. Retrieved 12

November 2017, from https://docs.docker.com/compose/aspnet-mssql-compose/

Get started with SQL Server 2017 on Docker. (2017). Docs.microsoft.com. Retrieved 12 November 2017,

from https://docs.microsoft.com/en-us/sql/linux/quickstart-install-connect-docker

.NET Core 2.0 Hello-world | Red Hat Developers. (2017). Developers.redhat.com. Retrieved 12 November

2017, from https://developers.redhat.com/products/dotnet/hello-world/

Get started with SQL Server 2017 on Red Hat Enterprise Linux. (2017). Docs.microsoft.com. Retrieved 12

November 2017, from https://docs.microsoft.com/en-us/sql/linux/quickstart-install-connect-

red-hat

Helpx.adobe.com. (2017). Find resources and get support for Adobe ColdFusion. [online] Available at:

https://helpx.adobe.com/coldfusion/home.html [Accessed 14 Nov. 2017].

The MVVM Pattern. (2017). Msdn.microsoft.com. Retrieved 19 November 2017, from

https://msdn.microsoft.com/en-us/library/hh848246.aspx

SE690 GRP

APPENDICES

APPENDIX A: APPLICATION CLASSES

Figure 22: FlightManager Class

Table 6: FlightManager class description


fireEvent Triggers an Event,

registering it in the DB and

fires runCommand for

each telemetric command

contained in an Event for

the respective Flights

runCommand Sends telemetry updates

to the Flight’s JSBSim

instance

SE690 GRP

Figure 23:Flight class

Table 7:Flight class description


aircraft Contains the Aircraft object

associated with the Flight

beaconCode The identifying 4-digit transponder /

squawk code

callSign 3-character string identifier

expiresAt Timestamp at which the flight ends

flightElement The corresponding flightElement

object derived from the scenario XML

initAlt Initial altitude value

initHeading Initial heading value

initSpeed Initial speed value

route Initial flight plan

tailNum Aircraft tail number

uid

SE690 GRP

Figure 24: JSBSim class

Table 8: JSBSim Class Description


inputSocket The socket JSBSim

monitors to receive

commands

outputSocket The socket JSBSim

sets to send flight

telemetry

createScriptFile Generates the flight

log file

getInputSocket Returns the input

socket

getOutputSocket Returns the output

socket

launchSim Triggers the

simulation to run and

sets the flight state to

active

receiveAircraftState Compiles the aircraft

telemetry

sendControlCommand Sends received

control command to

flight sim

SE690 GRP

Figure 25: PortManager class

Table 9: PortManager Class Description


allocatePort Creates a port listener in the

ASTT application

deletePort Removes a port listener from

the ASTT application

Figure 26: FlightSimulator class

Table 10: FlightSimulator Class Description


launchSim Starts the flight

simulation

SE690 GRP

Figure 27: Aircraft class

Table 11: Aircraft Class Description


ACType Type of Aircraft

acTypeInfo Aircraft Type

flight

characteristics

Figure 28: AircraftType class

Table 12: AircraftType Class Description


Figure 29: AircraftState class

Table 13: AircraftState Class Description


SE690 GRP

Figure 30: DepartureFlight class

Table 14: DepartureFlight Class Description


filedAlt Starting altitude

filedSpeed Starting ground

speed

departureFlight Register

departure flight

~departureFlight Unregister

departure flight

Dispose Delete departure

flight instance

Figure 31: ActiveFlight class

Table 15: ActiveFlight Class Description


alt Current altitude

heading Current heading

speed Current speed

vSpeed Current vertical

speed

SE690 GRP

Figure 32: Altitude class

Table 16: Altitude Class Description


AGL Altitude above

ground level

(Absolute

altitude)

MSL Altitude above

mean sea level

(True altitude)

Figure 33: Speed class

Table 17: Speed Class Description


CAS Calibrated

airspeed

GS Groundspeed

TAS True airspeed

SE690 GRP

APPENDIX B: VUE.JS ARCHITECTURAL MAP OF THE EDST SUB-INTERFACES

Figure 34: RA-Position: DL View components

SE690 GRP

Figure 35: RA-Position: ACL View components

d implementation challenges of a web based air...

Documents