Die Gesetze des Raumfahrzeugdesigns (Akin’s Laws of Spacecraft Design)

• Eine Folie, die 40 praktische Prinzipien zusammenfasst, die auf Raumfahrzeugdesign und Engineering-Projekte anwendbar sind
• Betont zahlenbasierte Analyse, iteratives Design und fehlertolerantes Design als Kernprinzipien
• Enthält die realistische Warnung, dass Zeitpläne sich nur in eine Richtung bewegen und frühe Schätzungen immer zu niedrig ausfallen
• Über die Raumfahrttechnik hinaus direkt auf Software-, System- und Startup-Design im Allgemeinen anwendbar
• Eine praxisnahe Checkliste, die wiederkehrende Fehler bei technischen Urteilen verhindert

---

Gesetz 1 — Ingenieurwesen wird mit Zahlen bewiesen

• "Engineering is done with numbers. Analysis without numbers is only an opinion."
  • Ingenieurwesen wird mit Zahlen betrieben; Analyse ohne Zahlen ist nur eine Meinung
• Der Grund, warum Ingenieurinnen und Ingenieure viel Zeit ins Erlernen von Mathematik investieren
• Technischer Erfolg muss quantifizierbar sein
  • "Mein System ist schneller" → um wie viel schneller?
  • "Mein System ist günstiger" → wie hoch sind die Kosten?
  • "Mein System ist einfacher" → wie misst man Einfachheit?

Gesetz 2 — Fehlertolerantes Design

• "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."
  • Um ein Raumfahrzeug richtig zu entwerfen, ist unendlich viel Aufwand nötig; deshalb sollte man es so auslegen, dass es auch funktioniert, wenn einige Dinge schieflaufen
• Keine Systemarchitektur, die 100% Zuverlässigkeit verlangt
• Beispiele für Scheitern: Deepwater Horizon, Fukushima
• Beispiel für 3 way logic checking in Flugzeug-Steuerungssystemen

Gesetz 3 — Iterativer Designprozess

• "Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time."
  • Design ist ein iterativer Prozess, und die notwendige Anzahl an Iterationen ist immer genau eine mehr als die Anzahl, die man bisher durchgeführt hat
• Gutes Design ist niemals wirklich fertig

Gesetz 4 — Mit Enttäuschung umgehen

• "Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment."
  • Deine besten Designanstrengungen können im finalen Entwurf zwangsläufig nutzlos werden; man muss lernen, mit dieser Enttäuschung zu leben
• Bhargavas Gesetz: Nur 1 von 10 Forschungsprojekten findet den Weg in die industrielle Praxis
• Der größte kommerzielle Erfolg ist nicht gleich das beste technische Design
  • Beispiel: Nokia N95 vs. iPhone der ersten Generation

Gesetz 5 (Millers Gesetz) — Drei Punkte bestimmen eine Kurve

• "Three points determine a curve."
  • Drei Punkte bestimmen eine Kurve
• In Datensätzen findet man immer ein Muster
• Es muss geprüft werden, ob dieses Muster durch das tatsächlich untersuchte Phänomen verursacht wird oder nur durch Messrauschen
• Besonders in der Wissenschaft und bei Graduiertenstudierenden wird diese Regel oft ignoriert

Gesetz 6 (Mars Gesetz) — Vorsicht vor Overfitting von Daten

• "Everything is linear if plotted log-log with a fat magic marker."
  • In einem log-log-Diagramm sieht mit einem dicken Filzstift gezeichnet alles linear aus
• Biggs Gesetz: "Verlieb dich nicht in mathematische Werkzeuge; sie lieben dich nicht zurück"
• Kein Overfitting von Daten

Gesetz 7 — Führung und Teamzusammensetzung

• "At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it."
  • Zu Beginn eines Designprojekts ist die Person, die am stärksten Teamleitung werden will, am wenigsten wahrscheinlich dafür geeignet
• Der Dilbert-Comic basiert auf leicht überzeichneten Erfahrungen aus echten Engineering-Unternehmen
• Führung ist zum Teil angeboren, zu einem großen Teil muss sie aber erlernt werden
• Es gibt Manager, die die 'Grundlagen respektieren (respect the basics)' nicht beherrschen
  • Frag einen Wirtschaftsingenieur nach dem MBA

