[Из песочницы] Программист в автомобильной индустрии. Через тернии к звездам28.10.2020 15:02

Вступление

Фото сделано мной при посещении шоу-рума BMW Мюнхена.

Небольшая статья о там, как живется и чем дышится в большом и неповоротливом Automotive мире. Мире разработки программного обеспечения, какие технологии используются, какие задачи приходится решать, все исключительно на личном опыте. Да, тут я истины не открою, автомобильное ПО как правило использует устаревшие технологии и достаточно длинные циклы разработки, хотя конечно бывают исключения — Tesla, например. Хотя это лишь мои предположения по тому, что я могу прочить об этой компании в интернете. Текст содержит небольшие вставки биографии автора.

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

Первый automotive проект. Год 2014

Начнем… Начнем с того, как наверное это часто бывает в IT, особенно на начальном этапе карьеры, я попал в automotive совершенно случайно. В 2014 г., после неожиданного закрытия основного проекта, наша команда была частично переведена на поддержку ПО для разработки Human-Machine Interface (HMI) для автомобилей. Такие интерфейсы, как правило, использовались в Head-Unit устройствах. В то время это был немного устаревший продукт, изначально разработанный немецкой компанией, и теперь отданный нам на поддержку. На тот момент у меня был лишь небольшой 2-х летний опыт С++ разработки GPU драйвера для Windows, поэтому данный проект я использовал как площадку для дальнейшего изучения С++.

Отступление: В автомобиле можно выделить два устройства которые используют HMI — это Head-Unit — вычислительное устройство с экраном на торпедо, и Digital Instrument Cluster, область где обычно выводится спидометр и другие датчики авто. Многие производители, особенно сейчас, пытаются Digital Instrument Cluster делать цифровыми. Head-Unit также может поддерживать несколько мониторов, например для задних пассажиров и, как правило, соединен с Infotainment системой. Системой, которая позволяет управлять некоторыми функциями автомобиля (кондиционер или стеклоподъемники) через команды на дисплее и предоставляет функции мультимедиа. Head-Unit система может быть встроенной, а может быть установлена от стороннего производителя (Alpine, Clarion, etc.) через стандартные разъемы.

Итак, мы имеем, небольшой С++ framework, цель которого ускорить разработку HMI интерфейсов и предоставить некоторый базовый набор функций, общих для проектов такого типа. Например, поддержка переводов, тем для визуального представления, машину состояний и т.п. Был в наличии и свой редактор UI, написанный на Microsoft MFC, где можно было рисовать экраны с кнопочками, добавлять события и переходы. И еще отдельно был редактор для переводчиков. Его почему-то все хвалили, за то что он предоставлял информацию о доступном свободном пространстве для переведённого текста. Таким образом, переводчик всегда знал будет ли переведенный текст обрезан или нет. Ну да, и конечно стандартная библиотека типов (строки, массивы, …) была своя, чтобы уменьшить потребляемую память, на которой так любят экономить производители.

Я же, со своей стороны, не могу выделить что-то специфическое для отрасли, но точно помню что там можно было добавить картинку приборной панели для имитации нажатия hardware кнопок на ней.

Далее, после создания проекта в редакторе UI, появлялась возможность сгенерировать файл модели, который загружался в память вычислительного устройства автомобиля и использовалась запущенной engine программой для отрисовки графики.

Система сборки была написана на Jam, которую в срочном порядке пришлось переписывать на CMake, потому что никто не понимал как она работает, да и поддержка Jam разработчиками прекратилась. Также была поддержка кросс-платформености для QNX и Linux, так что я наконец-то смог начать изучать другие ОС в процессе работы. Из странностей была поддержка отрисовки на Flash.

Весь процесс создания HMI с помощью framework выглядел следующим образом:

1. Создание прототипа

