ГОСТ Р МЭК 62138-2010 Атомные электростанции. Системы контроля и управления, важные для безопасности. Программное обеспечение компьютерных систем, выполняющих функции категорий В и С

     4.4 Принципы градации

Вследствие распределения функций в отношении безопасности по категориям А, В и С соответствующая градация была введена и для требований к программному обеспечению СКУ, относящемуся к классам безопасности 1, 2 и 3.

Применение требований настоящего стандарта для класса безопасности 3 обеспечивает базовый уровень доверительности, соответствующий программному обеспечению СКУ, важных для безопасности. При этом руководствуются следующими принципами:

- наличие программы обеспечения качества;

- особое внимание уделяют тому, чтобы программное обеспечение:

1) вносило необходимый вклад в функции, важные для безопасности, и не оказывало на них отрицательного влияния,

2) соответствовало положениям спецификации требований программного обеспечения, которые устанавливают ограничения, важные для безопасности;

- обеспечение как можно более раннего информирования операторов СКУ об ошибках и отказах программного обеспечения, которые могут повлиять на функции, важные для безопасности, с тем чтобы можно было предпринять необходимые действия;

- наличие документально оформленных спецификаций требований к программному обеспечению, спецификаций проекта, спецификаций интеграции, спецификаций валидации и спецификаций модификации.

Для класса безопасности 2 в дополнение к принципам, уже изложенным для класса 3, в настоящем стандарте добавляют принципы:

- базирующееся на тестированиях и проекте обоснования того, что требование к характеристике, связанной с безопасностью (например, время реакции), будет выполнено для всех заданных условий;

- использование документации по безопасности для ранее разработанного программного обеспечения и для ранее разработанных устройств с встроенным программным обеспечением; цель такой документации состоит в том, чтобы обеспечить всю необходимую информацию для безопасного использования программного обеспечения или устройства; в частности, требование по представлению основанного на проекте обоснования эксплуатационных характеристик, связанных с безопасностью, устанавливает минимальный уровень необходимой информации;

- использование ранее разработанного программного обеспечения и устройств с встроенным программным обеспечением в соответствии с правилами, основанными на соответствующей документации по безопасности;

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

- обоснование корректности и функциональной пригодности ранее разработанного программного обеспечения и ранее разработанных устройств с встроенным программным обеспечением; процесс такого обоснования корректности использования ПО и устройств по классу безопасности 2 показан на рисунке 5;

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

- более жесткие требования по верификации, управлению конфигурацией ПО, выбору и использованию инструментальных программ и языков программирования, защищенности и сохранению работоспособности при отказе отдельных элементов;

- четкие требования к простоте, ясности, точности, проверяемости, тестируемости и модифицируемости.

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

Требования для программного обеспечения СКУ класса безопасности 1 приведены в МЭК 60880.

Требования и рекомендации настоящего стандарта приведены в разделе 5 (для класса 3) и 6 (для класса 2). Эти разделы могут применяться независимо друг от друга. Они имеют одинаковую структуру, так что подразделы 5.х.у и 6.х.у устанавливают требования и рекомендации по одному типу. Требования раздела 6, не идентичные требованиям раздела 5 (дополнительные или модифицированные), выделены курсивом. Все требования и рекомендации двух подразделов структурированы и пронумерованы, и те из них, которые относятся к одной проблеме, имеют одинаковый номер. Все другие пункты являются справочными.

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