智能交通系统体系结构

第三章ITS体系结构
智能交通系统是一种复杂的巨系统，如何来描述系统各构件之间的相互关系及系统各部分的功能与整体功能，就要用到“体系结构”这一概念。

本章介绍ITS体系结构的基本概念、体系结构的构建方法、以及应用实例。

第一节什么是ITS体系结构
系统的概念来源于自然实践。

辞海对系统的解释是：所谓“系统”，是由相互作用和相互依赖的若干组成部分结合成的具有特定功能的有机整体。

在交通系统中，人、车、路以及货物这四个组成部分构成了道路交通系统，该系统的目的是实现人或物的有效移动。

如果人（货物）、车、路构成的道路交通系统，再配上具有智能的交通信息中心、交通管理中心、交通控制中心等以及智能化的车载设施和道路交通基础设施，如各类检测设施、信息发布设施即信息传输设施，就构成了智能交通运输系统。

然而，怎样来描述这一抽象概念的系统呢像居住房屋一样，房屋由基础、梁、柱、屋面等各构件用一定的搭接方式建成，具有供人们居住生活的功能。

房屋的各构件相互搭接的关系及房屋各部分的功能和整体功能可用房屋的建筑图和结构图来描绘。

同样，ITS各构件的相互关系及各部分的功能和整体功能，也可用系统体系结构来描述。

因此，ITS的体系结构是指系统所包含的子系统、各个子系统之间的相互关系和集成方式、以及各个子系统为实现用户服务功能、满足用户需求所应具备的功能。

根据定义，ITS体系结构决定了系统如何构成，确定了功能模块以及模块之间的通信协议和接口，它的设计必须包含实现用户服务功能的全部子系统的设计。

ITS体系结构具有下列重要意义：
ITS本身比较复杂，涉及面广，需要有一个指导性的框架，来帮助我们理解这个系统的结构；
ITS是一个庞大的系统，包含有很多子系统，它的实施需要通过这些子系统来实现，ITS体系结构为ITS的各个部分提供了统一的接口标准，从而使各个部分便于协调，集成为一个整体；
避免少缺和重复，使ITS成为一个高效、完整的系统，并具有良好的扩展性；
根据国家总体ITS框架，发展地区性的体系结构，保证不同地区智能交通系统具有兼容性。

第二节ITS体系结构的构建方法
1. ITS体系结构构建方法比较
世界各国开发ITS体系结构采用的方法主要有两种，一种称为结构化方法(Structured Method)，一种称为面向对象的方法(Object Oriented Method)。

结构化方法，以功能的抽象与分解为主要手段，按功能之间的联结关系组织数据。

结构化方法简单易行，流行已久，能被大多数工程师理解和接受，便于交流，但用结构化方法开发的系统修改或扩展比较困难。

面向对象的方法，首先确定对象或实体及其与其他对象之间的关系，然后确定每个对象执行的功能，围绕数据对象或实体组织功能，形成单一的相互关联的视图。

用面向对象方法开发的系统易于扩展和修改，但该方法操作起来比较复杂，而且可读性不强，不利于交流和讨论。

国家ITS体系结构作为一种指导全国ITS设计的框架，必须得到全国工程师和投资者的广泛认同才能真正发挥作用。

因此，国家ITS体系结构必须具有较强的可读性，以便让更多的人能理解之，进而讨论之。

此外，如果用面向对象的方法来开发ITS逻辑结构，在确定“对象”集时将遇到很大的麻烦，因为ITS是一个复杂的大系统，可能的“对象”太多，“对象”的抽象程度也很难一致。

美国“国家ITS体系结构开发小组”就是选用结构化方法构建了其《国家ITS体系结构》。

我国“九五”国家科技攻关项目“中国智能交通系统体系框架研究”，也采用了结构化方法。

2. 结构化方法简介
结构化方法构建ITS体系结构，其主要流程如图所示。

图结构化方法构建体系结构流程简图
（1）界定用户
构建ITS体系结构首先要界定系统的用户。

ITS作为信息技术（IT）系统的一个分支，可用IT系统界定用户的方法来界定其用户。

信息系统的用户是指影响系统或受系统影响的人和机构，可以从四个方面识别信息技术系统的用户，即：需要IT者、制造IT者、使用IT者和管理IT者。

