In the mid 1990s I was working at Realtime Software on a project to automate an aluminium smelter. One of the problems was that there were many disparate elements of the system that needed to communicate with each other:
Control of the smelting reduction cells (called pots) that produce the metal is done by raising and lowering the anode into a smelting pot which is a cathode.
There are temperature sensors to measure the temperature in the pot.
There are ammeters to measure the current through the pot.
Operator screens show the current state of each pot line (there are 186 pots per line and 3 lines in just one of the smelters).
A database records each activity - movement of an anode, topping up and emptying of a pot etc.
Ian Jamieson, MD of Realtime, produced an idea that would make this easy to control. It was a publish and subscribe system that we called Message Director. Applications controlling each aspect of the system communicated through messages that were handled by a central 'director' application. An application that controlled movement of the anode, for instance, received messages that directed it to move. These messages could come from an application that controlled anode movement by monitoring current and temperature through the pot but could also come from an operator console where an operator could override the system movement. A database application also received these messages and logged the movements to a database.
The project was finished (under time and under budget with only 3 people!). Unfortunately, after the project was finished Ian died in a car accident whist driving to the smelter.
I realised that this concept was world beating. There was one deficiency, however. In Message Director, the receiver of a message had to know the data format of a message it received. For instance a message that directed the movement of an anode had a particular message format, in this case a structure with a pot number, a movement amount (+ or -) and some other data. Similarly, each message had a format that that any receiver of the message needed to know. This diminished the universal concept of publish and subscribe in that a publisher shouldn't care who receives the messages and the receiver shouldn't care who published it.
I moved to Queensland to work on a smelter there and around 2000 got funding from the Queensland Government to develop Universal Message Manager. (As it happens, this was in the same office where WiFi was developed.) We had students from the University of Queensland working on the project, and also developed a layer to work over Bluetooth in its early days. However, I couldn't get a suitable company interested enough to fund the project to the point where it was marketable. I needed a team of programmers who could understand the concept deeply enough to build it properly — and for years, that team never came together.
This year, that changed. Working with Claude, I finally had the team I needed. Claude suggested Python to build it initially, though the design allows agents written in any language to be plugged in. I directed the design throughout — the architecture, the FSM model, the layered addressing, decisions grounded in twenty-five years of industrial automation experience — and reviewed, tested, and corrected the implementation at every stage. Claude did most of the actual coding and a large part of the documentation under that direction, and grasped the concepts quickly enough to spot potential in the design I hadn't fully seen myself, including its value as a teaching tool. The result is a genuine collaboration: a concept I'd been unable to bring to life for two decades, finally built to a level of completeness that would have taken a small team of human programmers years to reach.
Top comments (0)