Независимость программных элементов для IEC 61508 от CPU без блока защиты памяти

Question

Можно ли обосновать независимость элементов программного обеспечения с помощью IEC 61508, часть 3, Приложение F, чтобы компоненты, относящиеся к безопасности, могли иметь класс SIL 2, а компоненты, не относящиеся к безопасности (например, интерфейс пользователя, связь .) можно оставить без оценки и получить общий результат, который оценивается как SIL 2?

В частности, мне интересны мнения об этом, когда элементы безопасности и элементы безопасности не работают на одном процессоре и процессор не реализует любую форму аппаратной защиты памяти. Есть все виды вещей, которые можно сделать, чтобы гарантировать отсутствие помех программных элементов, таких как обеспечение целостности данных, передача данных строго контролируется и проверяется, планирование задач определено c (задачи, не связанные с безопасностью, гарантированно прекращаются ) и т. д.

Достаточно ли будет таких строго применяемых методов?

Answer 1

Если в MCU имеется любая прошивка, связанная с безопасностью, то все его программного обеспечения связана с безопасностью. Период.

Здравый смысл подсказывает, что любая ошибка в любом месте вашего кода может привести к неработающему коду, переполнению стека, выходу за границы, ложным прерываниям и так далее. Не говоря уже об ошибках, связанных с интерфейсом между безопасными и не относящимися к безопасности деталями.

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

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

Answer 2

Это вопрос, на который нет однозначного ответа. Ответ основан исключительно на мнениях или зависит от конкретных c условий.

Если у вас есть компания / организация, которая будет проводить оценку или сертификацию, вы должны спросить их ( изменить для уточнения: ) если ваш подход в порядке. Насколько я понимаю, стандарты разработки устройств, критичных для безопасности, вы должны документально подтвердить, что вы учли все возможные риски, а также то, как вы обнаруживаете или предотвращаете возможные неисправности.

В проекте, который должен быть сертифицирован на соответствие По аналогичному стандарту мы помещаем все связанные с безопасностью данные и код в определенные секции памяти c и «блокируем» секцию связанных с безопасностью данных, вычисляя CR C после выхода из функций, связанных с безопасностью, и проверяем CR C прежде чем войти снова.

Кроме того, мы проверяем, что функция «блокировки» данных вызывается из раздела кода, связанного с безопасностью, только путем проверки обратного адреса. Любая непредвиденная модификация данных, связанных с безопасностью, будет обнаружена, и устройство перейдет в безопасное состояние.

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

Редактировать (ответить на комментарий)

Из Конечно, мы сами убеждены в том, что этого решения достаточно для описанной цели в соответствующем устройстве.

Этот механизм является лишь частью концепции безопасности устройства.

CR Описанный здесь механизм C используется для защиты связанных с безопасностью данных в ОЗУ от нежелательного изменения функциями, не связанными с безопасностью, до обеспечения независимости функций, связанных с безопасностью, от не связанные с безопасностью функции. (Это не связано с защитой двоичной программы в памяти fla sh от модификации. Конечно, мы также делаем это, используя E CC fla sh и CRC.)

У нас есть много других мер безопасности меры в аппаратном и программном обеспечении, но они не связаны с вопросом, как оправдать независимость частей программного обеспечения без MPU.

Устройство, в котором используется описанная здесь методика, соответствует другому стандарту с уровнем безопасности ок. между SIL 1 и SIL 2.

Конечно, каждый пользователь должен проверить, достаточно ли этого решения для определенного c устройства.