Gesetz 8 — Das Optimum liegt in der Mitte

• "In nature, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point."
  • In der Natur liegt das Optimum fast immer irgendwo in der Mitte; Behauptungen, das Optimum liege an einem Extrempunkt, sollte man misstrauen
• Standardbeispiel: Optimal power transfer
• Praxisbeispiel: optimaler Sensorwiderstand

Gesetz 9 — Fehlende Informationen sind keine Ausrede

• "Not having all the information you need is never a satisfactory excuse for not starting the analysis."
  • Nicht alle nötigen Informationen zu haben, ist nie eine zufriedenstellende Ausrede dafür, die Analyse nicht zu beginnen
• Für eine vollständigere Analyse muss man ermitteln, welche Werte benötigt werden

Gesetz 10 — Schätzen und Raten

• "When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along."
  • Im Zweifel schätzen; im Notfall raten. Aber wenn die echten Zahlen vorliegen, muss man unbedingt zurückgehen und das Durcheinander aufräumen
• Man wird zum Ingenieur ausgebildet, nicht zum Wahrsager
• In diesem Beruf ist gutes Denken wichtiger als schnelles Denken

Gesetz 11 — Von vorn anfangen

• "Sometimes, the fastest way to get to the end is to throw everything out and start over."
  • Manchmal ist der schnellste Weg zum Ziel, alles wegzuwerfen und von vorn zu beginnen
• Zu lernen, wann das nötig ist, braucht Zeit
• In vielen Branchen gab es zahlreiche Fälle, in denen man genau das hätte tun sollen, es aber nicht getan hat
  • Almaz, die russische bemannte Aufklärungs-Raumstation: technisch hervorragend ausgelegt, aber nach dem Start durch computergesteuerte Aufklärungssatelliten überholt
  • frühe 'Automobile'

Gesetz 12 — Es gibt keine einzige richtige Antwort

• "There is never a single right solution. There are always multiple wrong ones, though."
  • Es gibt nie nur eine einzige richtige Lösung, aber immer mehrere falsche
• Offen bleiben
• Ingenieurwesen ist keine Religion
  • Technical apostasy ist völlig erlaubt
• Beispiel: mechanische automatische Rechenverfahren
  • Im Zweiten Weltkrieg der Mainstream-Ansatz
  • Bis in die 1960er-Jahre dauerte es, bis digitale Hardware diesen Bereich dominierte

Gesetz 13 — Anforderungsbasiertes Design

• "Design is based on requirements. There's no justification for designing something one bit 'better' than the requirements dictate."
  • Design basiert auf Anforderungen; es gibt keine Rechtfertigung, etwas auch nur ein bisschen 'besser' zu entwerfen, als die Anforderungen vorgeben
• Kunden zahlen ungern für Funktionen, die sie nicht brauchen
• Man muss die für die Anwendung nötige Zuverlässigkeit bestimmen und dann auf genau dieses Zuverlässigkeitsniveau hin entwerfen
  • leicht gesagt, schwer umzusetzen

Gesetz 14 (Edisons Gesetz) — 'Besser' ist der Feind von 'gut'

• "„Besser“ ist der Feind von „gut“."
  • „Besser“ ist der Feind von „gut“
• Tatsächlich ein Zitat von Voltaire
• Man muss erkennen, wann ein System den Zustand gut genug (good enough) erreicht hat
  • Perfektion erfordert unendliche Ressourcen, daher kann ein System immer weiter verbessert werden
  • Siehe Gesetz 13

Gesetz 15 (Sheas Gesetz) — Schnittstellen sind entscheidend

• "The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up."
  • Die Möglichkeit, ein Design zu verbessern, entsteht hauptsächlich an den Schnittstellen; dort ist auch der wichtigste Ort, um es zu vermasseln
• Es gibt viele Ingenieure/Techniker, die ein einzelnes System wirklich gut verstehen
• Menschen, die mehrere unterschiedliche Systeme wirklich gut verstehen, sind selten
  • Beispiel: Systeme mit komplexen Hardware-Software-Interaktionen haben meist Probleme an den Schnittstellen

