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

 

 

 

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

 

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

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

 

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

 

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

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

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

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

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

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

 

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

 

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

 

 

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

 

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

 

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

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

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

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

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

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

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

 

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

 

AUTOSAR

 

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

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

 

 

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

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

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

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

 

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

 

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

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

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

 

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

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

 

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

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

 

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

 

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

 

ISO 9000 и TS 16949

 

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

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

 

CMMI

 

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

 

 

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

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

 

 

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

 

Automotive SPICE

 

Аббревиатура SPICE расшифровывается как «совершенствование процессов в разработке программного обеспечения и определение возможностей». Automotive SPICE — это «ав­томобильный» вариант международного стандарта ISO/IEC 15504 (Процессы при раз­работке программного обеспечения). Это модель для оценки, с учетом специфики про­екта, процессов, имеющих место при разра­ботке программного обеспечения. Она, как и 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 самым высоким уровнем интеграции безопасности.

 

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

 

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

 

 

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

 

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

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

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

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

 

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

 

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

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

 

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

 

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

 

Моделирование систем управления автомобиля

 

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

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

 

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

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

 

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

 

 

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

 

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

 

 

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

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

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

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

 

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

 

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

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

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

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

 

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

 

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

 

 

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

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

 

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

 

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

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

 

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

 

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

 

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

 

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

 

 

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

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

 

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

 

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

 

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

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

 

 

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

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

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

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

 

 

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

 

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

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

 

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

 

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

 

Процедура

 

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

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

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

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

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

 

 

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

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

 

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

 

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

 

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

 

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

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

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

 

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

 

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

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

 

РЕКОМЕНДУЮ ЕЩЁ ПОЧИТАТЬ: