Oce Bruning Graduation

Document Sample
Oce Bruning Graduation Powered By Docstoc
					         Graduation Report
        Visualization of a printer for a
    Hardware-In-The-Loop test environment

Name:              Ralph Peters, 2043538, TI8
Year of release:   2008
             Graduation Report
         Visualization of a printer for a
     Hardware-In-The-Loop test environment

Author:                      Ralph Peters
Class:                       TI8
Student number:              2043538
Author’s company initials:   QRPE
Report:                      Graduation Report

Period:                      February 11th 2008 – July 9th 2008
Place:                       Venlo
Date:                        June 4th 2008

Company:                     Océ R&D, Venlo
Company mentors:             J. van de Hee, S. Hulsenboom
School mentor:               R. Brans

Education:                   Technical Informatics
College:                     Hogeschool Zuyd, Heerlen
This graduation report is intended for the HBO-program Technical Informatics and
describes twenty weeks of practical work at Océ R&D from February 11 th to July 9th.
This internship was done within the scope of Technical Informatics. In this period I
was occupied with the development of a visualization tool for a new test environment.

Océ is a company which aims at the effective information exchange between people.
To achieve that goal Océ offers products and services for reproducing, presenting,
distributing and maintaining documents. In this report the history and organization of
Océ and Océ R&D, the used development tools and the performed tasks are

It was very interesting and exciting to be part of a large company. I acquired a lot of
new (programming) knowledge and I was able to apply this effectively. Furthermore, I
consider this graduation assignment as a wonderful conclusion to my time on the
Hogeschool Zuyd and as a great gateway to the rest of the ICT-world.

Furthermore, I would like to thank everybody at Océ R&D for this graduation period
which I fulfilled with much joy. In particular I would like to mention and thank the
following people, who were willing to help me overcome any obstacles concerning
the visualization and contributed to a successful learning process:

Sander Hulsenboom, Embedded Software Engineer and company mentor
Johan van de Hee, System Integrator and company mentor
Ton Janssen, Chief Designer
Richard Rietema, Graduate Intern
Werner de Kort, Integrator
Eugen Schindler, Postgraduate Intern
Reinier Dankers, Software Engineer
Joost Janse, Software Engineer
Jac Reinders, Software Engineer

Venlo, June 2008

Ralph Peters


This graduation internship takes place at Océ R&D in the eighth semester of the
HBO-program Technical Informatics from February 11th to July 9th. During this period
of approximately one hundred working days the student applies his or her theoretical
and practical knowledge to a non-trivial problem within a company.
The subject of this assignment is designing and developing a visualization tool for a
new test environment, with which the software testers can follow the sheet behaviour
in a simulated print engine and can manually influence the objects in the also
simulated paper path.

One of the primary activities of Océ R&D includes developing products that are
involved in document management like printers and copiers. These machines usually
have an internal path through which the paper sheets flow. The sheets are
transported by pinches: a type of actuator driven by motors. Sensors are also placed
on the paper path to give a signal when a sheet passes a specific point.

The creation of software for the embedded control of printers is part of the product
development process. This software needs to be tested. Several test environments
are being used for this purpose. Every environment has its own advantages and
disadvantages. The ideal situation would be if there was a test setup which combined
all of the advantages and kept the disadvantages to a minimum. Such an
environment is currently being developed by several departments of Océ R&D. Its
need is high, so a lot of effort is being put into this solution. To be able to test
software on this new environment, a visualization component is needed. The
sensors, actuators and paper path which you would normally find in a printer, will be
completely simulated. The role of the visualization will be to display these objects.
The simulation data will be computed by a simulator and sent to the visualization. It
will also be able to catch changes in the objects through user interaction, which will
be sent to the same simulator. This will enable the user to enter test cases and see
the results of it.

Océ is a corporation which makes printers and document management systems and
delivers relating services. The company currently focuses on three core markets:
printing and copying in office environments, printing and copying on wide format and
high volume printing.

Microsoft Visual Studio 2005 Professional Edition has been chosen as the
development environment to build the visualization. This is a full IDE, which can be
used to develop small and large applications. C++ is used as the programming
language to program the application.
An open-source graphics engine named OGRE 3D has been used to render the
visualization. It is basically an API which provides the engine and several libraries
with functions to create graphical applications.

The first step was collecting information about the assignment and its context to be
able to understand the need for the visualization. This resulted in setting up
functional and non-functional requirements and a project plan.
Next, an inventory of possible development tools was needed to determine the best
toolset to realize the requirements with. The most significant candidates were the
MATLAB-tool Happyflow, Blender and Visual Studio 6.0 in combination with the
graphics library OpenGL. The last development tool was chosen for this project.
Shortly after finishing the investigation, the animation of sheets was designed and
implemented. For this, an existing test environment continuously sends data packets
to the visualization. After a few days, the switch from OpenGL to OGRE 3D was
made for the purpose of improved paper path shaping. Loading segment, sensor and
actuator from an XML-file and showing them as objects in the visualization was the
next implemented feature. To separate the rendering and data receiving tasks, an
additional thread was built into the application. Furthermore, selecting objects with
the mouse and showing tool tips while hovering over them was realized.
Future activities include specifying a new data packet format for the object attributes,
code optimization and documenting the design and writing a user manual.

The following results were delivered during the graduation period:

      The functional and non-functional requirements of the visualization;
      A project plan;
      A document containing the results of the development tools inventory;
      The design and implementation of the visualization according to most of the
       functional requirements;
      This graduation report;
      A graduation presentation;
      Documentation regarding the design and used configurations;
      A user manual.

Table of contents
Graduation Report – Visualization of a printer for a Hardware-In-The-Loop test

Preface                                                         3

Summary                                                         4

List of abbreviations                                           8

List of addresses                                               9

Introduction                                                    10

1. The organization                                             12
   1.1 Océ                                                      12
       1.1.1 History                                            12
       1.1.2 Profile                                            13
       1.1.3 R&D project organization                           14
   1.2 Products and services                                    15
   1.3 Clients and competitors                                  16
   1.4 Working environment                                      17

2. The development tools                                        18
   2.1 Introduction                                             18
   2.2 Microsoft Visual Studio 2005                             19
   2.3 OGRE 3D                                                  21

3. The assignment and approach                                  23
   3.1 Analysis of the problem                                  23
       3.1.1 SIL                                                23
       3.1.2 BBO                                                24
       3.1.3 HIL                                                26
       3.1.4 Visualization                                      27
   3.2 Task description                                         27
   3.3 Planning                                                 27
   3.4 Approach                                                 28

4. Project execution and results                                31
   4.1 Execution                                                31
       4.1.1 Analysing the assignment and its context           31
       4.1.2 Setting up requirements                            31
       4.1.3 Making an inventory of potential development tools 32
       4.1.4 Developing a sheet animation                       39
       4.1.5 Future activities                                  41
   4.2 Adjustments                                              42
   4.3 Results                                                  42

Conclusion                                                     44

Literature                                                     45

Appendix 1 - Class diagram                                     46

Appendix 2 - Requirements                                      47

Appendix 3 - Planning                                          48

Appendix 4 - Sequence Diagram                                  50

List of abbreviations

API       -     Application Programming Interface
BBO       -     Besturings Bank Opstelling
BG        -     Business Group
CAD       -     Computer Aided Design
CEGUI     -     Crazy Eddie‟s GUI System
DDS       -     Digital Document Systems
GL        -     Graphics Library
HIL       -     Hardware In The Loop
I/O       -     Input / Output
IDE       -     Integrated Development Environment
OGRE      -     Object-Oriented Graphics Rendering Engine
PIM       -     Paper Input Module
SBU       -     Strategic Business Unit
SIL       -     Software In The Loop
UI        -     User Interface
WFPS      -     Wide Format Printing Systems
XML       -     eXtensible Markup Language

