Максим Мигранов > Комментарии

Для построения программного комплекса, включая применение методов и алгоритмов прогнозирования энергопотребления исследуемых объектов, была разработана платформа на основе паттерна MVC.

Шаблон проектирования MVC предполагает разделение данных…

Размернуть цепочку комменатриев

Для построения программного комплекса, включая применение методов и алгоритмов прогнозирования энергопотребления исследуемых объектов, была разработана платформа на основе паттерна MVC.

Шаблон проектирования MVC предполагает разделение данных приложения, пользовательского интерфейса и управляющей логики на три отдельных компонента: Модель, Представление и Контроллер – таким образом, что модификация каждого компонента может осуществляться независимо.

Основные преимущества MVC архитектуры:

­ единая концепция системы. Несомненным плюсом MVC является единая глобальная архитектура приложения. Даже в сложных системах, разработчики (как те, которые разрабатывали систему, так и вновь присоединившиеся) могут легко ориентироваться в программных блоках. Например, если возникла ошибка в логике обработки данных, разработчик сразу отбрасывает 2-блока программы (controller и view) и занимается исследованием 3-го (model).

­ упрощен механизм отладки приложения. Т. к. весь механизм визуализации теперь сконцентрирован в одном программном блоке, упростились механизмы опционального вывода графических элементов.

В свою очередь, к основным недостаткам данного подхода можно отнести:

­ необходимость использования большего количества ресурсов. Сложность обусловлена тем, что все три фундаментальных блока являются абсолютно независимыми и взаимодействуют между собой исключительно путем передачи данных. Controller должен всегда загрузить (и при необходимости создать) все возможные комбинации переменных и передать их в Model. Model, в свою очередь, должен загрузить все данные для визуализации и передать их во View. Например, в модульном подходе, модуль может напрямую обрабатывать переменные окружения и визуализировать данные без загрузки их в отдельные секции памяти;

­ усложнен механизм разделения программы на модули. В концепции MVC наличие трех блоков (Model, View, Controller) прописано жестко. Соответственно каждый функциональный модуль должен состоять из трех блоков, что в свою очередь, несколько усложняет архитектуру функциональных модулей программы;

­ усложнен процесс расширения функционала. Проблема очень схожа с вышеописанной. Недостаточно просто написать функциональный модуль и подключить его в одном месте программы. Каждый функциональный модуль должен состоять из трех частей, и каждая из этих частей должна быть подключена в соответствующем блоке.

Предлагаемая архитектура построения приложения представлена на рисунке

Свернуть цепочку комменатриев

Для обеспечения бесперебойного наблюдения за потреблением подстанции и работы реализации исследуемых моделей и алгоритмов прогнозирования на основе данных, получаемых из разных источников, была разработан программный комплекс прогнозирования…

Размернуть цепочку комменатриев

Для обеспечения бесперебойного наблюдения за потреблением подстанции и работы реализации исследуемых моделей и алгоритмов прогнозирования на основе данных, получаемых из разных источников, была разработан программный комплекс прогнозирования потребления электроэнергии.

Основные требования, предъявляемые к программному комплексу:

прогнозирование энергопотребления собственных нужд объектов электросетевого хозяйства предприятия;

определение аномалий в структуре энергопотребления

клиентское приложение с возможностью графического представления архивных данных энергопотребления

В предложенном варианте функционирование программного комплекса достигается за счет взаимодействия компонентов структуры, представленной на рисунке


Свернуть цепочку комменатриев

1) Пока что это экспериментальный проект в рамках ПАО "ФСК ЕЭС", и его дальнейшее развитие зависит от того насколько он будет интересен и сможет быть интегрирован в существующую программную экосистему компании. Касаемо аналогов - аналоги есть, но…

Размернуть цепочку комменатриев

1) Пока что это экспериментальный проект в рамках ПАО "ФСК ЕЭС", и его дальнейшее развитие зависит от того насколько он будет интересен и сможет быть интегрирован в существующую программную экосистему компании. Касаемо аналогов - аналоги есть, но оценить результаты их работы практически невозможно, поэтому сложно что-либо о них говорить. Если бы было возможно устроить "challenge" на эталонном датасете, то мы приняли бы в нём участие. Что касается, например, энергосбытовых компаний, то во многих до сих пор прогноз делается путём экспертной оценки т.е. сидят отделы и вручную делают прогнозы. Так что объём потенциального рынка достаточно велики. Касаемо прогнозирования потребления собственных нужд, в рамках ПАО "ФСК ЕЭС" это сверхактуальная задача в рамках борьбы за снижение потребления электроэнергии. Ну а эксперимент с энергорайонами был лишь способом апробации работоспособности модели, и это может заинтересовать ОАО "СО ЕЭС", но у них есть свои способы прогнозирования, а также доступ к предполагаемым объёмам потребления на ОРЭМ.

2) С введением в энергетике ПК "АСУРЭО" и ПК "Заявки" ситуация значительно улучшилась, т.к. практически все работы, как плановые, так и внеплановые, проходят через регламент подачи заявок. Да, есть часть информации, которая теряется, но решить этот вопрос можно внедрением электронного журнала нарядов и распоряжений, который мог бы идти отдельной подсистемой того же АСУРЭО, и я, честно говоря, искренне не понимаю, почему это до сих пор не было реализовано, учитывая что с точки зрения программной разработки, это не является какой-то сверхсложной задачей.

Свернуть цепочку комменатриев

Добрый день, Дмитрий! Прошу прощения за столь долгое ожидание! Да, в своей работе мы пробовали использовать данные метеопрогноза, а также календарные признаки, указанные в статьи. В ходе исследований мы прогнозировали потребление как физ.лиц и…

Размернуть цепочку комменатриев

Добрый день, Дмитрий! Прошу прощения за столь долгое ожидание! Да, в своей работе мы пробовали использовать данные метеопрогноза, а также календарные признаки, указанные в статьи. В ходе исследований мы прогнозировали потребление как физ.лиц и муниципальных образований, так и подстанций. В случае с потреблением энергорайонов, метеорологические данные действительно улучшают качество прогноза. Так, погрешность месячного прогноза потребления Сосновского района Челябинской области составляла не более 5% на разных моделях. Но при работе с потреблением собственных нужды, мы пришли к выводу, что метеорологические данные:

1) Вносят сумятицу в работу модели
2) Имеют проблемы с точностью архива метеоданных, так как точка измерения может быть зачастую в 10-15км от подстанции, и там могут быть иные условия окружающей среды, а для модели разница в 1-2 градусы или м/с может быть чувствительна
3) Имеют проблемы с точностью прогноза, что также негативно влияет на точность.

Зачастую в статьях точность прогноза с использованием метеоданных считают на тех же архивных данных, что уже само по себе нарушает чистоту эксперимента. Так что в части метеоданных вполне достаточно сезонности, которая очень ярко выражена в структуре потребления.

Также стоит отметить, что очень сильно на потребление собственных нужд влияет ремонтная программа подстанция. Мы планируем провести эксперимент, разметив датасет размерностью 5 лет данными по выводу оборудования подстанции на планируемые ремонты. Также на основе этой модели мы попробуем создать классификатор разворота тренда, т.к. именно в точках разворота очень большая погрешность прогноза, а на суточном тренде направление может меняться каждые сутки.

На данный момент диссертация по исследованиям закончена, после получения разрешения ПАО "ФСК ЕЭС" на публикацию и защиты, диссертация и материалы с конкретными цифрами потребления будут выложены здесь, пока, увы, связан обязательствами.

Свернуть цепочку комменатриев