Тестирование операционной системы реального времени для твердости

Question

У меня есть встроенное устройство (Technologic TS-7800), которое рекламирует возможности реального времени, но ничего не говорит о «жестком» или «мягком». Пока я жду ответа от производителя, я подумал, что это не помешает самому протестировать систему.

Каковы некоторые установленные процедуры для определения «жесткости» конкретного устройства в отношении реального времени/детерминированного поведения (латентность и джиттер)?

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

Answer 1

У меня такая же доска здесь на работе. Это немного модифицированное 2.6 Ядро, я считаю ... не в режиме реального времени.

Я не знаю, что что-то прочитал в документах, но это указывает на то, что он предназначен для работы с ОСРВ.

Answer 2

С таким оборудованием должно быть достаточно легко синхронизировать o-scope с устойчивыми часами, производить всплеск каждый раз, когда система реального времени производит выход, а также видно, насколько этот шип изменяется от центра , Чем меньше вариация, тем больше твердость.

Answer 3

Чтобы уточнить ответ Боба может быть:

Используйте генератор сигнала для генерирования импульса при некотором изменении частоты. Случайное распределение по некоторым диапазонам было бы лучше.

использовать генератор сигналов (сигнал запуска), чтобы запустить область.

RTOS должен ответить, сделать это и отправить выходной импульс.

подача RTOS-выхода на вход 2 области действия.

получить область действия для сохранения/сбора. получите возможность начать с A, остановитесь на B., если сможете.

в идеальном workd, получите его для измерения распределения для вас. Лекрой. Начните с гораздо более медленного следа, чем вы ожидали. Вы должны уметь видеть медленные выбросы. Вы сможете увидеть распространение.
Предполагая нормальное распределение, SD изменения времени отклика является SOFTNESS. (Это на самом деле не происходит на практике, но если вы не получаете выбросы, это разумно полезно.) Если есть избыточные задержки, то RTOS НЕ очень сложно. Не соответствует срокам. Неподходящий, то он предназначен для работы в режиме реального времени. Многие похожие на RTOS вещи имеют хороший левый край кривой, наклоненный вниз как кривая 1/f. То, что указывает на комбинированные колебания. Вещь, на которую нужно обратить внимание, - это всплески медленного ответа в правом конце области. Продолжайте повторять эксперимент с более быстрыми трассами, если нет ярлыков, чтобы получить хорошее изображение склона. Должно быть хорошо для какого-то спекулятивного заключения в вашем документе.

Если для вашего приложения, скажем, дельта 1uS в порядке, и вы измеряете 0.5us, все круто.

Во всяком случае, вы можете опубликовать результаты (и, вероятно, в публиковать смысл, но, конечно, в Интернете.)

Ссылка от этого вопроса к работе, когда вы написали это.

Answer 4

Я понимаю, что вы выродка, но с помощью осциллографа для тестирования компьютера с сетевыми/USB/другими цифровыми портами и ОГРОМНЫМ внутренним состоянием (ОЗУ) является неэффективным и ненадежным.

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

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

Опять же, если вы используете стандартные порты, вы можете легко сгенерировать их на ПК. Если вход действительно аналоговый, потребуется отдельный ЦАП или просто хорошая звуковая карта.

Теперь это ничего не говорит о том, что ОС в режиме реального времени - это может работать с ванильным Linux или даже Win CE и при этом производить хорошие и стабильные результаты в тех тестах, если оборудование достаточно быстро.

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

P.S .: Вывод заключается в том, что даже для критических систем вам действительно не требуется жесткое в реальном времени, если у вас есть оборудование.

Answer 5

Жесткий режим реального времени имеет больше общего с тем, как работает ваше программное обеспечение, чем аппаратное обеспечение. Когда вы спрашиваете, что-то трудно в режиме реального времени, оно должно применяться к полной системе (аппаратное обеспечение, RTOS и приложение). Это означает, что жесткие или мягкие в реальном времени проблемы с дизайном системы.

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

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

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

Эта плата будет работать с планировщиком голых костей, что даст большую прогнозируемую производительность в режиме реального времени для большинства задач. Запуск полной RTOS с тяжелой вычислительной нагрузкой, вероятно, вы получите только в режиме реального времени.

Edit after comment
Наиболее эффективный и простой способ, который я использовал для измерения производительности своего программного обеспечения (при условии, вы используете Schedular) является с помощью бесплатного таймера работает аппаратный на плате и время штампа в начале и конец моего цикла , Или, если вы запустили полную RTOS-метку, которую вы приобрели и перешлите. Сохраните максимальное время и запустите среднее значение в течение секунды. Если ваш средний показатель составляет около 50%, а макс - в пределах 20% от вашего среднего, вы в порядке. Если не настало время реорганизовать ваше приложение. По мере роста вашего приложения время цикла будет расти. Вы можете отслеживать влияние всех изменений программного обеспечения на время вашего цикла.

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

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

Надеюсь, что это поможет

Answer 6

Я думаю, что это не жесткое устройство в режиме реального времени, так как оно не запускает RTOS.