智能交通系统第二章概要课件

1、2 智能交通系统体系结构开发意义目标开发历程美国国家ITS体系结构国外ITS体系结构比较中国ITS体系结构的建立4学时智能交通系统将是21世纪我国交通运输领域的一场技术革命，建立一个统一、结构完整、可扩展性强的ITS体系结构是ITS全面实施应用的基础美国、日本和欧洲在20世纪90年代陆续完成了本国(地区)的智能交通系统体系结构，并不断地推出改进版本。智能交通系统(ITS)的体系结构是指系统所包含的各子系统为实现用户服务功能、满足用户需求所应具备的功能，以及各个子系统之间的相互关系和集成方式。2.1 意义决定了系统如何构成 确定了功能模块以及模块之间的通信协议和接口 它的设计必须包含实现用户服务

2、功能的全部子系统的设计意义 ITS是大量的功能、技术和信息的集成 通信需求无所不在 数据的获取途径和处理方法多种多样 产品和服务的开发具有阶段性 所有这些都要求有一个框架来赖以建立灵活而经济的系统ITS体系结构系统体系结构通过确定系统组件、组件的功能以及各组件之间的关系来向设计人员和产品开发者提供所需的框架和基本指导美国从1993年开始组织力量研究开发国家ITS体系结构，取得了一些值得借鉴的成果，并于1998年和1999年分别提交了美国国家ITS体系结构的第二和第三版ITS体系结构开发欧盟各国在欧盟委员会的领导下，由来自各国相关政府部门、大学、科研机构和产业界的专家于1998年4月开始了为期2

3、4个月、代号为KAREN（Keystone Architecture Required for European Networks）的项目，进行欧盟ITS体系结构的开发，并于1999年8月和10月分别推出了其逻辑体系结构和物理体系结构。日本国家ITS体系结构的开发由5个政府部门：运输省、邮电省、建设省、通产省和警察厅联合进行，并于1999年11月完成。ITS体系结构2.2 开发目的ITS系统本身比较复杂，涉及面广，需要有一个指导性的框架(或模型)，来帮助理解这个系统的结构；ITS是一个庞大的系统，包含有很多子系统，它的实施需要通过这些子系统来实现，ITS体系结构为ITS各个部分提供了统一的接口

4、标准，从而使各个部分便于协调，集成为一个整体；避免缺少和重复，使ITS为一个高效、完整的系统，并具有良好的扩展性； 根据国家总体ITS框架，发展地区性的ITS体系结构，保证不同地区智能交通系统具有兼容性。2.3 开发历程以美国为例 1992年ITS AMERICA向美国运输部正式推荐了一套调动多家国有/私立机构联合攻关的ITS体系结构开发方法。 1993年USDOT正式启动了ITS体系结构开发计划，其目的是开发一个经过详细规划的国家ITS体系结构第一阶段称为“思路竞争”阶段，有4个开发小组参加。 4个小组都有能力单独完成体系结构的开发，所以让他们在第一阶段展开竞争比进行合作更有利于激发对各种观

5、点的公开分析，最终将增加体系结构的可接受性。 1994年10月4个小组都完成了体系结构初步方案，经过评审和比较，2个开发小组获准进入第二阶段第二阶段从1995年2月到1996年7月，2个开发小组不再是竞争关系，而是合作开发统一的国家体系结构。 1997年1月，USDOT公布了美国国家ITS体系结构(第一版)，经过1年多的试用和维护 1998年9月USDOT又公布了修订后的美国国家ITS体系结构(第二版)。整个计划共耗资2500万美元，主要成果体现在5000页文档中，平均每页5000美元。2.3 开发历程2.4 美国国家ITS体系结构美国国家ITS体系结构（National Architectu

