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

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

Entwicklungsprozesse und -werkzeuge

Entwicklungsprozesse und -werkzeuge Entwicklungsprozesse und -werkzeuge Boris Nikolai Konrad boris.konrad@udo.edu PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Entwicklungsprozesse Unterstützungsprozesse Kernprozess Entwicklungswerkzeuge

Mehr

Die Softwareentwicklungsphasen!

Die Softwareentwicklungsphasen! Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.

Mehr

Übungen zu. Kraftfahrzeugmechatronik II

Übungen zu. Kraftfahrzeugmechatronik II Übungen zu Kraftfahrzeugmechatronik II Software-Entwicklung nach dem V-Modell Übungen Rapid Prototyping und Target Link Quelle: Schäuffele/Zurawka Automotiv Software Engineering vieweg Verlag Umsetzung

Mehr

Simulink - Modelle grafisch vergleichen

Simulink - Modelle grafisch vergleichen Simulink - Modelle grafisch vergleichen Effizienzsteigerung bei der modellbasierten Softwareentwicklung Dr. Helmuth Stahl ExpertControl GmbH Email: hstahl@expertcontrol.com Web: www.expertcontrol.com Übersicht

Mehr

Einführung in CAE-Simulationssysteme

Einführung in CAE-Simulationssysteme Einführung in CAE-Simulationssysteme Einleitung Motivation für CAE-Werkzeuge Modellierung technischer Prozesse Übersicht über CAE-Simulationssysteme Kommerzielle Programme Freeware Funktionsinhalte von

Mehr

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

1. Grundbegriffe des Software-Engineering

1. Grundbegriffe des Software-Engineering 1. Grundbegriffe Software Engineering 1 1. Grundbegriffe des Software-Engineering Was ist Software-Engineering? (deutsch: Software-Technik) Teilgebiet der Informatik, das sich mit Methoden und Werkzeugen

Mehr

Digitale Regelung. Vorlesung: Seminarübungen: Dozent: Professor Ferdinand Svaricek Ort: 33/2211 Zeit:Di 15.00 16.30 Uhr

Digitale Regelung. Vorlesung: Seminarübungen: Dozent: Professor Ferdinand Svaricek Ort: 33/2211 Zeit:Di 15.00 16.30 Uhr Vorlesung: Dozent: Professor Ferdinand Svaricek Ort: 33/2211 Zeit:Di 15.00 16.30 Uhr Seminarübungen: Dozent: Alexander Weber Ort: 33/1101 Zeit: Mo 9.45 11.15 Uhr (Beginn: 20.04.2015) Vorlesungsskript:

Mehr

Vom funktionalen Entwurf mit physikalischer Modellierung bis zum vollständigen Test mechatronischer Systeme in der virtuellen und realen Umgebung

Vom funktionalen Entwurf mit physikalischer Modellierung bis zum vollständigen Test mechatronischer Systeme in der virtuellen und realen Umgebung Vom funktionalen Entwurf mit physikalischer Modellierung bis zum vollständigen Test mechatronischer Systeme in der virtuellen und realen Umgebung Jens Schindler, Andreas Abel ITI GmbH Firmenlogo Agenda

Mehr

FRAUNHOFER-INSTITUT FÜR PRODUKTIONSTECHNOLOGIE IPT PROJEKTGRUPPE ENTWURFSTECHNIK MECHATRONIK

FRAUNHOFER-INSTITUT FÜR PRODUKTIONSTECHNOLOGIE IPT PROJEKTGRUPPE ENTWURFSTECHNIK MECHATRONIK FRAUNHOFER-INSTITUT FÜR PRODUKTIONSTECHNOLOGIE IPT PROJEKTGRUPPE ENTWURFSTECHNIK MECHATRONIK DIE METHODE FÜR DEN SOFTWAREENTWURF VERNETZTER MECHATRONISCHER SYSTEME Innovative Funktionen moderner mechatronischer

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

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

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

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

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

Matlab bis. zum Limit. Hier klicken, um Master-Titelformat zu bearbeiten. Hier klicken, um Master-Textformat zu bearbeiten. Zweite Ebene Dritte Ebene

Matlab bis. zum Limit. Hier klicken, um Master-Titelformat zu bearbeiten. Hier klicken, um Master-Textformat zu bearbeiten. Zweite Ebene Dritte Ebene Matlab bis zum Limit Praxiserfahrungen mit komplexen Simulationen und Analysen unter Matlab / Simulink Dr.-Ing. Gordon Strickert Hier klicken, Matlab um Master-Titelformat? Was ist Matlab Matrix Laboratory

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

