Questa guida illustra i possibili utilizzi degli attributi di transizione. Ti insegnerà a modellare scenari reali in due esempi: incorporare il tempo per parcheggiare il veicolo nelle route ottimizzate e assicurarsi che ogni route termini con una visita a una località specifica.
Prima di iniziare
Utilizza gli attributi di transizione per aggiungere costi e ritardi specifici del modello a determinate transizioni nelle route ottimizzate. Questi costi e ritardi vengono aggiunti in aggiunta alle durate e ai costi di transizione calcolati dai dati della mappa in base ai parametri del veicolo utilizzato.
Una transizione è il segmento della route che collega una località alla successiva.
Una località si riferisce a uno dei seguenti punti nella route di un veicolo:
- Il punto di partenza della route.
- Una fermata in cui viene effettuato un ritiro o una consegna.
- Il punto di arrivo della route.
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 abbinato alle transizioni nelle route utilizzando i tag nella località di partenza e nella località di arrivo della transizione. Per saperne 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.
Riservare tempo per il parcheggio
In questo scenario, il conducente deve parcheggiare il veicolo prima di poter visitare la località A. La località B è nelle vicinanze e il conducente può utilizzare la stessa posizione del parcheggio per entrambe le visite. Se il conducente visita B subito dopo A, risparmia tempo perché non deve lasciare la posizione del 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 il conducente si sposta da una posizione del parcheggio all'altra.
Quando modelli il tempo di parcheggio separatamente dalle durate delle visite, le route 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 le route in cui le visite sono raggruppate.
Per farlo in una richiesta dell'API Route Optimization:
Utilizza
VisitRequest.durationsolo per il tempo necessario per eseguire la visita. Ad esempio, per consegnare il pacco e raccogliere la firma del cliente.Per ogni posizione del parcheggio distinta utilizzata nel modello, utilizza un nuovo tag che non viene utilizzato per nient'altro nel modello, ad esempio
PARKING_123.Aggiungi questo tag a:
VisitRequest.tagsin tutte le richieste di visita che utilizzano questa posizione del parcheggio.Vehicle.start_tagsse il veicolo inizia la route in questa posizione del parcheggio.Vehicle.end_tagsse il veicolo inizia o termina la route in questa posizione del parcheggio.
Per ogni nuovo tag di parcheggio, aggiungi una voce a
ShipmentModel.transition_attributesche aggiunga un ritardo per il parcheggio quando si arriva da una posizione del parcheggio diversa:Imposta
TransitionAttributes.excluded_src_tageTransitionAttributes.dst_tagsuPARKING_123.Imposta
TransitionAttributes.delaysul tempo necessario per parcheggiare il veicolo.
Ad esempio, se il tag di una località è
PARKING_123e 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 alla fine della route
In questo scenario, il veicolo deve essere pulito alla fine della route, con i seguenti vincoli aggiuntivi:
- La pulizia viene eseguita in una struttura di pulizia specializzata prima di tornare al deposito dei veicoli. La route ottimizzata utilizza la struttura di pulizia migliore in base alla sua posizione e alle posizioni dei ritiri e delle consegne effettuate dal veicolo.
- Dopo la pulizia, il veicolo non deve effettuare ulteriori ritiri o consegne.
- Il tempo necessario per raggiungere la struttura e pulire il veicolo rientra nelle ore di lavoro del conducente e deve rientrare nella durata massima della route.
Modella questo requisito consentendo solo le route vuote o la cui ultima visita è a una struttura di pulizia. Nell'API Route Optimization, puoi farlo vietando le transizioni al waypoint finale della route da qualsiasi località, ad eccezione della struttura di pulizia o del punto di partenza della route:
- Scegli due nuovi tag che non vengono utilizzati in nessun punto del modello, ad esempio
CLEANEDeROUTE_END. Il primo è per le località in cui il veicolo è o diventa pulito, mentre il secondo è per la fine della route. - Per ogni veicolo, aggiungi una nuova spedizione solo per la consegna che rappresenta la visita a una struttura di pulizia con i seguenti attributi:
- Ogni località della struttura di pulizia deve essere rappresentata come una richiesta di visita di consegna di questa spedizione.
- Aggiungi
CLEANEDaVisitRequest.tagsdi ogni richiesta di visita della spedizione della struttura di pulizia. Indica che un veicolo che lascia questa località è pulito. Le altre richieste di visita nel modello non devono utilizzare questo tag in modo che il veicolo sia considerato "non pulito" quando le lascia. - Consenti all'ottimizzatore di ignorare questa spedizione quando il veicolo non viene utilizzato in altro modo
impostando il relativo
penalty_costsu un numero piccolo.
Per ogni veicolo, aggiungi
CLEANEDaVehicle.start_tags. Viene utilizzato per contrassegnare il veicolo come pulito prima che esegua ritiri o consegne, presupponendo che sia stato pulito alla fine del giorno lavorativo precedente, e per consentirgli di passare dal waypoint iniziale direttamente al waypoint finale. Anche se queste route non si verificano in pratica, consentire questo scenario aiuta l'ottimizzatore a cercare route ottimizzate in modo più efficiente.Per ogni veicolo, aggiungi
ROUTE_ENDaVehicle.end_tags.Aggiungi una nuova voce a
ShipmentModel.transition_attributesche impedisca ai veicoli di arrivare al waypoint finale del veicolo quando non sono puliti, con le seguenti proprietà:Imposta
TransitionAttributes.excluded_src_tagsuCLEANED.Imposta
TransitionAttributes.dst_tagsuROUTE_END.Imposta
TransitionAttributes.delaysu un valore elevato. Se imposti un ritardo superiore alla durata massima della route, impedisci all'ottimizzatore di utilizzare questa transizione in una route.
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 della route da qualsiasi punto, ad eccezione di una struttura di pulizia e dell' inizio della route:
{ "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 di business e dei vincoli implementati. L'impostazione
TransitionAttributes.delay
è ideale per implementare vincoli rigidi o per esprimere un compromesso in termini di
tempo trascorso.
TransitionAttributes.cost
è più adatta per implementare preferenze o compromessi flessibili espressi come costo aggiuntivo. Puoi combinare ritardi e costi in modo arbitrario quando sono interessati sia il tempo trascorso sia il costo.
L'esempio di pulizia del veicolo utilizza un ritardo molto lungo, perché la pulizia del veicolo alla fine della route è un requisito rigido e il ritardo lungo 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 consegnando più spedizioni nel tempo "risparmiato" non pulendo il veicolo.
L'esempio di parcheggio utilizza un ritardo breve che corrisponde al tempo aggiuntivo necessario per parcheggiare il veicolo. Puoi anche utilizzare i costi in combinazione con i ritardi, se il conducente 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à che non hanno il tag. Ma cosa succede se devi aggiungere attributi di transizione che si applicano a tutte le transizioni?
Non puoi semplicemente omettere i tag, perché ogni
TransitionAttributes
messaggio deve avere uno tra
TransitionAttributes.src_tag
e
TransitionAttributes.excluded_src_tag
e uno tra
TransitionAttributes.dst_tag
e
TransitionAttributes.excluded_dst_tag.
Tuttavia, puoi abbinare tutti i tag impostando
TransitionAttributes.excluded_src_tag
o
TransitionAttributes.excluded_dst_tag
su 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à.