（2）用户服务
所谓用户服务是按用户的要求，系统应能为用户服务的事项。

ITS用户服务就是ITS能提供的服务与产品；提出了ITS用户服务项目，也就是提出了ITS开发的范围。

（3）用户服务要求
为了实现每项用户服务，需要ITS能完成一系列功能。

为了反映这一点，须将每项用户服务分解成更为详细的功能说明——即用户服务要求；换句话说，用户服务要求是系统为提供用户服务而应该具备的一些功能。

（4）需求模型
需求模型描述系统应该做什么，是系统功能要求的模型化。

需求模型主要任务是定义系统的信息处理行为和控制行为。

在构架模型开发阶段主要考虑系统的功能要求。

需求模型由“需求总图”、一系列分层次的“数据流图”与“控制流图”及其相应的“过程定义”、“控制说明”与“数据字典”组成。

需求总图定义系统的边界，即确定哪些元素属于系统内部，哪些元素位于系统外部。

数据流图和过程定义描述系统执行的功能。

控制流图和控制说明描述系统执行这些功能的条件或环境。

实时性要求(Time Specification)对系统在“输入终端”接受事件(Event)刺激后，在“输出终端”作出反应的时间进行限定。

数据字典对在数据流图、控制流图中出现的数据流、控制流、存储器和终端进行描述和定义。

需求模型在美国《国家ITS体系结构》中被叫做“逻辑结构”，其中的控制流图被加入数据流图。

（5）构架模型
构架模型描述系统设计应如何组织，是系统设计的模型化。

构架模型的主要任务是：①确定组成系统的物理实体；②定义物理实体之间的信息流动；③说明信息流动的通道。

在构架模型开发阶段不仅要考虑功能要求，而且要考虑性能要求、可靠性要求、安全保密要求以及开发费用、开发周期、可用资源甚至市场条件等方面的问题。

构架模型由“构架总图”、“信息流图”、“模块说明”、“信息通道图”、“信息通道定义”和“信息字典”组成。

构架总图建立系统与其运行环境之间的信息边界，是系统的最高级视图，构架总图一般与系统总图一致。

信息流图和构架模块说明描述组成系统的物理模块以及模块之间的信息流动。

信息通道图和信息通道定义描述模块间信息流动的渠道。

信息字典注释信息通道中所有的数据以及数据字典中未出现的其他信息。

构架模型在美国《国家ITS体系结构》中被叫做“物理结构”。

构架模型完成后，经确认所有的用户服务都被体系结构构架中各子系统所包含，并经过对所构建的体系进行评价，包括来自投资者意愿的反馈信息，最后利用来自确认和评价的反馈结果进一步修改系统要求和体系结构。

修改完善后，在确定的ITS体系结构的基础上，才能拟定整个ITS的研究开发计划、制定ITS各部分和各类产品的统一标准以及规定系统的通信协议等。

第三节美国的国家ITS体系结构
1. 开发过程
目前，我国还没有形成最终完善的《国家ITS体系结构》，这里以美国为例，简要介绍其ITS体系结构。

美国是最早开发完整的ITS体系结构的国家，美国国家ITS体系结构开发计划分为两个阶段，第一阶段为“思路竞争阶段”，由4个小组分别独立开发出体系结构初步方案；经过方案评审和比较，2个开发小组获准进入第二阶段，称为“联合开发阶段”，吸收各初步方案的优点，经过整理与合并，合作开发统一、唯一的国家ITS体系结构。

典型的体系结构开发过程实质上包括在第一阶段的工作中，采用了反复修改的开发程序。

首先从界定用户、确定用户服务和用户服务要求出发，开发出运营要求或系统要求，进而开发出运营概念（体系结构的目标以及用户如何与之交互）；接着，开发包含一系列详细功能要求的逻辑结构；将逻辑结构中的处理分配到物理实体/子系统，就产生了物理结构，一个在2012年时间框架内提供所有用户服务的体系结构也就被开发出来了；发展部署确定导入某些功能(或服务)的时间框架和背景；体系结构的确认体现在追溯矩阵中，追溯矩阵将用户服务要求追溯至逻辑结构中的处理、物理结构中的子系统，以保证所有的用户服务都被体系结构所包含；然后对体系结构进行评价，包括接受来自投资者意愿的反馈信息；最后利用来自评价和确认过程的返馈结果进一步改进系统要求和体系结构。

