Softwarearchitektur und Embedded-UML mit Echzeitbetriebssystemen (RTOS) -Möglichkeiten und Grenzen-

Größe: px
Ab Seite anzeigen:

Download "Softwarearchitektur und Embedded-UML mit Echzeitbetriebssystemen (RTOS) -Möglichkeiten und Grenzen-"

Transkript

1 1 Softwarearchitektur und Embedded-UML mit Echzeitbetriebssystemen (RTOS) -Möglichkeiten und Grenzen- Anne Gregor Olaf C. Winne Quategra GmbH Karl-Heine-Str. 99, Leipzig T F Zusammenfassung: Der erfolgreiche Einsatz von UML (Unified Modelling Language) und Echtzeitbetriebssystemen (RTOS) für die Softwareentwicklung von kleinen und mittleren Embedded-Systemen setzt eine gute Softwarearchitektur voraus. Knappe Ressourcen, harte Echtzeitanforderungen und hardwarenahe Programmteile können die sinnvolle Anwendung der UML mit Codegenerierung in modellbasierter Softwareentwicklung für diese Systeme einschränken. Kenntnisse und Erfahrungen an den Grenzen der hardwarenahen Programmierung zum RTOS und zum generierten UML Code sind erforderlich, um die Vorteile zu optimieren.

2 2 Moderne Softwareentwicklung für kleine und mittlere Embedded-Systeme Rahmenbedingungen heutiger Embedded-Systeme Kleine und mittlere Embedded-Systeme charakterisieren sich heute vor allem durch [4]: Mikrocontroller 8-, 16- bis 32-Bit kbyte ROM kbyte RAM Zeitkritische Abläufe, harte Echtzeitanforderungen, Interrupts Kein dynamischer Speichercontroller Betriebssysteme sind nicht Standard, oft properitäre Laufzeitsysteme (Main-Loop) Hardwarenahe Programmierung in C oder Assembler Sicherheitskritische Funktionen Programm- und Datenspeicher ist begrenzt. Die Abläufe sind häufig zeitkritisch und werden nicht selten durch Interrupts beeinflusst. Dabei wird oft Systemverhalten durch Priorisierung der Interrupts gestaltet. Insgesamt werden in kleinen (deeply-) Embedded-Systemen kaum Betriebssysteme mit dynamischer Speicherverwaltung eingesetzt, da diese den meist geforderten Determinismus der Anwendung nicht gewährleisten. In den meisten Applikationen herrscht zudem das MAIN-Loop RTOS, um schlanke Systeme entwickeln zu können. Die Gründe für den überwiegenden Einsatz von C liegen nach wie vor in technischen Gegebenheiten (Verfügbarkeit von Compilern, Ressourcen des Systems, Sicherheitsvorschriften) und in anderen Gebieten (Verfügbarkeit von Know-How, vorhandene Investitionen, fertige Programmteile) [4]. Nicht zuletzt kennzeichnen sich kleinere Embedded-Systeme zunehmend durch sicherheitskritische Funktionen, da der Einsatz kleiner Steuerungen zunehmend in sichere Bereiche vordringt (elektrische Lenkung, elektrische Bremsen, Bremsassistenten, Autopiloten und viele andere Einsatzgebiete).

3 3 Komplexität von Embedded-Softwareprojekten Die Software von Embedded-Systemen wird dabei zunehmend komplexer und dabei in seinen bisherigen Rahmenbedingungen gleichzeitig immer anspruchvoller (schneller, sicherer, zuverlässiger und kleiner). Was ist unter der wachsenden Komplexität zu verstehen? Zum einen wächst natürlich die Softwaregröße je Mikrocontroller mit leistungsfähigerer Vernetzung und aufwändigeren Protokollen (z.b. TCP/IP und USB als Standardschnittstellen der nächsten Gerätegenerationen). Zum anderen tragen wachsende Anforderungen an Echtzeit, Sicherheit, Verfügbarkeit und Funktionalität erheblich zum vorhandenen Fehlerpotential bei der Entwicklung bei. Für komplexe Software-Systeme sind Erfahrungen und Kompetenzen in Softwareentwurf und Architektur erforderlich. Bisher nicht ausreichend berücksichtigte Themen der Softwarearchitektur werden zukünftig den Erfolg von Embedded-Softwareprojekten maßgeblich mitbestimmen und sind heute schon als Wettbewerbsfaktor zu betrachten[1] Average Number of K Lines of Code Bit 16 Bit 32 Bit Processor Architecture Abbildung 1: Steigende Programmgröße / Prozessorarchitektur [2] In der Praxis sind dagegen derzeit oft Vorgehensmodelle und Entwicklungsmethoden anzutreffen, die aus alten Zeiten der 8- und 16- Bit Programmierung (meist ohne kommerzielles Echtzeit- Betriebssystem(RTOS)) stammen und nun bei ungleich komplexeren Systemen beibehalten werden.

4 4 Zusammenfassend beschreibt das folgende Zitat aktuelle und zukünftige Tendenzen: Industrien der unterschiedlichsten Anwendungsbereiche haben einen neuen gemeinsamen Kernbereich: Softwareintensive, in Netzwerke eingebundene multimediale Daten verarbeitende eingebettete Systeme [1] Perspektiven von Embedded-Softwareprojekten Durch die ständig wachsende Komplexität der Software für kleine und mittlere echtzeitfähige Systeme (Embedded-Systeme für z.b. Automotive, Luftfahrt, Steuerungstechnik) ist die Bedeutung von Softwarearchitektur, objektorientierten Ansätzen und Echtzeitbetriebssystemen in der Programmierung und Wiederverwendung von Bibliotheken und Komponenten stark gestiegen. Um den neuen Anforderungen gerecht zu werden, sind zunehmend Methoden und Werkzeuge des Entwurfs von komplexen IT-Anwendungen anzutreffen, wie z.b. die Modellierung mit UML - teilweise mit integrierter Code-Generierung (CASE Tools). Weiterhin werden immer häufiger komplexe Bibliotheken (Treiber, Protokollstacks wie TCP/IP oder USB und Graphical-User-Interfaces GUI) zugekauft oder wieder verwendet. Diese sind meist prozedural geschrieben und müssen mit der objektorientierten Welt verheiratet werden. Weil dazu im Bereich der Embedded-Systeme sehr hohe Anforderungen an die Echtzeitfähigkeit gestellt werden, ist die Integration dieser Komponenten mittels objektorientierten Konstrukten in vielen Projekten problematisch, insbesondere da das herkömmliche Schichtenmodell (Hardware-Treiber-RTOS-Applikation) aus Gründen der Echtzeitanforderung nicht immer eingehalten werden kann. Was bedeutet Kreativität und Steigerung der Produktivität in der Softwareentwicklung? Was aber soll nun das Mittel sein? Was sind die Methoden?

5 5 Bisher wurde Embedded-Software aus kleinen überschaubaren Anfängen heraus entwickelt. An die enorm wachsende Komplexität wurde vor 10 Jahren nicht gedacht. Einige Routinen in der Main-Loop, ein paar Interrupt Service Routinen, die Asynchronitäten und gemeinsamen Datenzugriffe per globale Flags synchronisiert, fertig war das System. Quelle: Willert Software Tools Irgendwann wurde das System jedoch größer, die Abhängigkeiten wuchsen (aber Achtung: die meisten Abhängigkeiten wachsen nicht linear, sondern exponentiell) und das System hat niemand mehr wirklich verstanden. Oder nur noch einige wenige, die Helden. Durch neue Mitarbeiter sinkt dann natürlich die Effizienz spürbar, weil die einzigen kompetenten Mitarbeiter nun mit der langwierigen Einarbeitung neuer Leute beschäftigt sind. Solche Systeme kommen oftmals zu einem gewissen Punkt an ihre Grenzen und werden schwere Pflegefälle, die Ressourcen binden und Innovationen verhindern.

