项目需求说明
标包一:城市交通治堵大数据分析系统开发项目
采购清单
序号 |
建设内容 |
数量 |
备注 |
一 |
软件开发 |
|
城市交通治堵大数据分析系统开发 |
1 |
城市交通运行状态诊断子系统 |
1 |
城市道路交通运行状态诊断、常规公交运行状态诊断、轨道交通运行状态诊断、公共自行车运行状态诊断、出租车运行状态诊断、停车运行状态诊断、居民出行运行状态诊断、科技治堵报表等 |
2 |
拥堵成因综合分析子系统 |
1 |
交通流特征分析、公交设施与出行需求匹配分析、公交与小汽车出行效率分析、区域拥堵分析、快速路分析等 |
3 |
治堵措施实施效果评估子系统 |
1 |
治堵效果评估指标管理、治堵措施评估等 |
二 |
数据建设 |
|
|
1 |
数据采集与共享 |
1 |
数据采集、数据共享等,含车辆GPS数据、公交IC数据、自行车数据、用户出行轨迹等数据采集实施,以及城市交通治堵大数据分析系统和交通工程协同监管子系统的数据共享实施 |
2 |
数据库设计 |
1 |
元数据库、业务数据库、拥堵指标数据库和若干专题库等 |
3 |
数据处理分析 |
1 |
数据清洗、转换、一致性校验、数据加密、数据挖掘等 |
4 |
数据管理 |
1 |
元数据管理和维护、数据安全与权限管理、数据质量监管等 |
三 |
模型建设 |
1 |
公交出行OD模型、小汽车出行OD模型、非机动车出行OD模型、小汽车路径识别模型、常规公交及轨道交通客流路径识别模型、出租车客流OD模型、职住分析模型等 |
四 |
数据购买 |
1 |
宁波绕城高速范围内(含绕城高速)用户出行轨迹等数据(购买2021年1月至2022年12月数据,每月至少更新一次) |
五 |
其它 |
|
|
1 |
测评费 |
1 |
负责支付城市交通治堵大数据分析系统(标包1)和交通工程大数据监管系统(标包2)的等保测评、软件测评、安全测评等测评费用,并配合做好标包1的测评工作。若标包1测评结果未达到等保要求,投标单位必须根据测评结果进行整改,直到通过测评。费用包含在投标报价中。 |
2 |
项目培训 |
|
|
预算为511万元,超过该预算的投标文件作无效标处理。
本次招标接受联合体投标。若以联合体形式投标,联合体成员不超过两家。投标时提供联合体协议。协议中组成联合体的两家单位自行约定牵头单位、明确各自的项目实施范围。
未提交联合体协议的投标文件作无效标处理。
中标单位不允许转包、分包。
各投标单位根据对城市交通治理工作的理解,在满足需求的基础上,可增加其他内容。
投标方需设计城市交通治堵大数据分析系统和交通工程大数据监管系统的界面模板,并将模板提供给交通工程大数据监管系统的中标单位,以保证标包1和标包2的界面风格保持一致。投标单位应对此作出无推诿承诺,及相关的配合工作。
1、项目概述
1.1项目背景
2019年12月,交通运输部印发《推进综合交通运输大数据发展行动纲要(2020—2025年)》,要求政务大数据有效支撑综合交通运输体系建设,交通运输行业数字化水平显著提升。2019年4月,省政府印发《2019年全省治理城市交通拥堵工作要点》,明确提出:坚持依托大数据发展智慧交通,推广应用“城市大脑”,推进城市交通运行指数系统应用于治堵政策的制定与后评估。2020年8月,中共宁波市委、宁波市人民政府发布《关于建设高水平交通强市的实施意见》,明确提出要深化应用智慧交通,完善交通智慧云服务,实现集成分析、集成控制、集成智慧,打造“交通慧眼”。2019年6月,根据沈敏副市长6月6日在听取城市治堵工作汇报中的讲话精神,市治堵办又会同相关部门就建设城市交通大数据分析平台进行了专题研究,在7月23日向沈市长提交《关于建设宁波市城市交通大数据分析平台一期项目的报告》,沈市长批示请市财政局予以支持安排。城市交通大数据分析平台建设实现数字技术和政府履职的全面深度融合,充分利用大数据、物联网等先进技术,全面提升以大数据为支撑的政府决策科学化、治理精准化、服务便捷化水平,聚焦城市交通治堵与交通工程质监,未来可能对该系统进行进一步拓展延伸,打造面向整个交通行业的数字化应用体系,推进数字化技术与政府履职的深度融合。
1.2建设目标
1.2.1项目总体目标
按照《浙江省人民政府关于印发浙江省深化“最多跑一次”改革推进政府数字化转型工作总体方案的通知》和《宁波市人民政府关于印发宁波市深化“最多跑一次改革”推进政府数字化转型三年行动计划(2019-2021年)的通知》文件精神,加快交通政府部门数字化转型。城市交通大数据分析平台依托智慧交通一期的底层框架,融合利用城市大脑(宁波市大数据中心平台)资源,深化拓展智慧交通一期应用,包含“城市交通治堵大数据分析系统”和“交通工程大数据监管系统”两大业务应用系统。本项目建设内容为城市交通治堵大数据分析系统,利用大数据破解城市拥堵治理难题,实现科技治堵考核指标的自动计算,支撑诊断-分析-评估业务流程,为治堵措施制定提供科学依据。
1.2.2业务目标
通过城市交通治堵大数据分析系统建设,破解城市拥堵治理难题,具体实现以下业务目标。
——利用信息技术实现道路拥堵指数、常规公交运行特征、轨道交通运行特征、常规公交、轨道交通与公共自行车(含共享单车)的接驳情况等治堵考核指标的自动计算和展示;
——利用经信、规划、交通、城管、交警等政务数据,以及用户出行轨迹等多源大数据进行分析,掌握人和车的OD与路径,校验后的准确率不低于80%,挖掘造成城市交通拥堵的原因;
——分析出行需求和公共交通供给的匹配程度,发现公交线路布局的缺陷,为公交线网优化,提高公共交通服务水平,优化出行结构服务;
——对治堵措施的效果进行后评估。
1.3建设范围
城市交通治堵大数据分析系统的建设单位为市交通运输局,主要应用单位为市治堵办,服务单位还包括市自然资源和规划局、市住房和城乡建设局、市交通运输局、市综合行政执法局、市公安局交通警察局等部门。建设范围包括主城区范围内城市交通治堵工作。
1.4主要建设内容
项目主要建设内容包括城市交通治堵大数据分析系统软件开发、数据建设、模型建设和数据购买等。城市交通治堵大数据分析系统,从相关主管单位接入城市路网、常规公交、轨道交通、公共自行车、共享单车、出租车、网约车、停车等领域的动静态信息,结合由手机信令或互联网公司数据分析得到的居民出行特征信息,实现对宁波市城市交通运行状态的诊断,以及出行OD和路径的溯源分析;通过分析公共交通供给与出行需求的匹配关系,对比公共交通和小汽车出行的效率,判断重点区域拥堵特征,实现对造成城市拥堵原因的挖掘;建立评价指标体系,分析缓堵措施实施前后交通拥堵情况,实现对缓堵措施效果的科学评估。
数据建设,完成数据采集与共享,实现数据采集接口、信息填报等功能开发,完成车辆GPS、公交IC卡数据、自行车数据等采集实施,以及居民出行特征、常规公交出行特征等数据的共享实施;完成数据处理分析,对数据进行清洗、转换、一致性校验、加密和挖掘等;完成数据管理,完成元数据管理和维护、数据安全与权限管理、数据质量监管等功能。
模型建设,建立公交出行OD模型、小汽车出行OD模型、非机动车出行OD模型、小汽车路径识别模型、常规公交及轨道交通客流路径识别模型、出租车客流OD模型、职住分析模型等交通模型。
数据购买:购买2021年1月至2022年12月宁波绕城高速范围内(含绕城高速)用户出行轨迹等数据(例如手机信令、互联网用户数据等),更新频率每月至少一次。投标单位在投标文件中应当明确购买的数据内容、年限、更新频率、维度、颗粒度(精度)、数据量等。
2、智慧交通一期项目建设现状
2.1智慧交通一期项目建设成果
(1)初步建立宁波交通大数据资源体系。目前,宁波交通信息资源整合单位数量和数据规模达到国内一流水准,实现了智慧交通谋划要求。依托智慧交通信息采集与感知网络平台的建设,一方面在更深程度上整合高速公路、“两客一危”、公交、公共自行车、出租车等交通运输系统内部数据;另一方面在更大范围内整合轨道、交警、城管、市民卡、气象等系统外单位数据。目前宁波智慧交通一期全量历史数据和实时数据均存储在市政务云计算中心,数据总量达到940亿条,日平均增长约1.4亿条,数据总规模达9.5T,日平均增长10.1G。已形成公铁水空一体的交通感知网络,共接入12054辆“两客一危”车辆、20794辆集装箱卡车、6544辆公交车、6245辆出租车、16470辆网约车、38694辆公共自行车、29187艘船舶、9184个公交站点、655条公交线路、2条轨道交通线路、1363个公共自行车网点、647个停车场、1个国际机场、6座铁路客运站、97个交通流量观测站,105套公路治超电子检测系统、13207路视频监控等交通资源,基本实现了重要路段、大型站点、特大桥隧、综合枢纽等基础设施以及交通运输工具的实时监测。
(2)实现“地理信息一张图”。与市规划局合作,以“天地图”为基础,围绕交通地理信息应用服务需求,以地理信息资源整合为核心,以应用服务为主线,开展交通特色需求专项测绘,进一步完善交通地理信息数据资源,构建了全市交通“一张图”。
(3)建立一体化智慧交通出行服务体系。涵盖公交、地铁、出租、公共自行车、长途客运、城市道路、主要国省干线公路等领域交通信息服务,建成包含网站、宁波通APP和微信公众号等公共信息服务渠道,为市民出行提供综合交通信息服务。
2.2智慧交通一期应用情况
宁波市智慧交通一期通过物联网、人工智能、云计算、大数据等技术,全面提升交通运输管理能力和服务水平,促进交通行业转型升级。在公众出行信息服务方面,早在2013年宁波市即发布“宁波通”APP,其集成了实时公交、轨道交通、公共自行车和出租车电召等20余项综合出行服务功能。随后市交通局顺应互联网发展趋势,推出和“宁波交通运输”微信公众号,目前,“宁波通”APP累计下载数量已破335万,注册用户数80万,日均活跃用户数50万,日均查询次数超200万;“宁波交通运输”微信公众号关注用户数达到11万,日均活跃用户数2万。通过公众出行服务系统的建设,市区公共汽电车信息实时预报率达到100%。2019年6月底,宁波通APP已整合至全省掌上办事统一入口“浙里办”APP,方便了老百姓集中获取政府各部门提供的各类服务。根据国家信息中心大数据发展部和高德地图等机构发布的中国主要城市交通分析报告显示,宁波在2019年第二季度和第三季度全国主要城市定公交出行幸福榜中均排名第一。在服务行业治理方面,初步构建了省市县三级交通运输部门联网协同的互联网行政审批服务体系和公路、运管等市县两级监控中心和应急指挥系统。实现了高速公路、国省道干线公路、城市重要道路、大型桥梁、综合枢纽等重要基础设施以及“两客一危”、公交、出租车、公共自行车、地铁等运输装备的实时监测,日常通行和应急保障能力明显提高。
3、业务系统功能需求
3.1平台总体架构
图3-1 城市交通大数据分析平台总体框架图
3.2城市交通治堵大数据分析系统业务需求
各投标单位根据业务需求,提出业务应用系统建设方案。业务应用系统建设方案需具有普适性和可拓展性,以便将来在此基础上进行新的业务功能开发。
3.2.1城市交通运行状态诊断子系统
城市交通运行状态诊断模块综合规划、建设、交通、城管、交警等各部门的交通系统检测数据,以及用户出行轨迹等数据,分项监测各交通子系统的运行特征,诊断交通堵点,并分析市民的职住与出行特征。通过对不同领域交通出行特征进行诊断,为管理部门提供月报、季报,指导和协调治堵办各成员单位提出整改措施及开展治堵工作。所存储的数据或产生结果应能支撑拥堵成因综合分析模块与治堵措施实施效果评估的使用。
城市交通运行状态诊断子系统包含城市道路交通运行状态诊断、常规公交运行状态诊断、轨道交通运行状态诊断、公共自行车运行状态诊断、出租车运行状态诊断、停车运行状态诊断、居民出行需求分析和科技治堵报表自动生成等8个子功能模块,具体划分为道路交通、公共交通、停车、居民出行需求等四大类。道路交通运行状态诊断模块的建设重点为机动车溯源分析,包括机动车出行OD和出行路径分析。公交监测模块的建设重点为公交OD分析、常规公交车速与正点率监测、公交换乘分析等。居民出行需求监测模块是本系统的基础核心模块之一,主要功能为居住地与工作地关联OD分析、全方式及分方式出行OD分析、居民出行结构分析、各方式出行效率分析与对比等。
1. 城市道路交通运行状态诊断
检测诊断快速路、干线路网的运行状态与拥堵节点,其中快速路分为匝道、立交、基本路段三类,干线路网分为主干路与次干路。
分析与展示机动车出行OD、同时在途机动车数量、机动车出行数量与保有量的比值等。
2. 常规公交运行状态诊断
检测与诊断常规公交运行车速,包括公交线路车速排名;公交站间车速监测与评估;公交线路特定时段所有班次行程时间算术平均值与同线路社会车辆通行时间的比值;公交专用道公交线路车速与社会车辆车速的对比等分析功能。
检测与诊断常规公交运行正点率,包括公交线路首末站正点率(发车正点率、到站正点率、综合正点率)排名、公交线路首末班次到达沿线各站点正点率、公交线路所有班次的沿线各站点稳定性等分析功能。
检测与诊断常规公交设施建设,包括公交线网密度、公交站点300米与500米覆盖率、公交车辆万人拥有率、公交车均场站面积、非直线系数、公交专用道设置比例等指标的统计功能。
常规公交客流分析功能,包括公交线路/站点客流监测与评估、常规公交线路客流OD分析与展示等功能。
常规公交与地铁的接驳分析,包括单条轨道线路并站分析、轨道网络与公交并线情况分析等功能。
3. 轨道交通运行状态诊断
检测与诊断轨道交通客流特征,包括站点客流、轨道换乘客流、各时段客流的变化、轨道客流OD等分析功能。
检测与诊断轨道交通客流时空特征,包括轨道交通出行距离、轨道交通出行时耗、轨道站点的客流服务范围等统计功能。
检测与诊断轨道交通利用效率,包括轨道站点利用效率、轨道区间线路利用效率、轨道站点接驳效率等分析功能。
4. 公共自行车运行状态诊断
检测与诊断公共自行车(含共享单车)客流特征,包括公共自行车站点借还车特征、各时段客流的变化、公共自行车(含共享单车)OD等分析功能。
公共自行车(含共享单车)出行时空分析,包括出行距离监测与评估、公共自行车(含共享单车)出行时长监测与评估等功能。
检测与诊断公共自行车设施利用效率,包括公共自行车站点利用率与公共自行车站点服务效率。
检测与诊断非机动车与常规公交和轨道交通的接驳情况。
5. 出租车运行状态诊断
出租车客流时空分析,包括出租车客流源空间分布、出租车客流时间分布、出租车客流OD、出租车路径等特征分析,以及出租车车速数据挖掘分析。
6. 停车运行状态诊断
检测与诊断公共停车场和路侧停车泊位的周转率、停放时长与停车设施运行状态。
7. 居民出行需求分析
综合关联信令数据或互联网企业的个人位置数据、公交线路数据、道路流量数据分析城市人口与岗位分布、居住地与工作地的关联矩阵、全方式及分方式出行OD、人口随时间动态演变过程、居民出行时间特征、居民出行路径、居民出行结构、公交分担率、各方式出行效率分析与对比等内容。
8. 科技治堵报表自动生成
根据治堵考核任务书和科技治堵任务数据要求,利用信息系统实现对考核指标的自动计算和监测,对超出预警范围的指标实现自动预警。
通过交通大数据分析与评估,产生最堵20条道路车速排名、最堵20个路口排名、最大20个高架匝道流量排名、前后20名常规公交线路车速排名、前后20名常规公交线路正点率排名、常规公交首末班最准点20条线路和最不准点20条线路、特定20条提速线路的速度报表、主干道上常规公交与同线路社会车辆车速比值最大20条和最小的20条线路、高峰时段轨道站点进出客流量最大的前20个站点及客流量、各轨道交通线路末班最大出站客流站点的客流量及时段、常规公交与地铁的接驳分析、轨道网络与公交并线情况、非机动车与常规公交和轨道交通接驳情况、常规公交线路行程时间与同期同线路社会车辆的行程时间对比、大型停车场周转率、常规公交正点率;早晚高峰时段常规公交平均运营车速、公共交通乘车一卡通使用率等交通运行指标汇总的城市交通月度报告。
3.2.2拥堵成因综合分析子系统
通过多源数据的关联与交通需求溯源分析,采用定量化方法,挖掘各类交通问题或交通拥堵背后的原因,从数据分析方面服务各部门开展交通治堵研究与优化建设工作。拥堵成因综合分析子系统包括5个子功能模块,具有三类业务功能,包含交通流特征分析、公交设施的问题分析、交通拥堵区域或节点的拥堵原因及交通需求溯源分析。交通流特征分析模块是其他分析模块的基础,包括机动车、公交车等各交通方式的流量分析、各方式路径分析与展示、客运廊道、交通异常拥堵节点等分析功能。公交设施的问题分析模块服务于公交设施的优化,包括公交设施与需求匹配分析、公交与小汽车出行效率分析。其中,公交设施与需求匹配分析的目的是评估常规公交和轨道线网与居民出行OD的匹配程度,包含直达率和一次换乘率等指标。公交与小汽车出行效率分析从出行时耗与出行距离方面,对比分析公交出行的缺陷,服务于公交系统与出行结构的优化。交通拥堵区域或节点的拥堵原因分析模块服务于综合交通拥堵治理,包含区域拥堵分析、快速路分析等。具体分析指标包括交通运行特征、出行结构、停车、交通溯源等。这些模块还须具备用户交互功能,系统可根据用户自定义的区域或节点自动分析。
1. 交通流特征分析
使用城市交通运行状态诊断子系统的机动车、公交车、非机动车的OD数据,采用交通流分配的方法,以现状的流量、车速数据为基准,预测并分析三种交通方式的流量和路径,具体包括计算道路网中各路段在各时间段中的机动车流量、评估道路的服务水平、计算公交站点、公交线路、路段在各时段的公交乘客量、评估公共交通的服务水平以及车辆的满载率。
机动车、公交车、非机动车等三种交通方式的路径分析与展示功能,此功能需自动计算、存储路径结果。结果的展示需具有交互功能,用户可选择路段、或自定义区域,系统根据用户需求展示每个路段或范围内的统计结果。
客运走廊分析功能,采用全、分方式OD及人流量的分配结果,分析重点区域或自定义区域的主要客流走廊,结果可分别以路段或路径为基础展示。
交通异常分析功能,采用路段车速、交叉口排队长度、交通流量、路段车道数、路口进口道数,分析交通运行经常存在异常的点位,比如交通流量不大,但是车速很低路段或排队长度很长的路口。
2. 公交设施与出行需求匹配分析
采用直达率、一次换乘率等指标分析常规公交线路和地铁线路与出行需求的匹配程度。采用接驳距离、服务范围、时间衔接、接驳客流等指标评估为地铁接驳的公交设施和公共自行车设施的衔接效率。
3. 公交与小汽车出行效率分析
采用出行时间比和出行距离比等指标,对比分析各区域之间的公交出行效率的差距,并对比出行效率与出行结构。分析应基于被使用的路径和线路统计,包含最大值、最小值、平均值等。分析功能需细化到交通小区,分析的时间区间应包括早高峰、晚高峰、平峰与全天。
4. 区域拥堵分析
基于监测与分析数据,对于重要的区域或自定义的区域,采用交通溯源的方法,从出行需求方面分析区域交通拥堵的原因,分析指标需包含本区域职住矩阵、相关的出行OD、内部及周边交通运行特征、出行距离、时耗、出行结构、出行路径、客运走廊、公交设施与本区域出行需求的匹配程度、公交与小汽车出行时间及距离之比。该功能须自动分析3-5个区域,还应具备自定义区域分析的功能。
5. 快速路分析
针对宁波市已建设的快速路和规划的快速路通道,分析沿线及匝道的交通需求,分析指标需包含全天及高峰OD、各断面全天及高峰流量、行程距离、行程时间、各匝道的服务范围与路径等。
3.2.3治堵措施实施效果评估子系统
治堵措施实施效果评估子系统建立结合各类缓堵措施实施计划,对比实施前后路网运行数据,包括平均速度、路网流量、交通指数、出行OD与路径、出行结构、各方式的出行时耗等,评估措施实施的成效。应具有交互功能,用户可自定义区域和编辑优化方案。
3.3系统管理
实现用户、机构、角色、权限、菜单等人员和功能的管理。
(1)用户管理
用户管理提供用户的添加、修改、删除、启用、禁用、重置密码等功能。每个用户可拥有不同的权限,属于不同的机构。通过角色设置可控制用户能访问哪些模块和功能。通过机构设置可控制用户能哪些数据的资源。
可在用户管理中对账号的密码进行重置。
(2)机构管理
机构管理可添加不同级别的机构信息,例如总公司、分公司、车队等。这些机构可在各模块功能的筛选中应用。
(3)角色管理
角色管理可为不同级别的用户设置不同的角色。每个角色拥有不同的访问权限。
(4)权限管理
权限管理通过设置不同的功能访问权限,达到控制账号权限的功能。
4、系统部署和支撑平台要求
系统部署在城市大脑(宁波市大数据中心平台),应集约化利用城市大脑(宁波市大数据中心平台)提供的工具组件和资源能力进行开发。本项目涉及地理信息相关内容,应利用宁波时空信息云平台提供的服务,包括全市统一的空间基础数据、GIS空间数据服务、空间分析功能服务和应用开发API接口等。以上服务属于宁波时空信息云平台免费内容,无需投标人另行采购。本项目系统应支持国产和非国产响应。
4.1系统部署
投标单位根据实际业务需求,估算所需资源,选择城市大脑(宁波市大数据中心平台)资源清单内的产品,设计系统部署方案,所需产品无需投标人另行采购。列出所需资源清单和系统部署架构图,资源清单格式可参考城市大脑(宁波市大数据中心平台)资源申请表的形式填列。
系统部署方案包括服务器性能、存储容量、备份容量、网络带宽和安全服务需求、数据库资源以及其他配置说明。城市大脑(宁波市大数据中心平台)提供资源表和城市大脑(宁波市大数据中心平台)资源申请表如下所示:
表4-1城市大脑(宁波市大数据中心平台)资源表
产品类别 |
产品子类 |
产品名称 |
采购规格(单位) |
计算服务 |
弹性计算 |
云服务器(ECS) |
1核1G |
1核2G |
|||
1核4G |
|||
1核8G |
|||
2核4G |
|||
2核8G |
|||
2核16G |
|||
4核8G |
|||
4核16G |
|||
4核32G |
|||
8核16G |
|||
8核32G |
|||
8核64G |
|||
12核48G |
|||
16核32G |
|||
16核64G |
|||
16核128G |
|||
32核64G |
|||
32核128G |
|||
GPU云服务器 |
4核30G,1 * NVIDIA P100 |
||
8核60G, 1 * NVIDIA P100 |
|||
8核60G, 2 * NVIDIA P100 |
|||
16核120G, 2 * NVIDIA P100 |
|||
28核112G, 1 * NVIDIA P100 |
|||
56核224G, 2 * NVIDIA P100 |
|||
块存储-高效云盘 |
GB |
||
块存储-SSD云盘 |
GB |
||
容器服务 |
容器服务(ACS) |
ECS节点 |
|
存储服务 |
对象存储服务 |
对象存储(OSS) |
存储容量包规格:40GB |
存储容量包规格:100GB |
|||
存储容量包规格:500GB |
|||
存储容量包规格:1TB |
|||
存储容量包规格:2TB |
|||
存储容量包规格:5TB |
|||
存储容量包规格:10TB |
|||
存储容量包规格:20TB |
|||
存储容量包规格:50TB |
|||
存储容量包规格:100TB |
|||
存储容量包规格:200TB |
|||
存储容量包规格:300TB |
|||
存储容量包规格:500TB |
|||
超出存储容量包:GB/小时 |
|||
流量包规格:50G |
|||
流量包规格:100G |
|||
流量包规格:300G |
|||
流量包规格:500G |
|||
流量包规格:1TB |
|||
流量包规格:2TB |
|||
流量包规格:10TB |
|||
流量包规格:30TB |
|||
流量包规格:50TB |
|||
流量包规格:100TB |
|||
流量包规格:300TB |
|||
流量包规格:500TB |
|||
超出流量包:GB |
|||
文件存储服务 |
文件存储(NAS) |
存储容量包规格:100GB |
|
存储容量包规格:500GB |
|||
存储容量包规格:1TB |
|||
存储容量包规格:5TB |
|||
存储容量包规格:10TB |
|||
存储容量包规格:30TB |
|||
存储容量包规格:50TB |
|||
存储容量包规格:100TB |
|||
存储容量包规格:200TB |
|||
存储容量包规格:300TB |
|||
存储容量包规格:500TB |
|||
存储容量包规格:1PB |
|||
超出容量包:GB/小时 |
|||
表格存储服务 |
表格存储(OTS) |
容量型存储容量包规格:1TB |
|
容量型存储容量包规格:4TB |
|||
容量型存储容量包规格:8TB |
|||
容量型存储容量包规格:10TB |
|||
容量型存储容量包规格:40TB |
|||
容量型读CU容量包规格:10亿 |
|||
容量型读CU容量包规格: 20亿 |
|||
容量型读CU容量包规格: 40亿 |
|||
容量型读CU容量包规格: 80亿 |
|||
容量型读CU容量包规格: 100亿 |
|||
容量型读CU容量包规格: 200亿 |
|||
容量型读CU容量包规格: 400亿 |
|||
容量型写CU容量包规格: 10亿 |
|||
容量型写CU容量包规格: 20亿 |
|||
容量型写CU容量包规格: 40亿 |
|||
容量型写CU容量包规格: 80亿 |
|||
容量型写CU容量包规格: 100亿 |
|||
容量型写CU容量包规格: 200亿 |
|||
容量型写CU容量包规格: 400亿 |
|||
超出容量型存储资源包:GB/小时 |
|||
超出容量型读CU资源包:万CU/小时 |
|||
超出容量型写CU资源包:万CU/小时 |
|||
高性能型存储容量包规格:1TB |
|||
高性能型存储容量包规格:4TB |
|||
高性能型存储容量包规格:8TB |
|||
高性能型存储容量包规格:10TB |
|||
高性能型存储容量包规格:40TB |
|||
高性能型读CU容量包规格:10亿 |
|||
高性能型读CU容量包规格:20亿 |
|||
高性能型读CU容量包规格:40亿 |
|||
高性能型读CU容量包规格:80亿 |
|||
高性能型读CU容量包规格:100亿 |
|||
高性能型读CU容量包规格:200亿 |
|||
高性能型读CU容量包规格:400亿 |
|||
高性能型写CU容量包规格:10亿 |
|||
高性能型写CU容量包规格:20亿 |
|||
高性能型写CU容量包规格:40亿 |
|||
高性能型写CU容量包规格:80亿 |
|||
高性能型写CU容量包规格:100亿 |
|||
高性能型写CU容量包规格:200亿 |
|||
高性能型写CU容量包规格:400亿 |
|||
超出高性能型存储资源包:GB/小时 |
|||
超出高性能型读CU资源包:万CU/小时 |
|||
超出高性能型写CU资源包:万CU/小时 |
|||
网络服务 |
虚拟专网(vpc) |
专有网络(VPC) |
实例 |
弹性公网IP(EIP) |
实例 |
||
带宽费:1Mbps |
|||
带宽费:2Mbps |
|||
带宽费:3Mbps |
|||
带宽费:4Mbps |
|||
带宽费:5Mbps |
|||
带宽费:6 Mbps及其以上 |
|||
NAT网关 |
规格1:小型 |
||
规格2:中型 |
|||
规格3:大型 |
|||
公网IP数:个 |
|||
带宽费:1Mbps |
|||
带宽费:2Mbps |
|||
带宽费:3Mbps |
|||
带宽费:4Mbps |
|||
带宽费:5Mbps |
|||
带宽费:6 Mbps及其以上 |
|||
高速通道 |
规格1:同region |
||
规格2:跨region |
|||
软件负载均衡 |
负载均衡(SLB) |
计费项1:实例 |
|
带宽费:1Mbps |
|||
带宽费:2Mbps |
|||
带宽费:3Mbps |
|||
带宽费:4Mbps |
|||
带宽费:5Mbps |
|||
带宽费:6 Mbps及其以上 |
|||
数据库服务 |
关系型数据库服务 |
云数据库RDS MySQL版(RDS for MySQL) |
1核1G(共享型,连接数300) |
1核2G(共享型,连接数600) |
|||
2核4G(共享型,连接数1200) |
|||
2核8G(共享型,连接数2000) |
|||
4核8G(共享型,连接数2000) |
|||
4核16G(共享型,连接数4000) |
|||
8核16G(共享型,连接数4000) |
|||
8核32G(共享型,连接数8000) |
|||
16核64G(共享型,连接数16000) |
|||
16核96G(共享型,连接数24000) |
|||
存储空间:GB |
|||
2核16G,250GB Disk(独享型,连接数2500) |
|||
4核32G,500GB Disk(独享型,连接数5000) |
|||
8核64G,1000GB Disk(独享型,连接数10000) |
|||
16核128G,2000GB Disk(独享型,连接数20000) |
|||
4核16G,250GB Disk(独享型,连接数2500) |
|||
8核32G,500GB Disk(独享型,连接数5000) |
|||
16核64G,1000GB Disk(独享型,连接数10000) |
|||
32核128G,2000GB Disk(独享型,连接数20000) |
|||
30核220G,3000GB Disk(独占物理机,连接数64000) |
|||
云数据库RDS SQL Server版(RDS for SQLServer) |
1核2G(共享型,连接数600) |
||
2核4G(共享型,连接数1200) |
|||
2核8G(共享型,连接数2000) |
|||
4核8G(共享型,连接数2000) |
|||
4核16G(共享型,连接数4000) |
|||
8核16G(共享型,连接数4000) |
|||
8核32G(共享型,连接数8000) |
|||
16核64G(共享型,连接数16000) |
|||
16核96G(共享型,连接数24000) |
|||
存储空间:GB |
|||
2核16G,250GB Disk(独享型) |
|||
4核32G,500GB Disk(独享型) |
|||
8核64G,1000GB Disk(独享型) |
|||
16核128G,2000GB Disk(独享型) |
|||
30核220G,2000GB Disk(独占物理机) |
|||
云数据库RDS PostgreSQL版(RDS for PostgreSQL) |
1核1G(共享型,连接数2000) |
||
1核2G(共享型,连接数2000) |
|||
2核4G(共享型,连接数2000) |
|||
4核8G(共享型,连接数2000) |
|||
8核16G(共享型,连接数2000) |
|||
8核32G(共享型,连接数2000) |
|||
16核64G(共享型,连接数2000) |
|||
存储空间:GB |
|||
2核16G,250GB Disk(独享型,连接数2500) |
|||
4核32G,500GB Disk(独享型,连接数5000) |
|||
8核64G,1000GB Disk(独享型,连接数10000) |
|||
16核128G,2000GB Disk(独享型,连接数12000) |
|||
4核16G,250GB Disk(独享型,连接数2500) |
|||
4核16G,500GB Disk(独享型,连接数2500) |
|||
8核32G,500GB Disk(独享型,连接数5000) |
|||
8核32G,1000GB Disk(独享型,连接数5000) |
|||
16核64G,1000GB Disk(独享型,连接数10000) |
|||
16核64G,2000GB Disk(独享型,连接数10000) |
|||
32核128G,2000GB Disk(独享型,连接数12000) |
|||
32核128G,3000GB Disk(独享型,连接数12000) |
|||
30核220G,3000GB Disk(独占物理机,连接数4000) |
|||
NoSQL数据库服务 |
云数据库Redis版 |
规格1:标准版1G,连接数20000 |
|
规格2:标准版2G,连接数20000 |
|||
规格3:标准版4G,连接数20000 |
|||
规格4:标准版8G,连接数20000 |
|||
规格5:标准版16G,连接数20000 |
|||
规格6:标准版32G,连接数20000 |
|||
规格7:集群版16G,连接数80000 |
|||
规格8:集群版32G,连接数80000 |
|||
规格9:集群版64G,连接数80000 |
|||
规格10:集群版128G,连接数160000 |
|||
规格11:集群版256G,连接数160000 |
|||
云数据库MongoDB版(MongoDB) |
规格1:三副本共享,1核2G,连接数200 |
||
规格2:三副本共享,2核4G,连接数400 |
|||
规格3:三副本共享,4核8G,连接数1000 |
|||
规格4:三副本共享,8核16G,连接数2000 |
|||
规格5:三副本共享,8核32G,连接数4000 |
|||
规格6:三副本共享,16核64G,连接数8000 |
|||
规格7:独享,2核16G,连接数2500 |
|||
规格8:独享,4核32G,连接数5000 |
|||
规格9:独享,8核64G,连接数10000 |
|||
规格10:独享,16核128G,连接数20000 |
|||
规格11:独享,32核256G,连接数40000 |
|||
存储空间:GB |
|||
|
分布式关系型数据库企业版 |
实例规格:32核64GB |
|
实例规格:64核128GB |
|||
实例规格:80核160GB |
|||
实例规格:96核192GB |
|||
实例规格:112核224GB |
|||
实例规格:128核256GB |
|||
实例规格:144核288GB |
|||
实例规格:160核320GB |
|||
实例规格:176核352GB |
|||
实例规格:192核384GB |
|||
|
分析型数据库MySQL版(AnalyticDB for MySQL)(原ADS) |
规格1:C1:1CORE,7.5GB内存, 60GB SSD |
|
规格1:C4:3CORE,30G内存,180G SSD |
|||
规格2:C8:4CORE ,45G内存,480G SSD |
|||
规格3:C12:12CORE,60G内存,600G SSD |
|||
规格4:S8N:6CORE,120G内存,1024G SSD,12288G SATA |
|||
数据库管理服务 |
数据传输服务(DTS) |
数据同步 |
|
数据不停服迁移 |
|||
数据订阅 |
|||
数据管理(DMS) |
规格:100用户+50实例 |
||
大数据服务 |
大数据计算服务 |
大数据计算服务(MaxCompute)(原ODPS) |
计费项1:CU |
计费项1:GB |
|||
实时计算(Blink) |
CU |
||
E-MapReduce(EMR) |
CPU数 |
||
大数据搜索与分析 |
日志服务(Log Service)(原SLS) |
存储容量包:100GB |
|
存储容量包:1TB |
|||
存储容量包:10TB |
|||
存储容量包:100TB |
|||
存储容量包:1000TB |
|||
超出存储包后:GB/小时 |
|||
流量包:100GB |
|||
流量包:1TB |
|||
流量包:10TB |
|||
流量包:100TB |
|||
流量包:1000TB |
|||
超出流量包后:GB |
|||
机器学习(PAI) |
每账号 |
||
Quick BI |
初始规格:30用户 |
||
增量包:10用户 |
|||
弹性搜索(Elasticsearch) |
1核2G |
||
2核4G |
|||
2核8G |
|||
4核16G |
|||
8核32G |
|||
16核64G |
|||
GB |
|||
DataWorks |
标准版 |
套 |
|
调度资源组套餐 |
500调度任务数 |
||
1000调度任务数 |
|||
2000调度任务数 |
|||
5000调度任务数 |
|||
20000调度任务数 |
|||
50000调度任务数 |
|||
120000调度任务数 |
|||
数据集成资源组套餐 |
500集成任务数 |
||
1000集成任务数 |
|||
2000集成任务数 |
|||
5000集成任务数 |
|||
20000集成任务数 |
|||
50000集成任务数 |
|||
120000集成任务数 |
|||
数据保护套件 |
套 |
||
数据可视化 |
数据可视化工具(DataV) |
展示页面个数 |
|
中间件服务 |
微服务 |
企业级分布式应用服务(EDAS) |
20vCPU |
云服务总线(CSB) |
逻辑实例 |
||
应用监控 |
应用实时监控服务(ARMS) |
应用监控初级资源包:含150Agent |
|
应用监控中级资源包:含1200Agent |
|||
应用监控高级资源包:含9600Agent |
|||
前端监控初级资源包:含200万页面上报次数 |
|||
前端监控中级资源包:含1600万页面上报次数 |
|||
前端监控高级资源包:含12800万页面上报次数 |
|||
消息中间件 |
消息队列(MQ) |
Topic基础包:50个 |
|
Topic扩展包:10个 |
|||
消息发送基础包:1000TPS |
|||
消息发送扩展包:500TPS |
|||
消息订阅基础包:1000TPS |
|||
消息订阅扩展包:500TPS |
|||
|
Web应用防火墙服务(互联网安全服务) |
Web应用防火墙(WAF) |
规格:支持10个域名防护(限1个主域名);业务带宽30M;支持180天日志,3TB日志存储容量 |
域名补充包(包含10个域名,限1个主域名) |
|||
每增加100M业务带宽 |
|||
态势感知服务 |
态势感知 |
规格:1个虚拟机实例 |
|
DDoS流量清洗服务 |
DDoS防护(Anti-DDoS) |
规格:10G |
|
规格:共享20G |
|||
云防火墙服务 |
云防火墙 |
规格:1个虚拟机实例 |
|
主机安全服务 |
安骑士 |
规格:1个虚拟机实例 |
|
堡垒机服务 |
堡垒机 |
规格:单实例200资产,200并发 |
|
规格:单实例500资产,500并发 |
|||
规格:单实例1000资产,1000并发 |
|||
Web应用防火墙服务 |
Web应用防火墙-企业版 |
规格:1个SLB |
|
数据库审计服务 |
数据库审计 |
规格:20个数据库实例 |
|
数据脱敏服务 |
数据发现与脱敏 |
规格:20个数据库实例 |
表4-2城市大脑(宁波市大数据中心平台)资源申请表(样表)
序号 |
设备及软件名称 |
主要性能指标 |
型号 |
资源估算依据 |
数量 |
所属系统 |
1 |
|
|
|
|
|
城市大脑(宁波市大数据中心平台)资源 |
2 |
|
|
|
|
|
|
3 |
|
|
|
|
|
根据大数据中心总体架构设计原则,考虑实际需求,提出应用支撑平台建设方案,包括操作系统、数据库管理软件、GIS平台、备份软件和安全权限管理等。
本系统建设需接入大量数据资源,数据建设方案是本项目重点内容之一。各投标单位根据实际业务需求和城市大脑(宁波市大数据中心平台)资源清单,提出数据建设方案,内容包括总体设计、数据采集与共享、数据库设计、数据处理分析、数据管理等。
中标方需制定城市交通治堵大数据分析系统和交通工程大数据监管系统的数据库建设标准,并将标准提供给交通工程大数据监管系统的中标单位。投标单位应对此作出无推诿承诺,及相关的配合工作。相关费用包含在投标报价中。
本项目需要与市经信局、市资规局、市公安局、市住建局、市综合执法局、运营商或互联网公司等单位的信息系统进行对接,通过数据交换平台共享实现政府部门数据的交换共享,通过数据接口实现与企业的数据交换共享。所需接入(计算)的数据资源主要内容如下表所示:
表4-3 数据接入(计算)需求表
序号 |
数据资源名称 |
数据资源项(字段名称) |
数据共享方式 |
数据更新频度 |
1 |
城市路网运行数据 |
交通指数、道路运行速度、道路交通流量等 |
数据交换平台共享 |
实时 |
2 |
常规公交运行数据 |
公交线路客流量、公交排班表、公交线路运行速度、公交GPS数据、公交刷卡数据等 |
数据交换平台共享 |
实时 |
3 |
出租汽车运行数据 |
出租汽车载客状态、出租车GPS数据、出租车乘客OD等 |
数据交换平台共享 |
实时 |
4 |
公共自行车运行数据 |
公共自行车站点信息、公共自行车站点桩位状态、公共自行车刷卡记录等 |
数据交换平台共享 |
实时 |
5 |
共享单车运行数据 |
借还车信息、路径等 |
数据交换平台共享 |
实时 |
6 |
轨道交通运行数据 |
轨道交通线路客流量、进出站乘客量等 |
数据交换平台共享 |
实时 |
7 |
道路客运数据 |
道路客运量、客运班次信息等 |
数据交换平台共享 |
实时 |
8 |
公共停车数据 |
公共停车场与地面停车泊位设施数据(位置与泊位数)、公共停车场与地面停车泊位的车牌识别记录等 |
数据交换平台共享 |
实时 |
9 |
用户出行轨迹等数据 |
手机信令数据或互联网用户数据 |
数据接口 |
每月 |
系统建设将产生能够对外共享的数据,以帮助各业务相关部门开展工作,通过数据交换平台对外共享。各投标单位根据系统功能设计提出共享数据清单,包括数据资源名称、资源项、共享条件和更新频率等。共享数据清单模板如下表所示:
表4-4 数据共享表(样表)
序号 |
数据资源名称 |
数据资源项(字段名称) |
数据类型 |
共享方式 |
数据更新频度 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
建立元数据库、拥堵指标库及若干专题数据库。专题数据库数量和具体内容由各招标单位根据业务实际需求提出。数据库设计及字段命名规则必须符合部、省交通运输部门正式发布的数据元标准。
各投标单位需提出数据处理分析方案,包括数据清洗、转换、一致性校验、数据加密、数据挖掘等方面。
实现元数据管理和维护、数据安全与权限管理、数据质量监管等功能。
5、交通模型建设需求
为支撑业务应用系统建设,本项目需建设包括小汽车路径识别模型、小汽车出行OD模型等交通模型。各投标单位需根据业务需求提出交通模型建设方案、模型的功能应用,包括以下交通模型。投标单位可根据对城市交通治理工作的理解,在满足采购方需求的基础上,提供其他交通模型。
交通模型建设方案的提出应基于表4-3数据接入(计算)需求表,若模型的数据需求超出表4-3,投标单位应在数据建设方案中予以说明,并且承诺提供超出表4-3的相关数据,出具盖章承诺函。
在建设期和免费维保期内,因政策调整、使用习惯等原因,需对模型作出调整的,中标方需免费提供相应服务。投标单位应对此作出无推诿承诺。
表5-1 交通模型需求表
序号 |
模型名称 |
模型说明 |
1 |
小汽车路径识别模型 |
建立小汽车路径识别模型,实现路段、交叉口小汽车通行和转向情况的展示,挖掘路段小汽车的来源与去向 |
2 |
小汽车出行OD模型 |
通过多源数据融合,结合小汽车路径识别模型,挖掘小汽车出行OD |
3 |
常规公交及轨道交通客流路径识别模型 |
建立常规公交及轨道交通客流路径识别模型,挖掘常规公交下客点、轨道交通客流路径、公共交通出行链等信息 |
4 |
公交出行OD模型 |
结合常规公交及轨道交通客流路径识别模型,识别公共交通出行OD |
5 |
非机动车出行OD模型 |
建立非机动车出行OD模型,分析识别电动自行车、公共自行车(含共享单车)等非机动车出行者OD |
6 |
出租车客流OD模型 |
建立出租车客流OD模型,分析出租车客流OD、道路运行状况等信息 |
7 |
职住分析模型 |
建立职住分析模型,分析城区范围内人口流动规律及居民职住情况 |
对本次工程信息系统安全的威胁和风险表现在以下几个方面:
(1)来自外部网络的安全威胁
本次工程中具有大量信息的交换和共享,很多信息涉及公众和企业的隐私,同时系统需要连接到Internet上,存在各种各样不可预知的风险,网络入侵者可以通过多种方式攻击内部网络。因此,有必要将对外信息发布服务器(Web、DNS、EMAIL等)部署在外网并和政务外网进行必要的隔离,避免网络信息外泄,使得攻击者无从下手,同时还要对网络通讯进行有效的过滤,使必要的服务请求到达主机,对不必要的访问请求加以拒绝。
(2)来自内部网络的安全威胁
本次工程内部网络上造成安全问题的原因来自多方面,具体包括:人为失误或错误的操作,潜在的计算机病毒威胁,对于己经或正在发生的攻击缺乏有效的追查手段以及无法对网络的运行状况实施有效监控。
(3)物理安全风险
物理安全的威胁主要有地震、水灾、火灾等环境事故;电源故障;人为操作失误或错误;设备被盗、被毁;电磁干扰;线路截获;以及高可用性的硬件、双机多冗余的设计、机房环境及报警系统、安全意识薄弱等。
(4)系统安全风险
本次工程系统的安全风险是指整个网络操作系统和网络硬件平台是否可靠且值得信任。服务器主机和终端设备根据实际需求,同时存在微软的Windows系列以及UNIX操作系统,都无法保证绝对的安全。因此不但要选用尽可能可靠的操作系统和硬件平台,并对操作系统进行安全配置。而且,必须加强登录过程的认证(特别是在到达服务器主机之前的认证),确保用户的合法性;其次应该严格限制登录者的操作权限,将其完成的操作限制在最小的范围内。
(5)管理制度安全风险
管理是网络安全中最重要的部分。要求中标方遵守采购方网络安全有关制度。
本项目系统运行过程中,将会产生、传输和储存大量关于综合交通的监控和服务信息。这些信息对于行业管理和监控起到十分关键的作用,并涉及到公共利益,本工程需按照信息系统等级保护第二级要求进行设计。
中标方需负责支付城市交通治堵大数据分析系统(标包1)和交通工程大数据监管系统(标包2)的等保测评、软件测评、安全测评等测评费用,并配合做好标包1的测评工作。若标包1测评结果未达到等保要求,中标单位必须根据测评结果进行整改,直到通过测评。测评费用包含在投标报价中。
本项目安全建设需充分利用城市大脑(宁波市大数据中心平台)资源,各投标单位需根据业务需求及城市大脑(宁波市大数据中心平台)资源提出本项目的安全建设方案,包括安全系统设计与数据加密方案设计,并填写安全系统明细表及城市大脑(宁波市大数据中心平台)安全资源申请表。安全系统设计内容包括物理安全、网络安全、应用安全和数据备份等;数据加密方案设计内容包括数据保护平台、数据库加密、数据脱敏等。安全系统明细表模板及安全资源申请表如下表所示:
表7-1 安全系统明细表(样表)
序号 |
设备及软件名称 |
主要性能指标 |
所属系统及部署位置 |
单价(万元) |
数量 |
总价(万元) |
备注 |
1 |
|
|
|
|
|
|
|
2 |
|
|
|
|
|
|
|
3 |
|
|
|
|
|
|
|
合计: |
|
表7-2 安全资源申请表(样表)
序号 |
资源名称 |
数量 |
规格 |
部署 |
1 |
|
|
|
|
2 |
|
|
|
|
1、本项目工期:自合同签订之日起到2022年10月完成验收(包含6个月试运行)。
2、投标单位应在投标文件中提供详细的实施方案,应包括项目组织机构、项目实施流程、项目实施进度、项目实施安排。
3、项目开发过程中,中标方必须提供项目管理文档,以便采购人及时了解项目进展情况。
4、投标单位应向采购人提供项目管理人员和技术人员配置情况。投标单位技术人员至少10人及以上,其中50%以上人员需具有相关软件开发经验,其中项目经理和技术负责人需具有相关大数据项目经验。投标单位必须提供人员名单、身份证号码、职称、联系方式、项目实施经历、在本项目中的职务及任务。
5、在开发阶段,中标方需派项目经理携至少3名开发人员,常驻现场。
6、中标方应与采购人相关业务与技术人员一同完成本应用系统的业务建模和业务需求分析阶段的工作;需求分析结束后,采购人将再进一步提出应用系统的设计、开发、测试等详细要求,中标方应按要求编制有关说明书。
7、本招标文件提出项目需求,是投标方编制投标文件和报价的主要依据,但采购人有权根据实际业务需求,对招标文件规定的需求进行细化和优化,最终的需求以各方确认的细化和优化需求规格说明书为准,并以此需求规格说明书作为验收依据。
要求中标方提交的成果包括:
(1)需求分析说明书;
(2)概要设计说明书;
(3)详细设计说明书;
(4)测试计划、测试案例、测试报告;
(5)可运行的系统;
(6)全部源代码和执行码;数据库设计及数据表详细内容(字段名、字段属性等);
(7)软件系统使用的全部软件工具的列表;
(8)各种培训教材;
(9)发布说明;
(10)部署材料清单;
(11)系统安装手册;
(12)系统维护手册;
(13)用户操作手册;
(14)系统数据库设计文档(参照交通运输部正式颁布的数据元集标准格式);
(15)应用支撑平台的设计文档;
(16)发表核心期刊论文或取得专利受理合计2篇(项)。
1、负责本项目范围内应用软件的现场安装部署、集成、测试和调试,保证系统功能、性能要求的实现。在安装、配置和测试、调试过程中,中标方应对最终用户技术人员所提出的技术问题,给予满意的答复。
2、要求有完整的安装和配置程序,具有详细的系统安装配置说明手册、用户使用说明书和系统维护说明书。系统实际安装与操作必须与说明书描述一致。
3、要求具有完整的系统测试计划,包括根据用户需求编写的遍及系统95%以上功能、性能的测试用例,合理的测试方案和测试方法。要求保留完整的测试报告。
4、中标方负责解决系统集成中全部技术问题,对用户单位项目建设中碰到的其他技术问题,有责任和义务提供咨询和帮助。
1、验收标准:所有应用软件的产品验收标准、国家、行业标准、招标文件要求、合同中的相关条款及经采购人确认的需求说明书进行验收,如有矛盾,以其中最高要求为准。
2、验收方式
项目验收分初步验收和最终验收。
1)系统开发调试完毕后,中标方应对系统的整体性能和功能进行自检,自检结果必须符合招标文件要求及合同中的相关条款,中标方应负责组织专业技术人员进行系统的安装调试,解决安装中出现的问题。系统功能开发完成、自检无误后,中标方向采购人提交初验收申请,经采购人初验合格同意后,系统进入试运行。
2)在试运行期间,由于软件系统功能质量等造成某些指标达不到要求,允许中标方更换、修复、修改等,在全部达到要求时可进行最终验收。
3)最终验收
项目终验前,由中标方提交验收申请,经采购人同意后,组织进行终验,验收结果必须符合招标文件要求及合同中的相关条款。终验期间,如有发现系统运行有问题,中标方应无条件重新检测并调试系统直至最终验收合格交付使用。
1、本项目的培训,是指投标单位对城市交通大数据分析平台使用和维护该软件的人员进行培训。投标单位培训采购人的技术人员,实现采购人的自我支持能力以及源代码级的自我维护能力。
2、培训由投标单位负责师资及教材,并负责组织实施。投标单位方必须派出具有相关专业资格和实际工作经验的教师及辅导人员授课,主要培训教员至少应具有三年的同等内容的教学经验。
3、投标单位应详细制定人员培训方案,包括培训目的、培训时间安排、人数、次数、教材编写(列出教材基本内容)、培训课程(包括课程介绍)、培训师资情况(包括教师简历)、培训组织方式等。
4、培训费用计入总报价。
1、中标方应提供至少1年的项目免费维保服务,要求提供不少于1名驻场维护人员并具备独立承担本系统日常维护的技术能力。维保期从项目最终验收合格之日算起。在维保期内,出现软件系统的故障,中标方应研究其故障原因,并迅速修复,直至满足采购人原定的要求为止。
在开发和维护期间中标单位人员发生变动时必须经过采购方的同意,否则按每人以合同总价2%的标准在项目费用中扣除。
2、维保服务的响应时间。若采购人提出故障申请,中标方须提供7×24小时电话服务,维保服务响应时间为30分钟,并在2小时内派专业技术人员到达现场进行免费维保服务。故障原因在8小时内无法排除的,中标方在1个工作日内提交解决软件系统故障的方案。通过与用户交涉承诺将以最快的时间将故障排除。中标方还须提供系统应用软件的故障处理、维护和现场巡检等服务,以及其他的技术支持工作。在维保期内,与软件系统维保等相关的费用由中标方负责。
3、维保期后的服务要求。维保期结束后,中标方仍应提供与维保期内相同质量的售后服务,其维保的相关费用由采购方自行承担。
4、投标人可视自身能力在投标文件中提供更优、更合理的维保服务承诺。
5、投标人在其投标文件中须对售后服务作出明确的承诺,包括服务时限、故障响应处理时限、应用恢复处理时限等。
1、付款方式
(1)在合同签订生效后10个工作日内,中标单位出具合同总价款5%的银行履约保函,提交给采购方,银行履约保函在项目竣工验收合格后30个工作日内无息退还。
(2)在合同签订生效,采购方收到中标方提供的正规发票后,于2021年5月底前向中标方支付中标单位合同总价款的30%;
(3)在完成需求规格说明书、项目详细设计,并通过采购方组织的评审后,采购方自收到中标方提供的正规发票15日内,向中标方支付合同总价款的16%;
(4)在完成交通模型建设、系统原型开发和修改意见征集,并通过采购方组织的评审后,采购方自收到中标方提供的正规发票15日内,向中标方支付合同总价款的16%;
(5)项目初验合格后,采购方自收到中标方提供的正规发票15日内,向中标方支付合同总价款的20%;
(6)项目竣工验收合格后,采购方自收到中标方提供的正规发票15日内,向中标方支付至决算价的100%。
2、知识产权
(1)宁波市交通运输局(“权利人”)具有本项目软件的著作权、所有权、使用权等全部版权,包括所有源代码和文档,中标方未经权利人、采购方授权不得使用。
(2)中标方应保证权利人、采购方,以及权利人授权的其他第三方(如有)在使用该软件时免受第三方在知识产权方面的起诉。
(3)中标方应当赔偿由于知识产权纠纷而造成权利人、采购方以及权利人授权的其他第三方(如有)的损失。
(4)中标方需接受采购方所委托的第三方的项目咨询和管理。
3、交付违约
如中标方未按进度要求及时提交项目成果,导致工程延期,中标方每延期10天,中标方应向采购方支付合同金额的3%的违约金;但违约金的总数不超过合同金额的10%。如延期时间超过60天,采购方有权终止合同,除前款所约定的违约金外,还有权要求中标方支付合同总金额的5%作为对采购方的赔偿。
4、信息安全
中标方配合采购方做好信息安全等级保护工作。
5、保密要求
中标方必须严格遵守国家保密法规和信息安全保密相关法律法规,并按规定签订保密协议,在任何时候不得泄露与本项目、本合同业务有关的商业合同、技术文档、业务管理等方面的保密资料。
标包二:交通工程大数据监管系统开发项目
说明:标包1的中标单位不能中标标包2。
具体见招标文件