Comment

1 April 2002

How about some Java with your automation?

By John s. Rinaldi

A few weeks ago, in the hallowed halls of a major PLC vendor, I attended a memorable presentation by a marketing executive. Mr. Marketing has apparently spent his entire automation career within the insulated, sanitized walls of a large corporation; his myopic presentation proved it.

To my absolute disbelief, he tried to dazzle the audience with his company’s plan to lock its large customers even more tightly into its one-vendor, proprietary solutions with a smattering of open software and systems. The latter appeared to be a token offering to those that need an open systems life preserver.

His fiery presentation made me wonder whether he received these plans from stone tablets. The plans were as old, tired, and inflexible as stone itself. Mr. Marketing doesn’t understand changing customer demands, changing technology, and skill sets needed for the future.

Today, the world is about truly open, platform-independent systems; very fast time to market; and off-the-shelf, portable components that expand open technologies into new domains and applications. Java will power this world. You can leave the PLC (and even the PC, for that matter), C, C++, and the rest to the archeologists.

Here’s what Mr. Marketing and his good ol’ boys club don’t seem to understand:

Instead of persuading overworked and understaffed development organizations to use their new language, Sun Microsystems tore the long-term planning page out of the Microsoft manual and decided to court universities.

Universities were quick to adopt Java, with its many teaching advantages, over other programming languages. Sun knows that when these students start product development, they will more likely have Java training than C or C++. Industry analyst firm Gartner Group has studies of university programming language support that shows this strategy is paying off:

• C++ instruction declined by 8%, while Java increased by 9%.
• 87% of universities now offer Java.
• 56% make it mandatory in computer science tracks.
• 13% have replaced Pascal with Java.
• 21% have replaced C++ with Java.

Pros and cons

Some of the reasons why universities were quick to adopt Java is its lack of pointers, strong typing, required object-oriented structure, platform independence, lack of global variables, and superior exception handling. Students grasp Java concepts faster than C++ and move on to advanced topics such as concurrency much sooner. If we allow that C++ produces faster code—a claim subject to debate—can that mitigate the faster development cycles, better data encapsulation, better tools, platform independence, and growing pool of Java programmers? With 4.1 million Java developers expected by year-end 2003 (according to an International Data Corp. report), where will automation vendors get engineers to develop and support their C- and C++-based architectures?

In addition, unlike the Microsoft "shared source" program, Java is free and available to everyone. While Microsoft has shared source with 1,500 developers, there have been more than 5 million API and source downloads. Sun and others offer free Web-based courses.

IT department pull

Large and small companies worldwide are converting their proprietary back-office systems to Java. These departments have the daunting task of supporting many legacy systems based on assembly language, Cobol, Fortran, and C on mainframes, minicomputers, and all sorts of PC platforms. Companies say Java reduces their support costs and reduces the need to discard legacy platforms. With their influential IT departments staffed with highly trained, enthusiastic supporters of Java, how long will it be before they ask their controls people why they don’t run Java in the factory? Given the superior financing and clout that IT departments enjoy, control engineers will soon push vendors for Java solutions. If you don’t have Java on your product today, you’d better have it tomorrow.

With Java’s "write once, run everywhere" operation, control engineers will finally have a language with interchangeable, easily supported logic. They can change control platforms as necessary. Also, XML data from control platforms can easily integrate into MRP and ERP systems. Open communication standards that link the factory to the back office are especially important to customers that presently know only labor and raw materials costs.

A utility model

With the variety of open computing platforms available to the control engineer, I/O processing and logic control functions can be easily deployed, redeployed, and replaced when needed with faster, smaller, higher I/O count versions.

The utility model, in contrast to PLC-centric systems, emphasizes I/O processing and logic control as tools to achieve quality and efficiency—not as an end in themselves. Java will be the catalyst for this trend.

I don’t know about you, but personally, I can’t wait. IT

John S. Rinaldi is president of Real Time Automation, which provides industrial network capability to OEMs. He is author of a new e-book, Industrial Ethernet in 90 Days or Less: A Plan for Product Developers.