1200.aero

Architecture
In-flight emergency
Near-miss detection
Live notifications
Traffic pattern practice

Inspiration

1200.aero was created by a small team of pilots and aviation enthusiasts. Inspiration came from a near-mid-air collision one of the authors experienced in the fall of 2015 as he departed his favorite airport. In the information age, there is still no data about the airspace surrounding small airports, and that's what we're set out to improve.

What it does

1200.aero is a monitoring service specifically developed for general aviation. It relies on a network of airport-based ADS-B receivers to analyze air traffic data that can be used to enhance safety.

Tracking history: Facilitates pilot flight debriefs by tracking aircraft of interest, capturing 1-second grain data about takeoffs, maneuvers, approaches, landings, and even taxiing activity.
NMACs: Potential near mid-air collisions detected between two or more aircraft (as defined by the FAA, a good example here). Data is anonymous to protect privacy.
Events: Emergency transponder codes, unusually low flying aircraft, excessively high descending rates, and combinations thereof. Data is anonymous to protect privacy.
Live notifications for the above features, sent via SMS to subscribers.
Live traffic: Renders live traffic directly from all ADS-B stations (currently KRDU, KLZU, KJNX). Reuses work from the ADS-B Receiver and dump1090-mutability projects.
Airport traffic: Visualizes collective traffic pattern trends by airport in the last two weeks.

How we built it

The team leveraged years of experience in areas like NoSQL distributed databases and infrastructure and webapp development. The platform's MVP was originally envisioned in AWS but implemented using Kafka/Spark/Cassandra due to our familiarity with that stack. We finally ported it to AWS for scale, availability and as a stretch goal.

Challenges we ran into

Sourcing data from the devices took days of research. Thankfully, we were able to reuse open source work already in place to feed established tracker sites like FlightAware and ADSBExchange.
Integrating dependencies between Spark Streaming and Kafka for the first time took several days to get right. Turned out much easier for Kinesis and EMR Spark.
DynamoDB took some getting used to, given its restrictions coming from Cassandra.

What's next for 1200.aero

Continue to grow user adoption and airport coverage.
Better UI to depict altitude profile.
Slack integration for use in the field by flight schools

Built With

Submitted to

AWS IoT App Challenge
- Winner Second Place

Created by

I worked in the development of an NodeJS API to retrieve the data from the Cassandra Database and send it to the web UI.

sdelosrios95
Developed the integration between Raspberry Pi devices and Kinesis/Spark/DynamoDB back end, as well as the event detection logic (in Scala) based on own flight experience and that of fellow pilots.

Ivan Vasquez
https://www.linkedin.com/in/ivan-vasquez-0230766/
I worked in the platform side building the network infrastructure, security, scalability strategy, container design , and automation. We migrated the frontend webUI user interface and non SQL database access API from an Openstack solution running in premisses, to a EC2 Container Service. We used cloudformation to orchestrate most of the AWS operations including VPC, security, auto scaling groups, load balancer, ECS cluster, and more.

Oscar Bermeo
I worked in the development of the UI and backend APIs. The UI was developed in Angular 1.6, integrated with Google maps. The backend was developed in Node.js and DynamoDB as database engine.

David Eduardo Morales