Univ.-Prof. Dr.-Ing. Birgit Vogel-Heuser FG Embedded Systems Elektrotechnik / Informatik II. AUTOMATION SYMPOSIUM Modularität und Wiederverwendung Effizienteres Engineering in der Automatisierungstechnik und für Eingebettete Systeme 26. Oktober 2006 Universität Kassel Univ.-Prof. Dr.-Ing. Birgit Vogel-Heuser FG Embedded Systems Elektrotechnik / Informatik II. AUTOMATION SYMPOSIUM - Tagesordnung - 09:15 h Anforderungen an das Engineering und Zielsetzung der Veranstaltung Prof. Birgit Vogel-Heuser, FG Eingebettete Systeme, Uni Kassel 09:30 h Effizienteres Engineering unterstützen durch Objektorientierung und UML – Stand der Technik David Friedrich, FG Eingebettete Systeme, Uni Kassel 10:15 h SysML- Der neue Standard zur Modellierung eingebetteter Systeme Andreas Korff, ARTiSAN 11:00 h Kaffeepause 11:30 h Nutzen und Konzepte des objektorientierten Engineering mit CoDeSys 3.0 D. Hess, 3S 12:00 h PLCopen – for efficiency in automation E. van der Wal, PLCopen, Niederlande 12:30 h Konfigurieren von modular aufgebauten Anlagen und Maschinen mit einem Anlagen- und Maschinenkonfigurator M. Bogeljic, innotec, Österreich 13:00 h Mittagspause – Möglichkeit zur Laborbesichtigung 14:00 h Effizienzsteigerung im Engineering – Konzepte im Projekt EUPASS Dr.-Ing. Josef Papenfort, Beckhoff GmbH 14:30 h Mit SysML und UML von Ideen zu validierten Systemen Matthias Linhardt 15:00 h Kaffeepause 15:30 h Workshop: Erfahrungen mit UML und Objektorientierung alle Teilnehmer 16:30 h Abschlussdiskussion und Verabschiedung Möglichkeit zur Laborbesichtigung Inhaltsverzeichnis Referent Seite Anforderungen an das Engineering und Zielsetzung der Veranstaltung Prof. Dr. Birgit Vogel-Heuser 1 - 3 FG Eingebettete Systeme Uni Kassel Effizienteres Engineering unterstützen durch Objektorientierung und UML – Stand der Technik David Friedrich 4 - 18 FG Eingebettete Systeme Uni Kassel SysML- Der neue Standard zur Modellierung eingebetteter Systeme Andreas Korff 19 - 36 ARTiSAN Software Tools GmbH Nutzen und Konzepte des objektorientierten Engineering mit CoDeSys 3.0 Dieter Hess 37 - 45 3S Smart Software Solutions GmbH Konfigurieren von modular aufgebauten Anlagen und Maschinen mit einem Anlagen- und Maschinenkonfigurator Marco Bogeljic 46 - 53 Innotec GmbH Effizienzsteigerung im Engineering Konzepte im Projekt EUPASS Dr. Josef Papenfort 54 - 74 Elektro Beckhoff GmbH Mit SysML und UML von Ideen zu validierten Systemen Matthias Linhardt 75 - 82 Univ.-Prof. Dr.-Ing. Birgit Vogel-Heuser FG Embedded Systems Elektrotechnik / Informatik II. AUTOMATION SYMPOSIUM - Referentenverzeichnis - Prof. Dr.-Ing. Birgit Vogel-Heuser FG Eingebettete Systeme - FB Elektrotechnik / Informatik - Universität Kassel Wilhelmshöher Allee 73, 34121 Kassel vogel-heuser@uni-kassel.de Dipl.-Ing. David Friedrich FG Eingebettete Systeme - FB Elektrotechnik / Informatik - Universität Kassel Wilhelmshöher Allee 73, 34121 Kassel friedrich@uni-kassel.de Andreas Korff ARTiSAN Software Tools GmbH Eupener Straße 135-137, 50933 Köln andreas.korff@artisansw.com Dipl.-Ing. Dieter Hess 3S Smart Software Solutions GmbH Memminger Str. 151, 87439 Kempten/Allgäu d.hess@3S-software.com Eelco van der Wal PLCopen PO Box 3009, NL 4200 EA Gorinchem, The Netherlands evdwal@plcopen.org Marko Bogeljic innotec GmbH Schleppe Platz 5, A-9020 Klagenfurt, Austria marko.bogeljic@comos.at Dr.-Ing. Josef Papenfort Elektro Beckhoff GmbH Eiserstr. 5, 33415 Verl j.papenfort@beckhoff.com PD. Matthias Linhardt Am Horstfeld 1, 38154 Königslutter MLinhardt@t-online.de 1 Fo lie n ,2 4. 10 .2 00 6 13 :3 5 © E S 1 Prof. Dr.-Ing. Birgit Vogel-Heuser Embedded Systems Universität Kassel www.es.eecs.uni-kassel.de Was sind eingebettete Systeme? Ein eingebettetes System ist eine Hardware/Software Einheit, die über Sensoren und Aktoren mit einem Gesamtsystem verbunden ist und darin Überwachungs-, Steuerungs- bzw. Regelungsaufgaben übernimmt. In der Regel handelt es sich um reaktive, häufig auch um hybride verteilte Systeme mit Sicherheits- und Echtzeitanforderungen. (nach Broy) 2 Fo lie n ,2 4. 10 .2 00 6 13 :3 5 © E S 2 Prof. Dr.-Ing. Birgit Vogel-Heuser Embedded Systems Universität Kassel www.es.eecs.uni-kassel.de Rechner- und Kommunika- tionssystem Technischer Prozess Sensorsignale Steuersignale Menschen Uhrzeit Uhrzeit äußere Einflüsse Womit beschäftigen wir uns am Fachgebiet? Automatisierungsgerät 3 Fo lie n ,2 4. 10 .2 00 6 13 :3 5 © E S 3 Prof. Dr.-Ing. Birgit Vogel-Heuser Embedded Systems Universität Kassel www.es.eecs.uni-kassel.de Fachgebiet Eingebettete Systeme Fachbereich Elektrotechnik / Informatik Mitarbeiter des Fachgebiets • 8 wissenschaftliche Mitarbeiter (plus Leitung, Stand 1.8.2006) • 1 Laboringenieur • 1 Fachinformatiker • 2 Azubis Fachinformatiker • 1 Sekretariat • Labor mit Prozessmodell einer Sortieranlage (fertigungstechnischer Prozess) sowie diversen marktüblichen Automatisierungsgeräten (SPS, PLS, Soft-SPS, Embedded Systemen) sowie ECAE-Werkzeug 4 Fo lie n ,2 4. 10 .2 00 6 13 :3 5 © E S 4 Prof. Dr.-Ing. Birgit Vogel-Heuser Embedded Systems Universität Kassel www.es.eecs.uni-kassel.de Forschung Workflow, Wiederverwendung und Modularisierung ƒ Erfassung und Modellierung des Workflow zur Entwicklung eines durchgängigen Engineering- Konzeptes ƒ Analyse der Anwendung von Modularisierung und Modulbibliotheken Entwurfsmethoden für die Automatisierungstechnik ƒ Modellierung hybrider Prozesse mit verschiedenen Beschreibungsmitteln ƒ Vergleichende Evaluation von Beschreibungsmitteln für die Programmierung von Steuerungen unter dem Aspekt der leichten Erlernbarkeit und der Eignung für Ingenieure ƒ Entwicklung und Adaption von Methoden zur Softwarespezifikation für verteilte Echtzeitsysteme in der Prozessautomatisierung ƒ Automatische Codegenerierung aus der UML für die Steuerungsprogrammierung Agententechnologien ƒ Ermittlung von Konzepten und Methoden zur Anwendung der agentenorientierten Softwareentwicklung für flexible und verlässliche eingebettete Echtzeitsysteme 3D-Visualisierung industrieller Prozesse ƒ Interaktive 3D-Controls für die Prozessführung Networked control und Echtzeit bzw. Zuverlässigkeit ƒ Modellierung eines verteilten Ethernet-basierten Automatisierungssystems mit UML und Überprüfung des Zeitverhaltens mittels Model-Checking ƒ Entwicklung eines Konzeptes zur Rekonfiguration von Automatisierungssystemen (Industrie) ƒ … 5 Fo lie n ,2 4. 10 .2 00 6 13 :3 5 © E S 5 Prof. Dr.-Ing. Birgit Vogel-Heuser Embedded Systems Universität Kassel www.es.eecs.uni-kassel.de Anforderungen der Automatisierungstechnik im Maschinen- und Anlagenbau Hart bzw. weich / zeit- und ereignisgesteuerte SystemeEchtzeit Werkzeugkopplung, durchgängiges WerkzeugWerkzeugunterstützung Sequentiell, iterativ, SpezialistenteamsWorkflowaspekte Personalqualifikation Facharbeiter, Techniker, Ingenieure (Applikation, Systemspezialist) Modularität, Hierarchie, Wiederverwendung (Variantenbildung)Entwurf Projekt (Gesamter Lebenszyklus) Bedienen und Beobachten Zentral, dezentral, verteilt, agentenorientiert / Verteilung Systemarchitektur heterogen Speicherprogrammierbare Steuerungen, PC, Prozessrechner, MikrocontrollerHardwareplattform Softwareplattform Zuverlässigkeit diskret Batch [kontinuierlich] Betriebssystem (RTOS (proprietär)), Windows) Programmiersprache (C, IEC 61131-3, C++, Java, PEARL) Automatisierungs- system (Heterogen) Abbildung Zuverlässigkeitsaspekte (FMEA, FTA) Zustandsmodelle Zustandsmodelle [Übertragungsfunktionen] Prozess (Hybrid) Funktion / Notations-AspekteKategorie / Kriterium 1 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 1 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Effizienteres Engineering unterstützt durch Objektorientierung und UML – Stand der Technik – Effizienteres Engineering unterstützt durch bjektorientierung und U L – Stand der Technik – Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel Automation Symposium Modularität und Wiederverwendung – Effizienteres Engineering in der Automatisierungstechnik und für Eingebettete Systeme 26. Oktober 2006, Kassel 2 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 2 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Gliederung • Motivation – Engineering im Maschinen und Anlagenbau – Modularität und Wiederverwendung • UML als Modellierungsnotation in der Automatisierungstechnik – Beispielprozess – Use Case Diagramm – Klassendiagramm – Strukturdiagramm – Zustandsdiagramm • Evaluation der Anwendung der UML – Versuchsdesign – Ergebnisse • Zusammenfassung und Ausblick – Lessons learned 3 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 3 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Anforderungen der Automatisierungstechnik im Maschinen- und Anlagenbau Hart bzw. weich / zeit- und ereignisgesteuerte SystemeEchtzeit Werkzeugkopplung, durchgängiges WerkzeugWerkzeugunterstützung Sequentiell, iterativ, SpezialistenteamsWorkflowaspekte Personalqualifikation Facharbeiter, Techniker, Ingenieure (Applikation, Systemspezialist) Modularität, Hierarchie, Wiederverwendung (Variantenbildung)Entwurf Projekt (Gesamter Lebenszyklus) Bedienen und Beobachten Zentral, dezentral, verteilt, agentenorientiert / Verteilung Systemarchitektur heterogen Speicherprogrammierbare Steuerungen, PC, Prozessrechner, MikrocontrollerHardwareplattform Softwareplattform Zuverlässigkeit diskret Batch [kontinuierlich] Betriebssystem (RTOS (proprietär)), Windows) Programmiersprache (C, IEC 61131-3, C++, Java, PEARL) Automatisierungs- system (Heterogen) Abbildung Zuverlässigkeitsaspekte (FMEA, FTA) Zustandsmodelle Zustandsmodelle [Übertragungsfunktionen] Prozess (Hybrid) Funktion / Notations-AspekteKategorie / Kriterium 4 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 4 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Workflow-Analyse des Engineering im Maschinen- und Anlagenbau 5 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 5 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Ansatz des modularen Engineering Ein Gesamtsystem kann beschrieben werden als eine Zusammensetzung von Modulen, die über Schnittstellen mitein- ander gekoppelt sind. Ein Modul ist ein austauschbares, komplexes Teil eines Geräts oder einer Maschine, das eine geschlossene Funktionseinheit bildet. 6 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 6 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Modularität und Wiederverwendung - Zieleigenschaften von Varianten Gesucht sind Komponenten mit der Fähigkeit zur Variantenkonstruktion (Die UML-Syntax dient hier nur der Präsentation des Modells) Reduktion einer Vorlage Erweiterung einer Vorlage Nachträgliches Hinzufügen einer Funktion Installiertes Modul muss sich zur Vorlage eignen Vorlage Eingang 1 Eingang 2 Eingang 3 Eingang 4 Reduziertes Modul Eingang 3 Eingang 4 Teile der Vorlage sind ausgeblendet Vorlage Eingang 1 Eingang 2 Eingang 3 Eingang 4 Erweitertes Modul Eingang 5 Eingang 6 Vorlage wird ergänzt Nachtrag OnEíngang1Do() Vorlage Eingang 1 Eingang 2 Eingang 3 Eingang 4 Neue Funktion in implementiertes Modul Einkesselregler MaxReached() SetMax() Zweikesselregler SetMax() SetMax nutzt MaxReached SetMax nutzt geändertes MaxReached Änderungen fügen sich in den Kontext einer Komponente ein 7 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 7 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Motivation • Engineering Automatisierungstechnischer Systeme – ist Gewerkeübergreifend – ist zwangsweise sequentiell sondern hat parallele oder iterative Abläufe – erfordert den Einsatz verschiedenster Engineering-Tools, Schnittstellen meist proprietär oder nicht vorhanden • Hoher Kosten- und Zeitdruck erfordert den Einsatz von Modulen und Variantenkonstruktion ⇒ Es sind Beschreibungsmittel und Methoden notwendig, die diesen Anforderungen gerecht werden 8 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 8 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Motivation ⇒ Objekt-Orientierung und OO-Methoden sind nicht Gewerkespezifisch, sind für die Beschreibung von Modularität und Konstruktion von Varianten geeignet und können zur Werkzeugkopplung genutzt werden (OO-Metamodell) • Höhere Transparenz durch höheres Abstraktionsniveau zur Integration der verschiedenen Sichten • Erstellung des Modells (Automatisierungsaufgabe inklusive Sichten) mit einem Beschreibungsmittel • aber: IEC 61131 ist funktionsorientiert Frage ist ⇒ ob sich objekt-orientierte Ansätze (die Verwendung der UML) für eine Beschreibung eignen ⇒ ob sich aus dem Einsatz der UML Vorteile für die Programmierung von Speicherprogrammierbaren Steuerungen ergeben ⇒ wie die Anwender die UML zur Modellierung automatisierungstechnischer Systeme anwendet und sie bewertet 9 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 9 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Gliederung • Motivation – Engineering im Maschinen und Anlagenbau – Modularität und Wiederverwendung • UML als Modellierungsnotation in der Automatisierungstechnik – Beispielprozess – Use Case Diagramm – Klassendiagramm – Strukturdiagramm – Zustandsdiagramm • Evaluation der Anwendung der UML – Versuchsdesign – Ergebnisse • Zusammenfassung und Ausblick – Lessons learned – Weitere Aktivitäten 10 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 10 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Der Beispielprozess Das Labormodell stellt einen modular aufgebauten, fertigungstechnischen Prozess nach, bei dem Werkstücke auf bestimmte Kriterien geprüft und je nach Ergebnis dieser Prüfung mit einem Stempel bearbeitet oder direkt aussortiert werden. Das Modell verfügt über eine Vielzahl digitaler und analoger Sensoren und Aktoren welche für jedes Modul separat über eine definierte Schnittstelle zur Verfügung stehen. Die Steuerung erfolgt mit Hilfe mit einer IEC 61131-basierten Steuerung. Das Labormodell stellt einen modular aufgebauten, fertigungstechnischen Prozess nach, bei dem Werkstücke auf bestimmte Kriterien geprüft und je nach Ergebnis dieser Prüfung mit einem Stempel bearbeitet oder direkt aussortiert werden. Das Modell verfügt über eine Vielzahl digitaler und analoger Sensoren und Aktoren welche für jedes Modul separat über eine definierte Schnittstelle zur Verfügung stehen. Die Steuerung erfolgt mit Hilfe mit einer IEC 61131-basierten Steuerung. 11 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 11 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de UseCase – Diagramm Vereinzler Kran Stempel WS auslagern WS Transportieren WS Stempeln WS_bereitstellen WS_erkennen «include» «include» WS_abholen WS_abgeben Ziel_anfahren «include» «include» «include» «extend» WS_einfahren WS_ausfahren WS_pressen «include»«include» «include» «extend» 12 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 12 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Stempelanlage ::binärSensor boolean get_wert () ::analogSensor float get_wert () ::HydraulikZylinder ausfahren () einfahren () set_wert (p:integer) 13 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 13 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de ::Sensor get_wert () ::Aktor ::binärSensor boolean get_wert () ::analogSensor float get_wert () ::Motor drehe_rechts () drehe_links () ::HydraulikZylinder boolean aktiv boolean get_wert () boolean set_wert () ::Zylinder einfahren () ausfahren () ::Stempelzylinder ::Spannzylinder ::Stempel Stempel_beladen WS_einfahren () WS_ausfahren () WS_stempeln () abfr_stempel_beladen () pos_vorne 1 1 Druck WS_vorhanden 1 1 Stempel 1 1 Spanner 1 1 Pleuel pos_hinten Klassendiagramm Stempelanlage 14 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 14 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Struktur - Diagramm ::binärSensor boolean get_wert () ::Zylinder ::Spannzylinder pos_vorneWS_vorhanden 1 1 pos_hinten ::HydraulikZylinder ausfahren () einfahren () set_wert (p:integer) Spannzylinder WS_vorhanden : binärSensor pos_vorne : binärSensor : HydraulikZylinder pos_hinten : binärSensor B2 B1 S5 Y1 Y2 15 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 15 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Statechart Stempelanlage - Stempel Spanner_eingefahren Spanner_ausgefahren gestempelt warten auf Werkstück do : stempel_beladen:=abfr_stempel_beladen / WS_stempeln [true]/ /WS_ausfahren [stempel_beladen]/ WS_einfahren [not stempel_beladen]/ / ::Stempel stempel_beladen WS_einfahren () WS_ausfahren () WS_stempeln () abfr_stempel_beladen () warten auf Abholung do : stempel_beladen:=abfr_stempel_beladen 16 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 16 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Stempel und Spanner Spanner ausgefahren Spanner eingefahren [true]/ Return=false /Spanner.einfahren /Return:=true einfahrend eingefahren /pleuel.set_wert... [pos_hinten.get_wert]/ / Stempel: ws_einfahren() Zylinder: einfahren() Klasse Rolle 17 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 17 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Gliederung • Motivation – Engineering im Maschinen und Anlagenbau – Modularität und Wiederverwendung • UML als Modellierungsnotation in der Automatisierungstechnik – Beispielprozess – Use Case Diagramm – Klassendiagramm – Strukturdiagramm – Zustandsdiagramm • Evaluation der Anwendung der UML – Versuchsdesign – Ergebnisse • Zusammenfassung und Ausblick – Lessons learned 18 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 18 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Ziel der Evaluation Die Modellierung automatisierungstechnischer Systeme mit der UML konnte gezeigt werden, dennoch wird sie nur selten eingesetzt. Es sollen folgende Aspekte untersucht werden: - Anwendung der Modellierungsnotationen durch Nutzer - welche Diagrammarten werden verwendet, welche nicht - welche Probleme treten bei der Modellierung auf - welche Randbedingungen beeinflussen die Modellierung - Ermittlung messbarer Vorteile einer Modellierung im Bezug auf die Steuerungsprogrammierung - Überprüfung der Akzeptanz einer Modellierung bei den Nutzern => Untersuchung mit Hilfe von Laborexperimenten 19 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 19 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Die UML im Engineering Entwicklung des Versuchsdesigns ¾ Keine automatische Codegenerierung • Modell selbst erstellen - Fall: Konstrukteur (keine automatische Codegenerierung wegen Qualitätsmaß) • Vorgegebenes Modell - Fall: Inbetriebnehmer (Verständnis des Modells) ¾ Ohne Werkzeugunterstützung • Vorteil: keine Störeffekte durch Werkzeuge • Nachteil: Werkzeugunterstützung wesentlich für Akzeptanz ¾ Einfluss der Persönlichkeitsaspekte (Individualaspekte) sehr groß ⇒ Einteilung der Gruppenzuordnung (gleichmäßig) • Vorkenntnisse/Erfahrung: - Programmierung allgemein - Programmierung IEC 61131 - Modellierung (UML und andere) • Erhebung: Fragebogen (pre) - Z.T. Prüfungsergebnisse; Kenntnisse • Subjektive Einschätzung: Fragebogen (post) - Akzeptanz - Feedback zu Anwendbarkeit, Problemen (Verständnis / Anwendung) 20 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 20 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Ergebnisse (1) Ergebnis der Modellierung mit der Unified Modeling Language: Analyse und Bewertung der erstellten Modelle a) Konzentration auf wenige Diagrammformen • mit wenigen Ausnahmen wurde ausschließlich das dynamische Verhalten des Prozesses mit Hilfe von Zustandsdiagrammen beschrieben • wenige Probanden modellierten die Struktur des Prozesse mit Hilfe eines Klassen-/ Objektdiagramms • andere Diagramme wurden nicht verwendet b) Qualität der Modelle • Fehler in der Verwendung einzelner Modellelemente • Modelliertes Verhalten unvollständig / fehlerhaft • Geringe Detailtiefe in der Beschreibung des Prozesses • Wenig modularer Aufbau und Wiederverwendung von Modulen 21 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 21 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Einfluss der Modellierung auf die Steuerungsprogrammierung: Bewertung der erstellten Steuerungsprogramme mittels Codeinspektion c) Modular aufgebautes Programm • flache, wenig strukturierte Programme • keine Modularität in den Programmen der Gruppe ohne Modellierung erkennbar • nur die Probanden, die auch modular modellierten erstellten ein modulares Programm d) Zeitaufwand zur Programmierung der Steuerung • Bewertung: Anzahl realisierter Programmschritte in einer vorgegebenen Zeitspanne • Gruppen, die den Prozess vorab modellierten, erstellten einen geringeren Anteil des Gesamtprogramms Ergebnisse (2) 22 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 22 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Ergebnisse (3) Einfluss der Modellierung auf die Steuerungsprogrammierung: Bewertung der erstellten Steuerungsprogramme mittels Codeinspektion c) Fehlerrate bei der Programmierung der Steuerung • Bewertung: Anzahl fehlerfrei realisierter Schritte gemessen an der Gesamtzahl • über den gesamten Versuche eine relativ hohe Fehlerrate (50-70%) • Versuchsdesign 1: Höhere Fehlerrate bei Verwendung der UML (~70 %) als in der Vergleichsgruppe (~60 %) • Versuchsdesign 1: Geringere Fehlerrate bei Verwendung der UML (~60 %) als in der Vergleichsgruppe (~70 %) • Vergleich der Ergebnisse der UML-Gruppen aus Versuch 1 und 2 zeigt, dass die Modellqualität einen Einfluss auf das Ergebnis der Programmierung hat 23 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 23 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Ergebnisse (4) Bewertung der Modellierung durch den Anwender: Auswertung der durch die Probanden ausgefüllten Fragebögen f) Schwierigkeit der Anwendung der UML • Schwierigkeiten bei der Auswahl der geeigneten Diagramme • fehlende Praxis bei der Modellierung mit der UML • Gruppen die den Prozess nicht modellierten bewerteten die Aufgabe meist als schwieriger (Ausnahme: Auszubildende) 24 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 24 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Ergebnisse (4) Bewertung der Modellierung durch den Anwender: Auswertung der durch die Probanden ausgefüllten Fragebögen g) Bewertung der Anwendbarkeit der UML für die Modellierung der Steuerungs- aufgabe - Probanden bewerteten die Anwendung einer Modellierung als nützlich - Bereitschaft, bei einer ähnlichen Problemstellung erneut zu modellieren, war hoch 25 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 25 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Gliederung • Motivation – Engineering im Maschinen und Anlagenbau – Modularität und Wiederverwendung • UML als Modellierungsnotation in der Automatisierungstechnik – Beispielprozess – Use Case Diagramm – Klassendiagramm – Strukturdiagramm – Zustandsdiagramm • Evaluation der Anwendung der UML – Versuchsdesign – Ergebnisse • Zusammenfassung und Ausblick – Lessons learned 26 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 26 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Lessons learned (1) Unsicherheit bzw. fehlendes Wissen - über die zu modellierenden Aspekte des Automatisierungssystems - bei der Auswahl der Diagramme und der Reihenfolge der Anwendung Unsicherheit bzw. fehlendes Wissen - über die zu modellierenden Aspekte des Automatisierungssystems - bei der Auswahl der Diagramme und der Reihenfolge der Anwendung Unterstützung des Anwenders durch die Bereitstellung eines Leitfadens Unterstützung des Anwenders durch die Bereitstellung eines Leitfadens 27 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 27 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Lessons learned (2) übernommen entfallen hinzugefügt geändert übernommen diagram structure diagram behavioral diagram class diagram object diagram composition structure diagram component diagram deployment diagram package diagram use case diagram activity diagram state machine diagram interaction diagram sequence diagram communication diagram timing diagram interaction overview diagram instance structure diagram Timing-Sequencediagram Vielzahl an Diagrammen, die gleiche Information aus unter- schiedlichen Sichten und in unterschiedlichem Kontext darstellen Vielzahl an Diagrammen, die gleiche Information aus unter- schiedlichen Sichten und in unterschiedlichem Kontext darstellen Eingrenzung und Anpassung der zu verwendenden Diagramme für die Modellierung⇒ z. B. Ansatz der UML PA Eingrenzung und Anpassung der zu verwendenden Diagramme für die Modellierung z. B. Ansatz der UML PA 28 Fo lie n ,2 4. 10 .2 00 6 13 :3 7 © E S 28 Dipl.-Ing. David Friedrich Fachgebiet Eingebettete Systeme Universität Kassel friedrich@uni-kassel.de Lessons learned (3) Forderung nach automatischer Umsetzung des Modells in Programmcode der Zielumgebung Forderung nach automatischer Umsetzung des Modells in Programmcode der Zielumgebung Prototypische Realisierung eines Code-Generators für IEC 6 1131-3 konforme Steuerungsumgebung (Hardwarekonfiguration und Programmcode) Prototypische Realisierung eines Code-Generators für IEC 6 1131-3 konforme Steuerungsumgebung (Hardwarekonfiguration und Programmcode) Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Andreas Korff ARTiSAN Software Tools GmbH Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Überblick z Status der SysML z SysML Architektur der Modellierungssprache z SysML Sprachdetails ¼ Anforderungsmodellierung (Requirements) ¼ Strukturmodellierung (Structure) ¼ Parametrische Modelle (Parametric Models) ¼ Allokation (Allocation) z Zusammenfassung und Fragen Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Praxis des Systems Engineering zur Systembeschreibung i i i i z Spezifikationen z Schnittstellenanforderungen z Systemdesign z Analyse & Vergleich von Alternativen z Testpläne Übergang von dokum enten-zu m odellzentrierten Vorgehen Früher Zukünftig Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Systemmodellierung Start Shift Accelerate Brake Engine Transmission Transaxle Control Input Power Equations Vehicle Dynamics Mass Properties ModelStructural Model Safety Model Cost Model Anforderungen Integrierte System m odelle m üssen eine Vielzahlvon System aspekten unterstützen Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Was ist die SysML? z Eine grafische Modellierungssprache ensprechend des UML for Systems Engineering RfP, entwickelt von der OMG, INCOSE, und AP233 ¼ ein UML Profil, das eine Untermenge der UML 2 um Systemaspekte erweitert z SysML unterstützt die Spezifikation, Analyse, Design, Verifikation und Validierung von Systemen, die Hardware, Software, Daten, Personal, Verfahren und Anlagen enthalten z Ermöglicht Modell- und Datenaustausch via XMI und dem zukünftigen AP233 Standard Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved UML/SysML Status zUML V2.0 ¼ Angepasste Version der UML, die signifikante Verbesserungen zur Systemmodellierung im Vergleich zu früheren Versionen enthält ¼ 2005 Finalisiert (OMG-Dokument formal/05-07-04) zUML for Systems Engineering (SE) RfP ¼ Beschreibt die Anforderungen an eine Systemmodellierungssprache ¼ Veröffentlicht durch die OMG im März 2003 zSysML ¼ Stellungnahme durch die Industrie auf das UML for SE RfP ¼ Adressiert die meisten Anforderungen im RFP ¼ Version 1.0 wurde von der OMG im May 2006 angenommen ¼ Jetzt in Finalisierungsphase ¼ Wird jetzt von verschiedenen Toolherstellern implementiert Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Beziehung zwischen SysML und UMLi i UML 2 SysML in SysML wiederverwendete Konzepte der UML UML4SysML SysML SysML-spezifische Erweiterungen zur UML für SysML nicht notwendige Anteile der UML UML - UML4SysML notype Verhältnis von UML 2 und SysML Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved SysML Diagrammtaxonomie «Diagrammfamilie» SysML Diagramme «neues Diagramm» Anforderungsdiagramm «modifiziert» Blockdiagramm «modifiziert» Internes Blockdiagramm «neues Diagramm» Parametrisches Diagramm «Diagrammfamilie» Strukturdiagramme «Diagrammfamilie» Verhaltensdiagramme «modifiziert» Aktivitätsdiagramm Anwendungsfalldiagramm Sequenzdiagramm ZustandsmaschinendiagrammPaketdiagramm Vereinfachtes Klassendiagramm erweitertes Kompositionsstrukturdiagramm CLD SysML Diagrammtaxonomie Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved req [package] VehicleSpecifications [Requirements Diagram - Braking Requirements] Braking Subsystem Specification Vehicle System Specification id=“102” text=”The vehicle shall stop from 60 mph within 150 ft on a clean dry surface.” «requirement» StoppingDistance id=”337" text=”Braking subsystem shall prevent wheel lockup under all braking conditions.” «requirement» Anti-LockPerformance «deriveReqt» Definition bdd [package] VehicleStructure [ABS-Block Definition Diagram] «block» Traction Detector «block» Brake Modulator «block» Library::Elec tro-Hydraulic Valve «block» Library:: Electronic Processor «block» Anti-Lock Controller d1 m1 Vier Säulen der SysML – ABS Beispieli l i i l 1. Struktur 2. Verhalten 3. Anforderungen 4. Parametrisch sd ABS_ActivationSequence [Sequence Diagram] d1:Traction Detector m1:Brake Modulator detTrkLos() modBrkFrc() sendSignal() modBrkFrc(traction_signal:boolean) sendAck() Interaktion Zustands- maschine stm TireTraction [State Diagram] Gripping Slipping LossOfTraction RegainTraction Aktivität/ Funktion act PreventLockup [Activity Diagram] DetectLossOf Traction Modulate BrakingForceTractionLoss: par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram] :Accelleration Equation [F = ma] :VelocityEquation [a = dv/dt] :DistanceEquation [v = dx/dt] :BrakingForce Equation [f = (tf*bf)*(1-tl)] tf: bf:tl: f: F: c a: a: v: v: x: ibd [block] Anti-LockController [Internal Block Diagram] d1:Traction Detector m1:Brake Modulator c1:modulator interface Nutzung Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Anforderungen z Anforderungen in der SysML repräsentieren textbasierte Anforderungen ¼ Enthalten ID und Texteigenschaften ¼ Der Nutzer kann eigene Eigenschaften hinzufügen (z.B. Verifikationsmethode) ¼ Der Nutzer kann eigene Anforderungskategorien hinzufügen (z.B. funktional, Schnittstellenanforderung, Leistungsanforderung ...) z Die Anforderungshierarchie beschreibt die Struktur in einer Spezifikation z Anforderungsbeziehungen beinhalten: DeriveReqt, Satisfy, Verify, Refine, Trace, Copy z Anforderungen können grafisch, tabellarisch und in einer Baumstruktur beschrieben werden Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Nutzeranforderungen im Beispiel «activity» Distill Water «UseCase» Distill Water «requirement» txt The system must be able to connect directly to mains water Water Input «requirement» txt Distill dirty water into pure water Produce Distilled Water «requirement» txt The pure water output must be at a safe temperature Water Output «requirement» txt The system shall handle 1 litre of water per minute Water Throughput Customer Brochure «requirement» txt The system shall have an input valve that is closed when the system is off Provide Input Protection «requirement» txt The system must have an overflow valve in the main heating vessel Handle Overflow «requirement» txt The condenser needs to cool the pure water to 30 °C Condenser Efficiency «refine» «satisfy» «trace» «deriveReqt» «deriveReqt» «deriveReqt» «rationale» Analysis of this activity show s that the throughput is possible «rationale» Direct connection to high pressure mains w hen the system is off might cause damage «rationale» High pressure w ater may overpow er the boiler so an overf low valve is needed «rationale» 30 ° is deemed a safe output temperature req [package] UserRequirements Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Interaktionen z Sequenzdiagramme zeigen nachrichtenbasiertes Verhalten ¼ Repräsentiert Kontrollfluss z (UML 2.0-) Sequenzdiagramme enthalten auch Schlüsselmechanismen zur Darstellung komplexem Verhaltens ¼ Referenzen auf Sequenzen ¼ Kontrolllogik ¼ Dekomposition auf Instanzlebenslinien Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Interaktionsdiagramm für “Destiliere Wasser” Description :Distiller «block» :Distiller User «actor» seq seq User switches distiller on TurnOn Power Lamp On PowerLampOn Distiller reaches operating temperature LightOperatingLamp par par loop loop Boiler Overflow LightOverflowLamp Boiler OK OverflowLampOff end loop also par loop loop Sludge Build Up LightEmptyingLamp Sludge OK EmptyingLampOff end loop end par User switches distiller off TurnOff Power Lamp Off... PowerLampOff sd [interaction]Distill Water Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Aktivitäten z Aktivitäten werden genutzt, um Input/-Output-Flüsse und Kontrollflüsse zu spezifizieren, mit der Möglichkeit, durch Sequenzen und Bedingungen Aktivitäten zu koordinieren z Weitere Elemente zeigen Verantwortlichkeiten für Aktivitäten durch Schwimmbahnen z Erweiterungen für Aktivitäten in der SysML: ¼ Unterstützung der Modellierung kontinuierlicher Flüsse ¼ Unterstützung wahrscheinlichkeitsbasierter Entscheidungen ¼ Abgleich der Modellierung von Aktivitäten mit Enhanced Functional Flow Block Diagrammen (EFFBD’s) Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Analysiemodell des of Distiller- Verhaltens z SysML Erweiterungen in diesem Diagramm ¼ «streaming» Aktivitäten verbrauchen Inputs nach der Initialisierung ¼ «continuous» Flüsse act Distill Water Boil «streaming» HeatIn WarmWater Steam Heat «streaming» WaterIn : H2O WaterOut : H2O HeatIn : Heat InputWater «continuous» Condense «streaming» SteamInHeatOut PureOut OutputWater «continuous» GenerateHeat «streaming» inPoweroutHeat powerIn «continuous» «continuous» «continuous» «continuous» «continuous» Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved SysML Blocks z Ermöglichen ein vereinheitliches Konzept zur Darstellung der Struktur eines Elements oder Systems ¼ Hardware ¼ Software ¼ Daten ¼ Verfahren ¼ Anlagen ¼ Personen Block istdasBasisstrukturelem ent Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Zwei verschiedene Sichten auf Strukturen UML2::Class Diagram SysML::Block Definition Diagram UML2::Composite Structure Diagram SysML::Internal Block Diagram Structural Hierarchy: Class Diagram Traction Detector Brake Modulator Electro- Hydraulic Valve Electronic Processor Anti-Lock Controller Structural Hierarchy: Composite Structure Diagram Anti-Lock Controller :Traction Detector :Brake Modulator :modulator interface • gewohnte Sicht f. SW-Ingenieure • betont die Eigenschaften • gewohnte Sicht f.Systemingenieure • betont die Verschaltung Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Block Definition Diagram für die strukturellen Komponenten des Distiller z Parts (strukturelle Bestandteile) werden über die gefüllte Raute gezeigt, oder durch… z … Parts Compartment z Werte-Compartments zeigen Eigenschaften des Blocks z Flowport Compartments zeigen das Interface des Blocks «block» values MaxPressure : Pa Distiller «block» parts heater : Element tank : HeatingVessel vOverflow : DrainValve vResidue : DrainValve values FluidPurity : Real MaxTemp : °C Boiler «block» values tempGradient : Real flowPorts fIn : Fluid HEC : FluidExchange pFOut : Fluid HeatExchanger «block» Controller «block» FrontPanel «block» FlowValve hx bl UI controller 1 1 inValve bdd [package] Structure [composition] Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Einheiten und Elementtypen z Unit- Typen basieren in der Regel auf “Real” z SI Einheiten und Dimensionen sind im SysML-Anhang definiert «block» values lh : J/kg = 520 m : kg = 0 press : Pa sh : J/kg/°C = 1 t : °C H2O «block» values Q : J Heat «block» values lh : J/kg = 520 press : Pa sh : J/kg/°C = 1 t : °C Residue «block» values lh : J/kg = 520 press : Pa sh : J/kg/°C = 1 t : °C Fluid «block» values p : W Electricity bdd [package] Items «valueType» dimension = mass unit = kilogram kg «valueType» dimension = temperature unit = degrees Centigrade ºC «valueType» unit = Joules J «valueType» unit = kilograms/second kg/s «valueType» dimension = pressure unit = kilograms/square meter kg/m² bdd Units Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Internes Blockdiagramm für den Boiler ibd [block] Boiler block Boiler heater : Element Hout PwrIn blWrn BC SOut excess PwrIn tank : HeatingVessel HVwrn HVFe HVsludge HVexcess HIn Ocnt Rcnt vResidue : DrainValve cntRIn ROut vOverflow : DrainValve cnt RIn ROut IValve IValve IValve IValve z Zeigt Parts (Strukturelle Bestandteile) … z … und Ports (Interaktionspunkte für Blöcke und Parts) ¼ Unterstützt dine Zusammenführung von Struktur und Verhalten z Porttypen ¼ Standard Ports ‹ Spezifizieren eine Menge an Operationen und/oder Signalen ‹ Vom Typ eines UML Interface ¼ Flow Ports ‹ Spezifizieren, was hier fliessen kann in oder aus den Block/Port ‹ Vom Typ einer Flow Specification Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Elementflüsse (Item Flows) z Unterscheiden sich durch das, was über die Portspezifikation fliessen kann z Unterstützt die Top-Down-Beschreibung von Flüssen ohne die Notwendigkeit, Verhalten modellieren zu müssen (z.B. Aktivitäten, Zustände, Interaktionen) ¼ Verhalten wird nicht durch die Item Flows bestimmt, muss aber damit konsistent sein ¼ Ist abgestimmt mit dem Verhaltensmodell durch Verfeinerung und Allokierung ¼ Kann alloziert werden von einem Objektknoten, einer Nachricht oder einem Signal aus einem Verhaltensdiagramm z Eigenschaften eines Elements können in Parametrischen Diagrammen spezifiziert oder eingeschränkt werden Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved ibd [block] Distiller IBD für den Distiller z Zusammengesetzte Flow Ports (BC und HEC) ¼ I/O wird spezifiziert durch FlowSpecification ¼ FlowSpecification besteht aus Eigenschaften mit dem Stereotyp «FlowProperty» ¼ isConjugate begünstigt die Wiederverwendung von flowSpecifications z Atomare FlowPorts (dirtyWater, extPower …) ¼ Hier sind die Ports direkt typisiert mit einem Elementtyp (Block oder ValueType) ¼ Die Richtungseigenschaft bestimmt die Fliessrichtung block Distiller PureWater loPressResidue dirtyWater hx : HeatExchangerfIn : Fluid pFOut HEC tempWrn bl : Boiler SOut BC excess blWrn PwrIn Rcnt Ocnt controller : Controller ui vO vD wrn pwrIn blrPwr vI UI : FrontPanel cnt User overFlow extPower inValve : FlowValve p op cnt UserIO ILamp IPower IValve IValve ILamp IPower IValve IValve IValve IValve waterOut : H2O blSteamOut : H2O hxWaterOut : H2O PowerIn : Electricity RegPower : Electricity waterIn : H2O Excess : H2O blSludgeOut : Residue «problem» Overflow water is very hot! Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Callout-Notation für Anforderungenll i «requirement» Boil Water «requirement» Boiler Power «requirement» Boiler Function «requirement» Safety Cut Off «requirement» Handle Overflow «requirement» Condenser Efficiency «requirement» Provide Input Protection «requirement» Residue Processing «requirement» Maximum Capacity «requirement» Minimum Rating satisfiedBy «blockProperty»vResidue derivedFrom «requirement»Water Input satisfiedBy «blockProperty»vOverflow derivedFrom «requirement»Water Input satisfiedBy «blockProperty»inValve req [package] SystemRequirements Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Parametrische Modellierung z Dient der Modellierung von Einschränkungen (Constraints) in Form von Gleichungen zwischen Werteeigenschaften ¼ Ermöglicht die Unterstützung von Analysen (z.B. Performanz, Zuverlässigkeit usw.) z Constraint Blocks enthalten die Gleichungen ¼ Die genutzte Sprache der Ausdrücke kann formal (e.g. MathML, OCL …) or nicht-formal sein ¼ Die Auswertung der Ausdrücke erfolgt extern durch ein Analysewerkzeug, nicht durch die SysML z Parametrische Diagramme repräsentieren die Nutzung der Constraints in einem Analysekontext ¼ Bindung einer Constraint-Nutzung an Werteeigenschaften eines Blocks (z.B. Fahrzeugmasse gebunden an F= m * a) Param etrische M odellierung erm öglichtdie Integration von SE-Analysen m itDesignm odellen Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved BDD für Distiller-Parametrisierung z BDDs können parametrische Definitionen zeigen z Parameter Compartment enthalten die Constraint- Parameter z Constraint Compartment zeigen das genutzte Constraint z Elementeigenschaften des Distillers beschreiben den Fluss in das System «block» itemProperties blSludgeOut : Residue blSteamOut : H2O Excess : H2O hxWaterOut : H2O PowerIn : Electricity RegPower : Electricity waterIn : H2O waterOut : H2O Distiller «constraintBlock» constraint {qRate=(tout-tin)*mRat- e/sh} parameter mRate : kg/s qRate : W sh : J/kg/°C tin : °C tout : °C SinglePhaseHeatXFR- Equation «constraintBlock» constraint {r1=r2} parameter lh : J/kg mRate : kg/s qRate : W SimplePhaseChange- Equation «constraintBlock» constraint {r1=r2} parameter r1 : Real r2 : Real equivalent be ce boiling condensing XFRHeat bdd [package] DistillerParametrics Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Parametrisches Diagramm block Distil ler hxWaterOut : H2O t massFlowRate waterIn : H2O t massFlowRate blSteamOut : H2O massFlowRate waterOut : H2O massFlowRate boiling qRate lhmRate condensing qRate lh mRate XFRHeat tout tin qRate sh mRate PowerIn : Electricity p : equivalent r1 r2 : equivalent r1 r2 H2O lh sh {qRate=mRate*lh} {r1=r2} {qRate=(tout-tin)*mRate/sh}... par [block] Distiller z Kleine Quadrate entsprechen Parametern und die daran gebundenen Eigenschaften z Linke Rechtecke zeigen die Item Flows z Das Constraint kann in einem Compartment oder in einer verbundenen Notiz gezeigt werden Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Allokationen z Ermöglichen eine generelle Verbindung zwischen einzelnen Modellelementen z Es gibt verschiedenste Arten von Allokationen: ¼ Verhalten (i.e. Funktion auf Komponente) ¼ Strukturell (i.e. Logisch auf Physikalisch) ¼ Hardware auf Software ¼ …. z Explizite Allozierung von Aktivitäten in Schwimmbahnen (z.B. Aktivitätspartitionen) z Nutzung von grafischen und/oder tabellarischen Repräsentationen möglich Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Swimmbahn-Allokation von Verhalten auf Struktur act Distill Water Distiller.hx OutputWater «continuous» Condense «streaming» SteamIn HeatOut PureOut Heat «streaming» WaterIn : H2O WaterOut : H2O HeatIn : Heat Boil «streaming» HeatIn WarmWater Steam Distiller.bl GenerateHeat «streaming» inPoweroutHeat powerIn «continuous» InputWater «continuous» «continuous» «continuous» «continuous» «continuous» z «allocate» Partitionen zeigen, welche Teile für die Ausführung welcher Aktivitäten verantwortlich sind «allocate» «allocate» Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Allokation auf einem IBD ibd [block] Distiller [Allocation] z Allokationen ¼ Allozierung von Aktivitätsaufrufen in Parts werden durch das allocatedFrom Compartment dargestellt ¼ Allozierung von Aktivitätsobjektknoten auf Item Flows werden durch Call-outs gezeigt block Distiller hx : HeatExchanger allocatedFrom «activity» Condense «activity» Heat bl : Boiler allocatedFrom «activity» GenerateHeat «activity» Boil controller : ControllerUI : FrontPanel User inValve : FlowValve UserIO waterOut : H2O blSteamOut : H2O hxWaterOut : H2O PowerIn : Electricity RegPower : Electricity waterIn : H2O Excess : H2O blSludgeOut : Residue allocatedFrom «parameter» OutputWater allocatedFrom «parameter» InputWater allocatedFrom «objectNode» OutSteam allocatedFrom «objectNode» WI allocatedFrom «parameter» powerIn Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved ibd [block] Anti-LockController [Internal Block Diagram] d1:Traction Detector m1:Brake Modulator c1:modulator interface ibd [block] Anti-LockController [Internal Block Diagram] allocatedFrom «activity»DetectLos OfTraction d1:TractionDetector allocatedFrom «activity»Modulate BrakingForce m1:BrakeModulator allocatedFrom «ObjectNode» TractionLoss: c1:modulator Interface act PreventLockup [Activity Diagram] DetectLossOf Traction Modulate BrakingForceTractionLoss: par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram] :Accelleration Equation [F = ma] :VelocityEquation [a = dv/dt] :DistanceEquation [v = dx/dt] :BrakingForce Equation [f = (tf*bf)*(1-tl)] tf: bf:tl: f: F: c a: a: v: v: x: Querverbindung von Modellelementeni ll l 1. Structure 2. Behavior 3. Requirements 4. Pa ametrics act PreventLockup [Swimlane Diagram] «allocate» :TractionDetector «allocate» :BrakeModulator allocatedTo «connector»c1:modulatorInterface l i req [package] VehicleSpecifications [Requirements Diagram - Braking Requirements] Braking Subsystem Specification Vehicle System Specification id=“102” text=”The vehicle shall stop from 60 mph within 150 ft on a clean dry surface.” «requirement» StoppingDistance id=”337" text=”Braking subsystem shall prevent wheel lockup under all braking conditions.” «requirement» Anti-LockPerformance «deriveReqt» satisfies «requirement» Anti-Lock Performance SatisfiedBy «block»Anti-LockController «deriveReqt» ll i l t Traction values DutyCycle: Percentage i i l t i l c1:modulator Interface i fi i t ti par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram] ll i i [ ] l i i [ / t] i i [ / t] i i [f tf f tl ] tf: f:tl: f: : m: : : : : : v.Position: v.Weight:v.chassis.tire.Friction: v.brake.abs.m1. DutyCycle: v.brake.rotor. BrakingForce: [ t i t l ] t i t i i l i [ t i i ] ll i i [ ] l i i [ / t] i i [ / t] i i [ tf l ] tf: f:tl: f: : : : : : . i i .. . i .i i . . . . l . . i VerifiedBy «interaction»MinimumStopp ingDistance «deriveReqt» satisfy verify value binding alloca te Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Zusammenfassung z SysML wird getragen durch INCOSE/OMG mit breiter Industrie- und Toolherstellerbeteiligung z SysML stellt eine universelle Modellierungssprache dar zur Spezifikation, Analyse, Design und Verifikation komplexer Systeme ¼ Untermenge der UML 2 erweitert um Systemaspekte ¼ Die 4 Säulen der SysML beihalten die Modellierung von Anforderungen, Verhalten, Struktur und parametrischen Eigenschaften z OMG SysML wurde im Mai 2006 angenommen (d.h. standardisiert) z Viele Toolhersteller haben die SysML-Unterstützung angekündigt z Der standard-basierte Modellierungsansatz für SE läßt eine Verbesserung der Kommunikation in den Entwicklungsteams, eine verbesserte Interoperabilität von Tools und eine höhere Designqualität erwarten. Copyright © 1998-2006 ARTiSAN Software Tools GmbH All Rights Reserved Fragen? Objektorientiert programmieren mit CoDeSys 3.0 A ut om at io n S ym po si um 2 00 6 am 2 6. 10 .2 00 6 / K as se l We software Automation. Überblick ƒ Objektorientiert programmieren – ein kleines Beispiel ƒ Verbindung mit der E/A-Ebene ƒ Verbindung mit einer Visualisierung ƒ Vererbung, Methoden und Interfaces A ut om at io n S ym po si um 2 00 6 am 2 6. 10 .2 00 6 / K as se l We software Automation. Das Beispiel ƒEin Zimmer in einem Gebäude ƒ Ein Lichttaster ƒ Eine Leuchte ƒ Ein Tastendruck: Licht an/aus A ut om at io n S ym po si um 2 00 6 am 2 6. 10 .2 00 6 / K as se l We software Automation. Das Beispiel A ut om at io n S ym po si um 2 00 6 am 2 6. 10 .2 00 6 / K as se l We software Automation. Verbindung mit der E/A-Ebene ƒStandard IEC 61131-3 ƒ E/A-Adressen sind global ƒ Übergabe der E/A-Adressen als Parameter ƒCoDeSys 3.0 ƒ VAR_CONFIG ƒ Assoziation der Komponente mit der Adresse direkt in der Konfiguration A ut om at io n S ym po si um 2 00 6 am 2 6. 10 .2 00 6 / K as se l We software Automation. Verbindung mit der E/A-Ebene A ut om at io n S ym po si um 2 00 6 am 2 6. 10 .2 00 6 / K as se l We software Automation. Verbindung mit der Visualisierung ƒStandard Systeme ƒ Einzelne Assoziation von Elementen mit Variablen ƒCoDeSys 3.0 ƒ Definition einer Visualisierung pro Funktionsbaustein/Klasse ƒ Assoziation von Komponenten mit Elementen ƒ Instanz als Parameter bei der Verwendung der Visualisierung A ut om at io n S ym po si um 2 00 6 am 2 6. 10 .2 00 6 / K as se l We software Automation. Verbindung mit der Visualisierung Schalter Auch eine Visualisierung hat eine Schnittstelle A ut om at io n S ym po si um 2 00 6 am 2 6. 10 .2 00 6 / K as se l We software Automation. Ableiten von Klassen ƒ Chefbüro ƒ Wie Einzelbüro ƒ Zusätzlich Klimaanlage ƒ Großraumbüro ƒ Zwei Lichter statt einem A ut om at io n S ym po si um 2 00 6 am 2 6. 10 .2 00 6 / K as se l We software Automation. Ableiten von Klassen FUNCTION_BLOCK Einzelzimmer FUNCTION_BLOCK Grossraumbuero FUNCTION_BLOCK Chefzimmer Ist abgeleitet von A ut om at io n S ym po si um 2 00 6 am 2 6. 10 .2 00 6 / K as se l We software Automation. Methoden ƒ Neben dem normalen Betrieb gibt es Ereignisse, die besondere Reaktion erfordern ƒ Nachabschaltung ƒ Panikmodus A ut om at io n S ym po si um 2 00 6 am 2 6. 10 .2 00 6 / K as se l We software Automation. Methoden FUNCTION_BLOCK Einzelzimmer FUNCTION_BLOCK Grossraumbuero FUNCTION_BLOCK Chefzimmer Ist abgeleitet von METHOD BOOL Nachtabschaltung METHOD BOOL Alarmschaltung METHOD BOOL Nachtabschaltung METHOD BOOL Alarmschaltung METHOD BOOL Nachtabschaltung METHOD BOOL Alarmschaltung A ut om at io n S ym po si um 2 00 6 am 2 6. 10 .2 00 6 / K as se l We software Automation. Interfaces ƒ Funktionen, die für alle gleich sind: ƒ Nachtabschaltung ƒ Panikbeleuchtung (Feueralarm) A ut om at io n S ym po si um 2 00 6 am 2 6. 10 .2 00 6 / K as se l We software Automation. Interfaces FUNCTION_BLOCK Einzelzimmer FUNCTION_BLOCK Grossraumbuero FUNCTION_BLOCK Chefzimmer Ist abgeleitet von METHOD BOOL Nachtabschaltung METHOD BOOL Alarmschaltung METHOD BOOL Nachtabschaltung METHOD BOOL Alarmschaltung METHOD BOOL Nachtabschaltung METHOD BOOL Alarmschaltung INTERFACE Zimmer METHOD BOOL Nachtabschaltung METHOD BOOL Alarmschaltung Implementiert Implementiert A ut om at io n S ym po si um 2 00 6 am 2 6. 10 .2 00 6 / K as se l We software Automation. Objektorientierte Programme erweitern ƒ Erweiterung des Gebäudes um einen Anbau: ƒ Zwei neue Einzelzimmer ƒ Ein Chefbüro ƒ Ein Großraumbüro A ut om at io n S ym po si um 2 00 6 am 2 6. 10 .2 00 6 / K as se l We software Automation. Fazit ƒ Objektorientierte Programme sind leicht zu erweitern ƒ Die Einbindung von Visualisierung und Feldbuskonfiguration kann durch Toolunterstützung optimiert werden © 2006 innotec GmbH. All rights reserved Comos® Express Konfigurieren von modular aufgebauten Anlagen und Maschinen mit dem Anlagen- und Maschinenkonfigurator Ing. Marko Bogeljić © 2006 innotec GmbH. All rights reserved agenda Allgemeine Informationen über Software und die Firma Comos® Express – Anlagen- und Maschinenkonfigurator - Konzept - Handling Key Benefits © 2006 innotec GmbH. All rights reserved innotec GmbH (seit 1991) Mitarbeiter: >250 (über 140 Ingenieure) Erfahrung: > 20 Jahre Softwareentwicklung Development Cons.+Eng. Support Sales Marketing Admininnotec Inc. USA Systemtechnik GmbHSystemtechnik Ltd. Qualitätssicherung innotec Inc. USAMark ting Ltdinnotec Inc. USASoftwaretechnik Ltd LOGOTEC Software Ltd. innotec Austria CEO: Jochen Schüler Michael Weller Stephan Rohleder Ltd. innotec Brasil innotec Benelux innotec Swiss innotec SA innotec Asia Produkte und Module Comos® PT (Prozesstechnik) Comos® ME (Mechatronik) Comos® PQM (Project and Quality-Managem.) Comos® iAge (Instandhaltung) UNSERE KUNDEN Aker Kvaerner, Akzo Nobel, Aventis Pharma, Andritz, Chiron, Ciba, Corus Aluminium, DSM Vitamine, Degussa Engineering, E-on, EVC, Invensys Foxboro, Lonza, Pharmaplan, Kostal, Linde, Lurgi, Novartis, OMV, Roche, Sandoz, Siemens A&D, Siemens PGI, SMS, TEVA, Uhde, Vattenfall Europe, Voith, Wacker-Chemie, Zimmer, ...) © 2006 innotec GmbH. All rights reserved Comos® Express Objektmodel Microsoft Jet-Engine Microsoft SQL Server OracleDB Comos® MotionX XMLXML AQM (Audit Quality Management) / FDA BASIC P E /P FD C on ce pt ua l M od el er C om os ®® V ie w C om os ®® P Q M BASIC PT P & ID P PC B as ic Fu nc tio na l D es ig n E M R BASIC FACTORY iAge W or ks ho p M od ul Ba rc od e SA P S ch ic ht bu ch S hu td ow n- R ev is io n pl an ni ng MS Project Viper BASIC P ip e cl as s- m an ag er Is om et ric s P PC P PC FEED BASIC MECHATRONICS M E -D es ig ne r E- En gi ne er in g Fl ui d En gi ne er in g Ex pr es s © 2006 innotec GmbH. All rights reserved Objektorient. Datenbanklösung Comos® PT Engineering Tool DB PFD H o ok U p Lo op D i ag ra m s PFD P&ID Iso m e tr ien 3D FEED Lo gi ca l D ia gr am s © 2006 innotec GmbH. All rights reserved agenda Allgemeine Informationen über Software und die Firma Comos® Express – Anlagen- und Maschinenkonfigurator - Konzept - Handling Key Benefits © 2006 innotec GmbH. All rights reserved Funktionsübersicht 1. Fixe Strukturen (Optionstechnik) „ Option ein/aus „ Optionen gegenseitig verknüpfen „ Optionen verschachteln 2. Baugruppentechnik „ Mehrfaches Anlegen „ Freie Auswahl der Zielknoten „ Optionstechnik 3. Parameterabhängige Konfiguration 4. Variantentechnik © 2006 innotec GmbH. All rights reserved Konzept (fixe Strukturen) 30Parameter 1Optionen Option 1 Option 2 170Parameter 2 Vorlage B Comos® ExpressVorlagen Projekt 150ParameterOptionen Option 1 Option 1.1 Option 2 Vorlage A Option 3 Option 3.1 Option 3.1.1 150ParameterOptionen Option 1 Option 1.1 Option 2 Vorlage A Option 3 Option 3.1 Option 3.1.1 220ParameterOptionen Option 1 Option 3 Option 3.1 22 © 2006 innotec GmbH. All rights reserved Comos® Express Projekt Ziel A Ziel B Parameter 1 170Parameter 2 Vorlage B Ziel Anzahl 30Parameter 1 170Parameter 2 Vorlage B Vorlagen 150ParameterOptionen Option 1 Vorlage A Vorlage C Parameter 1 Parameter 2 Vorlage B Ziel Anzahl ParameterOptionen Vorlage A Ziel Anzahl Konzept (einzelne Baugruppen) 30 170 150 Option 1 30 150ParameterOptionen Option 1 Vorlage A Ziel Anzahl 80 Ziel A 1 200 5 Ziel A 1 Ziel B 1 Ziel B 2 1 ParameterOptionen 80 Option 1 Parameter 1 Parameter 2 200 150 Parameter 150 Parameter 1 Parameter 2 10 170 Parameter 1 Parameter 2 10 170 © 2006 innotec GmbH. All rights reserved Handling mit fixen Strukturen Projekt Optionen definieren Vorlagen © 2006 innotec GmbH. All rights reserved Handling mit einzelnen Baugruppen Vorlagen Projekt X8 X9 © 2006 innotec GmbH. All rights reserved agenda Allgemeine Informationen über Software und die Firma Comos® Express – Anlagen- und Maschinenkonfigurator - Konzept - Handling Key Benefits © 2006 innotec GmbH. All rights reserved Key Benefits 1. Konfiguration von Anlagen und Maschinen über eine einheitliche Oberfläche 2. Konfiguration bereits in der Vertriebsphase möglich „ Mengengerüst „ Listen „ Angebot 3. Sehr hoher Fertigstellungsgrad (bis 100 %) „ Prozesstechnik „ Elektrotechnik „ MSR „ Fluidtechnik 4. Zeitersparnis 5. Umkonfigurieren möglich © 2006 innotec GmbH. All rights reserved Vielen Dank für Ihre Aufmerksamkeit ! Abstraction Module2 Module3Module3 Module1