Алгоритмы обучения и профилактическое обслуживание Интернета вещей

Автор: Д-р Ташкин Дениз, специалист по данным / консультант компании Record Evolution GmbH

Резюме

В статье рассматривается интеллектуальная обработка данных Интернета вещей (IoT) в контексте профилактического обслуживания и связывается с последними разработками в области полууправляемого обучения. Хотя статья написана с оглядкой на аудиторию, не являющуюся экспертом, статья ссылается на недавние научные публикации. Мы предоставляем любознательному и технически ориентированному читателю возможность расширить свои знания по изложенным нами идеям (см. Ссылки). Мы стремимся быть информативными и открытыми для стимулирования дискуссий по аналитике данных Интернета вещей.

Мы освещаем тему алгоритмов обучения и профилактического обслуживания Интернета вещей в серии из трех статей. В ЧАСТИ I мы представляем простой пример и обсуждаем некоторые алгоритмы обучения, связанные с ним. В ЧАСТИ I I (текущая статья) мы сосредотачиваемся на анализе данных IoT и разработке приложений для IoT для профилактического обслуживания. В ЧАСТИ III мы рассматриваем недавнюю литературу по полу-контролируемому обучению и сравниваем основы различных методов. Мы представляем реальные случаи, в которых обучение за несколько шагов может стать эффективным методом для интеллектуальной аналитики Интернета вещей и потоковой передачи данных. В конце этой серии статей вы можете найти глоссарий терминов и предложения для дальнейшего чтения.

Мы не претендуем на полноту: Интернет вещей - обширная и процветающая тема. Не стесняйтесь комментировать и начинать обсуждение с нами.

Пролог

Мы завершили ЧАСТЬ I этой серии статей несколькими открытыми вопросами, касающимися аналитики данных Интернета вещей и соответствующих алгоритмов машинного обучения:

Каковы свойства разных источников данных Интернета вещей?
Какова структура различных ресурсов в иерархии Интернета вещей?
Как можно хранить данные и в каком формате?
Каковы последние достижения машинного обучения в отношении проблемы Интернета вещей?
Как сравниваются разные алгоритмы? Какие в нем нерешенные проблемы?

В данной статье мы коснемся первых трех вопросов, оставив все остальное для ЧАСТИ III.

1. Введение в инфраструктуру данных IoT

Интернет вещей - это модное слово, которое относится к взаимосвязанным устройствам, встроенным в глобальную сеть. А именно, IoT - это беспроводная сенсорная сеть (WSN) устройств, использующих один или несколько протоколов связи (например, WAMP [28], MQTT [33]). Таким образом, Интернет вещей может существовать в различных контекстах, таких как умный город, городское планирование, сельское хозяйство, промышленное производство, автономное вождение, техническое обслуживание и т. Д. Говорят, что к 2020 году нас будут окружать около 17 миллиардов устройств, потенциально передающих данные в облако, что означает примерно 5 квинтиллионов (5x10ˆ18) байтов данных, производимых в среднем каждый день [34]. Как бы захватывающе и многообещающе это ни звучало на этом раннем этапе разработки, Интернет вещей сопряжен с рядом проблем. В этой статье рассматриваются некоторые из этих проблем.

В ЧАСТИ I этой серии мы представили простой мысленный эксперимент по профилактическому обслуживанию и IoT. Мы предложили фильтровать потоковую передачу на месте (имеется в виду, например, в цехе завода или в любом соответствующем месте) с помощью интеллектуальных моделей на границе сети IoT. Это было представлено как динамически выбираемый параметр фильтра с учетом локальных изменений (например, так просто, как открытое или закрытое окно на двух идентичных фабриках). Как бы просто это ни звучало, такой процесс требует, прежде всего, соответствующих алгоритмов обучения (ЧАСТЬ III), которые могут справиться с дисбалансом данных и многомодальностью. Более того, для этого процесса требуется архитектура для создания и распространения информации: безопасный обмен сообщениями, хранилище данных и инфраструктура развертывания приложений. Вот почему, прежде всего, следует глубоко изучить соответствующую инфраструктуру Интернета вещей и экосистему программного обеспечения. В следующих разделах мы объясним, что мы имеем в виду под этим. Кроме того, мы внимательно рассмотрим соответствующие технические детали и ответим, почему проблемы, представленные в ЧАСТИ I, имеют смысл .

