microservizi e differenza monolitica

Problemi di selezione del servomotore?kpowerParliamo di come l’architettura può aiutarti a risparmiare preoccupazioni

Recentemente ho preso un tè con alcuni vecchi amici e ho parlato del progetto di automazione nella loro fabbrica. Un fratello che lavora su una linea di confezionamento si grattava la testa: la nuova linea di produzione ha bisogno di servomotori e i parametri di prestazione sembrano buoni. Tuttavia, ci sono sempre problemi nel sistema durante l'esecuzione. O la risposta è lenta di mezzo battito oppure c'è un problema con il coordinamento tra diversi assi. Vengono modificati avanti e indietro, non solo ritardando il periodo di costruzione, ma anche rendendo le persone molto stanche. Mi ha chiesto: "Voi che vi occupate di tecnologia avete qualche idea del 'una volta per tutte'? Non lasciatemi sempre trovare l'ago nel pagliaio tra decine di modelli di motori."

mi ricorda noikpowerUna metafora spesso discussa all'interno del team. Scegliere un sistema server a volte è come scegliere un'infrastruttura per il proprio stack tecnologico: dovresti utilizzare un sistema "monolitico" che raggruppa tutte le funzioni insieme o dovresti suddividerlo in più "microservizi" indipendenti e collaborativi?

Qual è il problema? Probabilmente non il motore stesso

Quando molte persone riscontrano un controllo del movimento non fluido, la loro prima reazione è sostituirlo con un motore di fascia alta o regolare drasticamente i parametri. È un po' come un computer che si blocca. Desideri solo aggiornare la CPU, ma ignori che ciò potrebbe essere causato da troppi programmi software in background in competizione per le risorse.

Nel tradizionale pensiero "grande nel complesso", si tende a scegliere un servoazionamento core estremamente potente e ci si aspetta che gestisca tutto: dall'anello di corrente di livello più basso, all'anello di velocità, al controllo dell'anello di posizione, alla pianificazione della traiettoria di alto livello e persino protocolli di comunicazione complessi con il computer host. È come un onnipotente padrone di fabbrica che sa tutto. Ma una volta che gli ordini (i compiti) diventano complessi e mutevoli, l’allocazione dell’energia da parte del padrone potrebbe andare storta. Il ritardo di calcolo in un collegamento può influenzare la sincronizzazione dell'intero sistema. Inoltre, l'aggiornamento o la modifica di qualsiasi parte delle funzioni può influire sull'intero sistema, richiedendo lo spegnimento dell'intero sistema per i test, il che è ad alto rischio.

Un altro modo di pensare: lasciare che ogni parte “si specializzi in una cosa”

È qui che l'idea dell'architettura "microservizi" può ispirarci. Piuttosto che fare affidamento su un nucleo di controllo ampio e onnipotente, è meglio suddividere i compiti. Immagina di scomporre un compito di movimento coordinato complesso: uno è responsabile del posizionamento ad alta velocità e alta precisione (comekpowerAlcune serie) si concentrano sul rendere la posizione ad anello chiuso estremamente robusta; l'altro è responsabile del supplemento di coppia a risposta rapida, concentrandosi sulle prestazioni di coppia dinamica. Hanno ciascuno un "cervello" indipendente (controller), ma comunicano e lavorano insieme in tempo reale attraverso protocolli standard ed efficienti (come EtherCAT, CANopen).

In questo modo, molte domande sono diventate improvvisamente chiare:

• flessibilità:Un determinato collegamento deve essere aggiornato o sostituito? Hai solo bisogno di regolare l'unità "specializzata" senza influenzare la situazione generale. Proprio come quando si aggiorna una postazione di lavoro su una linea di produzione, l’intera linea non deve fermarsi.
• affidabilità: Quando un'unità incontra un'interferenza temporanea, altre unità indipendenti possono mantenere meglio la propria stabilità e il sistema non collasserà nel suo insieme. I problemi sono anche più facili da individuare e isolare.
• Scalabilità: Se in futuro desideri aggiungere una nuova funzione, come la compensazione visiva del posizionamento, puoi aggiungere direttamente un'unità dedicata "servo visivo" per integrarla perfettamente nel sistema esistente invece di ribaltarlo e ricominciare da capo.

