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

[wedmeed]

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

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

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

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

[AlexandrY]

-защита программ друг от друга (виртуализация, МК без MMU), скорее всего аппаратными средствами;

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

Так MMU и есть единственное аппаратное средство виртуализации. Нет MMU - нет виртуализации.
Из перечисленных вами RTOS только QNX поддерживает виртуализацию.
Остальные свою надежность обосновывают компактностью. Т.е. чем меньше объем исходников тем меньше ошибок. И в принципе правы.
Самой надежной будет пожалуй в таком случае scmRTOS. Ну и самой бесполезной

[wedmeed]

Из перечисленных вами RTOS только QNX поддерживает виртуализацию.

Добавил еще VxWorks, LynxOS. А они поддерживают?
Собственно, MMU я и собираюсь аппаратно организовать. Литературы о их структуре я тоже не встречал, только в составе руководств на микропроцессоры, буду рад если кто подскажет.
Кстати, один из вопросов в том, насколько польза от устранения класса ошибок ПО будет больше ненадежности, внесенной добавлением микросхем.

[MrYuran]

Собственно, MMU я и собираюсь аппаратно организовать.

А смысл?
Не говоря уже про реализуемость.
Если нужен MMU (а точно нужен?) - так и берите соответствующий кристалл.

[wedmeed]

Если нужен MMU (а точно нужен?) - так и берите соответствующий кристалл.

Так стоит задача на работе. Нужно реализовать на конкретном МК (5 приемка, отечественный, большой набор встроенных нужных модулей). Это почему нельзя взять другой кристалл.
Нужен ли MMU? Как писалось выше - единственный способ виртуализироваться. А как еще защититься от того, что программа влезет в чужую память?

Про DMA спасибо, не думал. Если он не работает с внешней шиной, то придется защищать доступ к нему в принципе, делать через системные вызовы.
Кэша у конкретного МК нет (1887ВЕ3Т).

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

[AlexandrY]

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

Ну есть единственный выход, это писать прикладной софт на языке поддерживающем защиту памяти софтварно.
LUA, Java ME, .NET MF ...
Только придется среду исполнения портировать.

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

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

QNX порты на MMU-less не имеет.
Из серьезных осей чипы без MMU поддерживают: ThreadX, Symbian, VxWorks, Nucleus Plus, MQX ... Выбирайте.

[sasamy]

Ну есть единственный выход, это писать прикладной софт на языке поддерживающем защиту памяти софтварно.
LUA, Java ME, .NET MF ...
Только придется среду исполнения портировать.

среду исполнения не обязательно портировать

http://www.ertos.nicta.com.au/research/l4....ed/approach.pml

но в целом направление верное - использовать ЯВУ

[SyncLair]

http://www.ertos.nicta.com.au/research/l4....ed/approach.pml

L4 -- это семейство ядер почти все из них ориентированы на наличие MMU. И вообще наверное скорее следует говорить о MPU! Поэтому Вас не поддерживаю в этом, а вот в том чтобы "использовать ЯВУ" с защитой -- это да!
На мой взгляд java и Lua лучшие кандидаты.

А виртуализацией пользуются многие, например
http://www.ok-labs.com/releases/release/ok...quipment-from-k

Опять таки L4-тое ядро.

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

1. По надёжности -- Нет MPU -- нет надёжности от быдлокода!
2. По методикам -- различные стандарты требуют куча всего для того чтобы код был надёжным.
То есть направо не ходить, налево не ходить, компиляторными нестандартными фишками не пользоваться,
память выделять так, именовать так и так далее -- все эти требования выглядят как ритуал который впринципе помогает кодить среднеквалифицированым специалистам. НО! это всё не даёт 100% гарантии на выполнение!
ДЛЯ доказательства того что ВСЯ система надёжна нужно доказывать всё до последнего байта!

Если есть MPU -- то для доказательства надёжности нужно доказать что ядро+аппаратный механиз защиты памяти надёжны (L4 и прочее тут как раз рулит!) и то что нужные Вам высокоприритетные важные процессы надёжны!

3. РТОС без ММU c "гарантирванным временем вытеснения!" даёт возможность проводить математическое докозательство того что при любых условях самые высокоприоритетные процессы-"элита" получат себе нужное быстродействие а система уложится в отведённые дедлайны!
ВСЁ!


