Tutorial Software As Integrating Technology Paper

Tutorial Software as Integrating Technology in
Complex Systems
-
logo
TBD
Gerrit Muller
Embedded Systems Institute
Den Dolech 2 (Laplace Building 0.10) P.O. Box 513, 5600 MB Eindhoven The Netherlands
gerrit.muller@embeddedsystems.nl
Abstract
This tutorial describes the integrating value of software in complex systems. The
extensive use of software technology to integrate other technologies has a signif-
icant impact on the product characteristics and on the product creation organization
and process. This tutorial provides insight in the relation between software and the
system, and it provides insight in the consequences for the product and the organi-
zation. Some recommendations are provided to cope with these consequences.
Distribution
This article or presentation is written as part of the Gaudí project. The Gaudí project philosophy is to improve
by obtaining frequent feedback. Frequent feedback is pursued by an open creation process. This document is
published as intermediate or nearly mature version to get feedback. Further distribution is allowed as long as the
document remains complete and unchanged.
All Gaudí documents are available at:

http://www.gaudisite.nl/
version: 0.1 status: concept May 22, 2010

1 Introduction
In this tutorial we will address the role of software in a complex system by using
a waferstepper as an illustrating case. The material of this tutorial reuses previous
articles and presentations of the Gaudí project. However about 50% of the material
is new.
2 Case: the waferstepper and it’s context
disclaimer
The case material is based on actual data, from a

complex context with large commercial interests. The
material is simplified to increase the accessibility,
while at the same time small changes have been
made to remove commercial sensitivity. Commercial
sensitivity is further reduced by using relatively old
data (between 5 and 10 years in the past). Care has
been taken that the illustrative value is maintained
ASML builds wafersteppers, lithography equipment used by semiconductor

manufacturers. The lithography equipment determines to a high degree the perfor-
mance and cost of the semiconductor manufacturing.
Figure 1: ASML Twinscan AT1100
Figure 1 shows one of the most recent ASML products, the Twinscan AT1100.
This is an 193nm high NA scanner, capable of handling 300 mm wafers.
The main function of the waferstepper is to “print” the electronic circuit infor-
mation on the wafer. The waferstepper is only exposing the wafer, the actual circuit
is formed by many processing steps in the semiconductor fab. Many (typical
hundreds) dies, identical electronic circuits, fit on one wafer. A few dies are
Gerrit Muller Embedded Systems Institute

Tutorial Software as Integrating Technology in Complex Systems
May 22, 2010 version: 0.1
page: 1
source
reticle
lens
wafer
Figure 2: What is an waferstepper
exposed at a time. The original information for the exposure resides on the mask
or reticle. This mask or reticle is 4 or 5 times larger than the final circuitry. Via an
extremely high quality, but expensive lens subsystem the original is projected on
the wafer, see figure 2.
n n+1
expose
expose
vy
step
step
stepper: static exposure of field
t
reticle
vy
slit
wafer 250
t
expose
expose
mm/s
step
vx
scanner: dynamic exposure through slit
Figure 3: From stepping to scanning
Modern wafersteppers actually do the exposure scan-wise, where both reticle

and wafer move and the light is passing through a narrow slit, see figure 3. Scanning
is using the lens more effectively than static exposure of the entire area.
Lithography customers use a few key specifications for the lithography operation,
see also figure 4:
• Critical Dimension (CD) control or imaging
• Overlay
The Critical Dimension (CD) control defines how accurate the linewidth of
structures can be controlled. This parameter strongly influences the final perfor-
mance (speed, power) of the electronic circuitry.
The overlay is defined as the repositioning accuracy of successive exposures.
Electronic circuitry is build by exposing and processing layer by layer. Hence the

