Уровень 3: Сетевой уровень (Network Layer)
Сетевой уровень предназначен для добавления информации к передаваемому пакету данных о получателе, т.е. вся информация, необходимая для маршрутизации сообщения, добавляется на третьем уровне модели OSI (Open Systems Interconnection). Информация сетевого уровня имеет значение только на одном сегменте сети и может быть заменена при прохождении следующего сетевого элемента. Хорошим примером задач уровня 3 может послужить адресная информация на конверте письма, которая должна быть проверена на каждом сетевом элементе (почтовом отделении) на пути его следования от отправителя к получателю. Кроме функции адресации сетевой уровень может выполнять функции сегментации данных на передающей стороне и сборки – на приемной. Также сетевой уровень отправляет отчеты об ошибках к передающей стороне в случае их обнаружения.
Модель OSI
Если говорить о компьютерных сетях передачи данных, то примерами устройств, работающих на этом уровне сигнализации являются IP — router и ATM — switch, которые соединяют небольшие сегменты в единую сеть и служат в качестве коммутационных устройств в этих сетях.
В сетях сотовой связи стандарта GSM косвенно функции сетевого уровня выполняет протокол RR (radio resource management – протокол управления радиоресурсами) для протоколов MM (mobility management – протокол управления мобильностью), CC (call control – протокол управления соединением).
При использовании материалов ссылка на сайт обязательна
—С автором сайта можно связаться по e-mail: ipleto@gmail.com
Обзор сетевых протоколов и протоколов обмена сообщениями для IoT
Интернет вещей (IoT, Internet of Things) будет построен на базе существующей сетевой инфраструктуры, технологий и протоколов, используемых в настоящее время в домах/офисах и в Интернете, и предложит много другого.
Цель данного руководства — дать краткий обзор сетевых и прикладных протоколов для IoT.
Примечание. У вас должны быть знания основ сетевых технологий.
IoT-сети
IoT будет работать в существующих TCP/IP-сетях.
TCP/IP использует четырехуровневую модель с определенными протоколами на каждом уровне. См. understanding the TCP/IP 4 layer model (разбираемся с четырехуровневой моделью TCP/IP).
На диаграмме ниже показано сравнение протоколов, используемых в настоящее время, и тех что, скорее всего, будут использоваться для IoT.
Примечания к диаграмме:
- Размер шрифта отображает степень популярности протокола. Например, слева IPv4 больше, так как он гораздо популярнее в современном Интернете. Однако справа он меньше, поскольку ожидается, что IPv6 будет более популярным в IoT.
- Показаны не все протоколы.
- Больше всего изменений на канальном (уровни 1 и 2) и прикладном уровнях (уровень 4).
- Сетевой и транспортный уровни, скорее всего, останутся неизменными.
Протоколы канального уровня
На канальном уровне (Data Link) вам нужно соединить устройства между собой. Они могут находиться как недалеко, например, в локальных сетях (local networks) так и на большом расстоянии друг от друга: в городских (metropolitan area networks) и глобальных сетях (wide area networks).
В настоящее время на этом уровне в домашних и офисных сетях (LAN) используются Ethernet и Wi-Fi, а в мобильных (WAN) — 3G / 4G. Однако многие IoT-устройства маломощные, например, датчики, и питаются только от батарей. В этих случаях Ethernet не подходит, но можно использовать low powered Wi-Fi и low powered Bluetooth.
Хотя для подключения этих устройств по-прежнему будут использоваться существующие беспроводные технологии (Wi-Fi, Bluetooth, 3G / 4G), стоит также обратить внимание на новые технологии, специально разработанные для IoT-приложений, популярность которых, по всей вероятности, будет расти.
- BLE – Bluetooth Low Energy
- LoRaWAN – Long Range WAN
- SigFox
- LTE-M
Более подробно они описаны в статье An overview of IOT wireless technologies (обзор беспроводных технологий IoT).
Сетевой уровень
На сетевом уровне (Networking) в долгосрочной перспективе будет доминировать протокол IPv6. Маловероятно, что будет использоваться IPv4, но он может играть определенную роль на начальных этапах. Большинство IoT-устройств для дома, например, умные лампочки, в настоящее время используют IPv4.
Транспортный уровень
На транспортном уровне (Transport) в Интернете и вебе доминирует TCP. Он используется как в HTTP, так и во многих других популярных протоколах Интернета (SMTP, POP3, IMAP4 и т. д.).
MQTT, который, как я ожидаю, станет одним из основных протоколов прикладного уровня для обмена сообщениями, в настоящее время использует TCP.
Однако в будущем из-за более низких накладных расходов, я ожидаю, что UDP будет более популярен для IoT. Вероятно, более широкое распространение получит MQTT-SN, работающий поверх UDP. См. статью о сравнении TCP vs UDP .
Прикладной уровень и протоколы обмена сообщениями
Важные характеристики для протоколов IoT:
- Скорость — количество передаваемых данных в секунду.
- Задержка — время, необходимое для передачи сообщения.
- Потребляемая мощность.
- Безопасность.
- Наличие программных средств.
В настоящее время на этом уровне активно используются два основных протокола: HTTP и MQTT.
HTTP, вероятно, самый известный протокол этого уровня, лежащий в основе веба (WWW). Он по прежнему будет иметь важное значение для IoT, поскольку используется для REST API — основного механизма взаимодействия веб-приложений и сервисов. Однако, из-за высоких накладных расходов, HTTP вряд ли станет основным протоколом IoT, хотя все равно будет широко использоваться в Интернете.
MQTT (Message Queuing Telemetry Transport) стал основным протоколом обмена сообщениями в IoT, благодаря своей легкости и простоте в использовании. См. статью Introduction to MQTT for beginners (Введение в MQTT для начинающих).
Сравнение HTTP и MQTT для IoT
MQTT быстро становится стандартом де-факто для IoT-приложений. Это происходит из-за его легкости и скорости по сравнению с HTTP и того, что он является протоколом «один ко многим», а не «один к одному» (HTTP).
Многие современные веб-приложения, с радостью использовали бы MQTT вместо HTTP, если бы он был доступен на момент их разработки.
Хороший пример — отправка информации множеству клиентов, например, о прибытии и отправлении поездов / автобусов / самолетов. В этом сценарии протокол «один-к-одному», такой как HTTP, имеет большие накладные расходы и создает большую нагрузку на веб-серверы. Масштабирование этих веб-серверов может быть затруднено. С MQTT клиенты подключаются к брокеру, которые легко можно добавлять для балансировки нагрузки. Смотрите об этом туториал с видео Republish HTML Data Over MQTT (Flight Arrivals Example) и статью MQTT vs HTTP for IOT.
Другие протоколы обмена сообщениями
HTTP не был разработан для IoT-приложений, но, как уже упоминалось, он будет широко использоваться в течение какого-то времени благодаря его широкому использованию в API.
Почти все платформы IoT поддерживают как HTTP, так и MQTT.
Однако есть и другие протоколы, которые стоит рассмотреть.
- MQTT — (Message Queuing Telemetry Transport). Использует TCP/IP. Для модели «издатель-подписчик» требуется брокер сообщений.
- AMQP — (Advanced Message Queuing Protocol). Использует TCP/IP. Модели «издатель-подписчик» и «точка-точка».
- COAP — (Constrained Application Protocol). Использует UDP. Разработан специально для IoT, использует модель запроса-ответа как в HTTP. RFC 7252.
- DDS — (Data Distribution Service)
В этой статье рассматриваются основные протоколы и их применения. Вывод этой статьи заключается в том, что IoT будет использовать набор протоколов, в зависимости от их предполагаемого применения.
Однако, если оглянуться назад, в первые годы существования Интернета протокол HTTP, впоследствии ставший доминирующим, был всего лишь одним из множества протоколов.
Несмотря на то что HTTP не был изначально задуман для передачи файлов и электронной почты, сегодня он используется и для того и для другого.
Я ожидаю, что в IoT с протоколами обмена сообщениями произойдет то же самое: большинство сервисов будут использовать один преобладающий протокол.
Ниже приведены графики Google Trends, показывающие, как изменялась популярность MQTT, COAP и AMQP за последние несколько лет.
Обзор Google Trends
Поддержка протоколов по платформам
- Microsoft Azure — MQTT, AMQP, HTTP и HTTPS
- AWS — MQTT, HTTPS, MQTT over websockets
- IBM Bluemix – MQTT,HTTPS,MQTT
- Thingworx — MQTT,HTTPS,MQTT,AMQP
Резюме
Больше всего изменений на канальном (уровни 1 и 2) и прикладном уровнях (уровень 4).
Сетевой и транспортный уровни, скорее всего, останутся неизменными.
На прикладном уровне компоненты IoT будут использовать протоколы обмена сообщениями. Хотя мы все еще находимся на раннем этапе развития IoT, вполне вероятно, что выделится один или, возможно, два протокола обмена сообщениями.
За последние несколько лет MQTT стал самым популярным, и именно на нем я сейчас фокусируюсь на этом сайте.
HTTP также по-прежнему будет использоваться, так как он уже хорошо встроен в существующие IoT-платформы.
На этом все. Приглашаем вас записаться на бесплатный демо урок по теме «Чат-бот для быстрых команд устройству».
Читать ещё:
Что такое Интернет вещей (Internet of Things, IoT)?
Что такое Интернет вещей (Internet of Things, IoT)?
Термин IoT, или Интернет вещей, относится к коллективной сети подключенных устройств и технологии, которая облегчает связь между устройствами и облаком, а также между самими устройствами. Благодаря появлению недорогих компьютерных микросхем и телекоммуникаций с высокой пропускной способностью у нас теперь есть миллиарды устройств, подключенных к Интернету. Это означает, что повседневные устройства, такие как зубные щетки, пылесосы, автомобили и механические установки, могут использовать датчики для сбора данных и разумного реагирования на действия пользователей.
Интернет вещей объединяет повседневные «вещи» с Интернетом. Компьютерные инженеры добавляют датчики и процессоры к повседневным предметам с 90-х годов. Однако поначалу прогресс был медленным, потому что микросхемы были большими и громоздкими. Компьютерные чипы малой мощности, называемые RFID-метками, впервые использовались для отслеживания дорогостоящего оборудования. По мере того как вычислительные устройства уменьшались в размерах, эти чипы также со временем становились меньше, быстрее и умнее.
Стоимость интеграции вычислительной мощности в небольшие объекты теперь значительно снизилась. Например, вы можете добавить возможность подключения голосовых сервисов Alexa к микроконтроллерам со встроенной оперативной памятью менее 1 МБ, например для выключателей света. Возникла целая индустрия, направленная на то, чтобы наполнить наши дома, предприятия и офисы устройствами IoT. Эти смарт-объекты могут автоматически передавать данные в Интернет и из Интернета. Все эти «невидимые вычислительные устройства» и связанные с ними технологии в совокупности называются Интернетом вещей.
Как работает IoT?
Типичная система IoT работает посредством сбора и обмена данными в режиме реального времени. Система IoT состоит из трех компонентов.
Смарт-устройства
Это устройство, такое как телевизор, камера видеонаблюдения или тренажер, которому были предоставлены вычислительные возможности. Такое устройство собирает данные из своей среды, пользовательского ввода или шаблонов использования и передает данные через Интернет в приложение IoT и из него.
Приложения IoT
Приложение IoT – это набор сервисов и ПО, которые объединяют данные, полученные от различных устройств IoT. Такое приложение использует технологию машинного обучения или искусственного интеллекта (ИИ) для анализа этих данных и принятия обоснованных решений. Эти решения передаются обратно на устройство IoT, а затем устройство IoT интеллектуально реагирует на входные данные.
Графический интерфейс пользователя
Устройством IoT или парком устройств можно управлять через графический интерфейс пользователя. Общие примеры включают мобильное приложение или веб-сайт, которые можно использовать для регистрации и управления смарт-устройствами.
Каковы примеры устройств IoT?
Примеры систем IoT, используемых сегодня, см. ниже.
«Умный» автомобиль
Транспортные средства, например автомобили, можно подключить к Интернету разными способами. Это может быть через интеллектуальные видеорегистраторы, информационно-развлекательные системы или даже подключенный шлюз автомобиля. Такие автомобили собирают данные с педали акселератора, тормозов, спидометра, одометра, колес и топливных баков, чтобы контролировать работу водителя и состояние автомобиля. «Умные» автомобили используются во многих областях.
- Мониторинг парков арендованных автомобилей для повышения эффективности использования топлива и снижения затрат.
- Помощь родителям в отслеживании поведения детей за рулем.
- Автоматическое уведомление друзей и родственников в случае автомобильной аварии.
- Прогнозирование и предотвращение потребности в техническом обслуживании автомобиля.
«Умный» дом
Устройства «умного» дома в основном ориентированы на повышение эффективности и безопасности дома, а также на улучшение домашних сетей. Такие устройства, как «умные» розетки, контролируют потребление электроэнергии, а интеллектуальные термостаты обеспечивают повышенный контроль температуры. Гидропонные системы могут использовать датчики IoT для управления садом, а датчики дыма IoT могут обнаруживать табачный дым. Домашние системы безопасности, такие как дверные замки, камеры видеонаблюдения и детекторы утечки воды, могут обнаруживать и предотвращать угрозы, а также отправлять предупреждения домовладельцам.
«Умные» устройства применяются для:
- автоматического выключения неиспользуемых устройств;
- управления арендованной недвижимостью и ее обслуживания;
- поиска предметов, которые находятся в неположенном месте, таких как ключи или кошельки.
- автоматизации повседневных задач, таких как уборка пылесосом, приготовление кофе и т. д.
«Умные» города
Приложения IoT сделали городское планирование и обслуживание инфраструктуры более эффективными. Правительства используют приложения IoT для решения проблем в инфраструктуре, здравоохранении и окружающей среде. Приложения IoT используются для:
- оценивания качества воздуха и уровня радиации;
- сокращения счетов за электроэнергию с помощью «умных» систем освещения.
- выявления потребностей в обслуживании критически важных инфраструктур, таких как улицы, мосты и трубопроводы;
- увеличения прибыли за счет эффективного управления парковкой.
«Умные» дома
Такие здания, как университетские городки и коммерческие здания, используют приложения IoT для повышения операционной эффективности. Устройства IoT могут использоваться в «умных» домах для:
- сокращения расхода электроэнергии;
- Уменьшения затрат на обслуживание;
- более эффективного использования рабочего пространства.
Что такое промышленный Интернет вещей?
Промышленный Интернет вещей (IIoT) относится к «умным» устройствам, используемым в производстве, розничной торговле, здравоохранении и других предприятиях для повышения эффективности бизнеса. Промышленные устройства, от датчиков до оборудования, предоставляют владельцам бизнеса подробные данные в режиме реального времени, которые можно использовать для улучшения бизнес-процессов. Такие устройства дают представление об управлении цепочками поставок, логистике, человеческих ресурсах и производстве, снижая затраты и увеличивая потоки доходов.
«Умные» промышленные системы разнятся в зависимости от вертикалей.
Производство
Корпоративный IoT в производстве использует профилактическое обслуживание для сокращения незапланированных простоев и носимые технологии для повышения безопасности сотрудников. Приложения IoT могут прогнозировать отказ оборудования до того, как он произойдет, что сокращает время простоя производства. Носимые устройства в шлемах и браслетах, а также камеры компьютерного зрения используются для предупреждения рабочих о потенциальных опасностях.
Автомобилестроение
Аналитика на основе датчиков и робототехника повышают эффективность обслуживания и производства автомобилей. Например, промышленные датчики используются для получения трехмерных изображений внутренних компонентов автомобиля в режиме реального времени. Диагностику и устранение неполадок можно выполнять намного быстрее, поскольку система IoT автоматически заказывает запасные части.
Логистика и транспортировки
Коммерческие и промышленные устройства IoT могут помочь в управлении цепочкой поставок, включая управление запасами, отношения с поставщиками, управление парком и плановое техническое обслуживание. Судоходные компании используют приложения IoT для отслеживания активов и оптимизации расхода топлива на маршрутах доставки. Эта технология особенно полезна для жесткого контроля температуры в рефрижераторных контейнерах. Менеджеры цепочки поставок делают обоснованные прогнозы с помощью «умных» алгоритмов маршрутизации и перемаршрутизации.
Розничная торговля
Компания Amazon продвигает инновации в области автоматизации и взаимодействия человека и машины в розничной торговле. На объектах Amazon используются подключенные к Интернету роботы для отслеживания, обнаружения, сортировки и перемещения товаров.
Как IoT может повысить уровень жизни?
Интернет вещей оказывает широкое влияние на профессиональную и личную жизнь человека. Технология IoT позволяет машинам выполнять более тяжелую работу и утомительные задачи, а также повышать уровень благополучия, продуктивности и комфорта жизни.
Например, «умные» устройства могут полностью изменить утренний распорядок. После нажатия кнопки повтора будильник автоматически включит кофемашину и откроет жалюзи. Холодильник автоматически обнаружит продукты и закажет их с доставкой на дом. «Умная» духовка подскажет меню на день – она может даже приготовить предварительно собранные ингредиенты и убедиться, что обед готов. Смарт-часы будут планировать встречи, а «умный» автомобиль автоматически настраивает GPS на остановку для заправки топливом. В мире IoT возможности неограничены!
Каковы преимущества IoT для бизнеса?
Ускорение инноваций
Интернет вещей предоставляет предприятиям доступ к расширенной аналитике, открывающей новые возможности. Например, компании могут создавать узконаправленные рекламные кампании, собирая данные о поведении клиентов.
Преобразование данных в аналитические сведения и действия посредством ИИ и машинного обучения
Собранные данные и статистику тенденций можно использовать для прогнозирования будущих результатов. Например, информация о гарантии может быть объединена с данными, собранными IoT, для прогнозирования инцидентов, связанных с техническим обслуживанием. Это можно использовать для активного обслуживания клиентов и повышения лояльности клиентов.
Повышение уровня безопасности
Непрерывный мониторинг цифровой и физической инфраструктуры может оптимизировать производительность, повысить эффективность и снизить риски для безопасности. Например, данные, собранные с локального монитора, можно объединить с данными о версиях аппаратного и микропрограммного обеспечения для автоматического планирования обновлений системы.
Масштабирование дифференцированных решений
Технологии IoT могут быть развернуты с ориентацией на клиента для повышения удовлетворенности. Например, можно быстро пополнить запасы трендовых товаров, чтобы избежать нехватки.
Какими бывают технологии IoT?
Технологии, используемые в системах IoT, см. ниже.
Периферийные вычисления
Периферийные вычисления относятся к технологии, используемой для того, чтобы интеллектуальные устройства могли делать больше, чем просто отправлять или получать данные на свою платформу IoT. Это увеличивает вычислительную мощность на периферии сети IoT, уменьшая задержку связи и улучшая время ответа.
Облачные вычисления
Облачные технологии используются для удаленного хранения данных и управления устройствами IoT, что делает данные доступными для нескольких устройств в сети.
Машинное обучение
Машинное обучение относится к ПО и алгоритмам, используемым для обработки данных и принятия решений в режиме реального времени на основе этих данных. Эти алгоритмы машинного обучения можно развернуть в облаке или на периферии.
Что такое AWS IoT и каковы преимущества?
AWS IoT объединяет ИИ и IoT для улучшения бизнес-результатов. Это единственный поставщик облачных услуг, который сочетает управление данными и богатую аналитику для создания простых в использовании услуг, предназначенных для обработки больших объемов данных IoT.
AWS IoT включает в себя такие сервисы, как безопасность, шифрование данных и контроль доступа к данным устройства. AWS IoT построен на безопасной и проверенной облачной инфраструктуре и сетях IoT и масштабируется до миллиардов устройств и триллионов сообщений. AWS IoT интегрируется с другими сервисами AWS, что позволяет создавать комплексные решения.
Разработка посредством AWS IoT
AWS IoT – поставщик сервисов IoT для промышленных, потребительских и коммерческих решений. Вы можете положиться на сервисы AWS IoT для создания приложений, которые раскрывают новые преимущества для бизнеса, запускают сложную аналитику, а также обнаруживают и реагируют на события с большого количества IoT-устройств.
Чтобы начать работу с AWS IoT, создайте бесплатный аккаунт AWS. Только начинайте осваиваться в мире IoT? Изучите основы и приступайте к созданию простых комплексных приложений IoT.
Интерфейсы и протоколы в IoT. Лекция первая
В этом году меня в очередной раз позвали в Московский институт электроники и математики (МИЭМ) НИУ ВШЭ читать студентам магистратуры (четвёртый курс на наши деньги) департамента электронной инженерии курс «Обеспечение взаимодействия элементов системы IoT, интерфейсы и протоколы».
Когда-то давно я уже читал вводный курс по программированию микроконтроллеров в МИРЭА, от лекций которого остались любезно сделанные вузом видеозаписи (от семинаров не осталось ничего, увы), потом — курс по Интернету вещей (там было сочетание микроконтроллеров, их программирования и введения в специфику IoT-систем) уже в МИЭМ НИУ ВШЭ, от которого, увы, тоже не осталось никаких публично доступных материалов.
В этот раз хочу исправиться — и выложить, не отходя от кассы, конспекты всех лекций. Объём курса заложен очень приличный — 60 академических часов, собранных в 14 групп занятий, с начала января и по середину июня.
Надеюсь, разные рассказываемые вещи будут полезны не только моим студентам (ребята, но вы же понимаете, что в тексте будет просто в силу формата сказано меньше, чем голосом на лекциях?), которым не надо писать конспекты лекций, но и всем желающим. Например, не далее как сегодня вступал на Хабре в статье про протоколы питания в USB-C в дискуссию «зачем они так сделали» — а в прошлый вторник рассказывал студентам, какие на самом деле соображения могут лежать в основе выбора того или иного решения, и как раз на примере эволюции питания в USB.
Интерфейс и протокол
Я неоднозначно отношусь к такой любимой многими преподавателями вещи, как формальные определения: с одной стороны, знать их, как правило, не мешает, с другой — вызубривание последовательности слов часто заменяет реальное понимание процессов, лежащих за этими словами (в своё время у меня был однокурсник, который великолепно обращался с формулами, но любой преподаватель мог завалить его вопросом «ну ладно, это всё замечательно, а теперь отложите расчёты и объясните мне на пальцах, что тут происходит?»).
Зато очень люблю попытки наложить тот или иной изучаемый объект на чисто бытовые понятия — они не только позволяют понять суть явления, но и расширяют границы восприятия, устраняя ситуацию, когда человек вроде бы и знает даже определение, но упорно не может понять, как его применить в конкретном случае.
Попытка заучивания определений мне напоминает переводной метод изучения иностранного языка — благополучно похороненный лет двадцать назад, хотя люди, которые помнят номера табличек по учебнику Бонк, но при этом не могут связать пять слов на ресепшене отеля, регулярно встречаются до сих пор.
Ну, например. «Интерфе́йс (от англ. interface) — граница между двумя функциональными объектами, требования к которой определяются стандартом; совокупность средств, методов и правил взаимодействия (управления, контроля и т. д.) между элементами системы», — сообщает нам Википедия.
Что печально, правильно построенное определение — что твоя матрёшка: оно включает в себя отсылки к другим определениям, и далее, и далее. Например, «. между двумя функциональными объектами» — опа, пошли смотреть, что такое «функциональный объект», является ли то, к чему мы хотим прикрутить интерфейс, именно функциональным объектом, или каким-то другим (а то и вообще не объектом, а субъектом), и понеслась. Все правила знаем, номера табличек помним, слова во фразу сложить не можем.
Поэтому давайте начнём с простого примера: с устной речи. Очевидно, устная речь — это взаимодействие между двумя людьми, которых, наверное, можно отнести к «элементам системы».
Давайте сразу договоримся: интерфейс — это механизмы, которые обеспечивают нам возможность взаимодействия (передачи информации). Протокол — это договорённости, которые реализуют это взаимодействие с использованием данных механизмов.
Что есть интерфейс в устной речи? Из аудитории звучит «голосовые связки», но на самом деле — в первую очередь это воздушная среда (или, в более общем случае, другая упругая среда), потом уже органы дыхания, а потом уже голосовые связки. Этого набора в принципе достаточно для формирования звуков — но пока что эти звуки не имеют смысла, они не передают информацию.
Для передачи информации мы используем протокол — и что характерно, если интерфейс у всех одинаковый, то протоколы крайне изменчивы. В протокол устной речи входят:
- фонетика — то есть звучание букв;
- лексика — то есть построение из этих букв слов;
- грамматика — то есть сборка из отдельных слов целых фраз;
- социальные нормы.
Последний пункт не называет практически никто и никогда — кроме профессиональных лингвистов, для которых он очевиден. Но на самом деле — это тоже крайне важный элемент протокола: если я буду разговаривать с вами вне принятых для данного контекста социальных норм (например, перейду на мат), наше взаимодействие не сложится (например, меня забанят).
Пока что это всё кажется тривиальным, но сделаем один шаг дальше — положим наше устное взаимодействие на модель OSI.
Да, сейчас придут хардкорные айтишники и расскажут, что модель OSI давно ничего не описывает, потому что вот у нас тут Wireguard поверх PPPoE поверх Wi-Fi (реальный случай, напишу наверное тоже статью на днях) поверх чёрта в ступе, и как вы это в вашу пирамидку. Но — как и любые простые представления, модель OSI может не описывать всю сложность окружающего мира, зато практически незаменима для того, чтобы сколь-нибудь наглядно представить себе его базовое устройство. Ньютоновская механика тоже, знаете ли, реальный мир описывает так себе, но отменять её пока никто не планирует.
Итак, как можно попробовать разложить устную речь в модель OSI?
- физический уровень — ну, это очевидно, это упругая среда, как правило воздух, в космосе никто не услышит твой крик;
- канальный уровень — голосовые связи (с одной стороны канала) и уши (с другой стороны), они обеспечивают взаимодействие между двумя людьми по акустическому каналу;
- сетевой уровень — здесь всё становится интереснее, но можно вспомнить, что в него должна попадать маршрутизация, а что у нас есть маршрутизация, если не обращение к собеседнику? Это, кстати, не обязательно произнесение его имени, это и поворот головы в его сторону, и невнятное мычание, и «мальчик жестами показал, что его зовут Хуан». В общем, маршрутизация в устном общении очень рудиментарная, но нельзя сказать, что её нет.
- транспортный уровень — обеспечивает надёжную передачу данных. В устной речи это, пожалуй, фонетика и лексика. «Нрзбр» в транскрипте — это когда сломалось либо то, либо другое, и слово превратилось в набор звуков.
- сеансовый уровень — и тут аудитория угадала с первой попытки, сеансом в речи можно считать разговор. В речи нет явных признаков «этого разговора», но есть много неявных — максимально допустимая задержка между фразами, например, непрерывное нахождение собеседеников в поле зрения друг друга и так далее.
- уровень представления — пожалуй, что грамматика. Если в компьютере уровень представления — это, например, формат файла, который обе системы должны понимать одинаковым образом, то в речи — построение фраз. «Буквы знаю, смысла не понял» — это как раз случай нестыковки на уровне представления, могущего возникнуть как по причине шизофазии у одного из собеседников, так и в случае, например, попытки объяснить номотетический метод немецкого неокантианства человеку, который не очень уверен, что такое «категорический императив».
- прикладной уровень — очевидно, само содержание разговора.
Таким образом немного развлекшись и повысив пластичность мозга, приступим к чуть более формальной части.
Любой интерфейс описывается неким набором технических параметров, всегда фундаментально ограниченных снизу нашими хотелками (интерфейс, не решающий поставленную задачу, очевидно, не нужен), а сверху — законами физики.
Но при этом очевидно, что не все интерфейсы равны — какой-то хуже, какой-то лучше. Но как именно мы будем это хуже-лучше? Быстрее, но прожорливее — это лучше или хуже?
Крайне полезно не просто выписать значимые параметры интерфейса, а нарисовать их на лепестковой диаграмме.
Второй крайне полезный момент — представить себе контур такой диаграммы как резинку (возьмите аптечную или резинку и растяните её на пальцах). Хотите увеличить один параметр, не ухудшая другие? Вам придётся приложить больше усилий, потому что резинка сопротивляется. Не хватает усилий? Значит, чтобы ещё сильнее увеличить один параметр, придётся уменьшить другие.
Это момент, который не понимают даже многие начинающие проектировщики, что уж говорить даже про многоопытных интеграторов, — all magic comes with a price. Если вы смогли улучшить один параметр, не ухудшая другие — значит, ваш новый интерфейс объективно лучше старого. Но рано или поздно вы придёте к ситуации, когда невозможно улучшить одно, не ухудшая другого. Неизбежно.
Ну, например, прискорбно малоизвестная формула предела Шеннона на скорость передачи данных в канале с шумами. Это — физическое ограничение, верхний предел, к которому нужно стремиться, но невозможно превзойти. При заданном уровне сигнала (то есть вбухиваемой в канал мощности, то есть энергопотреблении передатчика) и заданной полосе частот скорость может быть только такая. Хотите больше? Можно, но надо, например, вложить большую мощность — а значит, пожертвовать экономичностью устройства.
В принципе, уже очевидно, как правильно оценить «хорошесть» интерфейса: по площади, которую занимает диаграмма его параметров. Любой интерфейс, который занимает меньшую площадь, менее оптимален — его разработчиками не выбраны доступные физические пределы на его параметры.
Нежно люблю эту картинку — тем более, что она отражает некоторые реальные моменты из моего опыта взаимодействия с маркетинговым отделом.
И она же, если посмотреть на неё с другой стороны, а это вообще полезное упражнение — побыть адвокатом дьявола — на самом деле не так уж однозначна. Потому что маркетинговый отдел, внезапно, тоже может иметь свои причины так обращаться с продуктом — которые может не знать инженер (да, дальше маркетинг действует неправильно, но кто, на минуточку, сказал, что инженеры всегда действуют правильно?).
И эти моменты крайне желательно понимать — не только потому, что они могут повлиять и повлияют на вашу работу (если вы не планируете работать в гордом одиночестве), но и помогут вам правильно понять, почему то или иное решение было сделано в прошлом.
Диаграммы выше описывают чисто технические параметры интерфейса. Но причины, по которым его сделали именно таким — в том числе и не обязательно идеальным — могут быть довольно разнообразны:
- технические причины — здесь всё понятно, это имеющиеся у нас технические пожелания и физические ограничения, которые пришли в какой-то компромисс;
- экономические причины — это не просто стоимость реализации какого-то технического решения, но и ожидаемые доходы от его использования. Хороший пример — дорогой в реализации Lightning, от которого Apple при этом отказывается очень неохотно, потому что. да потому что он принёс Apple миллиарды на продаже аксессуаров, производство которых даже сторонними производителями компания может контролировать.
- политические причины — конкретное решение может даже не приносить денег напрямую, но при этом формировать определённый образ компании («инновационная», «отечественная», и так далее, возможных эпитетов десятки). Отказ от проприетарного решения в пользу стандартного — это часто как минимум одна волна негативных комментариев в стиле «прогнулись, смотрите, они больше не инновационные, теперь у них как у китайцев», и даже это при принятии решений учитывается.
- исторические причины — это, в первую очередь, сложившаяся практика использования решений компании. Например, недавно в одной статье на Хабре проскальзывало удивление, что Siemens годами не модернизирует свои ПЛК, их внешний вид и интерфейс такой же, как двадцать лет назад — но задумывался ли автор, что может быть, Siemens обладает некоторой информацией, побуждающей его делать иметь так? Например, что заказчики между современным интерфейсом и отсутствием необходимости переучивать эксплуатационщиков на новый продукт выбирают второе?
Более того, не менее важный момент — а кто вообще вам сказал, что какое-то решение является удачным, оптимальным, оправданным? Сам факт его использования ещё не означает ничего из этого.
Разработчика этого решения наградили или уволили? Если уволили, то с какой формулировкой? Не осталось ли оно в использовании в основном потому, что уже не было бюджета и времени на его переделку (экономический фактор), было решено не докладывать заказчику о необходимости пересогласования ТЗ (политический фактор), а в последующие годы требовалось поддерживать обратную совместимость с ним (исторический фактор)?
Я очень часто встречаю инженеров, которые очень стремятся что-то улучшить, но редко — задающихся вопросом о влиянии нетехнических факторов, и следовательно, о том, улучшат ли они ситуацию в целом, улучшив техническое решение.
Как пример развития интерфейса и протокола, возьмём такую штуку, как питание по USB.
Интерфейс USB зародился в середине 1990-х годов как универсальная замена существовавшему тогда зоопарку из RS232/COM, LPT, SCSI, PS/2 и чёрт знает чему ещё. Он обеспечивал передачу данных на достаточной для большинства применений скорости, а также подачу на периферийные устройства питания с напряжением 5 В и током до 500 мА.
Никто вообще не рассматривал в тот момент USB как интерфейс электропитания. Наличие в нём напряжения было чисто вспомогательной функцией для мелкой периферии, которой по определению не надо было много ватт и которая по определению в любом случае общалась с компьютером-хостом — то есть полноценная реализация протокола передачи данных в ней была.
Соответственно, для получения своего устройство сразу после подключения начинает инициализацию интерфейса, в ходе которой отправляет хосту дескриптор bMaxPower, в котором указан желаемый им ток с шагом 2 мА, в однобайтовой переменной. До ответа хоста устройство имеет право потреблять в пределах 100 мА, после ответа — сколько попросило, если хост столько разрешил.
Но потом появились смартфоны.
Galaxy SII тут, конечно, чисто для примера, началось всё раньше. Началось с появления устройств, у которых разъём USB, на тот момент — microUSB, использовался как для обмена данными с хостом, так и для зарядки аккумулятора устройства. И аккумуляторы эти стали быстро расти в ёмкости.
Во-первых, возник вопрос зарядных устройств, не являющихся компьютером, то есть — хостом. Поддержка с их стороны обмена данными по протоколу USB сильно усложняла и удорожала их конструкцию (экономическая причина), соответственно, о какой-то инициализации и обмене дескрипторами речи не шло.
Во-вторых, возникла потребность в больших мощностях данных зарядных устройств, позволяющих сократить время зарядки аккумулятора — благо что со стороны смартфона технических препятствий здесь не было, литиевый аккумулятор довольно быстро может набрать первые 50-70 % ёмкости.
Но это привело к следующей проблеме — а как, собственно, смартфон поймёт, что можно от зарядки потребить больше 500 мА? И сколько конкретно можно-то?
В Samsung сделали просто — повесили на сигнальные линии USB обычные резисторы. Резистор стоит копейки (буквально), а алгоритм получился простой и вроде бы надёжный: смартфон, увидев питание на шине USB, пробует достучаться до хоста, если ответа нет — значит, это не хост, а зарядка, дальше смотрим, какие уровни напряжения стоят на D+/D- и делаем выводы о том, какой ток зарядка может отдать. Нет ответа и нет резисторов — 500 мА, есть резисторы — смотрим по их комбинации из нескольких возможных вариантов.
Один нюанс — аккумуляторы-то продолжают расти. И 7,5 Вт уже не выглядят серьёзной мощностью, а просто поднять ток — чревато перегрузкой разъёма и кабелей, банальным их подгоранием.
И тут приходит компания Qualcomm и предлагает — а давайте увеличивать напряжение! Так при том же токе мы сможем поднять мощность, а уж 5, 9 или 12 В — кабелям вообще без разницы, изоляция там по определению на напряжения на порядок больше сделана. При этом уже зарядка должна понять, какое напряжение можно подавать на устройство, то есть задача внезапно разворачивается на 180 градусов.
Но делать это мы будём по-прежнему дёшево, потому что на дворе вообще-то 2015 год, и встраивать в зарядку какие-то серьёзные протоколы, а уж тем более, довольно сложный в реализации протокол USB — по-прежнему сложно и дорого.
Так возникают по сути те же самые резисторы, но теперь их выставляет не зарядка, а устройство — показывая, сколько вольт оно готово получить. Зарядка же, пользуясь достаточно несложным (то есть дешёвым и простым) чипом, выясняет, сколько вольт надо подать на устройство.
Что мы видим на этом этапе? Да весь спектр причин возникновения именно такого протокола:
- технический — есть физические ограничения интерфейса, которые надо как-то обойти;
- экономический — надо сделать это дёшево, поэтому наиболее прямолинейный путь, заключающийся в использовании линий данных интерфейса по их прямому назначению, не подходит по деньгам;
- политический — конечно, каждый производитель хочет эти новые возможности сделать конкретно под себя;
- исторический — менять разъём USB на что-то другое нереально, только-только все наконец на USB-то переехали (даже эксперименты с microUSB 3.0 на смартфонах успеха не имели, с ним вышли единичные модели, а ведь он хотя бы был полностью обратно совместим с microUSB 2.0).
При этом QuickCharge тоже, с очевидностью, не был панацеей от всех бед. Во-первых, он по-прежнему принадлежал конкретной компании, хоть и готовой лицензировать его на сторону (и тут параллельно QC родилась ещё пачка различных альтернативных протоколов быстрой зарядки, например, Oppo VOOC). Во-вторых, универсального протокола внутри QC по-прежнему не было — была лишь договорённость о том, что несколько конкретных уровней постоянного напряжения на линиях данных разъёма USB сигнализировали о нескольких конкретных уровнях напряжения зарядки.
В-третьих, судя по всему, китайцы довольно быстро пренебрегли в своих QC-зарядках требованиями к обязательному хендшейку — и начались случаи, когда такая зарядка встречалась с устройством, у которого почему-то на D+/D- были выставлены уровни, в QC кодирующие 9 или 12 В. Ну и зарядка, пренебрегшая хендшейком, в ходе которого она могла бы установить, что устройство на самом деле может питаться только от 5 В, туда ему 9 или 12 В и подавала.
Некоторые мои коллеги уже прямо запретили покупать им зарядки с поддержкой QC, потому что объяснить бойцу, что некоторые устройства нельзя включать в некоторые USB-порты (хорошо, если внешне отличающиеся хотя бы цветом), невозможно.
И помимо этого, мощность устройств продолжала упорно расти! Более того, идея о том, что устройства — любые устройства — очень удобно заряжать от USB, захватывала всё больше умов, благо что и доступная мощность уже поднялась с изначальных 2,5 Вт до весьма серьёзных 18 Вт.
К счастью, в этот момент наконец-то случилась перезагрузка: на смену классическому USB пришёл USB-C, в разъёме которого, помимо всех прочих удобств, можно было сделать очень много ножек — и, с учётом сложившейся реальности, две из них под названием CC выделили на нормальный протокол зарядки, получивший название Power Delivery (PD).
Цифровая двусторонняя связь между устройством и зарядкой, мощности до 240 Вт (в распространённых на данный момент устройствах — до 65 Вт, но и этого уже достаточно для ноутбуков, а не только смартфонов), напряжение до 48 В, возможность точной установки как напряжения, так и тока.
Почему это стало возможным и, более того, популярным?
- технический фактор — разъём перестал быть лимитирующим фактором, так как новый разъём изначально учитывал потребность в зарядке;
- экономический фактор — для управления зарядкой были выделены отдельные линии, что незначительно увеличило цену разъёма, но зато позволило реализовать простой и дешёвый протокол обмена данными конкретно о зарядке (цифровой интерфейс на скорости 300 кбит/с);
- политический фактор — спецификации PD не принадлежали ни одному конкретному вендору, реализовывать их могли все желающие (и это далее позволило Google внести поддержку стандартных протоколов зарядки по USB-C сначала в рекомендуемые, а потом в обязательные требования к Android-смартфонам);
- исторический фактор — смена разъёма на USB-C к этому моменту уже была обусловлена многими причинами, и в целом покупателями воспринята положительно.
В некотором смысле, технологии развивались по спирали: история началась с bMaxPower в цифровом протоколе USB, прошла через несколько поколений сильно упрощённых аналоговых решений, а закончилась снова на цифровом протоколе USB — только уже другом протоколе и в другом USB. Но при этом выбор интерфейса и протокола на каждом этапе был обусловлен серьёзными причинами, которые не позволяли как-то срезать углы и побыстрее прийти к Power Delivery.
То есть, является ли протокол Samsung или QuickCharge в версиях 2 и 3 (в 4 он стал совместим с PD) оптимальным на данный момент? Нет, потому что сейчас можно незначительно дороже сделать значительно лучше. Но являлись ли они оптимальными на момент своей разработки? Да, потому что тогда другие решения имели бы существенно более высокую цену — хотя и, вне всякого сомнения, были технически реализуемы.
Внимательный читатель уже заметил, что где-то посередине разговора мы перешли от интерфейса к протоколу, то есть договорённости о том, как мы используем данный нам интерфейс.
Замечу два важных момента: во-первых, интерфейс может позволять реализовать много разных протоколов, абсолютно несовместимых друг с другом. Не только USB, но и, например, банальный проводной телефон: он имеет протокол передачи номера на АТС, протокол вызова и протокол передачи голоса. Они существенно различны, не могут использоваться в один момент времени и не могут заменять друг друга — но эксплуатируют один и тот же интерфейс, двухпроводную линию связи с центральным питанием.
Во-вторых, если интерфейс ограничен требованиями физического мира, то протокол — уже возможностями интерфейса. Разъём USB-A — не вершина инженерного мастерства и уж точно не предел физически допустимого, но долгие годы именно его конструкцией и возможностями определялось развитие протоколов быстрой зарядки по USB.
При этом «хорошесть» протокола также можно прикидывать по площади на лепестковой диаграмме — только не надо забывать, что содержание этой диаграммы меняется со временем, даже если сами протоколы остаются неизменными. Двадцать лет назад «дешевизна» у Power Delivery была бы в районе нуля, а универсальность упиралась бы в нераспространённость необходимого ему разъёма USB-C.
Это гигансткое лирическое отступление в целом обозначает, что именно я планирую донести до слушателей в рамках курса. Ни в коем случае не наборы справочных характеристик различных протоколов, и даже не «давайте возьмём библиотечку и отправим данные с Raspberry Pi в облако» — я хочу донести сложность окружающего мира, пусть и в контексте только используемых в IoT протоколов и интерфейсов, научить понимать её причины и в этой сложности ориентироваться.
Какие вообще бывают интерфейсы и протоколы в IoT, а также какое внимание мы им уделим?
Первая группа — внутрисхемные интерфейсы, обеспечивающие взаимодействие внутри устройства. Они практически всегда проводные, крайне консервативно развиваются (старшим из них уже десятки лет, и ещё десятки лет они будут с нами), а главное — обеспечивают связь на небольших расстояниях, обычно не более десятков сантиметров.
Иногда, впрочем, в качестве внутрисхемных используются внешние интерфейсы, такие как USB, Ethernet или CAN — в зависимости от конкретных потребностей в скорости, наличия аппаратных приёмопередатчиков и т.п. При этом они могут технически упрощаться, например, интерфейс Ethernet внутри устройства может использовать без разделительных трансформаторов.
Проводным внутрисхемным интерфейсам будет посвящена следующая лекция.
Межмашинные проводные интерфейсы и протоколы — использующиеся для проводной связи между различными устройствами. Также развиваются весьма консервативно, но в быту в последнее десятилетие активно сдают позиции беспроводным интерфейсам — в промышленности, впрочем, держатся и будут держаться ещё долго, ибо in wire we trust.
Это могут быть специализированные бытовые интерфейсы, такие как PS/2 (мыши и клавиатуры в компьютерах), LPT (параллельный порт принтера там же), RS-232 (модемы) — эта категория сейчас уже фактически полностью вымерла.
Это могут быть промышленные интерфейсы — RS-485, аналоговая токовая петля 4-20 мА и цифровой HART поверх неё.
Это могут быть автомобильные интерфейсы — CAN и LIN — сейчас уже вышедшие за пределы автомобильной промышленности.
Наконец, это современные универсальные бытовые интерфейсы, такие как USB и Ethernet.
Проводным межмашинным интерфейсам также будет посвящена одна лекция.
И наиболее интересная часть — это беспроводные интерфейсы, бурно развивающиеся последние два десятилетия, уже серьёзно потеснившие проводных конкурентов в быту и офисе, а также активно пробивающиеся в промышленное и даже военное применение.
Они крайне, невероятно разнообразны, не менее запутана и их эволюция с годами — и потому они представляют особенный интерес для изучения.
Это бытовые интерфейсы общего назначения — Wi-Fi, Bluetooth (что интересно, разрабатывавшийся в своё время как интерфейс довольно узкого применения), BLE. Это протоколы умного дома — Zigbee, Z-Wave, Thread, Matter, BLE Mesh. Это протоколы сотовой связи — от 2G/GPRS до 4G и его IoT-отпрысков LTE-M и NB-IoT. Это весьма интересные сверхэкономичные низкоскоростные протоколы дальней связи специально для IoT-систем — Sigfox, OpenUNB, LoRaWAN. Это спутниковая связь — которая, как ни странно, существовала задолго до Starlink, хотя последний и привнёс в неё новое качество. Наконец, это военные системы связи, которые также весьма своеобразны в своём развитии — но благодаря этому позволяют продемонстрировать некоторые вещи, важные и интересные, но несущественные или попросту незаметные на «гражданке» (возьмём тот же ППРЧ или широкополосную модуляцию — в некотором смысле их назначение в Bluetooth и «Азарте», в LoRaWAN и «Волновой сети», конечно, схоже. ).
Именно беспроводные протоколы и займут оставшиеся лекции. Как они эволюционировали, зачем создавались и почему умирали, какими физическими ограничениями определяются их свойства, каких целей пытаются достичь их разработчики и эксплуататоры, как в них обеспечивается надёжность, криптографические и стеганографические свойства, как работают mesh-сети и прочая, и прочая.
- Беспроводные технологии
- Производство и разработка электроники
- Умный дом
- Электроника для начинающих