Display,

actuators,
Sensor Input Processing Output signals,
control

A Brief Tutorial
on the IEEE 1451.1
Standard
Part 13 in a series of tutorials in instrumentation and measurement

V. Viegas, M. Pereira, and P. Girão

T
he integration of microprocessors in the trans-
ducer body has afforded the opportunity for
adding intelligence to the transducer and for
making it “pluggable” to digital communication net-
works. From the manufacturer’s viewpoint, the work of
together. This article focuses on the 1451.1 Standard
(Std.) [1], which defines a software interface suitable to
represent any networked smart transducer.
IEEE 1451.1 Overview

13
adding intelligence to transducers is a good invest- The 1451.1 Std. addresses th e definition of a Network
ment because it adds value to the device Capable Application Processor (NCAP).
itself. On the other hand, interfacing The NCAP is a piece of hardware
transducers with the wide vari- and software that acts as a
ety of fieldbuses currently bridge between transducers
7
2 4
Thirteenth
available, each with its own and the communication
protocol specifications, network (Figure 1). On the
is a huge headache. For field side, an abstraction
this reason, manufactur- 1 layer provides high-level
in a 12
Series
ers tend to choose a par- functionality to commu-
ticular fieldbus and work
around it. Others decide 55 16
1 6
nicate with transducers.
On the network side, an
to create a new, customized
fieldbus for their products.
33 abstraction layer provides
high-level functionality to
This diversity of fieldbuses and handle network requests. In the
network protocols leads a manufac- middle, the control routine adds intel-
turer to closed, less-flexible, and generally ligence to the NCAP by running algorithms
more-expensive solutions. that process the data received by both sides (the field
The 1451 family of standards tries to solve this prob- and the network) and decide the next state of the
lem by proposing a set of standardized hardware and system. The software architecture of the 1451.1 Std. is
software interfaces that act as “plugs,” whereby the based on an information model, a data model, and two
heterogeneous components can be connected and work network communication models.

38 IEEE Instrumentation & Measurement Magazine April 2008

1094-6969/08/$25.00©2008IEEE
 Display,
actuators,
Sensor Input Processing Output signals,
control

Information Model w Block classes perform processing.

The information model is composed of a hierarchy of object w Component classes encapsulate data.
classes divided in three main categories (see Figure 2), as fol- w Service classes handle inter-NCAP communications and
lows: system-wide synchronization.
All Blocks, Components, and Services share a common
characteristic: they are also Entities. The Entity abstract class
provides generic attributes for all 1451.1 objects that are vis-
ible across the network. Table 1 briefly describes some of those
attributes.
The hierarchy is extensible by adding non-1451.1 object
classes to satisfy particular requirements of a given applica-
tion. NCAP manufacturers should develop the object model
for their product and deploy it as a reusable software library so
that system developers can include it in their projects.

Data Model
Fig. 1. Network Capable Application Processor (NCAP).
The data model defines the data types used to
exchange information between Entities inside
Root [1] the NCAP process and across the network. The
Entity [1.1]
Block [1.1.1] data model supports the following primitive
NCAP Block [1.1.1.1] data types:
Function Block [1.1.1.2]
Base Transducer Block [1.1.1.3] w Boolean (true or false)
Transducer Block [1.1.1.3.1]
DotX Transducer Block [1.1.1.3.1.X] w Octet (eight-bit quantity not interpreted as a
Component [1.1.2] number)
Parameter [1.1.2.1]
Parameter With Update [1.1.2.1.1] w Integer (signed and unsigned number from
Physical Parameter [1.1.2.1.1.1]
Scalar Parameter [1.1.2.1.1.1.1] eight bits to 64 bits)
Scalar Series Parameter [1.1.2.1.1.1.1.1] w Float (single and double precision number ac-
Vector Parameter [1.1.2.1.1.1.2]
Vector Series Parameter [1.1.2.1.1.1.2.1] cording to the IEEE 754 Std. [2])
...
Service [1.1.3] w String (array of octets containing human read-
Base Port [1.1.3.1] able text)
Base Client Port [1.1.3.1.1]
Client Port [1.1.3.1.1.1] w Arrays of the previous data types
Asynchronous Client Port [1.1.3.1.1.2]
Base Publisher Port [1.1.3.1.2]
The data model also supports structures
Publisher Port [1.1.3.1.2.1] of primitive data types to represent complex
Self Identifying Publisher Port [1.1.3.1.2.2]
Event Generator Publisher Port [1.1.3.1.2.2.1] quantities such as time and measurements. A
Subscriber Port [1.1.3.2]
special data type, called Argument, is used as
a container to transport any of the data types,
...
especially in network communications. Similar
containers exist in current software technolo-
Fig. 2. Information model proposed by the 1451.1 Std.

