Проблемы создания цифровых инструментальных кластеров

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

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

Кроме этих преимуществ, существует тенденция падения стоимости больших ЖК-панелей и процессоров, управляющих ими. Это делает цифровой инструментальный кластер весьма приемлемой альтернативой аналоговым кластерам.

Аналоговые кластеры нам хорошо послужили

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

• Шаговые двигатели: давно ушли те времена, когда от двигателя шел тросик к спидометру для непосредственной передачи текущей скорости. В современных измерительных приборах для управления стрелками используются шаговые двигатели, по одному двигателю на каждую стрелку. Процессор посылает на двигатель импульсы, чтобы установить стрелку в нужное положение.
• Процессор (ЦП): для аналоговых кластеров обычно используются 8-и и 16-битные ЦП, в которые встроены (или имеются на плате) аналого-цифровые преобразователи, линии ввода/вывода общего назначения и другие периферийные устройства. Вычислительная мощность такого ЦП расходуется в основном на чтение CAN-шины, по данным с которой идет управление шаговыми двигателями и обновляются показания спидометра. Поэтому в большинстве разработок используются дешевые ЦП.
• Аналого-цифровые преобразователи (АЦП): эти устройства измеряют уровень топлива, степень заряженности батареи и выдают другую информацию, непосредственно представляя уровень напряжения в дискретном виде. АЦП могут также выявлять аварийные ситуации (например, падение напряжения резервной батареи) и обнаруживать случаи, когда по одному проводнику передаются множественные сигналы (например, резистивная цепочка на кнопке рулевого колеса). АЦП могут размещаться непосредственно на системном кристалле или быть реализованным в виде отдельной микросхемы.
• Драйверы светодиодных индикаторов / ЖК-панелей: в аналоговом кластере имеется большое число контрольных ламп, в том числе индикаторов поворота, непристегнутого ремня безопасности, малого уровня топлива, низкого уровня заряда батареи, низкого давления масла и необходимости обслуживания двигателя. ЦП или другой модуль может непосредственно управлять некоторыми из этих индикаторов, но чаще всего ЦП перехватывает сообщение на CAN-шине и посылает сигнал через канал ввода/вывода общего назначения для включения или выключения индикатора. В некоторых кластерах используется сегментный дисплей для спидометра или одометра/измерителя пройденного пути.
• Интерфейс CAN-шины: основная часть отображаемой информации получается кластером по CAN-шине. Для минимизации затрат в большинстве разработок используется ЦП со встроенным CAN-интерфейсом.

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

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

Будущее – за цифровыми кластерами

Переход к цифровым инструментальным кластерам влечет за собой значительные перемены, особенно это касается команды разработчиков с опытом создания аналоговых кластеров. Начнем с того, что для кластера нужен большой ЖК-дисплей, чаще всего размером 1280 х 480 пикселей. Таким количеством пикселей не может управлять 8-и или 16-битный ЦП, поэтому для кластера нужен 32-битный ЦП с тактовой частотой не менее 200 МГц. Для управления этим дисплеем нужен графический контроллер. Контроллер может быть реализован непосредственно на кристалле ЦП или в виде отдельной микросхемы. Для кластера по-прежнему нужен CAN-интерфейс и один или более АЦП для получения информации, выводимой на виртуальные измерительные приборы, в которых уже нет стрелочных индикаторов, а, значит, не нужны шаговые двигатели. Поскольку на экране могут отображаться любые индикаторы, нет необходимости в сегментных дисплеях или независимых драйверах светодиодных индикаторов и ЖК-панелей.

Самые большие изменения происходят со стороны программного обеспечения. Из-за того, что требуется визуализация графических элементов цифрового кластера, появляется потребность в ОСРВ. Кроме того, требуемый опыт работы с программным обеспечением выходит за рамки традиционных навыков работы со встраиваемыми системами.

Необходима ОСРВ

