Entwicklung von Smart Products IoT-Basics – smarte Produkte agil entwickeln

Die produzierende Industrie steht vor tiefgreifenden Veränderungen, denn die digitale Transformation und die Vernetzung zu Industrie 4.0 stellen etablierte Technologien und Geschäftsmodelle in Frage. Um erfolgreich zu bleiben, müssen Unternehmen mit agilen Entwicklungsmethoden neue, smarte Produkte schneller und marktgerechter entwickeln.

Anbieter zum Thema

Fujitsu Technology Solutions GmbH

QUNIS GmbH

Fivetran Germany GmbH

Wettbewerbsfähige, zukunftssichere Automatisierungsprodukte und -lösungen fügen sich zukünftig „smart“ in vernetzte Umgebungen ein und übernehmen eigenständig Aufgaben. Die besondere Herausforderung: Es ist noch nicht klar, welche konkreten Standards und Anforderungen diese Produkte in fünf Jahren erfüllen müssen. Darum sind die klassischen Entwicklungsmethoden mit einmal definierten Pflichten- und Lastenheften sowie linearer Entwicklung bis zum fertigen Produkt nicht mehr zielführend. Wenn sich erst bei der Produktvorstellung beim Kunden herausstellt, dass sich seit Entwicklungsbeginn die Anforderungen verändert haben, ist es zu spät. Die notwendigen Nachentwicklungen führen immer zu Zeitverlusten und erheblichen Budgetüberschreitungen.

Smarte Produkte schnell und agil entwickeln

Die Lebenszyklen vieler Automatisierungsprodukte werden zukünftig oft nur noch in Monaten bemessen. Entwickler smarter Produkte müssen deshalb schnell und flexibel neue Trends und Standards in ihre Lösungen integrieren. Sie können dabei nur begrenzt die Erfahrungen und die Prozesse der Vergangenheit fortschreiben, sie müssen vielmehr unterwegs lernen, zu laufen. Das schaffen sie nur, wenn sie auch neue Entwicklungsmethoden einsetzen, mit denen sie agil zu neuen Lösungen kommen.

Smarte Produkte erfüllen die Anforderungen, die Industrie 4.0 an die Vernetzbarkeit und Intelligenz stellt. Neu ist dabei die ganzheitliche Betrachtung über den kompletten Lebenszyklus. Zum einen verändern sich die Herstellprozesse nachhaltig, denn an die Stelle traditioneller Wertschöpfungsketten treten digital vernetzte Wertschöpfungsnetzwerke. In ihnen arbeiten die beteiligten Unternehmen parallel und mit einem Echtzeit-Datenaustausch gemeinsam an der Entwicklung und Herstellung von Produkten. Zum anderen erfassen die Produkte auch nach der Auslieferung noch Daten über ihre Betriebszustände. Diese Informationen dienen dem Service sowie der kontinuierlichen Verbesserung der Produkte und ihrer Herstellprozesse.

Die digitale Transformation verändert die Anforderungen der Anwender an Produktionsmittel. Deshalb brauchen Hersteller und Anwender von Automatisierungskomponenten und Maschinen eine gemeinsame Basis, die die Grundlagen definiert. Hier hat die Plattform Industrie 4.0 gemeinsam mit seinen Partnern wie ZVEI, VDMA, Bitkom, VDI/VDE-GMA und DKE entsprechende Definitionen entwickelt. Die ersten Ergebnisse sind das Referenzarchitekturmodell Industrie 4.0 (RAMI 4.0) und die Kriterien für Industrie-4.0-Produkte als Mindesteigenschaften.

Produktkriterien für Industrie-4.0-Produkte als Mindesteigenschaften

RAMI 4.0 ist der Blick von außen auf den gesamten Lösungsraum von Industrie 4.0. Die Industrie-4.0-Komponente ist die Betrachtung aus der Sicht eines Dings, das nun in das Industrie-4.0-Netzwerk integriert werden soll. Dazu gehört neben dem Ding an sich die Abbildung wieder in den Layern vom RAMI 4.0. Diese digitale Abbildung ist in den 5 Layern als „Verwaltungsschale“ zusammengefasst. Die Industrie-4.0-Komponente ist also eher die Betrachtung von innen und RAMI 4.0 die Betrachtung von außen.

Arbeitskreise der Verbände und Unternehmen haben Kriterien für Industrie-4.0-Komponenten (I4.0-Komponente) definiert.

