На каком языке позволяет cooja писать программы для сетевых устройств

Беспроводные сенсорные сети (БСС) состоят из миниатюрных вычислителей — мотов, снабженных сенсорами (температуры, освещенности, давления и т.д.) и приемопередающими радио­устройствами. Поскольку размер мота должен быть небольшим, его питание осуществляется от маломощной батареи. Моты применяются для сбора и первичной обработки сенсорных данных, которые они передают друг другу.

Структура сенсорной сети формируется автоматически таким образом, чтобы в конечном счете все сенсорные данные были получены шлюзом, имеющим соединение с корпоративной сетью. Как уже отмечалось (см. КомпьютерПресс № 4’2008), современный технологический уровень развития БСС дает возможность перейти к практическому использованию сенсорных сетей, но для этого необходимо уметь разрабатывать программное обеспечение для мотов. В настоящее время для этой цели имеются специальные средства и даже технологии, к которым в первую очередь относятся операционная система TinyOS и язык программирования NesC.

TinyOS — это операционная система класса Open Source, разработанная специально для использования в БСС. Более того, TinyOS — первая ОС для БСС. Сама TinyOS написана на языке NesC, который разрабатывался именно для программирования приложений, ориентированных на работу в среде TinyOS, что позволило сделать работу программ, написанных на NesC, максимально эффективной. В связи с этим есть смысл сначала остановиться на принципах организации работы TinyOS, а затем перейти к конкретным инструментальным средствам языка NesC.

Full tutorial for Cooja Simulator in Contiki OS — Arabic

Операционная система TinyOS

TinyOS имеет компонентную архитектуру, при правильной компоновке обеспечивающую минимальный размер кода, что очень важно для сенсорных устройств, которые имеют строгие ограничения по объему памяти. Библиотека компонентов TinyOS включает сетевые протоколы, драйверы сенсоров и утилиты получения и сбора информации, которые могут быть усовершенствованы в клиентских приложениях. Реализованная в TinyOS событийная модель дает возможность управлять питанием на низком уровне, что позволяет экономить энергопотреб­ление. TinyOS перенесена более чем на дюжину аппаратных платформ и многочисленные сенсорные устройства.

TinyOS заметно отличается от ОС общего назначения, таких как UNIX, Windows и пр. Например, приложения для БСС не являются интерактивными в том же смысле, что и приложения для обычных ПК. Это объясняется тем, что TinyOS не нуждается во встроенной поддержке пользовательского интерфейса. К тому же ограничения в ресурсах памяти, с одной стороны, и аппаратная поддержка распределения памяти — с другой, делают такие механизмы, как виртуальная память, ненужными или даже невозможными в реализации.

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

Contiki cooja Simulator for beginners

Архитектура TinyOS включает две главные функциональные составляющие: планировщик задач и компонент. Понятие «компонент» в TinyOS несколько отличается от общепринятого. Так, интерфейс компонента TinyOS состоит из двух частей: верхней (upper), предоставляемой этим компонентом как провайдером, и нижней (lower), требуемой для его функционирования. Обе части содержат описания команд и событий.

Компонент имеет два основных элемента: набор команд и набор обработчиков событий. Кроме того, в каждом компоненте объявляются события, о которых он сигнализирует, и команды, используемые данным компонентом. Эти объявления применяются при компоновке для формирования конфигурации системы, настроенной на определенный класс приложений. Процесс компоновки распределяет компоненты по уровням, где каждый более высокий уровень посылает команды нижележащему уровню, а тот, в свою очередь, обращается к более высокому уровню с помощью сигналов о событиях. Аппаратное обес­печение является самым нижним уровнем в иерархии компонентов.

Использование статического распределения памяти позволяет определять требования к памяти на этапе компиляции и избегать накладных расходов, связанных с динамическим распределением памяти. Кроме того, такой подход позволяет сокращать время выполнения благодаря статическому размещению переменных во время компиляции вмес­то доступа к ним по указателям во время выполнения.

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

Обработчики событий прямо или косвенно имеют дело с аппаратными событиями. Самый нижний уровень компонентов содержит обработчики, непосредственно связанные с аппаратными прерываниями. Аппаратное событие инициирует процесс обработки, который распространяется вверх по уровням через события и может вернуться вниз с помощью команд.

Как и в остальных ОС, в TinyOS существуют атомарные потоки (task), которые выполняются вплоть до своего завершения, хотя и могут быть вытеснены событиями. С компонентом может быть связано более одного потока. Потоки могут вызывать команды нижележащего уровня, сигнализировать о событиях более высокому уровню и планировать другие потоки внутри компонента.

Семантика потока «выполнение вплоть до завершения» позволяет иметь один стек, который выделяется выполняющемуся в данный момент потоку, что очень важно в системах с ограниченной памятью. Потоки дают возможность имитировать параллельную обработку внутри каждого компонента, так как они выполняются асинхронно по отношению к событиям. Однако потоки не должны блокироваться или простаивать в ожидании, поскольку в таких случаях они будут препятствовать развитию обработки в других компонентах.

Язык программирования NesC

NesC (network embedded system C) — это компонентно-ориентированный язык программирования, построенный на базе C. Основной структурной единицей программы на NesC является компонент, который через интерфейсы взаимодействует с другими компонентами. Интерфейсы в NesC двунаправленны, они определяют способы взаимодействия между двумя типами компонентов: пользователями и провайдерами. Интерфейсы могут содержать объявления команд и событий. Реализации команд должны быть описаны в компоненте-провайдере, а реализации обработчиков объявленных в интерфейсе событий — в компоненте-пользователе:

command result_t send(uint16_t address, uint8_t length, TOS_MsgPtr msg);

event result_t sendDone(TOS_MsgPtr msg, result_t success);

В приведенном примере представлена часть стандартного интерфейса SendMsg для отправки сообщения в сеть. Компонент-провайдер этого интерфейса предоставляет команду send, которой может воспользоваться компонент-пользователь для отправки сообщения, а после отправления сообщения компонент-провайдер вернет компоненту-пользователю сигнал о событии sendDone, значением параметра которого будет результат операции отправки сообщения (см. рисунок).

В NesC существует два типа компонентов: модули и конфигураторы. Модули описывают действующие механизмы компонента: команды, которые он предоставляет, и обработчики событий.

Обычно разработка модулей не вызывает больших сложностей, если разработчик знаком с программированием на стандартном языке С. Конфигураторы описывают связи между интерфейсами других компонентов, а также могут предоставлять свои интерфейсы (экспортировать интерфейсы). Несмотря на то что при реализации конфигуратора используется весьма простой язык, содержащий всего три оператора: «->», «

Описание любого компонента в NesC, будь то конфигуратор или модуль, состоит из двух секций: интерфейсной и секции реализации.

Интерфейсная секция компонента содержит объявления команд, событий и интерфейсов (в дальнейшем команды, события и интерфейсы мы будем называть одним общим термином — функции), которые использует или предоставляет компонент. Если компонент использует функцию, на это указывает зарезервированное слово uses, если предоставляет — provides. Эта секция также может быть пустой, что свойственно конфигураторам, или содержать объявления только используемых или только предоставляемых функций. Взаимодействие с другими компонентами осуществляется через объявленные функции.

Приведем пример описания модуля, поставляемого вместе с TinyOS:

Источник: compress.ru

Предисловие

Когда я впервые столкнулся с необходимостью написать приложение, которое могло бы взаимодействовать с таким же приложением, запущенным на другом компьютере, я был неприятно удивлен дефицитом полезной русскоязычной документации по этому делу. Конечно, я знал английский, и для меня не составило особого труда разобраться в тонкостях сетевого программирования, но что делать человеку который не знает ничего кроме русского («русский язык велик и могук!» :))? Ответа нет. И даже если он знает английский язык, то поначалу это ему не очень-то поможет. Лично я не видел еще ни одного систематизированного и каталогизированного источника информации о программировании сетевых приложений, который бы в той или иной степени охватывал весь этот огромный хаос.

Итак, уже сделано все, что касается однопользовательских режимов игры, однако было бы неплохо добавить возможность игры по сети. И ты, конечно, даже и не представляешь, с чего начать. С Интернетом ты ранее сталкивался только в двух случаях: форум на gamedev.ru и навязчивые pop-ups от порносайтов. Хорошо, я тебе помогу, вернее, тебе поможет мой CGNP.

Для того чтобы не было недоразумений, я сразу оговорюсь, что написанное ниже рассчитано на тех, кто кодит на с/с++ (MSVC++ в Windows-системах и gсс/g++ в никсах). Я также предполагаю, что у читателей есть хотя бы минимальный набор знаний об устройстве и функционировании компьютерных сетей. Необязателен, но желателен справочник по Windows API 32 под рукой или доступ к MSDN (юниксоидам в этом плане повезло — man pages не могут быть «не под рукой» ;)). Еще я хотел бы сделать предупреждение: представленный ниже материал не претендует на полноту освещения затронутых в нем тем, а также на абсолютную точность.

