книги / SCADA-╤Б╨╕╤Б╤В╨╡╨╝╤Л ╨║╨░╨║ ╨╕╨╜╤Б╤В╤А╤Г╨╝╨╡╨╜╤В ╨┐╤А╨╛╨╡╨║╤В╨╕╤А╨╛╨▓╨░╨╜╨╕╤П ╨Р╨б╨г ╨в╨Я

фармацевтической и некоторых других отраслях промышленности можно выделить задачи управления технологическими последова­ тельностями (batch control). Их суть заключается в обеспечении выпуска продукции в нужном объеме с заданными технологиче­ скими характеристиками при наличии возможности перехода на новый вид продукции. Отделились от АСУ ТП и задачи ведения архива значений технологических переменных с возможностью восстановления производственных ситуаций прошедших периодов и анализа нештатных ситуаций. Появились программы обучения технологического персонала и оптимизации ведения технологиче­ ских процессов.

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

Расследование и анализ большинства аварий и происшествий в авиации, наземном и водном транспорте, промышленности и энер­ гетике, часть из которых привела к катастрофическим последстви­ ям, показали, что если в 60-х годах XX столетия ошибка человека являлась первоначальной причиной лишь 20 % инцидентов (80 %, соответственно, за технологическими неисправностями и отказа­ ми), то к 90-м годам доля «человеческого фактора» возросла до 80 %, причем в связи с постоянным совершенствованием техноло­ гий и повышением надежности электронного оборудования и ма­ шин эта доля может еще возрасти [3].

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

11

темы и в то же время недооценка необходимости построения эффективного человекомашинного интерфейса, т. е. интерфейса, ориентированного на пользователя (оператора). Изучение мате­ риалов по проблемам построения эффективных и надежных систем диспетчерского управления показало необходимость при­ менения нового подхода при разработке таких систем: «human­ centered design» или top-down (сверху вниз), т. е. ориентация в первую очередь на человека-оператора (диспетчера) и его зада­ чи вместо традиционного и повсеместно применявшегося «hard­ ware-centered» или bottom-up (снизу вверх), в котором при по­ строении системы основное внимание уделялось выбору и разработке технических средств (оборудования и программного обеспечения).

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

планирует, какие следующие действия необходимо выполнить; обучает (программирует) компьютерную систему на после­

дующие действия; отслеживает результаты (полу)автоматической работы систе­

мы;

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

обучается в процессе работы (получает опыт).

Основными особенностями процесса управления в диспетчер­ ских системах управления являются следующие:

процесс SCADA применяется в системах, в которых обязатель­ но наличие человека (оператора, диспетчера);

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

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

пр-);

12

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

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

1)программирование с использованием «традиционных» средств (классические языки программирования, стандартные средства отладки и пр.);

2)применение существующих, готовых COTS (Commercial Of The Shelf) инструментальных проблемно-ориентированных средств.

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

Логика развития современного бизнеса в части разработки прикладного ПО для систем управления требует использования все более развитых инструментальных средств типа SCADAсистем. Разработка современной SCADA-системы требует боль­ ших вложений и выполняется в длительные сроки. Именно поэто­

13

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

1.2.Этапы создания системы диспетчерского контроля

иуправления

Процесс создания системы диспетчерского контроля и управ­ ления состоит из следующих этапов.

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

2. Разработка проектно-сметной документации (в полном или сокращенном объеме).

3.Сбор исходных данных.

4.Составление полного перечня переменных.

5.Комплектация системы.

14

6.Разбиение объекта управления на технологические участки; компоновка переменных по участкам и группам.

7.Заполнение (генерация) базы данных.

8.«Рисование» статических частей мнемосхем.

9.Заполнение мнемосхем динамическими элементами.

10.Составление схемы переходов между мнемосхемами.

11.Генерация печатных документов.

12.Верификация базы данных.

13.Разработка эксплуатационной документации.

14.Тестирование системы в автономном режиме (без УСО).

15.Монтаж.

16.Тестирование системы в рабочем режиме (с УСО).

17.Внедрение, в том числе пусконаладка и обучение персонала. Возможно распараллеливание некоторых видов работ, что

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

На этапах 1, 2 составляются подробные технические требова­ ния (техническое задание) на систему контроля и управления, ко­ торые согласуются с конечным пользователем - теми, кто будет непосредственно эксплуатировать систему, например технолога­ ми. Для конкретизации технических требований необходимо вы­ полнить следующее:

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

указать конкретную информационную мощность системы (пе­ речень измеряемых и управляющих переменных);

привести перечень расчетных переменных, формулы расчета; привести конкретный перечень печатных документов и усло­