Когда команды разработчиков берутся за создание цифрового инструментального кластера, обычно выясняется, что гораздо проще использовать готовую ОСРВ, чем "написать собственную" ОС. Для получения изображений измерительных приборов, индикаторов, текстовых уведомлений и других компонентов программистам нужно вызывать процедуры графической библиотеки. Создание "доморощенной" графической структуры непрактично и дорого. Команда разработчиков может положиться на инструментальный набор элементов управления (виджетов) для упрощения реализации вращающегося одометра, системы меню или других специализированных элементов управления. Большинство стандартизованных графических библиотек пользуется преимуществами низкоуровневых примитивов ОС для загрузки графической библиотеки как разделяемого объекта, для доступа к аппаратному буферу кадров, управления прерываниями, выполнения динамического распределения памяти, доступа к таймеру и выполнения синхронизации потоков.

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

ОСРВ необходима цифровому кластеру также для того, чтобы гарантировать получение детерминированного отклика. В аналоговом кластере простой цикл задач работает хорошо, потому что каждая задача выполняется за короткий и фиксированный интервал времени. В цифровом инструментальном кластере время, необходимое для рисования объекта, может зависеть от углового положения, занимаемого стрелкой прибора, от ограничений графического конвейера или от элемента, рисуемого непосредственно перед объектом. В кластере может потребоваться сделать выборку из конкретного канала ввода/вывода или АЦП с точно заданной частотой, которая может быть изменена нестатической синхронизацией рисования.

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

В кластерном приложении абсолютно необходимо иметь малое время начальной загрузки. Пользователь не может ждать несколько секунд, пока появиться изображение спидометра или изображение с камеры заднего вида, чтобы увидеть дорогу при движении задним ходом. Самая большая задержка, которая допустима в данном случае, – это одна-две секунды. Соответственно, ОСРВ должна загружаться очень быстро. В ОСРВ QNX Neutrino предлагается несколько технологий начальной загрузки за жестко ограниченное время. Например, инженеры могут полностью пересмотреть последовательность начальной загрузки устройств и запускать драйверы шины передачи данных автомобиля параллельно с процессом загрузки ОС. На рис. 1 показан пример программной архитектуры цифрового инструментального кластера.

Рис. 1. На диаграмме показан пример программной архитектуры цифрового инструментального кластера

Другая квалификация при работе с новым программным обеспечением

Консервативные инженеры встраиваемых систем из мира аналоговых кластеров при переходе к программному окружению цифрового кластера должны будут сделать некоторые коррективы в своих действиях. Начнем с того, что переход на коммерческую ОСРВ требует использования полностью нового набора инструментальных средств. Далее, при переходе на 32-битное программирование на языке С инженеры должны избавиться от некоторых «плохих привычек», которые «пролезли» в кодовую базу. Например, выполнение прямого чтения памяти или использование предположения, что тип данных "int" имеет определенный размер. Инструменты контроля соблюдения стиля программирования могут упростить переход, хотя доведение кода до уровня, когда он компилируется без нарушения стиля программирования, может быть затратным по времени. Часто 8- или 16-битные ЦП требуют использования указателей на блок изменяемого размера (sized pointers) в стиле любимых когда-то сегментных регистров старого процессора 8086. В мире 32-битных приложений не требуются указатели такого типа, и инженеры должны убрать их из директив приведения типов (typecast) или #define.

Другие проблемы возникают скорее из-за склада ума инженеров, чем из-за самого кода. В отличие от статического распределения памяти, используемого в аналоговом кластере (никаких функций malloc или free), цифровой мир – больше и сложнее. Многие графические библиотеки и каркасы виджетов опираются на активное управление памятью. Инженеры должны смириться с тем, что нельзя предварительно выделить статическую память под каждый буфер, точнее, для этого нужно воспользоваться динамической памятью. В результате команда разработчиков должна тщательно проверять код для выявления всех возможных мест утечек динамической памяти, прежде чем система попадет в эксплуатацию. В ОС должны предоставляться инструменты, помогающие выполнять эти действия. Например, специализированные инструменты анализа в среде IDE QNX Momentics на базе платформы Eclipse позволяют инженерам обнаруживать трудно выявляемые утечки динамической памяти.

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

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

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

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

