Google Adwords  |  Guerilla Marketing  |  Marketing Tools  |  Articles & Editorials  |  Contact Us  | Home    

Back

The Internet has grown from a bleeding-edge curiosity to a ubiquitous force that is redefining how we live and work. Every imaginable kind of device will eventually be networked, but pervasive connectivity of sensors will materialize in the industrial world before it happens in the consumer arena. This will transform sensors from information devices into communication devices.

But the sensor world is more diverse than the PC world. In most cases, it’s more expensive to network a sensor with embedded intelligence than it is to connect a PC, and there are more ways of doing it. The plethora of network standards and the inherent difficulties in supporting more than one protocol have stopped many an engineer cold.

This three-part series discusses adding network capability to sensors via embedded devices. The remaining parts of the series will answer the following questions.

Part 2: What are the basic hardware and software components needed to build networking capability into a sensor?

Part 3: What are the prepackaged and off-the-shelf alternatives to designing network capability from scratch?

Why Add Network Capability to a Sensor?

Photo 1. On the left is a control panel for a point-to-point wired automation system. On the right is a system that's wired with DeviceNet. Notice the dramatic reduction of wires and the physical simplification of the system. Network-based systems have a higher component cost, but they save on wiring, labor, and wiring errors and can report diagnostic data unavailable with point-to-point wiring. (Photo courtesy of ODVA.)

The first and most obvious reason is to save wiring when interconnecting multiple devices. Large factory automation and process control applications use industrial networks (fieldbuses) extensively. The elimination of large, unwieldy bundles of cables and the associated mess is an obvious advantage (see Photo 1). Networking allows you to connect hundreds of devices to a single trunk line instead of using hundreds of individual wires. As systems grow past the threshold of 100 I/O points, the added expense of network hardware is offset by savings in wiring time. These benefits grow exponentially with the size of the system.

Figure 1. Cost savings grow exponentially with the size of a system. Generally, systems with 100 or more devices are likely to be less expensive if you use a network. Networked systems can be reconfigured in software, rather than physically changed. The modularity brings interesting possibilities to machine design.

The modularity of a networked system is another major advantage (see Figure 1). Connectivity is achieved through software, so taking a large system apart, putting it on a truck, and reassembling it somewhere else is much easier.

In addition to the wiring savings and modularity, there are three major reasons to add network capability to a sensor:

Diagnostics. A networked device often can tell you if it is malfunctioning, or if something’s about to go wrong. This information can be of great help. It’s even more valuable if the information can be accessed remotely via the Internet.

Self-Configuration. Machine controllers can automatically detect which modular components are connected to the network and determine what software configuration to load. This can cut hours or even days off the delivery and setup time of a large system.

Enterprisewide Information Systems. Initiatives to interconnect every system in a company—from accounting to purchasing to manufacturing to payroll and sales—may extend down to individual devices. Even the most mundane information can add money to the bottom line if used appropriately.

Redefining a Sensor via Networking
It’s one thing to connect hundreds of solenoid valves and proximity switches via a network to save wiring time or to make the system

Photo 2. The 6950/6960 mass flow controller series from Brooks Instrument, Hatfield, PA, comes in two versions: a hard-wired analog version, which has seven connections, and a DeviceNet-enabled version, which has a single connector and the ability to handle many additional variables. The DeviceNet version exchanges more than 100 additional data types, making it more valuable to customers in the semiconductor industry.

modular. It’s quite another to use the network to gather more information than you could get from a hard-wired device.

For example, Brooks Instrument Division, Emerson Electric (215-362-3500), makes mass flow controllers (MFCs) for semiconductor fabrication machines. These devices precisely monitor and regulate the flow of gases in a process (see Photo 2). Network the MFCs, and you’ve greatly enhanced the device. In addition to the seven control variables available through the hard-wired version, the network-enabled unit gives you access to hundreds of variables from 39 categories of variables and functions, which relate to the complexity of regulating and monitoring gas flow in real time (see the sidebar “Information Access: Hard Wire vs. Network”). This rich array of information provides insight into the process that otherwise would be unavailable. The information lets you identify the source of problems, and the manufacturer can determine whether the problem originated in its MFC or elsewhere.

Commercially, a manufacturer can sell its sensor based on the added value of the specialized information that its unit provides, rather than on the commodity value of an xyz category sensor. For this product, semiconductor processes that create millions of dollars of product per hour can be optimized in ways that were only dreamed of when hard-wired devices were used.

