Aufgabenstellung

Problem 1

Nahezu alle Geräte werden über proprietäre, zum Teil sehr hardwarenah ablaufende Kommandosequenzen gesteuert. Dadurch erzeugt die Anbindung jedes Mal einen zusätzlichen Entwicklungsaufwand, der nicht akzeptabel ist und die Kosten nach oben treibt. Aufgrund der Vielfalt der Anbieter ist in der heutigen Situation die einmal erstellte und angepasste Software (z.B. eine Lagerverwaltung) untrennbar mit der ursprünglich erworbenen Hardware verbunden. Damit kann ein Kunde die Hardware weder austauschen noch Geräte anderer Hersteller in seine Applikation integrieren, ohne die Erstellung der Software teilweise noch einmal zu bezahlen.

Hersteller der Auto-ID -Systeme sind wenig veranlasst, an dieser Situation etwas zu ändern. Ein einmal gewonnener Kunde ist in der aktuellen Marktlage ein Stammkunde, da der Total Cost of Change nach Inbetriebnahme sehr hoch ist. Die Anwendungsentwickler investieren in die primären Funktionen ihrer Software (Frontend) und haben sich in der Regel auf einen Hardware-Anbieter spezialisiert, da ihnen die Marktmacht fehlt, um Standards durchzusetzen. Zusatzkosten, die durch Integration neuer Komponenten entstehen, werden auf den Kunden abgewälzt (Customizing).

Problem 2

So leistungsfähig die heute erhältlichen Datenerfassungsgeräte auch sind, aus logistischer Sicht liefern sie unvollständige und unstrukturierte Daten. Nicht einmal die notwendigsten Informationen (logistischer Transaktionsdatensatz) können den gelieferten Daten direkt entnommen werden. Die identifizierten Daten (oftmals Zahlenkolonnen) sind für reine Steuerungszwecke ausreichend. Auf Anwendungsebene sind aber gerade für das Logistik-Monitoring weitere Informationen unbedingt notwendig. Bei Analysen von Logistiksystemen werden darüber hinaus nicht nur aktuelle, sondern auch historische Werte interessant.

Die Anwendungssoftware ist nicht in der Lage, alle gewünschten Daten und Informationen zu rekonstruieren, zumal dies bei zeitkritischen Daten im Nachhinein auch nicht mehr möglich ist. Hinzu kommen Probleme bei der Analyse der Daten, da das Format von Gerät zu Gerät verschieden ist, was eine automatische Speicherung, Verarbeitung und Auswertung erschwert.

Problem 3

Oft ist es in Materialflusssystemen und in der Produktion erforderlich, verschiedene Sensoren miteinander zu verknüpfen, die eine gemeinsame Station bilden. Es entsteht ein Gesamtsystem mit durchgängig neuen Eigenschaften. Anwender wollen dieses System als ein einziges Gerät ansprechen, anstatt die interne Struktur bei jeder Abfrage zu berücksichtigen.

Auf diese Weise könnten neue, virtuelle ID-Geräte entstehen. Die Struktur und das Zusammenspiel der Einzelgeräte müssen dem System selbst bekannt sein, während die Anwendungsebene unabhängig davon handelt. Ganz im Sinne der objektorientierten Programmierung könnten so Applikationen entworfen werden, die auf komplexe Identifikationssysteme zugreifen, ohne sich über die exakte Funktionsweise einzubeziehen. Bei der aktuell verfügbaren Hard- und Software ist diese Vorgehensweise allerdings Wunschdenken.


Abbildung: Eine Middleware verbindet die zahlreichen Datenquellen auf Feldebene mit der innerbetrieblichen DV-Landschaft, meist also SAP

Software.Aufgabenstellung by Katrin Reiher at 09.03.2007 11:50

Servicebereich:

Autorenkontakt, PDFs der Vorlesungsfolien und des Skripts, off-line CD, Links, das Glossar uvm.

weiter...

Alle Bilder zum Thema:Software

weiter...

Die gesamte Literaturliste

weiter...

Übungsfragen:Software

weiter...

Glossar der Identifikation

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Abkürzungen