Using dynamic ID's

In distributed network systems it may happen that ID's have to be assigned
dynamically. Eg

the adress space is too big to poll

there are more possibly connected devices than the address space of the
network

devices may be moved from network to network and cannot have a unique ID.

As usual, a device may only send a packet when a master requests it to do so.
This means a device cannot broadcast a message such as 'hello, I'm here ! ID#A2W4567VZ'.
The network has to provide broadcasts though. The broadcast is used exclusively
by the master. It is obvious that only one device can answer at a time, otherwise
the reply becomes corrupted. Assigning a dynamic ID requires a series of steps
and a few commands. Both, the master and the slave device act as state machines.
The master has to be able to detect the sending of a corruped reply.

The command, here simply named AssignID is set up similar to :

field

value

meaning

STX

header

Length

length of packet

SRC

ID of the master

DST

Broadcast address

Msg

AssignID

data[1]

new ID

data[2]

probability

data[3]

assign unknown / assign all

CRC

checksum to detect valid packet

The device state machine :

state

event

action

next state

unassigned

receive AssignID and probability evaluates to 1

none

possibly assigned

possibly assigned

receive any command to this ID

reply to this command

probably assigned

possibly assigned

timeout

none

unassigned

probably assigned

receive any command to this ID

reply to this command

assigned

probably assigned

timeout

none

unassigned

assigned

The master state machine, concerning this try :

state

event

action

next state

idle

timer

make new ID and send AssignID

1

1

timer

send any command to new ID

2

2

receive valid reply

send any command to new ID

3

2

receive invalid reply

cache ID for non use while timeout of the device

1

2

timeout

discard ID

1

3

receive valid reply

add new device to list of devices

1

3

receive invalid reply

retry

3

3

timeout

retry

3

3

retries expired

mark device

The state machines require some finish, that they are water tight.This depends
on the actual implementation.

The probability mechanism

As there may be more than one device in the unassigned state, not all of them
should reply to an AssignID request. This can be achieved with a random number
generator. The device calculates a random number each time an AssignID request
is received. The probability is a mask, ANDed with the random number gives zero
or not. A zero means reply to the request. Note that the random number must
not be just an incrementing counter as at powerup, all devices would have the
same value and it would repeatedly be so. Use a random number XOR the serial
number or such a thing.

The outer loop of the master

The master does the AssignID from time to time. A bit more often when more
that average invalid replies are encountered during AssignID. In a loop the
probability is increased, when no reply comes forth, and lowered when the number
of invalid replies rise.

The AssignID is best run in an own thread (task). It should run exclusively,
meaning no other commands may interfere.