Modèles Twin

Un modèle (.twin.yaml) définit un type d’actif industriel. Voici la structure.

Exemple minimal

schema_version: "2"
model:
  name: my-sensor
  description: "Simple capteur de température"

members:
  temperature:
    kind: variable
    data_type: Double
    access: read
    unit: degC
    generator:
      type: noise
      center: 22.0
      stddev: 0.5

Structure complète du schéma

schema_version: "2"
model:
  name: <identifiant>          # Minuscules, chiffres, tirets. 1-64 caractères.
  namespace: <chaine-pointée>  # Optionnel. ex. com.acme.pompes
  description: <chaine>

parameters:
  <nom>:
    type: float | int
    default: <nombre>
    min: <nombre>             # Optionnel
    max: <nombre>             # Optionnel
    unit: <unité-ingénierie>  # Optionnel

methods:
  <NomMethode>:
    description: <chaine>
    input_arguments:          # Optionnel
      <nom_arg>:
        data_type: Double | Float | Int32 | UInt16 | UInt32 | Boolean | String
        unit: <chaine>        # Optionnel
        description: <chaine>
    runtime:                  # Optionnel -- rend la méthode exécutable
      type: set-members | set-parameters | clear-faults
      writes:                 # Pour set-members et set-parameters
        - member: <nom>
          value: <littéral>   # Ou argument: <nom_arg>
    output_arguments:
      <nom_arg>:
        data_type: <type>
        description: <chaine>

members:
  <nom>:
    kind: variable | property
    data_type: Double | Float | Int32 | UInt16 | UInt32 | Boolean | String
    access: read | readwrite | write
    unit: <unité-ingénierie>    # Optionnel
    eu_range: [<min>, <max>]    # Optionnel
    default: <valeur>           # Optionnel
    enum_values: [...]          # Optionnel, pour les membres String
    generator: { ... }          # Optionnel, pilote la valeur à chaque tick
    binding: { ... }            # Optionnel, lie à l'état d'exécution

lifecycle:
  stages:
    - name: <chaine>
      duration_hours: [<min>, <max>]
      effects:
        <nom_membre>: { multiplier: <n>, offset: <n> }

faults:
  - name: <chaine>
    trigger:
      lifecycle_stage: <étape>    # Optionnel
      condition: "<expr>"         # Optionnel, ex. "pressure < 2.5"
      probability: <0-1>
    effects:
      <nom_membre>:
        spike: <n>                # Optionnel, multiplicatif
        multiplier: <n>           # Optionnel
        offset: <n>               # Optionnel
        duration_ticks: <n>

Paramètres

Les paramètres sont des constantes réglables qui varient par instance. Référencez-les dans les générateurs avec $param.nom :

parameters:
  rated_rpm:
    type: float
    default: 1750
    min: 500
    max: 3600
    unit: rpm

members:
  speed_feedback:
    kind: variable
    data_type: Double
    access: read
    unit: rpm
    generator:
      type: noise
      center: "$param.rated_rpm"
      stddev: 5

Les templates peuvent surcharger les paramètres par instance. Le réglage variation applique une dispersion aléatoire autour des valeurs par défaut des paramètres.

Membres

Les membres sont traités dans l’ordre de déclaration. Cela est important pour les générateurs qui référencent d’autres membres — le membre référencé doit être déclaré plus tôt.

Liaisons

Des membres spéciaux peuvent se lier à l’état d’exécution au lieu d’utiliser des générateurs :

fault_active:
  kind: variable
  data_type: Boolean
  access: read
  binding:
    type: fault-active      # true quand une défaillance est active

lifecycle_stage:
  kind: variable
  data_type: String
  access: read
  binding:
    type: lifecycle-stage   # Nom de l'étape de cycle de vie actuelle

Types de liaisons disponibles : fault-active, fault-count, active-fault-code, lifecycle-stage, health-state, availability-state.

Méthodes

Les méthodes définissent des actions exécutables. Quand une méthode a un bloc runtime, elle peut être invoquée via n’importe quel protocole activé (MQTT, OPC UA et les futurs adaptateurs) :

methods:
  SetSpeed:
    description: "Définir la référence de vitesse de la pompe."
    input_arguments:
      speed_rpm:
        data_type: Double
        unit: rpm
        description: "Vitesse d'arbre demandée."
    runtime:
      type: set-members
      writes:
        - member: speed_command
          argument: speed_rpm
    output_arguments:
      accepted:
        data_type: Boolean
        description: "True si accepté."

Types d’exécution : set-members (écrire les valeurs des membres), set-parameters (écrire les paramètres), clear-faults (réinitialiser toutes les défaillances actives).

Unités d’ingénierie

Les membres et paramètres utilisent un vocabulaire contrôlé d’unités d’ingénierie (ex. rpm, bar, degC, kW, m3/h). Ces unités se propagent à toutes les sorties de protocoles — payloads MQTT, nœuds EUInformation OPC UA et tout futur adaptateur de protocole.