Mehr Transparenz in der Software-Entwicklung

Im Titelbeitrag wird die Softwareentwicklung als nur schwer greif­bares und steuerbares Projekt beschrieben, also ohne klassische Kontrollmechanismen. Woran liegt das?

"Software wird zum Entscheidungs­kriterium." Jens Dreyer (rechts)Redaktion IEE/Renate Schildheuer

Andreas Deuter: Es gibt nicht diesen einen Grund. Aus meiner beruflichen Erfahrung heraus als Entwicklungsleiter für Automatisierungs-Software ist es so, dass die Entwicklung in vielen Unternehmen, auch bei Phoenix Contact, im Komponentengeschäft begann. Hier gibt es hardware-orientierte Entwicklungsstrukturen und Fertigungsabläufe.

Das Thema Software hat in den letzten 20 Jahren über die Automatisierungstechnik in den Unternehmen zwar an Bedeutung gewonnen. Es wurde allerdings nicht systematisch etwa mit IT-Strukturen aufgesetzt, sondern ist mit der steigenden Intelligenz in den Feldgeräten nach und nach gewachsen. Anfangs gab es einen ersten Prozessor in einem Gerät, der von einem Entwickler mal eben programmiert wurde. Aus diesen kleinen Zellen heraus hat das Thema an Bedeutung gewonnen. Dadurch fehlt vielleicht auch noch heute die vollständige Management-Attention, unter anderem weil es schwierig ist, greif- und begreifbar zu machen, was Software tatsächlich darstellt.

Daher rührt auch die einseitige Kostenkalkulation von Geräten und Komponenten. Software wird bei der Kostenrechnung derzeit noch als Bestandteil der Gemeinkosten eines Unternehmens betrachtet und nicht seiner Bedeutung, also seiner Wertschöpfung und des Aufwands entsprechend separat. Das Stück Software eines Geräts wird aktuell nicht bepreist.

Also auch nicht bei der Kostenkalkulation einer Steuerung?

Andreas Deuter: In die Entwicklungskosten fließt die Software natürlich ein. Jedoch nur Software von extern, für die wir Lizenzgebühren zahlen, hat als ‚Stück Software‘ einen Preis, den wir dem Produkt zuordnen können. In der Kalkulation der Herstellkosten sieht es im Moment oft so aus, dass die im eigenen Haus entwickelte Software in der Regel keinen Preis hat.

Jens Dreyer: Diese Entstehungskosten gehen meistens in den Gemeinkosten auf, die auf die Hardware umgelegt, die Software-Entwicklung finanziert. Alles andere wird zu Beginn eines Projekts nicht betrachtet. Das funktioniert, so lange der Produktivitäts- oder Kostenanteil der Software am gesamten Produkt ­relativ gering ist.

Andreas Deuter: Aber es zeichnet sich in den letzten Jahren eine immer stärkere Verschiebung in Richtung Software ab, die immer mehr Aufwand verursacht – und damit Kosten.

Wie schätzen Sie für Phoenix Contact-Produkte diese Gewichtung ein?

Jens Dreyer: Bei einer Steuerung beispielsweise hat die Software mehrere Aspekte: Zum einen hat jede Steuerung ihre Firmware und zum anderen ist eine Programmier-Software fürs Engineering notwendig, mit der ich die Steuerung erst nutzen kann. In Summe kann der Software daher ein hoher zweistelliger Prozentwert der Gesamtfunktionalität zugeordnet werden.

Andreas Deuter: Hinzu kommt, dass die Innovationskraft vieler Produkte heute in der Software steckt – bei einer SPS nahezu ausschließlich. Sicher, über den Lebenszyklus von zehn bis 15 Jahren gibt es immer wieder Hardware-Anpassungen – etwa getriggert durch Bauteilabkündigungen. Produkt-Weiterentwicklungen, etwa die Implementierung einer neuen Profinet-Version, OPC UA oder verbesserte Diagnosemöglichkeiten, all diese Innovationen laufen größtenteils über Software ab. Daran sieht man die steigende Bedeutung des Themas.

