ГОСТ Р 59390-2021

ФЕДЕРАЛЬНОЕ АГЕНТСТВО

ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

ГОСТР 59390— 2021

НАЦИОНАЛЬНЫЙ

СТАНДАРТ РОССИЙСКОЙ

ФЕДЕРАЦИИ

АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ ТЕХНОЛОГИЧЕСКИМИ ПРОЦЕССАМИ АТОМНЫХ СТАНЦИЙ

Термины и определения

Издание официальное

Москва Стаидартинформ 2021

Предисловие

• 1 РАЗРАБОТАН Акционерным обществом «Русатом Автоматизированные системы управления» (АО «РАСУ»)

• 2 ВНЕСЕН Техническим комитетом по стандартизации ТК 322 «Атомная техника»

• 3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому ре* гулированию и метрологии от 11 марта 2021 г. Ns 134-ст

• 4 ВВЕДЕН ВПЕРВЫЕ

Пробила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N9 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регупироеанию и метрологии в сети Интернет (www.gost.ru)

© Стзндартинформ, оформление. 2021

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

Содержание

• 1 Область применения

• 2 Термины и определения

Алфавитный указатель терминов на русском языке

Алфавитный указатель эквивалентов терминов на английском языке

Введение

Настоящий стандарт распространяется на автоматизированные системы управления технологи* ческими процессами атомных станций. Установленные в настоящем стандарте термины расположены в систематизированном порядке.

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

Приведенные определения можно, при необходимости, изменять, вводя в них производные при* знаки, раскрывая значения используемых в них терминов, указывая объекты, входящие е объем опре* делаемого понятия. Изменения не должны нарушать объем и содержание понятий, определенных в настоящем стандарте.

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

В стандарте приведены англоязычные (ел) эквиваленты для стандартизованных терминов.

Стандартизованные термины набраны полужирным шрифтом, их краткие формы, представлен* ные аббревиатурой. — светлым.

В стандарте приведены алфавитные указатели терминов на русском языке и их эквивалентов на английском.

ГОСТ Р 59390—2021

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ ТЕХНОЛОГИЧЕСКИМИ ПРОЦЕССАМИ АТОМНЫХ СТАНЦИЙ

Термины и определения

Automated control systems of tectinologtcal processes for nuclear power plants.

Terms and definitions

Дата введения — 2021—12—01

• 1 Область применения

  • 1.1 Настоящий стандарт устанавливает терминологию, относящуюся к таким понятиям, как система, процесс, модель, жизненный цикл и его типовые процессы, а также к проектной и конструкторской деятельности, архитектуре и функционированию систем контроля и управления (СКУ). участию человека при проектировании автоматизированных систем управления технологическими процессами.

  • 1.2 Термины, установленные настоящим стандартом, предназначены для применения во всех видах документации и литературы (по данной научно-технической отрасли), входящих в сферу работ по стандартизации и (или) использующих результаты этих работ.

  • 1.3 Стандарт носит обязательный характер для применения при составлении нормативных документов. стандартов организаций и технической документации в области создания автоматизированных систем, а также в деловой переписке между организациями при проектировании и эксплуатации автоматизированных систем управления технологическими процессами.

• 2 Термины и определения

• 1 _____________________________________________________________________________________________________________________________

аварийные условия: Отклонения от нормальной эксплуатации, которые accident conditions являются менее частыми и более тяжелыми, чем ожидаемые при эксплуатации события.

Примечание — Аварийные условия — это проектные аварии и запроектнъю условия.

[[1 ]. Определения]__________________________________________________________________________________

• 2 ___________________________________________________________________________________________

автоматизированная генерация кода: Функция автоматизированных automated code gen-

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

(ГОСТ Р МЭК 60880—2010, пункт 3.5]

• 3 ___________________________________________________________________________________________

автоматизированная система; АС: Система, состоящая из персонала и automated system;

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

Издание официальное

Примечания

• 1 В зависимости от вида деятельности выделяют, например, следующие виды АС: автоматизированные системы управления (АСУ), системы автоматизированного проектирования (САПР), автоматизированные системы научных исследований (АСНИ) и др.

• 2 В зависимости от вида управляемого объекта (процесса) АСУ делят, например, на АСУ технологическими процессами (АСУ ТП). АСУ предприятиями (АСУП) и т. д.

(ГОСТ 34,003-90, статья 1.1]________________________________________________________________

4___________________________________________________________________________________

архитектура СКУ: Организационная структура СКУ станции, которые яв- l&C architecture ляются важными для безопасности.

Примечания

• 1 См. также термины: «архитектура СКУ». «СКУ».

• 2 Организационная структура определяет, главным образом, основные функции, класс и границы каждой системы, взаимосвязь и независимость систем, приоритетность и голосование между одновременно действующими сигналами. ЧМИ.

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

• 4 Для простоты использования термин «общая архитектура СКУ» используется как краткая форма термина «общая архитектура СКУ, важных для безопасности».

(ГОСТ Р МЭК 61513-2020. пункт 3.27]__________________________________________________

5

базовая конфигурация: Информация, которая позволяет проверяемым и configuration baseline систематическим путем воссоздать версию программного обеспечения, включая все исходные коды, данные, файлы времени выполнения, документацию, конфигурационные файлы и скрипты для установки, которые включают в себя версию программного обеспечения, информацию о компиляторах, операционных системах и средствах разработки, используемых для создания версии программного обеспечения.

