ГОСТРМЭК 62061—2013
6.10.2.3 Спецификация требований к безопасности прикладного программного обеспечения
должна быть достаточно подробной для того, чтобы обеспечить выполнение стадий проектирова
ния и внедрения СБЭСУ для достижения требуемой полноты безопасности и позволить выполнить
верификацию.
6.10.2.4 Разработчик прикладного программного обеспечения должен просмотреть информацию,
содержащуюся в спецификации для того, чтобы гарантировать, что требования определены адекват
ным образом. В частности, разработчик программного обеспечения должен в соответствии с настоящим
стандартом учесть следующее;
- связанные с безопасностью функции управления;
- конфигурацию или архитектуру системы;
- производительность и время отклика;
- интерфейсы оборудования и оператора;
- все соответствующие режимы работы машины, как указано в спецификации требований к без
опасности;
- диагностические тесты внешних устройств (например, датчиков и исполнительных элементов).
6.10.2.5 Заданные для безопасности программного обеспечения требования должны быть выра
жены и структурированы так. чтобы они:
- были ясными, пригодными для верификации, тестирования, поддержки и выполнения и сораз
мерными с уровнем полноты безопасности;
- были пригодными для того, чтобы можно было определить их источник в спецификации требова
ний к безопасности СБЭСУ;
- не содержали информации и описаний, которые являются двусмысленными.
6.10.2.6 Спецификация требований к безопасности программного обеспечения должна выражать
необходимые характеристики каждой подсистемы, предоставляя информацию, позволяющую выпол
нить соответствующий требованиям выбор оборудования. Должны быть определены следующие тре
бования для программируемых СБФУ:
- логика (то есть функциональность) всех функциональных блоков, выполняемых каждой под
системой;
- входные и выходные интерфейсы, предназначенные для каждого функционального блока;
- формат и диапазоны значений входящих и исходящих данных и их связь с функциональными
блоками;
- соответствующие данные, описывающие любые ограничения каждого функционального блока,
например, максимальное время отклика, предельные значения для проверки достоверности;
- функции, которые позволяют машине достигать или поддерживать безопасное состояние;
- функции, связанные с обнаружением, оповещением и обработкой ошибок;
- функции, связанные с периодическим тестированием СБФУ в автономном и неавтономном
режимах;
- функции, предотвращающие несанкционированные изменения в СБЭСУ:
- интерфейсы функций, не связанных с безопасностью;
- производительность и время отклика.
П р и м е ч а н и е — Интерфейсы включают в себя средства программирования как в автономном, так
и в неавтономном режиме.
6.10.2.7 В случае необходимости в документации должны использоваться полуформальные ме
тоды. такие, как логика, метод функциональных блоков или последовательностных диаграмм.
П р и м е ч а н и е — Руководящие указания по документированию программного обеспечения даны
в МЭК 61506. ИСО/МЭК 15910 и ИСО/МЭК 9254.
6.11 Проектирование и разработка программного обеспечения
6.11.1Проектирование и разработка встроенного программного обеспечения
Встроенное программное обеспечение, включенное в подсистемы, должно соответствовать
МЭК 61508-3 и требуемому УПБ.
П р и м е ч а н и я
1 См. также 6.7.3.2.
2 В приложении С рассматривается проектирование и разработка встроенного программного обеспечения,
используемого для реализации СБФУ для СБЭСУ.
36