Gesetz 16 — Kein blindes Vertrauen in frühere Analysen

• "The previous people who did a similar analysis did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis over yours. There is especially no reason to present their analysis as yours."
  • Die früheren Personen, die eine ähnliche Analyse durchgeführt haben, hatten keinen direkten Draht zur Weisheit der Zeiten; daher gibt es keinen Grund, ihrer Analyse mehr zu glauben als der eigenen, und erst recht keinen Grund, ihre Analyse als die eigene auszugeben

Gesetz 17 — Die Genauigkeit von Veröffentlichungen

• "The fact that an analysis appears in print has no relationship to the likelihood of its being correct."
  • Die Tatsache, dass eine Analyse gedruckt erscheint, hat nichts mit der Wahrscheinlichkeit zu tun, dass sie korrekt ist
• Eine berühmte Meinung aus den 1970er Jahren:
  • „1200 baud ist wahrscheinlich die Höchstgeschwindigkeit, die ein Telefonmodem erreichen kann“
  • Bekannt durch die Aussage "Coding is dead"
  • Trellis coded modulation steigerte diese Geschwindigkeit bis in die 1990er Jahre auf 50kbps

Gesetz 18 — Die Doppelseitigkeit früherer Erfahrung

• "Past experience is excellent for providing a reality check. Too much reality can doom an otherwise worthwhile design, though."
  • Frühere Erfahrung ist hervorragend für einen Realitätscheck, doch zu viel Realität kann ein ansonsten lohnendes Design zunichtemachen

Gesetz 19 — Die Bedeutung von Demut

• "The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your terminal velocity is twice the speed of light, you may have invented warp drive, but the chances are a lot better that you've screwed up."
  • Die Chancen stehen sehr schlecht, dass du in diesem Bereich immens klüger bist als alle anderen. Wenn deine Analyse ergibt, dass deine Endgeschwindigkeit doppelt so hoch ist wie die Lichtgeschwindigkeit, hast du vielleicht den Warp-Antrieb erfunden — wahrscheinlicher ist aber, dass du einen Fehler gemacht hast

Gesetz 20 — Die Bedeutung der Präsentation

• "A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately."
  • Ein schlechtes Design mit einer guten Präsentation ist früher oder später zum Scheitern verurteilt. Ein gutes Design mit einer schlechten Präsentation ist sofort zum Scheitern verurteilt
• Beispiel: Avro C102 — das zweite kommerzielle Düsenflugzeug der Welt (mit 13 Tagen Abstand)
  • Wurde zur Unterstützung der Entwicklung des Avro Arrow eingestellt

Gesetz 21 — Das Wesen von Bildung

• "Half of everything you hear in a classroom is crap. Education is figuring out which half is which."
  • Die Hälfte von allem, was man im Unterricht hört, ist Mist; Bildung bedeutet herauszufinden, welche Hälfte welche ist
• Professoren versuchen nicht absichtlich, 50 % der Zeit zu verschwenden
  • In sich schnell verändernden und weiterentwickelnden Bereichen wird vermutet, welche Fähigkeiten gebraucht werden könnten
• Beispiel: Quantencomputing
  • Es könnte Wissen sein, das für die Arbeit als Ingenieur in den nächsten 20 Jahren unverzichtbar ist, oder bis in die 2030er Jahre nur von akademischem Interesse bleiben

Gesetz 22 — Die Bedeutung von Dokumentation

• "When in doubt, document. (Documentation requirements will reach a maximum shortly after the termination of a program.)"
  • Im Zweifel dokumentieren; die Anforderungen an die Dokumentation erreichen kurz nach dem Ende eines Programms ihren Höchststand
• Wenn man ein Problem nicht lösen kann, sollte man Unwissenheit nicht verbergen
  • Die Ursache des Problems dokumentieren
  • Jemand anderes findet möglicherweise einen Weg, das Problem zu lösen

Gesetz 23 — Die Fiktionalität von Zeitplänen

• "The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it."
  • Der Zeitplan, den du erstellst, wird wie reine Fiktion wirken — bis zu dem Zeitpunkt, an dem dein Kunde dich entlässt, weil du ihn nicht eingehalten hast