(ГОСТ Р МЭК 61508-4—2012. статья 3.7.4]

6

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

(ГОСТ Р МЭК 60709-2011. пункт 3.2]

7

библиотека: Набор связанных элементов программного обеспечения library (ПО), сгруппированных вместе, но индивидуально отбираемых для включения в окончательный продукт ПО.

(ГОСТ Р МЭК 60880-2010, пункт 3.24]__________________________________________________

8__________________________________________________________________________________

вспомогательные средства системы безопасности: Комплект обо- safety system support рудования, который обеспечивает такие виды обслуживания, как охлажде- features ние. смазка и подача энергии, необходимые для системы защиты (системы управления защитными действиями) и систем обслуживания устройств безопасности (исполнительных систем безопасности).

П2). В]

• 16 _________________________________________________________________________________

защищенность, информационная безопасность (кибербезопасность): security

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

(ГОСТ Р МЭИ 61513-2020. пункт 3.48)

• 17 измерение: Присвоение объекту количественной характеристики в measurement рамках формализованной процедуры в целях представления свойств объекта.

• 18 _________________________________________________________________________________________

изолирующее устройство: Устройство в контуре, не допускающее того, isolation device

чтобы неполадки в работе одной части контура были причиной недопустимых сбоев в других частях контура или в других контурах.

[ГОСТ Р МЭИ 60709-2011. пункт 3.5)

• 19 _________________________________________________________________________________

инициализировать: Установить счетчики, переключатели, адреса или со- initialize

держимое устройств памяти на нулевое значение или другие начальные значения в начале или в заданной точке выполнения компьютерной программы.

[ГОСТ Р МЭИ 60880-2010, пункт 3.22)

• 20 инкапсуляция: Метод разработки программного обеспечения, который со- encapsulation стоит в изолировании функции системы или набора данных, оперировании этими

данными внутри модуля и предоставлении точных технических условий для модуля.

• 21 _________________________________________________________________________________________

интеграция: Последовательная сборка компонентов и их проверка внутри integration

завершенной системы.

[ГОСТ Р МЭК 62138-2010, пункт 3.18)__________________________________________________

• 22 _________________________________________________________________________________

исполнительное устройство: Элемент. который непосредственно actuation device

управляет движущей силой исполнительного оборудования.

Д2), И)_________________________________________________________________________________________________________

• 23 _________________________________________________________________________________

исходная конфигурация: Информация о конфигурации, формально лривя- configuration baseline

занная к определенному моменту времени в жизни продукции или ее элемента.

Примечание — Исходная конфигурация, дополненная принятыми изменениями, составляет информацию о текущей конфигурации.

Ц4), статья 3.772]

• 24 _________________________________________________________________________________

кабельная трасса: Физическая магистраль, проходящая через станцию, cable route

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

[ГОСТ Р МЭК 60709-2011, пункт 3.3]

• 25 _________________________________________________________________________________

канал: Совокупность взаимосвязанных элементов в системе, которая channel

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

Ц2), К]

• 26_________________________________________________________________________________

канал связи: Особая линия логической или физической связи между communication channel субъектами.

Примечание — Канал облегчает установление соединения.

(ГОСТ Р МЭК 62443-3-3-2016. пункт 3.1.9}

27

категория функции СКУ: Одно из трех возможных обозначений (А. В. С) category of an l&C функций СКУ. устанавливаемое в результате рассмотрения влияния выполняв* function мой функции на безопасность.

Примечания

• 1 См. таюке термины: «класс СКУ». «функция СКУ».

• 2 ГОСТ Р МЭК 61226 определяет категории функций СКУ. Каждой категории соответствует набор требований, применяемый как к каждой функции (относительно их спецификаций, проекта, реализации, верификации и валидации}, так и к целому набору элементов, которые необходимы для реализации функции (относитегъно свойств и требуемой квалифжации) независимо от того, как эти элементы распределены в ряду взаимосвязанных СКУ. Для большей ясности этот стандарт определяет категории функций СКУ и классы СКУ и устанавливает связь между категорией функции и минимальным требуемым классом соответствующих систем и оборудования.

(ГОСТ Р МЭК 61513—2020, пункт 3.4]

28

класс СКУ: Одно из трех возможных обозначений (1. 2. 3) СКУ. важных для class of an l&C sys-безопасности. присваиваемое в результате рассмотрения требований, предъявля- tern емых к выполнению функций СКУ. имеющих разное значение для безопасности.

Примечание — См. также термины «категории функций СКУ». «элементы, важные для безопасности», «системы безопасности».

(ГОСТ Р МЭК 61513—2020. пункт 3.6]

29

комплекс оборудования: Набор аппаратных и программных компонен- equipment family тов. которые могут работать совместно в одной или более определенных архитектурах или конфигурациях.

Примечания

• 1 См. также термины «функциональность», «прикладное программное обеспечение». «библиотека прикладных программ».

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

• 3 Термин «платформа оборудования» иногда используется как синоним термина «комплекс оборудования».

(ГОСТ Р МЭК 61513—2020. пункт 3.17]

30

комплексирование: Процесс объединения компонентов программного aggregation обеспечения и аппаратных компонентов или того и другого в общую систему.

((4]. статья 3.117]____________________________________________________________________________________________

31

