Комментарии 15
Прочитал. Осталось ощущение какой-то недосказанности. Давайте конкретные примеры внедрения, технологический стек и прочие "кровавые" подробности для инженеров.
https://open-horizon.github.io/
Посмотрел. Сайт пустой. Грустно. Ушел печальный.
Ну, и до кучи — помимо платформы нужна еще сборка оконечных устройств, их заливка и все такое. Т.е. целые дерево технологических процессов. Быстро глянул — даже для более-менее популярных распи инструкцию на стопицот абзацев. А мы, дураки, образы печь пытаемся для автоматизации… (
Касательно платформы IBM Watson IoT — да, крутая штука, но тут еще надо понимать TCO ее владением.
Спасибо за комментарий. Недосказанность запланирована, так как хотелось сделать вводную. В плане еще две статьи — одна про сценарии, а вторая про наш проект, где мы вывели решение на edge computing до уровня продуктива.
Ссылку на гитхаб не ту использовал — правильная в разделе ссылок. В рамках нашей последней конференции делали лабораторную работу, все работает.
Про конечные устройства очень интересная тема. В одном из топиков раскроем, как мы модель распознавания дефектов запускали на Jetson TX2. Для нетерпеливых есть небольшое описание на английском в блоге IBM.
“Стрелка”, я понял, что это в чистом виде edge computing
До прихода IoT и Edge было понятие встраиваемые системы. В большенстве своем edge computing трактуется очень узко, хотя он окружает нас повсюду — транспорт, энергетика, жкх, сельское хозяйство, ЖД, производство и т.д.
Есть вопрос — какое должно быть аппаратное обеспечение(набор интерфейсов или архитектура), чтобы можно было бы использовать ваше решение, если иметь ввиду удаленное управление?
В данный момент edge сервисы работают на уровне контейнеров или Pod в кластере. По поводу архитектуры процессов — amd64, большинство arm, ppc64le. Под архитектуру завязан только агент. Его код в Open Source — Anax. Он написан на GoLang, так что портирование достаточно простая задача. Мы в своем решении использовали ARM версию для Jetson TX. Сам Anax использует MQTT для связи с центральным хабом.
Встраиваемые системы редко управлялись централизованно. Обычно все управление было ручным, по крайне мере те, с которыми я работал.
большинство arm
армов минимум два — armhf & arm64 — ну, это мало ли кто столкнется с этим.
Встраиваемые системы редко управлялись централизованно. Обычно все управление было ручным, по крайне мере те, с которыми я работал.
я думаю, что есть два типа систем. Что-то типа кубернетеса — очень централизованные системы, которые отвечают за оркестрацию и выкидывание сдохших узлов (селф-хилинг и все такое). И нечто типа "роя" — когда каждая пчела опрашивает улей на предмет тех же обновлений и умеет откатываться в случае, если обновление сбойное. Вообще скомпоновать такую систему при учете того, что пчела может быть и не сдохла, но не выходит на связь, т.к. лег интернет — достаточно нетривиальная задача. Плюс если еще секурити вопросы учитывать (возможность подмены злоумышленником "улея" на свой и слива всех данных и получения контроля над "пчелой")
Между прочим, в таком ключе известный обыгрыш логотипа IBM выглядит в новом свете
армов минимум два — armhf & arm64 — ну, это мало ли кто столкнется с этим.
фреймворк работает и с тем и с тем.
когда каждая пчела опрашивает улей на предмет тех же обновлений и умеет откатываться в случае, если обновление сбойное
я видел наработки и исследования на тему edge computing и децентрализованного консенсуса. Есть определенный круг задач, где решение имело бы смысл. К сожалению на практике не встречал.
Встраиваемые системы редко управлялись централизованно
В закрытых контурах управление производится в ручную и не ценролизованно, а других потребителей в этой стране раньше и не было. Не знаю как в «Стрелке», но обновлять все радары в ручную ещё то удовольствие.
Edge device — это устройство, которое может производить обработку данных от сенсоров, камер и прочих устройств. Edge Server, как видно из архитектуры, это кластер Kubernetes или OpenShift, который находится близко к данным, но может обрабатывать например поток с сотни камер.
В Open Horizon осуществлен единый подход к управлению приложением, как на уровне чистого Docker, так и управлению приложением в кластере. Для интеграции с Edge device используется Anax компонент, а для интеграции с кластером Klusterlet. Хотя для администратора системы — сценарий один — управление приложением на Edge node(s).
не вижу смысла размещать edger device и edge server на одном физическом устройстве. Можно обойтись с помощью edge server, подключив к нему датчики и сенсоры.
теоретически ограничений нет, в этом случае один агент будет работать на уровне Docker, второй на уровне кластера. Главный вопрос в том, что в данном случае приложение на Edge Device можно перенести на Edge Server и отказаться от Edge device, осуществив подключение периферии напрямую в кластер. Хотя могут быть устройства интерфейс которых невозможно пробросить в кластер.
Edge-ик в тумане и другие приключения периферийных вычислений