|
|
 |
Customer Care
E-Learning Center
White Paper: When Technology Standards Become Counterproductive
Kenneth C. Crater, Chairman
Control Technology Corporation
Hopkinton, MA
Abstract
The adoption of technical standards in a high-technology
environment must be carefully weighed against the costs of so doing. In
fields where technology moves at a rapid pace, the ability to adopt new
technologies as they become available often means the difference between
being competitive or falling hopelessly behind. The current popularity
of the phrase Agile Manufacturing is testament to importance being granted
to such traits as technological currency.
The field of PLC programming languages has been ripe
for change for over a decade. Now, on the eve of a renaissance in this field,
an attempt is afoot to turn the clock back and freeze time. For what purpose?
To what end? This paper explores the topic and offers a strong argument
against the proposed effort.
Introduction
This document is drawn from a letter originally written
to cast a vote against the ratification of the proposed draft IEC Standard
1131-1, part 3. The arguments against this effort fall into two broad
categories, each of which, I believe, bear considerable weight:
- The entire concept of a standardized suite of languages,
presumably to become "the" accepted PLC programming languages,
is flawed and works against the interest of the user base.
- If such an idea were to have any validity, the proposed
standard is retrogressive and specific to the point of mediocrity.
In the computer science field, the idea of standardizing
on a single language or group of languages would be considered ludicrous.
In this specific case, the proposed standard appears to be simply an enumeration
of tired old languages which have been kicking around Europe (without
any substantial interest from the U.S. market) for the past decade or
two. One is led to wonder about the motivation for suddenly declaring
these a worldwide "standard".
There are numerous, quite specific, supporting reasons
for the above position. Space and time limitations allow me to explore
only the following.
1. - Arguments against the adoption of standard languages
generally
1.1 - Language Standards, Yes, Standard Languages, No.
If 1131/part 3 stopped at defining the syntax and visual
representation of Relay Ladder Logic, as an example, I would applaud the
effort wholeheartedly. The proposed standard, however, crosses the line
with its hubris of defining "the programming languages to be used
for Programmable Controllers...". Inconceivable!
This standard intends to stop the clock in 1992 (indeed,
in 1980), with its own limited vision of the future of programming technology
governing the future of automation. This will never happen, for two reasons.
First, one or more manufacturers of PLCs, responding to the tremendous advances
being made in software technology and data representation techniques, will
develop non-compliant languages offering insurmountable competitive advantages
to their product offerings. The remainder of the market will, and must,
respond in kind.
Secondly, the user base will bear witness to the
progression of technology and will become increasingly dissatisfied with
obsolete language representations (I already hear this from a number of
markets), creating a demand for language products embodying these new technologies.
Both of the above points rely on the premise that
subsequent technological advances will render the proposed languages ineffectual.
This is not a theoretical possibility, but in fact has already happened
to such an extent as to render the standard obsolete on its date of publication.
Some of the technical specifics of this assertion are explored further below.
I'm sure that, in defending the work of 1131/part
3, the standardization of ANSI C will be invoked as an example. There is
no parallel here whatsoever. ANSI C was a reaction to the proliferation
of many minor variants of the language "C", which variants served
little useful purpose and caused substantial annoyance to those porting
code among differing machine architectures.
Never was it suggested (at least, seriously) that
"C" should become "the" standard programming language
for computers. Further, it would appear that the C standard was passed just
in time for the language to become largely obsolete, replaced by object-oriented
languages for most new application areas. The utility of this standard could
therefore be called into question, as could the utility of passing a standard
for Relay Ladder Logic today.
1.2 - The hope of portability is illusory
One of the primary advantages to be hoped for with the
adoption of a standard language set is the complete portability of program
code from one programmable controller to another, even among different
manufacturers' products. Experience indicates that this advantage will
never be realized. There are truths which are fundamental to the programmable
controller industry which will insure this.
The proposed standard allows extensions (documented
as such, to be sure) to be added to any of the language representations
specified. Competitive pressures and opportunism will surely lead most manufacturers
to elect to include numerous such extensions in their language set. This
is especially true given the paucity of high-level functionality represented
in the languages as presented.
The nature of machine control is such that controls
engineers are constantly driven to reduce execution times, increase functionality,
and otherwise stretch the capacities of whatever programmable controller
they happen to be using. In some cases, milliseconds of improvement translate
into millions of dollars in savings.
In this environment, given the choice between preserving
language purity and increasing machine performance or, indeed, attaining
machine functionality, what will the controls engineer choose? It is a rare
company that would place adherence to a controls standard above financial
performance and, I predict, such companies will become more rare with time.
The result? A proliferation of non-portable programs,
just as we have now and to virtually the same extent.
1.3 - Standard languages work against the interests
of the user community
In actual practice, the true benefit of this standard
will be enjoyed by a small handful of major controls manufacturers, at
the expense of the user community. By defining the internals of an entire
class of products at a technologically mediocre level, products on the
market would appear homogeneous to the user. In such a market, the user
would be deprived of choice to the extent that market pressures exist
to conform to the standard.
There would then be an inevitable further concentration
of the market, as the major manufacturers continue to accrue market share
using their greater marketing resources, having neutralized any potential
for technologically superior offerings by newer competitors. They would
also presumably benefit from the economies of scale which their increasing
market share would offer.
Neither this concentration of the market, nor the
narrowing of choice and freezing of technology, can be credibly stated to
be in the best interests of the user community. Quite the opposite is true.
2. - Arguments against the specific languages defined
in the draft Standard
2.1 - Languages are low-level by contemporary standards
To call any of the proposed languages "high-level"
is a substantial misrepresentation. Each has been based on very low-level
constructs which parallel older forms of language/functional representation.
As examples:
- IL (Instruction List) is very close to assembly language
programming, one of the lowest levels at which programming is done by
humans. Further, most modern-day assemblers provide sufficient tools
to allow the user to create higher-level toolsets. IL has no such inherent
provision.
- LD is (by definition) a representation of mechanical
relays, i.e., Boolean entities. I have heard Boolean programming called
many things, but "high-level" is not one of them.
- FBD is a throw-back to the days when we designed
control systems with discrete gates, flip-flops, registers, and etc.
None of these elemental functions could credibly be termed "high-level".
The concept of a high-level language is to provide abstractions
which are closer to the needs of an intended application than the natural
language of the processor being used. The above languages do not meet
this test; in fact, they are merely simulations of outmoded past methods
of control design.
In contrast, contemporary practice in language development
is working toward very high-level representation of functionality, with
abstractions which "hide" execution details from the user thus
allowing him to focus on the application at hand. I have seen such languages
result in dramatic reduction in programming effort, to the point where programming
becomes a non-issue. The proposed languages will deny any such benefit to
users, locking them into older paradigms of program expression.
2.2 - The proposed communications model is outmoded
The use of globals and conceptual links for interprocess
communication in the proposed standard is a now-obsolete model for intercommunication
which will impose substantive limitations in the future. These limitations
will become increasingly apparent as system architects attempt to meld
such controllers into an object-oriented environment where messaging and
the use of agents is the widely-accepted paradigm.
While globals and links may be usable in a localized
implementation, I don't believe that the implications of this model have
been well thought-out with respect to their use in larger-scale plant networks.
A system designed using these tools is not extensible, nor can it be easy
to represent or manage at the plant level. It is likely that those who base
their automation strategy on such a model over the next few years will be
very sorry for having done so in the future, as these limitations become
apparent.
It should also be noted in passing that one of the
more powerful communications mechanisms implied by the proposed standard
is explicitly denied to complying programs. This is the hierarchical addressing
mechanism (e.g., %IW2.5.7.1), which could be quite useful for accessing
data across physical systems; its use as such is considered a non-complying
extension of functionality.
2.3 - Language representation is unnecessarily obtuse
Apart from the issue of language structure, the symbolic
representation system chosen for single-element variables seems tailored
to render the language unreadable (e.g., "%Q75" represents output
#75). I can think of no rational justification for imposing such cryptic
representations upon the user. Surely compiler technology has progressed
well beyond the point where such terse symbolism is not longer necessary.
It is also difficult to understand why the standard
feels compelled to dwell at length on specifications for a character-graphic
representation of language elements. This is especially puzzling since the
standard explicitly omits any full graphical representation of the same
elements. Certainly, the typical computer to be used for programming control
systems in the future will be capable of graphical display. Perhaps we could
save some trees by omitting the pages devoted to the crude character-graphic
function block specifications.
2.4 - Scope of standard is inadequate to secure benefit
A fundamental flaw in the proposed standard lies in
the scope of its influence. In a number of instances, it specifies sufficient
detail to prevent the cure of structural deficiencies, but allows extensions
which deny the user the primary benefit of portability. As an example,
foreign (i.e., beyond those contemplated by the standard) languages are
allowed to be utilized in the definition of a function or function block.
One suspects that this feature would be frequently utilized, although
it will surely impact portability.
On the other hand, the defined languages in the standard
are narrowly delineated, and the use of any extensions renders the user's
program non-complying.
2.5 - Structured Text language - what is it?
ST seems to suffer from the "neither fish nor fowl"
syndrome. Although it embodies some of the functionality of conventional
computer languages (and with it, the complexity and required skill-set)
it differs in enough respects to be truly annoying. If the standard is
to provide such a computer-oriented language in its scope, one wonders
why it didn't simply adopt C, perhaps with some realtime extensions in
the form of function calls. Here, even if one is accustomed to using computer
languages, an entirely new language must be learned from scratch with
such anachronisms as array subscripts beginning with "1" instead
of "0". If one is not accustomed to using computer languages,
ST introduces concepts which will have to be "unlearned" as
one progresses to "real" languages later.
2.6 - Overly complex language structure imposes a burden
on user
At first glance, the SFC framework in which the specified
languages may be cast seems to be a powerful high-level construct for
simply representing a complex program. Upon closer examination, however,
its actual effect is to impose another layer of complexity upon the program.
Instead of a unified language in which a relatively
small number of structural elements define the language, the proposed concept
of a language-within-a-language forces the user to think in two domains
simultaneously: a sequential domain at the SFC level and, typically, a combinatorial
domain at the step level. This seems neither necessary nor desirable; one
is left with the conclusion that the language(s) are attempting to please
everybody and, in so doing, end up pleasing no one.
In turn, this raises the broader issue of the utility
of a standard consisting of not one, but four distinct languages. These
languages, in aggregate, contain so many tokens that the standard will invite
(even demand) subsetting by the user community. Once this occurs, there
will be groups of users familiar with disparate segments of the standard,
such that one person may write a program which appears impenetrable to another,
even though both may profess to be nominal users of the standard. Large,
complex, multipartite languages have historically collapsed under their
own weight (ref.: Algol68, PL/1); I suspect the same fate awaits this one.
Conclusions
I strongly believe that 1131/part 3 is a damaging misuse
of the standardization process. In a technologically dynamic environment,
there is no place for standards which attempt to freeze the internals
of whole classes of systems. Instead, standardization efforts should be
directed toward boundaries between product classes. This latter form of
standard encourages technological development, the former discourages
it.
Even if the need or desirability of such a standard
is taken as a given, the proposed standard does not reflect current technology,
but rather seems to be an attempt to perpetuate dying and disadvantageous
programming paradigms.
At any rate, whether or not this standard is ratified,
I believe it will have little impact on the programmable controller marketplace.
Previous such misguided efforts have failed ignominiously (ref.: Ada); the
progress of technological development in a free marketplace will not be
impeded by an edict from a standards-making body.
|