Table 1—Entity attributes

Attribute Data type Accessa Unique values? Description
Object tag Octet array R/W Preferentially Tags are logical names given to Entities to
help system configuration. The Object
Tag is also used as an alias to the Dispatch
Address.
Object ID Octet array R Yes, in the context of all It represents a unique identifier that
executing systems unambiguously distinguishes the Entity
across the network.
Object name String R Yes, in the context of the It represents the name of the class instance
NCAP process given by the programmer.
Dispatch address String R Yes, in the context of all It represents the Universal Resource Locator
executing systems (URL) of the Entity in the network.
a
R: read; R/W: read and write.

April 2008 IEEE Instrumentation & Measurement Magazine 39

 encoded into an Argument
array type.
l The network infrastructure
invokes the Perform func-
tion on the target server
object.
m The Perform function in-
vokes the desired server
object operation.
n When the operation com-
pletes, it returns to Perform
with its output arguments
filled in.
o The network infrastructure
returns the operation re-
sults to the Client Port.
Fig. 3. Client/server communication model.
p The Execute function re-
turns the operation results
to the invoking client.
Using the publish/
subscribe model, the lo-
cal NCAP (publisher) can
broadcast messages on
the network whenever it
has some kind of “public
announcement” to make.
These messages, known
as “publications,” contain
context data describing the
domain, syntax, and se-
mantics of the information
they carry. Based on this
context data—or metadata,
for short—a remote NCAP
(subscriber) can filter the
Fig. 4. Publish/subscribe communication model. publications of its inter-
est and consume their at-
gies, as is the case of the Variant data type used in Microsoft tached data. This model is based on the Messaging paradigm
ActiveX. [5], and it is a very efficient way to implement distributed
events. Figure 4 illustrates the steps involved in a typical pub-
Network Communication Models lish/subscribe communication, and an explanation of each
The 1451.1 Std. provides two models of inter-NCAP commu- step follows:
nication: a tightly coupled client/server model for one-to-one j The publisher configures the metadata of the publication
communications and a loosely coupled publish/subscribe in the Publisher Port.
model for one-to-many communications. k The subscriber configures the metadata of the subscrip-
Using the client/server model, a remote NCAP (client) can tion in the Subscriber Port.
invoke a function on the local NCAP (server) and consume l The subscriber invokes the function AddSubscriber in
the returned results. This model is based on the Remote Proce- the Subscriber Port to register the callback function to be
dure Call (RPC) paradigm [3], [4]. Figure 3 is a diagram of this called if a valid publication is received.
model, and the following is a description of each step: m The publisher invokes the Publish function in the Pub-
j The Client Port in the client’s process space is bound to the lisher Port, passing it the contents of the publication as an
Dispatch Address of the server object. input argument encoded into an Argument array type.
k The client invokes the Execute function on the Client Port, n The Subscriber Port filters incoming publications by
indicating which operation of the remote server object comparing publication’s metadata with port’s metadata.
is to be executed. It provides input arguments for that If there is a match, then the publication is taken into ac-
operation and references to its output arguments, each count.

40 IEEE Instrumentation & Measurement Magazine April 2008