Суть нашего аргумента заключается в том, что для работы с большими потоками данных может быть сформирована сеть локальных устройств в распределенной вычислительной структуре. Представьте себе несколько узлов (таких как камеры, датчики температуры или давления, счетчики), которые находятся в контекстно-зависимых местах или просто достигают мобильности в определенной области, например в заводском цехе. Эти устройства созданы для измерения физических наблюдаемых и потоковой передачи данных на сервер. До недавнего времени это реализовывалось просто (например, в модели ведущий / ведомый). В качестве альтернативы устройства могут потенциально связываться со своими коллегами и оценивать данные. Более того, они могут формировать пакеты потоков данных (локальные буферы), а также действовать как локальные серверы. Решающим моментом является то, что в идеале эти устройства должны предварительно обрабатывать данные, которые они поглощают, перед их потоковой передачей на хост-сервер.

В качестве конечного продукта большие данные будут преобразованы в модель ИИ (искусственного интеллекта) с использованием огромных вычислительных ресурсов (которые, возможно, находятся в облаке или в «ближайшем» вычислительном центре). Это также проблема, которую мы не будем решать на данном этапе. Наконец, центральный ИИ будет рекурсивно унаследован локальными устройствами для улучшения решений реальных проблем. Как тогда подойти к этому вопросу по восходящему сценарию? Начнем со свойств данных Интернета вещей.

1.1. Характеристики данных Интернета вещей

Прежде всего, нам необходимо понять общие свойства данных, собираемых и публикуемых датчиками в общей настройке Интернета вещей. Данные Интернета вещей - это не просто еще один вид больших данных. Для начала необходимо знать о следующих шести проблемах или о так называемом c вызове 6 против Интернета вещей [8].

Первые три V являются общими:

Объем (измеренных данных)
Разнообразие (источников данных или способов)
Скорость (генерации данных)

Остальные три V часто зависят от контекста:

Правдивость (или, другими словами, достоверность данных)
Вариативность (в параметрах потоковой передачи)
Ценность (для бизнес-аналитики)

Некоторые из этих свойств могут стать более важными для данной проблемы. Например, в промышленных условиях не всегда наибольшее значение имеет размер данных. Иногда сетевая безопасность и ценность бизнеса выходят далеко вперед. Подумайте о данных с датчиков счетчика продуктов со сложным алгоритмом распознавания изображений за период производства в 10 секунд. В общем, могут быть гораздо более быстрые процессы, например полимерная продукция или пресс для металла; пропускная способность адаптируется в значительной степени. Мы предполагаем, что можно ограничить рост объема данных - в случае, если они бесполезны в данном контексте. Эта задача будет оптимально выполнена, если будут реализованы умные фильтры. Это, вероятно, самая простая задача специалиста по данным при создании платформы IoT.

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

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

В-третьих, с указанными выше проблемами или без них IoT требует базы данных и огромной вычислительной мощности для обучения общей модели (представьте себе успех модели распознавания речи Google по сравнению с индивидуальным решением). В конце концов, мы хотели бы реализовать обе функции. А именно, универсальность центральной модели искусственного интеллекта, развивающейся в медленном масштабе времени и, локально работающий интеллект для оценки и потоковой передачи данных. Дьявол заключается в тонком компромиссе между уровнями (вверх или вниз на рисунке 2) , что означает, что мы должны внедрять ИИ на любом уровне. Поистине неприятная альтернатива - проснуться в ясное воскресенье посреди огромного озера данных, возможно, включающего в себя сотни терабайт звуковых файлов с дискретизацией 10 кГц, хотя в них нет никаких аномалий. Это уже требует затрат на хранение и вычислительные ресурсы - только для того, чтобы обнаружить, что они бесполезны.

