1 Einleitung und Motivation

Ein Cyber-Physisches System (CPS) ist ein System in dem physische Einheiten und Softwarekomponenten eng miteinander vernetzt und abhängig von ihrem Betriebskontext und ihrer Umgebung interagieren. CPS sind hochkomplexe, verteilte und Software-intensive Systeme, d.h. Software trägt einen wesentlichen Teil zum Entwurf, der Konstruktion, der Inbetriebnahme und der Wartung und Weiterentwicklung (Evolution) solcher Systeme bei.Footnote 1 Software-intensive Cyber-Physische Produktionssysteme (SiCPPS) sind hochvariable Systeme von Systemen [36], die sich ständig weiterentwickeln [20].

Variabilität meint „die Fähigkeit eines Softwaresystems oder -artefakts effizient erweitert, geändert, angepasst oder konfiguriert zu werden“ [8]. In SiCPPS unterstützt Software den Aufbau hochkonfigurierbarer Produktionssysteme, die in der Lage sind, Produkte flexibel an die Anforderungen des Kunden angepasst zu produzieren. Der Entwicklungsprozess von SiCPPS umfasst mehrere technische Disziplinen (z.B. Mechanik, Elektrik, Mechatronik, Software), die während der Systementwicklung zusammenarbeiten müssen, um mit der Vielfalt an Produktvarianten umgehen zu können [14]. Dies erfordert insbesondere eine klare Definition der Abhängigkeiten zwischen den Artefakten in diesen Disziplinen.

Wie in Abb. 1.a dargestellt, werden die meisten der heterogenen Artefakte (z.B. Software, Elektroschaltpläne, Hydraulikpläne, Stücklisten, Spezifikationen) von verschiedenen Personen aus den unterschiedlichen Disziplinen mit unterschiedlichen Werkzeugen manuell erstellt und gepflegt. Abhängigkeiten zwischen den Artefakten resultieren aus physikalischen Anforderungen oder aus Geschäftsentscheidungen. Diese Abhängigkeiten sind jedoch häufig nicht dokumentiert, insbesondere nicht zwischen Artefakten verschiedener Disziplinen. Damit hängt der Erfolg der Entwicklung stark vom Domänenwissen der Mitarbeiter ab. Darüber hinaus folgen Werkzeugen aus verschiedenen Disziplinen unterschiedlichen Ontologien, was ihre Interoperabilität behindert.

Abb. 1.
figure 1

In SiCPPS werden heterogene Artefakte aus verschiedenen Disziplinen mit unterschiedlichen Abhängigkeiten von verschiedenen Personen meist manuell, mit verschiedenen Werkzeugen gepflegt (a); Variabilität wird in SiCPPS typischerweise durch verschiedene, oft eigens entwickelte Mechanismen und Werkzeuge verwaltet (b)

Full size image

Die Industrie hat daher ein Interesse daran besser mit der Variabilität der Artefakte umzugehen und vor allem systematische Wiederverwendung zu unterstützen, da damit Entwicklungs- und Wartungskosten gesenkt und die Markteinführungsdauer reduziert werden kann [10]. In einem kürzlich erschienenen Artikel haben Berger et al. [3] die Ergebnisse einer Studie mit zwölf mittelgroßen bis großen Firmen in Bezug auf den Einsatz von Variabilitätsmanagementtechniken vorgestellt. Sie kommen zu dem Schluss, dass Hardware und der Druck des Marktes zur Individualisierung die wichtigsten Treiber für Variabilität in der Industrie sind. Außerdem folgern sie, dass Industrie 4.0 und Digitalisierung das Variabilitätsmanagement erschweren bzw. weitere Forschung motivieren.

Systematisches Variabilitätsmanagement wurde in der bisherigen CPS-Forschung bisher weitgehend vernachlässigt [60]. Im Bereich des Software Engineering, insbesondere im Bereich der Softwareproduktlinien [10], konzentrierte sich die frühe Forschung zwar auf software-intensive Systeme [39, 46], jedoch fokussiert sich die aktuelle Forschung mehr und mehr auf die Variabilität von Software, Services und Betriebssystemen. Leider werden Evaluierungen von Forschungsansätzen oft mit kleinen, konstruierten Beispielen und im Labor statt unter realen Bedingungen durchgeführt [46].

