Здравствуйте, уважаемые любители Интернета Вещей!
Эта статья отличается от моих предыдущих. Здесь не про решения и кейсы. Я написал про девять проблем IoT, которые портят нам жизнь.
Предлагаю присоединиться к моим размышлениям и вместе спрогнозировать будущее Интернета Вещей.
Прогресс идет семимильными шагами. За скорость мы платим высокую цену, особенно за ошибки.
К примеру, программисты пишут код. На основе этого кода создается библиотека или прошивка, которые адаптируются под разные задачи. Один и тот же код каждый раз используется в разных проектах. В результате остаются «хвосты» — остатки кода, которые кочуют из девайса в девайс.
Терпимо, если это рабочие «хвосты». И совсем плохо, если там дыра в безопасности.
Пример: запуск с космодрома «Восточный» ракеты-носителя Союз-2.1б. Тогда разгонный блок «Фрегат» повел себя нештатно. В его программе 20-ти лет давности все запуски были привязаны к «Байконуру». Пуска с «Восточного» он не ожидал. Вот и случился казус.
Смею предположить, что эти самые «хвосты 20-ти лет давности» будут все больше портить жизнь. Потому что попадают в новые программы. И это проблема.
Отсутствие квалификации — распространенная вещь. Но с появлением Интернета она стала проблемой. Инженер перестал думать головой, он ищет готовое решение в Google. В результате получаем поверхностный подход и ошибки.
Пример: некоторые «строители» LoRa-сетей начитались буклетов и ожидают дальности на десятки километров от базовой станции с дохлой антенной, которую поставили в квартире у Кулибина.
Это хорошо, если просто не заработало. А если отказало, когда уже начали эксплуатировать?
Маркетинг любит вмешиваться туда, куда не просят. С одной стороны, это понятно. Продукт нужно продавать. С другой стороны, границы надо держать. Маркетингу нечего делать в технической документации. Иначе она превращается в рекламный буклет (читай — бесполезную вещь).
У нас в Центре промышленного Интернета есть правило: не использовать то, что не проверено на характеристики.
Через нас прошли горы ширпотреба, иногда даже с шильдиками серьезных фирм, которые даже отдаленно не показывают паспортные характеристики.
Пример: формулировка «до» в описаниях LoRa. Например: «наше оборудование развивает скорость до 50 килобит/сек и работает до 15 километров». Разумеется, никто не упоминает, что это разные «до» и одновременно они не работают. Либо скорость, либо дальность.
Я подробно писал про это тут — Проприетарность. Здесь буду краток.
Многие мечтают создать востребованный продукт, который смогут продавать только они. Так рождаются проприетарные, ни с чем не совместимые стандарты и девайсы.
Даже если разработка ведется грамотными специалистами и продукт не украшается мишурой. Все равно при работе узкой командой можно что-то упустить.
Открытые стандарты, как правило, собирают вокруг себя сообщество энтузиастов. Они под микроскопом изучают все достоинства и недостатки, ищут дыры и баги. Результатом становится понимание проблем проекта и их решение.
В случае проприетарности технология варится в ограниченном круге лиц. И они обязательно что-нибудь упустят.
Пример: стандарт NB-Fi, который не защищен от атак повторения.
Эта проблема особенно остро ощущается в радиосвязи.
Большая часть наших IoT-устройств скована ограничениями не технического, а административного характера. Мы не можем превышать допустимый уровень излучения, не можем использовать некоторые частоты без лицензии.
IoT-устройства дополнительно страдают от туманной нормативной базы. Не каждый провайдер готов вкладывать деньги в IoT-сеть, которая требует партнерства с оператором мобильной четверки (NB-IoT решения) либо имеет неясный правовой статус.
Пример 1: отзыв частот у Yota в Казани в 2010 году, когда уже был построен пилот 4g-сети.
Пример 2: проект решения ГКРЧ использовать базовые станции LPWAN только российского производства. Таким образом вне закона могут оказаться уже построенные сети либо сети в процессе стройки. Ведь под них уже закуплено оборудование.
В противовес инженерам-копипастерам у нас растет сообщество людей, которые любят что-нибудь ломать. Часть из них делает это корыстно. Например, взломал систему платежей — украл деньги. Другие просто любят искать уязвимости.
Участились случаи атак без конкретной цели. Страшно, что квалификация таких ребят выше средней. А потому законы Мерфи сейчас вдвойне актуальны.
Пример: вирус Mirai, заразивший десятки тысяч устройств. Методом перебора логин-пароля он получал доступ к девайсам на дефолтных или околодефолтных настройках. Далее зараженные устройства использовались для DDoS-атак.
Безопасность требует дополнительных ресурсов и сказывается на цене. Но вариантов нет.
Проблема масштабируемости — самая серьезная, на мой взгляд, для современного IoT.
Рождается технология, которая быстро обретает популярность. У технологии есть ограничения, которые сдерживают ее развитие. Но в силу простоты, функциональности или еще каких причин, на ней начинают делать все подряд.
Так мы очень быстро упираемся в рамки, покинуть которые крайне сложно.
Пример: повальное распространение роутеров Wi-Fi 2,4 ГГц. Да, «вафля» проста в обращении, надежна и рассчитана на одновременную работу нескольких независимых устройств. Но когда в панельке врубают разом 60 роутеров, мы упираемся в емкость эфира.
Вечером скорость у абонентов падает, потому что частоты не резиновые. Решение тут — радикальный уход в 5 ГГц с большим запасом по емкости и меньшей длиной волны.
Эта проблема похожа на предыдущую, но у нее другие причины.
Зачастую новые технологии вынуждены работать со старыми стандартами или устройствами. В результате техническое задание инженеров содержит странные условия. Которые тем не менее нужно соблюдать.
Пример: ширина полосы стандарта цифрового телевидения DVB-T2 в России. Она составляет 8 МГц. Почему не 5 или 10? Очень просто. 8 МГц — это ширина полосы аналогового канала стандарта SECAM, на котором мы сидели предыдущие полвека.
Такое решение использовали, чтобы обеспечить совместное вещание аналога и цифры без нарушения логики OIRT. Однако в этом году аналог отключат, а 8 МГц останутся.
Одна из главных, на мой взгляд, проблем IoT.
Прогресс требует быстрых решений. Надежность проверяется временем. Сегодня лидирует прогресс, и в продуктив выходят сырые технологии. Часть из них не выдерживает проверку временем: они ломаются, плохо переносят масштабирование или оказываются просто бесполезными.
Рынок голосует деньгами. И нередки случаи, когда распиаренная технология никому не нужна, потому что неудобно, ненадежно или бесполезно. Последним особенно грешат стартапы, которые разрабатывают сложные, интересные и никому не нужные решения.
Пример: мы регулярно натыкаемся на заброшенные проекты по диспетчеризации.
Один из показательных случаев — опрос счетчиков по GSM. Развернули пилотную зону в нескольких подвалах — все заработало. Транслировали решение на сто подвалов — получили проблемы.
Сначала оказалось, что связь устойчива не везде. Потом обнаружили, что батареи хватает максимум на год, средний же срок — 6 месяцев. Обслуживание в проект не заложили. В результате просто бросили сто ящиков с пульсарами, батареями и антеннами. Оказалось, проще снимать показания по старинке, нежели поддерживать такую сеть.
На мой взгляд, именно эти девять проблем сдерживают развитие IoT и портят нам жизнь.
На мой взгляд, нельзя валить в кучу технологии с отличным профилем. Например, у Z-Wave и LoRaWAN изначально разные задачи, а потому сравнивать их некорректно.
Попытка протащить через LoRaWAN RS-485 в прозрачном режиме или построить дальнобойные решения на Z-Wave — это пример использования инструментов не по назначению. Вы же не обвиняете плоскогубцы, что ими неудобно закручивать шурупы. Хотя это и возможно, но неудобно и крайне странно.
Буду признателен за обратную связь в комментариях. С чем согласны, с чем — нет. Возможно, я что-то упустил в своем обзоре.
Архив предыдущих статей:
#1. Введение → #2. Покрытие → #3. Зоопарк приборов учета → #4. Проприетарность → #5. Активация и безопасность в LoraWAN → #6. LoRaWAN и RS-485→ #7. Девайсы и перекупы→ #8. Немного про частоты → #9. Кейс: делаем сеть LoRa для ТРК в Челябинске→ #10. Как за один день создать сеть LoRa в городе без сети?→ #11. Записки IoT-провайдера: да будет свет, или история первого государственного заказа по LoRa
Эта статья отличается от моих предыдущих. Здесь не про решения и кейсы. Я написал про девять проблем IoT, которые портят нам жизнь.
Предлагаю присоединиться к моим размышлениям и вместе спрогнозировать будущее Интернета Вещей.
Старые хвосты
Прогресс идет семимильными шагами. За скорость мы платим высокую цену, особенно за ошибки.
К примеру, программисты пишут код. На основе этого кода создается библиотека или прошивка, которые адаптируются под разные задачи. Один и тот же код каждый раз используется в разных проектах. В результате остаются «хвосты» — остатки кода, которые кочуют из девайса в девайс.
Терпимо, если это рабочие «хвосты». И совсем плохо, если там дыра в безопасности.
Пример: запуск с космодрома «Восточный» ракеты-носителя Союз-2.1б. Тогда разгонный блок «Фрегат» повел себя нештатно. В его программе 20-ти лет давности все запуски были привязаны к «Байконуру». Пуска с «Восточного» он не ожидал. Вот и случился казус.
Смею предположить, что эти самые «хвосты 20-ти лет давности» будут все больше портить жизнь. Потому что попадают в новые программы. И это проблема.
Копипаст
Отсутствие квалификации — распространенная вещь. Но с появлением Интернета она стала проблемой. Инженер перестал думать головой, он ищет готовое решение в Google. В результате получаем поверхностный подход и ошибки.
Пример: некоторые «строители» LoRa-сетей начитались буклетов и ожидают дальности на десятки километров от базовой станции с дохлой антенной, которую поставили в квартире у Кулибина.
Это хорошо, если просто не заработало. А если отказало, когда уже начали эксплуатировать?
Агрессивный маркетинг
Маркетинг любит вмешиваться туда, куда не просят. С одной стороны, это понятно. Продукт нужно продавать. С другой стороны, границы надо держать. Маркетингу нечего делать в технической документации. Иначе она превращается в рекламный буклет (читай — бесполезную вещь).
У нас в Центре промышленного Интернета есть правило: не использовать то, что не проверено на характеристики.
Через нас прошли горы ширпотреба, иногда даже с шильдиками серьезных фирм, которые даже отдаленно не показывают паспортные характеристики.
Пример: формулировка «до» в описаниях LoRa. Например: «наше оборудование развивает скорость до 50 килобит/сек и работает до 15 километров». Разумеется, никто не упоминает, что это разные «до» и одновременно они не работают. Либо скорость, либо дальность.
Проприетарность
Я подробно писал про это тут — Проприетарность. Здесь буду краток.
Многие мечтают создать востребованный продукт, который смогут продавать только они. Так рождаются проприетарные, ни с чем не совместимые стандарты и девайсы.
Даже если разработка ведется грамотными специалистами и продукт не украшается мишурой. Все равно при работе узкой командой можно что-то упустить.
Открытые стандарты, как правило, собирают вокруг себя сообщество энтузиастов. Они под микроскопом изучают все достоинства и недостатки, ищут дыры и баги. Результатом становится понимание проблем проекта и их решение.
В случае проприетарности технология варится в ограниченном круге лиц. И они обязательно что-нибудь упустят.
Пример: стандарт NB-Fi, который не защищен от атак повторения.
Административные барьеры
Эта проблема особенно остро ощущается в радиосвязи.
Большая часть наших IoT-устройств скована ограничениями не технического, а административного характера. Мы не можем превышать допустимый уровень излучения, не можем использовать некоторые частоты без лицензии.
IoT-устройства дополнительно страдают от туманной нормативной базы. Не каждый провайдер готов вкладывать деньги в IoT-сеть, которая требует партнерства с оператором мобильной четверки (NB-IoT решения) либо имеет неясный правовой статус.
Пример 1: отзыв частот у Yota в Казани в 2010 году, когда уже был построен пилот 4g-сети.
Пример 2: проект решения ГКРЧ использовать базовые станции LPWAN только российского производства. Таким образом вне закона могут оказаться уже построенные сети либо сети в процессе стройки. Ведь под них уже закуплено оборудование.
Квалифицированные злодеи
В противовес инженерам-копипастерам у нас растет сообщество людей, которые любят что-нибудь ломать. Часть из них делает это корыстно. Например, взломал систему платежей — украл деньги. Другие просто любят искать уязвимости.
Участились случаи атак без конкретной цели. Страшно, что квалификация таких ребят выше средней. А потому законы Мерфи сейчас вдвойне актуальны.
Пример: вирус Mirai, заразивший десятки тысяч устройств. Методом перебора логин-пароля он получал доступ к девайсам на дефолтных или околодефолтных настройках. Далее зараженные устройства использовались для DDoS-атак.
Безопасность требует дополнительных ресурсов и сказывается на цене. Но вариантов нет.
Технологический тупик
Проблема масштабируемости — самая серьезная, на мой взгляд, для современного IoT.
Рождается технология, которая быстро обретает популярность. У технологии есть ограничения, которые сдерживают ее развитие. Но в силу простоты, функциональности или еще каких причин, на ней начинают делать все подряд.
Так мы очень быстро упираемся в рамки, покинуть которые крайне сложно.
Пример: повальное распространение роутеров Wi-Fi 2,4 ГГц. Да, «вафля» проста в обращении, надежна и рассчитана на одновременную работу нескольких независимых устройств. Но когда в панельке врубают разом 60 роутеров, мы упираемся в емкость эфира.
Вечером скорость у абонентов падает, потому что частоты не резиновые. Решение тут — радикальный уход в 5 ГГц с большим запасом по емкости и меньшей длиной волны.
Обратная совместимость
Эта проблема похожа на предыдущую, но у нее другие причины.
Зачастую новые технологии вынуждены работать со старыми стандартами или устройствами. В результате техническое задание инженеров содержит странные условия. Которые тем не менее нужно соблюдать.
Пример: ширина полосы стандарта цифрового телевидения DVB-T2 в России. Она составляет 8 МГц. Почему не 5 или 10? Очень просто. 8 МГц — это ширина полосы аналогового канала стандарта SECAM, на котором мы сидели предыдущие полвека.
Такое решение использовали, чтобы обеспечить совместное вещание аналога и цифры без нарушения логики OIRT. Однако в этом году аналог отключат, а 8 МГц останутся.
Завышенные ожидания
Одна из главных, на мой взгляд, проблем IoT.
Прогресс требует быстрых решений. Надежность проверяется временем. Сегодня лидирует прогресс, и в продуктив выходят сырые технологии. Часть из них не выдерживает проверку временем: они ломаются, плохо переносят масштабирование или оказываются просто бесполезными.
Рынок голосует деньгами. И нередки случаи, когда распиаренная технология никому не нужна, потому что неудобно, ненадежно или бесполезно. Последним особенно грешат стартапы, которые разрабатывают сложные, интересные и никому не нужные решения.
Пример: мы регулярно натыкаемся на заброшенные проекты по диспетчеризации.
Один из показательных случаев — опрос счетчиков по GSM. Развернули пилотную зону в нескольких подвалах — все заработало. Транслировали решение на сто подвалов — получили проблемы.
Сначала оказалось, что связь устойчива не везде. Потом обнаружили, что батареи хватает максимум на год, средний же срок — 6 месяцев. Обслуживание в проект не заложили. В результате просто бросили сто ящиков с пульсарами, батареями и антеннами. Оказалось, проще снимать показания по старинке, нежели поддерживать такую сеть.
На мой взгляд, именно эти девять проблем сдерживают развитие IoT и портят нам жизнь.
Почему я не считаю битву стандартов — проблемой?
На мой взгляд, нельзя валить в кучу технологии с отличным профилем. Например, у Z-Wave и LoRaWAN изначально разные задачи, а потому сравнивать их некорректно.
Попытка протащить через LoRaWAN RS-485 в прозрачном режиме или построить дальнобойные решения на Z-Wave — это пример использования инструментов не по назначению. Вы же не обвиняете плоскогубцы, что ими неудобно закручивать шурупы. Хотя это и возможно, но неудобно и крайне странно.
Буду признателен за обратную связь в комментариях. С чем согласны, с чем — нет. Возможно, я что-то упустил в своем обзоре.
Архив предыдущих статей:
#1. Введение → #2. Покрытие → #3. Зоопарк приборов учета → #4. Проприетарность → #5. Активация и безопасность в LoraWAN → #6. LoRaWAN и RS-485→ #7. Девайсы и перекупы→ #8. Немного про частоты → #9. Кейс: делаем сеть LoRa для ТРК в Челябинске→ #10. Как за один день создать сеть LoRa в городе без сети?→ #11. Записки IoT-провайдера: да будет свет, или история первого государственного заказа по LoRa