И наконец, перед тем, как мы окунемся в омут с головой, я дам еще один совет: дружище, выучи все-таки английский! Он тебе очень пригодится. Ведь когда ты захочешь стать гуру сетевого программирования, тебе придется прочесть очень много RFC-документов, а ошибки перевода и неправильного толкования технических спецификаций являются «бомбами замедленного действия»!

Модель OSI

Чтобы понять все принципы взаимодействия компьютеров на расстоянии, надо знать так называемую модель OSI (ISO OSI == International Organization for Standardization Open System Interconnection — Взаимодействие Открытых Систем по Стандарту Международной Организации по Стандартизации). Теперь можем сделать перерыв, чтобы ты, уважаемый читатель, смог еще пять раз перечитать предыдущее предложение и понять его смысл, после чего мы разберемся, что такое OSI, и с чем ее едят.

Итак, модель OSI определяет несколько «уровней» взаимодействия компьютеров на расстоянии (я намеренно избегаю словосочетания «по сети», и ты скоро поймешь почему). Вот эти уровни:

7. Прикладной

Это уровень, максимально приближенный к пользовательскому интерфейсу. Пользователи конечного программно продукта не волнует, как передаются данные, зачем и через какое место. Он сказали «ХОЧУ!» — а мы, программисты, должны им это обеспечить. В качестве примера можно взять на рассмотрение любую сетевую игру: для игрока она работает на этом уровне.

Пользователь куда то ткнул, в интерфейсной части программы зафиксирована его команда. Что надо передать? Что то приняли, что произошло в мире игры?

6. Представительский

Здесь программист имеет дело с данными, полученными от низших уровней. В основном, это конвертирование и представление данных в удобоваримом для пользователя виде.

5. Сеансовый

Этот уровень позволяет пользователям осуществлять «сеансы связи». То есть именно на этом уровне передача пакетов становится для программиста прозрачной, и он может, не задумываясь о реализации, непосредственно передавать данные, как цельный поток. Здесь на сцену вступают протоколы HTTP, FTP, Telnet, SMTP и т.д.

4. Транспортный

Осуществляет контроль над передачей данных (сетевых пакетов). То есть, проверяет их целостность при передаче, распределяет нагрузку и т.д. Этот уровень реализует такие протоколы, как TCP, UDP и т.д. Для нас представляет наибольший интерес.

Логически контролирует адресацию в сети, маршрутизацию и т.д. Должен быть интересен разработчикам новых протоколов и стандартов. На этом уровне реализованы протоколы IP, IPX, IGMP, ICMP, ARP. В основном, управляется драйверами и операционными системами. Сюда влезать, конечно, стоит, но только когда ты знаешь, что делаешь, и полностью в себе уверен.

2. Канальный

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

1. Аппаратный (Физический)

Контролирует передачи представление битов и служебных сигналов физическими процессами и отправку физических сигналов между аппаратными устройствами, входящими в сеть. То есть управляет передачей электронов по проводам. Нас он не интересует, потому что все, что находится на этом уровне, контролируется аппаратными средствами (реализация этого уровня — это задача производителей хабов, мультиплексоров, повторителей и другого оборудования). Мы не физики-радиолюбители, а геймдевелоперы.

Итак, подведем небольшой итог к тому, что было представлено. Мы видим, что, чем выше уровень — тем выше степень абстракции от передачи данных, к работе с самими данными. Это и есть смысл всей модели OSI: поднимаясь все выше и выше по ступенькам ее лестницы, мы все меньше и меньше заботимся о том, как данные передаются, мы все больше и больше становимся заинтересованными в самих данных, нежели в средствах для их передачи. Каждый следующий уровень скрывает в себе предыдущий, облегчая жизнь пользователю этого уровня, будь он программист, радиоинженер или твоя подруга, которая не знает, как настроить MS Outlook Express.

Нас, как программистов, интересуют уровни 3, 4 и 5. Мы должны использовать средства, которые они предоставляют, для того чтобы построить 6 и 7 уровни, с которыми смогут работать конечные пользователи.

Сокеты и бла-бла-бла.