6 6 Ein Beispiel: Verkettungen dieser if-else Konstrukte in sequentiellen oder überlappenden (Interrupt-Service-) Funktionsaufrufen bestimmen das Systemverhalten. Wenn in Fkt_A Änderungen erfolgen, kann das Einfluss auf das Laufzeitverhalten und auf die Funktionalität von Fkt_B, C oder D haben. Das Verhalten der einzelnen Funktionen ist separat nicht nachvollziehbar und nicht entkoppelt. Fehler und Änderungen können systemweiten Einfluss haben. Eine Software dieser Art ist riskant, schlecht wart- und erweiterbar. Generell gilt: Je loser ein System gekoppelt ist, desto einfacher können seine Bestandteile konfiguriert und neu kombiniert werden (Wiederverwendbarkeit) [9] und das Risiko sinkt (Fehlervorbeugung, Fehlervermeidung).

7 7 Quelle: Willert Software Tools Werden die einzelnen Bestandteile eines Systems beispielsweise durch die Verwendung eines RTOS entkoppelt, so wird dadurch die Verständlichkeit, aber auch die Wartbarkeit und Erweiterbarkeit der Software wesentlich verbessert. Die Wahrscheinlichkeit des Auftretens systemweiter Fehler sinkt. Fehler innerhalb von Komponenten sind mit gesenktem Aufwand zu beheben [9].

8 8 Verbesserung der Entwicklung von Embedded-Systemen mit RTOS, objektorientierten Ansätzen und UML Die beschriebene Steigerung der Produktivität von Embedded- Softwareprojekten kann durch den Einsatz von geeigneten Softwarearchitekturen und der Verwendung von objektorientierten Methoden erreicht werden. Weiterhin ist der Einsatz von UML zum Systementwurf und Systemdesign geeignet. Die UML kann zur Analyse, Entwurf und Modellierung von Softwareprojekten verwendet werden. Dabei stellt die UML Notation diverse Diagramme und Elemente zur Verfügung, um ein Softwaresystem aus verschiedenen Sichten zu beschreiben [11]. Statisches Modell: - Anwendungsfalldiagramm - Klassendiagramm - Objektdiagramm - Komponentendiagramm - Einsatzdiagramm Dynamisches Modell: - Zustandsdiagramm - Sequenzdiagramm - Kollaborationsdiagramm - Aktivitätsdiagramm Die UML bildet sich letztendlich auf objektorientierte Konstrukte ab. Diese müssen in C darstellbar sein, damit die Anwendung erfolgreich ist. Da dies (je nach vorhandenen Ressourcen) nur teilweise möglich ist, ist der verwendbare UML Vorrat nicht immer nutzbar [4][6]. Folgend die wichtigsten objektorientierten Konstrukte: Klassen Instanzierung von Objekten Timer Mailboxen Events, Messages Ports

9 9 Einige dieser Konstrukte werden durch ein (Embedded-) Betriebssystem (RTOS, Real Time Operating System) zur Verfügung gestellt (Timer, Mailboxen, Events, Messages und ein Scheduler mit Taskverwaltung), andere werden mit C nachgebildet. Aus eventuellen Mangel an dynamischem Speicher können nicht alle objektorientierten Bestandteile sinnvoll und ressourcensparend in C implementiert werden. Daher wird gern auf einige verzichtet (Vererbung, Überladung, intensive dynamische Instanzierung von Objekten zur Laufzeit). Embedded-UML Es sind die Besonderheiten von Embedded-Systemen in objektorientierten Systemen zu berücksichtigen. Dies gilt generell, sobald in einer Software ein RTOS zum Einsatz kommen soll. Dabei ist insbesondere auf Systembeschreibung / Architektur Entkopplung der Programm-Module bezüglich Laufzeit, Funktion, Daten und Priorität Target-Unabhängigkeit, Simulation, Rapid-Prototyping Verwendung vorhandener (getesteter) C-Module und Bibliotheken zu achten. Ein Embedded-System benötigt hardwarenahe zum Teil hart echzeitkritische Reaktionen und Determinismus bei hardwarenahen Diensten. In diesem Kontext sind dies: Harte Echtzeit-Reaktionen Interrupts, Interruptprioritäten Hardwarenahe Routinen (z.b. DMA (Direct Memory Access)) Determinismus

10 10 Grenzen des sinnvollen RTOS und UML Einsatzes Werden objektorientierte UML Konstrukte in C weggelassen, ist sie fast beliebig anwendbar und ohne RTOS in C umsetzbar. So können z.b. statt Messages sogenannte Guards (Bedingungen, Wächter ) zur Steuerung von UML-Statecharts genutzt werden; Messages und Mailboxen entfallen dann (synchrones Modell). Allerdings kann dann durchaus der Nutzen der UML Notation in Frage gestellt sein, siehe dazu [5]. Eine oft genutzte Einschränkung ist der Verzicht auf Klassen und dynamischer Instanzierung. Stattdessen arbeiten kleine Embedded- Systeme mit statischen Objekten und Singleton-Objekten. Damit braucht das System keine dynamische Speicherreservierung (malloc), die in den meisten Embedded-Targets ohne MMU (Memory Mangement Unit) zur gefürchteten Speicherfragmentierung und damit zum sporadischen Fehlverhalten des Systems führen kann. Bestimmte (benötigte) Zusatzinformationen des Embedded- Systems sind nicht ausreichend beschreibbar (Interrupt-Services, Interrupt-Prioritäten, Verschachtelungen und hardwarenahe Routinen). Die UML stellt keine entsprechenden Möglichkeiten zur Verfügung. Auch sind nicht alle Programmteile über UML oder RTOS- Funktionalitäten umsetzbar. Beispielhaft ist hier die harte Echtzeit untersucht: Objekte können in UML aktiv sein, sie haben zur Laufzeit einen eigenen Task/Thread. Dies ist über ein RTOS effizient darstellbar. Die maximale (Echtzeit-) Auflösung hängt stark von der Task- (Kontext-) Umschaltung des verwendeten Betriebssystems ab , 8-Bit, RTX51 (KEIL), bis 100µs [7] - C166, 16-Bit, ARTX (KEIL), bis 25 µs [7] - M16, 16-Bit, EmbOS (Segger), bis 32 µs [8] - ARM7, 32-Bit, ARTX-ARM (KEIL), bis 5 µs [7] Die Interrupt-Latenzzeiten in den untersuchten Betriebssystemen liegen zwischen 50µs (8051) und 1,8µs(ARM7).

11 11 In vielen Applikationen wird daher auf Treiberebene die schnelle Datenverarbeitung oder Prozessreaktion ausgeführt, bevor über das RTOS ein Task zur Reaktion der Applikation initiiert wird. Wenn zum Beispiel über einen UART eine Befehlssequenz empfangen wird, werden zunächst alle Daten der Sequenz in der Treiberebene erfasst und vorverarbeitet, bevor die Applikation benachrichtigt wird. Damit wird nicht bei jedem Datumsempfang Rechenzeit für die Taskumschaltung benötigt. Es ist naheliegend, dass der Laufzeitanteil des RTOS keinen erheblichen Teil der verfügbaren Ressourcen verwenden soll. Anhand der Task- Umschaltzeiten kann abgeleitet werden, dass diese Mechanismen nur für wesentlich geringere Laufzeitanforderungen verwendet werden sollten. Die Zeit für einen Task-Wechsel liegt bei 8-Bit Mikrocontrollern deutlich im Millisekunden- und beim 32-Bit Mikrocontroller im 100µs Bereich (zusätzlich abhängig von der Anzahl der Nebenläufigkeiten, die diese Zeiten ebenfalls noch erhöhen können). Alle härteren Anforderungen sollten weiterhin hardwarenah entworfen und implementiert werden. Neben den zeitlichen Aspekten muss jedoch auch der Speicherverbrauch durch den Einsatz eines RTOS und die Verwendung eines UML-CASE- Tools betrachtet werden. In [5] wird durch Erfahrung (Randbedingungen: Rhapsody in C, Codegenerierung, UML-Framework mit kleinem Betriebssystem) eine Grenze bei Systemen mit < 32kb ROM Applikation hergeleitet, unter der ein Einsatz von UML nicht mehr sinnvoll erscheint. Damit stellt sich die Frage nach dem effizienten Einsatz von UML in Embedded-Systemen. Bei sehr kleinen Projekten können sich somit der erhöhte Speicherverbrauch sowie die zusätzliche benötigte Rechenzeit durchaus negativ auswirken, wenn es gilt mit sehr begrenzten Ressourcen auszukommen.

12 12 Architektur Bei größeren Systemen ist auf die Grenze der Embedded-Paradigmen zur UML zu achten und ist damit ein wesentlicher Erfolgsfaktor von Embedded-UML-Projekten. Kann die Grenzbetrachtung in eine Softwarearchitektur einfließen und als Designvorgabe umgesetzt werden, treten deutlich weniger Schwierigkeiten beim Umsetzen von komplexen Projekten auf. Abbildung 2: Verbrauchte Ressourcen in Codegröße (stat.) und Laufzeit (dyn.) [2] So hat das objekt-orientierte Design deutliche Vorteile im System- (Applikation-) Layer, wo ca. 80% des Codes nur mit 20% der Laufzeit behaftet sind. Bei den 20% laufzeitkritischem Code kommen die Embedded-Erfahrungen voll zum Tragen.

13 13 Anforderungs- und Systemanalyse, Softwarearchitekturen Embedded-Systeme sind ereignisorientierte und keine datenorientierte Softwaresysteme. Der Fokus liegt auf der Reaktion von Systemen auf Ereignisse und der dabei stattfindenden Kommunikation einzelner Teile des Systems. Die Softwarearchitektur beschreibt die Komponenten und Schnittstellen, aus denen das System besteht, und deren Zusammenspiel [10] In Embedded-Systemen sind zu beachten: Echtzeitfähigkeit / Prioritäten Funktionale Abhängigkeiten Datenfluss Abhängigkeiten Zeitliche Abhängigkeiten Grundlagen zur Softwarearchitektur Softwarearchitektur vereinigt in sich das Know-How eines Unternehmens und besitzt durch die Wiederverwendbarkeit einzelner Bestandteile einen projektübergreifenden Einfluß[10]. Ziel muss es sein, das Know-How des Unternehmens, dass prozessbezogen und nicht targetabhängig ist, so zu kapseln, dass es problemlos auf neuen Plattformen wieder verwendbar ist. Die Scheu davor, eine Embedded-Software neu zu entwerfen ( Redesign ) liegt meist nicht in der Verwendung neuer Hardware (und neuer Mikrocontroller) sondern in der Umsetzung der Applikation darauf. Zur Beherrschung der Komplexität ist die Betrachtung der Architektur aus verschiedenen Perspektiven notwendig[12]. Anforderungsperspektive (Requirements) Perspektive des Systemdesigns Perspektive von Infrastruktur und Verteilung

14 14 Im Folgenden betrachten wir die Perspektive des Systemdesigns, um eine beispielhafte Architektur zu entwerfen. Dazu gehören (bei vollständigem Entwurf)[2][12]: Statische Sichten: Dynamische Sichten: Komponenten, Klassen Struktur und Schnittstellen Verhalten, Mechanismen (Prioritäten) Objekte und Threads Die statische Sicht bildet sich übergeordnet als Schichtenmodell ab, das den Rahmen eines Entwurfsmusters vorgibt. Dabei ist auf die Besonderheiten von Embedded-Systemen einzugehen: Abbildung 3: Vergleich native und Embedded-Systeme[2] Bei nativen Systemen, wie sie beispielsweise aus dem PC-Bereich bekannt sind, werden die Schichten im Normalfall von oben nach unten durchlaufen. Bei diesem synchronen Kommunikations-Mechanismus werden alle Zeiten sowie die Prioritäten durch die Methodenaufrufe vererbt. Hingegen werden bei Embedded-Systemen die Schichten meist von unten noch oben durchlaufen (Interrupt/ Ereignis getrieben). Eine synchrone (zeitliche) Kopplung, wie sie bei nativen Systemen auftritt ist hierbei zu verhindern.

15 15 Dabei gibt es in Systemen, die ereignisgetrieben sind, die Frage, wie diese Schichten entkoppelt und wie Ereignisse (z.b. Interrupts) in den oberen Schichten erkannt werden. Dabei soll auch die Wiederverwendbarkeit der hardwarenahen Schicht betrachtet werden. Eine notwendige Identifikation in der Applikationsschicht von Ereignissen in der Hardwareschicht durch Polling ist dabei zu vermeiden. Hier können Messages und Events eingesetzt werden. Beide setzen jedoch einen Adressaten voraus. Damit müsste die hardwarenahe Schicht den Empfänger in der Applikation kennen und wäre somit nicht mehr uneingeschränkt wieder verwendbar. Die Wiederverwendbarkeit von Treibern oder Interrupt Service Routinen kann durch Callback-Funktionen oder Publisher-Subscribern verbessert werden. Abbildung 4: Entkopplung und Wiederverwendbarkeit hardwarenaher Schichten[2]

16 16 Herleitung eines geeigneten Schichtenmodells für kleine und mittlere Embedded-Systeme Diese Design-Pattern zur Entkopplung der Schichten sind häufig in Embedded-Systemen anzutreffen. Auch hier erkennt man, dass die objektorientierte Herangehensweise auf RTOS und Applikation sehr viele Vorteile bietet, die Anbindung und Implementierung der hardwarenahen Schichten jedoch Mechanismen benötigt, die schwer mit Objektorientierung und UML vereinbar sind. Abbildung 5: Schichtenmodell komplexer Embedded-Systeme mit RTOS[2] Bei dem Schichtenmodell ist zu sehen, dass es Interrupt-Service- und Treiber-Routinen geben kann, die am OSAL und RTOS vorbei hardwarenahe Dienste realisieren und eventuell die Applikation im zeitunkritischen Teil unterrichten. Das gleiche gilt auch für bereits vorhandene Programm-Module oder zugekaufte Bibliotheken. Auch diese sollen im Gesamtsystem, teilweise auf allen Schichten, weiter eingesetzt werden. Beispiele sind Grafik- Bibliotheken oder sicherheitstechnische Überwachungen. Es gibt in vielen kleinen Embedded-RTOS keine standardisierte Treiber- Einbindung. Kommunikation, Meßdaten und ähnliches werden oft direkt zwischen Applikation und Hardware-Layer stattfinden. Grund dafür sind die beschriebenen Grenzen, wie zum Beispiel Echtzeitanforderungen.