1.1. Дизайнеры рисовали интерфейс в Adobe Photoshop. Им приходилось специальным образом использовать слои и использовать ограниченный набор функционала Photoshop, чтобы потом все это можно было легко экспортировать в набор растровых изображений, с которыми мог работать редактор.
1.2. Сами переходы между экранами описывались в виде PowerPoint презентаций, где стрелочками просто соединялись различные картинки нарисованные на первом шаге. Таким образом описывалась машина состояний перехода между экранами.

1. Разработка

2.1. Из PSD проектов экспортировались картинки, которые использовались в UI редакторе для
компоновки экранов Переходы и состояния определялись из слайдов PowerPoint.
2.2. Разработчики писали controllers, которые содержали более сложную логику, чем та которую можно было сделать лишь с помощью средств редактора, которые затем компилировались в динамические подключаемые библиотеки и загружались движком при необходимости.

Да все было так просто и топорно :) Но это работало, машины выпускались и продавались.

Разработанный UI для платформы NTG5 в Mercedes

Отступление: в Automotive отрасли сложилось так, что большинство непосредственных производителей (OEM) не пишут ПО сами, а заказывают его у сторонних подрядчиков различных уровней. Их называют Tier 1, 2 и т.д. компаниями. Они как правило давно работают с OEM, а те в свою очередь доверяют им. Попасть в этот список какой нибудь software компании, не из automotive мира, практически нереально, поэтому они вынуждены работать с компаниями из Tier списка, если например условно эта компания хочет писать ПО для BMW. Еще один рабочий вариант это купить компанию Tier уровня.

Кажется, что все это уже было в каком-нибудь Qt или другом подобном framework, но это не помешало продавать его достаточно крупным немецким производителям авто. Уточнение: в моем случае это все таки были Tier 1 заказчики, такие как Harman, которые дальше уже продавали готовые решения компаниям уровня Daimler, Audi и т.п. И вот, как мне кажется, почему: во-первых разработан он был задолго до 2014 г., Qt на тот момент еще не было столь популярным и не обладало столь широким функционалом А во-вторых, и что наверное более важно, это продукт исключительно для конкретных заказчиков, они могли запросить сделать какой-нибудь новый функционал в достаточно короткие сроки или исправить bug. Второе, конечно, было чаще. Таким образом, они могли контролировать процесс разработки и оптимизировать его для своих продуктов.

Период неопределенности

В какой-то момент производители поняли, что функционала собственных разработок им не хватает, а технологии HTML, Java, Qt ушли далеко вперед, и /решили словить хайп/ начали пробовать писать HMI с использованием новых технологий. Flash на тот момент похоронили окончательно, а компания Qt вообще решила выделить automotive в отдельный бизнес с собственными решениями. Создавалось большое количество прототипов на WebKit, но все они страдали проблемами производительности.

Демонстрация возможностей Qt Automotive Suite:

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

В качестве поддерживаемых frontends были выбраны JavaFX, QML и Web, всеми переходами должен был управлять backend с машиной состояний. По задумке, с помощью редактора модели, можно было описать все состояния системы и модель данных, доступ к которым бы осуществлялся из клиентского кода frontend. Таким образом, описав и создав один раз модель с контроллерами на С++, была бы возможность замены frontend части на любую из поддерживаемых.

За то небольшое время, которое я успел поработать в проекте, я немного расширил свой стек разработки web-технологиями HTML/CSS/JavaScript и Qt/QML стеком. Проект был в статусе R&D, поэтому у нас не было прямых контактов с авто-производителями, можно сказать, что это было обычное C++ программирование. Помню даже, что мне настолько понравилось писать свое первое web приложение, что я даже подумывал пойти работать JS разработчиком в другую компанию.

Единственное, что было это небольшие курсы по Automotive SPICE (ASPICE), который является адаптацией общего стандарта SPICE (ISO 15504). Стандарт определяет процесс и шаги разработки ПО в автомобильной отрасли. Если вы следуете этому процессу, у вас также больше шансов пройти различные сертификации при выпуске ПО на рынок. Ну, и надо сказать крупные компании активно его используют.

Отступление: Automotive SPICE

