СПКД123 / СПДК / Задачи АСУТП / Лекция 8. Диспетчерские пункты АСУТП. Базы данных

Лекция 8. Диспетчерские пункты АСУТП. Базы данных

Содержание лекции:

• Виды применяемых в ДП АСУТП баз данных

• Сравнение характеристик СУБД различных типов

• Адресация к данным в базах данных различных типов 

• Пример проектирования структуры объектно-иерархической базы данных

1. Виды применяемых в ДП АСУТП баз данных

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

• Тэговая база данных состоит из набора объектов (тэгов) – групп данных различных сложных типов, являющихся наборами простых типов. 

• Иерархическая (древовидная) БД – «представляет собой иерархию групп данных, в которой на самом верхнем уровне имеется только одна группа, называемая корнем, и все группы, кроме корня, связаны с одним и только одним узлом, находящимся на более высоком по отношению к ним уровне».

• Реляционная БД – классическая модель организации данных в форме логически связанных между собой отношений.

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

• этап проектирования БД: проектирование структуры, адресация и т.п.;

• связывание хранимых данных с элементами интерфейса, мнемосхемами ТП;

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

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

Базы данных всех систем реального времени (независимо от модели данных) объединяет:

1. Типизация групп данных. Если сама архитектура реляционной базы данных подразумевает хранение однотипных наборов данных в одной области памяти, то в тэговых и древовидных базах данных вводятся специальные «метаобъекты» – классы. 

2. Реализация дополнительных средств хранения признака «достоверности» технологических данных.

3. Наличие механизмов пересчета хранимых агрегированных данных при получении новых значений технологических данных.

^

Сравнение характеристик СУБД различных типов

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

Интегрированность СУБД в систему в целом проявляется двояко: во-первых, данные, хранимые базой данных, активно используются другими программами, как входящими в состав программного комплекса АСУТП, так и ПО «третьих фирм». К первым относятся подсистема визуализации, менеджеры тревог, ввода/вывода. Во-вторых, системным ПО осуществляется постоянный мониторинг работы СУБД. Система управления реляционной базой данных более обособлена и более формализовано взаимодействует с другими компонентами АСУТП, чем тэговые и древовидные СУБД. Вне зависимости от программ, выборка данных осуществляется посредством SQL-запросов. Из литературы известно, что производительность – сильная сторона иерархических СУБД по сравнению с реляционными. Это справедливо и в настоящее время, но для общих задач. Однако, настроив реляционную СУБД специально как сервер базы данных системы управления реального времени с целью максимально ускорить обработку оперативных данных, и разделяя области хранения технологической и нормативно-справочной информации, можно нивелировать архитектурные преимущества. Так, крупный производитель ПО FactorySuite 2000 компания Wonderware утверждает, что производительность используемой ими в качестве ядра реляционной СУБД Microsoft SQL server была повышена более чем в 100 раз для операций над технологическими данными.  Хотя данные, публикуемые фирмами-производителями рассматриваемых систем, нельзя считать объективными, можно ожидать, что производительность всех рассматриваемых систем при решении типовых задач АСУТП вне зависимости от типа БД, при использовании доступных в настоящее время технических средств большой мощности, будет вполне достаточна для функционирования СУБД. Результаты оценки характеристик БД можно свести в таблицу. Для различных систем, имеющих базу данных одного типа, показатели различны, но практически никогда не отличаются кардинально, что позволяет говорить о влиянии именно выбранной модели хранения данных, а не конкретной реализации. Таблица 8.1. Итоговые оценки характеристик СУБД различных типов.

№	Характеристики	^ Модель базы данных
		Иерархич.	Тэговая	Реляционная
1	Архитектура	Отл	Хор	Удовл
2	Интегрированность	Отл	Удовл	Отл
3	Производительность	Отл	Хор	Хор
4	Развитие	Хор	Удовл	Отл
5	Проектирование	Хор	Хор	Отл

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

Адресация к данным в базах данных различных типов