компонент: Одна из составных частей системы. Компонент может пред- component ставлять собой аппаратное или программное обеспечение и может сам состоять из других компонентов.

Примечания

• 1 См. также термины «СКУ». «оборудование».

• 2 Термины «оборудование», «компонент» и «модуль» часто испогъзуют как взаимозаменяемые. Взаимоотношения между этими терминами пока не стандартизованы.

• 3 Это определение подкомитета ПК 45 А МЭК в принципе совместимо с определением термина «компонент», приведенным в группе терминов Глоссария МАГАТЭ издания 2007 г. под названием «Structures Systems and Components (SCC)» (Структуры систем и компонентов). Тем не менее, поскольку там приведены примеры только компонентов аппаратного обеспечения, что может ввести в заблуждение читателя, подкомитет ПК 45 А МЭК предпочитает использовать определение, которое явно касается и компонентов программного обеспечения.

(ГОСТ Р МЭК 61513-2020. пункт 3.10]

• 32 _________________________________________________________________________________

компонент программного обеспечения: Один из элементов проекта, software component

составляющих часть программного обеспечения. Он может быть разделен на другие компоненты программного обеспечения.

[ГОСТ Р МЭК 62138-2010. пункт 3.29}__________________________________________________

• 33 _________________________________________________________________________________

компьютеризированная система: Система контроля и управления, функ- computer-based sys-

ции которой в большей своей части зависят от использования микропроцес- tern соров, программируемого электронного оборудования или компьютеров либо полностью определяются таким использованием.

Примечание — Эквивалентны следующему определению: цифровые системы. системы с программным обеспечением, программируемые системы.

[ГОСТ Р МЭК 60880-2010, пункт 3.11)

• 34 _________________________________________________________________________________

компьютерная программа: Набор упорядоченных команд и данных, кото- computer program

рыв описывают операции в форме, приемлемом для их выполнения компьютером.

(ГОСТ Р МЭК 60880-2010, пункт 3.10}

• 35 _________________________________________________________________________________

конвейер: Техника разработки программного обеспечения или аппарат- pipeline

ных средств, основанная на использовании выхода первого процесса в качестве входа второго процесса, в свою очередь, выхода второго — в качестве входа третьего и т. д.

Ц4), статья 3.2907]

• 36 контрольная точка; веха: Запланированное событие, которое исполь- milestone зуется для оценки развития.

• 37 конфигурация: Характеристика устройства компьютерной системы configuration или элемента, определяемая количеством и природой составляющих систему (элемент) частей и взаимосвязями между этими частями.

• 38 _________________________________________________________________________________

концептуальная модель: Модель понятий, характерных для некоторой conceptual model

сферы деятельности.

Ц4), статья 3.751]

• 39 _________________________________________________________________________________

критерий единичного отказа: Критерий (или требование), применяемый single failure criterion;

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

Д2]. К]_________________________________________________________________________________________________________

• 40 ___________________________________________________________________________

метод анализа шумов: Метод натурного испытания времени срабатыва- noise analysis tech-

ния датчиков, детекторов и преобразователей и оперативного обнаружения за- nique купориваний, пустот и протечек в трубопроводах измерения давления.

(ГОСТ Р МЭК 62385-2012. пункт 3.10]

модификация ПО: Изменение е уже согласованном документе (или до* software modification кументах), ведущее к изменению рабочей программы.

Примечание — Модификации ПО могут происходить в процессе пер* воначальной разработки ПО (например, устранение ошибок, обнаруженных на поздних этапах разработки) или когда ПО уже находится в эксплуатации.

(ГОСТ Р МЭК 60880—2010, пункт 3.36]

42

• 49 ___________________________________________________________________________

общий жизненный цикл безопасности СКУ: Необходимая деятельность, overall safety life су-относящаяся к реализации систем и оборудования, важных для безопасности, de of the l&C общей архитектуры СКУ и выполняемая в течение периода времени, который начинается с формирования требований СКУ из проектных основ безопасности АС и заканчивается, когда ни одна из СКУ не доступна к использованию.

Примечания

• 1 Общий жизненный цикл системы контроля и управления (жизненный цикл СКУ) определяет требования к жизненным циклам безопасности отдельных систем.

• 2 См. также термин «жизненный цикл безопасности системы».

(ГОСТ Р МЭК 61513-2020. пункт 3.34]

• 50 объект конфигурации: Агрегат, состоящий из аппаратных средств, configuration item программных средств или того и другого, который предназначен для управления конфигурацией и рассматривается в процессе управления конфигурацией

в качестве единой сущности.

Примечание — Объекты конфигурации могут сильно отличаться по сложности. размеру я типу, начиная от всей системы, включая все оборудование, программное обеспечение и документацию, до одного модуля или малого компонента оборудования.

• 51 _________________________________________________________________________________________

оператор: Какой-либо объект, осуществляющий работу системы. operator

Примечания

• 1 Роль оператора и роль пользователя могут возлагаться одновременно или последовательно на одно и то же лицо или организацию.

• 2 В контексте данного конкретного определения термин «объект» означает лицо или организацию.

(ГОСТ Р ИСО/МЭК 12207—2010, пункт 4.22]______________________________________________

• 52 _________________________________________________________________________________

описание архитектуры: Совокупность документов, описывающих архи- architectural descrip-

тектуру. lion

