This approach have worked for years and, honestly it still works. More and more attention is being paid during the production of this documentation to make final user's life easier. On the other hand, the authors cannot be forgotten. Keeping up to date documentation is a tedious task. A small change on the system covered by the manual may drive multiple changes across the document.

In this post, I'm going to introduce what I have called Smart Manuals. Despite of the "smart" buzzword, the concept really aims to bring up real smartness to current manuals. I'm not talking about adding some computational capabilities to piece of SW or HW in order to be entitled to use the word "smart". I'm talking about going one step beyond.

Artificial Intelligence and Expert System

Artificial Intelligence has been a computer science target since the 50s (yes, we are talking about the last century). However, it has never been developed up to the expectations of its advocates. We are still far away of being able to casually chat with a computer, but, to be fair, there have been some successful developments during all these years.

One of the earliest and most successful AI systems were the so-called Expert Systems. An Expert System can be seen as a glorified database or, as AI people like to say, a Knowledge Base. The idea is to substitute human experts in some topic by this system, first transferring the knowledge these experts have into some machine representation, and then adding semantics to this data in order to enable basic reasoning capabilities on that knowledge. This last part is know as Rule Engine or Production Rule Engine, what, together with the knowledge base conforms an Expert System... roughly.

The avid reader probably can figure out, by now, where is this discussion leading.

Smart Manual

So, as you can imagine, I conceive a smart manual as an expert system holding all the knowledge usually dumped into a written manual. This approach will provide a completely different way to access the information contained in the manual of a given device.

• User Interaction. Instead of browsing the manual looking for the information you want, you will ask the manual how to do what you want to do.
• Just Baked. Instead of producing a fix set of chapters covering a set of topics about a given device, a smart manual should be able to produce the information requested by the user even when nobody else have considered it before.
• Update Once. Instead of manually update manuals when a minor change is introduced in a device or when the manual is extended to support a new member of a product family, authors just need to update the knowledge base and the manual will be updated automatically. Actually, it will be regenerated on the fly next time the user consults it (see bullet above).

At first glance the idea looks interesting. Let's see how could this be implemented.

SM Components

At first glance, a Smart Manual should have, at least, the following components:

• Natural language processor or reflective interface. By reflective I mean that the interface is generated based on the content stored in the Knowledge Base.
• Expert System. The component that will store the knowledge and produce the manual as per the user request.
• Authoring Toolchain. This is the real killer for this kind of systems. The ability to easily produce a knowledge base or translate existing documentation into knowledge entities (facts, rules,...) is still an Open problem heavily handicapped by different organizational constraints.

As we can seen, the central element of a Smart Manual is the Expert System. We can see the expert system as a database plus a reasoning engine. These two elements have to share an interface. They need to be able to talk one to each other. An this is the reason why the so called Knowledge Engineers appear.

As we will see in a sec, the languages to feed knowledge and define rules are everything but intuitive. On top of that, these definitions and rules have to be correct from a logical (mathematically speaking) point of view. That means, that there is no contradictions or paradoxes (as per the logic meaning of these terms) in the data.

And this is actually the difficult part to bring Smart Manuals to reality.

Introducing CLIPS

CLIPS stands for C Language Integrated Production System and it is an open source system intended to facilitate the development of software to model human knowledge or expertise...

This is indeed what we want. Our Smart Manual, should actually look like a expert on the device. Somebody we can ask any question and get the right answer without browsing one thousand pages and digging in different chapters to find what we are interested on.

However, it is not straight forward to use it. Let's see how does a CLIPS rule looks like, just to get the feeling of what we are facing:

(defrule walk-holding-object ""
  ?goal <- (goal-is-to (action walk-to) (arguments ?place))
  ?monkey <- (monkey (location ~?place) (on-top-of floor) (holding ?obj&~blank))
  =>
  (printout t "Monkey walks to " ?place " holding the " ?obj "." crlf)
  (modify ?monkey (location ?place))
  (retract ?goal))

