Добавил:

ivanov666 Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Башкирский Государственный Аграрный Университет

Предмет:

[НЕСОРТИРОВАННОЕ]

Файл:

Основы автоматизированных систем управления. Учебное пособие

.pdf

Скачиваний:

Добавлен:

07.09.2026

Размер:

2 Мб

Скачать

☆

<<< < Предыдущая 1 2 3 4 5 6 78 / 138 9 10 11 12 13 > Следующая >>>

Глава 4. Организация информационного обеспечения

Рис. 4.3. Последовательность выполнения процедур

Слот S

Фрейм F

рейм F

Фрейм F

(j+n) вертикаль (i+1) уровня структуры

параллельное означивание

j вертикаль (i+1) уровня структуры

(i+1) уровень структуры

Запуск демонов «если-

нужно» слотов S ..S

фрейма F (одно-

временно под управлением процедуры параллельного означивания)

Выполнение процедур означивания фреймов F

..F

Запуск процедуры означива-

ния фрейма F из демона «если-нужно» вышестоя-

щего фрейма

i уровень структуры

Слот S

Фрейм F

(j+n) вертикаль (i+1) уровня структуры

j вертикаль (i+1) уровня структуры

(i+1) уровень

Перезапуск процедуры озна-

чивания фрейма F

Запуск демонов

«если-добавлено» слотов

S ..S

Запуск демона «если-добав-

лено» слота S фрейма F

i уровень структуры

Фрейм F 4:

Основы автоматизированных систем управления

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

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

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

 возможность восстановить последовательность выполнения про- цедур при отладке процесса порождения данных;

 возможность унифицировать процедуры для дальнейшего иссле- дования свойств полученной базы данных.

ОРГАНИЗАЦИЯ ВНУТРИМАШИННОЙ

ИНФОРМАЦИОННОЙ БАЗЫ

Описание принципов построения внутримашинной информационной базы, характеристики ее состава и объема

К внутримашинным информационным структурам относятся элементы 3…7 уровней. Уровни 3, 4 реализуются АС НУ, уровни 5…7 – АС ВУ. На основе фрейма-прототипа построим фрейм-модель, как показано на рис. 4.4.

На нижнем и верхнем уровне существуют три фрейма-модели, которые отличаются только составом слотов субвершины объектов (составом входных сигналов):

 фрейм-модель куста скважин;

 фрейм-модель ДНС;

 фрейм-модель КНС.

На однотипный сигнал ТОУ выделяется один слот субвершины объектов (тэг). Например, сигналам «включение насосов» всех ЭЦН всех кустов соответствует один тэг. «Подстановкой» конкретных сигналов занимается процедура управления параллельным означиванием.

Глава 4. Организация информационного обеспечения

Рис. 4.4. Фрейм-модель

Описание структуры внутримашинной информационной базы

При построении информационной модели управления ТП ЦДНГ в виде фреймовой сети часть данных, составляющих внутримашинную информационную базу системы, означивает слоты фрейм-моделей куста скважин, ДНС и КНС. Так, параметры ТП, команды изменения параметров ТП и команды управления выступают в качестве слотов субвершины объ-

корень

слот-выходной пакет

статус-слоты

слот-массив уставок

слот-промежуточный

массив

слот-сигнал с датчика

слот-сигнал с исполни-

тельного механизма

слот-сигнал аварии

слот-сигнал на испол-

нительный механизм

задачи каналов

процессор

процессор передачи

автотестер

процессор приема

селектор, кодер

Исполнительный

процессор

слот-входной пакет

Основы автоматизированных систем управления

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

Для выполнения таких функций АС, как визуализация ТП, архивирование оперативных данных ЦДНГ и ведение отчетной документации на верхнем уровне системы вводятся три дополнительные служебные фрейммодели:

 фрейм-модель видеокадра;

 фрейм-модель отчета;

 фрейм-модель архива ЦДНГ.

Фрейм-модель видеокадра имеет несколько экземпляров, соответствующих видеокадрам, описанным в документе «Составе выходных данных». Слотами данной фрейм-модели являются:

 экранная форма (означивается из массива экранных форм);

 объект тревог/событий;

 динамика поведения параметров ТП;

 исторический тренд;

 информационные слоты, которые представляют собой тэги тексто-

вых сообщений, либо поступающих на РСт или ППОТ, либо формируемых на РСт или ППОТ);

 флаг активности (1 – находится в данный момент на экране РСт или ППОТ, 0 – нет).

Фрейм-модель отчета имеет несколько экземпляров, соответствующих выходным документам “Перечня выходных документов”. Слотами данной фрейм-модели являются:

 стандартная печатная форма (означивается из массива стандарт- ных печатных форм);

 произвольная печатная форма (означивается из массива произ- вольных печатных форм);

 текстовая информация.

Слотами фрейм-модели архива являются:

 идентификатор файла-журнала;

Глава 4. Организация информационного обеспечения

 архивируемые данные реального времени (запись), фиксируемые в

