Автомобильное программное обеспечение

Автомобильное программное обеспечение

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

  1. Разработка автомобильного программного обеспечения
  2. Требования к программному обеспечению в автомобиле
  3. Структура программного обеспечения в автомобилях
  4. Важные стандарты для автомобильного программного обеспечения
  5. Стандарты диагностики
  6. Процесс разработки про­граммного обеспечения
  7. Модели для описания процессов
  8. Контроль качества при разработке программного обеспечения
  9. Процессы разработки программного обеспечения для автомобилей
  10. Моделирование и имитация программных функций
  11. Проектирование и реализация программных функций
  12. Интеграция и тестирование программного обеспечения и ЭБУ
  13.  Калибровка программных функций
  14. Перспективы

Разработка автомобильного программного обеспечения

 

Любая разработка программного обеспечения имеет целью создание новой или улучшение существующей функ­ции. Такие функции создают дополнитель­ные плюсы и удобства для водителя, других пассажиров, механиков СТО, перевозчиков, обеспечивают соответствие требованиям за­конодательства, упрощают обслуживание или повышают эффективность проектирова­ния и изготовления. Техническая реализация может быть механической, гидравлической, электрической или электронной. Часто ком­бинируют сразу несколько этих технологий, а ключевую роль в реализации многих автомо­бильных новшеств все чаще играет электро­ника. Благодаря использованию электрики, электроники и программного обеспечения — логического ядра систем — экономически эф­фективно реализуются «интеллектуальные» функции привода, шасси и остальной части автомобиля.

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

Требования к программному обеспечению в автомобиле

 

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

Автомобильное программное обеспечение используется во многих вариантах автомобиля и даже мо­дельных рядах. Поэтому оно должно легко адаптироваться к соответствующим систе­мам. Для этого оно содержит параметры калибровки и программные карты. Их количество в автомобиле может достигать не­скольких десятков тысяч. Эти регулируемые переменные имеют множество взаимных за­висимостей. К тому же постоянно увеличива­ется степень связи отдельных систем между собой. Все чаще одна функция распределя­ется между несколькими системами или ЭБУ.

Программное обеспечение в автомобиле большей частью разрабатывается под кон­кретные области применения и интегрируется в единую систему. Его еще называют встроенным программным обеспечением, «зашитым» в постоянное запоминающее устройство. Многие функции часто раз­рабатываются и дорабатываются в течение длительного времени во многих уголках мира. Поскольку запасные части должны оставаться в наличии даже после заверше­ния производства конкретного автомобиля, электроника в автомобиле должна иметь относительно длительный срок службы — до 30 лет.

Из соображений экономии в ЭБУ зачастую содержатся микроконтроллеры с ограничен­ной вычислительной мощностью и ограни­ченным объемом памяти. Во многих случаях для этого требуются меры по оптимизации разработки программного обеспечения для сокращения количества необходимых аппа­ратных средств.

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

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

Структура программного обеспечения в автомобилях

 

Программное обеспечение в автомобиле со­стоит из множества компонентов. Как и в случае с персональным компьютером, различают «воспринимаемые функции» про­граммного обеспечения, прикладное про­граммного обеспечения и платформенное программное обеспечение, частично завися­щее от аппаратной части (рис.1 «Основные компоненты статичной программной архитектуры для микроконтроллеров и стандартизованных программных компонентов»). Взаимодей­ствие между всеми функциями определяется в архитектуре. Здесь могут быть различные отображения. Статичное отображение иерар­хически описывает функциональные группы, сигналы и распределение ресурсов. С другой стороны, функциональное отображение опи­сывает прохождение сигнала через различ­ные функции. Динамическое отображение, т.е. зависимое от времени, анализирует от­клик при выполнении различных задач. Уже на раннем этапе введены стандарты для обе­спечения взаимодействия между отдельными компонентами и их дальнейшего раз­вития. Наиболее важные стандарты описаны ниже.

Основные компоненты статичной программной архитектуры для микроконтроллеров и стандартизованных программных компонентов

Важные стандарты для автомобильного программного обеспечения

 

Органы и комитеты