У каждой уважающей себя современной операционной системы есть средства для взаимодействия с другими компьютерами. Самым распространенным среди программистов средством для упомянутых целей являются сокеты. Сокеты — это API (Application Programming Interface — Интерфейс Программирования Приложений) для работы с уровнями OSI. Сокеты настолько гибки, что позволяют работать почти с любым из уровней модели OSI. Хочешь — формируй IP-пакеты руками и займись хакингом, отправляя «неправильные» пакеты, которые будут вводить сервера в ступор, хочешь — займись более благоразумным делом и создай новый удобный голосовой чат, хочешь — игрульку по сети гоняй, не хочешь — твое право, но этот случай мы в данном руководстве не рассматриваем. 🙂

Когда мы создаем сокет (socket — гнездо), мы получаем возможность доступа к нужному нам уровню OSI. Ну а дальше мы можем использовать соответствующие вызовы для взаимодействия с ним. Для того чтобы понять сокеты, можно провести аналогию с телефонным аппаратом и телефонной трубкой.

Сокеты устроены таким образом, что они могут взаимодействовать с ОС на любом уровне OSI, скрывая ту часть реализации, которой мы не интересуемся (тебя же не волнует, как работает телефон, когда ты набираешь 03). Телефоны и сокеты бывают разные: бывают старые телефоны с дисковым набором и бывают низкоуровневые сокеты для работы с Ethernet-фреймами, бывают супер-модные цифровые телефоны и бывают сокеты для работы с верхними уровнями стека протоколов. и т.д.

Причем вызовы для всех типов сокетов одни и те же, что, имхо, очень удобно. Когда мы создаем сокет, мы также заставляем систему организовать два канала: входящий (это как громкоговоритель у телефона) и исходящий (микрофон).

Осуществляя чтение и запись в эти каналы, мы приказываем системе взять на себя дальнейшую судьбу данных, т.е. передать и проследить, чтоб данные дошли вовремя, в нужной последовательности, не искаженные и т.п. Система должна давать (и дает) максимум гарантий (для каждого уровня OSI — гарантии свои), что данные будут переданы правильно.

Наша задача — поместить их в очередь, а на другом конце — прочитать из входящей очереди и обработать должным образом. Все остальное — нам ни к чему. Еще один плюс — сокеты переносимы. То есть изначально концепция сокетов была разработана в Berkeley, поэтому классическая реализация сокетов называется Berkeley sockets или BSD sockets (BSD == Berkeley Software Distribution).

В дальнейшем, почти все ОС тем или иным образом унаследовали эту реализацию. В каждой ОС степень поддержки сокетов разная, но точно могу сказать: в современных операционных системах MS и *nix — сокеты поддерживаются настолько, насколько нам, геймдевелоперам, они могут понадобиться. Больше нам и не нужно, потому что мы не кодим под экзотические ОС, потому что, в свою очередь, геймеры (они наша целевая аудитория) на таковых не сидят. Однако по мере изучения мы будем придерживаться классической реализации BSD sockets, и стараться по минимуму использовать системно-зависимый код.

Короче, сокеты надо представлять себе так: сокет — это окно в мониторе, которое выходит во внешний мир. Если у кого-то еще открыто такое же окно, то можно контактировать. Ну что? Если вы уже достаточно раскочегарились, уважаемые читатели, то пора к делу.

Страницы: 1 2 3 Следующая »

18 мая 2003 (Обновление: 20 янв 2011)

Источник: gamedev.ru

Разработка для «интернета вещей»: языки программирования, операционки и каналы связи

Разбираемся, на чём кодят IoT, как выбрать язык программирования для проекта и что популярнее — провода или эти ваши хипстерские вайфаи.

Иллюстрация: Оля Ежак для Skillbox Media

Мария Даровская

Журналист, коммерческий автор и редактор. Пишет про IT, цифровой маркетинг и бизнес.
Сайт: darovska.com.

Интернет вещей (Internet of Things, IoT) — это когда вещи и предметы физического мира могут взаимодействовать между собой напрямую, не требуя вмешательства человека.

Простой пример — холодильник, который сам следит за количеством молока и других продуктов и делает заказ в интернет-магазине, когда они заканчиваются. Или умная колонка, которая связана с датчиками протечки, задымления и другими девайсами в вашем доме и способна управлять ими и снимать с них показания.

Архитектуру IoT-решений принято делить на четыре уровня:

