Содержание к диссертации
Введение
Глава 1. Анализ основных особенностей систем сбора, хранения, анализа и визуализации массивов данных 10
1.1. Введение 10
1.2. Функциональные возможности систем сбора, хранения, анализа и визуализации массивов данных 12
1.3. Анализ особенностей приложений сбора, хранения, анализа и визуализации массивов Данных 21
1.4. Основные выводы 46
1.5. Постановка задач исследования 47
Глава 2. Исследование и разработка системы сбора, хранения, анализа и визуализации массивов данных, поступающих с территориально распределенных источников 49
2.1. Использование приемов объектно-ориентированного программирования при разработке сложных систем 49
2.2. Использование паттернов проектирования при разработке сложных систем 50
2.3. Функциональные возможности предлагаемой системы 51
2.4. Общие принципы разработки системы 53
2.5. Описание структуры системы сбора, хранения, анализа и визуализации массивов данных 55
2.6. Уровень "хранилище данных" 57
2.7. Уровень "доступ к данным" 58
2.8. Уровень "бизнес-логика" 59
2.9. Разработка модулей анализа данных 2.10. Уровень "ввод-вывод" 68
2.11. Конфиденциальность данных во время передачи по каналам связи 69
2.12. Уровень "представление" 72
2.13. Методы повышения быстродействия и надежности с помощью технологий кластеризации 74
2.14. Методика защита системы от нелегального использования 78
2.15. Выводы по главе 81
Глава 3. Пример использования предлагаемой системы сбора, хранения, Анализа и визуализации массивов технологических параметров как часть концепции интеллектуальной системы управления процессом обжига сульфидных цинковых концентратов в печах кипящего слоя 82
3.1. Постановка задачи 82
3.2. Назначение процесса обжига в гидрометаллургическом способе получения металлического цинка 83
3.3. Технологические особенности обжига сульфидных цинковых концентратов в печах Кипящего слоя 86
3.4. Основные проблемы обжига сульфидных цинковых концентратов. Причины и способы Устранения 89
3.5. Автоматизация процесса обжига сульфидных цинковых концентратов в печах кипящего слоя 92
3.6. Подсистема "rznanalyticssys" и ее место в асутп 105
3.7. Создание и использование имитационной модели процесса обжи га 106
3.8. Создание математической модели процесса обжига 112
3.9. Оценка эффективности разработанной системы 122
3.10. Выводы по главе 123
Глава 4. Пример использования предлагаемой системы сбора, хранения, анализа и визуализации массивов данных как автоматизированной системы оценки качества знаний 124
4.1. Постановка задачи 124
4.2. Использование современных информационных технологий в оценке качества знаний 125
4.3. Создание списка факторов, которые могут в той или иной степени влиять на успеваемость тестируемых 129
4.4. Архитектура системы "testgen" 130
4.5. Схема распределения потоков данных 133
4.6. Подсистема создания и редактирования тестовых заданий testmaker 134
4.7. Подсистема проведения тестирования testreader 137
4.8. Подсистема визуализации результатов тестирования resultviewer 138
4.9. Подсистема ввода данных и объединения результатов тестирования testreporter
4.10. Модуль testanalyser 141
4.11. Базы централизованного хранения данных 142
4.12. Применение отраслевой модификации системы 142
4.13. Пример автоматизированного анализа зависимости оценки от нескольких факторов 144
4.14. Оценка эффективности разработанной системы 147
4.15. Выводы по главе 150
Заключение 151
Литература 153
- Анализ особенностей приложений сбора, хранения, анализа и визуализации массивов Данных
- Функциональные возможности предлагаемой системы
- Технологические особенности обжига сульфидных цинковых концентратов в печах Кипящего слоя
- Подсистема создания и редактирования тестовых заданий testmaker
Анализ особенностей приложений сбора, хранения, анализа и визуализации массивов Данных
В проанализированных продуктах сбор данных осуществляется либо специализированными модулями (входящими в состав программного комплекса) либо отсутствует вовсе. В некоторых случаях сбором данных занимается стороннее программное обеспечение (как правило, специально разработанное под конкретную задачу), либо данные берутся из общеизвестного централизованного хранилища, например, системы управления базами данных (СУБД).
В промышленности системой сбора данных может выступать система диспетчерского контроля и сбора данных (Supervisory Control And Data Acquisition — SCADA-система), хранящая данные в реляционной СУБД промышленного типа или структурированных файлах типа XML [4].
В образовании системами сбора данных могут выступать специализированные программные продукты для создания и проведения контрольных работ, опросов, тестов и т.д. Зачастую такие программные продукты включают в себя подсистемы создания тестов, механизмы проведения тестирования и подсистемы хранения и визуализации результатов.
Помимо этого, данные могут передаваться в систему анализа с помощью технологии ОРС. ОРС - OLE (Object Linking and Embedding) for Process Control - семейство программных технологий, предоставляющих единый интерфейс для обмена данными, управления объектами автоматизации и технологическими процессами [5]. Многие из ОРС протоколов базируются на Windows-технологиях: OLE, ActiveX, COM/DCOM. Такие ОРС протоколы, как ОРС XML DA и ОРС UA являются платформо-независимыми (т.е. работают без изменений в различных операционных системах). На данный момент используется ОРС версии 3.0, однако наиболее распространенной версией сегодня является 2.05а. Относительно недавно был разработан стандарт ОРС UA (Unified Architecture), унифицирующий набор функций для обмена данными, регистрации событий, хранения данных, обеспечения безопасности данных [6].
Широко распространенные программные комплексы (например, Microsoft Excel) позволяют вводить данные вручную с клавиатуры. Как правило, такой возможностью обладают настольные продукты, разработанные для анализа данных. Пользовательский интерфейс в подобных программах представлен в виде таблицы, в ячейки которых заносятся значения.
Многие клиент-серверные СУБД дополнительно комплектуются программным обеспечением для удаленного управления (например, Management Studio для Microsoft SQL Server), которое также позволяет ручной ввод непосредственно в таблицу базы данных [7].
Хранение данных может осуществляться несколькими способами, например: — Хранение данных в централизованном хранилище, например в клиент-серверных СУБД, таких как реляционные СУБД Microsoft SQL Server, Oracle, MySQL или объектно-ориентированных СУБД, таких как Cache. Это наиболее распространенный способ, так как при таком подходе функциональность, производительность, стоимость и ряд других параметров системы хранения находятся на оптимальном уровне. — Хранение данных в структурированных файлах открытого типа (например, XML), простых текстовых файлах (например, файлах с разделителями CSV) или в файл-серверных СУБД (например, Microsoft Access или HSQLDB). Это менее распространенный способ хранения, так как при увеличении объема данных, заметно падает производительность операций доступа к данным. Однако, при небольших объемах данных такой способ часто используется в реальных коммерческих приложениях. — Хранение данных в файлах бинарного типа в специально разработанном производителем под данную задачу формате или встраиваемой СУБД (например, SQLite). Такой способ хранения используется производителями при проектировании программных комплексов, в которых реализованы все функции: сбор, хранение, анализ и визуализация. На практике встречается достаточно редко.
Для обработки данных в программных комплексах применяются различные типы алгоритмов. Основными из них являются: — Алгоритмы на основе теории вероятностей и математической ста тистики - наиболее распространенные в науке и инженерной дея тельности алгоритмы анализа [1, 8, 9, 10]. Большинство используемых методов опираются на статистическую парадигму, в которой главны ми фигурантами служат усредненные характеристики выборки. Мето ды оценивания и проверки гипотез опираются на вероятностные мо дели порождения данных. Модели делятся на параметрические и не параметрические. В параметрических моделях предполагается, что изучаемые объекты описываются функциями распределения, завися щими от небольшого числа (1-6) числовых параметров. В непарамет рических моделях функции распределения предполагаются произ вольными непрерывными. С помощью алгоритмов математической статистики оценивают параметры и характеристики распределения (математическое ожидание, медиану, дисперсию, квантили и др.), плотности и функции распределения, зависимости между переменными (на основе линейных и непараметрических коэффициентов корреляции, а также параметрических или непараметрических оценок функций, выражающих зависимости) и др. Основными типами анализа, построенных на алгоритмах математической статистики являются: дисперсионный анализ, регрессионный анализ, анализ временных рядов, факторный анализ, дискриминантный анализ и кластерный анализ.
Алгоритмы на основе аналогий. Для того, чтобы сделать прогноз на будущее или выбрать правильное решение, алгоритмы подобного типа находят в прошлом близкие аналоги наличной ситуации и выбирают тот же ответ, который был для них правильным. Иногда этот метод называют "методом ближайшего соседа". В последнее время получил распространение термин memory based reasoning, который акцентирует внимание на том, что решение принимается на основании всей информации, накопленной в памяти. Системы анализа, использующие подобные алгоритмы, показывают неплохие результаты в самых разнообразных отраслях. Главным их минусом специалисты считают то, что они вообще не создают каких-либо моделей или правил, обобщающих предыдущий опыт, — в выборе решения они основываются на всем массиве доступных исторических данных, поэтому невозможно определить, на каких конкретно факторах данные алгоритмы строят свои ответы. Еще одним недостатком считают произвол, который допускают данные алгоритмы при выборе меры "близости". От этой меры самым решительным образом зависит объем множества прецедентов, которые необходимо хранить в памяти для достижения удовлетворительной классификации или прогноза [11].
Функциональные возможности предлагаемой системы
Массивы данных из территориально распределенных источников по локальной сети или сети Интернет поступают на вход службы приема-передачи данных в подсистему приема массивов данных. Далее массивы под управлением ядра системы и с помощью провайдера данных помещаются в базу(ы) централизованного хранения анализируемых данных. Если помимо анализируемых данных необходимо хранить специальные дополнительные (служебные) данные, то они размещаются в базе централизованного хранения дополнительных данных. Доступ к ним осуществляется под управлением ядра системы с помощью двух провайдеров: провайдера специализированных данных и провайдера баз данных.
Настройки системы хранятся в специальном конфигурационном файле, доступ к которому может осуществляться удаленно, одновременно несколькими экземплярами системы. Все алгоритмы анализа хранятся в специальных библиотеках анализа данных. В автоматическом режиме (например, по таймеру) или при запросе оператора, система начинает проводить анализ данных. Контроль над выполнением анализа данных проводится с помощью системы управления. В стандартной конфигурации система управления состоит из трех подсистем: подсистемы контроля и управления процессом анализа, подсистемы определения спецификаций хранимых и анализируемых данных (первые две подсистемы взаимодействует с ядром системы посредством провайдера терминального доступа), а так же подсистемы визуализации результатов анализа (взаимодействует в одностороннем порядке с ядром системы с помощью службы приема-передачи данных, а конкретно — подсистемы передачи результатов анализа).
Базовая структура предлагаемой системы сбора, хранения, анализа и визуализации массивов данных представлена на рис. 2.3. Источник данных Источник данных Источник данных К
В случае, когда анализируемые массивы данных представляют собой наборы численных значений, система управления может быть представлена в минимальной конфигурации и состоять только из двух модулей (подсистемы визуализации результатов анализа и подсистемы контроля и управления процессом анализа), программно объединенных в одно приложение.
На данном уровне располагаются база централизованного хранения анализируемых данных и базы централизованного хранения дополнительных данных (например, база данных химических свойств веществ).
Для систем анализа, предназначенных для работы с небольшим массивом данных, в качестве хранилища могут использоваться базы файл-серверной СУБД Microsoft Access или структурированные XML-файлы. Для больших массивов данных лучше всего использовать высокопроизводительные клиент-серверные реляционные системы управления базами данных. Как видно из Главы 1 в настоящее время это:
На данном уровне располагается специализированное программное обеспечение (поставщики данных), отвечающее за взаимодействие ядра (уровень "Бизнес-логика") и баз данных (уровень "Хранилище данных").
Для каждого типа базы данных предназначен свой поставщик (провайдер) данных - коннектор (data base connector) [48].
Программные компоненты, расположенные на этом уровне, в основном, представляют собой библиотеки Microsoft ADO.NET 2.0 и специализированные программные методы для управления и администрирования автономных объектов и баз данных [16, 49]. Укрупненная схема взаимодействия уровня "Доступ к данным" со смежными уровнями показана на рис. 2.4.
Паттерн "Facade" — предоставляет унифицированный интерфейс к множеству интерфейсов в некоторой подсистеме. Определяет интерфейс более высокого уровня, облегчающий работу с подсистемой. Структура паттерна с использованием языка UML [51] представлена на рис. 2.5. i-acaae -7Г ClassA \ ClassB ClassC ClassAI ClassA2 \ ClassBI ClassB2 Рис. 2.5. Структура паттерна "Facade Где Facade - фасад, который "знает", каким классам подсистемы адресовать запрос и делегирует запросы клиентов подходящим объектам внутри подсистемы; ClassA, ClassAI, ClassA2, ClassB, ClassBI, ClassB2, ClassC — классы подсистемы, реализуют ее функциональность, выполняя работу, порученную объектом Facade.
На уровне "Бизнес-логика" располагается центральный компонент системы - ядро. Ядро системы является связывающим звеном всех остальных компонентов.
Ядро связывается с остальными компонентами посредством вызова событий (events). Для реализации этой функциональности был использован паттерн Observer.
Паттерн Observer — определяет между объектами зависимость типа "один-ко-многим", так что при изменении состояния одного объекта все зависящие от него получают извещение и автоматически обновляются. Структура паттерна представлена на рис. 2.6. с observer Observer Attach(Observer) Detach(Observer) NotifyO Update() / Л \ ConcreteSubject subject ConcreteObserver GetState() — SetStateO Update() . - return subjectState I observerState 1 subjectState observerState = subject - GetStateQ
Структура паттерна Observer. Где Subject — субъект, располагает информацией о своих наблюдателях (за субъектом могут "следить" несколько наблюдателей), предоставляет интерфейс для присоединения и отделения наблюдателей; Observer -наблюдатель, определяет интерфейс обновления для объектов, которые должны быть уведомлены об изменении субъекта; ConcreteSubject — конкретный субъект, сохраняет состояние, представляющее интерес для конкретного наблюдателя ConcreteObserver и посылает информацию своим наблюдателям, когда происходит изменение; ConcreteObserver — конкретный наблюдатель, хранит ссылку на объект класса ConcreteSubject, сохраняет данные, которые должны быть согласованы с данными субъекта, реализует интерфейс обновления, определенный в классе Observer, чтобы поддерживать согласованность с субъектом.
Модули анализа данных функционально находятся на уровне "Бизнес-логика" и напрямую взаимодействуют с ядром системы посредством открытого интерфейса прикладного программирования (Application Programming Interface, API).
Модульность системы и открытый API позволяет при необходимости создавать неограниченное количество разнообразных библиотек анализа и подключать их к работающей системе. В базовой комплектации предлагаемая система снабжена следующими модулями анализа данных:
Технологические особенности обжига сульфидных цинковых концентратов в печах Кипящего слоя
Схема работы подсистемы RZnAnalyticsSys и ее взаимодействия с АСУТП. Массивы технологических данных (параметров) от имитационной модели процесса и SCADA-системы поступают службе приема-передачи данных (в подсистему приема). Под управлением ядра системы данные помещаются в базу централизованного хранения. При необходимости (в случае команды оператора или при возникновении внештатной ситуации) с помощью подсистемы контроля и управления процессом анализа и с учетом заданных спецификаций данные извлекаются из базы и анализируются. Тип анализа, выборку данных и другие необходимые параметры задаются с помощью подсистемы определения спецификации хранимых и анализируемых данных. Методы анализа выбираются из имеющихся в библиотеки анализа данных. Результаты анализа визуализируются и передаются в подсистему поддержки принятия решений (для генерации рекомендаций).
Необходимо отметить, что все механизмы управления подсистемой "RZnAnalyticsSys" и инструменты визуализации результатов сосредоточены в SCADA-системе АСУТП (т.е. являются ее частью). Взаимодействие SCADA-системы и ядра подсистемы "RZnAnalyticsSys" осуществляется посредством провайдера терминального доступа.
В разное время исследованием процессов (физических, химических, газодинамических, гидродинамических и т. д.), протекающих в кипящем слое занимались многие советские (российские) и зарубежные ученые. Среди них необходимо отметить И. А. Бурового [104,105], Л. А. Данилина [106, 107,108], Д. Куний и О. Левеншпиля (США) [109], В. Г. Айнштейна [110] и многих других.
Прикладными аспектами процесса обжига сульфидных цинковых концентратов в разное время занимались: Э. Ю. Серебренникова [67, 69, 70, 71, 72, 94], А. Д. Бессер [77, 94], М. С. Зак [70, 71, 72, 94], Лейзерович [69, 77, 94] и другие.
В настоящее время существует ряд коммерческих разработок. На рынке программного обеспечения предлагается французская программа, представляющая собой систему моделирования процесса обжига сульфидных цинковых концентратов в печи КС [111]. По утверждению разработчиков, основными возможностями программы являются: - детальный расчет окисления сульфидов;
Для моделирования работы обжиговой печи была создана имитационная модель процесса обжига. Основное предназначение данной модели -генерация массивов технологических параметров, так как если бы данные бы предоставила SCADA-система. Термохимические расчеты Термохимические расчёты, являющиеся основой модели процесса обжига цинковых концентратов, получены на основе фундаментальных законов термодинамики, а также законов, предложенных такими выдающимися учёными, как: Авогадро, Гей-Люссак, Бойль, Мариотт, Кирхгоф и др. [112, 113]. В свою очередь эти законы были в разное время получены и сформулированы путём анализа экспериментальных, или природных статистических данных. В связи с этим, полученные автором математические модели являются реальными, а не виртуальными.
При составлении алгоритма расчёта материального и теплового балансов, а также формирования плана эксперимента, были использованы материалы, представленные в работе [114].
Термохимические данные для расчета обжига взяты в основном из источника [113]. Средние теплоемкости компонентов концентрата, огарка, газов и пыли (кДж/(кг.К)) рассчитывали для заданного диапазона температур с помощью следующей формулы:
При этом теплотой превращений исходных и конечных продуктов при обжиге пренебрегли в связи с их малостью. Уравнения, связывающие зависимость теплового эффекта реакций обжига с температурой, приведены в программе в общепринятом в химии виде. Во всех уравнениях температура выражена в градусах Кельвина, а тепловой эффект в кДж/кг. Например, для реакции окисления сульфида цинка Расчёт производительности печи
Для расчёта рабочей скорости дутья, которая определяет производительность печи, использовали следующую формулу, полученную методом анализа размерностей [114]: где и — рабочая скорость дутья в печи, м/с; d — эквивалентный диаметр частиц огарка, м; рг — плотность газа в кипящем слое, как функция состава и температуры, кг/м ; р — плотность твердых частиц, кг/м . Имитационная модель базируется на работах [115, 116, 117].
Полностью формулы, использованные при создании имитационной модели, приведены в Приложении 2.
Имитационная модель оформлена в виде отдельного класса (динамической библиотеки) разработанного на языке программирования высокого уровня Microsoft Visual Basic 2008 под платформу Microsoft .NET Framework 2.0. Такое решение позволяет использовать имитационную модель как специализированный поставщик данных (виртуально устройство) в составе SCADA-системы или при подключении к графическому интерфейсу как отдельное приложение. При этом графический пользовательский интерфейс программы использует библиотеки WinForms. При реализации подсистемы вывода использовались библиотеки движка Microsoft Internet Explorer.
Подсистема создания и редактирования тестовых заданий testmaker
Так как отраслевая модификация "TestGen", в силу специфики архитектуры, получилась достаточно гибкой системой, она может применяться для оценки качества знаний практически в любой сфере жизнедеятельности человека. Например, в настоящее время многие промышленные предприятия Российской федерации переходят на систему управления качеством стандарта ГОСТ Р ИСО 9000-2008. Этот переход подразумевает обучение персонала по специальным методикам, с последующей проверкой их знаний. Система "TestGen" позволяет проводить оценку качества знаний в этой области без внесения каких-либо дополнительных изменений в ее архитектуру.
В качестве примера был проведен анализ влияния таких факторов, как Тип дошкольного образования и Категория учителя на успеваемость по математики школьников пятых классов. Исследование проводилось с помощью метода имитационного планируемого эксперимента, применяя матрицу дробного факторного эксперимента с полурепликой 24" +1 (см. табл. 4.2).
При этом, средняя оценка М для группы из п тестируемых с одинаковыми значениями переменных К и Д, определялась следующим образом: м = п Зависимость средней оценки Мот значений КиДможно представить как: М=ЯАГ,Д), где М - средняя оценка тестируемых, баллов; К — категория учителя; Д — тип дошкольного образования.
Диапазоны значений, принимаемые независимыми переменными, варьировались следующим образом
Матрица планирования и результаты анализа тестов по математике школьников 5-х классов Алагирского района Республики Северная Осетия — Алания.
Оценка эффективности системы базируется на работе [134]. Стоимость разработки отраслевой модификации "TestGen" составила 80000 р.
По результатам проведенного анализа влияние на суммарный экономический эффект от использования разработанной системы таких показателей как капиталовложения, стоимость, трудозатраты при проведении тестирования и другие, был сделан вывод об эффективности и целесообразности принятия в качестве ключевых показателей для оценки эффективности разработанной системы на основных стадиях проведения тестирования показателя трудоемкости и стоимости.
Результаты применения предложенного подхода к оценке эффективности комплекса для решения различных задач, позволяют утверждать, что время решения поставленных задач с использованием комплекса более чем на порядок ниже, времени затрачиваемого при традиционном подходе (неавтоматизированном или с применением ЭВМ для автоматизации процесса создания тестов, распространения тестов, сбора результатов и анализа).
Кроме того, применение разработанных методик и алгоритмов обеспечивает выполнение всех заданных исходных требований по качеству проводимого анализа данных и стоимости выполняемых работ.
Экономический эффект от использования результатов проведенных исследований определяется: во-первых, сокращением времени анализа данных, и как результат - трудозатрат персонала, занимающегося этими работами, а во-вторых, снижением стоимости при создании и передачи тестовых заданий и результатов тестирования.
На первом этапе, экономическая эффективность разработанного программного комплекса рассчитывалась на основе результатов оценки трудозатрат при реализации отдельных стадий, поставленных задач традиционным (см. Табл. 4.3.) и автоматизированным методом (см. Табл. 4.4.).
При расчете было принято, что стоимость печати одной страницы формата А4 на лазерном монохромном принтере равняется: где Ст - стоимость печати одной страницы, р.; Ст_ПБ — средняя рыночная стоимость одной пачки бумаги формата А4 плотностью 80 г/м , р.; ЛБП -количество листов в одной стандартной пачке бумаги, листов; СтП — средняя стоимость печати одной страницы на монохромном лазерном принтере, р.
Эмпирически было подсчитано, что стоимость передачи материалов по 206 школам на территории РСО-Алания из города Владикавказ автомобильным транспортом составит 20000 р. Так как при проведении тестирования с помощью системы "TestGen" все массивы данных передаются по сети Интернет, нет необходимости распечатывать задания, передавать их на места проведения тестирования и передавать результаты тестирования в центр обработки информации, следовательно, материальные затраты составят 0 р.
Исходя из этого, при проведении одного тестирования по одному предмету с помощью системы "TestGen" осуществляется экономия в размере 1378 чел/час и 66000 рублей. С учетом вышеизложенного, можно утверждать, что система окупится после проведения двух общереспубликанских тестирований по одному предмету.