Критически важное для безопасности программное обеспечение

Программное обеспечение для цифрового инструментального кластера относится к категории критически важных для безопасности. Тем не менее, некоторые программные компоненты могут потребовать их частого изменения, если автопроизводитель собирается использовать одну и ту же базовую разработку в нескольких моделях автомобилей. Эти два фактора не так уж просто совместить. Лучший способ защиты – использовать программные компоненты среды исполнения, которые себя хорошо зарекомендовали в областях, связанных с безопасностью. Кроме того, команда разработчиков должна выбрать инструменты, которые помогут выявить ошибки еще на этапе проектирования или тестирования, а не после сдачи в эксплуатацию. Например, ОСРВ QNX Neutrino хорошо приспособлена для решения этой задачи, она прошла эксплуатационную проверку во многих жизненно-важных приложениях. В ней также используется микроядерная архитектура с защищенной памятью, в которой можно обнаруживать ошибки работы с памятью и другие системные проблемы быстрее, чем в ОС других архитектур.

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

API для работы с графикой

Для создания привлекательного и реалистично выглядящего измерительного прибора инженеры могли бы просто использовать приемы рисования с использованием пикселей и линий, но это было бы исключительно утомительно. Разумный подход состоит в использовании стандартизованного графического API, подобно OpenGL ES или OpenVG, в котором предоставляется набор инструментов для создания 3D-эффектов подсвечивания и затенения (см. рис. 2).

Рис. 2. 3-D графика может использоваться для создания привлекательных кластерных дисплеев.

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

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

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

Набор инструментов для разработки

В зависимости от структуры цифрового инструментального кластера инженеры могут использовать уже ранее созданные виджеты, например, иконки (индикаторы), дисплеи с вращающимися цифрами (для одометра, счетчика пройденного пути) и меню (переключатели с английской системы мер на метрическую, счетчик поездки А/В, статусного режима). Хотя инженеры и могут создавать все виджеты "на дому", существуют наборы инструментов конструирования от некоторых компаний, например Altia, Adobe или Electrobit, которые предоставляют предварительно подготовленные и отлаженные виджеты. Это может сэкономить много времени на этапе разработки.

Технология Adobe Flash может быть полезна для сокращения времени разработки. Она предоставляет среду, где художники-графики и промышленные дизайнеры могут разрабатывать концепцию продукта и тестировать его на РС. Запуск скомпилированного продукта Flash на кластерах, реализованных в среде ОСРВ, исключает необходимость в трансляции графики в другую среду, например, С или Java.

Современный подход использует гибкое изменение дизайна

Если сравнивать аналоговый и цифровой инструментальные кластеры, то последний предоставляет полную свободу изменения "на лету" отображаемой информации. Например, в цифровом инструментальном кластере возможно:

• информировать водителя о постоянно меняющихся дорожных условиях, показывая ограничения скоростного режима движения (см. рис. 3), уведомление об очевидных обледенениях трассы или об окружающих транспортных средствах;

  
  Рис. 3. На цифровом инструментальном кластере появляется индикация ограничения скорости до 100 км/час на текущем участке.

• настраивать цвет, фон или расположение приборов на дисплее;
• уменьшать отвлекаемость водителя путем приглушения яркости, удаления или корректировки расположения приборов, которые в данный момент не нужны водителю (см. рис. 4);

  
  Рис. 4. На этом цифровом инструментальном кластере приборы с ненужной в данный момент информацией переведены на второй план.

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

  
  Рис. 5. В цифровой инструментальный кластер включена обложка мультимедийного альбома (внизу справа) и инструкции для водителя при использовании навигатора (внизу слева).

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

Об авторе

Источник: http://autoelectronics.com/body_electronics/instrumentation/digital-instrument-clusters-0727/index.html