Как пишут программы для автомобилей

Время на прочтение
4 мин

Количество просмотров 57K

Сталкиваясь с реалиями машиностроительной промышленности, большинство разработчиков программного обеспечения не справляются – уж очень узкоспециализированы продукты, с которыми приходится работать. Это вам не создание программ для интернет-пользователей, компьютеров и даже не мобильные приложения, а потому новички чувствуют себя, как Томас из фильма «Бегущий в лабиринте». Посмотрите, примерно, 50 секунд трейлера – и вы поймете, какой шок испытывают те, кто имеет дело с разработкой ПО для автомобилей впервые.

Все, что у вас есть — это множество терминов и инструментов, о которых вы понятия не имеете. Когда во время собеседования в одной автомобильной компании я поинтересовался, какую IDE они используют, интервьюеру мой вопрос, мягко говоря, не понравился. Я привык к Visual Studio, и наивно надеялся, что здесь для разработки встроенного программного обеспечения понадобится что-то аналогичное. Я даже не представлял, что меня ожидало! Просто море мелких и серьезных (по сложности) инструментов, которым нужна была очередная жертва.

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

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

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

Какие темы мы рассмотрим?

• Как встроенное программное обеспечение повышает производительность автомобиля?
• Как встроенные приложения позволяют управлять автомобилем?
• Какие существуют типичные ограничения CPU?
• Как благодаря встроенным программам осуществляется процесс непрерывной обработки данных с датчиков?
• Как это программное обеспечение структурировано и как отдельные приложения взаимодействуют между собой для управления автомобилем?

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

Вы можете посмотреть видео, посвященное разработке электронной системы рулевого управления. Кстати, я тоже работал в этой команде.

Данная модель частично управляется программно. Частично означает, что специализированное ПО лишь помогает водителю, но полный контроль над системой имеет именно он.

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

Работу ПО обеспечивает крошечный процессор или, если говорить точнее, микроконтроллер, по сети подключенный к датчику.

Когда водитель поворачивает руль, благодаря датчику, который постоянно передает информацию о текущем угле поворота, ПО получает соответствующий сигнал. Например, если водитель поворачивает руль на 90 ° вправо, в течение секунды сигнал датчика обрабатывается по следующему принципу:

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

Электронный блок управления (ECU)

При условии, что встроенное программное обеспечение работает корректно, при повороте руля почти мгновенно изменяется положение зубчатой рейки.

Руль — синий, рулевая рейка — розовый (прим.)

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

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

Часть 2/2

Собственно из-за отсутствия времени решил пока написать про написание прошивки в сжатом виде. Позже когда со временим будет попроще напишу развернутый материал. А на первых парах сегодняшнего материала хватит для понимания что такое написания прошивки.

Все описанное в данной статье делается на ваш страх и риск. Ответственности за поврежденные вами ДВС и понесенные вами убытки не несу.

Начнем с того что прежде чем писать прошивку нам надо иметь:

1) Средства для проведения диагностики автомобиля. Кабеля Consult и диагностического ПО вполне достаточно.

2) ECU с возможностью их перепрошивки.

3) ПО для изменения прошивки ECU. (Я буду использовать Nistune, для моих нужд его триал версии вполне достаточно.)

4) Программатор чипов.

5) Двигатель в идеальном или близком к идеалу состояние.

Остановимся подробнее на состояние двигателя. Т.к. неисправный двигатель может «развалиться» или в лучшем случае свести к минимуму наши труды.
Что требуется от двигателя перед началом тюнинга:

1) Отсутствие кодов ошибок.
2) Свежий воздушный фильтр и исправный MAF.
3) Исправный и правильно настроенный TPS(ДПДЗ)
4) Бензонасос и топливный фильтр — новые или в идеальном состояние. Исправные и чистые форсунки.
5) Правильно выставленное зажигание по стробоскопу. Как правило для Nissan Это 15 градусов (реже 20).
6) Новые или в хорошем состояние свечи зажигания. Для турбомоторов Nisssan я бы рекомендовал свечи производства NGK с зазором 0,6мм

Так же не стоит при тюнинге расчитывать на чудо. К примеру если мы имеем полный сток SR20DET, то по MAF-у мы упираемся в потолок равный 290 лс, а по форсункам в 280. И превышение максимально возможных параметров для форсунок опасно для двигателя смертью.
И написание каждой прошивки свыше 280 лс рассчитывается индивидуально под приобретенные спеки снимающие потолок в 280 л.с.
Так даже для потолка стока в 280 л.с. я бы рекомендовал поставить бензонасос 255 л/ч.

