VHDL Implementation of a communication interface for integrated MEMS
- 145 Downloads
The main objective of this paper is to develop a distributed architecture for integrating micro-electromechanical system (MEMS or microsystem) based on a hierarchical communications system governed by a master node. A MEM integrates a sensor with its signal conditioner and communications interface, thus reducing mass, volume and power consumption. In pursuing this objective, we developed an interface to connect MEMS on a sensor or microinstrument network. Interface model was developed using VHSIC hardware description language (VHDL). The implemented model or intellectual property (IP) core can be easily added to the microsystem or MEM. The core thus developed contains an interface file system (IFS) that supplies all the information related to the micro-system that we wish to connect to the network, allowing the specific characteristics to be isolated to the micro-instrument. The IFS allows all the nodes to have the same interface from the network point of view. In order to support complexity management and composability of the microinstrument, the IFS has a real-time service interface and a configuration interface. A functional characteristic of this configuration interface is the automatic new node integration or plug and play on network. The design was implemented in a field programmable gate array (FPGA) and was successfully tested. The FPGA implementation makes the designed nodes small-size, flexible, customizable, reconfigurable or reprogrammable with advantages of well-customized, cost-effective, integration, accessibility and expandability. The VHDL hardware solution is a key feature for size reduction. The system can be resized according to its needs taking advantages of the VHDL configurability.
KeywordsVHDL FPGA Communication protocol Distributed architecture Smart sensors MEMS
Advances in our understanding of silicon and microcircuit manufacturing technologies have brought about an increasingly greater integration of functions on a wafer or on circuits with a common support. These breakthroughs have led to the development of sensors that are able to perform functions instead of simply producing a signal based on a physical parameter, thus facilitating distributed control. MEMS offer many advantages, including reduced mass, volume and power consumption, more features and simpler architectures. The extensive variety of these characteristics suggest that the widespread application of these “micro-sensors” would be feasible if a way to lower costs and simplify the electronic interface were found (Bartek 1998; Ferrer and Lorente 2003)
Sensing devices were traditionally limited to measuring local parameters. These sensors were usually separated spatially when geographical coverage was needed and they had to be connected to a processor with a point-to-point connection. The availability of MEMS has increased demand for distributed architectures. This new class of device (smart sensors) requires a new design methodology for instruments based on a system of sensors. Such designs are simpler, cheaper and faster, and the resulting systems are more scalable and offer more features than traditional systems.
These advantages are obtained by providing the sensor with two characteristics: (1) the ability to compute and, (2) a network interface. Smart sensors in a measurement and control system reduce the load on PC controllers and increase reliability. The evolution in sensor technology has led to a device, which is now capable of independently performing tasks such as signal conditioning, linearity correction, unit conversion, self diagnostics and plug and play. Moreover, the network interface allows for the connection of a large number of smart sensor nodes in a distributed measurement or control system, with a reduced system cost.
The technical requirements for a sensor network vary: the communications service must guarantee real-time data transmission at predetermined intervals while minimizing delays, the interface should be as simple as possible and the system should be easily expandable. At the same time the sensor network needs to minimize purchase and maintenance costs (Kopetz et al. 2000; Bosse et al. 1996).
An effort has already been made to settle on a network interface for smart transducers via the IEEE1451 standard (Lee 2000; IEEE 1997, 1999). However, this standard contains a large number of communication lines. Our approach implements a network interface for smart transducers based on a time-triggered architecture (TTA) (Kopetz and Bauer 2003).
Our goal in this paper is to implement a communications interface that allows a MEMS integrated in a local bus (through a master node) to be connected with a high-level micro-instrumentation communications bus.
The rest of the paper is organized as follows: Sect. 2 gives an overview on the communication interfaces and features of smart field-buses. Section 3 describes the design of a distributed architecture using a smart transducer interface and the time-triggered protocol class A (TTP/A) protocol. The implemented plug and play functionality is descried in Sect. 4 while Sect. 5 explains the user interface. Section 6 compares the implemented protocol with the original. Experimental results and conclusions are offered in Sect. 7.
2 Sensor interface, definition and properties
An interface is defined as the boundary between two information-exchanging systems. This exchange is only possible if the connected systems share the same concepts and rules. The design of the distributed system in this paper includes a cluster made up of sensors, actuators and processing nodes that are connected through a specific communications medium.
2.2 Flow control
In Fig. 2a, the control signal is established by data source (A). This method is suitable for the sender, but the receiver must constantly check for a data transmission, which can arrive at any time. Push-based communications form the basic mechanism in event-triggered systems.
Figure 2b shows how the data flow is controlled by the data sink (pull method). Whenever the sink wants a specific piece of information, the sender must reply to the petition. This approach facilitates the receiver’s task, but the sender must now be on the lookout for incoming petitions. Pull-based communications form the basic mechanism in client-server systems.
Lastly, Fig. 2c presents a time-triggered communications model where the flow control is executed at predetermined global times.
All of these three communication methods translate into resource costs and cause design problems, however, the time-triggered communication is the least expensive.
Values are stored in memory and can be interpreted as status messages until their contents are updated and overwritten. Possible conflicts between simultaneous memory read-write operations are avoided by managing the memory with a time-triggered protocol. One feature in this type of architecture is that all the nodes know the transmission formats and have access to the same system clock, thus every component knows the instant in which the protocol updates the memory.
This smart transducer interface using IFS has the advantage of encapsulating and isolating internal complexity.
2.3 Internet connectivity
Connecting an industrial control system across internet offers numerous advantages, such as the remote monitoring of an industrial plant, fault diagnostics and correction from anywhere in the world, etc. Nevertheless, current Internet technology is faced with two problems: security and unpredictable connectivity. The security issue has made significant advances thanks to the growing interest in developing e-commerce.
The implementation of an event-based system over the Internet is clearly an inadequate approach, given the difficulties in the synchronization between the sender and the receiver. In a time-triggered system, however, the loss or delay of a message would only result in the unavailability of the system’s current state until the message’s arrival or until the next transmission interval.
2.4 Plug and play
The protocol can support plug and play functionality. In this case, the node identification and the configuration programming rely on the field bus network level.
3 Description and design of the smart instrumentation interface
3.1 Architecture model
Well-defined interfaces are introduced between these levels. A smart transducer interface handles data flow from node to cluster level and the cluster level presents results of all the instruments to the instrument master. The motivation for the introduction of these levels is a reduction of system complexity at cluster and control application in the instrument master and the possibility of hardware reuse or the implementation of the levels in different hardware technologies.
At the sensor level, all the transducers in the microinstrument are connected to a controller using a communication bus called IBIS (Ferrer and Lorente 2003; Lorente et al 2004; Rodriguez et al. 2005). The IBIS bus allows up to 32 transducers to be connected, and is a modification of the IS2 bus. This change in bus design brought about increased connectivity at a reduced cost. The IBIS master manages communication with transducers. An interface was designed and implemented to integrate the transducer level to the proposed architecture model. This microinstrumentation interface is based on the time-triggered master-slave protocol (TTP/A) (Kopetz and Bauer 2003) to obtain the standardization of the smart microinstrument interface and the resultant benefits. We chose this protocol because contains an IFS that easily identifies the particular characteristics of each transducer or microinstrument from the instrument master point of view. In effect, the microinstrumentation interface acts as a glue between microinstruments and control application (instrument master).
3.2 Principles of operation
The interface protocol is controlled by an active master (instrument master in Fig. 4) that supplies the synchronization to all the slave nodes (up to 255). The communication takes place through one wire, which minimizes the connections between components and, consequently, the size of the micro-instrument. This method also facilitates fiber optics based communications
Master-slave round. This round contains two frames. The first frame is for control and is sent by the master and includes several fields. One of these fields is the address of the slave with which it wants to communicate. The second frame is for the slave’s response. This round is used for reading from or writing to the memory acting as the interface with the slave node’s sensor. Plug and play functionality uses these master-slave rounds to identify the new nodes, to obtain documentation and to download the new configuration.
Multi-user round. This round begins with a fireworks byte from the master and continues with data frames from previously specified nodes. These rounds are periodic and are used to transmit observations to the master node. Master-slave rounds are used in the programming of these multi-partner rounds. Six different multi-user rounds can be programmed.
Each round is described in a round descriptor list (RODL) stored in every node into a structure called IFS (see Fig. 3). RODL files can be modified using master-slave rounds.
3.3 Hardware requirements
3.4 Description of communication
4 Node integration
The master controller not only manages the bus communication in our case but also includes a hardware baptism algorithm that performs a binary search on all node identifiers to obtain the documentation number. The master has to store three 32 bit integer variables, lo, hi, and the comparison identifier ci. The identifier of a node is found using iterations of the binary search used by Elmenreich et al. 2002 and the master assigns a new alias.
File 8 organization (documentation and configuration file) for slave nodes
Actual alias (FF)
Comparison identifier received
\( \vdots \)
\( \vdots \)
Identifier comparison iteration ends when there are no nodes writing a data frame with 00 in the last slave round. The master then obtains the documentation number and changes the node alias of the particular node from unbaptized (FF) to its new alias overwriting record 2 of file 8 in a baptize operation.
5 Programming and monitoring
6 Comparison of the Ttp/A with the protocol implemented
The implemented protocol resulted in a simplification of the needed TTP/A protocol to adapt its integration in a smart node. In both protocols each node has a unique address and the network can have up to 255 nodes. The main difference stems from the size of the interface memory. In the TTP/A protocol, the IFS can have a variable size of up to 64 kbytes of maximum capacity while in our protocol the interface memory has a fixed 1 kbyte size. Two objectives are satisfied: the first is to reduce the occupied space and the second is to simplify the protocol itself. The TTP/A protocol includes error control, but that function is simplified in our case in order to reduce the protocol size, the duration for baptizing task and to improve its integration into the smart node.
The documentation and configuration file has been integrated in the same file of the IFS (file 08). This distribution permits the use of one additional file for other tasks such as data sensor storing or round information. Furthermore, the documentation number of slaves is only 4 byte size. TTP/A original protocol uses 8 bytes for this number. As a result, each binary search in the baptize algorithm only needs four bus interactions instead of six.
TTP/A protocols are implemented on microcontrollers (PIC 16F874, Atmel AVR AT90S2313, Motorola) (Obermaisser 2001; Trödhandl 2002) using C or Assembler languages, thus these software implementations are technology-dependent. The hardware implementation using VDHL developed in this paper, however, is technology-independent.
7 Experimental results
A simple prototype of the protocol compliant smart sensor was implemented in a FPGA. The target FPGA for a master unit and a slave unit is Xilinx’s XC3S200-FT256 device, which belongs to the Xilinx Spartan-3 family. The Spartan-3 board has a 50 MHz free-running oscillator to drive the custom logics. All custom logics for this FPGA are designed to operate at this clock frequency. The XC3S200-FT256 device has 1,920 slices, 12 block-RAM.
All of the digital modules from the smart sensor were developed in VHDL and implemented in FPGA. The master unit has three blocks: a protocol controller, a Tx/Rx unit and an interface module. The slaves units have four blocks because they need a hardware divisor for synchronization tasks. For the master module the design occupied 378 slices (just 19% for the logic) and one block-RAM for the interface memory (8%). The slave module used 485 slices (25%) and one block-RAM. The theoretical maximum operating frequency was 84.5 MHz, although in practice, satisfactory results were obtained with the 50 MHz board frequency.
Each binary search in the baptize algorithm only needs four bus interactions instead of six. The original protocol needs additional master-slave rounds to send the other 4 bytes of ci number to the slaves.
The original protocol needs 64 iterations to obtain the documentation number of an unbaptized slave. The proposed variation only needs 32 iterations.
We developed a communications interface for smart transducers based on an interface file system, which conceals the micro-instrument’s properties and internal complexities by decoupling the application from the communications systems. The prototype includes a software tool to monitor and configure the network with a PC.
One advantage in the design is the ease in which the interface can be added to the micro-instrument. Distributed architecture can be used to easily connect MEMS with this interface.
The proposed architecture boasts a single wire bus, which minimizes the interconnection between components, reduces overall size and lowers the cost of implementing the network. The system is developed with VHDL and is technology-independent. These characteristics allow the smart instrument to be small-sized, flexible, customized, reconfigurable and reprogrammable. Consequently the proposed smart instrument is ideal for distributed measurement and control system applications. Clear advantages are seen in its well-customized, cost-effective, integration, accessibility and expandability properties. For example, the distributed architecture with the software tool designed in Visual C# can be used in greenhouses to detect pressure, temperature, humidity and luminosity by using smart sensor. Water actuators can also be controlled, in addition to other tasks.
Additionally the design, based on a time-triggered architecture, allows the sensor/actuator network to be easily controlled or remotely monitored via Internet.
This work has been supported by “Programa Nacional de Diseño y Producción Industrial” (Project DPI 2006-07906) of the “Ministerio de Educación y Ciencia” (Spain), and by “European Regional Development Fund” (ERDF).
- Bartek M (1998) “Semi-hybrid” techniques for microsystem integration. In: Proceedings of the Microsystems Symposium, Delft, The Netherlands, pp 17–26Google Scholar
- Bosse E, Roy J, Grenier D (1996) Data fusion concepts applied to a suite of dissimilar sensors. Canadian conference on electrical and computer engineering, pp 692–695Google Scholar
- Elmenreich W, Haidinger W, Peti P, Schneider L (2002) New Node Integration in TTP/A Networks. In: Proceedings of the 20th IASTED international conference on applied informatics, pp 173–178Google Scholar
- Ferrer C, Lorente B (2003), Smart sensors development based on a distributed Bus for microsystems applications. In: Proceedings of the SPIE’s first international symposium on microtechnologies, Gran Canaria, Spain, pp 19–21Google Scholar
- IEEE (1997) IEEE Std 1451.2–1997, Standard for a smart transducer to microprocessor communication protocols and electronics transducer data sheet formats. IEEE Inc., Piscataway, NJ, 1997Google Scholar
- (IEEE 1999) IEEE Std 1451.1–1999, Standard for a smart transducer interface for sensors and actuators—nertwork capable application processor (NCAP) information model, IEEE Inc., Piscataway, NJ, 1997Google Scholar
- Kopetz H, Holzmann M, Elmenreich W (2000) A universal smart transducer interface: TTP/A.In: Proceedings of the 3rd international symposium on object-oriented real-time distributed computing (ISORC), pp 16–23Google Scholar
- Kopetz H, Bauer G (2003), The time-triggered architecture. In: Proceedings of IEEE, pp 112–126Google Scholar
- Kruger A (1997) Interface design for time-triggered real-time system architectures. PhD thesis, Technische Universitat Wien, Institut f¨ur Technische Informatik, ViennaGoogle Scholar
- Lee K (2000) IEEE 1451: A standard in support of smart transducer networking. Instrumentation and measurement technology conference 2000 (IMTC 2000). In: Proceedings of the 17th IEEE, pp 525–528, May 2000Google Scholar
- Lee K (2001) Sensor networking and interface standardization. IEEE international and measurement technology conference, Hungary, pp 147–152Google Scholar
- Lorente B, Oliver J, Ferrer C (2004) IBIS Bus: towards a distributed architecture for MEMS integration. Sensor and actuators A: Physical, pp 470–475Google Scholar
- Obermaisser R (2001) Design and implementation of a smart transducer network. Master’s thesis, Teschnische Universität Wien, AustriaGoogle Scholar
- Rodriguez M, Magdaleno E, Ferrer C, Lorente B, Ayala A (2005), High level communication interface design for integrated MEMS and microinstrument bus. In: Proceedings of SPIE smart sensors, actuators and MEMS II, pp 107–115Google Scholar
- Trödhandl C (2002) Architectural requirements for TTP/A nodes. Master’s thesis, Technische Universität Wien, AustriaGoogle Scholar