Seen from a single device's point of view, EIB's System Characteristics combined with the node's local hosting features may be summarized as follows. (Note that this representation emphasizes functionality and features, thus slightly blurring the OSI picture.)

standard "device" nodes

Most EIB "device" nodes provide (a standardised subset of) the following elements (services):

• network communication

• resource management

• local application (program)

This is the task-specific logic which caters for the building automation functionality provided by the device. It usually communicates with other partners on the network via Communication Objects, bound to remote ones via a group address to form a shared variable.

Within the device itself, the application program also has to deal with the interaction with the task-specific hardware (e.g. flow sensor, analog output actuator, …), perhaps with the help of some general-purpose hosting services.

• hosting services

Some nodes encapsulate various auxiliary services into libraries which can be accessed by "guest" services. One example is an additional API to a local communication driver.

The guest can be simply the local application (which perhaps may be loaded at configuration time), or an external guest via a local link (e.g. the serial PEI).

• node control

In a device, all other services of course run under the control of the local firmware and its operating system. This may be anything from simple cyclic or interrupt driven up to fully fledged multi-threading PC operating systems.

In some cases, the device may publish specific configuration properties (via the Resource Management) which allow to tune the node's behaviour at this local OS level, or to enable, disable or tune the other EIB services.

This model is exemplified by general-purpose node profiles as implemented in BCU's and BIM's described further in this section.

node profiles streamline implementation flavours

EIB aims to be open multi-vendor system. This is not only true for products and installations, but also at the level of system implementations (whether proprietary or OEM).

As a consequence, EIB must allow for 3rd party implementations, adapted to application needs, price and technology developments in the microprocessor market, vendor know-how and experience, and indeed, the evolution of the EIB system itself.

This means that the precise set of features some manufacturer's implementation supports may vary, as may the exact way the abstract model is finally implemented. Some of these aspects remain completely hidden at all times in the device, and hence are of no relevance. Sometimes though, variations may become visible, for example when a configuration controller reads or sets node resources. A resource can appear in some particular size or format, or the API to access it in a particular version.

It is clear that the resulting diversity must be controlled. To this end, EIB defines detailed profiles, describing all allowed "flavours" of any pertinent feature, and their permitted combinations. Methods and properties are defined so that a node's communication partner can discover the relevant characteristics.

special node types

Apart from "everyday devices", EIB also specifies profiles for special devices like couplers (e.g. linking different media or a TP line to its main line, also performing routing functionality) etc.

Profiles are being extended to include hubs or switches (federating several lines into an area), EIB ANubis couplers and mappers (to integrate one or more EIB subnetworks into a internet Service Environment)), management clients and controllers (for network configuration) etc.