[prog] Поверхностные впечатления от Internet of Things и Machine-2-Machine

В связи с образовавшимся наличием свободного времени и дабы немного развеяться решил оглядеться по сторонам и посмотреть, что же происходит в других областях. Случайно внимание привлекла такая штука, как Internet of Things. Немного покопался в этой теме и дошел до другой штуки, на мой взгляд, более приземленной и реальной: Machine-2-Machine. Какое-то поверхностное, наверняка не объективное, впечатление сложилось. Интересно будет затем проверить, насколько права оказалась моя интуиция.

Internet of Things

На мой взгляд, Internet of Things на данный момент -- это миф. Это что-то вроде российских нанотехнологий, хорошая площадка для распила средств и проедания грантов. Или чего-то похожего на cloud computing шести или семилетней давности: много разговоров, много обещаний, но к чему все это придет так никто и не знал, и что затем трансформировалось в более-менее осязаемые понятия SaaS, PaaS и IaaS.

Internet of Things -- это мечта соединять все со всем. Ну, типа, у нас же есть Интернет, в котором есть куча сайтов и сервисов, на которые можно заходить с разных компьютеров (смартфонов, планшетов). И все это классно и здорово, и работает. А раз есть Интернет, в котором пользователь может найти или организовать для себя то, что ему нужно, то почему бы на место пользователя не поставить какое-то устройство. Да тот же смартфон, например. Или умный счетчик воды в квартире. Или умный холодильник. Или умную коробку с таблетками, которая напоминает о необходимости очередного приема лекарств и извещает о том, что таблетки заканчиваются. Или умную стиральную машину, которая сама выбирает программу стирки, когда в нее помещают "умную" одежду (это всего лишь одежда, на которой есть специальные маркеры, вроде RFID чипа). Или...

Идеальная картина мира, которую, как мне показалось, рисуют евангелисты IoT, это что-то вроде: вечером выйдя с работы вы садитесь в машину, выбираете на навигаторе пункт "Домой", навигатор связывается с центральным компьютером в вашем умном доме, тот запускает кондиционер (для подготовки комфортной для вас температуры) и кофеварку (дабы встретить вас чашечкой вашего любимого кофе). Еще дается команда вашему холодильнику провести ревизию содержимого и составить список отсутствующих или заканчивающихся продуктов. Далее навигатору в вашей машине будет предложено проложить маршрут через ближайший к основному маршруту супермаркет с наиболее выгодными ценами на эти продукты. А, если вы согласитесь туда заехать, возможно, будет направлен запрос в автоматизированную систему супермаркета для того, чтобы ваша покупка была подготовлена к вашему прибытию...

В общем, границы перспектив IoT ограничивается только вашей собственной фантазией. Что, собственно, и ставит большой крест на всей идее IoT по моему разумению. Ибо глобальные идеи "все связывается со всем" работают только в голливудских блокбастерах :) А в реальной жизни люди создают себе частные решения своих частных проблем, комбинируя чужие достижения, иногда добавляя что-то новое, но, в основном, выстраивая мостики между уже существующими частными решениями. Поэтому лично я не верю в то, что из такой аморфной штуки, как IoT, может вырасти что-то большое и реально работающее.

Хотя нельзя отрицать, что в рамках направления IoT ведутся и должны вестись важные исследования и разработки, которые, со временем, создадут необходимый базис для создания будущих больших и сложных систем. Не только в технологическом плане (например, технологий и стандартов посредством которых умные устройства разных производителей будут связываться друг с другом) или научно-исследовательском (например, может потребоваться развитие новых методов криптографической защиты информации, аутентификации, подтверждения подлинности и т.д.), но и в юридическом (например, легальные и утвержденные законом способы и средства обмена медицинской информацией между устройствами в одной стране могут не быть таковыми в другой стране), а так же в социальном (готово ли общество к тому, что при распространении умных устройств в разы вырастет объем информации, которую можно собрать на конкретного человека).

