Ansicht
Dokumentation

APO-OPT: APO Optimization Extension Workbench ( RELNAPO_30A_SP1_APX )

APO-OPT: APO Optimization Extension Workbench ( RELNAPO_30A_SP1_APX )

ROGBILLS - Synchronize billing plans   PERFORM Short Reference  
Diese Dokumentation steht unter dem Copyright der SAP AG.
SAP E-Book

Kurztext

APO-OPT: APO Optimization Extension Workbench

Verwendung

Ab Release 3.0A (First Customer Shipment und Support Package 1) steht die erste Version der APO Optimization Extension Workbench im APO zur Verfügung.

Die Optimierung nimmt im heutigen Supply Chain Management eine Schlüsselstellung ein. Gute Optimierungswerkzeuge, die an die individuellen Belange ihres jeweiligen Benutzers angepaßt sind, entscheiden über die Effizienz von Planung und Produktion und stellen somit einen marktentscheidenden Faktor dar.

Einsatzmöglichkeiten

In der Standard-Optimierung im Advanced Planner and Optimizer (SAP APO) gibt es an verschiedenen Stellen die Möglichkeit, auf Optimierungswerkzeuge zuzugreifen:

  • In der strategischen Planung beim Aufbau der gesamten Versorgungskette (der Komponente .Network Design).
  • In der taktischen mittel- und langfristigen Planung (Supply Network Planning)
  • In der operativen Produktionsplanung (.Production Planning and Detailed Scheduling)
  • In der Transportplanung (Transportation Planning and Vehicle Scheduling)
  • Bei der Verteilung produzierter Güter (Deployment)

Die hier aufgeführten Komponenten optimieren generische Zielgrößen, d.h. Parameter wie beispielsweise Produktionskosten oder Durchlaufzeiten, die für jedes Unternehmen grundsätzlich von Interesse sind.

Spezielle für einzelne Unternehmen oder Branchen wichtige Kenngrößen werden dabei nicht beachtet. So können beispielsweise für die Optimierung der Reihenfolge von Vorgängen auf einer Maschine geometrische oder technologische Randbedingungen von Belang sein. Dazu können zum Beispiel Anforderungen an Abmessungen, Gewichte, Temperaturen etc. gehören. Zu den wichtigsten Optimierungskriterien gehören die Minimierung von Abfällen oder die Maximierung der Maschinenauslastung. Derartig spezielle Randbedingungen und Zielgrößen werden von den Standardoptimierern nicht beachtet.

Ziele der APO Optimization Extension Workbench

Mit der APO Optimization Extension Workbench (APX) wird eine neue Möglichkeit gegeben, die Optimierung zu flexibilisieren. Ziel ist es, die Standard-Planungswerkzeuge des SAP APO um benutzerspezifische Optimierungskomponenten zu erweitern. Diese individuellen Optimierer werden direkt aus dem APO heraus aufgerufen. Sie bilden zusammen mit den Standard-Optimierern und den Heuristiken ein Planungssystem. Es bietet jederzeit die nötige Flexibilität, um genau auf die Bedürfnisse des Benutzers abgestimmt zu werden.

Neben der funktionalen Integration des externen Optimierers in dem Umfeld der Standardkomponenten des APO soll der Optimierer auch datentechnisch so eng angebunden werden, daß er sich stets vom Datenbestand des APO (aus dem liveCache und dem Datenbankserver) frei bedienen kann. Die Ergebnisse einer Optimierung können schließlich wieder im Datenbestand des APO abgelegt werden. Der Aufbau einer separaten Datenbank erübrigt sich daher. Die Anbindung wird über die BAPI-Technologie der SAP umgesetzt.

Randbedingungen und Zielgrößen, die so benutzerspezifisch sind, daß sie von Standard-Optimierern nicht betrachtet werden, gebrauchen Größen, die ihrerseits nicht im Standard-Datenbestand des APO vorhanden sind. Die Datenbank des APO ist daher erweiterbar. Es können neue Tabellen angelegt und gefüllt werden. Auch der Zugriff auf diese Daten wird durch die BAPI-Technologie ausgeführt.

Auf diese Weise wird ermöglicht, externe Optimierer zu einem integralen Bestandteil des APO zu machen. Sie werden wie die restlichen APO Komponenten vom APO aus aufgerufen, bedienen sich des APO-Datenbestandes und legen schließlich ihre Ergebnisse in diesem wieder ab.

Beispiel: .Verschnittoptimierung

