• TABLE OF CONTENTS
HIDE
 Title Page
 Copyright
 Acknowledgement
 Table of Contents
 List of Figures
 List of Tables
 Abstract
 Introduction
 Background and goals
 Designing towards digital...
 The DRCS software structure
 Implementation
 Summary and conclusions
 Reference
 Appendix
 Biographical sketch
 Copyright














Title: Software structures for digital remotely controlled systems
CITATION THUMBNAILS PAGE IMAGE ZOOMABLE
Full Citation
STANDARD VIEW MARC VIEW
Permanent Link: http://ufdc.ufl.edu/UF00082374/00001
 Material Information
Title: Software structures for digital remotely controlled systems
Physical Description: xi, 159 leaves : ill. ; 29 cm.
Language: English
Creator: Kalman, Andrew E
Publication Date: 1994
 Subjects
Subject: Digital control systems   ( lcsh )
Remote control   ( lcsh )
Electrical Engineering thesis, Ph. D
Dissertations, Academic -- Electrical Engineering -- UF
Genre: bibliography   ( marcgt )
non-fiction   ( marcgt )
 Notes
Thesis: Thesis (Ph. D.)--University of Florida, 1994.
Bibliography: Includes bibliographical references (leaves 135-139).
Statement of Responsibility: Andrew E. Kalman.
General Note: Typescript.
General Note: Vita.
 Record Information
Bibliographic ID: UF00082374
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
Resource Identifier: aleph - 002042878
oclc - 33315007
notis - AKN0756

Table of Contents
    Title Page
        Page i
    Copyright
        Page ii
    Acknowledgement
        Page iii
    Table of Contents
        Page iv
        Page v
        Page vi
    List of Figures
        Page vii
        Page viii
    List of Tables
        Page ix
    Abstract
        Page x
        Page xi
    Introduction
        Page 1
        Page 2
        Page 3
        Page 4
        Page 5
        Page 6
        Page 7
        Page 8
        Page 9
        Page 10
        Page 11
    Background and goals
        Page 12
        Page 13
        Page 14
        Page 15
        Page 16
        Page 17
        Page 18
        Page 19
        Page 20
        Page 21
        Page 22
        Page 23
    Designing towards digital control
        Page 24
        Page 25
        Page 26
        Page 27
        Page 28
        Page 29
        Page 30
        Page 31
        Page 32
    The DRCS software structure
        Page 33
        Page 34
        Page 35
        Page 36
        Page 37
        Page 38
        Page 39
        Page 40
        Page 41
        Page 42
        Page 43
        Page 44
        Page 45
        Page 46
        Page 47
        Page 48
        Page 49
        Page 50
        Page 51
        Page 52
        Page 53
        Page 54
        Page 55
        Page 56
        Page 57
        Page 58
        Page 59
        Page 60
        Page 61
        Page 62
        Page 63
        Page 64
        Page 65
        Page 66
        Page 67
        Page 68
        Page 69
        Page 70
        Page 71
        Page 72
        Page 73
        Page 74
        Page 75
        Page 76
        Page 77
        Page 78
        Page 79
    Implementation
        Page 80
        Page 81
        Page 82
        Page 83
        Page 84
        Page 85
        Page 86
        Page 87
        Page 88
        Page 89
        Page 90
        Page 91
        Page 92
        Page 93
        Page 94
        Page 95
        Page 96
        Page 97
        Page 98
        Page 99
        Page 100
        Page 101
        Page 102
        Page 103
        Page 104
        Page 105
        Page 106
        Page 107
        Page 108
        Page 109
        Page 110
        Page 111
        Page 112
        Page 113
        Page 114
        Page 115
        Page 116
        Page 117
        Page 118
        Page 119
        Page 120
        Page 121
        Page 122
        Page 123
        Page 124
        Page 125
        Page 126
        Page 127
        Page 128
        Page 129
        Page 130
        Page 131
    Summary and conclusions
        Page 132
        Page 133
        Page 134
    Reference
        Page 135
        Page 136
        Page 137
        Page 138
        Page 139
    Appendix
        Page 140
        Page 141
        Page 142
        Page 143
        Page 144
        Page 145
        Page 146
        Page 147
        Page 148
        Page 149
        Page 150
        Page 151
        Page 152
        Page 153
        Page 154
        Page 155
        Page 156
        Page 157
        Page 158
    Biographical sketch
        Page 159
        Page 160
        Page 161
    Copyright
        Copyright
Full Text








SOFTWARE STRUCTURES FOR
DIGITAL REMOTELY CONTROLLED SYSTEMS

















By

ANDREW E. KALMAN


A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY

UNIVERSITY OF FLORIDA


1994




























Copyright 1994

by
Andrew E. Kalman














ACKNOWLEDGMENTS


Due to a variety of happenings, complications, conflicts and a general

inability on my part to finish things in a timely manner, this work was long in the

making. First and foremost my thanks go to my advisor at UF and the chairman

of my supervisory committee, John Staudhammer, for his patience and his wry

humor. Thanks go also to Eddie Sivazlian for his insightful comments, and to the

other members of my committee -- Jack Smith, Joe Duffy, Jacob Hammer and

Martin Uman -- for taking the time to review my work and suggest changes.

Thanks to Greta Sbrocco, who handled the administrative details that came with

my drawn-out progress, and to my parents, who impressed upon me the need to
finish that in which I had already invested countless resources. Thanks go to
Euphonix for providing an environment in which I could undertake and

complete this work while continuing with my duties there, and to a variety of
people at Euphonix who joined in discussions, tested new software, suggested

alternatives, correlated observed events with our theories and provided relevant

material. Among this group, special thanks go to Mike Morasky for the lively

discussions we had concerning "the code" and his assistance in implementing

many new features, and to Russ Kadota for his patience in interfacing his

software with mine, for the use of his library and for his editorial suggestions.
Finally, thanks go to my fiancee Christina, who is both the reason for this
dissertation's delay and the reason for its completion.


-iii-
















TABLE OF CONTENTS


ACKNOWLEDGMENTS .............................................................................. iii

LIST O F FIG U RES .................................................................................................. vii

LIST O F TA BLES............................................................................................. ix

A BSTRA C T ....................................................................................................... x

CHAPTERS

1. INTRODUCTION ......................................... ............................................ 1
1.1 Digital Remotely Controlled Systems ............................................ 3
1.2 Flexibility, But at a Price............................................. ................ 4
1.3 The Software Engineer's Dilemma ............................................. 5
1.4 Good Tools Make a Difference..................................................... 6
1.5 Overview of Research......................................... ........................ 7
1.6 Plan of Dissertation .................................................................. 8

2. BACKGROUND AND GOALS................................................ ............ 12
2.1 Review of Previous Work ............................................ ........... ... 17
2.2 Availability of Tools......................................... ....................... 18
2.3 A New Approach Must Be Sustainable ......................................... 20
2.4 Chapter Summary ..................................................................... 21

3. DESIGNING TOWARDS DIGITAL CONTROL ........................................ 24
3.1 Direct Analog Control ................................................ ............. 24
3.2 Adding Indirection to Analog Control ................................... .. 25
3.3 Replacing Analog Control with Digital ......................................... 26
3.4 Adding gP and Memory Provides Full Flexibility ..................... 28
3.5 Chapter Summary ....................................................................... 31

4. THE DRCS SOFTWARE STRUCTURE ................................... ............ 33
4.1 Division of Software in the DRCS................................................ 33
4.2 Layers Within the Framework .................................... ............ 36
4.3 DRCD Software Layers ............................................... ............ 37
4.3.1 The Input Layer ................................................................ 37
4.3.2 The Output Layer ............................................................ 40









4.3.3 The Logical Layer ........................................................... .... 42
4.3.4 Summary ............................................................................. 43
4.4 The Structure of the Logical Layer .............................................. 44
4.4.1 State Variables .................................................................... 44
4.4.2 Filters and State Variables Define the DRCS...................... 48
4.4.3 State Variables Enhance Code Modularity........................... 50
4.4.4 State Variables Form Snapshots............................................... 54
4.4.5 Allocating State Variables .................................... ............ 57
4.4.6 Reliability............................................................................... 63
4.4.7 Summary ............................................................................. 64
4.5 Automation .................................................................................. 64
4.5.1 The Automation Database .................................... ........... 66
4.5.2 Assignable Controls ............................................. .......... .... 70
4.5.3 Automating the DRCS............................................................ 71
4.5.4 Summary ............................................................................. 72
4.6 Command-Based Structure.............................................................. 73
4.6.1 Executing Commands .......................................... ............. 74
4.7 M across ............................................................................................. 75
4.8 Chapter Summary ....................................................................... 76

5. IMPLEMENTATION................................................................................ 80
5.1 The Architecture as Implemented .................................. ........... 81
5.2 The Scale of the Problem.............................................. .............. 85
5.3 Overview ....................................... ................ .......................... 86
5.4 Standardized Representations......................... .......... .......... ... 88
5.5 Input Filters .................................................................................. 89
5.6 State Variables and Snapshots..................................... .......... .. 90
5.7 Output Filters....................................................................................... 95
5.8 Commands ............................................................................. 98
5.8.1 Implementing Automation ..................................................... 102
5.9 Other Difficulties ............................................................................... 106
5.10 Alternative DRCD Implementations .............................................. 109
5.11 Analysis ................................................................................... 111
5.11.1 Costs of Method .................................................................... 111
5.11.2 Reliability of Method ............................................................. 112
5.11.3 Benefits of Method ................................................................. 113
5.11.4 Disadvantages of Method ..................................................... 114
5.11.5 Costs of Implementation ....................................................... 115
5.11.6 Reliability of Implementation.............................................. 118
5.11.7 Benefits of Implementation................................................ 120
5.11.8 Disadvantages of Implementation.................................... 122
5.11.9 Summary ................................................................................... 123
5.12 Chapter Summary ........................................................................... 125
5.13 Future Developments and Research .............................................. 129

6. SUMMARY AND CONCLUSIONS ............................................................. 132









R EFER EN C ES ......................................................................................................... 135

APPENDICES

A. RESOLVING SPECIAL CASES .................................................................... 140
A.1 Conflicting State Variables........................................................... 140
A.2 State Variables With Illegal States ................................................. 141
A.3 Sets of Conflicting State Variables ................................................... 142

B. STATE VARIABLE REPRESENTATIONS.................................................. 144
B.1 Alternate Representations ............................................................... 144
B.2 DRCD Format Representation ........................................................ 144
B.3 User Input Representation .............................................................. 145

C. LARGE SYSTEM DESIGN ISSUES ............................................................. 146

D. CODE COMPUTATIONS............................................................................. 148
D.1 Computation of Call/Return Overhead for Commands ........... 148
D.2 Computation of Switch-Type Command Preprocessor
O overhead ............................................................................................ 150

E. EXAMPLES OF DRCS HARDWARE .......................................................... 152

F. DISSERTATION CREATION NOTES......................................................... 157

BIOGRAPHICAL SKETCH .................................................................................. 159


-vi-















LIST OF FIGURES


Figure 1: Generic Digital Remotely Controlled System....................................... 14

Figure 2: Example System #1 -- Simple Audio Volume Control........................ 25

Figure 3: Example System #2 -- Audio Volume Control with VCA .................. 26

Figure 4: Example System #3 -- Audio Volume Control with DCA ................ 27

Figure 5: Example System #4 -- Digital Remotely Controlled Audio
Volum e Control System ............................................... ........... ..... 30

Figure 6: Layers within the DRCS .................................................................. 34

Figure 7: Command Action Flow.................................................................... 52

Figure 8: A Snapshot in Memory.................................................................... 55

Figure 9: Input-to-output Mappings in the DRCS ............................................. 58

Figure 10: A Mapping of a Single DRCS Function Requiring Multiple
State Variables ................................................... ............................ 59

Figure 11: 1-to-1, 2-to-1, 1-to-2 and 2-to-2 Mappings of DRCD Functions
Using a Single State Variable.................................................... ... 60

Figure 12: Tightly-packed State Variables ....................................... ............ .. 60

Figure 13: Automation (Single Pass) .............................................. ............ .... 65

Figure 14: Sample Automation Database Format ............................................ 67

Figure 15: Another Sample Automation Database Format................................. 70

Figure 16: First Phase of DRCS Design Process -- State Variables,
Representations and Harmony with Hardware Design.................... 77

Figure 17: Second Phase of DRCS Design Process -- Filters, Conflict
Resolution and Snapshots............................................. ............... 78


-vii-









Figure 18:


Figure 19:


Figure 20:

Figure 21:

Figure 22:


Figure 23:

Figure 24:

Figure 25:

Figure 26:


-viii-


Third Phase of DRCS Design Process -- Commands,
Automation and Large-System Issues ............................................ 79

The Control (User) Surface of a DRCS-based Professional
Audio M ixing Console ................................................. ........ ..... 81

Console I/O Channel Strip ............................................ ........... .... 85

Multiple Operating Modes Using Two Input DRCDs .................... 92

Automated Operation with External Computer (shown with
user activity redirection bypassed)..................................................... 106

Control DRCDs for OUT1 Function..................................................... 153

User Interface DRCDs for OUT1 Function ......................................... 154

Control DRCDs for Upper Fader Multitrack Assign Function.......... 155

Upper Fader Multitrack Assign LED Board ....................................... 156















LIST OF TABLES


Table 1: Layers and Representations .............................................................. 36

Table 2: Input DRCD Characteristics ............................................. ................ 37

Table 3: Input DRCD Examples .................................................................... 38

Table 4: Output DRCD Characteristics ............................................ .......... .... 40

Table 5: Output DRCD Examples ................................................................... 41

Table 6: Comparative Advantages of State Variable Representations .............. 48

Table 7: Summary of Modular Routines......................................... ............ ... 54

Table 8: Comparative Advantages of Snapshot Allocation .............................. 62

Table 9: Comparative Advantages of DRCS Automation Schemes ................ 73

Table 10: Console DRCD Count...................................................................... 87

Table 11: Fader Block Modes and their State Variables....................................... 93

Table 12: State Variable Representations Used................................................ 94

Table 13: State-Variable-to-LED Translation Table................................................ 107

Table 14: Real-Time Performance Degradation Due to Multiple
Processors .......................................................................................... 121

Table 15: Benefits and Disadvantages of Method and Implementation ........... 124

Table 16: Call/Return Overhead Summary .......................................................... 148

Table 17: Command Preprocessor Overhead Summary ..................................... 150


-ix-











Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Doctor of Philosophy


SOFTWARE STRUCTURES FOR
DIGITAL REMOTELY CONTROLLED SYSTEMS




By

Andrew E. Kalman

December, 1994


Chairman: John Staudhammer
Major Department: Electrical Engineering


Digital Remotely Controlled System (DRCS) programming remains a

potentially daunting task, particularly because of the scope of large systems and

their requirements for reliability and performance. DRCS programming is not

standardized, as the modularity of such systems often allows for a

compartmentalization -- and hence an insulation from the outside world --

