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 berücksichtigen die Zeit zum Parken des Fahrzeugs in den optimierten Routen und sorgen dafür, dass jede Route mit einem Besuch eines bestimmten Standorts 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 Übergabedauern und Kosten addiert, die anhand der Kartendaten und der Parameter des verwendeten Fahrzeugs berechnet werden.

Ein Übergang 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.
  • Eine Haltestelle, an der 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 mithilfe von Tags am Start- und Endpunkt des Übergangs mit Übergängen in den Routen abgeglichen. Weitere Informationen zu Übergangsattributen finden Sie in der Referenzdokumentation zu TransitionAttributes.

Reale Szenarien modellieren

In diesem Abschnitt finden Sie zwei kleine Beispiele dafür, wie Sie reale Geschäftseinschränkungen mithilfe von Übergangsattributen implementieren.

Zeit fürs Parken reservieren

In diesem Szenario muss der Fahrer das Fahrzeug parken, bevor er Standort A aufsuchen kann. Standort B ist in der Nähe und der Fahrer kann für beide Fahrten 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 mithilfe von Übergangsattributen zusätzliche Zeit für das Parken des Fahrzeugs hinzufügen, nur wenn der Fahrer von einem Parkplatz zum anderen fährt.

Wenn Sie die Parkzeit separat von der Besuchsdauer modellieren, werden Routen, bei denen Besuche, die denselben Parkplatz nutzen, gruppiert werden, kürzer. Sie präzisieren das Modell und legen fest, dass der Optimierer Routen bevorzugt, bei denen die Besuche gruppiert sind.

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

  1. Verwenden Sie VisitRequest.duration nur für die Zeit, die für den Besuch erforderlich ist. Beispielsweise, um das Paket zu übergeben und eine Unterschrift des Kunden einzuholen.

  2. Verwenden Sie für jeden einzelnen im Modell verwendeten Parkplatz ein neues Tag, das im Modell nicht für andere Zwecke verwendet wird, z. B. PARKING_123.

  3. Fügen Sie dieses Tag Folgendem hinzu:

    1. VisitRequest.tags in allen Besuchsanfragen, bei 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 endet.

  4. Fügen Sie für jedes neue Park-Tag einen Eintrag zu ShipmentModel.transition_attributes hinzu, der eine Verzögerung beim Parken hinzufügt, wenn Sie von einem anderen Parkplatz kommen. Gehen Sie dazu so vor:

    1. Legen Sie TransitionAttributes.excluded_src_tag und TransitionAttributes.dst_tag auf PARKING_123 fest.

    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 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 Depot zurückkehrt. Für die optimierte Route wird die beste Reinigungsstation 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, die für die Fahrt dorthin und das Reinigen des Fahrzeugs benötigt wird, 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 Reinigungsstation war. In der Route Optimization API können Sie das so festlegen, dass Übergänge zum Endpunkt der Route von allen Orten außer von der Reinigungsstation oder vom Startpunkt der Route aus verboten werden:

  1. Wählen Sie zwei neue Tags aus, die im Modell nirgends verwendet werden, z. B. CLEANED und ROUTE_END. Ersteres ist für Standorte, an denen das Fahrzeug sauber ist oder wird, und letzteres für das Ende der Route.
  2. Fügen Sie für jedes Fahrzeug einen neuen Versand mit der Option „Nur Lieferung“ hinzu, der den Besuch einer Reinigungsanlage darstellt. Geben Sie dabei die folgenden Attribute an:
    1. Jeder Standort der Reinigungseinrichtung sollte als Zustellauftrag für diese Sendung dargestellt werden.
    2. Fügen Sie CLEANED zu VisitRequest.tags der einzelnen Besuchsanfragen der Lieferung der Reinigungsanlage hinzu. Sie signalisiert, dass ein Fahrzeug, das diesen Standort verlässt, sauber ist. Andere Besuchsanfragen im Modell sollten dieses Tag nicht verwenden, damit das Fahrzeug beim Verlassen als „nicht sauber“ eingestuft wird.
    3. Sie können dem Optimierer erlauben, diese Lieferung zu überspringen, wenn das Fahrzeug anderweitig nicht genutzt wird. Legen Sie dazu für penalty_cost eine kleine Zahl fest.

  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, vorausgesetzt, es wurde am Ende des vorherigen Arbeitstages gereinigt. Es kann dann vom Start- zum Zielpunkt fahren. Auch wenn solche Routen in der Praxis nicht vorkommen, hilft dieses Szenario 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 Fahrzeugen verbietet, den Endpunkt des Fahrzeugs zu erreichen, wenn sie nicht sauber sind. Verwenden Sie dazu die folgenden Properties:

    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, verhindert das den Optimierungsalgorithmus effektiv daran, diese Überleitung in einer Route zu verwenden.

    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 von einer Reinigungsstation und dem Startpunkt der Route aus zu verhindern:

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

Verzögerungen und Kosten abwägen

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

Im Beispiel für die Fahrzeugreinigung wird eine sehr lange Verzögerung verwendet, da die Reinigung des Fahrzeugs am Ende der Route eine strenge Anforderung ist und die lange Verzögerung verhindert, dass der Optimierer die Anforderung ignoriert. Wenn Sie nur einen Kostenwert festlegen, kann der Optimierer die Reinigung überspringen, wenn er eine Möglichkeit findet, die Kosten anderweitig auszugleichen, z. B. durch die Lieferung mehrer Sendungen in der Zeit, die durch das Nichtreinigen des Fahrzeugs „gespart“ 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 Kosten auch in Kombination mit Verzögerungen verwenden, wenn der Fahrer an einem kostenpflichtigen Parkplatz hält.

So fügen Sie ein Übergangsattribut hinzu, das mit allen Besuchsanfragen übereinstimmt

In den Beispielen oben werden Übergangsattribute verwendet, die mit Standorten mit einem bestimmten Tag oder Standorten ohne das Tag übereinstimmen. Was aber, wenn Sie Übergängen Attribute hinzufügen möchten, die auf alle Übergänge angewendet werden sollen?

Die Tags können nicht einfach weggelassen werden, da jede TransitionAttributes-Nachricht einen der folgenden Werte für TransitionAttributes.src_tag und TransitionAttributes.excluded_src_tag sowie einen der folgenden Werte für TransitionAttributes.dst_tag und 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 im Modell nirgends verwendet wird. Dies führt zu einer Übereinstimmung mit allen Standorten, die dieses Tag nicht haben. Da Sie jedoch bewusst ein Tag ausgewählt haben, das von keinem Standort verwendet wird, werden diese Übergangsattribute mit allen Standorten abgeglichen.

Weitere Informationen