ГОСТ Р МЭК 61069-3-2017. Национальный стандарт Российской Федерации. Измерение, управление и автоматизация промышленного процесса. Определение свойств системы с целью ее оценки. Часть 3. Оценка функциональности системы

(утв. и введен в действие Приказом Росстандарта от 07.11.2017 № 1651-ст)

ИСТОРИЯ ИЗМЕНЕНИЙ НОРМАТИВНО-ТЕХНИЧЕСКИХ АКТОВ

flowchart LR
  n0["ГОСТ Р МЭК 61069-3-2012"]:::rst
  click n0 "https://bukva.ai/docs/gost-r-mek-61069-3-2012" "ГОСТ Р МЭК 61069-3-2012. Национальный стандарт Российской Федерации. Измерение и управление промышленным процессом. Определение свойств системы с целью ее оценки. Часть 3. Оценка.."
  n1["ГОСТ Р МЭК 61069-3-2017"]:::doc
  click n1 "https://bukva.ai/docs/gost-r-mek-61069-3-2017" "ГОСТ Р МЭК 61069-3-2017. Национальный стандарт Российской Федерации. Измерение, управление и автоматизация промышленного процесса. Определение свойств системы с целью ее оценки... "
  n0 --> n1
classDef rst fill:#FFEBEB,stroke:#8B0000,color:#000;
classDef doc fill:#EBFFEB,stroke:#006400,color:#000;
classDef notEnt fill:#FFFFEB,stroke:#FF8C00,color:#000;

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

ИЗМЕРЕНИЕ, УПРАВЛЕНИЕ И АВТОМАТИЗАЦИЯ ПРОМЫШЛЕННОГО ПРОЦЕССА. ОПРЕДЕЛЕНИЕ СВОЙСТВ СИСТЕМЫ С ЦЕЛЬЮ ЕЕ ОЦЕНКИ

ЧАСТЬ 3

ОЦЕНКА ФУНКЦИОНАЛЬНОСТИ СИСТЕМЫ

Industrial-process measurement, control and automation. Evaluation of system properties for the purpose of system assessment. Part 3. Assessment of system functionality

(IEC 61069-3:2016, IDT)

ГОСТ Р МЭК 61069-3-2017

Предисловие

1 ПОДГОТОВЛЕН Негосударственным образовательным частным учреждением дополнительного профессионального образования «Новая Инженерная Школа» (НОЧУ «НИШ») на основе собственного перевода на русский язык англоязычной версии указанного в пункте 4 стандарта, который выполнен Российской комиссией экспертов МЭК/ТК 65, и Федеральным государственным унитарным предприятием «Всероссийский научно-исследовательский институт стандартизации» (ВНИИНМАШ)

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 306 «Измерения и управление в промышленных процессах»

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

4 Настоящий стандарт идентичен международному стандарту МЭК 61069-3:2016 «Измерение, управление и автоматизация промышленного процесса. Определение свойств системы с целью ее оценки. Часть 3. Оценка функциональности системы» (IEC 61069-3:2016 «Industrial-process measurement, control and automation — Evaluation of system properties for the purpose of system assessment — Part 3: Assessment of system functionality», IDT).

Международный стандарт разработан Техническим комитетом МЭК ТК 65 «Измерения и управление в промышленных процессах».

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

5 ВЗАМЕН ГОСТ Р МЭК 61069-3-2012

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

Введение

В МЭК 61069 рассматривается метод, который следует использовать для оценки системных свойств основной системы управления (ОСУ). МЭК 61069 состоит из следующих частей:

часть 1. Терминология и основные концепции;

часть 2. Методология оценки;

часть 3. Оценка функциональности системы;

часть 4. Оценка производительности системы;

часть 5. Оценка надежности системы;

часть 6. Оценка эксплуатабельности системы;

часть 7. Оценка безопасности системы;

часть 8. Оценка других свойств системы.

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

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

Так как на практике это требуется редко, для оценки системы более рациональным будет:

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

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

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

При подготовке к оценке может быть установлено, что определение границ системы является слишком узким. Например, для средства с двумя или более версиями совместного пользования системы управления, например сети, необходимо учитывать вопросы сосуществования и функциональной совместимости. В этом случае система, подлежащая оценке, не должна ограничиваться «новыми» ОСУ. Такая система должна включать в себя как «новые», так и «старые» системы. То есть, система должна изменять свои границы, чтобы включать в себя достаточный объем другой системы для решения требуемых от нее задач.