Сообщение отредактировал SyncLair - Oct 29 2012, 15:18

[wedmeed]

MPU!

Это если необходимо защищать встроенную память. Если пользуется внешняя - можно и MMU, правда выглядеть он будет довольно монстроидально. Исходя из задачи - да, MPU достаточно и гораздо оптимальнее.

"использовать ЯВУ"

Насколько сложно портировать среду явы?
Сложно ли гарантировать корретность портирования и отсутствие ошибок в среде?
Насколько понимаю, это накладные расходы x3 минимум?

З.Ы. На яве никогда не писал и, тем более, не портировал.

[SyncLair]

З.Ы. На яве никогда не писал и, тем более, не портировал.

ЯВУ не означает ТОЛЬКО ява. Ничем помочь не могу у самого реальный опыт ноль! Но на то она и диссертация....

[wedmeed]

ЯВУ не означает ТОЛЬКО ява.

Я Вас понял.
Виртуальные машины вещь очень сильная, но и расточительная. Когда люди говорят о микроконтроллерах - часто это связано с маломощными платформами и ужатыми ресурсами.
С другой стороны, у меня есть специфицеская задача со специфическим набором функций. Чтобы сократить расходы на интерпретацию байт-кода, очень пригодился бы такой же специфический набор функций. Но разрабатывать новый язык я не возмусь. Даже если он выродится в небольшой набор скриптов.
На мой взгляд, маленькая простенькая ОС с MMU/MPU выглядет гораздо элегантнее. Даже не ОС, диспетчер. Какие еще преимущества кроме контроля исполнения дают ЯВА-подобные среды?

Почему микроконроллеры с флэшью >64 Кб не оснащают MMU/MPU? Ведь уже в таком объеме можно наворотить довольно сложную систему. Насколько я понимаю это, по крайней мере MPU, не такой сложный модуль, который можно сделать даже не влезая в ядро (просто мониторить шину и генерировать прерывания-ловушки).

Сообщение отредактировал wedmeed - Nov 1 2012, 06:16

[Snaky]

Я Вас понял. Виртуальные машины вещь очень сильная... Какие еще преимущества кроме контроля исполнения дают ЯВА-подобные среды?

По-моему не поняли. ЯВУ - язык высокого уровня. Си, например. В отличие от ассемблера который низкоуровневый.

[wedmeed]

ЯВУ - язык высокого уровня. Си, например.

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

Сообщение отредактировал wedmeed - Nov 1 2012, 07:04

[sasamy]

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

В теме говорилось о том что "Только придется среду исполнения портировать", так вот ее не обязательно портировать - ЯВУ (Haskell по ссылке) используется для создания прототипа микроядра

Despite its ability to run real user code, the Haskell ker-
nel remains a prototype, as it does not satisfy our high-
performance requirement. Furthermore, Haskell requires a
significant run-time environment (much bigger than our ker-
nel), and thus violates our requirement of a small TCB. We
therefore translated the Haskell implementation manually
into high-performance C code. An automatic translation
(without proof) would have been possible, but we would
have lost most opportunities to micro-optimise the kernel in
order to meet our performance targets. We do not need to
trust the translations into C and from Haskell into Isabelle —
we formally verify the C code as it is seen by the compiler
gaining an end-to-end theorem between formal specification
and the C semantics.

[wedmeed]

ЯВУ (Haskell по ссылке) используется для создания прототипа микроядра

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

Использовать же MMU на этапе разработки только для того чтобы вычислить пару специфических ошибок сильно расточительно.

Человек есть человек. Все ошибки найти или гарантировать что они все найдены невозможно. http://www.osp.ru/os/1998/06/179592/
Или зачем тогда делают системы с резервированием?

то есть к доказательству надёжности каждой строчки проекта надо ещё и доказать надёжность дополнительного кода поддержки MPU?

Доказать надёжность кода поддержки MPU можно один раз и использовать во всех дальнейших проектах.
При защищенности процессов друг от друга можно плотно доказывать надежность только критических модулей программы, остальных - поверхностно. Если классифицировать уровень критичности модуля в соответствии с тем же КТ178.

[AlexandrY]

