Ingegneria collaborativa: rompere il ciclo seriale con Team Ribbot

Ogni ingegnere hardware conosce bene l’incubo di dover gestire l’ultima versione di un file di progettazione condiviso con un partner. Tradizionalmente, quando arriva un nuovo assieme o un nuovo layout della scheda, non c’è via di scampo. Se la controparte ha migliorato cinque fori di montaggio ma ha spostato inavvertitamente un connettore importante, ci si ritrova esattamente nella stessa situazione di prima. O si accetta tutto ciò che è stato fatto e si corregge manualmente l’errore, oppure non si accetta nulla, bloccando così tutti i progressi ottenuti.

Lo sviluppo elettronico moderno dipende da una collaborazione efficace tra i team di ingegneria elettrica e meccanica. I flussi di lavoro seriali tradizionali spesso costringono gli ingegneri ad accettare intere revisioni di progetto o a rifiutarle completamente, aumentando il rischio di rilavorazioni e rallentando lo sviluppo del prodotto. La gestione selettiva delle modifiche consente l’ingegneria parallela permettendo ai team di esaminare, accettare o rifiutare singoli aggiornamenti di progetto, mantenendo al contempo l’integrità del design e la sincronizzazione tra le discipline.

Punti chiave

• Nei flussi di lavoro tradizionali, gli ingegneri devono accettare un intero insieme di modifiche o rifiutarlo completamente, rendendo facile introdurre errori o perdere progressi preziosi.
• MCAD CoDesigner consente agli ingegneri di esaminare, accettare o rifiutare singole modifiche, eliminando la necessità di scendere a compromessi tra avanzamento e accuratezza.
• I team meccanici ed elettrici possono lavorare contemporaneamente sullo stesso progetto, effettuando più aggiornamenti in parallelo senza ostacolarsi a vicenda.
• L’anteprima e l’applicazione selettiva delle modifiche assicurano che gli errori non si propaghino, mantenendo la stabilità pur consentendo iterazioni rapide.

Il caso Ribbot: unire aggiornamenti tra discipline diverse

Sebbene il Team Ribbot operi in un ambiente robotico altamente competitivo, le sfide di collaborazione che ha affrontato sono comuni anche nello sviluppo di elettronica, automotive, aerospaziale, industriale e sistemi embedded. Creare un bot campione per la BattleBots Pro League significa realizzare un’elettronica densa e complessa all’interno di uno chassis corazzato. Il problema per questo team è che i suoi membri vivono in cinque stati diversi, pur essendo anche pienamente impegnati nelle rispettive carriere. Non c’è tempo per errori quando si apportano aggiornamenti al layout della scheda.

Quando il progetto di assieme aggiornato viene inviato a un ingegnere, quest’ultimo deve apportare le modifiche necessarie senza compromettere il resto del progetto del team. Se l’ingegnere destinatario fraintende, introduce errori o altera il progetto precedente, potrebbe sprecare molto tempo e annullare progressi significativi.

Il dilemma del tutto o niente

Il problema fondamentale nella progettazione collaborativa risiede nell’assenza di granularità nella combinazione dei contributi. Se due ingegneri, uno meccanico e l’altro elettrico, stanno lavorando sullo stesso assieme nello stesso momento, in ogni singolo aggiornamento verranno apportate numerose modifiche. In assenza di capacità di filtraggio, gli ingegneri si trovano di fronte a una scelta obbligata: adottare ogni singola modifica apportata dal collaboratore oppure ignorare completamente l’intero aggiornamento. I flussi di lavoro ingegneristici tradizionali si basano spesso su passaggi di consegne seriali del progetto, in cui una disciplina deve completare il proprio lavoro prima che un altro team possa proseguire in sicurezza.

Vecchio flusso di lavoro: accettazione totale forzata

Prima di implementare la soluzione attuale, utilizzavamo il concetto di sostituzione dei file di progetto e/o di assieme. Ogni volta che il responsabile della progettazione meccanica forniva un disegno aggiornato, l’ingegnere elettrico non aveva altra scelta che importare l’intero pacchetto di documenti. Questo significava che, se il responsabile meccanico riusciva a spostare correttamente un determinato foro di montaggio ma sbagliava di pochi millimetri il posizionamento del connettore, l’ingegnere elettrico non poteva scegliere tra le due modifiche. Questo approccio creava un rischio ingegneristico non necessario, perché miglioramenti non correlati e modifiche involontarie venivano raggruppati in un unico aggiornamento.

Nuovo flusso di lavoro: filtraggio granulare e selettivo delle modifiche

Ribbot ha ottenuto questo risultato sfruttando le funzionalità di Selective Change di MCAD CoDesigner. Invece di ricevere gli aggiornamenti in blocco, il software analizza quelli ricevuti dal progettista elettrico e li presenta in un elenco da selezionare singolarmente. La gestione granulare delle modifiche consente ai team di ingegneria di preservare il lavoro già validato, esaminando solo gli aggiornamenti che interessano la propria disciplina.

