1. scalable software design
technology. people. value.
steXbv
www.steXbv.com!
Lessons
learned
from
the
design
of
an
architecture
for
a
product
family
of
custom
laser
conversion
systems
Lodewijk
Bergmans
[lodewijk@steXbv.com]!

2. (c)
2011
steX
bv
–
www.stexbv.com

3. About me
Industry Research
¨ Independent consultant ¨ software composition
(1994-1997, 2008-) ¤ objects, aspects, ..
¤ teach & mentor sw. engineering ¤ design & frameworks
¤ software architecture
¤ architecture & product lines
¨ e.g. Philips Medical Systems,
Ernst & Young MC, ¨ Industry-as-a-laboratory
Ordina Panfox ¤ ASML, Oce, Siemens, ..
(c)
2011
steX
bv
–
www.stexbv.com
¨ Ericsson Mobile ¨ European Network of
Communications (Lund) Excellence on AOSD
scalable software design
technology. people. value.
steXbv

4. The
goal
of
this
talk
¨
to
discuss
experiences:
¤ trade-­‐offs
in
the
design
of
an
architecture
for
a
product
families
of
laser
conversion
systems
¤ hints
&
guidelines
how
we
tried
to
address
these
trade-­‐offs
(c)
2011
steX
bv
–
www.stexbv.com

5. Context:
laser-­‐based
manufacturing

6. ZENNA
Laser
SoluCons
¨ designs
and
produces:
¤ custom
manufacturing
soluEons
using
laser
technology:
n welding
n cuHng
n marking
(c)
2011
steX
bv
–
www.stexbv.com

7. ZENNA
product
characterisCcs
¤ laser
scanners
n laser
processing
on
conEnuously
moving
materials
n focus
on
throughput
n high
precision
in
both
posiEon
and
power
of
laser
marking
n digital
converEng
(no
dies)
n support
for
both
short
and
long
producEon
runs
(flexibility)
(c)
2011
steX
bv
–
www.stexbv.com
n fully
automated
and
integrated
producEon
lines.
‘trackscanner’

8. Examples
of
material
processing
¨ most
relevant:
¤ label
cuHng
¤ abrasive
conversion
¤ foil
cuHng
¤ material
cuHng
&
marking
(c)
2011
steX
bv
–
www.stexbv.com

9. ZENNA
products
demonstraCon
video:

10. A
product
line
of
laser
scanners

11. Exploring
the
product
line
(domain
analysis)
¨ the
architecture
is
focused
on
products
with:
¤ moving
material
(e.g.
on
rolls)
¤ mulEple
stages
(laser/material
handling)
¤ flexible
producEon
series
n switch
products
with
liMle
or
no
loss
of
Eme
and
material
n job
management
n integraEon
with
ERP
and
factory
automaEon
¨ some
technological
dimensions:
(c)
2011
steX
bv
–
www.stexbv.com
1. scanner
technology
2. mulE-­‐stage
processing

12. 1.
scanner
technology
12
StaCcScan
SingleScan
MulCScan
TrackScan
§ Material
not
§ Material
moving
§ Material
moving
§ Material
moving
moving
§ Scanner
not
§ Scanners
not
§ Scanner
moving
(c)
2011
steX
bv
–
www.stexbv.com
§ Scanner
not
moving
moving
(1
axis)
moving
§ e.g.:
labelcuMer
§ e.g.
wideweb
§ e.g.
wideweb
stage
1
stage
2

13. 2.
mulC-­‐stage
processing
¨ many
configuraEons
involving
following
building
blocks:
¤ material
handling
n e.g.
unwinding
n detecEng
markers
for
special
(e.g.
unusable)
secEons
¤ laser
processing
stages
(1
or
2)
¤ quality
control
stage
(e.g.
aUer
laser
stage)
n dynamically
respond
to
quality
issues
(e.g.
waste
bin)
(c)
2011
steX
bv
–
www.stexbv.com
¤ product
handling
n e.g.
product
picking
with
robots
n currently
up
to
4
robots
n on
1
or
more
conveyor
belts
or
garbage
bin

14. Developing
a
soUware
product
line
for
laser
scanners

15. SoJware
development
context
¨ small
company
(10-­‐15
persons)
¤ outsources
most
manufacturing
acEviEes
¤ design
&
assembly
in-­‐house
¨ SoUware
history:
¤ gradually
grown
over
the
years
¤ without
soUware
engineering
background
(c)
2011
steX
bv
–
www.stexbv.com
¨ SoUware
complexity
grows
¤ more
automaEon
required
¤ larger
systems
with
more
components
to
control

16. quick
impression:
operator
UI
(c)
2011
steX
bv
–
www.stexbv.com

17. design
principle:
scalable
design
¨ i.e.
a
soJware
design
that
scales
up
with
¤ changing
requirements
and
feature
requests
¤ addiConal
products
in
the
product
line
n NB:
there
is
no
roadmap!
¨ approach:
¤ design
a
common
foundaCon
that
is
n simple,
generic
&
expressive
(c)
2011
steX
bv
–
www.stexbv.com
n forms
a
common
structure
that
binds
the
building
blocks
and
their
(future)
variaCons.
NB:
≠
having
prepared
for
envisioned
addiCons!

