国家运输ITS通信协议（NTCIP）简介
国家智能交通系统工程技术研究中心 张北海 中交国通智能交通系统技术有限公司 肖媛媛
1. NTCIP的发展历程
NTCIP(National Transportation Communications for ITS Protocol)是美国针对智能运输系统(ITS)的电子设备间数据传输所制定的标准通讯协议，其主要目标是确保交通控制与ITS系统组成单元彼此之间的“互操作性”(Interoperability)与“互换性”(Interchangeability)，简言之，NTCIP有望能成为运输工业未来的Internet。所谓“互操作性”，是指在NTCIP通讯网络内不同种类的系统装置之间可以相互引用对方提供的服务，这些系统装置可以是安装在相同通讯链路的不同种类交通控制终端设施，或是不同控制中心之间的远程系统在线信息交换。所谓“互换性”，是指软硬件设备具有多个供货商，系统不会受限于供货商而导致软硬件设备置换时与系统联机的困难。
交通信号控制系统可说是ITS的先驱，而交通信号控制器，亦即信号机，则是该系统中最主要的设备，NTCIP的构想就是源自于交通信号控制器的应用需求。1992年美国国家电器制造商协会NEMA（National Electrical Manufacturers Association）开始讨论与开发共通性的交通信号控制系统通讯协议。1995年5月，在美国联邦公路局FHWA(Federal Highway Administration)主导下，由各界代表组成了NTCIP指导小组（NTCIP Steering Group）以加速ITS标准化工作。1995年12月，NEMA完成第一版NTCIP通讯协议，但仅限于低传输速率的交通信号控制器使用。1996年12月，FHWA提供五百万美金的经费开始制定NTCIP标准，并选择了交通工程师学会ITE(Institute of Transportation Engineers)、美国州公路及运输官员协会AASHTO(American Association of State Highway and Transportation Officials)与NEMA代表FHWA执行相关工作。ITE、AASHTO与NEMA共同组成的NTCIP联合委员会（Joint Committee on the NTCIP）也取代了NTCIP指导小组，成为目前美国NTCIP推动工作的正式官方组织，主要执行的工作包含：
1. 规划NTCIP未来的发展计划。
2. 成立工作小组(Working Group，WG)制定通讯协议标准。
3. 建议FHWA相关研究经费运用方式。
4. 开发标准通讯协议测试工具(例如NTCIP Exerciser)。
5. 协调美国其它标准化相关工作，例如DOT主导的ITS系统架构标准化。
6. 通过报告、期刊与网站(www.ntcip.org)等方式推广NTCIP之技术与应用。
NTCIP目前负责标准发展的工作小组有15个，包含Actuated Signal Control (ASC)、Base Standards and Protocols (BSP)、Center-to-center Profiles (C2C)、Closed Circuit TV (CCTV)、Data Collection and Monitoring (DCM)、Dynamic Message Sign (DMS)、Environmental Sensor Station (ESS)、Global Objects (GO)、Joint Committee on the NTCIP (STRGRP)、Profiles、Ramp Metering (RM)、Signal Control and Prioritization (SCP)、Transportation Sensor Systems (TSS)、Technical Coordination Forum (TCF)等，所发展的NTCIP标准适用以下领域：
Actuated Signal Control Messages (ASC)。
Highway Advisory Radio Messages (HAR)。
Dynamic Message Sign Messages (DMS)。
Center to Center Profiles (CTC)。
Communications Profiles (CP)。
Environmental Sensor Station (ESS)。
Ramp Meter Messages (RM)。
DSRC Coordination (DSRC)。
Video Camera Control Messages (VCS)。
Advanced Sensor Messages (AS)。
Transportation Sensor Systems (TSS)。
Transit TCIP (TCIP)。
NTCIP是美国ITS标准化工作的其中一环，其架构仿效Internet的做法，由AASHTO、ITE及NEMA作为NTCIP标准主要的发展机构NTCIP标准开发组织（NTCIP Standards Development Organizations，SDOs），三个机构则各派代表共同组成联合委员会，以合作推动NTCIP标准化工作。整个NTCIP组织架构如图1所示。
图1 NTCIP组织架构
NTCIP标准制定程序包含以下步骤：
1. 由联合委员会成员提出标准化工作主题。
2. 联合委员会投票表决是否针对该主题成立工作组(Working Group, WG)。
3. 联合委员会组织相关专业成员成立该工作组。
4. 工作组准备“工作组草案（Working Group Draft）”，并在网站上公告征求意见。
5. 工作组修正草稿后制作“用户评注草案（User Comment Draft）”，提送至联合委员会审核。
6. 联合委员会投票表决是否公布“用户评注草案”。
7. 联合委员会公布用户评注草案，并由SDOs审核文件。
8. 工作组依照SDOs意见修正“用户评注草案”。
9. 工作组决定是否提送新版的“用户评注草案”回到步骤6，或进行下一步骤。
10. 工作组制作“推荐标准草案（Draft Recommended Standard）”。
11. 联合委员会审核“推荐标准草案”，投票表决是否将文件提升为“推荐标准（Recommended Standard）”阶段，并交付SDOs审核。
联合委员会将“推荐标准”交付SDOs。
12. SDOs依照各自机构标准程序审核，投票通过NTCIP标准，并出版发行该文件。
13. SDOs鼓励机构成员实施NTCIP标准并负责后续维护工作。
14. NTCIP目前各项标准化工作之执行状况，汇总如表1所示。
表1 NTCIP标准发展现况
| NTCIP | Old Number | Type | Title | Approval Status |
| 1101 | TS3.2-1996 | Base Standard | NTCIP Simple Transportation Management Framework (STMF) | Jointly Approved; Amended |
| 1101A1 | none | Amendment | NTCIP STMF Amendment 1 | Jointly Approved |
| 1102 | OER | Base Standard | NTCIP Octet Encoding Rules (OER) | Recommended Standard |
| 1103 | STMP | Base Standard | NTCIP Transportation Management Protocol (TMP) | User Comment Draft |
| 1104 | none | Base Standard | NTCIP CORBA Naming Convention Specification | User Comment Draft |
| 1105 | none | Base Standard | NTCIP CORBA Security Service Specification | User Comment Draft |
| 1106 | none | Base Standard | NTCIP CORBA Near Real-Time Data Service Specification | Work Item, Approved |
| 1201 | TS3.4-1996 | Device Data Dictionary | NTCIP Global Object (GO) Definitions | Jointly Approved; Amended |
| 1201A1 | none | Amendment | NTCIP GO Definitions Amendment 1 | Jointly Approved |
| 1202 | TS3.5-1996 | Device Data Dictionary | NTCIP Object Definitions for ASC | Jointly Approved |
| 1202A1 | none | Amendment | NTCIP Objects for ASC Amendment 1 | User Comment Draft |
| 1203 | TS3.6-1997 | Device Data Dictionary | NTCIP Object Definitions for Dynamic Message Signs (DMS) | Jointly Approved |
| 1203A1 | none | Amendment | NTCIP Objects for DMS Amendment 1 | Recommended Amendment |
| 1204 | TS3.7-1998 | Device Data Dictionary | NTCIP Object Definitions for Environmental Sensor Stations (ESS) | Jointly Approved |
| 1204A1 | none | Amendment | NTCIP Objects for Envirnomental Sensor Stations (ESS) Amendment 1 | Jointly Approved |
| 1205 | TS3.CCTV | Device Data Dictionary | NTCIP Objects for CCTV Camera Control | Jointly Approved |
| 1206 | TS3.DCM | Device Data Dictionary | NTCIP Object Definitions for Data Collection | User Comment Draft |
| 1207 | TS3.RMC | Device Data Dictionary | NTCIP Object Definitions for Ramp Meter Control (RMC) | Jointly Approved |
| 1208 | TS3.SWITCH | Device Data Dictionary | NTCIP Object Definitions for Video Switches | User Comment Draft |
| 1209 | TS3.TSS | Device Data Dictionary | NTCIP Object Definitions for Transportation Sensor Systems (TSS) | User Comment Draft |
| 1210 | none | Device Data Dictionary | NTCIP Objects for Signal System Masters | User Comment Draft |
| 1211 | none | Device Data Dictionary | NTCIP Objects for SCP | User Comment Draft |
| 1212 | none | Device Data Dictionary | NTCIP Objects for Network Camera Operation | Working Group Draft |
| 1213 | none | Device Data Dictionary | NTCIP Objects for ELMS | Working Group Draft |
| 1301 | none | Message Set | Weather Report Message Set for ESS | Work Item, Approved |
| 1400 | TCIP-FRAME | Process, Control & Info Mgmt Policy | TCIP Framework Standard | Jointly Approved |
| 1401 | TCIP-CPT | Device Data Dictionary | TCIP Common Public Transportation (CPT) Objects | Jointly Approved |
| 1402 | TCIP-IM | Device Data Dictionary | TCIP Incident Management (IM) Bus. Area Std. | Jointly Approved |
| 1403 | TCIP-PI | Device Data Dictionary | TCIP Passenger Information (PI) Bus. Area Std. | Jointly Approved |
| 1404 | TCIP-SCH | Device Data Dictionary | TCIP Scheduling/Runcutting (SCH) Bus. Area Std. | Jointly Approved |
| 1405 | TCIP-SP | Device Data Dictionary | TCIP Spatial Representation (SP) Bus. Area Std. | Jointly Approved |
| 1406 | TCIP-OB | Device Data Dictionary | TCIP On-Board (OB) Objects | Jointly Approved |
| 1407 | TCIP-CC | Device Data Dictionary | TCIP Control Center (CC) Objects | Jointly Approved |
| 1408 | TCIP-FC | Device Data Dictionary | TCIP Fare Collection (FC) Objects | Jointly Approved |
| 1601 | none | Interface Definition | CORBA Base Object Model for TMS | User Comment Draft |
| 1602 | none | Interface Definition | Generic Reference Model (GRM) for Traffic Management | Working Group Draft |
| 1603 | none | Interface Definition | CORBA-Specific Reference Model (CSRM) for Traffic Management | Working Group Draft |
| 2001 | TS3.3-1996 | Comm. Class Profile | NTCIP Class B Profile | Jointly Approved; Amended |
| 2001A1 | none | Amendment | NTCIP Class B Profile Amendment 1 | Recommended Amendment |
| 2002 | CP-CLA | Comm. Class Profile | NTCIP Class A & Class C Profiles | Withdrawn |
| 2101 | SP-PMPP/RS232 | Subnetwork Profile | NTCIP SP-PMPP/RS232 | Jointly Approved |
| 2102 | SP-PMPP/FSK | Subnetwork Profile | NTCIP SP-PMPP/FSK | Recommended Standard |
| 2103 | SP-PPP/RS232 | Subnetwork Profile | NTCIP SP-PPP/RS232 | Recommended Standard |
| 2104 | SP-Ethernet | Subnetwork Profile | NTCIP SP-Ethernet | Recommended Standard |
| 2201 | TP-Null | Transport Profile | NTCIP TP-Transportation Transport Profile | Recommended Standard |
| 2202 | TP-INTERNET | Transport Profile | NTCIP TP-Internet (TCP/IP and UDP/IP) | Jointly Approved |
| 2301 | AP-STMF | Application Profile | NTCIP AP-STMF | Jointly Approved |
| 2302 | AP-TFTP | Application Profile | NTCIP AP-TFTP | Jointly Approved |
| 2303 | AP-FTP | Application Profile | NTCIP AP-FTP | Jointly Approved |
| 2304 | TS3.AP-DATEX | Application Profile | NTCIP AP-DATEX-ASN | Recommended Standard |
| 2305 | TS3.AP-CORBA | Application Profile | NTCIP AP-CORBA | User Comment Draft |
| 2500 | InP-C2C | Center Information Profile | NTCIP InP-C2C | Withdrawn |
| 2501 | InP-DATEX | Center Information Profile | NTCIP InP-DATEX | Work Item, Approved |
| 2502 | InP-CORBA | Center Information Profile | NTCIP InP-CORBA | Work Item, Approved |
| 7001 | NAN-1 | Registry | NTCIP Assigned Numbers (NAN) - Part 1 | Working Group Draft |
| 7002 | NAN-2 | Registry | NTCIP Assigned Numbers (NAN) - Part 2 | Working Group Draft |
| 8001 | White Paper | Process, Control & Info Mgmt Policy | NTCIP Standards Development Process | Working Group Draft |
| 8002 | none | Process, Control & Info Mgmt Policy | NTCIP Standards Publications Format | Editorial Committee Draft |
| 8003 | TS3.PRO | Process, Control & Info Mgmt Policy | NTCIP Profile Framework | Jointly Approved |
| 8004 | SMI | Process, Control & Info Mgmt Policy | NTCIP Structure and Ident. Of Mgmt. & Info. (SMI) | Working Group Draft |
| 8005 | none | Process, Control & Info Mgmt Policy | FOP for Using the NTCIP FADD and the IEEE ITS DR | User Comment Draft |
| 8006 | none | Process, Control & Info Mgmt Policy | NTCIP Administrative Policy and Procedure | Coordinators Draft |
| 9001 | Guide | Information Report | NTCIP Guide | Recommended Information Report |
| 9002 | none | Information Report | NTCIP VDOT Case Study on VMS | Recommended Information Report |
| 9003 | none | Information Report | NTCIP WashDOT Case Study on VMS | Recommended Information Report |
| 9004 | none | Information Report | NTCIP Phoenix Case Study on Signal Control | Recommended Information Report |
| 9005 | none | Information Report | Texas DOT Statewide NTCIP Integration | Project Draft |
| 9006 | none | Information Report | City of Lakewood Colorado NTCIP Signal System | Project Draft |
| 9007 | none | Information Report | City of Mesa Arizona NTCIP Signal System | Project Draft |
| 9008 | none | Information Report | Minnesota DOT NTCIP ESS | Project Draft |
| 9009 | none | Information Report | Washington State DOT NTCIP ESS | Project Draft |
（注：资料来源www.ntcip.org，截至2003年10月8日）
2. NTCIP的效益
NTCIP为运营运输管理系统的机构或部门提供了更多的机动性和选择。藉由统一的标准，NTCIP扫除了不同部门在协调上的障碍，并允许同一通讯线路上存在不同的设备种类和制造商生产的产品。即使原有的整套系统并没有采用NTCIP，但如果各运营部门在采购新设备时能够考虑采用兼容NTCIP的产品，依然能通过NTCIP在未来的采购及升级中获得益处。NTCIP主要的效益如下：
2.1 避免设备过早淘汰
NTCIP不可能针对早期的设备来订定标准，但是有了统一的标准，大多数的供货商都会在当前或者是未来的商品中提供对NTCIP的支持。尽管可能不在同一个通信线路中，运转一个混杂着NTCIP设备及非NTCIP的设备（或是这些设备虽支持NTCIP，但仍使用既有的通讯协议）的系统仍然是可能的。只要运营部门在采购设备时选择NTCIP兼容的产品，就能够确保设备保持长期的可用性和兼容性，避免设备的过早淘汰，延长设备的使用期限。这些设备包括计算机软件、外场设备、任何类型的交通或运输控制或监测设备的控制器。
2.2 提供更多的生产商供选择
若使用单位决定其系统采用NTCIP架构，就可以向不同的供货商购买NTCIP兼容之产品、现场设备、软件等。也许只有同一供货商之产品才能够充分运用其产品的功能，但至少在同一标准下，任何供货商都可以提供基本功能，交通单位选择厂商的机会将更多样化，也可避免单一供货商的垄断。
当一个运营部门采用了支持NTCIP的中央计算机系统时，他就能够从任一个提供支持NTCIP的产品的厂商那里购买其他的系统、外场设备或软件。也许只有同一供货商之产品才能够充分运用其产品的功能。但至少在同一标准下，任何供货商都可以提供基本功能。开放的NTCIP标准，使得运营部门可以逐步地从一个厂商向另一个厂商完全更换其软件、控制器和其他外场设备，或是使得在将来给系统添加其它厂商的设备变得更加容易。同时，开放的NTCIP标准也以可避免单一供货商造成的垄断。
2.3跨单位间的协调
NTCIP 允许在不同运营部门间进行信息交换，同时在相互授权的情形下，执行某些指令以监控其它运营部门的系统状态。像这类的信息交换与协调可以通过手动或是自动的方式来进行。如此一来，各运营部门间能够共享信息，并且进行跨部门的控制，以提供用实时出行者信息，进行路网协调控制等。
2.4 单一的通讯网路
NTCIP 使得管理系统能够在相同的通信息道内与不同种类的设备间进行数及传输。例如通过过系统计算机上的软件来信号控制交叉路口边的可变情报板(Changeable Message Sign, CMS)以显示适当信息。通信网络通常是运输管理系统中最昂贵的组成部分之一，采用NTCIP则确保这项投资未来使用上的弹性。
3. NTCIP所支持的系统及设备种类
NTCIP 定义了一系列通用的通信协议以及专用于交通的数据字典和信息集来支持大多数运输管理用途的计算机系统和外场设备。NTCIP的应用一般分为两大类：中心到外场（Center-to-Field，C2F）及中心到中心（Center-to-Center，C2C）的应用。前者通常包含路侧设施或者是各运营部门所拥有的车辆与管理中心的计算机之间的信息传输。而后者则主要是管理中心的计算机或各个子系统之间的数据传输，这些计算机可处于同一房间内，也可以是位于相邻机构运营的管理中心内或是跨国的。NTCIP在ITS系统架构所扮演的角色如图2 所示：
图 2 NTCIP与 National ITS Architecture间的关联
值得注意的是，有些Center-to-Center通讯相关计算机可能位于外场（如信息服务亭、外场控制器等），NTCIP的Center-to-Center及Center-to-Field的通讯协议也支持这些拨号方式的通讯连接。
不论是Center-to-Center或是Center-to-Field间的应用，NTCIP都支持诸如交通、公共运输、紧急管理、出行者信息及交通规划系统上所需用到的系统与设备。图 3 说明了不同的运输管理系统与设备间如何通过NTCIP来进行整合，图中的Streets System （城市交通控制系统）即为本计划主要的研究对象。
图3 利用NTCIP进行整合ITS各子系统
NTCIP可应用的系统及设备至少包含：
1. Center-to-Field
动态信息标志
交通信号控制器
车载感应器及控制器
环境检测器
匝道计量仪
车辆检测器
视频切换
公路照明控制
上述各项的组合
2. Center-to-Center
交通管理（高速公路／街道，城市／乡村）
运输管理（公共汽车／铁路／其他）
紧急事故管理
停车管理
出行者信息（所有模式）
商用车辆营运规划
上述各项的组合
许多NTCIP的应用都与实时通讯有关，并且涉及到连续的、自动化的信息及指令的传送。NTCIP也提供了使用者与远程机器通讯功能。历史资料也可以利用NTCIP来传送。当然其它的通讯标准，像是e-mail 及 ftp 等特别为Internet所设计的通讯标准，也适用此一目的。人与人(human-to-human)间的通讯最好是透过传真机/电话及网际网络的通讯协议，但在Center-to-Center的通讯协议中，NTCIP依旧提供基本的功能以进行人与人之间的沟通。
4 NTCIP不支持的应用功能
在智能运输系统中，某些信息传送因其特别的需求而要采用其它的标准。NTCIP的成果在于和这些不同标准进行协调整合以达成实际运作的要求。这些标准成果包括：
1. 路侧设施采集经过车辆的信息或向经过的车辆发送信息。这部分内容涉及到短距离、短时间、快速且精简的无线数据传输，如专用短程通信DSRC。 而NTCIP主要适用于路侧设施与中央计算机之间的通讯传输。
2. 由摄像机或其它媒体所传来的全动态的图像传输。这部分内容涉及到特别的通讯协议来负载大量且连续的信息流以显示图像，并且此部分已有许多标准存在，如MPEG等。如果有图像传输的需求，NTCIP系统仍可以通过另一通讯信道来传送输图像资料。
3. 传送出行者信息给一般道路使用者的车辆。这部份牵涉到了特别的通讯协议，比如FM广播，RDS等。NTCIP适用于从不同的信息来源传送交通信息给ISP(Internet Service Provider)，再由ISP通过广播或副载波的方式将交通信息发布出去。
4. 金融交易的通信。这部分内容涉及到特别的加密及安全方面因素，目前NTCIP并没有支持。
5. 操作监控与先进车辆控制及与安全相关的车内通讯。这部分内容涉及到了特别的通讯协议以应付同一车辆内不同装置之间的高速与故障自动防止的信息传输。
6. 路侧机箱内的控制器与电子设备间的传输。这部份牵涉到特别的通讯协议以完成短距离的快速信息传输。
5 NTCIP的通讯模块及分层
起初的NTCIP遵照OSI参考模型的规范，对于控制中心与现场设备或控制中心之间连接的标准，分别定义Class B、Class A、Class C及Class E四种分级配置。新版的NTCIP标准已不再使用Class来分级，而采用模块及分层方式来传输，类似ISO的OSI 7层。一般而言，两台计算机或其它电子设施间的数据传输和下面这几层有关，为了区别于ISO和Internet所定出的Layer，NTCIP 以 Level 来分层。
1. Information Level （信息层） － 这一层主要提供应用程序处理的数据元素、对象、信息等的传输标准，像是TCIP、TS3.5、MS/ETMCC等。
2. Application Level （应用层）－ 这一层主要提供信息包的结构及会话管理的标准，像是SNMP、STMP、DATEX、CORBA、FTP等，属于OSI中Application、Presentation、Session等Layer。
3. Transport Level（传输层） － 本层主要提供信息打包、分割、组合及路由等方面的标准，诸如TCP，UDP，IP等，属于OSI中Network、Transport等Layer。
4. Sub-network Level （子网络层） － 此层提供实体接口的标准，像是调制解调器、网络卡、CSU/DSU等以及封包传送，如HDLC、PMPP、PPP、Ethernet、ATM等，属于OSI中数据链路层（Data-link Layer）。
5. Plant Level（实体层）－ 实体层包含了实体的通讯传输介质，例如铜导线、铜轴电缆、光纤、无线通讯等，属于OSI中Physical Layer。
纵观上述的通信分层分级结构，除了Information Level具有交通运输产业的独有特性外，其它各层的标准及功能则都与现有计算机工业界标准几乎相同。由于ITS涉及在许多不同领域、不同功能的实体之间传送的标准对象、信息等，像是交通、运输、出行者信息、紧急管理，故Information Level 与现存工业标准之间有着较大的差异。
对于子网络层及传输层而言，这些部分可使用既有电信及计算机产业中已经发展成熟的标准。除了在应用层，NTCIP自行制订了STMP，在子网络层，NTCIP自行制订了PMPP 之外，NTCIP并不打算在这个领域发展新的标准，只是选择ITS中要采用那些标准以及这些标准与其它标准间的配合情形。NTCIP在这几层中特别着重于应用层。虽然这部分已存在某些标准，且这些标准亦能满足部分NTCIP的需求，但考虑到ITS的特别需要，该层是在现存标准的基础上继续延伸或是发展出全新的通讯协议（如STMP）以符合ITS的要求。这些 ITS的特殊通讯需求包括了：
1. 连续的、自动化的、安全且实时的大量数据信息在各单元间的网络传输。
2. 在路侧的嵌入式处理器及车上设备之间传送的连续、大量的实时数据，这部分信息须共享低速的通讯信道及要求很低的延滞时间。
由于不同层之间可以采用不同的业界现有通信标准或是专为ITS的特别需求而开发出来的全新标准，因此NTCIP所提供的一系列通讯协议可以满足大多数的ITS需求。
6 NTCIP的架构
在不同层之间，可以采用不同的标准来传送信息，而且这些标准之间都是兼容的。一条信息在NTCIP架构中的每层至多使用一个标准来传输。这种利用一连串标准来递送信息称为标准的堆栈“Stack of Standards”，或是通讯协议堆栈“Protocol Stack”。不同的设备在交换信息时，有可能部分信息采某一组标准来传输，其它信息则采另一组标准来传输。下图说明了NTCIP 的架构，显示出在每层都可以选择不同的标准来传递资料。
图 NTCIP标准架构
下面以一个简单的NTCIP中心到外场（Center-to-Field）的标准堆栈的例子来说明。一个堆栈可以视为全部NTCIP标准架构中的子集，在不同的层中传递信息。有些堆栈在某些层中会包括两个以上的标准，这代表了通讯协议能够使用其中的任意一个标准。下图显示了中心将信息通过SNMP、PMPP、FSK MODEM、双绞线传递给外场设备。
图 Center-to-Field 通信的例子
如上所示，大多数的底层标准都是现存于通信界，且行之多年的标准，NTCIP并不打算针对于此来发展。ITS特有的标准主要位在于架构的上层，如：Information Level与Application Level。每一个NTCIP 通信协议堆栈都涉及到上层NTCIP特定的标准与下层目前既有的标准。下表显示 Center-to-Field可供选择的标准。
表 Center-to-Field可供选择的标准
（注：并非所有Sub-network及Plant Level的任意组合都可行 。）
7 NTCIP 标准及通讯协议堆栈
一开始发展的NTCIP标准主要用于Center-to-Field的应用。这部分涉及到新的Application Level通信标准称为 STMP（简单运输管理协议：Simple Transportation Management Protocol）、新的Sub-network Level通信标准称为PMPP（单点对多点协议：Point-to-MultiPoint Protocol），以及Information Level中新的信息格式标准，称为对象（Object）。NTCIP在发展Center-to-Field之通信协议时，也包括了使用现存的标准：SNMP（Simple Network Management Protocol）及HDLC（High-Level Data Link Control）。其中SNMP用于Application Level，而HDLC则用于Sub-network Level。而后，NTCIP标准加入Center-to-Center的应用，并发展了新的Application Level通讯标准称为DATEX（数据交换：Data Exchange），以及使用现存的工业标准CORBA（通用对象请求代理体系：Common Object Request Broker Architecture）。
NTCIP在1999年利用Profile 来规范每层应该使用的标准。在 Information Level 、Application Level、 Transport Level 及 Sub-network Level中，上述标准均已被认可。概要说明如下：
HDLC（高级数据链路控制：High-level Data Link Control）- HDLC是面向位的，以数据帧为单位传送信息，传输的数据以二进制数据组成，不存在任何特殊的控制代码，但帧中的信息包含了控制和响应命令。它可支持全双工或半双工模式，适合于点对点和多点（多路播送或一对多）连接。HDLC的子集被用来向X．25、ISDN和帧中继网提供信令和控制数据链路。
PMPP（点对多点协议：Point-to-Multipoint Protocol）- PMPP本质上与HDLC相同，可支持全双工或半双工模式，适用于点对点与和多点（多路播送或一对多）连接的通信架构。PMPP可说是修订自HDLC的子集合。
SNMP （简单网络管理协议：Simple Network Management Protocol）- SNMP提供了简单但却占用较高带宽（带宽效率较低）的Center-to-Field应用，它主要是根据同名的网际互联通信协议SNMP 改造而来。SNMP只适用于宽带的或是信息量少的网络。 SNMP已由互联网团体设计成能够在UDP／IP上运行，但它也能勉强在TCP/IP 或 T2/NULL上运行
STMP（简单运输管理协议：Simple Transportation Management Protocol）- STMP 是SNMP的延伸，由于采用动态复合对象（Dynamic Composite Objects）的方式，在传输上较SNMP而言更有效率。STMP适用于较低带宽的但信息量大的网络，包括了交通信号控制系统。。由于STMP支持低带宽链路，因此它可在T2/NULL上运行，但是如果有足够的可用带宽，也可在UDP/IP 或 TCP/IP上运行。
SFMP（简单固定信息协议：Simple Fixed Message Protocol）－针对低端外场设备的有效带宽协议的需求已经凸显了出来，如闭路摄像机控制器。NTCIP开发SFMP就是为了满足这个需求。由于SFMP还不完善，因此它还没有被包括在NTCIP框架中
DATEX （系统数据交换协议：Data Exchange Between Systems）- DATEX 提供了一般的Center-to-Center的数据交换协议。DATEX在点对点的网络中使用了一般的网际互联通信协议（TCP／IP 及 UDP／IP）来传递事先定义过的信息，这是一个NTCIP工作小组所开发出的ISO标准，称为DATEX-ASN，因为是全新标准，目前开发工具尚不完善。
CORBA （通用对象请求代理体系：Common Object Request Broker Architecture）- CORBA 目前可说是计算机业界的成熟标准，开发工具比较完善。对于对象导向的系统而言，CORBA提供较DATEX来得更高度的整合，不过对于实时的应用及松散的连结系统来说，可能并不适用。
除了规范协议栈之外，系统设计者还必须在不同的可行方案之间进行选择。大多数的选择，像每一层要采用哪个协议等最好一致。当然某些供货商的特定设备若不支持这些标准，也只能例外处理。不过要达到NTCIP的效益，在采购时，应该要求供货商提供的产品支持上述之标准。
8 Center-to-Center的通信协议
Center-to-Center的通信协议主要有两种：DATEX及CORBA。由于涉及到各系统间的信息交换，这两种通讯协议都有其存在的必要。在同一网络中，使用两种通信协议是可行的，只要任一中心能将不同通讯协议的信息进行相互交换即可。DATEX的目的在于提供一般需要简单且便宜的解决方案，特别适用于：
系统需要实时且快速的数据传输
系统的带宽不足但是数据传输的负载却很重
非面向对象的系统
相反，CORBA则提供了开放的架构来连接不同的面向对象的系统。假定两个系统之间的处理速度足够快且带宽不是问题，则CORBA适用于这类系统的所有应用程序的信息传输。面向对象软件能够充份发挥CORBA的优点，并且能够进行快速开发，但是传统的过程性软件则不能。预期大多数的系统都会支持DATEX，甚至仅单独使用。即使网络上的某些系统是采用面向对象的，并且也采用CORBA，也可能会提供支持DATEX的系统接口来传递信息，以适应实时数据交换的需求。未来，经过一段时间之后，当网络上愈来愈多的用面向系统开始使用且硬件环境也加强后，CORBA将会成为未来的主流。同样的，这些非面向的系统则须反过来提供CORBA的接口来进行资料的交换。
Center-to-Center的网络将允许每个系统向其它系统间要求提供信息。每个系统能够接受或是拒绝其它系统的要求。传输的信息有可能是一些数据资料，也有可能是针对其它系统进行的控制。以一个交通信号控制系统给其它系统传送信息为例，这些信息内容将包括信号灯的配时信息。利用DATEX来进行信息交换，这些信息有可能对单一一个红绿灯进行控制或是某组红绿灯进行控制，也可能只是将控制的结果传给中心。不论是上述那种情形，使用者都能够要求信息只传一次或是持续不断地传送。在DATEX的系统中，能够指定资料只传一次，或是周期性的传送，或是在某些特殊情形下传送（主动回报）。除非是只传送一次的情形，否则信息将不断的传送，直到这一指令结束或是新的指令到来。
9 Center-to-Field的通讯协议
NTCIP提供三种相关的通信协议来定义Center-to-Field的通讯，这三个通讯协议分别是互联网的简单网络管理协议（SNMP），简单运输管理协议（STMP）和简单固定信息协议（SFMP），最后一项协议正在发展当中。追溯来源，SNMP及 STMP都源于网际网络中的Simple Network Management Protocol （SNMP）。SNMP及STMP使用NEMA TS 3.x 系列所定义出的相同信息对象。下表为 SNMP、STMP及SFMP间的简单比较。
SNMP、STMP及SFMP的比较
|
SNMP |
STMP |
SFMP |
|
|
能够传送任何基本数据元素? |
是 |
是 |
开发过程中 |
|
带宽使用效率－数据包开销对比 |
差 |
佳（使用动态对象） |
|
|
提供路由及拨号 |
可选 |
可选 |
|
|
信息设置 |
支持 |
13种 |
|
|
操作难易度 |
容易 |
难 |
|
|
能够传送任何基本数据元素? |
是 |
是 |
STMP能够节省带宽的使用，并且在不频繁的信息需求下能提供所有SNMP的功能。事实上SNMP为STMP的子集，亦即任何支持STMP的管理系统亦能与使用SNMP的设备进行通讯。相较于SNMP，STMP最大的优点是利用一有效的编码机制来支持动态复合对象（Dynamic Composite Object ）以有效降低封包的开销（Overhead）。动态复合对象也使得使用者能够自定订阅由任何对象组合而成的信息。因此STMP是一种较具弹性且节省带宽的选择。不过比起目前发展成熟且有现成开发工具的SNMP来说，STMP在实作上困难许多。
在Sub-network Level中，设备不论使用HDLC/PMPP或是以太网络都可以和其它使用相同的子网共享相同通信干线。每个设备都会被指分配唯一的地址以防与其它设备产生冲突。管理系统能够与在任一时间与任一设备进行通信，虽然如此，同一时间内还是只允许与单一设备进行通信。不过NTCIP也具备广播（Broadcasting）的功能（比如系统的时间同步与校正），而在广播时，所有设备均不能响应信息。
10 Center-to-Field 的通讯设备带宽的考虑
在规划一个NTCIP的Center-to-Field的通信网路时，中心与外场会不断进行信息交换，因此要考虑以下的因素：
传输速率（bps）
传输方法（全双工、半双工，顺序的 或是 重叠的）
传输延滞（包括 调制解调器的激活联机时间）
现场设备的响应延滞（收到请求到响应间的时间）
同一链路之设备间轮询（Polling）的时间
传送信息的长度
每种信息的发送频率
共同信道或是网络线路的设备数
通信频率（即轮询周期）
前述七项将决定每个设备通信时所需花费的总时间。假设每个设备通信总时间是固定的（T），同一时间又有N个设备在同一信道上，则轮询的周期P就变为N×T。这类简单的计算可做为先行规划的考虑。
虽然NTCIP的STMP设计给低传输率（如1200 bps）使用，但是STMP和过去设备使用的协议比起来效率依然不够好。弹性与效率间本来就是一个权衡的问题，弹性愈好，效率自然就差。因此对于既有设施而言，在设备数相同的情况下，采用STMP可能无法维持同样的轮询周期。这是因为之前设备之协议已经最佳化过，但只要频宽够高，折衷的情形自然会下降。
11 NTCIP针对目前的Center-to-Field系统的更新
修改控制器或控制器的软件以兼容NTCIP似乎并不可行，可能会遇到的问题有计算能力、内存使用、修改软件成本等，这些都将给旧有设备兼容NTCIP造成困难。在这种软件无法更新或被替换的情形下，交通控制系统将持续使用旧有的设施、旧有的软件、旧有的通信协议与其它设备进行通信。在预算许可的情形下，如果软硬件能够修改成兼容NTCIP，则应设法和制造商联系以升级相关软硬件。
一般而言，NTCIP 与非NTCIP的设备无法在同一通信信道上混用。因此若许多设备共享同一信道的话，则这些设备必须持续的升级以符合NTCIP的需要。若一计算机同时和NTCIP 兼容之设备与NTCIP不兼容的设备进行通信，则需采用不同的通讯端口来传输数据，同时也必须有着二套不同的通讯协议。
以传统的交通控制系统为例，最可能且最容易的解决方法为限制每个外场控制器采用单一通讯协议。只有具兼容于NTCIP控制器的外场控制器会被升级成提供NTCIP。这样可以避免外场控制器持续的供应两套不同的通讯协议且使用两个不同的通讯端口。
即使系统仍然使用既有的通信协议，但在新购买控制器、软件包时最好选择亦兼容NTCIP通讯协议的产品。有的厂商会在相同的软件包上提供现存的通讯协议及 NTCIP。在采购相关软硬件时，不论目前是否采行NTCIP也最好选择NTCIP兼容的产品，如此将可保有未来升级的可能性。
http://www.moc.gov.cn/hrcc2011/rencaigl_rcw/xueshujl_jyjl/jiaotongkj_xsjl/201108/t20110809_1020235.html
国家运输ITS通信协议（NTCIP）简介相关推荐
- MQTT通信协议的简介、特点及实现原理 - 第1章
目录 1.1 MQTT 特点 1.2 MQTT实现原理 1.3 术语 相关链接 MQTT是一种基于 发布/订阅 模式的 轻量级 通信协议,由IBM于1999年发布.MQTT专门针对 物联网设备 开发, ...
- 美国波多里奇国家质量奖（MBNQA）简介
美国前总统里根于1987年签发的美国<公众法100-107>,确立了美国马尔克姆·波多里奇国家质量奖(Malcolm Baldrige National Quality Award,缩写: ...
- STM-32：SPI通信协议/W25Q64简介—软件SPI读写W25Q64
目录 一.SPI简介 1.1电路模式 1.2通信原理 1.3SPI时序基本单元 1.3.1起始和终止 1.3.2交换字节 二.W25Q64 2.1W25Q64简介 2.2W25Q64硬件电路 2.3W ...
- 科研 | 国家自然科学基金委 | 资助项目简介
国家自然科学基金委员会根据科技发展趋势和国家战略需求设立相应的项目类型,经过不断优化调整,形成了结构合理.功能完备的资助体系. 一.面上项目 简称:面上 面上项目支持从事基础研究的科学技术人员在科学基 ...
- 数据通信协议的简介（数据通信协议和网络协议有什么区别？）
数据通信协议 Data communication protocol 亦称数据通信控制协议.是为保证数据通信网中通信双方能有效,可靠通信而规定的一系列约定.这些约定包括数据的格式,顺序和速率,数据传输 ...
- 智能网联汽车封闭测试场建设内容简介
一.背景 2021年7月30日,工业和信息化部发布了<关于加强智能网联汽车生产企业及产品准入管理的意见>(下称<意见>).此前,4月7日工业与信息化部发布了<智能网联汽车 ...
- 智能网联汽车测试场设计技术要求
智能网联汽车测试场设计技术要求 智能网联汽车测试场设计技术要求 自动驾驶功能和基础道路的基本对应关系 一般测试道路技术要求 高速测试道路 城市测试道路 乡村测试道路 特殊测试道路 坡道 隧道(含模拟隧 ...
- 全球及中国自主运输机器人行业十四五创新模式与运行战略规划报告2022版
全球及中国自主运输机器人行业十四五创新模式与运行战略规划报告2022版 --------------------------------------- [修订日期]:2021年12月 [搜索鸿晟信合研 ...
- 来自沙特阿拉伯的新国家航空公司--利雅得航空公司首次亮相
美通社消息,世界级的数字化领先航空公司利雅得航空公司在第54 届巴黎航空航天双年展览会上首次亮相,揭开了全球旅游业的新篇章. 6月12 日星期一,带有利雅得航空独特涂装的波音787-9梦想客机降落前, ...
最新文章
- 剪切粘贴时总是上次的内容_Quicker 1.4版本更新内容
- 使用chrome development tool观察box 模型
- 小程序的wx.onAccelerometerChange
- Ubuntu10.10的网络配置
- 如何为Docker项目创建持续集成持续部署 (CI-CD)解决方案
- c语言银行系统个人心得,c,,银行管理实验报告心得体会.docx
- grep 多模式匹配
- Loonframework-DAO-Alpha-0.1.0发布
- android 7双排设置菜单,双排状态栏
- 国内浏览器双核模式 默认切换chrome内核
- java deflate_Java实现deflate算法的压缩和解压
- vim ： 删除不包含某字符的行
- win7系统iis建立ftp服务器,win7 iis建立ftp服务器
- vue如何返回上一页效果
- AD域内禁用所有计算机445端口,勒索病毒“永恒之蓝”变种再来，该如何关闭445端口（收藏）(示例代码)...
- Windows XP 上网提示：您的时钟快了/慢了
- 使用JAVA面向对象语言，完成五子棋应用功能设计
- 贪心（基于检索式问答系统）
- 数字调制系列：IQ调制基本理论
- android获取手机的当前OS版本。sdk版本