![](bg2.png)
Network Capable Application Processor (NCAP) [1], targeting software-based, net-
work independent, transducer application environments, (ii) and a standard digital
interface and communication protocol, IEEE 1451.2 [2], for accessing the transducer
via a microprocessor modeled by the NCAP. The next two standards, IEEE 1451.3
and 1451.4, extend the possible single-attached configurations to distributed mul-
tidrop buses, and to mixed-mode, i.e. analog + digital communication enabling also
analog transducers. The last two discussed proposals, IEEE 1451.5 and 1451.0 de-
scribe wireless communication protocols and drive harmonization of individual stan-
dards of the 1451 family [3].
2.1 IEEE 1451.1 NCAP
The 1451.1 software architecture provides three models of the transducer device
environment: (i) an object model of a network capable application processor (NCAP),
which is the object-oriented embodiment of a smart networked de-vice; (ii) a data
model, which specifies information encoding rules for transmitting information across
both local and remote object interfaces; and (iii) network communication model,
which supports client/server and publishers/subscribers paradigms for communicating
information between NCAPs. The standard defines a network and transducer hard-
ware neutral environment in which a concrete sensor/actuator application can be
developed.
The object model definition encompasses a set of object classes, attributes, meth-
ods, and behaviors that specify a transducer and a network environment to which it
may connect. This model uses block and base classes offering pat-terns for one
Physical Block, one or more Transducer Blocks, Function Blocks, and Network
Blocks. Each block class may include specific base classes from the model. The base
classes include Parameters, Actions, Events, and Files, and provide component
classes.
Block classes form the major blocks of functionality that can be plugged into an
abstract card-cage to create various types of devices. One Physical Block is manda-
tory as it defines the card-cage and abstracts the hardware and software resources that
are used by the device. All other blocks and component base classes can be refer-
enced from the Physical Block.
The Physical Block representing the card-cage contains all the logical hardware and
software resources in the model. These resources determine the basic characteristics
of the device being assembled. Information contained in the Physical Block as attrib-
utes include the manufacturer’s identification, serial number, hardware and software
revision information, and more importantly, data structures that provide a repository
for other class components. As previously mentioned, the Physical Block is the logi-
cal container for all components in the device model; therefore, it must have access to
and be able to locate all available resources instantiated by the device. The data struc-
tures provided by the Physical Block house pointers (Instance_ID) to these compo-
nents and, in that way, offer easy indirect access to them. To communicate to a device
or a device object across the network when a remote NCAP requests an attribute from
the Physical Block, that Physical Block has to resolve address queries from the net-
work. For this purpose a hierarchical naming/addressing scheme is used based on
65