The rule above is part of one of the examples distributed with CLIPS: mab.clp. This example is specially interesting, as it is in a sense producing a set of steps to achieve a specific goal... which is one of the things we want our manual to tell us.

In this case, the goal is to feed a monkey. The system will generate, given an initial state, the sequence of actions the monkey have to take in order to eat bananas... It sounds funny said like that, but it is really an interesting example.

If you look at the end of the file, you will find the definition of the initial state. Based on that state, CLIPS generates the sequence of steps to complete the goal. Note that, this goes beyond the traditional manuals in the sense that the system state can really be tailored to the actual user environment.

Just for illustration, this is the definition of the initial state, which is a lot easier to read, that the rule we checked before.

(defrule startup ""
  =>
  (assert (monkey (location t5-7) (on-top-of green-couch) (holding blank)))
  (assert (thing (name green-couch) (location t5-7) (weight heavy)))
  (assert (thing (name red-couch) (location t2-2) (weight heavy)))
  (assert (thing (name big-pillow) (location t2-2) (on-top-of red-couch)))
  (assert (thing (name red-chest) (location t2-2) (on-top-of big-pillow)))
  (assert (chest (name red-chest) (contents ladder) (unlocked-by red-key)))
  (assert (thing (name blue-chest) (location t7-7) (on-top-of ceiling)))
  (assert (chest (name blue-chest) (contents bananas) (unlocked-by blue-key)))
  (assert (thing (name blue-couch) (location t8-8) (weight heavy)))
  (assert (thing (name green-chest) (location t8-8) (on-top-of ceiling)))
  (assert (chest (name green-chest) (contents blue-key) (unlocked-by red-key)))
  (assert (thing (name red-key) (location t1-3)))
  (assert (goal-is-to (action eat) (arguments bananas))))

Here, we can see how, based on an initial set of items and locations (that we can change) the system produces a manual chapter on how to proceed for a certain user question (the goal at the end of the startup rule).

Looking Further

So, let's assume we have a device, and we have managed to produce a set of rules to generate a manual. The user can now ask "How do I switch this thing on?", instead of looking for a specific chapter, or reading across the "Getting Starter" triptic in the device box.

That will be great. But now that we already have all that knowledge in our system, we can easily (well, probably not that easily) upgrade the system so it will also support troubleshooting of our device. In this case, the system will work backwards asking the user for the unknown state until the problem is identified.

But we can go even further. We can also upgrade our device and make it a "smart" device. Yes, I know, everything nowadays is already smart... but they need to be a bit smarter. So, our smart device can then talk to our smart manual, and provide by itself some of the state in the database. The manual will, immediately be updated reflecting the current device state, and producing tailored instructions for that state.

For instance, suppose we want to connect a new computer to our office switch. The switch will already know which connections are already used and provide specific instructions to the user: "Connect your RJ45 cable to port 3"

But we can even go further (yes, we are quite far away now :). If these knowledge bases become standardized, then we may expect to be able to solve inter-device issues. For instance, you may have a smart manual to configure your wifi router, and you may have a smart manual to configure your SmartTV. It is reasonable to think that unifying these knowledge bases both manuals will be kind of compatible and we can get specific instructions on how to connect our specific SmartTV together with our specific Wifi Router.

Next Steps

I have found this concept quite interesting and I'm aiming to look further in this as far as time permits. I have already integrated CLIPS in a minimal C application that allows me to run CLIPS files from my own program (a post is coming soon). So, next steps will be:

• Define a use case to build a working demo. It has to have a moderate complexity so the advantages of the approach become obvious
• Produce a standalone CLIPS file for that use case
• Extend CLIPS with a function to interface to CHICAS, instead of printing messages to the console.
• Integrate the CLIPS file in a simple application to test the concept of smart devices updating its own state.

The idea, indeed, is to get CLIPS integrated in MIA to provide her with some basic "thinking" capabilities. The Smart Manual concept will be the first step to let MIA become useful!... I hope

■