Akin's Laws of Spacecraft Design

Nell’ambito astronautico e spaziale, vengono spesso citate le leggi di Akin (le ho trovate citate in molti post di @Buzz, ad esempio). Ma molti non le conoscono o non ne hanno mai sentito parlare.

Chi è David Akin? è un professore di ingegneria aerospaziale all’università del Maryland, Direttore dello Space Systems Laboratory con 45 anni di esperienza nel settore.

Cito e traduco dal suo sito:
“sono stato impegnato nella progettazione di astronavi e sistemi spaziali per tutta la mia carriera, compreso l’insegnamento del corso finale di progettazione di sistemi spaziali, per 10 anni al MIT e ora per più di due decadi all’Università del Maryland. Queste leggi sono alcuni frammenti di saggezza che ho raccolto durante quel periodo, alcuni raccogliendo l’esperienza degli altri, ma soprattutto frutto dei miei fallimenti personali.
Originariamente le ho scritte e consegnate agli studenti dell’ultimo anno, come suggerimento sul modo migliore per sopravvivere nella loro carriera da progettisti. Mesi dopo, ho ricevuto una telefonata da un amico in California con i complimenti per le leggi, lette su una rubrica satirica.
Da allora, sono a conoscenza di una mezza dozzina di siti in tutto il mondo che presentano varie edizioni delle Leggi […]. Chiunque è invitato a linkarle, usarle, pubblicarle, inviarmi suggerimenti per leggi aggiuntive, ma ritengo che questo elenco sia l’insieme canonico delle Leggi di Akin”

L’elenco delle 44 leggi lo trovate qui
Alcune leggi possono risultare bizzarre e far sorridere, ma per esperienza personale nel settore aerospaziale penso siano tutte valide e applicabili quotidianamente.
Inoltre, mi piacerebbe avere la vostra ‘interpretazione’ di una o più leggi e magari collezionare qualche aneddoto ad esse legato.

Ho iniziato questo thread su Spazio Studenti per un motivo, che è lo stesso del prof.Akin : è dedicato ai neolaureati in ingegneria (e non) che si affacciano al mondo del lavoro. Fatene tesoro.

16 Mi Piace

LAW nr.1 : “Engineering is done with numbers. Analysis without numbers is only an opinion.”

Questa è la mia preferita: “l’ingegneria è fatta di numeri, un’analisi senza numeri è solo un’opinione” .
I requisiti, gli obiettivi e i risultati devono essere quantificabili: per questo gli ingegneri studiano tanta matematica. Non si può sostenere che il mio design sia ‘migliore’ del tuo, per quali parametri? Per quali valori?
Da un altro punto di vista : non si può giudicare se non con dati oggettivi alla mano, le chiacchiere stanno a zero, non c’è spazio per i “basterebbe che…”

Ho un aneddoto al riguardo : qualche anno fa, per un importante cliente americano, stavamo eseguendo delle lavorazioni meccaniche che prevedevano delle forature sull’hardware. Alla richiesta della quota del diametro da parte del cliente, l’ingegnere sistemista rispose : “about 6mm” .
Il cliente rispose solo con una sola parola : “ABOUT?” e ci beccammo un audit.
Non ho mai più scritto “about” su una mail, non ho mai più omesso le tolleranze di una quota o i decimali in una misura.

12 Mi Piace

Confermo al 150%! Purtroppo queste leggi troppo spesso vengono prese sotto gamba, ma io le trovo super valide.

Prendiamo ad esempio la legge n. 2:
“2. To design a spacecraft right takes an infinite amount of effort. This is why it’s a good idea to design them to operate when some things are wrong .”

Chi come me fa operazioni, sa quanto sia valida questa legge e quanto purtroppo sia troppo spesso sottovalutata durante la fase di progettazione.

Il capitolo di operations dello SMAD inizia con qualcosa tipo: l’ingegneria si aspetta che le cose funzionino, le operazioni si aspettano che le cose NON funzionino.

E la maggior parte del nostro lavoro consiste nel pensare in che modo le cose possano non funzionare, pensare a che effetto questo avrà e inventarsi un metodo (procedura) per rimettere le cose a posto o almeno mitigare questo effetto.

13 Mi Piace

La 35 sembra la stella guida di Elon Musk!

Grazie mille non le conoscevo!

La prima legge l’ho inserita nella mia firma digitale a lavoro :sunglasses:

1 Mi Piace

Grazie @furdisufit! Da “umanista” che però ha molta simpatia per l’ingegneria e gli ingegneri apprezzo lo spirito di queste leggi (alcune delle quali, tra l’altro, hanno una portata universale).

Mi permetterei anche una proposta. Se ci sono altri che possono continuare a commentarne alcune con episodi tratti dalla loro esperienza professionale, credo che ne verrebbe fuori un thread stimolante e istruttivo. :smiley:

6 Mi Piace

L’idea era proprio quella… sono curioso di leggere altri aneddoti. Non per forza strettamente legati all’ambito spaziale.

2 Mi Piace

Bastano i miei razzi ad acqua a confermare la numero 27:

“(Varsi’s Law) Schedules only move in one direction” Le date si muovono in una sola direzione"

Avevo comprato il materiale per iniziare a costruire il 27 agosto 2019. Speravo di costruire un sigillo funzionante nei giorni seguenti e di far esplodere una bottiglia in pressione il 28/29. Be’, il design quasi finale del sigillo è arrivato l’11 settembre, i primo lancio il 24, e nessuna bottiglia è ancora esplosa…