• Identifikation: Eine zwingend notwendige Voraussetzung für Industrie 4.0 ist die eindeutige Identifikation aller Produkte. Jedes Produkt braucht dafür einen Identifier. Diese eindeutige Identifikation wird über den gesamten Lebenszyklus von der Entwicklung über Logistik und Produktion bis hin zum Vertrieb, Service, Marketing und der Einbindung in Netzwerken benötigt.

• Industrie-4.0-Kommunikation: Industrie 4.0 folgt einer serviceorientierten Architektur, in der Dienste ausgeführt und Daten ausgetauscht werden können. Die Industrie-4.0-Kommunikation soll nicht neu entwickelt, sondern aus den vorhandenen und bereits in Entwicklung befindlichen Standards abgeleitet werden. Hier zeichnet sich ab, dass in der Produktion sich Ethernet als TCP/UDP/IP-Kommunikation sowie OPC UA als Vorzugsstandards etablieren. Die Übertragung von Daten des Produktes erfolgt in standardisierter Form. Das Produkt ist über offene Schnittstellen im Netzwerk ansprechbar, liefert und übernimmt Daten.

• Industrie-4.0-Semantik: Damit sich Komponenten, Maschinen, Anlagen und IT-Systeme herstellerübergreifend verstehen, benötigen sie eine gemeinsame Sprache. Sie umfasst gemeinsame Vokabeln in Form von Daten und Funktionen sowie eine gemeinsame Syntax, die den richtigen Kontext für die Daten herstellt. Auch hier sollen vorrangig schon vorhandene Standards zum Einsatz kommen.

• Virtuelle Beschreibung: Die virtuelle Beschreibung umfasst digital alle wichtigen Daten in Industrie-4.0-Semantik. Diese Informationen bilden das digitale Abbild eines Produktes, mit dem Anwender arbeiten können.

• Industrie-4.0-Dienste und -Zustände: Innerhalb des Industrie-4.0-Netzwerks finden sich Komponenten, Systeme und Maschinen und handeln zu Beginn aus, wie sie miteinander kommunizieren. Dazu müssen diese Industrie-4.0-Dienste herstellerübergreifend beschrieben und implementiert sowie standardisiert für jeden zugänglich sein. Proprietäre Systeme erfüllen diese Voraussetzungen nicht.

• Standardfunktionen: Standardisierte Funktionen bei allen Automatisierungskomponenten und -systemen erleichtern Maschinenherstellern und Endkunden die Arbeit. Das zeigen bereits heute die Funktionen aus PLC open, einem herstellerunabhängigen Standard für die Programmierung von Bewegungen. Die Standardfunktionen bilden die Basis, auf der jeder Hersteller seine eigenen Erweiterungen aufbauen kann.

• Security: Der Schutz vor einem unberechtigten digitalen Zugriff auf die Industrie-4.0-Komponente muss über den gesamten Lebenszyklus auf allen Architekturschichten und Hierarchieebenen wirksam sein. Die IEC 62 443-3-3 wird dabei zukünftig eine Schlüsselrolle spielen.

Auswirkungen auf die Produktentwicklung

Das Referenzarchitekturmodell RAMI 4.0 und die Produktkriterien vereinheitlichen nicht nur das Verständnis für Industrie 4.0. Sie machen auch deutlich, dass smarte Produkte wie die I4.0-Komponenten neue Anforderungen an ihre Entwicklung stellen und neue Einsatzszenarien und Geschäftsmodelle ermöglichen.

• Services: Produkte benötigen in der Zukunft immer mehr Services, um weiterhin verkauft werden zu können. Dabei wird es Standardservices geben, die alle Produkte als Mindeststandard erfüllen müssen, und herstellerspezifische Services als Differenzierungsmerkmal. Services werden über den gesamten Lebenszyklus angeboten.

• Verteilte Intelligenz: Diese Services werden zentral oder auch dezentral zur Anwendung kommen. Wichtig ist dabei, dass stets Intelligenz zur Verfügung steht, sei sie nun dezentral an oder in einem Produkt oder auch zentral in einer Plattform angeordnet.

• Komponenten ohne eigene Intelligenz: Mit dieser verteilten Intelligenz können auch heute Produkte ohne eigene Intelligenz über ein virtuelles Abbild in einer Plattform am digitalen Netzwerk von Industrie 4.0 teilnehmen. Die Konnektivität bei diesen Produkten erfolgt dann zum Beispiel über eine eindeutige Identifikation als QR-Code. Daher werden neben den Produkten mit eigener Intelligenz on board auch immer mehr Produkte ohne eigene Intelligenz durch ihr virtuelles Abbild zu Industrie-4.0-Produkten.