page: 2
imaging alignment
line
130 nm
width
45 nm overlay
critical
10 nm
dimension
Figure 4: Key specifications waferstepper
same wafer is exposed many times, with days to weeks in between, where the next
layer must be at (nearly) the same position. The overlay amongst others strongly
influences the density of electronic components that can be obtained.
1000
line width
in nm
250
180
130
100
100 70
50
10
1997 1999 2001 2003 2005 2007
Figure 5: Moore’s law
The entire semiconductor industry is driven by Moore’s law, see the visual-
ization in figure 5. Most competitors try to leapfrog each other by being faster than
Moore’s law, creating an extremely competitive environment, with large stakes.
In order to achieve the required performance figures technical budgets are used,
see figure 6. Such a budget is a decomposition of the allowed performance figure
into subsystem or component level contributions. Note that the addition of contri-
butions is not always linear; systematic effects add linear, stochastic effect add
quadratic.
These budgets are based on models of the system. Of course every model is a
simplification of reality. Figure 7 shows the many components in the system that in
one way or the other influence the overlay. It is immediately clear that the overlay
budget takes only a limited set of influences into account, the ”significant” ones.
When the performance requirements of the system increase (as dictated by
Moore’s law) more and more components start to fall into the significant category,
causing an exponential increase of adjustment and control complexity.

page: 3
off axis pos. off axis
meas. Sensor
accuracy repro
4 nm 3 nm
global stage Al. blue align
alignment pos. meas. sensor
accuracy accuracy repro
6 nm 4 nm 3 nm
system
lens interferometer
reticule adjustment
stability
matching accuracy
15 nm 1 nm
25 nm 2 nm
process matched single stage position frame

overlay machine machine overlay accuracy stability
80 nm 60 nm 30 nm 12 nm 7 nm 2.5 nm tracking
error WS
process
matching stage grid alignment tracking 2 nm
dependency
sensor accuracy accuracy repro error X, Y
5 nm 5 nm 5 nm 2.5 nm tracking
5 nm
error RS
metrology tracking 1 nm
stability error phi
5 nm 75 nrad
Figure 6: Overlay budget (1999)
: Fiducial
Overlay Influence Diagram.
(Maarten Bonnema, 19-3-1999) Reticle Errors
Illumination settings (NA )
Reticle Heating
Reticle Clamping
Energy
Light
Heat flow from LoS Fiducial Stability induced Distortion

into IF beams and Chuck expansion P and T of Air,
compartment Fiducial Calibration
Turbulences
Airshower RS Inaccurate Lens

Reticle
RS acceleration
LoS SS Feedforward
Heat flow from SS Bal RS Chuck IF
Motor Motor
into RS chuck and Mass Z-
compartment
sensors Acceler
ometer RS
T at top element of Lens s Ref-IF Data Delay
(Mag) Sensor-
P&T correction of frame +
Metroframe Lens
Temperature Drift Lens Heating
IF Block HP Inaccuracy
-> Effect on Showers ATHENA P and T in Lens
-> Effect on Position Sound
Measurement Compartment Accuracy of
of mirrors and IF's Accuracy Lens Lensmanipulators
ATHENA Mounting
Accuracy/Stability Lens Dynamics HP Rack
L Metroframe Metrology inaccuracy
Airmount Noise, S Metrology Errors

Limited Vibration Acceler Z-mirror Airshower WS
Isolation
Athena ometer
Ref-IF
s
Airmount IF Metrolog
Disturbance of MO
s Horizontal WS Servo
Wafer Block y
Metroframe vibration due
by LS setpoints IF
to water cooling (lens and WS Chuck Servo error
coolplates)
TIS Measurement
PAC/PA
T stability in LS LoS Fiducial Stability
lightpath SS Motor Feedforward errors
Motor Fiducial Calibration
Wafer Distortion due Air Foot
to Wafer table/chuck
Chuck deformation WS Balance Mass
Wafer Expansion by Gravity Compensator
noise Heat flow from LoS
input temperature
Baseframe offset
into IF beams
Chuck Dimensional
Heat flow from SS
Wafer Expansion by Stability
into WS chuck
Exposure
Figure 7: Everything influences overlay

page: 4
Exercise 1, 10 minutes
Make a 3 picture description (What, How, biggest challenge) of your own
system.
The key performance of the waferstepper, in terms of CD control, overlay
and productivity and the design choices depend on many context aspects, such as
the production environment, the business, the human stakeholders, and the many
involved technical disciplines.
resists
devices fab
logistics
semiconductor fab automation
design
processing SPC
tracks
reticule wafer yield
production
metrology optimization
reticules waferstepper
reticule
logistics
matching wafer
operator logistics
fab
maintenance contamination
layout
inspection and
utilization monitoring
fab cost fab
model infrastructure
Figure 8: Fab Context of Waferstepper
The key performance in the production environment depends on the wafer-