within which programmers can do whatever they choose. After examining how

system architectures of the past have evolved with the arrival of inexpensive

digital computing power, we propose an original, structured approach which

yields benefits that are not immediately apparent.

We provide an overview of DRCS hardware and operation, and we illustrate

how and why traditional, non-computer-based systems are often redesigned or

replaced by ones which are software-driven. We introduce a new method for

structuring DRCS software that employs only three basic elements -- state








variables, I/O filters and commands. We examine a variety of alternate

implementations within our scheme, and assess their effects on the system.

Particular attention has been paid to the DRCS's observability from the outside

world. We discuss how the often competing goals of reducing object code size

and increasing execution speed affect the basic elements of our scheme.

Solutions are proposed for the special cases where conflicts arise due to real-

world issues that might otherwise compromise the regular structure of the

software in our scheme. Finally, the methodology is applied to a large, complex

system in assembly language, and an analysis is performed with respect to cost,

reliability and benefits on both the methodology and on an implementation over

its first several years of operation.

Programming a DRCS using our methodology requires minimum of 2-3 years

of programming experience and a working knowledge of digital devices. This

work provides the DRCS software designer with a new framework for creating a

high-performance system that has tangible benefits over one that has been

designed in a less systematic manner. Our focus is on larger systems, but the
results are applicable to systems within a wide range of overall complexity.


- xi -















CHAPTER 1
INTRODUCTION


Over the past forty years digital computers have undergone tremendous

changes. The "world's first electronic general-purpose computer", ENIAC,

developed during WWII, contained 18,000 vacuum tubes and filled a large room

[Pat90, p. 23]. Today, the Motorola/IBM Power MPC601 RISC-based processor

contains nearly three million transistors in an area less than two-tenths of a

square inch [Tho93, Bur94]. In addition to the obvious improvements in speed,

size, power consumption and cost, applications for computers have seen

enormous growth. Computing chips, in the forms of microprocessors and
microcontrollers, have become essential product design elements largely because

they are an enabling technology with which the designer can provide useful

features that were previously impossible or prohibitively expensive to

implement.

Many new products are redesigned or repackaged versions of previous

models. Adding a processing chip, the accompanying circuitry and sometimes a

user interface (UI) can improve a product's functionality, reliability, safety, cost,

size, appeal, interoperability, longevity, etc. Cordless telephones, digital

watches, intelligent remote controls, test and measurement instruments, auto-

focus cameras and automotive engine management systems are all examples of
digital computing power serving as the enabling element to transform older

products and technologies into competitive modern ones.


-1-








Internally, all of these products have an interface between the processing

elements) and the various parts of the product itself. Every such product has

input and output (I/O) devices, some of which form the user interface, others

which ultimately interface to the outside world. The use of a digital computer

inside requires a digital interface between it and the I/O devices. This

requirement has been accompanied by a great increase in the number and quality

of analog-to-digital and digital-to-analog interfaces available to the product

designer. The evolution of mass-market consumer items -- the compact-disc

player being an excellent example, along with emerging digital-media recorders

-- continues to deliver higher-performance, lower cost interface devices.
Many of today's products are digital-analog hybrids, and will not be replaced
by purely digital ones anytime soon. On a human's scale of perception, the real

world is analog, and a computer requires interface devices to interact with its

analog surroundings. The scale of these devices range from large (industrial

stepper motor) to small (airbag's piezo-electric g-force detector), but the nature of

the digital interface to the processor remains common and recognizable.

With designs containing very large numbers of I/O devices, monolithic
digital systems are easily overwhelmed by the requisite I/O traffic required to

service the inputs and control the outputs. One solution is to provide a large
number of independent computing devices which can, in toto, handle this traffic.
While this approach can ensure adequate system performance, it lends insight
neither into how the system's software should be structured, nor into how

optimal a particular structure may be with respect to code size and execution
speed. Coordinating the large numbers (often hundreds) of devices in such a
system, regardless of the number of processors, is an unsolved problem. This

dissertation provides a framework for designing and partitioning the software

that operates such digital control systems. It focuses on the device interface and






-3-

its impact on programming the host processorss, and shows how this software

structure is extensible to multi-processor systems.

A design based on the framework presented here has been completed to

implement an expandable multi-processor control system for audio applications.



1.1 Digital Remotely Controlled Systems


In its simplest form, the digital remotely controlled system (DRCS) consists of

a device with digital I/O, some sort of digital computer, and an interface

between them. This device may take the form of a manipulator, a sensor, a

switch, a display, etc. The computer will most likely be a microcontroller or

microprocessor (giP), with memory. The interface will usually be a bus of

predetermined characteristics. Together, these three components, along with a

collection of other digital elements required to complete a working computer

system, form a DRCS whose behavior is dictated by the capabilities of the

processor, the properties of the device and the execution of the software. A

DRCS will often be a new, application-specific design that builds on portions of
older designs.

A DRCS can vary widely in scope and size, using a single processor running

the simplest of programs, or with a multitude of processors running

sophisticated operating systems. It can have one or many devices that interface

to the real world. Interfacing to many devices with digital I/O, e.g. analog-to-

digital converters (ADCs), is quite easily accomplished within the framework of

today's typical jgP system design. In the early stages of a design, the software

engineer is usually concerned with issues like I/O bandwidth, interface
correctness, and symbiosis between processor and design tools. Once the






-4-

corresponding performance requirements have been set, a competent hardware

engineer should have little trouble delivering a working prototype that the

software designer can use to develop and test his programs.



1.2 Flexibility, But at a Price


As a DRCS's design, and later its implementation, progresses towards

completion, some of the software programming decisions made will have a

profound effect on the system. Earlier decisions concerning choices of hardware

to match the requirements of the system will also have an impact. For example,

some processor families (e.g. the Zilog Z80 series) can exhibit high performance

when executing assembly-language code, but their performance may drop off
rapidly when executing code compiled from higher-level languages (e.g. C). This

may be due to a lack of availability of good compilers, or it may be due to the

processor's architecture and instruction set. The freedom that arises from being

able to design and program the DRCS must be carefully managed to guarantee

performance.
Programmable components are often added to a design to improve flexibility

and enable a wide range of operating modes. The benefits of this addition are

quickly picked up by the system designer. In many instances, previously

unrealizable features are easily implemented with the newly found power of the

design's digital elements. The functionality and performance of a DRCS stem

ultimately from its software.
Experienced systems designers recognize that the above mentioned power
and flexibility are accompanied by a potentially negative aspect of the design;
namely, that the success of the final product may hinge dramatically on the






-5-

quality of the system software. Software that must interface to the real world can

be very difficult to write properly, particularly when timing issues are involved,

and a haphazard approach to a solution rarely results in success. Not only does

the effort to manage software development increase with the size of the project

and the number of programmers, but the myriad of processor architectures,

programming languages, data structures and other programming issues make it

difficult for many programmers to settle on a satisfactory coding paradigm.



1.3 The Software Engineer's Dilemma


Hardware designers can draw on a large body of knowledge outside of their

own experience when confronted with a new design. Trade journals,

applications guides, do-it-yourself projects, old schematics and data books all

contain proven circuits which can be combined piecemeal to form larger systems.

A thorough search can yield a near-limitless variety of solutions to a particular

problem, many of which are easily comprehended and realized.

The software engineer faces a more difficult situation. Not only is systems

software tied intricately to the hardware on which it runs, but the detail-oriented

nature of control software resists simple one-page abstractions. While packaged
software solutions are available (usually in the form of software libraries), most
programmers find themselves utilizing some basic framework to which they

attach task-specific software modules. Some such frameworks are newly

designed for a specific project, others are purchased from software tools vendors

and many are lifted from previous programming projects. The quality and

success of a design have become largely dependent on how these tools are

employed.







-6-


1.4 Good Tools Make a Difference


When searching for software tools, it is difficult to know a priori whether the

chosen tool will remain adequate for the duration of the project. Only careful

planning, covering all parts of the design, can ensure the adequacy of the tools

chosen. Real-world constraints often limit the time available for this analysis.

Furthermore, there may be unforeseen difficulties beyond the engineer's control,

or the design requirements may change in mid-cycle.


Even at this late date, many programming projects are still operated
like machine shops so far as tools are concerned. Each master mechanic
has his own personal set, collected over a lifetime and carefully locked and
guarded -- the visible evidences of personal skills. [Bro75, p. 128]


Tools that provide the programmer with the ability to meet deadlines, achieve

design requirements and work easily within the code are highly prized.

Especially in larger, real-time DRCSs the ongoing coding effort can become
overwhelming for many programmers. Common or standardized tools aid in

communication, but specialized tools may still be required in certain instances.

This work presents a powerful, general-purpose programming tool, in the form

of a prescribed methodology, for structuring that part of a DRCS's software

which handles the interaction between a processor and a remotely controlled

device. Such a tool enables DRCS software designers to create higher-quality

systems in less time, ultimately benefiting the success of their product.






-7-


1.5 Overview of Research


Thanks in part to Alan Turing [Tur50], the programmability of the digital

computer means that a virtually endless variety of methods can be implemented

to solve "any effectively solvable algorithmic problem" [Har87, p. 221]. Many

approaches will be fundamentally similar, differing simply in the details of the

implementation (e.g. choice of programming languages or size vs. speed

optimizations). Our narrow focus on the digital remotely controlled device

(DRCD), aided by the extent of standardized digital interfaces, will isolate us

from needless details. The scope of this work does not include a cost-benefit
analysis of every possible DRCS implementation, but focuses on the fundamental

aspects of the interface between a DRCD and a digital computer, and how the

choice of an underlying software structure to handle this interface can strongly

affect the performance of the system.

We will analyze how the DRCD can be integrated into the DRCS, and its

impact, direct and indirect, on the user interface. We will investigate the extent

to which the specifications of the DRCD play a role in the design and

performance of the system's software. We will propose a framework within

which the programmer can structure the software of a DRCS to great advantage.

Finally, we will demonstrate how this structured software approach can be
applied to a large, real-time DRCS.
Software for a large-scale (hundreds of user inputs) multiprocessor DRCS that

links the user interface indirectly to the DRCDs -- by means of processing
elements operating within a particular software framework -- is the

demonstration of the ideas presented in this dissertation. The goal of the







-8-

research is to provide a universal and more formal framework for software

linking user input to control output. A DRCS using this framework can achieve,

at low cost, a level of small- and large-scale functionality beyond that of a direct

input-to-output chain, and will allow for substantial expansion beyond its

original scope.

Both new and experienced DRCS designers will benefit from this work for

several reasons. First, it illustrates the benefits of transforming an older design

into a DRCS. Second, it develops a well-defined structure for DRCS

programming, a very useful tool. Third, it provides solutions for many of the

real-world issues that must be addressed when situations force the designer to

depart from his ideals. Fourth, it proves that a large and complex real-time

system can use the proposed software structuring to its advantage. Overall, it

enhances our knowledge of systems with digital control and builds a framework

within which we can create robust, reliable and powerful digital remotely

controlled systems.



1.6 Plan of Dissertation


Particularly in assembly [language], you'll find that without proper up-
front design and everything else that goes into a high-performance design,
you'll waste considerable effort and time making an inherently slow
program go as fast as possible -- which is still slow -- when you could
easily have improved performance a great deal more with just a little
thought. [Abr94, p. 3]


The impetus for this research was the observed fact that the development of a

large, software-controlled system quickly becomes unmanageable if not planned

carefully in advance; and success is unlikely unless said plan is adhered to

[War90]. The sheer code size necessary to control and interface to a large number






-9-

of DRCDs requires the programmers) to expend much time and effort to correct

any repeated conceptual errors, to code desired optimizations and to enable new

features. Without a structured approach to programming, we felt that progress

in developing the DRCS would follow a line of diminishing returns. Hence we

set out to characterize the basic requirements of the DRCS, and from them
develop a framework for DRCS control software which would greatly ease

further development and guarantee performance. By taking a "vertical"

approach and accounting for all the DRCS activity that may surround a DRCD,

we were able to create a design framework that is extensible "horizontally" to

multi-DRCD DRCSs. The results obtained are widely applicable to all DRCSs.

This research evaluates the requirements of control software for DRCSs and

the problems that the system designer encounters as higher levels of

functionality are brought into the design. It investigates the interplay of software

and hardware in such a system and seeks to define a software framework which

yields the greatest benefits to the final product. It scrutinizes the software

interface between the computing elements and the devices being controlled. It

demonstrates the system advantages (and disadvantages) of divorcing the user

interface from the DRCDs. It considers the ramifications of choosing particular
software design constraints and methodologies. It analyzes overall system

performance; furthermore, it examines those non-ideal situations where

complications arise.

This research is organized as follows. First, the logical evolution of digital

remotely controlled systems is outlined, and the characteristics of such systems

are laid bare. Second, various schemes for organizing the software of such a

system are evaluated, resulting in the proposal of a unique framework for DRCS
software. Third, the framework is implemented within a commercial, salable






-10-

product to demonstrate its utility. Finally the success of the implementation is

evaluated, with suggestions for future designs.

This dissertation consists of six chapters. The introductory and background

chapters survey DRCS fundamentals, expose the wide variety of DRCS

implementations and raise the awareness of the great latitude granted the DRCS

designer. These two beginning chapters stress the benefits of a well-structured

approach. The third chapter presents an in-depth progression of a simple design

from a traditional analog version to a fully digitally controlled one, and serves as
a reference for the hardware elements of the DRCS architecture. The fourth

chapter introduces the dissertation's central theme -- that of structured DRCS

control software -- and details the steps involved. The fifth chapter covers a real-

world implementation of the proposed software scheme, exposing the reader to

issues of software-hardware integration, and concludes with an analysis of the

costs, reliability, benefits and disadvantages of both the method of creating the

DRCS software and of the resultant implementation. The final chapter

summarizes the work and points out some directions for further development.

In identifying the objectives of this work, there may be some items unfamiliar

to the user. These will be covered in depth later on. Our primary objective is to

develop a framework, or methodology, for creating DRCS control software.

Using this framework should lead to substantial simplification of the

programming effort required. This framework should be clear enough for any
first-time DRCS programmer to use as a guide for bringing his system into

operation. A minimum of 2-3 years of programming experience, as well as a
working knowledge of digital devices, is required. The DRCS programmer will
be able to identify the defining characteristics of the DRCS and translate them

into real data structures and procedures that fit into the proposed software







-11-

structure. By the end of this work the reader will have an appreciation for the

soundness of our approach, as well as the deficiencies of other methods.

We have two secondary objectives. One is to address the common worries of

systems designers and demonstrate the tradeoffs involved in using our

approach. We hope to convince the reader that our approach is simple, elegant,

and enhances the performance of the system. Our other objective is to present

and explore functional scenarios common to many DRCSs and show how the

proposed approach facilitates bringing higher-level functionality to a design with

an initial lower-level performance.















CHAPTER 2
BACKGROUND AND GOALS


The steadily increasing performance, falling cost and resultant proliferation of