Что же определяет данный стандарт? Если простыми словами, то стандарт говорит, что у вас должны быть определены требования заказчика (SWE.1), из которых потом рождается архитектурный документ (SWE.2). Данный документ описывает работу всей системы целиком, но без лишних деталей. Далее, если у вас система состоит из нескольких модулей, для каждого пишется более детальный дизайн документ (SWE.3). И наконец, вы приступаете к написанию кода (на картинке отсутсвует, видимо, ввиду малой значимости). После такого, как код написан его нужно протестировать на всех уровнях с помощью Unit тестов (SWE.4), интеграционных тестов (SWE.5) и квалификационных тестов (SWE.6) всей системы.

Automotive SPICE V-модель:

Еще одна важная штука, которую постоянно требуют — это возможность трассировки (traceability). Что это значит? Для каждого требования у вас должна быть ссылка на тесты, программный код, и архитектурный/детальный документ. И наоборот, указав на любую строчку кода, вы должны знать почему вы ее написали, какое требование она реализует.

Стоить также отметить, что стандарт не определяет набор инструментов для реализации требований. Компании обычно сами выбирают и разрабатывают инструментарий для того, чтобы соответствовать ему. Например, требования почти всегда пишутся в Excel или DOORS, где у каждого требования есть уникальный идентификатор, который потом используется в качестве ссылки во всех документах и программном коде. А в качестве дизайна документа, скажем, может быть сгенерированный Doxygen.

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

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

Азиатские будни

На дворе шел 2016 год, южное азиатское солнце нехило прогревало воздух, так что хотелось просто лежать и ничего не делать. Хотя освежающий морской ветерок придавал немного бодрости… Ой о чем это я, новый проект… Итак, я переехал в Юго-Восточную Азию, но времени заниматься изучением новой страны по началу особо не было. Новый проект предполагал создание мультимедийной системы (Head-Unit) практически с нуля, новой командой, в кратчайшие сроки (1 год). Да и еще задумывалось, что решение будет самым дешевым на рынке, однако с максимальным набором функционала для таких систем: поддержка Android Auto, CarPlay, SmartDeviceLink (SDL), и даже Miracast. В качестве заказчика — Clarion, который планировал сделать платформу с расширяемым функционалом, с тем, чтобы ее можно было бы изменять под нужды различных OEM.

Поставщиком hardware части системы выступила южно-корейская компания Telechips, также она предоставила Board Support Package (BSP). BSP был сделан на базе Yocto Project и предоставлял собой ядро линукса со всем необходимым набором драйверов, включая библиотеки для интеграции CarPlay и iAP2. Думаю, основным критерием выбора была цена решения. Но Telechips предоставлял только reference board, финальную железку Clarion делал своими силами и печатал рядом, буквально через дорогу от офиса.

Отступление: Yocto Project состоит из системы сборки BitBake и базового набора пакетов, которые позволяют вам собрать свой дистрибутив Linux. Сам BitBake написан на Python и использует файлы рецептов (recipes) для описания правил сборки. Система достаточно большая и универсальная, умеет собирать ядро Linux, пакеты и образы файловых систем. Файл рецепта для пакета, например, обычно содержит правила откуда скачать исходный код, как его собрать и как организовать структуру пакета, который потом менеджером пакетов будет установлен на файловую систему. На Yocto также сделан открытый Automotive Grade Linux, который добавляет пакеты с решениями для автомобиля.

Что требовалось от нас, так это написать user space уровень, который был ответственен за логику работы системы и отрисовку UI интерфейса. Пришлось в итоге покопаться в BitBake, чтобы написать парочку рецептов для наших приложений. Плюсом также было, что у нас уже был движок отрисовки UI, подобный тому, что я описывал в предыдущей главе, но только более современный, разработанный изначально шведской компанией. Там был более продвинутый редактор, уже на базе Eclipse, с поддержкой анимации и 3D, а контроллеры назывались Functional Units.

