Добавил:

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

Вуз:

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

Предмет:

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

Файл:

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

.pdf

Скачиваний:

Добавлен:

07.09.2026

Размер:

2 Мб

Скачать

☆

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

Глава 3. Эскизный проект. Общесистемные решения

Периодичность и объем обновления данных зависит от особенно-

стей технологического процесса и возможностей каналов связи.

Резервные копии информации ОБД ЦДНГ хранятся на сменных маг-

нитных носителях.

Входные документы для системы оформляются в печатном виде

путем заполнения стандартных форм и утверждения в установленном порядке. Допускаются входные документы на машинных носителях информации или полученные по каналам компьютерной связи, оформленные в соответствии с ГОСТ 6.10.4 и имеющие юридическую силу.

Выходными документами системы являются отчеты произволь-

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

Допускается обмен сообщениями между диспетчером и НГДУ,

службами ЦДНГ, диспетчером и ППОТ.

3.9. Решения по составу программных средств, языкам деятельно-

сти, алгоритмам процедур и операций и методов их реализации

Перечень покупных программных средств

Для НУ:

 система автоматизации программирования;  операционная система-монитор (входит в комплект поставки ТК);  драйверы обмена с ВУ (входят в комплект поставки ТК);  драйверы ретрансляции (входят в комплект поставки ТК).

Для ВУ:

 средство разработки ПО АСУ ТП класса SCADA;  многозадачная сетевая операционная система;  набор серверных программ для интеграции системы с внешними АСУ.

Прикладные программные средства ВУ должны выполняться на

любых IBM-совместимых компьютерах в соответствии с требованиями к техническому обеспечению.

Программное обеспечение должно быть построено на основе

функционально законченных программных модулей, проектироваться по технологии, допускающей его верификацию (в том числе CASE-технологии), включать в себя процедуры, поддерживающие стандартные механизмы DDE и SQL/ODBC.

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

Использование средства разработки ПО АСУ ТП класса SCADA

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

Перепрограммирование ТТ осуществляется инструментальными средствами, соответствующими стандарту IEC 1131-3.

Алгоритмы процедур:

 алгоритм мониторинга ТОУ;

 алгоритмы взаимодействия с ВУ;

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

с аналоговых и импульсных датчиков;

 математические модели и алгоритмы реализации управляющих воздействий;

 алгоритмы ретрансляции;

 алгоритмы автотестирования;

 алгоритмы обслуживания ППОТ;

 модель разграничения доступа и защиты информации;

 алгоритмы обслуживания аварийных ситуаций.

Модели ВУ:

 имитационная модель ТП;

 модель защиты информации;

 модель сетевого взаимодействия и распределенной обработки дан-

ных;

 модель данных, определяющая структуру оперативной базы дан- ных ЦДНГ.

Разрабатываемые алгоритмы:

 алгоритмы обработки событий;

 алгоритмы первичной обработки информации;

 алгоритмы экстраполяции технологических параметров по косвен-

ным измерениям на основе стандартных методов;

 алгоритмы статистического анализа параметров ТП;

 алгоритмы обмена данными в реальном времени между ОБД

ЦДНГ и внешними базами данных;

Глава 3. Эскизный проект. Общесистемные решения

 алгоритмы генерации отчетов и протоколов по произвольной

форме на основе текущей и архивной информации.

Типовые алгоритмы:

 алгоритмы преобразования данных (интерполяция, масштабирова-

ние и пр.);

 алгоритмы построения объектно-ориентированного MMI-интерфейса;  алгоритмы администрирования БД.

4. Мероприятия по подготовке объекта автоматизации к

вводу системы в действие

4.1. Мероприятия по приведению информации к виду, пригодному

для обработки на ЭВМ

Приведение поступающей информации в систему к виду, пригодному для обработки с помощью ЭВМ, производится аппаратно-программными средствами ТТ.

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

Измерение импульсных сигналов заключается в подсчете числа импульсов за заданное время и переводе суммы импульсов в физическую величину.

Аварийные сигналы поступают от датчиков ТОУ. Информация об аварийных сигналах передается на ВУ для дальнейшей обработки.

Часть аварийных сигналов может обрабатываться средствами местной автоматики, не входящими в систему.

4.2. Обучение и проверка квалификации персонала производится

разработчиком системы по согласованию с заказчиком.

4.3. Изменение штатно-должностного расписания производится за-

казчиком по предложению разработчика системы.

4.4. Мероприятия по изменению объекта автоматизации не преду-

сматриваются.

4.5. Другие мероприятия, исходящие из специфических особенно-

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

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

5. Очередность создания системы и объем каждой очереди

5.1. Демонстрационный прототип создается для проверки пра-

вильности основных проектных решений, алгоритмов обработки информации и отработки программного обеспечения ВУ системы, подсистемы связи ВУ с НУ (частично), подсистемы обмена с внешними базами данных. Для этого у разработчика создается аппаратно-программный комплекс, полностью выполняющий функции ВУ системы и основанный на технических и программных средствах, предлагаемых к установке в ЦДНГ пласта ХХ-9 Борусовского месторождения, а также разрабатывается программная модель НУ системы, функционирующая на отдельной ЭВМ. Кроме того, создается подсистема связи по проводным каналам между ВУ и НУ.

