Geschäftslogik mit Übergangsattributen modellieren

In diesem Leitfaden werden mögliche Verwendungen von Übergangsattributen beschrieben. Anhand von zwei Beispielen erfahren Sie, wie Sie reale Szenarien modellieren: Sie beziehen die Zeit zum Parken des Fahrzeugs in die optimierten Routen ein und sorgen dafür, dass jede Route mit einem Besuch an einem bestimmten Ort endet.

Hinweis

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

Ein Übergang ist das Segment der Route, das einen Ort mit dem nächsten verbindet.

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

  • Der Startpunkt der Route.
  • Ein Halt, an dem eine Abholung oder Lieferung erfolgt.
  • 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 und wird mit Übergängen in den Routen abgeglichen. Dazu werden Tags am Start- und Endort des Übergangs verwendet. Weitere Informationen zu Übergangsattributen finden Sie in der Referenzdokumentation zu TransitionAttributes.

Reale Szenarien modellieren

In diesem Abschnitt werden zwei kleine Beispiele für die Implementierung realer Geschäftseinschränkungen mithilfe von Übergangsattributen gezeigt.

Parkzeit reservieren

In diesem Szenario muss der Fahrer das Fahrzeug parken, bevor er Ort A besuchen kann. Ort B befindet sich 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 zu einem anderen wechselt.

Wenn Sie die Parkdauer separat von der Besuchsdauer modellieren, können Sie Routen erstellen, bei denen Besuche, die denselben Parkplatz nutzen, gruppiert werden und weniger Zeit in Anspruch nehmen. Sie machen das Modell präziser und sorgen dafür, dass der Optimierer Routen bevorzugt, bei denen die Besuche gruppiert sind.

So gehen Sie bei einer Route Optimization API-Anfrage vor:

  1. Verwenden Sie VisitRequest.duration nur für die Zeit, die für den Besuch erforderlich ist. Beispiel: Das Paket übergeben und eine Unterschrift vom Kunden einholen.

  2. Verwenden Sie für jeden im Modell verwendeten Parkplatz 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 Besuchsanfragen, die diesen Parkplatz verwenden.

    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 zu ShipmentModel.transition_attributes hinzu, der eine Verzögerung für das Parken hinzufügt, 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 für TransitionAttributes.delay die Zeit fest, die zum Parken des Fahrzeugs benötigt wird.

    Wenn das Tag eines Standorts beispielsweise PARKING_123 lautet 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 Reinigungseinrichtung, bevor das Fahrzeug zum Depot zurückkehrt. Für die optimierte Route wird die beste Reinigungseinrichtung basierend auf ihrem Standort und den Standorten der Abholungen und Lieferungen des Fahrzeugs verwendet.
  • Nach der Reinigung darf das Fahrzeug keine weiteren Abholungen oder Lieferungen durchführen.
  • Die Zeit für die Fahrt dorthin und die Reinigung des Fahrzeugs wird auf die Arbeitszeit des Fahrers angerechnet und muss in die maximale Dauer der Route passen.

Sie modellieren diese Anforderung, indem Sie nur Routen zulassen, die entweder leer sind oder deren letzter Besuch eine Reinigungsanlage ist. In der Route Optimization API können Sie dies tun, indem Sie Übergänge zum Endwegpunkt der Route von allen Standorten außer der Reinigungsanlage oder dem Startpunkt der Route verbieten:

  1. Wählen Sie zwei neue Tags aus, die nirgendwo im Modell verwendet werden, z. B. CLEANED und ROUTE_END. Ersteres gilt für Orte, an denen das Fahrzeug sauber ist oder wird, und Letzteres für das Ende der Route.
  2. Fügen Sie für jedes Fahrzeug eine neue reine Lieferlieferung hinzu, die den Besuch einer Reinigungsanlage mit den folgenden Attributen darstellt:
    1. Jeder Standort einer Reinigungseinrichtung sollte als Lieferanfrage für diese Sendung dargestellt werden.
    2. Fügen Sie CLEANED zu VisitRequest.tags jeder Besuchsanfrage der Sendung an die Reinigungseinrichtung hinzu. Es signalisiert, dass ein Fahrzeug, das diesen Ort verlässt, sauber ist. Andere Besuchsaufträge im Modell sollten dieses Tag nicht verwenden, damit das Fahrzeug beim Verlassen als „nicht sauber“ gilt.
    3. Lassen Sie den Optimierer diese Sendung überspringen, wenn das Fahrzeug anderweitig nicht verwendet wird, indem Sie die penalty_cost auf eine kleine Zahl setzen.

  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 ausführt. Es wird davon ausgegangen, dass es am Ende des vorherigen Arbeitstags gereinigt wurde. Das Fahrzeug kann dann direkt vom Startwegpunkt zum Endwegpunkt fahren. Auch wenn solche Routen in der Praxis nicht vorkommen, hilft die Berücksichtigung dieses Szenarios dem Optimierer, effizienter nach optimierten Routen zu 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 Endwegpunkt 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 großen Wert fest. Wenn Sie die Verzögerung länger als die maximale Routendauer festlegen, verhindern Sie, dass der Optimierer 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 überall 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 Wahl 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, um harte Einschränkungen zu implementieren oder einen Kompromiss in Bezug auf die aufgewendete Zeit zu finden. TransitionAttributes.cost eignet sich besser, wenn weiche Präferenzen oder Kompromisse implementiert werden sollen, die als zusätzliche Kosten ausgedrückt werden. Sie können Verzögerungen und Kosten beliebig kombinieren, wenn sowohl Zeitaufwand als auch Kosten eine Rolle spielen.

Im Beispiel für die Fahrzeugreinigung wird eine sehr lange Verzögerung verwendet, da die Reinigung des Fahrzeugs am Ende der Route eine harte Anforderung ist und die lange Verzögerung verhindert, dass der Optimierer die Anforderung ignoriert. Wenn Sie nur Kosten festlegen, kann der Optimierer die Reinigung überspringen, wenn er eine Möglichkeit findet, die Kosten an anderer Stelle auszugleichen, z. B. indem er mehr Lieferungen in der Zeit ausführt, die durch das Auslassen der Reinigung des Fahrzeugs „eingespart“ wird.

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

Übergangsattribut hinzufügen, das mit allen Besuchsanfragen übereinstimmt

In den obigen Beispielen werden Übergangsattribute verwendet, die mit Standorten übereinstimmen, die ein bestimmtes Tag haben, oder mit Standorten, die das Tag 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 entweder TransitionAttributes.src_tag oder TransitionAttributes.excluded_src_tag und entweder TransitionAttributes.dst_tag oder TransitionAttributes.excluded_dst_tag enthalten muss.

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 jedoch absichtlich ein Tag ausgewählt haben, das von keinem Standort verwendet wird, werden diese Übergangsattribute mit allen Standorten abgeglichen.

Weitere Informationen