This document is a summary of the “Visualising an Embedded Software Architecture” thesis written
by Mark van Kessel. This thesis was a result of a graduation project at Océ Research & Development
performed between September 2003 and March 2004. Because the subject of this graduation project
had a confidential character, the resulting thesis also became confidential.
Océ is a mayor player in the worldwide copier market and constantly tries to improve its market
position by innovating and developing new products. Developing a copier is a complex and timeconsuming process. The deployment of a new copier on the market takes years and hundreds of
people. People of all kinds of different disciplines participate and must work close together. One
aspect of developing a new copier deals with the embedded software. The embedded software controls
hardware like motors, heaters and sensors. Because Océ develops a wide range of products, much
efficiency is gained by reusing software. Therefore Océ has developed an Embedded Software
Reference Architecture (ESRA) which specifies the architecture of the embedded control software of
the Engine. When a new product is going to be developed it can make use of ESRA and make a jumpstart in the development of the embedded software. To ensure success, ESRA must be accessible and
understandable to all parties involved.
ESRA consists of documentation describing various architectural subjects, written for an audience of
software architects. These documents describe the architecture in a clear and high-level manner, but
documents are not always the right medium to reach a wide audience. For ESRA to be most effective
it needs to be as accessible and understandable as possible. In particular the ESRA subject of
Functions needs further explaining. Functions are stand-alone parts of a copier that perform one clear
and distinguishable functionality. Examples of these Functions are the Paper Input Module for
providing new sheets to the rest of the Engine, the Finisher to deliver ready sheets to the user and the
Process to actually print a sheet. Functions are also used as a project organisational structure. A
project is divided into Function teams where groups of multidisciplinary experts develop a Function.
These Function team members are the primary targets that ESRA would like to add to the audience.
They do not necessarily have a background in software architecture and are helped by a better
understanding of the embedded software architecture.
This project deals with the realisation of a visual model that shows what the embedded software does.
The approach of this project was to make a model of one particular Function, the Paper Input Module
(PIM) Function. The PIM is that part of a copier that provides sheets to the printing part of the copier.
A PIM typically consists of several paper trays, so different sorts of paper can be printed. The reason
to choose for the PIM is because it is relatively simple, but all architectural aspects are present.
Because too much detail would make such a model too complex (meaning less understandable) it was
chosen to base this project on a simplified version of a PIM with only one paper tray.
To make a jump-start with the development of this model, it was chosen to make use of the Generic
Function component of the Reuse Group. The Generic Function is a reusable software component
based on ESRA, developed to speed up Function software development. This component is developed
with Rational Rose RealTime in C++. Therefore it was chosen to develop the ESRA Explanatory
Model also in Rational Rose RealTime and C++. Rational Rose RealTime has many (debug) features
that can be used to explain the model. But because Rational Rose RealTime was not developed for
explanatory purposes, but for developing embedded (real-time) systems, some extra functionality has
to be implemented to further explain the model. Because the Rational Rose RealTime model and the
explanatory parts are very different, it was chosen to divide the ESRA Explanatory Model into two
layers, the Executable Model Layer and the Presentation Layer. The Executable Model Layer will
be a Rose RealTime model, implementing a PIM. The Presentation Layer will consist of all
functionality that can be used to show and explain the Executable Model Layer.
Most time of this graduation project was used to realise the Executable Model Layer. At the end, all
core functionality was implemented, so realistic behaviour of the Paper Input Module could be shown.
We showed this model to a possible audience to get feedback on how usable and understandably it
was. Based on these talks and demonstrations we started with the Presentation Layer. Several possible
extensions and improvements were investigated but because of the limited time available, only a few
of these possibilities could be worked out. The most important being a supportive tool to make the
output (log-files) of the Executable Model Layer better understandable.