Comments 19
Минус статье поставлен по ошибке из-за крайне плохого интернета.
Вообще с GCC могут проблемы (его не засчитают обычно), так как у него нет сертификата безопасности, зато он есть еще у GreenHill и IAR.
MDR_PORTE->CLRTXМиландр :)
Хочу еще отметить, что для получения сертификата на ПО недостаточно следовать только рекомендациям по используемым алгоритмам, но еще необходимо следовать процессам...
По которым должны быть требования к ПО, отдельно требования к частям которые влияют на надежность, архитектура ПО должна полностью трассироваться с требованиями, отдельно в ней также должны быть выделены части критические по надежности и опять же трейс с требованиями должен быть от кода до требований, чтобы можно было посмотреть, вот код, который покрывает вот эту часть архитектуры, которая покрывает вот эти требования.
Тоже самое касается наличия юнит тестов и статического анализа — они должны быть обязательно для Си и С++, должен быть файл с результатами и покрытием. Для статического анализатора, все задавленные предупреждения должны быть объяснены и выведены в отчет.
В общем, Безопасность по этому МИК определяется не только наличием диагностики ALU, ОЗУ, ПЗУ, регистров… и хорошим тулом для проверки, но и процессами. И это не маловажный факт, который при сертификации обязательно спрашивают (Ну по крайней мере при международной)
но еще необходимо следовать процессам...следование процессам определено как жизненный цикл в ГОСТ Р МЭК 61508-1-2012, детализация требований по аппаратной части производится в ГОСТ Р МЭК 61508-1-2012, а по программной в ГОСТ IEC 61508-3-2012 (действует с 1.07.2019).
В общем, Безопасность по этому МИК определяется не только наличием диагностики ALU, ОЗУ, ПЗУ, регистров… и хорошим тулом для проверки, но и процессами. И это не маловажный факт, который при сертификации обязательно спрашивают
— я думаю очень важный факт так как мало правильно разработать софт и железо, нужно ещё предоставить артефакты (свидетельства) следования жизненному циклу, а так же доказать правильность и корректность работы.
Факт слёта флеша сам по себе не является преградой для получения SIL сертификата, потому что флеш слетит в любом случае, вопрос только когда и какова вероятность этого. А она значительно ниже, чем слёт ОЗУ.
Но важно другое, надёжное устройство должно определить факт этого слёта и перевести устройство в безопасный режим, т. е. не исправить ошибку (исправление ошибок, как раз не рекомендуется), а выставить сигнал Аварии, чтобы остальная система знала, что датчику доверять нельзя. В токовых датчиках — это выставить сигнал ниже 3.6 мА, или выше 23 mA..
можно написать тесты для ОЗУ ( данные тесты как правило позволяют выявить константные отказы "0"и "1")- они позволяют зафиксировать отказ
Да, отказ ОЗУ можно зафиксировать, но например, проверить, что бит в ОЗУ был изменен с 0 на 1 уже найти не так просто, если константа там лежит долго, то вместе с ней придется хранить и контрольную сумму, либо использовать для хранения таких данных ОЗУ с ЕСС, у STM есть такие микроконтроллеры, которые имеют небольшую область ОЗУ с ЕСС
По идее диверсификация ПО нужна не для того, чтобы уменьшить количество отказов, а для того, чтобы при дублировании системы управления(или безопасности) отказы по возможности не были связанными. Т.е. как в примере с Ариан 5, когда дублирующая система вылетела из-за такой же ошибки, так как использовала идентичное ПО и железо.
Спасибо большое за статью. Я как раз осваиваю новое направление "функциональная безопасность" согласно ISO 26262. (они похожи с 61508).
Пишите ещё, это очень интересно и полезно.
З.ы.: в принципе ради подобных статей зарегистрировался в хабре :) сейчас буду искать как можно подписаться на Ваши статьи :)
Что можно было бы улучшить (в этот или в следующий раз)?
Уже были комменты про отсутствие информации о реализации жизненного цикла, управление ФБ и т.п. Чтобы избежать подобных замечаний, можно было бы обозначить то, о чем статья. Не о соответствии МЭК 61508 вообще, а о реализации определенного ограниченного набора технических и организационных требований.
Отлично, что затронута тема диверсификации (диверситета), это на хабре встречается довольно редко. Приведен интересный и наглядный пример по диверсной компиляции. Хотелось бы добавить, что существует определенный набор методов диверсификации, реализуемых в ПО, технических средствах, методологиях проектирования, разных командах разработчиков.
Больше всего у меня вопросов к схеме генератора, очевидно, было бы неплохо сделать более подробное описание. Используется 8 физически разных MCU? Тогда лучше было бы обозначить их по разному. Зачем нужны MCU генерации? В реле К1-К4 обмотки и контакты физически находятся в одном сегменте цепи (контактов нет на схеме)? Для MCU_В справа потерялось слово «выхода». Почему опасным отказом является появление напряжения, а не его отсутствие (для этого надо сказать пару слов об объекте управления)?
Формула расчета интенсивности отказов тоже требует пояснений. Точно интенсивности отказов должны умножаться, а не складываться?
А в целом хорошая статья, пишите еще.
Уже были комменты про отсутствие информации о реализации жизненного цикла, управление ФБ и т.п. Чтобы избежать подобных замечаний, можно было бы обозначить то, о чем статья. Не о соответствии МЭК 61508 вообще, а о реализации определенного ограниченного набора технических и организационных требований.
в дальнейшем учту
Используется 8 физически разных MCU? .— это два разных MCU (MCU_A и MCU_B), все что написано простым текстом на структуре стоит рассматривать как пояснения
Зачем нужны MCU генерации? .— MCU генерации нет, это просто поясняющая надпись
В реле К1-К4 обмотки и контакты физически находятся в одном сегменте цепи (контактов нет на схеме)?К1-К4 – это не реле, это транзисторные ключи, они находятся в одном сегменте цепи. В данном случае собран мостовой преобразователь.
Для MCU_В справа потерялось слово «выхода»исправил
Почему опасным отказом является появление напряжения, а не его отсутствие (для этого надо сказать пару слов об объекте управления)?
предполагаемый объект управления – Реле с несимметричными отказами, данный объект находится в безопасном состоянии при отсутствии напряжения на обмотке реле.
Точно интенсивности отказов должны умножаться, а не складываться?
Только при наличии всех трех отказов – произойдет опасный отказ (они все складываются по «И»), поэтому в формуле стоит знак умножить, последний коэффициент T – время в течение которого происходит накопление отказов.
Добрый вечер.
Скажи пожалуйста :
- Есть ли стандартизированные компиляторы для автомобильной промышленности? (в части реализации функциональной безопасности).
- Если мы у фирмы "Х" заказали разработку ПО и при этом фирма "Х" не предоставляет исходный код, то как можно будет проверить ПО на соответствие стандарту (например MISRA или AUTOSAR)? (в части реализации функциональной безопасности).
- Есть ли стандартизированный Статический анализатор (в части реализации функциональной безопасности)?
1)
Есть ли стандартизированные компиляторы для автомобильной промышленности? (в части реализации функциональной безопасности).
Пишут что могут, но я не проверял
2)
Если мы у фирмы «Х» заказали разработку ПО и при этом фирма «Х» не предоставляет исходный код, то как можно будет проверить ПО на соответствие стандарту (например MISRA или AUTOSAR)? (в части реализации функциональной безопасности).Без исходных кодов проверить нельзя.
3) 3-й вопрос пересекается с первым, данным направлением я не занимался.
данные вопросы выходят за рамки статьи.
Разработка «простого генератора напряжения» в соответствии с ГОСТ Р МЭК 61508 (IEC 61508)