Комментарии 45
Я правильно понимаю, при передаче значения переменной ее тип не передается? Как программа угадывает его тип? Как отличает целочисленную 5 от строковой '5', например?
Этот нюанс лежит на стороне разработчика со стороны МК, ведь тип тега определяет то как он будет парситься в ASCADA. Ведь так или иначе значение отсылается в символьном виде. Ну а вообще, вопрос вполне справедливый, мне на тот момент показалось удачной идея написать библиотеку для МК внутренностями которой и будет проверяться корректность значения
Мы, видимо, о разных вещах говорим. Ведь ascada и запускается на пк, она ведь и должна парсить входные данные от мк, разве нет? Или, по вашей задумке, данные будут ходить строго от пк к мк?
мне на тот момент показалось удачной идея написать библиотеку для МК внутренностями которой и будет проверяться корректность значения
А разве не проще добавить в тег всего один символ - букву, обозначающую тип. I, F, B, S, например. Это полностью исключит разночтения и существенно упростит парсинг.
На самом деле, каждая переменная (тег) - это текущее значение какого-то датчика. И тип этого значения определяется уже на уровне визуализации исходя из того, что это за датчик.
Специфика в том, что значение датчика может быть физически типа bool ("нормальное стояние" / "аварийное состояние"), а отображаемая переменная при этом будет иметь тип string - расшифровка того, что там не самом деле произошло.
Как выглядит примитивный пример как отправить в тег ASCADA с ID 4 значение float 36.6 от Arduino
Не совсем понятно - связь тега с конкретным датчиком захардкожена в прошивке контроллера?
Если я правильно понял суть вопроса, то - да. Со стороны контроллера необходимо передать какое-то значение на указанный ID тега, а в проекте привязать этот тег к любому объекту, чтобы этот объект выводил переданное в тег значение.
Хорошо. Допустим, у вам на порту 1 висит какой-то датчик.
По ряду причин, вам потребовалось его перевесить на порт 2.
Потребует это правки кода на МК?
Аналогично - есть датчик на порту . Вешаем еще один на порт 2. Нужно править код на МК?
Или в вашем случае "тег" связан с физическим портом на МК (и МК передает фактически значени того, что там на порту висит), а разборки что там это значит уже на стороне ПК идут?
Нет, тег никак не связан с портом. То есть внутри ASCADA реализован парсинг всего что прилетает в порт, и уже в зависимости от того что именно пришло происходит событие которое изменяет значение в привязанных к конкретному тега объектах
при подключении нового устройства требуется изменение кода МК?
Почему спрашиваю. В свое время занимался подобным. Делали "систему мониторинга инженерного оборудования зданий". МК там свои были, на STM32. Визуализация тоже своя - карта обслуживаемого района с объектами, окно аварийных сообщений...
Но там было требование - любые изменения конфигурации должны быть "на горячую, без остановки системы" (просто потому что остановить систему ЛДСС - лифтовая диспетчествкая связи и сигнализация - по нормативам означает предварительное отключение всх лифтов. А их в системе может быть 300-500 штук...)
Посему, у нас была разработана классификация устройств. Например, для датчика типа "сухой контакт" было так:
Тип датчика (информационный, аварийный, триггер, с задержкой)
Нормальное состояние (замкнут/разомкнут) - для всех, кроме информационных
Задержка (для датчиков с задержкой)
Тип датчика:
информационный - не генерирует событий, только возврат состояния по запросу
аварийный - обычный датчик, который генерирует событие при переходе из нормального состояния в аварийное.
триггер - аварийный датчик, который сам не возвращается в нормальное состояние, нужно сбрасывать отдельной командой
с задержкой - аварией считается не одиночный переход в аварийное состояние, но непрерывное нахождение в нем в течении заданного времени
Устройства подключаются к контроллеру нижнего уровня (УСО - устройство сопряжения с объектом). При старте УСО запрашивает у системы карту своих устройств и хранит ее в памяти в виде номер клеммы (куда подключено устройство), тип устройства, блок конфигурации (если нужно). Есть команды "удалить устройство из карты" и "добавить устройство в карту".
Т.е. подключение устройства - сначала идем на объект и физически цепляем устройство на клемму, затем уже с компа его описываем и посылаем команду "подключить". С этого момента система уже с ним может работать.
УСО постоянно "обтряхивает" состояние устройств по карте конфигурации. Обнаружило повод для события (например, переход из нормального состояния авариное) - посылает наверх (на контроллер верхнего уровня - IP-шлюз) короткое сообщение - номер клеммы + состояние.
IP-шлюз добавляет к посылке номер УСО (их несколько, может быть и 10 и 20 и 30 на одном шлюзе) от которого пришло сообщение и отправляет на комп в диспетчерской. Там дописывается номер шлюза и это идет в обработку - номер шлюза+номер УСО + номер клеммы составляют "физический адрес устройства в системе". Дальше блок данных (в общем случае).
Система уже по адресу устройства в таблице определяет что это такое и как нужно обрабатывать данные. Например, для аварийного датчика будет прописано аварийное сообщение - что на самом деле есть "переход в аварийное состояние".
Кроме того, устройство привязано к объекту - где оно установлено. В результате, получив, скажем посылку 01 03 02 01 система раскрутит ее как:
IP-шлюз 1
УСО 3
Клемма 2
Состояние 1
Дальше по таблице - это охранная сигнализация машинного помещения пассажирского лифта, улица .... дом ... подъезд ... Состояние 1 означает "несанкционированное проникновение". На основе всего этого будет сформировано понятное человеку сообщение, еще и на карте будет подсвечено где именно случилось.
Это так, вкратце. В реале там всего кратно больше и сложнее, но в общем и целом принцип такой.
Всё, я понял что вы имели в виду. Смотрите, если конкретная реализация кода на микроконтроллере позволяет на ходу добавлять/удалять какой либо сигнал из системы не останавливая ее - то есть не хардкодом, а конфигурацией то да, так сделать можно. Ведь данный софт не прикладной всё таки, а скорее как конструктор системы. Но в самой ASCADA на горячую изменить тег не получится, придется перезапускать HMI-проект. Как возможный вариант - это зарезервировать заранее в проекте какое нибудь количество тегов и добавлять удалять сигналы путем создания отдельного экрана с текстовыми/числовыми полями и кнопками из разряда: поле номер клеммы, поле ID тега, поле имя сигнала, кнопка добавить/удалить. Но всю механику этих процессов всё равно нужно будет предусматривать в ПО на микроконтроллере.
А можно плагинами сделать? Поллим папку с сериализованными объектами тегов, далее load/unload. Для безопасности и совместимости плагины можно подписывать... и продавать.
Такой функционал можно было предусмотреть и создать еще один объект или окно которое было бы своеобразным менаджером тегов в режиме работы "на горячую", но так как ни разу не сталкивался в своих поделках с такой потребностью - то такого функционала и нету. Ведь всё что тут реализовано возникло только из за того что был нужен тот или иной функционал мне в своих проектах.
Почему в качестве разделителя выбран такой странный символ, &? Чем хуже, например, 0=42.0 1=21.7 ?
Как передать значение переменной из МК в систему понятно.
А как передается значение при изменении свича или слайдера в системе в МК.?
формат сообщений одинаковый?
Изначально SCADA пакет создавались под Unix системы, помню такой SCADA пакет RTAP/Plus от компании Hewlett-Packard, который функционировал по ОС HP-UX, и эти системы были дорогими и доступными только для больших компаний
Потом в какой то момент появились реализации под Windows (один из первых был пакет Intouch) и в силу низкой стоимости и популярности intel+Windows эти пакеты практически вытеснили юниксовый
Затем появился протокол OPC DA , который стал стандартом де факто для SCADA и который основан на протоколе сетевого взаимодействия от MS - DCOM, что надолго привязало SCADA пакеты к платформе Windows (думается MS тут немало пстарались)
Наконец после популяризации Linux и появления спецификации протокола OPC UA, основанного на TCP или HTTPS картина стала постепенно меняться, появилось много решений под Linux
Тенденция сейчас все больше к созданию гуи под Web технологии, наиболее часто встречается связка svg, http, js на платформе которых и делают пользовательский интерфейс
На счет web согласен, в тот момент когда писалась эта программа были даже мысли создавать что то вроде сервера с вэб-мордой на которой было бы такое же отображение объектов как и в обычной реализации, чтобы можно было с любого устройства в сети выйти на страницу. Но кроме мыслей это никуда ее пошло, ни времени на это не было да и знаний, думаю, тоже
По сути так и есть - это решение из прошлого века.
Я даже больше скажу, когда мы заменили скаду на собственное решение с использованием Grafana получилось в итоге даже лучше. Потому что смотреть на цифры в один момент времени не имеет большого смысла. Графики показывают полноценно работу системы, и по ним можно полноценно диагностировать проблемы.
Ну и в целом SCADA в том виде в котором она была - имеет ну слишком много проблем. Рассказ об этом на самом деле тянет на целую статью.
Ну вот мы сразу собственное решение двигали. Но... Начиналось это в 1993-м году (первые мк делали на 8080) и про скаду никто тут не слышал еще.
Вообще все с нуля делали, аналогов в стране не было.
Ну а аотом уже не было смысла на скаду уходить - слишком много наработок было.
Окончательная версия - двухуровневая сеть мк (между собой они по rs485 общались, с сервером по udp), сервер ("ядро") к которому с одной стороны подключались мк верхнего уровня, с другой - интерфейсные клиенты разного плана (диспетчер, аварийная бригада, еще что-то).
Все это сильно распределенное было и достаточно объемное
Мы делали сами систему сбора данных, разные протоколы, под разные SCADA и на текущий момент практически во всех проектах ее используем
Делали и SCADA , но не стали ее развивать, слишком это дорого, не окупится
У нас оно было специализированное - то, что на диспетчерских в УК работает. Соответственно, интерфейс был сразу заточен на "неквалифицированного пользователя" - максимально просто и наглядно показывать что и где случилось.
Основная специфика там была в том, что все это очень распределенное в пространстве - по всему городу (два дома тут, три дома там...), а иногда еще и по городам-спутникам.
На компе в диспетчерской "ядро" (которое и маршрутизатор и отношение "многие-ко-многим" и монитор состояния контроллеров верхнего уровня и еще куча логики в нем), к нем по UDP подключаются контроллеры верхнего уровня (IP-шлюзы) - их там может быть штук 20.
К каждому IP-шлюзу по RS485 подключались несколько (где-то 5-ти хватало, где-то до 30-ти доходило) контроллеров нижнего уровня (УСО - устройство сопряжения с объектом). На них уже размещались "клеммные доски", позволяющие физически подключать устройства.
Устройства самые разные - датчики всякие, например, охрана служенных помещений (электрощитовая, машзалы лифтов), контроль работы клапанов дымоудаления, пожарная сигнализация (она на пульт пожарной охраны идет, но и на диспетчерскую тоже дублируется), лифтовые контроллеры...
Механизмов мало было - дистанционные замки в служебных помещениях.
Были устройства ГГС - громкоговорящая связь полудуплексная (со служебными помещениями, с кабинами лифтов) - там кнопка вызова + устройство коммутации линии + VoIP линия.
Видеонаблюдение можно было подключать, еще (где просили) подключали приборы общедомового учета (чтобы данные автоматом в диспетчерскую снимались).
В общем и целом на диспетчерской могло быть порядка тысячи устройств (одних лифтов 500-600 штук ну и остального...)
Протокол обмена - двоичный, датаграммы где в заголовке "физический адрес устройства" (номер шлюза - номер УСО - номер клеммы) + блок данных переменной длины который интерпретировался уже в соответствии с тем что это за устройство.
К ядру уже по TCP подключались интерфейсные клиенты. Они разных типов - диспетчер, аварийная бригада, просмотр логов и т.п.
Каждый клиент при регистрации в ядре указывал свой тип и как он будет работать - получать все из системы (диспетчер), получать сообщения только от заданной группы устройств (аварийная бригада - их интересуют только лифты и то не все, а только те, что за этой бригадой закреплены), вообще не получать сообщений, только ответы на посланные им запросы состояний и т.п.
Конфигурация вся "на горячую" - сначала физически подключаем устройство к клеммам, потом на компе уже включаем его в систему (описываем - где, что, куда подключено). На соотв. УСО уходит инициализация и устройство начинает работать.
Для новых типов были предусмотрены "драйвера" в виде DLL. Указывается в конфигурации и пришедшая датаграмма отправляется туда. А там уже вся ее обработка, вывод сообщений всех и т.п. В этом случае передо добавлением устройства добавлялся новый "тип" с указанием "драйвера".
Конфигурация в виде двух деревьев - с одной стороны дерево устройств: шлюз-усо-устройство, с другой - дерево объектов: улица-дом-подъезд... Каждое устройство связано с объектом, на котором оно физически установлено.
Все это позволяло формировать аварийные сообщения человеческим языком - что где случилось и подсвечивать все это на карте (все объекты были с привязкой к карте и детальной схеме объекта (например, дом - есть на карте, можно посмотреть детальную схему с подъездами и прочим).
Все это было проще реализовать самим чем путаться вписывать в какую-то готовую скаду.
С вебом решили не связываться. Все было в двоичном виде. Для интерфейсных клиентов в ядре был свой TCP сервер куда они подключались. Т.е. запускаешь клиент, указываешь к какому объекту подключаться (IP-адрес из справочника) и вперед - регистрация клиента в ядре и работаем.
Расскажите подробней, пожалуйста. С какой скады ушли? Что использовали для архивирования данных? Как реализовали управление из графаны, самописные плагины или что-то еще? Как у нее со стабильностью в таком сценарии использования, если оставить вкладку с автообновлением на месяц - работает?
Ушли с CodeSys (2?) не помню если честно. Дело в том что изначально не мы делали этот проект.
Суть проекта - мониторинг. Тот кто это делал до нас, поставил модули ввода, завел в них датчики, поставил ПЛК, прописал это все дело в ПЛК, поставил OPC + SCADA.
Но в итоге меня попросили посмотреть, можно ли с этим что то сделать, потому что это работало от слова "никак". Производительность просто отвратительная, схема отвратительная, как и конечный результат соответствующий.
Вносить изменения в такую схему для меня было просто неприемлемо сложно. Взять проект ПЛК, прописать входные данные, выходные данные, залить прошивку, прописать OPC сервер и только потом получить все это дело в SCADA.
В конечном итоге из этой схемы я выкинул все кроме модулей ввода.
Мы экспериментировали со сборщиком на PHP но результат был не очень.
Потом родился VRack и мы начали собирать данные им сразу в 2 базы ClickHouse и Graphite. А отображать все продолжали в Grafana.
Отдельно хотелось бы выделить ClickHouse, боже это просто чудо. Мы делаем запросы к нашим устройствам, получаем с них данные по датчикам и сохраняем их в ClickHouse. На данный момент у нас в базе данных только по датчикам 7 533 369 159 записей, таблица занимает в базе всего 36GB. ClickHouse супер эффективная база данных для хранения именно сырых данных. Поэтому мы пихаем в нее все что считаем нужным. Например, дополнительно к получению каждой метрики по датчику мы так же сохраняем сколько времени у нас ушло на запрос. Это позволяет локализовать сетевые проблемы или проблемы с оборудованием (преобразователи или сами модули ввода).
В ClickHouse есть агрегируемые таблицы, вам не нужно самим заниматься агрегацией, база все сделает за вас. Есть несколько движков таблиц, таблица даже может прикинутся Graphite-like таблицей.
Если вы сами занимаетесь получением и хранением данных - рекомендую, независимо от масштаба ClickHouse.
Такс, по поводу управления. Управление если необходимо осуществляется у нас обычно через отдельный самописный интерфейс для мобилки. С появлением Vue2/3 и VRack для меня это перестало быть хоть какой то минимальной проблемой. Вобще если вам интересно - можете глянуть могу статью про VRack.
По поводу графаны - у нее есть для нас серьезная проблема. Графана ну слишком быстро развивается. Она работает в целом хорошо, но нас по итогу она не устроила и мы переходим сейчас на собственное решение. В итоге стек для решение тех задач у нас - VRack/VRack-db/Clickhouse/Vue3/ECharts/.
Просто для понимания трудозатрат - все это я делаю в одного. Например новый интерфейс вместо графаны я сделал за 4 вечера и 2 выходных. Соответственно в этот интерфейс при желании я могу встроить управление, VRack мне это позволяет.
VRack-db я использую для кеширования данных и моментального отображения графиков. Graphite хоть и хороша, но у нее есть концептуальная проблема - он очень сильно нагружает SSD, 3-4 года и SDD на выброс. Я подумал подумал и решил вобще не хранить данные на SSD для отображения графиков и просто запилить In Memory базу данных. В формате Graphite с нужной нам точностью все метрики у нас занимают в памяти не больше гигабайта. В случае чего все равно есть сырые данные в Clickhouse.
Для меня сейчас, самое главное - это мобильность. Если инструмент не позволяет себя расширять или заменять, я на него даже не посмотрю. В OpenSource сейчас есть кучу реально крутых вещей, ClickHouse хороший тому пример.
Получилось чет многовато. Короче как я и говорил, это тянет все на отдельную статью)
Спасибо, очень интересно! Надо будет где-нибудь применить. И ещё найти аналогичную систему с открытым исходным кодом, чтобы не зависеть от пропадания с гитхаба
Похоже вы повторили то что сделана на мониторах Nextion Но там конечно возможностей побольше будет в плане создания интерфейса и разных скриптов на события.
Вопрос : а по ТСР эта система работает , а то только про сом порт речь идет
Стоит лишь выбрать в каком месте на компьютере создать иконку и дать ей имя. Как только мы нажмем Accept, то по указанному пути создастся иконка приложения, при нажатии по которой, наш проект сразу запустится, и, при необходимости, откроет нужный COM-порт!
Кстати да, на момент создания этого софта я еще не знал про Nextion (возможно их тогда и не было, либо были не популярны), но позже когда для очередной поделки решил воспользоваться их дисплеем, то тоже подумал что есть большое сходство, особенно в плане протокола обмена. Видимо, ребята тоже старались сделать чтобы было максимально просто. Но всё же у них направление на "гуи" для дисплейного модуля, а не для работы на ПК. Для Modbus RTU и Modbus TCP предусмотрен такой элемент как "девайс", в котором можно настроить какой регистр с какого адреса привязать к тегу и прочие вещи как байт-свап и т.д. На счет автозапуска по TCP, если память не изменяет, то я такого не делал. То есть нужно будет вручную нажать "Connect all devices".
Автор, вы делаете великое дело! На самом деле, многие это еще не осознают, потому что многие думают "scada это фронт, а я бэк, купят как нить". Есть маленькие проекты, типа CaScada, но все закрытое, каждый хочет свой кусок с асушного пирога урвать, а пирожок то маленький. Если для фирм\заводов платное решение да с поддержкой - нравится, то и в путь, господа.
Есть проекты средней величины типа OpenScada. Но оно уже переусложнено, плюс разработчики из Украины....сложно.
Можно пиратить. Но опять же как указал автор - высокий порог входа. Он не то чтобы высокий, но специфичен у каждой системы, и вот эта специфика добавляет постоянно мноооого геморроя. Система как будто говорит нам: наймите специалиста. Заплатите денег побольше! А потом еще! И еще много-много раз. Система в этом не виновата, ее такой создали разработчики, которым в свою очередь диктовали требования маркетологи. Плюс "как быть пряником и нравиться всем". Кому то не нужен OPC сервер, а какой нибудь завод скажет - о, у нас такие обьемы, конечно без серверов никуда, все будет. И выкатят им софт, которому они только и будут радоваться. Стоп. Получается только крупные заказчики и используют весь (и то не весь) функционал типичных SCADA, а на мелких плевать, и это так и есть. А те кто разрабатывают небольшие скады, хотят почему то денег. Их тоже можно понять. Но нужно понимать и сегодняшнее положение дел в асутп. Денег там 0. Спецы бегут. А кто остался - поддерживают существующее костылями. Я сам там работал, поддерживая древние скады еще под DOS, siemens S5 -115 и рулящее мощными механизмами. Это актуально до сих пор, и оно будет работать, потому что а смысл что то обновлять, если работает? Хорошо, жк экран поставим.
Универсальность готовых продуктов - одновременно их и плюс и минус. Может подойти для любого техпроцесса. Но разворачивание и настройка превращается в кипение в котле будто ты грешник.
Автор, твори, делай! На маленьких производствах, дома, такое очень востребовано!
Спасибо за теплые слова. Это решение именно для домашних проектов т.к. нет гарантий на отказоустойчивость и так далее, зато очень просто и быстро.
Нет, самоделки в этой области это гемор.
/- Ой, у нас студент что то сделал, поправьте плз.
Исходники есть?
-Нет
Пиратьте пока дают Сименс, ГЕ, РА
ЗЫ. Тема очень сложная, не для самодельщиков.
Смотря про какой уровень идет речь, если в промышленности либо на крупных объектах то однозначно крупные системы с экосистемами, которые отлажены со временем. Если дома, для условной теплицы - то вполне что то из самоделкиных сгодится. Я, проработав несколько лет в атомной промышленности, никогда в жизни не стал бы использовать что то самодельное, даже если бы был в нем уверен так как ответственность огромная.
Даже из крупнейших систем на рынке приходилось выбирать очень тщательно. И за обилием минусов в виде тяжести, стоимости и частичной монопольности системы я считаю одними из лучших это Siemens, так как надежность иногда просто поражала.
У Сименса хоть и хорошие решения но проприетарнейшие. Тут даже если пиратить, очень много "черных ящиков", оверинжиниринг во все поля, высокий порог входа. Например, у меня так и не получилось поработать с Step 5. Я брал аутентичное железо, ставил туда этот пакет, все дистрибутивы были. И DOS я очень неплохо знаю. Но сам принцип работы, это такое черезжопное колдунство, что осилить его так и не получилось. Ну, может я не справился. Виндовые версии step simatic - вот там уже все понятно. Но TIA Portal, это ж такой монстр, они туда захотели упаковать все что только можно, и все равно дальше клепают каждое под свое.
Step5 был написан под CP/M, потом портирован под DOS и WinNT. Тогда были еще другие, ранние интерфейсы. Впрочем, я работал, вполне удобно по хоткеям.
И называть пропиетарнейшими разработки первопроходцев, ну тут я даже не знаю =)
А про монструозность это да. Тиа портал вышел, когда ССД только появились но без нее не работал.
А вот WinCC 3.1 вышел под Win95 и ужасно тормозил на 16Мб памяти. А сейчас летает... =)
Ну что они были первопроходцами - я даже и не знаю. В чем сименс был первопроходцем? В проприетарщине? О да. В зависимости от правительств? Да, потому что технологии экпортировал критичные для инфраструктур. И те все понимали а с иглы не слазили. А еще в своей проприетарщине сименс настолько "осименсовел", извините за выражение, что совершенно плюет на обратную совместимость своего ПО и своего оборудования. Все в угоду кошельку. Осименсовели, и это я вижу аж с начала нулевых.
Публикации
Мал, да удал. ASCADA. Простейшая система диспетчеризации (SCADA) для Arduino и других микроконтроллеров