Wie in Abb. 1.b angedeutet, muss in SiCPPS die Variabilität verschiedener heterogener Artefakte verwaltet werden. Ein „one-size-fits-all“-Ansatz zur Variabilitätsmodellierung ist daher von vornherein zum Scheitern verurteilt. Stattdessen erfordern verschiedene Disziplinen unterschiedliche Ansätze zur Verwaltung der Variabilität und einen Mechanismus, der hilft die verschiedenen Variabilitätsebenen miteinander zu verbinden [19].

In unserer Forschung konzentrieren wir uns auf die Beherrschung der Variabilität in SiCPPS, d.h. diese zu verstehen, zu modellieren bzw. zu dokumentieren und vor allem zur automatisierten Konfiguration von SiCPPS zu verwenden. Im Rahmen dieses Artikels fassen wir den Stand der Technik und Praxis zusammen, diskutieren die besonderen Herausforderungen im Umgang mit Variabilität in SiCPPS und beschreiben unsere Forschungsziele und Forschungsagenda.

2 Stand der Technik

Unsere Arbeit stützt sich zum einen auf bestehende Forschung im Bereich CP(P)S und zum anderen auf Forschung zu Variabilität und Softwareproduktlinien (SPL) sowie Vorarbeiten zu Variabilität und CP(P)S.

Harrison et al. [21] geben beispielsweise eine ausführliche Zusammenfassung bestehender Entwicklungsstandards, -methoden und -werkzeuge für CP(P)S. Die Autoren betonen: „Es wurde viel über die potenziellen Vorteile der Einführung von CPSen in der Fertigungsindustrie veröffentlicht. Es wurde jedoch weniger darüber geschrieben, wie solche Automatisierungssysteme effektiv konfiguriert und über ihren Lebenszyklus hinweg unterstützt werden können und wie die Anwendungsmodellierung, Visualisierung und Wiederverwendung solcher Systeme am besten erreicht werden kann.“ Biffl et al. [4] fassen bestehende Arbeiten zum multidisziplinären Engineering für SiCPPS zusammen. Die Autoren stellen außerdem einen modellgetriebenen, auf AutomationML basierenden SiCPPS Entwicklungsansatz inklusive Versionierungs- und Verknüpfungsunterstützung vor. In der Praxis verwenden Domänenexperten jedoch nach wie vor verschiedene selbst entwickelte und zugekaufte Entwicklungswerkzeuge. Dies führt zu einer heterogenen Werkzeugslandschaft mit einer großen Anzahl an Entwicklungswerkzeuge, die auf unterschiedlichen Datenstrukturen arbeiten [16]. Modellentwicklung, -pflege und -integration sowie Datenaustausch und -freigabe stellen in der Praxis immer noch große Herausforderungen dar [26]. Im Zuge von Industrie 4.0 und daraus dem RAMI4.0 resultierenden Verwaltungsschale steigt die Verfügbarkeit von maschinenlesbaren integrierten Datenmodellen [25].

Bestehende Arbeiten beschäftigen sich zwar mit dem Entwicklungsprozess von SiCPPS, einschließlich der Versionierung und Verknüpfung von Modellen und Artefakten, jedoch wurde ein systematisches Variabilitätsmanagement jedoch bisher meist vernachlässigt [60].

Seit Anfang der 1990er Jahre wird zu SPL und Variabilität geforscht [39, 46]. Eine SPL wurde definiert als „eine Familie von (software-intensiven) Systemen, die aus einer gemeinsam verwalteten Menge von Artefakten durch systematische Wiederverwendung entwickelt werden und durch Erweiterungen und Konfiguration (Variabilität) an die Bedürfnisse spezifischer Kunden oder Marktsegmente angepasst werden.“ [10]. Es gibt erste Forschungsarbeiten zum Thema Variabilität und CPS. Zum Beispiel stellen ter Beek et al. [2] ein Featuremodell (Modell der Variabilität) einer Familie von Zugsteuerungssystemen vor. Brings et al. [7] berichten über eine explorative Fallstudie zur Variabilitätsmodellierung in der Industrieautomatisierung. Krüger et al. [27] schlagen in ihrem Positionspapier eine Klassifizierung der für CPS relevanten Variabilitätsaspekte vor. Sie weisen auf aktuelle Herausforderungen bei der Variabilitätsmodellierung hin und skizzieren offene Forschungsfragen und -ziele. Vor allem weisen sie darauf hin, dass die Variabilität eines CPS typischerweise heterogene Aspekte umfasst, die in ein gemeinsames Modell integriert werden müssen. Fang [15] stellt einen halbautomatischen, modellbasierten Ansatz vor, der darauf abzielt, die Wiederverwendbarkeit bestimmter Komponenten während des Entwicklungsprozesses zu verbessern (Ebene 4 Software der Automatisierungspyramide). Bezüglich der Variabilität in CPS untersuchten Safdar et al. [48] die Verwendung von existierenden Variabilitätsmodellierungstechniken und argumentieren, dass es notwendig ist, bestehende Ansätze zu erweitern oder neue Ansätze vorzuschlagen.