List of addresses

Student data:
Name:              Ralph Peters
Student number:    2043538
Class:             TI8
Phone number:      06-10932588
Email address:

Company mentors:
Name:              Ing. J. van de Hee
Occupation:        System Integrator
Email address:     johan.vandehee@oce.ccom
Phone number:      077-3594211

Name:              Ing. S. Hulsenboom
Occupation:        Embedded Software Engineer
Email address:
Phone number:      077-3595976

School mentor:
Name:              Ir. R. Brans
Occupation:        Lecturer
Email address:
Phone number:      045-4006817

Name:              Océ R&D
Address:           Hakkesstraat 3
                   5914 HD Venlo
Phone number:      077-3594597
Email address:

Name:              Hogeschool Zuyd
Address:           Nieuw Eyckholt 300
                   6419 DJ Heerlen
Phone number:      045-4006060
Fax number:        045-4006069


The quality of a machine lies not only in reliable hardware components, but also in
the software that controls them. One of the primary activities of Océ R&D includes
developing products that are involved in document management like printers and
copiers. These machines usually have an internal path through which the paper
sheets flow. The sheets are transported by pinches: a type of actuator driven by
motors. Sensors are also placed on the paper path to give a signal when a sheet
passes a specific point.
The creation of software for the embedded control of printers is part of the product
development process. It goes without saying that this software has to be tested
thoroughly to avoid any unpleasant behaviour. The ideal testing platform would be a
device that allows software testing as well as error testing. A fully integrated printer
(or prototype) is not available at all times and if it is, it will not be easy or cheap to
build and can not always be used for error testing. That‟s why several test
environments are being used within the company to test the functionalities as well as
the reaction of the hardware when things go wrong.

Every environment has its own advantages and disadvantages. The ideal situation
would be if there was a test setup which combined all of the advantages and kept the
disadvantages to a minimum. Such an environment is currently being developed by
several departments of Océ R&D and will be explained further on in this graduation
report. The need for this so called Hardware-In-The-Loop (HIL) test environment is
high. Therefore a lot of effort is being put into this project, which can be divided into
several smaller projects. A few of these projects are labelled as graduation
assignments. This report is about one of these assignments.

To be able to test software on HIL, a visualization component is needed. The
sensors, actuators and paper path which you would normally find in a printer, will be
completely simulated. The role of the visualization will be to display these objects.
The simulation data will be computed by a simulator and sent to the visualization. It
will also be able to catch changes in the objects through user interaction, which will
be sent to the same simulator. This will enable the user to enter test cases and see
the results of it. This graduation project involves the design and development of the
visualization component.

This obligatory graduation internship takes place in the eighth semester of the HBO-
program Technical Informatics. During this period of approximately one hundred
working days the student applies his or her theoretical and practical knowledge to a
non-trivial problem within a company. After this period he or she will hold a public
graduation presentation, in which the assignment and the accomplishments are
addressed. After this presentation, the student will be assessed by two lecturers
where he or she will have to defend the chosen actions which have led to the final
results. The final mark is based on this assessment and the graduation report.

The following project approach has been used for this assignment: The first phase
focused on analytic activities, starting with gathering information on the background
and the assignment. The next step was writing a project plan. The analysis continues
with setting up the requirements for the application. Next, a survey was held to
inventory and compare different development tools. The goal of this investigation was
to find a suitable development environment and programming language with which
the visualization could be made efficiently and effectively.
The next stage involved the design, implementation and debugging of the
application. Due to the changing nature of the requirements, the visualization has
been developed incrementally, meaning that the functionalities were designed,
implemented and tested one at a time and that one functionality could not be built
without the previous work as a basis.
The testing phase took place near the end of the internship, in which the visualization
was tested both functionally and technically.
The final tasks involved documenting the design and used configurations and writing
a user manual. This was done once the application fulfilled the primary requirements.

The structure of this graduation report is as follows: In chapter 1 the history,
products, services and working environment of Océ R&D are discussed. Chapter 2
describes all the development tools with which the visualization has been built, such
as the development environment and programming language. Details about the
assignment and the chosen approach are addressed in chapter 3. The execution and
results of the project are elaborated in chapter 4. This will eventually lead to a
conclusion, which contains the results and an evaluation.
It should be mentioned that this report was finished five weeks before the end of the
graduation period, due to supervision deadlines. Therefore only the planning of the
activities of these weeks is elaborated, not the actual execution. Furthermore, the
appendices contain information, which is known at the moment of finishing this
document. At the end of the period, the attachments will be updated for practical use
within Océ R&D.

The sources of information for this assignment were available in two major
categories. The main reasons for these sources to be used were the high reliability
and accessibility.
First are the employees at Océ R&D. They had a wide array of knowledge about the
needs of the company, software development in general and solutions to project
specific obstacles.
The second category is the Internet. Not all pieces of information were equally
reliable, but websites like the Océ homepage, Wikipedia, programming sites and API
references are known to contain facts and methods of high quality. These web pages
served as an excellent source for smaller problems, which could be solved quickly
without having to bother an employee about it first.

1. The organization

1.1 Océ

1.1.1 History

First base: a pharmacy and butter colouring
The history of today‟s Océ goes back to April 1857 when Lodewijk van der Grinten
opened a pharmacy in his home town of Venlo. The pharmacy grew quickly and
eventually moved to another, larger location.
Lodewijk van der Grinten took up the question of butter colouring, which was in high
demand at that time. It was manufactured in a workplace behind the pharmacy. Many
pharmacists in southern Netherlands purchased his product and then sold it on to
local farms that made butter.
The industry then developed rapidly. About 1890 Lodewijk‟s son Frans joined the
business. Frans equipped the L. van der Grinten butter factory with an industrial
production line. New equipment, machines and personnel were added. Frans
regarded a basic knowledge of possible raw materials as being of great importance
as well. Under his guidance various export markets were broached.

Work on copier systems and blueprint materials
Following a loss-making year in 1918, the enterprise took on copier activities as well
as Frans‟ son Louis. Frans van der Grinten decided to use his knowledge of
pigments to research into blueprint materials. The first steps in this market were the
production of blueprint paper, popularly used in the 1920s to replicate line drawings.
These were not the black and white copies common today: they produced blue paper
with a white line drawing which explains the name “blueprint”. Some knowledge of
chemistry is of course needed to make blueprint paper, but this is fairly common
property - definitely not top secret. Louis van der Grinten succeeded in producing
paper of such a quality that it drew the attention of the American company Charles
Bruning. In 1926 the business consisted of father Frans, the three brothers (Louis,
Piet and Karel) and ten employees.
It was a German company, Kalle & Co., which was the first to obtain a patent in the
field of diazos. Diazo is a simple and cheap process which results in positive copies:
white with a colour line. Louis van der Grinten sought to make contact with Kalle to
arrange a cooperation. When Kalle refused, Louis developed his own diazo process
and applied for a patent on his Primulin paper.

Océ: Ohne Componente
Louis‟ and Karel‟s efforts at perfecting the system were successful. When they
launched their „semi-dry diazo process‟, Kalle withdrew its legal action and finally
acknowledged that the Van der Grinten brothers‟ invention was unique. The process
was brought onto the market in 1930 under the name Océ, which was simply an
abbreviation for „Ohne Componente‟ - which means „without components‟ in German.
In 1931 Van der Grinten ceased selling Primulin paper and focused almost entirely
on the new Océ.

Building an international network
The brothers showed a clear preference for science over commercial sales. In
answer to enquiries from abroad, they issued sales licences to foreign companies,
rather than establishing their own branches. As a general rule there was just one
licensee per country. This international network of sellers expanded rapidly
throughout the twenties and thirties. The expansion continued through to the fifties.

