Nearly finished thesis

thesis/Source files/04_design.tex

@@ -0,0 +1,282 @@
+\newpage
+
+\section{Дизајн на системот}
+
+\subsection{Архитектура на платформата}
+
+Развиената платформа е изградена врз микросервисна архитектура, со цел
+да обезбеди висока скалабилност, добра флексибилност и отпорност на
+грешки и проблеми. Наместо целата логика да е сместена во една монолитна
+апликација, функционалноста е поделена во повеќе независни микросервиси
+кои меѓусебно комуницираат преку мрежа. Ваквиот пристап овозможува
+изолирање на одговорностите по сервиси, подобра контрола на ресурсите и
+поедноставно одржување, додавање нови функционалности и скалирање.
+
+Архитектурата на платформата е составена од повеќе специјализирани
+микросервиси, од кои секој има јасно дефинира улога во целокупниот
+процес. Сервисот \texttt{device\_manager}, имплементиран со \texttt{FastAPI}, е задолжен
+за регистрација на уредите и управување со нивните X.509 сертификати.
+Сервисот \texttt{mqtt\_ingestion} е одговорен за прием на MQTT пораките од
+уредите и нивно проследување кон \texttt{Redis Streams}. \texttt{db\_write} сервисот ја
+презема обработката на податоците од message queue и нивно запишување во
+базата на податоци. \texttt{gpt\_service} овозможува интелигентна анализа на
+собраните податоци со примена на вештачка интелигенција. Django служи
+како комуникациски слој помеѓу сите микросервиси и frontend апликацијата
+изградена со React која ни овозможува визуелизација на податоците,
+интеракција со истите, и целосна табла за контрола со уредите.
+
+При дизајнот на платформата беа во главно применети принципите на loose
+coupling и single responsibility, со цел да се обезбеди јасна поделба на
+одговорностите и минимална зависност меѓу сервисите. Секој микросервис
+извршува една конкретна функционалност и комуницира со останатите
+исклучиво преку дефинирани API-интерфејси или message queue механизми.
+На овој начин се овозможува поедноставно тестирање, полесна интеграција
+на нови функционалности и локализирано решавање на дефекти без да се
+наруши стабилноста на целиот систем. Дополнително ваквиот пристап
+овозможува независно хоризонтално скалирање на поединечни сервиси, во
+зависност од реалното оптоварување, што е особено значајно за IoT
+платформи со променлив број на активни уреди.
+
+За размена на податоци помеѓу микросервисите задолжени за прием и
+обработка на телеметриските информации е имплементиран асинхрон
+комуникациски модел базиран на \texttt{Redis Streams}. Сервисот \texttt{mqtt\_ingestion}
+функционира како producer и ги запишува сите пристигнати MQTT пораки во
+централен stream, додека сервисот \texttt{db\_write} функционира како consumer и
+ги чита пораките преку механизмот на \texttt{consumer groups}.
+
+Ваквиот пристап овозможува откачување(decoupling) на сервисите на прием
+и обработка, автоматско балансирање на товарот при повеќе активни worker
+инстанции, како и задржување на пораките во случајот на привремен преки
+или преоптоварување на downstream сервисите. Дополнително, \texttt{Redis Streams}
+обезбедува at-least-once семантика, со што се намалува ризикот на губење
+на телеметриските податоци. Целокупната комуникациска архитектура и движењето на податоците е прикажано на архитектурниот дијаграм (слика~\ref{fig:system-architecture}).
+
+\begin{figure}[htbp]
+    \centering
+    \includegraphics[width=\textwidth]{Miscellaneous/architecture.png}
+    \caption{Архитектура на платформата за мониторинг на работна околина}
+    \label{fig:system-architecture}
+\end{figure}
+
+\subsection{Проток на податоци}
+
+Протокот на податоци во рамките на развиената платформа е дизајниран
+така што овозможува сигурно, скалабилно и ефикасно движење на
+информациите од крајните IoT уреди до веб интерфејсот. Процесот опфаќа
+повеќе фази: регистрација на уред, безбедно поврзување преку mTLS,
+испраќање и обработка на телеметриски податоци, нивно складирање во база
+на податоци и конечно визуелизација преку frontend апликацијата.
+Целокупниот тек е прикажан со дијаграм. (сл 3.2)
+
+\subsubsection{Регистрација на уред}
+
+Процесот започнува со регистрација на нов IoT уред во системот.
+Корисникот иницира регистрација преку веб контролната табла имплементира
+со React. При оваа постапка, frontend-от испраќа HTTP POST барање до
+Django REST API кое содржи основни информации за уредот, како што се
+име, локација и тип на уред.
+
+Django го проследува ова барање кон интерниот \texttt{device\_manager}
+микросервис, кој е задолжен за управување со уредите и нивните дигитални
+сертификати. Device\_manager креира нов запис во табелата devices во
+базата на податоци и иницира процес на генерирање на X.509 сертификат за
+конкретниот уред. По успешното генерирање и потпишување на сертификатот
+од страна на интерниот Certificate Authority (CA), приватниот клуч и
+сертификатот му се враќаат на корисникот. Овие податоци понатаму се
+имплементираат на самиот уред, со што тој станува подготвен за безбедно
+поврзување на системот.
+
+\subsubsection{Поврзување на уред преку mTLS}
+
+По успешната регистрација, уредот иницира TCP конекција кон MQTT
+\texttt{broker}-от преку порт-от 8883 кој е наменет за MQTT со SSL. При
+воспоставување на конекцијата се извршува mTLS handshake постапка, при
+што уредот го презентира својот X.509 сертификат пред \texttt{broker}-от, а
+\texttt{broker}-от го презентира својот сертификат пред уредот.
+
+\texttt{Mosquitto broker}-от врши верификација на сертификатот преку:
+
+\begin{itemize}
+\item
+  Проверка на потписот од интерниот CA
+\item
+  Проверка на валидноста (датум на важност)
+\item
+  Проверка во Certificate Revocation List (CRL)
+\end{itemize}
+
+Доколку сите проверки се успешни, конекцијата се прифаќа и уредот добива
+дозвола за publish. Во спротивно, доколку сертификатот е невалиден,
+конекцијата автоматски се одбива.
+
+\subsubsection{Испраќање и процесирање на телеметрија}
+
+Откако уредот е успешно поврзан со MQTT \texttt{broker}-от, тој започнува со
+публикување на телеметриски податоци на MQTT теми во облик
+„devices/\{device\_id\}/\{metric\}`` каде што device\_id претставува
+уникатен идентификатор на уредот, а metric го означува тимот на
+измерениот параметар (на пр. Температура, влажност, CO2).
+
+Сервисот \texttt{mqtt\_ingestion} е претплатен на сите релевантни теми и
+функционира како централен приемник на сите MQTT пораки. По приемот на
+секоја порака, податоците се парсираат и се запишуваат како нов запис во
+Redis Stream-от \texttt{mqtt:ingestion}.
+
+Сервисот \texttt{db\_write} функционира како consumer во рамките на \texttt{Redis}
+\texttt{consumer group} и ги чита пораките од stream-от асинхроно. Податоците се
+групираат и се запишуваат во \texttt{TimescaleDB} базата како нови записи во
+\texttt{telemetry} \texttt{hypertable}. На овој начин се обезбедува висок проток на
+податоци, buffering при оптоварување и at-least-once гаранција за
+достава.
+
+\subsubsection{Визуелизација и пристап до податоците}
+
+Откако податоците се складирани во базата, тие стануваат достапни за
+визуелизација преку веб-контролната табла. Frontend апликација направена
+со React комуницира со Django REST API преку HTTP барања, при што API
+слојот врши SQL барања за извлекување на податоците во зададените
+временски интервали.
+
+Добиените податоци се прикажуваат преку интерактивни графици, виџети и
+табели, овозможувајќи им на корисниците да добијат увид во реално време
+и историски во состојбата на работната околина и активностите.
+
+\subsubsection{Интеграција на интелигентна анализа}
+
+Покрај стандардната визуелизација, платформата овозможува интелигентна
+анализа на податоците преку gpt\_service микросервисот. Овој сервис се
+повикува директно со потребите податоци кои треба да ги обработи со
+помош на AI модел и генерира текстуални анализи, препораки и детекција
+на аномалии. Резултатите од AI анализата се прикажуваат во frontend
+апликацијата како виџети што овозможува дополнителен слој на
+интерпретација на постоечките податоци.
+
+\subsection{Безбедносен модел на платформата}
+
+Безбедноста е еден од клучните аспекти при дизајнот на оваа IoT
+платформа, поради фактот што најголемиот дел од уредите се поставени во
+небезбедни средини и комуницираат преку јавни мрежи. Класичната
+автентикација, како што е споменато претходно, со корисничко име и
+лозинка не е соодветна за вакви системи, бидејќи често претставува чест
+извор на безбедности пропусти. Поради тоа, во рамките на оваа платформа
+е имплементиран безбедносен модел базиран на mutual TLS (mTLS).
+
+Кај mTLS, и клиентот (IoT уредот) и серверот (MQTT \texttt{broker}-от) меѓусебно
+се автентицираат преку X.509 дигитални сертификати. На овој начин се
+обезбедува двострана проверка на идентитетот, како и енкрипција и
+интегритет на податоците при нивниот пренос. Секој уред поседува
+уникатен сертификат, со што се овозможува прецизна идентификација и
+контрола на пристапот до системот.
+
+Во основата на овој модел се наоѓа интерен Certificate Authority (CA),
+која ги потпишува сите сертификати во системот. Процесот на издавање на
+сертификат се реализира преку \texttt{device\_manager} сервисот, кој при
+регистрација на уред генерира сертификат и приватен клуч, ги складира
+релевантните податоци во базата и му ги враќа на корисникот за
+инсталација на уредот.
+
+За управување со компромитирани или неактивни уреди се користи механизам
+за повлекување на сертификати преку Certificate Revocation List (CRL).
+При повлекување на сертификатот, тој се означува како невалиден во
+системот, CRL листата се ажурира и MQTT \texttt{broker}-от автоматски го одбива
+секој понатамошен обид за поврзување со тој сертификат.
+
+Изборот на mTLS обезбедува високо ниво на безбедност, елиминација на
+лозинки, силна криптографска идентификација на уредите и заштита од
+напади како man-in-the-middle, што го прави овој пристап особено погоден
+за IoT платформи.
+
+\subsection{Дизајн на базата на податоци}
+
+Складирањето на податоците во системот е дизајнирано така што овозможува
+сигурно управување со уредите, дигиталните сертификати и телеметриските
+мерења. Поради временската природа и големиот волумен на податоци,
+базата на податоци е реализирана со \texttt{PostgreSQL} со \texttt{TimescaleDB}
+екстензија.
+
+\subsubsection{Табела \texttt{devices}}
+
+Табелата \texttt{devices} ги содржи основните информации за секој регистриран
+уред во системот во неа се складираат податоци како:
+
+\begin{itemize}
+\item
+  Id - единствен идентификатор на уредот
+\item
+  name - име на уредот
+\item
+  Location - локација уредот
+\item
+  Created\_at - време на регистрација
+\end{itemize}
+
+Оваа табела претставува централна точка за поврзување на сите останати
+податоци во системот
+
+\subsubsection{Табела \texttt{device\_certificates}}
+
+Табелата \texttt{device\_certificates} се користи за управување со X.509
+сертификатите поврзани со уредите. Таа содржи:
+
+\begin{itemize}
+\item
+  Id - сериски број на сертификатот
+\item
+  Device\_id - надворешен клуч кон табелата devices
+\item
+  Issued\_at - датум на издавање
+\item
+  Expires\_at -- датум на истекување
+\item
+  Revoked\_at - датум на повлекување (доколку постои)
+\end{itemize}
+
+Преку оваа табела се обезбедува информации за целиот животен циклус на
+секој сертификат
+
+\subsubsection{Табела \texttt{telemetry}}
+
+Табелата \texttt{telemetry} претставува \texttt{TimescaleDB hypertable} и е
+оптимизирана за складирање на временски серии од телеметриски податоци.
+Таа содржи:
+
+\begin{itemize}
+\item
+  Device\_id - идентификатор на уредот
+\item
+  Metric - тип на измерениот параметар
+\item
+  Value - измерена вредност
+\item
+  Timestamp - време на мерење
+\end{itemize}
+
+Податоците се автоматски партиционирани по време, што овозможува високо
+ниво на ефикасност при внесување и пребарување на податоци. Примарниот
+клуч е составен од (timestamp, device\_id, metric), што овозможува
+оптимизирани прашалници при анализа на податоци по уред и временски
+опсег.
+
+\texttt{TimescaleDB} e избрана поради неколку технички предности како што се:
+
+\begin{itemize}
+\item
+  Оптимизирана за работа со временски серии
+\item
+  Автоматска компресија
+\item
+  Континуирани агрегации за пресметка на просечни вредности
+\item
+  Скалабилност и компатибилност со \texttt{PostgreSQL}
+\end{itemize}
+
+Со ова се овозможува ефикасно, стабилно и долгорочно чување и користење
+на телеметриските податоци од платформата. Целокупната структура на базата
+на податоци е прикажана на ER дијаграмот (слика~\ref{fig:er-diagram}).
+
+\begin{figure}[htbp]
+    \centering
+    \includegraphics[width=\textwidth]{Miscellaneous/er_diagram.png}
+    \caption{ER дијаграм на базата на податоци на платформата}
+    \label{fig:er-diagram}
+\end{figure}