По теории практически 100 % надежность (99,99999.... % ) обеспечивает 3-х контурная дублирующая система. Где 1 контур является работчим, 2 альтернативным, а 3 проверяет работу 1. Если произошел сбой 1, то перераспределяются. 2 включается, 3 альтернативным, 1 перезапуск и контроль 2. И так далее.
Вроде так если не запутался.
Соответсвенно должна быть трехпроцессорная модель, с тремя ядрами (главными циклами), для полной надежности.

VaStaNi
RTS (СРВ) делятся на HRT (жёстк. реальное время) и SRT (мягк. реальное время). Первая гарантирует появления результата в заданный интервал времени с вероятностью 1, вторая с заданной вероятностью (P<=1). Вот и всё!

Причём "заданный интервал времени" вполне может быть и большим, по этому поводу наш преподаватель привёл хороший пример: печь для обжига цемента. Она представляет из себя горизонтальный вращающийся цилиндр, цемент обжигается горелками, которыми управляет СРВ. Так вот, снятие параметров происходит один раз в час, по этим параметрам корректируется работа горелок. И это HRTS! Т.к. раз в час мы получаем результат, в виде анализа полученных данных и управления горелками. Это я к тому что многие восхищаются системами реального времени как очень быстрыми (реакции порядка неск. мкс. а то и нс, etc.... ), но это не всегда так. И ещё для примера: управлене инжекторными двигателями в автомобилях как правило поручают системам мягкого реального времени, т.к. некоторая задержка там не особо критична. По поводу винды : есть WinCE - вполне себе СРВ.

Термины "жёсткое" и "мягкое" реальное время придумали в MS когда пытались пропихнуть NT в качестве RTOS. Разница в том, что в настоящей RTOS время отклика системы на событие можно рассчитать точно а в "мягкой" нет.

По поводу MS с NT не соглашусь, а остальное как я и говорил.

Ну раз модеры считают, что тут излагать полные объемы статей на нескольких листах, норма, то бомблю
тут ЧАСТЬ 2.
-----------------------------------
Продолжаем.

Забегая вперёд сразу скажу, что "наш робот" обречён постоянно падать на землю,
даже если его несколько раз пытаться "ставить на ноги"..., так как система
в целом НЕ будет функционировать! И это при всём при том, что железо и прикладное ПО выполнены у нас изумительно!
Да, да, да я собираюсь больно ударить по самому святому для некоторых - незыблемости ОС, правильности её организации и функционирования,
свойствах и способности обеспечить стабильные таймерные воздействия на девайс,
посредством портов ввода-вывода! Очевидно, что как "прослойка" между ПО прикладного уровня и девайсом стоит - ОС. В первую очередь это драйвера и стратегия работы драйверного уровня, базовые механизмы ядра.
Естественно, что обеспечить нам стробированные 1 мс интервалы
это весьма круто, для современных известных ОС и "планка требований" - это явный перебор... типа нереальность это, но если "заказать" даже 10 мс жёсткого периода БЕЗ «дрожания фронтов»(!), то для многих ОС это все равно будет проблемно.
Почему? Куда я клоню, в конце концов? Хорошо, я не буду перебирать все ОСи/архитектуры их достоинства и недостатки, это можете сделать Вы или более знающий меня, да и в данном конкретном случае это мне (нам) и не нужно, будем отталкиваться от исходных данных и в их жёстких рамках пытаться предложить решение, или хотябы метод, направление, куда идти в таком случае, особенно в области ОСестроения, чтобы ОС могла позволить решать такие комплексные задачи.
Чем, какой ОС можно решить данную задачу или что из существующего можно улучшить?
1) ДОС. ДОС даёт почти полную широту и размах творений, но это будет ОДНОЗАДАЧНЫЙ аппарат, который "угробит" все прелести современных PC машин, тут придется распрощаться и со многими современными девайсами и гибкостью и т.д.
Но! Но, как замечательно просто тут обеспечить 1 мс! Берем и пишем обработчик IRQ0, который в силу архитектуры железа имеет максимальный приоритет, в него "будем гарантированно попадать" каждый 1 мс тик таймера. Ну и таймер 8054, конечно "заведем", как периодический 1 мс. Этот обработчик выполняет критически
важный участок по работе с портами (девайсной периферией). Остальная часть задачи, по сути, это прикладуха чистой воды, которая будет брать/посылать данные через некие буфера ввода-вывода. Тут, собственно ОС, вырождена, она не посредник!
Но задача то выше объявлена, как многозадачка! Значит, отпадает этот вариант. Но узелок на память, о красоте решения проблемы узкого места, оставить надо
2) Винда или еще что то из серии... Главнейшая проблема архитектурно-принципиального плана: планировщики задач, менеджеры процессов, драйвер, как почти рядовая задача вне зависимости от того в каком кольце защиты он и с каким суперсистемным приоритетом он работает, а ещё есть IPC...
Обобщим приговор. Данная архитектура, "плавающая" во времени, ввиду ряда причин, не может дать предсказуемых, программируемых, и уж тем более, жестких, гарантированных временных событий в виде обращений портов ввода-вывода.
3) ОСРВ типа QNX и им подобные архитектуры имеют существенные изъяны по быстродействию, для подобных задач. Основной минус и потери на IPC, несмотря на то, это уже ОСРВ. Плюс сюда их "жёсткость", насколько мне известно, на такие временные вещи не распространяется, т.е. они обеспечивают десятки миллисекунд... "Нас" это в 21 веке не устраивает ну хорошо, пусть будет не наглое нас, МЕНЯ. Меня не устраивает это и еще то, что рядом с этим лежит, связано, видно... мне, и, быть может, далее и Вам.
4) Нужно новое решение. Анализ недостатков, достоинств, обобщение и компромиссное решение.
Если проанализировать ныне известные и широко-используемые архитектуры ОС, в первую очередь пожалуй ОСРВ, то создается впечатление, что либо в целях упрощения, либо упущения, про синхронные операции ввода-вывода забыли или пренебрегли, посчитав их архаизмом что ли. Как сегодня яростно изживают LPT порт! А ведь железячникам, прибористам, ничего адекватного по скорости и простого по доступу не предлагают.
USB, FireWare... это все намученные, да накрученные, помимо того это последовательные данные(!), о стробировании и синхронном вводе-выводе не может быть и речи, сразу возникает проблема наличия/создания собственными силами ответного девайса, протокола работы самого порта и протокола "итогового" взаимодействия с девайсом и т.д.
Далее. Возможно и то, что среди "архитекторов" ОС настоящих "железячников" и не было... либо их голос ничего "не весил". А что? Могу предположить и такое. Имею право.
Результат, как говорится на лицо. Какой ценой, если отметать полную невозможность выдержать временные требования задачи, "приходится платить" если её все же РЕШАТЬ?
Что приносится в жертву вне нашего желания ущербной ОС при попытках "вписаться" в существующие жёсткие правила "жизни железа", которые при фактической реализации и дают истинную интеллектуальную жизнь комплекса в целом? Пусть робот не умеет ходить, но равновесие он держать должОН!? Т.е. стоять, балансировать при качках вправо-влево...
Согласитесь, для очень большого количества людей ОС - это почти только то, что
они видят на экране и слышат...
А ведь ОС, нужна человеку и для некоторой конечной физической цели в конце концов, а не для того, чтобы сидеть на стуле и наслаждаться тем, что в ней, в ОС, "под её крылом", так сказать мирно живут 100, 1000 или 1000000
весьма разумных, качественных приложений! Грубо говоря, просто перебирать, сортировать, мутировать терробайты цифр и этим ограничивать цель многозадачности ОС, дело скучное и огранниченное... по крайней мере для таких как я! Я верю, что есть думающие, как я, ведь мы, слава Богу не машины и не клоночеловеки!
Лично я, хочу видеть решения по ОС, позволяющие ЭФФЕКТИВНО управлять чем либо внешним и чем более эффективно и масштабно, тем лучше.
Получается, что даже имея xxxxx$ зеленых купив QNX задачу не решить. Так? Особенно, если о xxxxx$ и мечтать не приходится...
Возможные писсимисты и противники моих доводов и примеров скажут, наверное,
да что тебе еще надо? Возьми современный USB стык или несколько их, ну напиши драйвер под них и даже под свою ОС и "ворочай" свои железки. Но скажет это, думаю, как раз тот, кто не писал драйвера, не сталкивался с проблемой синхронного ввода-вывода ИМЕННО в драйвере, не видел множество
мест этапов жизнефункционирования дайвера, его алгоритма!
Да, скажу я вам по своему опыту, пишущий даже простой драйвер под многозадачную ОС, и который писал уже, умеет писать под ДОС, не раз в процессе создания, вспоминает прелести ДОСа и прямоты работы с портами!
Прежде всего печально и удручающе действует то, как нарастает огромный снежный ком тактов..., нет отнюдь не снежный, пожалуй, а огромный ком ...ма
на простые операции ввода-вывода, какой ужас охватывает сознание, когда цена расплаты возростает в тысячи раз, по сравнению с тем, если бы это было более оптимально решено в архитектуре ОС.
Ну пусть не так прямо и не так непосредственно, как в ДОСе, понятно, что за многозадачность все равно платить надо, но можно наверное и более дешевле раз в 10 или 100, наверное, по тактам выигрыш получить, совокупно системой затраченные на «переброс» всего одного байта от уровня приложения до самого порта или в обратном направлении.
Плюс, решить вопрос синхронизации этих обращений к портам, чтобы не плавали они
в "+" и в "-", как "...но в проруби".
А драйвера, скажут мне поверхностные люди, грамотно надо писать! Используй прерывания железки + системы!
Использую, использую, спокуха! Только не всегда ЭТО удовлетворяет, не всегда ТОЛЬКО ЭТО нужно, не всегда и ВСЕ прерывания заложены во ВСЕ механизмы работы устройства! Я уточню, в данном месте, речь идет уже об устройстве внутри PC машины (контроллер периферии), а не том, что вне его цепляем. Ведь для ОС
"по барабану" какой порт это. LPT на котором, что то подключено или это порт контроллера USB, FDC, SMBUS, аудиокодека... Итог, к сожалению, как приговор, один, чем меньше, казалось бы нужно данное обращение к порту, чем более оно «не важно», тем больше надо заплатить. Вот и получается, что для всех обращений к портам, требующие периодического, строго-периодического опроса или записи, к таковым относятся драйверные механизмы ожидания готовности, инициализаций или когда, действительно нужно строгое равенство промежутков времени
между обращениями, приходится уделять внимания при программировании, под час гораздо больше, чем к тем участкам драйвера, где, собственно производится самая полезная работа драйвера устройства. Чаще всего полезная, это именно передача данных да еще скоростная, потоковая, да еще и дуплексная. Еще раз напомню, что тут разработчики и ОС и железячного контроллера, как бы старались и Вы имеете и прерывания и скорость, но вот о том, чтобы сообщить, генерировать прерывание по готовности, это не везде есть. Вернее сказать, чаще всего, почему то, его просто нет. Выводы делает каждый сам.
Почему я из мухи делаю слона!? Давайте все же прикинем степень расплаты, хотя бы, а если у Вас есть возможность посчитать или ЗАМЕРИТЬ такты (RDTSC) в Вашей ОСи, в Вашем драйвере, то сделайте это.
Итак, ожидание, ожидание готовности - это полезная работа ОС или холостой ход, простой, на который тратится процессорное время, ввиду ВЫНУЖДЕННОЙ необходимости? Явно, это не полезная работа - ЭТО ЖЕРТВА! Вынужденная жертва, это та самая цена.
Получается так, что если простой/ожидание часами, сутками, то расход максимален, а если, скажем, чуть чуть тормознула ОС... ну винда «морозится», скажем когда пустой CD вставляешь или вообще он "битый", ну тогда неприятно, но потерпеть дескать можно, ну отвернуться можно и переключить внимание на что либо,
чтобы не тошнило в очередной раз от этого... Нет, ну может быть кому то и все равно в офисе, а может, кто то привык, кто то смирился или смиряется с «ценой». Но мы то нет! Мы то не крестики-нолики на экране гонять хотим...
Я лично, против, чтобы холостому ходу, в массе своей, "пустым" операциям тестинга портов устройств, уделялось так много времени. Подбираюсь к главному - контекст переключения задачи сжирает массу машинного времени при передаче считанного значения с тестируемого порта наверх, где собствено и производится оценка.
А ведь очень много случаев, когда простой, ожидание гораздо длительнее передачи "полезных" данных или параметров! Причем, для передачи "полезных" данных, как правило, имеются порты у которых есть аппаратные механизмы разгрузки поцессора, такие, как аппаратные прерывания завершения, прямой доступ к памяти DMA,
и тут сами обращения могут быть блочными, следовательно расход тут невелик.
А если в ряде случаев, происходит нештатная ситуация и код ОС или драйвера "вылетает" на длительную, быть может глухую ветку анализа готовности, к