Ц4], статья 3.217]

• 53 отказ: Прекращение способности системы выполнять требуемую функ- failure цию или ее неспособность работать в установленных пределах, внешне проявляющиеся в видимых отклонениях от системных характеристик.

• 54 _________________________________________________________________________________

отказ по общей причине: Отказ двух или более конструкций. систем и common cause failure элементов вследствие единичного конкретного события или единичной конкретной причины.

Ц2], О]________________________________________________________________________________________________________

• 55 _________________________________________________________________________________

отказ программного обеспечения: Отказ системы из-за проявившейся software failure

проектной ошибки в компоненте программного обеспечения.

Примечания

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

• 2 См. также термины «отказ», «дефект», «дефект программного обеспечения».

(ГОСТ Р МЭК 61513-2020, пункт 3.52]

охват диагностикой: Часть опасных отказов, выявляемая автоматически- diagnostic coverage ми диагностическими тестами в неавтономном режиме (эту часть опасных от* казов вычисляют как отношение интенсивности выявленных диагностическими тестами опасных отказов к общей интенсивности опасных отказов).

Примечания

• 1 Охват диагностикой опасных отказов определяют с помощью следующего выражения:

РС=

где DC — охват диагностикой;

• — интенсивности выявленных опасных отказов;

• — общая интенсивность опасных отказов.

• 2 Данное определение справедливо при условии, что рассматриваемые компоненты имеют постоянную интенсивность отказов.

(ГОСТ Р МЭК 61508-4—2012, статья 3.8.6}______________________________________________

57________________________________________________________________________________

передача данных: Обмен данными между узлами связи через каналы data communication связи.

(ГОСТ Р МЭК 61500—2012, пункт 3.4}

58

периодичность испытаний: Время, прошедшее между запусками едина- test interval ковых испытаний на одних и тех же датчике и устройстве обработки сигнала, логическом модуле или конечном управляющем устройстве.

(ГОСТ Р МЭК 62385—2012. пункт 3.18]________________________________________________

• 59 _______________________________________________________________________________

план проекта: Документ, содержащий описание технических и управлен- project plan

ческих подходов, которые следует реализовать в проекте.

((4). статья 3.3182]______________________________________________________________________________

• 60 _______________________________________________________________________________

предельные технические характеристики: Пределы, определяющие ко- performance limits

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

Примечание — Точность, время реакции и устойчивость измерительного канала является атрибутами предельных технических характеристик.

(ГОСТ Р МЭК 62342—2016. пункт 3.13]________________________________________________

• 61 ______________________________________________________________________________________

приемочное испытание: Установленное договором испытание с целью acceptance test

доказать заказчику, что устройство выполняет определенные технические условия (спецификации).

(ГОСТ Р МЭК 61559-1—2012. пункт 3.2.2]

62

программируемое устройство: Интегральная схема, конфигурируемая HDL-programmed (для систем контроля и управления атомных станций) с помощью языков опи- device; HPD сания аппаратуры и сопутствующих программных инструментов.

((5]. пункт 3.7]

• 63 _________________________________________________________________________________

программируемый (логический) контроллер; ПЛК: Цифровая электрон* programmable (logic)

ная система, предназначенная для применения в производственной среде, controller; PLC которая использует программируемую память для внутреннего хранения ори* оптированных на потребителя инструкций по реализации таких специальных функций, как логика, установление последовательности, согласование по вре* мени. счет и арифметические действия для контроля посредством цифрового или аналогового ввода/вывода данных различных видов машин или процессов. Как ПЛК, так и связанные с ними периферийные устройства разрабатываются таким образом, чтобы они могли легко интегрироваться в любую промышлен* ную систему управления с применением всех встроенных в них функций.

[ГОСТ Р МЭК 61131*1—2016. пункт 3.5]__________________________________________________

• 64 __________________________________________________________________________________

программная составная часть: Исходный код. объектный код. контроль* software item

ный код. контрольные данные или совокупность этих составных частей.

Примечание — Программная составная часть может рассматриваться как системный элемент.

[ГОСТ Р ИСО/МЭК12207—2010. л. 4.41]

architectural design

• 66 проект архитектуры: Результат процесса определения набора anna* ратных и программных элементов и их интерфейсов в целях формирования концептуальной основы для разработки компьютерной системы.

• 67 проектирование: Процесс определения архитектуры, элементов, ин* design терфейсов и других свойств и характеристик системы или ее частей.

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

• 68 проектирование сверху вниз: Процесс проектирования системы по* top-down design средством идентификации ее основных компонентов и разбиения их на компоненты более низкого уровня, повторяющихся до тех пор. пока не будет достигнут необходимый уровень детализации.

• 69 проектирование снизу вверх: Процесс проектирования системы по* bottom-up design средством идентификации низкоуровневых компонентов и проектирования каждого компонента в отдельности с последующим созданием структуры, интегрирующей низкоуровневые компоненты во все более и более высокоуровневые подсистемы, вплоть до создания системы в целом.

• 70 _________________________________________________________________________________

проектная авария: Авария, которая приводит к возникновению аварийных design basis accident

условий, с учетом которых проектируется установка в соответствии с установленными проектными критериями и консервативной методологией и при кото* рых выбросы радиоактивного материала удерживаются в рамках допустимых пределов.

Д1]. Определения]__________________________________________________________________________

