Equipements à l'arrêt

Equipements à l'arrêt

Ce guide documente la marche à suivre pour transmettre les états d'indisponibilité des équipements sur intentPlatform.
Les arrêts des équipements sont matérialisés par des événements rattachés au patrimoine.
  • Équipements télésurveillés : Les pannes doivent être envoyées automatiquement par vos systèmes.
  • Équipements non télésurveillés : Le technicien déclare l'équipement à l'arrêt ou en service suite à son passage.

Sur quel élément de patrimoine rattacher les arrêts ?

Les événements de mise à l'arrêt sont rattachés à un stream lui même rattaché directement à l'Équipement (Asset).

Combien de streams dois-je créer ?

Il vous faudra créer 1 stream par équipement. Ce stream recevra tous les événements de mise à l'arrêt, de maintenance ou de travaux liés à cet équipement spécifique.

Comment transmettre les données ?

Pour transmettre les données, vous devez créer un stream de type events et l'alimenter via l'API Data v1.

1. Création du flux (Stream)

Il faut créer un stream avec les caractéristiques suivantes :
  • type : events
  • dataType : alert
  • activityKey : LiftState
Requête : POST api/data/v1/streams
{
"reference": "ASC-213BO98_etat_de_fonctionnement",
"label": "Mise à l'arrêt de l'équipement ASC-213BO98",
"type": "events",
"tags": {
"intent_assetReference": "ASC-213BO98",
"intent_activityKey": "LiftState",
"intent_dataType": "alert",
"intent_contractReference": "CONTRACT-10"
}
}

  • Référence : Format recommandé : {{referenceEquipement}}_etat_de_fonctionnement.
  • Label : Doit être explicite pour les utilisateurs finaux (ex: "Etat de fonctionnement - ASC-213BO98").

2. Alimenter le stream en données

Une fois le stream créé, vous l'alimentez au fil de l'eau via le endpoint events.

Déclarer un début d'arrêt (Ouverture de l'alerte)

Requête : POST api/data/v1/events
{
"streamReference": "ASC-213BO98_etat_de_fonctionnement",
"payload": [
{
"type": "Mise à l'arrêt",
"status": "Début",
"timestamp": 1504063834184,
"information": {
"Motif": "Problème technique",
"Date prévisionnelle remise en service": "2026-04-09T10:00:00Z",
"Commentaire technicien": "Les câbles sont trop usés. Risque de sécurité détecté."
}
}
]
}
Champ
Description
Motif
Raison standard de l'arrêt (ex: Panne, Sécurité, Vandalisme).
Commentaire technicien
Détails complémentaires saisis sur le terrain.
Date prévisionnelle remise en service
Format ISO 8601. Aide à la planification pour le gestionnaire.

Déclarer une remise en service (Clôture de l'alerte)

Pour fermer l'alerte sur la plateforme, envoyez un événement avec le statut FIN.
Requête : POST api/data/v1/events
{
"streamReference": "ASC-213BO98_etat_de_fonctionnement",
"payload": [
{
"type": "Mise à l'arrêt",
"status": "Fin",
"timestamp": 1504063934184
}
]
}

3. Logique des types et status autorisés

Sur intentPlatform, une alerte est ouverte par un événement Début et fermée par un événement Fin. L'état de l'équipement basculera automatiquement en fonction du dernier événement reçu.
type
status
Résultat métier
Standard intentReady
Mise à l'arrêt
Début / Fin
Indisponibilité subie (panne).
Maintenance
Début / Fin
Indisponibilité programmée (entretien).
Travaux
Début / Fin
Indisponibilité longue (modernisation).
Si vous n'êtes pas en capacité en dissocier les arrêts des équipements pour Maintenance et Travaux, toutes les mises à l'arrêt seront donc du type Mise à l'arrêt

Etat de l'équipement à confirmer

Lors de la réception d'un appel client ou d'une demande d'intervention, vous pouvez transmettre un événement A confirmer pour signaler qu'un équipement est potentiellement en panne.
type
status
Résultat métier
Standard intentReady
Mise à l'arrêt
A confirmer / Début / Fin
Indisponibilité subie (panne).

Quand transmettre les données?

La fréquence de transmission dépend de la connectivité de vos actifs et de vos processus de gestion :

Équipements télésurveillés

Les données doivent être transmises en temps réel. Dès que vos systèmes automatiques détectent un changement d'état, l'événement doit être poussé vers l'API.

Équipements non télésurveillés

Deux options s'offrent à vous selon la maturité de votre Système d'Information (SI) :
    Synchronisation via votre SI : Si votre outil de gestion centralise l'état de fonctionnement des équipements, transmettez un événement de manière asynchrone à chaque mise à jour de cet attribut dans votre base de données.
    Saisie terrain (Workflow technicien) : Si l'information dépend exclusivement du passage d'un intervenant, transmettez le statut de l'équipement en même temps que vos comptes-rendus d'intervention.
Exemple de flux pour l'option 2 :
  • Signalement : À la création de la demande d'intervention (ex: signalement client), transmettez l'événement Mise à l'arrêt avec le statut A confirmer.
  • Clôture d'intervention : Une fois l'intervention terminée, le technicien valide l'état réel :
  • L'équipement est toujours en panne ⟶ Publication Mise à l'arrêt / Début.
  • L'équipement est réparé ⟶ Publication Mise à l'arrêt / Fin.
Avec l'option 2, la mise à jour de l'état sur la plateforme est strictement liée à l'existence d'une intervention. Si un équipement est remis en service sans déplacement (ex: relance à distance), vous devrez tout de même générer un événement technique pour clôturer l'alerte sur intentPlatform.

Critères de validation

Test
Résultat attendu
Création d'un flux d'alerte
Stream créé avec l'ensemble des caractéristiques attendues
Alimentation d'un flux d'alerte
Transmission des événements d'ouverture et fermeture d'une alerte sur un stream
Alimentation d'un flux d'alerte avec différents types d'alerte
Transmission des événements d'alerte sur un même stream pour une mise à l'arrêt, une maintenance, des travaux