Dies wollen wir erreichen, indem wir unsere eigenen früheren Arbeiten zu SPL und Variabilität [12, 43, 44, 56] mit unseren Arbeiten im Bereich Steuerungstechnik und Produktionsautomatisierung [58, 61–63] zusammenführen. Seit kurzem arbeitet einer der Autoren auch mit Kollegen an der TU Wien an der Modellierung der Variabilität von Produkten, Prozessen und Ressourcen in SiCPPS [17, 31] was ein wichtiger zusätzlicher Input für die in diesem Beitrag vorgeschlagene Arbeit ist.

3 Stand der Praxis

Aufgrund der unterschiedlichen Arten von automatisierten Prozessen und der für die industrielle Automatisierung verwendeten Steuerungssoftware wurden der Systementwicklungsprozess und das Lebenszyklusmodell bisher nicht vereinheitlicht [64]. Im Gegensatz zu typischen Software-Engineering-Lebenszyklusmodellen sind in SiCPPS verschiedene Disziplinen (Mechanik, Elektrik, Software, etc.) an verschiedenen Schritten der Maschinen- und Anlagenentwicklung beteiligt. Entscheidungen in einer Disziplin können die anderen in großem Umfang sowohl kurzfristig als auch langfristig beeinflussen. Beispiele dafür sind Anpassungen einer Maschine an die örtlichen Gegebenheiten des Kunden, der Wechsel von pneumatischen Achsen auf servo-elektrische oder der Wechsel eines Komponentenlieferanten.

Abbildung 2 zeigt einen typischen, die hohe Variabilität unterstützenden Entwicklungsprozess von Steuerungssoftware in SiCPPS. Er besteht aus drei Hauptphasen: Funktionsentwicklung, Projekterzeugung und Projektabwicklung. Im Rahmen der Funktionsentwicklung wird die Kernfunktionalität in Form einer Plattform entwickelt und gepflegt. Eine solche Plattform besteht aus Komponentenbibliotheken, Vorlagen und Lösungen für Maschinen oder Anlagen. Für ein bestimmtes Projekt werden die entsprechenden Elemente der Plattform verwendet (unter Verwendung eines Clone-and-Own-Reuse-Ansatzes) und auf das im konkreten Projekt verwendete Steuerungssystem umgesetzt (erweitert). Da sich Steuerungssysteme stark unterscheiden, muss dieser Projekterzeugungsprozess die Besonderheiten des Zielsystems berücksichtigen und kann daher langwierig und fehleranfällig sein. Außerdem müssen die Elemente der Plattform in einer für das eingesetzte Steuerungssystem spezifischen Version gepflegt werden. Dies sind die Gründe, warum nur eine Teilmenge der Steuerungssysteme für Projekte verwendet werden kann. In der Projektdurchführungsphase wird die erstellte Steuerungssoftware manuell an die spezifische Maschinen- oder Anlagenkonfiguration angepasst, getestet und schließlich in Betrieb genommen. Oft werden in der Projektdurchführungsphase auch zusätzliche projektspezifische Implementierungen durchgeführt.

Abb. 2.
figure 2

Übersicht über einen typischen Entwicklungsprozess, der von vielen Maschinen- und Anlagenbauern angewandt wird

Full size image

Dieses Vorgehen reduziert den Entwicklungsaufwand zwar bereits erheblich, dennoch gibt es immer noch offene Herausforderungen. Die hohe Variabilität von Maschinen- oder Anlagenkonfigurationen wird noch überwiegend manuell gehandhabt. Darüber hinaus müssen Änderungen an Maschinen- oder Anlagenkonfigurationen, die während der Projektabwicklung auftreten, manuell nachverfolgt und bearbeitet werden. Dadurch steigt der Aufwand in der Projektabwicklung. Derzeit gibt es keine Verbindung zwischen dem Code der Plattform und dem projektspezifischen Code. Daher ist es sehr schwierig, Korrekturen und Verbesserungen, die während der Projektabwicklung identifiziert werden, in die Plattform rückzuführen. Dies muss derzeit manuell erfolgen und es gibt keinen systematischen Roundtrip-Prozess.

Das Ziel unserer Forschung ist es daher, die Maschinen- und Anlagenvariabilität in der Plattform besser zu handhaben, den Projekterzeugungsprozess zu verbessern, um den projektspezifischen Entwicklungsaufwand zu reduzieren und ein systematischeres Round-Trip-Engineering zu unterstützen. Davon motiviert forschen wir an methodischer Unterstützung für die Beherrschung von Variabilität mit Unterstüztung von semantischer Datenintegration in SiCPPS und wenden Ansätze und Werkzeuge auf Anwendungsfälle aus der Industrie an.

4 Forschungsziele

Abbildung 3 zeigt einen Überblick über unsere Forschungsziele im Rahmen eines SiCPPS Entwicklungsprozesses unter der Annahme der Verfügbarkeit einer gemeinsamen Plattform (vgl. Abschn. 3), von der Produkte abgeleitet werden.

Abb. 3.
figure 3

Forschungsziele zur Beherrschung der Variabilität in SiCPPS

Full size image

(RG1) Modellierung der Variabilität in SiCPPS. Die Anforderungen an SiCPPS sind oft nicht vollständig dokumentiert, sondern existieren teilweise nur in den Köpfen der Ingenieure und sind somit implizites Wissen. Darüber hinaus sind die Anforderungsinformationen auf mehrere Artefakte verteilt, z.B. auf detaillierte technische Spezifikationen, Designmodelle, diverse Pläne, Softwareartefakte und sogar Benutzerhandbücher oder technische Benutzerdokumentation. Aufgrund der Heterogenität dieser Artefakte und weil verschiedene Rollen (oft mit ganz unterschiedlichem Hintergrund und unter Verwendung verschiedener Techniken und Werkzeuge) aus verschiedenen Disziplinen sie erstellen und pflegen, ist es fast unmöglich, einen vollständigen Überblick über die Anforderungen von SiCPPS zu erhalten. Speziell für die Variabilität führt dies „oft zu einer Situation, in der niemand im Unternehmen einen umfassenden Überblick über die vorhandene Variabilität hat“ [6]. Ein Team aus sehr erfahrenen Mitarbeitern kann SiCPPS dennoch erfolgreich planen, entwerfen, entwickeln, in Betrieb nehmen und warten. Der fehlende oder zumindest unvollständige Überblick über die Anforderungen und insbesondere die System- und Softwarevariabilität macht die Lernkurve für neue Mitarbeiter jedoch sehr steil und bremst auch erfahrenes Personal häufig aus. Dies spricht für den Einsatz von Variabilitätsmodellen, um implizites Expertenwissen explizit darzustellen. Solche Modelle sind auch eine Voraussetzung, um Wiederverwendung und Konfiguration besser zu unterstützen. Variabilitätsmodelle [11], z.B. Feature-Modelle oder Entscheidungsmodelle, könnten zu diesem Zweck verwendet werden. Feature-Modelle erfassen Features – das Verständnis der Endbenutzer über die allgemeinen Fähigkeiten von Systemen in der Domäne – und die Beziehungen zwischen ihnen. Entscheidungsmodelle definieren die Entscheidungen, die getroffen werden müssen, um ein Produkt einer SPL zu spezifizieren. Die Besonderheiten von SiCPPS werden in bestehenden Ansätzen noch nicht berücksichtigt. Dies betrifft insbesondere den Umgang mit verschiedenen Engineering-Disziplinen und damit verbundenen Artefakten und Prozessen. Multi-View-Modellierungsansätze [14, 15] und orthogonale Variabilitätsmodellierungsansätze [12, 38] scheinen uns hier ein vielversprechender Ansatzpunkt zu sein.

