SWD Software Ltd. - официальный дистрибьютор QNX на территории России и стран бывшего СССР Операционная система реального времени QNX
Инструменты для создания надёжных встраиваемых систем и
интеллектуальных устройств любой сложности
QNX Software Systems - разработчик встраиваемой операционной системы QNX
Информационные брошюры
Статьи и публикации
Обзоры
Операционные системы
Графические интерфейсы
Средства разработки
Прикладные системы на базе ОС QNX
Разное
Конкурсные статьи
Техническая литература
Материалы конференций QNX-Россия
Полезные ссылки
Блог QNX
Главная страница > Материалы > Статьи и публикации > Разное > Технология мгновенного запуска для автомобильных телематических и информационно-развлекательных систем Сделать страницу стартовой Послать ссылку коллеге Версия для печати

Технология мгновенного запуска для автомобильных телематических и информационно-развлекательных систем

Шеридан Этьер (Sheridan Ethier), инженер-программист, sheridan@qnx.com
Ренди Мартин (Randy Martin), менеджер по проектированию автомобильных систем, randy@qnx.com
QNX Software Systems

Вопросы быстродействия

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

Для того чтобы управлять такими сложными системами, разработчики стали использовать полнофункциональные операционные системы реального времени на 32-разрядных процессорах, способных работать в защищенном режиме и поддерживать различные автомобильные технологии, включая коммуникационные шины J1850, CAN и MOST. Несмотря на свою сложность, эти системы должны отвечать тем же требованиям по времени отклика, что и предшествующие аппаратно-программные решения. Например, с момента включения блок телематического управления должен обеспечивать прием CAN-сообщений в течение 60 – 100 мс. Однако проблема заключается в том, что на начальную загрузку сложного программного обеспечения, используемого в таком устройстве, может потребоваться несколько сотен миллисекунд или больше.

Моменты критической важности

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

  • прием CAN-сообщений в интервале от 30 до 100 мс после включения питания;
  • передача ответа на эти сообщения в течение 100 мс после их приема;
  • чтение сообщений Class 2, поступающих с коммуникационной шины автомобиля, и реагирование на события активизации;
  • инициализация MOST-трансивера и передача ответов на MOST-запросы.

Длительность многих из этих важных событий должна составлять не более нескольких десятков миллисекунд после включения питания системы.

Для соответствия этим временным требованиям во многих системах применяется вспомогательный коммуникационный процессор или внешний модуль питания — относительно простое, но дорогостоящее решение. Однако благодаря применению передовой технологии, разработанной инженерами компании QNX® Software Systems, такое оборудование больше не требуется. Технология мини-драйверов — это подход с применением компактных, высокоэффективных драйверов устройств, которые начинают выполняться до инициализации ядра ОС. Мини-драйвер, определенный в загрузочном файле системы, может быстро и своевременно реагировать на сообщения, выдаваемые при включении питания, обеспечивая прием всех без исключения сообщений во время загрузки ОС. После загрузки ОС мини-драйвер может продолжить свою работу или передать управление полной версии драйвера, которая затем может обработать все сообщения, буферизированные мини-драйвером.

Пример применения

В качестве примера применения мини-драйвера рассмотрим автомобильное телематическое устройство, подключенное к шине CAN. При запуске автомобиля контроллер CAN-шины посылает сообщение "Питание включено" на зависимые устройства в течение 65 мс (см. рис. 1). Программное обеспечение телематического устройства должно быть готово к приему CAN-сообщения и, возможно, к ответу на него в течение как можно более короткого периода времени — 55 мс или меньше. Это связано с тем, что после включения питания центральному процессору требуется порядка 10 мс на выполнение первой команды.

Кроме того, телематическое устройство должно передать в ответ сообщение "Устройство активно" в течение 100 мс после приема сообщения "Питание включено". Это сообщение информирует контроллер шины о том, что устройство находится в рабочем состоянии. Если устройству не удается передать это ответное сообщение в течение указанного периода времени, контроллер шины может решить, что устройство неработоспособно и отключить его от шины. После установления начального контакта при включении питания телематическое устройство должно также выполнять буферизацию и, возможно, передачу ответа на все сообщения, принимаемые по CAN-шине во время процедуры начальной загрузки. Как показано на рис. 1, эти сообщения могут поступать с частотой 1 сообщение каждые 10 мс.

