• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Wearable-> Internet. Правильная архитектура?

pvvx

Активный участник сообщества
вы форум не перепутали?
За пять лет существования форума только Вы рассказывали о промышленных решениях.
Это форум не для рассказов о том, как сделать боевой комплекс АВАНГАРД, а о том как на халяву мигать лампочками. Ну и кому нужна сертификация.
-------------
Относительно рассказа , что даже "не подготовленный" вы меня удивили.
с каких это пор Вы стали сторонником скриптовых языков и виртуальных машин?
А именно это и позволило Вам сделать "не имея никакого опыта работы с данным модемом на решение необходимой задачи в минимальные сроки "
--------------------------------
Как говорится - не плюй в корытце, пригодится воды напиться.
Дети изготавливают поделки с использованием пластилина и не одну, в день... Обычно после сборки поделка разбирается... Это аналогично использованию ESP. Осуждать их в практичности не имеет смысла, т.к. это процесс обучения и не имеет других целей.

Из имеющихся на рынке решений, поставленных в головном запросе, есть всего одно: “Умные часы” (смарт-часы). ESP там не наблюдается. SDK/DDK к таким часам есть, но они “проприетарные” и “для дома для семьи” не годятся, т.к. @nikolz не создал и ничем не приблизил создание открытой бесплатной среды разработки на них.

Карта устройства описанного в заголовке требует необходимость решения таких тех. задач:

1) Организация связи с внешним миром путем использования стандартных протоколов.

2) Накопление и обработка данных.

3) Время разработки и внедрения.

4) Малое потребление.

В зависимости от типа связи (п.п1) и требований надежности получения данных в общей системе, пп2 распределяется на само устройство и внешние сервисы. Доля накопления поступающих/обрабатываемых и прочих диагностических данных на самом устройстве не может быть нулевым и полностью вынесенным за пределы самого устройства. В итоге, чем больше требуемая надежность системы, тем большая часть данных и диагностики должна буферизироваться на самом устройстве, что требует у малых модулей SoC дополнительных ресурсов RAM и/или применения раздельных накопителей (с большой Flash и т.д).

Организация ESP и многих малых SoC не позволяет использовать для буферизации их Flash, т.к. в таких случаях сильно падает производительность и увеличивается потребление, что сказывается на общее время реакции устройства на все события, вызывая большой лаг для реал-тайм системы. Т.е. такая система уже не может обеспечивать нормальный реал-тайм режим. У первых RTL программа и данные, как и у многих малых Linux систем, работает из RAM, а Flash задействуется исключительно в случаях обращения к файловой системе или организованного в ней FIFO для данных, что запросто распределяется на малые атомарные задачи, исключая системные лаги возникающие при записи/стирании страниц Flash и опустошений программного кеша.

К примеру, реакция корректированной Embedded Linux (специально оптимизированной OpenWRT), на одноядерном MIPS с 300 MHz, дает джиттеры на внутренние пересылки между задачами или на внешние (IP) запросы до 5 мс, а в среднем менее 1 мс. Аппаратные прерывания обрабатываются в микросекунды… При наличии встроенного в такой SoC WiFi устройства без своего MCU о реал-тайм можно забыть, не увеличивая кол-во ядер и их частоты, что ведет к дикому потреблению, лишнему нагреву и удорожанию.

Применение MMC/SD карт усложняет и удорожает устройство более чем в два раза на систему “бесперебойного” экстренного питания на завершение операции с ними, разъемы и температурные диапазоны работы, малое ко-во гарантированных перезаписей... Т.е. нет смысла говорить о какой-либо надежности сохранности данных на них – но возможно использование в пластилиновых поделках (с) @nikolz :)

Изученных и проверенных факторов ещё много, а создавать их полное описание я пока не намерен. По тому в краце:

На сегодня уже куча дешевых китайских SoC со встроенной RAM более 32 Мб, способных удовлетворительно работать с Embedded Linux, обеспечивая приемлемую реал-тайм систему и небольшое потребление. Так-же куча модулей с раздельными шинами к раздельным типам памяти, которые при ненавязчивой оптимизации позволяют получать требуемый уровень реал-тайм всей системы. И становиться совершенно безразлично, какой встроенный или доп. модуль обеспечивает связь устройства с внешним миром, т.к. ресурсы позволяют незаморачиваясь использовать на них Linux подобные системы, а не ковыряться с пластилином.
 

pvvx

