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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ok.

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

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

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

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

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

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


Если делать раздельно,то STM32F4 для реалтаймовой части, а для не-реалтаймовой в принципе пофиг, лишь бы вся нужная периферия поддерживалась из Линукса, да модуль/чип подходил для промышленных применений и стоил баксов до 30.
RTOS - только freeware.

У FreeRTOS есть порт под STM32F407. Это если ось потребуется.
Есть еще интересная весч ptotothreads (мне на форуме тут как-то рекомендовали. author Adam Dunkels <adam@sics.se>).
По сути это оболочка для while(1) { }.

Я не так строю систему.
Да, Ethernet представляет некоторую опасность. Поскольку он будет подвергаться постоянному флуду.
Но с тем же успехом флуду подвержен и CAN и RS485 при сбоях оборудования.
Все сетевые стеки должны выбирать между быстродействием и защищенностью.

Но Ethernet одновременно и скоростной протокол, быстрее USB в микроконтроллерной реализации. Если его отделить от CAN-а c RS485, то сразу теряете много возможностей отладки этих самых CAN и RS485.
А в быстрых проектах гибкая и мощная отладка является самой важной.
Доморощенный межпроцессорный протокол по UART-у не спасет, либо выльется еще в больший челендж чем защита Ethernet-а от флуда.
Поэтому однозначно Ethernet у меня стоит на одном борту с CAN и прочими полевыми шинами.
К тому же сам стек TCP с Ethernet в исходных кодах и отладка и поиск ошибок в нем не составляет никаких проблем.
USB проблем не вызывает, там в шине всегда чисто и бояться нечего.
Другое дело Wi-Fi или BLE. Они открыты всем и всегда для флуда и их стеки не даются в исходниках. Вот для них я ставлю отдельные чипы, и связываю по SPI.
Отдельным внешним микроконтроллером можно делать только очень примитивные функции вроде оцифровки, предобработки, фильтрации, генерации сигналов.
Т.е. все то что действительно можно запустить практически без отладки или полностью отсимулировать в MATLAB-е.

Естественно все это относится только к развитым RTOS: Micrium 5, MQX, embOS, Nucleus Plus...
Если иметь в виду FreeRTOS то все будет печальней.
Тогда уже лучше Mbed OS. Там хотя бы есть такая экзотика как гипервизор для защищенного режима. Можно BLE ставить прямо вместе с риалтайм системой.

И что? Сделайте его неприоритетным процессом, и пусть флудит, на что он может повлиять? Что страничка откроется на неск. мсек позднее, и кому от этого хуже?

В ПЛК реалтайм есть, смотря насколько быстр он вам нужен, если надо считать импульсы с частотами в мегагерцы или микросекундные длительности, для таких задач всегда использовались сопроцессоры и спец. счетчики. Если же работа с миллисекундами или релейной логикой - то реалтайм там в полной мере представлен.

У меня сейчас тоже проблема выбора OS или вообще безосевость.
Разве что платформа определена MSP430. Это "бытность данная мне в реальность".

Собственно, если есть возможность - использовать коммерческую OS (и это намного проще-эффективнее),
как рекомендует AlexandrY, но не "в лоб", а с правильными настройками как самой оси,
так и своего разрабатываемого ПО. Тогда и возможен однопроцессорный вариант.
(предполагается, что разработчики ОС выполнили работу качественно, провели всякие сертификации, тесты итд,
и сделали процентов 80 от "проверочной" работы, которую нам надо будет проделать для free OS)
Недостаток один - ЭТО надо покупать и задорого.

С free XXXRTOS - все намного сложнее-неопределеннее, как с выбором собственно OS, так и с ее
опятьже настройкой-адаптацией, дописыванием драйверных модулей.
Достоинство - нет необходимости денежных затрат. Смотря какой вид лицензии, можно ли использовать для коммерческих целей
как встроеннное ПО.

Насчет коммерческих осей.
Сейчас на западе на это смотрят проще.
Если ваша компания зарабатывает меньше миллиона долларов в год, то дают исходники бесплатно и не цепляются если вы в ваших поделках там использете их RTOS.
Так сейчас и Micrium делает и Mentor. Мне они так предлагали. uCOS и Nucleus Plus соответсвенно.
Есть такие оси как MQX которые коммерческого уровня, но полностью открыты для использования.
Если исходники не так важны, то вон ThreadX у Renesas, тоже очень развитая ось.
Free оси плохи не тем что некачественные, а тем что скверно документированы и растащены на всякие сомнительные ветки и платформы в которых можно вечно разбираться.
Освоение free оси в разы сложнее коммерческой. Сложнее и поддержка изделий с free осями.