Rapid Prototyping mit CANape Version 1.0 2010-11-22

Rapid Prototyping mit CANape Version 1.0 2010-11-22 Version 1.0 2010-11-22 Inhaltsverzeichnis 1.0 Übersicht...3 2.0 Funktionsentwicklung mit MATLAB...4 3.0 Simulink als Ablaufumgebung CANape als komfortable Bedienoberfläche...4 4.0 CANape als Ablaufumgebung...5

Mehr

Model-Based Design für AUTOSAR Komponenten

Model-Based Design für AUTOSAR Komponenten W H I T E P A P E R Model-Based Design für AUTOSAR Komponenten Autoren: Guido Sandmann Automotive Marketing Manager EMEA Dr. Hans Martin Ritt Senior Teamleader Application Engineering Dr. Joachim Schlosser

Mehr

Automotive Software Engineering

Automotive Software Engineering Jörg Schäuffele Thomas Zurawka Automotive Software Engineering Grundlagen, Prozesse, Methoden und Werkzeuge effizient einsetzen 4., überarbeitete und erweiterte Auflage Mit 276 Abbildungen PRAXIS ATZ/MTZ-Fachbuch

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

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

VL2: Softwareprojekt - Anforderungsanalyse. Inhalt. 1. Struktur eines Softwareprojektes

VL2: Softwareprojekt - Anforderungsanalyse. Inhalt. 1. Struktur eines Softwareprojektes Dozent: G.Döben-Henisch (Version vom 16.April 2005) PPmP VL2 VL2: Softwareprojekt - Anforderungsanalyse Inhalt 1. Struktur eines Softwareprojektes 2. Anforderungsanalyse 1. Struktur eines Softwareprojektes

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

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

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

Entwicklungsprozesse. und -werkzeuge

Entwicklungsprozesse. und -werkzeuge Entwicklungsprozesse und -werkzeuge Ausarbeitung für die Einführungsveranstaltung zur Projektgruppe Autolab am Fachbereich 4 (Informatik) an der Universität Dortmund im Wintersemester 2007 / 2008 Der zugehörige

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

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

Ü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

Inhaltsverzeichnis 1 Einführung und Überblick 2 Grundlagen

Inhaltsverzeichnis 1 Einführung und Überblick 2 Grundlagen IX 1 Einführung und Überblick... 1 1.1 Das System Fahrer-Fahrzeug-Umwelt... 2 1.1.1 Aufbau und Wirkungsweise elektronischer Systeme... 2 1.1.2 Elektronische Systeme des Fahrzeugs und der Umwelt... 5 1.2

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

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

Der Design- und Verifizierungsprozess von elektronischen Schaltungen. Y Diagramm

Der Design- und Verifizierungsprozess von elektronischen Schaltungen. Y Diagramm Der Design- und Verifizierungsprozess von elektronischen Schaltungen Y Diagramm Verhaltens Beschreibung Struktur Beschreibung z.b. Vout =Vin/2 Analog: Teiler Digital: Schieberegister Widerstand oder Mosfet

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

IT-Projekt-Management

IT-Projekt-Management IT-Projekt-Management email: vuongtheanh@netscape.net http: www.dr-vuong.de 2005 by, Bielefeld Seite 1 Vorgehensmodell 2005 by, Bielefeld Seite 2 Was ist ein Vorgehensmodell? Strukturbeschreibung über

Mehr

Development Tools for 16/32 Bit Microcontroller

Development Tools for 16/32 Bit Microcontroller Praktika- und Diplomthemen bei Stand 01/2013 Die nachfolgend aufgeführten Themen sind Vorschläge und können in Absprache mit dem Praktikanten / Diplomanden sowie der Hochschule modifiziert werden. Die

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

Ansteuerung Versuchsstand Einfachpendel

Ansteuerung Versuchsstand Einfachpendel 4 6 Fachgebiet Regelungstechnik Leiter: Prof. Dr.-Ing. Johann Reger Ansteuerung Versuchsstand Einfachpendel 1 Echtzeitverarbeitungssystem Host-PC Simulink Modell Code Generierung Echtzeitcode ControlDesk

Mehr

C/C++ Entwickler Embedded Systems (m/w)

