Kapitel 7: Programmiersprachen für die Automatisierungstechnik AT1 § 7 Programmiersprachen für die Automatisierungstechnik Lernziele: – Die Vorgehensweisen bei der Erstellung von Automatisierungsprogrammen kennen – Die Programmiersprachen für SPSen kennen – Die wichtigsten Echtzeit-Konzepte für Programmiersprachen kennen – Wissen, wie Echtzeit-Konzepte in Ada 95 umgesetzt sind © 2015, IAS Universität Stuttgart 409 AT1 § 7 Programmiersprachen für die Automatisierungstechnik 7.1 Grundbegriffe 7.2 Programmierung von speicherprogrammierbaren Steuerungen (SPS) 7.3 Universelle Programmiersprachen für die Automatisierungstechnik 7.4 Konzepte der Parallelprogrammierung © 2015, IAS Universität Stuttgart 410 7.1 Grundbegriffe AT1 Vorgehensweisen bei der Erstellung der Programme Speicherprogrammierbare Steuerungen – – textuelle Programmiersprachen graphische Programmiersprachen Mikrocontroller – Assembler – niedere maschinenunabhängige Programmiersprachen PC und IPC – – Softwarepakete universelle Echtzeitprogrammiersprachen Prozessleitsysteme – Funktionsbausteintechnologie © 2015, IAS Universität Stuttgart 411 7.1 Grundbegriffe AT1 Arten von Programmiersprachen Klassifikation nach Art der Notation – – textuelle Programmiersprachen graphische Programmiersprache Ada, C, SPS-Anweisungsliste SPS-Kontaktplan Klassifikation nach dem Programmiersprachenparadigma – – – – prozedurale Programmiersprachen funktionale Programmiersprachen logische Programmiersprachen objektorientierte Programmiersprachen C, Ada 83 LISP PROLOG C++, Smalltalk, Ada 95 Klassifikation nach der Sprachhöhe – – hoch: nieder: an der Verstehbarkeit durch den Menschen orientiert an den Hardware-Eigenschaften eines Computers orientiert © 2015, IAS Universität Stuttgart 412 7.1 Grundbegriffe AT1 Klassifizierung nach der “Sprachhöhe” Programm-Generatoren „Sprachhöhe“ Anwendungsspezifische Programmiersprachen Maschinenunabhängige Programmiersprachen Universelle Programmiersprachen Makroassemblersprachen Assemblersprachen Maschinensprachen Mikroprogrammsprachen © 2015, IAS Universität Stuttgart Maschinenorientierte Programmiersprachen Maschinensprachen 413 7.1 Grundbegriffe AT1 Mikroprogrammsprachen – Realisierung der Ablaufsteuerungen zur Ausführung der Maschinenbefehle fest verdrahtete Verknüpfungsglieder Mikroprogramme (Firmware) Maschinensprachen – nicht für Anwendungsprogrammierung Befehle und Daten in Form von Bitmustern zur direkten Ausführung auf der Hardware des AT-Computers Assemblersprachen – Ersetzung der Bitmuster des Operationsteils der Befehle der Maschinensprache durch symbolische Buchstabenabkürzungen – Einführung eines symbolischen Namens anstelle der zahlenmäßigen Darstellung des Adressteils – Abhängigkeit von gerätetechnischen Eigenschaften der jeweiligen Rechenanlage © 2015, IAS Universität Stuttgart 414 7.1 Grundbegriffe AT1 Makroassemblersprachen (Makrosprachen) – weiteres Hilfsmittel zur einfacheren Handhabung: Makros Makro: Abkürzung für eine bestimmte Befehlsfolge – Unterscheidung Makrodefinition Makroaufruf Makroexpansion – Eindeutige Zuordnung von Makroassemblerbefehlen zu Befehlen der Maschinensprache – Einem Makrobefehl entsprechen mehrere Maschinenbefehle – Makro wird an jeder Stelle, an der es aufgerufen wird, expandiert Klassifizierung von Makros – Standardmakros: – Anwendermakros: vom Anwender selbst definierbare Makros für häufig vorkommende Befehlsfolgen fest vorgegeben © 2015, IAS Universität Stuttgart 415 7.1 Grundbegriffe AT1 Vor- und Nachteile der Assemblerprogrammierung + Speicher- und Rechenzeit-Effizienz - höhere Programm-Entwicklungskosten - geringe Wartbarkeit - Probleme mit der Zuverlässigkeit - schlechte Lesbarkeit, geringer Dokumentationswert - fehlende Portabilität Einsatz von Assemblersprachen ja: - Automatisierung von Geräten oder Maschinen, wo es um Serienoder Massenanwendungen geht - kleinste Programme - direkter Zugriff auf sehr spezifische Hardware nein: - langlebige, große zu automatisierende Prozesse - umfangreichere Programme © 2015, IAS Universität Stuttgart 416 7.1 Grundbegriffe AT1 Universelle Programmiersprachen Universell nicht auf ein Anwendungsgebiet ausgerichtet universelle niedere Programmiersprachen – – – Zweck: Systemprogrammiersprachen Erstellung von Systemprogrammen • Compiler • Editoren • Betriebssysteme • Treiberprogramme Ziel: 1. Ausnutzung der Hardwareeigenschaften 2. Portabilität Beispiel: C universelle höhere Programmiersprachen – Zweck: Erstellung von allgemeinen Programmen – Ziel: 1. einfache Formulierbarkeit 2. umfangreiche Compilerprüfungen 3. Portabilität – Beispiel: Ada, Java, Smalltalk © 2015, IAS Universität Stuttgart 417 7.1 Grundbegriffe AT1 Entwicklungslinien Eclipse 2005 2000 Java 2 Ada2005 Java Ada95 C# 1995 Python Ruby PEARL 90 1990 C++ Eiffel 1985 TKL/TK 1980 Ada Small talk 80 Mehrrechner PEARL C 1975 PEARL 1970 Pascal Simula 1965 PL/1 CORAL 66 BASIC 1960 COBOL ALGOL 68 ALGOL60 Legende: Objektorientierte Programmiersprache Echtzeit Programmiersprache FORTRAN 1955 © 2015, IAS Universität Stuttgart Höhere Programmiersprache 418 7.1 Grundbegriffe AT1 Anwendungsspezifische Sprachen Synonyme: Deskripitive Sprachen, nicht-prozedurale höhere Sprachen, very high level languages Unterscheidung zu prozeduralen Sprachen – – Bsp.: keine Beschreibung des Lösungsverfahrens, sondern Beschreibung der Problemstellung selbst Einschränkung auf bestimmtes Anwendungsgebiet FUP KOP AWL EXAPT ATLAS Funktionsplan Kontaktplan Anweisungsliste für Werkzeugmaschinensteuerungen für automatische Prüfsysteme Vorteile/Nachteile: + bequeme, anwendungsspezifische Ausdrucksweise - Inflexibilität © 2015, IAS Universität Stuttgart 419 7.1 Grundbegriffe AT1 Programm-Generatoren (Fill-in-the-blanks-Sprachen) – Formulierungsverfahren für Programme – Beantwortung von Fragen in Form von Menüs am Bildschirm durch den Anwender (Konfigurierung) – Umsetzung der Antworten durch den Programm-Generator in ein ausführbares Programm – Vorteil: – Nachteil: Einengung auf bestimmtes Anwendungsgebiet keine Programmierkenntnisse notwendig Abhängigkeit von einem bestimmten Hersteller Anwendung in Automatisierungstechnik – Leitsysteme in der Energie-und Verfahrenstechnik © 2015, IAS Universität Stuttgart 420 7.1 Grundbegriffe AT1 Problematik der Echtzeit-Programmierung – Höhere Programmiersprachen wie FORTRAN, COBOL, PASCAL, Java, C# sind ohne Erweiterungen für Echtzeit-Programmierung ungeeignet keine Echtzeitsprachmittel keine Einzelbitoperationen keine Befehle für Prozess-Ein-/Ausgabe – Einsatz von höheren Programmiersprachen im Vergleich zu Assemblersprachen bringt i.d.R. Erhöhung von Speicherbedarf und Rechenzeit mit sich Produktautomatisierung: Speicherplatz und Rechenzeit kritisch Anlagenautomatisierung: Rechenzeit unter Umständen kritisch Voraussetzung Compiler für Zielrechner Echtzeit-Betriebssystem © 2015, IAS Universität Stuttgart 421 7.1 Grundbegriffe AT1 Vergleich der Verwendung höherer Programmiersprachen Anteil der Anwendung höherer Programmiersprachen 100% Höhere Programmiersprachen für technischwissenschaftliche und kommerzielle Anwendungen Höhere Programmiersprachen für die Prozessautomatisierung 0% 1950 1960 © 2015, IAS Universität Stuttgart 1970 1980 1990 2000 t 422 7.1 Grundbegriffe AT1 Frage zu Kapitel 7.1 Mit welchen der folgenden Aussagen über die unterschiedlichen “Sprachhöhen” stimmen Sie überein? Antwort f Maschinensprachen sind gut geeignet für die Anwendungsprogrammierung. Die Programmiersprache C ist eine universelle Programmiersprache. f Der Kontaktplan (KOP) der SPS-Programmierung ist eine Maschinensprache. f Programmgeneratoren verlangen ausgeprägte Programmierkenntnisse. Programmiersprachen mit niedriger “Sprachhöhe” fokussieren HardwareCharakteristiken eines Computers. Mit universellen Programmiersprachen können maschinen-unabhängige Programme erstellt werden. © 2015, IAS Universität Stuttgart 423 AT1 § 7 Programmiersprachen für die Automatisierungstechnik 7.1 Grundbegriffe 7.2 Programmierung von speicherprogrammierbaren Steuerungen (SPS) 7.3 Universelle Programmiersprachen für die Automatisierungstechnik 7.4 Konzepte der Parallelprogrammierung © 2015, IAS Universität Stuttgart 424 7.2 Programmierung von speicherprogrammierbaren Steuerungen (SPS) AT1 Programmiersprachen für SPS-Systeme (1) – Keine feste Programmiersprache für SPS-Systeme – Unterschiedliche Arten der Programmierung, auch abhängig vom Hersteller – IEC 61131 definiert grafische und textuelle Grundsprachen Eingabesprachen Speicherprogrammierbarer Steuerungen (IEC 61131-1/3) alphanumerische Darstellung graphische Darstellung Zustands-orientierte Anweisungsliste AWL U E 5.3 U E 2.6 O A 2.1 ON M 23.1 = A 2.4 Strukturierter Text ST IF A&B = 1 THEN ... ELSE ... Funktionsplan FUP E5.3 Kontaktplan KOP E5.3 & E2.6 >=1 A2.1 A2.1 M23.1 Ablauf-orientiert E2.6 A2.4 ( ) Ablaufsprachen AS S1 T1 T8 S2 A2.4 S8 M23.1 T2 T9 – IEC 61131 definiert keine Befehle! sowohl deutsche als auch englische Bezeichner für Operatoren © 2015, IAS Universität Stuttgart 425 7.2 Programmierung von speicherprogrammierbaren Steuerungen (SPS) AT1 Programmiersprachen für SPS-Systeme (2) – Basis aller Programmiersprachen sind Logikverknüpfungen – Erweiterung um Möglichkeiten der Zeitverarbeitung – Darstellungsart je nach Aufgabenstellung unterschiedlich geeignet • Zustandsorientierte Programmteile besser in FUP oder KOP • Ablauforientierte Programmteile besser in AWL oder AS – Darstellungsarten lassen sich ineinander überführen ABER: Bestimmte Operationen nur in AWL programmierbar (Bit-Schiebeoperationen) Einführungsbeispiel: Ausgang 1( A1) und Ausgang 2 (A2) sind nur dann gesetzt, wenn entweder Eingang 3 (E3) gesetzt ist oder wenn die beiden Eingänge1 (E1) und 2 (E2) gleichzeitig gesetzt sind. © 2015, IAS Universität Stuttgart 426 7.2 Programmierung von speicherprogrammierbaren Steuerungen (SPS) Anweisungsliste AT1 (AWL)/Instruction List (IL) – Assemblerähnliche Programmiersprache – Alle Funktionen einer SPS uneingeschränkt programmierbar – Einheitlicher Aufbau einer Befehlszeile Marke(opt.): Operator Operand Kommentar(opt.) – Programmierung durch Verknüpfung von Signalen Umsetzung des Beispiels in AWL Start: U( U ) O = = E1 E2 E3 A1 A2 © 2015, IAS Universität Stuttgart 427 7.2 Programmierung von speicherprogrammierbaren Steuerungen (SPS) AT1 Strukturierter Text (ST) – Höhere, Pascal-ähnliche Sprache • Zuweisungen z.B.: alarm := ein AND aus; • Unterprogrammaufrufe z.B.: alarmleuchte(S:=ein, R:=aus); • Kontrollanweisungen z.B.: IF alarm THEN alarmleuchte(S:=ein, R:=aus); END_IF; – Zusätzliche Sprachmittel für Zeitverarbeitung und Prozessdatenzugriff – Für die Programmierung umfangreicher Systeme geeignet Umsetzung des Beispiels in ST A1 := A2 := © 2015, IAS Universität Stuttgart E3 OR (E1 AND E2); A1; 428 7.2 Programmierung von speicherprogrammierbaren Steuerungen (SPS) AT1 Kontaktplan (KOP) / Ladder Diagramm (LD) – Einfache Darstellung – Lehnt sich an Stromlaufplan der Relaistechnik an – Symbole für „Schließer“, „Öffner“, und „Relaisspule“ Schließer Verknüpfungsergebnis (Spule) Öffner – Symbolisierter Stromfluss von links nach rechts – I/O-Zustände werden auf Schalterzustände abgebildet – Programm wird von oben nach unten gelesen Nachteil: Komplexe mathematische Funktionen schlecht darstellbar Umsetzung des Beispiels in KOP E1 E3 © 2015, IAS Universität Stuttgart E2 A1 A2 429 7.2 Programmierung von speicherprogrammierbaren Steuerungen (SPS) AT1 Funktionsbausteinsprache (FBS)/ Funktionsplan (FUP) – Lehnt sich an bekannte Symbole für Funktionsbausteine (DIN40900) an – Symbolumfang nicht auf logische Grundelemente beschränkt Merker, Zähler, Zeitgeber und frei definierbare Blöcke möglich – I/O-Zustände werden direkt als Ein-/Ausgangssignale verwendet – Übersichtliche Darstellung Umsetzung des Beispiels in FUP E1 E2 & E3 > –1 A1 A2 Video: SPS-Programmierung © 2015, IAS Universität Stuttgart 430 7.2 Programmierung von speicherprogrammierbaren Steuerungen (SPS) GRAFCET AT1 DIN EN 60848 – Spezifikationssprache für Darstellung von Ablaufbeschreibungen – Nachfolger des Funktionsplans (seit 1. April 2005) – Gliederung in 0 Struktur und Wirkungsteil vertikal Schritte und Transitionen horizontal Taster 1 1 Lampe :=1 Taster – Grundelemente von GRAFCET Schritte „Initialisierung“ „Lampe bleibt aus“ 2 „Lampe bleibt an“ Taster Transitionen 3 Lampe :=0 Lampe :=0 Aktionen Taster Kommentare „Lampe bleibt an“ Struktur © 2015, IAS Universität Stuttgart Wirkungsteil 431 7.2 Programmierung von speicherprogrammierbaren Steuerungen (SPS) AT1 Frage zu Kapitel 7.2 Bei der Programmierung von Speicherprogrammierbaren Steuerungen (SPS) werden so genannte Programmiergeräte verwendet. Warum sind diese notwendig? Antwort Notwendige Programmierumgebung kann nicht auf der SPS selbst ausgeführt werden. Programmierung auf „Host Computer“, dann Laden des Programmcodes auf SPS. © 2015, IAS Universität Stuttgart 432 AT1 § 7 Programmiersprachen für die Automatisierungstechnik 7.1 Grundbegriffe 7.2 Programmierung von speicherprogrammierbaren Steuerungen (SPS) 7.3 Universelle Programmiersprachen für die Automatisierungstechnik 7.4 Konzepte der Parallelprogrammierung © 2015, IAS Universität Stuttgart 433 7.3 Universelle Programmiersprachen für die Automatisierungstechnik AT1 C und C++ als universelle Programmiersprachen C: – – – – – Maschinennahe effiziente Systemprogrammiersprache flexibel wie Assembler Kontrollflussmöglichkeiten höherer Programmiersprachen universelle Verwendbarkeit begrenzter Sprachumfang C++: – – – Erweiterung von C um Objektorientierung Beibehaltung der Effizienz von C Verbesserung der Produktivität und Qualität Hybride Programmiersprache Concurrent C: Erweiterung von C um Konzepte zur Echtzeitverarbeitung © 2015, IAS Universität Stuttgart 434 7.3 Universelle Programmiersprachen für die Automatisierungstechnik AT1 Sprachkonzepte von C – Vier Datentypen: char, int, float, double – Zusammenfassung von Daten: Vektoren, Strukturen – Kontrollstrukturen: if, switch, while, do-while, for, continue, break, exit, goto – Ein-/Ausgabe: Bibliotheksfunktionen – große Vielfalt an Bit-Manipulationsmöglichkeiten – schwaches Typkonzept – getrennte Kompilierbarkeit von Sourcefiles – keine expliziten Möglichkeiten für Parallelverarbeitung © 2015, IAS Universität Stuttgart 435 7.3 Universelle Programmiersprachen für die Automatisierungstechnik AT1 Sprachkonzepte von C++ – Klasse (class) Datenstruktur mit Daten und Methoden (memberfunction) – Konstruktor (constructor) Anlegen einer Instanz einer Klasse (Objekt) – Destruktor (destructor) Freigabe von Klassenobjekten – Überladen von Funktionen (overloading) – Datenkapselung (encapsulation) – Vererbung (inheritance) – Polymorphismus Auslösung unterschiedlicher Verarbeitungsschritte durch Botschaften © 2015, IAS Universität Stuttgart 436 7.3 Universelle Programmiersprachen für die Automatisierungstechnik AT1 Eignung von C und C++ für die Echtzeitprogrammierung (1) – C und C++ enthalten keine Echtzeit-Sprachmittel – Einsatz von Echtzeit-Betriebssystemen zur Realisierung von Echtzeitsystemen Aufruf von Betriebssystemfunktionen im C-Programm – Bereitstellung von Bibliotheken © 2015, IAS Universität Stuttgart 437 7.3 Universelle Programmiersprachen für die Automatisierungstechnik AT1 Eignung von C und C++ für die Echtzeitprogrammierung (2) Programmiersprachen C und C++ Am häufigsten verwendete Programmiersprache für Echtzeit-Anwendungen – große Anzahl und Vielfalt an Unterstützungswerkzeugen – gut ausgebaute Programmierumgebungen – für die meisten Mikroprozessoren sind Compiler verfügbar – Anschluss an Echtzeitbetriebssysteme wie QNX, OS9, RTS, VxWorks Vorsicht bei objektorientierten Sprachmitteln: – nicht-deterministisches Laufzeitverhalten – schlechte Speicherplatzausnutzung © 2015, IAS Universität Stuttgart 438 7.3 Universelle Programmiersprachen für die Automatisierungstechnik AT1 Java als universelle Programmiersprache – Objektorientierte Konzepte – Interpretierung des Codes schneller Entwicklungszyklus schlechtes Laufzeitverhalten und hoher Speicherplatzbedarf höhere Portabilität – Bereitstellung eines Speichermanagers – Verzicht auf herkömmliche Zeigertechnik – Strikte Typprüfung zur Kompilier- und Laufzeit – Leichtgewichtsprozesse – GUI-Klassenbibliotheken © 2015, IAS Universität Stuttgart 439 7.3 Universelle Programmiersprachen für die Automatisierungstechnik AT1 Unterschiede zu C++ – Keine Preprozessoranweisungen wie #define oder #include – keine typedef-Klauseln – Structures und Unions in Form von Klassen – keine Funktionen – keine Mehrfachvererbung – kein goto – kein Überladen von Operatoren – umfangreiche Klassenbibliothek Basisklassen (Object, Float, Integer) GUI-Klassen Klassen für Ein-und Ausgabe Klassen für Netzwerkunterstützung © 2015, IAS Universität Stuttgart 440 7.3 Universelle Programmiersprachen für die Automatisierungstechnik AT1 Ausführung von Java-Programmen (1) Java C Compiler Java Quellcode C Code Java Class Compiler Java Bytecode Applikation AOT Compiler C Compiler Objektcode Objektcode Applikation Applikation inkl. Laufzeitumg. inkl. Laufzeitumg. OS OS Zielsystem Zielsystem Applikation Applikation Java API Java API JVM JIT Compiler Java API Java OS OS Zielsystem OS Zielsystem JVM – Java Virtual Machine Java Zielsystem JIT – Just-In-Time-Compiler © 2015, IAS Universität Stuttgart AOT – Ahead-Of-Time-Compiler 441 7.3 Universelle Programmiersprachen für die Automatisierungstechnik AT1 Ausführung von Java-Programmen (2) Zweistufiges Übersetzungsverfahren: 1. Stufe: 2. Stufe Auf Entwicklungssystem Auf Zielsystem Auf Entwicklungssystem - Interpretation - Just-in-time Compilierung - direkte Ausführung auf Java Hardware - Ahead-of-time Compilierung - Übersetzung nach C Portabilität: auf Bytecode-Ebene auf Quellcodeebene Speicherbedarf: Interpreter / JIT Compiler gesamte Klassenbibliotheken > 1 Mb Laufzeitumgebung benötigte Klassenbibliotheken > 150 kb Laufzeitbedarf: Interpretation / Just-in-time Compilierung hoch direkte Ausführung gering © 2015, IAS Universität Stuttgart 442 7.3 Universelle Programmiersprachen für die Automatisierungstechnik AT1 Eignung von Java für die Entwicklung von Echtzeitsystemen Anwendungsfelder – rapid prototyping im Client/Server-Bereich – multimediale Darstellungen (Video, Sound, Animation) – Intranetapplikationen – Echtzeitanwendungen Speicherverwaltung (garbage collection) hoher Speicherbedarf schlechtes Laufzeitverhalten © 2015, IAS Universität Stuttgart 443 7.3 Universelle Programmiersprachen für die Automatisierungstechnik AT1 Echtzeitsprachmittel in Java – Eingabe und Ausgabe von Prozesswerten vergleichbar mit C/ C++ – Parallelität keine Prozessunterstützung Leichtgewichtsprozesse Zeitscheibenverfahren – Synchronisierung Monitore Semaphorvariablen – Interprozesskommunikation nur für Leichtgewichtsprozesse über gemeinsame Daten – Bitoperationen vergleichbar mit C/ C++ © 2015, IAS Universität Stuttgart 444 7.3 Universelle Programmiersprachen für die Automatisierungstechnik AT1 Real-Time Java Erweiterungen der Sprache Java, um Echtzeiteigenschaften Echtzeitanforderungen realisieren zu können. Erweiterungen – – – – 1. Scheduling Sicherstellung, dass Sequenzen von eingeplanten Objekten rechtzeitig und berechenbar ausgeführt werden 2. Speichermanagement Erweiterung des Speichermodells um für Echtzeitanwendungen deterministisches Verhalten zu ermöglichen 3. Synchronisation Spezifikation der Zuteilungsalgorithmen mit Unterstützung der „priority inheritance“ und „priority ceiling“-Methoden und unter Vermeidung des Problems der Prioritäteninversion 4. Asynchrone Ereignis-Behandlung Gewährleistung, dass das Programm mit einer großen Anzahl gleichzeitiger Ereignisse (bis zu mehreren 10000) umgehen kann. © 2015, IAS Universität Stuttgart 445 7.3 Universelle Programmiersprachen für die Automatisierungstechnik AT1 Erweiterungen (2) – 5. Asynchrone Ausführungsunterbrechung (ATC) Möglichkeit der Ausführungsunterbrechung eines Threads bei Eintreffen eines asynchronen Ereignisses (z.B. Timerablauf) – 6. Asynchrone Thread-Terminierung Gewährleistung einer planmäßigen Terminierung und Speicherfreigabe von Threads ohne Deadlockgefahr – 7. Physikalischer Speicherzugriff Spezielle API (Application Programming Interface) für einen direkten Speicherzugriff – 8. Exceptions Definition von neuen Exceptions (Ausnahmen) und neuer Behandlung von Exceptions im Zusammenhang mit ATC und Speicherreservierung © 2015, IAS Universität Stuttgart 446 7.3 Universelle Programmiersprachen für die Automatisierungstechnik AT1 Mobile Endgeräte in der Automatisierungstechnik Leistungsfähige Hardware Multicore CPU Hochauflösendes Multitouch-Display Sensoren Gestensensor Helligkeitssensor Beschleunigungssensor & Gyroskop Kameras & Mikrofon Kommunikationsschnittstellen Funkmodule für GSM, UMTS, LTE… WLAN Bluetooth NFC Quellen: Apple, Samsung © 2015, IAS Universität Stuttgart 447 7.3 Universelle Programmiersprachen für die Automatisierungstechnik AT1 Mobile Betriebssysteme – Android ca. 99 % Marktanteil Objective C C# / C++ – Windows Phone – … Stand: 2011 © 2015, IAS Universität Stuttgart Stand: 2014 448 Quelle: http://www.idc.com/getdoc.jsp?containerId=prUS25450615 – iOS Java 7.3 Universelle Programmiersprachen für die Automatisierungstechnik AT1 Beispiel Android Betriebssystem und Softwareplattform für mobile Endgeräte, seit 2008 offiziell als freie, quelloffene Software verfügbar Smartphones Auto Open Handset Alliance (gegründet von Google) Tablets TV Wearables – Basiert auf einem Linux-Kernel – Herstellerspezifische Modifikationen und Erweiterungen – Keine Lizenzgebühren für Gerätehersteller, allerdings starke Vorgaben bei Einbindung von proprietären Google-Apps © 2015, IAS Universität Stuttgart 449 7.3 Universelle Programmiersprachen für die Automatisierungstechnik AT1 Elementare Anwendungskomponenten von Android Apps für Android werden in Java programmiert. Das Android SDK (Software Development Kit) stellt hierfür Erweiterungen bereit, die die Besonderheiten von mobilen Endgeräten berücksichtigen. Hauptbestandteile einer Android-App: Stellt Oberfläche und Programmlogik eines ProgrammFensters dar Activity Service Übernimmt Aufgaben im Hintergrund, z.B. Kommunikation Android Kapselt Lese-/Schreibzugriffe auf Daten der App, z.B Datenbanken Content Provider © 2015, IAS Universität Stuttgart Broadcast Receiver Empfängt und reagiert auf Systemmeldungen und Ereignisse 450 7.3 Universelle Programmiersprachen für die Automatisierungstechnik AT1 Intent-Konzept von Android zur Komponentenkommunikation Komponenten bzw. Apps kommunizieren in Android über Absichtserklärungen (Intents). Dabei können Funktionen aufgerufen und Daten ausgetauscht werden. Expliziter Intent Activity B Activity A App C Bsp: Aufruf einer konkreten Komponente, adressiert über deren Namen Impliziter Intent Activity A © 2015, IAS Universität Stuttgart OS Bsp: Aufruf einer beliebigen Komponente, adressiert über die Beschreibung einer geforderten Funktionalität (z.B: ACTION_DIAL) 451 7.3 Universelle Programmiersprachen für die Automatisierungstechnik AT1 Erweiterung von Android für Echtzeitanwendungen Standard Android Basiert auf Linux Kein preemptives Scheduling implementiert Unvorhersagbare Verzögerungen durch Garbage Collection Keine manuelle Vorgabe von Prozessprioritäten Nicht für harte Echtzeitanforderungen geeignet * Quelle: RWTH Aachen, Igor Kalkov, Prof. Dr.-Ing. Stefan Kowalewski © 2015, IAS Universität Stuttgart RTAndroid * Preemptives Scheduling durch RT_PREEMPT-Patch Anpassung der Virtual Machine und der Speicherverwaltung Garbage Collection ohne Blockierung kritischer Echtzeitprozesse Priorisierung von Services (Prozessen) Rückwärtskompatibel zu NichtEchtzeit-Apps Beispiel für Erweiterung von Android um Echtzeitkonzepte 452 7.3 Universelle Programmiersprachen für die Automatisierungstechnik AT1 Frage zu Kapitel 7.3 Welche C++-Sprachmittel sind problematisch für ein deterministisches Laufzeitverhalten eines Programms? Antwort f Zeiger-Arithmetik Polymorphismus Exceptions f Kapselung © 2015, IAS Universität Stuttgart 453 7.3 Universelle Programmiersprachen für die Automatisierungstechnik AT1 Frage zu Kapitel 7.3 Welchen Aussagen bezüglich des Java-Garbage-Collector-Mechanismus stimmen Sie zu? Antwort f Der Ausführungszeitpunkt des Garbage Collectors muss manuell festgelegt werden. f Belegte Ressourcen sollten im Destruktor einer Klasse freigegeben werden. Durch den Garbage Collector führen identische Systembedingungen zu unterschiedlichem zeitlichem Verhalten. © 2015, IAS Universität Stuttgart 454 AT1 § 7 Programmiersprachen für die Automatisierungstechnik 7.1 Grundbegriffe 7.2 Programmierung von speicherprogrammierbaren Steuerungen (SPS) 7.3 Universelle Programmiersprachen für die Automatisierungstechnik 7.4 Konzepte der Parallelprogrammierung © 2015, IAS Universität Stuttgart 455 Quelle: http://gcn.com/Articles/2008/04/11/The-return-of-Ada.aspx?Page=1 am 16.03.2014 7.4 Konzepte der Parallelprogrammierung AT1 Last fall, contractor Lockheed Martin delivered an update to the Federal Aviation Administration's next-generation flight data air traffic control system ' ahead of schedule and under budget, which is something you don't often hear about in government circles. … Military developers stuck with the venerable C programming language they knew well, or they moved to the up-and-coming C++. A few years later, Java took hold, as did Web application languages such as JavaScript. However, Ada never vanished completely. In fact, in certain communities, notably aviation software, it has remained the programming language of choice. … © 2015, IAS Universität Stuttgart 456 7.4 Konzepte der Parallelprogrammierung AT1 Eigenschaften von Ada im Sinne der Echtzeitprogrammierung – Echtzeit-spezifische Eigenschaften • Unterstützung absoluter und relativer Zeitanforderungen • Ausführung paralleler Abläufe • Priorisierung und Scheduling von parallelen Abläufen Es gibt weitere Konzepte, die Ada in Bezug auf das Software-Engineering und die Wiederverwendung besonders auszeichnen. © 2015, IAS Universität Stuttgart 457 7.4 Konzepte der Parallelprogrammierung AT1 Konzepte der Parallelprogrammierung – Notwendigkeit auf gleichzeitig stattfindende Ereignisse reagieren zu können Konzept „paralleler“ Rechenprozesse zur Bearbeitung paralleler Abläufe – Direkte Unterstützung von Rechenprozesses in Programmiersprachen durch eigenes Sprachmittel z.B. “Task” Programmeinheit “Task” – Task als parallel ablaufende, abgeschlossene Befehlssequenz – Task als gekapselte Einheit Deklarationen innerhalb einer Task sind nicht nach außen sichtbar – Kommunikation zwischen Tasks unterschiedlich realisierbar „message passing“ und „shared variables“ © 2015, IAS Universität Stuttgart 458 7.4 Konzepte der Parallelprogrammierung AT1 Realisierung von Tasks – Spezifikation und Implementierung von Tasks in Unterprogrammen oder in Paketen möglich Paket Einbindung des Pakets; Task1; Task2; Hauptroutine Task3; Anweisungen in Task3; Paketrumpf Anweisungen in Task1; Programmcode der Hauptroutine Anweisungen in Task2; Einplanung von Task3 © 2015, IAS Universität Stuttgart 459 7.4 Konzepte der Parallelprogrammierung AT1 Task-Typen und Task-Objekte – Task-Typen definieren Vorlagen für die Instanziierung von Task-Objekten – Tasks des selben Typs besitzen ähnliche Eigenschaften und Funktionalität – Individuelle Task-Objekte durch Parametrierung bei der Instanziierung General Task-Typ monitorValue; Anweisungen in monitorValue; Einbindung von General Hauptroutine Deklaration von Task-Objekten M1 vom Task-Typ monitorValue; M2 vom Task-Typ monitorValue; M3 vom Task-Typ monitorValue; Task-Typ Spezifikation / Implementierung © 2015, IAS Universität Stuttgart Programmcode der Hauptroutine 460 7.4 Konzepte der Parallelprogrammierung AT1 Synchronisierung von Tasks Synchronisierungskonzepte – Logische Synchronisierung Definition einer Ablaufreihenfolge der Tasks Rendez-Vous-Konzept – Betriebsmittel-orientierte Synchronisierung Regeln für den Zugriff auf gemeinsam genutzte Betriebsmittel Geschützte Betriebsmittel (protected units) © 2015, IAS Universität Stuttgart 461 7.4 Konzepte der Parallelprogrammierung AT1 Rendezvous-Konzept (1) – Handshake-Verfahren • Festlegung zeitlicher Synchronisierungspunkte zwischen Tasks • Beiderseitiges Warten der Tasks – Rendezvous hat aus Aufrufersicht die Gestalt eines Prozeduraufrufs – Definition von Aufrufvereinbarung (entry) und Aufrufpunkt (accept) Aufrufende Task1 Empfangende Task2 Aufrufer wartet auf Bestätigung durch Empfänger. Solange pausiert dieser. Ggf. Datentransfer Aufruf der Synchronisation Rendezvous Ggf. Datentransfer © 2015, IAS Universität Stuttgart Beide Tasks starten synchronisiert 462 7.4 Konzepte der Parallelprogrammierung AT1 Rendezvous-Konzept (2) – Deklaration der Aufrufvereinbarung in Task-Spezifikation – Aufrufe und Aufrufpunkte im Task-Rumpf implementiert – Funktionsprinzip: Task ruft Aufrufpunkt einer anderen Task auf Task1 mit Aufrufvereinbarung Task2 mit Aufrufvereinbarung Task3 mit Aufrufvereinbarung Anweisungen in Task1; Anweisungen in Task2; Anweisungen in Task3; Eigener Aufrufpunkt; Eigener Aufrufpunkt; Eigener Aufrufpunkt; Aufruf des Aufrufpunkts von Task 2; Aufruf des Aufrufpunkts von Task 3; Aufruf des Aufrufpunkts von Task 1; Weitere Anweisungen; Weitere Anweisungen; Weitere Anweisungen; Beispiel realisiert Ablaufreihenfolge T1, T2, T3, T1…. © 2015, IAS Universität Stuttgart 463 7.4 Konzepte der Parallelprogrammierung Beispielablauf AT1 T1 T2 T3 Aufrufpunkt T2; Aufrufpunkt T3; Waiting Waiting Aufruf von T2; Aufrufpunkt T1; Waiting Aufruf von T2; Aufruf von T2; © 2015, IAS Universität Stuttgart 464 7.4 Konzepte der Parallelprogrammierung AT1 Geschützte Betriebsmittel (1) – Problem: Zugriff auf gemeinsam genutzte Betriebsmittel – Monitor-Konzept für exklusiven Zugriff Geschützte Anweisung Anfrage einer Task … – Schnittstelle als geschützte Anweisung – Zugriff auf gemeinsames Betriebsmittel durch internen Monitor geregelt Geschützte Anweisungen werden nicht parallel ausgeführt Monitor Gemeinsames Betriebsmittel Sequenzielle Abarbeitung von gleichzeitigen Anfragen Exklusiver Zugriff auf gemeinsame Betriebsmittel © 2015, IAS Universität Stuttgart 465 7.4 Konzepte der Parallelprogrammierung AT1 Geschützte Betriebsmittel (2) Geschützte Anweisungen Protected Eingangsfunktion; Prozeduren; Funktionen; – Geschützte Anweisungen schließen sich gegenseitig aus – Alle Variablen von geschützten Einheiten müssen als „private“ deklariert werden Aufrufvereinbarung; – Eine Prozedur kann gemeinsames Betriebsmittel beliebig verändern Paketrumpf von Protected Rumpf der Eingangsfunktion; Festlegung der Aufrufbedingung; Funktionen besitzen nur Lesezugriff – Aufrufpunkte als geschützte Anweisungen Anweisungen; © 2015, IAS Universität Stuttgart 466 7.4 Konzepte der Parallelprogrammierung AT1 Kommunikation zwischen Tasks – Synchrone Kommunikation • Erweiterung der Rendezvous-Synchronisierung um Datenaustausch Gegenseitiges Warten Datenaustausch im Zuge des Rendezvous Daten nur innerhalb des Rendezvous gültig – Asynchrone Kommunikation • Datenaustausch mittels gemeinsamer Variablen Geschützte Operationen für Zugriff Kein Warten/Blockieren bei Kommunikation © 2015, IAS Universität Stuttgart 467 7.4 Konzepte der Parallelprogrammierung AT1 Zeitoperationen – Verzögerung des Ablaufs • Bis zu einem bestimmten Zeitpunkt • Für eine feste Zeitdauer – Ada-Befehle: “delay” bzw. “delay until” – Zeiteinheiten und Operationen im Standardpaket definiert • Zeiteinheiten für Standard-Anwendungen: Sekunden (seconds) • Zeiteinheiten für Echtzeit-Anwendungen: ms, μs, ns • Operationen Addition und Subtraktion von Zeitvariablen Auslesen der Systemzeit – Während einer Verzögerung führt der Prozessor eine andere Task aus – Nach Ablauf einer Verzögerung evtl. weitere Verzögerungen bis zur erneuten Prozessorzuteilung Ausführungsunterbrechung durch höherpriore Task © 2015, IAS Universität Stuttgart 468 7.4 Konzepte der Parallelprogrammierung AT1 Beispiele für Zeitoperationen T1 mit Vereinbarungen; T2 mit Vereinbarungen; Vereinbarung einer Zeitdauer von 1 ms; Vereinbarung einer Zeitdauer von 1 ms; Vereinbarung des nächsten Aufrufs next_call; aktuelle Zeit Aufruf einer Funktion ; Delay von 10*1 ms; next_call abhängig von Clock; Aufruf einer Funktion read_sensor; Delay bis next_call; Schleife Ausführung von read_sensor; Task T1 laufend blockiert 5 15 22 32 t – Aufruf einer Funktion durch eine Task 10ms nach der letzten Ausführung Zeit zwischen Aufrufen hängt von der Ausführungsdauer ab – Aufruf einer Funktion alle 10 ms durch eine Task Unterprogramm wird zu festen Zeitpunkten aufgerufen © 2015, IAS Universität Stuttgart 469 7.4 Konzepte der Parallelprogrammierung AT1 Modularisierte Ausnahmebehandlung – Ausnahmefehler auf Grund irregulärer Operationen möglich Ausnahmebehandlung (exception handling) “Exception Handling” Konzept – Ausführung eines “Exception Handling Block” bei Auftreten einer Exception – Exception Handling Blocks direkt in der Programmeinheit implementiert – Mehrere Exceptions können in einem Handling Block behandelt werden – Nicht behandelte Exceptions werden an übergeordnete Einheit übergeben – Exceptions durch Laufzeitumgebung oder Programmcode ausgelöst Laufzeitumgebung: vordefinierte Exceptions Programmcode: Anwender-definierte Exceptions © 2015, IAS Universität Stuttgart 470 7.4 Konzepte der Parallelprogrammierung AT1 Erweiterung der Echtzeitprogrammierkonzepte (1) – Tasks mit dynamischen Prioritäten Basispriorität wird auf Basis der Spezifikation festgelegt Tatsächliche Priorität kann davon abweichen Bsp. bestimmt durch “Priority inheritance protocol” – Hinweis: In Ada bedeutet eine niedrigere Zahl eine niedrigere Priorität! Implementierung Spezifikation Task1 mit Priorität 10; Anweisungen in Task1; T1 ruft T2 auf Basispriorität Task2 mit Priorität 1; Aufruf des Aufrufpunkts von Task2; T2 wird mit der Priorität von Anweisungen in Task2; T1 ausgeführt Eigener Aufrufpunkt; Dynamischer Prioritätswechsel © 2015, IAS Universität Stuttgart Eigene Priorität setzen; 471 7.4 Konzepte der Parallelprogrammierung AT1 Erweiterung der Echtzeitprogrammierkonzepte (2) – Scheduling-Verfahren Scheduling-Verfahren kann frei festgelegt werden Pragma-Anweisung “Task_Dispatching_Policy” Standard-Verfahren: Feste Prioritäten, FIFO bei gleicher Priorität Weitere Verfahren können implementiert und dann verwendet werden – Zugriff auf geschützte Einheiten per “Priority Ceiling Protocol” Prioritätsschranke von geschützten Einheiten kann in deren Spezifikation definiert werden Default-Wert: Höchste Systempriorität Prioritätsvererbung garantiert Deadlock-Freiheit! © 2015, IAS Universität Stuttgart 472 7.4 Konzepte der Parallelprogrammierung AT1 Frage zu Kapitel 7.4 Welche der genannten Synchronisierungskonzepte würden Sie für folgende Aufgaben einsetzen? A) In einer Automatisierungseinheit soll der Task „Bohren“, erst nachdem der Task „Fräsen“ abgelaufen ist, ausgeführt werden. B) In einer automatisierten Montage müssen die eingesetzten Roboterarme ihre Initialposition nach jeder Ausführung nachjustieren. Die hierzu verwendeten Initialwerte werden nach jedem Durchlauf zentral angepasst. Antwort A) Logische Synchronisierung B) Betriebsmittel-orientierte Synchronisierung © 2015, IAS Universität Stuttgart 473 Kapitel 7: Vorbereitungsfrage AT1 Vorbereitungsfrage zu Kapitel 7 Frage 1: SPS (WS 10/11) Geben Sie folgende Aussage in einem Funktionsplan wieder: Ausgangssignal Q1 soll dauerhaft anliegen, sobald Eingang I1 oder I2 gleichzeitig mit I3 aktiv waren. I4 deaktiviert Ausgangssignal Q1 und löst Ausgangssignal Q2 aus. © 2015, IAS Universität Stuttgart 474 AT1 Kreuzworträtsel 1 3 19 A R B 25 D I T R 30 I E R U N G 47 A U D 51 A S 4 M K O O 8 D E A D U L 14 F L I 23 P E R S V E R S M B P I N T E L I D V 5 N T A K T P O 9 L I N E W N E T R 15 E L R I 20 R E D U N U K 24 P F I T A E T H L L I G E N T R 32 M I T T E L E O 35 T D L 38 I I D E A D M A R 41 D E Z E N T R A L 42 R F N M 45 J I Z A V L K T O M A T I S I E R E O Y N C H R O N L A N 10 K O M P A I V E L O C D A N Z 27 28 R I E P 31 N A C H R D 33 W E R T U M Z A 36 V S E N L O C K 39 U S T U S E T 46 M U N G S G R 52 R E C H 54 E I N P L A © 2015, IAS Universität Stuttgart F E L D B I 7 F P R A T O R A R A K L 16 17 A S S E M B L 21 E I E C K L H R 26 T P R O Z E Z C E O I C H T E N F A T T 34 S E T Z E R S Y O 37 S O R G L E I T L 40 E T Z S T E L L M C R 43 H R A S T E R D 48 A D U T L O T Z E I T I G K N E 55 N U N G H A N 2 U S 6 C O D E S H 11 I M I E B E 18 E R P 22 E R A G O K I Z T S S G E K O T S R E S E H R P L A N E C H N I T T T C H Z E I T B E N V E R F N E C H E N P C H E I B E 12 N I S L O E 13 M S A E P Q H U O E R N P P E L T T 29 S I T E U L S T E L L C I G K E I P A H R E N O 44 R O Z E S E I S M 49 50 P R O F I B U S U B E L E I T S T 53 C S M A D S H A K E N T E T S 475 AT1 Kreuzworträtsel Senkrecht Waagerecht 1 2 3 5 1 7 9 12 13 14 17 18 19 21 22 23 24 27 28 29 32 33 35 40 42 44 45 47 48 50 Stapelverarbeitung in der Reihenfolge des Eintreffens (4) Prinzip der Datenübertragung beim Interbus-S (15) Paket in Ada (5) Realisierung des Industrial Ethernets mit synchronem Sendebereich und MasterSlave-Kommunikation (9) Gleichzeitige Datenübertragung auf mehreren Leitungen (8) Unterbrechungsanforderung (9) Synchronierungs-Konstrukt (9) Bez. für Aktionen, die in bestimmter Reihenfolge angeordnet sind (12) Darstellung, ähnlich Blockbild (10) Ein-Chip-Computer (15) Automatisierungstechnisches Analogon zur "Taktischen Ebene" (16) Verfahren zur Kollisionsvermeidung beim Buszugriff (12) Bezeichnung für Systeme bei denen die Verarbeitung der Programme zeitlich mit den in externen Systemen ablaufenden Vorgängen Schritt hält (14) „Muskeln“ des Automatisierungssystem (7) Unterbrechende Prozessorzuteilung (8) Erhalt der Funktionsfähigkeit trotz Auftreten eines Fehlers (14) Ada-Konzept zur Synchronisierung (10) Abkürzung für Rechner, die speziell auf ein industrielles Einsatzfeld ausgelegt sind (3) Alternative Bezeichnung für objektbezogene Prozesse (14) Nichtlinearer Filteralgorithmus (12) Menge aller von einem Scheduler verwalteter Taks (7) Taktgeber (5) Vergabe von Prozessorrescourcen an ablaufbereite Prozesse (10) Hilfsmittel zur Vereinfachung der Maschinensprache (5) Bezeichnung für zwei Aktoren eines Rechenprozesses, die gleichzeitig ausgeführt werden können (8) Grundlage für die Plattformunabhängigkeit von Java (3) Echtzeit-Programmiersprache (3) Spezifische Nachricht für Senderechtserteilung (5) Abkürzung für eine Blockschaltbild-orientierte SPS-Programmiersprache (3) © 2015, IAS Universität Stuttgart 4 6 8 10 11 15 16 20 25 26 30 31 32 34 36 37 38 39 41 43 46 47 49 51 52 53 54 55 Kommunikationssystem in unmittelbarer Anlagennähe (7) Schaltplan-ähnliche Darstellung für SPS-Programme (11) Realisierung zur Umwandlung des nichtelektrischen Signals einer Drehbewegung in ein digitales Signal (11) Spätester Abgabezeitpunkt einer Task (8) Schaltung zum Spannungsvergleich (10) Zuordnung der Sendeberechtigung zum Busteilnehmer in dynamischen Segment bei FlexRay (8) Permanente Blockierung (8) Maschinennahe Programmiersprache (9) Mehrfaches Vorhandensein von Hardware für die gleiche Aufgabe (9) Verschiedenartigkeit von Software bei gleicher Funktion (11) Bezeichnung für die direkte Verbindung von Rechnersystemen mit einer Anlage (16) Bezeichnung für Sensoren/Aktoren mit integrierter Busankopplung (11) Spezifikation des Nachrichtenaustauschs in zeitgesteuerten Bussystemen (19) Langsamer Analog-Digital-Umsetzer (18) Verbindung zwischen Systemen (13) Messwertaufnahmeeinrichtung (6) Fähigkeit, auf mehrere Dinge gleichzeitig zu reagieren (16) Verklemmung (8) Verfahren zur Signalanpassung bei Sensoren mit nicht-linearer Kennlinie (22) Örtlich verteilt (9) Von Echtzeit-OS gesteuerter Vorgang der Abarbeitung eines sequenziellen Programms (13) Kommunikationssteuernde Einheit bei deterministischen Buszugriffsverfahren (6) Bezeichnung für den Umfang einer Automatisierung (20) Bussystem mit hybrider Kommunikation (8) Organisation des zeitlichen Ablaufs während der Programmausführung (9) Fähigkeit zur richtigen Zeit zu reagieren (15) Verfahren mit zufälligen Buszugriff (4) Übergang vom Prozesszustand "ruhend" in den Zustand "bereit" (10) Engl. Bezeichnung für eine gemeinsame Ausführung eines Programmstücks auf Empfängerseite (9) 476 AT1 Index (1) ABK acatech accept Adress-Arbitrierung Aktor Aktor-Sensor-Bussystem Amdahl‘sches Gesetz Analog-Digital-Umsetzung Anlagenautomatisierung Anpassung Anweisungsliste Anzeige- und Bedienkomponente Arbitrierung AS AS i AS-Interface Assemblerprogrammierung Assemblersprache Asymmetrische Multiprozessorsysteme (AMP) Asynchrone Kommunikation asynchrone Programmierung © 2015, IAS Universität Stuttgart 93 46 462 204 *150* 214 395 171 *38*, 44, 421 176, 177 *427* 93 223 426 214 198, 212 *416* 414 400 312 266, *277*, 282, 290, 366 477 AT1 Index (2) Ausführbarkeitstest automatisiertes Gesamtsystem Automatisierungs-Computer Automatisierungs-Hierarchie Automatisierungs-Softwaresystem Automatisierungsfunktionen Automatisierungsgrad Automatisierungsstrukturen AWL *331* *22*, 24 137 113, 117 53 59 *31*, 44 99, *106* 426 Betriebsmittel Betriebssystem Bit stuffing Bitbus Bus-Struktur Buszugriffsverfahren *340* *338* 224 198 195 197 Cache-Speicher CAN Carrier Sense Multiple Access Counter 349 212, *222* 202 87 © 2015, IAS Universität Stuttgart 478 AT1 Index (3) CPU CSMA/CA-Verfahren CSMA/CD-Verfahren cyber-physisches System 87 204, 223 203 46 Datenkapselung Datenkommunikation deadlock Deadlock delay Destruktor Determiniertheit dezentrale Anordnung Dezentrale Buszuteilung Dialogsystem dispatching table Diversität Doppelrechner-Struktur dynamisches Scheduling 436 311 *299* 351, 472 468 436 *260* 101 197 262 317 130 125 317 Earliest-Deadline-First-Verfahren 327, 332 © 2015, IAS Universität Stuttgart 479 AT1 Index (4) Echtzeit-Betriebssysteme Echtzeit-Kernel Echtzeit-Linux Echtzeit-Programmierung Echtzeit-System Echtzeit-UNIX Echtzeitbetrieb Echtzeitsprachmittel Einplanung Engineering-Tool Engineering-Tools entry EPROM ereignisgesteuerte Architektur EtherCAT Exception Handling 342, 343 341, 359, 403 358 *248* 261 341, 359, 403 *25* 421 *289* 93 95 462 87 282 238 470 Fabrik-Bus FBS Fehlertoleranz Feldbereich 52 *430* 116 *192* © 2015, IAS Universität Stuttgart 480 AT1 Index (5) Feldbuskonzepte Feldbussysteme Feldgeräte FIFO - Scheduling Filterung FlexRay Frequenzanaloge Sensoren Funktionsbausteinsprache Funktionsplan FUP *193* 190, *192* *192* *320* 178, 179 212, *230* 148 *430* *430* 426, *430* garbage collection Geschützte Betriebsmittel Gleichzeitigkeit Glättung 443 461, *465* 26, *258* 178 Hardware-Redundanz Harte Echtzeitsysteme Heterogener Multicore-Prozessor Homogener Multicore-Prozessor Honeywell 124 *253* 404 402 96 © 2015, IAS Universität Stuttgart 481 AT1 Index (6) hybride Programmiersprache 434 IEC 1131 Industrial Ethernet Industrie-PC Interbus-S Internet of Things Interrupt Interrupt Service Routine Interrupt-Verwaltung IPC isochron 76, 425 212, 235 88 *218* 407 87 352 *352* 88, 411 237 kleinster Spielraum Kommunikation Konstruktor Kontaktplan Kontrollierter Buszugriff kooperatives Scheduling KOP *329* *310* 436 *429* 198 318 426, *429* © 2015, IAS Universität Stuttgart 482 AT1 Index (7) Ladder Diagramm laxity LD least laxity Leiternetzwerk Leitsystemhersteller LIN livelock logische Synchronisierung 429 293 429 *329* 184 96 212 *299* 302 Makro Makroassemblersprache Maschinensprache Massenprodukte Mikrocomputer Mikrocontroller Mikroprogrammsprachen Mikroprozessor Mikrosegmentierung Minislot Mittelwertumsetzer *415* 415 414 85 86 *85*, 86, 411 414 86 236 *231* 173 © 2015, IAS Universität Stuttgart 483 AT1 Index (8) Modularisierung Momentanwertumsetzer Monitor-Konzept Monitore 457 173 *465* 444 Nachrichtenfahrplan nebenläufig Netz-Struktur nicht-preemptives Scheduling Notation 229 296 195 318 412 Örtliche Struktur 99 parallel Parallele Busse Parallelprogrammierung PNK Polymorphismus Poor-Man‘s-Multithreading Powerlink preemptives Scheduling 296 196 266 93 436 355 237 318 © 2015, IAS Universität Stuttgart 484 AT1 Index (9) Priority Ceiling Protocol Prioritätsvergabe Produktautomatisierung Profibus PROFIBUS Profinet IRT Programm-Generatoren Programmiersprachenparadigma prozedurale Sprachen Prozess-Signale Prozess-Signalerfassung Prozessführungsebenen prozessgekoppelt Prozessgrößen Prozessgrößenebene Prozessinformatik Prozessleitebene Prozessleitsystem Prozessnahe Komponente 472 291 *38*, 40, 421 198 212, *216* 237 *420* 412 419 *138* 139 110 31 *62* 58 24 58 24, 92, 411 93 quasi parallel 259 © 2015, IAS Universität Stuttgart 485 AT1 Index (10) RAM Rate-Monotonic ratenmonotones Scheduling Rechenprozess Rechtzeitigkeit Redundanz Rendez-Vous-Konzept Ring-Struktur Round-Robin-Verfahren 87 *325*, 333 *325* *286* 26, *254*, 262, 281 121 303, 461 195 321 schedulability test Scheduling Scheduling-Verfahren Schieberegister Schwarm-Intelligenz Semaphore Semaphorkonzept Semaphoroperation Semaphorvariable Semaphorvariablen Sensor *331* *316* *319* 220 407 303 *304* 304 304 444 50, *142* © 2015, IAS Universität Stuttgart 486 AT1 Index (11) Sensorelement Sensorsystem sequenziell Serielle Busse shared memory Signaldurchschaltung Simatic simultan Software-Redundanz Speicherhierarchie speicherprogrammierbare Steuerung Speicherverwaltung Spielraum Sprachhöhe SPS-Sprachen ST statisches Scheduling Stellglied Stern-Struktur strukturierter Text Symmetrische Multiprozessorsysteme (SMP) © 2015, IAS Universität Stuttgart *143* 145 296 196 311 156, 157, 167 96 296 129 349 411 349 293 412 76 428 317 50 195 *428* 398 487 AT1 Index (12) Synchrone Kommunikation synchrone Programmierung Synchronisierung Synchronisierungsverfahren Synchronität 312, 467 266, *268*, 282 299, *302*, *310* 303 297 Task Task-Typ TDMA-Verfahren technischer Prozess Technisches System Theorem von Liu und Layland Thread Token-Passing *286* 460 200 *17*, *19* 20 332 287 199 Ubiquitous Computing Überladen Unternehmensführungsebene 46 436 58 Verarbeitungsleistung Verfügbarkeit 111 111, 118 © 2015, IAS Universität Stuttgart 488 AT1 Index (13) Verklemmung Verlässlichkeit verteilte Automatisierungssysteme VERWALTUNGSBLOCK Vorhersehbarkeit VxWorks *299* 26 116 382 26 357 Weiche Echtzeitsysteme Wirkungsmäßige Struktur *253* 99 Yokogawa 96 zeitgesteuerte Architektur Zeitparameter Zeitscheibenverfahren Zeitsteuerung ZEITZÄHLER zentrale Anordnung Zentrale Buszuteilung Zufälliger Buszugriff Zustandsdiagramm 282 291 *321* *226* 379 100 197 202 289 © 2015, IAS Universität Stuttgart 489 AT1 Index (14) Zustandsführung Zuverlässigkeit ZYKLUS Zykluszeit-Bildung © 2015, IAS Universität Stuttgart 371 118 380 368 490