Ein Beispiel soll die genannten Ziele verdeutlichen. Aus einem Walzwerk kommende Coils (Rollen gewalzten Stahls) mit einer bestimmten Stahlbandlänge und breite sollen, je nach Kundenwunsch, zugeschnitten werden. Ergebnisprodukte sind entweder kleinere Coils oder Blechtafeln, die dann an den Kunden ausgeliefert werden.

Der Zuschnitt unterliegt geometrischen Restriktionen: Das heißt, daß die Breiten der Coils oder Blechtafeln in ihrer Summe nicht größer sein dürfen als die Breite des ursprünglichen Coils. Das gilt ebenso für die Längen. Beim Zuschnitt entstehender Verschnitt geht als .Schrott wieder in die Stahlproduktion ein.

Während die geometrischen Größen .Länge und .Breite als Attribute in der merkmalsbasierten Planung geführt werden, sind die oben genannten speziellen Restriktionen für diese Größen den Feinplanungskomponenten des APO unbekannt. Sie werden somit nicht beachtet und sind nach einer Standardplanung höchstwahrscheinlich verletzt. Das Ziel, die Menge des Verschnitts möglichst klein zu halten, ist außerdem ein zusätzliches, für diese Fertigung spezielles, Optimierungskriterium, das den Standard-Optimierern ebenfalls unbekannt ist.

Um die Randbedingungen einzuhalten und zusätzlich eine Minimierung des Verschnitts zu erreichen, wird ein externer Optimierer benötigt. Dieser kann den, bezüglich der zusätzlichen Randbedingungen, fehlerhaften Plan im APO aufnehmen, korrigieren und gleichzeitig den Verschnitt optimieren. Der geänderte Produktionsplan wird dann an den APO zurückgegeben.

Aufruf eines externen Optimierers

Die Möglichkeit zum Start eines externen Optimierers ist überall dort vorgesehen, wo man auch einen Standard-Optimierer starten kann. Dies sind insbesondere die Drucktasten Optimieren auf den Plantafeln der Komponenten .Production Planning and Detailed Scheduling (PP/DS) und .Supply Network Planning (SNP). Nach ihrer Betätigung starteten hier bisher die jeweiligen Standard-Optimierer.

Vorgehensweise

  1. Wählen Sie z.B. für die Produktions- und Feinplanung aus dem APO-Hauptmenü Produktionsplanung-->Interaktive Produktionsplanung-->FeinplanungstafelSicht 1-3. Starten Sie mit einem geeigneten Profil die PP/DS Plantafel. Hinweis: Wählen Sie die Plantafel entsprechend der Komponente, in der der externe Optimierer angewendet werden soll, aus. An diesen Stellen konnten bisher nur Standard-Optimierer angewendet werden.
  2. Wählen Sie die Drucktaste Optimieren auf den Plantafeln der Komponenten Production Planning and Detailed Scheduling (PP/DS) und .Supply Network Planning (SNP).
  3. Das Dialogfenster Optimiererauswahl erscheint. Hinweis: Sie können im Customizing einstellen, welche Optimierer Sie hier zur Auswahl angezeigt bekommen möchten. Wenn Sie mehr als einen Optimierer eingestellt haben, wird zunächst ein Menü angezeigt, welches Ihnen eine Auswahl der zur Verfügung stehenden Optimierer anzeigt.
  4. Wählen Sie einen externen Optimierer aus.
  5. Sie gelangen auf den GUI des externen Optimierers Hinweis: Der Inhalt dieses Fensters ist der GUI des externen Optimierers mit dem Rahmen des SAP GUIs. Die APO Optimization Extension Workbench verwendet hier Microsofts ActiveX-Technologie. Der vom SAP GUI erzeugte Rahmen ist ein OCX-Container. Vom Entwickler des externen Optimierers muß eine OCX-Datei bereitgestellt werden. Über den GUI des OCX soll die Möglichkeit gegeben werden, Parameter wie etwa Horizonte oder Gewichte einer Zielfunktion einzugeben. Das Design des GUI, die Steuerung des Optimierungslaufes sowie die Darstellung des Ergebnisses (etwa anhand der errechneten Zielgrößen) obliegt vollständig dem Entwickler des externen Optimierers. Dies beinhaltet insbesondere die Möglichkeit, in dem OCX auch den externen Optimierer einzubetten. Dieser läuft dann auf dem Arbeitsplatzrechner ab. Andererseits kann aber auch durch den OCX (neben dem GUI) lediglich die Steuerung des Datenaustauschs zwischen dem betreffenden Arbeitsplatzrechner und einem zentral installierten, sogenannten Optimierungsserver, bereitgestellt werden. Die Ergebnisdarstellung in Form von Plantafeln oder anderen Grafiken soll weiterhin im APO erfolgen.

