ГОСТ Р МЭК 61069-2-2017
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
ИЗМЕРЕНИЕ, УПРАВЛЕНИЕ И АВТОМАТИЗАЦИЯ ПРОМЫШЛЕННОГО ПРОЦЕССА. ОПРЕДЕЛЕНИЕ СВОЙСТВ СИСТЕМЫ С ЦЕЛЬЮ ЕЕ ОЦЕНКИ
Часть 2
Методология оценки
Industrial-process measurement, control and automation. Evaluation of system properties for the purpose of system assessment. Part 2. Assessment methodology
ОКС 25.040.40
Дата введения 2018-09-01
Предисловие
1 ПОДГОТОВЛЕН Негосударственным образовательным частным учреждением дополнительного профессионального образования "Новая Инженерная Школа" (НОЧУ "НИШ") на основе собственного перевода на русский язык англоязычной версии указанного в пункте 4 стандарта, который выполнен Российской комиссией экспертов МЭК/ТК 65 и Федеральным государственным унитарным предприятием "Всероссийский научно-исследовательский институт стандартизации" (ВНИИНМАШ)
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 306 "Измерения и управление в промышленных процессах"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 7 ноября 2017 г. N 1650-ст
4 Настоящий стандарт идентичен международному стандарту МЭК 61069-2:2016* "Измерение, управление и автоматизация промышленного процесса. Определение свойств системы с целью ее оценки. Часть 2. Методология оценки" (IEC 61069-2:2016 "Industrial-process measurement, control and automation - Evaluation of system properties for the purpose of system assessment - Part 2: Assessment methodology", IDT).
________________
* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. - Примечание изготовителя базы данных.
Международный стандарт разработан Техническим комитетом МЭК ТК 65 "Измерения и управление в промышленных процессах".
При применении настоящего стандарта рекомендуется использовать вместо ссылочного международного стандарта соответствующий ему национальный стандарт, сведения о котором приведены в дополнительном приложении ДА
5 ВЗАМЕН ГОСТ Р МЭК 61069-2-2012
6 ПЕРЕИЗДАНИЕ. Апрель 2020 г.
Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ "О стандартизации в Российской Федерации". Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)
Введение
В МЭК 61069 рассматривается метод, который следует использовать для оценки системных свойств основной системы управления (ОСУ). МЭК 61069 состоит из следующих частей:
часть 1. Терминология и основные концепции;
часть 2. Методология оценки;
часть 3. Оценка функциональности системы;
часть 4. Оценка производительности системы;
часть 5. Оценка надежности системы;
часть 6. Оценка эксплуатабельности системы;
часть 7. Оценка безопасности системы;
часть 8. Оценка других свойств системы.
Оценка системы - основанное на доказательстве суждение о пригодности системы для определенного целевого назначения или класса целевых назначений.
Для получения полного итогового доказательства потребовалось бы полное (т.е. при всех влияющих факторах) определение пригодности всех свойств системы для конкретного целевого назначения или класса целевых назначений.
Так как на практике это требуется редко, для оценки системы более рациональным будет:
- определить критичность соответствующих свойств системы;
- спланировать определение (оценку) соответствующих свойств системы на основе экономического принципа "цена - целесообразность" для усилий по реализации этих свойств.
При проведении оценки системы следует стремиться к получению максимальной обоснованности пригодности системы с учетом целесообразной стоимости и ограничений по времени.
Оценка может быть выполнена только в том случае, если целевое назначение (миссия) сформулировано (или задано), или если оно может быть представлено гипотетически. В случае отсутствия миссии оценка не может быть выполнена. Тем не менее, возможно определение свойств системы в части сбора и систематизации данных для последующей оценки, проводимой другими лицами. В таком случае настоящий стандарт может применяться как руководство для планирования, а также устанавливает процедуры определения свойств системы, являющееся неотъемлемой частью оценки системы.
При подготовке к оценке может быть установлено, что определение границ системы является слишком узким. Например, для средства с двумя или более версиями совместного пользования системы управления, например сети, необходимо учитывать вопросы сосуществования и функциональной совместимости. В этом случае система, подлежащая оценке, не должна ограничиваться "новыми" ОСУ. Такая система должна включать в себя как "новые", так и "старые" системы. То есть, система должна изменять свои границы, чтобы включать в себя достаточный объем другой системы для решения требуемых от нее задач.
Структура настоящей части и ее взаимосвязь с другими частями МЭК 61069 показаны на рисунке 1.
|
Рисунок 1 - Общий состав МЭК 61069
1 Область применения
Настоящий стандарт устанавливает методологию оценки основной системы управления (ОСУ) на основании общих концепций, данных в МЭК 61069-1.
В настоящем стандарте описаны методы анализа целей оценки, определения важности различных свойств систем, влияющих факторов, а также разработки программы оценки.
2 Нормативные ссылки
В настоящем стандарте использована нормативная ссылка на следующий стандарт. Для датированной ссылки применяют только указанное издание ссылочного стандарта, для недатированной - последнее издание (включая все изменения):
IEC 61069-1, Industrial-process measurement, control and automation - Evaluation of system properties for the purpose of system assessment - Part 1: Terminology and basic concepts (Измерение, управление и автоматизация промышленного процесса - Определение свойств системы с целью ее оценки. Часть 1. Терминология и базовые концепции)
_________________
Второе издание стандарта подлежит одновременной публикации с настоящим стандартом.
3 Термины, определения, обозначения и сокращения
3.1 Термины и определения
В настоящем стандарте применены термины по МЭК 61069-1.
3.2 Обозначения и сокращения
В настоящем стандарте применены обозначения и сокращения по МЭК 61069-1.
4 Подход к оценке
ОСУ являются достаточно сложными, так что общая, полная оценка неизбежно требует затрат усилий и времени для того, чтобы быть практически реализуемой в соответствии с критерием "цена - эффективность". Поэтому важно тщательно проанализировать и установить конкретные цели оценки, прежде чем разрабатывать программу проведения оценки.
Целевое назначение (миссия) системы или класс целевых назначений (миссий) разбиваются на задачи.
Задачу (задачи), которую система должна выполнять, следует определять в отношении выбранной ОСУ, ее системных свойств и необходимых функций. Это дает возможность точно определить функции, которыми должна обладать система для выполнения ее целевого назначения (миссии).
Целевые назначения (миссии) системы, как правило, требуют некоторых характеристик системы, которые напрямую не связаны с задачами системы. Данные характеристики включают в себя документацию и услуги по информационно-технической поддержке.
Программа оценки должна разрабатываться вместе с определением цели оценки, системными требованиями и системными спецификациями. Программа проведения оценки должна быть разработана предварительно.
Примечание - В определенных случаях, например, при регламентированном применении, может потребоваться, чтобы программа оценки разрабатывалась и оценка проводилась независимой стороной.
Если для системы не определено целевое назначение (миссия), то оценка не может быть проведена. Тем не менее, может быть выполнено исследование системы с целью сбора и организации данных для проведения последующей оценки.
5 Методология оценки
5.1 Обзор
5.1.1 Общие положения
Детали программы оценки должны быть определены (как указано в 5.2) исходя из целей оценки и следующих документов:
- документа о требованиях к системе (ДТС) и
- документа спецификации системы (ДСС).
Примечание 1 - Документ о требованиях к системе (ДТС) приведен в приложении А.
Примечание 2 - Документ спецификации системы (ДСС) приведен в приложении В.
При проведении оценки осуществляется корреляция положений ДТС с положениями ДСС, исходя из цели оценки.
Если на любом этапе оценки будет потеряна или являться неполной информация из ДТС или ДСС, для получения необходимой дополнительной информации необходимо проконсультироваться с разработчиками ДТС или ДСС по всем возникшим вопросам.
Метод оценки - это средство, которое надлежит применять в течение всего жизненного цикла ОСУ. Тем не менее, жизненный цикл не рассматривается в МЭК 61069-2. Во время разработки программы проведения оценки ОСУ, необходимо учитывать общий срок ее службы.
Необходимо планировать проведение оценки для каждого соответствующего этапа жизненного цикла, например, для пуско-наладочных работ.
5.1.2 Этапы
Оценка состоит из следующих этапов:
- определение целей оценки;
- проектирование и схема оценки;
- планирование программы проведения оценки;
- проведение оценки;
- составление отчета о результатах проведения оценки.
Этапы и соответствующие им исходные/выходные документы приведены в таблице 1.
Таблица 1 - Исходные и выходные документы, этапы оценки
Этап |
Исходный документ |
Выходной документ |
Определение целей оценки |
ДТС и ДСС |
(Задокументированная) цель оценки |
Проектирование и схема оценки |
Цель оценки |
Спецификация оценки |
Планирование программы проведения оценки |
Спецификация оценки |
Программа оценки |
Проведение оценки |
Программа оценки |
Результаты определений свойств |
Составление отчета о результатах проведения оценки |
Результаты определения свойств |
Отчет об оценке |
5.2 Определение целей оценки
Цели оценки должны быть указаны и задокументированы до начала оценки в качестве основания для планирования и разработки программы проведения оценки. Цели должны быть четко сформулированы.
Эти цели образуют основание для руководящих принципов при проведении оценки посредством определения:
- области применения;
- характера оценки;
- глубины проводимой оценки;
- измерений и наблюдений, которые необходимо выполнить;
- типов отчетов, которые будут подготовлены.
Цели определяют стоимость оценки и ресурсы, требуемые для проведения оценки.
Поэтому крайне важно, чтобы цели и объем оценки были тщательно задокументированы и согласованы до того, как программа оценки будет полностью разработана.
Необходимо определить степень изменения ОСУ, которое потребует повторной оценки, например, расширение ОСУ.
Сроки проведения повторной оценки в течение срока службы ОСУ, вне зависимости от результатов изменений/расширений, должны быть указаны, например, по истечении 10 лет эксплуатации.
Кроме того, должны быть указаны органы власти, которые согласовывают первоначальные и повторные оценки.
Во время оценки, должны проводиться проверки в запланированных местах проверки и с заранее установленными временными интервалами. Данные проверки должны проводиться, как минимум, в конце каждого этапа.
Например, целями оценки могут быть:
- оценка специальной системы для определенного целевого назначения (миссии);
- оценка широкого диапазона конфигураций одной системы для определенного целевого назначения (миссии);
- сравнение нескольких систем для определенного целевого назначения (миссии);
- оценка определенной системы для общего применения при широком выборе целевых назначений (миссий);
- подтверждение пригодности системы для определенного целевого назначения (миссии);
- подтверждение пригодности системы для установленного класса целевых назначений (миссий).
Протокол должен содержать следующую информацию:
- органы оценки, которые вносят изменения и разрабатывают программу оценки;
- спецификации и отчеты по оценке;
- процедуры, подлежащие выполнению;
- чрезвычайные действия, которые допустимы без получения разрешения в случае, если оценку невозможно выполнить так, как планировалось.
5.3 Проектирование и схема оценки
5.3.1 Определение объема оценки
5.3.1.1 Границы системы
Граница системы должна быть тщательно определена с учетом того, "что входит" и "что не входит" в состав системы, подлежащей оценке.
Границы системы, подлежащей оценке, должны быть определены с учетом всех аспектов влияющих факторов, описанных в 5.3 МЭК 61069-1. Они должны быть задокументированы в спецификации оценки.
Границы системы могут быть физическими (например, оборудование, география) и/или виртуальными (например, информация, связь).
Цели оценки определяют объем оценки. Для определения объема оценки, необходимо учитывать свойства системы, описанные в 5.2.2-5.2.7 МЭК 61069-1.
5.3.1.2 Конфигурация системы, подлежащей оценке, должна быть указана в спецификации оценки. Так как конфигурируемость системы сама по себе может быть свойством системы, подлежащей оценке, конфигурация системы, в которой определяются элементы оценки, должна устанавливаться тщательным образом.
Если цель оценки состоит в том, чтобы оценить определенную систему для определенного целевого назначения (миссии), то оценка должна быть выполнена на определенной конфигурации системы, и данная конфигурация должна быть задокументирована в спецификации оценки.
Если цель оценки состоит в том, чтобы оценить гибкость системы для соответствия широкому диапазону типовых требований, с которыми сталкиваются в определенной отрасли промышленности, оценка должна быть выполнена для определенного набора модулей, которые могут быть применены в разнообразных альтернативных конфигурациях. Данные модули и набор конфигураций должны быть задокументированы в спецификации оценки.
Иногда система может быть настолько сложной, что всестороннее определение всех свойств системы будет экономически неэффективным и даже невозможным. Посредством тщательного анализа целей, конфигурации системы и факторов воздействия, объем определения может быть уменьшен для того, чтобы включать в себя только те элементы оценки, которые являются наиболее важными для целевого назначения (миссии) системы.
5.3.2 Свойства системы и влияющие факторы
Должны быть определены элементы оценки, которые требуется оценить. Должны быть также установлены требуемые значения или диапазоны значений каждого свойства системы и влияющего фактора.
Кроме того, насколько это возможно, должны быть включены влияющие факторы, описанные в МЭК 61069-1.
Каждый элемент, подлежащий оценке, должен быть тщательно проанализирован, чтобы определить влияет ли он на свойства системы в такой степени, что оказывает негативное воздействие или препятствует выполнению оценки других элементов.
Результаты анализа должны быть задокументированы в спецификации оценки для определения ограничений на последовательность действий при проведении оценки.
Документировать свойства системы и влияющие факторы удобно в виде матрицы, в которой ячейки соответствуют элементам оценки.
Обобщенная матрица, суммирующая оценку, представлена на рисунке 2.
|
Рисунок 2 - Матрица оценки
Элементы оценки, которые необходимо включить в оценку, должны быть выбраны, а их относительные приоритеты должны быть определены. Это может быть выполнено с помощью данной матрицы, применяемой как средство анализа каждого свойства системы и фактора воздействия, с учетом цели оценки.
Элемент оценки может быть еще более детализирован посредством применения, например, групп или подгрупп свойств, в которых заголовки общей матрицы будут еще более расширены в более детальные свойства системы и факторы воздействия.
Элементы оценки, которые не приемлемы для конкретной оценки, должны быть также идентифицированы для последующей ссылки, а причины их исключения должны быть задокументированы.
5.3.3 Сопоставление документированной информации
Сопоставление - это шаг данного этапа для выявления информации, необходимой для определения потенциальных элементов, подлежащих оценке. Информация, полученная в результате данного процесса, применяется при проектировании и составлении схемы оценки.
Необходимую для сопоставления информацию следует получать из ДТС и ДСС.
ДТС и ДСС должны быть тщательно проанализированы, для составления точных и кратких заключений по соответствующим вопросам. Примеры таких вопросов:
- границы системы;
- области, в которых имеются несоответствия между требованиями к системе и спецификацией системы;
- перечень задач, необходимых для решения в настоящее время и в будущем;
- перечень функций, обеспечивающих выполнение каждой задачи в настоящее время и в будущем;
- перечень альтернативных путей данных, подключенных к функциям для выполнения требуемых задач;
- распределение функций по модулям и элементам;
- число данных модулей и элементов;
- степень использования данных модулей и элементов для выполнения требуемых задач;
- свойства системы для каждой из вышеуказанных функций;
- факторы, влияющие на каждый из вышеуказанных модулей/элементов.
На основании данных вопросов должен быть создан перечень потенциальных элементов оценки. Данные элементы оценки должны быть определены в соответствии с определенной конфигурацией системы согласно цели оценки.
Каждый потенциальный элемент оценки должен быть изучен для определения степени оценки данного элемента для повышения уровня ее достоверности.
Результаты должны быть описаны в количественном и качественном выражениях, и, в соответствующих случаях, с указанием диапазона значений.
Примечание - Примеры сопоставления документации приведены в приложении С.
Каждая задача, подлежащая оценке, должна быть описана в отношении вводов, выводов и функционирования.
Для каждого ввода особое внимание следует уделить:
- допустимому состоянию ввода и соответствующим допустимым состояниям вывода;
- недопустимому состоянию ввода и соответствующим необходимым действиям.
Для каждого вывода особое внимание следует уделить:
- допустимому состоянию вывода;
- недопустимому состоянию вывода и соответствующим необходимым действиям.
В отношении каждой задачи должна быть четко предоставлена следующая информация:
- виды отказов, негативно влияющих на каждую задачу;
- допустимая частота появления каждого отказа;
- действия, которые необходимо предпринять при каждом отказе;
- максимальное время, в течение которого выполнение задачи может быть остановлено до восстановления модуля.
5.3.4 Документирование информации сопоставления
Информация, сопоставленная в соответствии с 5.3.3, должна быть задокументирована так, чтобы ее можно было обработать в процессе планирования программы оценки.
Если информация для сопоставления утеряна или является неполной, необходимая дополнительная информация должна быть получена от разработчиков ДТС и ДСС. Такая дополнительная или последующая информация должна быть задокументирована соответствующим образом в спецификации оценки.
5.3.5 Выбор элементов оценки
Полный перечень элементов оценки необходимо сократить, используя следующие фильтры:
- важность задачи (задач) для целевого назначения (миссии);
- существующий уровень достоверности на основании первоначальных знаний;
- уровень взаимозависимости различных функций, количество интерфейсов, повторное использование одной и той же функции для выполнения различных задач;
- общие доступные предварительные знания и степень применения знаний к элементам оценки.
Относительная важность элемента оценки должна быть определена с учетом как аспектов значимости задач на определенном этапе жизненного цикла системы, так и длительности этапа, так как значимость может меняться в зависимости от этапа.
Существующий уровень достоверности может основываться на предшествующем успешном функционировании системы при подобных или идентичных целевых назначениях (миссий), опыте изготовителя, опыте работы потребителей с подобного рода системами или совместимыми с ними системами.
Элементы оценки, требуемые международными и национальными регулирующими органами, должны определяться в соответствии с правилами, установленными данными органами.
Элементы оценки должны включать в себя проверку соответствия ОСУ национальному законодательству, действующему на площадке, на которой планируется использование системы.
5.3.6 Спецификация оценки
Спецификация оценки - это документ, описывающий, что подлежит оценке. Спецификация оценки должна определять, как минимум, следующее:
- цель оценки в соответствии с подразделом 5.2;
- границы системы в соответствии с 5.3.1.1;
- конфигурацию системы в соответствии с 5.3.1.2;
- матрицу оценки в соответствии с 5.3.2;
- перечень элементов оценки в соответствии с 5.3.2;
- перечень задач в соответствии с 5.3.3;
- критерии, применяемые для фильтрации элементов в соответствии с 5.3.5;
- ссылочные стандарты для каждого элемента оценки.
5.4 Планирование программы оценки
5.4.1 Общие положения
Во время данного этапа, программа оценки должна планироваться на основании спецификации оценки, подготовленной в течение предыдущего этапа.
Целью разработки программы оценки является увеличение уровня достоверности определения пригодности системы для целевого назначения (миссии) системы.
Действия по оценке должны максимизировать данное повышение уровня достоверности в рамках определенных затрат и временных ограничений.
Программа оценки должна устанавливать действия по оценке и их последовательность таким способом, который позволил бы управлять процессом проведения оценки.
Программа оценки должна включать в себя набор действий по оценке, каждое из которых может быть:
- наблюдением на системном уровне; или
- наблюдением на более низких уровнях (если необходимо опуститься до отдельного элемента) в комбинации с синтезом на системном уровне.
Проект конкретных действий по оценке зависит от рассматриваемых свойств системы.
Программа оценки должна определять также детальную информацию о каждом действии по оценке, включая:
- тип методов определения;
- требуемые средства и сервисные программы.
Применяемые методы определения должны выбираться так, чтобы результаты можно было сравнить в количественном и/или качественном выражениях.
Выбранные методы определения могут быть аналитическими с использованием только системной документации, или эмпирическими, требующими доступа к системе определения свойств. На практике выбранные методы будут представлять собой комбинацию аналитических и эмпирических методов и испытаний с использованием системной документации и ограниченной комбинации модулей.
Действия по оценке должны планироваться в логической последовательности с соблюдением всех ограничений элементов оценки, идентифицированных в спецификации оценки. Для выбора действий по оценке, включенных в программу оценки, каждое потенциальное действие должно быть проанализировано по следующим аспектам:
- определение методов и средств;
- стоимость и время, необходимые для выполнения;
- значимость.
Шаги по планированию программы оценки должны повторяться до тех пор, пока программа не будет согласована всеми сторонами, участвующими в оценке.
5.4.2 Разработка действий по оценке
Перечень действий по оценке должен быть разработан на основании следующих критериев:
- тип анализа и/или определения, необходимых для поддержки оценки;
- значимость определенного свойства системы для целевого назначения (миссии) в целом;
- значимость свойства системы и влияющие факторы для целевого назначения (миссии);
- знания и навыки, необходимые для выполнения каждого анализа и/или испытания;
- ограничения графика оценки в результате постоянных воздействий, которые могут влиять на испытания производительности и других свойств системы;
- технические ограничения оценки, такие как размер, вес, наличие сервисных программ, контроль за испытательной средой; и
- наличие обученного персонала;
- наличие группы обученных операторов для выполнения определенных задач по контролю за эксплуатабельностью;
- средства и сервисные программы, необходимые для выполнения анализов и испытаний;
- наличие средств для выполнения действий по оценке;
- расчет затрат и времени для каждого анализа и испытания;
- рассчитанные затраты и время действий по оценке;
- уровень приоритета для каждого действия по оценке;
- уровень достоверности на основании предыдущих знаний.
Иногда необходимо рассмотреть несколько методов определения, которые взаимно дополняют друг друга.
Все перечни действий по оценке должны быть учтены в программе оценки системы.
5.4.3 Программа оценки
Программа оценки должна устанавливать:
- методы определения свойства, выбранные в соответствии с 5.4.1;
- критерии, которые надлежит учитывать в соответствии с 5.4.2;
- требуемое повышение уровня достоверности;
- график проведения оценки, учитывающий возможные постоянные влияющие факторы, которые могут оказывать испытания;
- режимы отказа, которые должны быть проанализированы и/или определены, а также ожидаемые итоговые воздействия;
- физическая целостность и технологии обеспечения кибербезопасности, предусмотренные в системе.
5.5 Проведение оценки
Действия по оценке должны выполняться в соответствии с программой проведения оценки, определенной в подразделе 5.4, и в соответствии с разработанным протоколом оценки, установленным в подразделе 5.2.
Если необходимы отклонения от программы или протокола оценки, они должны быть указаны в отчете об оценке и, если предварительно согласованные действия в непредвиденных обстоятельствах не могут быть выполнены, то данные отклонения должны быть утверждены органами оценки.
Все наблюдения, измерения, вычисления должны быть зарегистрированы в отчете об оценке на момент их выполнения.
5.6 Отчет об оценке
Проведение и результаты оценки должны быть документально оформлены в отчете об оценке. В отчете должна быть точно, ясно, однозначно и объективно определена цель, представлены результаты и вся соответствующая информация по оценке.
Отчет должен, как минимум, содержать следующую информацию:
- название отчета об оценке;
- уникальный идентификационный номер отчета;
- дату выдачи отчета;
- наименование органа по оценке;
- ссылку на спецификацию оценки, описанную в 5.3.6;
- ссылку на программу оценки, установленную в 5.4.3;
- конфигурацию системы, например, тип и количество вводов/выводов, требуемая скорость сканирования, целевое назначение (миссия), задачи и функции;
- характеристики целевого назначения (миссии), такие как тип процесса в случае оценки для определенного целевого назначения (миссии);
- описание и идентификация системы, подлежащей оценке, включая перечень, отражающий аппаратное обеспечение с указанием номеров модели, и используемое программное обеспечение с датой выпуска;
- резюме по существенным пунктам, вытекающим из оценки и сформулированных заключений;
- перечень процедур, методов, спецификаций и испытаний (предпочтительно полученных в итоге в матричной форме и добавленных в соответствии с упомянутыми документами);
- причины, ведущие к конкретному выбору элементов оценки, подлежащих определению и причины, по которым другие элементы оценки не были выбраны;
- любые отклонения от программы оценки (дополнения или исключения);
- измерения, испытания и полученные результаты, подтверждаемые соответствующими таблицами, графиками, чертежами или фотографиями;
- установленные отказы;
- заключение о неопределенности измерений;
- заключение о том, действительно ли система соответствует требованиям, в соответствии с которыми она была оценена, включая заключение о любых несоответствиях.
Форма отчета должна быть стандартизована для облегчения сравнения оценок различных систем. Результаты оценки должны быть подтверждены информацией в соответствующей форме, такой как перечни, матрицы и графики.
Исправления или дополнения к отчету после его выпуска должны производиться только в виде дополнительного отчета со ссылкой на первоначальный отчет, который идентифицируется по названию и номеру. Такой дополнительный отчет должен соответствовать тем же требованиям, что и основной отчет.
6 Методы определения свойств
Методы, применяемые для определения свойств, подлежащих оценке, должны выбираться так, чтобы можно было провести сравнение результатов, как количественно, так и качественно в соответствии с требованиями, установленными в ДТС, с необходимым уровнем достоверности.
Выбранные методы определения свойств могут быть аналитическими, с использованием только системной документации; априорными доказательствами или данными, или в некоторых случаях могут быть комбинацией аналитических и эмпирических методов, требующих доступ к системе определения свойств.
На практике выбранные методы представляют собой комбинацию аналитических и эмпирических испытаний с использованием системной документации и (ограниченной) комбинации модулей.
Для данной цели модель системы должна компоноваться с помощью выбора функций системы, отображающего задачи, подлежащие выполнению, и детально демонстрирующего средства двухсторонней связи, предусмотренной в ЧМИ.
Примечание - Пример модели приведен в МЭК 61069-4, приложение D.
_________________
Второе издание стандарта подлежит одновременной публикации с настоящим стандартом.
Приложение А
(справочное)
Документ о требованиях к системе (ДТС)
А.1 Введение
В настоящем приложении описывается метод разработки и проверки ДТС, включая контрольный перечень для каждого свойства системы.
А.2 Анализ целевого назначения (миссии) системы
А.2.1 Общие положения
Для оценки ОСУ, необходимо определить целевое назначение (миссию) системы.
Целевое назначение (миссия) системы может быть надлежащим образом определено только в том случае, если система рассматривается в конкретном контексте, т.е. с учетом персонала, процесса, к которому она относится, и других систем, связанных с ней, а также среды, в которой она функционирует.
Результатом действий, указанных в А.2.2, А.2.3, А.2.4 и А.2.5 должен стать Документ о требованиях к системе (ДТС).
А.2.2 Формулирование целевого назначения (миссии) системы
Целью данного этапа является определение целевого назначения (миссии) ОСУ, а не роли, которую должна она выполнять.
В описании целевого назначения (миссии) необходимо указать, что должно быть достигнуто, а не способ и средства достижения этого.
Целевое назначение (миссия) должно характеризоваться определенными этапами. Этапы могут включать в себя:
- исходную конфигурацию и пуско-наладочные работы всего объекта, включая персонал, установку, ОСУ и другие системы, которые будут применяться для выполнения целевого назначения (миссии);
- конфигурацию и настройку для определенных производственных прогонов;
- производство, которое может включать в себя стабильную постоянную работу или программируемые последовательности подопераций;
- переход с одного производственного прогона на другой;
- аварийный останов или переход в состояние поддержания безопасности;
- штатный останов;
- обновления и изменения системы для добавления новых задач или функций;
- вывод системы из эксплуатации по истечении ее срока эксплуатации.
Хотя это и не всегда является очевидным, но этапы формирования, пуско-наладочных работ и вывода системы из эксплуатации являются очень важными и могут образовывать часть целевого назначения (миссии) системы.
А.2.3 Анализ целевого назначения (миссии) системы с помощью задач
Для реализации целевого назначения (миссии), ОСУ должна выполнять определенные задачи и/или иметь определенные свойства, связанные с каждым из этапов целевого назначения системы, указанных выше. Эти этапы анализируются для определения задач, которые должна выполнить система.
Задачи, выполняемые в пределах этапа, могут быть, например следующими:
- контроль и централизованное отображение контролируемых значений, которые могут включать в себя обработку измеряемых переменных для получения значений переменных целевого назначения (миссии);
- активация определенного этапа в технологическом процессе в соответствии с введенными вручную или автоматическими командами;
- автоматическое управление технологическими процессами, например, автоматическое управление отдельной технологической переменной;
- блокировка управления технологическими переменными;
- автоматическая инициация и выполнение этапа.
ОСУ могут потребоваться только для выполнения определенных задач, как полностью, так и частично, т.е. для задачи, выполняемой совместно с другой системой или другим персоналом.
Каждая задача определяется достаточно детально, чтобы понять масштабы такой задачи, поставленной для выполнения ОСУ.
Для каждой из задач должны быть определены требования по функциональности, производительности, надежности, эксплуатабельности, безопасности системы и/или свойств системы, например обеспечение качества, послепродажное обслуживание и т.д.
Следует отметить, что на данном этапе, целью является определение задач системы, а не функций системы.
А.2.4 Определение относительной значимости задачам
На данном этапе необходимо рассмотреть взаимозависимость целевого назначения (миссии) с каждой из задач. Задачи должны быть классифицированы, как минимум, по группам значимости для целевого назначения (миссии):
- важные: задачи, которые являются важными для выполнения целевого назначения (миссии);
- значимые: задачи, которые не являются важными, но имеют значительный эффект на затратную эффективность целевого назначения (миссии);
- желательные: задачи, которые являются желательными, но оказывают минимальный количественный эффект на целевое назначение (миссию).
А.2.5 Определение влияющих факторов
На правильность выполнения каждой из задач, предусмотренных целевым назначением (миссией), могут влиять определенные факторы.
На данном этапе, для каждой из задач необходимо рассмотреть факторы, которые могут оказать влияние на критерии выполняемости данной задачи.
А.3 Проверка документа о требованиях к системе (ДТС)
Руководство по контрольным перечням документа требований к системе для каждого типа свойств приводится в настоящем приложении в части, относящейся к данному свойству.
Эффективность оценки зависит от всестороннего описания требований.
Приложение В
(справочное)
Документ спецификации системы (ДСС)
В.1 Введение
Настоящее приложение описывает метод разработки и проверки ДСС, включая контрольные перечни для каждого свойства системы.
В.2 Разработка документа спецификации системы (ДСС)
В.2.1 Общие положения
Исходной документацией для разработки ДСС является ДТС, с выделением задач с присвоенной относительной значимостью.
На основании этого и после распределения задач на функциональной модели (см. 5.1.1 и МЭК 61069-1, рисунок 4), появится возможность реализации системы, формируемой для выполнения системных требований.
В течение этапа оценки, система, предусмотренная ДСС, будет сравниваться с детальной формулировкой целевого назначения (миссии), указанной в ДТС.
Для выполнения эффективного анализа соответствия системным требованиям, очень важно, чтобы спецификация предполагаемой системы идентифицировала различные ключевые моменты. Такие моменты детально рассмотрены в В.2.2-В.2.7.
Результатом действий, указанных в В.2.2-В.2.7 будет разработка ДСС.
В.2.2 Обзор системы
Целью обзора является установление взаимоотношения реализации системы с целевым назначением (миссией) системы, как это отражено в ДТС.
Точно так же, как целевое назначение (миссия) может быть разделено на задачи в иерархическом порядке, система, подлежащая оценке, может быть разделена в иерархическом порядке на модули и элементы.
Установлено, что результатом разделения обычно являются схемы общего вида и дополнительные описания.
Они должны содержать, как минимум, следующую информацию:
- все модули, взаимодействующие с процессом, оператором, внешними системами и т.д.;
- коммуникационные модули;
- модули обработки приложений;
- взаимодействие между модулями, и
- относительные и абсолютные расстояния и местоположения модулей.
Для разделения важно знать, что большая часть современных ОСУ основывается на гибридной архитектуре, состоящей из комбинации отдельного измерительного и управляющего оборудования, и программного обеспечения, связанного с ним.
В.2.3 Определение границ системы
У системы есть четкие границы с процессом, инженерными сетями, обеспечивающими электропитание, окружающей средой, в которой расположена система, другими подсоединенными внешними системами и пользователями системы (операторами, обслуживающим персоналом). Граница системы должна быть тщательно определена посредством идентификации того, "что входит и что не входит" в состав системы, оценка которой должна быть проведена, с учетом, как минимум, следующих аспектов:
- граница с технологическим процессом может быть расположена таким образом, чтобы включить или исключить в/из нее блоки формирования сигналов, гальванические разъединители, кроссовые шкафы, кабеля, устройства ввода/вывода, такие как датчики и исполнительные механизмы и т.д.;
- граница с инженерными сетями определяется с учетом оборудования различных производителей, например источников бесперебойного питания, аккумуляторов, фильтров, регуляторов и т.д., которые могут поставить систему полностью или ее часть, включая датчики и исполнительные механизмы.
- граница с внешним оборудованием должна учитывать требуемые интерфейсы, функции связи, кабеля и т.д.
- граница с окружающей средой должна учитывать физическое распределение модулей и элементов, которые могут быть расположены в помещении с кондиционированием воздуха, в офисной среде, в производственной зоне или непосредственно на самом технологическом оборудовании и т.д.
- граница с человеко-машинным интерфейсом исключительно важна при оценке надежности системы, поскольку оперативный и обслуживающий персонал играют очень важную роль в выполнении установленного целевого назначения (миссии). Взаимодействие пользователей и системы осуществляется на нескольких уровнях иерархии управления и в значительной степени зависит от рассматриваемого режима работы и включает в себя все аппаратные и программные модули системы.
- хотя это и не очевидно, задачи сами по себе являются внешними по отношению к границе системы. Влияние предписывающих, изменяющих и добавляющих задач является очень важным аспектом в оценке свойств "гибкости и расширяемости" системы.
Если целью оценки является "получение сравнительной оценки различных систем", то довольно затруднительно определить одним и тем же способом границы каждой из систем, подлежащих сравнению, в особенности, если данные системы имеют различные функциональные области применения. В этом случае, оборудование, которое не входит в состав рассматриваемой системы, должно быть добавлено, чтобы появилась возможность провести сравнение. Факт добавления оборудования должен быть специально отмечен.
В.2.4 Спецификация системы
Целью разработки спецификации системы является предоставление точной цифровой, эксплуатационной и реляционной информации для предполагаемой реализации системы.
Как правило, она должна содержать:
- полный перечень всех модулей и элементов;
- спецификации продукции для каждого типа модулей и элементов с предоставлением общих, функциональных и технических спецификаций, включая технические характеристики окружающей среды;
- детальные принципиальные схемы с указанием и дальнейшей детализацией межсоединений и внутренних связей между отдельными модулями и элементами, включая магистрали резервирования в соответствующих случаях.
В.2.5 Описание работы системы
Целью описания работы системы является предоставление в систематическом виде способа выполнения отдельных задач предложенной системой.
Систематическое описание должно основываться на позадачном представлении и, как правило, содержать:
- перечень функций, предложенных к исполнению каждой задачи;
- замечания к каждой задаче, с указанием способа, с помощью которого предложенные модули и элементы будут обеспечивать данные функции.
Уровень детализации реализации задач и степень подразделения на модули или элементы следует выбирать сообразно необходимости и достаточности для демонстрации соответствия требованиям.
В.2.6 Заключение об обосновании практической реализации системы
При проведении оценки определение реализации системы следует проводить на основе заключений с логическими обоснованиями.
Такие заключения следует составлять для каждого из свойств (см. подраздел 5.2), соответствующих целевому назначению (миссии) системы, предоставляя в них дополнительную информацию, относящуюся к обоснованию практической реализации системы с достижением требуемых свойств системы. Она может включать в себя:
- критерии выбора альтернативных решений;
- обосновывающие данные (например, опыт работы периферии), расчеты и т.д.;
- сопутствующие отчеты об испытаниях.
В.2.7 Заключение о соответствии системным требованиям
По каждому из требований к системе, по которому оцениваемая система не соответствует, должно быть сделано четкое заключение с указанием причин и степени несоответствия.
Приложение С
(справочное)
Примеры документации сопоставления
С.1 Введение
В настоящем приложении приведены примеры документации сопоставления.
С.2 Пример документации управления топкой
С.2.1 Схема задачи
На рисунке 1 показано управление "ведущий - ведомый" для документации по управлению топкой.
|
Рисунок С.1 - Блок управления
СВ1 и СВ2 являются ПИД параметрами для блока управления
С.2.2 Постановка задачи
С.2.2.1 Алгоритм управления и/или расчета
Управление температурой |
: |
OV1 |
= |
функция [MV1, SP1 и СВ1 (ПИД параметры) |
Управление топливным газом |
: |
OV1 |
= |
функция [функция (MV1, MV3), SP2/OV1 и СВ2 (ПИД параметры)] |
Расход топливного газа |
: |
OV3 |
= |
функция{М2, М3} = константа [кв. корень из {MV2 * MV3}] |
Аварийная температура |
: |
OV4 |
= |
1 М1 < k градус Цельсия |
С.2.2.2 Значимость для целевого назначения (миссии)
Задача крайне важна для целевого назначения (миссии) системы.
С.2.2.3 Граница системы
Система должна включать все модули и элементы, выполняющие описанную задачу. Управляющие элементы (регулирующие клапаны) и датчики находятся вне зоны рассмотрения.
С.2.3 Характеристики ввода
Измеряемое значение 1 |
: |
Измеряемая величина |
: |
температура |
|
: |
Тип |
: |
термопара |
|
: |
Характеристика |
: |
J железо/олово-никель |
|
: |
Стандарт |
: |
МЭК 60584-1 |
|
: |
Единица измерения |
: |
градус Цельсия |
Измеряемое значение 2 |
|
Измеряемая величина |
|
разница давления |
|
: |
Тип |
: |
4-20 мА, искробезопасный |
|
: |
Питание |
: |
от системы |
|
: |
Характеристика |
: |
линейная с дифференциальным давлением |
|
: |
Стандарт |
: |
|
|
: |
Единица измерения |
: |
|
Измеряемое значение 3 |
: |
Измеряемая величина |
: |
давление |
|
: |
Тип |
: |
4-20 мА, искробезопасный |
|
: |
Питание |
: |
от системы |
|
: |
Характеристика |
: |
линейная с давлением |
|
: |
Стандарт |
: |
|
|
: |
Единица измерения |
: |
бар |
Установленное значение 1 |
: |
Индикация |
: |
как для MV1 |
|
: |
Единица измерения |
: |
градус Цельсия |
Установленное значение 2 |
: |
Индикация |
: |
как для OV3 |
|
: |
Единица измерения |
: |
т в ч |
С.2.4 Характеристики вывода
Значение вывода 1 |
: |
Назначение |
: |
внутрисистемное установленное значение SP2 |
|
: |
Тип |
: |
также для OV3 |
|
: |
Питание |
: |
|
|
: |
Характеристика |
: |
также для OV3 |
|
: |
Действие |
: |
изменение на противоположное |
|
: |
Энергоснабжение |
: |
|
Значение вывода 2 |
: |
Назначение |
: |
вывод на позиционер клапана |
|
: |
Тип |
: |
4-20 мА, искробезопасный |
|
: |
Питание |
: |
от системы |
|
: |
Характеристика |
: |
линейная |
|
: |
Действие |
: |
прямое, клапан закрыт при 4 мА |
|
: |
Единица измерения |
: |
линейная, 0-100% |
Значение вывода 3 |
: |
Назначение |
: |
ввод на СВ2, управление топливным газом |
|
: |
Тип |
: |
внутренний блок расчета |
|
: |
Питание |
: |
от системы |
|
: |
Характеристика |
: |
линейная |
|
: |
Действие |
: |
|
|
: |
Единица измерения |
: |
линейная, тонн в час |
Значение вывода 4 |
: |
Назначение |
: |
вывод на щит сигнализации |
|
: |
Тип |
: |
напряжение свободных контактов |
|
: |
Питание |
: |
от внешнего источника, 24 В постоянного тока |
|
: |
Характеристика |
: |
два положения: открыто/закрыто |
|
: |
Действие |
: |
контакт нормально закрыт |
|
|
Единица измерения |
: |
|
С.2.5 Эксплуатационные функции
Оперативный персонал должен иметь возможность управлять:
- |
установленными значениями |
: |
величины установленных значений SP1 и SP2; |
- |
выводами |
: |
значения выводов OV1 и OV2; |
- |
режимами |
: |
ручной: значение вывода OV2, ручной: ведомый СВ2, автоматический: ведомый СВ2, ручной: ведущий СВ1, автоматический: ведущий СВ1 |
С.2.6 Функции контроля
Отображение |
|
: |
MV1, MV2, MV3, SP1, SP2, OV(1...N) |
Записи |
(короткие) |
: |
как для отображения |
|
(средние) |
: |
MV1, MV2, MV3 и OV3 |
|
(длинные) |
: |
MV1, ОV3 |
Аварийная сигнализация |
|
: |
OV4 = MV1 |
С.2.7 Конфигурация
Оперативному персоналу разрешено работать со следующим:
- |
настройки управления |
: |
инженер КИП и А |
- |
параметры настройки |
: |
инженер КИП и А |
- |
ввод в эксплуатацию |
: |
инженер КИП и А/техник |
С.2.8 Гибкость
С.2.8.1 Общие положения
Должна предусматриваться возможность модернизации системы в течение следующих пяти лет по следующим характеристикам.
С.2.8.2 Улучшение функции
Усовершенствование OV3 (Функция {MV2, MV3}) в:
функция {MV2..5}) = постоянная [квадратный корень {MV2* MV3* MV4/(MV5 + переменная)}].
С.2.8.3 Добавление блока управления
Добавление блока управления для управления количеством мазута с установленным значением SPy и выводом Ovx, аналогичного блоку управления, приведенному в С.2.2 выше для OV2 и с тем же самым усовершенствованием, как это определено в С.2.8.2.
С.2.8.4 Добавление функции
Дополнение логической функции со следующими возможностями:
- выводы мазута и топливного газа на ручное управление;
- выводы мазута и топливного газа на автоматическое управление;
- мазут на автоматическое управление и топливный газ на систему ведущий-ведомый из температурного контроля;
- мазут и топливный газ на систему ведущий-ведомый, где есть возможность установить соотношение между мазутом и топливным газом.
С.2.8.5 Добавление внешнего подсоединения
Подсоединение системы к системе оптимизации и управления информацией, включая сбор данных и управление параметрами управления.
С.2.9 Таблицы сопоставления функциональности
_________________
В таблицах С.1, С.2 и С.З приведены примеры для трех аспектов анализа ДТС: полнота, конфигурируемость и гибкость.
С.2.9.1 Полнота
Таблица С.1 - Анализ полноты ДТС
Задача (ДТС) |
Полнота (ДСС) |
Анализ | |||||||
Тип |
Важ- |
Описание/ характеристика |
Поддержка |
Соответствие? |
Дальнейшая оценка? | ||||
|
|
|
Функция |
Модуль |
Элемент |
Да |
Нет |
Да |
Нет |
|
|
|
|
|
|
|
Принято? |
|
|
Ведущий - ведомый: |
Крити- |
Интерфейс с процессом |
Монитор ввода/ |
Модуль ввода/ |
|
|
|
|
|
|
|
Измерения: |
Таблица соот- |
Модуль ввода/ |
Интер- |
|
|
|
|
|
|
MV2: |
|
|
Интер- |
|
|
|
|
|
|
MV3 ....n |
|
|
|
|
|
|
|
|
|
Выводы |
|
|
Карта вывода искро- |
|
|
|
|
|
|
Данные обработки |
Управ- |
Модуль обра- |
CPU-С |
|
|
|
|
|
|
Вычисление |
|
|
CPU-СВ |
|
|
|
|
|
|
Управление |
|
|
CPU-СВ |
|
|
|
|
|
|
Тренды |
|
|
PS-РМ |
|
|
|
|
|
|
Средства комму- |
|
|
Fbus |
|
|
|
|
|
|
Человеко- |
OPS-DRV |
OPS |
CPU-ops |
|
|
|
|
|
|
Отображение: |
|
|
|
|
|
|
|
|
|
Расчеты: |
|
|
|
|
|
|
|
|
|
Выводы: |
|
|
|
|
|
|
|
|
|
Параметры, константы и настройки: |
|
|
|
|
|
|
|
|
|
Тренды: |
|
|
Mem-Ex |
|
|
|
|
|
|
Отчеты: |
|
|
Mem-Ex |
|
|
|
|
|
|
Графика: |
|
|
GRD-Ex |
|
|
|
|
|
|
Настройка: |
|
|
|
|
|
|
|
|
|
Средства конфигури- |
|
|
GRD-Ex |
|
|
|
|
|
|
Интерфейс с внешними системами |
|
|
Особый |
|
|
|
|
|
С.2.9.2 Конфигурируемость
Таблица С.2 - Анализ конфигурируемости ДТС
Задача (ДТС) |
Конфигурируемость |
Анализ | |||||||
Тип |
Важ- |
Описание/ характеристика |
Требования конфи- |
Поддерживается |
Соответ- |
Дальнейшая оценка? | |||
|
|
|
|
Метод |
Состояние системы |
Да |
Нет |
Да |
Нет |
|
|
|
|
|
|
|
При- |
|
|
Ведущий - ведомый: |
Крити- |
Интерфейс с процессом |
|
|
|
|
|
|
|
|
|
Измерения: |
Инженер КИП/техник |
При- |
Ручное управ- |
|
|
|
|
|
|
MV2: |
|
|
|
|
|
|
|
|
|
MV3 ....n |
|
|
|
|
|
|
|
|
|
Выводы |
Инженер КИП/техник |
|
Местное управ- |
|
|
|
|
|
|
Обработка данных |
|
|
|
|
|
|
|
|
|
Вычисление |
Инженер КИП и А |
Управ- |
Ручное управ- |
|
|
|
|
|
|
Управление |
Инженер КИП и А |
Управ- |
Ручное управ- |
|
|
|
|
|
|
Тренды |
Инженер КИП и А |
Управ- |
Работа в опера- |
|
|
|
|
|
|
Средства комму- |
Инженер КИП и А |
|
Система в автоном- |
|
|
|
|
|
|
Человеко- |
Инженер КИП и А |
Управ- |
Система в автоном- |
|
|
|
|
|
|
Отображение: |
|
|
|
|
|
|
|
|
|
Расчеты: |
|
|
|
|
|
|
|
|
|
Выводы: |
|
|
|
|
|
|
|
|
|
Параметры, константы и настройки: |
|
|
|
|
|
|
|
|
|
Тренды: |
|
Особые карты |
|
|
|
|
|
|
|
Отчеты: |
|
|
|
|
|
|
|
|
|
Графика: |
|
Управ- |
|
|
|
|
|
|
|
Настройка: |
|
|
|
|
|
|
|
|
|
Средства конфигури- |
|
Управ- |
|
|
|
|
|
|
|
Интерфейс с внешними системами |
|
|
Система в автоном- |
|
|
|
|
|
С.2.9.3 Гибкость
Таблица С.3 - Анализ гибкости ДТС
Задача (ДТС) |
Гибкость |
Анализ | |||||||
Тип |
Важ- |
Описание/ характеристика |
Требо- |
Поддержка |
Сравне- |
Дальнейшая оценка? | |||
|
|
|
|
Метод |
Сос- |
Да |
Нет |
Да |
Нет |
|
|
|
|
|
|
|
При- |
|
|
Ведущий - ведомый: |
Крити- |
Интерфейс с процессом |
|
|
|
|
|
|
|
|
|
Измерения: |
Дополни- |
Уста- |
Ручное управ- |
|
|
|
|
|
|
MV2: |
|
|
|
|
|
|
|
|
|
MV3 ....n |
|
|
|
|
|
|
|
|
|
Выводы |
Дополни- |
|
Контур управ- |
|
|
|
|
|
|
Обработка данных |
Функция добав- |
Конфи- |
Ручное управ- |
|
|
|
|
|
|
Управление |
|
Управ- |
|
|
|
|
|
|
|
Тренды |
Изме- |
С помощью меню |
Опера- |
|
|
|
|
|
|
Связь |
|
|
|
|
|
|
|
|
|
Человеко- |
|
|
|
|
|
|
|
|
|
Индикация в |
Добав- |
С помощью меню до 256 точек |
Онлайн |
|
|
|
|
|
|
Расчет в |
Добав- |
Макс. 64 расчета |
Онлайн |
|
|
|
|
|
|
Вывод в |
|
|
|
|
|
|
|
|
|
Параметры, константы и настройки |
|
|
|
|
|
|
|
|
|
Тренды: |
|
|
|
|
|
|
|
|
|
Отчеты: |
|
|
|
|
|
|
|
|
|
Графика: |
|
|
|
|
|
|
|
|
|
Настройка: |
|
|
|
|
|
|
|
|
|
Средства конфигурации |
|
|
|
|
|
|
|
|
|
Интерфейс с внешними системами |
Допол- |
Особое |
Автоном- |
|
|
|
|
|
С.2.9.4 Ссылочный документ
МЭК 60584-1-2013, Термопары. Часть 1. Спецификации и допуски ЭМП.
С.3 Пример документации задачи простого контура управления
С.3.1 Введение
В разделе С.3 показан пример документации задачи простого контура управления.
С.3.2 Схема задачи
На рисунке С.2 показан пример схемы задачи.
|
Рисунок С.2 - Схема задачи
С.3.3 Потоки информации
Действие управления технологическим процессом: |
измеренное значение |
|
Клавиатура, управляющая действием процесса: |
станция оператора |
|
Индикация измерений процесса: |
измеренное значение |
|
Обратная связи* обработанного значения: |
вывод |
|
___________________
* Текст документа соответствует оригиналу. - Примечание изготовителя базы данных.
С.3.4 Таблицы производительности
Таблица С.4 содержит пример таблицы производительности для потока информации
Таблица С.4 - Производительность для потока информации
Поток информации |
Точность, % |
Время реакции, с |
Период выборки, с |
Измеренное значение - вывод |
±0,5 |
0,25 |
0,05 |
Станция оператора - вывод |
±0,5 |
0,50 |
0,20 |
Измеренное значение - станция оператора |
±2,0 |
1,00 |
0,01 |
Вывод - станция оператора |
±2,0 |
1,00 |
0,01 |
В таблице С.5 показан пример таблицы производительности для передачи информации.
Таблица С.5 - Передача информации
Задача |
Передача информации |
Элемент |
Точность, % |
Время реакции, с |
Время выборки, с |
Управление с ПИД-алгоритмом |
Измеренное значение |
Модуль ввода |
0,2 |
0,1 |
0,01 |
|
Вывод |
ПИД-модуль |
0,1 |
Н/П |
0,01 |
|
|
Модуль вывода |
0,2 |
0,1 |
0,01 |
|
Станция оператора |
Клавиатура |
Н/П |
1,0 |
Н/П |
|
Вывод |
Коммуникационный модуль |
Н/П |
0,2 |
0,001 |
|
|
ПИД-модуль |
0,1 |
Н/П |
0,01 |
|
|
Модуль вывода |
0,2 |
0,1 |
0,01 |
|
Измеренное значение |
Модуль ввода |
0,2 |
0,1 |
0,01 |
|
Станция оператора |
Коммуникационный модуль |
Н/П |
0,2 |
0,001 |
|
|
Дисплей |
1,0 |
1,0 |
0,01 |
|
Вывод |
Модуль вывода |
0,2 |
0,1 |
0,01 |
|
Станция оператора |
Коммуникационный модуль |
Н/П |
0,2 |
0,001 |
|
|
Дисплей |
1,0 |
1,0 |
0,01 |
С.3.5 Таблицы сопоставления производительности
В таблице С.6 показан пример таблицы сопоставления производительности
Таблица С.6 - Сопоставление производительности
Задача (ДТС) |
Данные производительности (ДСС) |
Анализ | ||||||||
Тип |
Значи- |
Передача инфор- |
Поддержи- |
Данные производительности |
Соответствие? |
Дальнейшая оценка? | ||||
|
|
|
|
Точ- |
Время реакции |
Расход |
Да |
Нет |
Да |
Нет |
|
|
|
|
|
|
|
|
Принято? |
|
|
|
|
|
|
|
|
|
|
|
|
|
С.4 Пример документации сопоставления (из ДТС задачи управления ведущий - ведомый)
С.4.1 Введение
В настоящем разделе дан пример описаний, которые соответствуют требованиям надежности задачи управления ведущий - ведомый в ДТС.
С.4.2 Схема задачи
На рисунке С.3 показана типовая схема задачи в виде функционального блока управления.
|
Рисунок С.3 - Схема задачи
С.4.3 Граничные состояния
Возможные состояния вводов:
- измеренное значение 1: > высокое, нормальное, < низкое;
- измеренное значение 2: > высокое, нормальное, < низкое;
- установленное значение: > высокое, нормальное, < низкое.
Возможные состояния выводов:
- вывод: полностью открытый, зафиксированный, плавающий, полностью закрытый.
Таблица С.7 содержит пример краткого описания граничных состояний задачи.
Таблица С.7 - Состояния отказа ввода и вывода задачи
Задача |
Режим |
Событие отказа | |||
|
|
Ожидаемая частота |
Требуемые меры |
Время на восстановление | |
Ведущий - ведомый |
Ввод |
Измерение 1 |
| ||
|
|
>высокое |
1 в год |
Отчет/зафиксировать вывод |
* |
|
|
Нормальное |
Н/П |
Н/П |
- |
|
|
<низкое |
1 год |
Отчет/зафиксировать вывод |
* |
|
|
Измерение 1 |
| ||
|
|
>высокое |
1 в год |
Отчет/фиксация последнего значения |
* |
|
|
Нормальное |
Н/П |
Н/П |
- |
|
|
<низкое |
1 год |
Отчет/вывод на повышение |
* |
|
|
Установленное значение |
| ||
|
|
>высокое |
1 в год |
Отчет/фиксация последнего значения
|
2 ч |
|
|
Нормальное |
Н/П |
Н/П |
- |
|
|
<низкое |
1 год |
Отчет/вывод на повышение
|
2 ч |
|
Вывод |
Вывод |
| ||
|
|
>высокое |
1 в год |
Отчет/фиксация последнего значения
|
2 ч |
|
|
Нормальное |
Н/П |
Н/П |
- |
|
|
<низкое |
1 год |
Отчет/вывод на повышение
|
2 ч |
Примечания |
С.5 Пример документации сопоставления (из ДСС задачи управления ведущий - ведомый)
В настоящем разделе дан пример описания, которое содержит спецификации задачи управления ведущий - ведомый, связанной с надежностью в ДТС.
В таблице С.8 приведен пример сопоставления надежности для задачи управления "ведущий - ведомый".
Таблица С.8 - Надежность
Задача |
Поддерживается |
Свойства надежности | |||||
|
Функцией |
Модулем |
Элемен- |
Доступность |
Достоверность | ||
|
|
|
|
Безот- |
Ремотопри- |
Целост- |
Защищен- |
Ведущий - ведомый |
Монитор ввода- |
Модуль ввода- |
l-card |
|
|
|
|
|
|
|
Barrier |
|
|
|
|
|
|
|
l-card |
|
|
|
|
|
|
|
Barrier |
|
|
|
|
|
Управление |
Модуль процесса 1 или |
CPU-PM |
|
|
|
|
|
|
|
FbusC |
|
|
|
|
|
|
|
DIA |
|
|
|
|
|
|
|
PS-PM |
|
|
|
|
|
|
|
SysBusC |
|
|
|
|
|
Управление |
Модуль процесса 2 |
CPU-PM |
|
|
|
|
|
|
|
FbusC |
|
|
|
|
|
|
|
DIA |
|
|
|
|
|
|
|
PS-PM |
|
|
|
|
|
|
|
SysBusC |
|
|
|
|
|
Человеко- |
Станция оператора 1 или |
CPU-OPS |
|
|
|
|
|
|
|
Mem-card |
|
|
|
|
|
|
|
GrD-card |
|
|
|
|
|
|
|
SysBusC |
|
|
|
|
|
|
Станция оператора 2 |
CPU-OPS |
|
|
|
|
|
|
|
Mem-card |
|
|
|
|
|
|
|
GrD-card |
|
|
|
|
|
|
|
SysBusC |
|
|
|
|
|
Приложение ДА
(справочное)
Сведения о соответствии ссылочных международных стандартов национальным стандартам
Таблица ДА.1
Обозначение ссылочного международного стандарта |
Степень соответствия |
Обозначение и наименование соответствующего национального стандарта |
IEC 61069-1 |
IDT |
ГОСТ Р МЭК 61069-1-2017 "Измерение, управление и автоматизация промышленного процесса. Определение свойств системы с целью ее оценки. Часть 1. Терминология и общие концепции" |
Примечание - В настоящей таблице использовано следующее условное обозначение степени соответствия стандарта: |
Библиография
[1] |
IEC/TS 62603-1:2014, Industrial process control systems - Guideline for evaluating process control systems - Part 1: Specifications |
[2] |
IEC 60584-1:2013, Thermocouples - Part 1: EMF specifications and tolerances |
[3] |
ISO 9001:2015, Quality management systems - Requirements |
[4] |
IEC 61069-4, Industrial-process measurement, control and automation - Evaluation of system properties for the purpose of system assessment - Part 4: Assessment of system performance |
[5] |
IEC 61709, Electric components - Reliability - Reference conditions for failure rates and stress models for conversion |
УДК 658.5.012.7:006.354 |
OКC 25.040.40 |
Ключевые слова: промышленный процесс, система измерения и управления, определение свойств системы, методология оценки, оценка системы, анализ цели оценки, программа оценки, свойства системы, влияющие факторы |