PDL, a Process Description Language

Abstract :

PDL is an experimental programming framework for process control in manufacturing systems. It grew from a requirement of Fisher and Paykel ( an Auckland company, hereinafter referred to as F&P ) for a computer control system which would be robust to changes in the plant, product, and control hardware of their assembly line installation. Secondary desirable features were ease of making minor changes, and the potential for later incorporation of an "intelligent" diagnosis system. The suggested solution is an information-based interpreter with little fixed vocabulary and all system information kept in easily accessible databases. I shall describe the justification for, and operation of, this approach, and the limited progress made so far.

This work began with Mark Brodsky's M.Sc. thesis work, done in conjunction with F&P. The body of this seminar is written from something like Mark's viewpoint, but I don't guarantee to reproduce Mark's views.

How it began.

Started from contacts with local company.
Reasonably straightforward FMS, workcells, conveyor belts, production line.
Controlled locally by PLCs, coordinated in local groups ( pre-workcells ) by C programmes in Unix systems, with another C-Unix system as message switcher - supervisory controller.
Worked well.
But things changing more quickly these days. New customer demands ( wanted "batch-of-one" for individual orders, etc. ), new models, new product technology, new machine tools, new networks, new computers, etc.

Problem :

Their system was effective, but fairly old-fashioned.
Needed rewriting for every new development.
Workings obscure ( documentation terrible ).
programmes which contained lots of incomprehensible details.
( All C, defines on defines on defines, no documentation, .... )

No diagnostics at all, really. Fault -> C-level debugging.

Brief :

Find a way to keep F&P's programmes up to date safely without massive rewriting;
- and without disrupting production.
Make it easy for non-programmers to add "hints" known to be practically good ( engineer - programmer gap ( EPG ) );
Lay the foundations for a diagnostic system - and perhaps for programme proofs ?

EPG : Programmers and engineers regarded each other with reserve. Engineers : programmers slow, software soso; therefore possessive about PLC level, tend to do as much as they can for themselves, e.g. manage local messages within PLCs, so message sequence seen from outside is incomplete. Computists : engineers make arbitrary requests, don't understand the system, isn't consistent; so can't see good structure, build system piecemeal, hard to patch. Engineers request message from A to B; programmers have to patch programmes in two local computers and the supervisory system, check for non-interference with other parts of the system, etc.

Cause ?

A significant contributory cause of all these problems was the reliance on the C programmes to do everything. In effect, and in the absence of consistent and effective documentation, they were the sole repository of all the accumulated knowledge about the whole plant. Various people connected with the plant knew bits of it, but for the details - particularly the interactions between the components, which was where things could easily go awry - the C code was the ultimate sink of wisdom.

A further complication was that the code represented the programmers' understanding of the engineers' requirements - which was not necessarily precisely what the engineers had required. The engineers' specifications were filtered through the computists' knowledge of the system's communications networks, etc.; so a simple request for a signal to be passed between two machines could end up as a collection of software pieces on a computer local to the first machine, a network controller, and a third computer local to the second machine, with any meaning of the message disguised under some new numerical message type. ( That's a fabricated example, but in the spirit of the real thing. )

"Everything", as done by the C programmes, wasn't everything; it was everything that wasn't in the PLCs. This was another potential problem which was perhaps connected with the EPG. The PLCs were the engineers' job, and for the computists the machines started at the PLC boundary. From the pure control point of view, that didn't matter a lot, as all we need is a stimulus-response decsription of the machinery - but for diagnosis or programme proof it was a bad thing, because the machinery became a set of large not-very-comprehensible black boxes, with mysterious inner states, and often little to indicate what was happening. Also, PLCs might talk to each other, implementing complicated interactions.

Solution ?

All the problems come from the interment of the information in the C code. ( An assumption - could be PLCs, but there was nothing we could do straight away except regard them as part of their machines.)

That's a gross oversimplification - but consider :

• If the engineers could see what the programme was about -
  • they could check it;
  • they could write little bits;
  • they would be able to adapt it to new products and new machine tools;
• If the programmers could see what the programme was about -
  • they could find faults more easily;
  • they could adapt it more easily when new computers and software were acquired;
• If the system could see what the programme was about -
  • there would be a chance of automatic checking;
  • there would be a chance of automatic fault diagnosis;
• And pigs might fly.

But at the bottom of all this wild speculation, there seemed to be a grain of sense.
So we took the notion of information accessibility as our theme.

What was the information which had to be accessible ?

• It must be there somewhere.
• It must describe the process, the product, the plant .......
• ( Does it have to describe the programme ? - not so obviously. )

Being careful.

But let's not do it just yet. There are a few more questions to ask first.

How would the result be affected by

- a change in product ?

That's easy; if we could write the original, we can write the new one.

- or a change in machine tool ?

That's not quite so easy. This time, we have to change the instructions which the programme sends to the machine tool.

- or a change in production line geography ?

??? We haven't mentioned that at all.

There's more to this than meets the eye.

What determines the programme ?

If we want a system which is robust to all possible changes ( a generalisation, but not much ), then we want to know just what it is that determines how the programme is. Then we'll know what sorts of change are important.

Start by specifying the programme : it has to

The list of words in capital letters on the right is a selection of the factors which determine how the programme must be composed, for any change in any of these system properties will require a change in the programme somewhere.

• We need to know about the COMPUTER to compile into the right machine code.

• We need to know about the CODE which must be used to manage communication between machines, whether computers or plant so that we can make the communication work. It might be network communications, or device drivers, or anything. We therefore need to know about the COMMUNICATIONS NETWORK.

• We need to know about the INSTRUCTION which the machine must receive in order to cause it to perform the right action.

• We need to know about the TIME, which might also require communications. If the time is determined by a signal from a machine, we need to know how to receive the signal.

• We need to know about the MACHINE which performs the instructions - how to send a message to it, whether any reply is expected, any other details of the interface which have to be taken care of.

• We need to know about the OPERATION to decide which machine instruction to use.

• We need to know about the WORKPIECE to determine to which product it belongs, and thence which operation should be performed.

• We need to know about the PRODUCT to determine specific parameters of the workpiece - so we can do batch-of-one.

• We need to know about the PRODUCT TYPE to determine general properties of the product.

In the long term, we'd like to sort all that out, so that the REAL basic information was linked to all the parts of the programme which it affected in a systematic and - above all - formalised way.

Where does that get us ?

Well, it turned out to be rather complicated. It seems that practically everything in the world affects the executed code. If we want a really robust system, we have to take everything into account in the programme somewhere.

Does that help ?

NO :

Far too ambitious for a little MSc project. Many of the subproblems haven't nearly been solved yet.

That isn't a very good answer. Try another; this isn't a problem, it's an opportunity.

YES :

• It gives a context from which we can choose a topic to work on;
• It makes clear the sorts of information which might be important;
• It shows that - in principle - the information has to be available somewhere.

In practice, a lot of that information might be invisible - typically, in people's heads. But it's significant - and, if it changes, the code might have to change too.

THEREFORE : if we did compose a fully automated design and manufacturing system, we'd have to write it down.

THEREFORE : it isn't unreasonable to assume that, if we need it in our little part of the system, it can be written down.

Think about information.

The information is important - that's what determines the programme.

So for a robust system, the programme must change "automatically" as the information changes.

So why don't we put the information in databases, and work out the programme from there automatically ?

In a manner of speaking, that's what happens now. The database is the specification and documentation ( should there be any - one of our difficulties ); "automatically" means having some programmer decide every time there's a change how it should be encoded in C. We're not trying to do anything dramatically new in principle - just to clarify, systematise, and automate the traditional process.

By the same token, we don't expect ( or need ) to do the whole automation job in one go; we're quite happy to leave a large proportion of the system implemented on people rather than computers. "All" we require then is some formalisation of existing things, probably amounting to writing down facts and procedures in simple forms - there are no revolutions in prospect. Yet.

That sounds a bit familiar. The information ALSO contributes to the diagnostic part of the system, where it's essential raw material for the attempts to interpret unexpected phenomena. In that context, we talk about knowledge-based systems, where the special feature is the separation of the knowledge base from the processing ( "expert system shell" ).

So perhaps we can use all the good arguments for expert systems ( should there be any ) in favour of our approach ?

A specific topic.

Down to earth. Anticlimax time.

We worked on the bit that was most immediately effective : an interpreter ( assumed to include compilers ) for the CONTROL PROGRAMME. That would implement most of figure 1, and potentially reduce the EPG.

It was also ( we thought ) reasonably straightforward, and would give us a way to try out ideas which we thought would help in the robustness area.

THEREFORE : the idea was -

We'd design a "source language" for the control programme, which - for the time being - would be written by an engineer, but could in principle be produced by an automatic implementation of the earlier parts of the overall design process.

We'd write a processor for the language which could take into account the various sorts of information we've discussed, assumed to be recorded in databases, and drive the system.

Notice that it has to produce code for a distributed computing system. The programme will describe the manufacturing process for one product, but that will be implemented by a wide variety of computers scattered around the plant.

The "one product"-ness is important in several ways.

• In the manufacturing, it's important because it describes the complete process, and it's the entity we'd want to use for programme proofs, or other validation tests. In the original system, no such statement of the process existed; the engineers knew what had to happen, but by the time it got to the computers it had been fragmented into bits for each separate computer. Notice, though, that to make it work properly we really want to include the PLC code.

• In the "expert system", it's important for the same reason. If there's a fault in the product, then a view of the complete process is required to formulate hypotheses on where the fault could have originated; again, a set of disparate programmes isn't very helpful.

• AND it emphasises that there's one more job to be done : coordinating the products which are moving along the production line at the same time. This is a problem we haven't tackled in practice, though we have a preferred solution : we want to build a virtual production line ( in fact, just an independent process ) for each product to abstract the product-related details, then to provide a higher level production line control which will produce and destroy the virtual production lines, and coordinate their progress. But that's an advanced topic.

Designing the language.

What are the constraints on the language ?

Comfortable for engineers

so that they can write it or check it.

Machine-writable

so that it can plausibly be composed by ( non-existent ) "higher level" software; keep it low level; "Assembly" ( literally ! ) language.

Machine-comprehensible

so that it can be used as a database describing the manufacturing process; needs what machines do, and how they do it. ( PLCs again. )

But the first is the most important. We're reasonably confident that if we can manage that the others will follow.

Therefore :

How do engineers like to write their programmes ? - We asked for samples - and didn't get many. ( EPG again ? - certainly some caution about disclosing F&P secrets. )

Whatever it is it's essentially engineering, which we want to be able to build into our programmes if we need it. Why not ask the engineers ?

A practical language.

After a certain amount of obscure difficulty ( EPG ? ) in the bowels of F&P, we found out what the engineers wanted to do. We even got a specimen of a real system design outline produced by an engineer.

It was simple, straightforward, clear, comprehensible, and obviously right.

That seemed like a good idea. Why couldn't we use something like that ? We could write a sort of compiler which would translate the engineer's specification into something executable in the real production line. Let's do it.

But one example looked more or less like this :

Machine :	Detector.
Stimulus :	A bottle arrives.
Action :	Send "Found a bottle" to the Controller.
Machine :	Robot.
Stimulus :	Receive "Move bottle from Detector to Filler" from the Controller.
Action :	Move the bottle to the Filler,
	Send "Operation complete" to the Controller.
Machine :	Filler.
Stimulus :	Receive "Fill the bottle" from the Controller.
Action :	Fill the bottle,
	Send "Finished" to the Controller.
Machine :	Robot.
Stimulus :	Receive "Move bottle from Filler to Packer" from the Controller.
Action :	Move the bottle to the Packer,
	Send "Operation complete" to the Controller.
Machine :	Packer.
Stimulus :	Receive coordinates from the Controller.
Action :	Receive "Pack" from the Controller,
	Pack the bottle at the coordinates.

( It isn't the original; I've transcribed it as it might be applied to a different problem, but the original format is preserved. ) This is what I described as " simple, straightforward, clear, comprehensible, and obviously right".

NOTE that it contains more than the fabrication programme. It contains stuff about the line design and product design as well, but much of it is predigested by people.

Features :

Programme feature -	Expressed as -	Related to -
The whole process.	The manufacture of one product is followed as it passes along the production line.	The process database.
Machines.	The machine which performs each step is identified.	"... the right machine"
Event-driven.	The event which triggers each step is identified. ( NOTE : includes periodic. )	"... at the right time"
Pseudocode.	The steps are described in English - but they're fairly detailed.	"... the right operation"
What happens.	The action performed is described in terms of the machine's abilities.	"... the right instruction"
Formalism.	Each step is laid out in a standard pattern.	Like a frame ?

- and the programme is specific to a product type. That leaves product and workpiece - both implied by the context in which the programme is to be run.

So it's all there.

And if we can make it a bit more formal, we'll have something we can use as a process description for diagnosis.

Refinement.

First step : insert the controller activities :

Machine :	Detector.
Stimulus :	A bottle arrives.
Action :	Send "Found a bottle" to the Controller.
Machine :	Controller.
Stimulus :	Receive "Found a bottle" from the detector.
Action :	Send "Move bottle from Detector to Filler" to Robot.
Machine :	Robot.
Stimulus :	Receive "Move bottle from Detector to Filler" from the Controller.
Action :	Move the bottle to the Filler,
	Send "Operation complete" to the Controller.
Machine :	Controller.
Stimulus :	Receive "Operation complete" from the Robot.
Action :	Send "Fill the bottle" to the Filler.
Machine :	Filler.
Stimulus :	Receive "Fill the bottle" from the Controller.
Action :	Fill the bottle,
	Send "Finished" to the Controller.
Machine :	Controller.
Stimulus :	Receive "Finished" from the Filler.
Action :	Send "Move bottle from Filler to Packer" to Robot.
Machine :	Robot.
Stimulus :	Receive "Move bottle from Filler to Packer" from the Controller.
Action :	Move the bottle to the Packer,
	Send "Operation complete" to the Controller.
Machine :	Controller.
Stimulus :	Receive "Operation complete" from the Robot.
Action :	Send coordinates to the Packer
	Send "Pack" to the Packer,
	Calculate next coordinates,
	Restart.
Machine :	Packer.
Stimulus :	Receive coordinates from the Controller.
Action :	Receive "Pack" from the Controller,
	Pack the bottle at the coordinates.

What more do we need ? Not an exhaustive list, but it'll do :

• The programming language - what it needs for its machine :

  Standard vocabulary.

  "English", associated with the machine.

  Means of associating actions with the vocabulary.

  The machine database.

  How to make a machine do things.

  "Machine language", and how to get it there.

• Programme structure - what it needs for the process :

  Programme structure - conditions, loops.

  - but keep the basic simplicity.

  Manage faults.

  - particularly external faults.

So a machine database must include :

• What the machine can do, as English descriptions. ( Not necessary at this level, but documentation. )
• The corresponding instruction which must be got to the machine, described in "English".
• The corresponding instruction which must be got to the machine, described in networkese.

( The last two define the programming language to be used when programming for the machine, and the translation to be used by the parser which handles it. THESE CAN'T BE PREDEFINED. So the language can't have a defined vocabulary. Better called a framework ? )

- and a network database must include :

How the components are connected together.

- and the controller's database must include :

How to send a message into the network.

What sort of programme structure ?

The programme structure must be designed to permit the operations listed.

How ? - obviously, by "Algol" - but that won't do - notoriously hard to untangle. ( Compare programme proofs. ) And hard for machines to write.

But DOES explicitly include structure - has to be inferred from simpler styles. Why do we need structure ?

• For human comprehensibility - but it will never get complicated in a mathematical way.
• For backtracking after a fault - but we can keep a history.

It's procedural - untrendy. But appropriate for procedures. ( NOTE that trend to declarative and functional styles is sensible for mathematics - it's not a procedural subject, and the use of algorithms was artificial from the start. )

A state-based model.

( This is so important that it deserves a step to itself - because - )

Programme structure - conditions, loops.

Identify every instruction as a state with two components, { Normal, Fault }.
Normal is associated with the instruction; it tells where in the process the system has reached. Its value while executing instruction N is Instruction-N.
Fault says something about the overall state. It is usually NoFault.
Unless otherwise instructed, at the end of any instruction the normal state is changed to Instruction-(N+1).

It is then up to a general dispatcher to find a state { Instruction-(N+1), NoFault }; and that is normally the next instruction.

An unconditional branch is achieved by providing an instruction to change the normal state.

          SetNormalState to GoRound.

The appropriate change will cause the dispatcher to execute any other instruction in the programme.

A conditional branch requires some sort of test; this is associated with a state-setting instruction :

          SetNormalState to <state> if <condition>

Loops are constructed in the good old-fashioned way using what amount to if and goto instructions. That's tedious, but the programme is supposed to be machine-writable. If you want to devise a higher-level language and write a compiler, go ahead.

Manage faults.

To deal with a fault, we need all the information we can get. At this level, that's the type of the fault and the point in the programme at which it occurred - which is the normal state component. So when a fault has been identified, we can set the fault state component to some value denoting the fault type, and let the dispatcher select a corresponding fault handler. ( If we haven't foreseen the fault, that doesn't work - but then, neither does anything else. )

That makes it very easy to insert fault handling code ( one of the F&P desiderata ) without messing up the sense of the main programme.

State is a combinatorial entity. If ten significant variables each have two states, then there are 1024 states of the system. And that's a smallish system.

It hasn't really been tested yet, but we think that it should be possible to express the programme in modules which are sufficiently small to have not very many states each. Once we use a computer, it doesn't matter much anyway, because we can keep lots of state information in the form of variables; only with stupid machines does all the state have to be made explicit.

Programmes for individual machines.

Each machine needs its own programme. Easy - collect same machine bits from the whole programme.

     Trigger
          
          -- Await a signal from the detector;
               Receive “Found a bottle”
                    : from Detector.

     Procedure
          
          -- Tell the robot to move the bottle to the filler's workbench;
               Send move instruction
                    : to Robot;
                    : carry bottle;
                    : from detector station; 
                    : to workbench.

          -- Await the "finished" signal from the robot;
               Receive “operation complete”
                    : from Robot.

          -- Tell the filler to fill the bottle.
               Send fill instruction
                    : to Filler.

          -- Await the "finished" signal from the filler;
               Receive finished
                    : from Filler.

          -- Tell the robot to move the bottle to the packer;
               Send move instruction
                    : to Robot;
                    : carry bottle;
                    : from workbench.
                    : to packer station.

          -- Await the "finished" signal from the robot;
               Receive “operation complete”
                    : from Robot.

          -- Send the coordinates to the packer;
               Send message
                    : to packer
                    : contents box coordinates.

          -- Tell the packer to pack the bottle into the box;
               Send pack instruction
                    : to Packer

          -- Calculate the coordinates for the next bottle.
               Calculate next 
                    : box coordinates.
          

Implementation.

Do what ? - execute the single machine programme as sketched above.

In essence, we want to find out what's involved in executing this :

          -- Tell the robot to move the bottle to the filler's workbench;
               Send move instruction
                    : to Robot;
                    : carry bottle;
                    : from detector station; 
                    : to workbench.

SECOND aim : to make it work in practice;

THIRD aim : to make it work well enough to use in industry.

FIRST :

We were reasonably confident that the database ideas were sound, after the varied experience gained in earlier approaches. But they had usually ended up as compromises implemented by students panicking ( unnecessarily ) because they hadn't managed an implementation.

It's non-trivial. Consider the example :

               Send move instruction

Because of the insistence that no vocabulary should be built in, everything has to be looked up somewhere.

Send, being the keyword, must be found in the controller's database. It must identify a procedure ( perhaps as a pattern ) to be executed; the procedure has to provide for all the other parts of the Send instruction. There must be a definition of the syntax, so that the interpreter can understand the programme, and information sufficient to construct the message to be sent, and to send it.

Move immediately raises difficulties; it isn't a controller instruction. It is a robot instruction, so the Send procedure must be able to find out ( from the to clause ) where to look for the move instruction

                   : to Robot;

This clause tells us where to find not only the vocabulary used in the programme to define the instruction, but also how the instruction must be encoded and where to send the encoded instruction - which will probably require some sort of network database.

                    : carry bottle;
                    : from detector station; 
                    : to workbench.

These clauses fill out the instruction. Carry, from, and to are words identified in the robot vocabulary; we infer that the robot wants to know what it should carry, so bottle is necessary to identify the object, and perhaps the bottle database entry includes information on how to pick up a bottle.

Similarly, from and to are retrieved from the robot's database, and these will require coordinates which can be retrieved from the information about the detector station and workbench in the production line database.

SECOND :

So it looks possible. It also looks complicated - but it's not deep and profound complication ( we think ), it's the simple complication you get from picking the right pieces from large quantities of material, and we should have enough keys to get the right stuff when we want it.

Of course, we DO WANT THE DATABASES. Someone has to write them down, and perhaps that's the bit that hasn't been done in such detail before. But, once written, the rest follows; and - if it works - once written it's very easy to switch to ( say ) a new robot, or product, or line layout, or whatever.

THIRD :

To be investigated.

What Natalie did.

FIRST :

Natalie ( almost ) made it work. She used a VERY simple system, but got as far as implementing an interpreter which seems to work. ( She didn't quite have time to complete a simulated demonstration, but the details of machinery she used were fairly realistic. )

Her programme had components for four machines, including the controller.

          {machine IRB     

               {machinetype
                    robot}     

               {location
                    workcell X
                    {x 0}
                    {y 0}
                    {z 0}}     

               {messagetype
                    opengripper instruction
                    {sequence
                         construct opengripper instruction called opengripper;
                         send opengripper instruction to IRB opengripper;}
                    {format
                         1     number_of_bytes = 9;
                         2     destn_addr = 1;
                         3     source_addr = 0;
                         4     fn_code = 16;
                         5     telegram_info = 1;
                         9     status_of_digital_output = 1;}
                    {size
                         9}}     

               {messagetype
                         ....}
          ....}
          

She used these databases :

Machine type :

Intrinsic properties of a machine :
vocabulary;
syntax.
So you can have several instances of a machine if you want.

Machine :

Instances of machines :
machine type;
machine position.
Describes the factory layout.

Controller configuration :

About the machine controllers :
defines various message queues.
Information for implementation.

and a nice simple interpreter. Here's the controller programme :

          Trigger
               receive "found an object" from Detector.

          
          Procedure
               send move instruction to robot "move bottle from conveyor to packer";
               receive "operation complete" from robot;
               send pack bottle message to packer "pack bottle";
               receive "operation complete" from packer;

It's smaller, it's simpler, but it's just about working.

SECOND :

Close. She had hoped to use a real workcell for implementation. That didn't work out, but the exercise concentrated the mind on real systems.

THIRD :

Later.

Encouraging.

What Natalie did next.

FUTURE PLANS :

FIRST :

More. Fill out the skeleton to cover a more realistic system.

SECOND :

Do it. Produce a working controller for something like a simple workcell. Show that it is easy to adapt to changes in environment, etc.

THIRD :

Maybe not, but try. Survey a wider range of systems. A particular target is a production line with several items travelling along it in different stages of completeion. ( We want to use a "virtual controller". )

AND IF THERE'S TIME AND INCLINATION -

- look again at the diagnostic side of things.