Real-time и не-real-time - в одном флаконе или раздельно? Опции

[syoma]

Привет. Собственно вопрос из области начинающих по архитектуре процессорной системы. Делаем новый проект и возник вопрос.
С одной стороны есть программа, работающая в жестком реальном времени с коммуникацией, через CAN, SPI и RS485. Это основная функция системы.
С другой стороны есть куча других интерфейсов - SD card, Ethernet, USB и прочих, которые служат для вспомогательных функций - записи логов, параметрирования, обновления ПО, удаленного доступа через WEB и bluetooth, терминалки и т.д.

Если все это реализовывать на одном процессоре, то получается, что надо использовать RTOS, что требует определенных программистских навыков и не нравится то, что это уменьшает защиту системы от внешних хакерских атак. Если из-за Ethernetа зависнет основная программа - это будет очень-очень плохо. Т.е. в результате увеличиваем затраты на разработку, делаем сложную программу, но уменьшаем стоимость железа.
Поэтому у меня настрой такой, что основной процессор должен выполнять только основную real-time программу и все. При этом ему не нужна операционная система вообще, так как нужные интерфейсы реализуются как функции ввода/вывода - это уже реализовано и проверено.
А для всего остального поставить отдельный процессор или даже платку, на которой будет крутиться обыкновенный Linux со всеми нужными драйверами. И с основным процессором эта плата будет общаться только через CAN. В этом случае практически все функции будут уже реализованы в самом ядре и программисту надо будет сделать очень мало и хоть на питоне или джаве. То есть затраты на разработку будут гораздо меньше, имеем барьер от хакерских атак - если этот процессор зависнет, система будет прекрасно работать дальше, но увеличиваем стоимость железа.

Как думаете это нормальный подход сегодня?

[Kabdim]

А RTOS у которой в кач-ве guestOS крутится тот же linux чем не нравится? Ну или SoC которые и так совмещают процы A и М серии.

[k155la3]

В промышленных контроллерах (PLC) практикуется "разнесение" функций собственно контроллера и
"вспомогательных" функций-процессов на сопроцессоры. По крайней мере, так было лет 10-20 назад.
Собственно PLC обеспечивал реалтайм логику и основные коммуникации, тоже в рамках реалтайм.
Вспомогательные функции выносились в специализированные модули - коммуникационные процессоры, функциональные модули
(например "быстрые" счетчики для энкодеров), панели операторов итд.
Это на мой взгляд сделано для обеспечения надежности. (завес коммуникационного процессора не выводит из работы
собственно PLC, тк это может очень дорого стоить)
Еслиб бы Ваша система "набиралась" из модулей пром. PLC:
- Процессорный блок с RS485, CAN
- Коммуникационный (со) процессор - SD card, Ethernet, USB, HMI
"общение" - по SPI с использованием линий апп. прерываний в обе стороны.

[syoma]

У нас как раз почти-промышленный контроллер - логика управляет достаточно ответственным оборудованием, поэтому зависание может привести к серьезным поломкам.

А RTOS у которой в кач-ве guestOS крутится тот же linux чем не нравится?

Не нравится стоимостью затрат на реализацию, когда с точки зрения преимуществ дает мало.

[AlexandrY]

Собственно PLC обеспечивал реалтайм логику и основные коммуникации, тоже в рамках реалтайм.

Да будет вам известно, что PLC никакой риалтайм не обеспечивают.
Там всегда есть такое окошко с показателем нагрузки процессора,
и если вы не следите за ним в ручном режиме и сами не спланировали задачи как надо, то рухнет весь этот риалтайм.
Более того, если на своей платформе вы можете прицизионно профайлить, то на PLC вам это не удастся.

У PLC есть одна только важнейшая черта - быть масштабируемыми.

[syoma]

Ну вот с другой сторону смотрю на системы типа TwinCAT и Codesys, которые стоят не в одном десятке мировых промышленных ПЛК. И получается, что там все в одном флаконе крутится - и реалтайм и всякие Скады с Веб-визуализациями. Но там народ, наверное годами софт отлаживал, а у меня столько времени нет. А за портирование того же CodeSys рантайм просят 15кевро + лицензия за каждый девайс.

[Lagman]

что там все в одном флаконе крутится - и реалтайм и всякие Скады с Веб-визуализациями.

Вы смешали две сущности, реалтайм и скаду. Скада в основном это отображение, сбор, обработка и хранение информации ну и иногда управление и это верхний уровень (хотя это тоже под вопросом, т.к. если вы занимаетесь бизнес процессами то скада это нижний уровень) для автоматизации технологического процесса, а вот PLC считается нижним но и тут реалтайм очень ограниченный, так как любой PLC имеет ограничение на количество точек и частоту опроса точки, но хорошо работает с верхним уровнем, почти в реалтайме.

[AlexandrY]

Но там народ, наверное годами софт отлаживал, а у меня столько времени нет. А за портирование того же CodeSys рантайм просят 15кевро + лицензия за каждый девайс.

Если 15кевро, то значит портирование плевое дело, на месяц работы.
Вы как будто не в Европе живете.

[syoma]

Если 15кевро, то значит портирование плевое дело, на месяц работы.
Вы как будто не в Европе живете.

Сорри, неправильно сказал - 15к - это за тулкит - лицензию и исходники с библиотеками. Портирование сюда не входит.

[k155la3]

Да будет вам известно, что PLC никакой риалтайм не обеспечивают.
. . .

