теоретически ограничений нет, в этом случае один агент будет работать на уровне Docker, второй на уровне кластера. Главный вопрос в том, что в данном случае приложение на Edge Device можно перенести на Edge Server и отказаться от Edge device, осуществив подключение периферии напрямую в кластер. Хотя могут быть устройства интерфейс которых невозможно пробросить в кластер.
не вижу смысла размещать edger device и edge server на одном физическом устройстве. Можно обойтись с помощью edge server, подключив к нему датчики и сенсоры.
Edge device — это устройство, которое может производить обработку данных от сенсоров, камер и прочих устройств. Edge Server, как видно из архитектуры, это кластер Kubernetes или OpenShift, который находится близко к данным, но может обрабатывать например поток с сотни камер.
В Open Horizon осуществлен единый подход к управлению приложением, как на уровне чистого Docker, так и управлению приложением в кластере. Для интеграции с Edge device используется Anax компонент, а для интеграции с кластером Klusterlet. Хотя для администратора системы — сценарий один — управление приложением на Edge node(s).
Думаю, что для "Стрелок" написано что-то свое. В прошлой жизни, работая в РосАтоме, даже на атомных электростанциях есть свои системы управления встроенными системами. Вопрос в том, что они редко универсальны.
армов минимум два — armhf & arm64 — ну, это мало ли кто столкнется с этим.
фреймворк работает и с тем и с тем.
когда каждая пчела опрашивает улей на предмет тех же обновлений и умеет откатываться в случае, если обновление сбойное
я видел наработки и исследования на тему edge computing и децентрализованного консенсуса. Есть определенный круг задач, где решение имело бы смысл. К сожалению на практике не встречал.
В данный момент edge сервисы работают на уровне контейнеров или Pod в кластере. По поводу архитектуры процессов — amd64, большинство arm, ppc64le. Под архитектуру завязан только агент. Его код в Open Source — Anax. Он написан на GoLang, так что портирование достаточно простая задача. Мы в своем решении использовали ARM версию для Jetson TX. Сам Anax использует MQTT для связи с центральным хабом.
Встраиваемые системы редко управлялись централизованно. Обычно все управление было ручным, по крайне мере те, с которыми я работал.
Спасибо за комментарий. Недосказанность запланирована, так как хотелось сделать вводную. В плане еще две статьи — одна про сценарии, а вторая про наш проект, где мы вывели решение на edge computing до уровня продуктива.
Ссылку на гитхаб не ту использовал — правильная в разделе ссылок. В рамках нашей последней конференции делали лабораторную работу, все работает.
Про конечные устройства очень интересная тема. В одном из топиков раскроем, как мы модель распознавания дефектов запускали на Jetson TX2. Для нетерпеливых есть небольшое описание на английском в блоге IBM.
Добрый,
в целом если разбить на составляющие, то сам Watson это бренд над достаточно большим набором сервисов (Watson Speech To Text (STT), Watson Text To Speech(TTS), Watson conversation, Watson studio, Watson image recognition ...). В зависимости от задач выбирается определенный набор. В данном случае участвует STT, TTS и Watson conversation. STT и TTS могут обучаться. Для этого есть специальный REST API на который необходимо отправить корректно ли отработал сервис и какой результат ожидался. Хотя по моему данный фидбек будет каплей в море. Если использовать сервисы в промышленных масштабах, то делается отдельная инсталляция сервиса, со своими обособленными моделями. А если хочется сделать что-то свое, то отлично подойдет Watson Studio. Тут тебе jupyter, zeppelin, R Studio, pipeline моделей и ускорение на GPU. Сам диалог в данном открытом проекте не самообучается, он основан на древовидных цепочках бесед(JSON, XML). Добавить их динамическое добавление не составит труда, но обычно это делается под определенные сценарии (например служба поддержки клиентов банка).
Думаю WiFI не указали так как он уже встроен в raspberry pi. В целом есть проекты где дообучение моделей происходит на самих устройствах, но в этом случае имеет смысл использования fog computing и других устройств(например Jetson TX2, Jetson nano).
теоретически ограничений нет, в этом случае один агент будет работать на уровне Docker, второй на уровне кластера. Главный вопрос в том, что в данном случае приложение на Edge Device можно перенести на Edge Server и отказаться от Edge device, осуществив подключение периферии напрямую в кластер. Хотя могут быть устройства интерфейс которых невозможно пробросить в кластер.
не вижу смысла размещать edger device и edge server на одном физическом устройстве. Можно обойтись с помощью edge server, подключив к нему датчики и сенсоры.
Edge device — это устройство, которое может производить обработку данных от сенсоров, камер и прочих устройств. Edge Server, как видно из архитектуры, это кластер Kubernetes или OpenShift, который находится близко к данным, но может обрабатывать например поток с сотни камер.
В Open Horizon осуществлен единый подход к управлению приложением, как на уровне чистого Docker, так и управлению приложением в кластере. Для интеграции с Edge device используется Anax компонент, а для интеграции с кластером Klusterlet. Хотя для администратора системы — сценарий один — управление приложением на Edge node(s).
Думаю, что для "Стрелок" написано что-то свое. В прошлой жизни, работая в РосАтоме, даже на атомных электростанциях есть свои системы управления встроенными системами. Вопрос в том, что они редко универсальны.
фреймворк работает и с тем и с тем.
я видел наработки и исследования на тему edge computing и децентрализованного консенсуса. Есть определенный круг задач, где решение имело бы смысл. К сожалению на практике не встречал.
В данный момент edge сервисы работают на уровне контейнеров или Pod в кластере. По поводу архитектуры процессов — amd64, большинство arm, ppc64le. Под архитектуру завязан только агент. Его код в Open Source — Anax. Он написан на GoLang, так что портирование достаточно простая задача. Мы в своем решении использовали ARM версию для Jetson TX. Сам Anax использует MQTT для связи с центральным хабом.
Встраиваемые системы редко управлялись централизованно. Обычно все управление было ручным, по крайне мере те, с которыми я работал.
Спасибо за комментарий. Недосказанность запланирована, так как хотелось сделать вводную. В плане еще две статьи — одна про сценарии, а вторая про наш проект, где мы вывели решение на edge computing до уровня продуктива.
Ссылку на гитхаб не ту использовал — правильная в разделе ссылок. В рамках нашей последней конференции делали лабораторную работу, все работает.
Про конечные устройства очень интересная тема. В одном из топиков раскроем, как мы модель распознавания дефектов запускали на Jetson TX2. Для нетерпеливых есть небольшое описание на английском в блоге IBM.
в целом если разбить на составляющие, то сам Watson это бренд над достаточно большим набором сервисов (Watson Speech To Text (STT), Watson Text To Speech(TTS), Watson conversation, Watson studio, Watson image recognition ...). В зависимости от задач выбирается определенный набор. В данном случае участвует STT, TTS и Watson conversation. STT и TTS могут обучаться. Для этого есть специальный REST API на который необходимо отправить корректно ли отработал сервис и какой результат ожидался. Хотя по моему данный фидбек будет каплей в море. Если использовать сервисы в промышленных масштабах, то делается отдельная инсталляция сервиса, со своими обособленными моделями. А если хочется сделать что-то свое, то отлично подойдет Watson Studio. Тут тебе jupyter, zeppelin, R Studio, pipeline моделей и ускорение на GPU. Сам диалог в данном открытом проекте не самообучается, он основан на древовидных цепочках бесед(JSON, XML). Добавить их динамическое добавление не составит труда, но обычно это делается под определенные сценарии (например служба поддержки клиентов банка).
Думаю WiFI не указали так как он уже встроен в raspberry pi. В целом есть проекты где дообучение моделей происходит на самих устройствах, но в этом случае имеет смысл использования fog computing и других устройств(например Jetson TX2, Jetson nano).