Vincoli del modello

I vincoli sulle variabili decisionali assicurano che solamente una configura-zione di scaffalatura, tra le C fattibili individuate nella fase di progettaconfigura-zione precedente, venga scelta dal risolutore (eq. 6.16), cosiccome venga adottato un solo criterio di allocazione (eq. 6.17) tra le S strategie proposte. Una sola dimensione principale della baia viene scelta tra il minimo min_pp e il massimo numero max_pp di posti pallet possibili in base al peso dell’unità di carico (eq. 6.18). X r∈[1...C] rackr = 1 rackr ∈ {0, 1} (6.16) X k∈[1...S] storage_k= 1 storage_k∈ {0, 1} (6.17) X m∈[minpp...maxpp] pp_m = 1 pp_m∈ {0, 1} (6.18)

Per ogni combinazione di scaffalatura (ovvero numero di colonne) e nu-mero di posti pallet per baia, il relativo nunu-mero di baie raramente risulta essere un numero intero; per evitare l’aumento della capacità di stoccaggio rispetto al valore individuato nella prima fase di design, vengono attribuiti un diverso numero di posti pallet rispetto al valore base ad un limitato nu-mero di baie, in modo da rispettare il nunu-mero totale di colonne. Ad esempio, se il numero di colonne è 45 e il numero di posti pallet selezionato è 2, si potranno ottenere 21 baie con 2 posti pallet per baia e 1 baia con 3 posti

6.3. Un nuovo approccio all’ottimizzazione della progettazione 107

pallet, oppure 22 baie con 2 posti pallet e 1 baia con 1 posto pallet. Viene quindi introdotta la variabile booleana ausiliaria bb_n (uguale a 1 se viene selezionata la configurazione di baia n, 0 altrimenti) per identificare la cor-retta configurazione di baia; il vincolo in eq. 6.19 assicura che sia selezionata solo una configurazione di baia tra le B possibili.

X

n∈[1...B]

bbn = 1 bbn ∈ {0, 1} (6.19)

Il secondo gruppo di vincoli permette di dettagliare la struttura della scaffalatura in termini di ripiani, colonne, baie e livelli per ogni strato sulla base delle variabili decisionali.

Data una configurazione di scaffalatura r, identificata nella prima fase della progettazione, vengono selezionati il numero di colonne e di livelli (si veda eq. 6.20); il numero effettivo di baie bays_i costituite da i posti pallet per una data scaffalatura r, posti pallet m e configurazione di baia n deve rispettare i valori generati (si veda eq. 6.21). Infine, quando viene selezionata la politica di stratificazione della scaffalatura in base alle W classi di peso dei prodotti, deve essere identificato il corretto numero di livelli per ogni strato (si veda eq. 6.22); in assenza, invece, di stratificazione, viene considerato un unico strato che coinvolge l’intera scaffalatura.

rack_r⇒ [col, rows] = RackVal[r] (6.20)

rackr∧ pp_m∧ bb_n ⇒ bays_i = BayVal[r,m,n]∀i ∈ [minpp. . . maxpp] (6.21)

rackr∧ storage_k⇒ levels_j = LayVal[r,k] ∀j ∈ [1 . . . W ] (6.22)

I vincoli sopra riportati possono essere facilmente codificati in Comet grazie al table constraint, che vincola tre variabili ad assumere valori concordi con una delle triple contenute nella tabella passata come parametro. In questo caso, tutte le specifiche provenienti dalle combinazione delle varie opzioni generate sono state organizzate secondo queste tabelle, in modo tale che le variabili vi debbano aderire (si vedano ad es. la Tabella 6.2 per l’eq. 6.21 e la Tabella 6.1 per l’eq. 6.22 per il caso di riferimento).

Il terzo gruppo di vincoli permette di scegliere correttamente il tipo di spalla e di corrente in base al carico che devono sopportare. Se viene stra-tificata la scaffalatura, le sezioni degli elementi diminuiscono dal pavimento al soffitto e devono pertanto essere selezionate diverse tipologie frame_i,j e beam_i,j per ogni tipo di baia i e per ogni strato j corrispondente ad una

