中国电建智信能源科技有限公司集中功率预测平台研发项目 数据交互与计算技术开发服务公开竞价采购公告

****

****公司数据交互与计算技术开发服务

招标采购

审核：陆学锋

编制：张 岷

招标人：****

2026年4月

中国﹒****

邀请函工具

一、采购条件

根据江****公司（以下简称“招标人”）提交审批的集中采购立项计划，以竞价方式采购，采购计****银行****采购所签订合同的支付。

二、项目概况、采购范围

1.项目概况：

1.1项目名称:****公司

1.2到货地址:****公司项目

1.3采购范围：

2.采购清单：

序号	材料名称	规格型号	单位	数量	备注
1	数据交互与计算技术开发服务	技术协议	套	1	含开发安装及调试

以上招标数量可能与实际需求量存在偏差，最终结算量根据工程需要经验收合格实际供货的数量为准,若因投资计划、设计变更等原因，致使投资规模、工程量或供货品种、供货时间发生较大规模改变，采购量及采购品种相应调整，投标人应予接受，并不得以此作为调价和索赔依据。

3.交货时间：按项目部要求。

4.交货地点: ****公司项目 熊仑187****0108

5.质量要求：供货方应提供全新的、符合本项目规定性能的产品，并保证质量与使用寿命。供货方应对产品的制造、工厂试验、包装、供货全面负责；提供必要的安装、检查、维修设备；提交全套技术文件及相关质量检测合格证明文件。

6.付款方式：

6.1支付方式：电汇，配合甲方委托第三方支付。

三、投标单位响应人资格要求

1. 响应人必须满足的条件：

1.1 必须是依照中华人民**国法律设立并在中华人民**国境内登记注册的独立法人，企业注册资本金达到 元人民币及以上，具有效期内的质量管理体系认证证。

1.2必须在中国电建**电建供货商名单范围内。

1.3 经营状况良好，银行资信和商业信誉良好，没有处于被责令停业，财产被接管、冻结及破产状态，近三年经济行为没有受到起诉。具有近三年经第三方审计的财务报表，资产负债结构合理，具备一定的盈利能力，企业的现金流表现正常，资金周转不存在困难。

1.4 在《**企业信用信息公示系统》无经营异常名录信息和严重违法失信企业名单（黑名单）信息。

1.5 近三年企业及法定代表人无行贿犯罪记录，近三年在《**企业信用信息公示系统》中无产品质量的行政处罚信息。

2.本次不接受联合体投标。

3.3.响应人须为一般纳税人，具有提供增值税专用发票（税率13%）的能力。

4. 响应人不存在《中华人民**国招标投标法》、《中华人民**国招标投标法实施条例》禁止投标的情形。

四、文件的获取

1.凡满足本公告规定的响应人资格要求并有意参加的，要求在中国电建**电建采购平台免费注册、在线报名并上传下列资料（合并文件上传）：

购买文件经办人身份证和法定代表人签发的针对本项目购买文件授权委托书或介绍信（加盖公章）扫描件。

资质证明文件：营业执照；业绩证明及质量证明文件

2.已注册、报名、上传合格资料的，请在上述时间内在中国电建集中采购电子平台下载文件。

3. 文件每套工本费为人民币（大写）：0（￥0.00）。

五、评标办法 1.竞价:报价总价含开发安装及调试费用，含税金(专用带抵扣联13%增值税发票或电子专票)、包装费、运输费、保险费、仓储费、损耗费备品备件费用及后续相关费用(包括但不限于后续的开箱检验、检验、产品培训、技术服务等伴随服务的费用)。 标书代写

2.付款方式：3个月(验收合格)付款90％；10％质保一年后付清。

六、联系方式

招 标 人： ****

地 址： **市**路69号

邮 编： 330001

联 系 人： 张岷138****4486

咨 询： 熊仑187****0108

八、监督机构

江****公司纪委办

监督电话：0791-****2811

开放式智慧一体化集中功率预测平台研发项目

数据交互与计算技术开发服务采购

技术协议

****公司

二零二六年三月

1 项目背景

随着新能源装机规模的持续增加、电网对新能源数据的考核不断升级，对新能源场站的短期预报准确率、超短期预报准确率、预测完整性、单机信息和测风数据合理性和完整性、系统可靠性提出了更高的要求。

为解决目前单个场站预报准确率低、模型优化困难、可靠性差、维护成本高、网络安全无法保障等难题，同时为****电厂风功率预测系统进行集中管理，随时查看各站的实时数据采集情况、预报情况和上报情况，了解当前所有场站预报的发电量等业务需求，****公司（以下简称“智信能科”）自主研发了一套开放式集中功率预测平台（以下“平台”或“平台端”，初步建立了自主可控的运营保障系统，实现了新能源功率预测，****电厂运行效率，减少电网考核经济损失，提高未来售电竞争力提供了基础支撑条件。

2 项目目的

本项目旨在建设一套遵循《风光一体集中接入通讯系统102规约》（采用规约在原有的DL/T 719-2000协议基础上增加ASDU功能）的数据交互与计算系统。该系统需能同时满足开放式集中功率预测平台场站侧作为风光功率预测系统子站，统一上报数据的从动站（服务端），作为主站（启动端）统一数据接收的客户端双重功能，同时对数据上报后的业务指标表现进行计算，****调度中心、平台端及第三方风光功率预测系统子站之间的信息交互通道，及业务表现趋势分析。