• датчики, которые собирают данные: например, датчики протечки, движения, освещения и тому подобные, подключённые к микроконтроллеру;
• локальные шлюзы — устройства, которые передают и обеспечивают обмен данными;
• Edge Servers — граничные серверы, которые хранят, аккумулируют и обрабатывают данные непосредственно там, где информация производится (например, это могут быть производственные помещения);
• облачная инфраструктура.

Компании, которые занимаются разработкой IoT-устройств и решений, нередко разрабатывают как и сами устройства, так и всё ПО для всех четырёх уровней устройств. Исключение — компании, которые собирают отдельные датчики или девайсы для уже готовых экосистем и стандартов, поддерживаемых крупными вендорами. «Железо» и различные архитектуры мы почти не затронем — подробности об этой стороне IoT можно узнать в выпуске нашего подкаста «Люди и код», посвящённом микроконтроллерам.

На чём программируют интернет вещей

Так как архитектура интернета вещей состоит из четырёх уровней, для программирования под каждый из них разработчики выбирают свои технологии. Согласно исследованию Eclipse Foundation от декабря 2021 года, в IoT наибольшей популярностью пользуются такие языки:

• Лидеры на встраиваемых устройствах и микроконтроллерах — C, C++, Java и Python.
• Для программирования шлюзов чаще всего выбирают Python, C++, C и Java.
• Для серверной разработки предпочтение отдают Python, Java, C++ и C.
• В облаках — Python, Java, JavaScript, C++.

«В разработке IoT-устройств всё делается с применением стандартных подходов — подводных камней нет, и всё более-менее предсказуемо. Выбор конкретного языка программирования чаще всего зависит от удобства и принятых стандартов, но на безопасность почти не влияет».

Python

Примечательно, что по итогам 2021 года явным лидером стал Python — хотя за год до этого в топе был Java. Это, кстати, интересный тренд: в том же рейтинге популярности языков программирования TIOBE в 2021 году Python наконец-то сумел обойти Java и C — фактически бессменных лидеров последних десятилетий.

«Python прост в освоении и поддерживается большим отзывчивым сообществом. Его синтаксис чистый и простой, что привлекает большое количество программистов. Поэтому Python часто выбирают социологи и биологи — чтобы программировать лабораторные устройства. А ещё это предпочтительный язык для одного из самых популярных микроконтроллеров на рынке — Raspberry Pi».

Кинман Кови,
разработчик микроконтроллеров

Рост популярности Python вполне понятен: это удобный и быстрый с точки зрения написания кода язык с кучей библиотек почти под каждую задачу (особенно силён в сфере машинного обучения и работы с данными), он прекрасно взаимодействует со многими языками программирования (недаром его часто называют «клеем» среди языков программирования). Кроме того, устройства с каждым годом становятся всё мощнее и вопрос оптимизации стоит уже не так остро, как вопрос скорости разработки и поставки ПО.

Если проект простой и не требует больших вычислительных мощностей, можно использовать стандартные библиотеки Python, а вот для микроконтроллеров стоит посмотреть на пакет MicroPython — он подходит для запуска Python на небольших платах с 256 КБ памяти и 16 КБ оперативки и площадью в пару квадратных сантиметров.

Хотя вполне очевидно, почему в нише микроконтроллеров и встроенных устройств позиции Python не так прочны — здесь гораздо выше требования к скорости исполнения, энергосбережению и экономному расходованию памяти. Конечно, в таких условиях Python и MicroPython уступают более скоростным C, C++ и Java.

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

Иван Игнатьев,
Cloud Solution Architect из Pluto Informatics

C++

Второе место можно отдать «плюсам» — всё-таки ещё не перевелись любители пощекотать себе нервишки 🙂 Его часто используют на одноплатных компьютерах типа Raspberry Pi — он быстрый, как C, но при этом разработка на нём, как правило, занимает меньше времени.

Java

Сила Java — в переносимости и принципе write once, run anywhere. Если виртуальная Java-машина (JVM) поддерживает какую-то архитектуру, вы обычно можете быть уверены, что ваш код будет на ней работать так же, как и на других платформах.

Кроме того, Java — это классический ООП-язык, удобный для энтерпрайз-решений, с большим набором библиотек и инструментами для работы с безопасностью, а байт-код и сама Java-машина за долгие годы были оптимизированы и могут исполняться с достаточно хорошей скоростью.

