RWTS™ and AREMA C&S Manual Part 24.2.1: Alignment at a Glance

A plain-English walkthrough of how the open standard satisfies every requirement in Part 24.2.1 — written by the authors of both the spec and the reference implementation.

Published 2026 · By EPU Engineering · 8 min read

Why Part 24.2.1 Matters

AREMA's Communications & Signals Manual Part 24.2.1 — Data Acquisition for Asset Health Sensing and Condition Monitoring, approved 2022 and published in the 2024 Manual — is the first place most North American railroads look when they're specifying a wayside monitoring system. It sets expectations for three functional layers (data acquisition, edge processing, back office) and names the protocols, message formats, time-sync mechanisms, and security controls each layer must support.

Part 24.2.1 is intentionally protocol-inclusive: it doesn't mandate a single wire format. Instead it requires each interface to support at least one protocol drawn from a curated list, and to use standard message bodies (XML or JSON) so data is extractable without proprietary decoders.

That leaves room for vendor lock-in at every seam. Each manufacturer can satisfy Part 24.2.1 while still shipping equipment that only talks to its own back office. RWTS exists to close that gap — a common application-layer contract that every device, every edge node, and every back-office system can meet, so a railroad can mix vendors without writing translation code.

Requirement-by-Requirement Alignment

Part 24.2.1 imposes requirements on three interfaces: Data Acquisition Unit → Edge, Edge → Data Acquisition, and Edge → Back Office. Here's how RWTS aligns at each.

Physical Interfaces

AREMA 24.2.1 requirement RWTS alignment
Device → Edge: IP or asynchronous serial RWTS is transport-agnostic at the application layer; runs natively over IP (MQTT/SNMPv3) and over serial via standard bridges
Edge → Back Office: IP (wired or wireless) RWTS over MQTT (QoS 1/2) on TCP/TLS — the canonical deployment model

Data Transfer Protocols

Part 24.2.1 lists acceptable protocols at each interface. RWTS is designed to coexist with them rather than replace them — RWTS defines the message format and semantics that ride on top.

Interface AREMA-approved protocols RWTS transports
Device → Edge MQTT, SNMP, OPC UA, ITCM, ITCSM, ATCS, Genisys, Modbus (slave) MQTT or SNMPv3 (primary); Modbus and serial supported via edge adapters
Edge → Back Office MQTT, SNMP, secure web services, ITCM MQTT (QoS 1/2) with TLS 1.2+; SNMPv3 authPriv for legacy paths

Because RWTS operates above the transport, the same RWTS message can be delivered over any AREMA-approved protocol on the interface — railroads choose the transport that fits their network, and application semantics stay identical.

Message Body Format

Part 24.2.1 requires "standard defined message body format (e.g., XML, JSON)" and data that is extractable without restricted-rights software.

  • RWTS: JSON (human-readable) and CBOR (compact binary, approximately 50% bandwidth vs. JSON) — both open, both documented in the specification, both decoder-available under Apache 2.0.
  • Zero restricted-rights software anywhere in the stack. Any organization can implement a conformant RWTS encoder or decoder using only published tools.

Time Synchronization

Part 24.2.1 requires network time synchronization (e.g., NTP) with alternative methods (peer protocol, code-line, GPS, railroad-approved methods) permitted where NTP isn't available. Free-running clocks must stay within ±4 minutes per 30 days; automatic re-sync at least every 30 days where a railroad time source is reachable; and synchronization events must be logged with the observed time differential.

  • RWTS: every message carries a UTC timestamp and a monotonic sequence number, enabling drift detection and replay protection.
  • Device registration advertises the device's time source (NTP, GPS, peer, code-line) so the edge and back office can flag devices that fall out of sync.
  • Sync events are emitted as STATUS messages with the previous-versus-current offset — satisfying the logging requirement by construction.

Security

Part 24.2.1 requires encryption in transit (edge → back office), encryption at rest (edge storage), authentication of content via checksum or hash, and principle-of-least-privilege access controls for data, configuration, and device access.

  • In transit: TLS 1.2+ required on MQTT; authPriv mode required on SNMPv3 (authentication + encryption).
  • At rest: reference implementation encrypts the local message buffer on edge devices using standard OS-level primitives.
  • Authentication of content: every RWTS message includes a cryptographic message integrity code; back-office systems reject unsigned or tampered messages.
  • Access control: RWTS separates read, write, and admin surfaces into distinct MQTT topics / SNMP OIDs so least-privilege roles can be enforced at the broker or agent without custom application logic.

Vital vs. Non-Vital Applications

Part 24.2.1 is explicit that data acquisition, asset health sensing, and condition monitoring are non-vital — they inform maintenance and diagnostics, they do not command train movements or control safety-critical signal logic.

RWTS is application-agnostic at the protocol level — its message format and security controls can theoretically support vital applications if implemented with the additional certifications and safety measures vital signal systems require. EPU Engineering's Wayside Maintenance Monitoring System (Wayside Sentinel, Wayside Overwatch, Wayside Nexus) is intentionally non-vital: it observes and reports, it doesn't command.

Any railroad considering RWTS for vital applications should engage qualified signal engineers and regulatory authorities. The data protocol itself does not replace safety certifications.

The Short Version

RWTS was built from the ground up to satisfy AREMA Part 24.2.1 — and to go further, by solving the interoperability problem Part 24.2.1 doesn't mandate a solution for. If your railroad is specifying a wayside monitoring system against Part 24.2.1 today, RWTS is a drop-in application-layer contract that keeps every vendor on the same page.

If you want a direct comparison for a specific solicitation or system, we'll produce one. If you want the spec and reference library when they release, join the waitlist.

Take the Next Step

Join the RWTS Waitlist Request a Capability Statement

Prefer a conversation? Start with a consulting inquiry →