Skip to main content

One post tagged with "设计"

View All Tags

浅谈HCP平台及其设计理念

· 7 min read

控制保护装置是电力设备的二次核心。无论是电力电子、继电保护还是自动化领域,都需要一个统一的控制器平台来支撑业务开发。近年来,随着控制平台技术的不断进步,许多长期困扰研发人员的问题已得到改善,但仍有一些根本性痛点尚未被彻底解决。

  1. 软硬件的强耦合 微机控制器的发展始终紧跟芯片技术的迭代速度,硬件快速更新,每次更换都要求软件重新适配,导致适配和验证成本居高不下。为此,“软件平台”的概念应运而生:将应用程序与硬件解耦,应用只能通过平台提供的标准接口操作硬件。这样,硬件升级时只需适配平台层,应用程序即可无缝迁移,大幅降低适配代价。

  2. 软件的验证成本高 电力设备对可靠性要求极高,而软件又天然需要不断迭代。任何一次验证中发现问题,往往需要从头再来,验证成本甚至远超开发成本。虽然业界已尝试对控制保护装置进行自动化验证,但装置对外接口的不统一,仍使自动化验证的推广存在较大局限。

  3. 开发语言的表达能力与业务不匹配 嵌入式裸机开发受限于硬件资源,多采用C语言。理论上C语言可以完成任何逻辑,但其面向过程的编程范式在面对特定业务逻辑时抽象能力不足。工业控制领域较早发现了这一问题,由此诞生了PLC,支持梯形图、功能块图、顺序功能图等多种编程语言,各自适应不同场景,弥补了纯C语言抽象能力不足的缺点。然而,这种领域特定语言在泛化能力上又有其局限性。

  4. 软件的可维护性差 在软件平台出现之前,控制保护装置多基于裸机开发,组件高度耦合,应用与底层往往需要联合编译,维护成本极高。更关键的是,随着功能持续扩展,代码量很快就会超出单人维护的极限,多人协作同一套代码的难度很大,这严重制约了程序规模的提升。

这些痛点中,既有电力控制领域的特有问题,也有软件工程领域的普遍挑战。领先的电力系统控制平台已经开始吸收操作系统技术实现硬软解耦与模块隔离,并借鉴工业控制领域的PLC可视化编程思想。站在2026年这个时间点,如果从零开始设计一套全新的控制保护平台,如何在前人工作的基础上,进一步汲取更先进的技术与开发范式,从更深层次解决上述问题?HCP异构控制平台(Heterogeneous Control Platform)正是在这一背景下,提出了三大设计理念:AI化、融合化、虚拟化。

AI化:面向大模型的开发范式重构

大模型的快速发展正在重塑编程工具,从2022年底ChatGPT掀起的对话式交互,到代码补全,再到如今的Agent自主开发,AI正逐步打通从编码、编译、测试到部署的全闭环。一旦AI能够自主闭环完成开发任务,它带来的效率提升将是颠覆性的。

然而,大模型在当前阶段仍存在两个显著局限:其一,对图形的理解能力远逊于语言能力,即便许多模型宣称支持多模态,理解图形化编程逻辑仍十分困难,这使得对人类友好的图形编程反而成为AI的短板;其二,上下文窗口有限,难以直接胜任复杂的大规模任务,需要人类辅助进行任务分解和功能定义。

针对这两个问题,HCP平台采用了“功能块开发→功能块集成”的两段式开发理念。单个功能块要求以纯C语言实现,一方面能充分利用大模型强大的语言编程能力,另一方面也通过限制功能块的规模,解决了上下文不足的问题。为支撑这一理念,平台不仅提供了图形化开发工具HCP BlockEditor,还配套了HCP BlockEditor CLI。借助配套的Skill,开发者可直接在Claude Code、Codex等主流Agent编程工具中,以自然语言驱动功能块的自主开发、编译与验证。

融合化:多尺度实时任务的统一承载

任何计算机系统设计都面临吞吐量与实时性之间的矛盾。大多数通用系统追求高吞吐量,虚拟内存、分支预测、乱序执行、多发射等技术皆为此服务。而控制保护装置往往更关注实时性,但同时也承载着大量非实时业务。

若以时间尺度来界定不同业务的实时性需求,电力电子控制通常在微秒级,继电保护与一般工业控制要求毫秒级,人机交互、后台通信等则只需几十至几百毫秒甚至秒级响应。如何在同一平台上同时满足从微秒到秒级的差异化实时需求,是HCP平台必须回答的核心问题。

HCP平台采用功能异构的系统架构来融合这些任务。以RK3568四核ARM Cortex-A55处理器为例,虽然其四颗核心在硬件上同构,但平台通过非对称多处理(AMP)模式实现了功能层面的异构:核心0运行Linux RT操作系统,承载软实时与非实时任务,如人机交互、后台通信,并提供软PLC控制运行时;核心1-3直接运行裸机程序,统一承载硬实时任务,涵盖微秒级高实时控制以及毫秒级保护逻辑等。这种架构既通过核心0的复用提升了CPU资源利用率,又利用核心1-3保证了最苛刻的硬实时性需求。

虚拟化:从硬件在环到软件在环的闭环验证

虚拟化技术在嵌入式领域早有应用,最著名的当属QEMU。它利用TCG(Tiny Code Generator)技术实现跨架构的动态二进制翻译,使得在x86平台上能够直接运行ARM、PowerPC、RISC-V等架构的二进制程序。这项技术最初是为了让软件开发不依赖实体硬件,与硬件并行推进,从而缩短项目周期。而在当下,虚拟化又被赋予了新的意义:AI天然更易于操作计算机系统而非物理世界,通过虚拟化技术,可以方便地利用AI对控制器软件进行自动化闭环验证。

实际上,控制保护领域广泛使用的硬件在环仿真(HIL)在本质上也是一种虚拟化——它虚拟化了一次设备。将真实控制器接入HIL仿真平台,就能在不接入实际一次设备的情况下验证控制器软件的功能。但主流HIL平台如RTDS、RTLAB等售价高昂,难以大规模配备给每一位开发人员。

为此,HCP平台进一步提出了软件在环闭环验证方案。该方案基于MATLAB、PSCAD等离线仿真环境,并集成了虚拟化指令集模拟技术,使得编译生成的目标机二进制程序能够直接在仿真模型中闭环运行。这就相当于以极低的成本为每一位开发者提供了一个“虚拟硬件在环”环境,可随时对控制保护软件的二进制程序进行全面验证。这一做法大大降低了验证的门槛和成本,显著提升了研发效率。

从AI化的开发范式重构,到融合化的多实时任务统一承载,再到虚拟化的低成本闭环验证,HCP异构控制平台的三大设计理念环环相扣,直指当前控制保护装置开发中最为核心的痛点。它们共同勾勒出了下一代控制平台的发展方向,也为电力系统控制软件的高效、可靠开发提供了更为坚实的技术底座。