3 项目范围

本项目拟建设的数据交互与计****公司自主研发的开放式集中功率预测平台子系统（功能），能够满足**、**、**、**、**、**、**等7省个省份/地区电网调度管辖下范围内，开放式集中功率预测平台作为新能源场站风光功率预测系统子站和主站角色，以E文本方式传输上述各省份/地区电网调度新能源场站运行数据文件，具体文件定义见“9.1.4 E文本文件定义”。

4 总体原则

□ 标准化与合规性:数据交互与计算系统设计与实现必须严格遵守国家及电力行业的相关标准与规范，核心通信协议必须完整、准确地实现102规约的全部要求。所有数据文件的格式、命名及内容必须符****调度中心的具体管理规定。

□ 可靠性与可用性:数据交互与计算系统必须具备高度的可靠性，关键部件和功能模块应有冗余设计。应具备完善的故障自诊断、自恢复能力和详细的日志记录功能。

□ 安全性:数据交互与计算系统必须具备全面的安全防护能力，包括网络访问控制、用户身份鉴别、权限管理和日志审计。部署于电力安全二区的系统，必须与外部网络进行有效隔离并采取严格的安全加固措施。

5 工作范围

基于本项目拟建设的数据交互与计算系统，供应商/成交人工作范围包括且不限于：

（1）完成开放式集中功率预测平台场站侧，电网调度风光功率预测系统主站所需数据文件的生成与上报程序（风光功率预测系统子(从动)站角色，服务端）的开发与源代码交付，该程序上报能力所需覆盖的省份/地区电网调度见“3 项目范围”，功能要求见“9.1 102数据交互系统”。

（2）完成包括开放式集中功率预测系统在内的第三方风光功率预测系统子站所发送的系统数据的接收、解析与转发程序（风光功率预测系统主站角色，客户端）的开发与源代码交付，该程序接收和解析数据能力所需覆盖的省份/地区电网调度见“3 项目范围”，功能要求见“9.1 102数据交互系统”。

（3）按照所需覆盖的省份/地区电网调度的两个细则考核规则，进行上报数据的业务指标计算程序的开发与源代码交付，业务指标所参照的标准规范和业务指标计算要求见“9.2 业务指标计算系统”。

（3）完成上述（1）、（2）、（3）所提及程序单元测试、集成测试、系统测试、试运行。

（4）完成上述（1）、（2）、（3）所提及程序与开放式集中功率预测平台端及场站端的系统集成与联合测试。

（5）协助询价方完成**、**、**、**、**、**、**等7省个省份/地区电网调度风光各一个新能源场站（1）和（2）所提及程序与电网调度的联调，协助方式包括但不限于远程协助和现场协助。

（6）协助供应商/成交人在询价方自有开发环境，完成上述（1）和（2）所提及程序源代码的部署、调试、启动及打包。

（7）其他询价方协助掌握供应商/成交人程序或代码所必须的工作，包括但不限于如详细设计解读、代码逻辑解读等。

6 参考标准

GB/T 36572 电力监控系统网络安全防护导则

GB/T 40607 调度侧风电或光伏功率预测系统技术要求

NB/T 32031—2025 光伏发电功率预测系统功能规范

NB/T 31046 风电功率预测系统功能规范

7 项目要求7.1 资质业绩

（1） 供应商/成交人须具备信息安全服务资质认证书、电子与智能化工程专业承包二级及以上资质，具备电力系统信息化项目现场实施、调试及运维能力；

（2） 供应商/成交人须拥有至少2项与新能源功率预测、数据通信相关的发明专利证书（专利权利人为供应商/成交人本身，无权属争议、未被质押）；

（3） 如供应商/成交人无法满足上述要求，则视供应商/成交人不满足询价方要求。

7.2 交付清单

供应商/成交人在报价时应按单个省份进行报价，并另行对新增风光功率预测系统子（从动）站程序和风光功率预测系统主站程序单独报价，供甲方新增范围参照。以下为本项目询价方交付清单：

表7-1 项目交付清单表

7.3 交付周期

本项目采用分阶段交付方式，具体交付时间，根据甲方需求进行调整，初步交付时间节点如下表：

表7-2 项目交付时间节点

序号	省份	优先级	最晚交付时间	备注
	**	高	2026年3月	华北区域
	**	高	2026年4月	华北区域
	**	高	2026年4月	南方区域
	**	中	2026年5月	华中区域
	**	中	2026年5月	西北区域
	**	中	2026年6月	西北区域
	**	高	2026年7月	南方区域

8 职责与分工8.1 供应商/成交人责任

供应商/成交人应指派项目经理与询价方协调项目实施的各项工作，并在进场前7天，向询价方提供项目实施团队组织架构图及人员联系表，保持与询价方的联系。

供应商/成交人应根据询价方的需求作出科学的、完善的、规范的需求分析报告、总体设计报告、项目实施方案和工程进度计划表，并经双方认可之后，开始系统详细设计和部署实施。

供应商/成交人负责系统的设计、部署、调试、完善、开发和维护文档的编写、整理和修订。

供应商/成交人负责开展面向系统管理员的应用程序运行、管理和维护的专业知识及开发工具指导。对有关人员作针对应用系统的使用指导。