«Какой язык использовать в проекте, зависит от юзкейсов. Например, есть задача — определить заполняемость мусорных баков в городе. Для этого внутри них ставят датчики и следят за наполнением. Датчик в этом случае должен быть как можно менее энергозатратный, так как мы не можем подключить каждый мусорный бак к розетке или регулярно ездить и менять в них батарейки. Поэтому для таких задач используются языки более низкого уровня вроде C или предназначенного для встроенных систем Java Embedded».

Иван Игнатьев,
Cloud Solution Architect из Pluto Informatics

C

Да, этот старичок ещё очень популярен во встраиваемых системах и в качестве средства для системного программирования — где-то в силу традиций и накопленной большой кодовой базы на C, которую пока невозможно (да часто и не нужно) перевести на более современные языки, где-то в силу его скорости и других плюсов. К тому же благодаря C разработчик может напрямую взаимодействовать с памятью и любым «железом» — не зря C называют «переносимым ассемблером».

«У меня был проект промышленного IoT с „Роснефтью“ с системой предиктивной (предсказательной) аналитики. С помощью датчиков она определяла, сколько нефти проходит через весы, а сколько попадает в хранилища, а потом анализировала, сходятся ли эти данные, нет ли издержек. Датчики весов подключались к интернету и передавали данные на сервер. Софт для них был написан на C».

Алексей Барышников,
Java-/JS-разработчик

JavaScript

JavaScript тоже используют в IoT. Причём не только для веб-интерфейса приложений, но и для софта серверов. А в сочетании с фреймворком Node.js — ещё и для датчиков, серверов и шлюзов на ОС Linux. Например, построить софт на Node.js удалось в микроконтроллерах производителей Espruino и Tessel.

«Если объект можно запитать от солнечной панели или другого внешнего источника, то обычно в IoT используют Python, MicroPython, JavaScript и Node.js».

Иван Игнатьев,
Cloud Solution Architect из Pluto Informatics

LUA

Этого языка (как и последующих) нет в топе исследования, однако он часто упоминается в связи с IoT. Фишка языка — он специально был разработан для поддержки средств описания данных, у него есть особый фреймворк Node.lua, то есть порт, или аналог, Node.js в LUA-мире, к тому же построенный на облегчённом интерпретаторе LUA.

Go

У Go богатая стандартная библиотека, отличная работа с параллелизмом из коробки, и его популярность в мире постоянно растёт.

«Golang в основном заменяет JavaScript/Node.js для серверных HTTP-приложений. На мой взгляд, он гораздо лучше JavaScript. Golang можно использовать и в других компонентах IoT, но, по моему опыту, он для этого не очень подходит. Часть кода используется в высокоуровневых программах, а часть должна работать на низком уровне — ближе к „железу“. В IoT хватает и того, и другого.

И вот для низкоуровневой работы Go практически не годится. Он некрасиво обрабатывает данные, а использование указателей — так и вообще устаревший подход. Короче говоря, для работы с протоколами он не подходит. Конечно, даже несмотря на это в подобных задачах он ещё лучше Java, но гораздо хуже C. А если вас пугает сложность C и вы думаете, чем бы его заменить, — лучше обратите внимание на Julia».

JP Norair,
IoT-разработчик, комментарий на Quora

PHPoC

Это особая версия PHP для работы с чипами. Удобна для тех, кто уже знает PHP и хочет заняться интернетом вещей. Плюс в этом диалекте из коробки есть средства, полезные для разработки под IoT. К тому же более 90% серверов в мире по-прежнему работают на PHP, поэтому этот язык также популярен в интернете вещей и применяется для управления микросервисами на базе Linux.

Swift

Swift используется для создания приложений для умных устройств в экосистеме Apple. У Swift собственные библиотеки для платформы HomeKit, которая обеспечивает поддержку интеграции каналов данных из сети совместимых устройств.

Какие операционные системы и каналы связи используют в IoT

Использование операционных систем, как и в случае языков программирования, определяется тем, с какой частью архитектуры вы работаете (но надо понимать, что для уровня микроконтроллеров и встраиваемых устройств операционная система — необязательный компонент).

Во встраиваемых устройствах, шлюзах и микроконтроллерах самым популярным выбором является Linux (в основном урезанные или специфические версии — из «обычных» линуксов более-менее популярен разве что CentOS). Linux — гибкая и свободная ОС, которую можно «доработать напильником» практически под любые нужды, которая умеет запускаться на множестве разных архитектур. Плюс у него огромное сообщество и куча готового софта почти под любые задачи (разве что с Photoshop и Microsoft Office проблемы — но кому они нужны в IoT).