o After the publication passes the filter, the Subscriber Port
invokes the registered callback operation, passing it the
contents of the publication.
Blocks
Block classes include the NCAP Block, Transducer Blocks, and
Function Blocks. To help the internal organization of the NCAP
process in terms of initialization and configuration, the 1451.1
Std. defines owning relations between Blocks and the other
Entities. These logical relations obey the following rules:
w The owning relations do not cross process space boundar-
ies.
w Only Blocks may own objects.
w The owning relations define a tree structure in which the
NCAP Block is the root. The NCAP Block is the only object
that owns itself.
w Each non-Block object (Component, Service, or non-
1451.1 object) there is precisely one Block that owns it.
Every NCAP process has a single top-level object, the
NCAP Block, which is in charge for the management of all
underlying Entities. The management process includes four
main tasks:
w System startup: The NCAP Block is responsible for creat-
ing the initial set of objects that guarantee minimum sys-
tem operability. The recommendations state that the start-
up information, which includes a list of object types and
attribute values, should be kept in a nonvolatile storage
device, such as the hard disk or an EEPROM memory.
w Generation of Object IDs: During the process of creating
an Entity instance, the NCAP Block provides a function to
generate a unique Object ID for that instance.
w Keep track of all network-visible Entities present in the
system: To accomplish this task it is necessary that all
NCAP Blocks announce their presence across the net-
work and broadcast updated information about all net-
work-visible Entities that they own. To do this, the 1451.1
Std. provides two publications:
w PSK_NCAPBLOCK_ANNOUNCEMET: After com-
pleting the start-up process, the NCAP Block issues this
publication to notify its presence across the network.
w PSK_NETWORK_VISIBLE_SERVER_OBJECT_PROP-
ERTIES: Whenever a network-visible Entity suffers a
“profound change” (as happens when a Parameter gets
its metadata changed or its Object Tag modified), the cor-
responding NCAP Block communicates that occurrence
to the entire network by issuing this publication.
At the same time, all NCAP Blocks listen to these publica-
tions and use the attached information to construct and maintain
a faithful image of the network in which they are integrated.
Transducer Blocks are software drivers that support com-
munications with transducers. The 1451.1 information model
is natively prepared to include Transducer Blocks from 1451.X
standards, but additional Transducer Blocks can be included
to support other fieldbuses (e.g., Profibus or Foundation Field-
Bus). Generically speaking, Transducer Blocks provide the
following functionalities:
April 2008 IEEE Instrumentation & Measurement Magazine 41
Display,
actuators,
Sensor Input Processing Output signals,
control
w They read data from sensors.
w They write actuation values.
w They read status registers.
w They read/write interrupt masks.
w They read/write transducer Transducer Electronic Data
Sheet (TEDS) [6], a memory structure that describes trans-
ducer characteristics.
w They enable/disable the Correction Engine [6], a software
component that converts raw data from the field into en-
gineering units, and vice versa.
As the name indicates, Function Blocks behave like soft-
ware functions: they process input data using logical and
mathematical operations and return the results. Examples of
typical Function Blocks include Proportional Integral Deriva-
tive (PID) controllers, square root extractors, comparators, and
multiplexers. The 1451.1 Std. does not specify any Function
Block in concrete terms, only an abstract class that describes
the macroscopic behavior of third-party Function Blocks. The
idea is that component manufacturers shall develop and de-
ploy prefabricated Function Blocks so that system developers
can reuse them.
Components
Component classes include Parameters, Actions, and Files. Pa-
rameters classes are data repositories used to store information
related with Blocks. The 1451.1 Std. distinguishes four types of
Parameters, as follows:
w Parameter: This Component represents a simple variable
that can be read and written.
w Parameter with Update: This Component adds additional
support for data synchronization between the Parameter
and its owning Block. For example, the function Update-
AndRead instructs the owning Block to acquire fresh data
(from a sensor, for example) and store it in the Parameter.
w Physical Parameters: These Components provide ad-
ditional metadata structures used to describe measur-
ing quantities. Typical metadata fields include units,
maximum and minimum values, data type, uncertainty,
sampling period, and other attributes. Whenever the
information held by the Physical Parameter changes, in
terms of either value or metadata, it broadcasts the publi-
cation PSK_PHYSICAL_PARAMETRIC_DATA to inform
the network of that occurrence.
w Time Parameter: This Component behaves as a timer by
providing time representations of some event. Whenever
the timer ticks, it issues the publication PSK_TIMER_
TICK to share its time stamp with all subscribers across
the network.
The diversity of data types and metadata fields provided
by Physical Parameters makes possible the representation of
(almost) every conceivable physical quantity. Table 2 gives an
idea about the extensibility of Physical Parameters.
Service
The Action Component handles complex inter-NCAP opera-
tions, called Transactions, which require significant time to ex-
ecute. It provides functions to invoke and abort Transactions,
as well as to query them about their internal executing state.
The File Component handles network-visible data resources,
generically called Files. It provides a software interface that
resembles the FTP by including functions to open, read, write,
and close remote Files.
Services
Service classes include communication ports and Mutexes. All
communication ports provide functions to get/set the time-out
and the priority of the on-wire messages. Two priority values
are possible: MP_NORMAL and MP_EXPEDITE. Client Ports
implement the client/server communication model presented
in Figure 3. Besides the basic functionality described earlier,
Client Ports offer two advanced modes of operation:
w Asynchronous mode: This is a nonblocking operation
mode in which the Execute function returns to the invok-
ing Client as soon as the message is transmitted. Later, the
Client can query the port as to whether the remote server
operation has completed and, if so, request from the port
any returned data.
w “Send and Forget” mode: This is also a nonblocking
operation mode, similar to the previous one. The only dif-
ference is that the Client does not care about any returned
data at all.
Publisher/Subscriber Ports implement the publish/sub-
scribe communication model presented in Figure 4 by pro-
viding functions to issue publications, to edit metadata of
publications and subscriptions, and to register subscription
callbacks.
Mutexes are semaphores that guarantee exclusive access
to network-visible NCAP resources. They provide atomic
functions such as Lock and Unlock in order to allow one and
only one remote client to execute a given NCAP operation at
a time.
Putting it All Together
In the previous sections, we analyzed the 1451.1 Std., starting
with an overview and stressing its main features. Now, we
assemble the parts and see how they work together. Figure 5 il-
lustrates the internal organization of a typical user application
running on a NCAP. The application works as follows (arrows
represent the data flow between objects):
j The application starts by creating the NCAP Block, which
instantiates all the other objects, giving them unique Ob-
ject IDs. The start-up information can be stored in the hard
disk by means of a configuration file. Subsequently, the
NCAP Block issues the publication PSK_NCAPBLOCK_
ANNOUNCEMENT to inform the network about the
arrival of a new NCAP Block, including detailed informa-
tion about itself and all its child objects.
k The NCAP Block constructs and maintains a data
structure that represents all the Entities visible across
the entire network. To update this “network image,”
the NCAP Block subscribes two publications: PSK_
NCAPBLOCK_ANNOUNCEMENT and PSK_NET-

Table 2—Examples of physical parameters

Physical parameter Usage
Scalar parameter Used to represent an
individual quantity
Scalar series parameter Used to represent an
individual waveform
Vector parameter Used to represent
correlated individual
quantities
Vector series parameter Used to represent
correlated waveforms
Data type Examples of physical quantities
Numeric Readings from a thermometer, voltmeter, etc.
Boolean On/off signal to actuate a pump
Octet array Raw data value returned by a digital counter
Numeric array Analog waveform registered by an oscilloscope
or the amplitude spectrum computed by a
spectrum analyzer
Boolean array Digital waveform registered by a logic analyzer
Two-dimensional Raw data values returned by an analog to
(2D) octet array digital converter (ADC)
Numeric array Latitude, longitude, and elevation coordinates
measured by a Global Positioning System
(GPS)
Boolean array Group of correlated on/off alarms
2D octet array Group of correlated barcodes
2D numeric array Analog waveforms registered by a multi-
channel oscilloscope
2D boolean array Digital waveforms registered by a multi-
channel logic analyzer
Three-dimensional Sequence of raw data values returned by a
octet array multi-channel ADC

42 IEEE Instrumentation & Measurement Magazine April 2008

 Display,
actuators,
Sensor Input Processing Output signals,
control

WORK_VISIBLE_SERVER_OBJECT_PROPERTIES. The its metadata in a Physical Parameter. This occurrence,

first subscription listens to network-incoming NCAP which represents a “profound change” in the Physical
Blocks; the second one intercepts changes in existing Parameter behavior, is reported to the network by issuing
network-visible Entities. This distributed arrangement the publication PSK_PHYSICAL_PARAMETRIC_DATA.
guarantees maximum robustness, because the crash of o Using the publish/subscribe model, Function Blocks can
one NCAP Block does not compromise the integrity of subscribe publications from remote Parameters in order
the whole system. to receive fresh data from the network.
l The control routine implements application-specific p Using the client/server model, every Entity can receive
functionality. It receives data from input Parameters, an RPC. The remote call is performed and eventual results
processes it using a combination of Function Blocks, and must be returned to the client.
returns results to output Parameters. q Using the client/server model, every Entity can initiate
m Parameters introduce a buffering layer between the an RPC. To execute the remote call, the Entity must know
control routine and Transducer Blocks. Readings from the Dispatch Address of the server object, which is pro-
sensors and updates to actuators are stored in Physical vided by the local NCAP Block by means of a query to its
Parameters and are available to other Entities in the local “network image.”
NCAP and across the network. Every time the value of The network infrastructure handles low-level commu-
a Physical Parameter changes, it issues the publication nication details in order to facilitate the implementation of
PSK_PHYSICAL_PARAMETRIC_DATA so that the en- high-level communication models, as those defined by the
tire network is informed. The same applies to the Time 1451.1 Std. For this reason, the choice of a “good” network
Parameter with respect to the PSK_TIMER_TICK publi- infrastructure is fundamental for the success of a NCAP ap-
cation. plication. With respect to Ethernet, there are many middleware
n 1451.X Transducer Blocks are supplied with hardware technologies that extend far beyond the basic functionalities
and software features in order to auto-detect the connec- provided by simple Transmission Control Protocol and User
tion of compatible transducers. When the transducer first Datagram Protocol sockets. Some of them have proved to be
connects, the Transducer Block reads its TEDS and stores effective in the development of NCAP prototypes, as it is in the
case of ADAPTIVE Com-
munication Environment
[7]-[9], Java.net [10], and
Web Services [11], [12].
Another point of inter-
est is to understand how to
translate system functional
requirements into NCAP
devices and 1451.1 objects.
The design of a 1451.1 solu-
tion typically consists of the
following steps:
w The system requirements
are analyzed in order to de-
cide the number of NCAPs
needed, their locations, and
their assignments.
w Each NCAP assignment is
mapped onto a set of 1451.1
objects.
w An appropriate schema for
inter-NCAP communica-
tion is delineated.
To demonstrate the use of
the object model, consider, as
an example, the water-sup-
ply pump system presented
in Figure 6. The purpose of
the system is to maintain
the water level between two
Fig. 5. Data Flow inside the NCAP. threshold values by turning

April 2008 IEEE Instrumentation & Measurement Magazine 43

the pump on and off (e.g., 40% and 70% of the tank capacity).
In this way, water is available for consumption, and the water
level never exceeds the tank capacity. A level transmitter mea-
sures the water level and two level switches provide two alarm
signals: a high-level alarm if the water level reaches the top of
the tank and a low-level alarm if the water level reaches the
bottom of the tank. The control strategy consists of a hysteresis
algorithm and a set of logical equations to handle alarm condi-
tions. An operator station supervises the system remotely.
The water-supply system uses two NCAPs: a local NCAP
in the field and a remote NCAP in the operator room. The
local NCAP acquires sensor signals, executes the water level
control loop, and actuates the pump. The remote NCAP hosts
the system’s Human-Machine Interface (HMI) and logs data
to a database.
Figure 7(a) shows a mapping of the local NCAP function-
ality onto 1451.1 objects. Since all transducers hosted by the
local NCAP are compliant with the 1451.2 Std., the WaterLev-
elTransducerBlock object is an instance of the Dot2 Transducer
Block class. Furthermore, it owns four Scalar Parameters,
thus:
w the PumpScalarParameter that holds pump’s actuation
values,
w the WaterLevelScalarParameter that retains samples from
the level transmitter, and
w the pair of HLevelAlarmScalarParameter/LLevelAlarm-
ScalarParameter that catches high-/low-level alarms.
The control strategy is implemented by the Hysteresis-
FunctionBlock object, which is a specialization of the Function
Block class.
Figure 7(b) shows a mapping of the remote NCAP function-
ality onto 1451.1 objects. The remote NCAP has no Transducer
Blocks because it does not connect to any transducer. Instead,
it implements two specialized Function Blocks: the LogFunc-
tionBlock that records data from transducers into a database
and the HMIFunctionBlock that provides functions to interact
with the operator. There are no Parameters associated with
these Blocks.
Figure 7 also shows a valid schema for inter-NCAP com-
munication. All Blocks and Parameters from both NCAPs
Fig. 6. Water-supply pump system.
44 IEEE Instrumentation & Measurement Magazine April 2008
are network visible because all of them can receive RPCs.
Using a Client Port, the remote NCAP can invoke the op-
erations Get/SetHighThreshold and Get/SetLowThreshold,
provided by the HysteresisFunctionBlock object, in order to
get/set the hysteresis window, in which the water level can
vary. It also can invoke the operation SetMode to switch the
system to manual mode, overriding the automatic control of
the pump. Additionally, all field variables are transmitted to
the operator station by means of matched Publisher/Sub-
scriber Ports on both NCAPs. This high-speed communica-
tion path allows the database and the HMI to be updated in
real time.
Alternatively, the control strategy could consist of a PID
algorithm. That scenario would bring some changes to the sys-
tem: first, the pump actuator would become analog; second,
the HysteresisFunctionBlock would be replaced by some kind
of “PIDFunctionBlock,” which would implement the PID al-
gorithm and provide functions to get/set controller variables,
such as the set point and proportional/integral/derivative
gains.
Conclusions
This article is a brief tutorial for those who are interested in the
1451.1 Std. All the main parts of the standard were covered:
the information model (which includes Blocks, Components,
and Services), the data model (which is used by Parameters
to represent physical quantities), and the two communication
models (client/server and publish/subscribe). Finally, we
showed how these parts work together in order to implement
the concept of NCAP, using an application example based on a
simple water-supply pump system.
Despite the vast set of functionalities provided by the
1451.1 Std. and the advantages carried by standardization,
there are no commercial NCAPs available on the market. We
hope to make a commercial NCAP available by pursuing our
work on the 1451.1 Std.; by calling the community’s attention
to its benefits; and by searching for new ways to improve it. We
are working on a service-oriented NCAP prototype that takes
advantage of two emergent technologies: Web Services and
Windows Communication Foundation [13].

Fig. 7. Mappings of NCAP functionality onto 1451.1 objects: (a) local NCAP; (b) remote NCAP.
References
[1] IEEE Standard for a Smart Transducer Interface for Sensors and
Actuators—Network Capable Application Processor (NCAP)
Information Model, IEEE Std. 1451.1, 1999.
[2] Standard for Binary Floating-Point Arithmetic, IEEE Std. 754, 1985.
[3] A. Birrel and B.J. Nelson, “Implementing remote procedure calls,”
ACM Trans. Comput. Syst., vol. 2, (no. 1), Feb 1984.
[4] ISO/IEC Std. 11578-1996, “Remote Procedure Call (RPC)
Specification”.
[5] D.A. Chappell and R. Monson-Haefel, “Understanding the
Messaging Paradigm”, Java Message Service, 1st Edition,
Sebastopol, California, USA, O’Reilly & Associates, 2001, pp.1-16.
[6] IEEE Standard for a Smart Transducer Interface for Sensors and
Actuators—Transducer to Microprocessor Communication Protocols
and Transducer Electronic Data Sheet (TEDS) Formats, IEEE Std.
1451.2, 1997.
[7] ACE (ADAPTIVE Communication Environment) [Online]
Available http://www.cs.wustl.edu/~schmidt/ACE.html.
April 2008 IEEE Instrumentation & Measurement Magazine 45
Display,
actuators,
Sensor Input Processing Output signals,
control
[8] K.B. Lee and E.Y. Song, “Object-oriented application framework
for IEEE 1451.1 Standard,” IEEE Trans. Instrum. Meas., vol. 54, (no.
4), pp. 1527–1533, Aug 2005.
[9] A. Stepanenko, K. Lee, R. Kochan, V. Kochan, A. Sachenko,
“Development of a minimal IEEE 1451.1 model for microcontroller
implementation,” IEEE Sensors Appl. Symp., Houston, Texas, USA,
Feb 2006.
[10] K. Lee and E. Song, “A wireless environmental monitoring system
based on the IEEE 1451.1 Standards,” Proc. IMTC 2006, Sorento,
Italy, Apr 2006, pp. 1931–1936.
[11] Web Services Activity Page from W3C (World Wide Web
Consortium) [Online] Available http://www.w3.org/2002/ws.
[12] V. Viegas, J.M. Dias Pereira, and P. Silva Girão, “Using a
commercial framework to implement and enhance the IEEE
1451.1 Standard,” Proc.IMTC 2005, Ottawa, Ontario, Canada,
May 2005.
[13] WCF (Windows Communication Services) [Online] Available
http://wcf.netfx3.com.
 Vítor Viegas received his de-
gree in Electrical and Computer
Engineering from the Instituto
Superior Técnico of the Tech-
nical University of Lisbon in
1999, and he received the M.Sc.
degree from the same school in
2003. He works as a teaching as-
sistant at the Escola Superior de
Tecnologia de Setúbal of Insti-
tuto Politécnico de Setúbal. His
main research activities concern
virtual, smart, and distributed instrumentation.
J. M. Dias Pereira (joseper@
est.ips.pt) (M’00–SM’04) re-
ceived his degree in Electrical
Engineering from the Instituto
Superior Técnico (IST) of the
Technical University of Lisbon
in 1982. He worked for Portu-
gal Telecom for 8 yr in digital
switching and transmission
systems. In 1992, he returned to
teaching as Assistant Professor
in Escola Superior de Tecnolo-
46 IEEE Instrumentation & Measurement Magazine April 2008
gia of Instituto Politécnico de Setúbal, where he is, at present,
a Coordinator Professor. In 1995, he received the M.Sc. degree
and in 1999 the Ph.D. degree in Electrical Engineering and
Computer Science from IST. His main research interests are
included in the Instrumentation and Measurements areas.
P.M.B. Silva Girão (M’00,
SM’01) received the Ph.D. de-
gree in electrical engineering
from the Instituto Superior
Técnico of the Technical Uni-
versity of Lisbon (IST/UTL)
in 1988. In 1975, he joined the
Department of Electrical Engi-
neering at IST/UTL, first as a
Lecturer and, since 1988, as an
Associate Professor. Presently
his main research interests are
instrumentation, transducers, measurement techniques, and
digital data processing, particularly for biomedical, environ-
mental, chemical, and civil applications. Metrology, quality,
and electromagnetic compatibility are also areas of regular
activity, mainly as an auditor for the Portuguese Institute
for Quality. Dr. Girão is chairman of IMEKO TC19–Environ-
mental Measurements and vice-president of the Portuguese
Metrology Society.