Есть такой не очень корректный термин: PC based industrial automation. Я думаю, что он не совсем точен, так как никто, конечно, не подсоединяет станок к обычному персональному компьютеру. А то вдруг зависнет, и станок отрежет что-нибудь ненужное. Но рациональное зерно в этом термине есть — уже много лет среди управляющих устройств промышленной автоматизации встречаются устройства, напоминающие ПК.
Напоминающие, конечно, не внешне.
Как и в вашем ноутбуке, в контроллере может стоять процессор Core i5, обыкновенная DRAM (только обычно с ECC), SSD диск, обычный Ethernet. Процесс загрузки тоже не отличается — BIOS загружает операционку. Как правило, операционка — RTOS. Однако иногда бывает даже Windows. Причем не всегда это Windows Embedded Compact (бывшая CE). Используется даже Windows Embedded 7, а это полноценная семерка. (Линуксы тоже встречаются)
Основные классы вычислительных задач, решаемых в процессе работы производственной линии — CNC и SCADA.
В случае с CAD и SCADA вопросы, необходима ли производительность x86, и достаточно ли это надежная платформа, давно уже не стоят.
С CNC все немного сложнее. Для управления многими промышленными девайсами не нужна мощная числодробилка, зато требования к надежности и гарантированного времени отклика могут превышать возможности x86. Достаточно микроконтроллера или простейшего PLC.
Для программирования CNC обычно используется G-code, вычислительная мощь x86 для него не требуется. Если станок более сложный, используется PLC. Как программируется PLC? Есть стандарт IEC61131-3. Он определяет способы программирования: «типа ассемблер» IL, а также графические диаграммы на базе сетей Петри, блок схем или релейной логики.
Конечно, на релейной логике, асме или сетях Петри очень трудно написать настолько сложную программу, чтобы для ее исполнения не хватало вычислительной мощи микроконтроллера. Но тут на помощь приходит паскаль! еще одно представление PLC кода, определенное в IEC61131-3.
Вот как выглядит код на этом малоизвестном языке:
VAR
arr1 : ARRAY [1..3,1..3] OF REAL;
arr2 : ARRAY [1..3,1..3] OF REAL;
arr3 : ARRAY [1..3,1..3] OF REAL;
i: INT;
j: INT;
k: INT;
END_VAR
FOR i := 1 TO 3 DO
FOR j := 1 TO 3 DO
arr3[i,j] := 0.0;
FOR k :=1 TO 3 DO
arr3[i,j] := arr3[i,j] + arr1[i,k]*arr2[k,j];
END_FOR
END_FOR
END_FOR
Ничего не напоминает? Я еще на уроках информатики в школе, 20 лет назад, заметил, что если программиста вооружить паскалем и структурным программированием, то скорость процессора слишком большой не бывает.
В некоторых случаях чем быстрее процессор PLC, тем лучше: бывают приложения, где результаты измерений с десятков сенсоров используются как входные данные для достаточно сложного вычисления, причем данные приходят с частотой десятки килогерц. То есть за десятки микросекунд их надо принять, прогнать через сложный алгоритм с плавающей точкой, и отдать команды. Здесь может справиться только x86 процессор последнего поколения с кучей гигафлопсов внутрé.
Кроме того, бывает удобно, если HMI (то есть GUI в переводе на общеайтишный) будет крутиться на той же железке, что и программа PLC. Ну а раз уж начали такой workload consolidation, пусть и коммуникации по fieldbus тоже управляются этой же железкой, чего уж там! Благо ядер сейчас в одном процессоре бывает много, создавать многопоточные приложения реального времени сложно, и виртуализация обеспечивает хорошую изоляцию (если не забывать о нюансах, связанных с общим кэшем и контроллером памяти)
В прошлом абзаце я употребил новое слово — fieldbus. Эволюция производственных систем передачи данных — тоже хороший пример того, как технологии родом из IT вытесняют специализированных динозавров. Современные fieldbus сети Profinet, Ethercat, Sercos III базируются на Ethernet, и работают с обычными сетевыми карточками производства Intel и, наверное, других вендоров.
Что же мешает полному переходу на x86? Осторожные законодатели боятся взрыва АЭС от блюскрина требуют, чтобы в особенно важных местах PLC соответствовали определенным стандартам безопасности. Операционки, соответствующие этим стандартам есть — например, VxWorks, QNX, etc. Даже есть виртуальная машина — Windriver Hypervisor тоже сертифицированная SIL3/SIL4.
Вопрос в сертификации железа. Конечно, соответствующий сертификат проще получить на простой микроконтроллер, который производится в неизменном виде годами, чем на сложный x86 процессор и чипсет, поколения которых меняются каждый год. Но это не мешает процессорам Intel применяться во многих популярных PLC разных производителей.
А как же real time? Нам нужен hard real time, soft real time не пойдет вот почему: даже если в 99.99999% случаев мы укладываемся в deadline, оставшиеся 0.00001% могут привести к сбою в среднем несколько раз в день. Конечно, у нас на этот случай должна быть safety function, которая все обесточит, но делать это часто как-то не весело. Я много раз слышал мнение, что сложный OOO процессор и Real Time — понятия несовместимые. Ведь у микроконтроллера можно посмотреть на код, и с точностью до такта знать, сколько времени займет его исполнение.
Так? Так, да не так. Следите за руками! Например, пусть у нас цикл 100 микросекунд. Пусть он начинается с прерывания. До обработчика прерывания управление может дойти через 2, а может (в худшем случае) через 8 микросекунд. Пусть еще 10-15 микросекунд потратим на чтение полученной информации. И потом еще 50-75 микросекунд будем ее обрабатывать (у нас ведь жутко непредсказуемый суперскалярный процессор с еще более непредсказуемым кэшем!). Итого потратим от 62 до 98 микросекунд. Ужасный jitter; жуткий, не приспособленный для hard real time x86! Но в худшем случае (который встречается один раз за несколько часов работы с частотой 10 килогерц), все равно убираемся в 100 микросекунд.
Но что такое 50 микросекунд обработки полученных данных на core i3? Это 100000 тактов, или около 120000 инструкций при совсем не выдающемся IPC=1.2. Пусть у нас еще и не очень эффективный PLC компилятор, который на каждую инструкцию IL генерит в среднем 5 инструкций x86. То есть за цикл мы выполнили 24000 инструкций IEC61131-3 IL.
А если представить то же самое на очень шустром, но не x86 PLC? Никакого jitter'a на прерывание и при чтении данных, и можно заранее точно сказать, сколько времени займет исполнение 24000 инструкций IL. Посмотрим в документацию производителя PLC из большой тройки (A-B, Siemens, Mitsubishi automation). Сколько времени исполняется одна инструкция IL? 9.5 наносекунд. 24000 инструкций выполнятся за 228 микросекунд. Ч.т.д.
Если мне возразят, что 24000 инструкций обработки за цикл — это слишком много, то я отвечу:
Ты за меня, или за медведя?. Клиенты рассказывали о современных станках, контроллер которых каждый цикл обсчитывает физическую модель десятков актуаторов, основываясь на показаниях десятков сенсоров. То есть занимается численным решением системы уравнений каждый такт, что требует больше и больше FP производительности.
Все вышеупомянутое относилось к производительности одного ядра. Но у нас-то их теперь много. И мы можем их использовать для консолидации нескольких функций или PLC на одном устройстве, либо для распараллеливания управляющей программы. Последние версии RTOS типа VxWorks, Twincat и т.д. сохраняют hard real time гарантии при поддержке многопоточности. Но это на уровне ядра ОС, гипервизора и библиотек. А на уровне приложения, пользуясь обычными примитивами межъядерной синхронизации сломать real time очень легко. К сожалению, общий рецепт борьбы с этой проблемой мне неизвестен.
Выше я написал, что в отрасли становится популярным многопоточное программирование и использование виртуализации. То есть существует отставание от IT лет так в несколько. Может быть, еще через несколько лет начнут внедрять что-то вроде private cloud? И тогда помимо Stuxnet, о котором все слышали, но никто не видел, придется бороться со зловредами, способными ломать промышленных роботов, и заставлять автоматизированные химические производства синтезировать интересные вещества вместо нужных?
Автор: izard
