|
Written on: 08. 02. 2013 [04:17]
|
|
pentagon128
Руслан Кучерявый
Topic creator
registered since: 15.11.2011
Posts: 102
|
Добрый день! Потихоньку тему копаю с SUSE Linux Enterprise Real Time (производства Novell, https://www.suse.com/products/realtime). Это расширение ядра линукса на основе Suse SLES_v11_SP2 (ставиться поверх него) которое позволяет исполнять критичные приложения в режиме реального времени. Распространяется открыто. В руководстве написано - для критичных серверов и приложений собирающих данные. Подписка на обновления с репозиториев платная. Судя по руководству пользователя (прилагается) содержит 2 основных версии kernel до 4 Гб и свыше 4 Гб. На каждое ядро 3 разновидности. Рабочая, Trace, Debug. Рабочая-для исполнения готового проекта. Trace-для отладки приложений и замеров цикла выполнения, Debug-тоже что и Trace только заточена под написание драйверов которые будут исполняться в системе Realtime. Позволяет запускать приложение на "защищённых" (shielded) процессорах в многопроцессорных системах (обработка прерываний сдвинута на другие свободные процессоры). Согласно различным НТД требования на реакцию системы где есть ПАЗ (противоаварийная защита) начинаются от 200 мс и жёстче. Причём это касается не только контроллера но и АРМ оператора. Следовательно в случае наличия ПАЗ крайне желательно ставить АРМ оператора на Realtime систему. Соответственно система должна быть отлажена на конкретном железе (тайминги замерены, драйверы только необходимые, ничего лишнего). В теории Open Scada под данной Real Time ОС должна работать. Вот и думаю-пробовать ставить на виртуальную машину вначале всё это "хозяйство"(что вобщето не есть хорошо - надо ставить на конкретную железяку), или дождаться конкретного проекта. Кто что думает по этому поводу? Может уже пробовали с SUSE Linux Enterprise Real Time (производства Novell)? Стоит ли заморачиваться? Пока и на Open Suse неплохо работает Open Scada.
Attachment
|
|
Written on: 08. 02. 2013 [11:43]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"pentagon128" wrote:
Потихоньку тему копаю с SUSE Linux Enterprise Real Time (производства Novell, https://www.suse.com/products/realtime). Это расширение ядра линукса на основе Suse SLES_v11_SP2 (ставиться поверх него) которое позволяет исполнять критичные приложения в режиме реального времени. Распространяется открыто.
Это скорее всего известный xenomai(RT) патч к ядру Linux, сборки ядер с которым часто доступны и в других дистрибутивах.
"pentagon128" wrote:
Согласно различным НТД требования на реакцию системы где есть ПАЗ (противоаварийная защита) начинаются от 200 мс и жёстче. Причём это касается не только контроллера но и АРМ оператора.
Нигде не видел таких требований на АРМ, если он конечно по совместительству не выполняет функцию ПЛК, например, сенсорные панели. Что касается 200мс, то это требование даже самое захудалое ядро Linux в обычном режиме планирования обеспечивает. В родном режиме же реального времени современные Linux-ядра обеспечивают устойчивую периодичность обработки 200 микросекунд, естественно с "preempt" патчами и без управления частотой процессора, например, мой тест (1000 выборок) на ноутбуке показывает:
Precission 0.064423 ms; max 0.161893
В случае xenomai(RT) патчей можно добиться и меньшего времени, правда в их собственном планировщике, располагающемся над стандартным планировщиком Linux, для чего нужно и их библиотеку использовать.
"pentagon128" wrote:
В теории Open Scada под данной Real Time ОС должна работать. Вот и думаю-пробовать ставить на виртуальную машину вначале всё это "хозяйство"(что вобщето не есть хорошо - надо ставить на конкретную железяку), или дождаться конкретного проекта. Кто что думает по этому поводу? Может уже пробовали с SUSE Linux Enterprise Real Time (производства Novell)? Стоит ли заморачиваться?
Не должна работать, а давно и неоднократно использовалась, например:
- на ПЛК LP-8781, где родное окружение в лучшем случае 10 мс обеспечивало, а ядро 2.6.29-rt обеспечило устойчивую периодичность 200 микросекунд для задачи прямого опроса АЦП на частоте 5КГц, с последующим анализом спектра сигнала: http://wiki.oscada.org/Using/LP8x81 . Причём высокоприоритетный планировщик xenomai для этого не использовался.
- на Segnetics SMH2Gi, где тоже ядро 2.6.29-rt, но на ARM-процессоре, в рамках проекта http://wiki.oscada.org/Using/VacuumProcUnit
Работа под виртуальной машиной всякий РеалТайм нивелирует полностью!
Вложил файл теста разрешения счётчика реального времени и равномерности периодичности задач реального времени. Можете поиграться и оценить на различном железе и ядрах. Политики реального времени в ядре Linux доступны только привелигерованному пользователю, поэтому запускать нужно от "root" или установить такие права нужному пользователю. Этот тест встроен и в OpenSCADA, в виде значения "Отстав." на вкладке "Задачи" (http://wiki.oscada.org/Doc/OpisanieProgrammy/part4/files?get=sys_tasks.png).
Learn, learn and learn better than work, work and work.
Attachment
|
|
Written on: 09. 02. 2013 [15:29]
|
|
pentagon128
Руслан Кучерявый
Topic creator
registered since: 15.11.2011
Posts: 102
|
Спасибо Роман за информацию :D. Приложил файл типовых требований РД, взят из описания ПТК Саргон. Информация в них возможно устарела. Есть последние РД и ГОСТы где данные требования изложены, пока просто нет необходимости их копать. В конечном итоге Заказчик выбирает. Обратите внимание - для энергоблока время задержки отражения аварийного дискретного сигнала на АРМе=50...250 миллисекунд.
[This article was edited 1 times, at last 09.02.2013 at 15:45.]
Attachment
|
|
Written on: 11. 02. 2013 [12:38]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"pentagon128" wrote:
Обратите внимание - для энергоблока время задержки отражения аварийного дискретного сигнала на АРМе=50...250 миллисекунд.
OK. Периодичность обновления интерфейса оператора (не Web) в OpenSCADA по умолчанию установлена в 100мс и это нормально работает на любом ядре Linux.
Увидел странный пункт "Минимальный период опроса" в приложенном документе, поскольку оценка периодичности опроса по минимальному периоду особого смысла не имеет, а вот по максимальному периоду смысл имеется, для оценки гарантированной периодичности получения данных.
Learn, learn and learn better than work, work and work.
|
|
Written on: 21. 02. 2013 [16:11]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"roman" wrote:
Вложил файл теста разрешения счётчика реального времени и равномерности периодичности задач реального времени. Можете поиграться и оценить на различном железе и ядрах. Политики реального времени в ядре Linux доступны только привелигерованному пользователю, поэтому запускать нужно от "root" или установить такие права нужному пользователю. Этот тест встроен и в OpenSCADA, в виде значения "Отстав." на вкладке "Задачи" ( http://wiki.oscada.org/Doc/OpisanieProgrammy/part4/files?get=sys_tasks.png).
Ещё есть специализированный тест Cyclictest.
Learn, learn and learn better than work, work and work.
|