Что, продолжим. Требования заказчик предоставил, а это значит что нужна архитектура. Не долго думая, за базу взяли прототип, предлагаемый GENIVI Alliance, выкинув оттуда лишние модули, функционал которых нам не требовался. Но получилось все равно достаточно много для команды из 10 человек на тот момент. Поэтому, к нам на помощь на некоторые время были привлечены разработчики из других стран. Получилась такая интернациональная команда — Малайзия, Южная Корея, Япония, Украина, Россия, Румыния, Болгария (в Японии находился главный офис Clarion, который должен был контролировать процесс разработки). И это, по началу, доставляло некоторые неудобства ввиду различных часовых поясов, и не совсем идеального английского, по крайней мере у меня так точно :) Также сказывалось различие культур и религий, все таки Малайзия это Азия и работать они привыкли по азиатски — много, но не очень эффективно.

Предлагаемая GENIVI архитектура:

В результате, архитектура получилась сервис-ориентированной, где почти каждый блок из диаграммы были выделен в отдельный сервис (процесс) и общался с другими сервисами через механизмы IPC. Одним из основных механизмов IPC был CommonAPI (тоже разработка GENIVI). Согласно CommonAPI вы описывает свой интерфейс с помощью Franca IDL, и затем с помощью генераторов получаете С++ код клиент-серверных интерфейсов, где в качестве транспортного протокола выступает D-Bus. Но на самом деле CommonAPI не ограничивается только C++, а в качестве протокола были реализации для D-Bus и SOME/IP, просто в нашем случае не было сетевого взаимодействия. Поэтому D-Bus нас вполне устраивал, хотя по началу был некоторый скептицизм по его быстродействию с большим количеством сервисов и объемом передаваемых данных.

CommonAPI С++:

Отступление: Franca Interface Definition Language (IDL) — декларативный язык описания интерфейсов, где вы можете определить различные типы, методы и события для коммуникации. Файл с описанием интерфейса затем может быть использован для автоматической генерации кода на различных языках программирования.

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

• UI не должен отвлекать водителя, анимации должны быть быстрыми, кнопки крупными. Видео по требованиям можно было проигрывать только во время включенного стояночного тормоза, иначе при включении видео показывался предупреждающий экран, сообщающий об опасности просмотра видео за рулем;
• в процессе работы автомобиля, питание (12 Вольт) может периодически пропадать, например при зажигании (электрокары не учитываю);
• система должна загружаться быстро, как следствие пункта выше;
• сервисы типа CarPlay и AndroidAuto тесно интегрируются в систему и предъявляют свои дополнительные требования для работы вашего UI;
• предполагаемый срок службы авто 20 лет, нужно расчитывать, что за это время работы постоянная память не выработает свой ресурс по записи.

Вот список возможных решений:

• дизайнеры должны учитывать данные особенности при отрисовке интерфейсов. Требования, как правило, уже написаны специалистами с учетом логики, специфичной для авто. Например, как в случае с видео из примера выше, или, еще один пример, работа камера заднего вида, которая должна включаться при включении задней передачи. Поэтому, задача разработчика просто следовать этим требованиям;
• так как питание может неожиданно пропасть, мы можем потерять важную информацию в RAM, поэтому обычно критическую информация периодически сохраняют. Иногда бывает так, что контроллер питания отводит несколько миллисекунд на завершение работы, но это уже зависит от hardware;
• для быстрой загрузки мы использовали snapshot базовых сервисов системы, когда они еще не были инициализированы, но ядро Linux и все процессы уже были загружены в память. На первом старте системы, мы этот snapshot создавали, а затем, при последующих запусках, загрузчик просто копировал его в RAM. После обновления системы snapshot создавался снова;
• нам пришлось изменять некоторые изначальные требования и переделывать логику работы UI, чтобы удовлетворять условиям Apple и компании, и пройти сертификацию;
• за работу с non-volatile memory (NVM) обычно отвечает отдельный модуль Persistence. Все приложения и сервисы, которые хотят что-то писать в память, должны это делать через него. Для продления жизни и работы памяти, Persistence обычно хранит все в RAM памяти и реально пишет в долгосрочную память только по определенным событиям. Например, при завершении работы системы или с определенной периодичностью.

