Procédure de dégagement à long horizon physique
Objectif
Guider l'ordonnancement des candidats sur de nombreux retraits en utilisant un retour d'information physique de confiance. Les traces mesurées soutiennent deux schémas pratiques : essayer une autre direction disponible après une collision de chemin, et lorsque le bloqueur signalé a lui-même une extraction acceptée, réévaluer la cible bloquée dans l'état modifié. Ces schémas guident les requêtes ; ils ne garantissent pas l'achèvement de la tâche. Chaque retrait accepté nécessite une validation physique.
Déclencheurs observés
Appliquer lorsqu'un candidat actuellement amovible reçoit un résultat path_collision de confiance. Enregistrer ses bloqueurs signalés et l'état exact. Les preuves montrent à la fois des directions alternatives acceptées dans le même état (L01, L02, L04, L05) et le retrait accepté d'un bloqueur signalé suivi d'un retrait accepté ultérieur de la cible précédemment bloquée (L01 : 10 bloqué par 11, 11 retiré, puis 10 retiré ; L04 : 5 bloqué par 9, 9 retiré, puis 5 retiré). L04 montre également une cible avec plusieurs directions rejetées acceptée dans une autre direction disponible.
Il s'agit d'une preuve d'ordonnancement à long horizon, pas d'une stratégie universelle. L05 a épuisé son budget de vérification sans atteindre l'objectif malgré des retraits acceptés et des essais de direction répétés.
Actions numérotées du planificateur
- Établir l'état actuel. Lister uniquement les candidats actuellement amovibles et leurs actions disponibles. Conserver un enregistrement d'état exact des résultats de requêtes précédentes.
- En cas de collision, enregistrer l'observation. Stocker l'identité de l'état, la cible, la direction, les bloqueurs, le résultat et le statut de validation. Une requête de retrait échouée ne valide pas et ne modifie pas l'état physique ; elle seule ne nécessite pas de restauration de point de contrôle.
- Essayer les directions disponibles pour la même cible. Les ordonner en utilisant la géométrie disponible et les vecteurs monde, si fournis. Les étiquettes de direction seules n'établissent pas l'orientation monde. Interroger chaque candidat choisi avec le validateur de confiance. Une collision pour une direction n'interdit pas la cible dans d'autres directions.
- Utiliser les bloqueurs nommés comme indices d'ordonnancement. Si la cible reste bloquée, considérer les bloqueurs amovibles actuels nommés par le validateur. Cela ne fait que prioriser un test ; cela ne prouve pas une relation de support ou que la suppression du bloqueur dégagera le chemin.
- Valider chaque retrait. Valider uniquement lorsque le validateur de confiance accepte le retrait proposé. Après validation, utiliser l'état physique résultant et rafraîchir la disponibilité des candidats, les bloqueurs et les directions.
- Reconsidérer les cibles différées après des changements pertinents. Lorsqu'un bloqueur a été retiré ou que l'état change autrement, interroger à nouveau la cible différée si disponible. Les rejets restent liés à leur état et action exacts enregistrés. Les enregistrements d'état exact survivent à la restauration ; ne pas réessayer un échec connu inchangé. Un état différent nécessite une nouvelle évaluation, pas une hypothèse de succès.
- Continuer avec les candidats restants et signaler les limites. Si les actions testées échouent, préserver les actions non testées et indiquer seulement qu'aucune action testée n'a été acceptée dans cet état. Ne pas en déduire que l'assemblage est impossible à démonter.
Retour d'information physique de confiance attendu
Une requête de collision rejetée identifie un chemin testé et peut nommer des bloqueurs ; ce n'est pas un retrait. Un résultat accepté et validé doit confirmer le composant retiré et l'état physique modifié. La réévaluation après le retrait du bloqueur peut alors produire un nouveau retrait accepté, comme observé dans L01 et L04. Ces observations n'établissent pas de causalité au-delà de la séquence mesurée et ne prédisent pas une acceptation future.
Applicabilité aux codes Généré-B et Graphe/DFS fixe C
- Code généré-B : Utiliser la procédure pour ordonner ses propres requêtes de candidats disponibles et conserver le retour d'état exact. Préserver les actions non testées. Ne pas remplacer l'exécution, la validation ou le suivi d'état de l'hôte.
- Graphe/DFS fixe C : Utiliser ce document uniquement pour classer les actions actuellement disponibles. Le DFS fixe contrôle le parcours et le timing de restauration. Le document ne modifie pas ce contrôle de flux ni ne prescrit de restauration. Les requêtes échouées seules ne nécessitent pas de restauration. Préserver les enregistrements d'échec d'état exact lors de la restauration et éviter de réessayer un échec connu inchangé.
Limites et statut des preuves
L01, L02 et L04 ont atteint leurs objectifs mesurés ; L05 non, malgré de nombreux retraits acceptés et 40 restaurations. L03 est exclu car les avertissements natifs du moteur ont rendu ses preuves de procédure physique inutilisables. Ce sont des observations de développement, pas une validation indépendante. Les CAD d'évaluation et de validation indépendante sont retenus.
L'alternance des directions et la priorisation des bloqueurs nommés sont des schémas d'ordonnancement de requêtes observés. L'explication selon laquelle le retrait d'un bloqueur permet la cible est une hypothèse au-delà de la séquence mesurée. Ne pas en déduire des supports cachés, des rotations, des changements de préhension ou des exemptions de collision. Ne pas prétendre qu'un retour en arrière réussi constitue une réparation : bien que L05 enregistre des restaurations, les preuves n'établissent pas un retour en arrière réussi. Cette procédure ne remplace pas les directives antérieures de dégagement spécifique à la direction ou de réparation des défaillances et n'établit pas un succès universel du démontage.