Ассоциация стандартизации автоматизи­рованных и измерительных систем (ASAM) занимается стандартизацией в автомобиль­ной промышленности применительно к мо­делям данных, интерфейсам и синтаксису [5]. ASAM разработала различные стандарты для подключения ЭБУ к компьютеру или тер­миналу ввода данных. Стандарт ASAM-MCD1 (MCD — измерение, калибровка и диагно­стика) поддерживает различные протоколы передачи данных. При использовании спец­ификаций ASAM-MCD2 можно обращаться к двоичным данным в ЭБУ и одновременно отображать соответствующие данные в виде физических значений и обрабатывать их. Стандарт ASAM-MCD3 также позволяет ав­томатизировать такие процессы, например, для автоматической калибровки данных. Есть и другие стандарты ASAM, регламен­тирующие, к примеру, обмен функциональ­ными описаниями и данными.

Консорциум FlexRay разработал специфика­цию для полевой шины FlexRay для регули­рования по разомкнутому и замкнутому (с обратной связью) циклу в автомобилях [6]. Благодаря высокой скорости передачи дан­ных с запрограммированным арбитражем шины и отказоустойчивой конструкции она особенно подходит для использования в си­стемах активной безопасности и в системе привода.

Международная электротехническая ко­миссия (IEC) устанавливает стандарты в области электротехники и электроники [9]. IEC предлагает три системы анализа, с помо­щью которых можно проверить соответствие международным стандартам. IEC работает в тесном взаимодействии с международной организацией по стандартизации (ISO) [10], международным телекоммуникационным союзом (ITU) и многочисленными органами стандартизации (в том числе Институтом инженеров-электриков и электронщиков, IEEE) [11].

Ассоциация разработчиков программного обеспечения для автомобилей (MISRA) — ор­ганизация в автопромышленности, устанав­ливающая правила для разработки и внедре­ния надежного программного обеспечения в автомобильных системах [12]. Самым из­вестным является стандарт программирования MISRA-C, разработанный компанией MISRA. Он предписывает правила надежного программирования на языке С. Цель этого стандарта — избежать ошибок периода испол­нения из-за ненадежных конструкций языка С и возникновения слабых мест в структуре из-за непонимания между программистами, и защитить правильность выражений. Многие правила могут автоматически проверяться и учитываться при генерировании кодов.

Сообщество автомобильных инженеров (SAE) — международная научно-техническая организация, работающая в области технологий для обеспечения мобильности [13]. По­мимо прочего, оно устанавливает стандарты для автомобильной промышленности и спо­собствует обмену знаниями.

Стандартизационный орган «Открытые си­стемы и их интерфейсы для автомобильной электроники» (OSEK) появился из проекта немецкой автомобильной промышленности. Позже появилась инициатива «Vehicle Distributed Executive» (VDX) французской автомобильной промышленности. Стандар­тизация базовых компонентов программного обеспечения осуществляется под эгидой OSEK/VDX в следующих областях [14]:

  • связь (обмен данными внутри и между ЭБУ);
  • операционная система (выполнение в ре­альном времени программ ЭБУ и базовых услуг для других модулей OSEK/VDX);
  • управление сетью (конфигурация и кон­троль).

Архитектура программных платформ для япон­ской автомобильной промышленности (JasPar) [15] — инициатива для сокращения расходов и технологий разработки в автомобильной электронике. Она поощряет японские компа­нии совместно разрабатывать технологии, не имеющие отношения к конкуренции, такие как сетевые решения, сервисные функции и базо­вое программное обеспечение. JasPar работает в тесном сотрудничестве с AUTOSAR и FlexRay.

AUTOSAR

AUTOSAR — это ассоциация автопроизводите­лей, изготовителей ЭБУ и средств для разра­ботки, базового программного обеспечения для ЭБУ и микроконтроллеров. Цель AUTOSAR — упрощение обмена программного обеспечения на разных ЭБУ. Для этого была разработана стандартизированная программная архитектура со стандартизированными форматами описа­ния и конфигурации для встроенного автомо­бильного программного обеспечения. AUTOSAR определяет методы описания программного обеспечения в автомобилях, обеспечивающие возможность повторного использования, об­мена, масштабирования и интеграции компо­нентов программного обеспечения [16].

