Крис Хоббс (Chris Hobbs) в своей фундаментальной работе Embedded Software Development for Safety-Critical Systems [1] приводит распространенное среди программистов мнение о том, что накладывать ограничения на языки программирования, это как заказывать Пикассо создание картины, при этом запрещать ему использовать желтый цвет. Тем не менее, сложно представить себе предприятие, которое серьезно занимается разработкой программного обеспечения для систем ответственного назначения, у которого в писанных или неписанных стандартах не было бы указаний о том, какой язык программирования применять и, мало того, как его применять.

Данная статья посвящена подходу, который определен в стандарте IEC 61508 и который состоит в применении для разработки ответственного программного обеспечения безопасных подмножеств языков программирования С и С++.

IEC 61508 имеет семь частей и официальный перевод на русский язык, имеющий статус национального стандарта Российской Федерации. Для обсуждаемой темы нас, в первую очередь, интересуют часть 3 Требования к программному обеспечению [2], которая содержит необходимые базовые принципы, и часть 7 Методы и средства [3], которая предлагает конкретные рекомендации. Далее мы рассмотрим стандарты MISRA C:2012 [4] и MISRA C++:2008 [5], которые имеют для программистов самое непосредственное практическое значение.

Программирование как инструмент управления рисками

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

Разумеется, меры по снижению риска имеют свою цену, выражаемую в затратах рабочего времени на их реализацию. А рабочее время каждого сотрудника имеет вполне конкретное денежное выражение.

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

Чем выше требования к снижению риска, тем выше затраты на выполнение соответствующих мероприятий. Поэтому IEC 61508 делит системы, обеспечивающие функциональную безопасность, на четыре иерархические категории, именуемые по-русски уровнями полноты безопасности (УПБ). Самый высокий уровень УПБ4, самый низкий УПБ1. В английском оригинале используется термин safety integrity level (SIL).

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

Приложение А седьмого раздела IEC 61508 [3] содержит весьма информативное руководство по выбору методов и средств, а приложение С, в свою очередь, содержит обзор методов и средств с их кратким описанием и ссылками на источники информации о них.

Указания по выбору формулируются весьма просто: для каждого уровня и каждого средства задается обозначение. Эти обозначения называют рекомендациями. Самыми жесткими рекомендациями являются HR (настоятельно рекомендуется) и NR (категорически не рекомендуется).

Разумеется, для разработки программного обеспечения систем ответственного назначения существует ряд специализированных языков программирования, таких как, например, Ada, D, FORTRAN 77 или RUST, в которых обеспечивается строгая типизация данных и решены другие важные вопросы, связанные с кодированием. Все они имеют свои ниши и являются весьма интересными с инженерной точки зрения. Но, поскольку мы с Вами, уважаемый читатель, реалисты, то для данной статьи выбор пал на тот язык, на котором на самом деле чаще всего пишут программы для систем ответственного назначения на С. А коль скоро такие объектно-ориентированные технологии, как Qt и Mesa 3D, завоёвывают всё большую популярность среди разработчиков систем реального времени, то нельзя обойти вниманием и вопросы применения С++.

Что же об этих языках говорит МЭК 61508?

Для высоких уровней полноты безопасности УПБ3 и УПБ4 для языков С, С++ и, на всякий случай замечу, Java задана рекомендация NR. Однако для С и С++, как сказано в стандарте, с подмножеством и стандартом кодирования, а так же использование инструментов статического анализа, задана рекомендация HR. В тоже время, например, для Java, даже для подмножества с выключенной или детерминированной сборкой мусора, для уровней УПБ3 и УПБ4 указана рекомендация NR.

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

Давайте с вами разберемся, какие мы можем применять подмножества и стандарты кодирования для языков С и С++.

Язык С

Наиболее авторитетным документом, определяющим подмножество языка С является стандарт, известный как MISRA C [4]. На основе него или, по крайней мере, под его влиянием, разрабатываются стандарты безопасного кодирования различных организаций, например, стандарт кодирования компании JPL [6].

Во вводной части MISRA C приводит причины популярности языка С. Назовем некоторые из них:

