Framework for middleware executed on mobile devices

Die ubiquitäre Datenverarbeitung ist ein attraktives Forschungsgebiet des vergangenen und aktuellen Jahrzehnts. Es handelt von unaufdringlicher Unterstützung von Menschen in ihren alltäglichen Aufgaben durch Rechner. Diese Unterstützung wird durch die Allgegenwärtigkeit von Rechnern ermöglicht die sich spontan zu verteilten Kommunikationsnetzwerken zusammen finden, um Informationen auszutauschen und zu verarbeiten. Umgebende Intelligenz ist eine Anwendung der ubiquitären Datenverarbeitung und eine strategische Forschungsrichtung der Information Society Technology der Europäischen Union. Das Ziel der umbebenden Intelligenz ist komfortableres und sichereres Leben. Verteilte Kommunikationsnetzwerke für die ubiquitäre Datenverarbeitung charakterisieren sich durch Heterogenität der verwendeten Rechner. Diese reichen von Kleinstrechnern, eingebettet in Gegenstände des täglichen Gebrauchs, bis hin zu leistungsfähigen Großrechnern. Die Rechner verbinden sich spontan über kabellose Netzwerktechnologien wie wireless local area networks (WLAN), Bluetooth, oder UMTS. Die Heterogenität verkompliziert die Entwicklung und den Aufbau von verteilten Kommunikationsnetzwerken. Middleware ist eine Software Technologie um Komplexität durch Abstraktion zu einer homogenen Schicht zu reduzieren. Middleware bietet eine einheitliche Sicht auf die durch sie abstrahierten Ressourcen, Funktionalitäten, und Rechner. Verteilte Kommunikationsnetzwerke für die ubiquitäre Datenverarbeitung sind durch die spontane Verbindung von Rechnern gekennzeichnet. Klassische Middleware geht davon aus, dass Rechner dauerhaft miteinander in Kommunikationsbeziehungen stehen. Das Konzept der dienstorienterten Architektur ermöglicht die Entwicklung von Middleware die auch spontane Verbindungen zwischen Rechnern erlaubt. Die Funktionalität von Middleware ist dabei durch Dienste realisiert, die unabhängige Software-Einheiten darstellen. Das Wireless World Research Forum beschreibt Dienste die zukünftige Middleware beinhalten sollte. Diese Dienste werden von einer Ausführungsumgebung beherbergt. Jedoch gibt es noch keine Definitionen wie sich eine solche Ausführungsumgebung ausprägen und welchen Funktionsumfang sie haben muss. Diese Arbeit trägt zu Aspekten der Middleware-Entwicklung für verteilte Kommunikationsnetzwerke in der ubiquitären Datenverarbeitung bei. Der Schwerpunkt liegt auf Middleware und Grundlagentechnologien. Die Beiträge liegen als Konzepte und Ideen für die Entwicklung von Middleware vor. Sie decken die Bereiche Dienstfindung, Dienstaktualisierung, sowie Verträge zwischen Diensten ab. Sie sind in einem Rahmenwerk bereit gestellt, welches auf die Entwicklung von Middleware optimiert ist. Dieses Rahmenwerk, Framework for Applications in Mobile Environments (FAME²) genannt, beinhaltet Richtlinien, eine Definition einer Ausführungsumgebung, sowie Unterstützung für verschiedene Zugriffskontrollmechanismen um Middleware vor unerlaubter Benutzung zu schützen. Das Leistungsspektrum der Ausführungsumgebung von FAME² umfasst: • minimale Ressourcenbenutzung, um auch auf Rechnern mit wenigen Ressourcen, wie z.B. Mobiltelefone und Kleinstrechnern, nutzbar zu sein • Unterstützung für die Anpassung von Middleware durch Änderung der enthaltenen Dienste während die Middleware ausgeführt wird • eine offene Schnittstelle um praktisch jede existierende Lösung für das Finden von Diensten zu verwenden • und eine Möglichkeit der Aktualisierung von Diensten zu deren Laufzeit um damit Fehlerbereinigende, optimierende, und anpassende Wartungsarbeiten an Diensten durchführen zu können Eine begleitende Arbeit ist das Extensible Constraint Framework (ECF), welches Design by Contract (DbC) im Rahmen von FAME² nutzbar macht. DbC ist eine Technologie um Verträge zwischen Diensten zu formulieren und damit die Qualität von Software zu erhöhen. ECF erlaubt das aushandeln sowie die Optimierung von solchen Verträgen.

On the Benefits of Abstraction in Concurrent Haskell

Heutzutage haben selbst durchschnittliche Computersysteme mehrere unabhängige Recheneinheiten (Kerne). Wird ein rechenintensives Problem in mehrere Teilberechnungen unterteilt, können diese parallel und damit schneller verarbeitet werden. Obwohl die Entwicklung paralleler Programme mittels Abstraktionen vereinfacht werden kann, ist es selbst für Experten anspruchsvoll, effiziente und korrekte Programme zu schreiben. Während traditionelle Programmiersprachen auf einem eher geringen Abstraktionsniveau arbeiten, bieten funktionale Programmiersprachen wie z.B. Haskell, Möglichkeiten zur fortgeschrittenen Abstrahierung. Das Ziel der vorliegenden Dissertation war es, zu untersuchen, wie gut verschiedene Arten der Abstraktion das Programmieren mit Concurrent Haskell unterstützen. Concurrent Haskell ist eine Bibliothek für Haskell, die parallele Programmierung auf Systemen mit gemeinsamem Speicher ermöglicht. Im Mittelpunkt der Dissertation standen zwei Forschungsfragen. Erstens wurden verschiedene Synchronisierungsansätze verglichen, die sich in ihrem Abstraktionsgrad unterscheiden. Zweitens wurde untersucht, wie Abstraktionen verwendet werden können, um die Komplexität der Parallelisierung vor dem Entwickler zu verbergen. Bei dem Vergleich der Synchronisierungsansätze wurden Locks, Compare-and-Swap Operationen und Software Transactional Memory berücksichtigt. Die Ansätze wurden zunächst bezüglich ihrer Eignung für die Synchronisation einer Prioritätenwarteschlange auf Basis von Skiplists untersucht. Anschließend wurden verschiedene Varianten des Taskpool Entwurfsmusters implementiert (globale Taskpools sowie private Taskpools mit und ohne Taskdiebstahl). Zusätzlich wurde für das Entwurfsmuster eine Abstraktionsschicht entwickelt, welche eine einfache Formulierung von Taskpool-basierten Algorithmen erlaubt. Für die Untersuchung der Frage, ob Haskells Abstraktionsmethoden die Komplexität paralleler Programmierung verbergen können, wurden zunächst stencil-basierte Algorithmen betrachtet. Es wurde eine Bibliothek entwickelt, die eine deklarative Beschreibung von stencil-basierten Algorithmen sowie ihre parallele Ausführung erlaubt. Mit Hilfe dieses deklarativen Interfaces wurde die parallele Implementation vollständig vor dem Anwender verborgen. Anschließend wurde eine eingebettete domänenspezifische Sprache (EDSL) für Knoten-basierte Graphalgorithmen sowie eine entsprechende Ausführungsplattform entwickelt. Die Plattform erlaubt die automatische parallele Verarbeitung dieser Algorithmen. Verschiedene Beispiele zeigten, dass die EDSL eine knappe und dennoch verständliche Formulierung von Graphalgorithmen ermöglicht.

Context as a Service

