И так уж вышло, что настало время сорвать покров тайны (та-дам) и рассказать, что мы делаем, почему и какие возможности для разработки проектов в сфере того самого Интернета вещей и промышленного интернета открывает наш стек-протокол.
Подобного рода рассказ было бы разумно начать с объяснения тому, что же стало толчком к началу нашей работы. Кратко эту причину можно сформулировать так: мы пришли к выводу, что современные мобильные сети имеют ряд недостатков (несовместимых с жизнью в будущем), преодоление которых невозможно без внедрения технологии с принципиально иной архитектурой, вариант которой мы придумали и решили воплотить в жизнь.
Кто виноват
На заре появления мобильных сетей некоторые их архитектурные особенности ещё не успели обернуться недостатками: концепция разбиения зоны покрытия на отдельные области выглядела элегантно и логично, в полном соответствии со стратегией «разделяй и властвуй». Но с момента своего возникновения рынок мобильных устройств непрерывно расширялся, ужесточались требования к качеству предоставляемых услуг, в сотни раз возросли скорости передачи данных и количество абонентов. Этот рост позволил выявить проблемы масштабируемости и гибкости ставшей уже классической архитектуры мобильных сетей. Перефразируя классику, 640 Кб не хватило.
1. Мобильные сети плохо масштабируются по числу сот. Каждая новая сота – это моделирование распространения радиоволн в интересующем районе, расчёт уровня шума, определение подходящих настроек для минимизации взаимных помех (как для новой станции, так и для окружающих, если они есть), дорогое оборудование, разрешения от надзорных служб, обеспечение резервных линий связи и питания, работа специалистов по монтажу, настройке и сопровождению … – в общем, время и деньги. И чем активнее используется в этом районе радиосвязь – тем больше затраты. В первую очередь это касается LPWAN сетей
2. Мобильные сети плохо масштабируются по числу абонентов. Каждый поддерживаемый базовой станцией аппарат резервирует либо частоту (FDMA), либо временной слот (TDMA), либо кодовую последовательность (CDMA). Все эти ресурсы ограничены, и когда абонентов становится слишком много, начинает страдать качество связи: для того, кому не хватило частоты, слота или кода, базовая станция словно перестаёт существовать, что во многих случаях оборачивается «выпадением» абонента из сети.
В то же время рост рынка Интернета вещей приводит к лавинообразному росту числа устройств, требующих доступ в сеть. Число гаджетов растет по экспоненте, а разработчики не утруждают себя работой над способами связи, полагаясь на уже существующие решения: большая часть умных гаджетов либо «живёт» в сети домашнего роутера, либо подключается к Интернет через сети мобильных операторов. И часто мы видим комичную ситуацию: устройства, находящиеся в одной комнате, общаются между собой через облачные сервисы. И даже если сейчас таких устройств сравнительно немного, то совсем скоро пропускной способности как каналов связи, так и станций обработки просто не хватит. Гудбай, красивая жизнь!
3. Современные сети совершенно не гибкие. Даже в повседневном режиме при изменении базовых условий необходимо провести перерасчет и перенастройку базовых станций, а в случае экстренных и чрезвычайных ситуаций «падение» одной из станций ведет к резкому наплыву устройств на соседние, что чаще всего приводит к падению всей сети, что чревато проблемами в случае стихийных бедствий или других чрезвычайных ситуаций.
Просто вспомните любой Новый Год, когда ни до кого невозможно дозвониться, а все абоненты временно не обслуживаются. И если наплыв во время Нового Года довольно быстро заканчивается и особых поводов переживать нет, то во время спасательных мероприятий наличие хоть какой-нибудь связи является жизненно важным фактором. А уж про то, что от поиска сети батарейка вашего любимого смартфона разряжается еще быстрее, можно и не говорить.
Что делать
Корнем всех бед является обычное для всех применение топологии «звезды» с довольно жесткой централизацией. Поэтому мы и решили заняться разработкой инфраструктуры для быстрого развертывания децентрализованной сети, которые называются Ad-Hoc или MESH. Идея состоит в исключении из сети «слабого» звена – базовой станции – для чего функции обеспечения связности перекладываются на абонентские устройства. В итоге каждое из них, помимо роли потребителя услуг связи также выполняет роль их поставщика для своих соседей. Сами устройства в таких сетях традиционно именуются нодами. В таких сетях при появлении новых нод или выхода из строя существующих сеть автоматически перестраивает маршруты, сохраняя работоспособность, что упрощает масштабирование и делает всю систему непривычно гибкой. Необходимость администрирования и настройки таких сетей сводится к минимуму и может выполняться удаленно. Именно поэтому поддержание беспроводных MESH-сетей не требует дорогостоящей инфраструктуры, прокладки кабелей, монтажа базовых станций и их регулярного администрирования, что делает эти сети весьма экономичными в эксплуатации.
Очевидно, что главной особенностью узла децентрализованной беспроводной сети являются алгоритмы, управляющие процессом маршрутизации, которые должны быть сложнее таковых в привычных маршрутизаторах. Но поскольку большинство абонентских устройств не обладают большими вычислительными ресурсами, применяемые алгоритмы маршрутизации должны быть не только высокоинтеллектуальными, но и не ресурсоёмкими. Этот спектр задач был принят нами как своего рода вызов.
Что сделано
Примерно год назад, выдвинув несколько гипотез о том, какие решения необходимо реализовать для построения централизованной беспроводной сети, мы проверили их на специально созданной имитационной модели. Поскольку разного вида MESH-сети пытались строить и до нас, важно было преодолеть ограничение, с которым их разработчики сталкивались раньше: затруднительно объединить в одной Ad-Hoc сети более сотни, а порой даже десятка абонентов. Однако результаты моделирования были обнадёживающими, и мы принялись за реализацию.
Первым нашим партнёром стала местная компания, занимающаяся системной интеграцией и решениями в области автоматизации управления. Нас пригласили участвовать в проекте по разработке системы умного уличного освещения, в которой наш стек протоколов занял бы подобающее место – обеспечение передачи данных. Партнерам же оставалось спроектировать аппаратную часть и создать приложения для управления фонарями, которые стали бы «клиентами» нашего стека. В результате обсуждения аппаратных требований было решено работать с микроконтроллерами NXP LPC1343 и радиопередатчиками Semtech SX1272 (RFM96), поддерживающими стандарт LoRa. На тот момент ресурсов выбранного микроконтроллера казалось достаточно, и впереди нас ждало очень много строк кода на чистом С.
В минимальной реализации стек представлен тремя уровнями, между которыми постоянно происходит обмен данными: интерфейсным уровнем, уровнем маршрутизации и сервисным уровнем. Уделять время и силы созданию собственных примитивов параллельной обработки нам не хотелось, поэтому было решено реализовывать стек под FreeRTOS (не без проблем, зато с неожиданными успехами). К тому же, это решение обеспечивало некоторую кроссплатформенность, что было бы полезно при дальнейшем развитии проекта.
Для полноценной проверки стека мы решили создать отдельную открытую платформу для разработки. В качестве основы мы выбрали Raspberry Pi, и сделали для неё бокс, облегчающий монтаж необходимой периферии: LCD-дисплея, GPS-модуля, платы-«шляпы» для радиомодулей и т.д… О том, как это было сделано, можно почитать в конце статьи.
Несмотря на экономное расходование ресурсов микроконтроллера, довольно скоро обнаружилось, что в 32 Кб FLASH стек не помещается, поэтому требования к аппаратной части были повышены. Сегодня минимальная версия стека требует следующих характеристик платформы:
MCU: Cortex M3
OS: FreeRTOS
FLASH: 128 Кб
EEPROM: 8 Кб
RAM: 32 Кб
Кроме того, для генерации псевдослучайных чисел стек использует встроенный в микроконтроллер АЦП, однако при необходимости его можно заменить любым подходящим генератором ПСЧ с соблюдением требуемой криптографической стойкости. Собственно говоря, этот стек и называется MOAR.
Чего ждать дальше
Следующая цель, которую мы перед собой поставили – это разработка GNU/Linux-версии стека MOAR, причём с поддержкой – насколько это будет возможно – стандартов POSIX. Полагаем, нет необходимости детально объяснять причины этого решения в мире, где абсолютное большинство сетевых устройств работает если не под управлением GNU/Linux, то с операционной системой, поддерживающей POSIX. Кроме того, в наших планах публикация исходных кодов стека под свободной лицензией.
Версия для GNU/Linux, в отличие от первой, включает в себя уже пять различных уровней: к имевшимся ранее добавились канальный уровень и уровень представления. Вместо очередей, использовавшихся в первой версии, для обмена данными между уровнями теперь используются стандартные сокеты Unix. Каждый из уровней может быть перезапущен отдельно от остальных, что уже гораздо полезнее.
Стек обладает API, который мы стараемся приблизить к привычному API сокетов. Как нам кажется, такой подход сильно облегчит «переезд» разработчикам, которые будут использовать стек как готовое решение. Кроме того, тонкая настройка стека возможна посредством конфигурационных файлов, с их применением «на лету» и передачей посредством самой сети – простейшая реализация этого функционала есть уже в первой версии стека, для GNU/Linux она будет развита и расширена.
Такая гибкость и модульность разрабатываемого стека была выбрана не только из эстетических соображений и удобства разработки. В дальнейшие планы входит реализация многих захватывающих дух возможностей как, например, адаптивный роутинг, использующий самообучающуюся нейросеть для предсказания состояний ближайших соседей и приоритетов маршрутов. Благодаря архитектурным особенностям нашего решения можно менять сценарии обработки данных без необходимости перезагружать стек целиком или заново обучать нейросеть. Другие запланированные возможности относятся к сфере информационной безопасности, и о них мы подробно расскажем позже.
23 декабря мы опубликуем исходные коды стека MOAR под свободной лицензией и с нетерпением будем ждать ваших вопросов, идей, замечаний и даже форков!
Комментарии (48)
KonstantinSpb
07.12.2016 15:57+1FreeRTOS довольно жирная РТОС, рассматривались ли другие РТОС?
ChibiOS, Contiki, RIOT
BelBES
08.12.2016 10:24А contiki все ещё живая? А то я её помню только по тому, что она накатывалась аж на Atrari portfolio )
tunelix
07.12.2016 16:33тема интересная но cтатья мало что раскрывает.
- зачем там GPS? ноды будут подвижные?
- чем ваш решение лучше других? почему вы написали свою систему маршрутизации, а не взяли существующие?
- почему нет солнечной панели? аккумулятор долго не проживет.
- почему lora, а не wifi? как в сеть с мобильного подключатся?
- вы не пробовали делать на ESP8266? можно сделать много очень дешовых нод и раскидать по территории.
Apuzakov
07.12.2016 16:561. Да, стек заточен под динамические системы.
2. В рамках Open Source DevKit будет возможность реализовывать собственные протоколы маршрутизации. Наше главное отличие это фокус на динамические сети, в которых маршрут постоянно перестраивается, поэтому мы минимизируем размеры таблицы маршрутизации.
3. Представленная нами нода была собрана под нужды тестирования и разработки. Добавить солнечную батарею можно, но пусть это сделают профессионалы.
4. При релизе мы заложим поддержку wi-fi + lora. Для связи нужно будет написать приложение на телефон.
5. Под ESP8266 есть рабочий проект который мы возили на SLUSH. Но там есть сложности в публикации под Open Source. Если интересно ESP на одной банке лития проработала больше 24 часов общаясь и моргая светодиодом. Если интересно могу больше деталей про ESP с фото представить после релиза.
Dark_Purple
07.12.2016 19:58+1Ну и чем ваша разработка лучше ZigBee например?
Apuzakov
07.12.2016 20:191. Наша разработка независима от конкретного физического (и не только физического) интерфейса. При наличии соответствующих интерфейсных уровней можем работать и через LoRa, и через WiFi, и через BLE, и через ещё что-нибудь.
2. ZigBee выделяет какую-то из нод в качестве маршрутизатора; нагрузка на эту ноду резко возрастает, поскольку ей необходимо полностью маршрутизировать всю сеть в зоне своей ответственности, из-за чего нода может слишком быстро разрядиться. После её отключения то же самое происходит с другой нодой. И так далее.
3. Ключи шифрования не хранятся на координаторе. Никакого координатора у нас вообще нет.
lumag
08.12.2016 01:22Координатор, чаще всего, является нодой с постоянным питанием и большими ресурсами. Проблема его разрядки, обычно, не возникает.
Apuzakov
08.12.2016 12:21Речь шла про питание маршрутизаторов. И если маршрутизатор — узел с постоянным питанием, то он перестаёт быть мобильным, а наше решение, как уже упоминалось, рассчитано на полностью динамические сети — то есть такие, где и маршрутизаторы вынуждены (непредсказуемо) менять своё положение.
DarkTiger
08.12.2016 13:20Я, собственно, вот про что. С прошествием некоторого периода времени батарейки на мобильных узлах-ретрансляторах садятся. Никто их не будет менять периодически (давайте смотреть на вещи трезво). Поэтому весь трафик — включая синхронизацию времени — пойдет через стационарные узлы, а не в обход их по кратчайшему пути. Отсюда забивание таймслотов.
Следующий этап радости — высаживание батареек мобильных узлов вблизи этих сетей, которые маршрутизируют трафик через эти узлы. Сеть не упадет, нет. Просто более удаленные узлы будут пытаться связаться с маршрутизатором напрямую, отчего резко поползет вверх количество битых пакетов и повторов, а это опять же занятые таймслоты.
Это опыт на сети из 40 устройств на MSP430 c батарейками 2032 и трансиверами сс2420. У нас, правда, была несколько другая задача — организовать трафик внутри большого здания
lumag
08.12.2016 01:21API в виде сокетов действительно удобнее. Когда мы писали 802.15.4, тоже пришли к сокетному API для приложений.
Кстати говоря, а почему вы выбрали WAN-решение?
borisxm
08.12.2016 12:08Как-то надо ввести дифференцированные названия для «Интернета вещей» в зависимости от сложности и фичесодержания. Например, у меня система датчиков, умных розеток, светильников и проч. живет в mesh-сети. При этом умещается в восьмибитные МК с размером флеша 8/16/32КБ. Есть конечные узлы, есть маршрутизирующие, присутствует шифрование и авторизация. Это сильно отличается от приведенного в статье, хотя и то и это можно считать IoTом.
Apuzakov
08.12.2016 14:29Насколько мы понимаем, наше решение несколько отличается от Вашего с идейной точки зрения:
1. Вероятно, используемая Вами система рассчитана на домашнее применение, а потому имеет некоторые ограничения, позволяющие её упростить (не нужно связывать ноды, скажем, на расстоянии 500 метров).
2. Мы принципиально отказались от разделения ролей узлов.
3. Мы поддерживаем любой нижележащий интерфейс (как физический, так и нет), и даже несколько разных одновременно. Разумеется, библиотека интерфейса должна отвечать некоторым требованиям, но это лишь один модуль нашего стека, а не весь стек.
4. Указанные нами требования включают в себя, помимо стека, саму ОС, и при этом ещё остаётся достаточно свободных ресурсов для пользовательского приложения или даже нескольких.
Так что Вы правы, и наше, и Ваше решения — IoT, но разного предназначения. Полагаю, история сама «раздаст» подходящие названия для соответствующих категорий.
DarkTiger
08.12.2016 13:24Может стоит попробовать Raspberry Pi Zero? Он, в принципе, доступен — 12$/шт у перекупщиков в Штатах + 40$ пересылка. На 5 штук получается по 20$ за штуку, я себе привез недавно. Zero сильно меньше кушают, например, пиковое потребление на загрузке — 0,18А. Ну и размеры, само собой — можно в тот же объем запихать еще пару 18650.
Apuzakov
08.12.2016 14:42Упомянутые устройства на основе Raspberry Pi — в первую очередь тестовые, и в них нам важнее было не оптимизировать цену или какие-то аналогичные факторы, а обеспечить удобство разработки и расширяемость. Кроме того, Raspberry Pi 2B уже были у нас под рукой, тогда как Zero пришлось бы заказывать и ждать.
gxcreator
08.12.2016 14:58Thread Group же есть и 6LowPAN
Apuzakov
08.12.2016 16:20Как уже было упомянуто (правда, иными словами), мы поставили перед собой задачу несколько более сложную и общую, чем условно-простое обеспечение mesh в рамках одного дома или одной квартиры. А Thread Guard, по их собственному указанию, предназначен исключительно для такого применения.
6LoWPAN также имеет несколько отличающуюся идею в своём основании: эти сети работают исключительно на одном типе интерфейса, тогда как мы стараемся не привязываться к конкретному типу физического интерфейса. В некотором смысле, мы хотим не «победить» другие решения, а подружить их между собой.gxcreator
08.12.2016 17:02Тогда гляньте в сторону IoTivity, у них довольно похожий с вашим подход, если я правильно понял.
lumag
09.12.2016 01:056lowpan работают поверх 802.15.4 и поверх BT. А главное, что это просто IPv6. Поэтому это универсальная прослойка между ,, странными'' сетками. Т.е. поверх других физических интерфейсов не обязательно прокидывать именно 6lowpan. Достаточно прокинуть просто IPv6.
leocat33
08.12.2016 17:22POSIX для Cortex M3 уже есть: NuttX
Занимаюсь подобными системами.
Начал «рисовать» сайт о своих продуктах ( opensource ): open-plc.com
Может быть есть смысл в сотрудничестве…
novoxudonoser
09.12.2016 00:57+2Либо я плохо прочитал статью, либо вы её не доконца проработали, либо у вас весьма туманное будущее.
1) Вы ориентируетесь на коммерческую направленность и хотите выступать технологическим провайдером для реализации технологии mesh, это неплохое решение для B2B engineering подрядов, жить в этом ключе вы сможете.
2) Вы зачем то «выпускаете» linux опенсорс версию на полноценной малине. Для реального применения в своих разработках людям опресненного решения нужен именно мк с вашей технологией, а не дорогая и энергозатратная малина. Вы что пытаетесь создать целый IoT «бассейн» на опенсорсном решении, а потом плавно продавать им свой коммерческий мк когда они вырастут из pet проектов в то, что может делать бизнес (или стартапить) и платить деньги? А у вас силёнок хватит? Этож получается практически EEE а таким может позволить себе заниматься (и успешно заниматься) некрософт скажем.
3) Вы правда хотите создать IoT «бассейн»? Эта статья выглядит одним из начальных шагов. У вас нет ресурсов. Я посетил ваш сайт (могли бы кстати не просто купить шаблон и залить туда текст, а хоть немного над ним поработать, вы на нём и свою команду разместили. Вы судя по всему либо студенты, либо вчерашние студенты. Вы стартап, откуда вам взять ресурсы на это дело? Вы должны противостоять огромному количеству больших компаний которые уже давно в этом направлении работают.
4) Вы говорите что все текущие решения для IoT не годятся. Долой их на свалку истории! «Покупайте» наше! Три ваших пункта в разделе <Кто виноват> абсолютно надуманы. Решения на мобильных сетях для IoT это очень маленький процент от всех кейсов.
5)Главный пункт вашей претензии к современным MESH решениям — что сложно подключить более 100 абонентов. Это не совсем так, для ZigBee вы частично правы, но в ZigBee и не требуется больше, ведь это домашняя и производственная автоматизация. Многие реализации 6lowpan позволяют иметь в сети более 1000 активных нод.
6) Вы делаете свою логическую MESH которая это «решает», а ресурсы то етсь? У вас что то заработало, но вы в начале пути.
Ещё мне не очень понятно на кого ориентированна статья. Для тех кто разбирается в вопросе в ней слишком много воды и прописных истин. Для тех кто не разбирается (а судя по статье она ориентированна на них) нет коммерческого интереса во все IoT теме.
В общем в любом случае я желаю вам творческих успехов. А я запасаюсь покорном и буду за вами приглядывать (конечно если вы будете притворствовать на хабре).Apuzakov
10.12.2016 13:47-1Добрый день
1. Зачем мы выпускаем версию для «полноценного» linux на «полноценной» малине? Достаточно универсальная платформа, много скучающих программистов, гиков.
Мы бы хотели, чтобы в iot появлялось что-нибудь умнее лампочек и камер, а для этого, как нам кажется, нужны программисты, которые обычно не работают непосредственно с устройствами.
2. Что если кто-то сделает на открытой версии хороший продукт? Так это же будет замечательно, let it be, как нам кажется.
3. Мы начали работать с того, что нам не понравились Zigbee и 2g/3g. Оказалось, что потребность в новых решениях значительно больше и не ограничивается заменой плохого ZigBee и дорогого 2g/3gnovoxudonoser
12.12.2016 00:07+11. Зачем мы выпускаем версию для «полноценного» linux на «полноценной» малине? Достаточно универсальная платформа, много скучающих программистов, гиков.
Мы бы хотели, чтобы в iot появлялось что-нибудь умнее лампочек и камер, а для этого, как нам кажется, нужны программисты, которые обычно не работают непосредственно с устройствами.
Это просто замечательное стремление. Но я ещё раз повторюсь |версия для «полноценного» linux на «полноценной» малине| подходит для pet проектов и то очень, очень ограничено. Если вы действительно хотите принести немного «доброты» в этот мир задаром, а не подсаживать всех на свою «платформу» — то открывайте проект на мк. Но вы не можете это сделать, т.к. потеряете основной продукт на котором вы зарабатываете, а зарабатывать деньги открывая продукт и работая интегратором и саппортом как большие компании вы тоже не можете, да и пока продукта готового у вас толком нет.
много скучающих программистов, гиков
Это я как понимаю ваша цель. Глупая цель, если это правда. Ну во первых скучающих программистов я ещё не видел, да и веселить их надо по другому. Вам не развлекать программистов надо, а делать коммерческий продукт и его продавать. Опенсорс не может быть прикрытием для этого. Только больные люди опенсорсят за так (да они есть и я их уважаю). В любом случае это либо работа в портфолио, либо открытасть ради развития и сборки багов и поддержки, либо как я и говорил делать открытый продукт и зарабатывать потом на наладке сопровождении. Моделей много, суть одна некая выгода. Не стоит маскироваться под чистые помыслы, а на самом деле пытаться сделать на этом площадку, рынок и влияние. В вашу безгрешность я не верю.
Да и зачем вам гики и программисты? Они привередливы и не платят. Вы не сделаете здесь денег, как минимум потому что вам не хватит ресурсов создать сообщество. Да и техническая проблема которую вы сейчас решаете очень узка, нужна не всем, и по большей части надуманна.
2Что если кто-то сделает на открытой версии хороший продукт? Так это же будет замечательно, let it be, как нам кажется.
Конечно именно поэтому, если это правда, я искренне желал вам удачи в прошлом коменте и желаю и сейчас.
3. Мы начали работать с того, что нам не понравились Zigbee и 2g/3g. Оказалось, что потребность в новых решениях значительно больше и не ограничивается заменой плохого ZigBee и дорогого 2g/3g
1) Эмм, как я понимаю вы ни чего другого не попробовали.
2) Вам Zigbee и 2g/3g не понравилось на вашей задаче.
3) Вы сделали вывод что все пути и технологии ошибочны
4) И теперь вы готовы сделать проект — техно мессия для IoT
5) и решить все проблемы
6) ???
7) Profit!
В общем и ещё раз, желаю вам успехов, грызите этот гранит. А я тем временем запасусь ещё ведёрком попкорна и буду ждать.
OFFREAL
12.12.2016 07:39-1Но вы не можете это сделать, т.к. потеряете основной продукт на котором вы зарабатываете, а зарабатывать деньги открывая продукт и работая интегратором и саппортом как большие компании вы тоже не можете, да и пока продукта готового у вас толком нет.
Демагогия.
а) Вы не располагаете достаточной информацией ни о продукте, ни о степени его готовности.
б) Мы разрабатываем инструмент, c его помощью можно создавать продукт для конечного потребителя.
в) Это b2b решение. Если вы желаете поговорить про b, прошу в ЛС — мы рады помочь в решении ваших сетевых проблем.
Не стоит маскироваться под чистые помыслы, а на самом деле пытаться сделать на этом площадку, рынок и влияние. В вашу безгрешность я не верю.
Потрудитесь объяснить причем тут безгрешность?
Да и техническая проблема которую вы сейчас решаете очень узка, нужна не всем, и по большей части надуманна.
Вы в самом деле не понимаете? Погуглите про ботнет Mirai, такая очень узкая проблемка. Еще десяток таких надуманных ботнетов и будем дружно хоронить Интернет.
Вам Zigbee и 2g/3g не понравилось на вашей задаче
Назовете сходу стандарт который:
а) Не привязан к интерфейсу (частоте, модуляции, среде передачи)
б) Является полным стеком представленным на всех уровнях и реализующий функционал OSI, либо заменяющий ее.
в) Имеет поддержку хотя-бы пары RTOS и Linux.novoxudonoser
12.12.2016 11:10+1Вы веткой ошиблись, ну да ладно.
Да и техническая проблема которую вы сейчас решаете очень узка, нужна не всем, и по большей части надуманна.
Вы в самом деле не понимаете? Погуглите про ботнет Mirai, такая очень узкая проблемка. Еще десяток таких надуманных ботнетов и будем дружно хоронить Интернет.
Бред. Недаром я говорил про надуманные проблемы. Ботнет Mirai составлен большей частью не из IoT устройств, их правда приписывают к IoT но они таковыми не являются. Более того из википедии:
«Ботнет Mirai стал возможным благодаря реализации уязвимости, которая заключалась в использовании одинакового, неизменного, установленного производителем пароля для доступа к учетной записи администратора на «умных» устройствах»
Никакой проблемой в существующих IoT это не вызвано. Это банальная глупость производителя. Вы всё таки решили поиграть в техномиссию надуманных проблем?
Вам Zigbee и 2g/3g не понравилось на вашей задаче
Назовете сходу стандарт который:
а) Не привязан к интерфейсу (частоте, модуляции, среде передачи)
б) Является полным стеком представленным на всех уровнях и реализующий функционал OSI, либо заменяющий ее.
в) Имеет поддержку хотя-бы пары RTOS и Linux.
Первый пункт потребовался лично вам на вашей задаче. И вы захотели странного и подумали какую крутую штуку вы изобрели. Сейчас это проблема согласоваения разных сетей решается и будет решаться за счёт бриджов прикладного уровня между сетями (есть ещё сетевые но там возможностей мало).
Отвечаю сразу на 3 пункта — IPv6, вы можете гнать его по любому интерфейсу, «тунелировать» в СAN, Zigbee и т.д… И самое главное у него есть отличная реализация в MESH — 6lowpan.
Но вы не можете это сделать, т.к. потеряете основной продукт на котором вы зарабатываете, а зарабатывать деньги открывая продукт и работая интегратором и саппортом как большие компании вы тоже не можете, да и пока продукта готового у вас толком нет.
Демагогия.
а) Вы не располагаете достаточной информацией ни о продукте, ни о степени его готовности.
б) Мы разрабатываем инструмент, c его помощью можно создавать продукт для конечного потребителя.
в) Это b2b решение. Если вы желаете поговорить про b, прошу в ЛС — мы рады помочь в решении ваших сетевых проблем.
а) Конечно не располагаю, я оперирую текущей скудной информацией из вашей статьи и сайта. И конечно я могу ошибаться в.ч. по причине не виденьем полный картины вашей деятельности. Но мне достаточно и этого. Знания вопроса и логика компенсируют недостающую информацию.
б) Если вы про ваше решение на малине. То инструмент плох. Он дорог, габаритен, энергозатратен, не может долго автономно работать, имеет полноценную ОС и вычислительные возможности, что оверхед для задач на это решение возложенных.
Ещё раз открывайте «платформу» на мк. Это будет достойный инструмент для конечного потребителя.
в)Это b2b решение
Вот вы и прокололись. Если это b2b решения зачем преподносить его под соусом опенсорса? Развивайте и продавайте ваш продукт, вы не на то силы тратите, выше в коментах я уже писал об этом.
OFFREAL
12.12.2016 20:22-1Никакой проблемой в существующих IoT это не вызвано.
Вы в корне неправильно понимаете суть проблемы в примере с Mirai. Подсказка — она не в уязвимости самих устройств (хотя, это тоже проблема, но совсем другая).
Если вы про ваше решение на малине
Нет. Это не является продуктом, это демонстрационный прототип о чем и было сказано в статье.
Отвечаю сразу на 3 пункта — IPv6, вы можете гнать его по любому интерфейсу, «тунелировать» в СAN, Zigbee и т.д… И самое главное у него есть отличная реализация в MESH — 6lowpan.
Спасибо. Предлагаю на этом закончить.novoxudonoser
12.12.2016 23:32+1Вы в корне неправильно понимаете суть проблемы в примере с Mirai. Подсказка — она не в уязвимости самих устройств (хотя, это тоже проблема, но совсем другая).
Так расскажите мне суть проблемы мессия. Как я понял вы намекаете на то что проблема в том, что любая камера (которая ещё раз подчёркиваю не является IoT) в Mirai может вещать куда угодно в интернет, ну и что??? Это не проблема IoT его тут нет, это не проблема MESH. И в статью ваше объяснение бы не плохо добавить (или в следующую она же будет да?), ото всё что там есть — что текущие решения не годятся. Впрочем я жду вашего «релиза» чтобы посмотреть как же у вас там революционно будет обеспечиваться «безопасность» и нейросеть тоже жду.
Нет. Это не является продуктом, это демонстрационный прототип о чем и было сказано в статье.
Ок, жду продукт.
Отвечаю сразу на 3 пункта — IPv6, вы можете гнать его по любому интерфейсу, «тунелировать» в СAN, Zigbee и т.д… И самое главное у него есть отличная реализация в MESH — 6lowpan.
Спасибо. Предлагаю на этом закончить.
Очень зря предлагаете, расскажите почему вы не согласны с моим ответом, что в нём неверного. Вы просили удовлетворить три ваших пункта я удовлетворил, уточните вопрос если он не полон, переформулируйте, или просто без вопроса скажите что пытались.
Я как ваш потенциальный клиент (без шуток) жду ответ. Впрочем как и другие потенциальные клиенты которые этот комент прочитают.
Watcover3396
С интернетом вещей, меш сетями дела не имел и мало что в этой области знаю, но.
Я не понимаю, зачем вы пилите софт под киты и т.д., если сейчас у всех есть как минимум один устаревший смартфон, с более мощным железом, USB, BT, WIFI, экраном и все это помещается в одной руке.
Может я ошибаюсь, но как по мне малинка и адуино прикольные как для обучения, помигать светодиодами, может что по сложнее.
Написать бы мелкую операционку на Линукс ядре, что бы просто взял какой нить смарт на андроиде, поставил на зарядку, залил прошивку и меш ячейка готова, а там может по желанию торрент качалку запустить.
P.S. Губу уже закатил)
Apuzakov
Версия под андройд (точнее кастомная сборка) в планах есть. Мы сейчас решили сделать первый шаг с Линукс ОС просто потому что Rasbery Pie откопать можно сравнительно быстро и не дорого
Watcover3396
Я просто представляю этот проект меш-сети в более масштабном варианте, в случае жестких ограничений в обычном инете.
Например, я живу в Горловке на Донбассе в условиях гражданской войны, что мне проще достать, устаревший смартфон 2010 года или какой-то Rasbery Pie который если и завезут то втридорога?
Плюсы смартфонов в качестве меш ячейки зашкаливают.
Будь возможность, я бы конечно сам собрал, это намного интересней)
Apuzakov
В данной реализации есть не большой плюс над телефоном. Радио чип LoRa в радиусе до 1 км отлично себя показывает. Но в ваших условиях мобильный телефон будет действительно лучше. Есть приложение Firechat, может оно будет полезно.
Ctacfs
На Донбассе эти сети поднимать просто некому. Логично стартовать, охватив как можно более широкую аудиторию. И раз уж на то пошло, старых компьютеров куда больше, чем старых ведрофонов, а сами компьютеры гораздо более гибкие.
Watcover3396
Да поднимать некому, наверное просто потому что нет необходимости, пока что.
Старых компьютеров больше, но зачастую их просто сдают на запчасти ибо практической пользы от них уже очень мало, а вот старые смартфоны откладывают в «долгий ящик» практически все, из простого принципа «авось основной сломается так старый возьму».
Если речь идет об обычных системниках, то у них 3 основных минуса, размеры, отсутствие встроенного Wifi и аккумулятора, ноутбуки конечно всех обыгрывают)
Watcover3396
Допустим существует эта легкая меш-операционка на линукс ядре и есть 10к добровольцев.
Например, один доброволец на одну многоэтажку, он берет свой смартфон и по инструкции заливает прошивку, затем в хорошо изолированной пластиковой бутылке закрепляет на крыше.
Питание для смартфона из зарядного можно подключить через заброшенный антенный коаксиальный кабель.
Исходя что в смартах слабые Wifi модули, вероятно лучше всего ставить их на крышу каждого дома, дома стоят относительно близко.
Вот и профит)
Ctacfs
Аккумулятор в таких условиях, конечно, действительно необходим. Об этом не подумал. Тут еще энергопотребление компьютеров к минусам можно отнести тогда. В случае обрыва ЛЭП или проблем с подстанциями, это ударит даже сильнее, чем отсутствие аккумулятора, потому что аккумулятор можно сколхозить.
Areso
Старые системники еще, кроме указанных минусов, обладают еще несколькими: в них нет блютуза, вафли, т.е. эти интерфейсы надо докупать (доп. траты), они шумные, и они потребляют прилично электричества (в десятки раз больше смартфона).