Разработка модуля подготовки отчетности о состоянии киберфизического объекта "Умный офис"

Размещено на http://www.allbest.ru/

Пермский филиал федерального государственного автономного образовательного учреждение высшего образования

Национальный исследовательский университет

«Высшая школа экономики»

Факультет экономики, менеджмента и бизнес-информатики

Выпускная квалификационная работа

РАЗРАБОТКА МОДУЛЯ ПОДГОТОВКИ ОТЧЕТНОСТИ О СОСТОЯНИИ КИБЕРФИЗИЧЕСКОГО ОБЪЕКТА «УМНЫЙ ОФИС»

Демина Дарья Сергеевна

Руководитель К.т.н., доцент кафедры информационных

технологий в бизнесе О.Л. Викентьева

Пермь, 2019 год

Аннотация

Демина Д. Разработка модуля подготовки отчетности о состоянии киберфизического объекта «Умный офис» // Кафедра информационных технологий в бизнесе, 2019. - 71с.

Данная работа включает описание анализа, проектирования и разработки программного модуля подготовки отёчности о состоянии киберфизического объекта «Умный офис». Первая глава содержит теоретический анализ систем подготовки отчетности о состоянии киберфзических систем в состоянии «как есть». Вторая глава включает в себя текстовое и формальное описание модуля подготовки отчетности в состоянии «как должно быть», а также описание используемых технологий. Помимо этого, во второй главе представлено описание моделей разрабатываемого модуля. В третьей главе представлено описание процесса разработки модуля подготовки отчетности. Результатом данной работы является разработанный прототип модуля подготовки отчетности о состоянии киберфизического объекта «Умный офис» в среде Visual Studio на языке программирования C#. Полученный прототип может быть внедрен в систему интернета вещей. отчетность киберфизический система модуль

Работа включает в себя: 89 страниц основного текста, включая 16 страниц приложений, содержит 43 иллюстрации, 10 таблиц.

Оглавление

• Введение
• 1. Анализ предметной области киберфизического объекта «Умный офис»
• 1.1 Киберфизические системы
• 1.1.1 Определение и описание киберфизических систем на примере Умного офиса
• 1.1.2 Цифровой двойник
• 1.1.3 Области применения кибер-физических систем
• 1.1.4 Уровень развития кибер-физических систем
• 1.2 Подготовка отчетности
• 1.2.1 Определение и общие сведения
• 1.2.2 Модуль подготовки отчетности для киберфизических систем
• 1.3 Методы анализа временных рядов
• 1.4 Сравнение существующих систем
• 1.4.1 Приложения, используемые для интернета вещей
• 1.4.2 Сравнительный анализ используемых систем
• 1.5 Анализ бизнес-процессов киберфизических систем в состоянии «как есть»
• 1.5.1 Анализ бизнес-процесса проектирование модуля подготовки отчетности в состоянии «как есть»
• 1.5.2 Анализ бизнес-процесса проектирование модуля создания шаблонов в состоянии «как есть»
• 1.5.3 Анализ бизнес-процесса проектирование модуля выбора получателя в состоянии «как есть»
• 1.5.4 Анализ бизнес-процесса проектирование модуля генерации отчета в состоянии «как есть»
• 1.6 Выявление требований к разрабатываемому модулю подготовки отчетности
• 1.7 Диаграмма прецедентов
• 2. Проектирование модуля подготовки отчетности
• 2.1 Разработка моделей to be бизнес-процессов модуля подготовки отчетности
• 2.1.1 Разработка модели to be бизнес-процесса «Создание отчета»
• 2.2 Разработка модели to be бизнес-процесса «Создание шаблона»
• 2.2.1 Текстовое описание модели to be бизнес-процесса «Создание шаблона»
• 2.2.2 Формальное описание модели to be бизнес-процесса «Создание шаблона»
• 2.3 Разработка модели to be бизнес-процесса «Выбор получателя»
• 2.3.1 Анализ модели to be бизнес-процесса «Выбор получателя»
• 2.4 Разработка модели to be бизнес-процесса «Генерация отчета»
• 2.4.1 Текстовое описание модели to be бизнес-процесса «Генерация отчета»
• 2.4.2 Формальное описание модели to be бизнес-процесса «Генерация отчета»
• 2.5 Используемые технологии
• 2.6 Инфологическая модель базы данных
• 2.7 Даталогическая модель базы данных
• 2.8 Диаграмма компонентов модуля подготовки отчетности
• 3. Разработка модуля подготовки отчетности
• 3.1 Интеграция модуля с системой «Менеджер сценариев»
• 3.1.1 Создание модели
• 3.1.2 Строка подключения
• 3.1.3 Миграции
• 3.2 Работа с БД временных рядов
• 3.2.1 Развертывание БД временных рядов
• 3.2.2 Создание и работа с базой данных
• 3.3 Реализация модуля подготовки отчётности
• 3.3.1 Проект MVC
• 3.3.2 Drag&Drop
• 3.3.3 JSON
• 3.3.4 Формирование файла в формате.pdf
• 3.3.5 Отправка отчет на электронную почту
• 3.4 Интерфейс
• 3.3.1 Выбор пользовательской группы
• 3.3.2 Рабочая область
• 3.3.3 Сохранение файла в формате.pdf
• 3.3.4 Отправка отчета на электронную почту
• Заключение
• Список сокращений и условных обозначений
• Библиографический список
• Приложение А Листинг модели данных
• Приложение Б Листинг создания шаблона
• Приложение В Листинг формирования файла в формате.pdf
• Приложение Г Листинг отправки файла на электронную почту
• 

Введение

