ОСРВ как тема кандидатской диссертации, прошу наставлений Опции

[wedmeed]

Я только поступил в апирантуру. Сразу оговорюсь что волею судьбы научные интересы моего научного руководителя и моей работы (читать - практической базы) оказались разные, хоть и в одной сфере. В связи с этим разбираться в выбранной теме приходится самостоятельно.
В этом году я защитил магистерскую по теме проектирования ПО для микроконтроллеров без ОС, но с планировщиком, применительно к системам автоматического управления (САУ). Скажу честно, хоть было и новое в этой работе, по большей части я просто изучал и приглядывался к принципам построения ОС.
В своей кандидатской работе я собираюсь объединить практику и теорию. На работе стоит задача переписать ПО для САУ на новый МК. Не возбраняется введение ОСРВ (раньше подзадачи тупо выполнялись в цикле определенной длительности). Естественно, целой ОСРВ там и не надо, ПО объемом <256 Кб. Но надо:
-многозадачность (многопоточность);
-защита программ друг от друга (виртуализация, МК без MMU), скорее всего аппаратными средствами;
-по возможности оптимизация.
Я не претендую на звание разработчика полноценной ОСРВ. Во избежание споров, возникающих даже из-за трактовок определения ОСРВ, и из-за использования в работе аппаратных средств назову её просто исполнительной средой (ИС).

Итак, моя работа будет состоять:
-Определение критериев надежности ПО (основные источник - статьи Шеремета В.П., кники Липаева В.В. и стандарты типа КТ178) и описание того, как ИС позволит их увеличить для задач моего класса.
-Выбор оптимального алгоритма планирования для специфических задач САУ (всегда есть циклические процессы ввод-обработка-вывод вместе с обычными процессами). Источники пока - Таненбаум, Курниц и интернеты, википедии.
-Определение специфики моего класса задач в необходимости абстракций (файловой системы не нужно, проецирования файлов в память не нужно, работы с сетью не нужно и т.п.). Написание ИС.
-Пример использования ИС на конкретном примере (надеюсь еще и получить внедрение).

Вопросы:
Какие еще материалы посоветуете по надежности ПО?
Какие материалы посоветуете по распространенным ОСРВ (RTX Keil, FreeRTOS, scmRTOS (на форуме не нашел, каюсь), MicroC/OS-II, uClinux, QNX, VxWorks, LynxOS) и их основным принципам? Именно основным, так как не хочу нарваться на уже изобретенный велосипед, а большинство статей носят обзорный характер (например, Курниц про FreeRTOS) и не рассказывают как устроен алгоритм виртуализации для МК без MMU, есть ли он вообще и прочие тонкости.
Ну и, собственно, ваше мнение по описанной проблеме. Что добавить/убавить, на чем заостриться, как облагородить тему для обретения значимости уровня кандидатской.

Сообщение отредактировал wedmeed - Oct 29 2012, 07:55

[sasamy]

ПО объемом <256 Кб. Но надо:
-многозадачность (многопоточность);
-защита программ друг от друга (виртуализация, МК без MMU), скорее всего аппаратными средствами;
-по возможности оптимизация.

Ваша память соизмерима с размером trusted base систем виртуализации - так что смысла нет никакого - это защита ради защиты.

Сообщение отредактировал sasamy - Oct 29 2012, 09:05

[wedmeed]

Какие еще есть способы защитить программу? Как это делают FreeRTOS и остальные без MMU.

Офтоп. А, например, QNX, имеет порты на МК без MMU (напр. для Cortex-M3 оно опционально)?

[MrYuran]

Какие еще есть способы защитить программу? Как это делают FreeRTOS и остальные без MMU.

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

Нет, конечно, можно и на AVR линукс запустить...
А смысл?

[wedmeed]

От кого? От самой себя?

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

[AlexandrY]

А вот ошибки программиста, среди которых так часто переполнения стека или неуправляемые циклы, контролировать бы надо. И как бы того не хотелось, от ошибок не защищен никто...

О методах достижения надежности в RTOS можно почитать в этой статье.
MMU для RTOS не добавляет надежности. Будет тот же самый сбой и выгрузка процесса. А в RTOS вообще не должно быть сбоев.
Недаром на навороченных чипах типа i.MX53 c MMU и прочими фичами для жизненно важных приложений выбирают uC/OS RTOS без всякой виртуализации.