Введение в управление безопасностью беспилотных автомобилей

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

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

Введение в функциональную безопасность беспилотных автомобилей
Введение в такие понятия, как ISO 26262, безопасность, функциональная безопасность, оценка рисков, выявление опасностей и их снижение…prateek-sawhney97 .medium.com

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

Культура безопасности

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

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

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

Адаптация жизненного цикла безопасности

Давайте еще раз посмотрим на этапы, содержащиеся в V-модели, которые обсуждались в предыдущей статье для СМИ. Я включил изображение здесь для справки.

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

Допустим, например, что мы работаем над обновлением уже существующей системы автоматического торможения. Наша компания решила использовать новый электронный блок управления с более быстрым и мощным процессором. Однако функционал тормозной системы не изменился. Наш первый шаг — убедиться, что новый ЭБУ действительно не повлияет на тормозную систему. Если новый ECU не имеет никакого эффекта, нам, возможно, не придется ничего менять в конструкции. Мы также могли бы повторно использовать часть первоначального анализа функциональной безопасности. Однако нам все равно нужно провести тесты, чтобы убедиться, что новый электронный блок управления интегрируется с остальной частью системы. В плане безопасности нам нужно будет обсудить, является ли разрабатываемый продукт новым или просто модификацией. Затем мы адаптируем жизненный цикл безопасности и обсуждаем, какие разделы V-модели необходимо включить. Адаптация жизненного цикла безопасности позволяет нам сосредоточиться на новых частях продукта.

Роли и обязанности по управлению безопасностью

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

Как машинное обучение и искусственный интеллект меняют облик электронной коммерции? | Data Driven…
Компания, занимающаяся разработкой электронной коммерции, в настоящее время интегрирует усовершенствования, чтобы вывести качество обслуживания клиентов на новый уровень…www.datadriveninvestor.com

Соглашение об интерфейсе разработки

Цепочка поставок автомобилей обычно делится на трех игроков:

OEM
Поставщики первого уровня
Поставщики второго уровня

OEM означает производителя оригинального оборудования. Это известные автомобильные компании, которые продают автомобили потребителям, но OEM-производители не обязательно разрабатывают все свои автомобильные системы собственными силами. OEM-производители передают некоторые разработки на аутсорсинг так называемым поставщикам уровня 1. OEM и поставщик уровня 1, а затем берут на себя отношения клиента и поставщика. OEM может предоставить требования к тому, что должна делать система транспортного средства, а затем поставщик уровня 1 разрабатывает и производит систему для OEM. Или OEM-производитель может предоставить предварительный дизайн продукта, а затем уровень 1 доработает детали. Компании уровня 1 часто передают свою работу компаниям уровня 2 на аутсорсинг. Типичным примером может быть уровень 1, который получает электронный блок управления от компании уровня 2. Затем поставщик уровня 1 использует электронный блок управления для разработки системы автоматического торможения для OEM-производителя.

В плане обеспечения безопасности есть раздел, который называется "Соглашение об интерфейсе разработки" или DIA. DIA определяет ответственность за проектирование и производство между OEM и поставщиком уровня 1 или между поставщиком уровня 1 и поставщиком уровня 2.

Зачем включать Соглашение о интерфейсе разработки в план обеспечения безопасности?

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

Меры подтверждения

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

Резюме

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