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- together. This article focuses on the 1451.1 Standard
ducer body has afforded the opportunity for (Std.) [1], which defines a software interface suitable to
adding intelligence to the transducer and for represent any networked smart transducer.
making it “pluggable” to digital communication net-
works. From the manufacturer’s viewpoint, the work of 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

 Display,
actuators,
Sensor Input Processing Output signals,
control

o After the publication passes the filter, the Subscriber Port w They read data from sensors.
invokes the registered callback operation, passing it the w They write actuation values.
contents of the publication. w They read status registers.
w They read/write interrupt masks.
Blocks w They read/write transducer Transducer Electronic Data
Block classes include the NCAP Block, Transducer Blocks, and Sheet (TEDS) [6], a memory structure that describes trans-
Function Blocks. To help the internal organization of the NCAP ducer characteristics.
process in terms of initialization and configuration, the 1451.1 w They enable/disable the Correction Engine [6], a software
Std. defines owning relations between Blocks and the other component that converts raw data from the field into en-
Entities. These logical relations obey the following rules: gineering units, and vice versa.
w The owning relations do not cross process space boundar- As the name indicates, Function Blocks behave like soft-
ies. ware functions: they process input data using logical and
w Only Blocks may own objects. mathematical operations and return the results. Examples of
w The owning relations define a tree structure in which the typical Function Blocks include Proportional Integral Deriva-
NCAP Block is the root. The NCAP Block is the only object tive (PID) controllers, square root extractors, comparators, and
that owns itself. multiplexers. The 1451.1 Std. does not specify any Function
w Each non-Block object (Component, Service, or non- Block in concrete terms, only an abstract class that describes
1451.1 object) there is precisely one Block that owns it. the macroscopic behavior of third-party Function Blocks. The
Every NCAP process has a single top-level object, the idea is that component manufacturers shall develop and de-
NCAP Block, which is in charge for the management of all ploy prefabricated Function Blocks so that system developers
underlying Entities. The management process includes four can reuse them.
main tasks:
w System startup: The NCAP Block is responsible for creat- Components
ing the initial set of objects that guarantee minimum sys- Component classes include Parameters, Actions, and Files. Pa-
tem operability. The recommendations state that the start- rameters classes are data repositories used to store information
up information, which includes a list of object types and related with Blocks. The 1451.1 Std. distinguishes four types of
attribute values, should be kept in a nonvolatile storage Parameters, as follows:
device, such as the hard disk or an EEPROM memory. w Parameter: This Component represents a simple variable
w Generation of Object IDs: During the process of creating that can be read and written.
an Entity instance, the NCAP Block provides a function to w Parameter with Update: This Component adds additional
generate a unique Object ID for that instance. support for data synchronization between the Parameter
w Keep track of all network-visible Entities present in the and its owning Block. For example, the function Update-
system: To accomplish this task it is necessary that all AndRead instructs the owning Block to acquire fresh data
NCAP Blocks announce their presence across the net- (from a sensor, for example) and store it in the Parameter.
work and broadcast updated information about all net- w Physical Parameters: These Components provide ad-
work-visible Entities that they own. To do this, the 1451.1 ditional metadata structures used to describe measur-
Std. provides two publications: ing quantities. Typical metadata fields include units,
w PSK_NCAPBLOCK_ANNOUNCEMET: After com- maximum and minimum values, data type, uncertainty,
pleting the start-up process, the NCAP Block issues this sampling period, and other attributes. Whenever the
publication to notify its presence across the network. information held by the Physical Parameter changes, in
w PSK_NETWORK_VISIBLE_SERVER_OBJECT_PROP- terms of either value or metadata, it broadcasts the publi-
ERTIES: Whenever a network-visible Entity suffers a cation PSK_PHYSICAL_PARAMETRIC_DATA to inform
“profound change” (as happens when a Parameter gets the network of that occurrence.
its metadata changed or its Object Tag modified), the cor- w Time Parameter: This Component behaves as a timer by
responding NCAP Block communicates that occurrence providing time representations of some event. Whenever
to the entire network by issuing this publication. the timer ticks, it issues the publication PSK_TIMER_
At the same time, all NCAP Blocks listen to these publica- TICK to share its time stamp with all subscribers across
tions and use the attached information to construct and maintain the network.
a faithful image of the network in which they are integrated. The diversity of data types and metadata fields provided
Transducer Blocks are software drivers that support com- by Physical Parameters makes possible the representation of
munications with transducers. The 1451.1 information model (almost) every conceivable physical quantity. Table 2 gives an
is natively prepared to include Transducer Blocks from 1451.X idea about the extensibility of Physical Parameters.
standards, but additional Transducer Blocks can be included
to support other fieldbuses (e.g., Profibus or Foundation Field- Service
Bus). Generically speaking, Transducer Blocks provide the The Action Component handles complex inter-NCAP opera-
following functionalities: tions, called Transactions, which require significant time to ex-