In altre parole, se un aggiornamento dal lato elettrico contiene modifiche potenzialmente utili ma anche alcune che potrebbero creare un problema di ingombro a causa dello spostamento di un componente meccanico, l’ingegnere meccanico può semplicemente selezionare solo ciò che desidera.

Vera concorrenza operativa e lo scudo del filtro

L’ingegneria concorrente consente ai team elettrici e meccanici di lavorare in parallelo invece di attendere passaggi di consegne sequenziali del progetto, migliorando significativamente la velocità di iterazione e riducendo al contempo il carico di coordinamento. Il team meccanico può modificare il layout della scheda mentre il team elettrico posiziona contemporaneamente i componenti, consentendo di apportare decine di modifiche in una sola serata. 

Quando il gruppo meccanico invia un aggiornamento con cinque eccellenti modifiche strutturali ma con una variazione indesiderata nel posizionamento di un componente, il team elettronico non deve ignorare l’intero file né accettare l’errore. Può invece filtrare l’errore, importare gli aggiornamenti strutturali e continuare a lavorare con piena autonomia nel proprio dominio.

"Possiamo anche scegliere quali modifiche vogliamo accettare... se [l’ingegnere meccanico] sposta accidentalmente qualcosa che non volevo fosse spostato, posso semplicemente rifiutare quella parte della sua modifica accettando le altre modifiche. Per noi è un enorme vantaggio." — Nick Sorensen, Principal Electrical Engineer

Collaborazione non lineare e integrità del progetto

La gestione selettiva delle modifiche di MCAD CoDesigner consente una collaborazione non lineare permettendo ai team di ingegneria di valutare gli aggiornamenti proposti prima che diventino parte del progetto attivo. Questo aiuta a preservare l’intento progettuale supportando al contempo una collaborazione continua tra discipline.

Perché i flussi di lavoro ingegneristici seriali rallentano lo sviluppo hardware

Lo sviluppo hardware tradizionale segue spesso un flusso di lavoro seriale in cui i team elettrici, meccanici e produttivi completano il lavoro in sequenza. Sebbene sia un approccio lineare e semplice, crea colli di bottiglia perché ogni disciplina deve attendere revisioni complete del progetto prima di poter procedere. Man mano che i progetti diventano più complessi, questi ritardi aumentano la probabilità di conflitti di versione, lavoro duplicato, lacune comunicative e rilavorazioni non necessarie. I flussi di lavoro di ingegneria parallela riducono questi rischi consentendo ai team di collaborare continuamente mantenendo il controllo sulle singole modifiche di progetto.

Gestire le modifiche selettive del progetto (passo dopo passo)

Progressi paralleli per risultati professionali

Nella BattleBots Pro League, Ribbot può iterare più rapidamente rispetto al passato. Grazie alla capacità di collaborare e progettare in parallelo, Ribbot sarà sempre un passo avanti. Gli stessi vantaggi del flusso di lavoro si applicano allo sviluppo hardware commerciale, dove la riduzione dei tempi di iterazione del progetto può migliorare le tempistiche, la qualità del prodotto e la produttività ingegneristica.

Dimentica i passaggi di consegne e inizia a progettare in parallelo. Scopri come gestire le modifiche selettive in MCAD CoDesigner.

Progettazione parallela: domande frequenti

L’accettazione selettiva funziona sia per gli ingegneri elettrici sia per quelli meccanici?

Sì. Con Altium Designer o qualsiasi altro strumento MCAD, come SOLIDWORKS, hai la possibilità di visualizzare le modifiche suggerite e poi selezionare o deselezionare ciascuna di esse prima di applicarle al tuo spazio di lavoro.

Se rifiuto una modifica specifica del team partner, il file originale viene sovrascritto o compromesso?

Assolutamente no. Rifiutando una determinata modifica, la stai semplicemente escludendo dal tuo spazio di lavoro per mantenere l’assetto attuale. Il file principale del team partner rimane intatto e il sistema contrassegna l’elemento come rifiutato affinché entrambi i team possano tenerne conto rispetto ai diversi piani di progettazione.

È difficile vedere esattamente cosa è cambiato in un assieme complesso?

No. L’applicazione fornisce un’anteprima 3D dello spostamento con un’immagine evidenziata, così puoi vedere dove si trovava il componente prima dello spostamento e dove verrà posizionato successivamente. È facile individuare eventuali interferenze durante il processo di spostamento prima di finalizzare l’operazione.

Questo flusso di lavoro parallelo richiede uno specifico strumento di gestione del progetto per tracciare le modifiche?

No. Il meccanismo di controllo delle versioni e il registro sono entrambi inclusi nell’interfaccia di MCAD CoDesigner, che funge allo stesso tempo da mediatore e da archivio delle attività. Tutti gli spostamenti e le interazioni vengono registrati e contrassegnati temporalmente nell’applicazione stessa, che funge da centro di comunicazione. Non è necessario cercare le versioni in un foglio di calcolo esterno a questa applicazione.