• Programmiersprachen aus der IT: Das Konzept der verteilten Intelligenz erfordert einen „Brückenschlag zwischen Automatisierung und IT-Welt“. Mit Industrie 4.0 wächst der Druck, dass verschiedenste Maschinen und Anlagen Informationen untereinander und mit übergeordneten Systemen austauschen. Diese horizontale und vertikale Vernetzung stellt neue Anforderungen an die Offenheit zwischen Automatisierung und IT. Ein Flaschenhals ist oft die Erstellung von SPS-Programmen und -Schnittstellen. Hier stehen vergleichsweise wenige Entwickler zur Verfügung, die über die entsprechenden Kenntnisse verfügen. Gleichzeitig finden IT-Programmiersprachen immer mehr Verwendung in der Automatisierung. Ein Vorteil: Millionen Programmierer arbeiten mit den IT-Hochsprachen und Internet-Dialekten. Unternehmen, die es schaffen, diese Ressourcen für die eigene Entwicklung zu nutzen, können ihre Time-to-Market auf einen Bruchteil der bisherigen Dauer verkürzen.

• Offenheit: Der wachsende Softwareanteil im Maschinen- und Anlagenbau verändert die Wertschöpfung. Hersteller investieren viele Mannstunden in die Entwicklung von Software. Offene, herstellerübergreifende Standards sichern diese Investition. Offenheit ist eine große Herausforderung, denn sie betrifft mehrere Ebenen: Innerhalb der Automatisierungswelt hat es immer wieder Anstrengungen einzelner Anbieter gegeben, proprietäre Systemlösungen durchzusetzen. Sie eliminieren vordergründig die Schnittstellenproblematik, setzen aber auf der anderen Seite der Innovation Grenzen. Gleichzeitig besteht die Gefahr, dass der Anbieter des proprietären Systems einseitige Veränderungen durchsetzen kann. Anders verhält es sich bei offenen Standards, die von vielen Herstellern getragen werden. Änderungen sind hier nur im Konsens möglich, und in der Regel ist die Abwärtskompatibilität gewährleistet. Das schützt die bisherigen Investitionen nachhaltig. Gleichzeitig sind offene Systeme tendenziell innovativer, weil alle Komponenten im freien Wettbewerb stehen.

• Lebenszyklus: Der Maschinenbau sieht sich mit verkürzten Produktlebenszyklen konfrontiert. Konnten einmal ausentwickelte Maschinen in der Vergangenheit hardwaremäßig unverändert gebaut werden, so verringert der steigende Software-Anteil diese Zeiträume erheblich. Updates und neue Funktionalitäten in Form von Software werden immer häufiger in Maschinen und Anlagen üblich werden. Diese Funktionen werden mit „Pay per Use“-Modellen zu- und abgeschaltet. Das wirkt sich auch auf die notwendige Entwicklungsgeschwindigkeit aus: Je kürzer der Lebenszyklus der Software, desto weniger Zeit steht den Entwicklern für die nächste Generation zur Verfügung.

• Kollaboration mit IT-Partnern: Die Entwicklung neuer Automationslösungen und Maschinen sowie ihre Anbindung an vernetzte IT-Systeme wird in Zukunft nicht mehr komplett inhouse eines einzelnen Herstellers möglich sein. Mit Industrie 4.0 wird es immer wichtiger, Kooperationen mit anderen zu schließen. Mit der Konzentration auf das eigene Know-how und der Nutzung von anderen Tools und Standards der Kooperationspartner können Automatisierungshersteller, Maschinenbau und IT-Industrie schnell zu tragfähigen und zukunftssicheren Lösungen kommen.

• Daten: Smarte Produkte bedeuten immer häufiger auch datenbasierte Services. Dazu ist in einer Industrie 4.0 eine herstellerübergreifende Standardisierung von zumindest grundlegenden Daten nötig. Nur wenn ein minimales Set an Daten einheitlich vorhanden ist, kann ein Produkt in ein Industrie-4.0-Netzwerk leicht integriert werden und weitergehende Funktionen/ Services können ohne Programmieraufwand angeboten werden.