C/C++ Entwickler Embedded Systems (m/w) Sie sind ein begeisterter C++ Entwickler und brennen darauf, Ihr Können in die Entwicklung innovativer Produkte auf der Basis von Embedded Linux einzubringen? Bei uns entwickeln Sie in einem dynamischen

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

Software-Engineering

Software-Engineering SWE5 Slide 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 5: Systementwurf SWE5 Slide 2 Systemanalyse vs. Softwareentwurf Systemanalyse beschreibt das System der Anwendung, für das eine Aufgabe

Mehr

Integrierte, universelle Entwicklungsplattform für die fahrzeugbezogene Applikationsentwicklung mit Schnittstellen für FlexRay, CAN, LIN und K-Line

Integrierte, universelle Entwicklungsplattform für die fahrzeugbezogene Applikationsentwicklung mit Schnittstellen für FlexRay, CAN, LIN und K-Line Integrierte, universelle Entwicklungsplattform für die fahrzeugbezogene Applikationsentwicklung mit Schnittstellen für FlexRay, CAN, LIN und K-Line In zunehmendem Maße finden heute PC-basierte Entwicklungs-

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

OSEK-OS. Oliver Botschkowski. oliver.botschkowski@udo.edu. PG AutoLab Seminarwochenende 21.-23. Oktober 2007. AutoLab

OSEK-OS. Oliver Botschkowski. oliver.botschkowski@udo.edu. PG AutoLab Seminarwochenende 21.-23. Oktober 2007. AutoLab OSEK-OS Oliver Botschkowski oliver.botschkowski@udo.edu PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Einleitung Motivation Ziele Vorteile Einführung in OSEK-OS Architektur Task Management Interrupt

Mehr

Methodik der Modellbasierten Systementwicklung

Methodik der Modellbasierten Systementwicklung Methodik der Modellbasierten Systementwicklung Donnerstag, 13.11.2014 Prof. Dr.-Ing. habil. Klaus Panreck Institutsmitglieder Prof. Dr.-Ing. habil. Klaus Panreck Mess- und Regelungstechnik seit 2011 Prof.

Mehr

Softwaretechnik. Fomuso Ekellem WS 2011/12

Softwaretechnik. Fomuso Ekellem WS 2011/12 WS 2011/12 Inhalt Wiederholung Weitere Begriffe Programmierung im Großem (Programmierung von Software als Ganzes) Prozess-Modelle 2 Wiederholung: Prozesse Prozesse sind hierarchische Gruppierungen von

Mehr

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Prof. Dr. Wilhelm Schäfer Paderborn, 15. Dezember 2014 Christian Brenner Tristan Wittgen Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Aufgabe 1 Codegenerierung

Mehr

Informationssystemanalyse Use Cases 11 1

Informationssystemanalyse Use Cases 11 1 Informationssystemanalyse Use Cases 11 1 Use Cases Slide 1 Als ein populäres Mittel um Anforderungen zu erfassen und Systeme zu beschreiben, werden Use Cases benutzt. Sie bilden die Basis für eine umfassendere

Mehr

Erfolgreicher Einsatz von modellbasierter Softwareentwicklung - Praxisbericht

Erfolgreicher Einsatz von modellbasierter Softwareentwicklung - Praxisbericht Platz für ein Bild (optional) Erfolgreicher Einsatz von modellbasierter Softwareentwicklung - Praxisbericht 1.0 1.1 Elektronik? Was heisst modellbasierte Software-Entwicklung für uns? Was sind für eine

Mehr

Detaillierte Abschlussarbeiten

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

Mehr

Modellbasierte Entwicklung mechatronischer Systeme mit automatischer Codegenerierung für Cortex-Mx-Controller

Modellbasierte Entwicklung mechatronischer Systeme mit automatischer Codegenerierung für Cortex-Mx-Controller Modellbasierte Entwicklung mechatronischer Systeme mit automatischer Codegenerierung für Cortex-Mx-Controller Bastian Schindler, Christian Bartl, Jens Baumbach, Veit Zöppig drivexpert GmbH Kurzvorstellung

Mehr

Anforderungsanalyse, Requirements Engineering

Anforderungsanalyse, Requirements Engineering Anforderungsanalyse, Requirements Engineering, Lastenheft, Pflichtenheft, Spezifikation, Zielgruppen Natürliche Sprache, Formulare Pflichtenheft, an ein Pflichtenheft von Funktionale, nicht-funktionale

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

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

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

