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

5.1 Иерархическая структура технических процессов

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

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

Таблица 2 -Типичные требования к информации о процессах

(все показатели — ориентировочные)

К нижнему уровню иерархии предприятия относятся механизмы и устройства которые непосредственно соприкасаются с процессом, — датчики и исполнительные механизмы. Это уровень локального управления (field control level) или уровень датчиков/ исполнительных механизмов (sensors / actuators level). Как следует из назва­ния, на этом уровне расположено оборудование, которое непосредственно связано с техническим процессом. Науровне управления процессом (process control level) находятся ЭВМ, регуляторы и другие "интеллектуальные" устройства, которые ведут наблюдение за процессом и управляют им с помощью датчиков и исполнительных механизмов. Уровень управления процессом являются самым нижним, на котором будут приниматься автономные решения.

Следующий, более высокий уровень — это уровень управления участком (sell control level). Этот уровень управления прямо не связан с техническими процессами, обменивается информацией в виде опорных и текущих значений величин с выше-ниже лежащими уровнями. В случае производственного участка, на котором разные участки связаны в технологическую цепочку для выполнения определенных операций, происходит интенсивный горизонтальный обмен данными (т. е. на одном уровне) для координации работы различных механизмов при меньшем вертикальном обмене с вертикальными уровнями. Действительно, для верхних уровней управления представляют интерес только поступление материалов (деталей) и потоки энергии на входе и выходе участка. Науровне управления производством (рrоduсtion сопtrol 1еvе1) координируется деятельность нескольких участков для достижения равномерного потока материалов или энергии (выход одного производственного участка является входом для другого. Наконец, науровне стратегического управления (management сопtrо1 1еvе1) имаются общие решения, которые влияют на работу всего предприятия.

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

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

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

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

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

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

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

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

На уровне управления процессом сбор данных выполняется по опросу (ро1ling).

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

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

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

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

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

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

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

Определение пропускной способности канала и мощности процессора является существенным моментом. Мощности процессора должно быть достаточно для обработки требуемого объема данных с известным запасом. Простейшее правило - использовать коэффициент запаса от 3 до 10 по отношению к минимально необходимой мощности процессора.

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

Протокол автоматизации производства (МАР)

Необходимость в практичном и едином способе соединения различных устройств производственных линий и систем управления в течение длительного времени было в центре внимания. Американский автостроительный гигант Gеnегаl Моtоrs один из первых осознал, что несовместимость различных вычислительных систем является главной помехой для комплексной автоматизации их производств. Компания начала исследования для объединения своих производственных ЭВМ. Было замечено, что затраты на системы управления значительно превышали общие затраты на переоснащение производства при запуске новых моделей автомобилей и имели только одну тенденцию — к увеличению. В соответствии с оценками, сделанными в начале 1980-х годов, к 1990 году было бы необходимо объединить порядка ста тысяч единиц различного оборудования типа роботов и ПЛК. Стоимость объединения должна была составить значительную долю всех вложений компании в автоматизации, этому General Моtогs пришла к необходимости разработать ясный и стандартный подход к открытой системе заводских коммуникаций, имея в виду универсальное взаимодействие и взаимозаменяемость. Первое означает, что любая информация должна быть понятна устройствам-получателям без использования программ преобразования; второе — что устройство нового поколения или другого производителя, заменяющее некоторое старое устройство, должно работать без изменений в системе, к которой оно присоединяется. Идея сразу вызвала интерес у основных производителей ВТ и других компаний, связанных с промышленной автоматизацией, и привела к созданию Протокола автоматизации производства (Маnиfасtиring Automatic Protocol- МАР).

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

МАР следует схеме разделения на уровни, принятой в модели ВОС. Для каждого уровня существует определенный стандарт, являющийся частью общей структуры МАР. Стандарты уровней от 1 до 6 используются и в других приложениях, а непосредственно к МАР относится Служба производственных сообщений (Manufacturing Message Specification — ММS), которая описана далее. Ниже приведено соответствие стандартов МАР уровням модели ВОС.

Уровень 7: ISO 9506 Manufacturing Message Specification (ММS)

Уровень 6: ISO 8824 Abstract Syntax Notarion (ASN.1) ISO8825 Base Encoding Rules

Уровень 5: ISO 8326/8327

Уровень 4: ISO 8072/8073

Уровень 3: ISO 8348/8473 (CLNS) и ISO 9542 (ЕS/IS)

Уровень 2: ISO 8802.2 Logical Link Control и ISO 8802.4 Тоkеn Виs

Уровень 1:Широкополосная / Узкополосная среда передачи (Broadband / Carrierband Link)

Другими словами, МАР - устройство должно использовать физические соединения которые соответствуют стандарту маркерной шины локальных вычислительных сетей (Noken Bus) с управлением логическим звеном данных в соответствии IEЕЕ 802.2, должно кодировать данные, следуя АSN.1 (ISO 8824) и ISO 8825, и обмениваться сообщениями в формате ММS (ISO 9506). Любая другая комбинация стандартов, даже если она технически возможна, не совместима со схемой МАР. Например, решение, при котором Еnhentel используется вместо маркерной шины на физическом и канальном уровнях, не соответствует МАР. Тем не менее ММS в сочетании с Еnhentel работает и находит применение в промышленности.

На физическом уровне МАР можно реализовать на основе различных сред пере типов сигналов. Первоначальные пожелания General Motors – передавать данные со скоростью 10 Мбит/с — требовали двух смежных каналов с полосой пропускания 6 МГц, при условии использования широкополосной модуляции АМ-РSК для узкополосного МАР определены две скорости передачи данных и применяется частотная модуляция FSK: для пропускной способности 5 Мбит/с несущие частоты 5 и 10 МГц, для 10 Мбит/с - 10 и 20 МГц.

Для обмена укрупненной (интегрированной) информацией о процессах и административными данными используется схема, аналогичная МАР, — это Протокол автоматизации учрежденческой деятельности (Technical and Office Protocol - ТОР). Архитектура ТОР в основном совпадает с архитектурой МАР и опирается на те же стандарты. В архитектуре ТОР на физическом и канальном уровне используется вгпе1, а не маркерная шина. На прикладном уровне протокол ТОР включает в себя виртуальный терминал (Virtual Terminal - VТ), систему обработки сообщений (Message Handling System — MHS) и протокол передачи, доступа и управления файлами (File Transfer Access and Management — FТАМ). Концепция ТОР разработана корпорацией Воеning, которая в течение длительного времени использовала Ethenter для cвязи производственного оборудования и системы планирования производства. Основные идеи архитектур МАР и ТОР практически одинаковы.

МАР был специально разработан для применения на производстве в режиме реального времени. Причина, определившая выбор конкретных стандартов для МАР, в первую очередь широкополосной сети и маркерной шины в качестве метода доступа заключалась в том, что они уже были опробованы в условиях реального производства, а соответствующие устройства производились серийно. Маркерная шина имеет детерминированное и поддающееся расчету время передачи сообщения в наихудших условиях чего нет в протоколе Ethenter (некоторые приложения реального времени нельзя реализовать при неопределенном времени передачи сообщения). Не удивительно, что протоколы МАР и ТОР благодаря своей структуре были поддержаны компаниями с резко различающимися требованиями. General Motors производит автомобили на конвейерах, движущихся с заданной скоростью, а компания Воеing собирает самолеты на неподвижных стапелях; соответственно, требования синхронизации совершенно различны. Совместимость на верхних уровнях гарантирует сопряжение приложений МАР и ТОР.

В системах автоматизации производства, вообще говоря, имеется три функциональных уровня — общее (целевое) управление, управление процессом или производственной линией и локальное управление. МАР поддерживает взаимодействие на среднем уровне, на его основе координируется работа множества участков в технологической цепочке и нескольких технологических цепочек на уровне предприятий МАР не подходит для связи и управления на уровне датчиков. МАР является достаточно "тяжеловесным" продуктом из-за большого количества уровней и соответствующих протоколов, и поэтому не соответствует нуждам простых, быстрых и дешевых технологий, используемых на нижнем уровне автоматизации производства. Здесь рационален другой подход — использование шины локального управления Fieldbas (раздел 9.7). МАР также не годится для поддержки системы управления верхнего уровня, на котором принимаются стратегические решения. Программные средства этого уровня не должны удовлетворять специфическим требованиям реального времени и могут разрабатываться на основе обычного программирования, использующие статистическую обработку и анализ больших объемов данных. Тем не менее МАР остается ключевым подходом к практической реализации автоматизированных систем, управления производством (АСУП, Соmрutег Integrated Manufacturing— СIМ).