Customizing-Einstellungen pflegen

Im Customizing pflegen Sie, welche externen Optimierer für welche Komponenten von SAP APO bereitgestellt werden und unter welchem OCX-Schlüssel diese zu finden sind.

  1. Steigen Sie folgendermaßen in das Customizing ein: SAP MenüWerkzeugeBusiness EngineerCustomizing.
  2. Sie gelangen auf den Bildschirm Customizing: Projektbearbeitung.
  3. Wählen Sie die Drucktaste SAP Referenz-IMG
  4. Sie gelangen auf den Bildschirm Einführungsleitfaden anzeigen.
  5. Wählen Sie Advanced Planner and Optimizer (APO) Basis EinstellungenOptimierungOptimization Extension Workbench Stammdaten für Optimization Extension Workbench pflegen
  6. Sie gelangen auf die Sicht Optimization Extension Workbench Stammdaten ändern: Übersicht.
  7. Pflegen Sie die Tabelle wie unten beschrieben:

Feld   Vorgehensweise
Identifier   Geben Sie eine eindeutige Bezeichnung eines externen
  Optimierungsprogramms ein
Modul   Wählen Sie eines der APO-Module: Capable-to-Match,
  Produktions- und Feinplanung und Supply Network
  Planning.
Kurztext   Beschreibung des externen Optimierers
Status   Unterscheiden Sie zwischen
  Inaktiv: Der Optimierer ist inaktiv und kann daher nicht
  aufgerufen werden
  Aktiv: Der Optimierer ist aktiv
OCX Key   Geben Sie den Schlüssel an, unter dem der OCX des
  externen Optimierers auf dem jeweiligen Arbeitsplatz-
  rechner registriert ist.

Handhabung der Datenmodelle von SAP APO

Die APO Optimization Extension Workbench bedient sich der .Business Application Programming Interfaces (BAPIs), um in der Datenbank und im LiveCache gespeicherte Daten einem externen Optimierer zur Verfügung zu stellen. Damit können grundsätzlich alle von SAP APO bereitgestellten BAPIs auch von externen Optimierern verwendet werden.

BAPIs basieren auf sogenannten Geschäftsobjekten (.Business Objects). So sind beispielsweise Lokationen, Produkte, Ressourcen, PPMs und Aufträge aller Art typische Geschäftsobjekte von SAP APO. Diesen sind Methoden zugeordnet, die das Anlegen, Lesen, Ändern und Löschen von Instanzen dieser Objekte erlauben. Dabei werden eine Fülle von Attributen berücksichtigt, die diese Instanzen genauer beschreiben. Die Zuordnung dieser Attribute zu einzelnen Feldern, Strukturen der Datenbank oder des LiveCaches ist für die Benutzung der BAPIs nicht relevant. Derzeit ist vor allem das Geschäftsobjekt .ManufacturingOrderAPS (Produktionsauftrag) im Rahmen von APX im Einsatz. Dabei werden die folgenden Methoden verwendet:

  • SaveMultiple
    Erstellt neue bzw. ändert bestehende Produktionsaufträge. Dabei wird automatisch die Feinplanung gestartet, die im APO ein hier verwendbares PPM sucht und die zugehörigen Operationen und Aktivitäten unter Beachtung sämtlicher Restriktionen einplant.
  • ChangePeggingMultiple
    Erstellt, ändert oder löscht die Peggingbeziehungen zwischen den INPUT-Knoten des Auftrags und den OUTPUT-Knoten eines anderen Auftrages oder Bestandes. Es können auch die zugehörigen Attribute verändert werden.
  • GetList
    Ermittelt sämtliche Produktionsaufträge, die einem vorgegebenen Selektionskriterium genügen. Dabei werden nicht nur die Attribute des Auftragskopfes sondern auch alle Ein- und Ausgabeprodukte mit ihren Merkmalsausprägungen sowie die zugehörigen Peggingbeziehungen gelesen.
  • DeleteMultiple
    Löscht einen oder mehrere Produktionsaufträge. Dabei werden auch sämtliche zugehörigen Operationen und Aktivitäten gelöscht.

Handhabung benutzerspezifischer Daten

Für die Verwendung des externen Optimierers wird es immer wieder notwendig sein, benutzerspezifischer Daten einzubeziehen. Da es nicht sinnvoll ist, zu deren Speicherung eine weitere (externe) Datenbank aufzubauen wird die Möglichkeit gegeben, die bestehenden APO Datenbanken zu ergänzen. Dafür gibt es grundsätzlich zwei Möglichkeiten:

  1. Zusätzliche Daten können als Merkmale einzelner Produkte modelliert werden. Dies ist Bestandteil des .merkmalsbasierten Planens (.characteristics dependent planning, CDP) im APO. Die Merkmale werden mit Hilfe der Standard-APO-Funktionalität implementiert und können dann vom externen Optimierer über die Standard-BAPIs abgefragt werden.
  2. Wenn es nicht möglich ist, zusätzliche Informationen als Merkmale der Produkte abzubilden, kann die Datenbankstruktur von SAP APO erweitert werden. Hierfür gibt es wiederum zwei verschiedene Vorgehensweisen:
    1. Bestehende Datenbanktabellen können durch Hinzufügen neuer Spalten erweitert werden. Derartige Erweiterungen betreffen vor allem Tabellen zu Ressourcen, PPMs, Aufträgen und allen anderen Elementen, denen Business Objekte zugeordnet sind. Auf die in diesen Spalten gespeicherten Daten kann dann mit den Methoden der jeweiligen Business-Objekte zugegriffen werden. Dazu führen diese Methoden an ihren Schnittstellen ExtensionIn- und ExtensionOut-Parameter mit. Hierbei handelt es sich um .Container, die den individuellen Tabellenerweiterungen und modifikationen Rechnung tragen.
    2. Wenn die zusätzlichen Informationen nicht unmittelbar den Business-Objekten zugeordnet werden können, dann müssen diese in separaten Tabellen modelliert und gespeichert werden. Während das Anlegen und Handhaben dieser Tabellen wiederum zur SAP-Basistechnologie gehört (siehe die Transaktionen .se11 und .se16) wird der Zugriff auf ihren Inhalt von einem externen Optimierer aus durch einen speziellen Baustein der APO Optimization Extension Workbench umgesetzt.

Beispiel: Benutzerspezifische Tabellen

Die Tabelle .KOMPATIBLE_STAHLTYPEN ist ein Beispiel für den oben unter 2b beschriebenen Fall:

Stahl Typ   Kompatibler Stahltyp   Grad der Kompatibilität
A60   A61   1
A60   A65   1
A60   B82   3
A60   B92   3
A60   A60   1
A60   A65   2

Hier werden einander kompatible Stahltypen beschrieben. Wird in einem Stahlwerk in einer gegebenen Schmelze gerade ein Stahl vom Typ .B82 gefertigt, so kann ein Optimierer beispielsweise wählen, ob für einen Kundenauftrag zum Stahltyp .A60 eine neue Schmelze angesetzt oder der kompatible (d.h. in der Regel der hochwertigere) Stahltyp .B82 verwendet werden soll. Der Grad der Kompatibilität ist ebenfalls angegeben.

Während der Stahltyp eines Produktes noch als Merkmal modelliert werden kann, sind die oben beschriebenen Informationen nur in einer separaten Tabelle effizient darstellbar.

Anlegen und pflegen benutzerspezifischer Tabellen

Die Namen benutzerspezifischer Tabellen, die von externen Optimierern verwendet werden sollen, müssen mit dem Kürzel .YAPX_ oder .ZAPX_ beginnen, d.h. die Tabellen liegen im Kundennamensraum und sind APX zugeordnet. Angelegt werden die Tabellen mit der Transaktion .se11.Tabelleninhalte werden mit der Transaktion .se16 angelegt, geändert oder gelöscht.

Zugriff auf benutzerspezifische Tabellen

Ein externer Optimierer kann auf Tabellen im Namensraum .YAPX_ oder .ZAPX_ mit dem Funktionsbaustein ./SAPAPO/APX_GET_ANY_TABLE zugreifen. Dieser ist per RFC (remote function call) von Visual Basic, C++ und Java-Programmen aufrufbar.

Als Eingabeparameter erwartet APX_GET_ANY_TABLE ausschließlich den Namen der zu lesenden Tabelle.

Eingabeparameter   Typ   Länge
TAB_NAME   CHAR   30

Die Ausgabe besteht aus einer ABAP-Struktur und drei Tabellen. Die Struktur beinhaltet grundsätzliche Informationen über die zu lesende Tabelle:

Ergebnisparameter   Typ   Länge
TAB_INFO
TAB_NAME   CHAR   30
NUMBER_OF_COLUMNS   INT1   3
NUMBER_OF_LINES   INT4   10

Der erste Eintrag bestätigt lediglich den Tabellennamen TAB_NAME, der bereits als Eingabeparameter übergeben wurde. Im folgenden wird unter «TAB_NAME» die Tabelle verstanden, deren Name in TAB_NAME abgelegt ist (also die zu lesende Tabelle). Die weiteren Parameter geben die Anzahl der Spalten und Zeilen von «TAB_NAME» wieder.

In der Tabelle .TAB_STRUCTURE wird die Struktur der Tabelle «TAB_NAME», d. h. ihre Felder und der jeweilige Feldtyp beschrieben. Das sind die aus dem ABAP-Dictionary erhältlichen Informationen. TAB_STRUCTURE ist wie folgt aufgebaut:

Ergebnisparameter   Typ   Länge
TAB_STRUCTURE
FIELD_NAME   CHAR   30
FIELD_TYPE   CHAR   1
FIELD_LENGTH   NUMC   6
FIELD_DECIMALS   NUMC   6

Das Feld FIELD_NAME beinhaltet die in der Transaktion .se11 beim Anlegen der Tabelle «TAB_NAME» genannten Feldnamen. FIELD_TYPE ist der ABAP Datentyp des jeweiligen Feldes. Im einzelnen können die folgenden Belegungen auftreten:

C   Zeichen (Character)
N   numerischer Text
D   Datum (Date: YYYYMMDD)
T   Zeitpunkt (Time: HHMMSS)
X   Byte (heXadecimal)
I   ganze Zahl (Integer)
P   gepackte Zahl (Packed)
F   Gleitpunktzahl (Float)
S   Zeichenfolge (String)
x   Bytefolge (X-String)

Die Felder FIELD_LENGTH und FIELD_DECIMALS geben die Länge und die Anzahl der Nachkommastellen des betreffenden Feldes der Tabelle «TAB_NAME» an.

Die Tabelle .TAB_CONTENTS gibt schließlich den Inhalt von «TAB_NAME» wieder. Dazu wird jeder Datensatz von «TAB_NAME» Feld für Feld in TAB_CONTENTS übernommen. Jeder Datensatz von TAB_CONTENTS repräsentiert ein Feld von «TAB_NAME». Die Reihenfolge der Datensätze entspricht derjenigen in TAB_STRUCTURE.

Die Tabelle TAB_CONTENTS selbst besteht aus drei Feldern:

Ergebnisparameter   Typ   Länge   Dezimalstellen
TAB_CONTENTS
STRING_LIKE   CHAR   128
FLOAT_LIKE   FLTP   16   16
INTEGER_LIKE   INT4   10
TO_BE_CONTINUED   CHAR   1

Der Typ des Datenfeldes (FIELD_TYPE aus TAB_STRUCTURE) entscheidet darüber, welches Feld von TAB_CONTENTS gefüllt wird. Gepackte Zahlen werden wie Gleitkommazahlen übertragen. Auch ganze Zahlen werden nicht transformiert. Alle übrigen Daten werden als Zeichenfolgen dargestellt.

Eine Besonderheit betrifft die Übertragung von Zeichenfolgen und Bytefolgen, die in ABAP eine beliebige Länge haben können. Ist diese größer als 128 Byte dann werden sie in ein oder mehrere Teile gesplittet. In diesem Fall ist das Feld TO_BE_CONTINUED mit einem X gefüllt. Der nächste Datensatz von TAB_CONTENTS ist dann also die Fortsetzung des Inhaltes des langen Datenfeldes aus «TAB_NAME». Dies ist beliebig häufig hintereinander möglich.

Im folgenden wird am oben bereits erwähnten Beispiel der Tabelle KOMPATIBLE_STAHLTYPEN der Inhalt der übergebenen Datenstrukturen verdeutlicht.

Beispiel: Lesen der Tabelle .KOMPATIBLE_STAHLTYPEN

Die Variable TAB_NAME hat den Inhalt KOMPATIBLE_STAHLTYPEN. Dann liefert der Aufruf von ./SAPAPO/APX_GET_ANY_TABLE die folgenden Ergebnisse:

TAB_INFO-TAB_NAME = KOMPATIBLE_STAHLTYPEN

TAB_INFO-NUMBER_OF_COLUMNS = 3

TAB_INFO-NUMBER_OF_LINES = 79

TAB_STRUCTURE

FIELD_NAME FIELD_TYPE   FIELD_LENGTH   FIELD_DECIMALS
STAHLTYP C   3   -
KOMPATIBLER_STAHLTYP C   3   -
KOMPATIBILITÄTSGRAD I   2   -

TAB_CONTENTS,,

N_C_D_T_X_S_x   P_F   I   TO_BE_CONTINUED
A60   -   -   -
A61   -   -   -
-   -   1   -
A60   -   -   -
A65   -   -   -
-   -   1   -
A60   -   -   -
A82   -   -   -
-   -   3   -
...   ...   ...   ...

Planungsszenarios in SAP APO

Allgemeines

Die Integration externer Optimierer in SAP APO ist unabhängig von den einzelnen Komponenten. Die Anwendungen zum taktischen Planen (Supply Network Planning, Transportation Planning, etc.) sowie zum operationalen Planen (Production Planning and Detailed Scheduling, Vehicle Scheduling) sind gleichermaßen betroffen.

In diesen Komponenten gibt es wiederum vier verschiedene Möglichkeiten der Planung:

  1. Standard-Heuristiken
    Standard-Heuristiken berechnen in kürzester Zeit einen umsetzbaren, d.h. unter Berücksichtigung der gegebenen APO Randbedingungen fehlerfreien, Plan. Da das System möglichst schnell zu einem Ergebnis kommen soll, werden vor allem lokale und keine globalen Optimierungskriterien beachtet. Sie sind in ABAP implementiert.
  2. Standard-Optimierer
    Optimierer verbessern die von den Heuristiken berechneten Ergebnisse. Hierzu werden globale Optimierungskriterien wie beispielsweise die gesamte Produktionszeit, die Summe aller Rüstkosten oder die durchschnittliche Verspätung herangezogen. Die Planung selbst findet im Hintergrund statt. Je nach der Größe des Problems kann sie im Minuten- aber auch im Stundenbereich liegen. Da Optimierungsalgorithmen wegen ihrer Komplexität für gewöhnlich hohe Laufzeiten haben sind sie in C++ implementiert.
  3. Benutzerspezifische Heuristiken
    Der Anwender kann natürlich auch eigene, auf sein spezifisches Problem angepaßte Heuristiken entwickeln oder entwickeln lassen. Das erfolgt wie bei den Standard-Heuristiken in der ABAP Programmierumgebung.
  4. Benutzerspezifische Optimierer
    Wie in dieser Release-Information beschrieben, bietet die APO Optimization Extension Workbench die Möglichkeit, individuell für den Benutzer entwickelte Optimierungsalgorithmen in SAP APO einzubinden.

SAP APO ermöglicht eine Integration dieser unterschiedlichen Planungsalgorithmen in einem Planungssystem, so daß sämtliche Anforderungen des Kunden erfüllt werden. Dazu können die Algorithmen in einer beliebigen Reihenfolge gestartet und jeweils entweder das gesamte Planungsproblem oder nur ein Teil (bezogen auf die betrachteten Ressourcen / Lokationen und den betrachteten Zeitraum) bearbeitet werden. Die möglichen Planungsszenarios können hier wiederum individuell an den Anwender angepaßt werden.

Im folgenden wird ein derartiges Szenario an einem Beispiel erläutert.

Beispiel: Sequenzoptimierung in der Stahlindustrie

Zur Veranschaulichung eines möglichen Planungsszenarios soll folgendes, vereinfachtes Beispiel aus der Stahlindustrie dienen.

Aus dem Stahlwerk kommende Brammen (Blöcke ungewalzten Stahls) werden zunächst auf einer Warmwalzstraße zu einem, wenige Millimeter starkem, Bandstahl gewalzt. In weiteren Arbeitsschritten (beispielsweise dem Eloxieren, Galvanisieren, Verzinken, Beschichten etc.) kann der Bandstahl veredelt werden. Auf der Warmwalzstraße können zwar grundsätzlich Aufträge in beliebiger Reihenfolge bearbeitet werden, der Anlagenverschleiß wird allerdings unter Beachtung bestimmter Randbedingungen erheblich verringert. Zur Berechnung der idealen Auftragsreihenfolge wird daher ein spezieller Sequenzoptimierer herangezogen, der mit Hilfe der Optimization Extension Workbench in den APO integriert wird.

Zu den Randbedingungen gehört insbesondere die Forderung nach möglichst kleinen Sprüngen in Breite und Dicke des gewalzten Bleches von einem Walzvorgang zum nächsten. Die Breite der Bleche soll zunächst anwachsen und dann langsam wieder abfallen. Die Dicke der Bleche unterliegt Schwankungen, die allerdings weitestgehend vermieden werden sollten.

In einer Zielfunktion werden die einzelnen Breiten- und Dickeschwankungen summiert. Die beste Sequenz ist die, bei der die Zielfunktion das kleinste Ergebnis aufweist. Kommen zu der Summe der Schwankungen in Dicke und Breite noch unterschiedliche Gewichtungen hinzu, die der Benutzer modifizieren kann, so hat dieser die Möglichkeit, das Ergebnis hinsichtlich der einen oder anderen Randbedingung zu verändern.

  1. Für die Produktionsplanung des gesamten Werkes gibt es nun verschiedene Möglichkeiten (Szenarios): Im Rahmen einer Rückwärtsplanung werden, ausgehend von den Kundenaufträgen, zunächst die Operationen auf den letzten Aggregaten so eingeplant, daß das Fälligkeitsdatum dem Liefertermin entspricht. Damit wird weder durch eine zu frühe Fertigstellung des Produkts ein Bestand aufgebaut, noch wird durch eine Verspätung die Kundenzufriedenheit in Frage gestellt. Plant das System auf diese Weise weiter rückwärts, so ergibt sich letztlich auf dem ersten Aggregat, der Warmwalzstraße, eine Reihenfolge von Operationen, die in der Regel einen hohen Maschinenverschleiß bedingt. Die Reihenfolge genügt mit hoher Wahrscheinlichkeit nicht den speziellen Randbedingungen, deren Einhaltung einen minimierten Maschinenverschleiß zur Folge hätten. Eine hohe Anzahl von Umrüstzeiten kennzeichnet den häufigen Wechsel verschlissener Maschinenteile.
  2. Ausgangssituation eines zweiten Szenarios ist eine vorgegebene Reihenfolge von Operationen auf der Warmwalzstraße. Diese kann entweder direkt aus den gegebenen Kundenaufträgen abgeleitet oder mit Durchführung von Schritt 1 ermittelt werden.
    Diese Reihenfolge wird nun mit dem Sequenzoptimierer unter Berücksichtigung der zusätzlichen Randbedingungen und somit unter Minimierung des Maschinenverschleißes geändert. Eine anschließende Vorwärtsplanung sorgt dafür, daß nachfolgende Operationen gemäß der jeweiligen Anordnungs- oder Peggingbeziehungen eingeplant werden. Die Terminierung der Operationen auf den anderen Ressourcen richtet sich also nach der Reihenfolge der Operationen auf der Warmwalzstraße. Da der Sequenzoptimierer die Lage der jeweils letzten Operationen zu einem Kundenauftrag nicht kennt, werden die Fälligkeitstermine in der Regel verletzt. Die Produkte werden entweder zu früh oder zu spät fertiggestellt.
  3. Wie die Szenarios 1 und 2 zeigen, gibt es eine klare Austauschbeziehung (Tradeoff) zwischen der Einhaltung der Kundentermine auf der einen Seite und einer optimalen Bearbeitungsreihenfolge der Operationen auf der Warmwalzstraße auf der anderen Seite. Die Beachtung aller Ziele kann durch eine kombinierte Anwendung beider Szenarios erreicht werden: Zunächst wird hier, wie in Szenario 1, eine Rückwärtsplanung durchgeführt. Die sich ergebende Lage der Operationen auf der Warmwalzstraße kann als ideal bezüglich der Einhaltung der Fälligkeitstermine angesehen werden. Jede Verschiebung einer dieser Operationen nach links macht es wahrscheinlicher, daß die Produktion für den zugehörigen Kundenauftrag zu früh fertig ist. Jede Verschiebung nach rechts verursacht wahrscheinlich eine Verspätung der Fertigstellung. Im Hinblick auf die Fälligkeitstermine sollten daher möglichst wenig Operationen und diese dann nicht weit auf der Warmwalzstraße verschoben werden. Die Summe aller Abstände der Operationen von ihrer ursprünglichen Lage kann als Maß der .Ähnlichkeit der vom Optimierer bestimmten Bearbeitungsreihenfolge zu der ursprünglichen Reihenfolge gesehen werden.
    Dieses Ähnlichkeitsmaß geht als Zielgröße zusätzlich in die Optimierung ein. Oben wurde bereits beschrieben, wie sich die Zielfunktion als Summe der einzelnen gewichteten Zielgrößen definiert. Das Ähnlichkeitsmaß kann als Zielgröße betrachtet werden und ist daher ebenfalls zu minimieren. Mit einem Gewicht versehen geht es in die Summe der indie Summe der restlichen Zielgrößen und somit in die Zielfunktion mit ein. Das Gewicht ist das zentrale Element, welches die Qualität des Endergebnisses beeinflußt. Ist es hoch, so wird zu Gunsten einer Einhaltung der Fälligkeitstermine die Operationsreihenfolge auf der Warmwalzstraße wenig verändert. Ist es niedrig, so wird vor allem die Reihenfolge optimiert.
    In einem weiteren Schritt kann man auch zwischen der Summe aller Verschiebungen nach links auf der Plantafel (in die Vergangenheit) und der nach rechts unterscheiden. Durch unterschiedliche Gewichtungen können Verschiebungen nach links bzw. rechts unterschiedlich bestraft werden. Je nachdem wird dann entweder eine zu frühe Fertigstellung der Kundenaufträge oder eine Verspätung zugelassen. Durch das Verändern der Gewichte kann auf diese Weise das Endergebnis der Planung hinsichtlich einer zu frühen Fertigstellung der Kundenaufträge, ihrer Verspätung oder einer schlechteren Reihenfolge der Operationen auf der Warmwalzstraße verändert werden.
    Vor allem die nach rechts auf der Plantafel verschobenen Operationen können eine Verletzung von Anordnungsbeziehungen zu nachfolgenden Operationen (auf anderen Ressourcen) mit sich führen. Um dies zu beheben und gleichzeitig auch den restlichen Plan zu optimieren ist es notwendig, die Belegung der restlichen Ressourcen mit dem PP/DS Optimierer des APO zu bestimmen. Die optimierte Operationsreihenfolge ist vorher zu fixieren. Die genannten Verletzungen werden so korrigiert.
    Zusammenfassend berechnet sich also ein optimaler Produktionsplan mit dem folgenden Szenario:
    1. Die Heuristik berechnet einen Vorschlag für die Beplanung der Anlagen.
    2. Der Sequenzbilder optimiert die Reihenfolge der Operationen auf der Warmwalzstraße unter Berücksichtigung der Anzahl aller Änderungen des ursprünglichen Plans.
    3. Der Standardoptimierer korrigiert evtl. aufgetretene Verletzungen von Anordnungsbeziehungen und optimiert die Belegung der restlichen Ressourcen.

Das Beispiel zeigt, wie durch ein Zusammenspiel von Standard-Heuristiken und benutzerspezifischen Optimierern ein Planungsproblem gelöst werden kann. Dieses Vorgehen steht exemplarisch für viele Probleme der Reihenfolgeoptimierung. Es gibt aber auch andere technologisch bedingte Aufgaben zur Optimierung einzelner Anlagen oder ganzer Betriebe unterschiedlichster Branchen. Zur Planung von Transporten unter besonderen Randbedingungen und Zielsetzungen, sowie zur Planung im mittel- und langfristigen Bereich ist die APO Optimization Extension Workbench in ähnlicher Weise einsetzbar.

Siehe auch

Für weitere Informationen über einzelne Basiskomponenten, deren Handhabung für die jeweilige APX-Funktionalität unerläßlich ist, siehe folgende Dokumente, Links und Schulungsverweise:

1. APO BAPIs Funktionsbausteindokumentation (SE80)
  Transaktion BAPI
  http://www.sapneth5.wdf.sap-ag.de:1080/bapi
2. Aufruf von BAPIs
a) BAPI OCX SAP-Bibliothek--> Basis--> Services
  Kommunikationsschnittstelle->Remote
  Communications
  -->SAP Automation
  http://sapnet.com/bapi-->COM section
  http://www.saptechjournal.com-->Archive
  Training: CA926 und CA927
b) DCOM Connector RFC SDK Kitab 4.5A (SAP Presentation CD):
  rfcsdk\ccwww
  http://sapnet.sap.com/connectors
  http://www.saptechjournal.com
  http://sapnet.sap.com/bapi
3. ABAP Dictionary
(se11) ABAP/4 Development Workbench: ABAP/4 Dictionary
  (Chapter 12: Maintaining Tables)
4. Data Brower
(se16) ABAP/4 Development Workbench: ABAP/4 Dictionary
5. Kundenerweiter-
ungen von BAPIS SAP-Bibliothek-->Basis-->Middleware-->BAPI
  BAPI Programmierleitfaden'-->Modifikationen
  und Eigenentwicklungen von Kunden.
6. Handhabung von SAP-Bibliothek-->Basis-->Services/Kommunikations-
RFCs schnittstelle-->Remote Communications
  http://www.saptechjournal.com
  Training: siehe 2a)






PERFORM Short Reference   rdisp/max_wprun_time - Maximum work process run time  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 48143 Date: 20240419 Time: 040518     sap01-206 ( 617 ms )