stepper itself, but also on many other aspects in the context of the waferstepper, as
shown in Figure 8. For example, the wafer and the reticule themselves influence
the performance as well as the measurement, processing and logistics of wafers
and reticules.
yield other players:

equipments vendors
value of system integrators
performance CD control lease companies
(MHz) fab designers
consultants
key driver trade-off
mask makers
resist makers
wafer makers
OEM’s: laser
business models of the customer: intimate partners: lens
design houses
foundries Limited number of customers;
vertical integration Many systems per customer
Figure 9: Business Context
In the business context, Figure 9 a balancing act is performed between yield

and CD control with a significant impact on the final chip performance (power
and speed). The business context is a complex playing field with many players,
such as equipments vendors, system integrators, lease companies, fab designers,
consultants, mask makers, resist makers, and wafer makers and many different
kinds of customers: design houses, foundries, and vertical integrated companies.

page: 5
"external" "internal"
customer managers engineers

purchaser business manager system engineers
decision maker marketing manager experts
user product manager manufacturing engineers
operator operational manager customer support
maintainer project leader
sales manager
suppliers
other quality manager
component manufacturer
government logistics manager
outsourced design
customer's customer line manager
banks, insurance technology manager
Figure 10: Human Context: Stakeholders
Figure 10 shows the stakeholders in the human context. The stakeholders are
both internal as well as external. All stakeholders have their particular concerns,
interests, rhythms, and contributions. The design emerges from a complex psychosocial
interaction between all these stakeholders.
temperature
stiffness UV senistivity transmission
sensitivity
modes
motors construction reflection
optical
actuators construction materials coatings
materials
servo's lens
uniformity
air
showers C&T gratings
mechanics imaging bandwidth
cooling dynamics optics lasers frequency
vacuum robotics
pulse
clamping lithography lamps timing
interferometers
mirrors
dose energy
measurement control
measurement dose
lasers home sensor
sensors measurement
capacitive gratings light
sensors SW control sensor
hall pre-
analog
sensors digital amplifiers
real time signal
signal
executives digital processing
processing
infrastructure
Figure 11: Multitude of Disciplines
The system is developed by a large number of different experts. Figure 11

shows many of the involved technologies, and therefor the involved technical disci-
plines.
Figure 12 summarizes all the mentioned different contexts of the waferstepper.
The waferstepper is in itself a very complex system, operating in a heterogeneous
and complex context.
Problems arising from the complexity of this context become visible in a rather
late stage of development: during integration or worse in the customer’s fab. The
problems are often detected during the integration, when (often well tested) compo-
nents have to work together, see Figure 13. The solution of these problems takes
more time than planned, causing project delays. The dynamics, the uncertainties,
the unknowns and the heterogeneity of these systems engineering aspects makes
complex systems engineering into a challenge.

page: 6
"external" "internal"
yield other players:
equipments vendors
value of system integrators customer managers engineers
lease companies purchaser business manager system engineers
performance CD control decision maker marketing manager experts
fab designers
(MHz) consultants user product manager manufacturing engineers
key driver trade-off mask makers operator operational manager customer support
resist makers maintainer project leader
wafer makers sales manager
OEM’s: laser quality manager
intimate partners: lens logistics manager suppliers
business models of the customer: other line manager component manufacturer
design houses government technology manager outsourced design
foundries Limited number of customers; customer's customer
vertical integration Many systems per customer banks, insurance
market, business
stakeholders
waferstepper
fab context multitude of disciplines
resists
devices fab
logistics temperature
stiffness sensitivity UV senistivitytransmission
semiconductor modes
fab automation motors reflection
design construction optical
SPC actuators construction materials coatings
processing tracks servo's
materials lens
reticle wafer yield air uniformity
production
metrology optimization showers C&T
mechanics imaging
gratings
bandwidth
cooling lasers frequency
reticles waferstepper dynamics optics
vacuum robotics
pulse
reticle
matching wafer
clamping lithography lamps timing
logistics
operator logistics mirrors interferometers dose energy
fab measurement control
maintenance contamination measurement dose
layout lasers home sensor
inspection and measurement
utilization sensors
monitoring capacitive gratings light
fab cost fab sensors SW control sensor
model infrastructure hall pre-
digital analog
sensors real time amplifiers
digital signal signal
executives processing
infrastructureprocessing
Figure 12: Complexity of Waferstepper Context
scheduled realized
closing date closing date
component 1
component 2
component 3 integration and test
component 4 delay
Do you have any design During integration numerous