Copying on plain paper
In the sixties the demand for office copier systems grew rapidly. Now widely known,
Océ-van der Grinten, as the company was called, now focussed its attentions on
copying on plain paper, for which there was a large demand in offices. In 1973 the
first plain paper copier equipment was introduced: the Océ 1700. More successful
versions followed and potential uses were also expanded. In 1983 Océ introduced its
first equipment for copying large format originals on plain paper, the Océ 7500.

Digital technology and colour
The trends during the nineties were: the environment, digital technology and colour.
Océ was the forerunner in all these fields. Its achievements in the environmental field
have been internationally recognised with various prizes. In 1995 Océ introduced its
first digital high-volume printer/copier for office environments and for technical
documentation (broad format). In 2001 Océ presented a colour printer based on its
own totally new seven-colour print technology, the Océ CPS700.

1.1.2 Profile

Océ focuses on three core markets: printing and copying in office environments,
printing and copying on wide format and high volume printing. These are all business
markets; Océ does not target the private sector.

The company structure of Océ is divided into two strategic business units (SBUs).
These are in turn split up into separate business groups (BGs). The two SBUs are
Wide Format Printing Systems (WFPS) and Digital Document Systems (DDS).
WFPS is divided into the BGs Technical Document Systems, Display Graphics
Systems and Imaging. DDS is divided into the BGs Corporate Printing, Commercial
Printing, Software & Professional Services and Océ Business Services.

Océ headquarters is seated in Venlo. The company is active in over 80 countries and
has over 22.000 employees world-wide. Océ Research & Development performs
market research, develops new products and improves existing ones.

1.1.3 R&D project organization

At Océ R&D, activities are organized in projects. Usually the goal of a development
project is to deliver a product. To achieve this, a project gets a multidisciplinary
accent by putting employees from different departments on a project. Thus, one can
find electrical engineers, industrial designers and software engineers working closely
with each other on the same project. A special group called the Reuse Group has
been formed to enable efficient development in the projects. It is made up of people
from different embedded software departments who are also placed in a specific
project and supplies off-the-shelf solutions. The new test environment, for which the
visualization is developed in this graduation assignment, will become one of these
An example of this structure is shown in the figure below.

                                        P          P           P
       Dept.                            R          R           R
       Electrical                       O          O           O
       Engineering                      J          J           J
                                        E          E           E
                                        C          C           C
       Dept.                            T          T           T
       Industrial Design
                                        X          Y           Z



        Figure 1.1 - An example of how the projects within Océ R&D are organized.

1.2 Products and services

Océ has a large variety of products and services nowadays. Its main products
include black and white printers, copiers and plotters for central reproduction, wide
format technical documentation and general office and industrial application. Colour
printers are developed for industrial use, document printing and wide format graphic
arts. Océ also develops scanners, which help with scanning office and wide format
documents and are part of the digitalization process of microfilm images.

          Figure 1.2 - The VarioPrint 6250: the fastest duplex printer in the world.

Documents are often processed at high speed, especially in industrial environments.
To reduce the manual work of ordering, stacking, stapling and making other finishing
touches to groups of sheets, Océ builds finishing devices to do this work quickly and
automatically for plain office paper as well as wide format paper.

                    Figure 1.3 - The Océ 180 Booklet Maker: a finisher
                     which makes producing booklets quick and easy.
Next to this, office supplies can be purchased to support reprographic needs.
Examples are white and coloured papers of all sorts of material and of course ink and
toner for inkjet and laser printers, respectively.

The most of the company‟s revenue however is earned through services. These
include consulting services, where clients are advised on cost- and time-savings and
on solutions which Océ provides to benefit from optimal efficiency opportunities.
In order to maximize results from all hardware and software, Océ also provides
education services to transfer expert knowledge to the client‟s employees. This will
lead to improved cost control, productivity and quality. Moreover, a customer is often
not very adept at implementing an entire document system. This is where
implementation services of Océ can offer support of great value. Lastly, Océ delivers
support to help customers maintain their software for years.

1.3 Clients and competitors

Océ is a company that has branches and therefore different types of customers all
over the world. Some of them include healthcare institutions, logistic and
manufacturing enterprises, governmental and even educational institutes like the
Hogeschool Zuyd.

Océ may be a globally active and successful company, but that does not mean that it
has a monopoly position in the document management business. Competitors that
are to be reckoned with include Hewlett Packard, Canon, Xerox and Ricoh. However,
Océ can maintain its strong market position, because of its high quality technologies,
products and services.

1.4 Working environment

Océ is divided into several divisions, which are housed in their own complex in Venlo.
Océ Headquarters and R&D are two of them and are located close to each other.
These sites have an average form of security including perimeter fences, road
barriers and random briefcase searches by security service workers. Employees
need an access card to be able to enter a complex. Visitors also need such a card,
which has to be requested at the reception by an employee.

Once inside Océ R&D, newcomers will be surprised by the size of the complex,
which consists of about 5 buildings. These structures look old on the outside, but are
very modern decorated on the inside. A cleaning and maintenance crew is present
on a daily basis. An entire department, R-IS, is dedicated to maintaining the uptime
of the network infrastructure and to the delivery of office hardware and software for
the employees. Of course, no infrastructure is safe from crashes, which occur
incidentally. These events are often solved very quickly. Océ R&D also has a large
canteen and restaurant.

The supporting departments of Océ R&D, such as Human Resources and the
Service Desk, are each located as a whole unit in several buildings. However,
employees of the core departments, such as software developers, industrial
designers and electrical engineers, are placed together on specific projects.
Therefore, one can find an employee of a random division in literally any possible
R&D building. Most of them have a workplace in a large office space next to their
colleagues, who work on the same project. This may seem like it can get rather
noisy, but surprisingly this is often not the case.

The professional attitude of the staff is generally sensible, helpful, informal and open.
It is not uncommon for people to visit their colleagues, either announced as well as
unannounced, and leave with some constructive results. It is this attitude and the
variety of disciplines in a project that result in one major advantage: no matter where
you work there is always a large body of knowledge available.
The stance towards interns is just as professional as towards regular employees.
Although students get the less critical assignments they are not treated any less
important. The underlying reason is of course the mutual benefits of the graduating

2. The development tools

2.1 Introduction

Like any software application, the visualization has to be developed using a specific
toolset. To determine the best tools for this purpose, an investigation was done prior
to the development phase. The activities of this survey will be handled later in this
report. The following two development components were the outcome of the

   1. Microsoft Visual Studio 2005 Professional Edition with Service Pack 1 has
      been chosen as the development environment to build the visualization. This
      is a full IDE, which can be used to develop small and large applications but
      has its focus on the latter. Among a wide array of features it contains all sorts
      of wizards, visual design environments for designing forms and facilities for
      writing flawless code. Furthermore, Visual Studio can be used with all the
      programming languages that are supported by the .NET Framework. One of
      these languages is C++, in which the visualization has been programmed.

   2. An open-source graphics engine named OGRE 3D has been used to render
      the visualization. It is basically an API which provides the engine and several
      libraries with functions to create graphical applications. It also allows the
      programmer to include other libraries, e.g. for GUIs and audio. OGRE can be
      fully integrated into different IDEs, including Microsoft Visual Studio.

The programmer-friendly aspect of Visual Studio combined with the modular attribute
of OGRE makes the development of the visualization highly effective.

The machine, on which the graduation assignment was carried out, consisted of the

Operating System: Microsoft Windows XP Professional
Processor: Intel Pentium 4 CPU 3.00 GHz
Memory: 2 GB RAM
Graphics card: Intel 82865G Graphics Controller, 64 MB Memory
Display: TFT-monitor, 1600x1200 (32 bit)