Интернет вещей - Internet of Things (IoT) развивается и становится все более и более популярным. За последние 5 лет количество устройств, подключенных к интернету вещей, увеличилось на 300% [1]. Для того чтобы управлять IoT разрабатываются специальные платформы. IoT платформы объединяют физические объекты и сеть. Примерами таких платформ являются Bug Lab и DeviceHub. Однако проблема наглядной визуализации данных остается открытой, так как датчики считывают данные в виде временных рядов. Временной ряд - это последовательность данных, соответствующих каким-либо изменениям на некотором временном интервале. Для понятного пользователю представления информации необходимо преобразовать временные ряды в более наглядный вид. Представление отчетности в виде настраиваемых таблиц и графиков является решением данной проблемы. Другими словами, необходимо реализовать слой представления [2] системы управления подсистемами технического обеспечения Умного офиса для того, чтобы пользователь мог увидеть, оценить и проанализировать работу киберфизической системы. Таким образом, тема «Разработка модуля подготовки отчетности о состоянии киберфизического объекта «Умный офис» является актуальной.

Microsoft Cloud предоставляет систему создания отчетов для интернета вещей в режиме реального времени. Для создания отчетности данная система использует Microsoft Azure приложение Power BI. Минусом данной системы является то, что для ее использования необходима покупка платных аппаратных средств. В данной работе основное внимание будет уделено временным рядам и возможности их дальнейшего преобразования в формат, понятный пользователю. Это необходимо для анализа и прогнозирования работы умного офиса, а также для предотвращения возможных сбоев в системе или аварий. Только когда данные визуализированы, пользователь может увидеть, как работает система. Модуль подготовки отчетности будет отправлять запрос в базу данных Influx DB, в которой хранятся данные о работе «Умного офиса» в виде временных рядов. На основе полученных из базы данных модуль будет строить графики в виде, выбранном пользователем с возможностью дальнейшего сохранения отчета в формате.pdf. Для построения графиков на основе данных будут использоваться математико-статистические методы анализа временных рядов.

Объектом исследования является киберфизический объект «Умный офис».

Предметом исследования являются средства для получения отчетности о состоянии объекта.

Цель работы - разработать модуль подготовки отчетности о состоянии киберфизического объекта «Умный офис».

Для достижения цели были поставлены следующие задачи:

1. Выполнить анализ процессов и данных киберфизической системы «Умный Офис».

2. Проанализировать и сравнить аналогичные системы составления отчетности.

3. Проанализировать инструментальные средства для реализации системы.

4. Разработать требования к модулю подготовки отчетности киберфизической системы «Умный Офис».

5. Спроектировать разрабатываемый модуль.

6. Реализовать и протестировать модуль подготовки отчетности.

7. Подвести итоги.

Результатом работы будет являться прототип конструктора отчетов. Работа считается успешно завершенной, если система работает без ошибок и наглядно отображает результаты работы «Умного офиса» в формате pdf. Теоретический результат работы включает в себя анализ предметной области и инструментальных средств, а также необходимые для построения графиков математические формулы. Практическим результатом является сама система.

Разработанный модуль подготовки отчетности будет использован в системе, частью которой этот модуль является. Данный модуль играет значимую роль в системе, так как именно благодаря ему у пользователей появится возможность наглядно увидеть результаты работы киберфизического объекта «Умный офис». Наглядное представление позволит быстро и точно выявлять неисправности, а также облегчит контроль над киберфизическим объектом.

1. Анализ предметной области киберфизического объекта «Умный офис»

1.1 Киберфизические системы

1.1.1 Определение и описание киберфизических систем на примере Умного офиса

На данные момент существует большое количество определений кибер-физических систем (КФС). Например, в [3] под КФС понимаются распределенные гибридные динамические системы, предназначенные для интеграции вычислительных услуг и физических систем, работающих в разных временных и пространственных масштабах; в то время как Владислав Дробот в своей статье для «Control Engineering Россия» [4] дает более общее и простое определение: КФС - это совместно разработанные взаимодействующие сети физических и вычислительных компонентов.

КФС состоят из объединенных вычислительных объектов, которые тесно взаимодействуют с физическими компонентами через датчики и исполнительные механизмы. Как правило, они объединяются в систему систем, взаимодействующих друг с другом и с людьми через Интернет вещей (IoT) - сетевую инфраструктуру, обеспечивающую взаимодействие этих устройств [5]. Интернет вещей и кибер-физические системы имеют сходную концепцию интеграции вычислительных и физических устройств, хотя между их архитектурами систем существуют значительные различия.

Для лучшего понимания принципов работы киберфизического объекта (КФО), они будут рассмотрены на примере Умного Офиса (см. рис. 1.1). Умный офис - это помещение, оборудованное датчиками и контроллерами. Датчики считывают различные показатели, такие как свет, температура, присутствие, влажность воздуха и другие. Контроллеры управляют Умными вещами, расположенными в Умном офисе, на основе данных, полученных с датчиков. Правила поведения умными вещами задается на компьютере, при подключении контролера к компьютеру. Подключение может быть как проводным, так и беспроводным. Каждое правило отвечает за один параметр и программируется в формате «ЕСЛИ…, ТО…, ИНАЧЕ…». Набор правил, которые определяют поведение умных вещей, называются сценариями.

Рисунок 1.1 Умный офис

Сценарии обычно описывают поведение сразу нескольких параметров и задают правила поведения для всей системы. Например, когда последний работник уходит из офиса, он включает сценарий «Ночь», который задает следующее поведение: выключить свет, закрыть жалюзи, понизить температуру до наступления утра, а потом снова повысить перед приходом сотрудников, поставить офис на сигнализацию, подготовить отчет о работе системы за предыдущие сутки и так далее.

В то время как определенный сценарий включает пользователь, поведение умных вещей, прописанное в контроллере, может изменяться в зависимости от нескольких параметров: от даты и времени (при наступлении определенного времени в определенный день или каждый день в одно и то же время), от константы (когда значение показания какой-либо умной вещи достигает определенного значения - значения константы).

Основной задачей Умного офиса является обеспечение комфортных условий для эффективной работы сотрудников. Эффективная работа достигается за счет создания комфортной для работы атмосферы для каждого сотрудника. Теперь людям не нужно тратить время на закрытие и открытие окон, включение увлажнителей воздуха, кондиционеров и прочее, человек может просто сосредоточиться на работе.