Активный участник сообщества
я лишь привел информацию как сделать то, что реально может работать в мед аппаратуре и тоже с сертификацией если надо.
Эти решения не обеспечивают современных требований.
Не путайте архитектуру аппаратного драйвера связи с датчиком с "архитектурой устройства".
Времена получения данных 1 бит в час прошли. Магазины завалены готовыми простейшими беспроводными датчиками и их воссоздание на ESP или контроллерах Ti "для дома для семьи" не требуется. У вас гигантомания - вы разрабатываете устройство с миллионными тиражами на форуме для игры в вечерний блог с ESP? :)
На 1 бит от датчика к передаче в систему требуются: время события, качество сигнала, статистика отказа, время наработки, ...
Выборка в 1 точку в пять минут от вашей ESP не несет никакой информации и не дает возможности анализа и прочей для системной диагностики.
При малой полосе канала большинство современных систем ведут усреднение потока от датчиков с выводом доп.информации типа максимума/минимума и других характеристик сигнала за период, чего не наблюдается в предложенной вами системе :p Используются и диагностические режимы, буферизации raw значений для последующей передачи...
 

nikolz

Well-known member
Дети изготавливают поделки с использованием пластилина и не одну, в день... Обычно после сборки поделка разбирается... Это аналогично использованию ESP. Осуждать их в практичности не имеет смысла, т.к. это процесс обучения и не имеет других целей.

Из имеющихся на рынке решений, поставленных в головном запросе, есть всего одно: “Умные часы” (смарт-часы). ESP там не наблюдается. SDK/DDK к таким часам есть, но они “проприетарные” и “для дома для семьи” не годятся, т.к. @nikolz не создал и ничем не приблизил создание открытой бесплатной среды разработки на них.

Карта устройства описанного в заголовке требует необходимость решения таких тех. задач:

1) Организация связи с внешним миром путем использования стандартных протоколов.

2) Накопление и обработка данных.

3) Время разработки и внедрения.

4) Малое потребление.

В зависимости от типа связи (п.п1) и требований надежности получения данных в общей системе, пп2 распределяется на само устройство и внешние сервисы. Доля накопления поступающих/обрабатываемых и прочих диагностических данных на самом устройстве не может быть нулевым и полностью вынесенным за пределы самого устройства. В итоге, чем больше требуемая надежность системы, тем большая часть данных и диагностики должна буферизироваться на самом устройстве, что требует у малых модулей SoC дополнительных ресурсов RAM и/или применения раздельных накопителей (с большой Flash и т.д).

Организация ESP и многих малых SoC не позволяет использовать для буферизации их Flash, т.к. в таких случаях сильно падает производительность и увеличивается потребление, что сказывается на общее время реакции устройства на все события, вызывая большой лаг для реал-тайм системы. Т.е. такая система уже не может обеспечивать нормальный реал-тайм режим. У первых RTL программа и данные, как и у многих малых Linux систем, работает из RAM, а Flash задействуется исключительно в случаях обращения к файловой системе или организованного в ней FIFO для данных, что запросто распределяется на малые атомарные задачи, исключая системные лаги возникающие при записи/стирании страниц Flash и опустошений программного кеша.

К примеру, реакция корректированной Embedded Linux (специально оптимизированной OpenWRT), на одноядерном MIPS с 300 MHz, дает джиттеры на внутренние пересылки между задачами или на внешние (IP) запросы до 5 мс, а в среднем менее 1 мс. Аппаратные прерывания обрабатываются в микросекунды… При наличии встроенного в такой SoC WiFi устройства без своего MCU о реал-тайм можно забыть, не увеличивая кол-во ядер и их частоты, что ведет к дикому потреблению, лишнему нагреву и удорожанию.

Применение MMC/SD карт усложняет и удорожает устройство более чем в два раза на систему “бесперебойного” экстренного питания на завершение операции с ними, разъемы и температурные диапазоны работы, малое ко-во гарантированных перезаписей... Т.е. нет смысла говорить о какой-либо надежности сохранности данных на них – но возможно использование в пластилиновых поделках (с) @nikolz :)

Изученных и проверенных факторов ещё много, а создавать их полное описание я пока не намерен. По тому в краце:

На сегодня уже куча дешевых китайских SoC со встроенной RAM более 32 Мб, способных удовлетворительно работать с Embedded Linux, обеспечивая приемлемую реал-тайм систему и небольшое потребление. Так-же куча модулей с раздельными шинами к раздельным типам памяти, которые при ненавязчивой оптимизации позволяют получать требуемый уровень реал-тайм всей системы. И становиться совершенно безразлично, какой встроенный или доп. модуль обеспечивает связь устройства с внешним миром, т.к. ресурсы позволяют незаморачиваясь использовать на них Linux подобные системы, а не ковыряться с пластилином.
Увы Вы не в теме рынка мед сенсоров. Признайте?
Я вам покажу лишь один пример
Системы непрерывного мониторинга уровня глюкозы (CGM)
В настоящее время есть три сертифицированные по международным стандартам системы
две из них построены на чипах Ti (CC2500, СС 2510, СС 2640) - в порядке создания модификаций.
А умные часы - это игрушки (об одном чипе для них с линуксом и андроидом с Гбайтами я вам говорил еще 5 лет назад , так как получал тогда их для экспериментов. Для медицины они не пошли.
Для фитнесов - применяется сейчас и китайские разработки и те что я указал выше.
--------------------------
Но спорить с Вами не буду, не интересно.
 

pvvx

Активный участник сообщества
Увы Вы не в теме рынка мед сенсоров. Признайте?
Нет, не в теме "рынка мед сенсоров", но в мед.теме и имеем необходимые разрешения и выпускаемую продукцию для медицины и прочие бумажки/плюшки на данную тему. На это давно уже было убито более года работы нескольких сотрудников, сопровождается далее и вложены некие средства, гораздо более цены сотен выданных вам для пиара микрух от Ti :)
Например без разницы - купить новые микрухи или получить из бесплатно, в качестве семплов. Лучше купить - это дает меньше проблем в дальнейшем :p
 

pvvx

Активный участник сообщества
Но спорить с Вами не буду, не интересно.
И между прочим, все эти установки, используемые в сотнях больниц РФ требуют систему оповещения местного персонала и другой диагностической информации для их обслуживания уже нами. Потому и готовлю сервис с применением уже NB-IoT, т.к. оно имеет большее проникновение, дальность и в будущем покрытие… А вот с WiFi/Lora/BT и подобным дело не очень, т.к. имеет местные проблемы связи и обслуживания, завязанные на частном учреждение и их “внутренних конфликтах”, где эксплуатируются наши установки, что дает низкую надежность и лишние затраты на сервисное обслуживание...
И какой спор может быть, если у вас нет многолетней практики работы с клиентами по данной тематике?
 

pvvx

Активный участник сообщества
В настоящее время есть три сертифицированные по международным стандартам системы
две из них построены на чипах Ti (CC2500, СС 2510, СС 2640) - в порядке создания модификаций.
Вас загрузить текущими проблемами в рос. пром.оборудовании?

Резервирование – кое-как осваивается, т.к. дело не очень сложное...

Автоматическая адаптация системы к поломкам и прочим факторам, как и автоматический анализ износа компонентов с выработкой решений (на местном оборудовании) для эксплуатационников – пока нулевая. Нет или не хватает накопленных данных, обратной информации, т.к. не сформированы системные сервисы, нет надежных каналов передачи данных с оборудования для сбора статистики разработчиком-производителем и т.д. Развитие в данной области для малого и среднего “бизнеса” только начинается. Специалистов по данному поводу вообще нет. Такие работы ведутся исключительно на западные корпорации и разрабатываются у поставщиков оборудования типа Siemens, т.к. другие в РФ-ии не развиты (мало платят взяток?). В итоге в уже имеющейся инфраструктуре это могут позволить и использовать одни монополисты…

Посмотрите на ваши “пиары” – они нацелены на посадку на иглу от Ti и никакого развития :p
Общество потребления ESP :)
 

pvvx

Активный участник сообщества
модуль ... - такое старье.
На счет ваших соображений про использование старых модемов – куда деваются снятые с производства 2G модемы?
upload_2019-3-10_12-36-7.png

Берем компрессор Atlas Copco. “В нагрузку” в нем установлен 2G GSM модем, даже если вы его не заказывали. Если хотите получить компрессор без него, то надо специально оповещать и договариваться при заказе (поставщик выдернет его :) ). Можно его выдернуть и самому – на работу он не влияет, местоположение его работы производитель не узнает и к вам не придет навязчивое сервисное обслуживание (только если вы сами запросите его). Стоит данный стукачок-модем нуль. Если он вам нужен, то по запросу при заказе ТО его заново бесплатно установят.
В комплект входит старый 2G модем с поддержкой LUA, сим карта Vodafone с оплаченным обслуживанием по всему миру, антенна и БП.
Сам модем уже давно снят с производства... Раритет. ПО,SDK к нему ныне не поддерживается.
upload_2019-3-10_12-40-37.png
>ati
Sierra Wireless
FXT009 Product
OK

В модеме стоит платка расширения Ethernet на дедушке ESN28J60.
upload_2019-3-10_12-38-55.png
При включении модем сразу стучит во все дыры UDP пакетами…
 
Сверху Снизу