Manufacturing Execution Systems
Demonstrator Platform
Integrating professional MES tools with LEGO® components
RICARDO
OLIVEIRA
Master of Science Thesis
Stockholm, Sweden 2011
Manufacturing Execution Systems
Demonstrator Platform
Integrating professional MES tools with LEGO® components
RICARDO
OLIVEIRA
Master’s Thesis in Computer Science (30 ECTS credits)
at the Systems, Control and Robotics Master’s Program
Royal Institute of Technology year 2011
Supervisor at CSC was Danica Kragic
Examiner was Danica Kragic
TRITA-CSC-E 2011:129
ISRN-KTH/CSC/E--11/129--SE
ISSN-1653-5715
Royal Institute of Technology
School of Computer Science and Communication
KTH CSC
SE-100 44 Stockholm, Sweden
URL: www.kth.se/csc
Manufacturing Execution System demonstrator
platform
Integrating professional MES tools with LEGO® components
Abstract
Optimizing resources and decreasing waste is a primary and constant challenge in the
manufacturing industry. Manufacturing execution systems (MES) are tools to achieve efficiency
in many aspects of the production processes. However, MES concepts can be complex and hard
to understand, hindering production plants from implementing such systems. It is the aim of this
thesis to create a robust and flexible demonstrator platform to make it easy to see and
understand MES. Hence, the demonstrator can be used to create a constructive dialogue within
the factory management team. In addition, the demonstrator can efficiently work as an
educational tool, specifically for people who are not used to production and assembly.
By analyzing the requirements for the demonstrator, LEGO® components turned out to be a
good match because of their high flexibility and low cost. The unusual use of LEGO bricks and
MINDSTORMS® components in an industrial environment provided an extra inspiration along
the project.
This thesis has shown that connecting a professional MES with LEGO components is a viable
solution to highlight the desirable features. In addition, LEGO components have the feature of
being attractive, captivating attention.
Keywords: Manufacturing Execution Systems, Lean manufacturing, Production system,
Production management, LEGO MINDSTORMS.
Acknowledgements
This thesis work was carried out between January 2011 and June 2011 in collaboration between
Chalmers University of Technology, Royal Institute of Technology and Volvo Technology
Corporation. The authors have background from the Master programs Systems Control and
Mechatronics and Systems Control and Robotics. The tasks have been equally shared between
Pierre Johansson and Ricardo Mendes de Oliveira.
We would like to express our gratitude and appreciation to the complete team that was part of
the project we worked on, especially to our supervisors Jenny Everbring and Johan Sahlström at
Volvo Technology, who kindly integrated us in the company environment. It has been a great
time to work with such encouraging people.
We wish to thank our examiners at Chalmers University of Technology and Royal Institute of
Technology, Jonas Fredriksson and Danica Kragic, respectively, for the availability and all
support provided as well as to make it possible both universities collaborating with each other.
Thanks as well to the Cluster program that allowed Ricardo to do the exchange between
Instituto Superior Técnico (Lisbon) and Royal Institute of Technology.
We would also like to thank Steven Canvin at LEGO for a great cooperation in the underlying
project.
Furthermore we would like to express our gratitude to Krister Thelin and Jonas Andersson at
Volvo IT in Skövde.
Last but not the least, a special thanks to our families that, in their way, motivated and
encouraged us, throughout our educational process and private life.
Göteborg June 2011
Pierre Johansson
Ricardo Mendes de Oliveira
Division of Work
Both thesis workers were involved in the decisions taken along the development process,
together with the Volvo Technology team that managed the project. Both students took visits to
plants in order to perform research. They met Volvo IT to discuss requirements and to integrate
the systems implemented.
The whole designing process of the demonstrator, namely the trucks and carrier designs, was
carried out by both, each contributing differently to each module, but overall in a balanced way.
Pierre Johansson focused on the gate and kit programming. He also got an understanding of
MONT server architecture and introduced the all necessary data in the database.
Ricardo Oliveira focused on the communication interface between LEGO and Volvo IT
systems. He was also dedicated to the programming of the transporter layer.
In the testing phase, both were present, debugging and fixing remaining bugs. The presentation
on the Tech Show 2011 was assisted full time by both, explaining the platform concepts to the
visitors and preventing any technical issues.
Table of Contents
1
Introduction ........................................................................................................................... 1
1.1
1.1.1
2
Purpose .......................................................................................................................... 1
1.3
Objective ....................................................................................................................... 2
1.4
Scope ............................................................................................................................. 2
1.5
Project phases ................................................................................................................ 2
1.6
Limitations .................................................................................................................... 3
1.7
Environmental aspects .................................................................................................. 3
Theory ................................................................................................................................... 5
2.1
Manufacturing Execution Systems ............................................................................... 5
2.2
Lean manufacturing ...................................................................................................... 7
2.2.1
Poka-yoke .............................................................................................................. 7
2.2.2
Andon .................................................................................................................... 7
2.2.3
Ergonomics ........................................................................................................... 8
2.2.4
Line balancing ....................................................................................................... 8
2.3.1
Volvo systems ............................................................................................................... 8
Manual versus automatic stations ......................................................................... 9
Demonstrator requirements ................................................................................................. 11
3.1
Decisions influence on requirements .......................................................................... 11
3.2
Volvo requirements ..................................................................................................... 11
3.2.1
Reproducibility.................................................................................................... 11
3.2.2
Low cost .............................................................................................................. 11
3.2.3
Flexibility ............................................................................................................ 11
3.2.4
Portability ............................................................................................................ 11
3.2.5
Integration with Volvo systems .......................................................................... 12
3.3
MES concepts requirements ........................................................................................ 12
3.3.1
Poka-yoke ............................................................................................................ 12
3.3.2
Testing ................................................................................................................. 13
3.3.3
Other concept features......................................................................................... 13
3.4
4
Volvo Technology Corporation ............................................................................ 1
1.2
2.3
3
Background ................................................................................................................... 1
LEGO as a tool ............................................................................................................ 13
3.4.1
LEGO MINDSTORMS specifications................................................................ 14
3.4.2
LEGO Digital Designer....................................................................................... 16
Implementation ................................................................................................................... 17
4.1
Demonstrator setup ..................................................................................................... 17
4.1.1
ML010 ................................................................................................................. 18
4.1.2
KIT ...................................................................................................................... 18
4.1.3
ML020 ................................................................................................................. 18
4.1.4
ML030 ................................................................................................................. 18
4.1.5
ML040 ................................................................................................................. 18
4.1.6
Mapping concepts to stations .............................................................................. 19
4.2
Product design ............................................................................................................. 19
4.2.1
Consistence with reality ...................................................................................... 20
4.2.2
Modular concept.................................................................................................. 20
4.2.3
Variant handling .................................................................................................. 24
4.2.4
Functional features .............................................................................................. 25
4.3
Transporter setup......................................................................................................... 26
4.3.1
Transport method ................................................................................................ 27
4.3.2
Carrier configuration ........................................................................................... 27
4.4
Kitting and gate ........................................................................................................... 29
4.5
Transporter programming ........................................................................................... 33
4.5.1
Communication interface .................................................................................... 33
4.5.2
Message exchanging protocol ............................................................................. 34
4.5.3
Carrier programming ........................................................................................... 36
5
Testing................................................................................................................................. 39
6
Discussion ........................................................................................................................... 43
7
Conclusions ......................................................................................................................... 45
7.1
Future work ................................................................................................................. 45
References ................................................................................................................................... 47
Appendix A – Variant matrix...................................................................................................... 49
Appendix B – Reference catalog of product modules................................................................. 51
Appendix C – Picture from Tech Show 2011 ............................................................................. 53
Introduction
1 Introduction
1.1 Background
Manufacturing Executions Systems is a set of tools that combine several aspects in production,
based in IT solutions that have proved to increase productivity and quality. A study made by
Manufacturing Enterprise Solutions Association, hereinafter MESA, shows that several benefits
can be achieved by using MES. In the study, several manufacturers using MES were
investigated to find out whether the expected benefits were experienced or not. Benefits like
decreasing manufacturing cycle time, less paper work and decreasing lead time was reported
(MESA Int. 1997).
The reported benefits are the same that also Volvo is keen to achieve. Work has been ongoing
for some time, but there are still obstacles to overcome to roll out MES systems on a wider basis
in the Volvo Group. There is a need to visualize and demonstrate MES concepts, both within
factory management, but also between management and workforce.
1.1.1 Volvo Technology Corporation
Volvo group is one of the world’s leading suppliers of commercial transport solutions. Volvo
group was established in 1927. Volvo group’s corporate values are quality, safety and
environmental care. The business areas within Volvo group are Volvo Trucks, Renault Trucks,
MAC Trucks, UD Trucks, Volvo Buses, Construction Equipment, Volvo Penta, Volvo Aero and
Volvo Financial Services.
The master thesis is carried out at Volvo Technology in Göteborg. Volvo Technology is an
independent business unit within the Volvo group. Volvo Technology, established in 1969 and
business unit in 1997, is an innovation company that supplies all business units within the
Volvo trademark with new technology. Volvo Technology has approximately 500 employees in
Sweden, France, North America and Asia with a turnover of € 50 million per year.
This master thesis project is a part of an ongoing project at Volvo Technology in collaboration
with Volvo IT, with LEGO group as supplier.
1.2 Purpose
MES tools are complex to understand and visualize. Getting managers attention is difficult,
partly because of the complexity, and partly because the large investments needed. In addition,
there is a priority of having a plant working correctly, which is not an easy job, by itself and
disturbing production with new systems is seen reluctantly.
The purpose for Volvo Technology, running this project, is to increase the knowledge about
MES among factory managers and make them understand all benefits around MES, increasing
the usage of such systems.
1
Introduction
1.3 Objective
To achieve the purpose, Volvo Technology, in collaboration with the thesis workers, want to
develop an MES demonstrator platform that is capable of demonstrating important production
features and strategies, by integrating professional MES tools.
Volvo IT has developed an MES software family, which includes a system called MONT.
MONT is an assembly control system which connects several underlying systems directly to the
production chain.
The ultimate goal is that every factory in the Volvo group has a copy of the demonstrator.
It is, therefore, the aim of the thesis project to design and build such demonstrator for the
industrial project, as a diploma work of the master studies. The key innovation points with the
demonstrator are:
•
•
•
•
Integration of a professional grade MES (MONT) with low cost, and flexible LEGO
components where LEGO is seen not as a toy, but as an industrial material.
That the demonstrator and how it is handled is realistic, and that the models used are
realistic in terms of how they look and work
Low cost, so that is within factory budget for demonstration and educational tools.
Flexible, so that it can be adapted to any factory layout and specifications.
1.4 Scope
The thesis project, hereafter referred to as the project, is carried out between January 2011 and
June 2011 at Volvo Technology in Göteborg. The demonstrator will be developed within the
scope of the industrial project. The project will be carried out through literature studies,
workshops together with Volvo IT and Volvo Technology.
1.5 Project phases
To sum up, the project is developed in five phases:
•
•
•
•
•
Phase 1 – Demonstrator concept development
Phase 2 – Product development
Phase 3 – Transporter layer development
Phase 4 – Building and integration
Phase 5 – Testing at Volvo group Tech Show 2011
2
Introduction
1.6 Limitations
Regarding software, the project is limited to only develop the software for transporter units and
communication between transporter units and MONT. The MES system is developed and
modified by Volvo IT to suit the demonstrator, since the demonstrator will not be connected to
the underlying systems that are normally used.
•
•
•
•
•
•
The demonstrator itself will not be a full scale model of a real productions site, but
suitable assembling procedures and stations will be adapted in small scale.
The project is limited in time since the prototype should be presented during Volvo
Group Tech show in May 2011.
The project is limited to only use LEGO MINDSTORMS servos, sensors and
microcontrollers, instead of using customized circuit boards and electronics, making it
easy to duplicate in the future.
The production system will be tested by Volvo IT, and the production system together
with the transporter units will be tested as a complete package within the thesis work.
A short-term testing and evaluation will be carried out during Volvo group Tech Show.
The thesis workers will be present to help running everything in good technical
conditions, but, due to the complexity and time constraints, they are not responsible for
the conceptual evaluation itself.
Tasks to fulfill the goal for Volvo Technology, like long-term testing and duplication of
the demonstrator, fall out from the scope of this project.
1.7 Environmental aspects
The environmental aspects could be divided into two parts: environmental effects and working
environment. The demonstrator will show that MES have impact on the environment since
research shows that implementation of MES reduces paper usage (MESA, 1997).
Implementation will also have effect on working environment, as the platform will use screens
and computers within the ergonomic zones at the assembling stations. Also the fact that the
scope of the demonstrator is to show that assembling errors can be eliminated with adapted
instructions and supporting pictures, will lead to a better psychological working environment
due to the constructive feedback that is given to the assembly worker. (Braksick 2007)
3
Introduction
4
Theory
2 Theory
In this chapter the background research about MES will be presented to support the material
explored in the report.
2.1 Manufacturing Execution Systems
The MES concept is derived from previous data collection systems used in production planning
and quality assurance. Such systems were in the beginning isolated from each other. Since the
higher integration of Information Technology, data collection has started to be used more
between previous isolated systems. The major reason is that different processes today are seen
as dependent and not independent as before. The MES concept was born since several
specialized systems were developed in the early 1990s. MES is interacting with several different
systems and an example is shown in Figure 2-1. (Kletti 2007)
Figure 2-1 MES integration concept
Systems with high integration factor and unified integration technology are closely related to
MES. If the systems also include management, quality assurance and analysis, they start
becoming MES. A quotation from the book of Dr. Jürgen Kletti states that
“A product will not be created in the most economically efficient manner unless
the right resources are available in the right quantity at the right place at the right
time with the right quality and with the right costs throughout the entire business
process.” (Kletti 2007, p. 16).
Important to mention is that in MES, production deviations and errors can be addressed in real
time. Old production systems were not capable of doing this, and therefore there were no
possibilities to create a good production control system. (Kletti 2007)
5
Theory
MESA has performed much research about MES and divides their concept into different groups;
Strategic initiatives, Business operations and Manufacturing/Production Operations which
include
Strategic initiatives
•
•
•
•
•
Lean manufacturing
Quality and regulatory compliance
Product lifecycle Management
Real time enterprise
Asset performance management
Business operations
•
•
•
•
•
•
Customer focused
Financial and performance focused
Product focused
Compliance focused
Supply focused
Asset reliability focused
Manufacturing/Production operations
•
•
•
•
•
•
•
•
•
•
Product tracking and genealogy
Resource allocation and status
Performance analysis
Process management
Data collection acquisition
Quality management
Labor management
Dispatching production units
Logistics focused
Control
(MESA Int. 2008)
6
Theory
2.2 Lean manufacturing
As seen in the previous section, lean manufacturing is one of the strategic initiatives from the
MESA derived MES model. The well known lean concept was developed by Toyota as Toyota
Production System, TPS. The wisdom from TPS is doing more with less. Lean includes
important categories as Just-in-Time (JIT) and jidoka. (Dennis 2007). Features within jidoka as
andon and poka-yoke will be described in the following sections.
2.2.1 Poka-yoke
The word poka-yoke in English means error prevention. Poka-yoke detects when an undesirable
situation occurs and may stop production to prevent defects. The purpose of poka-yoke is to
remove the burden from an assembler worker to try to detect common errors. Such errors may
be missing process steps, process errors, miss-set work pieces, missing parts and wrong parts
just to mention a few. Requirements for a good poka-yoke structure should include low cost,
high reliability, simple, long life time and low maintenance needs. (Dennis 2007)
There are different ways of implementing and using poka-yoke. Three different categories are
used to categorize poka-yoke methods: Work piece deviations, work method deviations and
deviations from fixed values. In work piece deviations, for instance, a processed unit can be
weighed and measured according to a standard. In work method deviations, sensors can be used
to detect when the worker is reaching for a part. If the sensing count mismatch, material must be
missing. Deviations from fixed values can be simply verified by counting the number of spot
welds done on a work piece. (Dennis 2007)
Poka-yoke can be implemented in many different ways, using sensors or just having a failsafe
physical design according to assembling procedures. It is just the imagination that puts the limit
on how to implement failsafe procedures and methods in production.
2.2.2 Andon
Andon is a way of highlighting a production station that has a problem, by displaying lights,
sometimes combined with sound. Four different colors are used to visualize the status; blue,
green yellow and red. (Zidel 2006) Green light is to show normal operation and red light is to
show error in production that may lead to a stop in production. Figure 2-2 shows an example of
an andon screen.
The benefit of using andon is that the operator has real time status of his or her job performance,
and easily alerts if something disturbs production. (Middleton & Sutton 2005)
Figure 2-2 An andon screen showing a station with problems and another station warning for
deviation in normal production
7
Theory
2.2.3 Ergonomics
The major reason to connect ergonomics to lean is to ensure product quality to the customer. If
manufacturing ergonomics is lacking, then the operator cannot fulfill his or her procedures to
deliver the end product ordered by the customer. Quality, productivity, safety health and
motivation are the purposes of ergonomics. There are several features addressed directly by lean
production. The productivity can be increased by introducing lean features, basically by
removing activities that do not add any value to the production nor to the product itself. Using
automatic or manual station is a choice that may affect ergonomics. Safety is an important
factor within ergonomics. Work need to be structured to decrease the risk of injuries such as
slipping, falling, but also causing damage to the product or tools. Handling a tool wrong or
lifting material wrongly can lead to muscular or stress related injuries. (Charlton & O’Brien
2002)
2.2.4 Line balancing
Basic knowledge in line balancing is that, in the perfect world, all stations are equally time
balanced, but if they are not, the maximum output of a production line is based on the slowest
operation, the so called bottleneck. This means that all other stations are in standby during the
bottleneck time, not fulfilling the lean concept because non value adding operations are not
removed. The focus is to balance the workload evenly over the production line, parallel to
decreasing labor to its minimum. Balancing a production line is complex, and several
constraints need to be fulfilled. The most important information for balancing a production line
is:
•
•
Sum of task times, leading to the maximum cycle time
Length of the longest task, leading to the minimum cycle time
(Shim & Siegel 1999)
2.3 Volvo systems
In order to give the reader a better understanding of the relation between the professional tools
chosen in the demonstrator and the MES general concepts, a brief description of the Volvo
systems involved is presented.
Volvo IT has been responsible along the years to develop most of the systems related to MES
concepts taking place in some Volvo factories. Two main systems used are MONT and DUGA.
1) MONT is a set of tools used to manage the manufacturing systems. MONT is a software
product, developed by Volvo IT to control automated and semi-automated production lines. It is
part of the Volvo IT MES securing the assembly process by controlling the shop floor
equipment and guiding operators in every step of the assembly.
To assure the assembly process, there is a software application connected to MONT that is seen
as an assembly assurance system (called from now on AAS). It secures the assembly in each
working station, raising the attention about every assembly detail by means of on-screen
instructions. A screen shows the right sequence with the right instructions for the truck being
assembled. It replaces paper instructions, handles several product variants and still allows the
user to give feedback about the instructions performed. Moreover, it is capable of reporting a
rejection, when serious problems occur. Images are provided in each instruction if necessary.
Naturally, every data inserted should be planned in advance. There is also a takt time line in the
AAS of each station, showing the status of the station, relative to the cycle-time assigned to it.
Volvo IT has also andon principles implemented. A screen with the information presented in
2.2.2 is placed in every line of Volvo production sites that include MES.
8
Theory
2) DUGA is a real-time supervisory system, allowing doing analysis of data related with the
working progress in each station. It also records data about machine maintenance and alerts for
problems.
2.3.1 Manual versus automatic stations
Volvo IT systems distinguish between two kinds of stations, automatic and manual. For the
implementation it is important to clarify the difference between them, since they include
different approaches in what concerns communication protocols and necessary hardware.
1) Automatic stations are stations in which MONT communicates directly with the
programmable logic controllers (hereinafter, PLC). PLCs execute the operation and return the
results directly to MONT. The information retrieved is little and objective, not leaving room for
extended reports or mechanical losses reports.
Asking PLCs to perform an operation does not necessarily mean that the station is fully
automated. A typical example is scanning devices. Assembly workers use scanning devices to
get the identification of the products and report them to MONT through a PLC.
Wrong execution of instructions is not possible in automatic stations, since the operation will
only be concluded after achieving the expected results, within the tolerance parameters. A good
example is the use of a nut runner. Behind a nut runner there is a PLC expecting it to tighten
some amount of nuts with specific torques. In this case, torques, tolerances, kind and amount of
nuts are arguments sent by MONT.
Automatic
Manual
MONT
AAS
PLC
PLC
Figure 2-3 Automatic and manual stations communication scheme
On the other hand, 2) manual stations include an AAS application, which provides detailed
information and a list of instructions to the operative, about the instructions to be performed in
that station. In turn, AAS communicates with PLCs, asking them to run the desired tasks. The
operative has to acknowledge each instruction either through device automatic response or by
pressing a key. Sometimes, all individual instructions in AAS fulfill the requirements to be
implemented as automatic stations, but it is convenient to place them in a unique sequence,
through an AAS interface. Figure 2-3 shows the communication flow difference between both
types of stations.
9
Theory
10
Requirements for the demonstrator
3 Demonstrator requirements
In this chapter, the requirements for the demonstrator given by Volvo will be analyzed. The
requirements mainly affect how the material will be used, in order to successfully demonstrate
the concepts.
3.1 Decisions influence on requirements
There is a key point around the requirements for this demonstrator, the use of LEGO. In fact,
the decision for LEGO, as the main material to be used, allowed getting a wider range of
requirements, that otherwise, would not be possible to achieve. In this sense, LEGO could be
seen as a requirement. Observe that the decisions feed the requirements, not only the opposite
(Figure 3-1).
Requirements
Decisions
Figure 3-1 Close relation between requirements and decisions taken
3.2 Volvo requirements
3.2.1 Reproducibility
When designing a demonstrator, regardless of the technical objectives, it often integrates a
considerable amount of customized features, specifically made for its own purpose.
Customization results, in most of the cases, in a unique demonstrator, hard to reproduce and to
make available in more than one plant. As such, one of the requirements of the demonstrator in
questions is to be duplicable, giving factory managers the opportunity to acquire it. Keeping this
feature in mind involves an extra care during the development process.
3.2.2 Low cost
Recalling the need for reproducibility, one can expect that low cost of the final result is a major
requirement.
3.2.3 Flexibility
The demonstrator should be flexible, in certain aspects. The layout of the demonstrator should
be adjustable, so that management teams can display it according to their own factory layouts
and specifications. Taking LEGO in advance as the material choice for the demonstrator gives
the opportunity of designing different trucks, according to the preference of every manager.
Also, it needs to be easy to adapt assembly instructions, depending on the product configuration,
number of stations, and distribution of assembly steps on them.
3.2.4 Portability
Sharing the benefits of implementing MES in factories also highlights the importance of
transporting such platform to different factories and interacting in place with the target
11
Requirements for the demonstrator
managers. This feature is a challenge in the sense that a professional platform is usually heavy
and not modular, lacking of flexibility.
3.2.5 Integration with Volvo systems
Due to the wide number of features that MES include and in order to reduce the complexity of
the demonstrator, some of the concepts will not be exposed and not all Volvo Systems will be
used. The choices about which MES concepts to show rely on the pedagogical value added or
not to the end platform, both for highlighting MES importance and training factory assembly
workers.
MONT and DUGA systems are powerful tools to achieve the objectives. MONT will be the
Volvo system used as the core of the demonstrator. As part of the requirements of the
demonstrator, Volvo IT will make sure their systems are adapted to the demonstrator setup
decided by Volvo Technology. The material chosen for the transporter layer needs to be capable
of communicating with MONT, according to the Figure 3-2.
Figure 3-2 Typical handshake between MONT and the transporter layer
3.3 MES concepts requirements
3.3.1 Poka-yoke
As mentioned earlier there are different work methods of implementing poka-yoke in
production. Industrialized methods for poka-yoke could be several sensors integrated in the
production infrastructure, for instance to detect volume of work elements, standardized weight
measures and many more. One of the requirements for the demonstrator is to show this feature
in the production. The difficultness of using such sensors depends on what kind of controllers to
use for the demonstrator.
A concept used by large scale production companies as Volvo, is pick-to-light. In this working
strategy, the right material is highlighted with a strong lit light together with a screen stating the
quantity of the part. The operator confirms the material taken by pushing a button next to the
screen. In this way, the right quantity and the right part are taken for the right order. To ensure
part assurance, pick-to-light is suited to use in a kitting station in the demonstrator, being
delivered to the main line as a kit, and not as sequence driven material. Sequence driven
material means that the material belongs to a certain order, and no other (e.g. the cab and the
engine). Therefore, sequence driven material should be delivered to the assembly line when
needed in a so called sub flow. The kit may consist of, for instance, a set of different cables and
belongs to a certain order. Kitting is a complex problem to solve due to, for example, the lack of
space in the assembly line to store the parts. To remove non value adding operations in
production, the assembly worker should have his/her material in a short distance. In a
production line with small series and unique products, this becomes a problem. For the
demonstrator kitting will be used, but not sequence driven material.
12
Requirements for the demonstrator
3.3.2 Testing
One feature that is very important for production plants is testing the product. The testing is
divided into component test and system test. For the demonstrator, component test is not shown,
since no suitable test and test tool was found that could be referred to a real production site.
Instead, the system test (integration of several parts) is a requirement to have a method of
showing the result of the previous assembly steps and try to prove an actual reduced amount of
mistakes, or even none, by using MES features.
3.3.3 Other concept features
Andon is a very useful tool in MES. Andon gives feedback to the assembly worker, but also to
the production manager and production planning team. Andon shows real time status and all
data can be collected since the system is implemented in MES. Andon is also one of the
requirements for the demonstrator, to state the importance of always reporting the status of the
work in progress.
In the concept of MES, feedback is a requirement. DUGA system, as mentioned before, is a real
time system that collects and stores data from production. It can show the production output,
address problems to certain operations and also collect equipment data. For the demonstrator
DUGA is used to be able to see the progress in the production line, and the result after ending
the shifts.
For the demonstrator the order assurance is required to be visualized, showing that MONT will
always know which carrier has which order and where it is at each moment.
The ergonomics will not be shown more than having the demonstrator platform in a comfortable
height and computers on adjustable linked arms. One of the most important requirements is that
the professional AAS client will be used with unique instructions for each variant of the
product. An AAS client will be placed in each assembly station and in the testing station. Since
the kitting station is outside of MONT, it will not be connected with a computer.
3.4 LEGO as a tool
After getting to know all the constraints of the demonstrator, from section 3.2 and 3.3, LEGO
system becomes an extremely fair solution, especially regarding the equipment requirements. It
was actually one of the key points that made it possible to go ahead with the project.
LEGO parts are cheap, when compared to any other customized professional solution. Parts can
be used and reused, providing them a longer life span. If a mistake occurs in the development
process, that built piece does not need to be thrown away, wasting part of the budget. This is not
just an economical advantage, but also an ecological aspect (Ferrari, Ferrari & Hempel 2002).
LEGO pieces are light, facilitating the transport of the demonstrator.
LEGO Digital Designer is an official LEGO CAD tool of free use that allows building 3D
LEGO models and getting the proper instructions. This fulfils the reproducibility requirement
and makes it easier to save documentation about the project implementation.
LEGO MINDSTORMS platform includes a powerful set of electronic and robotics related
components, which ensure the capability of simulating PLCs and any other robotics equipment
present in a real factory. It also allows the integration with the Volvo systems.
Specifications about LEGO MINDSTORMS components and a brief introduction to LEGO
Digital Designer software will be presented in the next sections.
13
Requirements for the demonstrator
3.4.1 LEGO MINDSTORMS specifications
3.4.1.1
Hardware components
The current family of LEGO MINDSTORMS devices is called NXT. It includes a
microcontroller unit, rechargeable batteries, sensors and actuators.
Figure 3-3 NXT programmable brick
The NXT programmable brick (Figure 3-3) is a microcontroller equipped with input/output
interfaces and other important features such as (The LEGO Group [TLG] 2006):
•
•
•
•
•
•
•
•
Main processor: Atmel® 32-bit ARM® processor, AT91SAM7S256
o 256 KB Flash
o 64 KB RAM
o 48MHz
Co-processor: Atmel® 8-bit AVR processor, ATmega48
Bluetooth wireless communication: CSR BlueCore™ 4 v2.0 +EDR System
USB 2.0 Full speed communication
4 input ports: 6-wire interface, supporting both digital and analog interface
1 high speed port, IEC 61158 Type 4/EN 50170 compliant
3 output ports: 6-wire interface supporting input from encoders
Power source: 6AA batteries or rechargeable Lithium-Polymer battery with 2200mAh
Figure 3-4 LEGO MINDSTORMS electronic components; from left to right: NXT servo, color
sensor, ultrasonic sensor and touch sensor
The output ports of the NXT give the possibility of plugging several different LEGO motors.
However, they were specially developed to attach the NXT servo motors (Figure 3-4, on the
left). The NXT servo differs from regular motors because it includes a built-in optical encoder
that keeps count of rotations of the motor shaft. This encoder is accurate up to 1 degree.
(Astolfo, Ferrari & Ferrari 2007) The NXT servo also includes a gear reduction of 1/48,
decreasing velocity and increasing torque in the output hub.
14
Requirements for the demonstrator
Besides no official information, measurements have been done to date. Hurbain has performed a
substantial amount of measurements and comparisons and published them in his website:
http://www.philohome.com. From there it is possible to fetch the following characteristics,
under 9V of power supply:
•
•
•
Weight (grams): 80
No-load rotation speed(rpm)/current(mA): 170/60
Stalled torque(N·cm)/current(mA): 50/2000
Regarding sensors, LEGO currently manufactures touch, color and ultrasonic sensors (Figure 34, the three devices on the right). The touch and color sensor are analog sensors, being 333MHz
the sample rate for the touch sensor and around 1KH for the color sensor. The ultrasonic sensor
is a digital sensor, using the I2C interface. I2C is known as a low-speed interface, providing the
digital sensors a maximum sample rate of about 80Hz.
The touch sensor is just an on/off sensor, not distinguishing levels of pressure.
The color sensor distinguishes between 6 different colors: black, white, red, green, blue and
yellow. To achieve the result, the sensor includes a tri-color LED, sensing the red, green and
blue reflection, one at a time. Based on all reflections, the firmware calculates the color. It is
also possible to access each component value. This makes it possible to use the color sensor as a
simple light sensor, inferring about light intensity, in a monochromatic scale.
The ultrasonic sensor measures distances between 4 and 255cm. Among other options, the
internal chip allows setting the measurement mode, to single-shot or continuous measurements
(TLG 2006).
Besides the LEGO official sensors, there are several companies that manufacture add-on
sensors. Among all, Codatex and HiTechnic products are certified by LEGO. Considering
robustness and support, preference is given to these two over the others, in case extra sensors
are needed.
3.4.1.2
Programming tools
There are several programming languages available, including not only the official NXT-G by
LEGO, but some other developed within the fan community. NXT-G is a graphical
programming environment, powered by LabVIEW, from National Instruments. Due to its
limitations, slow program execution and heavy executable files, there was a need to search for
alternatives (Astolfo, Ferrari, & Ferrari 2007).
Not eXactly C (hereafter, NXC) (Hansen 2007) is a suitable programming language for the
demonstrator needs. It is a script language and does not require any license. It uses the standard
firmware, saving warranty about low-level operations. It is widely used among NXT hobbyists,
providing a frequent on-line support, which became a helpful characteristic.
Bricx Command Center (hereafter, BricxCC) is a Windows program commonly known as an
integrated development environment (IDE) for programming the NXT brick, mainly intended to
develop NXC programs. It was the IDE program chosen for the code implementations in the
project.
3.4.1.3
Interfacing between host computers and the NXT brick
LEGO provides an SDK to interface with the NXT drivers, called Fantom drivers. Part of the
SDK consists of a C++ API, which can be used in user applications to interact with the NXT
brick.
15
Requirements for the demonstrator
From the complete list of functionalities, here are some highlights:
•
•
•
•
•
•
Connect to the NXT over either Bluetooth or USB (all the remaining API works
properly, regardless of the bus communication chosen);
Download a firmware into the NXT;
Get a list of all files in the file system and download or upload files;
Read/Write from/to firmware IOMap modules;
Send direct commands, according to the LEGO communication protocol (TLG 2006);
o Note 1: This is a very powerful tool to request sensor values and act on the
motors, controlling the NXT without any embedded program running.
o Note 2: There are commands that deal with a mailbox system that the standard
LEGO firmware provides.
Read and write raw data directly on the bus communication buffer.
Two ways are available to exchange messages between Volvo systems and the NXT platform,
through direct raw data in the buses or using the mailbox system, whose protocol was written by
LEGO. The discussion and decision about communication implementation details will be taken
in section 4.5.1.
3.4.2 LEGO Digital Designer
LDD is the official CAD software developed by LEGO targeting virtual building. The strongest
points about the usage of this software are the fast building and adjustments and planning before
ordering the parts.
What makes LDD special compared to other freeware programs related with LEGO 3D
modeling is the connectivity feature. Currently, it is the only program available that only allows
placing the parts where they can actually fit in reality. Moreover, the program inherits the
building quality standards by LEGO, preventing from placing parts under stress conditions.
If experienced enough using the program, one can virtually build much faster than with the
proper bricks. It happens frequently the need of changing a small amount of pieces inside a
complex structure already built. Instead, virtual building makes it immediate to solve.
The virtual building concept also gives the opportunity of advancing the development process
with zero-cost, regarding material. Otherwise, because it is hard to guess which pieces are
needed, there is an early and high investment buying material that may not be needed.
As already mentioned as well, the generation of building instructions is a great tool for future
reproducibility of the demonstrator.
Not everything is positive. There is a disadvantage when it comes to physics applied to the
models. LDD does not take into account forces, rotations, elasticity or any electronics
simulation. Thus, it is not possible to simulate mechanical features. Due to this limitation, there
is a mixture of LDD usage and real building along the development process of the demonstrator.
16
Implementation
4 Implementation
In the present chapter, solutions taken are analyzed and explained. Firstly, the overall setup of
the platform is studied, including the layout and where each concept is demonstrated. In a
second phase, the product design is described. In the last part of the chapter, it will be
explained how the transporter layer was developed to handle the communication with MONT
and the product transportation.
4.1 Demonstrator setup
As mentioned in the introduction the demonstrator will not be a complete production line in a
small scale, but instead important and interesting production stations have been adapted and
shown in the demonstrator.
Recalling the difference between automatic and manual stations described in 2.3.1, a decision
had to be taken on which kind to use in the platform. The demonstrator was developed to use
manual stations without automatic feedback operations. The reason is that the demonstrator is
limited to use certain hardware, and all operations performed in the demonstrator shall have an
accurate relation to the real factory. Using manual stations with the AAS screen gives the
benefit of showing important features in modern production systems such as andon and
rejection functionality.
KITTING
Figure 4-1 The demonstrator layout showing stations and carriers
The production line in the demonstrator will be divided into three assembly station, one kitting
station and one testing station. All station excluding the kitting station will be controlled by the
MES control system MONT. The layout of the demonstrator is shown in Figure 4-1.
17
Implementation
4.1.1 ML010
ML010 is the first station in the demonstrator. ML stands for Main Line.
Since MONT works as a state machine, it reacts on events. Therefore the production needs to be
started outside of the system, the so called “kick start”. In a truck factory, the execution order
identification is carried by the frame. It is the frame that steers that certain order through
production. The frame needs to be married to a carrier that belongs to the transporter layer,
since it is the transporter layer that communicates with the production system, which in turn
needs to know the execution order ID to be started. The benefit of this is that from the
production system’s real time overview, each carrier can be reviewed to see if it is empty, and if
not which order it is carrying. When the carrier is married to a frame and has arrived to a certain
communication point, it sends its identification and the order it is carrying. MONT will send an
assembly instruction to the AAS client that will display it for the assembly worker on the
screen.
At this station the assembly worker will first connect the frame execution order ID to the carrier,
and after receiving assembling instructions, attach the wheel axles to the frame. The assembly
worker ensures part assurance by scanning barcodes on the axle modules with a barcode scanner
connected to the AAS client. When the assembly worker confirms that all assembly instructions
are performed, AAS sends result to MONT, which in turn sends a new request of transportation
to the carrier.
4.1.2 KIT
The kitting station as mentioned before, is not a MONT controlled station, it is stand alone. The
station is activated in parallel with ML010. The idea is that the kit assembled on this station
should be delivered to ML020 at the same time slot as the carrier arrives to that station. This
means that the kit is unique for each product variant.
In the kitting station the assembly worker will collect certain parts from a warehouse using the
pick-to-light feature described in section 3.2.2. Then the assembly worker will pre-assemble the
kit and deliver it to station ML020. The kitting station is activated as soon as a new carrier is
released from the queue to enter ML010.
4.1.3 ML020
At ML020 the engine, fuel tank, kit and side covers will be attached. For tractors the fifth wheel
will be attached in the end. All assembly work is performed according to the assembling
instructions on the screen. All instructions are unique and belong to a certain order, which
shows the importance of having good preparation procedures. Also at this station, the assembly
worker needs to ensure part assurance using a barcode scanner to scan all barcodes, but not the
kit, since it is already part assured. The assembly worker confirms that all assembly instructions
are performed, and the carrier leaves the station.
4.1.4 ML030
In station ML030 wheels and the cab are attached. Normally the cab is sequence driven, but due
to limitations in maintenance of the demonstrator, they were chosen to be used as normal parts
combined with part assurance. The procedure is the same as described for ML020. The
assembly worker confirms that all assembly instructions are performed and the carrier leaves the
station.
4.1.5 ML040
ML040 is the testing station. At this station the assembly worker will perform some system tests
to the product. Tests that will be performed are: driveline mechanics, cab tilting functionality
for the cab, check the symmetries of the wheels and look after scratches in the surface on the
18
Implementation
cab. The assembly worker confirms that all tests are performed, and the carrier exits the station.
It goes back to the queue of carriers and the truck is delivered to the customer. At this step,
when the last procedure is performed and no errors occurred during production, the system
releases the execution order identification from the carrier, which means that the carrier now
can be reused.
4.1.6 Mapping concepts to stations
The demonstrator is showing several important features that may increase efficiency, quality
and decrease cost for production. In those stations described in previous sections several
features are simulated as
•
•
•
•
•
•
•
•
•
•
AAS
Andon
Green zone
Kitting
Part assurance
Pick-to-light
Poka-yoke
Rejection functionality
Testing
Variant handling
The three assembly stations, (ML010-ML030), demonstrate the concept of poka-yoke, andon,
rejection functionality, AAS, part assurance, variant handling and green zone. All features
except green zone, kitting and pick-to-light are implemented or supported in the AAS
application of each station. In the product design described in the following section, Poke-Yoke
has been one requirement, to remove error prone assembling. Barcode scanners are used to
ensure part assurance. In ML020 kitted material is used. In the kitting station the pick-to-light
feature is used. All stations are covered by the green zone concept. The tables for the
demonstrator are in an ergonomically comfortable height. Computers are placed on adjustable
linked arms. The demonstrator itself is capable of handling different truck variants and does not
need to be adjusted before starting production. Since material is put in boxes at the production
line, the concept of Just-in-Time is not demonstrated since the boxes work as buffers of
material.
4.2 Product design
In the present section, the development and all the inner details about the product to be
assembled in the line will be explored. A top-down approach is taken, starting from showing the
final product design and going to the deeper details, justifying their conception.
Firstly, the modular concept will be addressed, followed by the variant handling. These are
considered the most important requirements to fit the demonstrator purposes. Although, having
room for functional features built in the trucks will be also an important improvement for testing
simulation purposes, keeping consistence to reality as much as possible.
19
Implementation
4.2.1 Consistence with reality
Figure 4-2 Overall design of a tractor truck variant, in CAD format
Figure 4-2 shows the final design of a complete and assembled truck, in CAD format. Although
there were different variants developed, the overall aspect is similar. The cab takes the most
important role in the final design, which is equal in every variant, apart from the color. Variant
handling will be discussed later in this chapter.
Besides not making any difference in the functional aspects of the demonstrator, it turned out to
be one of the key points of the product, to look realistic, because of the inevitable connection
with the Volvo Group. Some general designing guidelines about Volvo products were taken into
consideration when designing the cab, accessories positioning, axle’s clearance and overall
proportions.
4.2.2 Modular concept
For the modular concept, the product needs to show the following characteristics:
•
•
•
•
Part assurance
Placement assurance
Mounting assurance
Similarity with real assembly
Below, Figure 4-3 shows all modules developed for the variant presented in Figure 4-2. Next
sections will describe how each characteristic was achieved and how they affected the design,
providing some examples.
20
Implementation
Figure 4-3 Tractor truck dismantled with all modules in perspective
4.2.2.1
Part assurance
As discussed before, each module needs to be identified before assembling. That identification
is going to be performed through a barcode in each part. The frame identification is an
exception, needing an external identification method, not connected to MONT, but with the
carrier. The carrier in turn tells MONT its own ID and the frame ID it is carrying. Because of
that, a color combination will be placed in each frame in order to be scanned and matched with
a unique order number. That scanning will be performed with two LEGO color sensors.
The kit pre-assembled was designed with no barcode. This was decided due to incoherence in
the concepts shown. In one hand, someone will pre-assemble the accessories, simulating the fact
that each kit is different from each other and that the kit depends on the current order released.
On the other hand, barcode stickers have to be applied in advance by the administration, all with
the same identification. It would become clear for the worker in the kit area that the parts
picked, already had a barcode.
Unlike in reality, the space available to place the barcodes is not extensive in each of the
modules that had to be designed, especially due the lack of flat space. Almost every LEGO
Technic piece has one or more holes. Examples of tricky modules to find place for the barcode
were the axles, needing extra parts just for that purpose. These extra parts turned out to be
useful to ensure a right placement of them, as discussed in the next section.
The frame design also had to be sacrificed in order to get the two-color identification. The size
of the color identification has to be bigger than a regular barcode, due to the LEGO color sensor
physical configuration that will sense the ID. The ID had to be place in the down side,
decreasing the visual impact on the final assembly result of the truck. Figure 4-4 shows the
effect of these constraints in the model.
21
Implementation
Figure 4-4 Bottom view of a tractor truck; all barcodes referenced, except for the engine which
is not visible
4.2.2.2
Placement assurance
Assuring the right placement of each module required careful thinking from the beginning of
the design process, removing every possibility of mistakes. It was seen as a major requirement
of the demonstrator to have as many secure features as possible. That is here where poka-yoke
concept is shown the most.
Two main ways of achieving poka-yoke were physical configuration of the modules and color
matching.
There was a priority in making each module in such way that one can only place it in one single
position, through the physical configuration. This was well achieved in case like the engine,
steering axle, fifth wheel and fuel tank, as exposed in the Figure 4-5. However, if analyzed
correctly, one can see that the fuel tank and fifth wheel can actually be placed in the wrong
orientation. But in truth, the fifth wheel becomes angled incorrectly and the fuel tank becomes
misaligned with the frame.
Figure 4-5 Attachment designs based on poka-yoke concept
22
Implementation
Color marks were added to the frame in order to instruct the worker where to attach the side
covers. The use of LEGO Technic bricks in the frame gave it the real impression about the high
amount of holes drilled, normally. On the other hand, no more suitable solution was found
better than using color marks to identify the right holes to use. Locking every hole with pins
was not physically possible, unless it was decided to cut some pieces. The same approach was
taken to facilitate the placement of the fuel tank and the accessory place, like shown in the
Figure 4-6.
Figure 4-6 Improved visual support for attachments by using white color marks
4.2.2.3
Mounting assurance
The LEGO system, namely the connectivity concept of LEGO Technic models, came in handy.
LEGO does not require glue, screws or any special tool to assemble or dismantle, but only the
hands to press plastic bushes. In some cases, red bushes were added for easy visual recognition
of which parts should be used to attach each module to each other. Examples of this are the
engine and the axles, as can be seen in the Figure 4-3.
In addiction to an easy visualization of the pieces to attach the modules, it is very important to
provide a high structural robustness to all truck components, avoiding taking apart any of them.
The main reasons to put extra efforts on a robust solution are the following:
•
•
•
Any damaged module is not supposed to be considered intentional material defect, as
the demonstrator is not intended to raise material quality issues;
One of the aim of the project is to prove that LEGO is a powerful and robust tool to its
extent, minimizing the demonstrator maintenance;
The potential users of the demonstrator can get quickly frustrated and possibly
embarrassed when taking apart a module.
In most of the modules developed, it was possible to get a robust construction, with more or less
building time. For instance, the driving axle was firstly developed with weak axles that came
out from the module very easily when taking the wheels from it. As far as possible, all
weaknesses were solved by building extra techniques. Some were not solved so easily, forcing
the use of glue in strategic places.
4.2.2.4
Similarities with real parts and assembly process
The building process ensured that every module developed exists in reality and is assembled in
the right order. Unfortunately, the size of the demonstrator and the product forced to drop a lot
of components that are assembled in reality. One of the biggest misses is the gearbox, which
was not managed to be built in a reasonable scale and fit together with the engine, under the
cab.
There is actually a combination of parts preassembled that do not comply with the reality. It is
the case of the frame together with the rear lights. In reality, in most of the cases, they are
23
Implementation
placed on top of the mudguards. For the sake of reducing modules and keep a nice design, it
was decided not to change, like it can be seen in Figure 4-3.
4.2.3 Variant handling
When planning the range of variants able to assemble, two principles were followed. The
former was to keep the same line balancing in terms of assembly time in each station, so that the
production does not show bottlenecks and each user benefits from the same amount of assembly
experience. The latter was to minimize the workload of developing new modules, trying to work
around the same set of modules, differently combined. The drawback is that each module had to
be designed in a flexible fashion to serve multi variants.
Before going further, a question is raised. In theory, how many variants can be made?
In fact, there is a limit, concerning the frame identification method. Recalling the LEGO color
sensor characteristics (from section 3.3.1.1), there are only six recognizable colors. A
combination of 2 colors defines the limit of 36 variants.
4.2.3.1
Frame lengths
The first idea that came to mind was having the possibility of assembling trucks with different
frame lengths. Hence, two frame lengths were designed, one suitable for tractors and another
suitable for rigid trucks, as shown in the Figure 4-7a) and 4-7b).
4.2.3.2
Axles configuration
There were designed three different kinds of axles, including a single steering axle and two
different rear axles, one with a driving differential and double wheels attachment and another
for supporting purposes, with no differential.
The tractor frame was designed with one single rear axle slot and the rigid frame with two.
After analyzing the real possible configurations in the market, the configurations chosen were
the ones in the Figure 4-7.
Figure 4-7 a) Tractor frame with axle configuration 4x2; b) Rigid frames with axle
configurations 6x2, 6x2 alternated and 6x4 (left to right)
The capability of attaching different axle types in the same slot has lead to a standard way of
attaching both kinds of axles. The disadvantage is that the user of the demonstrator is able to
place them in wrong slots, which does not comply with the poka-yoke concept.
24
Implementation
4.2.3.3
Fuel tank and accessory plate positioning
An easy way of increasing the number of variants was getting different positions for the same
items. Thus, it was decided to include two positions for both fuel tank and accessory plate. They
can be placed either on the right or on the left side (Figure 4-8a)). In this case, the poka-yoke
concept was dropped, giving the user the possibility of placing them wrongly.
4.2.3.4
Truck colors
So far, there are four axle’s configurations (including tractor and rigid options) and two
positioning options for the fuel tank and accessory plate, making a total of eight different
variants. By having different colors, one can increase considerably the amount of variants. It
was decided that 16 variants would be enough to show the variant handling feature of the
demonstrator. Therefore, two colors were chosen for the cab and side cover modules, red and
yellow (Figure 4-8b)). The limitation of the LEGO pieces currently in production also played
some role in this decision.
Figure 4-8 a) Fuel tank and accessories plate different positioning; b) Two possible color
variants
The complete reference catalog of the modules and the variant matrix can be seen in Appendix
A and B, respectively.
4.2.4 Functional features
There was still room for functional features, as a result of the combination of several modules.
The features presented next are requested to be tested by the user, on ML040.
4.2.4.1
Moving pistons
The engine, frame and the driving axle were designed in such a way that once combined, they
work together, moving the pistons when the truck is rolled back and forth. The key point of this
feature is that one does not need to insert extra pieces to join gears or any other mechanism. Just
by placing them together, by pressing the red bushes, everything gets working. Figure 4-9
highlights the moving parts of each module.
25
Implementation
Figure 4-9 Mechanisms for moving pistons are highlighted in green (engine), brown (frame)
and blue (driving axle) colors
4.2.4.2
Working steering
The steering axle allows to actually steer the front wheels. A knob on the top of the cab was
designed to work together with the steering axle, to give the user the chance to try it. This
feature can be analyzed in the Figure 4-10. Notice that the three knobs (green and blue) are
circumventing the driveshaft, in the complete model. The green parts belong to the engine,
adding some structural support.
Figure 4-10 Working steering mechanism; red, green and blue parts belong to cab, engine and
steering, respectively
4.3 Transporter setup
One of the major objectives for the thesis project is to implement the transporter layer. The task
for the transporter layer is to move the product along the production line in the demonstrator,
and be responsible for sending message to the control system (e.g. execution order identification
and arriving to communication point messages). The transporter method and the configuration
26
Implementation
will be described in this section, and the communication and programming will be separately
described in the section 4.5.
4.3.1 Transport method
As a first solution, the old fashioned conveyor belt was the transportation method for the
demonstrator, with sensors at each station identifying new carriers arriving. The benefit of using
conveyor belts is that they can be built and used in blocks, which means that the length can
easily be adapted to space for set up the demonstrator. Though, there are several weaknesses
having a conveyor belt. Depending on what material to use for conveyor belt, it can easily break
down, due to high rate of mechanics involved. The conveyor belt may also increase cost due to
the material used. To make each conveyor belt block independent, more controllers are needed,
to allow buffers. Using takt time in production will allow the conveyor belt just using one
controller.
Another solution that was derived later on in the project was the Automated Guided Vehicle,
AGV. The AGV solution would decrease material cost, and mechanical movement, which
makes the solution more robust and qualified for the demonstrator. The weaknesses with AGVs
are the fact that the power supply will be rechargeable batteries, instead of using a power
adapter like for the conveyor belt system. Using an AGV makes it hard to use standard USB
connection that is easier and more stable to implement for the conveyor belt. One solution that
is possible for the AGV solution is using Bluetooth communication. However, there is a
limitation in the number of possible connected Bluetooth devices to the host computer. Since for
the AGV solution it is not needed to have more than seven Bluetooth devices connected at the
same time (limit of devices connected at the same time with the same Bluetooth dongle device),
this will not be a problem, as long as the connection itself is robust.
The transporter method chosen for the demonstrator is an AGV network. The main reason is
that the conveyor belt solution would cost more in time and material. The conveyor belt solution
would be very noisy due to the mechanical movement and friction. The solution with AGVs is
more related to the factory of tomorrow than the traditional conveyor belt. Earlier mentioned in
this section, the conveyor belt was stated to be flexible for be adapted in length. But, the AGV is
much more flexible since it is easy to adapt the route with a navigation system implemented.
4.3.2 Carrier configuration
The AGV solution for the demonstrator will use the line following principle. This method
relates to the solution used in production plants today, where magnetic tracks with several
communications points are hidden under the floor in the factory. In the demonstrator a black
tape is used to symbolize the track under the floor. The communication points used are color
marks on the black tape. In Figure 4-11 the line following setup is shown.
Figure 4-11 Line following method used to guide the AGV around the production line in the
demonstrator
27
Implementation
To be able to follow the line and detect color marks, a color sensor from the LEGO
MINDSTORMS product family is used. The sensor is directed against the line and follows the
edge of the line. The AGV calibrates first the reading values of the black line and the ground.
During the development process the ground has been white (e.g. white surface tables). Thanks
to the capability of sensing colors at the same time, no extra sensor was needed to perform the
station detections. More details about the programming development can be found in the section
4.5.
The AGV consists of
•
•
•
•
Two interactive servo motors
One ultrasonic sensor
Three color sensors
One NXT intelligent brick
and the material can be seen in Figure 4-12.
The AGV is using the steering method called skid steering, and therefore the servos were placed
in parallel, instead of using one motor for driving and another for steering. The ultrasonic sensor
was placed in the front according to Figure 4-11, to be able to detect obstacles, such as an object
placed in the way and to be able to let the AGV stand in queue and automatically moves
forward when the next AGV starts moving.
One color sensor is placed under the AGV to follow the line and detect the color marks and two
color sensors are placed in the top surface of the AGV directed upwards. This is the frame
scanner. In a real production line, barcodes or RFID tags are used to detect ID. In the
demonstrator case, one of the purposes was to use LEGO original material to facilitate
reproducing the demonstrator.
Figure 4-12 The Hardware used for the AGVs
Thus, standardized products that can be assured to be used in the future were preferred. This
means that the ultimate design would be using a RFID reader. In the configuration of the
prototype presented, two color sensors are used limiting identification to 26 variants (6 different
colors), as already mentioned in the section 4.2.3.
28
Implementation
The design of the AGV can be seen in Figure 4-13 where the frame supports are attached to the
AGV’s top surface.
Figure 4-13 The AGV design
The power supplies for the NXTs are Lithium Ion Polymer batteries shown in Figure 4-14. With
these batteries the NXTs can be direct driven via power network adapter, but also in battery
mode. The batteries are easily recharged via the chargers supplied by LEGO. The disadvantage
of using these batteries is the cost. The batteries are expensive, but due to the fact that the
prototype demonstrator should sustain robustness, the cost was not an issue, considering that the
lifetime of these batteries is longer than ordinary alkaline 1.5V or rechargeable 1.2V batteries.
Figure 4-14 Lithium Ion Polymer battery supplied from LEGO with 2100 mAh
4.4 Kitting and gate
As mentioned before one station is a kitting station that uses the pick-to-light feature. The
transporter layer uses several AGVs, but the production line may only activate a new AGV
when a new order is started. Therefore, a gate was developed to queue non used AGVs, as they
automatically stop through obstacle detection. This prevents extra communication with the
AGVs so that they would know when they should move or not. To control when a new AGV is
released and a new order is started, a button will be the interface to decide for starting an order
and opening the gate. Some kind of mechanism is needed to activate the kitting station.
The solution used for the prototype of the demonstrator, is that the kitting station is activated,
when the gate has been opened and closed, releasing a new AGV. Two NXT bricks have been
used, one for the gate and one for the kitting station. The NXTs uses Bluetooth for connection
in-between, and communicate in a master-slave configuration, where the gate acts as the master,
since it is where the production starts.
The hardware used for the kitting station is shown in Figure 4-15. As seen in the figure, three
new parts are used: Power Functions IR Receiver, Power Functions Light and NXT IRLink
Sensor. The IRLink addresses the communication with the IR receiver, asking to turn on or off a
light. It is possible to control up to 8 lights with this setup.
29
Implementation
Figure 4-15 Hardware for the kitting station. From top left to right: Power Functions light,
Power Functions IR Receiver and NXT brick. From bottom left to right: touch sensor, NXT
IRLink Sensor and color sensor
Figure 4-16 shows the final setup of the kitting station. Eight bins were used, where three
contain air tanks, two contain battery boxes, two have ad blue tanks and another one with the
plate to assemble the parts mentioned. The kit pre-assembled can be seen in appendix B, unit
10.
Figure 4-16 kitting station setup
30
Implementation
The gate used in the demonstrator is shown in Figure 4-17. The gate uses an ultrasonic sensor to
make sure that the gate is not closing when an object is in the opening.
Figure 4-17 The gate controlling the flow of new AGVs in the production line
In Figure 4-18 and 4-19, the programs’ structure for the gate and the kitting station is shown. As
mentioned earlier each one is implemented in separated NXT and LEGO MINDSTORMS
components. The Gate NXT brick works as a master, and the kitting NXT brick works as a
slave. This means that the kitting program can only be activated by the gate program. When the
gate program main loop body is ended, a Bluetooth message is sent to the slave unit, which the
kitting program is waiting for to start its main loop body. When the kitting program is started by
the assembly worker by striking the confirmation button in the kitting stand, the green light
stops blinking and first part bin is lighted up with a white LED. The status light turns red when
the program loop is completed. The kitting program can store several up to five orders (message
queuing), and starts a new one immediately when finishing the previous one.
31
Implementation
Figure 4-18 Chart showing the
program structure for the gate.
Figure 4-19 Chart showing the program
structure for the kitting station.
32
Implementation
4.5 Transporter programming
In this section all issues related with transporter layer programming are addressed. It is mostly
focused on the LEGO components side. Before discussing higher level implementations, a
description of how the Bluetooth interface between the NXT brick and MONT was implemented
will be presented.
4.5.1 Communication interface
Before establishing the messages format protocol to exchange between NXT and MONT (hostcomputer application responsible for low level communication with shop floor equipment), the
low level implementation of exchanging data will be presented below.
According to what was described in the section 3.3.1.3, Fantom drivers allow developing
applications that interact with the NXT brick, through either Bluetooth or USB bus. The
transporter layer with AGVs led to a Bluetooth implementation.
There are two ways of transmitting data, writing directly in the Bluetooth buffer or using a
mailbox system that the LEGO firmware has implemented.
The API on both sides, computer and NXT, includes methods to read and write messages to
those mailboxes. This is true on the NXT side, since NXC (the programming language chosen)
uses the standard official firmware. There are several languages that do not benefit from the
mailbox system.
Since this approach avoids going to a lower level programming, it was immediately preferred.
Moreover, the mailbox system has a considerable amount of error handling implemented,
providing faster debugging tools while developing the communication. However, there is a
drawback about using mailboxes, which is its size limitation. Messages can be strings with up to
58 characters. On the other hand, it is possible to write up to 65k characters directly in the
Bluetooth bus. To overcome this limitation, it was needed to split the messages when sending
and to collect several packages when receiving, in case the message exceeds the 58 characters.
Later, the message protocol will actually show that this limit is not exceeded, but an unlimited
solution is preferred. An evolution of the demonstrator may require bigger messages. The real
message protocol that MONT has implemented in MES factories is up to some hundreds of
chars.
Bluetooth communication is implemented in a master-slave fashion in the standard firmware.
When connected to a host computer, the NXT is always the slave. It means that the host
computer is always the one responsible for initiating a data exchange process. This is a relevant
issue, recalling that when an AGV arrives to a station it has to spontaneously tell MONT that it
arrived. This problem was solved by implementing in MONT a polling system, to poll
constantly all AGVs in the network.
Figure 4-20 shows the schematic with the flow of data. On the AGV program side, the messages
are written and read directly from the mailboxes allocated in the NXT flash memory. There is
no communication bus programming, keeping the code clean and simple.
In the MONT application, C++ API methods are used to encapsulate the messages in direct
commands (described in detail the Bluetooth developer kit, by TLG (2006)). The firmware runs
in the background of the AGV program, processing the direct command and storing the
message, received from the Bluetooth buffer, in the mailboxes. There are ten mailboxes
available with a maximum of five messages queued.
33
Implementation
Figure 4-20 Communication interfaces - data flow schematic
4.5.2 Message exchanging protocol
Once solved the low-level interface, the message exchanging protocol had to be agreed together
with Volvo IT and it is described in this section.
There are only two types of events, one related with handshaking, to register the carrier in the
MONT system and another related with requests of transportation between stations along the
assembly line. Table 4-1 includes an overview of the events.
Table 4-1 Events overview
Event
00
01
10
11
Description
Sent by
General commands
Request identity, when the NXTMONT
controller receives this command it
should reply with its identity (Event type
01).
Identity telegram.
NXT
Transport-mode related commands
Go to destination, is sent by MONT when MONT
the carrier should move to another
station.
Arrive to station event, is sent by NXT
NXT
when it arrives to a station.
Each event specification is described next in tables 4-2 to 4-5. “System ID” and “Carrier ID”
have different meanings in real Volvo IT MES but it was simplified for the demonstrator,
sharing the same string (example: system ID = “AGV01” and carrier ID = “AGV01 “).
Note that the field “Load exchange program” refers to a possible request from MONT to the
carrier to execute some operation. It can be, for instance, rotating or lifting a frame. For the
current setup of the demonstrator, this field is always left blank. The acronyms TB and L0 mean
trailing blanks (example: “AGV “) and leading zeros (example “0012”).
34
Implementation
Table 4-2 Event type "00" - Request of identity
Field
Event type
Pos Length Format
0
2
L0
Description
Event type constant
Table 4-3 Event Type "01" - Reply request of identity
Field name
Event type
System ID
Pos Length Format
0
2
L0
2
5
TB
Description
Event type constant
The system identifier constant which
is unique for each communicating
system, e.g. AGV01.
Table 4-4 Event type "10" - Request of transportation
Field name
Event type
From Comm.
Point
To Comm.
Point
Pos Length Format
0
2
L0
2
10
TB
12
10
TB
Carrier ID
22
10
TB
Exec.Order ID
32
15
TB
Load
exchange
program
47
4
L0
Description
Event type field
Communication point that MONT
believes the carrier comes from.
Communication point to where the
carrier is to be transported. This
indicates which station the carrier is
expected to be at.
The identity of the carrier id. (Not
system id).
Execution order id of the product unit
to start. This filed is mandatory for
the start station, but optional for
other stations.
Table 4-5 Event type "11" - Arrive to station
Field name
Event type
Comm. point
Pos Length Format
0
2
L0
2
10
TB
Carrier ID
12
10
TB
Exec.Order ID
22
15
TB
35
Description
Event type field
The communication point where this
event occurred, e.g. ‘ML010 ’.
This indicates which station the
carrier is at.
The identity of the carrier id. (Not
system id).
Execution order id of the product unit
to start. This filed is mandatory for
the start station, but optional for
other stations.
Implementation
4.5.3 Carrier programming
The programming charts for the AGV are presented in Figures 4-20 and 4-21. Each one
corresponds to two concurrent threads, one handling the main loop (Figure 4-20) responsible for
the line following and stations detection and the other responsible for handling a continuous
communication process between the microcontroller unit and MONT (Figure 4-21).
When starting the AGV program, before any other operation, it fetches its own identification,
carrier ID, from a file, and line parameters. The line parameters are the light values sensed by
the LEGO color sensor with the AGV completely on top of the line and outside the line. These
are essential to calibrate the line following PID algorithm. When reading the sensor, four values
are returned. Three of them correspond to the reflection when the integrated LED illuminates
the environment with red, green and blue light. The last one is the color, calculated by the
firmware based on the RGB values read. One can use one of these RGB values to track the edge
of a line. Red component was chosen, being the more sensitive to a grey scale (sensed between
top of line and top of table surface).
The main loop starts fetching the color sensor values and proceeds with their analysis. If a color
different than black and white is found, the AGV assumes it arrived to a station (blue, yellow,
green or red marks). In fact, it was not so easy to assume that. Because following a line implies
staying between white and black color, the sensor easily gets abnormal colors along the line. To
filter these colors, two criteria were required. To conclude that a color mark was detected, it is
needed that a predefined number of consecutive coherent color readings were read by the
sensor. 25 consecutive times was defined as the threshold, by trial and error, always relying on
the size of the color marks and the speed of the AGV. These 25 readings mean 250ms reading
the same color, since the loop runs every 10ms. For the second criteria, to ensure a robust
reading, the AGV was only allowed to detect stations if in the previous 1,5s the turning sum was
under a certain value. This criterion prevented an AGV to find color marks in curves. Once
again, the threshold was by trial and error. This second criteria was decided because misreading
was more frequent along curves. Also, this forced the color marks to be placed in straight lines,
what actually makes sense because the four stations were designed to be in line with each other.
It is important to mention that when an AGV arrives to a station, the “arrive to station” message
is sent to MONT spontaneously, outside the communication thread. Then, it waits for the target
station variable to become different than “NONE”. It will be the communication thread that will
set this variable, after MONT asks a “request of transportation”, like explained in table 4-4.
When an AGV arrives to ML010, it needs to scan the new frame to match it with its carrier ID
and send the information to MONT. Because the frame is not on top of the color sensors right
after the AGV stops, a mechanism had to be developed to ensure that the scanning only
occurred after the user places the frame. To address this problem, one of the color sensors stays
with its LED turned off and gets the ambient light. Do to its vertical position, before the frame
is put, the value is substantially high. With the frame on top of it, makes the reading decrease to
almost “zero” ambient light. Thus, this was the criteria. Moreover, the AGV waits for five
consecutive seconds with a low ambient light value, because the users may adjust the frame
before the color IDs get in the correct place, like shown in Figure 4-22.
36
Implementation
Figure 4-16 Chart of the AGV main thread
37
Implementation
Figure 4-17 Chart of the AGV communication thread; “00” – Request of identity; “01” – Reply
to request of identity; “10” – Request of transportation
Figure 4-18 Frame placement on the AGV with the frame ID pointing down to the scanning
devices
38
Testing
5 Testing
Everything was put together and all data about order preparation and instructions was inserted
in both MONT server and AAS computers. The complete setup can be seen in Figure 5-1, as
well as individual figures showing each station, ML010, Kitting, ML020, ML030 and ML040,
from Figure 5-2 to 5-6.
Figure 5-1 Complete setup of the demonstrator
Figure 5-2 ML010; in the back, it can be seen the set of frames ready to start production; in the
front, an AGV is standing, waiting for the instructions to be executed; a barcode scanner for
part assurance can be seen below the laptop; in this station, the assembly worker attach the
axles to the frame
39
Testing
Figure 5-3 Kitting station; instructions to execute the work on this station are shown in the
surface of the table
40
Testing
Figure 5-4 ML020; here the worker places the engine, fuel tank, accessory kit, side covers and
fifth wheel
Figure 5-5 ML030; here the worker places the cab and the wheels, finishing the assembly
process; the blue square is used to put the right amount of wheels, before assembling, to avoid
placing a wrong quantity
41
Testing
Figure 5-6 ML040; the truck is removed from the carrier and placed in the testing area; testing
instructions are followed using the AAS application; the carrier is released
In the Figure 5-7, it’s possible to see the gate and the AGVs standing in line, waiting for a new
order to start. The start is simulated by pressing the button on the right of the NXT brick.
Figure 5-7 Gate mechanism with button on the right to start production; the AGVs stand in
queue due to obstacle detection
Testing the demonstrator was limited to the presentation on the Volvo Group Tech Show 2011,
as referred before. It is still considered a test of high importance, due to the presence of a
considerable amount of factory managers and associated positions. In total, it was estimated to
reach around 2000 visitors, during the five days event. The innovation behind the demonstrator
and the central position that was given to it inside the event room make believe that most of the
visitors actually saw and tried the demonstrator.
There were some issues addressed specifically for the event, like calibrating the line following
parameters of the AGV to match the light conditions. The line was laid with smooth and wide
curves. The reason is that the tables were more slippery than the ones used before the event and
the AGV wheels skidded sometimes, specially performing curves with heavy trucks completely
assembled on top.
Extra glue in some parts of the engine module was needed, after checking the first tests. Also
some extra color marks were added to some modules to facilitate the placement identification,
after realizing how frequent the visitors needed support in the assembly process.
Each visitor could try at least one station or the kitting area. But, due to the affluence of visitors,
it was sometimes required to restrict the experience to a single station or kitting.
Appendix C shows a picture taken during the event, with one AGV carrying a truck under the
assembly process.
42
Discussion
6 Discussion
Due to the time and resources limitation, not every stage of the development process had the
equal efforts on. Testing time was shorter than it should, in order to achieve a completely robust
platform. There were some unpredicted issues raised about communication interface between
MONT and the LEGO components, reducing the amount of tests related with the MES concepts
exposure.
As part of the demonstrator requirements, material identification was prioritized by means of
barcodes (part assurance). However, in reality, a substantial amount of parts are delivered in the
assembly line in a sequenced fashion, according to the truck orders. The decision of not
including such feature has to do with administration material supplying facility. It would be
harder to actually coordinate the material flow in a sequenced way. But, surprisingly, the testing
users of the platform claim that there was material in the line not used to assemble the current
trucks, making it harder to find the proper material to assemble and also taking unnecessary
space in the line. This situation actually take the demonstrator solution a step from Lean concept
and then also the MES concepts, specially related to Just-In-Time, where right material, should
be on the right place in the right time. Thus, there is a concern about whether sequenced
material should be included in the demonstrator requirements or not.
Since the demonstrator uses on-screen instructions, there is a huge pedagogical benefit for the
user to understand the assembly steps, through text and graphical instructions. Images would be
unfeasible in paper. Furthermore, the elimination of paper instructions reflects an environmental
impact. In that respect, the demonstrator certainly showed the concept successfully.
Pictures should be as clear as possible to add the correct value to the assembly process.
Unfortunately, there were some cases where this was not true, lacking some details that made
the users commit mistakes easily. On the other hand, this fact proved that the preparation has a
considerable impact on the assembly performance. It raises the question of if losses would
decrease by increasing the preparation investment. However, the users that performed the tests
were assembling for the first time, with no previous experience. May it be the case that regular
users would assembly by heart, focusing less on the instructions?
The product design revealed good robustness in what concerns not taking pieces apart.
Although poka-yoke feature succeeded in most of the cases, there were few situations where it
failed, unexpectedly. What seemed to be clear enough for the project team, it was not for some
of the users, like placing the fuel tank with the tap pointing down or placing the accessory kit
misaligned with the frame. The frame was designed to handle different variants, placing the
same components on different sides, removing poka-yoke concept. Nevertheless, through
pictures there were very few cases of wrong positioning of modules, proving their importance.
Kitting area was robust and well designed as planned, easy to understand and follow picking
instructions. Though, users were not attracted to try it as much as for the stations around it.
Therefore, there seems to be a weak point in it, when compared to the rest of the line. The look
of every kit is the same, as explained in section 4.2, but their components were collected from
different bins each time. The question is if it would become more attractive and easy to catch
the point if there were actually different looking components.
After all, collecting all feedback and keeping in mind all issues here discussed some questions
remains. Is this solution the best of showing the good benefits of MES? Would an enlargement
of the platform, to show more concepts, improve the understanding of MES?
43
Discussion
44
Conclusions
7 Conclusions
The created MES demonstrator platform shows several important features to implement in
production. The features can be directly addressed to well known problem areas such as
wrongly assembled material or incorrect material choices. Using computer based instructions
that are more pedagogical and combining them with part assurance through any kind of
identification that needs to be recorded by the system, it is possible to decrease such problems.
The poka-yoke feature is implemented in the demonstrator in different ways reducing the
possibility of errors occurring. However, problems were detected during tests with people not
taking part in the development, which shows that it is a very complex problem, creating
accurate instructions and also designing modules in a good and assembly friendly way.
As mentioned in the discussion section, Just-in-time was not demonstrated since material could
be considered to be put in buffers. Buffers are not good for demonstrating production systems
with lean features and it would be preferred to use sequence driven material instead. Feedback
stated that it is confusing to place non used material in the production line. However, the
feedbacks from people that have tried the demonstrator are that they find it very interesting and
very educational. Using the platform for demonstrating interesting, modern, and well
documented features for improving production seemed, throughout the tests performed, to be a
good way.
7.1 Future work
There are some issues that should be considered to be analyzed, such as improving instructions,
enlarging pictures, configuring the rejection functionality, the feedback system and improving
the kitting station. There is the possibility to use the platform in the future as a pedagogical tool
to educate new assembly workers that have no or poor experience in assembly work. To be fully
coherent when showing the importance of using modern production systems, it would be
preferred to implement more features from MES such as sequence driven material, as well as
equipment that automatically returns performance feedback to the system.
45
Conclusions
46
References
References
ASTOLFO, D., FERRARI, G. & FERRARI, M. (2007). Building Robots with LEGO MINDSTORMS
NXT. Burlington, MA: Syngress Publishing, Inc.
BRAKSICK, L. (2007). Unlock behavior, unleash profits: developing leadership behavior that
drives profitability in your organization. New York: McGraw-Hill.
CHARLTON, S. & O’BRIEN, T. (2002). Handbook of human factors testing and evaluation.
Mahwah, New Jersey: Lawrence Erlbaum Associates.
DENNIS, P (2007). Lean Production Simplified. New York: Productivity Press.
FERRARI, G., FERRARI, M. & HEMPEL, R. (2002). Building Robots with LEGO MINDSTORMS.
Rockland, MA: Syngress Publishing, Inc.
GARDINER, K. (1996). An Integrated Design Strategy for Future Manufacturing Systems.
Journal of Manufacturing Systems, 15(1), 52-61.
HANSEN, J. (2007). LEGO MINDSTORMS NXT Power Programming: Robotics in C. Winnipeg,
Manitoba: Variant Press.
KLETTI, J. (2007). Manufacturing Execution Systems — MES. Berlin, Heidelberg: SpringerVerlag Berlin Heidelberg.
MESA INTERNATIONAL. (1997). The Benefits of MES: A Report from the Field. Pittsburgh,
Pennsylvania: Manufacturing Execution Systems Association.
MIDDLETON, P. & SUTTON, J. (2005). Lean software strategies: proven techniques for managers
and developers. New York: Productivity Press.
RODERBURG, A. KLOCKE, F. & KOSHY, P. (2011). Principles of technology evolutions for
manufacturing process design. TRIZ Future Conference 2009. Procedia Engineering, 9.
SHIM, J. & SIEGEL, J. (1999). Operations management. Hauppauge, New York: Barron's
Educational Series.
THE LEGO GROUP. (2006). LEGO MINDSTORMS NXT Bluetooth Developer Kit. Retrieved
December, 15, 2010, from http://mindstorms.lego.com/en-gb/support/files/default.aspx
THE LEGO GROUP. (2006). LEGO MINDSTORMS NXT Hardware Developer Kit. Retrieved
December, 15, 2010, from http://mindstorms.lego.com/en-gb/support/files/default.aspx
ZIDEL, T. (2006). A lean guide to transforming healthcare: how to implement lean principles in
hospitals, medical offices, clinics, and other healthcare organizations. Milwaukee, Wisconsin:
ASQ Quality Press.
47
References
48
Appendix A
Appendix A – Variant matrix
Table A-1 Variant matrix – variant 1 to 8
Rigid two rear axles
6x2
Variant number ->
Unit
number
1
2
3
4
5
6
7
8
7
8
10
11
10
11
13
14
15
12
Frame
Frame rigid
Frame tractor S
Cab
Cab red
Cab yellow
Driveline
Straight-six engine
Front wheel unit
Single wheel axle
First rear wheel unit
Single wheel axle
Double wheel axle
Second rear wheel unit
Single wheel axle
Double wheel axle
Left accessory position
Accessories plate
Fuel tank
Right accessory position
Accessories plate
Fuel tank
Side covers
Side panels red
Side panels yellow
Side panels gray
Others
Fifth wheel
Rigid two rear axles
6x2
1
2
3
4
5
6
7
8
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Note: Unit numbers refer to the next Appendix – Reference Catalogue of Product Modules.
49
x
Appendix A
Table A-2 Variant matrix - variant 9 to 16
Rigid two rear axles
6x4
Variant number ->
Unit
number
1
2
3
4
5
6
7
8
7
8
10
11
10
11
13
14
15
12
Frame
Frame rigid
Frame tractor S
Cab
Cab red
Cab yellow
Driveline
Straight-six engine
Front wheel unit
Single wheel axle
First rear wheel unit
Single wheel axle
Double wheel axle
Second rear wheel unit
Single wheel axle
Double wheel axle
Left accessory position
Accessories plate
Fuel tank
Right accessory position
Accessories plate
Fuel tank
Side covers
Side panels red
Side panels yellow
Side panels gray
Others
Fifth wheel
9
10
11
12
x
x
x
x
x
x
x
x
Tractor one rear axle
4x2
13
14
15
16
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
50
x
x
x
x
x
x
x
Appendix B
Appendix B – Reference
catalog of product modules
Figure B-1 Reference catalogue
51
Appendix B
52
Appendix C
Appendix C – Picture from
Tech Show 2011
Figure C-1 Tech Show 2011 – AGV carrying a truck under assembly process
53
TRITA-CSC-E 2011:129
ISRN-KTH/CSC/E--11/129-SE
ISSN-1653-5715
www.kth.se