В данном сценарии ядро операционной системы (ОС) вряд ли сможет выполнить полную инициализацию до получения первого CAN-сообщения "Питание включено", так как в самом процессе начальной загрузки есть узкие места. Эти узкие места включают в себя копирование образа ОС в ОЗУ, переключение ЦП из физического режима в виртуальный режим и ожидание стабилизации тактовой синхронизации. В действительности время начальной загрузки полнофункциональной защищенной ОСРВ от момента сброса при включении питания до момента запуска первого пользовательского приложения, как правило, составляет несколько сотен миллисекунд. Таким образом, мини-драйвер должен начать свою работу во время инициализации системы до того, как образ ОС будет скопирован в ОЗУ.


Рис. 1. Примерная карта событий при инициализации телематического устройства на шине CAN

Обзор архитектуры

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

Мини-драйвер состоит из двух основных компонентов:

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

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

  • Опрос. Во время начальной загрузки система опрашивает функцию обработчика мини-драйвера в различные моменты времени для определения того, приняты ли данные периферийным устройством. Для осуществления этого опроса загрузочный код может обращаться к функции обработчика с заданными пользователем интервалами.
  • Опрос на основе прерываний по таймеру. Функция обработчика подключается как обработчик псевдопрерывания, срабатывающий по системному таймеру. Вызов обработчика выполняется с фиксированным интервалом времени. В этом случае мини-драйвер по-прежнему находится в режиме опроса, однако системе не требуется явно обращаться к функции обработчика во время исполнения загрузочного кода.
  • Прерывание от устройства. Механизм прерывания от устройства подключает функцию обработчика непосредственно к источнику прерывания устройства. Этот механизм также позволяет избежать опросов и вызывает обработчик прерываний только при возникновении аппаратных событий.

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

Плавное переключение

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

Краткое описание управляющей последовательности

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

  1. Мини-драйвер принимает на себя управление в заданные интервалы времени в ходе начальной загрузки. Этот процесс выполняется на основе опроса, поскольку аппаратные прерывания на этом этапе еще не работают. С мини-драйвером может быть связан небольшой стек протоколов. Он реализует минимальный объем логики для выполнения следующих операций:
    • инициализации оборудования;
    • буферизации входящих сообщений в памяти данных;
    • реагирования на критические события.
  2. В определенный момент фазы начальной загрузки включаются прерывания. После этого система может вызывать мини-драйвер с использованием прерываний. (Так как системный таймер сам по себе является прерыванием, механизм опроса при необходимости по-прежнему может использоваться.)
  3. После загрузки ОС мини-драйвер передает управление полной версии драйвера.
  4. С полной версией драйвера связан полный стек протоколов. После запуска драйвер может читать и обрабатывать все данные, собранные мини-драйвером в процессе начальной загрузки.

При такой схеме начальной загрузки процессор общего назначения может работать как специализированный. Например, лабораторные испытания системы на основе процессора Freescale MPC5200 с тактовой частотой 396 МГц показали, что мини-драйвер может легко обеспечить обработку потока сообщений, поступающих каждую миллисекунду. Другими словами, если при включении питания данные посылаются в устройство каждую миллисекунду, мини-драйвер может успешно принять и обработать все данные, поступившие во время начального запуска системы. Аналогичные результаты могут быть получены и при использовании процессоров на основе архитектур SH-4 и ARM.


Рис. 2. С помощью мини-драйверов автомобильные телематические системы со сложным программным обеспечением на основе ОСРВ QNX Neutrino® способны реагировать на сообщение запуска по шине CAN в течение не более 40 мс без необходимости применения вспомогательного коммуникационного процессора.

О компании QNX Software Systems

Компания QNX Software Systems Ltd. является мировым лидером в области технологий микроядерных операционных систем реального времени. Решения QNX внедрены в миллионы устройств по всему миру. Такие компании, как Cisco, DaimlerChrysler, Lockheed Martin, Panasonic, Siemens и General Electric, используют технологии QNX для создания сверхнадежных систем, предназначенных для рынков сетевого, автомобильного, медицинского, военного оборудования и систем промышленной автоматизации. Компания QNX Software Systems основана в 1980 году. Офисы компании находятся в Северной Америке, Европе и Азии.

Рассказать друзьям:

Rambler's Top100           Рейтинг@Mail.ru