ГОСТ Р МЭК 60880—2010
6.2.4 Если во время эксплуатации станции обнаружен отказ, то программное обеспечение должно
вовремя и соответствующим образом на негоотреагировать. Это реагирование должно реализовываться в
соответствии с требуемыми в спецификации реакциями системы, а также в соответствии с правилами,
установленными МЭК61513 для проекта системы.
С целью исключения ложных срабатываний может потребоваться соответствующий анализ.
6.2.5 Самоконтроль не должен негативно влиять на выполнениесистемой непредусмотренных функ
ций.
6.2.6 Следует предусмотреть возможность автоматического сбора полезнойдиагностической инфор
мации. получаемой в результате самоконтроля программного обеспечения.
6.3 Периодические тестирования
6.3.1 Для компьютерных систем безопасности следует применять основные принципы МЭК 60671
для тех компонентов, которыедолжным образом не охватываются самоконтролем.
6.3.2 Программное обеспечениедолжно быть спроектировано так. чтобы соответствовало следую
щим требованиям периодических тестирований, проводимых в пределах установленных максимальных
интервалов (например, в периоды останова):
1) каждая функция безопасности должна охватываться периодическими тестированиями;
2) любой отказ при выполнении функции безопасностидолжен бытьобнаружен.
6.3.3 Следует предусмотреть возможность автоматического сбора полезнойдиагностической инфор
мации. получаемой в результате периодическихтестирований программного обеспечения.
6.3.4 Рекомендуется, чтобы качество программного обеспечения вспомогательных устройств, пред
назначенных для тестирований, соответствовало качеству оборудования, используемогодля валидации,
как указано в 10.2.
Нет необходимости в том. чтобы программное обеспечение вспомогательных устройств, предназна
ченныхдля тестирований систем класса 1. соответствовало всем требованиям настоящего стандарта.
6.4 Документация
6.4.1 Основная цель документации по спецификации требований к программному обеспечению состо
ит в формировании основы для разработки программного обеспечения. Однако не следует пренебрегать
аспектами лицензирования, посколькуданная документация может быть представлена регулирующим орга
нам. Поэтомуона может содержатьаспекты, не являющиеся важными для разработки программного обес
печения. но являющиеся основой для лицензирования.
Такими важнымидля лицензирования аспектами могут быть:
- рассмотрение рисков;
- рекомендации для функций или конструкционных элементов безопасности;
-другие элементы, обеспечивающие основудля специфичных требований;
- специальные требования регулирующих органов к структуре программного обеспечения, анализу
кода. В&В и т.п.
6.4.2 Спецификация требований кпрограммному обеспечению должна быть представлена встандар
тизованном формате, который недолжен влиять на понятностьдокумента (см. пункт А.2.3 приложения А).
6.4.3 Спецификация требований к программному обеспечениюдолжна быть однозначной, тестируе
мой или верифицируемой, а такжедостижимой.
Для улучшения согласованности и полноты аспектов спецификации требований кпрограммному обес
печению может применяться формализованный язык или проблемно-ориентированный язык.
Для этой цели могут использоваться автоматизированные программные инструменты.
6.4.4 Спецификация требований к программному обеспечению должна быть представлена ведущим
участникам процесса проектирования.
7 Проектирование и реализация
7.1 Принципы проектирования и реализации
7.1.1 Общие сведения
7.1.1.1 Проект программного обеспечения должен включатьсамоконтроль (см. А.2.2 приложения А).
7.1.1.2 При обнаружении отказа должны быть предприняты надлежащие действия в соответствии
с 6.2.
14