Als Zeitfenster wird der Zeitraum zwischen einer Anfangs- und Endzeit bezeichnet, in dem ein Netzwerkstandort, z. B. ein Stopp bei einer Routenanalyse, in einer Route erreicht wird. Zeitfenster werden häufig zum Modellieren von Terminen oder Lieferzeiten verwendet.
Hinweis:
Ein Zeitfenster beschreibt, wann ein Fahrzeug an einem Ort eintreffen kann. Es beschreibt nicht den Zeitraum, in dem alle Aktivitäten an diesem Ort abgeschlossen sein müssen.Die drei Netzwerkanalysetypen, die Zeitfenster umfassen, lauten Route, Vehicle Routing Problem und Last-Mile-Delivery. Für "Route" und "Vehicle Routing Problem" können die Zeitfenster für ein bestimmtes Datum, einen generischen Wochentag oder das aktuelle Datum konfiguriert werden. Für Last-Mile-Delivery können die Zeitfenster jedoch nur für ein bestimmtes Datum konfiguriert werden.
Weitere Informationen zu Datumsangaben und Uhrzeiten in einer Netzwerkanalyse
Zeitfenster in einer Routenanalyse
Der Routen-Solver versucht, eine Route entlang bestimmter Stopps zu finden, die die geringsten Kosten verursacht und für die gleichzeitig die ausgewählten Beschränkungen im Netzwerk und alle Zeitfenster berücksichtigt werden. Wenn Überschreitungen des Zeitfensters unvermeidbar sind, versucht der Solver, die gesamte Zeitüberschreitung zu minimieren.
Zeitfenster in einer Routenanalyse werden mit Feldern in der Eingabeklasse Stops definiert:
| Netzwerkanalyseklasse | Zeitfensterfeld |
|---|---|
Stops |
TimeWindowStart: Der Anfang des Zeitfensters, in dem der Stopp aufgesucht werden kann |
|
TimeWindowEnd: Das Ende des Zeitfensters, in dem der Stopp aufgesucht werden kann |
Zeitfenster werden automatisch in der Analyse verwendet, wenn Zeitfensterfelder gefüllt sind.
Die für jedes Zeitfenster angegebene Zeit kann in der lokalen Zeitzone der jeweiligen Eingabeposition oder in koordinierter Weltzeit (UTC) interpretiert werden. Bei Verwendung eines Routenanalyse-Layers kann die Zeitzone für Zeitfensterfelder mit dem Parameter Zeitzone für Zeitfelder im Dialogfeld des Geoverarbeitungswerkzeugs Routenanalyse-Layer erstellen oder in der Dropdown-Liste Bezugszeitzone auf dem Menüband Routen-Layer angegeben werden. Bei Verwendung eines Route-Solver-Objekts im arcpy.nax Python-Modul verwenden Sie die timeZoneForTimeWindows-Eigenschaft.
Wenn Zeitfenster verwendet werden, muss kein Analysezeitpunkt angegeben werden, da das Zeitfenster des ersten Stopps zum Bestimmen des Routenanfangs verwendet wird. Wenn Sie jedoch einen Analysezeitpunkt angeben, der beispielsweise den Anfang der Schicht eines Fahrers darstellt, wird dies bei den Ankunfts- und Abfahrtszeiten an allen Stopps berücksichtigt. Wenn die Route vor dem Zeitfenster des ersten Stopps beginnt, wird am ersten Stopp eine Wartezeit hinzugefügt. Wenn die Route nach Verstreichen des Zeitfensters eines Stopps beginnt, entsteht eine Zeitüberschreitung. Das Datum des Zeitfensters muss mit dem für den Zeitpunkt angegebenen Datum für die Routenanalyse übereinstimmen.
Auf der Route entstandene Wartezeiten oder Zeitüberschreitungen sind in der Ausgabe enthalten. Die gesamte Wartezeit und Zeitüberschreitung für jede Route finden Sie in der Ausgabeklasse Routes in Feldern mit dem Präfix TotalWait_ bzw. TotalViolation_. Die Wartezeit und Zeitüberschreitung für jeden Stopp auf einer Route finden Sie in der Ausgabeklasse Stops in Feldern mit dem Präfix Wait_ bzw. Violation_. Die Felder in der Ausgabeklasse Stops mit den Präfixen CumulWait_ und CumulViolation_ stellen die kumulative Wartezeit und Zeitüberschreitung bis zu diesem Punkt in der Route dar.
Zeitfenster in einer Vehicle Routing Problem-Analyse
Der Vehicle Routing Problem-Solver versucht, die kostengünstigste Route zu Aufträgen zu finden, bei der notwendige Depotstopps und Pausen eingeplant sind und bei der gleichzeitig die ausgewählten Einschränkungen im Netzwerk und alle Zeitfenster berücksichtigt werden. Wenn Überschreitungen des Zeitfensters zulässig und unvermeidbar sind, versucht der Solver, die gesamte Zeitüberschreitung zu minimieren.
Zeitfenster in einer Vehicle Routing Problem-Analyse können mit den folgenden Feldern für die Klassen Orders, Depots und Breaks definiert werden:
| Netzwerkanalyseklasse | Zeitfensterfeld |
|---|---|
Orders |
TimeWindowStart: Der Anfang des ersten Zeitfensters, in dem der Auftragsort aufgesucht werden kann |
TimeWindowEnd: Das Ende des ersten Zeitfensters, in dem der Auftragsort aufgesucht werden kann | |
TimeWindowStart2: Der Anfang des zweiten Zeitfensters, in dem der Auftragsort aufgesucht werden kann | |
TimeWindowEnd2: Das Ende des zweiten Zeitfensters, in dem der Auftragsort aufgesucht werden kann | |
Depots | TimeWindowStart: Der Anfang des ersten Zeitfensters, in dem das Depot aufgesucht werden kann |
TimeWindowEnd: Das Ende des ersten Zeitfensters, in dem das Depot aufgesucht werden kann | |
TimeWindowStart2: Der Anfang des zweiten Zeitfensters, in dem das Depot aufgesucht werden kann | |
TimeWindowEnd2: Das Ende des zweiten Zeitfensters, in dem das Depot aufgesucht werden kann | |
Breaks | TimeWindowStart: Der Anfang des Zeitfensters, in dem die Pause stattfinden kann |
TimeWindowEnd: Das Ende des Zeitfensters, in dem die Pause stattfinden kann |
Vorversion:
Bei Verwendung eines VehicleRoutingProblem-Solver-Objekts mit Schemaversion One im arcpy.nax-Modul Python wird das erste Zeitfenster in den Klassen Orders und Depots mit den Feldern TimeWindowStart1 und TimeWindowEnd1 anstatt mit den Feldern TimeWindowStart und TimeWindowEnd definiert.
Die Eingabeklasse Routes verfügt ebenfalls über Zeitfensterfelder, die zum Angeben des Zeitraums, in dem eine Route beginnen kann, verwendet werden:
| Netzwerkanalyseklasse | Zeitfensterfeld |
|---|---|
Routes |
EarliestStartTime: Der Anfang des Zeitfensters, in dem die Route beginnen kann |
LatestStartTime: Das Ende des Zeitfensters, in dem die Route beginnen kann |
Zeitfenster werden automatisch in der Analyse verwendet, wenn die Zeitfensterfelder gefüllt sind. Das Datum des Zeitfensters muss mit dem für die Analyse konfigurierten Standarddatum übereinstimmen.
Die für jedes Zeitfenster angegebene Zeit kann in der lokalen Zeitzone der jeweiligen Eingabeposition oder in koordinierter Weltzeit (UTC) interpretiert werden. Bei Verwendung eines Vehicle Routing Problem-Analyse-Layers kann die Zeitzone für Zeitfensterfelder mit dem Parameter Zeitzone für Zeitfelder im Dialogfeld des Geoverarbeitungswerkzeugs Analyse-Layer für Vehicle Routing Problem erstellen oder in der Dropdown-Liste Bezugszeitzone auf dem Menüband VRP-Layer angegeben werden. Bei Verwendung eines VehicleRoutingProblem-Solver-Objekts im arcpy.nax Python-Modul verwenden Sie die timeZoneForTimeWindows-Eigenschaft.
Auf der Route entstandene Wartezeiten oder Zeitüberschreitungen sind in der Ausgabe enthalten. Die gesamte Wartezeit und Zeitüberschreitung für jede Route finden Sie in der Ausgabeklasse Routes im Feld TotalWaitTime bzw. TotalViolationTime. Die bei den einzelnen Aufträgen, Pausen oder Depots auf einer Route entstandenen Wartezeiten und Zeitüberschreitungen finden Sie im Feld WaitTime bzw. ViolationTime. Die Felder CumulWaitTime und CumulViolationTime für einen Auftrag, ein Depot oder eine Pause stellen die kumulative Wartezeit bzw. Zeitüberschreitung bis zu diesem Punkt in der Route dar.
Sie können die Felder MaxViolationTime und MaxViolationTime2 in den Eingabeaufträgen und das Feld MaxViolationTime in den Eingabepausen zum Steuern der akzeptablen Zeitfensterverletzung für Ihre Analyse verwenden. Wenn Sie Zeitfenster als harte Einschränkung modellieren möchten, die Zeitfensterverletzungen nicht zulässt, legen Sie die entsprechenden Felder MaxViolationTime und MaxViolationTime2 auf Null fest.
Vorversion:
Bei Verwendung eines VehicleRoutingProblem-Solver-Objekts mit Schemaversion 1 im arcpy.nax-Modul Python hat das Feld MaxViolationTime in der Orders-Klasse den Namen MaxViolationTime1.
Zeitfenster in einer Last-Mile-Delivery-Analyse
Der Last Mile Delivery Solver sucht eine ordnungsgemäß gruppierte und kostengünstige Reihe von Routen für die Erfüllung von Aufträgen unter Berücksichtigung der ausgewählten Einschränkungen für das Netzwerk und der Bedingungen für das Problem, z. B. Zeitfenster. Wenn Überschreitungen des Zeitfensters zulässig und unvermeidbar sind, versucht der Solver, die gesamte Zeitüberschreitung zu minimieren.
Zeitfenster in der Last-Mile-Delivery-Analyse werden in der Klasse "Aufträge" mit den folgenden Feldern definiert:
| Netzwerkanalyseklasse | Zeitfensterfeld |
|---|---|
Orders |
TimeWindowStart: Der Anfang des Zeitfensters, in dem der Auftragsort aufgesucht werden kann |
TimeWindowEnd: Das Ende des Zeitfensters, in dem der Auftragsort aufgesucht werden kann |
Die Eingabeklasse "Routen" verfügt ebenfalls über Zeitfensterfelder, die zum Angeben des Zeitraums, in dem eine Route beginnen kann, verwendet werden:
| Netzwerkanalyseklasse | Zeitfensterfeld |
|---|---|
Routes |
EarliestStartDate: Definiert in Verbindung mit der EarliestStartTime den Anfang des Zeitfensters, in dem die Route beginnen kann, und gibt den Datumsteil an. |
EarliestStartTime: Definiert in Verbindung mit dem EarliestStartDate den Anfang des Zeitfensters, in dem die Route beginnen kann, und gibt den Uhrzeitteil an. | |
StartFlexibility: Gibt an, wie lange nach dem frühesten zulässigen Startzeitpunkt der Route die Route starten kann. Verwendet die durch den Parameter TimeFieldUnits angegebenen Einheiten. |
EarliestStartDate und EarliestStartTime können für jedes Feature in der Klasse "Routen" oder mit den Parametern EarliestRouteStartDate und EarliestRouteStartTime für alle Features angegeben werden.
Zeitfenster werden automatisch in der Analyse verwendet, wenn die Zeitfensterfelder gefüllt sind. Die Zeitfenster-Datumsangaben für die Klassen "Aufträge" und "Routen" müssen bestimmte Datumsangaben sein und dürfen nicht mehr als ein Jahr auseinanderliegen.
Die für jedes Zeitfenster angegebene Zeit kann in der lokalen Zeitzone der jeweiligen Eingabeposition oder in koordinierter Weltzeit (UTC) interpretiert werden. Bei Verwendung eines Last-Mile-Delivery-Analyse-Layers kann die Zeitzone für Zeitfensterfelder mit dem Parameter Zeitzone für Zeitfelder im Dialogfeld des Geoverarbeitungswerkzeugs Last-Mile-Delivery-Analyse-Layer erstellen oder in der Dropdown-Liste Bezugszeitzone auf dem Menüband "Last-Mile-Delivery-Layer'" angegeben werden. Bei Verwendung eines LastMileDelivery-Solver-Objekts im Python-Modul "arcpy.nax" verwenden Sie die timeZoneForTimeFields-Eigenschaft.
Auf der Route entstandene Wartezeiten oder Zeitüberschreitungen sind in der Ausgabe enthalten. Die gesamte Wartezeit und Zeitüberschreitung für jede Route finden Sie in der Ausgabeklasse "Routen" im Feld TotalWaitTime bzw. TotalViolationTime. Die bei den einzelnen Aufträgen auf einer Route entstandenen Wartezeiten und Zeitüberschreitungen finden Sie im Feld WaitTime bzw. ViolationTime.
Sie können das Feld MaxViolationTime in den Eingabeaufträgen festlegen, um die akzeptable Zeitfensterverletzung für Ihre Analyse zu steuern. Wenn Sie Zeitfenster als harte Einschränkung modellieren möchten, die Zeitfensterverletzungen nicht zulässt, legen Sie MaxViolationTime auf Null fest.
Beispiel für ein Zeitfenster
Im folgenden Beispiel werden Zeitfenster veranschaulicht, die für eine Routenanalyse verwendet werden, um die optimale Route zum Aufsuchen von drei Stopps (a, b und c) zu ermitteln. Das Zeitfenster für die einzelnen Stopps wird durch die Felder TimeWindowStart und TimeWindowEnd angegeben.
Die Route kann jederzeit zwischen 8:00 Uhr und 9:00 Uhr an Punkt a beginnen. Punkt b darf jedoch nicht vor 9:15 Uhr erreicht werden. Wie unten gezeigt, wird b um 9:08:24 Uhr erreicht.
Da b nur zwischen 9:15 Uhr und 9:30 Uhr erreicht werden darf, wird an Punkt b 6 Minuten und 36 Sekunden gewartet, und der Punkt wird um 9:15 Uhr verlassen. Diese Wartezeit wird im Feld Wait_TravelTime von Stopp b als 6,6 Minuten gespeichert und zum Gesamtzeitbedarf für die Route addiert. Im Feld Cumul_TravelTime für einen Stopp wird die Gesamtzeit gespeichert, die zum Erreichen dieser Station benötigt wird. Die kumulative Fahrzeit für Punkt b beträgt 15 Minuten (8 Minuten und 24 Sekunden Fahrzeit und 6 Minuten und 36 Sekunden Wartezeit, um das Zeitfenster für Stopp b zu berücksichtigen).
Die Route sieht für Stopp b die Abfahrtszeit 9:15 Uhr vor, und Stopp c wird um 9:35:34 Uhr erreicht. Stopp c hat jedoch ein Zeitfenster von 9:15 Uhr bis 9:30 Uhr. Da das Zeitfenster von Stopp c bei dieser Route nicht berücksichtigt werden kann, entsteht eine Zeitüberschreitung von 5 Minuten und 34 Sekunden, die im Feld Violation_TravelTime als 5,58 Minuten gespeichert wird.