供应商/成交人应在项目执行过程中分阶段提交下述图纸及资料：系统总体规划设计、系统进度计划、系统用户使用说明书、系统维护手册，具体内容详见“13 文档和资料”有关要求。

供应商/成交人软硬件设计开发文档应严格按照国家和电力行业的管理信息系统开发规范编制并提交。

供应商/成交人应按照合同要求，在本合同规定的时间内完成本项目的设计、开发、部署、调试和运行、验收等。

供应商/成交人须接受询价方对项目的监管。

8.2 询价方责任

询价方应配合供应商/成交人完成系统实施和部署工作。

询价方应指派专人成立项目工作组，负责质量的监督和办理本项目中商定的事宜。

询价方有权对本项目的技术方案、体系结构、进度、质量、实施人员进行有效监管。

询价方应做好本项目的实施协调配合工作，负责协调供应商/成交人与相关部门的关系，对供应商/成交人项目建设过程中呈报的有关报告及时批复。

询价方应根据本合同中规定的验收标准，在系统试运行完成后的三个月内组织项目初步验收。项目初步验收通过后，询价方为供应商/成交人签发验收证书和完工交接证书。

9 技术要求9.1 102数据交互系统9.1.1 102规约技术说明

本技术协议提及的**、**、**、**、**、**、**等7省个省份/地区电网调度风光功率预测系统102规约，均参考中华人民**国电力行业标准DL/T 634.5.104-2002和DL/T719-2000规定的传输规约，并在原有的DL/T 719-2000协议基础上增加ASDU功能。

上述各省风光功率预测系统102规约采用DL/T 719-2000第5章规定的非平衡传输规则，即传输过程的启动仅限于某一固定点，在本规约中调度为主站端，作为启动端，而风光功率预测系统为子站，始终为从动站。风光功率预测系统为子站系统的基本问答过程是采用带有功能码11的请求2级用户数据的请求响应服务，1级数据如同IEC60870-5-2 所定义的用请求访问位（ACD bit）来表示。采用 C/S 方式，遵从 TCP/IP协议，主站作为客户端，子站为服务端。

上述各省份/地区电网调度风光功率预测系统102规约帧格式、帧单元说明、控制流程、数据帧格式、数据帧格式及类型标识，以各省份/地区电网调度发布的标准文件为准。

因各省份/地区电网调度风光功率预测主站102规约类型标识存在差异，且均按照自身情况进行自定义，供应商/成交人需在本项目数据交互与计算系统建设方案中予以体现和文字说明，否则视为不满足询价方要求。

9.1.2 系统基本功能要求9.1.2.1 数据通信交互流程

表9-1开放式集中功率预测平台数据通信交互流程图

下载

9.1.2.2 子（从动）站服务端

作为独立功能（服务），是开放式集中功率预测平台场站侧数据上报主站（如调度、平台端）的唯一出口，严格遵循各省级/地区级新能源场站风光功率预测系统主站102规约的从动站服务端角色，主要满足如下技术要求。

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、IEC104、OPC、Modbus、数据库视图等），从场站内各数据源（如SCADA、功率预测系统等）高效获取数据。

2) 对从场站内各数据源获取到的各类数据，按照“8.4 E文本文件定义”所需内容进行数据加工、预处理、存储、查询等，以满足各省级/地区级电网调度新能源场站风光功率预测系统主站数据要求。

3) 内置灵活的任务调度引擎，能够自动、准时地生成各省级/地区级电网调度新能源场站风光功率预测系统主站要求的标准化数据文件，文件类型见“9.1.4 E文本文件定义”。

9.1.2.2.3 文件传输控制与交互

1) ASDU封装与分帧: 必须将生成的标准文件封装为省级/地区级新能源场站风光功率预测系统主站102规约ASDU进行传输，并正确填充类型标识、传送原因（COT）和公共地址 。必须具备长文件自动分帧传输能力，并正确使用传送原因（COT）字段来标识文件的起始帧、中间帧和结束帧 。

2) 传输应答处理:能够正确解析主站返回的针对文件传输的各类确认报文，并执行相应动作 。

a) 收到主站的文件接收成功确认后，标记该文件为发送成功 。

b) 收到主站的异常确认后，必须记录详细日志并根据预设策略进行处理。需正确响应的异常确认包括：文件长度不符、重复传输、文件过长、文件名不合规等。

c) 向开放式集中功率预测平台场站侧系统反馈与多个主站的文件传输状态，如上传成功、上传失败、异常信息等。

9.1.2.2.4 系统集成

本模块需与询价方现有的功率预测场站端系统、调度侧主站系统实现数据对接，用于接收场站端数据，转化为102规约/mqtt协议规定的数据格式，并上报至调度/平台端。

1) 数据交互类型：供应商/成交人提供接口，供询价方现有的功率预测场站端系统调用并接受询价方调度；

2) 数据交互协议与形式：询价方通过HTTP协议提供JSON格式数据，或者提供数据库直连方式。

3) 数据交互安全要求：数据的所有权归询价方所有，供应商/成交人对本项目生产或使用的数据有保密义务，未经询价方同意，不得擅自挪作他用；

4) 数据交互性能要求：供应商/成交人需保证接口响应时间≤10秒；