Структура настоящей части и ее взаимосвязь с другими частями МЭК 61069 показаны на рисунке 1.

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

• устанавливает детальный метод оценки функциональности основной системы управления (ОСУ) на основании общих концепций, данных в МЭК 61069-1, и методологии оценки, приведенной в МЭК 61069-2;
• устанавливает основную классификацию свойств функциональности;
• описывает факторы, влияющие на функциональность, и которые необходимо учитывать при оценке функциональности; и
• предоставляет руководство по выбору методов из набора вариантов (с нормативными ссылками) для определения функциональности.

2. Нормативные ссылки

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

IEC 61069-1 <1>, Industrial-process measurement, control and automation — Evaluation of system properties for the purpose of system assessment — Part 1: Terminology and basic concepts (Измерение, управление и автоматизация промышленного процесса. Определение свойств системы с целью ее оценки. Часть 1. Терминология и базовые концепции)

IEC 61069-2 <1>, Industrial process measurement, control and automation — Evaluation of system properties for the purpose of system assessment — Part 2: Assessment methodology (Измерение, управление и автоматизация промышленного процесса. Определение свойств системы с целью ее оценки. Часть 2. Методология оценки)

<1> Второе издание стандарта подлежит публикации одновременно с настоящим стандартом.

3. Термины, определения, обозначения и сокращения

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

В настоящем стандарте применены термины по МЭК 61069-1.

3.2. Обозначения и сокращения

В настоящем стандарте применены обозначения и сокращения по МЭК 61069-1.

4. Основы оценки, связанные с функциональностью

4.1. Свойства функциональности

4.1.1 Общие положения

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

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

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

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

Функциональные свойства должны классифицироваться в соответствии с рисунком 2.

Функциональность

                            ─────────┬────────
               ┌─────────────────────┼──────────────────────┐
<pre class="legal-pre">      ┌────────┴───────┐    ┌────────┴────────┐    ┌────────┴───────┐
      │     Полнота    │    │Конфигурируемость│    │    Гибкость    │
      └────────────────┘    └─────────────────┘    └────────────────┘</pre>

Рисунок 2 — Функциональность

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

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

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

4.1.2 Полнота

Полнота определяется:

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

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

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

Целевое назначение (миссия) системы = n задач;

Коэффициент полноты (КП) = выполняемые задачи/n задач.

4.1.3 Конфигурируемость

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

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

Рисунок 3 — Методы конфигурирования

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

Средства конфигурирования являются частью системы и рассматриваются как «функции поддержки», если они полностью описаны в документе спецификация системы (ДСС).

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

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

4.1.4 Гибкость

4.1.4.1 Общие положения

Гибкость системы зависит от способа адаптации системы.

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

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

4.1.4.2 Масштабирование

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

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

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

4.1.4.3 Изменяемость

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

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

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

4.1.4.4 Совершенствование

Система может быть спроектирована таким образом, чтобы имелась возможность совершенствовать определенные свойства системы.

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

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

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

Совершенствование может быть выражено в виде качественного описания, с добавлением некоторых количественных элементов.

4.2. Факторы, влияющие на функциональность

На функциональность системы могут оказывать воздействие влияющие факторы, приведенные в 5.3 МЭК 610069-1.

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

a) на полноту могут воздействовать:

• отсутствие влияющих факторов;

b) на конфигурируемость могут влиять:

1. лицензирование особой функциональности,

2. установка, например, всех модулей и элементов на месте;

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

5. Процедура оценки

5.1. Общие положения

Оценку следует проводить в соответствии с методологией, приведенной в разделе 5 МЭК 61069-2.

5.2. Определение цели оценки

Определение цели оценки следует проводить в соответствии с процедурами, приведенными в подразделе 5.2 МЭК 61069-2.

5.3. Проектирование и схема оценки

Проектирование и схему оценки следует выполнять в соответствии с процедурами, приведенными в подразделе 5.3 МЭК 61069-2.

Определение объема оценки следует проводить в соответствии с 5.3.1 МЭК 61069-2.

Сопоставление документированной информации следует проводить в соответствии с 5.3.3 МЭК 61069-2.

Заключения, сформулированные в соответствии с 5.3.3 МЭК 61069-2, должны содержать следующую информацию в дополнение к пунктам, перечисленным в 5.3.3 МЭК 61069-2:

• дополнительные пункты не были отмечены.

Документирование информации для сопоставления следует проводить в соответствии с 5.3.4 МЭК 61069-2.

Выбор элементов оценки следует проводить в соответствии с 5.3.5 МЭК 61069-2.

Спецификацию оценки следует разрабатывать в соответствии с 5.3.6 МЭК 61069-2.

Сравнение ДТС и ДСС следует проводить в соответствии с подразделом 5.3 МЭК 61069-2.

Примечание 1 — Контрольный перечень ДТС для функциональности системы приведен в приложении A.

Примечание 2 — Контрольный перечень ДСС для функциональности системы приведен в приложении B.

5.4. Планирование программы проведения оценки

Планирование программы проведения оценки следует выполнять в соответствии с процедурами, приведенными в подразделе 5.4 МЭК 61069-2.

Действия по оценке должны быть разработаны в соответствии с 5.4.2 МЭК 61069-2.

В итоговой программе проведения оценки следует определить пункты, перечисленные в 5.4.3 МЭК 61069-2.

5.5. Проведение оценки

Оценку следует проводить в соответствии с подразделом 5.5 МЭК 61069-2.

5.6. Отчет об оценке

Отчет об оценке следует оформлять в соответствии с подразделом 5.6 МЭК 61069-2.

Отчет должен содержать информацию, приведенную в подразделе 5.6 МЭК 61069-2. Дополнительно отчет по оценке должен включать в себя следующие пункты:

• информацию, указанную в разделе 6.

6. Методы определения свойств

6.1. Общие положения

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

Данные методы определения свойств сгруппированы согласно требованиям, установленным в разделе 6 МЭК 61069-2.

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

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

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

Функциональность, которая является неотъемлемой частью системы, но не была указана в ДТС, может не рассматриваться при проведении оценки, но подобные исключения должны быть зафиксированы в отчете.

Примечание — Пример перечня элементов оценки предоставлен в приложении C.

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

6.2.1 Полнота

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

В отчет следует включить следующую информацию:

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

6.2.2 Конфигурируемость

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

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

6.2.3 Гибкость

Гибкость определяется на основе аналитического анализа:

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

6.3. Эмпирические методы определения свойств

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

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

6.4. Дополнительные разделы методов определения свойств

Дополнительные разделы не были отмечены.

Приложение A (справочное)

КОНТРОЛЬНЫЙ ПЕРЕЧЕНЬ И/ИЛИ ПРИМЕР ДТС ДЛЯ ФУНКЦИОНАЛЬНОСТИ СИСТЕМЫ

В матрице таблицы A.1 приведено руководство по типу информации (задача за задачей и/или передача информации), которое должно быть приведено в ДТС с целью оценки производительности.

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

Таблица A.1

Контрольный перечень ДТС

B.1 Информация ДСС

ДСС необходимо проверять на соответствие свойств, указанных в ДТС, требованиям МЭК 61069-2, приложение B.

B.2 Контрольный перечень для функциональности системы

Особое внимание следует уделить проверке предоставления информации в отношении:

a) модулей и элементов, как аппаратных, так и программных, поддерживающих каждую функцию;

b) количественной и/или качественной информации о свойствах данных модулей и элементов, а также наличия модулей и элементов с альтернативными свойствами;

c) детальной информации о средствах конфигурации, их применении и ограничениях касательно функционирования системы;

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

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

2. расчета резервных мощностей, устройств памяти и т.д.,

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

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

C.1 Общие положения

Настоящее приложение содержит несколько примеров элементов оценки, имеющих отношение к настоящему стандарту, приведенных в МЭК ТС 62603-1.

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

C.2 Характеристики системы

C.2.1 Общие положения

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

C.2.2 Масштабируемость системы

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

C.2.3 Расширяемость системы

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

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

Для компонента, например ПЛК, расширяемость обозначает возможность добавления пригодных запасных частей к компонентам [например, свободная память или центральный процессор управления в ПЛК].

C.2.4 Интеграция подсистем

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

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

C.2.5 Автоматическое ведение документации

ОСУ автоматически формирует документацию после этапа конфигурации.

Документация может включать в себя:

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

C.2.6 Языки программирования для управления

C.2.6.1 Общие положения

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

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