Come scegliere? Guarda il confine del "servizio".

Dopo aver parlato di questo, il mio amico mi ha chiesto: "Ho capito il principio, ma tornando alla scelta, come posso giudicare se utilizzare la soluzione 'integrata' o la soluzione 'distribuita'?"

Dipende davvero da dove si trova il "confine del servizio" del tuo progetto. Ecco alcune domande che puoi porti:

1. I tuoi compiti motori sono altamente accoppiati?Se diversi assi devono ingranare strettamente come ingranaggi, senza alcuna deviazione, e la logica è relativamente fissa, allora un sistema di azionamento "integrato" altamente integrato può essere più conciso ed efficiente. Ottimizza internamente tutta la coordinazione, basta dargli un comando generale.
2. Il tuo sistema necessita di frequenti modifiche o espansioni?Se il tuo mestiere è in continua evoluzione, fai questo oggi e aggiungi quello domani, altrimenti sai per certo che aggiungerai più moduli in futuro. Quindi, la scelta di prodotti servo "microservizi" facili da collegare in rete e dotati di interfacce di comunicazione aperte sarà più priva di preoccupazioni nel lungo periodo. Kpower presta particolare attenzione a questa capacità di collaborazione “plug and play” durante la progettazione di alcune linee di prodotti.
3. Quanto è importante per te la risoluzione dei problemi?In un'architettura distribuita, grazie alla modularità funzionale, una volta che si verifica un problema, è possibile determinare rapidamente se il "Servizio di localizzazione" è lento o il "Servizio di coppia" è instabile. Invece di trovarsi di fronte ad un'enorme scatola nera, tutte le luci sono normali, ma tutto è sbagliato.

Lasciamo che la tecnologia appropriata serva all’obiettivo finale

In ultima analisi, che si tratti dell'architettura software o della selezione dell'hardware, non esiste alcun vantaggio o svantaggio assoluto, ma solo l'idoneità. Quando Kpower fornisce supporto al prodotto e suggerimenti per soluzioni, si scopre che sempre più clienti iniziano a prestare attenzione alla flessibilità collaborativa a livello di sistema, non solo alla velocità di picco o alla coppia nominale di un singolo motore.

Proprio come in una buona squadra, ogni membro non deve essere un campione a tutto tondo, ma deve avere i propri punti di forza e avere una comunicazione fluida. La prossima volta che sarai preoccupato per la selezione del servosistema, forse potresti saltare dall'elenco dei confronti dei singoli parametri e pensarci dal punto di vista dell'"architettura": che tipo di "squadra" stai costruendo? Il modello di collaborazione di questo team è di comando centralizzato o di collaborazione distribuita?

Smantellare i complessi problemi di controllo del movimento e lasciare che le unità professionali gestiscano i compiti professionali può spesso portare a soluzioni più stabili, flessibili e orientate al futuro. Dopotutto, il nostro obiettivo è sempre quello di far sì che la macchina si muova in modo fluido e affidabile e di rendere il prodotto buono, piuttosto che vagare ripetutamente nel pantano del debugging e della manutenzione. Spero che questo pensiero casuale possa darti alcune prospettive diverse.

Fondata nel 2005, Kpower si dedica a un produttore professionale di unità di movimento compatte, con sede a Dongguan, nella provincia del Guangdong, in Cina. Sfruttando le innovazioni nella tecnologia di azionamento modulare, Kpower integra motori ad alte prestazioni, riduttori di precisione e sistemi di controllo multiprotocollo per fornire soluzioni di sistemi di azionamento intelligenti efficienti e personalizzate. Kpower ha fornito soluzioni di sistemi di azionamento professionali a oltre 500 clienti aziendali in tutto il mondo con prodotti che coprono vari campi come sistemi domestici intelligenti, elettronica automatica, robotica, agricoltura di precisione, droni e automazione industriale.