Jens Dreyer: Das kann ich bestätigen. Auf der letzten Hannover Messe kam ein potenzieller Kunde auf mich zu und meinte: Zeigen Sie mir mal ihre Engineeringsoftware, ich suche eine neue Steuerung. Er wollte die Hardware gar nicht sehen, weil die seiner Meinung nach bis auf Farbe und Form doch ziemlich identisch wäre. Ihm ging es im Wesentlichen darum, wie viel Aufwand seine Software-Ingenieure haben, um das Projekt zu erstellen. Wenn ihm die Entwicklungsumgebung ermöglicht 30 % zu sparen, dann sei die Steuerung für ihn interessant. Das Beispiel zeigt den Wandel: Software wird zum Entscheidungskriterium.

Aber woran lässt sich denn die Verbesserung durch einen Software-Wechsel festmachen?

"Die Innovationskraft liegt in der Software." Andreas Deuter (links)Redaktion IEE/Renate Schildheuer

Andreas Deuter: Das betrifft nicht nur unsere Kunden. Wir betrachten unsere eigene Software-Entwicklung und versuchen uns ständig zu verbessern. Unsere Entwickler beschäftigen sich ja auch damit, welches Engineering-System ist das Beste, bringt ein Wechsel von C++ auf C# Vorteile? Würde eine integrierte Codeanalyse die Qualität weiter steigern? Hier kommt genau das Thema Greifbarkeit, Messbarkeit auf. Was ist eine Verbesserung? Das können wir gar nicht so richtig fassen, noch nicht.

Jens Dreyer: Gerade hinsichtlich objektiver Messungen von Verbesserungen haben wir gemerkt: da gibt es noch Lücken. Wir und viele Andere können nicht wirklich nachweisen, dass sich durch konkrete Maßnahmen die Fehlerquote in der Entwicklung erheblich reduziert hat oder dass unsere Entwickler viel mehr Funktionen innerhalb der gleichen Zeit oder mit dem gleichen Aufwand schaffen. Diese Messbarkeit fehlt.

Andreas Deuter: An solchen Konzepten arbeiten wir im Moment und haben Ansätze aus der klassischen Software-Industrie analysiert. So entstand das Grobkonzept für ein Verfahren, mit dem wir Software-Entwicklung greifbar machen können, und das wir natürlich auch evaluieren wollen.

Wie hilft das Konzept ihren Kunden?

Jens Dreyer: Den Gedankengang kann man auf unsere Kunden übertragen, die unsere Entwicklungsumgebung nutzen. Auch die Entwickler im Maschinen- und Anlagenbau programmieren und haben die gleichen Probleme, die Effizienz zu messen, zu kon­trollieren und – das ist das Ziel – natürlich zu steigern. Ich sehe hier eine Analogie, und die Möglichkeit, von unserem Verfahren später einmal zu profitieren.

Wie messen Sie jetzt konkret die Effizienz bei der Programmierung? Sie sagten ja gerade, Sie sind am Implementieren und Evaluieren.

Andreas Deuter: Zunächst müssen wir die Daten, die wir in der Software-Entwicklung generieren, überhaupt erst mal abgreifbar haben. Frühere Audits durch externe Gutachter hinsichtlich Prozessqualität haben beispielsweise ergeben, dass unsere Daten in fünf verschiedenen Töpfen liegen. Die Anforderungen liegen dort, der Quelltext hier, die Testdaten in einer weiteren Datenbank. Und die Fehler werden in einem ganz anderen System reportet. Kurzum: Die Daten, die wir für eine Messung brauchen, waren überhaupt nicht konsistent abgelegt.

Jens Dreyer: Daraus haben wir Schritt eins abgeleitet: Alle Daten, die in der Software-Entwicklung anfallen, wollten wir in einer einzigen Datenbank haben, einem Application Lifecycle Management. Mittlerweile arbeiten alle unsere Entwickler, Tester und auch die Marketingkollegen mit diesem System, sodass wir sämtliche Daten zur Verfügung haben.

Ist damit die Messbarkeit erreicht?

Software wird zum Entscheidungs­kriterium.Redaktion IEE/Renate Schildheuer

Andreas Deuter: Die Grundlagen stehen. Wir haben ein erstes Reportingtool testhalber geschrieben, das analysiert, wie viele Software-Artefakte geschaffen wurden. Wie viel Code ist erstellt worden? Wie viele Testfälle bearbeiten wir denn überhaupt? Wie viele Fehler laufen während der Entwicklung auf oder wie viele Fehler kommen nach einem Release zurück?