Термин «ПЛК-система» обозначает компонуемую потребителем конфигурацию, состоящую из программируемого контроллера и связанной с ним периферии, необходимой для проектируемой автоматизированной системы. Она состоит из узлов, соединенных кабелями или разъемными соединителями для постоянной установки, кабелями и другими способами для переносной или транспортируемой периферии.

C.2.6.2 Языки программирования для программируемых контроллеров

МЭК 61131-3 устанавливает набор языков для программирования ПЛК и контроллеров. Стандартные языки программирования делятся на две категории:

a) графические языки:

1. лестничная структура (ЛС) — это символическое представление, схематично отображающее функции управления в форме принципиальных электрических схем,

2. диаграммы функциональных блоков (ДФБ) — данный язык позволяет отображать программные элементы (такие как ПИД и другие алгоритмы) в виде блоков, соединенных друг с другом в виде визуального представления подобного логической схеме;

b) текстовые языки:

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

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

C.2.6.3 Программное средство: последовательная функциональная схема (ПФС)

В дополнение к языкам программирования, установленным в МЭК 61131-3, ПФС позволяет осуществлять графическое представление и структурирование программного обеспечения управления. ПФС — это способ графического представления сложных программ управления в виде последовательности альтернативных шагов и переходов.

C.2.6.4 Программное средство: непрерывная функциональная схема (НФС)

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

НФС может рассматриваться как особая форма ДФБ. Основное различие между НФС и ДФБ состоит в том, что она также отображает ресурсы и распределение задач. Каждый функциональный блок отображает наименование задачи, которая контролирует его выполнение.

НФС, в основном, применяется для отображения структуры верхнего уровня ресурсов и программ.

C.2.6.5 Определение пользовательского функционального блока

МЭК 61131-3 устанавливает набор стандартных функциональных блоков, которые приняты для программируемых контроллеров. Функциональный блок — это набор элементов, состоящий из:

a) определения структуры данных, разделенной на ввод, вывод и внутренние переменные; и

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

Примерами стандартных функциональных блоков являются:

• триггер;
• определение фронта;
• счетчик;
• таймер.

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

C.2.6.6 Пакетное программное средство

ОСУ может поддерживать программную среду пакетного управления, установленного в МЭК 61512.

C.2.6.7 Многозадачное рабочее программное обеспечение для контроллера

Многозадачное рабочее программное обеспечение — это метод управления ресурсами контроллера ЦПУ для использования общих ресурсов обработки при решении множественных задач. Многозадачное средство позволяет программисту применять способность контроллера к параллельному программированию. Термин «параллельное программирование» относится к методу программирования, при котором в состоянии исполнения одновременно находится более одной задачи.

C.2.6.8 Усовершенствованная автоматическая система управления технологическим процессом (УАСУ ТП)

УАСУ ТП в упрощенном виде может быть определена, как средство управления технологическим процессом помимо простых контуров ПИД управления. УАСУ ТП — это программные средства, реализуемые как дополнительные пакеты, которые могут быть либо подсоединены, либо установлены на ОСУ. УАСУ ТП позволяет улучшить контроль и оптимизировать технологический процесс, и обычно применяется со сложными функциями управления, такими как экспертные системы, управление со скользящим режимом, управление по нескольким переменным и т.д.

C.2.7 Локализация ОСУ

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

• программирование;
• ведение документации;
• человеко-машинный интерфейс (ЧМИ).

Необходимо определить требуемые языки и функции.

C.3 Свойства функциональности

C.3.1 Спецификации ввода/вывода

Рассматриваемыми типами ввода/вывода являются: стандартный аналоговый ввод/вывод (например, 4 — 20 мА, 0 — 10 В и т.д.), цифровой ввод/вывод, счетчики (например, высокоскоростные счетчики), импульсные выводы, ввод/вывод протокола взаимодействия с дистанционным датчиком с шинной адресацией (HART) и промышленная шина. Для каждого типа ввода/вывода потребитель должен установить разрешающую способность, точность и повторяемость.

C.3.2 Стандартный ввод/вывод

C.3.2.1 Цифровой ввод

Спецификация цифровых вводов может включать в себя:

• номинальное напряжение (например, 24 В постоянного тока) и ток (например, 10 мА);
• задержку ввода (фиксированная или переменная);
• локальное состояние отображения вводов;
• электрическую изоляцию между вводами, а также между вводами и материнской платой;
• уровень изоляции (например, 1 кВ постоянного тока).

C.3.2.2 Цифровой вывод

