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

На каком языке пишется программа для электронного блока управления для автомобиля?

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

• Вопрос задан более трёх лет назад
• 24468 просмотров

Комментировать

Решения вопроса 0

Ответы на вопрос 4

Андрей @poslannikD

Java/C/C++ Programmer

Все зависит от модуля. По опыту в машиностроении скажу что в данный момент эбу это чистый с либо вот это. Ассемблером никто не балуется, так-как это производство, а на производстве нужно работать быстро, а писать на асме занятие затратное по времени. С++ в эбу,пока не встречал, зато активно используется в программах сопровождения, терминалах и другом embedded.
Если интересует электроника, тогда нужно учить все связанное с железом и href https://ru.wikipedia.org/wiki/%D0%AF%D0%B7%D1%8B%D0%BA_%D0%BE%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8F_%D0%B0%D0%BF%D0%BF%D0%B0%D1%80%D0%B0%D1%82%D1%83%D1%80%D1%8B» rel=»nofollow»>https://ru.wikipedia.org/wiki/%D0%AF%D0%B7%D1%8B%D. «>вот этот ужас. Плюс основы логики, битовые операции, основы пк(ну там как работает проц и как он обменивается данными с другими частями пк, и как один пк обменивается данными с другим пк на уровне железа что бы иметь представление о том как работает электроника), принципы работы CAN строги и обязательны а также знание конкурирующих шин.
Если душа ближе к программухе тогда с/с++, алгоритмы, ооп, работа с ос, разработка драйверов, linux тут стандарт де факто так что знания этой ос на уровне уверенного администратора это минимум, знание CAN и аналогов, битовые операции(and, xor, or маски), немного логики, знание систем счисления(2,16) и умение переводить из одной в другую. Начальные знания по электронике, основы пайки.

Ответ написан более трёх лет назад

Комментировать

Нравится 3 Комментировать

Сергей Горностаев @sergey-gornostaev

Седой и строгий

На C. Выбрать изучение самого языка и программирования микроконтроллеров.

Ответ написан более трёх лет назад

Комментировать

Нравится 2 Комментировать

Lead Software Developer

Языки программирования и автомобили

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

Basic: Жигули

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

Visual Basic: Лада

Когда Жигули должны были уйти в прошлое, на смену пришла Лада. Да, завод всё же оказался проклятым, но поддержка государства и возможность простому россиянину за короткий срок заработать на такой автомобиль, сделали марку настоящим хитом.

C/C++/C#: Ford Mustang

Эру автомобиля Mustang можно разделить сразу на несколько этапов. Первые модели, те что сошли с конвейера в 60-е годы, были изумительны со всех точек зрения. Даже сегодня, когда так далеко шагнула эволюция, Мустанги крайне популярны. Экземпляры, произведённые в 80-х потеряли большую часть своей магии: они носили громкое имя, имели спрос, но выглядели обыденно, теряясь на фоне куда более быстрых и элегантных машин. Но в 2000-х Mustang взревел с новой мощью, объединив агрессию из 60-х и современных подход к автомобилестроению. Да, это не лучший автомобиль в мире, но крайне привлекательный.

Java: Volvo

Вряд ли тут может быть много мнений: Volvo действительно классный автомобиль. Он может быть семейным, он может быть быстрым, он может быть романтичным – всё зависит только от вас. Правда, дороговат, да и говорят сейчас в Китае создают идеальные копии. Но в целом, покупая Volvo, вы не рискуете прогадать.

Python: Subaru

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

Ruby: Honda

Вечный спор автомобилистов: что лучше, Honda или Subaru? Качество, скорость, породистые представители – всё это свойственно и Honda. Да и страна производитель – Япония. Говорят, только подвеска у них немного жесткая и обслуживание дорогое, а в остальном – мечта.

PHP: Citroen

Сегодня модно ругать старый-добрый французский концерн. А ведь было время, когда Citroen восседал на самой вершине технологической мысли. Но потом требовательным покупателям понадобились не только хорошая подвеска и приятный внешний вид, но ещё идеальное качество сборки. И тут посыпалось…

