Дефиниция термина «автомобильное программное обеспечение» в контексте программно-определяемых транспортных средств

Введение, цель

Автомобильная промышленность относится к наиболее высокотехнологичным, наукоемким и конкурентным отраслям рос-сийской экономики [1–3]. Для обеспечения технологического суверенитета посредством импортоопережения [4] государство на федеральном уровне активно поддерживает ее развитие через финансирование научных и научно-технических проектов для создания инноваций и конкурентоспособной продукции, модернизацию производственной базы и запуск новых производств, а также через выдачу субсидий для льготного автокредитования [5–8].

На фоне развития приоритетных (ключевых) технологий [9] часть потребительской ценности современных транспортных средств (ТС) формируется за счет новых цифровых сервисов, товаров и услуг [10], предоставляемых автовладельцам и другим заинтересованным сторонам, использующим данные о работе ТС (страховые компании, топливные операторы, государственные органы и др.). Например, телематические системы, собирающие данные о характере движения ТС в режиме реального времени, могут использоваться для прогнозирования страховых случаев и оптимизации процессов технического обслуживания

[11; 12]. Ожидается, что к 2030 г. электронные системы и программное обеспечение будут составлять около 50 % стоимости нового ТС [13; 14], что отражает смещение акцента от аппаратной составляющей ТС к функциональности, обеспечиваемой электроникой и программным обеспечением.

Переход к программно-определяемым ТС [15–17] приводит к быстрому росту функцио-нальной и архитектурной сложности разрабатываемого программного обеспечения. В результате архитектура становится много-уровневой и сервисно-ориентированной [18; 19], где некоторые существующие уровни модифицируются и формируются новые. К новым уровням, в частности, относится уровень облачной платформы [20; 21], обеспечиваю-щий интеграцию ТС с внешними цифровыми сервисами и частичное управление его функциями из облака (рисунок).

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

Облачные атформа

Облачные сервисы обновлений «по воздуху»

Облачные телематические сервисы

Simplified architecture of software-defined vehicles

Блок те

Блок управления подушками безопасности (ACU)

услуга- (Network as a

технология «хранилище как услуга» (Storage as а Service, STaaS)

Технология «предприятие как услуга» (Enterprise as а Service, ENaaS)

Технология «контейнеры как услуга» (Containers as a Service, CaaS)

Связь между транспортными средствами (V2V)

1зьтранспортного средства с инфраструктурой (V2I)

Блок управления двигателем (MCU)

Упрощенная архитектура программно-определяемых ТС

Источник: составлено автором. Source: compiled by the author.

спечении, как правило, на электронных блоках управления (ЭБУ).

Подобная неоднородность терминологии становится методологической проблемой, поскольку все чаще значимая часть современной функциональности ТС находится вне его «внутреннего» контура. К таким функциям относятся, например, телематические и диагностические онлайн-сервисы, а также функции обновления «по воздуху», обеспечивающие развертывание новых функций без физиче ского вмешательства в ТС. Дополнительную методологическую сложность создает то, что облачные сервисы могут разрабатываться как универсальные решения для нескольких Original Equipment Manufacturer (OEM). В результате остается открытым вопрос, как нормативно закреплять их состав и границы, чтобы они были сопоставимы в цепочках поставок различных OEM.

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

Цель исследования – устранение существующего разрыва в терминологии путем предложения дефиниции термина «автомобильное программное обеспечение» в контексте программно-определяемых ТС.

Методы исследования

Исследование имеет жанр научного обзора, носит качественный характер и выполнено в рамках наблюдательного дизайна. Объектом анализа выступила общая (межотраслевая) и отраслевая (автомобильная) нормативная документация, регламентирующая разработку и жизненный цикл программного обеспечения. Выборка нормативной документации носила целенаправленный характер. Объем выборки заранее не фиксировался и определялся в ходе отбора по критериям включения и исключения до достижения смысловой насыщенности. Критерии включения: 1) действующий статус нормативной документации на момент анализа; 2) нормативная значимость для разработки и жизненного цикла программного обеспечения в части общих (межотраслевых) требо-ваний и требований автомобильной отрасли; 3) наличие релевантных терминов и/или опре-делений, описывающих программные сущности. Критерии исключения: 1) материалы, не являющиеся нормативной документацией; 2) нормативная документация с недействую-щим статусом; 3) нормативная документация, не содержащая терминов и/или определений, относимых к программным сущностям. Сбор данных осуществлялся путем кабинетного анализа официально опубликованной норма-тивной документации из публично доступных источников. Сбор и анализ данных проводились в период подготовки рукописи статьи. В качестве инструментария использованы процедуры сравнительно-терминологического анализа и обобщения: 1) извлечение опре-делений и связанных терминов из текстов нормативной документации; 2) сопоставление смысловых границ (охват, привязка к среде исполнения, уровень архитектурной декомпозиции); 3) выявление ограничений отраслевых формулировок применительно к распределен-ной реализации функций современного ТС; 4) формирование обобщающего определения «автомобильное программное обеспечение».

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