Главным для AUTOSAR является логическое распределение между базовым программным обеспечением (BSW) для конкретных ЭБУ и прикладным программным обеспечением, не­зависимым от ЭБУ (ASW) и их соединение по виртуальной системе шин (VFB) (рис.2 «Архитектура AUTOSAR»). Эта виртуальная шина также соединяет компоненты программного обеспечения, реализованные в разных ЭБУ. Таким образом, их можно смещать между разными ЭБУ без необходимости вно­сить изменения в сами компоненты программ­ного обеспечения. Это может быть полезно при оптимизации вычислительной мощности, требо­ваний к памяти и коммуникационной нагрузки.

Архитектура AUTOSAR

Функциональные программные компо­ненты (SWC) строго разграничиваются между собой и с базовым программным обеспече­нием. Они, как правило, содержат конкрет­ные алгоритмы управления, выполняемые во время прогона программы. Они сообщаются через интерфейс AUTOSAR с другими функ­циями и интерфейсами ЭБУ. Эти интерфейсы (API) определяются в описаниях SWC XML.

Среда прогона программы (RTE) обе­спечивает связь между функциональными компонентами программного обеспечения и соответствующим базовым программным обеспечением на ЭБУ. RTE адаптируется к конкретному ЭБУ и области применения. Она может в большой степени создаваться авто­матически из требований к интерфейсу.

Базовое программное обеспечение содержит программные части для конкретных ЭБУ — ин­терфейсы связи, диагностику и управление памятью. Базовое программное обеспечение также содержит слой сервисов. Это программ­ное обеспечение сочетает в себе программные компоненты для общих сервисных функций (SRV), связи (СОМ) и операционной системы, частично зависящей от используемого ЭБУ (OS) [4,14]. Последняя базируется на операционной система OSEK/VDX. В этой области ресурсы ЭБУ группируются и управляются таким образом, чтобы получить оптимальную сетевую под­держку, управление памятью, диагностику и пр. Используемые аппаратные средства заключа­ются в два слоя со взаимной зависимостью. Абстракция микропроцессора (MCAL) с прямым доступом к интерфейсным модулям ЭБУ про­должается в еще одном слое (абстракция ЭБУ). Драйверы сложных устройств (CCD) обеспечи­вают прямой доступ к ресурсам микроконтрол­лера для приложений с особыми требованиями к функциональности и выбору времени. Они также являются неотъемлемой частью базового программного обеспечения, т.е. прикладное про­граммное обеспечение можно разрабатывать независимо от аппаратной части, даже когда требуются услуги драйверов сложных устройств.

Помимо архитектуры ЭБУ, AUTOSAR ча­стично стандартизирует также методы раз­работки. Это прежде всего относится к структуре и зависимостям различных рабочих продуктов (например, файлов). Они нужны для создания выполнимых программ для со­ответствующих ЭБУ из разных описаний про­граммных компонентов.



Стандарты диагностики

 

Системы диагностики для проектирования и производства, ремонта и обслуживания авто­мобилей показали себя как очень затратные и негибкие. Они привязывают изготовителей к поставщикам и предотвращают простой об­мен данными в случае взаимодействия между компаниями. Поэтому был разработан ряд диагностических стандартов (например, [17] и [18]).

Рабочая группа Automotive Electronics (ASAM-AE) [5] разработала три специфика­ции для программных средств диагностики автомобилей, публикуемых в виде междуна­родных стандартов в группе стандартов ISO 22900 [19]:

  • интерфейс между средой прогона и устройствами связи (MCD-1Dи PDU-API, ISO 22900);
  • стандарт ODX для обмена данными диагно­стики, например, для передачи данных на тестер СТО (MCC-2D, ISO 22901);
  • интерфейс объектно-ориентированного программирования (MCD-3D, ISO 22900) для диагностических приложений, таких как, например, диагностика с подсказками.

Стандарт MCD-1C учитывает существую­щие стандартные инструменты, например, устройства для программирования ЭБУ.

В настоящее время в рамках проекта стандарта ISO разрабатываются требования к формату обмена, «Коммуникационный формат последовательной проверки на от­сутствие разрывов» (ОТХ), для создания, использования и обмена диагностическими программами.

