Skip to content

Refactor ADJv3 & Protections #94

Description

@JavierRibaldelRio

Context

This issue tracks the ST-LIB implementation of ADJv3, as specified in the
first Communications meeting (2026-09-10). ADJv3 builds on ADJv2, with the main
conceptual change being the decoupling of messages and protections:
previously a protection was just a message of a given type; now they have
independent packet structures.

1. Numeric id for packets/orders/measurements

  • Replace the textual id with a numeric identifier shared across packets,
    orders, and measurements, range [0, 8191] (uint13).
  • IDs [0, 511] are reserved as special IDs (not assigned to
    packets/orders/protections).
  • Keep the old textual id under a new field alias, since codegen still
    depends on it for variable naming and it's needed for logging-view
    compatibility.

2. protections decoupled from messages

Each measurement in <BOARD>_measurements.json gets an optional
protections array (max 7 entries):

{
  "type":  "<protection type>",
  "value": [number] | [number, number],
  "fault": boolean?,
  "time":  "<number><unit>?"
}
  • type: one of the types declared in general_info.json →
    protectionTypes (Above, Below, Equal, NotEqual, Range).
  • value: single limit, or [min, max] for Range.
  • fault: default true → emitted as fault; false → warning.
  • time: only for time-accumulation protections (e.g. "500ms", "3s"),
    default 0.

protectionTypes definition in general_info.json:

{
  "protectionTypes": {
    "<protection_name>": {
      "range":    boolean?,
      "text":     "<template>",
      "textTime": "<template>?"
    }
  }
}

Protection packet layout

Fixed 48-bit header (id + timestamp) followed by a value field whose
size matches the monitored measurement's type (8–64 bits):

  • id (bits 0–15): numeric protection id.
  • timestamp (bits 16–47): hour/min/sec (1 byte each) + 1 reserved byte. (NOT RATIFICATED YET)
  • value (bits 48+): same size/encoding as the monitored measurement.

Composite id (bit-packing)

Since packets, orders, and protections share the same 16-bit id
field, the top 3 bits (pos) disambiguate:

  • pos = 000: normal id (packet/order/measurement), remaining 13 bits = id.
  • pos = 001–111: protections[0]–protections[6] of the measurement
    identified by the low 13 bits.

id = (pos << 13) | id_measurement

Transmitted as a single little-endian uint16.

  1. message refactor

New packet layout:

  • id (2 bytes, uint16): reuses message_ids from general_info.json.
    New value: 13 = panic (previously masked as fault in ST-LIB).
  • timestamp (4 bytes): same short format as protections (hour/min/sec
    • 1 reserved byte).
  • origin (up to 48 bytes, null-terminated string): source file path.
  • message (up to 320 bytes, null-terminated string): message content.

message_ids in general_info.json:

{
"message_ids": {
"fault": 10,
"warning": 11,
"info": 12,
"panic": 13
}
}

  1. Add mac field to board info

Add a mac field (board MAC address) to be used in codegen and validated by
adj-validator, to catch invalid/duplicate MACs at build time (motivated by
MAC-related issues found during H11 EHW).

Open questions (to resolve in next meeting, not blocking this issue's scope)

  • Reserve a special-ID range for the BLCU.
  • ADJ commit verification at TCP connection start.
  • Custom keep-alive mechanism.
  • Whether to keep the units module or drop it.
  • Support for measurement arrays (pending Víctor's proposal).

Acceptance criteria

  • id becomes numeric (uint13) across packets/orders/measurements;
    legacy textual id preserved as alias.
  • protections array support in _measurements.json (max 7),
    with protectionTypes read from general_info.json.
  • Protection packet encode/decode matches the layout above.
  • Composite id (pos + id_measurement) encode/decode implemented.
  • message packet refactored to the new layout, panic type added.
  • mac field added to board info, validated by adj-validator.

See ACTA

Metadata

Metadata

Labels

No labels
No labels

Type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions