Комментарии 7
хорошо, а как быть, если есть требование чтоб рабочий сервис был в соседней команате?
обычный платежный терминал нельзя подключать какому-то там облаку, а вдруг перекроют канал
обычный платежный терминал нельзя подключать какому-то там облаку, а вдруг перекроют канал
В случае, описанном в статье, речь шла именно о централизованном отслеживании, когда на одной панели мониторинга будет видно «сразу все». Киоски изначально имели подключение к Интернету по условию задачи, т.к. оттуда берутся данные для пользователя. Нет сети — киоск в принципе не работает, как надо (кстати, этот случай при централизованном мониторинге тоже можно отследить, в статье описано, как именно).
Если вопрос в том, что делать при временном пропадании сети, то можно добавить в решение IoT Edge, который прозрачно все закэширует и при появлении сети отправит данные в облако. Это вообще достаточно мощный продукт, который очень много может помимо собственно кэширования данных.
Если вопрос в том, что делать, если сети вообще нет, или она уж очень плохого качества, стоит подумать о резервном канале связи, либо отказаться от использования облака и думать о каком-то локальном решении.
Но тогда это решение уже не будет централизованным, да и в чем смысл локального решения? Локально вы и так видите, что с устройством происходит. Пожалуй, такое «локальное» решение подойдет только для каких-то очень крупных объектов (торговый центр без подключения к Интернету?..), в этом случае можете сделать его на IoT Edge, сделать что-то свое, или взять готовый продукт (например, www.quarta-embedded.ru/products/monitoring-management) и интегрировать в него свои процедуры мониторинга.
Если вопрос в том, что делать при временном пропадании сети, то можно добавить в решение IoT Edge, который прозрачно все закэширует и при появлении сети отправит данные в облако. Это вообще достаточно мощный продукт, который очень много может помимо собственно кэширования данных.
Если вопрос в том, что делать, если сети вообще нет, или она уж очень плохого качества, стоит подумать о резервном канале связи, либо отказаться от использования облака и думать о каком-то локальном решении.
Но тогда это решение уже не будет централизованным, да и в чем смысл локального решения? Локально вы и так видите, что с устройством происходит. Пожалуй, такое «локальное» решение подойдет только для каких-то очень крупных объектов (торговый центр без подключения к Интернету?..), в этом случае можете сделать его на IoT Edge, сделать что-то свое, или взять готовый продукт (например, www.quarta-embedded.ru/products/monitoring-management) и интегрировать в него свои процедуры мониторинга.
вопрос был к тому что вы подключаетесь к Azure который расположен за пределами страны, и выходит так что у вас нет возможности построить резервный собственный сервак при сохранении функционала на случай если завтра вашему провайдеру запретят выходить на внешку.
я сам участвую в терминальном бизнесе, как разработчик. Написал собственное приложение для платежных терминалов под .net core чтоб можно было спокойно запускать под линукс, и хотел подключить к азуру для мониторинга точек возможно и в качестве платежного сервиса, но мне нечего говорить потенциальному заказчику по поводу обеспечения связи в случаи если внешка пропадет, приходится писать собственный сервис.
все надеюсь что кто-то скажется что функционал Азура можно купить на собственный сервак без привязки самому Азуру.
я сам участвую в терминальном бизнесе, как разработчик. Написал собственное приложение для платежных терминалов под .net core чтоб можно было спокойно запускать под линукс, и хотел подключить к азуру для мониторинга точек возможно и в качестве платежного сервиса, но мне нечего говорить потенциальному заказчику по поводу обеспечения связи в случаи если внешка пропадет, приходится писать собственный сервис.
все надеюсь что кто-то скажется что функционал Азура можно купить на собственный сервак без привязки самому Азуру.
Часть базового функционала доступна в Windows Azure Pack.
Насчет «локального Azure» — есть такое понятие как Azure Stack, его продает МТС, например. Но функционально он очень сильно не дотягивает до «большого» Azure, поэтому смысла в его использовании для задач IoT нет. Разумеется, никто не мешает создать локальное решение, но это деньги и время.
Вообще, «локальное использование» противоречит самой концепции Azure, как сервиса, доступного в любой точке мира. А если ваш клиент в Беларуси или Украине, то ситуация становится ровно обратная — изоляция отключит их от вашего русского сервера. Если «отключат Интернет» — то да, в РФ работать перестанет. Но тогда перестанет много чего работать. Мне кажется, такие разговоры уже прекратились.
Вообще, «локальное использование» противоречит самой концепции Azure, как сервиса, доступного в любой точке мира. А если ваш клиент в Беларуси или Украине, то ситуация становится ровно обратная — изоляция отключит их от вашего русского сервера. Если «отключат Интернет» — то да, в РФ работать перестанет. Но тогда перестанет много чего работать. Мне кажется, такие разговоры уже прекратились.
Подскажите а собиралась ли какая-то экномическая информация (о заказах, внесенной наличности и т.д.). И позволяет ли решение от макрософт хранить такую информацию «вечно», а не 30 дней как телеметрию?
Экономическая информация не собиралась, т.к. этого в пилотном проекте не требовалось, но реализовать это можно, технических ограничений в этом плане нет.
Что касается срока хранения данных: поскольку это SaaS, то мы так или иначе ограничены его возможностями, но ничто не мешает сделать экспорт данных (поддерживаются разные варианты) и хранить их, сколько нужно. Собственно, для этого экспорт и нужен.
Что касается срока хранения данных: поскольку это SaaS, то мы так или иначе ограничены его возможностями, но ничто не мешает сделать экспорт данных (поддерживаются разные варианты) и хранить их, сколько нужно. Собственно, для этого экспорт и нужен.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Опыт создания облачного решения по мониторингу цифрового киоска на Azure IoT Central