PDL is an experimental programming framework for process control in manufacturing systems. It grew from an Auckland company's requirement 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 was an information-based interpreter with little fixed vocabulary and all system information kept in easily accessible databases.
Mark's brief was, more or less, to survey the company's manufacturing system organisation, and to make recommendations on how it could be improved. The original structure was a reasonably straightforward Flexible Manufacturing System. It was controlled locally by Programmable Logic Controllers, coordinated in local groups ( now they'd be workcells ) by C programmes running in Unix systems, with another C-Unix system as message-switcher-cum-supervisory-controller.The system worked well, but things change quickly these days. New customer demands, new models, new product technology, new machine tools, new networks, new computers, etc. all posed certain problems for the future of the system.
The main problem was that, in the face of all this novelty, it was proving difficult to keep up to date with system development. We thought that a major cause of this difficulty was ( oversimplifying in the cause of brevity ) the lack of clear connections between causes and effects in the software. While the implications of all the decisions which had been taken when design the product, the process, and the plant were properly incorporated in the C code ( they must have been, or it wouldn't have worked ), they were incorporated by digestion, so that the links between the decisions and the code were to a great extent destroyed. That's nobody's fault - it's common in programming, and doesn't really matter a lot if the programme isn't going to change.
But these programmes were going to change, and it would help a lot if it was easier to see how design decisions at various levels affected the details of the software. Our tentative solution was therefore to seek means of making these dependencies clearer, so we took information accessibility as our theme. Our intention was to make clear the connections between decisions and code, so that the consequences of changing the decisions could more easily be deterimined and incorporated in the running system.
( More history ? )
After rather a lot more steps, we finish up with a programming "language" which has hardly any predefined vocabulary ( because we don't know what vocabulary will be needed for machines not yet invented - that's why I like to call it a "framework" ), and gets all its information about source and object languages from a set of databases about all the system components.
Even better - it seems to work. A model system built by Natalie Spooner in 1995 gave us a lot of confidence that it would, and Natalie continued the development convincingly in her work for her M.Sc..
More recently, I've been applying the PDL approach to the problem of construction our department's handbooks. This turns out to be a significant, if rather abstract, assembly task, and I've been able to test the ideas presented in my report on something very like the design of a complete factory. It worked very well indeed. While the language itself was involved only peripherally with that exercise, it was possible to test all the bits of the whole surrounding system, and they worked. Peter Shum produced an implementation as a project.
I hope ( springs eternal, etc. ) that the language will come back again in another part of the handbook job. I did that until around 2002 May; I was the department's "Information Coordinator", a job I invented at the beginning of 1997 and promptly volunteered to do. This was partly sheer altruism, but tempered by an aversion to any of the other administrative responsibilities which were available. ( Earlier stints as dogsbody, stage 4 coordinator, examinations coordinator, and diploma coordinator had left me not only uncoordinated but also properly suspicious of such tasks. Unfortunately, someone has to do them, and as we've no one else it has to be an academic. We're cheap and expendable, even though not always conspicuously efficient. But I digress .... ) Information coordination, as I invented it, was comparatively interesting, as it gave me an opportunity to try out some real-time systems ideas. I carried on until "progress" changed the nature of the job by introducing a lot of quite unnecessary bureaucracy from outside the department. As I haven't quite got round to the real-time systems bits yet, I am secretly carrying on in a comfortable and civilised world of the past ....
Several students have put in some work on PDL :
TECHNICAL REPORT :
WORKING NOTES :
Alan Creak,
June, 1998.
Go to me;
Go to Computer Science.