Beuth Hochschule für Technik Berlin Fachbereich VI (Informatik und Medien) Manfred Ottens Richard Spyra

Größe: px
Ab Seite anzeigen:

Download "Beuth Hochschule für Technik Berlin Fachbereich VI (Informatik und Medien) Manfred Ottens Richard Spyra"

Transkript

1 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 ) Berlin, Sommersemster 2010

2 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

3 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, und 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

4 Inhalt 1 Einführung 1.1 Klassischer Softwareentwurf für eingebettete Systeme Entwurfsphasenmodelle Modellierungsverfahren Realisierungsprobleme eingebetteter Systeme 1.2 Rapid Control Prototyping Das Entwurfsphasenmodell Werkzeuge zum Rapid Control Prototyping Mit Matlab von der Systemspezifikation zum Objektkode Konzeptorientiertes Prototyping Implementierungsorientiertes Prototyping Echtzeitbetrieb Festkommaarithmetik What is in the Loop? 2 Fachliches Umfeld 2.1 Systemtheorie 2.2 Systemmodellierung / Systemidentifikation 2.3 Regelungstechnik 2.4 Simulation dynamischer Systeme 3 Die Arbeitsumgebung Matlab/ Simulink 3.1 Ein Werkzeug zur Systemidentifikation 3.2 Ein Werkzeug zum Reglerentwurf 3.3 Ein Werkzeug zur Systemsimulation Einbindung von Festkommaarithmetik 3.4 Das Real-Time Windows Target als Werkzeug zum konzeptorientierten Rapid Prototyping Einleitung Vorbemerkungen zum Betrieb des Real-Time Workshop / Real-Time Windows Target Bedienungsanleitung des Real-Time Workshop / Real-Time Windows Targets III

5 Prüfung der Installation des Echtzeitkerns Anpassung der "RT In"- und "RT Out"-Blöcke an die installierte A/D-DA-Wandler-Karte Realisierung einer Realtime-Anwendung Hardware-Ankopplung Parametrierung des Real-Time Workshop / Real-Time Windows Targets Parametrierung der Simulationsblöcke Starten einer Real -Time - Anwendung Signalvisualisierung Offsetabgleich der A/D-D/A-Wandlerkarte pci6025e 3.5 Embedded Coder und Target for Infineon C166 als Werkzeug zum implementierungsorientierten Rapid Prototyping 4 Praktisches Rapid Control Prototyping 4.1 Identifikation des Steuerverhaltens der Regelstrecke Statisches Verhalten Dynamisches Verhalten 4.2 Identifikation des Störverhaltens der Regelstrecke 4.3 Simulation des Streckenverhaltens 4.4 Der Reglerentwurf Kontinuierlicher Regler Zeitdiskreter Regler Zeitdiskreter Regler mit Festkommaarithmetik 4.5 Simulation des Regelkreises Prüfung des Führungsverhaltens Prüfung des Störverhaltens Prüfung des Aussteuerbereich der Stellgröße 4.6 Implementierung des Reglers in das Anwendersystem Software in the Loop Hardware in the Loop IV

6 1 Einführung Software zur Regelung technischer Prozesse läuft i. A. in dezentral angeordneten Steuergeräten, die einen Mikrocontroller und aufgabenspezifische Ein-/Ausagabe- Hardware, 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

7 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 wird bei der Betrachtung des Entwurfphasen-Modells im Vergleich zu den Modellen für den klassischen Entwurf im Kapitel deutlich, an welcher Stelle sich beide Entwurfsstrategien maßgeblich unterscheiden. Das Kapitel 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 "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 wird die Grundidee eines einfachen Echtzeit-Betriebssystems auf der Basis periodischer Interrupts beschrieben. Anschließend im Kapitel 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 vertieft. Das zu entwickelnde Regelungssystem kann mit dem zu regelnden Prozess in 1.2

8 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 "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 Entwurfsphasenmodelle 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

9 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 und Beschreibung solcher Subsysteme wird eine gewisse Strukturierung der Gesamtaufgabe angestrebt, die 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 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

10 Anforderungs analyse System spezifikation Lastenheft 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 V- Modell: Anforderungs analyse Fertigung System spezifikation Anwendungs test Top Down System entwurf Subsystem entwürfe Subsystem test System test Bottom Up System realisierung Bild 1.1.2: Das V-Modell des Softwareentwurfs 1.5

11 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 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

12 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 daten- und 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

13 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

14 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 ut () C y() t u() t = y() t = Eingangsspannung Ausgangsspannung Bild 1.1.3: Ein nachzubildendes reales System R = 100 kω, C = 100 µf 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. yt () 1V ut () 0 0 t 1V Digitalrechner mit 0 0 t implementiertem Filteralgorithmus yt () A / D D / A 1V Bild 1.1.4: Nachbildung des Wirkungsverhaltens durch einen Algorithmus 0 0 t In /2/ wurde gezeigt, wie man das RC-Glied mittels einer mathematisch /physikalischen Modellbildung in eine Zustandsmodell und anschließender 1.9