Фото салона с HU в Nissan Datsun Cross:

Если AndroidAuto и CarPlay у всех на слуху, то технологию SmartDeviceLink (SDL) знают не многие. Хотя по своей задумке и реализации она очень похожа на решения от технологических гигантов. Впервые была использована компанией Ford в своем решении SYNC AppLink, и является Open-Source проектом. Основная идея в том, чтобы соединить смартфон с головным устройством, и позволить запускать пользовательские приложения на экране автомобиля.

Архитектура SmartDeviceLink:

Для того, чтобы HU поддерживал данную технологию, на него необходимо интегрировать SDL Core. Таки образом он сможет общаться с приложениями установленными на телефон по специальными протоколу SDL. Конечно, не с любыми, а только с теми, которые поддерживают его. Когда телефон соединяется с автомобилем, он может выводить адаптированную видео-картинку на дисплей и обмениваться различными данными с Head-Unit. Таким образом установка приложения не требуется, а вся логика работает на телефоне.

В качестве примера можно привести навигационное приложение Sygic, которое в том числе работало на HU в нашем проекте.

Пример работы навигационного SDL приложения Sygic:

Happy End’а по началу не ожидалось ввиду того что, как это обычно бывает в automotive, ПО в срок готово не было. Хотя оно обладало почти всем требуемым функционалом, багов в нем было хоть отбавляй. Но надо отдать должное командам, в том, что это вообще удалось в сделать в столь короткий срок. Хотя, конечно, не обходилось без переработок. В итоге проект удалось закончить и сдать заказчику, компании Nissan, которая использовала данное решение в своих моделях автомобилей Datsun Cross для тайского и индонезийского рынка. Проект и дальше развивается как платформа с возможностью кастомизации функционала и UI интерфейса. Используется в том числе и на локальном рынке Малайзии авто-производителем Perodua.

Родина зовет

По личным причинам пришлось покинуть малазийский полуостров и вернуться на Родину. И опять automotive проект, правда в этот раз заказчиком выступил напрямую крупный немецкий OEM. А это значит привет Automotive SPICE, MISRA, ISO 26262.

Отступление: Safety ISO 26262 — стандарт по безопасности, которому должны следовать разработчики автомобильного ПО при разработки систем, которые могут повлиять на безопасность (водителя, пассажиров, пешеходов) при использовании автомобиля. И это действительно важно, потому что авто это такое устройство, которое с определенной долей вероятности может убить человека. Задача стандарта эту вероятность минимизировать.

MISRA C/C++ — стандарт разработки ПО на языке C/C++ для встраиваемых систем с целью повышения безопасности и надежности последних. Часто используется в automotive в связке с safety стандартом ISO 26262. Технически — это набор правил (не всегда адекватных) для языка, что-то типа code style. Пример адекватного правила — конструкция switch всегда должна иметь default ветку. Зачастую, чтобы соответствовать стандарту используются статические анализаторы кода, которые проверяют правила из стандарта. На рынке также много готовых решений, например от компании Axivion, правда стоят они обычно как крыло от самолета.

К счастью, от MISRA удалось отказаться, потому что разработка предполагалась с использованием C++14, о котором MISRA ничего не знает. Но почему C++14? Как же тогда проходить сертификацию? Потому что разрабатывать пришлось под современный (сырой на тот момент) стандарт Adaptive AUTOSAR. А он предполагает использование С++14. Здесь я первый раз столкнулся с AUTOSAR (AUTomotive Open System ARchitecture).

Оказывается, данный стандарт существует уже давно, только называется он теперь Classic AUTOSAR. Направлен он, в основном, на маломощные встраиваемые системы, такие как микроконтроллеры и предполагает использование языка Си. Он по-прежнему развивается и последняя на сегодняшний день версия 4. Сам стандарт — это несколько сотен документов в свободном доступе, которые описывают единую архитектуру ПО для различных автомобильных блоков управления. Создается он консорциумом компаний (список ключевых компаний можно посмотреть тут), так или иначе связанных с автомобильной отраслью. Его можно, например, использовать при разработке ПО микроконтроллера, который управляет подушкой безопасности, системой подъема стеклоподъемников и др. Для In-Vehicle Infotainment (IVI) систем он не используется ввиду слишком низкого уровня и нацеленности на системы реального времени.

