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