Geschäftslogik mit Übergangsattributen modellieren

In diesem Leitfaden werden mögliche Anwendungsfälle für Übergangsattribute beschrieben. Darin wird anhand von zwei Beispielen gezeigt, wie Sie reale Szenarien modellieren können: Berücksichtigung der Parkzeit des Fahrzeugs in den optimierten Routen und Sicherstellung, dass jede Route mit einem Besuch an einem bestimmten Ort endet.

Hinweis

Mit Übergangsattributen können Sie bestimmten Übergängen in den optimierten Routen modellbezogene Kosten und Verzögerungen hinzufügen. Diese Kosten und Verzögerungen werden zusätzlich zu den Übergangsdauern und Kosten berechnet, die anhand der Kartendaten basierend auf den Parametern des verwendeten Fahrzeugs ermittelt werden.

Eine Transition ist das Segment der Route, das einen Ort mit dem nächsten verbindet.

Ein Standort bezieht sich auf einen der folgenden Punkte auf der Route eines Fahrzeugs:

  • Der Startpunkt der Route.
  • Ein Stopp, an dem etwas abgeholt oder geliefert wird.
  • Der Endpunkt der Route.

Sie definieren alle Übergangsattribute für das Modell, indem Sie sie der Liste ShipmentModel.transition_attributes hinzufügen. Jedes Element der Liste definiert einen Satz von Übergangsattributen. Es wird mit Übergängen in den Routen abgeglichen, indem Tags für den Start- und Endpunkt des Übergangs verwendet werden. Weitere Informationen zu Übergangsattributen finden Sie in der Referenzdokumentation zu TransitionAttributes.

Reale Szenarien modellieren

In diesem Abschnitt finden Sie zwei kleine Beispiele für die Implementierung von realen geschäftlichen Einschränkungen mithilfe von Übergangsattributen.

Zeit für das Parken reservieren

In diesem Szenario muss der Fahrer das Fahrzeug parken, bevor er Standort A besuchen kann. Ort B liegt in der Nähe und der Fahrer kann für beide Besuche denselben Parkplatz nutzen. Wenn der Fahrer B direkt nach A besucht, spart er Zeit, da er den Parkplatz nicht verlassen und das Fahrzeug nicht noch einmal parken muss. In der Route Optimization API können Sie Übergangsattribute verwenden, um zusätzliche Zeit für das Parken des Fahrzeugs hinzuzufügen, wenn der Fahrer von einem Parkplatz zum anderen fährt.

Wenn Sie die Parkzeit separat von den Besuchszeiten modellieren, dauern Routen, bei denen Besuche mit demselben Parkplatz gruppiert werden, weniger lange. Sie machen das Modell präziser und sorgen dafür, dass der Optimierer Routen bevorzugt, bei denen die Besuche gruppiert sind.

Führen Sie dazu die folgenden Schritte in einer Route Optimization API-Anfrage aus:

  1. Verwenden Sie VisitRequest.duration nur für die Dauer des Besuchs. Beispiel: Übergabe des Pakets und Einholung der Unterschrift des Kunden.

  2. Verwenden Sie für jeden einzelnen Parkplatz, der im Modell verwendet wird, ein neues Tag, das für nichts anderes im Modell verwendet wird, z. B. PARKING_123.

  3. Fügen Sie dieses Tag den folgenden Elementen hinzu:

    1. VisitRequest.tags in allen Besuchsanträgen, in denen dieser Parkplatz verwendet wird.

    2. Vehicle.start_tags, wenn das Fahrzeug seine Route an diesem Parkplatz beginnt.

    3. Vehicle.end_tags, wenn das Fahrzeug seine Route an diesem Parkplatz beginnt oder beendet.

  4. Fügen Sie für jedes neue Park-Tag einen Eintrag in ShipmentModel.transition_attributes ein, um eine Verzögerung für das Parken hinzuzufügen, wenn Sie von einem anderen Parkplatz kommen. Gehen Sie dazu so vor:

    1. Setzen Sie TransitionAttributes.excluded_src_tag und TransitionAttributes.dst_tag auf PARKING_123.

    2. Legen Sie TransitionAttributes.delay auf die Zeit fest, die zum Parken des Fahrzeugs benötigt wird.

    Wenn das Tag eines Standorts beispielsweise PARKING_123 ist und das Parken des Fahrzeugs 150 Sekunden dauert, fügen Sie ShipmentModel.transition_attributes den folgenden Eintrag hinzu:

    {
  "excluded_src_tag": "PARKING_123",
  "dst_tag": "PARKING_123",
  "delay": "150s"
}

Obligatorische Reinigung am Ende der Route

In diesem Szenario muss das Fahrzeug am Ende der Route gereinigt werden. Dabei gelten die folgenden zusätzlichen Einschränkungen:

  • Die Reinigung erfolgt in einer speziellen Reinigungsanlage, bevor das Fahrzeug zum Fahrzeugdepot zurückgebracht wird. Bei der optimierten Route wird die beste Reinigungsanlage basierend auf ihrem Standort und den Standorten der Abholungen und Lieferungen des Fahrzeugs verwendet.
  • Nach der Reinigung dürfen mit dem Fahrzeug keine weiteren Abholungen oder Lieferungen erfolgen.
  • Die Fahrzeit zum Zielort und die Zeit für die Reinigung des Fahrzeugs werden auf die Arbeitszeit des Fahrers angerechnet und müssen in die maximale Dauer der Route passen.

Sie modellieren diese Anforderung, indem Sie nur Routen zulassen, die entweder leer sind oder deren letzter Besuch in einer Reinigungsanlage erfolgt. In der Route Optimization API können Sie dies tun, indem Sie Übergänge zum End-Waypoint der Route von jedem Ort außer von der Reinigungsanlage oder vom Startpunkt der Route aus verbieten:

  1. Wählen Sie zwei neue Tags aus, die nirgendwo im Modell verwendet werden, z. B. CLEANED und ROUTE_END. Die erste ist für Orte, an denen das Fahrzeug gereinigt wird oder wurde, die zweite für das Ende der Route.
  2. Fügen Sie für jedes Fahrzeug eine neue Sendung nur für die Lieferung hinzu, die den Besuch einer Reinigungsanlage mit den folgenden Attributen darstellt:
    1. Jeder Standort einer Reinigungsanlage sollte als Zustellungsanfrage für diese Sendung dargestellt werden.
    2. Fügen Sie CLEANED zu VisitRequest.tags jeder Besuchs-Anfrage für die Reinigungseinrichtung hinzu. Es signalisiert, dass ein Fahrzeug, das diesen Ort verlässt, sauber ist. Bei anderen Besuchsanträgen im Modell sollte dieses Tag nicht verwendet werden, damit das Fahrzeug beim Verlassen als „nicht sauber“ gilt.
    3. Wenn Sie möchten, dass der Optimierer diese Sendung überspringt, wenn das Fahrzeug ansonsten nicht verwendet wird, setzen Sie den Wert für penalty_cost auf eine kleine Zahl.

  3. Fügen Sie für jedes Fahrzeug CLEANED zu Vehicle.start_tags hinzu. Damit wird das Fahrzeug als sauber markiert, bevor es Abholungen oder Lieferungen durchführt. Es wird davon ausgegangen, dass es am Ende des vorherigen Arbeitstags gereinigt wurde. So kann es direkt vom Start- zum End-Waypoint fahren. Auch wenn solche Routen in der Praxis nicht vorkommen, kann der Optimierer durch dieses Szenario effizienter nach optimierten Routen suchen.

  4. Fügen Sie für jedes Fahrzeug ROUTE_END zu Vehicle.end_tags hinzu.

  5. Fügen Sie ShipmentModel.transition_attributes einen neuen Eintrag hinzu, der verhindert, dass Fahrzeuge am End-Wegpunkt ankommen, wenn sie nicht sauber sind. Verwenden Sie dazu die folgenden Attribute:

    1. Legen Sie TransitionAttributes.excluded_src_tag auf CLEANED fest.

    2. Legen Sie TransitionAttributes.dst_tag auf ROUTE_END fest.

    3. Legen Sie für TransitionAttributes.delay einen hohen Wert fest. Wenn Sie die Verzögerung länger als die maximale Routendauer festlegen, verhindern Sie effektiv, dass das Optimierungsprogramm diesen Übergang in einer Route verwendet.

    Wenn die Zeitskala des Modells beispielsweise ein Arbeitstag ist, können Sie eine Verzögerung von 24 Stunden (86.400 Sekunden) verwenden, um den Übergang zum Ende der Route von jedem Ort außer einer Reinigungsanlage und dem Start der Route zu verhindern:

    {
  "excluded_src_tag": "CLEANED",
  "dst_tag": "ROUTE_END",
  "delay": "86400s"
}

Zwischen Verzögerungen und Kosten wählen

Die Entscheidung zwischen Verzögerungen und Kosten hängt von der Art der implementierten Geschäftslogik und den Einschränkungen ab. Die Einstellung TransitionAttributes.delay eignet sich am besten für die Implementierung harter Einschränkungen oder um einen Kompromiss in Bezug auf den Zeitaufwand auszudrücken. TransitionAttributes.cost eignet sich besser für die Implementierung von weichen Präferenzen oder Kompromissen, die als zusätzliche Kosten ausgedrückt werden. Sie können Verzögerungen und Kosten beliebig kombinieren, wenn sowohl der Zeitaufwand als auch die Kosten berücksichtigt werden.

Im Beispiel zur Fahrzeugreinigung wird eine sehr lange Verzögerung verwendet, da die Reinigung des Fahrzeugs am Ende der Route eine wichtige Anforderung ist und die lange Verzögerung verhindert, dass der Optimierer die Anforderung ignoriert. Wenn Sie nur cost festlegen, kann der Optimierer die Reinigung überspringen, wenn er eine Möglichkeit findet, die Kosten anderweitig zu decken, z. B. indem er mehr Sendungen in der Zeit ausliefert, die durch die unterlassene Reinigung des Fahrzeugs „eingespart“ wird.

Im Beispiel für das Parken wird eine kurze Verzögerung verwendet, die der zusätzlichen Zeit entspricht, die zum Parken des Fahrzeugs benötigt wird. Sie können costs auch in Kombination mit Verzögerungen verwenden, wenn der Fahrer auf einem gebührenpflichtigen Parkplatz anhält.

Übergangsattribut hinzufügen, das allen Besuchsanträgen entspricht

In den obigen Beispielen werden Übergangsattribute verwendet, die mit Standorten übereinstimmen, die ein bestimmtes Tag haben oder nicht haben. Was aber, wenn Sie Übergangsattribute hinzufügen müssen, die für alle Übergänge gelten?

Sie können die Tags nicht einfach weglassen, da jede TransitionAttributes-Nachricht eines der folgenden Elemente enthalten muss: TransitionAttributes.src_tag und TransitionAttributes.excluded_src_tag sowie eines der folgenden Elemente: TransitionAttributes.dst_tag und TransitionAttributes.excluded_dst_tag.

Sie können jedoch alle Tags abgleichen, indem Sie TransitionAttributes.excluded_src_tag oder TransitionAttributes.excluded_dst_tag auf ein Tag festlegen, das nirgendwo im Modell verwendet wird. Dadurch werden alle Standorte abgeglichen, die dieses Tag nicht haben. Da Sie aber absichtlich ein Tag ausgewählt haben, das von keinem Standort verwendet wird, werden alle Standorte abgeglichen.

Weitere Informationen