Результаты и дискуссия

В общих (межотраслевых) нормативных источниках в области разработки программного обеспечения (в частности, ГОСТ 19781– 90, ГОСТ Р ИСО/МЭК 9126–93 и ГОСТ Р 51904–2002) термин «программное обеспечение» трактуется как совокупность программ (системы обработки информации или компьютерных) и «программных документов, необходимых для эксплуатации этих программ» [22, с. 2; 23, с. 3], или как «программы, процедуры, правила и любая соответствующая документация, относящиеся к работе вычис-лительной системы» [24, с. 2]. Тем самым программное обеспечение понимается через пригодность к использованию и техническому сопровождению, а не только через факт существования программы. Документация в данном контексте оказывается не внешним приложением, а составной частью понятия. Правовые и регуляторные формулировки, напротив, как правило, сужают понятие до объекта учета и классификации. Так, например, в Постановлении Правительства Российской Федерации № 1236 программное обеспечение описывается как «программа для электронных вычислительных машин (ЭВМ) или баз данных» [25, с. 5], при этом документация не выделяется как обязательная составляющая. В свою очередь, термин «программа для ЭВМ» в соответствии со статьей 1261 части четвертой Гражданского кодекса Российской Федерации определяется как «представленная в объективной форме совокупность данных и команд, предназначенных для функционирования ЭВМ и других компьютерных устройств в целях получения определенного результата, включая подготовительные материалы, полученные в ходе разработки программы для ЭВМ, и порождаемые ею аудиовизуальные отображения» [26, с. 32]. В данном случае подчеркивается не только форма выражения программы, но и ее назначение - получение конкретного результата. Наряду с программным обеспечением используются близкие по смыслу термины «программное средство» и «программный продукт», однако их акценты различаются. ГОСТ 28806-90 трактует программное средство как объект, в состав которого входят программы и регламентирующие элементы поведения (правила, процедуры) [27]. При необходимости в его состав также могут входить сопутствующие данные и документация. В ГОСТ Р 51904-2002 термин раскрывается как программное обеспечение и связанные документы, которые могут быть не только разработаны «с нуля», но и модифицированы либо сгруппированы для удовлетворения требованиям контракта [23]. Тем самым в определение изначально включается контекст поставки и приемки результата. ГОСТ Р ИСО/МЭК 12207-2010 же смещает фокус на системную инженерию и жизненный цикл. Программное средство рассматривается как единая часть общей системы, выполняющая определенные функции, причем его выделение и создание описывается через процесс декомпозиции требований (от системных требований к требованиям к программным средствам), последующее проектирование, производство и интеграцию в состав системы [28]. В этой логике «программное средство»

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

«Программный продукт», в свою очередь, трактуется ГОСТ 28806-90 и ГОСТ Р ИСО/ МЭК 12207-2010 в двух взаимодополняющих плоскостях: как состав (что именно входит) -«набор компьютерных программ, процедур и, возможно, связанных с ними документации и данных» [28, с. 4] и как назначение в цепочке поставки (для чего предназначено) - «программное средство, предназначенное для поставки, передачи, продажи пользователю» [27, с. 81]. Тем самым вводится критерий предназначения для распространения и, по сути, коммерциализации.

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

В автомобильной промышленности ключевой нормативной основой для программного обеспечения, связанного с безопасностью Э/Э-систем ТС, выступает ГОСТ Р ИСО 26262. Однако стандарт не вводит универсального термина «программное обеспечение», а опирается на систему взаимосвязанных терминов, описывающих программные сущности через их роль в архитектуре Э/Э-системы и через среду исполнения. Э/Э-система согласно ГОСТ Р ИСО 26262-1-2020 трактуется как «система, которая состоит из Э/Э-элементов, включая программируемые электронные элементы» [29, с. 7]. Элементами могут выступать части аппаратных средств, модули программного обеспечения, компоненты (аппаратные средства или программное обеспечение) или системы (в том числе другие Э/Э-системы). В этой иерархии «компонент программного обеспечения» - это один или несколько модулей программного обеспечения, а «модуль программного обеспечения» – минимальный уровень архитектуры программного обеспечения, который может быть протестирован автономно. Дополнительно используется термин «встроенное программное обеспечение», который определяется как полностью интегрированное программное обеспечение, выполняемое в элементе обработки данных, т. е., по сути, в части аппаратного средства, обе-спечивающей ряд функций обработки данных. Тем самым стандарт выстраивает иерархию программных сущностей и определяет их место выполнения на аппаратной части ТС.