In the vision of Mark Weiser on ubiquitous computing, computers are disappearing from the focus of the users and are seamlessly interacting with other computers and users in order to provide information and services. This shift of computers away from direct computer interaction requires another way of applications to interact without bothering the user. Context is the information which can be used to characterize the situation of persons, locations, or other objects relevant for the applications. Context-aware applications are capable of monitoring and exploiting knowledge about external operating conditions. These applications can adapt their behaviour based on the retrieved information and thus to replace (at least a certain amount) the missing user interactions. Context awareness can be assumed to be an important ingredient for applications in ubiquitous computing environments. However, context management in ubiquitous computing environments must reflect the specific characteristics of these environments, for example distribution, mobility, resource-constrained devices, and heterogeneity of context sources. Modern mobile devices are equipped with fast processors, sufficient memory, and with several sensors, like Global Positioning System (GPS) sensor, light sensor, or accelerometer. Since many applications in ubiquitous computing environments can exploit context information for enhancing their service to the user, these devices are highly useful for context-aware applications in ubiquitous computing environments. Additionally, context reasoners and external context providers can be incorporated. It is possible that several context sensors, reasoners and context providers offer the same type of information. However, the information providers can differ in quality levels (e.g. accuracy), representations (e.g. position represented in coordinates and as an address) of the offered information, and costs (like battery consumption) for providing the information. In order to simplify the development of context-aware applications, the developers should be able to transparently access context information without bothering with underlying context accessing techniques and distribution aspects. They should rather be able to express which kind of information they require, which quality criteria this information should fulfil, and how much the provision of this information should cost (not only monetary cost but also energy or performance usage). For this purpose, application developers as well as developers of context providers need a common language and vocabulary to specify which information they require respectively they provide. These descriptions respectively criteria have to be matched. For a matching of these descriptions, it is likely that a transformation of the provided information is needed to fulfil the criteria of the context-aware application. As it is possible that more than one provider fulfils the criteria, a selection process is required. In this process the system has to trade off the provided quality of context and required costs of the context provider against the quality of context requested by the context consumer. This selection allows to turn on context sources only if required. Explicitly selecting context services and thereby dynamically activating and deactivating the local context provider has the advantage that also the resource consumption is reduced as especially unused context sensors are deactivated. One promising solution is a middleware providing appropriate support in consideration of the principles of service-oriented computing like loose coupling, abstraction, reusability, or discoverability of context providers. This allows us to abstract context sensors, context reasoners and also external context providers as context services. In this thesis we present our solution consisting of a context model and ontology, a context offer and query language, a comprehensive matching and mediation process and a selection service. Especially the matching and mediation process and the selection service differ from the existing works. The matching and mediation process allows an autonomous establishment of mediation processes in order to transfer information from an offered representation into a requested representation. In difference to other approaches, the selection service selects not only a service for a service request, it rather selects a set of services in order to fulfil all requests which also facilitates the sharing of services. The approach is extensively reviewed regarding the different requirements and a set of demonstrators shows its usability in real-world scenarios.

Beiträge zur Modellierung technischer dynamischer Systeme

Die Nichtlineare Dynamik verallgemeinert Aussagen über dynamische Systeme durch Abstraktion von konkreten Systemen. In der Technik sind Maschinen dagegen sehr konkret und die Behandlung auftretender Probleme mit Methoden der theoretischen Physik ist nicht trivial. Diese Arbeit versucht einige der Schwierigkeiten einer technischen Anwendung der nichtlinearen Theorie zu lokalisieren. Am Beispiel von vier Klassen von Modellansätzen, werden Anwendungsschnittstellen beleuchtet und systematisiert. Die Anwendung von Modellen, die explizit auf bekannten physikalischen Gesetzmäßigkeiten aufbauen, findet Grenzen in der Anzahl der Freiheitsgrade und den Nebenbedingungen konkreter Systeme. Solche Modelle liefern jedoch wichtige Hinweise auf die Vielfalt der nichtlinearen Phänomene und tragen zu ihrem Verständnis bei. Daher sind sie für die Konstruktionspraxis wichtig. Es werden typisch nichtlineare Phänomene und ihre zugrundeliegenden Mechanismen vorgestellt und klassifiziert, sowie grundsätzliche Probleme der Berechenbarkeit analytisch formulierter Modelle betrachtet. Eine zweite Schnittstelle bieten die Darstellungen des Systemverhaltens als überlagerung spezieller Funktionen, diez.B. Symmetrieeigenschaften des betrachteten Systems besonders deutlich widerspiegeln. Gegenüber der klassischen Fourierzerlegung nach Frequenz und Phase bringt die Analyse nach Detaillierungsgrad und Position von Waveletfunktionen wichtige Vorteile für die nichtlineare zustandsraumbasierte Datenanalyse. Viele Verfahren der Nichtlinearen Datenanalyse beruhen auf metrischen Eigenschaften der dynamischen Systeme. Als dritte Gruppe werden demgegenüber topologische Methoden beleuchtet. Die Konstruktion von Simplexen aus Zeitreihen mittels der Zeitversatzmethode ist die Grundlage für eine Triangulation der Zustandsräume. Die Methoden, z.B. Templateverfahren, die auf der Einbettung von eindimensionalen Trajektorien in den R^3 basieren, lassen sich hingegen nicht einfach auf hochdimensionale Zustandsmannigfaltigkeiten anwenden. Schließlich werden stochastische Aspekte behandelt. Schwankungen des Systemverhaltens können auf Schwankungen der Anfangswerte und/oder auf Schwankungen der eigentlichen Systemdynamik beruhen. Die Einordnung des konkreten Anwendungsfalles setzt jedoch ein sicheres Verständnis stochastischer Prozesse voraus. Am Beispiel der Rekonstruktion der stochastischen Dynamik über eine eindimensionale Fokker-Planck-Gleichung zeigen sich deutlich die praktischen Grenzen solcher Ansätze.

Offenes Baukastensystem zur effizienten Dimensionierung von Materialflusssystemen

