Рисунок 2.7 - Контроллер I-8811
последовательным каналам связи на базе интерфейса RS-485. Контроллер имеет открытую архитектуру и может программироваться как с помощью традиционных языков программирования (С, ассемблер), так и с помощью языков логического программирования в соответствии со стандартом МЭК-61131 (в настоящий момент поддержка ICOS-8811 реализована в системах программирования UltraLogik и Paradym-31). Таким образом, ICOS-8811 удачно сочетает в себе качества программируемого логического контроллера (PLC) с простой и открытой архитектурой IBM PC совместимых компьютеров.
Характеристика микроконтроллера:
- процессор: 80188, 16-разрядный;
- память ОЗУ: 256 кбайт;
- флэш-ПЗУ: 256 кбайт;
- операционная система: ROM-DOS;
- часы реального времени: встроенные;
- сторожевой таймер: встроенный;
- количество обслуживаемых модулей ввода-вывода:8;
- последовательных порта: RS-232 и RS-485;
- напряжение изоляции: 3000 В;
Для сбора сигналов с датчиков используются 8-канальные модули аналогового ввода ICOS 87017:
Каналы: 8 дифференциальных;
Эффективное разрешение: 16 бит;
Типы входного сигнала: мВ, В, мА ;
Входной диапазон: ±150, ±500 мВ, ±1, ±5, ±10 В; 0…20 мА ;
Напряжение изоляции: 1000 В (пост.)
Частота выборки: 10 Гц (общая)
Входное сопротивление: 2 МОм
Полоса пропускания: 13,1 Гц
Точность не хуже: ±0,1%
Дрейф нуля: ±0,3 мкВ/°С
Дрейф диапазона: ±25 РРМ/°С
Ослабление сигнала при 50/60 Гц — 92 дБ/мин
Потребляемая мощ ность: 1,0 Вт
Рисунок 2.8 - I-87017
4-канальный модуль аналогового вывода
Каналы: 4
Эффективное разрешение: 12 бит
Типы выходного сигнала: мА, В
Выходной диапазон: 0…20, 4…20 мА, 0…10 В
Напряжение изоляции: 500 В (пост.)
Точность:
±0,1% для токового выхода;
±0,1% для выхода напряжения
Разрешающая способность: 0,015%
Дрейф нуля:
выход напряжения: ±30 мкВ/°С;
токовый выход: ±0,2 мкА/°С
Рисунок 2.9 I-87024
Программируемая скорость нарастания выходного сигнала: 0,125…0,128 мА/с; 0,0625…64,0 В/с
Токовый нагрузочный резистор: 0…500 Ом (источник)
Потребляемая мощность: 2,5 Вт
В качестве удаленного сбора информации и управления технологическим процессом выбраны микроконтроллеры серии ICOS-7000 представленные на рисунке 2.10
Характеристика микроконтроллера I-7017:
Модуль аналогового ввода на 8 каналов;
16-разрядный АЦП;
6 дифференциальных и 2 однополюсных канала;
Программная настройка для работы с мВ, В или мА;
Гальваническая изоляция: 3000 В.
Характеристика микроконтроллера I-7024:
Модуль аналогового вывода на 4 канала;
12-разрядный ЦАП;
Программная настройка выхода на В или мА; Контроль состояния выхода;
Программируемая скорость изменения сигнала навыходе:
от 0,125 до 128,0 мА/с или от 0,0625 до 64 В/с;
Гальваническая изоляция: 3000 В.
|
Модуль аналогового вывода на 2 канала;
12-разрядный ЦАП
Программная настройка выхода на В или мА
_ Контроль состояния выхода;
Программируемая скорость изменения сигнала на выходе:
от 0,125 до 128,0 мА/с или от 0,0625 до 64 В/с;
Гальваническая изоляция: 3000 В.
Для обработки полученной информации, контроля за технологическим процессом и управления им необходим персональный компьютер:
- дисплей: цветной с диагональю 15 дюймов и разрешением 1024 ×768 точек;
- процессор: Intel Pentium III до 850 МГц;
- память ОЗУ: до 256 Мбайт;
- CD ROM: 57 скоростной;
- контроллер Ethernet.
Порты ввода вывода: 4 последовательных порта (3 ×RS 232, 1 ×RS 232/422/485), 1 универсальный параллельный порт, 2 порта USB, порты для подключения клавиатуры и мыши (PS/2), входы и выходы звуковой подсистемы.
3 МОДЕЛИРОВАНИЕ ТЕХНОЛОГИЧЕСКОГО ПРОЦЕССА
3.1 Построение функциональной модели автоматизированной системы и алгоритмов обеспечения безопасности методом объектно-ориентированного моделирования
3.1.1 Описание метода моделирования
Для анализа и проектирования, рассматриваемого технологического процесса, целесообразно использовать методы объектно-ориентированного подхода с применением UML, который представляет собой общецелевой язык визуального моделирования, разработанный для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения и других систем. Язык UML одновременно является простым и мощным средством моделирования, который может быть эффективно использован для построения концептуальных, логических и графических моделей сложных систем самого различного целевого назначения. Этот язык вобрал в себя наилучшие качества методов программной инженерии.
Базовые понятия языка UML комбинируются и расширяются таким образом, что специалисты объектного моделирования получают возможность самостоятельно разрабатывать модели систем в самых различных областях приложений [12-14].
Конструктивное использование языка UML основывается на понимании общих принципов моделирования систем и особенностей процесса объектно-ориентированного анализа и проектирования. Выбор выразительных средств для построения моделей сложных систем предопределяет те задачи, которые могут быть решены с использованием данных моделей. При этом одним из основных принципов построения моделей систем является принцип абстрагирования, который предписывает включать в модель только те аспекты проектируемой системы, которые имеют непосредственное отношение к выполнению системой своих функций или своего целевого предназначения.
При этом все второстепенные детали опускаются, чтобы чрезмерно не усложнять процесс анализа и исследования полученной модели.
Другим принципом построения моделей сложных систем является принцип многомодельности. Этот принцип представляет собой утверждение о том, что никакая единственная модель не может с достаточной степенью адекватности описывать различные аспекты системы. Наиболее общими представлениями сложной системы принято считать статическое и динамическое представления, которые, в свою очередь, могут подразделяться на другие более частные представления. Феномен сложной системы как раз и состоит в том, что никакое ее единственное представление не является достаточным для адекватного выражения всех особенностей моделируемой системы [15].
Еще одним принципом прикладного системного анализа является принцип иерархического построения моделей сложных систем. Этот принцип предписывает рассматривать процесс построения модели на разных уровнях абстрагирования или детализации в рамках фиксированных представлений. При этом исходная или первоначальная модель сложной системы имеет наиболее общее представление (метапредставление). Такая модель строится на начальном этапе проектирования и может не содержать многих деталей и аспектов моделируемой системы.
При разработке часто возникает проблема изменения функциональности системы, заключающаяся как в добавлении новых функций, так и в модификации уже существующих. Использование объектных методов позволяет локализовать изменения таким образом, чтобы изменение функциональности одного модуля не привело к ошибкам в работе других, а также быстро и четко выделить модули, поведение которых изменится в результате данного изменения.
Использование UML облегчает проблему сопровождаемости проекта, поскольку основная информация о проекте хранится в визуальной форме. Средства визуального моделирования, поддерживающие UML, позволяют автоматизировать анализ и проектирование программных систем, а интегрированные в них средства автоматической кодогенерации дают возможность привязывать исходный код объектно-ориентированных языков программирования (C++, Java, Delphi, Power Builder, Visual Basic, Forte, Ada, Smalltalk и других) прямо к элементам модели и вести разработку кода внутри построенной модели.
Язык UML определяет набор диаграмм, описывающих модели, и базовую нотацию. Он включает в себя описание семантики, расширения и комментарии по применению. В документации семантика представлена как на естественном языке, так и в нотации UML в виде метамодели. Описание графической нотации сопровождается примерами диаграмм.
Моделирование сложной системы средствами UML сводится к ее описанию в различных проекциях. Каждая проекция описывает определенный аспект разрабатываемой системы, а все вместе они определяют систему с должной степенью полноты, правильности и адекватности. В UML для описания системы при анализе и проектировании предусмотрены следующие графические диаграммы.
Диаграммы прецедентов (Use Case Diagram) применяются для анализа проблемной области и разработки функциональной структуры системы. Эта методология в настоящее время широко применяется для анализа бизнес-систем и реинжиниринга деятельности компаний.
На основании диаграмм прецедентов строятся модели поведения системы (Interaction Diagrams). Они позволяют рассмотреть выполнение определенных функций системы и спроектировать поведенческие свойства классов. Это осуществляется с помощью диаграмм последовательности (Sequence Diagrams) и диаграмм взаимодействия (Collaboration Diagrams), которые в совокупности отображают трехмерную модель взаимодействий между классами, с учетом временных параметров этих взаимодействий.
Диаграммы классов (Class Diagrams) применяются для проектирования иерархической структуры классификации объектов системы. Кроме атрибутивной и поведенческой структуры классов, диаграммы классов позволяют выделить связи и зависимости между классами и объектами системы.
Диаграммы состояний (State Diagram) позволяют описать иерархическую структуру состояний объектов системы и переходы между состояниями под воздействием определенных событий. Особый вид диаграмм состояний -диаграммы активности (Activity Diagrams) позволяют описать алгоритмы выполнения отдельных операций.
Диаграммы размещения (Deployment Diagrams) позволяют спроектировать архитектуру системы и обозначить процессы, выполняемые на отдельных вычислительных узлах системы, что особенно важно для проектирования распределенных систем, использующих интернет-технологии.
Диаграммы компонент (Component Diagrams) предназначены для грамотного разделения приложения на модули, что является очень сложной задачей. Это позволяет эффективно распределить работу внутри коллектива разработчиков и избежать ошибок несовместимости компонент приложения, правильно работающих в отдельности. Использование грамотного разделения программы на компоненты дает возможность накопления наработок в отдельных областях (создания библиотек готовых компонентов), их повторного использования и сборки готовых программ из ранее разработанных компонентов.
Разные разработчики могут применять UML по своему усмотрению в зависимости от своих проблемных областей и используемых технологий.
3.1.2 Разработка функциональной модели системы
Результаты анализа требований к системе формализуются с помощью функциональной модели, которая определяет, какие функции должны выполняться системой, вне зависимости от ее структуры. Наполнение (реализация) функций происходит в терминах объектов, обладающих определенными свойствами и поведением.
Создание функциональной модели, как правило, начинается с представления проектируемой системы в виде наборов актеров, взаимодействующих с системой с помощью так называемых прецедентов, то есть сначала мы определяем, что взаимодействует с системой. Примерами таких «действующих лиц», или внешних актеров, могут быть: пользователь системы, оператор, оборудование, система, внешняя по отношению к данной. В свою очередь прецедент описывает, что система предоставляет актеру - то есть определяет некоторый набор транзакций или услуг, совершаемый актером при диалоге с системой, при этом ничего не говорится о том, каким образом будет реализовано взаимодействие. Диаграмма прецедентов несет в себе высокий уровень абстракции, что позволяет еще на ранних этапах проекта определить и зафиксировать функциональные требования к системе и обеспечить гибкий и эффективный механизм взаимодействия между разработчиком и заказчиком проекта.
Каждый из случаев использования системы может быть рассмотрен, как функция системы и подвергнут дальнейшей декомпозиции в терминах функций. В результате возникает дерево функциональной декомпозиции. Каждая функция может быть разбита на несколько более мелких. Такое разбиение обычно соответствует либо структурной декомпозиции функциональных требований (на фазе анализа), либо выделению подзадач, решение которых требуется для осуществления основной цели (на фазе проектирования). На диаграмме прецедент обозначается овалом, внутри которого или под ним указывается его имя. Актер также представляется в виде условного обозначения. Взаимодействие между актером и прецедентом обозначается линией.
Для построения модели прецедентов необходимо сформулировать требования к рассматриваемой системе и провести их декомпозицию. Целью технологического процесса в целом считаем достижение максимальной производительности технологической линии при обеспечении безопасности процесса и заданного качества изделий. Для решения глобальной цели необходимо обеспечить достижение максимальной производительности при обеспечении безопасности и заданного качества изделий на каждой фазе технологического процесса. Так, для фазы электролиза цель формализуется следующим образом [9]:
Где Q – производительность процесса электролиза;
х1,х2,…,хn – технологические параметры;
n – количество параметров, влияющих на производительность электролиза:
К – качество полученного газа;
Кmin, Кmax – соответственно минимальные и максимальные значения качества;
Б, Бmin – соответственно безопасность и допустимый уровень безопасности.
К={к1, к2, …кm}
где к1, к2, …кm – показатели качества.
Для достижения каждой из полученных целей необходимо реализовать другие подцели, и т.д. На рисунке 3.1 Обобщенная функциональная модель обеспечения безопасности ТП получения водорода, представленная в виде формализованной декомпозиции целей..
Рисунок 3.1 – Обобщенная функциональная модель обеспечения безопасности ТП получения водорода
Обеспечение безопасности процесса электролиза достигается за счет, во-первых, осуществления прогноза опасных и критических ситуаций, и, во-вторых, своевременного принятия решения и реализации управляющих воздействия на ТП для недопущения и (или) устранения опасных ситуаций.
Указанные цели представлены на рисунке 3.2 в виде диаграммы прецедентов. В качестве актеров выступает оператор системы, следящий за ходом ТП и технолог задающий технологический регламент.
Рисунок 4.2 – Представление целей управления ТП в виде диаграммы прецедентов
Основные прецеденты определяются целями процесса электролиза (рисунок 3.1). Обобщенная модель реализации цели «Обеспечение безопасности» приведена на рисунке 3.3 в виде расширенной диаграммы данного прецедента.
Рисунок 3.3 – Обобщенная модель реализации цели (прецедента) «Обеспечения безопасности»
В результате анализа технологического процесса выявлены следующие критические ситуации
- S1 повышение содержимого кислорода в водороде ;
- S2 повышение содержимого водорода в кислороде;
- S3 повышение температуры электролита на выходе из разделительных колон;
- S4 одновременное повышение удельных энергозатрат и температуры в электролизере;
- S5 повышение давления в колоннах регулирования давления
Отсюда, Б={S1,S2,S3,S4,S5}.
В качестве показателей распознавания критических ситуаций выбраны следующие параметры:
-
удельные энергозатраты, определяемые отношением энергии,
подводимой
электролизерам, к производительности, (Еэлек);
- температура газов на выходе из разделительных колон (Тгаз);
- резкое уменьшение текущей производительности (Q) электролизера;
- давление водорода (Рводор) и кислорода (Ркисл.)
При достижении текущими показателями безопасности предельно допустимых значений режим работы электролизера считается критическим.
Величины предельно допустимых значений показателей безопасности могут быть взяты из технологического регламента, либо из анализа аварий.
Таким образом, система обеспечения безопасности процесса получения водорода методом электролиза предназначена для распознавания (по величине и характеру изменения показателей) и устранения критических ситуаций при работе электролизера путем изменения его режимов.
Функциональная модель предоставляет средства для спецификации требований к системе. Дальнейшая детализация этих требований, а также их проекция на ее структуру, осуществляется с помощью диаграмм классов и последовательностей.
3.1.3 Разработка алгоритмов функционирования системы
Диаграмма последовательности делает упор на временную последовательность передаваемых сообщений, важен порядок, вид и имя сообщения, на диаграмме изображаются исключительно те объекты, которые непосредственно участвуют во взаимодействии, и не показываются возможные статические ассоциации с другими объектами.