6、re， 简称NA）从用户服务(User Service)入手 逐步确定了未来在美国发展和实施的ITS的逻辑结构(Logical Architecure) 物理结构(Physical Architecture) 针对不同背景的实际需要推荐了一系列市场包(Market Package)。 组成部分名称 作用(与服务的关系)用户主体 服务的对象，指定需求的主体服务主体 服务的提供者用户服务 明确系统能够提供的服务系统功能 ITS为完成用户服务必须具有的处理能力逻辑框架 为提供拥护服务所需ITS功能的组织化物理框架 明确怎样具体提供服务ITS标准和评价其他技术经济因素美国国家ITS体系结构组成建立一个

7、开放、公平、适应多层次系统集成的体系结构 同时能为用户提供多种性能价格比选择 保护用户隐私 最大限度地增强操作性和降低市场风险。2.4.1 总体设计原则2.4.2 用户服务从用户的角度看ITS所能做的事情 进一步细化为用户服务要求，是体系结构开发的基础 美国NA的30项用户服务及其分类如下表所示。用户服务领域 用户服务 出行和运输管理在途驾驶员信息 路线导行 旅行者服务信息出行和运输管理 交通控制 偶发事件管理 排放测试与污染缓解 道路-铁路交叉口 出行前旅行信息 合乘车匹配与预约出行需求管理 需求管理和运营 公共运输管理美国NA的30项用户服务美国NA的30项用户服务用户服务领域 用户服务

8、在途公交信息 个人化公共交通公共运输运营 公共出行安全 电子付费服务电子付费服务商用车电子结关 自动路边安全检查 车载安全监视 商用车行政管理 危险物品异常响应商用车运营 商用车队管理 紧急事件通报与个人安全保障用户服务领域 用户服务紧急事件管理 紧急车辆管理 纵向防撞 横向防撞 交叉口防撞 防撞视野强化先进车辆控制和安全系统危险预警 撞前避伤 自动公路系统美国NA的30项用户服务2.4.3 逻辑结构逻辑结构是组织复杂实体和关系的辅助工具，其重点是系统的功能性加工和信息流。开发逻辑结构有助于确定系统的功能和信息流动，并能指导开发出对新系统和改进后的系统的功能性要求主要有两种系统建模的方法：面向

9、过程的方法(Process Oriented methodology)和面向对象的方法(object oriented methodology)。面向过程的方法用自顶而下的方法对系统进行结构化分析，产生系统功能表以及数据流图。面向对象的方法用对象和类的概念对系统进行抽象分析，将功能(方法)与数据(属性)封装在一起，并具有继承特性。美国逻辑结构的开发方法采用面向过程的开发方法，用结构化思想和方法，针对每一类用户服务，设计出一系列结构相互独立、功能单一的功能模块，这些模块之间通过数据流来实现相互联系，形成整体子系统并完成相应的功能。逻辑结构逻辑结构独立于体制和技术不确定由谁来实现系统中的功能不考虑

10、实现这些功能的方式。相关的加工和数据流组合起来就可形成特定的运输管理功能(如管理交通)。逻辑结构通常用分层的数据流图数据词典和加工说明等来描述面向过程方法美国NA的顶层逻辑结构图2.4.4 物理结构物理结构是系统的物理视图，它是关于系统应该如何提供所有用户所要求的功能的物理性陈述。物理结构把逻辑结构所认定的“加工”分配到物理实体(在ITS中称为子系统)上，根据各实体所含的加工之间的数据流(Data Flow)，确定实体之间的结构流(Architecture Flow)。结构流及其对通信的要求将确定物理实体之间的接口(Interface)，是制定有关标准和协议的基础。在美国NA中，物理结构分2层

11、进行描述：运输层和物理层。运输层显示ITS组件之间的关系；通信层为运输层各组件的连接提供通信服务。美国NA子系统及其通信连接 2.4.5 市场包如果说逻辑结构和物理结构是体系结构的正式定义的话，市场包则是体系结构的补充说明。市场包可以表示特定的运输问题和需要，并且可以回溯到30项用户服务及其详细的用户服务要求。市场包不倾向于与特定的技术相联系，但要靠可行的技术和产品市场来实现。随着运输市场需求的进化、技术的发展、新设备的开发，市场包可以调整，也可以定义新的市场包。分类 内容 分类 内容 路网监视 广播式交通信息 交 探测车监视 出 互式交通信息 平面道路控制 行 自主型路线导行 通 高速公路管