Принципиальное различие баз данных различных типов – в методиках адресации (доступа) к хранимым данным.  Адресация в тэговой БД имеет общий вид «имя_тэга.имя_атрибута», являясь по сути абсолютной адресацией к логическому эквиваленту реального технологического значения (т.к. тэг является логическим эквивалентом технологического объекта, а атрибут – логическим эквивалентом значения датчика). Формирование имен тэгов формализовано, и является кодированием информации о месте объекта в системе (применяется т.н. упорядочивание). Адресация в древовидной БД может быть двух видов – как абсолютной, когда также как и в тэговой БД идет обращение к определенному значению выбранного объекта (атрибута узла древовидной структуры), так и относительной, когда указывается «путь» к элементу группы данных указанием иерархии родительских узлов. Эта особенность позволяет создавать удобный механизм привязки мнемосхем ТП к одним и тем же значениям ТИ и ТС однотипного оборудования (см. лекцию 8). Имена групп данных могут быть заданы явно как имена объектов, т.к. при использовании иерархической адресации (вида ГКС:КЦ1:ГПА3:ДавлениеВходное) не требуется их уникальности в пределах всей базы. Доступ к значениям, хранимым реляционной СУБД, осуществляется стандартным образом, используя SQL-запросы. 

2. ^ Пример проектирования структуры объектно-иерархической базы данных (на примере программного комплекса RTAP/Plus)

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

1. Выделение базовых классов, описывающих технологические объекты.

2. Внутреннее проектирование базовых классов БД. Классы содержат свойства и методы, являющиеся общими для любых представлений технологического объекта.

3. Создание производных от базовых классов, описывающих технологические объекты различных модификаций.

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

При необходимости создать класс-описание еще более частного случая – повторение п. 3, 4. На рис. 8.1 приведен фрагмент иерархии классов. От общего базового класса созданы два производных: «Технологический объект» и «Эксплуатационный участок», описывающие две наиболее абстрактные сущности предметной области. Детализацией эксплуатационного участка являются «Участок газопровода» и «Компрессорный цех». Производным от технологического объекта является, в частности, класс «Кран». Его структура также может быть уточнена, например, класс «Кран ТМ “Магистраль”» содержит специальные атрибуты, которые можно получить только от данной системы телемеханики. Также создаются отдельные классы для телеизмерений, телесигнализаций, ниток и участков трубопровода, контролируемых пунктов, насосных станций и т.д. Рис. 8.1. Фрагмент иерархии классов. Структура класса в СУБД RTAP немного отличается от принятой в языках объектно-ориентированного программирования: определяются свойства (атрибуты) класса, и им может быть сопоставлена некоторая формула; отдельно операции (методы) класса не определяются. Значение атрибута – это результат вычисления формулы; пересчет производится, когда изменяется значение атрибута-аргумента (или поступают актуальные данные от внешних систем).  Таблица 8.2. Структура класса «Кран».

Имя	Тип	Значение	Формула
title *	BYTES(32)
condition	INTEGER	2	[.close] + 2*[.open]
open	LOGICAL	1	SCAN(адрес сигнала)
close	LOGICAL	0	SCAN(адрес сигнала)
quality	INTEGER	1	QUALITY([.open])
time stamp	DATE/TIME	21/02/03 12:14:56	NOW()
manual	LOGICAL	0
manual condition	INTEGER	1

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

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

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

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

На рис. 8.2 приведен фрагмент иерархии объектов – шаблон базы данных, описывающий линейное КП двухниточного магистрального газопровода (МГ). Объекты, описывающие устройства и датчики, объединены под объектом «нитка МГ», который в свою очередь включен в «линейное КП». Данный шаблон типовой подветви сам также содержит две типовые подиерархии, описывающие нитку МГ. При применении объектно-ориентированного подхода к проектированию БД значительно ускоряется разработка мнемосхем. Привязка динамических компонентов изображения технологического объекта к описателю этого объекта в БД, когда все параметры этого объекта иерархически упорядочены в поддереве, позволяет компоновать интерфейс по образцу БД, с наименьшими затратами получая все связанные с ним объектом технологические и производные от них данные. Рис. 8.2. Иерархия объектов  (описывает линейное КП 2-х ниточного МГ). В заключение также нужно отметить, что созданные иерархия классов и библиотека шаблонов обладают следующими преимуществами перед наработками структурного анализа и проектирования:

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

• возможность гибкой компоновки тиражируемых структур объектов.

Лекция 9. Диспетчерские пункты АСУТП. Графический интерфейс Содержание лекции:

• Основные элементы визуального интерфейса диспетчерского пункта АСУТП

• Разработка динамического элемента мнемосхемы

• Разработка и повторное использование мнемосхем. Контекст

