The increasing interest in smart sensors is a direct result of the need to communicate sensor information in distributed control systems. Unfortunately, numerous protocols have been defined for data communication in control systems. Industry standards have been and are being developed for various applications. Within a given market segment, several proposals are vying for acceptance. A few of these protocols have already been implemented in silicon hardware. This chapter provides background information, identifies many of the proposed protocols, and describes silicon chips that have been developed to support system designs.

Data communication from sensor inputs must be analyzed, with the recognition that the sensor is a part of an entire control system. Several industry committees and individual companies have expended considerable effort to generate acceptable protocols that will support the requirements for distributed control. System functionality and the ability to use available silicon hardware, software, and development tools must be considered in the selection of a protocol for a given application.

Several terms and definitions are used to describe the communication of system information. A protocol is an agreed-on set of rules for communications. The bus connects internal or external circuit components and can be serial or parallel; the serial approach is more common. A device-level bus connects basic control elements, the sensors and actuators, to a host controller. Multiplexing (mux) is the combining of several messages for transmission over the same signal path. Access to the bus is obtained through an arbitration process. Bit-by-bit arbitration is also called collision detection. Contention is the ability to gain access to the bus on a predetermined priority. Latency is guaranteed access (with maximum priority) within a defined time. A deterministic system can predict the future behavior of a signal. The data link controller (DLC) is the silicon implementation of the protocol that handles all communications requirements.

The system goal of interoperability permits sensors or actuators from one supplier to be substituted for one from another manufacturer. Star, ring and linear (tree, multidrop) are common topologies, that is, methods of connecting data lines to system nodes. The use of master-slave relationships, although an important part of control networks, is giving way to the use of more distributed intelligence in many applications.

Smart digital cameras with embedded operating systems offer enough processing horsepower to recreate downloaded computer games.

The 4- to 20-mA standard of the Instrument Society of America (ISA) has been the analog data transmission standard for over 30 years. However, digital techniques can provide more system functionality and increased noise immunity for signal transmission. Many digital interface formats already exist for point-to-point or multidrop communications. These protocols have seen limited use in computer-controlled systems. The EIA-485 is most often used for digital field bus applications. It is the physical layer in Profibus, Topaz and Bitbus protocols. The EIA-485 is a balanced-line (differential) data transmission over a single twisted-wire pair. However, examining the different market segments, an even wider variety of standards exists.

The International Standards Organization (ISO) has defined the Open Systems Interconnection (OSI) model, which describes seven layers for data networking. Available and proposed standards typically use all or a portion of the layers to define the standard.

In a distributed system, a node contains the sensor (or actuator), the hardware for local computations, and the network interface. The term sensor bus is frequently used when sensors are connected in a system using a multiplexed bus offering data-link-level multiplexing and allowing packets from different senders to be sent to different receivers. A higher-level sensor network uses all layers of the OSI model to provide more information and simplify the user's system design and maintenance activity.

Smart sensor bus
Several universities have developed standards for communication. For example, the University of Michigan has proposed the Michigan parallel standard (MPS). Researchers at Delft University of Technology have developed a serial communications protocol. The Integrated Smart Sensor (IS 2 ) bus is a mixed analog/digital two-line serial bus interface.

However, a protocol requires more than definition and demonstration hardware. Accepted usage by a number of manufacturers ultimately determines the real standards, which may, in fact, be de facto standards. University-developed protocols may achieve acceptance with the adaptation of industrial users, but the process takes longer than using existing industry-sponsored standards.

Autos drive specs
Because of its large volumes, the automotive segment has driven specifications, resulting in the actual implementation of protocols in several products. In automobiles, information from one sensor and/or data from one system can be communicated with other systems using multiplex wiring to reduce the number of sensors and the amount of wire used in a vehicle. Two predominant protocols have emerged as standards, but several other protocols exist that are specific to manufacturers' applications. The Society of Automotive Engineers (SAE) has established SAE J1850 as the standard for multiplexing and data communications in U.S. automobiles. However, data communications for trucks and On-Board Diagnostics II (OBDII) are based on the Controller Area Network (CAN) protocol developed by Robert Bosch GmbH.

The SAE Vehicle Network for Multiplexing and Data Communications (Multiplex) Committee has defined three classes of vehicle networks: Classes A, B and C. Class A is for low-speed applications such as body lighting. Class B is for data transfer between nodes to eliminate redundant sensors and other system elements. Class C is for high-speed communications and data rates typically associated with real-time control systems.

SAE J1850 was approved as the standard protocol for U.S. automakers in 1994. J1850 defines the application, data-link and physical layers of the OSI model. J1850 specifies two implementations: a pulsewidth modulation (PWM) version and a variable-pulsewidth (VPW) version. J1850 is supported by a number of other SAE specifications, which are referenced in J1850, such as the message strategy document, J2178.

In addition to the SAE bit-encoding techniques, other common techniques include 10-bit nonreturn to zero (NRZ), Bit-stuf NRZ, L-Man (Manchester), E-Man, and modified frequency modulation (MFM). These techniques differ based on variable synchronizing, arbitration, transitions per bit, maximum data rate, oscillator tolerance, and integrity. SAE J1850 network access is nondestructive prioritized by bit-by-bit arbitration for either protocol option. A frame is defined as one complete transmission of information. Within the frame, the header contains information regarding the message priority, message source, target address, message type, and in-frame response. For SAE J1850, each frame contains only one message, and the maximum length for a frame is 101 bit times. A power reduction or sleep mode occurs at a node if the bus is idle for more than 500 ms. Wakeup occurs with any activity on the bus.

Real-time control
CAN, a serial communications protocol developed by Robert Bosch GmbH, was originally designed for automotive multiplex wiring systems, high-speed data communications. CAN supports distributed real-time control with a high level of security and message integrity. It has also become attractive for use in lower-speed and other distributed control applications.

The original CAN specification was announced in the 1980s. A revision, CAN 2.0, was announced in 1991. CAN 2.0 consists of an A part and a B part. Part A is known as CAN 2.0 A, CAN 1.2, and BasicCAN. Part A specifies an 11-bit identifier field, includes no specification for message filtering, and has a layered architecture description based on Boschis internal model. Part B enhancements include an extended 29-bit identifier field, some message filtering requirements, and layer description based on ISO/OSI reference model. The 29-bit identifier field allows the automotive standard protocol, SAE J1850, 3-byte headers to be mapped into the CAN identifier field. However, minimum CAN compliance is established by conformance to CAN 2.0 A only.

CAN is a multimaster protocol that allows any network node to communicate with any other node on the same network. Any node can initiate a transmission once it has determined that the network is idle. CAN properties include user-defined message prioritization. CAN is actually a non-deterministic system, but a guaranteed maximum latency for highest prioritization can be calculated. Lower priorities are determined on a statistical basis. CAN utilizes carrier sense, multiple access/collision resolution (CSMA/CR) for nondestructive collision resolution. The arbitration technique is bitwise and results in the highest priority message being transmitted with low latency time. The flexible system configuration allows user options that have been led to CAN-developed systems in automotive and industrial applications.

The message format for CAN is a fixed-format frame with a variable number of data bytes. Zero to 8 data bytes are permissible. The minimum data frame length is 44 bit times. Four message types are defined: data frame, remote frame, error frame, and overload frame. The messages are routed to receiving nodes through the use of message identifiers and message filtering. Functional addressing allows multiple nodes to act on a single message. However, nothing in the hardware prevents the user from using physical addressing to achieve node-to-node addressing. Part of the error-detection scheme is the acceptance of every message by all nodes or no nodes. Even if a component on the network is not concerned with the message that is transmitted, it must still receive the message, check the cyclic redundancy check (CRC), and acknowledge (ACK) acceptance.

Data is requested through the use of a remote frame and transmitted through the data frame. The remote frame contains no data field and the remote transmission request (RTR) bit is sent recessive. Otherwise, the remote frame is identical to the data frame.

Error detection and error signaling are possible because CAN has a variety of built-in error counters that help contain errors and prevent nodes that have failures from restricting communications on the bus. A faulty transmitting node always increases its error counter more than other nodes. Therefore, the faulty node becomes the first to go ibus off. Automatic retransmission of corrupted messages minimizes the possibility of an undetected message. CAN also has the ability to distinguish between temporary errors and permanent node failures, which makes it ideal for the high-noise environments that occur in automotive and industrial applications.

The CAN protocol does not address the physical layer requirements. The transceiver is not specified; it is left to the user's network characteristics to define the requirements. Accepted physical media include but are not limited to twisted pair (shielded or unshielded), single wire, fiber-optic cable and transformers coupled to power lines. RF transmitters are being developed by some users for CAN systems. Acceptable transmission rates range from 5 kbits/second to 1 Mbit/s. The most widely used implementation to date is a twisted-pair bus with NRZ bit formatting. Twisted-pair CAN drivers that simplify system design are available.

Other automotive protocols, some of which are covered by SAE specifications, have been developed. The implementation of those alternatives requires a volume user that obtains benefit by using the alternative protocol, as well as a semiconductor manufacturer willing to implement the protocol in silicon hardware. For comparison, the Automotive Bit-Serial Universal Interface System (A-bus) and the vehicle area network (VAN) are discussed.

Fiber optics
A-bus was developed by Volkswagen AG. Error detection is by bit only. Both single wire and fiber optics can be used for the transmission media. The maximum bus length is not specified but is typically 30 m. The maximum data rate of 500 kbits/s is considerably higher than the rate specified in SAE J1850.

VAN, developed by French automaker Renault, is being considered as an ISO standard. The transmission medium is twisted pair. The maximum data rate is user-definable. A maximum of 16 nodes is possible with a maximum bus length of 20 m. Bit encoding is one of two variations on Manchester coding. The Manchester coding technique encodes a 1 with a high level for the first half of the bit time, and a 0 is encoded with a low level for the second half of the bit time. Consequently, a maximum of two transitions per bit time is possible.

The Technical University of Wien in Austria has developed a time-triggered protocol (TTP). The protocol provides information about the future behavior of the system through timing algorithms. All system activities are triggered by the progression of real-time. The architecture requires clock synchronization by a global time base. TTP supports high-speed distributed- control systems, where fault-tolerant operation is critical.

A consortium of German and French automakers has developed an operating-system standard for automotive electronics. The Osek (the German acronym for Open System for Automotive Electronics) OS is an extension of the front end of the MCU hardware. It is intended to provide a structured design with additional, higher software levels encapsulating lower levels to reduce the software complexity for distributed-control systems in vehicles. The spec allows standardized software components to be used across multiple platforms to reduce development cost and time-to-market.

Osek was developed to be independent of the communication protocol. as a result, it is compatible with the CAN, J1850 and other automotive protocols. The combination of application-specific OS, protocol and system hardware- including smart sensors-will be required to improve efficiency, meet emissions and safety standards, and improve the overall driving experience in future vehicles.

The power of a distributed multiplex system is easily demonstrated in factory automation. In many cases, users have completed wiring a multiplex system installation with one or two people in a single day, a task that previously took a crew of electrical technicians several days to wire. Also, these installations work successfully the first time, resulting in a considerable cost reduction. Wiring for a multiplex system consists of a twisted pair of wires, power and ground, which greatly simplifies the interconnection process. Once a system strategy is developed, nodes can be added or moved easily without reengineering the system. The nodes can include sensors, as well as valves, motors and lighting loads. The key is an open standard and plug-and-play capability.

Industrial standards
The industrial market has even more proposed and developing standards than the automotive market. Fieldbus is the term for a nonproprietary digital two-way communications standard in the process automation industry. The fieldbus specification will define the application, data link and physical layers of the ISO model with some Layer 4 services defined.

Fieldbus has not been completed, however, and semiconductor products are not available to implement the control nodes. Two protocols that are attracting a number of industrial users based on available silicon products are CAN and LonTalk.

CAN has been adopted for use in industrial applications by manufacturers such as Allen-Bradley and Honeywell in the DeviceNET system and SDS, respectively. Those communication networks were developed as simpler, lower-cost alternatives to fieldbus, which is being developed as an industrial standard.

However, fieldbus is intended to handle a larger amount of data. All three networks are designed for real-time operation, but each handles a different amount of transmitted data.

The CAN protocol is used to implement both SDS and DeviceNET, but the two systems are not interoperable. The difference between them is in the physical layer, which is not defined in the CAN specification, allowing users to implement different approaches.

Meanwhile, the LonTalk protocol, developed by Echelon Corp., has received considerable support for several industrial and consumer applications.

The protocol defines all seven layers of the OSI model. It uses differential Manchester coding with data packet length of 256 bytes and can operate up to a maximum speed of 1.25 Mbits/s. The arbitration is predictive carrier sense, multiple access (CSMA) and has collision detection and priority options. The LonTalk protocol can be used to support sensor network to fieldbus requirements. A LonWorks system works on a peer-to-peer basis and does not require a host central processing unit (CPU). Events occurring at a particular device are communicated directly between modules.

LonWorks control network technology has been selected as a standard by Semiconductor Equipment Materials International. SEMI standard E-61 specifies LonWorks as a sensor bus for connecting simple as well as complex sensors and other equipment in semiconductor manufacturing.

Other industrial protocols offer advantages to distributed control systems: highway addressable remote transducer (HART), fieldbus, process fieldbus (Profibus), SERCOS, Topaz and ARCNet protocols.

Rosemount developed the HART protocol in the late 1980s. It has a dedicated users group (HART Communication Foundation) with several participating companies. The open multiple master protocol is compatible with the 4- to 20- A current loop and also allows digital communication.

The recent combination of the Interoperable Systems Project Foundation (ISPF) and WorldFIP North America into the Fieldbus Foundation has the potential to complete a fieldbus specification that has been in development for over 10 years. Fieldbus defines the user layer in the OSI model, making it more extensive than protocols that address only the physical, data link and/or application layers (e.g., CAN).

Profibus is a German DIN standard that supports a data rate up to 1.5 Mbits/s. The deterministic system uses a master-slave hierarchy and has a capacity of 127 nodes. Arbitration is handled by command response. EIA-485 is used as the physical layer.

A serial, real-time communication system (SERCOS) network typically consists of eight nodes per ring. It operates at a speed of up to 1 Mbit/s and for a distance of up to 40 m at that speed. It is a deterministic multimaster network with command response and broadcast for arbitration. The physical layer is fiber-optic.

Topaz can handle up to 255 nodes and operate at a speed of 1 MHz. At 1 km, the speed decreases to 500 kbits/s. The multimaster system is deterministic and uses token passing for arbitration. The physical layer uses EIA-485 interface.

Token-passing protocol
ARCNet (Attached Resource Computer Network), a trademark of Datapoint Corp., is a deterministic token-passing protocol. In an ARCNet system, all nodes have equal access to the network, eliminating transmission collisions on busy networks. The ARCNet protocol automatically reconfigures the network without software intervention if a node is added or deleted.

Other specialty buses, including ControlNet, Genius I/O, and Sensoplex, have been developed by industrial control manufacturers.

The BACnet protocol has been developed by the building automation industry. Ethernet, ARCNet, MS/TP and LonWorks are among the networks that could communicate on the proposed BACnet-compatible system being developed by the American Society of Heating, Refrigeration and Air-Conditioning Engineers (ASHRAE). Building energy management systems standards are also being developed. In addition, the Automatic Meter Reading Association is developing a standard for automatic meter reading. IBIbus has been developed by the Intelligent Building Institute.

Smart office buildings offer a high degree of automation. In offices, nodes sense changes in the environment and send status and control messages to other nodes in response to those changes. Power nodes open or close dampers, change fan speed and make other adjustments based on that information. Other aspects of these systems are self-diagnostics, data logging, fire detection and sprinkler systems, energy usage monitoring, and security systems.

The computer control of future homes is the goal of the Smart House project. Among the likely candidates for interfacing to the network are the heating, ventilation and air conditioning system; water heater; range; security; and lighting. Remote meter reading and demand-side management by utility companies are among the driving forces for home applications. Protocol acceptance in this consumer environment is contingent on achieving low cost/node and ease of operation. The speed of those systems will range from low to high, depending on the devices connected to the system. Both the message size and the message protocol complexity will be medium.

Over two decades ago, X-10 Corp. developed the X-10 protocol for homes, which has been used extensively for lamp and appliance controls. More recently, the Smart House Applications Language was developed and includes over 100 message types for specific functions. Dedicated multiconductor wiring is required in the home. The system can address 900 nodes and operates at a maximum of 9.6 kbits/s. Two additional contenders in this arena are CEBus and LonTalk.

The consumer electronics bus (CEBus) was initiated by the Consumer Electronics Group of the Electronic Industries Association. CEBus provides data and control channels and handles a maximum of 10 kbits/s. It has a growing acceptance in the utility industry.

The acceptance of LonTalk in building automation, the availability of full OSI layers, and interoperability are among the reasons that it is well-suited for the home automation environment. Simplicity and ease of installation are also important attributes, especially for add-on equipment. Widespread acceptance in other markets will also drive the learning curve for cost reduction that this market requires.

A few of the protocols discussed in this chapter have been implemented in silicon hardware and are available from multiple sources. In some cases, the protocol is a standalone integrated circuit. However, a protocol integrated into an MCU provides computing capability and a variety of system features that affect the cost effectiveness of individual system nodes.

A standard protocol provides sufficient volume potential for semiconductor manufacturers to design a variety of integrated circuits. In many cases, the highly integrated solution provides the lowest cost per node. For example, Motorola's MC68HC705V8 integrates the J1850 communication protocol, on-chip voltage regulation, the physical layer interface, the J1850 digital aspect (VPW version), and other systems-related functions. The integrated solution has many features that make system design easier and reduce both component count and system cost.

System features
Several semiconductor manufacturers have implemented the CAN protocol on a variety of microcontrollers. The integrated CAN solution contains a variety of I/O, memory and other system features. One key point of the CAN protocol is that, although a set of basic features must be implemented in any CAN device, a number of extended features may also be implemented in silicon, depending on the intended target application. The implications must be understood when interoperability and interchangeability are being considered. A number of semiconductor manufacturers have designed and offer several solutions. In fact, the broad product availability is among the reasons that industrial users are choosing CAN.

An example of the CAN protocol implemented in an MCU is provided by Motorola's M68HC05 microcontroller family. This CAN implementation conforms to the CAN 2.0 part A specification. All Motorola CAN (MCAN) devices include automatic bus arbitration, collision resolution, transmission retry, digital noise filtering, message ID filtering, frame generation and checking, CRC generation and checking, as well as single transmission and multiple receive frame buffers. The MCAN module contains full message transmit and receive buffers and limited message filtering capability. The integrated bus interface includes input comparators and CMOS output drivers. However, an external transceiver may be necessary.