Процесс разработки про­граммного обеспечения

 

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

Для удовлетворения приведенных выше требований в разработке программного обе­спечения для автомобилей неотъемлемой ча­стью разработки, в дополнение к технологии и инструментам, являются определяемые по­следовательности (процессы).

Модели для описания процессов

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

Принцип V-модели

Описанное здесь V-образное отображение процесса разработки используется во многих вариациях и степенях детализации. V-модель Федерации проектирования и реализации в сфере информационных технологий прави­тельства Германии [20] здесь описана не бу­дет.

Расширенная V-модель

V-модель распределяет этапы процесса, связанные непосредственно с разработкой, по лучам воображаемой буквы V, где по оси х отображается ход разработки, а по оси у — степень детализации соответствующего этапа (рис.3 «Расширенная V-модель»). Этап процесса можно описать необходимыми вводными переменными, процедурой, методами, ролями, инструментами, критериями качества и выходными пе­ременными. Этапы процесса, определяемые на левом луче латинской V, проверяются на ее правом луче. Эти этапы могут также про­ходиться несколько раз или быть поделены на части.

В расширенной V-модели можно рассмо­треть сопутствующие процессы — например, запрос, изменение, управление проектом и качеством.

Модели для оценки процессов

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

ISO 9000 и TS 16949

Ориентированный на процессы стандарт EN ISO 9000 регламентирует требования к си­стеме управления качеством. Акцент здесь делается на взаимодействия и интерфейсы. Изначально акцент делался на производство и интерфейсы заказчика.

Техническая спецификация ISO/TS 16949 была разработана североамериканской и европейской автомобильной промышленностью устанавливает требования к системам управления качеством. Цель этого стан­дарта — эффективное повышение качества системы и процессов для повышения сте­пени удовлетворенности клиентов, выявле­ния сбоев и рисков в производственном про­цессе и каналах сбыта, устранения их причин и проверки эффективности коррекционных и профилактических мер. Сутью специфика­ции является не выявление, а скорее предо­твращение сбоев. Соответствие ISO 9000 и TS 16949 можно проверить путем сертификации.

CMMI

CMMI — это модель для оценки и систе­матической оптимизации организаций- разработчиков и их процессов [21], изначально разработанная Институтом раз­работки программного обеспечения (SEI). Она описывает набор требований к процес­сам и их зависимости (рис.4 «Обзор процесс CMMI. ML-уровень зрелости»). CMMI обеспе­чивает рамки, реализация которых требует ориентированной на бизнес интерпретации и организации содержания. Она описывает то, что необходимо сделать. Организация должна соответствующим образом описать, «как» это необходимо сделать. Содержание модели CMMI базируется на передовых ме­тодах организации работы, т.е. «лучших ме­тодах». CMMI обеспечивает процедуру для оптимизации процессов на долгосрочную перспективу от пути развития организации до обучения организации.

Обзор процесс CMMI. ML-уровень зрелости

CMMI имеет много общего в плане содер­жания с ISO 9000/TS 16949. В этом контексте CMMI имеет большую степень детализации, в то время как ISO 9000/TS 16949 охватывает более широкий спектр областей применения.

CMMI различает пять уровней зрелости (ML) подразделения организации (рис.4,5 «Уровни зрелости CMMI»). Рассматриваются различные области про­цесса, в зависимости от уровня зрелости. Уровень зрелости считается достигнутым, когда все соответствующие области процесса отлажены и проверены системой оценки. Для выхода на более высокий уровень зрелости нужно еще раз проверить области процесса нижнего уровня.

Уровни зрелости CMMI

CMMI используется в качестве оптимизационной-оценочной модели для организаций-разработчиков и обеспечивает хорошую поддержку при оптимизации про­цессов во всех подразделениях организации и оценке поставщиков.

Automotive SPICE

