Nearly finished thesis

thesis/Source files/03_theory.tex

@@ -0,0 +1,237 @@
+\newpage
+
+\section{Основи на IoT и применети технологии}
+
+Ова поглавје ги опфаќа основните технички концепти врз кои се базира
+развиената платформа. Прикажани се клучните технологии, протоколи и
+архитектонски принципи што овозможуваат безбедно, сигурно и скалабилно
+функционирање на системот. Со разбирање на овие теоретски основи станува
+појасно зошто одредени технолошки решенија се избрани и како тие
+директно придонесуваат кон целокупната архитектура и функционирањето на
+самата платформата.
+
+\subsection{Интернет на Нештата}
+
+Интернет на нештата (Internet of Things или IoT) претставува технолошки
+концепт кој се однесува околу поврзување на голем број мали уреди со
+интернетот со цел размена на податоци, обработка и автоматизација на
+истите. Терминот прв пат е воведен кон крајот на 90-тите од страна на
+Кевин Ештон, професор од МИТ. А во последните години достигнува голема
+популарност со порастот на интернетот, зголемената достапност на
+електронски компоненти, нивното поевтинување како и нивното усовршување
+што овозможува полесна и поевтина имплементација на истите. Денес се
+проценува дека во 2025 година постојат околу 20 милијарди IoT уреди, а
+се проценува дека нивната бројка ќе се искачи до над 30 милијарди до
+2030та година. IoT наоѓа широка примена во индустрија, здравство,
+транспорт, земјоделие, паметни домови и многу други области.
+
+Архитектурата на IoT системите најчесто се состои од три главни слоеви:
+Perception, Network и Application слојот. Perception слојот ги опфаќа
+сите уреди со сензори и актуатори кои се поставени во некоја околина,
+Network слојот, односно мрежниот слој е слојот кој е задолжен за пренос
+на информациите од и до самите уреди преку разни мрежни технологии како
+WiFi, Bluetooth, 4G/5G, LoRaWAN како и други поедноставни радио
+протоколи, како и специјализираните протоколи за истите како MQTT, HTTP,
+AMQP. А додека пак Application слојот, односно апликацискиот претставува
+највисокото ниво, и тој слој е задолжен за обработка, собирање,
+складирање, анализа, прикажување на податоците од и за уредите.
+
+Покрај широката примена, IoT системите и индустријата имаат бројни
+предизвици. Еден од нив е безбедноста, бидејќи најчесто уредите се со
+мала процесорска моќ и батериски напојувани не можат да извршуваат
+комплексни криптографски операции. Скалабилноста претставува огромен
+проблем бидејќи во IoT системите се очекува да комуницираат истовремено
+стотици, а некогаш и илјадници. Интероперабилноста е исто клучен фактор
+за успех, најчесто таа е ограничена од разни стандарди и протоколи кои
+често знаат да се лиценцирани и приватни. Справувањето со големиот
+волумен на податоци е исто така доста сложено, што бара специјализирани
+системи за обработка и посебни бази на податоци за истите.
+
+Сите овие предизвици се релевантни и за развиената платформа во овој
+труд. Потребата за сигурна комуникација се адресира со имплементација на
+mTLS и X.509 сертификати. Скалабилноста и ефикасното управување со
+податоците се постигнуваат со користење на \texttt{Redis Streams} и \texttt{TimescaleDB},
+додека микро-сервисната архитектура обезбедува флексибилност, независно
+развивање и лесно проширување на системот. Со тоа, избраната архитектура
+директно ги решава клучните слабости во традиционалните IoT решенија.
+
+\subsection{MQTT}
+
+Со ефикасност и сигурност како цел во преносот на телеметриските податоци
+во IoT светот, изборот на комуникацискиот протокол има клучна улога. За
+разлика од де факто стандардот за веб комуникација, HTTP, протокол кој
+се базира на request/response моделот, MQTT (Message Queuing Telemetry
+Transport) користи publish/subsrcibe модел, што го прави погоден за
+системите со голем број на уреди и ограничени ресурси. MQTT е развиен
+токму за овие намени, за средини со нестабилна мрежна конекција, мал
+проток и уреди со ограничена процесорска и енергетска моќ, што го прави
+идеален кандидат за IoT системи.
+
+За разлика од HTTP, каде клиентот мора постојано да испраќа барања за да
+провери дали има нови податоци, MQTT работи на принципот
+publish/subscribe. Уредите кои се „произведуваат`` податоци(publishers)
+ги испраќаат пораките до централен сервер наречен \texttt{broker}, додека
+апликациите кои сакаат да ги „конзумираат`` тие податоци subscribers, се
+претплатуваат на одредени теми. На овој начин, \texttt{broker}-от автоматски ги
+доставува пораките до сите заинтересирани корисници без тие константно
+да испраќаат барања.
+
+Комуникацијата преку MQTT е организирана преку така наречени теми
+(topics), кои имаат хиерархиска структура и овозможува организација на
+пораките. На пример, тема од облик devices/sensor01/temperature јасно
+укажува дека пораката се однесува на температура измерена од конкретен
+уред. MQTT дополнително поддржува и т.н. wildcard знаци, со што се
+овозможува флексибилно претплатување на повеќе теми истовремено, што е
+особено корисно во системи со голем број уреди.
+
+Исто така многу важен механизам кај MQTT е Quality of Service(QoS), кој
+го дефинира нивото на сигурност при достава на пораките. Протоколот
+поддржува три нивоа на QoS, кои овозможуваат баланс помеѓу брзината на
+комуникација и сигурност во доставата. Овој механизам е особено битен
+кај системи каде е важно пораките да не се изгубат, но истовремено да не
+се оптоварува мрежата.
+
+Покрај овие можности, MQTT нуди и дополнителни механизми како retained
+пораки и last will пораки. Retained пораките се пораки кои остануваат во
+\texttt{topic}-от, и секој нов претплатник ќе ја добие таа порака, за разликата
+од другите нормални пораки кои ги добиваат само ако биле претплатени во
+истиот момент кога била испратена. Додека пак last will пораката
+претставува начин еден испраќач (publisher) кога непланирано ќе се
+дисконектира да остави некаква трага. Благодарение на овие
+карактеристики, MQTT претставува стандарден избор за комуникација во IoT
+платформите, вклучувајќи го и платформата која ја развивам во рамките на
+овој дипломски труд.
+
+\subsection{Безбедност - mTLS и X.509 сертификати}
+
+Безбедноста претставува еден од најкритичните аспекти кај IoT системите,
+бидејќи уредите најчесто се поставени на небезбедни локации и
+комуницираат преку небезбедни канали. Во изминатите години се забележани
+бројни напади врз IoT уредите, каде илјадници уреди се компромитирани
+поради слаба софтверска безбедност. Денес тие претставуваат една од
+главните мети на хакерски напади поради нивното сѐ присуство и
+ранливост. Еден таков познат напад е Mirai botnet во 2016, преку кој беа
+компромитирани стотици илјади уреди поради користење слаби лозинки или
+стандардни лозинки. Поради таквите примери класичната добро позната
+автентикација со лозинка и корисничко име се смета за не соодветно
+решение.
+
+За заштита на комуникацијата кај IoT уредите се користи TLS (Transport
+Layer Security) протоколот, кој обезбедува енкрипција на податоците,
+интегритет и автентикација на двете страни во комуникацијата. При TCP
+конекција, TLS спроведува размена на сертификати за потврда на
+идентитетот. Kај стандардниот TLS, како на пример за web комуникација,
+се врши еднострана идентификација, односно серверот се идентификува пред
+клиентот за да покаже дека тој е стварно тој, додека пак кај mutual TLS
+(mTLS) и клиентот и серверот меѓусебно се автентицираат. Ова е посебно
+важно кај IoT уредите, бидејќи секој уред мора да биде јасно
+идентификуван со што се спречува неовластен пристап до системот.
+
+Автентикацијата кај mTLS се заснова врз X.509 дигитални сертификати.
+Секој сертификат содржи податоци за сопственикот, јавен криптографски
+клуч, неговата важност, неговиот сериски број како и дигитален потпис од
+доверлив издавач, односно така наречен Certificate Authority (CA). Преку
+концептот наречен „ chain of trust`` се обезбедува сигурност дека
+сертификатот е издаден од валидна и доверлива институција,.
+
+Во рамките на системот развиен за овој дипломски труд се користи интерен
+Certificate Authority, преку кој се издаваат X.509 сертификати за секој
+уред. Процесот на генерирање и управување со сертификати е имплементиран
+во рамките на сервисот за управување со уреди (\texttt{device\_manager}), додека
+пак MQTT \texttt{broker}-от врши верификација на сертификатите при секое
+поврзување. Дополнително, се користи и Certificate Revocation List
+(CRL), со што се овозможува одземање на пристапот на компромитирани или
+неактивни уреди, што спречува користење на тие валидни цели за
+малициозни цели.
+
+Со примената на mTLS се обезбедува високо ниво на безбедност, доверлива
+идентификација на уредите и заштита на податоците при нивниот пренос.
+
+\subsection{Микросервисна архитектура}
+
+Традиционалниот пристап во развојот на софтверските системи најчесто се
+базира на монолитна архитектура, каде целата функционалност на една
+апликација е имплементирана во една целина. Овој начин е доста
+едноставен за почетна имплементација, но како што се зголемува
+комплексноста и бројот на корисници, одржувањето, скалабилноста на
+системот и развојот стануваат се потешки за менаџирање. Спротивно на тоа
+микросервисната архитектура го дели системот на повеќе мали, логички
+независни целини наречени сервиси, од кои секој извршува една точно
+јасно дефинирана функција и комуницира со останатите најчесто преку
+мрежа.
+
+Главните предности на микросервисната архитектура се флексибилноста,
+скалабилноста и можноста секој да се развива независно. Секој
+микросервис може да се развива во различна насока, со различни
+технологии и програмски јазици во зависност од потребата и намената.
+Дополнително, проблем со еден од сервисите не значи дека и целиот систем
+ќе престане со работа. Тоа дополнително ја зголемува отпорноста на
+грешки на системот. Овој пристап е доста користен и погоден за IoT
+системи, бидејќи различни компоненти имаат различни намени, барања за
+перформанси и скалабилност.
+
+Покрај своите бројни предности, микросервисната архитектура како и се
+друго има и свои недостатоци и предизвици. Комуникацијата помеѓу
+микросервисите се одвива преку мрежа, што може да доведе до дополнително
+каснење и грешки. Дистрибуираните системи се потешки за управување и
+синхронизирање во споредба со монолитната архитектура. Нивното
+дебагирање и откривање на проблеми е доста покомплексно, бидејќи треба
+следење и анализирање на повеќе сервиси кои работат одвоено.
+
+За надминување на ваквите предизвици, во микросервисините системи често
+се применува асинхрона комуникација преку message queue механизми. Во
+рамките на оваа дипломска се користи \texttt{Redis Streams} како комуникациски
+посредник помеѓу некои сервиси. Преку концептот на \texttt{consumer groups},
+повеќе worker процеси можат паралелно да читаат и обработуваат еден ист
+stream. Дополнително, обезбедува at-least-once достава, со што се
+намалува ризикот од губење на податоци.
+
+Во платформа која се развива како дел од оваа дипломска работа се
+имплементирани повеќе микросервиси со јасно дефинирани одговорности.
+Сервисот \texttt{device\_manager} е задолжен за регистрација на уредите и
+управување со X.509 сертификати. \texttt{mqtt\_ingestion} сервисот го прима
+телеметрискиот сообраќај и го запишува во \texttt{Redis Streams}. \texttt{db\_write}
+сервисот ја презема улогата на обработка и запишување на податоците во
+базата на податоци. \texttt{gpt\_service} е задолжен за паметна анализа на
+собраните податоци со помош на вештачка интелигенција , додека Django ни
+служи како позадина за веб-контролната табла и оркестрира и комуницира
+со другите сервиси и базата на податоци во која се запишуваат
+телеметриските податоци. Со ваквата организација, секој сервис има јасна
+улога, што го прави системот модуларен, проширлив и лесен за одржување.
+
+\subsection{Временски бази на податоци}
+
+IoT системите генерираат голем број на податоци во кратки временски
+интервали, што резултира со голем број на INSERT операции во базата на
+податоци. Ваквиот тип на податоци најчесто се анализираат според
+временски опсези, како последен час, последен ден или месец, а не според
+нивните класични релациски односи. А исто така често се извршуваат
+агрегациски функции, максимално и минимални вредности во временски
+период. Поради ваквите карактеристики, најчесто користените релациски
+бази на податоци не се оптимални за ваков тип на податоци без надградби
+за оптимизација.
+
+Како решение за управување со податоци од временски серии, во рамките на
+дипломскиот труд се користи \texttt{TimescaleDB}, кој претставува екстензија за
+\texttt{PostgreSQL} широко користената релациона база на податоци. Ова овозможува
+користење на секојдневна релациона база заедно со временски серии на
+податоци. Клучниот концепт кај оваа база се така наречените \texttt{hypertables},
+кои овозможуваат автоматско партиционирање на податоците кои се
+временски серии, според временската димензија и дополнителни клучеви, со
+што се постигнува висока ефикасност за запишување и читање.
+Дополнително, \texttt{TimescaleDB} поддржува компресија на стари податоци, што
+помага за намалување на просторот кој го зафаќа базата на податоци, како
+и континуирани агрегации (continous aggregations), кои овозможуваат
+автоматско пресметување на агрегатни вредности по претходно зададени
+временски интервали.
+
+Во платформата развиена за овој дипломски труд, телеметриските податоци
+се складирани во посебна \texttt{telemetry} табела, чија структура е прилагодена
+на временската природа на податоците, односно е \texttt{hypertable}. Примарниот
+клуч е составен од времето на мерење, идентификаторот на уредот и типот
+на метриката, односно (time, device\_id, metric). Ваквиот редослед на
+клучевите овозможува ефикасни пребарување најчесто користени во
+системот, како на пример прикажување на податоци за конкретен уред во
+одреден временски период.
+
+Со прикажаните концепти за IoT, комуникациски протоколи, безбедност, микросервисна архитектура и временски бази на податоци се поставува теоретската основа за дизајнот на конкретниот систем. Во следното поглавје детално е опишана архитектурата на развиената платформа и меѓусебната интеракција на нејзините компоненти.