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

[syoma]

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

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

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

[syoma]

Получается большой черный ящик, с массой входов и выходов, работающий (декларирутеся) в реалтайм и надежно (декларируется).

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

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

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

[AlexandrY]

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

Я не так строю систему.
Да, 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 ставить прямо вместе с риалтайм системой.