Оперативность, качество, доступные цены!
info@smart-sps.ru

Москва, ул. 6-я Радиальная, д.9​

Стандарт безопасности ISO 26262. Часть 1

Введение

 

ISO 26262 является производным от более общего стандарта функциональной безопасности IEC 61508 для электрических и электронных (E / E) систем в дорожных транспортных средствах. Он применяется на всех этапах проектирования, разработки и производства, а также для регламентирования отношений между автомобильной компанией и ее поставщиками. Стандарт ISO26262 предназначен для серийных дорожных транспортных средств (кроме мопедов) и направлен на минимизацию потенциальных опасностей, вызванных неисправностью или отказом встроенной бортовой электроники.

 

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

 

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

 

ISO 26262 и программное обеспечение

 

ISO 26262, части 2, 6 и 8, устанавливают особые требования к любому виду программного обеспечения, которое используется в системе управления, чтобы обеспечить требования безопасности. Для лучшего понимания проблем, связанных с системами автономного управления, полезно ознакомиться с соответствующими требованиями ISO 26262, применимыми к программному обеспечению.

 

Уровни ASIL и программное обеспечение

 

Стандарт ISO 26262 использует концепцию «ASIL» (уровень целостности автомобильной безопасности) для классификации требований безопасности для каждой подсистемы в транспортном средстве - они классифицируются от A (наименее критичный) до D (наиболее критичный); он также определяет концепцию «QM» (контролируемое качество) для элементов, которые могут не иметь отношения к безопасности или оказывать незначительное влияние на общую безопасность системы. В таблице ниже приведены примеры опасностей ASIL A-D.

 

Изображение выглядит как стол

Автоматически созданное описание

 

ISO 26262 присваивает определенный уровень ASIL опасностям/рискам, тем самым определяя требования безопасности, которые призваны снизить эти опасности/риски.

Разработчик системы управления распределяет уровни ASIL по подсистемам, таким образом, чтобы отдельные подсистемы имели более низкие уровни ASIL чем уровень опасности который был бы применим ко всей системе управления. При автономном вождении или ADAS (усовершенствованные системы обеспечения безопасности водителя) отказ системы может привести к катастрофическим результатам (как с точки зрения травм, так и с точки зрения управляемости транспортного средства), что означает, что такие системы неизменно будут получить рейтинг ASIL D.

 

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

Автоматически созданное описание

 

Рисунок 1: Отказ автономных систем вождения может привести к катастрофическим результатам

 

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

 

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

 

ISO 26262 устанавливает особые требования к любому виду программного обеспечения, которое используется в объекте управления, чтобы помочь обеспечить необходимый уровень безопасности. Эти требования делятся на две основные категории:

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

 

Высокое качество практики развития

 

Требования к качеству проектирования и разработке программного обеспечения в основном изложены в ISO26262-6, а вспомогательные процессы описаны в ISO26262-8. Хотя в части 6 четко указано, что рекомендации применимы только к программному обеспечению, имеющему отношение к безопасности, эти рекомендации являются хорошими руководящими принципами для всего программного обеспечения, как внутри, так и за пределами автомобильной промышленности, и аналогичны руководящим документам, указанным в других стандартах безопасности, таких как IEC 61508 (электронные устройства общего назначения), IEC 62304 (медицинское программное обеспечение) и другие.

 

Рекомендации, указанные для ISO 26262, включают:

 

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

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

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

• Удостовериться, что реализация программного обеспечения полностью соответствует проектам модулей и реализуется с высоким качеством (включая правила статического анализа, такие как MISRA, структурированные ручные проверки и т. д.)

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

 

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

 

Управление требованиями безопасности

 

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

 

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

 

В этом примере сопоставление требований технической безопасности объекта с требованиями функциональной безопасности довольно очевидна. Именно в этих случаях полностью реализуются концепция ISO 26262. Требования безопасности воплощаются в виде функциональных требований к объекту, поэтому легко проверить выполнение этих требований. Обратите внимание, что в то время как ISO 26262 представляет набор требований к проектированию, разработке или проверке. Стандарт позволяет разрабатывать систему более гибко. Требуется только, чтобы результат этой разработки был сопоставим с традиционной V-моделью.

 

Так в чем же проблема?

 

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

 

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

 

 

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

 

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

 

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

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

 

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

 

Проблема с нейронными сетями

 

Как упоминалось ранее, ISO 26262 предполагает, что существует четкое разграничение требований технической безопасности и требований безопасности программного обеспечения, которые должны выполняться функциональным объектом, до реализации и проверки. В системе, основанной на нейронных сетях, эта связь нарушена из-за самой природы реализации. В случае простого примера, приведенного ранее, требование безопасности может быть таким: «Если транспортное средство впереди замедляется и находится достаточно близко к рассматриваемому транспортному средству, снизьте скорость и избегайте столкновения». Это не «разработайте нейронную сеть и обучите ее, чтобы избежать столкновения».

 

Изображение выглядит как дорога, автомобиль, термакадам

Автоматически созданное описание

 

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

 

Эта проблема не является непреодолимой, поскольку в противном случае будущее автономного управления автомобилем никогда не наступит. Однако пока отсутствует стандартизация того, как это следует учитывать, и это не вписывается точно в структуру ISO 26262.

 

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

 

Наиболее ответственная часть - проверка. Как узнать, были ли соблюдены первоначальные требования безопасности? Эти вопросы связаны, очевидно с тем, что можно проводить дорожные испытания транспортного средства в различных условиях, и можно испытывать транспортные средства с большим количеством участниками дорожного движения в различных условиях. Такое тестирование проводят в настоящее время будь то автопилот Tesla, автоматизированный автомобиль Google или автономный автомобиль GM Cruise Automotive Orion. Автомобильные компании создают все более обширные программы тестирования, чтобы показать, что эти программные системы функционируют так, как они ожидают, и позволяют оперативно вносить исправления по мере обнаружения проблем.

 

Источник: www.siemens.com