Спецификация цифрового вывода может включать в себя:

• тип вывода: статический или релейный;
• подсоединенную нагрузку, например, соленоидные клапаны, контакторы, индикаторы и т.д.;
• номинальное напряжение вывода (например, 24 В постоянного тока);
• номинальный ток вывода (постоянный или кратковременный);
• локальное отображение выводов (например, СИД);
• электрическую изоляцию между вводами и между вводами и материнской платой;
• уровень изоляции (например, 1 кВ постоянного тока).

C.3.2.3 Аналоговый ввод

Спецификация аналогового ввода может включать в себя:

• тип вводов, например, термопара, терморезистор (2-3-4 жильный), 4 — 20 мА;
• защиту от обратной полярности;
• электрическую изоляцию между вводами и между вводами и материнской платой;
• уровень изоляции (например, 500 В постоянного тока).

C.3.2.4 Аналоговый вывод

Спецификация аналогового вывода может включать в себя:

• тип вывода, например, 4 — 20 мА, +/- 10 В, 0 — 5 В и т.д.;
• разрешающую способность (или число битов преобразования);
• электрическую изоляцию между выводами и между выводами и материнской платой;
• уровень изоляции (например, 500 В постоянного тока);
• отдельную защиту вывода с предохранителем.

C.3.2.5 Счетчики

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

C.3.2.6 Импульсные выводы

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

C.3.3 Ввод/вывод из/на интеллектуальные устройства

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

C.3.4 Подсоединение промышленной шины к удаленному вводу/выводу

Потребитель устанавливает возможность использования подсоединения промышленной шины для подключения удаленного ввода/вывода и контроллеров. Промышленная шина может быть промышленной шиной по МЭК 61158 или запатентованной промышленной шиной.

C.3.5 Проверка ввода

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

C.3.6 Специальные вводы

Необходимо установить особые требования к вводам, которые отличаются от обычных.

C.3.7 Программные требования

C.3.7.1 Требования к системной базе данных

Системная база данных предоставляет собой информацию, которая необходима для различных системных транзакций (функций) для выполнения своих задач. Данные вводы поступают от устройств нижнего уровня (датчиков, преобразователей, переключателей и т.д.) через интерфейсы сбора данных контроллера, от систем оперативного управления [программируемый контроллер (ПК), ПЛК, распределенная система управления (РСУ)] через связи внешних контроллеров, и от других контроллеров через соединения между контроллерами. Данные выводы направляются на устройства управления и индикации нижнего уровня, системы оперативного управления и другие контроллеры.

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

C.3.7.2 Физическое размещение базы данных (реализация)

Системная база данных может иметь два возможных физических размещения:

• распределенная база данных: данные распределяются среди множественных физических местоположений. Вся база данных контролируется централизованной системой управления базой данных (ЦСУБД), которая выступает в качестве координатора всех файлов данных;
• центральная база данных: все данные хранятся в центральной базе данных, то есть, все записи вносятся в отдельную машину и могут быть доступны посредством системы управления базы данных (ЦСУБД).

C.3.7.3 Совместимость с внешней базой данных

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

C.3.7.4 Тип программного обеспечения

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

C.3.8 Управление тревожной сигнализацией

C.3.8.1 Общие положения

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

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

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

C.3.8.2 Типы аварийных сигналов

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

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

C.3.8.3 Серьезность тревожной сигнализации

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

Возможное определение уровней серьезности представляет собой:

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

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

C.3.8.4 Уровень приоритета аварийного сигнала

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

• уровень 1: требуются немедленные действия оператора. Опасность для персонала, катастрофический отказ оборудования/экологическое воздействие, неизбежен останов блока или останов других блоков;
• уровень 2: требуются быстрые действия оператора. Возможен останов блока. Наблюдается частичный останов. Возможны аварийные сигналы экстренного приоритета;
• уровень 3: требуются оперативные действия оператора. Возможен аварийный сигнал более высокого приоритета. Неизбежны производственные потери или производство некондиционного продукта.

Потребитель должен определить, следует ли в системе управления аварийными сигналами ОСУ поддерживать уровни приоритета.

C.3.8.5 Группирование аварийных сигналов

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

C.3.8.6 Квитирование аварийных сигналов

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

C.3.8.7 «Интеллектуальная» тревожная сигнализация/сокрытие аварийных сигналов

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

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

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

C.3.8.8 Аварийное оповещение

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

