See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/273886898

An IEEE 1451.0-based Platform-Independent TEDS Creator using Open Source

Software Components

Article · March 2015

DOI: 10.11648/j.ijssn.20150301.11

CITATIONS READS

3 726

2 authors:

Paul Celicourt Michael Piasecki

Institut National de la Recherche Scientifique City College of New York
30 PUBLICATIONS 123 CITATIONS 118 PUBLICATIONS 922 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Paul Celicourt on 23 March 2015.

The user has requested enhancement of the downloaded file.

International Journal of Sensors and Sensor Networks
2015; 3(1): 1-11
Published online March 19, 2015 (http://www.sciencepublishinggroup.com/j/ijssn)
doi: 10.11648/j.ijssn.20150301.11

An IEEE 1451.0-based Platform-Independent TEDS Creator

using Open Source Software Components
Paul Celicourt, Michael Piasecki
Civil Engineering Department, The City College of New York, New York, USA

Email address:
pcelico00@citymail.cuny.edu (P. Celicourt), mpiasecki@ccny.cuny.edu (M. Piasecki)

To cite this article:

Paul Celicourt, Michael Piasecki. An IEEE 1451.0-based Platform-Independent TEDS Creator using Open Source Software Components.
International Journal of Sensors and Sensor Networks. Vol. 3, No. 1, 2015, pp. 1-11. doi: 10.11648/j.ijssn.20150301.11

Abstract: This paper introduces a Graphical User Interface supported and platform-independent application to generate a
Transducer Electronic Data Sheet (TEDS) based on the IEEE 1451.0 standard using Python programming language. Compared
to other TEDS application development efforts, this application provides a help system that improves the usability as it requires
little familiarity with the IEEE 1451 standard. It is built on the Hierarchical Model-View-Controller software design architecture
to improve reusability and modularity, it is platform agnostic, light-weight and easy to install, it produces both binary and
Text-based TEDS, supports a large array of physical units used in the hydrology field and also incorporates sensor data
management provision. We have used the Consortium of Universities for the Advancement of Hydrologic Sciences, Inc.’s
Observations Data Model (CUAHSI ODM) as a test case to demonstrate how backend demands on data management can be
incorporated in front end applications such as the TEDS. We have tested the results of our application with examples provided in
the IEEE 1451.0 documentation, and both results show agreement.
Keywords: IEEE 1451, Transducer Electronic Data Sheet, CUAHSI’s Observations Data Model,
Automatic Data Management, Python, Low-Cost Sensor Network

1. Introduction
Implementing a sensor network requires, in most cases, the While offering substantial benefits, implementation of the
use of proprietary protocols and programming languages to IEEE 1451 standards, more importantly the TEDS for
configure sensors and loggers. When using different sensors traditional sensors and sensor platforms, remains a tedious
platforms the configuration task becomes more complex due task especially for practitioners with no or little background in
to the need of having to learn different proprietary data computer programming. Hence, the development of an
formats and protocols which constitute a bottleneck for the application that incorporates an intuitive Graphical User
expansion of sensor networks [1]. In response to this rising Interface (GUI) to generate the TEDS represents a critical step
complexity the Institute of Electrical and Electronics to both reduce work load and also to avoid mistakes as manual
Engineers (IEEE) have sponsored the development of the compilation has shown to be tedious and error prone [1, 4, 11,
IEEE 1451 standard [2, 25, 46] to introduce a common 12, 45, 55-57]. Multiple mistakes in manually assembling the
standard. This standard is a family of eight (8) (sub)standards, TEDS in addition to lack of knowledge of the IEEE 1451
as of the date of this writing, that provides the common standard have been reported in Rana et al. [11] where, for
interface and enabling technology for the connectivity of example, instead of providing the “Design operational upper
transducers to microprocessors, control and field networks, and lower measurement limits” for the temperature sensor
and data acquisition and instrumentation systems in a they use in their setup; they provide the operating temperature
plug-and-play fashion [2]. The standard puts forth the concept range for the Arduino board itself.
of a Transducer Electronic Data Sheet (TEDS) which plays the TEDS generators have been developed before; see [3, 5-10,
role of an identification card attached to smart transducers 44, 61-62]. A key aspect to evaluate most of these TEDS
enabling transducers self-identification, self-description, generators is their level of convenience vis-à-vis the user’s
self-diagnosis, self-calibration, and plug-and-play experience or expertise with this standard. In other words,
functionality. these applications require the users to know the intricate
2 Paul Celicourt and Michael Piasecki: An IEEE 1451.0-based Platform-Independent TEDS Creator using Open
Source Software Components

details and technical terms of the standard. Acquiring detailed SensorML [65-67]. None of these applications have an
knowledge of the standard however is a time consuming and interface or mechanism that would allow integration of
onerous task for one because it is an expansive standard, for controlled vocabularies such as the CUAHSI ODM [29]
another because it is filled with technical jargon. For example, Physical Units controlled vocabularies, which we seek to use
the TEDS generator in [6] requires the users to understand in the present application to improve on and ease the burden of
how physical units are represented in the TEDS and they have inserting correct units. Another important aspect that has been
to insert the proper and correct forms themselves, which has overlooked and omitted in TEDS applications is the fact that
shown to be a likely source of error in TEDS creation; see the IEEE 1451 is flexible enough to allow practitioners to
table 1 for more details. Additionally, these applications suffer store ancillary information (metadata) about the sensors data
from a general lack of controlled vocabularies to allow sensors values that in turn can be used to provide traceable heritage
data to be organized, cataloged and retrieved painlessly. For from raw measurements to usable information and be
example, in [3] temperature unit is “celsius” while in [6] it is unambiguously interpreted in the form of Text-based TEDS.
“DEGREE CELSIUS”. A somehow similar issue has been For this TEDS category, the IEEE 1451.0 documentation [12]
raised by Hu et al. [37] prompting them to develop ontology to only provides a suggestive model of the Text portion. Hence,
model terminologies defined in IEEE 1451.4 [63] and this TEDS category is not fully documented to be seamlessly
consequently, bridge the gap between IEEE 1451 and replicated.
Table 1. Summary of the existing TEDS editors characteristics.

References Programming language Comments

[10] Labview Poor documentation for TEDS implementation
[5] Delphi Poor documentation for TEDS implementation
[6] C# Manual decomposition of Physical units, Use IEEE 1451 keywords
[7] ANSI C Manual decomposition of Physical units, Use IEEE 1451 field type names abbreviations for GUI labels
[8] C/C++ Poor documentation for TEDS implementation
[9] C++ Poor documentation for TEDS implementation
User-friendly GUI, Preliminary TEDS editor, No further improvement, Published prior to the acceptance
[3] Not reported
and publication of IEEE 1451.0,
[44] Web Technologies Manual decomposition of Physical units, Heavily use abbreviations for GUI labels
[62] Web Technologies Well documented TEDS editor, but requires familiarity with IEEE 1451 and HEX manipulation

Finally, while a mature language, the use of Python

programming language in sensor application is still at its 2. Overview of the IEEE 1451 Standards
infancy. A review of the current status of the IEEE 1451
standard based sensor applications [52] such as GUI for data The anatomy of the IEEE 1451 standard can be succinctly
management and visualization, communication drivers and explained using the Smart Transducer model as a reference
data logging demonstrates that programming languages such (figure 1 (a) from [13]). It comprises analog or digital sensor
as the C family, Java and LabVIEW (a proprietary language or actuator elements, a processing unit, and a communication
and programming environment) remain the de facto interface as a single block element [14]. The IEEE 1451
programming languages adopted. Out of 24 GUI applications retrofits the Smart Transducer model and splits it into two
reported in that review, only one [53] has used Python. A major components: the Transducer Interface Module (TIM)
similar dominance of those programming languages has also and the Network Capable Application Processor (NCAP)
been noted in TEDS creator applications (Table 1). linked by a Transducer Independent Interface (TII) (fig. 1 (b)).
This paper presents a much improved and The TIM consists of a Transducer Signal Conditioning and
platform-independent TEDS generator application developed Data Conversion unit, a maximum of 255 sensors and
using Python programming language and incorporates actuators, and the TEDS files. This differentiates the IEEE
provision for a unified standards-based automatic data storage 1451 smart transducer from the conventional smart transducer.
system incorporating IEEE 1451.0 features [12, 16]. The NCAP performs application processing and network
The paper is organized as follows: Section II provides an communication functions. The IEEE 1451 smart transducer
overview of the IEEE 1451 family of standards, Section III model (fig. 1(b)) demonstrates that both TIMs and NCAPs can
provides an understanding of the TEDS, Section IV presents be implemented using off-the-shelf components [15] like the
the key design principles underlying the application, Section Arduino (http://www.arduino.cc/) microcontroller as TIM and
V shows an essential UML model of the application, Section the Raspberry Pi (http://www.raspberrypi.org/) as a NCAP
VI presents some of GUIs and demonstrates some results and which is what we ultimate lively seek to accomplish.
finally, Section V summarizes the paper and provides insight We focus on the presentation of a straightforward creation
to future works. of the various types of TEDS as defined in the IEEE 1451.0
standard [12]. The IEEE 1451.0 standard member provides a
 International Journal of Sensors and Sensor Networks 2015; 3(1): 1-11 3

common basis to enable interoperability between the other the data value octets describing the property of the entry.
members (named IEEE 1451.X). Within this interoperability There is an exception to this convention however; the User’s
philosophy, the IEEE 1451 standard defines a common set of Transducer Name TEDS, even when implemented as a binary
commands for setting up, accessing sensors and actuators TEDS, has the “TCName” user-dependent entry, a name to
connected in various physical configurations such as recognize the TIM that does to not follow the TLV rule. The
point-to-point, distributed multi-drop and wireless data block of the Text-based TEDS also ignores this
configurations as well as reading and writing the data used by convention. It is also worthwhile noting that not all of the
the system [13]. It defines the functions that are to be defined entries in any TEDS need to be included in the
performed by a transducer interface module (TIM) and the implemented TEDS information block. For example, the field
common characteristics for all devices that implement the indicating the time and date when a sensor was last calibrated
TIM. More importantly, it specifies the formats for the TEDSs can be omitted in the Calibration TEDS.
and defines a set of commands to facilitate the setup and The TEDS for smart sensors are typically stored and
control of the TIM. It also defines Application Programming shipped on a nonvolatile memory embedded in the sensor or
Interfaces (APIs) to facilitate communications with the TIM the TIM. However, the standard allows the TEDS to be stored
and with applications through a network link. As this paper is in other places within the user’s system; in this case they are
concerned with the IEEE 1451.0 member only, the bolts and known as Virtual TEDS. These permit traditional analog
nuts of the IEEE 1451 family of standards are not explained sensors to also enjoy the benefits of TEDS without needing to
here. Further details can be found in [2] and [13]. be retrofitted with an embedded nonvolatile memory. This is
achieved by generating and storing the TEDS on the sensor
platform or downloading it from an online repository managed
by the sensor manufacturer. Once implemented and loaded to
the TIM or somewhere within the system a copy of each
TEDS is transferred to the NCAP; this action utilizes the
TEDS information to help identify which TIMs are attached to
it and further identify which transducers are attached to a TIM
[16].

Figure 1. Smart Transducer model (a) vs IEEE 1451 Smart Transducer Model
(b).

3. TEDS Background
The IEEE 1451.0 defines 16 TEDS types [46] divided in
Figure 2. IEEE 1451.0 TEDS types and their categorization.
two general categories based on the content of the TEDS
information block and can accommodate a wide range of
potential sensors and actuators. These are: the Binary TEDS 4. Application Design Principles
which are divided into two sub-categories, Required and
Optional TEDS; and the Text-based TEDS which are all The TEDS generator is built upon the following key design
Optional TEDS. However, the exceptions to the rule are the principles:
Optional Manufacturer-defined and End User’s Application 4.1. Minimal Dependency on Python’s Non-Native Package
Specific TEDS which can be either a Text-based or Binary
TEDS the choice of which is left up to the user’s discretion. Our application has been developed in Python, an
Fig. 2 depicts the division of the IEEE 1451.0 TEDS. interpreted, interactive, and object-oriented programming
The IEEE 1451.0 format for binary TEDS consists of three language. It is built using primarily python’s built-in packages
major blocks: the Length block specifying the number of to make installation and utilization as easy and convenient as
octets in the information block and the checksum, the possible. This design principle allows the application to be as
Information block (a series of ordered entries) and the light-weight as possible in terms of memory usage and also
Checksum block to verify data integrity. In addition, each permits it to run on resource constrained devices like the
entry in the information block uses the Time-Length-Value Raspberry Pi. Moreover, because the application is developed
(TLV) format where T is an octet representing the entry in Python it is platform agnostic which means that it is able to
number, L represents the number of octets in the V, and V is run common platforms such as Windows, Mac OS, Linux,
4 Paul Celicourt and Michael Piasecki: An IEEE 1451.0-based Platform-Independent TEDS Creator using Open
Source Software Components

Android, etc., without alteration. Currently available Python packages intended to

manipulate units do not natively support conversion of units
4.2. Open-Source GUI Development Toolkit (WxPython) with the naming convention adopted by CUAHSI like
Our application provides a GUI to enable users to create the 'kilograms per 1000 square meter' or by the National Institute
implemented TEDS. The stand-alone WxPython [49] of Technology and Standard [35]. In addition, there are a
open-Source GUI development toolkit was selected for its number of peculiarities and subtleties in the unit names and
simplicity in both utilization and installation compared to the abbreviation that these packages cannot manage
use of other toolkits such as PyQt4 [50]. The package is free out-of-the-box such as “gallon” represented by lower (g) and
for anyone to use in commercial and non-commercial uppercase (G) abbreviations. On top of those issues, these
applications and is also platform agnostic. packages could not be used because they perform what we
may call “meshed dimensional conversion” by analogy to a
4.3. Model-View-Controller Architecture meshed sensor network. A special Python package having the
capabilities to perform Dimensional Analysis, Unit Reduction
A key strategy in the development of our application was and Conversion has been developed according to the unit
the introduction of the Model-View-Controller, MVC, definition and conversion algorithm proposed by [36] after
approach developed by Tryge Reenskaug [17-24, 51]. It pre-processing the units. In addition, a Compact
permits the separation of the View, Controller, and Model Representation of the units according to [34], a structure that
components such that alterations and further developments on encodes only the exponents of a physical unit decomposed
one component will not affect the usability of the other two into the product of the seven Système International (SI) base
[17]. It thus greatly aids in meeting our objective for software units and two SI supplementary units (radian and steradian) as
reusability and ease-of-use, parallel implementation of a vector in a well-defined order (e.g., joule (m^2*kg/s^2) is
components, and modularity. The design rules and [0,0,2,1,-2,0,0,0,0]), is also a feature of our newly developed
conventions for reusable application/classes suggested by [26] Python package to meet the unit representation specification
were followed wherever they are applicable to our application. in IEEE 1451. A full description of our package however, is
4.4. Help System beyond the scope of this paper and we just introduce its
existence for the time being.
Besides the translation of the IEEE 1451 technical terms
into more comprehensible terms, our application has been 4.6. TEDS Structure Model
augmented with a help system in the form of a tooltip that Each entry in the TEDS data block requires the field types
gives instructions to the user with regard on how to select (Type), generally a sequence of numbers, to be known. In
entries in the Graphical User Interface. In addition, an asterix addition, each entry has a specified data type (Int, float, etc.)
(*) is added to the essential fields required to create the TEDS. and is represented with a certain length or number of octets.
4.5. TEDS-Based Controlled Vocabularies and Ready-Made Some data blocks also contain nested entries such as parent
Metadata entries with children entries where both parents and children
have to follow the TLV format. This means that the V in the
The CUAHSI Observations Data Model (ODM) [29] is a parent entry is a sequence of TLVs. Generating these TLVs is
relational database designed to store time series observations an involved and onerous task that complicates the creation of
with sufficient ancillary information (metadata) about the data TEDS thus prompting the desire to develop a one-size-fits-all
values to provide traceable heritage from raw measurements [30] method to generate the desired TEDS. Therefore, we
to usable information [27-28]. [28] provides a detailed need a model/pattern of the TEDS structure defined in IEEE
description of the tables and associated attributes in this data 1451.0 for each TEDS type to be implemented. In our
model, a listing of the fields contained in each table, a application, the TEDS structure is modeled using the
description of the data contained in each field and its data type, following general pattern (fig. 4):
specific constraints imposed on each field, and discussion on
how each field should be populated. Because the authors deal TEDS Type = Field Type: {Field Name: {Key1:Field Type,
Key2:Number of bits, Key3:Value, Key4:Data type, Children:
with a substantial amount of time series generated data, the
Children_Fields/None}}.
motivation arose to integrate information system requirements
up front into the TEDS. A key component for the successful The Python dictionary type allows the capture of more
functioning of a distributed time series database system is the structured information than a simple list of elements and its
provision and subsequent adherence to controlled nesting feature allows building up and access complex
vocabularies. We demonstrate using CUAHSI ODM information structures directly and easily. The strength of this
Controlled Vocabularies how these can be integrated into our data structure is that it can accommodate and store an
system, in this case the inclusion of the physical units CV, to unlimited number of data structures and types.
aid discovery, search and publication of sensor data at the Adoption of this strategy also permits i the model to offer an
NCAP level. We have also integrated a “crawler” that all-encompassing to encapsulate the user inputs and the
automatically interrogates the CVs we are using for one-size-fits-all method processing the inputs to create the
integration of the latest version.
 International Journal of Sensors and Sensor Networks 2015; 3(1): 1-11 5

TEDS. In addition, if the IEEE standard is subject to some the TEDS structure model with only, if at all, minimal changes
future revisions, the same method can be used without needed in the View and Controller classes.
modification to accommodate new entries by simply updating

Figure 3. the Main View of the application.

Figure 4. Example of the TEDS model used as a helper to create the TEDS.

with the application. It receives and registers user actions

5. A Simplified UML Model of the and determines the action to be taken, for example,
Application calling a method. Like the View, the Controller registers
itself as an observer of the Model.
The MVC architecture while conceptually simple To better illustrate the complexity of the interactions of all
nevertheless requires a substantial effort when implementing. components in our application, we have developed a UML
The goal of the MVC triad is to separate application representation that depicts the dependencies and inheritance,
components into three independent action blocks. Each one of as shown in Fig. 5. The UML model shows that our
them however, still requires considerable coding work in application is actually built on a variant of the MVC pattern
addition to needing to stipulate data and information flow named Hierarchical MVC [31, 33] which is a hierarchy of
interfaces that require careful consideration. The three parent-child MCV layers. We introduced this as a convenient
components are tasked as follows: way of structuring the Main GUI (Fig. 3) from which users
a. The Model handles data storage, provision and can choose the TEDS to be implemented (e.g., Fig. 6) which
processing tasks and operates independently of the other themselves are based on the MVC pattern. Hence, the
two. It is also responsible for broadcasting messages application is built as layered/hierarchical MVC in which a
about changes occurring on the data to its dependent link is made between the main layer and the children layers.
view-controller pairs. To better illustrate the HMVC setup, we provide the following
b. The View requests and presents the data and the state of example: Fig. 3 is modeled in the UML Model by the
the application held by the Model to the user through a classes/objects: Main View, Main Controller and Model that
GUI. In order to obtain information about the Model together constitute the parent MVC layer; The Main
contents, the View component must register itself as a Controller follows up on the user actions (click a button to
dependent or an observer of the Model using an Observer implement a TEDS) on this GUI and calls the MVC layer
Pattern [41]. associated to the clicked button. We use a common model
c. The Controller is the interface or the glue between the (IEEE1451Dot0Model) instead of using a separate model for
View and the Model and handles the user interaction each controller-view pair.
6 Paul Celicourt and Michael Piasecki: An IEEE 1451.0-based Platform-Independent TEDS Creator using Open
Source Software Components

Figure 5. an Essential UML model of the TEDS generator application.

easily deployed in the field. Our goal is to provide a complete

sensor-to-end user package in which data management aspects
in addition to data submission and retrieval are handled
automatically thus providing a solution that is as hands-off as
it can be. As mentioned before we choose the Observations
Data Model of the CUAHSI HIS [43] a system to store point
based time series data using international standards such
WaterML2.0 [58-59] and Water One Flow web services to
provide computer-to-computer communications. One
consequence of this specific adoption is the need to provide
compliant metadata to adequately annotate the time series
data.
The IEEE 1451.0 standard is flexible enough that it can be
used to embed textual information into a TEDS where each
block is an XML “instance document”, the only constraint
Figure 6. Meta-TEDS Created for the Arduino Uno. imposed. Researchers have taken steps to either suggest some
additional entries [1] or develop new TEDS [38] that have the
potential to fulfill some application specific needs such as
6. TEDS Implementation reporting on sensor health. While possible, our application
Our work has been motivated in the context of developing does not demand this extra work of supplying metadata and
affordable and smart hydro-climate sensor stations that are stays within the confinement of the TEDS list enumerated
 International Journal of Sensors and Sensor Networks 2015; 3(1): 1-11 7

above. This is because the required metadata can easily be

described using the CUAHSI Water Markup Language
(WaterML) [39]-[40] making the information block of the
Text-based TEDS comply with the XML “instance document”
constraint imposed by IEEE 1451.0. The metadata is encoded
in WaterML at the TIM level for transmission to the NCAP
and an application at the NCAP level will consume the
WaterML description to dynamically process and store the
data properly into the ODM.
There are, however, three metadata tables that need direct
user input: Variable, Source, and Site tables. The last two
Figure 7. Transducer Channel TEDS for the MPXx5050 series.
tables contain information common to all Transducer
Channels attached to the TIM. There are three TEDS
6.3. Transducer Channel Identification TEDS (Variable
candidates to represent those tables: Meta-Identification
Metadata Table)
TEDS, End User’s Application Specific TEDS and
Manufacturer-Defined TEDS. Based on the fact that the The Transducer Channel Identification TEDS falls into the
Meta-TEDS provides information common to all Transducer category of Text-based TEDS that comprises two blocks: a
Channels, the Meta-Identification TEDS is the best candidate binary which is a directory to allow a processor to locate and
to represent the TEDS describing the Source and Site read the information block for a single language in the TEDS.
metadata tables in the CUAHSI ODM. This same reasoning Note that multiple information blocks in different languages
holds for the Variable metadata table and the Transducer are permitted. The second block, the Text (XML instance)
Channel Identification TEDS was selected to represent the based portion, should be created first as the binary portion
information that will be loaded into the ODM Variable table. contains sub-fields that depend on the memory size of the text
Our application implements the following TEDS. portion. Text-based TEDS are much more cumbersome to be
created manually than binary TEDS because byte counting,
6.1. Meta-TEDS
evaluation and subsequent checksum computations are labor
The Meta-TEDS ensures availability of information intensive. They are also highly prone to error in addition to
necessary to gain access to any Transducer Channel, plus the requiring multiple checksum computations for text based
information common to all Transducer Channels. An essential TEDS. This is even more difficult if the content is to be
Meta-TEDS consists of the key fields (with asterix) in figure 6. implemented in more than one language because the memory
As an example, we show the geographic location of the size of the text portion may vary from one language to another
Arduino Uno manufacturer in Turin, Italy together with a and the binary part has to contain the right information to
made-up manufacturing date and we also assume that a allow the TEDS processor to accurately locate the text portion
collection of seven sensors will be connected to the Arduino. for each language.
Our application produces the TEDS as shown above where the Figure 8 shows the TEDS containing information about the
first line indicates the total number of bytes in the TEDS, the ODM Variable table as a Water ML instance for the selected
second one is the TEDS identifier, the third one identifies the pressure sensor. Currently, our application supports only a
microcontroller manufacturer, the fourth to sixth lines show single language (English) but there is the opportunity to
the communication-related time, the seventh is the number of extend it to support more than one language in the context of
sensors to be implemented, and the last one is the Checksum the “Internationalization of the CUAHSI Hydro Server” [42].
to ensure data integrity. To minimize the space occupation of For transmission purposes, the text information block
the figures, we put the TEDS figure on the GUI. (Water ML string) is compressed using the Gzip compression
method natively available in Python and accepted by the IEEE
6.2. Transducer Channel TEDS 1451.0. This compression technique helps achieve a
compression ratio of about 50%, which is important because
The Transducer Channel TEDS describes and makes
data transmission/reception time is proportional to data packet
available all of the information concerning the Transducer
size and a sensor node expends maximum energy in data
Channel being addressed thus ensuring proper operation of the
communication [60]. We need to mention also that the
channel. We have used the MPX5050/MPXV5050G series
compression has an impact on the checksum computation for
pressure sensor [54] compatible with Arduino for testing, the
the information block and subfields in the binary portion. To
results of which are shown below (Fig. 7). We do not show the
avoid users’ mistakes in associating the Variable metadata to
GUI here because it is too large to fit into the text at a
the appropriate sensor, the GUI generating this TEDS is
resolution high enough to discern the individual input field
integrated into the Transducer Channel TEDS GUI so they are
descriptions. Instead we show the TEDS content as a series of
implemented simultaneously.
entries to facilitate its interpretation and understanding, but we
could also group the whole content as a series of octets.
8 Paul Celicourt and Michael Piasecki: An IEEE 1451.0-based Platform-Independent TEDS Creator using Open
Source Software Components

Figure 8. Text-based TEDS to describe the ODM variable table.

Figure 9. The Calibration TEDS GUI.
6.4. Meta-Identification TEDS (Source & Site Metadata
Tables)

The Meta-Identification TEDS provides all information

needed to identify the TIM plus any information common to
all channels. Under this Text-based TEDS, we implement the
ODM Source and Site Tables. The result is similar to the text
shown Fig. 8 with the unique difference that this TEDS
contains an information block with two XML elements
“source” and “site”. To minimize space, it is not presented
here.
Figure 10. The Calibration TEDS for the pressure sensor used.
6.5. Calibration TEDS

Finally, the calibration TEDS provides all of the 7. Summary

information used by the correction software in charge of
converting the sensor output (electrical signal) into A practical user-friendly and platform-independent
engineering units in connection with the Transducer Channel application designed to generate Transducer Electronic Data
being queried. Our application supports both the Linear and Sheet (TEDS) according to the IEEE 1451.0 standard using
General (Polynomial form) sensor data Correction Method the Python open source programming language has been
(LCM/LGM) of the IEEE 1451.0. presented. It has been designed to ease the end user’s work
We referred to [64] to implement the general correction with an on-the-fly help system provided and constrained the
method in which provision to accommodate a large array of user to provide required information for compliance to the
sensor outputs as inputs is made. However, due to the specification of the standard. It has been successful in
complexity of this method and even though we provide producing the supported TEDS including Text-based TEDS
instructions to users about how to provide the information, it smoothly. The Hierarchical Model-View-Controller software
must be implemented by users with an adequate design architecture has been used to produce concise,
comprehension of the general calibration method of the IEEE maintainable and reusable high quality software. It also
1451 to correctly supply the information to the application. demonstrates the promising capability of the Python
We need to point out here that none of the previously studied programming language to be used in sensor applications and
TEDS creators has implemented the general correction more importantly when the aspect of sensor data management
method. is considered.
For unit-to-unit conversion, the application provides the The reusable and modular software development mind will
conversion slope and intercept to the user on the fly using the allow us to easily decode and test the TEDS for compliance
Physical unit selected in the Transducer Channel TEDS GUI and perform tasks necessary to achieve an
once the related Transducer Channel TEDS has been created. Auto-programmable Data Acquisition System. We have tested
Fig. 9 shows those two values for the selected sensor and the results of our application with examples provided in the
figure 10 shows the calibration TEDS created (LCM). IEEE 1451.0 documentation, and both results show
agreement.
 International Journal of Sensors and Sensor Networks 2015; 3(1): 1-11 9

25-38, October 1996, Helmers Publishing.

References [16] J., Wiczer & K., Lee (2005). ‘A Unifying Standard for
Interfacing Transducers to Networks–IEEE 1451.0. In
[1] J., Higuera, J., Polo, & M., Gasulla (2009). A ZigBee wireless Proceedings of ISA Conference, Chicago, IL.
sensor network compliant with the IEEE 1451 standard. In
Proceedings of the IEEE Sensors Applications Symposium. [17] G. E., Krasner & S. T., Pope, “A cookbook for using the
model-view-controller user interface paradigm in smalltalk-80,”
[2] K., Lee (2000). IEEE 1451: A standard in support of smart J. Object Oriented Program., vol. 1, no. 3, pp. 26–49, Aug.
transducer networking. In Instrumentation and Measurement 1988.
Technology Conference, 2000. IMTC 2000. Proceedings of the
17th IEEE (Vol. 2, pp. 525-528). IEEE. [18] T., Reenskaug (2003). The Model-View-Controller (MVC): Its
Past and Present. [Online] Draft of August 20, 2003. Accessed
[3] Liu, W. (2006). Design of teds writer, reader and testing system January 15th, 2015.
for transducer interface modules based on the ieee 1451 http://heim.ifi.uio.no/~trygver/2003/javazone-jaoo/MVC_patt
standard. State University of New York at Buffalo. ern.pdf
[4] D., Wobschall (2007). IEEE 1451—a universal transducer [19] T., Reenskaug (2007). The original MVC reports. [Online]
protocol standard. In Autotestcon, 2007 IEEE (pp. 359-363). February 12, 2007. Accessed January 15th, 2015.
IEEE. http://heim.ifi.uio.no/~trygver/2007/MVC_Originals.pdf
[5] L., Cámara, O., Ruiz, & J., Samitier (2000). Complete [20] J., Deacon (2009). Model-view-controller (mvc) architecture.
IEEE-1451 node, STIM and NCAP, implemented for a CAN Online][Citado em: 10 de março de 2006.]
network. In Instrumentation and Measurement Technology http://www.jdl.co.uk/briefings/MVC.pdf
Conference, 2000. IMTC 2000. Proceedings of the 17th IEEE
(Vol. 2, pp. 541-545). IEEE. [21] A., Bower & B., McGlashan (2000). Twisting the triad: the
evolution of the Dolphin Samlltalk MVP application
[6] S., Manda & D., Gurkan (2009). IEEE 1451.0 compatible framework. Tutorial Paper for ESUG, 2000.
TEDS creation using. NET framework. In Sensors
Applications Symposium, 2009. SAS 2009. IEEE (pp. [22] S., Burbeck (1987). Applications Programming in
281-286). IEEE. Smalltalk-80(TM): How to use Model-View-Controller (MVC).
Accessed January 15th, 2015.
[7] J., Guevara, F., Barrero, E., Vargas, J., Becerra, & S. Toral
(2012). Environmental wireless sensor network for road traffic [23] M., Fowler (2006). GUI Architectures. [online]
applications. IET Intelligent Transport Systems, 6(2), 177-186. martinfowler.com. Available at:
http://martinfowler.com/eaaDev/uiArchs.html [Accessed 16
[8] D., Markovic, U., Pesovic, & S., Randic (2012)"TEDS Jan. 2015].
specification for IEEE 1451.0 smart Transducer,"
Telecommunications Forum (TELFOR), 2012 20th, vol., no., [24] T., Reenskaug (1979). Models - Views - Controllers. Technical
pp.1532, 1535, 20-22 Nov. 2012. note, Xerox PARC.

[9] N., Kularatna & B. H., Sudantha (2008). An environmental air [25] K. B., Lee (2014). Smart Transducer Interface Standard for
pollution monitoring system based on the IEEE 1451 standard Sensors and Actuators. Industrial Communication Technology
for low cost requirements. Sensors Journal, IEEE, 8(4), Handbook, Second Edition. Aug. 2014, 1 -17.
415-422.
[26] R. E., Johnson & B., Foote (1988). Designing reusable classes.
[10] Jevtic, N., & Drndarevic, V. (2013). Design and Journal of object-oriented programming, 1(2), 22-35.
implementation of plug-and-play analog resistance temperature
sensor. Metrology and Measurement Systems, 20(4), 565-580. [27] D. G., Tarboton, J. S., Horsburgh & D. R., Maidment (2007).
CUAHSI community Observations Data Model (ODM)
[11] R., Rana, N., Bergmann, & J., Trevathan (2011). Towards version 1.1 design specifications.
plug-and-play functionality in low-cost sensor network. In
Intelligent Sensors, Sensor Networks and Information [28] J. S., Horsburgh & D. G., Tarboton (2008). CUAHSI
Processing (ISSNIP), 2011 Seventh International Conference Community Observations Data Model (ODM) Version 1.1. 1
on (pp. 265-270). IEEE. Design Specifications.

[12] IEEE Standard for a Smart Transducer Interface for Sensors [29] J. S., Horsburgh & D. G., Tarboton, D. R., Maidment & I.,
and Actuators – Common Functions, Communication Zaslavsky (2008). “A relational model for environmental and
Protocols, and Transducer Electronic Data Sheet (TEDS) water resources data.”, Water Resources Research, Vol. 44
Formats, IEEE Standard 1451.0-2007. (2008).

[13] E. Y., Song & K., Lee (2008). Understanding IEEE [30] M., Stonebraker & U., Cetintemel (2005). “One Size Fits All:
1451-Networked smart transducer interface standard-What is a An Idea Whose Time has Come and Gone”. In Proceedings of
smart transducer?. Instrumentation & Measurement Magazine, the International Conference on Data Engineering (ICDE),
IEEE, 11(2), 11-17. 2005.

[14] W., Elmenreich, & S., Pitzek (2003). Smart [31] Cai, J., Kapila, R. and Pal, G. (2000). HMVC: The layered
transducers-principles, communications, and configuration. na. pattern for developing strong client tiers. [online] Available at:
http://www.javaworld.com/article/2076128/design-patterns/h
[15] S., Woods et al. (1996). “IEEE-P1451.2 Smart Transducer mvc--the-layered-pattern-for-developing-strong-client-tiers.ht
Interface Module,” Proceedings Sensors Expo Philadelphia, pp. ml [Accessed 17 Jan. 2015].
10 Paul Celicourt and Michael Piasecki: An IEEE 1451.0-based Platform-Independent TEDS Creator using Open
Source Software Components

[32] B., Cogan (2010). HMVC: an Introduction and Application - [45] T. A. dos Santos Filho, A. C. R. da Silva, A. Luiz, A. Nogueira,
Tuts+ Code Tutorial. [online] Code Tuts+. Available at: S. R. Rossi, E. A. Batista (2010). Descricao Dos Teds Para O
http://code.tutsplus.com/tutorials/hvmc-an-introduction-and-a Controle De Motores De Passo Em Conformidade Com Do
pplication--net-11850 [Accessed 17 Jan. 2015]. Padrao IEEE 1451. [online]
http://www.eletrica.ufpr.br/anais/cba/2010/Artigos/65581_1.p
[33] W., Crow (2012). Hierarchical Model-View-Controller df [Accessed 01-29-2015]
(HMVC): Planning for the Future. [online] Available at:
http://somethingstatic.com/hierarchical-model-view-controller [46] K. Lee, A Smart Transducer Interface Standard for Sensors and
-planning-future/ [Accessed 17 Jan. 2015]. Actuators, The Industrial Information Technology Handbook,
Zurawski R. (Ed.), CRC Press, Boca Raton, FL, 2004
[34] B., Hamilton (1996). A compact representation of units.
Hewlett-Packard Laboratories, Technical Publications [47] Ilyas, M., & Mahgoub, I. (Eds.). (2004). Handbook of sensor
Department. networks: compact wireless and wired sensing systems. CRC
press.
[35] A., Thompson and B. N., Taylor (2008), Guide for the Use of
the International System of Units (SI) NIST Special Publication [48] National Instruments, (2006). Sensor Calibration with TEDS
811, 2008 Edition (version 3.0). [Online] Available: Technology. [online] Available at:
http://physics.nist.gov/SP811 [Saturday, 24-Jan-2015 22:46:15 http://www.ni.com/white-paper/4043/en/ [Accessed 29 Jan.
EST]. National Institute of Standards and Technology, 2015].
Gaithersburg, MD.
[49] N. Rappin and R. Dunn, wxPython in action. Greenwich, Conn.:
[36] G. S., Novak (1995). Conversion of units of measurement. Manning, 2006.
Software Engineering, IEEE Transactions on, 21(8), 651-661.
[50] M. Summerfield, Rapid GUI programming with Python and Qt.
[37] Hu, P., Robinson, R., & Indulska, J. (2007). Sensor standards: Upper Saddle River, NJ: Prentice Hall, 2008.
Overview and experiences. In Proceedings of the 3rd
[51] Sasine, J. M., & Toal, R. J. (1995, November). Implementing
International Conference on Intelligent Sensors, Sensor
Networks and Information Processing ISSNIP’07. the model-view-controller paradigm in Ada 95. In Proceedings
of the conference on TRI-Ada'95: Ada's role in global markets:
[38] R. L., Oostdyk, C. T., Mata & J. M., Perotti (2006). A Kennedy solutions for a changing complex world (pp. 202-211). ACM.
Space Center implementation of IEEE 1451 networked smart
[52] A. Kumar, V. Srivastava, M. Singh and G. Hancke, 'Current
sensors and lessons learned. In Aerospace Conference, 2006
Status of the IEEE 1451 Standard Based Sensor Applications',
IEEE (pp. 20-pp). IEEE.
IEEE Sensors Journal, pp. 1-1, 2014.
[39] Zaslavsky, I., Valentine, D., Maidment, D., Tarboton, D. G.,
[53] Fadzil, M. H., Abas, M. A., & Hakiim, A. K. (2010, April).
Whiteaker, T., Hooper, R., & Rodriguez, M. (2009). The Development of Environmental Monitoring Data Management
evolution of the CUAHSI Water Markup Language (WaterML).
System using OSS Python. InProceeding of the International
In EGU General Assembly Conference Abstracts (Vol. 11, p.
Conference on Electrical and Computer Engineering.
6824).
[54] Freescale Semiconductor (2010). 'Integrated Silicon Pressure
[40] Valentine, D., Zaslavsky, I., Whitenack, T., & Maidment, D. R. Sensor On-Chip Signal Conditioned, Temperature
(2007). Design and implementation of CUAHSI WATERML Compensated and Calibrated', 2010. [Online]. Available:
and WaterOneFlow Web services. In Proceedings of the http://cache.freescale.com/files/sensors/doc/data_sheet/MPX5
Geoinformatics 2007 Conference, San Diego, California (pp. 050.pdf. [Accessed: 04- Feb- 2015].
5-3).
[55] Kamala, J. and Umamaheswari, B. “IEEE 1451.0-2007
[41] Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1994). compatible smart sensor readout with error compensation using
Design patterns: elements of reusable object-oriented software. FPGA”, International Journal of Sensors and Transducers, Vol.
Pearson Education. 102, Issue 3, pp. 10-21, 2009 (Elsevier Publishers).
[42] J. Sadler, S. Bolster, D. Ames and E. Nelson (2013). [56] R. J. Costa, G. R. Alves, and M. Zenha-Rela, “Extending the
Internationalizing HydroServer - Multilingual Support for IEEE 1451.0 Std. to serve distributed weblab architectures,“ in
Water Data Sharing. In: CUAHSI conference on 1st Experiment@ International Conference (exp.at’11),
Hydroinformatics and Modeling. [online] Available at: Calouste Gulbenkian Foundation, Lisboa-Portugal, 2011.
https://www.cuahsi.org/PageFiles/2013PosterAbstracts.pdf
[Accessed 25 Jan. 2015]. [57] G. Giorgi and C. Narduzzi, “Instrumentation electronic data
sheets: IEEE 1451-like extension to measuring
[43] D. G. Tarboton, J. S. Horsburgh, D. R. Maidment, T. Whiteaker, systems,“ Instrumentation and Measurement Technology
I. Zaslavsky, M. Piasecki, J. Goodall, D. Valentine, and T. Conference (I2MTC), 2012 IEEE International, 2012.
Whitenack, "Development of a community hydrologic
information system," in 18th World IMACS Congress and [58] Almoradie, A., Popescu, I., Jonoski, A., & Solomatine, D.
MODSIM09 International Congress on Modelling and (2013). Web Based Access to Water Related Data Using OGC
Simulation, 2009, pp. 988-994. WaterML 2.0. Specialissue, 3(3).
doi:10.14569/specialissue.2013.030310
[44] Barrero, F., Toral, S., Vargas, M., & Becerra, J. (2012).
Networked Electronic Equipments Using the IEEE 1451 [59] P. Taylor, S. Cox, G. Walker, D. Valentine and P. Sheahan,
Standard—VisioWay: A Case Study in the ITS Area. 'WaterML2.0: development of an open standard for
International Journal Of Distributed Sensor Networks, 2012, hydrological time-series data exchange', Journal of
1-12. doi:10.1155/2012/467124 Hydroinformatics, vol. 16, no. 2, p. 425, 2014.
 International Journal of Sensors and Sensor Networks 2015; 3(1): 1-11 11

[60] Akyildiz, I. F., Su, W., Sankarasubramaniam, Y., & Cayirci, E. [64] Eccles, L. (1999). IEEE-1451.2 Engineering Units Conversion
(2002). Wireless sensor networks: a survey. Computer Algorithm. Sensors Magazine, [online] (Volume 16, No. 5).
networks, 38(4), 393-422. Available at:
http://archives.sensorsmag.com/articles/0599/0599_p107/inde
[61] D., Wobschall (2008). Networked sensor monitoring using the x.htm [Accessed 30 Jan. 2015].
universal IEEE 1451 standard. Instrumentation &
Measurement Magazine, IEEE, 11(2), 18-22. [65] Botts, M. (2002). Sensor Model Language (SensorML) for
In-situ and Remote Sensors IPR. OpenGIS Project Document.
[62] Ma, A. Cherian and D. Wobschall, 'IEEE 1451 Development
Kit Description', Esensors Inc., 2013. [Online]. Available: [66] Reichardt, M. (2005). Sensor web enablement: An OGC white
http://eesensors.com/media/wysiwyg/pdf/1451_manual.pdf. paper. Open Geospatial Consortium (OCG).
[Accessed: 12- Feb- 2015].
[67] M. Botts and L. McKee, 'A Sensor Model Language: Moving
[63] IEEE Standard 1451.4 (2004) IEEE Standard for a Smart Sensor Data onto the Internet | Sensors', Sensors Magazine,
Transducer Interface for Sensors and Actuators: Mixed-Mode 2003. [Online]. Available:
Communication Protocols and Transducer Electronic Data http://www.sensorsmag.com/networking-communications/a-se
Sheet (TEDS) Formats, IEEE Standard 1451.4-2004. nsor-model-language-moving-sensor-data-internet-967.
[Accessed: 14- Feb- 2015].

View publication stats