«Для всего, что можно воткнуть в розетку, существует операционная система Linux. В качестве use case может быть определение безопасности закрытия дверей в поезде. Для этого используют обычные компьютеры, которые соединены с датчиками по проводу или с помощью Bluetooth.Чтобы эта система работала, нужно полноценное питание и интернет-соединение. Приложения для умного дома можно писать на чём угодно — в серверных используют файрволы, роутеры и хранилища App Storage для загрузки файлов. Для написания приложений существует множество open-source-проектов, в основном построенных на PHP».

Иван Игнатьев,
Cloud Solution Architect из Pluto Informatics

За Linux следует FreeRTOS — операционка реального времени, созданная специально под микроконтроллеры. А значит, она умеет экономно использовать даже самые скромные ресурсы. Особенность систем реального времени — они заранее гарантируют, что задача будет выполнена в конкретные сроки. То есть работают максимально предсказуемо, что особенно важно для обработки критических запросов в военной или космической промышленности, а также везде, где от точной до миллисекунды обработки задачи зависят жизни людей или работоспособность дорогостоящего оборудования. Кстати, Linux так не умеет.

На третьем месте с большим отрывом — Windows. Все мы работали с терминалами оплаты или банкоматами, в которых нередко используется именно система от Microsoft. Это закрытая и гораздо менее гибкая система, и подходит она только для тех устройств, в которых достаточно много свободных ресурсов.

На четвёртом месте Zephyr — ещё одна свободная операционка реального времени, созданная специально для работы со встраиваемыми устройствами и микроконтроллерами.

А вот на серверах и в облаках ситуация отличается — хотя в рейтинге всё так же присутствуют Linux (лидирует с большим отрывом) и Windows. Кроме того, достаточно популярен майкрософтовский вариант Linux — Azure Sphere. Неудивительно — на ней строится Azure, а это один из лидеров в мире среди облачных платформ. Четвёртое место скромно заняла FreeBSD, ещё одна свободная операционка, которая традиционно считается более надёжной и безопасной, чем Linux.

Среди каналов связи, конечно же, лидирует классический Ethernet — проводной, надёжный, стабильный и предсказуемый. Он обеспечивает самые большие скорости и может быть почти «бесплатным» с точки зрения энергопотребления.

Из беспроводных технологий наибольшей популярностью пользуется Wi-Fi — его можно развернуть относительно дёшево, не нужно использовать базовые станции, привязанные к операторам связи, у него отличная скорость, и он может покрывать относительно неплохое расстояние.

Чуть менее популярны сети сотовой связи. Их плюс — они уже есть на куче смартфонов, могут обеспечить хорошую зону покрытия и работают на больших расстояниях. То есть удобны там, где нет проводов, а Wi-Fi просто «не добивает».

Bluetooth на четвёртом месте — у него достаточно низкая скорость передачи данных, он не так стабилен в работе, и у него серьёзные ограничения по расстоянию между устройствами. Зато он экономнее в потреблении электроэнергии, чем Wi-Fi и сотовые сети связи.

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

Для передачи данных использовали DSL-линию — с её помощью выгружали Python-скрипты. Скрипты использовали для построения прогнозных моделей по объёмам производства нефти на заводе в Сочи. Для отображения моделей в единой ноде использовали Node.js и React, Polymer и Angular. С их помощью строили таблицы и графики из уже посчитанных дата-сайентистами данных, а также сырых данных, выгружаемых из Data Lake.

Конечный результат проекта — интерактивная карта в формате SVG, на которой отмечены точки с заводами „Роснефти“».

Алексей Барышников,
Java-/JS-разработчик

Заключение

Мир IoT — это наше будущее, а значит, разработка ПО для интернета вещей будет всё более востребованным занятием. Если вы уже кодите на Python, PHP, Java, Go или JS — попробуйте вкатиться в эту сферу через них. Python будет лучшим выбором для тех, кто ещё не знаком с программированием. А если вы хотите напрямую поработать с «железом» и памятью — обратите внимание на C/C++.

• Toit открывает исходный код своего языка для IoT-устройств
• Тест: ИИ на столе — пересол на спине. Распознай, какое блюдо придумал компьютер
• Всё о Java: экосистема, популярные фреймворки, системы сборки, JDK, JVM и будущее языка

Источник: skillbox.ru