Lumea dezvoltării de software are multe ingrediente, iar dezvoltatorii de software preferă arome diferite. O abordare mai ludică ce menține această analogie cu domeniul culinar oferă ocazia relevării unor aspecte specifice pentru lumea Internetului lucrurilor (IoT). Așadar, unul dintre ingredientele cele mai importante este cel al DETECTĂRII (SENSING). Prin adăugarea unei arome MOBILE oricărui produs IoT, soluţia devine una foarte plăcută. Chiar dacă simţul şi mobilitatea ar fi foarte plăcute pentru utilizatorii generali, este greu să găseşti dezvoltatori cărora să le placă ambele arome. Pe de o parte avem volţi, amperi, senzori, dispozitive de acţionare, iar pe de altă parte avem imagini, icon-uri, cicluri de viaţă, uEx. Dar se poate depăși acest impas prin apelul la Sensoriada.Aceasta defineşte un context care încearcă să surmonteze discrepanţa dintre aceste ingrediente, cu unicul scop de a crea aplicaţii mai bune şi în acelaşi timp de a permite dezvoltatorilor să lucreze cu ingredientul lor preferat.
"Internetul lucrurilor" (IoT) nu este ceva nou, ci este mai degrabă un concept nou pentru ceea ce obişnuia să fie, cel puţin în ultimul deceniu, casa inteligentă, automatizarea casei, monitorizare inteligentă şi multe altele. În toţi aceşti ani, o caracteristică importantă a rămas cea care definește toate aplicațiile IoT: acestea sunt foarte prezente în vieţile noastre (noi avem o interacţiune directă foarte puternică cu ele şi ele ne afectează viaţa în mod direct).
În această cercetare, am pornit de la o problemă simplă, definită după cum urmează. Afişează pe un dispozitiv mobil temperatura din interiorul şi din afara casei, într-o manieră live. Nu ne era permis să facem găuri şi nu exista un loc anume unde trebuia monitorizată temperatura interioară. Din cauza acestor restricţii, singura soluţie era să găsim o soluţie wireless. După părerea noastră, există cel puţin trei moduri (legate de frecvenţă) de a obţine date de la un senzor: live (în direct), real time (în timp real) și hard real time.
În paragrafele anterioare am folosit câţiva termeni care vor fi detaliaţi în continuare.
Dintre aceștia selectăm pentru început, senzori şi dispozitive de acţionare. Senzorii sunt aportul de informaţie al unui proiect IoT; ei furnizează datele care sunt stocate, procesate şi analizate de către sistem. Dispozitivele de acţionare sunt uneltele de reacţie. După ce toate datele sunt analizate şi decizia este luată, se lansează de obicei o acţiune pentru un declanşator . De exemplu, un dispozitiv de acţionare poate fi un întrerupător electric care va aprinde o lumină sau va porni un corp de încălzire. De obicei, şi senzorii şi dispozitivele de acţionare sunt conectate lacontroler-e (microcontroler-e, cipuri, CPU). Un sfat de bună practică pe care l-am primit şi pe care doresc să vi-l împărtăşesc este următorul: într-un proiect, senzorii şi dispozitivele de acţionare nu ar trebui conectate la acelaşi controler, pentru că este mai sigur să avem un controler pentru input (detectare) şi unul pentru rezultat (acţiune).
Apoi, prezentarea s-a concentrat pe ciclul de viaţă al unui produs IoT. Există mai multe abordări, dar articolul de faţă va prezenta numai una dintre ele, pe care noi o considerăm ca fiind cea mai relevantă pentru acest proiect. În imaginea de mai jos sunt prezentate patru etape ale acestui ciclu:
În sistemul nostru vom avea un dispozitiv mobil implicat, deci ar trebui să afirmăm că, în general, rolul unui dispozitiv mobil într-un produs IoT se exercită pe parcursul etapelor de Stocare şi Analizare, deoarece dispozitivul este utilizat în principal pentru a vizualiza datele şi pentru a selecta anumite acţiuni care vor fi transmise dispozitivelor de acţionare spre a fi executate în etapa de Reacţie.
Noi am structurat soluţia aleasă ca o reţea de senzori. Poate că este timpul să detaliem ce este o reţea de senzori. Componentele sale principale sunt:
Din punctul de vedere al aplicaţiei mobile, avem trei elemente principale de design:
Cloud cache furnizează datele drept un JSON. Există mai multe protocoale şi modalităţi de a obţine date dintr-o reţea de senzori, cea mai populară fiind MQTT; totuşi, noi am ales HTTP având sarcina utilă (payload) JSON în primul rând pentru că este suficient pentru sistemul nostru, iar electric imp cloud oferă o modalitate foarte uşoară de a face un conector server HTTP. Am ales JSON drept format sarcina utilă, în primul rând datorită popularităţii sale, popularitate care face ca procesarea sa să fie facilă şi la îndemână.
Structura JSON este bazată pe modelul de aplicaţie descris mai sus. Există o gamă de noduri de senzori care au drept elemente: identificarea ("id" care este în prezent un întreg, dar există o întreagă dezbatere pentru a o face un şir), starea energiei ("voltaj"), acuratețe ("secondsAgo"- acum n secunde de la "dată") şi lista de senzori. Un senzor va avea drept elemente tipul, versiunea şi valorile; ca valoare, senzorul ar putea avea de asemenea alte elemente şi nu există vreo restricţie pentru o singură valoare. Tipul şi versiunea identifică într-o manieră unică tipul senzorului şi influenţează direct modul în care valorile furnizate sunt procesate.
Mai jos este un exemplu de câteva date furnizate de sistemul live/ care rulează:
{
"sensorNodes":[
{
"id":0,
"voltage":2848,
"secondsAgo":247192,
"date":"2015-01-24 07:10:21",
"sensors":[
{
"type":10,
"version":1,
"value":787
}
]
},
{
"id":1,
"voltage":2892,
"secondsAgo":32,
"date":"2015-01-24 07:10:21",
"sensors":[
{
"type":10,
"version":1,
"value":2243
}
]
}
]
}Din punctul de vedere al Android, modelul Nodului de Senzori este foarte simplu şi include elementele definite mai sus.
public class SensorNode {
public long id;
public int voltage;
public long secondsAgo;
public Date date;
public List sensors = new
LinkedList();
} Modelul Senzor este o interfaţă deoarece avem o mare diversitate în funcţie de tipul şi versiunea senzorului. Pentru că această versiune este un sistem read-only, noi doar oferim metode pentru a obţine date într-un mod view şi acesta este motivul principal pentru care avem numai metoda getHumanReadableValue() pentru a obține date. În ceea ce priveşte varianta senzorului, există mai multe valori fixe pentru tip (definit în Sensor.Type enum); Referitor la versiune, clasele implementate ar trebui să aleagă versiunea maximă şi să susţină toate versiunile mai jos de cea aleasă:
public interface Sensor {
public enum Type {
TEMPERATURE(10),
HUMIDITY(11),
PRESSURE(12);
…
}
String getHumanReadableValue();
Type[] getSupportedTypes();
boolean isTypeSupported(Type type);
int getMaximumSupportedVersion();
}Lumea automotive ne-a învățat că în această industrie lucrurile ar trebui să fie foarte simple. Altfel, testarea este foarte dificilă, iar dacă sistemele IoT nu sunt testate corespunzător, erorile pot avea consecinţe regretabile deoarece, după cum am arătat la începutul acestui articol, sistemele IoT sunt foarte prezente în vieţile noastre şi interacţionează direct. Acestea fiind precizate, noi am dorit ca utilizatorii acestui cadru (framework) să îl poată utiliza într-un mod foarte facil.
Mai jos vă oferim un exemplu de cod de utilizare într-o aplicaţie Android clasică :
String nodesJson = getSomeHowTheJson();
// DataProvider in the next version
List sensorNodes = SensorNodeUtil.
parseSensorNodes(nodesJson);
int mySensorNodeIndex = someValue;
// String identification in the next version
int mySensorIndex = someValue;
// byType identification in the next version
someView.setText(sensorNodes.get(mySensorNodeIndex).sensors.get(mySensorIndex).getHumanReadableValue()); Magia are loc în clasa SensorNodeUtil care este responsabilă cu procesarea aportului JSON şi cu returnarea unei liste de SensorNode-s, fiecare dintre ele conţinând implementările adecvate ale Sensor-s în funcție de tip şi versiune. Pentru a reuşi, am implementat un mod de configurare a sistemului. Configurarea va gestiona în principal o hartă/rețea între tipul senzor şi numele clasei care se va ocupa de datele pentru acel tip. Aceasta permite cadrului să fie extins de către oricine şi de asemenea să aibă o configuraredefault de-a gata.
La începutul acestui articol am afirmat că scopul nostru a fost să favorizăm o conexiune mai puternică între ingineri care lucrează în industria IoT , indiferent de ingredientele pe care le preferă. Dacă am realizat sau nu acest lucru prin prima versiune a cadrului (_framework-_ului), vom vedea în timp, dar considerăm că am făcut câţiva paşi înainte. Odată cu evoluția comunității IoT, sperăm că Sensoriada va ajuta la construirea unei sinergii între dezvoltatori, care nu va mai lăsa loc pentru conflict, ci numai pentru armonie şi discuţii constructive.
Este prima comunitate mobile din Cluj. Ne-am început activitatea în 2012 şi deoarece dorim să creştem şi să devenim mai relevanţi şi mai atrăgători pentru a deservi mai bine comunitateamobile din Transilvania, a doua ediție a MobOS va fi o versiune îmbunătăţită!
A doua ediţie va consta într-o conferinţă de două zile; prima zi dedicată prezentărilor cu tema tehnologiei mobile şi discuţiilor deschise, în timp ce a doua zi va găzdui 4 workshop-uri legate de Android și iOS, atât pentru dezvoltatorii începători cât şi pentru cei avansaţi. Elementele cheie ale conferinţei:
În 15 Ianuarie 2015, am avut un pre-eveniment de lansare a conferinței, găzduit de Fortech. Pe parcursul acestui eveniment, 2 dintre vorbitorii noştri locali au susţinut o prezentare despre IoT (Internetul lucrurilor) și datorită interesului crescut de care s-a bucurat acest subiect, Andrei Crăciun, inginer software senior la Intel Corporation, a avut iniţiativa de a scrie un articol pentru TSM.
de Peter Lawrey
de Răzvan Costa
