Référence

Format de projet (YAML)

Un projet est un seul fichier YAML, éventuellement découpé avec includes:. Les chemins sont relatifs au fichier de projet. Le schéma JSON (arnodiqa schema, également fourni dans docs/arnodiqa.schema.json) apporte l'autocomplétion et la validation dans VS Code grâce à la première ligne du fichier. Voici le projet de démonstration tel qu'il est livré :

# yaml-language-server: $schema=../../docs/arnodiqa.schema.json
#
# Arnodiqa demo project: two virtual CAN channels with a remaining bus
# simulation built from the databases (every database node runs the CAN
# interaction layer), so it runs without hardware:
#
#   arnodiqa run examples/demo/demo.yaml --simulated --duration 10s
#
version: 21
name: Demo
description: PowerTrain (CAN FD) and Comfort (CAN) on virtual networks.
includes:2
  system_variables: sysvars.yaml
networks:3
- name: PowerTrain
  channel: 1
  bus: can_fd4
  bitrate: 500000
  data_bitrate: 2000000
  hardware:5
    virtual:
      network: vcan1
  databases:6
  - powertrain.dbc
- name: Comfort
  channel: 2
  bitrate: 500000
  hardware:
    virtual:
      network: vcan2
  databases:
  - comfort.dbc
measurement:7
  working_mode: simulated_bus
  duration: 10s
measurement_setup:8
  blocks:
  - logging:
      id: Logging
      file: logs/{ConfigName}_{MeasurementIndex}.blf9
  - filter:
      id: PowerTrainOnly
      action: pass
      rules:
      - channels: [1]
  # Fires on the first EngineData frame with EngineSpeed = 800 rpm (the
  # database start value); later ones are ignored while the block is open.
  - trigger:
      id: HighRpm
      input: PowerTrainOnly10
      mode: single
      pre_trigger: 50ms11
      post_trigger: 200ms
      conditions:
      - event:
          signal:
            message: EngineData
            signal: EngineSpeed
            op: '=='
            value: 800
      max_triggers: 1
  - logging:
      id: HighRpmLog
      input: HighRpm
      file: logs/high_rpm_{IncMeasurement}.asc
  - view:
      id: Trace
      kind: trace
  - view:
      id: Statistics
      kind: statistics
simulation:12
  # All nodes of both databases become IL nodes. To test a real ECU, list it
  # under `exclude` (e.g. `exclude: [ECM]`) and connect the hardware.
  restbus:
    il:
      counters:
      - message: EngineData
        signal: AliveCounter

1. version indique la version du format (actuellement 2). Les projets plus anciens sont migrés automatiquement, les plus récents sont refusés avec un message d'erreur.
2. includes place une section (ici les variables système) dans un fichier distinct, ce qui réduit les conflits de fusion au sein d'une équipe.
3. networks définit un réseau par canal applicatif (channel: 1 = CAN1), avec son nom et son débit.
4. bus: can_fd s'accompagne de data_bitrate. Les champs sample_point, fd_mode: iso|non_iso et listen_only sont facultatifs.
5. hardware définit l'affectation du canal : virtual (réseau virtuel nommé), une forme propre au back-end telle que pcan, vector, kvaser, socketcan, slcan ou gs_usb (voir arnodiqa hw list), ou la forme générique device. En mode bus simulé, tous les réseaux sont virtuels, quelle que soit l'affectation.
6. databases liste les fichiers DBC utilisés pour le décodage, les déclencheurs sur valeurs de signaux et la couche d'interaction.
7. measurement regroupe mode: online|offline, working_mode: real_bus|simulated_bus, duration, le tri des événements, les sources hors ligne et la cadence de relecture (pacing).
8. measurement_setup.blocks décrit le flux de données d'analyse ; voir Measurement Setup.
9. Les noms de fichiers peuvent contenir des field codes. Un bloc sans input est rattaché à source (tous les événements).
10. input enchaîne les blocs, ou en fusionne plusieurs lorsqu'il contient une liste d'identifiants.
11. Les durées s'écrivent 50ms, 1.5s, 2min (unités ns, us, ms, s, min, h, d).
12. simulation.restbus configure la simulation de bus résiduel. Chaque nœud des bases de données devient un nœud de la couche d'interaction, qui émet ses messages selon les types d'envoi et les temps de cycle définis dans le DBC. exclude: [ECM] retire un nœud afin de tester un calculateur réel ; il.counters définit les compteurs de vie. S'y ajoutent simulation.nodes pour des nœuds individuels, par exemple un programme CAPL (kind: capl, file: capl/gateway.can), et les blocs replay. Les panneaux sont déclarés sous panels: sous forme de fichiers YAML.

Types de valeurs

Measurement Setup

Le Measurement Setup est un arbre (DAG) de blocs fonctionnels dont la racine est la source de mesure (source). Les branches s'exécutent en parallèle. Un bloc à plusieurs entrées les fusionne dans l'ordre chronologique et ne transmet qu'une seule fois un événement arrivé par deux branches. Voici le projet de démonstration sous forme de graphe :

Types de blocs

Tous les blocs ont id, input (source par défaut, ou une liste pour fusionner) et comment.

Field codes

Les noms de fichiers des blocs de journalisation acceptent les field codes suivants : {MeasurementStart} {MeasurementIndex} {IncMeasurement} {IncTrigger} {IncSize} {IncTime} {LoggingBlock} {ConfigName} {TriggerCondition} {@NS::Var}.

Surcharge

En temps réel, la mesure n'attend jamais. Les files pleines sont comptabilisées (mainQueueDropped, lost) et donnent le code de sortie 5. En mode simulé ou hors ligne (« as fast as possible »), les producteurs attendent et rien n'est perdu. Les abonnements de l'interface abandonnent toujours les événements les plus anciens, avec un compteur.

Architecture

Le diagramme figure dans Fonctionnement. En résumé, le produit se compose de crates Rust (bf-core, bf-hw, bf-db, bf-log, bf-project, bf-engine, bf-cli, bf-diag, bf-test, la machine virtuelle de script) et d'une application Tauri/React qui communique avec le moteur uniquement via la façade Session.

Contrat IPC (interface ↔ moteur)

Les champs JSON sont en camelCase, les temps sont exprimés en nanosecondes depuis le début de la mesure (i64) et les identifiants CAN sont des chaînes ("0x123", "0x18FEF100x").