Функциональная и организационная структура АСУ технологическими процессами
Выбери формат для чтения
Загружаем конспект в формате docx
Это займет всего пару минут! А пока ты можешь прочитать работу в формате Word 👇
Лекция 8.1. Функциональная и организационная структура АСУ технологическими процессами
страница 1
8.1.1. Структура АСУ ТП
8.1.1.1. Назначение АСУ технологическими процессами
АСУ ТП – это совокупность аппаратно-программных средств, осуществляющих в реальном времени контроль и управление технологическими процессами, поддерживающих обратную связь и воздействующих на ход процесса при отклонении его от заданных параметров, и обеспечивающих регулирование и оптимизацию управляемого процесса.
Не существует отрасли промышленности, в которой не было бы потребности применения автоматизации технологических процессов. Одними из главных преимуществ внедрения АСУ ТП является снижение, вплоть до полного исключения, влияния так называемого человеческого фактора на управляемый процесс, сокращение персонала, минимизация расходов сырья, повышение качества исходного продукта, и в конечном итоге существенное повышение эффективности производства. Основные функции, выполняемые подобными системами, включают в себя контроль и управление, обмен данными, обработку, накопление и хранение информации, формирование сигналов тревог, построение графиков и отчетов.
8.1.1.2. Три уровня иерархии АСУТП
АСУ ТП, приведенная на рис.8.1, состоит из трех уровней и включает в себя совокупность устройств управления, контроля и визуализации технологического процесса, а также системы сбора и трансляции архивированной информации:
- уровень 0 – базовая автоматизация: обеспечивает интерфейс с объектом управления, представлен датчиками и исполнительными механизмами;
- уровень 1 – управляющая подсистема: отвечает за сбор, обработку, отображение информации, выработку решений и передачу управляющих воздействий на объект, представлен программируемыми логическими контроллерами (PLC) и системами визуализации (операторскими панелями и SCADA-станциями);
- уровень 2 – информационная подсистема АСУ ТП: предназначена для обеспечения интеграции уровней управления АСУ, то есть для сбора, хранения и передачи данных с объекта управления в системы уровня управления производством (АСУП) или предприятия, обычно представлен серверами баз данных.
Рис. 8.1 Структура АСУТП
Уровень 2 является необязательным, опциональным, выделение которого зависит от сложности проектируемой системы управления и конкретных условий функционирования. Часто функции данного уровня выполняют SCADA-системы, но тогда им необходимо иметь интерфейс для интеграции с информационными системами АСУП.
8.1.1.3. Основные компоненты АСУТП
Датчик – устройство, преобразующее физические параметры технологического процесса в электрические сигналы, поступающие в дальнейшем на контроллер. Обычно под термином «датчик» подразумеваются два взаимосвязанных блока – чувствительный элемент (сенсор) и преобразователь.
Исполнительный механизм – устройство, которое преобразует электрические сигналы в физические воздействия и осуществляет управление параметрами технологического процесса.
Контроллер – вычислительное устройство, предназначенное для получения в реальном времени информации с датчиков, преобразования ее по программному алгоритму и обмена с другими компонентами системы автоматизации (компьютер оператора, панель визуализации, база данных и т.д.), а также для управления исполнительными механизмами.
SCADA-система (Supervisory Control and Data Acquisition - система диспетчерского контроля и сбора данных) – специальное программное обеспечение, решающее задачи ввода-вывода информации в системе АСУ ТП, отслеживания аварийных и предаварийных ситуаций, обработки и представления на экране оператора графической информации о процессе, поддержки отчетов о выполнении технологического процесса.
Пульт оператора – специально оборудованное место для обслуживающего персонала, куда поступает вся информация о технологическом процессе. Современные пульты управления оснащаются автоматизированными рабочими местами (АРМ) и позволяют не только контролировать процесс, но вмешиваться в его протекание.
Сервер баз данных реального времени (БД РВ) – аппаратно-программная платформа поддержки баз данных (обычно на основе известной реляционной СУБД), совместимая с информационно-управляющей сетью контроллеров и информационной сетью АСУП, обеспечивающая скоростной сбор данных, сжатие данных при сохранении и открытое предоставление полученной информации клиентским приложениям.
Управляющая сеть – это сеть передачи данных, функционирование которой обеспечивает, в отличие от сети информационной, помимо гарантии доставки собственно данных, гарантию доставки их за известный определенный детерминированный интервал времени.
8.1.2. Сбор данных с объекта управления
8.1.2.1. Получение дискретных и непрерывных сигналов с объекта
Сбор данных с объекта управления, а также контроль состояния оборудования объекта, осуществляется с применением преобразовательной техники и электрических аппаратов. Электрические аппараты (реле, контакторы, конечные выключатели и т.д.) обеспечивают доведение дискретных сигналов до управляющей подсистемы, а преобразовательная техника (датчики, электрические преобразователи и т.п.) – преимущественно аналоговых сигналов с объекта.
Сигнал называется непрерывным (или аналоговым), если его параметр может принимать любое значение в пределах некоторого интервала. Если обозначить Z – значение параметра сигнала, а t – время, то зависимость Z(t) будет непрерывной функцией (рис. 8.2 (а)).
Сигнал называется дискретным, если его параметр может принимать конечное число значений в пределах некоторого интервала. В АСУ ТП, как правило, дискретные сигналы могут принимать логические значения из множества {0,1} в зависимости от уровня передаваемого электрического сигнала (рис. 8.2(б)).
Рис. 8.2. Непрерывные и дискретные сигналы
8.1.2.2. Классификация измерительных преобразователей
Существует огромное множество преобразовательной техники, предназначенной для измерения физических параметров, которую можно классифицировать на группы по следующим признакам:
- по измеряемому параметру: давление, температура, магнитное поле и т.п.;
- по принципу действия: акустические, вибрационные, дымовые, позиционные, тепловые, индуктивные, емкостные, пьезоэлектрические и т.д.;
- по области применения: промышленные, бытовые, автомобильные, охранные и т.д.;
- по сервисным функциям: определяются наличием преобразователя, методом и алгоритмом обработки измеряемого параметра, возможностью автоматической калибровки, типом интерфейса для передачи данных и другими особенностями;
- по технологии изготовления: полупроводниковые, микромеханические, оптоволоконные, электромеханические, электрохимические и др.;
- по конструктивному исполнению: бескорпусные, в металлическом корпусе, пыле-, влагозащищенные и т.д.
8.1.2.3. Интерфейсы интеллектуальных датчиков и преобразователей
Помимо возможности доведения дискретных и аналоговых значений до управляющей системы, на сегодняшний день наибольший интерес представляют интеллектуальные преобразовательные устройства, в сервисные функции которых входит наличие стандартизированных интерфейсов передачи данных.
Среди большого многообразия стандартизированных коммуникационных решений можно выделить следующие группы интерфейсов интеллектуальных датчиков и преобразователей:
- точечные и многоточечные последовательные интерфейсы, основанные на физическом подключении посредством RS-232/422/485;
- интерфейсы (контроллеры, платы) коммуникационных сетей передачи данных (полевых шин), например DeviceNet, Profibus DP, CANOpen и др.;
- интерфейсы, позволяющие организовать беспроводную передачу данных, например инфракрасное соединение, GSM-канал, радиочастотный канал и т.п.;
- интерфейсы, позволяющие наряду с аналоговой информацией (4-20 мА) передавать и цифровые значения, например HART-протокол и др.
Все сказанное по процессу сбора данных с объекта управления, наоборот может быть отнесено и к передаче управляющих сигналов и данных на преобразователи исполнительных механизмов. Управляющая система вырабатывает дискретные управляющие воздействия или передает аналоговые данные на устройства полевого уровня для обеспечения функционирования объекта управления.
8.2.1. Структура комплексной АСУ предприятия
8.2.1.1. Цель и проблемы интеграции автоматизированных систем
Современный уровень автоматизации всех областей знаний и уровней управления в промышленности, требует пристального внимания со стороны проектировщиков и разработчиков АСУ и заставляет учитывать возможные внешние, по отношению к вновь создаваемым системам, информационные связи. Существующие, или создаваемые, локальные (автономные) системы, основанные на многообразии программно-технических решений, не охватывают всех функциональных областей управления. Продолжение практики внедрения автономных систем без общей стратегии объединения их в единое информационное пространство приводит к тому, что быстро возрастает количество используемых для обмена данными интерфейсов, в том числе и нестандартизованных, образующих наиболее дорогостоящие и ненадежные узлы информационных потоков. Сопровождение таких систем становится крайне трудоемкой задачей и перспективы данного подхода оказываются сомнительными в случае необходимости интеграции создаваемой системы с действующими технологическими и производственными системами, с бизнес-системами, логистическими системами и т.п.
В связи с этим, одной из главных задач, которые встают перед проектировщиками систем управления, является задача обеспечения информационной совместимости с существующими действующими АСУ на территории исследуемого объекта управления (задача интеграции систем).
Основная цель интеграции различных подсистем на предприятии – это создание единого информационного пространства предприятия для объективной и оперативной оценки текущей ситуации, оперативного принятия оптимальных управленческих решений и ликвидации информационных и организационных барьеров между управленческим и технологическим уровнями.
Применительно к АСУ ТП, интеграция объектов технологических систем в АСУ предприятия представляет собой сложный процесс синтеза информационного потока, интенсивность которого изменяется на разных уровнях управления.
8.2.1.2. Иерархическая структура комплексной АСУ предприятиям
Графически модель комплексной АСУ предприятия можно представить в форме трехуровневой пирамиды управления промышленным предприятием (рис. 3.5).
Верхний уровень управления предприятием (административно-хозяйственный) решает стратегические задачи, обеспечивает управление ресурсами в масштабе предприятия в целом, включая часть функций поддержки производства (долгосрочное планирование и стратегическое управление в годовом, квартальном, месячном масштабе).
Интеграционный (производственный) уровень комплексной структуры управления решает задачи оперативного управления процессом производства и обеспечивает эффективное использование ресурсов, таких как сырье, энергоносители, производственные средства, персонал и т.д., а также оптимальное исполнение плановых заданий за смену, сутки, декаду, месяц на уровне цеха, участка, агрегата.
Нижний уровень (технологический) решает классические задачи управления технологическими процессами.
На каждом из уровней управления должны функционировать одноименные АСУ, в совокупности образующие интегрированную АСУ предприятия.
Процесс интеграции систем следует понимать как выработку совокупности технических, программных, информационных, организационных и других решений, позволяющих вести создание комплексной информационной поддержки деятельности предприятия, соответствующей современному уровню развития информационных технологий.
Реализация интегрированной АСУ предприятия обеспечивает оперативность и достоверность информации на всех уровнях управления и позволяет существенно оптимизировать потоки данных
8.2.2. Типы интеграции в АСУ
8.2.2.1. Горизонтальная интеграция автоматизированных систем
Для создания единой информационной системы предприятия, необходимо решить следующие задачи:
1. Горизонтальная интеграция, т.е. обеспечение информационного взаимодействия между существующими автономными системами внутри одного уровня управления.
2. Вертикальная интеграция, т.е. обеспечение информационной согласованности между системами, относящимися к разным уровням структуры АСУ предприятия.
Решение вопросов горизонтальной интеграции может происходить на любом из уровней управления. Необходимость интеграции объектов одного уровня может быть вызвана различными причинами, например:
- на уровне АСУ ТП требуется обеспечить согласованную работу сборочного участка, состоящего из нескольких роботов, выполняющих последовательные (или взаимоисключающие) операции и управляемых от PLC;
- на уровне АСУП необходимо обеспечить формирование сменного задания на производство основных видов продукции, автоматическое доведение его до всех участков (агрегатов) цеха и ведение контроля его выполнения;
- на уровне АХС ставится задача учета потребления энергоресурсов при производстве продукции (по видам) для сопоставления с плановыми показателями затрат и фактического их учета в бухгалтерии.
8.2.2.2. Вертикальная интеграция автоматизированных систем
При рассмотрении вопросов вертикальной интеграции, необходимо решать следующие проблемы:
На уровне АСУ ТП – это обеспечение хранения оперативных данных (данных реального времени – realtime-данные) в объеме, оптимальном для всего предприятия. Именно эти данные должны стать источником обрабатываемой информации на более высоком уровне, в том числе востребованной в бизнес-приложениях, системах управления ресурсами предприятия.
На уровне АСУП – это формирование данных, отражающих динамику и последовательность технологического процесса производства продукта от сырья до товара (product-данные). Программное обеспечение, ориентированное на решение таких задач, относится к классу MES (Manufacturing Executive Systems), или систем управления производством. В качестве входных данных в MES-системы поступают параметры сырья, выходными параметрами является полная характеристика (например, технологический паспорт) полученного товара.
На уровне АХС – это формирование данных, отражающих структуру и состояние фондов (активов) предприятия, прежде всего, основных фондов, с помощью которых реализуется технологический процесс (maintenance-данные). Программное обеспечение, ориентированное на отслеживание и сопровождение основных фондов производства, относится к классу систем EAM (Enterprise Assets Management).
8.2.2.3.Типовые варианты построения интегрированной АСУ
В условиях, когда сформировались субъективные (понимание задач) и объективные (возможность технической реализации) предпосылки создания единой информационной системы предприятия, важно разработать концепцию единого информационного пространства для предприятия. Она должна включать описание задач, структур отдельных подсистем, архитектурную схему обобщенной системы с определением информационных потоков и потоков управления.
Для интеграционного слоя важно оценить спектр требуемых технических и программных средств, проанализировать возможные каналы обмена данными, поскольку несовместимость по каналам обмена может заметно снизить интеграционные возможности, а, следовательно, потребительские свойства системы.
При разработке концепции интегрированной АСУ можно учитывать типовые варианты построения систем:
- иерархический вариант характеризуется тем, что выбранные realtime-данные поднимаются с уровня технологических систем на интеграционный уровень. Далее часть realtime-данных и product-данные поднимаются на уровень АХС и вместе с maintenance-данными предоставляются бизнес-приложениям. Аналогичным образом через интеграционный уровень должны осуществляться управляющие воздействия на технологические приложения со стороны бизнес-уровня. Данный вариант характеризуется иерархически распределенными информационными системами;
- централизованный вариант ориентирован на постоянное сохранение всей технологической информации на интеграционном уровне: приложения уровней АХС и АСУ ТП при необходимости обращаются к данным, хранящимся в инфраструктуре интеграционных систем, при этом, не обязательно сохраняя обработанную информацию на своем уровне. Соответствующее приложение, например, бизнес-уровня по известному алгоритму всегда может получить результат, запросив данные с интеграционного уровня. По конфигурации централизованная система аналогична иерархической, но направления информационных потоков и потоков управления отличаются;
- диспетчерский вариант предполагает, что интеграционные приложения распределены по объектам АСУ ТП (отдельным участкам, агрегатам). Например, в АСУ ТП каждого участка (агрегата) имеется свой сервер баз данных РВ для сбора технологической информации. В структуре АСУП отсутствуют выделенные информационные системы, обеспечивающие хранение данных о производстве в целом, а они распределены по участкам (агрегатам). В этом случае, разрабатывается некий пульт диспетчера (клиентское приложение), которое обеспечивает информацией о производстве на основе запросов к распределенным по участкам и агрегатам серверам. Уровень АХС получает данные по каналам связи с диспетчерского пульта.
8.2.3. Проблемы информационного взаимодействия АСУТП и АСУП
8.2.3.1. Концепция единой СУБД предприятия
Для обеспечения функций предприятия, системы административно-хозяйственного уровня должны быть связаны с интеграционным уровнем и чаще всего данное взаимодействие строится на реализации серверных и клиентских приложений информационных систем, которые объединены стратегией единой корпоративной системы управления базами данных (СУБД).
В настоящее время концепция единой СУБД корпорации является единственно правильной с точки зрения совместимости всех информационных потоков от уровня управления отдельными объектами до администрации предприятия. Процесс внедрения выбранной СУБД является оправданно длительным и трудоемким, и при комплексном логистическом подходе к построению информационной системы дает ощутимые преимущества.
8.2.3.2. Физическая основа интеграции уровней АСУП с АХС и АСУП с АСУТП
Физически, интеграция систем уровней АСУП и АХС осуществляется посредством информационных сетей, и чаще всего применяются решения, основанные на популярной технологии Ethernet, интерфейс с которой присутствует практически в любой современной ЭВМ.
Интеграция объектов АСУ ТП в единое информационное пространство систем предприятия также должна основываться на взаимодействии компонентов технологической автоматизации с компонентами уровня АСУП.
Огромное разнообразие прикладных систем управления технологическими объектами, множество частнофирменных компонентов, на основе которых строятся элементы АСУТП, а также отсутствие стандартов построения подобных систем, вызывают существенные трудности в построении связующих звеньев между технологическими и административными системами АСУ предприятий. Реализация физической линии связи, организация логического взаимодействия между уровнями в каждом конкретном случае является более сложной проблемой, чем определение структуры интегрированной АСУ, и относится к сложной системотехнической задаче с множеством возможных решений.
8.2.3.3. Интеграция уровней АСУП и АСУТП с применением аппаратно-программного шлюза
В общем случае, данные проблемы можно решить с использованием трех основных подходов к реализации интеграционного звена технологического объекта.
Первый подход основан на применении аппаратно-программного шлюза, обеспечивающего, с одной стороны, взаимодействие с компонентами управляющей системы объекта (PLC) и поддерживающий, с другой стороны, прямой доступ к известным СУБД, на базе одной из которых реализована корпоративная информационная система. Данный подход практически всегда может быть реализован на основе SCADA-системы (рис. 8.6).
8.2.3.4. Интеграция уровней АСУП и АСУТП с применением сервера баз данных реального времени
Второй подход основан на применении сервера баз данных реального времени (см. рис. 8.1), обеспечивающего сбор, обработку и дистрибуцию технологической информации в темпе с управляемым процессом. В этом случае SCADA-станции становятся независимыми от информационных сетей интеграционного уровня, и структура интеграции соответствует диспетчерскому варианту.
8.2.3.5. Интеграция уровней АСУП и АСУТП на основе открытых интерфейсов
Третий подход основан на использовании открытых интерфейсов и протоколов взаимодействия приложений (OPC, DDE), поддерживаемых практически всеми производителями средств управления технологическими процессами, и разработкой собственных программных продуктов с использованием языков высокого уровня или специальных пакетов разработчика, отвечающих за транспорт данных между уровнями (рис. 8.7).
В последнем случае клиентское приложение в качестве сервера может использовать SCADA-систему, но для связи с ней желательно использовать отдельную служебную сеть, независимую от других сетей любого уровня. Также в ряде случаев, при наличии драйверов прямого доступа к PLC, серверов OPC/DDE для чтения структур данных контроллера и коммуникационных карт для работы по информационно-управляющей сети, станцию с клиентским приложением подключают в единую сеть с PLC.
Не стоит ограничиваться представленными вариантами информационного взаимодействия, их может быть намного больше и решения по интеграции могут сочетать в себе как более простые средства взаимодействия, так и более сложные и даже экзотические. Выбор одного из этих или других решений зависит от множества факторов и в каждом конкретном случае значимость одних и тех же факторов может быть различной. На выбор проектного решения могут влиять: тип оборудования АСУТП, тип корпоративной СУБД, наличие открытых интерфейсов существующих программных средств, наличие прямых драйверов связи, наличие в штате квалифицированных программистов, стоимость проекта и т.д. и т.п.
8.2.4. Интеграция уровней управления на основе SCADA-систем
8.2.4.1. Компоненты SCADA-систем
Одним из вариантов интеграционного решения в АСУ предприятия является подключение SCADA-станций (или серверов SCADA) к информационной сети передачи данных, используемой в АСУП (см. рис. 8.6). В качестве информационной сети чаще всего применяется сеть, построенная по технологии Ethernet. В связи с этим, проблемы физической совместимости в решении задачи интеграции уровней уступают место программным технологиям и алгоритмам.
Наличие физических линий связи для обеспечения непрерывности потока информации между уровнями управления во многом является необходимым условием интеграции систем. Определяющим фактором в процессе информационной согласованности уровней АСУ является наличие совместимых программных средств и технологий.
На рис. 8.8 представлена компонентная структура SCADA-систем, позволяющая говорить о данном продукте, как об открытой (в смысле интеграции) системе.
Подавляющее большинство SCADA-систем на рынке автоматизации разработаны под платформу операционной системы Microsoft Windows NT. Рассмотрим основные программные технологии, применяемые и используемые в таких системах для обеспечения информационного взаимодействия программ различных уровней автоматизации.
Практически любая SCADA-система позволяет довести информацию с объекта управления без ограничений на выбор оборудования полевого уровня. Это возможно благодаря существующим возможностям настройки системы в качестве клиента OPC/DDE к соответствующим серверам, поставляемым вместе с устройствами автоматизации. Таким образом, обеспечивается унифицированный интерфейс SCADA с объектом управления, что позволяет, при определенных навыках программирования, вести разработку собственных OPC/DDE серверов для уникального (либо слабо распространенного) оборудования.
Наряду с унифицированным подходом к сбору данных с объекта управления, многие производители SCADA-систем, занимающиеся не только разработкой программного обеспечения (например, Siemens, Rockwell Automation и другие), поддерживают и возможность сбора данных посредством прямых драйверов устройств и сетей. Чаще всего, в комплекте SCADA имеются драйверы для связи с оборудованием данного производителя.
8.2.4.2. Особенности SCADA-систем, обеспечивающие возможность интеграции с АСУП
Данные, которые собираются и накапливаются в SCADA-станциях, могут быть использованы потребителями информации более высокого уровня автоматизации благодаря следующим возможностям:
1. Наличию встроенного OPC/DDE сервера, который предоставляет в реальном масштабе времени доступ к внутренней базе тегов (переменных). При этом доступ осуществляется не только к структуре базы тегов, но и к их текущим значениям в процессе исполнения.
2. Наличию локальной базы данных, поставляемой вместе с пакетом SCADA, с помощью которой осуществляется: сбор архивной технологической информации; регистрация данных об аварийных ситуациях; ведение журнала событий и действий оператора по управлению объектом. Доступ к таблицам базы данных может быть выполнен из клиентского приложения при наличии драйвера применяемой в SCADA СУБД.
3. Поддержке механизма передачи информации во внешнюю (локальную или удаленную) базу данных посредством установленных драйверов ODBC. При наличии драйвера, во внешнюю базу могут быть переданы такие же данные, что и в локальную.
4. Поддержке открытых интерфейсов взаимодействия приложений, например ActiveX. Большинство SCADA-систем могут выступать в роли контейнера ActiveX, что позволяет использовать любые созданные и зарегистрированные в операционной системе объекты ActiveX.
Современные SCADA-системы обладают высоким потенциалом и набором возможностей для применения их в качестве интеграционного звена между уровнями непосредственного управления объектами и анализа производственного процесса. Используя возможности операционной системы, открытые интерфейсы взаимодействия программ, SCADA-системы позволяют эффективно вести процесс трансляции оперативных данных в приложения пользователей, где они структурируются, идентифицируются и подвергаются анализу.