智能交通系统-ITS体系结构(DOC)Word文档下载推荐.docx
- 文档编号:1066275
- 上传时间:2023-04-30
- 格式:DOCX
- 页数:15
- 大小:60.54KB
智能交通系统-ITS体系结构(DOC)Word文档下载推荐.docx
《智能交通系统-ITS体系结构(DOC)Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《智能交通系统-ITS体系结构(DOC)Word文档下载推荐.docx(15页珍藏版)》请在冰点文库上搜索。
需要IT者、制造IT者、使用IT者和管理IT者。
(2)用户服务
所谓用户服务是按用户的要求,系统应能为用户服务的事项。
ITS用户服务就是ITS能提供的服务与产品;
提出了ITS用户服务项目,也就是提出了
ITS开发的范围。
(3)用户服务要求
为了实现每项用户服务,需要ITS能完成一系列功能。
为了反映这一点,须将每项用户服务分解成更为详细的功能说明——即用户服务要求;
换句话说,用户服务要求是系统为提供用户服务而应该具备的一些功能。
(4)需求模型
需求模型描述系统应该做什么,是系统功能要求的模型化。
需求模型主要任务是定义系统的信息处理行为和控制行为。
在构架模型开发阶段主要考虑系统的功能要求。
需求模型由“需求总图”、一系列分层次的“数据流图”与“控制流图”及其相应的“过程定义”、“控制说明”与“数据字典”组成。
需求总图定义系统的边界,即确定哪些元素属于系统内部,哪些元素位于系统外部。
数据流图和过程定义描述系统执行的功能。
控制流图和控制说明描述系统执行这些功能的条件或环境。
实时性要求(TimeSpecification)对系统在“输入终端”接受事件(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-RouteDriverInformation)
路线导行(RouteGuidance)
旅行者服务信息(TravelerServicesInformation)
交通控制(TrafficControl)
偶发事件管理(IncidentManagement)
排放测试与缓解(EmissionsTestingandMitigation)
道路—铁路交叉口(Highway-RailIntersection)
出行需求管理
出行前旅行信息(Pre-TripTravelInformation)
合乘车匹配与预约(RideMatchingandReservation)
需求管理和运营(DemandManagementandOperations)
公共运输运营
公共运输管理(PublicTransportationManagement)
在途公交信息(En-RouteTransitInformation)
个人化公共交通(PersonalizedPublicTransit)
公共出行安全(PublicTravelSecurity)
电子付费服务
电子付费服务(ElectronicPaymentServices)
商用车运营
商用车电子结算(CommercialVehicleElectronicClearance)
自动路边安全检查(AutomatedRoadsideSafetyInspection)
车载安全监视(On-BoardSafetyMonitoring)
商用车行政管理(Commercial Vehicle Administrative
Processes)
危险物品异常响应(HazardousMaterialIncidentResponse)
商用车队管理(CommercialFleetManagement)
紧急事件管理
紧急事件通报与个人安全(Emergency Notification and
PersonalSecurity)
紧急车辆管理(EmergencyVehicleManagement)
先进车辆控制和安全系统
纵向防撞(LongitudinalCollisionAvoidance)
横向防撞(LateralCollisionAvoidance)
交叉口防撞(IntersectionCollisionAvoidance)
防撞视野强化(VisionEnhancementforCrashAvoidance)
危险预警(SafetyReadiness)
撞前避伤(Pre-CrashRestraintDeployment)
自动公路系统(AutomatedHighwaySystems)
(2)逻辑结构
UNIA逻辑结构通过ITS需求总图、数据流图、处理说明和数据字典来体现前述用户服务和用户服务要求。
UNIA确定的美国ITS总图如图3.2所示,图中圆圈代表ITS功能性“处理”,矩形代表从ITS处理接收信息或者将信息传递给ITS处理的“外部终端”。
图3.3是简化了的UNIA顶层数据流图,图中箭头表示“数据流”,圆圈表示“处理”、直线段表示“文件”,矩形表示“外部终端”。
障碍 路况物
公交系统
运营者
信息服务
工作人员
车辆特征
收费设备
道路收费员
地图更新者
旅行者服务提供者
道路收
费机构
交通管理人员
交通
行人
管理
ITS
定位数据源
道路 路边设备
政府部门
公交车队管理者
其它商用车管理系统
车辆管理部门
紧急系统工作员
铁路运营者
其它公交管理中心
商用车检查人员
货运管理机构
商用车运营信息问讯者
其它信息服务提供者
道路建设与维护
多模式运输服务提供者
公共场所安全状况
紧急通信系统
多模式货运仓库
多模式货运装卸人员
其它交通管理中心
活动主办者
财政机构
其它紧急事件管理中心
停车场主
天气预报者
停车场工作人员
道路与铁路交叉口
交通规划人员
执法机构
公交维修人员
媒体
公交乘客
商用车
旅行者
公交车
其它车
普通车
公交驾驶员
普通车驾驶员
商用车驾驶员
图3.2 美国ITS总图
电子付款服务
付款请求
付款
驾驶员和出行者服务
紧急事件确认
紧急事件通知
紧急事件服务
紧急事件通信系统
路线请求
公交时刻表
公交请求
事故数据
路线信息
商用车辆运营管理
公交管理
规划与实施
规划数据
交通信息
公交优先请求
拥挤信息
事故信息
车辆监视与控制
车辆状态
管理交通
事故确认
交通控制信息
交通
普通车辆
商用车辆
ITS规划者
财务机构
(3)物理结构
图3.3 简化的UNIA顶层数据流图
UINA将运输系统分成3层:
运输层、通信层和体制层。
运输层执行运输功能,通信层为运输层组件之间的连接提供通信服务,体制层反映政策制定者、规划者和其他ITS用户之间的关系。
物理结构的确定要考虑体制方面的因素,但体制层不属于物理结构部分,而是在实施策略中描述。
物理结构分运输层和通信层进行描述。
运输层
UNIA构架总图与图3.2所示的逻辑结构总图一致。
UNIA将ITS组件分成4类,即:
中心子系统、路侧子系统、车辆子系统、出行者子系统;
每种类型又包括数量不等的个别子系统,UNIA共确定了19个子系统;
每个子系统进一步分解多个设备包。
设备包是物理结构中可以购买的最小单位的实体,每个设备包对应着逻辑结构中的一个或多个“处理”。
图3.4是UNIA顶层构架流图(TopLevelArchitectureFlowDiagram),显示了各类子系统之间及其与外部终端之间的关系,图中实线框表示ITS组件,虚
线框表示外部终端。
中心系统
其它中心子系统
信息
出行者
中心子系统
出行者子系统
请求 请求服务
状态 回应
协调
请求 中心
状态 工作人员
请求服务探测车数据
信息 识别交易确认
请求
驾驶员
状态
AHS 控制状态
其它车辆
车辆系统
路侧工作人员
障碍物
空气质量状态控制
环境
路侧系统
路侧子系统
车辆子系统
识别 请求
交易确认 状态
图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总图相比,增加了自行车、骑自行车者、残疾
驾驶员
障碍物 道路 路况 环境 其它车公交车
旅行者 商用车
公交乘客 媒体
交通 人员
行人 交通规划
人员
道路与轨道
交叉口
残疾车
路边
设备
信息服务工作人员
公交系统运营者
科研人员
残疾人
骑车者
自行车
防灾救灾办公室
车、残疾人、科研人员、防灾救灾办公室等外部终端。
图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
电子收付费
车辆数据
查询AHS路线
价格数据
交通数据
8
自行车与行人支援
路线数据
价格查询
公交数据
公交查询
探测车信息与排放数据
1
3
AHS控制
交控信息公交优先请求
4
紧急事件求救
交通数事件管理信息及据记录优先控制请求
公交紧急
事件检测信息 事件协调
路线
财务数据
公交紧急事件
确认信息
2
商车统计数据
9
提供历史数据服务
请求服务
公交统计数据
5
紧急
事件数据查询
查询危险物品信息
紧急车辆运营数据 服务管理
紧急事件数据暴力事件信息
图3.7 中国ITS逻辑结构顶层数据流图
2.物理结构
物理结构把逻辑结构所确定的“处理”分配到ITS物理实体上,根据各实体所含的“处理”之间的数据流,确定实体之间的构架流,进而确定物理实体的互连方式。
物理结构的确定要考虑系统功能要求,也要考虑非功能性要求,包括体制、文化、市场等因素的影响。
系统功能要求通过逻辑结构确定的“处理”和“数据流”来体现,决定ITS物理实体必须完成的功能。
非功能性要求则影响ITS功能在物理实体间的分配。
例如:
美国最初想把“交通信息服务”功能和“交通管理”功能分配到一个子系统中,但考虑到“交通信息服务”涉及到个人隐
私,执行“交通管理”功能的公有部门在保护个人隐私方面不如私有部门,因此决定专门设计“信息服务提供者”子系统来执行“交通信息服务”功能,并期望由赢利性私有商家来完成之;
又如:
为了吸引运输业者购买车载ITS产品,美国ITS体系结构研究小组又将“处理”功能尽量多地分配到“路侧子系统”中,减少“商用车系统”承担的功能,为降低商用车车载ITS产品的价格提供基础。
尽管中国与美国在体制、文化、市场等方面不尽相同,但从长远目标来看,
CNIA与UNIA在这方面的基本考虑应该是一致的,例如:
要保护隐私、扩大市场等。
所以,CNIA与UNIA在物理结构方面的差异,主要还是应该来源于功能要求上的差异。
以此为基础,可对CNIA物理结构作出初步展望。
CNIA构架总图与图3.7所示的逻辑结构总图一致。
自 行 车 道
自行车
灾害救治中心
历史数据服务
车队与货运管 理
中国ITS组件也分成4类,即:
但在中心子系统类型中增加“灾害救治中心”,同时将“规划”
图3.8 中国ITS顶层构架互连图
子系统扩展为“历史数据服务”子系统;
在路侧子系统
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 智能 交通 系统 ITS 体系结构 DOC