issues for the design meeting? problems become visible
The default answer is: No.
Figure 13: Symptom: Delays appear during Integration
Make a 3 picture description (Application context, Value chain, technologies)

of your own system.

page: 7
3 The Role of Software in General
100%
physics / chemical
relative etcetera
effort
mechanics
electronics SW
1970 2000
time
Figure 14: The relative contribution of software effort as function of time
The contribution of different technologies to the total system has changed

dramatically during the last century. Figure 14 shows a schematic overview of
the relative contribution of the different technologies to the total system.
Human User
Application SW
Control SW
Feedback
Control
Digital electronics
Analog or power electronics
Mechanical device sensor
Figure 15: The Control Hierarchy of a system along the Technology dimension
The different technologies contribute in different ways to the total system. The
differences between the technologies will provide insight in the specific role of
software in an overall system. Figure 15 uses the control viewpoint to look at
the different roles of the technologies. Mechanical and Physical devices act as
actuators and sensors. The power for mechanical or physical devices is in one way
or the other generated by power supplies or amplifiers. Those power supplies or
amplifiers are based on analog electronics, sometimes with specific high frequency
technology.
The input signal for the analog electronics is often generated in digital electronics.

page: 8
concrete abstract
tangible intangible
mature immature
production lead time flexible?
material cost
Analogue / power Digital

Mechanics Software
Electronics Electronics
Figure 16: Characterization of disciplines, ordered along the level of abstraction
The digital electronics is then controlled by control software. The set-points for
the control are generated by application software. Finally some human being is the
operator of the machine and ultimately determines what the system must do.
From control point of view the technologies contribute in an asymmetric way to
the system: a clear control hierarchy. Note that for performance or safety reasons
many control shortcuts are present, ranging from mechanical interlocks to PID
controllers implemented in low level software.
Figure 16 shows the same technologies ordered along the horizontal axis. The
vertical axis shows a number of characteristics per technology that appear to be
(inverse) proportional with the height in the control hierarchy: concreteness, tangi-
bility, maturity, material cost, and production lead time. For example, mechanical
constructs are very concrete and tangible, the engineering discipline is well-known,
and the cost and the production lead time are directly related to the materials used
and to the construction process. In contrast, software constructs are abstract and
intangible, the software engineering discipline is in its early infancy, and the cost
and lead time are practically zero.
The translation of system requirements to detailed mono-disciplinary design
decisions spans many orders of magnitude. The few statements of performance,
cost and size in the system requirements specification ultimately result in millions
of details in the technical product description: million(s) of lines of code, connec-
tions, and parts. Figure 17 shows this dynamic range as a pyramid with the system
at the top and the millions of technical details at the bottom.
In Figure 18 the pyramid is annotated with some examples from the wafer-
stepper case. The key-drivers are clearly at a very high abstraction level. The
highly simplified description of the waferstepper, based on Figure 2 is also at this
very high abstraction level. The Millions of lines of source code are at the very
detailed level.
Figure 19 shows another illustration of the level of abstraction in this pyramid.

page: 9
10 0
number of
10 1
details
system
10 2 system
research focus
requirements
10 3
10 4 design multi-
decisions disciplinary
10 5
10 6 parts
connections mono-
10 7 lines of code disciplinary
Figure 17: Exponential Pyramid, from requirement to bolts and nuts
overlay: 45nm
source CD control: 10nm
productivity: 100Wph
reticule
lens
wafer
10 Mloc
Figure 18: Waferstepper Example
At the lowest abstraction levels the components are shown. Many (atomic) compo-
nents are mono-disciplinary. Components are aggregated into multi-disciplinary
subsystems. These subsystems cooperate to perform system level functions. The
cooperating system level functions result in certain system level qualities, such as
overlay, critical dimension control, and productivity.
The software implements the functionality and realizes the system level qualities.
The software is the integrating technology: it implements the behavior of the
cooperating components, and in that way determines the actual system level qualities,
see Figure 20
Make a toplevel decomposition of the software in your system and estimate the
amount of software of the constituting parts