inexpensive computing elements, coupled with powerful, low-cost interconnect

and networking schemes, has led to a digital control explosion in a wide variety

of applications, such as automotive and telephony devices [Mi193, Cri93]. This

was previously the near-exclusive domain of industrial controls; today, new

applications are becoming increasingly commonplace.

The DRCS accepts user input and other external and system inputs and

effects corresponding changes on (physical) target hardware in real time. Apart

from monitoring the state of the system, the primary DRCS activity comes with

user input changes; if the user makes no input changes then the DRCS may have

little to do. When changes do occur, they can be fed back to the user in two

primary forms: 1) an indication of the hardware change and 2) the resultant effect

it has on the element being remotely controlled (e.g. robot arm position, audible

signal level, engine performance). Only the creators and maintainers of the

system are concerned with its internal structure. The internal workings of the

DRCS must be hidden from the user. The system as a whole must feel as if the

user is "connected" directly to the target hardware.

A very simple example of a DRCS is the emerging replacement with a digital

encoder of an automobile's conventional accelerator linkage (usually a direct,

mechanical linkage between accelerator pedal and throttle plate or "butterfly

valve" on the engine). This encoder's signal is read by an on-board digital


-12-







-13-


computer which then actuates servo-motor throttle controls in a predetermined

programmed manner. These three items a sensor/interface, a processor and an

actuator -- often are part of a much larger modem "engine management" system

in which


the user interface consists of the accelerator pedal, the
tachometer, the steering wheel and various engine-status
indicators (e.g. water temp and oil pressure dials, MPG
indicator).
external inputs consist of ambient air temperature sensor, fuel-air
mixture sensor (so-called oxygen or lambda sensor), water and
oil temperature sensor, manifold vacuum sensor, knock sensor,
etc.
a variety of analog and/or digital processes analyze the engine's
performance and compute required corrections to achieve
optimal power, economy, smoothness, etc.
multiple digital remotely-controllable devices (DRCDs) like fuel
injectors, intake plenum controls, ignition systems, valve timing
controls, bypass valves, etc. effect the desired engine operating
changes to achieve proper running.
an external diagnostics interface provides a means of measuring
and calibrating the system to a known reference.


Note that as a whole, we may consider some sophisticated automobiles as

even larger instances of the DRCS. The new Audi A8 sedan "can sense where the

sun is, and cool the hotter side of the car with more vigor" [Cor94, p. 24]. As an

extreme example, one manufacturer has integrated additional features such as

safety automatic windows, temperature-controlled seat heating, "automatic

stability and traction control" (ASC+T), "map-adjusted electronic engine power

control" (EEPC), "dynamic stability control" (DSC) and "speed-related,






-14-

pressure-controlled driver's side windshield wiper" into one complete networked
automotive control system [Sch93, p. 26].1
In conjunction with the system's computing power the DRCDs in this modern
engine management system provide the DRCS with tremendous flexibility and
adaptability. The system in the above example can provide substantial increases
in horsepower and fuel economy, a reduction in emissions and greater reliability
and durability over engines without this level of control sophistication. The
additional demands placed by a competitive marketplace often make a DRCS a
necessity rather than a luxury or designer's plaything.
A generic DRCS system might be structured as shown in Figure 1.


dUB


Figure 1: Generic Digital Remotely Controlled System


1 There is concern as to who will service such a complex automobile its sophisticated
electronics require training and familiarity beyond that of the average auto mechanic.







-15-


We characterize the DRCS as having the following components:


a user interface (UI),
a number of processing elements, performing a variety of tasks,
and
a number of DRCDs.


Additionally, the DRCS may also have, as an extension:


a machine interface to enable connections to other computers,
networks, etc., and
an external interface to allow it to gather input from and
disseminate output to its environment.


DRCSs have several advantages:


They present the system architect and programmer with
flexibility (for lack of discipline this can become a disadvantage,
too).
They are sufficiently modular to allow for transparent changes
and upgrades to the remotely controlled devices (e.g. switching
from 8-bit control to 12-bit control without altering the UI). This
means that the software architecture of an DRCS can remain
relatively independent of the hardware design.
They are capable of instant resettability.
They are capable of automation.
The user interface need not be tied tightly to the DRCD itself. This
has some Virtual Reality (VR) implications.
Their cost is usually lower than that of less flexible architectures.


The hallmark of the DRCS is the insertion of one or more processing elements

between the user and the item(s) being controlled. The existence of these







-16-

elements and the resultant indirect link between the user and the target system

bring a plethora of issues into a system that must appear quite simple to the user.

The key challenge is to structure the system with an emphasis on the

environment in which it will be used.

DRCS hardware is often application-specific, at least in terms of the interfaces

and the DRCDs used. The choice of processing power is perhaps more

standardized, but need not concern us provided it meets these general

requirements:


The processors) is a (are) digital computing elements) with
memory (e.g. Harvard or von Neumann architectures).
In a multiprocessing scheme there is a high degree of
interconnectivity among the processors.
Software processes can exist transparently across one or more
processors in the system.
The interconnects have sufficiently high bandwidth.
All the hardware in the system behaves in a deterministic
manner.
The hardware is sufficiently powerful and fast to operate in a
real-time environment.
The system is relatively easily extensible.
As a bonus, the system should be fault-tolerant.


DRCS architecture and applications abound. Some are more suited than

others to the task at hand. Given the existence of a hardware platform from

which to build an DRCS, we will focus on developing structures for that software

task which is unique to the DRCS -- the software that manages and translates

user input to system actions and user feedback. We will analyze several DRCS

scenarios and propose scenario-tailored software structures that are efficient,

expandable/extensible and may have other potential benefits.






-17-


2.1 Review of Previous Work


There is a broad expanse of literature covering computer-based systems with

heavy I/O demands. Among the topics often discussed are real-time response

[Sta89, Oeh93, T6r92], architectures and partitioning [Mil93, Tan91], cost and

reliability [Oeh93, Kir91], simulation and design [Fad92, T6r92] and performance

evaluation [Mil93, Oeh93]. In most discussions of systems the issue of how to get

from user input to device control is small. Of greater interest appears to be, for

example, the investigation into why such systems fail [Inv93, Spa94]. I/O issues

often appear relegated to the back burner -- the situation might be summarized

by simply stating that "digital and analog IO modules are included for

synchronization with an environment" [Kir91].

Given the little attention paid to the integration of I/O routines into these

systems, we reasonably conclude that this portion of the design is generally

being "hacked" without much attention to its effect on the systems.

Suboptimizing by hacking2 remains a viable means of achieving a goal; when

used to excess, it rapidly becomes fatiguing to the programmer and detracts

substantially from the readability, maintainability and portability of the system

software.


... handcrafted assembly language and optimizing compilers matter,
but less than you might think, in the grand scheme of things -- and they
scarcely matter at all unless they're used in the context of a good design
and a thorough understanding of both the task at hand and the PC.
[Abr94, p. 3]


2 Using empirical data to optimize, as opposed to optimizing from an original structured plan.






-18-


Also, the performance of many applications and architectures is I/O bound
[Abu86], perhaps without the knowledge of the designer. What is lacking from
the literature is a systematic and formalized procedure for linking the input side

of the system to the output side. The fact that all these systems use I/O, and that

many of them employ a man-machine interface [T6r92], indicates widespread

applicability for a formalized approach.

The lack of readily available treatises on this topic is perhaps explained by the

degree to which it is hidden in the final product. For example, the 250+-page

factory service manual for the Nikon F3 -- a professional computer-controlled

35mm SLR camera replete with DRCDs -- has not a single page devoted to any

software issues [Nip80], despite the often-lengthy explanations to calibrate

various subsystems to millisecond or millivolt accuracy. Neither do the

brochures and user manuals. The details of DRCS software are somewhat akin
to, say, engineering drawings for mechanical components -- they represent
proprietary information that is not usually divulged. Without insight into them,
the internal workings of a DRCS are neither glamorous nor obvious. Should they
fail, it is unlikely that anyone but those intimately associated with them will be

able to make any sense of them. Particularly in miniaturized products, the high

repair costs make replacement a sensible option. Hence there is little incentive to

publicize the DRCS software or to expound upon it.



2.2 Availability of Tools


What tools are available to create a DRCS? We must take into account that
DRCSs come in many different forms, at many different prices. Examples are
remote volume control, VCR cassette mechanism, numerically controlled






-19-

machines, etc. Virtually every one of these systems is highly applications-

specific, although some (i.e. in the case of VCR cassette mechanismss, camera

auto-focus system, etc.) have become standardized due to the immense volume

in which they are sold. Most of these are small systems which have little or no

direct user interface. They perform a rather indirect function, in that the user's

exposure to the complex actions) of the machine is masked within a simple

action (e.g. focus the lens, eject the videotape, etc.). As such, there has been little

impetus to extend the DRCS architecture beyond whatever is most expedient for

the developer. The DRCS has in many applications become an "enabling
element" of emerging new technologies.

This approach is acceptable if the product will remain static over its lifetime.

Such is the case with Nippon Kogaku, Inc. (Nikon), whose camera models do not

change over time, and whose offerings undergo leaps in functionality only when

a new model is released. In this situation what is most important is that the

product come to market quickly, function properly and be reliable. To this end,

most well-managed companies have an in-house software programming

methodology which seeks to reduce programming and software management

effort and increase return on software investments by borrowing heavily from

previous work. The familial resemblance of the user interfaces of several

automotive, consumer and professional product families is an example of this

practice.

Efforts are made to facilitate code migration from 8&16-bit (e.g. Z80, 68HC11)
to 32-bit (e.g. 68000, 683XX, embedded PowerPC) applications [Mot82]. To a

great extent the systems designers are familiar enough with newer hardware

developments not to be discouraged when starting a new design. Designs tend

to be evolutionary, rather than revolutionary. This is particularly true because







-20-

experienced software developers prefer to recycle old, product-tested code than

write new code.

With this pre-existing bias towards re-using parts of older designs, the

software and hardware development tools3 used to create DRCSs are necessarily

a mixture of commercially available tools [McC88], in-house expertise and, on

rare occasion, recent systematic advances. The focus of the commercially

available tools does not currently include DRCS issues, as there is no established

standard -- instead, these tools focus on well-known issues in software and

hardware systems design.



2.3 A New Approach Must Be Sustainable


The shortcomings of such an approach are brought vividly to the forefront

when user interface and interconnectivity/support issues arise. Within the audio

market, for example, there have been numerous proposed standards [Que88], of

which only a few have survived. Unfortunately, the quality of the standard has

little to do with its expected lifetime, and market forces often play large and

sometimes unexpected roles. Witness the Philips Digital Compact Cassette

(DCC) vs. Sony MiniDisc (MD) fight -- many plants that were created for these

much-heralded replacements for analog cassettes are now idle [Nor94]. As

performance requirements increase, inefficient approaches are either abandoned,

survive only at high cost, or are heavily revised to keep up within a niche

market. It would be highly beneficial to have an approach that was resistant to




3 One must distinguish software tools like compilers and debuggers, which help develop the
product, from tools like kernels and libraries, which are an integral part of the system's
software. The correctness and the performance of these "embedded tools" can be critical to
the success of a system, and they must be chosen with care [Win93, Cat93].







-21-

or even obsolescence-proof against the inevitable changes that new technologies

bring into the performance arena (resolution, speed, bandwidth, etc.).

Previously one might argue that, as computer-based systems and their

attendant software are evolving so rapidly, any proposed software structure

must rapidly become obsolete, or at least not be applicable to the next-generation

product. We can now counter this by two factors -- the rise of platform-

independent programming [Mey93, Neu91] and the gradual blurring of

hardware-platform distinctions [Shi94]. There is optimism that both of these

trends will protect intellectual effort and greatly preclude the re-writing of

software for new platforms, as many software systems can now be ported from

one processor family to another with minimal or no effort.4 Thus the time taken

to carefully structure DRCS software, and the experience gleaned from its

performance over time, will not be lost when creating the next-generation

version. Investing now in a framework for DRCS software will aid the

programmer in porting to newer, faster and more powerful hardware.5



2.4 Chapter Summary



In order to be useful, a new approach to DRCS software must have tangible

benefits. Also, the resulting design must be of high quality. As systems

designers, we attempt to create "a good set of trade-offs from competing




4 Of course, hardware differences (e.g. with plug-in cards) must be resolved when porting from
one platform to another.

5 Note that the actual coding of the DRCS framework will most likely be done in a portable
language (e.g. C), and hence will always be reasonably portable [Hor90]. From a portability
standpoint, the DRCS framework excels in helping the programmer support hardware on a
new platform, as it insulates the vast majority of the code from hardware-specific
compatibility issues.







-22-

objectives" [McC93, p. 165]. We will address that part of a DRCS's software

which defines its functionality as the user sees it. This software will link the

system's inputs to its outputs in a manner dictated by the system's functional

specifications. In order to do this, the system must already have:


a complete and error-free hardware design,6
a basic software kernel that handles internal and external
communications, interrupts, memory management, etc.,
memory available for code and data, and
functional specifications for the User Interface and all I/O
activity.


In designing our DRCS software structure, our objectives are that the

software exhibit the following external characteristics [McC93]:


correctness
usability
efficiency
reliability
integrity
adaptability
accuracy
robustness


Additionally, for the programmer's benefit, the software should exhibit these

internal characteristics:

maintainability
flexibility
portability


6 Often this is verified through simple test code.






-23-


reusability
readability
testability
understandability


The method we present uses a well-defined structure to facilitate the creation

of a DRCS


which is structured and easy to understand;
which can easily be extended, interfaced to, analyzed, monitored
and/or built;
which is accommodating to the inevitable changes and extensions
that will be made to it over its lifetime in order to remain
competitive;
which is easy to maintain (from a software perspective);
which isolates each part of the system from changes made
elsewhere;
whose hardware can be changed in number and type without
fundamental changes to the underlying software structure; and
with low replacement costs.


The DRCS software structure developed in the following chapters satisfies

these criteria. Along the way, certain issues of software quality assurance and

tradeoffs with respect to optimization must be addressed. We will show that this


structure fulfills these objectives.
















CHAPTER 3
DESIGNING TOWARDS DIGITAL CONTROL


Users who find a well-designed DRCS easy to operate may assume that it was

easy to create. However, in the design phase, it is not at all immediately obvious

to the programmer how the DRCS software should be structured to support

DRCDs on both the input and output sides of the system.
In this chapter we present a simple electronic circuit, as it develops from one
with a direct link between the user and the system's actions to the corresponding
DRCS architecture with its attendant parts. This progression is best illustrated by
example. We will see how the final DRCS reflects these developments.



3.1 Direct Analog Control


The example is one of simple audio volume control, in which the user moves
a fader (a linear-throw, log-taper potentiometer) up and down to control the
input signal level applied to a fixed-gain amplifier driving a loudspeaker. This
example system is shown in Figure 2.

Here we have a user interface (the fader) which controls the volume of an
audio signal. It is an inexpensive and simple system, but provides no means of
obtaining any information about the system (e.g. total signal-chain gain or level
setting) other than a visual indication of fader position (and hence signal gain)
and an audible indication of output level. There is no form of remote








-25-

controllability in this system. In this system the behavior of the system is
dictated by the physical (here: electrical) characteristics of the devices employed.






I-'1 -J ---_ \




Figure 2: Example System #1 -- Simple Audio Volume Control


In this example some relevant characteristics are 1) the resistance values of
the fader over its full range, 2) the gain, frequency response, noise, etc. of the
amplifier, 3) the sensitivity of the loudspeaker and 4) the (power) supply
voltages. Clearly, no software is needed for such a system.



3.2 Adding Indirection to Analog Control


The next step, as shown in Figure 3, is to add a level of indirection so that the
volume pot is now controlling the gain of a voltage-controlled amplifier (VCA)
instead of attenuating the signal itself. Conceptually this is the largest leap in the
transition towards digital remote-controllability, for a remotely controlled device,
the VCA, has been added.
This system functions identically to system #1, with the position of the fader
giving an indication of the signal gain. Used alone, it has no real benefit over
system #1. However, it allows the possibility of additional controlling elements
(e.g. a separate volume trim) due to the fact that the amplifier's gain is now a








-26-

function of the control voltage Vc. No information about the system is revealed

beyond that of the first example. Note also that certain constraints are placed on
the fader's taper (log) and on the VCA in order to map the user's positional input
to the desired system signal gain. No software is needed for this system, either.




A=f(Vc )



S..re f v c



I-------------- -



Figure 3: Example System #2 -- Audio Volume Control with VCA



3.3 Replacing Analog Control with Digital


By replacing the VCA with a digitally-controlled attenuator (DCA) and fixed-
gain amplifier, we move into the domain of digital control of the analog signal.
An interface from the user input to the DCA is required, and this is fulfilled by
an analog-to-digital converter which samples the position of the fader and
returns a corresponding digital word. Discrete control logic ties the two digital
devices together. This is shown in Figure 4.
This interim stage in the progression from direct analog control to indirect
digital control is of limited utility, primarily because the digital output format of
the ADC must be a match for the required input format of the DCA. In order to








-27-

be functionally identical to the previous example systems, together they must
present a voltage-to-level conversion that is very tightly defined, and is thus
rather inflexible. The designer will have to search for the appropriate hardware
to complete this design, and may be unable to do so if he wishes to have certain
characteristics (e.g. a "dead zone" at either end of the fader) that are not
supported by the chosen parts.




n Vout in of tA


a leef c ef

SADATA[0..n] control

logic




Figure 4: Example System #3 -- Audio Volume Control with DCA


We present this stage in the evolution of the system because the advent of the
digital control word (between the ADC and the DCA above) signals the arrival of
a level of abstraction, and hence a growing number of design choices, to the
design. For example, the length (i.e. number of bits) of the DCA control word
dictates the level-setting resolution of the design. We must also note that a
choice of linear or logarithmic ADCs and DCAs for this example results in
different data words corresponding to a particular level setting. As the number
of interconnected digital devices grows, the number of possible implementations
increases rapidly. This example system has digital devices without requiring any
software.








-28-


3.4 Adding pP and Memory Provides Full Flexibility


Due to their low cost, it has become common practice to add a digital

microprocessor (gpP) or microcontroller to designs of increasing levels of

sophistication. Using a gP to interface the various elements in Figure 4 enables

the system programmer to link these elements flexibly, unlike a hard-wired

design. What remains lacking in the above example is the notion of a storable
current state, but this is solved by the addition of memory to the design. We

cannot query the non-pP-based system as to its current configuration vis-a-vis
the user input and the signal gain. Interfacing with the outside world is greatly
facilitated by the gP's presence, as nearly all modern synchronous and

asynchronous communications hardware are supplied with gP interfaces
[Nat90].

Every gP executes a sequence of instructions, a dedicated software program.

Creating software for DRCS-type systems is typically referred to as embedded
systems programming. Generally a few years of programming experience is
required to approach such systems, as familiarity with the system hardware
(particularly I/O) and the more advanced issues of assembly language and real-

time programming are required [Bec93]. A successful embedded system
program incorporates a combination of many blocks of code; a kernel (perhaps
with a proper operating system (O/S)), interrupt routines, memory managers,
device drivers for I/O, etc. All of these concepts will be familiar to a
programmer seeking to create a DRCS. Since these components are common to
the vast majority of embedded systems, there are plenty of ready-to-use software

packages [Buy94] and books to aid the programmer. What is not readily








-29-

available is a structured method for tying the I/O devices to the rest of the

system to create a functional system -- this is where the programmer's

competency (and imagination) are tested.

With the addition of a processor, the hardware complexity attendant in a

design can often be exchanged for dedicated software performing hardware-like
functions. Programmability is added to a design to improve flexibility, lower

cost, and provide for functions that were previously not possible. Structured
programming [Led87] suggests that by following a set of rules governing the

behavior of program activity (essentially forbidding exit and goto statements)

program control flow is constrained in a manner that is beneficial both to the

programmer and to the program. By adhering to a set of well-laid-out rules

governing the interaction of a DRCS's gP with its I/O devices, the programmer

has the missing tool -- a template of sorts -- to complete the system's software.

If costs dictate that we minimize the number of gP's in a more complex

system (say ten faders and attendant signal paths instead of just one), it is likely

that a single gP will have to service multiple user inputs. If, for example, two or

more of these inputs are somehow linked together to control a single DRCD at
the output, the pP quickly finds itself in the position of having to assimilate and
make decisions on a large amount of user input data to properly control its
DRCD (in this case, the DCA). This common situation can quickly exhaust the
tP's on-board resources. In the following chapters we will show how this

situation can be resolved through the use of a carefully-organized, memory-
based software structure that makes extensive use of the current state or state

variable.

This system's response must be sufficiently fast to prevent any noticeable

delays between the movement of the fader and the change in signal gain. The

sampled-input nature of the DRCS can of course lead to some aliasing problems,







-30-
so we must typically structure the system to be fast enough for the application
and to have ample dynamic range. This on-the-fly mode of operation is typical
of DRCSs, and the structure of DRCS software can greatly impact the system's
ability to continue running in real time when user inputs are changing at a
seemingly high rate. The gIP-based system is shown in Figure 5.


'V


Figure 5: Example System #4 -- Digital Remotely Controlled
Audio Volume Control System

In Figure 5 we see that the addition of memory completes the example and
enables the system to incorporate information pertaining to its current state.
Externally, this system functions identically to the first example, but we have
now achieved some indirection through the flexibility to map any position of the
user input to any desired gain (through a look-up table in the memory). We can
choose a linear taper for the potentiometer because our concern is limited to
mapping the position of the fader to the signal gain. This means that the pIP's








-31-

task is to read the user's input position and write the control word to the DCA in

order to set the amplifier's signal gain. This also means that a variety of

processing "tricks" can occur between the user input and the amplifier gain -- for

example, the gP can apply hysteresis to the fader position coming out of the A/D

converter so that the amplifier's gain does not "wiggle" unnecessarily due to

noise in the fader. The key to this additional functionality is the addition of a

programmable element, the [tP, and its software. Note that we now have two

entirely different representations at the A/D and D/A interfaces -- at the A/D

we have a digital word indicating position (and, through table look-up, level),
and at the D/A we have a digital word indicating gain as a function of the
amplifier's make-up.
It is important to note that the nature of the DRCDs in a DRCS can be

completely hidden from the user -- he or she is usually only concerned that the

system functions correctly within its specifications. The details of the actual

device (or devices) used to implement the DRCS's function are solely the concern

of the system designer.



3.5 Chapter Summary


A powerful DRCS can be built up from systems similar to that in Figure 5. A

DRCS will have a minimum of two DRCDs, and is likely to have differing
numbers of DRCDs at its inputs and outputs. The number of processors used
will depend on the number of DRCDs required, the task and the power of the
processors) used. The software we are concerned with is the software that runs

on these processors. There may also be additional processors not directly

involved in the I/O chain, but they are not part of this discussion.








-32-

Sole reliance on the native format of the interfaces to the DRCDs employed

limits design freedom. This is not to suggest that certain designs are impossible

-- rather, a particular choice of hardware constrains the system's behavior to be

dependent on physical characteristics of the chosen devices. For example, a

particular D/A converter may have the desired LSB accuracy specifications, but

the lack of a Gray-code scale [Hor89] interface may preclude its use in a

particular design. Our goal is to create a collection of software constructs that

allows the DRCS designer to integrate any devices he wishes to employ, and to

do so efficiently.

Through this four-step example we have taken a simple, direct, stand-alone

circuit and turned it into a digitally-controlled system with indirection and

attendant complexity. We have shown why a designer would create a gP-based

system with digital remotely controlled devices. As discussed above, apart from

the flexibility obtained by divorcing the user input from the system output and

inserting a digital process between them, there are a multitude of scenarios in

which the system realizes substantial user-oriented benefits, such as:


storage of current status, with ability to query,
instant recall ability (snapshot),
record and playback abilities (automation),
remote (machine) controllability, and
macros, etc.


In the following chapter we will show how to create the software that enables

the system features listed above.















CHAPTER 4
THE DRCS SOFTWARE STRUCTURE



4.1 Division of Software in the DRCS


Figure 6 shows the DRCS with m inputs and p outputs illustrated from a

software organization viewpoint.

The hardware layers contain devices that are unique to the particular DRCS.1

The workings of the software layers form the basis of this dissertation. Every

complex software-based system requires a directed and concerted programming

effort to bring it to fruition. Whereas some parts of the system's software (e.g. an

operating system) may be purchased or obtained in the public domain, others

will have to be designed. A DRCS requires software interfaces to its DRCDs, as

well as a body of software between its inputs and outputs. All of this software

must be designed, and later tested and debugged -- the actual time spent coding

is likely to be quite small [Bro75]. Unfortunately, good design takes time, may

require much trial and error, and has no guarantee of success.


Design is a sloppy process. It's sloppy because the right answer is
often hard to distinguish from the wrong one. If you send three people
away to design the same program, they might easily return with three
vastly different designs, each of which is perfectly acceptable. It's sloppy
because you take many false steps and go down many blind alleys -- you
make a lot of design mistakes. Design is also sloppy because it's hard to


1 The flow of system input through the output DRCDs is required in those DRCSs that process
non-digital data.


-33-







-34-

know when your design is 'good enough.' When are you done? [McC93,
p. 161]


Figure 6: Layers within the DRCS


It is precisely this sloppiness that we wish to avoid. The lack of standardized

design tools for such systems suggests that they do not lend themselves to

straightforward solutions. We feel that this is not the case. The evolutionary

design of our modular DRCS software structure has allowed us to implement

and evaluate many different approaches to this problem. The initial structure

was subsequently tailored through incremental changes to handle a wide range






-35-

of operating conditions and requirements while still maintaining a high level of

performance. The resulting DRCS has many internal features, the necessity of

which is not obvious if taken in isolation. This DRCS structure should be viewed

as a method towards creating a working system while minimizing software

design and planning times. It will become apparent that there is considerable

leeway within the structure to optimize portions of DRCS code for particular

goals; "optimizing for size" refers to minimizing the size (number of bytes) of the

system's object code, and "optimizing for speed" refers to creating code that

requires the fewest clock cycles to complete.

Since the DRCS represents a melding of hardware and software, we must

address issues concerning both parts of the system. We will first address the

hardware issues that impact system software, for once the hardware is suitably

well-integrated into the design, it can be all but forgotten and all attention can

turn to the software.2

DRCDs are present at both the inputs and outputs of the DRCS, and

respectively present and accept digital control data in a wide range of formats.

The division of software in the DRCS is critical to the system, for by creating

well-defined software interfaces for the DRCDs in the design, we isolate the tasks

of collecting and disbursing control data from the task of processing that data.

With this isolation each layer can be optimized independently.











2 In our experience, once the hardware interface was working, it rarely changed, and very few (if
any) modifications were made to it over the course of the software's development.






-36-


4.2 Layers Within the Framework


As shown in Figure 6, we divide the system software in three -- the input,

logical and output layers. It is helpful to view the input layer software as

depositing into the logical layer information that represents the status of the

system's inputs independent of the characteristics of the devices used. The

output layer software can be thought of as extracting information to the output

devices for the purposes of effecting system functions and providing feedback to

the user. The software in the logical layer between them controls the flow of

information from input to output. Note that since the inputs are sampled, there

is never a direct path from the inputs to the outputs.

Associated with each layer is a representation of the state (or value) of its

digital data. Some layers provide us with leeway in defining the representations;
others do not. Prior to specifying the software of the I/O layers, in Table 1 we

present the terminology involved.

Table 1: Layers and Representations

Layer Representation Constrained By Design Freedom
input input variables input DRCDs some
logical state variables standardized format near-total
output DRCD native output DRCDs none


The previous chapters' example has illustrated the general lack of flexibility
with input format and DRCD native representations. This inflexibility arises

from the design of the devices employed, and is inescapable. Rather than
viewing this as a obstacle to the DRCS programmer, we will instead seek a







-37-

means of defining the software in the input and output layers so as to avoid the

limitations imposed by the DRCDs.3



4.3 DRCD Software Lavers


4.3.1 The Input Layer


Input to a DRCS comes in varied forms. We need a clear view of the defining

characteristics of the devices in the input layer before considering the structure

for the logical layer. For example, consider the input devices listed in Table 2.


Table 2: Input DRCD Characteristics

Interface Choices for
Input Device Type Characteristics User Perception Interpretation
Knob or Fader resolution, range position, inferred incremental or
function absolute value
Key, Button or single- or multi-bit setting (perhaps ON, OFF or value
Switch value context
dependent)
Key Matrix multi-bit (format e.g. as (none) or value
conversion likely) alphanumeric
device


It is critical to understand how the input devices are perceived by the user

(within the context of the particular system), and what sort of digital information

the device presents to the rest of the system. Even when the user is presented

with a variety of input devices, we need to minimize the number of different

interpretations. A good example can be made with switchgear -- each switch, in




3 We won't yet discuss the rare case when the input representation can map directly to the
required physical representation.






-38-


its active position, should return the same value to the DRCS. Any deviations

from this are likely to waste either code space or execution time. Sometimes this

may require intervention in the early stages of the system's hardware design to

ensure conformity. Of course, each input device must also be uniquely and
unambiguously addressable within the DRCS.

Some examples of input devices and possible logical representations in a

system using 16-bit data words are listed in Table 3.

Table 3: Input DRCD Examples

Device Type DRCD Format Logical Representation
ON/OFF switch OFF: xxxxxxxx xxxxxxx0b OFF: 0
ON: xxxxxxxx xxxxxxxlb ON: 1
16-position rotary 1st pos.: xxx0h 1st pos.: 0000b
switch 2nd pos.: xxxlh 2nd pos.: 0001b