Собственно, именно поэтому сейчас движуха в области IoT наблюдается именно со стороны научных и исследовательских организаций, проедающих гранты Евросоюза, США или крупных корпораций. Чтобы составить себе впечатление о том, что же вся эта кухня из себя представляет, можно посмотреть вот этот сборник статей: The Internet of Things 2012 - New Horizons, собранный организацией под названием European Research Cluster on the Internet of Things. Сборник этот большой, 360 страниц, плюс не очень новый (все таки 2012 год, а сейчас все развивается очень стремительно), но общее представление о том, что такое современный Internet Of Things, составить можно.

В то же самое время под маркой IoT потихоньку пытаются зарабатывать деньги производители устройств и/или сервисов для сбора и обработки разнообразной информации. Ярким примером может служить такой сервис, как Xively, который предлагает свой собственный облачный сервис для хранения измерительной информации и собственный API для работы с этим сервисом. Понятное дело, что все это, пусть и в виде OpenSource-библиотек, является чистой воды proprietary-решением (с эффектом vendor lock-in), никакого отношения не имеющего к открытым стандартам, интероперабельности между подобными сервисами и т.д. и т.п.

В общем, IoT сейчас -- это некое аморфное направление, в рамках которого различные исследователи на гранты правительств или крупных корпораций занимаются поиском того, что может стать востребованным в будущем. Плюс, это некая маркетинговая фишка, под которой что-то кому-то можно продать прямо здесь и сейчас.

Machine-2-Machine

В большой аморфной штуке под названием Internet of Things есть штука чуть поменьше, более четко обозначенная и ограниченная, которая называется Machine-2-Machine. На данный момент M2M представляется как одна из подобластей IoT, имеющая большое прикладное значение. Хотя я не буду этого утверждать. Вроде бы, направление M2M началось и развивалось, во многом, самостоятельно, а к IoT M2M притягивают уже по факту, т.к., во-первых, в IoT можно принянуть все что угодно, и, во-вторых, IoT как воздух нужны средства коммуникации устройств между собой. А это именно то, чем M2M занимается.

Суть M2M в выработке конкретных механизмов для того, чтобы позволить разнородным устройствам от разных производителей взаимодействовать друг с другом. В M2M, в отличии от IoT, акцент ставится именно на слове "конкретных". Поэтому M2M занимается такая серьезная организация, как ETSI -- European Telecommunications Standards Institute. ETSI разработала серию стандартов/рекомендаций для M2M Communications. Эти стандарты/спецификации доступны для свободного скачивания на соответствующей странице официального сайта ETSI. Cразу хочу предупредить, что штудирование данных стандартов дело крайне неблагодарное и тяжелое (даже если начинать с обзорного TS 102 690 "Machine-to-Machine communications (M2M); Functional architecture"). Лучше найти в Интернете книгу "M2M Communications. A System Approach" под редакцией David Boswarthick, Omar Elloumi и Olivier Hersent. Оттуда можно почерпнуть общую информацию о том, что же скрывается под маркой M2M, в каком направлении все это движется и что уже имеется в наличии. И лишь затем, если появится заинтересованность, желание или необходимость, можно приступить к штудированию стандартов.

Что подкупает в M2M, так это то, что M2M явно занимаются приближенные к реальности люди. Они отдают себе отчет, что соединение всех со всеми -- это утопия. Что даже если не смотреть на технологии, а просто взглянуть на вещи с обывательской точки зрения, нет никакого смысла в том, чтобы умная упаковка для таблеток могла связаться с умной поливочной машиной, а умной кофеварке вряд ли есть смысл взаимодействовать с цифровым фотоаппаратом. Поэтому в ETSI пошли по пути описания нескольких use-case. А именно, в разделе M2M Communications есть несколько документов, описывающих потенциальные варианты использования M2M в совершенно разных прикладных областях, а именно: TR 102 732 "Use Cases of M2M applications for eHealth", TR 102 857 "Use Cases of M2M applications for Connected Consumer", TR 102 898 "Use cases of Automotive Applications in M2M capable networks" и TR 102 691 "Smart Metering Use Cases". В ETSI полагают, и я в этом с ними согласен, что если под централизованным присмотром для каждой из предметных областей будут создаваться частные решения, то в этих решениях может быть накоплено достаточно много общего для выработки общего стандарта. Или же будут обнаружены принципиальные различия из-за которых нужно будет создавать не одно общее семейство стандартов, а несколько независимых друг от друга, но заточенных под конкретные прикладные области (как например, сейчас есть разные стандарты для беспроводной передачи данных WiFi, Bluetooth, NFC, ZigBee и пр.).

Активное участие, курирующей, в том числе, и стандарты сотовой связи, ETSI в развитии M2M неспроста. Дело в том, что для современных сотовых сетей характер взаимодействия между отдельными классами умных устройств крайне неудобен. Например, если речь идет об умных датчиках влажности, разбросанных на нескольких десятках гектаров какого-либо фермерского хозяйства, то каждый из датчиков может передавать всего 3-4 байта полезной информации, выходить на связь лишь один раз в сутки, иметь очень высокие требования к энергопотреблению (для того, чтобы работать на одной батарейке по 15-20 лет) и, поэтому, не может проводить ресурсоемкие операции регистрации на базовой станции и упаковывать свои 4 полезных байта в PDU объемом 1.5Kb. А в зоне обслуживания более-менее крупного оператора может оказаться не десяток миллионов телефонных аппаратов (как сейчас), а несколько сотен миллионов умных устройств. В каждое из них SIM-ку не вставишь и номер телефона (называемый MSISDN и имеющий ограниченную емкость) не назначишь. Да и подходы к тарификации M2M взаимодействий операторам нужно будет менять, т.к. снимать деньги за пересылку 4 байт от двухсот счетчиков одного клиента раз в сутки -- это совсем не то, что списывать средства за минуты телефонного разговора или килобайты GPRS-трафика.

В то же время, интерес у операторов сотовой связи к M2M-коммуникациям должен быть. Ведь пользы от умных устройств не будет, если они не смогут между собой взаимодействовать. А как организовать это взаимодействие, если расстояние между устройствами превышает радиус действия Bluetooth или WiFi? Тот же фермер при развертывании умных установок для полива и подкормки растений не будет прокладывать по своему полю километры кабеля. А вот если его участок находится в зоне покрытия сотового оператора, то задействование мощностей оператора -- это первое, что приходит в голову.

В общем, если M2M-взаимодействие действительно получит развитие, то операторам придется серьезно развивать свои сети передачи данных, а так же пересматривать подходы к оказанию услуг своим пользователям. Поэтому, как мне показалось, крупные сотовые операторы сейчас являются одними из основных движителей процесса развития M2M-коммуникаций, занимаясь разработкой и продвижением своих M2M платформ (как, например, AT&T).

Завершая раздел общей информации об M2M, нужно указать, что отдельное направление в этой теме -- это безопасность. Информация, передаваемая между умными устройствами, должна быть защищена. Сами устройства должны быть защищены от разных типов атак. Если принять во внимание то, что многие умные устройства будут совершенно маломощными недокомпьютерами, на которые не засунешь сильную криптографию, да еще и срок службы некоторых изделий должен будет определяться десятилетиями (а за это время обязательно будут выработаны новые атаки, средства взлома или же вычислительные мощности злоумышленников возрастут настолько, что появится возможность раскрытия перехваченных криптограмм методом грубой силы), то задача обеспечения защищенности M2M взаимодействий выглядит очень и очень непростой. Для соответствующих специалистов, полагаю, здесь не паханное поле. Но я к таким специалистам не отношусь, поэтому развивать эту тему не могу.

Взаимодействие между M2M устройствами и приложениями с точки зрения ETSI

Вот что мне не понравилось в ETSI-шных M2M-спецификациях, так это положенный в основу REST-подход. С базовой реализацией на основе HTTP.

Общую схему M2M взаимодействия ETSI видит себе так:

Где, в простейшем случае, взаимодействие между D (устройство), DSCL (софт, выставляющий возможности устройства наружу), GA (приложение-шлюз), GSCL (софт, выставляющий возможности шлюза наружу) и т.д. -- это все HTTP-запросы в рамках идеологии RESTful. А специфицированные ETSI интерфейсы взаимодействия dIa, mId, mIa, mIm -- это описание структуры ресурсов (в рамках RESTful) и правил поведения при выполнении тех или иных операций с каждым из ресурсов. И, например, для получения информации о потреблении воды за последний час может быть необходимо обратиться с GET-запросом по URL вида: http://m2m.operator.com/utility1/scls/meter12345/meteringApp/applications/meteringApp/containers/meterSamples/contentInstances/Day1H1/. При этом ETSI-шные стандарты как раз описывают, какую роль в M2M-взаимодействии играют имена scls/applications/containers/contentInstances в URL, что внутри ресурса с такими именами должно быть, как содержимое этого ресурса формируется и по каким правилам все это живет.

Смысла далеко зарываться в дебри ETSI-шных спецификаций у меня не было. Возможно, если долго повариться в этой теме, то ETSI-шный подход покажется разумным и оправданным. Но у меня возникло несколько сомнений.

Во-первых, мне показалось, что вся эта ETSI-шная кухня рассчитана не столько на реальное M2M-взаимодействие (т.е. когда устройство, скажем, счетчик, должен взаимодействовать с другим устройством, скажем, контроллером), сколько на то, чтобы специфицировать взаимодействие между внешним миром и приложениями, работающими наболее мощных устройствах (контроллеры, концентраторы, маршрутизатор и т.д.). Например, вам кто-то продает систему "умный дом", в которую входит центральный управляющий компьютер, несколько датчиков/счетчиков и управляющих устройств. А вы для управления этим хозяйством используете не родной софт от производителя системы умного дома, а стороннюю софтину для iPad-а, которая вам больше нравится. И как раз для того, чтобы софтина не была заточена под протокол конкретного производителя железа, и нужны ETSI-шные спецификации.

В принципе, идея M2M-стандартов должна быть в том, чтобы обеспечить интероперабильность не только между более-менее мощным железом и софтом, но и между совсем маломощными умными устройствами. Т.е. чтобы можно было собрать систему для своего умного дома не только из комплектующих от одного производителя, общающихся между собой посредством одного proprietary-протокола, но и из устройств разных производителей. Скажем, центральный компьютер для системы покупается у Siemens, счетчики электроэнергии у ABB, а счетчики воды и тепла у Sensus. Однако, что-то я слабо верю в то, что счетчик воды для обычной квартиры в скором времени станет достаточно мощным вычислительным устройством, способным поддерживать RESTful взаимодействие по протоколу HTTP, защищенному SSL/TLS, да еще и работающему на одной батарейке 15 лет.

Во-вторых, мне представляется, что вся эта тема взаимодействия с измерительными/управляющими устройствами, сбором и обработкой измерительной информации (т.е. поляна, на которой собираются топтаться ранее упомянутый Xively или AT&T со своей M2M-платформой), является давней вотчиной SCADA-систем. Но я уже больше 15 лет не имею отношения к SCADA (или АСУТП и ИИС, если говорить по-русски), поэтому не знаю, какие там сейчас тенденции, кто лидер, кто в чем специализируется и какие взгляды на M2M и IoT у производителей SCADA-систем и соответствующего промышленного оборудования. Может у них свой взгляд на происходящее и свое видение того, куда и как разные smart meters или industrial process automation должны развиваться в будущем.

В-третьих, вот чем мне в свое время нравились телекоммуникационные стандарты? Хотя бы GSM-овские спецификации, с коими пришлось плотно работать? Да тем, что берешь часть какого-нибудь стандарта (например, GSM 03.40, он же 3GPP TS 23.040) и реализуешь ее с нуля на чем хочешь и как хочешь. Всего-то и нужно, что уметь битики в байтиках правильным образом устанавливать. А вот нынешняя RESTful направленность M2M-стандартов означает, что базовые требования к реализации стандарта резко выросли. Нужно тебе обращаться к M2M-устройству? Изволь найти себе библиотеку для поддержки HTTP, не писать же HTTP-клиента с нуля. А если нужно не только самому обращаться, но и принимать M2M-запросы, то нужно еще и HTTP-сервер разворачивать.

