IEEE 1451.1

Description / Abstract: FOREWORD

The objective of the IEEE/NIST Working Group on transducer interface standards is to utilize existing control networking technology and develop standardized connection methods for Smart Transducers to control networks. Little or no changes would be required to use different methods of analog-to-digital (A/D) conversion, different microprocessors, or different network protocols and transceivers.

This objective is achieved through the definition of a common object model for the components of a Networked Smart Transducer, together with interface specifications to these components.

The Networked Smart Transducer model shows two key views of a smart transducer:

— Physical view

— Logical view

Physical view

The first view shows the physical components of the system. This view is indicated by components drawn in solid lines in Figure 1.

Figure 1 shows a model composed of sensors and actuators connected to form a transducer. The transducer is connected over an interface to a microprocessor or controller that is in turn interfaced to the network. The Hardware Interface Specification between the sensor/actuator and the rest of the device hardware, known as the network capable application processor (NCAP), is indicated by the rightmost thick, dashed line in the figure. A typical specification is described in the companion standard [IEEE Std 1451.2-1997].

The NCAP hardware consists of the microprocessor and its supporting circuitry as well as hardware implementing the physical layer of the attached network and the input/output (I/O) interface to the transducer, as shown in Figure 1.

Logical view

The second view is the logical view of the system and is indicated by components shown in dotted lines in Figure 1.

The logical components may be grouped into application and support components. The support components are the operating system, the network protocol, and transducer firmware components shown. The operating system provides an interface to applications, indicated by the dashed line labeled “Logical Interface to NCAP support.”

A second logical interface, labeled “Network Abstraction Logical Interface Specification,” consists of Port and Server Object Dispatch components defined in this standard. This interface provides an abstraction to hide communication details specific to a given network within a small set of communication methods. The details of this interface are defined by this standard.

The third logical interface, labeled “Transducer Abstraction Logical Interface Specification” performs the same abstraction function for the specifics of the transducer I/O hardware and firmware. In effect, this interface makes all such transducer interfaces look like I/O drivers. The details of this interface are defined by this standard.

Applications are modeled as Function Blocks in combination with Components and Services. The NCAP block provides application organization and support for the other blocks. All of these Blocks, Components, and Services are defined by this standard.

These interfaces are optional in the sense that not all must be exposed in an implementation.

NOTE—If support for interoperable transducers is not required, it is permissible to not use the IEEE1451.2 Interface Specification, or a similar transducer interface standard, but to still use the IEEE1451.1 object model. Similarly, if networking is not supported, or if the networking implementation is closed, it is not necessary to use IEEE1451.1 to still get the benefits of using IEEE1451.2 or a similar transducer interface standard.

Scope 

This standard defines an interface for connecting network-capable processors to control networks through the development of a common control network information object model for smart sensors and actuators.

The object model includes definitions of

— Transducer Blocks

— Function Blocks

— NCAP Blocks

This standard will not define individual device algorithms or specifics on what is implemented by using the model.