1、前言本标准按照GB/T 1.1-2009给出的规则起草。本标准由北京市交通委员会提出并归口。本标准起草单位：北京市公共交通研究所、北京航空航天大学、青岛海信网络科技股份有限公司。本标准主要起草人：林正、熊桂喜、翟志强、万里、张海、卢峰、罗大明、符毅1范围本标准规定了大容量快速公交（BRT）智能系统的功能和技术要求。本标准适用于北京市新建、扩建和改建的大容量快速公交（BRT）系统智能工程的设计和实施。2规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T 2423 电工
2、电子产品基本环境试验规程GB 4208-2008 外壳防护等级（IP代码）GB 9254 信息技术设备的无线电骚扰限值和测量方法GB 17626 电磁兼容 试验和测量技术JT/T 3101997 汽车客运站计算机售票管理信息系统规范DB11/T 159.2-2005 市政交通一卡通技术标准第2部分：终端DB11/T 648-2009 公共汽电车客运服务规范3术语和定义3.1快速公交 bus rapid transit一种介于轨道交通与常规地面公交之间的新型公交客运系统，利用改型的公交车辆，运营在公交专用道路空间上，是一种既保持轨道交通特性又具备常规公交灵活性的便利、快速的公交方式。3.2智能交
3、通系统 intelligent transportation system将先进的信息处理技术、电子通信技术、自动控制技术、计算机技术和网络技术等有效地综合应用于整个交通管理体系，从而建立起一种在大范围内、全方位发挥作用的，实时、准确、高效的交通运输综合管理和控制系统。3.3快速公交智能系统 bus rapid transit intelligent system采用智能交通系统技术，实现对快速公交中 “站台/车辆/道路”一体化的智能化监控、调度、管理及服务。3.4调用优先 即绿灯扩展。表示当路口信号为绿灯而又不足以让优先车辆本周期通过时，为使优先车辆不停车通过路口而延长本次绿灯。扩展优先还可
4、包含优先恢复功能，使优先执行后，给冲突方向交通流以适当补偿并尽快回到正常周期。3.5扩展优先 即绿灯调用。表示当路口信号为红灯时，为使优先车辆尽快通过路口而提前结束路口当前的红灯状态并使其转为绿灯状态。调用优先也可包含优先恢复功能。3.6本地控制的公交优先路口信号控制器不与系统相连，在接收到公交申请信息后，根据自身的优先程序执行优先控制。3.7系统监视下的公交优先路口信号控制器与系统相连，但在本地控制模式下运行。信号控制器接收公交申请信息，并根据自身的优先程序执行优先控制。3.8系统优化控制下的公交优先：路口信号控制器在系统优化控制模式下运行，系统各种优化器正常工作。系统接收公交申请信息，并根
5、据自身的优化计算和优先程序的执行结果向信号控制器发送实时扩展或调用优先控制命令。4缩略语下列缩略语适用于本文件。BRT：快速公交，也称为大容量快速公交（Bus Rapid Transit）IC：IP：ITS：智能交通系统（Intelligent Transportation System）GIS：地理信息系统（Geographical Information System）GPS：全球定位系统（Global Positioning System）GPRS：通用无线分组业务（General Packer Radio Service）UPS：5快速公交智能系统的总体要求5.1应按照BRT运营管理的
6、流程，采用ITS技术，实现BRT企业运营调度管理、运营计划编制、调度监控、人员排班及管理、乘客信息服务、电子售检票、公交信号优先、综合查询、统计分析等功能，达到快速公交优化运行、优质服务、规范管理的目标。5.2通过综合技术手段实现BRT“站台车辆道路”一体化的监控，采用车辆定位及识别技术，对车辆的运行位置、运营状态、行车安全信息进行实时采集和监视，对车站、停车场的运行秩序进行实时可视监视。5.3系统既要满足快速公交线路在实现时的运营业务规模需求，又要充分考虑到将来可能的调度中心扩展、调度台调整、车辆调整、车站调整、增加新线的扩容需求；各种功能模块既能按照业务分工或岗位安排进行单独设置，也能根据
7、业务流程调整需要进行组合和拆分。5.4通过功能、数据和通信方式的集成，让BRT智能系统的各类功能系统之间，各类电子设备系统之间，功能系统和电子设备系统之间能够形成满足BRT运营调度、服务、监控、管理要求的一体化系统。5.5系统应在网络系统、计算机及设备系统、数据管理及存储系统中采取保障系统正常运行的安全措施。5.6应在工程设计、设备安装、应用开发、系统部署等环节，采取必要的容错技术和可靠性措施，并进行严格的测试，确保系统能可靠、稳定地运行。5.7在达到预期设计功能和性能的前提下，应充分选用能降低建设成本和运营维护成本的技术和产品。6BRT智能系统功能及设备的组成6.1BRT智能系统应根据业务需
8、求，开发相应应用软件，实现以下功能子系统：a) 运营调度管理：能够运用计算机优化编制运营作业计划、配车计划和劳动配班计划，对运营作业进行实时监控，实现计算机辅助实时优化调度，提示发车，打印路单，记录运营调度结果，形成行车记录及统计报表。b) 车辆管理及安全监控：能对车辆的基本信息、保养状态进行管理。可在不同线路、车队间调配车辆。运营调度过程中可监视车辆速度，并对超速进行告警和记录，对记录可查询、统计和分析。c) 电子售检票：能满足北京公交运营管理要求，实现符合北京市政“一卡通”规范的电子售票、检票功能。d) 路口公交信号优先控制：在交叉路口，能够自动检测或识别BRT车辆，为BRT车辆快速通行提
9、供公交信号优先控制。e) 乘客信息服务：通过电子设备及适当的播报方式，在BRT站台及车辆上，为乘客提供准确、方便、实时的到达预报、报站、位置提示等信息服务。f) 视频监控：通过在停车场、车站安装视频监控设备，实现运营秩序和客流的监视。g) 设备监控及管理：能够对BRT智能系统中的网络、设备和系统实现统一的监控和管理。h) 信息交换：能与BRT线路所属的上级管理机构之间实现信息交换。6.2BRT智能系统应配置的电子设备子系统a) 车载电子设备：（要展开吗？列出(LF)；带要求的细分设备（LDM）b) 车站电子设备c) 停车场电子设备d) 调度中心电子设备e) 路口公交信号优先电子设备f) 网络通
10、信设备7BRT智能系统的功能要求7.1运营调度7.1.1运营基础信息管理7.1.1.1组织结构管理维护公交企业各级单位的信息。单位属性必须包含：单位名称、上级爱的能为、地址、电话、单位类别名称。7.1.1.2线路信息管理线路属性信息必须包含：线路名称、线路编码、线路类型、所属单位、运行方向、首班车发车时间、末班车发车时间、单程里程、单程运行时间、运行准点标准、途经站点集合。7.1.1.3车站信息管理维护公交各个车站的信息，车站信息应包含：标识号、车站名、车站类型、经度、纬度。7.1.1.4场站信息管理维护公交各个场站的信息，场站信息应包含：场站名称、场站类型、经度、纬度、场站之间的距离。7.1
11、.1.5人员信息管理维护公交企业人员的信息，人员信息应包含：所属组织、人员姓名、人员工号、人员岗位类型、人员性别、驾驶证类型、加入公司时间、身份证号。7.1.1.6车辆基本信息管理a) 维护公交运营车辆的信息，车辆信息应包含所属组织、车牌号、车辆自编号、是否空调车、车载机编号、人车绑定信息。b) 应能设置车辆的百公里油耗标准、材料费用标准等定额信息。7.1.1.7车辆保养计划管理a) 应能设置保养级别的种类，如一保、二保、大修等；并能设置不同保养级别的行驶里程规定里程。b) 应能根据车辆行驶里程和车辆保养记录，结合车辆技术状况系统自动计算和编制车辆保养计划，用户可以在自动生成的计划基础上进行调
12、整和修改，生成实际的保养计划。c) 应支持行车计划审批和发布的管理流程，能够将计划编制、审核、发布等操作按不同的角色进行权限控制。7.1.2行车计划管理7.1.2.1系统应能实现根据客流推导出配车数、发车间隔和班型要求，生成行车计划，系统应提供人工调整行车计划的辅助手段，并按照约束条件对人工调整的结果进行检查，给出提示和告警。行车计划应符合客流要求、运力要求和服务水平指标，满足平峰、低峰和高峰的客流变化需求。7.1.2.2系统应支持编制多套行车计划，并能对编制的行车计划进行版本管理。所编制的行车计划应能应对不同的客流需求，应至少包括平日行车计划、假日行车计划、多种客流高峰日的行车计划，并能按照
13、季节客流规律分别进行编制，调度人员根据需要选择使用不同的行车计划。行车计划可以作为标准模板使用，在模板的基础上进行调整，生成新的行车计划。7.1.2.3系统应能够在计划中设定每个车次详细属性，包括全程、区间、空放等多种运营形式，设定不同类型车次的发车时间、里程和车次数；给出每个班次的班型、上下班、出入库、加油、保养、用餐等活动的时间，并能确定出相应非运营车次和空驶里程。7.1.2.4编制格式上应支持按照发车时间顺序显示车次和按照班次显示车次两种方式。7.1.2.5系统应支持将电子表格导入行车计划和将时刻表导出至电子表格。7.1.2.6系统应能打印行车计划，支持浏览、查询、检索已经编制好的行车计
14、划。7.1.2.7系统应支持行车计划审批和发布的管理流程，能够将计划编制、审核、发布、注销等操作按不同的角色进行权限控制。7.1.3配车排班管理7.1.3.1应能根据行车计划要求，指派人员和车辆的运营任务；7.1.3.2应能设定轮班规则和作息类型，根据轮班规则和作息类型生成排班计划，并指定每班次使用的具体车辆，并提供人工调整配车排班计划的辅助手段。7.1.3.3应能实现跨线路调配人员、车辆，满足运营要求。并能自动检测人力、运力调配的冲突，提示调整。7.1.3.4配车排班计划可以作为模板使用，在模板的基础上进行调整，生成配车排班计划。7.1.3.5应能对车辆和人员的状态进行跟踪，作为计划编制依据
15、。7.1.3.6应支持排班计划从电子表格导入和将排班计划导出到电子表格，并支持一次将多条线路的配车数据导出到一个标准的电子表格中。7.1.3.7应支持配车排班计划审批和发布的管理流程，能够将计划编制、审核、发布、注销等操作按不同的角色进行权限控制。7.1.3.8系统应能打印配车排班表，支持浏览、查询、检索已经编制好的配车排班表。7.1.4调度监控管理7.1.4.1应能支持4000辆车的同时在线监控。7.1.4.2应支持用户自定义软件界面布局，并可保存为默认界面布局。7.1.4.3基于电子地图的实时监控a) 电子地图应能显示道路、线路、车站、场站等相关信息。b) 应能实现多种监控方式：单线路监控
16、、多线路监控、多视图监控，能锁定跟踪车辆并绘制运行轨迹。c) 应能在电子地图上显示车辆位置，并能实时查询线路车辆基本信息，包括车辆自编号、车牌号、车速、驾驶员姓名、车载设备在线状况、最后通讯时间、最后经过的站点。d) 应支持查询目标车辆以及查询地理目标的功能，支持模糊查询和精确查询两种查询方式。e) 应能回放单车或多车的运行轨迹，回放的速度倍数可调；回放的时间周期可根据需要设定，回放过程中可以绘制运行轨迹、在GIS上标示出不同的违规地点，并可以导出到图片，车辆运行中的状态、违规等信息配合以列表的形式，在回放过程中滚动显示。f) 应能显示和记录车辆进出停车场时间。g) 应支持主流电子地图平台，实
17、现电子地图基本操作功能。7.1.4.4基于线路示意图的实时监控a) 应根据线路基础信息，自动生成线路示意图，示意图中应包括线路的名称、运行方向、首末站、中途站，应按比例显示站距，实现单屏显示不少于4条线路。b) 应能根据车载GPS数据直观反映出车辆在线路上运行状况，表示出车辆运行的先后顺序、到达站点的位置。能够同时看到调度需要的单车辆信息，包括车辆自编号、车牌号、车速、驾驶员姓名、车载设备在线状况、最后通讯时间、最后经过的站点等信息；应反映出场站停车、驻站状态。c) 应能反映出超速、越线行驶、越站、滞站、快点、晚点、大间隔、串车、报警、故障、堵车的车辆。d) 应能直接在线路示意图上选择车辆进行
18、调度操作、进行历史回放、发送指令。e) 应能配置示意图上车辆图标样式、是否显示自编号、车牌号、站点名称。7.1.4.5人员状态管理a) 应能根据驾驶员签到、签退信息，自动添加上班和下班记录，并自动判断迟到早退；同时提供手工签到、签退功能、考勤记录审核功能。b) 根据驾驶员签到、签退信息，自动添加上班和下班记录，并自动判断迟到早退；同时提供手工签到、签退功能、考勤记录审核功能。c) 应提供手工调整排班配车功能。7.1.4.6信息发布a) 应支持车辆指挥指令、短信息、调度指令的发送，并可把常用信息保存在数据库中；支持信息群发机制；可以向车辆发送指挥指令，指挥车辆按要求行驶，如快行、慢行、注意安全等
19、；可以通过发送短信息方式与驾驶员进行简单的信息交流。b) 所有的指令和消息发送都应有应答机制，能够从系统界面上反映出设备是否已经收到信息，驾驶员是否已经查看过调度指令。7.1.4.7运营监管查询a) 系统应提供到离站信息的历史记录查询。b) 系统应提供违规报警信息查询，可以通过图表的形式进行分类汇总。c) 系统应提供基于公司、分公司、车队、线路等不同权限级别车次执行情况监管，通过表格和图线显示目前计划车次执行情况以及早点次数和晚点次数汇总。d) 系统应提供基于公司、分公司、车队、线路等不同权限级别出车数监管，通过表格和图线对比显示当天以及历史出车数情况。e) 系统应提供基于公司、分公司、车队、
20、线路等不同权限级别运营公里监管，通过表格和图线对比显示当天以及历史计划公里、营业公里、非营业公里、总行驶公里以及执行率等内容。f) 系统应提供基于公司、分公司、车队、线路等不同权限级别油耗监管，通过表格和图线显示当天以及历史油耗。g) 系统应提供中心发送指令的历史记录查询，包括监控端和调度端发送的指令。h) 系统应提供基本报表查询，包括路单查询、发车计划查询、配车排班计划查询、车次查询、驾驶员考勤记录查询、驾驶员工时查询和车辆故障信息查询。i) 可存储查询第三方外设提供的其他运行数据：客流数据、票款数据和投币票箱的开关门数据。7.1.4.8实时调度管理a) 系统应能同时调度4条线路。b) 系统
21、应能自动加载当日的行车计划，可根据实际的情况修改行车计划形成当日的调度作业计划；c) 系统应能批量调整发车计划，对某时段内的连续的几个发车计划进行匀点、调整发车时间、发车间隔、调换发车顺序等操作。d) 系统应支持自动发车模式，按照先到先发的规则自动排队安排发车，根据线路运营车辆情况自动调整发车间隔，自动向发车信息显示屏发送发车指令。e) 系统宜自动向车载机发送发车指令，在调度系统界面上展示出设备是否已经收到指令，驾驶员是否已经查看过指令。f) 系统应支持手动发车模式，由调度人员手动安排发车次序，系统自动发送车次指令。提供一线一调、多线一调和首末站双边调度等调度模式。g) 系统应支持多种调度方法
22、，包括：全程、区间、空放、大站快车等运营调度方法，不同的调度方法生成不同类型的车次信息。h) 系统应支持通过调度界面电话列表选择车辆，实现自动拨号和语音通话。i) 系统应根据车辆到离首末站信号自动记录车次实际发车时间和运行结束时间，自动确认车次；同时提供手工完成相同功能的手段。j) 系统应自动提示没有按时发车的车辆、长时间没有完成的车次、运行过短的车次，操作人员可以在异常列表中直接进行手动发车、完成车次等操作。k) 系统应自动检测不按照计划发车的车次，车辆、人员、到离站信息与计划不匹配时，系统会自动提取。l) 系统应提供跨线调车操作，跨线路使用车辆。在进行跨线操作时可以向车辆发送跨线调车指令，
23、并且可以设定信息的发送时间。通过跨线操作指令直接切换车载设备的线路配置。m) 系统应支持非运营调度管理，包括包车、保养、维修、加油等不同的非运营方式，生成不同类型的非运营车次信息。n) 系统应提供记录故障和事故的时间、地点、原因、影响车次、损失里程、备注等信息的功能。o) 当线路出现特殊情况（如恶劣天气、大型活动等），系统应支持紧急启用预备计划，以适应特殊情况下的车辆调度。p) 系统应能记录行车计划的执行情况，所有没有执行的发车计划要记录原因，并可汇总统计。q) 系统应根据车辆的实际运行情况，生成行车记录。r) 系统应提供运营记录修改功能，支持车次补录操作。操作人员可以通过手工录入、从GPS分
24、析获取车次或从计划获取车次的方式补录遗漏车次。系统应能记录进行修改和补录操作的内容、操作人员、操作时间等信息，并能够进行相关查询。s) 系统应支持向车辆发送调度指令和其他短信息，可把常用信息保存在数据库中作为短信模板，并支持信息群发机制。t) 系统应能够接收并在调度界面上显示从车辆发来的短信息，包括路堵、事故、故障、纠纷等。u) 系统应该能够接收车辆报警信息，同时以视觉和声音告警，并记录报警信息。7.1.5驾乘人员报到和信息查询7.1.5.1应在停车场设置报到查询设备，提供下列功能：打卡和输入工号两种身份识别；签到、签退；查询发车排班计划、车次及里程记录、违规记录、加油记录。发车签点、到站签点
25、和打印单次路单。7.1.5.2宜利用车载设备进行驾乘人员签到、签退操作。7.1.5.3应设置室内、室外发车信息显示屏，发布信息包括：线路、本班发车车号和发车时间、下班发车车号和发车时间、滚动显示预设和后台临时发送的通知信息。7.1.5.4提供发车提示语音播报功能，播报待发车号和发车时间，提示驾驶员发车。7.1.6业务数据录入和查询统计分析7.1.6.1车辆收入a) 车辆收入数据录入。提供车辆收入数据录入功能。可以按天录入各种类型款的总金额。可以提供标准格式的电子表格数据导入收入数据。b) 提供车辆票款台账数据查询。查询条件：线路、时间区间、车号、票款类型；查询结果包括：日期、车号、票款类型、金
26、额。7.1.6.2车辆费用a) 车辆费用录入管理。提供车辆材料费用、维修费用和轮胎费用明细数据录入功能。可以通过标准格式的电子表格数据导入费用数据。b) 提供车辆费用台账数据查询。查询条件：线路、时间区间、车号、费用类型；查询结果包括：日期、车号、费用类型、金额。7.1.6.3车辆油耗a) 车辆油耗录入管理。提供车辆油量、油料金额、加油点明细数据录入功能。可以通过标准格式的表格数据导入油耗数据。b) 提供车辆费用台账数据查询。查询条件：线路、时间区间、车号、燃油类型；查询结果包括：日期、车号、油量、金额。7.1.6.4查询统计a) 应实现行车计划综合查询统计，生成行车计划汇总表。b) 应实现行
27、车记录综合查询统计，生成反映线路、人员、车辆等生产情况报表。c) 应实现运营生产的质量指标和数量指标进行统计d) 应实现根据当日随机时间条件查询统计行车记录。7.1.6.5综合分析a) 应实现运营生产实际完成和计划的对比分析b) 应实现运营生产指标的趋势分析。7.2安全服务监控7.2.1行车事故管理7.2.1.1提供记录车辆事故时间、线路、车辆、驾驶员、是否报案、发生位置、预估费用、事故性质、事故类型、伤亡人数、责任划分、事故概况、处理状态、结案时间、车辆维修费用、实际总费用等信息的功能。 7.2.1.2提供根据线路、车号、时间、人员等条件进行单一条件或组合条件查询车辆事故记录功能。7.2.1
28、.3提供车辆事故统计分析功能，查询条件：线路、车号、时间；查询结果包括：车号、事故类型、伤亡人数、经济损失。7.2.2安全稽查管理7.2.2.1提供安全稽查信息录入功能，记录线路、车辆、驾驶员、违规站点、违规情况、检查日期、检查人处理、安全部门处理意见、公司处理意见等信息。并提供自动采集超速、开门行车等安全违规时间、车号、驾驶员、违规类型、违规标准值、实际违规值等信息功能。7.2.2.2提供根据时间区间、车号、驾驶员、类型、违规值范围等条件进行单一条件或组合条件查询车辆安全违规和稽查情况和统计分析功能。7.2.3服务稽查管理7.2.3.1提供服务稽查信息录入功能，记录线路、车辆、违规人、违规站
29、点、违规情况、检查日期、检查人处理、服务部门处理意见、公司处理意见等信息。并提供自动采集早点、晚点、滞站、越站等服务违规时间、车号、违规类型、违规标准值、实际违规值等信息功能。7.2.3.2提供根据时间区间、车号、驾驶员、类型、违规值范围等条件进行单一条件或组合条件查询车辆安全违规和稽查情况和统计分析功能。7.2.3.3提供登记乘客意见的功能，记录：意见类型、车辆、责任人、投诉或表扬：事件摘要、乘客姓名、受理时间、乘客电话、乘客地址、是否回复、服务部门处理意见、公司处理结果、回复客户情况、审核状态。并提查询和统计分析功能。7.3票务管理7.3.1票务员排班管理7.3.1.1应提供票务员姓名、工
30、号基本信息录入、修改、查询功能。7.3.1.2应能对票务员班次、线路号、值班车站（或车号）进行设定，可批次设定，支持一站（或一车）配备多个售票员。可导入电子表格排好的班次文件，也可将排好的班次文件导出为电子表格。7.3.1.3可按照日期、线路、班次、车站（车号）查询排班结果，并可打印查询的排班结果。7.3.1.4应能按照不同行车日、线路、班次、车站（车号）设定计划售票指标。7.3.1.5应能设置配票单号。7.3.2票库管理7.3.2.1应能设定车票的面值，可按照车票面值种类对车票进行入库管理，登记入库的车票，并自动修改票库库存数，可查询、审核入库结果。7.3.2.2应能按照车票面值种类对车票进
31、行配出管理，支持以票务室、班组为单位进行配票。配票时可实时查看票务中心库存、票务室库存。支持在不同的票务室、班组调票的功能。7.3.2.3应能按日、月、年进行票数、金额的结算，并可查询及打印结算结果。7.3.3票务7.3.3.1应根据上日晚班剩余车票交回情况，配出明日所有车站（或配班车辆）的车票。7.3.3.2应支持按照配票单从票库中提取车票的操作。配票单应记录使用日期、组号、票号、各种票面的张数、总张数、金额等信息。配票单编号从系统设置中自动提取，系统应能自动生成当前配票单的序号，配票单中应能区分上日剩余配票和当日新增配票的多个组号和票号，配票单中应能通过人工设置和系统设置记录配出车票使用日
32、期和配票工作日期。应根据记录结果打印配票单。7.3.3.3应根据调度中心次日的配班结果，自动打印出票袋领取登记表，并可录入票袋领取登记表中人工填入的内容，包括领票人的姓名和时间。7.3.3.4应能打印库存汇总表，打印票袋配出统计表。7.3.3.5应根据票务员回收各班次售票员所交回的配票单中的票款数，进行收票记录操作，记录售出票数和票款。7.3.3.6应具有校验功能，能够对库存、售出、剩余的车票张数和票款数据进行校验。7.3.4票务统计分析7.3.4.1应能汇总当天、当月、全年各个车队、班组按票面分类的剩余车票数、售出车票数和票款。此功能也可对应到售票员，当售票员更换车站或车辆时，数据应跟随记录
33、。应根据汇总结果自动打印车票配售分记帐、车票存售日报表。7.3.4.2应能自动将每月票款收入累计并汇总为全年票款收入。可将每个班组当月票款计划与实际票款收入对比，计算兑现率、超亏数额；可将售票员当月票款计划与实际票款收入对比，计算兑现率、超亏数额；可将线路当月票款计划与实际票款收入对比，计算兑现率、超亏数额；可将车队当月票款计划与实际票款收入对比，计算兑现率、超亏数额。可查询、打印上述分析结果。7.3.4.3可按票务员、售票员查询按月份或按任意选定日期的票款完成情况。可对查询结果进行保存和打印。7.4电子售检票7.4.1总体功能要求7.4.1.1宜采用与轨道交通类似的电子售检票体系，将售检票系
34、统置于公交枢纽或候车站台外，在公交车辆进站前完成售票和检票，对不具备站台检票条件的线路，可在车上刷卡检票。7.4.1.2应全面支持北京市政公交“一卡通”系统所规定的票制、卡读写器、票卡片及应用系统的功能和技术要求，能够通过BRT智能系统的网络实时地联机采集、传输、统计IC卡检票信息。7.4.1.3应为BRT智能系统中的运营调度功能子系统提供客流数据采集接口，能实时采集BRT线路各站的检票（客流）信息。7.4.1.4在调度中心应能实现票务数据的存储和传送功能，能将各车站实时上传的票务数据以及人工采集的票务数据，按照设定的传输间隔，实时地上传至上级单位或一卡通中心，同时实时地下载上级单位或一卡通中
35、心下发的参数和业务数据。应能实现断点重传，确保数据的完整性和一致性。7.4.2售票和充值7.4.2.1IC卡的售卡、充值可在北京市统一设置的售卡充值点进行，也可以在空间条件允许的BRT车站设置售卡充值点。7.4.2.2售票、充值业务的计算机应通过专用网络来连接，不应接入BRT智能系统的网络。7.4.3检票7.4.3.1当在站台完成检票时，应在站台上设置IC卡刷卡机，刷卡机内安装IC卡读写器，乘客在站台完成IC卡检票。刷卡机的安装数量应与车站的客流量相适应，每个进出通道应设置不少于2台刷卡机。刷卡机的设置应充分考虑到乘客刷卡的方便性，要有保护装置，能防雨、防尘。刷卡机的数字显示应清晰，应有应对光
36、反射的措施，刷卡机提示声音的大小应可调。7.4.3.2当需要在车上设置IC卡刷卡机时，乘客可在上车时刷卡检票。车载刷卡机的存储空间应充分考虑到BRT线路大客流量产生的交易数据的存储要求。宜采用通过无线传输方式将车载验票机的数据实时传送至调度中心。车载IC卡刷卡验票机应支持人工手持设备采集票务数据，手持设备采集的数据在调度中心通过专用接口传入中心系统。7.4.3.3应在站台配备适当数量的手持式或其他形式的移动式IC卡刷卡机。每个车站应配备不少于一台移动式IC卡刷卡机。7.4.3.4站台设置的IC卡刷卡机应通过专用接口与站台IC卡前端计算机系统相连接。IC卡前端计算机系统应实现的功能包括：连接的I
37、C卡读写器数据的实时采集，连接的IC卡读写器参数的自动下载和设置，IC卡手持读卡设备的数据采集、参数下载和设置，IC卡交易数据的本地缓存，IC卡交易数据的上传。7.4.4中心系统7.4.4.1应在BRT调度中心配备IC卡售检票的中心系统。中心系统应具备能实时采集各车站IC卡前端计算机系统或车载系统的实时交易数据，参数下载和下发、实时客流生成及查询、IC卡数据结算、统计和查询功能。7.4.4.2中心系统应向BRT智能系统提供实时信息采集接口。采集接口应能采集以下数据：详细的交易结算数据、统计数据、实时客流数据。7.5乘客信息服务7.5.1站台信息服务7.5.1.1可利用电子站牌、服务信息显示屏、
38、广播等等各种电子媒体为候车乘客提供车辆到站预报、进出站提示等出行导乘信息和其它公共服务信息。7.5.1.2LED显示屏发布的公共服务信息分为预设信息和即时信息，预设信息定时滚动播放，即时信息立刻显示，滚动播放频率和即时显示的时间长度可以配置。7.5.1.3应支持多线路服务信息发布，线路数量可根据需要进行扩展。7.5.1.4应提供距离本站最近的三辆车的动态位置信息，精度为0.5倍站距。7.5.1.5应提供下一班车所属的线路名称、开往的终点站、到达本站的时间长度，时间长度精确到1分钟，信息更新周期不超过1分钟，车辆离站后应立刻更新预报信息。7.5.1.6应提供末班车信息提示，让乘客准确了解到末班车
39、是否已经通过本站。7.5.1.7车辆进、出站播报车辆即将进站时应以语音和文字播报进站车辆的线路名称、终点站和注意安全等相关信息；车辆出站时应播报车辆出站注意安全等相关信息；语音播报的音量应能进行定时、自动和人工调节；7.5.1.8当末班车通过本站后应在站台显示末班车已过信息。7.5.1.9其它要求（放入设备监控和系统集成中）a) 可通过短程通信模块识别车辆到离站。b) 可监控站台服务运行状态及周边外设状态。c) 可设定关机时间。d) 系统可以自动连接升级服务，检测是否有新版本可以升级，并完成自动升级。e) 系统提供运行日志,，记录程序运行过程中重要的处理过程及结果，以及异常信息。f) 可通过串
40、口或485口控制LED屏显示文字。g) 可通过串口或485口控制车辆运行位置显示牌的显示。7.5.2车上信息服务7.5.2.1提供报站信息服务a) 应在车厢内通过电子设备提供语音及文字报站和其它服务信息播报及车辆当前位置显示服务。b) 车辆在进入站点前30米80米范围内，开始播报到站信息，距离可以设置。c) 车辆在离站后播报下一站的站点信息。离站距离可以设置，距离值精确到米。d) 在车辆运行位置显示牌上显示当前车辆的运行位置。7.5.2.2提供服务用语音播报，服务用语分为定点播放和即时播放。注：定点是指固定地点，如在右转弯处，会播报站稳扶好；即时播放是靠驾驶员通过车载操作手柄触发播报的。7.5
41、.2.3应支持车内LED显示屏发布公共信息。公共信息发布分为两种：预设信息和即时信息。预设信息应定时滚动播放，播放频率可设置。即时信息可接收后台发送的信息或驾驶员通过车载操作手柄触发。7.6路口公交信号优先7.6.1信号优先申请7.6.1.1优先申请信息应包括车辆ID、线路号、支线号、优先申请的方向、车辆距离路口的距离等基本信息，可提供车辆速度、发车类型、晚点与否、优先级别信息。7.6.1.2应能屏蔽同一车辆短时间内（5秒内）的重复申请，可屏蔽指定时段内的优先申请信息，不应屏蔽相同方向不同车辆的优先申请。7.6.1.3应能生成与传输信号控制器可识别的优先申请信息，应能接收与解析信号控制器的反馈
42、信息，可向优先申请车辆传输优先申请反馈信息。7.6.2信号优先控制7.6.2.1应提供本地控制的公交优先、系统监视下的公交优先等基本控制模式，可提供系统优化控制下的公交优先模式。7.6.2.2应支持调用优先、扩展优先，可支持插入相位、相位次序交换优先方法。7.6.2.3应能提供公交车辆旅行时间、公交优先申请、公交优先信号分配的实时与历史数据及相关查询、统计分析功能。7.6.2.4可与公交调度中心进行信息传输，完成调度计划与信号控制方案的双向传输。7.7场站视频监控7.7.1视频监控系统的传输要求应基于网络通信子系统的IP网络实现视频信息传输。前端监控点摄像机的视频信号或通过网络视频服务器直接与
43、网络连接，或传输至相应站台、调度中心进行编码，实现数字化视频传输。7.7.2场站视频监控的实现要求7.7.2.1网络带宽及视频存储要求7.7.2.1.1连接调度中心服务器的局域网应采用至少百兆以太网交换机，提供给每一路视频传输的带宽不少于512Kb/s。7.7.2.1.2视频传输所需的网络带宽20K2M b/s可调，视频帧率最高25fps（PAL制视频）。系统支持视频移动侦测功能，图像变化率可由客户根据实际经验设置，以保证移动侦测报警的准确性。系统支持Pelco-P和Canon协议的云台控制解码器和球机，客户可根据需要选配。7.7.2.1.3宜采用MPEG4压缩编码技术存储录像。1小时的连续录
44、像数据可控制在100M300M字节之内。针对大量录像数据，宜采用分布式存储。对于变化相对较少的地点，可采用视频移动侦测报警录像。可以在服务器中增加RAID卡连接多个硬盘，也可以选用外接的磁盘阵列。7.7.2.2安装要求7.7.2.2.1摄像机宜采用吸顶式或支架式安装，每个摄像机的安装面积不超过直径30cm的区域，重量不超过2Kg，以螺钉或螺栓进行固定。7.7.2.2.2各监控点到设备间或机柜之间将铺设755非平衡视频电缆线、五芯控制线、三芯电源线，放置在PVC管道内。7.7.2.2.3场站可铺设主管道容纳矩阵到各监控点所有的控制线、视频线和电源线，铺设分管道容纳各点到主管道的控制线、视频线和电
45、源线。7.7.2.2.4应避免冬季施工，传输线也应选择耐低温（-10 -15）的低温线。在施工时传输线要外加保护套管，可带屏蔽。电源端及设备前端应设置防雷击保护设备。7.7.2.2.5本系统设备应单独供电，配备专用UPS电源，防止雷电发生时超高压强电流通过强电系统破坏弱电系统。所有设施保证良好接地，当强电流通过时可以分散电流。室外可安装避雷针。7.7.2.2.6在车站和停车场部署摄像机（含云台、防护罩等）。7.7.2.2.7在车站和停车场设备间（含机柜、电源等）部署视频服务器和云台解码器。7.7.2.2.8铺设连接摄像头与视频服务器之间的视频线、信号控制线、电源线。7.7.2.2.9网络服务器
46、与网络交换机之间通过网线连接。7.7.3网络上安装了客户端软件的任何一台计算机均可作为监控工作站，随时对监控现场的视频图像进行浏览。前端监控点应便于扩展，有网络的地方均可设置监控点。7.7.4通过网络视频解码器硬件解压缩，可直接将模拟视频输出到大屏幕或电视墙上。7.7.5视频监控系统前端监控子系统7.7.5.1前端监控子系统的主要功能是通过摄像机和网络视频服务器将采集到的视频数字信息化，并通过网络发送到调度中心。7.7.5.2前端监控设备包括：云台及解码器、摄像机、机柜（针对室外监控点，可将视频服务器、云台解码器、电源等统一安装在里面）。7.7.6视频监控系统后端监控子系统7.7.6.1后端监控子系统应实现对前端监控点传输过来的网络视频数据进行有效的管理和组织，为监控人员提供察看、控制和管理监控点图像的界面。所有授权用户可通过局域网上任一台监控工作站计算机登录到服务器系统，根据不同权限完成对图像的监视、查询、录像回放等功能。7.7.6.2后端监控子系统组成：调度中心设备应包括：网络视频解码器、视频服务器、电视墙或大屏幕投影仪、调度监控工作站以及视频切换
