Und wenn er das Falsche bewegt, macht man das nicht mit einem Update rückgängig. Ein Motor hat die Bewegung schon ausgeführt, ein Teil hat sich schon verschoben, manchmal sitzt eine Person darauf.
Deshalb wird diese Software anders geschrieben. Und vor allem anders getestet.
Wo es kompliziert wird
Der Test
Um zu wissen, ob eine Logik funktioniert, braucht man das physische Teil, das sich bewegt, oder eine originalgetreue Simulation seines Verhaltens. Der Zyklus aus Schreiben, Testen, Korrigieren ist langsamer und teurer, und das muss bei der Zeitschätzung eingeplant werden.
Die Zeit
Eine Verzögerung, die auf einem Bildschirm niemand bemerken würde, wird hier zu einer Bewegung zur falschen Zeit. Die Toleranzen sind eng und lassen sich nicht mit mehr Rechenleistung ausgleichen: Man gleicht sie aus, indem man den Code anders schreibt.
Die Distanz
Es steht in einem Raum, einer Halle, auf einer Anlage. Es zu aktualisieren, zu verstehen, warum es gestoppt hat, und zu wissen, in welchem Zustand es ist, ohne persönlich hinzufahren, sind drei getrennte Probleme, und sie müssen gelöst sein, bevor man hundert davon installiert.
Die Grenze
Zwischen wer die Mechanik gebaut und wer die Software geschrieben hat, liegt eine Grauzone, in der Probleme hin- und hergeschoben werden. Man braucht jemanden, der beide Seiten gut genug lesen kann, um zu sagen, wo die Sache wirklich liegt, statt das eigene Stück zu verteidigen.
Das Feld
Ein misslungenes Update auf einem Gerät, das zweihundert Kilometer entfernt steht, macht sich nicht mit einem Tastendruck rückgängig. Jede Änderung muss geplant werden im Wissen, dass ein Rollback eine Fahrt kostet.
Vorher
Simulatoren, installiert in öffentlich zugänglichen Räumen: Kabinen, die sich auf Aktuatoren bewegen, Bedienelemente, die sofort reagieren müssen, und eine Raumverwaltung, die ohne anwesenden Techniker funktionieren muss.
Nachher
Die Software der Platinen, die die Motoren steuern, die Interfaces für die Nutzer der Maschine, und das System, das den Raum verwaltet.
Warum es zählt
Wer Maschinen baut, hat Ingenieure, die alles über die Mechanik wissen. Softwarehäuser können Anwendungen bauen. Dazwischen liegt die Codezeile, die einen Befehl in eine Bewegung übersetzt, und das ist bei keinem der beiden das volle Metier.
Das ist der Punkt, an dem Projekte stecken bleiben: nicht weil die Kompetenz fehlt, sondern weil diese Kompetenz auf zwei Anbieter aufgeteilt ist, die sich das Problem gegenseitig zuschieben.
Wir bauen nicht die Maschine.
Wir bauen den Teil, der sie bewegt.
Das ist nicht die richtige Seite, wenn
Die Welt der Industriesteuerungen hat eigene Technologien, Normen und Zertifizierungen, und das ist nicht unser Metier. Wenn das, was du brauchst, in einer Produktionslinie mit zertifizierten Sicherheitsanforderungen lebt, brauchst du jemand anderen — und das lohnt sich, jetzt zu wissen.
Wir arbeiten an universell einsetzbaren programmierbaren Platinen: solchen, die einen Motor steuern, einen Sensor auslesen, eine Schranke öffnen, mit einem Server sprechen.
Wenn der Software-Teil noch nicht existiert, fängt man damit an zu verstehen, was wirklich gebraucht wird und was es kostet — Build Plan. Wenn er existiert, nur halb funktioniert, und niemand sagen kann, wessen Problem es ist, ist die Tür Rescue.
Wenn du dagegen schon weißt, was zu tun ist, und sehen willst, wie wir arbeiten, bevor du dich bindest, gibt es den Dry Run: zwei Wochen, und dann ist Schluss.