Files
secs-gem/interop
raphael 2fce2fad0c verify: secs4j cross-validation (independent Java implementation)
20 cross-validation checks PASS against [secs4java8] (Apache 2.0,
kenta-shimizu) — an independent SECS/HSMS implementation in Java by
a different author from a different language ecosystem.  Distinct
implementer = independent spec interpretation.  Two libraries
agreeing on wire bytes is much stronger evidence of spec-correctness
than either alone.

Coverage targets the gap the secsgem-py interop deliberately skipped
(secsgem-py's SFDL grammar couldn't easily express GEM 300 bodies
with variable lists of named scalars):

  - S1F1/F13/F17/F19/F21/F23 — establish comms + namelists
  - S2F17 — clock
  - S2F23 — trace init (5-field body)
  - S2F49 — enhanced remote command (DATAID + OBJSPEC + RCMD + params)
  - S3F17/F19/F25/F27 — full E87 carrier surface (action, slot map
                        verify, transfer with port pair, cancel)
  - S5F13/F17 — exception recovery (EXID + EXRECVRA)
  - S14F9/F11 — E94 CJ create with prjobids list, CJ delete
  - S16F5/F27 — E40 PJ command, E94 CJ command
  - S1F15 — offline cleanup

20/20 PASS against the demo equipment.  Reply S/F matches the spec
for every transaction; specific ACK values vary by equipment state
(CarrierIDUnknown for an unknown carrier is just as valid as Accept
for a known one) so we assert on the wire shape, not the result.

Ship layout:
  interop/secs4j/Dockerfile          — eclipse-temurin:21-jdk + clone
                                       + build of secs4java8 → Export.jar
  interop/secs4j/Secs4jHostHarness.java
                                     — 20 round_trip assertions; uses
                                       Secs2.list/uint4/ascii to build
                                       full GEM 300 bodies; comm.send()
                                       for arbitrary S/F pairs
  interop/secs4j_validate.sh         — orchestrator: builds image,
                                       compiles harness, starts compose
                                       server, runs Java container on
                                       the secs network against it
  .gitea/workflows/ci.yml            — secs4j-interop job in CI
  README.md                          — proof table grows to 7 commands
  .gitignore                         — *.class

After this commit our proof chain has:
  - SEMI E5 KAT          (standards body's own arithmetic)
  - tshark dissector     (Wireshark's HSMS impl)
  - secsgem-py interop   (Python reference impl)
  - **secs4j interop**   (independent Java impl)
  + 426 unit tests, 47 conformance harness checks, 100k random ops,
    YAML validation

Four independent external proofs, three of them on overlapping wire
surface from independent angles.

Plan: VERIFICATION.md §3.

[secs4java8]: https://github.com/kenta-shimizu/secs4java8

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-06-09 16:12:44 +02:00
..

secsgem-py interop harness

Cross-validates our C++ SECS-II / HSMS / GEM implementation against secsgem-py 0.3.0, the de-facto Python reference. Everything runs in Docker — no Python or secsgem-py on the host.

What it tests

Driver Peer Coverage
host_vs_cpp_server.py C++ secs_server (passive) HSMS select/separate, S1F1/F3/F11/F17/F23, S2F13/F17/F29/F33/F35/F37/F41, S5F3/F5/F7, S5F1 unsolicited, S6F11 unsolicited, S7F3/F5/F19, S10F1/F3, S1F15
secs_interop_probe (C++) passive_equipment.py (secsgem-py GemEquipmentHandler) HSMS select, S1F13/F14, S1F1/F2, S1F3/F4, clean separate
raw_gem300_harness.py C++ secs_server (passive) GEM 300 streams secsgem-py upstream doesn't ship: S3F17/F18 (E87 carrier action), S16F5/F6 (E40 PRJobCommand), S16F27/F28 (E94 CJobCommand) — built with custom SecsStreamFunction subclasses + registered custom DataItems

24 named checks on the C++-server side; 4 explicit checks on the C++-host side; 4 GEM-300 raw-frame checks. Implicit HSMS state-machine and wire-level framing validation everywhere.

Running

# Start C++ passive server, then drive it with secsgem-py host:
docker compose up -d server
docker compose run --rm interop python3 /app/interop/host_vs_cpp_server.py \
    --host server --port 5000 --session-id 0

# Start Python passive equipment, then probe it with the C++ host:
docker compose up -d equipment_py
docker compose run --rm builder /app/build/secs_interop_probe \
    --host equipment_py --port 5000 --device 0

Both exit 0 on success.

What this caught

Real bugs surfaced by interop (now fixed):

  1. Strict U4 parsing rejected U1-encoded identifiers. SEMI E5 declares DATAID, RPTID, VID, CEID, ALID, EXID, etc. as U1 | U2 | U4 | U8; secsgem-py picks the smallest width that fits. Our as_u4_scalar, as_u2_scalar, etc. were strict. Now lenient with range-checked downcasts (messages_helpers.hpp::any_unsigned_first).
  2. PPBODY rejected when sent as ASCII. SEMI lets PPBODY be ASCII | Binary | List; secsgem-py defaults to ASCII. Added the BINARY_OR_ASCII codegen item type plus a permissive as_text_or_binary accessor, used for S7F3/F6.
  3. Missing S1F23 / S1F24 (Collection Event Namelist). Added the wire schema in data/messages.yaml, a vids_for(ceid) accessor on the event-report store, and the dispatch handler in secs_server.cpp.
  4. Missing S10F3 handler (Terminal Display Single, host→equipment). Our server only registered S10F1; per SEMI E5, S10F1 is equipment→host and S10F3 is the host→equipment counterpart. Added the missing dispatch.

The C++ test suite still passes (278 cases / 1436 assertions) after each of these changes — the fixes are purely permissive widenings, no existing behaviour was broken.