1С: КАМАЗ

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

Go: Bugatti

Вчера в новостях писали, что самая быстрая серийная машина в мире – Bugatti Veyron. Сегодня, поговаривают, что Bugatti Chiron. «Bugatti» и «скорость» так часто встречаются в одном предложении, что закрадывается мысль: а может это просто пиар?

Perl: Saab

Saab никогда не был автомобилем из высшего общества. Но несмотря на это, его внешний вид, езда на нём могла доставить непередаваемое удовольствие. Если бы не миллион ненужных кнопок, проблемы с электроникой и необходимость постоянного ремонта.

JavaScript: Renault

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

Язык Ассемблера: драгстер

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

Программист в автомобильной индустрии. Через тернии к звездам

Фото сделано мной при посещении шоу-рума 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. Дизайнеры рисовали интерфейс в Adobe Photoshop. Им приходилось специальным образом использовать слои и использовать ограниченный набор функционала Photoshop, чтобы потом все это можно было легко экспортировать в набор растровых изображений, с которыми мог работать редактор.
1.2. Сами переходы между экранами описывались в виде PowerPoint презентаций, где стрелочками просто соединялись различные картинки нарисованные на первом шаге. Таким образом описывалась машина состояний перехода между экранами.

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 нас вполне устраивал, хотя по началу был некоторый скептицизм по его быстродействию с большим количеством сервисов и объемом передаваемых данных.

Отступление: 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 проектом. Основная идея в том, чтобы соединить смартфон с головным устройством, и позволить запускать пользовательские приложения на экране автомобиля.

Для того, чтобы 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.

Что такое Python?

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

В чем заключаются преимущества языка Python?

Язык Python имеет следующие преимущества:

• Разработчики могут легко читать и понимать программы на Python, поскольку язык имеет базовый синтаксис, похожий на синтаксис английского.
• Python помогает разработчикам быть более продуктивными, поскольку они могут писать программы на Python, используя меньше строк кода, чем в других языках.
• Python имеет большую стандартную библиотеку, содержащую многократно используемые коды практически для любой задачи. В результате разработчикам не требуется писать код с нуля.
• Разработчики могут легко сочетать Python с другими популярными языками программирования: Java, C и C++.
• Активное сообщество Python состоит из миллионов поддерживающих разработчиков со всего мира. При возникновении проблем сообщество поможет в их решении.
• Кроме того, в Интернете доступно множество полезных ресурсов для изучения Python. Например, вы можете легко найти видеоролики, учебные пособия, документацию и руководства для разработчиков.
• Python можно переносить на различные операционные системы: Windows, macOS, Linux и Unix.

Где применяется Python?

Язык Python имеет несколько стандартных примеров использования при разработке приложений, в числе которых:

Веб-разработка на стороне сервера

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

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

Автоматизация с помощью скриптов Python

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

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

Наука о данных и машинное обучение

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

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

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

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

Разработчики программного обеспечения часто используют Python для различных задач разработки и программных приложений, среди которых:

• Отслеживание ошибок в программном коде
• Автоматическая сборка программного обеспечения
• Управление программными проектами
• Разработка прототипов программного обеспечения
• Разработка настольных приложений с использованием библиотек графического пользовательского интерфейса (ГПИ)
• Разработка игр: от простых текстовых игр до сложных видеоигр

Автоматизация тестирования программного обеспечения

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

• Разработчики используют среды модульного тестирования Python (Unittest, Robot и PyUnit) для тестирования написанных функций.
• Тестировщики программного обеспечения используют Python для написания тестовых примеров для различных сценариев. Например, язык применяется для тестирования пользовательского интерфейса интернет-приложения, нескольких программных компонентов и новых функций.

