One of them is the system named data-pool, which is intended to act as a glue logic and to coordinate multiple application processes by means of messages sent via the inter-process communication over the network. Using the data-pool system, as all the information is exchanged by the inter-process messages, the user can easily program data sharing and task interlocking among multiple application processes, without any knowledge about the inter-process communication nor the networking. Furthermore, this system includes event notification and condition monitoring features to eliminate needs of data polling among application processes. Using these feature, all the behaviors among the application processes are concentrated within the data-pool system, and each application processes achieve high modularity and maintenanceablity.
Another is the Factory Automation Programming Language Processor, which controls equipment and monitors status in the manufacturing work-cell, running with the data-pool system. The language specification is designed to ease describing the task done in the manufacturing work-cells.
The manufacturing work-cell is requested to have following functions;
In the production area, the manufacturing work-cells as described above are installed and connected by some transporting systems and a communication system. Work-pieces and production data are distributed on demand requests from work-cells, and the results of the process done in work-cells are returned for the following requests. This imaginary field, which resides outside the work-cells and consists of storages for the work-pieces in process and the process / control data, is named as coordination field, as this field connects many work-cells by means of work-piece and information. Using the concept of the coordination field, we can easily design autonomous production control system.
Figure 1: The model of manufacturing work-cell
In the manufacturing work-cells, the work-cell controlling and monitoring software systems should have abilities to realize followings.
To achieve objectives listed above, the data to be handled in the work-cell controller software systems consists of followings.
In order to make the work-cell control systems autonomous, it is important to use these various data freely and timely. Moreover, these data should not have any contradiction in any instant. As these data should be represented in the work-cell controller software system, the FA programming language is requested to be able to handle these data.
In the following sections, these two elements of the FA Programming Language Environment are described.
The data-pool system is based on the client-sever model of the transaction processing, and basically consists of one server and multiple clients as many as users wish. The data-pool server system works as a process running on the work-cell controller operating system, and application programs including the data-pool clients are operated as other processes which communicate with the data-pool server process using inter-process communication vehicle provided by the operating system running on the work-cell controller.
As shown in the Figure 2 below, the data-pool server consists of two major parts; the communication interface subsystem and the data management subsystem. The data management subsystem also consists of two parts; the data change monitor subsystem and the data storage subsystem. The data storage subsystem manages association between the name and its data provided by the client. The access and / or update request from its client is processed by the communication interface subsystem, and the data retrieved from the data storage subsystem is manipulated according to the request.
Figure 2: The data-pool system
If the data-pool server has multiple clients over the network system, those clients can share all the data by means of accessing the same server. When some data in the data storage subsystem are changed by means of update request from one of clients, the data change monitor subsystem sends the notification messages to the clients registered in advance. Moreover, some relational expressions representing conditions can be registered within the data-pool server, and the data change monitor subsystem sends the notification messages when the condition is met. Using these feature, the data-pool clients need not poll the status of their interested data or relations amoung data.
The name is something like variable identifier in programming language,
and each of them can have a value. The name is a sequence of some identifiers,
separated by a period, such as
abc.ijk.xyz. Using this format,
users can denote data structure by the name sequence. For example, users can
use the name such as:
<item_identifier> . <aspect_identifier>to represent certain aspect of certain item. Using this notation, the application programmers can implement arbitrary data structures using names. In the elements of one structure, their names contain same identifier sequence in its leading part, and the trailing part of their name differs from each other. The leading common part is called stem and the trailing part is called variant.
Each name may have some attributes. The attributes denote optional settings or functions of corresponding names, and the data-pool system changes its behavior according to the values of attributes.
As the value of the name, application programs may specify one of followings; integer, floating point real, character string, expression and link. As the name itself is not typed, users may bind different types of data in turns. If a client accesses the name bounded to an expression value, the expression is evaluated and the result is returned to the client as the value of the name. Using the link type value, users can access one value with more than two name. This is equivalent to the function of the "symbolic link" found in many of the tree structured file systems, and users can use values of this type as pointers.
As there are some names which are deeply related to each other, those values should be updated simultaneously to keep those values consistent. In the data-pool system, there are many application program interface (API) used to change values of multiple names with only one transaction. For the names which values are updated by multiple clients, there is another API to do mutual access control.
On the time when the data-pool server system receives data update request, the system searches for the clients registered as the notification destination, and then notify the fact of change to all the registered clients. In this way, the application programs are free from polling to find the change of status.
The each name of the data-pool system can have a dependence list as the name's attribute. If the name listed in the dependence list is updated, the value of the name is updated to the result of a certain expression, which is also registered as the value of another attribute.
Using this mechanism, if the values of more than one names listed in the dependence list vary, the registered expression is evaluated and the result is assigned to the name itself as its value. If this new value differs from the former value, the data change notification is sent to its subscribers.
The condition monitoring can be done by registering conditional expressions. With this mechanism, user can implement multi-way branching by comparing value of a name to the constants. Usually, only one of them holds true, and the corresponding application program is notified. If the branching is implemented as above, users can add another selection later without changing any existing application program, but only adding new condition expressions comparing a name and a constant. This flexibility is implemented by the data-pool system and the registered condition expressions.
Assuming that users make it a rule to set the execution result or final status to the name in the data-pool system at the end of each process execution, this status updating causes the following tasks to start their process, just like falling dominos.
As the data-pool system can link the application programs coded and compiled separately using the shared data and the notification messages, those application programs obtain high modularity and readability.
The independent requester has very limited user interface, but can request all the operations available in the data-pool server.
Some panels can be shown on the display in turn, and the application programmers can define multiple fields in a panel. Each field has its origin point, width and depth, and foreground / background colors as its attributes. As these parameters are also defined in the data-pool system, the size or location of the field can be dynamically changed. Therefore, simple animation can be displayed on the screen, and this subsystem is enough to be used as a status monitor display panel.
On the screen of the data-pool inspector subsystem, the names or attributes selected by the user is listed vertically. On the right of them, its current value is displayed. In order to update those data, user places the cursor on the current value to be changed and overwrites the new value on it.
After the overwriting has been completed, user should do the "commit" operation. This operation causes a transaction to update the values. The data-pool system has two kinds of update transaction. One simply updates the value and has no concern for their old value. Another transaction first compares the values of selected names or attributes to the data sent from the client. If all the values are identical to the data from the client, then the values of the names are updated. Otherwise, the contents of the data-pool remain unchanged and the current value of the selected names are sent back to the client. Using this "secure" transactions, the data-pool system realizes semaphore operations.
The Sequential Function Chart (SFC) is one of such diagrams, which is added external signals as the firing conditions. In this diagram, the transition is fired if all of its upstream places are fired and all of its incoming external signals have logical true value. Once the transition is fired, the upstream places of the transition are now not fired and its downstream places are fired.
This relation is easily translated to the scheme of the condition monitoring in the data-pool system, assuming that the values of the names are updated by associated processes to the names, when those processes have completed their tasks, or when they have checked the status of external signals. The value of the condition expression is evaluated, at each time when one of names being referred in the condition expression is updated, that is when one of the preceding processes completes. The registered condition is met only if the value of condition expression becomes logical true, and then the notification message is sent to the data-pool client, that is the trigger to start the successive processes.
The condition expressions registered to the data-pool system can be made from SFC diagram automatically. Assuming the tool which has graphic interface to compose SFC diagrams and is able to generate condition expressions for the data-pool system, the application programmers can define the relations among the application processes using interactive graphic interface, and the generated condition expressions can be directly loaded to the data-pool system. Making glue logic among the application processes becomes quite simple and easy to maintain.
The data managed by the data-pool system is represented by a union type of the C language. This type is named DataCell, and the library package also contains a complete set of functions and macros to handle this data type.
The data-pool API consists of three types of the interface routines, which are;
The last type of the API includes following categories of API;
As this protocol is completely independent from the network communication vehicle used by the package, any kind of networks can be used as its vehicle. Moreover, the protocol is completely hidden from the application programmers, the transplantation work of the application program is quite simple.
All request transaction from the data-pool client is compressed within single message, and is sent to the data-pool server. At the network interface subsystem in the data-pool server, all the requests from multiple clients are serialized and served in first come first served basis. So, all APIs are atomic operation for the data-pool server.
The FAPLE language processor is a kind of object oriented language interpreter system. This language is designed assuming the existence of the data-pool system, and it owes the data-pool system the global data management, as well as inter-interpreter communication, process synchronization, mutual execution and condition monitoring.
As the process of the FAPLE language interpreter can be started from the data-pool system, the action of a certain condition can be composed in this programming language. In this case, if the condition met, the data-pool server invokes the language interpreter process and send a message to the interpreter process just created.
Furthermore, followings are assumed to enhance its usability;
The message based execution is not always good in the statement level, because of its large over-head. But it is very effective for the information hiding purposes, and especially for the virtual manufacturing device (VMD) control. So the author selected the data abstraction rather than the execution efficiency.
But this problem is still left open, and the further study is seriously required.
<receiver_object> . <message_selector> ( <argument_list> )where the argument list is the comma separated list of the expressions, and the list is optional.
The FAPLE language processor searches for the appropriate method to the combination of the message receiver and the message selector, and then executes the method found to evaluate the value of the message sending expression. The method searching is done by the language processor at the evaluation time, not at the compilation time.
Though all the processes executed in the language processor are expressed as above, some frequently used operations are expressed using unary or binary operators for the simplicity. But also in this case, the expressions with the operators are once translated internally to the message sending expression, and then evaluated with method searching.
In order to express the need of synchronous data updating, following structure
Atomic <statement_list> EndAtomic
The assignment done in this structure is deferred until the structure
completed, and then they are updated at the same time. The data is not
updated while the statements inside is under execution, so the program:
Atomic A := B; B := A EndAtomicswaps contents of variables
Using this protocol, a structure for mutual execution is expressed as follows;
Exclusive <name> Then <statement_list> EndExclusive
In the FAPLE language system, every process can register a statement for each
exception, which is executed when the exception occurs. When the occurrence
of some event is expected, the exception control statement should be coded
with following syntax prior to the occurrence.
Exception <identifier> Then <statement> EndException
If the exception occurs in the period from the execution of the exception statement until the completion of the method in which this statement is included, the method with the exception statement and all the methods invoked as its children are aborted, and the specified statement is executed instead. This operation sequence is illustrated in Figure 3.
Figure 3: Control flow of the exception handling
The binding of the exception and its handling statement is kept dynamically, and old handling statement is pushed down if the new exception statement is executed while the former is still valid.
Daemon <name> As <statement> On <condition> EndDaemon
The specified condition is registered to the data-pool system, and its value is evaluated every time its referring names are changed and is assigned as the value of the specified name. If the value becomes logical true, the notification message is sent to the newly created language interpreter process, in order to make the specified statement being evaluated.
These classes should be defined and be arranged in the tree structure. As the system expects that the classes far from the root of the tree structure describe more specific and detailed objects, the arranging order in this class hierarchy is very significant.
In the case of the device controlling classes, there should be methods for some purposes such as real-time control, run-time simulation for scheduling, automatic control file generation, and execution simulation for program verification. If the single class should have all the methods belonging to all these categories, the number of the method may be too many to manage. In those cases, it is thought effective that making the class describing the device specifications and the classes containing methods for each categories separately and arranging them as the former near the root and others as its descendants.
There are many application programs and operating systems which have many useful tools, but the succeeded systems among them have sophisticated mechanism to integrate prepared tools.
The author would like to emphasise that the smart glue mechanism is the very thing to make the programming system powerful and easy to be programmed, and also hopes that the data-pool system is the good candidate of such glue logics.