Einführung in Generatives Programmieren. Bastian Molkenthin

Einführung in Generatives Programmieren. Bastian Molkenthin Einführung in Generatives Programmieren Bastian Molkenthin Motivation Industrielle Entwicklung *!!*,(% % - #$% #!" + '( & )!* Softwareentwicklung Rückblick auf Objektorientierung Objektorientierte Softwareentwicklung

Mehr

1. Hochschulübergreifende Strategische Initiative

1. Hochschulübergreifende Strategische Initiative 1. Hochschulübergreifende Strategische Initiative Das Projekt Gebäudeautomation, Energieeffizienz und alternative Energiegewinnung vereinigt die Fachbereiche nachhaltige Gebäudetechnik, vernetzte Automation,

Mehr

Vortrag von: Ilias Agorakis & Robert Roginer

Vortrag von: Ilias Agorakis & Robert Roginer MDA Model Driven Architecture Vortrag von: Ilias Agorakis & Robert Roginer Anwendungen der SWT - WS 08/09 Inhalt Was ist MDA? Object Management Group (OMG) Ziele Konzepte der MDA Werkzeuge Vor- und Nachteile

Mehr

EMBEDDED SYSTEMS. Medien zwischen Technologie und Gesellschaft. Universität zu Köln Prof. Dr. Manfred Thaller. Maximilian Berndt WS 12/13

EMBEDDED SYSTEMS. Medien zwischen Technologie und Gesellschaft. Universität zu Köln Prof. Dr. Manfred Thaller. Maximilian Berndt WS 12/13 EMBEDDED SYSTEMS Universität zu Köln Prof. Dr. Manfred Thaller Medien zwischen Technologie und Gesellschaft Maximilian Berndt WS 12/13 Überblick 2 1) Grundlagen: Was sind eingebettete Systeme? 2) Software

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

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

Ü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

Pflichtenheft Großes Projekt Messdatenverarbeitung Aufbau eines digitalen Gitarrenstimmgerätes

Pflichtenheft Großes Projekt Messdatenverarbeitung Aufbau eines digitalen Gitarrenstimmgerätes Pflichtenheft Großes Projekt Messdatenverarbeitung Aufbau eines digitalen Gitarrenstimmgerätes Max Mustermann (000 0006), Bea Beispiel (000 007) 23.02.2010 1 Projektziel Ziel des Projektes ist der Aufbau

Mehr

SE Besprechung. Übung 3 Softwareprozesse

SE Besprechung. Übung 3 Softwareprozesse SE Besprechung Übung 3 Softwareprozesse SE, 08.11.11 Mengia Zollinger Analyse der Systemkomponenten(3 Punkte) Mögliche Ansätze: 3-Schichten-Architektur (tree-tier-architecture) Präsentation Anwendungslogik

Mehr

Software, Services & Success

Software, Services & Success Unser Team sucht für den Standort Stuttgart einen Diplomand Softwareentwicklung (m/w) Thema: Regelbasierte Messdatenauswertung Im Verlauf der Entwicklung und der Integration von neuen Automotive-Steuergeräten

Mehr

Abschluss- und Studienarbeiten. Entwicklung. Elektrik / Elektronik

Abschluss- und Studienarbeiten. Entwicklung. Elektrik / Elektronik Entwicklung Elektrik / Elektronik Ihr Ansprechpartner: ANDREAS STIHL AG & Co. KG Personalmarketing Andreas-Stihl-Str. 4 71336 Waiblingen Tel.: 07151-26-2489 oder über: www.stihl.de www.facebook.com/stihlkarriere

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

EINE MODULARE TESTPLATTFORM FÜR DAS PROTOTYPING VON DRAHTLOSEN SYSTEMEN

EINE MODULARE TESTPLATTFORM FÜR DAS PROTOTYPING VON DRAHTLOSEN SYSTEMEN EINE MODULARE TESTPLATTFORM FÜR DAS PROTOTYPING VON DRAHTLOSEN SYSTEMEN Einleitung Zunehmender Einsatz von Kurzstreckenfunk in Form drahtloser Datenkommunikation im Bereich IEEE Standard 802.15.4 - Zigbee

Mehr

Softwaretechnik (Allgemeine Informatik) Überblick

Softwaretechnik (Allgemeine Informatik) Überblick Softwaretechnik (Allgemeine Informatik) Überblick 1 Einführung und Überblick 2 Abstraktion 3 Objektorientiertes Vorgehensmodell 4 Methoden der Anforderungs- und Problembereichsanalyse 5 UML-Diagramme 6

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

