Ключевые аспекты стандарта ISO 26262
ISO 26262 разделяет риски возникновения опасности на 4 уровня полноты автомобильной безопасности (УПБА): A, B, C и D (по возрастанию уровня риска и требований функциональной безопасности). Рейтинги УПБА рассматриваются в контексте целей обеспечения защищённости автомобиля и основанных на них требований функциональной безопасности. Команда разработчиков преобразует последние в технические требования к системе безопасности (СБ), которые описывают механизацию и ожидаемые уровни производительности аппаратного и программного обеспечения. Технические требования к СБ становятся дополнительными функциональными требованиями, помимо обычных требований к проекту, связанных с безопасностью. Сопоставление всех указанных целей и требований – ключевая часть плана обеспечения безопасности продукта. Другая его часть – документирование механизмов безопасности, обеспечивающих предотвращение или обнаружение и смягчение отказов.
ISO 26262 определяет требуемые методологии проектирования и показатели надёжности в зависимости от УПБА. Средства разработки обязаны обеспечивать отслеживание требований и необходимый уровень анализа, производительности и целостности в соответствии с заданным УПБА для соответствующей части проекта и процесса проектирования.
Проект электронной части автомобиля содержит в среднем от 2 до 7 целей безопасности, каждой из которых соответствует от 1 до 5 требований функциональной безопасности. Команда разработчиков выдвигает одно или несколько технических требований к СБ для реализации каждого функционального требования безопасности. Обычно множество частей проекта влияют на несколько технических требований к системе безопасности с разными УПБА. Для более строгих УПБА (B, C и D) требуется более полный анализ, включающий расчёт вероятности случайного отказа оборудования для каждой цели безопасности. Выполнение этих сложных требований к анализу становится проще благодаря дополнительной документации и атрибутам, задаваемым на уровне схемы, и должным образом документируемым при разработке топологии печатной платы.
Наиболее вероятные нарушения требований безопасности автомобиля, связанные с печатными платами
Электронные системы автомобиля очень разнообразны, и так же разнообразны цели обеспечения безопасности, связанные с ними. Современные электронные системы автомобиля с высоким (УПБА C и D) уровнем функциональных требований безопасности – это:
- беспилотное управление;
- электроусилитель руля;
- адаптивный круиз-контроль;
- система мониторинга усталости водителя (система контроля и удержания в полосе, система обнаружения препятствий);
- гибридный/электрический привод (инверторы для управления электромотором, управление АКБ, заряд батареи / преобразователи постоянного тока);
- управление приводом (системы управления двигателем/трансмиссией/КПП/дифференциалом).
Существует также огромное количество систем с УПБА A и B, таких как датчик дождя / управление стеклоочистителем, управление климатом (оттаивание), контроллеры генератора и распределения питания.
С учётом вариативности их специфики от продукта к продукту цели обеспечения безопасности обычно подпадают под одну из следующих категорий:
- потеря/неправильная работа рулевого управления;
- избыточный/недостаточный крутящий момент на колёсах (движение, регенерация и торможение);
- непредусмотренный крутящий момент на колёсах;
- риски, связанные с высоким напряжением / большим током;
- потеря/неправильный анализ данных с сенсоров;
- полная/частичная потеря функционала;
- потеря/неправильная работа обратной связи с водителем;
- потеря/неправильное взаимодействие с контроллером.
Параметры среды разработки печатных плат, критичные для функциональной безопасности
Для того чтобы убедиться, что требования безопасности не нарушены, необходим соответствующий функционал среды разработки. Его смысл состоит в том, чтобы проектный замысел был аккуратно и надёжно зафиксирован в физическом проекте вместе со ссылками на документацию, содержащую соответствующие функциональные требования. Среда разработки печатных плат должна обеспечивать следующие концепции целостности проекта:
- Целостность списка цепей, получаемого из схемы:
• схема представляет собой детализированный проектный замысел и является основным документом, описывающим проектный замысел;
• список электрических цепей определяет трассировку печатной платы;
• список электрических цепей определяет работу инструментов моделирования электрических цепей для верификации проекта. - Целостность перечня элементов, получаемого на основе схемы: перечень должен корректно представлять электрические компоненты, используемые в схеме.
- Целостность данных при генерации топологии (списка физических цепей) на основе списка электрических цепей: топология печатной платы должна отражать список электрических цепей, чтобы удостовериться в корректной имплементации цепей.
- Корректность воплощения электрических требований на печатной плате: требования к зазорам на основе импеданса, длинам цепей на основе задержек и ширине дорожек на основе падения напряжения должны быть корректно интерпретированы и реализованы.
- Целостность механических ограничений (зазоры и порядок слоёв):
• физические расстояния между трассами и компонентами должны быть правильно интерпретированы и реализованы для выполнения требований к зазорам и утечкам (во избежание скрытых сбоев и электрических опасностей);
• физические расстояния между компонентами должны быть правильно интерпретированы и реализованы для правильной сборки (во избежание скрытых повреждений, связанных со сборкой);
• данные по слоям должны быть правильно интерпретированы и реализованы, чтобы избежать нарушения вертикальных зазоров и утечек. - Целостность данных, передаваемых на изготовление: файлы ODB++, Gerber должны содержать точные данные для изготовления, сборки и тестирования печатной платы.
Краткие требования к документированию функциональной безопасности
Конечная цель – разработать и должным образом задокументировать продукт, соответствующий всем требованиям. Стандарт ISO 26262 сосредоточен на требованиях, касающихся безопасности, которые должны быть описаны в виде технических требований к СБ со ссылкой на соответствующие требования функциональной безопасности и представлены заказчику в форме, позволяющей продемонстрировать, что транспортное средство соответствует поставленным целям.
Каждому требованию функциональной безопасности соответствует рейтинг УПБА, который должен учитываться в процессе проектирования и анализа. Требования функциональной безопасности задаются на уровне системы (продукта). План безопасности разрабатывается параллельно с механизацией системы. Он определяет технические требования к СБ для выполнения функциональных требований безопасности для текущего уровня механизации. Технические требования к безопасности добавляются к общим функциональным требованиям системы. Чертёж механизации системы – критически важный этап в процессе документирования. Он должен чётко определять интерфейсы связи между системами автомобиля, а также охватывать технические требования безопасности, ассоциированные с программной и аппаратной механизацией.
Ключевая концепция состоит в том, что на протяжении всего процесса проектирования должна существовать двунаправленная цепочка документации технических требований безопасности. Документация должна включать в себя не только проект, но и связанные с ним расчёты. Эта цепочка технических требований должна также распространяться на процессы производства, тестирования и обслуживания.
Документирование технических требований к безопасности при разработке аппаратной части
Механизация систем – ключевой документ для демонстрации интерфейсов связи с системой более высокого уровня. Цели обеспечения безопасности, а также ассоциированные с ними функциональные требования задаются на уровне автомобиля. Для разрабатываемого продукта функциональные требования безопасности наследуются либо из системы-автомобиля, либо из системы более высокого уровня. Функциональные требования должны быть чётко определены и преобразованы в технические требования к программным и аппаратным функциям.
К ключевым элементам документации механизации систем относятся:
- «флаг» функциональной безопасности титульного блока;
- номер для отслеживания документа;
- границы системы (электрические, механические, экзогенные);
- интерфейсы:
- электрические (земля/питание, модификация мощности, коммуникационные шины, входные/выходные сигналы, напряжения/токи, скорости переключения, переходные величины / электромагнитная совместимость, импедансы);
- механическое крепление (шок/вибрация);
- поток воздуха;
- поток охладителя; - требования функциональной безопасности:
- технические требования безопасности;
- УПБА;
- безопасное состояние (требуемые модели неисправностей/ответы);
- интервал сбоеустойчивости;
- предел обнаружения.
Каждый элемент, связанный с безопасностью, должен ссылаться на соответствующие технические требования к СБ и их ключевые атрибуты, влияющие на проект.
Заключение
Для проектирования транспортных средств, соответствующих современным требованиям безопасности, необходим интегрированный программный комплекс, основанный на единой базе данных, включающий в себя не только схемотехнический и топологический редакторы, а также средства моделирования, анализа и верификации, но и содержащий инструмент, обеспечивающий отслеживание требований и ограничений на всех этапах проектирования – от разработки технического задания и системного уровня до конечной реализации и моделирования.
Если вам понравился материал, кликните значок - вы поможете нам узнать, каким статьям и новостям следует отдавать предпочтение. Если вы хотите обсудить материал - не стесняйтесь оставлять свои комментарии : возможно, они будут полезны другим нашим читателям!