5.2. Исследовательский прототип создается для отладки про-

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

5.3. Опытный образец – в нем, в отличие от исследовательского

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

5.4. Ввод в эксплуатацию осуществляется расширением опытного

образца путем последовательного подключения ТОУ ЦДНГ и отладки системы. В приложении приводятся таблицы, являющиеся более детализованным представлением соответствующих разделов ТЗ.

Глава 3. Эскизный проект. Общесистемные решения

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

Приложения

ГЛАВА 4

ОРГАНИЗАЦИЯ ИНФОРМАЦИОННОГО ОБЕСПЕЧЕНИЯ

Принципы построения информационного обеспечения

1. Наиболее важной проблемой, от правильного решения

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

 возможность содержательной интерпретации элементарной струк-

туры представления;

 соответствие структур представления смысловым структурам

предметной области;

 возможность естественного разбиения структуры представления

на простые элементы, которым можно сопоставить величину или фактор с некоторым значением;

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

нент;

 удобство приведения других типов представления к выбранному

базовому типу;

 сохранение основных преимуществ других типов представлений

после приведения к выбранному типу;

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

ных;

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

матов;

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

Кроме того, при определении модели данных необходимо исходить из того, что проектируемая АС содержит более 20 тысяч входных и выходных сигналов данных со стороны ТОУ. Все эти сигналы проходят восемь

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

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

Рис. 4.1. Граф порождения данных

Уровень 1. Сигнал с источника информации по месту  сигнал на

исполнительный механизм.

Уровень 2. Сигнал на информационном входе ТТ  сигнал на

управляющем выходе ТТ.

Уровень 3. Элемент внутреннего представления сигнала  элемент внутреннего представления команды (ребро <C, X> представляет процесс самостоятельного порождения решения контроллером без участия ВУ).

Сигнал с источника информац

ии по месту

Сигнал на

информационн

ом входе ТТ

Элемент внутреннего представлен

ия сигнала

Элемент

массива данных для

передачи

или

ретрансляц

ии на ВУ

Элемент принято

го ВУ

массива

данных

Элемент внутреннего представлен

ия сигнала

ВУ

Элемент

отчета

(видеокадр

а)

Элемент докумен

та

A B C D E F G

Z Y X W V U T

Сигнал на

исполни-

тельный

механизм

Сигнал на

управляющем

выходе ТТ

Элемент внутреннего

представле-

ния ко-

манды

Элемент

массива

принятых

команд или

команд для

ретрансля-

ции

Элемент массива

для пе-

редачи

на НУ

Элемент внутреннего

представле-

ния ко-

манды ВУ

Команда

(запрос)

диспет-

чера

Элемент

приня-

того ре-

шения

1 уро-

вень

2 уровень

3 уровень

4 уровень

5 уро-

вень

6 уровень

7 уро-

вень

8 уро-

вень

ТОУ

ТТ

ЦДНГ

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

Уровень 4. Элемент массива данных для передачи на ВУ  элемент

массива принятых команд.

Уровень 5. Элемент принятого ВУ массива данных  элемент массива для передачи на НУ (вершина DW представляет порождение данных на терминале-объекте ретрансляции).

Уровень 6. Элемент внутреннего представления сигнала ВУ  элемент внутреннего представления команды ВУ.

Уровень 7. Элемент отчета (видеокадра)  команда (запрос) диспетчера.

Уровень 8. Элемент документа  элемент принятого решения.

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

Наиболее удобной моделью для закладки основ единого информационного пространства НГДУ представляется фреймовая модель данных.

2. Фрейм объединяет в себе иерархическую структуру при-

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

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

В общем виде фрейм-прототип модели данных изображен на рис. 4.2.

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

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

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

Рис. 4.2. Процедурные компоненты фреймовой сети

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

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

 пользователем при инициировании порождения данных в АС;

 внешней по отношению к фреймовой сети процедурой;

 внутренней процедурой-демоном «если-нужно» фрейма, стоящего

в иерархии выше, по отношению к данному;

 внутренней процедурой-демоном «если-добавлено» фрейма, стоя- щего в иерархии ниже (повторный запуск).

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

Процедура означивания

Корень

Процедура

управления

параллельным

означиванием

Внешняя процедура

Присоединенная процедура

если-удалено

если-добавлено

если-нужно

Демоны

Слот

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

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

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

 сообщение пользователю о текущих событиях;

 диалог с пользователем при отладке фреймовой сети;

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

 взаимодействие с внешней базой данных;

 визуализация процесса порождения данных.

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

Основной задачей процедур-демонов типа «если-добавлено» является сообщение другим процедурам о том, что интересующий их атрибут получил конкретное значение, или передача значения этого атрибута другим процедурам.

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

При проектировании процессов порождения данных инженер по знаниям может пользоваться процедурами из стандартной библиотеки или проектировать собственные процедуры, обязательная последовательность выполнения которых показана на рис. 4.3.

3. Набор процедур фреймовой сети должен удовлетворять

следующим требованиям:

 полнота по отношению к выбранному способу вывода (т. е. кон- кретный процесс можно представить последовательностью процедур из данного набора);

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

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