vorläufige Fassung - Beuth Hochschule für Technik Berlin

Transcrição

Beuth Hochschule für Technik Berlin
Fachbereich VI (Informatik und Medien)
Manfred Ottens
Richard Spyra
Rapid Control Prototyping
(Schneller Reglerprototypen-Entwurf)
Skript zur Lehrveranstaltung
(Vorläufige Version vom 18.04.2010)
Berlin, Sommersemster 2010
Vorwort
"Rapid Control Prototyping" heißt auf Deutsch "Schneller Reglerprototypen-Entwurf".
Die Phrase verbindet zwei Begriffe, den am Anfang einer Entwicklungsphase
liegenden "Entwurf" und den "Prototypen", der in der klassischen Entwurfphilosophie
eher am Ende einer Entwicklungsreihenfolge
angesiedelt ist. Dass der Entwurf
etwas mit Regelungstechnik zu tun haben muss, verrät das Wort Control.
Neu zu entwickelnde Regelalgorithmen werden im Allgemeinen, wenn der
Entwurfsprozess fach- und sachgerecht durchgeführt wird, auf der Basis eines
mathematischen Modells der Regelstrecke berechnet und simulativ auf einem PC an
einem ebenfalls simulierten Modell der Regelstrecke getestet und nachoptimiert.
Hierzu sind vertiefte Kenntnisse in Systemtheorie, Regelungstechnik und eines
geeigneten geeigneten Simulationswerkzeugs, z.B. Simulink der Firma Mathworks,
notwendig.
Zur Implementierung des entwickelten Regelalgorithmus sind dagegen völlig andere
Kenntnisse und Fähigkeiten notwendig. Der Regelalgorithmus läuft i. A. auf einem
Mikrocontroller oder, wenn es sich um eine größere zu regelnde Anlage handelt, auf
einem
leistungsfähigerem
PC
mit
höherem
Durchsatz.
Zur
weiteren
Durchsatzsteigerung muss der Regelalgorithmus in C oder teilweise sogar in
Assembler realisiert werden. Weil der Regelalgorithmus zur Beeinflussung eines
technischen Prozesses herangezogen wird, muss der Mikrocontroller die Fähigkeit
des Echtzeitbetriebs haben, d. h. er muß schritthaltend mit der zu beeinflussenden
Regelstrecke arbeiten. Dies kann insbesondere dadurch erschwert werden, dass die
notwendigen Berechnung des Regelalgorithmus in Gleitkommarechnung wie
ursprünglich in der Simulation durchgeführt werden. Zur weiteren Durchsatzerhöhung
würde es deshalb sinnvoll sein, den Regelalgorithmus vor seiner Implementierung in
die Zielhardware von Gleitkomma auf Festkommarechnung, die erheblich weniger
zeitintensiv ist, umzurechnen. Leider birgt aber Festkommaarithmetik die Gefahr des
Zahlenbereichsüberlauf und ungenauer Berechnung des Algorithmus.
Alle diese Einflussgrößen (Programmierung, Echtzeitbetrieb und Festkommarechnung),
die
vom
ursprünglichen
Entwurf
des
Algorithmus
auf
dem
Entwicklungssystem (PC) abweichen, bergen die Möglichkeit, unbekannte Fehler
vom Entwurf in die Implementierung einzuschleppen.
I
Vom CAE-Programm Matlab/Simulink wird eine durchgängige Entwicklungs- und
Implementierungsplattform für solche Reglerentwicklungen zur Verfügung gestellt,
die auf der Simulink Erweiterung "Realtime Workshop" aufbaut. Sie unterstützt den
Identifizierungsvorgang der Regelstrecke, die Simulation des dadurch gewonnenen
mathematischen Modells der Strecke, den Reglerentwurfsvorgang , die Simulation
des entworfenen Kreises und auch die Realisierung des Reglerprototypen in seiner
Zielumgebung. Der Implementierungsprozess des Regelalgorithmus, inklusive der
Realisierung seiner Echtzeitfähigkeit geschieht dabei quasi auf Knopfdruck.
Das vor Ihnen liegende Skript beschreibt ausführlich diese Entwurfs- und
Implementierungsstrategie, das Rapid Control Prototyping von Regelalgorithmen auf
der Basis des Realtime Workshops von Matlab/Simulink.
Wegen der Vielfalt der Wissensgebiete, aus denen man sich Kenntnisse erwerben
oder bereits haben
muss, kann dieses Skript nicht vollständig sein. Es setzt
zunächst auf den Gebieten Systemtheorie, Regelungstechnik, Systemidentifikation
und Matlab/Simulink Wissen voraus, wie es in den Skripten /2/,/3/, und /4/ sowie in
den Kapiteln 1, 2, 5.1, 5.2.1, 5.3.2 und 5.3.4 von /5/ beschrieben wird. Grundlegende
Kenntnisse des Aufbaus, der Funktion und der Programmierung von Mikrocontrollern
und über Echtzeitbetriebssysteme sollten ebenfalls vorhanden sein.
Aufbauend auf diesem Wissen werden die Grundzüge des Rapid Control Prototyping
so
weit
erläutert,
dass
die
entsprechenden
Matlab/Simulink-Werkzeuge
in
Laborübungen zu diesem Thema sinnvoll genutzt werden können. Für einen
vertiefenden Wissenserwerb wird häufig auf die Literatur verwiesen.
II
Inhalt
1
Einführung
1.1
Klassischer Softwareentwurf für eingebettete Systeme
1.1.1 Entwurfsphasenmodelle
1.1.2 Modellierungsverfahren
1.1.3 Realisierungsprobleme eingebetteter Systeme
1.2
1.2.1 Das Entwurfsphasenmodell
1.2.2 Werkzeuge zum Rapid Control Prototyping
1.2.3 Mit Matlab von der Systemspezifikation zum Objektkode
1.2.3.1
Konzeptorientiertes Prototyping
1.2.3.2
Implementierungsorientiertes Prototyping
1.2.4 Echtzeitbetrieb
1.2.5 Festkommaarithmetik
1.2.6 What is in the Loop?
2
3
Fachliches Umfeld
2.1
Systemtheorie
2.2
Systemmodellierung / Systemidentifikation
2.3
Regelungstechnik
2.4
Simulation dynamischer Systeme
Die Arbeitsumgebung Matlab/ Simulink
3.1
Ein Werkzeug zur Systemidentifikation
3.2
Ein Werkzeug zum Reglerentwurf
3.3
Ein Werkzeug zur Systemsimulation
3.3.1 Einbindung von Festkommaarithmetik
3.4
Das Real-Time Windows Target als Werkzeug zum konzeptorientierten Rapid Prototyping
3.4.1. Einleitung
3.4.2 Vorbemerkungen zum Betrieb des Real-Time Workshop /
Real-Time Windows Target
3.4.3 Bedienungsanleitung des Real-Time Workshop /
Real-Time Windows Targets
III
3.4.3.1
Prüfung der Installation des Echtzeitkerns
3.4.3.2
Anpassung der "RT In"- und "RT Out"-Blöcke
an die installierte A/D-DA-Wandler-Karte
3.4.3.3
Realisierung einer Realtime-Anwendung
3.4.3.4
Hardware-Ankopplung
3.4.3.5
Parametrierung des Real-Time Workshop /
Real-Time Windows Targets
3.4.3.6
Parametrierung der Simulationsblöcke
3.4.3.7
Starten einer Real -Time - Anwendung
3.4.3.8
Signalvisualisierung
3.4.4 Offsetabgleich der A/D-D/A-Wandlerkarte pci6025E
3.5
4
Embedded Coder und Target for Infineon C166 als Werkzeug zum
implementierungsorientierten Rapid Prototyping
Praktisches Rapid Control Prototyping
4.1
Identifikation des Steuerverhaltens der Regelstrecke
4.1.1 Statisches Verhalten
4.1.2 Dynamisches Verhalten
4.2
Identifikation des Störverhaltens der Regelstrecke
4.3
Simulation des Streckenverhaltens
4.4
Der Reglerentwurf
4.4.1 Kontinuierlicher Regler
4.4.2 Zeitdiskreter Regler
4.4.3 Zeitdiskreter Regler mit Festkommaarithmetik
4.5
Simulation des Regelkreises
4.5.1 Prüfung des Führungsverhaltens
4.5.2 Prüfung des Störverhaltens
4.5.3 Prüfung des Aussteuerbereich der Stellgröße
4.6
Implementierung des Reglers in das Anwendersystem
4.6.1 Software in the Loop
4.6.2 Hardware in the Loop
IV
1 Einführung
Software zur Regelung technischer Prozesse läuft i. A. in dezentral angeordneten
Steuergeräten, die einen Mikrocontroller und aufgabenspezifische Ein-/AusagabeHardware, angeordnet und verdrahtet auf einer gedruckten Schaltung enthalten.
Häufig sind diese Steuergeräte über ein Bussystem mit anderen Steuergeräten in
einer sinnvollen Hierarchie miteinander verknüpft. Ein Paradebeispiel sind moderne
Kraftfahrzeuge mit CAN-Bus /116/ gekoppelten, verteilten Steuergeräten für das
Motormanagement, die Getriebe-, die ESP-, die Klimasteuerung und andere
Funktionen eines modernen Autos. Oberklassenfahrzeuge enthalten heute bereits
mehr als fünfzig Mikrocontroller /1/.
Durch dies Komplexität wird die Entwurfsaufgabe der Steuersoftware zunehmend
anspruchsvoller. Kundenwünsche nach ständigen Neuerungen, z.B. automatische
Einparkhilfen oder die automatische Kommunikation zwischen Kraftfahrzeugen z. B.
zur Meldung von vor einem liegende Staus, ziehen den Zwang nach immer kürzeren
Entwicklungszeiten nach sich. Durch beide Forderungen, nämlich ständige
Neuerungen in immer kürzerer Zeit, wird die Qualitätssicherung ein zunehmendes
Problem.
Zur Vermeidung von Fehlern werden deshalb in frühen Entwicklungsphasen
Methoden zur abstrakten Spezifikation und Modellierung der zu lösenden Aufgaben
verwendet. Darüber hinaus wird beim Steuerungs-/Reglerentwurf schon sehr früh im
Entwicklungszyklus auf die Herstellung von Steuerungs-/Regelungsprototypen Wert
gelegt. Als Prototyp soll hier eine Einheit aus Hardware, die schon große Ähnlichkeit
mit der später in den Prozess zu integrierenden hat, und Software, die aus der
abstrakten Beschreibung -möglichst automatisch- Objektkode für den in der
Hardware befindlichen Mikrocontroller erzeugt wurde, verstanden werden.
Ein solcher Prototyp kann direkt in die endgültige, zu steuernde Systemumgebung
eingebettet werden, was allerdings voraussetzt, dass das Steuergerät in Echtzeit,
also schritthaltend mit der zu lösenden Steuer-/Regelaufgabe im Prozess arbeitet.
Integriert in seine spätere Umgebung offenbart ein solcher Prototyp beim Betrieb des
Gesamtsystems sowohl Fehler in der Hardware als auch in der Software.
Durch diesen "Schnellen Reglerprototypen-Entwurf" oder das gleichbedeutende
"Rapid Control Prototyping" (RCP) wird die Sicherheit, dass ein konzipiertes
Regelungskonzept die geforderten Aufgaben fehlerfrei erfüllt, schon relativ früh in der
1.1
Entwicklungsphase überprüfbar und kürzt damit den gesamtem Entwicklungsvorgang
erheblich ab. Mit Hilfe der in den nächsten Kapiteln dargestellte Methoden des RCP
kann das beschriebene Entwurfkonzept durchgeführt werden.
Zunächst wird im Kapitel 1.1 der klassische Softwareentwurf für eingebettete
Systeme /102/, /103/ beschrieben, um den RCP-Entwurf in den Gesamtkontext
"Softwareentwurf für eingebettete Systeme" einordnen und die Vorteile des RCP
(Kapitel 1.2) deutlich erkennen zu können.
Im Kapitel 1.2.1 wird bei der Betrachtung des Entwurfphasen-Modells im Vergleich
zu den Modellen für den klassischen Entwurf im Kapitel 1.1.1 deutlich, an welcher
Stelle sich beide Entwurfsstrategien maßgeblich unterscheiden.
Das Kapitel 1.2.2 stellt einige kommerziell erwerbbare Arbeitsumgebungen vor, die
das RCP unterstützen. Wir werden uns später im Kapitel 3 ausführlich mit der
Arbeitsumgebung Matlab/Simulink auseinandersetzen, weil wir sie auch im Kapitel 4
für das praktische RCP einsetzen werden. Das Kapitel 4 ist damit auch eine
praktische Handlungsanweisung zur Lösung von RCP-Aufgaben, z.B. bei den
Übungen im Regelungstechnik-Labor im Rahmen der Lehrveranstaltung "Rapid
Control Prototyping".
Das Kapitel 1.2.3 "Mit Matlab von der Systemspezifikation zum Objektkode" nimmt
eine erste, dem Überblick dienende Beschreibung der Matlab-Arbeitsumgebung und
ihrer Leistung vor. Dabei werden zwei Prototypenentwurfsverfahren, die zu
verschiedenen
Zeitpunkten
im
Entwurfsphasenmodell
ansetzen
und
damit
verschiedene Ziele verfolgen, betrachtet.
Im Kapitel 1.2.4 wird die Grundidee eines einfachen Echtzeit-Betriebssystems auf der
Basis periodischer Interrupts beschrieben.
Anschließend im Kapitel 1.2.5 wird ein weiterer wesentlicher Aspekt der Realisierung
von Mikrocontroller gestützten Steuer- und Regelgeräten besprochen, nämlich die
Realisierung von Festkommaarithmetik zur Erhöhung des Durchsatzes von
eingebetteten Steuer- und Regelgeräten. Simulink besitzt ein spezielles Blockset zur
Wandlung von Gleitkomma- in Festpunktzahlen und umgekehrt und die meisten
Simulink-Blöcke
können
sowohl
Gleitkomma-
als
auch
Festkommazahlen
verarbeiten. Aufbauend auf dieser Einführung wird deshalb die Implementierung von
Festkommaarithmetik in Simulink-Strukturen und ihre von Matlab unterstützte
automatische Skalierung in Kapitel 3.4.2 vertieft.
Das zu entwickelnde Regelungssystem kann mit dem zu regelnden Prozess in
1.2
verschiedenen Ausprägungsformen und Fertigstellungsphasen (z.B. Regler in
Zielhardware an simuliertem Prozess) gekoppelt werden. Abgeschlossen wir die
Einführung in das RCP deshalb in Kapitel 1.2.6 "What is in the Loop" mit einer
Betrachtung, die die verschiedenen in der Literatur gebräuchlichen und sich zum Teil
widersprechenden
Definitionen
für
diese
Steuergerät-/Prozesskonfigurationen
vorgestellt und die Definitionen herausgearbeitet, die zukünftig im vorliegenden
Skript benutzt werden.
Zusatzbemerkung: Leider steht die Arbeitsumgebung für das implenntierungsorientierte
RCP (moderne PC's und die notwendigen Matlabprogramme) aus
verschiedenen Gründen dem Labor für Regelungstechnik noch nicht so lange zur
Verfügung, dass größere Erfahrungen damit gesammelt werden konnten. Dem
entsprechend beschränken sich sowohl die tiefergehenden Beschreibungen dieses
Skripts als auch die praktischen Anwendungen im Labor überwiegend auf das
konzeptorientierte RCP mit Unterstützung des sogenannten Real-Time Windows
Target von Matlab. Wer sich allerdings für die implentierungsorientierte Variante
interessiert, ist eingeladen, seine Abschlussarbeit über einen Aspekt dieser Methode
zu schreiben.
1.1 Klassischer Softwareentwurf für eingebettete Systeme
Um deutlich erkennen zu können, welchen entscheidenden Vorteil das Verfahren des
Rapid Control Prototyping im Gegensatz zu herkömmlichen Entwurfsverfahren hat,
soll in diesem Kapitel kurz auf klassische Entwurfsgrundlagen und insbesondere ihre
Schwächen eingegangen werden.
Es sei noch einmal darauf hingewiesen, dass wir uns mit Software für eingebettete
Systeme, also Steuerungen mit einer begrenzten Anzahl von Aufgaben beschäftigen.
Das heißt wir betrachten keine Entwurfsverfahren für große Softwaresysteme, an
denen ganze Abteilungen von Entwicklern arbeiten, z.B. kommerzielle Software für
Computer Inegrated Manufacturing.
Einer der wichtigsten Aspekte beim Entwurf von Software für eingebettete Systeme
ist die schlichte Forderung, dass das fertige Produkt die Anforderungen erfüllt, die an
1.3
es gestellt werden.
Häufig ist ein Kunde oder derjenige, der die Aufgabe einer zu entwickelnden
Steuerung formuliert, nicht in der Lage, diese Anforderungen detailliert und restlos zu
beschreiben, weil es ihm nicht gelingt, alle Randbedingungen, die eine solche
Steuerung erfüllen muss, im Voraus zu erkennen.
Dies hat zur Konsequenz, dass man Auftraggeber und Auftragnehmer
eine
gemeinsame Anforderungsanalyse (auch Systemanalyse genannt) vornehmen lässt.
Woraus
ein
sogenanntes
Lastenheft
entsteht,
das
eine
Aufstellung
aller
Grundforderungen an das zu entwickelnde System aus der Sicht das Auftraggebers
enthält. Nach /100/; /101/ kann man heute diese Phase bereits mit CASE-Tools
(Computer Aided Software Engineering Tools), wie z. B. UML (Unified Modelling
Language) zur Prüfung und Bestätigung der Lastenheftinhalte unterstützen. Aus dem
Lastenheft
kann
nun
von
Auftragnehmer/Entwickler
eine
detaillierte
Systemspezifikation abgeleitet werden. Die schriftliche Form dieser Spezifikation wird
Pflichtenheft genannt. In der dann folgenden Systementwurfsphase wird vom
Entwickler aus dieser Spezifikation eine Unterteilung des Gesamtsystems in kleine
Subsysteme vorgenommen. Dabei wird das Ziel angestrebt, solche Subsysteme zu
generieren, die für sich weitgehend abgeschlossenen Aufgaben erledigen. Mit der
Identifikation
Strukturierung
und
der
Beschreibung
solcher
Gesamtaufgabe
Subsysteme
angestrebt,
die
wird
eine
gewisse
das
Gesamtsystem
überschaubarer macht. Die funktionelle Abgeschlossenheit der Subsysteme soll auch
eine Vereinfachung der späteren Funktionstests herbeiführen. Heute ist auch dieser
Schritt z.B. mit dem CASE-Tool UML beschreibbar.
In der Implementierungsphase werden alle Subsysteme vereint und im Allgemeinen
in der realen Umgebung getestet. Erst in dieser sehr späten Phase kann man
erkennen, ob die Funktion den Wünschen des Auftraggebers entspricht, d. h. , ob
alle Forderungen des Lastenhefts erfüllt werden oder ob sogar die Definition von
Funktionen vergessen wurde.
Das eben beschriebene Entwurfkonzept wird in /1/ als Wasserfallmodell bezeichnet
(siehe Bild 1.1.1 auf der nächsten Seite.)
Diese Vorgehensweise in der Entwicklungsphase führte auf eine sehr späte
Aufdeckung von Fehlern und Versäumnissen, die zu hohen Nacharbeitungskosten
und Zeitverzögerungen führen kann.
1.4
Anforderungs −
analyse
Lastenheft
System −
spezifikation
Pflichtenheft
System −
entwurf
Subsystem −
entwürfe
System −
int egration
Bild 1.1.1: Das Wasserfallmodell des Softwareentwurfs
Das gab Anlass zur Weiterentwicklung des Wasserfallmodells zum bekannten VModell:
Anforderungs −
analyse
Fertigung
Anwendungs −
test
System −
spezifikation
Top −
Down
System −
test
System −
entwurf
Subsystem −
test
Subsystem −
entwürfe
System −
realisierung
Bild 1.1.2: Das V-Modell des Softwareentwurfs
1.5
Bottom −
Up
Das V-Modell ist nicht in dem Sinne zu verstehen, dass zeitlich links oben mit der
Entwicklung begonnen und rechts oben die Entwicklung beendet wird, sondern das
V-Modell basiert auf der Annahme /1/, "dass der Spezifikations- und Entwurfsprozeß
hauptsächlich durch Zerlegung und Verfeinerung eines top-down-orientierten
Entwicklungsprozeß charakterisiert ist. Ergänzt wird dies durch einen auf
zunehmender Zusammensetzung beruhenden bottom-up-orientierten Prozeß, der die
Implementierungs- und Integrationsphasen charakterisiert. Jede Phase auf der
Spezifikations- und Entwurfsseite hat ihre Entsprechung auf der gegenüberliegenden
Seite auf den Implementierungs- und Integrationsphasen. Begleitend zu den
Implementierungs- und Integrationsphasen erfolgt die Verifikation und Validierung,
die die Konsistenz und Vollständigkeit der Entwurfsbeschreibung auf jeder Ebene
gewährleistet. Während der horizontale Verlauf des V-Modells die Projektphasen und
ihre relative Dauer darstellt, repräsentiert der vertikale Verlauf die unterschiedlichen
Abstraktionsebenen".
Leider erkennt man bei dieser Vorgehensweise Spezifikationsfehler auch sehr spät,
nämlich beim System- oder Anwendungstest.
1.1.2 Modellierungsverfahren für Software
Zu Beginn dieses Kapitels wurde betont, dass sich dieses Skript mit der Entwicklung
eingebetteter Systeme auseinandersetzt. Damit sollte zum Ausdruck gebracht
werden, dass nicht die Entwicklung großer, kommerzieller Softwaresysteme, wie z.B.
Buchhaltungssoftware, Datenbank- oder Textverarbeitungssysteme, sondern die
Entwicklung kleiner Softwarepakete, die auf Mikrocontrollern laufen und eine
überschaubare Anzahl technischer Aufgabenstellungen lösen sollen, betrachtet
werden. Damit wird ausgeschlossen, dass zur Modellierung der Software
umfangreiche, sehr breit nutzbare Verfahren, wie zum Beispiel UML (Unified
Modelling Language) eingesetzt werden. Es soll an dieser Stelle auch nicht versucht
werden zu begründen, warum dies nicht der Fall ist. Wollte man ein sinnvolles
Verständnis für eine solche Begründung wecken, müsste man für UML ein Skript,
das sinnvollerweise auch Beispiele enthält, schreiben, das mindestens einen Umfang
besitzt, wie das vorliegende. Wir wollen uns auf Modellierungsverfahren für
eingebettete Systeme und insbesondere auf solche, die Steuerungs- und
Regelungsaufgaben erfüllen, beschränken.
Deshalb nehmen wir eine kurze Strukturierung der dafür in der Literatur
1.6
beschriebenen Modellierungsverfahren vor und gehen nur intensiver auf solche ein,
die Signalverarbeitungssysteme in Form von Steuerungen oder Regelungen
beschreiben. Wir folgen an dieser Stelle weitgehend den Ausführungen von /1/. Dort
wird zwischen drei wesentlichen Steuerungsmodellen unterschieden:
•
ereignisdiskrete Steuerungen,
•
kontinuierliche Steuerungen und
•
datenund kontrollflussmodellierte Steuerungen (das sind alle restlichen
Steuerungen die nicht ereignisdiskret oder kontinuierlich sind).
Dabei wird impliziert, dass eine ereignisdiskrete Steuerung einen ereignisdiskreten
Prozess und eine kontinuierliche Steuerung einen kontinuierliche Prozess steuert,
bzw. regelt.
•
Ereignisdiskrete Steuerungen
Der Begriff "kontinuierliches System" ist aus der Systemtheorie /2/ hinlänglich
bekannt. Er beschreibt ein System zur Verarbeitung kontinuierlicher Signale, die sich
dadurch auszeichnen, dass sie zu jedem Zeitpunkt existieren, d.h. eine beliebig
genaue Amplitude haben. Unter einem zeitdiskreten System wird -genau genommenein nur zu diskreten Zeitpunkten existierendes Signal mit beliebig genauer Amplitude
verstanden. Solche Signale existieren real nur am Ausgang eines Haltegliedes vor
einen A-/D-Wandler. Der Begriff wird aber auch benutzt, wenn es sich um sowohl
zeit- als auch amplitudendiskrete Signale handelt. Solche Signale treten am Ausgang
von A/D-Wandlern und bei der Weiterverarbeitung in Digitalrechnern (zeitdiskretes
System, Abtastsystem) auf. Diese etwas ungenaue, aber häufig genutzte
Bezeichnung hat zwei Gründe. Erstens macht sich die Amplitudendiskretisierung bei
der Standarauflösung eingesetzter A-/D-Wandler von 12 Bit systemtheoretisch kaum
bemerkbar, während die Zeitdiskretisierung erheblichen Einfluß auf die Signal- und
damit auch auf die Systembeschreibung hat (z.B. Differenzengleichungen an Stelle
von Differenzialgleichungen als mathematisches Modell im Zeitbereich.) Der zweite
Grund liegt darin, dass unter der richtigeren Bezeichnung "digitales Signal" für ein
zeit- und wertquantisiertes Signal häufig eine Binärzahl, also eine Ansammlung von
Nullen und Einsen verstanden wird.
Ein ereignisdiskretes Signal ist auch ein nur zu diskreten Zeitpunkten auftretendes
1.7
Signal, aber nicht mit z.B. 256 oder 4096 verschiedenen Amplitudenquanten,
sondern i.A. nur mit zwei Amplitudenwerten. Deswegen nennt man solche
ereignisdiskreten Systeme
häufig auch "diskrete binäre Systeme" oder binäre
Automaten. Auch die Begriffe "endlicher Zustandsautomat" oder "finite state
machine" sind gebräuchlich.
Früher benutzte man zur Beschreibung ereignisdiskreter Systeme Ablaufdiagramme
endlicher Zustandsautomaten (Mealy- und Moore-Automaten) oder Petrinetze /1/.
Wegen erheblicher Mängel dieser Beschreibungen haben sich heute sogenannte
"Statecharts" (Zustandsübergangsdiagramme) durchgesetzt /1/.
Auch Simulink besitzt eine grafische Erweiterung zur Modellierung von endlichen
Zustandsautomaten, die hier darüber hinaus im Zusammenspiel mit kontinuierlichen
und zeitdiskreten Systemelementen modelliert werden können. Matlab nennt diese
Erweiterung "Stateflow". In /6/ findet der Leser eine sehr gut nachvollziehbare
Einführung in Stateflow mit zwei Beispielen "Getränkeautomat" und "Steuerung eines
Heizgebläses.
Da wir keine Zustandsautomaten betrachten wollen, gehen wir auf ereignisdiskrete
Steuerungen nicht weiter ein.
•
Kontinuierliche Steuerungen
Kontinuierliche Systemmodelle dienen zur Beschreibung kontinuierlicher Systeme,
die wiederum zur Beschreibung von steuer- und regelungstechnischen Algorithmen
herangezogen werden können. Ein kontinuierliches System kann mittels Formeln in
Form einer Differenzialgleichung (bzw. durch ein Zustandsmodell) oder in einem
anderen Betrachtungsbereich, dem Bildbereich, mit einer Übertragungsfunktion
modelliert werden /2/. Dazu gibt es äquivalente grafische Beschreibungsarten in
Form von sogenannten Strukturbildern. Die Formel- und die Strukturbildbeschreibungen besitzen den gleichen Informationsgehalt und lassen sich eindeutig
ineinander umrechnen. Als CASE-Tool wird im Falle des RCP allerdings die
grafische Beschreibungsform als Strukturbild bevorzugt.
Wir wollen uns an dieser Stelle noch einmal vor Augen führen, warum wir eine
Modellierung unseres kontinuierlichen Systems vornehmen: Wir wollen einen
zuverlässigen und möglichst fehlerfreien Entwurfsweg von dem zu realisierenden
System hin zu einem Algorithmus beschreiten, der in einen Digitalrechner
1.8
implementiert, das gleich Wirkungsverhalten zwischen Eingang und Ausgang zeigt,
wie das zu realisierende System.
Wir zeigen im Folgenden, welche Schritte man gehen muss, um eine solche
Implementierung weitgehend zuverlässig durchführen zu können. Um das Ganze
noch anschaulicher zu machen, soll nicht von einem abstrakten Regler, dessen
Wirkungsverhalten wir ja eigentlich im Mikrocontroller-Algorithmus nachbilden wollen,
ausgegangen werden, sondern
von einem -uns allen bekannten koninuierlichen
System- einem RC-Glied, wie wir es in /1/ bereits mathematisch modelliert haben:
R
u( t)
y( t)
C
u( t) = Eingangsspannung
y( t) = Ausgangsspannung
R = 100 kΩ, C = 100 µF
Bild 1.1.3: Ein nachzubildendes reales System
Es soll ein Algorithmus/Programm entworfen werden, das in einen Digitalrechner
implementiert, am Eingang mit einem A/D- und am Ausgang mit einem D/A-Wandler
versehen, das gleich Wirkungsverhalten zeigt wie das ursprüngliche reale System.
y( t)
1V
0
u( t)
t
0
1V
0
0
Digitalrechner mit
implementiertem
Filtera lg orithmus
t
y( t)
1V
A /D
D/A
0
t
0
Bild 1.1.4: Nachbildung des Wirkungsverhaltens durch einen Algorithmus
In /2/ wurde gezeigt, wie man das RC-Glied mittels einer mathematisch
/physikalischen
Modellbildung
in
eine
1.9
Zustandsmodell
und
anschließender
Transformation in eine Übertragungsfunktion wie folgt beschreiben kann:
Ua (s)
1
1
=
=
.
Ue (s) 1 + RC ⋅ s 1 + 10 ⋅ s
G(s) =
Obwohl man ein solches kontinuierliches System auch auf einem Digitalrechner
implementieren könnte, empfiehlt es sich, die Übertragungsfunktion zu diskretisieren
und den Algorithmus in Form einer zeitdiskreten Differenzengleichung zu
implementieren. Nach der Diskretisierung bei einer Abtastzeit von 1sek. (wie man die
Abtastzeit sinnvoll wählt wird in /2/ beschrieben) ergibt sich mit Hilfe der
Sprunginvarianztransformation eine z-Übertragungsfunktion
G(z) =
Ua (z)
0,09516
0,09516z −1
=
=
,
Ue (z) z − 0,9048 1 − 0,9048z −1
die man in eine Differenzengleichung wandeln kann:
ua (k) = 0,9048ua (k − 1) + 0,09516ue (k − 1).
Nach /2/ ergibt sich daraus folgendes Strukturbild:
ue (k)
ue (k − 1)
T
0,09516
ua (k)
0,9048
ua (k − 1)
T
Daraus läßt sich leicht -wie angestrebt- ein Programm schreiben, das das
vorgegebene RC-Glied simuliert. Weil wir den späteren Rapid Control Prototyping Vorgang
unter
Matlab/Simulink
realisieren
werden
und
keine
weitere
Programmiersprache einführen wollen, soll ein Matlab-Programm entwickelt werden,
um das obige Strukturbild als Programm zu realisieren. Man kann das MatlabProgramm quasi als Pseudocode für ein C-Programm auffassen.
1.10
Für die folgende Programmrealisierung soll eine Einheitssprungantwort über 50 sek.
realisiert werden:
% Pseudokode (Matlab) für ein C-Programm zur
% Realisierung des Verhaltens eines RC-Gliedes
ue_alt=0;
% Initialisierung der Speicher T
ua_alt=0;
ue=1;
% Eingangssprung.
for k=0:1:50
ua = 0.9048*ua_alt
%
ue_alt = ue;
%
ua_alt = ua;
%
end
+ 0.09516*ue_alt;
Realisierung des Strukturbildes.
Umladung der Signalspeicher
von kT nach (k-1)T.
ua_plot(k+1)=ua; % Speicher, um das Ausgangssignal
% zu plotten.
t=0:1:50;
figure(1)
stairs(t,ua_plot)
grid on
% Plotroutine (für die Nutzung des)
% Programms nicht notwendig).
Wenn man analytisch die Sprungantwort des RC-Gliedes berechnen würde, könnte
man zeigen, dass die vom obigen Programm berechnete Sprungantwort, der des
ursprünglichen realen kontinuierlichen Systems entspricht.
Das heißt, die Modellierung kontinuierlicher Systeme mittels parametrischer
mathematischer Modelle und deren grafisch Darstellung sind eine zuverlässige
Grundlage zum Entwurf kontinuierlicher Steuerungen.
Wir wollen uns an dieser Stelle noch ein paar Gedanken über den Sinn einer
kontinuierlichen Realisierung gegenüber einer zeitdiskreten Realisierung und deren
numerischer Simulation/Berechnung machen.
Am deutlichsten wird dies, wenn wir das vorangehende RC-Glied einmal
kontinuierlich mit einer Rechenschrittweite von dt = 1sek. und einmal nach der
Diskretisierung mit der Abtastzeit T = 1sek, also
zwischen
den
Berechnungszeitpunkten,
beantworten, wo der Unterschied liegt,
Berechnungsalgorithmus?
1.11
identischen Zwischenräumen
simulieren.
im
Wir
wollen
Berechnungsergebnis
die
Frage
oder
im
Wenn zur Berechnung der zeitdiskreten Realisierung die Sprunginvarianztransformation benutzt wurde, müssen die Sprungantworten zu den Berechungsbzw. Abtastzeitpunkten gleich sein, weil es die Eigenschaft dieser Transformation ist,
invariant
gegenüber
Sprungerregungen
zu
sein.
Wenn
man
eine
andere
Transformation wählt, z.B. die Tustinsche Näherung mit einer relativ kleinen
Abtastzeit, sind die Systemantworten nicht vollständig identisch, sich aber sehr
ähnlich. Das heißt, der praktische Unterschied liegt nicht im Berechnungsergebnis,
sondern im Berechnungsalgortihmus.
Um die Systemantwort eines kontinuierlichen Systems zu berechnen, müssen
Differenzialgleichungen
numerisch
gelöst
werden.
Dazu
sind,
wenn
das
Berechnungsergebnis genau sein soll, aufwändige rechenintensive Algorithmen,
sogenannte Integrationsalgorithmen, wie das Runge/Kutta-Verfahren notwendig.
Diese Algorithmen müssen, wenn das System in Echtzeit laufen soll, schritthaltend
mit dem Prozess gerechnet werden.
Diese CPU-Belastung kann man sich ersparen, wenn man die kontinuierlichen
Algorithmen in zeitdiskrete umrechnet (das macht man einmal Offline, d. h. vor dem
Echtzeitbetrieb) und berechnet während des Echzeitbetriebs die einfach zu lösende
Differenzengleichung mit wenigen, von der Ordnung des Systems abhängigen,
Multiplikationen und Additionen. D. h., es empfiehlt sich immer, mit zeitdiskreten
Regelalgorithmen zu arbeiten.
•
Modellierung von Daten- und Kontrollstrukturen
Alle Modellierungen für Steuerungen, die nicht diskreter oder kontinuierlicher Natur
sind, können, wenn kein zu großes Softwareprojekt modelliert werden soll, mit Datenund Kontrollflüssen modelliert werden. In der Literatur über Softwareegineering
werden sie als leicht erstellbar und gut lesbar auch für Nichtfachleute bezeichnet.
In /1/ werden zwei Verfahren vorgestellt,
•
Datenflussdiagramme und
•
Activity charts.
Da
wir
diese
Ansätze
Steuerungen/Regelungen
nicht
benutzen
zum
Entwurf
wollen,
Modellierungsverfahren nicht ein.
1.12
gehen
von
kontinuierlichen
wir
auf
dies
1.1.3 Realisierungsprobleme eingebetteter Systeme
Nachdem die zu lösende Programmieraufgabe durch eine geeignete Modellierung,
wie im vorangehenden Kapitel beschrieben, zur Programmierung vorbereite wurde,
muss nun auf dieser Basis eine Umsetzung in ein Programm für einen
Mikrocontroller erfolgen.
Diese Umsetzung birgt einige sachliche Probleme und setzt ein weitgehend anderes
Ingenieurwissen des Entwicklers voraus, als bei der vorangehenden systemtheoretisches Aufbereitung des Problems.
Das sachliche Problem besteht darin, dass die Entwicklungsumgebung für die
Software und das Zielsystem auf dem die Software später laufen soll, zwei
weitgehend verschiedene Welten sind. Das Entwicklungssystem wird i.A. ein PC
sein, auf der Cross Software zur Programmentwicklung in Form einer integrierten
Entwicklungsumgebung (IDE: "Integrated Development Environment") mit Compiler,
ggf. Assembler, Linker, Lader und Debugger arbeitet. (Als Cross Software wird ein
Compiler, Assembler oder eine IDE genannt, die auf einem Rechner läuft, der nicht
die CPU besitzt, für die die Entwicklungsumgebung Software erzeugt. Es handelt
sich z.B. um Cross Software, wenn man auf einem PC eine IDE zur Programmierung
von C167 Mikrocontrollern benutzt).
Das Zielsystem wird i.A. ein Mikrocontroller als eingebettete System sein, das
•
über spezifische Hardwareschnittstellen Sensorsignale vom zu steuernden
Prozess empfängt und Stellsignale in den Prozess abgibt,
•
i. A. in Echtzeit, d. h. schritthaltend zum Prozess betrieben wird und
•
neben einfachen Steueraufgaben und Kommunikation mit über-/untergeorneten
Systemen auch anspruchsvolle Regelalgorithmen zu lösen hat, d. .h eine
entsprechend genaue Arithmetikunterstützung braucht.
Die Entwicklung des Programms, dessen modellhafte Entstehung im letzten Kapitel
beschrieben wurde, wird i. a. in einer Hochsprache vorgenommen. Verschiedene
Firmen bieten z.B. IDE's an, die auf spezielle Mikrocontroller zugeschnitten sind, z.B.
die Firma Altium, den Tasking C-Compiler oder die Firma Keil auch einen
C-
Compiler für die Mikrocontroller C16x von Infineon.
Obwohl die Verwendung von Hochsprachen nicht so effizienten Objektcode liefert,
wie ein Assembler (d. h. der Code hat eine langsamere Verarbeitungs1.13
geschwindigkeit
und
benötigt
mehr
Speicherplatz)
zieht
man
die
Hochsprachenentwicklung vor, weil sie schneller und problemorientierter ist.
Weiterhin ist der Code für Dritte besser les- und damit wartbar. Das schließt
allerdings nicht aus, das z.B. Treiber, die sehr häufig während des Programmlaufs
aufgerufen werden, zur Steigerung des Durchsatzes in Assembler geschrieben
werden. Bei der Beschaffung einer geeigneten IDE sollte auf die Möglichkeit der
Einbindung von Assemblerprogrammen in Hochsprachenprogramme geachtet
werden. Eine weitere Erhöhung des Durchsatzes ist mit einer Umstellung der
Gleitkommarechnung, die ein Mikrocontroller i.A. nicht per Hardware sondern mit
einer Gleitkommabibliothek unterstützt, in Festkommarechnung möglich. Hier muss
allerdings sehr mühsam ein Kompromiss zwischen darstellbarem Zahlenbereich und
Genauigkeit (Zahlenauflösung) der Rechnung durch die Wahl der Lage des
Radixpunktes der Festkommazahlen gefunden werden. An dieser Stelle könnte
Matlab mit seiner "Fixed Point Toolbox" sehr hilfreich eingesetzt werden. Wir gehen
auf dieses Tool nicht weiter ein, weil wir im Rahmen des RCP im Kapitel 3.3.1 die
automatische Generierung von Festkommaarithmetik mit Simulink und dem "Fixed
Point Blockset" kennen lernen. In Kapitel 1.2.5 werden die dazu notwendigen
Grundlagen besprochen.
Der Echtzeitbetrieb ließe sich mit Echtzeitbetriebssystemen für Mikrocontroller
(FreeRTOS, RTO-UH, Tornado/VxWorks, usw.) herstellen. Häufig reicht auch schon
eine Lösung aus, die auf der Basis von periodisch von einem Hardwarezähler
getakteten Interrupt-Service-Routinen realisiert wird. Matlab nennt diese Form des
Echtzeitbetriebs "Bare-Board Environment", weil kein echtes Betriebssystem den
Echtzeitbetrieb ermöglicht.
Die Erläuterung der Funktion von Echtzeitbetriebssystemen wird im Rahmen dieses
Skripts im Überblick vorgenommen, so dass der Unterschied zur Echtzeiterzeugung
mit getakteten Interrupt Service Routinen deutlich erkennbar wird.
Das
hauptsächliche
Realisierungsproblem
eingebetteter
Systeme
ist
der
Funktionstest der Software im Zielsystem wegen der am Anfang dieses Kapitels
heraus gearbeiteten großen funktionellen Unterschiede zwischen Entwicklungs- und
Zielsystem.
Einige integrierte Entwicklungsumgebungen für Cross Software stellen einen
Simulator zur Verfügung, welcher die interne Struktur und die auf dem Controllerchip
befindliche Peripherie per Software nachbildet. Auf diesem Simulator kann die
1.14
entwickelte Software getestet werden, externe Anworten auf ausgegebenen Signale
müssen dabei auch per Software nachgebildet werden. Die Prüfung auf
Echtzeitreaktionen ist nicht möglich.
Das
seit
ca.
30
Jahren
klassische
Testinstrument
für
Steuergeräte
mit
Mikroprozessoren und Mikrocontroller ist der "In Circuit Emulator" (ICE) /104/. Mit
ihm ist ein Systemtest in der Zielhardware in Echtzeit möglich. Ein ICE ist eine
Kombination aus Software und Hardware. Zur Arbeit mit einem ICE wird der
Controller aus seiner Umgebung entnommen, d. h. er muss steckbar auf der Platine
angeordnet sein. An Stelle des Controllers wird der ICE angeschlossen. Im ICE ist
die Controller-Hardware durch einem typgleichen aber etwas schnelleren Controller
ersetzt oder wird mittels schnellerer Hardware "diskret" nachgebildet. Um den
Controller herum muss sich weitere Hardware befinden, die u. A. Kontakt zu einem
PC herstellt, um von dort Zugriffe auf die ICE-Hardware zu ermöglichen. Wenn man
nun eine Anwendung vom PC aus im Zielsystem startet, kann man die entwickelte
Software auch in Anwesenheit eines Echtzeitbetriebssystems testen. Weil der
Controller im ICE schneller ist als der ursprüngliche, kann man während des Lauf
z.B. CPU-Register auslesen, ausgegeben Signale auf einem Monitor betrachten, den
Controller bis zu einem gesetzten Breakpoint laufen lassen und anschließend
getracete Ein-/Ausgangssignale betrachten und damit Fehlfunktionen der Software
aufdecken. Auch andere Funktionen, die ein normaler Debugger eine IDE besitzt,
z.B. die Abarbeitung des Programms in Einzelschritten ist i. A. auch mit einem In
Circuit Emulator möglich.
Komfortable ICE's sind i. A. sehr kostspielig und können sechstellige Europreise
kosten. Heutige Mikrocontroller haben in der Regel rudimentäre ICE-Funktionen auf
dem Controllerchip integriert. Diese Funktion wird häufig "In System Programmer"
oder "In System Debugger" genannt. Sie bieten i. A. nicht die Testtiefe wie ICE's und
sind auch nur bedingt echtzeitfähig. Dafür liegen aber die Preise nur im zwei- bis
dreistelligen Eurobereich.
Mikocontroller, die den sogenannten JTAG-Standard (Joint Test Action Group Standard) /105/ unterstützen, verfügen über eine JTAG-Schnittstelle über die sie mit
einem PC gekoppelt werden können. Auch damit sind eingeschränkte DebugFunktionen möglich.
1.15
1.2 Rapid Control Prototyping
Wie schon im Vorwort dargestellt wurde, wird unter einem Prototypen in der Technik
ein Objekt verstanden, dessen Entwicklungsstand zwischen Entwurf und Fertigung
liegt.
Der Prototyp steht in seiner Aussagefähigkeit hinsichtlich des Erfüllungsgrades des
geplanten Konzepts zwischen der reinen Simulation und der endgültigen
Realisierung innerhalb eines zu beeinflussenden Prozesses. Das heißt, es können
Prototypen entwickelt werden, verschiedene interessierende Fragen beantworte. Wir
werden in Kapitel 1.2.1 auf drei zu verschiedenen Zeitpunkten im V-Modell
einsetzende Prototyping-Ansätze
•
Das konzeptorientierte RCP,
•
Das architekturorientierte RCP und
•
das implementierungsorientierte RCP
eingehen.
Das erweiterte V-Modell mit den drei Ansätzen für die Generierung von Prototypen ist
bereits ca. 20 Jahre alt /7/, obwohl man vermuten würde, das softwaregestützte
RCP -Methoden erst im aktuellen Jahrzehnt entwickelt wurden.
Der traditionelle Entwicklungsablauf nach dem V-Modell (vergleiche Kapitel 1.1.1)
wird dabei durch den Einsatz von Rapid Prototyping auf verschiedenen Ebenen der
Steuerungsentwicklung unterstützt (siehe Bild 1.2.1 auf der folgenden Seite.)
Da diesem Entwurfsphasenmodell, dem das V-Modell zu Grunde liegt, aber Rapid
Prototyping berücksichtigt, wird es VP-Modell genannt.
Aus den folgenden Betrachtungen wird deutlich, dass die drei Prototypingansätze
nicht miteinander konkurrieren, sondern sich ergänzen.
1.16
Anforderungs −
analyse
Fertigung
System −
spezifikation
Anwendungs −
test
I
System −
entwurf
System −
test
II
Subsystem −
entwürfe
III
Subsystem −
test
System −
realisierung
I:
II :
III :
Konzeptorientierter Prototyp
Architekturorientierter Prototyp
Implementierungorientierter Prototyp
Bild 1.2.1: Das VP-Modell der Softwareentwicklung
•
Konzeptorientiertes Rapid Control Prototyping
Das konzeptorientierte RCP, das am dichtesten bei der Systemspezifikation
angesiedelt ist, dient hauptsächlich der Klärung der Systemziele. Es realisiert einen
Prototypen direkt aus der Systemspezifikation heraus.
Das CAE-Programm Matlab/Simulink, das wir später für die praktische Anwendung
des
RCP
nutzen
wollen,
realisiert
das
konzeptorientierte
RCP
mit
zwei
verschiedenen Softwarewerkzeugen:
•
Dem Real-Time Windows Target und
•
dem xPC-Target.
Unter Target ("Ziel") wird im Fachjargon das Zielsystem verstanden, auf dem der
entwickelte Objektcode laufen soll.
Beim Real-Time Windows Target ist das Ziel ein PC, der unter dem Betriebssystem
Microsoft
Windows
läuft.
Zusätzlich
installiert
ein
Matlabprogramm
einen
sogenannten Echtzeitkern, so dass das Zielsystem echtzeitfähig ist. Um mit der
1.17
Außenwelt kommunizieren zu können, muss in den PC eine handelsübliche A/D-D/AWandlerkarte (z.B. von der Firma Keithley-Instruments oder der Firma Analog
Devices) eingefügt werden.
Beim xPC-Target werden zwei PC's benötigt, einen, mit dem der in Echtzeit laufende
PC gesteuert wird und dem in Echtzeit laufenden PC selbst. Auf dem Echtzeitrechner
kann die Kommunikation mit der Umwelt über alle bekannten PC-Schnittstellen und
eingesteckte analoge und digitale I/O-Karten erfolgen. Matlab bietet eine xPC-TargetBox an , die vielen mit I/O's, z.B. mit PWM-Signalgenerierung, CAN-Busschnitstelle
und Encoder-Eingang versehen ist.
Auf diesen Plattformen kann auf der Basis einer Simulation, z. B. mit Simulink im
Nicht-Echtzeitbetrieb die Funktionsfähigkeit eines Reglers nachgewiesen werden.
Mittels der beiden genannten Softwaresysteme (Realtime Windows Target, xPC
Target) kann dann ein in Echtzeit laufenden Prototyp generiert werden. Bei richtig
installierter Software geschieht das auf Knopfdruck bis hin zum Laden des
generierten Prototypenobjektcodes in den Echtzeitrechner. Anschließend kann die
Software zur Ausführung gebracht werden.
Stellt man bei der Ausführung eine Fehlfunktion fest, kann man mit den von Matlab
bereitgestellten CASE Tools schnell eine Programmänderung vornehmen und nach
wenigen Minuten die geänderte Steuerung erneut testen.
Weil mit dem konzeptorientierten Prototypen primär die konzipierte Funktion getestet
werden soll, muss die Hardwarearchitektur noch nicht zwangsläufig der endgültigen
entsprechen. Allerdings sollte man darauf achten, dass die Schnittstellen zwischen
dem zu testenden Target und seiner Umwelt (z. B. der Regelstrecke) keine
zusätzlichen Fehler in die Lösung einschleppen. Zum Beispiel sollte angestrebt
werden, dass der Aussteuerbereich und die Auflösung des A/D-Wandlers größer
oder gleich der endgültigen Realisierung sind. Dies ist in so fern unproblematisch,
weil der konzeptionelle Prototyp wieder verwendbar ist und damit auch etwas
kostenintensiver sein darf. Ist allerdings das Target, das bei den vorliegenden
Softwaresystemen mit einer Abtastzeit von minimal ca. 100 µsek. beim Real-Time
Windows Target und von ca. 10 µsek. beim xPC Target betrieben werden kann, zu
langsam (was bei einer regelungstechnischen Anwendung i. A. nicht der Fall ist)
muss auf die Nutzung konzeptionellen Prototypen verzichtet werden und ein
architektur- oder implementierungsorientierter Prototyp eingesetzt werden.
1.18
•
Architekturorientiertes Rapid Control Prototyping
Im Gegensatz zum konzeptorientierten RCP wird hier bereits die Zielarchitektur der
zu entwickelnden Steuerung berücksichtigt, um genauere Aussagen über die
endgültige Funktionsfähigkeit der Steuerung/Regelung treffen zu können. Bei diesem
Prototypen werden i. A. bereits die Hardwarekomponenten der endgültigen
Realisierung eingesetzt. Die Steuerungssoftware muss noch nicht auf minimalen
Speicherplatzbedarf optimiert, aber die Echtzeitfähigkeit muss sichergestellt sein.
•
Implementierungsorientiertes Rapid Control Prototyping
An dieser Stelle werden Prototypen erzeugt, die vollständig auf den spezifischen
Anwendungsfall
zugeschnitten
sind.
Häufig
werden
architektur-
und
implementierungsorientiertes Prototyping nicht mehr unterschieden, sondern in
einem letzten Arbeitsschritt implementierungsorientiert hergestellt. Matlab unterstützt
auch solche Plattformen, in dem für spezielle Controllertypen (z.B. Infineon C16x,
Motorola MPC 555, Texas Instruments TIC6000) sogenannte Embedded Target
angeboten werden. Wir gehen in den Kapiteln 1.2.3.2 und 3.4.2 etwas näher auf das
Embedded Target für den Infineon Controller C167 ein. Implementierungorientierte
Prototypen werden im Allgemeinen auch zur automatischen Codegenerierung für
Mikrocontroller
herangezogen,
diesen
Aspekt
wollen
wir
im
Rahmen
der
Lehrveranstaltung Rapid Control Prototyping nicht vertiefen, er soll dem Modul
"Modellbasierter Entwurf" im gleichen Studiengang vorbehalten bleiben
1.2.2 Werkzeuge zum Rapid Control Prototyping
Obwohl wir uns im Rahmen dieses Skripts primär mit den von der Firma
The Mathworks unter dem CAE-Programm Matlab laufenden RCP-Werkzeugen
auseinandersetzen wollen, soll zunächst ein Überblick über einige andere am Markt
verfügbare RCP-Werkzeuge gegeben werden.
Die Entwicklung von Rapid Control Prototyping Werkzeugen begann verstärkt Anfang
der 90-ger Jahre des letzten Jahrhunderts. Einige Werkzeuge existierten schon
früher, z.B. das "Engineering Analysis System, Version 5" (EASY5), das von der
Firma Boing Corporation, USA entwickelt und ab 1976 im zivilen Flugzeugbau
verwendet wurde. Die Stärken dieses Werkzeugs liegen allerdings nicht im
1.19
Prototyping, sondern unterstützen den Entwurf und die Simulation stark heterogener
Systeme (Mischsysteme aus z.B. mechanischen, hydraulischen und elektrischen
Komponenten). Es kann jedoch auch Code für verschiedenen Zielsysteme, z.B. von
der Firma dSpace, Deutschland (siehe weiter hinten) und der Firma SUN, USA
generiert werden.
Im folgenden sollen die heute am häufigsten in der Literatur genannten RCPWerkzeuge kurz in ihrer Leistung beschrieben werden. Die Weiterentwicklung dieser
Systeme geht so rasant voran, dass ihre aktuelle Leistung zeitnah im Internet
"nachgeschlagen" werden sollte.
•
Werkzeuge der Firma dSpace, Deutschland
Die dSpace GmbH, eine deutsche Firma mit internationalem Absatzmarkt, entwickelt
und vertreibt RCP-Werzeuge (Hard- und Softwarekomponenten), die direkt aus
Matlab, Simulink und Stateflow heraus Objektkode für verschiedene Zielcontroller
erzeugen können. Der Code kann dann unter Echtzeitbedingungen als "Softwareoder Hardware-In-The-Loop-Struktur" (vergleiche Kapitel 1.2.6) getestet werden.
dSpace nennt die Software, mit der aus einer Simulink-Struktur (vergleiche Kapitel
1.2.3 und 3.4) lauf- und echtzeitfähiger Code generiert werden kann, "TargetLink"
/106/.
Hinter TargetLink verbergen sich modular erweiterbare Softwarekomponenten mit
denen z.B. Code für die gängigsten Frescale-, Infineon- und Renasas-Mikrocontroller
und Mikroprozessoren generiert werden können. Haupteinsatzgebiet dieses dSpaceWerkzeugs ist die Automobilindustrie. Dies ist auch daran zu erkennen, dass
TargetLink automobilspezifische Softwaremodule, wie
•
AUTOSAR und
•
OSEK
unterstützt. AUTOSAR steht für "AUtomoTive Open System ARchitecture" und ist ein
offener Standard für Software Architekturen von vernetzten Mikrocontrollern in
Kraftfahrzeugen. AUTOSAR ist ein Schichtenmodell und standardisiert die Schichten
zwischen Anwendungssoftware/Applikation Layer (z.B. Einparkhilfe, adaptives
Abblendlicht) und die über einen CAN-Bus vernetzte Mikrocontrollerhardware /107/.
1.20
Bild 1 2 2: Die AUTOSAR-Architektur
Die Grundidee von AUTOSAR lautet: Zusammenarbeit bei Standards, Wettbewerb
bei der Implementierung von Funktionen.
OSEK geht von ähnlichen Intentionen aus, es steht für "Offene Systeme und deren
Schnittstellen für die Elektrik im Kraftfahrzeug". Das OSEK-Konzept wird durch die
Standards
OSEK-OS:
Ein Betriebssystem/Operating System, das auf die Belange der KFZIndustrie ausgerichtet ist.
OSEK-OIL: Eine Implementierungssprache (OSEK Implementation Language) mit
der
Betriebssystemobjekt
(Tasks,
Interrupts,
Ressourcen,
usw.)
angelegt werden können.
OSEK-ORTI: Ein OSEK Run Tme Interface zum Debuggen in Echtzeit.
OSEK-COM: Beschreibt die Kommunikation (Communication) zwischen Tasks und
auch verteilten Mikrocontrollern.
OSEK-NM: Beschreibt das Netzwerkmangement (Network Management) zwischen
den einzelnen Mikrocontrollern.
getragen.
1.21
•
Das RCP-Werkzeug ASCET
ASCET /113/ ist eine sehr spezifische Entwicklungsumgebung für hierarchisch
gekoppelte eingebettete Steuerungs- und Regelungssysteme im Automobilsektor.
ASCET ist eine Entwicklung der deutschen Firma ETAS und ist weltweit verbreitet.
ASCET unterstützt auch die modellbasierte Entwicklung von Komponenten für
Steuergeräte-Anwendungssoftware
nach
dem
AUTOSAR-Entwurfsprinzip
mit
anschließender automatischer Codegenerierung für Steuergeräte. Der generierte
Code, der mittels der Programmiersprache MISRA-C (Motor Industrie Software
Reliability Association) erzeugt wird, zeichnet sich durch die Einhaltung von
sogenannten Sicherheits-Integritäts-Level (SIL) aus. Aus dem angestrebten zu
erreichenden Level ergeben sich Konstruktionsprinzipien für die Hard- und Software,
die eingehalten werden müssen, damit das Risiko einer Fehlfunktion minimiert wird.
Simulink-Strukturen lassen sich in ASCET integrieren.
•
LabView
LabView (Laboratory Virtual Instrumentation Engeneering Workbench) /114/ ist ein
Produkt der Firma National Instruments (NI), USA, das mittels grafischer
Programmierung (ähnlich wie Simulink) primär zur Messdatenerfassung und
Datenanalyse (Mittel-wertbildung, Filterung, Spektralanalyse, usw.), also in der
Messtechnik eingesetzt wird. Ursprünglich diente diese Software zur Demonstration
der Leistungsumfangs der von NI hergestellten A/D-D/A-Wandler-Einsteckkarten für
PC's. In der neuesten Version (≥ 8) ermöglicht LabView auch die Programmierung
von Mikrocontrollern und DSP's. Es unterstützt auch einige Echtzeitbetriebssysteme.
Mittels der Software "NI LabView Simulation Interface Toolkit" lassen sich auch
Simulink-Strukturen in LabView einbinden und in Echtzeit z.B. auf NI-Harware
implementieren.
•
MATRIXx
MATRIXx /115/ ist ein Sammelbegriff einer auch von der Firma National Instruments
vertriebenen Software, die sich in drei Produktgruppen gliedert: Xmath, SystemBuild,
AutoCode.
1.22
NI Xmath: Ist eine interaktive Arbeitsumgebung für numerische Berechnungen,
Visualisierung und Entwicklung von Regelungsstrukturen. Grundlage von
Xmath ist MathScript, eine Hochsprache, die in Funktionsweise und
Umfang mit Matlab vergleichbar ist. Die Interaktivität von spezifischen
Anwendungsprogrammen (z.B. zur Reglerentwicklung) wird, auch wie
bei Matlab, mit GUI's (Graphical User Interfaces) hergestellt. Der
Funktionsumfang von MathSkript kann auch durch sogenannte "add-on
modules" , z.B. zur Signalverarbeitung oder Systemidentifikation
erweitert werden.
NI SystemBuild: Ist eine grafische Arbeitsumgebung zum Aufbau zu simulierender
Systemmodelle
aus
Systemsimulationen.
grafischen
SystemBuild
ist
Funktionselementen
erweiterter
mit
für
funktions-
spezifischen "add-on libraries" für z.B. neuronale Netze, Fuzzy Logik und
zur Simulation von Zustandsautomaten. SystemBuild unterstützt dabei
sowohl Gleit- als auch Festkommarechnung.
Auch hier ist die Ähnlichkeit mit Simulink und Stateflow von The
Mathworks verblüffend.
NI AuotCode:
Ist ein Werkzeug zur automatischen Codegenerierung aus
SystemBuild-Blockdiagrammen. Es besteht die Wahl, ob C- oder AdaCode generiert werden soll. Es werden sowohl kontinuierliche als auch
zeitdiskrete Systeme -auch mit verschiedenen Abtastraten- generiert.
Damit wird RCP im Echtzeitbetrieb möglich. Mit AutoCode add-on
Modulen lässt sich Code für Multiprozessorsysteme generieren.
•
Matlab / Simulink
Mit dieser Entwicklungsumgebung werden wir uns im Rahmen dieses Skriptes näher
auseinandersetzen. Wir gehen im nächsten Kapitel 1.2.3 zunächst kurz und dann
etwas intensiver im Kapitel 3 auf Matlab/Simulink ein. Praktisch anwenden werden
wir ausschließlich Matlab/Simulink.
1.23
1.2.3 Von der Systemspezifikation zum Objektkode
Nachdem wir gesehen haben, dass das Konzept des Prototypen offensichtlich die
zuverlässigste Methode ist, von einer Systemspezifikation zu einer eingebetteten
Realisierung zu gelangen, an der man nachweisen kann, dass die Spezifikationen
erfüllt sind (wir hatten diesen Prototypen "konzeptorientiert" genannt) und man
darüber hinaus mit einem "implementierungsorientierten" Prototypen sogar die
Funktionstüchtigkeit eines Steuergerätes in seiner späteren Arbeitsumgebung
vollständig nachweisen kann, wollen wir in diesen Kapitel zeigen
•
mit welchen Matlab-Komponenten dies gelingt und
•
wie man aus einer Simulink-Struktur automatisch lauffähigen Objektcode
erzeugt.
1.2.3.1
Matlabkomponenten
prototypen
zum
Entwurf
konzeptorientierter
Regler-
Um zu einer Systemspezifikation für einen Regler zu gelangen (Festlegung welcher
Reglertyp eingesetzt und wie die Parameter eingestellt werden sollen), muss man
nach regelungstechnischen Gesichtspunkten einen Regler entwerfen. Dazu benötigt
man ein mathematisches Modell der Regelstrecke. Um dieses bei einem realen
Problem zu erhalten, muss eine Systemidentifikation vorgenommen werden, die
zweckmäßigerweise rechnergestützt vorgenommen wird. Auf der Basis dieses
Streckenmodells kann nun eine Regler ausgewählt und nach verschiedenen
Methoden, die die Regelungstechnik lehrt, parametriert werden. Bevor man daran
geht, diesen Regler als Prototypen zu realisieren, erweist es sich als zweckmäßig,
den Regelkreis, von dem jetzt jede Systemkomponente bekannt ist, zunächst unter
Simulink zu simulieren. Auf der Basis dieser Simulation kann im ersten Ansatz
überprüft werden, ob die Reglerauslegung prinzipiell gelungen ist, das heißt, ob der
Kreis Führungsgrößen wunschgemäss folgt, Störungen ausregelt und ob z. B. die
Stellgröße bei bestimmten im Betrieb auftretenden Führungs- und Störgrößen
übersteuert wird. Erst jetzt ist der Entwurf eines konzeptorientierten Prototypen
sinnvoll.
Wegen der Wichtigkeit dieser Vorgehensweise wird diese sehr ausführlich im
Kapitel 4 "Praktisches Rapid Control Prototyping" beschrieben und als globale
Handlungsanweisung für die das RCP herangezogen.
1.24
Jetzt soll zunächst erläutert werden, welche Matlab-Programme für die Realisierung
des konzeptorientierten Prototypen benötigt werden.
In Kapitel 1.2.1 wurde schon angedeutet, dass Matlab das konzeptorientierte RCP
mit zwei verschiedenen Softwarewerkzeugen unterstützt, nämlich dem sogenannten
xPC- und mit dem Windows-Target. Wir wollen uns auf das Windows Target konzentrieren, weil es uns zur praktischen Arbeit im Labor für Regelungstechnik zur
Verfügung steht.
An dieser Stelle soll ein gewisses Grundverständnis für die Funktion und das
Zusammenspiel der eingesetzten Matlab-Komponenten geweckt und insbesondere
anschaulich gezeigt werden, wie Matlab automatisch aus einer Simulink-Struktur ein
compilier- und in den Arbeitsspeicher ladbares Programm erzeugen kann.
In Kapitel 3.4.1 "Praktische Nutzung des Realtime Workshops und des Realtime
Windows Targets" wird dann vertiefend auf die praktische Nutzung dieser
Werkzeuge eingegangen.
Zur Nutzung des Real-Time Windows Target wird an Hardware
•
Ein (möglichst moderner) PC und
•
eine A/D-D/A-Wandler-Karte, die kompatibel zum Real-Time Windows Target
ist (nähere Einzelheiten sieh /8/)
benötigt. Folgende Softwarekomponenten müssen auf dem PC installiert sein:
•
Das Betriebssystem Windows XP,
•
Matlab /10/,
•
Simulink /11/,
•
der Real-Time Workshop /9/,
•
das Real-Time Windows Target /8/ und
•
der Open Watcom C/C++ Compiler /110/.
(siehe Anhang A1, welche Softwareversionen im Labor für Regelungstechnik
verfügbar sind.)
Die Kenntnis der Funktion und des Umgangs mit Matlab und Simulink als CAEProgramm für die System- und Regelungstechnik, wie sie z.B. in /4/ vermittelt wird,
wird vorausgesetzt. Der weiterhin benötigte Real-Time Workshop ist eine
Erweiterung der Leistungen von Simulink: er generiert aus Simulink-Strukturen
1.25
automatisch einen Beschreibungscode, erzeugt daraus C-Quellcode, compiliert und
verlinkt ihn mit anderen notwendigen Funktionen, so dass er, geladen in die
Zielhardware die Funktion der ursprünglich entworfenen Simulink-Struktur realisiert.
Allein, ohne zusätzliche Installation der Zielort- (Target-) Software, z.B. des RealtimeWindows Targets, mit dem wir uns hier auseinandersetzen wollen, unterstützt der
Real-Time
Workshop
sogenannte
"Rapid
Simulations".
Das
sind
Simulationsstrukturen, die ca. 5 - 20 mal schneller ablaufen als allein unter Simulink.
Nähere Einzelheiten dazu finden sich in Kapitel 12 von /9/.
Mit der zusätzlich installierten Targetsoftware Real-Time Windows Target kann man
den erzeugten Objektcode auf einem PC in Echtzeit laufen lassen. Um in diesem
Rahmen einen per Simulink erzeugten Regler mit der realen Regelstrecke verbinden
Bild 1.2.3 : Ausschnitt aus dem Blockset des Real-Time Windows Target
zu können, muss die weiter oben beschriebene A/D-D/A-Wandler-Karte
im PC
installiert sein. Während der Installation des Real-Time Windows Target wird dieser
über die Auswahl eines kartenspezifischen Treibers mit der Karte verbunden. In der
Block Library von Simulink taucht dann in einer Unterbibliothek "Blocksets &
1.26
Toolboxes"
das Blockset Real-Time Windows Target auf. Führt man einen
Doppelklick auf dieses Blockset aus, öffnet sich des Fenster, wie es im
vorangehenden Bild 1.2.3 dargestellt ist.
Jeder darin befindliche Simulationsblock ist das Symbol eines speziellen Ein- oder
Ausgangs der sich im PC befindlichen A/D-D/A-Wandler-Karte.
Versieht man einen unter Simulink als Übertragungsfunktion realisierten zeitdiskreten
PI-Regler mit vorgeschalteter Vergleichseinrichtung und der Möglichkeit der
Aufschaltung einer Führungsgröße (z.B. Step Function für einen Führungssprung)
0.2973 -z+0.2828
z-1
Step
Discrete
Transfer Fcn
Bild 1.2.4: Ein zeitdiskreter PI-Regler
mit einem Analog Input für die Messgröße und einem Analog Output für das
Stellsignal, kann man nach der Implementierung des daraus mit dem RTW und dem
RT Windows Target erzeugten Objektcodes der PC über die A/D-D/A-Wandler-Karte
als PI-Regler an der PC-externen Regelstrecke arbeiten:
0.2973 -z+0.2828
z-1
Step
Analog Input
Discrete
Transfer Fcn
Analog
Output
Analog Output
Analog
Input
Bild 1.2.5: Ein zeitdiskreter PI-Regler mit analog Input- und Output-Blöcken
Die Umsetzung einer Simulink-Struktur in ausführbaren Objektcode wird bei Matlab
"Build"-Prozess genannt. Mit diesem Vorgang wollen wir uns im folgenden kurz
beschäftigen.
Solange wir Rapid Prototyping betreiben wollen, wird die praktische Ausführung
dieses Prozesses nach der Installation und Konfiguration der notwendigen Matlab1.27
software nicht mehr als die Betätigung eines Softwarebuttons bedeuten.
Im ersten Schritt übersetzt der RTW die Simulink-Struktur, die den Filenamen
"model.mdl" tragen möge in eine vom Menschen lesbare verbale Beschreibung in
Form einer Skriptsprache aus ASCII-Zeichen. Das erzeugte File wird von der
Software "model.rtw" genannt. Dieser Code dient als Input für den sogenannten
"Target Language Compiler" (TLC). Der TLC wird von der gewählten Targetsoftware,
in unserem Falle also von RT Windows Target bereitgestellt. (Er wird bei Matlab
"System Target File" genannt und trägt beim RT Windows Target den Namen
"rtwin.tlc".) Der TLC kompiliert die Modellbeschreibung "model.rtw" in den für das
Target spezifischen C-Code (model.c, model.h), in unserem Falle für eine Pentium
CPU mit PC-Peripherie.
Anschließend erzeugt der Real-Time Workshop mit Hilfe des sogenannten Make
commands "make.rtw.m" aus einem Muster- (Template-) Makefile "rtwin.tmf" (wobei
tmf für template make file steht) ein für das Windows Target zugeschnittenes
Makefile mit dem Namen "model.mk". dieses Makefile dient zur Steuerung der
Erzeugung des Objektcodes aus den vorher erzeugten C-Quellen. Dazu wird die IDE
des Watcom Compilers eingesetzt.
Der Real-Time Workshop stellt weiterhin ein sogenanntes "Run-Time Interface" zur
Verfügung, das folgende Komponenten enthält:
•
Schnittstellen nach Windows (z.B. für Signalplots auf Simulink-Scopes),
•
Ein-/Ausgabetreiber , z.B. für die Analogsignal-Ein-/ und Ausgabe über die A/DD/A-Wandler-Karte,
•
Integrationsalgorithmen (sog. "Solver" zur numerischen Lösung/Simulation
kontinuierlicher ,dynamischer Systemkomponenten)
Das "Run-Time Interface" und der Modellcode werden zusammen kompiliert, woraus
die ausführbare Datei "model.exe" entsteht, in ihr wird das "model" unter dem "RunTime Interface" ausgeführt.
1.2.3.2
Matlabkomponenten zum Entwurf implementierungsorientierter
Prototypen
Nachdem im vorangegangenen Kapitel beschrieben wurde, welche Matlab/SimulinkProgramme zum Entwurf von konzeptorientierten Prototypen benutzt werden können.
Sollen in diesem Kapitel sukzessive die Programme und ihre Leistungen beschrieben
1.28
werden, mit denen ein implementierungsorientiertes Rapid Control Prototyping
vorgenommen werden kann.
Im Rahmen des Masterstudiengangs "Technische Informatik - Embedded Systems"
soll dazu als Zielsystem ("Target") ein C167 Mikrocontroller der Firma Infineon auf
einem Board ("Development Kit") der Firma Phytec dienen.
Zur Nutzung des C166-Targets wird an Hardware
•
ein moderner PC als Hostrechner mit einer RS 232-Schnittstelle,
•
ein entsprechendes Kabel zur Kopplung zwischen Hostrechner und PhytecBoard und
•
ein Phytec-Board mit C167-Mikrocontroller.
Folgende Softwarekomponenten müssen darüber auf dem PC installiert sein:
•
Das Betriebssystem Windows XP,
•
Matlab /10/,
•
Simulink /11/,
•
Real-Time Workshop /9/,
•
Real-Time Workshop Embedded Coder /12/,
•
Link for Tasking /13/,
•
Target for Infineon C166 /14/ und
•
Tasking Compiler mit Entwicklungsumgebung der Firma Altium /111/.
Um später Messungen am entworfenen Regler, bzw. am Regelkreis vornehmen zu
können, ist es sinnvoll, wenn sich auf dem Host-PC noch - wie beim
konzeptorientierten RCP - eine A/D-D/A-Wandler-Karte im PC befinden würde und
das Real-Time Windows Target installiert wäre.
Da zur Zeit noch keine tiefergehenden Erfahrungen mit den vorangehend genannten
Entwurfswerkzeugen gesammelt wurden, muss dieses Kapitel zunächst noch ein
Fragment bleiben. Es wird ständig durch Ergebnisse von Bachelor-, Diplom- und
Masterarbeiten ergänzt und erweitert.
Die Leserin / der Leser sind eingeladen, sich durch eigene Abschlussarbeiten an der
Vervollständigung des Skripts zu beteiligen.
1.29
1.2.4. Echtzeitbetrieb
Ohne den Begriff Echtzeitbetrieb
exakter zu definieren, wurde er in den
vorangehenden Betrachtungen häufig verwendet mit der Eigenschaft umschrieben,
dass ein eingebettetes System einen technischen Prozess schritthaltend steuern
oder überwachen muss.
Weil die Echtzeitfähigkeit eine zentrale Forderung an Steuer- und Regelgeräte ist,
soll der Begriff in diesem Kapitel etwas näher erläutert und Methoden dargestellt
werden, wie die Echtzeitfähigkeit eingebetteter Systeme herbeigeführt werden kann.
Dazu wollen wir zunächst die in /1/ kurz und treffend beschriebenen Definitionen und
Funktionsbeschreibungen eines Echtzeitsystems zitieren und anschließend zeigen,
dass sich Echtzeitverhalten von Steuergeräten
•
einerseits mit einem Echtzeitbetriebssystem und
•
andererseits wesentlich einfacher, wenn auch nicht so vollkommen, mit
periodischen Interrupts
realisieren lässt. (Die Nutzung periodischer Interrupts als Alternative zu einem
Echtzeitbetriebssystem wird in der Matlab-Literatur häufig "bare baord"-Umgebung
genannt, weil die Modellsoftware des Steuergeräts auf einem Board ohne
Betriebssystem läuft.
Der Real-Time Workshop von Matlab unterstützt beide Methoden. Wir werden uns
auf die im Regelungstechnik-Labor verwendete Methode der periodischen Interrupts
konzentrieren.
In /1/ werden Echtzeitsysteme wie folgt beschrieben:
"Von elektronischen Systemen wird verlangt, dass strenge Zeitbedingungen
eingehalten werden müssen. Charakteristisch für diese Klasse von Systemen ist,
dass z. B. auf Prozeßstörungen in Echtzeit (engl. real–time) reagiert werden muss
und sofort korrigierende Maßnahmen eingeleitet werden. Je nach Anwendungsgebiet
unterscheiden sich die geforderten Zeitbedingungen stark und damit existieren
verschiedene Interpretationen von dem Begriff “Echtzeit”.
Nach DIN 44300 wird Echtzeit wie folgt definiert: Unter dem Begriff Echtzeitbetrieb
wird ein Rechnersystem verstanden, bei dem Programme zur Verarbeitung
anfallender
Daten
ständig
betriebsbereit
1.30
sind,
derart,
dass
die
Verarbeitungsergebnisse innerhalb einer vorgegebenen Zeitspanne verfügbar sind.
Somit ist ein Echtzeitsystem eine Hardware/Softwarekombination, die Daten
empfängt, diese verarbeitet und die Ergebnisse innerhalb einer definierten
Zeitspanne an den Prozeß weitergibt.
Diese Definition nimmt jedoch keine quantitative Aussage über die Länge der
Zeitspanne vor. Diese wird anwendungsspezifisch für unterschiedliche Bereiche
festgelegt und kann von einigen Mikrosekunden bei Spracherkennungssystemen bis
zu einigen Sekunden bei Feueralarmsystemen reichen.
Während bei konventionellen Systemen die Richtigkeit einer Berechnung im
Vordergrund steht und der Zeitpunkt für die Bereitstellung des Ergebnisses
zweitrangig ist, muss im Echtzeitsystem zu einem geforderten Zeitpunkt das
Ergebnis zwingend vorliegen. Echtzeitsysteme werden in ihrer Verarbeitung von
externen Ereignissen (z.B. Interrupts) unterbrochen. Daraufhin muss die Wichtigkeit
des externen Ereignisses bewertet werden und gegebenenfalls direkt in die
Verarbeitung eingegriffen werden. Die zur Verarbeitung anfallenden Daten und
Ereignisse können dabei zu zyklischen Zeitpunkten auftreten oder einer zufälligen
Verteilung unterliegen. Unabhängig von den eingehenden Daten und Ereignissen
ums ein Echtzeitsystem die vorgegebene Reaktionszeit auch im schlechtesten
anzunehmenden Fall (engl. worst case) einhalten.
Neben der Einteilung in anwendungsspezifische Klassen unterscheidet man bei
Echtzeitsystemen auch die Folgen der Nichteinhaltung einer Reaktionszeit. Führt die
Nichteinhaltung zu schwerwiegenden Störungen oder Systemabstürzen, spricht man
von harten Echtzeitbedingungen. Beispiele für solche Systeme sind Anti–Blockier–
Systeme bei Bremsanlagen von Automobilen oder Systeme zur Schnellabschaltung
bei kritischen Zuständen in Kraftwerken. Hat die Nichteinhaltung lediglich eine
tolerierbare Rechenungenauigkeit zur Folge, bezeichnet man dies als weiche
Echtzeitbedingung. Ein Beispiel hierfür sind Klimaanlagen.
•
Echtzeitbetriebssysteme
Bei Echtzeitsystemen wird häufig von einer parallelen oder verteilten Verarbeitung
Gebrauch
gemacht.
Unter
Berücksichtigung
der
Zeitbedingungen
ist
die
Synchronisation der Tasks eines Echtzeitsystems eines der vordringlichsten
Probleme. Zur Unterstützung bei der Programmierung von Echtzeitsystemen
gelangen deswegen spezielle Echtzeitbetriebssysteme (engl. real–time operating
ystems) zum Einsatz, die Mechanismen zur Verwaltung der Betriebsmittel zur
1.31
Verfügung stellen und als Schnittstelle zwischen Systemumgebung und der
Anwendung dienen. Betriebsmittel stellen in diesem Zusammenhang alle Mittel dar,
die von einer Task benötigt werden, um durchgeführt werden zu können. Dazu
zählen Prozessor, Speicher, Peripheriegeräte sowie Programme, Daten, Variablen
und Dateien. Beim Echtzeitbetrieb werden die Aufträge direkt in Form von einzelnen
Programmen vergeben, die abgearbeitet werden müssen. Um den zeitlichen
Anforderungen
zu
Tasksteuerung
(engl.
entsprechen,
task
besitzt
control),
die
das
die
Echtzeitbetriebssystem
einzelnen
Tasks
eine
verarbeiten,
unterbrechen oder beenden kann. Die Ablaufplanung dieser Tasksteuerung bestimmt
die Zuteilungsstrategie, nach der die Prozessorleistung an Tasks verteilt werden.
Dieser Vorgang wird als Task–Scheduling bezeichnet. Die Ablaufplanung muss auch
im worst case Fall die korrekte Verarbeitung gewährleisten. Ist ein System jedoch mit
der Abarbeitung von Tasks überlastet, so dass keine korrekte Verarbeitung mehr
gewährleistet ist, muss das elektronische System bei der Erkennung von
Zeitverletzungen in einen sicheren Zustand übergehen. Es sollte bereits bei der
Auslegung des Systems beachtet werden, dass eine Zeitverletzung ausgeschlossen
werden kann. Um dies zu gewährleisten, muss man die Machbarkeit des
Schedulings (engl. schedulability) nachweisen.
Echtzeitbetriebssysteme sind in der Regel modular aufgebaut und sind bezüglich
ihrer Funktionalität skalierbar (Bild 1.2.6).
Bild 1.2.6: Skalierbares Echtzeitbetriebssystem VxWorks
Dies gilt insbesondere für die Klasse der eingebetteten Systeme, denen oftmals nur
wenig Speicher und eine geringe Prozessorleistung zur Verfügung stehen. Neben
1.32
den stets vorhandenen Grundfunktionen lassen sich bei Bedarf weitere Funktionalität
z.B. zur Datei– oder Netzwerkverwaltung einbinden. Die spezifische Anpassung
eines Echtzeitbetriebssystems an eine Hardwareplattform geschieht über ein Board
Support Package, das dem Betriebssystem das Ansprechen der vorhandenen
Hardware (z.B. Timer, Speicher, Ein–/Ausgabekanäle) ermöglicht.
Der Kern (engl. kernel) eines Echtzeitbetriebssystems besteht aus den elementaren
Systemfunktionen zur Pflege des Systemtakts sowie der Synchronisation und
Verwaltung von Tasks. Er unterscheidet sich insbesondere bei der Unterbrechbarkeit
zu
konventionellen
Betriebssystemen.
Echtzeitbetriebssysteme
sind
voll
unterbrechbar (engl. full–preemptive) und besitzen damit die Möglichkeit, einen
Interrupt
direkt
bei
dessen
Auftreten
zu
bearbeiten.
Betriebssysteme
mit
Unterbrechungspunkten (z.B. Microsoft Windows) bearbeiten einen Interrupt nach
dem Erreichen des nächsten Unterbrechungspunktes (engl. preemption points). Bei
einem nicht unterbrechbaren Kernel (engl. non–preemptive) kann erst nach
Beendigung eines Systemaufrufs auf einen Interrupt reagiert werden.
Bei der Erstellung von Echtzeitsystemen wird häufig versucht, unabhängige
Aufgaben mit verschiedenen Tasks zu realisieren und die zeitlich korrekte
Abarbeitung dem Echtzeitbetriebssystem zu überlassen. Um bestimmen zu können,
welche Task als nächste ausgeführt werden soll, bzw. welche Tasks überhaupt
ausgeführt werden können, teilt ein Echtzeitbetriebssystem Tasks in unterschiedliche
Klassen ein. Insgesamt existieren sechs solcher Klassen:
•
Existent.
•
Nicht existent.
•
Eine Task ist bereit (engl. ready), wenn lauffähig ist, d.h. sie hat alle
Betriebsmittel außer dem Prozessor zugeteilt bekommen.
•
Eine Task ist laufend (engl. running), wenn sie in diesem Augenblick
ausgeführt wird und damit den Prozessor benutzt.
•
Eine Task ist blockiert (engl. blocked), wenn sie nicht ausgeführt
werden kann, weil sie auf die Zuteilung von Betriebsmitteln
oder ein Unterbrechungssignal wartet.
•
Eine Task ist beendet (engl. terminated), wenn sie alle ihre
Anweisungen abgearbeitet und die ihr zugeteilten Betriebsmittel
zurückgegeben hat.
1.33
Bild 1.2.7: Mögliche Taskzustände und Zustandsübergänge
In Bild 1.27 ist dargestellt, welche Übergänge zwischen den sechs Zuständen
möglich sind. Eine Task darf sich dabei nur in einem der Zustände aufhalten. Die
Zustandsübergänge werden vom sogenannten Dispatcher durchgeführt.
•
Task-Scheduling
Der Scheduler eines Echtzeitbetriebssystems bestimmt, wann welche Task
ausgeführt wird. Hierbei stehen mehrere unterschiedliche Verfahren zur Verfügung:
•
Beim Round–Robin Scheduling werden die Tasks zyklisch geordnet und
erhalten den Prozessor für eine definierte Dauer (einem sogenannten Time–
Slice) zugeteilt. Nach Ablauf dieser Dauer wird die Task in jedem Fall
unterbrochen und die nächste Task wird aktiviert. Dieses Verfahren wird
hauptsächlich dann eingesetzt, wenn alle Tasks gleich wichtig sind und die
Prozeßlaufzeiten abgeschätzt werden können.
•
Beim prioritätsbasierten Scheduling erhält jede Task eine bestimmte Priorität
zugewiesen. Der Scheduler führt dann die Task mit der höchsten Priorität aus.
Wird eine sich gerade in der Ausführung befindende Task zugunsten einer
freigeschalteten Task mit höherer Priorität unterbrochen, bevor sie ihre eigene
Abarbeitung
beendet
hat,
spricht
man
von
preemptiven
Scheduling.
Prioritätsbasiertes Scheduling eignet sich für Echtzeitbetriebssysteme.
•
Das Hybrid–Scheduling stellt eine Verbindung der beiden oben genannten
1.34
Scheduling–Mechanismen dar. Dabei werden Tasks, die die gleiche Priorität
besitzen, per Round–Robin Scheduling abgearbeitet.
Trotz der prioritätsbasierten Scheduling–Verfahren kann es zu unerwünschten
Effekten bei der Abarbeitung von Tasks kommen. Dies ist in Bild 1.2.8 dargestellt.
Greift eine Task C mit niedriger Priorität auf eine Ressource (beispielsweise über
eine Semaphore, siehe dazu nächstes Unterkapitel) zu, während zur gleichen Zeit
Task A, die eine höhere Priorität besitzt, die Ressource benötigt, muss Task A
warten, bis die Ressource von Task C freigegeben wird. Dieser Vorgang ist
beabsichtigt und dient der Datenkonsistenz. Wird zum Zeitpunkt t2 allerdings Task B
mit einer mittleren Priorität erzeugt, so wird sie Task C unterbrechen, da sie mit
einer
Bild 1.2.8: Prioritätsumkehr und Prioritätsvererbung
höheren Priorität ausgestattet ist. Damit ergibt sich der unerwünschte Effekt, dass die
mit höchster Priorität versehene Task A sowohl auf Task B als auch auf Task C
warten muss. Dieser Effekt wird als Prioritätsumkehr oder Prioritätsinversion
bezeichnet.
Um dieses Problem zu umgehen, vererbt Task A seine Priorität an Task C. Dabei
wird bei der Beanspruchung einer blockierten Ressource die Priorität der höher
priorisierten Task an die niedriger priorisierte Task weitergereicht. Dieses Verfahren
führt unter Beachtung der Prioritäten weiterer Tasks zu der schnellstmöglichen
Freigabe der Ressource. Task B ist in diesem Fall nicht mehr in der Lage, die
1.35
Abarbeitung von Task C zu unterbrechen. Man spricht in diesem Fall von
Prioritätsvererbung. Bild 1.2.8 unten zeigt die Abarbeitung der drei Tasks nach
Einführung der Prioritätsvererbung.
Die Bereitstellung von Mechanismen zur Interprozeßkommunikation zählt zu den
wichtigsten
Aufgaben
eines
Echtzeitbetriebssystems.
Unter
Interprozeß-
kommunikation versteht man die Möglichkeit, Informationen zwischen verschiedenen
Tasks auszutauschen. Da einzelne Tasks im allgemeinen keine selbständigen
Einheiten darstellen, sondern auf Datenaustausch mit anderen Tasks angewiesen
sind, werden Kommunikationsmittel benötigt, die den Datenaustausch und die
Synchronisation der Tasks übernehmen. Kommunikationsmechanismen, die für
diese Aufgaben verwendet werden, sind im folgenden aufgeführt.
•
Semaphoren zeigen die Verfügbarkeit von Ressourcen an und können auf
nahezu alle Betriebsmittel angewendet werden. Häufig werden Semaphoren auf
speziell für diesen Zweck definierte Variablen angewendet und dienen der
Synchronisation von Tasks. Solange eine Task eine Semaphore besitzt, muss
jede andere Task warten, die auf dieselbe Semaphore zugreifen will, bis die
Semaphore wieder freigegeben wird. Die wartende Task geht in den Zustand
”blockiert” über. Erst nach Freigabe der Semaphore kann die wartende Task auf
die Ressource zugreifen und kann weiter verarbeitet werden.
•
Message Queues dienen der Übermittlung von Daten beliebiger Länge.
•
Ein Shared Memory stellt einen Bereich dar, der von mehreren Tasks zur
gleichen Zeit benutzt werden kann. Beim Datenaustausch über Shared Memory
besitzen die Tasks einen Zeiger auf einen global definierten Speicherplatz, der
sowohl lesend als auch schreibend benutzt werden kann. Normalerweise wird
vor einem Lese– oder Schreibvorgang eine Semaphore auf diesen Bereich
gesetzt, um eine definierte Benutzung zu gewährleisten.
•
Asynchrone Signale entsprechen einem Software–Interrupt und können
zwischen Tasks das Auftreten von Ereignissen signalisieren. " (Ende des Zitats
aus /1/)
1.36
Echtzeitbetrieb mit dem Real-Time Workshop von Matlab
Auch der Real-Time Workshop kann unter einem Echtzeitbetriebssystem, nämlich
Tornado/VxWorks /112/ der Firma Wind River, Inc, USA, laufende Echtzeitapplikationen auf verschiedenen Mikroprozessoren und -Controllern generieren.
Tornado
ist
eine
integrierte
Echtzeitanwendungen.
Man
Entwicklungsbenutzt
und
Tornado
Ausführungsumgebung
zur
Cross-Entwicklung
für
von
Applikationen auf einem Host-PC, zum Downloaden der Anwendung in den Echtzeitprozessor und zum starten der Anwendung. Optional kann man die Aktivitäten des
Echtzeitsystems beobachten (grafische Signalverläufe) und Parameter ändern.
Tornado beinhaltet
•
Application building tool: Compiler, Linker, Make utility,
•
Interactive development tools: Editor, Debugger, Browser, Configuration Tool,
•
VxWorks: Hochleistungs Echtzeitbetriebssystem,
•
StethoScope: Datenerfassung und Monitoring System.
Zur Unterstützung der Tornado Umgebung, die von Wind River, Inc. zugekauft
werden muss, stellt der Real-Time Workshop das sogenannte "Tornado Target" zur
Verfügung (/9/, Kapitel 13). Diese Target wandelt Simulink-Modelle in eine Code der
mit Tornado-Werkzeugen korrespondiert und unter VxWorks läuft. Die Beobachtung
des in Echtzeit laufenden Systems kann mit dem vorangehend genannten
StethoScope
oder
auch
mit
Simulink-Scopes
durchgeführt
werden.
Auch
Parameteränderungen in Modell sind über Simulink (External Mode) möglich.
•
Echtzeitbetrieb mit dem Real-Time Workshop mittels periodischer Interrupts
(Bare Board Betrieb)
Um sich eine verständliche Vorstellung von der Echtzeitverarbeitng mittels
periodischer Interrupts bilden zu können, ist es sinnvoll, zunächst zu klären, wie eine
Simulink-Struktur zur Berechnung einer Systemantwort (also eine Systemsimulation)
abgearbeitet wird. Wir wollen zu diesem Zwecke wieder unser schon weiter vorn
betrachtetes RC-Glied als Beispiel heranziehen:
Nach /2/ wird das folgende RC-Glied
1.37
R = 50kΩ
uin (t)
uout (t)
C = 10µF
Bild 1.2.8: Eine Widerstands-/Kondensatorkombination
durch folgendes Zustandsmodell beschrieben:
•
= −0,5uc (t) + 0,5uin (t)
uc (t)
uout (t) =
(1.2.1)
uc (t)
Daraus lässt sich folgendes Strukturbild entwerfen:
uc (0)
uin (t)
∫
0,5
uout (t)
0,5
Bild 1.2.9: Strukturbild einer Widerstands-/Kondensatorkombination
Diese Struktur wurde im folgenden Bild 1.2.10 noch weiter verfeinert, um deutlicher
die einzelnen Systemkomponenten und die dazwischen liegen Leitungsverbindungen
Integrator
Eingangs −
erregung
uin
Pr oportional −
glied 1
ep1
Summierer
a0i
ei
ap1 e1s1
as1
Leitung 2
e2s1
Leitung 4
uout
ep2
ap2
e : Eingang
a : Ausgang
p : Pr oportiona lglied
s : Summierer
i : Integrator
ai
∫
0,5
Leitung 1
Speicher
und
Anzeige
Anfangs −
wert
0,5
Leitung 3
Leitung 5
Pr oportional −
glied 2
Bild 1.2.10: Verfeinertes Strukturbild einer Widerstands-/Kondensatorkombination
1.38
zu erkennen. Man sieht, dass das System aus zwei Proportionalgliedern, einem
Summierer und einem Integrator (mit Anfangswertaufschaltung der Zustandsgröße)
besteht. Verbunden sind diese Systemelemente mit fünf Leitungen.
Mit etwas Phantasie kann man sich vorstellen, das diese Information, die in der
Simulationsstruktur vorhanden ist, ausreicht, um daraus automatisch folgenden
lauffähigen Code (hier der besseren Anschauung wegen, Matlab Code) zu erzeugen:
% Matlabcode der Simulationsstruktur des RC-Glieds
% Parameter des Systems
R=50e3;
C=10e-6;
T=R*C;
% Eingangserregung
uin=1;
% Zeitachse
tend=5;
dt=0.001;
% Simulationzeitraum
% Rechenschrittweite
% Anfangswert der Zustands
a0i=0;
% Initialisierung
ap1=0;
ap2=0;
a1s1=0;
ai=0;
ai_alt=0;
k=0;
% Alle Ausgangsignale und
% Anfangswertzwischenspeicher = 0.
% Zählvariable
% Berechnungsschleife der Systemantwort
for t=0:dt:tend;
ep1=uin;
% Leitung
% Proportionalglied 1
ap1=T*ep1;
%
%%%%%%%%%%%%%%%%%%%%%
e1s1=ap1;
% Leitung
e2s1=ap2;
% Leitung
% Summierer 1 %%%%%%%
as1=e1s1-e2s1;
%
%%%%%%%%%%%%%%%%%%%%%
ei=as1;
% Leitung
% Integrierer %%%%%%%
if t==0
%
1.39
1
2
3
4
ai_alt= a0i;
%
end
%
ai=ai_alt+ei*dt;
%
ai_alt=ai;
%
%%%%%%%%%%%%%%%%%%%%%
ep2=ai;
% Proportionalglied 2
ap2=T*ep2;
%
%%%%%%%%%%%%%%%%%%%%%
% Leitung 5
% Ausgangssignalspeicher%
k=k+1;
%
uout(k)=ai;
%
%%%%%%%%%%%%%%%%%%%%%%%%%
pause
end
t=0:dt:tend;
figure(1)
plot(t,uout), grid on
% Plot des
% Ausgangssignals
Es treten darin die vier genannten Systemkomponenten (zwei Proportionalverstärker,
ein Summierer und ein Integrator) und vier Leitungsverbindungen auf. Der Integrator
wird näherungsweise durch eine kumulierte Summe von Rechtecken ei ∗ dt gebildet.
Er ist in der Lage einen Anfangswert der Zustandsgrößen a0i zu berücksichtigen.
(Das Ausgangssignal des Integrators, das auch das Ausgangssignal des
Gesamtsystems ist, wird in einem Speicher uout(k) abgelegt, um es nach
Matlabkonventionen nach Beendigung der Schleifendurchläufe (bei t ≥ tend)
anzeigen zu können.)
Das Programm beginnt mit einer Zuweisung der Systemparameterwerte für R und C
und der Berechnung der entsprechenden Zeitkonstante
T = R∗C = 50kΩ ∗ 10µF = 0,5 sek.
Anschließend werden die Eingangserregung uin = 1, ein Einheitssprung, und der
Anfangszustand der Zustandsgröße a0i = 0 festgelegt. Danach erfolgt die
Parametrierung der späteren Zeitachse, über der die Systemantwort berechnet
werden soll. Zuletzt werden von allen Systemkomponenten die Ausgänge initial auf
Null gesetzt, um von einem definierten Anfangszustand auszugehen.
Die eigentliche Simulation erfolgt in der anschließenden for-Schleife, die bei t = 0
beginnt und (tend / T +1)-mal durchlaufen wird.
Das Ausgangssignal uout wird gespeichert, damit es nach Vollendung der
1.40
Schleifendurchläufe angezeigt werden kann. (So könnte übrigens mit jedem Signal in
der Simulationsschleife verfahren werden.)
In Hinblick auf den Unterschied zwischen Simulation und Echtzeitbetrieb ist es
wesentlich, das innerhalb des Integrators eine if-Abfrage erfolgt, die nur zu einem
Zeitpunkt, nämlich t = 0 wirksam ist und zu einer Zuweisung des Anfangswerts a0i
der Zustandsgröße führt. Das heißt, der Schleifendurchlauf ist zum Zeitpunkt t = 0
etwas länger, womit auch die Programmlaufzeit in diesem Durchlauf etwas länger
dauert als bei den folgenden Durchläufen.
Für eine Simulation ist das unwesentlich und wird kaum bemerkt. Wäre die zu
berechnende Struktur z. B. ein Steuer- oder Regelalgorithmus, der für eine feste
Abtastzeit T entworfen wäre und sollte dieser Algorithmus nun in seiner realen
Umwelt arbeiten, wäre eine solche variable Abtastzeit fatal: Obwohl für eine
bestimmte feste Abtastzeit entworfen, würde der Steuer- oder Regelalgorithmus mit
variablen Abtastzeiten betrieben. Das Ergebnis wären falsche Berechnungsergebnisse.
Davon kann man sich leicht überzeugen, wenn man z. B. eine zeitdiskreten Regler
für eine Abtastzeit T = T1 entwickelt und ihn in einem Regelkreis mit einer anderen
Abtastzeit T ≠ T1 betreibt. Im vorliegenden Fall wäre das Ergebnis nach
unüberschaubarer, weil sich die Abtastzeit während des Betriebs ändert.
Mit Hilfe eines periodischen z.B. mit einem Hardware-Timer getakteten Interrupts, der
im Abstand der Abtastzeit, die zum Entwurf des Steuer-/Regelalgorithmus benutzt
wurde, eine Interrupt-Service-Routine aufruft, kann dieses Problem gelöst werden.
Die Interrupt-Service-Routine dient als Ersatz für die Simulationsschleife des
vorangehend betrachteten
Simulationsprogramms und in ihr werden die gleiche
Berechnungen vorgenommen. Alles bleibt damit gleich, bis auf die Tatsache, dass
das Ergebnis der Rechnung immer nach Ablauf eines festen Zeitintervalls (Abtastzeit
T = Periodendauer des erzeugten Interrupts) zur Verfügung steht.
Man muss lediglich darauf achten, dass innerhalb der Periodendauer zwischen zwei
Interrupts auch der am längsten dauernde Programmabschnitt (bei unserem Beispiel
der Schleifendurchlauf zum Zeitpunkt t = 0) vollständig abgearbeitet werden kann.
Falls der Rechner zur Berechnung des Codes der ehemaligen Schleife länger
braucht als die Zeit zwischen zwei Interrupts, muss entweder der Algorithmus mit
einer größeren Abtastzeit entworfen oder ein schnellerer Rechner genutzt werden.
1.41
Matlab spricht von einer Single Tasking Umgebung, wenn auf einer CPU ein oder
mehrere
Steuer-
oder
Regelalgorithmen
laufen,
die
mit
einer
Abtastzeit
beziehungsweise mit einer Rechenschrittweite betrieben werden.
Laufen auf einer CPU mehrere Algorithmen, die mit verschiedenen Abtastzeiten
betrieben werden, z.B. ein kontinuierliches System mit der Rechenschrittweite dt und
ein zeitdiskretes System mit der Abtastzeit T ≠ dt oder zeitdiskrete Systeme mit
verschiedenen Abtastzeiten T1 ≠ T2 spricht man von einer Multi Tasking Umgebung.
Für eine Single Tasking Umgebung wird folgendes Timing angegeben (/9/, Kapitel 7):
periodische
Interrupts
Abtastzeit /
Re chenschrittweite
Zeitachse
Interrupt − Service − Routine
zur Berechnung des Systemcodes
(Steuer − / Re gelalgorithmus)
Zeit zur Bearbeitung der Hint ergrundtask
Bild 1.2.11: Task Timing für Single Tasking Systeme mit periodischen Interrupts
Die nach oben zeigenden Pfeile stellen die periodischen Interrupts dar, die in
Schritten der Abtastzeit eine Interrupt-Service-Routine auslösen, die einen
Rechenschritt des Steuer-/Regelalgorithmus ausführt. (Das entspricht einem
Schleifendurchlauf des vorangehend beschriebenen Simulationsprogramms.)
Innerhalb dieser Periode werden alle zeitkritischen Operationen ausgeführt:
•
Lesen eines Eingangssignalwerts z. B. vom A/D-Wandler,
•
Berechnung
aller
Ausgangssignalwerte
der
Systemkomponenten
des
Systemmodels/Algorithmus,
•
Berechnung des Ausgangssignalwertes des Gesamtsystems,
•
Ausgabe des berechneten Ausgangssignalwerts z. B. über einen D/A-Wandler.
Nach Beendigung dieser Operationen kehrt die CPU aus der Inerrupt-Service1.42
Routine in eine ständig laufende Hintergrund Task zurück. Hier ermöglicht Matlab die
Erledigung von nicht zeitkritischen Aufgaben, z. B. die Ausgabe des berechneten
Ausgangssignalwerts des Algorithmus über ein Simulink-Scope oder die Änderung
von Parametern im Algorithmus.
Reicht die Zeit zwischen zwei aufeinander folgenden Interrupts nicht aus, um den
Code der Interrupt Service Routine und der Hintergrundtask vollständig abzuarbeiten,
muss, wie schon oben beschrieben, der Algorithmus für eine größere Abtastzeit neu
berechnet oder ein schnellerer Rechner eingesetzt werden.
Ebenfalls in /9/, Kapitel 7, wird Pseudokode angegeben, der die Ausführung der
Interrupt-Service-Routine, die dort den Funktionsnamen rtOneStep ( ) und des
main ()-Programms in dem die Hintergrundtask (Background Task) läuft, etwas
ausführlicher beschreibt:
rtOneStep()
{
Check for interrupt overflow
Enable "rtOneStep" interrupt
ModelOutputs
-- Major time step.
LogTXY
-- Log time, states and outports.
ModelUpdate
-- Major time step.
Integrate
-- Integration in minor time step for
-- models with continuous states.
ModelDerivatives
Do 0 or more
ModelOutputs
ModelDerivatives
EndDo (Number of iterations depends upon the solver.)
Integrate derivatives to update continuous states.
EndIntegrate
}
main()
{
Initialization (including installation of rtOneStep as an
interrupt service routine, ISR, for a real-time clock).
While(time < final time)
Background task.
EndWhile
Mask interrupts (Disable rtOneStep from executing.)
Complete any background tasks.
Shutdown
}
Beginnen wir mit der Erläuterung des Codes beim Hauptprogramm (main ()). Dort
1.43
wird zunächst die Interrupt-Service-Routine initialisiert, in dem ein Hardware-Timer
(real-time clock) so programmiert wird, dass er periodische Interrupts mit der
gewünschten Periodendauer (base sample time) erzeugt. Anschließend geht das
Hauptprogramm für die Zeit "t < final time" in die Hintergrundtask (Background
task),
wo die weiter vorn beschriebenen Aktivitäten, z. B. das Anzeigen von
berechneten
Daten
auf
einem
Scope
vorgenommen
werden.
Soll
die
Echtzeitumgebung nicht ständig laufen, muss für die "final time" ein endlicher
Zeitwert eingetragen werden. Wird dieser dann irgendwann einmal erreicht, wird der
periodische Aufruf der Interrupt-Service-Routine gestoppt (Mask interrupt) und alle
Aktivitäten der Background Task beendet.
Die Interrupt-Service-Routine prüft zunächst immer, ob die vorangegangene ServiceRoutine vollständig abgearbeitet wurde (Check für Interrupt overflow). Ist das nicht
der Fall, wird die Ausführung abgebrochen (z.B. mit "Disable interrupt"). Wurden alle
Befehle innerhalb der Dauer des Interrupts vollständig abgearbeitet, wir die aktuelle
Interrupt-Service-Routine ausgeführt (Enable rtOneStep).
Innerhalb der Service-Routine werden zuerst das oder die Ausgangssignale des
Gesamtsystems berechnet (ModelOutputs) und ausgegeben. Dann werden der
Zeitpunkt
(time),
die
aktuellen
kontinuierlichen
Zustände
(states)
und
die
Ausgangsgrößen der Systemelemente (outports) gespeichert (Log). Anschließend
werden die Ausgangssignale aller Systemelemente (zeitdiskrete Blöcke und alle
anderen Blöcke ohne kontinuierliche Zustände)
auf die aktuell anliegenden
Eingangssignale berechnet. Die Integrationsschleife zwischen "Integrate und
EndIntegrate" berechnet die kontinuierlichen Zustände und Ausgangssignale
eventuell vorhandener kontinuierlicher Übertragungsblöcke.
Der Pseudocode berücksichtigt die Tatsache, dass eine solche Berechnung mittels
eines numerischen Integrationsalgorithmus, z.B. des Runge-Kutta-Algorithmus
durchgeführt wird. Ein solcher Algorithmus teilt im Allgemeinen einen solchen
Berechnungsschritt innerhalb der Service-Routine (Major time step) in weitere
Teilintervalle
auf,
in
denen
er
zur
Erhöhung
der
Rechengenauigkeit
in
Zwischenschritten (Minor time steps) Zwischenergebnisse berechnet, (weiter genutzt
wird allerdings nur der im letzten Schritt berechneten Zustand). Der Runge-KuttaAlgorithmus arbeitet häufig mit vier Schritten.
1.44
•
Multitasking Echtzeitbetrieb mit dem Real-Time Workshop mittels
periodischer Interrupts (Bare Board Betrieb)
Wenn ein eingebetteter Mikrocontroller durch die Bearbeitung einer Steuerungs/Regelungsaufgabe nicht ausgelastet ist, d. h. nur ein geringer teil Rechenkapazität
genutzt wird, kann er zur Bearbeitung anderer Aufgaben (Tasks) herangezogen
werden.
Für ein solches Multitasking stellt der Real-Time Workshop auch einen Bare Board
Modus auf der Basis periodischer Interrupts zur Verfügung.
Dieser Modus kommt immer dann zur Anwendung, wenn auf einem Prozessor zwei
oder mehrere Steuer-/Regelalgorithmen mit verschiedenen Abtastzeiten laufen
sollen. Dabei kann auch unter einer der Tasks ein kontinuierlicher Algorithmus sein,
der mit Hilfe eines Integrationsalgorithmus bei einer Rechenschrittweite dt arbeitet.
Die
zweite
und
weitere
Tasks
müssen
dann
zeitdiskret
Algorithmen
mit
verschiedenen Abtastzeiten sein. Um eine synchrone Abarbeitung der Tasks zu
gewährleisten, müssen die Abtastzeiten aller Task sein ganzzahliges Vielfaches der
kürzesten gewählten Abtastzeit oder Rechenschrittweite sein.
Der Task mit der kürzesten Abtastzeit wird vom Real-Time Workshop automatisch
die höchste Priorität zugeordnet, der Task mit nächst langsameren, die zweithöchste
Priorität, usw.. Damit ergibt sich eine Timing, wie es beispielhaft für drei Tasks (drei
Algorithmen mit drei verschiedenen Abtastzeiten) im folgenden Bild 1.2.12 dargestellt
ist (/9/, Kapitel 8).
Die fetten nach oben zeigenden Pfeile stellen die periodischen Interrupts in den drei
Proritätsebenen dar, die die entsprechenden
Interrupt-Servic-Routinen starten,
sofern nicht eine andere Interrupt-Servic-Routine mit höherer Prorität gestartet
werden muss. Man erkennt an der zeitlichen Lage dieser Pfeile, dass niedriger
priorisierte
Interrupts in einer Zeitspanne auftreten, die einem ganzzahligen
Vielfachen der Basis-Abtastzeit entsprtcht. Nennt man die Basis-Abtastzeit
TMin = T1 = t1 − t 0 , hat die mittlere Prioritätsebene eine Abtastzeit von T2 = 2 ⋅ T1 und
die untere Ebenen T3 = 4 ⋅ T1 .
Die gestrichelten, nach unten zeigenden Pfeile zeigen die Freigabe der
Ausführungszeit für eine niedriger priorisierte Task an. Die gestrichelten, nach oben
zeigenden Pfeile zeigen die vorzeitige Freigabe einer niedriger priorisierten Task zu
Gunsten einer höher priorisierten an. (Dies wird häufig als präemptives Verhalten des
Multitasking Betriebssystems bezeichnet.)
1.45
t0
t1
t2
t3
t4
Pr iorität 1
Pr iorität 2
Pr iorität 3
periodische Interrupts
Freigabe der Rechenzei t aneine
geringer priorisierte Task
Aktive Laufzeiten
der Tasks
Unterbrechungszeiten
niederpriorisierter Tasks
Vorzeitige Freigabe der Rechenzei t
an eine höher priorisierte Task
Bild 1.2.12: Task-Timing für Multitasking Umgebungen mit periodischen Interrupts unter den Real-Time Workshop
Die hellgrau markierten Kästchen, bzw. Kästchenteile sind die aktiven Laufzeiten der
einzelnen Tasks. Die dunkler markierten Kästchenteile in den niedriger priorisierten
Ebenen markieren gerade von höher priorisierten Tasks unterbrochene InterruptService-Routinen.
Bei genauerem Hinsehen erkennt man, dass die aktiven Arbeitszeiten der Tasks und
die zur Verfügung stehende Rechenzeit der einzelnen Tasks deterministisch
festliegen und voraus berechenbar sind. Trotz des deterministischen Betriebs können
Übergabefehler (Transition Errors) auftreten (/9/, Kapitel 8), dies allerdings nur, wenn
in einem Algorithmus verschiedene Abtastzeiten benutzt werden. Tauschen die mit
verschiedenen Abtastraten auf einem Mikrocontroller laufenden Algorithmen
untereinander keine Daten aus, können Übergabefehler nicht auftreten. Der RealTime Workshop stellt sogenannten "Rate Transitons Blocks" zur Verfügung, mit
denen bei der Datenübergabe von langsamer zu schneller getakteten SimulinkBlöcken und umgekehrt solche Übergabefehler vermieden werden können. Darüber
hinaus kann man im "Solver"-Parametrierungsfeld bei "Automatically handle data
transfer between tasks" ein Häkchen setzen, dann integriert der Realt-Time
Workshop automatisch unsichtbare, also nicht dargestellte "Rate Transitons Blocks"
an die notwendigen Stellen in der Simulink-Struktur des Algorithmus.
Obwohl die meisten Anwendungen der Real-Time Workshop mit dem Bare Board
Multitasking auskommen, muss in einigen Anwendungen auch auf asynchron
auftretende Ereignisse reagiert werden. Dies kann allerdings nur in Anwesenheit
eines Echtzeitbetriebssystems, vorzugsweise Tornado/VxWorks, realisiert werden.
Im Blockset des Real-Time Workshops befindet sich eine VxWorks-Library, die
Interface- Blöcke zu diesem Echtzeitbetriebssystem zur Verfügung stellt. In einer
weiteren Library "Create Yor Own Asynchronous Interrupt Library" befinden zwei
Blöcke,
die
als
Interface
zu
beliebigen
anderen
Echtzeitbetriebssystemen
weiterentwickelt werden können. Die Nutzung dieser Blöcke wird ausführlich in (/9/,
Kapitel 16) und in /15/ beschreiben.
Da wir im Rahmen der praktischen Nutzung des Real-Time Workshops nur den
Signale Tasking -Betrieb nutzen werden, soll auf eine nähere Beschreibung des
Multitasking und des asynchronen Echtzeitbetriebs nicht weiter eingegangen werden.
Anwendungsspezifische
Zusammenhänge
Workshops werden in Kapitel 3.4 beschrieben.
1.47
bei
der
Nutzung
der
Real-Time
1.2.5 Festkommaarithmetik
•
Motiv zur Nutzung von Festkommaarithmetik
In digitaler Hardware können Zahlen als Fließkomma- (Floating Point) oder
Festkomma- (Fixed Point) Datentypen dargestellt werden. (Andere Datentypen sind
auch noch möglich, aber zur Berechnung von Algorithmen bevorzugt man die beiden
genannten.) Beide Datentypen werden durch Datenworte mit einer festen Anzahl von
Bits beschreiben. Jedoch ist der darstellbare Zahlenbereich einer Festkommazahl
viele geringer als der einer Gleitkommazahl mit gleicher Datenwortlänge.
Der darstellbare Zahlenbereich wird bei einer Fließkommazahl primär durch die
Datenwortlänge des Exponenten und die Auflösung durch die Datenwortlänge der
Mantisse beschreiben. Schon mit einem 8-Bit Datenwort für den Exponenten lassen
sich Zahlenbereich von ca. 10^ ± 127 realisieren und die Auflösung steigt mit der
Länge des Datenwortes der Mantisse.
Bei einer Festkommazahl fällt die Aufteilung in Mantisse und Exponent weg, es
existiert nur noch ein Datenwort. Je nach Lage des Kommas (Radix Point) innerhalb
dieses Datenworts steigt oder verringert sich der darstellbare Zahlenbereich (Range),
was mit einer Erhöhung bzw. Verringerung der Auflösung/Genauigkeit (Precision)
verbunden ist.
Dies hat zur Folge, dass bei der Nutzung von Festkommazahlen bei jeder
Rechenoperation eine relativ aufwändige Skalierung (Positionierung des Kommas
innerhalb des Datenwortes) vorgenommen werden muss. Würde man Prozessoren
mit Gleitkomma-Harware verwenden, müsste man sich darüber keine Gedanken
machen. Damit erhebt sich die Frage, warum man immer noch vorwiegend
Mikrocontroller mit Festkommahardware einsetzt?
Den Vorteilen der Gleitkommaarithmetik stehen eine Reihen von Nachteilen
entgegen:
Gleitkomma-Harware ist aufwändiger, d.h. es sind elektronische Schaltungen mit
mehr Bauelementen als bei Festkommaarithmetik notwendig. Dadurch erhöht
sich der Platzbedarf auf dem Chip und die Stromaufnahme wird höher. Erhöhter
Strombedarf belastet Batterien stärker und erzeugt Verlustwärme, wodurch die
Packungsdichte
auf
dem
Chip
verringert
1.48
werden
muss.
Wegen
der
aufwändigeren Hardware erhöhen sich die Kosten, was sich insbesondere bei
Massenprodukten negativ bemerkbar macht.
Gleitkomma-Rechenoperationen,
die
ja
Exponenten
und
Mantissen
verschiedener Zahlen miteinander zu verknüpfen und abzugleichen haben,
dauern länger als Festkomma-Rechenoperationen. Damit sinkt der Durchsatz
eines Gleitkommaprozessors.
Will man Kosten sparen und realisiert die Gleitkommarechnung per Software,
wird die Performance / der Durchsatz noch schlechter und der Stromverbrauch
steigt wegen der längeren Rechenzeiten auch noch an.
Auf Grund dieser Zusammenhänge müssen wir uns mit der Implementierung von
Festkommaarithmetik
zur
Berechnung
von
Steuer-
und
Regelalgorithmen
auseinandersetzen.
•
Grundlagen und Begriffe der Festkommaarithmetik
Festkommazahlen im Binärformat erlauben es, reelle Zahlen als eine Integerwert
durch Festlegung einer Datenwortlänge und der Lage eines Binärkommas zumindest
näherungsweise zu beschreiben.
Das folgende Beispiel zeigt die Dezimalzahl 6,5 als binäre Festkommazahl,
beschrieben
durch
ein
8-Bit
Datenwort
und
einem
0
0
0
2−3
2−4
Binärkomma
an
der
gekennzeichneten Stelle:
0
1
1
0
+
22
21
20
1
2−1 2−2
Bild 1.2.13: Beschreibung der Dezimalzahl 6,5 als binäre Festkommazahl
Aus der Wertigkeit der Bits lässt sich die Dezimalzahl 6,5 ablesen. Auf dem
folgenden
Bild
1.2.14
werden
alle
notwendigen
Zusammenhang wichtig sind, dargestellt:
1.49
Begriffe,
die
in
diesem
Wortlänge
Dezimalzahl : Ganze Zahl links vom
Dezimalkomma (6),gebrochnener
Teil rechts von Dezimalkomma (5)
+6,5
64447444
8 644444744444
4
8
0
1
1
0
1
0
0
0
2
22 42444
2−3 2−43
2−1 2−4
21 203 14444
144
244444
Äquivalente Festkommazahl :
ganzahliger Teil links vom Binärkomma (110),
gebrochener Teil rechts vom Komma (1000)
gebrochener
ganzzahliger
Teil
Teil
Dezimale Gewichte
Vorzeichen −
Auflösung
=
Binär −
der Binärstellen
bit
−4
2
0,0625
=
komma
0=+
1 =−
Maximaler Wertebereich :
3
−2 bis 23 − 0,0625 = −8 bis 7,9375
Bild 1.2.14: Begriffe die bei der Darstellung von Dezimalzahlen als binäre Festkommazahlen wichtig sind
Die Umrechnung sowohl des ganzzahligen als auch des gebrochenen Teils der
binären Festkommazahl in die entsprechenden Teile der Dezimalzahl erfolgt durch
x
Aufsummierung der dezimalen Gewichte (2 ) der mit 1 gekennzeichneten
Binärstellen:
21 + 22 = 2 + 4 = 6
1
Gebrochener Teil:
2-1 = = 0,5
2
Daraus folgt die Dezimalzahl:
6+0,6 = 6,5 .
Ganzzahliger Teil:
Das ganz links außen liegende Bit gibt das Vorzeichen an: 0: +; 1: - .
Die Auflösung, das ist der kleinste darstellbare von Null verschiedene Wert, den die
Festkommazahl annehmen kann, wird durch das dezimale Gewicht der ganz rechts
außen liegenden Binärstelle beschrieben:
Auflösung: 2-4 = 0,0625.
Der maximale durch die Festkommazahl darstellbare Zahlenbereich geht von:
-2x bis + 2x − Auflösung.
Wobei x die Anzahl der links vom Festkomma liegenden Bits minus des
Vorzeichenbits, im vorliegenden Fall x = 3, ist. Damit ergibt sich ein Wertebereich
von:
-23 bis + 23 − 0,0625,
beziehungsweise von:
-8 bis + 7,9375.
Man kann sich leicht davon überzeugen, dass eine Verschiebung des Kommas nach
rechts eine Erhöhung des Wertebereichs (unter Verlust von Auflösung) und eine
Verschiebung des Kommas nach links eine Verkleinerung des Wertebereichs mit
einer Verbesserung (Verkleinerung ) der Auflösung einher geht.
•
Festkommaarithmetik unter Simulink
Um mit Festkommaarithmetik nicht nur Simulationen durchführen, sondern auch
Code für eingebettete Systeme generieren zu können, muss Simulink um das "Fixed
Point Blockset" ergänzt werden.
1.51
Simulink stellt eine Demonstrationsstruktur mit dem Namen "Double to Fixed-Point
Conversion" zur Verfügung. (Im Matlab Command Window (MCW) den String "demo"
eingeben, im sich öffnenden "Help Navigator" Simulink anklicken, aus dem sich
öffnenden Menü "Simulink Fixed Point" anklicken und im MCW erscheint als erstes
Demonstrationsprogramm "Double to Fixed-Point Conversion", das nach dem
Anklicken erläutert wird. Durch Betätigung des Links (oben rechts) "Open this model"
öffnet sich die Simulink-Struktur, die dann gestartet werden kann.)
Double to Fixed-Point Conversion
double
Signal
Generator
Convert
sfix 5_En2
Dbl -to-FixPt
double
double
FixPt-to-Dbl
Mux
double
Mux
Scope
?
Copyright 1990 -2007 The MathWorks , Inc.
Bild 1.2.15: Simulationsstruktur für "Double to Fixed Point Conversion"
Mit dieser Simulation können die Auswirkungen einer Lageänderung des
Binärkommas bei der Wandlung von Double-Precision-Gleitkommazahlen in
Festkommazahlen demonstriert werden. Mit dem "Signal Generator" wird ein
Sägezahnsignal mit einem Signalanstieg von -10 bis +10 zum Zeitpunkt t=0 und ein
linearer Abfall von +10 nach -10 in der darauf folgenden Sekunde mit der
Matlab/Simulink üblichen Double-Precision Auflösung erzeugt. Diese Signal wird als
dünne gestrichelte Linie auf den folgenden Bildern angezeigt.
Anschließend wird das Double-Precision-Signal in der Simulink-Struktur mittels eines
"Data-Type-Conversion-Blockes" (DTC-Block) aus der "Signal and Systems"Blocklibrary von Simulink in ein Signal mit Festkommadatentypen gewandelt.
Darauf hin werden mit einem zweiten DTC-Block bei Erhaltung der im ersten DTCBlock berechneten Werte und auch deren Auflösung diese wieder in Werte eines
Double Datentyps gewandelt und ebenfalls auf dem gleiche Scope angezeigt. (Der
Grund für dies Wandlung liegt darin, dass das Scope keine verschiedenen
Datentypen gleichzeitig anzeigen kann.)
1.52
Als Ausgangsdatentyp (Output data type) wird im Parametrierungsfenster des ersten
DTC-Blockes der Fixed-Point-Datatyp
fixdt(x,y,z)
{
1 Vorzeichen berücksichtigen
0 Vorzeichen nicht berücksichtigen
y : Datenwortlänge
z : Länge des gebrochenen Teils des Datenworts
x:
mit der Parametrierung fixdt(1, 5, 2) und den folgenden weiteren Parametrierungen
Bild 1.2.16: Parametrierung des ersten DTC-Blockes
gewählt. Damit ergibt sich folgendes Simulationsergebnis:
1.53
10
5
0
-5
-10
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Bild 1.2.17: Ergebnis der ersten Simulation zur Datentyp-Wandlung
Bei einer Wortlänge von 5 Bit, einem Vorzeichenbit und einem gebrochenen Teil des
Datenworts von 2 Bit berechnet man eine Auflösung von 2−2 = 0,25 und einen
maximalen Wertebereich von
−25 − 2 −1 bis 25 − 2 −1 − 0,25
−4
bis
3,75,
⇒
was auch in der Simulation zu erkennen ist. Im Falle der Übersteuerung (im vorderen
Bereich von ca. t = 0 - 0,3 und im hinteren Bereich von t = 0,7 - 1), d. h. wo das
Eingangssignal größer (kleiner) ist als der Wertebereich des Eingangssignals, geht
der DTC-Block in die Begrenzung.
Verändert man den "Output data type" auf
fixdt(1, 5, 1) verschlechtert sich die
Auflösung auf 2−1 = 0,5 und der Wertebereich vergrößert sich auf
−25 −1−1 bis 25 −1−1 − 0,15
−8
bis
7,5.
⇒
Damit ergibt sich erwartungsgemäß die folgende zweite Simulation (vergleiche Bild
1.2.18) mit dem vergrößerten Wertebereich und der verschlechterten Auflösung.
1.54
10
5
0
-5
-10
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Bild 1.2.18: Ergebnis der zweiten Simulation zur Datentyp-Wandlung
Bei bekannten Signal-Maximal- und -Minimalwerten, die man durch eine Simulation
mit Double-Precision-Fließkomma-Datentypen bestimmen und in die entsprechenden
Felder (Output minimum / Output maximum) des Parametrierungsfeldes des DTCBlocks (vergleiche Bild 1.2.16) einträgt, kann man nach Betätigung des
Doppelpfeilknopfes (>>) im Parametrierungsfeld auf einen sich öffnenden neuen Teil
des Feldes gelangen, wo man durch einen Knopfdruck auf den Button "Calculate
Best-Precision Scaling" die Länge des ganzzahligen und des gebrochenen Teils des
Datenworts der Festkommazahl automatisch von Simulink berechnen lassen kann.
Nicht nur die Data-Type-Conversion-Blöcke besitzen die Möglichkeit der Anpassung
des
Wertebereichs
an
die
maximal
und
minimal
im
Block
auftretenden
Signalamplituden. Auch alle Blöcke, die z.B. zum Aufbau eines zeitdiskreten Reglers
gehören (Summierer, Verstärker) beinhalten die Möglichkeit des automatischen "Best
Precison Scaling". Die in diesem Zusammenhang auch benötigten "Unit delays" (1/z)
benötigen diese Eigenschaft nicht, weil sie die Amplitude des Eingangssignals nicht
verändern sondern nur um einen Abtastschritt verzögern.
Mit Hilfe des sogenannten "Fixed-Point Tools", das man mit einem rechten Mausklick
in die zu wandelnde Simulink-Struktur und Auswahl von "Fixed Poit Settings" aus
dem sich öffnenden
Festkommazahlen
für
Menü auswählt, kann man diesen Anpassungsvorgang an
ganze
Simulationsstrukturen
(z.B.
Regler)
in
einem
Arbeitsgang durchführen und mit einer Simulation mit Double Datentypen
vergleichen.
Auf dieses Werkzeug wird im Rahmen der aktuellen Lehrveranstaltung nicht
1.55
eingegangen, weil das Real-Time Windows Target, das aktuell im Labor eingesetzt
wird, nicht mit Festkomma-Datentypen arbeitet.
Übertragungsfunktionen, mit denen man sonst in Simulationen Regler realisiert,
können nicht mit "Best Precision Scaling" für die Verarbeitung von Festkommazahlen
automatisch abgeglichen werden, weil nicht jeder Rechenschritt für das "Fixed Point
Tool" beobachtbar ist. Dies ist aber notwendig, um die maxi- und minimalen
Berechnungswerte bestimmen zu können, um daraus die beste Auflösung bei
Einhaltung des notwendigen Wertebereichs berechnen zu können.
Die benötigten Rechenoperationen (Multiplikation und Summation) müssen mit
einzelnen Simulink-Blöcken quasi "atomar" durchgeführt werden.
1.2.6 What is in the Loop?
Im
Kapitel
1.2.1
"Entwurfsmodelle"
wurde
beschrieben,
dass
eingebettete
Steuerungs-/Regelungsprototypen in unterschiedlichsten Fertigstellungsgraden als
konzept-, architektur- und implementierungsorientierte Realisierungen in den zu
beeinflussenden Prozess eingefügt werden.
Häufig existiert dieser Prozess aus verschiedenen Gründen auch nicht real, sondern
liegt als nicht echtzeitfähiges oder echtzeitfähiges Simulationsmodell oder als
echtzeitfähiges Simulationsmodell in Kombination mit realen Systemkomponenten
(z.B. simuliertes Kraftfahrzeug mit realem Getriebe zum Test des Prototypen eines
Getriebesteuergeräts) vor.
Zu allen diesen Kombinationen von verschiedenen Fertigstellungsgraden der
Steuergeräte und Art des Vorliegens des zu steuernden Prozesses gibt es in der
aktuellen
Literatur
Bezeichnungen
die
schlagwortartig
diese
verschiedenen
Kombinationen erklären sollen. Weil es sich immer um Regelkreise handelt, kommt in
diesen Bezeichnungen immer die Phrase "in the Loop" vor und das "was", welches
sich in der Schleife (Loop) befindet, bezieht sich auf den Steuerungsprototypen.
Damit sind aber auch schon die Gemeinsamkeiten der Definitionen weitgehend
erschöpft. Beginnen wir mit der einheitlichsten Definition:
•
"Hardware in the Loop" (HIL)
In /17/ versteht man darunter einen Regelungs-/Steuerungsprototypen dessen
Software auf seiner Zielhardware läuft und mit einem in Echtzeit simuliertem
1.56
Prozess, der z.B. auf einem PC läuft, verbunden ist.
/118/
verbreitert
diese
Definition
dahingehend,
dass
auch
mechatronische
Komponenten, die die Software des Regelungs-/Steuerungsprototypen beinhalten,
und an dem vorangehend genannten simulierten Prozess arbeiten, als "Hardware in
the Loop" bezeichnet werden. Weitere Literaturstellen, z.B. /16/ beschreiben das HILPrinzip sehr ähnlich.
Bei allen Autoren wird hervorgehoben, dass das HIL-Prinzip sehr gut automatisierte
Tests unterstützt und sehr kostengünstig ist, weil kein Eingriff in den realen Prozess
erfolgen muss. Dies hat zur Folge, dass sich mit dem HIL-Ansatz auch
Systemzustände testen lassen, die aus Sicherheitsgründen im realen System nicht
testbar sind.
•
"Software in the Loop" (SIL)
Bei der Definition von "Software in the Loop" gehen die Festlegungen verschiedener
Autoren relativ weit auseinander. /17/ versteht darunter die prototypische
Implementierung der Regelungs-/Steuerungsprototypen-Software in echtzeitfähige
Hardware, die noch nicht die später zu implementierende ist, aber so leistungsfähige
Komponenten besitzt, dass in Bezug auf Rechenleistung, Speicherkapazität,
Auflösung der Messaufnehmer, usw. keine oder nur geringfügige Einschränkungen
für den verwendeten Algorithmus entstehen. Diese Hardware wird mit dem realen
Prozess verbunden.
/118/ dagegen implementiert die entwickelte Regelungs-/SteuerungsprototypenSoftware in keine besondere Hardware und lässt sie zusammen mit dem simulierten
Prozess auf dem gleichen PC laufen. Über die Einhaltung von Echtzeitbedingungen
wird keine Aussage gemacht.
/16/ ist der gleichen Auffassung, betont aber, dass Echtzeitfähigkeit nicht unbedingt
bestehen muss. Als spezifisches Merkmal des SIL-Ansatzes wird hier die Tatsache
verstanden, dass es sich bei dem Code des Regelungs-/Steuerungsprototypen nicht
um Simulationssoftware handelt (z.B. die Ausführung einer Simulink-Simulationsstruktur, die mit Simulink-Blöcken aufgebaut ist), sondern um Code (z.B. C-Code),
den man von Hand oder automatisch aus der Simulink-Struktur erzeugt und
anschließend in ausführbaren Code compiliert hat.
/16/ erweitert die Begriffsbildungen HIL und SIL um zwei zusätzliche "in the Loop"1.57
Phrasen:
• Beim "Model in the Loop" (MIL) liegen der Regelungs-/Steuerungsalgorithmus
und der Prozess als Simulationsmodelle vor und laufen auf dem gleichen
Rechner, beispielsweise einem PC. Das Task-Management, die Festkommaarithmetik, die I/O-Schnittstellen usw. werden weitgehend mit simuliert. Da alles
auf dem gleichen Rechner läuft, muss er nicht in Echtzeit arbeiten.
• Die "Prozessor in the Loop" -Simulation (PIL) ist der SIL-Methode sehr ähnlich.
Der Steuer-/Regelalgorithmus läuft allerdings auf einer der späteren Zielhardware
nahen Hardware, z.B. einem Evaluierungsboard mit dem späteren Zielcontroller.
Der Prozess wird wiederum simuliert, überwiegend in Echtzeit.
Der Autor des vorliegenden Skripts hält die beiden Definitionen von /17/ im
Kombination mit den in Kapitel 1.2.1 eingeführten Prototypenbezeichnungen für am
sinnvollsten:
Die Bezeichnung "Software in the Loop" (SIL) bedeutet den Einsatz von
konzept-, architektur- und implementierungsorientierten Steuerungs/Regelungsprototypen am realen Prozess.
"Hardware in the Loop" dagegen den Einsatz dieser Prototypen am
simulierten, aber in Echtzeit laufenden Prozess.
1.58
2
Fachliches Umfeld
Dieses Kapitel wurde im Rahmen der aktuellen Lehrveranstaltung bereits zu Beginn des
Semesters durchgearbeitet. Es wurde darauf hingewiesen, dass zur Bearbeitung des
Kapitels 4 "Praktisches Rapid Control Prototyping" Kenntnisse auf folgenden Gebieten
notwendig sind:
2.1
Systemtheorie
Die Systemtheorie legt die Grundlagen für sämtliche Wissensgebiete des fachlichen
Umfelds des RCP (Systemmodellierung / Systemidentifikation, Regelungstechnik und
die Simulation dynamischer Systeme). Es wird deshalb dringend empfohlen, bei
fehlendem oder nur bruchstückhaftem Wissen aus diesem Gebiet das Skript
"Grundlagen der Systemtheorie" /2/ vollständig durchzuarbeiten.
Auf Seite 122 von /2/ befindet sich eine Übersicht, mit der man sich bei
systemtheoretischen Fragen orientieren kann, wo man im Skript nachschlagen muss.
Das
Kapitel
“Eine
Übersicht
über
die
Beschreibungsformen
der
wichtigsten
Übertragungsglieder“ (/2/ Seite 133) schließt die Betrachtungen über die Systemtheorie
kontinuierlicher SISO-LTI-Systeme ab. Es zeigt in Form eines Katalogs einige wichtige
Modellierungsformen (Übertragungsfunktion, Sprungantwort, Bodediagramm, usw.)
wichtiger einfacher Übertragungsglieder. Auch ein Bezug zu realen Systemen, die das
beschriebene
Übertragungsverhalten
aufweisen,
wird
hergestellt.
Der
Katalog
unterstützt damit anschaulich das Kapitel 1.2.4 über “Praktische Bezüge zwischen
Übertragungsfunktion und Übertragungssystem“. Darüber hinaus werden den einzelnen
Übertragungssystemen systemtheoretische Namen und Kurzbezeichnungen (z.B.
Integralglied mit Verzögerung 1. Ordnung, IT1-Glied) zugewiesen. Auch auf die
Möglichkeit, den Katalog zur experimentellen Modellbildung nutzen zu können, soll mit
Nachdruck hingewiesen werden. Damit wird eine grundlegende Alternative zur
schwierigen mathematisch-/physikalischen Modellbildung aufgezeigt.
Während das Kapitel 1 von /2/ der Theorie kontinuierlicher SISO-LTI-Systeme gewidmet
war, geht das Kapitel 2 auf mathematische Modelle zeitdiskreter Systeme ein. Die
zeitdiskreten Systeme werden dort auch im Zeit-, Bild- und Frequenzbereich modelliert,
2.1
allerdings nicht in der Modellvielfalt, wie bei kontinuierlichen Systemen.
Um gemischte kontinuierliche und zeitdiskrete Systeme modellieren und um aus
kontinuierlichen Systembeschreibungen (z.B. eines kontinuierlichen PI-Reglers) digitale
Algorithmen entwickeln zu können, die in einem Digitalrechner implementierbar sind,
werden darüber hinaus sogenannte Diskretisierungstransformationen eingeführt.
An einem praktischen Beispiel, dem Entwurf eines digitalen Filters, wird die praktische
Anwendbarkeit der kontinuierlichen und zeitdiskreten Systemtheorie gezeigt.
2.2
Systemmodellierung / Systemidentifikation
Um sinnvoll Regelungstechnik betreiben zu können, muss von dem regelnden System
ein mathematisches Modell vorliegen. Die Systemmodellierung / Systemidentifikation
beschäftigt
sich
mit
dieser
Problematik.
Ein
grundlegender
Einblick
in
die
Systemmodellierung, d.h. in die theoretische Modellbildung wird in /2/, Kapitel 1.2.1,
gegeben. Man erkennt, dass diese Methode für praktische Alltagsprobleme nicht
anwendbar ist.
Im Skript "Praktische Verfahren zur experimentellen Systemidentifikation" /5/ wird
deshalb ausführlich auf die messtechnische Identifikation dynamischer System
eingegangen. In Kapitel 5.3.2 "Bestimmung der Parameter der Übertragungsfunktion
mittels einer Optimierungsstrategie" wird ein Verfahren beschrieben, welches auch unter
praktischen Gesichtspunkten zu sehr guten Identifikationsergebnissen führt.
Zum Verständnis dieses Verfahrens sollten die Kapitel 1 "Was ist Systemidentifikation",
Kapitel 2 " Einflußgrößen bei der Systemidentifikation" und Kapitel 5.1 "Vorbereitende
Betrachtungen"
durchgearbeitet
werden.
Das
Kapitel
5.2.1
"Kataloggestützte
Systemidentifikation" gibt Einblicke in den Zusammenhang zwischen der Struktur der
systembeschreibenden Übertragungsfunktion (also dem Systemmodel) und der Form
der Sprungantwort des zu identifizierenden Systems. Diese Kenntnis wird benötigt,
wenn man das in Kapitel 5.3.2 beschriebene Identifikationsverfahren sinnvoll praktisch
nutzen will. Das eigentliche messtechnische Verfahren wird in Kapitel 5.3.2 beschrieben.
Eine quasi "Bedienungsanleitung" findet man in Kapitel 5.3.2.7 "SYS_ID: Ein Werkzeug
zur praktischen Systemidentifikation".
2.2
2.3
Regelungstechnik
Die zentrale Aufgabe der Regelungstechnik ist der Entwurf eines Reglers, der nach
vorzugebenden Kriterien eine Regelstrecke beeinflusst. Dieser Optimierungsvorgang
wird in Kapitel 2.3 "Optimierung von Regelkreisen " von /3/ beschrieben. Fast alle
Beispielregelkreise bei den Laborübungen lassen sich mit Hilfe des relativ einfach
anzuwendenden "Verfahrens der Polkompensation" (Kapitel 2.3.2.2 von /3/) optimieren.
Hier sollten insbesondere die "wichtigen Ergänzungen zur Polkompensation" auf Seite
2.99 berücksichtigt werden, da es sich bei den Regelstrecken im Labor für Regelungstechnik häufig um Strecken niedriger Ordnung handelt.
Zur Untersuchung der Struktureigenschaften des optimierten Regelkreises (Führungs-,
Störungs- und Stellverhalten) können die Verfahren des Kapitels 2.2 "Struktureigenschaften von Regelkreisen" herangezogen werden. Mit einer Simulink-Struktur
lässt sich dieses Verhalten allerdings mit wesentlich geringerem Aufwand studieren.
Zum Entwurf eines zeitdiskreten Reglers reicht im Rahmen der Laborübungen "der
quasikontinuierliche Reglerentwurf", wie er in Kapitel 3.3.1 beschrieben wird, völlig aus.
Grundlegende Zusammenhänge der Regelungstechnik können anschaulich im Kapitel 1
"Aufbau und prinzipielle Wirkungsweise von Regelkreisen" und theoretisch untermauert
in Kapitel 2.1.4 "Der Regler mit Vergleichseinrichtung" und in Kapitel 2.3.1 "Das
Entwurfsprinzip des dominierenden Polpaares" nachgelesen werden.
2.4
Simulation dynamischer Systeme
Da wir die Arbeitsumgebung Matlab/Simulink zur Erzeugung von Prototypen benutzen,
ziehen wir dieses CAE-Programm natürlich auch zur Simulation und für andere
numerische Berechnungen heran. Im Skript "Einführung in das CAE-Programm
Matlab/Simulink (Version 5.3)" /4/ wird diese Thematik behandelt. Nach einer kurzen
Einführung in Kapitel 1, werden in Kapitel 2 "Grundlagen von Matlab" die allgemeinen
Fähigkeiten von Matlab als Computeralgebra-Programm beschrieben (nutzbare
Datenstrukturen, mathematische Funktionen, die in Ihrer Leistungsfähigkeit i.A. weit
über die anderer Hochsprachen hinausgehen, Programmlaufkontrolle, Unterprogramme,
Benutzerkommunikation und Elemente der integrierten Entwicklungsumgebung). Das
2.3
Kapitel weist insbesondere darauf hin, dass Matlabvariable Zahlenfelder sind und diese
mathematisch im Sinne der Matrizenrechnung oder elementweise, das ist eine
Besonderheit von Matlab, arithmetisch verknüpft werden können. Wegen der
Möglichkeit der elementweisen Verknüpfung von Zahlenfeldern können mit Matlab forSchleifen-freie Programme geschrieben werden.
Im dritten Kapitel werden "Matlabfunktionen für die System- und Regelungstechnik
beschrieben". Es werden für alle im Skript "Grundlagen der Systemtheorie" eingeführten
Berechungs- und Umrechnungsverfahren (z.B. Berechnung einer Sprungantwort,
Umrechnung eines Zustandsmodells in eine Übertragungsfunktion oder Umrechnung
der Polynomform der Übertragungsfunktion in die faktorisierte V-Normalform) die
numerischen Äquivalente angegeben und das sowohl für kontinuierliche als auch
zeitdiskrete Systeme. Auch die Umrechnung kontinuierlicher Systeme in zeitdiskrete
werden
die
entsprechenden
Befehle
vorgestellt.
Nach
einem
ausführlichen
Programmbeispiel, wo alle vorangehend besprochenen Befehle zum Einsatz kommen,
werden noch einige spezielle regelungstechnische Befehle (z.B. zur Berechnung einer
Wurzelortskurve) angesprochen.
Das vierte Kapitel setzt sich mit Simulink, einem grafikgestützten Simulationsprogramm
auseinander. In diesem Kapitel wird zunächst in die Arbeitsumgebung eingeführt: Aufruf
von Simulink, Öffnen eines Simulink-Arbeitsfensters, Grundzüge der Erstellung
von
Simulink-Simulationsstrukturen und Parametrierung von Signal-Anzeige-Elementen
(Scopes). Anschließend werden die wichtigsten Inhalte der Menueleisten des SimulinkArbeitsfensters (File-, Edit-, View-, Simulation-, Format- und Tools-Menue) besprochen.
Dabei wird intensiv auf das "Simulation-Menue" und den darin auftretenden Menuepunkt
"Parameters..." eingegangen. Hinter diesem wichtigem Menuepunkt verbirgt sich die
Parametrierung
des
Integrationsalgorithmus
für
die
Simulation
dynamischer
Systemanteile (also die numerische Berechnung von Differentialgleichungen).
Nach
der
Besprechung
Simulationselemente
(z.B.
der
einzelnen
Menuepunkte
Übertragungsfunktions-,
wird
intensiv
Zustandsmodell-,
auf
die
Integrator-,
Verstärker-Blöcke) der "Simulink Block Library" eingegangen, mit deren Hilfe die
Simulationsstrukturen aufgebaut werden. Das abschließende Kapitel beschäftigt sich mit
dem Übergang von Simulink nach Matlab und umgekehrt. Beim Übergang von Simulink
nach Matlab ist insbesondere der Befehl "linmod" von Wichtigkeit, weil mit Ihm Simulink2.4
Strukturen in Form von Zustandsmodellen nach Matlab transferiert werden können, um
dort weiter verarbeitet zu werden, z.B. durch Berechnung des Bodediagramms der
Simulink-Struktur. Auch nichtlineare Simulink-Strukturen lassen sich mit "linmod" nach
einer automatischen Linearisierung in einem angebbaren Arbeitspunkt in eine
Zustandsmodell wandeln. Der Übergang von Matlab nach Simulink ermöglicht die
Parametrierung von Simulink-Blöcken aus einem Matlabprogramm heraus. Dies ist
immer dann sinnvoll, wenn eine Reihe von Versuchen vorgenommen werden sollen, um
z.B.
eine
bestmögliche
Parametrierung
experimentell
durchzuführen,
z.B.
die
Bestimmung der optimalen Abtastzeit bei einem zeitdiskreten Regler aus seinem
kontinuierlichen Vorbild: Zu diesem Zwecke würde man eine Simulink-Struktur
entwerfen, bei der der Regelkreis einmal mit dem optimalen kontinuierlichen Regler und
einmal mit einem zeitdiskreten Regler realisiert wird. Die Regelgrößen und die
Stellgrößen werden jeweils gemeinsam auf einem Scope dargestellt. Die Koeffizienten
der zeitdiskreten Regler-Übertragungsfunktion und die aktuelle Abtastzeit werden von
einem Matlabprogramm aus den optimalen Koeffizienten des kontinuierlichen Reglers
berechnet und an die Simulink-Struktur, d.h. an den zeitdiskreten
Übertragungs-
funktionsblock übergeben, dann ruft das Matlabprogramm die Simulink-Struktur auf und
man kann sie simulieren. Durch Änderung der Abtastzeit und Neuberechnung der
Parameter des zeitdiskreten Reglers im Matlab-Programm kann man so ohne großen
Aufwand die Veränderung der Regelgüte des zeitdiskreten Regelkreises im Vergleich
zum kontinuierlichen Regelkreis studieren.
2.5
3
Die Arbeitsumgebung Matlab/ Simulink
Die nächsten Kapitel 3.1 "Ein Werkzeug zur Systemidentifikation", 3.2 " Ein
Werkzeug zum Reglerentwurf" und 3.3 "Ein Werkzeug zur Systemsimulation" lagen
im aktuellen Semester noch nicht als Skript vor und wurden deshalb an Hand des
folgenden Beispiels zur Lösung einer regelungstechnischen Problemstelllung
mündlich erläutert.
Das
Unterkapitel
3.3.1
"Einbindung
von
Festkommaarithmetik"
wird
nicht
vorgetragen, weil das aktuell verfügbare Real-Time Windows Target Festkommaarithmetik nicht unterstützt.
Beispiels zur Lösung einer regelungstechnischen Problemstelllung
Ein Walzenmotor einer Blechwalzstraße, der mit einer Arbeitspunktdrehzahl von
120 U/min betrieben wird, treibt ein Walzenpaar an, welches Walzgut (sogenannte
Brammen) einzieht, dünner walzt und wieder auswirft. (Normalerweise wird eine
solche Walze repetierend in zwei Walzrichtungen betrieben, was zur Vereinfachung
der Aufgabe hier nicht der Fall sein soll.)
Beim Eingriff der Bramme in das Walzenpaar sinkt wegen der Belastung die
Arbeitspunktdrehzahl, solange sich das Walzgut im Eingriff befindet (Nennlast). Nach
Abwurf des Walzgutes erhöht sich die Drehzahl wieder, um nach einer gewissen Zeit
wieder die Arbeitspunktdrehzahl zu erreichen. Der lineare Aussteuerbereich der
Stelleinrichtung beträgt ± 10 V.
Der Walzenmotor soll in einen Regelkreis eingefügt werden, der dafür sorgt, dass bei
den oben genannten Belastungen die Arbeitspunktdrehzahl zumindest stationär (d.h.
nach einer gewissen Zeit nach der Belastungsänderung) wieder erreicht wird.
Um einen solchen Regelkreis entwerfen zu können, wurden zur Identifikation des
Übertragungsverhalten von Regelstrecke und Messeinrichtung bei der in Bild 1
dargestellten Geräteanordnung
3.1
u(t)
V
Walzen −
Motor
Stell−
einrichtung
uA (t)
V
un (t)
V
Drehzahl −
Messeinrichtung
n(t)
U / min
u(t): spätere Stellgröße, uA(t): Ankerspannung des Motors, n(t): Drehzahl der
Rotorwelle des Motors, un(t): Ausgangsspannung der
Drehzahlmesseinrichtung.
Bild 1: Der Walzenmotor mit Stell- und Messeinrichtung
zunächst die folgende statische Kennlinie gemessen, auf der basierend die
Messungen zur Identifikation ihres dynamischen Verhaltens durchgeführt wurden:
12
un
V
10
8
6
4
2
0
0
2
4
6
8
u
V
10
Bild 2: Statische Kennlinie der Anordnung Stelleinrichtung, Walzenmotor und
Messeinrichtung nach Bild 1 im Leerlauf
3.2
Anschließend wurde bei folgender Erregung
6
u(t)
V
4
2
0
5
0
10
15
20
t
sek
20
t
sek
Bild 3: Erregungssignal der Geräteanordnung von Bild 1
folgende Systemantwort an der Messeinrichtung gemessen:
8
un (t)
V 6
4
2
0
-2
5
0
15
10
Bild 4: Systemantwort der Geräteanordnung von Bild 1 bei Erregung
mit dem Signal von Bild 3
Weiterhin ist bekannt, dass die eingesetzte Messeinrichtung, ein sogenannter
Tachogenerator, eine Drehzahl von 0 - 200 U/min linear auf 0 - 10V abbildet und bei
folgendem rampenförmigen Drehzahlanstieg
10
n(t)
U / min
5
0
0
0.2
22
0.4
0.6
0.8
t
1.0 sek
Bild 5: Erregung der Messeinrichtung mit einer rampenförmigen Drehzahländerung
3.3
mit folgendem Spannungsverlauf am Ausgang antwortet:
0.6
un (t)
V 0.5
0.4
0.3
0.2
0.1
0
0
0.4
0.2
0.6
0.8
1.0
t
sek
Bild 6: Systemantwort der Messeinrichtung bei einer Erregung nach Bild 5
a) Identifizieren Sie die Übertragungsfunktion der Anordnung Stelleinrichtung,
Walzenmotor und Drehzahlmesseinrichtung (Bild 1) mit Hilfe der in Bild 3 und
Bild 4 angegebenen Ein- und Ausgangssignale. Die entsprechenden Messwerte
finden sie unter dem Namen "Datensätze zur 3. Hausaufgabe" auf der WEB-Seite
zum
Modul
Regelungstechnik
(http://prof.tfh-berlin.de/ottens).
Der
Ordner
"Daten_Strecke" enthält die Vektoren
t:
Zeitachse der folgenden Vektoren,
uerr:
Erregungssignal nach Bild 3,
ySystem:
Systemantwort nach Bild 4.
b) Identifizieren Sie die Übertragungsfunktion der Messeinrichtung mit Hilfe der in
Bild 5 und Bild 6 angegebenen Ein- und Ausgangssignale. Die entsprechenden
Messwerte finden sie auch unter dem Namen "Datensätze zur 3. Hausaufgabe"
auf
der
WEB-Seite
zum
Modul
Regelungstechnik.
"Daten_Messeinrichtung" enthält folgende Vektoren:
t:
Zeitachse der folgenden Vektoren,
uerr:
Erregungssignal nach Bild 5,
ySystem:
Systemantwort nach Bild 6.
3.4
Der
Ordner
c) Werten Sie die identifizierten Übertragungsfunktionen so aus, dass Sie die
Übertragungsfunktion der Strecke (mit Stelleinrichtung)
N(s)
U(s)
und der Messeinrichtung
GS (s) =
GM (s) =
Un (s)
N(s)
in V-Normalform hinschreiben können.
d) Entwerfen Sie einen kontinuierlichen Regler, der mit den restlichen Baugliedern
zu einem Standard-Regelkreis verknüpft, folgende Regelungsziele erreicht:
-
keine bleibende Regelabweichung,
-
möglichst geringe Anstiegszeit tr der Führungssprungantwort unter
Ausschöpfung des gesamten Stellbereichs aber ohne Übersteuerung der
Stellgröße.
Beginnen Sie mit den Optimierungsvorgang, in dem Sie mittels Polkompensation
zunächst eine Überschwingweite Mp = 0,2 einstellen.
e) Erproben Sie den entworfenen Regler in einer Simulink-Simulation des gesamtem
Regelkreises. Simulieren Sie dabei auch die Wirkung der Belastung und
Entlastung durch den Eingriff bzw. den Abwurf von Walzgut und zwar so, dass
sich die ungeregelte Drehzahl bei Lasteingriff um maximal -50 U/min von ihrer
Arbeitspunktdrehzahl
entfernt
und
sich
nach
Lastabwurf
wieder
die
Arbeitspunktdrehzahl einstellt. Jedem Lasteingriff muß ein Lastabwurf folgen.
Betrachten Sie den "worst-case"-Fall, d.h. sprungförmige Laständerungen.
Wählen Sie zunächst auch eine sprungförmige Führungsgröße mit einer
Amplitude, die stationär die Arbeitspunktdrehzahl von 120 U/min einstellt.
f) Überprüfen Sie die Stellgröße des Regelkreises und optimieren Sie bei Bedarf
den Regler experimentell nach. Bedenken Sie, dass der Regelkreis primär
Störungen ausregeln soll, das heißt, die Führungsgröße w(t) bleibt während des
3.5
Betriebs längere Zeit (Tage) konstant. Nur nach Wartungs- und Reparaturarbeiten
wird der Kreis wieder in seinen Arbeitspunkt gefahren. Dies hat Konsequenzen
hinsichtlich der Auslegung des Regelkreises.
g) Entwerfen Sie einen quasikontinuierlichen, zeitdiskreten Regler dessen Abtastzeit
so groß wie möglich gewählt werden soll, wobei sich aber die dynamischen
Eigenschaften des Regelkreises gegenüber der optimalen kontinuierlichen
Realisierung nicht wesentlich verschlechtern sollen. (Diese Forderung ist eine
wichtige Randbedingung für den Echtzeitbetrieb des Reglers, es wird damit
nämlich die notwendige Rechenzeit für die Regelalgorithmen geschaffen).
Demonstrieren Sie die Leistungsfähigkeit des zeitdiskreten Reglers, indem Sie die
Regelergebnisse (Verlauf der Regel- und Stellgröße) des kontinuierlichen
Regelkreises und die des zeitdiskreten Regelkreises in jeweils einem Scope
darstellen.
Lösung der regelungstechnischen Problemstellung
a) Die Identifikation der Reihenschaltung Stelleinrichtung, Strecke und
Messeinrichtung (nach Bild 1) führt auf folgende Übertragungsfunktion (dabei
wird die Reihenschaltung Stelleinrichtung und Strecke vereinbarungsgemäß als
Einheit aufgefasst und "Strecke" genannt):
V
1,8164  
V
GSM (s) =
.
(1 + 0,427 [sek.] s ) (1 + 1,0423 [sek.] s )
b) Die Identifikation der Messeinrichtung führt auf folgende Übertragungs-
funktion:
 V 
