Привет, Geektimes!
Совсем недавно мы — Mail.Ru Group, Intel и Unwired Devices — делали хакатон по Интернету вещей. В принципе, это могло бы быть рядовым событием — хакатоны по IoT сейчас не делает только ленивый. Но мы решили придумать формат, который выгодно отличал бы нас от других подобных мероприятий.
И если отбросить излишнюю скромность, то можно сказать, что этим хакатоном мы начинаем новую серию мероприятий по IoT — мероприятий, на базе которых мы хотим сформировать площадку для обсуждения современных IoT-технологий, на которой будут присутствовать не только энтузиасты, но и разработчики самих технологий, представители индустрии и инвесторы, заинтересованные в тематике Интернета вещей.
Ничтожная часть выпитого за два дня кофе
Начали же мы с хакатона. И теперь хотим рассказать вам, почему мы его сделали, что получилось и какие выводы мы извлекли.
Что же нам не нравилось в типичных IoT-хакатонах? В первую очередь то, что в них, как правило, нет IoT как такового — в том виде, в каком его понимают в промышленности, ЖКХ или даже умном доме. К сожалению, в образовательном IoT (а хакатоны можно отнести к образовательному сегменту) сейчас царит вакуум. Если в умном доме живут и здравствуют Z-Wave и ZigBee, промышленность с интересом смотрит на 6LoWPAN, а ЖКХ планирует переезжать на LoRa, то на среднестатистическом хакатоне вам, скорее всего, предложат написать что-нибудь для железки с обычным Wi-Fi. В среде разработки Arduino или подобной. С аналитикой и визуализацией — и это будет единственная серьёзная часть такого мероприятия — в облаке ThingWorx, Azure или подобном.
Да, даже на таких платформах можно отработать различные программные решения и сделать наброски IoT-сервисов, но вообще говоря, всё то же самое можно отработать и на обычном ноутбуке. Если вам надо показать, как вообще можно данные с какого-нибудь электросчётчика отправлять в облако, то одинаково подойдёт и Raspberry Pi, и ноутбук. А если вам эти данные надо отправлять с каждого из 236 электросчётчиков настоящего многоквартирного дома — и Raspberry Pi, и ноутбук для этого одинаково не подойдут. То есть, между ноутбуком и RPi в такой задаче есть количественная разница, но никак не качественная.
Мы решили это изменить и организовать хакатон на тех IoT-технологиях, которые не просто используются в промышленности сегодня, а будут использоваться завтра. И аппаратных, и программных.
Вторая проблема многих хакатонов — это замкнутые, герметичные мероприятия, в которых на входе команды получают некие наборы и инструкции, а на выходе — призы. Часто больше ничего не происходит: ни до, ни после, ни во время (за исключением, конечно, написания командами кода). Это мы тоже решили изменить — и, как я сказал выше, превратить хакатон в площадку, на которой есть и команды, и разработчики собственно базовых технологий, и представители индустрии, и инвесторы, заинтересованные в тематике IoT.
С точки зрения технологий интернет вещей распадается на три направления:
Из этих трёх подсистем мы решили предоставить участникам хакатона… разумеется, все три!
Фактически, на таких компонентах вполне можно построить беспроводную SCADA-систему какого-нибудь объекта — от офисного здания до заводской площадки (особенный интерес в промышленности беспроводные SCADA вызывают применительно к открытым площадкам: если в здании ещё можно худо-бедно проложить слаботочку и гонять по ней старый добрый RS-485 + Modbus, то в каком-нибудь карьере это просто невозможно, а на какой-нибудь крупной подстанции или станции водоочистки — хоть и возможно, но совершенно негуманно по деньгам).
За тем, как используемые технологии влияют на содержание хакатона, было интересно смотреть уже на примере списка участников: к началу мероприятия в нём чётко сформировались три основные категории.
Первая — классическая: команды, в том числе и студенческие, у которых есть свой проект, и они хотели бы попробовать в рамках хакатона его развить. Впрочем, и здесь список доступного оборудования и ПО уже оказал влияние: некоторые из команд прямо попросили принести им те или иные модули, например, GPS или акселерометр.
Вторая — профессиональные разработчики, которым было интересно размять руки, а заодно поупражняться с новыми для них вещами, будь то работа с MQTT и «беспроводкой» или же с Tarantool.
Третья — команды из бизнеса, не обязательно как-то связанного с IT, но интересующегося теми технологиями, которые мы давали участникам хакатона. Например, была команда из успешного агрохозяйства, занимающегося круглогодичным выращиванием зелени. По их собственному признанию, их интересовал не столько сам процесс создания чего-то за два дня, сколько само по себе личное знакомство с современными технологиями. Круглогодичное агрохозяйство в наших широтах — дело хлопотное, требующее непрерывного контроля климата, полива и освещения (для меня, например, стало новостью, что у некоторых растений есть суточные циклы, и светить на них одними и теми же люменами 24 часа в сутки — не лучший способ их выращивать), и многие такие хозяйства сейчас присматриваются к технологиям беспроводного мониторинга и автоматического управления теплицами.
В целом получилась интересная смесь: команды из первой группы продвинули свои проекты, команды из второй показали первым, как надо работать профессионально и целенаправленно, а с третьей было о чём пообщаться и нам, и некоторым из инвесторов — им тоже интересно, какие технологии интересны с точки зрения потенциальных заказчиков.
На первый хакатон мы не приглашали целенаправленно представителей индустрии, хотя в результате пришли и они, и не только в составе команд.
В дальнейшем нам крайне интересно развивать сотрудничество с потенциальными заказчиками того, что на хакатоне могут сделать различные команды — вплоть до формата, при котором хакатон проводится под руководством одного крупного заказчика, который в качестве вводных данных предлагает командам свои бизнес-проблемы, требующие решения. Преимущества для заказчиков здесь очевидны, а для команд же это — прекрасный случай пообщаться с людьми, представляющими реальный бизнес и знающими о его реальных проблемах, причём не только тех, которые команда собралась решать, но и тех, которые на пути этого решения возникнут.
На самом деле, такой информации часто не хватает даже вполне оформившимся (но ещё не вышедшим на большой рынок) стартапам. Даже при хорошо проработанной технологической основе они часто не осознают, какой объём экономических, юридических и политических проблем их может ожидать впереди. И для нас было бы крайне интересно дать им фидбек от бизнеса, причём фидбек настоящий, иногда даже злой, а не формальное «молодцы, отличный проект, трудитесь дальше».
Здесь, конечно, существует опасный разрыв между реальностью бизнеса и реальностью хакатона: первый ожидает увидеть законченное решение в красивой коробочке и с поставкой 10 рабочих дней с момента оплаты, второй же показывает сделанную за два дня и одну ночь конструкцию из проводков и костылей, от которой постоянно что-то отваливается. Но как показывает практика, если подходить к делу с умом — и бизнес можно научить понимать, чем заняты стартапы.
Если говорить про инвесторов, то, конечно, с одной стороны, проекты хакатона — не венчурный материал, разве что какой-нибудь случайно забредший ангел возьмёт под крыло. С другой — инвесторы интересуются положением вещей в самой по себе отрасли, им бывает интересно посмотреть и послушать, о чём в принципе думают начинающие команды, а иногда и проследить за их судьбой.
Например, наш хакатон, хоть и проходил в нерабочее время — финал был вечером воскресенья — посетили представители CommIT Capital, ФРИИ, Сколково и другие. Беседовали со многими, контакты некоторых команд попросили им передать.
Каждая команда по итогам двухдневной работы делала 6-минутный доклад о своей разработке — и после двух часов докладов (два десятка команд плюс перерывы на кофе, чтобы все желающие успели с только что доложившейся командой пообщаться подробнее) жюри удалилось на совещание.
Жюри мы собрали из представителей всех трёх организаторов — и сразу отказались от системы простого подсчёта баллов, когда каждый член жюри что-то ставит каждой команде, а потом оценки суммируются. Основным возражением против такой системы было то, что один член жюри будет ставить за артистизм, другой за технику — и получится средняя температура по больнице.
Подтвердилось это полностью: с первой же минуты обсуждения проектов жюри разделилось на три части. У представителей Mail.Ru Group перевешивала техническая сторона реализации проекта, у представителей Intel — коммерческая, ну а мы были где-то посередине, хотя и со склонностью к коммерческой стороне. В результате вместо формального сухого голосования вышла оживлённая дискуссия: если отсеять однозначных аутсайдеров получилось единогласно, то лидеры, а уж тем более распределение мест между ними менялись в ходе обсуждения несколько раз.
Что мы учитывали:
Собственно, о поиске баланса между первым и третьим пунктом и шла основная дискуссия. С одной стороны, хакатон — это конкурс по написанию кода; с другой, мы, во-первых, устраиваем нечто большее, чем обычный хакатон, а во-вторых, среди участников есть профессиональные команды — и при учёте только написанного кода можно сразу все призы отдать им.
Кроме того (и в этом отличие от механизированной системы суммирования баллов), выбить команду из числа финалистов мог провал по любому из пунктов. Например, даже самой красивой презентацией невозможно было спасти команду, не использовавшую Tarantool или, например, потратившую львиную долю времени на обсуждение бизнес-моделей вместо написания кода.
Первое место — проект «Агрогенез»: система мониторинга для сельского хозяйства (нет, не та, о которой речь была выше, та называлась «ГудФарм» — IoT в с/х вообще становится очень популярен). Команда, быстро попавшая в список победителей и расколовшая жюри надвое при попытках договориться о её месте в нём: с одной стороны, видно сложившуюся команду и проект, над которым она работала до хакатона и явно продолжит после, с другой — на хакатоне было сделано не очень много, и часто требовалась помощь разработчиков с нашей стороны.
Второе место — команда «Cool-IoT» с проектом беспроводных датчиков для спортзала: тренажёры (вплоть до гантелей) оснащаются акселерометрами и другими датчиками, позволяющими собирать статистику о количестве подходов, поднятом весе и т.п. Подобными системами оснащаются современные тренажёры, однако они весьма недёшевы, и многим спортцентрам просто не по карману. Команда за два дня сделала прототип гантели с акселерометром (за отсутствием чугуния — в виде пластмассовой коробки), который действительно сбрасывал данные по количеству подъёмов этой гантели по 6LoWPAN в Tarantool, а последний даже отображал их в веб-интерфейсе. Немного подвела команду презентация: было мало сказано про возможные детали реализации и коммерциализации, а потому у части членов жюри возникли сомнения, что такой проект технически и коммерчески возможен.
Синяя коробочка — гантель, хотя так и не очень похожа
Третье место — проект «ColorControl», умная лампа, цвет освещения которой меняется в зависимости от произносимых рядом слов: скажете «глубокий океан» — лампа плавно сменит цвет на синий, скажете «пустыня Сахара» — на жёлтый. Проект не использовал сеть 6LoWPAN: речь обрабатывалась на Intel Edison с распознаванием через Google API. У команды была отличная презентация с рассказом о том, какую атмосферу способна создать такая лампа, например, при чтении сказки детям на ночь, но немного подвело использование исключительно сторонних облачных сервисов для основной обработки данных и непонятные перспективы коммерциализации: такая лампа интересна как отдельный продукт, но вряд ли вокруг неё получится построить бизнес.
В общем, как вы видите, выбрать победителей было действительно трудно. Даже сейчас, когда я пишу описания проектов, начинают закрадываться мысли, что ведь и другое распределение мест можно было тоже убедительно обосновать. В целом, была бы наша воля, я думаю, всё жюри согласилось бы просто дать 5-7 лучшим проектам по первому месту каждому.
Основной вывод из хакатона: в следующий раз требуется ещё больше подготовки с нашей стороны. Фактически, команды получили в своё распоряжение две аппаратные и три программные платформы, которые стыкуются друг с другом и ни с одной из которых у многих не было опыта. Поэтому часто было даже трудно с первого подхода понять, в какой именно части всей системы вылезает проблема: в 6LoWPAN-модулях, в нашем ПО на Edison, в Yocto Linux, в Tarantool или в том, как со всем этим работает написанный ночью с субботы на воскресенье код. На практике встречались все варианты, а также их комбинации.
До самой презентации для организаторов было загадкой, что это такое и куда оно едет. Оказалось — ищет утечки вредных газов
Но, впрочем, такой опыт был полезен и для нас: стало понятнее, какие вопросы (и не только технические) чаще задают неопытные пользователи, чего они ожидают и какую ещё документацию и примеры надо подготовить на следующий раз.
Если говорить тезисно:
Но это — технические моменты. Если же говорить в целом, то и нам, и участникам понравилось, и мы надеемся в дальнейшем развивать тему таких мероприятий, постепенно стирая грань между хакатонами, конкурсами стартапов и просто тематической площадкой для обсуждения развития и потребностей в IoT.
Мы надеемся, что этот хакатон по Industrial IoT (да, у нас не было ни одного умного дома или браслета-шагомера, зато было сразу несколько команд с проектами в сельском хозяйстве!) — первый, но отнюдь не последний. Мы заинтересованы в популяризации IoT, в демонстрации современной элементной, сетевой и программной базы — для всех, кто в этом заинтересован так же, как и мы.
Но нам не очень интересно проводить хакатон ради хакатона, поэтому мы ищем партнёров среди бизнеса. Если вашей компании интересно стать организатором такого хакатона — для продвижения своих продуктов, для решения своих проблем или с какими-либо другими благими целями — мы готовы с удовольствием обсудить возможное партнёрство.
Обращайтесь.
Этим полукреслом мастер Гамбс начинает новую партию мебели...
И. Ильф, Е. Петров, «Двенадцать стульев»
Совсем недавно мы — Mail.Ru Group, Intel и Unwired Devices — делали хакатон по Интернету вещей. В принципе, это могло бы быть рядовым событием — хакатоны по IoT сейчас не делает только ленивый. Но мы решили придумать формат, который выгодно отличал бы нас от других подобных мероприятий.
И если отбросить излишнюю скромность, то можно сказать, что этим хакатоном мы начинаем новую серию мероприятий по IoT — мероприятий, на базе которых мы хотим сформировать площадку для обсуждения современных IoT-технологий, на которой будут присутствовать не только энтузиасты, но и разработчики самих технологий, представители индустрии и инвесторы, заинтересованные в тематике Интернета вещей.
Ничтожная часть выпитого за два дня кофе
Начали же мы с хакатона. И теперь хотим рассказать вам, почему мы его сделали, что получилось и какие выводы мы извлекли.
Что же нам не нравилось в типичных IoT-хакатонах? В первую очередь то, что в них, как правило, нет IoT как такового — в том виде, в каком его понимают в промышленности, ЖКХ или даже умном доме. К сожалению, в образовательном IoT (а хакатоны можно отнести к образовательному сегменту) сейчас царит вакуум. Если в умном доме живут и здравствуют Z-Wave и ZigBee, промышленность с интересом смотрит на 6LoWPAN, а ЖКХ планирует переезжать на LoRa, то на среднестатистическом хакатоне вам, скорее всего, предложат написать что-нибудь для железки с обычным Wi-Fi. В среде разработки Arduino или подобной. С аналитикой и визуализацией — и это будет единственная серьёзная часть такого мероприятия — в облаке ThingWorx, Azure или подобном.
Да, даже на таких платформах можно отработать различные программные решения и сделать наброски IoT-сервисов, но вообще говоря, всё то же самое можно отработать и на обычном ноутбуке. Если вам надо показать, как вообще можно данные с какого-нибудь электросчётчика отправлять в облако, то одинаково подойдёт и Raspberry Pi, и ноутбук. А если вам эти данные надо отправлять с каждого из 236 электросчётчиков настоящего многоквартирного дома — и Raspberry Pi, и ноутбук для этого одинаково не подойдут. То есть, между ноутбуком и RPi в такой задаче есть количественная разница, но никак не качественная.
Мы решили это изменить и организовать хакатон на тех IoT-технологиях, которые не просто используются в промышленности сегодня, а будут использоваться завтра. И аппаратных, и программных.
Вторая проблема многих хакатонов — это замкнутые, герметичные мероприятия, в которых на входе команды получают некие наборы и инструкции, а на выходе — призы. Часто больше ничего не происходит: ни до, ни после, ни во время (за исключением, конечно, написания командами кода). Это мы тоже решили изменить — и, как я сказал выше, превратить хакатон в площадку, на которой есть и команды, и разработчики собственно базовых технологий, и представители индустрии, и инвесторы, заинтересованные в тематике IoT.
Технологии
С точки зрения технологий интернет вещей распадается на три направления:
- передать данные: беспроводные технологии связи, позволяющие подключить датчики и системы управления;
- собрать данные: программно-аппаратная система сбора данных с подключённых систем и их хранения;
- обработать данные: программная среда анализа и визуализации накопленных данных.
Из этих трёх подсистем мы решили предоставить участникам хакатона… разумеется, все три!
- Передать данные: участникам были доступны комплекты для построения небольших меш-сетей с протоколом 6LoWPAN на базе модулей Unwired Kit — в них входили датчики температуры и влажности воздуха, влажности почвы, гироакселерометры, реле, дополнительно имелись кнопки, GPS и другие модули. К комплектам можно было подключать проводные датчики Seeedstudio.
- Собрать данные: шлюз между сетью 6LoWPAN и Wi-Fi на базе микрокомпьютера Intel Edison, который мы специально сделали для мероприятия (но и, конечно, с заделом на будущее: Edison весьма интересен, когда нужна хорошая вычислительная мощность и много памяти в предельном компактном размере).
- Обработать данные: СУБД Tarantool, которая в данной ипостаси превратилась из СУБД в платформу Интернета вещей. У Tarantool есть встроенный сервер приложений с Lua — и он позволяет написать как скрипты для сбора данных (наша система отдаёт их в MQTT, например), так и собственно обработку этих данных с последующей передачей их в системы более высокого уровня.
Фактически, на таких компонентах вполне можно построить беспроводную SCADA-систему какого-нибудь объекта — от офисного здания до заводской площадки (особенный интерес в промышленности беспроводные SCADA вызывают применительно к открытым площадкам: если в здании ещё можно худо-бедно проложить слаботочку и гонять по ней старый добрый RS-485 + Modbus, то в каком-нибудь карьере это просто невозможно, а на какой-нибудь крупной подстанции или станции водоочистки — хоть и возможно, но совершенно негуманно по деньгам).
Участники
За тем, как используемые технологии влияют на содержание хакатона, было интересно смотреть уже на примере списка участников: к началу мероприятия в нём чётко сформировались три основные категории.
Первая — классическая: команды, в том числе и студенческие, у которых есть свой проект, и они хотели бы попробовать в рамках хакатона его развить. Впрочем, и здесь список доступного оборудования и ПО уже оказал влияние: некоторые из команд прямо попросили принести им те или иные модули, например, GPS или акселерометр.
Вторая — профессиональные разработчики, которым было интересно размять руки, а заодно поупражняться с новыми для них вещами, будь то работа с MQTT и «беспроводкой» или же с Tarantool.
Третья — команды из бизнеса, не обязательно как-то связанного с IT, но интересующегося теми технологиями, которые мы давали участникам хакатона. Например, была команда из успешного агрохозяйства, занимающегося круглогодичным выращиванием зелени. По их собственному признанию, их интересовал не столько сам процесс создания чего-то за два дня, сколько само по себе личное знакомство с современными технологиями. Круглогодичное агрохозяйство в наших широтах — дело хлопотное, требующее непрерывного контроля климата, полива и освещения (для меня, например, стало новостью, что у некоторых растений есть суточные циклы, и светить на них одними и теми же люменами 24 часа в сутки — не лучший способ их выращивать), и многие такие хозяйства сейчас присматриваются к технологиям беспроводного мониторинга и автоматического управления теплицами.
В целом получилась интересная смесь: команды из первой группы продвинули свои проекты, команды из второй показали первым, как надо работать профессионально и целенаправленно, а с третьей было о чём пообщаться и нам, и некоторым из инвесторов — им тоже интересно, какие технологии интересны с точки зрения потенциальных заказчиков.
Гости
На первый хакатон мы не приглашали целенаправленно представителей индустрии, хотя в результате пришли и они, и не только в составе команд.
В дальнейшем нам крайне интересно развивать сотрудничество с потенциальными заказчиками того, что на хакатоне могут сделать различные команды — вплоть до формата, при котором хакатон проводится под руководством одного крупного заказчика, который в качестве вводных данных предлагает командам свои бизнес-проблемы, требующие решения. Преимущества для заказчиков здесь очевидны, а для команд же это — прекрасный случай пообщаться с людьми, представляющими реальный бизнес и знающими о его реальных проблемах, причём не только тех, которые команда собралась решать, но и тех, которые на пути этого решения возникнут.
На самом деле, такой информации часто не хватает даже вполне оформившимся (но ещё не вышедшим на большой рынок) стартапам. Даже при хорошо проработанной технологической основе они часто не осознают, какой объём экономических, юридических и политических проблем их может ожидать впереди. И для нас было бы крайне интересно дать им фидбек от бизнеса, причём фидбек настоящий, иногда даже злой, а не формальное «молодцы, отличный проект, трудитесь дальше».
Здесь, конечно, существует опасный разрыв между реальностью бизнеса и реальностью хакатона: первый ожидает увидеть законченное решение в красивой коробочке и с поставкой 10 рабочих дней с момента оплаты, второй же показывает сделанную за два дня и одну ночь конструкцию из проводков и костылей, от которой постоянно что-то отваливается. Но как показывает практика, если подходить к делу с умом — и бизнес можно научить понимать, чем заняты стартапы.
Если говорить про инвесторов, то, конечно, с одной стороны, проекты хакатона — не венчурный материал, разве что какой-нибудь случайно забредший ангел возьмёт под крыло. С другой — инвесторы интересуются положением вещей в самой по себе отрасли, им бывает интересно посмотреть и послушать, о чём в принципе думают начинающие команды, а иногда и проследить за их судьбой.
Например, наш хакатон, хоть и проходил в нерабочее время — финал был вечером воскресенья — посетили представители CommIT Capital, ФРИИ, Сколково и другие. Беседовали со многими, контакты некоторых команд попросили им передать.
Жюри и судейство
Каждая команда по итогам двухдневной работы делала 6-минутный доклад о своей разработке — и после двух часов докладов (два десятка команд плюс перерывы на кофе, чтобы все желающие успели с только что доложившейся командой пообщаться подробнее) жюри удалилось на совещание.
Жюри мы собрали из представителей всех трёх организаторов — и сразу отказались от системы простого подсчёта баллов, когда каждый член жюри что-то ставит каждой команде, а потом оценки суммируются. Основным возражением против такой системы было то, что один член жюри будет ставить за артистизм, другой за технику — и получится средняя температура по больнице.
Подтвердилось это полностью: с первой же минуты обсуждения проектов жюри разделилось на три части. У представителей Mail.Ru Group перевешивала техническая сторона реализации проекта, у представителей Intel — коммерческая, ну а мы были где-то посередине, хотя и со склонностью к коммерческой стороне. В результате вместо формального сухого голосования вышла оживлённая дискуссия: если отсеять однозначных аутсайдеров получилось единогласно, то лидеры, а уж тем более распределение мест между ними менялись в ходе обсуждения несколько раз.
Что мы учитывали:
- Работа на хакатоне. Так как примерно половина членов жюри в течение хакатона занималась непрерывным консультированием команд по техническим вопросам, а некоторые даже не уезжали из офиса на ночь, то мы хорошо знали, какая команда сколько времени и чем занималась, а также какую часть из этого сделала самостоятельно.
- Использование предложенных технологий. Как минимум Tarantool надо было использовать обязательно.
- Коммерческая составляющая. Насколько проект (или хотя бы его идея) интересны с точки зрения воплощения в реальности.
- Качество презентации. Разумеется, профессионального выступления не требовалось, на технические проблемы с демонстрацией проектов (а они были примерно у всех, кто пробовал продемонстрировать что-то в работе) также внимания не обращали — но, как минимум, надо было объяснить, в чём проект заключается и почему он нужен в этом мире так, чтобы все члены жюри это поняли.
Собственно, о поиске баланса между первым и третьим пунктом и шла основная дискуссия. С одной стороны, хакатон — это конкурс по написанию кода; с другой, мы, во-первых, устраиваем нечто большее, чем обычный хакатон, а во-вторых, среди участников есть профессиональные команды — и при учёте только написанного кода можно сразу все призы отдать им.
Кроме того (и в этом отличие от механизированной системы суммирования баллов), выбить команду из числа финалистов мог провал по любому из пунктов. Например, даже самой красивой презентацией невозможно было спасти команду, не использовавшую Tarantool или, например, потратившую львиную долю времени на обсуждение бизнес-моделей вместо написания кода.
Победители
Первое место — проект «Агрогенез»: система мониторинга для сельского хозяйства (нет, не та, о которой речь была выше, та называлась «ГудФарм» — IoT в с/х вообще становится очень популярен). Команда, быстро попавшая в список победителей и расколовшая жюри надвое при попытках договориться о её месте в нём: с одной стороны, видно сложившуюся команду и проект, над которым она работала до хакатона и явно продолжит после, с другой — на хакатоне было сделано не очень много, и часто требовалась помощь разработчиков с нашей стороны.
Второе место — команда «Cool-IoT» с проектом беспроводных датчиков для спортзала: тренажёры (вплоть до гантелей) оснащаются акселерометрами и другими датчиками, позволяющими собирать статистику о количестве подходов, поднятом весе и т.п. Подобными системами оснащаются современные тренажёры, однако они весьма недёшевы, и многим спортцентрам просто не по карману. Команда за два дня сделала прототип гантели с акселерометром (за отсутствием чугуния — в виде пластмассовой коробки), который действительно сбрасывал данные по количеству подъёмов этой гантели по 6LoWPAN в Tarantool, а последний даже отображал их в веб-интерфейсе. Немного подвела команду презентация: было мало сказано про возможные детали реализации и коммерциализации, а потому у части членов жюри возникли сомнения, что такой проект технически и коммерчески возможен.
Синяя коробочка — гантель, хотя так и не очень похожа
Третье место — проект «ColorControl», умная лампа, цвет освещения которой меняется в зависимости от произносимых рядом слов: скажете «глубокий океан» — лампа плавно сменит цвет на синий, скажете «пустыня Сахара» — на жёлтый. Проект не использовал сеть 6LoWPAN: речь обрабатывалась на Intel Edison с распознаванием через Google API. У команды была отличная презентация с рассказом о том, какую атмосферу способна создать такая лампа, например, при чтении сказки детям на ночь, но немного подвело использование исключительно сторонних облачных сервисов для основной обработки данных и непонятные перспективы коммерциализации: такая лампа интересна как отдельный продукт, но вряд ли вокруг неё получится построить бизнес.
В общем, как вы видите, выбрать победителей было действительно трудно. Даже сейчас, когда я пишу описания проектов, начинают закрадываться мысли, что ведь и другое распределение мест можно было тоже убедительно обосновать. В целом, была бы наша воля, я думаю, всё жюри согласилось бы просто дать 5-7 лучшим проектам по первому месту каждому.
Опыт, сын ошибок трудных
Основной вывод из хакатона: в следующий раз требуется ещё больше подготовки с нашей стороны. Фактически, команды получили в своё распоряжение две аппаратные и три программные платформы, которые стыкуются друг с другом и ни с одной из которых у многих не было опыта. Поэтому часто было даже трудно с первого подхода понять, в какой именно части всей системы вылезает проблема: в 6LoWPAN-модулях, в нашем ПО на Edison, в Yocto Linux, в Tarantool или в том, как со всем этим работает написанный ночью с субботы на воскресенье код. На практике встречались все варианты, а также их комбинации.
До самой презентации для организаторов было загадкой, что это такое и куда оно едет. Оказалось — ищет утечки вредных газов
Но, впрочем, такой опыт был полезен и для нас: стало понятнее, какие вопросы (и не только технические) чаще задают неопытные пользователи, чего они ожидают и какую ещё документацию и примеры надо подготовить на следующий раз.
Если говорить тезисно:
- будем стараться больше популяризировать возможности Tarantool и Lua — участникам хакатона были интересны в первую очередь конкретные примеры проектов и возможностей;
- будем больше внимания уделять документации класса Getting started — и для железа, и для ПО;
- следующую версию набора Unwired Kit сделаем полностью plug'n'play — сейчас у радиомодулей прошивки не универсальны, их надо иногда менять в зависимости от подключённых плат расширения.
Но это — технические моменты. Если же говорить в целом, то и нам, и участникам понравилось, и мы надеемся в дальнейшем развивать тему таких мероприятий, постепенно стирая грань между хакатонами, конкурсами стартапов и просто тематической площадкой для обсуждения развития и потребностей в IoT.
Что дальше?
Мы надеемся, что этот хакатон по Industrial IoT (да, у нас не было ни одного умного дома или браслета-шагомера, зато было сразу несколько команд с проектами в сельском хозяйстве!) — первый, но отнюдь не последний. Мы заинтересованы в популяризации IoT, в демонстрации современной элементной, сетевой и программной базы — для всех, кто в этом заинтересован так же, как и мы.
Но нам не очень интересно проводить хакатон ради хакатона, поэтому мы ищем партнёров среди бизнеса. Если вашей компании интересно стать организатором такого хакатона — для продвижения своих продуктов, для решения своих проблем или с какими-либо другими благими целями — мы готовы с удовольствием обсудить возможное партнёрство.
Обращайтесь.
Поделиться с друзьями
Комментарии (31)
lingvo
12.08.2016 13:43+3Немного непонятен смысл и задачи этого Хакатона.
Если это для промышленного интернета вещей, то вы как-то двигаетесь не в том направлении. Промышленный интернет вещей, это не скада. Скада была вчера. Сегодня и завтра это Fog Computing — сочетание распределенных I/O, и вычислений — локальных и облачных и в конце концов управление каким-либо процессом в реальном времени. В любом случае — это системы управления — производствами, насосами, конвейерами, двигателями самолетов, а не только визуализация и обработка данных.
Взгляните на трендовые системы для завтрашнего Industirial IoT — Windriver Rocket, GE Predix Edge. Где вы видите свое место?
olartamonov
12.08.2016 13:58У вас типичная ошибка человека, который темой IoT на практике не занимается: вы смотрите на красивые рекламные брошюрки красивых облачных систем и считаете, что они решают задачу.
А они её не решают. Даже не приближаются к этому.
Потому что прежде, чем данные попадут в красивую облачную систему, их надо собрать с датчиков, обработать, передать на контроллер, обработать там — а потом уже передать в красивую облачную систему. Или не передать, потому что когда «трендовость» не является существенным критерием при выборе, красивые облачные системы вообще часто оказываются не нужны.
lingvo
12.08.2016 15:39Сорри, но я системами сбора информации в индустриальных системах занимался еще со студенчества, а дом у меня сделан на УД с Z-wave и MQTT.
Вы думаете, что проблема сбора данных в индустрии еще не решена? Помоему решена уже давно, и такими средствами, к которым Вы со своими 6LoWPAN еще не приблизились вообще. Вы знакомы с OPC UA, IEC 61850 и пр? Там даже с секурностью уже давно все налажено.olartamonov
12.08.2016 17:21> а дом у меня сделан на УД с Z-wave и MQTT
Огромное достижение. Где покупали, в Леруа Мерлене?
> Вы знакомы с OPC UA, IEC 61850 и пр?
У меня ощущение, что вы просто перечисляете термины, которые у вас в голове свалены как овощи в винегрете. В первой серии была недоделанная RTOS и облачная PaaS, во второй — сетевой протокол и стандарт на ЛВС подстанций.
Каким образом сетевой протокол, в котором вообще нет ни слова о физическом уровне, решает задачу сбора данных с устройств? А хранения и обработки этих данных? Или устройства и каналы связи, в вашем представлении, они как булки — на деревьях растут, надо только сорвать и сетевой протокол добавить?
МЭК 61850 хотя бы теоретически относится к теме — стандарт ЛВС для подстанций. Вот только те, кто занимается подстанциями, от него не очень счастливы, потому что проводная ЛВС на среднюю подстанцию, занимающую гектар-другой территории, стоит крайне немало. Что возвращает нас на начальную позицию.
P.S. Интересно, почему вы в качестве примеров приводите маргинальные и/или узкоспециализированные системы, а не какой-нибудь там Modbus/TCP, EtherCAT и т.п., про которые каждая собака знает. Опасаетесь, что если будете использовать знакомые другим читателям слова, то ваша речь прозвучит не так весомо? Или надеетесь, что от вида МЭКовского стандарта я испугаюсь и убегу?lingvo
12.08.2016 17:56+2Я перечисляю то, с чем реально работал. Вы сами перевели разговор на сбор данных, а не собственно платформы для построения систем управления.
Каким образом сетевой протокол, в котором вообще нет ни слова о физическом уровне, решает задачу сбора данных с устройств? А хранения и обработки этих данных? Или устройства и каналы связи, в вашем представлении, они как булки — на деревьях растут, надо только сорвать и сетевой протокол добавить?
Потому что физический уровень передачи может быть любой в зависимости от условий — и интернет, и витая пара, и оптика и беспроводка. Для каждого из них уже есть с десяток протоколов и придумывать там особо нечего. Сейчас индустриальный IoT основывается на том, что физические каналы связи уже есть и нужно использовать их, а не придумывать что-то новое. При этом особое внимание уделяется легкости конфигурирования.
Интересно, почему вы в качестве примеров приводите маргинальные и/или узкоспециализированные системы
Нифига себе, маргинальные! Если хотите — можно сравнить Modbus TCP и OPC UA. В первом разработчик должен задавать адреса регистров, держать в уме список IP всех клиентов, периодически делать опрос слейвов. Безопасность? Насколько я знаю нулевая. Передача файлов и текстов в принципе невозможна. А теперь OPC UA — автообнаружение и безопасность, как говорится, в базе. При подключении сканируются словари и привязка осуществляется двумя кликами по символьным переменным. Поллинг не нужен, временные штампы и т.д. Даже этих фактов хватает, чтобы Modbus TCP в промышленной автоматизации повсеместно исчезал, а OPC UA сейчас поддерживал каждый вендор в промышленной автоматизации.
MQTT туда же — просто отлично решили разом и проблему файерволов с помощью брокера и клиентов, и легкость самого стека и передачу информации любого типа — он тоже, собственно, засовывает Modbus TCP куда подальше там, где нужна большая гибкость, типя DIY. Где, кстати, в MQTT указывается физический канал передачи? К чему его тут указывать?
А EtherCAT я люблю, но только он предназначен на для IoT, а для высокоскоростного сбора данных в реальном времени с использованием дешевых кабелей. Т.е замена Profibus, Modbus RTU, CANopen и др.olartamonov
12.08.2016 20:12Потому что физический уровень передачи может быть любой в зависимости от условий — и интернет, и витая пара, и оптика и беспроводка. Для каждого из них уже есть с десяток протоколов и придумывать там особо нечего. Сейчас индустриальный IoT основывается на том, что физические каналы связи уже есть и нужно использовать их, а не придумывать что-то новое.
Вот это сейчас было настолько мощное заявление, что я даже не берусь его комментировать. Уровня «640 килобайт хватит всем».
А какие, кстати, у вас «уже есть» каналы беспроводной связи?
Нифига себе, маргинальные! Если хотите — можно сравнить Modbus TCP и OPC UA
Боюсь, если я сравню частоту использования в реальных системах — ой не в пользую OPC UA результат получится.
К чему его тут указывать?
Это вы меня спрашиваете? Вроде как не я начал швыряться всеми подряд названиями в диапазоне от RTOS до PaaS.
А EtherCAT я люблю, но только он предназначен на для IoT, а для высокоскоростного сбора данных в реальном времени с использованием дешевых кабелей
У вас, видимо, какое-то своё определение термина «IoT». Почему для IoT нельзя собирать данные в реальном времени с использованием дешёвых кабелей?lingvo
12.08.2016 22:32Вот это сейчас было настолько мощное заявление, что я даже не берусь его комментировать. Уровня «640 килобайт хватит всем».
Еще раз, я просто хочу понять о чем Хакатон. Вы продвигаете свой вариант беспроводной связи?
А какие, кстати, у вас «уже есть» каналы беспроводной связи?
Bluetooth, Wi-Fi, Z-wave, Zigbee, Enocean, 3G, LTE, IR, 433МГц. В чем смысл данного вопроса?
Боюсь, если я сравню частоту использования в реальных системах — ой не в пользую OPC UA результат получится.
Боюсь, если сравнить количество сегодня ездящих автомобилей на дороге на бензине с электромобилями, то результат тоже будет не в пользу последних. Это не значит, что последние менее инновационные, или, что за ДВС будущее. Скорее, наоборот.
У вас, видимо, какое-то своё определение термина «IoT». Почему для IoT нельзя собирать данные в реальном времени с использованием дешёвых кабелей?
Где в EtherCAT Internet of Things? Я его там не нашел, как не искал.olartamonov
12.08.2016 22:57Еще раз, я просто хочу понять о чем Хакатон. Вы продвигаете свой вариант беспроводной связи?
Мы продвигаем современные технологии IoT для тех, кому они интересны.
Bluetooth, Wi-Fi, Z-wave, Zigbee, Enocean, 3G, LTE, IR, 433МГц. В чем смысл данного вопроса?
Боже. И что из этого относится к промышленному IoT? Ну ОК, на ZigBee в предыдущие годы в промышленности, с/х и ЖКХ многие пытались что-то сделать, примерно все остались недовольны. В основном сейчас переделывают на 6LoWPAN и LoRa, в зависимости от потребностей по дальности и схеме подключения. Извините, интересующихся этой переделкой назвать не могу, у меня NDA — так что просто поверьте, что каждый из них из первой пятёрки в своей отрасли.
Bluetooth — низкая дальность, странная схема сети. Wi-Fi — низкая дальность, больше потребление. Z-Wave — низкая дальность, жёсткая проприетарность, ограниченные возможности. ZigBee — низкая дальность, бессмысленность таскания специфического уровня приложений. Enocean — низкая дальность, проприетарность. 3G, LTE — очень дорого, использование сторонней сети связи. IR — это вообще, что, ИК-пульт от телека? 433 МГц — это частота такая, а не канал связи.
Ну вот возьмём банальную сельскохозяйственную задачу — контроль температуры в кагате*. Кагат — это такая система открытого временного хранения, небольшое поле, засыпанное корнеплодами на 2-3 м в высоту. У кагата есть неприятная особенность — если внутри начинает гнить, то включается ПОС по температуре, и кагат сгорает. Как торфяное поле горит, видели? Вот тысячи кубометров свеклы или картошки тоже так умеют. Начавший гнить кагат за два-три дня сгорает целиком.
Кагат можно спасти, если вовремя отследить начало гниения. Для этого по всему катагу надо поставить датчики температуры, которые будут снимать трёхмерную картинку.
Вы себе хорошо представили, да? Тысячи тонн картошки. Территория размерами в сотни метров. В каждом кагате — десятки, а то и сотни датчиков температуры.
Возьмите теперь Bluetooth или Z-Wave и сделайте мне на них систему мониторинга температуры в кагатах, а потом поговорим про то, какие у вас каналы связи есть.
* — кто узнал эту задачу, не бегите хвастаться, её вся индустрия уже знает ;)
Где в EtherCAT Internet of Things? Я его там не нашел
А вы как, я боюсь спросить, искали, по надписям на Ethernet-кабеле?..
vvzvlad
12.08.2016 23:18Кагат можно спасти, если вовремя отследить начало гниения. Для этого по всему катагу надо поставить датчики температуры, которые будут снимать трёхмерную картинку.
Это для этого нужны были датчики температуры в виде трубы?olartamonov
12.08.2016 23:25Ээээ… ты про фотку у меня в фейсбуке? Нет, это датчики влажности почвы были. Датчики для кагатов тоже конструктивно делаются трубами, но там масштабы совсем иные — температуру надо измерять в глубине кагата, а так как он несколько метров высотой, то конструкция будет впечатляющая.
vvzvlad
12.08.2016 20:38следующую версию набора Unwired Kit сделаем полностью plug'n'play — сейчас у радиомодулей прошивки не универсальны, их надо иногда менять в зависимости от подключённых плат расширения.
Как по мне, если сделать UART-бутлоадер, разные прошивки не проблема — их можно и залить, если будет набор собранных под разные платы расширения.
Что хотелось бы сделать:
• Возможность настройки частоты(вспоминаю мой эпичный бег по этажу с вопросом «а у вас случайно нет передатчика с ID 3B6A? А то он на моем канале висит и эвенты шлет, мешает, а где он физически находится, непонятно»), пусть даже и путем сбора прошивки/консольных команд в UART
• Нормальные штекеры PLS/PBS с двух сторон платы.
• Плату с каким-нибудь контроллером(например, Arduino-совместимая atmega/stm32 для быстрого старта на хакатоне), которая бы реализовывала на оконечном устройстве уровень логики чуть выше, чем дрыганье ножками, и общалась бы с передатчиком по UART — это было бы удобно для тех ситуаций, когда проще написать небольшой код для предварительной фильтрации событий акселя/освещения, или для быстрой работы с портами(IR-приемопередатчик, например), для какого-нибудь устройства, типа LCD-экрана, или просто для кастомного кода(например, для подавление дребезга кнопок, из-за которого я отказался от использования платы с кнопками).
• Привести в порядок MQTT-топики — сейчас там немного каша в том, куда отсылается и куда приходит, и парсить это не то, чтобы совсем просто.olartamonov
12.08.2016 20:41Как по мне, если сделать UART-бутлоадер, разные прошивки не проблема — их можно и залить, если будет набор собранных под разные платы расширения.
Он есть, мы просто решили не привносить ещё больше путаницы, давая командам самостоятельно разбираться с разными прошивками.
Возможность настройки частоты
Будет система сборки, в которой можно будет задать SSID сети и ключ шифрования. Частоту просто так — нет, чтобы пользователи не вылезали из нелицензируемых диапазонов (а они очень узкие, в общем случае всего 0,5 МГц).
Плату с каким-нибудь контроллером(например, Arduino-совместимая atmega/stm32 для быстрого старта на хакатоне), которая бы реализовывала на оконечном устройстве уровень логики чуть выше, чем дрыганье ножками, и общалась бы с передатчиком по UART
Со временем будет скриптовый язык на конечных устройствах.vvzvlad
13.08.2016 01:13Будет система сборки, в которой можно будет задать SSID сети и ключ шифрования. Частоту просто так — нет, чтобы пользователи не вылезали из нелицензируемых диапазонов (а они очень узкие, в общем случае всего 0,5 МГц).
Так-то можно можно сделать и просто выбор диапазона, а не частоты.
В каком смысле SSID? Разделение будет частотное? Или просто схема вида «устройство игнорирует пакеты не со своим именем сети, а для защиты от чуваков со сканером и ноутбуком есть шифрование»?
А когда будет по времени, примерно?
Со временем будет скриптовый язык на конечных устройствах.
А какой язык? Я тут потыкал, например, Lua на ESP8266(сетевой стек у которого, конечно, глючный, но ядро там достаточно бодрое), и там уже 38кгц для IR делается с извращениями. Да, прикладную часть и логику писать на нем одно удовольствие, гораздо быстрее и удобнее, но для устройств умного дома, у которых есть центральный сервер, в сложной логике на устройствах необходимости вроде и нет.
И опять же, «со временем» — это к следующему хакатону? :)
olartamonov
13.08.2016 01:24В каком смысле SSID? Разделение будет частотное?
В прямом — логическое имя сети, то есть да, игнорирует не свои пакеты. Частного разделения серьёзного не будет, потому что не получится: 0,5 МГц доступного диапазона — это очень мало отдельных каналов.
SSID и сейчас есть. Конфигуратор будет где-то осенью, наверное, когда CC1310/CC2650 переедут с Contiki на RIOT OS. Допиливать сейчас Контики нет большого смысла, в дальнейшем мы не хотим её поддерживать.
А какой язык?
Сейчас выбираем между Lua и PAWN (который не очень скриптовый, зато маленький и быстрый). Скорее всего останется PAWN.
Ну а вещи типа стандартных драйверов (IR к таковым можно отнести) должны собираться в прошивке, а не писаться скриптом. Скрипт определяет взаимодействие между драйверами — чтобы по каждому чиху не грузить сеть и не дёргать центральный сервер.vvzvlad
13.08.2016 17:290,5 МГц доступного диапазона — это очень мало отдельных каналов.
А, там вообще 0.5? Тогда да.
Ну а вещи типа стандартных драйверов (IR к таковым можно отнести) должны собираться в прошивке, а не писаться скриптом.
А вы будете открывать исходники для того, чтобы можно было свой драйвер написать? Скриптовый язык, конечно, хорошо, но все-таки немного не о том — я говорю больше про поддержку всяких девайсов и странных протоколов, которые вы просто не будете поддерживать, потому что вам это не сдалось. Ну вот из последнего: CO2-датчик с обрезанным SPI, драйвер шагового двигателя, UART, в котором режим команды/данные управляется отдельной ножкой.olartamonov
13.08.2016 19:50А, там вообще 0.5? Тогда да.
Ну как бы да, сейчас есть всего два куска диапазона, условно называемого «868 МГц», для неспециализированных устройств:
* 864,0 — 865,0 Мгц — 25 мВт, рабочий период не более 0,1 %, запрещено использовать около аэропортов
* 868,7 — 869,2 МГц — 25 мВт, рабочий период не ограничен, использование не ограничено
Остальное — для устройств конкретного назначения (охранной сигнализации, передачи аудио и т.п.). Так как в общем случае вписываться в 0,1% duty cycle мы не хотим, это оставляет второй кусок шириной 0,5 МГц.
Проще в 2,4 ГГц, потому что там весь диапазон 2400—2483,5 МГц отдан под «устройтва малого радиуса действия». Вот только — с примечанием «Разрешается использование только в пределах зданий, сооружений, закрытых промышленных и складских площадках» (Приложение 2 к решению ГКРЧ от 7 мая 2007 года N 07-20-03-001).
Хотя в целом думаю, что если мы начнём продажи модулей в DIY/образование — мы ограничимся версией на 2,4 ГГц, а там выбор канала будет иметь смысл. Для этих целей эксплуатация на улице всё равно не нужна, равно как и высокая дальность.
А вы будете открывать исходники для того, чтобы можно было свой драйвер написать?
Да, наработки под RIOT я планирую отдавать в их официальный репозиторий. Но это в целом не играет большой роли: посторонний человек в этой теме всё равно без поллитры не разберётся, а те, кто понимает, что делают, могут напрямую к нам обращаться.vvzvlad
13.08.2016 20:29Но это в целом не играет большой роли: посторонний человек в этой теме всё равно без поллитры не разберётся, а те, кто понимает, что делают, могут напрямую к нам обращаться.
Ну вот это и смущает меня в написании драйверов — на хакатоне быстренько драйвер уже не запилишь, для любой любой работы с железом, выходящей за рамки скриптового языка придется вникать в тему и общаться с вами. Но ладно, это я к использованию модулей в DIY привязался, если использовать в сколько-нибудь крупном проекте, проблем не составит.olartamonov
13.08.2016 20:57Человек, не имевший опыта работы с такими системами, вообще ничего там быстренько не запилит — ни на хакатоне, ни как-либо иначе. Они внутри специфические — это не ардуина, не линукс, и в данном случае даже не STM32.
Поэтому на хакатоне всё-таки предполагается работа на более высоком уровне абстракции.vvzvlad
13.08.2016 21:03Человек, не имевший опыта работы с такими системами, вообще ничего там быстренько не запилит — ни на хакатоне, ни как-либо иначе. Они внутри специфические — это не ардуина, не линукс, и в данном случае даже не STM32.
Да, я и говорю про это. И железо другое, и внутри помимо пользовательской задачи своя ОС крутится, которую надо не просто иметь ввиду, а принудительно использовать только ее очередь задач, таймеры, приоритеты и так далее.
Вот и предлагаю сделать для DIY/обучения/хакатонов простейший модуль с stm32/atmega, чтобы закидывать туда пользовательскую логику при необходимости таковой. Это будет проще, быстрее, и понятнее для неопытного разработчика, чем скриптовый язык, к которому надо еще и документацию писать.olartamonov
13.08.2016 21:06Это бессмысленно с точки зрения использования за пределами хакатонов, а потому мы этого делать не будем. Желающие могут притащить ардуину с собой и делать что-то на ней.
P.S. Справедливости ради, три четверти модулей LoRa с набортным процессором сделаны именно так — стоит дохлое ядро (STM8L, PIC18F), которое просто реализует HAL между чипом LoRa и UART. Но это неэффективная реализация.vvzvlad
13.08.2016 21:11Ну ты же вон сам пишешь про DIY и образование. Есть в этом смысл. Но ок, аргумент принимается.
lingvo
13.08.2016 14:28Со временем будет скриптовый язык на конечных устройствах.
Зачем? Если это для какой либо высокой логики — то это тупиковый путь. Представьте себе, вы ошиблись где-то в этой логике или хотите что-то добавить. Будете бегать по этому вашему «кагату» и обновлять прошивку у всей сотни датчиков? Или пытаться делать это удаленно, по воздуху с риском превратить датчик в кирпич? Если вы взгляните на аналогичные системы сбора данных, то увидите, что предварительной обработки на датчике там минимум — разве что дребезг контактов, да перевод данных АЦП к нормальному виду. Но сама прошивка датчика — одна и не меняется от проекта к проекту. И как уже написали, для низкоуровневой обработки типа UART, или LCD — скорости интерпретатора будет недостаточно — это придется кодить на Си с изрядной привязкой к конкретному железу.olartamonov
13.08.2016 18:13Зачем?
Для DIY и образования, в первую очередь.
Представьте себе, вы ошиблись где-то в этой логике или хотите что-то добавить
Шансов ошибиться в высокоуровневой логике — намного меньше, чем в низкоуровневой прошивке.
Если вы взгляните на аналогичные системы сбора данных, то увидите, что предварительной обработки на датчике там минимум — разве что дребезг контактов, да перевод данных АЦП к нормальному виду
Простите, это вы мне писали про туманные вычисления и распределённое I/O — или ваш evil twin?
Берёте современную систему АСУНО — и видите на одном модуле как минимум:
— стек LoRaWAN
— датчик освещённости
— датчик температуры
— часы и локальное расписание работы лампы
— вкл/выкл драйвера лампы и его диммирование
И всё это между собой взаимодействует.lingvo
13.08.2016 19:23Что такое АСУНО и что за модель модуля?
olartamonov
13.08.2016 19:52-2В гугле вас забанили, знаток SCADA-систем вы наш?
Автоматизированная система управления наружным освещением. Перечисленный функционал — базовые требования к исполнительному модулю современной АСУНО.lingvo
14.08.2016 11:22Не издевайтесь. Это могла бы быть и автоматизированная система управления насосным оборудованием. Я вас тоже могу закидать аббревиатурами, о которых вы и не слышали.
Так это все-таки требования или уже реализованная функциональность какого либо оборудования?olartamonov
14.08.2016 11:30Это могла бы быть и автоматизированная система управления насосным оборудованием
Ну, в вашем параллельном мире может и могла бы. А в моём вся первая страница гугля совершенно однозначно указывает, что это такое, и вы — первый человек из индустрии (ну, вы, по крайней мере, утверждаете, что вы из неё, да ещё и с первого комментария свысока указываете нам, что мы не тем занимаемся — что предполагает некоторый уровень знаний), который эту аббревиатуру не понимает и не считает общеупотребимой.
На всякий случай: если мы дальше начнём про АСКУЭ, вы тоже сделаете круглые глаза, профессионал вы наш?
Я вас тоже могу закидать аббревиатурами, о которых вы и не слышали.
Вы эти пытались заниматься, я напомню.
Так это все-таки требования или уже реализованная функциональность какого либо оборудования?
(пожав плечами) У нас, например, реализована. У inteliLIGHT реализована. Много у кого реализована. И? Дальше что? К чему этот вопрос?
P.S. Я до сих пор жду рассказа, что такое «каналы связи IR и 433 МГц» и как вы будете решать описанную выше задачу с кагатами с каналами связи, которые у вас «уже есть и других не надо».
AlexBaggins
13.08.2016 15:45По поводу " некоторых растений есть суточные циклы"
Интересно было бы в агротехнических проектах за развитием листиков на ЭПР-спектрометре последить.
Это я так, по старой памяти, в университете на изучении фотосинтеза специализировался
j_wayne
>> беспроводную SCADA-систему какого-нибудь объекта — от офисного здания до заводской площадки
А секурность? TLS/DTLS?
olartamonov
Секурность на практике сильно зависит от задачи. Например, в каком-нибудь ЖКХ показания счётчиков снимать — нужна максимальная дальность (которая всегда обратно пропорциональна скорости), а требования к защите при этом в общем-то минимальные — достаточно имитозащиты пакета плюс шифрование пользовательских данных.
Конкретно у нас вот эта имитозащита + шифрование есть в работе, DTLS сейчас в разработке.