SW for an intelligent transducer network based on IEEE 1451 standard

Computer Standards & Interfaces 34 (2012) 1–13

Contents lists available at ScienceDirect

Computer Standards & Interfaces j o u r n a l h o m e p a g e : w w w. e l s ev i e r. c o m / l o c a t e / c s i

HW/SW for an intelligent transducer network based on IEEE 1451 standard E.A. Batista a,⁎, L. Gonda b,⁎, A.C.R. da Silva c, S.R. Rossi d, M.C. Pereira e, A.A. de Carvalho c, C.E. Cugnasca f a

Federal University of Mato Grosso do Sul, Dept. of Electrical Engineering, Campo Grande-MS, Brazil Federal University of Mato Grosso do Sul, College of Computing, Campo Grande-MS, Brazil c University of São Paulo State, Dept. of Electrical Engineering, Ilha Solteira-SP, Brazil d Center of Buenos Aires Province National University, Dept. of Electro-Mechanical Engineering, Argentina e Dom Bosco Catholic University, Computer and Engineering Research Group, Campo Grande-MS, Brazil f Polytechnic School, University of São Paulo, São Paulo-SP, Brazil b

a r t i c l e

i n f o

Article history: Received 30 April 2009 Accepted 20 May 2011 Available online 12 June 2011 Keywords: IEEE 1451 standard NIOS II processor FPGA Intelligent transducers

a b s t r a c t This work describes a hardware/software co-design system development, named IEEE 1451 platform, to be used in process automation. This platform intends to make easier the implementation of IEEE standards 1451.0, 1451.1, 1451.2 and 1451.5. The hardware was built using NIOS II processor resources on Alteras Cyclone II FPGA. The software was done using Java technology and C/C++ for the processors programming. This HW/SW system implements the IEEE 1451 based on a control module and supervisory software for industrial automation. © 2011 Elsevier B.V. All rights reserved.

Contents 1.

Introduction . . . . . . . . . . . . . . . . . . . . . 1.1. IEEE 1451.0 — TEDS . . . . . . . . . . . . . . 1.2. IEEE 1451.2 . . . . . . . . . . . . . . . . . . 1.3. IEEE 1451.5 — WTIM . . . . . . . . . . . . . 1.4. IDE and CAD tools used to develop the IEEE 1451 1.5. Quartus II and SOPC Builder . . . . . . . . . . 2. Implemented IEEE 1451 platform . . . . . . . . . . . 2.1. NCAP — IEEE 1451 platform . . . . . . . . . . 2.2. TIM IEEE 1451 platform . . . . . . . . . . . . 2.3. TIM configuration for Cyclone II FPGA . . . . . 2.4. NIOS II IDE . . . . . . . . . . . . . . . . . . 3. IEEE 1451 platform test . . . . . . . . . . . . . . . 3.1. Hydraulic automation kit . . . . . . . . . . . 3.2. Flow and pressure compressor automation . . . 3.3. Analysis of results . . . . . . . . . . . . . . . 4. Conclusions and future work . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

1. Introduction Transducer networks built using standard interfaces provide better flexibility for maintenance and expansion design of industrial ⁎ Corresponding authors. E-mail addresses: [email protected] (E.A. Batista), [email protected] (L. Gonda), [email protected] (A.C.R. da Silva), srossi@fio.unicen.edu.ar (S.R. Rossi), [email protected] (M.C. Pereira), [email protected] (A.A. de Carvalho), [email protected] (C.E. Cugnasca). 0920-5489/$ – see front matter © 2011 Elsevier B.V. All rights reserved. doi:10.1016/j.csi.2011.05.009

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

1 3 4 4 4 4 5 6 6 7 7 9 9 11 12 12 13

plants. This kind of networks is common on various instrumentation applications like production lines, agricultural and home automations, biomedical engineering, robotics and safety, among others. Proprietary solutions are still dominant, which protects companies' research and development, but jeopardizes scalable project distributed instrumentation. Since the 1990s NIST (National Institute of Standards and Technology) and IEEE (Institute of Electrical and Electronics Engineers) have been developing a set of transducer networks standards, called IEEE 1451 [1]. It establishes a set of rules for different interfaces

2

E.A. Batista et al. / Computer Standards & Interfaces 34 (2012) 1–13

to be used in a transducer network. The main idea is based on the definition that an intelligent transducer is a device capable of identifying itself and operating a communication network [2]. The IEEE 1451 requires the use of open and standard tools, based on an architecture set up by a NCAP (Network Capable Application Processor) and the TIMs (Transducer Interface Module). The connection mode between the NCAP and TIM and their functions originated the following committees [3], formed by scientists and engineers from various institutions. These committees are responsible for the elaboration and validation of standards details, such as: • IEEE 1451.0: is the committee responsible for the development of standards to specify transducer information, which should be in electronic format and grouped on data blocks called TEDS (Transducer Electronic Data Sheet). In first validation of the IEEE 1451.2 standard, the TEDS should be coupled to the STIM (Smart Transducer Interface Module), but around 2004, the TEDS became a responsibility of the IEEE 1451.0 committee, being common to all other interfaces. The 1451.0 establishes the way transducers data should be accessed and which information should be available. Through this interface a transducer can be identified in the communication network, providing information like manufacturer, data range and to which channel number it is connected [4]. • IEEE 1451.1: defines the NCAP (Network Capable Application Processor) concept, specifying which functions this processor should provide. The NCAP should link different communication networks and the other 1451 interfaces. To implement the NCAP, the designer should take care of two basic functionalities: the information exchange to the control network, and to manage the transducers actions [5]. • IEEE 1451.2: describes the transducer interconnection using cabling system and a serial protocol. The transducers should be connected to a STIM (Smart Transducer Interface Module). The first 1451.2 validation defined that STIM should communicate to the NCAP via a TII (Transducer Independent Interface). TII is formed by a 10-line bus, and the main purpose of this interface is to provide a plug-andplay system between the NCAP and the STIMs. Currently another possibility is under study to allow other communication approaches based on serial data transmission standards like RS232, RS485, RS422, I2C, USB [6,7]. • IEEE 1451.3: intends to define an interface to connect the transducer modules in a bus form called TBIM (Transducer Bus Interface Module). A bus should be provided to connect devices using digital signals, allowing the construction of a transducer network using the same operation mode [8]. • IEEE 1451.4: develops a mixed mode interface, to allow for the connection of digital and analog transducers using common modules, being called MMC (Mixed-Mode Communication). This interface is