(RG2) Automatisierte Extraktion von Variabilität. Jeder Modellierungsansatz, der die manuelle Erstellung von Modellen und insbesondere die manuelle Pflege und Weiterentwicklung der Modelle voraussetzt, wird in der Praxis wahrscheinlich scheitern. Selbst wenn der zusätzliche Aufwand für das Re-Engineering und die Modellierung von der Industrie akzeptiert würde, würden die Mitarbeiter in einer zeitlich begrenzten, projektgetriebenen Umgebung weiterhin mit den Artefakten und Werkzeugen arbeiten, an die sie gewöhnt sind, und nicht jedes Mal, wenn sie etwas in ihren Dokumenten, Plänen, dem Quellcode oder ähnlichem ändern, manuell zusätzliche Modelle einpflegen. Bestehende Arbeiten gehen jedoch typischerweise davon aus, dass jemand manuell Variabilitätsmodelle erstellt und pflegt. Damit ein Ansatz zur Variabilitätsmodellierung für die Praxis nützlich ist, muss die Modellerstellung und -wartung daher zumindest teilweise automatisiert werden, d.h. die Extraktion von Variabilitätsinformationen aus bestehenden Artefakten, wie zum Beispiel aus oft als Spreadsheets vorhandenen Komponenten- und Templatelisten, muss unterstützt werden. Siehe den Abschnitt über verwandte Arbeiten in [31]. Das automatische Extrahieren von Variabilität in SiCPPS erfordert das Parsen der heterogenen Artefakte und die richtige Interpretation der Informationen auf der Grundlage vordefinierter Regeln oder Heuristiken. Domänenexperten sollten nur dann hinzugezogen werden, wenn etwas nicht vollständig automatisiert werden kann. Von diesen Experten angebotene Lösungen müssen später zu programmierten Regeln werden, die die Aufgabe in Zukunft weiter automatisieren. Forschung aus dem Bereich der künstlichen Intelligenz (insbesondere Information Retrieval und maschinelles Lernen) könnte hier hilfreich sein [55].

(RG3) Automatisierte Abbildung von Problem- zu Lösungsraum. Variabilitätsmodelle bieten typischerweise eine Problemraumsicht (Anforderungen, Features) auf bestehende Systeme und wiederverwendbare Artefakte. Bestehende Arbeiten zur Modellierung des Lösungsraums, z.B. unter Verwendung der Unified Modeling Language,Footnote 2 der IEC 61499 [61] und insbesondere der Systems Modeling LanguageFootnote 3 und der AutomationMLFootnote 4 berücksichtigen Variabilität nur teilweise. Insbesondere für Ingenieure, die für die Wartung verantwortlich sind, ist es oft schwer zu verstehen, welche Auswirkungen eine Änderung, die sie an einem Artefakt vornehmen, auf bestehende Modelle hat und umgekehrt. Gleichzeitig müssen Ingenieure schnell reagieren, um Produktionssysteme am Laufen zu halten oder sie nach Ausfällen wieder zum Laufen zu bringen. Bestehende Ansätze müssen an den SiCPPS-Kontext angepasst werden. Insbesondere müssen sie so flexibel gestaltet werden, dass neue (Arten von) Artefakten und Modellen integriert werden können. Bestehende Standards wie AutomationML bieten bereits eine Möglichkeit zur Verknüpfung von Lösungsraum-Artefakten. Wenn ein solches explizites Modell der Entwicklungsartefakte und ihrer Beziehungen bereits vorhanden ist (vgl. RG4), sollten Verknüpfungen vom Problem (Features) zum Lösungsraum (Artefakte) auf der Basis dieses Modells erstellt werden können. Techniken zur FeatureLokalisierung [47], die auf statischer Analyse, dynamischer Analyse, Information Retrieval oder hybriden Techniken basieren, könnten als Ausgangspunkt verwendet werden. Zusätzlich könnten Traceability-basierte Ansätze [9, 23] helfen.