Помимо удобства и создания приятной рабочей атмосферы система Умного офиса позволяет экономить и беречь ресурсы. При использовании КФО при отсутствии людей в помещении, в нем будет тратиться минимально возможное количество электроэнергии. Если же в помещении кто-то находится, то будет тратиться оптимальное количество электроэнергии (например, уровень освещенности в офисе может меняться в зависимости от освещенности за окном).

Также КФС Умный офис может предотвратить или защитить от аварийных ситуаций, таких как пожар или утечка. Так при пожаре определенный датчик подаст показания контроллеру, который мгновенно обеспечит тушение пожара.

1.1.2 Цифровой двойник

Помимо физической составляющей у умных вещей есть еще виртуальная - цифровой двойник. Цифровой двойник (рис. 1.2) - это технология интегрированного вероятностного моделирования, которая обеспечивает доступ к реалистичным моделям текущего состояния процесса и их поведению при взаимодействии с окружающей средой в реальном мире [6].



Рисунок 1.2 Цифровой двойник

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

При создании цифрового двойника реализуются решения для следующих задач:

· Задача мониторинга, диагностики и управления производственными и инженерными решениями.

· Задача 3D визуализации физического объекта и его функционирования.

· Задача моделирования работы объекта в различны условиях.

· Задача обеспечения промышленной безопасности.

· Задача автоматизации систем технического обслуживания и ремонта.

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

· Отчет, определяющий фактическое состояние объекта.

· Отчет со статистикой по отказам и авариям.

· Отчет-анализ эффективности использования.

· Отчет-анализ времени реагирования и сроков устранения неполадок.

· Отчет, показывающий энергоэффективность и контроль потребления энергоресурсов.

· Отчет-прогноз остаточных ресурсов, вероятностей поломок и принятие решений о техническом обслуживании.

1.1.3 Области применения кибер-физических систем

КФС имеют очень большую популярность и применяются не только для улучшения и облегчения жизнедеятельности человека. КФС системы нашли применение практически в любой сфере деятельности. Ниже представлены примеры отраслей, в которых активно используется применение КФС [7]

· В производственной сфере

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

· В здравоохранении

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

· В возобновляемой энергетике

Интеллектуальные энергосети являются КФС, где датчики и контроллеры дают возможность проводить мониторинг сети. Мониторинг позволяет контролировать, повышать надежность и энергоэффективность сети.

· В интеллектуальных зданиях

Как уже было сказано ранее, КФС в интеллектуальных зданиях позволяют не только создать наиболее комфортные условия для жизнедеятельности, но и сократить энергопотребление и повысить безопасность.

· В транспорте

КФС могут повысить безопасность на дорогах благодаря тому, что транспортные средства и инфраструктура могут взаимодействовать между собой. А именно, обмениваться информацией о дорожном движении, проблемах на дороге и их местоположении. Тем самым можно предотвратить дорожно-транспортные происшествия и пробки. Безопасность движения на дорогах, в свою очередь обеспечивает экономию средств и времени.

· В сельском хозяйстве

КФС могут усовершенствовать сельское хозяйство, сделать его более современным и эффективным. КФС могут хранить и обрабатывать данные о климате, почве и других необходимых параметрах и в последствии, на основе датчиков, создавать наиболее подходящий микроклимат для каждой культуры.

· В вычислительных средах

КФС обеспечивают более эффективное управление ресурсами, так как позволяет понимать поведение систем и пользователей. Основываясь на действиях пользователей в прошлом, КФС могут предсказать, что может быть интересно пользователю в будущем.



1.1.4 Уровень развития кибер-физических систем

КФС неразрывно связаны со стратегией «Индустрия 4.0» (Industry 4.0) (см. рис. 1.3). Данная стратегия была представлена Правительством Германии на Ганноверской выставке в 2011 году. Индустрия 4.0 по смыслу представляет концепцию четвертой промышленной революции и заключается в использовании высоких технологий для развития производства и промышленности, основываясь на тесной интеграции КФ систем.

Рисунок 1.3 Индустрия 4.0

Основные принципы, которые лежат в основе концепции Индустрии 4.0 представлены ниже [8]:

· Взаимодействие и взаимообмен: обеспечение взаимодействия машин, объектов, устройств, датчиков, людей с помощью интернета и интернета вещей.

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

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

· Децентрализованные решения: возможность КФС принимать собственные решения и максимизировать автономность их работы.

На данный момент существует около 200 проектов, созданных в рамках Индустрии 4.0 в Германии [3]. Это не очень большая цифра, так как с начала создания данной концепции прошло уже почти 10 лет. Это связано с тем, что не так много компаний могут предложить такие инновационные решения. Помимо того, у людей есть недоверие к таким системам, так как они новые и должны быть максимально автоматизированными. Также эффект от внедрения инновационных технологий кажется некоторым производителям неочевидным, так как они оценивают эффективность из существующих реалий.

В России таких глобальных инновационных проектов еще не реализовано. Однако в федеральной целевой программе «Цифровая экономика» упоминается данная технология как концепция. КФС становятся все более популярными в России и реализуются в основном небольшие проекты.

1.2 Подготовка отчетности

1.2.1 Определение и общие сведения

Отчет - подробное сообщение о положении дел, состоянии чего-либо [9]. В данной работе рассматривается отчет, который будет предоставлять информацию о состоянии и работе КФО Умный офис. Умный офис - это кибер-физический объект, значит внутри Умного офиса идет постоянная запись данных со всех датчиков. Такие большие объемы данных сложно анализировать, во-первых, потому что их много, во-вторых, потому что они хранятся в неудобном для анализа формате (формате временных рядов), в-третьих, потому что данные никак не структурированы. Для того, чтобы обеспечить возможность анализа данных о работе системы необходим отчет.