composed of two classes. Class 1 has two wires, which define when the signal is digital, if the voltage is negative, or analog, otherwise. For the digital, zero Volts means logic level zero, and −5 V means logic level one. Class 2 defines a communication protocol independent from the analogical signal, which is interpreted by the NCAP via the TEDS (Transducer Electronic Data Sheet) [9]. • IEEE 1451.5: this committee develops a wireless communication between the NCAP and the transducer network. Its validation defined the ZigBee, Bluetooth e Wi-Fi technologies to be used in the interface construction between NCAP and WTIM (Wireless Transducer Interface Module) [9]. • IEEE 1451.6: this committee has been studying the application of the CAN (Control Area Network) protocol for the construction of intelligent transducers. The CAN network has a large application in the automotive industry and has been gaining popularity as a field bus. The committee suggests the use of CAN open Cia DS404 to implement a sensor network according to IEEE 1451 [3]. • IEEE 1451.7: this committee is responsible for the standardization of a RFID (Radio-Frequency Identification) system [10]. Fig. 1 shows the detailed architecture. Several research groups have been developed projects based on the IEEE 1451 standard in different segments of distributed instrumentation [11–15]. For example the IEEE 1451 node developed by the LPSSD and LAC laboratories from Unesp-Feis, which is based on a NCAP, a protocol manager, TII and STIM. The NCAPs logical part was done using Java technology and the physical part used a PC and a reconfigurable logic device from Altera, FLEX EPF10K20RC240-4 Protocol Manager (PM). This PM is connected to a PC via parallel port and to the STIM via the TII, and is responsible for physical controls of the communication protocol between the NCAP and the STIM. The STIM had two implementations, asynchronous and synchronous modes. Alteras ACEX EP1K50TC144-3 was implemented in synchronous mode. This STIM is basically formed by these function blocks: an address module, a TII control module, state registers and TEDS multiplexer. The TEDS was linked to a ROM developed with programmable parameters from Altera. Based on IEEE 1451 standard, this article describes the implementation of a hardware and software platform to build intelligent instrumentation. The software implements the logical actions of NCAP and the hardware is an embedded module that implements the TIM functions. The logical part of the NCAP was implemented using Java NetBeans environment from Sun Microsystems and the TIM was done using the Altera Corporations CAD (Computer Aided Design) tool Quartus II and the NIOS II IDE (Integrated Development Environment). This embedded module is composed by a FPGA (Field Programmable Gate Array) Cyclone II, NIOS II processor, memory, communication

Fig. 1. IEEE 1451 architecture.

E.A. Batista et al. / Computer Standards & Interfaces 34 (2012) 1–13

3

and the Driver IEEE 1451.X block provides information exchange between NCAP and TIM, according to IEEE 1451.2, IEEE 1451.3, IEEE 1451.4, IEEE 1451.5, IEEE P1451.6 and IEEE 1451.7 interfaces. The main NCAP features developed include the following features:

Fig. 2. NCAP configuration example according to IEEE 1451 standard.

interfaces and RTOS (Run Time Operating Systems) MicroC/OS. This embedded module functionality is defined through the operational logic and communication protocol based on the specific API for the IEEE 1451 rules. The APIs of this IEEE 1451 were developed in C/C++ and XML, allowing the implementation of the TEDS, NCAP communication protocol and interruption handling. The NCAP is a common module in an IEEE 1451-based smart transducers network, and is responsible for coordinating the service operator requests to the transducers network. The NCAP platform has two friendly user graphical interfaces, allowing automated processes' remote activation and monitoring and technical reports of TEDS information. The NCAPs logical functions are based on classes and methods that can be reused as basis for several other applications. Sections 1, 2 and 3 show details on the IEEE 1451 rules implemented, while Section 4 reviews the tools used on this development. Section 5 describes the IEEE 1451 platform used for operating tests, with Section 1 reports about NCAP, Section 2 about TIM, and Section 3 presents the executed tests and obtained results. Finally, Section 4 provides the conclusions of this work. A NCAP should be able to implement specific applications, such as communication with the control network processing the information from the transducers network, supply events, communication with transducers' modules via IEEE 1451.X interfaces, and accessing a TEDS from a TIM (Transducer Interface Module) [3]. Fig. 2 shows a NCAP architecture as defined by the IEEE1451.1, pointing out that the Protocol Services block manages other blocks based on the processing capability of the actual processor that implements the hardware of the NCAP. The IEEE 1451.0 block implements the TEDS, the API (Application Programming Interface) block is built according to each application, providing functionalities, such as, graphical interfaces, and service requests and others. The DNC (Driver Network Communication) supplies communication between the NCAP and the local network,