2. ITS体系结构概貌
美国国家ITS体系结构（简称UNIA）开发计划共耗资2500万美元，主要成果体现在约2500页的文本中，分为：体系结构、评价、实施策略和相关标准等4部分内容。

下文将从用户服务与用户服务要求、逻辑结构和物理结构等方面，介绍美国国家ITS体系结构概貌。

（1）用户服务与用户服务要求
满足用户服务和用户服务要求是对ITS体系结构的基本要求，UNIA覆盖了30项ITS用户服务（见下表3-1）)及相应的1000多条用户服务要求。

表3-1 美国ITS用户服务
（2）逻辑结构
UNIA逻辑结构通过ITS需求总图、数据流图、处理说明和数据字典来体现前述用户服务和用户服务要求。

UNIA确定的美国ITS总图如图所示，图中圆圈代表ITS功能性“处理”，矩形代表从ITS处理接收信息或者将信息传递给ITS处理的“外部终端”。

图是简化了的UNIA顶层数据流图，图中箭头表示“数据流”，圆圈表示“处理”、直线段表示“文件”，矩形表示“外部终端”。

图美国ITS总图
（3）物理结构
UINA 将运输系统分成3层：运输层、通信层和体制层。

运输层执行运输功能，通信层为运输层组件之间的连接提供通信服务，体制层反映政策制定者、规划者和其他ITS 用户之间的关系。

物理结构的确定要考虑体制方面的因素，但体制层不属于物理结构部分，而是在实施策略中描述。

物理结构分运输层和通信层进行描述。

运输层
UNIA 构架总图与图所示的逻辑结构总图一致。

UNIA 将ITS 组件分成4类，即：中心子系统、路侧子系统、车辆子系统、出行者子系统；每种类型又包括数量不等的个别子系统，UNIA 共确定了19个子系统；每个子系统进一步分解多个设备包。

设备包是物理结构中可以购买的最小单位的实体，每个设备包对应着逻辑结构中的一个或多个“处理”。

图是UNIA 顶层构架流图(Top Level Architecture Flow Diagram)，显示了各类子系统之间及其与外部终端之间的关系，图中实线框表示ITS 组件，虚线框表示外部终端。

图 简化的UNIA 顶层数据流图
电子付款服务
驾驶员和出行者服务
紧急事件服务
付款请求付款
紧急事件确认紧急事件通知
财务机构
商用车辆
路线请求
公交时刻表
紧急事件通信系统
事故数据路线信息
事故信息事故确认
交 通
普通车辆
拥挤信息
路线信息
交通信息
ITS 规划者公交请求
商用车辆运营管理
路线信息
公交管理
规划与实施
规划数据
车辆状态
交通控制信息
车辆监视与控制
管理交通
公交优先请求
通信层
UNIA 为支持ITS 子系统之间的通信定义了4种类型的通信媒体，即：有线通信（固定——固定）、广域无线通信（固定——移动）、专用短程通信（固定——移动）和车车通信（移动——移动）。

图是UNIA 顶层构架互连图，显示了美国ITS 分属4类的19个子系统（用矩形框表示）及其交换信息的4种基本通信连接方式（用椭圆形框表示），该图也可被看成是UNIA 物理结构之运输层和通信层的最高级视图。

图 UNIA 顶层构架流图
出行者
出行者子系统
请求状态
中心子系统
请求服务回应中心系统
信息
其它中心
子系统
协调中心系统中心工作人员
状态
请求车辆子系统
驾驶员
路侧子系统
路侧工作人员
请求状态识别交易确认状态
请求信息识别交易确认
请求服务探测车数据
其它车辆车辆系统控制状态
AHS 环 境障碍物
空气质量路侧系统
状态控制
ITS总
人、科研人员、防灾救灾办公室等外部终端。

图 中国ITS 总图
顶层数据流图
顶层数据流图涉及到ITS 功能的首次分解，其实质是划分ITS 功能领域。

UNIA 逻辑结构将ITS 分解成8棵功能性“处理树”，即：交通管理、商用车管理、车辆监视与控制、公交管理、紧急服务管理、驾驶员和出行者服务、电子付款服务、规划与实施。