Gesetz 24 — Work Breakdown Structure

• "It's called a 'Work Breakdown Structure' because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it."
  • Es heißt „Work Breakdown Structure“, weil die verbleibende Arbeit immer weiter anwächst, bis du einen Breakdown hast, wenn du ihr keine Struktur gibst

Gesetz 25 (Bowdens Gesetz) — Analyse nach Testfehlschlägen

• "Following a testing failure, it's always possible to refine the analysis to show that you had negative margins all along."
  • Nach einem Testfehlschlag lässt sich die Analyse immer so verfeinern, dass sich zeigt, dass von Anfang an negative Margen vorlagen
• Beispiele: Unfallberichte des kanadischen Verkehrssicherheitsausschusses für Unfalluntersuchungen und der Federal Aviation Administration (FAA)
• Manche Fehlschläge entstehen durch mangelnde Vorstellungskraft (freie Wiedergabe von Frank Borman)
• Ingenieuren wird verziehen, wenn sie Fehler machen, aber Fehler zu verbergen ist unverzeihlich

Gesetz 26 (Montemerlos Gesetz) — Nichts Dummes tun

• "Don't do nuthin' dumb."
  • Mach nichts Dummes
• Eine Regel, die im Ingenieuralltag erstaunlich schwer einzuhalten ist
• Die Grundlagen nicht vergessen
• Die eigenen Prioritäten klar setzen

Gesetz 27 (Varsis Gesetz) — Zeitpläne bewegen sich nur in eine Richtung

• "Schedules only move in one direction."
  • Zeitpläne bewegen sich nur in eine Richtung
• Puffer für Probleme und Schwierigkeiten einplanen
  • Testfehlschläge
  • Später familiäre Notfälle
• Jemand anderes kann das benötigte Produkt verspätet liefern, ohne dass es deine Schuld ist
• Dir selbst und deinem Team immer zeitlichen Spielraum lassen

Gesetz 28 (Rangers Gesetz) — Es gibt keinen kostenlosen Start

• "There ain't no such thing as a free launch."
  • Einen kostenlosen Start gibt es nicht

Gesetz 29 (von Tiesenhausens Gesetz des Programmmanagements) — Kosten- und Zeitschätzung

• "To get an accurate estimate of final program requirements, multiply the initial time estimates by pi, and slide the decimal point on the cost estimates one place to the right."
  • Um eine genaue Schätzung der endgültigen Programmanforderungen zu erhalten, multipliziere die anfänglichen Zeitschätzungen mit π und verschiebe bei den Kostenschätzungen das Dezimalkomma um eine Stelle nach rechts

Gesetz 30 (von Tiesenhausens Gesetz des Engineering-Designs) — Der Einfluss des Artist’s Concept

• "If you want to have a maximum effect on the design of a new engineering system, learn to draw. Engineers always wind up designing the vehicle to look like the initial artist's concept."
  • Wenn du den größtmöglichen Einfluss auf das Design eines neuen Engineering-Systems haben willst, lerne zu zeichnen. Ingenieure entwerfen das Fahrzeug am Ende immer so, dass es wie das ursprüngliche Artist’s Concept aussieht.

Gesetz 31 (Mos Gesetz der evolutionären Entwicklung) — Grundlegende Grenzen der Technologie

• "You can't get to the moon by climbing successively taller trees."
  • Man kommt nicht zum Mond, indem man nacheinander immer höhere Bäume erklimmt.
• Es ist nützlich, die grundlegenden Grenzen einer Technologie bzw. eines Ansatzes zu verstehen

Gesetz 32 (Atkins Demo-Gesetz) — Murphys Gesetz

• "When the hardware is working perfectly, the really important visitors don't show up."
  • Wenn die Hardware perfekt funktioniert, tauchen die wirklich wichtigen Besucher nicht auf.

Gesetz 33 (Pattons Gesetz der Programmplanung) — Die Bedeutung der Umsetzung

• "A good plan violently executed now is better than a perfect plan next week."
  • Ein guter Plan, der jetzt mit Nachdruck umgesetzt wird, ist besser als ein perfekter Plan nächste Woche.