2.2 Microsoft Visual Studio 2005

Visual Studio 2005 is a development environment by Microsoft, which offers a
complete toolset to develop console and GUI applications in various programming
languages, like Visual Basic, C++ and C#. It is mainly used for Windows-based
development. Known examples of software products include desktop programs,
websites and mobile applications. Visual Studio is very suitable for building Windows
applications, because it provides several standard libraries and MFC class libraries
with programming code. Therefore, it is easy to give Windows characteristics to
software products, such as windows and menus.

Visual Studio 2005 consists of compilers for the different programming languages, an
editor for entering software code, a debugger, a visual designer for (dialog) windows
and a profiler. It also has a complete version of the MSDN Library and a local web
server that can be used to host ASP.NET applications during development and
testing. It makes full use of the .NET-platform which has been developed by
Microsoft to simplify the development of modern Windows applications. It is better
known as the .NET Framework. It is a class library that has been added to Visual

             Figure 2.1 - The Visual Studio 2005 IDE: a collection of windows
                including the text editor, directory structures and toolbars.

There are several versions of Visual Studio. One example is the Standard Edition,
which provides standard functionality and supports the entire MSDN library. The
Professional Edition extends that with the integration of Microsoft SQL Server.
Developers who do not want the full package can use a Visual Studio Express
Edition. They are basically a set of free lightweight individual IDEs, which are
provided as stripped-down versions of the complete IDE on a per-language basis.
These editions also do not use the full MSDN Library, but the MSDN Express Library.
The languages that are available as part of the Express IDEs are: Visual Basic
Express, Visual C++ Express, Visual C# Express and Visual Web Developer

2.3 OGRE 3D

OGRE 3D (Object-Oriented Graphics Rendering Engine) is a scene-oriented, flexible
3D rendering engine written in C++. It is an open source tool and was designed to
make it easier for developers to produce applications utilising hardware-accelerated
3D graphics. The class library abstracts the details of using the underlying system
libraries like Direct3D and OpenGL and provides an interface based on world objects
and other high level classes. This means that it can render the same content on
different platforms without the programmer having to take the different capabilities of
each platform into consideration. This reduces the complexity of deploying graphical
applications on multiple systems. OGRE has an object oriented design with a plug-in
architecture that allows easy addition of features, making it highly modular.

OGRE is just a rendering engine. As such, its main purpose is to provide a general
solution for graphics rendering. It is not an all-in-one solution in terms of video game
development or simulation as it does not provide audio or physics support. Generally,
this is thought of as the main drawback of OGRE, but it could also be seen as a
feature of the engine. After all, not everybody who needs a 3D engine wants to make
a video game. The choice of OGRE as a graphics engine gives developers the
freedom to use whatever physics, input, audio and other libraries they want.
Therefore, game developers can make a game engine of their own by using the
OGRE rendering engine and linking other gaming-related libraries to it. Many
experienced programmers have expressed their approval of this approach, because
there are no inbuilt constraints. It can be more daunting for newer users, but they
have access to a growing number of existing frameworks using OGRE.

     Figure 2.2 - One of many examples which can be put together using the rendering
     engine: from left to right, three OGRE logos with a decreasing amount of polygons.