17 17 Bei der Entwicklung von Embedded-Systemen ist diesen Gegebenheiten in der Praxis Rechnung zu tragen. Um die Applikation tatsächlich hardwareunabhängig zu entwerfen, genügt das klassische OSAL in der Regel nicht. Entweder erweitert man dieses stark oder es werden weitere Schichten in der Applikation geschaffen, die Hardwareabhängigkeiten außerhalb des OSAL kapseln. Für solche Fälle empfiehlt sich die Einführung eines Adapter- oder Abstarktion-Layers in der Applikationsschicht. Dieser soll alle echtzeitkritischen und prozeduralen Dienste, die am Schichtenmodell vorbei gehen müssen, mit der objektorientierte Applikation verbinden und die Anwendung dieser Dienste vereinfachen. Abbildung 6: Schichtenmodell mit hardwarenahen Objekten und Adapter Wird dieses Vorgehen bei Echzeitsystemen sauber umgesetzt, können erfahrungsgemäß mehr als 90% der Applikation in einem neuen Projekt direkt wiederverwendet werden. Dasselbe trifft auf die Wiederverwendbarkeit der hardwarenahen Layer zu. Ziel ist, für die genannten Probleme eine Referenzlösung zu schaffen, die den Entwicklern gleichartiger Systeme zur Verfügung stehen kann und damit den Basisentwurf solcher Systeme erheblich vereinfacht.

18 18 Entwicklung einer Referenzlösung für ein Adapter-Layer Im Folgenden soll eine Referenzlösung für ein Adapter-Layer geschaffen werden, mit deren Hilfe ein Entwickler in der Lage sein soll die echtzeitkritischen und prozeduralen Dienste, die sich außerhalb des Schichtenmodells befinden, zu kapseln. Bei der Entwicklung eines solchen Adapter-Layers müssen auf der Basis der Objektorientierung und der durch UML zur Verfügung gestellten Elemente folgende Vorüberlegungen stattfinden: - Welche Strukturierung soll verwendet werden? - Wie können die Funktionalitäten in Klassen und Objekte gekapselt werden? - Welche Form der Kommunikation zwischen Applikation und Adapter-Layer soll angewendet werden? - Können Elemente und Verhaltensweisen von Objekten gegebenenfalls vereinheitlicht werden? Anhand dieser Punkte sollte schon zu Beginn der Implementierung erreicht werden, dass dem zu entwickelnden Adapter-Layer ein einheitliches Konzept zugrunde liegt. Durch die Verwendung eines modularen und einheitlichen Aufbaus sowie die Vergabe von vereinheitlichten Bezeichnern für Objekte und Kommunikationselemente werden Erweiterungen und Änderungen vereinfacht. Außerdem wird die Einarbeitung in die Anwendung eines solchen Adapter-Layers wesentlich erleichtert. Eine gute Strukturierung kann durch die Aufteilung in Pakete erzielt werden. Alle benötigten Objekte, Klassen und zusätzliche Komponenten für die Bereitstellung eines Dienstes wie beispielsweise die Bereitstellung eines Flash File Systems oder die Kommunikation via TCP/IP können hierbei jeweils in einem Paket abgelegt werden.

19 19 Abbildung 7: Paketstruktur des Referenz-Adapter-Layers Je Dienst, der innerhalb des Adapter-Layers gekapselt werden soll, muss die Entscheidung getroffen werden, ob eine Klasse oder ein Objekt zur Kapselung der Funktionalitäten geeigneter ist. Für einen Dienst, wie beispielsweise die CAN-Kommunikation, wird eine Klasse geeigneter sein, da für jede anzusteuernde Schnittstelle lediglich eine Instanz dieser Klasse erstellt werden muss. Für andere Dienste die auf dem System einzigartig sind kann hingegen ein (Singleton) Objekt verwendet werden. Abbildung 8: Referenz-Klasse und Objekt

20 20 Bei den verwendeten Operationen innerhalb von Klassen und Objekten erleichtern vereinheitlichte Namen die Anwendung, Erweiterung und Änderung von Funktionalitäten. Bei der Instanzierung von Klassen muss jedoch beachtet werden, dass diese nach Möglichkeit nicht zur Laufzeit angelegt werden (dynamische Speicherverwaltung). Besser für die Wahrung der Echtzeitfähigkeit des Systems ist das Anlegen einer Instanz bereits während der Modellierung. Für die Kommunikation zwischen Elementen der Applikation und des Adapter-Layers gibt es verschiedene Ansätze. Für den internen Informationsaustausch können beispielsweise Callback-Funktionen verwendet werden, aber auch Ports oder Interfaces können für diese Form der Kommunikation eingesetzt werden. Abbildung 9: Interner Informationsaustausch mittels Ports Wurde ein Port für ein Element des Adapter-Layers angelegt, so können mittels Interface-Objekten die Ein- und Ausgabe zugewiesen werden. Innerhalb dieser Interface-Objekte werden Events angelegt, die zum eigentlichen Informationsaustausch zwischen den beiden Elementen genutzt werden. Werden innerhalb des Adapter-Layer-Elements bestimmten Events Funktionen zugewiesen (mittels Statecharts), so können auf diese Weise Funktionen aufgerufen ( EingabeDienst1 ) und Rückmeldungen ( AusgabeDienst1 ) realisiert werden.

21 21 Abbildung 10: Statechart von KlasseDienst1 Wie man sieht kann durch ein gut durchdachtes Konzept mit Vereinheitlichung bei der Namensgebung erzielt werden, dass sämtliche Funktionalitäten die mittels Adapter-Layer gekapselt und auf einer hohen Ebene zur Verfügung gestellt werden ohne größere Einarbeitung angewendet werden können. Wird dieses Schema auch bei der Implementierung aller weiteren Dienste angewendet, so erhält man ein Adapter-Layer welches vielseitig einsetzbar ist. Abbildung 11: Sequenzchart für den Aufruf von evdienst1start Eine Applikation auf Basis einer solchen Schicht kann somit in allen Belangen unabhängig von den verwendeten Treibern und Bibliotheken implementiert werden. Im Falle einer Portierung auf eine neue Hardware muss lediglich der Adapter-Layer angepasst werden. Die Applikation wird unverändert übernommen. Dadurch reduziert sich der Portierungsaufwand auf ein Minimum.

22 22 Exemplarische Implementierung eines Adapter-Layer-Dienstes Im Folgenden soll die oben beschriebene Referenzlösung für die Implementierung eines TCP/IP-Dienstes adaptiert werden. Dadurch soll die praktische Umsetzung anhand einer real existierenden Problemstellung veranschaulicht werden. Die gegebene Tool-Chain besteht aus Rhapsody in C von Telelogic, der Bridge WST52 von Willert Software Tools sowie dem RealView MDK 3.10 und der RL-ARM RealView Real-Time Library der Firma Keil. Da innerhalb der Real-Time Library ein TCP/IP Protokoll Stack (TcpNet) zur Verfügung gestellt wird, der allerdings am Schichtenmodell vorbeigeht, soll dieser Dienst innerhalb des Adapter-Layers zur Verfügung gestellt werden, um eine Entkopplung zwischen den Bibliotheks-Funktionen und der Applikation zu ermöglichen. Durch TcpNet werden sowohl alle grundlegenden Funktionalitäten zur Kommunikation via TCP/IP und UDP wie auch zusätzliche Applikationen (z.b. HTTP-Webserver, CGI-Scripting, Telnet) zur Verfügung gestellt. Für den Dienst werden innerhalb des Adapter-Layers ausgewählte Funktionalitäten gekapselt, die durch die Bereitstellung von entsprechenden Operationen und Events realisiert werden. Als Funktionalitäten wurden im vorliegenden Fall die folgenden ausgewählt: - Erstellen eines TCP/IP-Servers - Erstellen eines TCP/IP-Clients - Versenden von Daten via TCP/IP - Empfangen von Daten via TCP/IP - Beenden der TCP/IP-Kommunikation

