TERM-PAPER

ELECTRICAL

Name:

Roll-No:

Reg. No:

Topic: SMART-TRANSDUCERS

Teacher: Lect. KIRANDEEP KAUR

D.O.S: 18/12/08
 TRANSDUCERS:

Introduction:
Recent advances in technology have led to the development of
sensors with embedded memory used to store
pertinent information related to the sensor such as make, model,
serial number and sensitivity. This data may be
automatically retrieved and utilized to set up the measurement
system. Also, a channel table can be generated that
gives correspondence between the signal conditioner channel and
the attached sensor. This serves to reduce or
eliminate bookkeeping errors associated with a manually generated
channel table. The channel table may also list
and display all pertinent sensor data, including position and
orientation on the test article .
The IEEE 1451.4 standard defines interface and communication
protocol for such sensors. The data contained in the
memory is commonly referred to as the Transducer Electronic
Datasheet or TEDS. Accelerometers with integrated
electronics (known as IEPE) that contain TEDS have become
commonplace in the market, with devices available
from a number of manufacturers. These sensors may be effectively
applied to test models; however, there is a
restriction that the cable run between the signal conditioner and the
sensor be limited to 400’ in order to be able to
properly read the TEDS. For applications such as weapons test or
vibration test on large structures, safety,
environment, test article size and other factors often require cable
runs in excess of 1000’ that have until now
precluded the use of TEDS equipped sensors.
COMMUNICATION DISTANCE LIMITATIONS OF TEDS
EEPROM
One-wire Electronically Erasable Programmable Read-Only
Memory (EEPROM) devices are utilized as the
memory for the TEDS. The Dallas Semiconductor DS2430A 256-
bit EEPROM is commonly embedded in IEPE
accelerometers for the TEDS memory and will be the device that
we refer to in our discussion for this paper.
Referring to , during normal operation, the signal conditioner is
connected to the accelerometer output to
measure analog data. Data is transferred serially to and from the
TEDS device via a protocol that requires a single
wire plus a return. For reading and writing data to the EEPROM,
the signal conditioner interface contains a TEDS
reader, which consists of a current source, a write switch and a
receiver. The current source acts to pull down the
line to the “open level” whenever the TEDS reader or the 1-wire
device does not short it. The length of the cable
run to the transducer is determined by how fast the current source
can charge the cable capacitance. The DS2430A
achieves specified logic levels with a 4mA current source.
The “short level” is the value that the line reaches when the TEDS
reader shorts it. The 1-wire device short level is
approximately 0.8V higher than the TEDS reader short level due to
the isolation diode D2 in series with the 1-wire device. This diode
is necessary to allow the 1-wire device to share the signal lines
with an IEPE transducer.The DS2430A, as with all of the Dallas 1-
wire devices, has four types of 1-wire signaling: The Reset and
Presence
pulses (as part of the reset sequence), Write 0, Write 1 and Read
data. The DS2430A must be initialized before
sending or receiving data. The initialization consists of a reset
pulse sent by the TEDS reader, followed by the
presence pulse returned by the 1-wire device. After the presence
pulse is received, data may be communicated
between the TEDS reader and the DS2430A.
Data communication takes place by adhering to strict timing
protocols. The timing diagrams for the read and write
timing slots are shown in Figures 2 and 3. Communication
between the TEDS reader and the 1-wire device for a
Read or Write operation is started in an identical manner by
initiating a start pulse via TEDS reader switch SW1.
For a Write 0 (Figure 2), the pulse length must be a minimum of
60μsec. For a Write 1, the pulse must be a
maximum of 15μsec. When SW1 opens, the line is driven to the
open level (-5V) by the current source in the TEDS
reader. In all cases, the data must be maintained to desired logic
levels between 15μsec and 60μsec from the
beginning of the start pulse.
During a read timing slot SW1 is driven to produce a start pulse
that is a minimum of 1μsec in duration.
If the 1-wire device wants to deliver logic 1, it does nothing,
allowing the line to be driven to the open level by the
current source. The line must reach the detection threshold within
15μsec from the beginning of the start pulse or the
TEDS reader may erroneously detect logic 0. To deliver logic 0,
the 1-wire device must hold the line down with
SW2 for a minimum of 15μsec after the beginning of the start
pulse. When SW2 opens, the line is driven back to
the open level by the current source.The ability of the interface to
adhere to the timing slot restrictions will be limited by the time it
takes the current
source to drive the line high in the presence of any cable
capacitance. The cable capacitance, Cc, that can be
supported given the charging time, TC, is given by:
Cc = Tc I /VL (1)
Where I is the charging current of 4mA. Assuming a start pulse of
5μsec, then the current source has TC of 10μsec
to drive the line to a valid logic 1 level before the DS2430A begins
sampling. VL equals VIH of the 1-wire device
(2.2V) plus the voltage drop of the blocking diode (0.8V) or 3V.
The evaluation of Equation (1) with Tc = 10μsec,
I = 4mA and VL = 3V predicts a maximum cable capacitance of
0.013μF or 444 feet of 30 pF/ft coaxial cable.
Ccmax = (10μsec)(4mA)/(3V) = 0.013μF (2)

LONG DISTANCE TEDS

Long Distance TEDS (LDTEDS) communication requires that new
methods of detection be utilized by the TEDS
reader in the signal conditioner in order to differentiate whether the
1-wire device in the transducer is sending a “1”
or a “0”. In the discussion above, it is clear that the 4mA current
source limits the amount of cable capacitance that is permitted for
error free communication. Unfortunately, the only way to send a
pulse over a long cable without
distorting its width is to provide a higher drive current. We can
provide this higher drive current when the TEDS
reader must signal to the 1-wire device, but when receiving a
signal from the 1-wire device, we must limit the charging current
to 4mA to be compliant with DS2430A specifications.
 To make long distance communications possible, an analog-
to-digital converter (ADC) and a digital signal processor
(DSP) are introduced to sample the communications interface as
shown in Figure 6. We use an ADC to digitize the
waveform, and DSP techniques to analyze the data. Referring to
Figure 7, after the TEDS reader discharges the
cable to the short level, we compute the slope and Y intercept of
the voltage versus time line as the cable
capacitance charges back to the open level. We use the slope and
intercept to compute the 1-wire release time where
the line crosses the 1-wire short level. If the release time is less
than 15μsec, then a 1 is read from the 1-wire device
and if it is greater than 15μsec, then a 0 is read.
To improve noise immunity, we calculate a detection threshold that
is unique to each 1-wire device by evaluating
the release times associated with the 64-bit ROM in the 1-wire
device. The ROM consists of a device ID, device
serial number and CRC that contains a mix of 1’s and 0’s. From
the data we set the detection threshold to the
midpoint of the computed minimum and maximum release times.
Subsequently, we evaluate the release time of
each bit against the computed detection threshold to determine if
the 1-wire data is a 0 or 1.

In order to write data to the 1-wire device over long cable runs, we
can provide a current source boost to improve the wire charging
time. In our design, the boosted current level is 18mA, which is
more than sufficient to drive 1500
feet of 30pF/ft cable to the required logic levels. Assuming that the
detection threshold in the 1-wire device is -
2.2V, then the Write 1 trailing edge must reach approximately -3V
within 15μsec of the leading edge of the pulse.
Examining Figure 8, we see that this is the case, so there will be
no problem writing data to a 1-wire device over a1500 feet cable.

SUMMARY
In this paper we demonstrate the fundamental communication
distance limitations of conventional IEEE 1451.4
TEDS hardware. We propose a model for the limitation and
compute a maximum communication distance of 444
feet. We introduce Long Distance TEDS (LDTEDS) as a method
of extending communication distances for TEDS
sensors. The LDTEDS circuitry uses an analog to digital converter
to digitize the 1-wire read waveforms and
utilizes a digital signal processor to determine if the 1-wire device
transmits a 0 or 1. We propose a current source
boost circuit to enable writing of data to the 1-wire device at long
distance. Our circuit can communicate with
TEDS sensors at distances out to 1500 feet.
LDTEDS is commercially available in two Precision Filters
products. The 28334A is a 4-channel dual mode
charge/IEPE amplifier and the 28316B is a 16-channel IEPE
amplifier/filter. Both products are designed for the company’s
28000 Signal Conditioning System.

ACKNOWLEDGEMENTS
The authors wish to acknowledge Mr. Alan Szary for his
contributions toward the development of LDTEDS.
Finney, S. H., 2004, “Investigation of Precision Filters Hardware
Interface to TEDS Sensors”, Precision Filters, Inc.
Engineering Report Number 228.
IEEE Std 1451.4, 2004, “Standard for A Smart Transducer
Interface for Sensors and Actuators—Mixed-Mode
Communication Protocols and Transducer Electronic Data Sheet
(TEDS) Formats”, The Institute of Electrical and
Electronics Engineers, Inc., 3 Park Avenue, New York, NY
10016-5997, USA December 14, 2004.
Dallas Semiconductor, 1999, “DS2430A 256-Bit 1-Wire EEPROM
Data Sheet”
Precision Filters, Inc., 2005, “28316B 16-Channel TEDS, IEPE
Accelerometer Conditioner Data Sheet”
Precision Filters, Inc., 2005, “28334 Quad Dual Mode
Charge/IEPE Conditioner Data Sheet”

A Standardized Smart Transducer Interface

Abstract
In December 2000 the Object Management Group
(OMG) called for a proposal of a smart transducer
interface. In response a new standard has been proposed
that comprises a time-triggered transport service
within the distributed smart transducer subsystem
and a well-defined interface to a CORBA environment.
This smart transducer standard has been adopted
by the OMG in January 2002. The smart transducer
interface and the time-triggered transport service
have been implemented in the time-triggered fieldbus
protocol TTP/A.
This paper examines the strengths and weaknesses
of the smart transducer interface and
presents two case studies. The first case study describes
a demonstrator with a robot arm that is instrumented
by smart transducers and a TTP/A fieldbus.
The second case study is an autonomous mobile
robot instrumented by a TTP/A cluster that orientates
itself via a set of heterogenous sensors and
decides, based on this sensor data, which way to
go.
1 Introduction
The design of the network interface for a smart
transducer is of great importance. Transducers can
come in a great variety with different capabilities
from different vendors. A smart transducer interface
must thus be very generic to support all present and
future types of transducers. However, it must provide
some standard functionalities to transmit data
in a temporal deterministic manner in a standard
data format, provide means for fault tolerance, and
enable a smooth integration into a transducer network
and its application.
A smart transducer interface should conform to
a world-wide standard. Such a standard for a realtime
communication network has been long sought,
but efforts to find one agreed standard have been
hampered by vendors, which were reluctant to support
such a single common standard in fear of losing
some of their competitive advantages [1]. Hence,
several different fieldbus solutions have been developed
and promoted. Some of these existing
solutions have been combined and standardized.
In 1994, the two large fieldbus groups ISP (Interoperable
Systems Project supported by Fisher-
Rosemount, Siemens, Yokogawa, and others) and
theWorldFIP (supported by Honeywell, Bailey, and
others) joined to form the Fieldbus Foundation (FF).
It is the stated objective of the FF to develop a single
interoperable fieldbus standard in cooperation
with the International Electrotechnical Commission
(IEC) and the Instrumentation Society of America
IEC committees met jointly to make the development
of an international standard possible. ISA
SP50 was the same committee that introduced the
4-20 mA standard back in the 1970s.
Meanwhile, other standards for smart transducers
were developed. The IEEE 1451.2 [3] standard
deals with the specification of interfaces for smart
transducers. An idea proposed by this standard is
the specification of electronic data sheets to describe
the hardware interface and communication protocols
of the smart transducer interface model [4].
In December 2000 the Object Management
Group (OMG) called for a proposal of a smart transducer
interface (STI). In response a new standard
has been proposed that comprises a time-triggered
transport service within the distributed smart transducer
subsystem and a well-defined interface to a
CORBA (Common Object Request Broker Architecture)
environment. The key feature of the STI is
the concept of an Interface File System (IFS) that
contains all relevant transducer data. This IFS allows
different views of a system, namely a real-time
service view, a diagnostic and management view,
and a configuration and planning view. The interface
concept encompasses a communication model
for transparent time-triggered communication. This
STI standard has been adopted by the OMG in January
2002.
It is the objective of this paper to examine the
strengths and weaknesses of the STI standard and
to present two case studies showing the capabilities
of the smart transducer interface.
The rest of the paper is organized as follows:
The following section explains the conceptual
model and architecture of the STI. Section 3 introduces
the properties of the IFS. Section 4 depicts the
proposed time-triggered fieldbus protocol. In section
5 we will describe two case studies, that implemented
smart transducer networks based on the STI.
Section 6 investigates on the strengths and weaknesses
of the STI standard. The paper is concluded
in section 7.
2 Conceptual Model
This section will introduce the conceptual model of
the OMG smart transducers interface [5].
On a abstract level, the purpose of a real-time
smart transducer interface is the timely exchange of
“observations” of real-time entities between the engaged
subsystems across the provided interfaces. A
real-time entity is a state variable of interest that has
a name and a value at a particular instant. An observation
[6] is thus an atomic triple:
<name, observation instant, value>,
where name is an element of the common name
space of real-time entities, the observation instant
is a point in the “time space” and value is an element
of the chosen value domain. An observation
expresses that the referenced real-time entity possessed
the stated value at the indicated instant.
A smart transducer (ST) system consists of several
clusters with transducer nodes connected to a
bus. Each cluster is connected to a CORBA gateway
via a master node. One CORBA gateway can interface
up to 250 clusters. The master of each cluster
is connected to the CORBA gateway through a
real-time communication network, which provides
a synchronized time to each master. Each cluster
can contain up to 250 STs that communicate via
a cluster-wide broadcast communication channel.
There may be redundant shadow masters to support
fault tolerance. One active master controls the communication
within a cluster (in the following sections
the term master refers to the active master unless
stated otherwise). Since smart transducers are
controlled by the master, they are called slave nodes.
Figure 1 depicts an example for such a smart transducer
system.
Access to the smart transducer data is achieved by
assigning three different interfaces to each ST node:
DM interface: This is a diagnostic and management
interface. It establishes a connection to
a particular ST node and allows reading or
modifying of specific IFS records. Most sensors
need parameterization and calibration at
startup and continuously collect diagnostic information
to support the maintenance activities.
For example a remote maintenance console
can request diagnostic information from a
certain sensor.
CP interface: The configuration and planning allows
the integration and setup of newly connected
nodes. It is used to generate the “glue”
in the network that enables the components of
the network to interact in the indented function.
Usually, the CP interface is not time-critical.
RS interface: The real-time service interface performs
a periodic communication with predictable
timing behavior among the ST nodes.
Communicated data is usually data from sensors
and for actuators. This view employs
sensors for producing periodic observations of
real-time entities in the environment. This
view supports the normal operation of the sensor.
For example, a temperature sensor periodically
sends the observed and locally preprocessed
sensor value to the temporal firewall of
the master. Since in TTP/A the time interval
between sensing the environment and presenting
the sensor value at the temporal firewall [7]
of the master is known a priori it is possible to
perform a feed forward state estimation of the
sensor value at the sensor node in such a way,
that the delivered sensor value is a good estimate
of the real-time entity’s actual state at the
point in time of delivery.
Although all transducer nodes are built as smart
transducers and contain a physical sensor or actuator,
a microcontroller, and a network interface, the
hardware requirements for the ST interface are very
flexible. The STI supports low-cost implementations
of smart transducers, by allowing optional implementation
of standard features. Thus, it is possible
to fit a minimum STI implementation on an embedded
microcontroller with 2k flash memory and
64 bytes of RAM memory [8].
3 Interface File System
The information transfer between a smart transducer
and its client is achieved by sharing information
that is contained in an internal interface file system
(IFS), which is encapsulated in each smart transducer.
A time-triggered sensor bus will perform a periodical
time-triggered communication to copy data
from the IFS to the fieldbus and write received data
into the IFS. Thus, the IFS is the source and sink for
all communication activities. Furthermore, the IFS
acts as a temporal firewall that decouples the local
transducer application from the communication activities.
It is the task of the communication protocol to
keep consistency among the local copies of the IFS
data elements. A predefined communication schedule
defines time, origin, and destination of each protocol
communication. The instants of updates are
specified a priori and known by the communicants.
Thus, the IFS acts as a temporally specified interface
that decouples the local transducer application
from the communication task.
Each transducer can contain up to 64 files in its
IFS. An IFS file is an index sequential array of up
to 256 records. A record has a fixed length of four
bytes (32 bits). An IFS record is the smallest addressable
unit within a smart transducer system. Every
record of an IFS file has a unique hierarchical
3
Fig. 2: Logical Network Structure
address (which also serves as the global name of the
record) consisting of the concatenation of the cluster
name, the logical name, the file name and the record
name.
The IFS provides a unique address scheme for
transducer data, configuration data, self-describing
information and internal state reports of a smart
transducer [9].
Besides access via the master node, the local applications
in the smart transducer nodes are also able
to execute a clusterwide application by communicating
directly with each other. Figure 2 depicts the
network view for such a clusterwide application.
As depicted in Figure 3, the IFS of each smart
transducer node can be accessed via the RS interface,
the DM interface and the CP interface for different
purposes. All three interfaces are mapped
onto the fieldbus communication protocol, but with
different semantics regarding timing and data protection.
4 Fieldbus Communication Protocol
A time-triggered transport service following the
specification of the STI has been implemented in the
time-triggered fieldbus protocol TTP/A.
The bus allocation is done by a Time Division
Multiple Access (TDMA) scheme. Communication
is organized into rounds consisting of several
TDMA slots. A slot is the unit for transmission of
one byte of data. Data bytes are transmitted in a
standard UART format. Each communication round
is started by the master with a so-called fireworks
byte. The fireworks byte defines the type of the
round.
The protocol supports eight different firework
bytes encoded in a message of one byte using a redundant
bit code [10] supporting error detection.
Generally, there are two types of rounds:
Multipartner round: This round consists of a configuration
dependent number of slots and an
assigned sender node for each slot. The configuration
of a round is defined in a datastructure
called “RODL” (ROund Descriptor List).
The RODL defines which node transmits in a
certain slot, the operation in each individual
slot, and the receiving nodes of a slot. RODLs
must be configured in the slave nodes prior
to the execution of the corresponding multipartner
round. An example for a multipartner
round is depicted in Figure 4.
Master/slave round: A master/slave round is a
special round with a fixed layout that establishes
a connection between the master and a
particular slave for accessing data of the node’s
IFS, e. g. the RODL information. In a master/
slave round the master addresses a data
4
record in the hierarchical IFS address and specifies
an action like reading, writing or executing
on that record.
The master/slave rounds establish the DM and the
CP interface to the transducer nodes. The RS interface
is provided by periodical multipartner rounds.
Master/slave rounds are scheduled periodically between
multipartner rounds as depicted in Figure 5 in
order to enable maintenance and monitoring activities
during system operation without a probe effect.
5 Case Study Implementations
5.1 Robot Arm
Fig. 6: Robot Arm
As a demonstrator for the STI we built a system
with a robot arm [11]. At the application level a human
operator can control a prosthetic arm mounted
on top of a linear thrust unit (See Figure 6). Simplicity
of control for the user is established by the
presence of intelligence in the demonstrator. Smart
sensors yield information about the environmental
conditions allowing avoidance of operating errors
and obtaining precise control. Pressure sensors are
present for determining the required grip force to
grasp an object. No intervention of the human operator
is needed to avoid slipping of an object. Motor
actuator nodes implement trapezoid excitation for
handling of inertia. The demonstrator is equipped
with an angle sensor to allow limiting the opening
of the elbow.
The demonstrator was also intended to investigate
partitioning of nodes into distinct clusters. The resulting
intercluster communication was required to
preserve temporal predictability and capabilities for
monitoring, maintenance and configuration.
The demonstrator consists of two clusters (See
Figure 7). The first cluster contains the nodes for
controlling the motors of the linear thrust units, the
elbow and the wrist. The nodes for retrieving the
current angle of the elbow and the joystick commands
are also placed in this cluster. A shadow master
can take over control in case the primary master
fails. Both masters are connected to the intercluster
bus and act as intermediate systems. In addition to
their TTP/A master role, they are slaves of a timetriggered
backbone bus. The second cluster contains
a node behaving as an interface system for integrating
the prosthetic hand into the demonstrator. Two
nodes equipped with pressure sensors obtain measurements
for grasping objects intelligently.
5.2 Autonomous Mobile Robot:
Another implementation of the STI is shown by a model car, that
acts as an autonomous robot with sensory inputs [12]. Seventeen
nodes were used for building this mobile robot (“smart car”). Some
of these nodes are implemented on very small MCUs to
demonstrate the possibility of cheap slaves. Other nodes should
demonstrate the possibility of complex features like plug & play or
reconfiguration. The model comprises a smart car equipped with a
suit of pivoted distance sensors, an electric drive and a steering
unit. Distance sensors, servo motors for sensor pivoting, driving
and steering units are all separate smart transducer nodes. Each
node is implemented on a low-cost microcontroller and equipped
with an STI. The STI supports the integration of smart transducer
nodes with a predictable timing behavior. It is possible to add extra
“light” nodes to the car during operation. different operation
modes are defined. The STI standard supports up to 6 user-
definable independent communication modes, which support
applications running different modes. As long as no obstacles are
detected within the sensors’ range the car operates in “rabbit
mode”. In this mode the car drives straight forward at full speed
and two infrared sensors are aimed slightly outward the driving
direction. The main detection of obstacles relies on two ultrasonic
sensors. These are capable to report obstacles straight ahead of the
car within a range of about 5m. In case an obstacle is detected the
car switches to “turtle mode”. In this mode the car uses a
communication schedule where all infrared sensors and pivot
servos are serviced. The distance sensors are swivelled around by
servo motors so that they are able to scan the area in front of the
robot. The sensors generate a value that corresponds to the distance
of the object they are aimed at. The data stream provided by the
distance sensors is taken over by a data processing node that fuses
the perceptions from the distance sensors and the directions they
are aimed at with a model of the robot environment. In this model
the shapes of obstacles are stored and assigned with a probability
value, that decreases with the progression of time and increases
when the object is re-scanned. From this data a navigation node
calculates the speed and the direction to provide this information to
the speed and steering nodes.

6. Discussion:
One requirement stated in the call for proposal by the OMG was
real-time capability of the smart transducer interface. The STI
supports hard real-time communication by introducing a time-
triggered communication scheme, that is a priori specified before
the RS interface of the system is used. Generally, time-triggered
systems require an increased effort in the design phase of the
system, but provide an easier verification of the temporal
correctness [14]. Since time-triggered systems are designed
according to the principle of resource adequacy [15], it is
guaranteed that sufficient computing resources are available to
handle the speci-

6.
fied peak load scenario. On the other hand, timetriggered
systems are often blamed for their bad flexibility. The STI
overcomes this limitation by introducing means to configure the
interaction of the components via the CP interface. The RS
interface provides composability, guaranteed timeliness, and hides
components’ internals. The DM and CP interfaces involve
inherently event-triggered activities, which require an
eventtriggered communication service. These interfaces cannot
invalidate the temporal behavior of the RS interface and support
full access to component internals – as required by a maintenance
engineer. The specification of interfaces should be complete and of
minimal cognitive complexity. Cognitive complexity can be
minimized by restricting interactions via interfaces and by
providing access restrictions. The kind of information that must be
available via an interface depends on the purpose of the particular
interface. For example, a properly designed operational interface
hides component internals, thereby allowing a component to form
a meaningful abstraction. The corresponding operational interface
specification stipulated during architecture design should
incorporate a precise specification of a component’s inputs and
outputs in both the temporal and value domain. A maintenance
engineer on the other hand, might require access to intermediate
computational results for locating the origin of an incorrect system
behavior. The smart transducer interface (STI) standard meets the
requirement for complete interfaces of minimal cognitive
complexity by introducing three different types of interfaces of a
component. The separation into RS, DM and CP interface is done
according to the interface purpose, the necessary level of visibility
of component internal information, and the type of the temporal
interaction patterns. Such a separation minimizes complexity in
contrast to a universal interface incorporating support for all
possible interactions. The STI standard also specifies the provision
of the three interfaces through a CORBA server. However,
currently there is no CORBA architecture for effectively
supporting the temporal requirements to establish the RS interface.
Current priority-based approaches like Real-time CORBA [16]
require complete knowledge about all other service requests and
their corresponding priority values in the whole CORBA network.
However, the availability of a global notion of time allows to
record the instant of the acquisition of a real-time entity’s state in
each observation.

7. Conclusion
We implemented two case studies of the STI. The first case study
comprises a demonstrator with a robot arm that is instrumented by
a smart transducer network partitioned into two clusters. The
second case study is an autonomous mobile robot, that shows the
integration of new nodes and efficient communication despite of
static communication schedules. The results show, that the STI
standard is an interesting option for various sensor network
applications. The STI provides many features that are required by a
fieldbus applications for automotive or automation industries.
Supported features are the real-time capability, the encapsulation
of the node’s internals, and a universal address space with the
interface file system. The STI can be implemented on low-cost
Commercial-off-the-Shelf (COTS) hardware and supports various
bus media types.

8. Acknowledgments
This work was supported in part by the Austrian Ministry of
Science, project TTSB and by the European IST project DSoS
under contract No IST-1999- 11585.

Smart Transducers – Depth Speed

Temperature Connect to your NMEA
displays with these digital transducers
The Actisense™ Active Depth/Speed/ Temperature
transducer is the best solution for supplying NMEA
Depth, Speed/Log and Temperature to an NMEA 0183
compatible chart plotter, radar, or on board
PC/Laptop. Our industry proven depth sounder
algorithm has the best-in-class seabed tracking.
Couple that to the processing electronics only a
centimetre from the depth transducer, and the
performance obtained is truly the best possible,
tracking the seabed down to 0.3m (1 foot). 100W
peak depth power enables a maximum depth range
of 100m (330 feet) under optimum conditions. The
data interface is configured as an NMEA 0183
interface, but can operate as a fully bidirectional
RS485 interface for
customised applications, such as on board multiple
depth sounder networks. 235 kHz depth transducer
frequency for
enhanced interference rejection from surface noise
and other transducers nearby. A built-in Log
transducer and Temperature thermistor (certain
models), allow additional
data to be provided over the NMEA network, giving a
cable saving when those extra measurements are
required.
Easy reprogramming is possible using free software,
available on the Actisense website, and the Actisens
RS485 PC interface. The transducer’s software may
be updated as many times as required with the very
latest software enhancements, or special purpose
software such as the
fish-finder/hydrograph software upgrade. NMEA
display software for a Windows PC, will also be
available from the
Actisens website to display the fish
finder/hydrograph data from specific upgraded NMEA
Active DST transducers.

The interfacing of smart transducers to a wireless medium is an

attractive solution for reconfigurable networks but this has not
been explored extensively for small-span networks using existing
wireless technology. Wireless sensors today are equipped with RF
capability at the physical layer but do not lend themselves to
cooperative networking. Smart transducer interfaces have recently
been standardized to enable the interoperability of smart
transducers with a variety of instruments, microprocessor based
systems, fieldbus and control networks and using this interface
with an existing wireless networking technology provides a quick,
cost-effective, ubiquitous and simple solution for reconfigurable,
cooperative wireless smart transducer networks.
2
In order to enable the smart transducer interface to operate with a
wireless networking technology we propose a “network
infrastructure” in this thesis and investigate the definition and
design of a software model for such an infrastructure. The network
communication models standardized by the IEEE 1451 and the
different wireless alternatives that may be adopted for autonomous
smart transducer networks are examined and evaluated. The
Bluetooth wireless technology is chosen for the wireless interface
and the OBEX Session protocol is used for network
communication between the smart transducers in a client-server
network architecture. The software model for the network
communication is described via behavioral VHDL constructs and
simulation outputs corresponding to the network operation are
obtained.
3
industry defines all seven layers of the OSI model and is different
on account of its peerto-
peer architecture. Profibus, HART, Topaz, ARCNet are
examples of other protocols
that are popular for factory automation applications. The wide
variety of existing
networking protocols has prompted industry to migrate towards an
open standard that can
offer “plug-and-play” capability, such as the Fieldbus. Fieldbus
refers to a non22
proprietary digital two-way communication standard that defines
application, data link,
and physical layer services of the OSI model for the process
automation industry. The
slow standardization of the Fieldbus and the lack of semiconductor
products in the
market to implement the sensor nodes have retarded the initial
excitement for this new
standard [FRANK00].
Office and Building Automation has been mainly implemented
with the BACnet protocol
used for energy management in smart buildings and is being
supported by protocols for
meter reading, security system, and self-diagnostics that are not yet
standardized. Home
Automation is migrating from the X-10 protocol previously used
for lamp and appliance
controls towards the Smart House Application Language protocol.
The Consumer
Electronics Bus (CEBus) and LonTalk are other contenders for
building automation
[FRANK00].
Interfacing transducers to the numerous existing control networks
with support for an
extensive set of communication protocols requires significant
effort and expense from
transducer manufacturers [RNJ00]. Transducer manufacturers and
system integrators are
required to redesign the transducer interfaces for each type of
multivendor network. This
redesign process is expensive, time consuming and prevents
interoperability of sensors
due to proprietary or unique interfaces.
23
2.4 IEEE 1451 Smart Transducer Interface for Sensors and
Actuators
Recent industry efforts towards interoperability in a wide range of
applications have
attempted to focus on the definition, functionality, and
communication protocol standards
for smart transducers. The IEEE and the NIST have defined the
IEEE 1451 set of
standards for a Smart Transducer Interface for Sensors and
Actuators in an effort to
overcome the incompatibility issues that arise while interfacing
smart transducers to
instruments, microprocessor-based systems, fieldbus and control
networks.
The objective of these standards is to define an architecture that
allows transducers to
connect into any live distributed control network in a true “plug-
and-play” fashion, such
that automatic system identification and configuration is facilitated
[LEE_K00]. The
IEEE Working Group for the standards has attempted to achieve
this by specifying a
network independent object model for interfacing smart
transducers to any target network
and descriptive datasheets embedded within smart transducers for
self-identification of
each device. As a result, the same transducers can be used on
multiple control networks
and the selection of a control network for measurement, and
control application is no
longer dependent on transducer compatibility constraints. This
would also encourage
transducer application developers to shift their focus to adding
value and innovation to
their applications rather than developing interfaces for different
networks.
Smart transducers (either smart sensors or actuators) typically
follow a signal chain
composed of a raw transducer element, signal conditioning block,
signal conversion
24
block, a microprocessor block, and a communication transceiver
[RNJ00]. The core of
the IEEE 1451 set of standards attempts to provide a layer of
abstraction between the
microprocessor and the signal conversion blocks, as well as the
communication
transceiver and the field network to provide network independence
to the smart
transducers. Thus, the standards provide a means to achieve
transducers-to-network
interchangeability as well as transducer-to-networks
interoperability [LEE_K00].
The IEEE 1451 family of standards is comprised of four
independent standards, 1451.1,
1451.2, P1451.3 and P1451.4, the latter two still waiting approval
from the Standards
Committee. The standards may be used either separately or
together as part of a complete
IEEE 1451 solution [CAN99].
IEEE 1451.1
Network Information Model
Signal Conditioning
Signal Conversion
Field Network
Commands Data
IEEE 1451.2
Smart Transducer Interface Module
Microprocessor
Communication Transceiver
Raw Transducer Element
Fig. 2.1 The IEEE 1451 Core Protocols [RNJ00]
25
The specifications are defined in such a manner that each higher
numbered specification
is completely contained within the confines of a lower numbered
specification. This
provides tight encapsulation of the hardware details at each level,
similar to the data
hiding concepts in object-oriented programming or protocol
layering definitions in
networking.
2.4.1 The 1451.1-1999 Standard for a Smart Transducer
Interface for Sensors and
Actuators – Network Capable Application Processor (NCAP)
Information Model
The IEEE 1451.1 standard defines a network independent
Common Object Model to
enable the interfacing of smart transducers to any network
[1451STD99]. Standardized
access to a physical transducer is possible by a programmable
interface that may be
provided by transducer manufacturers or network vendors.
The 1451.1 specification provides the object-oriented definition of
a Network Capable
Application Processor (NCAP) that encapsulates the details of the
transducer hardware
implementation. It also provides the definition of application-level
access to network
resources and the framework for application access to transducer
hardware.
The IEEE 1451.1 architecture defines three types of models – an
object model for the
software components of the IEEE 1451 system, a data model for
the information
communicated across the specified object interfaces, and a pair of
network
communication models.
26
The networked smart transducer model is described in the
specification through two
views, the physical and logical views.
Network Hardware
Network Protocol
Network Transducer Interface
(IEEE 1451.2)
Microprocessor Hardware
Operating System Firmware
Server Object Dispatch Ports
Application Software:
Function Blocks
Components
Services
NCAP Block
Transducer Blocks
Transducer Firmware
I/O Interface Hardware
Logical Interfaces
Logical Blocks
Fig. 2.2 Networked Smart Transducer Model [1451STD99]
The physical view of the system identifies the actual components
present in the system,
viz. the network hardware, I/O interface hardware, microprocessor
hardware, transducers
and the communication network. The logical view of the system
can be a view of the
logical components or the logical interfaces of the system. The
application software on
the NCAP, operating system firmware, network protocol, etc are
logical components and
may be grouped as application and support components. The
logical interfaces defined by
this view are the network abstraction interface, transducer
abstraction interface, and the
27
logical interface to NCAP support between the operating system
firmware and the
microprocessor hardware [1451STD99].
The information model is represented as a set of object classes,
attributes, methods and
behavior that provide an abstract view of device characteristics in
object-oriented terms
[LEE_K96]. The card-cage paradigm that is commonly used to
describe plug-in I/O
functionality in motherboards is used here to describe the different
functionality that may
be used in the NCAP model.
Logical
Backplane
Network
Transducer
Independent
InterfacPhysical e
Block Network
Block
Application-specific
Function Blocks
Transducer Block
Transducers
Network Neutral Interface
Fig. 2.3 The IEEE 1451.1 Card Cage Object Model [FRANK00]
The blocks that may be implemented in an IEEE 1451.1 design
include a Physical Block,
one or more Transducer, Function, and Network Blocks. The
Physical Block provides the
backplane for the card-cage structure and contains the logical
hardware and software
28
resources in the model. The Transducer Blocks abstract the
capabilities of each
transducer that may be connected to an NCAP, and are primarily
used in the
configuration phase. The Function Blocks provide a skeletal area
for application-specific
data and methods that may be plugged in whenever necessary. The
Network Blocks are
used to encapsulate all network communication operations from
the rest of the NCAP
functionality through a network neutral interface. The Network
Blocks are based on the
principles of Remote Procedure Calls (RPC) commonly used in
distributed systems
[LEE_K96]. The interfaces that are exposed by the IEEE 1451.1
Model are the interface
to the transducer modules and that
Transducers
DEPTH 250FT