В свою очередь, требования ГОСТ Р ИСО 26262–6–2021 сфокусированы на разработке программного обеспечения ТС и регламентируют процессы формирования спецификации требований безопасности, архитектурного проектирования, детального проектирования и реализации, а также верификации, интеграции и тестирования именно встроенного программного обеспечения, функционирующего на аппаратной платформе Э/Э-системы [30]. Следовательно, требования стандарта распространяются на то программное обеспечение, которое непосредственно входит в причинно-следственные цепочки, способные привести к опасным отказам аппаратной части Э/Э-системы ТС. Вместе с тем любое другое программное обеспечение, способное влиять или выполнять функции ТС, но не являющееся встроенным программным обеспечением в составе Э/Э-систем, оказывается неохваченным ГОСТ Р ИСО 26262. Это происходит не по причине отсутствия такого программного обеспечения в программной экосистеме ТС, а вследствие более узкой предметной области данного стандарта.

Стандарт ISO/SAE 21434:2021 устанавливает инженерные требования к управлению рисками кибербезопасности на всех этапах жизненного цикла Э/Э-систем дорожных ТС, включая их компоненты и интерфейсы. Стандарт не вводит прямого определения термина «программное обеспечение», а рассматривает его в составе более общих сущностей: «компонент» (англ. component) – логически и технически отделимая часть и «элемент» (англ. item) – компонент или совокупность компо- нентов, реализующих функцию на уровне ТС [31]. Элемент включает в себя все электронное оборудование и программное обеспечение в ТС, участвующие в реализации конкретной функциональности на уровне ТС (например, торможение), т. е. электронное оборудование и программное обеспечение являются компонентами ТС. Следовательно, в контексте ISO/ SAE 21434:2021 программное обеспечение не выступает отдельным объектом, а включается в состав элементов и компонентов Э/Э-систем и участвует в реализации функций ТС.

Согласно ISO 24089:2023 программное обеспечение дорожных ТС рассматривается в контексте обновлений и определяется как совокупность компьютерных программ и связанных данных, предназначенных для установки на ТС, его системы или ЭБУ. При этом подчеркивается возможность динамической записи или модификации такого программного обеспечения в процессе выполнения [32]. Под системой ТС понимается функциональная группа одного или нескольких ЭБУ и подключенного оборудования (например, датчиков или исполнительных механизмов, не являющихся ЭБУ). Само ЭБУ определяется как встроенное в ТС устройство, программное обеспечение которого может быть обновлено. Из этого следует, что в логике ISO 24089:2023 программное обеспечение рассматривается прежде всего как то, что устанавливается и записывается в рамках Э/Э-архитектуры ТС на уровень ЭБУ и/или объединяющих их систем. Значит, программное обеспечение, используемое вне этого контура (на облачной платформе), не попадает в рамки определения термина данного стандарта.

Правила Организации Объединенных Наций № 156 и китайский стандарт GB 44496–2024 в области обновления программного обеспечения ТС тоже определяют программное обеспечение как часть электронной системы управления, представляющую собой совокупность цифровых данных, команд и соответствующих инструкций [33; 34]. Такое определение, с одной стороны, удобно для регулирования, поскольку позволяет однозначно соотнести программное обеспечение с Э/Э-системой ТС и процедурами управления обновлениями. С другой стороны, оно концептуально ограничивает программное обеспечение пределами Э/Э-системы ТС, не охватывает компоненты вне ее, хотя именно они могут обеспечивать обновления, управление конфигурациями, контроль совместимости и другие функции жизненного цикла ТС.

ГОСТ Р 58139-2024 устанавливает требования к системам менеджмента качества автомобильной промышленности, распространяя свое действие на организации, занимающиеся разработкой программного обеспечения [35]. Однако данный стандарт не содержит определения термина «программное обеспечение».

