Hier ga je wel kort door de bocht door een sturingseenheid simpelweg een computer te noemen. Je zit hier in de wereld van automatisering waarbij de doorsnee Tweaker eerder met home automation in aanraking komt met typerend een Raspberry Pi die als veredelde controller dienst doet maar in dit geval hebben we het over car automation waarbij ook nog process automation bestaat voor industrie.
Het probleem is dat je inputs & outputs moet aansturen, je hebt bijvoorbeeld een motortje of een temperatuur meting waarbij je met gewone analoge elektrische signalen zit te werken. Die gaan in car automation net zoals bij home automation rechtstreeks naar een ingang van de controller.
Als je gaat centraliseren zit je eerder in het process automation te werken waarbij je een analoog elektrisch signaal naar een I/O sturingskaart brengt die vervolgens de boel digitaal doorstuurt naar een centrale controller/sturingseenheid. Het nadeel daaraan is de je met aparte I/O kaarten zit en vervolgens een volledige field bus wat allemaal nogal veel plaats inneemt en dus niet echt geschikt is om in een auto te steken. Maar het heeft dan wel weer als voordeel dat het eenvoudig uitbreidbaar/aanpasbaar is, iets wat je in het knutselwerk met een Rasberry Pi wel nog kan opvangen maar bij een controller van auto of van een wasmachine wat dat betreft is de situatie eerder fixed.
Wat jij dan voorstelt is dat je alle elektrische aansturingen doortrekt tot aan 1 grote centrale sturing, dat het motortje van je ruitenwisser zijn elektrische kabels worden doorgetrokken. Dat levert serieuze problemen op, je gaat héél dikke kabelbomen krijgen en de lengte van je elektrische kabels waar I/O over gaat neemt toe waarbij die anologe signalen gevoelig zijn voor storing, alsook moet je meer stroom leveren om verlies op te vangen, dat luistert sterk omdat je een elektrisch signaal gaat gebruiken om te interpreteren, 3.36V van de luchtmassa meter staat bijvoorbeeld voor 50 gram/lucht, als dat zakt naar 3.33V door een lange kabel zonder compensatie heb je een probleem. Bij sommige sensoren zoals lambdasondes is die bekabeling dusdanig gevoelig dat je die nooit mag solderen, niet echt een geweldig plan te noemen om dan met gigantisch dikke kabelbomen aan analoge elektrische kabels te liggen doortrekken naar 1 locatie.
Daar zou je volledige digitale sensoren voor nodig hebben en volledig digitaal gestuurde elektromotoren voor je ruitenwissers zodat je die rechtstreeks digitaal kan aansturen ipv analoog, dat is echter duur.
En dus ja, dan steek je een controller bij de ruitenwissers om enkel de analoge signalen in & uit te sturen van de ruitenwisser omdat je dan niet ver moet lopen met je I/O elektrische kabels.
De CAN bus word gebruikt om die controllers met elkaar te laten praten, niet om ruwe signalen door te sturen zoals je in een andere reactie aangeeft. De reden daarvoor, die communicatie bus is véél te traag om zoiets als een camerabeeld over te sturen, men gaat nu pas beginnen met encryptie toe te passen op bus communicatie in auto's omdat al het vorige véél te traag was om encryptie te gebruiken, laat staan dat je daar een video stream over zou willen sturen. Dat is ook de reden waarom updates zo traag zijn, men moet die over een vrij basic bus communicatie sturen die daar niet voor gemaakt is.
Wat gebeurd er dan wel op die bus communicatie? Zeer low level communicatie, ik schud even iets uit mijn arm: S48 4 586 156324
Dat dan moeten worden gelezen als Slave 48, 4 = broadcast naar alle andere sturingen; 586 temperatuurmeting buiten, 156324, 18 graden buiten waarbij iedere controller maar zelf moet weten wie 48 is, welke meting 586 is of hoe 156324 omgevormd word naar 18 graden. Dat is niet zoals TCP/IP verkeer wat een veel hogere vorm van communicatie is.
Men gebruikt de CAN bus dus enkel om digitale data of commands uit te wisselen, zo kan de controller een command op de bus zetten zodat de controller die de ruitenwisser aanstuurt een input krijgt dat hij zijn 'zet ruitenwisser aan' logica kan uitvoeren. Maar in het voorbeeld dat ik uit mijn mouw heb geschud, er hoeft maar 1 controller daadwerkelijk een analoge input van een temperatuursensor te meten waardoor alle andere controllers nu weten dat het 18 graden is buiten. De sturing van de motor, climate control, tractiesystemen, automatische versnellingsbak, die willen allemaal weten hoe warm het buiten is, dankzij een CAN bus of andere weten ze dat zonder zelf een sensor te moeten hebben.
Om terug te keren waarom EV's meer en complexere controllers aan boord hebben, ze zijn gebouwd op compleet nieuwe platformen waarbij ICE's vaak upgedate oudere platformen zijn (en dus sowiezo beschikken over meer complexe sturingen). Tevens hebben ze complexe stroomvoorziening en complexe warmtesturing. Iets met 400V, 12V, energierecuperatie op remmen, elektromotor die generator kan spelen, stroomomvormers, stroom stabiliseren maar ook dat warmte produceren enorm veel energie kost. Bij een hybride is warmte best complex mits goed uitgevoerd met warmte uitwisseling tussen interieur, koelsysteem batterij en koelsysteem ICE maar bij de volledige EV's zijn tegenwoordig ook warmtepompen terug te vinden.
Dat de automatisatie wereld achter loopt, dat is een feit dat ze aan zichzelf te danken hebben doordat ze in het verleden niets moesten weten van die "veel te complexe IT wereld", maar dat wilt niet zeggen dat je zomaar heel hun werkwijze aan de kant kan schuiven, dat is net een van de redenen waarom ze nog steeds wantrouwig zijn tov "IT" of toch vanuit hun perspectief gezien, ze hebben schrik dat ze een onbetrouwbaar "IT systeem" gaan krijgen waar ze geen controle meer over hebben. En kan je zeggen wat je wilt, die controller van je climate control van je 20 jaar oude auto of wasmachine, die doet het vandaag nog altijd, dat heeft ook zo zijn redenen.
[Reactie gewijzigd door sprankel op 23 juli 2024 12:27]