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

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

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

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

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

В смысле!? Применить микропроцессор и на внешней его шине на логике типа FPGA организовать подобие MMU?
Сильно! Здесь помочь не смогу.
Единственно сомневаюсь в эффективности такого решения, поскольку MMU тесно связан с кэшем. Ну а кэш не бывает на внешней шине.

А VxWorks, LynxOS поддерживают MMU. Только вот их исходники трудно найти.

Кроме того, для полной изоляции нужно еще IOMMU, т.к. устройства обладают такой "неприятной" возможностью как DMA.

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

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

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

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

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

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

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



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

Где можно найти какие методы они используют для обеспечения надежности?

Ну и к моей учебной проблеме. Написание банального диспетчера или портирование одной из осей/сред на новый МК тянет на кандидатскую?

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

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

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

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

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

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

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

вы как всегда в ударе, капитан очевидность



использовать на таких процессорах голые RTOS - это как в анекдоте про лису "обманула, обманула - деньги таксисту заплатила, а сама не поехала", а теперь куда вы засунете эти бумажки от uC/OS, если нужно что-то чуть более, чем круто дернуть ножкой ? Нормальные парни давно об этом подумали, даже комитеты создали по стандартизации Trusted Computing Group & ISO/IEC, GlobalPlatform TEE. А виртуализацией пользуются многие, например
http://www.ok-labs.com/releases/release/ok...quipment-from-k

От кого защитить? От своей же соседней программы?
Смысл защиты памяти в том чтобы оградить программу (и ядро) от произвольной сторонней программы, написанной кулхацкером Васей из 7а, осилившим журнал "какер". Или от одноклассника Васи - Пети, который осиливает указатели в Си по K&R и то и дело портит данные в драйвере файловой системы и теряет данные на диске.
В МК же вы заранее пишите весь софт, который там будет работать, и, соответственно вылавливаете баги и уж точно не станете специально портить данные ядра или других программ.
Например, во FreeRTOS-MPU чтобы для Cortex-M3 настроить правильно распределение памяти для задач уйдёт много больше времени и сил чем отлов реальных багов. А попытка программы обратиться куда нельзя так же вызовет MemFault. Надёжность только если на случай порчи данных, например вдруг так совпало и записываем неверные данные в буфер отправки сообщения по какому-либо каналу связи и так получится что вместо "привет" отправится что-то нецензурное. Т.е. гарантируется "плановый" сбой на случай бага с указателями или иными косяками в работе с памятью. Так на этот случай вроде достаточно простого MPU в кортексах М3

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




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



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

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

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

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


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

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

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

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

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

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

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

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

Voyager-1 летит уже 35 лет. Никакого MMU на нем нет.

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

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

а кто вам сказал что если есть MPU - то сразу появляется надёжность от быдлокода? надёжность с наличием/отсутствием MPU никак не связана (конечно, в проектах, где внешнюю программу подгрузить нельзя). надёжность зависит только от количества быдлокода.


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

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


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


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

Вы похоже не то что по ссылкам не ходите - даже не читаете то что тут цитируют - удачной беседы самому с собой

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

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

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

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

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

Да уж! ... вообще то средне-инженерная задача, но с неё делают кандидатскую и/или затем на докторскую замахиваются.
Что дальше? Или такое сильное отставание по OS в стране и какой!?

проблема с Opportunity ... хороша, но не фейк ли это? Они же тестируют все на модели на земле потом туда, или просто прохлопали.

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




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

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

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

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

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


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

Прошу прощения, я не сразу понял суть. Идея в том , чтобы использовать ЯВУ для мат. доказательства правильности работы ядра (или хотя бы его алгоритмов)?


Основное преимущество форта (говорим про быстродействие) - в малом объеме программ на нем? За счет отсутствия необходимости частой подкачки?



Теперь про L4. Я не особо силен в иностранном, поэтому чтобы вникнуть воспользовался этим: обзор.
Есть пара вопросов:
Синхронная передача сообщений означает что оба процесса должны одновременно быть в режимах приемника (один) и передатчика (другой). То есть для передачи оба процесса должны сменить состояние и отдать управление ядру, так?
Наличие многоуровневых менеджеров памяти. То есть аппаратно виртуализацию/защиту поддерживает только менеджер высшего уровня (в ядре L4)? В остальных виртуализация программна и менеджер работает в usermode? Например, ОС, работающая поверх L4 не имеет внутри абсолютных защит между своими процессами?

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

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

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