(RG4) Semantische Repräsentation und Integration. Die Entwicklung von SiCPPS ist durch eine Umgebung mit sehr heterogenen Disziplinen and Standards gekennzeichnet [4, 57]. Dennoch sind die Entwicklungsdaten aus den verschiedenen Disziplinen stark voneinander abhängig [33]. Die Daten werden jedoch meist nur innerhalb der einzelnen Disziplinen gepflegt. Aufgrund fehlender formaler Definitionen und Richtlinien bzw. Regeln für Ingenieure wird derzeit entweder eine manuelle Synchronisation vorgenommen, die zeitaufwändig und fehleranfällig ist, oder es werden Arbeitsabläufe sequentiell organisiert. Letzteres verlangsamt den Fortschritt eines Projekts erheblich [34]. Die bisherigen Erfahrungen im Bereich des modellbasierten Systems-Engineering [59] und der Werkzeugintegration von Entwicklungswerkzeugen [58] haben gezeigt, dass eine wesentliche Anforderung darin besteht, die vorhandenen Entwicklungsdaten aus den verschiedenen Entwicklungsdisziplinen (wieder) zu verwenden. Es wurde versucht, Ansätze aus dem Software Engineering als dedizierte Sprachen zur Modellierung dieser Informationen einzuführen, z.B. SysML und AADL [18]. Allerdings ist deren Akzeptanz bei Ingenieuren für viele SiCPPS gering, da wieder zusätzliche Modelle entwickelt und gepflegt werden müssen. Wir schlagen ein Semantic Integration Model (SIM) basierend auf einer Ontologie vor. Ontologien unterstützen die explizite Spezifizierung des Wissens in einer Disziplin, erhöhen den Grad der Spezifikation von Wissen durch die Einbindung von Semantik in die Daten und fördern deren Austausch in einer explizit verständlichen Form. Ausgangspunkt für das SIM sind aktuelle Entwicklungsmodelle der verschiedenen Disziplinen sowie bestehende Modellierungstechniken für das Systems Engineering, wie SysML oder AADL, und entsprechende Datenintegrationsstandards wie AutomationML. Das SIM soll genutzt werden um z.B. Konsistenzprüfungen (vgl. RG6) und die Generierung von Zielartefakten zu unterstützen (vgl. RG5).

(RG5) Generierung und Konfiguration von SiCPPS-Zielartefakten. Die Generierung von Zielartefakten auf Basis von Entwicklungsmodellen erfolgt aktuell typischerweise mit einzelnen Eingabemodellen und wird von Fall zu Fall entwickelt. Dies ist eine langwierige, fehleranfällige Aufgabe, die für jedes neue Zielartefakt erneut durchgeführt werden muss [52]. Die semantische Integration von Entwicklungsdaten, wie sie unser SIM bieten würde (vgl. RG4), wird den Prozess der Zielartefaktgenerierung vereinfachen. Als Zielartefakte sehen wir z.B. Steuerungsprogrammfragmente, automatisierte Testszenarien, Steuerungskonfigurationen oder anlagenspezifische multidisziplinäre Simulationsskripte vor. Wir planen zusätzlich die in Variabilitätsmodellen enthaltenen Informationen zu nutzen, um eine schnelle Ableitung mehrerer Varianten von generierten Artefakten zu unterstützen. Im SiCPPS-Kontext besteht eine besondere Herausforderung darin, dass das für die Produktableitung benötigte Wissen oft in den Köpfen von Personen aus verschiedenen Disziplinen verteilt ist, die während des Ableitungsprozesses möglicherweise nicht verfügbar sind. Darüber hinaus können die Variabilitätsmodelle in der realen Welt sehr komplex werden. Die Integration von wiederverwendeten (sowohl selbst entwickelten als auch „off-the-shelf“) Artefakten mit neu erstellten Artefakten [41, 42] ist daher eine zentrale Herausforderung, die es hier zu bewältigen gilt.

