Nadchodzi nowe wsparcie w IoT: NarrowBand dla internetu rzeczy - Nb-IoT + T-Mobile w hub::raum/Kraków

Wiele startupów tworzy IoT i niewiele wie o możliwościach jakie niesie przyszłość w temacie komunikacji urządzeń internetu rzeczy. Tzn. używają WiFi + Bluetooth, bo RaspberryPi i inne tanie płytki mające wsparcie społeczności ułatwiają dostęp do wiedzi i darmowego softu. To jest super z punktu widzenia przygotowania prototypu i uruchomienia PoC. Jednak takie rozwiązania nie spełniają często standardów automatyki: bezawaryjna praca ciągła, gwarancja działania do 5 lat, modułowa modernizacja/upgrade software/hardware, brak zakłóceń sfery dookólnej i niewielkie zużycie mocy.
Po prostu patrząc na IoT robione "na kolanie" widzę dużo ludzi, którzy po obejrzeniu YT tworzą swoje środowiska, natomiast robią to bez szerszej wiedzy z dziedziny elektroniki/sieci/informatyki. Takie prototypy najczęściej idą do szuflady i docelowy system wbudowany jest zamawiany w firmie znającej się na rzeczy a czasami też startupowcy uczą się elektroniki od podstaw i budują wiele prototypów dochodząc do wyznaczonego celu. Ale mimo wszystko sobie jakoś radzą na rynku systemów wbudowanych, bo jest to dość bogaty w "prawie gotowe" rozwiązania rynek.

Jeśli chodzi o startupy IoT oraz wsparcie urządzeń internetu rzeczy jest dla nich radosna nowina.
Otóż jak firma T-Mobile na swojej stronie IoT zadeklarowała, już niedługo obok internetu i transmisji danych 2G/3G/4G ujrzymy w ofercie nowa generację połączeń 5G o nazwie NarrowBand. Energooszczędne i dedykowane pasma dla transmisji danych z urządzeń M2M.

Prezentacja pochodzi ze stron T-Mobile - link do prezentacji na temat Internet rzeczy + Nb-IoT

Tak się składa, że lubię meetupy i trafił mi się jeden w tym temacie w Krakowie - na temat tej nieznanej wcześniej technologii NarrowBand (Bazyli, dzięki za zaproszenie). Jak to zwykle bywa spakowałem plecak, kupiłem bilety, aby spędzić 98% czasu w podróży i 4h na inspirującym spotkaniu z inżynierami skupionymi wokół hardware i transmisji danych. Jak się zorientowałem miejsce nazwane hub::raum to work place w Krakowie, gdzie swoje projekty rywalizują startupy zaproszone przez firmę T-MOBILE do pierwszej fazy testów wdrożeniowych dla technologii NarrowBand. Bardzo przyjazne miejsce i z unoszącymi się w powietrzu startupowymi tematami :)


Kiedy przybyłem na spotkanie zaskoczyła mnie spora ilość rożnych płytek prototypowych wspierających NarrowBand ( NB-IoT ). Zawierające różne marki modemów oraz podstawek dev. kits zwróciły moją uwagę - oto jak wyglądały:

Okazało się, że powyższe developerskie kity to nasze przedmioty ćwiczeń. Wow, od razu radość na inżynierskiej duszy, że praktyka a nie tylko teoria rządzi na tym spotkaniu.

Z rzeczy ważnych dowiedziałem się, że w Krakowie w okolicy warsztatów jest działająca aktywna stacja GSM/UMTS dla testów NarrowBand. Wdrożenia dla powszechnego użycia we własnych produktach jakie się zapowiadają na 2018 rok dotyczą wstępnie Krakowa i Warszawy.
Coś co Was ucieszy to fakt, że NarrowBand jest przeznaczony i zaprojektowany od początku dla IoT, zakłada małe pakiety danych nie więcej niż kilka mega bajtów na miesiąc. Jego szacowana cena rocznego abonamentu to ok. 20 USD :) i tutaj fąfary ; )
Nie ma na tą chwilę modemów wspierających protokół TCP natomiast są modemy wspierające UDP. Istotny fakt to niemożliwość podłączenia się z zewnątrz do urządzenia. Tzn. możemy tylko traktować modem jako klienta sieci i jeśli postawimy na nim aplikację to z założenia powinien to być klient do usługi a nie aktywny serwer.

Techniczna wartość jaka płynie z takiego rozwiązania to również oszczędność energii tzn. nasz produkt IoT może wysyłać rzadziej dane i przez to działać na akumulatorze dłużej. Producenci modemów NarrowBand wprowadzili specjalne tryby oszczędzania energii oraz wybudzania, aby nasze urządzenia działały dłużej.

A teraz nieco fotek i komentarzy do nich. Oto początek prezentacji ze spotkania.

Oto typowy deweloper kit jakiego używałem na warsztatach i zestaw komend AT stosowanych do niego.

Zasadniczo to działa po podłączeniu do USB. Pojawia się w systemie wirtualny port ttyUSBx (ew. kolejny COMx) i wystarczy otworzyć port i zrobić restart modemu. Przedstawia nam się od razu i możemy działać z ustawieniem trybu i zasad działania.

Oto zrzut ekranu z praktycznego terminala cutecom na Ubuntu i wspierającego wydawanie komend AT.

Wśród uczestników spotkałem fascynatow nowych technologii i hardware. Nie jest to spore grono fanatyków, ale dość konkretne jak to w inżynierskiem środowisku bywa. Jako gift otrzymałem od jednego gościa PCB zrobione w Chinach na którym można osadzić modem i kartę SIM w postaci układu scalonego. Dowiedziałem się, że w naszym kraju można kupić takie SIMy w T-Mobile, które wlutowuje się w PCB i przez to wielkość urządzenia znacząco maleje.
Oto jak prezentuje się taka płytka z dwóch stron. Może ktoś skorzysta i pobawić się tematem jak ja.

Moje zabawki, z którymi będę niebawem się bawił w podłączenie modemu GSM do sieci wyglądają tak:

Zamierzam kupić kilka kart rożnych operatorów i pobawić się w transmisję danych a jeśli będę miał NarrowBand w zasięgu to również wchodzi w grę :) ale szukam sponsora/dostawcy na modem SARA N21  na ten moment najwięcej urządzeń NB-IoT widziałem w u-Blox, ale z czasem się to napewno zmieni.


Gdybyście chcieli obejrzeć co n.t. NarrowBand planuje T-Mobile Polska - polecam ten cenny materiał o NarroBand IoT w odniesieniu do Polski:






Napiszcie o Waszych przygodach z IoT, GSM, modemami i ew. NarrowBand w komentarzach.

Linki

Narrowband-IoT: wsparcie Internetu rzeczy

T-Mobile Takes on IoT with New Network Tech & a Growing Product Family

Webinarium : INTERNET RZECZY – BUDOWANIE ROZWIĄZAŃ Z TECHNOLOGIĄ KOMUNIKACYJNĄ NARROWBAND-IO

T-Mobile reveals plans for nationwide Narrowband-IoT network by 2018, also intros SyncUp Fleet

Fenomen DEVOPS na ratunek dla skostniałych i niezbyt wydajnych zespołów w IT (programista i administrator w jednym)

Widowiskowe prezentacje na konferencjach to nie tylko takie, które powalają technologią i frapują, że tego tricku architektonicznego jeszcze nie mamy w naszym systemie :-) Są to również sprawy "miękkiej natury ludzkiej", które w branży IT stanowią często niezbędny pomost pomiędzy tymi, którzy potrafią ale im się nie chce a tymi, którzy mogliby więcej bo mogą dać z siebie więcej dla wyższych idei :-)

Jak wiadomo z ciekawej sztuki V jak Vendetta "idea jest niezniszczalna" i w tym wpisie chętnie poruszę temat spraw nie technicznych, które wspierają ludzi technicznych. Idei, które trwają w świecie DevOps :-)

Jak się zaczęło to całe DevOps i gdzie po drodze spotkali się ludzie z IT?

Na początku był Dev a potem pojawił się Ops albo odwrotnie, zależnie od źródeł ... ;-)
Zmierzam do tego, że na początku ery komputerów i informatyki istnieli deweloperzy, którzy stworzyli maszyny, po czym dalej byli zajęci kodowaniem i mieli misje rozwoju oprogramowania. Zabrakło im czasu na utrzymywanie i zarządzanie technicznymi aspektami ich dzieła i pojawił się zawód administratora w informatyce.
Celowo bardzo ten wstęp uprościłem, gdyż te dwie role i do tej pory rozdzielne zawody: programista / developer oraz sysops / ops / administrator za sprawą tzw. chęci stały się jednością:)

"Banalne" założenie – łączymy wysiłki zespołów rozwoju i utrzymania (Development i Operations).

Tak na serio poruszam temat dość niesamowity w branży IT, kiedy dwie popadające w skrajności - tak, nie przesadzam - grupy informatyków o podobnych zainteresowaniach zawodowych ścierały się ze sobą i utrudniały sobie prace a tu nagle ....
Z pomocą przyszedł tzw. Agile wraz z manifestami zwinności w codziennym postępowaniu. Niczym kodeks, który stanowi bazę dla wszelkich czynności zawodowych zjawia się: Agile Manifesto , który wspomógł ideologicznie cały świat IT. 
Istotnie są tacy, którzy się temu nie poddali - jak zwykle "mądrzejsi" - ale nie o nich jest ten wpis. Skupiam się na ludziach, którzy lubią na co dzień ryzykować i eksperymentować, którzy porzucili wygodną strefę komfortu na rzecz zwinności w pracy.

Oto zasady, którymi posługuje się na stale od wielu lat:

Wytwarzając oprogramowanie i pomagając innym w tym zakresie, odkrywa się lepsze sposoby wykonywania tej pracy. W wyniku tych doświadczeń przedkłada się:

• Ludzie i interakcje ponad procesy i narzędzia

• Działające oprogramowanie ponad obszerną dokumentację

• Współpracę z klientem ponad formalne ustalenia

• Reagowanie na zmiany ponad podążanie za planem

Według Manifestu Agile docenia się to, co wymieniono po prawej stronie, jednak bardziej ceni się to, co po lewej (src)

Otóż, naturalnie zainteresowanie programowaniem ze strony administratorów systemów operacyjnych oraz zainteresowanie budową systemu Linux ze strony programistów, czy inżynierów oprogramowania spowodowało falę pozytywnych kreacji. Nie teoretyzuję tutaj, bo widzę na co dzień zadowolonych adminów, software developerów, którzy nazywają siebie DevOpsami.

Nazwałem zjawisko w tytule jako Fenomen DevOps dlatego, że nie znam branży, w której dwa kierunki rozwoju zawodowego spotykają się tak ochoczo i brną we współpracę.
Są widoczne naturalnie pozytywne skutki tego połączenia w wielu organizacjach. Wiele firm z TOP 500 już wdrożyła Agile, SCRUM, czy Lean ew. Kanban i po latach nauki mogą cieszyć się zwinnością w produkcji zmian w swoich produktach.

Co zyskujemy wdrażając w organizacji kulturę DevOps ?

Argumenty poniższe są zapożyczone z praktyki:

• zadowolenie wśród pracowników i brak barier branżowych (dyskusje na różne tematy)
• otwartość i transparentność w działaniach (każdy z każdym współpracuje jak najlepiej potrafi)
• utrzymanie i rozwój produktów przez wiele zwinnych osób (bo im się chce, a nie muszą)
• zespoły produkujące są też utrzymującymi swoje produkty (bo wiedzą o nich wszystko)
• zespoły monitorują swoje wdrożenia i produkty metrykami biznesowymi i technicznymi (wiedzą przed awarią, że zasoby niebawem się skończą i zareagują na automatyczny alarm)
• automatyzują pracę, która jest powtarzalna i monotonna (bo są wygodni i maszyna zrobi to zawsze tak samo, w tym czasie mogą pójść na herbatkę)
• dzielą się ze światem Open Source, bo biorą z niego też niektóre składowe swoich produktów
• pozwalają na krytykę innym ze swojej pracy i dyskutują o tym, wyciągają wnioski (wartościowa cecha ludzka)
• panują nad kodem i wiedzą co zrobić, aby koszt utrzymania nie rósł stale (bo są inżynierami)
• motywują się wzajemnie przez dzielenie pasjami zawodowymi (taki to wesoły świat IT)
• razem z biznesem patrzą sobie na ręce, bo mają metryki i mogą (biznes też się uczy wiele z właściwych metryk n.t. zdarzeń w produkcie)
• robią Hackatony, aby udowodnić sobie i innym, że zabawki zrobione w 24h potrafią zaskakiwać oraz poznają kolegów z innych odległych oddziałów (same atuty)
• drobne zmiany, które można szybko zobaczyć na produkcji są cenniejsze niż 5 m-cy straty
• eksperymentowanie to domena ludzi odważnych (czyli DevOpsów)

Liczby w różnych źródłach mówią o tym fenomenie dość konkretnie.

Z jakimi rozwiązaniami wiąże się DevOps ?

Celowo pozostawiłem nazwy w języku angielskich, bo ozn. bardzo konkretne działania

1. Continuous build - czyli zmiana to uruchomienie procesów budowania świata/środowiska od zera w konkretnym scenriuszu
2. Continuous testing - czyli każda zmiana to uruchomienie testów automatycznych i zbudowanie paczki do wdrożenia lub alert
3. Continuous inspection - przeglądy kodu (Code Review), audyty, zapis historii zmian, autora zmian
4. Continuous integration - jeśli zbudujemy swój projekt, to jeszcze zintegrujmy go z resztą usług - jak zadziałają nie tylko nasze testy ale też innych, to jest bardzo dobrze
5. Continuous delivery - małe przyrosty zmian dające minimalną wartość produktu to cenny każdy dzień w pracy
6. Continuous configuration enforcement - wiem, gdzie przestawić przełączniki mojej aplikacji i wszelkie paramerty. Nie potrzebuję wdrożenia, aby zmienić właściwości i warunki pracy usług. Zawsze inni widzą, co zmieniałem ostatnio i mogą w trakcie awarii odpowiedni szybko zareagować.
7. Continuous deployment - najlepiej kiedy każda zmiana w kodzie, na dowolnym branchu uruchamia procedury testów automatycznych / integracyjnych. Lubimy spać spokojnie.
8. Continuous monitoring - na każdym etapie wytwarzania, testowania, wdrożenia, działania staraj się widzieć metryki a najlepiej podepnij do nich automatyczny system alarmujący w SMS lub dzwoniący. Tak przy każdej zmianie testuj też system alertujący, uratuje to Twój swiat.  
9. Continuous recovery - jeśli nie udało się wdrożenie, rollback to nie problem - wycofujemy i próbujemy dalej
10. Continuous scaling - cóż, w święta większy ruch, to nie problem jeden parametr lub automatyczne skalowanie instancji lub maszyn spowoduje, że wydajność usług nie spadnie

Antywzorzec jaki zauważyłem w rozumieniu DevOps to jest robienie oddzielnych integracji zespołów DEV i odzielne OPS, to czyni świat IT gorszym a ludzi klasyfikuje niepotrzebnie na dewów i adminów. Ludzie nie lubią być sortowani, ale bardzo cenią sobie możliwość poznania zdania innych stron.
Inny problem to zamknięte w sobie i niewspółpracujące typki o dziwnych charakterach - cóż, warto być wyrozumiałym i dać im czas oraz szansę rozwoju. Po jakimś czasie będą bardzo wdzięczni za otworzenie oczu i wytarcie mgły sprzed ich oczu ;-) kiedy zobaczą swój kod na produkcji pod wysokim obciążeniem i kiedy miliony polaków przed swoimi monitorami klika ten "mój guzik" :-)

Jeśli nadal zastanawiasz się, czym jest DevOps i nie wiesz, jak wdrożyć u siebie zapraszam do dyskusji. Chętnie odpowiem o tym, jak ja to rozumiem i poznam też inne punkty widzenia.

[ Naprawianie na Kolanie ] Praktyczne naprawianie elektroniki, robotów, błędów w oprogramowaniu, systemów operacyjnych

Odważyłem się i postanowiłem naprawiać różne praktyczne rzeczy materialne i mniej materialne na oczach telewidzów YOUTUBE

NAPRAWIANIE NA KOLANIE - tak nazwałem serię odcinków typu FIX IT ! w moim wydaniu, gdzie prezentuję jak w warunkach amatorskich (domowych) można naprawić, dokonać przeglądu, zmienić i udoskonalić urządzenia codziennego użytku.

Pierwszy odcinek dedykuję użytkownikom iRobot Roomba 650  a szczególnie mojemy mentorowi w tematyce Agile/SCRUM/Kanban/XP. Pomyślałem, że zawsze kilka stówek w kieszeni :-) to nie problem, więc jak to polak z natury ciekawski naprawiam sobie z wizją i fonią zapisaną na youtube.

Problem jaki poruszam ww pierwszym odcinku to to stukanie podczas pracy i związane z tym zanieczyszczenie części mechanicznej (trybów) głównego modułu czyszczącego w iRobot Roomba.
Wiele osób kojarzy firmę iRobot , która wprowadziła wspaniały wynalazek na rynek jakim jest automatyczny "pseudo odkurzacz". Każdy chciałby go mieć, ale nie wszyscy sobie zdają sprawę, że trzeba go stosownie konserwować. Oczywiście, mam tutaj na myśli regularne czyszczenie, bo jak to w mechatronicznych urządzeniach bywa kurz i brud nie wspomagają automatu.

Miłego oglądania i oczywiście naprawiania robotów :-)