Questa guida mostra i possibili utilizzi degli attributi di transizione. Ti insegnerà a modellare scenari reali in due esempi: l'incorporazione del tempo di parcheggio del veicolo nei percorsi ottimizzati e la garanzia che ogni percorso termini con una visita a una posizione specifica.
Prima di iniziare
Utilizzi gli attributi di transizione per aggiungere costi e ritardi specifici del modello a determinate transizioni negli itinerari ottimizzati. Questi costi e ritardi si aggiungono alle durate della transizione e ai costi calcolati dai dati della mappa in base ai parametri del veicolo utilizzato.
Una transizione è il segmento del percorso che collega una località a quella successiva.
Una posizione si riferisce a uno dei seguenti punti nel percorso di un veicolo:
- Il punto di partenza del percorso.
- Una fermata in cui viene effettuato un ritiro o una consegna.
- Il punto di arrivo del percorso.
Definisci tutti gli attributi di transizione per il modello aggiungendoli all'elenco
ShipmentModel.transition_attributes
.
Ogni elemento dell'elenco definisce un insieme di attributi di transizione e viene
corrisposto alle transizioni nelle route utilizzando i tag sulla posizione iniziale e sulla
posizione finale della transizione. Per scoprire di più sugli attributi di transizione, consulta la documentazione di riferimento per
TransitionAttributes
.
Modellare scenari reali
Questa sezione mostra due piccoli esempi di come implementare i vincoli aziendali reali utilizzando gli attributi di transizione.
Prenotare un orario per il parcheggio
In questo scenario, il conducente deve parcheggiare il veicolo prima di poter visitare la posizione A. La posizione B è nelle vicinanze e l'autista può utilizzare lo stesso parcheggio per entrambe le visite. Se l'autista visita B subito dopo A, risparmia tempo perché non deve lasciare il parcheggio e parcheggiare di nuovo il veicolo. Nell'API Route Optimization, puoi utilizzare gli attributi di transizione per aggiungere tempo extra per parcheggiare il veicolo solo quando l'autista si sposta da un parcheggio all'altro.
Quando modelli il tempo di parcheggio separatamente dalle durate delle visite, i percorsi in cui le visite che utilizzano lo stesso parcheggio sono raggruppate richiedono meno tempo. Rendi il modello più preciso e fai in modo che l'ottimizzatore preferisca i percorsi in cui le visite sono raggruppate.
Per farlo in una richiesta dell'API Route Optimization, segui questi passaggi:
Utilizza
VisitRequest.duration
solo per il tempo necessario per eseguire la visita. Ad esempio, per consegnare il pacco e raccogliere la firma del cliente.Per ogni posto auto distinto utilizzato nel modello, utilizza un nuovo tag che non venga utilizzato per altro nel modello, ad esempio
PARKING_123
.Aggiungi questo tag a quanto segue:
VisitRequest.tags
in tutte le richieste di visita che utilizzano questo parcheggio.Vehicle.start_tags
se il veicolo inizia il suo percorso da questo parcheggio.Vehicle.end_tags
se il veicolo inizia e termina il percorso in questo parcheggio.
Per ogni nuovo tag di parcheggio, aggiungi una voce a
ShipmentModel.transition_attributes
che aggiunge un ritardo per il parcheggio quando si arriva da un altro parcheggio nel seguente modo:Imposta
TransitionAttributes.excluded_src_tag
eTransitionAttributes.dst_tag
suPARKING_123
.Imposta
TransitionAttributes.delay
sull'ora necessaria per parcheggiare il veicolo.
Ad esempio, quando il tag di una posizione è
PARKING_123
e ci vogliono 150 secondi per parcheggiare il veicolo, aggiungi la seguente voce aShipmentModel.transition_attributes
:{ "excluded_src_tag": "PARKING_123", "dst_tag": "PARKING_123", "delay": "150s" }
Pulizia obbligatoria al termine dell'itinerario
In questo scenario, il veicolo deve essere pulito al termine dell'itinerario, con i seguenti vincoli aggiuntivi:
- La pulizia viene eseguita in un impianto di pulizia specializzato prima di tornare al deposito dei veicoli. Il percorso ottimizzato utilizza l'impianto di lavaggio migliore in base alla sua posizione e alle posizioni dei ritiri e delle consegne effettuati dal veicolo.
- Dopo la pulizia, il veicolo non deve effettuare ulteriori ritiri o consegne.
- Il tempo necessario per raggiungere la destinazione e pulire il veicolo viene conteggiato tra le ore di lavoro del conducente e deve rientrare nella durata massima del percorso.
Modelli questo requisito consentendo solo i percorsi vuoti o la cui ultima visita è a un impianto di pulizia. Nell'API Route Optimization, puoi eseguire questa operazione vietando le transizioni al waypoint finale dell'itinerario da qualsiasi posizione, tranne che dall'impianto di pulizia o dal punto di partenza dell'itinerario:
- Scegli due nuovi tag che non vengono utilizzati in nessun punto del modello, ad esempio
CLEANED
eROUTE_END
. Il primo è per le posizioni in cui il veicolo è o diventa pulito, mentre il secondo è per la fine del percorso. - Per ogni veicolo, aggiungi una nuova spedizione solo per la consegna che rappresenta la visita
a un impianto di lavaggio con i seguenti attributi:
- Ogni sede dell'impianto di pulizia deve essere rappresentata come una richiesta di visita di consegna di questa spedizione.
- Aggiungi
CLEANED
aVisitRequest.tags
di ogni richiesta di visita della spedizione della struttura di pulizia. Indica che un veicolo che lascia questa posizione è pulito. Le altre richieste di visita nel modello non devono utilizzare questo tag, in modo che il veicolo venga considerato "non pulito" quando le lascia. - Consenti all'ottimizzatore di ignorare questa spedizione quando il veicolo non viene utilizzato
impostando il valore di
penalty_cost
su un numero piccolo.
Per ogni veicolo, aggiungi
CLEANED
aVehicle.start_tags
. Questo valore viene utilizzato per contrassegnare il veicolo come pulito prima che esegua ritiri o consegne, supponendo che sia stato pulito alla fine del giorno lavorativo precedente, e per consentirgli di passare dal waypoint iniziale direttamente a quello finale. Anche se questi percorsi non vengono utilizzati nella pratica, consentire questo scenario aiuta l'ottimizzatore a cercare percorsi ottimizzati in modo più efficiente.Per ogni veicolo, aggiungi
ROUTE_END
aVehicle.end_tags
.Aggiungi una nuova voce a
ShipmentModel.transition_attributes
che vieta ai veicoli di arrivare al waypoint finale del veicolo quando non sono puliti, con le seguenti proprietà:Imposta
TransitionAttributes.excluded_src_tag
suCLEANED
.Imposta
TransitionAttributes.dst_tag
suROUTE_END
.Imposta
TransitionAttributes.delay
su un valore elevato. Se imposti un ritardo superiore alla durata massima del percorso, impedisci di fatto all'ottimizzatore di utilizzare questa transizione in un percorso.
Ad esempio, se la scala temporale del modello è di un giorno lavorativo, puoi utilizzare un ritardo di 24 ore (86.400 secondi) per impedire la transizione alla fine del percorso da qualsiasi luogo, tranne da un impianto di pulizia e dall'inizio del percorso:
{ "excluded_src_tag": "CLEANED", "dst_tag": "ROUTE_END", "delay": "86400s" }
Come scegliere tra ritardi e costi
La scelta tra ritardi e costi dipende dalla natura della logica e dei vincoli aziendali implementati. L'impostazione
TransitionAttributes.delay
è ideale per implementare vincoli rigidi o per esprimere un compromesso in termini di
tempo trascorso.
TransitionAttributes.cost
si adatta meglio quando si implementano preferenze o compromessi espressi come
costo aggiuntivo. Puoi combinare ritardi e costi in modo arbitrario quando sono interessati sia il tempo
trascorso sia i costi.
L'esempio di pulizia del veicolo utilizza un ritardo molto lungo, perché la pulizia del veicolo alla fine del percorso è un requisito fondamentale e il lungo ritardo impedisce all'ottimizzatore di ignorare il requisito. Se imposti solo un costo, l'ottimizzatore potrebbe scegliere di saltare la pulizia se trova un modo per compensare il costo altrove, ad esempio effettuando più consegne nel tempo "risparmiato" non pulendo il veicolo.
L'esempio di parcheggio utilizza un breve ritardo che corrisponde al tempo aggiuntivo necessario per parcheggiare il veicolo. Puoi anche utilizzare costs in combinazione con delays, se l'autista si ferma in un parcheggio a pagamento.
Come aggiungere un attributo di transizione che corrisponda a tutte le richieste di visita
Gli esempi precedenti utilizzano attributi di transizione che corrispondono a località con un determinato tag o a località senza il tag. Ma cosa succede se devi aggiungere attributi di transizione che si applicano a tutte le transizioni?
Non puoi omettere i tag, perché ogni messaggio
TransitionAttributes
deve avere uno dei tag
TransitionAttributes.src_tag
e
TransitionAttributes.excluded_src_tag
e uno dei tag
TransitionAttributes.dst_tag
e
TransitionAttributes.excluded_dst_tag
.
Tuttavia, puoi abbinare tutti i tag impostando
TransitionAttributes.excluded_src_tag
o
TransitionAttributes.excluded_dst_tag
a un tag che non viene utilizzato in nessun punto del modello. In questo modo verranno abbinate tutte le località
che non hanno questo tag, ma poiché hai scelto intenzionalmente un tag che non
viene utilizzato da nessuna località, questi attributi di transizione verranno abbinati a tutte le località.