Далее как выглядит написание прошивки в nistune. Собственно писать я её буду под сток двигатель с бустконтроллером, прямоток и нулевиком.

При запуске Nistune с начала выбираем модель под которую будет писаться прошивка. Это очень важный момент т.к. разные ECU имеют разные адресные карты и с «не родным» адресным файлом, ваша машина в лучшем случае просто не заведется.

Далее там появиться меня и ищем в нем свою платформу и двигатель. После выбора так же надо будет выбрать прошивку нашего двигателя.

После того как у нас откроется прошика мы сможем её редактировать. Прошивку тоже желательно выбирать согласно модели своего ECU.

Первым делом я направися во вкладку Limits. Она отвечает за отсечки по TPS, оборотам, скорости.

Изменение параметров не вызывает трудности. После клика мыши открывается не большое меню с бегунком которым и производится регулирование.
Soft Rev limit 1 — отвечает у нас за отсечку по оборотам когда дроссель полностью не открыт.
Hard Rev limit 1 — отвечает у нас за отсечку по оборотам когда дроссель полностью открыт. Не рекомендую эту отсечку трогать со стоковыми валами т.к. сток валы примерно при 7500 тысячах начинают активно деградировать.
Safety Rev limit — отвечает за отсечку оборотов при полностью закрытом дросселе.
Safety TP limit — отвечает за отсечку по допустимому открытию дросселя.
Speed limit 1 — отвечает за отсечку по скорости при полностью открытом дросселе.
Speed limit 2 — отвечает за отсечку по скорости когда дроссель полностью не открыт.

Я трогал только отсечку по скорости, поставил оба параметра в 250 км/ч.

Так же если есть необходимость можно изменить карту MAF и К константу при замене форсунок.

В нистюн это все автоматизированно. Если будете работать с другой программой константу К придется считать в ручную. Формула расчета замены форсунок не сложна (производительность старых форсунок / производительность новых форсунок) * константа старых форсунок = константа новых форсунок.

Т.к. у нас прямоток и нулевик, то нам нужно убрать в ECU ограничения что бы наши улучшения не свелись к нулю (да, да прямоток и нулевик без перепрошивки не дают некого прироста мощности, одни звуковые изменения)

Находим вкладку Limit tables

Min TPulse width — этот параметр отвечает за длительность впрыска топлива что бы двигатель не заглох когда вы после активного педалирования бросаете газ. Его можно не трогать.

Min TPulse width — этот параметр отвечает за максимальное время впрыска топлива. Это и есть один из ограничителей наших спеков типа нулевика и прямотока. Т.к. двигатель даже получая больше воздуха, в цилиндры не нальет топлива больше чем положено и сделает нулевик, и прямоток бесполезными. Тут можно начиная примерно с 2800 оборотов ставить 175. Не советую без тонкой настройки ставить максимальное значение в 255 т.к. вам скорее всего будет заливать свечи и взорвется выхлоп.

Load cut — отсечка по топливу/бусту. Вторая палка мешающая нашим спекам увеличить мощность нашего мотора. Из-за этого параметра при поступление воздуха больше чем указано мозгу он отсекает подачу топлива. Тут можно выставить везде 255 если вы собираетесь дуть в двигатель больше 1кг. Я ограничился так же 175 от 2800 оборотов.

В моем случае я на этом закончил. И сохранил прошивку сразу для записи её на чипы.

Но сохраняем в формате odd/even для 256 чипов. Если у вас ECU использует 512 чипы то нужно сохранять одним файлом.

После прихода некоторых спеков напишу про более подробное написание прошивки с расширением топливных карт и прочими интересными вещами.

Первое автомобильное программное обеспечение появилось в автомобилях еще в 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 для маневров торможения во время тест-драйва), настройки не выполня­ются во время фактических маневров тормо­жения. В этом случае калибровка в реальном времени все равно может сэкономить время посредством предотвращения любых преры­ваний выполнения программы и, соответ­ственно, снижения интервала между двумя тест-драйвами.

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

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

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

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

Сталкиваясь с реалиями машиностроительной промышленности, большинство разработчиков программного обеспечения не справляются – уж очень узкоспециализированы продукты, с которыми приходится работать. Это вам не создание программ для интернет-пользователей, компьютеров и даже не мобильные приложения, а потому новички чувствуют себя, как Томас из фильма «Бегущий в лабиринте». Посмотрите, примерно, 50 секунд трейлера – и вы поймете, какой шок испытывают те, кто имеет дело с разработкой ПО для автомобилей впервые.