Аббревиатура SPICE расшифровывается как «совершенствование процессов в разработке программного обеспечения и определение возможностей». Automotive SPICE — это «ав­томобильный» вариант международного стандарта ISO/IEC 15504 (Процессы при раз­работке программного обеспечения) [22]. Это модель для оценки, с учетом специфики про­екта, процессов, имеющих место при разра­ботке программного обеспечения. Она, как и CMMI, концентрируется на требованиях к систематической разработке. Поэтому содер­жание моделей Automotive SPICE и CMMI очень похоже. Automotive SPICE больше кон­центрируется на требованиях к уровню и дает меньше возможностей для ориентированной на бизнес интерпретации требований. Automotive SPICE фокусируется (в настоящее время) только на программном обеспечении и только на отдельных проектах. Напротив, области применения CMMI шире и охваты­вают любые работы и услуги в сфере разра­ботки и руководство ими. Automotive SPICE используется автопроизводителями в каче­стве модели для оценки проектов и постав­щиков в области разработки программного обеспечения.

Оценка процессов выполняется с помощью двухразмерной модели. Понятие «размер процесса» служит для определения и выбора анализируемых процессов, а «размер уровня зрелости» — для определения и оценки их со­ответствующей возможности. Размер уровня зрелости состоит из шести ступеней уровня зрелости — «не завершено», «выполнено», «проконтролировано», «установлено», «предсказуемо» и «оптимизация».

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

 

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

ISO 61508 и TS 26262

В настоящее время автомобильная промыш­ленность разрабатывает стандарт ISO 26262 (Транспортные средства — функциональная безопасность) для проектирования имеющих отношение к безопасности электрических и электронных систем в автомобилях на базе стандарта IEC 61508 (Функциональная безо­пасность электрических / электронных / про­граммируемых электронных систем, имею­щих отношение к безопасности). Он включает в себя требования и к продукту, и к процессу разработки, и охватывает концепцию, проек­тирование, разработку, реализацию, запуск, обслуживание, модификацию, выключение и демонтаж как самой системы, имеющей от­ношение к безопасности, так и систем, умень­шающих риск. Стандарт обозначает эти этапы в целом как «полный жизненный цикл безо­пасности». Продукты делятся на уровни инте­грации безопасности SIL1 — SIL 4 (ISO 61508) и автомобильные SIL, ASIL А — ASIL D (ISO 26262). SIL 1 и ASIL А, являются самым низ­ким, a SIL 4 и ASIL D самым высоким уровнем интеграции безопасности.

Процессы разработки программного обеспечения для автомобилей

 

Междисциплинарная кооперация в разра­ботке (например, между разработкой при­вода и электроники), распределенная разра­ботка (например, между поставщиком и автопроизводителем или разработка в раз­ных местах) и длительные жизненные циклы элементов программного обеспечения тре­буют общего понимания задач в целом. На­пример, при проектировании автомобильных функций управления с обратной связью и без нее, также должен обеспечиваться общий обзор всех требований к надежности и безо­пасности, а также аспектов реализации про­граммного обеспечения. Для этого во многих областях используется разработка программ­ного обеспечения на базе моделей (рис.6 «Этапы разработки программных функций на основе моделей»).

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

 

Разработка программного обеспечения на базе моделей

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

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

Для реализации заданных функциональных моделей в качестве программных компонентов для ЭБУ можно использовать методы автома­тизированного генерирования кода. Поэтому функциональные модели должны содержать дополнительную информацию о разработке программного обеспечения. Сюда могут отно­ситься меры по оптимизации, зависящие от характеристик продукта, необходимых элек­тронной системе. Автоматизированное генери­рование кода также гарантирует последова­тельность качественных характеристик кода.

На следующем этапе виртуальные модели среды, при необходимости дополняемые ре­альными компонентами, такими как фор­сунки, имитируют среду ЭБУ, тем самым по­зволяя проводить циклические лабораторные испытания формата «In-the-Loop». По срав­нению с испытаниями на стенде и на дороге они повышают гибкость и глубину испыта­ний, упрощая их воспроизводимость. Калибровка функций программного обеспече­ния в электронной системе должна учитывать настройки, относящиеся к конкретному авто­мобилю — например, параметры, записанные в виде характеристических значений, кривых и карт этих функций. Во многих случаях это сопо­ставление происходит лишь на более поздней стадии разработки; зачастую прямо в автомо­биле во время работы систем. Однако усилива­ется тенденция к более ранней (предваритель­ной) передаче данных; т.е. уже на ранних этапах разработки как можно более реалистичные ка­либровочные данные определяются с помощью моделей или эмпирических значений. Из-за множества калибровочных переменных и вза­имной зависимости для калибровки требуются подходящие процедуры и инструменты, потому что в конечном итоге качество калибровки, т.е. точная адаптация программного обеспечения к автомобилю, определяет степень использо­вания потенциала программного обеспечения.

