1 项目背景
随着新能源装机规模的持续增加、电网对新能源数据的考核不断升级,对新能源场站的短期预报准确率、超短期预报准确率、预测完整性、单机信息和测风数据合理性和完整性、系统可靠性提出了更高的要求。
为解决目前单个场站预报准确率低、模型优化困难、可靠性差、维护成本高、网络安全无法保障等难题,同时为满足对所有新能源电厂风功率预测系统进行集中管理,随时查看各站的实时数据采集情况、预报情况和上报情况,了解当前所有场站预报的发电量等业务需求,智信能源科技有限公司(以下简称“智信能科”)自主研发了一套开放式集中功率预测平台(以下“平台”或“平台端”,初步建立了自主可控的运营保障系统,实现了新能源功率预测,为提升新能源电厂运行效率,减少电网考核经济损失,提高未来售电竞争力提供了基础支撑条件。
2 项目目的
本项目旨在建设一套遵循《风光一体集中接入通讯系统(略)规约》(采用规约在原有的DL/T (略)-(略)协议基础上增加ASDU功能)的数据交互与计算系统。该系统需能同时满足开放式集中功率预测平台场站侧作为风光功率预测系统子站,统一上报数据的从动站(服务端),作为主站(启动端)统一数据接收的客户端双重功能,同时对数据上报后的业务指标表现进行计算,打通新能源场站与调度中心、平台端及第三方风光功率预测系统子站之间的信息交互通道,及业务表现趋势分析。
3 项目范围
本项目拟建设的数据交互与计算系统为智信能科公司自主研发的开放式集中功率预测平台子系统(功能),能够满足河北、广西、广东、山西、江西、陕西、甘肃等7省个省份/地区电网调度管辖下范围内,开放式集中功率预测平台作为新能源场站风光功率预测系统子站和主站角色,以E文本方式传输上述各省份/地区电网调度新能源场站运行数据文件,具体文件定义见“9.1.4 E文本文件定义”。
4 总体原则
? 标准化与合规性:(略)
? 可靠性与可用性:(略)
? 安全性:(略)
5 工作范围
基于本项目拟建设的数据交互与计算系统,供应商/成交人工作范围包括且不限于:
(1)完成开放式集中功率预测平台场站侧,电网调度风光功率预测系统主站所需数据文件的生成与上报程序(风光功率预测系统子(从动)站角色,服务端)的开发与源代码交付,该程序上报能力所需覆盖的省份/地区电网调度见“3 项目范围”,功能要求见“9.1 (略)数据交互系统”。
(2)完成包括开放式集中功率预测系统在内的第三方风光功率预测系统子站所发送的系统数据的接收、解析与转发程序(风光功率预测系统主站角色,客户端)的开发与源代码交付,该程序接收和解析数据能力所需覆盖的省份/地区电网调度见“3 项目范围”,功能要求见“9.1 (略)数据交互系统”。
(3)按照所需覆盖的省份/地区电网调度的两个细则考核规则,进行上报数据的业务指标计算程序的开发与源代码交付,业务指标所参照的标准规范和业务指标计算要求见“9.2 业务指标计算系统”。
(3)完成上述(1)、(2)、(3)所提及程序单元测试、集成测试、系统测试、试运行。
(4)完成上述(1)、(2)、(3)所提及程序与开放式集中功率预测平台端及场站端的系统集成与联合测试。
(5)协助询价方完成河北、广西、广东、山西、江西、陕西、甘肃等7省个省份/地区电网调度风光各一个新能源场站(1)和(2)所提及程序与电网调度的联调,协助方式包括但不限于远程协助和现场协助。
(6)协助供应商/成交人在询价方自有开发环境,完成上述(1)和(2)所提及程序源代码的部署、调试、启动及打包。
(7)其他询价方协助掌握供应商/成交人程序或代码所必须的工作,包括但不限于如详细设计解读、代码逻辑解读等。
6 参考标准
GB/T (略) 电力监控系统网络安全防护导则
GB/T (略) 调度侧风电或光伏功率预测系统技术要求
NB/T (略)—(略) 光伏发电功率预测系统功能规范
NB/T (略) 风电功率预测系统功能规范
7 项目要求7.1 资质业绩
(1) 供应商/成交人须具备信息安全服务资质认证书、电子与智能化工程专业承包二级及以上资质,具备电力系统信息化项目现场实施、调试及运维能力;
(2) 供应商/成交人须拥有至少2项与新能源功率预测、数据通信相关的发明专利证书(专利权利人为供应商/成交人本身,无权属争议、未被质押);
(3) 如供应商/成交人无法满足上述要求,则视供应商/成交人不满足询价方要求。
7.2 交付清单
供应商/成交人在报价时应按单个省份进行报价,并另行对新增风光功率预测系统子(从动)站程序和风光功率预测系统主站程序单独报价,供甲方新增范围参照。以下为本项目询价方交付清单:
表7-1 项目交付清单表
序号 | 名称 | 数量 | 交付内容 | 报价方式 |
1 | 风光功率预测系统子(从动)站程序 | 1套 | 河北、广西、广东、山西、江西、陕西、甘肃等7省/地区电网调度风光功率预测系统子(从动)站程序一套,包括程序本体、程序运行环境,源代码及源代码。 | 供应商/成交人按照单个省份报价,询价方按需新增、据实结算 |
2 | 风光功率预测系统主站程序 | 1套 | 河北、广西、广东、山西、江西、陕西、甘肃等7省/地区电网调度风光功率预测系统主站程序一套,包括程序本体、程序运行环境,源代码及源代码运行环境。 | 供应商/成交人按照单个省份报价,询价方按需新增、据实结算 |
3 | 业务数据指标计算系统 | 1套 | 参照西北区域、华北区域、南方区域、华中区域及河北、广西、广东、山西、江西、陕西、甘肃等7省发电厂并网运行管理实施细则相关功率预测业务考核指标。 | 供应商/成交人按照单个省份报价,询价方按需新增、据实结算 |
4 | 项目文档 | 1套 | 需求规格说明书、详细设计说明书、测试计划/测试用例、项目源代码、开发文档、集成测试报告、安装手册、用户手册、系统测试报告、性能测试报告、安全测试报告、试运行报告、应急预案、系统上线报告、验收计划、系统验收报告、项目状态(周月)报告 | 按项目交付 |
7.3 交付周期
本项目采用分阶段交付方式,具体交付时间,根据甲方需求进行调整,初步交付时间节点如下表:
表7-2 项目交付时间节点
序号 | 省份 | 优先级 | 最晚交付时间 | 备注 |
-
| 河北 | 高 | (略)年3月 | 华北区域 |
-
| 山西 | 高 | (略)年4月 | 华北区域 |
-
| 广西 | 高 | (略)年4月 | 南方区域 |
-
| 江西 | 中 | (略)年5月 | 华中区域 |
-
| 陕西 | 中 | (略)年5月 | 西北区域 |
-
| 甘肃 | 中 | (略)年6月 | 西北区域 |
-
| 广东 | 高 | (略)年7月 | 南方区域 |
8 职责与分工8.1 供应商/成交人责任
供应商/成交人应指派项目经理与询价方协调项目实施的各项工作,并在进场前7天,向询价方提供项目实施团队组织架构图及人员联系表,保持与询价方的联系。
供应商/成交人应根据询价方的需求作出科学的、完善的、规范的需求分析报告、总体设计报告、项目实施方案和工程进度计划表,并经双方认可之后,开始系统详细设计和部署实施。
供应商/成交人负责系统的设计、部署、调试、完善、开发和维护文档的编写、整理和修订。
供应商/成交人负责开展面向系统管理员的应用程序运行、管理和维护的专业知识及开发工具指导。对有关人员作针对应用系统的使用指导。
供应商/成交人应在项目执行过程中分阶段提交下述图纸及资料:(略)
供应商/成交人软硬件设计开发文档应严格按照国家和电力行业的管理信息系统开发规范编制并提交。
供应商/成交人应按照合同要求,在本合同规定的时间内完成本项目的设计、开发、部署、调试和运行、验收等。
供应商/成交人须接受询价方对项目的监管。
8.2 询价方责任
询价方应配合供应商/成交人完成系统实施和部署工作。
询价方应指派专人成立项目工作组,负责质量的监督和办理本项目中商定的事宜。
询价方有权对本项目的技术方案、体系结构、进度、质量、实施人员进行有效监管。
询价方应做好本项目的实施协调配合工作,负责协调供应商/成交人与相关部门的关系,对供应商/成交人项目建设过程中呈报的有关报告及时批复。
询价方应根据本合同中规定的验收标准,在系统试运行完成后的三个月内组织项目初步验收。项目初步验收通过后,询价方为供应商/成交人签发验收证书和完工交接证书。
9 技术要求9.1 (略)数据交互系统9.1.1 (略)规约技术说明
本技术协议提及的河北、广西、广东、山西、江西、陕西、甘肃等7省个省份/地区电网调度风光功率预测系统(略)规约,均参考中华人民共和国电力行业标准DL/T (略).5.(略)-(略)和DL/T(略)-(略)规定的传输规约,并在原有的DL/T (略)-(略)协议基础上增加ASDU功能。
上述各省风光功率预测系统(略)规约采用DL/T (略)-(略)第5章规定的非平衡传输规则,即传输过程的启动仅限于某一固定点,在本规约中调度为主站端,作为启动端,而风光功率预测系统为子站,始终为从动站。风光功率预测系统为子站系统的基本问答过程是采用带有功能码(略)的请求2级用户数据的请求响应服务,1级数据如同IEC(略)-5-2 所定义的用请求访问位(ACD bit)来表示。采用 C/S 方式,遵从 TCP/IP协议,主站作为客户端,子站为服务端。
上述各省份/地区电网调度风光功率预测系统(略)规约帧格式、帧单元说明、控制流程、数据帧格式、数据帧格式及类型标识,以各省份/地区电网调度发布的标准文件为准。
因各省份/地区电网调度风光功率预测主站(略)规约类型标识存在差异,且均按照自身情况进行自定义,供应商/成交人需在本项目数据交互与计算系统建设方案中予以体现和文字说明,否则视为不满足询价方要求。
9.1.2系统基本功能要求9.1.2.1 数据通信交互流程
表9-1开放式集中功率预测平台数据通信交互流程图
.png")
9.1.2.2 子(从动)站服务端
作为独立功能(服务),是开放式集中功率预测平台场站侧数据上报主站(如调度、平台端)的唯一出口,严格遵循各省级/地区级新能源场站风光功率预测系统主站(略)规约的从动站服务端角色,主要满足如下技术要求。
9.1.2.2.1 链路层实现
1) 作为各省级/地区级新能源场站风光功率预测系统子站服务端,被动监听并接受主站发起的TCP连接请求。
2) 具备稳定的网络链路管理能力,支持与多个主站(如主用、备用调度中心、平台端)同时建立并维持连接。
3) 实时监控连接状态,在网络异常断开后,能够立即恢复监听,等待主站重连。
4) 向开放式集中功率预测平台场站侧系统反馈与多个主站的链路状态,如链路断开、链路恢复、链路等待、链路复位等。
9.1.2.2.2 应用层指令响应
1) 能够正确解析并响应主站下发的各类应用层指令,主要包括:
a) 召唤1级用户数据
b) 召唤2级用户数据
c) 请求链路状态
d) 复位通信单元
2) 精确处理和维护上行报文控制域(Control Domain)的各位状态。当有1级用户数据(如紧急告警、状态变位)需要上报时,必须能正确置位要求访问位(ACD)。
? 上报文件生成与管理
1) 提供标准化的数据采集接口(如MQTT、IEC(略)、OPC、Modbus、数据库视图等),从场站内各数据源(如SCADA、功率预测系统等)高效获取数据。
2) 对从场站内各数据源获取到的各类数据,按照“8.4 E文本文件定义”所需内容进行数据加工、预处理、存储、查询等,以满足各省级/地区级电网调度新能源场站风光功率预测系统主站数据要求。
3) 内置灵活的任务调度引擎,能够自动、准时地生成各省级/地区级电网调度新能源场站风光功率预测系统主站要求的标准化数据文件,文件类型见“9.1.4 E文本文件定义”。
9.1.2.2.3 文件传输控制与交互
1) ASDU封装与分帧:(略)
2) 传输应答处理:(略)
a) 收到主站的文件接收成功确认后,标记该文件为发送成功 。
b) 收到主站的异常确认后,必须记录详细日志并根据预设策略进行处理。需正确响应的异常确认包括:(略)
c) 向开放式集中功率预测平台场站侧系统反馈与多个主站的文件传输状态,如上传成功、上传失败、异常信息等。
9.1.2.2.4 系统集成
本模块需与询价方现有的功率预测场站端系统、调度侧主站系统实现数据对接,用于接收场站端数据,转化为(略)规约/mqtt协议规定的数据格式,并上报至调度/平台端。
1) 数据交互类型:(略)
2) 数据交互协议与形式:(略)
3) 数据交互安全要求:(略)
4) 数据交互性能要求:(略)
5) 服务部署要求:(略)
6) 运维要求:(略)
9.1.2.3 主站客户端
作为独立功能(服务),承担主站客户端角色,可接收和解析包括开放式集中功率预测平台等第三方新能源场站风光功率预测系统标准化数据文件,文件类型见“9.1.4 E文本文件定义”,主要满足如下技术要求。
9.1.2.3.1 链路层实现
1) 作为客户端,能够主动向上百个发电场站(从动站)发起并维持TCP连接 。
2) 具备强大的连接管理能力,包括对各场站连接状态的实时监控、连接失败后的自动重试(重试间隔和次数可配) 。
3) 需维护一个可配置的场站地址列表(IP、端口、逻辑地址)。
4) 向开放式集中功率预测平台,以MQTT消息形式反馈与第三方新能源场站风光功率预测系统子(从动)站服务端的链路状态,如链路断开、链路恢复、链路等待、链路复位等。
9.1.2.3.2 应用层轮询与命令下发
1) 任务轮询:(略)
2) 控制域管理:(略)
3) 指令下发:(略)
9.1.2.3.3 数据接收与文件处理
1) 报文接收与解析:(略)
2) 文件重组与校验:(略)
3) 数据存储与转发:(略)
9.1.2.3.4 应答与确认机制
1) 在成功接收并重组文件后,系统必须能自动生成并发送包含文件长度的确认报文。
2) 在检测到异常情况时,能自动发送相应的否定确认报文,主要包括:
a) 检测到重复文件,发送重复传输告知报文。
b) 接收文件超过规定最大长度,发送文件过长告知报文。
c) 文件名或格式不符合规范,发送格式错误告知报文。
d) 单帧报文过长,发送单帧超长告知报文。
3) 向开放式集中功率预测平台场站侧系统反馈与子(从动)站的文件传输状态,如上传成功、上传失败、异常信息等。
9.1.3 系统高级功能要求
本项目拟建设的数据交互与计算系统除满足基础功能要求外,针对广东、山西、陕西、河北南网等电网调度,还必须实现以下高级功能:
●全系统高可用性冗余:(略)
●多目的地/多源并发通信:(略)
9.1.4 E文本文件定义
本项目拟建设的数据交互与计算系统,支持的新能源场站风光功率预测系统新能源场站运行数据E文本文件定义如下表。
各省级/地区级E文本文件定义如发生变化,应以各省级/地区级最新的E文本文件定义稳准,本技术协议不再额外阐述。
供应商/成交人应遵照各省级/地区级电网调度最新的E文本文件定义进行评估,并提供数据交互与计算系统技术开发服务。
9.1.4.1 广东、广西省
表9-1广东省、广西省、云南省新能源场站风光功率预测系统E文本文件定义
序号 | 新能源类型 | 文件名称 | 上送/解析数据信息 |
1 | 风电场 | E文本-FDJZ | 风力发电机组信息 |
2 | E文本-SYZXX | 升压站信息 |
3 | E文本-ZTXX-QXHJ | 风电场总体信息/气象环境监视信息 |
4 | E文本-AGC-AVC | AGC-AVC信息 |
5 | E文本-DQYC | 风电短期功率预测信息 |
6 | E文本-CDQYC | 风电超短期功率预测信息 |
7 | E文本-TJXX | 风电场统计信息 |
8 | 光伏电站 | E文本-XB-FZ | 光伏箱变/方阵信息 |
9 | E文本-SYZXX | 升压站信息 |
(略) | E文本-ZTXX-QXHJ-TYGZ | 光伏电站总体信息-气象环境-太阳跟踪系统信息 |
(略) | E文本-AGC-AVC | AGC-AVC信息 |
(略) | E文本-DQYC | 光伏短期功率预测信息 |
(略) | E文本-CDQYC | 光伏超短期功率预测信息 |
(略) | E文本-TJXX | 光伏电站统计信息 |
(略) | E文本-NBQ-HLX | 光伏逆变器/汇流箱信息 |
9.1.4.2 江西省
表9-2 江西省新能源场站风光功率预测系统E文本文件定义
序号 | 新能源类型 | 文件名称 | 上述数据 |
1 | 风电场 | E文本- (略)wind | 风电未来3或(略)天天短期功率预测信息 |
2 | E文本- 4Cwind | 风电超短期功率预测信息 |
3 | E文本- (略)nwp | 风电未来(略)小时或(略)小时天气预报信息 |
4 | E文本- (略)nwp | 风电未来(略)小时天气预报信息 |
5 | E文本- FJ | 风机信息 |
6 | E文本- DJ | 风电场单机信息 |
7 | E文本-CFT | 风电测风塔实测信息 |
8 | 光伏电站 | E文本- (略)wind | 光伏未来3或(略)天天短期功率预测信息 |
9 | E文本- 4Cwind | 光伏超短期功率预测信息 |
(略) | E文本- (略)nwp | 光伏未来(略)小时或(略)小时天气预报信息 |
(略) | E文本- (略)nwp | 光伏未来(略)小时天气预报信息 |
(略) | E文本- DJ | 逆变器单机信息 |
(略) | E文本-QX | 光伏气象站实测信息 |
9.1.4.3 甘肃省
表9-3 甘肃省新能源场站风光功率预测系统E文本文件定义
序号 | 新能源类型 | 文件名称 | 上述数据 |
1 | 风电场 | E文本- DQ | 风电未来8天短期功率预测信息 |
2 | E文本-TDQ | 风电未来(略)天的预测及开机容量 |
3 | E文本- CDQ | 风电超短期功率预测信息 |
4 | E文本- FJ | 风电机组状态数据 |
5 | E文本-DL | 风电未来(略)月的电量预测数据 |
6 | E文本-CFT | 风电测风塔实测信息 |
7 | E文本-THEROY | 风电理论功率 |
8 | 光伏电站 | E文本- DQ | 风电未来8天短期功率预测信息 |
9 | E文本-TDQ | 光伏未来(略)天的预测及开机容量 |
(略) | E文本-CDQ | 光伏超短期功率预测信息 |
(略) | E文本-NBQ | 逆变器运行信息 |
(略) | E文本-DL | 光伏未来(略)月的电量预测数据 |
(略) | E文本-QXZ | 光伏气象站实测信息 |
(略) | E文本-THEROY | 光伏理论功率 |
9.1.4.4 山西省
表9-4 山西省新能源场站风光功率预测系统E文本文件定义
序号 | 新能源类型 | 文件名称 | 上述数据 |
1 | 风电场 | E文本- (略)wind | 风电未来(略)天短期功率预测信息 |
2 | E文本- 4Cwind | 风电超短期功率预测信息 |
3 | E文本- 4CKJ | 风电超短期开机容量信息 |
4 | E文本- (略)nwp | 风电未来(略)小时天气预报信息 |
5 | 光伏电站 | E文本- (略)wind | 光伏未来(略)天短期功率预测信息 |
6 | E文本- 4Cwind | 光伏超短期功率预测信息 |
7 | E文本- 4CKJ | 光伏超短期开机容量信息 |
8 | E文本- (略)nwp | 光伏未来(略)小时天气预报信息 |
9.1.4.5 陕西省
表9-5 陕西省新能源场站风光功率预测系统E文本文件定义
序号 | 新能源类型 | 文件名称 | 上述数据 |
1 | 风电场 | E文本- ZR | 风电昨日开机容量 |
2 | E文本- DQ | 风电未来(略)短期功率预测第一报 |
3 | E文本- DQ(略) | 风电未来(略)天短期功率预测第二报 |
4 | E文本- CDQ | 风电超短期功率预测信息 |
5 | E文本- (略)nwp | 风电未来(略)小时天气预报信息 |
6 | E文本- (略)nwp | 风电未来(略)小时天气预报信息 |
7 | E文本- (略)TheoryPower | 风电离线理论功率 |
8 | E文本- RtTheoryPower | 风电在线理论功率 |
9 | E文本- (略)wind | 风电未来(略)小时极端天气影响预测出力 |
(略) | E文本- WThCDQ | 风电极端天气影响实时状态 |
(略) | 光伏电站 | E文本- ZR | 光伏未来(略)天天短期功率预测信息 |
(略) | E文本- DQ | 光伏超短期功率预测信息 |
(略) | E文本- DQ(略) | 光伏未来(略)天短期功率预测第二报 |
(略) | E文本- CDQ | 光伏超短期功率预测信息 |
(略) | E文本- (略)nwp | 光伏未来(略)小时天气预报信息 |
(略) | E文本- (略)nwp | 光伏未来(略)小时天气预报信息 |
(略) | E文本- (略)TheoryPower | 光伏离线理论功率 |
(略) | E文本- RtTheoryPower | 光伏在线理论功率 |
(略) | E文本- (略)wind | 光伏未来(略)小时极端天气影响预测出力 |
(略) | E文本- EWmeter_ | 光伏极端天气影响实时状态 |
9.1.4.6 河北省南网
表9-6 河北省南网新能源场站风光功率预测系统E文本文件定义
序号 | 新能源类型 | 文件名称 | 上述数据 |
1 | 风电场 | E文本- DQ | 风电未来(略)短期功率预测 |
2 | E文本- CDQ | 风电超短期功率预测信息 |
3 | E文本-CFT | 风电测风塔实测信息 |
4 | 光伏电站 | E文本- DQ | 光伏未来(略)天天短期功率预测信息 |
5 | E文本- CDQ | 光伏超短期功率预测信息 |
6 | E文本-CFT | 光伏气象站实测信息 |
9.1.5 E文本文件内容
“9.1.4 E文本文件定义”中各省份/地区电网调度风光功率预测主站上报E文本文件内容,以各省份/地区电网调度发布的新能源风光功率预测系统数据接入调度主站技术文件为准。
9.2 业务指标计算系统
本模块需以功能模块方式与询价方现有的功率预测平台进行集成。
9.2.1 计算逻辑参考标准
西北区域、华北区域、南方区域、华中区域电网及河北、广西、广东、山西、江西、陕西、甘肃等7省调度(包括省调/市调)有关发电厂并网运行管理实施细则。
9.2.2 业务指标参考标准
参照西北区域、华北区域、南方区域、华中区域电网及河北、广西、广东、山西、江西、陕西、甘肃等7省调度(包括省调/市调)有关发电厂并网运行管理实施细则相关功率预测业务考核指标。
9.2.3 接口规范与通信协议9.2.3.1 API 设计标准
1) 必须遵循平台现有的 API 设计规范(如 RESTful 风格、资源命名、状态码使用)。
2) 使用 OpenAPI 3.0(Swagger)提供完整、可测试的接口文档。
3) 所有接口需支持 JSON 格式,编码统一为 UTF-8。
9.2.3.2 认证与授权机制
1) 调用内部服务必须通过统一身份认证(如 OAuth2.0、JWT、API Key + Secret)。
2) 明确权限粒度(如 RBAC 模型),禁止越权访问。
3) 外部调用需通过网关(API Gateway)接入,不得直连后端服务。
9.2.3.3 通信协议与数据格式
1) 同步通信:(略)
2) 异步通信:(略)
9.2.4 对接要求9.2.4.1 用户体系集成
1) 必须复用平台统一用户 ID(如 UID),不得新建独立账号体系。
2) 用户信息通过用户中心服务获取(禁止本地缓存敏感字段如手机号、身份证)。
9.2.4.2 数据一致性保障
1) 涉及跨系统数据变更时,需采用分布式事务方案或最终一致性。
2) 禁止直接读写其他系统的数据库。
9.2.4.3 日志与追踪
1) 所有服务调用需携带全链路 TraceID。
2) 日志格式统一(JSON),包含时间戳、服务名、TraceID、操作人、关键参数等。
3) 日志需接入平台统一日志系统。
9.2.5 代码协作与版本管理要求9.2.5.1 代码仓库与权限
1) 必须在甲方指定的 Git 平台上开发,不得使用外部或私有仓库。
2) 仅授予对指定项目仓库的有限权限:
3) 可创建和推送 feature 分支
4) 不可推送或合并到 main / develop / release/ 等保护分支
5) 不可删除任何已有分支或标签
9.2.5.2 分支策略
1) 开发必须基于甲方提供的基准分支拉出新分支。
2) 功能完成后,通过 Merge Request(MR) 提交合并申请,禁止直接合并。
9.2.5.3 提交与代码质量
1) 提交信息需遵循 Conventional Commits 格式,并关联需求编号(如 JIRA ID)。
2) 代码风格、注释、异常处理等须符合甲方编码规范。
3) 禁止提交:(略)
9.2.6 安全与合规要求9.2.6.1 数据安全
1) 用户敏感信息存储须加密(AES-(略))或脱敏。
2) 日志中不得记录明文密码、Token等 PII 数据。
9.2.6.2 网络与访问控制
1) 服务部署于甲方指定 VPC 子网,网络策略遵循“最小开放”原则。
2) 外部访问必须经过 WAF 和 API 网关,内部服务间通信建议启用 mTLS。
9.2.6.3 漏洞与依赖管理
1) 所有第三方依赖需提供 SCA(软件成分分析)报告。
2) 禁止使用存在高危 CVE 漏洞的组件。
3) 上线前需通过甲方组织的 SAST(静态扫描)与渗透测试。
9.2.7 可观测性与运维集成9.2.7.1 日志
1) 日志格式为结构化 JSON,必须包含字段:
2) timestamp, trace_id, service_name, level, msg, user_id(如适用)
3) 自动接入甲方统一日志系统。
9.2.7.2 监控与告警
1) 暴露标准 Prometheus 指标(请求量、延迟、错误率、资源使用等)。
2) 关键业务异常需主动上报至告警平台。
9.2.7.3 链路追踪
1) 所有服务调用必须透传全局 trace_id。
2) 支持接入甲方追踪系统。
9.2.7.4 健康检查
1) 提供 /health(存活)和 /ready(就绪)探针接口,符合 K8s 规范。
2) 依赖服务不可用时应快速失败,避免雪崩。
9.2.8 部署与交付要求9.2.8.1 容器化
1) 服务必须提供标准 Dockerfile,支持构建为容器镜像。
2) 镜像由甲方 CI 流水线构建并推送到甲方仓库。
9.2.8.2 配置管理
所有配置(数据库地址、密钥等)通过环境变量或 ConfigMap 注入,禁止硬编码。
9.2.8.3 交付物清单
需随 MR 一并提交:
1) 完整源代码(含 Git 提交历史)
2) 接口文档
3) 数据库变更脚本
4) 单元测试 & 集成测试用例(覆盖率 ≥ (略)%)
5) 部署手册、回滚方案、应急处理指南
9.2.9 流程与验收机制9.2.9.1 CI/CD 集成
1) 所有 feature 分支推送后,自动触发甲方 CI 流水线,执行:
2) 代码静态检查(SonarQube)
3) 单元测试 & 覆盖率验证
4) 安全扫描(SAST + SCA)
5) 镜像构建
9.2.9.2 MR 合并门禁
MR 必须满足以下条件才可合并:
1) CI 流水线全量通过
2) 至少 1 名甲方开发人员 Code Review 通过
3) 安全团队无高危风险反馈
4) 需求状态为“已验收”
9.2.9.3 验收标准
1) 功能在预发环境稳定运行 ≥ (略) 小时
2) 通过甲方 QA 团队的集成测试用例
3) 架构师确认无技术债务或架构冲突
(略) 指标要求(略).1性能要求
风光功率预测系统主站程序需至少支持(略)个场站的并发稳定连接;实时数据处理能力不低于(略),(略)点/秒;指令响应内部时延不高于(略)毫秒 。
风光功率预测系统子(从动)站程序需至少支持5个上级主站的并发稳定连接;指令响应时延不高于1秒 。
(略).2可靠性要求
单机系统年平均可用性不低于 (略).(略)%;高可用冗余系统年平均可用性不低于 (略).(略)% 。
平均无故障时间 (MTBF) 不低于 (略),(略)小时 。系统处理及转发的数据,准确率必须为(略)% 。
(略).3安全性要求
需提供基于角色的访问控制(RBAC)、严格的身份认证和不可篡改的操作审计日志。提供图形化配置管理界面和实时运行状态监控仪表盘。
(略).4服务要求
(略).4.1 硬件兼容性
充分兼容询价方现有相关硬件设备。
(略).4.2 信息安全要求
信息安全应符合GB/T (略)和GB/T (略)的要求,系统的身份鉴别、访问控制、安全审计、数据完整性、数据保密性、抗抵赖、软件容错、资源控制、信息探测应满足DL/T (略)要求,程序软件不应存在明显可被利用的漏洞。
(略).4.3 代码管理
供应商/成交人需使用询价方开发环境来进行开发和代码管理,并遵循以下代码管理原则:
? 制定代码规范定:(略)
? 代码目录结构管理:(略)
? 版本控制:(略)
? 代码审查:(略)
? 测试和调试:(略)
? 文档编写:(略)
? 协作和集成:(略)
? 持续改进:(略)
(略) 知识产权
? 供应商/成交人应保证在本项目使用的任何产品和服务(包括部分使用)时,不会产生因第三方提出侵犯其专利权、商标权或其它知识产权而引起的法律和经济纠纷,如因专利权、商标权或其它知识产权而引起法律和经济纠纷,由供应商/成交人承担所有相关责任。
? 根据采购人提供的相关资料和工作条件完成的本项目所有的技术成果和知识产权归询价方所有。供应商/成交人应在本项目实施过程中、项目验收前交付针对本项目的所有开发源代码、源代码说明文档等。
? 技术秘密处理方式。有关本项目开发成果使用和转让的权利归属及由此产生的利益按以下约定处理:
(1) 技术秘密的使用权:(略)
(2) 技术秘密的转让权:(略)
(3) 相关利益的分配办法:(略)
(4) 所有提交至甲方仓库的代码、文档、配置,知识产权归甲方所有。
(5) 项目结束后,配合清理远程 feature 分支,移交全部技术上下文。
(略) 项目实施管理
供应商/成交人应负责提供执行及实施过程中项目管理方案,其内容包含但不限于项目管理、范围管理、进度管理、风险管理、质量管理、协调与合作管理、配置管理、文档管理、保密管理等内容。
供应商/成交人应提供项目的实施目标、实施计划及安排方案、应急处理方案等,在项目实施过程中定期向询价方提交实施进度计划和相关进度报告。
供应商/成交人应提供实施质量保证承诺和质量保证措施方案。
供应商/成交人应提供详细的项目培训方案。
(略).1项目组
组成与职责:(略)
会议制度:(略)
(略).2管理要求
供应商/成交人须使用询价方指定项目管理平台进行项目全周期管理,涵盖项目计划制定、任务分配、进度跟踪、问题反馈、文档管理等所有环节。
供应商/成交人应确保项目管理平台数据的实时性与准确性,项目进度、任务完成情况、质量检验结果、安全检查记录等信息须在相关工作完成后 (略) 小时内录入平台。每日下班前需更新当日任务进展,每周五下午 5 点前提交本周项目总结报告至项目管理平台指定板块。
供应商/成交人需严格按照询价方在项目管理平台设定的项目管理流程执行,包括但不限于任务审批流程、变更管理流程、验收流程等。若对平台流程有优化建议,需提交书面申请,经询价方审核同意后方可调整。
(略).2.1 需求调研与分析
供应商/成交人须组织开展业务需求调研和需求分析阶段,询价方相关业务部门须配合开展相关活动,以便供应商/成交人全面准确的了解业务过程、存在问题和用户需求。在需求调研过程中,供应商/成交人应安排专门的人员对调研沟通情况进行详尽的记录,结束后将对调研记录进行整理,并在调研结束后3个工作日内向询价方相关人员发出,供应商/成交人如有任何异议或补充,则需要在调研记录发出后3个工作日内给出反馈,以保证沟通的准确性和及时性,确保调研记录真实性和准确性。
(略).2.2 项目设计确认
为便于合同的执行、审查和确定系统设计方案,设计方、供应商/成交人与询价方应根据需要举行设计联络会,除按合同规定举行的设计联络会外,双方可以根据需要约定对方举行额外的设计联络会。
每次设计联络会买卖双方均应签署会议纪要,该纪要将视为合同的组成部分。
设计联络会要求如下:
(1)合同生效后两个星期在询价方所在地召开,内容应包括:
(2)确认供应商/成交人提出的有关标准及规范
(3)讨论并澄清合同文件中的技术条款及相应的配置方案
(4)审查并确定初步设计方案
(5)讨论/确定培训计划(包括课程安排、教材、进度)
在合同生效后,供应商/成交人应向询价方提供有关标准、技术规范、初步设计,以及项目进度表、培训计划等。询价方对于上述由供应商/成交人发出的有关标准、规范、初步设计说明等应给予确认或提出修正意见以作为供应商/成交人进行设计的依据,在设联会进行澄清和确认。
(略).2.3 项目沟通
询价方需就本项目指定项目沟通计划,并记录在《项目实施管理计划》中。
(略).2.3.1 沟通机制
信息共享:(略)
反馈渠道:(略)
(略).2.3.2 会议管理
供应商/成交人在项目关键节点须组织召开相关会议,包括项目启动会、评审会议、项目例会、里程碑会议、项目验收会及项目总结会。
项目启动会标志着项目生命周期的起点,此会议明确了项目的目标、范围、进度等关键要素。参会人包括项目经理、项目团队成员、询价方业务部门等,由项目经理介绍项目背景和目标,组建项目团队并分配任务,同时展示项目的详细计划,设置关键里程碑,建立沟通协作机制。
评审会议在项目管理过程中进行,通过集体讨论和审议从多角度、多层次对项目的工作产品进行审查,发现潜在的问题和缺陷。评审内容包括:(略)
项目例会是项目管理过程中的一项常规活动,提供一个集中平台让项目成员能够分享和同步项目的最新进展,包括任务的完成情况、遇到的问题、资源需求以及下一步工作计划,参会人员为项目经理、项目团队成员、询价方业务部门等。
里程碑会议在项目关键阶段或重要事件完成之后召开,会议内容旨在评估与回顾项目进展、明确后续工作计划、识别与解决潜在问题、适时调整项目计划和策略,参会人员为项目经理、项目团队成员、询价方业务部门等。
项目验收会在项目结束之前举行,主要包含对文档资料的验收、技术成果的验收、项目产出产品的验收、项目管理过程的评估以及合约履约情况审查,参会人员包括项目经理、项目团队成员、询价方业务部门等。
项目总结会在项目结束之后举行,会议通过回顾项目的全过程,总结经验教训,识别成功因素和潜在改进点,以便为未来项目提供参考和借鉴,参会人员为项目经理、项目团队成员、询价方业务部门等。
(略).2.3.3 议题跟踪
对于在项目中产生的一些暂时无法达成一致或不具备实施条件的议题,询价方组织供应商/成交人对议题进行跟踪和记录,并分析问题的原因,提供初步的解决方案建议。
(略).2.3.4 日常沟通
在项目实施过程中,除项目周例会等有计划的沟通外,供应商/成交人应建立项目成员日常沟通机制,提供清晰的反馈渠道,如微信群、飞书群等,让团队成员能够就项目提出疑问或建议。
(略).2.4 项目变更管理
提出变更:(略)
评估影响:(略)
审批过程:(略)
(略).2.5 项目文档记录
变更日志:(略)
更新文档:(略)
(略).2.6 项目实施与验证
本项目定制研发的程序软件,在交付询价方前,供应商/成交人负责所有程序软件的开发、调试、性能试验、试运行、验收及上线,并依据本协议规定的标准、规程规范进行。供应商/成交人完成设备安装后,询价方和供应商/成交人应检查和确认安装及调试工作,并签署工作证明书,共两份、双方各执一份。
实施计划:(略)
验证结果:(略)
(略).2.7 项目风险管理
识别潜在风险:(略)
持续监控:(略)
(略) 技术培训
供应商/成交人须为询价方培训一批合格的软件、系统运行、系统管理人员。通过技术培训,确保询价方工作人员在培训后能熟练地掌握系统软件的运行、维护和管理,并能及时排除大部分的障碍。
供应商/成交人应提供详细的培训方案,包含但不限于培训目的、需求、目标、策略、计划和内容。在询价方认可后,由供应商/成交人邀请询价方人员进行培训。
培训人员数量和天数按询价方需求确定。
培训的内容至少包括:
1)用户使用操作培训。
2)向询价方提供运行维护级培训。
3)能够熟悉系统各功能块之间的关系以及系统的软件开发环境和接口等。
4)要求接受培训的人员在培训后,能够熟悉系统的运行、例行检查、维护和一般性故障处理。
5)其它询价方认为需要的培训内容
(略) 文档和资料
供应商/成交人必须按项目不同阶段,提供满足询价方要求的文档资料,包括但不限于:
1)项目启动阶段
项目章程:(略)
2)需求分析阶段
需求规格说明书:(略)
3)系统设计阶段
概要设计说明书:(略)
详细设计说明书:(略)
测试计划/测试用例:(略)
4)开发阶段
项目源代码:(略)
开发文档:(略)
集成测试报告:(略)
版本控制日志
5)测试阶段
安装手册:(略)
用户手册:(略)
系统测试报告、性能测试报告、安全测试报告
6)试运行阶段
试运行报告:(略)
7)系统上线阶段
应急预案:(略)
系统上线报告:(略)
培训材料:(略)
8)系统验收阶段
验收计划:(略)
系统验收报告:(略)
9)项目管理相关
项目状态报告:(略)
(略) 试运行与验收(略).1试运行
项目初验完成后进入项目试运行阶段,试运行时间(略)天。
(略).2验收标准与原则
(略).2.1 验收标准
本项目验收标准除须遵循国家和行业有关业务、技术、数据标准和规范外,须按照询价方以下进行:
《赣电软件采购标准》(江西电建)
《智信能源科技有限公司软件开发项目管理制度》
(略).2.2 验收原则
本项目验收原则主要涉及以下方面:
? 功能性:(略)
? 性能:(略)
? 安全性:(略)
? 易用性:(略)
(略).3项目初验
1) 本项目供应商/成交人提交项目合同货物文件、完成现场安装和其他询价方要求的资料文件,按合同要求完成安装调试和系统测试后由本项目供应商/成交人向询价方提出初验申请并组织实施。
2) 初步验收时间为安装、调试、性能试验和试运行完成后三个月内。在此期间,如果所有的设备都已达到各项技术指标,并稳定运行1个月,双方应签署项目的验收证明书,该证明书共两份、双方各执一份。
3) 初验将由询价方根据合同条款对系统功能和设备清单逐一核对,对不合格项限期予以整改。
4) 完成上述工作并整改后,本项目供应商/成交人向询价方提出初验合格申请并出具证明材料。经询价方批准后,项目通过。
5) 项目初验通过后,进入为期1年的质量保证期。
(略).4项目终验
1)项目终验应在本项目系统测试、初步验收后进行。
2)项目终验的条件。
a.本工程供应商/成交人已完成按合同约定的项目施工安装、测试及试运行工作
b.系统的实际运行的功能和性能以及测试性能指标满足技术规范要求;设备设施的实际运行性能和测试性能指标满足技术规范要求
c.测试出现的问题已被解决至询价方同意,对其它工程项目的影响已消除
d.已按本技术规范和政府有关管理部门的规定提供了全部货物和资料
3)本项目供应商/成交人应按照询价方要求向其提供竣工资料。
5)如果本项目供应商/成交人认为工程已达到约定的项目终验条件,应通知询价方,各方应根据合同约定进行项目终验。
(略) 售后服务要求(略).1质量保证期
本项目定制研发的程序软件,通过项目初验后,供应商/成交人提供须至少提供1年质量保证期,在质量保证期内,由供货方免费硬件和软件系统日常维护及升级迭代服务。
在质量保证期内,由于供应商/成交人程序软件的质量问题而造成停运,供应商/成交人应负责尽快升级、迭代、修复,并赔偿相应损失;同时程序软件的质保期将重新计算。
对于安装、调试、性能试验、试运行及质保期内技术指标一项或多项不能满足要求,双方共同分析原因,分清责任,如属供货方的原因,涉及索赔部分按商务条款执行。
(略).2售后服务
供应商/成交人应提供详细的售后服务方案,包含但不限于以下内容:
1)提供7×(略)小时全国统一服务热线。
2)设立有售后服务中心,其主要职责是快速高效的完成技术服务任务。对客户的服务通知,应在接报后1小时内响应,2小时内到达现场,(略)小时内处理完毕,使系统恢复正常运行。若主要系统的故障在(略)小时内仍未处理完毕,应采取应急措施解决,不影响客户的正常工作业务。
3)供应商/成交人技术服务人员将严格遵守施工现场的各项安全规定,自觉做好安保措施,未经许可不得拆卸、涂抹、损坏、操作客户任何物品设备。各项安装调试内容,应在客户监督下进行。
4)技术服务工作完成后,技术人员应向客户人员讲述本次服务内容,客户认可服务结果后,方可签署相关资料离开。
(略).3服务措施
供应商/成交人应提供具体售后服务措施,对客户的系统使用情况进行跟进。
(略).4应急响应
供应商/成交人应提供系统故障 处理分级响应和服务机制,对不同的故障分级管控处理。