на каком языке пишут по для автомобилей

Чиптюнинг часть3: написание прошивки

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

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

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

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 чипы то нужно сохранять одним файлом.

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

Источник

Какой язык программирования учить прямо сейчас: 9 самых востребованных

Самые востребованные языки программирования

Язык программирования — это набор лексических, синтаксических и семантических правил, которые придумали люди, чтобы создавать программы. Изучить язык до начального уровня можно за 6–10 месяцев, но если ошибиться с выбором, язык может устареть, а вы потеряете время и деньги.

Чтобы отслеживать востребованность языков программирования, компании составляют специальные рейтинги. Преподаватель онлайн-школы цифрового творчества и программирования для детей «Кодабра» Николай Ведерников выбрал языки, которые занимают высокие места в рейтингах TIOBE и IEEE. В первый рейтинг попадают языки, на которых написано больше всего строк кода, для второго используют чуть больше критериев. Например, популярность на сайтах для поиска работы, упоминания в сервисах для программистов и соцсетях.

Самые востребованные языки программирования:

Стоит ли учиться программированию на C

C — один из самых старых и популярных языков программирования. Он «легкий» и быстрый, поэтому его используют там, где нужна высокая производительность. Например, для создания драйверов, операционных систем или ПО для микроконтроллеров. При этом C сложно изучить — многое приходится писать с нуля. Если сравнивать языки программирования с автомобилями, то C — гоночный болид, неудобный на городских дорогах, но очень быстрый.

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

Сколько платят программисту. В Москве разработчик на C получает в среднем от 100 тыс. до 250 тыс. руб. В других городах зарплаты меньше — от 50 тыс. до 200 тыс. руб.

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

Стоит ли учиться программировать на Java

Java — кроссплатформенный язык с большим количеством библиотек и большим сообществом разработчиков. Кроссплатформенность — это возможность написать программу один раз и сразу пользоваться ей на нескольких операционных системах: Windows, Linux и MacOS. Благодаря библиотекам Java подойдет практически для всего: работы с графикой, звуком, создания небольших игр. А в большом сообществе начинающий разработчик легко найдет готовые куски кода для разных задач и ответы почти на любые вопросы.

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

Где используют. Java — это язык для всего. На нем пишут мобильные приложения для Android, программы для микроволновых печей и серверы. Для разработки мобильных приложений сейчас все активнее используют язык Kotlin. Но на Java уже написали очень много приложений, которые придется обслуживать и обновлять.

Сколько платят программисту. Зарплаты Java-разработчиков не сильно отличаются от обычных зарплат программистов — от 100 тыс. до 250 тыс. руб. в Москве.

Стоит ли учиться программировать на Python

Python — логичный и относительно простой язык с минималистичным синтаксисом. У него небольшой набор основных правил, язык легко читать и писать на нем не сложно. Разработчики написали для Python множество библиотек, поэтому вы можете использовать готовые решения в своих проектах. Главный минус Python — его невысокая скорость. Программы на нем будут работать в среднем медленнее, чем на других языках.

Где используют. Чаще всего на Python создают серверы, обрабатывают данные и разрабатывают нейронные сети. После изучения Python можно работать бэкенд-разработчиком или разработчиком в сфере data science. С помощью Python можно «прикрутить» неочевидные функции к программам — это его главное удобство. Например, создать нейронную сеть для определения степени поражения легких, а заодно в этой же программе сделать просмотр снимков КТ.

Сколько платят программисту. Разработчик в крупной компании в Москве, знающий Python, зарабатывает от 100 тыс. до 250 тыс. руб. При этом спрос на разработчиков в сфере data science растет, поэтому можно рассчитывать даже на более высокую оплату.

Зачем изучать. С помощью Python можно создать бота для мессенджеров или социальных сетей. Или написать программу для парсинга — поиска и переноса информации с разных сайтов в один документ. Такая программа пригодится дизайнерам и журналистам.

Стоит ли учиться программировать на C++

С++ — кроссплатформенный язык семейства C с расширенными функциями.

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

Где используют. Чаще всего на С++ создают операционные системы, драйверы и утилиты. Делают популярные десктопные приложения серий Adobe и Office. Из-за высокой скорости и производительности C++ используют для разработки компьютерных игр. Например, на нем написан популярный движок Unreal Engine.

Сколько платят программисту. В регионах разработчик на C++ зарабатывает от 50 тыс. до 150 тыс. руб., в Москве — от 100 тыс. до 250 тыс. руб. Зарплата зависит не только от города, но и от сферы — в геймдеве можно заработать больше, чем в разработке системных приложений.

Зачем изучать. C++ плохо подходит для решения простых «домашних» задач, но с него можно начать обучение языкам, чтобы понять их структуру и принципы. Если решили изучать, запаситесь терпением — с С++ в полной мере работает принцип «тяжело в учении — легко в бою».

Стоит ли учиться программировать на C#

C# (си-шарп) — язык, изначально придуманный компанией Microsoft, чтобы создавать приложения под Windows. Это объектно-ориентированный язык — его сложнее изучать, но проще использовать, например, меньше писать одинаковый код. С помощью С# можно работать с платформой WPF, которая помогает создавать «красивые» оконные приложения. Например, последние версии MS Office.

Где используют. Чаще всего на C# пишут приложения для Windows и создают компьютерные игры. Например, на C# работает популярный движок Unity. Кроме того, на нем можно разрабатывать системные приложения и создавать библиотеки для С++.

