Résolution du problème de DHP

Nous cherchons maintenant à résoudre ce problème de DHP en nous appuyant sur le modèle DHP _P T A que nous avons construit. Pour ce faire la propriété d’atteignabilité PRS4 est formulée et vérifiée dans UppAal-CORA en sélectionnant l’ordre de recherche Best-first. Cela veut dire que la recherche s’effectue au sein du graphe en choisissant d’explorer à chaque étape le nœud le plus prometteur et la résolution permet de fournir le coût optimal (le temps minimum de la récolte).

Afin d’étudier empiriquement la complexité de la résolution du DHP avec le modèle DHP _P T A, la requête a d’abord été appliquée sans utiliser la fonctionnalité d’optimisation par remaining de UppAal-CORA, que l’on expliquera par la suite.

La table 5.2 et la figure 5.11 présentent les résultats de cette analyse en indiquant pour chaque instance le nombre d’états explorés pendant la résolution et le coût optimal obtenu. Si le nombre de rangs dépasse 9 rangs, un problème d’explosion combinatoire se produit et la vérification devient impossible. Dans la table 5.2, la première colonne désigne les instances du problème DHP soumis à UppAal-CORA. Le codage nCiRi est choisi pour désigner les instances avec n le nombre de rangs (n ∈ [7, 12]), Ci la capacité maximale de la trémie en litres (égale à C1 ou C2, avec C1 = 1000l et C2 = 2000l), et Ri qui représente la façon de calculer Rmin (Rmin = R1 × QAtot ou Rmin = R2 × QAtot, avec QAtot la somme des valeurs des quantités de raisin A dans l’ensemble des rangs, R1 = 50% et R2 = 70%). La deuxième colonne désigne le nombre d’états explorés pendant la résolution de cette instance et la troisième colonne désigne le coût optimal obtenu.

Table 5.2 – Résultats expérimentaux sans remaining

Instance Nombre d’états Coût Instance Nombre d’états Coût

7C1R1 264113 655 9C1R1 9295636 827 7C1R2 199744 655 9C1R2 4297934 827 7C2R1 436221 655 9C2R1 18497531 809 7C2R2 337626 655 9C2R2 12763043 809 8C1R1 945767 669 8C1R2 726570 676 8C2R1 2077252 668 8C2R2 1670658 668

Ces résultats sont issus de l’application de la commande suivante :

./memtime ./verif yta − u − t3 − o3 − f tracef ile model.xml query.q

Comme mentionné dans le chapitre 2, la fonction memtime permet la mesure de la mémoire et du temps utilisé lors de l’exécution d’une commande. La fonction

verifyta permet de vérifier la propriété décrite dans le fichier query.q sur le modèle DHP_P T A décrit dans le fichier model.xml. Les options de vérification utilisées

5.5. RÉSULTATS D’APPLICATION DE LA MÉTHODE 147

Figure 5.11 – Analyse quantitative du nombre d’états explorés en fonction du nombre de rangs récoltés

nombre d’états explorés. L’option -t3 génère la trace avec le meilleur coût. L’option - o3 sélectionne l’ordre de recherche optimal first et l’option -f ajoute un préfixe au nom de la trace. Le fichier tracefile est le nom du fichier trace, le fichier model.xml peut avoir le nom nCiRi.xml avec nCiRi représentant le codage défini précédemment. Le fichier query.q contient la propriété qui permet de résoudre le problème du DHP qui est la propriété PRS4.

5.5.2.1 Étude du gain obtenu

Pour évaluer l’efficacité de notre méthode et estimer le gain obtenu avec l’ap- proche CORA, il est intéressant de faire une comparaison sur le coût (temps de récolte) avec une machine qui parcourrait et récolterait la parcelle de façon clas- sique c’est-à-dire avec un motif régulier pratique pour les manoeuvres. Par exemple, récolter le ième _{rang dans un sens puis faire demi-tour et récolter le rang i + 2 dans}

le sens inverse puis aller à la benne. Il suffit de répéter ce motif jusqu’à la fin de la récolte de toute la parcelle. Le tableau 5.3 présente une comparaison des coûts entre une approche classique et une approche CORA. La première colonne désigne les instances (même codage qu’auparavant). La colonne nommée "Coût classique" donne le coût si la machine suit le motif régulier et la colonne nommée "Coût opti- mal" donne le coût optimal trouvé par notre approche. La colonne nommée "Gain" représente le gain obtenu grâce à notre approche.

D’après les résultats du tableau 5.3, notre méthode permet d’économiser entre 6 et 9 % du coût par rapport à une approche classique. Il est surtout important de noter que ce gain n’est pas constant, et qu’il augmente avec le nombre de rangs. Il est sera ainsi possible d’atteindre des gains non négligeable, d’autant plus si on

Table 5.3 – Comparaison du coût (temps de récolte) entre une approche classique et une approche CORA

Instance Coût

classique optimalCoût Gain Instance classiqueCoût optimalCoût Gain

7C1R1 703 655 6,82% 9C1R1 888 827 6,87% 7C1R2 703 655 6,82% 9C1R2 888 827 6,87% 7C2R1 703 655 6,82% 9C2R1 888 809 8,89% 7C2R2 703 655 6,82% 9C2R2 888 809 8,89% 8C1R1 713 669 6,17% 8C1R2 713 676 5,19% 8C2R1 713 668 6,31 % 8C2R2 713 668 6,31 %

arrive à maîtriser la complexité du problème.

5.5.2.2 Analyse de la complexité

Nous allons maintenant analyser la sensibilité du problème de DHP en fonction des paramètres qui influencent sa complexité de façon à chercher à mieux maîtriser l’explosion combinatoire.

Influence du nombre de rangs

