AUTRAN(ID:6514/aut044)


English-like process control language from CDC


References:
  • [Control Data Corporation] "Control Data 1700 AUTRAN process control computer system" 1968 view details
  • Gaspar, T. G.; Dobrohotoff, V. V. and Burgess, D. R. "New process language uses English terms," Control Engineering, vol. 15, pp. 118-121, 0ct. 1968 view details
  • Dobrohotoff, V. V.; Silver, L. and S. Bacher, "When user and vendor collaborate," Control Engineering, vol. 16, pp. 124-127, Jan. 1969. view details
  • Richter, J. A. "Process control languages and APL" pp277-281 view details Abstract: At the moment, the trend on software developing shows generalized and flexible macro-routines by which any user with an explicit knowledge to his process should be able to write his own software for control, optimization, and information. Generalized software are mostly of the compiler level type and the evolution of these languages in the on-line control field is lagging behind the development in general edp and scientific field by three to five years. The gap is easily explained because on-line control is complex, diversified in application and time dependent. That no standard on-line control language has become generally accepted yet is an important observation. Viewing the possibilities within APL it is remarkable that no APL system dedicated to process control is on the market although APL has been implemented since 1966. The present paper, therefore, is dealing with the general problems which arise for an APL system for process control but the discussion is made specific by referring to the experience by using APL on an IBM 1800 process control computer. An APL system for process control will here be called APL-PC in analogy to the APL shared variables system APL SV.
          in Proceedings of seventh international conference on APL Pisa, Italy 1975 view details
  • Takahashi, Hideyuki "An Automatic-Controller Description Language" IEEE Transactions on Software Engineering January 1, 1980 view details Abstract: This paper proposes a control-oriented Algol-like nonprocedural language called Condor. Automatic controller theory, in company with computer science, underlies many industrial fields. Sequential control is especially imporhat. So far, sequential-controller description methods have by and large been limited to graphic ones, which are unreadable in the case of large controllers. A higher-level linguistic approach has been considered unlikely. This paper proposes a language widely suitable for controller architecture description. A controller, in its nature, consists of many subsystems which work in a parallel manner, interacting with one another. This paper deems that a basic component is not a process, but a response. A controller is considered to be a responding system in which every reactor works together, having a relation and communication to one another. A Condor program is a role assignment list for the reactors; it is Algol-like and nonprocedural. All the statements work at all times, interacting with one another.
    Besides, a controller has some kinds of tree structures: one is that of information-collecting subsystems, another is that of information distributing subsystems, and a third is that of the hierarchical construction of the controller system. On the other hand a language also has some kinds of tree structures. It is nature, to express the tree structures of a controller by the tree structures of a language through graphtheoretic isomorphism. We can properly call Condor a spatial programming language. Condor is a language of a new kind. This paper will bring new progress into both the programming language theory and automatic-controlled engineering.
    For the readers unfamiliar with automatic control, this paper includes elementary explanations. Extract: Computer control languages
    There are many languages for computer control based on existing procedural languages; there are also a number of problem-oriented languages, for example, PROSPRO, BICEPS, BATCH, and AUTRAN. (For AUTRAN, see Section 111.) Although those languages are excellent in particular in the intended fields, it seems those are biased to computer science and do not catch all aspects of sequential control. After all, there is no higher-level control-oriented language which is general, natural, flexible, and powerful. We usually use ladder diagrams for sequential control description. Thus our way of description basically remains on a level with Shannon's work. Extract: CONDOR and AUTRAN
    AUTRAN is an excellent POL (problem-oriented language) suitable mainly for describing procedures for starting and stopping a chemical plant. AUTRAN basically pays attention to the change in the values of Boolean variables. An AUTRAN program gives a sequence of instantaneous operations each of which changes the ON/OFF value of a Boolean variable. This is in a complementary contrast to a Condor program which continuously indicates the ON/OFF values of Boolean variables, though Condor can also handle change-causing instructions of the pulse-type. AUTRAN basically considers control to be a procedure; however, it divides a procedure into three sections: an action list, an alarm list, and a display list. Since Condor is a spatial programming language, it is easy to divide a program into any number of sections.
    Extract: CONDOR
    Conclusion
    This paper illustrated a controller description language Condor, which is Algol-like and nonprocedural. It is worth calling a spatial programming language. Condor is to Algol what space is to time. A Condor program represents an organization of reactors which work together in a parallel manner and use tools if necessary. Condor is a language for describing the roles of the reactors. A nested block structure expresses a hierarchy of reactors. This paper proposed the meaning of "hierarchy" for a sequential controller. A distant source of this paper was the concept of parallel action and teamwork of cellular automata [...] ......In general, controllers neither terminate nor conclude, so that they form a class different from the class of all algorithms. We should investigate and classify nonalgorithms. "program" is not a synonym of "algorithm."
    The problem of loops is fatal for any system. Little difficulty will arise in investigating a system with no loops. The problem of loops is important especially in control-oriented circuit theories. How to handle loops characterizes a theory. Since a circuit is a simultaneous equation system, circuit loops are different from computer program loops in the following respect: all the circuit loops basically operate in a parallel manner. This is a difficult and interesting problem. There are some kinds of positive and negative feedback loops in a relay circuit. A negative feedback loop is a cause-killing circuit. Note: Condor is intended for bringing tree structures into relief. A system is composed of trees and loops.
    We can discuss the subroutine concept and extensibility of Condor. They have properties different from those of a procedural language.
    The most interesting course of future research are efforts to build both the pattern recognition (or responding-to- pattern) ability and the learning ability into a controller. A language for describing patterns, pattern processing, and learning is needed. The language should be founded on circuit theory. A learning description language will be concerned with a Condor-handling language, because to learn is to generate a new or improved behavioral program. The handling language should handle not only Condor, but also the handling language itself. For a learning mechanism itself is learned. (This selfreference property of the handling language is somewhat similar to that of a list processing language.) For pattern recognition, the pandemonium model seems suited to the philosophy of this paper. Our ultimate objective is to make the level of a descriptive language so high that an ethologist's description of animal behavior can be a controller description program itself.
          in Proceedings of seventh international conference on APL Pisa, Italy 1975 view details