The engine requires a C++ compiler to work. As such, the primary language to
develop an OGRE application is C++. However there are a few alternative languages
for which wrappers have been written. They are Python, Java and .NET (e.g. Visual
Basic and C#).

The OGRE source is made available under the GNU Lesser General Public License
(LGPL), which basically means that developers can use it however they like as long
as the source of any changes made to the core engine are released if they distribute
their product. The source to their application or to new plug-ins does not have to be

3. The assignment and approach

3.1 Analysis of the problem

One of the activities of Océ R&D is the development of software for the embedded
control of printers. Testing the software‟s functionality is an important but difficult
task. Various test facilities are being used within the company for this purpose.
Testing on a native platform leads to stubbing of functionality, causing not all the
software to be tested and real-time behaviour to be influenced from the stubs.
Testing on a laboratory model or prototype brings dependencies with hardware,
planning and priorities.

3.1.1 SIL

To overcome the problems mentioned before, a Software In The Loop (SIL)
simulation has been developed with which the complete software functionality can be
tested on a single PC. This test facility has its own internal clock and uses an old
MATLAB-visualization, which shows a schematic picture of the print engine. When
SIL is activated, the visualization shows the paper sheets going through the paper
path. Test cases are put in scripts for the purpose of error testing.
This solution has proven to be a large success and is currently being further
developed and deployed into multiple projects. However, one considerable drawback
is that SIL is not real-time and does not use the real embedded hardware.

The diagram below shows the situation in a real printer as well as in the SIL-

         Target system                                 Development PC

            Target software                              Target software

                  I/O layer                                     I/O layer

                         I/O signals                                Simulated I/O

       I/O (motors, sensors, …)                      I/O and sheet simulation

                              Real printer                 Software In The Loop

        Figure 3.1 – The situation in a real printer (left) and in the SIL-environment.

3.1.2 BBO

Since the real-time aspect is very significant in a printer, it still has to be tested within
the embedded software. Therefore, most projects also build a Besturings Bank
Opstelling (BBO), which can be translated as Control Platform Test System. In a
complete BBO all controller cards of the embedded system are present on which the
real target software is run. In general the real mechanical parts are not present. The
electromechanical components are only present when it is difficult to simulate them,
like a motor with a high-resolution encoder. Sensors are attached to a simulator that
simulates things like the movement of sheets along the paper path sensors or the
warming up of heaters.
A BBO is also equipped with a large front panel with a schematic drawing of the print
engine. LEDs, switches and pot meters are placed on this panel. The LEDs represent
the status of the sensors and the switches are used to change these statuses.
Analogous values, like the temperature of a heater, can be set by operating the pot
meters. The electromechanical components and the LEDs provide feedback of what
the system is doing. The simulator, switches and pot meters can be used to manually
influence the inputs of the system to test various exceptional situations.

       Figure 3.2 – The BBO of the VarioPrint 6250. Some motors are present below
          the front panel and the controller cards are placed behind it (not visible).

The main goal of a BBO is to be able to test and confront hardware and software
without the need of a complete printer prototype. Test cases can be repeated more
easily and exceptional conditions can be generated with less effort.

The BBO also has a few disadvantages:

      Building a BBO involves a lot of time and resources;
      The front panel is very inflexible with respect to changes in the print engine
      Unlike SIL, a BBO is dedicated to a certain product and can not be reused by
       other projects.

These drawbacks indicate that it is impossible to build a generic BBO, because
different products do not have the same embedded platform, number of controller
cards and electromechanical parts. Building and maintaining a BBO would be a lot
easier when the front panel would be more flexible to construct.

3.1.3 HIL

The distinct disadvantages of SIL and the BBO provide enough motivation for R&D to
create a new test solution. A Hardware In The Loop (HIL) simulation will combine the
flexibility of SIL and the real-time attribute of the BBO. It can be defined as:

A test facility that tests the complete embedded system, including target hardware
and software, using simulated sheet behaviour and simulated or real I/O without
changing the target hardware or software.

HIL will extend SIL‟s purpose of testing software functionality by making integration
testing with hardware possible. This means that the software will run on the actual
embedded system. It is basically SIL with a real-time aspect.

The diagram below shows the situation in the HIL-environment:

                   Target system

                                       Target software

                                         I/O layer

                         I/O signals                 I/O signals

                   I/O (motors,                 Sheet simulation
                   sensors, …)                  and I/O interference

                                            Hardware In The Loop

                    Figure 3.3 – The situation in the HIL-environment

In general, testing with HIL should be real-time, flexible, intelligent, project
independent and easy to set-up and maintain. The simulation is currently being
developed within R&D.

3.1.4 Visualization

Three considerable test facilities have been covered. Although they have different
purposes, they all require one specific component: some kind of visualization. Every
test environment implements this in its own way. SIL uses an application created in
MATLAB and the BBO has a physical front panel. However, HIL is still in
development and therefore simply does not yet have a visualization of its own. The
most persuasive reason for starting up a graduation project was to create a general,
flexible, user friendly and scalable visualization.
During the development this component is initially meant as a component for HIL. If
this solution proves to be successful, the visualization can then be altered and
deployed onto the other test facilities. Especially the BBO would benefit from this
application, because it would replace the front panel and therefore decrease building
time and resources.

3.2 Task description

The assignment is defined as follows: “Designing and implementing a digital
visualization, which can convert the calculations of the HIL-simulator (and later other
test facilities) into an animation and can send manually entered changes to this
This visualization has two major functionalities:

   1. Animating a paper sheet through a configurable paper path and represent the
      status and analogous values of sensors and actuators in the print engine.
   2. Allowing the user to manually influence components for exception testing and
      pass analogous values on to these objects.

3.3 Planning

The whole planning was made in the first week and can be found in appendix 2. As
shown, the project can be divided in a few phases. The next paragraph will cover
them in detail. They are:

      Analysis - this stage includes collecting information concerning the
       assignment and carrying out all preparatory activities prior to the development
       of the application. It takes about six weeks to have some constructive results.
      Design/realization - these two steps are combined in one development
       phase. The application is designed and implemented incrementally per
       functionality for approximately nine weeks.
      Testing - this action implies that the application is tested both functionally and
       technically. It takes place near the end of the graduation period and lasts two
       to four weeks.
      Finishing - writing several design documents and a user manual is the
       project‟s last phase, which happens in the final two weeks.

It should be mentioned that some activities are executed parallel to each other. This
is particularly true for writing the graduation report and preparing the (interim)
graduation presentation, which are done over the entire graduation period.

3.4 Approach

The following approach has been used for this project:

      The first step is analysing and understanding the background, the nature of
       the problem, the task description and the direct system context of the

      The analysis continues with setting up functional and non-functional
       requirements of the visualization. These were obtained by interviewing some
       of the (eventual) users of the test facilities and giving priority to the demands
       and requests that were mentioned the most. These first two analysis steps
       resulted in a project plan and a document containing the final requirements.

      Thirdly, an inventory of various potential development tools was needed. A
       few of them were already known. These are the toolsets that are currently
       being used within R&D, like MATLAB and CAD. Furthermore, an external
       search had to be made in order to have a diverse collection of candidates.
       Several criteria were used for this investigation, such as the extent to which
       the functional requirements could be realized with the tool, the programmer‟s
       learning curve, availability and cost.

      Once a tool and programming language is chosen, the project can move on to
       the next phase: designing and programming the visualization. Since the
       application‟s requirements and used libraries were most likely to change
       throughout the development process, it was decided that it would be
       incrementally developed per functionality.

      Testing the application follows closely every time a requirement is
       implemented. By the end of the graduation period the application is fully
       tested, both functionally and technically. Moreover, the program‟s code is
       inspected for possible optimizations, correct naming and code comments.

      Finishing the assignment happens once the product fulfils the primary
       functional requirements. The final touch is documenting the design and used
       configuration and writing a user manual.

A schematic overview of the approach is shown below:

 Problem analysis              Requirements set-up               Toolset inventory

                                                               Functionality design

                                      Functionality test

                                                           Functionality implementation
              Full application test

            Project documentation

               Figure 3.4 – A schematic overview of the project approach

             The following milestones were produced during the first part of the graduation period:

                      The functional and non-functional requirements of the visualization;
                      A project plan;
                      A document containing the results of the development tools inventory.

                                       Project plan
                            27-2                                        21-3
                        Requirements                              Inventory results

                18-2         25-2            3-3      10-3          17-3          24-3      31-3           7-4          14-4           21-4
11-2-08                                                                                                                                       25-4-08

             The following milestones were produced during the second part of the graduation

                      The design and implementation of the sheet animation functionality;
                      The design and implementation of the manual object influence functionality;
                      This graduation report;
                      A graduation presentation;
                      Design documentation;
                      A user manual.
                6-5                                             2-6                                                                    7-7
          Sheet animation                                   Manual object                               23-6                     Design and user
            functionality                              influence functionality                     Graduation report             documentation

                 5-5         12-5           19-5      26-5           2-6              9-6   16-6           23-6         30-6           7-7
28-4-08                                                                                                                                       11-7-08

4. Project execution and results

4.1 Execution

4.1.1 Analysing the assignment and its context

The first goal was trying to understand the need for a visualization tool by studying
various documents and consulting a few employees. The articles contained
information about the need, wanted features, architecture and aspirations of HIL and
its components. The employees demonstrated SIL and the BBO by operating it and
explaining their every action. An initial project plan, containing an early project
approach and interpretation of the assignment, was written parallel to these activities.

4.1.2 Setting up requirements

Once the most essential information was gathered, the requirements could be
formed. This was done by speaking with some of the employees, who use or will use
the different test facilities. The objective of these interviews was to get a clear answer
to the question: “What features should be present in the visualization?” The results of
all conversations were unique, but included some common demands and requests.
These elements were given a higher priority, while setting up the official
The functionalities of the application were divided into three categories:

      Primary functional requirements: These features were sure to be
       implemented during the graduation period and were given the main focus
       throughout the development process.
      Secondary functional requirements: If there was any time left after
       programming the primary requirements, then the secondary features would
       be evaluated on the amount of effort. They would then be planned or
       neglected for implementation with respect to the remaining development time.
      Non-functional requirements: These are actually the most important quality
       attributes of the visualization, which must be taken into account during the
       implementation. Examples are maintainability and flexibility.

The complete list of the visualization‟s requirements can be found in appendix 3. The
project plan was worked out and finalized during and shortly after making this list.

4.1.3 Making an inventory of potential development tools

The next and final step in the analysis phase was investigating some suitable
development toolsets. The main activities in this study were reading about the
features of every tool and trying to make a small program which could function as a
proof of concept. The list of requirements served as a point of orientation. These
tools were assessed according to a few criteria:

      Available facilities with which the functional requirements could be realized;
      Programmer friendliness;
      Learning curve for the programmer;
      Cost;
      Scalable concerning the monitor size.

After a search throughout the company and on the Internet, the following tools were
eventually found:

      Monitor: a tool made in MATLAB. This is the visualization used by SIL.
      Happyflow: an extended version of Monitor, consisting of a toolbox and a
       paper path designer.
      OneSpace Designer Modeling 2005: a CAD-environment used by the
       mechanical engineers within Océ R&D to design the physical components of
       a printer.
      Blender 2.45: a package that focuses on modelling and animating 3D-
      OpenGL: an application can also be built from scratch by including a graphics
       library like OpenGL and using an IDE such as Visual Studio to program
       towards it.

The results of the inventory have been documented and will be addressed in this
subparagraph including their benefits and drawbacks.

Monitor is a simple visualization component, made in MATLAB. This application
continuously receives packets from SIL by means of a TCP/IP socket. This packet is
described in detail in figure 4.6 and simply contains position information of sheets.
Monitor translates this data into images, thus making an animation.

This tool was not chosen as the development tool, because its successor Happyflow
pretty much offers the same functionality. However, the method described above is
very useful concerning the input of sheet data. The frame structure is sufficient to
show a standard sheet animation and is used in the final development.

    It is a simple and goal-oriented program: only 3 files needed to run.

    Its successor Happyflow offers the same functionality and more.

Happyflow is the successor of Monitor and has been used within Océ R&D to
simulate and visualise several paper path animations. It consists of a toolbox with
various functions and a number of program files that determine the characteristics of
the simulation. The configurations of the application are entered through a GUI,
which passes the user‟s input to the files by means of function parameters. Examples
are the number and type of sheets, the sample frequency and if the sheets should
face up or down upon exiting the engine. The application then calculates the eventual

                 Figure 4.1 - The Happyflow application: with the GUI on
                       the right and the visualization in the top left.
Happyflow was not suitable for developing the new visualization for a variety of
reasons. Although it has a lot of facilities to visualize a print engine, it can not work
with multiple threads. Without this technique, the program will ultimately have trouble
rendering graphics and receiving sheet data simultaneously once more functionality
is implemented.
However, one of the most substantial problems was the lack of real-time behaviour.
After a short study, it seemed that Happyflow had a simulated clock that depends on
the sample frequency, the image size, the number of sheets per minute and the
number of sheets visible. In other words, the application‟s speed is determined by the
user‟s input and does not take real-time aspects into account.

    More than enough facilities to complete the visualization;
    Enough background knowledge present within Océ;
    Immediately available.

    Not real-time;
    Multithreading is not possible;
    MATLAB has a higher learning curve than the conventional languages;
    MATLAB requires a rather expensive license;
    Not hardware accelerated;
    Later versions of MATLAB introduce compatibility problems.

OneSpace Designer Modeling 2005
This toolset was developed to allow the user to design (components of) machines in
3D quickly and easily. It is used within Océ R&D by the mechanical engineers to set
up a 3D model of a printer. Once a model is assembled, relationships can be added
to objects, such as relative movement. Moreover, static animations can be made in
design time, like moving a lever. The rendered images are close to realistic.

OneSpace arrived somewhat late in the investigation, which is the main reason for
not getting as much attention as the other packages. Despite this, its main purpose
and disadvantages were easy to determine: it focuses on the design of products in
3D and has a fairly high learning curve. Besides that, OneSpace requires a
modification of the work station to operate properly. The conclusion was that it had
more drawbacks than advantages and was therefore not picked as the development
tool for the visualization.

    Designing in 3D is possible;
    Models and animations are realistic.

    Focuses mainly on 3D design;
    Fairly high learning curve;
    Not easily available to everybody;
    Textual programming is not possible;
    It requires a floating license.

Blender 2.45
Blender is an extern open source package, which focuses on modelling and
animating 3D objects. As such, it facilitates the user in creating, shape, refining and
moving these objects over a predefined or unknown path. The tool also allows 2D
modelling, but this is always done in 3D space. Scripting with Python is also possible,
with which these functionalities and GUIs can be made. Textual programming is
procedural and happens in a built-in text editor.
Blender can be downloaded with no charge. It has proven that a paper sheet can
easily be programmed to follow a paper path with a fixed curve. Furthermore, it can
render realistic objects and apply lifelike attributes to them, like curves in a sheet.

This package demands a great deal of knowledge of the programmer to be able to
work with it. That means that any upgrades on the visualization will cause the user to
study Blender, which may take a while. Therefore, this package has not been
selected as the visualization toolset, but it may be a good second choice and worth
further investigation in the future.

                             Figure 4.2 - Blender‟s interface

    Designing in 3D is possible;
    Scripting in Python is possible;
    Effective animations are easy to make;
    Free of charge;
    Immediately available

    Focuses mainly on 3D-design;
    High learning curve;
    Extent of modularity is unknown;
    Upgrades on the visualization require knowledge of Blender.
OpenGL is a free graphics library, which supplies standard functions for making 2D
and 3D applications. It is possible to call these functions by including header files of
OpenGL to the main program. Using this, the programmer can draw and manipulate
shapes, text, background pictures and other objects on a set position. In addition,
objects can be controlled using a mouse or keyboard. C++ allows an object-oriented
and low-level implementation of these functionalities. Besides that, multithreading is
possible in C++.

Using a combination of Visual Studio and OpenGL means that the visualization
would have to be built from scratch. This costs more effort than with the other
candidates, especially because programming would happen on a low level. However,
this does allow more modularity and freedom regarding the implementation. In
practice, this means that external libraries can be included to add a programming

         Figure 4.3 - This triangle is drawn by defining the position and colour of its
             three vertices and letting OpenGL take care of the actual drawing.

    More than enough facilities to complete the visualization;
    More control over the implementation;
    Multithreading is possible;
    Designing in 3D is possible;
    Immediately available;
    Free of charge;

    It is unknown if low-level programming is suitable for the application;
    Some features are difficult to accomplish in OpenGL, such as smooth paper
      path shaping.

Initially, OpenGL was chosen for the development of the visualization, because of the
high flexibility and performance. Visual Studio 6.0 was selected instead of the 2005
edition, because its architecture was more in sync with the other development
environments used within Océ R&D. The only real drawback was that programming
directly towards OpenGL is rather dated and that the implementation of some
features could bring about some difficulties. One of the R&D interns realized this and
foresaw that shaping the segments smoothly could become a problem. Luckily he
had acquired some experience with OGRE 3D, a graphics rendering engine that
abstracts the low-level implementation of OpenGL by working with objects. Basically,
it provides a layer on OpenGL. More on OGRE can be found in paragraph 2.3. He
had also made a small program in which the ease of forming a smooth paper path
was demonstrated.

The image below depicts the program made in OpenGL right before the introduction
of OGRE. Only a single paper path segment was used for simplicity reasons. The
application takes the data sent by SIL, creates the sheet objects at runtime and
continuously passes the positions to them using function parameters. This makes the
sheets move along the segment. In the future more segments would have been
added according to their information in the data file.

    Figure 4.4 - The coloured lines represent sheets on a predefined segment (the long
         white line).The number in the top is an example of a position coordinate.

Switching over to OGRE was a big step. The details of this change are given in
paragraph 4.2.

A standard OGRE application consists of the following: Like any other C++ program,
it has a main function. A main application object is created in here, which then tries to
call a go-function. This method does three things:

      Setting up the application by calling some internal functions, like creating all
       the static objects in the scene, creating a manager to keep track of all these
       objects and creating the camera.
      Rendering the program in an infinite loop. It does three things within this loop:
       Calling a function FrameStarted before one frame is rendered, rendering one
       frame and calling a function FrameEnded after one frame is rendered.
      Destroying the application when the user quits it.

Next to the main application, another object needs to be covered: the frame listener.
Its properties and behaviour are also implemented in a class. This is where the
FrameStarted and FrameEnded functions can be called from. A frame listener keeps
track of any events regarding a frame, like mouse or keyboard input and delays
before rendering a frame. The frame listener is created in the first step of the go-
function. The programmer is free to put his or her own code within the previously
mentioned functions in order to customize the application.

4.1.4 Developing a sheet animation

This activity set off the start of the development stage in the project. The first
functionality scheduled for implementation was a sheet animation. Prior to
programming this feature, a design was set up:


                          Sending position coordinates to sheet
                             objects by means of a socket



                                   Loading segment
                   1..*              information          1..*
                     Sheet                                 Segment

                                         Data file


                                 supplies GL-functions


                Figure 4.5 – The preliminary design of the sheet animation.

   As shown in figure 4.5, SIL is used as the sheet behaviour simulator for testing
   purposes, because HIL simply was not finished at the time. SIL calculates sheet
   information and sends its data packets described in figure 4.6 through a socket to the
   main application. This packet, or frame, has the following format:

                 Leading            Leading Trailing          Trailing       Leading
           Sheet  Edge               Edge    Edge              Edge    Sheet  Edge
Timestamp number position           segment position          segment number position            ...

(1 double)       First sheet visible in this timestamp (5 doubles)         Second sheet visible in
                                                                           this timestamp (5 doubles)

                Figure 4.6 – The format of the data packet that is currently
                         sent by SIL to the Monitor-visualization.

   The first element is a timestamp, indicated in seconds. This is followed by the unique
   sheet number. A paper path is made up of segments. The next elements in the
   packet are the position on a specific segment and the number of that segment. Two
   positions and two segment numbers are received: that of the leading edge and that
   of the trailing edge. The leading edge can be interpreted as the “head” of a moving
   sheet and the trailing edge as its “tail”.
   The sheet number, the two edge positions and the two edge segments form a group,
   which per timestamp occurs as many times as there are sheets visible in the
   visualization. For example, if three sheets can be seen, the related frame would
   consist of a timestamp and three groups of sheet information. The size of each
   element is 1 double (8 bytes). The general purpose of this method is to produce an
   animation by sending multiple positions shortly after each other.
   This application then creates as many sheet objects as needed and a segment
   object, whose classes are specified as Sheet and Segment, respectively. The actual
   shape and draw functions of these objects are defined in these classes. This is
   where the graphics library makes its entrance. The main application catches the data
   sent by SIL and determines how many sheets need to be created, drawn and
   destroyed. By separating responsibilities a greater modularity is attained.

   Loading segment, sensor and actuator information from an XML-file
   After two weeks of getting familiar with OGRE and having an initial program, the next
   action was to shape and draw the paper path according to textual coordinates in a
   data file. At first there were two types of data files to choose from: a binary MATLAB-
   file and an XML-file that could be generated from it using a script. Loading the data
   from an XML-file turned out to be a lot easier, since there already was an XML-parser
   available: TinyXML. This is basically just another API which can be integrated in a
   Visual Studio application. TinyXML has been used to extract the control points of
   every segment. Control points are a few specific points, that can be linked together to
   draw a curve. The application provides these points to OGRE, which takes care of
   connecting the dots and drawing the curve. The same technique is applied to loading
   sensors and actuators, whose positions on a specific segment are stored in another

Implementing multiple threads
An application that includes continuous rendering functionality is in essence stuck in
an infinite loop, which takes care of drawing all the objects on the screen. The
visualization also receives data from a simulator. With a single thread this would
mean that the data is received within the render loop, causing serious drops in the
frame rate. Therefore, another thread was implemented, which takes care of
receiving the sheet data. Threads are a way for a program to fork itself into two of
more simultaneously running tasks.

Displaying the mouse cursor and GUI elements
OGRE does not have a standard mouse cursor. This must be included by the
programmer. There is a free external library available, called CEGUI (Crazy Eddie‟s
GUI System). It is object-oriented, written in C++ and provides windows and widgets,
such as buttons, checkboxes and menus. After some research, a standard mouse
cursor was implemented in the visualization. A while later, some buttons were added
as well. The functionalities of these buttons are to quit the application and to initialize
the PIM, as described in the requirements.

Manually influencing objects
The next step was developing the object manipulation feature. The user had to be
able to select sensors and actuators using the mouse. Passing analogous values to
them through the keyboard was also a requirement.
The first functionality was realized using an invisible ray, which starts from a
determined point in 3D-space and travels in a certain direction. When the left button
of the mouse is clicked, a ray is created with the position of the cursor as its point of
origin. It will travel directly into and perpendicular to the screen. Every object that is in
its path will be stored in a variable. The only thing that is left is to check whether the
first intersected object is a sensor or an actuator. If this is true, then a wire frame box
is drawn around it as a way of selection.
The same technique is used for showing tool tips of every object. Only this time, a
ray is created on every movement of the mouse. If the mouse hovers over a sensor
or an actuator, this will be the first object returned by the ray.

4.1.5 Future activities

As mentioned in the introduction, this report was finished five weeks before the end
of the graduation period, which was right after implementing part of the object
influence feature. The following activities were scheduled from that point on:

       Determining the object attributes and specifying a new data packet format;
       Making a smoother sheet animation;
       Code optimization;
       Documenting the design and the used configuration and writing a user

4.2 Adjustments

The introduction of OGRE marked a large change in the development process. The
original OpenGL program code could not be easily transferred to OGRE. The
graphics-independent features, like the socket implementation and loading the paper
path from a data file, remained unaffected. Shaping and drawing objects however
was at first sight of a different nature. Unlike pure OpenGL, objects in OGRE must be
attached to a scene node object before they are displayed on the screen. Also, many
classes in OGRE have several derived subclasses. It took a while to understand the
intentions of this technique and be able to use it to full effect.

4.3 Results

Considerable progress has been made regarding the visualization. A few
functionalities still need to be developed at the moment, but their completion is
expected within the graduation period. The same applies to the design documents
and the user manual. An interim class diagram can be found in appendix 1.

The following results have been or will be delivered:

      The functional and non-functional requirements of the visualization;
      The design and implementation of the visualization according to most of the
       functional requirements;
      This graduation report;
      Documentation regarding the design and the used configurations;
      A user manual.

The progress with the visualization so far is shown in the figure below. The red and
blue lines are individual segments and are loaded from the XML-file. The rectangle,
indicated by the yellow circle, represents a sheet. It is currently positioned at the start
of the PIM and will move up and to the right through the fuse and further to the
finisher. The information for this sheet animation is calculated and transmitted to the
visualization by SIL.

The green triangles and pink diamonds are sensors and pinches (a type of actuator),
respectively. An example of manually influencing such an object is the pinch left of
the fuse, which is indicated by a surrounding white rectangle. The detailed
information of that object is displayed in the top right corner of the screen. The edit
box below the finisher can be used to change this data, while the pinch is selected.
The button “PIM init” can be used to initialize the PIM, i.e. activate a few sensors

                               SHEET                           FINISHER

                    Figure 4.7 - The print engine, paper path and some
                       sensors and actuators of the VarioPrint 6250.


As mentioned previously, getting familiarized with OGRE caused a small delay in the
project. Fortunately, this never led to a serious lack of development time. At the
moment of writing it seems that the assignment will be finished with success. All but
a few features of the visualization are currently implemented. The corresponding user
documents still need to be written. The final products were natural results of the
milestones, like the list of requirements.

Developing a visualization using C++ and a graphics engine has been fun, valuable
and challenging. Trying to pick useful information from the abundance of background
data at the very beginning of the project was slightly intimidating and confusing. The
same applies to finding a suitable approach. After a couple of weeks it became clear
that there was a lot of knowledge of support in the direct environment, which made it
easier to carry out the assignment.

The basic requirements of the visualization are realized by the end of the graduation
period. This includes the sheet animation, showing and influencing sensors and
pinches and loading the paper path from a data file. Of course, the application allows
for more functionality to be implemented. More object types and analogous values
can be shown; a recording and playback function may be useful and other print
engines must be loaded in easily without changing the code (much). These
requirements are pretty much stand-alone, so they can be implemented one at a time
by a full-time software engineer. It is also possible to start up another graduation
project and combine these new requirements along with any further optimization of
the existing code. One of these two methods can be picked depending on the
urgency of these functionalities.

This graduation project fulfilled the requirements of an internship at HBO level
regarding tasks and complexity. Working in a large environment was an entirely new
and exciting experience. Océ R&D was a good example of how a big organization
operates. Nevertheless, after a few months it looks smaller than it actually is.
Although the employees were constantly busy, they always had time to answer
questions or help with problems concerning development.


   Laan, G. (2005). Aan de slag met C++. Den Haag; Academic Service.

   Non-disclosable internal documents on the subject of SIL/HIL and the visualization.

   Blender. Blender
   Océ. Homepage Océ
   OGRE. Homepage OGRE 3D
   OGRE. OGRE Wiki

    Programming websites
   Canaware. Creating a Winsock Application
   Grinning Lizard. TinyXML Documentation
   Microsoft. MSDN
   NeHe Productions. OpenGL lessons

   Microsoft Visual Studio
   OGRE 3D

       Appendix 1 – Class diagram

                          Thread                                ExampleApplication
               #_threadObj : Thread                    #mRoot : Root
               #hThread : HANDLE                       #mCamera : Camera
               #threadProc() : unsigned long           #mSceneMgr : SceneManager
               +Thread()                               #mFrameListener : ExampleFrameListener
               +start() : void                         #mWindow : RenderWindow
               +stop() : void                          #mResourcePath : String
               +run() : virtual void                   #setup() : virtual bool
                                                       #configure() : virtual bool
                                                       #chooseSceneManager() : virtual void
                                                       #createCamera() : virtual void
                                                       #createFrameListener() : virtual void               ExampleFrameListener
                    C_MainApplication                  #createScene() : virtual void                -splinePos : Real
        -xSplineCoordinates[ ] : float                 #destroyScene() : virtual void               -sheetNode : SceneNode
        -ySplineCoordinates[ ] : float                 #createViewports() : virtual void            -spline : SimpleSpline
        -segmentLength[ ] : float                      #setupResources() : virtual void             -SceneMgr : SceneManager
        -nrSplineSteps : int                           #createResourceListener() : virtual void     #mLMouseDown : bool
        -segmentCount : int                            #loadResources() : virtual void              #mRMouseDown : bool
        -sensorCount : int                             +ExampleApplication()                        #mRaySceneQuery : RaySceneQuery
        -pinchCount : int                              +~ExampleApplication()                       #mCurrentObject : SceneNode
        -sheetNode : SceneNode                         +go() : virtual void                         #mouseOver : bool
        -sensorNode[ ] : SceneNode                                                                  #textWindow : CEGUI::Window
        -pinchNode[ ] : SceneNode
                                                                       1                            +ExampleFrameListener()
        -spline[ ] : SimpleSpline
        -segmentNode : SceneNode                                                                    +~ExampleFrameListener()
   1    -backgroundPlane : C_BackgroundPlane                                                        #updateStats() : void
        -sheet : C_Sheet                                                                            +quit() : bool
        -segment[ ] : C_Segment                                                                     +frameStarted() : bool
        -sensor[ ] : C_Sensor                                                                       +frameEnded() : bool
                                                                                              1     +windowResized() : virtual void
        -pinch[ ] : C_Pinch
        #mSystem : CEGUI::System                                                                    +windowClosed() : virtual void
        #mRenderer : CEGUI::OgreCEGUIRenderer                                                       +showDebugOverlay() : void
                                                                                                    +mouseMoved() : bool
        #createScene() : void                                                                       +mousePressed() : bool
        +C_MainApplication()                                                                        +mouseReleased() : bool
        +~C_MainApplication()                                                                       +keyPressed() : bool
        +loadPathFromXML() : int                         1                                          +keyReleased() : bool
        +loadSensorsFromXML() : int                                                                 +getSheetNode : SceneNode()
        +loadPinchesFromXML() : int                                                                 +setSheetNode() : void
        +OpenConnection() : bool                                                                    +getSpline : SimpleSpline()
        +ReceiveData() : void                                                                       +setSpline() : void
        +run() : void                                                                               +getSplinePos : Real()
        +go() : void                                                                                +setSplinePos() : void
                                                                                                    +setSceneManager() : void
               1          1            1

                                1..*                             1                          1..*

             C_Sheet                       C_Sensor             C_BackgroundPlane                   C_Pinch                      C_Segment
        -lePos : float         -sensorName : String                                         -pinchId : String
        -tePos : float         -sensorActivated : bool                                      -pinchPosition : float
                                                               +C_BackgroundPlane()                                        +C_Segment()
1..*    +C_Sheet()             -sensorPosition : float                                      -pinchSegment : int
                                                               +drawBackground() : void                                    +drawSpline() : void
        +drawSheet() : void    -sensorSegment : int                                         +C_Pinch()
                               +C_Sensor()                                                  +drawPinch() : void
                               +drawSensor() : void                                         +getPinchId() : String
                               +getSensorName() : String                                    +setPinchId() : void
                               +setSensorName() : void                                      +getPinchPosition() : float
                               +getSensorActivated() : bool                                 +setPinchPosition() : void
                               +setSensorActivated() : void                                 +getPinchSegment() : int
                               +getSensorPosition() : float                                 +setPinchSegment() : void
                               +setSensorPosition() : void
                               +getSensorSegment() : int
                               +setSensorSegment() : void

Appendix 2


Primary functional requirements
    The clear representation and animation of:
          o A paper sheet through the paper path;
          o Sensors;
          o Actuators.
    Being able to manually influence:
          o Sensors;
          o Actuators.
    The automation of certain actions, such as the initialization of the PIM;
    The position and shape of the paper path and all objects concerning a
      random print engine must be loaded from a data file in a predetermined

Secondary functional requirements
    Zooming in on objects for additional information;
    The representation of analogous values, like preheater temperature;
    Being able to manually influence analogues values, like the paper format in
     the PIM;
    Recording and playback function;
    Stopping a sheet in the paper path without influencing a sensor.

Non-functional requirements
    User friendly;
    Maintainability (source code);
    Flexible/reusable;
    Extendable;
    Scalable concerning the monitor size;
    The application should be able to run stand-alone from the HIL-simulator;
    The application must be developed according to the procedures of Reuse;
    The application must run in sync with the actual status of the machine, for
      example when showing paper sheets and object values;
    The application would benefit from a paper path that is represented as
      smooth as possible.

Appendix 3
                                       Week   Week   Week 9    Week 10     Week     Week 12     Week      Week     Week 15      Week 16    Week 17
    PLANNING – First half               7      8                            11                   13        14
           Collecting background
                                        An     An
            Making a project plan*      An     An      An        An
   Determining requirements and                An      An        An
         Setting up requirements               An      An        An
     Inventory development tools               An      An        An         An         An
  Getting familiar with the chosen                               An         An         An
          Design per functionality                                                     De        De        De         De           De        De
 Implementation per functionality                                                                Re        Re         Re           Re        Re
 Graduation report/presentation*

                                                     Require- Project               Inventory
                   MILESTONES                        ments    plan                  results

                        Analysis        An
                         Design         De
                     Realization        Re
                         Testing        Te
                       Finishing        Fi
  Graduation report/presentation        Gr
                       Vacation                               * These products are liable to change during the entire graduation period.

                                   Week   Week   Week    Week      Week      Week      Week      Week      Week 26      Week 27      Week 28
  PLANNING – Second half            18     19     20      21        22        23        24        25
         Making a project plan*
        Design per functionality           De     De      De        De        De        De        De
Implementation per functionality           Re     Re      Re        Re        Re        Re        Re          Re
Functional and technical testing                          Te         Te        Te        Te        Te         Te
              of the application
           Finishing the project                                                                   Fi         Fi           Fi           Fi
Graduation report/presentation*            Gr     Gr      Gr         Gr        Gr        Gr        Gr         Gr           Gr           Gr

                                                                                                          Graduation Final           Product
                 MILESTONES                                                                               report     product         documents

                       Analysis    An
                        Design     De
                    Realization    Re
                        Testing    Te
                      Finishing    Fi
 Graduation report/presentation    Gr
                      Vacation                          * These products are liable to change during the entire graduation period.

Appendix 4 – Sequence Diagram

                           Starting up the application

   User                        MainApplication                          ExampleApplication                       Thread


















Description: Oce Bruning document sample