Диссертация (Модели и алгоритмы автоматизации пожаровзрывоопасных поточно-транспортных систем), страница 9
Описание файла
Файл "Диссертация" внутри архива находится в папке "Модели и алгоритмы автоматизации пожаровзрывоопасных поточно-транспортных систем". PDF-файл из архива "Модели и алгоритмы автоматизации пожаровзрывоопасных поточно-транспортных систем", который расположен в категории "". Всё это находится в предмете "технические науки" из Аспирантура и докторантура, которые можно найти в файловом архиве АГПС. Не смотря на прямую связь этого архива с АГПС, его также можно найти и в других разделах. , а ещё этот архив представляет собой кандидатскую диссертацию, поэтому ещё представлен в разделе всех диссертаций на соискание учёной степени кандидата технических наук.
Просмотр PDF-файла онлайн
Текст 9 страницы из PDF
Технологический узелТехнологический узел формализуется как программный логический блок,который принимает команды и осуществляет диспетчеризацию технологическимоборудованием, принадлежащим технологическому узлу.Алгоритм обработки технологического узла в данной модели распределенмеждуполномочиямитехнологическогооборудованияивнешнейдиспетчеризацией для него самим технологическим узлом. Такое разделениеполномочий позволяет осуществить принцип динамических маршрутов. Принципдинамических маршрутов заключается в том, что технологическое оборудование75статически не связано ни с каким другим оборудованием для работы втехнологическом узле, пока такой узел не запуститься в работу с верхнего уровня.Это позволяет иметь много разных (созданных заранее на верхнем уровне)технологическихузлов,которыемогутиспользоватьодноитожетехнологическое оборудование для решения разных технологических задач вразное время.
Технологический узел, через команды диспетчеризации сообщаеттехнологическому оборудованию, входящему в технологический узел, чтонеобходимо выполнить.На рис. 3.5 представлен блок памяти для технологического узла.Переменная приема командПеременнаяПамять длятехнологическогооборудованиясостояниятехнологическойцепочкиПеременная для диспетчеризацииоборудованием в цепочкеДинамические переменныетехнологической цепочкиРис.
3.5 Блок памяти с данными технологического узла.Возможные команды диспетчеризации:монтироватьсятехнологическоевтехнологическуюоборудование,котороецепочку-назначилипонаэтойкомандеконкретнуютехнологическую цепочку и ему указали динамические связи с другимоборудованием, должно либо сообщить об удачном монтировании (готовности кработе в технологическом узле) либо о невозможности работы в технологическомузле в этот состоянии. Соответственно, технологический узел сообщит в своемсостоянии об отказе в готовности к работе либо об удачном монтировании всеготехнологического оборудования.
При удачном монтировании в технологическийузел технологическое оборудование перестает выполнять команды управления отверхнего уровня (оператора), противоречащие работе технологического узла;размонтироваться из технологической цепочки - по этой командетехнологическое оборудование размонтируется из технологического узла и готовок управлению от команд верхнего уровня (оператора);76запуститься по правилам промышленной безопасности - по этой командетехнологическое оборудование с учетом динамических связей с оборудованием,подающим и принимающим продукт, приступает к запуску по правилампромышленнойбезопасности.Длятранспортировкисыпучихпродуктоввыполняются правила ПБ-14-586-03, где запуск технологического оборудованиядолжен начинаться с последнего оборудования в технологической цепочке. Длятранспортировкижидкихпродуктоввыполняютсяправилабезопасностихимических и нефтехимических производств, на которых для запуска необходимооткрыть запорную арматуру в трубопроводах;остановиться по правилам промышленной безопасности - по этойкоманде начинается остановка технологического оборудования и выполняется также, с требованиями промышленной безопасности;подготовиться к перемонтажу технологической цепочки - по этойкомандекаждоетехнологическоеоборудованиепроверяетвозможностьдинамического перемонтирования (связывания) по новым связям, не меняя своесостояние в текущих условиях и не прекращая контроль за своей работой всоставе технологического узла и сообщает об этом блоку технологического узла;произвести перемонтаж технологической цепочки - по этой команде всетехнологическое оборудование в составе конкретного технологического узла втечении одного контроллерного цикла принимает новые параметры динамическихсвязей в составе технологического узла;аварийно размонтироваться - по этой команде все технологическоеоборудование выходит из состава технологического узла в экстренном режиме (нештатном режиме).Для обеспечения эффективности в использовании ресурсов при эксплуатациитехнологических узлов предусмотрен контроль за количество-качественнымипараметрами: количество продукции созданной, переваленной, отгруженной,принятой и т.д., потраченной электрической энергии.77Для«узкихспециалистов»(энергетиков,экологовидр.)созданыспециальные зависимые счетчики моточасов (наработки) транспортного илиперерабатывающего оборудования и вспомогательного (аспирационного).3.6.
Редактор конфигурации АСУ ТПРедактор конфигурации АСУ ТП, как это следует из структурной схемы ПТК(рис.2.7) и описания постановки его разработки, «работает» с базой данных, вкоторой имеются все необходимые прототипы (контроллеры, модули УСО,технологическое оборудование, устройства (драйверы), технологические датчикии каналы). Для создания конфигурации «в ручную» необходимы исходныеданные (технологическая схема, Техническое задание на АСУ ТП и таблицаподключений).
Для получения конфигурации из проекта в электронном виде(AUTOCAD, E-PLAN) необходимо добавить нужный макрос в среду разработки ивыполнить его. В результате выполнения макроса будет создана необходимаяконфигурация, которая может быть открыта в редакторе конфигурации длядальнейшей настройки в соответствии с Техническим заданием на АСУ ТП.3.6.1. Диалоговый режим и визуализацияРис.3.6 – Скриншот окна конфигуратора78Вся рабочая область редактора разбита на три основных окна («Деревопроекта»,«Свойства»и«Информация»)ипанелейинструментовссоответствующими ярлыками («Конфигурация», «Контроллер», «Оборудование»,«WinCC», «Проверка» и «История»). При выборе элемента в «Дереве проекта»область «Свойства» соответственно представляет допустимые параметры дляэтого объекта. На рис.
3.6-3.8 показаны окна редактора конфигураций.«Дереворасположенияпроекта»полностьюинформациивповторяеттехнологическомструктуру(древовидную)контроллере.Интуитивнопонятный интерфейс для ввода и редактирования данных позволяет легкоопределить, как добавлять оборудование, устройства и датчики.Рис. 3.7 - Скриншот окна для контроллеровОтличительной особенностью является создание технологических связей,которые для контроллеров являются динамическими, а для конфигурациипрактическисоставляют«скелет»объекта,которыйопределяетсявтехнологической схеме. Технологическая связь – это совокупность состояния79оборудования с использованием определенной командыи направлениемдвижения продукта к следующему оборудованию с этой командой [22].Редактор конфигурации состоит из одного программного модуля, и базыданных с конфигурацией, а в результате генерации метаданных проекта редакторсоздает несколько папок (OS и папки с именами контроллеров в конфигурации) сфайлами для верхнего и нижнего уровня соответственно.Для нижнего уровня, для каждого контроллера это:devconfig.xml – метаданные технологического оборудованияdrconfig.xml – метаданные для простых устройств (драйверов)dcinpconfig.xml – метаданные для датчиков дискретного вводаdcoutconfig.xml – метаданные для каналов дискретного выводаdbinpconfig.xml – метаданные для граничных значений вводаdboutconfig.xml – метаданные для граничных значений выводаacinpconfig.xml – метаданные для аналогового вводаacoutconfig.xml – метаданные для аналогового выводаicinpconfig.xml – метаданные для целочисленного вводаicoutconfig.xml – метаданные для целочисленного выводаРис.
3.8 - Скриншот окна для настройки WinCC80Для верхнего уровня (папка OS) это:tritera.xml – метаданные всех ресурсов проекта АСУ ТПtagengine_tritera.xml – метаданные для импорта данных в SCADA WINCC3.6.2. Методология загрузки конфигурацииДля загрузки конфигурации верхнего уровня достаточно разместить файлы сметаданными проекта «верхнего уровня» в основной папке с исполняемымимодулями (указывается при инсталляции ПО верхнего уровня).Загрузканижнегоуровняметаданнымипроектазависитоттипатехнологического контроллера и производителя:1-й способ (для любых контроллеров). После загрузки конфигурацииверхнего уровня, основной программный модуль (Dispatcher.exe) проверяетналичие метаданных во всех контроллерах системы через специальный признакналичия метаданных в контроллере.
Если конфигурационных данных нет, томодуль начинает наполнять все блоки памяти метаданными для каждогоконтроллера и после окончания загрузки конфигурации взводит специальныйпризнак о наличии конфигурации и контроллер приступает к своей обычнойработе. Такая загрузка производится для всех контроллеров АСУ ТП имеющиесяв конфигурации объекта2-й способ (для контроллеров с наличием ОС). С помощью любойимеющийся программой для приема-передачи файлов по протоколу FTPнеобходимо записать метаданные для каждого контроллера в каждый контроллер.Контроллер сам обнаруживает наличие новых метаданных и загружает (либоперечитывает) новые метаданные и после окончания ввода новых метаданныхсамостоятельно приступает к обычной работе.3.7. Основной модуль верхнего уровняОсновной модуль верхнего уровня – это СОМ-сервер Dispatcher.exe.
Этотмодульсоединяетсясовсемиконтроллерамиконфигурации,загружаетметаданные верхнего уровня и устанавливает связь со всеми необходимымиблоками памяти контроллера для передачи команд и чтения всех необходимых81данных. Этот модуль использует объектно-ориентированное программирование.Он написан на языке С++. С использованием программных интерфейсов онпозволяет присоединиться к себе любой программе с использованием СОМтехнологий. Вторая его функция – это взаимодействие со SCADA системами.3.8. Модуль SCADA WINCCНа рис. 3.8 приведена мнемосхема одного экрана SCADA WINCC дляобъектаавтоматизацииприема,храненияитранспортировкисельскохозяйственного сырья.Рис.3.9 – Скриншот окна результирующей мнемосхемыДля обеспечения работы системы SCADA с основнымDispatcher.exe внутри проекта WINCC созданы следующие модули:82модулемВнутренние теги WinCCИнформация о пользователеИнформация о пользователе, выполнившем вход в систему, находится в группе тегов«CurrentUser»Имя тегаFirstNameMiddleNameLastNameLoginОписаниеИмяОтчествоФамилияЛогинТеги маршрутовИмя тегаОписаниеroute_{no}_a Тег, биты которого указывают на аварию маршрута в системе сообщенийWinCCroute_{no}_c Тег квитирования аварии маршрутаroute_{no}_id Название маршрута{ no } – номер маршрута, от 1 до 20Теги оборудованияДля каждого оборудования при генерации тегов создаются следующие теги:Имя тега{tagprefix}_sОписаниеСтатус оборудования:0 – Остановлено (левое положение)1 – Запускается2 – Работает (правое положение)3 – Останавливается4 – (резерв)5 – Режим энергосбережения6 – Ошибка запуска7 – Ошибка работы8 – Ошибка останова9 – Ошибка остановленного оборудования10 – Ручной режим работы{tagprefix}_s_localЛокальный статус устройства, используется только врежиме редактора маршрутов для подсветки входящего всостав маршрута оборудования.{tagprefix}_sexРасширенный статус устройства:0 – Устройство не исключено из маршрута1 – Устройство исключено из маршрута{tagprefix}_a(ex)Информация об аварии оборудования.