• 71 _________________________________________________________________________________________

проектное событие; ПС: Термин применяется для обозначения группы design basis event;

проектных аварий и ожидаемых при эксплуатации событий. DBE

[ГОСТ Р МЭК 61226-2011. пункт 3.4]

• 72 _________________________________________________________________________________

проектные основы (основа проекта, основы проекта), проектный (при* design basis

лагательное): Диапазон условий и событий, учитываемых непосредственно в проекте установки, согласно установленным критериям, таким образом, что* бы установка могла выдерживать их без превышения разрешенных (санкционированных) пределов при запланированной работе систем безопасности.

Примечание — Англоязычный термин «design basis» используется в качестве существительного в случае определения, приведенного выше. Кроме того, часто используется атрибутивно в связи с конкретными категориями условий или событий в значении «проектный», «включаемый в проектные основы»; например проектная авария (design basis accident), проектные внешние события (design basis external events) и проектное землетрясение (design basis earthquake).

[[2]. П]______________________________________________________________________________________________________________________

• 73 _________________________________________________________________________________

рабочая программа: Программное обеспечение, которое включено в еле- executable code

диализированную систему.

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

(ГОСТ Р МЭК 62138—2010, пункт 3.13]__________________________________________________

• 74 _________________________________________________________________________________

резервирование: Использование альтернативных (одинаковых или не* redundancy

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

((2). Р)______________________________________________________________________________________________________________________

• 75 _________________________________________________________________________________

ролевое управление доступом: Управление доступом на основе правил, role-based access

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

(ГОСТ Р МЭК 60880—2010, пункт 3.30]

• 76 руководство оператора: Документ, содержащий информацию, необ- operator manual, ходимую для того, чтобы привести систему или ее элемент в работоспособное operations manual состояние и управлять их работой.

Примечание — Обычно документ описывает процедуры подготовки системы к работе, обслуживания работающей системы, контроля и ремонта. Руководство оператора отличается от руководства пользователя, поскольку существенна разница между тем. кто управляет компьютерной системой (загружает информацию и т. д.). и тем. кто только использует информацию по назначению.

• 77 _________________________________________________________________________________

руководство по обслуживанию: Документ, содержащий информацию, support manual

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

Примечание — Обычно документ описывает оборудование и программное обеспечение, составлжощие систему или компонент, и процедуры их обслуживания, ремонта и перепрограммирования.

((4]. статья 3.4056]

• 78 ________________________________________________________________________________

руководство по установке: Документ, содержащий информацию, не- installation manual

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

Ц4]. статья 3.2006]

• 79 руководство пользователя: Документ, содержащий информацию, не- user manual обходимую для использования системы или элемента по назначению.

Примечание — Обычно документ описывает потенциагъные возможности системы или компонента, ограничения, опции, разрешенные исходные данные, ожидаемые конечные данные, возможные сообщения об ошибках и специальную инструкцию. Руководство пользователя отличается от руководства оператора, поскольку существенна разница между тем. кто управляет компьютерной системой (загружает информацию и т. д.). и тем. кто только использует информацию по назначению.

• 80 ________________________________________________________________________________

руководство программиста: Документ, содержащий информацию, необ- programmer manual

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

Примечание — Обычно документ описывает конфигурацию оборудования, рабочие характеристики, программные средства, функциональные особенности входа/ выхода, а также особенности компиляции или сборки компьютерной системы.

([4]. статья 3.3145]

• 81 ________________________________________________________________________________________

связанный контур: Часть системы более низкой категории безопасности, associated circuit не отделенная физически или не изолированная электрически от других частей системы (контуров) с более высокой категорией безопасности с помощью соответствующих разделительных интервалов, конструкций, барьеров или электроизолирующих устройств безопасного класса, но отвечающая, тем не менее, соответствующим критериям безопасности.

(ГОСТ Р МЭИ 60709-2011. пункт 3.1]

• 82 ________________________________________________________________________________

сеть: Совокупность узлов и соединяющих ветвей. network

[ГОСТ Р МЭИ 61131-3-2016. пункт 3.66]________________________________________________

• 83 ________________________________________________________________________________

сигнализация: Единица диагностической, прогностической или рекомен- alarms

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

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

Можно выделить два типа отклонений:

• - незапланированные — нежелательные отклонения технологического процесса и неисправности оборудования;

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

(ГОСТ Р МЭИ 60964-2012. пункт 3.18]

• 84 ________________________________________________________________________________

система: Совокупность компонентов, взаимодействующих в соответствии system

с проектом, в котором элемент системы может представлять собой другую систему. называемую подсистемой.

Примечания

• 1 См. также термин «СКУ».

• 2 СКУ отделяют от механических систем и электрических систем АС.

• 3 Это определение подкомитета ПК 45 А МЭК полностью соответствует определению «системы», данному в Глоссарии МАГАТЭ издания 2007 годэ в группе терминов «структуры систем и компонентов (SCC)».

[ГОСТ Р МЭК 61513—2020. пункт 3.56]__________________________________________________

• 85 _________________________________________________________________________________

система поддержки оператора; СПО: Система или системы, лредназна- operator support sys-

ченные для поддержки задач абстрактного мышления или задач интеллекту* tern. OSS альной обработки информации, выполняемых персоналом блочного пункта управления (БПУ).

[ГОСТ Р МЭК 60964—2012, пункт 3.21]__________________________________________________