12、理 者 动态路线导行 和可变车道管理 信基于信息服务提供者的路线导行 管 交通信息发布 息 运输管理/路线导行集成 区域交通控制 服 旅行者服务 理 偶发事件管理系统 务动态合乘车服务 交通网络性能评价车内标志 动态过路费/停车费管理 虚拟和智能探测 普通铁路与道路交叉口 高速铁路与道路交叉口 铁路运营协调美国NA定义的市场包美国NA定义的市场包分类 内容 分类 内容紧急 紧急事件响应 车队管理事件 紧急路线引导 商 货运管理管理 紧急事件支援 用 电子结关公交车跟踪 车 电子结关登记公固定线路公交车运营 管国际边境电子结关交需求响应公交车运营 理加载请求车公交乘客及车费管理商用车路边安全设备

13、管公交车安全保证 商用车车载安全设备理公交车维护 商用车队维护多运输方式协调 危险品管理分类 内容 车辆安全监视 驾驶员安全监视 纵向安全警告先 横向安全警告进 交叉口安全警告车 撞前避伤辆 防撞视野强化 先进的车辆纵向控制 先进的车辆横向控制 交叉口防撞 自动公路系统ITS规划 ITS规划美国NA定义的市场包2.5 国外ITS体系结构比较2.5.1 总体设计原则 欧盟的总体设计原则是要建立一个开放、精炼而稳定的体系结构，能支持多种路面交通模式，可在不同模式之间自由切换，同时保障技术上的独立性。日本的总体设计原则是所建立的体系结构要具有足够的灵活性，能适应社会需求变化和技术进步带来的剧烈变革，

14、保障ITS与构建在先进的信息和通讯基础设施上的社会之间的相容性和关联性，而ITS的信息资源及其基础设施作为整个社会信息构架。 美国国家ITS体系结构和欧洲ITS框架结构的用户需求都是定义在主要结构之前的。在KAREN项目中，用户需求定义的是体系结构需要提供和支持的服务，它们的结构基本相同，相关的需求被分为一组。在美国体系结构中，需求以“域”分类，而KAREN中以“组”分类。2.5.2 用户服务美国用户需求域 KAREN用户需求组No.标题 No. 标题1 出行和运输管理 1 总体2 公共运输运营 2 管理行为3 电子付费服务 3 政策4 商用车运营 4 金融交易5 紧急事件管理 5 紧急服务6

15、 先进车辆控制和安全系统 6 旅游信息7 信息管理 7 交通管理 8 车内系统 9 货运和车队运营 10 公共交通美国用户需求“捆”和KAREN用户需求“组” 2.5.3 逻辑结构 欧盟和美国ITS体系结构的开发基于面向过程的方法。日本和澳大利亚ITS体系结构的开发基于面向对象的方法欧盟和美国的逻辑结构，通过“自顶向下”的方法进行功能分析，以便用户能从结构得到尽可能多的细节，这种方法最大的特点是便于理解一是美国国家ITS体系结构中的“逻辑结构”在欧盟ITS框架结构中称为“功能结构”二是美国国家ITS体系结构中功能被分为“过程”，而欧盟ITS框架结构分为“功能”，“过程”和“功能”的形式及内容是

16、类似的，它们之间的关系通过数据流图表示。 美国逻辑结构 欧洲功能结构No.名称 No. 名称1 交通管理 1提供电子支付设备2 商业车辆管理 2提供安全和紧急设备3 提供车辆监控 3交通管理4 运输管理 4公共交通运营管理5 紧急服务管理 5提供驾驶员辅助系统6 提供驾驶员和旅行者服务 6提供旅行者旅游服务7 提供电子支付服务 7提供法律加强支持8 存档数据管理 8运输和车队运营管理美国和欧盟结构中的功能区 日本采用面向对象的开发方法 从系统组成上对系统进行分解，使得设计人员以更接近人的思维方式建立问题模型，使设计出的系统尽可能直接描述现实世界； 在系统的功能需求发生变化时，能更方便地对系统进