Die optimale Gestaltung logistischer Systeme und Prozesse bekommt eine immer größere Bedeutung für die Wirtschaftlichkeit und Wettbewerbsfähigkeit von Unternehmen. Für Einzelkomponenten von Materi-alflusssystemen sind neben exakten analytischen Verfahren auch Näherungslösungen und Ersatzmodelle in Form von Polynomen, neuronalen Netzen oder zeitdiskreten Verfahren vorhanden, mit denen eine gute Nachbildung des Verhaltens dieser Komponenten möglich ist. Ziel des Baukastensystems ist es, für diese Vielzahl von Methoden mit ihren spezifischen Ein- und Aus-gangsgrößen eine übergeordnete, einheitliche Kommunikations- und Datenschnittstelle zu definieren. In einem grafischen Editor kann ein Modell eines Materialflusssystems aus solchen Bausteinen gebildet und parametriert werden. Durch Verbindungen zwischen den Bausteinen werden Informationen ausge-tauscht. Die Berechnungen der Bausteine liefern Aussagen zu Auslastungen, Warteschlangen bzw. Warte-zeiten vor den Bausteinen sowie Flussgrößen zur Beschreibung der Abgangströme. The optimal arrangement of logistical systems and operations gets an increased importance for the economicalness and competitiveness of enterprises. For individual components of material flow systems there are also existing approximate solutions and substitute models besides exact analytical calculations in the form of polynomials, neural nets or time-discrete analysis which allows a good analytical description of the behaviour of these components. It is aim of the module system to define a superordinate and unified communication and data interface for all of these variety of methods with her specific input and output quantities. By using a graphic editor, the material flow system can be modelled of such components with specified functions and parameters. Connections between the components allows exchange of information. The calculations of the components provide statements concerning utilization, queue size or waiting time ahead of the components as well as parameters for the description of the departure process. Materialflusssysteme sind Träger innerbetrieblicher Transportprozesse und elementarer Bestandteil logistischer Systeme. Die optimale Gestaltung logistischer Systeme und Prozesse bekommt eine immer größere Bedeutung für die Wirtschaftlichkeit und Wettbewerbsfähigkeit von Unternehmen. Die effiziente Dimensionierung von Materialflusssystemen ist für Planer, Hersteller und Betreiber solcher Anlagen von grundsätzlicher Bedeutung. Für viele bei der Planung materialflusstechnischer Anlagen auftretende Fragestellungen steht noch immer kein Berechnungsverfahren oder -werkzeug zur Verfügung, welches allen drei folgenden Anforderungen gleicherma-ßen gerecht wird: Die Handhabung soll einfach, unkompliziert und schnell sein. Die Berechnungsergebnisse sollen eine hohe Genauigkeit haben. Die Berechnung soll allgemein gültige Ergebnisse liefern. Dabei handelt es sich um Fragestellungen, die durchaus grundlegender Natur sind. Beispielsweise nach den (statistisch) zu erwartenden minimalen und maximalen Auftragsdurchlaufzeiten, nach dem Einfluss von Belas-tungsschwankungen auf die Anlagenleistung, nach vorzusehenden Puffern (Stauplätze) und Leistungsreserven (Auslastung). Für die oben genannten Aufgaben der Materialflussplanung stehen heute hauptsächlich drei Verfahren zur Verfügung (Abb. 1): Faustformeln (gekennzeichnet mit f) sind einfach aber ungenau. Das Systemverhalten von Materialfluss-komponenten beschreiben sie selten über den gesamten Bereich möglicher Betriebsbedingungen und Konfi-gurationen. Das Verhalten von gesamten Materialflusssystemen ist zu komplex, als dass es mit Faustformeln adäquat beschreibbar wäre. Bedienungstheoretische Ansätze erlauben die Beschreibung von Materialflusskomponenten (kleines b) sehr genau und sehr umfassend, soweit Standardmethoden und -modelle der Bedienungstheorie anwendbar sind. Ist diese Voraussetzung nicht gegeben, kann der Aufwand zur Modellbildung schnell erheblich werden. Die Beschreibung von Materialflusssystemen (großes B) als Bedienungsnetzwerke ist nur unter (zum Teil stark) vereinfachenden Annahmen möglich. Solche Vereinfachungen gehen zu Lasten von Genauigkeit und All-gemeingültigkeit der Aussagen. Die Methoden sind häufig sehr komplex, ihre Anwendung erfordert vertief-te Kenntnisse in der Statistik und Stochastik. Simulationsuntersuchungen liefern für Materialflusskomponenten (kleines s) und für Materialflusssysteme (großes S) gleichermaßen genaue Aussagen. Der für die Untersuchungen erforderliche Aufwand hängt dabei weit weniger von den Eigenschaften und der Größe des Systems ab, als es bei bedienungstheoretischen An-sätzen der Fall ist. Die Aussagen der Simulation sind nie universell. Sie betreffen immer nur ein System in einer bestimmten Konfiguration. Die Anwendung der Simulation erfordert Spezialsoftware und vertiefte Kenntnisse in der Modellierung und Programmierung. Verfahren, die genaue und allgemein gültige Aussagen über das Verhalten komplexer Materialflusssysteme liefern können, sind insbesondere in der Phase der Angebotserstellung bzw. in der Phase der Grobplanung von besonderer Wichtigkeit. Andererseits sind heute verfügbare Verfahren aber zu kompliziert und damit unwirt-schaftlich. Gerade in der Phase der Systemgrobplanung werden häufig Änderungen in der Struktur des Systems notwendig, welche z.B. beim Einsatz der Simulation zu erheblichem Änderungsaufwand am Modell führt. Oftmals können solche Änderungen nicht schnell genug ausgeführt werden. Damit bleiben in der Praxis oft erhebliche Planungsunsicherheiten bestehen. Der Grundgedanke des Baukastensystems besteht in der Modularisierung von Materialflusssystemen in einzelne Bausteine und Berechnungen zum Verhalten dieser Komponenten. Die betrachteten Module sind Materialfluss-komponenten, die eine bestimmte logistische Funktion in einer konstruktiv bzw. steuerungstechnisch bedingten, definierten Weise ausführen. Das Verhalten einer Komponente wird durch Belastungen (Durchsatz) und techni-sche Parameter (Geschwindigkeit, Schaltzeit o.ä.) beeinflusst und kann durch ein adäquates mathematisches Modell quantifiziert werden. Das offene Baukastensystem soll dabei vor allem einen konzeptionellen Rahmen für die Integration derartiger Modellbausteine bilden. Es umfasst neben der Bausteinmodularisierung die Problematik der Kommunikation zwischen den Bausteinen (Schnittstellen) sowie Möglichkeiten zur Visualisierung von Ergebnissen. Das daraus abgeleitete softwaretechnische Konzept berücksichtigt neben der einheitlichen Integration der zum Teil stark unterschiedlichen Berechnungsverfahren für einzelne Materialflusskomponenten auch einheitliche Definitionen zur Beschreibung von benötigten Eingangsparametern einschließlich der Randbedingungen (Defini-tionsbereich) und Plausibilitätskontrollen sowie zur Ergebnisbereitstellung. Äußerst wichtig war die Zielstellung, das System offen und erweiterbar zu gestalten: Prototypisch wurden zwar einzelne vorliegende Bausteine integ-riert, es ist aber jederzeit möglich, weitere Verfahren in Form eines Bausteines zu implementieren und in das Baukastensystem einzubringen. Die Ergebnisse der Berechnungen für ein einzelnes Element (Output) fließen zugleich als Input in das nachfol-gende Element ein: Genau wie im realen Materialflusssystem durch Aneinanderreihung einzelner fördertechni-scher Elemente der Materialfluss realisiert wird, kommt es im Baukasten durch Verknüpfung der Bausteine zur Übertragung der relevanten Informationen, mit denen der Fluss beschrieben werden kann. Durch die Weitergabe der Ergebnisse kann trotz Modularisierung in einzelne Bausteine das Verhalten eines gesamten Materialflusssys-tems bestimmt werden. Daher sind auch hier einheitliche Festlegungen zu Art und Umfang der Übergabeparame-ter zwischen den Bausteinen erforderlich. Unter einem Baustein soll ein Modell einer Materialflusskomponente verstanden werden, welches das Verhalten dieser Komponente beim Vorliegen bestimmter Belastungen beschreibt. Dieses Verhalten ist insbesondere gekennzeichnet durch Warteschlangen und Wartezeiten, die vor der Komponente entstehen, durch Auslastung (Besetztanteil) der Komponente selbst und durch die Verteilung des zeitlichen Abstand (Variabilität) des die Komponente verlassenden Stroms an Transporteinheiten. Maßgeblich bestimmt wird dieses Verhalten durch Intensität und Variabilität des ankommenden Stroms an Transporteinheiten, durch die Arbeitsweise (z.B. stetig / unstetig, stochastisch / deterministisch) und zeitliche Inanspruchnahme der Komponente sowie durch Steuerungsregeln, mit denen die Reihenfolge (Priorisierung / Vorfahrt) und/oder Dauer der Abarbeitung (z.B. Regalbediengerät mit Strategie „Minimierung des Leerfahrtan-teils“) verändert werden. Im Grunde genommen beinhaltet ein Baustein damit ein mathematisches Modell, das einen oder mehrere an-kommende Ströme von Transporteinheiten in einen oder mehrere abgehende Ströme transformiert (Abb. 2). Derartige Modelle gibt es beispielsweise in Form von Bedienmodellen ([Gnedenko1984], [Fischer1990 u.a.]), zeitdiskreten Modellen ([Arnold2005], [Furmans1992]), künstlichen neuronalen Netzen ([Schulze2000], [Markwardt2003]), Polynomen ([Schulze1998]). Die zu Grunde liegenden Verfahren (analytisch, simulativ, numerisch) unterscheiden sich zwar erheblich, genü-gen aber prinzipiell den genannten Anforderungen. Die Fixierung auf ein mathematisches Modell ist aber nicht hinreichend, vielmehr bedarf es für einen Baustein auch definierter Schnittstellen, mit denen der Informationsaustausch erfolgen kann (Abb. 3). Dazu zählen neben der einheitlichen Bereitstellung von Informationen über die ankommenden und abgehenden Materialströme auch die Berücksichtigung einer individuellen Parametrierung der Bausteine sowie die Möglichkeit zur Interaktion mit dem Bediener (Anordnung, Parametrierung und Visualisierung). Das offene Konzept erlaubt das eigenständige Entwickeln und Aufnehmen neuer Bausteine in den Baukasten. Dazu ergibt sich als weitere Anforderung die einfache Konfigurierbarkeit eines Bausteins hinsichtlich Identifika-tion, Aussehen und Leistungsbeschreibung. An einen Baustein innerhalb des Baukastensystems werden weiter-hin die folgenden Anforderungen gestellt: Jeder Baustein ist eine in sich abgeschlossene Einheit und kann nur über die Ein- und Ausgänge mit seiner Umgebung kommunizieren. Damit ist ausgeschlossen, dass ein Baustein den Zustand eines ande-ren Bausteins beeinflussen kann. Das führt zu den beiden Lokalitätsbedingungen: Es gibt keine �����bergeordnete Steuerung, die in Abhängigkeit vom aktuellen Systemzustand dispositive Entscheidungen (z.B. zur Routenplanung) trifft. Blockierungen in Folge von Warteschlangen haben keine Auswirkungen auf die Funktion an-derer Bausteine. Bausteine beinhalten in sich abgeschlossene Verfahren zur Dimensionierung einer Komponente (Klas-se) des Materialflusssystems (z.B. Einschleusung auf einen Sorter, Drehtisch als Verzweigungselement oder als Eckumsetzer). Dabei werden auf Grund von technischen Parametern, Steuerungsstrategien und Belastungsannahmen (Durchsatz, Zeitverteilungen) Ergebnisse ermittelt. Ergebnisse im Sinne dieses Bausteinkonzepts sind Auslastungen, Warteschlangen bzw. Wartezeiten vor dem Baustein sowie Flussgrößen zur Beschreibung des Abgangstroms. Als Beschreibung eignen sich sowohl einzelne Kennwerte (Mittelwert, Varianz, Quantile) als auch statische Verteilungsfunktionen. Die Lokalitätsbedingungen stellen Einschränkungen in der Anwendbarkeit des Baukastensystems dar: Systeme mit übergeordneten Steuerungsebenen wie Routenplanung oder Leerfahrzeugsteuerung, die Entscheidungen auf Grund der vorhandenen Transportaufträge und des aktuellen Systemzustands treffen (Fahrerlose Transportsys-teme, Elektrohängebahn), können mit dem Baukasten nicht bearbeitet werden. Diese auf Unstetigförderern basierenden Systeme unterscheiden sich aber auch in ihren Einsatzmerkmalen grundlegend von den hier betrach-teten Stetigförderersystemen. Das Problem der Blockierungen vorgelagerter Bereiche durch zu große Warteschlangen kann dagegen bereits mit dem Baukasten betrachtet und zumindest visualisiert werden. Dazu ist den Verbindungen zwischen den Bausteinen eine Kapazität zugeordnet, so dass durch Vergleich mit den berechneten Warteschlangenlängen eine generelle Einschätzung zur Blockierungsgefahr möglich wird: Ist die Streckenkapazität kleiner als die mittlere Warteschlange, muss von einer permanenten Blockierung ausgegangen werden. In diesem Fall kann der vorhergehende Baustein seine gerade in Bearbeitung befindli-che Transporteinheit nach dem Ende der „Bedienung“ nicht sofort abgeben und behindert damit auch seine weiteren ankommenden Transporteinheiten. Für die Transporteinheiten bedeutet das eine Verlustzeit, die auch nicht wieder aufgeholt werden kann, für das gesamte Transportsystem ist von einer Leistungsminde-rung (geringerer Durchsatz, größere Transport- / Durchlaufzeit) auszugehen. Da bei der Berechnung der Bausteine von einer Blockierfreiheit ausgegangen wird, sind die Berechnungser-gebnisse in aller Regel falsch. Ist die Streckenkapazität zwar größer als die mittlere Warteschlange, aber kleiner als beispielsweise das 90%-Quantil der Warteschlange, ist mit teilweisen Blockierungen (in dem Fall mit mehr als 10% Wahr-scheinlichkeit) zu rechnen. Dann tritt der o.g. Effekt nur zeitweise auf. Die Ergebnisse der Berechungen sind dann zumindest für einzelne Bausteine ungenau. In beiden Fällen wird das Problem erkannt und dem Anwender signalisiert. Es wird davon ausgegangen, dass die geplante Funktionalität und Leistungsfähigkeit des Materialflusssystems nur dann gewährleistet ist, wenn keine Blockierungen auftreten. Durch Änderung der Parameter des kritischen Bausteins, aber auch durch Änderung der Materialströme muss daher eine Anpassung vorgenommen werden. Erst bei Vorliegen der Blockierfreiheit ist die Voraussetzung der Lokalität der Berechnungen erfüllt. Die Berechnungsverfahren in den Bausteinen selbst können wegen der Modularisierung (Lokalität) sehr unter-schiedlicher Art sein. Dabei ist es prinzipiell möglich, die einzelnen Ergebnisse eines Bausteins mit verschiede-nen Verfahren zu ermitteln, insbesondere dann, wenn auf Grund eines eingeschränkten Definitionsbereichs der Eingangsparameter die Anwendung eines bestimmten Verfahrens nicht zulässig ist. Bausteine, die einen Materialfluss auf Grund äußerer, nicht aus dem Verhalten des Bausteins resultierende Einflüsse generieren (Quelle) oder verändern (Service-Station), sind durch eine Flussgröße  parametriert. Die Flussgröße ist eine statistische Verteilungsfunktion zur Beschreibung der Ankunfts- und Abgangsströme (Zwi-schenankunftszeiten). In der Praxis, insbesondere in der Planungsphase, ist aber eine solche Verteilungsfunktion meist nicht bekannt. Zudem erweist sich das Rechnen mit Verteilungsfunktionen als numerisch aufwändig. Untersuchungen in [Markwardt2003] haben gezeigt, dass eine Parametrisierung als Abstraktion über statistische Verteilungsfunktionen mit gleichen Erwartungswerten, Minima und Streuungen ausreichend genaue Ergebnisse liefert. Daher wird die Flussgröße beschrieben durch die Parameter Ankunftsrate (=Durchsatz), Mindestzeitabstand tmind und Variationskoeffizient c (als Maß für die Variabilität des Stroms). Zur Visualisierung der Ergebnisse kann die dreiparametrige Gammaverteilung zu Grunde gelegt werden, die eine gute Anpassung an reale Prozessverläufe bietet und durch die genannten Parameter eindeutig beschrieben ist: Weitere leistungsbestimmende Größen wie technische Parameter, Zeitbedarfe u.ä. werden als Parametertupel (k) der jeweiligen Klasse zugeordnet. So ist z.B. bei einer Einschleusung auf einen Sorter zu garantieren, dass der Strom auf der Hauptstrecke nicht angehalten wird. Das erfordert bei einer Einschleusung von der Nebenstrecke eine Lücke im Gutstrom auf der Hauptstrecke mit der Länge Mindestabstand und Fördergeschwindigkeit sind Parameter der ankommenden Förderstrecken, demnach ist lediglich die Größe ttr als Transferzeit ein leistungsbestimmender Parameter der Einschleusung. Förderstrecken stellen die Verbindungen zwischen den Bausteinen her und realisieren den eigentlichen Material-fluss durch das System. Die technische Realisierung kann dabei prinzipiell durch verschiedenartige Bauformen von Stetig- und Unstetigförderern erfolgen. Systeme, die aber vollständig auf der Basis von Unstetigförderern arbeiten wie fahrerlose Transportsysteme (FTS) oder Elektrohängebahn (EHB), werden im Rahmen des Baukas-tens nicht betrachtet, weil die Lokalitätsbedingungen nicht gelten und beispielsweise eine übergeordnete Sys-temsteuerung (Fahrzeugdisposition, Leerfahrtoptimierung) einen erheblichen Einfluss auf die Leistungsfähigkeit des Gesamtsystems hat. Förderstrecken im hier verwendeten Sinne sind Rollen-, Ketten-, Bandförderer oder ähnliches, deren maximaler Durchsatz im Wesentlichen durch zwei Parameter bestimmt wird: Fördergeschwindigkeit (vF) und Mindestab-stand zwischen den Transporteinheiten (smind). Der Mindestabstand ergibt sich aus der Länge der Transportein-heit in Transportrichtung (sx) und einem Sicherheitsabstand (s0), der für ein sicheres und gefahrloses Transportie-ren erforderlich ist. Die Mindestzeit tmind,S zwischen zwei Fördereinheiten auf einer Förderstrecke bestimmt sich demnach zu Ist das verbindende Förderelement nicht staufähig (nicht akkumulierend, z.B. Gurtbandförderer), so kann sich der Abstand zwischen den Fördergütern während des Förder- oder Transportvorgangs nicht verändern: Muss das Band angehalten werden, weil eine Abgabe an das nachfolgende Förderelement nicht möglich ist, bleiben alle Einheiten stehen. In diesem Fall ist es also nicht möglich, die Lücken im Transportstrom zu schließen, die bereits bei der Aufgabe auf das Förderelement entstehen. Für die Berechnung der Mindestzeit tmind,S bedeutet das, dass dann auch die Mindestzeit tmind,B des vorhergehenden Bausteins berücksichtigt werden muss. Die Mindestzeit des Streckenelements nach (6) bzw. (7) wird als einer der Parameter der Flussgröße zur Be-schreibung des am nachfolgenden Baustein ankommenden Stroms verwendet. Als Parameter der Förderstrecke werden neben der Fördergeschwindigkeit daher auch Angaben zum Transportgut (Abmessungen, Sicherheitsab-stand, Transportrichtung) benötigt. Es bot sich ferner an, eine Typisierung der Förderstrecken hinsichtlich ihrer technischen Realisierung (Rollenförderer, Kettenförderer, Bandförderer usw. mit zugeordneten Parametern) vorzunehmen, um den Aufwand für die Beschreibung der Förderstrecken gering zu halten. Weitere Parameter der Förderstrecken dienen der Aufnahme der Berechnungsergebnisse von vor- bzw. nachge-lagerten Bausteinen und beinhalten: die Länge der Warteschlange (einzelne Kenngrößen wie Mittelwert, 90%-, 95% bzw. 99%-Quantil oder - falls ermittelbar - als statistische Verteilung) die Wartezeit (ebenfalls Kenngrößen oder statistische Verteilung) die (Strecken-)Auslastung Variationskoeffizient für den Güterstrom Für die Darstellung des Materialflusses in einem System werden jeweils einzelne Materialfluss-Relationen betrachtet. Dabei wird angenommen, dass jede Relation an einer Quelle beginnt, an einer Senke endet, dabei mehrere Materialfluss-Komponenten (Bausteine) durchläuft und über den gesamten Verlauf in seiner Größe (Transportmenge) konstant bleibt. Einziger leistungsbestimmender Parameter einer Materialfluss-Relation ist die Transportmenge. Sie wird als zeitabhängige Größe angegeben und entspricht damit dem Durchsatz. Mindestabstand und Variationskoeffizient werden vom erzeugenden Baustein (Quelle) bestimmt, von den weiteren durchlaufenen Bausteinen verändert und über die Förderstrecken jeweils an den nachfolgenden Baustein übertragen. Die verbindenden Förderstrecken werden mit dem jeweiligen Durchsatz „belastet“. Bei Verbindungen, die von mehreren Relationen benutzt werden, summieren sich die Durchsätze, so dass sich unterschiedliche Strecken- und Bausteinbelastungen ergeben. Im Kontext des Baukastensystems werden Metadaten1 verwendet, um die in einem Baustein enthaltenen Infor-mationen über Anwendung, Verfahren und Restriktionen transparent zu machen. Ziel des Baukastensystems ist es je gerade, einfache und leicht handhabbare Berechnungsmodule für einen breiteren Anwenderkreis zur Verfü-gung zu stellen. Dazu sind Beschreibungen erforderlich, mit denen das Leistungsspektrum, mögliche Ergebnisse und Anwendungs- bzw. Einsatzkriterien dokumentiert werden. Aufgabe der Baustein-Bibliothek ist die Sammlung, Verwaltung und Bereitstellung von Informationen über die vorhandenen Bausteine. Damit soll dem Nutzer die Möglichkeit gegeben werden, für seine konkret benötigte Materialflusskomponente einen geeigneten Baustein zur Abbildung zu finden. Mit der Entwicklung weiterer Bausteine für ähnliche Funktionen, aber unterschiedliche Realisierungen (z. B. Regalbediengerät: einfach- oder doppeltiefe Lagerung, mit oder ohne Schnellläuferzone usw.) wächst die Notwendigkeit, die Einsatz- und Leis-tungsmerkmale des Bausteins in geeigneter Weise zu präsentieren. Die Baustein-Bibliothek enthält demnach eine formalisierte Beschreibung der vorhandenen und verfügbaren Bausteine. Die Informationen sind im Wesentlichen unter dem Aspekt einer einheitlichen Identifikation, Infor-mation, Visualisierung und Implementierung der unterschiedlichen Bausteine zusammengestellt worden. Einige der in der Baustein-Bibliothek enthaltenen Metadaten lassen sich durchaus mehreren Rubriken zuordnen. Identifikation und Information Ein Baustein wird durch eine eindeutige Ident-Nummer fixiert. Daneben geben Informationen zum Autor (Ent-wicklung und/oder Implementierung des Verfahrens) und eine Funktionsbeschreibung eine verbale Auskunft über den Baustein. Zusätzlich ist jeder Baustein einem bestimmten Typ zugeordnet entsprechend der Baustein-Klassifizierung (Bearbeiten, Verzweigen, Zusammenführen usw.), über den die Baustein-Auswahl eingegrenzt werden kann. Visualisierung Die Parameter für die Visualisierung beschreiben die Darstellung des Bausteins innerhalb des Baukastensystems (Form, Farbe, Lage der Ein- und Ausgänge des Bausteins, Icons). Implementierung Der Klassenname verweist auf die Implementierung des Bausteins. Zusätzlich benötigte Programm-Ressourcen (externe Bibliotheken wie *.dll , *.tcl o.ä.) können angegeben werden. Weiterhin sind Bezeichnungen und Erläuterungen der erforderlichen technischen Parameter für den Eingabedialog enthalten. Für die Förderstrecken wird ebenfalls eine formalisierte Beschreibung verwendet. Sie verweist jedoch nicht wie die Baustein-Bibliothek auf Software-Ressourcen, sondern enthält nur eine Reihe technischer Parameter, die für das Übertragungsverhalten der Förderstrecke eine Rolle spielen (Fördergeschwindigkeit, Arbeitsweise akkumu-lierend, Ausrichtung des Transportguts). Die Einträge lassen sich als Musterdatensätze (Template) für die Bau-stein-Verbindungen auffassen, um bestimmte, häufig vorkommende fördertechnische Lösungen diesen Verbin-dungen in einfacher Weise zuordnen zu können. Die Angaben sind aber im konkreten Anwendungsfall änderbar. Angaben zum Transportgut beschränken sich auf die Abmessungen der Transporteinheiten (Länge, Breite) und den erforderlichen Sicherheitsabstand (s0). Als Grundform wird von einer Standard-Euro-Palette (1200x800 mm) ausgegangen, es lassen sich aber auch Güter mit anderen Maßen hinzufügen. Die Angaben zum Transportgut werden in Verbindung mit den Parametern der Förderstrecken (Ausrichtung des Gutes längs oder quer) ausgewertet, so dass sich die jeweiligen Mindestabstände (Gleichung 6 bzw. 7) sowie der maximale Durchsatz Qmax als Grundlage für die Berechnung der Streckenauslastung bestimmen lassen. Das Gesamtkonzept des Baukastensystems ist in Abbildung 4 dargestellt. Es besteht im Wesentlichen aus drei Bereichen: Bausteinerstellung Bausteinverwaltung (Bibliotheken) Baukasten (Benutzeroberfläche) Dabei ist der Bereich der Bausteinerstellung nicht unmittelbarer Bestandteil der realisierten Lösung. Sie ist vielmehr die Quelle für die Bausteine, die über die jeweiligen Metadaten in einer Baustein-Bibliothek verwaltet und bereitgestellt werden. Die Verwaltung von Bausteinen und Förderstrecken ist die Umsetzung der Baustein-Bibliothek und (im erwei-terten Sinne) der Definitionen für die Förderstrecken. Der Modellbaukasten selbst stellt die Grafische Nutzeroberfläche dar (Abb. 11) und enthält den interaktiven, grafischen Modelleditor, die Auswahlelemente (Werkzeugkoffer bzw. -filter) für Bausteine und Förderstrecken, tabellarische Übersichten für alle Bausteine, Förderstrecken und Materialflussrelationen sowie Eingabedialoge für Bausteine, Förderstrecken und Materialflussrelationen. Die Entwicklung eines Modells mit dem Baukastensystem erfolgt prinzipiell in drei Schritten: Schritt eins umfasst die Anordnung und Definition der Bausteine. Der Modellbaukasten bietet die Möglich-keit, einen bestimmten Baustein direkt (z.B. Ausschleusung) oder unter Nutzung eines Bausteinfilters (z.B. alle Verzweigungselemente) auszuwählen und im grafischen Editor mittels Mausklick zu platzieren . An-schließend erfolgt im Dialog die notwendige Parametrierung des Bausteins. Dies beinhaltet sowohl die An-gaben zur Visualisierung (Drehung, Spiegelung) als auch die für die Dimensionierung erforderlichen techni-schen Parameter. Die für jeden Baustein benötigten Leistungsanforderungen (Durchsatz, lokale Transport-matrix) werden allerdings nicht direkt angegeben, sondern aus den Beziehungen zu den vor- und nachgela-gerten Bausteinen automatisch ermittelt (Übertragungsfunktion der Förderstrecken). Danach erfolgt in einem zweiten Schritt die Definition von Verbindung zwischen den Bausteinen (Förder-strecken): Das Erzeugen der Bausteinverbindungen ist ebenfalls ganz einfach zu realisieren. Nach Auswahl der zu Grunde liegenden Fördertechnik (z.B. Rollenförderer) wird durch Ziehen des Mauszeigers von einem nicht belegten Ausgang zu einem nicht belegten Eingang eines Bausteins die entsprechende Förderstrecke erzeugt. In einem abschließenden Dialog können die gewählten Voreinstellungen zum Transportgut, zum Förderertyp usw. bestätigt oder gegebenenfalls korrigiert werden. Außerdem kann die Kapazität der Förder-strecke definiert werden. Dabei geht es weniger um die Länge des Förderers als viel mehr um die Anzahl der vorgesehenen Puffer- oder Stauplätze im Zusammenhang mit den zu berechnenden Warteschlangenlän-gen. Abschließend wird im dritten Schritt der Materialfluss definiert: Ein Materialstrom ist jeweils eine Relation, die an einer Quelle beginnt, an einer Senke endet und dabei mehrere Bausteine durchläuft. Da die Förder-strecken zu diesem Zeitpunkt bereits definiert sein müssen, kann automatisch ein möglicher Weg zwischen Quelle und Senke gefunden werden. Ähnlich wie bei Routenplanungssystemen kann dabei durch zusätzliche Angabe von Zwischenpunkten (via) der automatisch vorgeschlagene Transportweg verändert und angepasst werden (Abb. 5). Nach Bestätigung des Transportweges und damit der unterwegs zu passierenden Bausteine erfolgt in einem Dialog die Parametrierung (Transportmenge pro Stunde) für diese Relation. Die Elemente des Transportweges (die benutzten Förderstrecken) werden mit dem entsprechenden Durchsatz „belastet“. Nach Abschluss der Modellierung kann die Berechnung ausgeführt werden. Im Ergebnis werden Kennzahlen bestimmt und im Baukasten in verschiedener Form visualisiert, um eine Bewertung der Ergebnisse vornehmen zu können. Eine Übersicht Fehlermeldungen listet die Problemelemente auf. Dabei wird die Schwere eines Problems farb-lich hervorgehoben: fataler Fehler (rot): entsteht z.B. bei Überlastung eines Bausteins – die geforderte Leistung für einen Bau-stein (und damit die des Gesamtsystems) kann nicht erbracht werden. lokaler Fehler (orange): entsteht z.B. bei permanenter Blockierung – die mittlere Warteschlange vor einem Baustein ist größer als dessen vorgesehene Kapazität. Warnung (hellgelb): bei teilweiser Blockierung – das 90%-Quantil der Warteschlange ist größer als die Ka-pazität der Förderstrecke, es ist daher zeitweise mit Blockierungen (und damit Behinderungen des vorherge-henden Bausteins) zu rechnen. Information (weiß): wird immer dann erzeugt, wenn Erwartungswerte für die Wartezeit oder Warteschlange mit einem G/G/1-Bedienmodell berechnet werden. Die Lösungen dieser Näherungsgleichungen sind im All-gemeinen nicht sehr genau, dienen aber als Abschätzung für die sonst fehlenden Kennwerte. Entsprechend der berechneten Auslastung werden die Bausteine im Modelleditor mit einer Farbabstufung von Grün nach Rot markiert, Bausteine und Förderstrecken leuchten rot bei Überlastung. Die dargestellten Ergebnisse im Modelleditor zu Bausteinen und Förderstrecken sind umschaltbar durch den Nutzer (Abb. 6). Je nach den in den Bausteinen hinterlegten Berechnungen sind jedoch nicht immer alle Kenn-größen verfügbar. Die Implementierung des Baukastensystems wurde mit Java (Release 1.5) vorgenommen. Für das Kernsystem wird dabei das in Abbildung 7 dargestellte Klassen-Konzept umgesetzt. Ausgehend von einer allgemeinen Klasse (Object3D) für Visualisierung von und Interaktionen mit grafischen Objekten wurden für Bausteine (AbstractNode) und Förderstrecken (Connection) die jeweiligen Klassen abgelei-tet. Für die Förderstecken ergibt sich dabei eine weitgehend einheitliche Beschreibungsform, die lediglich durch die Parametrierung (Vorlagen in der Förderstrecken-Bibliothek als XML-Datei) auf den konkreten Einsatz im Modell des Materialflusssystems angepasst werden muss. Anders verhält es sich mit den Bausteinen: Durch die mögliche Vielfalt von Bausteinen und den ihnen zu Grunde liegenden Berechnungsverfahren muss es auch eine Vielzahl von Klassen geben. Um jedoch für jeden belie-bigen Baustein den Zugriff (Bereitstellung von Eingangsdaten, Berechnung und Bereitstellung der Ergebnisse) in einer identischen Weise zu gewährleisten, muss es dafür eine nach außen einheitliche Schnittstelle geben. Die Java zu Grunde liegende objektorientierte Programmierung bietet mit dem Konzept der „abstrakten Klasse“ eine Möglichkeit, dies in einfacher Weise zu realisieren. Dazu wird mit AbstractNode quasi eine Vorlage entwi-ckelt, von der alle implementierten Baustein-Klassen abgeleitet sind. AbstractNode selbst enthält alle Methoden, mit denen Baustein-Daten übernommen oder übergeben, die jeweiligen Visualisierungen vorgenommen, die baustein-internen Verbindungen (lokale Transportmatrix) verwaltet und Ein- und Ausgänge mit den zugehörigen Förderstrecken verbunden werden. Die für den Aufruf der eigentlichen Berechnungen in den Bausteinen ver-wendeten Methoden sind deklariert, aber nicht implementiert (sogenannte abstrakte Methoden). Ein Baustein wird von AbstractNode abgeleitet und erbt damit die implementierten Methoden, lediglich die abstrakten Methoden, die die Spezifik des Bausteins ausmachen, sind noch zu implementieren. Um neue Bausteine zu erzeugen, wird Unterstützung in Form eines Bildschirmdialogs angeboten (Abb. 8). Danach sind die entsprechenden Angaben zu den Metadaten, zur Struktur und zur Visualisierung des Bausteins, die Eingangsparameter (Name und Erläuterung) sowie die berechenbaren Ergebnisse (z.B. Auslastung, Quantile der Warteschlangenlänge, aber keine Aussage zu Wartezeiten usw.) anzugeben. Nach Bestätigung der Daten und diversen Syntax- bzw. Semantik-Kontrollen wird der Baustein in der Bibliothek registriert, ein Sourcecode für den neuen Baustein generiert und kompiliert. Der Baustein selbst ist damit formal korrekt und kann sofort verwendet werden, liefert aber noch keine verwertbaren Ergebnisse, weil natürlich die Implementierung des Berechnungsverfahrens selbst noch aussteht. Das muss in einem zweiten Schritt im Rah-men der üblichen Software-Entwicklung nachgeholt werden. Dazu sind die Berechnungsverfahren zu implemen-tieren und die Bausteinschnittstellen zu bedienen. Der generierte Java-Code enthält in den Kommentaren eine Reihe von Hinweisen für den Programmierer, so dass sich problemlos die Schnittstellen des Bausteins program-mieren lassen (Abb. 9). In einem Beispiel werden ein Hochregallager (3 Regalbediengeräte) und zwei Kommissionierplätze durch ein Transportsystem verbunden. Mit der Einlastung von Kommissionieraufträgen werden im Simulationsmodell die entsprechenden Transportaufträge generiert und abgearbeitet (Abb. 10). Dabei können Systemzustände (z.B. Warteschlangen) protokolliert und statistisch ausgewertet werden. Ein entsprechendes Modell für den Baukasten ist in Abbildung 11 dargestellt. Der Vorteil des Baukastensystems liegt selbst bei diesem recht einfachen Beispiel im Zeitvorteil: Für Erstellung und Test des Simulationsmodells und anschließende Simulationsläufe und Auswertungen wird ein Zeitaufwand von ca. 4-5 Stunden benötigt, das Baukastenmodell braucht für Erstellung und korrekte Parametrierung weniger als 0,5 Stunden, die Rechenzeit selbst ist vernachlässigbar gering. Sollte im Ergebnis der Untersuchungen eine Änderung des Materialflusssystems notwendig werden, so führt das im Simulationsmodell teilweise zu erheblichen Änderungen (Abläufe, Steuerungsstrategien, Auswertungen) mit entsprechendem Zeitaufwand. Im Baukasten können dagegen in einfacher Weise zusätzliche Bausteine eingefügt oder vorhandene ersetzt werden durch Bausteine mit geänderter Funktion oder Steuerung. Strukturelle Änderungen am Materialflusssys-tem sind also mit deutlich geringerem Aufwand realisierbar. In [Markwardt2003] werden für mehrere Strukturen von Materialflusskomponenten Fehlerbetrachtungen über die Genauigkeit der mittels neuronaler Netze untersuchten Systeme gegenüber den Simulationsergebnissen vorge-nommen. Danach ergibt sich beispielsweise für das 90%-Quantil der Warteschlange eine Abweichung, die mit 90% Sicherheit kleiner als 0,3 Warteplätze ist. Bei den Variationskoeffizienten des Abgangsstroms betragen die absoluten Abweichungen mit 90% Sicherheit nicht mehr als 0,02 bis 0,05 (in Abhängigkeit vom betrachteten Baustein). Daraus wird die Schlussfolgerung abgeleitet, dass die durch Verknüpfung neuronaler Netze gewonne-nen Aussagen sehr gut mit statistischen Ergebnissen diskreter Simulation übereinstimmen und eine Planungssi-cherheit ermöglichen, die für einen Grobentwurf von Materialflusssystemen weit über die heute gebräuchlichen statischen Berechnungsverfahren hinausgehen. Im konkreten Beispiel wurde die Zahl der Pufferplätze vor den Kommissionierern (Work1 bzw. Work2) zu-nächst auf 3 begrenzt. Die Berechnung im Baukasten ergab dabei in beiden Fällen Fehlermeldungen mit dem Hinweis auf Blockierungen (Abb. 12, links). Diese bestätigten sich auch im Simulationsmodell (Abb. 12, rechts). Nach Vergr��ßerung der Pufferstrecken auf 7 Plätze ist die Blockierungsgefahr auf ein vertretbares Minimum reduziert, und die mit dem Baukasten berechneten Kenngrößen können durch die Simulation prinzipiell bestätigt werden. it dem offenen Baukastensystem ist eine schnelle, einfache, sichere und damit wirtschaftlichere Dimensionie-rung von Materialflusssystemen möglich. Für den Anwender sind sofort statistisch abgesicherte und ausreichend genaue Ergebnisse ohne aufwändige Berechnungen verfügbar, womit sich die Planungsqualität erhöht. Besonde-re Anforderungen an Hard- und Software sind dabei nicht erforderlich. Für die Dimensionierung der einzelnen Bausteine stehen Informationen aus der Bedienungstheorie, Simulati-onswissen und numerische Verfahren direkt und anwendungsbereit zur Verfügung. Es erlaubt eine deutlich vereinfachte Berechnung von statistischen Kenngrößen wie Quantile (statistische Obergrenzen) der Pufferbelegung, Auslastung von Einzelelementen und mittlere Auftragsdurchlaufzeit bei gleichzeitig erhöhter Genauigkeit. Ferner ist das Baukastensystem offen für eine Erweiterung um neue Bausteine, die neue oder spezielle fördertechnische Elemente abbilden oder zusätzliche Informationen liefern können. Da auch komplexe Materialflusssysteme immer wieder aus einer begrenzten Anzahl unterschiedlicher Kompo-nenten bestehen, können durch die Verknüpfung der Einzelbausteine auch Gesamtsysteme abgebildet werden. Die Verknüpfung der Bausteine über eine einheitliche Schnittstelle erlaubt Aussagen über das Verhalten der Gesamtanlage. Bei Einsatz des Baukastensystems sind in einer solchen Verknüpfung jederzeit Parameterände-rungen möglich, deren Folgen sofort sichtbar werden. Die Zeit bis zum Vorliegen gesicherter, ausreichend genauer Ergebnisse wird dadurch drastisch verkürzt. Damit erwächst Variantenuntersuchungen bereits in frühen Planungsphasen neues Potential und kann zum entscheidenden Wettbewerbsvorteil werden.

Erfahrbares Programmieren durch den zielgerichten Einsatz von Flugdrohnen im Informatikunterricht

Informatik- und insbesondere Programmierunterricht sind heute ein wichtiger Bestandteil der schulischen Ausbildung. Vereinfachte Entwicklungsumgebungen, die auf die Abstraktion typischer Programmierkonzepte in Form von grafischen Bausteinen setzen, unterstützen diesen Trend. Zusätzliche Attraktivität wird durch die Verwendung exotischer Laufzeitumgebungen (z. B. Roboter) geschaffen. Die in diesem Paper vorgestellte Plattform “ScratchDrone” führt ergänzend zu diesen Angeboten eine moderne Flugdrohne als innovative Laufzeitumgebung für Scratch-Programme ein. Die Programmierung kann dabei dank modularer Systemarchitektur auf verschiedenen Abstraktionsebenen erfolgen, abhängig vom Lernfortschritt der Schüler. Kombiniert mit einem mehrstufigen didaktischen Modell, der Herausforderung der Bewegung im 3D-Raum sowie der natürlichen menschlichen Faszination für das Fliegen wird so eine hohe Lernmotivation bei jungen Programmieranfängern erreicht.

Abstrahierendes Lernen durch aktive Modellbildung: Evaluation eines Prozesses und einer Lernumgebung