Реле два раза может клацнуть пока пройдет цикл в 2 мс у ПЛК.
ПЛК который всегда реагирует не раньше 1..2 мс ну никак к реальному времени отнести не могу.


В интернете не просто флудят, а DOS-ят все порты. Ваш-то HTTP сервер небось на одних memcpy да strcpy сделан. А это любимый объект атаки по переполнению.

В том-то и дело. Допустим я захочу купить эту ось. Не знаю, сколько в среднем по рынку, но я считаю что качественная ось будет стоить 10к$ за лицензию + еще 10-20$ за рантайм на каждое устройство. При моих количествах примерно 1000 изделий в год выходит, что в себестоимости изделия стоимость оси будет 20-30 баксов, так как обычно через 2 года надо покупать поддержку, которая стоит, как новая лицензия. А ведь за эти деньги уже можно купить чуть ли не компьютер на линуксе.
Так вот стоит оно того?

Это какая-то ваша внутренняя проблема. Я поднял около 5-ти комерческих осей на голых платформах. Никогда не обращался не только в их тех поддержку, но даже на их форумы.
Главное иметь исходники.

Чет не понял причем тут ддосы и копирование блока... Пускай, забьют мне весь канал по езернету, да, вебка открываться не будет, и все! Причем тут копирование? Забьют весь пул стека, ну и пусть, больше, чем нужно выделить не получится - сработает ограничение, в чем проблема - не понятно. Если вы выделяете память без ограничений - ну тогда логика тут бессильна



И что это за "реле" такое, которое за 1 мсек срабатывает SSR - так это уже не реле в классическом понимании.

Конечно, я о ней уже писал. Она называется "отсутствие квалифицированного специалиста, который способен поднять 5 коммерческих осей на голых платформах". И вторая проблема, как я уже тоже писал - одного портирования операционки мало, нужна архитектура.


Во многих системах реального времени опрос входов и выходов осуществляется с периодами и побольше этих. Естественно и реакция в худшем случае будет соответствующей. Тем не менее, это реальное время.

Вот на это и рассчитывают, купят, а потом еще разбираться с ней... А по началу представляют, что раз уж стоит столько, так все остальное в шоколаде будет



Два взаимоисключающих высказывания - т.е. у фри-осей исходников нет, или у коммерческих они какие-то особенные...
Отличие лишь в том, что там побольше их и, надеюсь, они лучше протестированы, хотя не факт.

СтОит или нет - зависит от ментальности, географического местоположения и конечной цены продукта

Для выпуска прототипа, если есть возможность, лучше взять готовое решение "по макисмуму", те это коммерческая OS
с исходником, документацией, требуемыми драйверными модулями.
После принятия прототипа "за основу" и невозможности использовать эту комм. OS -
подобрать подходящее из free и де-портировать ( ) работающий прототип "туда".

ps
Есть альтеннатива следующего вида. Решение, которое предоставляет производитель.
П.О. TexasInstriments:
Операционная система: Ti-RTOS / SYS-BIOS / MSP430 (TCP, Ethernet нет) Процессоры Ti
Процессоро-зависимый набор драйверов: DriverLib (библиотека в исходниках, встроенная периферия)
Среда разработки: Code Composer Studio (компилятор, IDE)

Шедеврально!! Т,е. заплатить кучу бабок за эту ось, вникнуть в нее, сделать проект... А потом, да ну ее нафиг, делаем на бесплатной... Один вопрос - зачем такой мазохизм???

В нормально спроектированной RTOS зависание не возможно


Понятие "реальное время" перпендикулярно тому, через сколько времени ртось среагирует на событие.

Если ртось УСПЕВАЕТ ВОВРЕМЯ среагировать и обработать евент за ДЕТЕРМИНИРОВАННОЕ время и это время устраивает заказчика, значит это ртось. Даже если время реакции сотни милисекунд

К примеру если цикл ПЛК 0.5 секунды то нафига успевать среагировать и обрабатывать евент за микросекунды?

Вы мне льстите (шедеврально). В моем посте слово "заплатить" не фигурировало.
Хотя еслиб масштаб цен позволял - покупал бы.

Многие конторы не предоставляют доступ к своему софту или докам пока не заплатишь им, конечно можно найти ломаное, но сколь не встречал, что-нибудь не хватает или недоломано



В любом нормально спроектированном софте не возможно, и это факт! Вот только вероятность сделать все правильно обратно пропорциональна сложности софта, и это тоже факт, поэтому чем проще - тем лучше, а проще без оси и динамического выделения памяти, и если задачу можно решить не прибегая к этим двум факторам - это и есть гуд

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