23 23 Aufruf der Funktionalität Mögliche Rückmeldungen Operation evtcpservercreate evtcpclientcreate evtcpdatasend evtcpdatareceive evtcpconnectionclose evtcpservercreateok evtcpservercreatefailed evtcpclientcreateok evtcpclientcreatefailed evtcpdatasendok evtcpdatasendfailed optcpservercreate optcpclientcreate optcpdatasend evtcpdatareceiveok optcpdatareceive evtcpdatareceivefailed evtcpdatareceivedone evtcpconnectioncloseok optcpconnectionclose evtcpconnectionclosefailed Im nächsten Schritt wird eine Klasse mit den benötigten Operationen angelegt und anschließend die Implementierung hinzugefügt. Außerdem werden noch die Interface-Objekte zur Sammlung der Funktions-Aufrufe und Rückmeldungen benötigt, die dem speziell angelegten Port zugewiesen werden. Abbildung 12: Instanz mit Port für eine TCP/IP-Verbindung Das Verhalten dieser Klasse zur Realisierung einer Kommunikation via TCP/IP wird durch ein Statechart definiert. Darin können alle Zustände sowie die Zustandsübergänge dieses Elements des Adapter-Layers grafisch modelliert werden.

24 24 Abbildung 13:Statechart für eine TCP/IP-Verbindung Der Reaktionen auf den Aufruf einer Funktionalität lässt sich am besten durch ein Sequenzdiagramm darstellen. Darin wird veranschaulicht welche Events, Operationen und Funktionen ausgeführt werden und welche Objekte an der internen Kommunikation beteiligt sind. Abbildung 14: Erstellen eines TCP/IP-Servers (Sequenzchart)

25 25 Besonders anhand des Sequenzcharts kann man erkennen, dass das Objekt aus der Applikation lediglich mit Elementen aus dem Adapter-Layer kommuniziert. Direkte Zugriffe auf die Bibliotheks-Funktionen werden nicht durchgeführt. Durch die daraus resultierende Entkopplung könnte zu einem späteren Zeitpunkt beispielsweise der hierbei verwendete TCP/IP Protokoll Stack ausgetauscht werden. Alle nötigen Änderungen können direkt im Adapter- Layer durch Anpassungen der Operationen durchgeführt werden. Die Applikation kann anschließend unverändert wieder verwendet werden. FAZIT Die hier aufgezeigten Ansätze sind für eine Verbesserung der Softwareentwicklung im Bereich der Embedded-Systeme geeignet und empfehlenswert, um die Systeme für die aktuelle Generation zu entwickeln. Die Grenzen der beschriebenen Methoden sollten bekannt sein und in einer guten Architektur berücksichtigt sein. Die Kunst ist, zu erkennen, was wo gemacht wird (Applikation vs. Treiberund Interrupt-Ebene) und wie diese Schichten so zusammenarbeiten, dass die Echtzeit und die Entkopplung des Applikations-Know-Hows gleichermaßen berücksichtigt wird. Dazu zeigt dieser Beitrag mögliche Lösungsansätze.

26 26 Quellenverzeichnis [1] Vortrag Eingebettete Systeme Die neue IT-Revolution,Prof. Dr.-Ing. Werner Grass, Lehrstuhl für Rechnerstrukturen, Universität Passau, [2]Vortrag Softwarearchitektur und RTOS, Andreas Willert, Willert Software Tool GmbH und Olaf Winne, Quategra GmbH, [3] Standish Group (http://www.standishgroup.com) veröffentlicht in regelmäßigen Abständen den sogenannten Chaos Report (hier 2000) [4] Codegenerierung aus UML nach ANSI-C für kleine Embedded- Systeme, Dr.Martin Geier, , method park GmbH [5] UML für kleine Embedded- Systeme, Elektronik Praxis 07/07, Andreas Willert, Vogel Verlag [6] Object Based Development Using the UML and C, Mark Richardson, Senior Application Engineer, I-Logix (now Telelogic). [7] KEIL RTX Datasheets, [8] Segger EmbOS Datasheet, [9] Der pragmatische Programmierer, Andrew Hunt und David Thomas, Carl Hanser Verlag, ISBN [10] Modernen Softwarearchitektur, Johannes Siedersleben, dpunkt.verlag, ISBN [11] jetzt lerne ich UML, Joseph Schmuller, Mark+Technik Verlag, ISBN [12] isqi: Grundlagen der Softwarearchitektur, 2003

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

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

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

Orientierte Modellierung mit der Unified Modeling Language

Orientierte Modellierung mit der Unified Modeling Language UML-Basics: Einführung in Objekt- Orientierte Modellierung mit der Unified Modeling Language Michael Hahsler Ziel dieses Seminars Verständnis von Objekt-Orientierung Was sind Klassen? Was ist Vererbung?

Mehr

Software Engineering. Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Prof. Dr.-Ing. Dagmar Meyer

Software Engineering. Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Prof. Dr.-Ing. Dagmar Meyer Fakultät Elektrotechnik Bachelor-Studiengänge, 4. Semester Vorausgesetzte Kenntnisse Allgemeine Kenntnisse aus dem Bereich der Softwareentwicklung - Programmierkenntnisse (Java, C) - Beherrschung der notwendigen

Mehr

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML)

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML) Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)

Mehr

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

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

Mehr

Key Note und Abstracts Stream 4

Key Note und Abstracts Stream 4 Key Note und Abstracts Stream 4 Key-Note: Future of Google Search Referent: Emmanuel Mogenet, Engineering Director, Google Zurich Agile Embedded Projekte mit Scrum & Kanban Tips & Tricks aus der Praxis

Mehr

Reflex The Real-Time Event Flow EXecutive

Reflex The Real-Time Event Flow EXecutive Einführung The Real-Time Event Flow EXecutive Karsten Walther, und Jörg Nolte Brandenburgische Technische Universität Cottbus 1. Statusseminar des InnoProfile Projekt TANDEM 2007 Gliederung Einführung

Mehr

6 Architektur-Mittel (WOMIT)

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

Mehr

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

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

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

Vorlesung Objektorientierte Softwareentwicklung. Kapitel 0. Java-Überblick

Vorlesung Objektorientierte Softwareentwicklung. Kapitel 0. Java-Überblick Vorlesung Objektorientierte Softwareentwicklung Sommersemester este 2008 Kapitel 0. Java-Überblick Was sind die Ziele? Warum Java? Komplexe Anwendungen e-business verteilt zuverlässig sicher mobil persistent

Mehr

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Die Unified Modeling Language Die UML (hier in der Version 0.9) ist ein Satz von Notationen zur Beschreibung objektorientierter Softwaresysteme.

Mehr

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble

Tier-Konzepte. Vertiefungsarbeit von Karin Schäuble Vertiefungsarbeit von Karin Schäuble Gliederung 1. Einführung 3. Rahmenbedingungen in der heutigen Marktwirtschaft 3.1 Situation für Unternehmen 3.2 Situation für Applikationsentwickler 4. Lösungskonzepte

Mehr

Programmierung von Steuerungen künftig objektorientiert?

Programmierung von Steuerungen künftig objektorientiert? 1 Programmierung von Steuerungen künftig objektorientiert? R. Hungerbühler, Dozent BFH R. Hungerbühler Dozent Automation BFH 2 Sichten auf Fragestellung Wissenstand Mitarbeiter /Ausbildung Entwickler,

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

CORBA. Systemprogrammierung WS 2006-2007

