Perpetuum-M:适用于 Win7/8 的实时纽约公交追踪应用
适用于 Win 7/8 的纽约市 MTA 公交追踪应用,后端服务基于 Azure 云
引言
本文介绍了一个Microsoft Azure 物联网竞赛的参赛项目:“Perpetuum-M”Windows 应用程序(下称 WinApp),主要面向纽约市通勤者和相关的 MTA 部门。它允许在任何联网的移动或固定 PC 计算机硬件上,通过 Microsoft Windows 7/8 操作系统,实时追踪 316 条 MTA 公交线路 [2,3] 的运行情况。该解决方案由 Microsoft Azure 云技术提供支持,因此其核心实时运行需要互联网连接。
这款 WinApp 扩展了先前发布的 HeMoSiBi™ Windows 应用程序 [10] 的功能(本文附带该 WinApp 的试用版用于演示)。与之互补的 Web 应用“enRoute”[15] 提供了在任何联网平台(不限于 Windows 操作系统)的网页浏览器中运行的额外能力。
技术亮点
WinApp 能够持续实时监控 MTA 公交,并将结果输出到动态公交时刻表(列表)和公交地图数据可视化控件。它利用了实时公交数据源(GTFS、SIRI、OBA [5-7])的新能力以及 Microsoft Azure 云服务的技术支持。美观且直观的应用程序用户界面适应了各种外形的移动设备。该应用程序可归类为一种实时的分布式“基于互联网的 SCADA”(也称物联网)解决方案,主要侧重于监控(监督)和数据采集功能。
更广泛的影响
纽约市都会运输署 (Metropolitan Transportation Authority) 的日均客运量超过 1000 万人次 [2,3](几乎是挪威总人口的两倍)。通过为纽约市的大众交通通勤者提供实质性的技术协助,该解决方案解决了规模宏大的重要社会经济问题。核心的实时 MTA 公交监控解决方案还可以应用于其他交通工具,如纽约地铁、长岛铁路 (LIRR) 和纽约北线铁路 (MNR)。
受众
个人通勤者预计将构成一个主要且相当庞大的用户群体。纽约市政府部门和一些基础设施服务部门可能会利用该解决方案提供的能力。此外,总部位于纽约市的各类私营公司也可以使用该解决方案。
硬件平台/操作系统
这款物联网应用程序 [1] 适用于从智能手机到高性能台式计算机的任何 PC 平台,特别关注配备 Intel i3/i5/i7 CPU 的高端平板电脑/笔记本电脑。该应用扩展了先前开发的 HeMoSiBi™ 应用 [10] 的原始功能,后者本质上是“静态”的,利用其内部存储的纽约地铁数据。与前代产品不同,该应用利用了 [6-9] 中所述的各种实时纽约 MTA 公交数据服务(数据源)。其 Azure 后端服务与互补的实时公交追踪 Web 应用程序 [15] 使用的服务非常相似,充分利用了在该 Web 应用背景下开发的 Azure 云服务的可重用代码库。
开发方法和工具
该解决方案是使用 Microsoft 核心技术集开发的:.NET4.5/C#、SQL Server、WPF/XAML、Azure 云服务以及纽约市 MTA 面向开发者的 API 提供的实时数据源(需要有效的 API 访问密钥 [6-9])。该应用程序的目标框架设置为 .NET Framework 4 客户端配置文件。
背景
物联网(IoT)[1] 被认为是一个相对较新的技术趋势,尽管其许多核心概念已经存在了几十年。它与现有的 SCADA 系统 [2] 表现出明显的相似性,特别是遥测系统、无线传感器网络、分布式控制和自动化系统。核心区别在于物联网使用的分组交换通信协议(TCP/IP),而不是传统 SCADA 系统典型的电路/信道交换技术。
系统架构
系统架构图由客户端机器上运行的 Windows 应用程序以及应用程序所使用的所有相关 Azure 云功能组成。它遵循编程概念分离的基本原则,即数据层、商业智能 (BI) 和用户界面 (GUI) 的逻辑(可选物理)分离。简化的架构图如下所示。
图 1a. 所提出的“Azure 物联网”解决方案的通用架构图(涵盖 Web/Win 应用)
图 1b. 此 Windows/PC 应用程序的扩展版本的系统架构(开发中)
原型
该解决方案已使用缩减比例的模拟公交路线/站点数据集进行了部分原型开发,主要目的是测试基于 `ObservableCollection` .NET 数据对象(在以下子章节中描述)的流畅异步实时操作的概念。示例演示截图如下。
图 2. 缩减比例原型:测试实时异步操作(演示截图)
这款物联网 Windows 应用将利用先前开发的 HeMoSiBi™ 应用 [10] 的许多可重用组件(该应用的试用版已附于本项目用于演示——请参见下方的示例截图)。
图 3. 所提出的解决方案将利用先前开发的 HeMoSiBi™ 应用的代码库/布局
MTA 数据源
实时纽约公交追踪需要根据 [6-9] 中详述的,向相应的 SIRI 和 OBA 端点发送几种类型的 Web 查询请求。响应数据流可以格式化为 JSON 或 XML 文档。该解决方案实现了一个专有解析器,使用 .NET/C# 将在线数据流反序列化为相应的软件对象。
GTFS
通用交通源规范(GTFS,最初称为:Google Transit Feed Specification)为公共交通时刻表和相关地理信息定义了一种通用格式 [6]。GTFS 源是一个包含 CSV 文件(主要列表如下)的集合,封装在一个 ZIP 文件中。
- agency.txt
- routes.txt
- trips.txt
- stop_times.txt
- stops.txt
- calendar.txt
专门的程序执行从 GTFS 静态源到应用程序数据库(SQL Server)的数据导入,其中最重要的表包含机构、路线和站点记录。
OBA
开源 OneBusAway (OBA) API 允许“发现”MTA 所覆盖的公交服务的静态/基线信息 [7]。
SIRI
实时信息服务接口 (SIRI) 是一种 XML 协议,允许分布式计算机交换有关公共交通服务和车辆的实时信息 [8]。针对应用程序任务,使用了两个实时数据源:VehicleMonitoring 和 StopMonitoring。
解析器
解析器模块反序列化 OBA/SIRI 的“站点-路线-机构”数据流(XML 编码),并将其转换为 Win/Web 应用程序 [9] 使用的相应软件对象。值得一提的是,机构和站点数据也可以从“静态”GTFS 数据源获取并如上所述存储在应用程序数据库中,从而减少了实时更新周期中的一项数据请求。最终数据集包含站点静态数据以及叠加的实时公交位置数据。
Web API
配备 GPS 传感器的 MTA 公交通过 OBA/SIRI 数据源 [6,7] 提供实时车辆位置信息。除了 OBA/SIRI 提供的下行数据流外,额外的上行功能,即众包实时数据通道,将增强解决方案的数据能力。计划提供两组主要的 Web API:
- 实时公交路线/车辆位置数据源(下行)
- 实现用于收集“众包”数据的反馈通道(上行)
反馈通道
目前正在考虑的几个上行数据源提供以下指标:公交载客量和站点等候人数。此外,还可以向上传数据通道添加一组反映能源效率、通勤安全性和舒适度的独特专有指标 [11]。
现代“Wintel”PC 的物联网技术支撑向量
解决方案的上述“上行”(反馈)部分可以利用现代“Intel Inside”PC 平台各种技术支撑向量,特别是集成传感器:GPS、加速度计、位置和方向传感器(可选——电子罗盘)。WinApp 实现了利用双向数据流的附加功能:下行提供车辆/站点位置,上行将“众包”数据集发送回服务器。此类上行数据反馈可能包括基于嵌入式传感器读数(PC 平板电脑/超极本)和作者 [10] 开发的专有算法的多个标量指标:人体工程学驾驶效率比 (EDER)、加速一致性比 (ACR)、动态驾驶舒适度比 (DDCR)、动态驾驶风险比 (DDRR)。
地理空间搜索引擎
当前的 Web 应用程序利用 Microsoft Bing 地图技术的内在地理空间搜索功能,允许用户查找公交路线附近(或地图上用户选择的任何区域)的兴趣点。未来的开发可能包括 Azure 搜索服务来增强此功能。
使用代码
实时数据源中编码的典型公交路线和公交站点 XML 数据结构如下(见列表 1、2)。
列表 1. 纽约 MTA 公交路线元素,XML 编码
<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>
列表 2. 纽约 MTA 公交站点元素,XML 编码
<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>
注意:作者最近在 OBA GitHub [8] 上提出一个问题单,请求减少站点 API 的响应文档大小。
在核心应用功能方面,列表 2 中 XML 节点的 most important 数据项是:站点 ID、坐标(纬度/经度)、名称和方向。站点集合可以在地图上显示(特别是使用 Bing 技术,如在“HeMoSiBi”应用程序 [9] 中所做的那样),也可以以纯文本格式显示为数据列表,并叠加实时获取的公交位置(实际上是“伪”实时,因为固有的互联网协议不确定性和延迟不允许精确计时:总的来说,对于此类应用程序,响应/处理时间在 1-3 秒内是可行且合理的)。应用程序计时器以预设的间隔(例如 10 秒,这对于此类应用程序是合理的)不断更新选定车辆(公交车)相对于站点的位置。应用程序还允许用户强制立即更新数据(“刷新”按钮)。
GIS 功能
计算地球表面两个地理点之间的距离是核心 GIS 功能之一。存在多种算法(见列表 3),它们的性能/精度各不相同 [12-14]。
列表 3. 计算地球表面两地理点之间距离的基本 GIS 函数
/*****************************************************************************************
Module : GIS.cs |Class Lib
Description : Calculate distance between two geo-points on surface
*****************************************************************************************
Author : Alexander Bell
Copyright : 2011-2015 Infosoft International Inc
*****************************************************************************************
DISCLAIMER : This Module is provided on AS IS basis without any warranty
*****************************************************************************************
TERMS OF USE : This module is copyrighted. Please keep the Copyright notice intact.
*****************************************************************************************/
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
/// <summary>
/// Distance between two geographic points on surface, km/miles
/// Haversine formula to calculate
/// great-circle (orthodromic) distance on Earth
/// High Accuracy, Medium speed
/// re: http://en.wikipedia.org/wiki/Haversine_formula
/// </summary>
/// <param name="Lat1">double: 1st point Latitude</param>
/// <param name="Lon1">double: 1st point Longitude</param>
/// <param name="Lat2">double: 2nd point Latitude</param>
/// <param name="Lon2">double: 2nd point Longitude</param>
/// <returns>double: distance, km/miles</returns>
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;
// intermediate result
double _a = Math.Sin(_dLatHalf);
_a *= _a;
// intermediate result
double _b = Math.Sin(_dLonHalf);
_b *= _b * Math.Cos(_radLat1) * Math.Cos(_radLat2);
// central angle, aka arc segment angular distance
double _centralAngle = 2 * Math.Atan2(Math.Sqrt(_a + _b), Math.Sqrt(1 - _a - _b));
// great-circle (orthodromic) distance on Earth between 2 points
if (UnitSys == UnitSystem.SI) { return _radiusEarthKM * _centralAngle; }
else { return _radiusEarthMiles * _centralAngle; }
}
catch { throw; }
}
#endregion
#region Method 2: Spherical Law of Cosines
/// <summary>
/// Distance between two geographic points on surface, km/miles
/// Spherical Law of Cosines formula to calculate
/// great-circle (orthodromic) distance on Earth;
/// High Accuracy, Medium speed
/// re: http://en.wikipedia.org/wiki/Spherical_law_of_cosines
/// </summary>
/// <param name="Lat1">double: 1st point Latitude</param>
/// <param name="Lon1">double: 1st point Longitude</param>
/// <param name="Lat2">double: 2nd point Latitude</param>
/// <param name="Lon2">double: 2nd point Longitude</param>
/// <returns>double: distance, km/miles</returns>
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;
// central angle, aka arc segment angular distance
double _centralAngle = Math.Acos(Math.Sin(_radLat1) * Math.Sin(_radLat2) +
Math.Cos(_radLat1) * Math.Cos(_radLat2) * Math.Cos(_radLon2 - _radLon1));
// great-circle (orthodromic) distance on Earth between 2 points
if (UnitSys == UnitSystem.SI) { return _radiusEarthKM * _centralAngle; }
else { return _radiusEarthMiles * _centralAngle; }
}
catch { throw; }
}
#endregion
#region Method 3: Spherical Earth projection
/// <summary>
/// Distance between two geographic points on surface, km/miles
/// Spherical Earth projection to a plane formula (using Pythagorean Theorem)
/// to calculate great-circle (orthodromic) distance on Earth.
/// central angle =
/// Sqrt((_radLat2 - _radLat1)^2 + (Cos((_radLat1 + _radLat2)/2) * (Lon2 - Lon1))^2)
/// Medium Accuracy, Fast,
/// relative error less than 0.1% in search area smaller than 250 miles
/// re: http://en.wikipedia.org/wiki/Geographical_distance
/// </summary>
/// <param name="Lat1">double: 1st point Latitude</param>
/// <param name="Lon1">double: 1st point Longitude</param>
/// <param name="Lat2">double: 2nd point Latitude</param>
/// <param name="Lon2">double: 2nd point Longitude</param>
/// <returns>double: distance, km/miles</returns>
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);
// central angle, aka arc segment angular distance
double _centralAngle = Math.Sqrt(_a * _a + _dLat * _dLat);
// great-circle (orthodromic) distance on Earth between 2 points
if (UnitSys == UnitSystem.SI) { return _radiusEarthKM * _centralAngle; }
else { return _radiusEarthMiles * _centralAngle; }
}
catch { throw; }
}
#endregion
}
}
从数学上讲,所有三种算法都计算地球上两点之间的“大圆”(正交线)距离,尽管精度和性能不同。在当前应用程序的上下文中,它们在纽约市边界内通常提供合理的近似值,误差不超过几米。上述三种算法均基于球形地球模型。存在更精确的椭球模型(例如 Vincenty 解决方案),可将误差减小到毫米级别(这种精度对于当前应用程序显然是“过度”的),但计算复杂度也大大增加。因此,选择了方法 3(球面地球投影),它在精度合理的情况下提供了最高的计算性能。
关注点
实时应用中的 ObservableCollection
该应用程序使用其 UI/XAML 可视化元素绑定到 `ObservableCollection` 对象,该对象不断用从实时 SIRI/OBA 数据源拉取的数据进行更新。`ObservableCollection` 在处理 SQL 添加/删除操作时效果很好,而更新情况需要一些额外的编码,即:在 `ObservableCollection
列表 4. `ObservableCollection
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>();
物联网简介
什么是物联网?
物联网是构建在互联网相关分组交换协议(最著名的是 TCP/IP 和 HTTP)之上的分布式 SCADA(即监控与数据采集)。
物联网与传统互联网有何不同?
如上所述,物联网为主要被视为“人联网”的传统互联网增加了更多 SCADA 功能。物联网应被视为对传统互联网的扩展,尽管许多与分布式 SCADA 系统相关的用例在“物联网”一词出现之前就已经存在。重要区别还在于,在传统互联网中,数据/信号的接收方主要是人类,而物联网有望增加更多与直接机器对机器交互相关的用例。
物联网与传统 SCADA 有何不同?
数据/信号传输机制是重要的分类标准。分组交换网络和电路交换网络之间的区别比语义更深层:类比来说,看看有线和无线网络之间的区别,它们之间的差异如此之大,以至于在网络分类法中被视为两个不同的子类别。从设计/分析的角度来看,将物联网置于不同于传统 SCADA 的单独类别是合理的。
对于物联网,HTTP 是否只是另一种调制技术,就像例如无线 DSS?
不,物联网中使用的 HTTP 与数据/信号通信中存在的其他信号调制技术之间存在深刻的差异。与上述 DSS、跳频和其他现有调制技术相关联的通信模型仍然是“点对点”类型,通信点之间的信号传播路径高度可预测;在涉及 HTTP 的用例中,数据包的传递路径本质上是不可预测的,其所有派生指标也是如此。
物联网开发需要哪些知识体系/技能?
严肃的物联网项目,除了那些臭名昭著的无处不在的 70 年代定时器 555 爱好项目之外,还需要各种 IT、软件/固件开发、电气工程和电子设计知识/技能,以及一些计量学(即仪器仪表和测量)和可能的控制工程的工作知识。
在不久的将来,我们可以期待哪些类型的物联网项目会取得成功?
主要是各种非关键领域的实时监控和监督应用,例如各种爱好/教育项目(特别是利用在线连接教师-学生和允许进行一些真实科学实验的电子学习的巨大潜力),或者监测鱼缸水位、自动售货机库存,或在大城市中寻找免费停车位,或大众交通工具跟踪系统(如本次应用提交),以及在一些半关键领域,如家庭安全监控系统。对于处理“历史”数据的非实时应用程序,可以是各种气象/环境统计应用程序、众包数据/信号聚合应用程序(例如,监测影响生活质量的城市噪音水平和其他因素),以及某些家庭自动化应用程序,前提是它们符合适用的质量/安全标准。
有哪些开放的物联网交通应用数据源?
在具体的大众交通领域:车辆和站点实时监控(例如,本项目文章中描述的公交路线-站点监控)。纽约市的 5000 多辆 MTA 公交车 [3-5] 服务于 316 条路线,配备 GPS 系统,可提供实时车辆监控能力。公交站点位置可以从“静态”GTFS 数据源获取,或者使用 SIRI/OBA 数据源 [6-8] 实时获取。
物联网应用是否仅属于云技术领域?
不,物联网几乎可以在任何 Web 托管服务器上实现,但云技术(尤其是 Microsoft Azure)通常提供方便的项目集成工具,例如,从开发平台(如 Visual Studio 2012/2013)轻松发布到 Azure Web 托管服务器。
物联网的现状如何?
目前物联网处于非常早期的阶段,其所有成功案例主要继承自现有的“互联网 SCADA”用例。目前更多的是一种语义创新,一个抽象的术语,我们预期它会随着时间的推移被充实以真实内容。
有哪些物联网建模工具?
关于软件开发部分,物联网非常适合现有的统一建模语言 (UML),侧重于实体关系图、状态机图和活动图。针对特定领域(即传感器、执行器和通用电子电路),其他计算机建模/仿真工具可能很有用:例如数字滤波器设计软件(在信号和噪声的世界中,不只是移动平均,还有更复杂的 FIR/IIR 滤波技术)、电路仿真软件如 SPICE、各种电路原理图捕获/PCB 布局软件等。
物联网设计模式和“反模式”怎么样?
物联网成功案例:前面几章讨论了与物联网远程监控(监督)和数据采集用例相关的物联网成功案例。可以合理地预期,这个特定的应用程序领域将随着物联网的普及而蓬勃发展(这款 Web 应用实际上属于这个应用领域)。
物联网反模式:另一方面,应该明确指出,某些物联网自动控制应用(特别是任何闭环控制系统)很容易陷入设计“失败模式”或反模式(甚至存在安全隐患)类别。例如,关于家庭自动化(即“智能家居”):已经有很多荒谬的物联网自动控制用例/项目,人为地将这类应用的合理界限过度扩展,超出了常识和任何实际价值。将一个 Web 服务器(通常位于遥远的地方)及其所有相关的互联网不确定性集成到一个针对您旁边咖啡机(微波炉、烤面包机等)的控制系统中,这个想法本身就非常荒谬。几乎所有的家庭控制自动化都可以通过零互联网依赖(从而排除其所有不确定性/漏洞)仅通过使用本地有线/无线网络来实现。此外,几十年来一直存在使用电力线进行信号传输的想法(它实际上已在许多商业应用中实现),这似乎比这种物联网应用更实际。总的来说,任何合理的家庭控制自动化应用都可以通过上述传统的本地控制回路(有线或无线)以更安全/可靠和更具成本效益的方式实现,而不是使用固有不安全/不可靠的通用物联网控制应用。此类人为过度扩展的物联网用例及其相应应用程序可能会造成巨大的安全隐患,坦率地说,其使用应受到立法层面的监管。
物联网是又一个技术泡沫吗?
有效的问题:在互联网泡沫破灭后,每一个新的“大事”都必须经受最大的怀疑的考验,即“除非证明是如此,否则一切都是泡沫”。不幸的是,太多时候,仅仅一个新的“行话”、流行语或现有分类法的某种语义重排就被视为重要的技术趋势,因此健康的怀疑态度是相当合适的。对于物联网,有理由谨慎乐观。分布式 SCADA 的核心基础概念是真实且经过时间检验的。在“物联网”一词出现之前,就已经写下了“互联网 SCADA”的一些成功案例,因此它反映了基于扎实工程背景的现实。但是,现在断言物联网普及的程度、其技术重要性以及潜在的市场前景还为时过早,因为需要全面评估许多风险/回报因素,如下所述。
物联网风险因素
安全和保障方面的担忧
到目前为止,安全和保障方面的担忧远远超过了其他物联网运营风险。目前互联网很容易受到恶意网络攻击,全球新闻头条经常充斥着安全/隐私泄露、信息泄露和金融欺诈案件。除了“虚拟数字损害”外,物联网还可能对连接的设备造成直接的、因此更危险的物理损害。考虑到所有现有的网络安全问题,目前物联网不应在任何生命支持或任务关键型系统中使用。
物联网运行可靠性
除了安全和保障因素外,另一组担忧与物联网运行可靠性有关。总的来说,目前的物联网不应用于任何 SCADA,其中精确计时或“数据/信号传输延迟”对系统运行至关重要。这一设计考虑对于任何闭环控制系统的运行稳定性尤其重要。
物联网质量控制
物联网软件必须遵守与嵌入式应用程序中的硬件/固件相同的质量标准。从传统互联网的模糊虚拟现实转向“真实世界”物联网的软件开发人员应清楚地认识到,其软件的任何部分都将成为固件,并具有所有相关含义。
免责声明和责任限制
拟议的解决方案不实现接收方对物理设备的任何开/闭环控制系统。它输出到人类可读的设备(即计算机显示器/屏幕),并可归类为具有一些监督功能的分布式实时数据采集系统,以及可选的用户反馈通道(众包数据聚合器)。
该软件解决方案按“原样”提供,“附带所有故障”和“可用时”提供,并且最终用户承担使用它的所有风险。作者/公司不提供与本软件相关的任何明示或暗示的保证、担保或条件。在任何情况下,作者/公司均不对因使用或无法使用本软件而引起的任何实际或隐含的、直接或间接的、偶然的或附带的、或其他损害负责。
历史
2015 年 2 月:Azure 云服务已进行原型开发
2015 年 3 月:缩减比例的 Win 应用已进行原型开发
2015 年 3 月:文章草稿已发布
缩略语列表
ACR | 加速一致性比 |
AJAX | Asynchronous JavaScript and XML |
API | Application Programming Interface |
CEN | 欧洲标准化委员会 |
CSV | Comma-Separated Values (数据格式) |
GIS | Geographic Information System |
DDCR | 动态驾驶舒适度比 |
DDRR | 动态驾驶风险比 |
EDER | 人体工程学驾驶效率比 |
GTFS | General Transit Feed Specification |
IoT | 物联网 |
JSON | Javascript Object Notation |
LIRR | 长岛铁路 |
MNR | 纽约市都会运输署 |
MTA | Metropolitan Transportation Authority (NY) |
NSF | 美国国家科学基金会 |
NYCTA | 纽约市交通局 |
OBA | One Bus Away (“Discovery" API) |
POI | Point Of Interest |
REST | Representational State Transfer |
SBIR | 小型企业创新研究 |
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 |
参考文献
- 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)
- 减少站点-路线 API 的引用输出 (GitHub OBA #122)
- HeMoSiBi™ - Her Most Significant Bit (AIC-2013 FINALIST 应用)
- Ergometric Efficiency Profiler of Vehicles (向 NSF SBIR 第一阶段提交的提案,2014 年)
- Haversine Formula (wiki)
- Spherical law of cosines (wiki)
- Geographical distance (wiki)
- Azure:纽约市实时公交追踪 Web 应用