Die Fähigkeit zum Lernen durch Abstraktion aus Erfahrungen unterscheidet Experten von Novizen. Wir stellen einen Prozess für individuelles abstrahierendes Lernen und eine diesen Prozess unterstützende Lernumgebung vor. Die Ergebnisse einer Pilotstudie zeigen, dass Lernende unter Nutzung der Lernumgebung aus Fallbeispielen ein abstraktes Modell erstellen und über ihren Prozess reflektieren konnten. Dies fiel ihnen leichter, wenn die Fallbeispiele wenige gemeinsame Oberflächenmerkmale aufwiesen. Im Gegensatz zum intendierten Lernprozess wandten manche Lernende einen anderen Prozess an.

Einfügen als Kulturtechnik

Der Architekt und Pritzker-Preisträger von 2012 Wang Shu und seine Frau Lu Wenyu setzen traditionelle chinesische Baukultur neu um. Das kommt insbesondere im Fügen alter und neuer Materialien nach tradierten Handwerksregeln zum Ausdruck. Das theoretische wie praktische Interesse am lokalen Handwerk führen sie unter anderem auf die Beschäftigung mit den chinesischen Literati zurück. Auf diese Weise widersetzen sie sich der heute vorherrschenden Ökonomie im chinesischen Baugewerbe. Sie aktualisieren nicht nur das traditionelle chinesische Handwerk, sondern setzen sich auch für eine Nachhaltigkeit ein, in welcher die zeitliche Entwicklung im Zusammenhang mit bestimmten Erfahrungsräumen gesehen wird. Mittels Improvisationen und Handwerk lassen Wang Shu und Lu Wenyu die alten kulturellen Traditionen mit spezifischen Ästhetiken in einem neuen Licht einer anderen gegenwärtigen Moderne wieder aufscheinen.

