Zusammenfassung
Die Zusammenarbeit von Fachexperten in einem heterogenen Entwicklungsumfeld im Industrie 4.0 Kontext bringt neben dem verstärkten Bedarf an effizientem Datenaustausch auch Herausforderungen und neue Möglichkeiten an Fachbereiche übergreifenden Maßnahmen der Qualitätssicherung zur Verbesserung der Projekt-, Prozess- und Produktqualität mit sich. Dieses Kapitel beschreibt Bedarfe an Methoden zur Fachbereiche übergreifenden Qualitätssicherung sowohl für Ingenieure als auch für Projekt- und Qualitätsmanager und stellt Konzepte und Lösungsansätze anhand exemplarischer Industrieprototypen dar, etwa effizientes Änderungsmanagement über Fachbereichsgrenzen, Mechanismen zum effizienten und qualitätsgesicherten Datenaustausch basierend auf AutomationML Integrationslösungen, die selektive Überwachung von kritischen Projektparametern (etwa mit dem Multi-Model-Dashboard) oder übergreifende Projektbeobachtung mit dem Engineering Cockpit. Basierend auf integrierten Daten können diese Ansätze helfen, Fehler und Inkonsistenzen in Planungsdaten unterschiedlicher Fachbereiche schneller und effizienter zu finden und einen schnellen Überblick über den aktuellen Projektstatus zu erhalten.
Schlüsselwörter
1 Einleitung
Abgestimmte und konsistente Engineering-Pläne bilden die Grundlage für die erfolgreiche Abwicklung von Planungsprojekten von industriellen Anlagen oder Produktionssystemen (Kap. Prozessunterstützung durch Integrationsplattform für anlagenmodellorientiertes Engineering, Kap. Digitale Durchgängigkeit des Engineers automatisierter Produktionsanlagen als Säule von Industrie 4.0, Drath 2010) entlang der Wertschöpfungskette (VDI/VDE 2014). In der industriellen Praxis sind in vielen Fällen heterogene Entwicklungslandschaften mit einer Vielzahl unterschiedlicher Software-Werkzeuge und Datenmodelle, etwa für Elektrik, Mechanik, oder Software, im Einsatz; eine nahtlose Zusammenarbeit der Fachbereiche und der Abgleich unterschiedlicher Engineering-Pläne sind meist nicht oder nur eingeschränkt möglich (Fay et al. 2013). Ein manueller Datenabgleich oder der Einsatz von Behelfslösungen (etwa spezifische Datenbank- oder Software-Lösungen, die durch lokale Experten als individuelle Unterstützung für den Datenaustausch erstellt und verwendet werden) ist jedoch meist zeitaufwändig, fehleranfällig und bringt mitunter ein hohes Risiko für den Projekterfolg mit sich. Maßnahmen der Qualitätssicherung können helfen, Fehler – speziell in Fachbereiche übergreifenden Datenmodellen – frühzeitig zu finden und dadurch das Risiko für den Projekterfolg zu minimieren (Biffl et al. 2011).
Ergänzend zu funktionalen Anforderungen an Software-Werkzeuge im Entwicklungsprozess (Schmidt et al. 2014 und Kap. Prozessunterstützung durch Integrationsplattform für anlagenmodellorientiertes Engineering) ergeben sich auch Bedarfe an die Qualitätssicherung, wie beispielsweise (a) die Sicherung einer durchgängigen Qualität der Ergebnisse einzelner Fachbereiche; (b) die effiziente Überwachung von kritischen Projekt- und Produktparametern, deren aktuelle Daten aus unterschiedlichen Werkzeugen stammen; oder (c) die effiziente Sammlung und Analyse von Projektdaten für Projektbeobachtung und Projektsteuerung. Je nach Rolle oder Projektphase sind unterschiedlichste Informationen erforderlich: während Ingenieure einzelner Fachbereiche etwa an der Konsistenz innerhalb ihrer Pläne interessiert sind und über notwendige Änderungen möglichst zeitnahe informiert werden wollen, interessieren sich Systemintegratoren für die Konsistenz der Daten und Konzepte an den Schnittstellen zwischen unterschiedlichen Fachbereichen. Projekt- und Qualitätsleiter möchten etwa die Häufigkeit von Änderungen an Konzepten in einzelnen Gewerken analysieren und, darauf aufbauend, das Risiko für das Gesamtprojekt einschätzen können – zentrale Herausforderungen, die ohne Mechanismen für einen effizienten Datenaustausch oder ohne geeignete Maßnahmen der Qualitätssicherung nicht oder nur schwer realisierbar sind. Abb. 1 illustriert einen vereinfachten Entwicklungsprozess nach VDI/VDE 2206 sowie ausgewählte Projektrollen und deren Bedarfe an Qualitätssicherungsmaßnahmen.
Aus diesem Prozessmodell können folgende Ebenen der Qualitätssicherung abgeleitet werden: (1) fachbereichsspezifische Qualitätssicherung, (2) Qualitätssicherung für integrierte Anlagemodelle oder übergreifende Datenmodelle und (3) Mechanismen zur Sicherstellung der Projekt- und Prozessqualität auf Managementebene. Diese unterschiedlichen Ebenen können im Anlagen-Engineering unterschiedlich adressiert werden.
-
1.
Fachbereichsspezifische Qualitätssicherung . Diese Ebene nutzt im Wesentlichen Funktionalitäten, die durch verwendete Software-Werkzeuge, etwa für Maschinenbau, Elektrotechnik oder Softwaretechnik, bereitgestellt werden. Diese Maßnahmen der Qualitätssicherung, wie etwa Konsistenzprüfungen innerhalb eines spezifischen Engineering-Plans eines Fachbereichs, sind meist isoliert und verwenden das Datenmodell, das durch das Werkzeug vorgegeben wird. Meist gibt es aber keine Überprüfungen über Werkzeuggrenzen hinweg. All-in-One Lösungen (also Werkzeug-Suiten, die Funktionalitäten mehrerer Fachbereiche zur Verfügung stellen, siehe Kap. Prozessunterstützung durch Integrationsplattform für anlagenmodellorientiertes Engineering) können aufgrund ihres gemeinsam genutzten Datenmodells übergreifende Prüfungen ermöglichen (Fay et al. 2013). Beispielsweise ermöglichen das EPLAN Engineering CenterFootnote 1 und der SIMATIC Automation DesignerFootnote 2 – basierend auf einem gemeinsamen Datenmodell – durchgängiges Engineering mit einheitlicher Dokumentation und Standardisierung durch wiederverwendbare Komponenten. Die Realisierung von übergreifenden Maßnahmen der Qualitätssicherung, speziell auch die Einbindung externer Werkzeuge, muss meist individuell angepasst werden und erfordert meist einen hohen Aufwand.
-
2.
Um die Qualität des integrierten Anlagenmodells sicherstellen zu können, gibt es Methoden, wie etwa Reviews und Inspektionen (Rösler et al. 2013), die eine Prüfung auf Konsistenz und das Finden von Fehlern systematisch erleichtern. Diese Reviews und Inspektionen werden meist durch Experten anhand der verfügbaren Pläne, etwa Dokumente oder ausgedruckte Pläne und Modelle, durchgeführt. Durch diesen Bedarf an erfahrenen Experten (die Expertise eines Experten sollte zumindest zwei der betroffenen Fachbereiche abdecken) und den meist manuellen Ansätzen sind derartige Maßnahmen aufwändig und auch fehleranfällig.
-
3.
Die Projekt- und Prozessqualität muss durch Projekt- und Qualitätsleiter geplant, überprüft und eingeschätzt werden können, um ein effizientes Projekt- und Qualitätsmanagement zu ermöglichen. Dazu sind integrierte Daten oder Reports erforderlich, die den aktuellen Stand des Projektes widerspiegeln und bei Bedarf effizient zur Verfügung gestellt werden können. In vielen Projekten mit heterogenen Datenquellen ist diese Sicht auf die Projektdaten nur aufwändig herzustellen, da Daten erst manuell oder mit Behelfslösungen zusammengetragen und ausgewertet werden müssen. Bei All-in-One Lösungen sind integrierte Sichten möglich, sofern sie auf dem gemeinsamen Datenmodell basieren.
Ein effizienter Datenaustausch bzw. ein integriertes Datenmodell in einer Wertschöpfungskette ist eine zentrale Anforderung im Umfeld von Industrie 4.0 (VDI/VDE 2014), um die Qualität der Projekte, Produkte und Prozesse sicherstellen zu können. Ein integriertes Anlagenmodell mit entsprechenden Zugriffsmöglichkeiten auf spezifische Daten eines Fachbereichs kann zusätzlich genutzt werden, um eine effiziente Qualitätssicherung auf unterschiedlichen Planungsebenen zu ermöglichen.
Ausgehend von wichtigen Projektrollen und ausgewählten Bedarfen an Methoden der Qualitätssicherung (Abschn. 2) werden in Abschn. 3 integrierte Daten und Anlagenmodelle als Grundlage für übergreifende Methoden der Qualitätssicherung diskutiert. Die Abschn. 4 - 6 zeigen Konzepte und Prototypen für ausgewählte Methoden zur Verbesserung der Produkt-, Prozess- und Projektqualität auf Projekt- und Organisationsebene. Abschn. 4 beschäftigt sich fokussierten Inspektionen und Integrationstests auf Basis von integrierten Anlagendaten. Abschn. 5 beschreibt das Multi-Model-Dashboard (MMD) zur selektiven Definition und Beobachtung kritischer Projektparameter und technischer Rahmenbedingungen. Das Engineering-Cockpit (Abschn. 6) ermöglicht eine laufende Projektbeobachtung auf Projektebene zur Steuerung des Projekts und als Grundlage für Verbesserungsprozesse auf Organisationsebene. Abschließend fasst Abschn. 7 die wesentlichen Aspekte aus dem Blickwinkel der Qualitätssicherung zusammen und gibt einen Ausblick auf vielversprechende künftige Entwicklungen.
2 Projektrollen und Bedarfe
In einer Wertschöpfungskette (VDI/VDE 2014) im verteilten und heterogenen Entwicklungsumfeld sind zahlreiche Rollen involviert, die unterschiedliche Ziele verfolgen und daher unterschiedliche Bedarfe an effizientem Datenaustausch und an effizienter Qualitätssicherung haben. In Abb. 1 sind wichtige Projektrollen auf unterschiedlichen Ebenen des Entwicklungsprozesses ersichtlich, die sich nicht nur auf die eigentliche Projektarbeit beziehen, sondern auch Geschäftsfelder einer Organisation und Kundenbedarfe umfassen. Wichtige Gruppen von Projektrollen umfassen dabei (a) das eigentliche Engineering-Projekt, in dem Kunde, Anlagenbauer, Fachexperten unterschiedlicher Disziplinen und gegebenenfalls weitere Unterauftragnehmer involviert sind. Aufgrund der Projektstruktur und Projektgröße sind typischerweise auch (b) Gesetzgeber, unterschiedliche Werkzeughersteller und Lieferanten im Entwicklungsprozess zu berücksichtigen. Nach Fertigstellung der Anlage und während des Betriebs der Anlage kommen weitere Projektrollen für Betrieb, Wartung und gegebenenfalls Weiterentwicklung der Anlage dazu. Integrierte Daten helfen dabei, die Bedarfe dieser unterschiedlichen Projektrollen auch aus dem Blickwinkel der Qualitätssicherung zu adressieren.
Im Folgenden werden ausgewählte Bedarfe aus der Sicht eines Engineering-Projekts mit Schwerpunkt auf die Qualitätssicherung betrachtet, die ein Engineering-Team (Fachexperten aus unterschiedlichen Bereichen) sowie Projekt- und Qualitätsleiter aus Managementsicht betreffen. Der Einsatz von Qualitätssicherungsmaßnahmen auf Werkzeugebene ist meist ein zentraler Bestandteil der eingesetzten spezialisierten Werkzeuge; individuelle Funktionalitäten werden meist durch diese Werkzeuge bereitgestellt. Der Einsatz unterschiedlicher und heterogener Werkzeuge erfordert aber integrierte Datenmodelle. Basierend auf diesen integrierten Datenmodellen ergeben sich Bedarfe an die Qualitätssicherung für (a) die Zusammenarbeit der unterschiedlichen Fachbereiche und (b) für die Projektbeobachtung über Werkzeuggrenzen hinweg zur Verbesserung der Projekt-, Produkt- und Prozessqualität.
Abb. 2 gibt einen Überblick dieser Bedarfe im Anlagen-Engineering aus dem Blickwinkel der Qualitätssicherung und Tab. 1 illustriert den Nutzen für ausgewählte Projektbeteiligte.
B1. Bedarf an effizienter Unterstützung bei der Durchführung von Reviews und Inspektionen . Um Engineering-Pläne aus unterschiedlichen Fachbereichen auf Konsistenz und Fehler zu überprüfen, sind typischerweise Fachexperten erforderlich, die zumindest zwei der involvierten Fachbereiche gut kennen. Speziell bei großen Anlagen oder umfangreichen Engineering-Plänen erfordern diese meist manuell (oder mit Behelfslösungen) durchgeführten Reviews meist hohe Aufwände, sind fehleranfällig und beinhalten ein Risiko für den Projekterfolg. Automatisierte Prüfungen können ebenfalls für die Fehlererkennung eingesetzt werden, sind aber in vielen Fällen an ein Werkzeug oder Datenmodell gekoppelt. Außerdem ist semantische Heterogenität und komplexes Wissen über die Zusammenhänge nicht oft explizit verfügbar und daher nur schwer automatisierbar. Es ist aber möglich, Fachexperten auf mögliche Zusammenhänge und Problemstellungen hinzuweisen, um die Arbeit der Experten möglichst effizient zu gestalten. Methoden für Reviews und Inspektionen haben den Vorteil, dass sie unabhängig von Datenformaten und Werkzeugen eingesetzt werden können und benötigtes Expertenwissen durch das Inspektionsteam eingebracht wird. Integrierte Daten oder Datenmodelle können zusätzlich dabei helfen, gezielt Änderungen oder Inkonsistenzen aufzuzeigen (Fokussierte Inspektion), um die Effizienz des Review-Prozesses deutlich zu steigern (Winkler und Biffl 2015).
B2. Bedarf an Integrationstests über Fachbereichs- und Werkzeuggrenzen. Während Review und Inspektionsmethoden weitgehend ohne Werkzeugunterstützung auskommen, erfordern Tests in der Regel eine passende Werkzeug- und Testumgebungen. Schnittstellen, die in Engineering-Plänen der jeweiligen Fachbereiche festgelegt werden, können automatisch und früh im Entwicklungsprozess getestet werden. Voraussetzung dafür sind integrierte Daten bzw. Datenmodelle. Beispielsweise erfolgt eine Überprüfung, ob alle Sensoren/Aktoren einer Anlage auch korrekt mit entsprechenden Software-Variablen verbunden sind, in der Regel erst während der Testphase (z. B. Factory Test) oder während der Inbetriebnahme (z. B. Commissioning), also sehr spät in der Wertschöpfungskette. Eine frühe und automatische Überprüfung (End-to-End-Test ) über die richtig geplante Verdrahtung (sowohl innerhalb von Plänen eines Fachbereichs aber auch über Fachbereichsgrenzen hinweg) kann jedoch derartige Fehler frühzeitig erkennen, die Produkt- und Qualität steigern und Kosten reduzieren.
B3. Bedarf an einfachen Mechanismen für die Beobachtung kritischer Produkt-, Prozess- und Projektparameter. Die gezielte Überwachung von Produkt-, Prozess- und Projektparametern kann sowohl Ingenieure als auch das Management dabei unterstützen, Abweichungen – speziell in Fachbereiche übergreifenden Engineering-Plänen – effizient zu erkennen und korrigierend einzugreifen. Beispielsweise kann bei der Planung einer neuen Produktionshalle bzw. Produktionsanlage die maximal zulässige Gesamtlast einer Bodenplatte durch den Architekten in einer Gebäudespezifikation definiert sein. Unterschiedliche Maschinen oder Geräte mit individuellen Massen (etwa spezifiziert in Datenblättern verschiedener Hersteller) werden in unterschiedlichen Plänen durch den Anlagenbauer oder Prozesstechniker auf dieser Bodenplatte platziert. Ob das zulässige Gesamtgewicht überschritten wird, muss – ohne integrierte Daten – manuell ermittelt werden. Um die maximale Tragfähigkeit zu definieren und automatisch zu überprüfen, müssen jene (ausgewählten) Parameter zugänglich gemacht werden, die für die Berechnung relevant sind – etwa die individuellen Massen der Maschinen und Geräte aus den unterschiedlichen Engineering-Plänen oder Datenblättern und die maximal zulässige Gesamtlast (aus der Gebäudespezifikation). Durch den Vergleich (Summe der einzelnen Massen und zulässige Maximallast) kann unmittelbar entschieden werden, ob diese Bedingung erfüllt oder verletzt wird (Biffl et al. 2014b). Für einen Projektleiter kann der Aufwand pro Projektphase interessant sein. Auch hier können ausgewählte Parameter helfen, Daten aus unterschiedlichen Quellen (z. B. Aufwandsaufzeichnungen unterschiedlicher Projektpartner) zu aggregieren und im Hinblick auf Projektplanungsdokumente auszuwerten (Biffl et al. 2014a).
B4. Bedarf an effizienten Mechanismen für die Beobachtung von Projektstatus und Projektfortschritt . Für eine ganzheitliche Betrachtung des Projekts aus der Perspektive des Projekt- und Qualitätsmanagements sind einzelne Datenpunkte nur eingeschränkt nützlich. Diese können bei Bedarf zusätzlich verwendet werden, um kritische Parameter zu überwachen. Für eine ganzheitliche Betrachtung ist allerdings der Gesamtstatus des Projektes erforderlich. Oft ist der Projektstatus (über Fachbereichsgrenzen) aber nur mit zusätzlichem Aufwand zu ermitteln; die Anzahl von Änderungen, die Ursache von Änderungen ist meist nur durch einzelne Fachexperten zu erfahren. Integrierte Datenmodelle können helfen, derartige Informationen automatisch zu erhalten und systematisch auszuwerten (Engineering Cockpit ). Durch diese effiziente Projektbeobachtung können auch Risiken, z. B. durch eine hohe Anzahl unerwarteter Änderungen an Modellelementen in einer Projektphase, minimiert werde (Moser et al. 2011).
3 Integrierte Datenmodelle und Daten
Die Grundlage für Fachbereiche übergreifende Funktionalitäten, die speziell auch im Bereich der Qualitätssicherung eine wichtige Rolle spielen, bildet die Möglichkeit, Daten zwischen Werkzeugen effizient auszutauschen – eine zentrale Forderung im Industrie 4.0 Umfeld (VDI/VDE 2014). Die Punkt-zu-Punkt Integration , also die direkte Vernetzung von zwei oder mehreren Werkzeugen, ist eine einfache Möglichkeit, Daten zwischen beteiligten Werkzeugen auszutauschen. Allerdings können nur „integrierte“ Werkzeuge miteinander interagieren – Änderungen an Datenmodellen, Werkzeugen oder Werkzeug-konfigurationen (etwa verursacht durch Aktualisierungen oder neue Releases von Werkzeugen) erfordern meist hohe Aufwände für Erweiterungen und Wartung. Außerdem erlauben derartige Integrationslösungen meist nur einen geringen Grad an Flexibilität, d. h. neue Werkzeuge oder zusätzlich benötigte Daten können nur mit verhältnismäßig hohem Aufwand integriert werden (Biffl et al. 2009).
Ein naheliegender Ansatz ist es daher, nur eine minimale Menge an Daten (ein „gemeinsames Konzept “), die von den beteiligten Fachbereichen/Werkzeugen auch tatsächlich benötigt wird, für die Synchronisierung zu verwenden anstatt alle Daten aller beteiligten Werkzeuge zu integrieren. Dieser Ansatz ermöglicht es, die Verbindung zwischen unterschiedlichen Fachbereichen/Werkzeugen über dieses gemeinsame Konzept herzustellen. Alle anderen fachbereichsspezifischen Daten verbleiben in den lokalen Datenmodellen, auf die bei Bedarf über das gemeinsame Konzept zugegriffen werden kann Moser und Biffl (2012). Beispielsweise stellt im Bereich der Planung von Wasserkraftwerken ein „Signal“ ein derartiges gemeinsames Konzept dar: In der Elektrik repräsentiert ein Signal etwa einen Hardware-Pin, der über eine definierte Hardwareadresse verfügt. In der Software ist dieses Signal eine „Software-Variable“, die konkrete Daten für die Steuerungssoftware benötigt und nutzt. Das gemeinsame Konzept „Signal“ ermöglicht den Datenaustausch zwischen den Fachbereichen „Elektrik“ und „Software“. Sollten weiterführende Informationen, wie etwa der Gerätetyp, der sich hinter dem Hardware-Pin verbirgt, oder Klassen, die in der Software verwendet werden, benötigt werden, können diese Informationen bei Bedarf über die gemeinsamen Konzepte (als Verbindungsglied) aus den jeweils lokalen Datenmodellen gewonnen werden.
Diese Vorgehensweise bedeutet aber auch, dass diese gemeinsam genutzten Daten bzw. die gemeinsamen Konzepte in beteiligten Werkzeugen geeignet identifiziert werden müssen. Die Projektbeteiligten müssen sich daher am Beginn eines Projektes auf eine Menge an Datenelementen verständigen, diese aufeinander abbilden und in weiterer Folge für die Synchronisierung und den Datenaustausch verwenden. Abb. 3 illustriert dieses Konzept, in dem drei unterschiedliche Fachbereiche (Mechanik, Elektrik und Software) über gemeinsame Konzepte (überlappende Bereiche im Zentrum der Abbildung) verbunden werden. Die Punkte in den überlappenden Bereichen kennzeichnen einzelne Datenpunkte zwischen den Fachbereichen. Diese Bereiche eignen sich aber nicht nur für die Synchronisierung von Fachbereichen und den Datenaustausch zwischen den Werkzeugen, sondern ermöglichen auch eine effizientere Fehlersuche über Fachbereiche und Werkzeuggrenzen hinweg.
Das Vorliegen der Daten in einem maschinell lesbaren und standardisierten Format ist die Voraussetzung für einen effizienten Datenaustausch. Dafür kann beispielsweise das standardisierte Datenaustauschformat AutomationML (Automation Markup Language, AML) gut verwendet werden (DIN EN 62714 2015; Drath 2010, Kap. AutomationML in an Nutshell). AutomationML ist in der Lage, CAEX (Anlagentopologie und mechanische Komponenten), Collada (Geometrie und Kinematik) und auch PLCOpen XML (Software bzw. das Verhalten) zu beschreiben. Auf der Basis von AutomationML ist es somit möglich, eine herstellerunabhängige Integrationsplattform zur Verfügung zu stellen, die einen effizienten Datenaustausch ermöglicht. Eine auf diesem Konzept aufgebaute Integrationslösung ist etwa der AML Hub (siehe Kap. AutomationML in an Nutshell), die AutomationML als Datenaustauschformat nutzt und zusätzliche Funktionalität für die Synchronisierung unterschiedlicher Fachbereiche aber auch Funktionalitäten für die Qualitätssicherung bereitstellt.
Im Folgenden werden einige Anwendungsfälle aus dem Bereich der Qualitätssicherung beschrieben, die auf den gemeinsamen Konzepten bzw. dem AML Hub aufgebaut sind.
4 Fokussierte Inspektionen und Integrationstests
Ausgehend von Best-Practices im Software-Engineering können Methoden der Qualitätssicherung, etwa Reviews, Inspektionen (Rösler et al. 2013) und Tests (Myers 2011) genutzt werden, um Engineering-Prozesse im Anlagenbau zu unterstützen.
Software Inspektionen (Rösler et al. 2013) können Fachexperten dabei helfen, unterschiedlichste Artefakte, wie Engineering-Pläne oder Spezifikationen gezielt nach Fehlern zu durchsuchen. Spezielle Lesetechniken helfen dabei, den Schwerpunkt auf spezielle Fehlertypen oder Anwendungsfälle zu legen. Unterschiedliche Perspektiven ermöglichen eine differenziertere Sicht auf die zu untersuchenden Objekte (Aurum et al. 2002). Diese Perspektiven entsprechen den unterschiedlichen Fachbereichen (etwa Perspective-based Reading Techniques ) und ermöglichen eine gezielte Fehlersuche aus der jeweiligen Sicht. Basierend auf den gemeinsamen Konzepten und automatisierten Änderungsmanagementprozessen (Winkler et al. 2011), die im Rahmen der Synchronisierung von Engineering-Plänen unterschiedlicher Fachbereiche durchgeführt werden, kann der Fokus der Inspektion auf konkrete Änderungen, Inkonsistenzen oder – allgemeiner – auf Abweichungen zwischen den Plänen gelegt werden. Anstatt sämtliche Pläne und Dokumente auf Konsistenz und Fehler zu untersuchen, kann somit der Schwerpunkt auf diese Abweichungen gelegt werden. Abweichungen können dabei sowohl Änderungen als auch mögliche Fehler sein. Im Rahmen eines Reviews oder einer Inspektion können diese effizient analysiert werden.
Dadurch ergibt sich typischerweise neben einer effizienteren und zielgerichteten Fehlersuche auch eine massive Reduktion von Aufwand und Kosten bei der Fehlersuche (Winkler und Biffl 2015). Der Einsatz von Inspektionen in einem AML Hub (Biffl et al. 2015) erlaubt es zusätzlich, auch fehlende Informationen aufzudecken, etwa fehlende PLC-Komponenten oder elektrische Komponenten, die zwar in der Anlagentopologie verfügbar sind, aber noch nicht umgesetzt sind. Durch die Verfügbarkeit von Verknüpfungen, die über den AML Hub hergestellt werden können (Biffl et al. 2015), ist im Bedarfsfall auch eine Navigation nicht nur zu den betroffenen Plänen sondern auch zu den relevanten Positionen innerhalb dieser Pläne möglich (Mordinyi et al. 2012).
Im Software Engineering werden Software Tests typischerweise eingesetzt, um Fehler in Source-Code zu finden (Myers 2011). Auch im Software Engineering unterscheidet man unterschiedliche Testebenen, wie Modul- und Komponententests, Integrationstests und System- oder Akzeptanztests (siehe auch das Prozessmodell nach VDI 2206 2004). Während einzelne Komponenten isoliert getestet werden können (und häufig auch durch die Werkzeuge des jeweiligen Fachbereichs unterstützt werden), kommen Integration- und Systemtests meist im Factory Test oder während der Kommissionierungsphase zur Anwendung. Fehler in diesen Phasen verursachen meist hohe Aufwände und Kosten und führen zu Projektverzögerung.
Daher können Testansätze genutzt werden, um Engineering-Pläne – basierend auf einem integrierten Anlagenmodell und gemeinsamen Konzepten – frühzeitig durchzuführen. Beispielsweise ermöglicht der End-to-End Test die Überprüfung (Winkler und Biffl (2012)), ob sämtliche Sensoren/Aktoren (Fachbereich: Mechanik) auch tatsächlich korrekt verkabelt sind (Fachbereich: Elektrik) und über eine passende Software-Variable (Fachbereich: Software) ausgelesen bzw. angesteuert werden.
Abb. 4 illustriert das Konzept des End-to-End Integrationstests (Hardware-Sensor zu Software Variable). Beispielsweise kann frühzeitig erkannt werden, dass Klemme D1 mit keinem Sensor verbunden ist, allerdings zu einer Software-Variable (Variable_D) weiterverbunden ist. Klemme D2 ist mit zwei Sensoren verbunden (S1 und S4), was vermutlich zu Fehlfunktionen führen wird. Klemme D3 ist zwar mit einem Sensor verbunden, wird aber nicht weiterverarbeitet. Die Software Variable_E (D4) wird in einer Kontrollapplikation verwendet, aber nicht mit Daten versorgt, da keine Verbindung zu einem Sensor existiert. Durch ein integriertes Anlagenmodell, wie es beispielsweise durch gemeinsame Konzepte oder den AML Hub bereitgestellt wird, können Möglichkeiten geschaffen werden, um derartige Fehler frühzeitig, effizient und automatisch zu erkennen. Definierte Abfragen über das integrierte Anlagenmodell ermöglichen eine Vorselektion auf mögliche Fehler, die dann anschließend mit einer fokussierten Inspektion genauer untersucht werden können.
5 Beobachtung kritischer Prozess- und Projektparameter
In verteilten und heterogenen Entwicklungsumgebungen mit komplexen Analgenmodellen stellt sich die Frage, wie kritische Parameter, etwa Key Performance Indicators (KPI) (Reichert et al. 2010), die auf mehrere und unterschiedliche Datenmodelle zugreifen müssen, effizient beobachtet werden können. Diese KPIs können einerseits technische Fragen im Engineering-Projekt, wie etwa die Überwachung der maximalen Tragfähigkeit einer Bodenplatte, die maximale Stromaufnahme der Gesamtanlage oder die Kühlkapazität einer Klimaanlage adressieren aber auch Managementfragen, wie etwa Aufwände, Kosten und Projektzustände beantworten. In heterogenen Entwicklungsumgebungen mit lose verbundenen Software-Werkzeugen sind diese Fragestellungen, die meist mehrere Fachbereiche betreffen, nur mit hohem und zum Teil manuellem Aufwand zu beantworten, da weder die konkreten Parameter bekannt sind, unterschiedlich benannt werden (semantische Heterogenität), und Datenpunkte über unterschiedliche und lokale Datenmodelle verstreut sind.
Abb. 5 illustriert die wesentlichen Bedarfe und Herausforderungen im Anlagen-Engineering, in dem Parameter und Rahmenbedingungen zentral in einem Team Workspace definiert werden sollen:
-
(1)
Wie können Parametern und Rahmenbedingungen einfach und effizient definiert werden, um sie im Gesamtprojekt zu nutzen?
-
(2)
Wie kann die Datensammlung und Integration über lokale und heterogene Modelle effizient organisiert werden?
-
(3)
Wie bekommt der Projektmanager Zugang zu verstreuten Engineering-Daten, ohne die Fachexperten regelmäßig mit der Datensammlung, Transformation und Analyse zu beauftragen?
Gemeinsame Konzepte bzw. integrierte Anlagenmodelle bilden die Grundlage für diesen Anwendungsfall. Neben einem konkreten Hilfsmittel (etwa ein Werkzeug, das im Fall des Multi-Model-Dashboard s als Webanwendung realisiert wurde), ist auch eine Prozessdefinition erforderlich, um einerseits die Parameter und Rahmenbedingungen über Fachbereichsgrenzen hinweg zu ermitteln, aufeinander abzustimmen (Definitionsphase) und entsprechend auszuwerten (Evaluierungsphase). Dieser Prozess, der anhand eines Industrieprototyps illustriert wird, beinhaltet folgende grundlegenden Schritte (Biffl et al. 2014a):
-
1.
Definitions- und Abstimmungsphase (auf Projekt- bzw. Teamebene). In einem ersten Schritt müssen die relevanten Daten (Bedingungen und benötigte Parameter) verfügbar gemacht werden. Dazu wird etwa ein Publish/Subscribe Verfahren verwendet (Eugster et al. 2003); ein Datenlieferant stellt seine Daten bereit, ein Datenkonsument kann diese Daten abonnieren und verwenden. Dazu müssen aber erst die erforderlichen Projekt- und Prozessbedingungen festgelegt werden. Relevante Projektrollen (z. B. Fachexperten, Systemintegratoren, Projekt- und Qualitätsmanager) definieren ihren konkreten Bedarf an Bedingungen, die überprüft werden sollen. Diese Bedingungen stammen meist aus Planungsdokumenten und Spezifikationen (etwa maximale Tragfähigkeit einer Bodenplatte, maximaler Energieverbrauch oder maximale Kühlkapazität). Aus diesen Bedingungen lassen sich die dafür notwendigen Parameter ableiten (etwa Masse, Energieverbrauch, oder Kühlbedarf der einzelnen Maschinen). Daraus ergibt sich eine Anfrage bei den Datenlieferanten, relevante Parameter und Datenpunkte bereit zu stellen. Angefragte und verfügbare Daten werden mittels Webapplikation dargestellt und können – sofern sie verfügbar sind – abonniert werden. Die Abstimmung, ob und welche Daten wie verfügbar sind, kann beispielsweise auch durch Verhandlungsprozesse wie Easy-Win-Win (Grünbacher 2000) unterstützt werden. Offen ist allerdings, wie verfügbare Daten tatsächlich genutzt werden können und wie einzelne Datenpunkte semantisch aufeinander abgebildet werden können.
-
2.
Linking, Mapping und Transformation von Datenmodellen. In einem zweiten Schritt müssen also die konkreten Datenmodelle und Datenpunkte (Parameter und Bedingungen) identifiziert und miteinander verbunden werden. Die abgestimmten Parameter und Rahmenbedingungen (im gemeinsamen Design Workspace) werden durch Experten mit lokalen Datenmodellen und Datenpunkten verbunden und gegebenenfalls transformiert (Linking, Mapping und Transformation). Dazu werden die benötigten lokalen Dateien in einem gemeinsam nutzbaren Speicherbereich oder einem Versionierungssystem abgelegt (Team Workspace). Die Verbindung zu einzelnen Datenpunkten innerhalb einer Datei hängt vom Datenformat ab: Bei Spreadsheet-Lösungen erfolgt die Verbindung zu einem konkreten Datenpunkt über eine Verknüpfung zu einer spezifischen Zelle innerhalb des Spreadsheets; bei strukturierten Dokumenten kann über eine spezielle Kennzeichnung (Tag) ein Datenelement identifiziert und dessen Inhalt verwendet werden; in Engineering-Plänen kann meist auf konkrete Parameter oder Attribute direkt zugegriffen werden. Eine Änderung an einem Datenelement ist also unmittelbar im Team-Workspace ersichtlich.
-
3.
Änderungserkennung in lokalen Datenmodellen . Durch diese Verbindungen sind Änderungen einzelner Parameter unmittelbar beobachtbar und können genutzt werden, sofern der betroffene Parameter durch eine Projektrolle abonniert wurde (subscribe).
-
4.
Evaluierung von Rahmenbedingungen . Die Kernaufgabe des Multi-Model-Dashboards (MMD), das als Webanwendung konzipiert wurde, umfasst die automatische Überprüfung von definierten Parametern und Rahmenbedingungen und Alarmierung bei Verletzung der Rahmenbedingungen. Neben der direkten Beobachtung ausgewählter Parameter (Schritt 3) ist die Auswertung von Bedingungen, die aus Berechnungen ermittelt werden, eine zentrale Aufgabe des MMD. Beispielsweise darf die maximale Tragfähigkeit einer Bodenplatte nicht überschritten werden (d. h. die Summe der Einzelmassen von Maschinen darf die maximale Tragfähigkeit nicht überschreiten); der gesamte Energieverbrauch oder der erforderliche Kühlbedarf dürfen die festgelegten Rahmenbedingungen nicht überschreiten. Je nach Anforderung können die Bedingungen mittels mathematischer Formel aus einzelnen verfügbaren Parametern berechnet und für die Evaluierung eingesetzt werden. Eine Verletzung der Rahmenbedingung hat zur Folge, dass der Beobachter unmittelbar informiert wird (über das MMD bzw. per E-Mail) und so rasch reagieren kann.
-
5.
Die Ergebnisse dieser Evaluierung werden in einem Dashboard, dem MMD, bereitgestellt und stehen den individuellen Projektrollen nach Bedarf zur Verfügung. Dabei werden nur diejenigen Informationen visualisiert, die für die jeweilige Projektrolle relevant ist, d. h. die abonniert wurden.
Abb. 6 zeigt eine exemplarische Lösung eines Industrieprototypen (Biffl et al. 2014a, b) mit den unterschiedlichen Sichtweisen des MMD. Die individuellen Parameter und Variablen werden über einen Publish/Subscribe Mechanismus durch die Projektbeteiligten angefordert, definiert und abonniert (Position 1). Im folgenden Schritt (Position 2) werden diese benötigten Parameter mit lokalen Konzepten durch Experten verbunden, in dem relevante Dateien im Team Workspace verfügbar gemacht und mit individuellen Datenpunkten semantisch verbunden werden. Diese Verbindung ermöglicht es, relevante Parameter, sofern sie abonniert wurden, laufend zu beobachten (Position 3). In dieser Sicht ist sowohl eine Liste mit verfügbaren (abonnierten) Parametern als auch eine Sicht auf ausgewählte Detaildaten möglich, d. h. aktuelle Werte, Ursprung der Daten (Datei und konkrete Position innerhalb der Datei), Datentyp, sowie Zeitpunkt der letzten Aktualisierung. Zur Evaluierung von Rahmenbedingungen ist es notwendig, einzelne Parameter mittels Formeln zu verbinden um das Ergebnis der Bedingung zu berechnen, etwa eine Summenbildung zur Ermittlung der Gesamtmasse der unterschiedlichen Maschinen und die Überprüfung der Bedingung, ob die maximale Tragfähigkeit überschritten wurde. Einige Beispiele für definierte Rahmenbedingungen sind in Abb. 6 (Position 3) ersichtlich. Die kontinuierliche Überwachung kritischer Projektparameter und Evaluierung von Bedingungen erfolgt mit jedem Update zumindest einer Datei im lokalen Workspace, synchronisiert mit dem Team Workspace. Ein Beispiel einer Evaluierung ist in Abb. 6 (Position 5) ersichtlich. Dabei wird sowohl das Ergebnis der Evaluierung, als auch der Zeitpunkt der letzten Aktualisierung dargestellt. Je nach Konfiguration des MMD, kann der Projektteilnehmer etwaige Alarmierungen nicht nur im MMD beobachten sondern auch explizit per E-Mail darüber informiert werden.
Das Multi-Model-Dashboard bietet somit eine flexible Möglichkeit einer selektive Beobachtung von kritischen Projektparametern, sowohl auf technischer Ebene (Biffl et al. 2014b) als auch auf organisatorischer Ebene, etwa für das Projektmanagement (Biffl et al. 2014a). Gemeinsame Konzepte oder integrierte Anlagenmodelle, wie sie beispielsweise durch AutomationML bereitgestellt werden, bilden die Grundlage für einen flexibel definierbaren Datenaustausch. Durch die Beobachtung von kritischen Parametern und die Überprüfung von Produkt-, Prozess- und Projektbedingungen sind etwa Fachexperten in der Lage, rasch auf Änderungen reagieren zu können oder Abweichungen zu erkennen. Projekt- und Qualitätsleiter können geeignete organisatorische KPIs definieren und beobachten, zeitnahe auf aktuelle Projektgegebenheiten reagieren und somit auch das Risiko für den Projekterfolg reduzieren.
6 Projektbeobachtung für Projekt- und Qualitätsmanagement
Die selektive Beobachtung einzelner Projektparameter hilft sowohl Fachexperten als auch Projekt- und Qualitätsleitern bei der Risikominimierung und dem Auffinden von punktuellen Abweichungen. Eine zentrale Aufgabe beinhaltet aber auch eine laufende Beobachtung des Projektstatus und des Projektfortschritts, etwa ob alle Meilensteine innerhalb des Projektes erreicht wurden. Einen wertvollen Beitrag zur Risikoeinschätzung liefern etwa auch Aussagen über Änderungen, wie die Art von Änderungen, deren Auswirkung auf andere Fachbereiche oder die Verursacher von Änderungen in unterschiedlichen Projektphasen oder im Zeitverlauf. Beispielsweise können sich häufige und vor allem späte Änderungen massiv auf den Projektfortschritt und den Projekterfolg auswirken. Typischerweise beruhen diese Informationen auf Experteneinschätzungen (d. h. Erfahrungen aus früheren Projekten) oder müssen mühsam von unterschiedlichen Fachexperten meist manuell oder mit Behelfslösungen zusammengetragen werden. Integrierte Daten mit Versionsinformationen erlauben eine zeitnahe Auswertung über Werkzeug- und Fachbereichsgrenzen hinweg und ermöglichen somit eine bessere Einschätzung des Projektstatus und Projektfortschritts.
Basierend auf einem umgesetzten Änderungsmanagement im Anlagen-Engineering von Wasserkraftwerken (Winkler et al. 2011) werden Signaldaten verwendet, um Änderungen im Projektverlauf transparent zu machen. Dabei werden pro Projektphase (etwa Design, Konstruktion, Umsetzung, Test, Kommissionierung und Betrieb) Planungsdaten aus unterschiedlichen Fachbereichen häufig (d. h. etwa 1–2 mal pro Woche) synchronisiert, um Fehler und Inkonsistenzen frühzeitig zu finden, Änderungen und deren Auswirkungen zu erkennen und betroffene Fachbereiche zeitnah über erforderliche Anpassungen zu informieren. Ergänzend zu diesen technischen Abstimmungen können diese Daten genutzt werden, um eine Aussage über Projektfortschritt und Qualität des Gesamtprojektes zu liefern.
Basierend auf integrierten Daten und einem integrierten Anlagenmodell eines Wasserkraftwerks zeigt Abb. 7 einen Auszug aus einem Industrieprototypen: Die Anzahl der Engineering-Objekte (in diesem Fall „Signale“) werden pro Anlagenteil im Zeitverlauf dargestellt (Position 1). Wichtig ist auch die zu erwartende Gesamtanzahl der Signale für das Gesamtprojekt (ein Beitrag aus einem Planungsdokument, einer Spezifikation oder eines Angebots). Daraus kann der Projekt- oder Qualitätsleiter Rückschlüsse auf den Projektstatus und den Projektfortschritt ableiten. Diese Ergebnisse können einfach durch Auswertungen (Queries) über das integrierte Anlagenmodell ermittelt werden. Weiterführende Auswertungen können etwa Detailinformationen (Drill-Down) für ausgewählte Komponenten, die Anzahl der Engineering-Objekte pro Projektphase, den Verursacher von Änderungen (etwa durch welchen Fachbereich bzw. durch welches Werkzeug die Änderungen eingepflegt wurden), die Art von Änderungen (etwa, neue, geänderte oder gelöschte Engineering-Objekte), oder die Akzeptanz von Änderungen durch ein Inspektionsteam (d. h. ob Änderungen angenommen oder abgelehnt wurden) umfassen. Zusätzlich zu diesen Auswertungen, die auf technische Eigenschaften des Projektes abzielen, sind im Engineering Cockpit auch Funktionalitäten vorgesehen, die den Anwender über Ereignisse, etwa Meilensteine oder kommende Ereignisse, informieren (Position 2) oder den Verfügbarkeitsstatus der Projektmitglieder zeigen (Position 3) – typische Anwendungsfälle aus bekannten sozialen Plattformen und Kommunikationswerkzeugen.
Somit kann das Engineering Cockpit als zentrale Steuereinheit für das Projekt gesehen werden, das sowohl durch Projekt- und Qualitätsleiter für eine effiziente Projektbeobachtung eingesetzt werden kann, als auch für Fachexperten nützlich ist, um Informationen zu Engineering-Plänen, die für den jeweiligen Fachbereich relevant sind, zu erhalten. Beispielweise können auch Review- und Inspektionsprozesse, das Multi-Model-Dashboard oder Benachrichtigungswerkzeuge, wie Issue-Tracker oder spezifischer Auswertungen, zentral in das Engineering Cockpit einfach und effizient integriert und das Projekt damit gesteuert werden. Basierend auf integrierten Daten bzw. integrierten Anlagenmodellen kann das Engineering Cockpit im Kontext von Industrie 4.0 eingesetzt werden, um die Projekt- und Qualitätsplanung und -beobachtung zu unterstützen.
7 Zusammenfassung und Ausblick
Industrie 4.0 erfordert den übergreifenden Austausch von Engineering-Daten entlang einer Werkzeugkette (VDI/VDE 2014), der nicht nur für die technische Umsetzung von Anlagenplanungsprojekten sondern auch für Maßnahmen der Qualitätssicherung effizient eingesetzt werden kann. Aufbauend auf dem Prozessmodell nach VDI 2206 (VDI 2206 2004) und integrierten Daten bzw. Anlagenmodellen wurden in diesem Kapitel konkrete Bedarfe und Lösungsmöglichkeiten für die Qualitätssicherung aus unterschiedlichen Sichten beschrieben. Dabei wurden sowohl das frühe Erkennen von Fehlern und Abweichungen als auch die Beobachtung von kritischen Produkt-, Prozess- und Projektparametern – zentrale Herausforderungen im Anlagen-Engineering – diskutiert. Integrierte Daten- und Anlagenmodelle bilden die Grundlage für erweiterte Maßnahmen der Qualitätssicherung zur Steigerung der Produkt-, Prozess- und Projektqualität. AutomationML stellt – als Beschreibungssprache für Engineering-Daten – eine vielversprechende Möglichkeit dar, um einen effizienten Datenaustausch im Sinn von Industrie 4.0 zu ermöglichen (Drath 2010) und dadurch auch neue und effizientere Maßnahmen der Qualitätssicherung zu unterstützen.
Durch integrierte Datenmodelle (Moser und Biffl 2012; Drath 2010) und abgestimmte Änderungsmanagementprozesse (Winkler et al. 2011) können Änderungen, Abweichungen und mögliche Fehler automatisiert erkannt werden. Bewährte Methoden der Qualitätssicherung, etwa Reviews und Inspektionen (Rösler et al. 2013) können eingesetzt werden, um fokussiert diese Änderungen, Abweichungen und mögliche Fehler zu analysieren (Winkler und Biffl 2015). Dadurch ist einerseits eine massive Kostenreduktion (Untersuchung von relevanten Anlagenteilen anstatt der Gesamtanlage) als auch eine Qualitätsverbesserung zu erwarten. Ein End-to-End Integrationstest kann in weiterer Folge helfen, fehlerhafte bzw. unvollständige oder falsche Planungsdaten zwischen unterschiedlichen Fachbereichen aufzudecken (Winkler et al. 2011). Das Multi-Model-Dashboard (MMD) ermöglicht die Definition und selektive Beobachtung von kritischen Produkt-, Prozess- und Projektparametern und unterstützt Fachexperten und Manager dabei, punktuelle Änderungen rasch und zuverlässig zu erkennen und dadurch das Risiko zu minimieren. Um den Überblick über das Gesamtprojekt (aus Projekt- oder Qualitätsmanagementsicht) zu erhalten, hilft das Engineering Cockpit dabei, sowohl den Projektstatus als auch die Summe und die Auswirkung von Änderungen über das Gesamtprojekt transparent zu machen. Dadurch sind Rückschlüsse auf das jeweilige Projekt im Hinblick auf Projektbeobachtung und Risikomanagement möglich. In weiterer Folge kann auch das Projekt-Wissen genutzt werden, um Verbesserungsprozesse auf organisatorischer Ebene anzustoßen.
Integrierte Daten bzw. Anlagenmodelle und Maßnahmen der Qualitätssicherung können – ganzheitlich betrachtet – einen wesentlichen Beitrag zur Verbesserung von Engineering-Projekten leisten. VDI 3695 (VDI/VDE 3695 2010, 2014) stellt dafür einen organisatorischen Rahmen zur Verfügung (siehe Abb. 8). Der untere Teil von Abb. 8 zeigt wesentliche Schritt im Projektablauf, die durch integrierte Daten (1 und 1a) unterstützt werden können. Diese integrierte Datensicht ermöglicht auch die schnelle und effiziente Erhebung von aktuellen Projektstatusinformationen für Projektplanung und Projektcontrolling. Im Kontext von VDI 3695 (VDI/VDE 3695 2010, 2014) ergeben sich somit Verbesserungen auf Projektebene (2) in Bezug auf Produktivität, Qualität und Zusammenarbeit zwischen Fachbereichen und ermöglichen ein ganzheitliches und besseres Verständnis des Gesamtprojekts. Aufbauend darauf erschließen sich auch neue Möglichkeiten der Nutzung von Engineering-Wissen, sowohl auf Projekt- und Produktebene als auch auf Organisations- und Domänenebene (Best-Practice Ansätze) zur (Wieder-)Verwendung in unterschiedlichen Projekten einer Organisation (3). Durch eine integrative Betrachtung von Engineering-Daten und Engineering-Prozessen können Verbesserungsinitiativen für Organisationen angestoßen, geplant und effizient evaluiert werden.
Ausblick. Die in diesem Kapitel beschriebenen Bedarfe, Anwendungsfälle und Konzepte können in konkreten Anwendungsumfeldern genutzt werden, um einerseits lokale Bedarfe zu erheben und andererseits existierende Lösungen zu bewerten. Aus Diskussionen mit Fachexperten ergeben sich laufend neue Bedarfe und Herausforderungen im integrierten Anlagen-Engineering und in der Qualitätssicherung, die durch integrierte Daten und Anlagenmodelle entlang der Wertschöpfungskette gelöst werden können. Basierend auf dem standardisierten Datenaustauschformat AutomationML können die vorgestellten Konzepte und Lösungsansätze zur Verbesserung und Weiterentwicklung von Qualitätssicherungsmaßnahmen genutzt werden.
Im Kontext der kontinuierlichen Verbesserung nach VDI 3695 ergeben sich Möglichkeiten zur Prozessverbesserung auf Projektebene. Basierend auf der Verfügbarkeit von vernetzten und integrierten Daten können Projektdaten effizient gesammelt, aggregiert und ausgewertet werden um, gemeinsam mit Engineering-Wissen, die Grundlage für Verbesserungsinitiativen für Prozesse und Methoden auf Organisationsebene zu schaffen.
Notes
- 1.
EPLAN: www.eplan.at.
- 2.
SIMATEC Automation: http://w3.siemens.com/mcms/automation/de.
Literatur
Aurum A, Petersson H, Wohlin C (2002) State-of-the-art: software inspection after 25 years. J Softw Test Verif Reliab 12(3):133–154
Biffl S, Schatten A, Zoitl A (2009) Integration of heterogeneous engineering environments for the automation systems lifecycle. In: Proceedings of the 7th international conference on industrial informatics (INDIN), S 576–581
Biffl S, Moser T, Winkler D (2011) Risk assessment in multi-disciplinary (software+) engineering projects. Int J Softw Eng Knowl Eng 21(2):211
Biffl S, Winkler D, Mordinyi R, Scheiber S, Holl G (2014a) Efficient monitoring of constraints in a multi-disciplinary engineering project with semantic data integration in the multi-model dashboard process. In: Proceedings of the 19th IEEE international conference on Emerging Technologies and Factory Automation (ETFA), IEEE, S 1–10
Biffl S, Lüder A, Schmidt N, Winkler D (2014b) Early and efficient quality assurance of risky technical parameters in a mechatronic design process. In: Proceedings of the 40 annual conference of the IEEE industrial electronics society (IECON), S 2544–2550
Biffl S, Lüder A, Mätzler E, Schmidt N, Wimmer M (2015) Linking and versioning support for automationML: a model-driven engineering perspective. In: Proceedings of the 13th IEEE international conference on industrial informatics (Indin), S 1–8
DIN EN 62714 (2015) „Datenaustauschformat für Planungsdaten industrieller Automatisierungssysteme – Automation Markup Language – Teil 1: Architektur und allgemeine Festlegungen“, DIN EN 62714-1:2015-06, IEC 62714-1:2014, EN 62714-1:2014
Drath R (Hrsg) (2010) Datenaustausch in der Anlagenplanung mit AutomationML: Integration von CAEX, PLCOpenXML und COLLADA, Springer Heidelberg Dordrecht London New York. doi: http://dx.doi.org/10.1007/978-3-642-04674-2, ISBN 978-3-642-04673-5
Eugster PT, Felber PA, Guerraoui R, Kermarrec A-M (2003) The many faces of publish/subscribe. ACM Comput Surv 35(2):114–131
Fay A, Biffl S, Winkler D, Drath R, Barth M (2013) A method to evaluate the openness of automation tools for increased interoperability. In: Proceedings of the 39th annual conference of the IEEE industrial electronics society (IECON), IEEE, S 6842–6847
Grünbacher P (2000) Collaborative requirements negotiation with EasyWinWin. In: Proceedings of the 23rd international workshop on database and expert systems applications, S 954–958
Kovalenko O, Serral E, Sabou M, Ekaputra FJ, Winkler D, Biffl S (2014) Automating cross-disciplinary defect detection in multi-disciplinary engineering environments. In: Proceedings of 19th international conference on knowledge engineering and knowledge management (EKAW)
Mordinyi R, Moser T, Winkler D, Biffl S (2012) Navigating between tools in Heterogeneous automation systems engineering landscapes. In: Proceedings of the 38th annual conference of the IEEE industrial electronics society (IECON), IEEE, S 6182–6188
Moser T, Biffl S (2012) Semantic integration of software and systems engineering environments. IEEE Trans Syst Man, Cybernetics, Part SMC-C (Application and Reviews), Special issue on Semantics-enabled Software Engineering 42(1):38–50, IEEE, ISSN:1094-6977
Moser T, Mordinyi R, Winkler D, Biffl S (2011) Engineering project management using the engineering cockpit. In: Proceedings of the 9th international conference on industrial informatics (INDIN), S 579–584
Myers GJ (2011) The art of software testing, 3. Aufl. Wiley, ISBN: 978-1118031964
Reichert R, Kunz A, Moryson R, Wegener K (2010) A key performance indicator system of process control as a basis for relocation planning. In: Proceedings of the 43rd CIRP conference on manufacturing systems, S 805–812
Rösler P, Schlich M, Kneuper R (2013) „Reviews in der System- und Softwareentwicklung: Grundlagen, Praxis, kontinuierliche Verbesserung“, 1. Aufl. Heidelberg, ISBN:978-3864900945
Schmidt N, Lüder A, Biffl S, Steininger H (2014) Analyzing requirements on software tools according to functional engineering phase in the technical systems engineering process. In: Proceedings of the 19th IEEE international conference on emerging technologies and factory automation (ETFA), IEEE, S 1–8
VDI 2206 (2004) „Entwicklungsmethodik für mechatronische Systeme“, VDI-Gesellschaft Entwicklung Konstruktion Vertrieb (VDI-EKV)VDO 2206, Juni 2004
VDI/VDE (2014) „Industrie 4.0 – Wertschöpfungsketten“, VDI/VDE Gesellschaft Mess- und Automatisierungstechnik, Statusreport April 2014
VDI/VDE 3695 (2010, 2014) „Engineering von Anlagen – Evaluierung und optimieren des Engineerings“, Blatt 1 „Grundlagen und Vorgehensweisen“ und Blatt 2 „Themenfeld Prozesse“ (jeweils 2010-11), Blatt 3 „Themenfeld Methoden“ und Blatt 4 „Themenfeld Hilfsmittel“, sowie Blatt 5 „Themenfeld Aufbauorganisation“ (2014-11), VDI/VDE Gesellschaft Mess- und Automatisierungstechnik
Winkler D, Biffl S (2012) Improving quality assurance in automation systems development projects. In: Quality assurance and management. Book Chapter, http://www.intechopen.com/books/quality-assurance-and-management/improving-quality-assurance-in-automation-systems-development-projects http://dx.doi.org/10.5772/33487
Winkler D, Biffl S (2015) Focused inspection to support quality assurance in automation systems engineering environments. In: Research preview paper accepted at PROFES 2015, December 2–4, 2015, Bozen/Bolzano, Italy & Technical report IFS-CDL-15-02, September 2015. http://qse.ifs.tuwien.ac.at/publication/IFS-CDL-15-02.pdf
Winkler D, Moser T, Mordinyi R, Sunindyo WD, Biffl S (2011) Engineering object change management process observation in distributed automation systems projects. In: Proceedings of the 18th EuroSPI conference on systems software and service process improvement, communication in computer and information science, Springer, S 73–85
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
Rights and permissions
Copyright information
© 2015 Springer-Verlag Berlin Heidelberg
About this entry
Cite this entry
Winkler, D., Mordinyi, R., Biffl, S. (2015). Qualitätssicherung in heterogenen und verteilten Entwicklungsumgebungen für industrielle Produktionssysteme . In: Vogel-Heuser, B., Bauernhansl, T., ten Hompel, M. (eds) Handbuch Industrie 4.0. Springer NachschlageWissen(). Springer Vieweg, Berlin, Heidelberg. https://doi.org/10.1007/978-3-662-45537-1_89-1
Download citation
DOI: https://doi.org/10.1007/978-3-662-45537-1_89-1
Received:
Accepted:
Published:
Publisher Name: Springer Vieweg, Berlin, Heidelberg
Online ISBN: 978-3-662-45537-1
eBook Packages: Springer Referenz Technik und Informatik
Publish with us
Chapter history
-
Latest
Modellunterstützte Qualitätssicherung von Engineering-Daten industrieller Produktionssysteme- Published:
- 28 April 2020
DOI: https://doi.org/10.1007/978-3-662-45537-1_89-2
-
Original
- Published:
- 23 December 2015
DOI: https://doi.org/10.1007/978-3-662-45537-1_89-1