Кто-то из читателей может воспринимать эти мои слова с недоумением, мол, в той же Java или .NET-е поддержка HTTP-клиента/сервера, если и не из коробки, то уж точно элементарно находится в Интернете. На что я могу возразить, что все это хорошо, пока речь идет о компьютерах/планшетах/смартфонах с гигагерцовыми процессорами и сотнями мегабайт RAM на борту, не сильно заморачивающихся потреблением электроэнергии. Если же нужно будет написать софтовую начинку для какой-то мелкой железяки с совершенно дохлым процессором и хотя бы с мегабайтом памяти на борту, питающейся от слабенькой батарейки, на которой нужно продержаться пять лет, то картина резко поменяется. Не будет в таком устройстве ни нормальной Java, ни нормального .NET-а, не говоря уже про Python-ы с Ruby. Некоторые могут вспомнить, какая была Java на SIM-картах с 16Kb памяти и что из себя представляло программирование на такой Java :)

Конечно, прогресс не стоит на месте и, возможно, лет через 10-15 рядовой счетчик воды будет иметь внутри 4-х ядерный процессор, 1GB RAM и очередную версию Windows. Почему бы и нет? Когда я в 2002-м покупал Palm m105, я не мог предположить, насколько сильно от него будет отличаться Samsung-овский Galaxy Note 3. А ведь и пятнадцати лет не прошло. Так что все может быть и, в долгосрочной перспективе, нынешняя заряженность ETSI-шных стандартов на HTTP-шный RESTful вполне может оправдаться. Однако, есть у меня подозрение в том, что лет через 10 REST уже не будет таким модным направлением, как сейчас (за примерами далеко ходить не нужно, достаточно посмотреть на тот же SOAP).

Должен сказать, что говоря о нацеленности M2M спецификаций на HTTP я излишне утрирую и передергиваю. M2M описывает стандарты своих интерфейсов (dIa, mId, mIa, mIm) как модель ресурсов, обращение к которым возможно не только по HTTP, хотя HTTP наверняка будет одним из главных протоколов, по крайней мере на высоком уровне, где вычислительные ресурсы это позволяют. Но кроме HTTP ETSI описывает возможность использования еще одного протокола, более компактного и приспособленного к работе на слабом железе -- это Constrained Application Protocol (CoAP), интересная штука, построенная на использовании UDP, а не TCP. Хотя, и CoAP может найти не такое уж и широкое применение, если вспомнить тот перечень проблем сотовых операторов, о котором я говорил выше: может быть огромная масса устройств, которые выходят на связь на очень короткий промежуток времени и передают считанные байты информации. Для таких устройств работа на основе распространенного сейчас IP вообще может быть невыгодна. И нужно будет использовать что-то другое. А вот что? Время покажет.

Итого

Что в итоге? Мне думается, что Internet of Things сейчас -- это маркетинговый булшит, каковым был лет шесть назад термин "облако". Что из этого получится в итоге нужно посмотреть. Мне лично кажется, что производители различных девайсов, гаджетов и сервисов будут придумывать свои, удобные для решения собственных задач, стандарты. А потом кто-то будет увязывать все это вместе и получится что-то совершенно новое. Как в свое время произошло с Internet-ом, HTTP и WWW. Если кто не знает, Internet появился до WWW и предназначался совсем не для того, чтобы постить селфи в Инстраграмме :)

А вот ETSI-шная M2M -- эта штука поинтереснее будет. Особенно, если операторы сотовой связи действительно начнут оптимизировать свое хозяйство под передачу небольших объемов данных от эпизодически подключающихся к сети устройств. И, не смотря на мое скептическое отношение к базирующимся на REST-е интерфейсам, специфицированным ETSI (речь о dIa, dIm, mIa, mIm), не удивлюсь, если эти штуки уже используются сейчас, когда это позволяют вычислительные ресурсы. Да и интерес к CoAP-у явно существует. Так что эта тема, полагаю, будет развиваться. Но вот насколько активно и в каком именно направлении -- это для меня вопрос.