Back Compile
ICL depends on Back Compiling to achieve efficient execution (through an internal execution friendly interpretive p-code format), which is Back Compilable to the readable visual ICL form. In this case, Back Compiling is the process of taking an internal computer readable form and converting it (back) to a human readable form, essentially identical in meaning and appearance to the original input form. As applies to ICL the process is elaborated in the discussion of the Small System Language and the SuperVariable, and illustrated in the reference.
With respect to ICL, Completeness covers the goal of not only addressing all operational control (sequencing, logic, continuous) efficiently, but capturing these functions within higher level practices either by built in capabilities (Idioms) or clear user expression (States, Recipes).
By contrast, commercial block systems handle logic (as AND and OR blocks) awkwardly and inefficiently, and Programmable Controllers are equally inept with continuous control.
(Control) Idiom
A Control Idiom is a named concept consisting of a standardized control strategy with a well defined process/processing related intent. In a formal context, such Idioms are to be defined in a specialized formalism within the Idiomatic Control Language or any similar intended practice. In ICL Idioms address the continuous feedback control. For the unfamiliar, Idioms tend to be confused with Objects in the sense of Object Oriented Programming. But their real function is at a higher level, much more like the Patterns within the same Object Oriented Programming. Thus Idioms, like other Patterns represent a collection of usages intended to support a higher level Intent and function.
The reason for the term Control Idiom is that the different intents in a control design are implemented by sets of implementing functions whose collective intent and behavior would often not be evident to a user unless he were widely familiar with the practice, in the same sense that a language idiom is not necessarily clear unless the listener is familiar with the language practice. But a Control Idiom is then given a short appropriate name to clarify and document its function to the user or anyone else. The confusion in looking at a control structure without the help of Idiom notation is exacerbated when several Idioms are implemented in a collective interacting way.
Footnote Example
ICL Footnotes are expressions of control details keyed to a larger computation by numbered, daggered, or asterisked footnote references in that larger computation, where those details are intended to be executed as if programmed at the referencing point, sometimes under particular conditions related to the particular type of Footnote. The illustrated Footnote is linked from the SuperVariable table below.
With respect to ICL, Integration is the designed interplay between all different classes of function (e.g. logic and continuous control) with the goal that the entire control function behaves in a clear and natural way, predictable from point of view of the both lowest computation and highest level of intent and practice.
Intent Based Programming/Modeling
This is a programming/modeling of the application based on describing higher level control system functions in terms of stated lower level user intents rather than the associated implementations. Intent Based Programming applies when the associated implementations are automated within a realistic and complete application practice. The goal is to allow application clarity whereby the stated user Intents are clearly related to an underlying (control) implementation established and standardized by the practice. Ideally the Intents fit within a formalization and graphic representation which naturally distinguishes viable control combinations from errors of Intent Language usage, and relates to a separate implementation formalism and graphics.
Because the Intents express the application more transparently and in much less specialized detail it is feasible not only to automate the implementation of the intended function but of other naturally related functions. For example control Intents are related to human interfacing Intents and maintenance Intents. Their implementations are as naturally related to the control Intent and standardized practice as the control implementation. They can thus be similarly automated. Intent Modeling relates to earlier use of the term Knowledge Engineering except that the model design is intended to generally recognized implementation strategies not private mysteries.
Large System Language
This is the version of the language described in most of the papers (and in an associated patent), which divides an application into a hierarchy of Operations each representing the control of a different part of the process. Each Operation includes multiple Tasks and Activities representing different control functions to be applied to that part of the process. The Operation is represented on distinct functional Pages: Procedures, Definitions, Parameters, Details, each representing different structural aspects of Operations. For example, the Definitions page defines the process variables in a special flexible tabular format called a SuperVariable. and the Procedures Page includes the programming of the Tasks and Activities.
The ICL List is used instead of vector notation. ICL Lists, separately named or not, can take the form of lists of variable names or values. The former allows any set of variables to be used in terms of their names without creating a redundant vector, artificial to the user, whose element values equal the corresponding values of the individual variables.
Process Control
In the immediate usage, Fluid Process Control is the control of industrial processes making or significantly using homogeneous fluids or materials: Oil Refineries and Chemicals, Foods and Drugs, Power, Mining.
Self Aware Box
This is an earlier concept attempting some of the same objectives (as Intent Based Programming). In support of distributed control systems, a Self Aware Box was defined as a distributed element whose operating software was based on a clear functional conceptual model, like the block diagram (function block), Sequential Function Chart, Ladder Diagram, etc. The intent was that the model defined the relation between the natural objects of the model and of other related Self Aware Boxes. The concept anticipated the different languages underpinning the Programmable Logic Controller as expressed in such standards as ISO 1131. While the intent was the same kind of integration provided by ICL the level of the conceptual model emphasized control implementation rather than Intent at the level currently envisioned. The Self Aware Box is a lower level predecessor of Intent Based Modeling.
As defined here, Self-Documentation provides automatically generated and formatted (pretty printed) program listings for any user which reflect the currently running (back compiled) control program in standardized layouts with redundant illustrating graphics. More detailed design discussion elaborates these concepts.
The Self-Documentation aspect is a key commercial ICL characteristic. The controls implementing engineer is generally the least trained or inclined to properly document the control application, particularly as the design evolves over time. But with ICL the related goal is to automatically provide clear documentation; if it works its documentation is also current.
Small System/Field Device Language
This is a simplified version of the language based on the SuperVariable (augmented by Footnotes) and a concept of a field device as an extended sensor or actuator control. This is established in a way capable of carrying out any form of control function. The different process variables can be thought of as being represented in a SuperVariable with flexibly chosen Attributes. Any additional computations are expressed as appropriate Footnotes. From an implementation point of view, the consecutive Attributes of all these SuperVariables are combined into a Single SuperVariable, with appropriately inserted Footnotes. The resulting sequence of Attributes and Footnotes is scanned and executed every sample time. This language form is described in one reference and a patent.
SuperVariable table
Generally an ICL SuperVariable is a Variable defined, with other similar Variables, as a sequence of Attributes under a shared set of associated Attribute Headings. This permits such a set of Variables to be displayed as a table under the shared headings. In addition the real time implementation of the Variables processes these Attributes and headings, in sequence order, each sample time. Thus their ordering is restricted to those making computational sense. The illustrated SuperVariable table shows typical Attributes for real valued input variables, except that the TF Input Attribute is replaced by a Footnote link to the Footnote above, which would compute its value from TRF and TFF.
In the Small System implementation all of the application variables are further strung together in sequence so that all of the Attributes of all variables constitute a single sequence which is to be interpreted in sequence once each sample time. The application also may contain Footnotes which are implemented embedded in the sequence at the appropriate execution point. Thus the whole run time program consists of a single long sequence of Attributes and Footnotes. However, when the program is displayed, Footnotes and Variables are sorted out and displayed in appropriate tables and statement listings. The reference illustrates a NeXT computer prototyping effort where a hand compiled p-code representation in SuperVariable format is interpreted to control a simulated process and automatically Back Compiled to show some of the implications of all of this.
A colleague has pointed out the analogy between the SuperVariable, encoded as a long string of independently programmed p-coded Attributes and Footnotes, and the biological DNA, encoded as a long string of independently positioned codons or genes.