„It’s a bug, dude!“ Diese Notiz, festgehalten auf einem Post-it-Zettel, klebte einige Zeit am Computerbildschirm von Wolfgang Engelhard. Der Grund für diese Notiz an seinem Arbeitsplatz sei ein Rüffel seines Chefs gewesen, wie er mit einem Schmunzeln erzählt. Und diesen wiederum habe er erhalten, weil er ganz zu Beginn seiner Laufbahn als Functional Safety Engineer bei Embedded Office, einer Hightech-Software-Schmiede für Embedded-Systeme, etwas nicht gemäß den im Safety-Bereich vorgeschriebenen Prozessen entwickelt hatte. Als der 37-jährige Engelhard bemerkt, dass sich der Autorin dieses Artikels der inhaltliche Sinn dieser Notiz nicht auf Anhieb erschließt, liefert er gleich die Erklärung hinterher: „Wenn man bei Software-Entwicklungen im sicherheitskritischen Bereich etwas ändert, fängt das immer mit einem Bug an. Das heißt, man schreibt einen Problembericht – wir bei Embedded Office sagen ‚Bug‘ dazu –, in dem ein aufgetretener Fehler beschrieben wird. Ist dieser behoben, vermerkt man in einem Dokument in der Revision-Historie, dass der jeweilige Bug in die aktuelle Version eingearbeitet wurde.“
Arbeiten nach dem V-Modell
Nach diesem erklärenden Ausflug in das Berufsumfeld des Wolfgang Engelhard ist man auch schon mittendrin in seiner Arbeitswelt: Bei seinem Arbeitgeber Embedded Office ist er dafür zuständig, sicherheitskritische Software zu entwickeln. Diese muss nach Abschluss der Entwicklung auch entsprechend zertifiziert werden – und für diesen Zertifizierungsprozess schreibt er die nötigen Dokumente. Um seine Arbeit noch etwas zu konkretisieren – erläutert er, dass die Entwicklungen im sicherheitskritischen Bereich nach dem so genannten V-Modell erfolgen. Dabei handelt es sich um ein Vorgehensmodell in der Softwareentwicklung, bei dem der Softwareentwurfsprozess in Phasen organisiert wird. Neben diesen Entwicklungsphasen definiert das V-Modell auch das Vorgehen zur Qualitätssicherung, dem Testen, phasenweise. „Ich bin mit meiner Arbeit vor allem im Vorwärtszweig unterwegs und kümmere mich um Planungsdokumente oder Dokumente, in denen die Requirements an die Software beschrieben sind. Sind diese fertig erstellt, mache ich im weiteren Ablauf des V-Modells dann noch deren Reviews.“ Während der gesamten Zeit, die ein Software-Projekt das V-Modell durchläuft, hält Wolfgang Engelhard Rücksprache mit dem TÜV. Am Ende werden dann die Arbeitsergebnisse komplett vorgelegt – und wenn alles in Ordnung ist, erhält die Software die Vorzertifizierung, die bescheinigt, dass sie im sicherheitskritischen Bereich eingesetzt werden kann.
Dokumentationen anzufertigen ist also momentan seine tägliche Arbeit – die ihn jedes Mal aufs Neue fordert, wie er erzählt: „Software-Entwicklung ist das, was ich gerne mache und was mir leicht fällt. Den ganzen Tag Dokumentationen im Rahmen von Zertifizierungsprojekten zu schreiben ist da schon anspruchsvoller. Da brummt einem am Abend schon ganz schön der Schädel.“ An der Entwicklung von Software schätzt Wolfgang Engelhard, dass „man unmittelbar Feedback bekommt, ob die Arbeit gut ist oder nicht. So gibt zum Beispiel der Compiler ehrlich und ohne Interpretationsspielraum Rückmeldung, ob etwas funktioniert oder nicht.“ Bei Zertifizierungsprojekten, die in der Regel über mehr als ein Jahr laufen, müsse man bis zum Ende des Projekts auf Feedback von der Zertifizierungsstelle warten, die entweder – im positiven Fall – das Zertifikat ausstelle oder Nachbearbeitungen einfordere. „Hier stellt sich dann natürlich Spaß an der Arbeit ein, wenn man nach langer Vorarbeit endlich das Zertifikat in der Hand hält.“ Darüber hinaus macht ihm Freude bei seiner Tätigkeit bei Embedded Office, dass hier Teamarbeit ein wesentlicher Bestandteil des täglichen Schaffens ist, der auch intensiv gelebt wird.
Eine Portion Pessimismus gehört dazu
Nach speziellen Voraussetzungen gefragt, die für Wolfgang Engelhards Tätigkeit als Safety Engineer unabdingbar sind, erwähnt er als Erstes, dass Sinn für Qualität sowie Akribie bei der Arbeit wichtig sind. Auch müsse man sich der großen Verantwortung bewusst sein, wenn man Software für ein sicherheitskritisches Umfeld entwirft. „Man muss seine Arbeit nach bestem Wissen und Gewissen machen. Denn wenn ich im Safety-Bereich grob fahrlässig arbeite, gefährde ich schnell Menschenleben.“ Aber auch eine gewisse Portion Pessimismus müsse er an den Tag legen. So „sollte ein Safety Engineer immer im Hinterkopf haben, was alles schief gehen kann. Und daran muss er bei seinen Entwicklungen stets denken – damit am Ende alles glatt läuft.“ Und last but not least seien für eine Position, die Wolfgang Engelhard im Moment inne hat, langjährige Erfahrungen im Safety-Bereich und entsprechende Fortbildungen wichtige Voraussetzungen. Und deswegen hat er, kurz nachdem er bei Embedded Office eingestiegen ist, in Köln einen einwöchigen Trainingskurs beim TÜV Rheinland absolviert und diesen mit der Prüfung zum Functional Safety Engineer abgelegt. Sein Chef hat ihn für diese Weiterbildung abgestellt, da man im Unternehmen jemanden haben wollte, der im Safety-Bereich qualifiziert ist, um so das Echtzeitbetriebssystem der Firma ordnungsgemäß nach IEC 61508 vorzertifizieren lassen zu können.
Wie aus den Erzählungen von Wolfgang Engelhard hervorgeht, ist die Entwicklung von Software eines seiner Steckenpferde. Und dafür zuständig war er auch bei seinem ersten Vollzeitjob nach Abschluss des Fachhochschul-Studiums der Elektro- und Informationstechnik. Die Möglichkeit, sich bei seinem ersten Arbeitgeber, einer Firma für System Engineering, Software und technische Logistik, zu bewerben, zeigte ihm einer der Betreuer seiner Diplomarbeit auf, die er bei EADS in Manching schrieb. Die Arbeit befasste sich mit einem rechnergestützten Dokumentationssystem zur Erfassung von Schäden an Strukturkomponenten, das dann beim Eurofighter-Projekt bei EADS zum Einsatz kommen sollte. „Bei der Firma für System- und Softwareentwicklung habe ich in der Hauptsache Softwareentwicklung gemacht.“ Auch für einen europäischen Flugzeugbauer hat er Softwareprojekte umgesetzt und ist dabei zum ersten Mal mit Normen und dem Thema Safety in Berührung gekommen – und zwar mit der Norm DO-178B, ein Standard zur Softwareentwicklung im sicherheitskritischen Bereich der Luftfahrt.
Zeit für neue Herausforderungen
Auf seiner ersten Stelle blieb er insgesamt sechs Jahre. Dann war es für ihn an der Zeit, sich einer neuen Herausforderung zu stellen. Als Begründung für den Wechselwillen nennt er, dass seine künftigen Aufgaben rein softwarebezogen gewesen wären und die Hardwareseite ganz hinten runter gefallen wäre. „Das hat mich dann nicht mehr so gereizt.“ Und so nahm er den Besuch der Fachmesse Embedded World 2010 zum Anlass, potenzielle neue Arbeitgeber unter die Lupe zu nehmen. Auf der Messe sprach er mit dem Geschäftsführer von Embedded Office und nicht ganz ein halbes Jahr später fand dann dort ein Bewerbungsgespräch statt – mit einem für ihn positiven Endergebnis: einem Arbeitsvertrag bei Embedded Office. „Hier gab es einfach den Vorteil, dass man es bei seiner Arbeit auch mit Mikrocontrollerboards zu tun hat.“ Nun kam in Wolfgang Engelhards Berufsleben endlich die Hardware wieder zurück ins Spiel.
Dass er es in seinem Beruf täglich mit anspruchsvoller Technik zu tun hat, ist für ihn kein Hinderungsgrund, sich auch hobbymäßig damit zu beschäftigen: In seiner freien Zeit bastelt er an einem Cockpit für eine Flugsimulation für einen F16-Kampfjet. 1999 hat er seine erste Cockpit-Version gebaut: „Ein etwas unförmiger Stuhl mit Schubhebel, Joystick, Kippschaltern und Monitor.“ Seit nunmehr acht Jahren feilt er an der zweiten Version. Man sieht also: Wolfgang Engelhard braucht zu seinem technisch geprägten Beruf keinen anders gelagerten Ausgleich in der Freizeit.
