125046 (Автоматизированная система управления компрессорной установки), страница 8

Рис. 4.3 - Диаграмма взаимодействия объектов системы.

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

На данной диаграмме приняты следующие обозначения:

Frequency_Device – частотный регулятор привода компрессора;

Moto – приводной электродвигатель компрессора;

Compressor – воздушный компрессор подачи охлаждения;

Oil_Pump – маслонасос системы охлаждения;

Water_Pump – водяной насос подачи охлаждения;

Temperature_Buter_Sensor – датчик температуры масла;

Temperature_bearings_Sensor – датчик температуры подшипников;

Temperature_Moto_Sensor - датчик температуры двигателя;

Pressure_In_Sensor - датчик давления газа на входе компрессора;

Pressure_Out_Sensor – датчик давления газа на выходе компрессора;

Pressure_Refall_Sensor - датчик перепада давления;

Pressure_butter_Sensor - датчик давления масла;

Pressure_chill-water_Sensor - датчик давления охлаждающей воды;

Pressure_blown_Sensor - датчик давления обдува воздуха;

Pressure_Stek_Sensor – датчик давления воздуха в стойку;

Vibration_H_Sensor – датчик вибрации горизонтальный;

Vibration_L_Sensor – датчик вибрации вертикальный;

Center_Sensor – датчик осевого сдвига;

Gas_In_Valve – клан подачи газа на вход компрессора;

Gas_Out_Valve – клан выкида газа с компрессора;

Butter_Out_Vale – клапан слива масла;

Chill-Water_Out_Valve – клапан слива охлаждающей воды;

Stek_Valve – клапан подачи воздуха в стойку;

Blow_Valve – клапан подачи воздуха на обдув ЭД;

Baipas_Valve – байпасный клапан.

На диаграмме видно, что всем объектам класса Valve контроллером посылаются управляющие сигналы на закрытие (Close) и открытие (Open) соответствующего клапана. Датчикам T_Sensor, P_Sensor, V_ Sensor, C_ Sensor контроллер посылает запросы на выдачу соответственно сигнала (Get_Param). Объектам класса Pump, Compressor контроллер посылает управляющие сигналы на включение (Start) и отключение (Stop).

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

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

Класс Valve

Так как клапаны должны выполнять процентную функции открытия и закрытия, класс содержит атрибутов – State, и два метода: Open() и Close().

Класс Sensor

Объединил в себе все измерительные устройства, которые при необходимости запрашивают атрибут Param и метод Get_Param.

Класс Moto

Данное устройство должны выполнять функции включения и выключения, класс содержит атрибутов – State, и два метода: (Start) и (Stop).

Класс Frequency_Device

Устройство производит регулирование частоты вращения двигателя, класс содержит атрибутов m_Freq и два метода: (Up_Freq) и (Down_Freq).

Класс Air_Compressor

Данное устройство должны выполнять функции включения и выключения, класс содержит атрибутов – State, и два метода: (Start) и (Stop).

Класс Pump

Объединил в себе все насосы, которые содержат два метода: (Start) и (Stop) и атрибут – State.

Класс Receiver

Объединил в себя регулирующие органы класса Valve спуска газа.

Класс Controller.

Должен содержать в себе все введенные оператором параметры технологического процесса:

m_P_Gas_In_min – минимальное входное давление;

m_P_Gas_In_max – максимальное входное давление;

m_P_Gas_Out_min – минимальное выходное давление;

m_P_Gas_Out_max – максимальное выходное давление;

m_P_Gas_Defference_max – максимальный перепад давления;

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

m_T_Gas_In_max – минимальная температура газа на входе;

m_Freq_max – максимальная частота вращения двигателя;

m_C_max – максимальное значение смещения вала;

m_Vibr_max – максимальное значение вибрации вала;

m_T_ bearing_max – максимальная температура подшипника;

m_T_moto_max – максимальная температура двигателя;

m_T_Oil_max – максимальная температура масла;

m_P_Oil_max – максимальное давление масла;

m_P_Oil_Reserv_max – максимальное давление масла с резерва;

m_T_time – время опроса датчиков температуры;

m_P_time – время опроса датчиков давления;

m_C_time – время опроса датчиков смещения;

m_Vibr_time – время опроса датчиков вибрации;

m_P_Water_max – максимальное давление воды;

m_P_Water_min – минимальное давление воды;

m_P_Air_max – максимальное давление воздуха на обдув;

m_P_Air_min – минимальное давление воздуха на обдув;

Все выше сказанное представлено на диаграмме классов рис. 4.4

Рис. 4.4 - Диаграмма классов системы

4.2 Построение алгоритма работы системы

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

Система функционирует следующим образом.

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

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

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

Во время работы происходит постоянная обработка входящих величин с датчиков, что говорит о том – система находится в активном состоянии. Дублирование данных и внешний отчет способствует анализу протекания процесса.

Алгоритм обработки данных имеет вид, представленный на рис. 4.5

Рис. 4.5 - Диаграмма активности, иллюстрирующая обработку данных

4.3 Генерация программного кода

Класс в Rational Rose — это описание общей структуры (данных и связей) для дальнейшего создания объектов. Для того чтобы генератор Rational Rose имел возможность создавать на основе описанной модели программный код, для каждого класса необходимо указать язык, для которого будет создаваться код. Также необходимо определить компонент, в котором этот класс будет храниться. Если в качестве языка для создания кода указан VC++, то пользователь получает доступ ко всей иерархии классов библиотеки MFC при помощи визуальных средств Model Assistant. Поэтому прежде чем приступить к генерации кода на Visual C++, следует создать диаграмму компонентов, отражающая организацию и взаимосвязи программных компонентов, представленных в исходном коде, двоичных или выполняемых файлах. Связи в данном типе диаграммы представляют зависимости одного компонента от другого и имеют специальное отображение через значок «зависимости».

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

Для каждого из классов создается два файла: заголовочный (с расширением .h), который содержит описание класса, и файл реализации (с расширением .cpp), где содержится программная реализация методов класса.

Поэтому каждый класс на диаграмме компонентов будет представлен двумя компонентами: Package Specification и Package Body. Первый компонент представляет собой определение пакета (заголовочный файл с расширением .h), второй – тело пакета (файл с расширением.cpp).

Компоненты на диаграмме (рис. 4.6) для простоты имеют те же названия, что и класс, который они представляют.

Рис. 4.6 - Диаграмма компонентов

Кроме того, при создании компонентов в спецификации каждого из них задается язык, на котором он будет реализован (в нашем случае – VC++), а также указывается какие классы включаются в компонент (вкладка Realizes спецификации компонента). На приведенной диаграмме в каждый компонент включен только один класс с тем же именем, что и компонент.

После того, как реализация и прототипы функций определены, с помощью инструмента Model Assistant в указанных классах задаем для каждого оператора тип возвращаемого им значения, передаваемых ему параметров и тело функции (Default Code Body). В классе Controller задается определение структуры params и содержащиеся в ней поля, представляющие задаваемые оператором параметры процесса.

Заключительным этапом в создании программного кода на Visual C++ является ассоциирование компонента с проектом Microsoft Visual Studio 6.0. Для этого используется инструмент Component Assignment Tool (меню Tools → Visual C++ → Component Assignment Tool…). Здесь в свойствах компонентов требуется либо указать существующий проект Visual Studio, либо создать новый проект (при этом используются средства Microsoft Visual Studio), в котором создаются классы, включенные в выбранные компоненты. С помощью этого инструмента можно также включать классы в компоненты и ассоциировать их с языком VC++ (если это еще не было сделано), методом Drag’n’Drop. После того как для всех компонентов был указан проект, в который они будут включены, можно приступать к генерации кода (меню Tools → Visual C++ → Update Code…). Если при этом был выделен класс или компонент, то произойдет обновление его кода (или создание, если он еще не был сгенерирован). Полный перечень программного кода, реализованного в данном проекте, представлен в Приложении В.

5. Аппаратная и программная реализация системы управления КУ

1. Аппаратная реализация управления

Реализация аппаратной части производится в соответствии с требованиями к системе управления, основные принципы которых излагаются в п.п. 2.3, 2.4 и особенностями технологического процесса, описание которых дается в п. 1.8. Фирмы, занимающиеся проектированием, установкой и наладкой САУ промышленных объектов в нефтехимической отрасли, особенно газоперекачивающей, имеют огромный опыт разработки систем подобного уровня. Поэтому, наиболее разумным было бы обратится к уже готовым решениям как построения самой системы управления, так и внедряемого оборудования. Многие фирмы при проектировании сложных объектов используют методологии, основной принцип которых описан в п. 3.1. Таким образом, можно считать, что данный метод позволит нам более рационально использовать предоставленные ресурсы.

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

1. Выбор платформы системы управления

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

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

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

• Наличие информационного центра технической поддержки;

• Огромная база принципов реализуемых систем;

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