International DSP Conference. Blockset für pneumatische Systeme. Programmierung von Steuergeräten. X-by-Wire. Vermessung von Mobilfunk- Radiokanälen

Größe: px
Ab Seite anzeigen:

Download "International DSP Conference. Blockset für pneumatische Systeme. Programmierung von Steuergeräten. X-by-Wire. Vermessung von Mobilfunk- Radiokanälen"

Transkript

1 select Ausgabe 1/03 Das Kundenmagazin von The MathWorks Blockset für pneumatische Systeme Programmierung von Steuergeräten X-by-Wire Vermessung von Mobilfunk- Radiokanälen Analyse von CTGs Portfolio Management System Enbedded Targets International DSP Conference select 1/01

2 Editorial Uns freut besonders das gestiegene Interesse von Kunden, Anwenderberichte in select veröffentlichen zu wollen. Das Spektrum dieser Artikel spiegelt den breiten Einsatz unserer Produktfamilie in den verschiedensten Industriezweigen wider. So finden sich in dieser Ausgabe Beiträge aus folgenden Bereichen: Anlagenbau, Automobilindustrie, Financial Engineering, Medizintechnik Messtechnik und Telekommunikation. Allen Autoren ein herzliches Dankeschön. Sie halten eine neue Ausgabe von select in Ihren Händen. select bietet uns die Möglichkeit, Ihnen den Einsatz unserer Produkte ganz konkret anhand realer Anwendungen zu präsentieren. Auf diesem Wege hoffen wir auch diesmal wieder, Ihr Interesse an vielen Themen rund um die - Produktfamilie zu wecken. Trotz wirtschaftlich schwierigen Zeiten freuen wir uns über stetig steigende Anwenderzahlen. The MathWorks sieht dies als Aufforderung, die Produktpalette ständig zu erweitern und zu verbessern. Außerdem freuen wir uns im Gegensatz zu vielen anderen Softwareanbietern, die Personal abbauen auch in diesen Zeiten unser Team ständig erweitern zu können. Um Sie über technologische Neuigkeiten und Einsatzmöglichkeiten unserer Produktfamilie auf dem Laufenden zu halten, haben wir neben select unseren Kunden- Informationsprozess um ein wichtiges Medium erweitert: Ab sofort führen wir in regelmäßigen Abständen Webinare durch. In den Webinaren werden praxisorientiert verschiedene Einsatzmöglichkeiten unserer Produkte bezogen auf industrielle Anwendungsfelder präsentiert. Das jeweils aktuelle Programm finden Sie auf unserer Web-Site. Die Webinare bieten Kunden und Interessenten eine bequeme Möglichkeit, sich über unsere Produkte und deren Anwendungsfelder zu informieren. Sie benötigen nur einen Internet-Zugang am Arbeitsplatz und etwa 90 Minuten Zeit. Wir haben uns dieses Jahr zur Teilnahme an der Hannover Messe vom April entschieden und sind der CeBIT bewusst ferngeblieben. Wir mussten in den vergangenen Jahren wie viele andere Aussteller auch feststellen, dass Kosten und Nutzen in immer ungünstigerem Verhältnis standen. Wir konzentrieren uns deshalb zukünftig mehr auf anwendungsbezogene Veranstaltungen mit zielgerichtetem Publikum. In diesem Zusammenhang freuen wir uns auf unsere dritte International DSP Conference am Mai in Stuttgart, zu der wir Sie recht herzlich einladen. Viel Freude beim Lesen Ihr Andreas Schindler 1

3 Inhalt Editorial 1 Intern Neue Student Version 3 International DSP Conference Hannover Messe 5 Anwendungen Simulink-Blockset für pneumatische Systeme 6 Model Based Design von Fahrzeugelektronik-Systemen auf Steuergeräten 11 X-by-Wire Systementwicklung in Simulink 16 Verteilte Simulation 21 Vermessung von Mobilfunk-Radiokanälen 25 SCORT- Ein neuer Bluetooth-Pakettyp 30 Automatische Analyse von vorgeburtlichen Herzfrequenzsignalen (CTG) 32 Portfolio Management System 34 xpc Target Team von Echtzeit-Künstlern 36 Schlaglichter Produkte in der Welt: Industrieller Anlagenbau und Automation 40 Update: Embedded Targets 42 Produktübersicht 44 Tipps&Tricks Tipps & Tricks 46 Buchtipps 47 Termine Karriere 49 Termine 50 Faxantwort 52 IMPRESSUM Herausgeber The MathWorks GmbH Geschäftsführung Andreas Schindler Redaktion Thomas Andraczek Eigene Beiträge Thomas Andraczek, Cord Elias, Andreas Goser, Sven Janssen, Wolfgang Schweizer Kontakt Thomas Andraczek Gestaltung formwerk.ac Druck Gatzen Druck Auflage Das Magazin und alle darin enthaltenen Beiträge und Abbildungen sind urheberrechtlich geschützt. Kopieren und Nachdruck nicht gestattet; Ausnahmen nur mit ausdrücklicher Genehmigung. The MathWorks GmbH Aachen: Friedlandstraße 18, Aachen Tel.: Fax: München: Siedlerstraße 2, Unterföhring Tel.: Fax: Schweiz: The MathWorks GmbH Schürmattstraße 6+8, CH-3073 Gümlingen Tel.: Fax:

4 Intern Neue Student Version Stand Release 13 Mit der neuen Student Version des Release 13 unterstützt The MathWorks Studenten mit modernsten Berechnungswerkzeugen. Die aktuelle Version unterstützt Windows und erstmals in Europa auch die Linux- und MacOSX-Plattform. Das Release enthält die aktuellen Versionen 6.5 und Simulink 5 sowie die Symbolic Math Toolbox als Komplettpaket. Mit der MAT- LAB Student Version erhalten Studenten zwei Bücher, die ihnen den Start erleichtern und eine Einführung in die Programme geben: Learning und Learning Simulink. Mit 6.5 profitieren die Studenten von s neuer JIT-Technologie, mit der komplexe technische und wissenschaftliche Anwendungen bis zu einhundertmal schneller ausgeführt werden. Simulink 5 bietet Mehrdomänen-Fähigkeiten für die Modellierung, Simulation und Analyse mechanischer und elektrischer Systeme. Zusätzlich werden für Studenten weitere spezielle Anwendungsprogramme angeboten. Einsatz der Student Version Die Studentenversion soll dazu dienen, vorlesungs- bzw. übungsbegleitende Aufgaben zuhause zu lösen, die von den Dozenten an Hochschulen erarbeitet und vergeben werden. Studenten können somit im privaten Umfeld als Ergänzung zu Vorlesungen und Übungen die gleichen Produkte, die in Lehre und Industrie Verwendung finden, einsetzen, um ihre Studien in verschiedensten Bereichen wie Elektrotechnik, Maschinenbau, Chemie, Mathematik, Physik und Wirtschaft zu vervollständigen. Neue Version unterstützt auch Mac OS X- und Linux-Systeme Erwerb der Student Version Der Erwerb ist Studenten mit einer gültigen Immatrikulationsbescheinigung vorbehalten. Der professionelle und kommerzielle Einsatz der Studentenversion ist untersagt. Sie darf im Rahmen einer Studien- oder Diplomarbeit eingesetzt werden, sofern sie dabei nicht an der Hochschule oder in der Industrie oder in Zusammenarbeit mit der Industrie verwendet wird. Der Vertrieb in Deutschland erfolgt über die Firma asknet in Karlsruhe, (https:// academic.softwarehouse.de/cgi-bin/ product/p11756), der Preis liegt bei Euro 87,00 inkl. MwSt. und umfasst die CD-ROM sowie einen Satz Handbücher. Dozenten haben die Möglichkeit, über die sogenannte Instructor Evaluation Copy die Studentenversion kennenzulernen. Sollte eine größere Anzahl Studenten an der seminarbegleitenden Studentenversion Interesse haben, bieten wir im Rahmen der sogenannten Student Group License günstigere Konditionen an. So kosten z.b Lizenzen Euro 62,00 pro Stück, zzgl. MwSt. Weitere Staffelpreise erhalten Sie gerne auf Anfrage. Jeder Student erhält einen eigenen Datenträger, die Dokumentation befindet sich online auf einer Dokumentations-CD. Setzen Sie sich mit uns in Verbindung: oder telefonisch unter Neue Education Web-Site Zusätzlich zur Student Version unterstützt The MathWorks weltweit Hochschullehrer und Studenten mit der Einführung der Education Web Site (www. mathworks.de/education), die interessante Quellen und Hilfsmittel bereithält. Das Student Center hilft Studenten Schritt-für- Schritt beim Einstieg in und Simulink. Des weiteren bietet es Links zu Stellenangeboten auf der ganzen Welt, für die -Kenntnisse erforderlich sind, sowie Informationen über die Produktfamilie. Das Faculty Center, eine Quellensammlung für Lehrende, enthält sowohl Links zu auf basierenden Lehrmaterialien und empfohlenen Produktgruppen als auch eine Aufstellung der über 500 Lehrbücher zu, die derzeit verlegt werden. 3

5 Intern International DSP Conference 2003 Anwender der -Produktfamilie präsentieren zukunftsweisende Entwicklungsmethoden rund um digitale Signalverarbeitung und ausgewählte Embedded Systems Anwendungen in der Kommunikationsindustrie. Die ersten beiden Konferenzen waren mit jeweils rund 200 Teilnehmern sehr erfolgreich. Der zweitägige Kongress steht unter dem Motto Neue Wege und schnellere Entwicklungsprozesse in der digitalen Signalverarbeitung. Anwendern aus Europa und den USA dient diese Veranstaltung als Forum zum Austausch über innovative Lösungsansätze und erfolgreich beschrittene Wege unter Nutzung der -Produktfamilie. Namhafte Hersteller und Zulieferer aus aller Welt, darunter in diesem Jahr u.a. EADS, Siemens, Xilinx, Altera und Texas Instruments stellen im Rahmen der Konferenz den erfolgreichen Einsatz von -Produkten als Entwicklungsplattform vor. Das Spektrum dieser Vorträge ist breit gefächert. The MathWorks Deutschland veranstaltet bereits zum dritten Mal die International DSP Conference in Deutschland, vom Mai 2003 in der Liederhalle/Schiller-Saal, Stuttgart. Beispielsweise referiert ein Anwender über den Entwurf eines FPGAs zur Verarbeitung von Radar-Signalen. Ein anderer Vortrag schildert die Analyse und Simulation der Übertragungscharakteristik in Funkkanälen bei mobilen Kommunikations- Systemen. Aber auch im biomedizinischen Bereich findet und Simulink seine Anwendung, beispielsweise bei der Entwicklung eines Kommunikations-Interfaces zwischen Gehirn und Computer zur Auswertung von Hirnstrom-Signalen (EEG). Weitere Vorträge behandeln Themen wie die Implementierung von Signalverarbeitungssystemen auf DSPs und FPGAs, das Filterdesign, Echtzeitverarbeitung von Signalen, eine Schnittstelle von Simulink zu SystemC oder die Entwicklung sogenannter Smart Antennas. Experten von The MathWorks USA geben einen Überblick über das neue -Release. Schwerpunkt sind dabei neue Eigenschaften und Funktionserweiterungen für die digitale Signalverarbeitung und Kommunikationstechnik. Die DSP Conference bietet Teilnehmern somit die Möglichkeit, über moderne Technologiekonzepte zu diskutieren und sich gleichzeitig über aktuelle Trends der Entwicklungssoftware zu informieren. Spezielle Anwendungen können an eigens zur Verfügung stehenden PCs getestet werden. Eine Übersicht über das Konferenz-Programm und Teilnahme-Informationen finden Sie unter Begleitend zur DSP Conference veranstaltet The MathWorks eine Fachausstellung. Dort haben Anwender die Gelegenheit, ihre Produkte im -Umfeld zu präsentieren und stehen Interessierten für Fragen und Diskussionen zur Verfügung. Falls Sie Interesse haben, sich als Aussteller auf der DSP Conference zu präsentieren, sprechen Sie uns an. Ansprechpartner: Sven Janssen, Die Teilnahmegebühr (inkl. Konferenzunterlagen, Zugang zur Fachausstellung sowie Verpflegung während der Pausen) beträgt 199 EUR für Teilnehmer aus der Industrie und 119 EUR für Teilnehmer aus Hochschulen (jeweils zzgl. MwSt.). 4

6 H BIELEFELD FH BIELEFELD FH BIELEFELD FH BIELEFELD Studie zu Modellierungsund Simulationswerkzeugen Die Fachhochschule Bielefeld beabsichtigt, eine Studie zum Einsatz von Modellierungs- und Simulationswerkzeugen zu erstellen. Diese wird am Fachbereich für Mathematik und Technik durch Prof. Bachmann betreut. Wichtigste Grundlage ist ein Fragebogen, der im Rahmen der Studie ausgewertet werden soll. The MathWorks unterstützt dieses Vorhaben. Wir freuen uns, wenn Sie zu dieser Studie beitragen möchten. Interessierte Leser können den Fragebogen unter der Internet-Adressehttp://noether.fh-bielefeld.de/ fragebogen ausfüllen. Die Anonymität Ihrer Daten ist in jedem Fall gewährleistet. Nach Abschluss der Fragebogenaktion sendet die FH Bielefeld allen Teilnehmern auf Wunsch eine Auswertung zu. Auch im Namen der FH Bielefeld im voraus ein herzliches Dankeschön an alle Teilnehmer. Die Bedeutung von und Simulink im Bereich industrieller Anlagenbau und Automation steigt stetig. Vor diesem Hintergrund präsentiert sich The MathWorks 2003 erstmalig auf der Hannover Messe. Intern Willkommen zur Hannover Messe! Neben wertvollen und aktuellen Informationen rund um unser gesamtes Produktportfolio bieten wir Ihnen auf der Hannover Messe die Möglichkeit, dem Messe-Trubel zu entkommen. In entspannter Atmosphäre präsentieren wir Ihnen die neuesten Entwicklungen im Umfeld. Anhand vieler praxisnaher Demonstrationsbeispiele, unterstützt durch entsprechende Hardware, haben Sie die Möglichkeit, sich über den neusten Stand unserer Entwicklungswerkzeuge zu informieren. Beispielweise der neuen Industrie- PC Hardware xpc TargetBox, die zusammen mit xpc Target eine Komplettlösung für Rapid Prototyping auf PC-Basis bietet, oder dem neuen SimMechanics 2 für die Modellierung und Simulation mechanischer Komponenten in Simulink. Sie finden uns in der Halle 6 am Stand G 05. Wir freuen uns auf Ihren Besuch! Halle 6, Stand G 05 5

7 Entwicklungssystematik für hoch-dynamische pneumatische Systeme Abb. 1: High Speed Gravity Handler MT9918 der Firma Multitest Die Firma Multitest in Rosenheim ist Marktführer für IC-Handler. Die Durchsatzraten dieser Maschinen und der verwendeten Kontaktierungen werden stark durch die Verfahrgeschwindigkeit der pneumatischen Aktoren bestimmt. In Anlehnung an das Hydraulic Blockset wurde daher für Multitest ein Pneumatic Blockset entwickelt, um die speziellen Nichtlinearitäten pneumatischer Elemente abzubilden. Ziel ist es, Modelle pneumatischer Systeme für das Rapid Prototyping einzusetzen. Die Ausgangssituation Die Simulation pneumatischer Antriebe und Elemente ist bislang nicht unter bzw. Simulink als Toolbox/Blockset verfügbar. Zum Teil liegen an Universitäten und in Unternehmen keine gültigen physikalischen und überzeugenden Modellverifikationen für pneumatische Systeme vor (Ausnahmen siehe Literaturverzeichnis). Statt dessen werden oft rein empirische, teilphysikalische und parametrische Modelle eingesetzt, die maximal im Arbeitspunkt gültig sind. Die Folge ist, dass der Konstrukteur oder Anwendungsentwickler so leider keine Möglichkeit zum Rapid Prototyping hat, um seine Lösungen im Vorfeld zu prüfen und dies daher nicht tun wird. Die Akzeptanz der Simulation auch deshalb gering, weil das Vertrauen in das Modell fehlt. Im Gegensatz zur weitgehend linearen und überwiegend inkompressiblen Hydraulik, für die es das Hydraulic Blockset als Drittanbieter-Produkt zu Simulink gibt, fehlen also in der Pneumatik für den Anwender die Werkzeuge, die Modellgleichungen und die Annahmen, um Kompressibilitäts- und Durchflusseffekte hinreichend zuverlässig im gesamten Arbeitsbereich abzubilden. Insbesondere fehlt die Berücksichtigung der Temperatur in den Simulationsgleichungen. Verschiedene Pneumatikhersteller bieten eindimensionale Zylindersimulationen, aber nur für ihre eigenen Ventilkomponenten. Die zugehörigen Berechnungen sind nicht erweiterbar, arbeiten größtenteils nur pneumatisch stationär und sind demzufolge für richtige Entwicklungsarbeiten nicht verwendbar. Der Anwender kann die Ergebnisse nicht nachvollziehen und nicht in sein Gesamtsystem einbinden. Im folgenden Beitrag wird die Entwicklungssystematik dargestellt, mit der bei der Firma Multitest in Rosenheim ein neues Prinzip für schnelle Zylinderanwendungen mittels gesteuerter adaptiver Endlagendämpfung untersucht wurde. Zu diesem Zweck wurde ein Pneumatic Blockset für Simulink entwickelt. Die Funktionsblöcke dieser Bibliothek repräsentieren verschiedene pneumatische Komponenten, die zu einem pneumatischen Gesamtsystem verschaltet werden können. Der Anwender baut aus Zylindern, Drosseln und Ventilen sein System blockorientiert zusammen und parametriert die Elemente aufgrund der vorhandenen und beim Hersteller gemessenen Daten. Regelungstechnischer Aufbau des Blockset Die physikalischen Modellgleichungen, die den einzelnen Blöcken zugrunde liegen, wurden als gewöhnliche Differentialgleichungen erster Ordnung unter Verwendung von Integratoren so geordnet, dass keine algebraische Schleifen bei der Berechnung der Zustands- und Ausgangsgrößen auftreten. Die Simulation läuft demzufolge stabil und ohne numerische Probleme. Als Blöcke werden Ventile, pneumatische Widerstände, Volumina, Leitungen und Zylinder verwendet, die untereinander sowie mit anderen Simulink-Blöcken verschaltet werden können. 6

8 Die rein pneumatischen Blöcke verwenden als Ein-/Ausgangsgrößen die pneumatischen Zustandsgrößen Druck und Temperatur, kinematische Größen wie Weg, Geschwindigkeit und Beschleunigung sowie die daraus berechnete Größen Massen- oder Volumenstrom. Letztere lassen sich ihrerseits ineinander umrechnen, so dass der Anwender bei Bedarf stets Ausgaben in Normliter/Minute machen kann. Als Ausgangsgrößen der Ventile und Widerstände wurden grundsätzlich Massenströme gewählt, als deren Eingangsgrößen Drücke. Die Drücke sind entweder direkt durch die Druckversorgung gegeben oder werden durch Leitungen und Zylinder bestimmt, deren Eingangsgrößen pneumatische Massenströme sind. Als kinematische Größen entstehen stets Ventil- und Zylinderbewegungen. Die Ventilbewegungen ändern geometrisch festgelegte Öffnungsquerschnitte und beeinflussen damit direkt nur die Massenströme. Die Zylinderbewegungen ändern über die Geometrie die Volumina und beeinflussen direkt den kompressiblen Druckaufbau. Bei Volumenänderungen muss weiterhin die Art der Temperaturentwicklung ausgewählt werden (adiabatisch oder isotherm), je nachdem ob das System abgeschlossen ist oder ein genügend großer Wärmeaustausch mit der Umgebung erfolgt. Abb. 3: Pneumatic Blockset Beispielanwendung Abb. 2: Schaltplan mit 3/2 Wegeventil Beispielanwendung Der Anwender legt sein System genau so an, wie er es in der Praxis vorfindet. Er kann dabei Schalt- und Servoventile selbst definieren und die Durchfluss- oder Blendencharakteristik wählen. Die Abbildungen 2 und 3 zeigen einen kleinen Ausschnitt eines pneumatischen Schaltplans und die zugehörige Umsetzung mittels Pneumatic Blockset. Folgende Schritte sind notwendig: Zuordnung von Bauteilen zu Bibliothekskomponenten Festlegung von Massenflussknoten (Leitungsknoten) Auswahl von Druckverbindern oder Massenverbindern für die Leitungsknoten Festlegung relevanter konstanter und veränderlicher Volumina Rückführung der kinematischen Größen auf die veränderlichen Volumina. Im Beispiel aus Abbildung 2 werden folgende Bauteile gewählt: 3/2 Wegeventil 2 Drosseln mechanischer Zylinder Druckaufbaublock pro Zylinderkammer Es gibt zwei Leitungsknoten, mit denen die Drosseln zwischen Ventil und Zylinder geschaltet werden. Diese Leitungsknoten entstehen in der Praxis oft durch den Einsatz von Verteilerelementen. Zum Anschluss der Drosseln an das Ventil wird das erste Verteilerelement durch einen Druck-/Massenflussverbinder und das zweite Verteilerelement durch einen reinen Massenflussverbinder (Addierer) abgebildet. Die übrigen Elemente erhalten so alle als Eingangsgrößen pneumatische Drücke. 7

9 Die Drücke des Zylinders werden an beide Drosseln und der erste Verteilerdruck ebenfalls an die Drosseln zurückgeführt. Das Volumen des Zylinders wird an den Druckaufbaublock vor dem Zylinder zurückgeführt. Berücksichtigung der Temperatur und der Kompressibilität der Luft im Druckaufbau Abbildung 4 zeigt stark vereinfacht die grafische Modellierung des nichtlinearen Druckaufbaus in einem Arbeitsvolumen, welches im Pneumatic Blockset immer auf ein einzelnes und zusammenhängendes Volumen bezogen ist. Dieses Volumen wird (vergl. Abb. 3) mit der Summe von Zu- und Abflüssen (Mass In und Mass Out) von Luftmassen beaufschlagt und die Summe aller Zu- und Abgänge bildet zunächst einen von der Volumenänderung entkoppelten Anteil im Druckgradienten (Mass Input Flow). Die Volumenänderung und die Druckänderung selbst sorgen für den kompressiblen Anteil im Druckgradient (Compressiblity Flow). Die Temperaturentwicklung folgt direkt über den ersten Hauptsatz der Thermodynamik aus der Druckentwicklung. Der Anwender legt fest, ob ein nennenswerter Wärmeaustausch mit der Umgebung stattfindet oder nicht, d.h. ob sich die Temperatur im betrachteten Volumen ändert oder einfach gleich bleibend die Umgebungstemperatur annimmt. Ergebnisse für ein Kontaktiersystem als Anwendungsbeispiel der Firma Multitest Für den Multitest High Speed Gravity Handler MT9918 wurden verschiedene Optimierungsprinzipien untersucht, um Alternativen zu bestehenden Ventilprinzipien für die Zukunft zu erarbeiten. Multitest erreicht zur Zeit den am Markt mit Abstand höchsten Durchsatz von ICs bei Gravity Handlern mit ca Bauteilen pro Stunde. Ein Handler verwendet aktuell bis zu 8 Kontaktiersysteme zur parallel synchronen Vereinzelung von Bauteilen und dem anschließenden Bewegungsvorgang der vereinzelten Bauteile zum Loadboard (auf Seite des elektronischen Testsystems). Ein Kontaktiersystem hat stets mehrere mechanische Positionen, die in der Regel über pneumatische Aktoren, Federn und Ventilschaltungen realisiert werden. Unter Verwendung des Pneumatic Blokkset wurde dabei ein Kontaktiersystem in folgendem Arbeitsbereich untersucht: Verfahrzeiten im Bereich von ms Verfahrweg von ca mm Untersuchung verschiedener Ventilanordnungen mit bis zu 16 Ventilen Abb. 4: Druck- und Temperaturaufbau (unvollständige Prinzipdarstellung) 8

10 Abb. 5a: Modellverifikation A (gestrichelt := Simulation, durchgezogen := Messung) in zwei Arbeitspunkten (blau, grün) fernab der Druckstabilitätsgrenze (kleine Massen), Prinzip I Abb. 5b: Modellverifikation B (gestrichelt := Simulation, durchgezogen := Messung) in zwei Arbeitspunkten (blau, grün) nahe der Druckstabilitätsgrenze (große Massen), Prinzip II Abbildung 5 zeigt vier Modellverifikationen für drei Prinzipien, auf denen das gesteuerte aktive Bremsen beruht. Die Parametersensitivität der drei Bremsmethoden ist extrem hoch und die Eigenwerte schwanken sehr stark. (Das Gesamtprinzip unter Prüfung aller drei Prinzipien wurde aus genau diesem Grund verworfen, weil Verfahrzeitschwankungen von +/-2ms! zu unakzeptablem Dämpfungsverhalten führen). Die drei Brems-Prinzipien bringen jeweils zu einem definierten Zeitpunkt einen Druck gegen die Bewegungsrichtung auf und unterscheiden sich durch die Art und Höhe des Bremsdruckes. Der Bremsdruck setzt sich aus den beiden wirksamen Zylinderdrücken Ansteuerdruck und Gegendruck zusammen. Je nachdem ob der Ansteuerdruck weggenommen wird oder nicht, bzw. ob der Gegendruck aufgebracht wird oder beide Drücke weggenommen werden und der Zylinder einfach über die Reibung in Richtung Anschlag ausläuft, variiert der Bremsdruck und damit die Bremscharakteristik. Abb. 5c: Modellverifikation C (gestrichelt := Simulation, durchgezogen := Messung) in drei weit entfernten Arbeitspunkten (blau, grün, rot) fernab der Druckstabilitätsgrenze (kleine Massen), Prinzip I Abb. 5d: Modellverifikation D (gestrichelt := Simulation, durchgezogen := Messung) in zwei fast instabilen Arbeitspunkten (blau, grün) nahe der Druckstabilitätsgrenze (kleine Massen), Prinzip III 9

11 Die Abbildungen 5a und 5c zeigen das Prinzip I, wo der Zylinder ohne Gegendruck ausläuft und machen den Einfluss der Bremszeitänderungen bei Verwendung kleiner Massen sichtbar. In Abbildung 5a sind die Ergebnisse ohne und in Abbildung 5c mit zusätzlichen geschalteten Blenden dargestellt. Die Abbildung 5b zeigt das Prinzip II mit Aufschaltung des Gegendrucks und Abbildung 5d das Prinzip III, bei dem zusätzlich zum aufgeschalteten Gegendruck der Ansteuerdruck weggenommen wird. Die Abbildungen repräsentieren bewusst keine optimalen Einstellungen, sondern belegen die Gültigkeit der Modelle in weit entfernten Arbeitspunkten, die durch Blenden, Bremszeiten, Massen und Höhe des wirksamen Bremsdruckes erreicht werden. Bei dem moderat aussehenden Verfahrvorgang aus Abbildung 5 entstehen Druckgradienten bis 5bar/msec und Drücke im Zylinder bis zum dreifachem Versorgungsdruck. Die Druckgradienten entsprechen den maximal in der Getriebehydraulik auftretenden Druckgradienten der Ölhydraulik. Die Übereinstimmung zwischen Simulation und Messung ist im gesamten Arbeitsbereich sehr gut und es wurden ausdrücklic keine optimierten Parametersätze für die Verifikation verwendet. Durch die Simulation werden physikalische Größen transparent, die entweder gar nicht oder schwer zu messen sind. Dadurch erreicht der Anwender sehr schnell Erklärungen für das Verhalten des Systems und kann Teile des System umkonstruieren. Er kann erklären, wann und wie Vorgänge zeitlich einsetzen. Die Parameter für das Kontaktiersystem wurden im ersten Schritt nach Katalogangaben und im zweiten Schritt durch Volumenflussmessungen der Komponenten ermittelt, um das unter- wie überkritische Verhalten der Drosseln im Durchfluss exakt zu berükksichtigen. Im Verlauf der Arbeiten wurden teilweise Abweichungen von 100% zwischen Katalognennweite und gemessener Nennweite der Ventile festgestellt. Die Hersteller geben also Nennweiten an, die mit Nennweiten pneumatischer Modelle wenig zu tun haben. Das Pneumatic Blockset ermöglicht die Berechnung der pneumatischen Durchflussfunktion und des kritischen Druckverhältnisses aufgrund der gemessenen Durchflusskurven. Auf diese Weise werden Unterdruckeffekte und Überschallgeschwindigkeitseffekte berücksichtigt. Die Simulation auf Basis des Simulink- Modells und zugehöriger Parametrierung bildet die Realität extrem gut ab, da im gesamten Arbeitsbereich des untersuchten mikropneumatischen Kontaktiersystems über alle Massenvariationen und Bremsvariationen ein sehr gute Übereinstimmung mit den Messungen erzielt wird. Dabei erstreckt sich der Arbeitsbereich (vergl. Abb. 5a-5d) von stabil bis instabil und von gedämpft bis ungedämpft. Die Simulation ermöglicht wesentlich geringere Entwicklungszeiten, frühzeitige Vermeidung von Fehlentwicklungen und Kosteneinsparungen im gesamten Vor- und Nachentwicklungszyklus. Autoren: Dr.-Ing. Andreas Piepenbrink, Dipl.-Ing. Max Schaule, Dipl.-Ing. Günther Jeserer Multitest elektronische Systeme GmbH Zusammenfassung Die Simulation pneumatischer Systeme ist insbesondere bei dynamischen Effekten sehr hilfreich und verschafft ein tieferes Verständnis des Systemverhaltens. Sie war jedoch in der Regel bislang unmöglich für den Konstrukteur. Die blockorientierte Simulation in Simulink mit Hilfe des entwickelten Pneumatic Blocksets ermöglicht nun, selbst kleinste und damit sehr anspruchsvolle pneumatische Systeme realitätsnah abzubilden. 10

12 Model Based Design von Fahrzeugelektronik-Systemen auf Universalsteuergeräten der IAV Um auf der Grundlage von fertigen Lösungen sehr schnell mit automotive-tauglichen Steuergeräten ins Fahrzeug zu kommen, hat die IAV die modulare Steuergerätereihe UCU entwickelt. Je nach Projektanforderung und Anwendung können drei verschiedene Baseboards mit drei CPU-Modulen mit unterschiedlicher Rechenleistung kombiniert werden. Die IAV Universal-Steuergeräte (UCUs) werden sowohl im Prototypen Bereich als auch für die Funktionsentwicklung von Seriensoftware (A-Muster Steuergeräte) eingesetzt. Bei diesen Anwendungen ist es wichtig, neue Ideen möglichst schnell auf einem fahrzeugtauglichen Steuergerät seriennah umzusetzen. Dies erfolgt mittels Model Based Design auf der Basis von und Simulink sowie der Automatischen Code-Generierung aus Simulink mit den Universalsteuergeräten der IAV. Diese durchgängige Entwicklungsplattform verleiht die nötige Flexibilität bis in die Schlussphase der Projekte. Die Wiederverwendbarkeit ausgetesteter Software-Module ermöglicht es zudem, sich sehr schnell auf die eigentlichen Requirements des Kunden zu konzentrieren. Die IAV kann im Bereich Prototyping und Vorentwicklung in der Fahrzeugelektronik bereits auf eine mehr als zehnjährige Tradition zurückblicken. Um Kundenanforderungen gerecht zu werden, müssen im Bereich Fahrzeugelektronik zunehmend komplexere Systeme in immer kürzeren Zeitabständen in ein Fahrzeug integriert werden. Target Integration der Universal-Steuergeräte (UCU) in /Simulink Ein Baustein für die zügige Entwicklung neuer Fahrzeugelektronik-Systeme ist die Modularität der IAV Universal-Steuergeräte (UCU s). Die drei Baseboard-Varianten, die im Wesentlichen die Ansteuerung der Aktoren und die Versorgung beinhalten, können wahlweise mit den derzeit verfügbaren Prozessoren C167, MPC555 oder Tricore als CPU Module kombiniert werden. Projektspezifisch wird so das passende System hinsichtlich Hardwareumgebung sowie geforderter Rechenart und Rechenleistung zusammengestellt. Der zweite Baustein für die Umsetzung der elektronischen Steuerung ist das Software-Design inklusive Hardware-Implementierung. Die Funktionsentwicklung erfolgt mittels modellbasierter Entwicklung in Simulink. Für die Programmierung aller Prozessoren wird ebenfalls und Simulink als Entwicklungsumgebung eingesetzt, der benötigte C-Code wird durch automatische Code-Generierung mit dem Real-Time Workshop (RTW) direkt aus den Simulink-Modellen gewonnen. Im Vergleich zur konventionellen Programmierung in C hat die Verwendung der automatischen Code-Generierung folgende Vorteile: Funktionsentwicklung und Programmierung können in einem Schritt durchgeführt werden. Die Software kann modulweise oder auch mittels Software-in-the-Loop-Tests vollständig durch Simulation getestet werden. Das Simulink Modell dient als Dokumentation für die Steuergeräte-Software. Das Erstellen und die Verwaltung einer Software Bibliothek (Simulink Module und selbst erstellte S-Function Blöcke) ist sehr einfach. Die Mehrfachverwendung von Modulen aus einer Bibliothek vereinfacht eine große Testtiefe. Die Wartbarkeit bzw. Erweiterbarkeit von Simulink-Modellen ist erheblich einfacher als von C-Code Programmen. Um all die zuvor erwähnten Vorteile nutzen zu können ist es notwendig, den Code- Generierungsprozess mit dem Real-Time Workshop bzw. RTW Embedded Coder an die jeweiligen Steuergeräte/Prozessoren zu adaptieren. Die Applikationsparameter werden direkt in angelegt, User C-Code wird direkt ins Simulink Modell eingebunden, nach der Code-Generierung mittels RTW wird automatisch der entsprechende Compiler aufgerufen und zum Schluss erfolgt ein automatischer Download auf das Steuergerät über den CAN-Bus. 11

13 Die Auswahl der CPU hängt von den Anforderungen des jeweiligen Projektes ab. Im Folgenden ist die Target-Integration für die unterschiedlichen Prozessoren kurz beschrieben: Die C167 CPU wird vorwiegend für die Entwicklung von Seriensoftware eingesetzt, um die Funktionsentwicklung auf einer CPU durchzuführen, die auch in Serie eingesetzt werden kann. Bei diesem Target IAV UCU C167 Target erfolgt die Tasksteuerung durch den automatisch generierten Scheduler des RTW, dessen zyklischer Aufruf in ein eigenes Basisprogramm für den C167 integriert ist. Für Anwendungen mit großer Rechenleistung kommt der MPC555 zum Einsatz. Dies Target IAV UCU MPC555 Target setzt auf dem Embedded Target for Motorola MPC555 von The Mathworks auf. Der TriCore wird immer dann eingesetzt, wenn große Anforderungen an die Peripherie gestellt werden (z.b. viele hochauflösende PWM Signale). Für diesen Prozessor stehen zwei Target Integrationen zur Auswahl: 1. Beim IAV UCU TriCore Target wird die Tasksteuerung durch einen selbst entwickelten Scheduler realisiert. 2. Das IAV UCU TriCore OSEK Target basiert auf dem ERKOSEK der Fa. ETAS. Einbindung des OSEK in /Simulink Bei komplexen Steuergerät-Programmen ist es vorteilhaft, ein Betriebssystem (OSEK) einzusetzen, um die Rechenleistung der CPU optimal auszunutzen. Die Hauptaufgabe eines OSEK ist die Tasksteuerung. Z.B. können Tasks mit hoher Priorität andere Tasks mit kleinerer Priorität unterbrechen, um unterschiedliche Zykluszeiten zu realisieren. Abb. 1: OSEK-Integration in Simulink Damit auch bei der Verwendung eines OSEK die gesamte Entwicklung in /Simulink erfolgt, wurde das Task Scheduling des OSEK mittels S-Funktion in Simulink integriert (Abb. 1). Die S-Function dient somit als integrierter OSEK-Konfigurator. Die einzelnen Tasks werden als Function-Call Subsystem in Simulink dargestellt. Für Simulation und Code-Generierung sind folgende Funktionen in der S-Function (OSEK Konfiguration) enthalten: In der Simulation stellt die S-Function den Scheduler für die einzelnen Subsysteme (Tasks) dar, jedoch nur als Vielfaches der Simulationszeit (Sample time). Die Subsysteme werden entsprechend der eingestellten Zykluszeit aufgerufen. Bei der automatischen Code-Generierung mittels RTW erstellt die S-Function automatisch eine OIL Datei (Beschreibungsdatei für das OSEK). Die Subsysteme werden als einzelnen Tasks in das OSEK Basisprogramm integriert und der Build Prozess mit der OIL Datei aufgerufen, mit anschließendem Download auf das Steuergerät. Integration der UCU Hardware IOs in Simulink Zusätzlich zur Funktionsentwicklung ist es notwendig, die Hardware der UCU IOs (z.b. digital IO, analog IO, CAN IO oder PWM IO) aus Simulink anzusprechen. Zu diesem Zweck wurde für die IAV Universal Steuergeräte mit unterschiedlichen CPUs ein einheitlicher HAL (Hardware Abstraction Layer) entwickelt. Die Integration der HAL Aufrufe (APIs) in Simulink erfolgt durch unterschiedliche S-Functions mit den dazugehörigen TLC-Scripten, die die Art der Codegenierung mit dem RTW steuern. Der CANin Block (Abb. 2) z.b. konfiguriert sich automatisch, indem eine Vector Datenbasis geladen und der gewünschte Identifier ausgelesen wird. Neben den entsprechenden Variablen (aus Datenbasis) liefert dieser Block Informationen über neu empfangene Daten oder Timeout eines bestimmten CAN-Identifier. In der Simulation werden die Simulations-Inputdaten (z.b. von mathematischen Modellen oder einem Joystick) des Blockes an die Ausgänge kopiert oder reale CAN-Daten gelesen. Als CAN-Bus 12

14 Block 2 (Modell_code) ist bei der Code- Generierung aktiv. Die Inputs sind auf Terminator Blöcke geführt und die Outputs sind mit Ground Blöcken verbunden. Dadurch entsteht auf dem Steuergerät kein überflüssiger Simulations Code. Eine Umschaltung zwischen Simulations-Block und Code-Generierungs-Block erfolgt über den Parameter Block choise. Dadurch ist es möglich, mit einem Simulink Modell sowohl umfangreiche Simulationen durchzuführen als auch auf Knopfdruck (Ctrl B) Steuergeräte zu programmieren. Abb. 2: CAN-Schnittstelle in Simulink Interface dient wahlweise eine Vector CANCardX oder ein IAV CAN <-> USB Adapter. Bei der Code-Generierung entsteht ein API Aufruf zum Lesen der CAN Daten. Sind aktuelle Daten eingetroffen, dann erfolgt eine Decodierung der CAN-Daten entsprechend den Vorgaben aus der Vector CAN Datenbasis. Solch eine flexible Code-Generierung ist mit dem TLC- Script des RTW möglich, da der generierte C-Code abhängig von den Vorgaben aus der Vector Datenbasis generisch erstellt wird. Damit bei der Code-Generierung kein überflüssiger Simulations-Code entsteht, sind alle Simulationsmodule jeweils in ein Configurable Subsystem eingebettet. Hier existieren für jedes Modell zwei Blöcke mit gleicher Anzahl von Ein- und Ausgängen (Abb. 3). Block 1 (Modell_sim) dient zur Simulation und enthält somit ein mathematisches Modell der Simulationsumgebung (z.b. mathematisches Modell einer Gleichstrom-Maschine). Applikation mittels CCP über den CAN-Bus Bei Rapid Prototyping Steuergeräten ist das CAN Calibration Protokoll (CCP) zum applizieren weit verbreitet. Bei der MPC555 CPU kommt das CCP Modul von The Math- Works zum Einsatz. Die IAV Basisprogramme für C167 CPU und TriCore CPU enthalten selbst erstellte CCP Module. Hierbei befinden sich die Referenz Applikationsparameter wahlweise im EEPROM oder Flash. Beim Start des Steuergerätes wird eine Kopie der Parameter ins RAM kopiert. Über das CCP lassen sich die einzelnen Parameter applizieren. Ist eine optimale Einstellung gefunden, dann lässt sich bei der EEPROM Version der aktuelle RAM Datensatz über Funktionsentwicklung mittels Software-in-the-Loop Der große Vorteil der Software-Entwicklung in Simulink ist die einfache Simulation der Funktionsmodule. Um die Simulationskette zu schließen ist es oftmals notwendig, ein mathematisches Modell der Steuergeräteumgebung zu erstellen (Abb. 3). Die Ausgangssignale des Modells werden z.b. über die UCU Hardware S-Function Blöcke (z.b. CANin oder ADCin) mittels der Kopierfunktion im Simulationsmode (Abb. 5) an die Funktionsmodule übergeben. Abb. 3: Mathematisches Modell der Steuergeräteumgebung in einem Configurable Subsystem, das für die Code-Generierung inaktiviert werden kann. 13

15 Abb. 4: Application Interface einen CCP Befehl als neuer Referenz Datensatz ins EEPROM speichern und über eine Checksumme sichern. Damit die /Simulink Toolkette eine solche CCP Applikationsschnittstelle durchgängig unterstützt, wurde ein Zusatzprogramm Application Interface erstellt. In diesem Tool werden alle Applikationsparameter (für /Simulink und zusätzlichen C-Code) angelegt (Abb. 4). Das Applikationstool hat folgende Funktionalität: Um die Applikationsparameter im /Simulink anzulegen, erzeugt das Programm eine *.m Datei, in der die Eigenschaften der Applikationsparameter beschrieben sind. Über eine Verknüpfung des Simulink Modells mit der *.m Datei lässt sich der Applikationsparameter direkt in Simulink-Blöcken verwenden (Abb. 5). Zusätzlich wird eine *.h Datei erzeugt, in der die Applikationsparameter angelegt werden, da diese in /Simulink als ImportedExtern deklariert werden. Die Verknüpfung der *.h Datei erfolgt über den User-Code-Block Parameter File (Abb. 1). Zum online Applizieren besitzt das Applikations-Programm eine CCP Schnittstelle. Dadurch lassen sich aktuelle Parameter auf ein Steuergerät speichern oder ein Datensatz aus einem Steuergerät lesen, um diese Parameter über eine neue *.m Datei in /Simulink zur Simulation zu übertragen. Durch die durchgängige Toolkette ist es einfach möglich, in Simulink-Modellen und bei der automatischen Code-Generierung mit Applikationsparametern (Einzelwerte und Matrizen für z.b. Kennlinien) zu arbeiten. Des Weiteren ist ein einfacher Austausch von Datensätzen zwischen einer Simulation in Simulink und dem Steuergerät möglich. Aufgrund der Verwendung einer genormten Applikationsschnittstelle können weitere Applikationstools wie z.b. INKA von Fa. ETAS und CANap von Fa. Vector eingesetzt werden. Nutzung des CCP Treibers als Debugschnittstelle Bei der Integration und dem Debugging der Software auf dem Steuergerät ist es oftmals sehr hilfreich, wenn der Entwickler sich online den Wert bestimmter Variablen ansehen kann. Durch eine entsprechende Parametrierung generiert der RTW für jeden Simulink-Blockausgang ein eigenes Element in der globalen Block-IO Struktur. Um online den Wert aus dem Steuergerät auszulesen, sind folgende Schritte notwendig: Ermitteln des vom RTW generierten Namen und Datentyp der Variablen für den Blockausgang im Source-Code. Die Adresse der Variablen aus der Map Datei des Compilers lesen. Mittels CCP Protokoll den Wert der Variablen aus dem Steuergerät zyklisch lesen. All diese Schritte wurden in einer speziellen S-Function umgesetzt. Diese S-Function (CCP Debug) wird in das Simulink Modell eingefügt (Abb. 1) und unterstützt dann den Entwickler automatisch beim Debuggen des Steuergerätes. Während der Simulation kann der Entwickler auf jeden (nicht virtuellen) Block klicken. Daraufhin öffnet sich ein Dialog (Abb. 5), in dem alle Variablen, die zu 14

16 Abb. 5: Anzeige von Blockparametern mittels CCP diesem Block gehören, angezeigt werden. Im Hintergrund holt sich die S-Function die Adressen der darzustellenden Variablen aus der Map Datei und liest die aktuellen Werte zyklisch mittels CANCardX oder IAV CAN<->USB Adapter über das CCP Protokoll vom Steuergerät. Wenn der Block Parameter enthält, lassen sich diese online verändern (Abb. 5). Somit ist es möglich selbst beim Debuggen /Simulink als vollständige Entwicklungsumgebung zu nutzen. Der Funktions-Softwareentwickler denkt während der gesamten Entwicklung in den grafischen Simulink-Strukturen. Durch diese Erweiterung hat er jetzt die Möglichkeit, durch Klicken auf einen beliebigen Block nachzusehen, ob die Block Eingangs-/Ausgangsund Internen Variablen auf dem Steuergerät im Fahrzeug den erwarteten Wert haben. Ausblick Die Verwendung von /Simulink zur Steuergeräte-Programmierung hat sich bereits in vielen Kundenprojekten bewährt. Die offenen Schnittstellen von / Simulink haben es ermöglicht, eine durchgängige Toolkette aufzusetzen, wodurch die gesamte Software Entwicklung (Mulitasking Design, Programmierung, Kompilieren, Download, Applikation und Debugging) in der Simulink-Umgebung erfolgen kann. Gerade im Rapid Prototyping Bereich ist die IAV mit dieser Toolkette in der Lage, sehr flexibel auf unterschiedlichste Kundenanforderung zu reagieren. Durch einen hohen Automatisierungsgrad bei der Softwareentwicklung (z.b. automatische Code-Generierung aus einer CAN Datenbasis und die Verwendung von umfangreichen Bibliotheken) werden Softwarefehler minimiert und Entwicklungszeiten verkürzt. Die Toolkette wird fortwährend weiterentwickelt. In einem nächsten Schritt ist die Integration des OSEK Target für die C167 und die MPC555 CPU vorgesehen, um die Portierbarkeit der Simulink Modelle auf unterschiedliche Steuergeräte zu verbessern. Auch das Applikationssystem wird in Zukunft für alle Prozessoren angeglichen. Eine zusätzliche grafische online Ausgabe von Debug-Daten in der Simulink-Umgebung wird bei zukünftigen Projekten den Entwicklern die Fehlersuche erheblich erleichtern. Autoren: Bernd Jahrsau, Martin Richter Elektronik-Systeme, Geschäftsfeld Automobilelektronik IAV GmbH 15

17 X-by-Wire Systementwicklung in Simulink Verglichen mit konventionellen ereignisgesteuerten Architekturen benötigen zeitgesteuerte Architekturen einen höheren Planungsaufwand. Entsprechend hoch sind die an den verwendeten Entwurfsprozess und die dabei eingesetzten Werkzeuge gestellten Anforderungen. Eine der wichtigsten Herausforderungen für einen derartigen Entwurfsprozess ist es, die Komplexität der Abhängigkeiten verschiedener Teilsysteme untereinander unter Kontrolle zu bringen. Die auftretende Komplexität wird durch die Zerlegung des Systems in Teilsysteme verschiedener Hersteller und durch Anforderungen bezüglich Sicherheit und Fehlertoleranz weiter erhöht. Für den Entwurf und die Simulation von verteilten Regelkreisen in zeitgesteuerten Systemen ist es erforderlich, Verzögerungen durch Laufzeiten von Berechnungsprozeduren und Übertragungszeiten des Kommunikationssystems zu berücksichtigen, da sie entscheidenden Einfluss auf die in den Regelkreisen auftretenden Totzeiten und somit auf die erzielbare Regelgüte haben. Eine integrierte Werkzeugkette der Firma DECOMSYS ermöglicht den Entwurf, die Simulation und die Codegenerierung von verteilten Echtzeitsystemen unter Simulink. In X-by-Wire Anwendungen der nächsten Generation im Automobilbau werden in einem hohen Maß regelungs- und steuerungstechnische Applikationen eingesetzt, welche hohen Anforderungen hinsichtlich Sicherheit und Fehlertoleranz genügen müssen. Aufgrund dieser Anforderungen kommen dabei zeitgesteuerte Architekturen für Taskausführung (z.b. OSEKtime) und Kommunikation zwischen den ECUs des Systems (z.b. FlexRay) zum Einsatz. Virtueller Prototyp Von besonderem Vorteil erweist sich in einem derartigen Entwicklungsprozess die Möglichkeit der Simulation des gesamten Systemverhaltens in sogenannten Virtuellen Prototypen. Hier können auftretende Effekte (im Zeit- und Wertebereich) im Zusammenspiel von Betriebssystem, Berechnungsprozeduren, Middleware und Kommunikation beobachtet und optimiert werden. Einen weiteren Vorteil stellt die Möglichkeit dar, das Systemverhalten in Extremsituationen und unter Fehlerbedingungen zu untersuchen, indem gezielt Fehler eingebracht werden und das dabei auftretende Systemverhalten optimiert werden kann. Dabei kommt man ohne vergleichsweise teure Hardwareaufbauten aus, in denen derartige Bedingungen nur sehr aufwändig nachgestellt werden könnten. Da bereits in einem sehr frühen Stadium im Entwurfsprozess ein hochwertiges Abbild des Systemverhaltens entsteht, kann ein hoher Anteil von Entwurfsfehlern bereits früh erkannt werden, wodurch der gesamte Entwicklungsaufwand des Systems sinkt. Das bevorzugte Entwicklungswerkzeug für regelungs- und steuerungstechnische Anwendungen im Automobilbau ist in vielen Bereichen Simulink. Die Verwendung von Simulink für die Entwicklung zeitgesteuerter verteilter Regelsysteme erfordert zusätzliche Mechanismen im Entwicklungsprozeß für Prototypen- und Seriensteuergeräte. V-Modell Zur Veranschaulichung von Softwareentwicklungsprozessen wird häufig das sogenannte V-Modell (Abb. 1) verwendet. Ausgehend von den Systemanforderungen wird (darauf aufbauend) ein funktionales Modell des Anwendungsverhaltens und deren Umgebung in Simulink erzeugt. Simulationen verschiedener Anwendungsfälle tragen dabei zur Optimierung des Anwendungsverhaltens bei. Aus den anwendungsspezifischen Teilen des funktionalen Modells wird anschließend durch den Einsatz von Codegeneratoren, wie z.b. Real-Time Workshop oder Real-Time Workshop Embedded Coder, Quellcode für Prototypen Steuergeräte erzeugt. Die rechte Hälfte des V-Modells beschäftigt sich mit dem Testen des erzeugten Quellcodes, der Verifikation der dabei erzielten Ergebnisse gegenüber dem funktionalen Modell und der nachfolgenden Validierung gegenüber den ursprünglichen Anforderungen. 16

18 Abb. 1: V-Modell Bei der Entwicklung von verteilten Steuerungen und Regelungen, bei denen ein Subsystem zur Kommunikation eingesetzt wird (FlexRay, CAN, TTCAN etc.), werden nun zusätzliche Anforderungen an den Software- Entwicklungsprozess gestellt. Einer der Gründe dafür ist, dass diese Kommunikationssysteme vor der Laufzeit konfiguriert werden müssen. Ein anderer, dass der Entwicklungsprozess die verteilte Architektur berücksichtigen muss, indem funktionale Teile des Systems verschiedenen Ausführungseinheiten (Hosts) zugeordnet werden. Diese Architekturinformationen sowie die sich ergebenden Nachrichtenschnittstellen sind wichtige Bausteine bei die Erstellung der Konfiguration für das Kommunikationssystem. Kommt ein zeitgesteuertes Kommunikationssystem zum Einsatz (FlexRay, TTCAN), so ist dieser Konfigurationsaufwand im Vergleich zu ereignisgesteuerten Kommunikationssystemen wie CAN relativ hoch, da ein genauer zeitlicher Busfahrplan erstellt werden muss. Als zusätzliche Resultate des Entwicklungsprozesses bei der Verwendung von zeitgesteuerten Systemen, die ein OSEKtime Betriebssystem verwenden, werden nun Konfigurationsdateien für die einzelnen Kommunikationskontroller erzeugt, und es wird Middleware Quellcode, z.b. für die Handhabung von Fehlertoleranz in der Nachrichtenübertragung (FTCom), konfiguriert und generiert. Die Verwaltung aller relevanten Eingabedaten sollte soweit wie möglich im zentral verwendeten Modellierungswerkzeug (in diesem Fall Simulink) gewährleistet sein. A-Modell DECOMSYS stellt einen Simulink basierten Entwicklungsprozess zur Verfügung, der den V-Modell Software-Entwicklungsprozess mit Simulink zwischen funktionalem Modell und Quellcode erweitert. Dadurch können die verteilte Struktur eingegeben, das Systemverhalten simuliert und die benötigten Konfigurationsdateien für Betriebssystem, Kommunikationssystem und Middleware automatisch generiert werden. Diese Erweiterung des V-Modelles wird auf Grund der graphischen Erscheinung A-Modell genannt (Abb. 2). Die im A-Modell Entwicklungsprozess verwendeten Werkzeuge und Übergänge zu nachfolgenden Modellen werden anhand eines einfachen Steer-by-Wire Beispiels veranschaulicht. Das funktionale Modell (FM) Das in diesem Beispiel verwendete funktionale Modell (Abb. 3) einer Steer-by-Wire Applikation besteht aus der Modellierung eines Lenkradsensors und einer Winkel-Regelung an einem Lenkwinkelaktuator sowie einem Modell des Verhaltens der Regelstrecke. Das funktionale Modell mit zugeteilten Architekturkomponenten (AAFM) Ausgehend vom rein funktionalen Modell der Applikation werden die funktionalen Modellteile auf verschiedene Ausfüh- Abb. 2: A-Modell Entwicklungsprozess 17

19 Abb. 3: Funktionales Modell (FM) einer Steer-by-Wire Applikation rungseinheiten aufgeteilt. Es entsteht das funktionale Modell mit zugeteilten Architekturkomponenten (engl. Architecture Allocated Functional Model AAFM, Abb. 2-1). Das Modell wird diskretisiert und es wird eine Zuordnung der funktionalen Modellteile zu Ausführungseinheiten, den Hosts, und Ausführungszeitpunkten, den Tasks, getroffen (Abb. 4). Abhängig von der so gewählten Architekturzuordnung ergeben sich Nachrichtenbeziehungen zwischen Tasks, die in Abhängigkeit von der Hostzuordnung über lokale Kommunikation (Intertask-Kommunikation) oder über das Kommunikationssystem aufgelöst werden. Im Beispiel des Lenksystems werden die Bereiche Abb. 4-1 und 4-5 keinen Hosts zugeordnet, da sie die Regelstrecke bzw. die Simulationsvorgaben repräsentieren. Die Bereiche Abb. 4-2, 4-3 und 4-4 bekommen jeweils unterschiedliche Tasks auf verschiedenen Hosts zugeordnet. Daraus ergibt sich, dass z.b. zwischen den Funktionsblöcken Abb. 4-1 und 4-2 der Sollwert des Regelkreises ausgetauscht werden muss. Um die Architekturkomponenten im Modell repräsentieren zu können, wird als Werkzeug DECOMSYS::SIMSYSTEM verwendet. Dieses Werkzeug besteht einerseits aus Simulink Blöcken zur Modellierung sowie andererseits aus einem Simulationskern, welcher das Aktivierungsverhalten zeitgesteuerter Tasks eines OSEKtime Betriebssystems und die Kommunikation zwischen Tasks nachbildet. Auf oberster Modellebene wird mit einem sogenannten Cluster Block das verwendete Kommunikationssystem festgelegt (Abb. 5-1), in diesem Beispiel ist das Flex- Ray. Danach werden die verwendeten Hosts durch sogenannte Host-Subsysteme definiert. Die Umgebungsmodelle bleiben auf oberster Modellebene, da sie keinem Host zugeordnet sind. Der Informationsaustausch mit den Umgebungsmodellen erfolgt über Simulink-Signale. Innerhalb eines Host-Subsystems werden die zugeordneten Tasks modelliert (Abb. 5-2 Mitte). Ein Task wird dabei aus einem verknüpften Paar aus Dispatch-Event Block und Task-Subsystem repräsentiert. Der Dispatch-Event Bock dient dabei zur Festlegung der jeweiligen Task-Aktivierungszeit des zeitgesteuerten Betriebssystems. Das dem Dispatch-Event Block durch ein Simulink Function-Call Signal zugeordnete Task-Subsystem (Abb. 5-2 Unten) enthält die dem Task zugeordnete Funktionalität (Abb. 5-3). Zum Austausch von Nachrichten werden sogenannte Signalkonnektor-Blöcke verwendet. Mit einem Signal-Write Konnektor werden zu sendende Signale definiert (Abb. 6). Mit Signal-Read Konnektoren kann dann in anderen Tasks dieses Signal empfangen werden. Während der Simulation interagieren diese Blöcke mit dem Simulationskern, welcher für die Signalübermittlung sorgt. Simulation des AAFM Bei der Simulation des AAFM werden nun vom Betriebssystem-Simulationskern die Tasks zu den angegebenen Zeitpunkten aktiviert. Die Simulation der Kommunikation wird im AAFM vereinfacht durchgeführt: Nachrichten, die vor der Task-Aktivierungszeit gesendet wurden, stehen bereits zur Verfügung. Signallaufzeiten über das Kommunikationsprotokoll werden nicht berücksichtigt, da das Kommunikationsschedule (der Busfahrplan) noch nicht bekannt ist. In einem Simulationsmodus kann auch die WCET (Worst Case Execution Time) der Applikationstasks berücksichtigt werden. Die Ergebnisse der Task-Berechnungen, welche versendet werden sollen, sind erst nach Ablauf der WCET für empfangende Tasks sichtbar. Somit können Zeitverzögerungen der Kommunikation, die durch Laufzeiten und zeitliche Reihenfolgen von Tasks bedingt sind, erkannt werden. Abb. 4: Aufteilung eines Funktionalen Modells 18

20 Architektur Modell (AM) Das Architekturmodell (AM) enthält nur die architekturellen Komponenten des Systems und keine funktionalen Anteile. Die architekturellen Eigenschaften des AAFM bilden die Grundlage für das AM (Abb. 2-2). Hierzu werden aus dem AAFM alle funktionalen Modellanteile entfernt und nur die für die Kommunikationskonfiguration relevanten Eigenschaften abstrahiert. Das AM wird in einer eigenen XML Datei gespeichert, dem XML Cluster Definition File (XCDEF). DECOMSYS::SIMSYSTEM interagiert während des Modellierens im AAFM Modell im Hintergrund stets mit dem zugehörigen AM. Diese automatische Interaktion bringt mehrere Vorteile mit sich. So können beispielsweise bestehende AMs bei der Simulink Modellierung verwendet werden. Das AM bietet nun den Ansatzpunkt für mehrere weitere Werkzeuge. So kann z.b. ein sogenanntes Expander Werkzeug eingesetzt werden, um Low-Level Tasks für die FTCom Schicht zu berechnen, welche für das Verpacken und Auspacken von Signalen in Frames oder die Ausführung von Replica Determinate Agreement (RDA) Algorithmen zuständig sind. Im Architekturmodell kann dann mit Hilfe weiterer Werkzeuge wie DECOM- SYS::DESIGNER ein Kommunikationsschedule zu dem bereits bestehenden Softwaremodell im AM erstellt werden. Der virtuelle Prototyp (VP) Sind im AM gültige Konfigurationen für FTCom Low-Level Tasks sowie Kommunikationschedules vorhanden, so kann das AAFM automatisiert in den Virtuellen Prototypen (VP) umgewandelt werden (Abb. 2-3 und 2-4), wobei hier ein weiteres Werkzeug zum Tragen kommt: DECOMSYS::SIM- COM ist zugleich ein Kommunikationssystem und FTCom-Simulationskern. Bei diesem automatisierten Umwandlungsprozess wird der Simulationskern für Kommunikation und den FTCom geladen. Alle Signalkonnektoren des AAFM werden dabei in Signalkonnektoren des VP umgewandelt, welche nun bei den folgenden Simulationen mit Abb. 5: Architekturalloziertes Funktionales Modell (AAFM) der FTCom Schicht interagieren, die wiederum mit dem jeweiligen Kommunikationskontroller Nachrichteninstanzen austauscht. Simulation des Virtuellen Prototypen DECOMSYS::SIMCOM ist nun zusätzlich zum DECOMSYS::SIMSYSTEM in der Lage, das Verhalten des Kommunikationssystems auf Basis eines vorhandenen Kommunikationsschedules im Zeit und Wertebereich zu simulieren. In der Simulation im VP kann somit das Zusammenspiel von Betriebssystemaktivierung des Applikationstasks, FTCom Low-Level Tasks und des Kommunikationssystems beobachtet werden. Schnittstellen zur Einstreuung von Kommunikationsfehlern können benutzt werden, um reproduzierbare Fehlerszenarien zu simulieren (Abb. 7). So kann z.b. auf sehr einfache Art und Weise festgestellt werden, wie sich die Applikation verhält, falls einzelne Kommunikationskontroller ausfallen, ein gesamter Kommunikationskanal ausfällt oder wenn einzelne Messages (Frames) am Kommunikationssystem nicht übertragen werden können. Dadurch kann die Fehlertoleranz des Systems überprüft und gegebenenfalls optimiert werden. Da der VP sowohl vollständige Betriebssystem-, FTCom- und Kommunikationssystem-Konfigurationen benötigt, ist ein Verändern der architekturellen Eigenschaften des Systems in diesem Modus nicht möglich. Ist dies jedoch erforderlich, z.b. zum Erzeugen zusätzlicher Tasks etc., so kann der VP in das AAFM zurückgeschaltet werden, wo die Änderungen vorgenommen werden können. 19

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

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

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

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

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

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

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

Ihr Vorteil durch effizientes Testen

Ihr Vorteil durch effizientes Testen EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM XAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM EXAM M EXAM EXAM EXAM EXAM EXAM EXAM EXAM

Mehr

OSEKtime - Time-Triggered OSEK/OS

OSEKtime - Time-Triggered OSEK/OS OSEKtime - Time-Triggered OSEK/OS Gregor Kaleta gregor.kaleta@udo.edu PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Einleitung OSEKtime Task-Zustandsmodell, Scheduling-Verfahren Interrupt-Verarbeitung

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

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

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

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

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

Restbussimulation für FlexRay-Netzwerke

Restbussimulation für FlexRay-Netzwerke Restbussimulation für FlexRay-Netzwerke Fachartikel von: Thomas Waggershauser, IXXAT Automation Weingarten Dr. Robert von Häfen, BMW Group München Im Folgenden werden Möglichkeiten und Vorteile der von

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

Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- Architekturentwicklung von Fahrzeugen

Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- Architekturentwicklung von Fahrzeugen Transfer von Prozessen des Software-Produktlinien Engineering in die Elektrik/Elektronik- entwicklung von Fahrzeugen Martin Jaensch, Dr. Bernd Hedenetz, Markus Conrath Daimler AG Prof. Dr. Klaus D. Müller-Glaser

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

Produktinformation DaVinci Developer

Produktinformation DaVinci Developer Produktinformation DaVinci Developer Inhaltsverzeichnis 1 DaVinci Developer - Entwurf von AUTOSAR Softwarekomponenten... 3 1.1 Die Vorteile von DaVinci Developer im Überblick... 3 1.2 Anwendungsgebiete...

Mehr

Code wiederverwenden: Objektorientierte Programmierung (OOP) sinnvoll nutzen Roland Wagner Automatisierungstreff IT & Automation 2015

Code wiederverwenden: Objektorientierte Programmierung (OOP) sinnvoll nutzen Roland Wagner Automatisierungstreff IT & Automation 2015 Code wiederverwenden: Objektorientierte Programmierung (OOP) sinnvoll nutzen Roland Wagner Automatisierungstreff IT & Automation 2015 CODESYS a trademark of 3S-Smart Software Solutions GmbH Agenda 1 Warum

Mehr

Embedded OS für ARM Cortex Microcontroller

Embedded OS für ARM Cortex Microcontroller Embedded OS für ARM Cortex Microcontroller RTOS Design, Timinganalyse und Test mit Core Simulation und Hardware Debugger Entscheidende Fragen für oder gegen RTOS Lohnt sich der Einsatz eines RTOS auch

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

Linutronix - Wir verbinden Welten. Open Source Software in der Industrie. Firmenvorstellung

Linutronix - Wir verbinden Welten. Open Source Software in der Industrie. Firmenvorstellung Linutronix - Wir verbinden Welten Open Source Software in der Industrie Firmenvorstellung Firma Gegründet 1996 von Thomas Gleixner 2006 Umwandlung in GmbH Maintainer von: X86 Architektur RT-Preempt UIO

Mehr

Grundlagen der Elektro-Proportionaltechnik

Grundlagen der Elektro-Proportionaltechnik Grundlagen der Elektro-Proportionaltechnik Totband Ventilverstärkung Hysterese Linearität Wiederholbarkeit Auflösung Sprungantwort Frequenzantwort - Bode Analyse Der Arbeitsbereich, in dem innerhalb von

Mehr

Die Revolution der Automation Software

Die Revolution der Automation Software Anwendungsentwicklung Die Revolution der Automation Software Maschinen und Anlagen müssen immer flexibler und effizienter werden. Das Software- Engineering ist dabei ein immer wichtigerer Zeit- und Kostenfaktor.

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

Ü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

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

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

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R

Vector Software. Test Automation mit VectorCAST während der gesamten Softwareentwicklung W H I T E P A P E R Vector Software W H I T E P A P E R Test Automation mit VectorCAST während der gesamten Softwareentwicklung VectorCAST Produktfamilie Die VectorCAST Produktfamilie automatisiert Testaktivitäten über den

Mehr

Simerics. Unternehmen. Über uns. info@simerics.de. Telefon +49 7472 96946-25. www.simerics.de

Simerics. Unternehmen. Über uns. info@simerics.de. Telefon +49 7472 96946-25. www.simerics.de Simerics Über uns Unternehmen Die Simerics GmbH ist ein Joint Venture der Partnergesellschaften Simerics Inc. (USA) und der CFD Consultants GmbH (Deutschland). Die Gründung erfolgte 2014 mit dem Ziel die

Mehr

Einführung in Automation Studio

Einführung in Automation Studio Einführung in Automation Studio Übungsziel: Der links abgebildete Stromlaufplan soll mit einer SPS realisiert werden und mit Automation Studio programmiert werden. Es soll ein Softwareobjekt Logik_1 in

Mehr

Prozesskette Funktionsdaten und Funktionsmodelle

Prozesskette Funktionsdaten und Funktionsmodelle Prozesskette Funktionsdaten und Funktionsmodelle Stuttgart, 11. Februar 2015 D. Ruschmeier 2/15 Wesentliche Eingangsparameter für die funktional-basierten Berechnungsverfahren sind: Anforderungs-, Modellbeschreibungen

Mehr

Z- Software Informationen Modularer Aufbau und Einsatzmöglichkeiten

Z- Software Informationen Modularer Aufbau und Einsatzmöglichkeiten Z- Software Informationen Modularer Aufbau und Einsatzmöglichkeiten Z- DBackup Freeware für den Privatgebrauch Die hier angebotenen Freeware Programme (Standard- Versionen) sind Freeware für den Privatgebrauch,

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

SmartExporter 2013 R1

SmartExporter 2013 R1 Die aktuelle Version wartet mit zahlreichen neuen Features und umfangreichen Erweiterungen auf. So können mit SmartExporter 2013 R1 nun auch archivierte Daten extrahiert und das Herunterladen der Daten

Mehr

Willkommen zu TwinCAT 3. Die TwinCAT-3-Philosophie

Willkommen zu TwinCAT 3. Die TwinCAT-3-Philosophie Erste Schritte Willkommen zu TwinCAT 3 Mit TwinCAT 3 beginnt ein neues Zeitalter der PC-basierten Steuerungssoftware und eine neue Etappe in der Firmengeschichte der Beckhoff Automation GmbH. Besonders

Mehr

Atomic Basic Blocks Eine kontrollflussunabhängige Zwischendarstellung für Echtzeitsysteme

Atomic Basic Blocks Eine kontrollflussunabhängige Zwischendarstellung für Echtzeitsysteme Atomic Basic Blocks Eine kontrollflussunabhängige Zwischendarstellung für Echtzeitsysteme Fabian Scheler Martin Mitzlaff Wolfgang Schröder-Preikschat Informatik 4 Verteilte Systeme und Betriebssysteme

Mehr

Mit dem Blick für Details Den Antrieb von morgen gestalten

Mit dem Blick für Details Den Antrieb von morgen gestalten Mit dem Blick für Details Den Antrieb von morgen gestalten Automotive Engineering FMEA, XiL, OBD oder FFT die Automobilentwicklung ist abwechslungsreich. Dabei stehen immer komplexe, mechatronische Systeme

Mehr

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Dokumentation zum Projekt Mail-Adapter in SAP PI 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Inhalt 1. Einleitung... 2 2. Vorgehen... 3 1. Datentyp für die Mail einrichten... 3 2. Message Typen

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

PRAKTIKUM Experimentelle Prozeßanalyse 2. VERSUCH AS-PA-2 "Methoden der Modellbildung statischer Systeme" Teil 2 (für ausgewählte Masterstudiengänge)

PRAKTIKUM Experimentelle Prozeßanalyse 2. VERSUCH AS-PA-2 Methoden der Modellbildung statischer Systeme Teil 2 (für ausgewählte Masterstudiengänge) FACHGEBIET Systemanalyse PRAKTIKUM Experimentelle Prozeßanalyse 2 VERSUCH AS-PA-2 "Methoden der Modellbildung statischer Systeme" Teil 2 (für ausgewählte Masterstudiengänge) Verantw. Hochschullehrer: Prof.

Mehr

BT OBD 327. Bluetooth OBD Interface. Technische Dokumentation

BT OBD 327. Bluetooth OBD Interface. Technische Dokumentation Bluetooth OBD Interface by Technische Dokumentation Dieses Dokument wurde sorgfältig überprüft. Die APOS GmbH Embedded Systems behält sich das Recht vor, Änderungen an allen hier beschriebenen Produkten

Mehr

Erfolg ist programmierbar.

Erfolg ist programmierbar. 45789545697749812346568958565124578954569774981 46568958565124578954569774981234656895856124578 45697749812346568958565124578954569774981234656 58565124578954569774981234656895856124578954569 49812346568958565124578954569774981234656895856

Mehr

Laufzeitverhalten von FFT Implementierungen O. Punk, S. Döhler, U. Heuert Hochschule Merseburg (FH), Fachbereich Ingenieur und Naturwissenschaften

Laufzeitverhalten von FFT Implementierungen O. Punk, S. Döhler, U. Heuert Hochschule Merseburg (FH), Fachbereich Ingenieur und Naturwissenschaften Laufzeitverhalten von FFT Implementierungen O. Punk, S. Döhler, U. Heuert Hochschule Merseburg (FH), Fachbereich Ingenieur und Naturwissenschaften Aufgabenstellung und Motivation Die DFT (Diskrete Fouriertransformation)

Mehr

Leistungs- und Geschwindigkeitssteigerung. Dipl.-Ing. Sebastian F. Kleinau Applikationsingenieur

Leistungs- und Geschwindigkeitssteigerung. Dipl.-Ing. Sebastian F. Kleinau Applikationsingenieur Leistungs- und Geschwindigkeitssteigerung von LabVIEW-Projekten Dipl.-Ing. Sebastian F. Kleinau Applikationsingenieur Agenda 1. Einführung 2. Hilfreiche Werkzeuge zur Codeanalyse 3. Benchmarks für LabVIEW-VIs

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

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

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

Smart Engineering. Perfection in Automation www.br-automation.com

Smart Engineering. Perfection in Automation www.br-automation.com Smart Engineering Perfection in Automation www.br-automation.com Smart Engineering Smart Engineering mit Automation Studio Mit der Einführung von Automation Studio im Jahr 1997 hat B&R einen weltweit beachteten

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

Abacus Formula Compiler (AFC)

Abacus Formula Compiler (AFC) Abacus Formula Compiler (AFC) Alle kennen Excel - jetzt sogar Ihre Java- Applikation! Bringt Tabellenkalkulationen auf die JVM http://formulacompiler.org/ Peter Arrenbrecht für Abacus Research AG http://abacus.ch/

Mehr

PROtroniC LINE. Die All-Rounder für Rapid Control Prototyping

PROtroniC LINE. Die All-Rounder für Rapid Control Prototyping PROtroniC LINE Die All-Rounder für Rapid Control Prototyping U n i v e r s a l g e n i e s Unsere Mission: Ihr Rapid Control Prototyping revolutionieren Entwicklungen auf die Überholspur bringen Schnell

Mehr

Erweiterte Vorgehensmodelle für die Entwicklung echtzeitfähiger, hochintegrierter, multifunktionaler Steuergeräte-Plattformen

Erweiterte Vorgehensmodelle für die Entwicklung echtzeitfähiger, hochintegrierter, multifunktionaler Steuergeräte-Plattformen Erweiterte Vorgehensmodelle für die Entwicklung echtzeitfähiger, hochintegrierter, multifunktionaler Steuergeräte-Plattformen Andreas Baudisch, AUDI AG Dr. Kai Richter, Symtavision GmbH Stefan Sollmann,

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

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

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

Individuell verformte Werkstücke automatisch bearbeiten. In-Prozess Scannen. Adaptive Bearbeitung. System-Integration BCT

Individuell verformte Werkstücke automatisch bearbeiten. In-Prozess Scannen. Adaptive Bearbeitung. System-Integration BCT Individuell verformte Werkstücke automatisch bearbeiten. In-Prozess Scannen Adaptive Bearbeitung System-Integration BCT BCT Automatisierte Bearbeitung individuell verformter Werkstücke. BCT GmbH ist ein

Mehr

Weitere Informationen über die neuen Funktionen und Möglichkeiten erhalten Sie auf dem Produktblatt

Weitere Informationen über die neuen Funktionen und Möglichkeiten erhalten Sie auf dem Produktblatt ZUR SOFORTIGEN VERÖFFENTLICHUNG Famic Technologies veröffentlicht das Neue Automation Studio mit verbesserten Funktionen & optimierter Leistungsfähigkeit Die umfangreichste Simulationssoftware, welche

Mehr

Variantenkonfiguration von Modellbasierter Embedded Automotive Software

Variantenkonfiguration von Modellbasierter Embedded Automotive Software Model-Driven Development & Product Lines Leipzig, 19. Oktober 2006 Jens Weiland DaimlerChrysler AG (GR/ESS) Die Rolle von Varianten für den Bereich Automotive Vielzahl variabler Funktionen Beispiel Mercedes

Mehr

Rechnernutzung in der Physik. Betriebssysteme

Rechnernutzung in der Physik. Betriebssysteme Rechnernutzung in der Physik Betriebssysteme 1 Betriebssysteme Anwendungsprogramme Betriebssystem Treiber BIOS Direkter Zugriff von Anwenderprogrammen auf Hardware nur in Ausnahmefällen sinnvoll / möglich:

Mehr

DesignCAD 3D Max V23 Architekt

DesignCAD 3D Max V23 Architekt 70382-6 HB 02.10.13 09:50 Seite 1 DesignCAD 3D Max V23 Architekt Ø = Null O = Buchstabe Hotline: 0900 / 140 96 41 Mo.- Fr. 1200 bis 1800 Uhr. 0,44 Euro/Minute aus dem deutschen Festnetz, mobil ggf. abweichend.

Mehr

Vom HMI zum WebSCADA Portal

Vom HMI zum WebSCADA Portal Vom HMI zum WebSCADA Portal Teil 1. Skalierbare webbasierende Visualisierungsplattform: Das Bedienpanel als Basis Marcel Bühner Schlagworte wie Industrie 4.0, IoT (Internet of Things), Automation in the

Mehr

objectif Requirements Modeller

objectif Requirements Modeller objectif Requirements Modeller Das ist neu in Version 1.1 1 Inhalt objectif Requirements Modeller das Tool für Requirements Engineering in Software- und Systementwicklung Das ist neu in Version 1.1 Seite

Mehr

Portfolio 09. Das Unternehmen Was ist NeQS Was bieten wir

Portfolio 09. Das Unternehmen Was ist NeQS Was bieten wir Portfolio 09 Nehring PC-Messtechnik Hauptstraße 18 56281 Dörth Telefon 06747 6967 neqs@a-nehring.de www.a-nehring.de Das Unternehmen Was ist NeQS Was bieten wir Das Unternehmen Das sagen Kunden über uns

Mehr

> Soft.ZIV. Matlab Programmiersystem für mathematische Berechnungen

> Soft.ZIV. Matlab Programmiersystem für mathematische Berechnungen > Soft.ZIV Matlab Programmiersystem für mathematische Berechnungen Inhaltsverzeichnis Organisation... 3 Hersteller... 3 Produkte... 3 MATLAB... 3 Simulink... 3 Parallel Computing... 3 Math, Statistics

Mehr

Simulation 2.0: Simulationsbaukasten und Team-Modellierung

Simulation 2.0: Simulationsbaukasten und Team-Modellierung Simulation 2.0: Simulationsbaukasten und Team-Modellierung Vortrag an der FH Ostfalia, ASIM 2012 Daniel Frechen TESIS DYNAware GmbH 24. Februar 2012 TESIS DYNAware GmbH, www.tesis-dynaware.com 1 Einleitung

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

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

Audiokommunikation im Computer. Andreas Jäger

Audiokommunikation im Computer. Andreas Jäger Audiokommunikation im Computer Wie kommunizieren die Teile einer DAW miteinander? Host Hardware Host Was gibt es in der Praxis zu beachten? Wo liegen Gefahren? Konkreter: Warum ist ASIO besser als MME?

Mehr

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten Aktuelle Themen der Wirtschaftsinformatik Zusammenfassung 09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten 1 Serverseitige Webprogrammierung

Mehr

Uberlegungen Einsatzgebiete Virtualisierungslosungen Fazit Hardwarevirtualisierung. Virtualisierung. Christian Voshage. 11.

Uberlegungen Einsatzgebiete Virtualisierungslosungen Fazit Hardwarevirtualisierung. Virtualisierung. Christian Voshage. 11. slosungen 11. Mai 2009 Inhaltsverzeichnis Uberlegungen slosungen 1 Uberlegungen Grunduberlegungen Vorteile Hardware-Emulation Nachteile 2 Servervirtualisierung Clientvirtualisierung 3 slosungen 4 5 Uberlegungen

Mehr

Requirement Engineering. in der Steuergeräteentwicklung

Requirement Engineering. in der Steuergeräteentwicklung Requirement Engineering in der Steuergeräteentwicklung A.User A.User IAV IAV GmbH GmbH Geschäftsfeld Geschäftsfeld Automobilelektronik Automobilelektronik Abteilung Abteilung Softwareentwicklung Softwareentwicklung

Mehr

Erfahrungsbericht zur Bachelor Thesis Silvan Wirth Studiengang Mechatronik Trinational www.trinat.net

Erfahrungsbericht zur Bachelor Thesis Silvan Wirth Studiengang Mechatronik Trinational www.trinat.net 2012 Entwicklung und Verifizierung von Berechnungsformeln zur Konzentrationsbestimmung von Gasgemischen mit einem neuartigen MEMS basierten Inline Dichtesensor Erfahrungsbericht zur Bachelor Thesis Silvan

Mehr

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen

CaseWare Monitor. ProduktNEWS CaseWare Monitor. Version 4.3. Mehr Informationen zu CaseWare Monitor und unseren anderen Produkten & Dienstleistungen Mit der aktuellen Version hält eine komplett neu konzipierte webbasierte Anwendung Einzug, die sich neben innovativer Technik auch durch ein modernes Design und eine intuitive Bedienung auszeichnet. Angefangen

Mehr

DER CONTROLLER KNX IP. Bewährte Technik auf neuem Niveau

DER CONTROLLER KNX IP. Bewährte Technik auf neuem Niveau DER CONTROLLER KNX IP Bewährte Technik auf neuem Niveau DAS WAGO-KNX-PORTFOLIO KNX Controller KNX IP starke Performance Der frei programmierbare Controller KNX IP ist das Multitalent für die flexible Gebäudetechnik.

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

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

Perzentile mit Hadoop ermitteln

Perzentile mit Hadoop ermitteln Perzentile mit Hadoop ermitteln Ausgangspunkt Ziel dieses Projektes war, einen Hadoop Job zu entwickeln, der mit Hilfe gegebener Parameter Simulationen durchführt und aus den Ergebnissen die Perzentile

Mehr

whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN

whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN CLOUD-ENTWICKLUNG: BESTE METHODEN 1 Cloud-basierte Lösungen sind auf dem IT-Markt immer weiter verbreitet und werden von immer mehr

Mehr

Konzept eines Datenbankprototypen. 30.06.2003 Folie 1 Daniel Gander / Gerhard Schrotter

Konzept eines Datenbankprototypen. 30.06.2003 Folie 1 Daniel Gander / Gerhard Schrotter Konzept eines Datenbankprototypen 30.06.2003 Folie 1 Daniel Gander / Gerhard Schrotter Inhalt (1) Projektvorstellung & Projektzeitplan Softwarekomponenten Detailierte Beschreibung der System Bausteine

Mehr

Bedienungsanleitung WR ConfigTool für DuoFern Handzentrale (9493) DuoFern Umweltsensor (9475)

Bedienungsanleitung WR ConfigTool für DuoFern Handzentrale (9493) DuoFern Umweltsensor (9475) Bedienungsanleitung WR ConfigTool für DuoFern Handzentrale (949) DuoFern Umweltsensor (9475) / Inhaltsverzeichnis Einleitung.... Standard Layout... 4 Handzentrale... 5. Daten laden... 5. Einstellungen

Mehr

SEMINARVORTRAG ANDROID ENTWICKLUNG ETIENNE KÖRNER EMBEDDED SYSTEMS SS2013 - HSRM

SEMINARVORTRAG ANDROID ENTWICKLUNG ETIENNE KÖRNER EMBEDDED SYSTEMS SS2013 - HSRM SEMINARVORTRAG ANDROID ENTWICKLUNG ETIENNE KÖRNER EMBEDDED SYSTEMS SS2013 - HSRM ÜBERSICHT Android Android Dalvik Virtuelle Maschine Android und Desktop Applikationen Android Entwicklung Tools R Activity

Mehr

Abb. 1 Akustikprüfstand, gemessene Geschwindigkeitsprofile hinter der Mehrlochblende (links); Spektrogramm der Mehrlochblende (rechts)

Abb. 1 Akustikprüfstand, gemessene Geschwindigkeitsprofile hinter der Mehrlochblende (links); Spektrogramm der Mehrlochblende (rechts) IGF-Vorhaben Nr. 17261 N/1 Numerische Berechnung des durch Turbulenz erzeugten Innenschalldruckpegels von Industriearmaturen auf der Basis von stationären Strömungsberechnungen (CFD) Die Vorhersage der

Mehr

Regelungstechnik 1 Praktikum Versuch 1.1. 1 Unterschied zwischen Steuerung und Regelung Reglereinstellung mittels Schwingversuch

Regelungstechnik 1 Praktikum Versuch 1.1. 1 Unterschied zwischen Steuerung und Regelung Reglereinstellung mittels Schwingversuch Regelungstechnik 1 Praktikum Versuch 1.1 1 nterschied zwischen Steuerung und Regelung Reglereinstellung mittels Schwingversuch Die Aufgabe der Regelungstechnik besteht im weitesten Sinne darin, einen bestimmten

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

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

Automation and Drives. Component based Automation. Neu bei TIA: Component based Automation

Automation and Drives. Component based Automation. Neu bei TIA: Component based Automation and Drives Neu bei TIA: Component based and Drives A&D AS SM 5, 07/2002 2 Der Wandel in der stechnologie Steuerungs-Plattformen PLC PC PLC Intelligent Field Devices PC PLC 1990 2000 2010 and Drives Kommunikation

Mehr

Albert HAYR Linux, IT and Open Source Expert and Solution Architect. Open Source professionell einsetzen

Albert HAYR Linux, IT and Open Source Expert and Solution Architect. Open Source professionell einsetzen Open Source professionell einsetzen 1 Mein Background Ich bin überzeugt von Open Source. Ich verwende fast nur Open Source privat und beruflich. Ich arbeite seit mehr als 10 Jahren mit Linux und Open Source.

Mehr

Komponenten- und ereignisorientierte Softwareentwicklung am Beispiel von Borland-Delphi

Komponenten- und ereignisorientierte Softwareentwicklung am Beispiel von Borland-Delphi Komponenten- und ereignisorientierte Softwareentwicklung am Beispiel von Borland-Delphi Dr. Henry Herper Otto-von-Guericke-Universität Magdeburg Institut für Simulation und Graphik Lisa-Weiterbildung -

Mehr

Simulation von Computer- und Kommunikationssystemen

Simulation von Computer- und Kommunikationssystemen Computer und Kommunikationssysteme Nachbildung der Verarbeitung in Rechnern und Kommunikation in Netzwerken Belegung und Auslastung von Systemressourcen Analyse von Systemverhalten Systemleistung in der

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Kanalentwicklung bei der IAVC

Kanalentwicklung bei der IAVC Kanalentwicklung bei der IAVC Konstruktion, Berechnung, Versuch SAXON SIMULATION MEETING (TU Chemnitz) Dipl.-Ing. Wolfgang Berg Chemnitz, 27.04.10 Innovationen in Serie IAV Firmenprofil Überblick Gründungsjahr:

Mehr

B.4. B.4 Betriebssysteme. 2002 Prof. Dr. Rainer Manthey Informatik II 1

B.4. B.4 Betriebssysteme. 2002 Prof. Dr. Rainer Manthey Informatik II 1 Betriebssysteme Betriebssysteme 2002 Prof. Dr. Rainer Manthey Informatik II 1 Bekannte Betriebssysteme Windows 2000 CMS UNIX MS-DOS OS/2 VM/SP BS 2000 MVS Windows NT Solaris Linux 2002 Prof. Dr. Rainer

Mehr

0. Inhaltsverzeichnis

0. Inhaltsverzeichnis 0. Inhaltsverzeichnis 0. Inhaltsverzeichnis...1 1. Kurze Einführung WebService Architektur...2 1.1 Synchrones Modell:...2 1.2 Asynchrones Modell:...2 1.3 Vorteile:...3 1.4 Voraussetzungen...3 2. Testseite

Mehr

Betriebssysteme Kap A: Grundlagen

Betriebssysteme Kap A: Grundlagen Betriebssysteme Kap A: Grundlagen 1 Betriebssystem Definition DIN 44300 Die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften dieser Rechenanlage die Basis der möglichen Betriebsarten

Mehr

DBUS Interprozess-Kommunikation für Embedded-Plattformen

DBUS Interprozess-Kommunikation für Embedded-Plattformen DBUS Interprozess-Kommunikation für Embedded-Plattformen Andreas Schwarz Neratec Solutions AG Firmenprofil Neratec Solutions AG Produkt-Entwicklungen für kundenspezifische elektronische Produkte Produkte

Mehr

Forms2Net Die neue Migrations-Software

Forms2Net Die neue Migrations-Software Forms2Net Die neue Migrations-Software Forms2Net transportiert Ihre Oracle Forms Anwendungen perfekt nach Microsoft.NET Darauf haben viele gewartet. Vielleicht auch Sie! Forms2Net ist ein Produktpaket,

Mehr

Reaktive Systeme und synchrones Paradigma

Reaktive Systeme und synchrones Paradigma Sascha Kretzschmann Freie Universität Berlin Reaktive Systeme und synchrones Paradigma Einführung in das Seminar über synchrone Programmiersprachen Worum geht es? INHALT 2 Inhalt 1. Einleitung - Wo befinden

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