Ross Shannon

At this early stage in my PhD, it would be instructive to look ahead and take a wild, naïve guess as to what kind of deliverable simulation I may end up producing at the end. If only to look back and laugh later on.

First of all; the challenge, as I understand it at this time:

To model an autonomic system, specifically one inside an automotive machine, most likely a car. A modern car will have a wide array of sensors and actuators, and the system designer needs to be able to see how they are performing, in real time.

At the moment I’m envisioning a car, modelled in 3D, driving out onto a classic Tufte-ian grid.

A car that I’ll never be able to model.

The best guess at the moment on what kind of 3D I’m going to use would be some modification of the “Source” engine, which powered Half Life 2. The SDK comes with the game and I’ve played around with it. It’s very powerful.

Once the car comes to a stop, the outer paneling flies off, exposing a simplified version of the car’s innards. Thus begins the simulation, with (hopefully live) data being fed into the system and the display showing various activities on the screen.

Statistics like network activity and CPU usage will be on-screen at all times, in the form of pie-graphs and “sparklines” to show trends over time. Atomic events such as sensors being activated and sensors failing will be shown as alerts, possibly through a picture-in-picture system that shows a zoomed-in version of the full model at the point where the incident occurred. Clicking on this PiP box will then focus the main view on this area, through a camera movement. This device was used in the household simulation game, “The Sims”, to announce events like burglaries and housefires.

So, that’s what I’ve got so far. Of course, I’m leaving out all the bits about multiple displays and pulling elements from the main screen down onto a PDA or something crazy. It’s early days yet though, so this could still go in any direction.

While looking into the possibilities of the Source SDK, specifically the FacePoser program, I had an idea that may or may not be useful. The SDK contains an assortment of tools for creating realistic human characters; characters that look, move and emote like real people. This goes as far as a very impressive facial expression modeller.

The characters that are created for games like Half Life 2 are very convincing. So, my idea was to create a human character (dressed in a lab coat and carrying a clipboard), who would stand beside the model of whatever autonomic system I was simulating. As the simulation wears on, the character will speak, and emote, various feedback cues to the user, like flailing his arms around when sensors fail. What more intuitive form of feedback than one which everyone is most used to having to interpret?

The trick, of course, is to not let this become a more technologically advanced version of Clippy. The character, who could be thought of as an avatar for the autonomic system’s general health, would generally stay in the background. Much of the feedback he provides could even be picked up subconciously, as he walks around the car performing ‘checks’; all the while providing subtle auditory hints and contorting his face to show his level of contentment.

Of course, there are some faces that no amount of technology could ever emulate.

A very interesting paper, given how long ago it was written. Though informal, this was inspiring. The examples of possible pervasive systems — the vast majority of which have not yet been implemented — seem to have had a large impact on future ‘thinkers’.

@article{213017,
  author = {Mark Weiser},
  title = {The computer for the 21st century},
  book = {Human-computer interaction: toward the year 2000},
  year = {1995},
  isbn = {1-55860-246-1},
  pages = {933--940},
  publisher = {Morgan Kaufmann Publishers Inc.},
  address = {San Francisco, CA, USA},
}