• 86 _________________________________________________________________________________

система связи: Совокупность технических средств, программного обеспе- communication sys-

чения и среды передачи данных, позволяющая осуществить передачу сообще* tern ний от одного приложения к другому (прикладной уровень в соответствии с ГОСТ Р ИСО/МЭК 7498-1).

(ГОСТ Р МЭК 61500—2012. пункт 3.3]

87

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

Примечания

• 1 Корректирующее сопровождение без модификации обычно не устраняет причину отказа.

• 2 Систематический отказ может быть вызван имитацией причины отказа.

• 3 Примерами причт систематических отказов являются ошибки человека:

• ■ в спецификации требований к безопасности;

• в проекте, изготовлении, установке или работе аппаратных средств;

• ■ при проектировании, реализации и т.п. программного обеспечения.

[ГОСТ Р МЭК 61508-4—2012. статья 3.6.6]

88

случайный отказ аппаратных средств: Отказ, возникающий в случай- random hardware ный момент времени, который является результатом одного или нескольких failure возможных механизмов ухудшения характеристик в аппаратных средствах.

Примечания

• 1 Существует много механизмов ухудшения характеристик, действующих с различной интенсивностью и в различных компонентах. Посхогьку допуски изготовления приводят к тому, что компоненты в результате действия этих мехатзмов отказывают в разное время и отказы аппаратных средств включают в себя много факторов, то отказы происходят с предсказуемой частотой, но в непредсказуемые (т.е. случайные) моменты времени.

• 2 Основное различие между случайными отказами аппаратных средств и систематическими отказами состоит в том. что интенсивность отказов системы (или другие подобные характеристики таких отказов), связанная со случайными отказами аппаратных средств, может прогнозироваться с достаточной степенью точности, но систематические отказы по своей природе не могут быть предсказаны точно. Поэтому интенсивность отказов системы, связанных со случайными отказами аппаратных средств, может быть охарактеризована количественно с достаточной степетю точности, тогда как отказы системы, связанные с систематическими отказами, не могут быть статистически охарактеризованы с достаточной точностью, поскольку события, приводящие к таким отказам, не могут быть предсказаны.

[ГОСТ Р МЭК 61508-4-2012. статья 3.6.5]

• 89 _________________________________________________________________________________

срок службы: Период от начальной эксплуатации до окончательного вы- service life

вода из эксплуатации конструкции, системы или элемента.

Д2]. С]_______________________________________________________________________________________________________

• 90 _________________________________________________________________________________

срок эксплуатации (эксплуатационный ресурс): Период, в течение ко- operating life/lifetime

торого разрешенная (имеющая официальное разрешение) установка используется в целях, для которых она предназначена, до ее снятия с эксплуатации или закрытия.

П2]. С]_______________________________________________________________________________________________________

• 91 ________________________________________________________________________________________

стратегия проектирования: Общий план и руководство по выполнению design strategy

проекта.

Ц4), статья 3.1150]

• 92 тест: Действие по приведению системы или элемента в рабочее со- test стояние при определенных условиях, наблюдению и регистрации результатов функционирования с последующей оценкой тех или иных свойств системы или элемента.

• 93 тестирование: Процесс оценки свойств системы или элемента на ос- testing новании наблюдения и регистрации результатов функционирования системы

или элемента при определенных условиях.

• 94 тестируемость: Степень, в которой система может быть протестироеа- testability на как помодульно, так и в целом (степень, в которой система или элемент позволяют определить критерии тестирования и провести тестирование с целью проверки выполнения данных критериев).

• 95 тестовая документация: Документация, содержащая описание пла- test documentation нов тестирования или результатов тестирования системы или компонента.

• 96 _________________________________________________________________________________

тестовое покрытие: Степень, с которой данный тест проверяет требова- test coverage

ния для системы или программного продукта.

(ГОСТ Р ИСО/МЭК12207-2010. пункт 4.51]______________________________________________

• 97 _________________________________________________________________________________

тестовый сценарий: Совокупность исходных данных, условий выполне- test case

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

Ц6]. пункт 3.1]________________________________________________________________________________________________

• 98 _________________________________________________________________________________

технические требования: Требования, относящиеся к технологии и окру- technical requirements

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

Ц4], статья 3.4187]

• 99 _________________________________________________________________________________

технический анализ: Систематическая оценка продукции командой ква- technical review

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

[[7]. пункт 3.7]

• 100 ________________________________________________________________________________________

типовое испытание: Испытание на соответствие, проводимое на одном type test

или более образцах, представляющих продукцию.

(ГОСТ Р МЭК 61226—2011. пункт 3.21]

• 101 ________________________________________________________________________________________

точность измерения: Степень соответствия между результатом измере- accuracy of measure-

ния и условно истинным значением измеряемой величины. ment

(ГОСТ Р МЭК 62385—2012. пункт 3.1]

• 102 требование к интерфейсу: Требование, определяющее внешний interface requirement элемент, с которым может взаимодействовать система или ее компонент, или

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

• 103 ________________________________________________________________________________

требование к реализации: Требование, которое специфицирует или implementation

накладывает ограничение на кодирование или на конструкцию системы или requirement элемента системы.

((4]. статья 3.1893]

• 104 требование к функционированию: Измеримый критерий, который performance require* определяет атрибут качества функционирования или степень соответствия за- ment