(RG6) Konsistenzüberprüfung für SiCPPS. SiCPPS müssen zu jeder Zeit Sicherheit und Korrektheit gewährleisten. Dies gilt auch für alle Modelle, die SiCPPS-Artefakte und deren Variabilität darstellen [11]. Selbst bei einem hohen Automatisierungsgrad (vgl. RG2) können leicht Inkonsistenzen in Variabilitätsmodelle eingeführt werden. Bestehende Arbeiten zur Überprüfung der Konsistenz von Design- bzw. Variabilitätsmodellen und Software-Engineering-Artefakten [5, 13, 56] könnten ein vielversprechender Ansatzpunkt sein. Die Definition von Konsistenzeinschränkungen kann im Kontext von SiCPPS besonders herausfordernd sein, vor allem, wenn Stakeholder, die nicht aus dem Software-Engineering kommen, Einschränkungen, zum Beispiel als Logische Ausdrücke, definieren müssen. Dies motiviert eine domänenspezifische Sprache, vielleicht eine, die an verschiedene (Gruppen von) Benutzern angepasst werden kann. Außerdem müssen wir einen besonderen Schwerpunkt auf die Nutzbarkeit der Werkzeugunterstützung legen [45].

(RG7) SiCPPS Evolution/Round-trip Engineering. In der Praxis ist es kaum möglich, Kundenanforderungen allein durch die Wiederverwendung bestehender Artefakte zu befriedigen weil Kunden spezifische Anforderungen haben, vor allem im Kontext von SiCPPS. Neu entwickelte (projektspezifische) Artefakte haben jedoch das Potenzial, auch in zukünftigen Projekten nützlich (und wiederverwendet) zu werden. Es ist daher essentiell, den vollen Round-Trip zu unterstützen, d.h. zu entscheiden, welche neu entwickelten Artefakte dieses Potenzial haben und diese dann auch richtig in die Platform bzw. Produktlinie zu integrieren. Dies ist ein wichtiger Aspekt zur Unterstützung der Produktlinienevolution. In einem SiCPPS-Kontext muss eine Evolutionsunterstützung darüber hinaus die Heterogenität von (neu entwickelten) Artefakten und deren Abhängigkeiten berücksichtigen.

5 Forschungsagenda

Wir planen, die im vorigen Abschnitt diskutierten Forschungsziele mit dem in Abb. 4 dargestellten Arbeitsplan im Rahmen des Christian Doppler Labors Mastering Variability in Software-intensive Cyber-physical Production Systems (VaSiCS), in Zusammenarbeit mit einem Industriepartner anzugehen. Wir werden unsere Forschung auf die bestehenden SiCPPS Entwicklungsartefakte unseres Industriepartners stützen, die individuell von Personen aus verschiedenen beteiligten Disziplinen entwickelt und gewartet werden. Explizite Variabilitätsmodelle werden vom Industriepartner derzeit nicht verwendet. Variabilitätsinformationen sind vor allem in den Köpfen der beteiligten Ingenieure vorhanden, aber auch in verschiedenen Spreadsheets und Konfigurationsdateien dokumentiert, die uns zur Analyse und Nutzung zur Verfügung stehen. Zusätzlich haben verschiedene Abteilungen bereits diverse eigene Werkzeuge entwickelt, die sie bei ihrer täglichen Arbeit unterstützen. Wir betrachten diese Werkzeuge, und insbesondere die von ihnen produzierten Daten, als einen sehr relevanten Input, um die Variabilität zu modellieren. Diese Fallstudie ist somit eine sehr gute Grundlage für die Evaluierung unserer Forschung und für die Entwicklung erster Prototypen.

Abb. 4.
figure 4

Forschungsansatz

Full size image

Ein wichtiger erster Schritt in unserer Agenda besteht darin, die Variabilität der von unserem Industriepartner entwickelten und gepflegten SiCPPS zu erheben und zu modellieren. Zu diesem Zweck planen wir Top-Down-Variabilitätsanalysen [40] und Bottom-Up-Variabilitätsanalysen [12, 24] von bestehenden Artefakten. Um sicherzustellen, dass sich unsere Forschung nicht nur auf die SiCPPS eines einzigen Partners konzentriert, planen wir, mindestens ein weiteres, von einer anderen Firma entwickeltes System zu analysieren.

