8.4. Определение требований к системе

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

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

Отобразим все вышесказанное на диаграмме сценариев Use Case (рис. 8.2). На этой диаграмме видно, что режим работы задается оператором действием Создать план. После запуска оператором процесса контроллеры, получая данные от датчиков, управляют устройствами. Контроллеры выдают в той или иной форме информацию о текущем состоянии процесса регулирования температурными режимами оператору, что показано на диаграмме действием Создать протокол работы. Протоколирование работы системы не рассматривается в данном проекте.

В данном проекте использовано 3 контура, на каждом из которых функцию управления осуществляет соответствующий контроллер. Информация со всех контроллеров поступает на персональный компьютер оператора (АРМ), который осуществляет регулирование температурными режимами системы в соответствии с требованиями обслуживания зданий.

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

Рис. 8.2 Диаграмма сценариев Use Case

Таким образом, в окончательном варианте мы получили следующие требования к проектируемой системе поддержания микроклимата:

1. оператор должен иметь возможность ввести нормы;

2. оператор должен иметь возможность просматривать протокол работы системы;

3. система должна получать информацию от датчиков;

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

8.5 Построение структуры системы

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

Рис. 8.3 Диаграмма топологии Deployment

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

Центральным устройством системы управления, функционально связанным со всеми устройствами системы и управляющий ими, является АРМ, что соответствует определенным выше требованиям к системе.

Далее определяем, каким образом устройства, показанные на диаграмме топологии, взаимодействуют между собой. Для этого сначала разделим устройства в зависимости от выполняемых ими функций на категории (классы). Диаграмма классов представлена на рис.8.4, на которой

• Контроллеры (класс Controller1, Controller2, Controller3) – посылают запросы датчикам и управляющих сигналов исполняющим устройствам;

• Насосы (класс Nasos) – включение и выключение;

• ГВС (класс GVS) – включение и выключение источника горячего водоснабжения;

• ПО (класс PO ) – включение и выключение подогревателя отопления;

• Клапаны (класс Klapan) – включение и выключение;

• Фильтры (класс Filtr) - включение и выключение;

• Датчик давления (класс Davlen_Sensor) – изменение давления в системе;

• Датчик температуры (класс Temper_Sensor) - измерение температуры в системе;

• Датчик расхода (класс Rashod_Sensor) – определение расхода.

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

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

Обмен сообщениями происходит в определенной последовательности, и Sequence diagram позволяют получить отражение этого обмена во времени.

Рис.8.4 Диаграмма Class Diagram

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

На основе приема-передачи сообщений основана многозадачность Windows, а в нашем случае для простоты демонстрации создания приложения будем считать, что сообщения обрабатываются немедленно в той последовательности, в которой они выдаются клиентами (рис.8.5., 8.6.).

Рис.8.5Диаграмма Sequence Diagram

Легко заметить, почти все объекты, представленные на диаграмме, соответствуют устройствам на диаграмме топологии. Исключение составляет объект Timer, который конструктивно входит в состав АРМ, но является самостоятельно функционирующим объектом. Таймер в системе выполняет роль тактирующего устройства, которое через определенные промежутки времени «будит» систему посылкой сигнала SetTimer, выводя ее тем самым из состояния бездействия. При получении этого сигнала АРМ посылает сигнал контроллерам, которые производят опрос датчиков.

В системе также предусмотрена возможность задания короткого и длинного интервала генерации сигнала SetTimer, т.к. некоторые процессы требуют относительно более частого опроса датчиков (например, температуры и давления), чем другие (например, определение расхода воды). Второй, уже упоминавшийся тип диаграмм взаимодействия, - это Collaboration Diagram «сотрудничество» (рис.8.7). Эта диаграмма отличается от предыдущей тем, что она не акцентирует внимание на последовательности передачи сообщений, она отражает наличие взаимосвязей вообще, то есть на этой диаграмме отражается наличие сообщений от клиентов к серверам.

Рис.8.7 Диаграмма сотрудничества

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

На диаграмме видно, что всем объектам классов GVS, Nasos, Klapan, Filtr, PO контроллеры посылаются управляющие сигналы на выключение (IsOFF()) и включение (IsON()) соответствующих устройств. Датчикам Temper_Sensor, Rashod_Sensor, Davlen_Sensor контроллеры Controller_1, Controller_2, Controller_3 посылают запросы на выдачу соответственных значений температуры воды (Get_Temper()), расхода воды (Get_Rashod()) и давления воды (Get_Davlen()), в зависимости от контура управления. Первому контру присвоено обозначение _1, второму - _2, третьему - _3. ARM, через интервалы времени задаваемые таймером m_Period, производит обмен информацией с контроллерами: с Controller_1 – Get_System1(), c Controller_2 – Get_System2(), c Controller_3 – Get_System3() и соответственно принимает сигнал от Controller_1 –Current_System1(), от Controller_2 – Current_System2(), от Controller_3 – Current_System3()

Каждая связь Link Message имеет свойства, позволяющие настроить область видимости для связанных объектов.

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

Класс Timer

Класс содержит в себе переменную т_Period типа double, которая определяет интервал времени между генерацией события OnTimer. Для защиты от доступа извне атрибут объявлен как private. Поэтому для задания этой переменной следует использовать функцию Set_Timer(), доступную для других объектов.

Класс GVS

Так как контур горячего водоснабжения выполняет только функции включения и выключения, класс не содержит атрибутов, а содержит только два метода: IsOn() и IsOff().

Класс PO

Также выполняет только функции включения и выключения, класс не содержит атрибутов, а содержит только два метода: IsOn() и IsOff().

Класс Nasos, Klapan, Filtr

Также не содержат атрибутов, а содержат методы: IsOn() и IsOff().

Класс Temper_Sensor

Данный класс имеет атрибуты трёх контуров управления: m_Temper_In_1 – температура на входе контура подачи воды, m_Temper_Out_1 – температура воды с контура ГВС, m_Temper_Out2_1 – температура воды на выходе ПО, m_Temper_In_2 – температура воды на входе в ПО, m_Temper_Out_2 - температура воды на выходе контура подогрева, m_Temper_In_3 - температура воды на входе контура циркуляции, m_Temper_Out_3 - температура воды на выходе контура циркуляции. Все переменные данного класса определены типом double. Для возвращения значений атрибутов используется единственная функция Get_Temper(), которая в зависимости от вида запроса будет возвращать определенное значение атрибута.

Класс Rashod_Sensor

Данный класс имеет следующие атрибуты контуров управления: m_Rashod_In_1 – объем воды на входе контура подачи воды, m_Rashod_Out_1 – объем воды на выходе, m_Rashod_2 – объем воды в контуре подогрева, m_Rashod_3 - объем воды на выходе контура циркуляции. Все переменные данного класса определены типом double. Функция Get_Rashod() возвращает значения атрибутов.

Класс Davlen_Sensor

Данный класс имеет атрибуты трёх контуров управления: m_Davlen_In_1 – давление воды на входе контура подачи воды, m_Davlen_Out_1 – давление воды на выходе контура ГВС, m_Davlen_Out2_1 – давление воды на выходе подогревателя отопления, m_Davlen_In_2 – давление воды на входе в ПО, m_Davlen_Out_2 - давление воды на выходе контура подогрева, m_Davlen_In_3 - давление воды на входе контура циркуляции, m_Davlen_Out_3 - давление воды на выходе контура циркуляции. Все переменные данного класса определены типом double. Функция Get_Davlen() возвращает значения атрибутов.

Класс ARM

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

т_System1_Norm - значение всех параметров для управления контуром подачи воды, поступивших от Controller1.

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

т_System3_Norm - значение всех параметров для управления контуром циркуляции воды, поступивших от Controller3.

т_ShortPeriod (1,2,3)- значение короткого интервала генерации сообщений таймера.

m_LongPeriod (1,2,3) - значение длинного интервала генерации сообщений таймера.

Введенные оператором значения параметров протекания процесса присваиваются соответствующим атрибутам класса с помощью методов Current_System1(), Current_System2() Current_System3().

Класс Controller1

Содержит в себе все параметры для обеспечения процесса подачи воды в систему отопления:

т_Davlen_Out_Set_1 - давление воды на выходе трубопровода.

т_Davlen_In_Set_1 – давление воды на входе системы.

т_Davlen_Out2_Set_1 – давление воды на выходе контура ГВС.

т_Temper_In_Set_1 – температура входного значения воды в трубопроводе.

т_Temper_Out_Set_1 – температура на выходе контура подачи воды.

т_Temper_Out2_Set_1 - температура воды, подающаяся с контура ГВС.

т_Rashod_Out_Set_1 - значение объема воды, прошедшей через водопровод.

т_Rashod_In_Set_1 - значение объема воды, поступившей в водопровод.

Все параметры первого контура генерируются в параметре т_System1.

Введенные оператором значения параметров протекания процесса присваиваются соответствующим атрибутам класса с помощью метода Get_System1(). А с помощью методов Current_Davlen_Out_1(), Current_Davlen_In_1(), Current_Dav-len_Out2_1(), Current_Temper_In_1(), Current_Temper_Out_1(), Current_Temper_Out2_1(), Current_Ras-hod_Out_1(), Current_Rashod_In_1() осуществляется корректировка давления газа, температуры, расхода воды, прошедшей через трубопровод и сравнение необходимой и текущей температуры воды.

Класс Controller2

Содержит в себе все параметры для обеспечения процесса подогрева воды в ПО:

т_Davlen_Out_Set_2 - давление воды на выходе контура.

т_Davlen_In_Set_2 – давление воды на входе системы.

т_Temper_In_Set_2 – температура воды на входе в подогреватель.

т_Temper_Out_Set_2 – температура воды на выходе подогревателя отопления.

т_Rashod_Set_2 - значение объема воды, прошедшей через подогреватель отопления.

Все параметры первого контура генерируются в параметром т_System2.

Введенные оператором значения параметров протекания процесса присваиваются соответствующим атрибутам класса с помощью метода Get_System2(). А с помощью методов Current_Davlen_Out_2(), Current_Davlen_In_2(), Current_Temper_In_2(), Current_Temper_Out_2(), Current_Rashod_2() осуществляется корректировка и сравнение давления газа, температуры, расхода воды, прошедшей через трубопровод.

Класс Controller3

Содержит в себе все параметры для обеспечения процесса поддержания температурного режима в контуре циркуляции воды:

т_Davlen_In_Set_3 – давление воды на входе системы.

т_Davlen_Out_Set_3 - давление воды на выходе трубопровода.

т_Davlen_Out2_Set_3 – давление воды на входе контура ГВС.

т_Temper_In_Set_3 – температура входного значения воды в контуре.

т_Temper_Out_Set_3 – температура воды на выходе контура циркуляции.

т_Rashod_Set_3 - значение объема воды в водопроводе.

Все параметры первого контура генерируются параметром т_System3.

Введенные оператором значения параметров протекания процесса присваиваются соответствующим атрибутам класса с помощью метода Get_System3(). А с помощью методов Current_Davlen_In_3(),Current_Davlen_Out_3(), Current_Dav-len_Out2_3(), Current_Temper_In_3(),

Current_Temper_Out_3(), Current_Rashod_3() осуществляется корректировка давления газа, температуры, расхода воды, прошедшей через трубопровод и сравнение необходимой и текущей температуры воды. (рис. 10.4).

Классы Controller1, Controller2, Controller3 должны иметь доступ к атрибутам других классов для обеспечения управления технологическим процессов. Для этого они используют методы классов для доступа к ним. Из этого следует, что классы Controller1, Controller2, Controller3 зависят от других классов, или в терминах UML, находятся с ними в отношении зависимости, что отображено на диаграмме пунктирными стрелками, указывающими на класс-источник зависимости.