• Программы, написанные на С, могут быть скомпилированы в эффективный машинный код;
• Существует готовые компиляторы С для самых разных аппаратных архитектур;
• С поддерживается значительным количеством инструментов статического анализа и тестирования;
• Существует международный стандарт на язык С [7], [8];
• Накоплен большой опыт применения С при разработке систем ответственного назначения.

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

MISRA C допускает использование как С99, так и С90. Рекомендации касательно стандарта C11/С18 отсутствуют только по причине того, что на момент завершения работы над текстом MISRA C рабочая группа ISO/IEC еще не успела одобрить новую версию языка С, а ссылаться на неутвержденный стандарт было бы моветоном. Поэтому, разумеется, С11/С18 вполне может применяться.

Большое внимание стандарт придает выбору непосредственно инструментальных средств: компиляторов и статических анализаторов. При этом весьма не случайно упоминаются стандарты IEC 61508, ISO 26262 [9] и DO-178C [10]. Если в этот список добавить ещё упоминаемые в MISRA C стандарты EN 50128 [11] и IEC 62304 [12], которые касаются жизненного цикла разработки программного обеспечения, то, в общем-то, круг замкнётся. Все остальные стандарты, относящиеся к функциональной безопасности программного обеспечения, содержат уточнения или специализированные варианты тех принципов и подходов, которые описаны в перечисленных документах. При этом я вовсе не хочу сказать, что не нужно изучать другие документы безусловно, такие стандарты, как, например, IEC 60880 [13] очень важны с точки зрения применения тех или иных средств и методов к решению определенного класса задач.

Указания MISRA C бывают двух типов: правила и директивы.

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

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

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

Если код, написанный на языке С, заявлен как соответствующий стандарту MISRA C, то он должен без каких-либо оговорок или исключений удовлетворять всем обязательным указаниям стандарта.

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

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

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

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

Пример требуемого правила, входящего в группу Стандартные библиотеки, разрешимого, масштаба единицы компиляции: функции выделения и освобождения памяти, определенные в заголовочном файле <stdlib.h> стандартной библиотеки С, использоваться не должны. Назначение это правила достаточно очевидное: сократить такие распространенные ошибки программирования, как утечка памяти, освобождение невыделенной памяти, доступ к выделенной памяти до инициализации и т.п. Допустим, Вам все-таки необходимо использовать кучу. Поскольку правило требуемое, а не обязательное, то его можно нарушить, задокументировав обоснование, почему это сделано. Но в таком случае вступают в силу обязательные правила из группы Ресурсы, нерешаемые, масштаба системы:

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

Как видите, второе из указанных правил в какой-то мере сужает применение функции free() по сравнению, например, с функцией malloc().

В заключение этого краткого обзора стандарта MISRA C хотелось бы подчеркнуть, что изучение этого документа, на мой взгляд, обязательно для любого программиста, который использует язык С при разработке приложений ответственного назначения. Причем независимо от того, внедрен этот стандарт в Вашей организации или нет. Как минимум он позволит углубить знания С и разобраться во многих нюансах этого языка. Поскольку для чтения этого документа нужна персональная или корпоративная лицензия, можно обратить внимание на разработанные под его влиянием правила кодирования компании JPL [6], упомянутые выше, и краткий, но эффективный и достаточно знаменитый набор десяти правил Жерара Хольцмана (Gerard J. Holzmann) [14].

Язык С++

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

Стандарт ГОСТ Р МЭК 61508-7-2012 [3] в приложении G коротко определяет (рекомендация HR для УПБ3 и УПБ4) базовые принципы написания объектно-ориентированного кода независимо от языка программирования, например,:

• Наследование допускается только с целью уточнения базового класса;
• Глубина наследования должна быть ограничена;
• Множественное наследование допускается только для интерфейсных классов;
• Должен осуществляться контроль переопределения методов и операций.

Стандарт настоятельно рекомендует (HR) использовать апробированные паттерны (шаблоны) проектирования и программные каркасы (фреймворки). И действительно, каркасы и автоматически сгенерированный код, вероятно, являются основными путями применения языка С++ в системах ответственного назначения. С конца 1990-х годов росла популярность фреймворков с генерацией кода из UML-моделей, которые удобно использовать для реализации алгоритмов, основанных на конечных автоматах. Затем, когда мощность встраиваемых систем позволила использовать богатые UX, передовые коммуникационные и другие технологии, широкое распространение получил также фреймворк Qt. Паттернам для разных этапов проектирования посвящена, например, работа Брюса Дугласа (Bruce Paul Douglass) Real-Time Design Patterns [15]. В качестве примеров фреймворков можно привести OXF от IBM Rational и RXF от Willert Software Tools.

Как бы то ни было, The Motor Industry Software Reliability Association не осталась в стороне от процесса и внесла свой вклад в разработку подходов к безопасному кодированию на языке С++, выпустив стандарт MISRA C++:2008 [5]. Несмотря на то, что уже несколько лет назад был принят стандарт С++11 [16], MISRA C++ всё ещё основан на С++03 [17], поскольку на момент утверждения это была действующая редакция. MISRA C++ прямо заявляет, что разработчики документа не имеют намерения продвигать язык С++. Их целью является рекомендованное IEC 61508 определение подмножества С++, требуемого для различных УПБ при разработке программного обеспечения ответственного назначения.

Еще раз отмечу, что С++ особенно актуален при использовании фреймворков совместно с автоматической генерацией кода из моделей того или иного типа. Основными целями модельно-ориентированной разработки является повышение уровня абстракции (а следовательно продуктивности) разработки сложных приложений, а также сокращение ошибок за счет автоматизации генерации и анализа кода.

Заключение

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

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

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

Использованная литература:

1. Chris Hobbs. Embedded Software Development for Safety-Critical Systems. CRC Press, 2016.
2. ГОСТ Р МЭК 61508-3-2012 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 3. Требования к программному обеспечению (пер. IEC 61508-3:2010). М.: Стандартинформ, 2014.
3. ГОСТ Р МЭК 61508-7-2012. Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью. Часть 7. Методы и средства (пер. IEC 61508-7:2010). М.: Стандартинформ, 2014.
4. MISRA C:2012 Guidelines for the use of the C language in critical systems. MIRA Limited, 2012.
5. MISRA C++:2008 Guidelines for the use of the C++ language in critical systems. MIRA Limited, 2008.
6. JPL Institutional Coding Standard for the C Programming Language, 2009. URL: itech.fgcu.edu/faculty/zalewski/CEN4935/JPL_Coding_Standard_C.pdf (дата обращения 25.06.2020).
7. ISO/IEC 9899:2011 Information technology Programming languages C. ISO/IEC, 2011.
8. ISO/IEC 9899:1999 Information technology Programming languages C. ISO/IEC, 1999.
9. ISO 26262-6:2011 Road vehicles Functional safety Part 6: Product development at the software level, ISO, 2011.
10. DO-178C Software Considerations in Airborne Systems and Equipment Certification. RTCA, 2012.
11. EN 50128 ed. 2 Railway applications Communication, signalling and processing systems Software for railway control and protection systems. CEN, 2011.
12. IEC 62304:2006 Medical device software Software life cycle processes. IEC, 2006.
13. IEC 60880:2006 Nuclear power plants Instrumentation and control systems important to safety Software aspects for computer-based systems performing category A functions. IEC, 2006.
14. Gerard J. Holzmann. The Power of 10: Rules for Developing Safety-Critical Code. IEEE Computer Society, 39 (6): p.p. 9599, 2006. URL: ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1642624 (дата обращения 25.06.2020).
15. Bruce Powel Douglass. Real-Time Design Patterns: robust scalable architecture for Real-time systems. Addison-Wesley, 2003.
16. ISO/IEC 14882:2011 Information technology Programming languages C++. ISO/IEC, 2011.
17. ISO/IEC 14882:2003 Information technology Programming languages C++. ISO/IEC, 2003.

Привет, хабр! В этой статье я хочу максимально просто и доступно рассказать про то, как доказывается, что ваши средства разработки и верификации подходят для создания систем повышенной надежности. Это очень важный и далеко не самый простой вопрос, и моя цель ответить на него как можно более понятным языком. В самой статье я обобщил указания из отраслевых стандартов, таких как КТ-178 или Р-331 (встраиваемое ПО в авиации), ГОСТ Р ИСО 26262-8 (встраиваемое ПО в автомобилестроении). Так что добро пожаловать под кат