17、行局部修改而不至于造成整个系统大的变化。 与开发方法相对应，美国和欧盟的逻辑结构主要以数据流图的方法进行表达，而日本的逻辑结构则采用统一建模语言及相应的开发工具进行开发和表达。逻辑结构 2.5.4 物理结构欧盟ITS物理结构的目的与美国不同，它是建立其它低层次的结构和物理系统的开始，这些结构可以在全国或地区范围内实施欧盟ITS框架结构包括“范例系统”，可以展示低层次结构和物理系统是如何建立的。使得结构更接近于使用者的特殊需要以一类用户服务为单位，针对一类或一组用户服务，采用系统、子系统、模块这一由高到低的层次化结构，将逻辑结构中定义的各类功能模块分配到这些模块中可以方便地根据需要分阶段实施IT

18、S相关任务欧盟ITS物理结构范例日本的物理结构综合了美国和欧盟的特色，分别从高、低两个层次来表达ITS物理结构一方面，它采用了美国的分类方法，将整个系统划分为4个大类别的24个子系统，构成一个高层次的系统总体结构另一方面，以用户服务为单位组织物理实体，即针对要实现的每一类用户服务设计一组包含了各项功能模块的物理实体，以实现相应的用户需求，同时这些物理实体也分别属于4大类中的一类，构成低层物理结构。日本物理结构2.6 中国ITS体系结构的建立科技部会同国家计委、经贸委、公安部、铁道部、交通部等十几个部、委、局联合建立了发展ITS的政府协调领导机构全国智能交通系统协调领导小组及办公室，并成立了IT

19、S专家咨询委员会。 “中国ITS系统框架研究” 成果提出了适合中国交通业现状和发展趋势的智能交通系统体系框架、逻辑结构、物理结构，提出中国智能交通系统的规划和实施以及经济和技术的评估。并明确全国ITS的总体内容和各部分相互关系，明确了政府、企业和用户在ITS发展中所处的角色和应起的作用 开发方法选择“中国ITS体系框架研究”采用了面向过程的方法。软件开发过程：现实世界建立模型（借助某种建模思想）编程实现（借助某种编程语言）计算机求解面向过程：现实世界流程图（变量、函数）面向过程语言执行求解。面向对象：现实世界类图（对象、方法、消息等）面向对象语言执行求解面向过程更接近与计算机世界的物理实现，把

20、数据和代码作为分离的实体，反应计算机的观点，忽略了数据与操作的内在联系分析阶段建立逻辑模型，设计阶段建立物理模型数据流图 模块结构图不通表示体系，转换面向对象符合人们的认识习惯，强调直观模型，而不强调算法，按照人的思维方式建立问题与模型，开发出尽可能直观、自然地表现求解方法的软件系统。采用统一建模语言，通用的、图形化的模型语言对象、类、继承、封装、属性、聚合、事件、状态、行为、消息传送、多态性等概念支持。开发方法选择2.6.1 体系结构研究过程 2.6.2 用户服务定义三个步骤：定义分类用户需求用户服务分别对ITS的用户主体(ITS users)和服务主体(ITS services provi

21、der)进行定义分类。用户主体分为六大类：道路使用者、道路建设者、交通管理者、运营管理者、公共安全负责部门、相关团体服务主体分为九大类：交通管理、公共交通、交通信息服务、紧急救援、基础设施、货物运输、产品/设备制造、产品服务、政府执法部门。 用户服务定义对用户主体进行用户需求分析，得到用户需求(user needs)用户需求是用户对于ITS系统功能的需求以及其他方面的需求(如系统可靠性、安全性、兼容性等) 即从用户角度阐述用户需要什么样的系统功能和系统特性用户需求是用户服务、子服务定义的基础，因此也是用户服务定义阶段最重要的工作，得出用户需求表。 运营者用户需求表 用户主体 对运输系统基本需求