Все, что у вас есть — это множество терминов и инструментов, о которых вы понятия не имеете. Когда во время собеседования в одной автомобильной компании я поинтересовался, какую IDE они используют, интервьюеру мой вопрос, мягко говоря, не понравился. Я привык к Visual Studio, и наивно надеялся, что здесь для разработки встроенного программного обеспечения понадобится что-то аналогичное. Я даже не представлял, что меня ожидало! Просто море мелких и серьезных (по сложности) инструментов, которым нужна была очередная жертва.

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

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

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

Какие темы мы рассмотрим?

• Как встроенное программное обеспечение повышает производительность автомобиля?
• Как встроенные приложения позволяют управлять автомобилем?
• Какие существуют типичные ограничения CPU?
• Как благодаря встроенным программам осуществляется процесс непрерывной обработки данных с датчиков?
• Как это программное обеспечение структурировано и как отдельные приложения взаимодействуют между собой для управления автомобилем?

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

Вы можете посмотреть видео, посвященное разработке электронной системы рулевого управления. Кстати, я тоже работал в этой команде.

Данная модель частично управляется программно. Частично означает, что специализированное ПО лишь помогает водителю, но полный контроль над системой имеет именно он.

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

Работу ПО обеспечивает крошечный процессор или, если говорить точнее, микроконтроллер, по сети подключенный к датчику.

Когда водитель поворачивает руль, благодаря датчику, который постоянно передает информацию о текущем угле поворота, ПО получает соответствующий сигнал. Например, если водитель поворачивает руль на 90 ° вправо, в течение секунды сигнал датчика обрабатывается по следующему принципу:

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

Электронный блок управления (ECU)

При условии, что встроенное программное обеспечение работает корректно, при повороте руля почти мгновенно изменяется положение зубчатой рейки.

Руль — синий, рулевая рейка — розовый (прим.)

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

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

Автор: ragequit

Источник

Программный код в автомобиле +17

Программирование микроконтроллеров, Автомобильные гаджеты, Транспорт, Блог компании НПП ИТЭЛМА

---

Рекомендация: подборка платных и бесплатных курсов Python — https://katalog-kursov.ru/

Требуется множество микропроцессоров, обрабатывающих 100 миллионов строк кода, чтобы обеспечивать работу машины премиум-класса (2009 год). И это в скором времени станет еще сложнее.

Система авионики в F-22 Raptor, реактивном истребителе военно-воздушных сил США, состоит примерно из 1,7 миллиона строк программного кода. F-35 Joint Strike Fighter, появившийся в 2010 году, требует около 5,7 миллионов строк кода для работы бортовых систем. А новому Boeing 787 Dreamliner требуется около 6,5 миллионов строк программного кода для работы систем бортового электронного оборудования.

Впечатляет, не правда ли? Но если вы недавно купили автомобиль премиум-класса, он, вероятно, содержит около 100 миллионов строк программного кода. Так говорит Манфред Брой, профессор информатики в Техническом университете Мюнхена, ведущий эксперт по программному обеспечению в автомобилях. Все это ПО запускается на 70-100 микропроцессорных электронных блоках управления (ECU), распределенных по всему кузову вашего автомобиля.

Альфред Катценбах, директор по управлению информационными технологиями в Daimler, сказал, что для радионавигационной системы в нынешнем Mercedes-Benz S-класса требуется более 20 миллионов строк кода. В автомобиле содержится почти столько же ECU, сколько в новом Airbus A380 (без учета развлекательной системы на борту). Программное обеспечение в автомобилях будет расти не только в количестве. Сложность ПО с каждым разом увеличивается все сильнее. В конце прошлого года исследовательская фирма Frost & Sullivan подсчитала, что для машин в ближайшем будущем потребуется от 200 до 300 миллионов строк программного кода.

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

«Автомобили больше не представляют собой только лишь батарею, распределитель или генератор переменного тока и карбюратор; они чрезвычайно современны по своей сложности», — говорит Thomas Little, профессор электротехники в Бостонском университете штата Массачусетс. Томас занимается разработкой интеллектуальных транспортных систем. «Преследуя цели экономии энергии, сокращения [выбросов] и повышения безопасности помимо прочего мы пришли к внедрению электроники».

Я недавно испытал эту сложность на себе. В прошлом году я купил новый автомобиль и был поражен, когда открыл руководство пользователя. В нем было 500 страниц. Еще 200 страниц объясняли работу GPS и радиосистем. Одной из новых рекламируемых функций было увеличение отдела для перчаток, но размеры, вероятно, были указаны где-то внутри бесконечного руководства.

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