CORBA. Systemprogrammierung WS 2006-2007 CORBA Systemprogrammierung WS 2006-2007 Teilnehmer: Bahareh Akherattalab Babak Akherattalab Inhaltsverzeichnis: Verteilte Systeme Vergleich zwischen lokale und verteilte Systeme Verteilte Anwendungen CORBA

Mehr

Die Revolution der Konsumelektronik

Die Revolution der Konsumelektronik Übersicht Betrachtung der technischen Entwicklung von Embedded Systemen im Konsumelektronikbereich Softwareentwicklung für Audio & Visuelle Geräte der Unterhaltungselektronik Hochintegrierter Embedded-Webserver-

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

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

Grundzüge der Programmierung. Konzepte der objektorientierten Programmierung (oop) OBJEKTE - KLASSEN

Grundzüge der Programmierung. Konzepte der objektorientierten Programmierung (oop) OBJEKTE - KLASSEN Grundzüge der Programmierung Konzepte der objektorientierten Programmierung (oop) OBJEKTE - KLASSEN Inhalt dieser Einheit JAVA ist objektorientiert! Grundbegriffe der objektorientierten Programmierung:

Mehr

Kapitelübersicht. Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge. Was bedeutet Objektorien+erung?

Kapitelübersicht. Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge. Was bedeutet Objektorien+erung? Kapitelübersicht Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge Was bedeutet Objektorien+erung? ObjektorienCerte Analyse und Design die Objektmodellierung

Mehr

Military Air Systems

Military Air Systems Trennung von Applikationen unterschiedlicher Kritikalität in der Luftfahrt durch Software en am Beispiel des Real-time Operating Systems PikeOS Dr. Bert Feldmann DGLR Workshop Garching, 09.10.2007 Seite

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

Dr. Nicholas Merriam Rapita Systems Ltd., IT Centre, York Science Park, Heslington, York, YO10 5DG (UK) nick.merriam@rapitasystems.

Dr. Nicholas Merriam Rapita Systems Ltd., IT Centre, York Science Park, Heslington, York, YO10 5DG (UK) nick.merriam@rapitasystems. Das zeitliche Verhalten von Echtzeitsoftware zu analysieren und sicher zu stellen, dass die Anforderungen an das Echtzeitverhalten erfüllt werden kann sehr aufwendig und teuer sein. In diesem Artikel sollen

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

Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design

Softwaretechnik (Medieninformatik) Überblick: 6. Objektorientiertes Design Softwaretechnik (Medieninformatik) Überblick: 6.1 Einleitung 6.2 Verfeinerung des Klassenmodells 6.3 Sequenzdiagramme 6.4 Umsetzung der Analysekonstrukte in das Design 6.5 Fallstudie 6.6 Software Kontrakte

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Timo Wagner & Sebastian Kühn Entwurf einer Multi-Tier Anwendung in ASP.NET

Timo Wagner & Sebastian Kühn Entwurf einer Multi-Tier Anwendung in ASP.NET Timo Wagner & Sebastian Kühn Entwurf einer Multi-Tier Anwendung in ASP.NET Überblick 1.Einfürung in die Multi-Tier Architektur 2.Ausgangspunkt und Probleme 3.Rundgang durch die Architektur 4.Architektur

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Inhaltsverzeichnis. Gernot Starke. Effektive Softwarearchitekturen. Ein praktischer Leitfaden ISBN: 978-3-446-42728-0

Inhaltsverzeichnis. Gernot Starke. Effektive Softwarearchitekturen. Ein praktischer Leitfaden ISBN: 978-3-446-42728-0 sverzeichnis Gernot Starke Effektive Softwarearchitekturen Ein praktischer Leitfaden ISBN: 978-3-446-42728-0 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42728-0 sowie im

Mehr

Einführung in die SWE

Einführung in die SWE Einführung in die SWE Inhalte der Vorlesung Allgemeine Ziele der Lehrveranstaltung Entwickeln einer kleinen Applikation nach professionellem Vorgehensmodell Erlernen des objektorientierten Herangehens

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Optimierung der Code-Generierung virtualisierender Ausführungsumgebungen zur Erzielung deterministischer Ausführungszeiten

Optimierung der Code-Generierung virtualisierender Ausführungsumgebungen zur Erzielung deterministischer Ausführungszeiten Optimierung der Code-Generierung virtualisierender Ausführungsumgebungen zur Erzielung deterministischer Ausführungszeiten Martin Däumler Matthias Werner Lehrstuhl Betriebssysteme Fakultät für Informatik

Mehr

Java lernen mit BlueJ

Java lernen mit BlueJ Java lernen mit BlueJ Eine Einführung in die objektorientierte Programmierung David J. Barnes Michael Kölling 4.0 Lernen in Eigenregiegi Vorlesungen Seminare Übungen Bücher Webseiten Diskussionslisten

Mehr

Performance Messungen von FreeRTOS und

Performance Messungen von FreeRTOS und Performance Messungen von FreeRTOS und µc/os-iii auf ARM-Architekturen Tim Wacher (wht4@bfh.ch) Master of Science in Engineering MRU Production Technology 16. August 2011/ CH-3400 Burgdorf Outline 1 Ziel

Mehr

1. Java ist... 2. Stammbaum der Programmiersprachen 3. Die "Softwarekrise"

1. Java ist... 2. Stammbaum der Programmiersprachen 3. Die Softwarekrise im Überblick im Überblick Inhalt 1. Java ist... 2. Stammbaum der Programmiersprachen 3. Die Softwarekrise 1. Merkmale von Software 2. Fortlaufende Veränderungen 3. Erschwerte Rahmenbedingungen bei der

Mehr

Informationsmanagement in Organisationen Überblick

Informationsmanagement in Organisationen Überblick Informationsmanagement in Organisationen Überblick Wolfgang H. Janko Andreas Geyer-Schulz Stefan Koch Edward Bernroider Abteilung für Informationswirtschaft Institut für Informationsverarbeitung und Informationswirtschaft

Mehr

Unit-Test Theorie und Praxis. Stephan Seefeld, INGTES AG

Unit-Test Theorie und Praxis. Stephan Seefeld, INGTES AG Unit-Test Theorie und Praxis Stephan Seefeld, INGTES AG Inhalt Was sind Unit-Test? NUnit für.net Demo Seite 2 Quellen Für diesen Vortrag verwendete Quellen: dotnet User Group Berlin Brandenburg http://www.dotnet-berlinbrandenburg.de/

Mehr

Definition: Software-Entwurf (SW Design) Vorlesung Softwaretechnik Software-Entwurf Dr. Lutz Prechelt. Entwurf: Wann? Entwurf vs.

Definition: Software-Entwurf (SW Design) Vorlesung Softwaretechnik Software-Entwurf Dr. Lutz Prechelt. Entwurf: Wann? Entwurf vs. Definition: Software-Entwurf (SW Design) Ziele Entwurf vs. Architektur Vorlesung Softwaretechnik Software-Entwurf Dr. Lutz Prechelt Vorgehen Festlegung der Struktur eines Softwaresystems Welche Teile gibt

Mehr

PRÜFUNG. Grundlagen der Softwaretechnik

PRÜFUNG. Grundlagen der Softwaretechnik Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner PRÜFUNG Grundlagen der Softwaretechnik Musterlösung Name: Matrikelnummer: Note: Prüfungstag:

Mehr

Echtzeitbetriebssysteme (am Beispiel QNX) Dr. Stefan Enderle HS Esslingen

Echtzeitbetriebssysteme (am Beispiel QNX) Dr. Stefan Enderle HS Esslingen Echtzeitbetriebssysteme (am Beispiel QNX) Dr. Stefan Enderle HS Esslingen 1. Einführung 1.1 Embedded Systeme Embedded Systeme besitzen / benutzen einen Mikrocontroller Embedded Systeme erfüllen meist eine

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

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

