1 октября 2012 в 14:48

x86 на производстве: high end промышленные контроллеры, Паскаль и вирусы

Есть такой не очень корректный термин: PC based industrial automation. Я думаю, что он не совсем точен, так как никто, конечно, не подсоединяет станок к обычному персональному компьютеру. А то вдруг зависнет, и станок отрежет что-нибудь ненужное. Но рациональное зерно в этом термине есть — уже много лет среди управляющих устройств промышленной автоматизации встречаются устройства, напоминающие ПК.

Simatic S7Напоминающие, конечно, не внешне.

Как и в вашем ноутбуке, в контроллере может стоять процессор 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..4,1..4] OF REAL; 
                arr2 : ARRAY [1..4,1..4] OF REAL;
                arr3 : ARRAY [1..4,1..4] OF REAL;
                i: INT;
                j: INT;
                k: INT;
END_VAR
FOR i := 1 TO 4 DO
                FOR j := 1 TO 4 DO
                                arr3[i,j] := 0.0;
                                FOR k :=1 TO 4 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, о котором все слышали, но никто не видел, придется бороться со зловредами, способными ломать промышленных роботов, и заставлять автоматизированные химические производства синтезировать интересные вещества вместо нужных?
+21
11689
32
izard 28,1

комментарии (8)

+2
Lampus, #
Я вот чего понять не могу…
Раз вам надо так быстро выполнять операции с плавающей запятой, почему бы под это дело не взять один из современных DSP или, скажем, не сделать специализированную железяку на FPGA заточенную под конкретно данную задачу?
На специализированной железке можно добиться гораздо большей производительности и гораздо более предсказуемого времени выполнения операции, нежели на x86_{32,64}. Если нужен RTOS и GUI рисовать, то берёте любой понравившийся (и достаточноый по производительности для данной задачи) eMPU и цепляете к нему разработанную числодробилку на DSP или FPGA — это просто, понятно и даёт предсказуемые задержки.
+2
izard, #
DSP и FPGA серьезно проигрывают и x86 PLC, и обычным PLC в гибкости — стоимости изменения программы.
+4
AbnormalHead, #
Дык это уже есть у Intel — зовется Atom E6x5C
+2
izard, #
izard> Получил личный коммент от muzzy0.livejournal.com. Это инженер, который занимается пром
izard> автоматизацией. У него нет аккаунта на хабре.

muzzy0>
1. Пример с тремя вложенными циклами — просто отличный. Его должны показывать на первом уроке курса по structured text — как пример «как нельзя программировать ПЛК» :)

Подобных дел можно и в instruction list наворотить, но несколько сложнее.

Это было одной из первых любопытных вещей, с которой я столкнулся, когда столкнулся с программированием контроллеров. Не надо тащить на ПЛК десктопные привычки :))

У тебя и так программа в цикле крутится, так зачем запихивать такой здоровый цикл в один проход главного цикла? Напиши свою программу так, чтоб за один проход главного цикла у тебя выполнялся один (ну или не один, а в пределах разумного) проход твоего цикла — и порядок :)

А насчёт сращивания контроллера и HMI — чем крупнее объект, тем физически дальше они друг от друга и тем большая вычислительная мощность им требуется. Кроме того, контроллеры могут быть дублированными (как S7-400H) и их может быть несколько. А HMI сервера достаточно одного, хоть и дублированного. Вот только стоит этот сервер в шкафу, в серверном помещении, даже без монитора, а люди сидят за клиентскими станциями, тонкими (веб) и толстыми (рантайм скады).

+2
izard, #
мой ответ:
1. Конечно! Я специально и написял, что в IL так наворотить сложно, а в structured text — запросто.
Однако приведенный код, как ни странно, «боевой». Я видел приложение, гда надо было перемножать 4x4 матрицы почти каждый цикл.

2. Сращивание HMI и контроллера конечно удобный пример для Интел, но действительно часто не полезно для крупного объекта. Хотя бывает и наоборот: на конвейейре фабрики бмв видел HMI у каждого робота отдельно, в нем видно пошаговое исполнение structure text, и еще в операторском помещении все дублируется.
+1
N1ghtroad, #
Ну, на самом деле подключают ПК к станкам. В бюджетных решениях.
Как пример, могу упомянуть комплекс Simple Cutter, выросший из моего дипломного проекта.
Всё управление процессом берет на себя обычный PC под управлением Windows. Не самый оптимальный подход, конечно, но тем не менее клиенты рады, и продано уже более 50 станков за два с небольшим года (при этом упираемся не в количество заказов, а в скорость производства и сборки).
Если интересно — могу попробовать наваять статью о том, как я до такого докатился и какие подводные камни собрал по дороге.
0
izard, #
Нашел Simple Cutter — станок плазменной резки. Ваш продукт?

Какое время реакции необходимов вашем приложении?

Я как сотрудник Интел очень даже люблю PC. Но в европе может быть сложно с сертификацией. Хотя если приспособить сбоку отдельную safety железку, может быть прокатит.

Удачи вам, Beckhoff тоже начинал с обычных PC.
0
N1ghtroad, #
Да, да, он самый.
Время реакции — не совсем подходящий параметр для него. Т.к. реагировать, по-сути, не на что. Обратная связь минимальна, а сам станок, в случае потери управления, замирает и гасит плазму.
Управляющие сигналы отсылаются с частотой 800-1500Гц в зависимости от скорости резака. И вот тут уже нужна достаточно высокая стабильность. Впрочем, её обеспечивает даже обычная WinXP на простенькой современной машине, если параллельно производству не играть в игрушки.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.