Как работи GridPeak отвътре
Тази страница описва техническата част на платформата: откъде идват данните, как се оценяват прогнозните модели, какво точно решава оптимизаторът, по какви протоколи стигаме до оборудването и как се разполага системата. Краткото описание е на началната страница.
Два модела се състезават всеки ден
Вместо да твърдим, че един модел е най-добрият, пускаме два и ги оставяме да се докажат. Оценката е ежедневна и по едни и същи данни, а решенията се водят от този, който е печелил.
- Базов модел. Изгражда прогнозата върху историческите ценови закономерности. Служи и за референция — всеки по-сложен модел трябва първо да го надмине.
- Машинен модел (XGBoost). Обучен върху историята на цените плюс метеорологични признаци — температура, облачност и слънчева радиация от Open-Meteo.
- Ежедневно сравнение. Двата модела работят паралелно върху едни и същи данни. Всеки ден се смятат MAE, RMSE и точност на посоката, а по-добрият поема водещата роля.
Оценката се прави върху едни и същи данни и за един и същ хоризонт, за да е сравнима. Точността се измерва всеки ден и се вижда в портала — не се обещава предварително. Когато базовият модел се окаже по-добър за периода, водещата роля се връща при него.
Виждате какво остава след износването — за всяко решение
Всеки цикъл има себестойност: батерията се изхабява и това е реален разход, който никъде не се появява в сметката. GridPeak го смята и го изважда, преди да реши. Спред, който не покрива износването, не се търгува — и вие виждате точно това в отчета: колко е бил спредът, колко е отнела загубата при преобразуване, колко е струвал цикълът и какво остава за вас.
максимизирай Σ ( цена[t]·разряд[t] − цена[t]·заряд[t] ) − цена_на_цикъл · оборот
при условия SoC[t+1] = SoC[t] + η_з·заряд[t]·Δt − разряд[t]/η_р·Δt
SoC[t] ≥ минимален резерв
разряд[t] ≤ макс. износ[t] , само в разрешените прозорци
действие[t] ∈ { STORE , SELL , HOLD }- Ограниченията са ограничения. Минималният резерв на заряда, максималната мощност на износ и разрешените прозорци влизат в модела като условия — оптимизаторът не може да планира решение, което ги нарушава.
- Има праг, под който не се търгува. Загубата при преобразуване и износването образуват праг в евро на MWh. Спред под него не носи пари, колкото и да изглежда изгоден — и оптимизаторът не го приема.
- Гаранцията е ограничение, не пожелание. Производителят дава определен брой цикли на година. Този лимит влиза в модела като условие, така че по-силното въртене днес да не изяде гаранцията след три години.
- Решенията се проверяват. Оптимизаторът работи непрекъснато и трупа история. Всяко решение носи причината си, а точността на прогнозата се оценява всеки ден — измерена, не обещана.
Оптимизаторът преизчислява непрекъснато върху живата телеметрия, а веднъж дневно — преди затварянето на пазара ден напред — същата задача се решава за цялото следващо денонощие и дава графика за деня. Двете използват една и съща прогноза и едни и същи ограничения, затова планът и текущото решение не си противоречат.
От данните до графика, стъпка по стъпка
Веригата е една и съща всеки ден: прогноза, оптимизация, график, одобрение, изпълнение, отчет. Всяка стъпка надгражда предишната и се вижда в портала — включително защо оптимизаторът е решил точно така.
Прогноза
Цени за пазара ден напред от ENTSO-E за българската зона и метеоданни от Open-Meteo. Базовият модел и XGBoost работят паралелно, а точността им се оценява всеки ден.
Оптимизация
MILP оптимизатор, който работи непрекъснато: заряд, прогнозни цени, цена на цикъла, ограничения за износ и минимален резерв. Изход: STORE, SELL или HOLD със задание в kW.
План за деня
Веднъж дневно, преди затварянето на пазара ден напред в 12:00 ч. по централноевропейско време, се изготвя график на интервалите за следващото денонощие — един план на ден.
Одобрение
Планът се показва в портала и се изпраща през Telegram бота. Одобрявате или отхвърляте в прозореца за корекция — ръчно, по правило или наведнъж за следващия ден.
Изпълнение и отчет
Одобреното се превръща в команди към батерията (диспечиране). След деня се съпоставят планираното и изпълненото и се отчита резултатът по площадка — с цената на цикъла вътре в сметката.
Всяка стъпка оставя запис: коя прогноза е използвана, какви са били ограниченията, защо оптимизаторът е избрал точно това действие и какво се е случило после. Затова всеки ден назад може да бъде проверен, а прогнозираният и реалният резултат се сравняват по интервали.
Един конекторен слой, независим от производителя
GridPeak е независим от марката на оборудването. Свързването е на ниво протокол, а не марка по марка: архитектурата поддържа оборудване, което предоставя поддържан индустриален или производителски програмен интерфейс. Затова добавянето на нов производител е работа по настройка на конектора, а не нов проект — и затова размерът на централата няма значение.
в реална работа
Victron през Cerbo GX по MQTT. Конекторът, по който днес влиза живата телеметрия от действаща производствена площадка, и по който излизат командите обратно.
по стандартен протокол
Modbus TCP/RTU, SunSpec, контролер на централата, SCADA. Оборудване, което изнася тези интерфейси, се свързва с настройка на конектора — картографиране на регистрите и проверка при въвеждането на площадката.
отделна интеграция
Затворени или облачни интерфейси. Когато производителят не отваря локален порт или държи достъпа зад партньорско споразумение, интеграцията се прави за конкретния случай и се оценява предварително.
Изброените по-долу марки говорят съответните протоколи. Това не означава, че всяка от тях вече е проверена в реална експлоатация при клиент — при офериране казваме за конкретния ви модел кое от трите важи.
Modbus TCP/RTU и SunSpec
Индустриалният стандарт за инвертори, системи за съхранение и измервателни уреди. Архитектурата поддържа устройства, които предоставят достъпни регистри по Modbus TCP или RTU; профилът SunSpec дава един и същ регистров модел за много производители наведнъж. Конекторът чете телеметрията и подава задания за мощност директно на площадката, без облачен посредник.
MQTT · Victron Cerbo GX работи
Връзка през Cerbo GX по MQTT — жива телеметрия от площадката и команди обратно към системата. По този път влизат данните от действаща производствена инсталация.
Контролер на централата и SCADA
Възможна е връзка с контролера на централата (PPC) или SCADA. Обхватът зависи от интерфейса, правата за управление, защитите и изпитванията на конкретния обект.
Облачни интерфейси на производителя
Когато производителят държи данните в свой облак, конекторът работи през неговия програмен интерфейс и привежда данните към общия модел. Този път се използва там, където оборудването не отваря локален порт. Обхватът на данните и правата за управление се проверяват за всеки интерфейс поотделно при въвеждането на площадката.
Регистровите карти, фърмуерът, защитите и правата за запис се проверяват при определяне на обхвата. Възможна е допълнителна разработка за конкретното оборудване.
Три начина да се разположи платформата
Разликата не е във функциите, а в това къде стоят данните и кой стопанисва инфраструктурата. Всяка площадка има собствена конфигурация на батерията, собствена ценова зона, собствен оптимизатор и собствен поток от телеметрия — независимо от начина на инсталация.
Споделена инстанция
Няколко по-малки клиенти върху общ API, общ MQTT брокер и обща времева база. Разделянето е логическо — етикет на клиента, отделни префикси на MQTT темите и ограничение на достъпа на ниво запис в базата. Най-икономичният вариант за съветващото ниво.
Отделна инстанция
Целият стек на един клиент в собствена група контейнери. Истинско разделяне на данните — стекът е преносим и може да се изнесе при вас, ако по-късно решите да го местите. За по-големи клиенти и за случаи с регулаторни изисквания.
Собствен хостинг с връзка обратно към нас
Отделна инстанция, която върви върху вашата инфраструктура. Ако пазарният график продължава да се подготвя от GridPeak, тя изпраща решенията за зареждане и разреждане към нас по защитен интерфейс. Данните остават при вас.
И в трите варианта достъпът е по HTTPS, с роли и разделяне на данните по клиент, а телеметрията от площадката минава през защитен тунел. Правата за запис към оборудването не са включени по подразбиране — те се активират отделно и по договор.
Какво изисква технически всяко от трите нива
Нивата не са различни продукти — инстанцията е една и съща. Нивото определя какви права има конекторът, кой потвърждава плана и колко от изпълнението поема платформата. Началната страница дава трите нива накратко; тук са пълните описания и техническите условия.
Системата прогнозира, оптимизира и показва на таблото препоръка — SELL, STORE или HOLD със задание и очакван резултат. Решението остава изцяло ваше, а телеметрията може да е само за четене.
Системата предлага, вие одобрявате. Графикът се изготвя веднъж дневно, показва се в портала и в Telegram бота и чака вашето решение — ръчно, по правило или наведнъж за следващия ден. Изпълнението минава през конектор с право на запис и се активира по договор.
От решението на оптимизатора до командата към батерията — без човек по веригата, в договорени оперативни граници. Аварийното спиране е винаги налично. Нивото се отваря по отделен договор и след доказана история на решенията.
Как се минава от едно ниво на друго
Надграждането не е миграция на данни — същата инстанция, нови включени възможности.
- Договор. Допълнение, което покрива автоматичното изпълнение и отговорността.
- Конектор. Ако е нужно, връзката се надгражда от четене към четене и запис.
- Настройка. Включва се автоматичното изпълнение и се избира режимът на одобрение.
- Пробен период. Системата генерира поръчки, но не ги изпълнява — вие проверявате решенията ѝ.
- Пускане. Превключване от пробен режим към реално изпълнение.
Какво изисква всяко ниво
Нивото се вписва в договора. Никое ниво не се включва мълчаливо — преминаването към автоматично изпълнение изисква изрично съгласие.
Какво работи
Не прототип и не презентация. Данните влизат на живо, прогнозата и оптимизаторът работят непрекъснато, планът отива за одобрение, а изпълнението стига до батерията.