Weltbilder und die Ästhetik der Geographie. Die Offizin Blaeu und die niederländische Kartographie der Frühen Neuzeit

Als kulturelle Konstrukte aus Bild, Schrift und Zahl stellten Land- und Weltkarten der Frühen Neuzeit komplexe Repräsentationen der Realität und Ausdrucksformen des abstrakten Denkens dar, die stets in ihrer Wirkungsmacht auf die graphische Wiedergabe angewiesen waren. Das konzeptuelle Ineinandergreifen von kartographischer Abstraktion und künstlerischer Figuration war eine insbesondere den niederländischen Karten des 16. und 17. Jahrhunderts eigene Form einer universellen »descriptio orbis«. Aufgrund dieser visuellen Interaktion unterschiedlicher Arten der Beschreibung waren die Topographien nicht nur weltabbildend, sondern vielmehr welterzeugend, indem sie zu Trägern, Vermittlern und Gegenständen zeitgebundener Wissensdiskurse wurden. Dieses Phänomen einer Ästhetik der Geographie, wie sie in den Werken der Amsterdamer Offizin Blaeu und ihres Umkreises zu beobachten ist, bildet erstmalig den Gegenstand einer kunsthistorischen Studie.

Laborativt arbete med konkret material inom matematikämnet : En empirisk studie med lågstadiets matematikundervisning i blickfånget

