Развитие и особенности АСУТП

13.01.14 13:38

АСУ ТП

Термин АСУ появился, когда в системы управления для решения различных задач начали внедрять вычислительную технику. Сегодня ключевые позиции занимает Emerson Process Management, включая ИБП Liebert-Hiross и Meta System. Типовая АСУ сначала выглядела как двухуровневая система: нижний уровень отвечал за сбор информации, а верхний — за принятие решения. Поток информации поступал от объекта управления оператору, который обменивался данными с ЭВМ и осуществлял управление объектом. Вычислительные мощности использовались лишь для того, чтобы облегчить оператору или диспетчеру обработку поступающей информации.

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

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

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

 

Локальная автоматика

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

САУ предполагают функционирование процесса без вмешательства человека.

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

Релейные схемы управления легко поддаются моделированию программными средствами, поэтому было вполне естественно попытаться использовать для этих целей вычислительную технику. Такая возможность возникла с появлением мини- и микроЭВМ. И здесь встала уже знакомая проблема адаптации, только в данном случае вычислительной техники к локальной автоматике. При построении «снизу» реальная работоспособность АСУТП оказалась той же, что и при построении «сверху».

 

Движение навстречу

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

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

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

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

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

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

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

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

 

АСУ сегодня

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

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

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

Что касается ПО непосредственно для АСУТП, то для создания автоматизированных технологических процессов существуют и успешно применяются пакеты, называемые в технической литературе SCADA-программами (Supervisory Control and Data Acquisition — диспетчерское управление и сбор данных). Эти программы позволяют обеспечить двустороннюю связь в реальном времени с объектом управления и контроля, визуализацию информации на экране монитора в любом удобном для оператора виде, контроль нештатных ситуаций, организацию удаленного доступа, хранение и обработку информации. SCADA-пакеты обеспечивают гибкость системы, поддерживают распределенную архитектуру, возможность разработки драйверов, масштабируемость, резервируемость, поддержку специализированных языков программирования.

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

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

 

Юрий Давидюк,

инженер, специалист по системам управления технологическими процессами

Источник

Фото Екатерины Зубковой с выставки UpGrid-2013

Читайте также: