BACnet MSTP Passive Slave Node Description

The BACnet Master Slave Token Passing (MSTP) LAN works on a token passing principle. A master node has to gain access to a token to be able to use the transport medium. Only master nodes are allowed to send and receive tokens on the MSTP network. Passive slave nodes on the other hand may only transmit a data frames on the network in response to a request from a master nodes. Passing the token represents overhead in the sense that the messages used for managing the token do not carry data that is useful to automation or monitoring.

On the BACnet MSTP network frame types are used as a mechanism to allow passive slaves node's, that never holds the token, a means to return replies.

A valid MAC address for a passive slave node on the BACnet MSTP network may range between MAC addresses 0 to 254. The MAC addresses range 0 to 127 is a shared address range between both master and passive slave nodes.

Practical Implications of the differences between using Masters and Passive Slaves.

Many vendors do not provide a choice between Master and Slave configuration of their field devices. They are masters and there is nothing you can do about it.

Slaves cannot be discovered

Because slave's can't reply to the who-is message they cannot be discovered. A consequence of this is that you have to know their Mac address in advance and you have to configure your client to poll that specific address.

Practically speaking this is less of a problem than you would think. Some client software suites allow you to discover devices objects and properties and then drag and drop these onto animation objects on the Scada/HMIS screens. A few of these are intelligent enough to discover objects and properties of a passive slave provided you provide the Mac Address. Some Scada/HMI applications require you to type in the object and property manually so there is no disadvantage to use passive slave nodes.

Masters burn bandwidth

So you must weigh this small one time engineering cost against the huge bandwidth burden using many masters on a network imposes. The charts below give you an idea of how big the burden is.

Based on traffic on a simple network with a single master and a single field device. In test 1 we configured the field device as a Master. In test 2 we configured the field device as a slave.

Chart 1 : Typical ratio of payload (APDU) to overhead (Token) when using Masters.

APDU = 5% (Useful)

Token = 95% (Overhead)

Chart 2 : Typical ratio of payload (APDU) to overhead (Token) when using a Slave device.

APDU = 31% (Useful)

Token = 69% (Overhead)

Additional Information

The frames and frame types that will be ignored by a passive slave node are as follows:

• Frames with a destination address not equal to this station address (TS)
• Frame with destination address equal to 255 (broadcast address) and frame type equal to BACnet_Data_Expecting_Reply, Test_Request or a proprietary type known to the node that expects a reply. (such frames may not be broadcasted)
• Frame types Token, Poll_For_Master, Reply_To_Poll_For_Master, Reply_Postponed or a standard or proprietary frame type not known to this station.

The frames and frame types excepted by a passive slave node are as follows:

• Frames with destination address equal to this station address (TS) and with frame type Receive_data_no_reply, Test_Response or proprietary type known to the node that does not expect a reply.
• Frames with destination address equal to this station address (TS) and with frame type Receive_Data_Expecting_Reply, Test_Request or proprietary type known to this station that expects a reply.

The passive slave node needs to respond, to a frame expecting a reply, within a specified time frame (Not exceed Treply_delay) from when receiving the last octet of the requesting frame. If this time period has expired the slave will not respond to the frame and will return to its Idle mode.