Квалификация зачем она?

Отраслевые стандарты, такие как КТ-178 или ИСО 26262, описывают процессы создания ПО повышенной надежности. Если следовать этим описаниям, то создание такого ПО превратится в бюрократический ад, который будет длиться вечно. Но существует программное обеспечение, которое позволяет автоматизировать значительную часть этих процессов. Такое ПО называется инструментом. И если вы применяете инструмент, то он должен быть надежным (ИСО 26262 даже вводит термин уверенность в инструменте). Для подтверждения надежности инструмента проводится его квалификация.

Квалификация теория

В отраслевых стандартах есть понятие уровня безопасности. В разных стандартах они называются по-разному: Уровень ПО в КТ-178, Уровни Полноты Безопасности автомобиля в ИСО 26262. А для средств разработки применяются уровни квалификации инструментов (КТ-178) или уровни классификации инструментов (ИСО 26262). Эти уровни назначаются по критичности инструментов чем больше влияния оказывает инструмент на разработку, тем более высокий уровень квалификации будет ему назначен. При этом одним из главных критериев по определению влияния инструмента является мера его влияния на результирующее ПО.
В качестве примера можно рассмотреть генератор исходного кода и статический анализатор кода. Сгенерированный код попадает в прошивку устройства, которое будет установлено на борт самолета или автомобиля. Таким образом, генератор кода оказывает непосредственное влияние на результирующее ПО. Так как генератор кода сложная штука, и может генерировать код с ошибками, то к качеству этого генератора кода предъявляются строгие требования и уровень его квалификации будет максимальным. Другое дело статический анализатор, результат работы которого не попадает в бортовое ПО и степень его влияния минимальна. Поэтому для статического анализатора уровень квалификации будет ниже, чем для генератора кода.
А еще уровень квалификации напрямую влияет на трудозатраты: так, для авиации, для квалификации инструмента по наивысшему уровню КТ-178С, требуется выполнение 76 контрольных мероприятий, а по низшему только 14.
Еще один важный момент квалификация инструментов проводится не разработчиком инструмента, а непосредственно разработчиком ПО, причем квалификация должна проводиться для каждого проекта!

Квалификация заметки по практике

Как было сказано в теоретической части, квалификация инструментов это затратный процесс, однако он упрощается несколькими способами:

• Поддержка процесса квалификации производителями инструментов (вендоров)
  
• Указания по квалификации инструментов из стандартов
  

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

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

Для квалификации инструментов верификации стандарты предписывают демонстрацию их поведения в нормальных условиях. На практике это выглядит следующим образом:

1. Вендор поставляет набор шаблонов документов, нормативных документов и опорных тестов для инструмента и их эталонные результаты.
   
2. Вы заполняете шаблоны документов и запускаете предоставленные тесты в своем окружении.
   
3. Результаты тестов, запущенных вами, сравниваются с эталонами, и при расхождении результатов вы устраняете расхождение.
   

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

Инструменты MathWorks и их квалификация

Такие инструменты как Simulink, DSP Toolbox, Control System Toolbox это стандарт индустрии для разработки систем управления, цифровой обработки сигналов. Неудивительно, что их применяют в авиации, автомобилестроении и прочих отраслях. Из разработанных моделей генерируется C/C++ код, который ездит и летает. Естественно, что перед разработчиками встает вопрос квалификации инструментов. И квалификация инструментов MathWorks для КТ-178С осуществляется для инструментов верификации моделей и кода:

• Simulink Check
  
• Simulink Coverage
  
• Simulink Requirements
  
• Simulink Design Verifier
  
• Simulink Test
  
• Simulink Report Generator
  
• Polyspace Bug Finder
  
• Polyspace Code Prover
  
• Simulink Code Inspector
  

А для ISO 26262 поставляются сертификаты для:

• Simulink Check
  
• Simulink Coverage
  
• Simulink Requirements
  
• Simulink Design Verifier
  