Подводя итог обсуждению на этом этапе, чтобы настроить эффективную среду IoT, необходимо иметь дело с техническими проблемами, связанными с IoT, помимо статических больших данных (см. Статью [8]):

Крупномасштабные потоковые данные. Множество устройств сбора данных распространяются и развертываются для приложений Интернета вещей и непрерывно генерируют потоки данных. Это приводит к огромному объему непрерывных данных.
Неоднородность. Различные устройства сбора данных Интернета вещей собирают разную информацию, что приводит к неоднородности данных.
Корреляция времени и пространства: в большинстве приложений IoT сенсорные устройства привязаны к определенному месту и, таким образом, имеют местоположение и отметку времени для каждого элемента данных.
Данные с высоким уровнем шума: из-за крошечных фрагментов данных в приложениях IoT данные могут быть подвержены ошибкам и шумам во время сбора и передачи.

Чтобы вмешиваться на любом уровне / уровне, нужно запускать интеллектуальные алгоритмы, встроенные в приложения Интернета вещей [13]. Это легче сказать, чем сделать. Для выполнения этой задачи используются недавно полууправляемые алгоритмы обучения, которые помогают сбалансировать недостающие выборки или даже создать больше выборок (с GAN [1]), если это необходимо. Эти методы, с одной стороны, могут смоделировать небольшой объем помеченных данных с большим объемом немаркированных данных [13] (трансдуктивное обучение). С другой стороны, они могут включать небольшой объем немаркированных данных с большим объемом помеченных данных [13 ] (индуктивное обучение). Мы предполагаем, что в этой серии статей мы имеем дело в основном с проблемой индуктивного обучения .

1.2. Аналитика данных Интернета вещей и машинное обучение

Данные IoT - это не только большие данные, они инкапсулируют мультимодальные наблюдения (например, аудио, визуальные и числовые), и их параметры могут меняться во времени в данном контексте. Эти свойства затрудняют адаптацию аналитики данных / искусственного интеллекта к IoT [13]. IoT просто нужны интеллектуальные алгоритмы, которые могут гибко включать различные источники и изменять свойства, а также инфраструктуру обновлений для достижения наиболее интеллектуальной доступной модели (например, из облачного реестра). На практике нам больше всего необходимо передать ранее изученные категории и отношения, чтобы понять новые наблюдения.

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

В ЧАСТИ III этой серии статей мы рассмотрим набор моделей и методов полууправляемого обучения, которые в определенной степени решают эти проблемы. В частности, особое внимание уделяется текущим разработкам в области глубоких нейронных сетей (DNN) и опорных векторных машин (SVM). Другие модели машинного обучения также упоминаются для полноты картины.

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

1.3. Примечание по обмену сообщениями и безопасности

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

Микросервисы: безопасность, стабильность и управление данными

В этом разделе мы имеем дело с технологиями обмена сообщениями и развертывания приложений. Они важны как часть сбора данных и последующего распространения обновленного ИИ на границу сети. Эти две темы рассматриваются в одном разделе, поскольку технология WAMP инкапсулирует как Pub / Sub (публикация и подписка), так и RPC (удаленные вызовы процедур). Это делает возможным одновременное развертывание и потоковую передачу данных в рамках одного и того же протокола. Телекоммуникационные протоколы и технологии обмена сообщениями мотивированы, с одной стороны, проблемами совместимости между различными компонентами сборочных линий. С другой стороны, у нас есть проблемы с безопасностью и стабильностью, связанные с предотвращением вторжений и простоями сети. Кроме того, сложность сетей приложений, расширенных во времени и пространстве, требует оптимизированных механизмов привязки данных. Еще одна проблема заключается в том, что соответствующая сеть является динамической, что означает, что она состоит из узлов или соединений, которые активируются и деактивируются как часть автоматизированного производственного процесса.

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

OPC (сервер)

OPC (Open Platform Communications) был представлен в 1996 году как унифицирующий протокол для промышленной автоматизации. Основная идея заключается в том, что одна сборочная линия может работать с множеством различных устройств управления, например. ПЛК (программируемые логические контроллеры), между которыми могут быть несовместимые протоколы обмена сообщениями. Сервер OPC просто собирает данные со всех ПЛК и HMI (человеко-машинных интерфейсов) в заводской среде, используя модель сервер-клиент. Традиционно в ПЛК использовались разные протоколы Modbus и сети Ethernet. Учитывая проблемы совместимости, альтернативой OPC было специальное программное обеспечение, созданное для данной производственной линии, которое требует много времени, дорого и негибко. С одной стороны, этот недостаток оправдывает единый протокол (OPC). С другой стороны, недостатком является то, что OPC зависит от платформы (на базе Windows) и небезопасен (с открытыми портами).

OPC UA (сервер)

Вышеупомянутый протокол OPC был основополагающим телекоммуникационным стандартом в автоматизации производства до 2006 года, когда его новая версия OPC UA (Open Platform Communications Unified Architecture) вступила во владение. Таким образом, OPC UA превосходит возможности OPC. Начнем с того, что OPC UA не зависит от платформы, тогда как экосистема OPC находится в операционной системе Windows. Кроме того, существует несколько пакетов OPC UA с открытым исходным кодом, доступных на языках C, Python, JavaScript и т. Д.

Структура сервера OPC UA проста. У него есть корневой узел, который открывает канал связи (который может быть защищен брандмауэрами) и адресное пространство, в котором каждый узел является объектом (в смысле объектно-ориентированного программирования) с соответствующими функциями и атрибутами. (статические и динамические данные). Корневой узел может быть подключен к внешнему миру с помощью безопасного протокола, такого как MQTT и / или WAMP.

Сегодня OPC UA рассматривается как шлюз к так называемой Индустрии 4.0. Глобальный план по достижению полностью автоматизированной отрасли состоит в том, чтобы внедрить технологию OPC UA не только в устройства управления нового поколения (ПЛК, HMI и т. Д.), Но также и в любом устройстве, которое подключается к промышленным сетям IoT. Это упрощает ручную работу, связанную с программным обеспечением, которой нужно управлять и за которую нужно платить. Однако OPC UA - это межмашинный протокол, в то время как полностью автоматизированная настройка часто должна взаимодействовать с внешним миром, что означает для хост-сервера или реестра приложений.

Экосистемы приложений могут находиться в облаке или на локальных объектах, удаленных от производственного цеха. Следовательно, необходимо управлять информацией, которая должна передаваться из / в локальную сеть IoT в / из внешнего мира, или обновлять приложения. Для обеспечения такого потока данных существует несколько отраслевых технологий безопасного обмена сообщениями, из которых мы рассмотрим только MQTT и WAMP [28, 33].

Безопасный обмен сообщениями Интернета вещей: MQTT и WAMP

