Ross’ PhD Blog Memex

• Currently Listening to: Phoenix — Too Young

I attended the workshop on Software Engineering Challenges for Ubiquitous Computing (SEUC 2006) in Lancaster, presided over by Gerd Kortuem.

After a somewhat hurried paper submission about using AOP in automotive software, I decided to change tack, so my presentation was about what kind of problems software engineers in the automotive space are facing. Admittedly I wasn’t presenting any answers, but my presentation went well and, being the only presenter discussing automotive systems and autonomics explicitly, I got a number of interesting questions which created a good discussion.

Software Considerations for Automotive Pervasive Systems Talk given at SEUC2006, June 1–2, Lancaster UK.

Here’s an excerpt from my talk:

The modern car is a highly sensorial, complex pervasive system, with thousands of sensors and actuators and hundreds of microcontrollers controlling almost all aspects of the car’s operation; from the multimedia & entertainment systems (radio, DVD players) and navigation/mapping software, to communication both to the outside world and also on a more limited scale to other cars nearby on the road.

Finally, and most importantly, are the car’s safety systems. Most of the impetus for adding so much software to cars is the supposed benefits to driver safety. And when it works, this is great, but we must also recognise that the stakes are higher. There are dangers involved that most pervasive systems don’t have to be concerned with.

System Personalisation

Much of the talk and discussion involved the implications of personalisation in automotive systems. In the future and to an extent even now, you can choose which features you want your car to come shipped with. This is likely to increase in scale over time, so that a car’s base configuration can be permuted in thousands of ways for each buyer. Modules need to be unobtrusively integrated and interoperable.

Layered on top of this is the possibility of a car being modified, upgraded or damaged over time. Cars will have to be able to adapt to whatever components they have installed, and thus, there is a lot of autonomic computing involved.

Questions & Answers

A few brief (paraphrased) questions and answers that I remembered to write down (not guaranteed to be correct!):

Will hardware and software become increasingly decoupled in automotive systems?

This doesn’t seem to be the way it’s going. As far as I can see (and this was backed up at the workshop), the hardware and software systems seem to be getting more tightly coupled if anything.

What is the development process at the car OEMs?

I couldn’t answer this, but someone else stepped in and suggested that a lot of OEM’s in-house teams are actually graviating towards being software-only development houses, with hardware being contracted out to other companies.

Does the drive-by-wire filtering of a user’s input spoil the love of driving?

Not really a research question, but interesting nonetheless. I do wonder how many drivers could honestly say they’d prefer the primal thrill of risky, unrestricted driving over the increased safety and stability benefits of these modern cars.

• Currently Listening to: Ampop - My Delusions

After my initial foray into predicting the future was met with puzzlement, I’ve been thinking back over the idea of, as Aaron put it, “marrying the Scientific Visualisation with the Information Visualisation”. This seemed like the logical way to go, but right now it doesn’t look like what’s actually required or even desired for this project. Nonetheless, I want to write down the reasons I originally started thinking along this track.

Spatial Representation

First of all, because an autonomic system is made up of a large and fluctuating number of sensors and actuators, it made sense to have some form of spatial representation of where the sensors are located. This allows such actions as the person watching the visualisation saying “show me activity for the sensors at the rear of the car”, or for those clustered in the engine, for example. This would surely be a useful UI for interacting with the simulation.

Sensor Grouping

Beyond these ‘logical groupings’, they could also simply drag a box around the sensors they were interested in, and use the usual Shift-click/Ctrl-click interaction to add or remove sensors from their selection, and then generate the visualisation from this selection. Splitting the sensors driving the visualisation into groups like this would simplify the task of focusing on certain parts of the simulation, or moving parts of it onto other display devices (particularly low-power devices, with not enough processing power to generate the entire visualisation).

Using a 3D Camera

When sensors fail, as they are wont to do, the camera in the 3D environment can be positioned to show the location of the failure. This would allow the user to select nearby sensors and get realtime data from just those sensors surrounding the problematic one.

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.