Разработчики могут использовать несколько инструментов для автоматического запуска тестовых скриптов. Эти инструменты известны как инструменты непрерывной интеграции / непрерывного развертывания (CI/CD). Тестировщики и разработчики программного обеспечения используют инструменты CI/CD (Travis CI и Jenkins) для автоматизации процесса тестирования. Инструмент CI/CD автоматически запускает тестовые скрипты Python и сообщает о результатах тестирования всякий раз, когда разработчики вносят новые изменения в код.

Как развивался Python?

Python разработан Гвидо Ван Россумом (Guido Van Rossum), программистом из Нидерландов. Он начал работу над языком в 1989 году в центре Centrum Wiskunde & Informatica (CWI). Изначально язык был полностью любительским проектом: Ван Россум просто хотел чем-то занять себя на рождественских каникулах. Название языка было взято из телешоу BBC «Летающий цирк Монти Пайтона», большим поклонником которого являлся программист.

История версий Python

• Гвидо Ван Россум опубликовал первую версию кода Python (версия 0.9.0) в 1991 году. Он уже включал в себя ряд полезных возможностей. Например, различные типы данных и функции для обработки ошибок.
• В версии Python 1.0, выпущенной в 1994 году, были реализованы новые функции для простой обработки списка данных: сопоставление, фильтрация и сокращение.
• Python 2.0 был выпущен 16 октября 2000 года с новыми полезными функциями для программистов, такими как поддержка символов Unicode и упрощенный способ циклического просмотра списка.
• 3 декабря 2008 года вышел Python 3.0. Эта версия включала функцию печати и дополнительную поддержку деления чисел и обработки ошибок.

Каковы особенности Python?

Язык Python уникален благодаря следующим особенностям:

Интерпретируемый язык

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

Простой в использовании язык

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

Язык с динамической типизацией

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

Язык высокого уровня

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

Объектно-ориентированный язык

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

Что такое библиотеки Python?

Библиотека — это набор часто используемых кодов, которые разработчики могут включать в свои программы Python, чтобы не писать код с нуля. По умолчанию в Python доступна стандартная библиотека, которая содержит большое количество многократно используемых функций. Кроме того, доступно более 137 000 библиотек Python для различных задач, в числе которых интернет-разработка, наука о данных и машинное обучение (ML).

Какие библиотеки Python наиболее популярны?

Matplotlib

Разработчики используют Matplotlib для отображения данных в высококачественной двух- и трехмерной (2D и 3D) графике. Данная библиотека распространена при решении научных задач. С помощью Matplotlib данные можно визуализировать в виде различных диаграмм (например, столбчатых и линейных). Также можно строить несколько диаграмм сразу, а графику — переносить на любые платформы.

Pandas

Pandas содержит оптимизированные и гибкие структуры данных, которые можно использовать для управления данными временных рядов и структурированными данными, такими как таблицы и массивы. Например, Pandas можно использовать для чтения, записи, объединения, фильтрации и группировки данных. Также данная библиотека широко применяется в науке о данных, анализе данных и задачах машинного обучения.

NumPy

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

Requests

Библиотека Requests содержит полезные функции, необходимые для веб-разработки. Их можно использовать для отправки HTTP-запросов, добавления заголовков, добавления параметров URL, добавления данных и выполнения многих других задач, связанных с интернет-приложениями.

OpenCV-Python

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

Keras

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

Что такое платформы Python?

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

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

Какие платформы Python наиболее популярны?

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

Django

Django — одна из наиболее популярных платформ с полным стеком Python, которая используется для разработки крупных интернет-приложений. Она содержит несколько полезных функций, в числе которых веб-сервер для разработки и тестирования, движок шаблонов для frontend-разработки и различные механизмы безопасности.

Flask

Flask – это микроплатформа для разработки небольших интернет-приложений. К ее особенностям относятся сильная поддержка со стороны сообщества, качественно составленная документация, движок шаблонов, модульное тестирование и встроенный веб-сервер. Также платформа содержит расширения для поддержки валидации, уровни отображения базы данных и веб-безопасность.

TurboGears

TurboGears – это платформа, предназначенная для более быстрого и простого создания интернет-приложений. Ниже представлены ее основные возможности:

• Определенная структура таблиц базы данных
• Инструменты для создания и управления проектами
• Движок шаблонов для создания баз данных
• Движок шаблонов для frontend-разработки
• Механизмы обеспечения веб-безопасности

Apache MXNet

Apache MXNet – это быстрая, гибкая и масштабируемая платформа глубокого обучения для создания исследовательских прототипов и приложений глубокого обучения. Она поддерживает несколько языков программирования, включая Java, C++, R и Perl. Платформа содержит богатый набор инструментов и библиотек для разработчиков. Например, на ней можно найти книгу по интерактивному машинному обучению (ML), наборы инструментов машинного зрения и модели глубокого обучения для обработки естественного языка (NLP), в том числе текста и речи.

PyTorch

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

Что такое Python IDE?

Интегрированная среда разработки (IDE) — это программное обеспечение, которое предоставляет разработчикам инструменты для написания, редактирования, тестирования и отладки кода.

Какие Python IDE наиболее популярны?

PyCharm

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

• Автоматическое завершение и проверка кода
• Обработка и быстрое устранение ошибок
• Чистка кода без изменения функциональных возможностей
• Поддержка платформ интернет-приложений, таких как Django и Flask
• Поддержка других языков программирования, таких как JavaScript, CoffeeScript, TypeScript, AngularJS и Node
• Научные инструменты и библиотеки, такие как Matplotlib и NumPy
• Возможность запуска, отладки, тестирования и развертывания приложений на удаленных виртуальных машинах
• Отладчик для поиска ошибок в коде, профилировщик для выявления проблем с производительностью и средство запуска модульных тестов
• Поддержка баз данных

IDLE

Интегрированная среда разработки и обучения (IDLE) – это интегрированная среда разработки Python, установленная по умолчанию. Среда разработана только на Python с использованием набора инструментов Tkinter GUI и имеет следующие особенности:

• Совместимость со множеством операционных систем, таких как Windows, Unix и macOS
• Командное окно для запуска команд и отображения вывода
• Многооконный текстовый редактор с подсветкой синтаксиса кода и автозавершением
• Встроенный отладчик

Spyder

Spyder – это IDE с открытым исходным кодом, которую используют многие специалисты и аналитики данных. Она применяется для всесторонней разработки с использованием функций расширенного анализа данных, визуализации и отладки. Среда имеет следующие особенности:

• Редактор кода, поддерживающий несколько языков
• Интерактивная консоль IPython
• Базовый отладчик
• Научные библиотеки, такие как Matplotlib, SciPy и NumPy
• Возможность исследования переменных в коде
• Возможность просмотра документации в режиме реального времени

Atom

Atom – это бесплатный редактор, разработанный GitHub, который поддерживает кодирование на многих языках программирования, в том числе Python. Atom позволяет напрямую работать с GitHub — веб-сайтом, на котором можно централизованно хранить свой код. Atom имеет следующие особенности:

• Совместимость со многими операционными системами
• Простая установка или создание новых пакетов
• Ускоренное автозавершение кода
• Возможность поиска файлов и проектов
• Простая настройка интерфейса

Что такое Python SDK?

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

Что такое AWS PyCharm?

Набор инструментов AWS для PyCharm – это подключаемый модуль для PyCharm IDE, упрощающий создание, отладку и развертывание приложений Python на AWS. AWS Toolkit for PyCharm значительно упрощает начало разработки на Python. Он имеет ряд полезных особенностей для разработчиков, в числе которых руководства по началу работы, пошаговая отладка и развертывание IDE.

Что такое Boto3 в Python?

Boto3 — это SDK AWS для Python. Его можно использовать для создания, и настройки сервисов AWS –Amazon Elastic Compute Cloud (EC2), Amazon Simple Storage Service (S3) и Amazon DynamoDB – а также управления ими. Boto3 имеет два типа API-интерфейсов: низкоуровневые API-интерфейсы и API-интерфейсы ресурсов для разработчиков.