'Seamless' automation needs clever tailoring
John Pogson speaks out on why end users, integrators and equipment
manufacturers must be open when it comes to industrial networking
As recently as July 2003 the ARC Advisory Group reported on the uptake of
fieldbus by stating: For many users fieldbus compatibility is becoming a
key criterion for control system selection . In another paper from the
same organisation it reports that there is a plethora of communications
alternatives at the device and sensor levels . The warning however, is
that the piling of one communications protocol on top of another is
causing what ARC described as a Tower of Babel that will come crashing
down. The report goes on to suggest that as Ethernet and other fieldbus
options open up the scope for true interoperability, there will be pain
and suffering caused for those who resist by attempting to maintain
closed proprietary communications protocols .
There is little to argue about in ARC's findings and most of the large
automation vendors would support the arguments publicly. In practicality
however, there is a very long way to go. The demands of end users for
greater speed, capabilities and ease of use have come hand in glove with
an equally stringent stipulation that costs must be reduced in hardware,
software and maintenance. Against this backdrop, automation equipment
manufacturers have suffered declining margins and increased costs of
research and development.
It is little wonder then that delivery of new 'open' technology and a
willingness to jeopardise the business from an otherwise 'captive' end
user has been slow to reach fruition. Fears over loss of product
differentiation are a further inhibitor to opening up automation systems
to all who could contribute.
Users of supposed open and integrated systems must ask whether the
expansion of such a system is prejudiced by constraints imposed by the
original system supplier. Or, will such 'tailor made' systems burst at
the seams as soon as another vendor's technology is introduced.
The quest for a similar level of interoperability in automation to that
achieved in the computer world, relies on components and equipment from
different manufacturers acting together via a mutual interface. It also
requires that components from different suppliers are able to take on the
tasks of other components in turn.
For manufacturers of complex or critical components, it should be
obligatory to ensure interoperability with different and standardised
interface definitions. In other words, manufacturers of automation
equipment should be compelled to support a range of interfaces. This is
why, as standard, all the author's company's mechatronic drive equipment
supports no less than seven discrete interfaces, including Profibus,
MechatroLink, CANopen, DeviceNet, Sercos, SynqNet (Ethernet) and Firewire.
It is highly unlikely there will ever be legislation to ensure broad
compliance - there are already many 'standards' within the communications
industry. What will drive automation vendors is demand from end users.
The truth is that this is beginning to happen, as ARC's survey suggests,
but there remains, understandably, a high degree of ignorance among
engineers and there are few sufficiently aware of all the issues to draw
up rigorous and robust enough specifications to put vendors on the spot
when it comes to widespread compatibility.
Even at machine control level, incompatibility remains rife. In a recent
example encountered by the author, there was a servo system from one
manufacturer under the supervisory control of another maker's PLC. The
end user wished to replace the servo system with one of a more superior
specification, which in this case happened to be a system from the
author's company. Only by producing a special motion control interface
(running on Profibus in this instance), was the end user able to make his
upgrade. Without this specific intervention, the user would have been
'locked out' from making the retrofit. The anecdote raises an interesting
point. With products that are genuinely open and modular, the interface
is the only item to be made bespoke. The same cannot be said to be true
for all suppliers' products.
If the end user in the above example had been sufficiently aware of the
possibility of a future lock out on new technology, they may have been
more insistent on open control architecture at the point of sale of the
machine. In other words, interoperability must be driven by end users.
Only if users vote with their specifications will vendors generally
comply.
To redress the balance, it is fair to state that certain major automation
vendors have embraced the concept of truly opening their control
architectures and software protocols to overcome the rigid system in
traditional architectures that requires programming interfaces between
the various layers (protocols) in a stacked system. These efforts have
produced highly transparent systems in which the user can access all
devices, including drives and motion controllers, from a single point on
a standard PC. Other vendors are beginning to follow similar approaches,
but not before time.
It is also right to point out that the manufacturers of discrete
equipment, whether it be drives, motion controllers, PLCs or sensors,
must equally embrace the concept of supporting all fieldbuses and all
protocols. This clearly adds to both the product development costs and
the costs of manufacturing and stocking. Something no equipment maker
really wants, but nevertheless if customer demand dictates it, all will
surely have to follow the lead of their competitors in providing all the
options as standard.
Of course, if all manufacturers adopt such an open approach to their
equipment design, there is a greater need for them to be aware of the
current and likely future needs of their customers. Only by doing this
would their own future be secure and their customer loyalty assured. For
many automation suppliers, this would need a dramatic change of culture.
John Pogson is with Yaskawa Electric Europe, based in Germany
Click Here for more info using our Oline Enquiry Service with number 541