Если под реалтаймом, в данном случае подразумевать, что входной сигнал/состояние на "входе" системы
будет принят-зафиксирован-обработан, и выдан управляющий сигнал - в течение определенного времени,
то, естественно, обеспечивает. Время порядка единиц-десятков мс.
А как иначе ? На входах сложилась аварийная комбинация сигналов, надо выдать сигнал на отключение,
а на оп. панели нарисованы "часики" ? (я понимаю, что аварийные цепи-защиты делаются аппаратно).

[AlexandrY]

А как иначе ? На входах сложилась аварийная комбинация сигналов, надо выдать сигнал на отключение,
а на оп. панели нарисованы "часики" ? (я понимаю, что аварийные цепи-защиты делаются аппаратно).

Обслуживание цепей безопасности делают также программно как всю остальную часть.
И сигналы об этих цепях гуляют по тому же CAN-у или EtherCat-у где и обычные пакеты.
Просто программу обслуживающую цепи безопасности вы обязаны показать надзорному органу, он ее должен изучить в исходниках и дать сертификат на применение.
На структуру и нотацию этих программ наложены жесткие ограничения.
Вот так и решается вопрос.
PLC явно не та облать где можно разгуляться с инновациями. Я б на них не ровнялся.

[k155la3]

. . .
Просто программу обслуживающую цепи безопасности вы обязаны показать надзорному органу, он ее должен изучить в исходниках и дать сертификат на применение.
На структуру и нотацию этих программ наложены жесткие ограничения.
. . .

Ok.

[syoma]

Обслуживание цепей безопасности делают также программно как всю остальную часть.
И сигналы об этих цепях гуляют по тому же CAN-у или EtherCat-у где и обычные пакеты.
Просто программу обслуживающую цепи безопасности вы обязаны показать надзорному органу, он ее должен изучить в исходниках и дать сертификат на применение.
На структуру и нотацию этих программ наложены жесткие ограничения.
Вот так и решается вопрос.

Ну, скажем так, не везде. У нас в отрасли цепи безопасности требуются еще аппаратные. Но это не отменяет того факта, что контроллер, помимо обеспечения правильности функционирования объекта, также отвечает за защиту оборудования от нештатных ситуаций на более высоком уровне - комбинаций различных условий и состояний объекта, которые уже цепями безопасности не отработаешь, а только на алгоритмическом уровне. Реал-тайм в данном случае означает, что программа в этом контроллере должна вызываться с определенным временным интервалом, который гораздо меньше, чем необходимый для безопасной и правильной работы оборудования и что программный цикл должен всегда выполняться быстрее этого интервала. В противном случае срабатывает ватчдог и контроллер вылетает в безопасное состояние с соответствующим приведением в безопасное состояние всего объекта. В нашей системе программный цикл должен быть в пределах 5мс, в идеале 2мс. ПЛК, кстати на интервалах от 10мс тоже прекрасно справляются с этой задачей, обеспечивая реал-тайм.

Но тема не об этом, а о том, почему стоит комбинировать такой реал-тайм с функциями, которые его не требуют в одном процессоре и какой бенефит это обеспечивает, кроме как удешевления железа. Или стоит ли, наоборот, разделить эти части на разные аппаратные платформы. Какие тренды?

[AlexandrY]

Но тема не об этом, а о том, почему стоит комбинировать такой реал-тайм с функциями, которые его не требуют в одном процессоре и какой бенефит это обеспечивает, кроме как удешевления железа. Или стоит ли, наоборот, разделить эти части на разные аппаратные платформы. Какие тренды?

Не все так просто. Сколько микроконтроллеров будет применено решает софт, расстояния и гальванические барьеры.

[k155la3]

. . .
Но тема не об этом, а о том, почему стоит комбинировать такой реал-тайм с функциями, которые его не требуют в одном процессоре и какой бенефит это обеспечивает, кроме как удешевления железа. Или стоит ли, наоборот, разделить эти части на разные аппаратные платформы. Какие тренды?

извиняюсь что влез.
Вы правы - насчет удешевления. Если девайс тиражирутся тысячами, то экономия 2-3-5 $ абсолютно оправдана, и впихивание "всего"
в один чип имеет смысл. Если... Если есть гарантированная возможность обеспечить правильность и надежность этого "все в одном".
Это подразумевает или использование готовых (сделанных кем-то) решений, наподобие Codesys, или - серьезные затраты времени
на разработку и тестирование этого монстра. Сразу возникет вопрос об RTOS. Комммерческая (дорого) или Free ?
А есть ли все необходимые драйверные модули для процессорной и внешней периферии ? итд.
И самое главное, сколько людей и какой квалификации должны все это разработать и оттестировать.
Получается большой черный ящик, с массой входов и выходов, работающий (декларирутеся) в реалтайм и надежно (декларируется).
---
Для малых тиражей имеет смысл разделить большой ЧЯ (однопроцессорный) на два:
- ЧЯ1/реалтайм/высокая-надежность и
- ЧЯ2/реалтайм-не-очень/средняя надежность (не очень ответственные процессы).
Тогда разработку и отладку-тестирование этих двух девайсом можно разделить и соотв-но упростить, что повысит надежность каждого. На завершающем этапе - обЪединить эти 2 процессора (каждый из которых уже отлажен), что уже не будет так сложно.
----
IMHO, аднака

ps
--> TS
А какая платформа HW, если не секрет, и какие RTOS рассматриваете ?