данному функциональному требованию.

• 105 ________________________________________________________________________________

требование потребителя: Результат выявления, обобщения и урегули- customer requirement

рования противоречий между потребностями, ожиданиями и ограничениями заинтересованных в продукции сторон способами, приемлемыми для потре-бителя/заказчика.

((4). статья 3.971]

• 106 ________________________________________________________________________________________

требование проекта: Требование, которое определяет или накладывает design requirement

ограничения на внешний вид. структурные и функциональные особенности системы или элемента системы.

((4]. статья 3.1146]

• 107 ________________________________________________________________________________________

угроза: Событие, обладающее потенциалом причинить вред здоровью hazard

персонала станции или привести к повреждению компонентов, оборудования или структур. Угрозы подразделяют на внутренние и внешние.

Примечания

• 1 Внутренние угрозы представляют собой, например, пожар и затопление, внутренние опасности могут являться последствиями ПИС (например, авария с потерей теплоносителя. разрыв паропровода).

• 2 Примером внешних опасностей может служить землетрясение или удар молнии.

(ГОСТ Р МЭК 61513—2020, пункт 3.25]

• 108 ________________________________________________________________________________

уплотнение кода (программы): Целесообразное уменьшение размеров code compaction

памяти, необходимой для программы, путем исключения избыточных или посторонних команд.

(ГОСТ Р МЭК 60880—2010, пункт 3.7]___________________________________________________

• 109 ________________________________________________________________________________________

управление качеством: Скоординированная деятельность по управле- quality management

нию и контролю организации в интересах обеспечения качества.

((4]. статья 3.3274]

• 110 управление конфигурацией: Дисциплина, использующая техническое configuration man-и административное управление и надзор в целях идентификации и документи- agement роеания функциональных и физических характеристик элементов конфигурации.

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

• 111 _________________________________________________________________________________________________

уровень организации: Уровень управления или уровни, ответственные за organization level

управление одним или более устройствами обработки данных или информационными системами.

(]4). статья 3.2739]_________________________________________________________________________________

• 112 ________________________________________________________________________________________

уровень проектирования: Глубина декомпозиции элемента программ- design level

ного обеспечения, установленная в проекте (например, система, подсистема, программа или модуль).

Ц4], статья 3.1138]

• 113 ________________________________________________________________________________________

фаза детального проектирования: Фаза жизненного цикла программно- detailed design phase

го продукта, во время которой на основе проекта программной системы и программной архитектуры, выполненного на предыдущей фазе проектирования.

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

П4], статья 3.1165]

• 114 ________________________________________________________________________________________

фаза проектирования: Период в жизненном цикле системы или про- design phase

граммного продукта, во время которого создаются, документируются и верифицируются на соответствие требованиям проекты архитектуры, компоненты системы и/или ПО. интерфейсы и данные.

Ц4]. статья 3.1143]

• 115 ________________________________________________________________________________________

фаза проектирования архитектуры: Фаза жизненного цикла системы, в architectural design

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

Ц4], статья 3.212]

• 116 фаза тестирования: Промежуток времени в жизненном цикле про- test phase граммного продукта, во время которого компоненты программного продукта оцениваются и комплексируются, а затем оценивается программный продукт в

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

• 117 функциональная архитектура: Функциональная структура, пред- functionalarchitecture ставляющая собой упорядоченное изображение функций и их составляющих.

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

• 118 ________________________________________________________________________________________

функционально-ориентированное проектирование: Разделение проекта function-oriented de-на подсистемы и модули, каждый из которых выполняет одну или более функций, sign

Ц4). статья 3.1684]

• 119 функциональное проектирование: Процесс определения функций* functional design нальных взаимосвязей между элементами системы.

• 120 функция: Определенное целевое или типичное действие системы function или элемента системы.

• 121 ________________________________________________________________________________________

функция СКУ: Функция контроля, управления и/или наблюдения за опре* l&C function

деленной частью процесса.

Примечания

• 1 Термин «функция СКУ» используется инженерами-технологами, чзобы структурировать функциональные требования к СКУ. Функция СКУ определена следующим образом:

• ■ дает полное представление о функциональных целях;

• ■ может быть категоризирована в соответствии с ее степенью важности для безопасности;

• для достижения функциональной цели учитывает малейшие сущности; от датчика до исполнительного устройства.

• 2 Функция СКУ может быть подразделена на несколько подфункций (например, на функцию измерения, функцию управления, функцию приведения в действие) в целях распределения по СКУ.

(ГОСТ Р МЭК 61513—2020, пункт 3.28]

• 122 ________________________________________________________________________________________

целостность: Степень, в которой система или элемент препятствуют integrity

несанкционированному доступу к компьютерным программам или данным, или их несанкционированному изменению.

([4]. статья 3.2035]_________________________________________________________________________________

• 123 ________________________________________________________________________________

эксплуатационные пределы и условия: Совокупность правил, operational limits and

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

([2].Э]

• 124 эталонный тест: Процедура, задача или тест, которые могут быть benchmark использованы для сравнения систем или их элементов между собой или со стандартом.

Алфавитный указатель терминов на русском языке авария проектная

анализ технический

архитектура СКУ

архитектура функциональная

АС

барьер

безопасность информационная

библиотека

блох программный

веха

генерация кода автоматизированная

декомпозиция модульная

