Also, für größere Kinder und junggebliebene Erwachsene gibt es das Hobby des Modellbaus. Wie bei den meisten Hobbies läßt sich damit kaum Geld verdienen, aber eine ganze Industrie lebt davon. Im Modellbau gibt es im Wesentlichen drei Ansätze:
a) Bausätze.
b) passende Materialien schneiden, kleben, schrauben, löten.
c) Bausteine.
Was gibt es zu tun und warum machen wir das eine und nicht das andere?
a) Generell als Modellbau etabliert ist das Zusamenfügen von industriell vorgefertigten Bausätzen. Dies ist für wenig phantasiebegabte Hobbyisten die sichere Lösung für ein realitätsnahes Modell. In der bildgebenden Kunst gibt es eine ähnliche Technologie, das sogenannte "Malen nach Zahlen".
b) Womit wir zur zweiten Fraktion der Modellbauer kommen. Fortgeschrittene Hobbyisten sägen in liebevoller Handarbeit aus Holz, Pappe, Kunststoff, Metall, und weiteren geeeigneten Materialien ihre eigenen Bauteile aus, die zusammengefügt, geklebt oder geschraubt, ein optisch nahe der Wirklichkeit entsprechendes Modell ergeben.
c) Bausteinsysteme sind wesentlich einfacher in der Handhabung als b), und wir finden sie in jedem Spielzeuggeschäft! Populäre Marken sind aus Plastik, daneben gibt es Metallbaukästen. Je nach Interesse und Fähigkeiten läßt sich damit sehr schön spielen und es kommen oft überraschende Gebilde dabei heraus. Für eine "ernsthafte" Modellierung wie zum Beispiel eine Modelleisenbahn taugen die meisten Bausteinsysteme wenig, denn die sich ergebenden Automobile und Häuser sind wenig realitätsnah. Wenn es dagegen um Kräne, Fabrikanlagen oder moderne Architektur geht, trumpfen einige Systembaukästen so richtig auf.
Die geneigten Leser werden schon wissen worauf ich hinaus will, denn unsere Embedded Software muss ja irgendwie auf die Beine kommen und ein Produkt zum Leben erwecken. Dies soll natürlich nichts kosten, darf keine Fehler haben und muss sofort verfügbar sein.
Wie würden unsere Modellbauer dies anstellen?
Für eine wirklichkeitsgetreue Kopie ist sicher Ansatz a) der beste, weil alle Teile vorfabriziert sind. Leider können unsere Modellbauer mit einem bestimmten Bausatz auch nur immer ein und das selbe Produkt nachbauen. Hier gibt es keine wirkliche Möglichkeit für Innovation oder tiefgreifende Veränderungen. Aus einem Flugzeugbausatz kann man kein Auto bauen, und schon gar kein Haus.
Wenn unser embedded Modellbauer ein Haus bauen sollen, greifen die meisten zur Methode b) denn mit etwas handwerklichem Geschick kann man alle Arten Häuser nachbauen, und auch reale Häuser entstehen ja meist in Handarbeit.
Wenn es aber darum geht eine Maschine zu bauen, womöglich noch eine neue Maschine, die etwas anders funktioniert und wo man sich noch nicht recht im Klaren ist wie diese Maschine denn genau funktionieren soll, werden unsere Modellbauer zur Methode c) greifen. Nur die Virtuosen mit ausserordentlichem Geschick bringen auch in Handarbeit zierliche Maschinchen zum Laufen, reagieren aber meist mit Schulterzucken, wenn denn etwas zu ändern sei.
Bei den Bausteine-Modellbauern hängt die Art der Bausteine von der Art des Modells ab. Dies ist schon der Einstieg in die Domänenspezifische Modellierung. Autos, Flugzeuge und Häuser lassen sich gut mit Lego bauen. Türme, Brücken und Maschinen dagegen besser mit Fischertechnik. Die eine Art Bausteine legt mehr Wert auf Äusseres, die andere Art konzentriert sich auf funktionelle Aspekte. Softwaretechnisch könnte man sagen: Lego hat ein ansprechendes GUI, während Fischertechnik die Universalität der "C" Sprache mit sich bringt.
Nun wissen wir alle, dass in der "C" Sprache viel Unsinn angestellt werden kann, weshalb man diese Sprache nicht mit der Methode b) kombinieren sollte, denn handwerklich weniger talentierte Softwerker verlieren sehr viel Zeit (und der Firma Geld ..) dabei, ihr aus "C" zusammengekleistertes Haus mit einem wasserdichten Dach und einer schließenden Tür zu versehen. Dabei sind innere Details wie Wände an denen der Putz nicht hält, und Fußböden mit Löchern zum Glück von aussen nicht sichtbar, aber so sieht es erschreckend häufig in ausgelieferter Software aus - das Produkt funktioniert doch!
In Software soll man zwar nicht wohnen, aber so ganz wohl ist einem nicht wenn solche Software in Autos verbaut wird - womöglich noch in sicherheitsrelevante Airbags oder Stabilitätsprogramme. Wie funktioniert der sichere Hausbau in der Wirklichkeit? Jeder Häuslebauer kann ein Lied von schlampigen Handwerkern und billigen Baumaterialien singen, die Abhilfe liegt auf der Hand: Häufige Inspektionen und Gedanken in bessere Materialien und Werkzeuge investieren.
Übersetzt in die Sprache des Softwareprojektes heisst dies zum Beispiel: Regelmäßige Reviews, talentierte und erfahrene Ingenieure - ob für Requirements, Programmierung, oder Testen - anheuern, und einen stabilen Compiler einsetzen. Schön gesagt, aber all dies kostet Zeit und Geld, die in vielen Projekten (zu) knapp bemessen sind - oder wenn man sie denn hätte, würde mit dem Endprodukt kein Geld mehr verdient, sagt das höhere Management.
Häufig ist das zu entwickelnde Endprodukt nur eine Variante oder Verbesserung des vorherigen Produktes. Viele Projekte werden den original Vorgänger-Code übernehmen und ein wenig den neuen Anforderungen anpassen. Dies geht im Allgemeinen über 1..2 Generationen gut, und nur Firmen mit einer guten Personalpolitik schaffen auch die dritte Generation, denn mit jeder Übernahme in ein neues Projekt wachsen die Fehler exponentiell an.
Eine bessere Strategie für eine im wesentlichen gleiche Produktfamilie ist die Platformentwicklung. Hier werden sichere zentrale Bausteine als Fundament hergenommen, um eine kundenspezifische Lösung aufzubauen. Eine weitere Ausbaustufe dieses Prinzips sind dann sicher kombinierbare Softwaremodule die nur noch konfiguriert werden müssen, um die speziell gesuchte Lösung in einer bestimmten Domäne auszubilden.
Ein Beispiel ist die Steuerung des Einspritzvorgangs für Verbrennungsmotoren in Automobilen. Motoren haben zwischen 1 und 12 Zylindern, drehen mit einigen hundert bis einigen tausend Umdrehungen pro Minute, arbeiten auf verschiedene Getriebe, mit verschieden Lasten, aber im Grunde geschieht immer dasselbe: Kraftstoff wird über steuerbare Ventile eingespritzt und verbrannt. Über die Anzahl und zeitliche Abfolge dieser Einspritzungen wird die Verbrennung gesteuert, und Anforderungen wie Laufruhe, Abgasreinheit und natürlich Drehmoment direkt beieinflusst. Es liegt auf der Hand für solche sich zyklisch wiederholenden Vorgänge einmal die optimale Standardlösung auszuarbeiten, und diese dann nur noch auf eine konkrete Anwendung hin anzupassen. Gerade bei der Motorsteuerung gibt es aber eine Vielzahl Parameter die teilweise sich widersprechenden Anforderungen gerecht werden müssen.
Einfacher sind die Verhältnisse in einem Body-Controller, der im Wesentlichen die Beleuchtung am und im Auto steuert sowie Türen und Fenster überwacht.
Da sich die Bedienelemente der verschiedenen Automobilmarken immer mehr annähern - Blinker geht über einen Hebel, manchmal links, manchmal rechts vom Lenkrad, aber es ist immer ein Hebel, kein Drehknopf, kein Schieber - bietet sich für Steuergeräte und Hardware ein Standard an, mit dem nur noch konfiguriert wird, ob der Blinker links oder rechts vom Lenkrad sitzt.
Und damit endet mein Ausflug in die Automobilindustrie heute, schreiben Sie mir doch ein paar Worte und ich erzähle wie es weiter geht.
