Товары в корзине: 0 шт Оформить заказ
Стр. 1 

31 страница

Купить ГОСТ Р 59390-2021 — бумажный документ с голограммой и синими печатями. подробнее

Цена на этот документ пока неизвестна. Нажмите кнопку "Купить" и сделайте заказ, и мы пришлем вам цену.

Распространяем нормативную документацию с 1999 года. Пробиваем чеки, платим налоги, принимаем к оплате все законные формы платежей без дополнительных процентов. Наши клиенты защищены Законом. ООО "ЦНТИ Нормоконтроль"

Наши цены ниже, чем в других местах, потому что мы работаем напрямую с поставщиками документов.

Способы доставки

  • Срочная курьерская доставка (1-3 дня)
  • Курьерская доставка (7 дней)
  • Самовывоз из московского офиса
  • Почта РФ

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

 Скачать PDF

 
Дата введения01.12.2021
Актуализация01.01.2022

Этот ГОСТ находится в:

Automated control systems of technological processes for nuclear power plants. Terms and definitions

Стр. 1
стр. 1
Стр. 2
стр. 2
Стр. 3
стр. 3
Стр. 4
стр. 4
Стр. 5
стр. 5
Стр. 6
стр. 6
Стр. 7
стр. 7
Стр. 8
стр. 8
Стр. 9
стр. 9
Стр. 10
стр. 10
Стр. 11
стр. 11
Стр. 12
стр. 12
Стр. 13
стр. 13
Стр. 14
стр. 14
Стр. 15
стр. 15
Стр. 16
стр. 16
Стр. 17
стр. 17
Стр. 18
стр. 18
Стр. 19
стр. 19
Стр. 20
стр. 20
Стр. 21
стр. 21
Стр. 22
стр. 22
Стр. 23
стр. 23
Стр. 24
стр. 24
Стр. 25
стр. 25
Стр. 26
стр. 26
Стр. 27
стр. 27
Стр. 28
стр. 28
Стр. 29
стр. 29
Стр. 30
стр. 30

ГОСТР

59390—

2021

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

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

СТАНДАРТ

РОССИЙСКОЙ

ФЕДЕРАЦИИ

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

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

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


Москва

Стандартинформ

2021


Предисловие

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

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

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

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

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

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

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

II

49

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

Примечания

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

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

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

overall safety life cycle of the l&C

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

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

51

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

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

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

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

52

operator

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

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

architectural description

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

54

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

Ц2]. О]

55

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

Примечания

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

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

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

software failure

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

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

ОС- .

^ *чога 1

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

*•00 — интенсивности выявленных опасных отказов; л,0(а, — общая интенсивность опасных отказов.

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

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

diagnostic coverage

57

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

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

data communication

58

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

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

test interval

59

план проекта: Документ, содержащий описание технических и управленческих подходов, которые следует реализовать в проекте.

[[4]. статья 3.3182]

project plan

60

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

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

[ГОСТ Р МЭК 62342-2016. пункт 3.13]

performance limits

61

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

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

acceptance test

62

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

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

HDL-programmed device; HPD

63

программируемый (логический) контроллер; ПЛК: Цифровая электронная система, предназначенная для применения в производственной среде, которая использует программируемую память для внутреннего хранения ориентированных на потребителя инструкций по реализации таких специальных функций, как логика, установление последовательности, согласование по времени. счет и арифметические действия для контроля посредством цифрового или аналогового ввода/вывода данных различных видов машин или процессов. Как ПЛК, так и связанные с ними периферийные устройства разрабатываются таким образом, чтобы они могли легко интегрироваться в любую промышленную систему управления с применением всех встроенных в них функций. [ГОСТ Р МЭК 61131-1-2016. пункт 3.5]

64

programmable (logic) controller: PLC

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

software item


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


[ГОСТ Р ИСО/МЭК 12207-2010, п. 4.41]

65

программный блок: Отдельная компилируемая часть кода. [ГОСТ Р ИСО/МЭК 12207-2010. пункт 4.43]

software unit

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

architectural design

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

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

design

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

top-down design

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

70

bottom-up design

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

Ц1]. Определения)

