TECHNISCHE SPECIFICATIE Cinnovate Versie 2.0
Inhoudsopgave 1. Inleiding... 2 2. Eindproduct... 2 3. Onderdelen van het eindproduct... 2 Sensor... 2 Tech data X4M200:... 3 Onderbouwing... 3 Sensor Development Kit vs Respiration Sensor... 3 C++... 3 Socket Server... 4 Eisen... 4 Onderbouwing... 4 Web socket... 4 API... 4 Besluit... 4 Database... 4 Front-End... 5 Eisen... 5 Onderbouwing... 5 4. Technisch streven... 6 1
1. Inleiding Het doel van de applicatie is om nachtelijke onrust te detecteren en weer te geven, zodat verzorgers hierop kunnen inspelen. In dit document wordt informatie verschaft over de technische keuzes die gemaakt zijn over de structuur van de applicatie. Aangezien een applicatie op meerdere manieren gebouwd kan worden met verschillende programmeertalen en tools, wordt er in dit document onderbouwd waarom voor deze keuzes gekozen zijn. Hierbij zijn de plus- en minpunten van de verschillende opties tegen elkaar opgezet, waardoor er een weloverwogen beslissing genomen is. Dit document is bedoeld voor iedereen die inzicht wil over de gemaakte technische beslissingen met betrekking tot de structuur van de applicatie. 2. Eindproduct Het eindproduct is een real-time applicatie die onrust bij een patiënt aantoont, tezamen met zijn ademhaling en beweging. De respiratie gegevens komen uit de Xethru X4M200 respiratie-sensor. De onrust gegevens komen uit het algoritme, gemaakt door een 4 de -jaars student, die de respiratiegegevens ontvangt als input. Hierna worden de onderdelen van het systeem verder belicht. Deze zijn schematisch weergegeven in figuur 1. Figuur 1 Eindproduct 3. Onderdelen van het eindproduct In dit hoofdstuk worden alle onderdelen van de applicatie gedefinieerd. Sensor De sensor is het deel van de applicatie die gegevens verzameld. Er is gekozen voor de Xethru X4M200 respiratie-sensor. Deze kan op afstand d.m.v. infrarood radartechnologie afstand meten tot objecten. Xethru heeft op deze sensor een algoritme gezet die, bij een afstand van minimaal 40cm, respiratiegegevens kan verschaffen. Een laptop of een externe controller (zoals een Raspberry Pi) geeft de respiratie gegevens door aan de Socket Server. De code hiervoor wordt door het team geschreven. 2
Tech data X4M200: Radar board: X4A02 rev 3 Radar sub system: X4SIP02 rev 4 (X4 SoC) MCU: XTMCU02 rev 4 7.29/8.748 GHz Baseband & RF IQ Amplitude-Phase Onderbouwing Sensor Development Kit vs Respiration Sensor Bij de aanvang van de comaker hadden we de Xethru Sensor Development Kit tot onze beschikking. Wij zijn ermee begonnen door deze kit aan te sluiten en de bijbehorende Xethru Explorer software op onze laptops te installeren. Daaruit bleek dat deze sensor kit alleen ruwe (radar)gegevens naar de laptop stuurt. Wij hebben op het internet, via zoekmachines en de Xethru website, gezocht over hoe we zelf een ademhalingsritme kunnen detecteren. We hebben toen ontdekt dat deze sensor kit bedoelt is om zelf een sensor te ontwikkelen aan de hand van de teruggestuurde radio impulsen, door zelf eigen algoritmes te programmeren op de sensor zelf. Hiervoor is grondige kennis van natuurkunde en digitale signaalverwerking voor nodig. Voor ons doel zouden we ook nog kennis moeten hebben over hoe we uit deze ruwe gegevens een ademhalingsritme kunnen halen. Xethru blijkt ook een kant-en-klare variant te hebben, de Respiration Sensor. Deze kan zonder zelfontwikkelde algoritmes een ademhalingsritme detecteren. We hebben eerst nog geprobeerd de firmware voor de Xethru Respiration Sensor op de Sensor Development Kit te programmeren. Dit blijkt niet mogelijk te zijn, onder andere omdat de firmware controleert of er een bepaalde sleutel aanwezig is op de sensor, die de Respiration (en de Presence) Sensor vanuit de fabriek meekrijgen. Dit hebben we aangekaart bij onze product owner, Sander. We hebben hierna de Respiration Sensor besteld bij Xethru. 2 weken later was de Respiration Sensor binnen. Toen we deze aan onze laptops hadden verbonden konden we met het programma Xethru Explorer wel al een ademhalingsritme detecteren. C++ Om gegevens uit de sensor te halen heeft Xethru een Module Connector beschikbaar gesteld. Helaas is hiervoor alleen een binaire C++ library voor beschikbaar. Deze C++ library kan alleen worden gebruikt in combinatie met de GNU C++ Compiler. Dat betekent dat we geen gebruik kunnen maken 3
van Microsoft Visual C++ of Visual Studio. In plaats daarvan moeten we gebruik maken van MinGW, een ontwikkelomgeving voor de GNU Compiler Collection voor Windows. We hebben besloten JetBrains CLion te gebruiken als onze IDE, onder andere omdat deze MinGW ondersteunt en we al gebruik maken van de andere IDE s van JetBrains voor onze backend (Rider) en Front-End (WebStorm). Socket Server De Socket Server is de logica van de applicatie. De server ontvangt middels web socket verbindingen (TCP/IP) gegevens en verstuurt deze naar de weergave (Front-End). Ook communiceert de Socket Server met de database voor het opslaan en ophalen van gegevens. Eisen Geschreven in C# ASP.NET Regelt databasebeheer Ontvangt data van sensor Geeft data vrij aan Front-end Onderbouwing Tijdens het bepalen van de technische specificaties van het onrust prototype liepen we tegen het probleem aan hoe de data te versturen van de sensor naar de grafiek. Hiervoor is een server nodig die alle data coördineert. Uiteindelijk zijn wij op twee mogelijke oplossingen gekomen: een web socket of een API. Web socket Een web socket is een connectie die open blijft. Vervolgens kunnen beide partijen berichten naar elkaar sturen. Bijvoorbeeld de server ontvangt nieuwe gegevens, dan kan de server tegen de andere clients melden dat er nieuwe data beschikbaar is. API Een API is een gesloten verbinding. De client vraagt gegevens op waarna de verbinding verbroken word. Besluit De gegevens die wij moeten versturen zijn: onrust, werking van vitale organen en mobiliteit. Bij een API ontstaat er vertraging i.p.v. real-time, omdat de nieuwe gegevens iedere x aantal seconden weer opnieuw opgevraagd moeten worden. Dit lijkt ons niet wijs bij het monitoren van vitale organen. Om deze reden hebben wij besloten om de gegevens te ontvangen/ versturen via één of meerdere web sockets. Database Er is gekozen voor MongoDB. Voor deze opdracht moet er veel data opgeslagen worden. Vanwege performance hebben wij hierdoor gekozen voor een NoSQL database. In het bedrijf lag de voorkeur voor MongoDB, maar ook ElasticSearch en Redis waren welkom. Redis is geen optie doordat voor 4
een snelle werking er veel RAM geheugen nodig is op de database server, aangezien Redis zijn data opslaat in het RAM geheugen. ElasticSearch is net als MongoDB gebaseerd op geïndexeerde documenten. ElasticSearch heeft een groot voordeel op MongoDB, namelijk dat het een geweldige zoekfunctionaliteiten heeft. Deze functionaliteiten zouden wij niet gebruiken en samen met de voorkeur van het bedrijf is besloten om te gaan voor MongoDB. Front-End Er is gekozen voor een aparte Front-End. Het gaat om het gebruik van een JavaScript framework (NUXT.js). Middels een JavaScript framework kan een reactief scherm opgesteld worden om de gegevens in grafieken etc. weer te geven. Eisen Geschreven in ES5/ES6 in Nuxt.JS Geeft data weer Krijgt data van Socket Server Onderbouwing Er is gekozen voor een aparte Front-End, omdat het gebruik van JavaScript frameworks onderhoudsvriendelijk is en het zich uitstekend leent voor real-time doeleinden. Er is voor Nuxt.js gekozen om meerdere redenen. Als eerste wil Cinnovate grote communities voor alle software die zij gebruiken. De meest gebruikte Javascript frameworks zijn: Angular, React, Vue/Nuxt. Daarnaast staat Angular bekend om dat het lastig te leren is voor beginners. Dit zou nadelig zijn voor het bedrijf als geen huidige werknemer gemotiveerd kan worden om dit erbij te leren. Natuurlijk kan een nieuwe kracht voor deze technologieën aangenomen worden. Echter is het niet verstandig in een bedrijf slechts één werknemer te hebben met kennis van een onderdeel van dit belang. React is geen framework maar een library. Hierdoor zijn er veel plugins nodig voor het maken van een applicatie. Dit maakt de applicatie lastiger te begrijpen en veel afhankelijker van kleinschalige plugins. De kleinste community is er voor Vue en Nuxt. Daarentegen is de community desalniettemin zeer groot en actief, ook hebben de frameworks goede documentatie en zijn er goede online-cursussen voor te volgen. Vue en Nuxt zijn opkomende frameworks. De reden dat Vue en Nuxt in een adem genoemd wordt is dat Nuxt een framework gebouwd op Vue is, dat op zichzelf ook een framework is. Vue is simpel in het gebruik en is de laatste jaren opkomend. Het is eenvoudig om een bibliotheek van componenten te maken. Vervolgens kan een developer binnen een paar minuten een hele frontend pagina maken. De developer hoeft dan enkel de juiste componenten op de pagina te zetten d.m.v. custom html-tags. En de componenten te koppelen met de daarbij horende logica binnen het Javascript framework of de socket server. Uiteindelijk is er gekozen voor Nuxt, omdat Nuxt voor het overgrote deel alleen handige functies toevoegt zoals een projectstructuur en server-side rendering. Op deze manier zou bijvoorbeeld een grafisch ontwerper samen met één front-end developer een hele huisstijl kunnen implementeren voor alle applicaties. 5
4. Technisch streven Hier staat een opsomming van elementen die het team en de opdrachtgever in het algemeen van belang vind bij applicatieontwikkeling. Deze elementen zullen indien toepasbaar en toelaatbaar i.v.m. tijd en andere factoren toegepast worden. Gebruik maken van kennis van de application lifecycle en OTAP Programmeer methodieken als SOLID, KISS en DRY Unit testen / TDD Zo veel mogelijk C# i.v.m. kennis binnen het bedrijf (Optioneel) Acceptatie testen met Cucumber / Gherkins (Optioneel) Applicatie meenemen in onze OTAP-bouwstraat incl. automatische tests. 6