• Neue Geschäftsmodelle: Ein entscheidender Faktor für die Wirtschaftlichkeit und Produktivität von Maschinen und Anlagen ist ihre Verfügbarkeit. Ein ungeplanter Maschinenstillstand erzeugt hohe Kosten für die Diagnose und Reparatur. Gerade bei kontinuierlich produzierenden Prozessanlagen und hochintegrierten Fertigungslinien sind die indirekten Kosten durch Produktionsausfall um ein Vielfaches höher. Hier zeichnen sich disruptive Geschäftsmodelle durch datenbasierte Services ab. Es wird beispielsweise eine höhere Verfügbarkeit garantiert, wenn die Daten online zur Verfügung gestellt werden. Dazu werden die Daten an einen Server gesendet, wo sie selbstlernende Software und Big-Data-Methoden auswerten.

Neue Prozesse für smarte Produkte – Agile Entwicklungsmethoden

Der klassische Entwicklungsansatz für Hardwareprodukte und damit verbundene langlebige Software ist in größeren Unternehmen als Prozess definiert und durch Meilensteine sowie Qualitätstore strukturiert. Das macht in ausgereiften Märkten auch darum Sinn, weil in der Entwicklungsphase entscheidende Weichen für die späteren Qualitätskosten gestellt werden. Dieses Vorgehen macht auch weiterhin Sinn bei Standardprodukten mit klar definierten Eigenschaften und überschaubarer Komplexität.

Bei smarten Produkten hingegen sind die Zieldefinition beweglich und die Komplexität (noch) hoch, weil Schnittstellen und Standards sich schnell ändern können. Vor allem ist Zeit wesentlich wichtiger, weil die ersten Anbieter den „Early Mover“-Vorteil haben. Sie sammeln bereits Anwendungserfahrungen, die in die nächste Version einfließen, während der Wettbewerb noch immer an der ersten Variante arbeitet. Ein solches exploratives, teilweise „Trial and Error“-Vorgehen ist bei den strukturierten Entwicklungsprozessen im Maschinenbau bislang nicht vorgesehen.

Hier bietet sich ein Blick über den Tellerrand an. Die Software-Industrie arbeitet seit Jahrzehnten mit extrem kurzer Produktlebenszyklen und der Unwägbarkeit, dass die Kunden nicht im Voraus sagen können, was sie wollen. Vielmehr erkennen sie die Vorteile einer Funktion oft erst, wenn sie verfügbar ist, und wollen mehr davon. In diesem Marktumfeld hat die Softwarebranche agile Entwicklungsmethoden validiert, die jetzt auch sinnvoll auf den Maschinenbau übertragbar sind.

Scrum-Methode: Auf variable Ziele hin entwickeln

Ein Beispiel für agile Entwicklungsmethoden ist die in der Softwarebranche bewährte Methode Scrum. Zunächst bindet diese Methode die Wünsche der Maschinenhersteller als direkte Kunden, sowie der Maschinenbetreiber, also der Anwender, ein. Anders als in klassischen Entwicklungsprozessen entsteht daraus aber nicht ein bis zum Entwicklungsende gültiges Lastenheft. Vielmehr werden während der Entwicklung die Kunden und Nutzer immer wieder neu befragt, um festzustellen, ob sich die Anforderungen verändert haben. Das verhindert, dass am zukünftigen Bedarf vorbei entwickelt wird.

Die regelmäßig überprüften Anforderungen des Marktes geben das Ziel für das interdisziplinär zusammengestellte Scrum-Team vor. Es hat einen hohen Freiheitsgrad, selbst zu entscheiden, wie es die Ziele erreicht. Scrum reduziert dabei nicht die Komplexität der Aufgabe, sondern teilt sie in viele kleine, weniger komplexe Teilaufgaben ein. Diese müssen in Sprintphasen von Arbeitsgruppen parallel abgearbeitet werden, sodass Schwierigkeiten an einer Stelle die anderen Arbeitsgruppen nicht ausbremsen. So wachsen neue Produkte schneller als in einem sequenziellen Entwicklungsprozess heran und sie treffen die Anforderungen des Marktes besser.

Diese Umstellung auf agile Entwicklungsmethoden fordert auch das Management. Scrum-Teams werden eben nicht klassisch durch Führungskräfte hierarchisch koordiniert, sondern organisieren sich in hohem Maße selbst. Führungskräfte greifen ein, um das Team oder einzelne Teammitglieder zu coachen und zu unterstützen.

Dieser Artikel stammt von unserem Partnerportal MaschinenMarkt. Verantwortliche Redakteurin: Stefanie Michel

* Dipl.-Ing. Martin Hankel ist Projektleiter Industrie 4.0 Technik bei der Bosch Rexroth AG in 97816 Lohr am Main

(ID:45241892)