Comments 73
В семье Распберри есть вполне промышленный модуль Raspberry Pi Compute Module 3
Для него есть вполне индустриальные платы и корпуса, типа Revolution Pi и прочее.
Уточняю, если не понятно: этот модуль предназначен для встраивания в промышленные изделия. Тем параметрам, которые от него зависят, он отвечает в полной мере — например имеет индустриальный диапазон температур. А соответствие остальным требованиям уже должно обеспечиваться самим изделием — защита от радиопомех, пыли и т.д. — соответствующим корпусом, I/O — схемами защиты на материнской плате и т.д.
Также замечу немаловажный для промышленности фактор — доступность. Данные модули будут гарантированно производиться как минимум до 2023 года. Кто вложился в разработку своей платы, тот поймет.
Как выглядит в реале промышленный Raspberry Pi на базе этого модуля, можно посмотреть тут.
Вообще даже обычный Raspberry Pi можно довести до вполне "промышленного" уровня, засунув его в металлический заземляемый корпус, в качестве блока питания взяв не китайскую фигню, а что-то более подходящее из индустриальной автоматизации, и подключив его к тому же свитчу Moxа коротким кабелем. И естественно никаких других подключений к периферии самой платы. Тогда по ЭМС он выдержит практически все, и только по температуре и влажности будет похуже.
Доступность до 2023 года почти ниочём для промышленных изделий, к нам требование, к примеру, 20 лет. И поставка запасных частей в любое время этого срока в течение 3-6 месяцев после заказа.
Засунутая малинка в корпус металлический, весьма вероятно пройдет по ЭМСу по питанию, но скорее всего не пройдёт наведенное на нее поле — разьемы то присутствуют.
Но вот вибрация и температура, это под большим вопросом.
А устойчивость к вибрации как он обеспечивает? за счет корпуса?
Вы проходили испытания на вибрацию? Я проходил и если на плате нету особо тяжелых компонентов, типа электролитов (а на CM их нету), они проходятся на ура. DIMM разъемы в промышленном оборудовании используются.
Ну и кстати за счет корпуса — а почему бы и нет? Прикрутить все это дело через резинки — и ее в космос можно будет запускать.
Доступность до 2023 года почти ниочём для промышленных изделий, к нам требование, к примеру, 20 лет.
Ваши требования производителям микропроцессоров пофиг. Найдите хоть один микрокомпьютер, который будет гарантированно доступен так долго. Подсказка — у Intel на встроенные процессоры гарантия доступности всего 7 лет и потом переходите на другую железяку. Не стоит это путать с готовыми промышленными изделиями — вы можете абстрагировать свое железо как хотите и через 20 лет эмулировать своим клиентам 8-и битную железяку с 10кБ памяти, хотя по настоящему у вас там будет стоять уже 3-я ревизия 32-х битного ARMа.
Но это не отменяет того факта, что когда вами используемый ARM перестанут производить — а это произойдет гораздо раньше назначенного срока в 20 лет, вам придется перелазить на что-то следующее, переразводить плату, опять проводить типовые испытания — а это деньги.
но скорее всего не пройдёт наведенное на нее поле — разьемы то присутствуют.
Чего? Что это за испытание такое?
он отвечает в полной мере — например имеет индустриальный диапазон температур
А можно пруф где сказано что он удовлетворяет хотя бы температурам. На сайте не нашел подтверждения этому.
Ну блин, хоть гуглить не ленитесь.
https://www.raspberrypi.org/documentation/hardware/computemodule/datasheets/rpi_DATA_CM_1p0.pdf
Это в пределах одного помещения. А если разнесены территориально, как это повсеместно в энергетике, то преобразуется в tcp и по существующим сетям уходит в центральный узел сбора и обработки.
Действительно нет, но можно извратиться (производителю счетчиков) и поменять местами Modbus Клиент (SCADA)-Modbus Сервер (Счетчик) и заставить счетчик писать в регистры SCADA системы по изменению вместо того что бы опрашивать его со стороны SCADA системы.
Еще не очень понятно, откуда появляются задержки в ответах аппаратных серверов Modbus, тем более на простые запросы.
В сети RS-485 хватит таймаута 50-100 мсек. В Ethernet необходим гораздо больше.
> а если составной канал с неизвестным оборудованием?
Ага, и с неизвестным протоколом обмена.
> Таймаут должен быть регулируемым,
Регулируйте, пожалуйста.
На 9600-38400 кбит/сек 50-100 мсек хватит всем. Обращаю ваше внимание, что в статье рассматривается сеть RS-485.
Я Вам про 485 и говорю. И как раз на скоростях 9600-38400 бит/c весьма возможны соединения через медленный тракт — как примеру, в одну сторону (обращаю внимание !) время прохождение порядка 70 мс.
Для интегрированного в плату (либо платы-адаптера) рекомендую размер приемного FIFO буфера установить в 1. Это резко уменьшает задержки в приеме пакета, так как таймаут стандартного драйвера работает по частотной сетке 55мс.
Сужу только по практическому отсутствию реализаций OPC UA — даже не интересовался (было не нужно), что из этой тройки он умеет.
А еще ведь есть 60870-5-103 и 61850. Сомневаюсь, что настолько разнородные идеи можно в одну коробку.
Отдельный вопрос про OLE и Linux и SCADA и Linux. Второе еще реализуемо, но первое…
(OPC это и есть OLE 4 Process Control, кто не в курсе)
> Сужу только по практическому отсутствию реализаций OPC UA
Уже есть. Поинтересуйтесть.
> А еще ведь есть 60870-5-103 и 61850. Сомневаюсь, что настолько разнородные идеи можно в одну коробку
Вы сомневаетесь, а уже есть спрос на преобразователь modbus в 61850.
OLE в Linux нет!
>Уже есть. Поинтересуйтесть.
Есть Кепварь. Просто слишком мало есть, чтобы создать рынок
>Вы сомневаетесь, а уже есть спрос на преобразователь modbus в 61850.
очень нужен, но нужен читатель 61850 (в modbus просят из-за ограниченности какого то софта). а еще по 61850 есть управление
не уверен, что твоя схема (можно на ты в ответ), сможет читать 61850 в UA
>OLE в Linux нет!
а ОРС, которое поверх OLE, есть ????
OPC UA не поверх OLE, а поверх TCP IP в рассматриваемом в статье случае. Изучайте матчасть.
Ну и OPC — оно же клиентам отдается (скадам там всяким и экселям) — и это позиционируется как его уникальное преимущество, и как так если в OPC UA его вдруг нету?
т.е если нету такого св-ва, то оно нафиг никому не нужно. и это все объясняет (0 на рынке)
> т.е если нету такого св-ва,
Чего нету? Того что сервер отдаёт данные клиенту?
ИМХО это никому не нужно/ на картинках из статьи — фикция, ибо СКАДЫ, поддерживающие OPC UA еще нужно поискать
Как вам динамика популярности trends.google.com/trends/explore?date=all&q=%2Fm%2F026g9gw ??
Кстати нам тоже надо аналогичное решение, только для диспетчеризации. В данном случае шлюз должен собирать данные по CANopen, а передавать наверх в виде того, что поддерживает диспетчеризация — MODBUS TCP, OPC UA, REST итд.
Прельщает то, что такой шлюз будет работать независимо от основной системы и в случае чего ничего страшного не будет.
И думал также сделать это на том же Raspberry Pi — соответствующая плата уже есть.
Можете реализовать софтверную часть? Можно в личку.
В статье, к сожалению, не рассмотрен один из серьезных аспектов в данном бизнесе — Кибербезопасность (Cybersecurity).
Вы пробовали проходить сертификацию или хотя бы что-то делать в этом направлении? Вроде у Microsofta были неплохие курсы по этому делу — Threat Attack Modelling, Password Policy, сертификаты и т.д.
Без всего этого ваш сервер будет очень опасно выпускать в открытый интернет.
> Без всего этого ваш сервер будет очень опасно выпускать в открытый интернет.
Я и сам против этого.
Это сравнительно новый вид сертификации, который еще далек от совершенства. Есть определенные стандарты, но скорей всего у нас о них ничего не известно, даже в мире в них мало кто разбирается.
Сравнительно хорошая методика раписана в NERC-CIP и они в открытом доступе. И это хоть для подстанций, но протоколоы DNP3 и 870-5-104 там тоже используются, поэтому более или менее подойдет и для индустрии.
Вот пример SCADA Гейтвея и что они пишут о Кибербезопасности:
Strengthen cybersecurity
Create an NERC CIP-compliant electronic perimeter to protect substation devices
Secure SCADA protocols using TLS and X.509 certificates as per IEC 62351-3
Implement DNP3 secure authentication V5 as per IEC 62351-5
Protect your system with a built-in firewall and integrity check
Secure SCADA communications and certificate-based authentication.
Signed firmware updates.
Malware protection.
Field-upgradable firmware to address technical and cybersecurity issues.
В общем надо разбираться, что там за Compliance нужен и где это можно исследовать.
Интернет, к сожалению, не ориентируется на российские стандарты. Может про сертификацию я и загнул, но в качестве методички:
Security features
Integrated firewall
Secure maintenance connection (SSL/TLS)
Secure SCADA protocol (SSL/TLS)
AES-128/256 encryption
X.509 certificates
Secure remote access for IED maintenance (Passthrough)
Account management: Strong passwords, User accounts and user groups, Detailed group permissions
Access management
Access attempts logs
Account lock upon failed access attempts
Retrievable access logs for auditing
Syslog support for remote log storage
All system components digitally signed
Continuous file monitoring for system integrity
Achilles certification
Nessus compliance
По всему этому должно быть достаточно документации, и если это все реализовать, то можно надеяться, что ваш сервер выстоит против достаточно большого спектра атак. Но все это только надежды.
В статье речь идёт об OPC UA.
Изучите мат часть ru.wikipedia.org/wiki/OPC_UA#Протоколы далее находите фразу 1. Двоичный протокол
> Про Modbus TCP — в пакете данных содержится поле TransactionID
В протоколах сэт-4 и меркурий 230 таких полей нет. Как с ними предлагаете быть?
Изучите мат часть ru.wikipedia.org/wiki/OPC_UA#Протоколы далее находите фразу 1. Двоичный протокол
Вы склонны верить всему, что в Вики написано? Это не протокол, а сериализация данных в бинарный поток, а на транспортном уровне это может быть как TCP, так и UDP. Да хоть в тот же Modbus RTU «заворачивать» можно, используя функции из пользовательского диапазона функций.
Шлюзы промышленных протоколов обмена на Linux. Собери сам