Rendere un sistema automobilistico più "modulare" in termini di software?

Vorrei iniziare osservando gli standard esistenti in quest'area, come ARINC 653 e (in particolare) AUTOSAR .

Entrambi sono sistemi basati su componenti in tempo reale in cui i componenti comunicano passando messaggi. È più complesso, ma in definitiva molto più flessibile, quello dell'approccio diretto all'uso delle caratteristiche di modularità di uno specifico linguaggio di programmazione.

Penso che, per lo meno, loro dovrebbero dirti quali sono le funzioni minime di ciascun componente. Ad esempio, (non ho idea della meccanica della macchina, quindi, porta l'esempio), una pompa potrebbe dover fornire il seguente insieme di funzioni: CurrentPressure , MaximumOperatingPressure , MinimumOperatingPressure .

Supponendo che tutti i componenti possano fornire un insieme simile di API, è possibile definire una serie di interfacce, come IPump , che definirebbe le funzioni minime che una pompa dovrebbe fornire.

Questo, a sua volta, ti permetterebbe di avere alcuni contratti contro cui puoi scrivere i driver, in modo che, indipendentemente dalla marca e dal modello, avresti sempre lo stesso set di funzioni disponibili, dove in ogni modello si occuperà quindi di implementa come sono forniti questi valori.

Quindi il tuo codice centralizzato funzionerebbe solo in termini di queste interfacce. Quindi, in sostanza, il tuo codice non sapere , né cura del resto, se stai lavorando con Brand A Pump o Brand B pompa .

Questa proposta presuppone ovviamente che ci sia un insieme di standard da qualche parte.

Penso che ti abbiano chiesto di fare l'impossibile. Facciamo qualcosa di simile nel nostro negozio con l'automazione industriale. Spesso acquistiamo presse meccaniche e le adeguiamo con il nostro sistema di controllo. Ci sforziamo molto per rendere l'interfaccia utente simile su tutte le macchine da stampa, ma internamente sono talvolta simili e talvolta molto diverse. Una pressa è dotata di sovraccarichi idraulici, uno ha il monitoraggio del tonnellaggio in stile strain gauge mentre un altro ha un monitoraggio del tonnellaggio in stile piezoelettrico.

Anche tra i sistemi che ogni macchina da stampa ha, come una pompa di lubrificazione a pressione, il modo in cui lavorano sono generalmente diversi.

Come gestiamo queste differenze senza follia? Noi no. Il software per ogni macchina è personalizzato al 90% circa. Disponiamo di una "biblioteca comune" di funzioni che usiamo attraverso presse, come un sistema di registrazione degli eventi, ma gli eventi che sono effettivamente registrati su ogni macchina da stampa sono quasi completamente unici. La libreria comune contiene la logica standard per l'interfaccia con una scheda di input analogico che usiamo su tutte le macchine da stampa.

Ogni stampa ha un motore principale, ma elettricamente tutti funzionano in modo leggermente diverso, quindi abbiamo una logica personalizzata per ciascuno.

Nel tuo esempio, puoi fare in modo che tu possa sostituire una pompa con un modello diverso senza dover apportare modifiche al software? Ne dubito. In effetti, l'importante è che tu anticipi la necessità di cambiare qualcosa quando lo fanno, e pensi a dove saranno fatti questi cambiamenti. Prova a farlo in modo che queste modifiche siano limitate a una singola classe o modulo. Che cosa si preoccupa del resto del sistema per quella pompa? Qualche altro sistema deve sapere che la pompa è in funzione prima che possa fare il suo lavoro? Quindi l'interfaccia richiede una proprietà Pump.Running . Come si imposta quel bit probabilmente dovrà cambiare quando sostituiscono la pompa, ma almeno la modifica dovrebbe essere localizzata. Sai che dovrai registrare i problemi nel sistema di segnalazione degli errori a livello di auto, quindi probabilmente hai bisogno di un'interfaccia di segnalazione degli errori, e dovresti assumere che il tuo modulo Pump debba essere iniettato con un riferimento a tale interfaccia nel costruttore o codice di inizializzazione.

Nei primi giorni delle automobili molte parti erano intercambiabili direttamente o con l'ausilio di un seghetto e un file. Era abbastanza comune per il motore, il telaio e la carrozzeria essere realizzati da aziende completamente diverse.

Negli anni Cinquanta e Sessanta era considerato interessante montare il miglior motore del motoviclo (ad esempio Triumph Bonneville) nel miglior telaio (ad esempio Norton Commando) con forse i freni e gli shock di una macchina completamente diversa.

Tutto ciò è stato possibile perché l'ingegneria era abbastanza grezza e le parti non erano realizzate con tolleranze elevate.

In un veicolo moderno anche le auto relativamente economiche hanno design altamente ottimizzati. Prendiamo ad esempio i flussi di gas (il pezzo di ingegneria che influisce maggiormente sulla potenza erogata); il design deve incorporare il filtro dell'aria, il carburatore / iniezione di carburante, il collettore di aspirazione, le valvole, il cilindro, il pistone, il collettore di scarico, le intestazioni di scarico, il silenziatore e il convertitore catalitico. La modifica di uno di questi componenti influisce sul flusso del gas e quindi sulla potenza e sul consumo di carburante (probabilmente in peggio).

È difficile capire come si possa avere un approccio plug and play alla progettazione dei componenti in questo scenario.

Il modo di modulare le cose (qualsiasi cosa) è di avere facciate per ogni componente. Se usi anche il passaggio dei messaggi invece delle API connesse direttamente, hai anche molta più flessibilità.

come esempio: immagina di avere 2 tipi di componenti dello sterzo: una ruota e 2 joystick; e 2 tipi di componenti di movimento: ruote e binari.

È possibile isolare ciascun componente dello sterzo per inviare un messaggio che descrive l'intenzione, ad esempio un volante ruotato di 10 gradi verso sinistra significa guidare il veicolo verso sinistra, in modo che possa costruire un messaggio che descrive l'intenzione e lo invia al movimento componente che trasforma questo in una rotazione di 10 gradi per le ruote, o una velocità più bassa per la traccia sinistra. Ora vedi che puoi inviare lo stesso tipo di messaggio per i joystick - quello destro premuto più a sinistra, si traduce nello stesso messaggio "svolta a sinistra di un po '".

Ora hai un sistema in grado di interscambiare un volante per due leve gemelle o per ruote. Mescola e abbina e non ti interessa quello che hai! Lo stesso principio si applica a tutto il resto: l'interfaccia deve essere progettata in modo indipendente dai componenti, decidere cosa occorre fare al veicolo senza pensare a come l'utente lo farà o l'hardware lo eseguirà.

L'utilizzo di un'architettura di passaggio dei messaggi significa che non è necessario collegare le cose: tutto si collega a un bus dei messaggi, quindi il volante sposterà i messaggi di guida sul bus e i componenti che riconoscono il messaggio di guida li elimineranno. Ciò aiuta quando si hanno diversi modi di controllare lo stesso sistema - ad esempio i pulsanti del volume della radio sul volante e il cruscotto e il bracciolo del passeggero posteriore - tutto semplicemente invia lo stesso messaggio al bus dei messaggi e tutto funziona.

Ora per l'hardware sei molto più limitato semplicemente perché le cose devono essere collegate insieme. Sei anche limitato dall'interfaccia che forniscono, ad esempio una batteria è una batteria, e sebbene possa essere una batteria al piombo o una cella a combustibile a idrogeno, deve avere le stesse spine e le stesse tensioni che escono da esso. In questo caso, sono necessarie interfacce standardizzate che ti limitano. Ad esempio, mentre puoi avere un telaio di dimensioni identiche e sagomato con ruote o tracce del serbatoio che possono essere scambiate, troverai che i vincoli fisici limiteranno le tue opzioni.