Здравствуйте, уважаемые любители Интернета Вещей. Продолжаю свой цикл статей.
Первая часть > Вторая часть > Третья часть > Четвертая часть > Пятая часть
Итак, мы научились работать с импульсным выходом счетчиков и освоили шифрование. Какой шаг следующий? Ответ очевиден. RS-485.
Чуть-чуть теории. RS-485 (Recommended Standard) – это асинхронный интерфейс физического уровня. Получил огромную популярность в Промышленном Интернете, начиная от ЖКХ и заканчивая различными заводами и предприятиями.
В принципе, почти любой счетчик, который хочет передать нам не один, а несколько параметров, скорее всего, будет снабжен RS-485. Реже RS-232 или M-Bus, но их пока оставим в стороне и разберем самый показательный пример. Точнее проблемы в работе с ним.
Проблема скорости
RS-485 – проводной стандарт. LoRa – беспроводная. Логично, что должно быть некое устройство, способное их подружить.
Все верно. Почти у каждого производителя оконечки в линейке есть радиомодуль с поддержкой RS-485. Работает по принципу прозрачного канала. Все пакеты, которые ходят по проводу, упаковываются в качестве полезной нагрузки пакетов LoRaWAN и уходят на передачу. Либо принимаются и преобразовываются в электрические импульсы.
И тут первая проблема. RS-485 – весьма скоростной интерфейс. Пакеты по нему ходят со скоростями в несколько килобит/сек или даже несколько десятков. К примеру, одна из типовых скоростей Modbus – 9,6 кбит/сек.
LoRa, даже при лучшем SF=7 (125 кГц, 4/5) выжмет 5,5 кбит/сек. С более высокими SF будет еще меньше.
Это значит, что опрос значений какого-нибудь электросчетчика займет не секунды, и даже не десятки секунд. Счет пойдет на минуты. И это еще при правильно отрегулированном времени ожидания. Если оставить настройки по умолчанию, то ваш опрос, скорее всего, окончится ошибкой таймаута. Я уж молчу про ограничения в длине пакетов LoRaWAN. Там просто беда.
Проблема опроса
С импульсными выходами все просто. Мы считаем импульсы, умножаем их на цену деления и получаем показания счетчика. С этим справится любой простенький интерфейс. И такой интерфейс, помимо простоты, будет еще универсальным.
С RS-485 все куда хуже. Удивительно, но многие не понимают одной важной вещи.
RS-485 – это НЕ ПРОТОКОЛ ОБМЕНА! Он не оговаривает формат пакетов, которые ходят внутри него. По сути – это просто среда передачи. Оговорены лишь электрические и временные характеристики интерфейса. Все! Все, что сверху уже надо разбирать отдельно.
А разбирать есть что! Поверх нашей среды каждый производитель может накрутить, что душе угодно. Ну, или что оказалось удобно лично ему. К примеру, теплосчетчик ВКТ-7 будет общаться с нами через ModBus. А Энергомера – через ГОСТ Р МЭК 61107-2001.
Это все протоколы, которые накладываются на среду передачи сверху и имеют более высокий уровень. Каждый протокол имеет свой состав кадра, требует своих команд на выполнение тех или иных действий, предусматривает различное хранение (а значит и опрос) значений. Следовательно, для каждого устройства необходим свой скрипт опроса. Более того, даже в рамках одного протокола (тот же ModBus) этот скрипт будет отличаться от устройства к устройству.
Сами по себе протоколы не являются тайной и, по большей части, открыты. Более того, сайт каждого производителя зачастую содержит бесплатную утилиту, с помощью которой можно приборы опрашивать. Но эти утилиты не универсальны и заточены под одного производителя. А мы помним, что у нас почти всегда зоопарк устройств. И ставить клиенту на компьютер несколько программ одновременно… ну это не слишком удобно.
Выхода два. Либо писать что-то свое. Либо взять программу, в которой уже скомпилированы скрипты опроса самых популярных устройств. На рынке немало готовых решений, скажем «ЛЭРС-учет» или «ЯЭнергетик». Но они платные и стоят хороших денег. Как и разработка своего софта.
Кроме того, если мы говорим про Промышленный Интернет (то есть выходим за рамки ЖКХ) готовые универсальные решения вам уже не помогут. Как быть?
Никак.
Если вы все еще планируете опрашивать через LoRa по прозрачному каналу, вы все равно упретесь в ограничения скорости и таймауты. Может не сразу и не с первым устройством, но это произойдет.
Проблема стандарта
Помимо всех бед, у нас есть еще одна. Т.к. RS-485 подразумевает, что мы можем обратиться к устройству в любой момент, радиомодуль LoRa с его поддержкой должен быть класса С. То есть всегда слушать эфир и быть готовым ответить.
Напомню, что класс С не подразумевает батарейного питания, но тут беда не столь серьезная. Обычно, RS-485 находится там, где внешнее питание можно раздобыть.
Хуже другое.
По закону, мы можем работать в двух частотных диапазонах. Помните, ограничение в 864-865 МГц? Не более 0,1 % времени в эфире? Это значит, что каждое отдельно взятое устройство может находиться в эфире, допустим, не дольше 3,6 секунд в час. Но за это время, на SF=12 мы даже три пакета не пропихнем.
Можно попробовать выжать максимум из каналов 868,7-869,2. Однако тут вступает в силу уже другое ограничение региональных стандартов спецификации LoRaWAN – не более 1 процента времени в эфире для каждого оконечного устройства (duty cycle). ОК, уже полегче, 36 секунд. Только толку все равно не особо.
В какой-то момент, мы можем сказать – да ну их, эти глупости! Буду сидеть в эфире столько, сколько нужно! Но тут появляется:
Проблема емкости эфира
LoRa не зря обменивается короткими и редкими пакетами. По сути, вокруг этого построен весь стандарт. Нужно, чтобы каждое устройство занимало максимально мало времени в эфире. Тогда мы снизим риск коллизий и сможем достичь той самой фантастической плотности в несколько тысяч радимодулей на одну БС. Что же будет, если один радиомодуль строчит пакетами как из пулемета? Его частота занята в момент передачи. А в момент ответа заняты вообще все частоты, т.к. базовая станция ничего не слышит, когда передает сама.
Разумеется, никто не отменял заделы на увеличение емкости. Т.е. если в зоне действия одного радиомодуля будет две БС, отвечать будет все равно одна, а вторая может услышать какой-то другой пакет. Однако, эфир не резиновый. Если каждый радиомодуль будет занимать минуту на обмен пакетами, то в час на одну БС мы сможем повесить не более 60 оконечных устройств, это еще при условии отсутствия коллизий. Очень мало, особенно если вспомнить, что радиус действия каждой БС в городе – порядка 2 км, а может и больше.
Значит, нет?
Получается, что наша сеть LoRaWAN ограничена только устройствами с импульсным выходом и сторожевыми системами, где регистрируется факт сработки?
Нет.
Просто мы попытались использовать концепцию Интернета Людей там, где этого делать нельзя. Согласитесь, нам привычно избыточно использовать стабильный Интернет-канал. Например, открыть видео, прихватив запас в буфере, и не досмотреть. Т.е. трафик пройдет, но по факту не будет использован.
Однако, здесь все иначе. Скорости у нас мало, времени в эфире тоже. Надо использовать его экономно. Что можно придумать?
Ответ на поверхности. Не гонять через LoRa кучу служебного трафика протоколов поверх RS-485.
Скрипт опроса можно загрузить в сам радиомодуль. Он будет на месте опрашивать счетчик с определенной частотой и высылать нам только сухие, заранее оговоренные значения.
У этого метода два минуса:
- Такой радиомодуль требует определенных вычислительных ресурсов. Это не большая проблема на текущем уровне развития технологий.
- Такой радиомодуль потребляет больше энергии. Но в случае прозрачного канала мы вынуждены использовать класс С, который так же не от батарей живет. То на то и выходит.
Зато мы получаем всю необходимую нам информацию в 2-3 пакетах. А то и в один все поместится, если нужно буквально несколько параметров. Ведь часто бывает, что нам не нужно передавать ВСЁ, достаточно ограниченного набора значений.
Радимодуль может передавать данные, допустим, раз в час. А на стороне сервера мы будем складывать их в хранилище. Если потребуется обратиться к архиву, то серверу даже не придется опрашивать устройство.
Разумеется, что нужно иметь некий универсальный радиомодуль, в который загружаются различные скрипты. И интерфейс, способный такую информацию воспринимать. Это не простой путь, но только он отвечает всем требованиям и ограничениям.
В данный момент, к этому решению приходят все больше производителей. Готовятся подобные устройства у Веги, уже есть у icbcom, ОРИОН М2М и других.
Т.к. мы используем самописный интерфейс, то подобные разработки есть и у нас. В какой-то момент стало ясно, что если не полезем глубже, просто не сможем работать.
Помимо хитрости с экономией трафика, нам по-прежнему требуется хорошая сеть, в которой устройства работают на минимальном SF и максимальной скорости. Я подчеркну – не такая сеть, в которой все устройства с SF=7. Вы этого все равно не добьетесь.
Такая сеть, которая стремится к SF=7. Это значит грамотное планирование и ADR.
На выходе получим достаточные скорости для хождения пакетов, по-прежнему большое число радиомодулей на одну БС и возможность работать с интерфейсами уровня выше импульсного выхода. Что и требовалось.
P.S. Коллеги, я благодарен всем за обратную связь. Скажите, что вам еще интересно узнать про LoRaWAN или Интернет Вещей? Ответы можете писать мне в личку или в комментариях. По самым интересным или массовым запросам будут выходить статьи.
Комментарии (47)
j_wayne
15.06.2018 10:30> Т.к. RS-485 подразумевает, что мы можем обратиться к устройству в любой момент, радиомодуль LoRa с его поддержкой должен быть класса С. То есть всегда слушать эфир и быть готовым ответить.
А если все таки нужно батарейное питание? Скажем, бывает ли такой режим у распространенных модулей, чтобы первый пакет разбудил модуль, а второй уже можно было принять?olartamonov
15.06.2018 10:47+1Нет, приёмник сам по себе слишком много жрёт, 11 мА в SX127x и в районе 5 мА в новых SX126x.
Есть класс B, нормально описанный только в свежей спецификации 1.1, он включается на послушать эфир по расписанию, без собственной передачи. Получается компромисс по энергопотреблению и доступности между A и C.
Ну и RS485 сам по себе не то чтобы сильно экономичный.j_wayne
15.06.2018 11:34Спасибо, значит как вариант лишь сетевое + бэкап.
Interfer Автор
16.06.2018 13:38Вы спрашиваете именно про вариант работы «прозрачный канал»? Т.е. опрос модуля в любой момент времени?
j_wayne
16.06.2018 15:26Думаю, да. То есть, чтобы слушал, но в экономичном режиме, что-то вроде BLE 4.0.
Первыми пакетами можно пренебречь.
Т.е. нужна возможность постоянного вызова, с некоторой оперативностью — расписание не подойдет.olartamonov
16.06.2018 16:17Есть вариант с периодическим запуском на трансивере лоры режима CAD, Channel Activity Detection — он быстро слушает эфир на предмет наличия в нём преамбулы, и если таковой нет, засыпает.
Но если у вас эфир достаточно сильно загружен общением с другими устройствами, это не поможет — будет постоянно просыпаться на чужие пакеты. Кроме того, CAD делается однократно по команде, то есть требует просыпания микроконтроллера, и по очевидной причине периодичность этих просыпаний должна быть такой, чтобы преамбулу точно успеть поймать — а у неё фиксированная длина в символах, т.е. с падением SF и прембула становится всё короче…
P.S. Вообще у Семтека был калькулятор энергопотребления, можно скачать и поиграться.
Makc_K
15.06.2018 12:03То, что вы описали — на самом деле не проблемы. Проблемы будут, если начнёте подключать ещё более «умные» приборы по интерфейсам. Особенно, имеющими свои архивы. Текущие данные запросить несложно. А вот выкачать с какого-нибудь расходомера часовые архивы за несколько месяцев — вот тут и начнутся танцы с бубнами.
olartamonov
15.06.2018 16:03В общем случае такую задачу на LoRaWAN можно считать нерешаемой.
Ну либо решаемой, но дня за три неспешного скачивания тех архивов маленькими кусочками.Makc_K
15.06.2018 16:07Вы сейчас очень сильно сузили область применения Лоры. По крайней мере для меня.
Видимо будущее промышленной телемеханики всё-таки за NB-Iot.olartamonov
15.06.2018 16:09Ну, как только сможете найти NB-IoT вне зоны покрытия LTE…
Makc_K
15.06.2018 16:13) более правильный вопрос — когда NB-Iot запустится в коммерческую эксплуатацию? В Беларуси/Белоруссии уже вполне себе работает, по словам местных разработчиков.
Ну а в общем, где нет LTE придётся по старинке GPRS/EDGE/3G.Interfer Автор
16.06.2018 13:42Каждую техзадачу нужно решать отдельно. И смотреть, что для нее лучше подходит. Я бы не хоронил Лору прежде времени, однако для определенного круга задач она правда не самое лучшее решение. И если уж мы говорим о промышленном предприятии, то там может и NBIoT окажется не к месту, а самым рациональным решением станет… Ну не знаю? Wireless HART?)
Может так получится, что беспроводка вообще не годится, если стоит какая-нибудь электромагнитная плавильная печь.
sguslya
16.06.2018 11:55Не знаете, есть ли на практике разница в энергопотреблении между одним и тем же датчиком на лоре и nb-iot?
Interfer Автор
16.06.2018 13:52NBIoT есть примерно в два раза больше LoRa на передаче и больше, чем в три раза на прием. Их не очень корректно сравнивать в лоб из-за разницы скоростей и общей разницы концепций. Однако, факт остается фактом, у NBIoT есть определенные проблемы с питанием и батареи им требуются хорошие.
olartamonov
16.06.2018 15:15Если б в два. Там по паспорту больше 200 мА на TX может быть против 29 мА у SX127x на +13 дБм.
olartamonov
16.06.2018 15:14Средняя температура по больнице примерно одинакова, но
1) у модулей NB-IoT пиковый ток при передаче на полной мощности — больше 200 мА, у LoRa — 30 мА
2) большая часть имеющихся сейчас в продаже модулей NB-IoT рассчитаны на работу от перезаряжаемого аккумулятора (3,2 — 4,2 В), LoRa — от батарейки (2,0 — 3,6 В)
В результате там, где лора годами живёт на ER14505 (3,6 В, 2400 мА*ч), придётся впихивать или обычный LiMNO2 3,0-вольтовый, или умощнённую ER14505M, которая способна вытянуть пиковое потребление NB-IoT, в обоих случаях с потерей в ёмкости в 20-30 %, а со многими модулями — ещё и с повышайкой до 3,6-3,8 В. И вот это будет печально.
Klukonin
18.06.2018 14:29За Wi-Fi.
NB-IoT — это та же лора, ну, может, чуть лучше, только с симкой.
Проблемы те же самые + дополнительные с регистрацией/установкой и обслуживанием симок.Makc_K
18.06.2018 14:38Не согласен. NB-Iot будет доступен в зоне действия БС с поддержкой LTE. За инфраструктуру сети отвечают операторы сотовой связи. Канальный, транспортный, сетевой, и частично физический уровень OSI — всё на операторе сотовой связи. Для разворачивания требуется только купить и установить SIM-карту оператора, фирменный цвет, которого больше нравится. Причём работать будет, как в центре мегаполиса, так и в поле (не скоро и не точно). Wi-Fi же для этих целей — чуть ли не худший вариант.
Я лично ходил (потому, что даже внедорожник там не проедет) по лесам Псковщины и степям Астраханьщины и осуществлял пуско-наладку систем телеметрии по GSM.
Там, где между объектами телемеханизации десятки км ни Лора, ни тем более Wi-Fi не применимы.Klukonin
18.06.2018 14:52А давайте еще более жесткий сценарий возьмем — сбор показаний на Луне!
1) Как в голове может умещаться «Просто установи сим карту» напротив «непролазных лесов и степей?» Я постоянно путешествую по местам, где никакиго LTE и даже 3G нет. Для этого достаточно сесть на электричку и проехать километров 30 от города.
2) Мухи отельно, котлеты отдельно. Промышленная автоматизация зданий и объектов и сбор показаний в условиях тундры — это два абсолютно разных сценария с абсолютно разными подходами/используемыми технологиями.
3) Если мы говорим о рынке, то автоматизация объектов, между которыми десятки километров — это жалкие крохи. В качестве контрпримера — ну да, сойдет. Как альтернативный сегмент рынка — нет. В городской и промышленной автоматизации Wi-Fi в большинстве сценариев будет лучшим решением.olartamonov
18.06.2018 15:02В городской и промышленной автоматизации Wi-Fi в большинстве сценариев будет лучшим решением
Рассчитайте систему управления уличным освещением на Wi-Fi. 100 кв. км, 20 тысяч ламп.
Да что там уличное освещение, сделайте смеха ради проект съёма показаний с тех же водосчётчиков по Wi-Fi. Жилой дом, 160 квартир. С радиопланированием, гарантирующим покрытие, и счётчиками с ресурсом работы без смены элемента питания 8 лет.
Imbecile
16.06.2018 18:57+1Хороший цикл статей, спасибо
А LoRa рассчитана исключительно на стационарные оконечные устройства? Или есть варианты с редкоподвижными (раз в день/неделю/месяц) переехали в зону действия другой БС? И просто подвижные, когда оконечное устройство может начать передачу в момент движения?Interfer Автор
16.06.2018 19:01Устройства могут быть мобильными. Спецификация это предусматривает.
Если брать практику, то я пробовал возить устройство с собой в машине по городу — потери пакетов не наблюдалось. Однако, прям длительных тестов на подвижность не делали и уж точно не тестировали на больших скоростях.
Спасибо за отзыв)
olartamonov
17.06.2018 11:37LoRa — это физуровень, канал связи.
MAC поверх него может быть разный, если это LoRaWAN, то в нём роуминг между БС одного оператора автоматический. Там БС вообще тупая как пробка, её задача — сигнал из эфира принял, в обёртку завернул и по эзернету или 3G в сторону сетевого сервера выплюнул.Interfer Автор
18.06.2018 06:54Все верно.
Я не уверен, что это вообще можно назвать роумингом в классическом понимании. Скорее БС LoRaWAN можно сравнить с портами неуправляемого коммутатора. В какой ни воткни разъем — смысл будет одинаковый и решение принимает нечто, стоящее дальше по иерархии.
Barsevich
17.06.2018 06:35Ну вот и вылезла ограниченность применения.
Только кажется, что посчитать импульсы и передать их — это достаточно. Это достаточно для курсовой работы первого курса, по факту задачки сбора показаний со счетчиков — посложнее. Сразу оговорюсь, что серебряной пули нет, но:
— при сборе показаний с теплосчетчика желательно видеть все измеряемые величины — обе температуры, расход теплоносителя, код состояния (в рудиментарном случае квартирного теплосчетчика). Если нет импульсов от квартирного теплосчетчика, то может быть целый набор ситуаций (разрешенных и нет) от закрытых кранов до оборванного термометра или застопреной крыльчатки. Через импульсный выход этого не увидеть и одно состояние от другого не отличить. Как и от оборванного импульсного выхода. В случае общедомового (промышленного) теплосчетчика — параметров может быть в разы больше.
Архив на сервере — хорошо, но как только часы LORA-устройства разойдутся с часами теплосчетчика, а это точно произойдет, весь архив на сервере потеряет ценность.
С электросчетчиками — абсолютно аналогичная ситуация, еще более осложненная «двухтарифностью» — часы разойдутся, и показания с LORA — устройства обесценятся.
Если быть правдивым, не совсем обесценятся — они станут тем, что в среде метрологов называют «показометром» — им можно верить «для личного пользования», но их нельзя использовать для коммерческих расчетов.
Вода — тут тоже непросто, но сложности другие. Через импульсный выход нельзя отличить, крутится счетчик вперед или назад, когда крутился вперед-назад (это проблема перетока в смесителях и кривых разводках труб, встречается в каждом доме обязательно), воздействие магнитов и когда провод импульсного выхода оборван. Частично эту проблему решает НАМУР (для детекта оборванности импульсного выхода), остальные можно решить только встраивая интерфейс в счетчик.
И тогда получается, что в многоквартирных домах провод всегда дешевле для электросчетчиков и теплосчетчиков — т.к. они в 95% случаем стоят в местах общего пользования, для водосчетчиков решение импульс+радиопередача — живое, но такие решения есть уже лет 10, и живые и работают и без LORA.
Получается, что сегмент применения, где решение действительно даст что-то, чего не было раньше — это передача на более-менее большие расстояния — коттеджные поселки, деревни, дачи? Тут они конкурируют с NB-IOT и GPRS.
Одиноко стоящие подстанции и промышленные узлы учета всегда проще оборудовать GPRS-модемом. Даже электросчетчики, которые сейчас в загородных поселках выносят группами на улицу проще оборудовать одним GPRS-модемом.
Получатся что сегмент очень ограничен. По крайней мере в ЖКХ.Interfer Автор
17.06.2018 07:09Давайте по порядку.
1) Не следует путать систему телеметрии с системой контроля хитрости) Меня часто спрашивают — может ли LoRa как-то помочь против магнитов или иных уловок на индивидуальных приборах учета. У меня один ответ.
А парень с карандашом и блокнотом, который попадает в одну квартиру из пяти или показания жильцов, которые они вбивают через Интернет смогут помочь выявить магнит?)
Насчет обрыва — у нас есть система мониторинга, что внезапно стали приходить нулевые значения. Само по себе это еще ничего не значит, но повод назначить ремонт на объект.
Кроме того, внешние радиомодули — это все-таки переходный период. Я думаю, что скоро будем иметь устройства с интегрированным радиомодулем. И вот тогда NBIoT потребует куда большей батарейки. Я уж молчу про GPRS, к нему вообще допшкаф понадобится)
2) Я не совсем понял вашу мысль с часами. Ну вот будет у нас рассинхрон c внутренними часами теплосчетчика. Ну или электросчетчика. Почему показания обесценятся? Вы считаете, что этот рассинхрон набежит в полчаса?Barsevich
17.06.2018 12:271) Я и не путаю. Я знаю реальные требования заказчиков, и они живут не в идеальном мире систем с узким предназначением, им надо решать комплексные проблемы, и данные снимать, и манипуляции отслеживать. И эволюция систем уже давно повернула в эту сторону.
Насчет обрыва — вы не сможете отличить — человек уехал в отпуск или у него сломался счетчик. И вы назначаете выезд на ремонт. Вы систему создаете, чтобы этих выездов не было, тем более — ложных.
Что касается GPRS — то вы тоже не правы. Никто не заставляет держать модуль GPRS постоянно включенным. А системы, которые его включат с настраиваемым интервалом для передачи данных я первый раз видел на выставке лет 6 назад. И работают нормально в своих сегментах.
Про часы написал ниже.
Не у всех, кто выходит на этот рынок, хватает широты взгляда чтобы оценить, что до них эту тему качают уже два десятка лет, и люди общаются с заказчиком и под его требования разрабатывают системы. И все это вымучено, выстрадано, многократно пропущено через себя и множество разнообразных кейсов. И многочисленные «невзлеты» новичков на этом поприще — это как раз из-за этого. Когда они это понимают, у них уже кончаются деньги.
Система сбора данных — это не самоцель, это лишь инструмент для решения совсем других проблем. И не надо думать, что кому-то нужна «чистая телеметрия и больше ничего». Как самоцель, по крайней мере в ЖКХ, она не нужна никому.Interfer Автор
17.06.2018 16:521) ОК, давайте поговорим про решение проблем воровства. Как вы хотите сделать это с помощью GPRS?
Собрать в одном корпусе индивидуальный водосчетчик, батарейку и передатчик GPRS не получится. Точнее получится, но долго эта конструкция не проживет. А вот на Лоре это вполне реализуемо.
2) Вы преувеличиваете проблему рассинхрона. Часы радимодуля можно подводить специальной командой. Пока таких проблем нет, но если они возникнут — просто добавим серверу в задачи отправлять команду синхронизации раз в… ну пусть раз в месяц. И все у нас будет актуально.
Что же касается внутренних часов теплосчетчика, был бы у них сертификат, если бы в конце срока эксплуатации там был рассинхрон в десятки минут?
3) Ну и наконец. Мы же можем запрашивать время с теплосчетчика, как один из параметров. И вуаля! У нас данные с первичного источника.Barsevich
17.06.2018 17:511) Я не говорил, что «водосчетчик со встроенным GPRS» — это решение. Я сразу написал —
Сразу оговорюсь, что серебряной пули нет
Я писал вам про то, что реализуемо на Лоре — уже 10 лет как есть на рынке, и ничего нового с точки зрения эксплуатации, с точки зрения приближения к этой самой «серебряной пуле» она (Лора) не предлагает.
2) Во всех документах, в ПП354, в правилах учета ТЭ и ТН — везде фигурирует первичный прибор и его архив. Нигде не написано, что его часы должны иметь сертификат. Но он — первичный прибор. И в итоге будут обращаться к его архиву. А если ваша система выдает данные, отличные от его архива, то доверия нет к системе, а не к прибору. Если вы посылаете безграмотного человека снимать показания, и он их неверно переписал — то нет доверия к системе (снятия показаний), а не к прибору. Пока у прибора есть поверка — доверие к нему абсолютное.
3) Ну да, я сам это написал ниже часов пять назад. Я думаю, что это костыль, и на нем далеко не уедешь.Interfer Автор
17.06.2018 17:581) Серебряной пули нет, тут вы правы. Но все ищут решение максимально приближенное к идеалу.
С моей колокольни — это устройства с интегрированными передатчиками. Я могу быть не прав.
2) и 3) А почему вы считаете, что забирать время у прибора учета — это костыль? Получается, что любая система диспетчеризации — это костыль?Barsevich
17.06.2018 18:531) Я с вами согласен, устройства с интегрированными передатчиками — это решение.
2)3) предвижу сложности с разными приборами, разными протоколами, переводом часов и сменой тарифных расписаний, возведенное в степень абсурда происходящего вокруг. Но волков бояться — в лес не ходить, как завещал нам анекдот — «хули думать — прыгать надо»
olartamonov
17.06.2018 11:41Никого не волнует рассинхрон одной железки с другой железкой. Рассинхрона не должно быть с московским временем — и на радиомодуле с двунаправленным каналом это обеспечить с приемлемой точностью (плюс-минус секунды) можно.
Ценность собственных часов счётчика в этом случае остаётся значимой постольку, поскольку он хранит архив показаний и является первичным средством измерения. Если, однако, радиоинтерфейс, даже внешний, сертифицирован как средство измерения, то сам счётчик часов может хоть вообще больше не иметь.Barsevich
17.06.2018 12:15Ну да, примерно так. Как только у вас в системе произойдет рассинхронизация с собственным архивом прибора, пропадает доверие к системе, т.к. она не способна без искажений передать внутренний архив прибора. А поверка систем измерения (если, конечно, сертификат не «куплен» на том и строится, что доказывается неискажаемость данных и невозможность манипулирования ими.
Кончено, положа руку на сердце, LORA-устройству можно по своим часам каждый час считывать 5 последних часовых записей или даже синхронизировать свое время со временем прибора. Но это костыли, на которых можно и не взлететь.olartamonov
17.06.2018 12:19Если радиомодем сертифицирован как средство измерения, пригодное для ведения коммерческих расчётов, и имеет собственный архив показаний, то всем пофигу, что там в приборе происходит. Истиной в последней инстанции в этом случае является радиомодем.
Кроме того, если у прибора есть архив показаний — то и выход у него обычно есть не только импульсный, а вариации на тему UART, по которым можно читать и архив, и текущее внутреннее время. И тогда всем пофигу, что там с часами в радиомодеме.Barsevich
17.06.2018 12:33Если только радиомодем корректно передает его внутренний архив. Мы же смотрим на это сквозь призму конфликта, правильно? Как вы написали выше,
Ценность собственных часов счётчика в этом случае остаётся значимой постольку, поскольку он хранит архив показаний и является первичным средством измерения
.
Скорее всего в случае конфликта будут смотреть на первичное средство измерения. И если его архив не совпадет с архивом системы, и суд примет решение, основываясь на архиве первичного прибора (а скорее всего так и будет), и вот тогда доверие к системе будет подорвано. После суда заказчик спросит — «А зачем нам система, если мы с такой системой суды проигрываем?»
shekelgruber
17.06.2018 14:36> оборудовать GPRS-модемом
Сим-карты кто будет в этих модемах менять? Пушкин, Александр Сергеевич? Или вы работаете в «АО ГЛОНАСС» и эти вопросы вас, как в случае с Эрой-Глонасс, не волнуют?Barsevich
17.06.2018 15:29Я не работаю в ЭРА-ГЛОНАСС. А зачем менять SIM-карты?
shekelgruber
18.06.2018 14:42Сим-карты имеют обыкновение умирать по самым разным причинам, блокироваться оператором и так далее. Частично проблема решается использованием «специальных» сим-карт и тарифов (это не всегда доступно). «Бытовые» же карты имеют лимит на количество регистраций в сети (несколько тысяч — исчерпывается довольно быстро, если модем большую часть времени спит и при каждом сеансе связи заново регистрируется) — ну и не стоит забывать о приколах наших операторов с подпиской на разные интересные услуги без ведома абонента.
sguslya
18.06.2018 12:36Про обратную связь…
Все lpwan интеграторы/операторы зачем то идут в ЖКХ. Это алый океан бизнеса, он переполнен акулами, маржинальность минимальна, проблемы максимальны. Зачем оно вам?Makc_K
18.06.2018 12:52Теоретически ЖКХ — оптимальная задача для Лоры. Большое количество достаточно простых устройств, концентрирующихся на небольшой площади. Трудно представить более подходящие условия.
Большинство других задач гораздо проще решаются проводом или GSM.
xapon
С интересом читаю ваш цикл статей, очень познавательно!
Я недавно закончил магистратуру в CMU, там плотно работал с профессором, который занимается связью, особенно IoT и LoRaWAN. Со многими проблемами, которые вы описываете (низкая скорость, лимиты на размер пакета, загруженность сети) мы тоже сталкивались и пытались решать.
У нас была идея в том, чтобы мультиплексировать доступ к сети через TDMA.
В основе этого решения — синхронизация времени на устройствах, этим я в основном и занимался. Если все пройдет удачно, эту работу могут принять в стандарт LoRaWAN — и может быть всем будет полегче строить поверх этого более нагруженные сети.
Interfer Автор
Кстати, очень много стартапов пилят свой стек, т.к. недовольны LoRaWAN.
А вы прямо связывались с LoRa Альянсом, и предлагали свои разработки?
xapon
Профессор в контакте с semtech, да. Подробностей не знаю, но мы готовим пейпер на NSDI 2019 на эту тему, и он в первую очередь попадет к ним.