Who Uses Sensor Networks?
The larger the company, the larger the installation, and the more sophisticated the application, the more likely it is that a network will be used. General Motors and Chrysler use DeviceNet and Profibus extensively to link factory-floor devices, and Ethernet is everywhere, not only connecting the enterprise but linking controllers and PLCs to each other and to the IT department.

âetworks like Bacnet and LonWorks link devices in building HVAC systems (see the sidebar “Honorable Mention”). Foundation Fieldbus connects intrinsically safe devices across huge oil refinery and chemical processing campuses.

How Does an Industrial Network Open New Markets?
If a network redefines a sensor, it also redefines who wants to buy it and what it can be used for. If customers have chosen a particular network for a control or data acquisition system (DA), then their choice of sensors is narrowed to those that support the network.

Right now, most sensors don’t have a network capability; only a few can make this claim. So if your sensors are network enabled, you’re in an elite group. You’re competing against fewer people, and your customers are more value driven and less price driven. Customers who focus only on the increased price of a networked system have missed the main point. It’s not about price. It’s about the value of information and what you can do with it—how you can profit from it—once it’s available.

Ethernet
There are a lot of network standards out there. If you’re going to add network capability to your sensor, which one should you support? Well, to start with, it’s best to view networks in terms of their scope. One of the reasons there are so many different network standards is that there are so many different requirements. Table 1 indicates the amount of data that various buses are designed to handle.

TABLE 1
Network Specs at a Glance
	Ethernet	Modbus RTU/ASCII	Profibus	Foundation Fieldbus	DeviceNet	CANopen	J1939
Origin	Digital Equipment Corp., Intel, and Xerox - 1976	Modicon - 1978	German govt. and automation manufacturers - 1989	ISA - 1998	Allen- Bradley - 1994	CAN in Automation - 1993	SAE 1994
Implemen- tation	Produced on chips by many vendors; based on IEEE 802.3	Produced on any medium, but it is typically found on RS-232, -422, or -485; no special ASICs required	Produced on ASICs by multiple vendors; based on RS-485 and the European EN50170	Produced on chips by multiple vendors	Produced on chips by many vendors; based on CAN	Produced on chips by many vendors; based on CAN	Produced on chips by many vendors; based on CAN
Formats	10Base-2, 10Base-T, 100Base-T, 100Base- FX, 1 Gb; copper (twisted pair/thin coaxial), and fiber	Typically RS-232, RS-422, RS-485	Profibus DP (master/slave), Profibus FMS (multimaster/ peer to peer), and Profibus PA (intrinsically safe)	H1 intrinsically safe and High-Speed Ethernet (HSE); based on ISA SP50/ IEC61158
Connectors	RJ-45 or coaxial	Typically DB9 or terminal block	9-pin D-shell connector (impedance terminated) or 12 mm IP 67 quick disconnect	Application dependent	Mini 18 mm and micro 12 mm waterproof quick disconnect plugs and receptacles; 5-pin Phoenix terminal block	Mini 18 mm and micro 12 mm waterproof quick disconnect plugs and receptacles; 9-pin D-shell	Application dependent
Max. nodes	1024, expandable with routers	250	127	240/ segment; 65,000 possible segments	64	64	30/ segment
Distance	100 m (10Base-T) to 50 km (mono mode, fiber with switches)	350 m for RS-485	100 m (copper, no repeaters, max. speed) to 24 km (with repeaters and fiber optic transmission)	1900 m for H1	100-500 m	100-500 m	40 m
Bit rate	10 Mbps to 1 Gbps	Can run at any speed, but it is most commonly used between 9600 and 38,400 bps	9600 bps to 12 Mbps	H1 31.25 Kbps and HSE 100 Mbps	125, 250, and 500 Kbps	125, 250, and 500 Kbps	250 Kbps
Message size	46-1500 bytes	0-254 bytes	Max. 244 bytes/ node / message	128 octets	8 bytes/ node/ message	8 bytes/ node/ message	4-8 bytes/ node/ message
Messaging format	Peer to peer	Master/ slave; discrete and analog I/O and parameters	Polling (DP/PA) and peer to peer (FMS)	Client/ server, publisher/ subscriber, and event notification	Polling, strobing, change- of-state, cyclic; explicit messaging for configur- ation and parameter data; UCMM for peer to peer messaging; producer- consumer- based model	Polling, strobing, change- of-state, cyclic, and others	Broadcast, one-to-one
Supporting trade organi- zation	Industrial Ethernet Assoc. and Industrial Automation Open Networking Assoc.	Modicon/ Groupe Schneider	Profibus Trade Org.	Fieldbus Foundation	Open DeviceNet Vendor Assoc.	CAN In Automation	Society of Automotive Engineers

One of the most widely accepted standards, Ethernet, is designed to transfer large amounts of data at high speed and to serve the needs of large installations (see Figure 2).

The networking of millions of PCs in offices and the proliferation of the Internet around the world has made Ethernet a universal networking standard. Today, the standard is gradually working its way to the sensor level in DA and control applications. The hardware and related software have evolved to the point where even inexperienced users can build simple networks and connect computers together. In automation, Ethernet is commonly used with other fieldbuses (see Figure 3).

Ethernet hardware is dirt cheap and can be purchased from office supply stores, computer stores, and e-commerce sites everywhere. The protocol appears to be a panacea for all those who are overwhelmed by the confusing array of standards vying for market dominance and who believe that the popular fieldbuses are expensive and difficult to use. Furthermore, a study by a Big Three automotive manufacturer showed that Ethernet could potentially serve up to 70% of plant floor networking applications.

On the other hand, Ethernet does have its drawbacks. For example, it has a high overhead-to-message ratio for small amounts of data. Also, Ethernet carries no power on the bus, and its RJ-45 connectors are physically vulnerable and more susceptible to EMI/ RFI than most fieldbuses. And even now, its multiple open and proprietary standards are a source of confusion in the industry.

What’s the Deal with Industrial Ethernet?
Multiple instrumentation protocols—including Modbus/TCP, EtherNet/IP, ProfiNet, and Foundation Fieldbus HSE—have emerged as standards for connecting sensors, discrete and analog I/O, and smart devices to Ethernet. This is a new chapter in the fieldbus wars that have been fought in the industry for the last 10 years, except that TCP/IP allows multiple protocols to exist simultaneously on the same wire.

There are at least three major issues that must be addressed for Ethernet to become a viable, popular, plant-floor fieldbus. First, a common application layer must be established. When your device receives a packet of data, in what format is that data? Is it a string of I/O values, a text document, or a spreadsheet? Is it a series of parameters for a variable frequency drive? How is that data arranged? There are several competing standards.

Photo 3. A panel mount receptacle allows a traditional RJ-45 Ethernet telephone connector to be changed to an 8-pole, euro-style waterproof connector for industry. Connectorization is a major issue in using Ethernet for control and data acquisition in industrial environments. (Photo courtesy of Lumberg, Inc.)

Next, many applications require industrial-grade connectors. Cheap plastic telephone connectors don’t cut it on the plant floor, and the RJ-45 connectors aren’t up to the task. An industrial-strength connector will be a great benefit (see Photo 3). Finally, some applications require determinism. Ethernet, as it is typically used, is not deterministic or repeatable—in other words, throughput rates are not guaranteed. But there are ways of building deterministic Ethernet systems. In reality, most people who think they need determinism really need speed.

Neither Ethernet nor TCP/IP Guarantees Interoperability
Ethernet is just a physical layer standard, in much the same way that an RS-232 link or a telephone line is. Having a physical connection means that messages can be transmitted, but it does not ensure successful communication. Just because you can make a telephone ring in Shanghai doesn’t mean you can speak Mandarin.

There are many transmission protocols that can be used on Ethernet. The most popular—and the one used on the Web—is TCP/IP, which stands for Transmission Control Protocol/Internet Protocol. TCP/IP is just a transport mechanism that ensures that messages get from point A to point B. Even though we all use TCP/IP, we’ve still had the experience of downloading a large file, only to discover that our PC “cannot find an associated application for this file type.” So you end up downloading a plug-in, such as Uhockwave, RealAudio, Winamp, or Adobe Acrobat Reader so that you can open the file.

The same problem applies to sensors. You can send any file or piece of process data you want over Ethernet or the Internet, but the receiving end has to know what to do with the data. TCP/IP doesn’t guarantee that you’ll be able to open the file; it just guarantees that it will arrive. Similarly, data can be packaged in an existing fieldbus format and then transported on TCP/IP. This is the direction in which the industry is moving.

Fieldbuses on Ethernet
There’s no need to start from scratch in defining Ethernet protocols for industry. Instead, many vendors are encapsulating existing protocols in TCP/IP. Presently there are four major contenders: Modbus/ TCP (Modbus protocol on TCP/IP), EtherNet/IP (the ControlNet/DeviceNet objects on TCP/IP), Foundation Fieldbus High-Speed Ethernet, and ProfiNet (Profibus on Ethernet).

You could propose an infinite number of application layer protocols. In fact, right now there are (in addition to the above protocols) many proprietary standards from various vendors. But there are several significant advantages to using existing bus architectures:

• Profiles for many devices have already been defined, and they can be transferred to Ethernet with relatively little effort.
• Data can be transferred between the upper and lower network easily. In systems that use, for example, Profibus as an I/O level network and Profibus on Ethernet at the supervisory level, the relationship between the two networks is relatively transparent.
• Many developers and users are familiar with the existing protocols, and this speeds the process of product development and adoption.

To go into the details of Modbus/TCP, EtherNet/IP, Foundation Fieldbus HSE, and ProfiNet is beyond the scope of Part 1 of this series. I’ll provide more information on these protocols in Part 2.

RS-232/-422/-485
RS-232 serial ports are like cassette players in automobiles—nobody brags about them, but almost everybody has one. RS-232 lets one device communicate with another. RS-422 and RS-485 allow multidrop networking on a single wire.

Please note that RS-232 is not a protocol. It’s merely a physical layer with defined pinouts, cable characteristics, and signal levels. ASCII is not a protocol, either: it’s an agreed upon digital representation of characters. For two devices to communicate, they must share the same protocol and physical connection. There are thousands of protocols, mostly proprietary, and a few ¬ommon open protocols. Just because two devices have a serial port doesn’t mean that they can talk to each other. Check out these details carefully when planning a system.

Modbus RTU/ASCII
Modbus Remote Terminal Unit (RTU)/ ASCII is probably the most popular serial protocol in instrumentation, automation, and process control. Today, it provides everything from short serial linkage of smart devices to wide area networking of many devices. Modbus is commonly used with gateways and works well encapsulated in TCP/IP. Developed almost 25 years ago, it’s a simple yet effective way of encapsulating analog and digital I/O and parameters in registers.

Modbus can link as many as 250 devices on an RS-485 cable. Furthermore, you can find many gateway devices that link Modbus and other networks, so if your product has the Modbus protocol on a serial port, you can get from there to almost any network using a black box converter.

The downside, though, is that transmission speed is slow on standard serial media. Also, the protocol lacks sophistication (i.e., it offers no peer-to-peer capabilities, and it is not object oriented).

The Controller Area Network
In the early 1980s, Bosch developed the Controller Area Network (CAN) so that the ürimary control components in an automobile (e.g., brake lights, airbags, sensors, lights, electric windows, and door locks) could be connected by a single cable instead of a 3-in.-thick bundle of cables. Automotive manufacturers found that if a wiring harness was faulty, it was sometimes cheaper to scrap the entire car than to troubleshoot the wiring harness. With a network, you can wire a control panel virtually in software, rather than physically with a screwdriver and terminal blocks. The added hardware cost of the network is more than paid for by labor savings. The same applies to automated equipment in a factory.

Of course, in a vehicle, communication can mean the difference between life and death. You cannot tolerate network errors, regardless of origin. CAN lives up to these rigorous requirements, with a statistical probability of less than one faulty message per century.

The standard is minimally a three-wire bus, with ground and two opposing signal conductors. Signals consist of a pulse train centered at about 2.5 V, with the high signal rising to about 3.2 V and the low signal falling to about 1.8 V. This creates noise immunity, which is especially important in a vehicle.

CAN is a low-level message arbitration protocol implemented on inexpensive (<$1) chips available from multiple vendors and manufactured by the millions. To have a functional network protocol, an additional software layer must be added.

Higher layer protocols (e.g., DeviceNet and CANopen) can be thought of as a sophisticated set of macros for CAN messages, specifically suited for automation. Another popular standard, J1939, was created by the Society of Automotive Engineers as a CAN application layer used in trucks and buses.

Profibus
Profibus is commonly found in process control, large assembly, and material-handling machines—single-cable wiring of multi-input sensor blocks, pneumatic valves, complex intelligent devices, smaller subnetworks (e.g., AS-I), and operator interfaces. Nearly universal in Europe and popular in North America, South America, and parts of Africa and Asia, Profibus is the most widely accepted international networking standard. It can handle large amounts of data at high speed and serve the needs of large instfllations. The DP, FMS, and PA versions collectively address the majority of automation applications.

Unfortunately, the network comes with a high overhead-to-message ratio for small amounts of data and carries no power on the bus. Profibus also costs slightly more than other buses. The standard’s European and Siemens centricity is occasionally an obstacle for some North American users.

Foundation Fieldbus
Foundation Fieldbus has finally come into its own and is rapidly establishing itself as the future standard for process industry networking. Since its official introduction in 1997, many distributed control system vendors have embraced the protocol, developing and certifying devices that conformed to its specifications. This standard contends with Modbus, HART, and Profibus PA.

The fieldbus is a flexible, sophisticated protocol with many capabilities. It holds great appeal because it’s intrinsically safe and provides an integrated device-level/plant-level approach. Broader adoption of Foundation Fieldbus has been slowed by the protocol’s process-industry-centric nature, the limited availability of compatible devices, and the slow process of standardization. The fieldbus combines a device-level network, H!, and High-Speed Ethernet (see Figure 4).

The standard is typically used in distributed control, continuous process control, batching, and oil and gas processing operations (see

Figure 5. (A) Ethernet 10Base-T and 100Base-T require a star topology (i.e., only one node at each end of a wire). Multiple devices must be isolated by a hub or switch. Low-speed networks, such as AS-Interface and Foundation Fieldbus H1, can be wired in nearly any configuration, including a star (no hubs or isolation devices necessary), because at low baud rates, signal reflections are not a problem. (B) A trunkline/dropline topology defines a length of cable with "spurs" going out to individual devices. The trunk is normally impedance terminated on each end, and drops are limited in length to keep reflections under control. (C) In a daisy-chain network, the trunkline has no spurs, keeping reflections to an absolute minimum.

Figure 5).

Is Network Technology New or State of the Art?
What’s interesting is that the answer is really no. Ethernet and the Internet were developed in the 1970s, CAN in the early 1980s, and these networks are more popular now than ever before. Most of the other technologies mentioned here have been around for 10 years or more, but by no means are they obsolete. These networks have steadily grown as a result of two powerful forces: the falling prices of embedded technology and components and the growing expectations of sophistication and connectivity driven by the Internet.

Ultimately, networking is not a technology issue; the technology is there and is readily available (as will be discussed in the next two installments). The issue is the user who is often just becoming educated about the technologies and the political alliances that promote these protocols. Most network formats are to some degree tilted in favor of one vendor or another, and vendor issues have a significant effect on the choice of one network over another.

In the next installment of this series, the circuitry and some of the protocol/ firmware issues for the most popular embedded/instrumentation networks will be discussed. Stay tuned.

SIDEBARS:

Information Access: Hard wire vs. Network Control Variables/Attributes Accessible Through Both Hard-Wired Connections and a Network Flow/Signal Output (indicates actual flow through the mass flow controller, or MFC) Set-Point Input (receives command for desired flow rate) Valve Override (turns valve on or off manually, regardless of set point) Calibration Select (activates multiple stored calibration settings) Remote Transducer Input (allows MFC to become slave to pressure transducer, making it a pressure controller instead of a flow controller) 5 V Reference (allows the MFC to be its own set-point voltage source) Adaptive Valve Control (permits allowances for pressure variation) Additional Control Variables/Attributes Provided Only by a Network Actuator Control Value; Direct Control Command; Drive Value; Hysteresis Reduction Time; Leak Tight Offset; Limits Max. and Min. Offset and Span; Mode; Offset Actual and Configuration; Span Actual and Configuration Calibration Scaling Factor; Temperature Copy Calibration Record Flow Linear Polynomial A0, A1, A2, A3, A4 Full-Scale Calibration; Reference Pressure and Temperature; Time Base; TruCal; Unit and Value Gas Correction Factor and Method Gas Density and Standard Number Selected Flow Calibration TruCal Linearization Polynomials A0, A1, A2, A3, A4 Adaptive Control Enable; Integral Time Constant; Control Mode Analog Set-Point Input Span Calibration and Zero Calibration   Fast Flow Signal Pole Flow Controller P.I.D.; Error, Override, Safe State, Safe Value; Output Noise Filter Off Limit, Pole Pole Compensation Down-Step; Up-Step Compensator Internal Pole; Prefilter Pole; Prefilter Zero Pressure Controller P.I.D.; Output; Error; Safe State Set Point; Set Point Internal; Source; and Analog Low Flow Cutoff Softstart Ramp Rate and Type ODVA Device Type, Revision, Product Code, Product Name; ODVA SEMI SIG Device, Unique Identifier, Configuration, Device Type, Manufacturer Name, SEMI Revision; Hardware Revision, Model Code, Serial Number, Software Revision Flow Output Safe Value Internal Flow Signal and Raw Flow Signal Analog Function Select and Enable Available Contiguous Memory Diagnostic Select and Enable Enable NV Parameter Update PC-RT Controller Mode Watchdog Action Analog Output Selection Full-Scale Pressure MFC-RT, UOM-MFC-RT, and PCV/PM Pressure Linear Polynomial A0, A1, A2, A3, A4 Pressure Output Safe State and Safe Value; Sensor Zero Correction Value Remote Transducer Zero Correction Value Selected Pressure Application Temperature; Correction Offset and Span Bridge Zero Temperature Flow; Flow Sensor Correction Value Reading Valid

Honorable Mention Aside from the giants of the networking world that have been discussed in this article, you’ll find a number of less common, but important networks. Here’s a look at some of them.   LonWorks. Echelon’s clever peer-to-peer networking standard is good for large numbers of smart devices when high speed is not essential. This protocol is popular in building automation. HART. HART is a blend of digital and analog signaling techniques on intrinsically safe media. Frequency shift keying of a 1200 baud signal is combined with 4–20 mA signal levels so that analog signals and digital data can be transmitted simultaneously. Interbus. Developed by Phoenix Contact, Interbus is a ring topology that has the appearance of trunk/drop. By virtue of moving data in a ring, minimal overhead and maximum speed are attained. ControlNet. Allen-Bradley developed this high-speed, peer-to-peer, deterministic, controller-to-controller network, with built-in intrinsic safety and redundancy. Bacnet. This network was developed under the auspices of the American Society of Heating, Refrigerating, and Air-Conditioning Engineers (ASHRAE) and is popular in building/HVAC automation, lighting, security, and elevators. Arcnet. This technology is about 20 years old and is slowly fading, but it’s a great network nevertheless. The standard does not define an application layer, and as such, it has been used “under the hood” in countless dedicated control applications, often not even recognized as being Arcnet. Sercos. This network originated in Europe, and it’s designed for high-speed, multiaxis coordinated motion control, by virtue of time stamping and peer-to-peer communication functions (www.sercos.com). AS-Interface. This is one of the simplest networks. It is recognized by its two-wire flat cable, which carries both 24 V power and signal on the same conductor and is pierced by “alligator teeth” on I/O devices. It’s best suited for simple digital I/O (www.as-interface.com). Proprietary Networks. These are widely used, but they require a license from the technology developer. In general, use of proprietary networks in new installations is declining. Allen-Bradley Remote I/O. This network is designed for locating remote racks of I/O cards at a distance from a PLC. The standard uses a master/slave topology. Allen-Bradley Data Highway Plus. This standard is designed for PLC-to-PLC and controller-to-controller communications. GE Genius I/O. This network is designed for locating remote clusters of I/O points at a distance from the PLC. Modicon Modbus Plus. Capable of peer-to-peer communications and high-speed data transfer, this network is designed to link controllers, devices, and I/O. The Synergetic Fieldbus Comparison Chart gives specs and numbers for the most popular industrial networks. For an exhaustive list of network protocols, from popular to obscure, including hyperlinks to information sources, see Rob's Fieldbus Pages.

Back

---

Copyright © 2005. All Rights Reserved.
Perry S. Marshall & Associates
1131 Lake Street #295
Oak Park, IL 60301 USA

AdWords(TM) is a Trademark of Google Inc., Mountain View, California.
Perry S. Marshall & Associates is an independent consulting & publishing firm, and is not affiliated with Google.