Кстати о передаче сообщений.
Вот пример ошибки с которой столкнулся вот прямо сегодня.
В применяемой операционке нет очередей. Вернее нет возможности послать в очередь из ISR.
Пришлось применить установку простого флага. Вполне подходящая процедура, а главное быстрая (что и подвело)
И все было хорошо и протестировано.
Но вот прошел год и понадобилось в программу ввести новую задачу и поменять распределение приоритетов у задач.
И начал сбоить тот драйвер который работал с флагом.
Оказалось что задача драйвера стала прерываться другой задачей и не успевать отслеживать флаг в результате чего на несколько установок флага приходилось одно считывание. Данные стали пропадать.

Так вот L4 это сплошное заумное теоретизирование никакого отношения к реальному риалтайму и RTOS не имеющее.
RTOS это детерминизм, профилирование, и замеры. Все силы направлены на обеспечение абсолютного быстродействия.
Отсюда и вытекают большинство компромиссов и ошибок.
Поработайте лучше над этим. Будет хоть какая-то польза обществу.

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



Да. Если интересует что-то по L4 на родном языке - обратитесь лучше сюда

http://l4os.ru/forum/

Alman - настоящий фанат L4



Систему можно построить по-разному, например в L4Linux процессы Linux - это задачи микроядра работающие каждый в отдельном адресном пространстве, а все системные вызовы Linux работают через IPC микроядра.

Так вот, создавайте высокоприоритетный поток, посылайте ему СИНХРОННОЕ сообщение из ISR а уж он затем пусть послылает асинхронное сообщение драйверу. Да -- согласен накладные расходы. Но никто не скажет что такая схема не обладает реалтаймом ).

Про "СИНХРОННОЕ сообщение из ISR" не понял. Звучит так словно ISR должна тормознуть пока какой-то поток не примет сообщение.
В какой RTOS это есть и как называется вызов API?

Это есть в L4 ядрах. Не ISR тормозит, а ISR отправляет сообщение, если что либо хочет принять "псевдосообщение от ISR" . Перед тем как его принять поток должен вызвать стандартный ipc_recv со спец идентификатором который обозначает номер прерывания, номер ловушки, номер ещё чего либо.

Interrupts are delivered as an IPC call to the interrupt handler thread (i.e., the pager of the interrupt thread).

Интересный пост
RetroBSD on Maximite

Я уже давно тут не отписывался, так как пока хочу лучше изучить предложенные решения (конкретно L4 и Forth). Но параллельно встречаются и другие вопросы, которые хотелось бы обсудить.

1) Какие способы оценки качества (а в случае моей целевой системы читать - надежности) существуют и могут быть актуальны. Последний классический учебник который я встречал (Майерс) датировани 1980 годом. Кнниги Липаева классическими не называют, да и основываются на совсем другом классе систем (большие, сложны, распределенные). То, что предлагают современные стандарты (чаще взаимодействуйте при разработке с сертифицирующим органом) не устраивает в связи с наличием человеческого фактора и отсутствием математически обоснованных методик.
Грубо говоря - как мне по науке доказать что то или иное решение принесет лучший результат.
2) Экзоядро. Я давно о нем слышал, но только недавно нашел хорошее объяснение, которое меня немного вдохновило. Еще раз про целевую систему: нет мму/мпу, памяти мало (дробить на страницы тяжело), не меняющийся набор программ, можно выполнять инструкции из флеш, много периферии, надо работать быстро, преобладание цикличных задач, вредоносного кода нет. Все так и подталкивает - отказаться от процессов в сторону потоков, написать простейшую переключалку по таймеру, а все остальное - в библиотеках. Защита - за счет инкапсуляции библиотек (ну и надеяться что в будущем к платформе пришьют мпу).
Кто сталкивался, поделитесь соображениями/ссылками/книжками.

Философские вопросы поднимаете.

Например в виденных мной проектах контроллеров управления двигателями не применяют RTOS в чистом виде, а используют гибридные механизмы где большую часть работы выполняют процедуры в прерываниях.
Потом процессы(задачи) и потоки на микроконтроллерах без MMU отличаются только работой со стеком.
Потоки используют стек задачи которую прервали. А задачи каждая имеет свой стек. В этом смысле потоки опасней, ибо ослабевает контроль за стеком задачи вызвавшей поток. Хотя в целом потоки экономят стек.
Сколько писал приложений ни разу не нашел применения потокам. Уж больно они усложняют схему межзадачных взаимодействий.

На работе сталкиваюсь с такими же системами. Ни разу не видел хоть какой-нибудь внятной методики оценки качества. ((((. То есть разговор упирается просто в известный холивар по поводу с "ОСи или без ОСи".

Единственное что нашёл, что код написанный под ОСРВ более структурен см структурное программирование

особенно пункт последовательное исполнение .

Буду рад если вы найдёте всё-таки методику.