15 Transformation in eine Übertragungsfunktion wie folgt beschreiben kann: U(s) a 1 1 G(s) = = =. U(s) 1+ RCs 1+ 10s e 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 e 1 U(z) a 0, ,09516z G(z) = = =, U(z) z 0, ,9048z die man in eine Differenzengleichung wandeln kann: u a(k) = 0,9048u a(k 1) + 0,09516u e(k 1). Nach /2/ ergibt sich daraus folgendes Strukturbild: u(k) e T u(k e 1) 0,09516 u(k) a 0,9048 u(k a 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 Matlab- Programm quasi als Pseudocode für ein C-Programm auffassen. 1.10

16 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 = *ua_alt *ue_alt; % Realisierung des Strukturbildes. ue_alt = ue; % Umladung der Signalspeicher ua_alt = ua; % von kt nach (k-1)t. end 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 identischen Zwischenräumen zwischen den Berechnungszeitpunkten, simulieren. Wir wollen die Frage beantworten, wo der Unterschied liegt, im Berechnungsergebnis oder im Berechnungsalgorithmus? 1.11

17 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 nicht zum Entwurf von kontinuierlichen Steuerungen/Regelungen benutzen wollen, gehen wir auf dies Modellierungsverfahren nicht ein. 1.12

18 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 Verarbeitungs- 1.13

19 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 die automatische Generierung von Festkommaarithmetik mit Simulink und dem "Fixed Point Blockset" kennen lernen. In Kapitel 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

20 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 Debug- Funktionen möglich. 1.15

Beobachtergestützte Regelung einer Gasheizung in der Minimal-Invasiven-Medizin (kurz MIM) Felix Menzel, 12.05.2015

Beobachtergestützte Regelung einer Gasheizung in der Minimal-Invasiven-Medizin (kurz MIM) Felix Menzel, 12.05.2015 W.O.M. WORLD OF MEDICINE GmbH Beobachtergestützte Regelung einer Gasheizung in der Minimal-Invasiven-Medizin (kurz MIM) Felix Menzel, 12.05.2015 Regelungssysteme bei WOM (1) Anwendung: Insufflatoren (Laporoskopie)

Mehr

Rapid Control Prototyping

Rapid Control Prototyping Dirk Abel Alexander Bollig Rapid Control Prototyping Methoden und Anwendungen Mit 230 Abbildungen und 16 Tabellen Springer Inhaltsverzeichnis Einführung und Überblick 1 1.1 Allgemeines 1 1.2 Entwicklungsprozesse

Mehr

Skript zum Labor Maschinenkonstruktion. Konzipieren mechatronischer Produkte: Modellbasierte Programmierung eines Mikroroboters

Skript zum Labor Maschinenkonstruktion. Konzipieren mechatronischer Produkte: Modellbasierte Programmierung eines Mikroroboters Skript zum Labor Maschinenkonstruktion Konzipieren mechatronischer Produkte: Modellbasierte Programmierung eines Mikroroboters Sommersemester 2012 1. Einführung 1.1. Modellbasierte Entwicklung mechatronischer

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Studienvertiefungsrichtung Informationstechnik

Studienvertiefungsrichtung Informationstechnik Studienvertiefungsrichtung Informationstechnik Prof.Dr.-Ing. Ulrich Sauvagerd Lehrgebiet Informationstechnik Nov. 2006, Seite 1 www.etech.haw-hamburg.de/~sauvagerd Lehrgebiet Informationstechnik Nov. 2006,

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Codegenerierung für Mikrocontroller aus einem SimulinkModell (Schritt-für-Schritt-Anleitung)

Codegenerierung für Mikrocontroller aus einem SimulinkModell (Schritt-für-Schritt-Anleitung) Codegenerierung für Mikrocontroller aus einem SimulinkModell (Schritt-für-Schritt-Anleitung) Folgende Schritt-für-Schritt-Anleitung zeigt exemplarisch den Arbeitsablauf der CCodegenerierung für den Mikrocontroller

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

Automotive Software Engineering

Automotive Software Engineering Jorg Schauffele Thomas Zurawka Automotive Software Engineering Grundlagen, Prozesse, Methoden und Werkzeuge Mit 278 Abbildungen ATZ-MTZ-Fachbuch vieweg Inhaltsverzeichnis 1 Einfiihrung und Uberblick 1

Mehr

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System?

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System? Der Entwicklungsprozess Oder wie entwickle ich ein eingebettetes System? Einleitung Problemstellung erläutern, Eine Entwicklungsprozess ist ein Prozess, der beschreibt, wie man eine Entwicklung anzugehen

Mehr

Absicherung von Automotive Software Funktionen

Absicherung von Automotive Software Funktionen GI Themenabend "Automotive" Absicherung von Automotive Software Funktionen 27.02.2013 Jürgen Schüling Überblick Berner & Mattner Gründung: 1979 Mitarbeiter: 400 Umsatz 2011: Standorte: Angebot: Branchen:

Mehr

Test & Diagnose. Thomas Romanek. thomas.romanek@udo.edu. PG AutoLab Seminarwochenende 21.-23. Oktober 2007. AutoLab

Test & Diagnose. Thomas Romanek. thomas.romanek@udo.edu. PG AutoLab Seminarwochenende 21.-23. Oktober 2007. AutoLab Test & Diagnose Thomas Romanek thomas.romanek@udo.edu PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Einführung Tests zur Qualitätssicherung V-Modell Spezielle Verfahren in Automotive Das Diagnosesystem

Mehr

dspace (1/3) dspace: Gegründet 1988 in Paderborn Mitarbeiter: Über 650 Mitarbeiter weltweit, davon über 70 % Ingenieure Ständiges Mitarbeiterwachstum

dspace (1/3) dspace: Gegründet 1988 in Paderborn Mitarbeiter: Über 650 Mitarbeiter weltweit, davon über 70 % Ingenieure Ständiges Mitarbeiterwachstum Agenda dspace und das V-Modell für Steuergeräte- Entwicklung Wie funktioniert Rapid Control Prototyping TargetLink: Vom Model zum Code Ein Wort zu HIL Praxisbeispiele dspace (1/3) dspace: Gegründet 1988

Mehr

Detaillierte Abschlussarbeiten

Detaillierte Abschlussarbeiten Detaillierte Abschlussarbeiten Themenkomplex: Zweimassenschwinger Masterarbeit: Entwicklung und Implementierung eines Störgröÿenbeobachters Bachelor-/Masterarbeit: Entwicklung von adaptiven Regelungskonzepten

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Rapid-Control-Prototyping und Hardware-in-the-Loop Simulationen mit xpc Target and xpclabdesk/labview

Rapid-Control-Prototyping und Hardware-in-the-Loop Simulationen mit xpc Target and xpclabdesk/labview Rapid-Control-Prototyping und Hardware-in-the-Loop Simulationen mit xpc Target and xpclabdesk/labview N. Bajcinca Institut für Robotik und Mechatronik, DLR, Oberpfaffenhofen Kurzfassung xpc Target bietet

Mehr

Themen für Abschlussarbeiten/Praktika im Bereich FlexRay

Themen für Abschlussarbeiten/Praktika im Bereich FlexRay Kopfarbeit mit Spaßfaktor Kopfarbeit mit Spaßfaktor Von A3 bis Z4 wir sind marktführend in der Entwicklung von Softwarewerkzeugen und komponenten für die Vernetzung von Steuergeräten in Fahrzeugen. Über

Mehr

Integration, Test und Debugging von C-Code gemeinsam mit UML-generierten Sourcen

Integration, Test und Debugging von C-Code gemeinsam mit UML-generierten Sourcen Integration, Test und Debugging von C-Code gemeinsam mit UML-generierten Sourcen Bild 1: Eine Kreuzung für den Kfz-Verkehr soll um Straßenbahnampeln erweitert werden. Einführung Die wachsende Komplexität

Mehr

Bildverarbeitung in der Medizintechnik

Bildverarbeitung in der Medizintechnik Bildverarbeitung in der Medizintechnik Aufgrund einer Zusammenarbeit mit Würth Elektronik im Gebiet der Medizintechnik ist eine Arbeit aus dem Gebiet der Bildverarbeitung in der Medizintechnik ausgeschrieben.

Mehr

Integrative Entwicklungsprozesse am Beispiel einer automotiven Anwendung

Integrative Entwicklungsprozesse am Beispiel einer automotiven Anwendung am Beispiel einer automotiven Anwendung Bernd van Vugt EXTESSY AG Stefan Gläser VOLKSWAGEN AG Motivation Kundenwunsch: Mobilität und Individualität Fahrzeug + Informationstechnologie + Dienst Herausforderung:

Mehr

Programmieren was ist das genau?

Programmieren was ist das genau? Programmieren was ist das genau? Programmieren heisst Computerprogramme herstellen (von griechisch programma für Vorschrift). Ein Computerprogramm ist Teil der Software eines Computers. Als Software bezeichnet

Mehr

Einführung in die Informatik

Einführung in die Informatik Einführung in die Informatik Softwareentwicklung Probleme bei großer Software Life-Cycle-Modelle Teilphasen eines Software-Projekts Methoden und Werkzeuge 01101101 01011001 11010011 10011000 00000011 00011100

Mehr

Korrektheitsbegriffe für modellbasierte Codegeneratoren

Korrektheitsbegriffe für modellbasierte Codegeneratoren Korrektheitsbegriffe für modellbasierte Codegeneratoren Institut für Informatik Martin-Luther-Universität Halle-Wittenberg 9.IT 2 22.06.2006 Dr. Mirko Conrad The MathWorks München Prof. Dr. Wolf Zimmermann

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Projektvorstellung Übung 1 Wiederholung zusammengefasst Planungsphase Lernziele Ziele und Inhalt der Planungsphase Anlass und Aufgabestellung(Was ist dabei erförderlich) Requirement Engineering

Mehr

Rhapsody in J Modellierung von Echtzeitsystemen

Rhapsody in J Modellierung von Echtzeitsystemen Rhapsody in J Modellierung von Echtzeitsystemen Tobias Schumacher tobe@uni-paderborn.de Rhapsody in J - Modellierung von Echtzeitsystemen p.1/17 Anspruch des Tools Einsatzbereiche/Features Modellierung

Mehr

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, 01. 02. Dezember 2009 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung

Mehr

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle Diverse Grundlagen Dr. Karsten Tolle Vorgehensmodelle im Software Engineering Wasserfallmodell Rapid Prototyping Spiralmodell V-Modell Rational Unified Process extrem Programming Test Driven Development

Mehr

Microsoft Dynamics NAV Technische Details

Microsoft Dynamics NAV Technische Details Microsoft Dynamics NAV Technische Details INHALT Microsoft Dynamics NAV Technische Details........................................ [3] Infrastruktur.............................................. [3] Systemanforderungen.....................................

Mehr

Programmierung von Kfz Steuergeräten

Programmierung von Kfz Steuergeräten Programmierung von Kfz Steuergeräten Zusammenfassung Der steigende Anteil von Software im Kfz verlagert Entwicklungsaufwendungen und verändert die Entwicklungsprozesse. Den kürzer werdenden Entwicklungszyklen

Mehr

Einführung (0) Erster funktionsfähiger programmgesteuerter Rechenautomat Z3, fertiggestellt 1941 Bild: Nachbau im Deutschen Museum München

Einführung (0) Erster funktionsfähiger programmgesteuerter Rechenautomat Z3, fertiggestellt 1941 Bild: Nachbau im Deutschen Museum München Einführung (0) Erster funktionsfähiger programmgesteuerter Rechenautomat Z3, fertiggestellt 1941 Bild: Nachbau im Deutschen Museum München Einführung (1) Was ist ein Rechner? Maschine, die Probleme für

Mehr

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java Willkommen zur Vorlesung Objektorientierte Programmierung Vertiefung - Java Zum Dozenten Mein Name: Andreas Berndt Diplom-Informatiker (TU Darmstadt) Derzeit Software-Entwickler für Web- Applikationen

Mehr

Embedded Microsystems

Embedded Microsystems Graduiertenkolleg 1103 Embedded Microsystems Albert-Ludwigs-Universität Freiburg Energieeffiziente Automatisierung in verteilten Systemen Statusbericht Peter Hilgers Betreuer: Prof. Dr.-Ing. Christoph

Mehr

Vorlesung Embedded Software-Engineering im Bereich Automotive

Vorlesung Embedded Software-Engineering im Bereich Automotive Vorlesung Embedded Software-Engineering im Bereich Automotive Technische Universität Dresden, Fakultät Informatik, Professur Softwaretechnologie WS 2008/2009 Dr. rer. nat. Bernhard Hohlfeld bernhard.hohlfeld@daad-alumni.de

Mehr

Programmierung, Algorithmen und Techniken. von Thomas Ohlhauser

Programmierung, Algorithmen und Techniken. von Thomas Ohlhauser Programmierung, Algorithmen und Techniken von Thomas Ohlhauser 1. Begriff Programmierung Entwicklung von Programmen inklusive der dabei verwendeten Methoden und Denkweisen. Ein Programm ist eine eine Zusammensetzung

Mehr

When testing meets intelligence MECHATRONIK

When testing meets intelligence MECHATRONIK When testing meets intelligence MECHATRONIK Mechatronik Entwicklungs- und Testzentrum Integrierte Testumgebung für mechatronische Systeme und Strukturen. Mechatronik Durch die Kombination von Mechanik,

Mehr

examen.press Echtzeitsysteme Grundlagen, Funktionsweisen, Anwendungen Bearbeitet von Heinz Wörn

examen.press Echtzeitsysteme Grundlagen, Funktionsweisen, Anwendungen Bearbeitet von Heinz Wörn examen.press Echtzeitsysteme Grundlagen, Funktionsweisen, Anwendungen Bearbeitet von Heinz Wörn 1. Auflage 2005. Taschenbuch. xiv, 556 S. Paperback ISBN 978 3 540 20588 3 Format (B x L): 15,5 x 23,5 cm

Mehr

GEDS Dienstleistungen. Software Engineering

GEDS Dienstleistungen. Software Engineering GEDS Dienstleistungen Software Engineering GEDS Software Engineering Übersicht Leistungen Methoden Vorgehen Projektablauf Technologien Software Engineering Leistungen Auftragsprogrammierung Wir übernehmen

Mehr

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

Eine Entwurfsmethodik für Prozesssteuerungen

Eine Entwurfsmethodik für Prozesssteuerungen Eine Entwurfsmethodik für Prozesssteuerungen Dr.-Ing. U. Brunner, FH Karlsruhe Kurzfassung Die Forderung nach Wiederverwendbarkeit von Softwarekomponenten und der Korrektheitsnachweis bei sicherheitsgerichteten

Mehr

EasyLab: Modell-basierte Software-Entwicklung für mechatronische Systeme

EasyLab: Modell-basierte Software-Entwicklung für mechatronische Systeme EasyLab: Modell-basierte Software-Entwicklung für mechatronische Systeme Prof. Dr.-Ing. habil. Alois Knoll (k@tum.de) Lehrstuhl für Echtzeitsysteme und Robotik Institut für Informatik Technische Universität

Mehr

Der moderne Funktions- und Softwareentwicklungsprozess

Der moderne Funktions- und Softwareentwicklungsprozess Bild 2.6_1 Quelle: ETAS Der moderne Funktions- und Softwareentwicklungsprozess ECU = Electronic Control Unit = Elektronisches Steuergerät Bild 2.6_2 Quelle: Bosch SW-QB = Software- Qualitätsbewertung Zeitlicher

Mehr

PRAKTIKUM REGELUNGSTECHNIK 2

PRAKTIKUM REGELUNGSTECHNIK 2 FACHHOCHSCHULE LANDSHUT Fachbereich Elektrotechnik Prof. Dr. G. Dorn PRAKTIKUM REGELUNGSTECHNIK 2 1 Versuch 2: Übertragungsfunktion und Polvorgabe 1.1 Einleitung Die Laplace Transformation ist ein äußerst

Mehr

Binarloop. Binarloop für die echtzeitfähige und kostengünstige Verifikation hochdynamischer leistungselektronischer Systeme

Binarloop. Binarloop für die echtzeitfähige und kostengünstige Verifikation hochdynamischer leistungselektronischer Systeme für die echtzeitfähige und kostengünstige Verifikation hochdynamischer leistungselektronischer Systeme Funktions- und Sicherheitstests sind unabdingbare Schritte im Entwicklungsprozess leistungselektronischer

Mehr

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

Nahtlose Mechatronik-Toolchain Von der Maschinensimulation bis zum Motorstromregler

Nahtlose Mechatronik-Toolchain Von der Maschinensimulation bis zum Motorstromregler Nahtlose Mechatronik-Toolchain Von der Maschinensimulation bis zum Motorstromregler Jochen Klier AE-Specialists Manager 11/8/2010 2 Agenda Tools für den mechatronischen Systementwurf Soft- und Hardware-Konzepte

Mehr

Einfache Computersteuerung für Modellbahnen

Einfache Computersteuerung für Modellbahnen Einfache Computersteuerung für Modellbahnen Was soll eigentlich mit einem Computer gesteuert werden? Diese Frage muss man sich als erstes stellen: - Man braucht für Ausstellungen einen kompletten automatischen

Mehr

Soft-SPS - Was ist eine SPS?

Soft-SPS - Was ist eine SPS? Soft-SPS - Was ist eine SPS? SPS = Speicherprogrammierbare Steuerung PLC = Programmable Logic Control Ursprünglich elektronischer Ersatz von Relaissteuerungen (Schützsteuerung) 1 Soft-SPS - Relais-Steuerung

Mehr

SOFTWARE-ENTWICKLUNG FÜR EMBEDDED SYSTEMS

SOFTWARE-ENTWICKLUNG FÜR EMBEDDED SYSTEMS SOFTWARE-ENTWICKLUNG FÜR EMBEDDED SYSTEMS Stimmungsbild zu den Herausforderungen bei der Software-Entwicklung für Embedded Systems Motivation In dieser Umfrage geht es um die Entwicklung von Software für

Mehr

VIRTUELLE INTEGRATION UND TEST VON E/E-FAHRZEUGSYSTEMEN

VIRTUELLE INTEGRATION UND TEST VON E/E-FAHRZEUGSYSTEMEN VIRTUELLE INTEGRATION UND TEST VON E/E-FAHRZEUGSYSTEMEN Durch die Methodik der Virtualisierung lässt sich die Softwarequalität entscheidend erhöhen, und zwar bevor eine Zielhardware überhaupt verfügbar

Mehr

Dynamisches Testen von Embedded. Hans Georg Hermann ExpertControl GmbH

Dynamisches Testen von Embedded. Hans Georg Hermann ExpertControl GmbH Dynamisches Testen von Embedded Systemen und Komponenten in Echtzeit Hans Georg Hermann ExpertControl GmbH Blá Balázs Tóth Nti National linstruments t Agenda Testen von Embedded Systemen und Komponenten

Mehr

Robustheit von Baugruppen und Systemen

Robustheit von Baugruppen und Systemen 12. FED-Konferenz Ulm, 16. September 2004 service for microelectronics Referent: Klaus Dittmann Praxisbeispiel: Gegenseitige Beeinflussung von Komponenten einer Baugruppe oder eines Gerätes Entwicklungsbegleitende

Mehr

Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten

Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten

Mehr

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014 Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung Klaus Kusche, September 2014 Inhalt Ziel & Voraussetzungen Was sind abstrakte Datentypen? Was kann man damit grundsätzlich?

Mehr

Programmieren. Wie entsteht ein Programm

Programmieren. Wie entsteht ein Programm Wie entsteht ein Programm 1/9 1. Schritt: Programmentwurf Der wichtigste Teil beim Erstellen eines Programms ist der Programmentwurf. Dabei wird das vorgegebene Problem analysiert, es wird ermittelt, welche

Mehr

Modellbasierte Programmierung einer Simulationskomponente für die KUKA-Robotersteuerung Sunrise

Modellbasierte Programmierung einer Simulationskomponente für die KUKA-Robotersteuerung Sunrise Modellbasierte Programmierung einer Simulationskomponente für die KUKA-Robotersteuerung Sunrise Hochschule Augsburg, Labor für, Prof. Dipl.-Ing. Georg Stark Email: Georg.Stark@hs-augsburg.de Modellbasierte

Mehr

Vorstellung Diplomarbeit

Vorstellung Diplomarbeit Vorstellung Diplomarbeit Entwurf und Implementierung eines BUS-Moduls für das Automatisierungswerkzeug ECU-TEST engineering software test Gliederung Einleitung Überblick Testautomatisierung Kurzvorstellung

Mehr

PARC. Eine virtuelle Echtzeit Entwicklungsumgebung für den Ausbildungsbereich

PARC. Eine virtuelle Echtzeit Entwicklungsumgebung für den Ausbildungsbereich PARC Eine virtuelle Echtzeit Entwicklungsumgebung für den Ausbildungsbereich Andre Köthur und Dr. Norbert Drescher Fachhochschule Südwestfalen 5095 Hagen Haldener Str. 12 Einleitung und Zielsetzung Die

Mehr

Script-Sprache für UPT und MKT-View II / III / IV. Einleitung, Anwendungsfälle, Programmierung. MKT Systemtechnik

Script-Sprache für UPT und MKT-View II / III / IV. Einleitung, Anwendungsfälle, Programmierung. MKT Systemtechnik Einleitung, Anwendungsfälle, Programmierung MKT Systemtechnik Autor: Stand: Ablage: Wolfgang Büscher Dipl.-Ing. Soft- und Hardware-Entwicklung buescher@mkt-sys.de 2015-01-21 (JJJJ-MM-DD) art85133_einfuehrung_mktview_scriptsprache.odp/pdf;

Mehr

Systemen - Testen im Softwarelebenszyklus

Systemen - Testen im Softwarelebenszyklus P r a k t I s c h e Entwicklung und Test Testen von Software-Systemen Systemen - Testen im Softwarelebenszyklus Entwickler erstellen ihr System bzw. ihre Software und testen es/sie zur Entwicklungszeit

Mehr

Codegenerierung für FPGAs aus einem Simulink-Modell (Schritt-für-Schritt-Anleitung)

Codegenerierung für FPGAs aus einem Simulink-Modell (Schritt-für-Schritt-Anleitung) Codegenerierung für FPGAs aus einem Simulink-Modell (Schritt-für-Schritt-Anleitung) Folgende Schritt-für-Schritt-Anleitung zeigt exemplarisch den Arbeitsablauf der HDLCodegenerierung für das Spartan-3E

Mehr

Session 8: Projektvorstellung Transferprojekt itsowl-tt-savez 18. August 2015, Gütersloh. www.its-owl.de

Session 8: Projektvorstellung Transferprojekt itsowl-tt-savez 18. August 2015, Gütersloh. www.its-owl.de Session 8: Projektvorstellung Transferprojekt itsowl-tt-savez 18. August 2015, Gütersloh www.its-owl.de Agenda Abschlusspräsentation itsowl-tt-savez Einführung Zielsetzung Ergebnisse Resümee und Ausblick

Mehr

С Ах für Ingenieure. Springer. Eine praxisbezogene Einführung

С Ах für Ingenieure. Springer. Eine praxisbezogene Einführung Sandor Vajna Christian Weber Helmut Bley Klaus Zeman In Zusammenarbeit mit Peter Hehenberger С Ах für Ingenieure Eine praxisbezogene Einführung 2. völlig neu bearbeitete Auflage Springer Inhalt 1. CAx-Systeme

Mehr

Fachhochschule Köln Fakultät IME - NT Bereich Regelungstechnik Prof. Dr.-Ing. R. Bartz. DSS Diskrete Signale und Systeme.

Fachhochschule Köln Fakultät IME - NT Bereich Regelungstechnik Prof. Dr.-Ing. R. Bartz. DSS Diskrete Signale und Systeme. Fachhochschule Köln Fakultät IME - NT Bereich Regelungstechnik Prof. Dr.-Ing. R. Bartz DSS Diskrete Signale und Systeme Teampartner: Praktikum Versuch 1 Laborplatz: Name: Vorname: Studiengang /-richtung

Mehr

Optimieren von Requirements Management & Engineering

Optimieren von Requirements Management & Engineering Xpert.press Optimieren von Requirements Management & Engineering Mit dem HOOD Capability Model Bearbeitet von Colin Hood, Rupert Wiebel 1. Auflage 2005. Buch. xii, 245 S. Hardcover ISBN 978 3 540 21178

Mehr

Modellbasierte Entwicklung im Kontext von Medizingeräten

Modellbasierte Entwicklung im Kontext von Medizingeräten up FPGA Modellbasierte Entwicklung im Kontext von Medizingeräten Gemeinsamer Ausgangspunkt für Software- und Hardwareentwicklung Osnabrück, 06.02.2014, Wanja Schöpfer Agenda 1 Einleitung 2 Modellbasierte

Mehr

Einführung in die Robotik Regelung. Mohamed Oubbati Institut für Neuroinformatik. Tel.: (+49) 731 / 50 24153 mohamed.oubbati@uni-ulm.de 04. 12.

Einführung in die Robotik Regelung. Mohamed Oubbati Institut für Neuroinformatik. Tel.: (+49) 731 / 50 24153 mohamed.oubbati@uni-ulm.de 04. 12. Einführung in die Robotik Regelung Mohamed Oubbati Institut für Neuroinformatik Tel.: (+49) 731 / 50 24153 mohamed.oubbati@uni-ulm.de 04. 12. 2012 The human is perhaps the most intelligent control system

Mehr

Session 3: Projektvorstellung Transferprojekt itsowl-tt-hapromesy 18. August 2015, Gütersloh. www.its-owl.de

Session 3: Projektvorstellung Transferprojekt itsowl-tt-hapromesy 18. August 2015, Gütersloh. www.its-owl.de Session 3: Projektvorstellung Transferprojekt itsowl-tt-hapromesy 18. August 2015, Gütersloh www.its-owl.de Agenda Abschlusspräsentation itsowl-tt-hapromesy Einführung Zielsetzung Ergebnisse Resümee und

Mehr

Verkürzung von Entwurfszeiten

Verkürzung von Entwurfszeiten Verkürzung von Entwurfszeiten durch Matlab-basiertes HPC R. Fink, S. Pawletta Übersicht aktuelle Situation im ingenieurtechnischen Bereich Multi-SCEs als Konzept zur Verkürzung von Entwurfszeiten Realisierung

Mehr

KOMPETENZ IN SOFTWARE

KOMPETENZ IN SOFTWARE KOMPETENZ IN SOFTWARE Software- und App-Entwicklung Automotive-Software Elektromobilität Collaboration und Business Intelligence BATTERY STATUS BATTERY STATUS c4c engineering GmbH kompetenz in Software,

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

4 Einführung in die Gruppenarbeit Produktstruktur

4 Einführung in die Gruppenarbeit Produktstruktur Bundesamt für Informationsmanagement und Informationstechnik der Bundeswehr 4 Einführung in die Gruppenarbeit Produktstruktur V-Modell XT Anwendung im Projekt

Mehr

Softwareentwicklungsprozesse. 18. Oktober 2012

Softwareentwicklungsprozesse. 18. Oktober 2012 Softwareentwicklungsprozesse 18. Oktober 2012 Überblick Was soll ein Softwareentwicklungsprozess leisten? Überblick über Softwareentwicklungsprozesse Welche gibt es? Warum gibt es mehrere? Diskussion:

Mehr

Data Mining-Projekte

Data Mining-Projekte Data Mining-Projekte Data Mining-Projekte Data Mining stellt normalerweise kein ei nmaliges Projekt dar, welches Erkenntnisse liefert, die dann nur einmal verwendet werden, sondern es soll gewöhnlich ein

Mehr

Algorithmus, siehe (1)

Algorithmus, siehe (1) Der Computer als elektronische Rechenmaschine entstand in den vierziger Jahren des 20. Jahrhunderts. Die Gedankenwelt der Informatik lässt sich aber bedeutend weiter zurückverfolgen. Mit diesem Kapitel

Mehr

In diesem Dokument soll kurz auf die Bedienung von VST3PluginTestHost.exe eingegangen werden.

In diesem Dokument soll kurz auf die Bedienung von VST3PluginTestHost.exe eingegangen werden. Hochschule für Angewandte Wissenschaften Hamburg Hamburg University of Applied Sciences Fakultät Technik und Informatik Department Informations- und Elektrotechnik Projekt E7 im Bachelorstudiengang Informations-

Mehr

Kapitel 6,»Objektorientierte Programmierung«, widmet sich der objektorientierten Programmierung mit Python.

Kapitel 6,»Objektorientierte Programmierung«, widmet sich der objektorientierten Programmierung mit Python. 1.3 Aufbau des Buchs lichkeiten offen. Auf die Unterschiede der beiden Versionen gehe ich besonders ein, sodass ein späterer Umstieg von der einen zur anderen Version leichtfällt. Erste Zusammenhänge werden

Mehr

Firmen Präsentation: Identität

Firmen Präsentation: Identität Firmen Präsentation: Identität ecu-testing definiert sich als Dienstleister im Bereich Testsysteme und Testengineering. Schwerpunkt sind die Open- und Closedloop Testsysteme für die elektronischen Steuergeräte.

Mehr

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells...

Inhaltsverzeichnis. Inhaltsverzeichnis... I. 1 Problemstellung... 1. 2 V-Modell... 1. 2.1 Allgemeines... 1. 2.2 Anwendung des V-Modells... Inhaltsverzeichnis Inhaltsverzeichnis... I 1 Problemstellung... 1 2 V-Modell... 1 2.1 Allgemeines... 1 2.2 Anwendung des V-Modells... 3 3 SCRUM-Modell... 4 3.1 Allgemeines... 4 3.2 Anwendung des SCRUM-Modells...

Mehr

Projekt für Systemprogrammierung WS 06/07

Projekt für Systemprogrammierung WS 06/07 Dienstag 30.01.2007 Projekt für Systemprogrammierung WS 06/07 Von: Hassan Bellamin E-Mail: h_bellamin@web.de Gliederung: 1. Geschichte und Definition 2. Was ist Virtualisierung? 3. Welche Virtualisierungssoftware

Mehr

Einsatz von UML und C++ am Beispiel einer Satelliten-Lageregelungssoftware

Einsatz von UML und C++ am Beispiel einer Satelliten-Lageregelungssoftware Einsatz von UML und C++ am Beispiel einer Satelliten-Lageregelungssoftware Dipl. Inform. Olaf Maibaum DLR, Abt. Simulations- und Softwaretechnik DLR, Abt. Simulations- und Softwaretechnik 1 Übersicht Bird-Satellit

Mehr

Teil VII. Software Engineering

Teil VII. Software Engineering Teil VII Software Engineering Überblick 1 Einführung 2 Der Softwareentwicklungsprozess 3 Methoden und Werkzeuge Eike Schallehn Grundlagen der Informatik für Ingenieure 2008/2009 7 1 Einführung Die Softwarekrise

Mehr

DRIVE LIKE A VIRTUAL DEVELOPER Die Poleposition für Ihre Softwareentwicklung

DRIVE LIKE A VIRTUAL DEVELOPER Die Poleposition für Ihre Softwareentwicklung DRIVE LIKE A VIRTUAL DEVELOPER Die Poleposition für Ihre Softwareentwicklung Was für ein Tempo! Das Rad dreht sich rasant schnell: Die heutigen Anforderungen an Softwareentwicklung sind hoch und werden

Mehr

Software-Engineering 2. Software-Engineering 2. Entwicklungsumgebungen (IDE) IT works. Klaus Mairon www.mairon-online.de 22.03.

Software-Engineering 2. Software-Engineering 2. Entwicklungsumgebungen (IDE) IT works. Klaus Mairon www.mairon-online.de 22.03. Software-Engineering 2 Entwicklungsumgebungen (IDE) IT works. Klaus Mairon www.mairon-online.de 22.03.2009 1 Entwicklungsumgebungen, CASE-Tools, CASE-Werkzeuge unterstützen den Software-Entwicklungsprozess

Mehr

Scheinaufgabe im Fach Web Engineering

Scheinaufgabe im Fach Web Engineering Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut für Verteilte Systeme Scheinaufgabe im Fach Web Engineering Thomas Thüm 07. August 2006 Matrikel: 171046 Lehrveranstaltung: Web

Mehr

Von der UML nach C++

Von der UML nach C++ 22 Von der UML nach C++ Dieses Kapitel behandelt die folgenden Themen: Vererbung Interfaces Assoziationen Multiplizität Aggregation Komposition Die Unified Modeling Language (UML) ist eine weit verbreitete

Mehr

Praktikum Software Engineering: Verfahren und Werkzeuge

Praktikum Software Engineering: Verfahren und Werkzeuge Praktikum Software Engineering: Verfahren und Werkzeuge Lehrstuhl für Software Engineering (Informatik 11) Verfahren und Werkzeuge Seite 1 Software Engineering Absichten, Aufgaben Systemnutzung Anforderungsspezifikation

Mehr

MICHAEL RÜGER. Abschluss Diplom Fach Informatik. Geburtsjahr 1985 Profil-Stand April 2015

MICHAEL RÜGER. Abschluss Diplom Fach Informatik. Geburtsjahr 1985 Profil-Stand April 2015 MICHAEL RÜGER Abschluss Diplom Fach Informatik Geburtsjahr 1985 Profil-Stand April 2015 Triona Information und Technologie GmbH Wilhelm-Theodor-Römheld-Str. 14 55130 Mainz Fon +49 (0) 61 31 9 21-122 Fax

Mehr

Entwicklung einer digitalen Übertragungsstrecke mit Einplatinencomputern zur Signalanalyse

Entwicklung einer digitalen Übertragungsstrecke mit Einplatinencomputern zur Signalanalyse Entwicklung einer digitalen mit Einplatinencomputern zur Signalanalyse Philipp Urban Jacobs p.1 Inhalt 1 Motivation 2 Grundlagen 3 Umsetzung 4 Verifizierung 5 Fazit p.2 Motivation Signalgenerator ADC Gertboard

Mehr

Presseinformation PI 084/14 14.11.2014

Presseinformation PI 084/14 14.11.2014 Rexroth-Steuerungen und -Antriebe offen für IT- und Internet-Programmiersprachen Nächste Evolutionsstufe von Open Core Engineering mit zusätzlichen Kommunikations- und Programmiermöglichkeiten Open Core

Mehr

Einführung in die OPC-Technik

Einführung in die OPC-Technik Einführung in die OPC-Technik Was ist OPC? OPC, als Standartschnittstelle der Zukunft, steht für OLE for Process Control,und basiert auf dem Komponentenmodel der Firma Microsoft,dem Hersteller des Betriebssystems

Mehr

Kursübersicht "Signale und Systeme"

Kursübersicht Signale und Systeme Kursübersicht "Signale und Systeme" SiSy, Einleitung, 1 SiSy HS2014: Zeitplan ET13a Signale analog Systeme analog Signale digital Kursübersicht "Signale und Systeme" SiSy, Einleitung, 2 Unterlagen siehe

Mehr

Test modellbasiert entwickelter Steuergeräte

Test modellbasiert entwickelter Steuergeräte Seite 1 von 31 26. Treffen der GI-Arbeitsgruppe Test, Analyse und Verifikation von Software Stuttgart, den 06.12.2007 Systematischer Test modellbasiert entwickelter Steuergeräte Dipl.-Ing. Matthias Wiese

Mehr

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003):

