Da sich mittlerweile gezeigt hat, daß es keine schlüsselfertigen, integrierten Lösungen zu kaufen geben wird, müssen die Unternehmen die Integrationsaufgabe selbst lösen. Voraussetzung hierfür ist erstens professionelle Fachkompetenz beziehungsweise Eigenständigkeit im notwendigen Umfang und zweitens der strategische Nachdruck seitens der Unternehmensleitung. Der Weg zu einem integrierten Informations-Management ist evolutionär; er muß schrittweise und unter Einbeziehung des Vorhandenen vollzogen werden.

Ein allumfassendes Informations-Management erfordert eine angemessene methodische Vorgehensweise. Hierzu sind verschiedene miteinander gekoppelte Abstraktionsebenen notwendig, um das Ganze vollständig, konsistent, transparent und überschaubar zu halten. Heute gibt es schon viele Bottom-up-Ansätze und Realisierungen, mehr oder weniger große, mehr oder weniger gut kultivierte IV-Inseln, teilweise mit nützlichen Verbindungen.

Im Vordergrund steht eine Informationsstrategie, die sich nach den Geschäftszielen beziehungsweise - strategien richtet - Top-down, und zwar von ganz oben beginnend - unter Berücksichtigung der Ist-Situation, der Umweltfaktoren sowie der technologischen Neuerungen. Die Informationsstrategie muß also die Aspekte pragmatisch, effizient und zukunftssicher berücksichtigen.

Umgesetzt heißt dies, die strategische Top-down-Philosophie hat, soweit möglich, auch die vorhandenen Bottom-up-Lösungen einzubinden. Dabei muß eindeutig die Integration Vorrang haben vor der Lösung von Einzelproblemen.

Der Begriff "Information-Engineering" soll diese neue methodische Vorgehensweise umschreiben, die den Übergang von der Datenverarbeitung zur Informationsverarbeitung und -bereitstellung bewerkstelligt. Der Schlüsselaspekt in diesem Wechsel ist der Übergang von der Funktions- zur Datenorientierung. Die Information in Form von Daten als Abbildung auf den Trägersystemen ist eine eigene, absolute Ressource.

Die Objekte oder die entsprechenden Daten stehen im Mittelpunkt aller Informationssysteme und ihre Strukturen sind stabiler als die darauf anzuwendenden Funktionen. Dieser Wandel zeigt sich auch zum Beispiel in dem Trend zu objektorientierten Sprachen beziehungsweise Systemen.

Auf dem Wege zum konzeptionellen Unternehmensdatenmodell ist zuerst eine komplette Bedarfsanalyse der betrieblichen Informationsflüsse und Abläufe notwendig. Dabei sind zwei Prinzipien konsequent einzuhalten:

- weg vom ungewollten Information-Hiding, das durch fehlende Abläufe, Fehlverhalten oder durch Unzulänglichkeit der Informationssysteme bedingt ist,

- hin zum gewollten Information-Hiding, nämlich dann, wenn keine betriebliche Notwendigkeit vorliegt (Need-to-know-Prinzip) und soweit Aktualität beziehungsweise Relevanz nicht gegeben ist.

Es muß also die Frage, wann was in welcher Form gebraucht wird, eindeutig beantwortet sein. Auf dieser Basis entsteht eine Datenarchitektur, die den Integrationsrahmen für die modulare Zusammenfassung aller anwendungsspezifischen Datensichten zu einem gesamten, unternehmensweiten Datenmodell darstellt.

Dieses Modell muß leben, weil die Fortschreibung, das heißt die Änderbarkeit und Erweiterbarkeit, der Datenarchitektur unabdingbar für den praktischen Wert dieser Methode ist. Eine starre Datenarchitektur dagegen verliert sehr schnell ihren Wert als gültiger Orientierungsrahmen. Unter diesem Alterungsproblem leiden bekanntlich alle funktionsorientierten Systeme mehr oder weniger. Als Beispiel mag hier der hohe Software-Wartungsaufwand dienen.

Genaue Definition des Anwendungssystems