MQTT - это безопасный протокол связи IoT с механизмом публикации / подписки. Доступно множество реализаций маршрутизаторов, наиболее известной из которых является RabbitMQ, поддерживаемый pivotal. MQTT существует уже некоторое время и широко используется в отрасли. Используя решение для обмена сообщениями, вы быстро оказываетесь в среде микросервисов с различными типами клиентских устройств и языков программирования на стороне клиента. У каждого языка есть свои собственные структуры данных, которые вы хотите получать или отправлять через службу обмена сообщениями, такую как MQTT или WAMP. MQTT предоставляет каждому программисту право кодировать и декодировать полезную нагрузку сообщения на стороне отправителя / получателя, поскольку MQTT может передавать только байтовые потоки. Процесс кодирования структурированных данных в поток байтов называется сериализацией. Недостатком этого подхода является то, что сеть должна согласовывать формат сериализации, чтобы любой получатель мог понять содержимое сообщения. Фреймворк сериализации Google protobuf с компиляторами для разных языков - один из многих способов обработки сериализации с помощью MQTT. Однако Javascript не поддерживается, поэтому его нельзя использовать для связи с веб-браузерами.
Протокол WAMP также предоставляет механизм pub / sub, как и MQTT, но также имеет некоторые важные дополнительные функции. Один из них - прозрачная поддержка разнообразных протоколов сериализации (CBOR, UBJSON, MSGPACK,…). Используя клиентские библиотеки WAMP (autobahn) и маршрутизатор WAMP (crossbar.io), вы можете отправлять структуры данных от любого клиента другому, каждый из которых отправляет или получает полезную нагрузку в своем собственном формате. Например, вы можете отправить dict от клиента Python и получить объект JavaScript в клиенте JavaScript.
Еще одна важная функция - это возможность использовать второй основной коммуникационный шаблон Удаленный вызов процедуры. Одним из важных последствий использования службы обмена сообщениями, объединяющей оба шаблона, является то, что вам не нужно полагаться на две разные технологии для публикации / подписки и RPC для реализации полной архитектуры приложения. (Часто обработка веб-запросов на основе REST используется для обеспечения связи в стиле RPC, для чего требуется веб-сервер в качестве дополнительного архитектурного узла рядом с маршрутизатором сообщений.)

Доступны мосты OPC UA - MQTT и OPC UA - WAMP и MQTT - WAMP . Сетевая архитектура является гибкой и может удовлетворить потребности гетерогенных промышленных сред IoT.

2. Архитектурный дизайн промышленного Интернета вещей

Профилактическое обслуживание и Интернет вещей идут рука об руку. Чтобы процитировать [21]:

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

Беспроводное подключение
Недорогие датчики
Облачные вычисления
Аналитика или искусственный интеллект (AI)

По отдельности каждая из этих технологий приносит определенную пользу. Объединенные в единое решение, они способны изменить индустриальный мир. [21]

Архитектура Интернета вещей состоит из четырех основных частей:

›A. Edge Devices

Название говорит само за себя. Пограничные устройства находятся на дальнем конце сети IoT, рядом с источником данных. Они просто состоят из блока обработки (архитектура ARM или даже компьютер меньшего размера) плюс одна или несколько конечных точек наблюдения (датчики, камеры, микрофоны и т. Д.).

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

›Б. Сеть

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

›C. Служба управления устройствами

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

›D. Служба управления данными

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

…

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

…

2.3. Как управлять своими устройствами

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

Опишите проблемы с помощью:

Управление устройствами. Необходимо следить за самими устройствами Интернета вещей и управлять настройками устройств в соответствии с потребностями среды Интернета вещей.
Неоднородность сред и конфигураций (brownfield): любая новая архитектура программного обеспечения должна учитывать и сосуществовать с уже используемым программным обеспечением.
Развертывание по беспроводной сети. Когда вы готовы распространить приложение по беспроводной сети на группу устройств, вы создаете развертывание для приложения. Развертывание доставляет программное обеспечение по воздуху в среду приложений на устройствах, на которых оно работает. В любой момент времени для конкретного устройства активно только одно развертывание.
Удаленное управление настройками подключения. Используя тот же механизм, что и управление устройством, можно также управлять настройками подключения (с помощью различных протоколов).
Качество сети (буферизация данных) не всегда может быть на высшем уровне. Таким образом, мы должны работать с локальными буферами, если не хотим использовать данные. Это также включает в себя оптимальную потоковую модель. Реализация таких моделей требует автоматического выбора параметров.
Сетевая безопасность имеет первостепенное значение, особенно от вторжений или атак. Мы уже упоминали о проблемах безопасности выше (см. Наше обсуждение OPC, MQTT и WAMP).

