\documentclass[a4paper]{article} \usepackage{comment} \usepackage[swedish]{babel} \usepackage[T1]{fontenc} \usepackage[utf8]{inputenc} \usepackage{graphicx} \usepackage{array} \usepackage{float} \usepackage{hyperref} \usepackage{amsmath} \graphicspath{{./figurer/}} \begin{document} \pagenumbering{gobble} \title{Projektplan för datatekniskt projekt (DAT290)} \author{Gustav Bruhn, Malin Alcén, Mohammed Louai Alayoubi,\\Gabriel Bengtsson, Daniel Karlsson, Edvin Nilsson, Erik Örtenberg} \date{2021-09-10} \maketitle \newpage \tableofcontents \newpage \pagenumbering{arabic} \section{Syfte} \label{sec:syfte} De senaste åren har bostadsinbrotten i Sverige ökat. Från 2015 till 2021 har andelen hushåll som blivit utsatta för bostadsinbrott legat på en stadig nivå runt 1,8 \%, till skillnad från tidigare år då andelen legat mellan 1,2 \% och 1,7 \%. Stölder vid inbrott har även ökat de senaste åren, särskilt vid den senaste mätning 2020 där stölderna ökat med 8\% jämfört med föregående år~\cite{bra_bostadsinbrott}. Syftet med detta projekt är att utveckla ett säkert larmsystem som ger trygghet i hemmet. Systemet ska fungera felfritt i både villor och lägenheter med möjligheten att koppla flera dörrlarm och sensorer till en och samma centralenhet. Sensorerna ska kunna känna av både rörelse i rummet samt vibrationer från t.ex. ryck i en dörr. \section{Mål} \label{sec:mål} Målet med projektet är att konstruera ett säkert larm- och låssystem med en centralenhet samt flera periferienheter. Systemet kommer ha stöd för ett flertal dörr- och rörelselarm kopplade till centralenheten. Varje enhet ska styras av en mikrokontroller av modellen MD407. Kommunikation mellan dessa enheter kommer att ske genom en CAN-buss (Controller Area Network) med ett egenutvecklat protokoll som ska kunna kommunicera även om det förekommer störningar på bussen. För att simulera störningar kommer en MD407 skicka ut en justerbar mängd brusdata på bussen. \subsection{Systemets olika delar} \label{subsec:systemets-olika-delar} \subsubsection{Dörrlarmen} \label{subsubsec:dörlarmen} Dörrlarmen ska larma om en dörr förblir öppen i en konfigurerbar tid passerat. I praktiken utlöses larmet till en början lokalt och signaleras exempelvis via en tänd lysdiod. Om larmsignalen fortfarande är aktiv efter en given tidsperiod ska centralenheten kontaktas och då initieras det centrala larmprotokollet. Larmet avaktiveras när rätt fyrsiffriga kod matas in på en knappsats kopplad till centralenheten. Dessutom ska dörrlarmen kunna aktiveras och inaktiveras individuellt via centralenheten. En inaktiverad eller avlarmad dörr indikeras med en grön lysdiod vid dörren. \subsubsection{Rörelselarm} \label{subsubsec:rörelselarm} Rörelselarmen ska använda sig av en ultraljudsbaserad avståndsmätare eller en vibrationssensor. Avståndsmätare kan användas för att exempelvis utlösa ett larm om någon passerar en dörröppning eller i närheten av ett larmat föremål, medan vibrationssensorer kan användas för att detektera om ett fönster krossas eller om något larmat stationärt föremål förflyttas. När rörelselarmet utlöses ska centralenheten kontaktas direkt via CAN-bussen. Avståndsmätare ska konfigureras och kalibreras av genom centralenheten, medan vibrationssensorers känslighetskalibrering sker via en potentiometer på hårdvaran. \subsubsection{Centralenheten} \label{subsubsec:centralenheten} Centralenheten styr periferienheterna via CAN-bussen, hanterar knappsatsen och sköter USART-kommunikation mot en ansluten persondator. Från persondatorn, ansluten via USART (Universal Synchronous/Asynchronous Receiver/Transmitter), visas anslutna enheter som konfigureras via USART-terminalen. Centralenheten ska även larma om en periferienhet kopplas ur eller går sönder, samt hantera avlarmning via knappsatsen. Dessa larm, tillsammans med andra larm från periferienheterna, ska visas på den anslutna datorn. \subsection{Extrauppgifter} \label{subsec:extrauppgifter} Utöver detta grundsystem ska extra funktionalitet implementeras, se tabell~\ref{tab:extrauppgifter}. Förhoppningen är att alla listade uppgifterna ska färdigställas, men om det blir tidsbrist prioriteras prio 1-uppgifterna. För detaljer om modulerna som ska utvecklas för uppgift 1 och 2, se rubrik \textit{Testläge} respektive \textit{Automatisk initialisering} i avsnittet \ref{sec:systemöversikt}~\nameref{sec:systemöversikt} på sida~\pageref{sec:systemöversikt}. Uppgift 5 handlar om replay-attacker som kan utföras av angripare med fysisk tillgång till CAN-kablarna. I attacken spelas ett meddelande in för att sedan kunna återanvändas och återuppspelas. Detta kan exempelvis möjliggöra att en larmenhet kopplas ur utan att centralenheten registrerar det eller att ett inspelat dörrupplåsningsmeddelande återanvänds. Ett skydd mot detta ska implementeras i kommunikationsprotokollet och en enhet med syftet att utföra dessa replay-attacker ska utvecklas. Fler detaljer finns under rubriken \textit{Avlyssnare och sändare} i avsnittet \ref{sec:systemöversikt}~\nameref{sec:systemöversikt}. Uppgift 6 är en utökning av uppgift 5 som även tar hänsyn till att angriparen känner till systemet i detalj och hur programvaran ska modifieras för att också skydda mot denna variant av replay-attack. \begin{table}[H] \centering \begin{tabular}{|c|l|l|} \hline \textbf{Uppgift nr.} & \textbf{Beskrivning} & \textbf{Prioritet} \\ \hline \hline 1 & Testläge för periferienheter & Prio 1 \\ \hline 2 & Automatisk initialisering & Prio 1 \\ \hline 5 & Skydd mot replay-attacker & Prio 2 \\ \hline 6 & Skydd mot angripare med systemkännedom & Prio 2 \\ \hline \end{tabular} \caption{Extrauppgifter för projektet} \label{tab:extrauppgifter} \end{table} \section{Bakgrund} \label{sec:bakgrund} I projektet kommer MD407-mikroprocessorn användas som basplattform för enheterna. För kommunikation mellan MD407:or kommer en CAN-buss användas tillsammans med ett nätverksprotokoll i transportlagret. % skriv mer om detta här: \begin{comment} När det gäller projektplanen för DAT290 beskrivs här bakgrunden till projektet vad gäller tillämpningen, dess sammanhang och de tekniska förutsättningar som råder. För att beskriva tillämpningen och dess sammanhang behöver ni förklara hur system av den typen som ska konstrueras här fungerar i största allmänhet. \end{comment} \subsection{Tekniska förutsättningar} \label{subsec:tekniska förutsättningar} För att konstruera ett dörrlarm, ett rörelselarm, en centralenhet samt en störenhet så kommer följande hårdvara att användas: \begin{itemize} \label{itemize:hardware} \item 3x MD407-kort \item 1x Avståndsmätare (ultraljud), HC-SR04 \item 1x Vibrationssensor, "Flying-Fish" SW-18010P \item 1x Keypad \item 1x 7-segmentsdisplay \item 2x 4-polig RJ-11 kabel \item 1x RJ-11 förgrening \item 2x Tiopolig flatkabel \item 3x USB-kabel \item 1x Kopplingsplatta \end{itemize} Beroende på hur väl projektet följer tidplaneringen för dess milstolpar kan det eventuellt finnas ytterligare behov av komponenter. Skulle det finnas tid över åt att exempelvis utveckla ett skydd mot replay-attacker kommer det att finnas ett behov för ett extra MD407-kort och diverse kopplingskablar. Ingen hårdvara kommer att nyutvecklas för projektets ändamål -- endast befintlig hårdvara kommer att användas för konstruktionen av dörrlarmet, rörelselarmet, centralenheten samt störenheten. För att utveckla mjukvaran kommer ett STM-bibliotek (STM32F4) att användas. Detta bibliotek används främst för kommunikation över CAN-bussen och initiering av GPIO-pinnar. Utöver STM-biblioteket används utvecklingsmiljön CodeLite för programmeringen samt MiKTeX för att skriva, kompilera och rendera \LaTeX kod. Det som ska nyutvecklas under projektets gång är ett nätverksprotokoll för kommunikation mellan centralenheten och de övriga enheterna. Även funktionalitet för enheterna kommer att nyutvecklas. \subsubsection{MD407-kort} \label{sec:MD407} MD407-kortet är en enkortsdator som är konstruerad baserat på ARM-enchipsdatorn ST32F407 \cite{maskinorienterad_programmering}. Kortet är utvecklat på Chalmers tekniska högskola i Göteborg och har tillräcklig prestanda för projektet. De olika enheterna som ska utvecklas under detta projekt är alla baserade på varsitt MD407-kort tillsammans med övriga sensorer eller mätare. Enkortsdatorn lägger grunden till all funktionalitet som de olika enheterna har och möjliggör även CAN-kommunikation mellan dessa enheter. Se figur~\ref{fig:systemöversikt} för en övergripande bild över hur de olika enheterna kommer att kommunicera med varandra. \subsubsection{Avståndsmätare (ultraljud), HC-SR04} \label{sec:HC-SR04} Avståndsmätaren mäter avstånd genom att skicka ut åtta pulser ultraljud och sedan mäta hur lång tid det tar för ljudet att studsa tillbaka. Avståndet ges av \( \mathrm{\frac{Ts}{2}}\), där \(\mathrm{s}\) är ljudets hastighet och \(\mathrm{T}\) är den uppmätta tiden. \subsubsection{Vibrationssensor, "Flying-Fish" SW-18010P} \label{sec:SW-18010P} Vibrationssensorn kan känna av vibration från alla vinklar och larmar när en vibrationströskel överskrids. En inbyggd potentiometer kan justeras för att ändra vibrationströskel. \section{Systemöversikt} \label{sec:systemöversikt} För att dela upp projektet i moduler har projektgruppen skapat en systemöversikt (se figur~\ref{fig:systemöversikt}) där kommunikationen mellan moduler specificeras och modulernas ansvarsområde definieras. Utöver grundsystemet (centralenhet, larmenhet, dörrenhet) planerar projektgruppen att utveckla ett antal extra enheter: \begin{description} \item[Testläge] Debuggmodulens ändamål är att underlätta utveckling av grundläggande funktionalitet hos periferienheter. För att bekräfta att en modul fungerar behövs en miljö som kringgår kommunikation över CAN-bussen och genom nätverkslager. Debuggmodulen undviker detta genom att skapa en direktanslutning mellan periferienheterna och centralenheten. \item[Automatisk initialisering] Denna modul startas vid centralenhetens initialisering och tilldelar periferienheterna ID-nummer, startvärden m.m. automatiskt samt skapar en komplett lista över närvarande periferienheter i centralenhetens minne. \item[Avlyssnare och sändare] Denna modul är del av ett separat system och visas därmed inte i figur~\ref{fig:systemöversikt}. Modulen ansvarar för att spela in data som skickas på CAN-bussen. Sedan upprepar enheten datan i ett försök att lura centralenheten och t.e.x. låsa upp en dörr. \end{description} \begin{figure}[h] \centering \includegraphics[width=\textwidth]{systemöversikt} \caption{Systemöversikt för projektet} \label{fig:systemöversikt} \end{figure} \subsection{Centralenhetens moduler} \label{subsec:centralenhetens moduler} Centralenhetens moduler står för all systembred logik, d.v.s. all logik som larmsystemet behöver för att fungera. Data och logikmodulen står för att ta emot larmsignaler från periferienheter, hantera avbrott från knappsatsen och USART, kontrollera att periferienheter fortfarande är anslutna till nätverket samt att skicka ut kontrollsignaler till periferienheterna. Nätverkslagermodulen är ett gränssnitt för data och logikmodulen att kommunicera igenom. Gränssnittet ska ha stöd för att skicka och ta emot meddelanden, hantera paketförlust och skicka meddelanden. Mycket av denna funktionalitet kommer från CAN STM-biblioteket, men för att säkra kommunikation mellan noder måste ett system likt TCP (Transmission Controll Protocol) implementeras för att bekräfta att paket kommer fram. Centralenhetens IO är ett avbrottshanterat användargränssnitt för hantering av en knappsats och en USART-terminal. Dessa inmatningsenheter hanteras i avbrottsrutiner eftersom rutinerna är relativt kostsamma utifrån en tidsaspekt att köra kontinuerligt. \subsection{Dörrenhetens moduler} \label{subsec:dörrenhetens moduler} Dörrenhetens data och logikmodul avgör om dörren är öppen eller stängd och meddelar denna information till centralenheten. Likt centralenheten har även dörrenheten ett nätverkslager med sin egen modul. Denna modul är funktionellt ekvivalent till centralenhetens nätverkslagermodul. \subsection{Larmenhetens moduler} \label{sec:larmenhetens moduler} Larmenhetens data och logikmodul hanterar rörelse- och vibrationssensorn samt när de ska utlösa larm. Larmenheten kommunicerar med centralenheten genom larmenhetens nätverkslager vars funktionalitet är ekvivalent till de föregående nätverkslagren. \subsection{Nätverkslagret} \label{subsec:nätverkslagret} Nätverkslagret symboliseras av den streckade rutan i figur~\ref{fig:systemöversikt}. Syftet med nätverkslagret är att de olika enheterna ska kunna kommunicera med varandra. Kommunikationen kommer ske över en CAN-buss(\ref{subsec:tekniska förutsättningar}). \subsection{Återuppspelningsenhet} \label{subsec:återuppspelningsenhet} Återuppspelningsenhetens syfte är att pröva systemets säkerhet mot återuppspelningsattacker och hjälpa projektgruppen i utvecklingen av ett nätverksprotokoll som inte är sårbar av denna form av attack. En återuppspelningsattack fungerar genom att först spela in ett meddelande från CAN-bussen och sedan återupprepa det i ett försök att lura centralenheten att återuppspelningsenheten är en vanlig periferienhet. \section{Resursplan} \label{sec:resursplan} I tabell~\ref{tab:ansvarsområden} visas vilken person som har vilket ansvarsområde tillsammans med deras e-mail för direkt kommunikation. \begin{table}[H] \centering \resizebox{\textwidth}{!}{ \begin{tabular}{|l|l|l|} \hline \textbf{Post} & \textbf{Namn} & \textbf{E-mail}\\ \hline \hline Gruppledare & Gabriel Bengtsson & Gabriel.Bengtsson.Lofqvist@gmail.com \\ \hline Admin. dokumentationsansvarig & Daniel Karlsson & daniel.karlsson36@outlook.com\\ \hline Teknisk dokumentationsansvarig & Malin Alcén & malin.alcen@dtek.se\\ \hline Kodstandardansvarig & Erik Örtenberg & erik.ortenberg@gmail.com\\ \hline Testansvarig & Mohammed Louai Alayoubi & loieayoubi@gmail.com\\ \hline Resursansvarig & Gustav Bruhn & gustav.bruhn@live.se\\ \hline Planeringsansvarig & Edvin Nilsson & edvinn.nilsson@gmail.com\\ \hline \end{tabular} } \caption{Poster och mailadresser för projektgruppen} \label{tab:ansvarsområden} \end{table} Grupprummen i EDIT-huset och Idéläran kommer att utnyttjas under projektets gång för möten och arbete. Dessa lokaler kan utnyttjas vid valfri tid så länge lokalerna inte är bokade av andra studenter. I avsnitt~\ref{itemize:hardware} listas hårdvaran som kommer användas. Även förskrivna bibliotek (\ref{subsec:tekniska förutsättningar}) kommer användas för en effektivare utvecklingsprocess. Den hårdvaran som inte redan blivit tilldelad projektgruppen kommer införskaffas av grupphandledaren på begäran av projektgruppen. Gruppmedlemmar som inte har möjlighet att ta sig till campus har möjlighet till att delta på möten via Zoom eller Discord. Förutnämnda gruppmedlemmar kan också jobba med projektet genom att hämta filerna ifrån Github och utveckla på valfri plats. \section{Milstolpar} \label{sec:milstolpar} I tabell~\ref{tab:milstolpar} ges de milstolpar projektgruppen ska nå under arbetets gång. \begin{table}[H] \centering \begin{tabular}{|c|l|l|} \hline \textbf{Nr} & \textbf{Beskrivning} & \textbf{Datum} \\ \hline \hline 1 & Projektplan inlämnad & 2021-09-10 \\ \hline 2 & Fungerande centralenhet och störenhet & 2021-09-19 \\ \hline 3 & Fungerande prototyp med dörr- och rörelselarm & 2021-09-26 \\ \hline 4 & Rapportutkast 1 & 2021-10-01 \\ \hline 5 & Oppositionskommentar på rapportutkast 1 & 2021-10-01 \\ \hline 6 & Basuppgift och prio 1 extrauppgifter klara & 2021-10-06 \\ \hline 7 & Prio 2 extrauppgifter klara & 2021-10-15 \\ \hline 8 & Rapportutkast 2 & 2021-10-20 \\ \hline 9 & Demopresentation & 2021-10-29 \\ \hline 10 & Slutrapport inlämnad & 2021-10-29 \\ \hline 11 & Medverkansrapporter & 2021-10-29 \\ \hline 12 & Kamratuppskattning & 2021-10-29 \\ \hline \end{tabular} \caption{Milstolpar för projektet} \label{tab:milstolpar} \end{table} \section{Aktiviteter} \label{sec:aktiviteter} I tabell~\ref{tab:aktivitetslista} listas allt som kommer behöva göras för att projektet ska bli färdigt och approximativt hur många timmar alla moment kommer att kräva för att färdigställas. Tidsåtgången är de totala timmarna beräknade för alla sju gruppmedlemmar. \begin{table}[H] \centering \begin{tabular}{|c|l|c|} \hline \textbf{Nr} & \textbf{Beskrivning} & \textbf{Tidsåtgång} \\ \hline \hline 1 & Första genomläsning mikrodatordokumentation & 70h \\ \hline 2 & Framtagning av LaTeX-mallar & 14h \\ \hline 3 & Projektmöten (2h/vecka, 8 veckor, 7 personer) & 112h \\ \hline 4 & Projektledning (3h/vecka, 8 veckor) & 168h \\ \hline 5 & Dokumentgranskning & 30h \\ \hline 6 & Programmering av Störenhet + Centralenhet & 170h \\ \hline 7 & Programmering av Dörr/Rörelse Larm System & 170h \\ \hline 8 & Förbered/genomför fungerande Prototyp & 140h \\ \hline 9 & Oppositionsapport & 70h \\ \hline 10 & Arbeta med Extrauppgifter & 140h \\ \hline 11 & Andra genomläsning mikrodatordokumentation & 140h \\ \hline 12 & Skriv oppositionskommuntar & 70h \\ \hline 13 & Förbered/genomför demonstration & 70h \\ \hline 14 & Arbeta med Projektrapport & 210h \\ \hline \end{tabular} \caption{Aktivitetslista för projektet} \label{tab:aktivitetslista} \end{table} \section{Tidsplan} \label{sec:tidsplan} Ganttschemat i figur~\ref{fig:tidsplan} visar hur de olika parallella uppgifterna är planerade. En uppskattning av hur lång tid de olika uppgifterna kommer ta visas i tabell~\ref{tab:aktivitetslista}. \begin{figure}[H] \includegraphics[width=\textwidth]{figurer/tidsplan.pdf} \caption{En skiss på en Ganttbaserad tidsplan för projektet.} \label{fig:tidsplan} \end{figure} \section{Mötesplan} \label{sec:mötesplan} Gruppen planerar att hålla möten med handledare reguljärt på måndagar kl. 10.00 via Zoom genom hela projektet. För arbetsmöten kommer en kombination av Zoom, Discord och fysiska möten att utnyttjas. Arbetsmöten kommer planeras in löpande och kommer inte ha en förutsatt plan eller protokoll eftersom dessa är arbetspass och inte veckomöten. \section{Kommunikationsplan} \label{sec:kommunikationsplan} Under projektets gång kommer gruppen tillsammans med projekthandledaren hålla möten enligt tabell~\ref{tab:kommunikationsplan} utöver detta används en Facebook Messenger grupp för snabb kommunikation och för att besluta om arbetsmötestillfällen. Kommunikationstjänsten Discord används för längre och mer komplicerade diskussioner då kanalfunktionaliteten gör det enkelt att separera ämnesområden. För att förhindra konflikter i versionshanteringssystemet används en kanal i Discord för att markera vilka delar som arbetas på för tillfället. Ett exceldokument på gruppens delade Google Drive används för att kommunicera och logga antal timmar samt vad dessa timmar spenderats på. För att kommunicera med handledaren utöver mötena används e-post och SMS. \begin{table}[H] \centering \begin{tabular}{|l|l|l|l|} \hline \textbf{Vad} & \textbf{När} & \textbf{Till} & \textbf{Hur} \\ \hline Mötesprotokoll möte LV1 & 2021-09-01 & Alla & Canvas gruppanslag (som pdf) \\ \hline Kallelse möte LV2 & 2021-09-06 & Alla & Gruppens google drive \\ \hline Mötesprotokoll möte LV2 & 2021-09-07 & Alla & Canvas gruppanslag (som pdf) \\ \hline Kallelse möte LV3 & 2021-09-11 & Alla & Canvas gruppanslag (som pdf) \\ \hline Mötesprotokoll möte LV3 & 2021-09-13 & Alla & Canvas gruppanslag (som pdf) \\ \hline Kallelse möte LV4 & 2021-09-18 & Alla & Canvas gruppanslag (som pdf) \\ \hline Mötesprotokoll möte LV4 & 2021-09-20 & Alla & Canvas gruppanslag (som pdf) \\ \hline Kallelse möte LV5 & 2021-09-25 & Alla & Canvas gruppanslag (som pdf) \\ \hline Mötesprotokoll möte LV5 & 2021-09-27 & Alla & Canvas gruppanslag (som pdf) \\ \hline Kallelse möte LV6 & 2021-10-02 & Alla & Canvas gruppanslag (som pdf) \\ \hline Mötesprotokoll möte LV6 & 2021-10-04 & Alla & Canvas gruppanslag (som pdf) \\ \hline Kallelse möte LV7 & 2021-10-09 & Alla & Canvas gruppanslag (som pdf) \\ \hline Mötesprotokoll möte LV7 & 2021-10-11 & Alla & Canvas gruppanslag (som pdf) \\ \hline Kallelse möte LV8 & 2021-10-16 & Alla & Canvas gruppanslag (som pdf) \\ \hline Mötesprotokoll möte LV8 & 2021-10-18 & Alla & Canvas gruppanslag (som pdf) \\ \hline Avslutningsmöte LV9 & 2021-10-25 & Alla & Canvas gruppanslag (som pdf) \\ \hline \end{tabular} \caption{Kommunikationsplan för projektet} \label{tab:kommunikationsplan} \end{table} \section{Kvalitetsplan} \label{sec:kvalitetsplan} Under projektet ska moduler testas i en miljö utan störningar för att bekräfta modulens funktionalitet. I ett andra teststadie introduceras störmoment så som andra periferienheter. Dessa störmoment intrduceras för att emulera ett komplett system. Varje test ska genomgå ett antal olika steg: \begin{description} \item[Testsyfte]Vad ska testet visa? \item[Utförande]Hur ska testet utföras? Vilka scenarier testas? \item[Resultat]Vad är testresultatet? \item[Analys]Vad innebär testets resultat? Behövs fler tester av komponenten? Behöver andra komponenter testas ytterligare? \end{description} Beroende på testresultatet kan modulen gå vidare till nästa test eller debuggas. \section{Spelregler} \label{sec:spelregler} Om någon inte infinner sig på utlyst möte vid utsatt tid så ska denne vid nästa möte bistå med fika till projektgruppen. Detta görs för att uppmuntra punktlighet och deltagande. \bibliography{referenser} \bibliographystyle{IEEEtran} \end{document}