Geschäftslogik mit Übergangsattributen modellieren

In diesem Leitfaden werden mögliche Anwendungsfälle für Übergangsattribute beschrieben. Anhand von zwei Beispielen erfahren Sie, wie Sie reale Szenarien modellieren können: Berücksichtigen der Zeit für das Parken des Fahrzeugs in den optimierten Routen und Sicherstellen, 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 zusätzlich zu den Übergangszeiten und Kosten hinzugefügt, 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 Ort bezieht sich auf einen der folgenden Punkte auf der Route eines Fahrzeugs:

  • Startpunkt der Route
  • Haltestelle für eine Abholung oder Lieferung
  • 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 mithilfe von Tags für den Start- und Zielort des Übergangs abgeglichen. Weitere Informationen zu Übergangsattributen finden Sie unter der Referenzdokumentation für TransitionAttributes.

Reale Szenarien modellieren

In diesem Abschnitt werden zwei kleine Beispiele gezeigt, wie Sie reale geschäftliche Einschränkungen mithilfe von Übergangsattributen implementieren können.

Zeit für das Parken reservieren

In diesem Szenario muss der Fahrer das Fahrzeug parken, bevor er Ort A besuchen kann. Ort B liegt in der Nähe und der Fahrer kann denselben Parkplatz für beide Besuche 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 fährt.

Wenn Sie die Parkzeit getrennt von den Besuchszeiten modellieren, dauern Routen, bei denen Besuche mit demselben Parkplatz gruppiert sind, weniger Zeit. Sie machen das Modell präziser und sorgen dafür, dass der Optimizer 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 benötigt wird. Beispiel: Übergabe des Pakets und Einholen einer Unterschrift vom Kunden.

  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 Folgendem hinzu:

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

    2. Vehicle.start_tags , wenn die Route des Fahrzeugs an diesem Parkplatz beginnt.

    3. Vehicle.end_tags , wenn die Route des Fahrzeugs an diesem Parkplatz endet.

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

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

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

    Wenn das Tag eines Ortes beispielsweise PARKING_123 ist und das Parken des Fahrzeugs 150 Sekunden dauert, fügen Sie den folgenden Eintrag zu ShipmentModel.transition_attributes 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 spezialisierten Reinigungsanlage, bevor das Fahrzeug zum Fahrzeugdepot zurückkehrt. Die optimierte Route verwendet die beste Reinigungsanlage basierend auf ihrem Standort und den Standorten der Abholungen und Lieferungen, die vom Fahrzeug durchgeführt werden.
  • 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 in einer Reinigungsanlage erfolgt. In der Route Optimization API verbieten Sie dazu Übergänge zum End-Wegpunkt der Route von jedem Ort außer der Reinigungsanlage oder dem Startpunkt der Route:

  1. Wählen Sie zwei neue Tags aus, die nirgendwo im Modell verwendet werden, z. B. CLEANED und ROUTE_END. Das erste Tag steht für Orte, an denen das Fahrzeug gereinigt wird oder wurde, und das zweite für das Ende der Route.
  2. Fügen Sie für jedes Fahrzeug eine neue Lieferung nur für den Versand hinzu, die den Besuch in einer Reinigungsanlage darstellt, mit den folgenden Attributen:
    1. Jeder Standort der Reinigungsanlage sollte als Lieferbesuchsantrag für diese Sendung dargestellt werden.
    2. Fügen Sie CLEANED zu VisitRequest.tags jedes Besuchsantrags für die Sendung der Reinigungsanlage hinzu. Dadurch wird signalisiert, dass ein Fahrzeug, das diesen Ort verlässt, sauber ist. Andere Besuchsanträge im Modell sollten dieses Tag nicht verwenden, damit das Fahrzeug beim Verlassen dieser Orte als „nicht sauber“ gilt.
    3. Ermöglichen Sie dem Optimizer, diese Sendung zu überspringen, wenn das Fahrzeug anderweitig nicht verwendet wird, indem Sie penalty_cost auf einen kleinen Wert festlegen.

  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. Dabei wird davon ausgegangen, dass es am Ende des vorherigen Arbeitstags gereinigt wurde. Außerdem kann es vom Start-Wegpunkt direkt zum End-Wegpunkt fahren. Auch wenn solche Routen in der Praxis nicht vorkommen, hilft es dem Optimizer, 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 End-Wegpunkt des Fahrzeugs 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 TransitionAttributes.delay auf einen hohen Wert fest. Wenn Sie die Verzögerung länger als die maximale Routendauer festlegen, verhindern Sie effektiv, dass der Optimizer 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 verbieten:

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

Verzögerungen und Kosten auswählen

Die Wahl zwischen Verzögerungen und Kosten hängt von der Art der implementierten Geschäftslogik und Einschränkungen ab. Das Festlegen von TransitionAttributes.delay ist am besten geeignet, um harte Einschränkungen zu implementieren oder einen Kompromiss in Bezug auf die aufgewendete Zeit auszudrücken. TransitionAttributes.cost ist besser geeignet, um weiche Präferenzen oder Kompromisse zu implementieren, die als zusätzliche Kosten ausgedrückt werden. Sie können Verzögerungen und Kosten beliebig kombinieren, wenn sowohl die aufgewendete Zeit als auch die Kosten eine Rolle spielen.

Im Beispiel zur 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 Optimizer die Anforderung ignoriert. Wenn Sie nur Kosten, festlegen, kann der Optimizer die Reinigung überspringen, wenn er eine Möglichkeit findet, die Kosten anderweitig auszugleichen, z. B. indem er in der Zeit, die durch die nicht erfolgte Reinigung "gespart" wird, mehr Sendungen liefert.

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

Übergangsattribute hinzufügen, die allen Besuchsanträgen entsprechen

In den obigen Beispielen werden Übergangsattribute verwendet, die mit Orten mit einem bestimmten Tag oder Orten ohne Tag übereinstimmen. 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 von TransitionAttributes.src_tag und TransitionAttributes.excluded_src_tag sowie eines von TransitionAttributes.dst_tag und TransitionAttributes.excluded_dst_tagenthalten 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 Orte abgeglichen, die dieses Tag nicht haben. Da Sie aber absichtlich ein Tag ausgewählt haben, das von keinem Ort verwendet wird, stimmen diese Übergangsattribute mit allen Orten überein.

Weitere Informationen