Comments 25
Данных о себе и следов пребывания в интернетах люди и так предостаточно оставляют.
Вайбером пользуется миллиард человек (данные примерные, сужу по 2017 году), а значит он устраивает их.
Таким образом, данный проект реализует удалённый доступ к данным, которые контролируются АСУ ТП на базе ПЛК Siemens, через привычные интерфейс повседневного мессенджера. Доступность данных позволяет качественнее управлять технологическим процессом и анализировать его на более высоком уровне.
Если это не приглашение к преступным деяниям, то не очень очевидно зачем это нужно.
Человек не в состоянии ни заменить, ни отследить, ни понять слёту алгоритм работы АСУТП. А уж на экранчике смартфона в мессенджере качественнее управлять технологическим процессом, чем АСУТП? Вы серьёзно так думаете? Или я слишком наивен?
Значит открывается перспектива банального воровства данных.
Кхм, при разработке объем передаваемых данных жёстко ограничен. Отдав во внешний мир уставки тех процесса (например, какую температуру поддерживать в приточке) и задав границы в программе, чтобы при выходе за допустимый диапазон она загонялась обратно в допустимые рамки, вы при всем желании не сможете что-то сломать, украсть или испортить. А уж "украсть" или злонамерно сломать оборудование в данной структуре обмена данными - это вовсе за гранью фантастики.
А чем это лучше простой вебморды?
А зачем в этой цепочке приседания с mysql и вообще вот этот весь велосипед на VBA? Любая вменяемая скада должна уметь из коробки в более стандартные (для управления технологическими процессами) штуки вроде протокола OPC. Тогда останется лишь короткий скрипт на python который напрямую читает из скады значение и транслирует его в вайбер.
Чтобы приложение можно было написать и без скады, а только на средствах среднего уровня. Потому что, как правило, верхний и средний уровень АСУ ТП разрабатывают разные компании
ИМХО, данные лучше хранить в базе. Потом из нее можно вытащить графики и историю. Другое дело, что в базу писать можно прямо из контроллера https://support.industry.siemens.com/cs/document/109779336/connecting-a-s7-1200-s7-1500-to-a-sql-database-?dti=0&dl=en&lc=ru-RU
А потом как на Colonial Pipeline остановится производственная деятельность..
Может не стоит так АСУТП выставлять в инет?
TableName,
Uname,
DBPassword,
DataBaseName,
SQLServer
- не подставляются в сonectionString.
Это -зарезервированные константы для ODBC?
В моём случае эти переменные излишни. Мне их следовало удалить.
В текущей версии ПО подключение к базе данных происходит через ODBC коннектор.
В строчке: SQLConnectionString = "Provider=MSDASQL;Initial Catalog=siemens; DSN=siemens"
Где в DSN указывается имя, настроенное в пункте 2
А здесь уже как раз прописаны IP , пользователь, пароль и сама база данных, в коде остаётся только сделать запрос к нужной таблице, имя которой хранится в переменной TableName
Тут вроде единственная неубираемая вещь в цепочке - сервер на python, который взаимодействует с Вайбером. Можно данные запрашивать с контроллера через TCP или через modbus-TCP и избавиться от панели, базы и скриптов если они реально для чего-то не нужны. Разве нет?
Интересный подход. Мне больше нравится телеграм, и я делал бота для телеги чтобы он мог посылать сообщения в чат при наступлении некоторого события. Там использовался opc клиент написанный на c# который отслеживал состояние сигналов и при превышении порога посылал сообщения.
В принципе разницы нет как делать главное чтобы работало и не ломалось)
Посмотрите в направление Snap7, она вполне закроет потребность в получении данных с неоптимизированных областей памяти ПЛК S7-1200/1500. Если нужен доступ более «легальный», в последних прошивках Siemens Simatic S7-1200/1500 реализован json RPC 2.0, там и через аутентификацию, и определением конкретного набора данных с ограничением к другим «чувствительным» данным.
HMI, скорее, обычные клиент базы данных, а не "скрипт-шлюз". А доступ к переменным ПЛК у панели оператора будет в любом случае, независимо от подключённой базы данных. А если это так, то зачем тратить ресурсы ПЛК на обмен данными с внешним миром, пусть он решает свою непосредственную задачу - управление процессом.
В данном подходе также конкретно определен набор данных, отдаваемых во внешний мир. и очень легко реализуем доступ только для конкретных пользователей.
Спасибо за комментарий, обязательно, почитаю про технологии, описанные вами
Сейчас структура следующая: Viber — Python — MySQL — HMI — PLC.
Я же предлагаю Вам: Viber — Python — PLC.
Аргументирую, почему я считаю это решение странным:
1) HMI не должна быть цепочкой какой либо автоматизации или коммуникации. HMI является самым уязвимым объектом на любом предприятии. В нее тычат пальцам, отвертками и бог знает чем. HMI может подвисать, к ним просто ниже требования к бесперебойной работе чем к ПЛК;
2) В Вашем случае HMI каждый раз при изменении тега подключается и отключается от БД. Повесьте скрипт на 50 — 100 тегов, будет печаль. И производительность HMI, даже RunTime, оставляет желать лучшего, 100+ скриптов будут нагружать достаточно сильно;
3) В данном случае Вы ограничены частотой обновления тега в HMI, а TP1200 это 0.1с. И то, если такой тайминг включить на все теги, фактическая частота обновления такой не будет;
4) АСУТП всегда предполагает самодиагностику. Если по какой либо причине HMI не будет передавать данные в БД, Вы об этом не узнаете (исходя из Вашего текущего решения). Вы будете также получать «Значение = 153», а то, что значение просто старое и не актуальное, нет;
На счет ресурсов, S7-1200/1500 и HMI просто несравнимы по коммуникационным ресурсам, в первых их запас в разы больше. В ПЛК Вы можете всегда иметь ввиду для масштабирования решения установки коммуникационного процессора (например, 6GK7543-1AX00-0XE0 SIEMENS CP 1543-1), он может выполнять функции интерфейсом между технологической и корпоративной сетью (что конечно не все предприятия допускают, но именно этот CP для этого и сделан Сименсом и снабжен соответствующими решения по ИБ).
Честно говоря я могу еще продолжить, но мне кажется, этого уже достаточно.
И Вам спасибо за оригинальный подход к решению задачи.
Кстати да, библиотека Snap7 на Python вполне себе работает. Я на ее основе создавал простенькое отображение температурных датчиков на производстве. И бота на для телеграмм писал тоже с помощью этой библиотеки. Только проблема была в том что бот периодически отваливался от серверов телеграмма. И даже консольный вариант мониторинга и отображения писал.
Единственное что меня не сильно устраивало, так это то что чтение ДБ было долгим. Примерно 0.1-0.2 секунды. Но может это и мой косяк, я так и не понял.
Как написать Viber чат-бота, работающего с АСУ ТП на базе ПЛК Siemens