В промышленной среде, где IoT встроен в производственный процесс, приходится иметь дело с различными источниками данных. Этот процесс является динамическим и автоматизированным, и, как правило, любое развертывание или обновление Интернета вещей не должно прерывать производство. Во-первых, функциональность в приложениях может развиваться или должен быть доступен механизм развертывания на тот случай, если должна быть создана новая функциональность. Более того, в сеть можно добавлять новые устройства. Этим следует управлять по модульному принципу, чтобы развивающиеся приложения могли соответствовать потребностям этой сложной динамической среды. Метод управления должен быть достаточно гибким, чтобы реализовать реестр приложений локально или в облаке. Он должен решить одну из основных проблем такой инфраструктуры, а именно безопасность: предотвращение вторжений и вмешательств.

2.4. Как управлять данными Интернета вещей

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

Ниже мы описываем основные проблемы:

Объем данных. Скоро мы будем иметь дело с Интернетом вещей в больших масштабах, а это означает, что нам понадобится оптимизированная инфраструктура хранения для так называемых больших данных.
Чувствительность к времени в реальном времени и пакетная обработка: нам необходимо организовать входящие данные в хранилище в режиме реального времени. Альтернативой является пакетная обработка, которая просто требует больше времени и ресурсов.
Неоднородность (отсутствие стандартов структур данных): данные могут собираться и передаваться с использованием различных протоколов и стандартов. Нам необходимо кодировать данные в источнике перед потоковой передачей и декодировать их в хранилище. Это также можно сделать с помощью механизмов маршрутизации на основе WAMP или MQTT (например, Crossbar).
Управление потоком данных: из-за этой сложности нам необходимо отслеживать все преобразования данных. Для этого есть несколько различных способов, например, код SQL или графическое представление конвейера.
Управление метаданными имеет решающее значение при оценке состояния сети и возможной оптимизации потоковой передачи. Нам также необходимо отслеживать свойства источников данных, таких как машины, заводская среда, данные устройств и т. Д.
Качество данных, преобразование для удобства использования: нам нужно иметь дело с недостающими данными в хранилище, а также в источнике данных; управление качеством должно быть автоматизированным и прозрачным.
Создание больших историй данных означает, что нам необходимо отслеживать временные ряды, поскольку последовательная корреляция в медленных временных масштабах может иметь решающее значение для профилактического обслуживания.
Возможность аудита данных - важная часть процесса, поскольку данные часто имеют ценность для бизнеса или собираются для решения проблемы. Часто бывает проще иметь дело с механизмом хранения, если у вас уже есть хорошая прогностическая модель.

Пока на устройствах развернуты приложения для сбора данных, мы можем начать сбор данных. Тем не менее, остается вопрос, как можно управлять такими данными с огромным объемом и мультимодальным характером. Частично этим можно управлять с помощью механизма развертывания приложений через RPC, например инкапсуляция различных структур данных, кодирование и декодирование. Опять же, с помощью потоковой передачи RPC параметры можно адаптировать вручную или автоматически. Однако нам необходимо хранить данные последовательно, то есть следует уважать источники, а операции с таблицами (SQL) должны быть прозрачными. Более того, данные в масштабе времени порождают еще больше проблем, поскольку часто данные имеют последовательную и параллельную корреляцию - поскольку часто решающим аспектом может быть физическая близость. Вот почему нужно отслеживать ванны и метаданные устройства в динамической среде. Как справиться со всей этой сложностью? Ответим на этот вопрос.

2.5. Студия разработки Интернета вещей Record Evolution

После того, как мы обрисовали в общих чертах основные проблемы, связанные с управлением устройствами и данными, мы пришли к тому, чтобы представить решение. Наше решение реализовано в новой платформе управления устройствами / приложениями Интернета вещей под названием Record Evolution IoT Development Studio. Студия Интернета вещей предлагает среду управления роем на основе WAMP. Сложность архитектуры, рассматриваемой в нашем решении, представлена на блок-схеме ниже:

Приложения могут находиться в облаке или локальном реестре, в то время как развертывание приложений может быть легко реализовано с использованием функций (на основе RPC) студии разработки IoT. Связь безопасна и последовательна (на основе паблика / субподразделения). Это снимок работающего экземпляра интерфейса студии разработки Интернета вещей со всеми его кнопками, связанными с управлением приложениями. Используя студию разработки, ваше приложение можно изменить:

Подробное описание технических особенностей Record Evolution IoT Development Studio выходит за рамки данной статьи. В общем, пока доступен механизм наследования рекурсивного обучения (так называемое онлайн-обучение), можно развертывать новые версии интеллектуальных моделей на различных устройствах с помощью контейнерной технологии (например, Docker) и обмена сообщениями WAMP (например, Crossbar).

2.6. Выбор архитектуры хранилища. Это большая тема сама по себе. Первый вопрос: какую модель данных мне использовать? Второй вопрос: какой вариант SQL / NoSQL мне выбрать и какую инфраструктуру хранения выбрать? Выбор подходящей технологии хранения для решения для долгосрочного управления данными - непростая задача, поскольку она требует принятия множества технических и концептуальных решений. Если вы хотите создать решение самостоятельно, используя компоненты с открытым исходным кодом, вы можете посмотреть на различные базы данных временных рядов, такие как InfxDB или PostgreSQL с расширением timescaleDB, или вы можете выбрать решение для кластерного хранилища, такое как HDFS, GlusterFS или Cassandra. . У каждого есть свои достоинства и недостатки.

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

Чтобы упростить эти задачи, мы предлагаем научную студию Record Evolution. Для обсуждения темы и этой платформы мы отсылаем вас к следующей средней статье [36].

Заключение - Часть II

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

Каковы свойства разных источников данных Интернета вещей?
Какова структура различных ресурсов в иерархии Интернета вещей?
Как можно хранить данные и в каком формате?

IoT - это будущее, но данные IoT создают множество технических проблем. По нашему мнению, сбор и потоковая передача огромных объемов данных с помощью ИИ - одна из наиболее актуальных проблем. Теоретически IoT может состоять из взаимосвязанных и взаимодействующих узлов вместо простой постоянной потоковой передачи или модели ведущий / ведомый. На практике для этого требуется инфраструктура обмена сообщениями и развертывания. В качестве возможного решения мы предлагаем Record Evolution IoT Development Studio, среду управления и разработки на основе WAMP. Несмотря на то, что еще не тестировалась в большом масштабе, студия разработки IoT теоретически масштабируема и предлагает простые в использовании функции для управления устройствами и приложениями в заводских средах.

Свойства данных IoT и инфраструктуры хранения данных также упоминаются выше. Основные проблемы, присущие этому, включают отслеживание коррелированных источников данных, сбор метаданных и постоянное хранение временных меток. Более того, прозрачный метод хранения данных помогает нам очищать и готовить данные для обучения крупномасштабных сетевых моделей. Для этих задач мы предлагаем Студию науки о данных Record Evolution. Вы получаете платформу облачных данных с соединителями IoT и функциями SQL, представленными в виде конвейеров данных. Платформа предоставляет пользователям функцию API и настраиваемые функции отчетности (например, D3, HTML). Посетите наш канал для получения дополнительной информации о платформе облачных данных и следите за обновлениями.

…

Мы все еще в долгу перед читателем и искупим это в ЧАСТИ III, ответив на следующие вопросы:

Почему алгоритмы машинного обучения актуальны для периферийных вычислений Интернета вещей?
Как реализованы эти алгоритмы?

________o_______________o_______

Благодарности

Спасибо доктору Марко Петцольду и доктору Свену Дорошу за наши обсуждения. Особая благодарность доктору Петцольду за его вклад в разделы управления данными и устройствами.