18. Some
architecture
design
trade-­‐offs

19. Overview
of
soJware
architecture
front-end
&
back-end
machine
control
(c)
2011
steX
bv
–
www.stexbv.com
device
control
hardware
interfaces

20. Trade-­‐off
I:
robustness
versus
flexibility
¨ run-­‐Cme
control
of
marking
(‘image
drawing’)
¤ e.g.
building
layout
from
individual
drawings
¤ accurate
marking
control
is
the
cri(cal
and
error-­‐sensi(ve
part
¤ marking
control
is
(somewhat)
different
for
most
applicaCons
¤ more
flexibility
allows
for
local
opCmizaCons
¨ soluCon:
¤ use
of
staCc
templates
n sufficiently
expressive
for
envisioned
products
(c)
2011
steX
bv
–
www.stexbv.com
¤ off-­‐line
processing
&
checking
¤ no
changes
to
laser
control
module
n much
less
quality
issues!

21. template
visualizaCon
sample:
(c)
2011
steX
bv
–
www.stexbv.com

22. Trade-­‐off
II:
ImplemenCng
control
in
‘hardware’
versus
soJware
¨ Example:
alignment
between
stages
(‘overlay’)
-67 -./0 -./1 -2/3&2+4+(&/("5%&
'%(%)*+,
!"#$%#&
.$#/%
.$#/%
-#*%&
-#*%&
0
1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!"#$%&'#(!$&#)*+,&$!!!!!!!!!!
' ' '
(c)
2011
steX
bv
–
www.stexbv.com

23. design
criteria
¨ consideraEons:
¤ Eming-­‐criEcal
à
hardware
¤ limited
hardware
experEse
inside
company
¤ volaElity
of
the
feature
¤ is
knowledge
needed
for
high-­‐level
control?
¨ formulated
these
design
criteria
¤ Eming-­‐criEcal
&
low-­‐level
control
à
hardware
(c)
2011
steX
bv
–
www.stexbv.com
n but
may
need
to
publish
what
happened
¤ process-­‐
&
logical
control
à
soUware

24. Trade-­‐off
III:
direct
communicaCon
versus
strict
layers
¨ Layers
are
good:
¤ clear
architectural
principle
layer 3
¤ avoid
cyclic
dependencies
¨ but
may
suffer
from:
layer 2
¤ improper
abstracCon
n à
bypassing
n may
cause
inconsistencies
layer 1
(c)
2011
steX
bv
–
www.stexbv.com
¤ cascading
dependencies
n all
intermediate
levels
are
involved
layer 0
¨ à
less
evolvable

25. Our
design
decision
¨ ConsideraEons:
¤ small
team,
does
not
benefit
much
from
strict
layering
¤ product
line:
components
will
be
exchanged
regularly
n with
possible
verEcal
impact
¤ distributed
over
mulEple
PCs
n would
complicate
layering
with
shared
state
even
more
(c)
2011
steX
bv
–
www.stexbv.com
¨ design
decision:
¤ aim
for
high
composability
with
directly
communicaEng
components

26. Trade-­‐off
IV:
scalable
architecture
vs.
YAGNI
¨ YAGNI:
“predicEon
is
hard,
especially
of
the
future”
¨ scalable:
“changing
is
hard,
especially
in
the
future”
¨ soluEon:
n (common
architectural
sense)
¤ well-­‐defined,
future-­‐proof
common
core
concepts
n simple
concepts
that
compose
to
build
even
complex
versions
¤ very
few
places
depend
on
actual
machine
configuraEon
(c)
2011
steX
bv
–
www.stexbv.com
-67 -./0 -./1 -2/3&2+4+(&/("5%&
'%(%)*+,
!"#$%#&
.#"/$
.#"/$
-"*$%
-"*$%
row model
0
1
4 2 & 4 4 4 !"#$%&"'(#%")*+,%# 4
4 4 4 3 4 4 4 4 4 4 ! 4 4 4

27. Overview
of
architecture
front-end
&
back-end
machine
control
(c)
2011
steX
bv
–
www.stexbv.com
device
control
hardware
interfaces

28. Wrapping
up

29. lessons
learned
¤ factors
that
made
life
harder:
n third-­‐party
components
&
hardware
issues
n did
not
sCck
with
centralized
row
administraCon
¤ factors
that
helped
to
reduce
and
manage
complexity:
n foundaCon
is
a
simple,
scalable,
core
conceptual
model
(row
model)
n we
separated
Cming
issues
into
hardware
n ‘triggerbox’
n we
implemented
most
control
logic
in
soJware
(c)
2011
steX
bv
–
www.stexbv.com
n disCnguished
device-­‐level,
machine-­‐level
&
job
management
n we
moved
away
(as
much
as
possible)
run-­‐Cme
marking
control
to
a
staCc,
pre-­‐processing
phase
n ‘model-­‐driven’

30. QuesEons?
Comments?