Auf Basis dieses konzeptionellen Schemas entsteht dann das logische sowie das physische Design, ebenfalls unter der vereinfachten Fragestellung: Wo wird was verarbeitet und gespeichert? Damit ist die Optimierung der Erfassung, Verarbeitung und Verwendung der Daten auf der Grundlage des unternehmensweit integrierten Datenmodells möglich. Die Daten werden dann letztlich nur einmal erfaßt, redundanzfrei - zumindest im logischen Sinne - gehalten, bedarfsgerecht aufbereitet und zeitgerecht angeboten.

Als weiterer wichtiger Effekt der projekt- beziehungsweise datenorientierten Vorgehensweise gestaltet sich auch die Entwicklung von Anwendungssystemen günstiger, weil die datenstrukturorientierte Analyse der Anwendungsorganisation bestimmte Zusammenhänge wesentlich präziser und konsistenter beschreibt als die funktionsorientierte Betrachtungsweise. Damit gelingt die genaue Definition des Anwendungssystems bei Anwendung der Datenstrukturanalyse wesentlich besser als bei ausschließlich funktionsorientierten Methoden, bei denen Daten lediglich in Zusammenhängen mit Funktionen implizit, nicht aber hinsichtlich ihrer eigenen Logik der Datenstruktur betrachtet und analysiert werden. Datenmodellierung liefert darüber hinaus auch einen wichtigen Beitrag zur Verringerung der Verständigungslücke zwischen Fachbereich und Systementwicklung, ein entscheidender Vorteil.

"Konzeptionell" werden solche Datenmodelle deswegen genannt, weil sie Aussagen über Bedeutung und Inhalt, nicht jedoch über die DV-technische Realisierung dieser Daten machen. Die Abstraktion der Daten unterstützt ihre Eigenstabilität, aber auch ihre Portabilität.

Die Entwicklung der Datenmodellierung basiert bekanntlich auf dem mathematisch fundierten relationalen Datenmodell mit seinen Normalformen nach Codd und auf dem semantischen Aspekt des Daten betonenden Entity-Relationship-Modell (ER-Modell) von Chen. Beide Aspekte sind vielfach weiterentwickelt und teilweise auch zusammengeführt worden. Sie liegen diversen Methoden, Verfahren und Werkzeugen zugrunde, die die Erstellung von Datenmodellen unterstützen.

Im gesamten Anwendungsspektrum ist eine zunehmende maschinelle Unterstützung aller Routine- beziehungsweise automatisierbaren Tätigkeiten zu erwarten, angefangen vom methodischen Konstruktionsprozeß bis hin zur Teile- beziehungsweise Komponentenfertigung und Montage. Beispiele hierfür sind Handskizzeneingabe, automatisches Digitalisieren, Generieren von 3D-Modellen, automatische Bemaßung, Simulation von NC-Vorgängen und Roboterbewegungen. Eine wesentliche Beeinflussung und Forcierung wird generell durch anwendungsspezifische Expertensysteme erfolgen. Ohne große Euphorie sollte man sich hier zuerst auf den Ersatz von Routinetätigkeiten beschränken.

Wichtig bleibt nach wie vor die Verfeinerung der Planung von Ingenieursleistungen. Zwar läßt sich die Kreativität nur schwer a priori planen, doch können durch Simultaneous Engineering, das heißt verstärktes Parallelisieren der Teilschritte mittels Netzplantechnik, noch enorme Zeitgewinne erzielt werden. Im Flugzeugbau gibt es auch den Fall des Reverse Engineering, der die gesamten Kunden- beziehungsweise Marktanforderungen inklusive der Lebenszyklus-Logistik als ganzheitlichen Ansatz behandelt.

Im Zuge der Integration sind auch Innovationen zu erwarten, wenn zusätzlich zum rein analytischen Vorgehen im Ingenieurbereich ganzheitliche Methoden angewandt werden. Hierfür steht das schon stark strapazierte Schlagwort Synergie. Die bisher praktizierte Separation von Funktionen mit Einzeloptimierung über serielle Iterationen zwischen diesen Funktionen in Richtung Gesamtoptimum wird um integrierte Optimierungen zu erweitern sein. Dies ist notwendig, um alle Kombinationseffekte zwischen den verschiedenen Disziplinen zu erzielen, etwa durch die Abkehr vom klassischen Flugzeugkonzept oder durch die A-priori-Einbeziehung von Prämissen aus anderen Disziplinen, so daß unzulässige Einzeloptima gar nicht erst unnötigerweise in Betracht gezogen werden.

