Top Down vs. Bottom up

I agree with a lot of the material covered in this chapter, but – and this is a big but – I think it comes at task analysis from a very particular perspective, and ignores other effective ways of getting at information that is vital to design. For instance, in the text, it is often difficult to determine when a particular item is being handled by a particular user. If there were two tea makers, the coordination would be difficult to describe with the task hierarchy as described. The situation where one item is accessed by two users is particularly difficult to handle.

For about six years, I worked on robotic control system development with Dr. Barbera fron NIST. He, along with Dr. Albus, had developed the 4D/RCS control system methodology, which was based on scenario creation with subject matter experts and task-based, hierarchical decomposition of systems.

Essentially, we built control systems based on a structure that looks almost exactly like the hierarchies shown in figures 15.2 – 15.6 in the text, with a critical difference – Each box is a Actor (or controller) rather than an Action. Actors pass commands to other actors below them in the hierarchy, and get a status/response back. Each actor performs a behavior based on the command passed down, global (non-state) information, and a finite state machine internal to each actor.

A simple way to imagine this is to think of a military chain of command. A general gets a command. That command is processed at the general’s level of abstraction, and the general in turn issues commands to the colonels below her, who in turn issue commands to captains who issue commands to sergeants who issue commands to privates who in turn interact with the environment.  A simplified (sans any actual tea) hierarchy for making tea is shown below:

RCS_Hierarchy

First, you can see the robotics background kicking in. I want sensors to tell me when things are full. Still, this gets the point across.

The most important thing to note about doing this approach is the hierarchy is built from the bottom up. So I started with the items used to make the tea, figured out what they did, and what kinds of commands that they would get to perform these tasks. How they perform those tasks doesn’t interest me right now, but later, a state table will be associated with each actor to describe how the task is accomplished.

Note further that the kettle and cups are placed under a manipulator. This manipulator coordinates the action of the kettle and the cups. The higher level coordination of the kettle and the sink, and the kettle and the stove is handled at a higher level.

In my experience, this type of task decomposition/integration has proved very effective in both describing a task in a clear and consistent way, while also being able to be understood by subject matter experts with a minimum of training.

The thing is, the approach that we used was in many ways profoundly different from what is described in the text. What makes me stop and really ponder this is that the goals of our control-system development and the task analysis described in the book are essentially identical, the way that the tasks are analyzed is not. While the book approaches the problem from a top-down perspective on task analysis, we developed our structures using a bottom up approach. The reason for this was known as “the multiple parent problem” which I touched on in the first paragraph. When you build a hierarchy downward, it is difficult to know where it should branch, or even where it should stop. You often get the case where two items want to control the same thing.

With a bottom-up approach, this problem never occurs. Child nodes naturally integrate under parent nodes. Levels of abstraction are split using simple rules. Generally if a actor node is getting more than 7 commands, it’s probably worth breaking up that node into two or more. This is in fact what happened to me when I was building this hierarchy, which is why there is a “Manipulator” node between Teamaker, Kettle and cups. In fact you can see that the kettle was originally going to be “mobile”.

If anyone would like a more detailed explanation of how to implement an RCS hierarchy  I’d be happy to provide more detail.

Advertisements
This entry was posted in Assignments. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s