Человек есть человек. Все ошибки найти или гарантировать что они все найдены невозможно. http://www.osp.ru/os/1998/06/179592/
Или зачем тогда делают системы с резервированием?

А не удивительно, что за столько лет все продолжают приводить в пример замусоленные случаи с Ariane 5 и Therac-25?

Почему бы не привести проблему с Opportunity?

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

Там речь шла о том, что марсоход в определенный момент экпедиции вдруг стал жутко тормозным и долго не реагировал на команды.
Его пришлось остановить и долго перезаливать софт.
Там была RTOS VxWorks. Поскольку нынче на космической технике применяю радиационно стойкие RAD750 (аналог PowerPC) то WxVorks там использует MMU.
Программист то ли из-за лени, то ли из-за невысокой своей квалификации подумал, что в RTOS можно кое в каких местах пропустить использование мьютексов.
Дескать вызов мьютекса вносит лишнюю задержку, а там надо было записать какую-то мелочь межзадачную.
Хотя проблема инверсии приоритетов ему была прекрасно известна.
Ну инверсия и произошла. Низкоприоритетная задача в результате остановила важные задачи по оперативному управлению.

Теперь вопрос. Как MMU могло бы помочь этой проблеме? Ответите и докторская у вас в кармане.

[SyncLair]

Ну инверсия и произошла. Низкоприоритетная задача в результате остановила важные задачи по оперативному управлению.

Теперь вопрос. Как MMU могло бы помочь этой проблеме? Ответите и докторская у вас в кармане.

Конкретно тут -- никак. Тем не менее наличие MPU наверное позволило гарантировать что ядро системы не убиваемо, а раз ядро не убиваемо, то высокоприоритетный процесс-загрузчик может быть активирован соответвенно активировав его систему можно было перезагрузить/перепрошить или чего то подобное. Хотя конечно всегда можно тупо соседним контроллером сделать RESET и вперёд!

а кто вам сказал что если есть MPU - то сразу появляется надёжность от быдлокода?

то есть к доказательству надёжности каждой строчки проекта надо ещё и доказать надёжность дополнительного кода поддержки MPU?

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

Да доказываем надёжность ядра и надёжность CPU support package куда включается управление MPU!

Сообщение отредактировал SyncLair - Nov 2 2012, 15:14

[Mahagam]

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

быдлокод он такой быдлокод. вот какая-нить задача позахватывает мютексов на периферию и не отдаст. и всё. и вся защищённая система станет колом. нет у неё юзера с Ctrl-Atl-Del для того чтобы снять тупую задачу.

[SyncLair]

быдлокод он такой быдлокод. вот какая-нить задача позахватывает мютексов на периферию и не отдаст. и всё. и вся защищённая система станет колом. нет у неё юзера с Ctrl-Atl-Del для того чтобы снять тупую задачу.

Значит эта задача сидит в функциях что пишут на перефирию. Значит она не вызывает функцию программного ватчдога. Значит снимаем эту задачу, отрываем у неё мьютексы, периферию делаем init() и всё.


Юзера нет, зато есть другие процессы которые а)как супервизор её контролируют б) после 100ой попытки длиной в 10мсек взять мьютекс на перифирию, перезапускают модуль перифирии, а при перезапуске модуля все задачи которые его юзают получают фиг... ой то есть FALSE.

[Mahagam]

Значит эта задача сидит в функциях что пишут на перефирию. Значит она не вызывает функцию программного ватчдога. Значит снимаем эту задачу, отрываем у неё мьютексы, периферию делаем init() и всё.


Юзера нет, зато есть другие процессы которые а)как супервизор её контролируют б) после 100ой попытки длиной в 10мсек взять мьютекс на перифирию, перезапускают модуль перифирии, а при перезапуске модуля все задачи которые его юзают получают фиг... ой то есть FALSE.

вы сути не поняли: от быдлокода нет защиты. и никакие MMU/MPU не помогут. это всё для самозащиты системы от _внешних_ программ.

[SyncLair]

вы сути не поняли: от быдлокода нет защиты. и никакие MMU/MPU не помогут. это всё для самозащиты системы от _внешних_ программ.

Видимо действительно не понял, а разве внешняя программа не есть равно потенциальный быдлокод?