Предложения по развитию функционала Simple SCADA
Здравствуйте.
Хотелось бы поднять вопрос не об отдельных небольших улучшениях, а о фундаментальном функционале Simple SCADA, которого сейчас не хватает для построения более крупных, гибких и сопровождаемых проектов. При работе с системой возникает ощущение, что многие возможности ориентированы прежде всего на создание конкретного проекта в рамках уже существующего функционала, тогда как для серьёзной долгосрочной разработки хотелось бы видеть больше возможностей для повторного использования компонентов, расширения системы, автоматизации разработки и работы с данными. Ниже перечислю основные функции, которых, на мой взгляд, сейчас не хватает.
1. Единая библиотека для всех проектов
Сейчас отсутствует полноценная возможность иметь одну общую библиотеку компонентов/шаблонов, доступную сразу для всех проектов Simple SCADA. Например, если разработчик создал собственный набор:
- шаблонов;
- групп;
- графических элементов;
- элементов управления;
- стандартных компонентов интерфейса;
- собственных визуальных решений,
, то хотелось бы иметь возможность сохранить их в общей библиотеке и использовать в любом проекте. Зачем это необходимо: при наличии нескольких проектов приходится фактически поддерживать одинаковые элементы отдельно в каждом проекте. Общая библиотека позволила бы:
- повторно использовать готовые компоненты;
- централизованно обновлять их;
- поддерживать единый стандарт оформления;
- значительно ускорить разработку новых проектов;
- уменьшить количество дублирования.
Особенно актуально это становится для интеграторов и разработчиков, которые работают одновременно с несколькими SCADA-проектами.
2. Полноценный отладчик
Одним из наиболее заметных ограничений является отсутствие полноценного debugger/отладчика. При разработке сложной логики приходится фактически отлаживать систему «вживую», что значительно усложняет поиск ошибок.
Было бы полезно иметь хотя бы базовые возможности:
- точки останова;
- пошаговое выполнение;
- просмотр значения переменных;
- просмотр состояния объектов;
- просмотр стека вызовов;
- выполнение кода по шагам;
- логирование;
- возможность остановить выполнение в определённой точке;
- просмотр причины возникновения ошибки.
Для разработчика это существенно упростило бы создание и поддержку сложных проектов.
3. Динамическое изменение изображения/анимации во время работы
Сейчас хотелось бы иметь возможность не просто проигрывать кадры одной анимации, а динамически выбирать различные изображения или анимации в зависимости от значения переменной.
Например: есть два состояния оборудования:
- насос работает;
- насос остановлен.
Для каждого состояния используется отдельная анимация. В зависимости от значения переменной SCADA должна иметь возможность переключаться между этими анимациями:
Variable = 0 → Animation A
Variable = 1 → Animation B
При этом хотелось бы иметь возможность использовать не только два состояния, но и несколько вариантов. Это позволило бы создавать гораздо более информативную визуализацию оборудования без необходимости создавать большое количество отдельных объектов.
4. Изменение размера и угла шаблонов и групп
Хотелось бы иметь возможность изменять:
- ширину;
- высоту;
- масштаб;
- угол поворота;
- положение
для шаблонов и групп. Особенно полезно это было бы для универсальных компонентов. Например, один шаблон можно было бы использовать для оборудования разных размеров или ориентации, не создавая отдельную версию каждого элемента. Также это значительно расширило бы возможности создания динамических интерфейсов.
5. Кастомное наследование от базовых классов TM
Хотелось бы получить возможность создавать собственные классы/шаблоны на основе существующих базовых классов TM. Например: "BaseObject → Pump → CustomPump → ProjectPump", где каждый последующий уровень наследует функциональность предыдущего и может её расширять. Это позволило бы создавать собственную архитектуру компонентов внутри проекта. Например, разработчик мог бы создать базовый шаблон насоса, определить в нём:
- стандартный внешний вид;
- основные свойства;
- обработку состояний;
- анимации;
- стандартные элементы управления;
, а затем на его основе создавать специализированные варианты. Это особенно полезно при разработке крупных проектов, где один и тот же тип оборудования используется десятки или сотни раз.
6. Экспорт текущих данных в пользовательском формате
Хотелось бы иметь возможность экспортировать все необходимые текущие данные из SCADA в пользовательском/кастомном формате для дальнейшей обработки сторонними инструментами. Речь не только об обычном экспорте исторических данных.
Интересна возможность получать структурированные данные, например:
- значения переменных;
- состояния оборудования;
- аварии;
- события;
- временные метки;
- параметры объектов;
- пользовательские данные;
- другие доступные данные SCADA.
И экспортировать их, например, в JSON / CSV / XML / другой пользовательский формат / API.
Отдельно хотелось бы отметить перспективу работы с ИИ. Такие данные можно было бы использовать для:
- анализа работы оборудования;
- поиска аномалий;
- прогнозирования неисправностей;
- формирования отчётов;
- анализа производительности;
- работы внешних AI/ML-систем.
Например, SCADA могла бы предоставлять структурированный набор данных внешнему аналитическому модулю, который уже выполнял бы их обработку. Поэтому наличие удобного API или механизма кастомного экспорта данных кажется особенно перспективным направлением развития.
7. Минимальные возможности кастомизации объектов
Сейчас разработчик достаточно сильно ограничен существующим набором возможностей объектов. Хотелось бы иметь значительно больше возможностей для адаптации стандартных объектов под конкретные задачи.
Например:
- добавление собственных свойств;
- создание собственных событий;
- изменение поведения объекта;
- добавление пользовательской логики;
- создание собственных состояний;
- изменение визуального представления;
- добавление дополнительных параметров;
- расширение стандартных объектов.
Иными словами, хотелось бы иметь возможность не только использовать готовые объекты Simple SCADA, но и создавать на их основе собственные специализированные компоненты.
8. Массовая вставка шаблонов
Отсутствует удобная возможность массовой вставки шаблонов. При работе с большим проектом может потребоваться разместить десятки или сотни одинаковых либо однотипных элементов. Вручную добавлять каждый шаблон становится крайне неудобно и значительно увеличивает время разработки.
Хотелось бы иметь возможность:
- выбрать несколько шаблонов и добавить их одновременно;
- массово вставлять шаблоны на страницу;
- создавать несколько экземпляров одного шаблона;
- задавать параметры при массовой вставке;
- по возможности автоматически связывать экземпляры с соответствующими переменными.
В перспективе было бы особенно полезно иметь возможность создавать элементы из таблицы или списка.
Например:
№ Тип Имя Переменная
- ----- ------- ----------
1 Насос Насос 1 Pump_01
2 Насос Насос 2 Pump_02
3 Насос Насос 3 Pump_03
И на основании этих данных автоматически создавать необходимые экземпляры шаблонов. Это могло бы существенно ускорить создание больших SCADA-проектов.
9. Возможность самостоятельно разрабатывать и расширять функционал
Один из наиболее важных вопросов - возможность расширения Simple SCADA самим разработчиком. Сейчас при отсутствии определённой функции пользователь в значительной степени зависит от того, будет ли эта функция когда-либо реализована разработчиками Simple SCADA. Хотелось бы иметь официальный механизм расширения системы.
Например:
- SDK;
- API;
- систему плагинов;
- пользовательские модули;
- пользовательские компоненты;
- возможность создавать собственные элементы интерфейса;
- возможность расширять существующие объекты;
- возможность добавлять собственные свойства и методы;
- возможность взаимодействовать с API Simple SCADA из внешних приложений.
В идеале хотелось бы иметь архитектуру, при которой разработчик может самостоятельно решить определённую задачу, даже если соответствующего функционала пока нет в ядре Simple SCADA. Это особенно важно для нестандартных промышленных задач, поскольку невозможно заранее реализовать абсолютно все возможные сценарии использования SCADA.
10. Более гибкая работа со шрифтами
В текущем функционале также хотелось бы видеть более широкие возможности настройки текста. В частности, отсутствует возможность:
- выбирать различные шрифты;
- задавать толщину шрифта;
- использовать различные начертания;
- более гибко настраивать текстовые элементы.
Например, хотелось бы иметь возможность использовать:
- Light;
- Regular;
- Medium;
- SemiBold;
- Bold;
- другие доступные начертания.
Также желательно иметь возможность выбирать сам шрифт для конкретного объекта или группы объектов. Это кажется небольшой функцией, однако для современных SCADA-интерфейсов типографика достаточно сильно влияет на читаемость и визуальное восприятие интерфейса. Особенно это актуально при создании больших мнемосхем, операторских панелей и современных HMI-интерфейсов.
Общая проблема
Если рассматривать все перечисленные функции вместе, то они относятся не столько к отдельным возможностям интерфейса, сколько к вопросу расширяемости и масштабируемости Simple SCADA.Сейчас разработчик в значительной степени работает внутри возможностей, которые заранее предусмотрены разработчиками системы. При появлении нестандартной задачи часто приходится искать обходные решения вместо того, чтобы расширить существующий функционал самостоятельно.
На мой взгляд, особенно перспективными направлениями развития могли бы стать:
Общая библиотека → Шаблоны → Наследование → Кастомные объекты → API/SDK → Плагины → Отладчик → Расширенная работа с данными. Это позволило бы превратить Simple SCADA не просто в набор готовых инструментов, а в более открытую платформу, которую разработчики могли бы адаптировать под конкретные промышленные задачи.
Что хотелось бы узнать от администрации
Хотелось бы получить не просто ответ «данная функция рассматривается», а более конкретную информацию.
По каждому из перечисленных пунктов хотелось бы понимать:
№ Функция Статус Планируется Приоритет Ориентировочные сроки
-- ----------------------------------------------- ------ ----------- --------- ---------------------
1 Общая библиотека для всех проектов ? ? ? ?
2 Полноценный отладчик ? ? ? ?
3 Динамическая смена изображений/анимаций ? ? ? ?
4 Изменение размера и угла шаблонов/групп ? ? ? ?
5 Кастомное наследование от базовых классов TM ? ? ? ?
6 Расширенный экспорт данных/API ? ? ? ?
7 Расширенная кастомизация объектов ? ? ? ?
8 Массовая вставка шаблонов ? ? ? ?
9 SDK/API/плагины для самостоятельного расширения ? ? ? ?
10 Выбор шрифта и толщины начертания ? ? ? ?
Также хотелось бы понимать:
- что из этого уже находится в разработке;
- что находится в планах;
- что находится только на стадии обсуждения/исследования;
- что не планируется;
- какие функции имеют высокий приоритет;
- какие технические ограничения препятствуют их реализации.
Почему важен roadmap
Также хотелось бы предложить администрации рассмотреть возможность создания публичного roadmap развития Simple SCADA. Не обязательно указывать точные даты выхода каждой функции. Даже информация в формате "Исследуется → Запланировано → В разработке → Тестирование → Выпущено", уже позволила бы пользователям значительно лучше понимать направление развития продукта. Особенно важно это для пользователей, которые строят на Simple SCADA долгосрочные проекты и принимают решение, насколько система подходит им для дальнейшего развития. Хотелось бы понимать не только, какие небольшие улучшения появляются в очередном обновлении, но и какие фундаментальные возможности планируется добавить в систему в перспективе года, двух и более лет.
Также хотелось бы видеть не только список будущих функций, но и общую концепцию развития платформы:
- будет ли развиваться система расширений;
- появится ли полноценный SDK/API;
- будет ли улучшаться работа с шаблонами;
- планируется ли развитие объектной модели;
- будет ли расширяться работа с данными;
- появится ли полноценная среда разработки и отладки;
- насколько в дальнейшем пользователь сможет самостоятельно расширять возможности Simple SCADA.
Сейчас некоторые функции, о которых пользователи ранее уже видели сообщения как о находящихся в разработке, спустя 2–3 года всё ещё отсутствуют.
Поэтому хотелось бы получать не просто формальные ответы вроде «функция рассматривается», а информацию, которая действительно позволяет понять, куда и в каком направлении развивается Simple SCADA.
Полагаю, что такой roadmap был бы полезен не только текущим пользователям, но и самой администрации, поскольку позволил бы пользователям понимать стратегию развития продукта и планировать свои проекты на несколько лет вперёд.
Заранее спасибо за подробный ответ.
