Referentie

Projectformaat (YAML)

Een project is één YAML-bestand, eventueel opgesplitst met includes:. Paden zijn relatief aan het projectbestand. Het JSON Schema (arnodiqa schema, ook in docs/arnodiqa.schema.json) geeft autocomplete en validatie in VS Code via de eerste regel van het bestand. Dit is het echte demoproject:

# 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 is de formaatversie (nu 2). Oudere projecten worden automatisch gemigreerd, nieuwere geweigerd met een foutmelding.
2. includes zet een sectie (hier de systeemvariabelen) in een eigen bestand, zodat teams minder merge-conflicten hebben.
3. networks bevat één netwerk per applicatiekanaal (channel: 1 = CAN1), met naam en bitrate.
4. bus: can_fd gaat samen met data_bitrate. Optioneel zijn sample_point, fd_mode: iso|non_iso en listen_only.
5. hardware is de kanaalmapping: virtual (benoemd virtueel netwerk), een backend-specifieke vorm zoals pcan, vector, kvaser, socketcan, slcan of gs_usb (zie arnodiqa hw list), of de generieke vorm device. In de simulated-busmodus zijn alle netwerken virtueel, ongeacht de mapping.
6. databases noemt de DBC-bestanden voor decodering, triggers op signaalwaarden en de Interaction Layer.
7. measurement bevat mode: online|offline, working_mode: real_bus|simulated_bus, duration, event-sortering, offline-bronnen en pacing.
8. measurement_setup.blocks beschrijft de analyse-dataflow, zie Measurement Setup.
9. Bestandsnamen kunnen field codes bevatten. Zonder input hangt een blok aan source (alle events).
10. input koppelt blokken tot een keten, of voegt er meerdere samen met een lijst van ids.
11. Tijden schrijf je als 50ms, 1.5s, 2min (eenheden ns, us, ms, s, min, h, d).
12. simulation.restbus regelt de restbussimulatie. Elke node uit de databases wordt een Interaction Layer-node die zijn berichten zendt volgens de send types en cyclustijden uit de DBC. Met exclude: [ECM] laat je een node weg om een echte ECU te testen; il.counters definieert alive counters. Daarnaast zijn er simulation.nodes voor afzonderlijke nodes, bijvoorbeeld een CAPL-programma (kind: capl, file: capl/gateway.can), en replay-blokken. Panels staan onder panels: als YAML-bestanden.

Waardetypes

Measurement Setup

De Measurement Setup is een boom (DAG) van functieblokken met als wortel de meetbron (source). Takken lopen parallel. Een blok met meerdere inputs voegt die in tijdsvolgorde samen en geeft een event dat via twee takken binnenkomt slechts één keer door. Het demoproject als graaf:

Bloktypes

Alle blokken hebben id, input (standaard source, of een lijst voor merge) en comment.

Field codes

In bestandsnamen van logging-blokken kun je deze field codes gebruiken: {MeasurementStart} {MeasurementIndex} {IncMeasurement} {IncTrigger} {IncSize} {IncTime} {LoggingBlock} {ConfigName} {TriggerCondition} {@NS::Var}.

Overbelasting

In real time wacht de meting nooit. Volle queues worden geteld (mainQueueDropped, lost) en leveren exitcode 5. In simulated- of offline-modus ("as fast as possible") wachten producenten en gaat er niets verloren. UI-subscripties laten altijd de oudste events vallen, met een teller.

Architectuur

Zie Hoe het werkt voor het diagram. Kort samengevat bestaat het product uit Rust-crates (bf-core, bf-hw, bf-db, bf-log, bf-project, bf-engine, bf-cli, bf-diag, bf-test, de script-VM) en een Tauri/React-applicatie die alleen via de Session-facade met de engine communiceert.

IPC-contract (UI ↔ engine)

JSON-velden zijn camelCase, tijden zijn nanoseconden sinds meetstart (i64), CAN-ID's zijn strings ("0x123", "0x18FEF100x").