Embedded Software Engeneering mit dem Raspberry Pi

Embedded Software Engeneering mit dem Raspberry Pi Embedded Software Engeneering mit dem Raspberry Pi Übersicht Rasperry Pi Betriebssystem Hardware ARM Μ-Controller vs. Μ-Prozessor vs. SoC Embedded Software Engineering vs. Software Engineering Fazit Raspberry

Mehr

Virtualisierung im Echtzeitbereich. Andreas Hollmann FH Landshut EADS Military Air Systems

Virtualisierung im Echtzeitbereich. Andreas Hollmann FH Landshut EADS Military Air Systems Virtualisierung im Echtzeitbereich Andreas Hollmann FH Landshut EADS Military Air Systems 2 Überblick Hintergrund und Motivation Vorstellung von Lösungsansätzen Auswahl und Evaluierung Einschränkungen

Mehr

Smartphone Entwicklung mit Android und Java

Smartphone Entwicklung mit Android und Java Smartphone Entwicklung mit Android und Java predic8 GmbH Moltkestr. 40 53173 Bonn Tel: (0228)5552576-0 www.predic8.de info@predic8.de Was ist Android Offene Plattform für mobile Geräte Software Kompletter

Mehr

Sowohl RTX64 als auch RTX bieten harten Echtzeitdeterminismus und symmetrische Multiprocessing- Fähigkeiten (SMP).

Sowohl RTX64 als auch RTX bieten harten Echtzeitdeterminismus und symmetrische Multiprocessing- Fähigkeiten (SMP). Produktbeschreibung Februar 2014 RTX RTOS-Plattform Mit der RTX-Echtzeitsoftware von IntervalZero wird aus Microsoft Windows ein Echtzeitbetriebssystem (RTOS). RTX64 von IntervalZero unterstützt 64-Bit-Betriebssysteme

Mehr

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

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

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

1 Objektorientierte Software-Entwicklung

1 Objektorientierte Software-Entwicklung 1 Objektmodellierung 1 Objektorientierte Software-Entwicklung Prof. Dr. Heide Balzert Fachbereich Informatik Fachhochschule Dortmund Heide Balzert 2000 2 Lernziele Wissen, was unter objektorientierter

Mehr

Das Beste zweier Welten: OSEK/VDX und Windows CE auf einem Mikrocontroller

Das Beste zweier Welten: OSEK/VDX und Windows CE auf einem Mikrocontroller Das Beste zweier Welten: OEK/VDX und auf einem Mikrocontroller Jochen choof, Markus Zetlmeisl 3OFT GmbH, Erlangen Einleitung Die Elektronik hat in den vergangenen Jahren auf breiter Front Einzug in Kraftfahrzeuge

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

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

POSIX Echtzeit: Kernel 2.6 und Preempt-RT

POSIX Echtzeit: Kernel 2.6 und Preempt-RT POSIX Echtzeit: Kernel 2.6 und Preempt-RT Slide 1 - http://www.pengutronix.de - 21.01.2007 Echtzeit-Systemplanung Wenn das zeitliche Verhalten spezifiziert ist, kann auch spezifiziert werden, welche Applikationsteile

Mehr

Klassenentwurf. Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? Objektorientierte Programmierung mit Java

Klassenentwurf. Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? Objektorientierte Programmierung mit Java Objektorientierte Programmierung mit Java Eine praxisnahe Einführung mit BlueJ Klassenentwurf Wie schreiben wir Klassen, die leicht zu verstehen, wartbar und wiederverwendbar sind? 1.0 Zentrale Konzepte

Mehr

Vorbereitung zur Prüfung Echtzeitbetriebssysteme

Vorbereitung zur Prüfung Echtzeitbetriebssysteme Vorbereitung zur Prüfung Echtzeitbetriebssysteme Zugelassene Hilfsmittel: Taschenrechner Bitte verwenden Sie keinen roten Farbstift! 1. Echtzeitbetriebssysteme - Allgemein (15 Punkte) 1.1. Warum setzen

Mehr

Lösungsvorschlag für Übungsblatt 4 Software Engineering 1 (WS 2012/13)

Lösungsvorschlag für Übungsblatt 4 Software Engineering 1 (WS 2012/13) Prof. Ina Schaefer Software Systems Engineering TU Braunschweig Lösungsvorschlag für Übungsblatt 4 Software Engineering 1 (WS 2012/13) Ausgabe: Kleine Übung: 07. Dezember/10. Dezember 2012 Abgabe: Kleine

Mehr

Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden

Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden 27.05.13 Autor / Redakteur: Nach Unterlagen von National Instruments / Hendrik Härter Messdaten

Mehr

PRÜFUNG. Grundlagen der Softwaretechnik

PRÜFUNG. Grundlagen der Softwaretechnik Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner PRÜFUNG Grundlagen der Softwaretechnik Name: Matrikelnummer: Note: Prüfungstag: 21.09.2012 Prüfungsdauer:

Mehr

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI Universität Osnabrück Drei-Schichten-Architektur 3 - Objektorientierte Programmierung in Java Vorlesung 6: 3-Schichten-Architektur Fachkonzept - GUI SS 2005 Prof. Dr. F.M. Thiesing, FH Dortmund Ein großer

Mehr

Embedded Linux. Arthur Baran

Embedded Linux. Arthur Baran Arthur Baran Inhalt Embedded System Aufbau von Embedded Linux Systemen Echtzeit Einige Beispiele Arthur Baran 2 Was ist Embedded System? klein verborgen im Gerät soll eine bestimmte Aufgabe erledigen Arthur

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

Entwurfsmuster (Design Pattern) ETIS SS05

Entwurfsmuster (Design Pattern) ETIS SS05 Entwurfsmuster (Design Pattern) ETIS SS05 Gliederung Motivation Pattern allgemein Proxy-Pattern Zusammenfassung 2 Motivation I Wie gut sind eure Programme strukturiert? Wartbarkeit? - Verständlichkeit

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

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

C vs. C++ Sebastian Meyer. Proseminar C - Grundlagen und Konzepte. Universität Hamburg

C vs. C++ Sebastian Meyer. Proseminar C - Grundlagen und Konzepte. Universität Hamburg C vs. C++ Sebastian Meyer Universität Hamburg Proseminar C - Grundlagen und Konzepte 2013 1 / 31 Gliederung 1 Einführung 2 Vergleich der Spracheigenschaften 3 Neue Sprachelemente in C++ 4 Fazit 5 Zusammenfassung

Mehr

Model Driven Development

Model Driven Development Model Driven Development Vorteile und Gründe für einen Einstieg Philip Zollinger Geschäftsführer EVOCEAN GmbH SEE, 28. 30. April 2008, Bern 1 EVOCEAN GmbH Die Herausforderung Automation der Schlüssel zum

Mehr

OPC UA und die SPS als OPC-Server

OPC UA und die SPS als OPC-Server OPC UA und die SPS als OPC-Server Public 01.10.2010 We software We software Automation. Automation. Agenda Firmenportrait Kurz-Einführung zu OPC Kurz-Einführung zu OPC UA (Unified Architecture) OPC UA

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE

BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE CO-MAT-TECH 2004 14-15 October 2004 BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE Roman NAGY External doctorand

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

SysML Die Zukunft des Systems Engineering?

SysML Die Zukunft des Systems Engineering? ECC 2012 Winterthur 5. Juni 2012 SysML Die Zukunft des Systems Engineering? Omar Naas, Senior Consultant, EVOCEAN GmbH 1934 Citroën 2CV Citroën Direktor Pierre-Jules Boulanger definierte 7 Anforderungen,

