Bhairava Sense: how protocols are identified
How Sense recognises what it hears, what every message becomes, and which kinds of equipment it covers.
Where things stand. Only BACnet/IP is supported in Bhairava Sense today. The other protocols on this page are coming soon.
How identification works
1. CaptureSense takes in what the equipment sends, whatever the link: network, serial line, CAN bus or Bluetooth LE.
2. IdentifyEvery known protocol tests the bytes against its own structure. The most certain match wins. Port numbers are never looked at.
3. ReadThe matching protocol reads the message into the common form, so everything after this step is the same for every protocol.
- Each protocol is recognised from its structure only: marker bytes, length fields that must add up exactly, checksums, version fields and known message types. Every test gives a confidence and a reason in words.
- A match is accepted only when it is certain enough. If two different protocols are equally likely, the traffic is left as unknown instead of guessing.
- Once a conversation has been identified, the pieces that follow it stay with the same protocol, even when a single piece would not be recognisable on its own.
- Traffic that cannot be identified is counted and a sample is kept, so nothing is dropped silently.
- Because ports are never used, BACnet is recognised on any port, and traffic that merely arrives on a BACnet port is not mistaken for BACnet.
What every message becomes
| Item | Meaning |
|---|---|
| Kind | Reading, event, presence, request, or other. Traffic that was recognised but not read, could not be read, or is unknown is kept as such. |
| Protocol | Which protocol it was, and the reason it was identified in words. |
| Device | A stable, readable name for the device that sent it, what the device says about itself, and where it was heard. |
| Point | A stable, readable name for the point on that device, such as a register, an input or a group address. |
| Value | The value with its unit or state word, and the previous value of the same point. |
| State | Normal, in alarm, fault, and so on, with quality flags as words. Only events that need attention at once are marked severe. |
| Message and time | A readable message, the time the device gave, and the time Sense heard it. |
| Details | Protocol details as readable text, and the original bytes. |
Encrypted traffic
Whether a protocol is encrypted on a site is declared by the site's owner. Sense does not guess it from the traffic. When a protocol is declared as encrypted, Sense reads it using the access details the owner provides. If those details are not accepted, Sense raises one severe notice for the tenant so the owner can correct them, and readings resume once they are corrected.
Supported and coming soon
27 protocols are listed. Supported means Bhairava Sense reads it today. Coming soon means it is planned and, where its structure allows, can already be recognised. Defence and nuclear protocols are left out. Project Haystack and Brick are data models, not wire protocols, and are not listed.
| Name | Category | Status | Link | How it is recognised |
|---|---|---|---|---|
| BACnet/IP | Building automation | Supported | udp | BVLC type 0x81 (0x82 for IPv6), a known BVLC function, BVLC length equal to the datagram, NPDU version 1 with reserved control bits zero, and the APDU decodes to the end |
| BACnet MS/TP | Building automation | Coming soon | serial | Preamble 0x55 0xFF, frame type 0-7, valid header CRC-8 (ASHRAE 135 Annex G) and, when data follows, a valid data CRC-16 |
| BACnet/SC | Building automation | Coming soon | tcp | Secure WebSocket over TLS: recognised as TLS, contents are encrypted Encrypted by design. |
| Modbus TCP | Industrial | Coming soon | tcp | MBAP headers with protocol id 0 and length fields that tile the data exactly, known function codes, and request/response shapes that agree with the function (byte count, quantity, exception code) |
| Modbus RTU | Industrial | Coming soon | serial | Slave address 0-247, a known function code, a frame shape that agrees with the function and a valid CRC-16/MODBUS over the frame |
| KNX (KNXnet/IP) | Building automation | Coming soon | udp / tcp | Header length 0x06, protocol version 0x10, a known KNXnet/IP service type and total length equal to the data |
| LonWorks / LON/IP | Building automation | Coming soon | udp / serial | No structural test confirmed yet: needs a LonWorks interface or IP-852 channel |
| DALI / DALI-2 | Building automation | Coming soon | serial | Only through a DALI interface; 16/24-bit forward frames have no checksum to test |
| EnOcean (ESP3) | Building automation | Coming soon | serial | Sync 0x55, valid CRC-8 over the 4 header bytes, packet length that fits and a valid data CRC-8 |
| OPC UA | Industrial | Coming soon | tcp | Chunks starting HEL/ACK/ERR/RHE/OPN/MSG/CLO, chunk type F/C/A and little-endian sizes that tile the data; HEL carries an opc.tcp:// endpoint |
| MTConnect | Industrial | Coming soon | tcp | XML with an MTConnectStreams/MTConnectDevices root in the urn:mtconnect.org namespace, or SHDR lines "timestamp|item|value" |
| MQTT | IoT | Coming soon | tcp | CONNECT with protocol name MQTT (level 4 or 5) or MQIsdp (level 3); otherwise packets whose fixed headers, flags and remaining lengths tile the data exactly |
| Sparkplug B | IoT | Coming soon | tcp | MQTT PUBLISH packets on topics starting spBv1.0/ |
| Thread / Matter | IoT | Coming soon | udp | Messages are encrypted per session; nodes are visible only through mDNS _matter._tcp Encrypted by design. |
| Zigbee | IoT | Coming soon | tcp | Radio is encrypted; read through the site hub (usually MQTT) Encrypted by design. |
| Z-Wave | IoT | Coming soon | tcp | Radio is encrypted (S2); read through the site controller Encrypted by design. |
| BTHome (Bluetooth LE sensors) | Wireless sensors | Coming soon | ble | Advertisement AD structures that tile exactly, with service data for UUID 0xFCD2 |
| Bluetooth LE advertisements (other formats) | Wireless sensors | Coming soon | ble | Advertisement AD structures that tile exactly with known AD types |
| SNMP | IT and power | Coming soon | udp | BER SEQUENCE spanning the whole datagram, version 0, 1 or 3, then a community string and a PDU tag 0xA0-0xA8 (v1/v2c) or the v3 header, with consistent nested lengths |
| M-Bus | Metering | Coming soon | udp / tcp / serial | Long frame 0x68 L L 0x68 ... checksum 0x16 with matching lengths and checksum, or short frame 0x10 C A checksum 0x16 |
| Serial weighing indicators | Industrial | Coming soon | tcp / serial | Text lines "ST|US|OL,GS|NT,weight unit" (A&D-style continuous output); formats of other makers are added per indicator |
| NMEA 0183 / AIS | Marine | Coming soon | udp / tcp / serial | Text lines starting $ or ! with an address field and a valid XOR checksum after * |
| NMEA 2000 | Marine | Coming soon | can | 29-bit CAN identifiers whose PGN is a marine PGN (position, heading, depth, product information...) |
| SAE J1939 | Vehicle | Coming soon | can | 29-bit CAN identifiers of at most 8 data bytes whose PGN is a known J1939 PGN (engine, vehicle, faults) |
| OBD-II | Vehicle | Coming soon | serial / can | 11-bit CAN ids 0x7DF/0x7E0-0x7EF with an ISO-TP single frame and a diagnostic service byte (reply = request + 0x40), or an ELM327 adapter banner / reply lines |
| ADS-B | Aviation | Coming soon | tcp / serial | AVR text lines *<28 hex digits>; with a valid CRC-24 (DF17/18) |
| Vendor cloud / system export APIs | Connected systems | Coming soon | - | Not captured: configured per vendor |
Protocol support per scenario
The protocols each of the demonstration scenarios usually communicate over. Green means supported now, grey means coming soon.
| Scenario | Type | Protocols |
|---|---|---|
| Maritime | Fleet | NMEA 0183 / AIS NMEA 2000 Modbus TCP Modbus RTU SAE J1939 |
| Passenger Bus | Fleet | SAE J1939 OBD-II Vendor cloud / system export APIs |
| Cargo Truck | Fleet | SAE J1939 OBD-II BTHome (Bluetooth LE sensors) Bluetooth LE advertisements (other formats) Vendor cloud / system export APIs |
| Passenger Aircraft | Fleet | ADS-B Modbus TCP Modbus RTU SAE J1939 BACnet/IP Vendor cloud / system export APIs |
| Cruise Ship | Fleet | BACnet/IP Modbus TCP Modbus RTU NMEA 0183 / AIS NMEA 2000 SAE J1939 |
| Defence Tank | Fleet | SAE J1939 |
| Defence Ship | Fleet | NMEA 0183 / AIS |
| HALE UAV | Fleet | Vendor cloud / system export APIs |
| Ambulance | Fleet | OBD-II SAE J1939 BTHome (Bluetooth LE sensors) Bluetooth LE advertisements (other formats) Vendor cloud / system export APIs |
| Cash Transit & Escorting | Fleet | SAE J1939 OBD-II BTHome (Bluetooth LE sensors) Bluetooth LE advertisements (other formats) Vendor cloud / system export APIs |
| Logistics & Delivery | Fleet | BTHome (Bluetooth LE sensors) Bluetooth LE advertisements (other formats) Vendor cloud / system export APIs |
| Home Services | Fleet | BTHome (Bluetooth LE sensors) Bluetooth LE advertisements (other formats) OBD-II |
| Retail | Fixed | Modbus TCP Modbus RTU BACnet/IP SNMP |
| Healthcare | Fixed | BACnet/IP Modbus TCP Modbus RTU SNMP BTHome (Bluetooth LE sensors) Bluetooth LE advertisements (other formats) |
| Hospitality | Fixed | BACnet/IP Modbus TCP Modbus RTU KNX (KNXnet/IP) SNMP |
| Manufacturing | Fixed | OPC UA Modbus TCP Modbus RTU MQTT Sparkplug B BACnet/IP |
| Mining | Fixed | SAE J1939 Modbus TCP Modbus RTU OPC UA Vendor cloud / system export APIs |
| Agriculture | Fixed | MQTT Modbus TCP Modbus RTU SAE J1939 Vendor cloud / system export APIs |
| Infrastructure | Fixed | BACnet/IP BACnet MS/TP Modbus TCP Modbus RTU SNMP Vendor cloud / system export APIs |
| Humanitarian | Fixed | Modbus TCP Modbus RTU BTHome (Bluetooth LE sensors) Bluetooth LE advertisements (other formats) Vendor cloud / system export APIs |
| Heavy Industry | Fixed | OPC UA MQTT |
| Sourcing | Fixed | Modbus TCP Modbus RTU BTHome (Bluetooth LE sensors) Bluetooth LE advertisements (other formats) BACnet/IP |
| Ammunition Depot | Fixed | BACnet/IP Modbus TCP Modbus RTU |
| Real Estate | Fixed | SAE J1939 Modbus TCP Modbus RTU OPC UA Serial weighing indicators Vendor cloud / system export APIs |