Processus EX (détail technique)¶
Extraction : code séquence EX (OF_TYPE_SEQUENCE = extraction). Extrait le produit du bois par passage d'eau, en deux demi-cycles sur un extracteur, dans une zone partagée par deux extracteurs.
Ce qui rend EX particulier¶
- Deux demi-cycles par cycle : DC1 (bois neuf + eau) puis DC2 (bois extrait + eau neuve). Le même BPM
EX - Extractionsert les deux, routé par le numéro d'étape (40 = DC1, 60 = DC2). - Zone partagée + verrou : les deux extracteurs partagent la zone
ZONE_EX_ID. Un verrou de zone empêche de lancer le même demi-cycle sur les deux en même temps. Acquis à l'extraction, relâché tout de suite après (étapes 45 / 65). - Transferts de conteneurs en parallèle : les conteneurs de provenance sont amenés par deux retourneurs, traités en parallèle (pas de séquencement).
- Topologie à nœuds fils : chaque extracteur a deux nœuds
cycle_1/cycle_2(les demi-cycles), qui portent les E/S de fonction et les champs présence/conteneur. Rappel : demi-cycle 1 = nœudcycle_2, demi-cycle 2 = nœudcycle_1.
Chaîne de planification¶
Générique, sauf l'entrée et le callback (spécifiques EX) :
flowchart LR
A[EX - Planification des cycles] --> B[ALL - Vérification de planification]
B --> C[ALL - Création d'un cycle]
C --> D[EX - Planification - callback]
D -->|si pas dernier cycle| C
- Entrée EX : formulaire (OF, poids, extracteur, recette, date, provenances conteneur R1/R2). Résout
ep_iddepuis l'extracteur, posesequence_type = "EX", empaquette les provenances dans lepayload, lance la vérification. - Callback EX : écrit
CYCLE_PROVENANCE_CONTENEUR_R1/R2sur le cycle créé, reboucle sur la création tant que l'OF n'est pas entièrement planifié.
Étapes d'exécution¶
SEQUENCE_ORDER["EX"] = [10, 20, 40, 45, 50, 60, 65, 70, 80, 120, 130, 1401…1404, 150, 1601…1604, 170, 180].
| Étape | BPM | Rôle |
|---|---|---|
| 10 | ALL - Vérifications des prérequis |
Contrôles génériques + spécifique EX (config extracteur, conteneurs, complétion). |
| 20 | EX - Gestion des transferts de conteneur |
Amène les conteneurs de provenance (orchestrateur parallèle). |
| 40 | EX - Extraction |
Demi-cycle 1 (bois neuf + eau). |
| 45 | EX - Libération du verrou |
Relâche le verrou de zone après DC1. |
| 50 | ALL - Contrôle laboratoire |
Prélèvement / contrôle. |
| 60 | EX - Extraction |
Demi-cycle 2 (bois extrait + eau neuve). |
| 65 | EX - Libération du verrou |
Relâche le verrou après DC2. |
| 70 | ALL - Contrôle laboratoire |
Prélèvement / contrôle. |
| 80 | EX - Gestion des transferts de conteneur |
Place les bennes à copeaux de sortie (même orchestrateur parallèle que l'étape 20, config TRANSFERT_CONFIG["80"]). |
| 120 | EX - Choix de destination |
Choix de la destination du produit : cuvons ou concentration (cuve intermédiaire). |
| 130 | ALL - Vérification présence |
Présence + état d'un cuvon prêt (config-driven), si destination cuvons. |
| 1401 / 1403 | ALL - Gestion du soulèvement de couvercle |
Soulèvement du couvercle. |
| 1402 / 1404 | ALL - Appel robot |
Montée du couvercle / alimentation du cuvon. |
| 150 | ALL - Vidage de cuvon |
Remplit le cuvon. |
| 1601 / 1603 | ALL - Appel robot |
Évacuation du cuvon plein / descente du couvercle. |
| 1602 / 1604 | ALL - Gestion du soulèvement de couvercle |
Soulèvement du couvercle. |
| 170 | ALL - Clôture de cycle |
Clôture de l'entité cycle. |
| 180 | ALL - Déclaration de fin d'ordre de fabrication |
Décide si l'OF est terminé (sinon cycle suivant). |
Le bloc cuvons (130 → 1604) est le même que CC
À partir de l'étape 130, EX et CC partagent exactement les mêmes BPM ALL - … (présence, couvercle, appel robot, vidage), pilotés par PRESENCE_CONFIG, ROBOT_ACTIONS et la topologie par ep_id. Seule la config diffère.
Étape 10 : prérequis EX¶
Le générique ALL - Vérifications des prérequis fait les contrôles communs, puis délègue au spécifique EX - Vérifications des prérequis, qui enchaîne trois familles dans le bon ordre :
- Config extracteur (
cycle_1/cycle_2/zone_slotprésents) → erreur dure (non complétable). - Conteneurs de provenance présents et disponibles (plein + en attente) → erreur d'état.
- Champs métier (recette, lots) → si manquants,
userTaskde complétion → écriture sur l'entité → reboucle.
Transferts de conteneurs : le triptyque parallèle (étape 20)¶
Comme le moteur ne fait pas de parallelGateway, le parallélisme passe par des instances séparées et la synchronisation par état relu sur le cycle :
flowchart TD
O[EX - Gestion des transferts<br/>orchestrateur] -->|par retourneur attendu| D1[EX - Demande de déplacement R1]
O -->|par retourneur attendu| D2[EX - Demande de déplacement R2]
D1 --> J[EX - Conteneur arrivé<br/>join sur le cycle]
D2 --> J
J -->|dernier arrivé seulement| N[ALL - Prochaine étape → 40]
EX - Gestion des transferts: lit les provenances sur le cycle, lance une instance par retourneur attendu, n'avance pas.EX - Demande de déplacement conteneur(par retourneur) : contrôle pinces ouvertes (RETOURNEUR_AUTORISATION_SELECTION), remet la présence à faux,userTaskde placement (ou appel AMR), puis lance le join.EX - Conteneur arrivé(join) : pose la présence, relit les deux présences sur le cycle et les compare aux provenances attendues. Seul le dernier relanceProchaine étape.
Extraction (étapes 40 / 60)¶
EX - Extraction résout le nœud demi-cycle (dc_id) selon l'étape, puis enchaîne les garde-fous dans cet ordre (chacun échoue avant de prendre le verrou) :
- conteneurs de provenance présents (uniquement DC1),
- demi-cycle valide (
cycle_1/cycle_2), - verrou de zone libre (pas le même DC sur l'autre extracteur),
- extracteur non déjà en cours (idempotence),
- acquisition du verrou → paramètres (
MvP > CSG…, recette) → commandeMARCHE.
Il n'avance pas : c'est l'événement de fin d'extraction de l'automate qui relance Prochaine étape vers le contrôle labo.
Verrou de zone¶
Porté par ZONE_EX_ID, deux slots (ZONE_EX_EXTRACTEUR_1/2) résolus via EXTRACTEURS[ep_id].zone_slot. Acquis dans EX - Extraction, relâché par EX - Libération du verrou (→ ZONE_EX_STATUT_AUCUN) aux étapes 45 / 65, juste après chaque extraction : l'autre extracteur récupère le demi-cycle sans attendre la fin du cycle complet.
Sortie des bennes à copeaux (étape 80)¶
L'étape 80 réutilise le même orchestrateur que l'étape 20 (EX - Gestion des transferts de conteneur), piloté par TRANSFERT_CONFIG["80"]. Différence : une benne considérée présente (car vidée en amont) est la benne à remplir. Le critère est donc inversé par rapport aux conteneurs d'entrée (absent → à amener). Le nombre de bennes de sortie suit le nombre de provenances du cycle.
Une fois les bennes placées, l'étape 80 avance directement vers le choix de destination (120) : il n'y a pas d'étapes 90/100/110 séparées, tout le placement se fait dans l'orchestrateur de l'étape 80.
Choix de destination (étape 120)¶
EX - Choix de destination lit le champ CYCLE_DESTINATION du cycle. S'il n'est pas déjà renseigné (Cuvons ou Concentration), un userTask le demande à l'opérateur, l'écrit sur le cycle, puis reboucle. Ensuite :
Cuvons→ poursuite vers le bloc cuvons (étape 130).Concentration(cuve intermédiaire) → forçage vers l'étape 170 (clôture), en sautant le conditionnement cuvon.
Ce n'est pas une clôture
Cette étape oriente le produit. Elle ne clôture pas l'entité (voir vocabulaire). La vraie clôture est l'étape 170. Le BPM a été renommé EX - Choix de destination (anciennement « Choix de fin de cycle ») pour lever l'ambiguïté.
Configuration EX¶
SEQUENCE_ORDER["EX"]/SEQUENCE_ACTIONS["EX"].EXTRACTEURS(code,zone,zone_slot,cycle_1,cycle_2),EXTRACTEURS_INVERSES,RETOURNEURS,ZONE_EX_ID.- Présence :
EXTRACTEUR_PRESENCE_BENNE_1/2,EXTRACTEUR_CONTENEUR_1/2,RETOURNEUR_PRESENCE_CONTENEUR,RETOURNEUR_AUTORISATION_SELECTION. TRANSFERT_CONFIG["20"](conteneurs d'entrée,presence: retourneur) et["80"](bennes de sortie,presence: benne), lus par l'orchestrateur et le join.PRESENCE_CONFIG["EX"]["130"](cuvon, avecetat_ko: CONTENEUR_ST_SALE) etROBOT_ACTIONS["EX"](gestes cuvon 1402/1404/1601/1603).