ГОСТ Р МЭК 61513—2011
d)Документация по спецификации системы должна включать в себя спецификацию программного
обеспечения (см. 6.1.2.3).
e) В системах классов 1 и 2 должно быть определено распределение функций по подсистемам, т.е.
спецификация системы должна определять, какие подсистемы участвуют и/или являются необходимыми
для выполнения конкретной функции.
6.3.2.2 Характерныечерты
Характерные черты документации по спецификации системы:
a)документация должна быть ясной и четкой, чтобы ее недвусмысленно могли понять все заинтере
сованные читатели, особенно рецензенты, а также изготовители системы и лица, выполняющие работы по
интеграции и валидации:
b
) спецификация прикладных функций должна быть выполнена так. чтобы облегчить верификацию и
понимание со стороны инженерного и оперативного персонала АС. связанного с системами контроля и
управления:
c) спецификация системы должна разрабатываться с использованием документированных инженер
ных методов, инструментальных средств и руководств системы. Эти методы, средства и руководства дол
жны минимально отличаться от методов, средств и руководств, используемых при спецификации
требова ний к системе.
П р и м е ч а н и е — Методы и средства разработки программного обеспечения могут улучшить качество
проектной спецификации на систему даже в сравнении с проектной спецификацией на систему с жесткой
логикой:
d) спецификация на системудолжна быть написана и упорядочена с тем. чтобы облегчить выполне
ние оценки соответствия требованиям ксистеме и обеспечить основудля проведения проверки системы,
т.е. она должна облегчить полную идентификацию спецификаций (вместо объяснений и привлечения
до полнительной информации).
6.3.2.3 Верификация
a) Верификациюспецификации системы на соответствие спецификации требованиям к системе сле
дует проводитьдо завершения разработки детального проекта. Должна быть возможностьдля внесения
поправокдо установки на месте и сборки системы.
b
)Должна быть установлена эффективная связь между ответственными за спецификацию системы и
поставщиками оборудования для определения порядка верификации.
c) Верификациядолжнадокументально подтвердить соответствие и зарегистрироватьлюбое несоот
ветствие спецификации системы спецификации требований к системе.
d) Необходимо верифицировать правильность передачи из спецификации требований к прикладным
функциям в спецификацию прикладного программного обеспечения.
e) Для систем классов 1 и 2 любое несоответствие должно быть устранено или обосновано с точки
зрения безопасности за счет введения возможных компенсирующих мер.
f) Для систем классов 1 и 2 компоненты, увеличивающие сложность системы, но не обусловленные
требованиями к ней. должны быть выявлены, а их наличие обосновано сточки зрения безопасности.
П р и м е ч а н и е — Наличие особенностей, не предусмотренных спецификацией требований к системе,
может значительно увеличить сложность системы, что ведет к снижению уверенности в ее правильной работе.
6.3.3 Документация детального проекта системы
Проект может осуществляться в несколько стадий. Требования настоящего пункта относятся к окон
чательному вариантудокументации на систему, котораядолжна быть в наличии после завершения проект
ных работ, интеграции и валидации, когда система готова к поставке и внедрению на АС.
Документация детального проекта системы обычно может быть разделена на четыре группы:
- документация проекта системы:
- необходимый анализ (см. 6.1.3.1);
- документация на прикладное программное обеспечение;
- документация на компоненты оборудования и системное программное обеспечение.
П р и м е ч а н и е 1— Если система выполнена с применением существующих технических устройств, то
проектная документация на оборудование системы и программное обеспечение является частью документации
на существующее оборудование.
47