Teilprojekt B1. Entwurfstechniken. Entwurfstechniken für sicherheitskritische, selbstoptimierende Multiagentensysteme im Kontext der Mechatronik
|
|
- Swen Ritter
- vor 8 Jahren
- Abrufe
Transkript
1 Teilprojekt B1 Entwurfstechniken Entwurfstechniken für sicherheitskritische, selbstoptimierende Multiagentensysteme im Kontext der Mechatronik Prof. Dr. rer. nat. W. Schäfer Lehrstuhl für Softwaretechnik Institut für Informatik Prof. Dr. rer. nat. H. Wehrheim Lehrstuhl für Spezifikation und Modellierung von Softwaresystemen Institut für Informatik
2
3 Schäfer, Wehrheim Teilprojekt B1 5.1 Allgemeine Angaben zum Teilprojekt B Titel: Entwurfstechniken Entwurfstechniken für sicherheitskritische, selbstoptimierende Multiagentensysteme im Kontext der Mechatronik Title: Software Design Techniques Design Techniques for Safety-Critical, Self-Optimizing Multi-Agent Systems in the Context of Mechatronic Projektleitung Schäfer, Wilhelm, Prof. Dr., 1954, Deutsch Lehrstuhl für Softwaretechnik Universität Paderborn Zukunftsmeile Paderborn Telefon: Telefax: Adresse: wilhelm@uni-paderborn.de Wehrheim, Heike, Prof. Dr., 1964, Deutsch Lehrstuhl für Spezifikation und Modellierung von Softwaresystemen Universität Paderborn Warburger Straße Paderborn Telefon: Telefax: Adresse: wehrheim@uni-paderborn.de 113
4 Teilprojekt B1 Entwurfstechniken 5.2 Entwicklung des Teilprojekts Bericht Im Teilprojekt B1 wurden UML-basierte Entwurfstechniken für selbstoptimierende mechatronische Multiagentensysteme entwickelt. Dabei wurde in der 1. Förderperiode ein auf kompositionaler Verifikation und domänenspezifischen Entwurfsmustern beruhender Ansatz entwickelt. In der 2. Förderperiode wurde dieser Ansatz um die Möglichkeiten zur Modellierung hybrider Agenten mit diskretem und kontinuierlichem Verhalten, sowie deren Online-Rekonfiguration unter besonderer Berücksichtigung von Sicherheit und Zuverlässigkeit, erweitert. Auch nach der erfolgreichen Validierung der bisherigen Ergebnisse an den komplexen Demonstratoren des SFB bestand weiterhin grundlegender Forschungsbedarf. In der 3. Förderperiode wurde der Ansatz daher um Konzepte für flexible Struktur- und Verhaltensanpassungen sowie um ein Re-Engineering erweitert Kenntnisstand und Ausgangsfragestellung bei der letzten Antragstellung Multiagentensysteme (MAS) mit mechatronischen Komponenten erreichen ihre weitreichende Funktionalität durch die Vernetzung der mechatronischen Komponenten. Die Vernetzung ermöglicht ein koordiniertes Vorgehen der Einzelagenten und damit die Selbstoptimierung durch Anpassung an veränderte Zielvektoren. Voraussetzung für die Koordination ist ein Austausch von Informationen zwischen Agenten mittels nachrichtenbasierter Kommunikation. Die Kombination von softwaretechnischer Interaktion zwischen Agenten einerseits und regelungstechnischer Aktorik und Sensorik andererseits stellt eine große Herausforderung für die Entwicklung korrekter Software mechatronischer Systeme dar. Dieser Herausforderung stellte sich das Teilprojekt B1. Adressiert wird diese Herausforderung durch eine Hand in Hand Entwicklung eines Modellierungformalismus für mechatronische MAS, der MECHATRONICUML, und einer assoziierten Verifikationsmethodik. In der 1. Förderperiode wurden dazu Muster entwickelt, die speziell die Koordination der mechatronischen Komponenten berücksichtigen und eine modellbasierte, kompositionale Verifikation ermöglichen. Die Muster wurden in der 2. Förderperiode zu parametrisierten Koordinationsmustern für eine variable Anzahl von Teilnehmern an einer zentral koordinierten Interaktion ausgebaut. Die Einbeziehung regelungstechnischer, durch Simulation oder Testen abgeleiteter Ergebnisse des Teilprojektes C3 und der D Teilprojekte ermöglichte eine Abstraktion des hybriden Systems zu einem rein zeit-kontinuierlichen System und ermöglichte damit eine effiziente Verifikation. Der Online-Rekonfiguration des Softwaresystems wurde dabei auf zwei Ebenen Rechnung getragen, der Ebene der Verhaltensanpassung eines OCMs und der Strukturanpassung eines MAS. Die Sicherheit ersterer Rekonfiguration wird durch die kompositionale Verifikation erreicht. Für die Strukturanpassungen, die für beliebige Ausgangskonfigurationen als sicher nachgewiesen werden müssen, wurde in der 2. Förderperiode eine neuartige Verifikationstechnik basierend auf dem Nachweis von Strukturinvarianten entwickelt. Der durch die Strukturanpassungen aufgespannte unendliche Zustandsraum wird formal durch ein Erzeugendensystem, genauer Graphtransformationssystem, modelliert. So können Strukturinvarianten durch eine induktive Technik nachgewiesen werden. 114
5 Schäfer, Wehrheim Teilprojekt B1 In der 2. Förderperiode wurde die Modellierung zusätzlich durch die Entwicklung von Syntheseverfahren unterstützt, die aus Szenariodiagrammen die erwähnten Koordinationsmuster ableiten und aus den in einer Komponente zu verwendenden Koordinationsmustern das Gesamtverhalten einer Komponente berechnen. Die notwendige Komponentenstruktur für die Modellierung von Szenariodiagrammen wurde in enger Kooperation mit dem Teilprojekt B2 aus den domänenübergreifenden Modellen abgeleitet. Zudem wurde eine Gefahrenanalyse entwickelt, die zusammen mit der Betrachtung von Fehlertoleranztechniken das Auftreten und die Vermeidung von Fehlern auf Grund des Ausfalls oder Fehlerverhaltens kompletter Komponenten betrachtet. In Kooperation mit dem Teilprojekt D2 wurden Gefahren für RailCab-Konvois analysiert und Techniken zur Fehlertoleranz angewandt. Forschungsbedarf zu Beginn der 3. Förderperiode Im Rahmen der 3. Förderperiode sollten die in der 2. Förderperiode begonnenen Arbeiten zur Modellierung und Verifikation von Koordinationsmustern fortgesetzt werden. In vielen Fällen kann der Einsatz eines Koordinationsmusters den Einsatz eines anderen Koordinationsmusters erfordern oder verbieten. Deshalb musste untersucht werden, wie diese Abhängigkeiten formal spezifiziert werden können und insbesondere wie die formal spezifizierten Abhängigkeiten für eine automatische Kombination von Koordinationsmustern eingesetzt werden können. Weiterer Forschungsbedarf bestand in der Erweiterung der in den vorangegangenen Förderperioden entwickelten Verifikationsverfahren. Die in der 2. Förderperiode entwickelten Verfahren erlauben eine Verifikation von induktiven Invarianten für ein parametrisiertes Koordinationsmuster. Mit diesem Verfahren lassen sich viele, aber nicht alle relevanten Sicherheitseigenschaften für ein parametrisiertes Koordinationsmuster nachweisen. In der 3. Förderperiode sollten weitere Verifikationsverfahren erforscht werden, die eine möglichst vollständige Verifikation parametrisierter Koordinationsmuster ermöglichen. Insbesondere sollten dabei auch etablierte Abstraktionstechniken untersucht und eingesetzt werden, um Systeme beliebiger Größe verifizieren zu können. Zentraler Bestandteil der ersten beiden Förderperioden war die Einbeziehung der Selbstoptimierung in Modellierung und Verifikation und dabei insbesondere die Kopplung von Regelungstechnik und Software. Hier sind Verhaltens- und Strukturanpassungen entwickelt worden, die jeweils einen Aspekt der Selbstoptimierung betrachten (z. B. Abstandsregelung von RailCabs). Selbstoptimierung wird aber immer ganz unterschiedliche, jedoch nicht unabhängige Bereiche eines mechatronischen Systems betreffen. Dafür muss das Zusammenspiel der verschiedenen, für die Selbstoptimierung nötigen softwaretechnischen Interaktionen präzise festgelegt werden und der kognitive Operator muss den Einsatz dieser Interaktionen planen können. Aus diesem Grund sollte in der 3. Förderperiode erforscht werden, wie die Planung der Koordination unter strengen Sicherheitsanforderungen sicher durchgeführt werden kann. In der 2. Förderperiode wurden für die Gefahrenanalyse Systeme betrachtet, die nicht zeitbehaftet waren. Deshalb konnte der Fall auftreten, dass Gefahren ermittelt wurden, die unter Berücksichtigung von zeitlichen Bedingungen, denen das System unterliegt, nicht auftreten. Zum anderen war es möglich, dass Gefahren nicht ermittelt wurden, die erst unter den zeitlichen Einschränkungen des Systems auftreten. Das gilt vor allem für den Übergang zwischen Konfigurationen. Aus diesem Grund sollte nun für die Gefahrenanalyse auch die Zeit berücksichtigt und zusätzlich das Rekonfigurationsverhalten in Betracht gezogen werden. Zusätzlich sollte eine Dekomposition der Gefahrenanalyse aus der 2. Förderperiode entwickelt werden, um diese Analyse auch für große Modelle anwendbar zu machen. Außerdem sollte die Gefahrenanalyse genutzt werden, um zur Laufzeit zu planen, wie das Verhalten des Systems hinsichtlich des Risikos optimiert werden kann. 115
6 Teilprojekt B1 Entwurfstechniken Die Entwurfstechnik von TP B1 ging bisher davon aus, dass mechatronische Systeme unter der Benutzung der MECHATRONICUML vollständig neu entworfen werden. Realistisch ist aber eher ein Neuentwurf unter Wiederverwendung bestehender Komponenten. Damit die von B1 entwickelten Techniken für diese Systeme genutzt werden können, musste ein Reverse Engineering von Altsystemen entwickelt werden, welches MECHATRONICUML-Modelle aus Quellcode konstruiert. Ziele in der 3. Förderperiode Ausgehend von dem dargestellten Forschungsbedarf ließen sich die folgenden Ziele für die 3. Förderperiode ableiten: 1) Koordination Zur Erhöhung der Flexibilität von Verhaltens- und Strukturanpassungen sollten Kombinationen von Koordinationsmustern sowie parametrisierte Koordinationsmuster für eine dezentrale Koordination beliebig vieler Agenten entwickelt werden. Um Systeme mit beliebig vielen Agenten verifizieren zu können sollte ein auf Shape Analyse basierendes Verifikationsverfahren entwickelt werden. Die zunehmenden Möglichkeiten zur Selbstoptimierung erfordern damit aber auch eine Planung des Einsatzes der Koordinationsmuster. Dafür sollten in der 3. Förderperiode zusätzlich Planungsverfahren für die softwaretechnische Agentenkoordination entwickelt werden, insbesondere und im Gegensatz zu den Teilprojekten A1 und A2 unter Berücksichtigung von Sicherheitsanforderungen. 2) Gefahrenanalyse Die Gefahrenanalyse sollte in der 3. Förderperiode durch die Behandlung von zeitabhängigen Fehlereinflüssen ergänzt werden, um den inhärenten Echtzeiteigenschaften mechatronischer Systeme Rechnung zu tragen und die Präzision der Analyse zu erhöhen. 3) Re-Engineering Ein weiteres neues Ziel war die Entwicklung von Techniken zur Integration von Altsystemen. Die Einbettung von Altsystemen in den bestehenden Modellierungsansatz erfordert ein Reverse Engineering bestehender Systeme mit dem Ziel, Modelle der ME- CHATRONICUML aus dem Quellcode zu synthetisieren. 4) Werkzeugunterstützung Die vorhandene Werkzeugunterstützung sollte um die in der 3. Förderperiode in B1 entwickelten Konzepte und Verfahren erweitert werden, um sie auch anderen Teilprojekten und den Demonstratoren zur Verfügung zu stellen und die entwickelten Methoden zu evaluieren Ergebnisse sowie angewandte und ggf. neu entwickelte Methoden 1) Koordination Bei der Selbstoptimierung von mechatronischen Systemen zur Laufzeit stehen uns im Wesentlichen zwei Wege zur Verfügung das System anzupassen, um eine Verbesserung im Sinne der Zielfunktionen zu erreichen: Anpassung von Laufzeitparametern und Anpassung der Systemstruktur. Erstere Möglichkeit wird hauptsächlich genutzt um kontinuierliche Parameter im optimalen Bereich zu halten und anzupassen, sollten Veränderungen in der Umwelt oder in den Zielfunktionen dazu führen, dass der optimale Bereich sich verändert. Letztere Möglichkeit wird verwendet, um das System an we- 116
7 Schäfer, Wehrheim Teilprojekt B1 sentliche, meist diskrete Veränderungen der Situation anzupassen, die mit reiner Parameteranpassung nicht optimal zu beantworten sind. Ein einfaches Beispiel hierfür ist das Umschalten von einem Regler auf einen anderen, der Situation angemesseneren. Komplexere Beispiele sind die Instanziierung von Koordinationsmustern zwischen interagierenden mechatronischen Systemen. Vor diesem Hintergrund wurde die Entwicklung parametrisierter Koordinationsmuster, die in der zweiten Förderperiode begonnen wurde, fortgesetzt [HHP+10, EHH+13]. Eine angepasste Systemstruktur stellt eine tiefgreifende Veränderung des Systems und seiner Funktionsweise dar und hat das Potenzial, im Falle einer fehlerhaften Strukturanpassung zur Laufzeit, zu gefährlichem und unter Umständen schwer nachvollziehbarem Systemverhalten zu führen. Ein wesentliches Ziel der im Teilprojekt B1 entwickelten Entwurfstechniken muss es also sein, solche Fälle ausschließen zu können. Aus diesem Grund wurden die Verifikationsverfahren für die Überprüfung von Sicherheitseigenschaften erweitert [EHH+13, Suc11]. Der in der 2. Förderperiode entwickelte Nachweis von Sicherheitseigenschaften für parametrisierte Koordinationsmuster bedingt eine feste, interne Kommunikationsstruktur bei der die einzelnen Rolleninstanzen des parametrisierten Koordinationsmusters, wie in Bild 5-16 dargestellt, nur entlang einer linearen Liste miteinander interagieren. Rolleninstanz 1 Rolleninstanz 2 Rolleninstanz n Bild 5-16: Kommunikation entlang einer linearen Liste Die Verifikationsverfahren wurden in der 3. Förderperiode so erweitert, dass eine formale Verifikation beliebig aufgebauter parametrisierter Koordinationsmuster ermöglicht wird.... Parametrisiertes Koordinationsmuster Real-Time Statecharts Rekonfigurationsregeln Natürlichsprachliche Anforderungen Automatische Übersetzung Manuelle Übersetzung Zeitbehaftetes Graphtransformationssystem Formalisierte Anforderungen (FO-TCTL) Verifikationsprozedur... Algorithmus... Artefakt OK Gegenbeispiel Bild 5-17: Ablauf der Verifikation eines parametrisierten Koordinationsmusters 117
8 Teilprojekt B1 Entwurfstechniken Der generelle Ablauf des Verifikationsverfahrens ist in Bild 5-17 dargestellt. Zunächst wird das parametrisierte Koordinationsmuster, wie in [EHH+13, HH11b] beschrieben, in ein zeitbehaftetes Graphtransformationssystem übersetzt. Dieses Graphtransformationssystem enthält sowohl das zustandsbasierte Kommunikationsverhalten, das über Real-Time Statecharts modelliert wird, als auch die Rekonfigurationsregeln. Damit kann es für den Nachweis von Sicherheitseigenschaften genutzt werden, die sich sowohl auf das zustandsbasierte Verhalten als auch auf Veränderungen der Kommunikationsstruktur beziehen. Die Spezifikation von Sicherheitseigenschaften wurde ebenfalls hinsichtlich der Variabilität der Kommunikationsstruktur eines parametrisierten Koordinationsmusters erweitert. In [Suc11] wurde eine Erweiterung der formalen Logik TCTL [ACD93] um Konstrukte der Prädikatenlogik entwickelt. Diese ermöglicht es, Sicherheitseigenschaften für eine variable Menge von Rollen eines parametrisierten Koordinationsmusters zu spezifizieren. Die formalen Eigenschaften werden aus den natürlichsprachlichen Anforderungen an das System abgeleitet. Im Rahmen der dritten Förderperiode wurden zwei Verifikationsalgorithmen auf Basis dieses Ansatzes entwickelt. Zum einen wurde ein Model Checking Ansatz für zeitbehaftete Graphtransformationssysteme entwickelt [EHH+13], [Suc11]. Dieser ermöglicht den Nachweis von Sicherheitseigenschaften für parametrisierte Koordinationsmuster mit einer endlichen Anzahl von Teilnehmer unter Berücksichtigung der Echtzeiteigenschaften. Mit dem zuvor beschriebenen Ansatz können jedoch nicht alle parametrisierten Koordinationsmuster verifiziert werden, da Systeme mit dynamischer Strukturanpassung im Modell prinzipiell keinerlei Größenbegrenzungen haben. Es existieren also potenziell unendliche viele verschiedene Systemkonfigurationen, die auf Fehler zu überprüfen sind. In der physikalischen Ebene sind zwar eventuell Größenbegrenzungen vorhanden, jedoch sind diese oft nicht vorher bekannt, während des Lebenszyklus des Systems Änderungen unterworfen oder so groß, dass eine Untersuchung aller möglichen Konfigurationen wirtschaftlich nicht vertretbar ist. Aus diesem Grund wurden verschiedene Abstraktionsverfahren evaluiert. Hierbei stellte sich der Ansatz der Shape Analyse als vielversprechender als die alternativen Ansätze Counter Abstraction [PXZ02] oder Spotlight Abstraction [WW07] heraus. Daher wurde ein auf Shape Analyse basierender Verifikationsansatz entwickelt [SW11], [SWW11]. Diese Methode macht sich neue Erkenntnisse aus dem Bereich der Programm- und Speicheranalyse zu Nutze und überträgt diese auf Graphtransformationssysteme. Dies ermöglicht die Überprüfung von Sicherheitseigenschaften für eine beliebig große Menge von Teilnehmern, jedoch ohne Berücksichtigung der Echtzeiteigenschaften. Eine detaillierte Beschreibung beider Ansätze befindet sich in [GSR13, Abschnitt 5.2.3]. Der in den vorangegangenen Förderperioden entwickelte kompositionale Verfikationsansatz bedingt die Definition einer Verfeinerung für Rollen eines Koordinationsmusters. Die Rollen eines Koordinationsmusters müssen von den Komponenten korrekt verfeinert werden, damit die für die Muster bewiesenen Sicherheitseigenschaften auch für die Komponenten weiterhin gültig sind. In [HH11] wurde die Verfeinerung hinsichtlich der Rekonfiguration eines parametrisierten Koordinationsmusters erweitert. Der entwickelte Verfeinerungsbegriff berücksichtigt insbesondere die Anpassung der Kommunikationsstruktur eines parametrisierten Koordinationsmusters zur Laufzeit und ermöglicht es so, den kompositionalen Verifikationsansatz auch für parametrisierte Koordinationsmuster einzusetzen. Ferner wurde in [BHS+13] ein Ansatz vorgestellt, mit dem eine geeignete Verfeinerung automatisch auf Basis der modellierten Rollen und der bewiesenen Sicherheitseigenschaften ausgewählt und überprüft werden kann. Eine detaillierte Beschreibung der Verfeinerung befindet sich in [GSR13, Abschnitt 5.2.4]. Die verfeinerten Koordinationsmuster müssen anschließend in den Komponenten des Systems kombiniert werden, da eine Komponente in der Regel mit mehreren anderen Komponenten interagieren muss. Eine beliebige Kombination der Koordinationsmuster 118
9 Schäfer, Wehrheim Teilprojekt B1 ist jedoch nicht immer möglich, da Abhängigkeiten zwischen Koordinationsmustern bestehen können, die eine parallele Ausführung erfordern oder verbieten. Im Rahmen der dritten Förderperiode wurden diese Abhängigkeiten über sogenannte State- Composition-Rules und Event-Composition-Automata formalisiert [EH10]. Darauf aufbauen wurde ein Synthesealgorithmus erarbeitet, der aus den einzelnen Rollenverhalten ein Komponentenverhalten synthetisiert, das die entsprechenden Einschränkungen erfüllt [EH10]. Des Weiteren wurden parametrisierte Koordinationsmuster mit den in der zweiten Förderperiode entwickelten Komponentenstorydiagrammen kombiniert [HPB12], [HB13]. Innerhalb einer atomaren Komponente können Komponentenstorydiagramme direkt als Seiteneffekte der Real-Time Statecharts, mit denen das zustandsbasierte Kommunikationsverhalten der Rollen spezifiziert wird, aufgerufen werden. Für hierarchische Komponenten wurde eine allgemeine Schnittstelle zwischen parametrisierten Koordinationsmustern und dem Rekonfigurationsverhalten einer Komponente geschaffen. Dies ermöglicht es, auf Basis der Kommunikation mit anderen Systemen über ein parametrisiertes Koordinationsmuster innerhalb einer Komponente eine Rekonfiguration auszulösen. Diese Rekonfiguration wird über ein Komponentenstorydiagramm spezifiziert. Bild 5-18 zeigt eine Übersicht über die Modellierungselemente, die für die Integration in einer hierarchischen Komponente verwendet werden. Message drivingathighspeed drivingatnormalspeed distancesensorfailure Type info info request Expected Response Time ms Description RailCab travels at high speed. RailCab travels at normal speed. Distance sensor is broken. RailCabDriveControl reconfmsg RM parent RM Manager Executor RMR embeddedci executor events RE parent R RE embeddedci RE reconfexec Message noconvoymode Description The RailCab will not engage in convoys anymore. Time for Execution 20ms Time for Decision 50 ms enableconvoymode The RailCab will try to join convoys if possible and useful. 50ms 5 ms Bild 5-18: Spezifikation der Rekonfiguration einer hierarchischen Komponente Jede hierarchische Komponente wird um einen Manager und einen Executor erweitert und erhält zwei Rekonfigurationsports, die in der Abbildung mit RM (Reconfiguration Message Port) und RE (Reconfiguration Execution Port) beschriftet sind. Falls innerhalb einer Komponente auf Basis der Interaktion eines Koordinationsmusters ein Bedarf für eine Rekonfiguration entsteht, schickt diese Komponente eine Nachricht über ihren RM-Port. Diese wird vom embeddedci RM-Port des Managers der umgebenden hierarchischen Komponente empfangen und vom Manager bearbeitet. Der Manager 119
10 Teilprojekt B1 Entwurfstechniken entscheidet, ob diese Nachricht behandelt oder in der Komponentenhierarchie weiter nach oben propagiert wird. Jede für einen RM-Port spezifizierte Nachricht hat, wie in Bild 5-18 dargestellt, einen Namen, einen Typ, eine erwartete Antwortzeit und eine Beschreibung für den Komponentenentwickler. Der Typ definiert, ob eine Nachricht beantwortet werden muss (request) oder nicht (info) und in welcher Zeit dieses geschehen muss. Falls die Nachricht behandelt wird, entscheidet der Manager ob zur Behandlung der Situation eine Rekonfiguration durchgeführt werden kann. Dazu wird insbesondere die weiter unten beschriebene Planung angestoßen. Falls eine Rekonfiguration ausgeführt werden soll, dann wird der Executor angewiesen, diese auszuführen. Der Executor spezifiziert eine Menge von Komponentenstorydiagrammen. Die Ausführung der Rekonfiguration bedingt in vielen Fällen die Rekonfiguration einer oder mehrerer eingebetteter Komponenten. Tritt beispielsweise ein RailCab in einen Konvoi ein, muss die Kommunikationsstruktur angepasst werden und zusätzlich muss der Regler umgeschaltet werden. In diesem Fall darf eine Rekonfiguration nur dann ausgeführt werden, wenn alle betroffenen eingebetteten Komponenten ebenfalls die benötigte Rekonfiguration durchführen können, da eine nur teilweise ausgeführte Rekonfiguration in der Regel zu einem unsicheren Systemzustand führt. Als Lösung wurde eine Adaption des 2-Phasen-Commit Protokolls für verteilte Datenbanken [BHG87, Abschnitt 7] entwickelt, das dieses Problem löst [HPB12], [HB13]. Dieses Protokoll nutzt die in Bild 5-18 dargestellte Spezifikation eines RE-Ports, über den Rekonfigurationen für die umgebende hierarchische Komponente aufrufbar gemacht werden. Dabei wird für jede Rekonfigurationsregel angegeben, wie lange die Überprüfung dauert, ob die Regel angewendet werden kann (Time For Decision), und wie lange die Ausführung der Rekonfiguration dauert (Time for Execution). Diese Informationen sind essentiell um entscheiden zu können, ob eine Rekonfiguration rechtzeitig vollständig ausgeführt werden kann. Ferner wurden die Techniken zur kompositionalen Verifikation dahingehend erweitert, dass ein Nachweis der Korrektheit der Strukturrekonfiguration für jede Komponente einzeln durchgeführt werden kann. Dazu ermöglicht das in [HB13] vorgestellte Verfahren die isolierte Betrachtung einzelner Hierarchieebenen einer hierarchischen Komponente bei der Verifikation. Die Überprüfung von Sicherheitseigenschaften für die interne Rekonfiguration einer Komponente wird mit dem oben vorgestellten, graphbasierten Verifikationsverfahren durchgeführt. In [HSS+13] wurde gezeigt, wie die in den vorangegangenen Förderperioden entwickelte Reglerumschaltung in die Modellierungstechnik der Komponentenstorydiagramme integriert wurde. Dafür wurden Komponentenstorydiagramme um spezielle Austauschaktivitäten erweitert, die die notwendigen Informationen für die Umschaltung der Regler enthalten. Damit bieten Komponentenstorydiagramme in Kombination mit Real-time Statecharts alle Modellierungsmöglichkeiten, die auch von hybriden Rekonfigurationscharts unterstützt wurden. Komponentenstorydiagramme bieten aber generelle Vorteile bei der Spezifikation von Rekonfiguration für Systeme mit einem großen Konfigurationsraum [Sch12]. Aus diesem Grund wurden die Arbeiten zur Rekonfiguration von hierarchischen Komponenten [HB13] allein für Komponentenstorydiagramme, jedoch nicht mehr für hybride Rekonfigurationscharts durchgeführt. Es wurden außerdem Planungsverfahren für die softwaretechnische Agentenkoordination entwickelt. Die Verfahren nutzen Graphtransformationssysteme als zu Grunde liegenden Formalismus. Das Planungsproblem ist, in dem von dem Graphtransformationssystem aufgespannten Transitionssystem einen Pfad zu finden, der zu einer Zielkonfiguration führt. Dieser Pfad von Konfigurationen (bzw. die Graphtransformationsregeln, aus deren Anwendung sich die Zustandsübergänge in die Folgekonfigurationen ergeben) ist der Plan. 120
11 Schäfer, Wehrheim Teilprojekt B1 Im Verlauf der 3. Förderperiode wurden mehrere Lösungsansätze für unterschiedliche Varianten des Planungsproblems entwickelt. Bei einer Variante des Problems müssen Sicherheitsanforderungen berücksichtigt werden, die die Planungsaufgabe erschweren [GSR+13, Abschnitt 3.2.2]. Man spricht deswegen auch von sicherer Planung. Die Sicherheitsanforderungen beschränken die Menge der erlaubten Konfigurationen, d. h. sie spezifizieren, welche Konfigurationen in einem Plan nicht erlaubt sind. Ein Beispiel einer verbotenen Konfiguration ist ein zu geringer Sicherheitsabstand zwischen zwei RailCabs. Bei Berücksichtigung von Sicherheitsanforderungen wird die Aufgabe des Planungsproblems insofern erweitert, als dass der Plan keine verbotenen Konfigurationen durchschreiten darf. Zur Lösung dieses Planungsproblems mit Sicherheitsanforderungen wurden zwei Ansätze entwickelt. Der erste Ansatz verwendet einen Model Checker, um einen Pfad zu einer Zielkonfiguration zu finden [RW10]. Dazu wird das Planungsproblem in ein Verifikationsproblem umformuliert und die Anforderung überprüft, dass kein Plan existiert. Falls diese Anforderung nicht erfüllt ist, also ein Plan existiert, wird dieser Plan als Gegenbeispiel geliefert. Die Sicherheitsanforderungen an das Planungsproblem können mit in die Anforderung des Verifikationsproblems integriert werden. Der zweite Ansatz zur sicheren Planung basiert auf heuristischer Suche. Dabei wurden sowohl domänenspezifische als auch domänenunabhängige Heuristiken verwendet. Domänenspezifische Heuristiken können teilautomatisch mittels eines Lernalgorithmus gelernt werden [EW11]. Dabei wird eine Regressionsfunktion erstellt, die die Kosten des Pfades einer gegebenen Konfiguration zu einer Zielkonfiguration voraussagt. Dazu muss vom Entwickler des Systems im Voraus eine Menge von Merkmalen deklariert werden, die für die Anwendungsdomäne sinnvoll sind. Als domänenunabhängige Heuristik kam ein Verfahren zum Einsatz, das eine Abstraktion des eigentlichen Planungsproblems löst und die Länge des abstrakten Plans als heuristischen Wert verwendet [Ahm12]. Die Anwendungsbedingung von Regeln wird dabei relaxiert, so dass störende Änderungen der Konfiguration, die durch vorherige Regelanwendungen verursacht wurden, vernachlässigt werden. Um eine (abstrakte) Folgekonfiguration zu erstellen, werden außerdem alle Transformationen parallel angewendet. Dadurch ist der (abstrakte) Zustandsraum linear und erlaubt das abstrakte Problem effizient zu lösen. Bei einer anderen Variante des Planungsproblems muss auch die Dauer der Transformationen berücksichtigt werden. In einer solchen temporalen Auffassung des Problems ist es möglich, Transformationen nebenläufig auszuführen. Aufgrund von nebenläufiger Ausführungen können jedoch Konflikte entstehen, wie z. B. die Deinstanziierung und der Gebrauch einer Komponente von unterschiedlichen Transformationen zur selben Zeit. Das Planungsverfahren muss Pläne erzeugen, die frei von Konflikten sind, um einer sicheren Planung gerecht zu werden. Diese Planungsaufgaben werden durch ein Verfahren gelöst, das eine Übersetzung des Modells in die Planning Domain Definition Language (PDDL), eine Eingabesprache für Standardplaner, vornimmt [ZW13]. Das Problem kann dann mit gängigen Standardplanern gelöst werden. Technisch finden Rekonfigurationen des Systems weiterhin in Nullzeit statt; es gibt jetzt lediglich zwei Rekonfigurationen, eine für den Beginn und eine für das Ende der zeitandauernden Transformation. Um Konflikte in der nebenläufigen Ausführung von Transformationen zu vermeiden, ist eine Nebenläufigkeitskontrolle direkt in die Übersetzung integriert worden. Für diesen Begriff von zeitandauernden Transformationen wurde eine formale Semantik entwickelt, die auf zeitbehafteten Graphtransformationssystemen aufsetzt und die Nebenläufigkeitskontrolle integriert [ZH13]. Es handelt sich dabei um ein Sperrverfahren, der den Lese- und Schreibzugriff auf Teile der Konfiguration sperrt, solange sich eine zeitandauernde Transformation in 121
12 Teilprojekt B1 Entwurfstechniken Anwendung befindet. Dieser Lösungsansatz wurde mit einem hybriden Planer, der auf einer tieferen Abstraktionsebene optimale Einstellungen während des Betriebs gewährleistet, in ein mehrstufiges Planungssystem integriert [RZ13]. Generell können die hier genannten Planungsverfahren auf unterschiedlichen Abstraktionsebenen angewendet werden: z. B. im kognitiven Operator eines VMS, um die Konvoikoordination zwischen mehreren RailCabs zu planen, oder im reflektorischen Operator eines AMS, um einen selbstheilenden Vorgang zu planen. Eine Instanz der selbstheilenden Planung kann beispielsweise von der Online-Gefahrenanalyse angestoßen werden. Im Rahmen der 3. Förderperiode wurden die Arbeiten an der formalen Semantik der MECHATRONICUML fortgesetzt. Insbesondere wurden die Ergebnisse der drei Förderperioden in eine Sprachspezifikation konsolidiert [BBB+12]. Eine formale Semantik für parametrisierte Koordinationsmuster und rekonfigurierbare Komponenten ist durch die in [EHH+13] beschriebenen zeitbehafteten Graphtransformationssysteme und die entsprechenden Übersetzungen eines MECHATRONICUML-Modells in zeitbehaftete Graphtransformationssysteme gegeben. Eine detaillierte Definition der Übersetzung befindet sich in [HH11b]. Zeitbehaftete Graphtransformationssysteme sind ebenfalls als Grundlage verwendet worden, um eine formale Semantik für zeitandauernde Graphtransformationen zu entwickeln [ZH13]. Die abstrakte Transformationssemantik, die im Rahmen der Shape Analyse für Graphtransformationssysteme entwickelt wurde, komplementiert die formale Basis der ME- CHATRONICUML indem sie die Repräsentation unendlicher Transformationssysteme ohne Zeit ermöglicht. 2) Gefahrenanalyse Die Gefahrenanalyse, die in der 2. Förderperiode entwickelt wurde, adressiert die besonderen Eigenschaften selbstoptimierender mechatronischer Systeme dadurch, dass sämtliche Konfigurationen des Systems analysiert werden können. Allerdings wird dabei nicht der Übergang zwischen den Konfigurationen betrachtet. So kann es vorkommen, dass Konfigurationen, die mittels der Gefahrenanalyse aus der 2. Förderperiode als sicher eingestuft wurden, nicht sicher sind. Das richtet sich nach dem Zeitpunkt der Rekonfiguration und der vorhergehenden Fehlersituation. Denn auch während das System die Rekonfiguration ausführt, können Fehler durch das System propagieren und Fehler aus der Anfangskonfiguration in die Folgekonfiguration übertragen wurden. Um diesem Problem zu begegnen, muss betrachtet werden, wie weit Fehler in einer bestimmten Zeit propagieren und wie sich die Rekonfiguration auf bestehende Fehler auswirkt. Deshalb wurde die Gefahrenanalyse in der 3. Förderperiode um die Betrachtung von Fehlerpropagierungszeiten und den Übergang bei der Rekonfiguration erweitert wie in [GSR+13, Abschnitt 3.2.1] sowie [PST11], [PST13] beschrieben wurde. Die Fehlerpropagierungsmodelle wurden um Propagierungszeiten von Fehlern erweitert. Damit kann die Position von Fehlern zu beliebigen Zeitpunkten im System berechnet werden, vor allem zum Zeitpunkt einer Rekonfiguration. Außerdem ist es dadurch möglich, zu bestimmen, welche Fehler durch die Rekonfiguration aus dem System entfernt oder an der weiteren Propagierung gehindert werden. Die um Zeit erweiterten Fehlerpropagierungsmodelle werden dabei automatisch aus den Real-time Statecharts generiert [PHS13]. Bei der in der 2. Förderperiode entwickelten Gefahrenanalyse wird das gesamte System auf einmal analysiert. Das bedeutet, dass die gesamte Fehlerpropagierung des Systems auf einmal verarbeitet werden muss. Aber schon bei der Analyse eines Fehlerpropagierungsmodells mit ein paar hundert Basisereignissen kann es passieren, 122
13 Schäfer, Wehrheim Teilprojekt B1 dass nicht genug Arbeitsspeicher vorhanden ist, um die Analyse durchzuführen. Bei den im SFB betrachteten Systemen mit ihrer Vielzahl von miteinander kooperierenden Hardwarekomponenten kommen leicht tausend Basisereignisse und Kombinationen daraus zusammen. Das führt dazu, dass die Gefahrenanalyse nicht mehr ausgeführt werden kann, wenn das Gesamtsystem auf einmal betrachtet wird. Dieses Problem wurde in der 3. Förderperiode gelöst, indem die Gefahrenanalyse nur auf Teilsystemen ausgeführt und die Ergebnisse hinterher zum Gesamtergebnis zusammengeführt wurden. Diese Vorgehensweise wird Dekomposition genannt. Die Dekomposition zerlegt das Fehlerpropagierungsmodell, so dass einzelne Komponenten quasi unabhängig vom restlichen System analysiert werden können, wie in [Ani12] beschrieben wurde. Dadurch bleibt die komponentenbasierte Vorgehensweise und damit alle Vorteile der komponentenweisen Vorgehensweise erhalten, z. B. die Wiederverwendung. So können die Ergebnisse der Gefahrenanalyse, die für eine Konfiguration durchgeführt wurde, für andere Konfigurationen, die Komponenten oder Teilkonfigurationen mit der bereits analysierten Konfiguration gemeinsam haben, wiederverwendet werden. Die Komponenten müssen dabei in einer bestimmten Reihenfolge analysiert werden, weil die Analyse von Komponenten innerhalb einer Konfiguration von den Ergebnissen anderer Komponenten abhängen kann. Deshalb muss mit Komponenten gestartet werden, die alle Informationen enthalten, die für die Analyse benötigt werden. In diesem Fall sind das Komponenten ohne eingehende Fehler, bei denen die ausgehenden Fehler also nur von Fehlern verursacht werden, die in der Komponente selbst auftreten. Danach werden alle Komponenten analysiert, die mit Hilfe dieser Informationen analysiert werden können und so weiter. Dafür werden die Komponenten einer Konfiguration vor der Analyse in Ebenen eingeteilt, wie in Bild 5-19 dargestellt ist. Die Komponenten der ersten Ebene haben keine eingehenden Fehler und können deshalb sofort analysiert werden. Anschließend wird die Komponente der zweiten Ebene analysiert, weil sie nur von ausgehenden Fehlern der Komponenten der ersten Ebene abhängt. Die restlichen Ebenen im System werden in aufsteigender Reihenfolge analysiert. 1. Ebene 2. Ebene 3. Ebene e 1 f 1 v1 : VSensor a1 : ASensor f 2 f 4 & f 9 & f f 8 6 f 5 b1 : BReg e 2 f 3 e1 : Entsch f 7 Bild 5-19: Dekomposition der Gefahrenanalyse Die Reihenfolge der Komponenten in der Analyse wird mittels einer Tiefensuche auf dem Fehlerpropagierungsmodell ermittelt. Dabei wird das komplette Fehlerpropagierungsmodell in den Arbeitsspeicher geladen. Allerdings ist der Speicherverbrauch dafür 123
14 Teilprojekt B1 Entwurfstechniken wesentlich geringer im Vergleich zur Ausführung einer Gefahrenanalyse auf einem Modell gleicher Größe, da bei der Gefahrenanalyse noch weitere Zwischenmodelle erzeugt werden müssen. Zudem kann die Gefahrenanalyse genutzt werden, um zu planen, wie bestimmte Konfigurationen gezielt eingesetzt werden können, um das Verhalten des Systems hinsichtlich des Risikos zu optimieren. Das Risiko ist die Kombination Gefahrenwahrscheinlichkeit mit dem Schadenswert des Systems. Dadurch wird es möglich, Gefahren nach Wichtigkeit zu klassifizieren, was in vielen Standards Verwendung findet. Zum Beispiel sollten beim Transport von Gefahrgut bestimmte Konfigurationen gemieden werden, um das Risiko akzeptabel zu halten. Da der verursachte Schaden in diesem Fall höher wäre, muss dazu die Wahrscheinlichkeit einer Gefahr verringert werden. Da während der Laufzeit Konfigurationen auftreten können, die vorher noch nicht betrachtet wurden, und es aufgrund der Größe des Systems vorkommen kann, dass zum Entwurfszeitpunkt nicht alle möglichen Konfigurationen analysiert werden können, sollte außerdem eine Gefahrenanalyse zur Laufzeit möglich sein. Deshalb haben wir in der 3. Förderperiode einen Ansatz entwickelt, der es erlaubt, das Risiko von erreichbaren Konfigurationen zur Laufzeit zu berechnen, und Konfigurationen, deren Risiko das maximal zulässige Risiko des Systems übersteigen, zu sperren [PHST12], [PT09]. Um Gefahrenwahrscheinlichkeiten berechnen zu können, braucht man immer auch die Konfigurationen des Gesamtsystems, die in Zukunft durch Rekonfiguration erzeugt werden können. Erreichbare Konfigurationen werden durch die Erreichbarkeitsanalyse von der Verifikationstechnik aus Abschnitt 1) Koordination berechnet. Mit Hilfe der erreichbaren Konfigurationen wird die Fehlerpropagierung des Gesamtsystems konstruiert und im Anschluss die Gefahrenwahrscheinlichkeit berechnet. Um zu verhindern, dass Konfigurationen konstruiert werden, deren Risiko das maximal zulässige Risiko für das System übersteigt, wurde das mit Real-time Statecharts modellierte Verhalten erweitert. Transitionen in Real-time Statecharts können als blockierbar deklariert werden und zur Laufzeit blockiert werden. Damit können Rekonfigurationen verhindert werden. Allerdings können nicht alle Rekonfigurationen im System blockiert werden. Sind zum Beispiel Selbstheilungsoperationen in Form von Rekonfigurationen umgesetzt, müssen diese unbedingt ausgeführt werden und dürfen nicht blockiert werden. Es kann lediglich die Transition blockiert werden, die auf dem Pfad zu einer benötigten Rekonfiguration am nächsten liegt. Dazu muss der ganze Pfad, welcher zwischen zwei blockierbaren Transitionen liegt analysiert werden. Wenn mindestens eine der erreichbaren Konfigurationen, die auf dem Pfad liegen, ein höheres Risiko hat als die Schranke für das Risiko vorgibt, werden die erste Transition und damit der ganze Pfad blockiert. Bei der in der 2. Förderperiode werden Konnektoren lediglich als Verbindungen zwischen Systemkomponenten betrachtet. Allerdings existieren solche Konnektoren nicht nur als reine Verbindungen zwischen Softwarekomponenten sondern finden sich auch in physischer Ausprägung, zum Beispiel in Form von Kabeln. Diese können Störeinflüssen unterliegen oder durch Verschleiß ausfallen. Deshalb wurde in Kooperation mit TP D1 die Gefahrenanalyse so weiterentwickelt, dass nun auch die speziellen Eigenschaften von Konnektoren berücksichtigt werden [PSTH11]. 3) Re-Engineering In diesem Arbeitspaket wurde eine Integration von Altsystemen in mit den Entwurfstechniken von TP B1 entwickelte Systeme [Hen12], [HMS+10a], [HMS+10b], 124
15 Schäfer, Wehrheim Teilprojekt B1 [HMS+10c] betrachtet. Die Integration eines Altsystems darf die verifizierten Eigenschaften des neuen Systems nicht verletzen. Allerdings ist davon auszugehen, dass für das Altsystem kein Modell oder ein veraltetes Modell vorliegt. Vor allem ist davon auszugehen, dass keine MECHATRONICUML-Modelle existieren. Idealerweise sollten jedoch die bisher entwickelten formalen Verifikationstechniken von TP B1 angewandt werden, um Eigenschaften des neuen Systems zu verifizieren. Um dies zu ermöglichen, wurde bei dem in B1 entwickelten Re-Engineering ein automatisches Verfahren entwickelt, um ein MECHATRONICUML-Modell zu erstellen. Die Integration eines Altsystems besteht aus zwei Schritten: dem Reverse Engineering und dem Forward Engineering. Beim Reverse Engineering wird ein MECHATRONICUML- Modell des Altsystems rekonstruiert. Beim Forward Engineering wird untersucht, ob das rekonstruierte Modell der Altkomponente um weiteres Protokollverhalten erweitert werden kann. Das Forward Engineering wird mit Hilfe der in Abschnitt 1) Koordination beschriebenen Verfeinerung erreicht. Das Reverse Engineering betrachtet zwei verschiedene Aspekte des zu integrierenden Altsystems: das diskrete und das regelungstechnische Verhalten. Das Erlernen des diskreten Verhaltens wurde in [GSR13, Abschnitt ] beschrieben. Im Vergleich zu anderen Lernverfahren wurde hier aufbauend auf einer Überapproximation des möglichen Ein- und Ausgabeverhaltens ermöglicht, dass nach jeder Iteration bereits überprüft werden kann, ob ein Konflikt mit der Kommunikation mit anderen Komponenten vorliegt. Voraussetzung dieses Verfahrens ist, dass die relevanten Zustandsinformationen des Altsystems an der Schnittstelle desselben erfragt werden können. Hierbei wurde eine Integration mit der bisherigen formalen Verifikation vorgestellt. Zum Erlernen des diskreten Verhaltens wurden drei Ansätze vorgestellt, welche je nach vorhandener Information, die über die Komponente vorliegen, anzuwenden sind. Wenn die Komponente eine Schnittstelle anbietet, an der ihr aktueller Zustand erfragt werden kann, wird Grey-Box-Checking angewendet. Ist das nicht der Fall, ist aber Quellcode vorhanden, wird das diskrete Verhalten durch White-Box-Checking erlernt. Wenn kein Quellcode vorhanden ist, und auch der aktuelle Zustand nicht abgefragt werden kann, wird das Black-Box-Checking verwendet. Die Integration der Regelungstechnik wird durch eine Identifikation des kontinuierlichen Verhaltens erreicht. Jeder Pfad des erlernten diskreten Verhaltens kann simuliert werden und für jeden Zustand in diesem Pfad das regelungstechnische Verhalten identifiziert werden. Die Eingabe für die Systemidentifikation ist eine spezifizierte Testtrajektorie oder ein realistischer Lauf des Systems in seiner Umgebung. Basierend auf diesem Eingabe- und Ausgabeverhalten wird die Transferfunktion des Reglers für lineare Systeme identifiziert. Wenn die Transferfunktion bekannt ist, können Rekonfigurationen durch andere Transferfunktionen erkannt werden. 4) Werkzeugunterstützung Die in der 3. Förderperiode erarbeiteten Konzepte wurden prototypisch im Rahmen der Fujaba Real-Time Tool Suite [PTH+10] umgesetzt. Dabei werden sowohl die Modellierung mit MECHATRONICUML als auch die zuvor beschriebenen Methoden im Werkzeug prototypisch unterstützt. Sämtliche entstandenen Methoden und Werkzeuge wurden am RailCab-Demonstrator evaluiert. Die in AP 1 entstandenen Methoden zum Einsatz und zur Verifikation von parametrisierten Koordinationsmustern wurden in [Eck09], [Hei09], [Suc11] implementiert. Dabei wurde in [Eck09] der Synthesealgorithmus zur Kombination von Koordinationsmustern erstellt. Die Verfeinerung von parametrisierten Koordinationsmustern wurde in [Hei09] 125
16 Teilprojekt B1 Entwurfstechniken implementiert, während der Model Checking Algorithmus für zeitbehaftete Graphtransformationssysteme auf diesen Ergebnissen aufbauend in [Suc11] implementiert wurde. Die Analyse von Graphtransformationssystemen mittels Shape Analyse wurde in einem Werkzeug namens Shape Graph Analyzer (SGA) implementiert. Das Werkzeug unterstützt die Erstellung abstrakter Zustandsräume nach zwei unterschiedlichen Abstraktionsverfeinerungsmechanismen und besitzt ein visuelles Frontend, den Visual Shape Graph Analyzer (ViSGA). Das Werkzeug wurde mit der Arbeit an AP1 kontinuierlich weiterentwickelt und war Implementationsgrundlage von [SWW11], [SW11], [Won10], [Buc10]. Die beiden Planungsansätze zur Planung unter Sicherheitsanforderungen wurden in [Röh09] und [Est10] implementiert. [Röh09] umfasst eine Übersetzung von in der Fujaba Real-Time Tool Suite modellierten Planungsproblemen nach GROOVE [Ren08], das hier als Model Checker verwendet wird. Das Lernverfahren, um domänenspezifische Heuristiken anhand einer Menge von Merkmalen zu lernen, wurde in [Est10] implementiert; domänenunabhängige Heuristiken für die Planung mittels heuristischer Suche in [Ahm12]. Die Übersetzung des Planungsproblems unter Berücksichtigung der Dauer von Transformationen nach PDDL wurde in [ZW13] veröffentlicht. Die Werkzeuge für die Erweiterungen der Gefahrenanalyse wurden in [AGL+12] implementiert. Die Dekomposition wurde in [Ani12] und die Laufzeitrisikoanalyse in [AAB+11] umgesetzt. Die Lernverfahren für das Reverse Engineering wurden in [HMS+10c] implementiert. Für die Systemidentifikation wurde die MATLAB System Identification Tool Box in die Fujaba Real-time Tool Suite integriert [HBB+09]. Für die Code Synthese aus MECHATRONICUML-Modellen wurden zwei Ansätze implementiert. Zum einen wurde eine Code Synthese für den BeBot Demonstrator entwickelt [AAB+11]. Mit der Code Synthese können Komponenten und deren über Real-time Statecharts definiertes Verhalten in C++ Quellcode exportiert werden. Der exportierte Quellcode kann in der Simulationsumgebung Stage oder direkt auf dem BeBot ausgeführt werden. Die Code Synthese wurde beispielhaft in Kooperation mit TP C1 für eine Verfolgungsfahrt von BeBots auf der Telewerkbank evaluiert. Zusätzlich zur Code Synthese für den Miniaturroboter BeBot wurde im Rahmen der 3. Förderperiode eine Anbindung an das kommerzielle Werkzeug MATLAB/Simulink geschaffen [HPR+12]. MATLAB/Simulink ist ein Werkzeug für die Spezifikation und Simulation von zeitkontinuierlichem regelungstechnischen Verhalten, für das zahlreiche industrielle Code Generatoren existieren. Im Gegensatz zu MECHATRONICUML bietet MATLAB/Simulink allerdings keine geeignete Modellierung von (parametrisierten) Koordinationsmustern und der damit verbundenen Kommunikation über asynchrone Nachrichten. Die im Rahmen der 3. Förderperiode geschaffene Anbindung erlaubt den Export von Komponenten, deren Real-time Statecharts, sowie eine Abbildung der Rekonfigurationsregeln [Pin12]. Damit kann ein in der Sprache MECHATRONICUML spezifiziertes und mit den beschriebenen formalen Verifikationsverfahren abgesichertes Modell automatisch in ein MATLAB/Simulink-Modell überführt werden. Dies ermöglicht die Generierung von Produktionscode mittels zertifizierter Code Generatoren aus MECHA- TRONICUML-Modellen. 126
17 Schäfer, Wehrheim Teilprojekt B Bezüge zu und Kooperationen mit anderen Arbeiten im Sonderforschungsbereich B1 <=> A1: Aufbauend auf den in [GHH+06] beschriebenen Ergebnissen der 2. Förderperiode wurde in Zusammenarbeit mit TP A1 und TP C3 eine kombinierte Methode zur Erhöhung der Verlässlichkeit komplexer, verteilter mechatronischer Systeme entwickelt und am Beispiel des RailCab-Konvois validiert. Der Ansatz basiert auf sogenannten Bremsprofilen, die es ermöglichen, das kontinuierliche Verhalten des Systems zu kapseln. Die Profile wurden von TP A1 und TP C3 über Optimalsteuerungsprobleme numerisch berechnet und genügen den Optimalitätskriterien Komfort und Zeitdauer des Bremsmanövers. Diese Profile wurden in die im TP B1 entwickelten parametrisierten Koordinationsmuster integriert und für die formale Verifikation verwendet. Die entwickelte Gesamtmethode ermöglicht es, die Komplexität der Verifikationsaufgabe drastisch zu reduzieren und dadurch sehr hohe Sicherheitsansprüche beweisbar umzusetzen. B1 <=> A2: In Zusammenarbeit haben TP A2 und TP B1 ein mehrstufiges Planungssystem entwickelt, das die beiden Planungsansätze der TPs vereint. Das Planungsverfahren von B1, das den Einsatz von unterschiedlichen Koordinationsmustern mittels Graphtransformationssystemen plant, arbeitet dabei auf einer abstrakteren Ebene als der hybride Planer von A2. Rekonfigurationen eines abstrakten Plans von B1 beeinflussen Parameter des hybriden Planers, der pareto-optimale Einstellungen während des Betriebs berechnet. B1 <=> B2: Das Vorgehen für die in TP B1 entwickelten Entwurfstechniken wurde in den Referenzprozess des TP B2 integriert. Dabei wurde ein manueller Übergang von den formal spezifizierten Anwendungsszenarien des TP B2 in die MECHATRONICUML- Modelle des TP B1 entwickelt. In TP B2 wurden die Konzepte für den automatischen Übergang von der Wirkstruktur in das Komponentenmodell von TP B1 implementiert. Des Weiteren wurden die Konzepte für den Übergang um Berücksichtigung von Informationen aus der Gefahrenanalyse des TP B1 im Systemmodell des TP B2 erweitert. B1 <=> B3: Aufbauend auf der bisherigen Kooperation zur Verhaltensvisualisierung in einer VR-Umgebung wurde in der 3. Förderperiode die Integration der von B1 entwickelten Techniken zur Modellierung von Erzeugendensystemen betrachtet. Darüber hinaus wurde untersucht, wie Informationen aus den in TP B1 verwendeten Erweiterungen zur Gefahrenanalyse als zusätzlicher Input für die Testfallgenerierung genutzt werden kann. B1 <=> C1: Wie schon in den ersten zwei Förderperioden, wurden auch in dieser Förderperiode die plattformspezifischen Informationen von C1 genutzt, um die plattformunabhängigen Modelle von B1 zu plattformspezifischen Modellen zu verfeinern. Die Codegenerierung für den Miniroboter BeBot aus Verhaltensmodellen der MECHATRONI- CUML wurde auf der Telewerkbank evaluiert. B1 <=> C2: In Zusammenarbeit mit C2 wurde die in der 2. Förderperiode vorgestellte Integration des Flexible Ressource Manager mit den hybriden Rekonfigurationscharts erweitert. Die in der 3. Förderperiode entwickelten Erweiterungen der Rekonfigurationsverfahren von B1 werden ebenfalls vom FRM unterstützt. Die Laufzeitverifikation aus C2 setzt auf den modellbasierten Entwurfstechniken aus B1 auf. B1 <=> C3: Aufbauend auf den in [GHH+06] beschriebenen Ergebnissen der 2. Förderperiode wurde in Zusammenarbeit mit TP A1 und TP C3 eine kombinierte Methode zur Erhöhung der Verlässlichkeit komplexer, verteilter mechatronischer Systeme entwickelt und am Beispiel des RailCab-Konvois validiert. Der Ansatz basiert auf sogenannten Bremsprofilen, die es ermöglichen, das kontinuierliche Verhalten des Systems zu 127
18 Teilprojekt B1 Entwurfstechniken kapseln. Die Profile wurden von TP A1 und TP C3 über Optimalsteuerungsprobleme numerisch berechnet und genügen den Optimalitätskriterien Komfort und Zeitdauer des Bremsmanövers. Diese Profile wurden in die im TP B1 entwickelten parametrisierten Koordinationsmuster integriert und für die formale Verifikation verwendet. Die entwickelte Gesamtmethode ermöglicht es, die Komplexität der Verifikationsaufgabe drastisch zu reduzieren und dadurch sehr hohe Sicherheitsansprüche beweisbar umzusetzen. B1 <=> D1: Die parametrisierten Koordinationsmuster aus B1 wurden eingesetzt, um die in D1 entwickelten komplexen Abläufe beherrschbar zu halten. Im Bereich der hochdynamischen Antriebsregelung wurden die Entwurfstechniken des TP B1 zu den bereits eingeführten flachheitsbasierten Rekonfigurationsverfahren weiter untersucht und validiert. Zudem wurden die im TP B1 entwickelten Methoden zur sicheren Planung und Gefahrenanalyse im TP D1 angewandt, erprobt und in Kooperation entwickelt. B1 <=> D2: In TP D2 wurden die Techniken zur Modellierung und Analyse der Software vernetzter Systeme von TP B1 angewandt, um die Verlässlichkeit und vor allem die Sicherheit des Systems zu analysieren. Insbesondere der vernetzte Prüfstand von TP D2 bot weitere Evaluierungsmöglichkeiten für die Techniken von B Vergleiche mit Arbeiten außerhalb des Sonderforschungsbereichs 1) Koordination Im Bereich der Synthese existiert mit [GV06] eine verwandte Arbeit, die dasselbe Ziel mit der Synthese verfolgt. In diesem Ansatz werden Einschränkungen für das synthetisierte Verhalten über Restriktionsautomaten definiert. Der Ansatz basiert auf einem diskreten Zeitmodell, während der hier entwickelte Ansatz auf dem verbreiteteren kontinuierlichen Zeitmodell basiert. In der Zielsetzung ähnliche Arbeiten zur Shape Analyse für Graphtransformationssysteme in AP1 finden sich zum Beispiel in [BCK08] und [RZ10]. Diese Arbeiten verfolgen ebenfalls das Ziel unendlich große Graphtransformationssysteme zu verifizieren. In [BCK08] wird dies erreicht durch die Transformation des Graphtransformationssystems in einen neuen, auf Petrinetzen basierenden Formalismus. Dieser Ansatz hat einige interessante Beispiele gut verifizieren können, macht jedoch Annahmen, die die Art der verwendbaren Graphtransformationssysteme stark einschränken. In [RZ10] wird eine unserem Ansatz ähnlichere Technik entwickelt. Graphen werden abstrahiert, in dem Knoten zusammengelegt werden. Das Ergebnis sind Shape Graphen. Die formale Basis dieses Ansatzes ist jedoch eine ganz andere. Das hat zur Folge, dass die Optionen für Abstraktionsverfeinerung in diesem Ansatz extrem eingeschränkt sind. Allerdings liefert die simplere Verfeinerung und die Fähigkeit, bis zu einer gewissen Grenze Knoten zählen zu können in einigen Fällen bessere Ergebnisse. Die Verifikation eines zeitbehafteten Graphtransformationssystems, jedoch mit einer anderen Semantik als der von uns verwendeten, unterstützen auch Real-Time Maude [ÖM07] und der Ansatz von Michelon u. a. [MCR07]. Real-Time Maude unterstützt jedoch nur eine Verifikation für diskrete Zeitmodelle, während unser Ansatz auf den verbreiteteren kontinuierlichen Zeitmodellen basiert. Der Ansatz von Michelon u.a. basiert auf festen Domänenannahmen, die unser Ansatz nicht treffen muss. Der verbreitete graphbasierte Model Checker GROOVE [Ren08] beherrscht kein Zeitmodell. Die Integration von parametrisierten Koordinationsmustern und Komponentenstorydiagrammen ermöglicht eine Rekonfiguration von hierarchischen Komponenten unter 128
19 Schäfer, Wehrheim Teilprojekt B1 Echtzeitbedingungen. Unser Ansatz basiert auf Konzepten des Fractal Komponentenmodells [LLC10], das jedoch keine Echtzeiteigenschaften unterstützt. Aktuelle Übersichtspapiere [HPB+10], [CSV+11] zeigen, dass keines der untersuchten Komponentenmodelle eine hierarchische Rekonfiguration unter Echtzeitbedingungen ermöglicht. Die parallel entstandenen Arbeiten [PPO+12] und [HCH12] verfolgen eine ähnliche Zielsetzung, bieten jedoch nicht die Möglichkeit einer formalen Verifikation des Verhaltens. Der entwickelte Verfeinerungsansatz für parametrisierte Koordinationsmuster kombiniert und erweitert Verfeinerungen für zeitbehaftete Automaten [TY01] und Graphtransformationssysteme [HT04]. Verfeinerungen für zeitbehaftete Automaten erfassen die Strukturänderungen innerhalb eines parametrisierten Koordinationsmuster nicht, während Verfeinerungen für Graphtransformationssysteme keine Zeit betrachten. Außerhalb des SFBs haben sich nur wenige Arbeiten mit der Planung für Graphtransformationssysteme beschäftigt. In [EJL06] und [Sni11] werden domänenunabhängige Heuristiken genutzt, um in dem Zustandsraum eines Graphtransformationssystems nach einem Zielzustand zu suchen. Die verwendeten Heuristiken basieren lediglich auf der Ähnlichkeit (in Form von Anzahl Knoten und Kanten) zwischen dem aktuellen Zustand und dem Zielzustand. In [Mei12] wurde ein System zur Übersetzung von Planungsproblemen zwischen Graphtransformationssystemen und PDDL entwickelt. Der Fokus des Übersetzers liegt jedoch im Gegensatz zu den Systemen von [TK11] und [ZW13], die innerhalb des SFBs entwickelt worden sind auf der Richtung von PDDL nach Graphtransformationssysteme. Außerdem unterstützt das System keine zeitkonsumierenden Aktionen. Uns sind keine graphtransformationsbasierten Planungsysteme bekannt, die die Ausführungsdauer von Aktionen berücksichtigen. Es gibt zwar graphtransformationsbasierte Ansätze, die ebenfalls Zeitaspekte in Regeln unterstützen; diese werden jedoch nicht zur Planung verwendet. Die beiden relevantesten Arbeiten in Bezug zu den im SFB entstandenen Arbeiten sind [RDV09] und [LGB+12]. In [RDV09] werden Regeln mit einer Dauer und Periodizität versehen. Während hier Regelanwendungen abgebrochen werden können, garantiert unser Ansatz die vollständige Ausführung von Transformationen. In [LGB+12] wird eine ereignisorientierte Simulation verwendet, die es Transformationsregeln erlaubt, die Ausführung von anderen Regeln zeitlich festzulegen. Für weitere verwandte Arbeiten im diesem Bereich wird auf [HZ13] verwiesen. 2) Gefahrenanalyse Neben der in der 2. Förderperiode entwickelten Gefahrenanalyse betrachten die Ansätze aus [GOR6, RS12] als einzige Rekonfiguration. Außerdem existiert eine Reihe von Ansätzen, die Zeit betrachten [GCW07], [CGW08], [GG06], [KGF07], [KNP11], [MS02]. Allerdings gibt es keinen Ansatz, der die Betrachtung von Rekonfiguration und Zeit kombiniert. Deshalb können diese Ansätze nicht dazu verwendet werden, um den Übergang zwischen zwei Konfigurationen zu analysieren. Bestehende Ansätze für komponentenbasierte Gefahrenanalyse betrachten keine Dekomposition. Bestehende Ansätze zur Dekomposition von Fehlerbäumen, zum Beispiel formelbasierte [AS98], vernachlässigen die Komponentenstruktur des Systems. Sie sind daher nicht zur Dekomposition einer komponentenbasierten Gefahrenanalyse geeignet. Existierende Ansätze für Laufzeitanalysen analysieren keine Auftrittswahrscheinlichkeiten von Gefahren. Sie verfolgen einerseits eine Zertifizierung zur Laufzeit [SBT11] oder konzentrieren sich auf die Detektion von Anomalien im ausgeführten System und ver- 129
20 Teilprojekt B1 Entwurfstechniken suchen dann, das System zu seinem beabsichtigten Verhalten zurück zu führen, wie zum Beispiel in [Rus08]. 3) Re-Engineering Verwandt zu unseren Arbeiten zur Integration von Altkomponenten sind reguläre Inferenzansätze und Modellabstraktionstechniken aus dem Bereich der formalen Verifikation. Sämtliche verwandten Lernalgorithmen im Bereich des Black-Box-Ansatzes, wie zum Beispiel [PVY99], basieren auf dem von Angluin. Bis auf [PVY99], versuchen alle Ansätze wie zum Beispiel [Ber06] das ganze Verhalten zu synthetisieren. In unserem Ansatz ist es nicht erforderlich das gesamte Verhalten der Altkomponente zu erlernen. Nur der relevante Teil der Integration ist erforderlich. Unser Gray und White-Box-Ansatz lassen sich aufgrund der unterschiedlichen zur Verfügung stehenden Informationen nicht direkt mit diesen Ansätzen vergleichen. Bezogen auf den Gray-Box-Ansatz lässt sich am ehesten ein Vergleich mit dem Ansatz von [EG+06] erstellen, der ebenfalls davon ausgeht, mehr Informationen als für die reine Black-Box-Analyse zur Verfügung zu haben. Im Vergleich dazu ermöglicht unser Gray- Box-Ansatz direkt das Verhalten zu lernen, ohne Äquivalenzanfragen, sowie reaktive Systeme und Zeit zu betrachten. Alle Ansätze zur Abstraktion wie [Kur94], [LNA99], [CGJ+03] basieren auf einer reinen Quellcodeanalyse. Es werden im Vergleich zu unserem Gray-Box-Ansatz keine Tests durchgeführt, um die Eingabe des Systems zu berücksichtigen. Weiterhin betrachten diese Ansätze im Vergleich zu all unseren keine Interaktion mit der Umgebung (Kontext) sowie Verletzungen von Zeitbedingungen. 130
Lineargleichungssysteme: Additions-/ Subtraktionsverfahren
Lineargleichungssysteme: Additions-/ Subtraktionsverfahren W. Kippels 22. Februar 2014 Inhaltsverzeichnis 1 Einleitung 2 2 Lineargleichungssysteme zweiten Grades 2 3 Lineargleichungssysteme höheren als
MehrFRAUNHOFER-INSTITUT FÜR PRODUKTIONSTECHNOLOGIE IPT PROJEKTGRUPPE ENTWURFSTECHNIK MECHATRONIK
FRAUNHOFER-INSTITUT FÜR PRODUKTIONSTECHNOLOGIE IPT PROJEKTGRUPPE ENTWURFSTECHNIK MECHATRONIK DIE METHODE FÜR DEN SOFTWAREENTWURF VERNETZTER MECHATRONISCHER SYSTEME Innovative Funktionen moderner mechatronischer
MehrMORE Profile. Pass- und Lizenzverwaltungssystem. Stand: 19.02.2014 MORE Projects GmbH
MORE Profile Pass- und Lizenzverwaltungssystem erstellt von: Thorsten Schumann erreichbar unter: thorsten.schumann@more-projects.de Stand: MORE Projects GmbH Einführung Die in More Profile integrierte
Mehr1 Mathematische Grundlagen
Mathematische Grundlagen - 1-1 Mathematische Grundlagen Der Begriff der Menge ist einer der grundlegenden Begriffe in der Mathematik. Mengen dienen dazu, Dinge oder Objekte zu einer Einheit zusammenzufassen.
MehrÜ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 9 17. Dezember 2002 www4.in.tum.de/~rumpe/se
MehrSpeicher in der Cloud
Speicher in der Cloud Kostenbremse, Sicherheitsrisiko oder Basis für die unternehmensweite Kollaboration? von Cornelius Höchel-Winter 2013 ComConsult Research GmbH, Aachen 3 SYNCHRONISATION TEUFELSZEUG
MehrPrimzahlen und RSA-Verschlüsselung
Primzahlen und RSA-Verschlüsselung Michael Fütterer und Jonathan Zachhuber 1 Einiges zu Primzahlen Ein paar Definitionen: Wir bezeichnen mit Z die Menge der positiven und negativen ganzen Zahlen, also
MehrGrundlagen verteilter Systeme
Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 3 12.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: a)
Mehr10.3.1.8 Übung - Konfigurieren einer Windows 7-Firewall
5.0 10.3.1.8 Übung - Konfigurieren einer Windows 7-Firewall Drucken Sie diese Übung aus und führen Sie sie durch. In dieser Übung werden Sie erfahren, wie man die Windows 7-Firewall konfiguriert und einige
Mehr1 topologisches Sortieren
Wolfgang Hönig / Andreas Ecke WS 09/0 topologisches Sortieren. Überblick. Solange noch Knoten vorhanden: a) Suche Knoten v, zu dem keine Kante führt (Falls nicht vorhanden keine topologische Sortierung
MehrNicht kopieren. Der neue Report von: Stefan Ploberger. 1. Ausgabe 2003
Nicht kopieren Der neue Report von: Stefan Ploberger 1. Ausgabe 2003 Herausgeber: Verlag Ploberger & Partner 2003 by: Stefan Ploberger Verlag Ploberger & Partner, Postfach 11 46, D-82065 Baierbrunn Tel.
Mehretutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche
etutor Benutzerhandbuch Benutzerhandbuch XQuery Georg Nitsche Version 1.0 Stand März 2006 Versionsverlauf: Version Autor Datum Änderungen 1.0 gn 06.03.2006 Fertigstellung der ersten Version Inhaltsverzeichnis:
MehrInformationssystemanalyse Problemstellung 2 1. Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse:
Informationssystemanalyse Problemstellung 2 1 Problemstellung Trotz aller Methoden, Techniken usw. zeigen Untersuchungen sehr negative Ergebnisse: große Software-Systeme werden im Schnitt ein Jahr zu spät
MehrInformationsblatt Induktionsbeweis
Sommer 015 Informationsblatt Induktionsbeweis 31. März 015 Motivation Die vollständige Induktion ist ein wichtiges Beweisverfahren in der Informatik. Sie wird häufig dazu gebraucht, um mathematische Formeln
MehrOutlook. sysplus.ch outlook - mail-grundlagen Seite 1/8. Mail-Grundlagen. Posteingang
sysplus.ch outlook - mail-grundlagen Seite 1/8 Outlook Mail-Grundlagen Posteingang Es gibt verschiedene Möglichkeiten, um zum Posteingang zu gelangen. Man kann links im Outlook-Fenster auf die Schaltfläche
MehrErstellung von Reports mit Anwender-Dokumentation und System-Dokumentation in der ArtemiS SUITE (ab Version 5.0)
Erstellung von und System-Dokumentation in der ArtemiS SUITE (ab Version 5.0) In der ArtemiS SUITE steht eine neue, sehr flexible Reporting-Funktion zur Verfügung, die mit der Version 5.0 noch einmal verbessert
MehrProjektmanagement in der Spieleentwicklung
Projektmanagement in der Spieleentwicklung Inhalt 1. Warum brauche ich ein Projekt-Management? 2. Die Charaktere des Projektmanagement - Mastermind - Producer - Projektleiter 3. Schnittstellen definieren
MehrWhitepaper. Produkt: combit Relationship Manager 7. combit Relationship Manager email-rückläufer Script. combit GmbH Untere Laube 30 78462 Konstanz
combit GmbH Untere Laube 30 78462 Konstanz Whitepaper Produkt: combit Relationship Manager 7 combit Relationship Manager email-rückläufer Script Inhalt Einleitung 3 Notwendige Anpassungen 3 crm Solution
MehrMSXFORUM - Exchange Server 2003 > SMTP Konfiguration von Exchange 2003
Page 1 of 8 SMTP Konfiguration von Exchange 2003 Kategorie : Exchange Server 2003 Veröffentlicht von webmaster am 25.02.2005 SMTP steht für Simple Mail Transport Protocol, welches ein Protokoll ist, womit
MehrTeambildung. 1 Einleitung. 2 Messen der Produktivität
1 Einleitung Teambildung In der Entwicklung, speziell bei hohem Softwareanteil, stellen Personalkosten den primären Kostenanteil dar. Daher ist es wichtig, den Personalbedarf optimal zu bestimmen. You
MehrGEVITAS Farben-Reaktionstest
GEVITAS Farben-Reaktionstest GEVITAS Farben-Reaktionstest Inhalt 1. Allgemeines... 1 2. Funktionsweise der Tests... 2 3. Die Ruhetaste und die Auslösetaste... 2 4. Starten der App Hauptmenü... 3 5. Auswahl
MehrSoftware Engineering. Sommersemester 2012, Dr. Andreas Metzger
Software Engineering (Übungsblatt 2) Sommersemester 2012, Dr. Andreas Metzger Übungsblatt-Themen: Prinzip, Technik, Methode und Werkzeug; Arten von Wartung; Modularität (Kohäsion/ Kopplung); Inkrementelle
MehrBeweisbar sichere Verschlüsselung
Beweisbar sichere Verschlüsselung ITS-Wahlpflichtvorlesung Dr. Bodo Möller Ruhr-Universität Bochum Horst-Görtz-Institut für IT-Sicherheit Lehrstuhl für Kommunikationssicherheit bmoeller@crypto.rub.de 6
MehrWürfelt man dabei je genau 10 - mal eine 1, 2, 3, 4, 5 und 6, so beträgt die Anzahl. der verschiedenen Reihenfolgen, in denen man dies tun kann, 60!.
040304 Übung 9a Analysis, Abschnitt 4, Folie 8 Die Wahrscheinlichkeit, dass bei n - maliger Durchführung eines Zufallexperiments ein Ereignis A ( mit Wahrscheinlichkeit p p ( A ) ) für eine beliebige Anzahl
MehrPowerMover. Ein halbautomatischer Sortierer für Outlook-PowerUser. Ein Add-In für die Versionen 2007 und 2010
PowerMover Ein halbautomatischer Sortierer für Outlook-PowerUser. Ein Add-In für die Versionen 2007 und 2010 Inhaltsverzeichnis: 1 Einleitung... 2 2 Bedienung... 3 2.1 Outlook-Menü-Leiste... 3 2.2 Den
MehrElexis-BlueEvidence-Connector
Elexis-BlueEvidence-Connector Gerry Weirich 26. Oktober 2012 1 Einführung Dieses Plugin dient dazu, den Status Hausarztpatient zwischen der BlueEvidence- Anwendung und Elexis abzugleichen. Das Plugin markiert
MehrArbeiten mit UMLed und Delphi
Arbeiten mit UMLed und Delphi Diese Anleitung soll zeigen, wie man Klassen mit dem UML ( Unified Modeling Language ) Editor UMLed erstellt, in Delphi exportiert und dort so einbindet, dass diese (bis auf
MehrLernerfolge sichern - Ein wichtiger Beitrag zu mehr Motivation
Lernerfolge sichern - Ein wichtiger Beitrag zu mehr Motivation Einführung Mit welchen Erwartungen gehen Jugendliche eigentlich in ihre Ausbildung? Wir haben zu dieser Frage einmal die Meinungen von Auszubildenden
MehrWas taugt der Wertpapierprospekt für die Anlegerinformation?
Was taugt der Wertpapierprospekt für die Anlegerinformation? Panel 1 Rahmenbedingungen für Anlegerinformation und Anlegerschutz beim Wertpapiererwerb Verhältnis zu Beratung, Informationsblatt und Investorenpräsentation
MehrUrlaubsregel in David
Urlaubsregel in David Inhaltsverzeichnis KlickDown Beitrag von Tobit...3 Präambel...3 Benachrichtigung externer Absender...3 Erstellen oder Anpassen des Anworttextes...3 Erstellen oder Anpassen der Auto-Reply-Regel...5
MehrMusterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9
Prof. Dr. Wilhelm Schäfer Paderborn, 15. Dezember 2014 Christian Brenner Tristan Wittgen Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Aufgabe 1 Codegenerierung
MehrTipp III: Leiten Sie eine immer direkt anwendbare Formel her zur Berechnung der sogenannten "bedingten Wahrscheinlichkeit".
Mathematik- Unterrichts- Einheiten- Datei e. V. Klasse 9 12 04/2015 Diabetes-Test Infos: www.mued.de Blutspenden werden auf Diabetes untersucht, das mit 8 % in der Bevölkerung verbreitet ist. Dabei werden
MehrAutoformat während der Eingabe
Vorbereitung der Arbeitsumgebung Herbert Utz Verlag Endlich! Der Text ist abgeschlossen und die letzten Korrekturen sind eingearbeitet. Herzlichen Glückwunsch. Jetzt bleibt nur noch die richtige Formatierung,
MehrDIE ANWENDUNG VON KENNZAHLEN IN DER PRAXIS: WEBMARK SEILBAHNEN IM EINSATZ
Kurzfassung DIE ANWENDUNG VON KENNZAHLEN IN DER PRAXIS: WEBMARK SEILBAHNEN IM EINSATZ Mag. Klaus Grabler 9. Oktober 2002 OITAF Seminar 2002 Kongresshaus Innsbruck K ennzahlen sind ein wesentliches Instrument
Mehr4 Aufzählungen und Listen erstellen
4 4 Aufzählungen und Listen erstellen Beim Strukturieren von Dokumenten und Inhalten stellen Listen und Aufzählungen wichtige Werkzeuge dar. Mit ihnen lässt sich so ziemlich alles sortieren, was auf einer
MehrPTV VISWALK TIPPS UND TRICKS PTV VISWALK TIPPS UND TRICKS: VERWENDUNG DICHTEBASIERTER TEILROUTEN
PTV VISWALK TIPPS UND TRICKS PTV VISWALK TIPPS UND TRICKS: VERWENDUNG DICHTEBASIERTER TEILROUTEN Karlsruhe, April 2015 Verwendung dichte-basierter Teilrouten Stellen Sie sich vor, in einem belebten Gebäude,
Mehr1. Man schreibe die folgenden Aussagen jeweils in einen normalen Satz um. Zum Beispiel kann man die Aussage:
Zählen und Zahlbereiche Übungsblatt 1 1. Man schreibe die folgenden Aussagen jeweils in einen normalen Satz um. Zum Beispiel kann man die Aussage: Für alle m, n N gilt m + n = n + m. in den Satz umschreiben:
MehrEmpathisches CRM. (Empathic CRM) Sven Bruck, die dialogagenten. die dialogagenten Agentur Beratung Service GmbH Katernberger Straße 4 42115 Wuppertal
Empathisches CRM (Empathic CRM) Sven Bruck, die dialogagenten die dialogagenten Agentur Beratung Service GmbH Katernberger Straße 4 42115 Wuppertal +49 (0)202. 371 47 0 crmpathy@die-da.com www.die-da.com
MehrAnhand des bereits hergeleiteten Models erstellen wir nun mit der Formel
Ausarbeitung zum Proseminar Finanzmathematische Modelle und Simulationen bei Raphael Kruse und Prof. Dr. Wolf-Jürgen Beyn zum Thema Simulation des Anlagenpreismodels von Simon Uphus im WS 09/10 Zusammenfassung
MehrKurzanleitung für Verkäufer
Kurzanleitung für Verkäufer Registrieren auf www.easybasar.de Einloggen Am Basar anmelden Artikel erfassen Artikel abgeben Artikel abholen Registrieren bei www.easybasar.de Sie sollten sich bereits vor
Mehr50. Mathematik-Olympiade 2. Stufe (Regionalrunde) Klasse 11 13. 501322 Lösung 10 Punkte
50. Mathematik-Olympiade. Stufe (Regionalrunde) Klasse 3 Lösungen c 00 Aufgabenausschuss des Mathematik-Olympiaden e.v. www.mathematik-olympiaden.de. Alle Rechte vorbehalten. 503 Lösung 0 Punkte Es seien
MehrEnigmail Konfiguration
Enigmail Konfiguration 11.06.2006 Steffen.Teubner@Arcor.de Enigmail ist in der Grundkonfiguration so eingestellt, dass alles funktioniert ohne weitere Einstellungen vornehmen zu müssen. Für alle, die es
Mehr1 Einleitung. Lernziele. automatische Antworten bei Abwesenheit senden. Einstellungen für automatische Antworten Lerndauer. 4 Minuten.
1 Einleitung Lernziele automatische Antworten bei Abwesenheit senden Einstellungen für automatische Antworten Lerndauer 4 Minuten Seite 1 von 18 2 Antworten bei Abwesenheit senden» Outlook kann während
MehrL10N-Manager 3. Netzwerktreffen der Hochschulübersetzer/i nnen Mannheim 10. Mai 2016
L10N-Manager 3. Netzwerktreffen der Hochschulübersetzer/i nnen Mannheim 10. Mai 2016 Referentin: Dr. Kelly Neudorfer Universität Hohenheim Was wir jetzt besprechen werden ist eine Frage, mit denen viele
Mehrecaros2 - Accountmanager
ecaros2 - Accountmanager procar informatik AG 1 Stand: FS 09/2012 Inhaltsverzeichnis 1 Aufruf des ecaros2-accountmanager...3 2 Bedienung Accountmanager...4 procar informatik AG 2 Stand: FS 09/2012 1 Aufruf
MehrAGROPLUS Buchhaltung. Daten-Server und Sicherheitskopie. Version vom 21.10.2013b
AGROPLUS Buchhaltung Daten-Server und Sicherheitskopie Version vom 21.10.2013b 3a) Der Daten-Server Modus und der Tresor Der Daten-Server ist eine Betriebsart welche dem Nutzer eine grosse Flexibilität
MehrProfessionelle Seminare im Bereich MS-Office
Der Name BEREICH.VERSCHIEBEN() ist etwas unglücklich gewählt. Man kann mit der Funktion Bereiche zwar verschieben, man kann Bereiche aber auch verkleinern oder vergrößern. Besser wäre es, die Funktion
MehrDie wichtigsten Werkzeuge, um UNTERNEHMENSKULTUR BEWUSST zu gestalten.
3 Die wichtigsten Werkzeuge, um UNTERNEHMENSKULTUR BEWUSST zu gestalten. Rasante Marktverände-rungen und eine ständig wachsende Komplexität beeinflussen heute die Unternehmensentwicklung mehr denn je zuvor.
MehrInventur. Bemerkung. / Inventur
Inventur Die beliebige Aufteilung des Artikelstamms nach Artikeln, Lieferanten, Warengruppen, Lagerorten, etc. ermöglicht es Ihnen, Ihre Inventur in mehreren Abschnitten durchzuführen. Bemerkung Zwischen
MehrGrundlagen des Software Engineering
Grundlagen des Software Engineering Teil 1: SW-Management Fachrichtung Wirtschaftsinformatik FB Berufsakademie der FHW Berlin Prof. Dr. Gert Faustmann Motivation des Risikomanagements Ungefähr 80 Prozent
MehrDie elektronische Rechnung als Fortsetzung der elektronischen Beauftragung so einfach geht es:
Bei Rückfragen erreichen Sie uns unter 0571-805474 Anleitung Die elektronische Rechnung als Fortsetzung der elektronischen Beauftragung so einfach geht es: Inhalt 1 Hintergrund zur elektronischen Rechnung
MehrDokumentation IBIS Monitor
Dokumentation IBIS Monitor Seite 1 von 16 11.01.06 Inhaltsverzeichnis 1. Allgemein 2. Installation und Programm starten 3. Programmkonfiguration 4. Aufzeichnung 4.1 Aufzeichnung mitschneiden 4.1.1 Inhalt
Mehr[Customer Service by KCS.net] KEEPING CUSTOMERS SUCCESSFUL
[Customer Service by KCS.net] KEEPING CUSTOMERS SUCCESSFUL Was bedeutet Customer Service by KCS.net? Mit der Einführung von Microsoft Dynamics AX ist der erste wichtige Schritt für viele Unternehmen abgeschlossen.
Mehr1. Einführung 2. 2. Erstellung einer Teillieferung 2. 3. Erstellung einer Teilrechnung 6
Inhalt 1. Einführung 2 2. Erstellung einer Teillieferung 2 3. Erstellung einer Teilrechnung 6 4. Erstellung einer Sammellieferung/ Mehrere Aufträge zu einem Lieferschein zusammenfassen 11 5. Besonderheiten
MehrMotivation. Motivation
Vorlesung Modellierung nebenläufiger Systeme Sommersemester 2012 Universität Duisburg-Essen Was sind nebenläufige Systeme? Ganz allgemein: Systeme, bei denen mehrere Komponenten/Prozesse nebenläufig arbeiten
MehrBenchmark MES Anbietern
MES Anbietern MES Consult beobachtet den MES Markt seit über 10 Jahren. Kritisch dabei ist immer wieder, dass aufgrund der heutigen Aktualität des Themas viele Anbieter ihren Systemen, die meist aus der
Mehr10 Erweiterung und Portierung
10.1 Überblick In vielen Fällen werden Compiler nicht vollständig neu geschrieben, sondern von einem Rechnersystem auf ein anderes portiert. Das spart viel Arbeit, ist aber immer noch eine sehr anspruchsvolle
MehrAnleitung zur Verwendung der VVW-Word-Vorlagen
Anleitung zur Verwendung der VVW-Word-Vorlagen v1.0. Jun-15 1 1 Vorwort Sehr geehrte Autorinnen und Autoren, wir haben für Sie eine Dokumentenvorlage für Microsoft Word entwickelt, um Ihnen die strukturierte
MehrWindows Server 2012 RC2 konfigurieren
Windows Server 2012 RC2 konfigurieren Kurzanleitung um einen Windows Server 2012 als Primären Domänencontroller einzurichten. Vorbereitung und Voraussetzungen In NT 4 Zeiten, konnte man bei der Installation
MehrCopyright 2014 Delta Software Technology GmbH. All Rights reserved.
Karlsruhe, 21. Mai 2014 Softwareentwicklung - Modellgetrieben und trotzdem agil Daniela Schilling Delta Software Technology GmbH The Perfect Way to Better Software Modellgetriebene Entwicklung Garant für
MehrMotivation. Formale Grundlagen der Informatik 1 Kapitel 5 Kontextfreie Sprachen. Informales Beispiel. Informales Beispiel.
Kontextfreie Kontextfreie Motivation Formale rundlagen der Informatik 1 Kapitel 5 Kontextfreie Sprachen Bisher hatten wir Automaten, die Wörter akzeptieren Frank Heitmann heitmann@informatik.uni-hamburg.de
MehrCharakteristikum des Gutachtenstils: Es wird mit einer Frage begonnen, sodann werden die Voraussetzungen Schritt für Schritt aufgezeigt und erörtert.
Der Gutachtenstil: Charakteristikum des Gutachtenstils: Es wird mit einer Frage begonnen, sodann werden die Voraussetzungen Schritt für Schritt aufgezeigt und erörtert. Das Ergebnis steht am Schluß. Charakteristikum
MehrAnleitung zum Computercheck So aktualisieren Sie Ihr Microsoft-Betriebssystem
Anleitung zum Computercheck So aktualisieren Sie Ihr Microsoft-Betriebssystem Information Wichtiger Hinweis: Microsoft hat am 8. April 2014 den Support für Windows XP eingestellt. Neue Sicherheitsaktualisierungen
MehrIst Fernsehen schädlich für die eigene Meinung oder fördert es unabhängig zu denken?
UErörterung zu dem Thema Ist Fernsehen schädlich für die eigene Meinung oder fördert es unabhängig zu denken? 2000 by christoph hoffmann Seite I Gliederung 1. In zu großen Mengen ist alles schädlich. 2.
MehrDatensicherung. Beschreibung der Datensicherung
Datensicherung Mit dem Datensicherungsprogramm können Sie Ihre persönlichen Daten problemlos Sichern. Es ist möglich eine komplette Datensicherung durchzuführen, aber auch nur die neuen und geänderten
MehrKonzepte der Informatik
Konzepte der Informatik Vorkurs Informatik zum WS 2011/2012 26.09. - 30.09.2011 17.10. - 21.10.2011 Dr. Werner Struckmann / Christoph Peltz Stark angelehnt an Kapitel 1 aus "Abenteuer Informatik" von Jens
MehrMaschinenrichtlinie 2006/42/EG 150 Fragen und Antworten zum Selbststudium
QUALITY-APPS Applikationen für das Qualitätsmanagement Maschinenrichtlinie 2006/42/EG 150 Fragen und Antworten zum Selbststudium Autor: Prof. Dr. Jürgen P. Bläsing Die Maschinenrichtlinie 2006/42/EG ist
MehrProduktskizze. 28. November 2005 Projektgruppe Syspect
28. November 2005 Carl von Ossietzky Universität Oldenburg Fakultät II Department für Informatik Abteilung Entwicklung korrekter Systeme Inhaltsverzeichnis 1 Einleitung 3 2 Die graphische Oberfläche der
MehrHinweise zur Datensicherung für die - Prüfmittelverwaltung - Inhalt
Hinweise zur Datensicherung für die - Prüfmittelverwaltung - Inhalt 1. Vorbetrachtungen... 2 2. Die Installation... 2 3. Einstellungen - Erstellung der Verknüpfung... 3 3.1 Benutzung des Konfigurationsprogramms
MehrAutoCAD 2007 - Dienstprogramm zur Lizenzübertragung
AutoCAD 2007 - Dienstprogramm zur Lizenzübertragung Problem: Um AutoCAD abwechselnd auf mehreren Rechnern einsetzen zu können konnte man bis AutoCAD 2000 einfach den Dongle umstecken. Seit AutoCAD 2000i
MehrLeseprobe. Thomas Konert, Achim Schmidt. Design for Six Sigma umsetzen ISBN: 978-3-446-41230-9. Weitere Informationen oder Bestellungen unter
Leseprobe Thomas Konert, Achim Schmidt Design for Six Sigma umsetzen ISBN: 978-3-446-41230-9 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-41230-9 sowie im Buchhandel. Carl
Mehriphone- und ipad-praxis: Kalender optimal synchronisieren
42 iphone- und ipad-praxis: Kalender optimal synchronisieren Die Synchronisierung von ios mit anderen Kalendern ist eine elementare Funktion. Die Standard-App bildet eine gute Basis, für eine optimale
MehrDie Gleichung A x = a hat für A 0 die eindeutig bestimmte Lösung. Für A=0 und a 0 existiert keine Lösung.
Lineare Gleichungen mit einer Unbekannten Die Grundform der linearen Gleichung mit einer Unbekannten x lautet A x = a Dabei sind A, a reelle Zahlen. Die Gleichung lösen heißt, alle reellen Zahlen anzugeben,
MehrInsiderwissen 2013. Hintergrund
Insiderwissen 213 XING EVENTS mit der Eventmanagement-Software für Online Eventregistrierung &Ticketing amiando, hat es sich erneut zur Aufgabe gemacht zu analysieren, wie Eventveranstalter ihre Veranstaltungen
MehrWir machen neue Politik für Baden-Württemberg
Wir machen neue Politik für Baden-Württemberg Am 27. März 2011 haben die Menschen in Baden-Württemberg gewählt. Sie wollten eine andere Politik als vorher. Die Menschen haben die GRÜNEN und die SPD in
Mehragitat Werkzeuge kann man brauchen und missbrauchen - vom Einsatz von NLP in der Führung
agitat Werkzeuge kann man brauchen und missbrauchen - vom Einsatz von NLP in der Führung Der Inhalt dieses Vortrages Moderne Führungskräfte stehen vor der Herausforderung, ihr Unternehmen, ihre Mitarbeiter
MehrTerminabgleich mit Mobiltelefonen
Terminabgleich mit Mobiltelefonen Sie können Termine- und Aufgaben aus unserem Kalender, sowie die Adressdaten aus dem Hauptprogramm mit Ihrem Mobiltelefon abgleichen. MS Outlook dient dabei als Schnittstelle
Mehr4. BEZIEHUNGEN ZWISCHEN TABELLEN
4. BEZIEHUNGEN ZWISCHEN TABELLEN Zwischen Tabellen können in MS Access Beziehungen bestehen. Durch das Verwenden von Tabellen, die zueinander in Beziehung stehen, können Sie Folgendes erreichen: Die Größe
MehrErstellen von x-y-diagrammen in OpenOffice.calc
Erstellen von x-y-diagrammen in OpenOffice.calc In dieser kleinen Anleitung geht es nur darum, aus einer bestehenden Tabelle ein x-y-diagramm zu erzeugen. D.h. es müssen in der Tabelle mindestens zwei
MehrWinWerk. Prozess 6a Rabatt gemäss Vorjahresverbrauch. KMU Ratgeber AG. Inhaltsverzeichnis. Im Ifang 16 8307 Effretikon
WinWerk Prozess 6a Rabatt gemäss Vorjahresverbrauch 8307 Effretikon Telefon: 052-740 11 11 Telefax: 052-740 11 71 E-Mail info@kmuratgeber.ch Internet: www.winwerk.ch Inhaltsverzeichnis 1 Ablauf der Rabattverarbeitung...
MehrOECD Programme for International Student Assessment PISA 2000. Lösungen der Beispielaufgaben aus dem Mathematiktest. Deutschland
OECD Programme for International Student Assessment Deutschland PISA 2000 Lösungen der Beispielaufgaben aus dem Mathematiktest Beispielaufgaben PISA-Hauptstudie 2000 Seite 3 UNIT ÄPFEL Beispielaufgaben
MehrAutorisierung. Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente
Autorisierung Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente Dokumentation zum Referat von Matthias Warnicke und Joachim Schröder Modul: Komponenten basierte Softwareentwickelung
MehrWas sind Jahres- und Zielvereinbarungsgespräche?
6 Was sind Jahres- und Zielvereinbarungsgespräche? Mit dem Jahresgespräch und der Zielvereinbarung stehen Ihnen zwei sehr wirkungsvolle Instrumente zur Verfügung, um Ihre Mitarbeiter zu führen und zu motivieren
MehrAnleitung über den Umgang mit Schildern
Anleitung über den Umgang mit Schildern -Vorwort -Wo bekommt man Schilder? -Wo und wie speichert man die Schilder? -Wie füge ich die Schilder in meinen Track ein? -Welche Bauteile kann man noch für Schilder
MehrStundenerfassung Version 1.8 Anleitung Arbeiten mit Replikaten
Stundenerfassung Version 1.8 Anleitung Arbeiten mit Replikaten 2008 netcadservice GmbH netcadservice GmbH Augustinerstraße 3 D-83395 Freilassing Dieses Programm ist urheberrechtlich geschützt. Eine Weitergabe
MehrSoftware-Engineering SS03. Zustandsautomat
Zustandsautomat Definition: Ein endlicher Automat oder Zustandsautomat besteht aus einer endlichen Zahl von internen Konfigurationen - Zustände genannt. Der Zustand eines Systems beinhaltet implizit die
MehrInstitut für Leistungselektronik und Elektrische Antriebe. Übungen Regelungstechnik 2
Institut für Leistungselektronik und Elektrische Antriebe Prof. Dr.-Ing. J. Roth-Stielow Übungen Regelungstechnik 2 Inhalt der Übungen: 1. Grundlagen (Wiederholung RT1) 2. Störgrößenaufschaltung 3. Störgrößennachbildung
MehrGrundbegriffe der Informatik
Grundbegriffe der Informatik Einheit 15: Reguläre Ausdrücke und rechtslineare Grammatiken Thomas Worsch Universität Karlsruhe, Fakultät für Informatik Wintersemester 2008/2009 1/25 Was kann man mit endlichen
MehrEinfaches, integriertes Projektmanagement mit Standard-Tools effizient planen und umsetzen
Einfaches, integriertes Projektmanagement mit Standard-Tools effizient planen und umsetzen von Dipl.-Ing. Christian Eichlehner Eines der Kernelemente zur erfolgreichen Projektabwicklung ist eine gute Strukturierung
MehrAchim Rosch, Institut für Theoretische Physik, Köln. Belegt das Gutachten wesentliche fachliche Fehler im KPK?
Impulsstrom Achim Rosch, Institut für Theoretische Physik, Köln zwei Fragen: Belegt das Gutachten wesentliche fachliche Fehler im KPK? Gibt es im Gutachten selbst wesentliche fachliche Fehler? andere wichtige
MehrThematische Abfrage mit Computerlinguistik
Thematische Abfrage mit Computerlinguistik Autor: Dr. Klaus Loth (ETH-Bibliothek Zürich) Zusammenfassung Der Beitrag befasst sich mit dem Einsatz der Computerlinguistik bei der thematischen Abfrage einer
Mehrwww.olr.ccli.com Jetzt neu: Online Reporting Schritt für Schritt durch das Online Reporting (OLR) Online Liedmeldung
Online Liedmeldung Jetzt neu: Online Reporting www.olr.ccli.com Schritt für Schritt durch das Online Reporting (OLR) Wichtige Information für Kirchen und Gemeinden Keine Software zu installieren Liedmeldung
MehrInformatik Kurs Simulation. Hilfe für den Consideo Modeler
Hilfe für den Consideo Modeler Consideo stellt Schulen den Modeler kostenlos zur Verfügung. Wenden Sie sich an: http://consideo-modeler.de/ Der Modeler ist ein Werkzeug, das nicht für schulische Zwecke
MehrAbschluss Version 1.0
Beschreibung Der Abschluss wird normalerweise nur einmal jährlich durchgeführt. Dieses Tech-Note soll helfen, diesen doch seltenen aber periodisch notwendigen Vorgang problemlos durchzuführen. Abschlussvarianten
MehrAnwendungsbeispiele Sign Live! Secure Mail Gateway
Anwendungsbeispiele Sign Live! Secure Mail Gateway Kritik, Kommentare & Korrekturen Wir sind ständig bemüht, unsere Dokumentation zu optimieren und Ihren Bedürfnissen anzupassen. Ihre Anregungen sind uns
MehrCTI SYSTEMS S.A. CTI SYSTEMS S.A. 12, op der Sang. Fax: +352/2685-3000 L- 9779 Lentzweiler. Email: cti@ctisystems.com G.D.
Z.I. Eselborn - Lentzweiler Phone: +352/2685-2000 12, op der Sang Fax: +352/2685-3000 L- 9779 Lentzweiler Email: cti@ctisystems.com G.D. Luxembourg URL: www.ctisystems.com Benutzung von Höhensicherungsgeräten
MehrNeuerungen der Ck-Schnittstelle in dms.net 1.9.8 Rev. 4895
Neuerungen der Ck-Schnittstelle in dms.net 1.9.8 Rev. 4895 Allgemeine Hinweise: Um die neuen Funktionen nutzen zu können, muss zunächst nur am dms.net-server ein Update auf Version 1.9.8 Rev. 4895 ausgeführt
MehrAffiliate Marketing Schnellstart Seite 1
Affiliate Marketing Schnellstart Seite 1 Inhaltsangabe Einführung...3 Gewinnbringende Nischen auswählen...4 Brainstorming...4 Mögliche Profitabilität prüfen...6 Stichwortsuche...7 Traffic und Marketing...9
MehrFolie 1: Fehlerbaumanalyse (FTA) Kurzbeschreibung und Ziel Die Fehlerbaumanalyse im Englischen als Fault Tree Analysis bezeichnet und mit FTA
Folie 1: Fehlerbaumanalyse (FTA) Kurzbeschreibung und Ziel Die Fehlerbaumanalyse im Englischen als Fault Tree Analysis bezeichnet und mit FTA abgekürzt dient der systematischen Untersuchung von Komponenten
MehrMCRServlet Table of contents
Table of contents 1 Das Zusammenspiel der Servlets mit dem MCRServlet... 2 1 Das Zusammenspiel der Servlets mit dem MCRServlet Als übergeordnetes Servlet mit einigen grundlegenden Funktionalitäten dient
Mehr