Отчет должен показывать только данные за выбранный период, что позволит работать с меньшим объемом данных. Как упоминалось в [10], большие наборы данных временных рядов имеют периодичность или повторяющееся поведение, которое связано с различными событиями, такими как праздники, политические события, времена года, погода и другие, которые называются тенденциями. Для выявленных тенденций система отчетности может иметь шаблоны, которые позволяют отображать отчет за определенный период времени, не указывая его, например, отображать данные не за весь год, а за летний период; Более того, необходимо, чтобы система позволяла сравнивать отчеты о тенденциях, например сравнивать летний период в 2017 и 2018 годах.

Также отчет должен быть наглядным и визуально понятным даже человеку без специальной подготовки [11]. Для обеспечения наглядности необходимо представить отчет в виде графиков и таблиц. Графики и таблицы не должны быть перегружены, все поля должны иметь подписи. Когда состояние системы понятно и данные пригодны для анализа, появляется возможность предсказать будущее поведение, другими словами - проактивно управлять системой. Суть проактивного управления заключается в том, что действия, направленные на уменьшение риска возникновения проблем в будущем, совершаются заранее. Таким образом можно избежать аварийных ситуаций или предсказать желаемое поведение пользователя Умного офиса.

1.2.2 Модуль подготовки отчетности для киберфизических систем

Понятие «состояние» кибер-физической системы очень общее, поэтому далее необходимо разобраться какие именно отчеты необходимы Умному офису.

Как уже упоминалось ранее, Умный офис - это реальное помещение, которое оборудовано датчиками, контроллерами и умными вещами. На контроллере программируется поведение умной вещи (сценарий), а датчики передают данные в контроллер для реализации сценария. Например, известна средняя освещенность на рабочих местах с постоянным пребыванием людей, в соответствие с ГОСТом [12] средняя освещенность составляет 200лк. Датчик уровня освещённости измеряет освещенность в комнате и передает показания контроллеру. Проблема состоит в том, что освещенность помещения зависит от нескольких факторов: время суток, погода за окном, закрыты или открыты шторы, включены ли лампы. Так как повлиять на время суток и погоду за окном контроллер не может, то контроллер управляет только умными шторами и выключателем освещения в помещении. Таким образом сценарий должен быть настроен так, что если за окном светло, то шторы необходимо открыть и при необходимости добавить какой-то степени освещения, но если солнце слепит в лицо, то шторы необходимо закрыть. Если же за окном темно, то настроить освещение до необходимого уровня. Главная задача - чтобы средняя освещенность на рабочих местах составляла 200лк.

Исходя из данного примера можно сделать вывод, для чего нужна система отчетности для КФС. Во-первых, данные, полученные с датчиков, позволят определить стабильно ли работает система. По наглядном представлению в виде графиков и таблиц гораздо проще определить работу системы, наличие выбросов и ошибок. То есть можно определить, всегда ли средний уровень освещенности равен 200лк. Во-вторых, опираясь на данные интегратор может корректировать поведение умной вещи для достижения необходимого результата, такого как уровень освещенности. Руководствуясь данными, можно определить, всегда ли уровень освещенности является равным среднему необходимому уровню освещенности, если нет, то в какое время данные не соответствуют необходимым. В результате появляется возможность перепрограммировать датчик для более корректной работы. В-третьих, полученные данные позволят интегратору повысить эффективность в денежном эквиваленте, так как основываясь на наглядном представлении полученных данных можно заметить возможные не максимально эффективные работающие контроллеры. Например, при частой смене погоды шторы открываются и закрываются слишком часто, более экономично было бы немного добавить искусственного освещения. Так возможно будет сэкономлена электроэнергия и износ механизма открывания и закрывания штор (см. табл. 1.1).

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

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

Для определения стабильности работы КФС пользователь должен иметь возможность воспользоваться следующими типами отчета (см. табл. 1.1.):

· Среднее значение.

· Сглаженное значение.

· Максимальное значение.

· Количество максимальных значений.

· Минимальное значение.

· Количество минимальных значений.

· Количество аварий.

· Показания при аварийном состоянии.

Для устранения неточностей пользователь может воспользоваться следующими типами отчета (см. табл. 1.1.):

· Отклонение от сглаженного значения.

· Отклонение от среднего значения.

Для обеспечения наиболее эффективного состояния пользователь может воспользоваться следующими типами отчета (см. табл. 1.1.):

· Тренд.

Таблица 1.1

Сопоставление критериев возможным типам отчетов

Критерий	Показания	Тип отчета
Стабильность	Штатное состояние системы	Среднее значение
		Сглаженное значение
	Выбросы	Максимальные значения
		Количество максимальных значений
		Минимальные значения
		Количество минимальных значений
	Аварии	Количество аварий
		Показания при аварийном состоянии
	Перебои связи	Ошибки связи
Неточность	Отклонения системы, не являющиеся серьезными ошибками	Отклонение от сглаженного значения
		Отклонение от среднего значения
Эффективность	Штатное состояние системы	Тренд (периодичность повтора)

Отчет для КФС строится на данных датчиков во времени. Таким образом для датчика необходимо знать, к какому контроллеру он относится, чтобы понимать, какой умной вещью он управляет. Данная задача выполняется одним из модулей системы. Модуль подготовки отчетности в свою очередь берет данные из модуля сбора данных, в котором указано, к какому контроллеру относятся показания датчика. На основе этих данных строится отчет по шаблону, созданному пользователем. Пользователь может создать шаблон для отчета по контроллеру или по умной вещи, которые принадлежат его пользовательской группе или дочерним группам пользователей. На шаблон пользователь добавляет необходимые таблицы и графики, выбирает временные промежутки и параметры отображения, после чего выбирает время и дату формирования шаблона. Это необходимо для того, чтобы была возможность получения как единовременного отчета, так и повторяющегося с определенной периодичностью, например, каждую неделю.

1.3 Методы анализа временных рядов

Данные с датчиков поступают в формате временных рядов, поэтому входные данные должны быть в формате временных рядов. Временные ряды представляют собой класс временных объектов данных [13], которые обеспечивают динамический анализ данных и прогнозирование будущего поведения. Временные ряды -- это значения наблюдений какого-либо объекта, которые измеряются с интервалами времени и записываются в хронологическом порядке.

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