0,05 
(1 + 0,12 [sek.] s )
U / min 

GM (s) =
.
1 + 0,08 [ sek.] s
3.6
c) Berechnung der Streckenübertragungsfunktion:
GSM (s) = GS (s) ⋅ GM (s)
GS (s) =
⇒
V
1,8164   (1 + 0,08 [ sek.] s )
v
GSM (s)
=
GM (s)
 V 
0,05 
(1 + 0,12 [sek.] s ) (1 + 0,427 [sek.] s ) (1+ 1,0423 [sek.] s )
 U / min 
 U / min 
36,33 
(1 + 0,08 [sek.] s )
V 

=
(1 + 0,12 [sek.] s ) (1 + 0,427 [sek.] s ) (1+ 1,0423 [sek.] s )
d) Entwurf eines Reglers mittels Polkompensation
Das Programm "go_bodedigramm.m" ruft die Simulink-Struktur "bodediagramm.mdl" auf.
experimentell
Es wird die größte Zeitkonstante kompensiert und
mittels
des
Verstärkungsfaktors
V
des
PI-Reglers
eine
Überschwingweite von 0,2 eingestellt (V=1,55):
% Programm go_bodediagramm, ruft die Simulink-Struktur
% bodediagramm.mdl auf.
% Beide Programme dienen zum Reglerentwurf.
[A,b,c,d]=linmod('bodediagramm');
sys=ss(A,b,c,d);
figure(1)
margin (sys)
grid on
1
In1
1.55*[1.042 1]
36.3
0.08s+1
1
0.05*[0.12 1]
s
0.43s+1
1.042s+1
0.12s+1
0.08s+1
PI-Regler
Strecke 1
Strecke 2
Strecke 3
Messeinrichtung
V=1.55 führt auf Phi_r = 48 Grad
Simulink-Struktur "bodediagramm.mdl"
3.7
1
Out1
Bode Diagrams
Gm = Inf, Pm=48.031 deg. (at 2.0917 rad/sec)
50
Phase (deg); Magnitude (dB)
0
-50
-100
-80
-100
-120
-140
-160
-180
10-2
10-1
100
101
102
Frequency (rad/sec)
Sich ergebendes Bodediagramm
Alternativer Reglerentwurf mittels "polkomp.m"
Zur
Reglerbestimmung
mittels
polkomp.m
wird
die
Polynomform
der
Übertragungsfunktion von Strecke und Messeinrichtung benötigt. Mit dem folgenden
Programm
"Polynomform_von_Gs_und_GM.m"
werden
die
Polynomformen
berechnet:
% Berechnung der Polynomform der Strecke und Messeinrichtung
% zum Reglerentwurf mittels "polkomp.m"
% Strecke in Polynomform
zS = 36.33*[0.08, 1];
n1S = [0.12, 1];
n2S =[0.427, 1];
nS= conv(n1S, n2S);
n3S = [1.0423, 1];
nS = conv(nS, n3S);
disp('Polynomform der Übertragungsfunktion der Strecke')
Strecke=tf(zS, nS)
% Messeinrichtung in Polynomform
3.8
zM =0.05*[0.12, 1];
nM = [0.08, 1];
disp('Polynomform der Übertragungsfunktion der
Messeinrichtung')
Messeinrichtung=tf(zM, nM)
Ergebnis:
Polynomform der Übertragungsfunktion der Strecke
Transfer function:
2.906 s + 36.33
-------------------------------------0.05341 s^3 + 0.6214 s^2 + 1.589 s + 1
Polynomform der Übertragungsfunktion der Messeinrichtung
Transfer function:
0.006 s + 0.05
-------------0.08 s + 1
Der Entwurf führt auf eine fast identische Übertragungsfunktion des Reglers:
GR (s) =
1,55 ⋅ (1 + 1,041s)
.
s
Das Bild auf dem nächsten Blatt zeigt die entworfene Simulationsstruktur zum Test
des entworfenen Reglers. V=1,55 führt auf einen Phasenrand von 48°.
Durch Nachoptimierung von V auf V = 1,7 wird die Ausregelung der Störung, die viel
häufiger auftritt als eine Führungsgrößenänderung, optimiert. Da dann bei Führung
eine kleine Übersteuerung der Stellgröße auftritt, wird ein Führungsgrößenvorfilter
eingefügt, was keine wesentliche Verlangsamung des Führungsverhaltens bedeutet.
Siehe dazu die folgenden Regel- und Führungsgrößenverläufe am Anschluss an das
Strukturbild:
3.9
V=1.55 führt auf Phi_r = 48 Grad
V=1.7 ist nachoptimiert auf optimale Störungsausregelung
(inklusive des Vorfilters)
Step
1.55*[1.042 1]
36.3
0.08s+1
1
s
0.43s+1
1.042s+1
0.12s+1
PI-Regler3
Strecke 1
Strecke 2
Strecke 3
1
1.7*[1.042 1]
0.15s+1
s
Strecke 5
Entlastung
Regelgrösse
Belastung
PI-Regler4
Stellgrösse
0.05*[0.12 1]
0.08s+1
Messeinrichtung
Simulationsstruktur zum Test des entworfenen Reglers
3.10
Regel- und Stellgröße bei V=1, 55 (Mp = 0,2).
Es bleibt ein gewisser Stellgrößenspielraum. Wenn man diesen mit V = 1,7
ausschöpft (Lastpeak auf 10V), wird die Stellgröße bei Führung überschritten.
Dies kann man mit einem Führungsgrößenvorfilter kompensieren. Dieses wurde auf
dem vorangehenden Strukturbild bereits darstellt, aber noch nicht angeschlossen.
Man erkennt auf dem folgenden Grafen der Stellgröße, das dann die weder die
Stellgröße bei Störung noch die Stellgröße bei Führung übersteuert wird.
3.11
g) Entwurf eines quasikontinuierlichen zeitdiskreten Reglers
Es wird die Simulink-Struktur "Vergleich_kont_diskret.mdl" entworfen (siehe nächstes
Blatt). Sie enthält den kontinuierlichen Regelkreis aus Aufgabenteil f), darunter wird
der
gleiche
Kreis
allerdings
mit
einem
zeitdiskreten
Regler
(Discrete
Transferfunction) realisiert.
Der Discrete Transferfunction - Block wird nicht mit Zahlenwerten für Zähler, Nenner
und Abtastzeit parametriert, sonder mit drei Variablennamen (zd, nd und T).
3.12
1
0.15s+1
Führungsgrößee
Vorfilter
1.7*[1.042 1]
36.3
0.08s+1
1
s
0.43s+1
1.042s+1
0.12s+1
Kontinuierlicher
PI-Regler
Strecke 1
Strecke 2
Strecke 3
Entlastung
Regelgröße
Belastung
0.05*[0.12 1]
Stellgröße
0.08s+1
Messeinrichtung
zd(z)
36.3
0.08s+1
1
nd(z)
0.43s+1
1.042s+1
0.12s+1
Diskreter
PI-Regler
Strecke 5
Strecke 6
Strecke 7
0.05*[0.12 1]
0.08s+1
Messeinrichtung1
Simulinkstruktur "Vergleich_kont_diskret.mdl" zur Lösung der Aufgabenstellung g)
3.13
Die Werte der Variablen werden
Vergleich_kont_diskret.m" parametriert:
mit
dem
Matlabprogramm
"go_
% Programm go_Vergleich_kont_diskret.m ruft die gleichnamige
% simulink-Strunktur auf und berechnet und parametriert den
% zeitdiskreten Regler.
clear
home
close all
% Öffnen der Simulink-Struktur
Vergleich_kont_diskret
% kontinuierlicher Regler
z=1.7*[1.042 1];
n=[1 0];
sys_kont=tf(z,n);
% diskreter Regler
T=0.01;
sys_diskret=c2d(sys_kont,T,'tustin');
[zd,nd]=tfdata(sys_diskret);
zd=zd{1,1};
nd=nd{1,1};
Regelgrößenverlauf bei einer Abtastzeit von T=1sek. (im Vergleich zur kontinuierlichen Realisierung
3.14
Dazugehöriger Stellgrößenverlauf bei einer Abtastzeit von T=1sek. (im Vergleich zur
kontinuierlichen Realisierung)
Regelgrößenverlauf bei einer Abtastzeit von T=0,1sek. (im Vergleich zur
3.15
Regel- und Stellgrößenverlauf bei einer Abtastzeit von T=0,1sek. (im Vergleich zur
Bei T=1sek. weichen die dynamischen Eigenschaften des Kreises stark von der
kontinuierlichen Realisierung ab. Bei T=0.1sek. sind die Eigenschaften sehr ähnlich.
Allerdings ist die freie Rechenzeit zur Berechnung des Regelalgorithmus wesentlich
kleiner.
3.16
3.4
Das Real-Time Windows Target als Werkzeug zum konzeptorientierten
Dieses Kapitel vertieft den Überblick des Kapitels 1.2.3 "Mit Matlab von der
Systemspezifikation zum Objektcode" so weit, dass man mit dem Real-Time
Windows Target praktisch arbeiten und konzeptorientierte Prototypen erzeugen
kann.
Alle Beschreibungen beziehen sich auf die im Labor verfügbare Matlabversion
R11.1, wie sie im Anhang A1 beschrieben ist.
3.4.1 Einleitung
Die folgenden Erläuterungen fassen ca. 900 Seiten des Real-Time Workshops User's
Guide und 200 Seiten das Real-Time Windows Target User's Guide auf ca. 25 Seiten
zusammen. Das Kapitel kann also nicht den Anspruch auf Vollständigkeit, erheben,
noch beschreibt es die Arbeitsweise der Real-Time Workshop / Real-Time Windows
Targets annähend erschöpfend. Die dargestellten Vorgehensweisen und Leistungen
des Real-Time Workshop / Real-Time Windows Targets reichen zur Lösung der
Laborübungen jedoch aus und versetzen den Leser in die Lage, sich tiefer in die
Arbeitsweise dieser Software einzuarbeiten.
Für nähere Einzelheiten wird auf die Handbücher /8/ und /9/ verwiesen, die im
Rahmen der Laborübungen eingesehen werden können. In ihnen können z.B.
nachgelesen werden:
•
Vorgehensschritte zur Installation des Systems
•
Alternative Vorgehensweisen zu den beschriebenen Arbeitsschritten
•
Methoden zum Online-Tuning von Simulationsparametern
•
Echtzeit-Simulation von Systemen mit verschiedenen Abtastzeiten
Da auch diese Handbücher nicht vollständig widerspruchsfrei sind, hilft manchmal
nur Probieren weiter. Halten Sie sich jedoch an die Empfehlungen des folgenden
Kapitels 3.4.2 .
3.17
3.4.2. Vorbemerkungen zum Betrieb des Real-Time Workshops / Real-Time
Windows Target
In
diesem
Kapitel
sind
einige
Empfehlungen
zusammengestellt,
die
auf
Erkenntnissen gegründet sind, die während der Nutzung des Real-Time Workshops
/ Real-Time Windows Targets bei Laborübungen in den letzten Semestern
gesammelt wurden.
•
Benutzen Sie zum Entwurf Ihrer eigenen Echtzeitanwendungen möglichst immer
das Ihnen zur Verfügung gestellte Mustermodell
"reinraus.mdl" bzw. "reinraus_dash.mdl"
Damit stellen Sie sicher, das alle Grundeinstellungen richtig vorgenommen
wurden. Damit lassen sich eventuell auftretende Fehler beim Build-Prozess
leichter eingrenzen. (Sie finden dieses Mustermodell neben anderen nützlichen
Programmen auf den "Echtzeit-PCs" im Labor. Fragen Sie den Dozenten ggf.
nach dem Speicherort.)
•
Nehmen Sie nach jedem Einschalten Ihres / Ihrer Arbeits-PCs einen OffsetAbgleich der A/D-D/A-Wandlerkarte pci6025E vor, wie er im Kapitel 3.4.4
beschrieben ist. Das Unterlassen des Abgleichs kann zu erheblichen Messfehlern
führen.
•
In einer Simulink-Struktur, die als Echtzeitanwendung laufen soll, muss sich
immer ein Scope befinden. Sonst wird der Compilierungsvorgang mit einer
sinnlosen Fehlermeldung abgebrochen.
•
Dateinamen von Simulink-Strukturen, die als Echtzeitanwendung laufen sollen,
dürfen nicht mehr als 8 Zeichen haben. Sonst wird der Compilierungsvorgang
auch mit einer sinnlosen Fehlermeldung abgebrochen.
•
Nehmen Sie notwendige Veränderungen an der Hardware (Rechner, Versuchsaufbau) nur bei abgeschalteter Netzspannung vor!
•
Wechseln Sie vor Beginn einer Matlab / Real-Time Workshop Sitzung immer in
das Unterverzeichnis "work" von Matlab R11 und von dort nach "RTII-Labor",
legen Sie sich hier Unterverzeichnisse an, mit denen Sie Ihre Arbeit strukturieren.
3.18
Stellen sie sicher, das Sie sich während eines Build-Prozesses in dem
Unterverzeichnis befinden, in dem sich auch die zu compilierende Modelldatei
befindet. Simulink legt sonst die beim Build-Prozess anfallenden Dateien (und das
sind nicht wenige) dort ab, wo sich gerade befinden. Die Folge ist eine völlig
unübersichtliche Datenhaltung.
•
Sichern Sie sich wichtige Programme auf Diskette, da ggf. auch andere
Studierende an den Rechnern des Labors arbeiten.
•
Benutzen Sie bei Echtzeitanwendungen keine Scopes mit mehreren Eigängen,
weil es sonst während des Echtzeitbetriebs zu Programmabbrüchen ohne
Fehlermeldung kommen kann. Es wird empfohlen, zur Signalvisualisierung im
Echtzeitbetrieb für jedes zu messende Signal ein Scope zu benutzen.
3.4.3 Bedienungsanleitung des Real-Time Workshop / Real-Time Windows
Targets
Für die folgenden Beschreibungen wird vorausgesetzt, dass folgende Software
Matlab
Version 5.3.1 (R11.1)
Simulink
Version 3.0.1 (R11.1)
Real-Time Workshop
Version 3.0.1 (R11.1)
Realtime-Windows-Target
Version 1.1 (R11.1)
Watcom C-Compiler
Version 11.0
und eine geeignete A/D-D/A-Wandlerkarte nach den Vorschriften des "Real-Time
Workshop User's Guide" /9/ und des "Real-Time Windows Target User's Guide" /8/
installiert wurden.
3.4.3.1
Prüfung der Installation des Echtzeitkerns
Nach dem Starten von Matlab (Doppelklick auf das Matlab-Icon) kann mit der
Eingabe des Strings
rtwho
in das Matlab Command Window geprüft werden, ob der Echtzeitkern des Real-Time
Workshops installiert wurde. Da die Installation vollständig ist, sollte Matlab wie folgt
3.19
antworten:
Real time windows Target version 1.00 ©
The MathWorks, Inc 1998
Matlab performance = 100%
Kernel timeslice period =1 ms
Nach der anschließenden Eingabe des Strings
simulink3 (CR)
in das Matlab-Command-Window, öffnet sich die "Simulink Block Library" mit dem
bekannten Angebot von Simulationsblock-Kategorien: Sources, Sinks, ... .
Durch die Auswahl folgender Menüfolge
File → New → Model öffnet sich das
Simulations-Arbeits-Fenster (SAF) von Simulink (siehe folgenden Ausschnitt),
in dem die zu realisierende Simulationsstruktur aufgebaut wird. Diese Simulationsstruktur trägt noch den Namen "untitled". Sie kann später nach den üblichen
Speichermethoden des Betriebssystems Windows mit einem frei wählbaren Namen
3.20
als Datei abgespeichert und auch wieder geladen werden. Es ist zu beachten, dass
die Namensergänzung einer Simulink-Datei "mdl" (von model) heißt.
3.4.3.2
Anpassung der "RT In"- und "RT Out"-Blöcke an die installierte A/DD/A-Wandler-Karte
Zur Arbeit mit dem Realtime Workshop werden noch weitere "Blocksets" benötigt. An
diese gelangt man durch Betätigung des Buttons "Blocksets & Toolboxes" im
"Simulink Block Library"-Fenster. Es öffnet sich ein weiteres Fenster mit dem Namen
"Library: Blocksets_and_Toolboxes".
Hier öffnen wir durch einen Doppelklick die Library "Real-Time Windows Target".
In der sich öffnenden "rtwinlib" befinden sich die schon im Kapitel 1.2.3 erwähnten
3.21
Ankopplungselemente an den A/D-Wandler ("RT In") und den D/A-Wandler ("RT
Out") und ein Block mit einer stilisierten PC-Einsteckkarte mit dem Namen "Adapter".
Wir ziehen, wie gewohnt, diese drei Blöcke in das SAF (siehe folgendes Bild). Durch
einen
Doppelklick
auf
den
Block
"Adapter"
öffnet
sich
eine
Liste
von
Hardwaretreibern ("Select a hardware driver") für die vom "Realtime-WindowsTarget" unterstützten A/D-D/A-Wandler-Karten.
Im Labor für Regelungstechnik werden zwei Karten-Typen eingesetzt:
•
•
das1602
pci6025e
(Firma Keithley) und
(Firma National Instruments).
Beide Karten besitzen 16 A/D-Wandler- (gemultiplext) und 2 D/A-Wandler-Kanäle mit
jeweils 12 Bit Amplitudenauflösung.
Wir wählen mittels eines Doppelklicks den für die im Rechner installierte Karte
gültigen Treiber aus. Welche Karte sich in den Labor-Rechnern befindet, können Sie
auf einer Beschriftung der Rechner ablesen. Mit dem Doppelklick öffnet sich ein
Parametrierungsfenster für die gewählte Karte (siehe nächstes Bild).
3.22
•
Bei der pci6025e-Karte aktivieren wir die beiden Felder
Single-ended A/D und
Unipolar D/A
und lassen alle anderen Einstellungen unverändert. Anschließend betätigen wir
den Button "Gains ..." und wählen durch Betätigung des Buttons "±10V >>" für
alle A/D-Wandler-Kanäle einen Aussteuerbereich von ±10V. Jeweils durch
Betätigung der "OK"-Buttons schließen wir dann die Parametrierungsfenster.
•
Bei der das1602-Karte verändern wir in dem sich zuerst öffnenden Fenster gar
nichts, sondern klicken gleich den Button "Gains ..." an.
Hier
wählen
wir
für
alle
A/D-Wandler-Kanäle
den
hier
abgefragten
Verstärkungsfaktor mit 1 (Button "1>>") und schließen, wie oben, beide Fenster
mit "OK".
Damit sind die "RT In"- und "RT Out"-Blöcke für die installierte A/D-D/A-WandlerKarte konfiguriert.
3.23
3.4.3.3 Realisierung einer Echtzeitanwendung
Die einfachste Anwendung des Real-Time Workshop / Real-Time Windows Targets
(allerdings zunächst ohne praktischen Nutzen) besteht aus dem Einlesen in und
sofortigem Ausgeben von Signalen aus der Echtzeitanwendung:
Im SAF muss dazu lediglich, wie bei Simulink üblich, eine Verbindungslinie zwischen
"RT In" und "RT Out" gezogen werden. Diese Anordnung im SAF ist im
vorangehenden Bild zu sehen. Wir realisieren diese Struktur an dieser Stelle noch
nicht, weil noch einige Randbedingungen einzuhalten sind, die wir im Folgenden
kennen lernen werden.
3.4.3.4 Hardware-Ankopplung
Zur hardwareseitigen Signal-An- und -Auskopplung steht für die das1602-Karte eine
Anschlußbox mit Bananen-Buchsen zur Verfügung, die vier A/D-Wandler-Eingänge
und zwei D/A-Wandler-Ausgänge zur Verfügung stellt. Die D/A-Wandlerkanäle
("Out") haben eine gemeinsame Masse ("Ground"), die A/D-Wandlerkanäle ("High
In") haben jeweils getrennte Massen ("Low In"). Die Box-Beschriftung ist weitgehend
selbsterklärend.
Die Signalankopplung für die pci6025e-Karte erfolgt über zwei Flachbandkabel mit
Schraubklemmen. Wir benötigen nur den Flachbandkabel-Anschluß für die PINs 1
bis 50 (siehe Beschriftung auf den Kabeln: "Position 1-50"). Die PINs haben folgende
Belegung:
3.24
A/D-Kanal 1
A/D-Kanal 2
A/D-Kanal 3
A/D-Kanal 4
...
Gemeinsame Masse
für alle A/D-Kanäle
D/A-Kanal 1
D/A-Kanal 2
Gemeindame Masse
für alle D/A-Kanäle
:
:
:
:
3
5
7
9
:
:
:
1 und 2
20
21
:
23
3.4.3.5 Parametrierung des Real-Time Workshop / Real-Time Windows Targets
Zur Ankopplung der Simulationsstruktur im SAF an den Real-Time Workshop / RealTime Windows Target und damit an die A/D-D/A-Wandler-Karte für den
Echtzeitbetrieb der Simulation sind eine Reihe von Einstellungen vorzunehmen:
1. Zunächst sollte zu Beginn einer Sitzung im Menü der SAF
Tools → RTW Options → Realtime Workshop
überprüft werden, ob folgende Eintragungen in den entsprechenden Feldern
stehen (Vergleiche Kapitel 1.2.3.1):
3.25
System target file :
Template makefile :
Make command
:
win_watc.tlc
win_watc.tmf
make_rtw.
Falls das "System target file" einen anderen Eintrag hat, muss es mittels des
Buttons "Browse..." entsprechend umbenannt werden.
An allen anderen Stellen wird keine Veränderung vorgenommen. Anschließend
wird das Fenster "Simulation Parameters" geschlossen.
2. Prüfung ob im Menue "Simulation" die Eigenschaft "External" aktiviert ist. Wenn
nicht, wird diese Einstellung vorgenommen.
3. Im dritten Schritt werden im Menü
Simulation → Parameters → Solver
im Abschnitt "Simulation time" die "Start time" der Simulation (i.a. 0.0) und die
"Stop time", die Simulationsdauer, beide in Sekunden eingegeben. Die zu
wählende "Stop time" hängt von der durchzuführenden Simulationsaufgabe ab.
Sie kann beliebig groß eingestellt werden.
Bei "Solver-Options" muss bei Nutzung des Real-Time Workshop / Real-Time
Windows Targets in der Rubrik "Type" grundsätzlich "Fixed-step" gewählt werden.
Abhängig davon, ob das im Real-Time Workshop / Real-Time Windows Target zu
betreibende System kontinuierlich (Simulationsblöcke aus der „Continous“Blocklibrary) oder zeitdiskret (Simulationsblöcke aus der „Diskret“- Blocklibrary)
realisiert ist, muss (wie bei einer normalen Simulation) im kontinuierlichen Fall ein
3.26
Integrationsalgorithmus („odex“, x steht für eine Zahl zwischen 1 und 5) und im
zeitdiskreten Fall „discret ( no continous states)“ gewählt werden. Es wird
empfohlen, für kontinuierliche Simulationen den Integrationsalgorithmus „ ode4
(Runge-Kutta)“ zu wählen. Dieser Algorithmus ist ein guter Kompromiß zwischen
Rechengenauigkeit und –geschwindigkeit.
Grundsätzlich sollte jedoch immer
überlegt
werden,
ob
überhaupt
mit
kontinuierlichen Simulationen gearbeitet werden soll. Integrationsalgorithmen sind
relativ rechenintensiv, so dass nicht mit sehr hohen Abtastzeiten gearbeitet
werden kann. Die Alternative mit der höchsten Rechengeschwindigkeit besteht
darin, ausschließlich mit zeitdiskreten Simulatiosblöcken zu arbeiten. Dazu
müssen
aber
vorliegende
kontinuierliche
Systeme
zunächst
diskretisiert
(Sprunginvarianz-Transformation, Tustinsche Näherung) und diskret in die
Simulation implementiert werden.
Bei der dann folgenden Abfragen "Fixed step size" und "Mode" im Feld
„Simulation Parameters“ sollte immer "auto" gewählt werden. Die Abtastzeit, die
sich hinter "Fixed step size" verbirgt, wird in den „RT In“- und „RT-Out“Simulationsblöcken (siehe Kapitel 3.2.3) festgelegt.
Die Menüpunkte "Workspace I/O" und "Diagnostics" werden im Rahmen dieser
Einführung nicht benötigt und deshalb nicht verändert.
Das Fenster "Simulation Parameters" kann nun geschlossen werden.
3.4.3.6 Parametrierung der Simulationsblöcke
Alle Simulationsblöcke im SAF müssen, wie bei normalen Simulink-Sitzungen auch,
parametriert werden. Zu diesem Zweck müssen der Block mittels eines Doppelklicks
geöffnet und die abgefragten Parameter eingetragen werden. (Neben den folgenden
Erläuterungen können zur näheren Auskunft auch die Informationen herangezogen
werden, die nach Betätigung des "Help"-Buttons angezeigt werden).
Im Falle des Blocks "RT In" werden folgende Parameter abgefragt (vergleiche das
folgende Bild): "Sample Time": hier muss die Abtastzeit eingetragen werden mit der
die Daten eingelesen, ausgeben und die Simulation betrieben werden soll. Die Größe
hängt
primär
von
der
Problemstellung
3.27
ab,
jedoch
hat
auch
die
Rechengeschwindigkeit
der
Problemstellung
Abtastzeit
eine
CPU
einen
maßgeblichen
erfordert,
die
so
Einfluß.
klein
ist,
Falls
die
dass
die
Rechengeschwindigkeit der CPU nicht ausreicht, (dies macht sich durch eine
Fehlermeldung des RTW bemerkbar: "Error occured ... Too fast for this hardware")
muss auf einen Rechner mit schnellerer CPU zurückgegriffen werden. In ungünstigen
Fällen erfolgt manchmal auch keine Fehlermeldung, sondern die Echtzeitanwendung
stürzt schlicht ab.
Bei "HW Adapter" muss der Name, der unter dem Kartensymbol zur Auswahl des
Kartentreibers (default "Adapter") steht, eingetragen werden.
Bei "Adapter Channels" wird die Anzahl der benutzten A/D-Wandler-Kanäle
eingetragen:
1
:
[1 2] :
[1 2 3] :
usw.
Kanal 1
Kanal 1 und 2
Kanal 1, 2 und 3
Mit dem "OK"-Button wird das Fenster geschlossen.
Der Block "RT Out" wird in gleicher weise parametriert. Es ist darauf zu achten, dass
an allen Stellen, wo die "Sample time" abgefragt wird, immer der gleiche Wert
eingetragen wird, sonst erfolgt eine Fehlermeldung, so dass die Echtzeitanwendung
nicht gestartet werden kann.
Sind noch weitere Simulationsblöcke in der zu simulierenden Struktur enthalten,
3.28
müssen diese selbstverständlich auch parametriert werden. Dabei kann man i.a. so
vorgehen, wie man es aus normalen Simulink-Sitzungen gewohnt ist.
3.4.3.7 Starten einer Echtzeitanwendung
Nach den vorangehenden Anschluß- und Parametrierungsarbeiten kann die erzeugte
Simulationsstruktur in Echtzeit betrieben werden.
Dazu muss im SAF im Menü "Tools" des SAF "RTW Build" ausgewählt werden.
Matlab startet dann die Übersetzungs-, Compilierungs- und Link-Prozedur zur
Generierung eines ausführbaren Programms. Dieser Vorgang ist im sich in den
Vordergrund legenden Matlab-Command-Window beobachtbar.
Bei dieser Prozedur entstehen neben dem ausführbaren Kode eine Vielzahl weiterer
Dateien, die im aktuell eingestellten Speicher-Verzeichnis abgelegt werden. Zur
Verhinderung von Datenchaos sollte deshalb vor dem „Build“-Vorgang in das
Verzeichnis gewechselt werden, wo diese Dateien abgelegt werden sollen. Dies wird
i.A. das Verzeichnis sein, in dem auch die Simulink-Quellstruktur abgelegt wurde.
Beim folgenden Startvorgang dieser Echtzeitanwendung (siehe weiter hinten) sollte
man sich auch in diesem Verzeichnis befinden.
Wenn kein Fehler auftritt heißt die letzte Meldung dieses Build-Prozesses
"Successfull completion of Realt-Time Workshop buildprocedure for
model: untitled".
Erfolgte diese Meldung, wechselt man wieder in das SAF und wählt im Menü
"Simulation" "Connect to target". Damit wird die Echzeitanwendung in den PCArbeitsspeicher geladen und mit der A/D-D/A-Hardware gekoppelt, der Kode aber
noch nicht gestartet. Erst mit der Menüauswahl "Simulation" "Start real-time code"
wird die Echtzeitanwendung gestartet. Sie stoppt entweder nach Ablauf der weiter
vorn gewählten "Stop time" oder durch manuelle Auswahl des Menüpunktes
"Simulation" "Stop real-time code".
Hinweis 1
Leider bleibt das Signal, was beim Stoppen der Echtzeitanwendung am Ausgang des
D/A-Wandlers liegt, anschließend konstant am Ausgang liegen. Falls dies zu
unerwünschten Betriebszuständen im angesteuerten System führen sollte, empfiehlt
es sich, das angesteuerte System vor dem Stoppen der Echtzeitanwendung
3.29
auszuschalten. Häufig genügt es jedoch, nach dem Stoppen der Echtzeitanwendung, wieder den Zustand „Connect to target“ herzustellen. In diesem Zustand
wird am Ausgang des D/A-Wandlers 0 Volt ausgegeben und das angesteuerte
System komm auch zur Ruhe, (auch wenn man anschließend "Disconnect from
target" wählt).
Falls während das Laufes Daten gespeichert wurden, kann es bei den vorangehend
beschriebenen Manipulationen zu Datenverlusten kommen. Es wird deshalb
empfohlen, nach dem Studium dieses Skriptes und vor einer echten Anwendung des
Real-Time Workshop / Real-Time Windows Targets, sich ausführlich mit dem
Stoppen
von
Echtzeitanwendungen
und
der
Rettung
gemessener
Daten
auseinanderzusetzen.
Hinweis 2
Der Real-Time Workshop / Real-Time Windows Target Wind nimmt eine Normierung
der ein- und auszugebenden Signalamplituden vor, die sich bei den vorangehend
vorgenommen Parametrierungen wie folgt auswirkt:
•
Ein über den Block "RT In" eingelesenes Signal von ±10V am Eingang des A/DWandlers wird auf ±1V im SAF am Blockausgang abgebildet (10 fache
Dämpfung).
•
Ein über den Block "RT Out" aus dem SAF ausgegebenes Signal von ±1V wird
auf eine Signalamplitude von ±10V am Ausgang des D/A-Wandlers abgebildet
(10 fache Verstärkung).
Um Verständnisschwierigkeiten zu vermeiden, sollte daher immer mit folgender
Konfiguration gearbeitet werden:
Die jeweilige Blockkofiguration sollten als Einheit aufgefasst werden, d.h. zwischen
"RT in"-Block und dem anschließenden "Gain"-Block oder dem "Gain"-Block und dem
anschließenden "RT Out"-Block sollte nie eine weiterer Block angeschlossen oder
eine Verbindungsleitung abgezweigt werden.
3.30
3.4.3.8 Signalvisualisierung
Einer der großen Vorzüge des Real-Time Workshop, wenn er in Zusammenhang mit
dem "Realtime-Windows-Target" betrieben wird, ist die Möglichkeit, sich mit Hilfe von
Oszilloskopen ("Scopes" aus der "Simulink Block Library" "Sinks") an beliebigen
Stellen einer Simulationsstruktur die aktuellen Signalverläufe in Echtzeit ansehen und
damit das Verhalten das Systems beurteilen zu können.
Zu diesem Zweck muss ein "Scope"-Block an die interessierende Leitung im SAF
angeschlossen werden.
Im folgenden Beispiel wird das eingelesene Signal auf einem "Scope" angezeigt und
gleichzeitig über einen "RT Out"-Block ausgegeben. Die Amplitudennormierung
wurde, wie vorangehend beschrieben, aufgehoben:
Würde man mit einem realen Oszilloskop das Eingangs- und das Ausgangssignal
messen und diese Signalverläufe mit der "Scope"-Abbildung vergleichen, müssen
alle Kurvenverläufe gleich sein.
Bevor das "Scope" sinnvoll arbeitet, muss es auch parametriert werden. Klickt man
das Scope-Symbol im SAF an, öffnet sich sein "Bildschirm" über dem sich sieben
Buttons mit folgender Bedeutung befinden (siehe folgendes Bild).
3.31
1: Zoom in x- und y-Richtung
5: Rettet die aktuellen
2: Zoom in x-Richtung
Einstellungen
3: Zoom in y-Richtung
6: Eigenschaften einstellen
4: Automatische Skalierung
7: Graphen drucken
Die Bedeutung der Buttons ist weitgehend selbsterklärend: mit 1, 2 und 3 kann mit
Hilfe der Maus ('klicken und ziehen') der Bildinhalt entsprechend gezoomt werden.
Button 4 nimmt durch Anklicken eine automatische Skalierung vor, so dass der
gesamte Bildinhalt, wie bei Matlab gewohnt, optimal in den Koordinaten angezeigt
wird. Mit Button 5 kann eine als optimal erkannte Skalierung für die folgenden
Signalausgaben "eingefroren" werden.
Der zunächst wichtigste Button ist Nr. 6 "Eigenschaften einstellen". Betätigt man ihn,
öffnet sich ein Fenster " 'Scope' properties " mit zwei weiteren Ordnern "General" und
"Data history".
Im Ordner "General" werden folgende Eigenschaften abgefragt:
3.32
•
"Number of axes ":Trage Sie hier ein, wieviel Darstellungs-Kanäle des Scope
haben soll. So erhält man z.B. bei einem Eintrag von z.B. "2" zwei ScopeEingänge und zwei übereinander liegende Bildschirme. Es wird empfohlen mit nur
einem Eingang pro Scope zu arbeiten.
•
"Time range"
Hier wird eingetragen über welcher Zeitachse die Signale im Scope ausgegeben
werden. Bei "auto" ist die Zeitachse genau so lang, wie die bei der
Parametrierung des RTW eingegebene "Stop Time" (vergleiche Kapitel 3.2.2).
Hier kann aber auch jede Zeit, die kleiner ist als die "Stop Time", eingegeben
werden, um eine repetierende, aber besser aufgelöste Signaldarstellung zu
erzielen.
•
"Tick labels"
"bottom axis only" beschriftet bei der Wahl von "Number of axes" > 2 nur die
untere Zeitachse, "all" alle Graphen und "non" keine.
•
"Sampling"
Im Feld "Sampling" kann in der Auswahl "Sampling time" eine DarstellungsAbtastzeit für die Scope-Darstellung des Signals gewählt werden. Bei Nutzung
der Auswahl "Decimation" kann die Anzahl der Darstellungs-Stützpunkte
dezimiert werden. Wenn z.B. die Simulation mit einer Abtastzeit von T= 0,1
durchgeführt und Decimation=10 gewählt wird, ergibt sich eine DarstellungsAbtastzeit von 1.
Im zweiten Ordner des Fensters " 'Scope' properties " nämlich "Data history"
(vergleiche das Bild auf der nächsten Seite) deaktivieren wir (falls es nicht schon
geschehen ist, "Limit rows to last ..." . Damit stellen wir sicher, dass bei der ScopeAnzeige keine Darstellungsverluste durch die hier einstellbare Anzahl von
Bildpunkten entstehen.
Die nächste Auswahl "Save data to workspace" besprechen wir im Kapitel 3.4.3.8,
wo wir uns mit der Speicherung von Meßdaten auseinander setzen.
Nach diesen Einstellungen wird das Fenster " 'Scope' properties" mittels des "OK"Buttons geschlossen. Eine vorangehende Betätigung von "Apply" ist nicht notwendig.
3.33
Während die vorangehend beschriebenen Parametrierungen eines Scope-Blockes
auch im normalen Simulink-Betrieb (d.h. Off-Line ohne Echtzeitbetrieb) durchgeführt
werden müssen, benötigt man zur Echtzeit-Visualisierung von Signalen mittels
Scope-Blöcken weitere Einstellungen.
Zu diesem Zweck öffnen wir im SAF mit der Menüfolge
Tools → External Mode Control Panel
ein Fenster mit dem Namen "Modellname: External Mode Control Panel",
wo wir den Button "Signal & Triggering" anklicken. (Die anderen Buttons werden im
Rahmen dieser Einführung nicht
benötigt.) Es öffnet sich ein Fenster mit dem
Namen "Modellname: External Signal & Triggering" (siehe nächstes Bild).
3.34
Im Feld "Signal selection" sind alle im Simulationsmodell benutzten "Scopes" mit
ihren Namen in der Rubrik "Block" aufgelistet. Um sie zu aktivieren, d.h. zur EchtzeitSignalanzeige zu veranlassen, muss zunächst in der linken unteren Ecke des
Fensters "Arm when connect to target" aktiviert werden. Jetzt können durch
Anklicken einer Scope-Zeile aus der dargestellten Liste und anschließender
Betätigung des Radio-Buttons "on" Scopes zur Anzeige aktiviert und durch "off"
wieder deaktiviert werden. Mit "Select all" können alle Scopes gleichzeitig aktiviert
werden.
Ein
aktiviertes
Scope
wird
durch
ein
der
entsprechenden
Zeile
vorangestelltes "X" gekennzeichnet.
Die Signalvisualisierung kann freilaufend oder signalgetriggert erfolgen, dies kann in
der Rubrik "Trigger" in der Abfrage "Source" eingestellt werden:
•
"manual"
Frei laufende Anzeige, d.h., die Signaldarstellung erfolgt nach dem Start der
Echtzeitanwendung durch "Start realtime code". Diese Einstellung wird für die
Durchführung erster Simulationsläufe in einer noch nicht näher bekannten
Umgebung empfohlen, wenn Verlauf und Amplitude des darzustellenden Signals
noch nicht genau bekannt sind.
3.35
•
"signal"
Anzeige des Signals erst nach dem Auftreten eines Trigger-Ereignisses, das noch
genauer spezifiziert werden kann (siehe weiter unten).
Im Feld "Duration" wird eingestellt, wieviel Abtastschritte (T) im Scope dargestellt
werden sollen. Es wird empfohlen, die "Duration" nach folgender Formel zu
berechnen
gewählte Signal-Darstellungsdauer des Scopes
Duration = -----------------------------------------------------------------------Abtastzeit (T)
.
Im freilaufenden Betrieb sollten die Felder "Mode" mit "normal" und "Delay" mit "0"
parametriert werden.
Zur getriggerten Signaldarstellung wählt man im Feld "Source" die Eigenschaft
"signal". Im gleichen Moment wird das Feld "Trigger signal" aktiviert, wodurch weitere
fünf Felder ("Port", "Element", "Direction", "Level" und "Hold-off") parametriert werden
müssen.
Zunächst
wählt
man
jedoch
aus,
welches
Scope-Signal
zur
Triggerung
herangezogen werden soll. Dazu klickt man die gewünschte Scope-Zeile in der
Rubrik "Signal Selection" an. Sie wird dadurch blau unterlegt. Anschließend betätigt
man den Button "Trigger signal", rechts neben dem Feld "Signal Selection". Das
gewählte Scope wird dadurch auf der linken Zeilenseite mit einem "T" versehen.
Die fünf oben erwähnten Parametrierungen werden wie folgt vorgenommen:
•
"Direction"
Angabe welche Verlaufsrichtung des Signal ("rising", "falling", "either") zur
Triggerung herangezogen werden soll.
•
"Level"
Angabe welcher Signalpegel (in Volt) die Triggerung auslösen soll.
•
"Port" und "Element"
Diese beiden Parameter werden nur benötigt, wenn ein Scope-Block mit
mehreren Eingängen zur Triggerung benutzt wird. Nähere Informationen finden
3.36
sich in /1/.
•
"Hold-off"
Bezieht sich auf die "Mode" "normal" Triggerung (siehe weiter unten).
Ausgedrückt in Abtastschritten ist "Hold-off" die Zeit zwischen der Beendigung
eines Trigger-Ereignisses und dem neuen Initialisieren des Triggers. Diese
Parametrierung wird selten benötigt, "Hold-off" steht daher i.a. auf 0.
In den Felder "Mode" und "Delay" bestehen noch folgende Parametrierungsmöglickeiten:
•
"Mode"
Hier besteht die Wahl zwischen "normal" und "one-shot". In der "normal"Betriebsweise wird der Trigger nach jedem Triggerereignis automatisch wieder
initialisiert. In der "one-shot"-Betriebsweise wird nur ein Datensatz gesammelt und
der Trigger erst nach erneutem ""Connect to target" wieder aktiviert. Es wird die
Benutzung des "normal"-Betriebszustands empfohlen.
•
"Delay"
Hier kann eine bestimmte Anzahl von Abtastschritten eingegeben werden, die die
Auslösung des Triggers gegenüber dem Anfang der Datendarstellung verzögert,
damit ist Posttriggering möglich. (Wird selten benötigt, nähere Einzelheiten siehe
/1/.
Nach diesen Parametrierungen wird das Fenster "Modellname: External Signal &
Triggering" geschlossen und die Echtzeitanwendung mit Datenvisualisierung kann
erstellt und laufen gelassen werden.
Hinweis 3
Die Signaltriggerung funktioniert nur, wenn die "Duration"-Einstellung nach der
Formel von Seite 21 richtig vorgenommen wird.
Hinweis 4
Für die in der Regelungstechnik relativ langsam ablaufenden Vorgänge wird i.A. die
Triggerung der Signale nicht benötigt, d.h. die Auswahl bei "Mode" wird i.A. "normal"
sein und mit dem Knopf "Trigger signal" wird kein Signal gekennzeichnet.
3.37
Falls zu viele Scopes zur Echtzeit-Signalbeobachtung eingesetzt werden, kann es,
insbesondere bei geringer CPU-Rechenleistung und kurzen Abtastzeiten, passieren,
dass die Anzeige nicht mehr schritthaltend arbeitet. Die Signale werden später
dargestellt, als sie in Wirklichkeit auftreten.
Die Rechenkapazität wird in diesem Falle auf das Einlesen, Ausgeben und die
Datenverarbeitung
innerhalb
der
Simulations-Struktur
verlagert,
weil
diese
Funktionen sinnvollerweise eine höhere Priorität genießen. Abhilfe kann damit erzielt
werden, dass
•
nicht alle Scopes im "External Signal & Triggering"-Fenster aktiviert werden oder
•
die Darstellungs-Abtastzeit der Scopes im "Scope properties"-Fenster (Scope
Anzeige-Fenster, Button 6) im Ordner "General" bei "Sampling" so verändert wird,
dass weniger Daten angezeigt werden (z.B. durch Wahl von "Decimation"
3.4.3.9
> 1).
Speicherung von Messdaten
Bei allen vorangegangenen Betriebsweisen des Real-Time Windows Target
existieren die gemessenen und verarbeiteten Signale nur transient im Moment ihres
Auftretens, d.h. es werden keine Daten gespeichert. Möchte man Daten speichern,
um sie nach einer Echzeit-Verarbeitung anschließend Off-Line weiter zu verarbeiten,
muss dieser Wunsch dem Real-Time Windows Target explizit mitgeteilt werden.
Dazu öffnen wir das schon bekannte Bildschirmfenster des Scopes, dessen Daten im
Matlab-Arbeitsspeicher gespeichert werden sollen:
Nach Betätigung von Button 6 erscheint das auch schon bekannte Fenster " 'Scope'
3.38
properties", bei dem wir den Ordner "Data history" öffnen:
Wir aktivieren das Feld "Save data to workspace" und wählen als "Format" "Matrix
(compatible with V2.0-2.2)". Damit erhalten wir ein gespeichertes Datenformat, das
uns aus der Nutzung von Matlab 4.2 bekannt ist.
Ist die im Ordner "General" von " 'Scope' properties" eingetragene "Time range"
identisch mit der bei "Simulation time" ( Menüfolge im SAF: Simulation → Parameters
→ Solver) eingetragenen, werden alle von diesem Scope während der laufenden
Echtzeitanwendung angezeigten Signale einschließlich des Zeitvektors mit der
gewählten Abtastzeit T im Matlab-Arbeitsspeicher mit dem Namen abgelegt, den Sie
unter "Variable name" eingetragen haben. Im vorliegenden Fall ist es die DefaultEintragung "ScopeData" . Ist die bei "'Scope' properties" eingetragene "Time range"
kürzer als die bei "Simulation time", wird nur der letzte Bildinhalt des Scopes
gespeichert.
Bitte bedenken Sie, dass jedes gespeicherte Datum und jeder im Zeitvektor
gespeicherte Zeitschritt nach Matlab-Konventionen jeweils 8 Byte lang ist. Berechnen
Sie daher überschlägig, ob die von Ihnen geplante Speicherdauer nicht die Kapazität
ihres Speichermediums sprengt.
Nach Ablauf der Echtzeitanwendung steht Ihnen dann der Datensatz unter Matlab
zur Verfügung. Mittels "whos" erfolgt im Matlab-Command-Window folgende
Ausgabe:
Name
Size
Bytes Class
ScopeData
51x2
816
double array
Grand total is 153 elements using 1224 bytes
3.39
In der (n x 2) - Matrix "ScopeData" befinden sich in der ersten Spalte die Zeitachse
"ScopeData( : , 1)" und in der zweiten Spalte der Signalverlauf "ScopeData( : , 2)".
Der Signalverlauf könnte z.B. mit dem folgenden Befehl unter Matlab geplottet
werden:
plot(ScopeData(:,1), ScopeData(:,2)), grid on;
Hinweis 5:
Speichern Sie die Meßdaten (auf Festplatte, Diskette), bevor Sie im Menü
"Simulation" den Menuepunkt "Connect to target" erneut wählen oder das
Bildschirmfenster, auf dem die Meßdaten zu sehen sind, schließen.
Anderenfalls können die Meßdaten im Matlab-Arbeitsspeicher gelöscht werden. Dies
ist insbesondere bei Langzeitmessungen ärgerlich.
3.4.4 Offset-Abgleich der A/D-D/A-Wandlerkarte pci6025E
Bei der A/D-D/A-Wandler-Karte pci6025E der Firma National Instruments können
sich nach dem Einschalten des Rechners ungewollte Gleichspannungspegel (OffsetSpannungen) einstellen, die sowohl die Signalerfassung über den A/D-Wandler als
auch die Signalausgabe über den D/A-Wandler verfälschen.
Aus diesem Grunde muss einmal nach jedem Einschalten des PCs ein sogenannter
Offsetabgleich vorgenommen werden. Aus didaktischen Gründen soll dies nicht
automatisch per Firmware sondern schrittweise von Hand vorgenommen werden.
•
Offsetkompensation am Analog-Eingang
Zunächst wird im Real-Time Windows Target an den oder die benutzten "RT In" Böcke mit Normierungsverstärker (vergleiche Kapitel 3.2.4. , Hinweis 2) ein Scope
angeschlossen
RT In
10
RT In
Gain
Scope
und der entsprechende Hardwareeingang elektrisch kurzgeschlossen. Falls ein
Offsetfehler vorliegt, kann diese Offsetspannung auf dem Scope abgelesen werden.
3.40
Zur Offset-Kompensation, wird mittels eines "Constant"-Blockes aus der SimulinkBlocklibrary "Sources" der im Vorzeichen umgekehrte Wert der auf dem Scope
abgelesenen Spannung wie folgt aufgeschaltet:
Weiterverarbeitung des
eingelesenen Signals
RT In
10
RT In
Gain
Scope
-Offset
Constant
Wenn dann am Scope eine Spannung von ca. Null Volt ablesbar ist, ist der
entsprechende Eingang ist abgeglichen.
•
Offsetkompensation am Analog-Ausgang
Zur Offsetkompensation von Analog-Ausgängen wird an den abzugleichenden
Hardware-Ausgang
ein
Gleichspannungsmesser
(Bereich
0V
bis
ca.
10V)
angeschlossen. Aus dem Real-Time Windows Target heraus wird mit folgender
Struktur Null Volt ausgegeben:
0
Constant
0,1
RT Out
Gain
RT Out
Falls ein Offset-Fehler vorliegt, kann eine Fehlerspanunng ungleich Null Volt auf dem
Spannungsmesser abgelesen werden. Die abgelesene Spannung wird anschließend
mit
umgekehrten
Vorzeichen
mittels
eines
"Constant"-Blockes
als
Offset-
Kompensation wie folgt in die Simulink-Strukutur eingefügt:
auszugebendes
Signal
0,1
RT Out
Gain
RT Out
-Offset
Constant
Nach diesen Offsetabgleichungen kann jetzt so lange Offsetfehler-frei gearbeitet
3.41
werden, bis der PC abgeschaltet wird. Nach einem erneuten Einschalten, muss ein
neuer Offsetabgleich vorgenommen werden.
Hinweis 6
Die
angegebenen
Offset-Kompensationsstrukturen
müssen
in
die
Simulink-
Echtzeitanwendungen eingebaut werden, die zur Messung benutzt werden!
3.5
Embedded Coder und Target for Infineon C166 als Werkzeug zum
implementierungsorientierten Rapid Prototyping
Leider existieren im aktuellen Semester noch keine Laborarbeitsplätze für
implementierungsorientiertes Rapid Control Prototyping. Es sind jedoch alle
Softwarekomponenten
von
Matlab/Simulink
und
die
dazu
notwendige
C-
Entwicklungsumgebung "Tasking Tools" der Firma Altium, Australien vorhanden, um
diese Arbeitsplätze aufzubauen. Auch entsprechende Hardware in Form von
Development Kits mit dem Prozessor C167 von der Firma Phytec, Deutschland sind
vorhanden.
Erste Erfahrungen mit dieser Entwicklungsumgebung wurden im Wintersemester in
Form einer Diplomarbeit /18 / gemacht.
Wer Interesse an dieser Technik hat, ist eingeladen sich in Form einer Masterarbeit
am Aufbau von Laborarbeitsplätzen zu beteiligen.
3.42
4.
Praktisches Rapid Control Prototyping
Dieses Kapitel kann mit Hilfe des Laborberichts, der parallel und zum Abschluss des
Laborversuchs
angefertigt
wird,
selbst
ergänzt
werden.
Die
Überschriften
entsprechen weitgehend dem Papier "Vorgehensweise zur Lösung praktischer
regelungstechnischer Problemstellungen", das auf der Webseite des Autors dieses
Skripts zu finden ist und als Bearbeitungsreihenfolge zur Lösung der Laboraufgabe
empfohlen wurde.
Die Anpassung des Berichts an die in diesem Kapitel verwendeten Überschriften ist
als Nachbereitung des Laborstoffss und als Vorbereitung zur Klausur sehr
empfehlenswert.
4.1
Literatur
(Gedruckte Literatur wird beginnend mit /1/, Internetadressen zu bestimmten
Themen werden beginnend mit /100/ durchnummeriert.)
/1/
A. Burst: "Rapid Prototyping eingebetteter Systeme auf der Basis des CDIFDatenaustauschformats"
Dissertation am Institut für Informationsverarbeitung, Universität Karlsruhe,
2000.
/2/
M. Ottens: "Grundlagen der Systemtheorie",
Vorlesungsskript im Fachbereich Informatik und Medien, Beuth Hochschule für
Technik Berlin, Sommersemester 2008.
/3/
M. Ottens: "Einführung in die Regelungstechnik",
/4/
M. Ottens: "Einführung in das CAE-Programm Matlab/Simulink",
/5/
M. Ottens: "Praktische Verfahren zur experimentellen Systemidentifikation",
/6/
A. Angermann, M. Beuschel, M. Rau, U. Wohlfahrt:
"Matlab-Simulink-Stateflow Grundlagen, Toolboxen, Beispiele",
Oldenbourg Verlag, Münschen, Wien, 2. Auflage, 2003.
/7/
Ratcliff, B.: "Early and not-so-early prototyping-rationale and tool support"
Computer Software an applications Conference, 1988, COMPSAC 88.
Proceedings, Twelfth International.
/8/
Ohne Autorenangabe: "Real-Time Windows Target Users Guide"
Version 3.0 (R2007b), The MathWorks, Inc; Natic, MA, USA
/9/
Ohne Autorenangabe: "Real-Time Workshop Users Guide"
/10/
Ohne Autorenangabe "Getting Started with Matlab"
Version 7.5.0.342 (R2007b), The MathWorks, Inc; Natic, MA, USA
(In diesem Manual wird auf die verschiedenen vertiefenden Manuals zu
Matlab hingewiesen)
/11/
Ohne Autorenangabe: "Using Simulink"
/12/
Ohne Autorenangabe: "Real-Time Workshop Embedded Coder Users Guide"
/13/
Ohne Autorenangabe: "Link for Tasking Users Guide"
/14/
Ohne Autorenangabe: "Target for Infineon C166 Users Guide"
/15/
Ohne Autorenangabe: "Real-Time Workshop Reference"
Version 7 (R2007b), The MathWorks, Inc; Natic, MA, USA
/16/
S.Rebeschieß, T. Liebezeit, U. Bazarsuren
"Automatisierter Closed-Loop-Softwaretest eingebetteter Motorsteuerfunktionen"
www.silest.de/data/multimedia/paper_elektronik_im_kfz_2006_rebeschiess.pdf
/17/
D. Abel, A. Bollig: "Rapid Control Prototyping: Methoden und Anwendungen"
Springer Verlag; Berlin, Heidelberg, New York, ... , 2006
/18/
R.Spyra: "Rapid Control Prototyping für C167-Mikrocontroller unter
Matlab/Simulink"
Diplomarbeit im Studiengang Technische Informatik des Fachbereichs VI
(Informatik und Medien), Beuth Hochschule für Technik, 2010
/100/
http://de.wikipedia.org/wiki/Unified_Modeling_Language
/101/
http://ivs.cs.uni-magdeburg.de/~dumke/UML/12.htm
/102/
http://de.wikipedia.org/wiki/Eingebettetes_System
/103/
http://en.wikipedia.org/wiki/Embedded_systems
/104/
http://de.wikipedia.org/wiki/In-Circuit-Emulator
/105/
http://de.wikipedia.org/wiki/Joint_Test_Action_Group
/106/
http://de.wikipedia.org/wiki/TargetLink
/107a/
http://www.autosar.org/download/AUTOSAR_long_de.pdf
/107b/
http://www.autosar.org/download/AUTOSAR_short_de.pdf
/108/
http://de.wikipedia.org/wiki/OSEK
/109/
http://de.wikipedia.org/wiki/Echtzeitsystem
/110/
http://www.openwatcom.org/index.php/Main_Page
/111/
http://www.altium.com (Tasking Tools for C166, v8.6r3)
/112/
http://www.windriver.com/
/113/
http://de.wikipedia.org/wiki/ASCET/
/114/
http://de.wikipedia.org/wiki/LabVIEW/
/115/
http://www.ni.com/matrixx/
/117/
http://de.wikipedia.org/wiki/Controller_Area_Network
/118/
http://de.wikipedia.org/wiki/Hardware_in_the_Loop
/119/
http://www.openwatcom.org/index.php/Main_Page

vorläufige Fassung - Beuth Hochschule für Technik Berlin

Transcrição

Documentos relacionados

Portunus 5.2 mit erweiterter VHDL-AMS

Speccy - Winprint

Lebenslauf als PDF-Datei

Spezialtreiber für TT-budget Produkte Unterstützte Produkte: TT

MBR-Wiederherstellung unter Windows 2000®/XP

Technische Daten - i

MICROSOFT LifeCam VX-800

Stellenbeschreibung IT-Support - Helpdesk

WINDOWS 7 FUNKTIONIERT AM BESTEN MIT DISKEEPER

Windows XP Windows Installer blockiert - FAQ