• активацию внешней звуковой тревожной сигнализации или аварийного освещения;
• активацию внутренней звуковой карты ПК (например, воспроизведение файлов в формате .wav);
• обновление экрана системы сигнализации для отображения текущего аварийного сигнала;
• обновление экрана всех аварийных сигналов для отображения появления аварийного сигнала в особой технологической зоне/дисплее;
• распечатку аварийного сообщения на принтере аварийной информации;
• изменение цвета, формы, внешнего вида, исчезновение и т.д. графического объекта, связанного с тревожной сигнализацией в зависимости от конфигурации.

C.3.8.9 Дисплейный перечень сводки аварийных сигналов

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

• активные технологические аварийные сигналы;
• сброшенные технологические аварийные сигналы;
• квитированные технологические аварийные сигналы;
• активные системные аварийные сигналы;
• сброшенные системные аварийные сигналы;
• квитированные системные аварийные сигналы;
• журнал аварийных ситуаций;
• перечень действий оператора;
• перечень подавленных (заблокированных) аварийных сигналов;
• перечень скрытых аварийных сигналов;
• дисплей частоты аварийных сигналов (перечень совпадений);

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

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

C.3.9 Управление событиями

C.3.9.1 Общие положения

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

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

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

C.3.9.2 Последовательность событий (ПС)

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

Разрешающая способность по времени не может быть меньше разделяющей способности и обычно она устанавливается.

C.3.9.3 Интеграция ПС с системами сторонних организаций

Если возможен доступ других прикладных программ и/или систем к данным, обрабатываемых ПС, необходимо определить их, а также потребность в особых драйверах или интерфейсе связи (например, аварийный сигнал и событие внешних контроллеров периферии).

C.3.9.4 Виды событий

Виды событий классифицируются по их источникам:

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

C.3.10 Архивирование событий

C.3.10.1 Общие положения

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

C.3.10.2 Метод архивирования

События могут сохраняться в базе данных событий в соответствии с различными методами:

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

Необходимо установить число событий подлежащих архивированию.

C.3.10.3 Резервирование архивной информации

База данных событий является критической частью всей ОСУ и по этой причине необходимо выбрать носители резервирования. Зарезервированная архивная информация очень важна для восстановления данных после аварийной ситуации или повреждения некоторых данных.

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

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

C.3.11 Управление трендами и статистической информацией

C.3.11.1 Общие положения

Для производственного и технологического контроля и управления ЧМИ должен отображать текущие и записанные значения в различных форматах в соответствии с технологическими требованиями.

C.3.11.2 Характеристики трендов

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

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

C.3.11.3 Тренды аналоговых значений

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

• текущее значение;
• среднее значение;
• минимум;
• максимум;
• среднеквадратическое отклонение.

C.3.11.4 Тренд дискретного значения

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

• текущее состояние;
• исходное состояние;
• число логических переходов;
• статистика.

C.3.11.5 Навигационные требования к трендам

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

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

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

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

C.3.12 Коммуникационные требования

Связь играет ключевую роль в ОСУ. Различные коммуникационные сети сосуществуют в ОСУ, каждая со своими особыми характеристиками и требованиями. Обычно коммуникационные сети могут быть разделены на три или четыре уровня в соответствии с используемой технологией. На рисунке C.1 схематично приведены эти альтернативы.

Условные обозначения:

DMZ — демилитаризованная зона;

FDN — сеть обратной связи с задержкой;

LAN — локальная сеть;

PCN — сети общего пользования;

WAN — глобальная сеть связи.

C.3.13 Промышленная шина

В соответствии с МЭК 61158 основными устанавливаемыми требованиями к промышленным шинам являются:

• физический уровень: медь, оптоволокно или беспроводная связь;
• коммуникационный профиль (КПФ) в соответствии с МЭК 61784;
• число устройств, подключенных к сети;
• установка в опасных зонах;
• необходимое дублирование коммуникационных носителей;
• максимальное расстояние между периферийным устройством и контроллером.

C.3.14 Сеть контроллера

Устанавливаемые требования к сети контроллера являются следующими:

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

C.3.15 Сеть аппаратной

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

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

C.3.16 Внешние связи

Внешние связи позволяют соединить различные сети, например, сеть аппаратной и корпоративной сети (см. рисунок C.1).

Пользователь должен установить:

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

C.3.17 Интерфейсы связи

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

