fupsrl

08 — Deployment, Runtime Operation, and Performance Tuning

2 min read Updated 15 July 2026

Deployment is optional and deliberately separated from generation. Use the offline build to produce artefacts first; then deploy only when the target is available and the matching build is ready for runtime validation.

Deployment workflow

  1. Build locally with the desired target profile.
  2. Set Offline=false and Deploy=true.
  3. Pass the target SSH host, user, password, optional pinned host key, and application directory directly to xcpWorkflow.
  4. The workflow creates the application directory, transfers the runtime and service configuration, starts/restarts the service, and verifies the selected target.

Connection settings are runtime inputs, not project files. The historical PiHost/PiUser naming is compatible with any supported Linux SBC.

Target scheduling model

The target runtime separates model work from XCPlite traffic. Pin ModelCores and XcpCores to disjoint CPU sets. The XCP server threads inherit the XCP affinity, while the model task uses its own affinity and configured SCHED_FIFO priority.

  • Use cores that exist on the selected board.
  • Start with the default separation only on boards with at least four usable cores.
  • On a smaller SBC, choose a disjoint configuration suitable for the available cores; do not overlap them.
  • Grant the target service permission for real-time scheduling and CPU affinity as required by the Linux distribution.

DAQ performance tuning

DAQ traffic consumes CPU, queue memory, and Ethernet bandwidth independently from the model algorithm. Add measurements gradually, choose the correct raster, and monitor the exported execution/overrun counters. When packets burst or a calibration tool requests many signals, increase capacity deliberately rather than blindly.

Parameter When to review it
DaqMemSize Adding many ODT entries or measurement signals.
QueueSize TCP bursts, slow tool consumption, or packet queue pressure.
MtuSize Balancing batching efficiency against network/device limits.
EventCount Models with more generated tasks/rasters than the default limit.
CalMemSize / CalSegCount Large tunable parameter structures or calibration pages.

System-level practices

  • Use wired Ethernet and verify switch/cable link speed.
  • Avoid sharing model cores with heavy logging, browser, desktop, or unrelated service workloads.
  • Use a sysroot/ABI baseline appropriate to the target distribution.
  • Record test conditions: target image, kernel, compiler/sysroot, core allocation, model rates, and DAQ signal count.
  • Use the runtime diagnostic measurements to make decisions from data rather than from a subjective UI refresh rate.

Board validation checklist

  1. Start the service and connect an XCP tool.
  2. Confirm base-rate and slower-raster timestamps.
  3. Observe overrun_count during expected DAQ load.
  4. Run a calibration-page read/write/checksum smoke test.
  5. Flash a known matched HEX and confirm restart/version/EPK.
  6. Repeat after a power cycle if persistence is required.