3 Mi Piace

Mi piace 3. "Il design è un processo iterativo. Il numero di iterazioni richieste è uno in più rispetto al numero attualmente completato. Questo è vero in ogni momento. " è così vero, a malapena finisco qualcosa che penso faccia schifo e voglio ricominciare.
Ci sono due siti che vorrei aggiungere:
Il mio insegnante di strutture metalliche: “un ingegnere non può dire che è impossibile, solo che gli rimane un po 'di lavoro”
E un altro di Saint-Exupery per le navi ma che si adatta allo spazio: "Se vuoi costruire una barca, non avvicinare uomini e donne per dare loro ordini, spiegare ogni dettaglio, dire loro dove trovarli. cosa … Se vuoi costruire una barca, dai vita al desiderio del mare nei cuori dei tuoi uomini e donne. "

4 Mi Piace

numero 15:
“(Shea’s Law) The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up.”

Su di questa, aneddoti ne avrei a bizzeffe, anche se non so quanto possano essere pubblicati in quanto non hanno raggiunto la stampa.

Parliamo per esempio di connettori di cavi con la “chiave” nella direzione sbagliata che non permettevano al connettore di essere installato perché non c’era abbastanza spazio, di interfaccie la cui femmina è stata modificata in integrazione, senza avvertire chi costruiva il maschio, equipaggiamenti “Mark II” qualche millimetro più larghi, che hanno richiesto di tagliare via un pezzo di struttura, e così via. Con alcuni casi di cui ci si è accorti dopo il lancio o addirittura durante un’EVA. :man_facepalming:

Se poi parliamo di interfacce dati, anche su questo avrei almeno un bell’esempio di qualcuno che ha deciso di non seguire gli standard CCSDS per qualche strano motivo, ma non ha pensato di informare la controparte, la quale si è accorta del problema durante la missione.

Insomma, per mia esperienza i due documenti più importanti in assoluto in un progetto sono l’IRD (Interface Requirements Document) e l’ICD (Interface Control Document, che in sostanza dettaglia la soluzione implementata per soddisfare l’IRD).

E purtroppo ogni tanto capita che qualcuno decida di deviare dall’ICD senza informare la controparte, con conseguenti ritardi (se ci si accorge del problema a terra) o anomalie in volo (se ci si accorge del problema durante la missione).

15 Mi Piace

Pero’ noi schiaccia bottoni di AIT siamo nella filiera proprio per scoprire quando si adottano le scorciatoie dal IRD o si devia dal CCSDS :slightly_smiling_face:

3 Mi Piace

Il problema è quando devi lanciare un pezzo di ricambio per la ISS, la cui integrazione è già stata fatta anni prima…

A quel punto devi sperare che gli NCR aperti dagli schiaccia bottoni di AIT siano stati riportati nella documentazione, altrimenti ci si ritrova a produrre pezzi di ricambio in base a degli ICD o disegni che non rispecchiano la realtà e a quel punto i primi ad accorgersene saranno gli schiaccia bottoni di ops, ma a quel punto sarà troppo tardi… Aggiungi che la documentazione l’ha scritta il prime ma l’AIT l’ha fatto il co-prime, et voilà :slight_smile:

3 Mi Piace

Chi non sbaglia mai sono quelli del Ingegneria :slight_smile:

1 Mi Piace

Calma raga! Che qui finisce a coltellate! :rofl: :rofl: :rofl: :rofl: :rofl:

Ps: quelli che non sbagliano mai sono quelli della contabilita’! :wink: :clown_face:

Tranquillo, che tra AIT e Ops siamo tutti d’accordo contro l’ingegneria :grin:

4 Mi Piace
  1. Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective.

Nel mio mondo si sostituisce il primo tipo di ingegnere con “consulente”, il secondo con “sviluppatore”, il terzo con chi prende sul serio gli User Acceptance Test. Ma il risultato non cambia.

PS. Non lavoro nell’aerospace, ma il 90% di queste leggi valgono anche altrove…

2 Mi Piace

Sottoscrivo.
A tal proposito mi è stata raccontata la storia di un satellite all’incirca 1 mm più grande della specifica di interfaccia con il lanciatore. Ciò venne scoperto solo sul sito di lancio e il fornitore dell’adattatore non volle concedere un waiver, pertanto il satellite dovette essere parzialmente smontato e rimontato al volo - con tutte le complicazioni del caso, adottando degli accorgimenti particolari per farlo rientrare nelle dimensioni.

Peraltro, a me piace molto la 13: La progettazione si basa sui requisiti. Non c’è giustificazione per progettare qualcosa che funzioni “un po’ meglio” di quanto definito dal requisito.
È una delle cose che non mi è stata trasmessa bene all’università, e che ho capito appieno solo poi.

12 Mi Piace

Sarebbe bello che i requisiti fossero tali. La maggior parte delle volte sono opinioni o indicazioni che sono perentorie e inattaccabili finché chi ha potere di cambiare idea non la cambia. E allora si riprogetta coi nuovi “requisiti”. L’esperienza porta a valutare quanto meglio rispetto al requisito progettare per anticipare il requisito aggiornato

2 Mi Piace

True story

1 Mi Piace