Ввиду роста сложности автомобильных систем и все большей цифровизации салона автомобиля, как любят говорить в одной компании из Купертино, стандарт был переосмыслен и создан новый Adaptive AUTOSAR. Он предполагает уже наличие POSIX PSE51 совместимой ОС. Можно сказать, что он описывает все те же самые модули, что и Classic, только на языке C++ и с учетом запуска на POSIX системах (то есть теперь у нас есть процессы и потоки, но по прежнему нет доступа к файловой системе). Правда, некоторые модули из Classic все же были сильно изменены и переработаны, часть была удалена, были добавлены и новые. Как и в Classic, в новой версии не отказались и от ARXML файлов, и это наверное то, за что большего всего ненавидят этот стандарт, огромные нечитаемые XML файлы, требующие написания или покупки специальных редакторов для работы с ними. Только представьте, документ, который описывает формат XML файла называется AUTOSAR TPS SoftwareComponentTemplate и для 4-ой версии Classic, состоит из 800 страниц.

Пример различных систем автомобиля:

Итак, как же устроен процесс разработки в AUTOSAR, или по крайней мере как это работает на практике. Представим, что нам нужно спроектировать систему для нового автомобиля. Типовое устройство автомобиля на сегодняшний день — это множество датчиков (sensors), исполнительных (actuators) и вычислительных/управляющих (ECUs) устройств, соединенных между собой в единую сеть по средством различных стандартов (CAN, LIN, FlexRay, Ethernet). Обязательно должен быть диагностический OBD выход, опционально связь с интернетом (а то как собирать о вас статистику) по какому-нибудь радио каналу.

Кстати Ethernet стандарт используется специально разработанный для atuomotive — 100BASE-T1, уменьшающий вес и стоимость кабелей по сравнению со стандартами типа 10BASE-T.

Имея такие исходные данные предполагается, что первым делом архитекторы описывают требования и архитектуру системы в формате ARXML файлов (конечно же вручную их никто не пишет, используются специальные редакторы). Эти файлы содержат описание всех интерфейсов и приложений, всех систем и модулей. В частности, коммуникационная матрица (communication matrix) содержит описание всех сигналов системы, определяет по каким интерфейсам они должны передаваться, топология системы содержит список всех вычислительных устройств (ECUs) и их параметров, список приложений на устройстве.

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

Параллельно с этим происходит производство HW и запуск на нем AUTOSAR стека.

Написанные приложения потом интегрируются в конечную систему (интеграторами обычно выступают компании, которые предоставляют AUTOSAR стек), которая тоже заранее сконфигурирована согласно описанию из ARXML модели. Под конечной системой в данном случае я имею ввиду HW с работающим AUTOSAR стеком, который включает ОС, драйвера и базовые сервисы из стандарта.

Но на самом деле все не совсем так идеально.

Первая проблема заключается в том, различные компании используют разные реализации AUTOSAR стека (свои собственные или от известных разработчиков таких как VECTOR Informatik или Elektrobit), которые не всегда совместимы. И тут причин несколько:

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

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

И третье — это ARXML файлы на 10-ки тысяч строк, тут и говорить нечего :)

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