Потребитель должен определить:

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

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

C.3.18 Связь с системой планирование ресурсов предприятия (ПРП)

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

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

• прямая интеграция: коммуникабельность систем ПРП (связь с системой управления), как часть программных продуктов, предлагаемых поставщиками. Поставщики должны предложить особую поддержку системе управления, которую должны эксплуатировать их заказчики;
• интеграция базы данных: системы ПРП подсоединяются к системе управления посредством промежуточных таблиц в базе данных. Системы управления сохраняют необходимую информацию в базу данных. Система ПРП считывает информацию в таблице;
• модули транзакций устройств предприятия (МТУП): данные устройства напрямую связаны с системой управления и системой ПРП с помощью методов, которые поддерживает система ПРП. МТУП могут применять промежуточную таблицу, веб-сервисы или программные интерфейсы, специфические для системы [программные интерфейсы приложения (ПИП)];
• стандартные протоколы: коммуникационные драйвера доступны для системы управления, а отдельные программные продукты способны регистрировать данные в промежуточных таблицах. Существуют промышленные стандарты для поддержки совместимости работы программных продуктов, известные как стандарты ОРС (связывание и встраивание объектов для управления технологическим процессом);
• необходимо проверить и учитывать требования безопасности для данной системы ПРП, в особенности, с учетом того, что нарушения безопасности могут возникнуть в офисной части (то есть, неконтролируемой) сети.

C.3.19 Связь с автоматизированной системой управления производственными процессами (АСУПП)

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

Существуют следующие методы подсоединения к АСУПП:

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

C.3.20 Модель программного обеспечения

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

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

C.3.21 Моделирование логики управления

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

C.3.22 Отладка в диалоговом режиме

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

C.3.23 Моделирование ввода/вывода

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

C.3.24 Функции удаленного контроля

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

C.3.25 Технология и область применения ОСУ

В соответствии с текущей терминологией, доступные технологии для ОСУ могут быть выбраны из:

• технологий на основе ПЛК;
• технологий программно-совместимых ПЛК;
• распределенная система управления (РСУ);
• комплексная автоматизированная система диспетчерского управления (КАС ДУ);
• прочее (необходимо указать).

Основную функцию или функции для необходимых ОСУ необходимо выбрать из нижеследующего:

• контроль;
• управление;
• противоаварийная защита (ПАЗ);
• партия изделий;
• прочее (необходимо указать).

C.3.26 Основная архитектура

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

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

C.4 Конфигурируемость

C.4.1 Конфигурация системы

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

Конфигурация может быть как аппаратной, так и программной.

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

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

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

Основными функциональными возможностями аппаратной конфигурации ОСУ являются:

• установка модулей;
• монтаж устройств;
• соединение пайкой и/или проводкой;
• установка перемычек;
• настройка переключателей;
• установка печатных плат.

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

C.4.2 Конфигурация в онлайновом режиме

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

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

Конфигурация в онлайновом режиме в основном зависит от стратегии резервирования ОСУ.

C.4.3 Конфигурация в автономном режиме

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

C.4.4 Конфигурация в режиме моделирования

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

C.4.5 Графические ресурсы

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

C.5 Гибкость

C.5.1 Резервная мощность системы

C.5.1.1 Общие положения

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

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

C.5.1.2 Резервная память

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

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

C.5.1.3 Расширяемость коммуникаций аппаратной

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

C.5.1.4 Расширяемость периферийных коммуникаций

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

C.5.1.5 Расширяемость периферийного устройства

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

C.5.1.6 Пространство, доступное для расширения ОСУ

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

• внутри шкафа управления для добавления новых устройств внутри;
• в аппаратной для добавления новых шкафов управления.

C.5.2 Общее число вводов/выводов

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

C.5.3 Число меток

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

• метки технологического управления: ограниченный набор информации или команд, необходимых для технологического управления. Например, технологический объект «клапан» может включать в себя следующие метки: положение клапана, состояние открыто/закрыто, заданное значение;
• метки дополнительных функций, таких как удаленная настройка устройства, диагностика, настройка тревожной сигнализации и т.д. Использование данных функций допускается только на интеллектуальных устройствах, подсоединенных посредством промышленной шины, и соответственно число меток может стать очень большим.

C.5.4 Число контуров управления

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

C.5.5 Масштабируемость системы

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

C.5.6 Расширяемость системы

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

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

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

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