На каком языке пишется по для автомобилей
Чиптюнинг часть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 чипы то нужно сохранять одним файлом.
После прихода некоторых спеков напишу про более подробное написание прошивки с расширением топливных карт и прочими интересными вещами.
Программный код в автомобиле
(Публикация 2009 года)
Требуется множество микропроцессоров, обрабатывающих 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 год.
(По материалам Википедии)
IEEE Spectrum — ежемесячный журнал, издаваемый Институтом инженеров электротехники и электроники (англ. Institute of Electrical and Electronics Engineers — IEEE). Официальное описание журнала:
«Журнал «IEEE Spectrum», флагманская публикация IEEE, исследует развитие, применение и последствия внедрения новых технологий. Он предвосхищает тенденции в области машиностроения, науки и техники, а также служит форумом для понимания, обсуждения и руководства в этих областях.»
Журнал «IEEE Spectrum» читает более 385 000 инженеров по всему миру, что делает его одним из ведущих научных и инженерных журналов в мире. Тематика журнала охватывает широкий круг технических проблем и достижений компьютерной техники, средств связи и электроники. Как и в стандартных журналах, статьи «IEEE Spectrum» пытаются сделать доступными для неспециалистов, хотя предполагается их инженерное образование. Материалы журнала пользуются авторитетом и часто цитируются другими изданиями.
Как это — быть разработчиком ПО для автомобилей. Часть 1/2
Сталкиваясь с реалиями машиностроительной промышленности, большинство разработчиков программного обеспечения не справляются – уж очень узкоспециализированы продукты, с которыми приходится работать. Это вам не создание программ для интернет-пользователей, компьютеров и даже не мобильные приложения, а потому новички чувствуют себя, как Томас из фильма «Бегущий в лабиринте». Посмотрите, примерно, 50 секунд трейлера – и вы поймете, какой шок испытывают те, кто имеет дело с разработкой ПО для автомобилей впервые.
Все, что у вас есть — это множество терминов и инструментов, о которых вы понятия не имеете. Когда во время собеседования в одной автомобильной компании я поинтересовался, какую IDE они используют, интервьюеру мой вопрос, мягко говоря, не понравился. Я привык к Visual Studio, и наивно надеялся, что здесь для разработки встроенного программного обеспечения понадобится что-то аналогичное. Я даже не представлял, что меня ожидало! Просто море мелких и серьезных (по сложности) инструментов, которым нужна была очередная жертва.
Причем, когда речь идет о разработке программного обеспечения для автомобилей, инструменты отнюдь не единственная проблема. Практически невозможно найти литературу для новичков или просто обучающие материалы, касающиеся библиотек или архитектуры соответствующих программ. Термин «учебное пособие» и вовсе звучит неуместно, ведь сфера автомобилестроения – весьма закрытое сообщество. Да и сообществом ее вряд ли назовешь, ведь при такой конкуренции никто не должен догадаться, как вы создаете ту или иную программу. Чтобы узнать хоть что-то об отдельных инструментах и механизмах этого сегмента программирования, вы можете записаться на запредельно дорогие курсы, но ваша компания должна быть готова выложить немалую сумму и потребуется не меньше нескольких недель, чтобы получить опыт, который вам нужен уже сейчас. Очень жаль, что разобраться в специфике программирования для автомобилестроения так сложно, а потому я решил посвятить свою статью именно этой теме.
Поскольку мне неоднократно приходилось переключаться с создания приложений для интернет-пользователей/компьютеров на разработку встроенных программ и обратно, мне не понаслышке известно о проблемах, с которыми сталкиваются новички, имеющие дело, в основном, с первым блоком продуктов. Аналогичные сложности возникают и у программистов, которые никогда не сталкивались со спецификой автомобильной промышленности.
В этой и следующей статье мне хотелось бы поговорить о принципах работы встроенных программ для автомобилей, а также заглянуть в недра экзотической архитектуры встроенных приложений.
Какие темы мы рассмотрим?
Вы можете посмотреть видео, посвященное разработке электронной системы рулевого управления. Кстати, я тоже работал в этой команде.
Данная модель частично управляется программно. Частично означает, что специализированное ПО лишь помогает водителю, но полный контроль над системой имеет именно он.
Предположим, нам нужно создать полностью электронную систему рулевого управления, в которой руль напрямую не связан с колесами. Вместо этого датчик измеряет угол поворота руля и отправляет полученные данные нашей программе. В автомобильной терминологии это сервопривод. Вы не поверите, но благодаря Nissan на рынке уже появилась модель с сервоприводом.
Работу ПО обеспечивает крошечный процессор или, если говорить точнее, микроконтроллер, по сети подключенный к датчику.
Когда водитель поворачивает руль, благодаря датчику, который постоянно передает информацию о текущем угле поворота, ПО получает соответствующий сигнал. Например, если водитель поворачивает руль на 90 ° вправо, в течение секунды сигнал датчика обрабатывается по следующему принципу:
Помимо этого, ПО также управляет работой электрического двигателя, который перемещает зубчатую рейку слева направо и в обратном направлении, а, значит, изменяется угол поворота передних колес автомобиля. Соответственно, ПО может направить машину влево или вправо. Связь между микроконтроллером, запускающим ПО, и электродвигателем обеспечивается благодаря электронному блоку управления (ECU), в состав которого входит собственно микроконтроллер и усилитель мощности, регулирующий систему питания двигателя. Таким образом, наша программа варьирует подачу тока в двигателе и положение зубчатой рейки изменяется в нужном направлении.
Электронный блок управления (ECU)
При условии, что встроенное программное обеспечение работает корректно, при повороте руля почти мгновенно изменяется положение зубчатой рейки.
Руль — синий, рулевая рейка — розовый (прим.)
Становится понятно, что даже обработка информации здесь не подчиняется ни логике событийно-ориентированного программирования, как в случае с привычными приложениями графического интерфейса пользователя, ни законам пакетных фалов. Вместо этого требуется непрерывная, своевременная обработка входящих данных. Если программе понадобится слишком много времени, чтобы проанализировать показатели датчиков, рулевая рейка и передние колеса автомобиля будут двигаться с задержкой, и водитель это заметит. Скорее всего, в экстремальной ситуации это приведет к потере контроля над автомобилем, например, при повороте руля в целях объезда препятствия машина не сразу среагирует на маневр. Подобная специфика повышает требования к временным показателям программ для автомобилей, особенно, если учесть ограниченную производительность процессора стандартных электронных блоков управления.
В продолжение серии мы рассмотрим архитектуру программного обеспечения, позволяющую устранить обозначенные проблемы, и, надеюсь, с помощью этих материалов начинающие разработчики встроенных приложений для автомобилей гораздо быстрее освоят базовые принципы, действующие в данной сфере.