Over the past decade, many third-party software developers who created and ran software for hardware manufacturers have disappeared. They were once essential because engineers who developed hardware could only develop hardware; they didn't write software. Most manufacturers still keep their automation solutions technology secret to retain customers who are tied down and unable to leave. You have to use their software, data cables, and methods. There's no development. In the technical field, "development" is defined as "the process by which something gradually transforms into something else, usually becoming more complex or formally improved." In the case of PLC development, or what we might call "incremental," has the PLC developed? Has it improved? What formal improvements has it made? Of course, it's much more complex than that. I've been involved with PLCs and automation for 30 years now. When PLCs started, they were a groundbreaking technology, described by Dick Morley as the "PDP-11 tractor," the acknowledged inventor of the PLC. The PDP-11 was an integrated circuit microcomputer. PLCs aren't as magical as you might imagine. Sometimes you have to bang on them to run, there's no button to turn them off, and they don't look cool at all. Oh, and back then, they were incredibly expensive. So what has happened to the amazing PLC and its robust supporting systems over the past 10 years? During my years working with PLC instructions, I was always told that a PLC is a control system—whatever it looks like. What matters is what it can do. A PLC is an electronic device—with programmable memory, inputs/outputs, and a power supply—that executes instructions input by the user. Yes, it's a computer, but back then we didn't have that concept. We also needed a programming device to input those nasty addresses into the machine. We controlled these discrete applications and software, and then processed them, as our vision blurred, and the PLC evolved into a fully-fledged automation controller. This is important. Every vendor, whether it's Texas Instruments, Siemens, Struthers-Dunn, or Allen-Bradley, has its own way of doing things. Over the past decade, many third-party software developers who created and ran software for hardware vendors have disappeared. They were once essential because hardware engineers could only develop hardware; they couldn't write software. But that has changed. Ten years ago, when IEC-61131 first appeared, it was based on an old-fashioned idea. The hardware vendor's ownership-first nature created market opportunities for many companies, but also added a nightmare for users. Wasn't the phrase "constrained and unable to move" enough to wake everyone up? It was in this environment that a group from GM Powertrain began developing OMAC, Open Modular Architecture Control. This group promoted the use of open standards and open connectivity. I believe this opened a path of evolution leading to where we are today. Who could have imagined that DeviceNet devices from many suppliers would come together in the same field? This in itself is progress. Today's PLCs offer more than 30 times the price and performance of 10 years ago. The performance of a small PLC series is equivalent to that of a medium or large PLC series from the previous year. The difference lies in the input/output calculations. Remember? Ten years ago, 256K of random access memory was expensive. Small size and wide distribution define PLCs today. In those golden years, the contributions of large PLC processors to central control were undeniable. Now, the feasibility and diversity of communication platforms allow for even wider automation distribution. The advent of Windows 95, seemingly concerned that we had forgotten the importance of software, ushered in a new era of software-based computer systems. What used to take an hour can now be done in five minutes. Operability has increased billions of times. It's not that we didn't have software before, but rather that current software is easier to use. Windows, compared to DOS, offers a more refined development platform. The learning curve is no longer just a sharp climb. After all, "It's Windows!" Thank goodness! We've witnessed the evolution of automation from large, truck-hauled computers to laptops. How I miss the days of keyboards and cassette tapes! Until I realized that what we have now is far better. Morley believes that PLCs are evolving into tools, and these tools are best used with internet access (specifically, IP access). He has developed a home PLC, PERTASCO (Personal Task Controller). Its ease of operation has made it widely popular, and registration is unnecessary. He feels that software development in this field is too vendor-driven today, and users are being lost. A central theme I follow when discussing this article is that today's PLC programmable controllers have evolved into PACs (Programmable Automation Controllers), a definition given by manufacturers. There are significant differences in market distribution between PLCs and PACs, but the functional differences are minor. This is the first significant point on the PLC evolution curve. A PAC is, by definition, a PLC. It has everything a PLC system possesses, but there are differences. Lee Lane, Production Manager for Automation at Logix Rockwell, says, "PACs can handle discrete, motion, drive, safety, batch, and control applications with a single, universal control platform." PLCs did this 10 years ago, and Heck systems did it 20 years ago. The PLC-3 comes with Advisor drawing or Modvue drawing provided by Modicon's PLC584, which is really cool! Remember the GA module? Why a new definition? Development, my dear reader, our topic is development. The integration of components and functionality is the single and biggest reason for the development of PAC. We could do this kind of interdisciplinary thing before, but not very well. This is not to say that everything is hindsight, but nothing can be done perfectly from the beginning, and making changes is indeed painful. Lee says that with the architecture of PAC, you can embed a series of motions in software in less than five minutes. This is an undeniable advancement. He attributes the shift to PAC application environments to the commercially promising need to improve factory efficiency. He says that the surge in data requirements has made it imperative for IT engineers to have a more comprehensive solution. A common data source allows integrated hardware and software to flow freely through a comprehensive data channel. Lane says this allows them to categorize resources according to the information needed. Bill Black, the controller production manager at GE Fanuc, agrees, but he gives a different reason. He believes the emergence of PAC systems stems from a global demand for reducing production costs and increasing the performance of standardized hardware architectures. He says that many new software tools have entered the market over the past decade. This software has enhanced engineers' capabilities, enabling them to design efficiently and rapidly. For example, if a specific processor is used at a particular step, information about heat can be obtained instantly. Remember, there are no fans to cool the central processing unit in automated systems. Flash memory and surface mount technology have allowed GE to design better non-proprietary architectures, guide users and provide them with better application software, make design and construction easier, and allow for migration to different platforms if needed. I also believe this platform has made the most significant contribution to integrated systems. Opto 22 has a slightly different perspective on this “incremental” automation. Opto 22 started as an input/output company. Rich Ryan, then president of Rockwell Software, said at a meeting, “I’m asking every holding company to become an input/output company, and I’ll stop things like processor production.” That was about 10 years ago. While Opto 22 now also offers PAC systems, they would still say that Ryan was right back then in terms of profitability. Many manufacturers still confine their automation capabilities to a box somewhere. This way, they can keep a constrained audience. You have to use their software, data cables, and methods. There's no development. Benson Hougland, Vice President of Marketing at Opto 22, points out that the processing power available today allows input/output subsystems to process data automatically. You can hold that power in your hands if you want, keeping the process under control. Ten years ago, we couldn't do these things. Opto says that what made this possible is Ethernet, along with the idea that Ethernet could be a public transit system or a global physical medium. Hougland also says that Ethernet input/output systems can be independent members of the control network, directly interacting with higher-level software applications. Opto 22, like many others, believes that future collaboration cannot occur without the flow of data. Tracking and control are two different things. I believe that the shift from a central controller—which is control—will feel foreign to some and will be ridiculed by some manufacturers. Therefore, the development of PLCs is PAC. However, it's still a PLC, with user input instructions, memory, and input/output. But we can do much more easily, and our weekends can be free again. However, our pace of development isn't fast. I believe that in the next 10 years, the pace of development will be different. As Morley said, all of this must be powered by the Internet. This includes: Ethernet, IP technology and network services, and the ability to make information available to anyone, anytime, anywhere. The offers provided by our control system manufacturers already meet and exceed these conditions.