5) 服务部署要求：与功率预测场站端共享服务器**，不额外单独为供应商/成交人提供部署服务器；服务器操作系统为Kylin Linux Advanced Server release V10 SP3（x86）。

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) 任务轮询:支持对不同场站、不同数据类型（1级、2级数据）设置独立的轮询周期，轮询对象、任务、周期等可配置。

2) 控制域管理: 为每一个场站链路维护独立的帧计数位（FCB），在发起新的请求/响应服务时，能正确翻转FCB位并置位帧计数有效位（FCV） 。在指令发送超时或收到错误报文后，能够按规约要求进行重发，重发期间FCB位保持不变 。

3) 指令下发:提供操作界面或API接口，允许调度员手动向下辖的单个或多个场站下发各类102指令，如“总召唤”、“复位通信单元”等，并对所有下发指令及其响应结果进行明确记录 。

9.1.2.3.3 数据接收与文件处理

1) 报文接收与解析:能够并发接收来自单个或多个场站的上行数据报文，支持ASDU高效解析。

2) 文件重组与校验:具备文件传输流处理能力，能够根据场站地址和文件信息，将分帧传输的数据包进行缓存和重组。通过检查传送原因（COT）字段，判断文件传输是否结束。

3) 数据存储与转发:接收并校验通过的实时数据需能解析并还原为各省级/地区级电网调度新能源场站风光功率预测系统主站要求的标准化数据文件，文件类型见“9.1.4 E文本文件定义”，同时能够以MQTT 客户端形式将接收并校验通过的实时数据转为MQTT消息，发送至开放式集中功率预测平台。

9.1.2.3.4 应答与确认机制

1) 在成功接收并重组文件后，系统必须能自动生成并发送包含文件长度的确认报文。

2) 在检测到异常情况时，能自动发送相应的否定确认报文，主要包括：

a) 检测到重复文件，发送重复传输告知报文。

b) 接收文件超过规定最大长度，发送文件过长告知报文。

c) 文件名或格式不符合规范，发送格式错误告知报文。

d) 单帧报文过长，发送单帧超长告知报文。

3) 向开放式集中功率预测平台场站侧系统反馈与子（从动）站的文件传输状态，如上传成功、上传失败、异常信息等。

9.1.3 系统高级功能要求

本项目拟建设的数据交互与计算系统除满足基础功能要求外，针对**、**、**、**南网等电网调度，还必须实现以下高级功能：

●全系统高可用性冗余:针对部分电网省级调度风光功率预测系统主站，要求同时支持多个上报通道的情况，项目拟建设的数据交互与计算系统系满足采用“双机热备”或“N+M集群”部署方案，具备应用级故障侦测和全自动分钟级切换能力。主备/集群节点间必须有高效、可靠的状态同步机制（包括连接状态、规约会话状态、数据缓存等），确保切换后业务无缝接管。

●多目的地/多源并发通信: 本项目拟建设的数据交互与计算系统必须支持同时与多个调度主站（省调、地调等）建立和维持独立的102通信链路，并能按策略向不同主站发送不同数据 。

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	升压站信息
10		E文本-ZTXX-QXHJ-TYGZ	光伏电站总体信息-气象环境-太阳跟踪系统信息
11		E文本-AGC-AVC	AGC-AVC信息
12		E文本-DQYC	光伏短期功率预测信息
13		E文本-CDQYC	光伏超短期功率预测信息
14		E文本-TJXX	光伏电站统计信息
15		E文本-NBQ-HLX	光伏逆变器/汇流箱信息

9.1.4.2 **省

表9-2 **省新能源场站风光功率预测系统E文本文件定义

序号	新能源类型	文件名称	上述数据
1	风电场	E文本- 72wind	风电未来3或10天天短期功率预测信息
2		E文本- 4Cwind	风电超短期功率预测信息
3		E文本- 72nwp	风电未来72小时或240小时天气预报信息
4		E文本- 24nwp	风电未来24小时天气预报信息
5		E文本- FJ	风机信息
6		E文本- DJ	风电场单机信息
7		E文本-CFT	风电测风塔实测信息
8	光伏电站	E文本- 72wind	光伏未来3或10天天短期功率预测信息
9		E文本- 4Cwind	光伏超短期功率预测信息
10		E文本- 72nwp	光伏未来72小时或240小时天气预报信息
11		E文本- 24nwp	光伏未来24小时天气预报信息
12		E文本- DJ	逆变器单机信息
13		E文本-QX	光伏气象站实测信息

9.1.4.3 **省

表9-3 **省新能源场站风光功率预测系统E文本文件定义

序号	新能源类型	文件名称	上述数据
1	风电场	E文本- DQ	风电未来8天短期功率预测信息
2		E文本-TDQ	风电未来10天的预测及开机容量
3		E文本- CDQ	风电超短期功率预测信息
4		E文本- FJ	风电机组状态数据
5		E文本-DL	风电未来12月的电量预测数据
6		E文本-CFT	风电测风塔实测信息
7		E文本-THEROY	风电理论功率
8	光伏电站	E文本- DQ	风电未来8天短期功率预测信息
9		E文本-TDQ	光伏未来10天的预测及开机容量
10		E文本-CDQ	光伏超短期功率预测信息
11		E文本-NBQ	逆变器运行信息
12		E文本-DL	光伏未来12月的电量预测数据
13		E文本-QXZ	光伏气象站实测信息
14		E文本-THEROY	光伏理论功率