На таблице 1.2 представлено какие методы анализа временных рядов необходимы для формирования разных типов отчета (п. 1.2, табл. 1.1).

Таблица 1.2

Сопоставление типа отчета методам анализа временных рядов

Тип отчета	Метод анализа временных рядов
Среднее значение.	(СУММ(i?..i?))/N
Сглаженное значение.	Экспоненциальное сглаживание.
Максимальное значение.	МАКС(i?..i?)
Количество максимальных значений.	СУММЕСЛИ(i?..i?, i= МАКС(i?..i?))
Минимальное значение.	МИН(i?..i?)
Количество минимальных значений.	СУММЕСЛИ(i?..i?, i= МИН(i?..i?))
Отклонение от сглаженного значения.	Скользящее среднее.
Отклонение от среднего значения.	Дисперсия.
Тренд.	Корреляционный анализ.
Предсказание будущего поведения	Регрессия.

1.4 Сравнение существующих систем

1.4.1 Приложения, используемые для интернета вещей

Для сравнения анализа и последующего сравнения существующих решений были выбраны приложения Blynk и ThingsBoard.

Blynk - мобильное приложение для управления микроконтроллерами через интернет (см. рис. 1.4). После установки приложение связывается с сервером Blynk-Cloud, где и происходит обмен данными с микроконтроллерами. Приложение имеет понятный интерфейс, так как управление происходит за счет перетаскивания иконок.

Рисунок 1.4 Интерфейс Blynk

Blynk является бесплатным приложением, однако пользователю придётся заплатить за энергию. Энергия - это так называемый банк, при установке приложения в нем уже хранится определенное количество энергии. За установку каждого виджета необходимо заплатить данную энергию, однако при удалении виджета энергия восстанавливается (рис 1.5). Если же необходимо добавить больше виджетов, а энергия уже закончилась, ее можно купить за деньги.

Рисунок 1.5 Окно выбора виджетов и индикатор энергии

Достоинства:

· Дружественный интерфейс.

· Бесплатное приложение.

· Широкий выбор аппаратных средств для подключения.

· Возможность управления контроллерами из любой точки мира.

· Возможность настраивать каждый виджет под свои нужды.

· Большой выбор виджетов.

Недостатки:

· Встроенные покупки.

· Англоязычный интерфейс.

· Для начала работы необходимо установить библиотеки Blynk на компьютер.

ThingsBoard - платформа интернета вещей, которая обеспечивает разработку масштабирование и управление проектами и имеет открытый исходный код. Данная платформа предназначена не только для визуализации данных, она имеет гораздо большую функциональность (см. рис 1.6):

· Предоставляет устройства, активы и клиенты и определяет отношения между ними.

· Собирает и визуализирует данные с устройств.

· Анализирует входящие телеметрические и триггерные сигналы с комплексной обработкой событий.

· Управляет устройствами с помощью удаленных вызовов процедур (RPC).

· Позволяет создавать рабочие потоки на основе события жизненного цикла устройства, события REST API, запроса RPC и т. д

· Позволяет разрабатывать динамические панели мониторинга и предоставлять клиентам данные телеметрии и аналитики устройств.

· Позволяет подключить специфические функции вариантов использования с помощью настраиваемых цепочек правил.

· И другие.

Рисунок 1.6 Функциональные возможность ThingsBoard

Модуль визуализации данных (рис. 1.7) имеет легкий для понимания интерфейс и позволяет настроить дашборды и виджеты на них под нужды пользователя. Так как дашборды имеют небольшой вес, пользователь может создавать большое количество данных информационных панелей. Дашборды могут быть изменены как с помощью скрипта, так и автоматически с помощью REST API. ThingsBoard позволяет визуализировать данные в режиме реального времени, а также использовать карты Google и OpenStreet для отслеживания местоположения.

Рисунок 1.7 Модуль визуализации данных ThingsBoard

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

Достоинства:

· Бесплатная платформа Интернета вещей.

· Имеет отрытый исходный код.

· «Дружественный» интерфейс.

· Широкий функционал.

· Много возможностей для настройки визуализации данных.

· Возможность настраивать виджеты и дашборды под нужды пользователя.

· Возможность формирования отчетных документов.

Недостатки:

· Формирование отчета только в платной версии платформы.

· Для построения отчета ThingsBoard загружает страницу браузера с необходимыми данным и потом на их основе формирует отчет.

1.4.2 Сравнительный анализ используемых систем

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

1. Тип приложения - мобильное или компьютерное.

2. Платное/бесплатное приложение.

3. Имеет ли приложение встроенные покупки.

4. Язык интерфейса.

5. Возможность формирования отчета за счет перетаскивания виджетов.

6. Возможность настроить дашборд.

7. Какое количество виджетов доступно для формирования отчета.

8. Возможность настройки виджетов.

9. Момент заполнения отчета данными.

10. Возможность создавать шаблоны отчетов.

11. В каком формате сохраняется отчет.

12. Куда сохраняется отчет.

13. Возможно ли выбрать время для генерации отчета.

Далее по выявленным критериям существующие приложение были сравнены, результаты сравнения представлены в таблице 1.3.

Таблица 1.3

Сравнение существующих систем

	Blynk	ThingsBoard
Тип приложения - мобильное или компьютерное.	Мобильное	Компьютерное
Платное/бесплатное приложение.	Бесплатное	Бесплатное
Имеет ли приложение встроенные покупки.	Имеет	Имеет
Язык интерфейса.	Английский	Английский
Возможность формирования отчета за счет перетаскивания виджетов.	Да	Да
Возможность настроить дашборд.	Да	Да
Какое количество виджетов доступно для формирования отчета.	Большой выбор	Большой выбор
Возможность настройки виджетов.	Да	Да
Момент заполнения отчета данными.	Во время создания отчета	Во время создания отчета
Возможность создавать шаблоны отчетов.	Нет	Нет
В каком формате сохраняется отчет.	Отчет показан на экране	Выбор из.pdf,.png,.jpeg
Куда сохраняется отчет.	Отчет хранится в приложении	В выбранную папку или на почту
Возможно ли выбрать время для генерации отчета.	Нет	Да

