Staying in control Java or Linux?

Chris Hazlewood, product manager for Mitsubishi’s micro PLCs, looks at trends in industrial controllers Computers and software are evolving at a terrifying rate and the PLC is no exception. Amongst the most exciting developments are Soft Logic, embedded PLCs and JAVA based embedded controllers (see panel next page). There has been a lot of debate recently around the topic of PLCs being replaced with Soft Logic (a PC running a programme that performs the function of a PLC), but most of it ignores the fact that a huge proportion of the market for PLCs is for PLCs with small numbers of I/O (input/output channels) designed to control the stand alone operation of an independent machine.

For these applications, especially if they are stand alone (and many of them are), the complexity and overhead cost of a PC cannot be justified and the major benefits of screen and keyboard for operator interface have no value in what are usually unattended installations or have physically hard environmental conditions. Also, the present rather unstable operating systems for PCs leave a lot to be desired, especially for unattended installations where a re-boot could mean a journey to a remote site during the night. Yes it is true that certain operating systems offer uncrashability – the ability to continue to process when all else has failed – but one has to question what good this is if the PC monitor is displaying the ‘blue screen of death’, hence the operator cannot check, monitor or safely shut the process down.

Embedded PLC Prehaps

No, Soft Logic has its market, but it lies in medium to large control installations where the operator interface of the PC is appreciated, where links to corporate IT systems and archiving to hard disc is a benefit, where networking is involved and where the alternative PLC solution would be quite costly. Changes in the micro PLC market will come from a quite different quarter – embedded PLCs.

It is a PLC stripped down to its essential components and packaged suitably for building into a product needing control facilities. At the extreme limit it could be a PLC on a chip. More usually it would be packaged on a small PCB sub-assembly, probably with a plastics case, that can be conveniently built into an end product needing control. The concept will be familiar to designers involved with the development of consumer durables such as washing machines, TVs and video recorders which commonly use embedded micro controllers.

Embedded micro controllers though, are typically fixed function, with the programme built in by the maker. Programmes are normally written using C, C++ based applications and are then compiled to suit the target device. This approach is practical because the products normally require no variation from unit to unit. But C based solutions are really a non-starter for an electrical engineer commissioning a one-off machine in his customer’s factory in a foreign country. Debugging is time consuming and difficult with many errors appearing as a result of compiling.

For real-time user programming, you need a familiar high level language such as the traditional ladder logic, or more recently the flexible structured text and sequence function charts of IEC61131-3. Fortunately, these languages can now be implemented conveniently in PC programming tools, so if you create a device that can run the resulting code, you have the PLC on a chip. In fact, if you look closely inside a micro PLC, you will find a PLC on a chip already. The challenge is to make the device ‘OEM Friendly’ by packaging it so that an OEM can assemble it into there product conveniently and without risk of damaging it, but without adding significant cost or size. Accomplish that and you have an embedded controller that can be programmed like a PLC.

An example is the Mitsubishi MELSEC FX2NC. In a housing just 30mm by 90mm by 75mm, this PLC packs 16 inputs. To programme it, OEMs simply use the familiar MM+ or PCS WIN programming tools that they use for the full size

Where next – to java?

Ladder logic and even IEC61131-3 were to some extent developed to suit historic approaches to programming industrial controllers, but although the tools are standardised, the resulting programmes cannot easily be re-used. Taking a programme written for a PLC from one vendor and running it on a PLC from another vendor is still a long way off.

In the IT industry, market pressure for applications that will run on MAC, PC, UNIX or any other flavour of platform (initially for the WWW) has given rise to JAVA. JAVA provides truly platform independent code because the programming interface has been removed from the direct control of the hardware. JAVA code is also highly re-usable because it is object oriented and because its structure breaks code into discrete component applications (called Classes or APIs). It is important to appreciate that JAVA is a programming environment and not a Real Time Operating System (RTOS). An example of an RTOS (subject to much debate) is Microsoft’s Windows CE.

JAVA is more than a programming environment, it is a method of programme construction and operation that offers many benefits over C and C++. For example, JAVA is able to employ classes not resident on the target machine, calling them down from a remote server as needed. Also, JAVA has eliminated pointer features that allow badly behaved code to reach out and disrupt other parts of the programme.

How can these benefits of JAVA be harnessed for industrial automation? Quite simply, it will require a JVM or JAVA Virtual Machine that can be run in the operating system of the target machine. At present, availability of JVMs is biased towards 32 bit processors, but modified versions are being developed for the 8 and 16 bit processors common in industrial controllers.

There is, however, a down side. In the case of JAVA, there are two key problems: memory efficiency and lack of determinism.

Because JAVA involves several layers of operation, the user’s JAVA program, the JAVA classes used, the code libraries to support the classes, the JVM itself and the operating system, the total requirement is greater than for an embedded controller. Similarly, because JAVA is compiled at run time, and some classes may need to be fetched across a network, operation may be slow.

Together these two factors make for unpredictable and variable execution time which is undesirable for real-time industrial control. However, developments in processor power and speed have made good old Ethernet so fast that similar limitations no longer matter and it is being adopted for higher levels of industrial networking including Fieldbus.

I believe that something similar will happen to JAVA platforms. For example, Mitsubishi has recently demonstrated ‘JAVA on a chip’, by porting the JAVA language to an M32R/D microprocessor with its 42MB of DRAM, 2kB of cache SRAM on board a 32bit RISC processor.