9.1.4.4 **省

表9-4 **省新能源场站风光功率预测系统E文本文件定义

序号	新能源类型	文件名称	上述数据
1	风电场	E文本- 240wind	风电未来10天短期功率预测信息
2		E文本- 4Cwind	风电超短期功率预测信息
3		E文本- 4CKJ	风电超短期开机容量信息
4		E文本- 240nwp	风电未来240小时天气预报信息
5	光伏电站	E文本- 240wind	光伏未来10天短期功率预测信息
6		E文本- 4Cwind	光伏超短期功率预测信息
7		E文本- 4CKJ	光伏超短期开机容量信息
8		E文本- 240nwp	光伏未来240小时天气预报信息

9.1.4.5 **省

表9-5 **省新能源场站风光功率预测系统E文本文件定义

序号	新能源类型	文件名称	上述数据
1	风电场	E文本- ZR	风电昨日开机容量
2		E文本- DQ	风电未来10短期功率预测第一报
3		E文本- DQ02	风电未来10天短期功率预测第二报
4		E文本- CDQ	风电超短期功率预测信息
5		E文本- 24nwp	风电未来24小时天气预报信息
6		E文本- 240nwp	风电未来240小时天气预报信息
7		E文本- 96TheoryPower	风电离线理论功率
8		E文本- RtTheoryPower	风电在线理论功率
9		E文本- 24wind	风电未来72小时极端天气影响预测出力
10		E文本- WThCDQ	风电极端天气影响实时状态
11	光伏电站	E文本- ZR	光伏未来10天天短期功率预测信息
12		E文本- DQ	光伏超短期功率预测信息
13		E文本- DQ02	光伏未来10天短期功率预测第二报
14		E文本- CDQ	光伏超短期功率预测信息
15		E文本- 24nwp	光伏未来24小时天气预报信息
16		E文本- 240nwp	光伏未来240小时天气预报信息
17		E文本- 96TheoryPower	光伏离线理论功率
18		E文本- RtTheoryPower	光伏在线理论功率
19		E文本- 24wind	光伏未来72小时极端天气影响预测出力
20		E文本- EWmeter_	光伏极端天气影响实时状态

9.1.4.6 **省南网

表9-6 **省南网新能源场站风光功率预测系统E文本文件定义

序号	新能源类型	文件名称	上述数据
1	风电场	E文本- DQ	风电未来10短期功率预测
2		E文本- CDQ	风电超短期功率预测信息
3		E文本-CFT	风电测风塔实测信息
4	光伏电站	E文本- DQ	光伏未来10天天短期功率预测信息
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) 同步通信：HTTP/HTTPS（强制 TLS 1.2+）。

2) 异步通信：若使用消息队列（如 Kafka、RabbitMQ），需遵循平台的消息格式、Topic 命名规范、重试与死信策略。

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-256）或脱敏。

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) 单元测试 集成测试用例（覆盖率 ≥ 80%）

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) 功能在预发环境稳定运行 ≥ 72 小时

2) 通过甲方 QA 团队的集成测试用例

3) 架构师确认无技术债务或架构冲突

10 指标要求10.1 性能要求

风光功率预测系统主站程序需至少支持500个场站的并发稳定连接；实时数据处理能力不低于100,000点/秒；指令响应内部时延不高于500毫秒 。

风光功率预测系统子（从动）站程序需至少支持5个上级主站的并发稳定连接；指令响应时延不高于1秒 。

10.2 可靠性要求

单机系统年平均可用性不低于 99.95%；高可用冗余系统年平均可用性不低于 99.99% 。

平均无故障时间 (MTBF) 不低于 10,000小时 。系统处理及转发的数据，准确率必须为100% 。

10.3 安全性要求

需提供基于角色的访问控制（RBAC）、严格的身份认证和不可篡改的操作审计日志。提供图形化配置管理界面和实时运行状态监控仪表盘。

10.4 服务要求

10.4.1 硬件兼容性

充分兼容询价方现有相关硬件设备。

10.4.2 信息安全要求

信息安全应符合GB/T 22239和GB/T 36572的要求，系统的身份鉴别、访问控制、安全审计、数据完整性、数据保密性、抗抵赖、软件容错、**控制、信息探测应满足DL/T 1455要求，程序软件不应存在明显可被利用的漏洞。

10.4.3 代码管理

供应商/成交人需使用询价方开发环境来进行开发和代码管理，并遵循以下代码管理原则：

制定代码规范定：在项目开始之前，制定一套公认的代码编写规则和标准，以确保代码的优秀、合理和易于维护。

代码目录结构管理：需进行代码的目录结构进行，以便于代码的维护、更**协作。目录结构应该清晰、有组织，并且与软件的层次结构相匹配。

版本控制：使用自有开发环境来管理代码的版本，确保每个成员都能获取到正确的代码版本，追踪代码的变更历史，以便于排查问题和进行回归测试。

代码审查：定期进行代码审查，以确保代码的质量和规范。通过审查代码，可以发现潜在的问题并提高代码的整体质量。