• Simulink Test
  
• Simulink Report Generator
  
• Polyspace Bug Finder
  
• Polyspace Code Prover
  
• Embedded Coder
  
• HDL Coder
  
• PLC Coder
  

В зависимости от отрасли предоставляются пакеты поддержки квалификации инструментов DO Qualification Kit для авиации или IEC Certification Kit для автомобильной, железнодорожной и других отраслей.

Вместо выводов

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

1. Р-330, Руководство по квалификации программных инструментов, в частности:
   

• п. 2.0 Назначение квалификации инструмента
  
• п. 3.1. Уровни квалификации
  
• Справочные материалы D, вопрос D7
  

1. ГОСТ Р ИСО 26262-8, Глава 11, Уверенность в использовании инструментального программного обеспечения
   

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

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

Печально известен тот факт, что разработку ПО очень сложно планировать и реализовывать особенно трудно оценивать времязатраты на создание больших программных продуктов. Такое положение дел тянется уже с 1960-ых годов, все это подробно описано в книге Мифический человеко-месяц. Это книга Фреда Брукса, она была опубликована в 1975 и дополнена в 1995. Проблемы доведения процесса разработки программных продуктов до конца могут быть сформулированы законом Брукса: если вы не укладываетесь в сроки, дополнительные человеческие ресурсы только увеличат время на разработку.

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

Обзор платформ

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

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

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

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

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

Платформы для автомобильного ПО

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

Операционные системы

Все автомобильные ECU нуждаются в ПО, которое будет управлять различными аппаратными компонентами, а также в приложениях, которые и будут выполняться блоком управления.

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

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

Некоторые блоки управления имеют повышенные требования к безопасности, и им нужны системы, прошедшие сертификацию (например, по стандарту ISO 26262). В настоящие момент, ни у одной из версий Linux нет таких сертификатов. В таких блоках используют QNX, Green Hills и другие аналогичные операционные системы, имеющие сертификаты безопасности.

Информационно-развлекательная системы высший уровень развития систем, использующих ОС. На рынке платформ ОС идет битва между QNX и различными версиями Linux AGL, Android и GENIVI-совместимыми версиями. Android от Google развивается семимильными шагами. Успех Android связан с основанием Открытого автомобильного альянса (OAA) в 2014 году. В настоящее время в этот альянс входят 60 брендов, включая ведущих OEM-производителей вроде Chrysler, Fiat, Ford, GM, Honda, Hyundai, Mazda, Mercedes-Benz, Nissan, Renault, Toyota и VW.

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

ОС-гипервизор

Гипервизор это небольшая программная платформа для управления несколькими ОС и их приложениями.

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

Можно привести два примера, демонстрирующих преимущества гипервизоров. Первый пример: резервный монитор, который должен обязательно быть установлен на всех продаваемых в США автомобилях является компонентом систем с повышенными требованиями к безопасности. Второй пример: дисплей в информационно-развлекательных системах может быть идеальным запасным средством для вывода информации, но при этом в этой схеме не может использоваться ОС Linux, поскольку у нее нет необходимых сертификатов безопасности. Решением может стать гипервизор, интегрирующий Linux с QNX, Green Hills или другими ОС с сертификатами безопасности.

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

Телематические системы

Телематические системы имеют встроенные программные платформы, взаимодействующие с SaaS-сервисами, работающими с телематическими данными. В бортовых телематических системах используется операционные системы, и лидером в этом сегменте рынка является QNX (за счет того, что именно QNX используется в OnStar). Ведущие поставщики первого уровня встраивают в телематические системы программное и аппаратное обеспечение. Некоторые из Tier-1 поставщиков информационно-развлекательных систем также являются ведущими поставщиками телематических систем.

Программные платформы для телематических систем на основе SaaS являются собственностью поставщика телематических услуг (TSP) (таких как OnStar, SiriusXM, Verizon Telematics и WirelessCar). OnStar используется только в автомобилях от GM, но у других поставщиков есть целый ряд OEM-клиентов. Система WirelessCar в настоящее время в основном принадлежит VW, и вливание дополнительных ресурсов, вероятно, расширят его позиции на рынке.

