Tektronix Case Study EEE465 2001 References: SG96 3.2

1
Tektronix Case StudyEEE465 2001References
SG96 3.2

• Major Greg Phillips
• Royal Military College of Canada
• Electrical and Computer Engineering
• greg.phillips_at_rmc.ca
• 1-613-541-6000 ext. 6190

2
Context

• Weve now completed our tour of some of the many
  architectural styles
• Event-based
• Layered
• Data Flow
• Data Store/Repository
• Over the next few classes well discuss the
  design of systems using these styles
• Today well look at
• what it means to express a systems
  architecture
• an example in which the designers attempted to
  use a variety of styles before settling on one
  that was a good fit for the problem

3
Process Control Architecture
Input variables
Process
Ds to manipulated variables
Controller
Set Point
Controlled variable
4
A Layered Architecture
controlled system
5
Process Control Mapped to Layers
Set Point
Controller
Ds to manipulated variables
process
6
The Lesson

• Systems do not necessarily have an
  architecture, or an architectural style
• In choosing a style, we are really choosing a way
  of thinking about the system
• to focus our understanding of existing systems
• to guide our development of new systems
• Frequently it is useful to alternate between
  different architectural views of a system
• e.g., Phillipe Kruchtens 41 Views Model of
  Architecture, IEEE Software, Nov 95
• Logical View (static structure, dynamic
  behaviour)
• Process View (concurrency)
• Development View (file organization, packages)
• Physical View (distribution across system nodes)
• Scenario View

7
Tektronix Oscilloscope Software

• aim was to develop a reusable product line
  architecture for a family of oscilloscopes,
  motivated by
• originally little reuse across different products
• new hardware or requirements caused complete
  redesigns
• hardware and interfaces changing rapidly
• perceived need to address specialized markets
• performance problems with existing software due
  to strategy of loading a new control program for
  each mode change (initially worked well broke
  down as size of systems increased)
• ultimately produced a successful architecture
  which has been used in many products since

8
Approach 1 Object-oriented

• very useful as a modeling exercise
• identified many different types of data in the
  problem domain
• waveforms (max/min, x/y, accumulate),
  measurements, trigger modes, display modes, etc.
• less successful as a design exercise
• no clear consensus emerged as to functional
  allocation
• should measurements be associated with the data
  being measured, or represented externally?
• which objects should the user interface interact
  with?

9
Approach 2 Layered
Note that figure 3.7 in SG96 is incorrect.
user interface

• intuitively appealing since it partitioned
  function into well-defined groups
• boundaries of layers conflicted with interaction
  requirements
• e.g., user interface interacts with layers other
  than visualization
• could accommodate by going to a relaxed layered
  system
• fundamentally compromises design integrity
• unlikely to lead to effective reuse due to
  maintenance overhead

visualization
manipulation
digitization
filtering hardware
10
Approach 3 Pipe and Filter
view
signal
Couple
Clip
Acquire
To XY
Measure
Trigger
times
waveform
measurement

• did not isolate functions into separate
  partitions
• e.g., signal data can feed directly into display
  filters
• corresponds to system engineers conceptual model
• allows functions to be moved between hardware and
  software
• still not clear how the user interacts with the
  system

11
Approach 4 Modified Pipe and Filter
coupling
kind, rate
transform
size
view
signal
Couple
Clip
Acquire
To XY
trigger
desired measure
Measure
Trigger
times
waveform
measurement

• added a control panel interface to each filter
• this provides collection of settings defining
  possible settings for the oscilloscope
• it also decoupled signal processing from user
  interface design, improving modularity and
  reusability

12
Final modification Coloured Pipes

• pipes are expensive because of data copying
• some filters run at radically different rates
• solution introduce specialized types or
  colours of pipes, each with a different
  transmission policy
• some allowed data transmission without copying
• some discarded data if the downstream filter was
  not ready to receive it
• allowed system behaviour to be tailored to
  product needs

13
Approach 4 Viewed as Layers
user interface
coupling
control
view
measurement
signal processing
signal
14
Next ClassArchitectural Mismatch