71

design basis accident

прооктное событие; ПС: Термин применяется для обозначения группы проектных аварий и ожидаемых при эксплуатации событий.

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

design basis event; DBE

10


72 _

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

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

m n]_

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

84

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

Примечания

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

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

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

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

85 _

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

ченные для поддержки задач абстрактного мышления или задач интеллекту- tem. 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.61

88

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

Примечания

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

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

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

89

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

Ц2]. С]

service life

90

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

Q2). С]

operating life/lifetime

91

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

(14], статья 3.1150]

design strategy

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

test

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

testing

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

testability

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

96

test documentation

тестовое покрытие: Степень, с которой данный тест проверяет требования для системы или программного продукта.

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

test coverage

97

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

Ц6], пункт 3.1]

test case

98

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

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

technical requirements

99

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

Q7], пункт 3.7]

technical review

100

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

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

101

type test

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

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

accuracy of measurement

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

103

interface requirement

требование к реализации: Требование, которое специфицирует или накладывает ограничение на кодирование или на конструкцию системы или элемента системы.

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

implementation

requirement

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

105

performance requirement

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

[[4]. статья 3.971]

106

customer requirement

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

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

107

design requirement

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

Примечания

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

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

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

108

hazard

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

[ГОСТ Р МЭК 60880-2010. пункт 3.7]

109

code compaction

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

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

quality management

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

111

configuration management

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

П4), статья 3.2739]

112

organization level

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

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

113

design level

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

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

114

detailed design phase

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

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

115

design phase

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

(14], статья 3.212]

architectural design phase

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

test phase

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

functional architecture

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

118

функционально-ориентированное проектирование: Разделение проекта на подсистемы и модули, каждый из которых выполняет одну или более функций. [14], статья 3.1684]

function-oriented design

Содержание

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

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

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

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

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 использованы для сравнения систем или их элементов между собой или со стандартом.

Введение

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

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

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

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

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

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

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

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

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

АТОМНЫХ СТАНЦИЙ

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

Automated control systems of technological 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 gon-инструментов. позволяющая преобразовывать проблемно-ориентированный 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

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

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

configuration baseline

6

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

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

barrier

7

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

[ГОСТ Р МЭК 60880-2010. пункт 3.24]

library

8

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

Ц2]. В]

safety system support features

16

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

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

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

security

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

18

measurement

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

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

19

isolation device

инициализировать: Установить счетчики, переключатели, адреса или содержимое устройств памяти на нулевое значение или другие начальные значения в начале или в заданной точке выполнения компьютерной программы. (ГОСТ Р МЭК 60880-2010. пункт 3.22]

initialize

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

21

encapsulation

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

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

22

integration

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

02]. И]

23

actuation device

исходная конфигурация: Информация о конфигурации, формально привязанная к определенному моменту времени в жизни продукции или ее элемента.

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

04]. статья 3.772]

24

configuration baseline

кабельная трасса: Физическая магистраль, проходящая через станцию, вдоль которой можно проложить большое количество кабелей, например помещение или кабельный туннель в здании станции либо металлический канал, кабельная коробка или труба, а также канал под дорогой или платформа над ней. [ГОСТ Р МЭК 60709-2011, пункт 3.3]

25

cable route

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

channel

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

Ц2).К]

31


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

Примечания

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

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

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

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

32

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

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

33

software component

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

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

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

computer-based system

34

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

[ГОСТ Р МЭК 60880-2010. пункт 3.10]

35

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

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

pipeline

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

milestone

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

38

configuration

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

[[4], статья 3.751]

39

conceptual model

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

Ц2]. К]

40

single failure criterion; SFC

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

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

noise analysis technique