108 Capitolo 6. Ottimizzazione sostenibile della configurazione di sistema

diversa classe di peso (si veda eq. 6.23). Tutte le specifiche dei montanti e dei correnti devono essere compatibili con i cataloghi dei fornitori, che sono stati organizzati nelle tabelle FrameVal[frame_i,j] e BeamVal[beam_i,j] passa-te come parametro al table constraint di Comet (si vedano la Tabella 6.3 e Tabella 6.4 per il caso di riferimento considerato). La capacità massi-ma di carico sopportata dai tipi di spalle e correnti selezionati dove essere sufficiente a sostenere il carico previsto, come riportato nell’eq. 6.26 e nel-l’eq. 6.28. Inoltre, i montanti delle spalle si appoggiano su una superficie di base (frame_base) in grado di sostenere un carico massimo per metro quadro pari a frame_Qslab, che non può essere superato (si veda eq. 6.27).

bays_i= 0 ⇒ frame_i,j= 0 ∧ beam_i,j = 0 layer_j= 0 ⇒ frame_i,j= 0 ∧ beam_i,j = 0

bays_i> 0 ∧ layer_j> 0 ⇒ frame_i,j> 0 ∧ beam_i,j > 0 ∀(i, j) (6.23)

framei,j> 0 ⇒ [frame_width_i,j, frame_weight_i,j, frame_cost_i,j, Qmax_frame_i,j] = FrameVal[frame_i,j] ∀(i, j) (6.24)

beam_i,j> 0 ⇒ [beam_weight_i,j, Qmax_beam_i,j] = BeamVal[beam_i,j](6.25)

Qmax_frame_i,j <^X

k≤j

(i · weight_k+ beam_weight_i,k)levelsk

⇒ bbn = 0 ∀(i, j) (6.26)



frame_weight_i,ˆj· height_floor+^X

j

levels_j i · weight_j+ beam_weight_i,j+

frame_weight_i,j· (height_cell+ beam_height_i,j)


/(2 · framebase)

> frame_Qslab ⇒ bb_n = 0 ∀(i, j) (6.27)

Qmax_beam_i,j< i · weight_j ⇒ bb_n = 0 ∀(i, j) (6.28)

Il consumo di energia per i movimenti del trasloelevatore è strettamente legato alla configurazione della scaffalatura in termini di livelli e colonne,

6.4. Risultati 109

specifiche del trasloelevatore e politica di allocazione. Le specifiche del tra-sloelevatore vengono identificate durante la prima fase di progettazione; in particolare, viene definita la velocità ed accelerazione per ogni configurazio-ne di base della scaffalatura. Tali specifiche, insieme agli ulteriori dettagli sui motori ottenibili dai cataloghi dei fornitori, vengono pre-processate dal modello di energia (par. 2.3), per ogni dimensione della scaffalatura e per la politica di allocazione selezionata. Il consumo energetico annuo è valutato tenendo conto del numero di ore di funzionamento al giorno dell’AS/RS e della produttività del sistema: i valori per il caso di riferimento sono ripor-tati nel par. 6.4.1. Si ottengono così i consumi energetici annui da associare alle varie alternative progettuali, i quali vengono inseriti nelle tabelle Ener-gyVal[r,k], passate come parametro al table constraint nell’eq. 6.29 (si veda Tabella 6.6 per i valori del caso di riferimento).

rackr∧ storage_k⇒ energy = EnergyVal[r,k] (6.29)

6.4 Risultati

I risultati ottenibili dai modelli progettuali proposti sono descritti nei para-grafi seguenti: nel par. 6.4.1, in particolare, viene presentato il caso studio con i relativi parametri di input, nel par. 6.4.2 viene analizzata la configu-razione ottima dal punto di vista economico e viene condotta un’analisi di sensibilità sui parametri di sistema, mentre nel par. 6.4.3 vengono discusse le soluzioni ottenute minimizzando l’impronta carbonica associata al sistema.