1.5 Анализ бизнес-процессов киберфизических систем в состоянии «как есть»

В данном разделе будет представлено описание бизнес-процессов киберфизических систем в состоянии «как есть» как для модуля подготовки отчетности в целом, так и для модулей создания шаблонов, выбора получателя и генерации отчета в частности. В качестве примера для анализа бизнес-процессов была выбрана система ThingsBoard.

1.5.1 Анализ бизнес-процесса проектирование модуля подготовки отчетности в состоянии «как есть»

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

В ThingsBoard модуль подготовки отчетности не является основной функциональной направленностью. Данное приложение предназначено для визуализации данных КФС, а модуль подготовки отчетности является дополнительной функцией, доступной только в «продвинутой» платной версии приложения.

Модуль подготовки отчетности для ThingsBoard работает по следующему алгоритму (рис 1.8): Пользователь находится на странице дашборда, который был настроен, как необходимо. После этого необходимо нажать на кнопку для формирования отчета, выбрать формат отчета и место, куда необходимо сохранить отчет. Отчет будет сохранен в указанном месте в указанном формате.



Рисунок 1.8 Диаграмма активности «Алгоритм работы модуля подготовки отчетности в состоянии «как есть» из дашборда»

Есть еще один вариант формирования отчета - из календаря (см. рис. 1.9). Необходимо нажать на соответствующую кнопку - создать событие для календаря. Затем необходимо указать название, выбрать тип события - формирование отчета и дашборд, на основе которого будет построен отчет. Также можно выбрать формат отчета, формат названия отчета и выбрать получателя. После этого необходимо указать дату и время старта, при необходимости также указать периодичность повтора отправки отчета.



Рисунок 1.9 Диаграмма активности «Алгоритм работы модуля подготовки отчетности в состоянии «как есть» из события календаря»

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

1.5.2 Анализ бизнес-процесса проектирование модуля создания шаблонов в состоянии «как есть»

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

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



Рисунок 1.10 Диаграмма активности «Создание шаблона в состоянии «как есть»

1.5.3 Анализ бизнес-процесса проектирование модуля выбора получателя в состоянии «как есть»

Выбор получателя в существующих решениях осуществляется только тогда, когда отчет создается как событие в календаре. Для того чтобы выбрать получателя необходим следовать следующему алгоритму (рис 1.11). Необходимо создать событие для календаря, в котором указан дашборд, по которому будет строиться отчет и формат, в котором отчет будет сохранен. В окне создания события календаря и указывается получатель отчета. Необходимо указать адрес электронной почты. Далее перейти к следующим настройкам события.

Рисунок 1.11 Диаграмма активности «Выбор получателя в состоянии «как есть»

1.5.4 Анализ бизнес-процесса проектирование модуля генерации отчета в состоянии «как есть»

Генерация отчета происходит либо во время работы с дашбородом (см. рис. 1.12), либо по указанной дате и времени генерации отчета (см. рис 1.13). Генерация отчета по указанной дате и времени происходит при создании события календаря. В окне создания события необходимо указать дату и время, а также периодичность (при необходимости) отправки отчета. Генерация отчета заключается в том, что созданный дашборд визуализации данных на выбранный момент времени «замирает», происходит формирование документа в выбранном формате с данными, изображенными на дашборде. После этого документ отправляется на почту или сохраняется в выбранном формате. Информация об отправленном отчете хранится в журнале операций.

Рисунок 1.12 Диаграмма активности «Генерация отчета в состоянии «как есть» из дашборда»



Рисунок 1.13 Диаграмма активности «Генерация отчета в состоянии «как есть» из события календаря»

1.6 Выявление требований к разрабатываемому модулю подготовки отчетности

Бизнес требованием к модулю подготовки отчетности о состоянии киберфизического объекта «Умный офис» является: обеспечение пользователей возможностью создания отчета о работе киберфизического объекта. Данный модуль необходим для анализа работы объекта, а также предсказания будущего поведения на основе анализа. Модуль подготовки отчетности необходим для любого КФО или КФС.

Пользовательские требования для модуля, позволяющего генерировать отчеты о состоянии КФО заключаются в возможности настроить отчет под свои нужды, сохранить шаблон отчета и получить отчет на почту в заданное время и дату, а также просматривать журнал отправленных отчетов (журнал операции). К пользовательским требованиям также относятся требования к интерфейсу. Большую часть экрана занимает рабочая панель. Это окно, в котором можно настроить внешний вид отчета. Обязательным полем будет являться дата генерации отчета, она расположена в правом верхнем углу. В левом верхнем углу можно установить название отчета. Справа от рабочей панели будет расположена панель настроек. Здесь будут храниться виджеты, которые можно перетаскивать на рабочую панель. Помимо этого, на панели настроек будут расположены настройки, такие как: выбор времени отправления, единовременный отчет или нет, добавление почты, на которую необходимо отправить отчет. Также здесь можно будет выбрать уже существующий шаблон, для его последующего изменения, сохранить новый шаблон, просмотреть журнал операций. Настройка самих виджетов происходит уже после того, как виджет добавлен на рабочую панель. На рабочей панели будет возможность настроить каждый виджет. Например, для таблиц можно будет выбрать количество строк и столбцов, ширину линий, особые параметры для заголовков, цвет текста и линий и прочее.

Системные требования заключается в необходимости взаимодействовать с существующими подсистемами «Менеджер сценариев» и «Модуль сбора данных». Также необходимо взаимодействовать с базой данных временных рядов InfluxDB и реляционной базой данных MS SQL. Готовый отчет должен представлять из себя файл в формате.pdf.

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

Функциональные требования:

1. Выбор пользовательской группы для дальнейшей работы с системой.

