Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

31.07.1992 - 

Datenintegration auf der AS400

Auch im Mittelstand steht das Ende der Stapelverarbeitung an

Die Zahl der Anwender moderner Softwarelösungen im Bereich der Planung und Steuerung von Produktionsabläufen steigt ständig. Damit wachsen auch die vielfältigen funktionalen Anforderungen an Standardprodukte dieser Art. Diese Entwicklung wirft immer häufiger auch die Frage auf, wie den Schwierigkeiten im Umgang mit Daten in komplexen integrierten Systemen effizient begegnet werden kann.

Das Datenvolumen eines Komplettsystems in seiner Vielfalt kann durchaus eine Größe von 1 bis 2 Gigabyte erreichen. Die erbrachte Entwicklungsleistung für PPS Standardprodukte der zweiten und dritten Generation - unter Berücksichtigung einer Hardwareplattform für den Mittelstand - umfaßt nicht selten 150 Mannjahre und mehr.

Bei der Betrachtung am Markt eingeführter Systeme läßt sich eine Reihe von Lösungsansätzen erkennen. Sie basieren oftmals auf historisch gewachsenen Softwarekomponenten, dessen angewandte Integrationsmodelle sich seit über 20 Jahren bewährt haben und über verschiedene Rechnergenerationen hinweg portiert und eingesetzt wurden.

Die physische Datenintegration wird heute größtenteils über den Einsatz einer Datenbankmaschine -wie zum Beispiel einer IBM AS/400 - erreicht. Hierbei übernehmen Beriebssystemfunktionen durch die Definition von Dateibestimmungen jegliche Pflege der Zugriffsmechanismen.

Ferner stehen oftmals Betriebssystem Features zur Verfügung, um über mehrere Dateien hinweg Auswertungen zu fahren oder Datenänderungen durchzuführen .

Systemintegration und die damit verbundene physische Dateneinbindung reichten noch nicht aus, sie dienen lediglich als Voraussetzung. Entscheidend sind die Funktionalität, die Art und Weise der Implementierung von Vorgängen und die Möglichkeiten hinsichtlich automatischer Bewertung und Verarbeitung von Informationen innerhalb des Systems.

Stapelverarbeitung verlängert Reaktionszeiten

Das Beispiel eines organisatorischen Belegflusses ohne DV-Unterstützung soll die angestrebte Integration von Daten verdeutlichen:

- Ein interner Auftrag wird geschrieben.

- Der Auftrag wird an die Disposition gereicht.

- Die Disposition errechnet - die Bedarfsmengen und gibt den Auftrag an die Fertigungssteuerung und an das Lager weiter.

- Das Lager ermittelt auf der Basis von Meldebestandsverfahren Beschaffungsanforderungen für den Einkauf.

- Der Einkauf beschafft die Materialien nach Vorgabe des Lagers.

- Die Fertigung plant Maschinen- und Personalkapazitäten auf der Basis des internen Auftrags.

Klassische "Stapelverarbeitungssysteme" halten sich strikt an derartige Abläufe. Jede organisatorische Stufe stellt eine in sich geschlossene Stapelfunktion mit dazugehörigen Datensegmenten dar. Der Nachteil einer solchen Verarbeitungsform liegt offensichtlich in der Zeitspanne der Abarbeitung der Ereignisse - es vergehen oftmals Tage. Das heißt: Die Reaktionsgeschwindigkeit auf Datenveränderungen entspricht der Durchlaufzeit der organisatorischen Schrittfolgen.

Eine Korrektur beziehungsweise Veränderung von Daten kann erst beim nächsten Stapelverarbeitungslauf erfolgen, getreu dem alten EVA-Prinzip vom Erfassen, Verarbeiten und Ausgeben von Daten. Die einzigen Vorteile liegen hierbei in der Übersichtlichkeit durch die klare Strukturierung sowie am leichter interpretierbaren Zustand der sich nicht permanent verändernden Daten.

Techniken bei der Anwendungsentwicklung

Da jedoch moderne Organisationsstrukturen versuchen, auf Marktveränderungen möglichst effizient zu reagieren, ist ein langfristiges Überleben mit ausgeprägt stapelverarbeitenden Systemen meist nicht möglich. Bei der Portierung von Anwendungen auf` zukunftsorientierte Maschinengenerationen oder bei Neukonzeptionen sind auch neue Techniken in der Anwendungsentwicklung gefragt. Die Stapelprogramme werden kürzer, asynchrone Monitore bearbeiten dynamische Postkörbe bei Bedarf automatisch.

Nur wenn der Gehalt von Informationseinheiten, die dynamischen Änderungen unterliegen, möglichst klein bleibt, können Algorithmen entworfen werden, die die Verarbeitung und Bewertung mit vertretbarem Aufwand zulassen.

Zu den zentralen Aufgaben zählt gewiß das Verändern von Lagerbeständen, Kapazitätseinheiten oder Stammdaten verschiedenster Art. Als kleinste Einheit im Bereich der Bestandsführung ist hier - sofern das System dies leistet - die Charge beziehungsweise das Gebinde zu nennen.

Wesentliche Voraussetzungen für das Beherrschen derart komplexer Problematiken sind

- die permanente Ereignisverarbeitung nach dem Verursacherprinzip,

- permanentes interaktives Nachrichtennetzwerk sowie

- Interaktive und asynchrone Abarbeitungsmöglichkeiten weitgehend aller Ereignisse.

Bei den obengenannten Voraussetzungen ergeben sich folgende Zusammenhänge:

Eine Ereignisverarbeitung nach dem Verursacherprinzip bearbeitet entstehende Ereignisse auf der verursachenden Ebene. Als Ergebnis dieser Verarbeitung können Folgeereignisse entstehen. Diese werden unter Berücksichtigung des Schneeballprinzips auch über mehrere Strukturstufen hinweg weiter bearbeitet.

Ein Nachrichtennetz ist notwendig

Ein Beispiel: Das primäre Ereignis sei eine Unterschreitung eines Endprodukt-Meldebestandes durch eine Lagerentnahme. Die Bearbeitung dieses Ereignisses hat als Ergebnis einen Produktionsvorschlag des Endproduktes zur Folge. Die daraus resultierenden Folgeereignisse sind Verfügbarkeitsprüfungen, Bedarfsermittlungen und Einzelplanungen der Komponenten. Diese Folgeereignisse können bei der Bearbeitung weitere Folgeereignisse erzeugen. Kurz: Es entsteht eine Ereigniskette nach dem Verursacherprinzip.

Der Vorteil dieser Abarbeitungsform liegt darin, daß nicht alle eventuellen Strukturelemente zu überprüfen und zu behandeln sind, sondern nur die vom primären Ereignis direkt abhängigen und betroffenen Daten. Um die beschriebene Ereigniskette aufzubauen und zu analysieren, ist ein permanentes Nachrichtennetzwerk notwendig, das die "Benachrichtigung" aller betroffenen Systemkomponenten übernimmt. Ein solches Nachrichtennetzwerk steuert optimalerweise nicht nur die Kommunikation zwischen Anwendern, sondern auch zwischen Funktionen und Anwendern und sogar zwischen Funktionen untereinander.

Als dritte wesentliche Voraussetzung ist die interaktive und asynchrone Abarbeitungsmöglichkeit von Ereignissen zu sehen. Nur wenn der Anwender die Möglichkeit hat, die Veränderung und Abhängigkeit seiner Datenelemente sofort zu erkennen und darauf zu reagieren, ist eine organisatorische und funktionale Integration erreicht.

Integration mit den dazugehörigen Verarbeitungs- und Darstellungsmechanismen hat natürlich auch seinen Preis. Die Zahl der Folgeereignisse steigt über den Bearbeitungszeitraum eines primären Ursprungsereignisses hinweg nicht selten exponential an.

Die sich daraus ergebende Verarbeitung und Bewertung dieser Folgeereignisse unterliegt einer Eigendynamik, die nur durch die einem Expertensystem ähnliche Funktionalität kontrolliert werden kann. Das heißt: "Integration wird durch Funktionalität erreicht."

Die Datenbasis muß auf diese funktionalen Strukturen feingliedrig abgestimmt sein, um sie überhaupt zu ermöglichen. Auch an die Hardware werden hier besondere Anforderungen gestellt, da das Zeitverhalten für Bereitstellung und Aktualisierung eines integrierten Datennetzes über Praxistauglichkeit und Akzeptanz maßgeblich mit entscheidet.

Betrachtet man Abhängigkeiten innerhalb der Fertigung, dann zeigt sich, daß noch keineswegs alle Probleme der Datenintegration gelöst sind. Der Ausfall einer Produktionseinheit zeitigt zum Beispiel unabsehbare Auswirkungen auf das kapazitive und dispositive Netz im Rahmen eines Regelkreises "Management von Störungen".

Die Vielzahl der möglichen Folgeereignisse könnte im Extremfall zu einer Überprüfung und Verarbeitung nahezu der gesamten dynamischen Daten eines Planungs- und Steuerungssystems führen. Der hierfür nötige Aufwand, läßt sich nicht mehr mit Ansprüchen wie möglichst rascher Auflösung und Ergebnisdarstellung von Abhängigkeiten vereinbaren.

Der Weg zur Realisierung vollständiger Integration in komplexen PPS-Anwendungen ist sichtlich eingeschlagen, doch wird es auch in absehbarer Zukunft ein Weg der Kompromisse sein, sowohl für Anwender als auch für Hersteller.

*Thomas Walther und Wolfgang Lehmann sind Geschäftsführer der SAM EDV Dienstleistung GmbH, Göppingen-Ursenwang.