• Interoperability: a system should allow the installation of specific programs from the control network, and allows the physical connection to the corresponding network. The NCAP interoperability allows more flexibility in the construction of a transducer network. • Object oriented software block: NCAP logic part should provide the handling of control network and IEEE 1451 protocols, and have applications with the user and allow generation of TEDS. This block should have high abstraction degree from the application. The 1451.1 committee suggests that object oriented methods are used to develop the application software. An attractive feature of the software block is the composition using a graphical interface, providing the operator details on the transducer actions. TIM Driver: this hardware allows NCAP to control the TIM, i.e., it is composed by the field busses. It should comply with the transducer network standards (IEEE 1451.2, IEEE 1451.3, IEEE 1451.5, IEEE 1451.6 and IEEE 1451.7). In this project a PC was used to provide for the IEEE 1451.1 functionalities, because PCs are common in industrial automation, making the NCAP implementation easier in this environment. For the software functionalities Java technology was used. 1.1. IEEE 1451.0 — TEDS According to the IEEE 1451.0 the Transducer Electronic Data Sheet (TEDS) should be implemented in an electronic format, involving basically the following information: manufacturer data, transducer address, operation range, calibration information, and other information to describe each transducer function. This data should be accessible to the transducer net operator, in order to favor preventive maintenance. The TEDS can be formed by the fields: Meta-TEDS, channel-TEDS, calibration-TEDS, application-TEDS and extensionTEDS. The Meta-TEDS is the data field common to all transducers connected to the TIM. It has the total description of the transducer network. The TEDS-channel contains the information on the transducer localization (1 a 255). The TEDS-calibration contains information about the transducer last calibration, the calibration parameters and interval, as well as all the constants and methods to convert raw data into engineering units. The standard does not specify how or which software should be used to perform the calibration. The TEDS-Application contains application

Fig. 3. IEEE 1451.5 architecture.

4

E.A. Batista et al. / Computer Standards & Interfaces 34 (2012) 1–13

Table 1 Physical layer addressing. Address value

Wireless technology

0 1 2

IEEE 802.11 (Wi-Fi) Bluetooth Zigbee

specific information, according to the transducer use. It is reserved for future implementations and industrial expansion, according to the IEEE1451.X standards (IEEE 1451.2, IEEE 1451.3, IEEE 1451.5, IEEE 1451.6 and IEEE 1451.7). 1.2. IEEE 1451.2 The IEEE 1451.2 standard specifies the STIM (Smart Transducer Interface Module) functionalities. The first STIM version was defined around 1997, but it is being revised specially regarding the NCAP and STIM connection [2]. In the first version of the standard the STIM is connected to the NCAP, using a 10-wire serial data interface called TII (Transducer Independent Interface). The 10 well defined pins are used to establish the hardware communication protocol between STIM and NCAP, enabling plug-and-play connection mode between NCAP and STIM. The STIM should include A/D and/or D/A converters and address logic circuit, communication driver and direct relation to the TEDS. The STIM is the module in which the transducers are connected and should allow information exchange between these devices and the control network. Recently is under the discussion the possibility of this TII interface to be optional when plug-and-play can be achieved by other means. Interfaces like RS232, SPI and USB can replace the TII [1].

function module involves the software and hardware required to implement the communication protocol between the transducer network and the wireless technology, as well as communication interfaces like RS232 and USB. The signal conditioning is based on electronic instrumentation to allow data acquisition and actuators activation. Table 1 shows the physical layer addressing, according to definitions described in IEEE 1451.5. The use of the IEEE 1451.5 specification allows the communication between a NCAP and WTIM by different ways, forcing the committee to establish the following operation rules: • • • •

A NCAP can register multiple WTIMs. A WTIM should be registered by only one NCAP. A WTIM should have interface to multiple transducers. Allow the communication between WTIMs.

1.4. IDE and CAD tools used to develop the IEEE 1451 platform To implement IEEE 1451 platform hardware, a tool from Altera Corporation is used, the EDA (Electronic Design Automation) Quartus II. The functionalities of the hardware are implemented in the NIOS II processor using its IDE. The embedded module is done with the NIOS II processor implemented in a Cyclone II FPGA, and along with the electronic instrumentation it forms the TIM of this platform. The NCAP logic functions are implemented using the Java technology in NetBeans IDE from Sun Microsystems. This technology is object oriented and allows the portability of the final supervisory system among different operating systems. The tools used here can reduce the development time and provide greater flexibility in Hardware/Software systems construction. 1.5. Quartus II and SOPC Builder

1.3. IEEE 1451.5 — WTIM The IEEE 1451.5 standard was defined in March of 2007, describing the technologies which should be used to implement wireless communication systems. It presents the functional configuration, the services data formats, and message types, for the different established physical layers. Fig. 3 shows the functional configuration independent from the wireless technology used, pointing out that the NCAP functionalities should comply with the descriptions of these articles. On WTIM part (Fig. 3), the Communication Module to the physical interface should comply with one of the technologies defined by IEEE 1451.5, such as: Bluetooth, ZigBee and Wi-Fi. The WTIM

To develop a processor in a FPGA using the Quartus EDA required the use of a tool called SOPC (System-On-a-Programmable-Chip) Builder. On SOPC Builder the designer configures each component before connecting them in the Avalon internal bus. This component sets a module containing a processor and the selected peripherals. The designer needs to finalize the hardware structure in the Quartus II environment. To develop the hardware functionalities NIOS II processor should be programmed in the NIOS II IDE environment, using C/C++ language. The designer should take care of the connections between Avalon bus, selected peripherals and NIOS II processor.

Fig. 4. Configuration of NCAP logic part.

E.A. Batista et al. / Computer Standards & Interfaces 34 (2012) 1–13

5

Fig. 5. RS 232 interface pins.

For every hardware generated by the SOPC Builder, functions and libraries are made available in the NIOS II IDE, so they can be programmed with chosen processor. Among them is system.h, in which all addresses and C/C++ peripheral descriptions are made available, located in the system description folder of the syslib package.

3.

4. 2. Implemented IEEE 1451 platform The IEEE 1451 platform is defined as a hardware and software system that allows the implementation of different configurations of the IEEE 1451 standard, to be used in process automation. It is basically formed by a NCAP and an embedded module. The IEEE 1451 standard intends to fulfill the needs of a system for distributed monitoring and control. Therefore, the NCAP performs the functions of a supervisory system and the embedded module performs the actions of a PLC (Programmable Logic Controller). Fig. 4 shows the platform architecture proposed in this work. It is important to observe that: 1. The NCAP is implemented in a PC, because it has functional blocks compatible to the IEEE 1451.1 definitions, and is common in automation systems. The main blocks implemented in the PC are the processor, operating system, communication interface to the transducer modules, communication interface to the control network. 2. The NCAP Application Programming Interfaces (APIs) were implemented using Java, and their functions include: to provide user application working details (dynamic graphical interfaces and report generation); to allow the TEDS decoding, and to

5.

6. 7.

8.

9. 10.

request information exchange between transducers and control network. The TEDS in the NCAP are implemented using information decoded, given by the TIM. This information is stored in a database and should be linked to the transducers network. So, the NCAP has a specific code table to generate the TEDS. The NCAP logical part allows communication parameters configuration for different wireless technologies (Bluetooth, ZigBee and Wi-Fi). The basic physical connection used was RS232, and for the wireless communication, the PC was linked using specific radios (ZigBee, Wi-Fi and Bluetooth) for the chosen protocol. As the NCAP, the TIM also used RS232, and when using wireless communication, a set of specific radios are used. The TIM should support different protocol communications (ZigBee, Wi-Fi and Bluetooth), as well as the information requested by the operator. The SPC in the TIM is basically done in the NIOS II processor using C/C++. The TEDS in the TIM was programmed in the SDRAM memory, in which the designer described the information of each transducer that composes the application, through a code table. This information is sent to the NCAP to be properly decoded, i.e., the TEDS of the TIM is programmed by the designer according to the application, and this data is interpreted by the NCAP according to item 3. The TIMs API performs the applications logic control and is stored in the SDRAM memory using C/C++. The TIM is defined as STIM for the communication system using cables and as WTIM for the wireless equivalent. The TIM is implemented in the DE2 Cyclone II from Altera, and to develop the

Table 3 Cyclone II resources required to implement a 32 I/O TIM.

Table 2 Basic resources required to implement TIM in Cyclone II FPGA. Logic cell

Dedicated logic register

Memory bit

Pins

Logic cell

Dedicated logic register

Memory bit

Pins

3359,10%

1931.60%

46720.10%

58.12%

3401,01%

1963.60%

46720.10%

90.19%

6

E.A. Batista et al. / Computer Standards & Interfaces 34 (2012) 1–13

Fig. 6. TIM hardware architecture to automate MHI-01.

TIM the SOPC Builder from Quartus II EDA environment is used together with NIOS II IDE, with hardware languages description VHDL and C/C++, respectively. When necessary, circuits for signal conditioning are used as part of the TIM. Details of the implementation of the NCAP and embedded module features are described in Sections 1 and 2, respectively. 2.1. NCAP — IEEE 1451 platform The logical part of this NCAP was developed using Java NetBeans 6.1 IDE from Sun Microsystems, because it attends several IEEE 1451 requirements, such as: to be free, object oriented having polymorphism and inheritance among classes. The main information of the IEEE 1451 platform is documented in NCAP through tutorials and explanatory texts. This NCAP performs tasks like communication to the local network, dynamic graphical interface, communication to the embedded modules, information storage, TEDS implementation, and others. The logical part of the NCAP has three packages containing classes that can be handled individually depending on the application. These packages provide automation level interaction, from reports for MES (Manufacturing Execution Systems) composition to supervisory systems and even communication to control modules. The designer implements a software application based on methods and classes that form the NCAP. On the execution of the IEEE 1451 platform, the designer can select which interface is to be used (IEEE 1451.2 or IEEE 1451.5) and later define the application. If wireless communication is chosen, IEEE 1451 has three options: Bluetooth, ZigBee and Wi-Fi. The operator requests

TEDS information and as a result has descriptions of the transducers network provided by the TIM. The IEEE 1451 platform software part provides information about users and report generation. In Section 1 more details about the logical part of the NCAP are shown, like graphic interface and TEDS implementation. To execute the NCAP, user identification is required, using login and password, and once verified, the operator can request one of the available resources. Report generation indicates when was the last time the operator logged in, and also provides information like which actions and how many cycles were executed. 2.2. TIM IEEE 1451 platform According to IEEE 1451 basic modules to execute a TIM task are CPU, on-chip memory, SDRAM memory, JTAG UART RS interface, LCD (Liquid Crystal Display), Timer, PLL (Phase Locked Loop), all with their respective configurations. These modules compose the TIM Driver, which along with transducers channels and electronic instrumentation, define the TIM platform. Depending on the application, logic blocks coded in VHDL are performed to provide embedded module functions. The application logic control, transducers network information and communication interface program are stored in SDRAM memory. The

Table 4 Cyclone II resources required to implement the TIM to automate the MHI-01 hydraulic kit. Logic cell

Dedicated logic register

Memory bit

Pins

4313,13%

2468.70%

228736.47%

81.17%

E.A. Batista et al. / Computer Standards & Interfaces 34 (2012) 1–13

usage of dynamic memory allocation in the TIM made possible the creation of libraries with standard configurable functions. The JTAG interface allows the synthesis of the hardware on the DE2 board, as well as the tasks execution for long periods. In this project the RS232 interface is the TIM communication driver, and in its configuration the designer may choose baud rate, parity bit and stop bit. With RS232 it was possible to implement an automation system using STIM or WTIM. Fig. 5 shows the logic blocks and respective RS232 pinout in (1) the block responsible for receiving data along with their control signals in (2) is the data transmission block, and in (3) interruption control and receiving and sending data flow is implemented. The LCD device is used to monitor the transducers activities, i.e., monitors the application through the embedded module (TIM). The PLL for the SDRAM may be developed using the SOPC Builder or using a Megafunction, and allows the synchronization of activities between the SDRAM and the processor. The resources to implement the basic hardware for the TIM are presented in Table 2; the percentage means how much of the Cyclone II FPGA was used. It is shown that the amount of resources to form the TIM favors this hardware expansion. The I/O pins are allocated in the expansion bus of the DE2 board, and depend on the number and type of transducers of the application. So, each bus pin can represent a transducer digital channel. If the channel is analog, the number of bits of the A/D conversion forms one channel. Table 3 shows the required resources to implement a TIM formed by 16 input and 16 output digital ports. 2.3. TIM configuration for Cyclone II FPGA A hydraulic didactic kit from HidroEletro Industrial, MHI-01, is used to simulate the typical sensors and actuators of heavy industry machinery. The resources and configurations of a TIM used to automate this kit and to monitor the flow and pressure in an industrial application prototype are described. After deciding the basic software and hardware structure that compose the TIM, the I/O pins and logic blocks were added according to applications requirements. Fig. 6 shows the hardware architecture used to form a TIM. In (1) 4 input channels are represented in a [3..0] vector; in (2) 5 output channels,

7

Table 5 Cyclone II resources required to implement the TIM used to monitor flow and pressure. Logic cell

Dedicated logic register

Memory bit

Pins

3467,10%

1946.60%

46720.10%

88.19%

and in (3) the PLL configuration. The resource usage is presented in Table 4. Another simulated process is an industrial processes flow and pressure monitoring of a compressor for a filtering process for Biogas. A total of 16 input pins were used, 8 for the pressure transducers and 8 for the flow measurer. For this monitoring logic blocks described in VHDL were needed, to count and treat the pulses supplied by the sensors. Fig. 7 shows the TIM Driver architecture used to monitor the pressure and flow of the compressor. Table 5 shows the resources used by the TIM in this application. 2.4. NIOS II IDE In the NIOS II IDE, hardware functionalities of this IEEE 1451 platform can be chosen, based on a pre-project developed. The preprojects are selected according to hardware operation requirements and should have libraries and functions to help the designer in the hardware programming. These pre-projects are formed basically by XML and C/C++ programs, containing basic information about hardware properties. For this platform, a pre-project called IEEE1451 was developed, implementing RS232 libraries and functions, TEDS construction, TEDS communication protocol description, and also made available the RTOS microC/OS-II and functions for interruption handling. The 1451 pre-project is formed by the following programs: ieee1451.h TEDS.h, ProtocolTEDS.h, IEEE1451.c, readme and template.xml. In IEEE1451.c program, a basic application is developed using the functions for serial communication, information LCD writing, which should help designers in the usage of 1451 preproject. In this program, the main() function is found and should also include the libraries ieee1451.h and TEDS.h.

Fig. 7. Embedded module (TIM) used to measure a compressor flow and pressure.

8

E.A. Batista et al. / Computer Standards & Interfaces 34 (2012) 1–13

Fig. 8. Insertion of IEEE 1451 pre-project in NIOS II IDE.

Fig. 9. IEEE 1451 library implementation.

E.A. Batista et al. / Computer Standards & Interfaces 34 (2012) 1–13

9

Fig. 10. TEDS composition to be sent to NCAP.

In readme, file information about TIM tasks from the 1451 platform were inserted, as well as a brief description of the pre-project used for this platform. Fig. 8 shows information that can be viewed when the designer selects the 1451 pre-project, also found on the template.xml, including: 1. Selection of the IEEE 1451 pre-project; 2. A brief description of the pre-project should be available to the users; 3. The main functions used on the pre-project are properly shown in a specific field; 4. A selection of the TIM Driver CPU, as well as these pre-project descriptions. The ieee1451.h file has functions that implement interruption processes according to the number of bits of the reading channels (sensors), allowing events detection that occur in the transducer channel as shown in Fig. 9. The TEDS.h library executes functions that allow insertions of manufacturer code, transducers type, and working range of each transducer. So, TEDS library helps the designer to describe the TEDS to be sent to the NCAP. The instructions used to form the TEDS, i.e., the codes for each information, are found in library TEDS Protocol. These codes are proposed in this platform to make the description of TEDS easier. Fig. 10 shows a part of TEDS.h library with specific configuration.

Fig. 11. TIM used to MHI-01 kit automation.

3. IEEE 1451 platform test This section describes the use of this IEEE 1451 platform to automate a hydraulic didactic kit used to simulate the command of heavy industry machinery, and to monitor flow and pressure of a compressor used in Biogas processing.

3.1. Hydraulic automation kit The MHI-01 Hydraulic kit from HidroEletro Industrial has the following transducers: two end-of-course sensors, two inductive sensors and five solenoids, which are activated by 24 DC Volts signal, while the hydraulic kit pump is connected directly to 127 AC Volts. This IEEE 1451 platform was used to automate the kit actions, each with its own logic control inserted in the TIM processor. The NCAP graphic interfaces and the channels that form this TIM were developed to meet the MHI-01 actions. The remainder of the 1451 platform is formed by the electronic instrumentation needed for the application, with the electronic conditioning circuits connected to the embedded module to complete the TIM. Fig. 11 shows the TIM used to automate the MHI-01, with the necessary circuits to amplify

Fig. 12. MHI-01 hydraulic kit automation according to IEEE 1451 standard.

10

E.A. Batista et al. / Computer Standards & Interfaces 34 (2012) 1–13

Fig. 13. TEDS description for MHI-01 hydraulic system.

Fig. 15. Monitoring of MHI-01 transducers using TIM.

the signal to activate the solenoids and to condition the signal from the sensors (1), and shows the embedded module (2). The structure used to automate the hydraulic kit and the IEEE 1451 platform is shown in Fig. 12. On the NCAP the operator should select which 1451 interface to use (1451.2 or 1451.5), and also should define which action and how many cycles will be performed. On the TEDS menu, the operator requests information from transducer network where the MHI-01 is inserted. These data are stored in a database, forming the TEDS. When an operator requests a report, the following information are shown: TEDS description, operator name, job execution date, action identification, and how many cycles were performed by that operator. In TEDS assembly on the NCAP occurs the decoding of the data sent from the TIM, i.e., the codes are defined by the designer in the infoTEDS.h library. Fig. 13 shows a TEDS generation screen, according

to the transducer network of the MHI-01. During the action execution, the operator observes in real time the movement of hydraulic pistons, according to the control logic. A green color indicates that the actuator is activated, while red indicates not activated. The panel presented in Fig. 14 shows the monitoring of the sensor actions; likewise, green indicates an active sensor, while red indicates not active. Fig. 14 shows some screens produced during the MHI-01 automation. The graphic shows experiments and number of cycles executed. The operator can also monitor the actions taken in the MHI-01 kit through the LCD screen, as shown in Fig. 15. The MHI-01 automation was conducted both with wireless and wired channels. The first option used RS232/RS485 converters to expand the reach between the NCAP and the TIM. For the wireless option three options were tested, ZigBee (Xbee) [16], Bluetooth (BTS1009C) [17] and Wi-Fi (INT550 RS232) [18]. Both configurations are shown in Fig. 16.

Fig. 14. NCAP main screen for MHI-01 automation.

E.A. Batista et al. / Computer Standards & Interfaces 34 (2012) 1–13

11

Fig. 16. IEEE 1451.2 and IEEE 1451.5 interfaces configuration.

3.2. Flow and pressure compressor automation A prototype used to measure pressure and flow of a compressor using this IEEE 1451 platform is shown in Fig. 17. This prototype required the design of electronic circuits to implement the TIM. This platform will be installed in a sewage company to automate a Biogas filtering system. In Fig. 17 the system components can be visualized. Component number 1 is the flow measurer; component number 2 is the pressure transmitter; component number 3 is the flow measurer signal,

component number 4 is the graphic used for pressure monitoring requested by the operator and component number 5 is the PC where the NCAP functions were implemented. The electronic circuits that form the TIM convert 4 to 20 mA to 1 to 5 V, and also convert analogical to digital signals. The TEDS request generates a description of the transducers on the NCAP used to measure the compressors flow and pressure, as shown in Fig. 18. Fig. 19 shows the values for the flow and pressure that were collected according to the scheme presented in Fig. 17.

Fig. 17. IEEE 1451 platform used to measure pressure.

12

E.A. Batista et al. / Computer Standards & Interfaces 34 (2012) 1–13

complex activities, making the use of FPGA in industrial applications attractive to design an intelligent instrumentation system. The electronic instrumentation was developed according to each application, and is part of the TIM in the general architecture of the IEEE 1451 standard. The platform developed here has been used by this research group to automate several different processes, such as home (domotics), greenhouse model and Biogas filtering, and is continually updated and improved [19]. 4. Conclusions and future work

Fig. 18. TEDS request results.

3.3. Analysis of results The IEEE 1451 platform is formed by the NCAP logic and an embedded module that implements the process automation according to the IEEE 1451 standard. The implementation of the embedded module using Quartus II and SOPC Builder makes easier the development of complex hardware. The insertion of I/O channels in the embedded module (TIM Driver) is flexible and easily configurable. The resources used from the Cyclone II FPGA to implement the TIM were relatively low, proving the possibility for this type of devices to be used in control and automation. The embedded module was formed by a NIOS II processor, to perform tasks like: TEDS implementation, control logic programming in C/C++, insertion of a RTOS (Real Time Operating System), interrupt handling and RS232 serial interface communication. The NIOS II processor has resources that provide good performance on

The implementation of the IEEE 1451 platform using reconfigurable logic and Java technology meets fundamental requirements of the IEEE 1451 standard. The NCAP from the implemented IEEE 1451 platform has characteristics of a SCADA software and the hardware (TIM) with NIOS II processor has the functionalities of a control module. This system can be used as basis for automating different processes, either with wired or wireless communication. The TIM is formed by an embedded module developed using EDA tool, allowing a rapid and flexible prototyping. Specifically for this IEEE 1451 platform, the interfaces IEEE 1451.0, IEEE 1451.1, IEEE 1451.2 and IEEE 1451.5 were implemented. The applicability of the NIOS II processor to form the TIM made possible a high level logic control development, interruption handling and the TEDS coding, and in all the cases specific C language functions and libraries were implemented. The TEDS was coded in NIOS II IDE, and through a request in NCAP, the operator can obtain information from the transducers network. To provide TEDS flexibility, a set of codes were created for manufacturers, working range, and transducer type. Later the NCAP decodes this information from the TEDS and makes it available in a database. In current version of this platform, the standards IEEE 1451.0, IEEE 1451.1 IEEE 1451.2 and IEEE 1451.5 were implemented. For the next versions also the interfaces IEEE 1451.3 and IEEE 1451.6 will be implemented. The embedded module was tested also with supervisory software Elipse SCADA, proving TIM flexibility, and for the next test, the communication of this TIM to other supervisory programs will be

Fig. 19. Real-time collected data.

E.A. Batista et al. / Computer Standards & Interfaces 34 (2012) 1–13

tested. The resources used to implement the TIM in the Cyclone II FPGA allow the insertion of logic blocks to turn this embedded module more applicable. This way, it will be possible to supply for this 1451 platform libraries to implement control algorithms, such as PID (Proportional Derivative Integrative), PID Fuzzy, image processing, FFT, Field bus protocols and others. With this platform, this research group intends to supply a flexible system, formed by attractive technologies and tools to implement an intelligent transducer network, with a standardized interface, according to IEEE 1451 Specifications. References [1] E.Y. Song, K. Lee, Understanding IEEE 1451-networked smart transducer interface standard — what is a smart transducer? IEEE Instrumentation and Measurement Magazine 11 (2008) 11–17. [2] K. Lee, IEEE 1451: a standard in support of smart transducer networking, Proceedings of 17th Instrumentation and Measurement Technology Conference, Vol. 2, IEEE, Baltimore, USA, 2000, pp. 525–528. [3] NIST, The proposed IEEE 1451.6 standard, http://grouper.ieee.org/groups/1451/6 2010 accessed in August, 2010. [4] NIST, Draft standard for a smart transducer interface for sensors and actuators — common functions, communications protocols and transducer electronic data sheets (teds) formats, http://grouper.ieee.org/groups/1451/0 2010 accessed in August, 2010. [5] K. Lee, E.Y. Song, UML model for the IEEE 1451.1 standard, Proceedings of 20th Instrumentation and Measurement Technology Conference, Vol. 2, IEEE, Vail, USA, 2003, pp. 1587–1592. [6] D. Wobschall, W.S. Port, A smart RTD temperature sensor with a prototype IEEE 1451.2 internet interface, Proceedings of Sensors for Industry Conference, IEEE, New Orleans, USA, 2004, pp. 183–186. [7] L. Bissi, A. Scorzoni, P. Placidi, L. Marrocchi, M. Bennati, S. Zampolli, L. Masini, I. Elmi, G. Cardinali, A low-cost distributed measurement system based on gas smart sensors for environmental monitoring, Proceedings of International Conference on Sensing Technology, IEEE, Palmerston North, New Zealand, 2005, pp. 301–306. [8] NIST, P1451.3 working group, http://www.nist.gov/el/isd/ieee/1451group3.cfm Aug. 2010 accessed in August, 2010. [9] E.Y. Song, K. Lee, An implementation of the proposed IEEE 1451.0 and 1451.5 standards, Proceedings of Sensor Application Symposium, IEEE, Houston, Texas, USA, 2006, pp. 72–77. [10] Sensors Portal, IEEE 1451.7 transducers to radio frequency identification (RFID) systems communication protocols and transducer electronic data sheet formats, http://www.sensorsportal.com/HTML/standard_7.htm 2010 accessed in August, 2010. [11] M. Sveda, R. Vrba, Sensor networking, Proceedings of Engineering of Computer Based Systems, IEEE, Washington D. C., USA, 2001, pp. 262–268. [12] V. Randal, Software development environment for prototyping ieee 1451 smart sensors, Proceedings of Sensors Applications Symposium, IEEE, San Diego, California, USA, 2007, pp. 1–5. [13] R.L. Oostdyk, C.T. Mata, J.M. Perotti, A kennedy space center implementation of ieee 1451 networked smart sensors and lessons learned, Proceedings of Aerospace Conference, IEEE, Big Sky, Montana, USA, 2006. [14] F. Tani, Proposta de desenvolvimento de transdutores inteligentes baseados na norma IEEE 1451 aplicados a redes LonWorks, Master's thesis, Polytechnic School, University of Sao Paulo, Sao Paulo, Brazil (2007). [15] S.R. Rossi, E.A. Batista, A.A. de Carvalho, A.C.R. da Silva, C. Kitano, T.A.S. Filho, L. Guardalben, T.A. Prado, R.P. Ferraz, L.A.P. Marçal, Open and standardized tools for smart transducer networking, Proceedings of Instrumentation and Measurement Technology Conference, Vol. 6, IEEE, Ottawa, Canada, 2005, pp. 1792–1796. [16] Zigbee Alliance, Zigbee standards overview, http://www.zigbee.org/Standards/ Overview.aspx 2010 accessed in December, 2010. [17] Bluetooth SIG, Bluetooth overview, http://www.bluetooth.org 2010 accessed in December, 2010. [18] Wi-Fi Alliance, Wi-fi articles, http://www.wi-fi.org/knowledge_center_overview. php?type=7 2010 accessed in December, 2010. [19] E.A. Batista, A.C.R. da Silva, L. Gonda, M.C. Pereira, I. da Silva, W.M. Ferreira, F. D'Elia, IEEE 1451 based multi-interface module (i2m) for industrial automation, Proceedings of Sensors Applications Symposium, IEEE, Atlanta, GA, USA, 2008, pp. 12–14.

Edson A. Batista is an undergraduate of Electrical Engineering at University of Sao Paulo State (UNESP), Brazil and obtained his Ph.D. degree from University of Sao Paulo State (UNESP) (2009). He is currently a professor at Electrical Engineering Department of UFMS and his research area of interest includes: development of embedded systems using FPGA, industrialautomation in accordance with IEEE 1451 standard and eletronic driving of electric machinery. He has an experience in applications using FPGA, NIOS IIprocessor, electronic instrumentation and development of monitoring software.

13

Luciano Gonda received his B.S. and M.S. degrees in Computer Science from Federal University of MatoGrosso do Sul(UFMS), Campo Grande-MS, Brazil, in 1999 and 2004, respectively. In 2010, he received his Ph.D. degree in Electrical Engineering from University of Sao Paulo (USP), Sao Paulo, Brazil. He is currently a professor at College of Computing in UFMS. His research interests include Wireless Sensor Networks, Parallel Algorithms and Distributed Systems.

Alexandre C. R. da Silva received the degree in Electrical Engineering from the University of Mogi das Cruzes (UMC), Brazil, in 1984, and the M.Sc. and Ph.D. degrees in Electrical Engineering from the University of Campinas (UNICAMP), Brazil, in 1989 and 2003, respectively. In 2003, he received the degree of Free Lecture from the University of São Paulo State (UNESP) and in 2007 developed a post-graduate stage at University of Limerick, Ireland. He is currently involved with synthesis tools for mixed-signal circuits, embedded systems and IEEE 1451 Standard applications. He is an Associate Professor and researcher within the Department of Electrical Engineering of the College of Engineering (FEIS) at the University of São Paulo State (UNESP). His research interests include analysis and synthesis of mixed-signal circuits, embedded systems, smart transducer networks, hardware description languages and Petri Net.

Silvano R. Rossi received the B.Sc. in Electro-Mechanical Engineering from the Center of Buenos Aires Province National University (UNCPBA), Argentine, in 1999, and the Ph.D. degree in Electrical Engineering from the University of São Paulo State (UNESP), Brazil, in 2005. He is currently involved with instrumentation systems and IEEE 1451 Standard applications. He is a professor at the Department of Electro-Mechanical Engineering in the Center of Buenos Aires Province National University, and researcher member of the INTELYMEC group in the same university. His research interests include instrumentation systems and measurements, smart transducer networks, autonomous vehicles and digital systems.

Aparecido A. de Carvalho was born in Bebedouro, SP, Brazil. He received the B.Sc. in Electrical Engineering in 1976 from the University of São Paulo, the M.Sc. degree in Biomedical Engineering in 1979 from the Federal University of Rio deJaneiro, and the Ph.D. in Applied Physics from the University of São Paulo (USP). In 1993 and 1994 he was an honorary fellow at the Department of Computer and Electrical Engineering of the University of WisconsinMadison, granted by FAPESP (Brazil). He is now a professor at the São Paulo State University (UNESP), Campus of Ilha Solteira, Brazil. His research interests include sensors and electronic instrumentation.

Carlos E. Cugnasca received his B.S., M.S., and Ph.D. degrees in electrical engineering from the University of São Paulo (USP), São Paulo, Brazil, in 1980, 1988, and 1992, respectively. In October 2002, he received his habilitation degree ("Livre-Docência") from USP. He is currently an Associate Professor at the Computing Engineering and Digital Systems Department of Escola Politécnica, University of São Paulo. He has been a researcher at the Agricultural Automation Laboratory, USP, São Paulo, Brazil, since 1989. He is the editor-in-chief of "Revista Brasileira de Agroinformática", Journal of the Brazilian Society of Agroinformatics, and a member of ISOBUS Brazilian Task Force. His research interests include network control, wireless sensor networks, pervasive computing, environment monitoring, and agricultural automation. He has authored/coauthored over 200 publications in these areas.