2. Возможность создания, изменения и удаления шаблонов отчета.

3. Возможность настройки шаблона и каждого виджета на шаблоне.

4. Возможность настройки получателя отчёта.

5. Возможность настройки даты и времени генерации отчета, а также возможность повторной генерации отчета.

6. Заполнение шаблона данными только при формировании отчета.

7. Генерация и отправка отчета на почту в выбранное время.

8. Возможность просмотра журнала операций.

Нефункциональные требования:

1. Формат входных данных - временные ряды, полученные из базы данных InfluxDB.

2. Формат выходных данных - отчет.

3. Формат отчета -.pdf.

1.7 Диаграмма прецедентов

Основываясь на функциональных требованиях, описанных в п. 1.5. был составлен перечень прецедентов использования программы:

1. Выбор группы пользователей.

2. Создание шаблона.

Включает:

· Выбор виджетов.

· Настройка каждого виджета.

· Настройка даты и времени генерации отчета.

· Настройка возможности отправлять отчет несколько раз.

· Выбор получателя.

3. Изменение шаблона.

4. Сохранение шаблона.

5. Удаление шаблона.

6. Генерация отчета в заданное время.

Включает:

· Заполнение отчета данными.

· Отправка отчета адресату.

Акторами являются пользователь и модуль подготовки отчетности. Пользователь может иметь любой статус (администратор, интегратор, обычный пользователь), функциональные возможность равны для всех. Разница заключается только в писке доступных умных вещей, по которым можно построить пользователю отчет в зависимости от его пользовательской группы.

Диаграмма прецедентов в нотации UML представлена на рисунке 1.14.

Рисунок 1.14 Диаграмма прецедентов

В таблице 1.4. представлено сопоставление прецедентов функциональным требованиям.



Таблица 1.4

Сопоставление прецедентов функциональным требованиям

Требование	Прецеденты
Выбор пользовательской группы для дальнейшей работы с системой.	Выбор пользовательской группы
Возможность создания, изменения и удаления шаблонов отчета.	Создание шаблона отчета, Сохранение шаблона отчета, Изменение шаблона отчета, Удаление шаблона отчета
Возможность настройки шаблона и каждого виджета на шаблоне.	Выбор виджетов, Настройка каждого виджета
Возможность настройки получателя отчёта.	Выбор получателя
Возможность настройки даты и времени генерации отчета, а также возможность повторной генерации отчета.	Настройка даты и времени генерации отчета, Настройка возможности отправлять отчет несколько раз
Заполнение шаблона данными только при формировании отчета.	Заполнение отчета данными
Генерация и отправка отчета на почту в выбранное время.	Генерация отчета в заданное время, Отправка отчета адресату
Возможность просмотра журнала операций.	Просмотр журнала операций

Далее будут представлены основные потоки прецедентов для более подробного описания каждого прецедента.

Название: Создание шаблона отчета (табл. 1.5).

Акторы: Пользователь.

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

Таблица 1.5

Создание шаблона отчета

Действия актора	Отклик системы
1. Выбор пользовательской группы.	2. Открытие рабочей области с панелью настроек.
3. Нажатие кнопки «Все виджеты» в панели настроек.	4. Открытие списка всех виджетов.
5. Выбор нужного виджета путем перетаскивания виджета из панели настроек на рабочую область (R1).	6. Отображение виджета в рабочей области.
6. Настройка виджета (R1).	7. Сохранение изменений виджета.
8. Нажатие кнопки «Выбор получателя» на панели настроек.	9. Открытие окна с выбором получателя.
10. Выбор получателя из списка или ввод электронной почты нового получателя
11. Нажатие на кнопку «Сохранить»	12. Проверка корректности ввод данных (E1).
	13. Сохранение получателя.
	14. Закрытие всплывающего окна выбора получателя.
15. Нажатие кнопки «Настроить дату и время генерации отчета»	16. Открытие окна с настройкой даты и времени.
17. Указать дату и время генерации и отправки отчета.
18. Указать периодичность повторения генерации. ...

Страница:

•  1 
•  2 

дипломная работа "Разработка модуля подготовки отчетности о состоянии киберфизического объекта "Умный офис"" скачать

Подобные документы

• Разработка программного модуля

  Структурная диаграмма программного модуля. Разработка схемы программного модуля и пользовательского интерфейса. Реализация программного модуля: код программы; описание использованных операторов и функций. Вид пользовательской формы с заполненной матрицей.
  
  курсовая работа [215,3 K], добавлен 01.09.2010
  

• Разработка программного модуля для интеграции данных между системами 1С:Предприятие 8.2 и модулем "Казначейство" КИС ОАО "ММК"

  Постановка задачи для модуля 1С. Бухгалтерия 3.0. Анализ существующих разработок в области интегрирования данных. Информационное обеспечение модуля "Связь 1С Предприятия 8.2. с "Казначейством". Программное и технологическое обеспечение данного модуля.
  
  курсовая работа [1,5 M], добавлен 10.06.2013
  

• Разработка модуля для контура управления tic-104

  Краткая характеристика PI System и контура управления tic-104. Анализ и планирование требований к модулю tic-104. Проектирование модуля tic-104. Внедрение модуля в приложение PI ProcessBook. Доступ к данным временных рядов PI. Модульная база данных.
  
  курсовая работа [38,1 K], добавлен 09.05.2011
  

• Проект программного модуля для нахождения корня уравнения

  Методика разработки программного модуля для нахождения методом хорд корня уравнения x3-x-0,3=0 с точностью до 0,001 на языке программирования Visual Basic for Application. Схема программного модуля и описание процедуры обработки кнопки "Найти корни".
  
  курсовая работа [394,0 K], добавлен 08.09.2010
  

• Разработка программного модуля, который находит сумму угловых элементов матрицы и сумму элементов, находящихся над главной диагональю

  Структурная диаграмма программного модуля. Нахождение суммы элементов, находящихся над главной диагональю. Реализация программного модуля: код программы; описание использованных операторов и функций. Особенности тестирования программного модуля.
  
  курсовая работа [146,6 K], добавлен 01.09.2010
  

