03-智能交通系统体系结构
第三章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体系结构，其主要流程如图3.1所示。
图3.1结构化方法构建体系结构流程简图
（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多条用户服务要求。
(2) 逻辑结构
UNIA 逻辑结构通过ITS 需求总图、数据流图、处理说明和数据字典来体现 前述用户服务和用户服务要求。UNIA 确定的美国ITS 总图如图3.2所示，图中 圆圈代表ITS 功能性“处理”，矩形代表从ITS 处理接收信息或者将信息传递给 ITS 处理的“外部终端”。图3.3是简化了的UNIA 顶层数据流图，图中箭头表 示“数据流”，圆圈表示“处理”、直线段表示“文件”，矩形表示“外部终端”
图3.2 美国ITS 总图
商用车 驾驶员
普通车 驾驶员
公交驾 驶员
普通车
其它车
公交车
紧急系统 车辆 工作员
管理部门
道路收 费机构 其它商用车 管
理系统
公交车队 管
理者
政府 部门
媒体 公交糸统 道路收费员 地图更新者 交通规划 人员 旅仃者服务 提供者 管理
ITS
交通 行-
人 道路建设 与维护
货运管理 机构
公交乘客 其它交通 管理中心 定位数据源 紧急通信 系统 多模式运输 服务提供者 公共场所 安全状况
道路
路边 设备
旅行者 商用车 |活动主办者| 多模式货运 装卸人员 多模式货运 仓库 其它公交 管理中心
收费设备 道路与铁路 交叉口 天气预报者 其它紧急事 件管理中心 停车场 工作人员
停车场主 财政机构 公交维修 人员 执法机构 信息服务 工作人员 交通管理 人员 运营者 车辆特征 其它信息服 务提供者 商用车运营 信息问讯者
商用车 检查人员
铁路 运营者
图3.3简化的UNIA顶层数据流图
(3)物理结构
UINA将运输系统分成3层：运输层、通信层和体制层。运输层执行运输功能，通信层为运输层组件之间的连接提供通信服务，体制层反映政策制定者、规划者和其他ITS用户之间的关系。物理结构的确定要考虑体制方面的因素，但体制层不属于物理结构部分，而是在实施策略中描述。物理结构分运输层和通信层进行描述。
运输层
UNIA构架总图与图3.2所示的逻辑结构总图一致。
UNIA将ITS组件分成4类，即：中心子系统、路侧子系统、车辆子系统、出行者子系统；每种类型又包括数量不等的个别子系统，UNIA共确定了19个
子系统；每个子系统进一步分解多个设备包。设备包是物理结构中可以购买的最小单位的实体，每个设备包对应着逻辑结构中的一个或多个“处理”。
图3.4 是UNIA 顶层构架流图(Top Level Architecture Flow Diagram)，显示了各类子系统之间及其与外部终端之间的关系，图中实线框表示ITS组件，虚线
框表示外部终端。
图3.4 UNIA 顶层构架流图
通信层
UNIA 为支持ITS 子系统之间的通信定义了 4种类型的通信媒体，即：有线 通信（固定一一固定）、广域无线通信（固定一一移动）、专用短程通信（固定 ――移动）和车车通信（移动一一移动）。
图3.5是UNIA 顶层构架互连图，显示了美国ITS 分属4类的19个子系统 （用矩形框表示）及其交换信息的 4种基本通信连接方式（用椭圆形框表示）， 该图也可被看成是UNIA 物理结构之运输层和通信层的最高级视图。
信息
其它中心 子系统
协调
请求
1
状态 4 1
中心 工作人员
1—请求_?
车辆 一识别__? 路侧
―请求一； 路侧
状态—
子系统
^_交易确认 ____ 子系统
_状态G 工作人员 ；
厂■ ■ ■ ■ ■ ■
车辆系统
环境
L ___ 2
1
i
L
—
路侧系统
出行者 子系统
1
出行者
.—请求
》
I
电状态
_请求服务亠 = 回应
识别交易确认
:驾驶员
中心 子系统
请求服务
探测车数据
障碍物
AHS 控制状态
空气质量状态控制
L
图3.5 UNIA顶层构架互连图
第四节中国国家ITS体系结构展望
本节参考UNIA，对中国国家ITS体系结构（CNIA ）做扼要介绍，主要集中于上层体系结构，并给出各子系统之间的关系。
1.逻辑结构
逻辑结构的重点是系统的功能性处理和数据流。逻辑结构独立于体制和技术，它不确定由谁来实现系统中的功能，也不考虑实现这些功能的方式。因此，CNIA逻辑结构与UNIA逻辑结构的差异主要来源于中、美ITS用户服务与用户服务要求的差异。
ITS总图
总图定义系统的边界，根据中国ITS用户服务要求，可初步确定中国ITS
总图如图3.6所示；与美国ITS 总图相比，增加了自行车、骑自行车者、残疾车、
残疾人、科研人员、防灾救灾办公室等外部终端。
图3.6 中国ITS 总图
顶层数据流图
顶层数据流图涉及到ITS 功能的首次分解，其实质是划分ITS 功能领域。 UNIA 逻辑结构将ITS 分解成8棵功能性“处理树”，即：交通管理、商用车管 理、车辆监视与控制、公交管理、紧急服务管理、驾驶员和出行者服务、电子
公交 驾驶员 商用车 驾驶员
晋通车 驾驶员
障碍物
道路
路况
环境
其它车
公交车
旅行者 ■动
商用车检 查人员
公共场所 安全状况 紧急系统 工作员
其它商用车 管理系统
公交车队 管理者
车辆 管理部门
多模式货运 装卸人员 管理
ITS
行人 交通 其它公交 铁路 路边 管理中心 运营者 设备
普通车
商用车 公交乘客 媒体 其它交通 管理中心 定位数据源 紧急通信 系统 多模式货运
仓库 多模式运输 服务提供者 防灾救灾 办公室 自行车 残疾车 商用车运营 信息问讯者
骑车者 货运管理 机构 残疾人
科研人员
道路建设
与维护 执法机构 信息服务 工作人员
车辆特征
道路收费员
道路收
费机构
交通管理
人员 交通规划 人员 停车场 工作人员 停车场王 财政机构
其它信息服 务提供者 公交维修 人员 公交系统 运营者
收费设备
地图更新者
旅行者服务 提供者
天气预报者 其它紧急事 件管理中心 道路与轨道 交叉口
付款服务、规划与实施。考虑到中国与美国在用户服务要求上的区别，可以在 逻辑结构顶层数据流图将中国ITS 分解成9棵功能性“处理树” ：1)交通管理； 2)商用车管理；3)车辆监视与控制；4)公交管理；5)紧急服务管理；6)驾驶员与 旅行者服务；7)电子收付费；8)自行车与行人支援；9)提供历史数据服务。
考虑各“处理树”之间的数据交换，可得中国ITS 逻辑结构顶层数据流图如 图3.7所示。
图3.7中国ITS 逻辑结构顶层数据流图
2.物理结构
物理结构把逻辑结构所确定的“处理”分配到ITS 物理实体上，根据各实体 所含的“处理”之间的数据流，确定实体之间的构架流，进而确定物理实体的 互连方式。
物理结构的确定要考虑系统功能要求，也要考虑非功能性要求，包括体制、 文化、市场等因素的影响。系统功能要求通过逻辑结构确定的“处理”和“数 据流”来体现，决定ITS 物理实体必须完成的功能。非功能性要求则影响
ITS
功能在物理实体间的分配。例如：美国最初想把“交通信息服务”功能和“交 通管理”功能分
付费请求
查询AH
路
线
公交紧急 事件协调
事件检测信息 \
\公交紧急事件 \
事件数据
肢务信息
路线请求
数据 据
价格数据 价格查询
AH 控制
收费结果
财务数据
确认信息
请求服务
紧急车辆运营数据
商车统 计数据
探测车信息 与排放数据
查询危险 物品信息
公交统 计数据 交控信息 公交优 先请求
事件数 据查询
公交
查询
交通数 据记录 事件管理信息及 优先控制请求
紧急 事件 求救
路线数据
车辆数据
9 提供历史 数据服务 (DFD
(2
商用车管理
(DFD
6 驾驶员与 旅行者服务 (DFD
交通管理 (DFD
7
电子收付费 (DFD
8
自行车与行 人支援 (DFD
车辆监视与 控制 (DFD
紧急 服务管理 (DFD
紧急事件数据 了暴力事件信息
收费结果
4 公交管理 (DFD
配到一个子系统中，但考虑到“交通信息服务”涉及到个人隐私，执行“交通管理”功能的公有部门在保护个人隐私方面不如私有部门，因此决定专门设计“信息服务提供者”子系统来执行“交通信息服务”功能，并期望由赢利性私有商家来完成之；又如：为了吸引运输业者购买车载ITS产品, 美国ITS体系结构研究小组又将“处理”功能尽量多地分配到“路侧子系统” 中，减少“商用车系统”承担的功能，为降低商用车车载ITS产品的价格提供
基础。
尽管中国与美国在体制、文化、市场等方面不尽相同，但从长远目标来看，CNIA与UNIA 在这方面的基本考虑应该是一致的，例如：要保护隐私、扩大市场等。所以，CNIA与UNIA在物理结构方面的差异，主要还是应该来源于功能要求上的差异。以此为基础，可对CNIA物理结构作出初步展望。
运输层
CNIA构架总图与图3.7所示的逻辑结构总图一致。
中国ITS组件也分成4类，即：中心子系统、路侧子系统、车辆子系统、出行者子系统；但在中心子系统类型中增加“灾害救治中心”，同时将“规划”子
图3.8中国ITS顶层构架互连图
系统扩展为“历史数据服务”子系统；在路侧子系统类型中增加“自行车道”；在车辆子系统类型中增加“自行车”子系统。
通信层
CNIA子系统之间的通信可以套用UNIA确定的4类通信媒体，即：有线通信（固定一一固定）、广域无线通信（固定一一移动）、专用短程通信（固定一—移动）和车车通信（移动一一移动）。
图3.8显示了中国ITS分属4类的22个子系统（用矩形框表示）及其交换信息的4种基本通信连接方式（用椭圆形框表示），是CNIA顶层构架互连图，同时也是CNIA物理结构之运输层和通信层的最高级视图。
思考题
建立ITS体系结构有什么重要意义？