Defensive labs About 1 min read

Modbus and BACnet interpretation

Interpret synthetic Modbus values and BACnet objects using the supplied definitions. Record uncertain mappings and keep the exercise separate from building equipment.

Sources and scopeSource record 25 August 2026

Technical source record: 25 August 2026. Check the linked documentation for current product requirements.

Offline research and planning only; product or deployment acceptance belongs to separately governed environment validation.

Verification and testing

Overview#

Lab class: Offline synthetic frame and object listing fixtures

Modbus exercise#

Use the synthetic read response to identify MBAP fields, unit/function, byte count and registers. Then apply a synthetic vendor register map to discuss signedness, scaling, word order, freshness and limits. Don't send reads or writes to a PLC, gate, barrier, power system or controller.

BACnet exercise#

Use a synthetic object inventory to map device/object identifiers, object types, properties, services and represented network path. Separate BACnet/IP, MS/TP and BACnet/SC transports, and identify BBMD/foreign device or hub/connector trust boundaries where applicable. Represent discovery and property write behaviour conceptually; the fixture contains object metadata only.

Security comparison#

  • Classic Modbus/TCP and BACnet/IP don't inherently provide the endpoint identity and protected transport expected from modern secure variants.
  • Modbus Security uses TLS and X.509 on assigned port 802 according to Modbus Organization materials.
  • BACnet/SC uses TLS secured WebSockets and certificates; certificate/hub operation remains a deployment responsibility.
  • Secure transport doesn't authorise a physical write or establish safe register/object semantics.

Evidence checklist#

  • Fixture provenance, digest, protocol/version, and synthetic topology recorded
  • Modbus MBAP, unit, function, byte count, register, signedness, scaling, and word order interpretation documented
  • BACnet device/object identifiers, properties, services, and transport family mapped
  • Unknown register/object semantics and vendor map dependencies identified rather than guessed
  • Classic and secure transport identity, confidentiality, integrity, and certificate boundaries compared
  • Read, write, acknowledgement, and physical outcome semantics kept distinct
  • Network discovery, field bus access, devices, controllers, and physical writes excluded

Sources#