April 2008 IEEE Instrumentation & Measurement Magazine 41

ecute. It provides functions to invoke and abort Transactions, publications and subscriptions, and to register subscription
as well as to query them about their internal executing state. callbacks.
The File Component handles network-visible data resources, Mutexes are semaphores that guarantee exclusive access
generically called Files. It provides a software interface that to network-visible NCAP resources. They provide atomic
resembles the FTP by including functions to open, read, write, functions such as Lock and Unlock in order to allow one and
and close remote Files. only one remote client to execute a given NCAP operation at
a time.
Services
Service classes include communication ports and Mutexes. All Putting it All Together
communication ports provide functions to get/set the time-out In the previous sections, we analyzed the 1451.1 Std., starting
and the priority of the on-wire messages. Two priority values with an overview and stressing its main features. Now, we
are possible: MP_NORMAL and MP_EXPEDITE. Client Ports assemble the parts and see how they work together. Figure 5 il-
implement the client/server communication model presented lustrates the internal organization of a typical user application
in Figure 3. Besides the basic functionality described earlier, running on a NCAP. The application works as follows (arrows
Client Ports offer two advanced modes of operation: represent the data flow between objects):
w Asynchronous mode: This is a nonblocking operation j The application starts by creating the NCAP Block, which
mode in which the Execute function returns to the invok- instantiates all the other objects, giving them unique Ob-
ing Client as soon as the message is transmitted. Later, the ject IDs. The start-up information can be stored in the hard
Client can query the port as to whether the remote server disk by means of a configuration file. Subsequently, the
operation has completed and, if so, request from the port NCAP Block issues the publication PSK_NCAPBLOCK_
any returned data. ANNOUNCEMENT to inform the network about the
w “Send and Forget” mode: This is also a nonblocking arrival of a new NCAP Block, including detailed informa-
operation mode, similar to the previous one. The only dif- tion about itself and all its child objects.
ference is that the Client does not care about any returned k The NCAP Block constructs and maintains a data
data at all. structure that represents all the Entities visible across
Publisher/Subscriber Ports implement the publish/sub- the entire network. To update this “network image,”
scribe communication model presented in Figure 4 by pro- the NCAP Block subscribes two publications: PSK_
viding functions to issue publications, to edit metadata of NCAPBLOCK_ANNOUNCEMENT and PSK_NET-

Table 2—Examples of physical parameters

Physical parameter Usage Data type Examples of physical quantities
Scalar parameter Used to represent an Numeric Readings from a thermometer, voltmeter, etc.
individual quantity
Boolean On/off signal to actuate a pump
Octet array Raw data value returned by a digital counter
Scalar series parameter Used to represent an Numeric array Analog waveform registered by an oscilloscope
individual waveform 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)
Vector parameter Used to represent Numeric array Latitude, longitude, and elevation coordinates
correlated individual measured by a Global Positioning System
quantities (GPS)
Boolean array Group of correlated on/off alarms
2D octet array Group of correlated barcodes
Vector series parameter Used to represent 2D numeric array Analog waveforms registered by a multi-
correlated waveforms 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). are network visible because all of them can receive RPCs.
In this way, water is available for consumption, and the water Using a Client Port, the remote NCAP can invoke the op-
level never exceeds the tank capacity. A level transmitter mea- erations Get/SetHighThreshold and Get/SetLowThreshold,
sures the water level and two level switches provide two alarm provided by the HysteresisFunctionBlock object, in order to
signals: a high-level alarm if the water level reaches the top of get/set the hysteresis window, in which the water level can
the tank and a low-level alarm if the water level reaches the vary. It also can invoke the operation SetMode to switch the
bottom of the tank. The control strategy consists of a hysteresis system to manual mode, overriding the automatic control of
algorithm and a set of logical equations to handle alarm condi- the pump. Additionally, all field variables are transmitted to
tions. An operator station supervises the system remotely. the operator station by means of matched Publisher/Sub-
The water-supply system uses two NCAPs: a local NCAP scriber Ports on both NCAPs. This high-speed communica-
in the field and a remote NCAP in the operator room. The tion path allows the database and the HMI to be updated in
local NCAP acquires sensor signals, executes the water level real time.
control loop, and actuates the pump. The remote NCAP hosts Alternatively, the control strategy could consist of a PID
the system’s Human-Machine Interface (HMI) and logs data algorithm. That scenario would bring some changes to the sys-
to a database. tem: first, the pump actuator would become analog; second,
Figure 7(a) shows a mapping of the local NCAP function- the HysteresisFunctionBlock would be replaced by some kind
ality onto 1451.1 objects. Since all transducers hosted by the of “PIDFunctionBlock,” which would implement the PID al-
local NCAP are compliant with the 1451.2 Std., the WaterLev- gorithm and provide functions to get/set controller variables,
elTransducerBlock object is an instance of the Dot2 Transducer such as the set point and proportional/integral/derivative
Block class. Furthermore, it owns four Scalar Parameters, gains.
thus:
w the PumpScalarParameter that holds pump’s actuation Conclusions
values, This article is a brief tutorial for those who are interested in the
w the WaterLevelScalarParameter that retains samples from 1451.1 Std. All the main parts of the standard were covered:
the level transmitter, and the information model (which includes Blocks, Components,
w the pair of HLevelAlarmScalarParameter/LLevelAlarm- and Services), the data model (which is used by Parameters
ScalarParameter that catches high-/low-level alarms. to represent physical quantities), and the two communication
The control strategy is implemented by the Hysteresis- models (client/server and publish/subscribe). Finally, we
FunctionBlock object, which is a specialization of the Function showed how these parts work together in order to implement
Block class. the concept of NCAP, using an application example based on a
Figure 7(b) shows a mapping of the remote NCAP function- simple water-supply pump system.
ality onto 1451.1 objects. The remote NCAP has no Transducer Despite the vast set of functionalities provided by the
Blocks because it does not connect to any transducer. Instead, 1451.1 Std. and the advantages carried by standardization,
it implements two specialized Function Blocks: the LogFunc- there are no commercial NCAPs available on the market. We
tionBlock that records data from transducers into a database hope to make a commercial NCAP available by pursuing our
and the HMIFunctionBlock that provides functions to interact work on the 1451.1 Std.; by calling the community’s attention
with the operator. There are no Parameters associated with to its benefits; and by searching for new ways to improve it. We
these Blocks. are working on a service-oriented NCAP prototype that takes
Figure 7 also shows a valid schema for inter-NCAP com- advantage of two emergent technologies: Web Services and
munication. All Blocks and Parameters from both NCAPs Windows Communication Foundation [13].

Fig. 6. Water-supply pump system.

44 IEEE Instrumentation & Measurement Magazine April 2008

 Display,
actuators,
Sensor Input Processing Output signals,
control

Fig. 7. Mappings of NCAP functionality onto 1451.1 objects: (a) local NCAP; (b) remote NCAP.

References [8] K.B. Lee and E.Y. Song, “Object-oriented application framework
[1] IEEE Standard for a Smart Transducer Interface for Sensors and for IEEE 1451.1 Standard,” IEEE Trans. Instrum. Meas., vol. 54, (no.
Actuators—Network Capable Application Processor (NCAP) 4), pp. 1527–1533, Aug 2005.
Information Model, IEEE Std. 1451.1, 1999. [9] A. Stepanenko, K. Lee, R. Kochan, V. Kochan, A. Sachenko,
[2] Standard for Binary Floating-Point Arithmetic, IEEE Std. 754, 1985. “Development of a minimal IEEE 1451.1 model for microcontroller
[3] A. Birrel and B.J. Nelson, “Implementing remote procedure calls,” implementation,” IEEE Sensors Appl. Symp., Houston, Texas, USA,
ACM Trans. Comput. Syst., vol. 2, (no. 1), Feb 1984. Feb 2006.
[4] ISO/IEC Std. 11578-1996, “Remote Procedure Call (RPC) [10] K. Lee and E. Song, “A wireless environmental monitoring system
Specification”. based on the IEEE 1451.1 Standards,” Proc. IMTC 2006, Sorento,
[5] D.A. Chappell and R. Monson-Haefel, “Understanding the Italy, Apr 2006, pp. 1931–1936.
Messaging Paradigm”, Java Message Service, 1st Edition, [11] Web Services Activity Page from W3C (World Wide Web
Sebastopol, California, USA, O’Reilly & Associates, 2001, pp.1-16. Consortium) [Online] Available http://www.w3.org/2002/ws.
[6] IEEE Standard for a Smart Transducer Interface for Sensors and [12] V. Viegas, J.M. Dias Pereira, and P. Silva Girão, “Using a
Actuators—Transducer to Microprocessor Communication Protocols commercial framework to implement and enhance the IEEE
and Transducer Electronic Data Sheet (TEDS) Formats, IEEE Std. 1451.1 Standard,” Proc.IMTC 2005, Ottawa, Ontario, Canada,
1451.2, 1997. May 2005.
[7] ACE (ADAPTIVE Communication Environment) [Online] [13] WCF (Windows Communication Services) [Online] Available
Available http://www.cs.wustl.edu/~schmidt/ACE.html. http://wcf.netfx3.com.

April 2008 IEEE Instrumentation & Measurement Magazine 45

 Vítor Viegas received his de- gia of Instituto Politécnico de Setúbal, where he is, at present,
gree in Electrical and Computer a Coordinator Professor. In 1995, he received the M.Sc. degree
Engineering from the Instituto and in 1999 the Ph.D. degree in Electrical Engineering and
Superior Técnico of the Tech- Computer Science from IST. His main research interests are
nical University of Lisbon in included in the Instrumentation and Measurements areas.
1999, and he received the M.Sc.
degree from the same school in P.M.B. Silva Girão (M’00,
2003. He works as a teaching as- SM’01) received the Ph.D. de-
sistant at the Escola Superior de gree in electrical engineering
Tecnologia de Setúbal of Insti- from the Instituto Superior
tuto Politécnico de Setúbal. His Técnico of the Technical Uni-
main research activities concern versity of Lisbon (IST/UTL)
virtual, smart, and distributed instrumentation. in 1988. In 1975, he joined the
Department of Electrical Engi-
J. M. Dias Pereira (joseper@ neering at IST/UTL, first as a
est.ips.pt) (M’00–SM’04) re- Lecturer and, since 1988, as an
ceived his degree in Electrical Associate Professor. Presently
Engineering from the Instituto his main research interests are
Superior Técnico (IST) of the instrumentation, transducers, measurement techniques, and
Technical University of Lisbon digital data processing, particularly for biomedical, environ-
in 1982. He worked for Portu- mental, chemical, and civil applications. Metrology, quality,
gal Telecom for 8 yr in digital and electromagnetic compatibility are also areas of regular
switching and transmission activity, mainly as an auditor for the Portuguese Institute
systems. In 1992, he returned to for Quality. Dr. Girão is chairman of IMEKO TC19–Environ-
teaching as Assistant Professor mental Measurements and vice-president of the Portuguese
in Escola Superior de Tecnolo- Metrology Society.

46 IEEE Instrumentation & Measurement Magazine April 2008