考虑到中国与美国在用户服务要求上的区别，可以在逻辑结构顶层数据流图将中国ITS 分解成9棵功能性“处理树”：1)交通管理；2)商用车管理；3)车辆监视与控制；4)公交管理；5)紧急服务管理；6)驾驶员与旅行者服务；7)电子收付费；8)自行车与行人支援；9)提供历史数据服务。

考虑各“处理树”之间的数据交换，可得中国ITS 逻辑结构顶层数据流图如图所示。

图 中国ITS 逻辑结构顶层数据流图
1交通管理（DFD）
6
驾驶员与旅行者服务（DFD）
2
商用车管理（DFD）
3
车辆监视与
控制（DFD）
4公交管理（DFD）
5紧急服务管理（DFD）
7
电子收付费（DFD）
9提供历史数据服务（DFD）
8
自行车与行人支援（DFD）
探测车信息与排放数据
AHS控制
交控信息公交优先请求
事件检测信息
事件管理信息及优先控制请求
交通数据
路线数据
价格数据价格查询
服务信息
交通数据记录路线请求
路线
查询危险物品信息
紧急事件数据收费结果
车辆数据
商车统计数据
请求服务确认信息
车辆数据
查询AHS路线
公交紧急事件
公交紧急事件协调
公交查询
公交数据公交统计数据
查询事件数据
事件数据查询
暴力事件信息
紧急车辆运营数据紧急事件求救
付费请求
收费结果财务数据
2. 物理结构
物理结构把逻辑结构所确定的“处理”分配到ITS物理实体上，根据各实体所含的“处理”之间的数据流，确定实体之间的构架流，进而确定物理实体的互连方式。

物理结构的确定要考虑系统功能要求，也要考虑非功能性要求，包括体制、文化、市场等因素的影响。

系统功能要求通过逻辑结构确定的“处理”和“数据流”来体现，决定ITS物理实体必须完成的功能。

非功能性要求则影响ITS功能在物理实体间的分配。

例如：美国最初想把“交通信息服务”功能和“交通管理”功能分配到一个子系统中，但考虑到“交通信息服务”涉及到个人隐私，执行“交通管理”功能的公有部门在保护个人隐私方面不如私有部门，因此决定专门设计“信息服务提供者”子系统来执行“交通信息服务”功能，并期望由赢利性私有商家来完成之；又如：为了吸引运输业者购买车载ITS产品，美国ITS体系结构研究小组又将“处理”功能尽量多地分配到“路侧子系统”中，减少“商用车系统”承担的功能，为降低商用车车载ITS产品的价格提供基础。

尽管中国与美国在体制、文化、市场等方面不尽相同，但从长远目标来看，CNIA与UNIA在这方面的基本考虑应该是一致的，例如：要保护隐私、扩大市场等。

所以，CNIA与UNIA在物理结构方面的差异，主要还是应该来源于功能要求上的差异。

以此为基础，可对CNIA物理结构作出初步展望。

运输层
CNIA构架总图与图所示的逻辑结构总图一致。

中国ITS 组件也分成4类，即：中心子系统、路侧子系统、车辆子系统、出行者子系统；但在中心子系统类型中增加“灾害救治中心”，同时将“规划”子
；在车辆子系统类型中增加“自行车”子系统。

通信层
CNIA 子系统之间的通信可以套用UNIA 确定的4类通信媒体，即：有线通信（固定——固定）、广域无线通信（固定——移动）、专用短程通信（固定——移动）和车车通信（移动——移动）。

图显示了中国ITS 分属4类的22个子系统（用矩形框表示）及其交换信息的4种基本通信连接方式（用椭圆形框表示），是CNIA 顶层构架互连图，同时也是CNIA 物理结构之运输层和通信层的最高级视图。

思考题
建立ITS 体系结构有什么重要意义
车
-车通信
远程出行支持个人信息入口
广域无线通信
出行者子系统
普通车辆
公交车辆商用车辆紧急车辆车辆子系统
路边
收费
停车管理商用车检查交通管理
尾气排放管理
公交管理
收费管理
车队与货运管
理
商用车管理
历史数据服务
中心子系统
专用短程通信
路边子系统
有线通信
信
息服务提供者
紧急事件管理
自 行 车
自 行 车 道
灾害救治中心
图 中国ITS 顶层构架互连图。