Mehr

Projekt:

Projekt: <Hier den Namen des Projektes eingeben!> <Adresse> <Telefon / Fax> <Ansprechpartner> Pflichtenheft Die Aufgabe des Pflichtenheftes ist es zu beschreiben, was die zu entwickelnde Software für den Anwender leisten soll. Diese Vorlage basiert auf der aus TSE I bekannten Vorlage. Projekt:

Mehr

Objektorientierter Softwareentwurf mit UML. Ricardo Hernández Garcia, Joachim Palmer 1. Ausgabe, Januar 2010. Grundlagen. Neubearbeitung 2010

Objektorientierter Softwareentwurf mit UML. Ricardo Hernández Garcia, Joachim Palmer 1. Ausgabe, Januar 2010. Grundlagen. Neubearbeitung 2010 Ricardo Hernández Garcia, Joachim Palmer 1. Ausgabe, Januar 2010 Objektorientierter Softwareentwurf mit UML Grundlagen Neubearbeitung 2010 PGOS2010 I Objektorientierter Softwareentwurf mit UML - Grundlagen

Mehr

Key Note und Abstracts Stream 4

Key Note und Abstracts Stream 4 Key Note und Abstracts Stream 4 Key-Note: Research: The Art of Predicting and Shaping the Future In der Research Division der IBM wurden und werden durch strukturierte Trendanalysen solide Vorhersagen

Mehr

Remote-Administration von eingebetteten Systemen mit einem Java-basierten Add-On-Modell

Remote-Administration von eingebetteten Systemen mit einem Java-basierten Add-On-Modell Remote-Administration von eingebetteten Systemen mit einem Java-basierten Add-On-Modell F. Burchert, C. Hochberger, U. Kleinau, D. Tavangarian Universität Rostock Fachbereich Informatik Institut für Technische

Mehr

32-Bit Microcontroller based, passive and intelligent UHF RFID Gen2 Tag. Zürcher Fachhochschule

32-Bit Microcontroller based, passive and intelligent UHF RFID Gen2 Tag. Zürcher Fachhochschule 32-Bit Microcontroller based, passive and intelligent UHF RFID Gen2 Tag Inhalt Vorgeschichte Was wurde erreicht Hardware Energy Micro Microcontroller µctag Plattform EPC Gen2 Tag Standard Protokoll-Vorgaben

Mehr

Prinzipien Objektorientierter Programmierung

Prinzipien Objektorientierter Programmierung Prinzipien Objektorientierter Programmierung Valerian Wintner Inhaltsverzeichnis 1 Vorwort 1 2 Kapselung 1 3 Polymorphie 2 3.1 Dynamische Polymorphie...................... 2 3.2 Statische Polymorphie........................

Mehr

Das Lehren von objektorientierter Programmierung in Java mit

Das Lehren von objektorientierter Programmierung in Java mit Das Lehren von objektorientierter Programmierung in Java mit Dr. Axel Schmolitzky Arbeitsbereich Softwaretechnik Fachbereich Informatik Universität Hamburg Überblick Kurz zu meiner Person Objektorientierung

Mehr

COMMON OBJECT REQUEST BROKER ARCHITECTURE. Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg

COMMON OBJECT REQUEST BROKER ARCHITECTURE. Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg COMMON OBJECT REQUEST BROKER ARCHITECTURE Dmytro Pyvovar Otto-von-Guericke Universität Magdeburg Gliederung Motivation Was ist CORBA? Object Management Architecture (OMA ) Interface Definition Language

Mehr

Test-Driven Developement Eine Einführung

Test-Driven Developement Eine Einführung Test-Driven Developement Eine Einführung 2007 by Tobias Hagen Im Rahmen der Veranstaltung Aktuelle Themen der Informatik bei Prof. Dr. Friedbert Kaspar Hochschule Furtwangen University Übersicht Einführung...

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

Untersuchung zur hardwareunterstützten Entwurfsverifikation von Stream-basierten Kommunikations- und Verarbeitungsalgorithmen

Untersuchung zur hardwareunterstützten Entwurfsverifikation von Stream-basierten Kommunikations- und Verarbeitungsalgorithmen Fakultät Informatik Institut für Technische Informatik, Professur für VLSI-Entwurfssysteme, Diagnostik und Architektur Untersuchung zur hardwareunterstützten Entwurfsverifikation von Stream-basierten Kommunikations-

Mehr

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013

Kundenanforderungen. Hochschule Luzern Technik & Architektur. Software Komponenten FS13. Gruppe 03 Horw, 24.05.2013 Software Komponenten FS13 Gruppe 03 Horw, 24.05.2013 Bontekoe Christian Estermann Michael Moor Simon Rohrer Felix Autoren Bontekoe Christian Studiengang Informatiker (Berufsbegleitend) Adresse Telefon

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

Grob- und Detailplanung bei der Implementierung nutzen

Grob- und Detailplanung bei der Implementierung nutzen Softwarearchitektur Grob- und Detailplanung bei der Implementierung nutzen Bereich Realisierung Aktivität Softwareinkrement realisieren Ziele Vermitteln einer Orientierungshilfe für alle Entwickler Etablierung

Mehr

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund

Guten Tag! CampusSource. Die CSE Integration Platform. CampusSource Engine. Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Engine Die CSE Integration Platform Guten Tag! Christof Pohl Softwareentwicklung Medienzentrum Universität Dortmund Integriertes Informationsmanagement mit der Engine - A2A vs. EBI Folie 2 Integration

Mehr

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung Software-Qualität im Rahmen modellgetriebener Softwareentwicklung OFFIS Technologiecluster Enterprise Application Integration niels.streekmann@offis.de 09.07.2008 Seite 1 / 13 Software-Qualität: Unterschiedliche

Mehr

- Agile Programmierung -

- Agile Programmierung - Fachhochschule Dortmund Fachbereich Informatik SS 2004 Seminar: Komponentenbasierte Softwareentwicklung und Hypermedia Thema: - - Vortrag von Michael Pols Betreut durch: Prof. Dr. Frank Thiesing Übersicht

Mehr

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

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

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

2 Echtzeitbetriebssysteme

2 Echtzeitbetriebssysteme 35 2 Echtzeitbetriebssysteme In den letzten Jahren hat sich die Automobilindustrie zu einem der wesentlichen Anwender von Echtzeitbetriebssystemen für eingebettete Systeme entwickelt. Relativ zeitig erkannten

Mehr

Task A Zündung. Task B Einspritzung. Task C Erfassung Pedalwert. J. Schäuffele, Th. Zurawka: Automotive Software Engineering, Vieweg, 2003

Task A Zündung. Task B Einspritzung. Task C Erfassung Pedalwert. J. Schäuffele, Th. Zurawka: Automotive Software Engineering, Vieweg, 2003 Task! evt. parallel zu bearbeitende Ausführungseinheit! Beispiel: Task A Zündung Task B Einspritzung Task C Erfassung Pedalwert Zeit t J. Schäuffele, Th. Zurawka:, Vieweg, 2003 Echtzeitbetriebssysteme

Mehr

Der BPM-Lebenszyklus in Theorie und Praxis. Prof. Dr. Mathias Weske

Der BPM-Lebenszyklus in Theorie und Praxis. Prof. Dr. Mathias Weske Der BPM-Lebenszyklus in Theorie und Praxis Prof. Dr. Mathias Weske Hasso Plattner Institut 2 An-Institut der Universität Potsdam, aus privaten Mitteln von SAP- Gründer Hasso Plattner finanziert Bachelor

Mehr