Способ потоковой обработки данных с iot устройств

Изобретение относится к области вычислительной техники, в частности к системам потоковой обработки данных с IoT устройств. Технический результат изобретения состоит в оптимизации использования технических ресурсов обслуживающих серверов путем высвобождения малоиспользуемых и нагружения новых ресурсов при росте нагрузки. Система выступает в роли кластерного ПО и шины передачи данных одновременно. Каждый узел, входящий в систему, имеет одинаковый набор функциональностей, что позволяет сохранить полную функциональность при частичной потере кластера - нескольких вычислительных узлов. Горизонтальное масштабирование выполняется автоматически, выделяя и высвобождая ресурсы в зависимости от текущего профиля нагрузки конкретных функций и загруженности вычислительных узлов, обеспечивая требуемый уровень производительности. Способ характеризуется использованием в качестве блоков управления данными и принятия решений контролирующих фабрик, состоящих из набора серверов и/или виртуальных машин (серверный пул), причем в контролирующей фабрике осуществляют контроль за IoT устройствами пользователей, подключение их к наиболее близкой и наименее нагруженной вычислительной фабрике, где вычислительные фабрики представляют из себя набор серверного оборудования и/или виртуальных машин (серверный пул) с заданным программным обеспечением, позволяющим в каждой вычислительной фабрике вести обработку данных IoT устройств, сбор статистики конфигурации IoT устройств, передачу новых версий прошивок, контроль за уязвимостями и конфигурацией программного обеспечения IoT устройств. 5 ил.

 

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

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

Таким образом существует техническая проблема автоматизированного анализа большого количества данных в системах IoT, в особенности для различных систем управления или контроля, в том числе в АСКУЭ (автоматизированная система коммерческого учета электроэнергии).