page: 10
overlay
CD control
productivity
system qualities
prepare align and scan and
calibrate expose
transport wafer functions transport reticle
laser lens stages handlers electronics infra
illuminator metro frame
subsystems
source frames air mounts OS database
mirrors motors PCBs computer user interface
fiducials sensors ICs disks TCP/IP
lens elements robot cables monitor comms package
flaps bolts cabinets drivers
air showers nuts
components
Figure 19: From Components to System Qualities
system qualities
SW rmi
de
functions
te
im es
ple em
n
m er
en gin
ts
subsystems
fu qu
nc a
g
tio litie
na s
lity
components SW
Figure 20: Role of Software

page: 11
4 Software Requirements
When SW engineers demand "requirements", then they expect frozen inputs to be
used for the design, implementation and validation of the software. So far, however,
we have discussed system requirements. System requirements describe the what at
system level. The system requirement specification can be a limited document, at
least if the authors focus on the most important and relevant system functions and
characteristics.
10 0
number of
10 1
details
10 2 system
system
10 3 requirements
10 4
multi-disciplinary
10 5
software
10 6 requirements
10 7 mono-disciplinary
Figure 21: System versus Software Requirements
The translation of system requirements into detailed mono-disciplinary design

decisions spans many orders of magnitude. The few statements of performance,
cost and size in the system requirements specification ultimately result in millions
of details in the technical product description: million(s) of lines of code, connec-
tions, and parts. The technical product description is the accumulation of mono-
disciplinary formalizations. Figure 21 shows this dynamic range as a pyramid with
the system at the top and the millions of technical details at the bottom.
The amount of details in a software requirements specification is several orders
of magnitude more than the amount of details in the systems requirements specifi-
cation. Figure 22 shows the software “subsystem” in its context. All the relations
of the software subsystem with its context must be reflected in the software require-
ments specification. The software requirements specification is part of the detailing
process of the system design and implementation.
The user interface and system behavior depends on many design choices. The
software in most systems is the technology that implements both user interface
and system behavior. Embedded systems interact with the physical world. The

page: 12
operational choices
synergy, tools, ...
control of
user interface software
physical subsystems:
system behavior subsystem sensors, actuators
limited
computing resources
Figure 22: Why is the Software Requirement Specification so Large?
software implements the control of actuators and sensors that perform the inter-
action with this physical world. The related hardware-software interface (HSI) is a
broad interface. The HSI determines many software design choices, and becomes
part of the software requirements specification. Software needs a computing infras-
tructure to be executed upon. The computing infrastructure is always limited,
putting constraints on the software. The combination of performance and cost
requirements are translated into resource management requirements for the software
subsystem. The software development department and environment result in opera-
tional requirements for the software subsystems. For instance in terms of tools and
languages, and in terms of programming conventions and rules.
10 0
number of
10 1
details
10 2 system
market fashion format
10 3 system
requirements changes
competition legislation
4
10
avalanche
multi-
disciplinary
10 5 problems
6
10 software
requirements
technical effort
10 7 mono-
disciplinary
duration cost
Figure 23: And why is the Software Requirement Specification never up-to-date?

page: 13
The amount of details in the software requirements specification is huge. One
of the consequences is that this specification is never complete nor up-to-date,
see Figure 23. The environment of the software requirements specification is in
practice highly dynamic. The outside world is changing in many ways (market,
competition, legislation, fashion, and format). A small change in the outside world
(top-down) may cause many changes in the software requirements. Design and
implementation problems (technical, cost, effort, and duration) trigger bottom-
up changes that may propagate into changes of the system requirements specifi-
cation. Bottom-up changes can also trigger an avalanche of changes in the software
requirements.
How many pages are in your Software Requirements Specification?

