Introduction
The article describes a Microsoft IoT on Azure contest submission: "Perpetuum-M" Windows application (hereinafter - WinApp) intended primarily for New York City commuters and respective MTA Agencies. It allows real-time tracking of any of 316 MTA bus routes [2,3] on any mobile or stationary Internet-enabled PC computer hardware equipped with Microsoft Windows 7/8 OS. The solutions is backed by Microsoft Azure cloud technologies, thus live Internet connectivity is required for its core real-time operations.
This Win app is extending the functionality of previously released HeMoSiBi™ Windows application [10] (trial edition of that Win app is attached to this article for demo purpose). The Web app counterpart "enRoute" app [15], complementing this one, provides additional capability of running in web browser on any Internet-enabled platform (not limited to just Windows OS).
Technical merits
Win app allows continious real-time MTA bus monitoring with output to dynamic bus-schedule (list) and bus map data visualization controls. It utilizes novell capabilities of real-time mass transit data feeds (GTFS, SIRI, OBA [5-7]) and technical-enabling vectors of Microsoft Azure cloud services. Aesthetically-rich and intuitive application UI is adapted for mobile devices of various form-factors. The application can be categorized as a real-time distributed "SCADA over Internet" (a.k.a. IoT) solution with primary focus on monitoring (supervisory) and data acquisition functionality.
Broader impact
Daily ridership pertinent to Metropolitan Transportation Authority in New York City exceeds 10 million [2,3] (almost 2x of entire population of Norway). Proposed solution is addressing important socio-economic issue of a high magnitude by providing substantial technical assistance to mass-transit computters in NY City. Core solutions dedicated to realtime MTA Bus monitoring can be also applied to other transportantion vehicles, like NY Subway, LIRR and MNR.
Audiences
Individual commuters are expected to form a major and rather substantial User group. NY City governmental agencies and some infrastructure services may utilize the capabilities provided by this solution. Also, a solution could be used by variety of private Companies headquarted in the New York City.
Hardware Platform/OS
This IoT application [1] is adapted for any PC platform ranging from smart phones to powerful desktop computers with focus made on high-end Tablets/Notebooks equipped with Intel i3/i5/i7 CPU. This app is extending the original functionality of the previously developed HeMoSiBi™ app [10], which was essentially a "static" one utilizing its internal storage containing NY Subway data. Unlike its predecessor, this app utilizes variety of real-time NY MTA Bus data services (feeds) described in [6-9]. It's Azure backend services are made quite similar to the ones consumed by the complementary real-time bus tracking Web application [15], utilizing plenty of reusable code base of Azure cloud services developed in the context of that web app.
Development approach and tools
This solution has been developed using Microsoft core technology set: .NET4.5/C#, SQL Server, WPF/XAML, Azure cloud services and real-time data feeds provided by NYC MTA API for the developers (require a valid API access key [6-9]). Target framework for this app is set to .NET Framework 4 Client Profile.
Background
Internet of Things (IoT) [1] is considered a relatively new technical trend, though many of its core concepts have been known for decades. Apparent similarity can be noticed with existing SCADA systems [2], in particular, telemetry systems, wireless sensors networks, distributed control and automation systems. The core difference is rooted in packet-switching communication protocols (TCP/IP) used by IoT instead of circuit/channel switching techniques typical for traditional SCADA systems.
System Architecture
System Architecture diagram is composed of this Windows app running on the client's machine, plus all related Azure cloud functionality consumed by the app. It adheres to the fundamental concept of separation of programming concepts, i.e. logical (and optionally, physical) separation of Data Layer, Business Intelligence (BI) and User Interface (GUI). Simplified Architectural diagrams are shown below:
Fig. 1a. Generalized Architectural diagram of the proposed 'IoT on Azure' solution (covers both Web/Win app)
Fig. 1b. System Architecture of upscaled version of this Windows/PC application (under dev)
Prototype
The solution was partially prototyped on scaled-down simulated bus routes/stops data set, mostly for the purpose of testing the concept of smooth asynchronous reat-time operations based on ObservableCollection .NET data object (described in the follwoing sub-chapter). The sample demo screenshot is shown below:
Fig. 2. Scaled-down proto: testing the reatime async operations (demo screenshot)
This IoT Win app will utilize many reusable components of the the previosuly developed app HeMoSiBi™ [10] (trial edition of that app is attached to this project for demo purpose - see the sample screenshot below).
Fig. 3. Proposed solution will utilize code base/layout of the previosuly developed app HeMoSiBi™
MTA Data Feeds
Real-time NYC bus tracking requires several type of web query requests to be sent to the correponding SIRI and OBA end points as detailed in [6-9]. Response data stream could be formatted either as JSON or XML document. The solution implements a proprietary parser which deserialize the online data stream into corresponding software object using .NET/C#.
GTFS
General Transit Feed Specification (GTFS, originally: Google Transit Feed Specification) defines a common format for public transportation schedules and associated geographic information [6]. A GTFS feed is a collection of CSV files (main list follows) encapsulated into a single ZIP file.
- agency.txt
- routes.txt
- trips.txt
- stop_times.txt
- stops.txt
- calendar.txt
Dedicated procedure performs data import from GTFS static feed into application Databases (SQL Servers), w/most important tables containing agency, routes and stops records.
OBA
The open source OneBusAway (OBA) API allows to "discover" static/baseline information about the bus services covered under MTA [7].
SIRI
Service Interface for Real Time Information (SIRI) is an XML protocol to allow distributed computers to exchange real-time information about public transport services and vehicles [8]. Pertinent to the application tasks, two real-time data feeds are used: VehicleMonitoring and StopMonitoring
Parser
The parser module de-serialize the OBA/SIRI "stops-routes-agency" data streams (Xml encoded) and transforms them into the corresponding software objects to be used by both Win/Web applications [9]. It's relevant to mention that Agencies and Stops data could be also obtained from the "static" GFTS data feeds and stored in application database as mentioned above, thus removing one data request from the real-time update cycles. The final data set contains Stops static data with superimposed real-time Buses position data.
Web API
MTA buses equipped with GPS sensors provide real-time vehicle location information via OBA/SIRI data feeds [6,7]. In addition to the downstreams provided by OBA/SIRI, additional upstream functionality, i.e a crowdsourcing real-time data channel will enhance the data capability of the solution. Two major sets of Web API are intended for:
- Real-time bus routes/vehicles locations data feed (downstream)
- Implementing feedback channel for gathering the "crowsdourcing" data (upstream)
Feedback channel
Currently under consideration are several upstream data feeds providing the following metrics: bus occupancy and bus awaiting population at stops. In addition to this, a set of unique proprietary metrics reflecting energy efficiency, commuting safery and comfort [11] could be added to the upstream data channel.
IoT technical-enabling vectors of modern "Wintel" PC
The aforementioned "upstream" (feedback) part of the solution may utilize various technical-enabling vectors of modern "Intel Inside" PC platforms, in particular, integrated sensors: GPS, Axelerometers, Position and Orientation Sensors (optionally - electronic compass). Win app implements additional functionality utilizing bi-directional data feed: downstream providing vehicle/stops location and upstream sending a "crowdsourcing" data set back to the server. Such upstream data feedback may include multiple scalar metrics based on the embedded sensors' reading (PC Tablets/Ultrabooks) and proprietary algorithms: Ergometric Driving Efficiency Ratio (EDER), Acceleration Conformance Ratio (ACR), Dynametric Driving Comfort Ratio (DDCR ), Dynametric Driving Risk Ratio (DDRR) developed by Author [10].
Geospatial search engine
Current web application utilizes intrinsic geospatial search capabilities of Microsoft Bing Map technology, allowing the User to find points of interest nearby the bus routes (or in any User-selected area on the map). Future development may include Azure search services to enhance this functionality.
Using the code
Typical Bus Route and Bus Stop Xml data structure encoded in reatime data feeds is shown below (see Listing 1, 2):
Listing 1. NY MTA Bus Route element, XML-encoded
<route>
<id>MTA NYCT_M1</id>
<shortName>M1</shortName>
<longName>Harlem - East Village</longName>
<description>via 5th Av / Madison Av</description>
<type>3</type>
<url>http://web.mta.info/nyct/bus/schedule/manh/m001cur.pdf</url>
<color>EE352E</color>
<textColor>FFFFFF</textColor>
<agencyId>MTA NYCT</agencyId>
</route>
Listing 2. NY MTA Bus Stop element, XML-encoded
<stop>
<id>MTA_400001</id>
<lat>40.73064</lat>
<lon>-73.99044</lon>
<direction>N</direction>
<name>4 AV/E 9 ST</name>
<code>400001</code>
<locationType>0</locationType>
<wheelchairBoarding>UNKNOWN</wheelchairBoarding>
<routeIds>
<string>MTA NYCT_M1</string>
<string>MTA NYCT_M2</string>
<string>MTA NYCT_M3</string>
</routeIds>
</stop>
Note: the Author recently opened an issue ticket on OBA GitHub [8] requesting the reduced-size response document
In a context of core app functionality, the most important data items of the Xml node in Listing 2 are: stop id, coordinates (Latitude/Longitude), name and direction. The collection of stops can be displayed on the map (in particular, using Bing technology as it was done in application "HeMoSiBi" [9]) and also shown in pure text format as data list with super-imposed bus location retrieved in real-time (actually, "pseudo" real-time as the intrinsic Internet protocol uncertainties and delays do not allow precise timing: in general, response/process time within 1...3 sec is feasible and reasonable for this type of application). App timer keeps updating the selected vehicles (buses) location relative to stops at predefined interval (e.g. 10 sec, which is reasonable for this type of app). App also allows forcing the immediate data update by User ("Refresh" Button).
GIS Functions
Calculation of the distance between two geo-point on the surface is one of the core GIS functions. Multiple algorithms (see the Listing 3) exist, which differ by performance/accuracy [12-14].
Listing 3. Basic GIS functions to calculate distance between two geo-point on the surface
using System;
namespace BusNY
{
internal enum UnitSystem { SI = 0, US = 1 }
internal static class GIS
{
#region internal: properties (read-only)
internal static double EarthRadiusKm { get {return _radiusEarthKM;} }
internal static double EarthRadiusMiles { get { return _radiusEarthMiles; } }
internal static double m2km { get { return _m2km; } }
internal static double Deg2rad { get { return _toRad; } }
#endregion
#region private: const
private const double _radiusEarthMiles = 3959;
private const double _radiusEarthKM = 6371;
private const double _m2km = 1.60934;
private const double _toRad = Math.PI / 180;
#endregion
#region Method 1: Haversine algo
internal static double DistanceHaversine(double Lat1,
double Lon1,
double Lat2,
double Lon2,
UnitSystem UnitSys ){
try {
double _radLat1 = Lat1 * _toRad;
double _radLat2 = Lat2 * _toRad;
double _dLatHalf = (_radLat2 - _radLat1) / 2;
double _dLonHalf = Math.PI * (Lon2 - Lon1) / 360;
double _a = Math.Sin(_dLatHalf);
_a *= _a;
double _b = Math.Sin(_dLonHalf);
_b *= _b * Math.Cos(_radLat1) * Math.Cos(_radLat2);
double _centralAngle = 2 * Math.Atan2(Math.Sqrt(_a + _b), Math.Sqrt(1 - _a - _b));
if (UnitSys == UnitSystem.SI) { return _radiusEarthKM * _centralAngle; }
else { return _radiusEarthMiles * _centralAngle; }
}
catch { throw; }
}
#endregion
#region Method 2: Spherical Law of Cosines
internal static double DistanceSLC(double Lat1,
double Lon1,
double Lat2,
double Lon2,
UnitSystem UnitSys ){
try {
double _radLat1 = Lat1 * _toRad;
double _radLat2 = Lat2 * _toRad;
double _radLon1 = Lon1 * _toRad;
double _radLon2 = Lon2 * _toRad;
double _centralAngle = Math.Acos(Math.Sin(_radLat1) * Math.Sin(_radLat2) +
Math.Cos(_radLat1) * Math.Cos(_radLat2) * Math.Cos(_radLon2 - _radLon1));
if (UnitSys == UnitSystem.SI) { return _radiusEarthKM * _centralAngle; }
else { return _radiusEarthMiles * _centralAngle; }
}
catch { throw; }
}
#endregion
#region Method 3: Spherical Earth projection
public static double DistanceSEP(double Lat1,
double Lon1,
double Lat2,
double Lon2,
UnitSystem UnitSys ){
try
{
double _radLat1 = Lat1 * _toRad;
double _radLat2 = Lat2 * _toRad;
double _dLat = (_radLat2 - _radLat1);
double _dLon = (Lon2 - Lon1) * _toRad;
double _a = (_dLon) * Math.Cos((_radLat1 + _radLat2) / 2);
double _centralAngle = Math.Sqrt(_a * _a + _dLat * _dLat);
if (UnitSys == UnitSystem.SI) { return _radiusEarthKM * _centralAngle; }
else { return _radiusEarthMiles * _centralAngle; }
}
catch { throw; }
}
#endregion
}
}
Mathematically speaking, all three algos result in computation of a great-circle (orthodromic) distance on Earth between 2 points, though the accuracy and performance are different. In a context of current application they all provide reasonably good approximation with error margin typically not exceeding couple meters within NY City boundaries. All three aforementioned algorithms are based on spherical model of the Earth. More accurate ellipsoidal model (e.g. Vincenty’s solution) exists reducing the error margin to the fraction of mm (such accuracy is obvious "oiverkill" for current application), but also substantially increasing the computational complexity. Therefore, Method 3 (Spherical Earth projection ) has been selected providing the highest computational performance with reasonable accuracy.
Points of Interest
ObservableCollection in a Realtime app
The app utilizes its UI/XAML visual elements binding to ObservableCollection object, constantly updated with data pulled from realtime SIRI/OBA data feeds. ObservableCollection works reasonably well dealing with SQL Add/Delete operation, while Update case requires a bit of additional coding, namely: implementing INotifyPropertyChanged Interface in Stop() class used by ObservableCollection<Stop>;
Listing 4. INotifyPropertyChanged implemented in Stop() class used in ObservableCollection<Stop>
public class Stop : INotifyPropertyChanged
{
public string Service { get; set; }
public int StopID { get; set; }
public int Position { get; set; }
public string Status { get; set; }
private string _station = String.Empty;
public string StopName
{
get { return _station; }
set {
if (value != _station)
{
NotifyPropertyChanged("StopName");
_station = value;
}
}
}
public event PropertyChangedEventHandler PropertyChanged;
private void NotifyPropertyChanged(String info)
{
if (PropertyChanged != null)
{
PropertyChanged(this, new PropertyChangedEventArgs(info));
}
}
private bool _isExpanded = true;
public bool IsGroupExpanded
{
get { return _isExpanded; }
set { _isExpanded = value; }
}
}
ObservableCollection<Stop> _ocStops = new ObservableCollection<Stop>();
IoT in a Nutshell
What is IoT?
IoT is a distributed SCADA (i.e. Supervisory Control and Data Acquisition) built on Internet-related packet-switching protocols (most notably TCP/IP and HTTP).
How IoT is different from traditional Internet?
As stated above, IoT is adding more SCADA functionality to the traditional Internet, which can be categorized as mostly "Internet of People". IoT should be considered an extension to the traditional Internet, even though many use-cases pertinent to distributed SCADA systems existed long before the term IoT was coined. Important difference also lies in the fact that in traditional Internet the receiving part of data/signals were primarily human beings, while IoT is expected to add more use-cases pertinent to direct machine-to-machine interactions.
How IoT is different from traditional SCADA?
Data/Signal transport mechanism is an important classification criteria. The difference between packet-switching networks and circuit-switching ones is goind much deeper than just semantics: by analogy, look at the difference between wired and wireless networks, which is quite substantial to be considered the two different sub-classes in networking taxonomy. From design/analytical perspectives, it's seems reasonable to place IoT in a separate category, different from traditional SCADA.
Pertinent to IoT - is HTTP just another type of modulation technique, like e.g. wireless DSS?
No, there is a deep difference between HTTP used in IoT and other signal modulation techniques existing in data/signal communication. Pertinent to aforementioned DSS, also frequency hopping and other existing modulation technique, the communication model remains type of "peer-to-peer" with highly-predictable signal propagation path between two communication points; in use-cases envolving HTTP the packet delivery path is essentially unpredictable, and so are all its derivative metrics.
What body of knowledge/set of skills required for IoT development?
Serious IoT projects going beyond some trivial "Arduino driving LED" sort of Ilike those notoriously omnipresent Timer 555 hobby stuff of the 70s) require variety of IT, Software/Firmware development, Electrical Engineering and Electronic Design knowledge/skills, plus some working knowledge of Metrology (i.e. Instrumentation and Measurement) and, possibly, Control Engineering.
What type of IoT projects could we expect to be successful in the nearest future?
Mostly real-time monitoring and supervision apps in many non-critical areas, e.g. variety of hobby/educational projects (in particular, utilizing the huge potential of eLearning by connecting teachers-students online and allowing to perform some real-life scientific experiments), or something like monitoring water level in a fish tank, or vending machine inventory, or finding free parking spots in big Cities, or mass-transit vehicles tracking systems (like this app submission), and also in some semi-critical areas, like home security surveillance systems. Regarding non-realtime apps dealing with "historical" data - it could be variety of meteorological/environmental statistical apps, crowdsourcing data/signal aggegation apps (e.g. monitoring City noise levels and other factors affecting quality of life), and certain home automation apps provided that they adhere to applicable quality/safety standards.
What data feeds are openly available for IoT transportation apps?
Pertinent to particular mass-transit domain: vehicles and stops real-time monitoring (for e.g. bus routes-stops monitoring as described in this project article). More than 5000 MTA buses in the NYC [3-5] serving 316 routes are equipped with GPS system providing a real-time vehicle monitoring capability. Bus stops location can be obtained from a 'static' GTFS data feed, or in a realtime using SIRI/OBA data feeds [6-8].
Are IoT apps pertain just to Cloud technology domain?
No, IoT can be implemented practically on any web hosting servers, but cloud technology in general (an Microsoft Azure in particular) provides a convenient project integration tools, for example, easy publishing from development platform (like Visual Studio 2012/2013) to Azure web hosting servers.
What is the current state of IoT?
Currently IoT is in a very erly stage with all its success stories primarily inherited from existing "SCADA over Internet" use-cases. It's currently more of a semantic innovation sort of, an abstract term, which should be filled (as we expect) with a real content over time.
What IoT modeling tools exist?
Regarding the software development part, IoT is a good fit for existing Unified Modeling Language (UML) with a focus on Entity-relationship, State Machine and Activity diagram. Pertinent to a subject domain (i.e. sensors, actuators, and electronic circuitry in general) other computer modeling/simulation tools could be handy: for example digital filter design software (in the world of signals and noise it's not all about moving averages, but also much more sophisticated FIR/IIR filtering technique), circuit simulation software like SPICE, variety of circuit schematic capture/PCB layout software, etc.
What about IoT design patterns and "anti-patterns"?
IoT success stories pertinent to IoT remote monitoring (supervision) and data acquisition use-cases have been discussed in previous sub-chapters. There is a reasonable expectation that this particular application domain could flourish with IoT proliferation (this web app actually belongs to this application domain).
IoT anti-patterns: on the other side, it should be clearly stated that certain IoT automatic control apps (in particular, any closed-loop control systems) could easily fall into design "pattern of failure", or anti-paterns (even safety hazard) category. For example, pertinent to the home automation (i.e. "smart home"): there are already plenty of ridiculous IoT automatic control use-cases/projects artificially over-stretching the reasonable boundary of these type of apps beyond common sense and any practical merits. Highly ridiculuos is the very idea to integrate a web server (often located in some far-away land) and all associated Internet uncertainties into control system targeting your coffee-maker (microwave oven, toaster, etc) sitting just next to you. Almost all home control automation could be achieved with zero dependency on Internet (thus, excluding all its uncertainties/vulnarabilities) just by using local wired/wireless networks. Also, there is a decades-old idea of using power-line for signal transmission (it's actually implemented in many commercial apps), which seems to be even more practical than such IoT apps. In general, any reasonable home control automation app can be implemented in much more safe/reliable and cost-effective manner using aforementioned traditional local control loops (wired or wireless) rather than intrinsically unsafe/unreliable common IoT control app. Such artificially over-stretched IoT use-cases and respective apps could potentially create tremendous safety hazards, and frankly, its usage should be regulated on a legislative level.
Is IoT another techno-bubble?
Valid question: after dotcom crash every new "big thing" must pass a litmus test of utmost skepticism, i.e. "everything is bubble unless proven otherwise". Unfortunately, too often just a new "piece of jargon", buzzword or some semantic re-arrangement of existing taxonomy were perceived as significant techno-trend, so a healthy dose of scepricism is quite appropriate. Pertinent to IoT, there is a reason to be cautiously optimistic. The core underlying concepts of distributed SCADA are absolutely real and time tested. Certain success stories of "SCADA over Internet" have been written long before the term "IoT" was coined, so it reflects existing reality based on a solid engineering backround. But it's too early to make any predictions about the magnitude of IoT proliferation, it's technological significance and potential market perspectives as too many risk/rewards factors need to be thorough evaluated as discussed below.
IoT risk factors
Safety and Security concerns
So far, security and safety concerns outweigh all other IoT operational risks. Internet in its current state is rather vulnerable to malicious cyber-attacks with security/privacy breaches, info-leaks and financial fraud cases frequently decorating the news headlines worlwide. In addition to the “virtual digital damage”, IoT may cause direct physical, thus much more dangerous damages to the connected devices. Considering all currently existing cyber-security concerns, for the time being IoT shall not be used in any life-support or mission-critical system.
IoT operational reliability
Beyond safety and security factors, another set of concerns relates to IoT operational reliability. As a general rule, current IoT should not be used in any SCADA where precise timing or “data/signal transport delay” are somewhat critical for system operation. This design consideration is particular important for operational stability of any closed-loop control systems.
IoT quality control
IoT software must adhere to the same quality standards as applied to the hardware/firmware in embedded applications. Software developers moving from elusive virtual realities of traditional Internet into IoT "world of real realities" should clearly understand that any part of their software became a firmware with all related implications.
Disclaimer of Warranty and Limitation of Liability
Proposed solution does not implement any open/closed-loop control system of a physical devices on a recipient side. It outputs to the human-readable devices (i.e. computer monitor/display) and can be categorized as distributed real-time Data Acquisition sytem with some supervisory functions, and optional user feedback channels (crowdsourcing data aggregator).
THE SOFTWARE SOLUTION IS PROVIDED "AS-IS," "WITH ALL FAULTS," AND "AS AVAILABLE" AND END USER BEAR ALL RISK OF USING IT. THE AUTHOR/COMPANY GIVES NO EXPRESS WARRANTIES, GUARANTEES, OR CONDITIONS IN RELATION TO THIS SOFTWARE. IN NO EVENT SHALL AUTHOR/COMPANY BE HELD LIABLE FOR ANY ACTUAL OR IMPLIED, DIRECT OR INDIRECT, INCIDENTAL OR CONSEQUENTIAL, OR ANY OTHER DAMAGES ARISING OUT OF THE USE OF, OR INABILITY TO USE THIS SOFTWARE.
History
Feb 2015: Azure cloud services have been prototyped
Mar 2015: Sub-scaled Win app has been prototyped
Mar 2015: Draft version of the article has been published
List of Acronyms
| ACR | Acceleration Conformance Ratio |
| AJAX | Asynchronous JavaScript and XML |
| API | Application Programming Interface |
| CEN | European Committee for Standardization |
| CSV | Comma-Separated Values (data format) |
| GIS | Geographic Information System |
| DDCR | Dynametric Driving Comfort Ratio |
| DDRR | Dynametric Driving Risk Ratio |
| EDER | Ergometric Driving Efficiency Ratio |
| GTFS | General Transit Feed Specification |
| IoT | Internet of Things |
| JSON | Javascript Object Notation |
| LIRR | Long Island Rail Road |
| MNR | Metro-North Railroad |
| MTA | Metropolitan Transportation Authority (NY) |
| NSF | National Science Foundation (US) |
| NYCTA | New York City Transit Authority |
| OBA | One Bus Away (“Discovery" API) |
| POI | Point Of Interest |
| REST | Representational State Transfer |
| SBIR | Small Business Innovation Research |
| SCADA | Supervisory Control and Data Acquisition |
| SIRI | Service Interface for Real Time Information |
| SOAP | Simple Object Access Protocol |
| TCP/IP | Transmission Control Protocol/Internet Protocol |
| WPF | Windows Presentation Foundation |
| UML | Unified Modeling Language |
| XML | Extensible Markup Language |
| XAML | Extensible Application Markup Language |
References
- IoT
- Supervisory Control and Data Acquisition (SCADA)
- Transportation in New York City
- MTA NY
- MTA Regional Bus Operation (wiki)
- General Transit Feed Specification (GTFS)
- Service Interface for Real Time Information (SIRI)
- OneBusAway (OBA)
- Reduce references output of stops-for-route API (GitHub OBA #122)
- HeMoSiBi™ - Her Most Significant Bit (AIC-2013 FINALIST app)
- Ergometric Efficiency Profiler of Vehicles (proposal to NSF SBIR Phase I, 2014)
- Haversine Formula (wiki)
- Spherical law of cosines (wiki)
- Geographical distance (wiki)
- Azure: NYC real-time Bus tracking web app
