A Universal Smart Transducer Interface: TTP/A H. Kopetz M. Holzmann W. Elmenreich [email protected] Insitut für Technische Informatik Technische Universität Wien Austria Abstract The primary goal of a universal smart transducer interface is the provision of a framework that helps to reduce the complexity of large distributed real-time systems by introducing precisely specified (in the value domain and in the temporal domain) and small interfaces between smart transducers and their users. This paper presents a universal smart transducer interface that can be implemented on top of different real-time communication systems. It integrates a time-triggered communication protocol with an interface file system that provides the sources and sinks for the exchanged information. The final section discusses an implementation of this interface on a low cost (less than 1 $) commercial off the shelf microcontroller. 1. Introduction The point-to-point connection of process input/output devices to a control system is expensive, both from the installation point of view and from the engineering point of view. One approach to reduce these costs is the introduction of the emerging smart transducer technology. A smart transducer is an intelligent subsystem consisting of a sensing or actuating device (sometimes already an integrated device on a silicon die), a micro-controller with the necessary software, and a communication network interface (CNI) to a field bus. A properly designed CNI of a smart transducer node should present a standardized high-level view of the sensor and encapsulate the idiosyncrasies of the particular sensing element within the smart transducer node. Such a smart-transducer CNI should be understandable, temporally predictable and implementable in available low-cost microcontrollers. To improve the understandability, the externally visible interface of a smart transducer should be designed around few already familiar concepts. The transducer interface must be generic, i.e., the interfaces of most of the available transducer should be expressible within the model. Ideally, the same basic concepts--and as a consequence the same application software at the user's side--should suffice to communicate with the majority of the available sensing and actuating devices. Since the bandwidth and response time requirement of various transducers may differ by orders of magnitude, the model should be flexible to accommodate different communication speeds and different media access protocols, e.g., simple single wire UART channels as well as a high-speed fiberoptic channel. Since more than ten years it has been recognized that a standardized real-time communication network, a fieldbus, to replace and enhance the existing 4-20 mA analog signal standard would be an enabling technology beneficial to the industrial instrumentation business as a whole. However, many vendors were reluctant to support such a single common standard in fear of losing some of their competitive advantages [1]. As a consequence, a number of different mostly incompatible fieldbus solutions (see [2]) have been developed and promoted. In 1992 the two large rival fieldbus groups ISP (Interoperable Systems Project supported by Fisher-Rosemount, Siemens, Yokogawa, and others) and the WorldFIP (supported by Honeywell, Bailey, and others) introduced two competing interim fieldbus standards. In 1994 these two rival groups merged 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 IEC (International Standard Organization) and the ISA (Instrumentation Society of America). This new fieldbus standard IEC/ISA SP 50 should integrate different types of control instruments and support, as far as possible, existing interfaces. In the meantime the Control Area Network CAN [3] was developed by the automotive industry to reduce the wiring harness within a car. From the functional point of view, the CAN bus can deliver a communication service that is closely related to that of thefieldbus, although with limited temporal predictability. The immense size of the automotive market has led to the appearance of low-cost highly integrated CAN chips that are being used by a number of companies in the factory and process automation market. Many of the cited efforts to create a standardized fieldbus have focused on the issues of reliable communication and wiring, but have neglected the higher level issues that must be addressed if interoperability or interchangeability of devices and subsystems must be achieved. The IEEE 1451.2 [4] 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 [5]. In contrast to this work, it is the objective of this paper to present a generic interface for smart transducers that can be used to connect many different concrete sensor and actuator subsystems within the same conceptional framework. Although it can be implemented on diverse communication layer, the specification of the communication system relies to the protocol specification and is not part of the transducer interface. The rest of the paper is organized as follows: Section 2 explores the abstract properties of an interface and discusses why the 4-20 mA current loop was highly successful. Section 3 presents the generic TTP/A protocol [6], a temporally predictable fieldbus protocol that can be implemented on different physical layers. Section 4 discusses the three shared code spaces that must be provided to enable an information exchange across an interface: a common name space, provided by an interface file system (IFS), a time space, and a value space. Section 5 presents an implementation of this interface on a low-cost microcontroller and an UART bus. The paper ends with the conclusions in Section 6. 2. What is an Interface? An interface is a common boundary between two subsystems. An information exchange across an interface is only possible if the engaged subsystems share a common background of concepts and a common coding system. In the context of a distributed control system, the smallest area of concern is a cluster, consisting of a set of sensor, actuator, and processing nodes connected by a broadbus communication medium. The set of all