测试和调试：编写测试用例并执行测试，以确保代码的正确性和稳定性。同时，还需要对代码进行调试，以修复任何错误或异常。

文档编写：为代码编写文档，以便于其他开发人员理解和使用代码。文档应该清晰、简洁，并包含必要的说明和示例。

协作和集成：在开发团队中协作和集成代码，以确保代码的一致性和可维护性。使用版本控制系统和集成开发环境（IDE）等工具来简化代码的协作和集成过程。

持续改进：不断优化代码，以提高其性能和可维护性。定期对代码进行重构和优化，以减少不必要的复杂性，提高代码的可读性和可维护性。

11 知识产权

□ 供应商/成交人应保证在本项目使用的任何产品和服务（包括部分使用）时，不会产生因第三方提出侵犯其专利权、商标权或其它知识产权而引起的法律和经济纠纷，如因专利权、商标权或其它知识产权而引起法律和经济纠纷，由供应商/成交人承担所有相关责任。

□ 根据采购人提供的相关资料和工作条件完成的本项目所有的技术成果和知识产权归询价方所有。供应商/成交人应在本项目实施过程中、项目验收前交付针对本项目的所有开发源代码、源代码说明文档等。

□ 技术秘密处理方式。有关本项目开发成果使用和转让的权利归属及由此产生的利益按以下约定处理：

(1) 技术秘密的使用权： 归询价方所有；

(2) 技术秘密的转让权： 归询价方所有；

(3) 相关利益的分配办法： 归询价方所有。

(4) 所有提交至甲方仓库的代码、文档、配置，知识产权归甲方所有。

(5) 项目结束后，配合清理远程 feature 分支，移交全部技术上下文。

12 项目实施管理

供应商/成交人应负责提供执行及实施过程中项目管理方案，其内容包含但不限于项目管理、范围管理、进度管理、风险管理、质量管理、协调与**管理、配置管理、文档管理、保密管理等内容。

供应商/成交人应提供项目的实施目标、实施计划及安排方案、应急处理方案等，在项目实施过程中定期向询价方提交实施进度计划和相关进度报告。

供应商/成交人应提供实施质量保证承诺和质量保证措施方案。

供应商/成交人应提供详细的项目培训方案。

12.1 项目组

组成与职责：项目组通常由来自不同利益相关者的代表组成，****公司管理层、询价方项目经理、供应商/成交人项目经理及其他必要人员等。其主要职责是对变更请求进行审查，决定是否批准实施变更，并监督变更的执行情况。

会议制度：询价方或供应商/成交人项目经理召开变更控制会议，讨论待处理的变更请求，紧急情况下可临时召集会议。

12.2 管理要求

供应商/成交人须使用询价方指定项目管理平台进行项目全周期管理，涵盖项目计划制定、任务分配、进度跟踪、问题反馈、文档管理等所有环节。

供应商/成交人应确保项目管理平台数据的实时性与准确性，项目进度、任务完成情况、质量检验结果、安全检查记录等信息须在相关工作完成后 24 小时内录入平台。每日下班前需更新当日任务进展，每周五下午 5 点前提交本周项目总结报告至项目管理平台指定板块。

供应商/成交人需严格按照询价方在项目管理平台设定的项目管理流程执行，包括但不限于任务审批流程、变更管理流程、验收流程等。若对平台流程有优化建议，需提交书面申请，经询价方审核同意后方可调整。

12.2.1 需求调研与分析

供应商/成交人须组织开展业务需求调研和需求分析阶段，询价方相关业务部门须配合开展相关活动，以便供应商/成交人全面准确的了解业务过程、存在问题和用户需求。在需求调研过程中，供应商/成交人应安排专门的人员对调研沟通情况进行详尽的记录，结束后将对调研记录进行整理，并在调研结束后3个工作日内向询价方相关人员发出，供应商/成交人如有任何异议或补充，则需要在调研记录发出后3个工作日内给出反馈，以保证沟通的准确性和及时性，确保调研记录真实性和准确性。

12.2.2 项目设计确认

为便于合同的执行、审查和确定系统设计方案，设计方、供应商/成交人与询价方应根据需要举行设计联络会，除按合同规定举行的设计联络会外，双方可以根据需要约定对方举行额外的设计联络会。

每次设计联络会买卖双方均应签署会议纪要，该纪要将视为合同的组成部分。

设计联络会要求如下：

（1）合同生效后两个星期在询价方所在地召开，内容应包括：

（2）确认供应商/成交人提出的有关标准及规范

（3）讨论并澄清合同文件中的技术条款及相应的配置方案

（4）审查并确定初步设计方案

（5）讨论/确定培训计划(包括课程安排、教材、进度)

在合同生效后，供应商/成交人应向询价方提供有关标准、技术规范、初步设计，以及项目进度表、培训计划等。询价方对于上述由供应商/成交人发出的有关标准、规范、初步设计说明等应给予确认或提出修正意见以作为供应商/成交人进行设计的依据，在设联会进行澄清和确认。

12.2.3 项目沟通

询价方需就本项目指定项目沟通计划，并记录在《项目实施管理计划》中。

12.2.3.1 沟通机制

信息共享：建立有效的沟通机制，确保所有受影响的相关方都能及时了解变更的内容及其影响。

反馈渠道：提供清晰的反馈渠道，让团队成员能够就变更事项提出疑问或建议。

