Информация

Дата основания
Местоположение
США
Сайт
ibm.com
Численность
1 001–5 000 человек
Дата регистрации

Блог на Хабре

Обновить
Комментарии 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 в вашем понимании?

Edge device — это устройство, которое может производить обработку данных от сенсоров, камер и прочих устройств. Edge Server, как видно из архитектуры, это кластер Kubernetes или OpenShift, который находится близко к данным, но может обрабатывать например поток с сотни камер.
В Open Horizon осуществлен единый подход к управлению приложением, как на уровне чистого Docker, так и управлению приложением в кластере. Для интеграции с Edge device используется Anax компонент, а для интеграции с кластером Klusterlet. Хотя для администратора системы — сценарий один — управление приложением на Edge node(s).

Аппаратно это может быть одно и тоже устройство?

не вижу смысла размещать edger device и edge server на одном физическом устройстве. Можно обойтись с помощью edge server, подключив к нему датчики и сенсоры.

Я хотел спросить другое. Edge device и Edge server аппаратно могут быть одно и тоже, но программно разные — это имелось ввиду?

теоретически ограничений нет, в этом случае один агент будет работать на уровне Docker, второй на уровне кластера. Главный вопрос в том, что в данном случае приложение на Edge Device можно перенести на Edge Server и отказаться от Edge device, осуществив подключение периферии напрямую в кластер. Хотя могут быть устройства интерфейс которых невозможно пробросить в кластер.

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