6 Produktqualität Systeme: Integrationstest [sehr stark gekürzt]

6 Produktqualität Systeme: Integrationstest [sehr stark gekürzt] 1 Software-Qualitätssicherung 2 Integrationsstrategien big bang 6 Produktqualität Systeme: Integrationstest [sehr stark gekürzt] nicht-inkrementell geschäftsprozeßorientiert Prof. Dr. Helmut Balzert Lehrstuhl

Mehr

C++11 C++14 Kapitel Doppelseite Übungen Musterlösungen Anhang

C++11 C++14 Kapitel Doppelseite Übungen Musterlösungen Anhang Einleitung Dieses Buch wendet sich an jeden Leser, der die Programmiersprache C++ neu lernen oder vertiefen möchte, egal ob Anfänger oder fortgeschrittener C++-Programmierer. C++ ist eine weitgehend plattformunabhängige

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

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

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software

Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Musteraufbau eines Anforderungsprofils zur Einführung neuer Software Ottostr. 15 96047 Bamberg Tel. +49/951/98046200 Fax +49/951/98046150 email: info@softcondev.de www: softcondev.de INHALT Vorwort Diese

Mehr

Realisierung eines Getriebe- HiL mit VeLoDyn, NI PXI RT- System und NI VeriStand

Realisierung eines Getriebe- HiL mit VeLoDyn, NI PXI RT- System und NI VeriStand Realisierung eines Getriebe- HiL mit VeLoDyn, NI PXI RT- System und NI VeriStand NI-Automotive-Technologietag Benjamin Grote Wolfsburg, 25.05.2011 Innovationen in Serie Inhalt NI-Automotive-Technologietag

Mehr

Regelungs- und Systemtechnik 1. Kapitel 1: Einführung

Regelungs- und Systemtechnik 1. Kapitel 1: Einführung Regelungs- und Systemtechnik 1 Kapitel 1: Einführung Prof. Dr.-Ing. Pu Li Fachgebiet Simulation und Optimale Prozesse (SOP) Luft- und Raumfahrtindustrie Zu regelnde Größen: Position Geschwindigkeit Beschleunigung

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

intence automotive electronics Ausführbare Spezifikation Der Weg zu besseren Anforderungen

intence automotive electronics Ausführbare Spezifikation Der Weg zu besseren Anforderungen intence automotive electronics Ausführbare Spezifikation Der Weg zu besseren Anforderungen Kurzvorstellung intence Agenda KURZVORSTELLUNG intence automotive electronics Wurde 2007 gegründet und ist Entwicklungspartner

Mehr

Echtzeit- und Regelungstechnische Aspekte bei der automatischen Transformation von Matlab/Simulink in SPS-basierten Steuerungscode

Echtzeit- und Regelungstechnische Aspekte bei der automatischen Transformation von Matlab/Simulink in SPS-basierten Steuerungscode PEARL Workshop 2007 06.12.2007 Echtzeit- und Regelungstechnische Aspekte bei der automatischen Transformation von Matlab/Simulink in SPS-basierten Steuerungscode, Dipl.-Ing. Andreas Wannagat, Prof. Dr.-Ing.

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

Coma I. Einleitung. Computer und Algorithmen. Programmiersprachen. Algorithmen versus Programmiersprachen. Literaturhinweise

Coma I. Einleitung. Computer und Algorithmen. Programmiersprachen. Algorithmen versus Programmiersprachen. Literaturhinweise Coma I Einleitung 1 Computer und Algorithmen Programmiersprachen Algorithmen versus Programmiersprachen Literaturhinweise 2 Computer und Algorithmen Programmiersprachen Algorithmen versus Programmiersprachen

Mehr

16 Architekturentwurf Einführung und Überblick

16 Architekturentwurf Einführung und Überblick Teil III: Software-Architekturentwurf 16 Architekturentwurf Einführung und Überblick 16.1 Software entwerfen Warum? Beim Arbeiten im Kleinen nicht oder nur ansatzweise (Detailentwurf) Größere Software

Mehr

Model Driven Architecture (MDA)

Model Driven Architecture (MDA) Model Driven Architecture (MDA) Vortrag im Fach Software Engineering II BA Mannheim / Fachrichtung Angewandte Informatik Torsten Hopp Gliederung Einleitung Motivation Grundzüge der MDA Ziele & Potenziale

