Die Anforderungen des Marktes sind so vielfältig wie die Märkte selbst. Verlangt werden individuell zugeschnittene Maschinen mit großer Komplexität, Flexibilität und Optionsvielfalt. Weiter sollen sie in Produktionszellen, -linien oder Gesamtanlagen integrierbar, kurzfristig verfügbar, energieeffizient, ergonomisch und schnell einsetzbar sein. Gefordert wird der Preis und die Stabilität eines Großserienproduktes, wobei die Maschinen allen Normen und Dokumentationsvorschriften entsprechen müssen. Zustandsüberwachung, Diagnosetools zur Wartungsunterstützung und vorausschauende, intuitive Benutzerführung sind gefragter denn je. Nicht zuletzt möchten Käufer später durch Nach- oder Umrüsten und eigene Eingriffe auf Bedarfsveränderungen reagieren können. All diese Funktionen und Fähigkeiten müssen konstruiert und programmiert werden. Im Maschinen- und Anlagenbau nimmt die Software daher einen immer größeren Anteil ein.
Aufgaben verteilen
In der mechanischen Konstruktion ist es seit Generationen üblich, Aufgaben auf mehrere Köpfe zu verteilen. Dazu müssen zwei Voraussetzungen erfüllt sein: Erstens eine gute interne Projektkoordination inklusive einer sinnvollen Aufteilung der Teilaufgaben und zweitens eine Entwicklungsumgebung, die paralleles Arbeiten an gemeinsamen Projekten bestmöglich unterstützt. Das Erste ist eine organisatorische Aufgabe. Jeder Softwareentwickler benötigt zunächst einen Rahmen, innerhalb dessen er sich entfalten kann. Dieser entsteht aus dem Konzept der Gesamtmaschine und enthält eine funktionale Definition der einzelnen Maschinenteile oder -module, die in beliebiger hierarchischer Tiefe untergliedert sein können. Die Schnittstellen zwischen den Modulen werden analog zu den Anschlüssen bei mechanischen Einheiten festgelegt. Viele funktionale Teile enthalten mehrere oder alle Automatisierungsaspekte. Entwicklungsleiter müssen die Aufgaben daher äquivalent zu den Einheiten der Gesamtmaschine oder nach automatisierungstechnischen Fachkriterien aufteilen. Es hat sich bewährt, beides zu tun. So ergeben sich Programmfunktionen als wiederverwendbare Module für alle Beteiligten und zugleich Teilprogramme für funktionale Einheiten aus einer Hand.
Modularisierung auf übergeordneter Ebene
Mit der im Frühjahr 2013 erstmals ausgelieferten, vierten Generation der B&R-Entwicklungsumgebung erreichte die parallele Softwareentwicklung im Team ein neues Niveau. Schon bisher war es möglich einen einmal erstellten Automatisierungscode auf Basis von Bibliotheken beliebig wiederzuverwenden und so die zunehmende Komplexität funktionaler Abläufe, das Steuerungsverhalten ganzer Maschinen und Regelungsalgorithmen beherrschbar zu machen. Häufig verwendete Grundfunktionalitäten waren in diesen Bibliotheken bereits verwendungsfertig enthalten und brauchten nur noch konfiguriert werden. Selbst entwickelte Funktionen konnten dem Katalog zur weiteren Verwendung hinzugefügt werden. So entstand analog zur Mechanik ein System von Software-Normteilen. Diese gesamten Funktionen sind auch in der neuen Version 4 von Automation Studio erhalten geblieben. Die bahnbrechende Neuerung ist jedoch die Modularisierung auf einer höheren Ebene. Diese erfolgt durch autonom lauffähige Applikationsmodule, die beinahe beliebig skalierbar sind und daher einzelne Funktionen, wie ganze Maschinenteile oder Teilmaschinen, repräsentieren. Das lässt modulare Maschinenkonzepte leichter abbilden und die Entwicklungsaufgaben auf mehrere Entwickler verteilen, die nicht notwendigerweise im selben Haus sitzen müssen. So können ohne großen Aufwand ganze Maschinenmodule, inklusive der zugehörigen Software von Spezialunternehmen zugekauft, externe Automatisierungsdienstleister einbezogen oder gewisse Teile vom Kunden selbst programmiert werden.
Entwicklungsaufgaben verteilen
Die parallele Entwicklung basiert auf dem Projektrahmen. Dieser legt die Konfiguration des Gesamtwerks fest und definiert die anzusprechende Hardware, Task-Klassen und die vereinbarten Schnittstellen. Die hierarchisch aufgeteilten Applikationsmodule können aus einzelnen Funktionsblöcken, ganzen Programmen oder einer beliebigen Mischung bestehen. Deshalb können funktional unterschiedliche Teilprogramme auf die jeweiligen Spezialisten und große Einzelaufgaben auf mehrere Entwickler verteilt werden. Die Beteiligten haben die Möglichkeit ihren individuellen Erfahrungsschatz einzubringen. Solange die Schnittstellendefinition eingehalten wird, funktioniert das Gesamtsystem, auch wenn ein Applikationsmodul mit unterschiedlichen Sprachen programmiert wird. So kann bewährte Funktionalität in Form bestehender Softwareteile weiter verwendet werden. Zur Erstellung von Applikationsmodulen stehen etwa für die Ansteuerung von Antriebsachsen vorgefertigte Bibliotheken und Funktionsmodule zur Verfügung. Um Schnittstellen für den Datenaustausch festzulegen, werden Prozessvariablen mit Namen, Semantik und Typ definiert, die den logischen Ein- und Ausgängen der jeweiligen Applikationsmodule zugeordnet werden. Auf Basis dieses Mappings kann die Software entwickelt werden. Dazu benötigt der Entwickler weder genauere Informationen über die interne Funktionsweise anderer Softwareteile, noch müssen diese selbst zur Verfügung stehen. Jedes Applikationsmodul kann, auch wenn angrenzende Softwareteile noch nicht vorliegen, ausführlich getestet werden. Auf diese Weise lassen sich viele Fehlerquellen bereits frühzeitig ausschließen und abschließende Tests hinsichtlich Zusammenstellung stark abkürzen. Der Zertifizierungsaufwand verringert sich, wenn Applikationsmodule, die bereits einmal zertifiziert wurden, wiederverwendet werden.
