建设场景
设备数量
功能模块
勾选的模块会生成对应的技术条款。
其他要求
生成的招标技术要求
共 8 章 47 条,可直接粘进招标文件
一、项目概述 1.1 项目名称:(待填写);建设场景:智慧园区 / 楼宇;规划设备数量:200 台。 1.2 本项目建设范围包括设备接入、平台部署、功能开发、系统集成、调试验收及质保期内的技术支持。 1.3 投标人须在投标文件中提供完整的技术方案、设备清单(含品牌型号)、实施计划与验收方案,缺项视为不响应。 二、平台总体技术要求 2.1 平台须采用微服务或模块化架构,支持横向扩展;在 200 台设备、每秒 100 条数据上报的压力下,单节点支持不少于 300 个设备并发连接。 2.2 平台须支持集群部署,节点故障时服务自动切换,切换过程中数据不丢失,切换时间不大于 60 秒。 2.3 关键查询接口 P95 响应时间:查询类不大于 2 秒,写入类不大于 1 秒;统计报表类不大于 5 秒。 2.4 历史数据在线保存不少于 12 个月,支持按时间范围导出 CSV,导出 100 万条数据不超过 5 分钟。 2.5 平台须支持私有化部署,部署于采购人指定机房或云资源,数据不出采购人管控范围;投标人须提供服务器配置建议清单。 三、设备接入要求 3.1 平台须支持 MQTT、HTTP/HTTPS、Modbus RTU/TCP、OPC UA、BACnet、GB/T 28181 等不少于 8 种通信协议,并提供协议适配说明文档。 3.2 门禁控制器、道闸、车牌识别相机、环境传感器、远传水电表等设备须接入统一平台,不得各自独立成套软件 3.3 存量门禁与视频系统如无法提供协议文档,投标人须在方案中明确替代方案及费用,不得列为实施阶段增项 3.4 新增设备类型(协议已知)的接入调试周期不超过 3 个工作日;协议未知的,双方协商确定周期并在合同中约定。 3.5 平台须提供设备接入 SDK 与物模型定义文档,支持采购人自行完成后续设备接入。 四、功能要求 【门禁与人员通行】 4.1 支持刷卡、二维码、人脸三种识别方式,识别响应时间不大于 1 秒,误识率不高于 0.1% 4.2 支持按部门、时段、区域配置通行权限,权限变更实时下发至终端,下发成功率不低于 99% 4.3 所有通行记录(含抓拍图)在平台留存不少于 6 个月,支持按人员、时间、门点组合查询并导出 【车辆道闸与车位】 4.4 车牌识别准确率在正常光照条件下不低于 99%,夜间不低于 97% 4.5 支持月卡、临时车、免费车等多类计费规则并行配置,规则变更不需停机 4.6 道闸开闸指令从平台下发到闸机动作的端到端时延不大于 2 秒 【环境与能耗监测】 4.7 温湿度、CO₂、PM2.5 等环境参数采集周期可配置,最小不大于 60 秒 4.8 水、电、气按楼层或部门分项计量,支持按日/月/年生成用量报表并对接财务口径 4.9 任一监测点越限后 10 秒内产生告警,告警可通过平台、短信、企业微信三种方式推送 【数据可视化大屏】 4.10 支持拖拽式组态,业务人员可在不编写代码的情况下调整页面布局与图表 4.11 数据刷新周期可配置,最小不大于 5 秒,刷新过程不出现整屏白屏 4.12 支持多终端自适应(1920×1080、2560×1440 及移动端),分辨率切换不变形 【告警与工单闭环】 4.13 告警支持分级(紧急/重要/一般),不同级别对应不同推送对象与响应时限 4.14 告警可一键转为工单,工单处理过程全程留痕,闭环率可统计 4.15 支持告警抑制与合并,同一设备短时间重复告警不重复推送 五、安全与合规要求 5.1 设备接入须采用一机一密或一型一密机制,禁止全站使用统一密钥。 5.2 平台与设备、平台与客户端之间的传输链路须启用 TLS 1.2 及以上版本加密。 5.3 须支持基于角色的访问控制(RBAC),最小权限粒度可到单个设备或单个数据点。 5.4 登录日志、操作日志、告警日志留存不少于 6 个月,日志不可被普通管理员删除。 5.5 平台须满足网络安全等级保护相关要求,投标人须配合完成等保测评并提供所需材料。 六、接口与集成要求 6.1 投标人须提供平台对外接口清单及文档,包括设备数据查询、告警推送、工单创建等主要能力。 6.2 涉及与采购人已有系统对接的,每个接口须在方案中单独列明对接方式、工作量与费用,不得以「配合对接」笼统表述。 6.3 接口变更须提前通知并提供不少于 3 个月的兼容期。 七、验收要求 7.1 验收以连续 30 天平台运行数据为准,不接受现场演示作为验收依据。 7.2 设备在线率:有线场景不低于 98%,无线场景不低于 95%。 7.3 数据完整率:不低于 98%(剔除设备故障与计划停机时段后计算)。 7.4 告警准确率:抽连续 7 天告警逐条现场核实,准确率不低于 90%(不含预测类告警)。 7.5 并网稳定性:连续 30 天内非计划中断不超过 2 次,累计时长不超过 4 小时。 7.6 交付文档须包含:需求确认书、系统设计说明、设备清单与拓扑图、接口文档、操作手册、运维手册、测试报告、培训记录。 7.7 验收不通过的处理方式、整改期限与二次验收安排在合同中明确约定。 八、服务与质保要求 8.1 质保期自终验合格之日起不少于 12 个月,质保期内非人为损坏的设备免费更换。 8.2 故障响应:重大故障 30 分钟内响应、4 小时内到场(同城);一般故障 2 小时内响应。 8.3 质保期内提供不少于 2 次现场巡检与 1 次操作培训。 8.4 质保期满后须提供续保方案与报价,续保费率不高于合同金额的 15%/年。
这些条款为什么这么写
每一条都带数字或明确交付物,是为了让投标人能响应、让你能验收。 「满足使用需求」这种写法在验收时没有任何约束力。
别写成只有一家能投
条款里不要出现具体品牌型号、不要要求独家功能。 用「支持不少于 8 种协议」代替「支持 XX 协议」,竞争才充分。
需要有人帮你把参数按项目实际情况调整一遍?
让技术负责人过一遍招标参数最常见的五个坑
这些坑我们在评审和答疑里反复见到,每一个都会在实施阶段变成扯皮。
写「满足使用需求」「达到行业先进水平」
这类表述没有任何约束力。投标人写一句「完全满足」就算响应,验收时你说不达标,他说已经满足了。技术条款必须能被第三方复核。
抄某一家厂商的产品白皮书
条款里出现独家功能名称、特定参数组合,就是指向性条款。轻则被质疑、重则废标重招,耽误的时间成本远大于省下的事。
只写功能,不写性能
「支持告警推送」是功能,「告警在 10 秒内送达」才是性能。只写功能的系统,上线后延迟三分钟推送也算满足。
验收条款留到签合同后再谈
验收标准必须在招标文件里就写清楚。中标后再谈,主动权完全在乙方手上——他已经在做别的项目了,你的项目排后面。
不写「不包含什么」
接口对接、电力增容、停电施工、等保测评、培训,这几项最容易变成增项。招标文件里明确「投标报价须包含 XX」,后期才有依据。
怎么用这份生成的参数
三步走,别直接复制粘贴就发出去。
- 第一步
删掉不适用的章节
生成的是通用模板,你项目里没有的模块(比如不装充电桩)就把对应条款整段删掉。条款越多,投标人越容易漏响应。
- 第二步
把数字改成你的实际情况
点数、并发数、质保期、响应时限这些,按项目需求改。默认值都是行业常见水平,不是最优值。
- 第三步
让懂技术的人过一遍
参数之间会互相影响——要求 1000 台设备并发、又要求单节点部署,技术上就矛盾了。定稿前找懂行的人看一眼,能省掉一轮答疑。
需要一份现成的参数样本对照?智慧水务招标参数模板里有三个核心指标的可验收写法和评分表设置。 验收阶段要用的清单在项目验收清单。参数定完之后,用报价计算器按设备台数估一下预算区间,看看这份参数对应的钱够不够;如果条款里写了视频存储要求,再用存储计算器把容量和带宽的数字核准,别让「保存 90 天」变成一句没法验收的话。
关于招标参数
生成的参数能直接用于正式招标吗?+
可以作为技术要求的初稿,但不建议一字不改直接用。招标文件涉及法律效力,需要走你们内部的法务和采购流程审核;涉及金额、工期、付款方式的条款必须按项目实际填。这份工具解决的是「技术条款怎么写才可验收」,不替代招标代理的工作。
为什么条款里都是「不少于 8 种协议」这种写法?+
这是为了既留出竞争空间、又能验收。写具体品牌型号会导致只有一家能投,涉嫌指向性条款;写「支持主流协议」又没法验收。用「不少于 N 种 + 列举」的写法,既明确了底线,又允许多家响应。
验收标准里的数字是怎么定的?+
在线率 98%(有线)/95%(无线)、数据完整率 98%、告警准确率 90% 这几个值来自实际项目交付经验:定得太高没人能做到,定得太低等于没有约束。无线场景单独降到 95%,是因为受运营商信号影响,一刀切写 98% 后期必然扯皮。
参数写得太严,会不会没人来投?+
会有这个风险,但通常是数量问题不是难度问题——比如要求「支持 12 种协议」可能只剩两三家能响应。建议把必须项控制在 5-8 条,其余写成加分项。这份生成器默认输出的都是行业普遍能达到的水平,如果你们项目特殊,可以在此基础上删减。
能不能生成设备清单和预算?+
设备清单要看现场点位构成,问卷给不出准确答案;预算可以先用报价计算器估个量级。真要出清单,需要先做点位盘点——资料中心有一份机房监控点位清单可以参考格式。
让技术负责人帮你过一遍参数
把项目背景和生成的参数发过来,我们按实际施工经验指出哪几条会踩坑、哪几条可能没人响应。免费,也不推销设备。