Tijdens het initiële ontwerp van C-Sense hebben we lang en veel nagedacht over de in en uitgangen van de hoofd module. De mogelijkheden zijn eindeloos maar je moet toch ergens een grens trekken anders komt er nooit een product 🙂

We hebben uiteindelijk een set van functionaliteiten geïmplementeerd waarmee we dachten te kunnen volstaan voor de meeste campers.

Maar tijdens de voorbereidingen voor een opdracht van Haaks campers, waarbij we een redelijk aantal relais moeten schakelen maar ook de status van de relais moeten kunnen detecteren, liepen we tegen een tekort aan digitale ingangen aan.

We kunnen dit wel oplossen omdat we al voorzien hadden dat we altijd uit moeten kunnen breiden en daarvoor een CAN bus geimplementeerd hebben. We hebben al 2 CAN modules (water flow en accu/stroomverbruik monitoring) welke super werken.

Maar het heeft ons wel aan het denken gezet of het basis ontwerp niet beter kan. Moeten we in de basis module wel functionaliteit opnemen die misschien nooit gebruikt wordt en hoe kunnen we zo flexibel mogelijk omgaan met wisselende functionele eisen…? Elk object (camper/nano-house/caravan) kan/zal natuurlijk weer anders zijn.

We hebben altijd we een bepaalde basisfunctionaliteit. Dit hebben we minimaal nodig om het geheel te kunnen laten werken en beheren:

• Orchestratie van het hele systeem (inclusief updates)
• Communicatie (LTE/Wifi/BLE/CAN)
• Locatie (GNSS)
• Aansturing display

En dan hebben we allerlei sensoren, relais enz. Welke natuurlijk gaan verschillen per soort en type object.

• Relais aansturing
• Relais status
• Led verlichting (dimmen/aan/uit)
• Beweging
• Barometer
• Luchtvochtigheid
• Gas
• Rook
• Water flow
• Water/vloeistof niveau
• Stroom verbruik
• KWh verbruik
• Accu status
• Temperaturen
• Waterpas (accelerometer)
• enz, enz

De wijziging die we gaan doorvoeren is dat we in plaats van zoveel mogelijk functionaliteit in de basis module en alleen CAN modules maken als het nodig is…. gaan naar zo min mogelijk functionaliteit in de basis module en alle andere functionaliteit altijd in een CAN module. We verplaatsen de object specifieke functionaliteit dus naar de edge.

De CAN modules worden dan 3 bouw blokken van verschillende grootte. De module die je op de afbeelding ziet is de eerste. Dit is een “LARGE I/O” CAN module met 17 digitale ingangen (5-24V optocouplers), 17 digitale uitgangen (500 mA sink voor relais), 4 analoge ingangen (met spanningsdeler), 4 20A 30V PWM uitgangen.

Later zullen we ook nog een medium en small ontwerpen met mogelijkheid tot uitbreiding met I2C of SPI IC-sensoren. Dan hebben we 3 generieke bouwblokken die flexibel zijn in functionaliteit en die afhankelijk van de behoefte ook op verschillende plaatsen in het object gemonteerd kunnen worden (wat weer bespaard op bekabeling). En alles gaat in DIN-rail behuizingen voor makkelijke montage, evt in een besturingskast.

Elke soort en type object krijgt dan zijn eigen set met configuratiefiles die bepalen welke functionaliteit welke poort op een CAN module heeft. Voor een nieuwe soort/type object hoeven we dan geen wijzigingen in de software door te voeren en enkel de configuratiefiles aan te passen.

De voordelen die we zo denken te behalen zijn:

• Flexibel in configuratie (ook na installatie)
• Nagenoeg eindeloos uitbreidbaar met standaard bouwblokken
• Flexibel in montage in object (minder bekabeling)
• Makkelijker calculeren/offreren (vaste prijzen standaard bouw blokken)
• Minder software wijzigingen bij nieuw type object
• Makkelijker te beheren/updaten
• Minder complexe basis unit (sneller en stabieler)

Nadelen/aandachtspunten:

• Mogelijk wat hogere kosten bij gebruik van minimale functionaliteit omdat er altijd minimaal 1 CAN module nodig is
• Goede administratie van configuratie files nodig

Het is weer een hoop werk maar we zijn ervan overtuigd dat dit het ons in de toekomst makkelijker gaat maken 🙂

(en het is natuurlijk heel leuk om te doen 😉 )