BICEPS(ID:8184/)

GE Procedural control language
References:
  • G.E. Process Computer Dept. "BICEPS summary manual and supervisory control" 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 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
    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