page: 14
5 Evolution and Growth
illuminator
laser
beam
light source
shaping
light
reticle
reticle stage
handler reticles
positioning
input/output
alignment, levelling
measurement
system C&T
lens
control contanimation,
projection
coordination temperature
wafer
wafer stage
handler wafers
positioning
input/output
Figure 24: Block Diagram of a Waferstepper
In many domains systems evolve slowly from more or less purely mechanical
systems to complex software-intensive systems. Many subsystems still have some
dominant technology. Figure 24 shows the subsystem decomposition in the wafer-
stepper case. Dominant technologies are optics in the laser, illuminator, and lens
subsystems, mechanics in the reticle stage, reticle handler, wafer stage, and wafer
handler, and more general physics in measurement and in contamination and temper-
ature control.
system
control
coordination
ethernet
illumi- measure- reticle reticle wafer wafer

laser lens C&T
nator ment stage handler stage handler
VME VME
hori- hori-
vertical vertical
zontal zontal
motion motion
motion motion
Figure 25: Control Hierarchy of a Waferstepper
The same subsystems can be shown in the electronics communication view, as

in Figure 25. The dominant subsystems in Figure 24 have become simple nodes in
the communication view.
The historic evolution in these systems is that subsystems start as independent
subsystems, connected by a few straightforward synchronization signals. Over
time dependencies are developing, when subsystems start to interfere, or when
system performance requires more complex types of interaction.

page: 15
trend with increasing
performance requirements
SW per per per per preventive

sampling die wafer batch day maintenance
10 -3 1 10 3 10 6
seconds
Figure 26: Frequency of Control Actions
One of the discriminating design parameters is the frequency of doing certain