Большую часть времени система подушек безопасности просто отслеживает состояние автомобиля. Но иногда подушки безопасности срабатывают, скажем, из-за столкновения нескольких транспортных средств. В таком случае у программного обеспечения в ECU, управляющего их раскрытием, есть от 15 до 40 миллисекунд, чтобы определить, «какие подушки безопасности активируются и в каком порядке», — говорит Брой.

В ближайшем будущем, по словам Броя, системы управления подушками безопасности будут использовать не только информацию о вероятности столкновения. Например, у BMW многие модели 2009 года оснащены системой BMW Assist. Эта система рассчитывает «риск серьезной травмы» на основе информации, полученной от контроллера подушки безопасности автомобиля и других его ECU. Аварийно-технические службы получают информацию не только о месте происшествия, но и о вероятности получения серьезной травмы пассажирами.

Количество программного обеспечения в автомобилях в наше время поражает.
Первый серийный ECU автомобильного микрокомпьютера представлял собой однофункциональный контроллер. Его использовали для электронного зажигания в 1977 году в General Motors в автомобиле Oldsmobile Toronado. В 1978 году GM предложили поставить свой Cadillac Trip Computer на Cadillac Seville. Компьютер представлял собой модифицированный микропроцессорный чип Motorola 6802. Он отображал информацию о скорости, топливе, поездке и двигателе. Однако микросхема выполняла другую функцию: GM использовали ее для проверки того, насколько хорошо микропроцессор может управлять несколькими функциями, такими как впрыск топлива, электронная синхронизация зажигания и круиз-контроль.

К 1981 году GM использовали микропроцессорное управление двигателем в производстве легковых автомобилей. Они обрабатывали около 50 000 строк кода. Другие автомобильные компании быстро последовали их примеру.

Jonas Bereisa, инженер GM, написал в 1983 году в статье IEEE Transactions по промышленной электронике, что «разработка программного обеспечения станет наиболее важным фактором в разработке новых продуктов». Он был чертовски прав. По оценкам Broy, более 80 процентов автомобильных инноваций происходят благодаря компьютерным системам. ПО стало основным источником стоимости в автомобилях, в том числе прейскурантной. Соотношение стоимости электроники и стоимости транспортных средств в процентах возросло с 5 процентов в конце 1970-х годов до 15 процентов в 2005 году (без учета затрат на окончательную сборку).
У гибридов количество ПО, необходимого только для одного управления двигателем, почти вдвое больше, чем у стандартного автомобиля. Соотношение стоимости электроники и стоимости транспортных средств у них приближается к 45 процентам. В течение 10 лет, по прогнозам некоторых экспертов, процентная доля стоимости электроники от стоимости транспортного средства вырастет до 50 процентов у обычных транспортных средств и до 80 процентов у гибридов.

Для современных автомобилей премиум-класса «стоимость программного обеспечения и электроники может достигать 35–40 процентов от стоимости автомобиля», — заявляет Брой. На разработку программного обеспечения приходится около 13–15 процентов от этой стоимости. Он говорит, что если каждая строчка разработанного программного обеспечения стоит 10$ — что очень мало — у автомобиля премиум-класса, одно только его программное обеспечение представляет собой инвестицию на сумму около миллиарда долларов.

John Voelcker, редактор IEEE Spectrum, написал в апреле 2007 года о гибридном автомобиле GMC Yukon и его двухрежимной автоматической коробке передач. Voelcker сказал, что «из всех рабочих часов затраченных на создание двухрежимной коробке передач… около 70 процентов… ушли на разработку управляющего программного обеспечения».

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

Из-за сложности кода возникают проблемы с надежностью. IBM утверждает, что примерно 50 процентов гарантийных расходов на автомобили в настоящее время связаны с электроникой и их встроенным программным обеспечением. По данным на 2005 год автопроизводителям в Соединенных Штатах это обошлось примерно в 350 долларов за один автомобиль, а европейским автопроизводителям в 250 долларов.

В 2005 году Toyota отозвала 160 000 своих гибридов Prius 2004 года выпуска и некоторые модели начала 2005 года из-за программной проблемы — автомобили глохли или внезапно останавливались. Время, необходимое для ремонта программного обеспечения, оценивалось примерно в 90 минут на одно транспортное средство — около 240 000 рабочих часов. Это обошлось им дорого.

Только в прошлом году было несколько отзывов автомобилей, связанных с проблемами программного обеспечения. Например, в мае 2008 года Chrysler отозвал 24 535 своих Jeep Commanders 2006 года из-за проблемы в программном обеспечении автоматической трансмиссии. Затем в июне Volkswagen отозвал около 4000 своих Passats и Passat Wagons 2008 года и около 2500 Tiguans из-за проблемы в программном обеспечении модуля управления двигателем. Эта проблема может привести к неожиданному увеличению оборотов двигателя в минуту при включении кондиционирования воздуха. В ноябре GM отозвала 12 662 из своих автомобилей Cadillac CTS 2009 года из-за проблемы с программным обеспечением в системе обнаружения пассажиров, которая могла отключить подушку безопасности пассажира, сидящего спереди, когда она должна быть включена, или включить ее, когда она должна быть отключена. Тем не менее, стоит отдать должное разработчикам автомобильного ПО, так как отзывов автомобилей из-за программного обеспечения не так много.

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

Несложно понять почему. «В автомобиле премиум-класса от 2000 до 3000 уникальных функций, связанных с программным обеспечением», — говорит Брой. Затем они объединяются в 250–300 функций, используемых водителем и пассажирами для управления системами автомобиля.

У большинства коммерческих самолетов есть межсетевые экраны между критически важными бортовыми системами и бортовыми развлекательными системами. У машин, в отличии от самолетов, происходит более сложная передача информации между электронными системами, используемыми для управления автомобилем, и системами, предназначенными для развлечения водителя и пассажиров. В бизнес-школе Wharton была опубликована статья под заголовком «Проблемы с автомобилем: стоит ли отозвать автомобильную промышленность США?». Несколько лет назад некоторые водители Mercedes обнаружили, что водительское кресло сдвигалось, если они нажимали определенную кнопку; проблема заключалась в том, что кнопка должна была управлять навигационной системой.

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

Broy сказал мне, что более 50 процентов ECU, которые механики заменяют в автомобилях, технически не содержат ошибок: у них нет проблем ни с аппаратным, ни с программным обеспечением. Механики заменяют ECU просто потому, что не могут починить машину иначе.

«Работники СТО и любители повозиться с машиной в гараже действительно находятся в тех реалиях, когда ремонт автомобиля слишком сложен и требует больших затрат[для них]», — говорит Брой. Удаленная диагностика и ремонт могут сделать механику ненужной для многих задач.

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

По словам Voelcker, он не удивится, если увидит, что бортовые системы, такие как BMW Assist, Ford Sync и GM OnStar, начнут регулярно передавать параметры рабочих данных обратно в централизованные системы, которыми управляют производители автомобилей. А производители в свою очередь будут анализировать данные для деталей, выходящих за пределы спецификации или для ПО, нуждающегося в обновлении. Водителя автоматически проинформируют о том, что автомобиль необходимо отвезти в ремонт.

Помимо контроля за состоянием своих внутренних деталей, автомобили начинают анализировать мир вокруг них. «Мы вступаем в эпоху, когда помимо того, что мы знаем, что происходит внутри автомобиля, мы используем такие вещи, как радары для обнаружения присутствия внешних объектов, лазеры для измерения расстояния у круиз-контроля, а также видео и ультразвук для обнаружения объектов позади тебя, — говорит Little. «Тенденция будет заключаться в том, чтобы извлекать информацию, которая относится к вашему автомобилю и к другим транспортным средствам. Затем эта информация будет использоваться для повышения безопасности. Например, автомобили перед вами сообщат вашему автомобилю, есть ли на шоссе лед или произошла ли авария.

Little говорит: «Мы отказываемся от маленьких частей контроля в обмен на безопасность. В какой момент вы и я будем готовы сказать: «Хорошо. Я не собираюсь вести машину, пусть она везет меня.

Об авторе

Robert N. Charette редактор IEEE Spectrum, самопровозглашенный «эколог риска», который исследует влияние меняющейся концепции риска на технологии и развитие общества. Charette также пишет IEEE Spectrum Online’s The Risk Factor.

Едем дальше

Манфред Брой и его коллеги написали исчерпывающую статью для февральского выпуска «Proceedings of the IEEE» под названием «Engineering Automotive Software» в феврале 2007 года. Она, вероятно, является одним из лучших обзоров на то, как разрабатывают и используют ПО для автомобилей.

Хорошую раннюю историческую точку зрения на использование ПО в автомобилях ищите в статье Jonas Bereisa, опубликованную в мае 1983 года в журнале IEEE Transactions по промышленной электронике под названием «Applications of Microprocessors in Automotive Electronics.». В ней представлена ??интересная хронология многих приложений микрокомпьютеров, которые использовались в автомобилях с 1977 по 1982 год.