This action might not be possible to undo. Are you sure you want to continue?
Reg. No: Topic: Teacher: D.O.S: SMART-TRANSDUCERS Lect. KIRANDEEP KAUR 18/12/08
Recent advances in technology have led to the development of sensors with embedded memory used to store pertinent information related to the sensor such as make, model, serial number and sensitivity. This data may be automatically retrieved and utilized to set up the measurement system. Also, a channel table can be generated that gives correspondence between the signal conditioner channel and the attached sensor. This serves to reduce or eliminate bookkeeping errors associated with a manually generated channel table. The channel table may also list and display all pertinent sensor data, including position and orientation on the test article . The IEEE 1451.4 standard defines interface and communication protocol for such sensors. The data contained in the memory is commonly referred to as the Transducer Electronic Datasheet or TEDS. Accelerometers with integrated electronics (known as IEPE) that contain TEDS have become commonplace in the market, with devices available from a number of manufacturers. These sensors may be effectively applied to test models; however, there is a restriction that the cable run between the signal conditioner and the sensor be limited to 400’ in order to be able to properly read the TEDS. For applications such as weapons test or vibration test on large structures, safety, environment, test article size and other factors often require cable runs in excess of 1000’ that have until now precluded the use of TEDS equipped sensors.
COMMUNICATION DISTANCE LIMITATIONS OF TEDS EEPROM One-wire Electronically Erasable Programmable Read-Only Memory (EEPROM) devices are utilized as the memory for the TEDS. The Dallas Semiconductor DS2430A 256bit EEPROM is commonly embedded in IEPE accelerometers for the TEDS memory and will be the device that we refer to in our discussion for this paper. Referring to , during normal operation, the signal conditioner is connected to the accelerometer output to measure analog data. Data is transferred serially to and from the TEDS device via a protocol that requires a single wire plus a return. For reading and writing data to the EEPROM, the signal conditioner interface contains a TEDS reader, which consists of a current source, a write switch and a receiver. The current source acts to pull down the line to the “open level” whenever the TEDS reader or the 1-wire device does not short it. The length of the cable run to the transducer is determined by how fast the current source can charge the cable capacitance. The DS2430A achieves specified logic levels with a 4mA current source. The “short level” is the value that the line reaches when the TEDS reader shorts it. The 1-wire device short level is approximately 0.8V higher than the TEDS reader short level due to the isolation diode D2 in series with the 1-wire device. This diode is necessary to allow the 1-wire device to share the signal lines with an IEPE transducer.The DS2430A, as with all of the Dallas 1wire devices, has four types of 1-wire signaling: The Reset and Presence pulses (as part of the reset sequence), Write 0, Write 1 and Read data. The DS2430A must be initialized before sending or receiving data. The initialization consists of a reset pulse sent by the TEDS reader, followed by the presence pulse returned by the 1-wire device. After the presence pulse is received, data may be communicated
between the TEDS reader and the DS2430A. Data communication takes place by adhering to strict timing protocols. The timing diagrams for the read and write timing slots are shown in Figures 2 and 3. Communication between the TEDS reader and the 1-wire device for a Read or Write operation is started in an identical manner by initiating a start pulse via TEDS reader switch SW1. For a Write 0 (Figure 2), the pulse length must be a minimum of 60μsec. For a Write 1, the pulse must be a maximum of 15μsec. When SW1 opens, the line is driven to the open level (-5V) by the current source in the TEDS reader. In all cases, the data must be maintained to desired logic levels between 15μsec and 60μsec from the beginning of the start pulse. During a read timing slot SW1 is driven to produce a start pulse that is a minimum of 1μsec in duration. If the 1-wire device wants to deliver logic 1, it does nothing, allowing the line to be driven to the open level by the current source. The line must reach the detection threshold within 15μsec from the beginning of the start pulse or the TEDS reader may erroneously detect logic 0. To deliver logic 0, the 1-wire device must hold the line down with SW2 for a minimum of 15μsec after the beginning of the start pulse. When SW2 opens, the line is driven back to the open level by the current source.The ability of the interface to adhere to the timing slot restrictions will be limited by the time it takes the current source to drive the line high in the presence of any cable capacitance. The cable capacitance, Cc, that can be supported given the charging time, TC, is given by: Cc = Tc I /VL (1) Where I is the charging current of 4mA. Assuming a start pulse of 5μsec, then the current source has TC of 10μsec to drive the line to a valid logic 1 level before the DS2430A begins sampling. VL equals VIH of the 1-wire device
(2.2V) plus the voltage drop of the blocking diode (0.8V) or 3V. The evaluation of Equation (1) with Tc = 10μsec, I = 4mA and VL = 3V predicts a maximum cable capacitance of 0.013μF or 444 feet of 30 pF/ft coaxial cable. Ccmax = (10μsec)(4mA)/(3V) = 0.013μF (2) LONG DISTANCE TEDS Long Distance TEDS (LDTEDS) communication requires that new methods of detection be utilized by the TEDS reader in the signal conditioner in order to differentiate whether the 1-wire device in the transducer is sending a “1” or a “0”. In the discussion above, it is clear that the 4mA current source limits the amount of cable capacitance that is permitted for error free communication. Unfortunately, the only way to send a pulse over a long cable without distorting its width is to provide a higher drive current. We can provide this higher drive current when the TEDS reader must signal to the 1-wire device, but when receiving a signal from the 1-wire device, we must limit the charging current to 4mA to be compliant with DS2430A specifications.
To make long distance communications possible, an analogto-digital converter (ADC) and a digital signal processor (DSP) are introduced to sample the communications interface as shown in Figure 6. We use an ADC to digitize the waveform, and DSP techniques to analyze the data. Referring to Figure 7, after the TEDS reader discharges the cable to the short level, we compute the slope and Y intercept of the voltage versus time line as the cable capacitance charges back to the open level. We use the slope and intercept to compute the 1-wire release time where the line crosses the 1-wire short level. If the release time is less than 15μsec, then a 1 is read from the 1-wire device and if it is greater than 15μsec, then a 0 is read.
To improve noise immunity, we calculate a detection threshold that is unique to each 1-wire device by evaluating the release times associated with the 64-bit ROM in the 1-wire device. The ROM consists of a device ID, device serial number and CRC that contains a mix of 1’s and 0’s. From the data we set the detection threshold to the midpoint of the computed minimum and maximum release times. Subsequently, we evaluate the release time of each bit against the computed detection threshold to determine if the 1-wire data is a 0 or 1.
In order to write data to the 1-wire device over long cable runs, we can provide a current source boost to improve the wire charging time. In our design, the boosted current level is 18mA, which is more than sufficient to drive 1500 feet of 30pF/ft cable to the required logic levels. Assuming that the detection threshold in the 1-wire device is -
2.2V, then the Write 1 trailing edge must reach approximately -3V within 15μsec of the leading edge of the pulse. Examining Figure 8, we see that this is the case, so there will be no problem writing data to a 1-wire device over a1500 feet cable.
In this paper we demonstrate the fundamental communication distance limitations of conventional IEEE 1451.4 TEDS hardware. We propose a model for the limitation and compute a maximum communication distance of 444 feet. We introduce Long Distance TEDS (LDTEDS) as a method of extending communication distances for TEDS
sensors. The LDTEDS circuitry uses an analog to digital converter to digitize the 1-wire read waveforms and utilizes a digital signal processor to determine if the 1-wire device transmits a 0 or 1. We propose a current source boost circuit to enable writing of data to the 1-wire device at long distance. Our circuit can communicate with TEDS sensors at distances out to 1500 feet. LDTEDS is commercially available in two Precision Filters products. The 28334A is a 4-channel dual mode charge/IEPE amplifier and the 28316B is a 16-channel IEPE amplifier/filter. Both products are designed for the company’s 28000 Signal Conditioning System.
The authors wish to acknowledge Mr. Alan Szary for his contributions toward the development of LDTEDS. Finney, S. H., 2004, “Investigation of Precision Filters Hardware Interface to TEDS Sensors”, Precision Filters, Inc. Engineering Report Number 228. IEEE Std 1451.4, 2004, “Standard for A Smart Transducer Interface for Sensors and Actuators—Mixed-Mode Communication Protocols and Transducer Electronic Data Sheet (TEDS) Formats”, The Institute of Electrical and Electronics Engineers, Inc., 3 Park Avenue, New York, NY 10016-5997, USA December 14, 2004. Dallas Semiconductor, 1999, “DS2430A 256-Bit 1-Wire EEPROM Data Sheet” Precision Filters, Inc., 2005, “28316B 16-Channel TEDS, IEPE Accelerometer Conditioner Data Sheet” Precision Filters, Inc., 2005, “28334 Quad Dual Mode Charge/IEPE Conditioner Data Sheet”
A Standardized Smart Transducer Interface
In December 2000 the Object Management Group (OMG) called for a proposal of a smart transducer interface. In response a new standard has been proposed that comprises a time-triggered transport service within the distributed smart transducer subsystem and a well-defined interface to a CORBA environment. This smart transducer standard has been adopted by the OMG in January 2002. The smart transducer interface and the time-triggered transport service have been implemented in the time-triggered fieldbus protocol TTP/A. This paper examines the strengths and weaknesses of the smart transducer interface and presents two case studies. The first case study describes a demonstrator with a robot arm that is instrumented
by smart transducers and a TTP/A fieldbus. The second case study is an autonomous mobile robot instrumented by a TTP/A cluster that orientates itself via a set of heterogenous sensors and decides, based on this sensor data, which way to go. 1 Introduction The design of the network interface for a smart transducer is of great importance. Transducers can come in a great variety with different capabilities from different vendors. A smart transducer interface must thus be very generic to support all present and future types of transducers. However, it must provide some standard functionalities to transmit data in a temporal deterministic manner in a standard data format, provide means for fault tolerance, and enable a smooth integration into a transducer network and its application. A smart transducer interface should conform to a world-wide standard. Such a standard for a realtime communication network has been long sought, but efforts to find one agreed standard have been hampered by vendors, which were reluctant to support such a single common standard in fear of losing some of their competitive advantages . Hence, several different fieldbus solutions have been developed and promoted. Some of these existing solutions have been combined and standardized. In 1994, the two large fieldbus groups ISP (Interoperable Systems Project supported by FisherRosemount, Siemens, Yokogawa, and others) and theWorldFIP (supported by Honeywell, Bailey, and others) joined to form the Fieldbus Foundation (FF). It is the stated objective of the FF to develop a single interoperable fieldbus standard in cooperation
with the International Electrotechnical Commission (IEC) and the Instrumentation Society of America IEC committees met jointly to make the development of an international standard possible. ISA SP50 was the same committee that introduced the 4-20 mA standard back in the 1970s. Meanwhile, other standards for smart transducers were developed. The IEEE 1451.2  standard deals with the specification of interfaces for smart transducers. An idea proposed by this standard is the specification of electronic data sheets to describe the hardware interface and communication protocols of the smart transducer interface model . In December 2000 the Object Management Group (OMG) called for a proposal of a smart transducer interface (STI). In response a new standard has been proposed that comprises a time-triggered transport service within the distributed smart transducer subsystem and a well-defined interface to a CORBA (Common Object Request Broker Architecture) environment. The key feature of the STI is the concept of an Interface File System (IFS) that contains all relevant transducer data. This IFS allows different views of a system, namely a real-time service view, a diagnostic and management view, and a configuration and planning view. The interface concept encompasses a communication model for transparent time-triggered communication. This STI standard has been adopted by the OMG in January 2002. It is the objective of this paper to examine the strengths and weaknesses of the STI standard and to present two case studies showing the capabilities of the smart transducer interface. The rest of the paper is organized as follows:
The following section explains the conceptual model and architecture of the STI. Section 3 introduces the properties of the IFS. Section 4 depicts the proposed time-triggered fieldbus protocol. In section 5 we will describe two case studies, that implemented smart transducer networks based on the STI. Section 6 investigates on the strengths and weaknesses of the STI standard. The paper is concluded in section 7. 2 Conceptual Model This section will introduce the conceptual model of the OMG smart transducers interface . On a abstract level, the purpose of a real-time smart transducer interface is the timely exchange of “observations” of real-time entities between the engaged subsystems across the provided interfaces. A real-time entity is a state variable of interest that has a name and a value at a particular instant. An observation  is thus an atomic triple: <name, observation instant, value>, where name is an element of the common name space of real-time entities, the observation instant is a point in the “time space” and value is an element of the chosen value domain. An observation expresses that the referenced real-time entity possessed the stated value at the indicated instant. A smart transducer (ST) system consists of several clusters with transducer nodes connected to a bus. Each cluster is connected to a CORBA gateway via a master node. One CORBA gateway can interface up to 250 clusters. The master of each cluster is connected to the CORBA gateway through a real-time communication network, which provides a synchronized time to each master. Each cluster can contain up to 250 STs that communicate via
a cluster-wide broadcast communication channel. There may be redundant shadow masters to support fault tolerance. One active master controls the communication within a cluster (in the following sections the term master refers to the active master unless stated otherwise). Since smart transducers are controlled by the master, they are called slave nodes. Figure 1 depicts an example for such a smart transducer system. Access to the smart transducer data is achieved by assigning three different interfaces to each ST node: DM interface: This is a diagnostic and management interface. It establishes a connection to a particular ST node and allows reading or modifying of specific IFS records. Most sensors need parameterization and calibration at startup and continuously collect diagnostic information to support the maintenance activities. For example a remote maintenance console can request diagnostic information from a certain sensor. CP interface: The configuration and planning allows the integration and setup of newly connected nodes. It is used to generate the “glue” in the network that enables the components of the network to interact in the indented function. Usually, the CP interface is not time-critical. RS interface: The real-time service interface performs a periodic communication with predictable timing behavior among the ST nodes. Communicated data is usually data from sensors and for actuators. This view employs sensors for producing periodic observations of real-time entities in the environment. This view supports the normal operation of the sensor.
For example, a temperature sensor periodically sends the observed and locally preprocessed sensor value to the temporal firewall of the master. Since in TTP/A the time interval between sensing the environment and presenting the sensor value at the temporal firewall  of the master is known a priori it is possible to perform a feed forward state estimation of the sensor value at the sensor node in such a way, that the delivered sensor value is a good estimate of the real-time entity’s actual state at the point in time of delivery. Although all transducer nodes are built as smart transducers and contain a physical sensor or actuator, a microcontroller, and a network interface, the hardware requirements for the ST interface are very flexible. The STI supports low-cost implementations of smart transducers, by allowing optional implementation of standard features. Thus, it is possible to fit a minimum STI implementation on an embedded microcontroller with 2k flash memory and 64 bytes of RAM memory . 3 Interface File System The information transfer between a smart transducer and its client is achieved by sharing information that is contained in an internal interface file system (IFS), which is encapsulated in each smart transducer. A time-triggered sensor bus will perform a periodical time-triggered communication to copy data from the IFS to the fieldbus and write received data into the IFS. Thus, the IFS is the source and sink for all communication activities. Furthermore, the IFS acts as a temporal firewall that decouples the local transducer application from the communication activities. It is the task of the communication protocol to
keep consistency among the local copies of the IFS data elements. A predefined communication schedule defines time, origin, and destination of each protocol communication. The instants of updates are specified a priori and known by the communicants. Thus, the IFS acts as a temporally specified interface that decouples the local transducer application from the communication task. Each transducer can contain up to 64 files in its IFS. An IFS file is an index sequential array of up to 256 records. A record has a fixed length of four bytes (32 bits). An IFS record is the smallest addressable unit within a smart transducer system. Every record of an IFS file has a unique hierarchical 3 Fig. 2: Logical Network Structure address (which also serves as the global name of the record) consisting of the concatenation of the cluster name, the logical name, the file name and the record name. The IFS provides a unique address scheme for transducer data, configuration data, self-describing information and internal state reports of a smart transducer . Besides access via the master node, the local applications in the smart transducer nodes are also able to execute a clusterwide application by communicating directly with each other. Figure 2 depicts the network view for such a clusterwide application. As depicted in Figure 3, the IFS of each smart transducer node can be accessed via the RS interface, the DM interface and the CP interface for different purposes. All three interfaces are mapped onto the fieldbus communication protocol, but with different semantics regarding timing and data protection.
4 Fieldbus Communication Protocol A time-triggered transport service following the specification of the STI has been implemented in the time-triggered fieldbus protocol TTP/A. The bus allocation is done by a Time Division Multiple Access (TDMA) scheme. Communication is organized into rounds consisting of several TDMA slots. A slot is the unit for transmission of one byte of data. Data bytes are transmitted in a standard UART format. Each communication round is started by the master with a so-called fireworks byte. The fireworks byte defines the type of the round. The protocol supports eight different firework bytes encoded in a message of one byte using a redundant bit code  supporting error detection. Generally, there are two types of rounds: Multipartner round: This round consists of a configuration dependent number of slots and an assigned sender node for each slot. The configuration of a round is defined in a datastructure called “RODL” (ROund Descriptor List). The RODL defines which node transmits in a certain slot, the operation in each individual slot, and the receiving nodes of a slot. RODLs must be configured in the slave nodes prior to the execution of the corresponding multipartner round. An example for a multipartner round is depicted in Figure 4. Master/slave round: A master/slave round is a special round with a fixed layout that establishes a connection between the master and a particular slave for accessing data of the node’s IFS, e. g. the RODL information. In a master/ slave round the master addresses a data
4 record in the hierarchical IFS address and specifies an action like reading, writing or executing on that record. The master/slave rounds establish the DM and the CP interface to the transducer nodes. The RS interface is provided by periodical multipartner rounds. Master/slave rounds are scheduled periodically between multipartner rounds as depicted in Figure 5 in order to enable maintenance and monitoring activities during system operation without a probe effect. 5 Case Study Implementations 5.1 Robot Arm Fig. 6: Robot Arm As a demonstrator for the STI we built a system with a robot arm . At the application level a human operator can control a prosthetic arm mounted on top of a linear thrust unit (See Figure 6). Simplicity of control for the user is established by the presence of intelligence in the demonstrator. Smart sensors yield information about the environmental conditions allowing avoidance of operating errors and obtaining precise control. Pressure sensors are present for determining the required grip force to grasp an object. No intervention of the human operator is needed to avoid slipping of an object. Motor actuator nodes implement trapezoid excitation for handling of inertia. The demonstrator is equipped with an angle sensor to allow limiting the opening of the elbow. The demonstrator was also intended to investigate partitioning of nodes into distinct clusters. The resulting intercluster communication was required to preserve temporal predictability and capabilities for monitoring, maintenance and configuration.
The demonstrator consists of two clusters (See Figure 7). The first cluster contains the nodes for controlling the motors of the linear thrust units, the elbow and the wrist. The nodes for retrieving the current angle of the elbow and the joystick commands are also placed in this cluster. A shadow master can take over control in case the primary master fails. Both masters are connected to the intercluster bus and act as intermediate systems. In addition to their TTP/A master role, they are slaves of a timetriggered backbone bus. The second cluster contains a node behaving as an interface system for integrating the prosthetic hand into the demonstrator. Two nodes equipped with pressure sensors obtain measurements for grasping objects intelligently. 5.2 Autonomous Mobile Robot: Another implementation of the STI is shown by a model car, that acts as an autonomous robot with sensory inputs . Seventeen nodes were used for building this mobile robot (“smart car”). Some of these nodes are implemented on very small MCUs to demonstrate the possibility of cheap slaves. Other nodes should demonstrate the possibility of complex features like plug & play or reconfiguration. The model comprises a smart car equipped with a suit of pivoted distance sensors, an electric drive and a steering unit. Distance sensors, servo motors for sensor pivoting, driving and steering units are all separate smart transducer nodes. Each node is implemented on a low-cost microcontroller and equipped with an STI. The STI supports the integration of smart transducer nodes with a predictable timing behavior. It is possible to add extra “light” nodes to the car during operation. different operation modes are defined. The STI standard supports up to 6 userdefinable independent communication modes, which support applications running different modes. As long as no obstacles are detected within the sensors’ range the car operates in “rabbit mode”. In this mode the car drives straight forward at full speed
and two infrared sensors are aimed slightly outward the driving direction. The main detection of obstacles relies on two ultrasonic sensors. These are capable to report obstacles straight ahead of the car within a range of about 5m. In case an obstacle is detected the car switches to “turtle mode”. In this mode the car uses a communication schedule where all infrared sensors and pivot servos are serviced. The distance sensors are swivelled around by servo motors so that they are able to scan the area in front of the robot. The sensors generate a value that corresponds to the distance of the object they are aimed at. The data stream provided by the distance sensors is taken over by a data processing node that fuses the perceptions from the distance sensors and the directions they are aimed at with a model of the robot environment. In this model the shapes of obstacles are stored and assigned with a probability value, that decreases with the progression of time and increases when the object is re-scanned. From this data a navigation node calculates the speed and the direction to provide this information to the speed and steering nodes. 6. Discussion: One requirement stated in the call for proposal by the OMG was real-time capability of the smart transducer interface. The STI supports hard real-time communication by introducing a timetriggered communication scheme, that is a priori specified before the RS interface of the system is used. Generally, time-triggered systems require an increased effort in the design phase of the system, but provide an easier verification of the temporal correctness . Since time-triggered systems are designed according to the principle of resource adequacy , it is guaranteed that sufficient computing resources are available to handle the speci6. fied peak load scenario. On the other hand, timetriggered
systems are often blamed for their bad flexibility. The STI overcomes this limitation by introducing means to configure the interaction of the components via the CP interface. The RS interface provides composability, guaranteed timeliness, and hides components’ internals. The DM and CP interfaces involve inherently event-triggered activities, which require an eventtriggered communication service. These interfaces cannot invalidate the temporal behavior of the RS interface and support full access to component internals – as required by a maintenance engineer. The specification of interfaces should be complete and of minimal cognitive complexity. Cognitive complexity can be minimized by restricting interactions via interfaces and by providing access restrictions. The kind of information that must be available via an interface depends on the purpose of the particular interface. For example, a properly designed operational interface hides component internals, thereby allowing a component to form a meaningful abstraction. The corresponding operational interface specification stipulated during architecture design should incorporate a precise specification of a component’s inputs and outputs in both the temporal and value domain. A maintenance engineer on the other hand, might require access to intermediate computational results for locating the origin of an incorrect system behavior. The smart transducer interface (STI) standard meets the requirement for complete interfaces of minimal cognitive complexity by introducing three different types of interfaces of a component. The separation into RS, DM and CP interface is done according to the interface purpose, the necessary level of visibility of component internal information, and the type of the temporal interaction patterns. Such a separation minimizes complexity in contrast to a universal interface incorporating support for all possible interactions. The STI standard also specifies the provision of the three interfaces through a CORBA server. However, currently there is no CORBA architecture for effectively supporting the temporal requirements to establish the RS interface. Current priority-based approaches like Real-time CORBA 
require complete knowledge about all other service requests and their corresponding priority values in the whole CORBA network. However, the availability of a global notion of time allows to record the instant of the acquisition of a real-time entity’s state in each observation. 7. Conclusion We implemented two case studies of the STI. The first case study comprises a demonstrator with a robot arm that is instrumented by a smart transducer network partitioned into two clusters. The second case study is an autonomous mobile robot, that shows the integration of new nodes and efficient communication despite of static communication schedules. The results show, that the STI standard is an interesting option for various sensor network applications. The STI provides many features that are required by a fieldbus applications for automotive or automation industries. Supported features are the real-time capability, the encapsulation of the node’s internals, and a universal address space with the interface file system. The STI can be implemented on low-cost Commercial-off-the-Shelf (COTS) hardware and supports various bus media types. 8. Acknowledgments This work was supported in part by the Austrian Ministry of Science, project TTSB and by the European IST project DSoS under contract No IST-1999- 11585.
Smart Transducers – Depth Speed Temperature Connect to your NMEA displays with these digital transducers
The Actisense™ Active Depth/Speed/ Temperature transducer is the best solution for supplying NMEA
Depth, Speed/Log and Temperature to an NMEA 0183 compatible chart plotter, radar, or on board PC/Laptop. Our industry proven depth sounder algorithm has the best-in-class seabed tracking. Couple that to the processing electronics only a centimetre from the depth transducer, and the performance obtained is truly the best possible, tracking the seabed down to 0.3m (1 foot). 100W peak depth power enables a maximum depth range of 100m (330 feet) under optimum conditions. The data interface is configured as an NMEA 0183 interface, but can operate as a fully bidirectional RS485 interface for customised applications, such as on board multiple depth sounder networks. 235 kHz depth transducer frequency for enhanced interference rejection from surface noise and other transducers nearby. A built-in Log transducer and Temperature thermistor (certain models), allow additional data to be provided over the NMEA network, giving a cable saving when those extra measurements are required. Easy reprogramming is possible using free software, available on the Actisense website, and the Actisens RS485 PC interface. The transducer’s software may be updated as many times as required with the very latest software enhancements, or special purpose software such as the fish-finder/hydrograph software upgrade. NMEA display software for a Windows PC, will also be available from the
Actisens website to display the fish finder/hydrograph data from specific upgraded NMEA Active DST transducers.
The interfacing of smart transducers to a wireless medium is an attractive solution for reconfigurable networks but this has not been explored extensively for small-span networks using existing wireless technology. Wireless sensors today are equipped with RF capability at the physical layer but do not lend themselves to cooperative networking. Smart transducer interfaces have recently been standardized to enable the interoperability of smart transducers with a variety of instruments, microprocessor based systems, fieldbus and control networks and using this interface with an existing wireless networking technology provides a quick, cost-effective, ubiquitous and simple solution for reconfigurable, cooperative wireless smart transducer networks. 2 In order to enable the smart transducer interface to operate with a wireless networking technology we propose a “network infrastructure” in this thesis and investigate the definition and design of a software model for such an infrastructure. The network communication models standardized by the IEEE 1451 and the different wireless alternatives that may be adopted for autonomous smart transducer networks are examined and evaluated. The Bluetooth wireless technology is chosen for the wireless interface and the OBEX Session protocol is used for network communication between the smart transducers in a client-server network architecture. The software model for the network communication is described via behavioral VHDL constructs and
simulation outputs corresponding to the network operation are obtained. 3 industry defines all seven layers of the OSI model and is different on account of its peertopeer architecture. Profibus, HART, Topaz, ARCNet are examples of other protocols that are popular for factory automation applications. The wide variety of existing networking protocols has prompted industry to migrate towards an open standard that can offer “plug-and-play” capability, such as the Fieldbus. Fieldbus refers to a non22 proprietary digital two-way communication standard that defines application, data link, and physical layer services of the OSI model for the process automation industry. The slow standardization of the Fieldbus and the lack of semiconductor products in the market to implement the sensor nodes have retarded the initial excitement for this new standard [FRANK00]. Office and Building Automation has been mainly implemented with the BACnet protocol used for energy management in smart buildings and is being supported by protocols for meter reading, security system, and self-diagnostics that are not yet standardized. Home Automation is migrating from the X-10 protocol previously used for lamp and appliance controls towards the Smart House Application Language protocol. The Consumer Electronics Bus (CEBus) and LonTalk are other contenders for building automation [FRANK00].
Interfacing transducers to the numerous existing control networks with support for an extensive set of communication protocols requires significant effort and expense from transducer manufacturers [RNJ00]. Transducer manufacturers and system integrators are required to redesign the transducer interfaces for each type of multivendor network. This redesign process is expensive, time consuming and prevents interoperability of sensors due to proprietary or unique interfaces. 23 2.4 IEEE 1451 Smart Transducer Interface for Sensors and Actuators Recent industry efforts towards interoperability in a wide range of applications have attempted to focus on the definition, functionality, and communication protocol standards for smart transducers. The IEEE and the NIST have defined the IEEE 1451 set of standards for a Smart Transducer Interface for Sensors and Actuators in an effort to overcome the incompatibility issues that arise while interfacing smart transducers to instruments, microprocessor-based systems, fieldbus and control networks. The objective of these standards is to define an architecture that allows transducers to connect into any live distributed control network in a true “plugand-play” fashion, such that automatic system identification and configuration is facilitated [LEE_K00]. The IEEE Working Group for the standards has attempted to achieve this by specifying a
network independent object model for interfacing smart transducers to any target network and descriptive datasheets embedded within smart transducers for self-identification of each device. As a result, the same transducers can be used on multiple control networks and the selection of a control network for measurement, and control application is no longer dependent on transducer compatibility constraints. This would also encourage transducer application developers to shift their focus to adding value and innovation to their applications rather than developing interfaces for different networks. Smart transducers (either smart sensors or actuators) typically follow a signal chain composed of a raw transducer element, signal conditioning block, signal conversion 24 block, a microprocessor block, and a communication transceiver [RNJ00]. The core of the IEEE 1451 set of standards attempts to provide a layer of abstraction between the microprocessor and the signal conversion blocks, as well as the communication transceiver and the field network to provide network independence to the smart transducers. Thus, the standards provide a means to achieve transducers-to-network interchangeability as well as transducer-to-networks interoperability [LEE_K00]. The IEEE 1451 family of standards is comprised of four independent standards, 1451.1, 1451.2, P1451.3 and P1451.4, the latter two still waiting approval from the Standards
Committee. The standards may be used either separately or together as part of a complete IEEE 1451 solution [CAN99]. IEEE 1451.1 Network Information Model Signal Conditioning Signal Conversion Field Network Commands Data IEEE 1451.2 Smart Transducer Interface Module Microprocessor Communication Transceiver Raw Transducer Element Fig. 2.1 The IEEE 1451 Core Protocols [RNJ00] 25 The specifications are defined in such a manner that each higher numbered specification is completely contained within the confines of a lower numbered specification. This provides tight encapsulation of the hardware details at each level, similar to the data hiding concepts in object-oriented programming or protocol layering definitions in networking. 2.4.1 The 1451.1-1999 Standard for a Smart Transducer Interface for Sensors and Actuators – Network Capable Application Processor (NCAP) Information Model The IEEE 1451.1 standard defines a network independent Common Object Model to enable the interfacing of smart transducers to any network [1451STD99]. Standardized access to a physical transducer is possible by a programmable interface that may be
provided by transducer manufacturers or network vendors. The 1451.1 specification provides the object-oriented definition of a Network Capable Application Processor (NCAP) that encapsulates the details of the transducer hardware implementation. It also provides the definition of application-level access to network resources and the framework for application access to transducer hardware. The IEEE 1451.1 architecture defines three types of models – an object model for the software components of the IEEE 1451 system, a data model for the information communicated across the specified object interfaces, and a pair of network communication models. 26 The networked smart transducer model is described in the specification through two views, the physical and logical views. Network Hardware Network Protocol Network Transducer Interface (IEEE 1451.2) Microprocessor Hardware Operating System Firmware Server Object Dispatch Ports Application Software: Function Blocks Components Services NCAP Block Transducer Blocks Transducer Firmware I/O Interface Hardware
Logical Interfaces Logical Blocks Fig. 2.2 Networked Smart Transducer Model [1451STD99] The physical view of the system identifies the actual components present in the system, viz. the network hardware, I/O interface hardware, microprocessor hardware, transducers and the communication network. The logical view of the system can be a view of the logical components or the logical interfaces of the system. The application software on the NCAP, operating system firmware, network protocol, etc are logical components and may be grouped as application and support components. The logical interfaces defined by this view are the network abstraction interface, transducer abstraction interface, and the 27 logical interface to NCAP support between the operating system firmware and the microprocessor hardware [1451STD99]. The information model is represented as a set of object classes, attributes, methods and behavior that provide an abstract view of device characteristics in object-oriented terms [LEE_K96]. The card-cage paradigm that is commonly used to describe plug-in I/O functionality in motherboards is used here to describe the different functionality that may be used in the NCAP model. Logical Backplane Network Transducer Independent
InterfacPhysical e Block Network Block Application-specific Function Blocks Transducer Block Transducers Network Neutral Interface Fig. 2.3 The IEEE 1451.1 Card Cage Object Model [FRANK00] The blocks that may be implemented in an IEEE 1451.1 design include a Physical Block, one or more Transducer, Function, and Network Blocks. The Physical Block provides the backplane for the card-cage structure and contains the logical hardware and software 28 resources in the model. The Transducer Blocks abstract the capabilities of each transducer that may be connected to an NCAP, and are primarily used in the configuration phase. The Function Blocks provide a skeletal area for application-specific data and methods that may be plugged in whenever necessary. The Network Blocks are used to encapsulate all network communication operations from the rest of the NCAP functionality through a network neutral interface. The Network Blocks are based on the principles of Remote Procedure Calls (RPC) commonly used in distributed systems [LEE_K96]. The interfaces that are exposed by the IEEE 1451.1 Model are the interface to the transducer modules and that
Transducers DEPTH 250FT
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.