Рис. 1. Многообразие протоколов обмена, используемых в АСУ ТП
Кратко о том, как устроена типичная система сбора данных (Немного упрощенно).
Рис. 2. Система сбора данных
Специальное ПО, называемое OPC-сервером ведёт опрос устройств, подключенных к интерфейсу RS-485. OPC-сервер является своего рода прослойкой между SCADA-системой и устройствами, переводя язык на котором общаются устройства в язык, понятный SCADA-системе. Преобразователь Ethernet/RS-485 служит для преобразования TCP/IP-пакетов в пакеты, которые ходят по физической среде RS-485.
Эта схема имеет ряд недостатков:
- Установим, например, в ОРС-сервере таймаут ожидания ответа 200 мс. В идеальном случае, когда пакеты в Ethernet ходят без задержек, обмен с устройствами идёт с хорошей скоростью (интенсивностью). Но если пакет, содержащий ответ, задерживается, например, на 300 мс (это больше таймаута ожидания ответа 200 мс), то ОРС-сервер считает, что ответ на запрос не пришел и отправляет следующий запрос. В это время приходит ответ на предыдущий запрос, но ОРС-сервер думает, что это пришел ответ на текущий запрос и передаёт неправильные данные наверх. Как результат данные на АРМе «скачут». Чтобы уйти от таких ситуаций установим таймаут больше. Возьмём с запасом — 3000 мс. Если ответ приходит раньше 3000 мс, то оставшееся время не ждём, переходим к следующему запросу. Пока всё идёт хорошо, но стоит нескольким устройствам перестать отвечать, как образуются задержки по 3000 мс на каждое устройство. Время опроса увеличивается.
- Большинство протоколов, используемых в АСУ ТП (Modbus, счетчики э/э) основываются на последовательном опросе одних и тех же параметров. Учитывая, что большую часть времени значения параметров остаются неизменными, сеть передачи данных используется для передачи одного и того же. Это нерационально, если среда передачи GPRS, и трафик стоит денег. Кроме того, в среде передачи GPRS задержки прохождения пакетов могут достигать нескольких секунд. Зачем тратить время и ресурсы для передачи одного и того же?
Для вышеперечисленных ситуаций более подходит протокол, в котором данные передаются наверх по изменению (спорадически) и сгруппированными по несколько значений в один TCP-пакет. Такими протоколами являются МЭК-60870-5-104 и OPC UA. Подойдёт и ModBus-TCP, в нём нет передачи по изменению, но зато, если данных немного, их можно упаковать в один пакет. Хорошо бы иметь какой-нибудь контроллер, который можно повесить на DIN-рейку, подключить к нему устройства по RS-485 и передавать данные по Ethernet в SCADA-систему.
В общем какие-то аппаратные шлюзы есть и в немалом количестве. Но в виде готовых неделимых решений. Всё в одном. И это мне не особо нравится. Понадобился мне когда-то шлюз, преобразующий протоколы счетчиков СЭТ-4ТМ в OPC UA с шестью портами RS-485 и двумя Ethernet. У одного производителя есть шлюз с поддержкой нужных протоколов обмена, но мало портов RS-485, у другого есть нужное количество портов RS-485, но нет двух портов Ethernet. У третьего есть два порта Ethernet, но нет всех протоколов обмена. У четвёртого есть почти всё, но нет OPC UA, имеющиеся на борту МЭК-60870-5-104 или ModBus-TCP требуют ОРС-сервера для этих протоколов.
А как бы было замечательно: купить контроллер или мини-ПК с ОС у одного производителя. Купить ПО для контроллера у другого. Если одного производителя ПО не поддерживает что-то, докупить что-то из ПО у другого, объединить между собой компоненты ПО через стандартный программный интерфейс. Казалось бы, вот оно светлое будущее!
Вот поэтому шлюзы протоколов применяются реже чем связка «ОРС-сервер и «Преобразователь Ethernet в RS-485»» — из-за их неделимости на компоненты.
Одна из причин, почему мало развиты SCADA для Linux: SCADA есть, протоколов обмена в ней поддержано мало, а ОРС-серверов для связи с оборудованием нет. SCADA оставляет интегратора один на один с железом.
Читатель уже может задавать вопрос: Что можете предложить? Что уже есть? Есть OPC UA серверы для Linux для следующих протоколов:
- МЭК 60870-5-104;
- МЭК 60870-5-101;
- Счетчики Меркурий 230, 231, 233, 234, 236;
- Счетчики СЭТ-4ТМ, ПСЧ-3ТМ, ПСЧ-4ТМ;
- Счетчики Энергомера;
- SNMP;
- MQTT;
- Счетчики Меркурий 200.
Чтобы на верхний уровень можно было передавать данные не только по протоколу OPC UA, создан «Преобразователь OPC UA в Modbus и МЭК 60870-5-104». Помимо функции передачи данных по этим протоколам, «Преобразователь» имеет встроенный web-сервер. С помощью специального редактора можно нарисовать схему, на неё вывести значения тэгов, а потом открыть её в браузере. Получается мини-SCADA непосредственно в контроллере. Как работает оживление схемы я уже писал здесь, про редактор здесь. В будущем планируется «Преобразователь OPC UA в MQTT».
OPC UA серверы и преобразователь работают на архитектурах x64, ARMv7 и AARCH64.
Таким образом, для аппаратной части можно использовать как проверенные временем решения на базе мини промышленных компьютеров, так и всевозможные «raspberry pi совместимые» ARM миникомпьютеры. Как производится установка и настройка ПО с примерами можно почитать здесь или здесь.
В общем виде структура комплекса выглядит так:
Система обладает масштабируемостью. Используются компоненты необходимые только для решения текущей задачи.
С использованием OPC UA сервера наша схема преобразуется:
У нас получилось следующее:
- OPC UA сервер собирает данные с устройств по RS-485 без больших задержек между запросами;
- Данные в SCADA выдаются по нескольку штук в одном TCP-пакете по изменению;
- К OPC UA серверу можно подключить несколько одинаково настроенных АРМов. Пригодится, если нужно дублирование.
Таким образом, вместо связки ОРС-сервер и «Преобразователь Ethernet в RS-485» у нас получается одно устройство, объединяющее в себе их функциональность. Мне такая схема нравится больше. А Вам?
Комментарии (71)
Javian
17.12.2018 16:31Это в пределах одного помещения. А если разнесены территориально, как это повсеместно в энергетике, то преобразуется в tcp и по существующим сетям уходит в центральный узел сбора и обработки.
Yak52
17.12.2018 16:55> Подойдёт и ModBus-TCP, в нём нет передачи по изменению…
Действительно нет, но можно извратиться (производителю счетчиков) и поменять местами Modbus Клиент (SCADA)-Modbus Сервер (Счетчик) и заставить счетчик писать в регистры SCADA системы по изменению вместо того что бы опрашивать его со стороны SCADA системы.Opc-server Автор
17.12.2018 17:04А если счетчиков несколько на RS-485?
andranick
17.12.2018 19:11Вам ответили про Вашу же фразу про ModbusTCP (никакого 485), теоретически предположив возможность поднять сервер протокола на стороне верхнего уровня, клиента — на устройствах, и передавать данные спорадикой (зачем нужно при наличии 104 протокола — ХЕЗ, но, безусловно, мысль интересная своей нетривиальностью)
Opc-server Автор
17.12.2018 19:13Это будет не стандартный ModbusTCP. Зачем ещё один протокол обмена, непонятно.
Borjomy
17.12.2018 17:20Не совсем понятно, каким образом предлагаемая система решает проблему таймаутов удаленных устройств. Ведь с этого все начиналось. Не проще-ли использовать многопортовые преобразователи COM-TCP?
Еще не очень понятно, откуда появляются задержки в ответах аппаратных серверов Modbus, тем более на простые запросы.Opc-server Автор
17.12.2018 17:24В сети RS-485 хватит таймаута 50-100 мсек. В Ethernet необходим гораздо больше.
sav6622
17.12.2018 17:34С чего вдруг такой постулат, что 50-100 мсек хватит всем? А если через оборудование ВЧ-связи, к примеру? а если составной канал, с неизвестным оборудованием? Таймаут должен быть регулируемым, уже наступали на грабли что некоторые ТМщики считают таймаут от скорости соединения по Ethernet (10 Мбит или 100 Мбит), совершенно не задумываясь, что бывают и другие каналы со временем совсем НЕоптическим.
Opc-server Автор
17.12.2018 17:45На 9600-38400 кбит/сек 50-100 мсек хватит всем. Обращаю ваше внимание, что в статье рассматривается сеть RS-485.
> а если составной канал с неизвестным оборудованием?
Ага, и с неизвестным протоколом обмена.
> Таймаут должен быть регулируемым,
Регулируйте, пожалуйста.sav6622
17.12.2018 18:03На 9600-38400 кбит/сек 50-100 мсек хватит всем. Обращаю ваше внимание, что в статье рассматривается сеть RS-485.
Я Вам про 485 и говорю. И как раз на скоростях 9600-38400 бит/c весьма возможны соединения через медленный тракт — как примеру, в одну сторону (обращаю внимание !) время прохождение порядка 70 мс.Opc-server Автор
17.12.2018 18:07сеть RS-485 — это два провода длинной до 1.2 км. Как в проводе с такой длинной может быть задержка 70 мс?
sav6622
17.12.2018 18:11Ну почему же просто ДВА провода, это может быть и удлинение через любую аппаратуру (а-ля мост в терминологии Ethernet), через геостационарный спутник, к примеру — там вообще задержки секундные будут.
Opc-server Автор
17.12.2018 18:18Перечитайте первую часть статьи, где я писал про Ethernet.
sav6622
17.12.2018 18:22Перечитал, я к тому, что задержки до нескольких сот мс НЕ только через Ethernet, но и просто в 485 возможны (вообще без конвертации в Ethernet)! и говорить о том, что 50-100 мсек хватит всем, как минимум неправильно.
Opc-server Автор
17.12.2018 18:24Погуглите с интернете скорость распространения электромагнитной волны.
sav6622
17.12.2018 18:27Перечитайте мои комментарии, попытайтесь понять. Я не говорю про «просто два провода 485».
Opc-server Автор
17.12.2018 18:36А я про просто два провода 485. Если в сети есть что-то вносящее задержку, то ОРС UA Сервер нужно ставить как можно ближе к устройству.
sav6622
17.12.2018 18:39А с чего вдруг столь категорично? а если сеть из 10 устройств 485 и только одно из них «удален вдаль» физически за десяток мс (каким либо каналом), зачем мне разоряться на второй OPC UA в таком случае, когда можно обойтись одним, который просто учитывает что задержка по 485 может быть до 150 мс, к примеру.
Opc-server Автор
17.12.2018 18:43Довольно редкая конфигурация.
Ставьте какую хотите задержку, кто не даёт?sav6622
17.12.2018 18:46Я всего лишь несогласен с заявлением, что «640 кбайт хватит всем». Конфигурация не столь редка, натыкались на грабли когда некоторые производители в принципе НЕ дают регулировать задержку, а ставят ее, к примеру, в зависимости от выбранной скорости 485.
Borjomy
17.12.2018 18:13А параметры буферов регулировать не пробовали? Преобразователь не будет каждый байт отдельным пакетом пересылать.
Для интегрированного в плату (либо платы-адаптера) рекомендую размер приемного FIFO буфера установить в 1. Это резко уменьшает задержки в приеме пакета, так как таймаут стандартного драйвера работает по частотной сетке 55мс.Opc-server Автор
17.12.2018 18:21Обычно все байты в одном пакете приходят. Но если приходят несколько неполных пакетов, ПО это распознаёт и программно соединяет.
Borjomy
17.12.2018 18:27Преобразователь НЕ ЗНАЕТ, сколько байт будет в посылке. Поэтому он ждет таймаута, после чего накопленные данные сбрасывает в пакет и отправляет по TCP. Отсюда такие чудовищные задержки при передаче 10-20 байт. Если буфер наполняется, то данные отправляются сразу.
Opc-server Автор
17.12.2018 18:40А в чем вопрос то? Настройка буфера не защищает от случайных задержек в сети Ethernet, пусть даже и редких.
Borjomy
17.12.2018 18:57У вас выделенная сеть, а траффик не достигает и единиц процента от пропускной способности. Поэтому ваши задержки не случайные, а систематические. При правильно настроенных размерах буферов задержки будут определяться только скоростью передачи данных в сети RS-485 и временем ответа сервера. Если размер буфера не настроен, то добавляйте по 50 мс на каждую пару запрос-ответ. Для скорости 9600 это уже разница в 2 раза.
Opc-server Автор
18.12.2018 04:32Кстати, подскажите, где в настройках MOXA Nport можно установить размер приемного FIFO буфера?
Borjomy
18.12.2018 13:02Хм… Operating Settings/Port X/Packing Length — это размер посылки, имеет смысл выставить значение, соответствующее ответу на наиболее частый запрос.
Force Transmit — имеет смысл выставить значение в единицы мс.
Siemargl
18.12.2018 04:10Очень сомнительно выглядит идея совместить в одном флаконе OPC DA (текущие данные), OPC HDA (исторические данные), и МЭК60870 (передача по инициативе сервера, а не клиента)
Сужу только по практическому отсутствию реализаций OPC UA — даже не интересовался (было не нужно), что из этой тройки он умеет.
А еще ведь есть 60870-5-103 и 61850. Сомневаюсь, что настолько разнородные идеи можно в одну коробку.
Отдельный вопрос про OLE и Linux и SCADA и Linux. Второе еще реализуемо, но первое…
(OPC это и есть OLE 4 Process Control, кто не в курсе)Opc-server Автор
18.12.2018 04:22Где Вы в статье нашли OPC DA, OPC HDA?
> Сужу только по практическому отсутствию реализаций OPC UA
Уже есть. Поинтересуйтесть.
> А еще ведь есть 60870-5-103 и 61850. Сомневаюсь, что настолько разнородные идеи можно в одну коробку
Вы сомневаетесь, а уже есть спрос на преобразователь modbus в 61850.
OLE в Linux нет!Siemargl
18.12.2018 04:34Для работы с приборами нужно OPC DA, со счетчиками — OPC HDA. Аксиома.
>Уже есть. Поинтересуйтесть.
Есть Кепварь. Просто слишком мало есть, чтобы создать рынок
>Вы сомневаетесь, а уже есть спрос на преобразователь modbus в 61850.
очень нужен, но нужен читатель 61850 (в modbus просят из-за ограниченности какого то софта). а еще по 61850 есть управление
не уверен, что твоя схема (можно на ты в ответ), сможет читать 61850 в UA
>OLE в Linux нет!
а ОРС, которое поверх OLE, есть ????Opc-server Автор
18.12.2018 04:40> а ОРС, которое поверх OLE, есть ????
OPC UA не поверх OLE, а поверх TCP IP в рассматриваемом в статье случае. Изучайте матчасть.Siemargl
18.12.2018 05:14Так я же написал, что даже не интересовался.
Ну и OPC — оно же клиентам отдается (скадам там всяким и экселям) — и это его уникальное преимущество позиционируется, как так если в OPC UA его вдруг нету?Opc-server Автор
18.12.2018 05:27>, и как так если в OPC UA его вдруг нету?
> т.е если нету такого св-ва,
Чего нету? Того что сервер отдаёт данные клиенту?Siemargl
18.12.2018 17:52поддержки ОРС. и действительно нету, спс за ссылку.
ИМХО это никому не нужно/ на картинках из статьи — фикция, ибо СКАДЫ, поддерживающие OPC UA еще нужно поискатьOpc-server Автор
18.12.2018 18:00Поживем увидим. Что вы скажете через 10 лет?
Как вам динамика популярности trends.google.com/trends/explore?date=all&q=%2Fm%2F026g9gw ??
lingvo
18.12.2018 10:56Кстати нам тоже надо аналогичное решение, только для диспетчеризации. В данном случае шлюз должен собирать данные по CANopen, а передавать наверх в виде того, что поддерживает диспетчеризация — MODBUS TCP, OPC UA, REST итд.
Прельщает то, что такой шлюз будет работать независимо от основной системы и в случае чего ничего страшного не будет.
И думал также сделать это на том же Raspberry Pi — соответствующая плата уже есть.
Можете реализовать софтверную часть? Можно в личку.
lingvo
18.12.2018 11:01В статье, к сожалению, не рассмотрен один из серьезных аспектов в данном бизнесе — Кибербезопасность (Cybersecurity).
Вы пробовали проходить сертификацию или хотя бы что-то делать в этом направлении? Вроде у Microsofta были неплохие курсы по этому делу — Threat Attack Modelling, Password Policy, сертификаты и т.д.
Без всего этого ваш сервер будет очень опасно выпускать в открытый интернет.Opc-server Автор
18.12.2018 11:20Какой сертификат? В каком ведомстве проходить сертификацию? Поподробнее об этом.
> Без всего этого ваш сервер будет очень опасно выпускать в открытый интернет.
Я и сам против этого.lingvo
18.12.2018 12:12Это сравнительно новый вид сертификации, который еще далек от совершенства. Есть определенные стандарты, но скорей всего у нас о них ничего не известно, даже в мире в них мало кто разбирается.
Сравнительно хорошая методика раписана в 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 нужен и где это можно исследовать.
Opc-server Автор
18.12.2018 12:18Я думал про Российские стандарты… Про это не слышал.
lingvo
18.12.2018 12:22Интернет, к сожалению, не ориентируется на российские стандарты. Может про сертификацию я и загнул, но в качестве методички:
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По всему этому должно быть достаточно документации, и если это все реализовать, то можно надеяться, что ваш сервер выстоит против достаточно большого спектра атак. Но все это только надежды.
sav6622
18.12.2018 14:14К отечественным устр-вам начинают предьявлять требования сертификации во ФСТЭКе… но пока мало кто прошёл…
gvtret
18.12.2018 11:08А с каких это пор технология OPC стала вдруг протоколом? Раз. Про Modbus TCP — в пакете данных содержится поле TransactionID по которому совершенно спокойно, на стороне OPC сервера, если он грамотно спроектирован, возможно отслеживать принадлежность ответа. Этим исключается неопределенность TCP/IP против UDP, а также минимизируются задержки, если при каком то запросе данные долго не приходят. Многопоточность наше все.
Opc-server Автор
18.12.2018 11:15> А с каких это пор технология OPC стала вдруг протоколом?
В статье речь идёт об OPC UA.
Изучите мат часть ru.wikipedia.org/wiki/OPC_UA#Протоколы далее находите фразу 1. Двоичный протокол
> Про Modbus TCP — в пакете данных содержится поле TransactionID
В протоколах сэт-4 и меркурий 230 таких полей нет. Как с ними предлагаете быть?gvtret
18.12.2018 11:27Про OPC UA у меня не было ни слова.
Изучите мат часть ru.wikipedia.org/wiki/OPC_UA#Протоколы далее находите фразу 1. Двоичный протокол
Вы склонны верить всему, что в Вики написано? Это не протокол, а сериализация данных в бинарный поток, а на транспортном уровне это может быть как TCP, так и UDP. Да хоть в тот же Modbus RTU «заворачивать» можно, используя функции из пользовательского диапазона функций.Opc-server Автор
18.12.2018 11:32> Вы склонны верить всему, что в Вики написано?
То есть вы предлагаете поверить Вам на слово?
Чем сериализация данных в бинарный поток отличается от протокола?
gvtret
18.12.2018 11:14Не помню как с остальными производителями ПЛК, но у Schneider Electric в линейке Quantum давно присутствуют Ethernet модули с собственным Web сервером, на котором никто не мешает поднять, например, на Jave OPC UA шлюз (Modbus TCP идет из «коробки»). И не надо никаких лишних шлюзов. А если система распределенная, так там уже само собой надо ставить сервер ввода/вывода, который и будет являться шлюзом данных. ИМХО.
Opc-server Автор
18.12.2018 11:21Schneider Electric поддерживает протокол какого-нибудь меркурия 230, если мне это вдруг понадобится?
Siemargl
18.12.2018 17:50квантум стоит как автомобиль (реально).
да и свободно-программируемый модулей связи я не наблюдал. можно партномер?
sav6622
А как вы на «raspberry pi» добиваетесь промышленной устойчивости к внешним факторам? Пыль, ЭМС…
Opc-server Автор
Не «raspberry pi», а «raspberry pi совместимые». Есть специальные платы с расширенным диапазоном температур.
sav6622
Вопрос был не только про температуру. Про какие платы речь, ссылку плиз или название.
Opc-server Автор
beagleboard.org/arrowbbbi
www.moxa.ru/shop/comp/risc
sav6622
Спасибо. Моха, да, согласено. А beagleboard, хоть и industrial — весьма спорный вариант (корпус, сертификация, самодельный велосипед получается).
ser-mk
и какие у моха можно отнести к «raspberry pi совместимые»?
sav6622
а beagleboard? я так понимаю, у автора всё что маленькое, то «raspberry pi совместимые»
Opc-server Автор
Компьютеры с архитектурой ARMv7.
Opc-server Автор
Бинарники, запускающиеся на raspberry pi ARMv7, запускаются и там.
lingvo
В семье Распберри есть вполне промышленный модуль Raspberry Pi Compute Module 3
Для него есть вполне индустриальные платы и корпуса, типа Revolution Pi и прочее.
sav6622
Посмотрел — там от промышленного, если только то, что он модуль, а не торчащая во все стороны разьемами плата. Называть модуль промышленным изделием, даже не имея индустриального диапазона, как то странно.
lingvo
Уточняю, если не понятно: этот модуль предназначен для встраивания в промышленные изделия. Тем параметрам, которые от него зависят, он отвечает в полной мере — например имеет индустриальный диапазон температур. А соответствие остальным требованиям уже должно обеспечиваться самим изделием — защита от радиопомех, пыли и т.д. — соответствующим корпусом, I/O — схемами защиты на материнской плате и т.д.
Также замечу немаловажный для промышленности фактор — доступность. Данные модули будут гарантированно производиться как минимум до 2023 года. Кто вложился в разработку своей платы, тот поймет.
Как выглядит в реале промышленный Raspberry Pi на базе этого модуля, можно посмотреть тут.
Вообще даже обычный Raspberry Pi можно довести до вполне "промышленного" уровня, засунув его в металлический заземляемый корпус, в качестве блока питания взяв не китайскую фигню, а что-то более подходящее из индустриальной автоматизации, и подключив его к тому же свитчу Moxа коротким кабелем. И естественно никаких других подключений к периферии самой платы. Тогда по ЭМС он выдержит практически все, и только по температуре и влажности будет похуже.
sav6622
А устойчивость к вибрации как он обеспечивает? за счет корпуса?
Доступность до 2023 года почти ниочём для промышленных изделий, к нам требование, к примеру, 20 лет. И поставка запасных частей в любое время этого срока в течение 3-6 месяцев после заказа.
Засунутая малинка в корпус металлический, весьма вероятно пройдет по ЭМСу по питанию, но скорее всего не пройдёт наведенное на нее поле — разьемы то присутствуют.
ser-mk
Там для разъемов которые наружу, отдельная плата идет, так что можно скорее достичь защиты.
Но вот вибрация и температура, это под большим вопросом.
lingvo
Вы проходили испытания на вибрацию? Я проходил и если на плате нету особо тяжелых компонентов, типа электролитов (а на CM их нету), они проходятся на ура. DIMM разъемы в промышленном оборудовании используются.
Ну и кстати за счет корпуса — а почему бы и нет? Прикрутить все это дело через резинки — и ее в космос можно будет запускать.
Ваши требования производителям микропроцессоров пофиг. Найдите хоть один микрокомпьютер, который будет гарантированно доступен так долго. Подсказка — у Intel на встроенные процессоры гарантия доступности всего 7 лет и потом переходите на другую железяку. Не стоит это путать с готовыми промышленными изделиями — вы можете абстрагировать свое железо как хотите и через 20 лет эмулировать своим клиентам 8-и битную железяку с 10кБ памяти, хотя по настоящему у вас там будет стоять уже 3-я ревизия 32-х битного ARMа.
Но это не отменяет того факта, что когда вами используемый ARM перестанут производить — а это произойдет гораздо раньше назначенного срока в 20 лет, вам придется перелазить на что-то следующее, переразводить плату, опять проводить типовые испытания — а это деньги.
Чего? Что это за испытание такое?
ser-mk
А можно пруф где сказано что он удовлетворяет хотя бы температурам. На сайте не нашел подтверждения этому.
lingvo
Ну блин, хоть гуглить не ленитесь.
https://www.raspberrypi.org/documentation/hardware/computemodule/datasheets/rpi_DATA_CM_1p0.pdf
ser-mk
Попутал, на самом деле я спрашивал про Revolution Pi, у которого заявлено
И это при том что для модуля нижняя -25 °C
но и сам модуль по верхней границе в +85 °C не влезает, не говоря уже о каком-то запасе.