Описание реализации автоматизированной системы на примере контура мониторинга и реагирования на источник возгорания. Презентация фрагмента кода на языке программирования высокого уровня Python, демонстрирующего принцип управления системой пожаротушения.
При низкой оригинальности работы "Использование микрокомпьютеров в качестве управляющих элементов автоматизированных систем", Вы можете повысить уникальность этой работы до 80-100%
В качестве управляющего элемента автоматизированной системы, микрокомпьютеры обладают возможностями к быстрому реагированию на те или иные события, к масштабированию автоматизированной системы и к ее полному изменению. Под масштабированием подразумевается возможность изменения как уже существующих компонентов системы (датчиков, реле, исполнительных механизмов), так и добавление или изъятие элементов. Доступ оператора к системе осуществляется либо непосредственно через микрокомпьютер на физическом уровне через технические средства, либо посредством SSH. В таком случае, требуется установка соответствующего программного обеспечения на управляющем элементе системы для взаимодействия компонентов системы друг с другом. В случае с системами наподобие сигнализаций, управляющий элемент системы регистрирует присутствие или отсутствие той или иной величины.
Введение
В качестве управляющего элемента автоматизированной системы, микрокомпьютеры обладают возможностями к быстрому реагированию на те или иные события, к масштабированию автоматизированной системы и к ее полному изменению. Под быстрым реагированием понимаются заранее запрограммированное поведение системы в случае каких-либо возможных событий. Так, в автоматизированной системе климат контроля, событием является выход температуры в помещении за пределы установленной заранее нормы, и управляющий элемент системы реагирует на подобное изменение согласно программе события. Либо активируется открытие окон и включение кондиционирования помещения при повышении температуры, либо обратное, в случае ее понижения. Под масштабированием подразумевается возможность изменения как уже существующих компонентов системы (датчиков, реле, исполнительных механизмов), так и добавление или изъятие элементов. Так, к управляющему элементу можно подключить плату расширения, а к уже имеющемуся определенному количеству датчиков добавить новые. Это возможно благодаря тому, что микрокомпьютер, невзирая на малые размеры, является полноценным персональным компьютером с более широким набором функций нежели "не жестко" запрограммированный (перепрограммируемый) микроконтроллер.
Таким образом, автоматизированная система с микроконтроллером в качестве управляющего элемента способна к полностью автономной работе в режиме 24/7. Доступ оператора к системе осуществляется либо непосредственно через микрокомпьютер на физическом уровне через технические средства, либо посредством SSH. Помимо этого, микрокомпьютер, имея доступ к сети, может быть оснащен веб-сервером и, соответственно, может иметь свою собственную веб-страницу управления и мониторинга системы.
Осуществление функции мониторинга
Слежение за измеряемыми величинами, за теми или иными состояниями исполнительных элементов системы и оборудования - является одной из основополагающих функций системы мониторинга. Контроль за величинами происходит через сравнение значений, передаваемых управляющему элементу системы датчиками с программно заданными значениями. Контроль за состоянием исполнительных элементов также может быть создан на основе сенсоров, таких как гироскоп, если речь идет о положении того или иного механизма в пространстве, или же, к примеру, датчик уровня, отмеряющего высоту, на которую поднялся или опустился механизм. Если исполнительный или контролируемый элемент обладает необходимым программным и аппаратным обеспечением, то о своих состояниях он может отправлять информацию самостоятельно, используя для этого заранее настроенные клиент-серверные протоколы, такие как, например, SNMP TRAP. В таком случае, требуется установка соответствующего программного обеспечения на управляющем элементе системы для взаимодействия компонентов системы друг с другом.
Сложность осуществления мониторинга напрямую зависит от того, за чем именно проводится контроль. В случае с системами наподобие сигнализаций, управляющий элемент системы регистрирует присутствие или отсутствие той или иной величины. Если взять в качестве примера датчик огня, то он либо среагирует на возникновение и присутствие пламени и отправит на микрокомпьютер единицу, либо, в случае отсутствия источников огня, будет отправлять нуль. Частота подачи сигнала программируется. Так, в пожароопасном помещении, сигнал от сенсора может приходить каждые пять секунд или даже меньше. Разумеется, что микрокомпьютер регистрирует и нули, и единицы одинаково. Однако в случае единицы программа управляющего элемента системы начнет выполнение цепочки действий по устранению опасности и извещению оператора о событии. При успешной ликвидации источника возгорания, автоматизированная система отправит уведомление диспетчеру. В данном примере датчик огня является цифровым (дискретным). В соответствии с теорией автоматизированного управления (ТАУ), такой маленький контур состоящий из микрокомпьютера, датчика и устройства оповещения, является простым в расчете, конструктивном исполнении и монтаже.
Если же слежение производится за большим количеством измеряемых величин и требуется знать их точные значения, то серьезнейшим образом изменяется сложность необходимого программного обеспечения, а именно увеличивается трудоемкость написания программного кода. Подобные скрипты должны точно соответствовать поставленной цели. В данном случае, имеется в виду качество кода. Появляется необходимость в тестировании, оптимизации и отладке программ. Такие комплексные системы могут использоваться на заводах и фабриках, к примеру, сталелитейных. Необходим контроль за температурой, за толщиной изготавливаемого материала, за количеством тех или иных смесей при технологическом процессе создания стали, и многое другое. При наличии датчиков и исполнительных механизмов в цепи производства, запрограммированная микрокомпьютерная система будет производить мониторинг и отправлять уведомления с той же точностью, что и в примере с мониторингом за возникновением пламени.
Анализ реализации контура мониторинга и реагирования на источник возгорания
После предварительной установки и настройки микрокомпьютера, к контактам GPIO подсоединяются цифровые датчики пламени (в случае если возможных источников возгорания несколько) и электромеханическое реле. Через реле к микрокомпьютеру подключается система пожаротушения (водяное, порошковое, пенное или газовое) в качестве исполнительного механизма.
Для каждого из элементов системы, контакты GPIO могут быть активированы через операционную систему микрокомпьютера с добавлением выполнения автоматической активации через автозагрузку. Либо, активация осуществляется программным путем через создание класса отвечающего за контакты платы. Это сокращает трудозатраты при возможном последующем добавлении компонентов в систему. В обоих случаях необходимо отредактировать системный файл script.bin, чтобы включить поддержку в ядре операционной системы. Рассмотрим оба этих способа подробнее.
При активации через операционную систему необходимо записать в файл последовательность действий, которые будет совершать система каждый раз, когда она включается. Это исключает ситуации, когда микрокомпьютер был перезагружен, а управляющие команды не сработали, поскольку не были ни кем вызваны. После чего, созданный файл требуется добавить в автозагрузку: # chkconfig имя_файла.
При активации посредством скрипта, программа также добавляется в автозагрузку и использует незначительно видоизменные команды первого метода. Однако существует принципиальная разница. Она заключается в том, что, во-первых, команды соответствуют синтаксическим нормам объектно-ориентированного языка программирования высокого уровня (ООП) на котором написан скрипт, во-вторых, используются специальные символы обращения компилятора и интерпретатора к операционной системе для срабатывания команд из скрипта и, в-третьих, поскольку команды написаны в классе, нет необходимости их переписывать заново в случае если они снова понадобятся, поскольку объемные дублирующиеся участки кода затрудняют как возможность чтения программы так и ее функционирование.
После активации GPIO к контактам подсоединяются датчики, размещенные в местах возможного возгорания. Соответственно, эти контакты постоянно включены, подают питание на датчики и получают от них данные (нуль или единицу). Подключается электромеханическое реле. В зависимости от требуемого количества подсоединяемых проводов, оно может состоять из нескольких блоков. Реле добавляется в цепь питания исполнительного элемента системы, в данном случае шарового моторизованного крана, подающего средства пожаротушения (воду) в разбрызгиватель. В некоторых конструкциях шаровых моторизованных кранов присутствует система инверсии питания. То есть при плюсе на одном контакте и минусе на другом - кран открыт. Кран закрывается при смене плюса на минус и минуса на плюс, а для этого необходимо распараллелить сигналы контактов GPIO для экономии свободных разъемов. Также возможно расширение контура при подключении расходомера воды и датчика напора воды, чтобы идентифицировать наличие или отсутствие воды в трубах. Напор следует измерять до шарового моторизованного крана и после него.
Для отделения контура мониторинга и реагирования на возгорание от других возможных контуров в автоматизированной системе, используется модульная структура, при которой программный код элементов контура "инкапсулируется". Этот тип изоляции одного модуля от другого используется для удобства оператора и разработчиков системы, придавая тем самым структуру всей системе.
При появлении источника пламени, его обнаруживает датчик и отправляет сигнал (единицу) микрокомпьютеру. Тот, в свою очередь, отправляет сообщение оператору о произошедшем событии, активирует контакты реле, запускает открытие шарового моторизованного крана, тем самым начиная процесс тушения возгорания. Это происходит до тех пор, пока датчик обнаружения пламени не сообщит об отсутствии огня. Тогда кран закрывается, и микрокомпьютер отправляет уведомление об успешном устранении опасности.
Вот как выглядит фрагмент программного кода на языке Python с подробными комментариями, выполненный с использованием модульной структуры, элементов объектно-ориентированного программирования (классы) и функций: # Во фрагменте использованы расходомеры воды и датчики напора
# Реагирование на сигнал об обнаружении пламени
# Объявление функции тушения огня def FIREFUNCTION(): if flame == 1: # Выполняется функция отправки уведомления оператору FLAMEMESSAGE(operator)
# Отключены контакты GPIO поддерживающие выключенной состояние шарового моторизованного крана
# Импортирован класс управления шаровым моторизованным краном import Cvalve
# В классе Cvalve заранее прописано открытие крана
# Если датчик напора воды посылает сигнал об отсутствии напора if WATERPRESSURE == 0: # Выполняется функция отправки уведомления оператору об отсутствии воды
WATERPRESSUREABSENCE(operator)
# Если вода присутствует, уведомления не отсылаются
# Когда сенсор пламени перестал идентифицировать огонь if FLAMESENSOR == 0: # Выполняется функция отправки уведомления оператору об устранении огня
STOPFIREMESSAGE(operator)
# Выполняется функция завершения пожаротушения STOPFIREFUNCTION()
# Объявление функции завершения пожаротушения def STOPFIREFUNCTION(): # Производится закрытие крана DEACTIVATEGPIO(1, 4) ACTIVATEGPIO(2, 3)
# Проверка присутствия напора воды после закрытия крана (ошибка: кран не был закрыт) if WATERPRESSURE == 1: # Отправление уведомления оператору об ошибке WATERPRESSUREPRESENCE(operator)
# Переменная FLAMESENSOR равна сигналу, приходящему с датчика на микрокомпьютер
# Пока датчик идентифицирует пламя, выполняется функция ликвидации возгорания if FLAMESENSOR == 1: # Используются разноименные переменные, чтобы избежать ошибок в коде изза области видимости переменных flame = 1
# Вызов функции тушения огня FIREFUNCTION()
Следует обратить внимание на обработку ошибок. В представленном выше фрагменте присутствуют уведомления WATERPRESSUREABSENCE и WATERPRESSUREPRESENCE. Поскольку данные ошибки обозначенная выше система исправить неспособна, она отправляет соответствующие сообщения оператору. Обработки ошибок во фрагменте кода являются функциями, поскольку предусматривается, что оператор может не находиться у монитора, демонстрирующего работу именно этого контура. Поэтому оператору отправляется SNMP сообщение по электронной почте. Для подобной системы характерно присутствие звукового сигнала в случае ошибок или при регистрации опасных ситуаций. В таком случае, в контур добавляются генераторы звуковых сигналов. Они, как правило, дискретны, и их легко интегрировать в систему. Тогда, функции WATERPRESSUREABSENCE и WATERPRESSUREPRESENCE заменяются простыми функциями подачи звукового сигнала.
В любой автоматизированной системе, контролю за возможными ошибками, такими как-то или иное несрабатывание механизмов и скриптов, должно уделяться повышенное внимание. В особенности, если система будет полностью автономной. Необходимо вести файлы учета действий системы, в зависимости от ее профиля. В продемонстрированном выше примере этот файл выглядел бы таблицей, в которой было бы зафиксировано время активации системы пожаротушения, расход воды в процессе эксплуатации, время уведомления оператора и время отключения системы. Таким образом, благодаря, так называемым, логам, предоставляется возможность по сбору системной статистики.
Выводы по анализу
Микрокомпьютер, в качестве управляющего элемента автоматизированной системы, является ключевым элементом, запускающим скрипты и протоколы, тем самым осуществляя контроль величин и работоспособность процессов. Микрокомпьютеры обладают всеми стандартными шинами передачи данных и дистрибутивами операционных систем, что делает автоматизированные системы соответствующими современным требованиям к цифровым устройствам. Управляющий элемент осуществляет мониторинг за всеми подключенными к системе комплектующими и получает от них информацию с одинаковой однородной частотой в запрограммированные промежутки времени для синхронности выполнения тех или иных действий в зависимости от событий. Автоматика системы предполагает наличие технического перезапуска системы в случае обновления пакетов программ и программного обеспечения, что также учитывается при разработке. В целях бесперебойной работы и оптимизации емкости рабочего пространства жесткого диска требуется добавление всех функционирующих постоянно скриптов в автозагрузку, для их автоматического запуска после включения или перезагрузки системы. Программный код, выполненный с соблюдением модульной структуры с использованием классов и с регистрацией ошибок, обеспечивает безотказность системы и оптимизирует трудоемкую работу программистов и инженеров в области автоматизации. Модульность создает возможность оптимизации и масштабирования системы. Это позволяет подключать больше периферийных элементов и комплектующих. Операционная система семейства Linux позволяет осуществлять коммутацию данных между устройствами и дает доступ к использованию протоколов для связи с оператором в случае возникновения запрограммированного события. Благодаря простоте подключение дополнительных устройств, основная сложность заключается именно в написании программного кода для различных элементов модульной системы управления, мониторинга и реагирования. Однако доступность различных сред разработки, большое число языков программирования высокого уровня и обилие информации по техническим особенностям написания кода в сети позволяет значительно сократить время создания требующегося программного обеспечения с соблюдением высокого качества работы.
Микрокомпьютеры все еще являются относительно недавно появившимися новшествами в мире цифровых технологий, однако их потенциал весьма велик благодаря сходству мощностей с полноценными системными блоками. Это позволяет экспериментировать с системой, создавать новые варианты существующих разработок и проектировать прототипы - комплексы, никогда ранее не существовавшие. Благодаря возможности объединения микрокомпьютеров в кластер, можно увеличить мощность системы, а значит, один управляющий элемент способен контролировать все аспекты функционирования электронных систем в отдельно взятом здании. Однозначно, не будет преувеличением заявить, что микрокомпьютеры значительно превосходят микроконтроллеры в сфере автоматизированных систем, и со временем, их технические характеристики и возможности будут только увеличиваться и совершенствоваться. автоматизированная программирование мониторинг управление
Список литературы
1. Оськин Д.А., Феоктистов Н.А. Использование микрокомпьютеров при решении задач масштабирования автоматизированных систем сбора информации и реагирования на события // Интернет-журнал "НАУКОВЕДЕНИЕ" Том 7, №1 (2015) http://naukovedenie.ru/PDF/ 108TVN115.pdf (доступ свободный). Загл. с экрана. Яз. рус., англ. DOI: 10.15862/108TVN115.
2. Стахнов А.А. Linux: 4-е изд., перераб. и доп. - СПБ: БХВ-Петербург, 2011. - 752 с.: ил. - (В подлиннике).
3. Крэйг Хант TCP/IP. Сетевое администрирование, 3-е издание. - Пер. с англ. - СПБ: Символ-Плюс, 2014. - 816 с., ил.
4. Гифт Н. Python в системном администрировании Unix и Linux. - Пер. с англ. - Символ-Плюс, 2015. - 512с., ил.
5. Маккинни У. Python и анализ данных. - Пер. с англ. - ДМК Пресс, 2015. - 481 с., ил.
6. Иванова Г.С. Объектно-ориентированное программирование. - МГТУ им. Н.Э. Баумана, 2014. - 455 с., ил.
8. Гоше Х.Д. HTML 5. Для профессионалов. 2-е изд. - СПБ: Питер, 2015. - 560 с.: ил. - (Серия "Для профессионалов").
9. Герлиц Е.А., Кулямин В.В., Максимов А.В. Тестирование операционных систем. Журнал Труды Института системного программирования РАН Выпуск №1 / том 26 / 2014.
10. Лафоре Р. Объектно-ориентированное программирование в С . Классика Computer Science. 4-е изд. - СПБ.:? Питер, 2012. - 928 с.: ил.
References: 1. Os"kin D.A., Feoktistov N.A. Ispol"zovanie mikrokomp"yuterov pri reshenii zadach masshtabirovaniya avtomatizirovannykh sistem sbora informatsii i reagirovaniya na sobytiya // Internet-zhurnal "NAUKOVEDENIE" Tom 7, №1 (2015) http://naukovedenie.ru/PDF/108TVN115.pdf (dostup svobodnyy). Zagl. s ekrana. Yaz. rus., angl. DOI: 10.15862/108TVN115.
2. Stakhnov A.A. Linux: 4-e izd., pererab. i dop. - SPB: BKHV-Peterburg, 2011. - 752 s.: il. - (V podlinnike).
3. Kreyg Khant TCP/IP. Setevoe administrirovanie, 3-e izdanie. - Per. s angl. - SPB: Simvol-Plyus, 2014. - 816 s., il.
4. Gift N. Python v sistemnom administrirovanii Unix i Linux. - Per. s angl. - SIMVOLPLYUS, 2015. - 512 s., il.
5. Makkinni U. Python i analiz dannykh. - Per. s angl. - DMK Press, 2015. - 481 s., il.
6. Ivanova G.S. Ob"ektno-orientirovannoe programmirovanie. - MGTU im. N.E.