Тогда убойный вопрос: откуда вы знаете что ваша программа в ПЛК реагирует за детерминированное время?
В ПЛК есть только цикл и все. Вы только знаете что он выполняется за скажем 2 мс и всегда обновит выходы данными из памяти за это время.
Но будут ли валидные данные в памяти в это время?
ПЛК не гарантирует никаким образом программе выполнение за цикл.

А гарантирует профайлинг и модели планирования.
В ПЛК планирование на рудиментарном уровне, в виде нескольких параллельных задач с жестко заданными приоритетами, профайлинга нет.
Скажем вашу задачу с сотней разных соленоидов вы бы умерли делать на ПЛК.

Реальное время в современной трактовке - инструмент, а не явление. RTOS - это фреймворк, а не просто планировщик и объекты синхронизации.


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

Если сказано, что время реакции на событие должно быть 5 мсек, значит цикл ПЛК, должен быть как минимум в 2 раза быстрее, тогда все данные будут валидными. По моему все понятно

Не видно оснований для такой эвристики.

Сначала копирование строк в проге не понравилось, теперь ватчдог... Вообще-то ватчдог нужен для того, если происходит непредвиденное зависание МК в результате критических сбоев, которые вообще-то не должны происходить изрядно-регулярно. Думаете в вашей любимой MQX их не может быть в принципе?? Или веб-сервер в ней сделан как-то по-другому, без применения функций копирования массивов и строк??

Что значит "готов порвать"? Задача ватчдога как раз в том, чтобы гарантировать реальное время. Т.е. если у меня цикл 5мс, то программа должна выполниться за меньшее время. Как мы можем это гарантировать? Легко - ставим ватчдог, который будет срабатывать, если время выполнения программы превысит 5мс. Данный ватчдог будет возвращать систему в безопасное состояние - в моем случае это отключение всех выходов и ресет микроконтроллера.

В итоге что мы имеем? Либо гарантированное реальное время ЛИБО безопасное состояние. Все, других вариантов нет.

А вопрос насколько часто система будет вываливаться в безопасное состояние как раз зависит от качества софта. В идеале - никогда.


Данный ответ работает и для ПЛК. Если в вашем ПЛК не срабатывает ватчдог и он не вываливается в безопасное состояние, значит его программа выполняется за детерминированное время.

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

В ПЛК не вотчдог, а набор штатных сигналов о нарушениях на шинах связи и проч. проверки. О реальном вотчдоге там нигде ни слова!

Вы можете гарантировать на 100% безотказность ваших программ в неблагоприятных условиях и в режиме 24\7 ?
И если да, то на основании чего, мне очень интересно?
А если нет - то в чем тогда их преимущество ?

Безотказность - нет, уменьшить вероятность возникновения аварийных ситуаций - да. Ключевое слово - Functional safety.

Правильно, и в любом случае без ватчдога не обойтись.

Весь вопрос в том - что рвать WDog'ом. Поэтому и исповедуется мысль отделять mission-critical части от user interface

И? Реальное время надо уважать. Иначе это будет очередная IoT поделка, коих сегодня развелось очень много.


Можете почитаете доки? Во всех ПЛК, что я видел, есть Watchdog, как программные - следящие за выполнением отдельных задач, так и аппаратные.

Эт вы уже стали играть терминами. Я в такие игры не играю.

>> В любом нормально спроектированном софте не возможно, и это факт!



Можно было бы попытаться дать гарантию безошибочности (100 %, или хотябы 9.999 ), если бы весь "продукт" был свой, доморощенный.
до последнего бита и проводка.
1. Читаем errata на ВСЕ что используется из комплекующих, и пытаемся ЭТО предусмотреть в коде.
2. Читаем errata, и "мечтаем", что там моежт появиться в следующей ревизии (но глючек уже в этой).
3. Неоткрытая элементарная частица из Вселенной влетает в ГЛАВНЫЙ РЕГИСТР системы и все рушится.
(одна надежда, что по вероятности ОНО не затронет WD).

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

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

Вы не смогли зайти на гитхаб?

Ну вообще-то известно, что каждая 9-ка такой гарантии увеличивает стоимость разработки на 100%. Т.е достичь гарантии в 99.9% по сравнению с 99% будет стоить, как новая разработка и так далее. Но мне это и не нужно - в моем проекте в этом случае дешевле угробить оборудование и возместить убытки, чем пытаться защититься от таких сбоев.

Имеете какое-то отношение к этому проекту или просто купились на фразу - "все формально проверено"?
Только взглянул на спецификацию и чуть крыша не съехала.
Вы напрмер можете человеческим языком объяснить что такое higher-order logic?
Чем эти сектанты там вообще занимаются?