Easyelectronics.ru

Вы правильно все описали. Так в реале все и делается (в нормальных системах).
Канальность, называется по буржуйскому (там чтото про sil надо читать, так глубоко я не лазил), по нашему - редундантность, но не полная.

Кстати, в той железке, в разработке которой я участвовал, был еще и третий компонент - который мониторил как мелкий контроллер (отвечающий за мотор помпы), так и большой (отвечающий за UI и терапии дыхания).
При этом как мелкий контроллер, так и большой контроллер - они мониторили друг друга обоюдно :)
И если кто-то начинал гнать, другой впадал в аварийный режим (помпа - на небольших оборотах, но уже без каких либо терапий продолжала дуть), или большой контроллер начинал всячески орать, а если оба они выпадали - то третий компонент (CPLD, кстати) орал еще громче.
Так что в итоге - один хрен - ресет.

Кстати - немного оффтопа - в госпиталях, когда к ним поступает новая железка, первым делом отключают все эти пищалки/свистелки - оно их нервирует.

Дополнение - бесконечное количество контроллеров не поставишь, денег не хватит, как у производителя, так и у покупателя, такое покупать - конкуренция не спит.

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

Не, ребят, это все, конечно, хорошо, но это не по теме. Тема заключается в построении удобной OS а не в уходе от необходимости таковой.

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

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

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

Насчёт денег.
Один большой или несколько малых МК — разница в цене очень незначительна.
Несколько МК ставят в достаточно сложных устройствах, цена которых десятки и сотни тысяч рублей, поэтому такая разница в цене не имеет значения. А упрощение разработки и связанное с этим повышение надежности и снижение времени разработки существенно.
Конечно, каждый МК в своём функциональном блоке может выполнять далеко не одну задачу. В своём блоке периферийный МК может обрабатывать несколько датчиков, исполнительных устройств, следящих систем и т. д.


Зачем МК мониторят друг друга — не ясно.
На мой взгляд, контролирует ситуацию центральный МК, а периферийные МК только обслуживают его: выполняют команды центрального МК и передают ему информацию о состояние дел в его блоке, показания датчиков и т. д.


Зачем «отдельно взятая единица должна иметь возможность решать широкий круг задач»?
Периферийный МК решает определенную чётко поставленную задачу или несколько задач, скажем, подачу кислорода. Программа для такого МК будет простой, без всяких наворотов с ОС, соответственно, её легко написать и она будет надёжной.


В каких устройствах должен стоять именно один МК?
Я предполагал, разработчик выбирает число МК согласно поставленной задаче.



Если разработчик ставит 10 МК, где без проблем можно поставить один, то тут вопрос в невысокой квалификации разработчика, а не в подходе.


Почему не по теме?
Нужна ли ОС для МК, по крайней мере, в большинстве случаев? Если нет, зачем Menzoda будет тратить время и силы.
На мой взгляд, есть гораздо более актуальные задачи. Скажем, удобный язык для МК, хотя я тут не специалист.


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

Почитайте стандарты IEC 60601-xxx. В частности IEC 60601-1ed3.0 пункт 14.8. И за одно IEC 62304, IEC 61508
Ну и еще статейку на тему:
http://www.todaysmedicaldevelopments.co ... al-safety/
Там на первой картинке средний и правый столбцы, ну и вообще вся статья целиком.
Особенно про Protection type CPP -One control system with two or more independent protective measures.
Ну и еще можно погуглить на ключевые слова - Class C Software Classification.
Тогда такие вопросы, я думаю, не станут возникать.

Зачем?
Я же это уже сделал еще более 15-ти лет назад. И мою RTOS Вам всё равно не переплюнуть

и где можно посмотреть на эту РТОСу? Где исходники?

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

На что отвечает предоставленная ссылка в несозданной Вами темы, но уже устаревшей информации?

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