Disclaimer
This documentation reflects the M-Bus specification from the late 1990s. It is for information only and should not be used for product design or any other application or engineering.
Publication of the current M-Bus specificationThe network layer takes care of choosing the best transmission route between the communication parties in a network. We define that the network layer in the M-Bus protocol “connects” a slave with a certain secondary address to the bus and and associates it with the primary address of 253 ($FD). So the number of 250 addresses (primary) is extended by the network layer associating a selected slave to this address 253. The network layer is only enabled by a SND_UD with CI_Field $52 / $56 to address 253.
7.1 Selection and Secondary Addressing
When addressing in the data link layer with the help of the A-Field, the problem of the address allocation arises. The addresses are normally set to a value of 0 by the manufacturer of the meters, in order to designate them as unconfigured slaves. A very laborious method of address allocation consists of setting the addresses when installing the slaves, for example with DIP switches. A further method of address allocation is to determine the bus addresses when connecting the equipments to the bus with the master software. This sends a command for address allocation (see 6.4.2) to the address 0. In this case the slaves must however all be successively connected to the bus, which very much gets in the way of a simple installation procedure.
When however addressing in the network layer these disadvantages are avoided and the address region is essentially extended beyond the number of 250 with primary addressing (A-Field). The addressing of the slaves takes place with secondary addressing with the help of the following so-called selection:
68h | 0Bh | 0Bh | 68h | 53h | FDh | 52h | ID1-4 | Man 1-2 | Gen | Med | CS | 16h |
Fig. 29 Structure of a telegram for selecting a slave (mode 1)
The master sends a SND_UD with the control information 52h (Mode 1) or 56h (Mode 2 ) to the address 253 (FDh) and fills the specific meter secondary address (identification number, manufacturer, version and medium) with the values of the slave which is to be addressed. The address FDh and the control information 52h / 56h are the indication for the slaves to compare the following secondary addresses with their own, and to change into the selected state should they agree. In this case the slave must answer the selection with an acknowledgement (E5h), otherwise the slave doesn’t send an answer. “Selected state” means that this slave will be addressed at the following commands (e.g. REQ_UD) with the bus address FDh and in this example will reply with RSP_UD. In other words the network layer has associated this slave with the address FDh.
During selection individual positions of the secondary addresses can be occupied with wildcards (Fh). Such a Wildcard means that this position will not be taken account of during selection, and that the selection will be limited to specific positions, in order to address complete groups of slaves (Multicasting). In the identification number each individual digit can be wildcarded by a wildcard nibble Fh while the fields for manufacturer, version and medium can be wildcarded by a wildcard byte FFh.
The state of the selection remains unchanged until the slave is deselected with a selection command (as described above) with non-matching secondary addresses, or a SND_NKE to address 253. The slave, which uses mode 1 for multibyte records, will be selected by a telegram with the CI-Field 52h and the right secondary address, but it will be deselected by a telegram with the CI-Field 56h and any secondary address.
A Slave with implemented primary and secondary addressing should also answer telegrams to his primary address. A Slave with only secondary addressing should occupy the address field in the RSP_UD telegram with $FD to signal that it will not participate in primary addressing.
7.2 FCB-Bit and Selection
(§ chapter 7.2 reworked)
FCB-Implementation slave
A slave with implemented secondary addressing and with implemented FCB-administration must have an additional set of 0, 1 or 2 separate “Last Received FCB”-memery Bit(s) for all communication via the pseudo primary address 253 ($FD). If it can communicate also alternatively over some other primary address (exept the special addresses 254 and 255) an additional set of 0, 1 or 2 “Last received FCB”-memry bit(s) for each of these primary addresses is required. A valid selection telegram will not only set the internal selection bit but will also clear all 0, 1 or 2 internal “Last received FCB”-memory bit(s) associated with secondary addressing via the pseudo primary address 253 ($FD). The master will start the communication (REQ_UD2 or SND_UD) after any selection telegram (CI=$52 or $56) with the FCV-Bit set and the FCB-Bit set. If a slave has more than one alternative secondary identification, only a single set of 0, 1 or 2 “Last received FCB”-memory bit(s) for all secondary addresses is required.
FCB-Implementation master
The master must implement a separate pair of “Next FCB image”-Bits for pseudo primary address 253 ($FD) as for each other primary address. Although these “Next FCB image”-bits might be used for many slaves, no confusion exists, since for accessing another slave a selection telegram is required which will define the future FCB sequence both for slave and master.
7.3 Searching for Installed Slaves
Primary Addresses
To read out all installed slaves the master software must know all the slaves, which are connected to the bus. Therefore the software searches for slaves with primary adressing by sending a REQ_UD2 to all allowed adresses (1..250) with all available baudrates. The master notes used primary addresses with the respective baudrates.
Secondary Addresses
The secondary addressing described in the preceding section draws attention to the problem of determining the secondary addresses of slaves connected to the bus. The master can after this read out the slaves making use of secondary addresses with previous selection. Testing all possible identification numbers with the master software would take years, since the identification number offers millions of combinations. For this reason, a procedure was developed for the rapid and automatic determination of already installed slaves:
Wildcard searching procedure
The following wildcard searching procedure uses the occupation of individual parts of the secondary address with wildcards (Fh) for selection:
In this case with the identification number (BCD) each individual position, and by manufacturer, version and medium (binary coding), only one complete byte, can be occupied with wildcards. The master begins the selection using a SND_UD with the control information 52h (Mode 1), and occupies all positions in the identification number, except the top one, with wildcards. The top position is run through in ten selections from 0 to 9 (0FFFFFFF to 9FFFFFFF).
If after such a selection the master receives no acknowledgement, it then goes to the next selection. If the master receives an E5h, it then sends a REQ_UD2 and learns the secondary address of the slaves from the reply telegram, as long as no collision occurs. If there is a collision after the selection or the REQ_UD2, the master varies the next positions and holds the existing one. If there is a collision, for example at 5FFFFFFF, the selection is run through from 50FFFFFF to 59FFFFFF. If in this case collisions again occur, then a change is made to a variation of the next position. After running through a complete position, the next higher position is processed up to 9.
With this Wildcard searching procedure, it will be seen that at least the top position must be run through in order to reach all slaves. Running through further positions may be necessary, depending on the number of the slaves and the distribution of the identification numbers. This procedure allows a statement of the maximum number of selections in relation to the number of slaves, but as disadvantage frequent collisions, which occur, should be mentioned. The wildcard searching procedure must be performed for all used baudrates and both byte sequences (mode 1 and 2).
The search procedure can be extended with searching for manufacturer, generation and finally media to find slaves, which have the same identification number. It is also possible to search for all slaves of a certain manufacturer or all slaves of a certain media by setting the corresponding value.
The company Aquametro AG has simulated such a search to find the minimum, the average and the maximum number of selections as a function of the number of slaves. For the minimum number of attempts the optimum distribution of the identification numbers was chosen, for the maximum number the most unfavourable, and for the average number of attempts a random distribution. The following diagram shows the result of these calculations:
Fig. 30 Number of Selections with Wildcard Searching Procedure
Instructions for implementation of Wildcard Search
The following program flow diagram shows the realization of the Wildcard searching procedure, whereby the search is made only with the identification number. The codes for manufacturer, version and medium are in general specified with wildcards, but can be changed by the user in order (for example) to locate all meters from a particular manufacturer. In order to avoid the categorisation by a factor of eight of the “For-To” loops for the eight positions, the array “Value” is defined with 8 byte numbers, which are intended to define the contents of the positions. The digit number of the identification number which is presently running is noted in the variable “Pos” of type byte.
Fig. 31 Flow Diagram for Slave Search with Wildcards
The routine begins at the first position, and implements the following actions for the value of this position from 0 to 9:
- Selection with the ID-Nr. Pos 1, Pos 2, …….., Pos 8
- if no reply, Value [Pos] is raised by 1
- if there is a reply, a REQ_UD2 is sent to address 253, and if the telegram is correctly received the secondary address is learnt and the Value [Pos] raised by 1
- if there is a collision a jump is made to the next position (Pos increased by 1), as long as the last position has not yet been reached
- after going through a complete position from 0 to 9 the subroutine proceeds to the next lower position, or ends the search if the position Nr. 1 has already been processed
Example
The next figure shows an example for secondary addresses in order from top to bottom, as they will be found by the master software:
No. | Identification-Nr. | Manufacturer. (hex.) | Version (hex.) | Media (hex.) |
1 | 14491001 | 1057 | 01 | 06 |
2 | 14491008 | 4567 | 01 | 06 |
3 | 32104833 | 2010 | 01 | 02 |
4 | 76543210 | 2010 | 01 | 03 |
Fig. 32 Secondary Addresses found with a Wildcard Search of Four Slaves
Search Process:
1. Start with ID = 0FFFFFFF : no reply
2. ID = 1FFFFFFF : collision between Nr.1 and Nr.2
3. ID = 10FFFFFF, 11FFFFFF, 12FFFFFF, 13FFFFFF : no reply
4. ID = 14FFFFFF : collision between Nr.1 and Nr.2
5. Repeated steps 3 to 4 up to the ID = 1449100F
6. Learn ID = 14491001 and 14491008
7. Go backwards to 19999999
8. ID = 2FFFFFFF : no reply
9. ID = 3FFFFFFF : learn ID = 32104833
10. ID = 4FFFFFFF, 5FFFFFFF, 6FFFFFFF : no reply
11. ID = 7FFFFFFF : learn ID = 76543210
12. ID = 8FFFFFFF, 9FFFFFFF : no reply
13. End of the Search
7.4 Generalized Selection Procedure
For including new or restructed identification parameters into a selection procedure an enhanced definition of the selection telegram (CI=$52/$56) is suggested:
After the 8 byte of the fixed selection header may also follow standard records with data. In this case only those meters will be selected, where in addition to the fixed header all record data agree. In most but not all cases this means that the DIF and parts of the VIF (not exponent) must match. Again wildcard rules apply to the record data (digit wildcard for BCD-coded data and byte wildcard for binary or string data).
With some new defined VIF-codes (extension) and this generalized selection it will be possible to select slaves using e.g. longer identification numbers, customer, customer location and more information. See chapter 8.4.4 for this new VIF-Codes. Two useful examples from the primary table for VIF are the “Fabrication No.” and “Bus Address”.
Enhanced selection with fabrication number §
The identification number is a customer number and can be changed by the master. Therefore it can be possible that two slaves have the same secondary adress. For this reason the selection telegram can be extended by a fabrication number to devide such slaves. This number is a serial number allocated during manufacture, coded with 8 BCD packed digits (4 Byte) like the identification number, and thus runs from 00000000 to 99999999.
The following figure shows the structure of an enhanced selection telegram released by the master.
68h | 11h | 11h | 68h | 53h | FDh | 52h | ID1-4 | Man1-2 | Gen | Med | 0Ch | 78h | Fab1-4 | CS | 16h |
Fig. 33 Structure of a telegram for enhanced selection (mode 1)
After the field medium the new data is given in form of a structured datarecord with DIF=0Ch and VIF=78h. Parts of the fabrication number (Fab1..Fab4) can be occupied with wildcards (Fh).
If a fabrication number exists the slave should add this data to the variable data blocks in every RSP-UD telegram. If the fabrication number and enhanced selection is not implemented in a slave this device will not confirm the enhanced selection telegram and will be deselected.
Enhanced selection should be used only if the normal kind of selection is not successful.