Функциональные сети и сети ЭБУ

Эта процедура может также применяться к разработке функциональных сетей и сетей ЭБУ. Однако в этих случаях появляются до­полнительные аспекты, например:

  • комбинации смоделированных, виртуаль­ных компонентов и функций, уже реализо­ванных в коде ЭБУ;
  • комбинации смоделированных, виртуаль­ных и реализованных механических ком­понентов и устройств.

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

Моделирование и имитация программных функций

 

Моделирование

Для моделирования систем управления с об­ратной связью и без обратной связи следует по возможности использовать блок-схемы. В этих схемах для отображения отклика компонентов используются блоки, а для ото­бражения потока сигналов между блоками — стрелки (рис.7 «Моделирование с блок-схемами и имитацией»). Поскольку большинство систем многовариантны, то все сигналы обычно представлены в виде векторов. Они классифицируются на:

  • измерительные переменные или переменные обратной связи у;
  • выходные переменные с управлением без обратной связи или с обратной связью u*
  • контрольные или заданные переменные w;
  • значения, задаваемые водителем w*;
  • переменные с управлением без обратной связи или с обратной связью у*:
  • регулируемые переменные u
  • значения возмущений z

Блоки классифицируются на:

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

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

Моделирование с блок-схемами и имитацией

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

Создание прототипа быстрого управления в этом контексте включает в себя все методы для ранней реализации спецификаций для функций управления без обратной связи или с обратной связью в реальном автомобиле. Для этого в испытании должны быть реализованы смоделированные функции управления без обратной связи или с обратной связью. В каче­стве платформы для реализации программ­ных частей функций управления без обратной связи или с обратной связью можно использо­вать экспериментальные системы (рис.8 «Создание прототипа быстрого управления программных функций в реальном автомобиле»).

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

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

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

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

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

Процедура обхода

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

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

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

Можно также скомбинировать обход от­дельных частей программного обеспечения с полной поддержкой всего программного обеспечения в целом, что повышает гибкость.

Приложения обхода

Приложения обхода подходят для раннего те­стирования дополнительной или модифициро­ванной программной функции автомобильного ЭБУ. Новая или модифицированная программ­ная функция определяется моделью и рабо­тает в экспериментальной системе. Для этого требуется ЭБУ, способный выполнять базовые функции программного обеспечения, поддер­живать все необходимые генераторы заданных значений, датчики и исполнительные органы и обеспечивать интерфейс обхода для экспери­ментальной системы. Новая или модифициро­ванная программная функция разрабатывается с помощью создания прототипа быстрого управления. В этом случае она выполняется в экспериментальной системе (рис.9 «Разработка прототипа с системой обхода»).

Разработка прототипа с системой обхода

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

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

Приложение с полной поддержкой

 

Разработка прототипов с полной поддержкойЕсли в автомобиле должна тестироваться со­вершенно новая функция, а ЭБУ с интерфейсом обхода нет, то испытания можно провести с по­мощью приложения «с полной поддержкой». В этом случае экспериментальная система должна поддерживать все генераторы заданных значений, датчики и интерфейсы исполнитель­ных органов для данной функции. Поведение функции в реальном времени также должно быть определено и гарантировано экспери­ментальной системой (рис.10 «Разработка прототипов с полной поддержкой»). Вообще, это делается операционной системой реального времени на компьютере с полной поддержкой.

Виртуальное создание прототипов

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

Проектирование и реализация программных функций

 

На основании спецификации данных на ста­дии проектирования необходимо учесть функциональное поведение программной функции и ее поведение в реальном времени, все технические детали сети ЭБУ, реализо­ванный микроконтроллер и архитектуру про­граммного обеспечения. Тогда окончатель­ная реализация программных функций может быть определена и осуществлена на базе программных компонентов (рис.11 «Реализация функции управления с обратной связью и без обратной связи с помощью сети ЭБУ»).

