Автоматизированная система управления компрессорной установки (стр. 11 из 22)

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

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. Аппаратная и программная реализация системы управления КУ

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

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

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

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

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

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

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

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

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

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

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

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

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