Важность функциональной безопасности при автоматизации
Количество роботизированных операций за последние 10 лет возросло в тысячи раз. Появление гуманоидных роботов, роботов-доставщиков, роботов-транспортировщиков и прочих заставляет заниматься вопросом безопасности на новом уровне и выстроить системный подход к безопасности.
Именно разработку и конструирование «безопасных» роботов мы и рассмотрим в этой статье.
Сначала погрузимся в стандарты, на основании которых следует разрабатывать безопасных роботов, затем рассмотрим, как применять требования к архитектуре роботов, и, наконец, увидим, как обеспечивается безопасность компонентов робота.
Стандарты безопасности: рациональный подход к требованиям
Возможное неправильное поведение робота может привести к рискам. Например, подвергнуть угрозе жизнь и здоровье людей, взаимодействующих с роботом, или причинить финансовый ущерб.
Функциональная безопасность отвечает на главный вопрос: «Как уменьшить потенциальные риски при наличии сбоев или отказов компонентов робота?»
Именно поэтому вопросы функциональной безопасности ставятся во главу угла.
Разработка робота, а также его тестирование не всегда позволяют проверить все аспекты его безопасной работы даже на стадии готовности, так как чем сложнее становится робот, тем сложнее проверить весь вариативный ряд тестовых сценариев.
Проектирование роботов по стандартам функциональной безопасности позволяет начать разработку с анализа возможных рисков, которые они несут, и сфокусироваться на снижении их до приемлемого уровня при дальнейшей проработке его составных частей.
Стандарты функциональной безопасности охватывают практически все высокотехнологичные отрасли. Они описывают последовательно-параллельный процесс проектирования, разработки и тестирования различных систем (см. этот раздел), но под углом негативных сценариев.
У стандартов безопасности схожий подход независимо от отрасли, но со своими отраслевыми особенностями и уточнениями, связанными с применением и последствиями некорректной работы. Как пример: последствия в атомной энергетике существенно выше, чем последствия в робототехнической отрасли.
Функциональная безопасность позволяет сделать ранжир последствий и рисков на стадии проектирования — на основании этого уровня в дальнейшем определяются требования к тому, как снизить риск до приемлемого уровня.
Под приемлемым уровнем безопасности понимается такой уровень, который не несёт угроз жизни и здоровью людей при соблюдении элементарных требований по технике безопасности или правил по эксплуатации.
Пример: электрическая розетка.
У неё есть защитный корпус и специализированный разъём для электроприборов.
В неё невозможно случайно засунуть палец, но целенаправленные попытки залить её водой, просунуть гвоздь или разрушить защитный корпус приводят к тому, что розетка уже будет нести избыточный риск.
Именно с этой целью следует использовать отраслевые стандарты по функциональной безопасности, так как они фокусируют оценку на специфических рисках разрабатываемой системы.
Это, в свою очередь, позволяет осуществить анализ и выработать механизмы безопасности под конкретные особенности отрасли, в которой планируется эксплуатация.
Использование отраслевых стандартов позволяет не «переутяжелить» систему механизмами безопасности, то есть разработать необходимый перечень механизмов, который позволяет снизить избыточный риск до приемлемого, без избытка.
Избыточное количество механизмов безопасности существенно влияет на стоимость разработки, так как заставляет обеспечить почти стопроцентный охват в диагностике, а зачастую это разработка дополнительного (резервного) канала управления и контроля.
Пример
В качестве примера рассмотрим систему управления роботом, выполненную по мажоритарной логике k из n, которая использует кворум в принятии управляющих решений. Система детекции препятствий перед роботом реализована при помощи лидара, радара и камеры.
Существует два подхода в проектировании системы управления роботом.
• Первый вариант — использовать дорогостоящие сенсоры, которые выдают проверенную информацию в вычислитель системы управления. Такой системе можно доверять на все 100%.
• Второй вариант — использовать сенсоры, которые обеспечивают приемлемый уровень качества передаваемой информации в вычислитель.
Первый подход избыточен с точки зрения функциональной безопасности для роботизированных систем, поскольку возрастают трудозатраты на разработку сенсоров, проверку и доказательства соответствия стандарту. В результате стоимость сенсоров будет на порядок выше, чем если применять второй подход.
Первый подход оправдан и целесообразен только в тех случаях, где уровень риска значительный и возможные последствия могут привести к большому количеству жертв (атомная энергетика, аэрокосмическая отрасль, железнодорожный транспорт).
Второй подход более рационален, поскольку основная масса механизмов безопасности сконцентрирована в вычислителе системы управления.
Аллокация механизмов безопасности на вычислитель позволяет выбрать только один дорогостоящий компонент, который обеспечивает необходимый уровень вычислительной мощности и независимости, зачастую этот компонент будет даже дешевле, чем один высокоточный сенсор.
Дополнительно стоит отметить, что в погоне за реализацией первого подхода можно столкнуться с техническими и технологическими ограничениями в компонентной базе, которые приведут к тому, что стоимость робота в целом станет равна «чугунному мосту».
Это сравнение можно резюмировать в простой таблице.
| Первый подход (надёжность в сенсорах) | Второй подход (надёжность в системе) |
|---|---|
| Сенсоры (радар, лидар, камера) | Очень дорогие, максимально точные |
| Вычислитель | Базовая обработка |
| Где обеспечивается безопасность | В каждом сенсоре отдельно |
| Стоимость системы | Очень высокая |
| Гибкость | Ниже |
| Применение | Критические системы |
При оценке безопасности сложных робототехнических систем используют свой набор стандартов ГОСТ Р 60-й серии. Эта серия регламентирует разработку и позволяет конструировать роботов с минимальным уровнем опасности.
Безопасность роботов: теория встречается с реальностью
Однако стоит отметить, что полное соблюдение стандартов по проектированию (стандартов по электробезопасности и прочее) не всегда является панацеей от всех проблем, которые могут возникнуть при эксплуатации роботов.
Это связано с тем, что роботы уже выполняют сложные, нетривиальные задачи, а также используются в постоянно меняющейся внешней среде.
В них всё чаще используются цифровые модели или нейросети для выработки управляющих команд. А нейросети и модели могут ошибаться. Да, вероятность таких ошибок минимальна, но никогда не равна нулю.
Функциональная безопасность также не обеспечивает нулевую вероятность некорректного управления, но позволяет иметь независимый предохранитель с ожидаемым поведением для минимизации рисков.
Вышеперечисленные риски заставляют задумываться про функциональную безопасность при разработке роботов, которые планируются использоваться в одном пространстве с человеком.
Поскольку роботы всё чаще взаимодействуют с человеком, то необходимо постоянно проверять безопасность выработанных управляющих команд.
При проектировании роботов существует высокая вероятность пропустить дефект или предполагаемое некорректное проведение в специфических условиях внешней среды, которые очень сложно воспроизводятся при тестировании.
Этот дефект может быть обнаружен уже на стадии производства или в эксплуатации, что приводит к переработке конструкции на финальных стадиях проекта, а это несёт значительные финансовые потери.
Процесс функциональной безопасности охватывает все стадии разработки от идеи до окончательной валидации. Данный подход позволяет непрерывно отслеживать безопасную разработку на всех стадиях и подстадиях.
Также стоит понимать, что при проектировании роботов можно упереться в технологический предел, в этом случае необходимо предпринимать процедуры по снижению рисков.
Основные подходы снижения рисков — это резервирование, дублирование, распределённое управление и качество применяемых компонентов системы.
Рассмотрим их подробнее.
Резервирование
Предполагает наличие второго, а главное, независимого канала управления, который отличается архитектурно от первого канала. Один канал работает, второй «спит», переключение на второй канал осуществляется после отказа первого канала.
На рисунке ниже представлен пример резервированной системы управления автономной платформой.
Дублирование
Предполагает наличие второго канала управления, который идентичен первому. Оба канала работают одновременно. Отказ одного канала приводит к снижению выдаваемых характеристик на 50%.
На рисунке ниже представлен пример дублированной системы управления автономной платформой.
Распределённое управление
Означает, что одна подсистема отвечает за управление скоростью робота, вторая — за управление тормозами робота, и обе эти системы имеют свой набор механизмов безопасности.
На рисунке ниже представлен пример распределённой системы управления автономной платформой.
Проектирование роботов не останавливается на этапе компонентов и распределения функций между агрегатами, процесс функциональной безопасности погружается также на уровень разработки компонентов, а именно на уровень разработки аппаратной части и процесса разработки ПО.
В случае если для управления используются цифровые модели или нейросети, задача функциональной безопасности — ограничить возможность некорректного управления. Другими словами, загнать цифровую модель или нейросеть обратно в рамки допустимого поведения.
Такой подход позволяет обеспечить безопасность кода (соответствующего требованиям стандарта) только для модуля ПО, который осуществляет оценку поведения робота и ограничивает цифровую модель.
Подходы обеспечения безопасности компонентов робота
Основные подходы, предъявляемые стандартом функциональной безопасности на уровне аппаратной части, заключаются в том, чтобы любая неисправность электронно-электрических компонентов, которые влияют на формирование управляющих команд, были контролируемы.
Это означает, что должен отсутствовать скрытый отказ в аппаратной части, который потенциально может привести к некорректному поведению робота. В некоторых случаях необходимо контролировать работоспособность даже резисторов, конденсаторов или реле.
Это необходимо, чтобы в момент возникновения проблем с «железом» система могла это определить и выработать соответствующую реакцию, которая не приводит к опасным последствиям.
Стоит отметить, что контролировать 100% компонентов аппаратной части не требуется. Контроль необходим только для «важных» элементов, неисправность которых потенциально влияет на управляющие решения. Например, драйвер управления мотором, который участвует в движении робота.
Всеобщий контроль может ухудшить ситуацию, связанную с надёжностью робота. Другими словами, наличие большого числа дополнительных контролирующих компонентов только ухудшает показатели надёжности робота в целом, что в итоге влияет на частоту регламентных работ и стоимость обслуживания.
В стандарте по функциональной безопасности имеется отдельный показатель, который относится к надёжности роботизированных систем — «доля безопасных отказов».
Он предоставляет процентное соотношение между безопасными отказами и опасными, но диагностируемыми отказами. Для потенциально опасных систем робота доля безопасных отказов должна быть не ниже 60%, то есть необходимость обеспечения 100% диагностики нецелесообразна.
Тут стоит упомянуть, что функциональная безопасность не тождественна надёжности — и наоборот. Показатели надёжности подкрепляют функциональную безопасность, но не закрывают вопрос, поскольку надёжность в общем показывает качественные характеристики применяемых компонентов в изделии.
В примере с двумя подходами к проектированию видно, что нет смысла гнаться за 100%-ной диагностикой при проектировании системы. Это только раздувает количество элементов, что в целом приводит к снижению надёжности системы, так как в простом случае отказы компонентов суммируются.
Основные подходы, предъявляемые стандартом по функциональной безопасности на уровне разработки ПО, заключаются в том, чтобы обеспечить максимальную глубину и максимальный охват проверки кода, на каждой стадии интеграции (от Unit-тестов до HW-SW интеграции), для каждого компонента ПО.
Заключение
Как мы видим, стандарт по функциональной безопасности содержит довольно подробный свод правил и процедур, соблюдение которых позволит разработать робота с допустимым уровнем риска при эксплуатации его совместно с человеком.
Однако в реальном процессе разработки чёткое и беспрекословное соблюдение всех требований стандарта может быть затруднено из-за ряда технических ограничений и процедурных несоответствий.
Один из плюсов стандарта — то, что при достаточном уровне обоснования и наличия доказательной аргументации некоторые пункты могут не выполняться.
Задача функциональной безопасности — не следовать требованиям, описанным в стандарте, а обеспечить:
• глубокую проработку системы с учётом потенциальных угроз и негативных сценариев;
• разработку работоспособных механизмов безопасности;
• описание точек, где были отступления от стандарта;
• дополнительные требования к эксплуатации, сервису или конструкции робота.
Стандарт не предлагает технических решений по архитектуре систем робота, а лишь подсказывает, как распределяются требования функциональной безопасности между компонентами робота при различных архитектурных решениях, таким образом, чтобы не нарушался контур безопасности на робота в целом.
Также стандарт довольно разумно определяет минимально необходимый перечень показателей безопасности по аппаратной части и предъявляет требования к культуре написания и проверки ПО.
Теперь у нас есть представление, как разработать безопасного робота. В следующей статье мы поговорим о моральной оценке робота в сложных поведенческих ситуациях.