operations. For example, if some adjustment has to be done once in the system
lifetime, than a factory or installation adjustment can be done manually. If this
adjustment is complex or critical it might be supported by (SW) tools. However,
when an adjustment is required for every wafer, then the adjustment will be automated
for reasons of productivity and operational costs. Figure 26 shows an exponential
time axis with different typical frequencies of control actions. In general the more
frequent those control actions can be preformed the more stable and predictable the
performance will be. However, high frequent control actions are often much more
complicated than low frequent actions. Part of the complexity of high frequent
actions is caused by the required cooperation between many subsystems (and technologies0
to implement the automated high frequent control action.
automation
user interface
interface
monitoring and optimization
production
metro job control
and
installation
support
exposure control
data
management
dynamic calibration
user interface
static simple infrastructure
data
calibra- sequen-
store
tion cer feedforward monitoring
1990 2000
150 kloc 2000 kloc
Figure 27: Evolution of System Control

page: 16
During the historic evolution from independent subsystems, with little or no
automated adjustments, to continuously cooperating subsystems, full of high frequent
automated adjustments, more and more software coupling is growing. Figure 27
shows the SW stacks early in the evolution and late in the evolution.
and functionality
Complexity
Reliability
Performance
causes threatens
demands
loss of overview (150kloc fits in 1 mind, 2Mloc not)

(more than?) exponential increase of coupling
1:1 relation HW:SW becomes n:m relation
autonomous paradigm integrated

subsystems shift! system
Figure 28: Consequences of Evolution
During this evolution many paradigm shifts are made. Unfortunately the engineered
and managers are unaware of the paradigm shifts, and processes and design are
not adopted accordingly. Figure 28 shows some of the consequences of such an
evolution. Performance and functionality demands cause an increase of complexity;
the increase of the complexity threatens the reliability of the system. The original
system, with more or less independent subsystems required about 150k lines of
code. Such a system can be well understood by a single system designer; the
overview fits in a single human mind. The evolved system requires several millions
lines of code. In practice that means that the overview is lost, or best case that the
complete picture can be reconstructed with a limited set of senior designers. The
evolved system suffers significantly from the much higher degree of coupling and
the lack of one-to-one relationship between system function and subsystem.
Visualize the (SW) evolution of your system. What is your current phase?

page: 17
6 Why do we always have problems with software?
System engineering focus SW engineering focus

qualities qualities
productivity functionality concepts
image quality concepts maintainability structure
reliability domain requirements variability (generic) mechanisms
models
concerns concerns
integral design (quality, balance) configuration management
system context release procedure
lifecycle tools
operational processes SW processes
SW problems, change requests
education education
principles languages
heuristics operating systems
analysis and synthesis algorithms
processes formal methods
Figure 29: Different Focus of Software and System
In the previous sections we have seen that software is much more abstract and
less tangible than the more conventional technologies. We have also seen that the
software is the implementation technology of the system behavior, and function-
ality. The software implementation is the determining factor for the actual system
performance. An additional source of problems in product creation is the different
focus of the software engineering discipline and the system engineering discipline,
see Figure 29.
Observation of SW engineering teams shows that the main concerns are: config-
uration management, release procedure, tools, SW processes, and SW problem and
change requests. The qualities that get a lot of attention from the software crew are
functionality, maintainability, and variability. As a consequence of these concerns
and qualities the design focus is on concepts that help to structure and concepts of
generic mechanisms.
The System engineering concerns are quite different: integral design (quality,
balance), system context, life-cycle, operational processes. The qualities that get a
lot of attention by system engineers are productivity, image quality, and reliability.
These system level concerns and qualities create a focus on concepts related to
domain models and descriptive models of the system design.
The education of software engineers addresses many software technology issues,
such as: languages, operating systems, algorithms, and formal methods. The
system engineering education is less technological and addresses issues such as:
principles, heuristics, analysis and synthesis, and processes.
The characterization above shows that system and software engineers have a
completely different focus and education, while they have a intimate relationship:
SW implements behavior, functionality and actual performance!

page: 18
Application
Property editor Session

Spool server
manager
Queue
manager
NameSpace Resource
Broker
server scheduler
Event Transparant Configurable

manager Communication pipeline
Compliance Abstraction
Registry Monitor
profile Layer
Device
Persistent Plug-in
independent Plug & play
Storage framework
format
Figure 30: Caricature of a SW Architecture
The differences in focus and education also result in completely different views
on the system design itself. Figure 30 shows a caricature of a software architecture.
The diagram shows all kinds of generic software mechanisms and their layering.
The only reference to the actual system functionality is in the box called appli-
cation.
In contrast Figure 31 shows a caricatured of the system view of the Physics
engineer. This view is dominated by the optical elements and characterizations.
From systems point of view the relation between the optical path and the
required control, in software, is important. Figure 32 adds the control aspects to the
physics viewpoint. The system engineer is responsible for the multi-disciplinary
design. For example the trade-off to solve a image quality requirement in the
physics components or to solve it by some software controlled adjustment procedure.
This simple example of the physics and software viewpoint shows the differ-
ences in language and system perception by the involved engineers. Many system
level problems are caused by the limited understanding of the hardware and physics
by the software engineers.
This problem is worsened by the limited awareness by most managers of both
this limited understanding as well as the crucial integrating role of the software.
The software developments and the system development are intimately related as
shown above. Nevertheless the software departments are often quite isolated from
the other engineering disciplines. Figure 33 shows a number of the symptoms of
this isolation and the potential counter measures.
What is the degree of integration or isolation of SW in your organization?

page: 19
sensor
laser illuminator
reticle
pulse-freq, bw, uniformity
wavelength, ..
NA
abberations
transmission
lens
aerial image
wafer
Figure 31: Caricature of Physics Systems View
sensor
laser illuminator
reticule
pulse-freq, bw, uniformity
wavelength, ..
measure
adjust NA
abberations
calibrate transmission
analyse
process
log
lens
control
aerial image
wafer
Figure 32: Relation SW and Physics

page: 20
symptoms counter measures
colocation per function, subsystem or quality

SW people are clustered together
continuous system integration

SW is alpha tested before system integration
higher level processes are shared

SW team uses own specification and design process
interaction between SW,

SW specification is in SW jargon or formalism HW and system engineers
Figure 33: Symptoms of too isolated SW efforts

page: 21
7 Conclusion
System
product: sellable self-sustained entity
operating in a broader context
different focus:
" qualities
inherent " concerns actual
performance " concepts performance
reliability " education reliability
HW engineering SW engineering
tangible intangible
concrete abstract
goods flow costs & lead times no goods flow costs
physics laws "everything is possible"
Figure 34: Different Mindsets and Characteristics
The creation of a product is focused on ceating a sellable system that fits well in
the customer’s context. The system is realized by many different disiciplines. The
more conventional hardware oriented disciplines can be characterized by tangi-
bility, concreteness, goods flow costs and lead times, and physics laws. The much
younger software discipline, and to some degree the also young digital hardware
discipline can be characterized by intangibility, abstraction, no goods flow costs,
and the "everything is possible" mindset.
The hardware technologies determine the intrinsic performance limits, while
the controlling software determines the actually realized performance. The system
engineers, hardware engineers and software engineers use different languages,
have different mindsets, have different concerns and address different qualities.
These disciplines are highly complementary. The product creation process will be
improved by more interaction and communication between these complementary
engineers. Figure 34 shows these considerations in a single diagram.
References
[1] Gerrit Muller. The system architecture homepage. http://www.
gaudisite.nl/index.html, 1999.

page: 22
History
Version: 0.1, date: 26 April, 2005 changed by: Gerrit Muller
• changed status to concept
Version: 0, date: 13 April, 2005 changed by: Gerrit Muller
• Created, no changelog yet

page: 23

Tutorial Software As Integrating Technology Paper

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Tutorial Software As Integrating Technology Paper

Transféré par

Droits d'auteur :

Formats disponibles

Tutorial Software as Integrating Technology in

All Gaudí documents are available at:

version: 0.1 status: concept May 22, 2010

2 Case: the waferstepper and it’s context

The case material is based on actual data, from a

ASML builds wafersteppers, lithography equipment used by semiconductor

Figure 1: ASML Twinscan AT1100

Gerrit Muller Embedded Systems Institute

Figure 2: What is an waferstepper

scanner: dynamic exposure through slit

Figure 3: From stepping to scanning

Modern wafersteppers actually do the exposure scan-wise, where both reticle

Gerrit Muller Embedded Systems Institute

Figure 4: Key specifications waferstepper

Figure 5: Moore’s law

Gerrit Muller Embedded Systems Institute

process matched single stage position frame

Figure 6: Overlay budget (1999)

Heat flow from LoS Fiducial Stability induced Distortion

Airshower RS Inaccurate Lens

Airmount Noise, S Metrology Errors

Figure 7: Everything influences overlay

Gerrit Muller Embedded Systems Institute

Figure 8: Fab Context of Waferstepper

The key performance in the production environment depends on the wafer-

yield other players:

Figure 9: Business Context

In the business context, Figure 9 a balancing act is performed between yield

Gerrit Muller Embedded Systems Institute

customer managers engineers

Figure 10: Human Context: Stakeholders

Figure 11: Multitude of Disciplines

The system is developed by a large number of different experts. Figure 11

Gerrit Muller Embedded Systems Institute

Figure 12: Complexity of Waferstepper Context

component 3 integration and test

Do you have any design During integration numerous

Figure 13: Symptom: Delays appear during Integration

Make a 3 picture description (Application context, Value chain, technologies)

Gerrit Muller Embedded Systems Institute

Figure 14: The relative contribution of software effort as function of time

The contribution of different technologies to the total system has changed

Analog or power electronics

Mechanical device sensor

Gerrit Muller Embedded Systems Institute

production lead time flexible?

Analogue / power Digital

Figure 16: Characterization of disciplines, ordered along the level of abstraction

Gerrit Muller Embedded Systems Institute

Figure 17: Exponential Pyramid, from requirement to bolts and nuts

Figure 18: Waferstepper Example

Gerrit Muller Embedded Systems Institute

Figure 19: From Components to System Qualities

Figure 20: Role of Software

Gerrit Muller Embedded Systems Institute

Figure 21: System versus Software Requirements

The translation of system requirements into detailed mono-disciplinary design

Gerrit Muller Embedded Systems Institute

Figure 22: Why is the Software Requirement Specification so Large?

Gerrit Muller Embedded Systems Institute

Gerrit Muller Embedded Systems Institute

Figure 24: Block Diagram of a Waferstepper