Diese ersten Auswertungen geben uns ein gutes Gefühl, dass wir valide Daten bekommen. Jetzt müssen wir das Ganze natürlich auch auf Belastbarkeit prüfen und die Daten über eine gewisse Zeit auf Konsistenz und auch Korrektheit kontrollieren. Hier sind wir aus meiner Sicht auf einem sehr guten Weg zu sagen, wir können messen.

Braucht es diese Funktionen nicht auch im klassischen SPS-Programmiersystem?

Andreas Deuter: Das ist eine meiner aktuellen Aufgaben, den Software-Entwicklungsprozess, wie wir ihn jetzt in der Produktentwicklung leben, auch in den Applikations-Software-Teams einzuführen, mit denen wir unser Lösungsgeschäft vorantreiben. Die Programmierer, die PC-Worx-Programme erstellen, arbeiten mittlerweile mit demselben Lifecycle-Management-System wie unsere Software-Entwickler. Stand heute. Aber warum nicht einzelne Aspekte des Lifecycle Managements direkt in das Engineering-System integrieren?

Wenn man den Begriff Engineering weiter fasst, kommen noch mal ganz andere Baustellen und Schnittstellen hinzu, gerade in Richtung CAD, Schaltschrankplanung oder die klassische Elektroplanung, bis hin zur Mechanik. Gibt es da auch Berührungspunkte?

Andreas Deuter: Das sind im Prinzip auch unterschiedliche Daten­töpfe und die ähnliche Situation, wie wir sie bei uns in der Standard-Software-Entwicklung bislang hatten: Jedes Gewerk speichert seine Daten für sich. Die Hauptschwierigkeit ist, die Verbindung zwischen diesen Daten herzustellen. Wenn es gelingt, so ein Lifecycle-Management-System für das Engineering einer Anlage zu implementieren, dann ist man einen Schritt weiter. Und in diese Richtung denken viele Unternehmen. Grundgedanke dieser Konzepte ist, Daten – egal wo und wann sie anfallen – über den gesamten Prozess zentral zu verwalten. Das ist jedenfalls im Lifecycle Management für Software definitiv ein Erfolgsfaktor, und warum nicht auch für die Planung ganzer Anlagen.

Wie sieht denn aus Ihrer Sicht der ideale Entwicklungs- oder Engineering-Prozess aus für eine Software?

Andreas Deuter: Gut wäre es, sich erst mal die Zeit zu nehmen, die Anforderungen zu verstehen, die in dem Prozess, egal ob in einem Software-Projekt oder im Engineering einer Anlage, umzusetzen sind. Mitunter ertappe ich mich selbst dabei, dass ich bei einer Aufgabenstellung, die irgendwo mit Software zu tun hat, sofort anfange zu programmieren. Aber das ist zu kurz gegriffen. Es ist besser, sich zuerst über die Anforderungen Gedanken zu machen. Das ist ein anstrengender Prozess zu hinterfragen, was ist eigentlich zu tun? Langfristig ist es aber billiger, als etwas zu implementieren, das sich später als unbrauchbar herausstellt. Nur, dieser Weg ist nicht so transparent, weil ein kurzfristiges Ergebnis fehlt.

Der Prozess an sich ist in der Theorie beschrieben, von der Planungsphase geht es in eine Designphase, in die Programmierphase, in der durchaus agile Methoden mit kurzen Feedback-Schleifen zum Einsatz kommen können. Zum Schluss folgt dann die Abnahme und qualitätssichernde Phase. Das Handwerkszeug ist da und beschrieben. Es muss vielleicht noch stärker angewendet werden.

Im Bereich Software arbeitet Phoenix Contact mit verschiedenen Dienstleistern, etwa ihrer Tochter KW-Software. Gehen Ihre Entwicklungspartner den skizzierten Weg mit?

Jens Dreyer: Ein Großteil unserer Software-Entwickler arbeitet seit vier Jahren unter dem Dach des Centrum Industrial IT (CIIT) in Lemgo, genauso wie unsere Kolleginnen und Kollegen von KW-Software. In einigen Phoenix-Contact-spezifischen Projekten arbeiten wir dort teamübergreifend zusammen. Dabei nutzen wir natürlich genau die gleichen Methoden. Dienstleister für unsere Software folgen mittlerweile unseren Prozessen und integrieren sich sogar direkt in unser Lifecycle-Management-System. Unseren Partnern können wir nicht ihre Prozesse vorschreiben, aber wir achten darauf, dass sie mit unseren harmonieren.

