Интернет вещей — это далеко не только умные чайники, лампочки и пылесосы. Гораздо больше взрывающих мозг решений реализовано в области так называемого промышленного Интернета вещей (Industrial Internet of Things, IIoT). Как раз ему и посвящён этот доклад.
Так, в 1-ой части рассказывается, что в современных животноводческих хозяйствах коровы пасутся уже не с колокольчиком на шее, а с GPS-датчиком, имеющим на борту встроенный акселерометр. Последний умеет определять состояние животного по его движениям: заболевание, готовность к оплодотворению и тому подобное. В одном реальном проекте эти данные наряду с координатами передаются по протоколу MQTT и с помощью open-source библиотеки Eclipse Paho оседают в IoT-платформе AggreGate — специализированном ПО (на Java) для интеграции устройств с остальным миром. AggreGate, на примере которого рассмотрено большинство кейсов доклада, может хранить данные в Cassandra’е, запущенной как традиционно, так и в embedded-режиме. Embedded сильно упрощает развертывание, хотя за это приходится платить масштабируемостью, а иногда и неочевидным расходом памяти (proof из Eclipse MAT прилагается). Зато пастух теперь ходит не только с плёткой, но и со смартфоном, где ему в близком к реальному времени отображается геопозиция всего парка подконтрольных ему голов. Но это лишь один кейс.
Удобно разбираться с инженерными системами большого здания, когда есть их подробный поэтажный план. Ещё удобнее, когда он представлен трехмерной интерактивной моделью. Но куда круче, когда все узлы этой 3D-модели отражают реальное состояние и метрики соответствующих устройств: датчиков, кондиционеров, ламп и тому подобное. Такая модель называется «цифровой двойник здания» (Digital Twin) и рассматривается во 2-ой части доклада. В стоящем за ней реальном проекте IoT-платформа получает данные от устройств по промышленному протоколу BACnet, поддержку которого для Java обеспечивает библиотека BACnet4j. У неё непростая судьба, поэтому в работе с ней приходится не только читать исходники, но и применять специальный диссектор в WireShark. Зато в остальном всё стандартно: платформа как бэкенд выставляет REST API на Spring WebMVC, потребляемый сторонним веб-клиентом на React (это где 3D и прочая красота). И всё работает. Почти. Если бы не CORS. И об этом в докладе есть отдельная заметка.
Только не надо думать, что IoT-платформа — это чисто про бэкенд. Так, на большом проекте для одной госкорпорации средствами веб-интерфейса AggreGate (на том же React) была запилена полноценная визуализация производственной линии по обработке сахарной свеклы, а по следам этого проекта — интерактивная демка , где любой желающий может поиграться с моделью этой линии, задавая на входе условия поставки свеклы и наблюдая весь процесс ее превращения в сахар. Как раз этой игре и посвящен небольшой перерыв между 2-ой и 3-ей частями доклада.
А 3-я часть начинается в... Якутии, на нефтяном месторождении. Оказывается, на таких предприятиях используются сложнейшие агрегаты, сплошь увешанные всевозможными датчиками. IoT-платформа здесь находит применение в том, чтобы быть единым инструментом, который умеет собирать данные с датчиков, интеллектуально обрабатывать их и всячески выдавать результаты (веб-дашборды, PDF-отчёты, интеграция с ERP/MES и т.д.). Это нужно, чтобы реализовать так называемое «прогностическое обслуживание» — когда агрегат начинают обслуживать не после поломки, и даже не при первых ее признаках, а задолго заранее. Благодаря этому, удаётся избегать колоссальных расходов, вызванных сбоем и простоем агрегата. В одном из реальных проектов на том же AggreGate интеллектуальная обработка делается средствами встроенного модуля машинного обучения. И хотя сам модуль из коробки написан на Java и работает на библиотеке Weka, он также поддерживает выполнение скриптов на Python через мостик под названием JEP (Java Embedded Python), который под капотом через JNI запускает «традиционный» движок CPython. Это позволяет быстро выполнять даже большие скрипты и давать на выходе наборы вероятностей и примерных времён поломки различных узлов агрегата — как раз то, что нужно оператору, чтобы вовремя начать обслуживание.
Чтобы как-то объединить такие разные рассмотренные кейсы применения IIoT, в 4-ой части доклада рассказывается о нормализации — способе унифицировать данные от самых разных устройств и для самых разных интеграций. В случае AggreGate за это отвечает т.н. «Единая модель данных», внутри которой все данные хранятся в собственном
Заключительная, 5-ая часть доклада, кроме стандартного резюме и попытки дать хорошее определение понятию «IoT-платформа», добивает слушателя сводкой полезных ссылок по теме IoT: на карту всех областей применения IoT, на русский справочник IoT-терминов, на площадки вопросов и ответов. А тем смельчакам, кто хочет повникать в слайды или кто после прочтения этого поста решил посмотреть доклад, предлагает ссылки на презентацию. Приятного чтения и просмотра.