Mehr

Grundlagen der Programm- und Systementwicklung

Grundlagen der Programm- und Systementwicklung Grundlagen der Programm- und Systementwicklung Technische Universität München Institut für Informatik Software & Systems Engineering Prof. Dr. Dr. h.c. Manfred Broy Unter Mitarbeit von Dr. Maria Spichkova

Mehr

Modellbasierte Funktionsentwicklung für Komfortsteuergeräte

Modellbasierte Funktionsentwicklung für Komfortsteuergeräte Modellbasierte Funktionsentwicklung für Komfortsteuergeräte Vorgehensweise, Ergebnisse und Potenziale Torsten Klein Business Team Manager Modellbasierte Entwicklung Internationale Zuliefererbörse, Wolfsburg,

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Einführung in die Programmierung der Schnittgrößenermittlung am Einfeldträger. 7.12.2012 J. Lange

Einführung in die Programmierung der Schnittgrößenermittlung am Einfeldträger. 7.12.2012 J. Lange Einführung in die Programmierung der Schnittgrößenermittlung am Einfeldträger 7.12.2012 J. Lange 1 Vorstellung Dr.-Ing. Johannes Lange Softwareentwicklung, Organisation Projekt-, Qualitätsmanagement CAD

Mehr

Softwarepraktikum SS 2005 Inhalt - VL 10. Softwaretechnik. Softwareentwicklungszyklus (2) Wasserfallmodell. Softwareentwicklungszyklus

Softwarepraktikum SS 2005 Inhalt - VL 10. Softwaretechnik. Softwareentwicklungszyklus (2) Wasserfallmodell. Softwareentwicklungszyklus Softwarepraktikum SS 2005 Inhalt - VL 10 1 Softwaretechnik 2 Anforderungsanalyse 3 Systemmodelle Softwaretechnik Technische Disziplin, mit dem Ziel, kosteneffektiv Softwaresysteme zu entwickeln Techniken

Mehr

Modellbasierte und komponentenorientierte Programmierung von Steuerungen

Modellbasierte und komponentenorientierte Programmierung von Steuerungen Labor für CIM & Robotik Prof. Dipl.-Ing. Georg Stark Modellbasierte und komponentenorientierte Programmierung von Steuerungen 1. Entwicklungsprozess Industriesteuerung 2. Programmierparadigmen - objektorientiert

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

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12 Vertretung von Prof. Dr. Blume WS 2011/12 Inhalt Test, Abnahme und Einführung Wartung- und Pflegephase gp Vorlesung Zusammenfassung Produkte und Recht (Folien von Prof. Blume) 2 , Abnahme und Einführung

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

Modul "Automatisierungstechnik Anwendungen" Projektaufgaben:

Modul Automatisierungstechnik Anwendungen Projektaufgaben: Modul "Automatisierungstechnik Anwendungen" Das Modul dient der Entwicklung praktischer und methodischer Fähigkeiten zur Bearbeitung und Lösung automatisierungstechnischer Aufgabenstellungen. Die Planung,

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

Carl von Ossietzky Universität Oldenburg Fachbereich 10 Informatik

Carl von Ossietzky Universität Oldenburg Fachbereich 10 Informatik Carl von Ossietzky Universität Oldenburg Fachbereich 10 Studienordnung Schwerpunkt Systeme im Rahmen der Studiengänge Diplom- BSc in Beschlossen in der Fachbereichsratssitzung am 03.07.2002 1. Der Schwerpunkt

Mehr

Im Folgenden erhalten Sie eine kurze Beschreibung unseres Unternehmens sowie unsere aktuellen Praktikumangebote.

Im Folgenden erhalten Sie eine kurze Beschreibung unseres Unternehmens sowie unsere aktuellen Praktikumangebote. Sehr geehrte Damen und Herren, Im Folgenden erhalten Sie eine kurze Beschreibung unseres Unternehmens sowie unsere aktuellen Praktikumangebote. Einige Infos über unsere Firma: Unser Unternehmen, ACTIMAGE,

Mehr

17 Architekturentwurf Vorgehen und Dokumentation

17 Architekturentwurf Vorgehen und Dokumentation 17 Architekturentwurf Vorgehen und Dokumentation 17.1 Einbettung Aber Erster Schritt der Lösung Wenn Anforderungsspezifikation vorliegt Vorgabe für Codierung Hierarchische Verzahnung von Anforderungen

Mehr