Beide Seiten, die technische und die administrative, müssen noch viel stärker und intensiver integriert werden. Separate Optimierungen sind heute in einzelnen Teilgebieten bei weitem nicht mehr ausreichend. So geht der Weg zur wirtschaftlich gesamtoptimierten Fertigungsautomatisierung nicht ohne eine vollständig maschinengestützte, online-fähige und integrierte Administration des rein technischen Komplexes CAE/CAD/NC/CAM.

Portabilität zwischen verschiedenen Systemen

Flankierend und verzahnt wenn nötig in Echtzeit - soll PPS die technischen Teilbereiche verwalten und einander zuordnen, zum Beispiel Stücklisten, aber auch konsistente Archivierung der Geometrien und NC-Teileprogramme. Im CAM-Bereich soll darüber hinaus die gesamte Fertigungsplanung und -steuerung, etwa im Sinne eines CIM-Handlers, abgewickelt werden. Hier liegen die größten Rationalisierungspotentiale in den betrieblichen Abläufen.

Weiter sind zur Optimierung zusätzliche Methoden und Verfahren in die IV-Technik einzubeziehen beziehungsweise zu entwickeln, wie heuristische Methoden, Methoden der Evolutionstheorie, der Chaostheorie etc.

Die Integration bedingt die Lösung zweier Problembereiche, nämlich

- Datenaustausch beziehungsweise Schnittstellen und

- offene Datenhaltung beziehungsweise Datenbanken.

Für den Datenaustausch zwischen verschiedenen IV-Teilsystemen und zur Zentrale sind flexible, das heißt programmierbare Schnittstellen zu definieren beziehungsweise zu realisieren (Stichwort: produktdefinierende Daten).

Die notwendige Abstraktion der Daten zwecks Austauschbarkeit beziehungsweise Portabilität zwischen verschiedenen Systemen ist sicherlich die anspruchsvollste und weitreichendste Aufgabe der Integration. Die Geometriedatenstrukturen beziehungsweise -modelle sind im Vergleich zu kommerziellen Modellen erheblich komplizierter. Dazu kommen derzeit unüberbrückbare Unterschiede beziehungsweise Unverträglichkeiten im Informationsgehalt der Modelle, zum Beispiel in der Topologie, oder in der Geometriedarstellung, etwa Beziér, Coons, B-Splines, Nurbs etc.

So stellt sich aus datentechnischer Sicht die Integration des technisch-geometrischen Bereichs (CAE/CAD/NC) als sehr schwierig dar. Hier leisten allerdings in der Praxis neben standardisierten Schnittstellen, allen voran VDAFS, manche Punkt-zu-Punkt-Koppelungen, zum Beispiel Cadam-Catia im 2D-Bereich, gute Dienste (Integrationsstufe eins).

Hohe Datenabstraktion in der dritten Stufe

In Fortführung der Standardisierungsbemühungen um Schnittstellen, wie Iges, VDAFS, Step, CAD-I, ist meiner Einsicht nach als nächstes ein dem Stand, der Technik entsprechendes modernes Bus-Konzept (Integrationsstufe zwei) anzustreben, etwa mit einer verallgemeinerten Geometrie-Datenstruktur-Schnittstelle inklusive ausreichender Topologiemöglichkeiten.

Für den Verbund verschiedener CAD/CAM-Systeme ist eine solche Bus-Lösung die günstigste. Sie reduziert zum einen die Anzahl der Interfaces im Punkt-zu-Punkt-Konzept von n*(n-1) auf 2*n (je ein Pre- und Postprozessor pro System) und erlaubt zum anderen die spätere Miteinbeziehung von weiteren Systemen.