файл-журнале;

 преобразованная архивная информация из журнала (запись), фик-

сируемая в исторической БД ЦДНГ.

Скрипты InTouch выступают в роли процедурных компонентов и де-

монов фрейм-моделей.

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

Тип Memory Real. Для данного типа могут быть означены следующие поля:

 Name – имя тэга;

 Comment – строка комментария;

 Value – значение тэга;

 MinEU, MaxEU – минимальное и максимальное значения, которые

может принимать значение тэга;

 Normal – флаг, который устанавливается в единицу тогда, когда не определено тревожное состояние параметра, описываемого данным тэгом;

 Alarm – флаг, который устанавливается в единицу тогда, когда определено тревожное состояние параметра, описываемого данным тэгом;

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

 Ack – флаг, который используется для отображения и/или контроля состояния (нормальное или тревожное) тэга;

 AlarmValDeadband – отклонение от верхней границы (MaxEU) и нижней границы (MinEU) значения тэга в процентах, когда производится идентификация тревожного события;

 HiHiStatus, HiStatus, LoStatus, LoLoStatus – флаги, устанавливае- мые в единицу при определении соответствующего класса тревоги для данного тэга;

 HiHiLimit, HiLimit, LoLimit, LoLimit – предельные значения пара- метра, описываемого данным тэгом, которые характеризуют определенный класс тревог;

Основы автоматизированных систем управления

 AlarmDevDeadband – отклонение от целевого значения тэга, задан-

ного DevTarget, когда производится идентификация тревожного события;

 DevTarget – в этом поле задается целевое значение тэга;  MinorDevStatus, MajorDevStatus, ROCStatus – флаги, которые уста-

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

 MinorDevPct, MajorDevPct, ROCPct – верхняя и нижняя границы

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

Тип DDE Real. Для данного типа могут быть означены те же поля,

что и для Memory Real, а также задается следующая информация:

 RDWRFlag – флаг, который указывает, что для чтения или записи

предназначен тэг;

 Application – идентификатор приложения, предоставляющего дан-

ные. Если значение данного тэга передается внешним приложениям, то здесь задается идентификатор Runtime-программы InTouch. Если в значение тэга записывается данное, поступающее от внешнего приложения, то здесь задается имя данного приложения;

 Topic – имя тэга/имя раздела внешнего приложения;  Item – имя тэга/имя переменной внешнего приложения.

Тип DDE Integer. Для данного типа могут быть означены те же поля,

что и для Memory Real.

Тип DDE Discrete. Для данного типа могут быть означены следующие поля: Name, Comment, Value, Normal, Alarm, AlarmEnabled, Ack, RDWRFlag, Application, Topic, Item. Их смысловое значение совпадает с указанным для типа DDE Real.

Тип DDE Message. Для данного типа могут быть означены следующие поля: Name, Comment, Value, Normal, Alarm, AlarmEnabled, Ack, RDWRFlag, Application, Topic, Item. Их смысловое значение совпадает с указанным для типа DDE Real.

Тип Tag ID. Для данного типа могут быть означены поля Name и Comment. Их смысловое значение совпадает с указанным для типа DDE Real.

Глава 4. Организация информационного обеспечения

Тип Hist Trend. Для данного типа могут быть означены поля Name и Comment, смысловое значение которых совпадает с указанным для типа DDE Real, а также следующие поля:

 ChartLength – период времени, отображенный на графике;

 ChartStart – время начала построения тренда и/или период скрол-

лирования графика вправо;

 DisplayMode – идентифицирует метод вычисления значения пара- метра, отображаемого на тренде (минимальное/максимальное/среднее значение в течение определенного периода времени);

 MaxRange, MinRange – максимальное и минимальное значения, ко- торые могут принимать тэги при отображении на тренде;

 UpdateCount – счетчик, значение которого уменьшается, когда пе- редача значений тэгов на тренд завершена;

 UpdateInProgress – флаг, который установлен в единицу, когда пе- редача данных на тренд еще не завершена;

 UpdateTrend – флаг, который установлен в единицу, когда необхо- димо обновить изображение диаграммы исторического тренда;

 ScooterLockLeft, ScooterLockRight, ScooterPosLeft, ScooterPosRight

– используются для создания полосы прокрутки данного тренда;

 Pen1, Pen2, Pen3, Pen4, TagID – идентифицируют тэги, значения которых отображаются на тренде.

Тип Group Var. Для данного типа могут быть означены следующие поля: Name, Comment, Value, Normal, Alarm, AlarmEnabled, Ack. Их смысловое значение совпадает с указанным для типа Memory Real.

Взаимосвязь информационных массивов данных приведена в документе «Описание организации информационной базы».

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

Описание решений, обеспечивающих информационную совместимость АС с другими системами управления

С целью обеспечения информационной совместимости проектируемой АС со смежными системами и системами верхнего уровня иерархии

Основы автоматизированных систем управления

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

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

