Комментарии 31
>> беспроводную SCADA-систему какого-нибудь объекта — от офисного здания до заводской площадки
А секурность? TLS/DTLS?
А секурность? TLS/DTLS?
Секурность на практике сильно зависит от задачи. Например, в каком-нибудь ЖКХ показания счётчиков снимать — нужна максимальная дальность (которая всегда обратно пропорциональна скорости), а требования к защите при этом в общем-то минимальные — достаточно имитозащиты пакета плюс шифрование пользовательских данных.
Конкретно у нас вот эта имитозащита + шифрование есть в работе, DTLS сейчас в разработке.
Немного непонятен смысл и задачи этого Хакатона.
Если это для промышленного интернета вещей, то вы как-то двигаетесь не в том направлении. Промышленный интернет вещей, это не скада. Скада была вчера. Сегодня и завтра это Fog Computing — сочетание распределенных I/O, и вычислений — локальных и облачных и в конце концов управление каким-либо процессом в реальном времени. В любом случае — это системы управления — производствами, насосами, конвейерами, двигателями самолетов, а не только визуализация и обработка данных.
Взгляните на трендовые системы для завтрашнего Industirial IoT — Windriver Rocket, GE Predix Edge. Где вы видите свое место?
Если это для промышленного интернета вещей, то вы как-то двигаетесь не в том направлении. Промышленный интернет вещей, это не скада. Скада была вчера. Сегодня и завтра это Fog Computing — сочетание распределенных I/O, и вычислений — локальных и облачных и в конце концов управление каким-либо процессом в реальном времени. В любом случае — это системы управления — производствами, насосами, конвейерами, двигателями самолетов, а не только визуализация и обработка данных.
Взгляните на трендовые системы для завтрашнего Industirial IoT — Windriver Rocket, GE Predix Edge. Где вы видите свое место?
У вас типичная ошибка человека, который темой IoT на практике не занимается: вы смотрите на красивые рекламные брошюрки красивых облачных систем и считаете, что они решают задачу.
А они её не решают. Даже не приближаются к этому.
Потому что прежде, чем данные попадут в красивую облачную систему, их надо собрать с датчиков, обработать, передать на контроллер, обработать там — а потом уже передать в красивую облачную систему. Или не передать, потому что когда «трендовость» не является существенным критерием при выборе, красивые облачные системы вообще часто оказываются не нужны.
Сорри, но я системами сбора информации в индустриальных системах занимался еще со студенчества, а дом у меня сделан на УД с Z-wave и MQTT.
Вы думаете, что проблема сбора данных в индустрии еще не решена? Помоему решена уже давно, и такими средствами, к которым Вы со своими 6LoWPAN еще не приблизились вообще. Вы знакомы с OPC UA, IEC 61850 и пр? Там даже с секурностью уже давно все налажено.
Вы думаете, что проблема сбора данных в индустрии еще не решена? Помоему решена уже давно, и такими средствами, к которым Вы со своими 6LoWPAN еще не приблизились вообще. Вы знакомы с OPC UA, IEC 61850 и пр? Там даже с секурностью уже давно все налажено.
> а дом у меня сделан на УД с Z-wave и MQTT
Огромное достижение. Где покупали, в Леруа Мерлене?
> Вы знакомы с OPC UA, IEC 61850 и пр?
У меня ощущение, что вы просто перечисляете термины, которые у вас в голове свалены как овощи в винегрете. В первой серии была недоделанная RTOS и облачная PaaS, во второй — сетевой протокол и стандарт на ЛВС подстанций.
Каким образом сетевой протокол, в котором вообще нет ни слова о физическом уровне, решает задачу сбора данных с устройств? А хранения и обработки этих данных? Или устройства и каналы связи, в вашем представлении, они как булки — на деревьях растут, надо только сорвать и сетевой протокол добавить?
МЭК 61850 хотя бы теоретически относится к теме — стандарт ЛВС для подстанций. Вот только те, кто занимается подстанциями, от него не очень счастливы, потому что проводная ЛВС на среднюю подстанцию, занимающую гектар-другой территории, стоит крайне немало. Что возвращает нас на начальную позицию.
P.S. Интересно, почему вы в качестве примеров приводите маргинальные и/или узкоспециализированные системы, а не какой-нибудь там Modbus/TCP, EtherCAT и т.п., про которые каждая собака знает. Опасаетесь, что если будете использовать знакомые другим читателям слова, то ваша речь прозвучит не так весомо? Или надеетесь, что от вида МЭКовского стандарта я испугаюсь и убегу?
Огромное достижение. Где покупали, в Леруа Мерлене?
> Вы знакомы с OPC UA, IEC 61850 и пр?
У меня ощущение, что вы просто перечисляете термины, которые у вас в голове свалены как овощи в винегрете. В первой серии была недоделанная RTOS и облачная PaaS, во второй — сетевой протокол и стандарт на ЛВС подстанций.
Каким образом сетевой протокол, в котором вообще нет ни слова о физическом уровне, решает задачу сбора данных с устройств? А хранения и обработки этих данных? Или устройства и каналы связи, в вашем представлении, они как булки — на деревьях растут, надо только сорвать и сетевой протокол добавить?
МЭК 61850 хотя бы теоретически относится к теме — стандарт ЛВС для подстанций. Вот только те, кто занимается подстанциями, от него не очень счастливы, потому что проводная ЛВС на среднюю подстанцию, занимающую гектар-другой территории, стоит крайне немало. Что возвращает нас на начальную позицию.
P.S. Интересно, почему вы в качестве примеров приводите маргинальные и/или узкоспециализированные системы, а не какой-нибудь там Modbus/TCP, EtherCAT и т.п., про которые каждая собака знает. Опасаетесь, что если будете использовать знакомые другим читателям слова, то ваша речь прозвучит не так весомо? Или надеетесь, что от вида МЭКовского стандарта я испугаюсь и убегу?
Я перечисляю то, с чем реально работал. Вы сами перевели разговор на сбор данных, а не собственно платформы для построения систем управления.
Потому что физический уровень передачи может быть любой в зависимости от условий — и интернет, и витая пара, и оптика и беспроводка. Для каждого из них уже есть с десяток протоколов и придумывать там особо нечего. Сейчас индустриальный IoT основывается на том, что физические каналы связи уже есть и нужно использовать их, а не придумывать что-то новое. При этом особое внимание уделяется легкости конфигурирования.
Нифига себе, маргинальные! Если хотите — можно сравнить Modbus TCP и OPC UA. В первом разработчик должен задавать адреса регистров, держать в уме список IP всех клиентов, периодически делать опрос слейвов. Безопасность? Насколько я знаю нулевая. Передача файлов и текстов в принципе невозможна. А теперь OPC UA — автообнаружение и безопасность, как говорится, в базе. При подключении сканируются словари и привязка осуществляется двумя кликами по символьным переменным. Поллинг не нужен, временные штампы и т.д. Даже этих фактов хватает, чтобы Modbus TCP в промышленной автоматизации повсеместно исчезал, а OPC UA сейчас поддерживал каждый вендор в промышленной автоматизации.
MQTT туда же — просто отлично решили разом и проблему файерволов с помощью брокера и клиентов, и легкость самого стека и передачу информации любого типа — он тоже, собственно, засовывает Modbus TCP куда подальше там, где нужна большая гибкость, типя DIY. Где, кстати, в MQTT указывается физический канал передачи? К чему его тут указывать?
А EtherCAT я люблю, но только он предназначен на для IoT, а для высокоскоростного сбора данных в реальном времени с использованием дешевых кабелей. Т.е замена Profibus, Modbus RTU, CANopen и др.
Каким образом сетевой протокол, в котором вообще нет ни слова о физическом уровне, решает задачу сбора данных с устройств? А хранения и обработки этих данных? Или устройства и каналы связи, в вашем представлении, они как булки — на деревьях растут, надо только сорвать и сетевой протокол добавить?
Потому что физический уровень передачи может быть любой в зависимости от условий — и интернет, и витая пара, и оптика и беспроводка. Для каждого из них уже есть с десяток протоколов и придумывать там особо нечего. Сейчас индустриальный IoT основывается на том, что физические каналы связи уже есть и нужно использовать их, а не придумывать что-то новое. При этом особое внимание уделяется легкости конфигурирования.
Интересно, почему вы в качестве примеров приводите маргинальные и/или узкоспециализированные системы
Нифига себе, маргинальные! Если хотите — можно сравнить Modbus TCP и OPC UA. В первом разработчик должен задавать адреса регистров, держать в уме список IP всех клиентов, периодически делать опрос слейвов. Безопасность? Насколько я знаю нулевая. Передача файлов и текстов в принципе невозможна. А теперь OPC UA — автообнаружение и безопасность, как говорится, в базе. При подключении сканируются словари и привязка осуществляется двумя кликами по символьным переменным. Поллинг не нужен, временные штампы и т.д. Даже этих фактов хватает, чтобы Modbus TCP в промышленной автоматизации повсеместно исчезал, а OPC UA сейчас поддерживал каждый вендор в промышленной автоматизации.
MQTT туда же — просто отлично решили разом и проблему файерволов с помощью брокера и клиентов, и легкость самого стека и передачу информации любого типа — он тоже, собственно, засовывает Modbus TCP куда подальше там, где нужна большая гибкость, типя DIY. Где, кстати, в MQTT указывается физический канал передачи? К чему его тут указывать?
А EtherCAT я люблю, но только он предназначен на для IoT, а для высокоскоростного сбора данных в реальном времени с использованием дешевых кабелей. Т.е замена Profibus, Modbus RTU, CANopen и др.
Потому что физический уровень передачи может быть любой в зависимости от условий — и интернет, и витая пара, и оптика и беспроводка. Для каждого из них уже есть с десяток протоколов и придумывать там особо нечего. Сейчас индустриальный IoT основывается на том, что физические каналы связи уже есть и нужно использовать их, а не придумывать что-то новое.
Вот это сейчас было настолько мощное заявление, что я даже не берусь его комментировать. Уровня «640 килобайт хватит всем».
А какие, кстати, у вас «уже есть» каналы беспроводной связи?
Нифига себе, маргинальные! Если хотите — можно сравнить Modbus TCP и OPC UA
Боюсь, если я сравню частоту использования в реальных системах — ой не в пользую OPC UA результат получится.
К чему его тут указывать?
Это вы меня спрашиваете? Вроде как не я начал швыряться всеми подряд названиями в диапазоне от RTOS до PaaS.
А EtherCAT я люблю, но только он предназначен на для IoT, а для высокоскоростного сбора данных в реальном времени с использованием дешевых кабелей
У вас, видимо, какое-то своё определение термина «IoT». Почему для IoT нельзя собирать данные в реальном времени с использованием дешёвых кабелей?
Вот это сейчас было настолько мощное заявление, что я даже не берусь его комментировать. Уровня «640 килобайт хватит всем».
Еще раз, я просто хочу понять о чем Хакатон. Вы продвигаете свой вариант беспроводной связи?
А какие, кстати, у вас «уже есть» каналы беспроводной связи?
Bluetooth, Wi-Fi, Z-wave, Zigbee, Enocean, 3G, LTE, IR, 433МГц. В чем смысл данного вопроса?
Боюсь, если я сравню частоту использования в реальных системах — ой не в пользую OPC UA результат получится.
Боюсь, если сравнить количество сегодня ездящих автомобилей на дороге на бензине с электромобилями, то результат тоже будет не в пользу последних. Это не значит, что последние менее инновационные, или, что за ДВС будущее. Скорее, наоборот.
У вас, видимо, какое-то своё определение термина «IoT». Почему для IoT нельзя собирать данные в реальном времени с использованием дешёвых кабелей?
Где в EtherCAT Internet of Things? Я его там не нашел, как не искал.
Еще раз, я просто хочу понять о чем Хакатон. Вы продвигаете свой вариант беспроводной связи?
Мы продвигаем современные технологии 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-кабеле?..
следующую версию набора Unwired Kit сделаем полностью plug'n'play — сейчас у радиомодулей прошивки не универсальны, их надо иногда менять в зависимости от подключённых плат расширения.
Как по мне, если сделать UART-бутлоадер, разные прошивки не проблема — их можно и залить, если будет набор собранных под разные платы расширения.
Что хотелось бы сделать:
• Возможность настройки частоты(вспоминаю мой эпичный бег по этажу с вопросом «а у вас случайно нет передатчика с ID 3B6A? А то он на моем канале висит и эвенты шлет, мешает, а где он физически находится, непонятно»), пусть даже и путем сбора прошивки/консольных команд в UART
• Нормальные штекеры PLS/PBS с двух сторон платы.
• Плату с каким-нибудь контроллером(например, Arduino-совместимая atmega/stm32 для быстрого старта на хакатоне), которая бы реализовывала на оконечном устройстве уровень логики чуть выше, чем дрыганье ножками, и общалась бы с передатчиком по UART — это было бы удобно для тех ситуаций, когда проще написать небольшой код для предварительной фильтрации событий акселя/освещения, или для быстрой работы с портами(IR-приемопередатчик, например), для какого-нибудь устройства, типа LCD-экрана, или просто для кастомного кода(например, для подавление дребезга кнопок, из-за которого я отказался от использования платы с кнопками).
• Привести в порядок MQTT-топики — сейчас там немного каша в том, куда отсылается и куда приходит, и парсить это не то, чтобы совсем просто.
Как по мне, если сделать UART-бутлоадер, разные прошивки не проблема — их можно и залить, если будет набор собранных под разные платы расширения.
Он есть, мы просто решили не привносить ещё больше путаницы, давая командам самостоятельно разбираться с разными прошивками.
Возможность настройки частоты
Будет система сборки, в которой можно будет задать SSID сети и ключ шифрования. Частоту просто так — нет, чтобы пользователи не вылезали из нелицензируемых диапазонов (а они очень узкие, в общем случае всего 0,5 МГц).
Плату с каким-нибудь контроллером(например, Arduino-совместимая atmega/stm32 для быстрого старта на хакатоне), которая бы реализовывала на оконечном устройстве уровень логики чуть выше, чем дрыганье ножками, и общалась бы с передатчиком по UART
Со временем будет скриптовый язык на конечных устройствах.
Будет система сборки, в которой можно будет задать SSID сети и ключ шифрования. Частоту просто так — нет, чтобы пользователи не вылезали из нелицензируемых диапазонов (а они очень узкие, в общем случае всего 0,5 МГц).Так-то можно можно сделать и просто выбор диапазона, а не частоты.
В каком смысле SSID? Разделение будет частотное? Или просто схема вида «устройство игнорирует пакеты не со своим именем сети, а для защиты от чуваков со сканером и ноутбуком есть шифрование»?
А когда будет по времени, примерно?
Со временем будет скриптовый язык на конечных устройствах.А какой язык? Я тут потыкал, например, Lua на ESP8266(сетевой стек у которого, конечно, глючный, но ядро там достаточно бодрое), и там уже 38кгц для IR делается с извращениями. Да, прикладную часть и логику писать на нем одно удовольствие, гораздо быстрее и удобнее, но для устройств умного дома, у которых есть центральный сервер, в сложной логике на устройствах необходимости вроде и нет.
И опять же, «со временем» — это к следующему хакатону? :)
В каком смысле SSID? Разделение будет частотное?
В прямом — логическое имя сети, то есть да, игнорирует не свои пакеты. Частного разделения серьёзного не будет, потому что не получится: 0,5 МГц доступного диапазона — это очень мало отдельных каналов.
SSID и сейчас есть. Конфигуратор будет где-то осенью, наверное, когда CC1310/CC2650 переедут с Contiki на RIOT OS. Допиливать сейчас Контики нет большого смысла, в дальнейшем мы не хотим её поддерживать.
А какой язык?
Сейчас выбираем между Lua и PAWN (который не очень скриптовый, зато маленький и быстрый). Скорее всего останется PAWN.
Ну а вещи типа стандартных драйверов (IR к таковым можно отнести) должны собираться в прошивке, а не писаться скриптом. Скрипт определяет взаимодействие между драйверами — чтобы по каждому чиху не грузить сеть и не дёргать центральный сервер.
0,5 МГц доступного диапазона — это очень мало отдельных каналов.А, там вообще 0.5? Тогда да.
Ну а вещи типа стандартных драйверов (IR к таковым можно отнести) должны собираться в прошивке, а не писаться скриптом.
А вы будете открывать исходники для того, чтобы можно было свой драйвер написать? Скриптовый язык, конечно, хорошо, но все-таки немного не о том — я говорю больше про поддержку всяких девайсов и странных протоколов, которые вы просто не будете поддерживать, потому что вам это не сдалось. Ну вот из последнего: CO2-датчик с обрезанным SPI, драйвер шагового двигателя, UART, в котором режим команды/данные управляется отдельной ножкой.
А, там вообще 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 я планирую отдавать в их официальный репозиторий. Но это в целом не играет большой роли: посторонний человек в этой теме всё равно без поллитры не разберётся, а те, кто понимает, что делают, могут напрямую к нам обращаться.
Но это в целом не играет большой роли: посторонний человек в этой теме всё равно без поллитры не разберётся, а те, кто понимает, что делают, могут напрямую к нам обращаться.
Ну вот это и смущает меня в написании драйверов — на хакатоне быстренько драйвер уже не запилишь, для любой любой работы с железом, выходящей за рамки скриптового языка придется вникать в тему и общаться с вами. Но ладно, это я к использованию модулей в DIY привязался, если использовать в сколько-нибудь крупном проекте, проблем не составит.
Человек, не имевший опыта работы с такими системами, вообще ничего там быстренько не запилит — ни на хакатоне, ни как-либо иначе. Они внутри специфические — это не ардуина, не линукс, и в данном случае даже не STM32.
Поэтому на хакатоне всё-таки предполагается работа на более высоком уровне абстракции.
Поэтому на хакатоне всё-таки предполагается работа на более высоком уровне абстракции.
Человек, не имевший опыта работы с такими системами, вообще ничего там быстренько не запилит — ни на хакатоне, ни как-либо иначе. Они внутри специфические — это не ардуина, не линукс, и в данном случае даже не STM32.
Да, я и говорю про это. И железо другое, и внутри помимо пользовательской задачи своя ОС крутится, которую надо не просто иметь ввиду, а принудительно использовать только ее очередь задач, таймеры, приоритеты и так далее.
Вот и предлагаю сделать для DIY/обучения/хакатонов простейший модуль с stm32/atmega, чтобы закидывать туда пользовательскую логику при необходимости таковой. Это будет проще, быстрее, и понятнее для неопытного разработчика, чем скриптовый язык, к которому надо еще и документацию писать.
Это бессмысленно с точки зрения использования за пределами хакатонов, а потому мы этого делать не будем. Желающие могут притащить ардуину с собой и делать что-то на ней.
P.S. Справедливости ради, три четверти модулей LoRa с набортным процессором сделаны именно так — стоит дохлое ядро (STM8L, PIC18F), которое просто реализует HAL между чипом LoRa и UART. Но это неэффективная реализация.
P.S. Справедливости ради, три четверти модулей LoRa с набортным процессором сделаны именно так — стоит дохлое ядро (STM8L, PIC18F), которое просто реализует HAL между чипом LoRa и UART. Но это неэффективная реализация.
Со временем будет скриптовый язык на конечных устройствах.
Зачем? Если это для какой либо высокой логики — то это тупиковый путь. Представьте себе, вы ошиблись где-то в этой логике или хотите что-то добавить. Будете бегать по этому вашему «кагату» и обновлять прошивку у всей сотни датчиков? Или пытаться делать это удаленно, по воздуху с риском превратить датчик в кирпич? Если вы взгляните на аналогичные системы сбора данных, то увидите, что предварительной обработки на датчике там минимум — разве что дребезг контактов, да перевод данных АЦП к нормальному виду. Но сама прошивка датчика — одна и не меняется от проекта к проекту. И как уже написали, для низкоуровневой обработки типа UART, или LCD — скорости интерпретатора будет недостаточно — это придется кодить на Си с изрядной привязкой к конкретному железу.
Зачем?
Для DIY и образования, в первую очередь.
Представьте себе, вы ошиблись где-то в этой логике или хотите что-то добавить
Шансов ошибиться в высокоуровневой логике — намного меньше, чем в низкоуровневой прошивке.
Если вы взгляните на аналогичные системы сбора данных, то увидите, что предварительной обработки на датчике там минимум — разве что дребезг контактов, да перевод данных АЦП к нормальному виду
Простите, это вы мне писали про туманные вычисления и распределённое I/O — или ваш evil twin?
Берёте современную систему АСУНО — и видите на одном модуле как минимум:
— стек LoRaWAN
— датчик освещённости
— датчик температуры
— часы и локальное расписание работы лампы
— вкл/выкл драйвера лампы и его диммирование
И всё это между собой взаимодействует.
Что такое АСУНО и что за модель модуля?
В гугле вас забанили, знаток SCADA-систем вы наш?
Автоматизированная система управления наружным освещением. Перечисленный функционал — базовые требования к исполнительному модулю современной АСУНО.
Автоматизированная система управления наружным освещением. Перечисленный функционал — базовые требования к исполнительному модулю современной АСУНО.
Не издевайтесь. Это могла бы быть и автоматизированная система управления насосным оборудованием. Я вас тоже могу закидать аббревиатурами, о которых вы и не слышали.
Так это все-таки требования или уже реализованная функциональность какого либо оборудования?
Так это все-таки требования или уже реализованная функциональность какого либо оборудования?
Это могла бы быть и автоматизированная система управления насосным оборудованием
Ну, в вашем параллельном мире может и могла бы. А в моём вся первая страница гугля совершенно однозначно указывает, что это такое, и вы — первый человек из индустрии (ну, вы, по крайней мере, утверждаете, что вы из неё, да ещё и с первого комментария свысока указываете нам, что мы не тем занимаемся — что предполагает некоторый уровень знаний), который эту аббревиатуру не понимает и не считает общеупотребимой.
На всякий случай: если мы дальше начнём про АСКУЭ, вы тоже сделаете круглые глаза, профессионал вы наш?
Я вас тоже могу закидать аббревиатурами, о которых вы и не слышали.
Вы эти пытались заниматься, я напомню.
Так это все-таки требования или уже реализованная функциональность какого либо оборудования?
(пожав плечами) У нас, например, реализована. У inteliLIGHT реализована. Много у кого реализована. И? Дальше что? К чему этот вопрос?
P.S. Я до сих пор жду рассказа, что такое «каналы связи IR и 433 МГц» и как вы будете решать описанную выше задачу с кагатами с каналами связи, которые у вас «уже есть и других не надо».
По поводу " некоторых растений есть суточные циклы"
Интересно было бы в агротехнических проектах за развитием листиков на ЭПР-спектрометре последить.
Это я так, по старой памяти, в университете на изучении фотосинтеза специализировался
Интересно было бы в агротехнических проектах за развитием листиков на ЭПР-спектрометре последить.
Это я так, по старой памяти, в университете на изучении фотосинтеза специализировался
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы хакатон про Интернет вещей делали