RWTS™ and AREMA Part 24.2.1: How They Align

What Part 24.2.1 Covers

AREMA Communications & Signals Manual Part 24.2.1, Data Acquisition for Asset Health Sensing and Condition Monitoring (approved 2022, published in the 2024 Manual), is the industry's recommended practice for what a wayside data-acquisition system should look like. It describes three functions, data acquisition, edge processing, and back office, and the two links between them, Data Acquisition Unit → Edge and Edge → Back Office. For each it lists the data-transfer standards to support, and it sets expectations for the message body format, local storage, time synchronization, and security.

What it does not do is define the messages themselves. Two vendors can each meet Part 24.2.1 and still speak different languages. RWTS™ is the application-layer contract that closes that gap, and it was written to sit on top of Part 24.2.1 rather than beside it.

This page is EPU Engineering's own assessment of RWTS v1.0.0 against the published text of Part 24.2.1. Last checked against the specification September 2026.

Requirement by Requirement

Part 24.2.1 calls for	What RWTS™ defines
Support for at least one listed data-transfer standard on each link, MQTT and SNMP among them	Messages ride over MQTT, SNMPv3, or both at once for redundancy. RWTS defines the application layer only, so the railroad chooses the transport its network already runs, and the message semantics stay identical.
A standard, defined message body format that can be read without restricted-rights software	One message format for every device: CBOR (RFC 8949) on the wire by default, with JSON available for debugging. The specification is openly licensed (CC BY 3.0), so anyone can implement an encoder or decoder from the document alone.
Time synchronization to a railroad time standard, with synchronization actions logged and free-running clock drift bounded	Every message carries a UTC timestamp and a sequence number. Each heartbeat flags the device's NTP status, and the `ntp_sync_state` system metric records it. A device that loses sync keeps operating with a widened timestamp tolerance, logs the loss, raises an alarm, and keeps trying to resynchronize rather than silently dropping data. The synchronization log itself, with the time differential the Part asks for, is kept by the edge platform; the standard carries the state, not the log.
Encryption in transit	TLS 1.2 or later is mandatory on MQTT, with server-certificate validation; SNMPv3 runs in `authPriv` mode, which authenticates and encrypts every PDU.
Authentication of content	A defined HMAC-SHA256 message signature, for devices that advertise it, lets a server verify that a message came from the registered device and was not altered in transit.
Least-privilege access to data, configuration, and devices	Devices register with per-device credentials, and authorization is enforced at the broker or SNMP agent. Server-to-device commands are limited to housekeeping: firmware updates, maintenance windows, sleep, commissioning, and registration revocation.

Encryption of data at rest on the edge device is outside the standard's scope and is an implementation matter for the platform that runs it.

Where RWTS™ Goes Further

Part 24.2.1 is silent on what the data means. RWTS fills that in, so that meeting the Part and achieving interoperability become the same job:

800+ standard alarm codes across 100+ equipment families, with the same meaning from every vendor
Defined device behavior: registration, heartbeat, alarm lifecycle (raise, clear, acknowledge), and configuration
Four conformance profiles, so a device states exactly what it implements and mixed fleets interoperate without special cases
RWTS Expanded, a lossless human-readable form of every message, so SCADA systems, historians, and dashboards that do not implement the protocol still receive the data

Read the RWTS™ overview

Scope and Limits

Part 24.2.1 treats data acquisition, asset health sensing, and condition monitoring as an overlay on the signal system: sensors and acquisition devices shall not adversely affect its safety, should be easy to remove and disable for troubleshooting, and exist for the sole purpose of capturing health and performance data. RWTS is a monitoring standard in exactly that sense: it informs maintenance and diagnostics, and it does not command train movements or control safety-critical signal logic. It defines no vital device-actuation commands, and EPU Engineering's Wayside Maintenance Monitoring System is likewise non-vital: it observes and reports, it never commands. RWTS is not a substitute for vital signaling systems or their certifications.

On the word "compliance." AREMA does not operate a conformance certification program for this Part, so no vendor, including EPU, holds third-party certification to it. Treat any such claim, ours included, as a self-assessment and ask to see the analysis behind it. Nothing on this page is engineering advice for a specific installation.

Need the Comparison for a Specific Solicitation?

We'll produce one against your system or specification. If you want the specification and reference library when they release, join the waitlist.

Join the RWTS waitlist Discuss signal engineering work