документация тестовая

ЖЦ

задача обеспечения безопасности

защищенность

измерение

инициализировать

инкапсуляция

интеграция

испытание на месте работ

испытание натурное

испытание приемочное

испытание типовое

канал

канал связи

категория функции СКУ

кибербезопасность

класс СКУ

комплекс оборудования

комплексирование

компонент

компонент программного обеспечения

конвейер

контроллер программируемый (логический)

контур связанный

конфигурация

конфигурация базовая

конфигурация исходная

критерий единичного отказа

метод анализа шумов

модель концептуальная

модификация ПО

неодинаковость

обеспечение качества

оборудование передачи данных

объект конфигурации

ОК

оператор

описание архитектуры

основа проекта

основы проекта

основы проектные

отказ

отказ аппаратного средства выявленный

отказ аппаратного средства невыявленный

отказ аппаратных средств случайный

отказ единичный

отказ зависимый

отказ по общей причине

отказ программного обеспечения

отказ систематический

охват диагностикой

передача данных

периодичность испытаний

план проекта

ПЛК

покрытие тестовое

пределы и условия эксплуатационные

программа компьютерная

программа рабочая

проект архитектуры

проектирование

проектирование сверху вниз

проектирование снизу вверх

проектирование функционально-ориентированное

проектирование функциональное

проектный

резервирование

ресурс эксплуатационный

руководство оператора

руководство по обслуживанию

руководство по установке

руководство пользователя

руководство программиста

сеть

сигнализация

система

система автоматизированная

система компьютеризированная

система обеспечивающая

система поддержки оператора

система связи

событие проектное

СПО

средства вспомогательные системы безопасности

срок службы

срок эксплуатации

стратегия проектирования

сценарий тестовый

тест

тест эталонный

тестирование

тестируемость

технические характеристики предельные

точка контрольная

точность измерения

трасса кабельная

требование к интерфейсу

требование к реализации

требование к функционированию

требование потребителя

требование проекта

требования технические

угроза

уплотнение кода (программы)

управление доступом ролевое

управление качеством

управление конфигурацией

уровень организации

уровень проектирования

условия аварийные

устройство изолирующее

устройство исполнительное

устройство программируемое

фаза детального проектирования

фаза проектирования

фаза проектирования архитектуры

фаза тестирования

функция

функция СКУ

целостность

цикл жизненный

цикл жизненный безопасности ПО

цикл жизненный безопасности системы

цикл жизненный общий безопасности С КУ

часть программная составная

Алфавитный указатель эквивалентов терминов на английском языке

performance limits

performance requirement

ppeline

PLC

programmable (logic) controller

programmer manual

project plan

□A

quality assurance

quality management

random hardware failure

redundancy

revealed hardware failure

role-based access control

safety system support features

safety task

security

service life

SFC

single failure

single failure criterion

software component

software failure

software item

software modification

software safety life cycle

software unit

support manual

system

system safety life cycle

systematic fadure

technical requirements

technical review

test

test case

test coverage

test documentation

test interval

test phase

testability

testing

top-down design

type test

unrevealed hardware failure

user manual

Библиография

• [1] IAEA SSR-2/1 (Rev.1) Безопасность атомных электростанций: проектирование. Конкретные требования безопасности. N» SSR-2/1 (Rev. 1) (Safety of Nuclear Power Plants: Design. 2016)

• [2] Глоссарий МАГАТЭ no вопросам безопасности. Терминология, используемая в области ядерной безопасности и радиационной защиты. Издание 2007 г.

• [3] МЭК 60987:2013 Электростанции атомные. Контрольно-измерительные приборы и системы управления, важные для обеспечения безопасности. Требования к проектированию аппаратуры для компьютерных систем (Nuclear power plants — Instrumentation and control important to safety — Hardware design requirements for computer-based systems)

• [4] ISO/IEC/IEEE 24765:2017 Системная и программная инженерия. Словарь (Systems and software engineering — Vocabulary)

• [5] МЭК 62566:2012 Атомные электростанции. Системы контроля и управления, важные для безопасности. Разработка HDL-программируемых интегральных схем для систем, выполняющих функции категории A (Nuclear power plants — Instrumentation and control important to safety — Development of HDL-programmed integrated circuits for systems performing category A functions)

• [6] IEEE 1012—2016 — IEEE Стандартный метод верификации и валидации системы, программного и аппаратного обеспечения (Standard for System, Software and Hardware Verification and Validation)

• [7] IEEE 1028—2008 — IEEE Стандартная процедура контроля и аудита программного обеспечения (Standard for Software Reviews and Audits)

УДК 621.311.3.049.75:006.354

ОКС 27.120.20

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

Редактор В.Н. Шмельков Технический редактор В.Н. Прусакова Корректор ЕД. Дульнева Компьютерная верстка Е.О. Асташина

Сдано о набор <2.03.2021 Подписано о печать 16.03.2021. Формат e0"84’/8. Гарнитура Ариал. Усп печ. л. 3.32. Уч.-и«. л 3.00.

Подготовлено на основе электронной версии, предоставленной разработчиком стандарта

Создано е единичной исполнении во дли комплектования Федерального информационного фонда стандартов. 117418 Москва. Нахимовский пр-т. д. 31. к. 2.

www.gaslmfo.ru mfo@gosbnfo.ru

ж W

ж

,«Z