CC BY
28
УДК 681.514.015
Профессор В.В. Шитов, аспирант Д.Ю. Уразов
(Воронеж: гос. ун-т. инж технш.) кафедра промышленной энергетики, гея. (473) 255-44-66 доцент А.Н. Рязанов
(Воронеж. гос. ун-т. инж. технш.) кафедрамашин а и аппараговпищевых производив, тег. (473) 255-38-96 доцент А.Л. Ивашин
(Воронеж. гос. ун-т. инж. технш.) кафедраинфсрмащонныхтехнологий моделирования и управления, тел. (473) 255-25-50
Разработка архитектуры программного обеспечения универсальной системы тепловизионной диагностики
Формирование требований и разработка архитектуры программного обеспечения универсальной системы тепловизионной диагностики. Описание базовых алгоритмов функционирования системы.
Formation of requirements and the development of the software architecture of a universal system thermal imaging diagnostics. Description of the basic algorithms of the system.
Ключевые слова: тепловизионная диагностика, архитектура программной системы.
Целью разработки универсальной тепловизионной системы является обеспечение выполнения следующих функций в автоматическом режиме: обеспечение работы с тепло-визионным устройством (тепловизионной камерой); указание методов и условий оповещения пользователя в случаях выхода температуры объекта за рамки допустимых значений; осуществление сохранения статистической информации в процессе слежения и генерирование отчетности по ней.
Разрабатываемая интеллектуальная система должна поддерживать приведенные ниже режимы функционирования: основной режим, в котором выполняются все поддерживаемые функции; профилактический режим, в котором выполнение всех функций не гарантированно, за исключением функции регистрации.
Основной режим предполагает выполнение всех функций в режиме (24x7). В профилактическом режиме обеспечивается техническое обслуживание и устранение аварийных ситуаций.
Общее время проведения профилактических работ не должно превышать 1% от общего времени работы системы в основном режиме всего времени эксплуатации в рамках одного цикла.
© Шитов В.В., Уразов Д.Ю., Рязанов А.Н., Ивашин А.Л., 2013
Структурная схема разрабатываемой системы приведена на рисунке 1. На данной схеме под смешанным взаимодействием подразумевается, что обмен данными может производиться или по сетевому протоколу или с использованием, например, разделяемой памяти внутри локальной машины.
Источник данных
Внутримашинное взаимодействие Сетевой протокол
" " " " Смешанное взаимодействие
Рисунок 1 - Структурная схема подсистем
Ниже приведены требования к функциям разрабатываемых подсистем.
Подсистема сбора данных, которая предназначена для реализации процессов сбора данных из систем источников, приведения указанных данных к виду, необходимому для наполнения подсистемы хранения данных, обеспечивает выполнение следующих функций:
- интерпретацию полученных от источника данных в пригодную для дальнейшей обработки форму [1,2];
- осуществление вычислений по модели искомых параметров.
Подсистема формирования отчетности должна обеспечивать выполнение следующих функций:
- формирование текущей (регулярной) отчетности о состоянии работы системы;
- формирование аварийной отчетности, возникающей в случае вывода измеряемых или расчетных показателей за допустимые пределы;
- оперативное извещение пользователей о нештатных ситуациях в процессе работы системы.
Таблица 1
Уровни оповещения
Уровень Наименование уровня Описание уровня
0 Уровень неработоспособности Сигнализирует о невыполнении системой собственных функций по управлению и/или мониторингу
1 Уровень ошибок Сигнализирует о наличии ошибок в устройствах любых описанных выше классов
2 Уровень предупреждений Показывает наличие неполадок, неустранение которых приведет систему на уровень ошибок
3 Уровень оповещений Предупреждает о достижении некоторым параметром установленного предела
4 Информационный уровень Показывает значение некоторого параметра с установленной периодичностью
С учетом общей клиент-серверной архитектуры системы, разумным методом реализации оповещения является оповещение посредством электронной почты. Функционал реализуемой подсистемы должен включать в себя следующие возможности:
- привязка адресов электронной почты к пользователям системы;
- настраиваемые параметры управления рассылкой (по времени, по уровням оповещения в таблице 1);
- настраиваемые параметры управления видом и объемом отчетности.
Подсистема хранения данных, которая предназначена для оперативного и долговременного хранения в структурах, нацеленных на принятие решений и формирование отчетности, должна обеспечивать выполнение следующих функций:
- хранение в течение заданного периода актуальных данных;
- помещение в архив данных, потерявших свою актуальность.
С точки зрения эффективности работы системы следует разбиение хранилища на два непересекающихся подмножества:
- основное или оперативное хранилище -для показаний, используемых часто в текущих расчетах;
- архивное хранилище или история - для показаний, используемых крайне редко. Принимаемые данные от источника после
проверки изначально попадают в оперативное хранилище. Спустя период времени, после которого они теряют свою актуальность для процесса управления, данные автоматически переносятся в архивное хранилище. При переносе в архивное хранилище производится процесс прореживания, в результате которого можно сократить информа-
ционный объем без существенной потери в качестве. Процесс переноса данных в архивное хранилище инициируется системой самостоятельно на основе факта утери актуальности данных.
Подсистема взаимодействия с пользователем обеспечивает выполнение следующих функций:
- осуществление первичной и оперативной настройки;
- определение и изменение расписания процессов сбора данных;
- сигнализация аварийных ситуаций и мониторинг текущего состояния тепловой карты;
- извещение пользователей о нештатных ситуациях в процессе работы системы. Для программного обеспечения системы
предъявляется перечень следующих независимых программных средств, а также требования:
- использование открытой реляционной системы управления базами данных PostgreSQL 9.2.0;
- использование открытой операционной среды Debian GNU/Linux 6.0 («Squeeze»);
- открытая платформа разработки Java SE 1.7.
<ЪестникФТУЖЛС, №3, 2013
Java - это одновременно язык программирования и платформа, представляет собой высокоуровневый объектно-ориентированный язык программирования. При компиляции, которая выполняется один раз во время сборки приложения, код на Java преобразуется в код на промежуточном языке (байт-код). В свою очередь, байт-код анализируется и выполняется (интерпретируется) виртуальной машиной Java (JVM). Все реализации Java, включая 1.7, должны эмулировать JVM, чтобы создаваемые приложения могли выполняться на любой системе, включающей виртуальную машину Java.
Java - это программная платформа, версии которой поставляются для различных аппаратных систем. Платформа включает в себя JVM и интерфейс прикладного программирования на Java (API), представляющий собой обширный набор готовых программных ком -понентов (классов), облегчающих разработку и развертывание апплетов и приложений. API Java охватывает многие аспекты разработки на Java, в том числе манипулирование базовыми объектами, сетевое программирование, обеспечение безопасности, генерацию XML и Web-сервисы. API организован в виде набора библиотек, именуемых пакетами, которые содержат классы и интерфейсы для решения связанных друг с другом задач.
В дополнение к API каждая полноценная реализация платформы Java должна включать следующее:
- инструментарий разработчика для компиляции, запуска, мониторинга, отладки и документирования приложений;
- стандартные механизмы развертывания приложений в пользовательской среде;
- инструментарии, позволяющие создавать сложные графические интерфейсы пользователей;
- интеграционные библиотеки для программного доступа к базам данных и удаленного манипулирования объектами.
Ниже приводятся требования к составу, структуре и способам организации данных в системе.
Исходя из высокого информационного потока между компонентами интеллектуальной системы, выдвигается требование централизо-ванности хранения данных, это означает, что оперативные и долговременные данные долж-ны располагаться в центральном хранилище. Система должна иметь трехуровневую архитек-туру (рисунок 2), обусловленную различными техническими средствами связи между функ-циональными блоками и протоколами обмена
данных. Первый уровень (функциональный блок) - источник оперативной термографической информации, второй - хранилище опера -тивных и долговременных данных, третий -блок принятия решения, визуализации и генерирования статической отчетности. Г " """
, Конечные пользователи системы I
Уровень принятия решения, визуализации и генерирования статической отчетности
База данных
Уровень обработки оперативной термографической информации
] Источник термографической информации i
________________________I
Рисунок 2 - Архитектура системы
Процесс работы системы, как было указано выше, может проистекать в одном из режимов функционирования. Наиболее интересен основной режим, в нем система производит получение и обработку данных, а также работу с пользовательским интерфейсом и генерирование отчетов и оповещений. Работа с пользовательским интерфейсом производится с использование библиотеки ApacheClick.
В работе показаны требований к архитектуре программного обеспечения универсальной системы тепловизионной диагностики.
Статья подготовлена по результатам работ, выполненных на оборудовании ЦКП «КУ-ЭП» ФГБОУ ВПО «ВГУИТ».
ЛИТЕРАТУРА
1 Буча, В.В. Алгоритмы интерактивного выделения объектов на цифровых изобра-жениях местности [Текст]: автореф. дис. ... канд.техн. наук.
2 Поляков, А.Ю. Методы и алгоритмы компьютерной графики на Visual C++ [Текст] / А.Ю. Поляков, А.В. Брусницев. - СПб.: БХВ-Петербург, 2003. - 503 с.
REFERENCES
1 Bucha, V.V. Algorithms interactive selection of objects in digital images areas [Text]: ab-str. diss. ... PhD.
2 Polyakov, A.Y. Methods and algorithms of computer graphics of Visual C++ [Text] / A.Y. Polyakov, A.V. Brusnitcev. - SPb.: BHV-Петербург, 2003. - 503 p.
Уровень хранения оперативных и долговременных данных