Написать такое приложение не составило труда, гораздо большие проблемы были с его интеграцией в достаточно сырую Adaptive AUTOSAR систему от VECTOR (позже заменённую на не чуть лучшую от Elektrobit). На тот момент эти компании только начали вести активную разработку нового стандарта, поэтому мы для них выступали вроде тестировщиков их систем. Что касается функционала самого приложения, то в качестве диагностического протокола использовался распространенный Unified Diagnostic Services (UDS). Достаточно простой протокол, который поддерживает несколько протоколов передачи данных (TCP/IP, CAN). Взаимодействие с AUTOSAR стеком осуществлялось только с несколькими компонентами: Persistence для сохранения данных в NVM, коммуникационная (COM) система предоставляла runtime библиотеку и генераторы интерфейсов (аналог CommonAPI). Execution Manager запускал наше приложение, а мы сообщали ему о состоянии нашей инициализации. Основное же наше взаимодействие было с базовым сервисом Diagnostic Manager (DM). Данный модуль наверное является самым большим и важным в системе, потому что предоставляет диагностическую информацию во внешний мир (обычно специальному тест устройству/программе). В стандарте AUTOSAR DM полностью реализует протокол передачи данных, в нашем случае это Diagnostic over IP (DoIP), и позволяет приложениям уже непосредственно обрабатывать UDS сообщения.

Отступление: Unified Diagnostic Services — унифицированный протокол, призванный стандартизировать процесс диагностики автомобилей. Предоставляет следующие функции при подключении внешнего трестирующего устройства:

• Чтение/запись диагностических данных;
• Через него может осуществляться обновление системы;
• Чтение кодов ошибок, или Diagnostic Trouble Codes (DTC);
• Поддержка примитивного механизма аутентификации;
• Выполнение удаленного кода и получение результата его работы.

Его реализация на протоколах CAN и Ethernet называется соответсвенно DoCAN и DoIP.

Теперь скорее всего это приложение является частью платформы Volkswagen MEB или VW.OS, хотя честно говоря я уже немного запутался в всех этих аббревиатурах и названиях, которые так часто любят использовать в Automotive, что не уверен.

Попытка VW превратить автомобиль в мобильный телефон:

VW.OS — операционная система, разрабатываемая Volkswagen, как единый стандарт ПО для свои будущих автомобилей. Немецкие автопроизводители наконец-то поняли, что разрабатывать каждый раз ПО с нуля это дорого и долго, а с каждым годом в автомобиле появляется все больше функционала. Поэтому появление собственного стандартного набора ПО стало логичным шагом. Предполагается модульная архитектура, где отдельные модули можно будет включать/выключать в зависимости от модели автомобиля. К тому же можно будет брать дополнительную денежку с пользователя за включение каких-нибудь премиальных функций, хотя инициатива BMW с подпиской на CarPlay как то не взлетела :)

Немецкий автопром стал ближе

После солнечной Азии, находиться в суровом климате северного города становилось невыносимо, организм требовал солнца и тепла :) Посему, было принято решение сменить location на более умеренный, а полученный опыт с прошлых проектов определил основную страну назначения. Работодателя тоже было решено поменять, все-таки 7 лет это большой срок, хотелось посмотреть как работают и устроены процессы в других компаниях. Так вышло, что из большой компании со сложной организационной структурой я перешел в маленькую с плоской организацией, но с крупными OEM заказчиками, где нет менеджеров в привычной для них роли, а только само-организованные и ответственные разработчики. А главная ответственность менеджеров это коммуникация между заказчиком и остальными отделами (разработки, тестирования). И знаете что? Это работает.

А что за проекты? Если раньше я писал код в основном для систем на Linux с мощными ARM микропроцессорами, то теперь мне предстояло вести разработку под микроконтроллер с операционной системой реального времени и Classic AUTOSAR стеком. И наверное это можно назвать шагом назад в плане платформы (очень не привычно когда у тебя нет динамической памяти), но в плане tools и технологий особенно для automotive компании это реальный прогресс. Тут тебе и Ruby, и Rust, и Electron/TypeScript. Своя реализация Classic AUTOSAR стека с генераторами, написанными на Ruby, а не на Java, как это обычно было в прошлых проектах. Свой подход для работы с ARXML файлами, с достаточно простой и понятной идей, когда специальная утилита конвертирует эти файлы в текстовый читаемый формат, а после редактирования синхронизирует их обратно в ARXML версию (кто в теме вот ссылка на демку).

На сегодняшний день это мой текущий проект… Год 2020.

© Habrahabr.ru