De keuze van een communicatieprotocol om te communiceren met een data genererende applicatie is soms heel eenvoudig. Vaak bepaald de applicatie met welk protocol er intern moet worden gecommuniceerd. Een mooi voorbeeld is een auto. Het communicatie systeem in auto’s heet CAN. Als er data uitgelezen moet worden om te verzenden naar een backoffice dan zul je aan moet sluiten op het CAN protocol. Zo zijn er nog wel meerdere interne protocollen als LIN of UART.
Als de data moet worden verzonden vanuit de applicatie naar een backoffice (Externe communicatie) zijn er ook heel veel mogelijkheden. De keuze voor een communicatieprotocol is in veel gevallen afhankelijk van de belangen van de verschillende gebruikers. Als je als leverancier sterk afhankelijk bent van de data omdat je businesscase daarop is ingericht moet je geen protocol nemen waarmee je afhankelijk bent van je klant. In dit soort gevallen kun je beter kiezen voor 4G, 5G, LTE-CatM maar ook LoRa of NBIoT is dan mogelijk, zodat het datatransport niet via jouw klant verloopt.
Heeft jouw klant ook belang bij de data dan kun je ook kiezen voor een Bluetooth Low Energy(BLE) of WiFi oplossing. Hieraan zijn ook geen maandelijkse abonnementskosten verbonden. Bij WiFi kun je dan gebruik maken van de router van de klant en bij BLE van een mobiele telefoon van de klant.
De engineers van Betronic werken aan een breed scala van producten en hebben hierdoor ook veel kennis van alle communicatie protocollen.
Wij gebruiken deze kennis al in het offerte traject om voor jouw oplossing het meest geschikte protocol te kiezen.
Maar welke factoren zijn belangrijk voor het kiezen van het juiste protocol? Welke partij heeft belang bij de data en de resultaten daarvan? Is er een lokale uitlezing noodzakelijk voor een servicemonteur dan kan dit worden gerealiseerd door een USB aansluiting maar ook door een draadloze WiFi Direct of Bluetooth Low Energy connectie. De juiste keuze is afhankelijk van wensen met betrekking tot de kostprijs en welke apparatuur de service engineer tot zijn beschikking heeft.
In het geval van een IoT product zijn er hele andere afwegingen die meespelen. Hier komen onderwerpen naar voren over hoe vaak en welke data verstuurd dient te worden, wel of geen software updates en is de business case van jouw product opgebouwd met een abonnement om eventuele kosten voor communicatie te kunnen dekken.
Onze ervaring is dat voor elk product weer andere afwegingen worden gemaakt. Wil je eens vrijblijvend sparren over de mogelijkheden voor jouw product neem dan contact met ons op.
Praktijk voorbeeld
Deze keer willen wij je een voorbeeld laten zien uit de medische sector. Het gaat hier om een product dat ervoor zorgt dat de patiënt zijn/haar medicijnen op tijd neemt. Gebeurt dit niet dan wordt een hulpinstantie ingeschakeld.
Werking
De gebruikers ontvangen van de apotheek een rol met zakjes waar medicijnen in zitten (baxter-rol). De zakjes zijn op volgorde van innemen achter elkaar geplaatst.
De baxter-rol wordt geplaatst in een scan apparaat welke verbonden is met een backoffice. De barcode op het eerst volgende zakje wordt gescand zodat het apparaat weet wanneer de patiënt het volgende zakje uit het apparaat moet halen.
Signalering
Om ervoor te zorgen dat de gebruiker zijn medicijnen op tijd inneemt geeft het display de tijd aan voor de volgende inname. Mocht de gebruiker zijn medicijnen niet innemen volgt er een lokale melding door middel van een geluidssignaal. Indien hier niet op wordt gereageerd zal er automatisch telefonisch contact worden opgenomen met de patiënt, leidt dit niet tot een contact dan wordt de huisarts of wijkverpleging automatisch gebeld. Deze zal dan een bezoek aan de patiënt brengen om vast te stellen wat er aan de hand is.
Protocol keuze
Belangrijkste eis van het product is, dat deze direct werkt nadat de stekker in het stopcontact is gestoken. Uitlezen door middel van een mobiele applicatie met Bluetooth of koppeling aan een WiFi netwerk vervalt omdat het product onafhankelijk van de omgeving van de patiënt moet werken. Na afweging van alle eisen en mogelijkheden is er in gezamenlijk overleg met de klant gekozen voor NB-IoT met een fall-back naar GPRS.