• Ein Fehler in der Industrie: auf die 'perfekte' Technologie zu warten
  • Währenddessen erobert die Konkurrenz den Markt.

Gesetz 34 (Roosevelts Gesetz der Aufgabenplanung) — Realistische Umsetzung

• "Do what you can, where you are, with what you have."
  • Tue, was du kannst, dort, wo du bist, mit dem, was du hast.
• Wenn man kein SF-Autor ist, ist es sinnlos, für eine Technologie zu entwerfen, die nicht existiert

Gesetz 35 (de Saint-Exupérys Design-Gesetz) — Perfektes Design

• "A designer knows that he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."
  • Ein Designer weiß, dass er Perfektion nicht dann erreicht hat, wenn es nichts mehr hinzuzufügen gibt, sondern wenn es nichts mehr wegzunehmen gibt.

Gesetz 36 — Eleganz, Effizienz und Wirksamkeit

• "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."
  • Jeder durchschnittliche Ingenieur kann etwas Elegantes entwerfen. Ein guter Ingenieur entwirft Systeme so, dass sie effizient sind. Ein großartiger Ingenieur entwirft sie so, dass sie wirksam sind.
• Elegantes Design (Elegant design): standardmäßiges städtisches Wasserversorgungssystem
• Effizientes Design (Efficient design): New Yorker Wasserversorgungssystem
• Wirksames Design (Effective design): Bewässerungssysteme indigener Zivilisationen in Nord- und Südamerika (einige sind seit mehr als 1000 Jahren in Betrieb)

Gesetz 37 (Henshaws Gesetz) — Klare Verantwortlichkeit

• "One key to success in a mission is establishing clear lines of blame."
  • Ein Schlüssel zum Erfolg einer Mission ist die Festlegung klarer Verantwortlichkeiten.
• Man muss Verantwortung für die eigenen Handlungen und Entscheidungen übernehmen
• Ingenieuren (oder irgendjemand anderem), die sich weigern, Verantwortung zu übernehmen, sollte man nicht vertrauen

Gesetz 38 — Fähigkeiten bestimmen Anforderungen

• "Capabilities drive requirements, regardless of what the systems engineering textbooks say."
  • Fähigkeiten bestimmen die Anforderungen, ganz gleich, was die Lehrbücher des Systems Engineering sagen.
• Entscheidend ist zu erkennen, welche neuen Fähigkeiten gerade entwickelt werden:
  • 1950er: Transistoren
  • 1960er: integrierte Schaltkreise
  • 1970er: Mikroprozessoren
  • 1980er: Heimcomputer
  • 1990er: Internet
  • 2000er: drahtloses/mobiles Computing

Gesetz 39 — Keine neuen Trägerraketen entwickeln

• Drei Schlüssel, um ein neues bemanntes Raumfahrtprogramm günstig und im Zeitplan zu halten:
  1. Keine neuen Trägerraketen
  2. Keine neuen Trägerraketen
  3. Unter keinen Umständen beschließen, neue Trägerraketen zu entwickeln
• Man muss der Versuchung widerstehen, zu glauben, dass ein vollständig neues Produkt immer besser sei als die Weiterentwicklung eines bestehenden Produkts.

Gesetz 40 — Das Weltall verzeiht nicht

• "Space is a completely unforgiving environment. If you screw up the engineering, somebody dies (and there's no partial credit because most of the analysis was right...)"
  • Das Weltall ist eine vollkommen gnadenlose Umgebung. Wenn man das Engineering verpfuscht, stirbt jemand (und es gibt keine Teilpunkte dafür, dass der Großteil der Analyse richtig war ...).
• Große technische Steuerungs-Katastrophen:
  • Fukushima, Tschernobyl
  • De Havilland Comet (der Grund, warum Fenster in Verkehrsflugzeugen abgerundete Ecken haben)
  • Eastern Airline Flight 401 (bei dem der Autopilot ein Verkehrsflugzeug in die Everglades steuerte)
  • Therac-25 (kanadisches Strahlentherapiegerät)
• Richard Feynman sinngemäß: "Nature cannot be fooled"