Basierend auf diesen Untersuchungen werden wir den vorhandenen Quellcode der SiCPPS unseres Industriepartners analysieren und abgeschlossen Module und deren Abhängigkeiten identifizieren [54]. Wir werden Modellierungsansätze für SiCPPS Steuerungssoftware entwickeln, welche die Modularität und Entkopplung von Komponenten unterstützen, die für die Beherrschung der Variabilität erforderlich sind [32, 51]. Dies bedeutet auch Refactoring Methoden zur Umwandlung der bestehenden Modelle in modulare Architekturen als Grundlage für die Variabilitätsmodellierung und -analyse zu entwickeln [50, 53]. Zusätzlich werden wir die wichtigsten Domänenmodelle für die Extraktion des Wissens aus den bestehenden technischen Modellen der verschiedenen Disziplinen überprüfen, um das SIM [22, 37] abzuleiten. Wir planen, einen iterativen Ansatz zu verfolgen, d.h. mit jedem integrierten Modell wird das SIM weiter ausgebaut.

Basierend auf den definierten Modellen werden wir an der Entwicklung von geeigneten Werkzeugen arbeiten, um (i) SiCPPS-Zielartefakte zu generieren und zu konfigurieren, (ii) vorhandene Artefakte automatisch zu analysieren, um unsere Modelle zu befüllen und (iii) die Konsistenz der Modelle zu überprüfen. Wir werden auf bestehenden Forschungsarbeiten zu Feature-Facets [28], Feature-Identifikation und -Extraktion [1, 30, 47], Constraint-Extraktion [35, 55], und Feature-Modell-Synthese [29, 49] zur (halbautomatischen) Extraktion von Variabilitätsinformationen aufbauen und diese anpassen. Wie wir festgestellt haben, ist es in der Industrie üblich, für jeden Kunden spezifische Artefakte zu entwickeln (und dies auch noch „vor Ort“/bei der Inbetriebnahme), daher ist es wichtig, den „Round-Trip“ zu unterstützen und zu identifizieren, welche neu entwickelten Artefakte für neue Kunden wiederverwendet werden können und Teil der Platform bzw. Produktlinie werden sollen. Damit kann mit der Zeit der Wiederverwendungsgrad erhöht werden und der Aufwand für projektspezifische Entwicklungen reduziert werden.

Das Feedback unseres Industriepartners, durch wissenschaftliche Kollaborationen und von der Forschungsgemeinschaft wird uns helfen, unsere Pläne weiter zu verfeinern. Als ersten Meilenstein werden wir einen prototypischen SiCPPS-Modellierungsansatz mit Unterstützung für die Generierung und Konfiguration ausgewählter SiCPPS-Artefakten entwickeln, der nach zwei Jahren erreicht werden soll. Anschließend werden wir den Ansatz auf weitere Artefakttypen und andere SiCPPS unseres Industriepartners sowie auf mindestens ein weiteres, nicht von unserem Industriepartner entwickeltes SiCPPS verallgemeinern. Parallel dazu werden wir an Schnittstellen/Werkzeugen für Anwender, Unterstützung für automatisches Variability Mining und Mapping, Konsistenzprüfung und Evolution/Roundtrip Engineering arbeiten (Aktionen 7-10). Als zweiten Meilenstein werden wir einen werkzeuggestützten Ansatz zur Beherrschung der Variabilität in SiCPPS, einschließlich Unterstützung für automatisches Variability Mining und Mapping, Konsistenzprüfung und Evolution/Roundtrip Engineering vorstellen.

6 Zusammenfassung

In diesem Beitrag haben wir beschrieben, warum der Umgang mit Variabilität in SiCPPS in der Praxis eine Herausforderung darstellt. Es mangelt an systematischen Ansätzen, Methoden und Lösungen. Wir haben die damit verbundenen Forschungsprobleme diskutiert, insbesondere (i) die prekäre Abhängigkeit von implizitem Expertenwissen; (ii) die unzureichende Automatisierungsunterstützung; (iii) die Schwierigkeiten bei der Bewertung der Auswirkungen von (geänderten) Anforderungen und Artefakten; (iv) den Umgang mit voneinander abhängigen Artefakten und Daten in verschiedenen technischen Disziplinen; und (v) den Umgang mit Inkonsistenzen. Basierend auf diesen Herausforderungen haben wir unsere Forschungsziele und Forschungsagenda skizziert. Konkret planen wir in unserem langfristigen Forschungsprojekt Christian Doppler Labor VaSiCS die Entwicklung eines werkzeuggestützten Ansatzes zur Beherrschung von Variabilität in SiCPPS, einschließlich Unterstützung für automatisiertes Variability Mining und Mapping, Konsistenzprüfungen und Evolution/Roundtrip Engineering.