Поставщики телематических услуг начинают использовать облачные ресурсы Microsoft, AWS и Google эти компании внедряют SaaS-платформы для функциональности сетевых автомобилей.

Информационно-развлекательные системы

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

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

Таким образом, в связке с информационно-развлекательной системой могут использоваться несколько разных программных платформ. Ключевой программной платформой в данной схеме является ОС, поскольку именно она косвенно управляет всем ПО, связанным с информационно-развлекательной системой. В этих системах основную долю рынка занимают различные ОС из группы Linux, в частности все более важной становится Android. Впрочем, выбор ОС для информационно-развлекательной системы сильно варьируется в зависимости от OEM-производителя.

Также во многих информационно-развлекательных платформах используются навигационные программные системы примерно в 25% (доля зависит от страны). Навигационные программные платформы, как правило, поставляются компаниями, специализирующимися на навигации в автомобильной и других промышленностях. Tier-1 Поставщики также могут поставлять навигационное программное обеспечение.

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

Интеграция смартфонов и мобильных приложений

В настоящее время смартфон стал неотъемлемой частью жизни водителя. Многие водители хотят использовать приложения из своих смартфонов в информационно-развлекательных системах для того, чтобы меньше отвлекаться не девайс. Некоторые OEM-производители разработали платформы для интеграции мобильных приложений в информационно-развлекательные системы. Впрочем, популярность CarPlay от Apple и Android Auto затмила всех остальных. Многие информационно-развлекательные системы поддерживают как CarPlay, так и Android Auto, чтобы иметь возможность взаимодействовать с большинством современных смартфонов. Baidu CarLife используется в основном в Китае, и там у этой системы очень сильные позиции, поскольку Android Auto в Китае недоступна.

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

С CarPlay работают более 500 моделей автомобилей от 65 разных автопроизводителей. Android Auto работает в примерно сопоставимом количестве автомобилей от 60 автопроизводителей.

Виртуальные личные ассистенты

Голосовые ассистенты, они же виртуальные личные ассистенты (VPA) хорошо зарекомендовали себя в автомобильной промышленности. Многие водители используют голосовых ассистентов в своих смартфонах или в домашних устройствах. OEM-производители пробовали создавать своих ассистентов, но высокотехнологичные платформы с голосовыми ассистентами взяли верх. Ведущими разработчиками голосовых ассистентов являются те же компании, что лидируют и на рынке умных домов и смартфонов: Amazon и их Alexa, Google и их ассистент, Apple и Siri. Достижения в области ИИ и технологий распознавания голоса сформировали спрос на голосовых ассистентов, поскольку они помогают водителям меньше отвлекаться.

Существует два способа использования голосовых ассистентов в автомобиле: через интеграцию мобильных приложения в CarPlay или Android Auto или через отдельную программную платформу с ассистентом в рамках автомобильной информационно-развлекательной системы. Лидером в области интегрированных ассистентов является Alexa, ассистент от Android держит крепкое второе место. Siri от Apple в основном используется в CarPlay, поскольку Apple является лидером на рынке интеграции смартфонов. Alexa и ассистент от Google также используются для интеграции мобильных приложений.

Подписывайтесь на каналы:
@TeslaHackers сообщество российских Tesla-хакеров, прокат и обучение дрифту на Tesla
@AutomotiveRu новости автоиндустрии, железо и психология вождения

---

Читать еще полезные статьи:

• Бесплатные онлайн-курсы по Automotive, Aerospace, робототехнике и инженерии (50+)
• [Прогноз] Транспорт будущего (краткосрочный, среднесрочный, долгосрочный горизонты)
• Лучшие материалы по взлому автомобилей с DEF CON 2018-2019 года
• [Прогноз] Motornet сеть обмена данными для роботизированного транспорта
• Компании потратили 16 миллиардов долларов на беспилотные автомобили, чтобы захватить рынок в 8 триллионов
• Камеры или лазеры
• Автономные автомобили на open source
• McKinsey: переосмысляем софт и архитектуру электроники в automotive
• Очередная война операционок уже идет под капотом автомобилей
• Программный код в автомобиле
• В современном автомобиле строк кода больше чем