Matematiken är en abstrakt vetenskap. Laborativt arbete med konkret material sägs kunna överbrygga glappet mellan abstrakt och konkret. Denna kvalitativa studie syftar utforska vilka möjligheter och begränsningar lågstadielärare erfar kring konkret material. Resultatet visar att en vanlig uppfattning bland lågstadielärare är att konkret material besitter den positiva egenskapen att stötta elever i alla åldrar och nivåer i arbetet med att utveckla matematisk förståelse. Detta genom att konstruera inre bilder av matematiken hos eleverna, vilka sedan kan stötta eleverna på vägen mot matematisk abstraktion och generalisering. Arbetssättet tycks också kunna väcka intresse, nyfikenhet och lust att lära matematik samt bjuda in till rikare möjligheter till kommunikation jämfört med läroboksfokuserad undervisning. Dock har valet av konkret material betydelse. Negativa faktorer som uppmärksammats är att leklust riskerar ta fokus från matematiken samt att duktiga elever särskiljer laborativ matematik med konkret material från "riktig" matematik i läroboken. Dokumentationen av arbetet kring det konkreta materialet är dessutom tidskrävande. En slutsats som dras är att laborativt arbete med konkret material inte ensamt kan stå som bas för elevers matematiska utveckling. Däremot kan arbetssättet kombineras med lärobokens färdighetsträning och matematikdiskussioner och tillsammans bidra till fördjupad förståelse genom att eleverna i ett varierat arbetssätt tillåts möta matematikens olika uttrycksformer.