12.2.3.2 会议管理

供应商/成交人在项目关键节点须组织召开相关会议，包括项目启动会、评审会议、项目例会、里程碑会议、项目验收会及项目总结会。

项目启动会标志着项目生命周期的起点，此会议明确了项目的目标、范围、进度等关键要素。参会人包括项目经理、项目团队成员、询价方业务部门等，由项目经理介绍项目背景和目标，组建项目团队并分配任务，同时展示项目的详细计划，设置关键里程碑，建立沟通协作机制。

评审会议在项目管理过程中进行，通过集体讨论和审议从多角度、多层次对项目的工作产品进行审查，发现潜在的问题和缺陷。评审内容包括：需求文档、设计文档、测试计划等，参与评审人员为：项目经理、项目团队成员、询价方业务部门等。

项目例会是项目管理过程中的一项常规活动，提供一个集中平台让项目成员能够分享和同步项目的最新进展，包括任务的完成情况、遇到的问题、**需求以及下一步工作计划，参会人员为项目经理、项目团队成员、询价方业务部门等。

里程碑会议在项目关键阶段或重要事件完成之后召开，会议内容旨在评估与回顾项目进展、明确后续工作计划、识别与解决潜在问题、适时调整项目计划和策略，参会人员为项目经理、项目团队成员、询价方业务部门等。

项目验收会在项目结束之前举行，主要包含对文档资料的验收、技术成果的验收、项目产出产品的验收、项目管理过程的评估以及合约履约情况审查，参会人员包括项目经理、项目团队成员、询价方业务部门等。

项目总结会在项目结束之后举行，会议通过回顾项目的全过程，总结经验教训，识别成功因素和潜在改进点，以便为未来项目提供参考和借鉴，参会人员为项目经理、项目团队成员、询价方业务部门等。

12.2.3.3 议题跟踪

对于在项目中产生的一些暂时无法达成一致或不具备实施条件的议题，询价方组织供应商/成交人对议题进行跟踪和记录，并分析问题的原因，提供初步的解决方案建议。

12.2.3.4 日常沟通

在项目实施过程中，除项目周例会等有计划的沟通外，供应商/成交人应建立项目成员日常沟通机制，提供清晰的反馈渠道，如微信群、飞书群等，让团队成员能够就项目提出疑问或建议。

12.2.4 项目变更管理

提出变更：任何关于项目范围、时间表、成本预算、技术规范等方面的变更请求应由供应商/成交人项目经理提交给询价方项目经理。变更请求需包含变更的理由、预期的影响以及建议的解决方案。

评估影响：供应商/成交人项目经理项目经理负责组织对变更请求进行全面评估，包括但不限于对项目进度、成本、质量、**等方面的影响分析。

审批过程：询价方项目经理根据变更的性质和影响程度，变更请求将提交给相应的项目组或其他决策机构进行审核批准。对于重大变更，需询价方管理层的最终批准。

12.2.5 项目文档记录

变更日志：所有变更请求及其状态（提出、评估、批准/拒绝、实施、验证）都应在变更日志中详细记录，以便跟踪和审计。

更新文档：一旦变更获得批准，相关的项目计划、规格说明书、合同文件等都需要及时更新以反映最新的要求。

12.2.6 项目实施与验证

本项目定制研发的程序软件，在交付询价方前，供应商/成交人负责所有程序软件的开发、调试、性能试验、试运行、验收及上线，并依据本协议规定的标准、规程规范进行。供应商/成交人完成设备安装后，询价方和供应商/成交人应检查和确认安装及调试工作，并签署工作证明书，共两份、双方各执一份。

实施计划：对于已批准的变更，制定详细的实施计划，明确责任人、时间节点和所需**。

验证结果：变更实施完成后，必须进行验证，以确保变更达到了预期效果且没有引入新的问题。

12.2.7 项目风险管理

识别潜在风险：在评估变更请求的过程中，要特别注意识别由此带来的新风险，并制定相应的缓解措施。

持续监控：在整个项目生命周期内持续监控变更相关的风险状况，必要时调整风险管理策略。

13 技术培训

供应商/成交人须为询价方培训一批合格的软件、系统运行、系统管理人员。通过技术培训，确保询价方工作人员在培训后能熟练地掌握系统软件的运行、维护和管理，并能及时排除大部分的障碍。

供应商/成交人应提供详细的培训方案，包含但不限于培训目的、需求、目标、策略、计划和内容。在询价方认可后，由供应商/成交人邀请询价方人员进行培训。

培训人员数量和天数按询价方需求确定。

培训的内容至少包括：

1）用户使用操作培训。

2）向询价方提供运行维护级培训。

3）能够熟悉系统各功能块之间的关系以及系统的软件开发环境和接口等。

4）要求接受培训的人员在培训后，能够熟悉系统的运行、例行检查、维护和一般性故障处理。

5）其它询价方认为需要的培训内容

14 文档和资料

供应商/成交人必须按项目不同阶段，提供满足询价方要求的文档资料，包括但不限于：

1）项目启动阶段

项目章程：项目正式启动标志，进行项目授权，明确项目目标及**。

2）需求分析阶段

需求规格说明书：将用户需求转化为详细的系统要求。

3）系统设计阶段

概要设计说明书：概述系统架构、模块划分和接口设计。

