Коротко про головне
У 2017 році на Хабрі з'явилася нотатка “”. У 2018 році технічний комітет "Кіберфізичні системи" :
ГОСТ Р «Інформаційні технології. Інтернет речей Терміни та визначення",
ГОСТ Р «Інформаційні технології. Інтернет речей Еталонна архітектура інтернету речей та індустріального інтернету речей», ГОСТ Р «Інформаційні технології. Інтернет речей Протокол обміну для Інтернету речей у вузькосмуговому спектрі (NB-FI)».
У лютому 2019 року ПНСТ-2019 «Інформаційні технології. Інтернет речей Протокол бездротової передачі на основі вузькосмугової модуляції радіосигналу NB-Fi». З 1 квітня 2019 року він почав діяти та завершить свою дію 1 квітня 2022 року. За три роки дії попередній стандарт має бути випробуваний на практиці, має бути оцінений його ринковий потенціал, підготовлені поправки до стандарту.
У ЗМІ документ активно позиціонується як "перший національний стандарт IoT РФ, з перспективою стати міжнародним стандартом" і в приклад наводиться реалізований на NB-Fi "ВАВІОТ" .
Уххх. Скільки посилань у такому короткому тексті. Ось — на текст попереднього стандарту в першій редакції для тих, кому ліньки гуглити. ТТХ стандарту краще дивитися в цьому документі, у статті ми їх не згадуватимемо.
Про стандарти передачі IoT
У мережі можна натрапити на значення близько 300 протоколів/технологій передачі даних між пристроями, які можна віднести до IoT. Живемо ми в Росії, працюємо на B2B, тому в публікації торкнемося лише кілька:
- NB-IoT
Стандарт стільникового зв'язку для телеметрії пристроїв. Один із трьох, що реалізуються в мережах LTE Advanced — NB-IoT, eMTC та EC-GSM-IoT. Велика трійка стільникових операторів РФ у 2017-2018 роках розгорнули ділянки мереж, що працюють із NB-IoT. Про eMTC та EC-GSM-IoT оператори не забувають, але виділяти їх окремо зараз не будемо.
- Lora
Працює на частотах, що не ліцензуються. Добре про стандарт розказано у статті кінця 2017 року “Що таке LoRaWan” на Хабрі. Живе на чіпах Semtech.
- "Стриж"
Працює на частотах, що не ліцензуються. Вітчизняний постачальник рішень для ЖКГ та інших галузей. Використовує протокол XNB. Говорять про виробництво в Росії, але обіцяють забезпечити масове виробництво чіпів у Росії тільки в 2020 році, поки живуть на ОН Semiconductor (ON Semiconductor AX8052F143).
- Свіжий NB-Fi
Працює на частотах, що не ліцензуються. Використовує той же чіп ON Semiconductor AX8052F143 як і "Стриж", ТТХ аналогічні, теж анонси виробництва власних чіпів в Росії. Загалом взаємозв'язок простежується. Протокол відкритий.
Про інтеграцію з білінгами
Для тих, хто намагався зібрати собі “розумний будинок”, швидко стає очевидним, що використання датчиків різних виробників суттєво ускладнене. Навіть якщо на двох пристроях бачимо один напис про технологію зв'язку, з'ясовується, що комунікувати вони один з одним не хочуть.
У сегменті B2B ситуація аналогічна. Розробники протоколів, чипів хочуть заробляти. Починаючи проект з LoRa, потрібно буде в будь-якому випадку купувати обладнання на чіпах Semtech. Звертаючи увагу на вітчизняного виробника, можна отримати в навантаження покупку сервісів і базових станцій, а в майбутньому, при успішному запуску виробництва чіпів в Росії, потенційно обладнання/елементну базу можна буде купити лише у обмеженої кількості вендорів.
Ми працюємо з телеком обладнанням і для нас звично отримувати дані по телеметрії обладнання, агрегувати, нормалізувати та передавати далі у різні інформаційні системи. За цей блок робіт відповідає Forward TI (Traffic Integrator). У типовому варіанті це виглядає так:
У разі розширення потреб замовника зі збору даних підключаються додаткові модулі:
Орієнтовна швидкість зростання ринку IoT-пристроїв - 18-22% на рік у світі та до 25% у Росії. У квітні на IoT Tech Spring 2019 у Москві Андрій Колесников, директор Асоціації інтернету речей, озвучував річне зростання у 15-17%, але по мережі різна інформація ходить. На РІФ у квітні 2019 року на слайдах давали дані про щорічне зростання російського ринку Інтернету речей у 18% до 2022 року, там же було вказано обсяг російського ринку в 2018 році — $3.67 мільярда. Що характерно, на цьому ж слайді згадували і привід для сьогоднішньої статті «Затверджено перший російський документ зі стандартизації в галузі IoT…». На нашу думку, назріла вже реальна потреба штатно інтегрувати базові станції UNB/LPWAN та телекомунікаційних серверів у білінгові системи.
роздуми
Перша лінія
Протокол передачі даних або взагалі реалізація транспортної функції великого значення не матиме (це ми знову про те, що IoT – це не просто праска, підключена до інтернету, а інфраструктура або екосистема). Дані будуть збиратися з різних пристроїв і корисне навантаження буде теж різною. Навряд чи компанія постачальник електроенергії будуватиме одну мережу збору даних, постачальник газу свою другу мережу, служби водовідведення третю тощо. Це не раціонально і малоймовірно.
Значить в умовній локації організовуватимуть мережу за одним принципом і збиратимуть дані одна організація. Назвемо таку організацію оператор-агрегатор даних.
Оператор-агрегатор може бути сервісною службою, яка здійснює лише передачу даних, або повноцінним посередником, який перебирає всі складнощі з тарифікації, організації оплати наданих послуг, взаємодію з кінцевими абонентами-клієнтами та постачальниками послуг.
Багато разів бачив, як люди вигрібають із поштової скриньки штук по 5 квитанцій щомісяця, для мене самого така ситуація знайома. Окрема квитанція на газ, окрема на електрику, окрема на капітальний ремонт, окрема на воду, окрема обслуговування будинку. І це не рахуючи оплати щомісячних рахунків, які існують тільки в онлайні - оплата доступу в інтернет, стільникові, передплати на різні сервіси постачальників контенту. Десь можна налаштувати автооплату, десь не можна. Але загальна ситуація така, що це вже стає традицією – сідати раз на місяць та оплачувати всі рахунки, процес може розтягуватися на півгодини-годину, а якщо в черговий раз щось в інформаційних системах постачальників глючить, то доводиться переносити частину оплат на інший день. . Я хотів би взаємодіяти з одним постачальником послуг з усіх питань, а не поділяти увагу на десяток платіжок і сайтів. Сучасні банки полегшують життя, але не повністю.
Тому автоматичний збір даних із спожитих послуг та перенесення кінцевого клієнта оплати послуг в одне «вікно» — це благо. Згаданий вище збір даних через трафік інтегратори типу нашого Forward TI – це лише вершина айсберга. Трафік інтегратор є першою лінією, через яку будуть збиратися дані телеметрії та корисне навантаження і на відміну від провайдерів, яким важливий обсяг споживання трафіку сам по собі, в IoT пріоритет надаватиметься корисному навантаженню.
Давайте на своєму прикладі з телекому розглянемо, чим займається перша лінія. Є оператор, який надає послуги зв'язку. Відбувається дзвінок тривалістю 30 хвилин. 15 хвилин дзвінка потрапили в одну добу, 15 в іншу. Телефонна станція на межі доби розділила дзвінок і записала його в 2 CDRa, по суті, зробила з одного дзвінка два. TI за непрямими ознаками склеїть такий дзвінок і передасть у систему тарифікації дані про один дзвінок, хоча з обладнання дані прийшли про два. На рівні збору даних має бути система, яка вміє дозволяти такі колізії. А ось наступна система має отримувати вже нормалізовані дані.
Інформація у трафік інтеграторі не лише нормалізується, а й збагачується. Ще один приклад: з телефонної станції не надходять дані для зональної тарифікації, але ми знаємо з якої локації був зроблений дзвінок і TI додає інформацію про географічні зони тарифікації дані, які передає в наступну інформаційну систему. Аналогічно можна проставляти будь-які параметри, що обчислюються. Це приклад простого зонування чи збагачення даних.
Ще одна функція трафік інтегратора – агрегація даних. Приклад: з обладнання приходять дані щохвилини, а в облікову систему TI віддає дані за годину. В обліковій системі залишаються лише дані необхідні для тарифікації та виставлення рахунків, замість 60 записів робиться лише один. При цьому відбувається резервне копіювання "сирих" даних у разі необхідності їх обробки.
друга лінія
Продовжимо розвивати ідею для агрегатора, що став повноцінним посередником. Такий оператор обслуговуватиме мережу збору даних та розділятиме телеметрію та корисне навантаження. Телеметрія буде використовуватися для власних потреб, підтримки мережі збору даних у справному стані, а корисне навантаження оброблятиметься, збагачуватиметься, нормалізуватиметься і передаватиметься постачальникам послуг.
Хвилина самореклами, бо простіше на своєму софті ілюструвати, ніж вигадувати абстрактні приклади.
На цій лінії агрегатор використовує у своєму інвентарі:
- Billing, що враховує надходження підготовлених даних від TI, прив'язку їх до зареєстрованих споживачів (абонентів), коректну тарифікацію цих даних відповідно до тарифного плану, формування рахунків і квитанцій, прийом коштів від абонентів та рознесення їх на відповідні рахунки та баланси.
- PC (Product Catalog) для створення комплексних пакетних пропозицій та управління послугами у складі цих пакетів, завдання правил підключення додаткових послуг.
- BMS (Баланс-менеджер), дана система обов'язково має бути багатобалансова, потрібно гнучке управління списаннями за різні послуги, також вона дасть можливість використання кількох спеціалізованих білінгових систем, що обслуговують окремі послуги та агрегації отриманих від них розрахунків стосовно загального балансу абонента.
- eShop для взаємодії з кінцевими споживачами, створення публічної вітрини послуг, надання доступу до Особистого кабінету з усіма сучасними плюшками на кшталт статистики використання послуг, перемикання послуг в онлайні, звернень за новими послугами.
- BPM (Бізнес-процеси) автоматизація бізнес-процесів агрегатора, спрямованих як на обслуговування абонентів, так і на взаємодію з постачальниками послуг.
Третя лінія
Ось тут починається найцікавіше на мій погляд.
По-перше, виникає потреба в системах класу PRM (Partner Management System), яка дозволить гнучко керувати агентськими та партнерськими схемами. Без такої системи керувати роботою партнерів та постачальників буде складно.
По-друге, виникає потреба в DWH (Data Warehouse) для аналізу. Тут є де розвернутися з BigData на даних телеметрії та корисного навантаження, сюди ж піде створення вітрин для BI-засобів та аналізу різного рівня.
По-третє, та як вишенька на торт, можна доповнити комплекс системою для прогнозування типу Forward Forecast. Дана система дозволить навчити математичну модель, що лежить в основі системи, сегментувати абонентську базу, формувати прогнози споживання та поведінки абонентів.
Спільно вимальовується досить складна інформаційна архітектура оператора-агрегатора.
Чому ми виділяємо у статті три лінії, а не об'єднуємо їх? Справа в тому, що бізнес-системі зазвичай є важливими кілька агрегованих параметрів. Решта потрібна для моніторингу, обслуговування, аналізу звітності та прогнозування. Детальна інформація потрібна для безпеки і Big Data, тому що ми часто не знаємо, які параметри і за якими критеріями заходять аналізувати в Big Data аналітики, тому DWH передаються всі дані у вихідному вигляді.
У бізнес-системах з функціями управління – білінг, PRM вже не потрібна частина параметрів, що прийшли з обладнання, телеметрія. Тому зайві поля фільтруємо, забираємо. За потреби збагачуємо дані за якимись правилами, агрегуємо та в ув'язненні нормалізуємо для передачі в бізнес системи.
Ось і виходить, що перша лінія збирає сирі дані для третьої лінії та адаптує їх до другої. Друга працює з нормалізованими даними та забезпечує оперативну діяльність підприємства. Третя дозволяє із сирих даних виділяти точки зростання.
Що ми очікуємо в майбутньому та про економіку проектів IoT
Спершу про економіку. Вище ми писали про обсяги ринку. Здається, що чималі гроші вже задіяні. Але ми бачили, як не сходиться економіка проектів, які намагалися реалізувати з нашою допомогою, або на які нас запрошували для оцінки. Наприклад, ми прораховували створення MVNO для M2M з використанням SIM-карт для збору телеметрії з певного типу обладнання. Проект не запустили, бо економічна модель виявилася нежиттєздатною.
Великі телеком-організації просуваються ринку IoT – вони мають інфраструктура, готові технології. Нових абонентів-людей у Росії з'являється досить мало. А ось ринок IoT дає чудові можливості для зростання та отримання додаткового прибутку зі своїх мереж. Поки тестується попередній національний стандарт, поки невеликі компанії-ентузіасти обирають різні варіанти реалізації UNB/LPWAN, великий бізнес вливатиме кошти в захоплення ринку.
Ми вважаємо, що згодом якийсь один стандарт/протокол передачі даних почне домінувати, як це було зі стільниковим зв'язком. Після цього ризики зменшаться, обладнання стане доступнішим. Але ринок на той час вже може бути наполовину захоплений.
Звичайні люди звикають до сервісу, їм зручно, коли автоматизовані пристрої враховують воду, газ, світло, інтернет, каналізацію, тепло, забезпечують роботу охоронної та пожежної сигналізації, тривожної кнопки, відеоспостереження. Люди дозріють до масового використання IoT у сфері ЖКГ у перспективі найближчих 2-5 років. Трохи більше піде на те, щоб довірити роботам холодильник та праску, але цей час також не за горами.
Побоювання
Про попередній національний стандарт NB-Fi голосно заявили як претенденту на міжнародне визнання. Серед плюсів названа низька вартість радіопередавачів для пристроїв та можливість їх виробництва у Росії. Ще у 2017 році у вищезгаданій статті на Хабрі анонсувалося:
Базова станція стандарту NB-FI буде коштувати в районі 100-150 тис. руб., Радіомодуль для підключення пристрою до Мережі - близько 800 руб., Вартість контролерів для збору та передачі інформації з лічильника - до 200 руб. руб.
Але це лише плани і практично важлива частина елементної бази для пристроїв виробляється там. У самому ПНСТ прописаний явно ON Semiconductor AX8052F143.
Хочеться сподіватися, що протокол NB-Fi буде справді відкритим та доступним, без спекуляцій на імпортозаміщенні та нав'язуванні. Стане конкурентним продуктом.
IoT – це модно. Але треба пам'ятати, що в першу чергу "інтернет речей" не про ітемізацію та навішування відправлення даних у хмару з усього, що можна. "Інтернет речей" про інфраструктуру та оптимізацію Machine-to-Machine. Бездротовий збір даних з лічильників електроенергії сам не IoT. А от автоматизований розподіл електроенергії по споживачах із кількох джерел — державних, приватних постачальників — для всього населеного пункту вже схожий на оригінальну концепцію інтернету речей.
На базі якого стандарту ви почали будувати свою мережу збору даних? Покладаєте якісь сподівання на NB-Fi, чи варто вкладати кошти у розвиток білінгових систем для збору даних із пристроїв цього стандарту? Можливо, брали участь у реалізації проектів IoT? Поділіться своїм досвідом у коментарях.
І удачі!
Джерело: habr.com