Тестирование операционной системы реального времени на твердость
У меня есть встроенное устройство ( Technologic TS-7800), которое рекламирует возможности в реальном времени, но ничего не говорит о "жестком" или "мягком". Пока я ждал ответа от производителя, я решил, что это не помешало бы проверить систему самостоятельно.
Каковы некоторые установленные процедуры для определения "твердости" конкретного устройства в отношении реального времени / детерминированного поведения (задержки и дрожания)?
Будучи в колледже, у меня есть доступ к довольно аккуратному оборудованию (хорошие осциллографы и генераторы сигналов), поэтому я не думаю, что у меня возникнут какие-либо проблемы с точки зрения тестирования оборудования, просто опыт.
6 ответов
У меня такая же доска здесь на работе. Я считаю, что это слегка модифицированное ядро версии 2.6, а не версия реального времени.
Я не знаю, что я прочитал что-то в документации, что означает, что это предназначено для строгой работы с ОСРВ.
С таким оборудованием должно быть довольно просто синхронизировать o-область с постоянными часами, генерировать всплеск каждый раз, когда система в реальном времени выдает выходной сигнал, видеть, насколько этот всплеск изменяется от центра. Чем меньше отклонение, тем больше твердость.
Чтобы уточнить ответ Боба, возможно:
Используйте генератор сигналов для генерации импульса с некоторой переменной частотой. Случайное распределение по некоторому диапазону было бы наилучшим.
используйте генератор сигналов (сигнал запуска), чтобы запустить прицел.
ОСРВ должна ответить, сделать это и отправить выходной импульс.
подайте выход RTOS на вход 2 прицела.
получить область, чтобы сохранить / режим сбора. получите прицел на А, остановитесь на Б., если можете.
в идеальном workd, получите его, чтобы измерить распределение для вас. Лекрой будет. Начните с гораздо более медленного следа, чем вы ожидаете. Вы должны быть в состоянии видеть медленные выбросы. Вы сможете увидеть распределение.
При условии нормального распределения SD изменения времени отклика - МЯГКОСТЬ.
(На практике этого не произойдет, но если вы не получите выбросы, это будет достаточно полезно.) Если есть выбросы с большой задержкой, ОСРВ НЕ очень сложная. Не уложился в сроки. Тогда не подходит для тяжелой работы в реальном времени. Многие RTOS-подобные вещи имеют хороший левый край кривой, наклоняясь вниз как кривая 1/f. Это свидетельствует о комбинированных дрожаниях. На что обращать внимание, это всплески медленной реакции на правом конце прицела. Продолжайте повторять эксперимент с более быстрыми следами, если нет никаких выбросов, чтобы получить хорошее изображение наклона. Должно быть хорошо для некоторого умозрительного заключения в вашей статье.
Если для вашего приложения скажем, что дельта 1 мс - это нормально, а вы измеряете 0,5 мкс, это все круто.
В любом случае, вы можете опубликовать результаты (и, вероятно, в смысле публикации, но, безусловно, в Интернете).
Ссылка из этого Вопроса на статью, когда вы ее написали.
Жесткий режим реального времени больше связан с тем, как работает ваше программное обеспечение, чем с аппаратным обеспечением. Когда вы спрашиваете, является ли что-то сложным в режиме реального времени, оно должно быть применено ко всей системе (Аппаратное обеспечение, ОСРВ и приложение). Это означает, что жесткое или мягкое в реальном времени является проблемой проектирования системы.
При нагрузке, превышающей спецификацию, даже жесткая система реального времени выйдет из строя (надеюсь, с надлежащей индикацией отказа), в то время как мягкая система реального времени с низкой нагрузкой выдаст жесткие результаты в реальном времени. Сколько обработки должно произойти во времени и сколько может быть выполнено предварительной / последующей обработки - это реальный ключ к жесткому / мягкому реальному времени.
В некоторых приложениях реального времени некоторая потеря данных не является ошибкой, она должна быть ниже определенного уровня, опять же по системным критериям.
Вы можете генерировать входные данные для платы и иметь небольшое приложение, подсчитывающее их и проверяющее, на каком уровне данные будут потеряны. Но это дает вам оценку, специфичную для той системы, на которой работает это приложение. Как только вы начнете больше обрабатывать, ваша вычислительная нагрузка увеличится, и теперь у вас будет другой жесткий предел в реальном времени.
На этой плате будет работать простой планировщик, который даст большую предсказуемую жесткую производительность в реальном времени для большинства задач. Запустив полную ОСРВ с большой вычислительной нагрузкой, вы, вероятно, получите только мягкие данные в реальном времени.
Edit after comment
Самый эффективный и самый простой способ, которым я пользовался для измерения производительности моего программного обеспечения (при условии, что вы используете расписание), - это использование свободно работающего аппаратного таймера на плате и отметка времени начала и конца моего цикла. Или, если вы используете полную отметку времени RTOS, вы получаете и переходите. Сохраните максимальное время и запустите среднее значение на секунду. Если ваш средний показатель составляет около 50%, а максимальный - в пределах 20% от среднего, с вами все в порядке. Если нет, то пришло время провести рефакторинг вашего приложения. По мере роста вашего приложения время цикла будет расти. Вы можете отслеживать влияние всех ваших изменений программного обеспечения на время вашего цикла.
Другой способ - использовать аппаратный таймер, генерирующий циклическое прерывание. Если вы вовремя сбросили прерывание. Если вы пропустили крайний срок, у вас есть обработчик прерываний, сигнализирующий о сбое. Это, однако, даст вам предупреждение только после того, как ваше приложение займет много времени, но оно зависит от аппаратного обеспечения и прерываний, поэтому вы не сможете пропустить.
Эти решения также устраняют необходимость подключения области для мониторинга выходных данных, поскольку информация о времени может отображаться в любом виде терминала с помощью фоновой задачи. Если его легко отслеживать, вы будете следить за ним регулярно, избегая, в конце концов, решения проблем синхронизации, но как только они появятся.
Надеюсь это поможет
Я думаю, что это не жесткое устройство реального времени, так как на нем нет RTOS.
Я понимаю, что вы гик, но использование осциллографа для тестирования компьютера с Ethernet / USB / другими цифровыми портами и ОГРОМНЫМ внутренним состоянием (ОЗУ) неэффективно и ненадежно.
Вместо просмотра волновых форм вы можете подключить любой компьютер к выходному порту и выполнить надлежащий статистический анализ.
Установленная процедура (если входной сигнал является аналоговым по своей природе) заключается в проверке системы на наличие нескольких характерных входов - традиционно пиков, ступенчатых функций и синусоидальных волн различных частот - и измерения фазового сдвига и дисперсии для каждого типа входа. Наихудший случай затем используется в спецификациях системы.
Опять же, если вы используете стандартные порты, вы можете легко генерировать их на ПК. Если вход действительно аналоговый, потребуется отдельный ЦАП или просто хорошая звуковая карта.
Теперь это ничего не говорит о том, что ОС работает в режиме реального времени - она может работать под управлением vanilla Linux или даже Win CE и при этом давать хорошие и стабильные результаты в тех тестах, если оборудование достаточно быстрое.
Итак, вам нужно смоделировать большие и различные нагрузки на процессор, память и все порты, дать ему нагреться и съесть память на несколько часов, а затем повторить тесты. Если задержка остается постоянной, то это трудно в режиме реального времени. Если это не произойдет, при любом типе нагрузки и входного сигнала, превысит допустимый предел, это мягко. В противном случае это реклама.
PS: Смысл в том, что даже для критически важных систем вам на самом деле не нужны жесткие данные в реальном времени, если у вас есть оборудование.