详细设计说明书：详细描述每个模块的设计，包括业务流程图、系统流程图、状态机、页面原型等。

测试计划/测试用例：详细测试策略、测试范围、测试方法和时间安排，****种场景的测试案例

4）开发阶段

项目源代码：遵循预定编码规范编写的源代码

开发文档：包括关键类、函数、数据库的注释和设计说明，确保代码可维护性

集成测试报告：记录系统集成测试结果、缺陷记录及修复情况

版本控制日志

5）测试阶段

安装手册：指导用户如何安装和配置软件，提供系统维护、故障排查和升级指南。

用户手册：介绍软件功能、操作步骤和使用指南。

系统测试报告、性能测试报告、安全测试报告

6）试运行阶段

试运行报告：包含试运行的范围、时间安排、**分配以及测试策略

7）系统上线阶段

应急预案：确保系统名称在上线过程中或上线后的运维阶段，面对可能出现的突发事件或异常情况，能够迅速、有效地采取应对措施。

系统上线报告：记录上线期间的运行情况与优化过程。

培训材料：对用户进行操作和维护培训的材料

8）系统验收阶段

验收计划：明确项目的验收标准、验收流程、时间安排和责任分配，确保项目符合预定的质量要求

系统验收报告：确认软件符合合同约定的质量和功能要求

9）项目管理相关

项目状态报告：定期汇报项目进展、问题和下一步计划。

15 试运行与验收15.1 试运行

项目初验完成后进入项目试运行阶段，试运行时间90天。

15.2 验收标准与原则

15.2.1 验收标准

本项目验收标准除须遵循国家和行业有关业务、技术、数据标准和规范外，须按照询价方以下进行：

《赣电软件采购标准》（**电建）

《****公司软件开发项目管理制度》

15.2.2 验收原则

本项目验收原则主要涉及以下方面：

□ 功能性：所有的功能需本协议要求实现。

□ 性能：系统性能需达到既定标准。

□ 安全性：系统符合安全规范和标准。

□ 易用性：用户界面**，易于操作。

15.3 项目初验

1） 本项目供应商/成交人提交项目合同货物文件、完成现场安装和其他询价方要求的资料文件，按合同要求完**装调试和系统测试后由本项目供应商/成交人向询价方提出初验申请并组织实施。

2） 初步验收时间为安装、调试、性能试验和试运行完成后三个月内。在此期间，如果所有的设备都已达到各项技术指标，并稳定运行1个月，双方应签署项目的验收证明书，该证明书共两份、双方各执一份。

3） 初验将由询价方根据合同条款对系统功能和设备清单逐一核对，对不合格项限期予以整改。

4） 完成上述工作并整改后，本项目供应商/成交人向询价方提出初验合格申请并出具证明材料。经询价方批准后，项目通过。

5） 项目初验通过后，进入为期1年的质量保证期。

15.4 项目终验

1）项目终验应在本项目系统测试、初步验收后进行。

2）项目终验的条件。

a.本工程供应商/成交人已完成按合同约定的项目施工安装、测试及试运行工作

b.系统的实际运行的功能和性能以及测试性能指标满足技术规范要求；设备设施的实际运行性能和测试性能指标满足技术规范要求

c.测试出现的问题已被解决至询价方同意，对其它工程项目的影响已消除

d.****政府有关管理部门的规定提供了全部货物和资料

3）本项目供应商/成交人应按照询价方要求向其提供竣工资料。

5）如果本项目供应商/成交人认为工程已达到约定的项目终验条件，应通知询价方，各方应根据合同约定进行项目终验。

16 售后服务要求16.1 质量保证期

本项目定制研发的程序软件，通过项目初验后，供应商/成交人提供须至少提供1年质量保证期，在质量保证期内，由供货方免费硬件和软件系统日常维护及升级迭代服务。

在质量保证期内，由于供应商/成交人程序软件的质量问题而造成停运，供应商/成交人应负责尽快升级、迭代、修复，并赔偿相应损失；同时程序软件的质保期将重新计算。

对于安装、调试、性能试验、试运行及质保期内技术指标一项或多项不能满足要求，双方共同分析原因，分清责任，如属供货方的原因，涉及索赔部分按商务条款执行。

16.2 售后服务

供应商/成交人应提供详细的售后服务方案，包含但不限于以下内容：

1)提供7×24小时**统一服务热线。

2****中心，其主要职责是快速高效的完成技术服务任务。对客户的服务通知，应在接报后1小时内响应，2小时内到达现场，48小时内处理完毕，使系统恢复正常运行。若主要系统的故障在48小时内仍未处理完毕，应采取应急措施解决，不影响客户的正常工作业务。

3)供应商/成交人技术服务人员将严格遵守施工现场的各项安全规定，自觉做好安保措施，未经许可不得拆卸、涂抹、损坏、操作客户任何物品设备。各项安装调试内容，应在客户监督下进行。

4)技术服务工作完成后，技术人员应向客户人员讲述本次服务内容，客户认可服务结果后，方可签署相关资料离开。

16.3 服务措施

供应商/成交人应提供具体售后服务措施，对客户的系统使用情况进行跟进。

16.4 应急响应

供应商/成交人应提供系统故障 处理分级响应和服务机制，对不同的故障分级管控处理。