Professionelles Projektmanagement in der Praxis. Veranstaltung 7 Teil 1 (30.06.2003): Professionelles Projekt-Management in der Praxis Veranstaltung 7 Teil 1 (30.06.2003): Prof. Dr. Phuoc Tran-Gia, FB Informatik, Prof. Dr. Margit Meyer, FB Wirtschaftswissenschaften, Dr. Harald Wehnes, AOK

Mehr

CompuLok Zentrale. Software Interface. Digitalzentrale für DCC und Motorola Format

CompuLok Zentrale. Software Interface. Digitalzentrale für DCC und Motorola Format CompuLok Zentrale Software Interface Digitalzentrale für DCC und Motorola Format Inhalt CompuLok Software Interface... 3 Das Software Interface... 3 Installation... 3 Treiber installieren.... 3 Hinweis

Mehr

Übungsaufgaben zum Software Engineering: Management

Übungsaufgaben zum Software Engineering: Management Übungsaufgaben zum Software Engineering: Management Grundbegriffe: Aufgabe 1: Aus welchen Disziplinen setzt sich das Software Engineering zusammen? a. Informatik b. Physik c. Psychologie d. Chemie e. Geologie

Mehr

Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung

Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung Einsatz der Mehrkörpersimulation in Verbindung mit Computertomographie in der Produktentwicklung Hintergrund Bei komplexen Baugruppen ergeben sich sehr hohe Anforderungen an die Tolerierung der einzelnen