В модели оценки процессов разработки Automotive Software Process Improvement and Capability Determination (Automotive SPICE) версии 4.0 также отсутствует прямое определение термина «программное обеспечение» как самостоятельной сущности. Вместо этого модель оперирует системой частных понятий, предназначенных для описания структуры и представлений программной части изделия на разных уровнях декомпозиции и в разных процессах: «компонент программного обеспечения» (англ. software component), «модуль программного обеспечения» (англ. software unit) и «элемент программного обеспечения» (англ. software element) [36]. Программный компонент в процессах проектирования и реализации используется для описания архитектурной декомпозиции программной части на компоненты по иерархическим уровням. В процессе верификации реализованный компонент программного обеспечения, выступающий объектом проверки, представляется в виде проверяемых артефактов (например, исходный код, исполняемые файлы, библиотеки и пр.). Модуль программного обеспечения в процессах проектирования и реализации определяется как результат дальнейшей декомпозиции компонента программного обеспечения до нижнего уровня, который не принято делить далее. В процессе верификации реализованный модуль программного обеспечения также рассматривается через конкретные проверяемые артефакты. Элемент программного обеспечения используется как обобщающее обозначение для компонента или модуля, фиксируя элемент программной структуры без уточнения уровня. Таким образом, Automotive SPICE версии 4.0 фактически описывает «программное обеспечение» через набор терминов, задающих уровни структурирования и формы представления в зависимости от процессного контекста без привязки к конкретной среде исполнения.

Дополнительно ко всему в автомобильной промышленности широко используется открытая стандартизированная архитектурная платформа Automotive Open System Architecture (AUTOSAR), предназначенная для снижения сложности разработки программного обеспечения современных ТС за счет унификации архитектуры. Изначально была разработана классическая платформа (англ. classic platform) AUTOSAR, которая применялась для разработки программного обеспечения, исполняемого на аппаратной части ТС. В данном случае большая часть программного обеспечения разрабатывается и внедряется для конкретного ТС и не предусматривает существенного изменения в течение срока его службы. По мере развития технологий была разработана адаптивная платформа (англ. adaptive platform) AUTOSAR, ориентированная на высокопроизводительные вычисления, более гибкую конфигурацию и поддержку обновлений программного обеспечения «по воздуху» в течение всего жизненного цикла ТС. Программное обеспечение реализуется как набор сервисов, взаимодействующих между собой через стандартизованные интерфейсы, представляя сервисно-ориентированную архитектуру.

При этом AUTOSAR не закрепляет единое универсальное определение термина «программное обеспечение». Вместо этого стандарт фиксирует набор связанных понятий [37]: «базовое программное обеспечение» (англ. basic software), «стандартное программное обеспечение» (англ. standard software), «компонент программного обеспечения» (англ. software component) и «модуль программного обеспечения» (англ. software unit). Базовое программное обеспечение обеспечивает инфраструктурные функции ЭБУ и состоит из «интеграционного кода» и «стандартного программного обеспечения». Стандартное программное обеспечение, в свою очередь, трактуется как программное обеспечение, реализующее аппаратно-независимые инфраструктурные функции на ЭБУ и использующее стандартизованные интерфейсы AUTOSAR. Компоненты программного обеспечения выступают архитектурными элементами, которые соединены друг с другом через виртуальную функциональную шину. Под компонентами программного обеспечения также понимают модули программного обеспечения, обеспечивающие «интерфейс компонента программного обеспечения» «базового программного обеспечения». При этом термин «модуль программного обеспечения» интерпретируется в соответствии с определением, приведенным в ГОСТ Р ИСО 26262 [29; 37].

Опираясь на ряд определений, можно прий-ти к выводу, что терминология AUTOSAR в основном описывает программное обеспечение, исполняемое на аппаратной части. При этом данная терминология почти не затрагивает программное обеспечение, исполняемое в облачной части программной экосистемы ТС.

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

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

• [38] и ввести термин «автомобильное программное обеспечение».

Под «автомобильным программным обеспечением» предлагается понимать «совокупность компьютерных программ и программных документов, предназначенных для реализации функций дорожных ТС». Дорожное ТС в соответствии с ГОСТ Р 59483–2021 определяется как «ТС, предназначенное для эксплуатации на дорогах с твердым покрытием» [39, с. 2]. В данном контексте под функциями дорожных ТС следует понимать, включая, но не ограничиваясь, функции управления движением, обеспечения активной и пассив-ной безопасности, помощи водителю, информирования и мониторинга в режиме реального времени [9].

Заключение

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

Для устранения выявленного терминологического разрыва предложена дефиниция термина «автомобильное программное обеспечение». Данный термин вводится как верхний уровень описания и не заменяет термины, закрепленные в отраслевой норма-тивной документации по разработке и жизненному циклу программного обеспечения. Так, например, «встроенное программное обеспечение» по ГОСТ Р ИСО 26262 может рассматриваться как составная часть автомобильного программного обеспечения.

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

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