22、 用户需求 1.提供天气情况、污染状 况信息 城市道路、地铁、交通设施 2.提供路面、路况信息城市公共交通部门 3.用户对交通流的需求 信息 根据用户需求分析的结果进行用户服务(users services)。 8个服务域，33项服务，161个子服务 8个服务域分别为：出行者信息服务；车辆安全与辅助驾驶；运营管理；交通管理和规划；电子收费；紧急事件和安全；综合运输(多式联运)和自动公路。用户服务 服务名称 定义 用户主体 交通管理部门应用ITS技术 执行交通法规，及时准确地 收集到违反交通法规事件的 公路交通管理部门交通法规监督与执行 信息，在不影响正常交通运 行的前提下自动或人工执行 城市交

23、通管理部门 相应的处理措施交通管理服务域服务定义 2.6.3 逻辑框架逻辑框架基于前边所定义的用户服务为ITS体系结构提供了系统功能和数据流的有序组织，主要分为以下3个步骤：功能需求分析终端定义逻辑框架构建1 功能需求(functions needs)分析功能需求分析则是针对系统开发人员。功能需求分析的结果产生功能需求表。服务名称 子服务名称对系统的功能需求紧急事件管理 事件的预防城市和城市间的交通 数据的采集;紧急事件 预测模型的建立在功能需求分析的基础上，对需求分析的结果进行整理汇总，合并那些相同、相类似的针对不同用户主体功能，对服务领域进行功能域的划分。逻辑框架构建的主要依据 功能域 第

24、1层功能第2层功能 第3层功能交通管理功能域 交通控制 提供城市的交通控制 设施管理控制 采集交通数据 提供城市间的交通控制服务领域的功能域划分终端是发送信息给智能交通系统内的子系统或从子系统接收信息的外部实体，是系统与外部世界的连接。定义了每个终端的功能并确定了系统的边界 是构建逻辑框架与物理框架的前提表达了系统与外部世界的相互作用；界定了系统的内部和外部终端名称 定义驾驶员 该终端指在道路上有执照的车辆操作人员,包括私人、公交车辆 驾驶人员以及紧急车辆驾驶人员.车辆接收或发送的数据不因 车型而有所区别2.终端(terminator)定义逻辑框架的构建不考虑管理体制和技术因素只确定系统功能，

25、而不管功能由谁来实现，如何实现，具体的实现工作交给物理框架去做。逻辑框架也被称为“基本模型”，与系统的具体实现分离使得逻辑框架便于改进。逻辑框架通常用数据流图、功能说明和数据词典等来描述。逻辑框架的构建逻辑框架顶层结构功能说明数据流数据流图逻辑框架的构建步骤功能说明功能说明是在功能层次表的基础上对过程总体上的叙述性说明，一系列的系统功能需求说明以及对输入输出数据流的简要说明。名称 功能描述 相关数据流 功能需求检测事件 检测发生的事件; 输入数据流: 接收到城间交通检 方便其他功能提供 当前事件信息 测数据或城市交通检 数据和视频数据的 城间交通检测数据 测数据时,分析其包含 输入;分析所得的数 城市交通检测数据 的内容 2.若(1)项的 据,确定事件发生的 输出数据流： 结果有异常,可能有事 方式;将事件发生的 事件检测信息 件发生,记录事件发生 详细信息传给其他 的日期、时间及位置 功能以分类存储 等信息 用事件检 测信息将(2)项记录的 事件信息传给存储管 理 数据流就是在逻辑框架中功能之间以及功能和终端之间传输的信息，它代表着ITS中“运动的数据”。在数据流图中，数据流表示为一个箭头并在逻辑框架的数据字典中进行定义说明。数据流按照起终点一致