1. Основные элементы визуального интерфейса диспетчерского пункта АСУТП

Визуальный интерфейс оператора технологического процесса и, вообще говоря, любого пользователя АСУТП, связанного с производственным процессом, радикально отличается от интерфейса рабочего места специалиста хозяйственной, финансовой и прочих непроизводственных сфер деятельности промышленного и любого другого предприятия народного хозяйства. Если последние используют оконные интерфейсы своих программных комплексов в основном для выполнения определенных действия, то основное время оператор просто наблюдает за состоянием, прохождением технологического процесса. Выделяют четыре типа визуального отображения информации: 1) мнемосхемы; 2) журнал тревог; 3) графики (тренды); 4) отчеты. Мнемосхема современного графического интерфейса пользователя ДП является окном, для которого определяются заголовок, размеры, возможность минимизации/закрытия, фон. Окно является контейнером для элементов управления (кнопок, переключателей, текстовых надписей, пролей ввода и др.), графических примитивов и динамических графических элементов, т.е. таких графических символов мнемосхемы, которые меняют свой внешний вид в зависимости от некоторого набора данных. На мнемосхеме в графическом виде схематично отображают структуру производственного предприятия и технологического процесса; производственное оборудование, средства контроля и автоматизации. При этом вид графического отображения технологических объектов видоизменяется в зависимости от их текущего состояния, в точках установки датчиков отображаются значения аналоговых величин, значения параметров технологического процесса. Для того чтобы отображать не только статическую структуру, подсистеме визуализации требуется устанавливать связи с базой данных, производить выборку информации (при получении от оператора команды – запись значений в БД). При загрузке мнемосхемы выполняется инициализация – установление связей с базой данных, загрузка значений, необходимых каждому динамическому элементу. Далее, в течение времени отображения мнемосхемы, поддерживается актуальность отображаемого состояния, для чего подсистема визуализации с заданной периодичностью запрашивает значения отображаемых технологических параметров или их изменения. По аналогии со структурой базы данных ДП АСУТП, которая в случае использования иерархической СУБД соответствует структуре административно-производственного деления, либо отражает структуру установленных средств автоматизации, «вложенность» мнемосхем АСУТП соответствует делению производства на эксплуатационные или технологические участки, контролируемые пункты и т.п. При переходе на более низкий уровень на отдельной мнемосхеме (в отдельном окне) отображается более подробная схема, на самом нижнем уровне мнемосхема отображает оперативную и паспортную информацию по отдельному объекту.  Журнал тревог (архив сообщений различной степени аварийности) – это также массив ретроспективных данных. В большинстве систем все тревоги последовательно (т.е. упорядоченно по времени возникновения) сохраняются в отдельной выделенной области данных. Параллельно средствами менеджера тревог ведется запись во внешние файлы, отображение на АРМах, распечатка и т.д., при этом возможна фильтрация тревог.  Ключевыми требованиями к журналу тревог являются:

• Сохранение упорядоченных по времени возникновения тревог.

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

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

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

• Диагностику состояния соединения с сервером БД. 

• Переключение между основным/резервным серверами БД ДП АСУТП при пропадании связи.

• Авторизацию пользователей, разграничение прав.

• Масштабирование и печать отображаемых мнемосхем/графиков.

2. Разработка динамического элемента мнемосхемы

В настоящее время существует два подхода к разработке динамических элементов: или производитель ДП АСУТП разрабатывает специализированный графический редактор, в котором можно определять внешний вид элемента и правила его изменения; или окна мнемосхем реализуются как ActiveX контейнеры и тогда разработка динамического элемента сводится к разработке ActiveX компонента с помощью универсального языка программирования.  Независимо от метода, при разработке для каждого динамического элемента сначала определяется перечень свойств, которые влияют на его внешний вид, а также правила изменения вида в зависимости от конкретных значений свойств. Например, для крана (задвижки) на трубопроводе можно определить, что на внешний вид символа влияют следующие свойства: состояние, достоверность, номер, режим управления, режим ввода данных, неподтвержденность (неквитированность оператором после изменения) состояния. В техническом задании может быть приведена требуемый вид символа, неформальный перечень свойств и описание зависимости внешнего вида от его значений (рис. 9.1). Рис. 9.1. Неформальное описание требуемого вида и динамики элемента мнемосхемы. Свойствам символа обычно можно, также на этапе разработки, сопоставить поля объекта базы данных, актуальные значения которых будут использоваться. Такой элемент помещается в библиотеку, и в дальнейшем разработчик должен для каждого размещаемого на мнемосхеме экземпляра элемента указать только имя объекта БД (говорят – «связать элемент мнемосхемы с источником данных, объектом БД»).

2. ^ Разработка и повторное использование мнемосхем. Контекст

Все мнемосхемы графического интерфейса пользователя ДП АСУТП можно разделить на две категории: уникальные и шаблонные. Уникальная мнемосхема отображает состояние какого-либо участка технологического процесса или производственного объекта, существующего в единственном экземпляре на автоматизируемом производстве. Например, каждая мнемосхема, показывающие расположение и текущее состояние сети трубопроводов с привязкой к карте местности, оригинальна. Шаблонная мнемосхема показывает состояние одной из множества типовых технологических площадок, единиц оборудования и т.п.  Далее мы будем оперировать понятием контекста. В иерархически упорядоченных структурах «контейнер-элемент» каждый элемент, который в свою очередь может являться контейнером, своими характеристиками уточняет положение конечного элемента в некоторой «системе координат». Множество свойств объекта-контейнера и является контекстом, в котором существует объект-элемент. Применительно к мнемосхемам АСУТП введение контекста означает уточнение роли каждого устройства, чье состояние отображается некоторым символом, в производственной системе предприятия и, соответственно, уточнение места размещения (способа адресации) области БД, хранящей оперативную информацию о состоянии этого объекта. Рассмотрим пример. На рис. 9.2 изображена мнемосхема, на которой схематично показаны два коридора газопроводов, проходящие по территории некоторого региона, крупные города этого региона. На газопроводах показаны места расположения компрессорных станций (КС). Динамическая информация – состояние связи центральной диспетчерской с каждой из КС, а также объем газа, прокачанный по газопроводам в западном и южном направлениях с начала суток.  В этом случае, для страницы (мнемосхемы) контекст – корневая точка БД (:Газопроводы). Для каждого из символов КС указан уникальный относительный путь к объекту БД, например (:А-Б:КС14:Связь). При этом при создании символа было определено, что на его внешнее отображение влияет значение атрибута .состояние связанного объекта БД. Тогда при загрузке мнемосхемы будет для каждого динамического объекта будет проведено объединение контекстов контейнера (страницы), собственно объекта и используемого атрибута, в результате чего будет сформировано множество адресов БД. EMBED Visio.Drawing.6  Рис. 9.2. Мнемосхема общего вида газотранспортной  системы региона. Каждому символу КС на мнемосхеме рис. 9.2 сопоставлено действие – при щелчке мышью происходит открытие мнемосхемы, показывающей технологическую схему КС (рис. 9.3). Поскольку технологические схемы всех КС одинаковые (учебное допущение), мы можем использовать шаблонную мнемосхему, и при вызове передать в нее идентификатор КС (относительный путь к объекту КС в БД), состояние которой требуется отобразить.  Тогда, контекст страницы будет иметь вид (:Газопроводы:А-Б:КС17). Контексты кранов имеют вид :КЦ1:Кран20. В этом случае, поскольку формирование полных адресов БД происходит при загрузке мнемосхемы и структуры деревьев БД, описывающих различные КС, одинаковы, передача другого контекста страницы при ее вызове приведет в загрузке набора данных, характеризующих состояние другой КС, без изменения самой мнемосхемы или каких-либо ее настроек. Рис. 9.3. Мнемосхема состояния узла подключения  компрессорной станции. Далее, чтобы просмотреть справочную (паспортную) информацию по определенному крану КС или подать на него команду управления, требуется открыть мнемосхему второго уровня вложенности – шаблонную мнемосхему, окно, отображающее полную информацию по определенному объекту (рис. 9.4). При этом странице-контейнеру будет передан контекст – относительный адрес в иерархической БД вида:Газопроводы:А-Б:КС17:КЦ1:Кран7. Тогда подсистема визуализации, добавив к нему пустой контекст динамического символа крана, а затем имена свойств объекта БД, влияющих на его отображение, такие как .состояние, .номер и др., сформирует множество адресов БД, по которым будут запрошены данные для визуализации из конкретного объекта БД.  Рис. 9.4. Мнемосхема, отображающая полную информацию о технологическом объекте, и соответствующий объект БД.