Алгоритм Безапосности: издание для профессионалов
Санкт-Петербург:
тел.: +7 911 137-88-32 magazine@algoritm.org
Москва:
тел.: +7 499 641-05-26moscow@algoritm.org

Главная
Новости
О журнале
Архив
Свежий номер
Реклама
Подписка
Контакты
Сотрудничество
 

Если вы хотите стать распространителем нашего журнала

 
 
 
 
 

"Алгоритм Безопасности" № 5, 2012 год.

Содержание

BACnet – путь к интеграции систем безопасности в общую систему управления зданием. Часть пятая
С. Лёвин


BACNET. ПУТЬ К ИНТЕГРАЦИИ СИСТЕМ БЕЗОПАСНОСТИ В ОБЩУЮ СИСТЕМУ УПРАВЛЕНИЯ ЗДАНИЕМ

ЧАСТЬ ПЯТАЯ

С. Левин

главный конструктор НПФ «Сигма-ИС»

ПРОЦЕДУРЫ BACNET

В этой статье описываются типовые процедуры, которые используются в системах автоматизации.

ПРОЦЕДУРЫ АРХИВАЦИИ И ВОССТАНОВЛЕНИЯ

В BACnet системах управления зданием многие устройства содержат данные конфигурации, которые, как правило, могут изменяться с помощью специальных инструментальных средств, предоставляемых производителем оборудования. Конфигурация может содержать как видимые по сети BACnet объекты, так и несетевые локальные параметры. Далее мы рассмотрим стандартные методы BACnet для сохранения и восстановления конфигурационных данных. Процедуры архивации и восстановления используют объекты типа Файл для хранения и передачи данных. Содержимое и формат конфигурационных файлов определяется в частном порядке для каждого устройства. Выбор в использовании потоковых файлов или файлов, основанных на записях, также остается за разработчиком BACnet устройства. Службы, требующие поддержку процедур архивации и восстановления: Reim'tializeDevice, ReadProperty, WriteProperty, AtomicWriteFile, AtomicReadFUe и опционально CreateObject, ReadPropertyMultiple, WritePropertyMultiple.

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

Инициализация процедуры архивации: Устройство А отправляет сообщение Reini-tializeDevice (STARTBACKUP, ) и ожидает ответа от устройства В для продолжения процедуры.

Подготовка к процедуре архивации: Перед началом архивирования устройство А считывает свойство Backup_Preparation_Time, если оно представлено, из устройства В. Если свойство не задано, принимается значение 0. После приема сообщения ReinitializeDevice, если устройство В способно выполнить процедуру архивации, то оно отвечает с Result(+) на данный запрос. Устройство В устанавливает свойство Backup_And_Restore_State в значение PREPARING_FOR_BACKUP. После получения положительного ответа устройство А начинает мониторить свойство Backup_And_Restore_State и не начинает процедуру архивирования до тех пор, пока свойство не примет значение PERFORMING_A_BACKUP. В течение времени, определенного в Backup_Preparation_Time, устройство В игнорирует все запросы от устройства А. В это время неответ от устройства не должен приниматься за ошибку. Как только устройство В устанавливает свойство Backup_And_Restore_State в PER-FORMING_A_BACKUP, оно готово принимать запросы, даже если время Backup_Prepa-ration_Time еще не вышло. Если устройство В не может выполнить архивирование или уже его выполняет в настоящий момент, оно отвечает на запрос ReinitializeDevice ответом Result(-). Если устройство B поддерживает процедуру архивирования и запрос был правильно сформулирован, то возможны следующие коды ошибок:

■ DEVICE: CONFIGURATION_IN_PROGRESS - если устройство уже обрабатывает запрос на архивирование или восстановление;

■ SECURITY: PASSWORD_FAILURE - если пароль, указанный в запросе, некорректен или не предоставлен.

После того как устройство В ответило на запрос ReinitializeDevice ответом Result(+), оно имеет Backup_Preparation_Time секунд для подготовки к процедуре архивирования. В течение этого времени устройство не отвечает ни на какие запросы. Когда подготовка к архивированию завершена, объекты конфигурации становятся доступны в устройстве и свойство Backup_And_Restore_State устанавливается в значение PERFORMING_A_BACKUP. Если устройство В не может успешно завершить подготовку, Backup_And_Restore_State устанавливается в значение BACKUP_FAILURE. Устройство А завершает процедуру архивирования при обнаружении значения BACKUP_FAILURE.

Как будет отвечать устройство В на запросы в процессе архивирования, определяют разработчики устройства. Исключение составляет лишь то, что устройству В требуется выполнить и завершить запросы на чтение, которые приходят от устройства А. Замечу, что устройство В может вернуть ошибку UKNOWN_FILE_SIZE в ответе в свойстве File_Size в любом из конфигурационных файлов, если размер файла неизвестен. Любые другие запросы могут быть отклонены в процессе архивирования с классом ошибки DEVICE и кодом ошибки DEVICE_BUSY.

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

Загрузка параметров архивации: После приема ответа Result(+), устройство А считывает свойство Configuration_Files из объекта Device. Это свойство используется для определения файлов конфигурации для чтения, а также порядка, в котором они должны вычитываться из устройства.

Архивирование конфигурационных файлов: Как только устройство А определяет файлы, которые составляют конфигурацию, далее определяется тип каждого файла и используется служба AtomicReadFile для чтения каждого конфигурационного файла из устройства В. Каждый файл может быть считан как поток байтов или как последовательность записей в зависимости от значения свойства File_Access_Method. Файлы читаются в том же порядке, в котором они указаны в свойстве Configuration_Files. Стандарт BACnet не описывает действия устройства А с полученными конфигурационными файлами, хотя, конечно, в общем задача этого сервиса - позволить оператору сохранить настройки устройства В и восстановить их в случае повреждения конфигурации устройства.

Завершение процедуры архивирования: Когда все конфигурационные файлы считаны, устройство А посылает сообщение Reim'tiaLizeDevice (ENDBACKUP, ) в устройство В. Устройство В выполняет все действия, необходимые для завершения архивирования и перевода устройства в состояние, которое было до начала архивирования, или в любое другое состояние, определенное производителем. Устройство В не должно оставаться в режиме BACKUP_IN_PROGRESS после завершения процедуры архивирования. Если устройству А необходимо прервать процесс архивирования (по любой причине, например, пользователь прервал процедуру, устройство В не дает доступ к чтению конфигурационных файлов, или устройство А обнаружило любые другие условия, которые не позволяют выполнить архивирование), также отправляется сообщение ReinitiaLizeDevice (END-BACKUP, ). Если процедура архивирования прервана, все уже считанные конфигурационные файлы не могут считаться актуальными и после возобновления процедуры должны быть считаны заново. Если устройство В не принимает никаких сообщений, связанных с процедурой архивирования от устройства А в течение интервала времени, указанного в свойстве Backup_FaiLure_Timeout, устройство В должно определить эту ситуацию как прекращение выполнения процедуры и самостоятельно выйти из режима архивирования. Сообщения, связанные с процедурой архивирования, определены в следующих службах: ReadProperty, ReadPropertyMuLtipLe, WriteProperty, WritePropertyMuLtipLe, CreateObject, AtomicReadFiLe. Когда архивирование завершено, устройство В устанавливает свойство Backup_and_Restore_State в значение IDLE.

Аналогично рассмотрим процедуру восстановления.

Инициализация процедуры восстановления: Устройство А отправляет сообщение ReinitiaLizeDevice (STARTRESTORE, ) и ожидает ответа от устройства В для продолжения процедуры восстановления.

Подготовка к процедуре восстановления: Перед началом процедуры устройство А считывает свойство Restore_Prepa-ration_Time, если оно представлено, из устройства В. Если свойство не задано, принимается значение 0. После приема сообщения Reini-tiaLizeDevice, если устройство В способно выполнить процедуру восстановления, оно отвечает с ResuLt(+) на данный запрос. Устройство В устанавливает свойство Backup_And_Restore_State в значение PREPARING_FOR_RESTORE. Если устройство В не может выполнить восстановление или уже его выполняет в настоящий момент, то оно отвечает на запрос ReinitiaLizeDevice ответом ResuLt(-). Если устройство B поддерживает процедуру восстановления и запрос был правильно сформулирован, то возможны следующие коды ошибок:

■ DEVICE: CONFIGURATION_IN_PROGRESS - если устройство уже обрабатывает запрос на архивирование или восстановление;

■ SECURITY: PASSWORD_FAILURE - если пароль, указанный в запросе, некорректен или не предоставлен.

После того как устройство В ответило на запрос ReinitiaL-izeDevice ответом ResuLt(+), оно имеет Restore_Preparation_Time секунд для подготовки к процедуре восстановления. В течение этого времени устройство не отвечает ни на какие запросы. Когда подготовка к восстановлению завершена, свойство Backup_And_Restore_State устанавливается в значение PER-FORMING_A_RESTORE. Если устройство В не может успешно завершить подготовку к восстановлению конфигурации, Backup_And_Restore_State устанавливается в значение RESTORE_FAILURE. Устройство А завершает процедуру восстановления при обнаружении значения BACKUP_FAILURE.

Восстановление конфигурационных файлов: Устройство А использует службу AtomicWriteFiLe для записи каждого конфигурационного файла в устройство В. Если какой-либо из файлов не существует в устройстве В, производится попытка создать файл с помощью службы CreateObject. Все файлы, которые уже существовали в устройстве В и отличаются по размеру от записываемых, сначала обрезаются до нулевого размера записью 0 в свойство FiLe_Size и затем новый контент записывается в файл устройства.

Стандарт BACnet не описывает формат и методы валидации контента конфигурационных файлов. Все это определяет производитель оборудования. Устройство В может отклонить операцию записи, если будут обнаружены какие-либо ошибки записи: ошибка CRC, ошибка типа данных и т.п. В этом случае устройство возвращает класс ошибки SERVICES и код ошибки INVALID_CONFIGURATION_DATA. Стандартом не оговаривается, будет ли устройство А повторять попытки записи и как долго это будет производиться, но устройство А должно прервать процедуру восстановления, если устройство В будет продолжать возвращать ошибку.

Завершение процедуры восстановления: Когда устройство А запишет все конфигурационные файлы, в устройство В отправляется сообщение ReinitiaLizeDevice (ENDRESTORE, ). Устройство В выполняет все действия, необходимые для восстановления конфигурационных данных, включая валидацию принятых файлов. Если проверка принятых данных выявляет ошибки, то устройство выставляет в свойстве System_State значение, отличное от DOWNLOAD_IN_PROGRESS.

Если устройству А необходимо прервать процесс восстановления (пользователь прервал процедуру, устройство В не дает доступ к записи конфигурационных файлов и т.д.), отправляется сообщение ReinitiaLizeDevice (ABORTRESTORE, ). После получения этого сообщения устройство В прерывает процедуру восстановления в течение Restore_CompLetion_Time секунд.

Если устройство В не принимает никаких сообщений, связанных с процедурой восстановления, от устройства А в течение ин-

тервала времени, указанного в свойстве Backup_Failure_Timeout, устройство В должно определить эту ситуацию как прекращение выполнения процедуры и самостоятельно выйти из режима восстановления конфигурации. Сообщения, связанные с процедурой восстановления, определены в следующих службах: ReadProperty, ReadPropertyMultiple, WriteProperty, WritePropertyMultiple, CreateObject, AtomicReadFile. Когда восстановление конфигурации завершено, устройство В устанавливает свойство Backup_and_Restore_State в значение IDLE.

ПРИОРИТИЗАЦИЯ КОМАНД BACNET

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

В BACnet арбитраж реализуется встроенной схемой приори-тизации, которая предусматривает различные уровни приоритетов для команд. Каждый объект содержит свойство, которое отвечает за приоритет команд. Следующие свойства объектов участвуют в механизме приоритизации:

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

■ Массив приоритетов: это свойство представляет собой массив значений «только для чтения», содержащий список команд по приоритету в порядке убывания важности. Высший приоритет имеет младший элемент массива. Для объектов BACnet используется фиксированный набор значений приоритетов 1-16. Где 1 - наивысший уровень приоритета. Назначение командам определенных приоритетов осуществляется, главным образом, при конфигурировании системы.

Однако есть несколько стандартных командных приоритетов:

Стандартные приоритеты:

Приоритет Приложение (команда)

1 2 5 6 8

Ручной аварийный выключатель Автоматический аварийный выключатель Критическое управление оборудованием Вкл./Выкл. при достижении минимума Ручное управление оператором

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

Продолжение следует...

скачать
скачать

 

Rambler's Top100 Интернет портал. Каталог фирм. бжд. Охрана. Обеспечение безопасности. Безопасность предприятия. Оборудование. Видеонаблюдение.