вий их печати; конкретизировать перечень требований к конечному пользова­

телю системы.

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

числа устройств связи с объектом;

15

типов УСО и скорости их обмена с ПК; объема базы данных (информационная мощность); числа расчетных переменных;

модели ПК (тип процессора, тактовая частота, объем кэш­ памяти и т. п.).

Проектно-сметная документация на систему контроля и управ­ ления может разрабатываться в полном или сокращенном объеме, определяемом заказчиком системы.

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

1)функциональные схемы КИПиА (А - автоматика);

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

3)ведомость (спецификация) средств КИПиА;

4)перечень контролируемых и регулируемых параметров;

5)внешний вид существующих щитов КИП с вторичными приборами;

6)разводка параметров по существующим вторичным прибо­

рам;

7)фотографии, рисунки, чертежи основных технологических агрегатов, которые помогают лучше и понятнее нарисовать мне­ мосхемы;

8)заполненные образцы отчетных документов (режимных листов, суточных ведомостей и т. п.).

Информация по пп. 5) и 6) существенно облегчает компоновку переменных по участкам и группам.

Существуют три основных подхода к разработке системы кон­

троля и управления: от графики;

от структуры системы управления (аппаратуры); от структуры технологического объекта (технологии).

Подход от графики - это простейший подход к разработке. Он предполагает первичным создание пользователького интерфейса оператора. Такой подход характерен для большинства западных пакетов, ориентирован на малоопытного разработчика и оправды­

16

вает себя при создании малых систем управления, состоящих из одного компьютера и стандартных ПЛК или модулей УСО. Здесь предполагается работа с небольшим числом сигналов, когда нет необходимости структурировать базу переменных проекта.

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

Подход от структуры технологического объекта - это наиболее продвинутый подход к созданию систем контроля и управления. Он интегрирует в себе оба предыдущих подхода и добавляет ана­ лиз автоматизируемого объекта для построения технологической иерархии (технологический слой проекта).

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

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

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

17

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

1.3. Функциональные характеристики SCADA-систем

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

производство, управление передачей и распределением элек­

троэнергии;

промышленное производство;

водозабор, водоочистка и водораспределение;

добыча, транспортировка и распределение нефти и газа;

управление космическими объектами;

управление на транспорте (все виды транспорта: авиа, метро,

железнодорожный, автомобильный, водный);

телекоммуникации;

военная область.

От SCADA-системы требуется выполнение таких функций, как: сбор данных от контроллеров; первичная обработка данных; архивизация данных; представление динамичных мнемосхем объ­ екта; представление трендов измеряемых величин; сообщение о неисправностях и авариях; печать протоколов и отчетов; ввод в

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

К SCADA-системам предъявляются следующие основные тре­ бования:

надежность системы (технологическая и функциональная);

18

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

1.3.1.Функциональные возможности

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

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

автоматизированная разработка, дающая возможность созда­ ния ПО системы автоматизации без использования стандартных языков программирования;

средства сбора первичной информации от устройств нижнего уровня;

средства управления и регистрации сигналов об аварийных си­ туациях;

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

средства обработки первичной (измерительной) информации; средства визуализации текущей и исторической информации в

виде таблиц, графиков, гистограмм, динамизированных мнемо­ схем, анимационных изображений и т. д.;

печать отчетов и протоколов произвольной формы в заданные моменты времени;

ввод и передача команд и сообщений оператора в ПЗГК и др\ - гие устройства системы;

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

информационные связи с серверами и другими рабочими стан­ циями через различные сетевые структуры.

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

19

В целом технология проектирования систем автоматизации на основе различных SCADA-систем очень схожа и состоит в сле­ дующем [6, 7]:

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

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

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

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

отладка созданной прикладной программы в режиме эмуляции

и в реальном режиме.

Функциональные возможности систем SCADA в значительной мере определяют стоимость и сроки создания ПО, а также сроки ее окупаемости.

Рассмотрим характеристики, наиболее важные для оценки функциональности SCADA-систем.

1.3.2. Программно-аппаратные платформы SCADA-систем

Анализ перечня таких платформ необходим, поскольку от не­ го зависит ответ на вопросы распространения SCADA-системы на имеющиеся вычислительные средства, а также оценка стоимо­ сти эксплуатации системы (будучи разработанной в одной опера­ ционной среде, прикладная программа может быть выполнена в любой другой, которую поддерживает выбранный SCADAпакет). В различных SCADA-системах этот вопрос решен по-разному. Так, Factory Link (версия 6.6) имела весьма широкий список поддерживаемых программно-аппаратных платформ

(табл. 1.2).

20