ГОСТ Р 59390-2021
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ ТЕХНОЛОГИЧЕСКИМИ ПРОЦЕССАМИ АТОМНЫХ СТАНЦИЙ
Термины и определения
Automated control systems of technological processes for nuclear power plants. Terms and definitions
ОКС 27.120.20
Дата введения 2021-12-01
Предисловие
1 РАЗРАБОТАН Акционерным обществом "Русатом Автоматизированные системы управления" (АО "РАСУ")
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 322 "Атомная техника"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ
Приказом Федерального агентства по техническому регулированию и метрологии от 11 марта 2021 г. N 134-ст
4 ВВЕДЕН ВПЕРВЫЕ
Правила применения настоящего стандарта установлены в
статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации ". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет ()
Введение
Настоящий стандарт распространяется на автоматизированные системы управления технологическими процессами атомных станций. Установленные в настоящем стандарте термины расположены в систематизированном порядке.
Для некоторых понятий установлены термины-синонимы, набранные полужирным шрифтом и следующие после основного термина через точку с запятой.
Приведенные определения можно, при необходимости, изменять, вводя в них производные признаки, раскрывая значения используемых в них терминов, указывая объекты, входящие в объем определяемого понятия. Изменения не должны нарушать объем и содержание понятий, определенных в настоящем стандарте.
Для отдельных стандартизованных терминов приведены в качестве справочных краткие формы (аббревиатуры), которые разрешается применять в случаях, исключающих возможность их различного толкования.
В стандарте приведены англоязычные (en) эквиваленты для стандартизованных терминов.
Стандартизованные термины набраны полужирным шрифтом, их краткие формы, представленные аббревиатурой, - светлым.
В стандарте приведены алфавитные указатели терминов на русском языке и их эквивалентов на английском.
1 Область применения
1.1 Настоящий стандарт устанавливает терминологию, относящуюся к таким понятиям, как система, процесс, модель, жизненный цикл и его типовые процессы, а также к проектной и конструкторской деятельности, архитектуре и функционированию систем контроля и управления (СКУ), участию человека при проектировании автоматизированных систем управления технологическими процессами.
1.2 Термины, установленные настоящим стандартом, предназначены для применения во всех видах документации и литературы (по данной научно-технической отрасли), входящих в сферу работ по стандартизации и (или) использующих результаты этих работ.
1.3 Стандарт носит обязательный характер для применения при составлении нормативных документов, стандартов организаций и технической документации в области создания автоматизированных систем, а также в деловой переписке между организациями при проектировании и эксплуатации автоматизированных систем управления технологическими процессами.
2 Термины и определения
1
|
|
|
аварийные условия: Отклонения от нормальной эксплуатации, которые являются менее частыми и более тяжелыми, чем ожидаемые при эксплуатации события.
Примечание - Аварийные условия - это проектные аварии и запроектные условия.
[[1]*, Определения] |
| accident conditions |
2
|
|
|
автоматизированная генерация кода: Функция автоматизированных инструментов, позволяющая преобразовывать проблемно-ориентированный язык в форму, пригодную для компиляции или выполнения.
[ ГОСТ Р МЭК 60880-2010 , пункт 3.5] |
| automated code generation |
3
|
|
|
автоматизированная система; АС: Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.
Примечания
1 В зависимости от вида деятельности выделяют, например, следующие виды АС: автоматизированные системы управления (АСУ), системы автоматизированного проектирования (САПР), автоматизированные системы научных исследований (АСНИ) и др.
2 В зависимости от вида управляемого объекта (процесса) АСУ делят, например, на АСУ технологическими процессами (АСУ ТП), АСУ предприятиями (АСУП) и т.д.
[ ГОСТ 34.003-90 , статья 1.1] |
| automated system; AS |
4
|
|
|
архитектура СКУ: Организационная структура СКУ станции, которые являются важными для безопасности.
Примечания
1 См. также термины: "архитектура СКУ", "СКУ".
2 Организационная структура определяет, главным образом, основные функции, класс и границы каждой системы, взаимосвязь и независимость систем, приоритетность и голосование между одновременно действующими сигналами, ЧМИ.
3 В этом стандарте термин определяет только часть общей архитектуры СКУ станции. Позднее включаются также неклассифицируемые системы и оборудование.
4 Для простоты использования термин "общая архитектура СКУ" используется как краткая форма термина "общая архитектура СКУ, важных для безопасности".
[ ГОСТ Р МЭК 61513-2020 , пункт 3.27] |
| l&C architecture |
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 |
9
|
|
|
выявленный отказ аппаратного средства: Отказ аппаратного средства, который был автоматически обнаружен и подтвержден, например отказ платы, автоматически обнаруженный контрольными средствами с последующей выдачей сигнала тревоги.
[[3], пункт 3.10] |
| revealed hardware failure |
10
|
|
|
единичный отказ: Отказ, который приводит к потере способности системы или элемента выполнять предписанные им функции безопасности, а также любые последующие отказы, являющиеся результатом этого.
[[2], Е] |
| single failure |
11
|
|
|
жизненный цикл; ЖЦ: Развитие системы, продукта, услуги, проекта или других изготовленных человеком объектов, начиная со стадии разработки концепции и заканчивая прекращением применения.
[ ГОСТ Р ИСО/МЭК 12207-2010 , пункт 4.16] |
| life cycle |
12
|
|
|
жизненный цикл безопасности ПО: Необходимая деятельность при разработке и использовании программного обеспечения системы контроля и управления (СКУ), важной для безопасности, осуществляемая в течение всего периода времени, начиная с разработки спецификации требований к программному обеспечению и заканчивая выведением программного обеспечения из эксплуатации.
[ ГОСТ Р МЭК 60880-2010 , пункт 3.37] |
| software safety life cycle |
13
|
|
|
жизненный цикл безопасности системы: Необходимая деятельность, относящаяся к реализации СКУ, важных для безопасности, и выполняемая в течение периода времени, который начинается со спецификации системных требований на стадии концепта и заканчивается, когда СКУ не доступна к использованию.
Примечания
1 Жизненный цикл безопасности системы ссылается к деятельности в рамках жизненного цикла СКУ.
2 См. также термин "общий жизненный цикл безопасности системы контроля и управления (жизненный цикл СКУ)".
[ ГОСТ Р МЭК 61513-2020 , пункт 3.57] |
| system safety life cycle |
14
|
|
|
зависимый отказ: Отказ, вероятность которого не может быть выражена в виде простого произведения безусловных вероятностей отдельных событий, являющихся причиной отказа.
Примечание - Пусть P(z) - вероятность события z. Два события A и B будут зависимы только в том случае, если P(A и B) > P(A)·P(B).
[ ГОСТ Р МЭК 61508-4-2012 , статья 3.6.9] |
| dependent failure |
15
|
|
|
задача обеспечения безопасности: Контроль одного или нескольких параметров, указывающих на возникновение конкретного постулируемого исходного события, обработка сигналов, инициирование и выполнение действий по обеспечению безопасности, требующихся для предотвращения превышения пределов, установленных в проектных основах, а также инициирование и выполнение определенных обслуживающих действий, осуществляемых вспомогательными средствами системы безопасности.
[[2], 3] |
| safety task |
16
|
|
|
защищенность, информационная безопасность (кибербезопасность): Способность компьютеризированной системы защитить информацию и данные так, чтобы не допустить их прочтения или изменения неавторизованными системами и отдельными лицами, и для того, чтобы авторизованные системы и лица не получали отказов.
[ ГОСТ Р МЭК 61513-2020 , пункт 3.48] |
| security |
|
|
|
17 измерение: Присвоение объекту количественной характеристики в рамках формализованной процедуры в целях представления свойств объекта.
18 |
| measurement |
|
|
|
изолирующее устройство: Устройство в контуре, не допускающее того, чтобы неполадки в работе одной части контура были причиной недопустимых сбоев в других частях контура или в других контурах.
[ ГОСТ Р МЭК 60709-2011 , пункт 3.5] |
| isolation device |
19
|
|
|
инициализировать: Установить счетчики, переключатели, адреса или содержимое устройств памяти на нулевое значение или другие начальные значения в начале или в заданной точке выполнения компьютерной программы.
[ ГОСТ Р МЭК 60880-2010 , пункт 3.22] |
| initialize |
|
|
|
20 инкапсуляция: Метод разработки программного обеспечения, который состоит в изолировании функции системы или набора данных, оперировании этими данными внутри модуля и предоставлении точных технических условий для модуля.
21 |
| encapsulation |
|
|
|
интеграция: Последовательная сборка компонентов и их проверка внутри завершенной системы.
[ ГОСТ Р МЭК 62138-2010 , пункт 3.18] |
| integration |
22
|
|
|
исполнительное устройство: Элемент, который непосредственно управляет движущей силой исполнительного оборудования.
[[2], И] |
| actuation device |
23
|
|
|
исходная конфигурация: Информация о конфигурации, формально привязанная к определенному моменту времени в жизни продукции или ее элемента.
Примечание - Исходная конфигурация, дополненная принятыми изменениями, составляет информацию о текущей конфигурации.
[[4], статья 3.772] |
| configuration baseline |
24
|
|
|
кабельная трасса: Физическая магистраль, проходящая через станцию, вдоль которой можно проложить большое количество кабелей, например помещение или кабельный туннель в здании станции либо металлический канал, кабельная коробка или труба, а также канал под дорогой или платформа над ней.
[ ГОСТ Р МЭК 60709-2011 , пункт 3.3] |
| cable route |
25
|
|
|
канал: Совокупность взаимосвязанных элементов в системе, которая выдает один выходной сигнал. Канал теряет свою идентичность, когда сигналы одного выхода объединяются с сигналами, поступающими от других каналов (например, от контрольно-измерительного канала или канала обслуживания устройств безопасности).
[[2], К] |
| channel |
26
|
|
|
канал связи: Особая линия логической или физической связи между субъектами.
Примечание - Канал облегчает установление соединения.
[ ГОСТ Р МЭК 62443-3-3-2016 , пункт 3.1.9] |
| communication channel |
27
|
|
|
категория функции СКУ: Одно из трех возможных обозначений (А, В, С) функций СКУ, устанавливаемое в результате рассмотрения влияния выполняемой функции на безопасность.
Примечания
1 См. также термины: "класс СКУ", "функция СКУ".
2 ГОСТ Р МЭК 61226 определяет категории функций СКУ. Каждой категории соответствует набор требований, применяемый как к каждой функции (относительно их спецификаций, проекта, реализации, верификации и валидации), так и к целому набору элементов, которые необходимы для реализации функции (относительно свойств и требуемой квалификации) независимо от того, как эти элементы распределены в ряду взаимосвязанных СКУ. Для большей ясности этот стандарт определяет категории функций СКУ и классы СКУ и устанавливает связь между категорией функции и минимальным требуемым классом соответствующих систем и оборудования.
[ ГОСТ Р МЭК 61513-2020 , пункт 3.4] |
| category of an l&C function |
28
|
|
|
класс СКУ: Одно из трех возможных обозначений (1, 2, 3) СКУ, важных для безопасности, присваиваемое в результате рассмотрения требований, предъявляемых к выполнению функций СКУ, имеющих разное значение для безопасности.
Примечание - См. также термины "категории функций СКУ", "элементы, важные для безопасности", "системы безопасности".
[ ГОСТ Р МЭК 61513-2020 , пункт 3.6] |
| class of an l&C system |
29
|
|
|
комплекс оборудования: Набор аппаратных и программных компонентов, которые могут работать совместно в одной или более определенных архитектурах или конфигурациях.
Примечания
1 См. также термины "функциональность", "прикладное программное обеспечение", "библиотека прикладных программ".
2 Комплекс оборудования может быть как продуктом от определенного производителя, так и набором продуктов, соединение и адаптация которых выполнены поставщиком.
3 Термин "платформа оборудования" иногда используется как синоним термина "комплекс оборудования".
[ ГОСТ Р МЭК 61513-2020 , пункт 3.17] |
| equipment family |
30
|
|
|
комплексирование: Процесс объединения компонентов программного обеспечения и аппаратных компонентов или того и другого в общую систему.
[[4], статья 3.117] |
| aggregation |
31
|
|
|
компонент: Одна из составных частей системы. Компонент может представлять собой аппаратное или программное обеспечение и может сам состоять из других компонентов.
Примечания
1 См. также термины "СКУ", "оборудование".
2 Термины "оборудование", "компонент" и "модуль" часто используют как взаимозаменяемые. Взаимоотношения между этими терминами пока не стандартизованы.
3 Это определение подкомитета ПК 45 А МЭК в принципе совместимо с определением термина "компонент", приведенным в группе терминов Глоссария МАГАТЭ издания 2007 г. под названием "Structures Systems and Components (SCC)" (Структуры систем и компонентов). Тем не менее, поскольку там приведены примеры только компонентов аппаратного обеспечения, что может ввести в заблуждение читателя, подкомитет ПК 45 А МЭК предпочитает использовать определение, которое явно касается и компонентов программного обеспечения.
[ ГОСТ Р МЭК 61513-2020 , пункт 3.10] |
| component |
32
|
|
|
компонент программного обеспечения: Один из элементов проекта, составляющих часть программного обеспечения. Он может быть разделен на другие компоненты программного обеспечения.
[ ГОСТ Р МЭК 62138-2010 , пункт 3.29] |
| software component |
33
|
|
|
компьютеризированная система: Система контроля и управления, функции которой в большей своей части зависят от использования микропроцессоров, программируемого электронного оборудования или компьютеров либо полностью определяются таким использованием.
Примечание - Эквивалентны следующему определению: цифровые системы, системы с программным обеспечением, программируемые системы.
[ ГОСТ Р МЭК 60880-2010 , пункт 3.11] |
| computer-based system |
34
|
|
|
компьютерная программа: Набор упорядоченных команд и данных, которые описывают операции в форме, приемлемой для их выполнения компьютером.
[ ГОСТ Р МЭК 60880-2010 , пункт 3.10] |
| computer program |
35
|
|
|
конвейер: Техника разработки программного обеспечения или аппаратных средств, основанная на использовании выхода первого процесса в качестве входа второго процесса, в свою очередь, выхода второго - в качестве входа третьего и т.д.
[[4], статья 3.2907] |
| pipeline |
|
|
|
36 контрольная точка; веха: Запланированное событие, которое используется для оценки развития.
|
| milestone |
37 конфигурация: Характеристика устройства компьютерной системы или элемента, определяемая количеством и природой составляющих систему (элемент) частей и взаимосвязями между этими частями.
38 |
| configuration |
|
|
|
концептуальная модель: Модель понятий, характерных для некоторой сферы деятельности.
[[4], статья 3.751] |
| conceptual model |
39
|
|
|
критерий единичного отказа: Критерий (или требование), применяемый к системе таким образом, чтобы она обязательно сохраняла способность выполнять свою функцию в случае любого единичного отказа.
[[2], К] |
| single failure criterion; SFC |
40
|
|
|
метод анализа шумов: Метод натурного испытания времени срабатывания датчиков, детекторов и преобразователей и оперативного обнаружения закупориваний, пустот и протечек в трубопроводах измерения давления.
[ ГОСТ Р МЭК 62385-2012 , пункт 3.10] |
| noise analysis technique |
41
|
|
|
модификация ПО: Изменение в уже согласованном документе (или документах), ведущее к изменению рабочей программы.
Примечание - Модификации ПО могут происходить в процессе первоначальной разработки ПО (например, устранение ошибок, обнаруженных на поздних этапах разработки) или когда ПО уже находится в эксплуатации.
[ ГОСТ Р МЭК 60880-2010 , пункт 3.36] |
| software modification |
42
|
|
|
модульная декомпозиция: Процесс разбиения системы на компоненты для упрощения проектирования, разработки и оценки.
[ ГОСТ Р ИСО/МЭК 15408-1-2012 , пункт 3.2.20] |
| modular decomposition |
43
|
|
|
натурное испытание, испытание на месте работ: Испытание датчика или преобразователя сигнала, проводимое без удаления датчика или преобразователя сигнала из положения его нормальной установки в системе.
[ ГОСТ Р МЭК 62385-2012 , пункт 3.9] |
| in-situ test |
44
|
|
|
невыявленный отказ аппаратного средства: Отказ аппаратного средства, который не был автоматически обнаружен системой и который становится очевидным только при попытке использовать функцию, за которую отвечает поврежденное аппаратное средство (такие отказы могут быть выявлены при функциональном тестировании или эксплуатации системы).
[[3], пункт 3.17] |
| unrevealed hardware failure |
45
|
|
|
неодинаковость: Наличие двух или более резервных систем или элементов для выполнения одной определенной функции, при котором разные системы или элементы наделяются различными признаками таким образом, чтобы уменьшалась возможность отказа по общей причине, включая общий отказ.
[[2], Н] |
| diversity |
46
|
|
|
обеспечение качества (ОК): Функция системы управления, которая обеспечивает уверенность в том, что установленные требования будут выполнены.
[[2], О] |
| quality assurance; QA |
47
|
|
|
обеспечивающая система: Система, которая служит дополнением к рассматриваемой системе на протяжении стадий ее жизненного цикла, но не обязательно вносит непосредственный вклад в ее функционирование.
Примечания
1 Например, если рассматриваемая система вступает в стадию производства, то требуется обеспечивающая производственная система.
2 Каждая обеспечивающая система имеет собственный жизненный цикл. Настоящий стандарт может применяться для любой обеспечивающей системы, если она представлена как рассматриваемая система.
[ ГОСТ Р ИСО/МЭК 12207-2010 , пункт 4.11] |
| enabling system |
48
|
|
|
оборудование передачи данных: Вариант реализации части устройства в зависимости от среды передачи данных, модуляции и кодирования для устройства, соединенного с магистралью передачи данных, включая части более низкого физического уровня в устройстве.
[ ГОСТ Р МЭК 61500-2012 , пункт 3.5] |
| data communication equipment |
49
|
|
|
общий жизненный цикл безопасности СКУ: Необходимая деятельность, относящаяся к реализации систем и оборудования, важных для безопасности, общей архитектуры СКУ и выполняемая в течение периода времени, который начинается с формирования требований СКУ из проектных основ безопасности АС и заканчивается, когда ни одна из СКУ не доступна к использованию.
Примечания
1 Общий жизненный цикл системы контроля и управления (жизненный цикл СКУ) определяет требования к жизненным циклам безопасности отдельных систем.
2 См. также термин "жизненный цикл безопасности системы".
[ ГОСТ Р МЭК 61513-2020 , пункт 3.34] |
| overall safety life cycle of the l&C |
|
|
|
50 объект конфигурации: Агрегат, состоящий из аппаратных средств, программных средств или того и другого, который предназначен для управления конфигурацией и рассматривается в процессе управления конфигурацией в качестве единой сущности.
Примечание - Объекты конфигурации могут сильно отличаться по сложности, размеру и типу, начиная от всей системы, включая все оборудование, программное обеспечение и документацию, до одного модуля или малого компонента оборудования.
51 |
| configuration item |
|
|
|
оператор: Какой-либо объект, осуществляющий работу системы.
Примечания
1 Роль оператора и роль пользователя могут возлагаться одновременно или последовательно на одно и то же лицо или организацию.
2 В контексте данного конкретного определения термин "объект" означает лицо или организацию.
[ ГОСТ Р ИСО/МЭК 12207-2010 , пункт 4.22] |
| operator |
52
|
|
|
описание архитектуры: Совокупность документов, описывающих архитектуру.
[[4], статья 3.217] |
| architectural description |
|
|
|
53 отказ: Прекращение способности системы выполнять требуемую функцию или ее неспособность работать в установленных пределах, внешне проявляющиеся в видимых отклонениях от системных характеристик.
54 |
| failure |
|
|
|
отказ по общей причине: Отказ двух или более конструкций, систем и элементов вследствие единичного конкретного события или единичной конкретной причины.
[[2], О] |
| common cause failure |
55
|
|
|
отказ программного обеспечения: Отказ системы из-за проявившейся проектной ошибки в компоненте программного обеспечения.
Примечания
1 Все отказы программного обеспечения являются следствием дефектов проектирования, т.к. программное обеспечение состоит исключительно из проектирования и не изнашивается или подвергается физическим отказам. Т.к. запуск активации дефектов программного обеспечения происходят случайным образом в период эксплуатации системы, то отказы программного обеспечения также происходят случайно.
2 См. также термины "отказ", "дефект", "дефект программного обеспечения".
[ ГОСТ Р МЭК 61513-2020 , пункт 3.52] |
| software failure |
56
|
|
|
охват диагностикой: Часть опасных отказов, выявляемая автоматическими диагностическими тестами в неавтономном режиме (эту часть опасных отказов вычисляют как отношение интенсивности выявленных диагностическими тестами опасных отказов к общей интенсивности опасных отказов).
Примечания
1 Охват диагностикой опасных отказов определяют с помощью следующего выражения:
, где DC - охват диагностикой;
- интенсивности выявленных опасных отказов; - общая интенсивность опасных отказов. 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] |
| programmable (logic) controller; PLC |
64
|
|
|
программная составная часть: Исходный код, объектный код, контрольный код, контрольные данные или совокупность этих составных частей.
Примечание - Программная составная часть может рассматриваться как системный элемент.
[ ГОСТ Р ИСО/МЭК 12207-2010 , п.4.41] |
| software item |
65
|
|
|
программный блок: Отдельная компилируемая часть кода.
[ ГОСТ Р ИСО/МЭК 12207-2010 , пункт 4.43] |
| software unit |
|
|
|
66 проект архитектуры: Результат процесса определения набора аппаратных и программных элементов и их интерфейсов в целях формирования концептуальной основы для разработки компьютерной системы.
|
| architectural design |
67 проектирование: Процесс определения архитектуры, элементов, интерфейсов и других свойств и характеристик системы или ее частей.
Примечание - Проект обеспечивает реализацию уровня совместимости физической структуры, поведения, временных связей и других атрибутов элементов системы. Проект содержит информацию, включающую спецификацию элементов системы и их взаимосвязей, достаточно полную для соответствующей реализации архитектуры.
|
| design |
68 проектирование сверху вниз: Процесс проектирования системы посредством идентификации ее основных компонентов и разбиения их на компоненты более низкого уровня, повторяющихся до тех пор, пока не будет достигнут необходимый уровень детализации.
|
| top-down design |
69 проектирование снизу вверх: Процесс проектирования системы посредством идентификации низкоуровневых компонентов и проектирования каждого компонента в отдельности с последующим созданием структуры, интегрирующей низкоуровневые компоненты во все более и более высокоуровневые подсистемы, вплоть до создания системы в целом.
70 |
| bottom-up design |
|
|
|
проектная авария: Авария, которая приводит к возникновению аварийных условий, с учетом которых проектируется установка в соответствии с установленными проектными критериями и консервативной методологией и при которых выбросы радиоактивного материала удерживаются в рамках допустимых пределов.
[[1], Определения] |
| design basis accident |
71
|
|
|
проектное событие; ПС: Термин применяется для обозначения группы проектных аварий и ожидаемых при эксплуатации событий.
[ ГОСТ Р МЭК 61226-2011 , пункт 3.4] |
| design basis event; DBE |
72
|
|
|
проектные основы (основа проекта, основы проекта), проектный (прилагательное): Диапазон условий и событий, учитываемых непосредственно в проекте установки, согласно установленным критериям, таким образом, чтобы установка могла выдерживать их без превышения разрешенных (санкционированных) пределов при запланированной работе систем безопасности.
Примечание - Англоязычный термин "design basis" используется в качестве существительного в случае определения, приведенного выше. Кроме того, часто используется атрибутивно в связи с конкретными категориями условий или событий в значении "проектный", "включаемый в проектные основы"; например проектная авария (design basis accident), проектные внешние события (design basis external events) и проектное землетрясение (design basis earthquake).
[[2], П] |
| design basis |
73
|
|
|
рабочая программа: Программное обеспечение, которое включено в специализированную систему.
Примечание - Рабочая программа обычно включает в себя команды, которые должны выполняться техническим обеспечением специализированной системы, и сопутствующие данные.
[ ГОСТ Р МЭК 62138-2010 , пункт 3.13] |
| executable code |
74
|
|
|
резервирование: Использование альтернативных (одинаковых или неодинаковых) конструкций, систем и элементов таким образом, чтобы все они могли выполнять требующуюся функцию независимо от эксплуатационного состояния или отказа (выхода из строя) любого из них.
[[2], Р] |
| redundancy |
75
|
|
|
ролевое управление доступом: Управление доступом на основе правил, определяющих разрешение доступа пользователей к объекту (функции, данные) не на индивидуальном основании, а на основании принадлежности к группам с идентичными задачами.
[ ГОСТ Р МЭК 60880-2010 , пункт 3.30] |
| role-based access control |
|
|
|
76 руководство оператора: Документ, содержащий информацию, необходимую для того, чтобы привести систему или ее элемент в работоспособное состояние и управлять их работой.
Примечание - Обычно документ описывает процедуры подготовки системы к работе, обслуживания работающей системы, контроля и ремонта. Руководство оператора отличается от руководства пользователя, поскольку существенна разница между тем, кто управляет компьютерной системой (загружает информацию и т.д.), и тем, кто только использует информацию по назначению.
77 |
| operator manual, operations manual |
|
|
|
руководство по обслуживанию: Документ, содержащий информацию, необходимую для сервисного обслуживания и сопровождения функционирующей системы или элементов в течение их жизненного цикла.
Примечание - Обычно документ описывает оборудование и программное обеспечение, составляющие систему или компонент, и процедуры их обслуживания, ремонта и перепрограммирования.
[[4], статья 3.4056] |
| support manual |
78
|
|
|
руководство по установке: Документ, содержащий информацию, необходимую для первоначальной установки системы или ее элемента, набор начальных параметров и сведения по подготовке системы или элемента к использованию по назначению.
[[4], статья 3.2006] |
| installation manual |
|
|
|
79 руководство пользователя: Документ, содержащий информацию, необходимую для использования системы или элемента по назначению.
Примечание - Обычно документ описывает потенциальные возможности системы или компонента, ограничения, опции, разрешенные исходные данные, ожидаемые конечные данные, возможные сообщения об ошибках и специальную инструкцию. Руководство пользователя отличается от руководства оператора, поскольку существенна разница между тем, кто управляет компьютерной системой (загружает информацию и т.д.), и тем, кто только использует информацию по назначению.
80 |
| user manual |
|
|
|
руководство программиста: Документ, содержащий информацию, необходимую для разработки или модификации программного обеспечения заданной компьютерной системы.
Примечание - Обычно документ описывает конфигурацию оборудования, рабочие характеристики, программные средства, функциональные особенности входа/выхода, а также особенности компиляции или сборки компьютерной системы.
[[4], статья 3.3145] |
| programmer manual |
81
|
|
|
связанный контур: Часть системы более низкой категории безопасности, не отделенная физически или не изолированная электрически от других частей системы (контуров) с более высокой категорией безопасности с помощью соответствующих разделительных интервалов, конструкций, барьеров или электроизолирующих устройств безопасного класса, но отвечающая, тем не менее, соответствующим критериям безопасности.
[ ГОСТ Р МЭК 60709-2011 , пункт 3.1] |
| associated circuit |
82
|
|
|
сеть: Совокупность узлов и соединяющих ветвей.
[ ГОСТ Р МЭК 61131-3-2016 , пункт 3.66] |
| network |
83
|
|
|
сигнализация: Единица диагностической, прогностической или рекомендательной информации, используемая для предупреждения оператора и привлечения его внимания к отклонению технологического процесса или системы.
Примечание - Характерной информацией, отображаемой с помощью сигнализации, является наличие аномалии, для которой могут потребоваться корректирующие действия, а также причина и возможные последствия этой аномалии, общее состояние атомной станции, корректирующие действия для устранения аномалии или результат корректирующих действий.
Можно выделить два типа отклонений:
- незапланированные - нежелательные отклонения технологического процесса и неисправности оборудования;
- плановые - отклонения параметров технологического процесса или состояния оборудования, являющиеся ожидаемыми, но при этом, возможно, являющиеся признаком нежелательных состояний атомной станции.
[ ГОСТ Р МЭК 60964-2012 , пункт 3.18] |
| alarms |
84
|
|
|
система: Совокупность компонентов, взаимодействующих в соответствии с проектом, в котором элемент системы может представлять собой другую систему, называемую подсистемой.
Примечания
1 См. также термин "СКУ".
2 СКУ отделяют от механических систем и электрических систем АС.
3 Это определение подкомитета ПК 45 А МЭК полностью соответствует определению "системы", данному в Глоссарии МАГАТЭ издания 2007 года в группе терминов "структуры систем и компонентов (SCC)".
[ ГОСТ Р МЭК 61513-2020 , пункт 3.56] |
| system |
85
|
|
|
система поддержки оператора; СПО: Система или системы, предназначенные для поддержки задач абстрактного мышления или задач интеллектуальной обработки информации, выполняемых персоналом блочного пункта управления (БПУ).
[ ГОСТ Р МЭК 60964-2012 , пункт 3.21] |
| operator support system; OSS |
86
|
|
|
система связи: Совокупность технических средств, программного обеспечения и среды передачи данных, позволяющая осуществить передачу сообщений от одного приложения к другому (прикладной уровень в соответствии с ГОСТ Р ИСО/МЭК 7498-1 ).
[ ГОСТ Р МЭК 61500-2012 , пункт 3.3] |
| communication system |
87
|
|
|
систематический отказ: Отказ, связанный детерминированным образом с какой-либо причиной, которая может быть исключена только путем модификации проекта либо производственного процесса, операций, документации либо других факторов.
Примечания
1 Корректирующее сопровождение без модификации обычно не устраняет причину отказа.
2 Систематический отказ может быть вызван имитацией причины отказа.
3 Примерами причин систематических отказов являются ошибки человека:
- в спецификации требований к безопасности;
- в проекте, изготовлении, установке или работе аппаратных средств;
- при проектировании, реализации и т.п. программного обеспечения.
[ ГОСТ Р МЭК 61508-4-2012 , статья 3.6.6] |
| systematic failure |
88
|
|
|
случайный отказ аппаратных средств: Отказ, возникающий в случайный момент времени, который является результатом одного или нескольких возможных механизмов ухудшения характеристик в аппаратных средствах.
Примечания
1 Существует много механизмов ухудшения характеристик, действующих с различной интенсивностью и в различных компонентах. Поскольку допуски изготовления приводят к тому, что компоненты в результате действия этих механизмов отказывают в разное время и отказы аппаратных средств включают в себя много факторов, то отказы происходят с предсказуемой частотой, но в непредсказуемые (т.е. случайные) моменты времени.
2 Основное различие между случайными отказами аппаратных средств и систематическими отказами состоит в том, что интенсивность отказов системы (или другие подобные характеристики таких отказов), связанная со случайными отказами аппаратных средств, может прогнозироваться с достаточной степенью точности, но систематические отказы по своей природе не могут быть предсказаны точно. Поэтому интенсивность отказов системы, связанных со случайными отказами аппаратных средств, может быть охарактеризована количественно с достаточной степенью точности, тогда как отказы системы, связанные с систематическими отказами, не могут быть статистически охарактеризованы с достаточной точностью, поскольку события, приводящие к таким отказам, не могут быть предсказаны.
[ ГОСТ Р МЭК 61508-4-2012 , статья 3.6.5] |
| random hardware failure |
89
|
|
|
срок службы: Период от начальной эксплуатации до окончательного вывода из эксплуатации конструкции, системы или элемента.
[[2], С] |
| service life |
90
|
|
|
срок эксплуатации (эксплуатационный ресурс): Период, в течение которого разрешенная (имеющая официальное разрешение) установка используется в целях, для которых она предназначена, до ее снятия с эксплуатации или закрытия.
[[2], С] |
| operating life/lifetime |
91
|
|
|
стратегия проектирования: Общий план и руководство по выполнению проекта.
[[4], статья 3.1150] |
| design strategy |
|
|
|
92 тест: Действие по приведению системы или элемента в рабочее состояние при определенных условиях, наблюдению и регистрации результатов функционирования с последующей оценкой тех или иных свойств системы или элемента.
|
| test |
93 тестирование: Процесс оценки свойств системы или элемента на основании наблюдения и регистрации результатов функционирования системы или элемента при определенных условиях.
|
| testing |
94 тестируемость: Степень, в которой система может быть протестирована как помодульно, так и в целом (степень, в которой система или элемент позволяют определить критерии тестирования и провести тестирование с целью проверки выполнения данных критериев).
|
| testability |
95 тестовая документация: Документация, содержащая описание планов тестирования или результатов тестирования системы или компонента.
|
| test documentation |
96 |
|
|
|
|
|
тестовое покрытие: Степень, с которой данный тест проверяет требования для системы или программного продукта.
[ ГОСТ Р ИСО/МЭК 12207-2010 , пункт 4.51] |
| test coverage |
97
|
|
|
тестовый сценарий: Совокупность исходных данных, условий выполнения и ожидаемых результатов испытаний, разработанных для конкретной цели, как, например, для выполнения конкретной части программы или подтверждения соответствия специфицированным требованиям.
[[6], пункт 3.1] |
| test case |
98
|
|
|
технические требования: Требования, относящиеся к технологии и окружающей среде, обеспечивающие функционирование, поддержку системы и выполнение программы.
[[4], статья 3.4187] |
| technical requirements |
99
|
|
|
технический анализ: Систематическая оценка продукции командой квалифицированного персонала, который исследует пригодность продукции для использования по назначению и идентифицирует несоответствия спецификациям и стандартам.
[[7], пункт 3.7] |
| technical review |
100
|
|
|
типовое испытание: Испытание на соответствие, проводимое на одном или более образцах, представляющих продукцию.
[ ГОСТ Р МЭК 61226-2011 , пункт 3.21] |
| type test |
101
|
|
|
точность измерения: Степень соответствия между результатом измерения и условно истинным значением измеряемой величины.
[ ГОСТ Р МЭК 62385-2012 , пункт 3.1] |
| accuracy of measurement |
|
|
|
102 требование к интерфейсу: Требование, определяющее внешний элемент, с которым может взаимодействовать система или ее компонент, или требование, которое определяет дальнейшие ограничения на форматы, синхронизацию либо другие факторы, связанные с таким взаимодействием.
103 |
| interface requirement |
|
|
|
требование к реализации: Требование, которое специфицирует или накладывает ограничение на кодирование или на конструкцию системы или элемента системы.
[[4], статья 3.1893] |
| implementation requirement |
|
|
|
104 требование к функционированию: Измеримый критерий, который определяет атрибут качества функционирования или степень соответствия заданному функциональному требованию.
105 |
| performance requirement |
|
|
|
требование потребителя: Результат выявления, обобщения и урегулирования противоречий между потребностями, ожиданиями и ограничениями заинтересованных в продукции сторон способами, приемлемыми для потребителя/заказчика.
[[4], статья 3.971] |
| customer requirement |
106
|
|
|
требование проекта: Требование, которое определяет или накладывает ограничения на внешний вид, структурные и функциональные особенности системы или элемента системы.
[[4], статья 3.1146] |
| design requirement |
107
|
|
|
угроза: Событие, обладающее потенциалом причинить вред здоровью персонала станции или привести к повреждению компонентов, оборудования или структур. Угрозы подразделяют на внутренние и внешние.
Примечания
1 Внутренние угрозы представляют собой, например, пожар и затопление, внутренние опасности могут являться последствиями ПИС (например, авария с потерей теплоносителя, разрыв паропровода).
2 Примером внешних опасностей может служить землетрясение или удар молнии.
[ ГОСТ Р МЭК 61513-2020 , пункт 3.25] |
| hazard |
108
|
|
|
уплотнение кода (программы): Целесообразное уменьшение размеров памяти, необходимой для программы, путем исключения избыточных или посторонних команд.
[ ГОСТ Р МЭК 60880-2010 , пункт 3.7] |
| code compaction |
109
|
|
|
управление качеством: Скоординированная деятельность по управлению и контролю организации в интересах обеспечения качества.
[[4], статья 3.3274] |
| quality management |
|
|
|
110 управление конфигурацией: Дисциплина, использующая техническое и административное управление и надзор в целях идентификации и документирования функциональных и физических характеристик элементов конфигурации, контроля изменения этих характеристик, документирования и формирования отчетности об изменениях и текущем статусе элементов конфигурации, а также подтверждения соответствия конфигурации и ее элементов заданным требованиям.
111 |
| configuration management |
|
|
|
уровень организации: Уровень управления или уровни, ответственные за управление одним или более устройствами обработки данных или информационными системами.
[[4], статья 3.2739] |
| organization level |
112
|
|
|
уровень проектирования: Глубина декомпозиции элемента программного обеспечения, установленная в проекте (например, система, подсистема, программа или модуль).
[[4], статья 3.1138] |
| design level |
113
|
|
|
фаза детального проектирования: Фаза жизненного цикла программного продукта, во время которой на основе проекта программной системы и программной архитектуры, выполненного на предыдущей фазе проектирования, осуществляется процесс детального проектирования, направленный на проработку детальной логики для каждого элемента программы, таким образом, чтобы можно было перейти непосредственно к кодированию.
[[4], статья 3.1165] |
| detailed design phase |
114
|
|
|
фаза проектирования: Период в жизненном цикле системы или программного продукта, во время которого создаются, документируются и верифицируются на соответствие требованиям проекты архитектуры, компоненты системы и/или ПО, интерфейсы и данные.
[[4], статья 3.1143] |
| design phase |
115
|
|
|
фаза проектирования архитектуры: Фаза жизненного цикла системы, в течение которой разрабатывается полная архитектура системы и, таким образом, выполняются требования, вытекающие из документов, содержащих требования к программному обеспечению, и появляется основа для детализации плана реализации системы.
[[4], статья 3.212] |
| architectural design phase |
|
|
|
116 фаза тестирования: Промежуток времени в жизненном цикле программного продукта, во время которого компоненты программного продукта оцениваются и комплексируются, а затем оценивается программный продукт в целом, на основании чего определяется, в какой степени он удовлетворяет заявленным требованиям. |
| test phase |
|
|
|
117 функциональная архитектура: Функциональная структура, представляющая собой упорядоченное изображение функций и их составляющих, а также интерфейсов (внутренних и внешних), которая определяет порядок функционирования, условия управления, потоки данных и показатели функционирования, удовлетворяющие исходным требованиям. |
| functional architecture |
118
|
|
|
функционально-ориентированное проектирование: Разделение проекта на подсистемы и модули, каждый из которых выполняет одну или более функций.
[[4], статья 3.1684] |
| function-oriented design |
|
|
|
119 функциональное проектирование: Процесс определения функциональных взаимосвязей между элементами системы.
|
| functional design |
120 функция: Определенное целевое или типичное действие системы или элемента системы.
|
| function |
121 |
|
|
|
|
|
функция СКУ: Функция контроля, управления и/или наблюдения за определенной частью процесса.
Примечания
1 Термин "функция СКУ" используется инженерами-технологами, чтобы структурировать функциональные требования к СКУ. Функция СКУ определена следующим образом:
- дает полное представление о функциональных целях;
- может быть категоризирована в соответствии с ее степенью важности для безопасности;
- для достижения функциональной цели учитывает малейшие сущности: от датчика до исполнительного устройства.
2 Функция СКУ может быть подразделена на несколько подфункций (например, на функцию измерения, функцию управления, функцию приведения в действие) в целях распределения по СКУ.
[ ГОСТ Р МЭК 61513-2020 , пункт 3.28] |
| l&C function |
122
|
|
|
целостность: Степень, в которой система или элемент препятствуют несанкционированному доступу к компьютерным программам или данным, или их несанкционированному изменению.
[[4], статья 3.2035] |
| integrity |
123
|
|
|
эксплуатационные пределы и условия: Совокупность правил, определяющих пределы параметров, функциональные возможности и уровни рабочих характеристик для оборудования и персонала, которые утверждены регулирующим органом с целью обеспечения безопасной эксплуатации разрешенной (имеющей официальное разрешение) установки.
[[2], Э] |
| operational limits and conditions |
|
|
|
124 эталонный тест: Процедура, задача или тест, которые могут быть использованы для сравнения систем или их элементов между собой или со стандартом. |
| benchmark |
Алфавитный указатель терминов на русском языке
|
|
авария проектная | 70 |
анализ технический | 99 |
архитектура СКУ | 4 |
архитектура функциональная | 117 |
АС | 3 |
барьер | 6 |
безопасность информационная | 16 |
библиотека | 7 |
блок программный | 65 |
веха | 36 |
генерация кода автоматизированная | 2 |
декомпозиция модульная | 42 |
документация тестовая | 95 |
ЖЦ | 11 |
задача обеспечения безопасности | 15 |
защищенность | 16 |
измерение | 17 |
инициализировать | 19 |
инкапсуляция | 20 |
интеграция | 21 |
испытание на месте работ | 43 |
испытание натурное | 43 |
испытание приемочное | 61 |
испытание типовое | 100 |
канал | 25 |
канал связи | 26 |
категория функции СКУ | 27 |
кибербезопасность | 16 |
класс СКУ | 28 |
комплекс оборудования | 29 |
комплексирование | 30 |
компонент | 31 |
компонент программного обеспечения | 32 |
конвейер | 35 |
контроллер программируемый (логический) | 63 |
контур связанный | 81 |
конфигурация | 37 |
конфигурация базовая | 5 |
конфигурация исходная | 23 |
критерий единичного отказа | 39 |
метод анализа шумов | 40 |
модель концептуальная | 38 |
модификация ПО | 41 |
неодинаковость | 45 |
обеспечение качества | 46 |
оборудование передачи данных | 48 |
объект конфигурации | 50 |
ОК | 46 |
оператор | 51 |
описание архитектуры | 52 |
основа проекта | 72 |
основы проекта | 72 |
основы проектные | 72 |
отказ | 53 |
отказ аппаратного средства выявленный | 9 |
отказ аппаратного средства невыявленный | 44 |
отказ аппаратных средств случайный | 88 |
отказ единичный | 10 |
отказ зависимый | 14 |
отказ по общей причине | 54 |
отказ программного обеспечения | 55 |
отказ систематический | 87 |
охват диагностикой | 56 |
передача данных | 57 |
периодичность испытаний | 58 |
план проекта | 59 |
ПЛК | 63 |
покрытие тестовое | 96 |
пределы и условия эксплуатационные | 123 |
программа компьютерная | 34 |
программа рабочая | 73 |
проект архитектуры | 66 |
проектирование | 67 |
проектирование сверху вниз | 68 |
проектирование снизу вверх | 69 |
проектирование функционально-ориентированное | 118 |
проектирование функциональное | 119 |
проектный | 72 |
резервирование | 74 |
ресурс эксплуатационный | 90 |
руководство оператора | 76 |
руководство по обслуживанию | 77 |
руководство по установке | 78 |
руководство пользователя | 79 |
руководство программиста | 80 |
сеть | 82 |
сигнализация | 83 |
система | 84 |
система автоматизированная | 3 |
система компьютеризированная | 33 |
система обеспечивающая | 47 |
система поддержки оператора | 85 |
система связи | 86 |
событие проектное | 71 |
СПО | 85 |
средства вспомогательные системы безопасности | 8 |
срок службы | 89 |
срок эксплуатации | 90 |
стратегия проектирования | 91 |
сценарий тестовый | 97 |
тест | 92 |
тест эталонный | 124 |
тестирование | 93 |
тестируемость | 94 |
технические характеристики предельные | 60 |
точка контрольная | 36 |
точность измерения | 101 |
трасса кабельная | 24 |
требование к интерфейсу | 102 |
требование к реализации | 103 |
требование к функционированию | 104 |
требование потребителя | 105 |
требование проекта | 106 |
требования технические | 98 |
угроза | 107 |
уплотнение кода (программы) | 108 |
управление доступом ролевое | 75 |
управление качеством | 109 |
управление конфигурацией | 110 |
уровень организации | 111 |
уровень проектирования | 112 |
условия аварийные | 1 |
устройство изолирующее | 18 |
устройство исполнительное | 22 |
устройство программируемое | 62 |
фаза детального проектирования | 113 |
фаза проектирования | 114 |
фаза проектирования архитектуры | 115 |
фаза тестирования | 116 |
функция | 120 |
функция СКУ | 121 |
целостность | 122 |
цикл жизненный | 11 |
цикл жизненный безопасности ПО | 12 |
цикл жизненный безопасности системы | 13 |
цикл жизненный общий безопасности СКУ | 49 |
часть программная составная | 64 |
Алфавитный указатель эквивалентов терминов на английском языке
|
|
acceptance test | 61 |
accident conditions | 1 |
accuracy of measurement | 101 |
actuation device | 22 |
aggregation | 30 |
alarms | 83 |
architectural description | 52 |
architectural design | 66 |
architectural design phase | 115 |
AS | 3 |
associated circuit | 81 |
automated code generation | 2 |
automated system | 3 |
barrier | 6 |
benchmark | 124 |
bottom-up design | 69 |
cable route | 24 |
category of an l&C function | 27 |
channel | 25 |
class of an l&C system | 28 |
code compaction | 108 |
common cause failure | 54 |
communication channel | 26 |
communication system | 86 |
component | 31 |
computer-based system | 33 |
computer program | 34 |
conceptual model | 38 |
configuration | 37 |
configuration baseline | 5; 23 |
configuration item | 50 |
configuration management | 110 |
customer requirement | 105 |
data communication | 57 |
data communication equipment | 48 |
DBE | 71 |
dependent failure | 14 |
design | 67 |
design basis | 72 |
design basis accident | 70 |
design basis event | 71 |
design level | 112 |
design phase | 114 |
design requirement | 106 |
design strategy | 91 |
detailed design phase | 113 |
diagnostic coverage | 56 |
diversity | 45 |
enabling system | 47 |
encapsulation | 20 |
equipment family | 29 |
executable code | 73 |
failure | 53 |
function | 120 |
function-oriented design | 118 |
functional architecture | 117 |
functional design | 119 |
hazard | 107 |
HDL-programmed device | 62 |
HPD | 62 |
l&C architecture | 4 |
l&C function | 121 |
implementation requirement | 103 |
in-situ test | 43 |
initialize | 19 |
installation manual | 78 |
integration | 21 |
integrity | 122 |
interface requirement | 102 |
isolation device | 18 |
library | 7 |
life cycle | 11 |
lifetime | 90 |
measurement | 17 |
milestone | 36 |
modular decomposition | 42 |
network | 82 |
noise analysis technique | 40 |
operating life | 90 |
operational limits and conditions | 123 |
operations manual | 76 |
operator | 51 |
operator manual | 76 |
operator support system | 85 |
organization level | 111 |
OSS | 85 |
overall safety life cycle of the l&C | 49 |
performance limits | 60 |
performance requirement | 104 |
pipeline | 35 |
PLC | 63 |
programmable (logic) controller | 63 |
programmer manual | 80 |
project plan | 59 |
QA | 46 |
quality assurance | 46 |
quality management | 109 |
random hardware failure | 88 |
redundancy | 74 |
revealed hardware failure | 9 |
role-based access control | 75 |
safety system support features | 8 |
safety task | 15 |
security | 16 |
service life | 89 |
SFC | 39 |
single failure | 10 |
single failure criterion | 39 |
software component | 32 |
software failure | 55 |
software item | 64 |
software modification | 41 |
software safety life cycle | 12 |
software unit | 65 |
support manual | 77 |
system | 84 |
system safety life cycle | 13 |
systematic failure | 87 |
technical requirements | 98 |
technical review | 99 |
test | 92 |
test case | 97 |
test coverage | 96 |
test documentation | 95 |
test interval | 58 |
test phase | 117 |
testability | 94 |
testing | 93 |
top-down design | 68 |
type test | 100 |
unrevealed hardware failure | 44 |
user manual | 79 |
Библиография
|
|
[1] | IAEA SSR-2/1 (Rev.1)* Безопасность атомных электростанций: проектирование. Конкретные требования безопасности, N SSR-2/1 (Rev. 1) (Safety of Nuclear Power Plants: Design, 2016) |
| |
[2] | Глоссарий МАГАТЭ по вопросам безопасности. Терминология, используемая в области ядерной безопасности и радиационной защиты. Издание 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 |
| |
Ключевые слова: атомные станции; системы контроля и управления, важные для безопасности; пункт управления; классификация систем |