处于户用光储场景里, 光伏的出力情况, 储能的状态情形, 家庭负荷的状况以及环境条件这个方面, 会于不一样的时间阶段持续不断地变换。针对于用户来讲, 难点并非仅仅是设备数量出现了增加, 而是更加在于信息分布在不同的界面之中, 分布在不同的终端之内, 甚至分布在不同的数据口径范围里: 光伏发出了多少电量, 储能还能够支撑多长的时间, 负荷处于什么样的状态, 软件给出的建议是基于哪些条件, 通常是很难被清晰地理解消化的。
就这一问题而言, 于指导教师李建军以及程尧的指导之下, 新疆政法学院学生团队中项目负责人燕梓桐引领团队去开发“胡杨新能——面向南疆的自适应户用光储智慧管理系统”这一软件原型。并且尝试在那些成熟的光伏、储能以及功率设备之上, 着手构建信息展示、策略建议、安全边界以及多端交互能力。该项目当下并不生产光伏组件、储能电池以及逆变器, 同时也并非以替代底层设备保护作为目标。其重点在于把光伏、储能、负荷以及环境等信息组织成为可以查看, 还可以解释, 且能够继续验证的软件链路。
从分散状态到统一的数据服务
户用光储系统运行和多个对象有关联, 光伏侧留意辐照、温度、输出功率以及工作点；储能侧关注荷电状态、温度、电压、健康状态与告警信息；负荷侧要依据不同时段的用电需求来理解。要是这些信息各自留在独立设备或者孤立页面里, 用户跟运维人员很难形成整体判断。
胡杨新能此刻的探寻, 起始于统一数据服务, 团队已然分别达成了Windows桌面端开发, 完成了APP端开发, 还实现了微信小程序端开发。这三个程序运用的是独立的界面以及交互实现方式, 可全都借助同一套后端数据API接入统一数据服务, 进而构成了基于统一API的三端软件协同原型。
这种协同所最先解决的是软件方面的数据以及服务的一致性, 并非是将三个客户端直接简单地复制成为相同的页面。Windows桌面端适宜去承载运行总览、数据源查看以及策略工作台。APP端是面向移动场景当中的状态、环境信息以及策略边界查看。微信小程序端能够提供更为轻量的入口, 使得光伏、储能、负荷与环境信息能够凭借较低的门槛被访问。三个入口分别面向不同的任务, 不过却是围绕同一套数据服务来组织内容。
这种分工还表示呢, 同一条状态信息没必要在三个终端用同样方式重复展现。桌面端能够留存更完备的字段、来源以及工作台信息, 方便对不同数据对象做横向查看；移动端更注重当前状态、环境变化还有提示信息；小程序端是降低访问门槛, 适宜快速查看。统一后端数据API在这儿担当的是字段组织与服务一致性的角色: 不同终端按照自身的界面逻辑去调用同一类状态信息, 而不是各自维护相互不一致的数据口径。
将光伏侧寻优与储能侧约束放回各自位置
对于软件原型, 光伏侧同储能侧的技术问题不一样。局部遮挡、辐照变化这类条件下, 光伏阵列的功率—电压曲线也许会出现多个局部峰值。团队针对这一问题, 于软件仿真里展开了20次分层候选加10次局部精化的有限预算MPPT探索: 电压允许范围被划分成多个区间, 候选位置在区间内生成, 之后围绕当前较优区域进行局部细化, 最终输出仿真参考电压候选。
服务于光伏侧工作点探索的是这一过程, 为观察候选覆盖及局部精化过程, 利用相近计算约束下20次与10次合计构成的30次P(V)软件评价预算, 它既不代表实体逆变器已完成在线扫描, 其中, 软件也不代表已直接控制真实光伏设备。
就软件仿真的工况而言, 在均匀辐照的条件之下, P–V特性一般会呈现出单一的主峰 , 一旦不同组件遭受不一致辐照或者局部遮挡的影响，曲线便有可能出现多个局部峰值, 峰值的位置以及功率水平同样会随着工况而发生变化。在这个时候, 仅仅在某一个邻域之内对工作点加以调整, 或许会比较早地停留在局部较为优渥的位置。分层候选覆盖是用来将处于允许电压范围之内的多个区域纳入到比较当中的, 而局部精化环绕着当前比较优的候选持续缩小搜索的范围。图里的多工况曲线是用来对这一机制加以说明的, 它和现场采样曲线并不对应, 并且也不应该被理解作是不同遮挡条件之下的实测发电量。
储能侧面临着另外一组约束, SOC、温度、电压、SOH、告警状态、设备能力以及权限等信息, 会对某一充放电目标能否被系统接受产生影响。当前胡杨新能在软件逻辑里, 把这类状态当作上层策略需要识别的安全约束, 软件能够形成候选建议, 然而候选建议进到更上层功率协调之后, 依旧要接受设备能力与底层BMS保护边界的检查。
这里得保证层级清晰, 明明白白。处于上层的软件, 能够呈现状态, 对组织进行约束, 进而形成策略建议, 还要收缩权限。处在底层的BMS能承担电池本体的保护功能。不光, 逆变器以及其他设备也都有自己的能发挥的能力, 还有相应的保护机制。这项目目前还没有采购以及接入BMS硬件, 所以不会把软件原型里的约束建模视为已经达成真实的BMS控制。
于日内仿真机制内, 光伏出力、家庭负荷以及储能功率并非始终同步改变。在光伏出力比较充足且负荷较低之际, 软件能够形成充电方向的候选建议；当负荷高于光伏出力之时, 软件能够形成由储能参与支撑的候选建议。此类曲线的用处乃是协助观察不同变量于同一时间轴上的关系, 并非宣告某项建议已然写入真实设备。候选建议是否能够进一步进入功率协调, 依旧取决于SOC、温度、电压、告警、设备能力、通信状态以及底层保护边界。
信息不完整时，软件应当更克制
对于智慧能源管理软件来讲, 连接的存在并不表明数据一直是可靠的, 网络出现波动, 数据到了过期的时候, 状态存在不完整的情况, 设备应答发生缺失, 这些都有可能致使一项策略建议是否还有可执行的条件, 被改变。
因此, 胡杨新能把“权限收缩”当作软件原型里的设计方向。在数据来源明晰、状态充裕且条件良好时, 软件能够展现更完备的状态和策略建议, 当通信出问题、数据时效下降或者关键应答缺少时, 系统要转到更保守的展示、提示或处理方法上, 防止依据不完整的信息持续扩大高风险操作权限。
以这种处理方式为目的, 是要让软件针对不确定性维持诚实状态。它不会去替代逆变器以及BMS的底层保护, 也不会将算法建议包装成无条件执行的设备指令。对于仍处在原型阶段的智慧能源管理系统来讲, 并能够清晰地表述“此刻了解什么、还差什么、哪些操作需要停止”, 跟增添功能数量是同等重要的。
所以, 数据的来源, 还有更新的时间, 以及设备的应答, 并非只是用于页面的展示。数据来源可以协助区分当下信息源自哪种软件链路或者记录方式；时效方面的信息能够表明状态是不是依然拥有参考的条件；设备能力跟写权限信息则能够表现某一建议是不是具备继续朝着下传递的基础。要是关键应答缺少、数据逾时或者实体链路没有建立, 软件留存状态以及异常提示, 与此同时收缩写控制相关的权限。已有的软件页面之中的数据溯源, 还有控制锁定, 以及设备能力展示, 所反映的, 是这种原型层面的边界表达, 然而这并不代表已经完成了真实设备的写入, 并且也不意味着已经完成了真实设备的执行。
三端软件为后续验证保留接口位置
当下, 胡杨新能已然完成了三个软件客户端的开发, 还完成了统一后端数据API的开发, 软件页面能够用于验证数据组织, 技术曲线能够用于验证界面交互, 策略输出能够用于验证原型逻辑。然而, 真实设备数据采集的完整闭环尚未建立, 指令写入的完整闭环尚未建立, 设备应答的完整闭环尚未建立, 执行结果回传的完整闭环也尚未建立。
接着, 团队会持续针对于数据来源标记、接口字段映照、状态时效性、权限判定、异常处置以及设备回应等诸多问题去展开验证。当拥有实验条件之后, 光伏侧工作点探寻、储能侧安全限制以及多端软件交互都需要各自形成能够进行复核的记录, 随后再逐步去考查它们在同一情景里的协同关联。
户用光储的智慧管理不是仅靠某一个算法, 也不是仅靠某一个界面就能够完成的。它要考虑把光伏侧的波动处理, 还要注重储能侧的边界界定, 同时要兼顾用户侧的信息理解, 并且不能忽视设备侧的安全保护, 统统放在同一条软件链路里去处理。胡杨新能目前是以软件仿真以及原型验证的方式, 探究这条链路怎能组建得更明晰, 能更把握制约的尺度, 且更有利于后续持续开展验证工作。