Andreas Deuter: Für die nächste Generation unserer Engineering-Plattform, einem auf .NET und C# basierenden Automation Framework, haben wir interne Prozessbeschreibungen erstellt und zuerst alle Software-Entwickler, die an dem Projekt arbeiten, auf diesen einheitlichen Kenntnisstand gebracht.

Jens Dreyer: Die besondere Konstellation in Lemgo ist mit ein Grund, weshalb KW-Software zum 1. Januar 2015 umbenannt und als Phoenix Contact Software GmbH Teil des Geschäfts­bereichs Control Systems wird. Die Belegschaft von KW-Software am Standort Lemgo wird dadurch mit den Software-Entwicklern von Phoenix Contact zusammengeführt. Die Geschäftsführung übernehmen der jetzige KW-Software-Geschäftsführer ­Andreas Orzelski sowie Detlev Kuschke, Leiter der Entwicklung im Geschäftsbereich Control Systems.

Wie ist denn der Status dieses Automation Framework?

"Unser Ziel ist, auch die Effizienz in der Software-Entwicklung unserer Kunden zu steigern." Dr. Jens Dreyer (rechts)Redaktion IEE/Renate Schildheuer

Jens Dreyer: Der Status ist sehr gut. Wir haben dieses Jahr auf der Hannover Messe für unsere intelligenten Logikrelais ein kompaktes Engineeringtool released – Logic+. Das ist quasi die erste Software aus diesem Automation Framework. Parallel diskutieren wir schon mit Key-Kunden, wie die weiteren Schritte aussehen werden.

Welchen Einfluss nimmt das Thema Industrie 4.0 – die Verzahnung unterschiedlichster Komponenten und Module vieler Hersteller – auf die Software-Entwicklung.

Andreas Deuter: Industrie 4.0 wird nachhaltig das Thema Software verändern, sowohl bei den Herstellern als auch den Unternehmen, die nach Industrie 4.0 arbeiten. Oft ist es auch ein Mix. Wir selbst entwickeln Produkte für Industrie 4.0 und setzen die Konzepte ebenso in unserer Produktion um. Die Komplexität, eine Industrie-4.0-Anlage aufzubauen, die von mehreren Herstellern beliefert wird, ist natürlich besonders groß. Wie bei der Software-Entwicklung sind dabei die Themen Wiederverwendung, Standards und gemeinsame Komponenten echte Produktivitätstreiber. Dieses muss daher noch viel stärker in den Fokus rücken als bisher und mit ihm das Thema Software.

Das heißt, Hauptthema sind dann wieder einmal Schnittstellen, deren Standardisierung, Implementierung und Test. Gleichzeitig werden die einzelnen Funktionsmodule immer kleiner. Welche Auswirkungen hat das auf die Programmierung?

Jens Dreyer: Analog zur Maschine muss auch die Software immer dezentraler aufgebaut werden. Wenn ein Maschinenmodul auszuwechseln ist, dann muss die Software auf diesem neuen Modul mit der Software der restlichen Module kommunizieren können. Auch wenn alle Module ein Hersteller liefert, muss die Software modular aufgebaut sein. Dazu müssen die Schnittstellen und die Kommunikation exakt definiert sein. Das verlangt wiederum klare Strukturen und Verantwortlichkeiten der Module in der Software.

Wie sieht aus Ihrer Sicht denn eine Masterschnittstelle für solche dezentralen Ansätze aus, OPC UA?

Jens Dreyer: Es sieht momentan ganz danach aus. OPC UA ist skalierbar von kleinen Geräten bis hin zu Steuerungen und ERP-Systemen. Also geeignet für die Kommunikation in der klassischen Automatisierungspyramide von ganz unten nach ganz oben. Und das noch gekoppelt mit Ethernet-Mechanismen. Wir selbst arbeiten daran, solche Mechanismen einzubauen. Besuchen Sie uns auf der SPS IPC Drives oder auf der nächsten Hannover Messe, dann können wir Ihnen das gerne vorführen.

SPS IPC Drives 2014
Halle 9, Stand 310

(sk)