Homogene Datenmodelle werden in der dritten Integrationsstufe durch eine entsprechend hohe Datenabstraktion erreicht. In dieser Idealstufe hat man höhere Effizienz, keine Schnittstellen-Software und vollständigen Datenaustausch beziehungsweise Datenkompatibilität. Hier bietet sich eine parametrisierende Methode an, das heißt, Geometriedaten sind danach biparametrische Daten (krummlinige Koordinaten) plus den zugehörigen Evaluatoren, die die Umrechnungsvorschriften ins kartesische System beinhalten (Abbildung 1). Empfangende Systeme können damit fremderzeugte nonnative Geometriemodelle original und authentisch behandeln. Die Fusion von CAx-Systemen wird erreicht durch die Übertragung nicht nur der Daten, sondern auch der Geometrie-Evaluatoren und deren untrennbare Benutzung in den Einzelsystemen.

Phasenkonzept sollte Tool-gestützt sein

Hier entfällt dann sowohl das Konvertieren als auch das Pre- und Postprocessing. Es sind dann keine Extra-Interfaces mehr nötig. Ein weiterer Effizienzvorteil liegt in der Geometrieverarbeitung, diese geschieht im zweidimensionalen u-v-Koordinatensystem statt im dreidimensionalen kartesischen Raum.

Zur Erreichung von Portabilität sind generell die dem Stand der Technik in der Software-Entwicklung entsprechenden Voraussetzungen zu schaffen. Das Ziel Portabilität geht insoweit nämlich konform mit den allgemeinen Bemühungen, günstigere, effizientere und wirtschaftlichere Software zu entwickeln, und zwar über den gesamten Lebenszyklus der Programme gesehen.

Die Methoden des Software-Engineering stehen hier an erster Stelle, wenn es gilt, klar und verfolgbar die verschiedenen Stufen der Software-Entwicklung, angefangen vom Pflichtenheft bis zum Austesten der Software, zu verfolgen. Dieses Phasenkonzept sollte weitestgehend IV-Tool-gestützt sein, und zwar mit kompatibler Datenübertragung zwischen den Phasen (vertikale Durchgängigkeit), um bestimmte Informationen nur einmal in die Maschine eingeben zu müssen und um Konsistenz zwischen den einzelnen Phasen - also gleichen Versionsstand - zu haben.

Wird dies nicht konsequent praktiziert, läuft das Phasenkonzept zwangsläufig auseinander, und nach einiger Zeit ist dann - wie gehabt - der jüngste Sourcecode das alleinige Dokument auf dem gültigen Stand.

Portabilität von Software verlangt sowohl Portabilität der Programme als auch der Daten - oft oder gerade auch von Alt-Daten bei Release-Wechsel und der Schnittstellen. Dazu gehört selbstverständlich auch die Benutzerschnittstelle, das heißt, der Benutzer sollte in der anderen Implementierung dieselbe Bedienungsweise vorfinden (portable Benutzerschnittstelle).

Die zu behandelnden Objekte, nämlich die Daten, werden von modernen Programmiersprachen, zum Beispiel Pascal, Ada, bevorzugter behandelt. Der hohe Grad an Datenabstraktion läßt recht komplexe Datenmodelle zu, mit der Konsequenz, daß die Programme selbst viel einfacher werden. Dies läßt sich mit der Portabilitätsforderung gut in Einklang bringen.

Großer Nachholbedarf bei Datenbanksystemen

Abstraktion ist in gewissem Sinne der erste Schritt zur Portabilität. Der zweite besteht daraus, diese Abstraktion sinnvoll und effizient auf der Maschine abzubilden (Umsetzung von Logik in Physik). Dabei gibt es bekanntermaßen mehrere verschiedene Zwischenebenen, maschinenfernere, zum Beispiel höhere Programmiersprachen, und maschinennahe, etwa Maschinencode, Firmware. Höchste Ebene über den höheren Programmiersprachen ist ein abstraktes, virtuelles Datenmodell, nämlich das erwähnte betriebliche Informationsmodell.

Beim Datenaustausch von technischen Modellen zwischen verschiedenen Teilsystemen kann der Einsatz von künstlicher Intelligenz einen weiteren technologischen Fortschritt bringen, zum Beispiel automatisches Erkennen des Sendesystems und automatische Umwandlung beziehungsweise Aufbereitung des Modells für das Empfangssystem. Mit einem entsprechenden Expertensystem läßt sich danach auch die Einbindung von gewachsenen Altsystemen in Integrationsstufe zwei und drei bewerkstelligen ein entscheidender Gesichtspunkt für die evolutionäre Integration.

Große Bedeutung für die evolutionäre Integration hat eine Optimal strukturierte Modularisierung, also eine effiziente, beherrschbare Aufteilung des Gesamtkomplexes. Ein Modul ist eine funktional abgeschlossene Software-Einheit, die eine Zusammenfassung von Datenstrukturen und Zugriffsoperationen darstellt und die ihre Leistung anderen Modulen zur Verfügung stellt beziehungsweise sich Leistungen von diesen verfügbar machen kann. Erwartet wird, daß Module einerseits weitgehend kontextabhängig und somit möglichst separat entwickelbar, prüfbar, wartbar sowie verständlich sind. Andererseits sollen sie eine möglichst hohe interne Kompaktheit und Mächtigkeit haben. Neben dieser Schnittstellenproblematik bildet die Datenbanktechnik den zweiten großen Aufgabenbereich der Systemintegration.

In bezug auf Datenbanksysteme haben die technischen Anwendungssysteme noch einen großen Nachholbedarf. Für den Anschluß von technischen Anwendungen an Datenbanksysteme ist zuerst eine Bereinigung der Datenstruktur und Geometriezugriffe nötig. Dies bedeutet allerdings meist eine komplette Überarbeitung des funktionsorientierten Systems. Nach einer solchen Umstellung auf eine standardisierte Datenbankschnittstelle - nach Codasyl ist nun SQL aufgrund der hohen Flexibilität, stark in den Vordergrund gerückt - ist die Integrationsfähigkeit und Zukunftssicherheit gegeben.

Die heutigen rein relationalen SQL-basierten Datenbanksysteme erlauben aus Performance-Gründen nicht die gewünschte technische Tiefe. Doch lassen sich die Aufgabenstellungen, die im Bereich verteilter technischer Datenbanken bestehen, basierend auf dem vorliegenden Hybridkonzept, stufenweise lösen. Für die nächste Stufe braucht die Praxis dann allerdings einsatzfähige Non-Standard- beziehungsweise technische DBMS. Entsprechende Erweiterungen bestehender relationaler Systeme zeichnen sich ab, zum Beispiel XSQL, SQLii, und es gibt vielversprechende Vorhaben, etwa Postgres, AIM, Damokles und NF2, die die universelle Konzeption der Objektorientiertheit in Daten und Systeme mit anbieten. Wichtige Forderungen, abgeleitet aus den Erfahrungen der Praxis, an ein zukünftiges verteiltes technisches Datenbanksystem sind vor allem:

- Management der verteilten Systeme, zum Beispiel langandauernde Transaktionen,

- verteiltes Datenbank-Sicherungskonzept, sowohl lokal als auch zentral,

- Assoziativverbindung zu technisch-administrativen Systemen,

- Versionsführung von technischen Datenmodellen,

- praktisch unlimitierte Modellgröße (mitwachsende Modellgröße),

- topologieverknüpfte Flächengeometrie,

- parametrisierte rechnerinterne Darstellungen (Prid),

- Flächengeometriemodell mit integrierter konventioneller Zeichnung in der Endausbaustufe,

- Speicherung von Genaugeometrie, Approximations-Geometrie (Polygone, Polyeder) und Abgriffgeometrie (FEM, Panel) nach einheitlicher Methode und assoziiert.

So muß der Weg der Realisierung in Zukunft aussehen: pragmatische, schrittweise Integration von Vorhandenem und Neuem mit modernen Methoden und Hilfsmitteln, um neben rein funktionalen und Integrationsfortschritten auch Effizienz und Zukunftssicherheit zu erzielen.

* Dr. Werner Fischer ist Vertriebsleiter Technische Systeme bei Cap Debis IAS.