Configuration and Management of Networked Embedded Devices - Networked Embedded Systems - page 563

• Baptizing of devices in order to obtain an identifier that allows addressing the newly con-
nected device. his could be done by explicitly assigning an identifier to the device, e.g.,
by setting dip switches or entering a number over a local interface, or implicitly by the
cabling topology, e.g., devices could be daisy chained and obtain their name subsequently
according to the chain.
Alternatively, it is possible to assign unique identifiers to nodes in advance. This approach is taken
for example, with Ethernet devices where the MAC address is a worldwide unique identifier, or in
the TTP/A protocol that also uses unique node IDs. However, such a worldwide unique identifier
willhavemanydigits,sothatitisusuallynotfeasibletohavethenumberprintedsomewhereonthe
device. To overcome this problem, machine-readable identifiers in form of bar codes or RF tags are
used during hardware configuration.
• Simple configuration procedures, which can be carried out and verified by nonexpert
personnel.
22.7.2 Plug and Participate
Since the hardware configuration is intended to be simple, a fieldbus system should behave intelli-
gently in order to release human personnel from error-prone tasks.
In the stage of plug and participate, the fieldbus system runs an integration task that identifies new
nodes, obtains information about these nodes, and changes the network configuration in order to
include the new nodes in the communication.
Identification of new nodes can be supported with manual baptizing as described in Section ...
Alternatively, it is also possible to automatically search for new nodes and identify them as described
in [].
If there can be different classes of nodes, it is necessary to obtain information on the type of the
newly connected nodes. his information will usually be available in form of an electronic datasheet
thatcanbeobtainedfromthenodeorfromanadequaterepository.
The necessary changes of the network configuration for including the new node greatly depend
on the employed communication paradigm. In case of a polling paradigm, only the list of nodes to
be polled has to be extended. In case of a time-triggered paradigm, the schedule has to be changed
and updated in all participating nodes. In case of an event-triggered paradigm, only the new node
has to be authorized to send data; however, it is very difficult to predict how a new sender will affect
the timing behavior of an event-triggered system. In all three cases critical timing might be affected
due to a change of the response time, i.e., when the cycle time has to be changed. Thus, in time-
critical systems, extensibility must be taken into account during system design, e.g., by reserving at
first unused bandwidth or including spare communication slots.
22.7.3 Application Configuration and Upload
Some frequently reoccurring fieldbus applications, like standard feedback control loops, alert mon-
itoring,andsimplecontrolalgorithmscanotenbeputinplacelikebuildingbricks,sincethese
applications are generically available (e.g., PID controller).
For more complex or unorthodox applications, however, it is necessary to implement user-defined
applications. hese cases require that code must be uploaded onto the target devices.
Aboutyearsago,themostcommonmethodtoreprogramadevicewastohaveanEPROM
memory chip in a socket that was physically removed from the device, erased under UV radiation,
and programmed using a dedicated development system, i.e., a PC with a hardware programming
device, and then put back into the system.