Tektronix Case Study EEE465 2001 References: SG96 3.2 - PowerPoint PPT Presentation

1 / 14
About This Presentation
Title:

Tektronix Case Study EEE465 2001 References: SG96 3.2

Description:

... Oscilloscope ... line architecture for a family of oscilloscopes, motivated by ... of settings defining possible settings for the oscilloscope ... – PowerPoint PPT presentation

Number of Views:117
Avg rating:3.0/5.0
Slides: 15
Provided by: GregPh4
Category:

less

Transcript and Presenter's Notes

Title: 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
Write a Comment
User Comments (0)
About PowerShow.com