Этапы создания SCADA-системы

Разработка SCADA-системы, как и разработка любой автоматизированной системы, ведется в общем случае в следующей последовательности:

1) формируются требования к SCADA-системе;

2) разрабатывается концепция SCADA-системы;

3) разрабатывается технический проект АСУ ТП верхнего уровня;

4) разрабатывается программная документация SCADA-системы.

 

2.1. Формирование требований к SCADA-системе

На этапе формирования требований проводят:

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

 

Рассмотрим некое «виртуальное» предприятие, состоящее из нескольких цехов (подразделений). Какие требования службы предприятия выдвигают к подобной системе?

Допустим, что основной пользователь системы — отдел Главного энергетика — желает получить:

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

• коммерческий учет энергоресурсов, отпускаемых субабонентам;

• технический учет энергоресурсов на вводе в отдельные цеха;

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

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

• телеуправление (возможно автоматическое) электротехническим и теплотехническим оборудованием;

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

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

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

• используемые операционные систе­мы — в большинстве случаев это Windows 98/NT/2000;

• единая база данных на стандартных СУБД, причем все чаще требуются не «настольные» СУБД (Paradox, Access), а мощные SQL-базы данных (MS SQL 7.0, Oracle), которые могут одновременно обслуживать десятки АРМ и гарантируют достоверность и сохранность информации;

• использование клиент-серверной технологии взаимодействия между АРМ и сервером баз данных, причем клиенты должны быть «тонкими», то есть все основные вычисления (биз­нес-логика) происходят на сервере баз данных или на специализирован­ном сервере приложений, а АРМ конкретных приложений больше ис­пользуются как терминалы, это также гарантирует сохранность и досто­верность данных;

• встроенные возможности администрирования и конфигурирования программного обеспечения, обеспечение защиты от несанкционированного доступа к информации (дополнительно к стандартным возможностям Windows NT и SQL-сервера);

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

• интеграция существующих узлов учета в систему, причем на верхнем уровне это должна быть полная интеграция, то есть единые базы данных, единые АРМ, единые отчеты;

• разделение доступа клиентов (АРМ) к базе данных.

 

17 Разработка структурных схем и схем автоматизации для ЛСУ

 

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

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

В общем случае любая система может быть представлена:

конструктивной структурой;

функциональной структурой;

алгоритмической структурой.

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

В конструктивной схеме присутствуют:

- объект и система автоматизации;

- информационные и управляющие потоки.

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

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

В функциональной структуре каждая часть предназначена для выполнения определœенной функции.

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

Структурная схема АСУ ТП разрабатывается на стадии “Проект” при двухстадийном проектировании и соответствует составу системы.

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

На структурной схеме показывают следующие элементы:

- технологические подразделœения (отделœения, участки, цеха, производства);

- пункты контроля и управления (местные щиты, операторские и диспетчерские пункты, блочные щиты и т.д.);

- технологический персонал (эксплуатационный) и дополнительные специальные службы, обеспечивающие оперативное управление;

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

- взаимосвязь между подразделœениями и с вышестоящей АСУ.

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