La forte augmentation de la complexité en fonction du nombre des rangs, que l’on peut observée figure 5.11, était attendue, dans la mesure où le choix de l’ordre de parcours des n rangs génère une combinatoire de type n!. La combinatoire est en réalité supérieure à n! dans la mesure où, à chaque fin de rang, il faut ajouter la décision d’aller vidanger ou non les trémies. Le DHP a quelques similitudes avec le VRP, qui est connu pour être un problème NP-difficile. En outre, évidemment, le model-checking est bien connu pour être exposé à l’explosion combinatoire.

Influence de la capacité des trémies et évaluation du nombre de chemins à explorer

On peut remarquer dans la figure 5.11 que les courbes C2R1 et C2R2 sont su- périeures respectivement aux courbes C1R1 et C1R2. Cet état de fait n’est pas anormal, car C2 indiquant une plus grande capacité de trémie, cela signifie que pour les instances correspondant à C2, plus souvent que dans le cas C1, HM aura le choix entre aller à l’emplacement des bennes ou récolter un autre rang.

Prenons un exemple simple : la capacité de la machine ne permet de récolter qu’un seul rang à la fois (on note C1 ≡ 1rang), et on a une parcelle formée de 4

5.5. RÉSULTATS D’APPLICATION DE LA MÉTHODE 149

rangs (R1, R2, R3, R4). La figure 5.12 présente le début du graphe d’états d’explo- ration. HM commence à l’emplacement des bennes et elle peut récolter l’un des 4 rangs, dans l’orientation directe ou inverse (8 possibilités). Dès que HM a récolté ce rang, elle doit aller à l’emplacement des bennes (B) pour vider ses trémies qui sont pleines. Il reste alors 3 rangs à récolter. Le même raisonnement peut être réitéré pour la récolte d’un nouveau rang. Au total, le graphe d’états sera composé de 1265 états : (1[l’emplacement des bennes] + 8[1ier _{rang récolté] + 8[l’emplacement des bennes] +} 8*6[2ième _{rang récolté] + 8*6[l’emplacement des bennes] + 8*6*4 [3}ième _{rang récolté]} +8*6*4[l’emplacement des bennes]+ 8*6*4*2 [4ième _{rangs récolté] +8*6*4*2[l’em-} placement des bennes]. Et il y aura 384 chemins dans le graphe (8*6*4*2), c’est à dire 384 façons de récolté le champ.

De façon générale, dans ce cas simple, si n est le nombre de rangs, alors le nombre exact d’états est 1 +qn

k=22k+1.k!

5 _{et le nombre de chemins est 2}n_.n!

Benne B B R2 R3 R4 R1 R2 R3 R1 R2 R3 R2 R3 R4 B B B B B B B B B B B B R2 R3 R1 R4 Benne orientation directe orientation inverse R2 _R3 R1 R4 orientation directe orientation directe orientation inverse orientation inverse

Figure 5.12 – Exemple de graphe d’exploration pour n = 4 et C1 ≡ 1 rang Supposons maintenant que, comme dans la réalité, la capacité de la machine soit suffisamment grande pour récolter plusieurs rangs à la suite (ici on ne précise pas la limite, HM peut donc a chaque fois soit récolter un autre rang soit vider ses trémies). Comme dans l’exemple précédent, HM commence à l’emplacement des bennes et elle a 4 rangs à récolter dans l’orientation directe ou inverse (8 possibilités). Si HM

récolte un rang, elle a alors le choix entre aller à l’emplacement des bennes pour vider ou alors récolter un des 3 rangs non récoltés, dans le sens inverse du précédent (soit en tout 4 possibilités). De l’emplacement des bennes, il reste 3 rangs à récolter, avec la possibilité de choisir entre récolter selon l’orientation directe ou l’orientation inverse, soit 6 possibilités. En ayant récolté 2 rangs sur les 4, nous avons déjà identifié 8×(3+6) chemins. En continuant, le même raisonnement peut être à nouveau réalisé à partir du choix qui aura été effectué. On arrive au final a 1296 chemins possibles (8 × (6 + 3) × (4 + 2) × (2 + 1)).

De façon générale, dans ce cas simple, si n est le nombre de rangs, alors le nombre de chemins est 2n_×rn−1

k=1(2k+ k), ce qui est nettement supérieur au nombre de chemins pour C1 ≡ 1rang, et ce qui confirme les résultats de la figure 5.11 et de la table 5.2.

Influence du seuil de récolte de raisins de qualité A

Nous pouvons également observer sur la figure 5.11 que pour une même capacité de trémie, la courbe avec le code R1 est plus élevée que celle avec le code R2. Cela résulte du fait qu’une fois que la quantité Rmin de raisins A a été récoltée, HM passe à une récolte mixée, qui est plus complexe en nombre d’états. En effet, en mode mixé, les raisins A et B peuvent être mélangés dans les deux trémies, ce qui peut permettre à HM de traiter plus de rangs entre 2 vidanges. On se retrouve un peu dans le même cas que sur l’exemple simple illustré précédemment : en mode mixé, pour chaque rang, HM peut choisir soit de récolter un autre rang soit d’aller à la benne. Lorsque Rmin est plus petit, HM peut basculer plus tôt en mode mixé, donc le nombre de chemins est plus grand et par conséquence, le nombre d’états explorés est plus important.

Nous avons pu constater qu’avec l’outil dont nous disposons nous ne pouvons résoudre le problème de DHP que pour un nombre maximal de rangs égal à 9. Afin de pallier cette limitation nous allons maintenant faire appel à une fonctionnalité proposée par UppAal-CORA, la fonction de remaining, qui permet d’optimiser le nombre de chemins parcourus. Cette fonction est expliquée ci-après.