16th pos.: xxxFh 16th pos.: 1111b
vertical fader top: xxxx0000 00000000b top: 0000 00000000b
representing .. ...
position, sampled bottom: xxxx1111 11111111b bottom: 1111 11111111b
via 12-bit ADC
potentiometer full ccw: uuuuh mode 1: 1
selecting one of ... mode 2:2
three modes, mid-range: vvvvh mode 3: 3
sampled via n-bit ...
ADC (n>2), 2n full cw: wwwwh
discrete values


The first three examples are straightforward and safe -- they are the direct

outputs of the DRCDs themselves,4 presented one-for-one on a multi-bit data

bus. The fourth example is quite different, in that it no longer bears a direct

relation to the DRCD, but is rather a filtered version of the ADC's output. This


4 Here we consider the DRCD to be the combination of the input device and the ADC.







-39-

filtering is performed in software, and produces a representation that is

convenient for us when applying the desired action of the input device to the

system. In pseudocode, the software filter for this example could look something

like:


if (0 <= DRCD value < 2n/3) then return (1)
else if (2n/3 <= DRCD value < 2n+1/3) then return (2)
else return (3)


Some input devices will require only the simplest of filters, namely:


return (DRCD_value)


There are three steps necessary for the creation of the input layer software:


create the representations that relate user action to system
activity,
identify the DRCDs and the values they present to the system,
and
create filters to translate the DRCD formats to logical
representations.


By characterizing the data format of the system's input devices, and

maintaining conformity among them, we can classify them into types and

associate them with particular input-layer filters. This organization contributes

to sound design practice, because too many DRCDs can introduce headaches

quite apart from the issues we address here. Each input's ultimate representation

(i.e. the output of its filter) should be expressed in terms that correspond to the

user interface and the functionality of the system. Reducing the number of

representations will naturally reduce the number of filters required. Virtual

DRCDs are discussed in a following section.






-40-


4.3.2 The Output Layer


The variety of DRCD digital interfaces is vast. As with the input layer, we

need a clear view of the defining characteristics of the devices in the output layer.

However, we are no longer concerned with the devices' user perception and

choices for interpretation, as the former is irrelevant with the device hidden from

the user, and the latter is strictly defined by the device and the (sub-)system

within which it resides. Consider the output devices shown in Table 4.

Table 4: Output DRCD Characteristics

Output Device (DRCD) Type Interface Characteristics
DCA word length, polarity, effect on circuit
Lamp Driver or LED polarity
Relay polarity, monostable or bistable
Pixel-Based Display x- and y-bounds, pixel color
requirements



As with the input layer, observe the same caveats when organizing the

devices in the output layer. Minimize the different types of output devices used,

and standardize their connections to the system. Once the output devices are

identified, collect them into groups with identical interfaces. Note that this does

not imply that identical devices will be only grouped together -- within the larger

context of how the devices are applied in the DRCS, there may be several
different groupings for a particular type. For example, identical momentary

switches may be used in both an operator control panel and within foot switches

-- in the control panel, they may toggle something on or off, but in the foot

switch, they might keep a motor running only as long as the switch is depressed







-41-


(i.e. a "deadman switch"). The raw specifications of a device are irrelevant;

rather, the emphasis lies on how the DRCD is used within the DRCS.

Some examples of output devices and possible logical representations in a

system using 16-bit data words are:


Table 5: Output DRCD Examples

DRCD Format Logical Representation Device Type
OFF: xxx0h OFF: Ob relay, latching
ON: xxxlh ON: lb or non-latching
0.32: xxFFh 0.32: Od Q (i.e.
0.40: xxC9h 0.40: Id 1/bandwidth)
...... control of 2-
9.00: xx09h 9.00: 14d pole state-
11.6: xx07h 11.6: 15d variable filter
via DCA
'0': xxxxxxxx 11000000b '0': 0 7-segment LED
'1': xxxxxxxx 11111001b '1': 1 digit display

'9': xxxxxxxx 10011000h '9': 9



In comparison to the filters of the input layer, in the output layer we map

easily understood logical values to values suited to DRCDs. For example, in the

7-segment LED driver example, the pseudocode filter might look like:


switch
case
case
case
case
case
case
case
case
case
case


(logical value)
'0': output (7-segment
'1': output (7-segment
'2': output (7-segment
'3': output (7-segment
'4': output (7-segment
'5': output (7-segment
'6': output (7-segment
'7': output (7-segment
'8': output (7-segment
'9': output (7-segment


display,
display,
display,
display,
display,
display,
display,
display,
display,
display,


COh);
F9h);
A4h);
BOh);
99h);
92h);
83h);
F8h);
80h);
98h);


Once again, some output devices may require only the simplest filters. We

will follow a top-down design methodology when coding for the DRCS. What







-42-

holds true for hardware design is also true for software that interfaces to

hardware:


We must approach hardware design problems from the top, remaining
aloof from hardware commitments as long as possible. We must
thoroughly understand the problem and must let the problem
requirements guide us to suitable hardware, rather than allow premature
hardware selections to force us into unsuitable design decisions. [Win80,
p. x]


Creating the output layer software requires these three top-down design

steps:


create the representations that relate user action to system
activity,
identify the DRCDs and the values they present to the system,
and
create filters to translate the logical representations to DRCD
formats.


4.3.3 The Logical Layer


Creating the input and output layers using the recommendations above may

be, in some instances, nearly all that is required. In cases where the

representation chosen is such that a direct one-to-one mapping exists between

input and output devices, all that is required of the logical layer is timely

execution of the associated filters. In the above examples, the ON/OFF switch

and the relay employ the same representation, and hence can be directly

connected.

As systems grow in complexity and other factors (e.g. cost and density) come

into play, this neat one-to-one mapping becomes the exception rather than the






-43-


rule. This may occur, for example, when multiple inputs control a single output

DRCD. In this case an interim layer of processing may be necessary, combining

one or more input representations into one more suited to output devices. In

another example, a single output control may affect both output control and

output display hardware, and hence a means is required for grouping the

execution of these related filters. These and other topics will be discussed

shortly.


4.3.4 Summary


By creating software filters for the input and output layers we isolate

ourselves from the details of the I/O devices used, yet in no way compromise

our ability to control the DRCDs. Integration of the DRCDs (hardware) into the

design is complete when the filters all exist and are known to be correct. The

filters protect the rest of the DRCS from the needless complexity that arises from

the wide variety of DRCD control data formats. Chosen representations, with

their associated data, form the interface between the logical and I/O layers. The

data in the representations fully describe the state of the system's input and

output DRCDs. The format of the representation should be closely associated

with the control function being performed. A filter is required for every different

combination of DRCD format and representation. Steps can be taken during the

hardware design stage to minimize the number of filters required. The logical

layer passes control information from the input to the output, and may process it

as well.






-44-


4.4 The Structure of the Logical Layer


With the DRCS's input and output layers narrowly defined to provide

interfaces to the system's DRCDs, the rest of the system's functionality must, by

definition, arise from the actions of the logical layer. Having established the

need for and the utility of input- and output-layer filters, we must investigate

more deeply the role of the logical layer in the design of the DRCS. Niklaus

Wirth, in his seminal book [Wir76], enjoins the reader to envision programs as

the combination of algorithms and data structures. The programs that act within

the DRCS's logical layer are dependent on data structures employed, and the

performance of the system can be deeply affected by the choice of

representations in the logical layer. In this section we develop the software for

the logical layer.


4.4.1 State Variables


As mentioned in the previous chapter, we define the state variable as simply a

representation of the current state (or "value") of some element in the DRCS

system. Without the notion of a storable current state in the DRCS (in whatever

form), we are severely limited in terms of the functionality that we can impart to

the design. Not only does the current state allow us to query and display the

status of the system, but it also can be combined with previous and next states,

which may prove to be useful. The choices that confront us as system architects

are which elements and what format to use. We will review the options in the

volume control example of the previous chapter.






-45-

We can think of the user input as a voltage, an absolute position, a relative

position, a gain, an attenuation, etc. Choosing a voltage as our representative

needlessly ties the format to a representation with which the user has little or no

link. The other possibilities are more viable, but at this stage a qualitatively

superior choice is unclear. In fact, we can choose from a wide range of different

representations from the input layer for the gP's "view" of the volume control

fader.

We must remember that output-layer DRCDs, on the other hand, offer no

choices whatsoever -- the system must present the DRCD with specific control

words that the DRCD understands. This "end-result" representation is usually

inextricably tied to the design of the DRCD and is often in a form unsuited for

quick human comprehension. In the previous DCA example, the system must

supply the DCA with values between 2n+1-1 and 0, which in turn attenuate the
signal by 0 dB to -- dB, respectively. The word length of the representation is

tied directly to the DRCD. Note that as this representation is the only one

suitable for the DRCD, it must always be present in some form or another in the

DRCS, even if only fleetingly. This leads us to the first possible logical-layer

representation at our disposal -- the DRCD native format representation. Such a

representation would require only the simplest of output-layer filters.

The DRCD native format is usually so far removed from anything a user

would understand5 that its usefulness is severely limited, except for one case to

be discussed later. If we were to use the DRCD native format to supply, say, a

system monitor reporting on the signal gains throughout the system, our

software would have to translate the representation to something more readable

before it was of any use to us. Also, such a representation requires a priori


5 See the volume control example in Chapter 3: "04Clh means cutting the level by -38.02 dB?!?"






-46-

knowledge of the nature of the DRCD itself! This is highly disadvantageous,

complicates the system tremendously, and fails to isolate the rest of the system

when an DRCD is changed or upgraded to one requiring a different control

format. Also, each instance of combining user input from DRCDs with different

representations requires code that is unique to this particular combination,

precluding the use of standardized routines to handle more complicated input-

to-output mappings.

We must therefore conclude that the DRCD native format representation is

not a good choice for the central representation of the DRCS's current state. Since

the workings of the DRCS must be transparent to the user, the system architect

has considerable freedom in choosing a representation for use in the logical layer.

It is, however, instructive to step back for a moment and take a look at what the

DRCS is doing. Recall that the function of the DRCS is to translate user input

into control output. In many DRCS systems, the user is the driving force behind

all DRCS actions! Choosing a representation that the user understands has

several advantages:


Querying is simplified because the state variable is already
formatted.
The actual format (e.g. signed 16-bit in 1/10dB units) can be
chosen to fit comfortably within the confines of the processing
power used.
All other inputs (internal and external) can be standardized to the
same format, reducing or eliminating the need for extra
translation.
Since the DRCD's native format is unlikely to be user-
understandable, some translating is already required.







-47-

A third option for the representation revolves around the physical nature of

the user input (e.g. position of user control). This shares several of the

disadvantages of the DRCD native format, but does have a marked advantage in

one area, also to be discussed later.6 Also note that choosing neither the user

input format nor the DRCD format representation means that some part of the

system may have to perform format conversion on the system's input and/or its

output. While format conversion will invariably detract from system

performance, parallel hardware or software format conversion can be employed

in both serial and multi-processor machines to yield very substantial speedups

[Abu86].

In summary, the best representation for the logical layer is neither one taken

directly from the input layer, nor one taken directly from the output layer.

Instead, a representation that is translatable to those of the input and output

layers affords us flexibility and enhances the utility of the system by being as

close to the user's perception as possible. Maintaining the entire set of DRCS

representations in memory, over time, provides us with a means of monitoring

the state of the system. An overview is presented in Table 6.

Choosing a state-variable representation for the logical layer completes the

specifications for the input- and output-layer filters, and frees the designer to

concentrate on the additional functionality provided by the logical layer through

its state variables.


6 See Chapter 5.







-48-


Table 6: Comparative Advantages of State Variable Representations

Representation Advantages Disadvantages
tied to input DRCDs or input and output filters often difficult to
tied to output DRCDs are simple comprehend
DRCS not insulated from
hardware changes
DRCS requires
translators between
representation and
output or input DRCDs
storage requirements
dependent on device
interfaces
external queries require a
priori knowledge of
DRCD particulars
format of input DRCDs
unlikely to match those
of output DRCDs
tied to system behavior number of may require many
representations can be different input and
kept to a minimum output filters
easily comprehended
without regard to
physical constraints
hardware changes
require only new
corresponding filter(s)
complete freedom in
choosing format
no translations required
when combining data


4.4.2 Filters and State Variables Define the DRCS


It is important to realize that state variables can represent a minimum of

information with which to control the DRCD. In the example of Chapter 3 we


can summarize the entire system by the simple statement







-49-


"state variable signal gain = xx.yydB"


Given that the relationship between the input fader and the signal gain, as

well as the relationship between the prescribed signal gain and the DCA control

word, are implicit to the system, this statement fully describes this simple DRCS.

As an example, in order to obtain the fader position we can map the signal gain

to the fader position via a reverse table lookup, and a forward table lookup can

be used to find the DCA control word.

In order to structure the system and avoid ambiguity it is important that the

state variable's format be one that has function-like behavior, i.e. in this example


signal gain = s[fader position]

DCA control word = a[signal gain]


so,


DCA control word = a[ signal gain = s[fader position]]


and


fader position = f-[signal gain]


The functions s[] and a[] above are of course the input- and output-layer

filters, respectively. As long as the functions s[], a[] and f[] exist, the state

variable will fully describe the system. The transitivity implied above is






-50-


guaranteed to exist by virtue of the same logical representation being the output

of the input filters and the input to the output filters.

The relationships above are clearest in those situations where a single input

device is mapped directly onto a single output device. In cases where the

mapping is not one-to-one, the functions above become functions of multiple

variables, to be discussed later. Note that the state variable occupies the only

place in this input-to-output chain where the system architect has some

discretion as to the format used. This abstract quality of the state variable is very

important. This further reinforces the importance of picking the right

representation in the first place.

It should now be apparent that a DRCS system can be constructed in which

the state variable is the only representation of the system's current state that need

maintain a temporal existence. This is because the current values of both the

input and output can be obtained solely and quickly, via the functions above,
from the state variable.

We conclude that in a large DRCS, composed of many smaller elements,

independent or interacting, a necessary and sufficient set of parameters that

describe the entire system's state is composed simply of all the state variables,

appropriately labeled. We refer to these parameters as the current state.
Experience has shown that the memory requirements for state variables are often

a tiny fraction of the total memory requirements for a larger system.


4.4.3 State Variables Enhance Code Modularity


The abstract quality of the state variable provides the systems architect with

the opportunity to create modular code. If organized properly, the modularity of
the functions that interact with the state variables and effect the input-to-output







-51-

chain can be used efficiently in a variety of DRCS scenarios. In this section we

will fully define how the input- and output-layer filters interact with the system's

state variables. This interaction leads to the independence of the functions from

one another.

For the input and output layers, for each DRCS I/O function, we propose a

coding structure built around three simple functions: set[], act[] and show[], each

of which is tied directly to its associated state variable. These three functions

correspond to the input- and output-layer filter previously described. Set[] is the

input-layer filter for all inputs, act[] is the output-layer filter for the machine

interface, and show[] is the output-layer filter for the user interface.

The set[] function's sole purpose is to translate user (or other) input into state

variable form. In effect, it projects new user input onto the DRCS's current state.

For safety reasons, some bounds and/or validity checking should be performed

at this point. The set[] function has no impact in the system beyond this action.7

The set[] function may read and write the state variable.

The act[] function translates the state variable into a form suitable for the

corresponding control output DRCD. It has no knowledge whatsoever of the

status of user input -- it can only "see" the state variable, which defines all of its

actions. The act[] function may only read the state variable.8

The show[] function is analogous to the act[] functions, but affects user

interface output DRCDs. Through the show[] function we are able to indicate the

status of the system to the user in a form that is easily comprehended. This is
required in instances where the input user interface employs a DRCD that is




7 Commands use set[] see command section.
8 Except in cases where a conflict between two or more state variables is detected -- in that case
act[] may (over)write state variables see Appendix A.






-52-

separate from the input device in order to provide visual or other feedback. The

show[] function may only read the state variable.

In order to create a working DRCS, we require a mechanism in the logical

layer to link the input and output filters. This we refer to as the command action,
and it is the set[], act[], show[] sequence. A DRCS system may require one or

many command actions to map user input to DRCD actions. Each command

action is usually associated with a single state variable. A DRCS that solely links
input activity to output controls need implement only command actions in its

logical layer. The interaction of these three functions and the associated state

variable is illustrated in the example below:


chag input DRCD e Input
User F] TIn-ut
Interface [ J state variable
~I3-tD-c-Ishow[lJ act[]
-- output DRCD show[] act[] control DRCD



Output


Figure 7: Command Action Flow


Note that these three functions are all independently callable. The thread
followed when an input changes is therefore

set[state variable, new_value]
act[state variable]
show[state variable]







-53-

where the order of act[] and show[] could be interchanged if necessary.9 The

syntax for calling a command action is


command[argl, ..., argn].



and is called the command. If all that is required of a command is the ability to

redefine the entire state variable, then a single (perhaps multi-byte) argument

will suffice. In those cases where additional control over the state variable is

desirable (e.g. the ability to set or reset particular bits in a multi-bit state

variable), a multi-argument syntax may be required. A command syntax can

even be developed to accommodate a variable number of arguments. Whatever

the command's syntax, there is one and only one command directly associated

with each state variable.

A DRCS that is organized into multiple, similar sections or channels will

require a more sophisticated scheme for allocating unique commands to its state

variables. A hierarchical approach allows for many software components to be

standardized, thus reducing code size and improving reliability. For a multi-

channel system, the command format might look like:


channel_number
function_name
command_name
subcommand_name
argi

argn


In a large system, hundreds of identical multi-bit controllers can be served by a

single subcommand (as above) as long as the arguments specify which of the



9 However, in this work we will always call act[] before show[], allowing us to make certain
assumptions about program flow.






-54-

hundreds of state variables to act upon. Alternatively, the hierarchy of the

command can make the specification of the state variable implicit through the

execution of the command itself.

Each input-to-output chain, and hence each command, may or may not use

both act[] and show[] functions, depending on the DRCS implementation. This

command organization is itself no more useful than a single function to achieve

the same end. However, other DRCS scenarios can make good use of this

organization. We will investigate these next.

Table 7: Summary of Modular Routines

set[] act[] show[]
corresponding filter input (UI or other) output (control) output (UI)
state variable access read and write read only read only
triggered by change in input change in state change in state
variable variable
special actions bounds checking conflict display of lock /
resolution unlock status


4.4.4 State Variables Form Snapshots


In a DRCS the collection of a complete set of state variables is called a

snapshot. The system's current state is represented by the current snapshot.

Snapshots are extremely useful. At the very least, they represent a compact, fully
defined configuration for the DRCS from which all other input-output
information can be obtained. We will explore some of their uses.
An important issue in DRCSs is resettability, the ability to re-configure the

system to some specified state as quickly and as synchronously as possible. With

this requirement follows the inevitable support of multiple snapshots within a







-55-

system -- that is, the user can instantly choose between many different

configurations with minimum effort. This is called snapshot recall.


address 1 state variable 1

address 2 state variable 2





address state variable


Figure 8: A Snapshot in Memory



When state variables are used and the input-to-output chain is organized on a

set[], act[] and show[] basis, snapshot recall is greatly simplified. It amounts to

the replacement of the current snapshot by a desired one (of same size and

format, etc.), and then calls to all the act[]s and show[]s involved. We may or

may not realize a speed-up over a system with single threads for all the input-to-

output relationships, depending on whether the single-threaded system

supported or was capable of the interim format of our state variables. What we

do gain immediately is synchronicity, the option of controlling the DRCD update

in a manner of our choosing. Once the new current state has been defined we

can call all the act[]s in our system in any order, and then follow that with some

or all of the show[]s.

Through the use of stand-alone output filters, snapshot recall can be

structured for synchronicity by coding it as:


(re-)initialize all state variables
act [state variable]
act[state variable]







-56-


act[state variablen]
show[state variable]
show[state variable]

show[state variablen].



By grouping the act[]s (high priority) and show[]s (low priority) together, the

delay between the invoking of the snapshot recall and the attendant changes in

the control DRCDs is minimized. The action of snapshot recall can thus be

biased towards the response of one group of DRCDs over another. This is

altogether different from the sequential command actions required to achieve the

same result:


set[state variable, new_value]
act[state variable]
show[state variablell
set[state variable, new_value]
act[state variable2]
show[state variable]

set[state variablen, new_value]
act[state variablen]
show[state variablen]



The system follows this sequence of actions whether or not the command

actions are split into filters or written as in-line code. Our scheme allows the

grouping of DRCD updates, potentially preventing unwanted effects wherever

multiple DRCDs work in concert. For example, an audio-control circuit may

require near-simultaneous left- and right-channel DRCD updates, and

undesirable artifacts may occur if the delay between the left- and right-channel

updates is too great. This is a marked advantage over simple in-line coding of

DRCS functions, and keeps code size small.

With the act[] and show[] routines the simplest way to initialize the DRCDs in

the system is to perform a snapshot recall. It is interesting to note that snapshot






-57-

recall can be optimized to call only those act[]s and show[]s whose state variables

have changed since the last snapshot recall. This will require some sort of

double-buffer state variable memory and tagging system.

When a snapshot is recalled, its state variables may no longer correspond to

the current user inputs. We call inputs in this state unlocked inputs. The break

with the user input that a snapshot recall introduces may require a means of

displaying the correlation between the user inputs and the system's internal state.

Unlocked inputs can be avoided altogether by separating the status indicators of
the UI from the UI's input devices. In this scenario so-called virtual controls
drive the system's set[] routines, and virtual display/indicators are driven by the

system's show[] routines. A DRCS with snapshot recallability also requires a

means of (re-)locking unlocked user inputs.

Some DRCS designers may be faced with the requirement of monitoring the

correctness of their systems) for safety reasons. Since the entire system

configuration is derived from the state variables, the current snapshot can be

sampled by an outside process for the purpose of detecting and correcting errors

in the system. This supervisory potential of the DRCS might help to avoid

catastrophic failures, notably in systems whose software was deemed error-free
by its designers, but was innocuously used just outside its testing envelope
[Inv93, Spa94].




4.4.5 Allocating State Variables


In a system with multiple DRCDs, where the mapping of input DRCDs to

output DRCDs is not simple, we must address the question of how to allocate the

system's state variables. Two issues arise: how to allocate those state variables







-58-

that are associated with particular DRCDs, and how to fit the associated state

variables within the memory provided. These issues are somewhat interrelated.

A DRCS may have one-to-one mappings or mappings of dissimilar order

between the inputs and the outputs, as illustrated in Figure 9.


2
m n 3 P
input m-3 set[] state act[] 4 output
DRCDs m-2 variables show[] ... DRCDs
m-1 p



Figure 9: Input-to-output Mappings in the DRCS


As an aid to allocating state variables, it is helpful to describe the DRCS as a

collection of the actions of its input-to-output functions. This is especially useful

in multi-channel DRCSs, where many system functions are duplicated

identically. Since our approach defines representations for state variables based

on system behavior (i.e. input-to-output functions), we now address the issue of

how to group related inputs, state variables and outputs together.
We will consider the case of a particular DRCS function, but it is equally

applicable to the whole DRCS. For a given function, there are two different ways

to allocate state variables; to tightly associate a single state variable with one and

only one filter of each type, or to loosely associate each state variable with one or

more filters, and hence DRCDs. The tight association is even applicable to more

complex DRCS functions, as illustrated in Figure 10.

While this means of creating DRCS functions benefits from predictably simple

filters, it is only applicable in situations where there is a direct 1-to-1

correspondence. It will increase memory requirements for state variable storage.

Such an allocation scheme is contrary to our goal of defining state variables in a







-59-

format which is independent of the DRCD characteristics. This scheme may also

have detrimental affects on the design of the system, as it restricts flexibility in

the hardware design stages. The inflexibility of this method of allocating state

variables is apparent.


chang input DRCD set state variable act[], show[] >control DRCDs

hg input DRCD state variable act showcontrol DRCDs

Sinput DRCD set[] state variable show[] control DRCDs
Sa -' function


Figure 10: A Mapping of a Single DRCS Function Requiring
Multiple State Variables


The alternative is to use a single state variable for a particular function. Only

one set of set[], act[] and show[] routines will be necessary, and each may interact

with one or more DRCDs. Some examples of this scenario are illustrated in

Figure 11.

These examples allocate state variables one-to-one with each DRCS function

as defined by the user interface. In other words, each input-to-output chain has

one and only one state variable assigned to it, and only one command. We are

led to conclude that in order to allocate state variables properly it is necessary to

associate them with the (high-level) functions of the DRCS, and not with the

numbers or characteristics of the DRCDs themselves. It is the focus on the

function, with its state variable and I/O filters, that is critical to the organization

and performance of our DRCS software.







-60-


chan npu DRCD t[] state variable shocontrol DRCDs
function


Figure 11: 1-to-1, 2-to-1, 1-to-2 and 2-to-2 Mappings of DRCD
Functions Using a Single State Variable



We must also address the different options for placing state variables in

memory. Again we have two options; to pack them into memory as tightly as

possible, or to freely allocate them in memory in a more convenient way.

Arguments can be made for each scheme. In the former, as shown in Figure 12,


address 1 state variable 2 state variable 1

address aa state variable
address variable 4

sv7 sv6 sv5



address state variable


Figure 12: Tightly-packed State Variables






-61-


we can minimize memory requirements by fitting the state variables in their

various representations into the minimum amount of memory. The

disadvantage of such a scheme is one of speed and performance -- all parts of the

system operating on state variables that share memory addresses with other ones

must apply masks to read or write only the relevant information they are

interested in. Bit-based operations could be used where the state variables are

binary in value. Performance suffers even more if we try to squeeze multi-bit

state variables into two or more distinct memory locations. This scheme also

negates the advantages of the "one state variable, one command." Finally, the

masking going on inside the system to support such compact state variables

must be made explicit to any process outside the system wishing to use the state

variables. These are serious disadvantages, and this scheme should be used only

when memory is at a premium. A notable advantage, however, is that
bandwidth requirements to and from the DRCS can be reduced with minimum-

sized snapshots.

The alternative is to locate state variables in memory as one would put

characters in a string, namely in fields of a contiguous memory block (see Figure

8). Naturally, this scheme does not minimize memory requirements for

snapshots, though the wasted space is unlikely to be excessive.10 Keeping the

DRCS state variables separate from one another does have several advantages,

which can be summarized by pointing out that any and all accesses of any type

by any part of the system incur no additional overhead when reading from or

writing to a single memory location. This is especially critical to those systems

without built-in read-modify-write instructions, for in some systems the required


10 The unused memory cannot exceed one addressable memory unit per state variable.






-62-


bandwidth to the state variables in memory can be very high during operations

like snapshot recall.

It is also worth noting that the limited range of allowed values of the state

variables may facilitate post-crash recovery by cleaning up solely the crash-

damaged state variables [Tay86]. However, this is hampered by the fact that

properly allocated state variables within a DRCS system are independent of one

another and can change radically from one instant to the next (e.g. due to

snapshot recall).

Table 8: Comparative Advantages of Snapshot Allocation

Advantages Disadvantages
strict 1-to-1 simple set[], act[] and show[] very inflexible
mappings filters affects hardware design
minimizes code memory rarely applicable
requirements increases number of state
variables
loose m-to-p universally applicable set[], act[] and show[] may
mappings minimizes number of state need to support multiple
variables DRCDs
easier to debug -- each increases code size
function fully described by
a single state variable
tight allocation snapshot memory where state variables are
(minimum-size requirements are reduced combined in memory
snapshots) system bandwidth locations, masking and/or
requirements for external bit operations are required
access are reduced to access them
external processes must be
aware of used and unused
fields within state
variables
loose allocation state variable accesses are increases size of snapshots
(maximum-size simpler
snapshots) simpler indexing of state
variables to commands






-63-


4.4.6 Reliability


The isolated scope of each state variables is chosen to wholly control one

clearly delineable DRCS function. This has two major advantages: first, that if
the validity of the state variable can be assured (outside the scope of this work,
but crucial for any system to be reliable), and the filters are known to be correct,

then the portion of the DRCS defined by this state variable is guaranteed to be

correct. Second, the isolation of the entire input-to-output chain of a particular

state variable means that the input-to-output chain can be created, tested and

debugged independent of the rest of the system, and once verified as correct,

need not be altered ever again. This localized activity of linking the state variable

to the remotely controlled device gives rise to a central rule in the DRCS: that

calls to act[] and show[] must accompany any change to the associated state

variable.

Also it should be noted that among state variables sharing the same decided-

upon state variable format, any error in code which employs the format should
manifest itself the same way wherever act[] and show[] occur, thus increasing the

odds of finding the problem. The worst problem areas vis-a-vis a breakdown in

the input-to-output chain are invariably where an isolated, unique format was

used and whose error was not discovered quickly due to the infrequent actions

of that part of the DRCS.






-64-


4.4.7 Summary


The DRCS requires software in its logical layer. Because it is isolated from the

input and output layers via filters, considerable leeway exists in creating this

software. This isolation is enhanced by picking the appropriate representation

for the state variables. Focusing on the user's perception and expectations of the

system helps us develop clearly definable algorithms (I/O filters) and data

structures (state variables) to achieve working programs (commands). We have

found that structuring the software in this manner brings a number of benefits.

The state variable is at the center of our approach, and its use simplifies filters,

improves code modularity and enables us to form snapshots. Commands effect

the desired changes to the state variables. There are a variety of tradeoffs to be
considered when allocating state variables to the DRCS command structure.



4.5 Automation


A DRCS with filters to interface to its DRCDs, state variables to reflect the

status of the system, and commands to link the inputs to the outputs is a complex

system capable of powerful features such as snapshot recall and querying of the

system's state. Of equal importance, however, was the requirement that the

DRCS perform a more sophisticated function; namely, automation. The

development of an automation system per se was not the goal of this work.
Rather, in this section we will demonstrate how our software structure, built with
commands, is highly suited to the demands of automation.







-65-

We define automation as a mode of operation in which the DRCS is recording

new user actions and replaying previous user actions, synchronized to some pre-

existing timebase. Automation must function in conjunction with the system's

normal operation. As the timebase "ticks", the system tags user-driven activity

with a timestamp. Then, by rewinding the timebase back to the start of the actions

the DRCS can re-create the net result of the user actions so as to be

indistinguishable from the original.



previous Database of next
pass user actions pass
(synchronized)


CD





DRCS
(with timebase)
User DRCS
Activity outputs


Figure 13: Automation (Single Pass)


Automation is especially well-suited to DRCS tasks that are completed

incrementally, in passes. After each pass the last pass's automation database and

the most recent user actions are combined to form the database for the next pass.

The digital nature of the DRCS makes it particularly attractive to automation.

Note that if the DRCS in question is one that accepts user input for action on

something else, then that which is acted upon must also be synchronized to the

system. The larger the DRCS's number of user inputs, the greater the potential






-66-

usefulness of the automation system. On a large system automation is

indispensable as it frees the user to concentrate on a particular part of the system

while the other parts repeat previous actions automatically and repetitively.

From Figure 13 we see that at any time during automated operation the

configuration of the console is a combination of what the operator is doing now

and what was done previously. This is typical of layered automated operation.

The DRCS itself need not be able to differentiate between current and previous

operator input. The applicability of our command and state-variable scheme can

be examined entirely in light of the link between the automation database and

the DRCS. This is because the rest of the DRCS functions normally during

automation. We must investigate whether the proposed scheme is well-suited to

the automation database, and how the DRCS can readily accept automation data.

Also, the existence of assignable controls in the UI may affect the design of the

automation system. We will address the database question first.


4.5.1 The Automation Database


An automation system, and hence the details of its database, must be chosen

to satisfy two criteria: it must fit within the current software framework, and it

must meet certain objective requirements, e.g. speed and/or memory usage.

Recalling that the goal of automation is to reproduce user actions, the most

practical choices involve either recording user input (i.e. this button was pressed

at this time) or recording changes to the state variables. Each has its own

advantages and disadvantages. Recording DRCD values can be dismissed for

reasons mentioned previously (also see Appendix B).

Having the automation database contain timestamped user actions, i.e.

recording user actions as close to the source as possible, is desirable for several







-67-

reasons. First, the accuracy of the system is maximized, as there is no possibility

of a loss of information through the DRCS's input filters. We cannot hope to

exactly reproduce user actions if we store state variables in the automation

database, as there is not always a 1-to-1 correspondence between the two. The

automation system does not attempt to recreate the operation of the DRCS; it

seeks to recreate the actions of the user, and one might reasonably argue that its

scope should be restricted to the user layer! During automation playback, the

DRCS accepts user input both from the UI and from the database, so the input

layer must be able to keep up with this ever-increasing load in order to maintain

overall system performance. The information in the database is not sufficient to

describe the state of the DRCS, only the activity of the UI.

A sample implementation of the database for this scheme is shown in Figure

14, with a record for each event containing a timestamp and information about

the user input:



timestamp timeslamp limes amp limeslamp
user input id ... user input id .. user input id ... ... user inpul id
user input value user inpul value user input value database user input value



time
start
of end
of
pass
pass


Figure 14: Sample Automation Database Format



The design of the automation database covers many issues that are outside

the scope of this work, e.g. the timestamp information may be in absolute or

relative time, and the database may be organized on a per-event or a per-







-68-

timestamp basis. Here we are concerned with the information about the input

events, and not how the database is organized or managed.

Recording user input changes requires a minimum of memory (since user

input devices, particularly incremental ones, are often of very low resolution11 --

switches are 1-bit, and positional indicators are rarely more accurate than 12-bit).

Lastly, and perhaps most importantly, this method keeps the details of the DRCS

completely out of the design of the automation system. Difficulties may arise

when the automation system is expanded to include additional features that are

related more to the function that the user is performing, rather than the way in

which it is performed.

There is one area where a lack of DRCD-specific information in the

automation system's scripts presents a problem -- namely, in the area of

automated playback visualization. With exclusively user inputs in the

automation database, there is insufficient information to see what the script's

effect on the audio will be. We can, for instance, see the user's moving knob m

from position p to position p+3p, but we cannot see the user's panning the signal

source from left-of-center to right-of-center without a substantial amount of

ancillary information (e.g. a map) about what knob m does (e.g. what it controls,

what function it performs) and what its state variable represents. Oftentimes

users of a playback visualization system will want this kind of information,

particularly if the database is to be applied to another system of different design.

Such information is portable if the emphasis is on the DRCS actions, and not the

activity of the user himself.12



11 Not to be confused with time resolution, which must be high enough to avoid perceptibility
and aliasing problems.
12 For example: "The edit decision list developed by CMX, Inc., is generally accepted as the
standard in the video industry for performing automated edits. Other manufacturers (such as







-69-

In order to get around this, the ancillary information is usually contained

within a map of the DRCS, which is either manually or automatically updated as

part of a database in order to remain current with the DRCS configuration. Note

that maps, unless structured very carefully with a strong bent towards

standardization (e.g. w/MIDI [Mus85, DeF87]), become highly system-specific

and non-portable.

Using an approach that records changes to the state variables has the

advantage that the automation system can at any time fully describe the state of

the system by creating a new current state from an initial value and the recorded

changes. With state variables in the automation database the automation system

can (re-)create the DRCS current state at any time without any action from the

DRCS! This approach is better suited to those systems that are primarily

concerned with what is being controlled, rather than with feeding back control

information to the user. Since the database contains the history of each state

variable, and hence each DRCS function, it is ideally suited as an aid to

visualizing the behavior of the DRCS over time.

In order to make such a scheme work, a means of indexing state variables is

required. As systems grow in size and complexity, the memory requirements for

the index fields in the database may rapidly exceed those for the state variables.

If memory considerations are important, it behooves the designer to develop an

efficient format for the database files. The command format we have developed

lends itself ideally to the needs of the automation database. The data fields in the

database simply contain the command, which is really just an index, and the

argumentss, which include the state variable.




Sony, Adams-Smith, Audio Kinetics, etc.) have developed CMX-compatible operating
programs for use in their video and audio-for-video edit controllers." [Hub87, p. 286]







-70-


timestamp tietam tmestamp timestamp
command ... command ... command ... ... ... command
argument gument argument database argument


t time
time
start -----_-
of end
pass of
pass


Figure 15: Another Sample Automation Database Format



The data contained in either type of automation database can be of relative or

absolute form, each with its advantages and disadvantages. For example, the

absolute approach is the considerably more fault-tolerant of the two, as the

DRCS's state at any time t+3t is not a function of its state at time t. Conversely, it

is much harder to go backwards in time with the absolute approach, as all

previous state information is lost when a particular item's state is re-written

(absolutely). It should be noted that in some cases, where the recorded data

does not represent some linear range of values, it may be difficult to create a

meaningful incremental representation.





4.5.2 Assignable Controls



User activity through dedicated input DRCDs can easily be integrated into

the automation system, using either the user input scheme or the state variable

scheme. In systems with large numbers of identical output DRCDs, however, it

is often advantageous and cost-effective to make use of assignable controls --

controls that, through user actions, are assigned to a particular DRCS function






-71-

[Sta93]. Examples of assignable controls include function keys and continuous

controllers (i.e. "endless" knobs). Such controls are typically re-assigned

regularly to those DRCS functions that require the user's current attention. The

context-sensitive nature of assignable controls destroys the simplicity of the user-

input derived automation database, as the link between the assignable control

and the DRCD must be stored as additional information. This also complicates

visualizing the system activity through the database, as the context of the
assignable control must be taken into account.

While a haphazard linking of assignable controls to the DRCS may be

sufficient for non-automated operation, the demands placed on the automated

system (efficient database, continued high performance, etc.) argue for

integrating these controls into the system with a minimum of overhead. The

solution to this problem is to create virtual controls (i.e. virtual DRCDs), one for

each DRCS function that does not have its own dedicated DRCD. This is

relatively simple, and requires an agent in the UI to be associated with each

DRCS command. This way, the assignable control passes its new values) onto

the virtual DRCD, which is then recorded in the automation database. Much of

the coding for an assignable control involves mimicking the characteristics of the

virtual control so as to appear correct to the user. The activity of the agent is
what is finally recorded in the automation database. Assignable controls have no

effect on the state-variable-based automation database.


4.5.3 Automating the DRCS


The above mentioned issues affect the automation database. We now turn to

the underlying software structure of the DRCS, and we find that the command

structure is well suited to handle the demands of automation, assignable controls






-72-

and concurrent user activity. This is because it ultimately provides a single,

simple entry point (the command) for the recorded event to enter the system and

reproduce the original action, this time without user input.

A significant performance increase can be obtained in situations where the

system's DRCDs need only be updated at a prescribed time, as opposed to

continuously. This is done by performing only the set[] portion of commands

until the DRCDs need updating, whereupon the act[] and show[] portions of a

snapshot recall are performed. This is possible because the state variable, which

the set[] portion of the commands is modifying, is the only item required to fully

define the state of the system. Of course, performing set[] without act[] leaves us

with a system whose DRCDs do not correctly correspond to their state variables,

i.e. they are unlocked. In some situations this may be acceptable as a tradeoff

towards better performance as long as the DRCDs are ultimately locked.


4.5.4 Summary


Within the proposed DRCS automation can be implemented in two distinct

ways, each with its advantages. The DRCS can accommodate either scheme, for

the user-input-based scheme can be wholly isolated from the workings of the

DRCS, and the state-variable-based scheme is intimately associated with the

system's current state. Both can be implemented with commands. DRCS

functions without dedicated DRCDs in the user interface require virtual DRCDs.

The larger the DRCS, the greater the need for a command organization. The

approaches to automation are summarized below:







-73-


Table 9: Comparative Advantages of DRCS Automation Schemes

User-Input Based State-Variable Based
accuracy in perfect may lose resolution where
replaying user no 1-to-1 mapping exists
actions between user input and
state variable
load on DRCS DRCS must interpret automation data bypasses
automation data as user input and is executed
additional user actions, solely as commands; less
using some of its power; predictable
stays constant
possible data incremental and absolute incremental and absolute
formats
automation provides information on provides information on
database state of user input DRCS state
transportable to other potentially transportable to
systems only through a other systems
map for translation
feedback on input easier to implement more difficult to implement
devices of
previous passes


4.6 Command-Based Structure


Another advantage of the command structure has only become apparent with

the enlargement of the DRCS's scope in software and operations. Those

functions which require considerable inter-channel communications (e.g. a

grouping of controls) can be quickly implemented once a standardized command

scheme is in place. In any large system, it is possible to implement inter-channel

meta functions in a variety of ways -- for example, channels could "talk" to one

another (loosely coupled), or channels could communicate via a central shared

piece of memory (tightly coupled). Often there are good reasons for picking one






-74-

scheme over the other, and a DRCS may uses both schemes to its advantage.

Some functions are much more easily realized when message transmittal and

receipt are deterministic. Having chosen a state variable scheme which is

compatible across different channels, as well as different types of channels,

ensures that computational power is not wasted in data type translations and

other types of conversions.


4.6.1 Executing Commands


Assignable controls and automation require a mechanism whereby the

control activity leads to changes in the corresponding state variable. By adding a

mechanism for executing commands from an external source, the DRCS is able to

simultaneously accept and act upon user, automation and external inputs. As

the DRCS workload increases, any command-execution overhead manifests itself

as a deterioration in the system's real-time performance.

This part of the DRCS design does not lend itself well to a generalized

approach. Rather, the DRCS programmer must consider the relative importance

of many issues revolving around command execution before settling on a
command format. For instance, dedicating additional bits to a command format

so as to make destination addressing and sender notification easier will place a

processing burden on all parts of the system that do not make use of this

additional information. On the other hand, a lack of such information may

preclude certain system functions that "handshake" between channels. With

unlimited code space all actions could be performed as commands -- however,

this way may be impractical or simply unnecessary (or even dangerous), as

although a large number of actions lend themselves to being made commands,






-75-

some actions do not. In any event, these issues do not detract from the

applicability of our state-variable-based approach to defining DRCS functions.



4.7 Macros


Another notable benefit of the unified command structure is the use of macros

-- small assemblages of data that provide the ability to replay a sequence or

group of user actions with or without a time reference, respectively. Macros are

especially useful for repetitive or complicated user actions. The DRCS must

provide a means of creating macros, ranging from the conceptually simple but

tedious editing of a text or data file to the complex (software-wise) but easy-to-

use automatic recording of user actions. A DRCS built around a command

structure has no difficulty executing macros or assembling user actions into

macros. The macro can be viewed as the ultimate incarnation of the command,

as it can exist in and be triggered and executed by any part of the system.

Macros have proven to be especially useful when the development of DRCS

functions outpaces the development of the UI. With a macro, a function can be

tested via its associated command and the chosen argument, without any UI

interaction. While each part of the UI must have a command associated with it,

the converse is not true. Test commands, for example, may intentionally be left

out of the UI for safety or security reasons. Macros are an ideal means of

executing these types of commands in the system. Grouped macros appear as

consecutive commands. Timed macros can be stored in the same format as

automation data as long as the timestamps are compatible.






-76-


4.8 Chapter Summary


A scheme for structuring software in digital remotely controlled systems has

been proposed. By describing the operation of the DRCS in terms of the

functions it presents to the user, an organization with distinct layers is achieved.

Each layer contains distinct software, yet they are all tied together by the DRCS's

central software entity, the command. Each DRCS function, from user input to

control output, is fully described by its associated command. Commands
operate on centrally located state variables, which at all times fully describe the

state of the system. The system's ability to execute commands, as well as the

independent nature of the components of the commands, can be exploited to

create higher-level DRCS functionality with little overhead. With the command

structure in place, adding new features and functions to the DRCS becomes

simply an exercise in defining the state variable(s), creating the input and output

filters, and assembling them into a command -- a relatively easy task.

Below are illustrated the three main phases of DRCS software design when

following the method described in this chapter.







-77-


Design system hardware, guaranteeing
correctly functioning interfaces to all I/O
devices (i.e. DRCDs). Ensure sufficient
bandwidth exists to service all DRCDs.




For each DRCS function, choose a
representation for its state variable(s) that
best suits the associated DRCDs, is readily
comprehensible, suits the available memory
requirements, and can be mapped to the
hardware without excessive translation.



end


Figure 16: First Phase of DRCS Design Process -- State Variables,
Representations and Harmony with Hardware Design


begin



Tally all of the system's input-to-output
functions and the I/O DRCDs needed to
implement them. Verify that the DRCDs have
the physical characteristics required to
implement the functions. Collect the DRCDs into
groups on a per-function basis. Include virtual
DRCDs.
I


Iterate over all state
variables until satisfied.
Redesign hardware
interfaces to bring
arbitrary design decisions
into compliance with state
variables. Standardize by
limiting the number of
differing representations.
Identify illegal states and
conflicting state variables.

<___________A







-78-


begin



Create input filters (set[]) for each function.
Each filter is triggered by user or system
activity, writes and may read state
variable(s), translates user activity to state
variable(s) and performs bounds/validity
checking, if required.



Create output filters (act[], show[]) for each
function. Each filter may read state variable
and converts state variable into format suited
for output DRCD.



Resolve any conflicts between functions by
appropriate modification of set[], act[] or
show[]. Particular attention must be paid to
calling sequences.



Create means of reading and writing snapshots.
Create snapshot recall operation using all act[]s
and show[]s.



end


Figure 17: Second Phase of DRCS Design Process -- Filters, Conflict Resolution
and Snapshots







-79-


begin



Create commands by combining set[], act[],
show[] sequences with a means of providing
command execution and arguments. Establish
mechanism for inter-processor passing of
commands. Implement assignable controls.
Implement macros.




Implement automation database by using
commands whose formats satisfy demands of
automation system. All automated activity
must execute through command actions.




Re-examine ramifications of large-scale system
behavior and modify original choices of
representations and mappings for optimum
performance. Identify filter performance
bottlenecks and suggest hardware modifications
for improved next-revision design.



end


Figure 18: Third Phase of DRCS Design Process -- Commands, Automation and
Large-System Issues















CHAPTER 5
IMPLEMENTATION


The proposed DRCS software was incorporated into a professional audio

mixing console according to the guidelines laid out in the previous chapter. The

development period was relatively long, which allowed for the trying and

rejection of many approaches that were deemed unsatisfactory. In several

instances conditions specific to the console's architecture and specifications

required enhancements or alterations to the basic scheme. This chapter reviews

this implementation of our DRCS software structure.

This professional product, shown in Figure 19, performs amplification, level

control, mixing and equalization of analog signals via digital control, and is

intended for use in music, live sound, post-production and film work. Typically

a single user, the mix engineer, operates the console under the direction of one or

more clients. The engineer uses his listening skills and mixing abilities to

combine the console's audio inputs (live, pre-recorded or synthesized) to create
an overall mix, typically of two (stereo) or more (e.g. 5.1-channel Dolby Digital
SR-D for movie theaters [Nor92]) output channels. The console interface is a
large surface with knobs, faders, switches and displays. Mixing is usually a high-

pressure, high-stress environment, with neither room nor time for equipment or

operator errors [Hol88]. Large professional consoles cost well in excess of

$100,000, so customer expectations of the system's performance and reliability are

very high.


-80-







-81-


Figure 19: The Control (User) Surface of a DRCS-based
Professional Audio Mixing Console



5.1 The Architecture as Implemented


The DRCS software structure was applied to the design of a cost-effective

mixing console with enhanced functionality, reliability, and configurability while

guaranteeing performance regardless of system size. Inexpensive

microprocessors in concert with digitally controllable audio elements formed the

basis of the design. A modular, processor-based design with the DRCS software

structure at its core was the end result. The system consists of four major

hardware components: the Mix Controller, the Audio Mainframe, the Patchbay and

the Support Computer. The two units we are concerned with -- the Mix Controller

and the Audio Mainframe -- are highly modular; the console's architecture is







-82-


easily expandable and can be configured with anywhere between 8 and 96

faders, in multiples of 8 faders.

The design's power and flexibility lie in the Mix Controller, the "brains" of the

system. In normal operation, the Mix Controller monitors the control surface

and implements the requisite changes to the audio circuitry in real time (a 1/30s

frame). The scale of this system1 quickly overwhelms all but the most powerful

single processor's2 ability to keep up with all the changes that can be made to the

control surface in real time (to say nothing of the immense bandwidth required

to get all the system signals into and out of the uniprocessor). As a practical

example, snapshot recall requires that each I/O channel update 174 bytes in the

Audio Mainframe in 1/30 sec. Of course the situation is made increasingly more

dire by the expansion of the system through additional channels. The solution is

to dedicate a processor to a manageable number of channels, and replicate this as

the system grows in size.

Below we present a quick overview of these four major components:


1) The Mix Controller contains from four to fifteen Z80 microprocessors
using a shared-memory paradigm to communicate among themselves
while running simultaneously and independently. All the DRCS
software resides in the Mix Controller; only two of the Z80s are not
directly responsible for the system's functions.3 No audio signals4 pass
through the Mix Controller. Rather, it presents the user with a unique