Подобные технические задачи решаются при помощи самообучающихся алгоритмов. Известны различные способы построения самообучающихся алгоритмов, называемые auto machine learning (автоматическое обучение машин) [Liu, Y. L. (2015). Automated machine learning tool. Получено из https://patents.google.com/patent/US20170193392А1/]. Они позволяют реализовывать модели машинного обучения для любых типов задач и данных.

Известен способ [US2017193392, опубл.: 2017-07-06], являющийся центром управления потреблением энергоресурсов на базе технологии IoT содержащий программно-аппаратные комплексы обработки данных и IoT -управления. Предложенные в нем решения могут использоваться для построения базовых частей системы.

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

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

Наиболее близким аналогом изобретения является система, описанная в патенте RU2731744, опубликовано: 08.09.2020. В ней обеспечивается уменьшение нагрузки на центральный сервер информационно-аналитической системы в IоТ сети и повышению ее автономности, а также автоматизация повторяющихся действий по обработке данных и построению моделей машинного обучения. Система содержит в себе центральный сервер, дублирующий сервер, системы хранения данных, системы связи с пользователем и множество конечных устройств сети IoT, на которые устанавливается система управления и принятия решений, включающая в себя средства загрузки, выполнения и обучения специализированных моделей машинного обучения, а также средства управления приборами.

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

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

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

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

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

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

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

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

В отличии от этих известных решений в заявленном изобретении используемый для обработки данных с датчиков IoT устройств ресурс разворачивается за минуты и не требует никаких дополнительных или сторонних компонент для функционирования.

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

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

Указанный технический результат достигается за счет того, что заявлен способ потоковой обработки данных с IoT устройств, включающий использование соединенных в сеть IоТ устройств пользователей, основных и дублирующих серверов, блоков управления данными и блоков управления анализом данных и принятия решений, базы данных, отличающийся использованием в качестве блоков управления данными и принятия решений контролирующих фабрик, состоящих из набора серверов и/или виртуальных машин (серверный пул), причем в контролирующей фабрике осуществляют контроль за IoT устройствами пользователей, подключение их к наиболее близкой и наименее нагруженной вычислительной фабрике, где вычислительные фабрики представляют из себя набор серверного оборудования и/или виртуальных машин (серверный пул) с заданным программным обеспечением, позволяющим в каждой вычислительной фабрике вести обработку данных IoT устройств, сбор статистики конфигурации IoT устройств, передачу новых версий прошивок, контроль за уязвимостями и конфигурацией программного обеспечения IoT устройств;

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

- служебное имя устройства

- тип устройства

- перечень собираемых данных

- внешний IP адрес устройства

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

- состояние контролирующей фабрики с возможным ответом On/Off/Failure

- количество обслуживаемых IoT устройств

- ближайшие регионы и другие фабрики, а также их состояние

- запрос состояния отправляется в виде наборов пакетов, используя протокол гарантированной передачи информации TCP;

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

- свое состояние (On/Off)

- количество обслуживаемых устройств

- другие доступные фабрики региона

- ответ о состоянии отправляется в виде наборов пакетов, используя протокол гарантированной передачи информации TCP;

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

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

- служебное имя устройства

- тип устройства

- перечень собираемых данных

- собираемые данные момент времени

- внешний IP адрес устройства

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

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

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

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

Краткое описание чертежей

На диаграмме Фиг.1 изображены логические компоненты, принимающие участие в процессе обработки данных с датчиков IoT устройств, все компоненты обмениваются сообщениями, используя TCP и UDP протоколы передачи данных.

На диаграмме Фиг.2 процесс отправки запроса ов другим доступным фабрикам региона.

На диаграмме Фиг.3 определения наименее нагруженной и самой географически близкой Вычислительной фабрике региона и процесс получения ответа о готовности Вычислительной фабрики принимать данные.

На диаграмме Фиг.4 показан процесс передачи данных выделенной Вычислительной фабрике напрямую от IoT устройств используя протокол негарантированной доставки данных UDP.

На диаграмме Фиг.5 показан процесс формирования новой вычислительной фабрики.

На чертежах: 1.0-1.3 - контролирующая фабрика, 2.0.1-2.3.3 - серверы контролирующей фабрики, 3.0-3.3 - вычислительная фабрика, 4.0.1-4.3.3 - база данных, 5.0-5.3 - IoT устройства, 6 - серверный пул, 7.2.1-7.2.3 - доступные к управлению контролирующей фабрикой сервера или виртуальные машины серверного пула, 8 - отправка IP адреса выделенной фабрики IoT устройству, 9 - передача данных напрямую от IoT устройства выделенной фабрике по протоколу UDP, 10 - запрос на масштабирование.

Осуществление изобретения

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

Новым в заявленном способе является то, что (см. Фиг.1) в качестве блоков управления данными и принятия решений контролирующих фабрик 1.0-1.3, состоящих из набора серверов 2.01-2.3.3 и/или виртуальных машин (серверный пул).

В контролирующей фабрике 1.0-1.3 осуществляют контроль за IoT устройствами 5.0-5.3 пользователей, подключение их к наиболее близкой и наименее нагруженной вычислительной фабрике (в примере на Фиг.1 - это поз.3.3), где вычислительные фабрики 3.0-3.3 представляют из себя набор серверного оборудования и/или виртуальных машин (серверный пул) с заданным программным обеспечением, позволяющим в каждой вычислительной фабрике вести обработку данных IoT устройств, сбор статистики конфигурации IoT устройств, передачу новых версий прошивок, контроль за уязвимостями и конфигурацией программного обеспечения IoT устройств.

Ниже описаны логические компоненты, принимающие участие в процессе обработки данных с датчиков IoT устройств.

IoT устройства (5.0-5.3) - устройствами так называемого интернета вещей являются различные бытовые и служебные устройства подключенные к сети Интернет. Каждое такое устройство имеет минимальный объем вычислительных мощностей для - изменения глобальных настроек самого устройства, выполнение базовых функций - запуска и исполнения пользовательских приложений, передачи статистики работы и данных о версии программного обеспечения (далее - ПО), примененных настройках и так далее. Каждое IoT устройство предконфигурируется перед поставкой пользователю - на заводе или на линии сборки. Такая настройка осуществляется разово - загружается первоначальная версия ПО, прописывается DNS адрес контролирующей фабрики. Это необходимо, чтобы устройство могло функционировать и иметь информацию о том, куда подключаться за получением новых версий ПО, куда отправлять данные о своем состоянии, настройках и работе.

Примеры бытовых IoT устройств:

- Умные телевизоры

- Умные холодильники

- Системы умного дома

- Системы безопасности для жилых и не жилых помещений

Интернет роутеры Интернет провайдеров

Датчики IoT устройств - некоторые умные устройства могут иметь наборы дополнительных датчиков, информация с которых должна отправляться Вычислительной Фабрике 3.0-3.3 для обработки, такими датчиками могут быть:

- Камеры безопасности

- Датчики движения

- Датчики влажности

- Датчики задымления

- Датчики температуры

Контролирующая фабрика (1.0-1.3) - представляет из себя набор серверного оборудования и/или виртуальных машин (серверный пул), серверное оборудования или ВМ размещаются в физическом центре обработки данных или на базе вычислительных мощностей оборудования облачного провайдера, например Google Cloud, Amazon AWS, MS Azure Cloud, Облако Ростелеком или другие. На вычислительных мощностях исполняется кластерное ПО, в задачи которого входит контроль за IoT устройствами, подключение их к наиболее близкой и наименее нагруженной Вычислительная фабрике. Таким образом, Контролирующая фабрика - кластер ПО выполняющий функции контроля всей инфраструктурой.

Вычислительная фабрика (3.0-3.3) - представляет из себя набор серверного оборудования и/или виртуальных машин (серверный пул), серверное оборудования или ВМ размещаются в физическом центре обработки данных или на базе вычислительных мощностей оборудования облачного провайдера, например Google Cloud, Amazon AWS, MS Azure Cloud, Облако Ростелеком или другие. На вычислительных мощностях исполняется кластерное ПО, в задачи которого входит:

- Получение и обработка статистики работы устройств

- Получение и обработка снимков конфигурации устройств

- Передача новых версий ПО (прошивок), для включения новых функций

- Контроль за уязвимостями ПО

- Контроль за конфигурацией ПО

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

Общий принцип работы заявленного способа

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

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

- Служебное имя устройства

- Тип устройства

- Перечень собираемых данных

- Внешний IP адрес устройства

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

Пакет информации должен быть гарантированно доставлен принимающей стороне, а именно серверному пулу Контролирующей фабрики 1.0-1.3. Для гарантии передачи такого регистрационного сообщения используется протокол гарантированной передачи данных, и формируются TCP пакеты, отправляемые в случае установки соединения между каким-то IoT устройством 5.0-5.N и какой-то Контролирующей фабрикой 1.0-1.3.

Пример такого соединения заключается в следующем.

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

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

- Состояние Контролирующей Фабрики - с возможным ответом On/Off/Failure

- Количество обслуживаемых устройств - целочисленная переменная

- Ближайшие регионы и другие Фабрики - перечень фабрик и их состояние

Запрос состояния отправляется в виде наборов пакетов, используя протокол гарантированной передачи информации TCP.

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

- Свое состояние, например - On или Off

- Количество обслуживаемых устройств - например 10.000

- Другие доступные фабрики региона

- Ответ о состоянии отправляется в виде наборов пакетов, используя протокол гарантированной передачи информации TCP.

Когда ответ доходит до Контролирующей фабрики 1.2 осуществляется обработка полученного ответа и отправляются запросы другим доступным фабрикам региона 1.0, 1.1 (см. Фиг.2). Запросы стандартны и также отправляются по протоколу TCP.

Собрав достаточное количество данных Контролирующая фабрика 1.2 определяет наименее нагруженную и самую географически близкую Вычислительную фабрику (в данном примере - это вычислительная фабрика 3.3).

Далее Контролирующая фабрика 1.2 отправляет запрос на обработку получаемых данных от IoT устройства 5.2 выбранной Вычислительную фабрике 3.3 и ожидает ответа от Вычислительной фабрики 3.3, что та готова к приему данных. Так Вычислительная фабрика 3.3 должна подготовить требуемые структуры в ее распределенной базе данных 4.3.1-4.3.3 для приема перечня заявленных данных, а также запустить экземпляр процесса приема и обработки данных. Запрос на обработку и ответ о готовности осуществляется так же используя протокол гарантированной передачи данных.

Когда Контролирующая фабрика 1.2 получает ответ 7 о готовности Вычислительной фабрики 3.3 принимать данные - Вычислительной фабрики 3.3 отправляется (поз. 8) адрес IoT устройству 5.2 в качестве ответа на инициализационное сообщение (см. Фиг.1). Отправка адреса 8 уходит так же по протоколу TCP.

Получив ответ от Контролирующей фабрики 1.2 IoT устройство 5.2 начинает передачу данных 9 выделенной Вычислительной фабрике 3.3 уже напрямую (см. Фиг.4). Данные передаются постоянно, используя протокол негарантированной доставки данных UDP. Каждое сообщение содержит поля:

- Служебное имя устройства

- Тип устройства

- Перечень собираемых данных

- Собираемые данные момент времени

- Внешний IP адрес устройства

Получая сообщения от устройств Вычислительная фабрика 3.3 разбирает их и укладывает в соответствующие поля распределенной базы данных Device Data (в данном примере 4.3.1-4.3.3). Эти данные становятся доступными для последующего анализа и обработки. Такая нагрузка также ложится на Вычислительную фабрику 3.3.

В случае повышенной нагрузки (см. Фиг.5) на определенную Вычислительную фабрику или в отсутствии доступных фабрик вычислительная фабрика региона (в данном примере на 3.1) отправляет в Контролирующую фабрику (в данном примере на 1.2) запрос 10 на масштабирование. Такой запрос так же отправляется по протоколу TCP.

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

Контролирующая фабрика 1.2 анализирует запрос, и принимает решение на масштабирование Вычислительной фабрики региона, созданию новой Вычислительной фабрики 3.2 или перенаправлении IoT устройств на вновь созданную другую фабрику 3.2.

Активация в работу (см. Фиг.5) новой вычислительной фабрики (в данном примере 3.2) происходит путем отправки на любой из доступных к управлению контролирующей фабрикой серверов 7.2.1-7.2.3 или виртуальных машин серверного пула 6 набора команд на установку соответствующего вычислительной фабрике ПО, затем отправляется команда на запуск в работу вычислительной фабрики 3.2, где было заданное ПО установлено (в данном примере на сервер 7.2.2).

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

Пример использования заявленного способа с IoT устройствами "Умный Дом"

Возьмем в качестве примера устройство "Умный Дом", в стандартный комплект которого войдут:

- IoT устройство умный дом

- Температурный датчик

- Датчик интеграции с системой кондиционирования

- Руководство по установке

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

После подключения к сети Интернет, IoT устройство Умный дом передает данные о себе, своем типе и доступных датчиках Контролирующей фабрике.

Контролирующая фабрика регистрирует IoT устройство как устройство Умного дома, с датчиком температуры и интеграцией с системой кондиционирования. Определяет из какого территориального региона пришел запрос на регистрацию, и ищет наименее нагруженный вычислительный кластер (Вычислительную фабрику). Отправляет данные о Вычислительной фабрике IoT устройству.

IoT устройство получает адрес Вычислительного кластера и начинает отправлять ему данные о своем состоянии, состоянии датчика и текущем состоянии системы кондиционирования.

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

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

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

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

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

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

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

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

В качестве технических ресурсов заявленного изобретения могут использоваться любые вычислительные платформы архитектуры x86_64, ARM или почти любые другие.

Как пример возможного исполнения можно рассматривать следующие варианты:

ФИЗИЧЕСКИЕ УЗЛЫ:

- Физический сервер

- Операционная система (Linux/MS Windows)

- Программное обеспечение

ВИРТУАЛЬНЫЕ МАШИНЫ ON-PREM С БОЛЕЕ ВЫСОКОЙ ПЛОТНОСТЬЮ:

- Физический сервер

- Гипервизор (VMWAre ESXi, QEMU-KVM)

- Виртуальный сервер (виртуальная машина)

- Операционная система (Linux/MS Windows)

Программное обеспечение

КОНТЕЙНЕРНАЯ ВИРТУАЛИЗАЦИЯ ON-PREM, С САМОЙ ВЫСОКОЙ ПЛОТНОСТЬЮ:

- Физический сервер

- Гипервизор (VMWAre ESXi, QEMU-KVM)

- Виртуальный сервер (виртуальная машина)

- Операционная система (Linux/MS Windows)

- Слой контейнерной виртуализации

- Программное обеспечение

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

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

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

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

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

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

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

ПО распределенной мульти-мастер системы, устанавливаемое на Вычислительную фабрику, представляет из себя небольшое приложение, поставляемое в виде пакета ОС Linux или бинарного файла.

Для запуска кластера по команде Контролирующей фабрики копируется данное ПО на каждый узел предполагаемого кластера и обеспечивается его выполнение путем отправки команды старта ПО (запуск).

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

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

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

Способ потоковой обработки данных с IoT устройств, включающий использование соединенных в сеть IоТ устройств пользователей, основных и дублирующих серверов, блоков управления данными и блоков управления анализом данных и принятия решений, базы данных, отличающийся использованием в качестве блоков управления данными и принятия решений контролирующих фабрик, состоящих из набора серверов и/или виртуальных машин (серверный пул), причем в контролирующей фабрике осуществляют контроль за IoT устройствами пользователей, подключение их к наиболее близкой и наименее нагруженной вычислительной фабрике, где вычислительные фабрики представляют из себя набор серверного оборудования и/или виртуальных машин (серверный пул) с заданным программным обеспечением, позволяющим в каждой вычислительной фабрике вести обработку данных IoT устройств, сбор статистики конфигурации IoT устройств, передачу новых версий прошивок, контроль за уязвимостями и конфигурацией программного обеспечения IoT устройств;

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

служебное имя устройства,

тип устройства,

перечень собираемых данных,

внешний IP адрес устройства,

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

состояние контролирующей фабрики с возможным ответом On/Off/Failure,

количество обслуживаемых IoT устройств,

ближайшие регионы и другие фабрики, а также их состояние,

запрос состояния отправляется в виде наборов пакетов, используя протокол гарантированной передачи информации TCP;

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

свое состояние (On/Off),

количество обслуживаемых устройств,

другие доступные фабрики региона,

ответ о состоянии отправляется в виде наборов пакетов, используя протокол гарантированной передачи информации TCP;

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

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

служебное имя устройства,

тип устройства,

перечень собираемых данных,

собираемые данные в момент времени,

внешний IP адрес устройства,

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

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

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

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