• Разработка программного модуля регистрации документов

  Проектирование модуля регистрации документов. Анализ предметной области, спецификация требований. Построение диаграммы прецедентов Анализ архитектуры модуля в "OpenText Content Server 16.2". Разработка программы регистрации документов, ее тестирование.
  
  дипломная работа [1,9 M], добавлен 25.08.2017
  

• Разработка программного модуля "Лаборатория"

  Разработка СУБД - программного модуля для систематизации, хранения и обработки сведений о работниках лаборатории. Технологический процесс машинной реализации задачи, составление алгоритма, описание переменных процедур и функций. Листинг программы.
  
  курсовая работа [1,7 M], добавлен 11.01.2013
  

• Программное обеспечение модуля управления и отладки комплекса систем железнодорожной автоматики

  Изучение области применения комплекса для проведения имитационных испытаний микропроцессорных систем железнодорожной автоматики на функциональную безопасность. Разработка программного обеспечения модуля управления и отладки. Тестирование системы команд.
  
  курсовая работа [1,1 M], добавлен 22.11.2014
  

• Разработка модуля для предприятия по сборке ПК в программе 1С: Предприятие

  Организационная и функциональная структура ОАО "Кировэнерго" по сборке компьютеров, разработка модуля ИС для увеличения производительности предприятия. Обзор и сравнение аналогов информационных систем. Расчет экономической эффективности внедряемой ИС.
  
  дипломная работа [2,3 M], добавлен 30.08.2010
  

• Разработка программных модулей программного обеспечения для компьютерных систем

  Реализация программного средства "Действия над матрицами". Разработка кода программного продукта на основе готовой спецификации на уровне модуля. Использование инструментальных средств на этапе отладки программного модуля. Выбор стратегии тестирования.
  
  отчет по практике [296,1 K], добавлен 19.04.2015
  

• Разработка идеи объединения сторонних решений и реализация многофункционального, легко масштабируемого приложения

  Разработка функциональной и структурной схемы программного средства. Реализация основного модуля программы. Реализация модуля печати и модуля обновлений. Изучение взаимодействия информационных технологий, методов их интеграции и обмена данными.
  
  дипломная работа [3,2 M], добавлен 27.10.2017
  

• Интерполяция траектории движения GPS-модуля по результатам измерения координат

  Разработка алгоритма фильтрации данных, полученных с систем спутниковой навигации с помощью GNSS-модуля. Анализ работы фильтра Калмана, его программная реализация под конкретную задачу. Выбор навигационных модулей для получения данных позиционирования.
  
  дипломная работа [3,6 M], добавлен 12.01.2016
  

• Разработка программного модуля на основе понятийно-тезисной модели

  Сравнительный анализ технологий тестирования. Разработка программного модуля "Интеллектуальная обучающая система для широкого перечня курсов". Обоснование необходимости и важности этапа отладки в процессе разработки данного программного обеспечения.
  
  дипломная работа [101,2 K], добавлен 17.06.2011
  

• Разработка автоматизированной системы оптимизации отслеживания отчетности предприятий

  Разработка программы по составлению бланка с анализом сданной отчетности клиента. Выбор способа организации данных, операторы языка SQL, построение ER-диаграммы и таблиц на её основе, листинг процедур. Описание процесса работы пользователя с программой.
  
  дипломная работа [1,8 M], добавлен 10.10.2015
  

• Разработка программного модуля для интеграции данных между системами 1С Предприятие 8.2 и модулем "Казначейство" КИС ОАО "ММК"

  Технико-экономические характеристики предметной области по учету готовой продукции на ОАО "ММК". Постановка задачи для модуля 1С. Бухгалтерия 3.0. Информационное обеспечение модуля "Связь 1С Предприятия 8.2. с "Казначейством". Оценка трудоемкости работы.
  
  дипломная работа [1,1 M], добавлен 06.06.2013
  

• Разработка учебно-методического модуля по проектированию автоматизированной системы управления в TRACE MODE 6 (на примере объектов с ЦППН-8 Приобского месторождения ООО "РН-Юганскнефтегаз")

  Характеристика учебно-методического модуля по проектированию автоматизированных систем в TRACE MODE 6. Интегрированная среда разработки TraceMode 6.05. Разработка автоматизированной системы управления. Социально-экономическая эффективность проекта.
  
  дипломная работа [2,9 M], добавлен 30.09.2013
  

• Проведение анализа существующих систем защиты компьютерных систем

  Обзор технологий обнаружения атак. Модуль накопления и хранения предупреждений. Алгоритм работы подсистемы. Реализация клиент-серверной технологии. Клиентская часть программы. Реализация модуля шифрования, модуля накопления и хранения предупреждений.
  
  дипломная работа [582,6 K], добавлен 17.11.2014
  

• Разработка программного модуля "Прокат автомобилей"

  Принципы разработки программы для хранения информации о клиентах, которым предоставляются услуги проката автомобилей, а так же для осуществления оперативного поиска необходимой информации. Структура программного модуля. Описание руководства программиста.
  
  курсовая работа [872,3 K], добавлен 10.06.2014
  

• Решение систем линейных уравнений. Метод Гаусса

  Разработка программного продукта для решения систем линейных алгебраических уравнений методом Гаусса с помощью ЭВМ. Математическое описание объекта моделирования, начальные и граничные условия. Алгоритм реализации задачи. Использование модуля CRT.
  
  курсовая работа [269,6 K], добавлен 07.01.2016
  

• Основы систем автоматизированного проектирования

  Определения процесса проектирования. Взаимодействие субъектов и объектов в процессе создания изделия. Подходы к конструированию на основе компьютерных технологий. Системы автоматизации подготовки производства, технической подготовки производства.
  
  курс лекций [288,9 K], добавлен 09.02.2012
  

Другие документы, подобные "Разработка модуля подготовки отчетности о состоянии киберфизического объекта "Умный офис""

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам