ГОСТ Р МЭК 62138—2010
6.2.1.2 Содержание
1 Документация по безопасностидолжна включать в себя описание:
- предусмотренныхфункций:
- интерфейсовс приложениями:
- ролевыхимен, типов, форматов, диапазонов ипределов входных, выходных иисключающихсиг
налов. параметров иданных конфигурации, еслиони присвоены;
- различных режимов работы исоответствующих условий перехода:
- любых ограничений, относящихся к использованию ранее разработанного программного обес
печения.
2 В соответствующих случаяхэти ограничения направлены на:
- обеспечение уверенности в правильности интегрированного программного обеспечения и
прое
к
та системы (например,границы использованиядинамичес
к
иразмещаемыхресурсов,та
к
их
к
а
к
память, производительность, полоса пропус
к
ания
к
оммуни
к
аций,ресурсы операционной системы).
- повышение способности интегрированного программного обеспечения и СКУ регистриро
вать от
к
азы, сигнализировать об их наличии и сохранять
к
ним устойчивость, пере
к
лючаться на
у
к
азанные режимыработы ивосстанавливаться после от
к
азов:
- обеспечениеуверенности в том. что ошиб
к
иоператоров иот
к
азы других систем илиобору
дования. с
к
оторыми объединенное программное обеспечение взаимодействует или разделяет
ресурсы, приведут
к
заданным режимамработы;
- гарантию того, что новое о
к
ружение ра
к
ов разработанного программного обеспечения
обеспечит все необходимыересурсы во всехусловиях использованияв СКУ.
3 Там. где необходимо, документация побезопасностидолжна такжепредоставлятьинформацию
о характеристикахфункций (например, в виде времени срабатывания).
Функции, интерфейсы и характеристики могут зависеть от режима работы, значений параметров,
данных конфигурации иусловий, предусмотренныхдля программного обеспечения.
4 До
к
ументация по безопасности должна та
к
же содержать информацию относительно:
- выполнения самонаблюдения, способности системы сохранять работоспособность при
дефе
к
тах и от
к
азах;
- требований ранее разработанного программного обеспечения
к
его о
к
ружению (например,
к
техничес
к
ому обеспечению илидругим
к
омпонентам программного обеспечения):
- взаимодействияинтерфейсовранееразработанногопрограммногообеспечениястехничес
к
им обеспечением,
к
оличеством информации, необходимым дляполного определения безопасности
фун
к
циональнойработы системы.
5 До
к
ументация по бвзопаыюсти операционной системы ранее разработанного
к
омпле
к
са
оборудованиядолжнаобеспечить поступление информации, позволяющейпроизводить правильное
прогнозирование относительно
к
лючевыхмоментовбезопасностисущественных элементоврабо
ты системы, например, ма
к
симального времениреа
к
ции соответствующих приложений илима
к
си
мального использования имиресурсов.
Та
к
ая информацияможет быть представлена в видеданных, формули/илимоделей, позволяю
щихвычислитьвремяреа
к
ции соответствующих приложенийииспользование имиресурсов длянаи
худшего случая. Если программное обеспечение предлагает слиш
к
ом широ
к
ий диапазон фун
к
ций,
интерфейсов и возможностей для
к
онфигурации, может быть затруднено обеспечение необходи
мой уверенности в правильности информации без знания фун
к
ционирования программного
обеспечения.
6.2.1.3 Свойства
1Эксплуатационные документы должны быть четкими, не допускающими двоякой интерпрета
ции.
6.2.2 Свидетельство корректности
6.2.2.1 Общие требования
1Должна быть подтверждена корректность ранее разработанного программного обеспечения по
отношению кегодокументации по безопасности.
Обычноподтверждениеявляется качественным, общепризнанныхметодов количественнойоцен
ки несуществует. Подходы,
к
оторые могут использоватьсядляпровер
к
и
к
орре
к
тностиранееразра
ботанного программного обеспечения, представлены нарисун
к
е 5. если:
- ранееразработанноепрограммное обеспечениебылосоздановсоответствии стребования
ми 6.1. 6.2.1.6.4. 6.5. 6.6. 6.7и 6.10.то обоснованиеправильностине требуется:
25