MÜNCHEN - Ohne den notwendigen Freiraum für das fachliche Fingerspitzengefühl im Produktionsprozeß steht trotz aller DV-Technisierung die zukunftsorientierte Konkurrenzfähigkeit in Frage. Die J. M. Voith GmbH aus Heidenheim verwirklicht in einer geschickten Symbiose im Werk München die Verwertung von Praxiserfahrung auf CIM-Basis.

Mit Blick auf das nächste Jahrtausend realisiert die J. M. Voith GmbH derzeit eine Straffung und Durchorganisation ihrer Produktion. Das Ziel des Projektes ist, im Rahmen einer Neustrukturierung vorerst des Münchner Werkes den gesamten Informationsfluß der komplexen und stark kundenorientierten Fertigung sowie die reine Fertigungssteuerung mit allen Komponenten zu automatisieren.

Für die Fertigung werden Grobdaten fein aufbereitet

Die Zentrale der J. M. Voith GmbH befindet sich in Heidenheim. An das administrative Hauptquartier ist ein Werk für die Herstellung von Maschinen und Anlagen für die Papierindustrie einschließlich der Stofftechnik, die Herstellung von Turbinen, des Voith-Schneider-Propellers und Produkten für die Antriebstechnik angeschlossen. Ein Werk in Crailsheim für kleinere Teile und eines in München gehören zu dem Verbund.

Das Münchner Werk, das DV-technisch über die letzten zwei Jahre von der GEI Informatik GmbH aus Stuttgart auf den letzten Stand gebracht wurde, fertigt hauptsächlich automatische Busgetriebe, Wandlergetriebe für Hubstapler, hydrodynamische Bremsen und andere Komponenten für die Automobilindustrie.

Aus technischen Erwägungen wurde das Projekt von Beginn im Januar 1987 an in zwei Teilbereiche aufgesplittet: LTR (Lager- und Transport-Rechner) und FLR (Fertigungsleitrechner).

Das Team der GEI befaßte sich mit dem Bereich FLR, in dem es galt, aus den Grobdaten, die vom IBM-Hostrechner aus Heidenheim nach München fließen, feinstrukturiert die Fertigung aufzubereiten und zu steuern, die vor- und nachgelagerte Materialwirtschaft zu verwalten und die insgesamt notwendigen Informationen zum Betriebsgeschehen bereitzustellen.

Um die Mittelbereitstellung und -verwendung für die Produktion wie auch den komplexen Produktionsprozeß als solchen DV-technisch sauber in den Griff zu bekommen, wurde schon zu Beginn des Projektes auf Methoden des Software-Engineering (SWE) zurückgegriffen. Bei J. M. Voith einigten sich die Projektbeteiligten auf die Entwicklungsumgebung ProMod der GEI GmbH.

Bevor das CIM-Projekt startete, lief die Fertigungssteuerung weitestgehend manuell, so die Projektverantwortlichen. Die Fertigungslisten kamen von dem IBM-Hostrechner aus Heidenheim und wurden von der zentralen Münchner Fertigungssteuerung an die verschiedenen Meistereien gegeben, die sich dann untereinander absprachen und die Fertigung feinterminierten.

Die Auftragspapiere begleiteten dabei auch rein physisch das Werkstück; eine Rückmeldung an die DV erfolgte meist erst nach der Fertigstellung.

Der Rechner aus Heidenheim zerlegt die zentral bearbeiteten Kundenaufträge in fünf Klassen, bevor sie an das Münchner Werk weitergegeben werden: Vormontage-, Montage-, Fertigungs-, Ersatzteil- oder Reparaturaufträge.

Die Komplexität dieser Aufträge, die jeder für sich eine andere Bearbeitung erfahren, wird bei einem Montageauftrag deutlich: So müssen hier unter Umständen gewisse Teile eines Getriebes noch extra gefertigt werden, sie werden in der Vormontage mit eventuell vorhandenen Fertigprodukten zusammengefügt. In einem weiteren Schritt entsteht dann aus vormontierten Getriebekomponenten und Stücken aus der Einzelfertigung das gewünschte Produkt in der Endmontage.

Knappes Zeitfenster sorgt für Flexibilität

Jeder Kundenauftrag wird im IBM-Hostrechner ausgehend vom Liefertermin nach der inhaltlichen Aufbereitung rückwärts terminiert. Bereits in diesem Schritt optimiert das System in Heidenheim in groben Zügen die Maschinenbelegung im Münchner Werk und verknüpft einzelne Aufträge, sofern möglich, auch mit anderen, ähnlichen Ordern.

Aus Gründen der Flexibilität liefert der Heidenheimer Hostrechner diese Grobdaten relativ kurzfristig vor Fertigungsbeginn an München weiter: Das Zeitfenster beträgt momentan gut 14 Tage.

Das Zusammenspiel aller Kräfte, der Arbeitsgänge, der Maschinen, Betriebsmittel und Betriebsstoffe wird nun zukünftig direkt in dem Münchner System feinterminiert und überwacht. Arbeitsvorgänge (AVO) werden an- und abgemeldet Material ebenso wie Betriebsmittei zusammengestellt und reserviert, Transportaufträge im Fertigungslauf ausgearbeitet und aufbereitet.

Der Fertigungsleitrechner stößt diese Aktivitäten an, die dann von dem nachgelagerten LTR ausgeführt und retourniert werden.

Die IBM-Terminals, die noch in Heidenheim und Crailsheim in Gebrauch sind, werden in München im Rahmen des Projektes teilweise durch FLR-Terminals ersetzt. In München steht zu diesem Zweck ein Cluster aus zwei VAX 8250 mit später über 100 Terminals in der Endausbaustufe bereit. Ein HSC-Plattencontroller ist nachgeschaltet, der die automatisch gespiegelten Disks verwaltet. Das Ethernet-Netzwerk und die Server sind bereits installiert, das Gesamtsystem soll bis Ende 1988/Anfang 1989 in Betrieb gehen. Als Datenbank ist Ingres eingesetzt.

Mit den Arbeiten am Fertigungsleitrechner wurde im Januar 1987 begonnen. Um eine gemeinsame Sprachbasis zwischen DV-Projektmitarbeitern und den Fertigungsfachleuten aufzubauen, bot sich an, konsequent die Hilfe einer Entwicklungsumgebung in Anspruch zu nehmen.

Das Pflichtenheft des Projektes besteht aus mehreren Kapiteln, von denen sich nur eines mit der Anwendungssoftware befaßt, die anderen beinhalten Fragen der hard- und software-technischen Ausstattung oder die Terminplanung des Projektes.

Bereits bei der grundlegenden Beschreibung der Anwendungssoftware wurde schon begonnen, ProMod in das Projekt einzubinden und die Entwicklungsumgebung so in das Pflichtenheft zu integrieren.

So entstand die Grobstruktur als oberster Level der zu gestaltenden Programme bereits mit Hilfe des ausgewählten SWE-Systems.

Die Komplexität der Aufgaben des Fertigungsleitrechners in diesem speziellen CIM-Vorhaben legte es dabei nahe, das Gesamtsystem in vier Einzelparts zu zerlegen: Disposition als Funktion der Auftragsannahme des Hostrechners und Planungseinheit bis hin zur Maschine zum einen, dann die Durchflußsteuerung als Fortführung der Dispositionsergebnisse mit ihren Maschinen-belegungsplänen zur Transportsteuerung und BDE-Verarbeitung zum anderen. Durch sie werden neue Aktionen ausgelöst, Material rechtzeitig reserviert und zur Verfügung gestellt, die Betriebsmittel kommissioniert und dekommissioniert.

Nicht alle Maschinen sind automatisiert verplanbar

Zudem sind spezielle Bedienerfunktionen bereitstellt, denn in der Fertigung der Voith GmbH gibt es eine interessante Besonderheit: So existieren im Fertigungsprozeß bestimmte Maschinengruppen, die nicht automatisiert verplanbar sind. Zu ihnen gehört zum Beispiel die Härterei. Die Arbeiten hier sind abhängig von der Größe und dem gewünschten Härtegrad des zu bearbeitenden Stückes, so daß hier auf die Erfahrung des Fachmannes vor Ort bei der optimalen Belegung des Ofens zurückgegriffen werden muß. Er ruft aus der Durchflußsteuerung passende Teile auch anderer AVOs (Arbeitsvorgänge) ab, die mit dem geplanten, anstehenden Härtegang zusammenpassen.

Die Forderung einer gemeinsamen Sprachbasis durch die Entwicklungsumgebung erwies sich bei der Analyse der komplexen Zusammenhänge insbesondere bei der Erarbeitung solcher "erfahrungsorientierter" Arbeitsgänge als hilfreich. Durch die Klarheit der Struktur und Analyse wird eine gute Möglichkeit geschaffen, notwendige Freiräume einzuplanen, ohne den DV-gestützten Ablauf zu irritieren.

Als weitere Teilprozesse im System kristallisierte sich der Material- und Betriebsmittelfluß als Überbau zum LTR heraus. Dieser Part bekommt seine Anstöße aus der Durchflußsteerung und koordiniert die entsprechenden Aktivitäten, die dann als Input in das Lager- und Transportsystem fließen. Rund 25 000 Artikel (Material und Betriebsmittel) befinden sich in den verschiedenen Lagern und werden palettenweise für die Auftragsabwicklung bereitgestellt. Letztlich ist dem FLR noch die Stammdaten-verwaltung zugeordnet.

Top-down-Verfeinerung muß nachvollziehbar sein

"Die Tatsache, daß frühzeitig eine Software-Engineering-Methode eingesetzt wurde, ist gut gewesen für die Zusammenarbeit mit dem Kunden und um Arbeit zu sparen", meint Projektleiterin Rita Dudick rückblickend. Bereits in der Anfangsphase wird mit dem Kunden intensiv besprochen und abgestimmt, was über die Anwendungssoftware im Pflichtenheft festgelegt wird: Die Entwicklungsumgebung verhilft bei diesen Gesprächen durch ihre Forderung nach klarer Struktur gut dazu, daß die Diskussionen immer wieder auf den Punkt kommen. Dabei ist auch insbesondere von Bedeutung, so die Erfahrung der Projektleiterin, daß die Top-down-Verfeinerung, die durch ein solches System vorgesehen ist, vom späteren Anwender gut und griffig nachvollzogen werden kann. Die folgende Systemanalyse in diesem Projekt wurde bis zu Level 6 durchgeführt, erreichte also einen sehr hohen Grad der Verfeinerung.

Nicht nur in der Darstellungsform, sondern auch in bezug auf die Datenflüsse hat die Entwicklungsumgebung eine gute, durchgehende Kontrolle erwirkt und in ihrer Konsequenz auch die Kommunikation zwischen dem Entwicklungsteam der GEI und den Voith-Projektmitarbeitern erleichtert und gesteuert.

Dennoch bedeutet der Einsatz einer SWE in der anfänglichen Eingewöhnungsphase einen gewissen Mehraufwand an Zeit und Denkarbeit, der allerdings im weiteren Projektfortschritt in den Phasen des Programmentwurfes und der Implementierung leicht wieder wettgemacht wird.

Die schrittweise Verfeinerung von der Grobstruktur bis hin zum laufenden System läßt sich dabei auch rein optisch gut verfolgen: Das Pflichtenheft einschließlich der Anwendungssoftware des Voith-Projektes umfaßte einen großen Aktenordner, in der Phase der Systemanalyse wuchs die Zahl auf derer zwei, beim Modular-Design waren es schon vier Ordner und ihre Zahl für die Hardcopy-Dokumentation der Software wird wohl exponentiell steigen - aber der rote Faden ist durchgängig.

Pseudocode hinterfragt die reine logische Funktion

Nachdem der Transfer zur Abbildung der Moduln auf dem Rechner in der relativ kurzen Zeit von drei Wochen durchgeführt wurde, wurde zu jedem Modul Pseudocode eingegeben. Auch hier unterzogen die Projektmitarbeiter die Daten und Datenflüsse erneut konsequent einer Kontrolle.

Der Pseudocode hat gegenüber herkömmlicher Vorgehensweise den Vorteil, daß für jedes Modul unabhängig von der Programmiersprache nochmals die reine logische Funktion hinterfragt wird, die beantwortet, was mit der einzelnen Funktion konkret zu tun sei.

Am Beispiel der Materialkommissionierung sei dies kurz erläutert. Anhand einer Auftragsnummer wird beispielsweise aus der Datenbank eine Materialliste abgerufen. Es ist für den Auftrag speziell zu prüfen, ob das Material reserviert ist und wo es lagert. Auch die Transportlisten müssen aufbereitet werden - sie werden hinterlegt und zu gegebener Zeit aktiviert und an ein anderes Modul weitergegeben.

In dieser Phase des Projektes können vor allem nochmals auch die Schnittstellen und Daten überprüft werden. So entsteht parallel zur Codeumwandlung ein sicherer Satz von Daten-beschreibungen, der für die weitere Verarbeitung abgespeichert wird.

Auch in dieser Phase wird das Teamgespräch anhand des Pseudocodes unterstützt und mögliche Fehlerquellen beseitigt. Bei Voith erfolgte die Umsetzung des Pseudocode in C mit den Tools "Procap" und "Prosource".

Innere Ordnung wirkt sich auf Wartung und Pflege aus

Bei der Rückschau auf die Projektarbeit bei der J. M. Voith GmbH heben die Beteiligten vor allem die gemeinsame Sprachbasis hervor, die durch den Einsatz einer Entwicklungsumgebung unterstützt und gefordert wird.

Flankiert durch viele Grafiken und Mini-Spezifikationen zu jedem System-Baustein konnte dem Projekt eine innere Struktur gegeben werden, die auch positiv auf die zukünftige Pflege und Wartung sowie geplante Erweiterungen durchschlagen wird - neben der vordergründigen Zielsetzung der Produktionsglättung wohl ein willkommener Beitrag zum Schutz der Investition.