1 A mid-size, 24-channel unit, has 48 faders, 48 microphone preamplifiers, 48 equalizers, 96 auxiliary level
sends, 48 mutes, 144 inputs and 120 outputs (I/O), plus 13 inputs and 22 outputs, 2 faders, 14 pots, and
2 mutes (Master). The corresponding stuffing of the Audio Mainframe is 24 I/O Channel modules and
one Master Channel module. The system has 38 internal signal busses.
2 A competing, uni-processor product was released at roughly the same time. It failed to gain adherents
primarily because of a lack of expandability, and soon vanished.
3 One handles high-speed (>1MBps) communications; the other arbitrates shared memory access, provides
synchronization and supports virtual controls.
4 Except the talkback microphone, which must be mounted in the console for convenience.







-83-


but recognizable and industry-standard5 control surface consisting of
rotary pots (knobs), linear pots faderss), switches, level meters and
illuminated panels to control and display the console's current
configuration. The Mix Controller consists of one Master control module 6
and up to 12 I/O control modules. It has almost negligible power
consumption, with its light-emitting diodes (LEDs) responsible for over
80% of the current draw.


2) The Audio Mainframe is a small-refrigerator-sized tower containing all
the system's audio-controlling DRCDs. It takes analog input signals and
digital control signals and returns analog output signals and digital
status signals. The Audio Mainframe consists of a Master audio module
and up to 28 I/O audio modules. Each of the Mix Controller's I/O control
modules controls 4 I/O audio modules. The Master audio module and
every group of 4 I/O audio modules each have a dedicated bidirectional
1Mbps link to the Mix Controller. The Audio Mainframe consumes
approximately 2.5kW in operation.

3) The Patchbay presents the user with an industry-standard means of
connecting audio signals to the system -- it's much like an old telephone
operator's jack panel. This is a custom, passive, off-the shelf component.

4) The Support Computer, connected to the Mix Controller via a high-
speed serial link, provides for off-line (disk) storage of console data, as
well as ancillary display functions which require a large, bit-mapped
display. It is an extension of the systems UI, to some extent a graphical
user interface (GUI). As the GUI developed, so did the link between the
Mix Controller and the Support Computer, evolving from a 38.4kbps RS-
232 link to a 10Mbps EuBUS connection.7 The Support Computer is also
an off-the shelf component.


5 While the input devices are industry-standard, their arrangement is new and unique to this design.
6 For packaging and standardization reasons, the Master section (a single Channel, but of a different type)
was allocated an entire Z80. It has evolved to the point where its load is approximately equivalent to
two I/O channels.


7 A proprietary point-to-point, bidirectional high-speed link.






-84-


The hardware design predated the software by several months, and most of

the design was complete before any programming began. A general idea of how

many Z80 clock cycles were required to perform the console's functions had been

previously established.8 In order for all these processors to work together, a

combination of loosely-coupled and tightly-coupled multiprocessor architectures

was developed. In it, each processor spends the vast majority of its time

monitoring its own control inputs, effecting changes in the audio circuitry, and

displaying the results on the control surface. Of course the user does not want to

treat the console as a grouping of independent 4-channel blocks -- rather, the

entire control surface should appear transparently as one large, harmonious unit

without any physical divisions due to modularity, etc. To this end, a means of

intercommunicating between modules was developed, in which several times

per frame each processor (and hence each channel, as the processor is the "agent"

for up to four channels) can access an area of shared memory, the Bulletin Board,

to post & read messages. The code supporting Bulletin Board communications

underwent six major revisions in an effort to provide as flexible a messaging

scheme in as few clock cycles per processor as was possible.

Many revisions to the specifications and the hardware design were made,

some to accommodate desired features in the software. By and large, we were

presented with a hardware design that had the perceived ability to execute

programs and interface to the DRCDs and to shared memory, with little

processing power to spare.






8 The system developed from 4MHz Z80s to 6MHz, and finally to 8MHz parts. A single 16MHz Z180
maintains the 1.25MBps EuBUS connection.






-85-


5.2 The Scale of the Problem


To fully appreciate the task that faced the software designers we

must examine what had to be done, and how much of it there was to do.
First, by examining the partitioning of the console's functions into the
I/O and Master control modules, the system's functions are defined. For
example, the I/O control module's most basic functionality (per channel)
was defined and arranged as:


2 19-segment LED meters with programmable ballistics and 16
different modes
3 programmable outputs (OUT1-OUT3) using the 6 sources
other miscellaneous routing and mixing functions
2 independent microphone preamps (M1, M2) with 60dB of auto-
ranging gain control, phase reverse, high-pass filter and +48V
phantom power
4 independent auxiliary sends (AUXA-AUXD) with 12-bit level
control, 6 sources, 8 destinations, and 34 different modes
2 independent fader (UF, LF) with 12-bit level control, 6 sources, 3
(LF) or 27 (UF) destinations, mute and 23 different modes
2 independent 4-band parametric equalizers (EQ1, EQ2) with
programmable insert points to all 6 sources
2 pre- and 2 post-fader SOLOs
full display of current routing settings via hidden-until-lit LEDs
positional and clipping LEDs for all pots and faders


This basic I/O functionality was to be repeated for every channel in

the console. The Master control module had considerably more such


Figure 20: Console I/O Channel Strip






-86-


functionality. The specifications demanded that the system be capable of

sustained updates of every single function every 1/30 second. This basic

functionality was to be eventually augmented by snapshot recall, automation,

grouping and macros, so these higher-level features had to be kept in mind while

the system was being designed.
The input DRCDs include momentary pushbutton switches, conventional

linear potentiometers sampled by analog-to-digital converters (ADCs),

overtemperature sensors, rotary encoders and LEDs packaged in bargraphs, 5x7

character arrays, and individually. The output DRCDs employed include

relays,9 silicon switches,10 ADCs and digital-to-analog converters (DACs). Very

few of the DRCDs support both input and output. The numbers of DRCDs

contained in each of the various modules are outlined in Table 10.

Some DRCDs (e.g. 12-bit level attenuators, metering units, equalizer controls)

are themselves collections of digitally controlled devices, and are so packaged for

various design reasons. A system with 24 channels has input and output DRCDs
numbering over five thousand!



5.3 Overview


The design of representations, filters and commands develops roughly

concurrently. Once a working model with a few functions is implemented, the

designer faces the now rote task of writing the full set of filters and commands

for the DRCS. After a basic working system is established, one invariably finds


9 In retrospect, one of the simplest DRCDs.
10 From which analog multiplexers can be designed.







-87-

areas amenable to improved performance. Thereafter, virtually every aspect of

the design -- including representations, filters and commands -- must be iterated

several times in order to reduce execution times, reduce code size, streamline

internal processes and enable new functionality.


Table 10: Console DRCD Count

Input DRCDs Output DRCDs
I/O control module rotary potentiometers 32 bargraph LEDs 152
(for 4 channels) linear faders 8 bicolor LEDs 56
pushbutton switches 60 single-color LEDs 520
total: 100 total: 728
Master control rotary potentiometers 14 bargraph LEDs 152
module linear faders 2 bicolor LEDs 48
pushbutton switches 100 single-color LEDs 111
total: 117 5x7 dot-matrix LEDs 24
total: 335
I/O audio module metering units 2 12-bit level attenuators 8
(1 per channel) clip indicators 8 8-bit level attenuators 2
configuration indicator 1 metering units 2
total: 11 6-input combiners 14
equalizer controls 44
relays 76
silicon (mute) switches 8
total: 154
Master audio metering units 8 12-bit level attenuators 24
channel clip indicators 10 metering units 8
total: 18 user bits 4
relays 51
silicon switches 28
115


It is instructive to follow how various issues led to certain design decisions.

Instead of attempting to chronicle the development of the hundreds of system
functions, as our primary example we will follow a simple function, OUT1,
which combines up to six inputs to form a single (mono) output in an I/O

channel. Besides the requisite input filter, OUT1 requires two output filters --







-88-

one for the control DRCD, and one for the UI DRCD. The development of this

function is representative of the effort required to complete the system.



5.4 Standardized Representations


The OUT1 function is quite straightforward, in that it controls the state of six

independent bipolar solid-state switches. Additionally, six LEDs corresponding

to the six switches present the state of OUT1 to the user. The situation for other

functions was similar; the polarity of the solid-state switches and relays was not

overwhelmingly standardized, but the polarities of the LEDs usually were -- a 0

meant that the LED was on, a 1 that the LED was off (active low). Despite the

hardware's bias towards an active-low representation, we discovered that active-

high was easier to explain to programmers and sophisticated users who created

their own macros. This led to an important decision concerning representations

-- that all switch-type functions in the console would be active high in their state

variables. This meant that some translation would be required when reflecting

the state of the function in the UI. In those DRCDs that were not active low, a
simple toggle operation was all that was required, and this was shown to have a

negligible effect on the system's performance (see below). Additionally, it meant

that all instances of virtual controllers that dealt with switch-type functions could

treat the data in the same way, eliminating any extra coding to handle one of two
possible polarities.
Due to the Z80's poor performance in bit-oriented instructions and due to

real-world memory constraints, it is undesirable to dedicate individual memory

locations (bytes) to each DRCS function. Rather, we collect DRCS functions in

groups (or blocks) that corresponded to the presentation on the surface of the Mix

Controller. Instead of having six state variables to represent the current settings







-89-

of the six silicon switches in OUT1, all six bits are collected into a single byte to

form a state variable for the OUT1 meta-function. Wherever possible the bits are

arranged to correspond to the bit alignment of the actual hardware.



5.5 Input Filters



The large number of DRCDs and the repetitiveness of the functions they

performed would quickly have led to large and unmanageable code if the filters

were not standardized. Input filters were invariably the simplest, especially

when the associated function had only a virtual (assignable) control. In these

cases the function is controlled through the execution of a command. OUT1's

input filter simply limits the allowable value of the command's argument,

masking out any unused and/or potentially dangerous bits, and then writes a

new byte-sized value to the state variable:


set_OUT_l_src: and 00111111b
_wr_Snapshot_byte OUT_l_src
ret



where OUT_ 1src is an index into the channel's current snapshot. The new

value for OUT1 is carried implicitly in the Z80's A register. This input filter is a

simple assembly-language subroutine of a few bytes, and differs from the input

filters for OUT2 and OUT3 by only a single piece of information, the state

variable index:


set_OUT_2_src: and Oll0111111b
_wr_Snapshot_byte OUT 2_src
ret
set_OUT_3_src: and 00111111b
_wr_Snapshot_byte OUT_3_src
ret




University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs