Remote islands of automation

During the many years I have been involved in automation I have seen many different systems but they have always had the common objectives of control, visualisation and integration with other systems. These systems have evolved over time into 'islands of automation' which use trusted older technology to implement new project requirements that can only be achieved using OPC, Ethernet, SQL, XML and other new technologies.

Many system developers - system integrators (SIs) and OEMs - having formed strong links with a group of manufacturers in the past, look only to their preferred suppliers to find what they need for new projects. The result is often that additional complexity is required to make a system work, even though developers use products because they know them and expect to expend less effort on the project because of that. Any design engineer will tell you that every job is 'the same but different' and it's the 'different' element that usually causes a problem. Many developers could save themselves time and money if they could look at each system project in its own right and choose the right products for the job each time, whoever makes them.

By making your design decisions based on manufacturers, you also end up with the many different programming packages they produce. The customer will ultimately have to buy these packages too, as well as any upgrades that come along, and many OEMs and SIs use this as a reason for not pursuing alternative solutions, mainly because of cost. This limits an integrator's flexibility, as there is no opportunity to learn and adapt to alternative systems. If a full range of alternatives is considered, then the integrator may find that cost is not actually the real issue.

Where there are islands of automation it is the customer who loses out. Invariably customers end up with a working system but not necessarily one that has been neatly integrated. At the factory this means extra training and support costs for the customer, and system developers will also have additional support costs and problems when demonstrating reliability. Poor reliability often means a developer does not get paid, and any problems with a new system tend to damage reputations, which will matter when the time comes for the next contract.

There are many examples to be found in industry. For example, one OEM had developed washing system over a number of years using a low cost PLC. Another OEM has developed a similar machine using a different, medium cost. There are only 128 I/O points on each system, so the programs are not that big. A large customer specified products from both OEMs for its new facility. Because the customer required these machines to communicate with each other, the OEMs will need to spend approximately £1200 on a gateway, and each OEM will spend approximately two weeks engineering the integration. IEC 1131 was supposed to the saviour for cross platform programming, by allowing different program code to be ported to any manufacturer's product. Most integrators by now have realised that this does not work, due to the special function limitations in all manufacturers' products as these special functions are not supported by the 1131 standards.

It is the manufacturers' responsibility to educate their customers in current technology and these manufacturers should realise that it is more important to provide a sound system than to supply 100% content on a project. OEMs and SIs owe it to their customers to keep up to date with the market, as their time will be paid back in full by savings on projects and customer satisfaction. Remember that not every project is cost driven, as invariably customers are prepared pay for a good design that meets their requirements. If we focus simply on cutting the cost of system components we can't expect to move technology forward at the pace demanded by industrial standards today.

Terry Price can be contacted on +44 (0)1892 785755 or at terryprice@lineone.net