Реализация функции управления с обратной связью и без обратной связи с помощью сети ЭБУ

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

Создание кода и сопутствующих данных (данные для документации, управление вари­антами или предварительная передача дан­ных калибровки) часто выполняются авто­матически в соответствии с установленными стандартами.

Интеграция и тестирование программного обеспечения и ЭБУ

 

Требования

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

Интеграция компонентов — это точка синхронизации для разработок всех отдельных ком­понентов. Интеграционное, системное и прие­мочное тестирование не могут быть выполнены до тех пор, пока не будут доступны все компо­ненты. Для ЭБУ это означает, что программные функции могут тестироваться только при на­личии всех компонентов в системе автомобиля (ЭБУ, генераторов заданных значений, датчи­ков, исполнительных механизмов и системы). Использование циклических систем тестирова­ния формата In-the-Loop в лаборатории позво­ляет заранее проверять ЭБУ в виртуальной среде тестирования при отсутствии фактиче­ских периферийных компонентов (рис.12 «Интеграция и тестирование ЭБУ с помощью циклической испытательной системы»).

Интеграция и тестирование ЭБУ с помощью циклической испытательной системы

Это позволяет проводить и автоматизиро­вать испытания в воспроизводимых лабора­торных условиях с высоким уровнем гибкости. В отличие от испытаний на стенде или в реальном автомобиле можно протестировать полный, неограниченный спектр рабочих со­стояний (например, ЭБУ двигателя можно протестировать при любой нагрузке и любых оборотах). Износ автомобиля и ситуации сбоев имитируются легко и позволяют про­тестировать функции контроля, диагностики и обеспечения безопасности. Допуски ком­понентов (например, в генераторах заданных значений, датчиках и исполнительных ор­ганах) можно имитировать таким образом, чтобы можно было проверять надежность функций управления с обратной связью и без обратной связи.

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

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

На рис.12 ЭБУ изображены в виде «чер­ного ящика». Поведение функций ЭБУ можно оценить только на основе входных и выход­ных сигналов w, у и u*. Этого изображения в виде «черного ящика» достаточно для простых программных функций. Однако для тестирования более сложных функций тре­буется интеграция процедуры измерения для внутренних промежуточных переменных ЭБУ. Эта технология измерения также называется инструментальным методом. Тестирование диагностических функций также требует доступа к запоминающему устройству неис­правностей через диагностический интерфейс ЭБУ, а для этого требуется интеграция измерительно-диагностической системы (рис.13 «Интеграция и тестирование ЭБУ в реальном автомобиле»).

Интеграция и тестирование ЭБУ на реальном автомобиле

Циклические испытательные системы

При циклических испытаниях встроенная электронная система подключается через ин­терфейсы к реальной (датчики, исполнитель­ные органы) или виртуальной (математиче­ские модели) среде. Реакция системы анализируется и вводится обратно в систему. В зависимости от типа испытательных образ­цов различают следующие испытательные системы:

  • В случае циклических испытаний модели (Model-in-the-Loop, MiL) тестируется функциональная модель программного обеспечения. Модель запускается на ин­струментальном компьютере систем авто­матизированного проектирования.
  • В случае циклических испытаний ПО (Software-in-the-Loop, SiL) тестируется программный код. Он запускается на инструментальном компьютере систем авто­матизированного проектирования.
  • В случае циклических испытаний функции (Function-in-the-Loop, FiL) тестируется про­граммный код. Однако в отличие от SiL, он прогоняется на конечном устройстве. Связь между программным обеспечением и моделью среды выполняется посред­ством ловушек и эмулятора.
  • В случае циклических испытаний аппа­ратной части (Hardware-in-the-Loop, HiL), весь ЭБУ проверяется посредством ин­терфейсов ввода-вывода. Также исполь­зуются сочетания FiL и HiL. В качестве имитационных компьютеров все больше используются персональные компью­теры.

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

Калибровка программных функций

 

Процедура

Любая электронно-управляемая автомобильная система может лишь тогда развит свою спо­собность, когда она оптимально адаптирована к соответствующему типу автомобиля. Чтобы программные функции можно было использо­вать в как можно большем количестве вариан­тов автомобилей, они содержат регулируемые параметры. Адаптация этих параметров к соответствующему варианту автомобиля и к каж­дому режиму работы (например, холодный ре­жим работы, экстремальная жара или высота) называется калибровкой. Для достижения нуж­ного уровня функциональности в автомобиле в целом необходимо использовать множество характеристических значений, кривых и про­граммных карт — калибровочных данных.

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

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

Калибровка выполняется в лаборатории на стендах для двигателя и автомобиля во время испытаний автомобиля и в реальных условиях на испытательных маршрутах. В дополнение к измерительно-диагностической системе часто требуется калибровочная система для кали­бровки внутренних параметров ЭБУ, например, характеристических кривых и голограммных карт). По завершении калибровки произво­дится комплексная проверка данных. Затем эти значения записываются в стираемую про­граммируемую постоянную память (EPROM) или флэш-память последовательных ЭБУ.

Во время калибровки значения параметров должны быть регулируемыми. Поэтому си­стема калибровки состоит из одного или бо­лее ЭБУ с подходящим интерфейсом измерительно-диагностической системы (рис.14 «Принцип работы измерительно-калибровочных инструментов»). В дополнение к использованию в автомобилях, измерительно-диагностические и калибровочные системы можно также ис­пользовать в циклических испытательных системах и на испытательных стендах.

Принцип работы измерительно-калибровочных инструментов

Изменения значений параметров, напри­мер, значений характеристической кривой, поддерживаются в калибровочной системе редакторами. Они также могут работать на уровне реализации (т.е. с примененными зна­чениями) или на уровне физической специ­фикации. Соответственно, измерительная система преобразует записанные значения в физическое представление или представ­ление реализаций. На рис.14 показан пример физического уровня и уровня реализации для характеристической кривой и записанного сигнала измерения.

При работе с системами калибровки обычно можно выбрать либо автономную калибровку, либо калибровку в реальном времени.

Автономная калибровка

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



Калибровка в реальном времени

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

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

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

Перспективы

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

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

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

Список литературы:

[1 ] Konrad Reif: Automobilelektronik — Eine Einfuhrung fur Ingenieure, 3rd Edition, Vieweg-Verlag, 2009.

[2] Jorg Schauffele, Thomas Zurawka: Automotive Software Engineering — Grundlagen, Prozesse, Methoden und Werkzeuge, 4th Edition, Vieweg-Verlag, 2010.

[3] Werner Zimmermann, Ralf Schmidgall: Automobilelektronik — Bussysteme in der Fahrzeugtechnik: Protokolle und Standards, 3rd Edition, Vieweg-Verlag, 2008.

[4] Robert Bosch GmbH: Autoelektrik/ Autoelektronik, 5th Edition, Vieweg-Verlag, 2007.

[5] Сайт ASAM: http://www.asam.de/

[6] СайтFlexray: http://www.flexray.com/

[7] Сайт LIN: http://www.lin-subbus.org/

[8] Сайт NEXUS 501, форум: http://www.nexus5001 .org/

[9] Сайт IEC: http://www.iec.ch/

[10] Сайт ISO: http://www.iso.org/

[11] Сайт IEEE: http://www.ieee.org/portal/site

[12] Сайт MISRA: http://www.misra.org.uk/

[13] Сайт SAE: http://www.sae.org/

[14] Сайт портала OSEK VDX: http://www.osek-vdx.org/

[15] Сайт JasPar: http://www.jaspar.jp/enghsh/

[16] Сайт AUTOSAR: http://www.autosar.org/

[17] ISO 14230: Road Vehicles Diagnostic Systems — Keyword Protocol 2000,1999.

[18] ISO 15765: Road Vehicles Diagnostic Systems — Diagnostics on CAN, 2000.

[19] ISO 22900: Road vehicles — Modular vehicle communication interface (MVCI) — Hardware design requirements.

[20] V-model-f IABG: http://www.v-modell.iabg.de/

[21] Сайт CMMI: http://www.sei.cmu.edu/cmmi/

[22] Сайт Automotive SPICE: http://www.automotivespice.com/

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *