Kris Tuttle
(the CMU experience...)
Shortly after arriving and insisting on taking a number of final exams for some of the computer science courses I was lucky to have John McDermott grant me a job interview. It went something like this:
JM: Are you familiar with production systems? KT: No.
JM: Do you know how to program in LISP? KT: No.
JM: Do you know how to program in BLISS or C? KT: No.
JM: Well you will start immediately. Your first task will be to take some of the implementation for our production system, OPS5, which is written in LISP and re-implement it in BLISS. Go to the documentation room and they will give you a badge, an office key and everything you need to figure this out. You should probably also meet with Charles Forgy since he wrote the entire system and can give you some direction. Come back when you have results.
After tackling this job we moved on to more interesting projects. One of the most exciting was a system built for the U.S. Navy aircraft carrier the USS Carl Vinson. The system helped commanders decide what to do with the many planes in the air during an operation. This is a very dynamic problem space and we enjoyed building the system.
However when we demonstrated the prototype to the Navy representatives they had one major issue with it. They said the system needed a "sense of urgency." Although our system would figure out the best thing to do for each plane it could sometimes take 30 seconds to do so, this would not do in a real situation.
So we went back to our drawing boards. We were already using the state-of-the-art hardware so there wasn't much we could do to speed things up. There had to be a fundamental change in how we performed the task.
We decided to create a fixed decision window of so many seconds. This short loop enabled the system to be responsive enough for the real world. Then we computed the resources to execute every rule in the system (this was implemented as a classic forward-chaining production system using OPS.) Once we had done this for the entire rule set we assigned a "depth of processing" level to each rule. At the beginning of each decision window we would compare the amount of time to handle each depth and then select and execute the one that matched.
The result was that when the data was changing fast and many decisions needed to be made the system would process knowledge at the most basic level. When time was available the system would automatically fire more rules and perform a deeper analysis to provide more optimized information and decision making.
In the end the behavior of the system was well matched to the style of the command environment at the time and we had another great application for emerging knowledge-based systems.