Your automation controller — Powerful, Tailored, Supported.

When Technology Standards Become Counterproductive

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.