Mehr

Systematisches Testen von Software

Systematisches Testen von Software Programmierung Systematisches Testen von Software Markus Eckstein Systematika Information Systems GmbH Kurfürsten-Anlage 36 69115 Heidelberg markus.eckstein@systematika.com Zusammenfassung Die wichtigsten

Mehr

Der Rechner. Grundbegriffe. Aufbau. Funktionsweise. Betriebssystem. Kategorisierung. PC-Komponenten. Prof. Dr. Aris Christidis

Der Rechner. Grundbegriffe. Aufbau. Funktionsweise. Betriebssystem. Kategorisierung. PC-Komponenten. Prof. Dr. Aris Christidis Der Rechner Grundbegriffe Aufbau Funktionsweise Betriebssystem Kategorisierung PC-Komponenten Auf der Grundlage eines Programms kann ein Computer Daten mit seiner Umgebung austauschen, mathematische und

Mehr

Modellbasierte Softwareentwicklung für automobilspezifische Steuergerätenetzwerke

Modellbasierte Softwareentwicklung für automobilspezifische Steuergerätenetzwerke Modellbasierte Softwareentwicklung für automobilspezifische Steuergerätenetzwerke Christian Schröder Telelogic Deutschland GmbH Bielefeld http://www www.forsoft.de/.de/automotive/ Christian Schröder VDI

Mehr