В данной статье будут рассмотрены необходимые шаги для создания устройства, отвечающего общим требованиям функциональной безопасности (ФБ). А также будет предложена архитектура простейшего «безопасного» (safety) генератора напряжения. Так как управляя напряжением, можно управлять практически любым устройством.
На сайте есть замечательные статьи (раз, два) на эту тему и книга на которых я вырос как инженер по ФБ.
Серия стандартов ГОСТ Р МЭК 61508 (IEC 61508) является базовой для Российских стандартов, определяющих порядок разработки устройств к которым предъявляются требования ФБ. Как известно, при разработке устройств, связанных с ФБ, существуют отраслевые стандарты регламентирующие порядок разработки (для железных дорог таковыми являются ГОСТ Р 52980-2015 «Требования к ПО», ГОСТ Р 34012-2016 «Общие требования к аппаратуре ЖД» и.т.д).
Согласно стандартов ГОСТ Р МЭК 61508 и IEC 61508 отказы делятся на 2 типа: систематические и случайные.
Систематические отказы определяются ошибками спецификации, проектирования, кодирования программного обеспечения, защита от них строится средствами организации жизненного цикла, к ним относится: верификация всех этапов жизненного цикла на соответствие требованиям, и валидация (валидационное тестирование) конечного продукта.
Случайные отказы рассчитываются как вероятности выхода из строя аппаратных средств, защита от них как правило определяется архитектурными решениями.
По стандартам все методы можно разделить на две группы: организационные и технические. К организационным методам относится: реализация жизненного цикла, применение стандартов кодирования, контроль производства аппаратных средств. К техническим методам относится: диверситет (с англ. diversity — разнообразие), резервирование, защита от окружающих воздействий, независимость и разделение компонентов, самодиагностика (каждый из данных методов необходимо описывать в рамках отдельных статей).
Основные организационные методы защиты от систематических ошибок описаны в приложениях ГОСТ Р МЭК 61508. В качестве примера рассмотрим систематическую составляющую программного обеспечения. При написании программного кода следует уделить большое внимание правилам кодирования и стандартам используемым при кодировании. Одним из известных стандартов при программировании на языке «СИ» является «MISRA-C», его применение улучшает безопасность системы. При этом существуют статические анализаторы ( анализаторами вообще полезно проверять любой код на предмет ошибок), способные проверять на соответствие стандарту «MISRA-C», одним из них является PVS-Studio .
Частичного диверситета программного обеспечения можно достигнуть за счет применения различных алгоритмов разработки ПО. Полный диверсистет программного обеспечения достигается только тогда, когда имеются две различные спецификации требований на программное обеспечение, разные команды программистов, разные средства программирования устройств при производстве т.е. данные программы должны быть абсолютно разными и процесс программирования устройств тоже должен быть разным. Так же при разработке программных средств необходимо защититься от ошибок инструментальных средств. Самым критичным ПО с точки зрения инструментальных средств являются компилятор в связке со стандартной библиотекой и линкер. Разнообразия инструментальных средств можно достигнуть, используя компиляторы «ARMCC» и «GCC». При этом некоторые версии «ARMCC» имеют сертификацию TUV на соответствие SIL-3 согласно IEC 61508, а «GCC» успешно применяется при разработке ПО Falcon 9 .
Рассмотрим результаты компиляции команды «Запись в порт»:
| Команда на языке «СИ» (ISO/IEC 9899): MDR_PORTE->CLRTX =0x0040 | |
|---|---|
| «GCC» | «ARMCC» |
| LDR r3, [pc, #20] | MOVS r0,#0x40 |
| MOVS r2, #64; 0x40 | LDR r1,[pc,#16]; @0x0000072C |
| STR r2, [r3, #36] | STR r0,[r1,#0x24] |
Даже на примере такой простой команды (как видно из таблицы), последовательность команд микроконтроллера разная и используются разные рабочие регистры. Что в некотором виде нам обеспечивает «разнообразие», тем самым уменьшая вероятность ошибок по
Рассмотрим методы защиты от случайных ошибок на примере устройства, управления электромагнитным реле, представленного на рисунке. Для того чтобы определить методы защиты необходимо выявить опасные отказы оборудования. Как известно реле управляется подачей напряжения на его обмотку, в этом случае опасным отказом для данного устройства будет несанкционированное появление напряжения достаточного для срабатывания реле. Данное устройство строится на архитектуре 2 из 2. В данной архитектуре MCU_А и MCU_B должны получать команды по физически разделенным сетям.
Рисунок — схема безопасного сопряжения
В рамках данной статьи не будем полностью описывать дерево отказов, поэтому рассмотрим одну из наиболее вероятных цепочек событий, приводящую к опасному отказу:
- Пробивается оптрон U1
- Пробивается ключ K2
- Пробивается трансформатор
Интенсивность наступления событий данного типа определяется по формуле
. Так как все три отказа связаны между собой интенсивность данной цепочки будет определяться формулой 
. При грубых допущениях интенсивность отказов данной цепочки составляет менее чем (10e-15) 1/ч, в предположении что отказы могут накапливаться в течении 24 часов. Рассмотрим еще один из отказов: выход из строя MCU_A и MCU_B так, что они «случайным образом» генерируют последовательность импульсов на выходе.
Под «случайным образом» понимается выполнение микроконтроллером как минимум девяти команд (три записи в порт), при этом напряжение на выходе будет зафиксировано двумя микроконтроллерами и будет выдана ошибка несоответствия принятой и «выданной команды». Интенсивность данных событий является крайне низкой так как: два МК одновременно должны будут выполнить 9 команд (не говоря о том что МК должны будут писать противополжные значения в порты, через определенные интервалы времени для того чтобы на выходе сформировать напряжение необходимое для срабатывания реле).
В заключение следует отметить, в качестве методов повышения функциональной безопасности рекомендуется применять:
- диверсификацию программно-аппаратных средств;
- самодиагностику всех ресурсов микроконтроллеров (ОЗУ, ПЗУ, АЛУ, рабочие регистры и.т.д), а также узлов устройства;
- снижение параметров элементов схем относительно предельных значений (De-rating), для обеспечения лучших эксплуатационных характеристик и снижения вероятности отказов.
Все перечисленные методы могут быть использованы при разработке устройств, отвечающих требования ФБ.
Р.S. В рассмотренном примере для снижения вероятности отказов по общей причине можно один из микроконтроллеров заменить на FPGA.
Всем спасибо за внимание (это моя первая статья)!
Комментарии (17)
lamerok
25.12.2019 14:33+2Вообще с GCC могут проблемы (его не засчитают обычно), так как у него нет сертификата безопасности, зато он есть еще у GreenHill и IAR.
MDR_PORTE->CLRTX
Миландр :)
Хочу еще отметить, что для получения сертификата на ПО недостаточно следовать только рекомендациям по используемым алгоритмам, но еще необходимо следовать процессам...
По которым должны быть требования к ПО, отдельно требования к частям которые влияют на надежность, архитектура ПО должна полностью трассироваться с требованиями, отдельно в ней также должны быть выделены части критические по надежности и опять же трейс с требованиями должен быть от кода до требований, чтобы можно было посмотреть, вот код, который покрывает вот эту часть архитектуры, которая покрывает вот эти требования.
Тоже самое касается наличия юнит тестов и статического анализа — они должны быть обязательно для Си и С++, должен быть файл с результатами и покрытием. Для статического анализатора, все задавленные предупреждения должны быть объяснены и выведены в отчет.
В общем, Безопасность по этому МИК определяется не только наличием диагностики ALU, ОЗУ, ПЗУ, регистров… и хорошим тулом для проверки, но и процессами. И это не маловажный факт, который при сертификации обязательно спрашивают (Ну по крайней мере при международной)
VLADIMIR_KANDALOV Автор
25.12.2019 15:11+1Спасибо за столь содержательный комментарий.
но еще необходимо следовать процессам...
следование процессам определено как жизненный цикл в ГОСТ Р МЭК 61508-1-2012, детализация требований по аппаратной части производится в ГОСТ Р МЭК 61508-1-2012, а по программной в ГОСТ IEC 61508-3-2012 (действует с 1.07.2019).
В общем, Безопасность по этому МИК определяется не только наличием диагностики ALU, ОЗУ, ПЗУ, регистров… и хорошим тулом для проверки, но и процессами. И это не маловажный факт, который при сертификации обязательно спрашивают
— я думаю очень важный факт так как мало правильно разработать софт и железо, нужно ещё предоставить артефакты (свидетельства) следования жизненному циклу, а так же доказать правильность и корректность работы.VLADIMIR_KANDALOV Автор
25.12.2019 16:04допущена ошибка ГОСТ IEC 61508-3-2012 (год не тот), а ГОСТ IEC 61508-3-2018
yarston
25.12.2019 14:53В устройствах с МК очень часто программа во флеш слетает, так что использование МК это уже серьзный минус к безопасности.
VLADIMIR_KANDALOV Автор
25.12.2019 15:25ну во первых у всех МК есть интенсивности отказов, во вторых на данный момент очень много производителей сертифицировали свои МК на соответствие SIL3 ST, у nxp тоже есть подобные МК, даже миландр собирается выпускать МК с контролем памяти (MPU)
lamerok
25.12.2019 16:55Факт слёта флеша сам по себе не является преградой для получения SIL сертификата, потому что флеш слетит в любом случае, вопрос только когда и какова вероятность этого. А она значительно ниже, чем слёт ОЗУ.
Но важно другое, надёжное устройство должно определить факт этого слёта и перевести устройство в безопасный режим, т. е. не исправить ошибку (исправление ошибок, как раз не рекомендуется), а выставить сигнал Аварии, чтобы остальная система знала, что датчику доверять нельзя. В токовых датчиках — это выставить сигнал ниже 3.6 мА, или выше 23 mA..
VLADIMIR_KANDALOV Автор
25.12.2019 18:13можно написать тесты для ОЗУ ( данные тесты как правило позволяют выявить константные отказы "0"и "1")- они позволяют зафиксировать отказ
lamerok
25.12.2019 19:10Да, отказ ОЗУ можно зафиксировать, но например, проверить, что бит в ОЗУ был изменен с 0 на 1 уже найти не так просто, если константа там лежит долго, то вместе с ней придется хранить и контрольную сумму, либо использовать для хранения таких данных ОЗУ с ЕСС, у STM есть такие микроконтроллеры, которые имеют небольшую область ОЗУ с ЕСС
VLADIMIR_KANDALOV Автор
25.12.2019 19:44Факт искажения одного бита найти
можно если применять парафазное кодирование ( 1бит информации представляется двумя битами)
lingvo
25.12.2019 15:12+1По идее диверсификация ПО нужна не для того, чтобы уменьшить количество отказов, а для того, чтобы при дублировании системы управления(или безопасности) отказы по возможности не были связанными. Т.е. как в примере с Ариан 5, когда дублирующая система вылетела из-за такой же ошибки, так как использовала идентичное ПО и железо.
VLADIMIR_KANDALOV Автор
25.12.2019 15:32Здесь вводится такое понятие как опасный отказ, к опасным отказам могут приводит ошибки в спецификации требований к изделию, программном обеспечении, архитектуре изделия или совокупности данных ошибок + ещё не нужно забывать человека (который своими действиями может только усугубить ситуацию). И по ГОСТ Р МЭК 61508 рассчитываются вероятности опасных отказов.
MAESTROLIDER
25.12.2019 15:36Спасибо большое за статью. Я как раз осваиваю новое направление "функциональная безопасность" согласно ISO 26262. (они похожи с 61508).
Пишите ещё, это очень интересно и полезно.
З.ы.: в принципе ради подобных статей зарегистрировался в хабре :) сейчас буду искать как можно подписаться на Ваши статьи :)
Vladimir_Sklyar
26.12.2019 10:15+1Спасибо за статью! Приятно, когда уделяется внимание любимой ФБ))
Что можно было бы улучшить (в этот или в следующий раз)?
Уже были комменты про отсутствие информации о реализации жизненного цикла, управление ФБ и т.п. Чтобы избежать подобных замечаний, можно было бы обозначить то, о чем статья. Не о соответствии МЭК 61508 вообще, а о реализации определенного ограниченного набора технических и организационных требований.
Отлично, что затронута тема диверсификации (диверситета), это на хабре встречается довольно редко. Приведен интересный и наглядный пример по диверсной компиляции. Хотелось бы добавить, что существует определенный набор методов диверсификации, реализуемых в ПО, технических средствах, методологиях проектирования, разных командах разработчиков.
Больше всего у меня вопросов к схеме генератора, очевидно, было бы неплохо сделать более подробное описание. Используется 8 физически разных MCU? Тогда лучше было бы обозначить их по разному. Зачем нужны MCU генерации? В реле К1-К4 обмотки и контакты физически находятся в одном сегменте цепи (контактов нет на схеме)? Для MCU_В справа потерялось слово «выхода». Почему опасным отказом является появление напряжения, а не его отсутствие (для этого надо сказать пару слов об объекте управления)?
Формула расчета интенсивности отказов тоже требует пояснений. Точно интенсивности отказов должны умножаться, а не складываться?
А в целом хорошая статья, пишите еще.VLADIMIR_KANDALOV Автор
26.12.2019 13:31спасибо за комментарий!
Уже были комменты про отсутствие информации о реализации жизненного цикла, управление ФБ и т.п. Чтобы избежать подобных замечаний, можно было бы обозначить то, о чем статья. Не о соответствии МЭК 61508 вообще, а о реализации определенного ограниченного набора технических и организационных требований.
в дальнейшем учту
Используется 8 физически разных MCU? .
— это два разных MCU (MCU_A и MCU_B), все что написано простым текстом на структуре стоит рассматривать как пояснения
Зачем нужны MCU генерации? .
— MCU генерации нет, это просто поясняющая надпись
В реле К1-К4 обмотки и контакты физически находятся в одном сегменте цепи (контактов нет на схеме)?
К1-К4 – это не реле, это транзисторные ключи, они находятся в одном сегменте цепи. В данном случае собран мостовой преобразователь.
Для MCU_В справа потерялось слово «выхода»
исправил
Почему опасным отказом является появление напряжения, а не его отсутствие (для этого надо сказать пару слов об объекте управления)?
предполагаемый объект управления – Реле с несимметричными отказами, данный объект находится в безопасном состоянии при отсутствии напряжения на обмотке реле.
Точно интенсивности отказов должны умножаться, а не складываться?
Только при наличии всех трех отказов – произойдет опасный отказ (они все складываются по «И»), поэтому в формуле стоит знак умножить, последний коэффициент T – время в течение которого происходит накопление отказов.
Sap_ru
Минус статье поставлен по ошибке из-за крайне плохого интернета.