Сколько платят программисту. В регионах разработчики на С# получают от 35 тыс. до 130 тыс. руб., в Москве — от 100 тыс. до 250 тыс. руб.

Зачем изучать. С помощью C# можно создать оконное приложение для Windows, например, калькулятор или небольшую игру. Но изучать его сложнее, чем языки для создания мобильных приложений.

Стоит ли учиться программировать на JavaScript

JavaScript — быстрый кроссплатформенный язык для веб-разработки. С помощью кода на JavaScript разработчик «говорит» странице, как она будет реагировать на действия пользователя. С помощью JS можно показывать пользователю информацию без перезагрузки страницы — так работают выпадающие меню, всплывающие окна, оконные клавиатуры.

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

Где используют. JS постоянно используют для веб-разработки. На нем удобно создавать мобильные и десктопные приложения, которые будут работать через браузер. Например, Notion, Discord, Visual Studio Code.

Сколько платят программисту. Разработчик на JavaScript в Москве зарабатывает от 140 тыс. до 300 тыс. руб.

Зачем изучать. С помощью JS можно создать простой сайт или модуль для него, работающий с запросами клиента. Например, онлайн-калькулятор.

Стоит ли учиться программировать на PHP

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

Где используют. С помощью PHP создают программы, которые работают на сервере и помогают отправлять почту с сайта, взаимодействовать с базами данным. PHP облегчает работу интернет-магазинов — можно не создавать 1 тыс. одинаковых страниц, а генерировать их автоматически из базы данных по запросу клиента.

Сколько платят программисту. В регионах PHP-разработчик получает от 50 тыс. до 120 тыс. руб., в московских компаниях — от 80 тыс. до 220 тыс. руб.

Зачем изучать. Со знанием PHP легко начать карьеру разработчика. Такой разработчик сможет найти работу, даже если у него мало опыта.

Стоит ли учиться программировать на R

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

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

Где используют. Чаще всего с помощью R обрабатывают данные в научных исследованиях. На нем создают нейронные сети.

Сколько платят программисту. Разработчики и дата-аналитики, использующие R, зарабатывают от 100 тыс. до 200 тыс. руб. Точная сумма зависит от типа компаний — иногда в научных проектах, получающих международные гранты, можно заработать больше.

Зачем изучать обычным людям. Не стоит.

Стоит ли учиться программировать на Arduino

Arduino — это упрощенный диалект C++, на котором пишут только программы для контроллеров Arduino. Но вот эти контроллеры используют почти везде — от устройств для автоматического полива до полноценных систем «умный дом» и разнообразных роботов.

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

Где используют. Специалисты, знающие Arduino, могут работать инженерами-электронщиками и разработчиками ПО для микроконтроллеров. Иногда — в школах роботехники.

Сколько платят программисту. В Москве инженеры-электронщики зарабатывают от 50 тыс. до 120 тыс. руб., преподаватели — от 30 тыс. до 100 тыс. руб.

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

Какие языки теряют актуальность

Сомнительная идея изучать Perl в 2021 году, — считает ИТ-предприниматель и идейный вдохновитель школы программирования для детей CODDY Оксана Селендеева. Perl — язык программирования для системного администрирования, веб-разработки, игр. У Perl-разработчиков довольно высокая зарплата — 150 тыс. ₽ в месяц, но начиная с 2017 года вакансий для таких разработчиков почти нет. Лучше обратить внимание на Python. На нем выполняют те же задачи, но язык в 2021 году намного более востребован в ИТ-сфере.

Теряют актуальность и другие языки: Fortran, Objective-C, Haskell, Visual Basic.

По версии Stack Overflow, самые «страшные» языки в 2020 году — VBA, Objective-C, Perl, Assembly, C. «Страшные» означают, что большинство разработчиков, которые сейчас пишут код на этих языках программирования, не планируют продолжать с ними работать.

Общие тренды ИТ-сферы вне зависимости от языков программирования

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

Растет популярность мобильной разработки и машинного обучения. Мобильная разработка стала привычным делом за несколько лет. Многие компании запускают только мобильные приложения, не думая об их браузерных и десктопных версиях. Из-за этого сильнее разрабатывают стандарты мобильной разработки. С одной стороны, это усложняет работу, с другой — сообществу выгодно обучить новичков этим стандартам.

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

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

Работодатели хотят посмотреть портфолио на GitHub. Если раньше при найме сотрудника работодатели смотрели приложения, к которым программист приложил руку, то теперь даже непрофессионалы все чаще хотят увидеть код. На Гитхабе можно посмотреть все проекты разработчика, увидеть, как он думает и пишет, как развивался и рос.

Программирование молодеет. Дети и подростки изучают программирование на онлайн-курсах или самостоятельно. Из-за этого уже в 13–15 лет они могут писать приложения, выкладывать их в Appstore или GooglePlay и даже зарабатывать деньги. Некоторые из них так начинают карьеру разработчика и конкурируют с выпускниками вузов и более старшими коллегами.

Еще пять статей о программировании

В Telegram-канале «Списать не получится» мы еще больше рассказываем о трендах в образовании и о том, как учиться в течение всей жизни и делать это с удовольствием. Подписывайтесь!

Источник

Автомобильный справочник

для настоящих любителей техники

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ассоциация стандартизации автоматизи­рованных и измерительных систем (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 в следующих областях:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Процедура

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник