Комплексная диспетчеризация бизнес-центра

Автор работы: Пользователь скрыл имя, 23 Мая 2013 в 08:46, дипломная работа

Описание работы

Объект – семиэтажное отдельно стоящее здание, находящееся по адресу: г. Санкт-Петербург, ул. Савушкина д.83, корп. 3 Бизнес - центр «Антарес». Эксплуатация здания круглогодичная. На цокольном этаже расположен паркинг. Бизнес – центр уже имеет следующие инженерные системы:
Системы вентиляции и кондиционирования

Файлы: 1 файл

DIPLOMMMM.docx

— 2.47 Мб (Скачать файл)

этот код, возможно доступа к данному коду не будет.

 

 

Далее рассмотрены  компененты «Twincat System»

Программный комплекс «Twincat System», включает в себя следующие программы:

  1. PLC Control
  2. System Manager
  3. OPC – Configurator
  4. System Control
  5. Event Configurator
  6. Scope View

«PLC Control» - программный продукт для конфигурирования программного кода, среда разработки, с помощью которой возможно написание программ на всех языках стандарта

 С  помощью PLC Control устанавливаются пароли пользователя, конфигурируется запись тренд – файлов, запись Log – файлов. Имеется встроенный разработчик графических интерфейсов – TwinCat Visualisation. Он поддерживает возможность архивировать и записывать данные в базы данных, автоматически регистрировать и производить действия при поступлении аварийных сигналов. Управление визуализацией осуществляется с помощью сенсорной панели фирмы «Beckhoff». Для более мощных моделей серии СХ… есть возможность управлять визуализацией при помощи интернет – браузера любого компьютера, подключившись к нему через сетевой провод.

Объявление  переменных происходит в PLC Control. Пример ввода переменных для дискретных(DI) и аналоговых(AI) входов:

DI[1] AT %I* : BOOL;

AI[1] AT %I* : INT;

Компилятор  автоматически раздаёт адреса для  переменных, привязываемых ко входам и выходам. Для объявления сетевых переменных, используется

 

 

следующий синтаксис:

k40206 AT %MB752: INT  , где k40206 – название переменной, MB – тип переменной (сетевой), 752 – адрес.

В данном проекте для контроля и управления используется скада – система  «Zenon», в установке дополнительных сенсорных панелей нет необходимости.

«System Manager» - средство для конфигурирования контроллеров и его входов/ выходов, а также создания к ним привязок переменных из PLC Control. Кроме этого, «System manager» устанавливает настройки подключения к контролерам, настройки IP-адресов, управляет загрузкой и созданием конфигурационных файлов контроллера.

«System OPC Configurator» - средство для создания и настройки OPC – серверов.

 «System Control» - средство для управления лицензированием и настройками подключения к контроллерам с данного компьютера.

«Event Configurator» - позволяет одновременно работать над большими проектами сразу нескольким программистам. Позволяет создавать различные уровни администрирования.

 

 

 

 

 

 

 

 

 

 

 

 

4.1.1 Разработка алгоритма управления системой при тревоге «Пожар»

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

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

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

-если в систему сигнал  одновременно приходит от двух  или более датчиков, запуск противопожарных  систем происходит автоматически   и оператор не может его  остановить.

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

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

 

 

 

 

Рисунок 4.1

Блок – схема управления противопожарными системами

 



                                         



Нет


 

          Да



 

 

 


 


                                  Да


 


              Нет


 

 




 

 

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

Данный алгоритм был реализован на языки ST. Далее отрывок программного кода.

(*Детекция пожарной тревоги*)

IF (NOT Di[56] OR NOT Di[69]) THEN

(*Таймер на 20 секунд*)

timer(in:=TRUE, PT:=T#120s);

(*Проверка отмены тревоги*) 

IF NOT  pozar_otmena AND timer.ET>T#22.5s AND   timer.ET<T#119.5s THEN

    trevoga_pozar:=TRUE;

ELSE

trevoga_pozar:=FALSE;

END_IF

 

IF (timer.ET>T#39s)  AND (timer.ET<T#119.5s)THEN

pozar_otmena:=FALSE;

trevoga_pozar:=FALSE;

END_IF

IF timer.Q THEN

         timer(IN:=TRUE);

END_IF

ELSE

 

pozar_otmena:=FALSE;

trevoga_pozar:=FALSE;

timer(IN:=FALSE);

END_IF

(*Сброс таймера*)

IF timer.Q OR POZAR_ACTIVE THEN

timer(IN:=FALSE);

END_IF

(*Активация пожарной тревоги*)

IF pozar_operator OR trevoga_pozar OR pozar_operator2 THEN

POZAR_ACTIVE:=TRUE;

ELSE

POZAR_ACTIVE:=FALSE;

END_IF

(* Включение противопожарной  системы*)

IF POZAR_ACTIVE THEN

TimerTON[49](IN:=TRUE,PT:=T#2s);

IF TimerTON[49].Q THEN

D019 :=TRUE;(*Включение*)

ELSE

D019:=FALSE;(*Выключение*)

END_IF

ELSE

TimerTON[49](IN:=FALSE);

D019:=FALSE;

END_IF

Данный алгоритм был одобрен  при сдаче объекта в эксплуатацию членами государственной приёмной комиссии.

 

4.2 Наладка связи с контроллерами  системы вентиляции «Сorrigo E» по протоколу «Lon». Использование Microsoft Visio.

LonTalk – закрытый коммуникационный протокол передачи данных, изобретён и запатентован компанией Echelon в 1979 году. Топология сети – «Peer – To – Peer» совместно с «Master – Slave», то есть протокол представляет систему с распределённым интеллектом, без центрального устройства. Благодаря этому, повышается надёжность системы, так как выход из строя оборудования не влияет на функционирование системы в целом. Одной из главных составляющих технологии LonWorks является открытый протокол LonTalk, описываемый 7-уровневой сетевой моделью взаимодействия открытых систем OSI.

Протокол LonTalk не опирается  на определенную реализацию физического

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

Каждый узел LonWorks работает с физическим уровнем в одном  из двух режимов – прямом или  специальном. В прямом режиме информация передается в закодированном виде (например, с применением дифференциального  манчестерского кодирования битов), а в специальном режиме данные передаются последовательно и без  кодирования. Причем в обоих режимах  каждый пакет сопровождается 16-битовым CRC-кодом. Это позволяет не учитывать  при передаче битов конкретную реализацию среды передачи. При работе в прямом режиме контроль над скоростью передачи данных, длиной заголовков пакетов  и кодированием берет на себя микроконтроллер Neuron. В специальном режиме эти  задачи выполняет приемопередатчик, используемый для сопряжения различных  физических протоколов.

На подуровне MAC в качестве средства борьбы с коллизиями (конфликтными ситуациями) используется предиктивный метод, основанный на

упорядочении доступа  к каналу с учетом предполагаемой нагрузки на канал. Передающий узел всегда получает доступ к каналу со случайной  задержкой из диапазона от 0 до некоторой  величины w, являющейся функцией числа  незавершенных заданий, стоящих  в очереди на выполнение. Разрешение коллизий на этом подуровне осуществляется по следующим правилам:

1. Если коллизия возникла  после двух последовательных  попыток передачи

пакета с приоритетом, то следующая отсылка пакета будет  происходить без приоритета.

2. При  обнаружении коллизии передающий  узел должен инкрементировать

число незавершенных  заданий.

3. Если  после 255 последовательных попыток  передачи пакета возникает

коллизия, то задание снимается.

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

Транспортный  уровень обеспечивает достоверную  передачу пакетов одному

абоненту  или группе абонентов. Для связи  с сеансовым уровнем на транспортном уровне LonTalk реализована поддержка  следующих функциональных запросов: послать телеграмму, принять телеграмму, подтверждение завершения передачи. Сеансовый уровень отвечает за реализацию простого механизма запроса/ответа для доступа к удаленным серверам данных и обеспечивает выполнение всего одной функции – запрос/ответ. При этом любой запрос будет ожидать ответа. Функции запроса/ответа можно использовать для прикладных задач, работающих по принципу клиент-сервер. И на транспортном, и на сеансовом уровнях включен механизм контроля авторизованного доступа: запрос, не обладающий правом доступа к данным текущего узла, не будет обслужен. Уровень приложений и предоставления данных создает основу для

совместимости узлов протокола LonTalk. Одной из важных задач, решаемых на этом уровне, является передача чужеродных по отношению к LonTalk телеграмм. Такая функция используется для организации шлюзов между  доменами, а также для перехода через LonTalk к другим протоколам. В LonWorks используется модифицированный произвольный доступ с контролем несущей (CSMA/CD). Для уменьшения нагрузки на сеть используется событийный механизм обмена сообщениями, а для сокращения внутрисетевого трафика можно использовать сегментацию сети при помощи маршрутизаторов, выпускаемых различными производителями.

Для конфигурирования сети используется адаптер «Echelon FT/TP» и лицензированное программное обеспечение «Echelon Lon Maker». Но для начала работы с этим оборудованием нужно сконфигурировать и настроить модуль расширения Lon  - «Beckhoff KL6401».

Для этого  используются специализированные библиотеки «TcKL6401» и «TcBaseBСхх00». Они содержат функциональные блоки чтения/записи для работы с Lon – протоколом, информацию для поддержки  snvt – переменных (специализированные переменные стандарта LonWorks). Далее приводится пример вызова функционального блока fb_FB_ReadWrite_OnChange_36B на языке ST:

(* Вызов функционального блока*)

fb_FB_ReadWrite_OnChange_36B(

Activate:=TRUE ,

stParameter_IN:=LON_IN ,

stParameter_OUT:=LON_OUT );

Предполагается считывать Lon – переменные типа snvt_state_64, длина которых 8 байт. Каждый бит этих переменных несёт в себе состояние о аварии (0 – авария обнаружена, 1 – авария имеется), то есть всего 64 вида аварий для каждого контроллера управления вентиляцией.

Так как  в библиотеках TwinCat переменная snvt_state_64 не поддерживается, предполагается записывать каждую приходящую переменную snvt_state_64 в две переменные типа UINT, целочисленные переменные длиной по 4 байта. Это позволит в дальнейшем без проблем, связанных с переводом переменных, вывести эти переменные на скада – систему, так как выбранная скада – система Zenon для контроллеров Beckhoff поддерживает максимально большую переменную USINT. Расшифровка переменных на 64 булевых значения для последующей привязки соответствующих аварий будет происходить в Zenon, что позволит сократить количество переменных, и уменьшит стоимость системы.

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

Приведём  пример считывания аварийных сигналов для 1 щита управления вентиляцией. В нашем случае для ЩУВ-а №1 созданы переменные SHUV1 и SHUV11 соответственно:

Информация о работе Комплексная диспетчеризация бизнес-центра