Основные трудности совместимости при реализации модели клиент/сервер, в основном, связаны с тем, что при интеграции комплексных информационных систем необходимо учитывать особенности различных сетевых уровней данной модели: аппаратуры, топологии, ОС, а также системы коммуникаций между клиентской и серверной частями, работающими на разных компьютерах. Также необходимо учитывать факт, что в результате развития единого информационного пространства ОАО «Кантигирнефтегаз», в силу определенных экономических либо других факторов, в его составе могут сосуществовать неоднородные компоненты (например, серверы БД Oracle127 и IBM DB2020 или др.)

Для обеспечения совместимости в рамках концепции единого информационного пространства ОАО «Кантигигнефтегаз» приняты следующие решения

Использовать при разработке приложений систем клиент/сервер инструментальные средства и серверы БД, поддерживающие стандартные

Глава 4. Организация информационного обеспечения

прикладные программные интерфейсы (API) промежуточного программного обеспечения, такие как Open Database Connectivity (ODBC) и Integrated

Database Application Programming Interface (IDAPI.)

Системы клиент/сервер используют промежуточное программное обеспечение – уровень программных средств, облегчающих коммуникации различных компонентов системы с распределенной обработкой. Промежуточное программное обеспечение находится на клиентах и серверах системы клиент/сервер и транслирует передаваемые между ними сообщения. Это так называемые программные шлюзы баз данных, делающие возможным «общение» серверов БД разных поставщиков в неоднородных информационных системах. Промежуточное программное обеспечение стандартизует API между клиентскими приложениями и различными типами серверов БД (Oracle127, SQL Server, Informix, Microsoft SQL Server и др.). В контексте клиент/сервер API представляет собой спецификацию набора функций, которые позволяют взаимодействовать клиенту и серверу. Примерами стандартных API являются ODBC и IDAPI. ODBC – стандартный протокол, который обеспечивает присоединение приложений к различным внешним серверам или файлам баз данных. Использование ПО, поддерживающего стандартные API промежуточного программного обеспечения, позволяет использовать вместо специального любой внутренний сервер БД, т. е. появляется возможность выбора сервера БД. Если необходимо переключаться с Oracle127 на Sybase SQL Server, Informix, Microsoft SQL Server и т. д. (или наоборот), то благодаря поддержке этими серверами БД стандартных API приложения будут продолжать функционировать без модификации. Допускается импорт или связывание данных из баз данных ODBC, а также других приложений, совместимых с протоколом ODBC.

Использовать при разработке приложений систем клиент/сервер инструментальные средства и серверы БД, поддерживающие стандарт

ANSI/ISO SQL-921 (Structured Query Language). Поддержка стандарта ANSI/ISO SQL-921. позволяет пользователям и приложениям баз данных SQL-типа идентично работать со многими различными реляционными сер-

верами БД. Инструкции на языке SQL обычно используются в запросах и статистических функциях, но также могут применяться для создания или изменения структуры базы данных. SQL является непроцедурным языком.

Основы автоматизированных систем управления

С помощью инструкций просто сообщается, что нужно сделать серверу БД и каким образом. Сервер для обработки запроса транслирует инструкции SQL во внутренние процедуры. Применение SQL особенно полезно в СУБД клиент/сервер, поскольку позволяет выполнять большую часть обработки данных не в клиентском приложении, а на сервере. В итоге, благодаря уменьшению передачи данных между клиентом и сервером улучшается производительность системы и обеспечивается информационная совместимость при подключении клиентов к разным серверам БД (Oracle127, Sybase SQL Server, Informix, Microsoft SQL Server и т. д.). С учетом неоднородности систем клиент/сервер особенно важным качеством промежуточного ПО стандартного SQL является его свойство скрывать сложности сети, – оно работает почти с каждой ОС и коммуникационным протоколом и не зависит от применяемой сетевой топологии; проектирование систем клиент/сервер может происходить без учета применяемых протоколов, компьютеров и операционных систем.

Производить подбор и написание для совместной работы в составе ПО АС приложений (коммуникационных пакетов, текстовых редакторов, электронных таблиц, СУБД и т. д.), отвечающих требованиям полной совместимости с форматом Win32 и поддерживающих обмен данными посредством стандартных механизмов OLE и DDE.

Совместимость программных продуктов формату Win64 гарантирует их корректное совместное функционирование в ОС Windows, являющейся базовой ОС (БОС) АС.

Механизм управления OLE (object linking and embedding) является стандартной промышленной технологией, которую используют приложения, для того чтобы предоставить свои объекты OLE в распоряжение разработчиков, макроязыков и других приложений, поддерживающих механизм управления OLE. Это позволяет проводить обработку этих объектов с помощью методов этих объектов или с помощью чтения или установки свойств этих объектов.

OLE реализует два метода обмена данными между документами, созданными в разных приложениях, – связывание и внедрение. Основное отличие между связыванием и внедрением состоит в том, как данные запоминаются и обновляются, после того как их поместили в документ.

<<< < Предыдущая 1 2 3 4 5 6 78 / 138 9 10 11 12 13 > Следующая >>>

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]