Architecture – Driven Embedded Systems
Adaptation for Supporting Vocabulary Evolution
Narayanan (Nary) Subramanian
Applied Technology Division
Anritsu Company
narayanan.subramanian@anritsu.com
Abstract
As the environment of a software system continuously
changes, so should the system adapt to such changes for
its continued success and survival. Software architecture
greatly facilitates the process of software adaptation to
environmental changes, since changes are then made to
the components instead of the much larger system as a
whole. Adaptability for embedded systems often requires
techniques different from those used for non-embedded
systems. This is due to the fact that embedded systems
operate in a harsher environment. This paper considers
software adaptability as a key non-functional requirement
(NFR) for evolving systems and discusses this concept as
applied to embedded systems. The strategies available to
adapt an embedded system are explained by solving the
practical problem of vocabulary evolution. Several
adaptable software architectures for an embedded system
for this problem are developed. The codes that follow
from these architectures are then implemented in an
embedded system and the results are discussed.
1. Introduction
As the environment of a software system continuously
changes, so should the system adapt to such changes for
its continued success and survival. Software architecture
greatly facilitates the process of software adaptation to
environmental changes, since changes are then made to
the components instead of the much larger system as a
whole. Adaptability for embedded systems often requires
techniques different from those used for non-embedded
systems.
Embedded systems run in a harsh environment – small
memory, limited computation resources, are expected to
have fast response times to external events and are
usually real-time systems as well [9]. Oreizy et al. [1]
give an insightful example of the UAV’s (unmanned air
vehicles) that are embedded systems in themselves. This
paper takes this spirit further and examines evolutionary
Lawrence Chung
Dept. of Computer Science
University of Texas, Dallas
chung@utdallas.edu
strategies for such systems bearing in mind the limited
computational power and memory of such systems.
Notkin and Griswold [2] present novel ideas for
dynamic extension of software systems while Jarzabek
and Hitz [3] offer pragmatic ideas for software evolution
using components and generic architectures. This paper
attempts to extend some of these ideas to evolution in
embedded systems and validates the strategies developed
using an embedded system.
It is now an accepted fact (Oreizy et al.[1], Oreizy et
al. [4], Shaw and Garlan [5], and Bass et al. [6]) that
software architecture should be the first step towards the
solution where decisions for software evolution are
taken. This enforces the consideration of the evolutionary
factor at each subsequent step of the software
development. This paper considers software evolution
from the point of view of adaptation of the software.
Adaptation is the change in a system to accommodate
changes in its environment while adaptability is the
ability of a system to make adaptation. Adaptibility is a
non-functional requirement (NFR) and software has to be
adaptable if it has to evolve. Making adaptability part of
the requirements ensures that the software built based on
these requirements will be evolutionary. And the first step
in the building of the evolutionary software is the
construction of adaptable software architecture.
Adaptable software architecture lets the changes be
considered in terms of the architectural components of the
system that individually are much smaller than the whole.
This significantly reduces the problem of determining the
parts of the system to change and effecting the change,
each time the system needs to be changed.
The strategies available for adaptation of a component
in an embedded system include:
1. standard
2. conditional expressions
3. algorithm selection
4. run-time binary code modification
5. porting the component outside the system, etc.
In the standard method the system is shut down, the new
program loaded, and the system is restarted. Conditional
expressions let a component change its behavior based on
the value of an expression. Algorithm selection involves
selecting a different algorithm to adapt to an environment
change. Run-time binary code modification involves
changing the binary executable to adapt to an
environment change. The fifth method – porting outside
the system – involves moving the component that has to
be adapted outside of the embedded system to a more
traditional environment. This lets the available adaptation
strategies for non-embedded software be used to achieve
the adaptation. In this paper we will describe the
techniques 2, 3 and 4 in detail and the other two only
briefly due to space limitations.
In order to illustrate these adaptation strategies a
problem that occurs frequently in the world of embedded
systems is considered - the evolving vocabulary problem
(Notkin and Griswold [2], Worrell [7]). This occurs when
the embedded system has to respond to commands from
an external controller (may be a human or a computer)
and the vocabulary of the commands evolve. The goal is
to design the embedded system in a way that it adapts to
the evolved vocabulary used by the external controller.
The evolution in the vocabulary is necessitated by many
reasons: standards used for vocabulary may have changed
and the older system may have to obey the commands
conforming to the newer standards; incremental
development of software may require older versions of
the software to respond to newer commands; or newer
modules have been added to the embedded system
necessitating the embedded system to respond to
commands meant for the newer modules. This paper uses
the strategies mentioned above to tackle this problem. The
paper develops architectures to solve this problem based
on the different strategies and validates the architectures
by implementing the codes that ensue from these
architectures in an embedded system.
Many of the software diagrams in this paper use the
notation borrowed from UML (Booch et al. [10])
although any other notation with a similar modeling
power
can
also
be
used.
Also
in
the architectures the
has been used to indicate
message passing between the layers of the architecture in
the direction of the arrow.
Section 2 discusses the concept of software
adaptability, Section 3 describes the vocabulary evolution
problem, Section 4 discusses the solutions to the problem,
Section 5 describes the implementation of the solutions
and Section 6 summarizes the paper and discusses future
work.
2. Adaptability
2.1. Definition
Adaptation means change in the system to
accommodate change in its environment. More
specifically, adaptation of a software system (S) is caused
by change (E) from an old environment (E) to a new
environment (E’), and results in a new system (S’) that
ideally meets the needs of its new environment (E’).
Formally, adaptation can be viewed as a function:
Adaptation: E x E’ x S  S’, where
meet(S’, need(E’)).
A system is adaptable if an adaptation function exists.
Adaptability then refers to the ability of the system to
make adaptation.
Adaptation involves three tasks:
1. ability to recognize E
2. ability to determine the change S to be made to the
system S according to E
3. ability to effect the change in order to generate the
new system S’.
These can be written as functions in the following
way:
EnvChangeRecognition : E’ – E  E
SysChangeRecognition : E x S  S
SysChange : S x S  S’, where
meet(S’, need(E’)).
The meet function above involves the two tasks of
validation and verification, which confirm that the
changed system (S’) indeed meets the needs of the
changed environment (E’). The predicate meet
is
intended to take the notion of goal satisficing of the NFR
framework [11], which assumes that development
decisions usually contribute only partially (or against) a
particular goal, rarely “accomplishing” or “satisfying”
goals in a clear-cut sense. Consequently generated
software is expected to satisfy NFR’s within acceptable
limits, rather than absolutely.
2.2. Axes of Software Adaptation
Software could be adaptable in different ways: static or
dynamic, manual or automatic, proactive or retroactive. In
dynamic adaptation the system only changes its run-time
behavior while its implementation is fixed; in static
adaptation the implementation (and the other phases of
software development) varies with each version of the
adaptable software developed. Manual adaptation occurs
when the software adaptation is achieved manually, while
in automatic adaptation software adapts itself. Proactive
adaptation occurs if the software is able to adapt to an
expected change in the environment; while retroactive
adaptation occurs after the environment has changed.
Thus any software system could be adaptable in one or
more axes of adaptation as shown in Figure 1, i.e.,
adaptation could be dynamic/automatic/retroactive or
static/manual/proactive and so on.
Dynamic
Retroactive
Automatic
Manual
Proactive
Static
Figure 1. Axes of Software Adaptation.
Embedded
System (ES)
Communication
Link
External
Controller (EC)
Figure 2. Application Domain for the Problem.
3. Problem
3.1. Analysis
The concept of adaptable software architecture will be
illustrated by solving the problem stated in the
Introduction. The application domain for this problem can
be understood better from Figure 2.
The embedded system (hereafter, ES) is a system that
has its own CPU, memory, peripheral components and
I/O and associated firmware. Examples include pagers,
cell phones, test and measuring instruments, automobile
control systems, microwaves, telephones, printers and a
variety of others. While many of the embedded systems
are designed to operate on their own with no outside
intervention, there are a host of embedded systems that
communicate with an external controller (EC). For
example pagers receive the information they display from
a central control via RF, i.e., the communication link
between the external controller and the pager is radio
frequency; similarly, cell phones receive information
from and transmit information to the base station
controller also via the communication link of RF;
likewise printers receive information from the printer
server via a communication cable such as Ethernet; also a
test and measuring instrument may be connected to a
controller PC via a IEEE488 cable and receive commands
from and send responses to the PC over the cable. Thus
the configuration of Figure 2 is a common one in practice.
The communication between the EC and the ES
involves two distinct aspects: the protocol used for
communication and the actual data transmitted during the
communication. The protocol is usually based on a
standard and are handled by ASIC (Application Specific
Integrated Circuit) and its associated driver on either end
of the communication link. However, the data transmitted
is higher-level issue that is of most importance to both the
parties involved in the communication.
The data transmitted consists of text taken from a
vocabulary that both the EC and the ES understand. The
text (or data) sent from the EC to the ES has two aspects
associated with it: the syntax and the semantics. Syntax
relates to the correctness of the literal text of the data
received from the controller while semantics is a higherlevel issue that is related to the meaning of the text
received from the EC (assuming that the syntax was
correct). The meaning of the text manifests itself as an
activity performed by the ES - such as printer printing the
page,
pager
beeping and displaying the received
message, a test and measuring instrument doing a
measurement, and the like.
The basic functional blocks in the ES and their
interconnection are shown in Figure 3. The
Communication ASIC Driver Block of this figure
communicates with the ASIC that handles the
communication with the external controller. The data
received from the EC is sent by this block as a string to
the Syntax Analysis Block. The Syntax Analysis Block
checks for the syntax of the received command and if
correct, sends the corresponding code to the Semantic
Analysis Block. The Semantic Analysis Block takes the
required action for the command received.
In case a response has to be sent back to the EC, the
Semantic Analysis Block
generates the response
string and sends it to the Communication ASIC Driver
Block directly and the latter sends it to the EC via the
communication link.
Figure 4 shows the activity diagram for the interaction
between EC and the ES that explains many of the details
mentioned above.
3.2. Vocabulary Evolution
One of the common problems encountered in such
application domains is that of vocabulary evolution
([2] discusses the problem of defining and executing new
commands, [7] discusses leveraging parsers for different
members of a product family to account for differing
‘programming metaphors’ – this paper considers
differing ‘programming metaphors’ to be a vocabulary
evolution problem). This means that the syntax of the
command for changing a feature changes with time. The
reasons for this vocabulary evolution are varied and some
of these are listed below:
1.The software follows an incremental model of
development lifecycle:
Each increment of the software has additional features
that require more commands to be added. The addition of
these new commands constitutes an evolution of the
command set.
Semantic Analysis Block
Parsed Code
The problem of vocabulary evolution is related to the
environment change for the embedded system by the
following equation:
E = CSi+1 - CSi
ES
Response String
Syntax Analysis Block
Table 1. Vocabulary Evolution Example.
Function
1.Set
Address
2.Display
Output
3.Set Time
Received String
Communication ASIC
Driver Block
Data From
Data To
Controller
Controller
Figure 3. Functional Blocks in the Embedded
System (ES) with their Interconnections.
ES
EC
Send String
Receive String
[ sy ntax
incorrect ]
Ignore String
[sy ntax correct ]
Process String
[resp onse
required]
[ resp onse not required ]
Send Resp onse
Receive Resp onse
Process Resp onse
Figure 4. Activity Diagram for EC-ES
Interaction.
2. The commands follow a standard:
If the commands follow a standard such as Standard
Commands for Programmable Instruments (SCPI) [8],
then some of the implemented commands may have to be
changed to meet the newer versions of the standard.
3.Newer modules have been added to the embedded
system:
Implementation of new hardware/software modules
may require some of the existing commands to become
more specific. Thus if initially, the embedded system had
only one means of display, say LCD
display, and a
newer version has a speaker too, then the commands
related to outputs may have to be
changed to indicate
which output to use.
Table 1 shows an example of vocabulary evolution.
Mathematically, if CSi and CSi+1
represent two
consecutive generations of command sets, then
CSi  CSi+1 .
Current Syntax
ADDR 5
OUTPUT “OK”
TIME “12:00:00”
Evolved Syntax
ADDR: ETHERNET 5
ADDR: GPIB 5
OUTPUT: LCD “OK”
OUTPUT: SPEAKER “OK”
TIME: MAINCPU “12:00:00”
TIME: SUBCPU “12:00:00”
3.2.1. Problem Analysis. As can be seen from Figure 3,
the evolution of vocabulary affects the syntax and
semantic analysis blocks. The basic component of the
syntax analysis block is the parser. The parser decodes the
received strings into codes that the semantic analysis
block can understand. The semantic analysis block
consists of all the software that comprises the core of the
application that the ES runs. In particular, it also decodes
the codes received from the syntax analysis block and
takes corresponding action for the code – such as
performing measurements, returning values of parameters
to the EC, setting value of internal parameters, and the
like. This block is the most complicated portion of the
software in the ES and could consists of several layers of
software. In subsequent discussion this block is referred
to as “Embedded System’s Higher Layers”. This paper
concentrates on generating
adaptable software
architecture for such a system in relation to the syntax
analysis block. Thus this paper assumes that evolved
vocabulary does not affect the functions of the existing
system and instead augments and expresses the same
function(s) more efficiently.
4. Solution
4.1. Solution Analysis
Figure 3 gives the high-level architecture for ES. In
order to be more useful for design purposes, the
architecture has to be viewed at a finer abstraction. The
architectures that will be developed here will be adaptable
and at a lower level of abstraction. While in Figure 3, the
response string that ES generates originates at the
semantic analysis block and goes directly to the ASIC
block, in the architectures that will be considered here an
Output Manager component will be included. This can be
thought of as belonging to the Communication ASIC
Driver Block of Figure 3. Likewise the Semantic Analysis
Block of Figure 3 will be represented by ES’s Higher
Layers component (explained earlier) in the architectures
considered here. This component consists of several
layers and it is assumed that the lowest layer of this
component interacts with the layers below it (however,
the lowest layer is not shown explicitly). The Syntax
Analysis Block of Figure 3 will be composed of the
components of Parser and (optionally) Parser Manager.
All the architectures considered will be in the layered
style.
As mentioned earlier, the ES will be using a parser to
parse the command strings from the EC. Thus the
requirement that the vocabulary be evolvable translates at
the analysis level to an evolvable parser for the ES.
In all cases considered in this paper, the architecture
change is not allowed at run-time; the architecture is fixed
at run-time.
4.2. Architecture Evaluation
The scenario used to evaluate the architectures is
given in Figure 5.
EC : sends strings from Current Syntax column of
Table 1 to ES.
ES: accepts all legal strings belonging to Current
Syntax column received from EC.
EC: starts sending strings from Evolved
Syntax column of Table 1 to ES.
ES: accepts all legal strings belonging to Evolved
Syntax column received from EC.
Figure 5. Scenario for Architecture
Evaluation.
Adaptation for the architectures will involve the three
tasks discussed in Section 2, viz., environment
change
recognition
(E),
system
change
recognition (S ) and system change (S’). Each of these
activities
could
be
accomplished
automatically, semi-automatically or manually.
4.3. Software Development Process
The software development process followed is given in
Figure 6. Though the process of Figure 6 refers to specific
system requirements, the architectures developed in the
next section will be for a more general system, as
discussed in sections 3.2.1 and 4.1.
4.4. Solution Architectures
4.4.1. Architecture 1 (A1): Static/Manual/Proactive
Adaptable Architecture
4.4.1.1. Architecture Description. This architecture
implements the standard technique. Briefly, whenever
the vocabulary changes, the implementation of the Parser
layer is changed, the code is recompiled and loaded into
the ES. The ES is then restarted. Thus this is a static
adaptation. Also this is a manual adaptation, as it requires
the parser to be changed by human intervention. Also this
adaptation is proactive since the parser is changed before
the new vocabulary corresponding to the new parser is
used. Thus this is a static, manual and proactive
adaptation.
The advantage of this architecture is that there is no
limit on the number of the vocabulary. The disadvantage
is that for each change of the vocabulary, the system has
to be recompiled and restarted.
Here E detection, S recognition and the system
change are all manual.
4.4.2. Architecture 2 (A2):
Dynamic/Automatic/Retroactive Adaptable
Architecture
4.4.2.1. Architecture Description. As can be seen from
Figure 7 the Device Driver layer sends the strings
received from EC to the layer immediately above it called
the Parser Manager (PM). There are two ways in which
subsequent processing can be done:
1. Sequential:
For this method, the statechart diagrams
for PM and the layer of parsers immediately above it is
given in Figure 8. If any of the parsers n (n = 1 to N)
parses the
code successfully it sends the code
corresponding to the command to the layer above it. If
none parses the command successfully the ES does not
have the vocabulary for that command or the command
had a typographical error. This architecture can support
N generations of evolution of the command set, i.e., it can
support command sets CS1 , CS2 , …, CSN .
2. Intelligent: In this method, each generation of evolving
vocabulary is assumed to have a basic structural
difference that lets the PM decide to which of the N
parsers in the layer above the input string should be sent.
Figure 9 shows the statechart diagrams for the PM and
parser layers in this case. The PM receives the input string
and determines to which parser to send the string to and
that parser processes the input string.
As can be observed, the adaptation is dynamic and
automatic. The system can support up to N generations of
vocabulary evolution where each generation of the
vocabulary has its corresponding parser in the system.
The adaptation is also retroactive since ES reacts to the
evolved vocabulary after it receives the command from
the EC. However, this architecture has its drawback: the
evolutions of the vocabulary have to be foreseen in
advance so that the parsers for the new generations of the
vocabulary can be built.
This model is especially applicable in the case when all
the increments for software are known in advance and
parser for each increment has the commands applicable
for that increment and other parsers are kept for backward
compatibility.
4.4.2.2. Architecture’s Adaptability.
1. E Detection: This is fully automatic. In fact,
in
the
Requirements:
The embedded system should display the commands
received from the external controller on an LCD display.
It should accept the commands of Table 1 and also
display to which generation the command belongs.
Architecture Development:
The system needed a device driver for communicating
with the EC; it needed a parser component to parse the
commands; it also needed a LCD display controller. The
parser component had to be adaptable.
Design:
The device driver and the display driver were
designed for the particular communication port and the
LCD; the parser component had to be designed to parse
evolvable commands – the algorithm used for parsing
had to be decided. The inter-component communication
methodology was chosen to be message-passing.
Implementation:
The device driver, display driver and the parser
components were implemented. Two different parsers
were implemented for the two generations of commands
in Table 1.
Testing:
The commands belonging to both the columns of Table 1
were sent to the embedded system from a PC (which was
the external controller).The system behavior met the
requirements.
Figure 6. Software Development Process.
parser that can parse that generation of the input. If it does
then the PM sends the input string to that parser; else it
does nothing (assumes that the input string was in error).
3. System Change: The system changes automatically.
For the Sequential method there is no change in the
system. For the Intelligent method the parser that is used
changes.
4. How the Needed Evolution is Achieved: Here the
needed evolution is achieved by finding the “best match”
parser. In the Sequential method the “best match” parser
is detected automatically, as a matter of course; in the
Intelligent method the “best match” parser is detected
explicitly.
4.4.2.3. Example. Figure 10 shows the statechart diagram
for the ES for the Sequential case (the statechart diagram
for EC
is simple – EC waits for ES to change before
using evolved syntax – hence omitted). To process the
scenario of Figure 5 two parsers are needed, Parser1 and
Parser2. Parser1 processes the Current Syntax
strings
while Parser2 processes the Evolved Syntax strings. As
soon as the input string is received, it is sent to Parser1 to
process and if the Parser1 returns an error code, the string
is sent to Parser2 to process. If either Parser1 or Parser2
parse the string successfully, the parsed code is sent to
higher layers; else the string is not parsed at all.
Figure 11 shows the statechart diagram for the ES for
the Intelligent case (the statechart diagram for EC is
omitted due to simplicity). In this figure, the PM
determines the parser to send the input string to and sends
the string only to that parser. If that parser processes the
string correctly, it sends the parsed code to higher layers;
else no further action is taken for that input string.
Embedded System’s Higher Layers
Parser 1
…
Parser N
Output Manager
Parser Manager (PM)
Device Driver
Figure 7. Dynamic/Automatic/Retroactive
Adaptable Architecture (A2).
Sequential method there is no explicit E detection. As
soon
as one of the available parsers parses the input
command, the system simply proceeds as usual. For the
Intelligent method, there is explicit attempt to find out E.
2. S Recognition: This is fully automatic. Again, in the
Sequential method there is no explicit recognition. For the
Intelligent method, any change in E results in a
corresponding change in S ,as long as the system can
adapt to the change in environment. The PM detects the
change in the environment and tries to find if it has a
4.4.3. Architecture 3 (A3): Static/Automatic/Proactive
Adaptable Architecture.
4.4.3.1.
Architecture Description. Briefly, this
architecture does away with the N parsers and the PM of
A2 and replaces them with a Composite Parser that can
parse all the commands that the N separate parsers of A2
do. This functions in the same way as A2, except that the
Device
Driver
sends
the
received
string
directly to the Composite Parser block that for a
syntactically correct command sends the corresponding
function code to the higher layer.
Here adaptation is static; it is automatic
as
evolved vocabularies are automatically parsed by the
composite parser; and it is also proactive as all commands
(even those to be used in the future) have already been
incorporated in the composite parser. The advantage of
A3 over
A2 is the
simpler mechanism used by
A3. However, the disadvantage is that the composite
parser could have a
complicated implementation and
poorer performance. Here E detection, S recognition and
system change are all zero.
PM
Idle
[received string
from EC]
Parser 1
processing
[parser 1 returned
error code]
Parser 2
processing
[parser 2 returned
error code]
...
[parser N-1
returned
error code]
Parser n
(1 <= n <= N)
Idle
[received
string from
PM ]
Parsing
string
[error]/
send
error code
to PM
Here the user sends a string to the ES to inform that the
next command is from a different command set. Based on
this information the ES uses the correct parser to process
the next input string. The command that instructs the ES
of change in command set is processed by parsers for all
command sets and all instruct the PM which parser to use
for the next command. The PM sends the next command
to the selected parser.
2. Modification: The binary code for the parser can be
dynamically changed to accept evolved commands. This
modification of the binary code may be made in the same
way as for the selection method by having a special
command that writes to memory. This modification is
possible
as
the
ES
[no error]/
send parsed
code to layer
above
Idle
[received
string
from EC]
Parser N
processing
Figure 8. Statechart Diagrams for PM and Parser
n (n = 1 to N) Layers (A2, Sequential case).
PM
Idle
[received
string
from EC]
Processing string
entry/determine parser
exit/send string to
parser n (1 <=n
<=N)
Parser n
(1 <= n <= N)
Idle
[received
string from
PM]
Parsing
string
[no error]/
send parsed
code to layer
above
Figure 9. Statechart Diagrams for PM and Parser n (n = 1
to N) Layers (A2, Intelligent case).
4.4.4. Architecture 4 (A4):
Dynamic/Automatic/Proactive Adaptable
Architecture.
4.4.4.1. Architecture Description. As can be seen from
Figure 12, A4 is almost identical to A2 except in the layer
for the parsers. A4 uses a Dynamically Modifiable Parser
block that lets the parser be modified dynamically.
There could be two ways in which the parser can be
modified dynamically:
1. Selection: Figure 13 shows the statechart diagrams for
the PM and the parser for this type of dynamic
modification. The selected parser processes the string.
[error code
from Parser 2]
Parsing string
Parser 1 [error code
from
processing
Parser 1]
Parser 2
processing
[no error]
Higher layers
processing
[processing
done]
Figure 10. Statechart Diagram for ES (A2, Sequential case).
compiler stores the data part of the parser in a separate
memory area and there are several techniques to detect
the starting memory address of this area. Using this
address it is possible to modify the memory contents
directly in a running system. In this case the PM is not
even necessary and may follow the architecture of Figure
14.
Here adaptation is proactive as the parser is chosen or
changed before the commands meant for the
parser
are sent. Also the adaptation is dynamic and automatic.
Here the evolution of the vocabulary is restricted
manually
by
not
sending
the
commands
not in the system’s vocabulary. Thus the system can
support up to N generations of vocabulary evolution (for
the Selection method of dynamic modification)
where each generation of the vocabulary has its
corresponding parser in the system; for the Modification
method no such limit on number of evolutions exists.
However, this architecture has its drawbacks: the
evolutions of the vocabulary have to be foreseen in
advance so that the parser for the new generations of the
vocabulary can be built (for the Selection method of
dynamic modification) and there
has to be manual
intervention to change parser. Also for the Modification
method deep knowledge of the parser’s data memory
addresses are required.
4.4.4.2. Architecture’s Adaptability.
1.E Detection: Here E detection is totally manual. The
user detects if the subsequent string to be sent to the
system belongs to a new generation or not.
ES
system to accept the strings of a different generation
(from that currently being used) – this change may be
made to the entire parser at a time or may be done
command-to-command basis.
Embedded System’s Higher Layers
Dynamically Modifiable
Parser
Output Manager
Parser Manager (PM)
Device Driver
Idle
[received string from EC]
PM
processing
Figure 12. Dynamic/Manual/Proactive Adaptable
Architecture (A4, Selection method).
PM
[parser determined]
Parser n (n = 1,2)
processing
[error code
from Parser n]
[no error]
Higher layers
processing
[processing
done]
Figure 11. Statechart Diagram for ES (A2,
Intelligent case).
2. S Recognition: Here S recognition is also totally
manual. If E   then S   too; i.e., the parser for
parsing the new string has to be changed.
3. System Change: The system changes by using a
different parser for the new string. This is done in the
following way:
a. For the Selection method of dynamic modification, the
EC
first sends Parser Select n (1 <= n <= N) to
instruct the ES to use the nth parser for subsequent
strings. The EC then sends the correct input string to
the system. Here the system changes automatically.
b. For the Modification method, the user changes the
executable binary code of the parser in the running
system to accept the strings of the new generation.
If an input string say “MODIFY” causes the ES
to change its memory contents then the system
change is automatic; if the memory contents changed
with human intervention then the system change is
manual.
4. How the Needed Evolution is Achieved: Here the
needed evolution is achieved by modifying the parser
currently being used. In the case of Selection method one
of the available parsers is selected (based on an input
command from the user); in the case of Modification
method, the user modifies the parser of the running
Parser n
(1 <= n <= N)
Idle
[received string
from EC]
Current
parser
processing
[received new
parser number
from current
parser]/ set
current parser =
new parser
Idle
[received
string from
PM]
Parsing
string
[change
parser
string]/
send
new parser
number
to PM
[legal string]/
send parsed
code to layer
above
Figure 13. Statechart Diagrams for PM and Parser in
A4 (Selection case).
Embedded System’s Higher Layers
Dynamically Modifiable
Parser
Output Manager
Device Driver
Figure 14. Dynamic/Automatic/Proactive Adaptable
Architecture (A4, Modification method).
4.4.4.3. Example. Figure 15 shows the statechart
diagrams for the EC and the ES to illustrate how the
architecture A4 handles the scenario of Figure 5 using the
Selection method. Here N = 2 and the parser selection
command is “CHANGEPARSER”. The ES toggles
between using Parser1 and Parser2 for the next input
string, each time the command “CHANGEPARSER” is
received.
Figure 16 gives the statechart diagrams for the EC and
the ES for the modification method wherein a command
“MODIFY” (it has parameters of memory addresses and
their new values) is used to change the contents of the
memory locations. Each time this command is received
the ES modifies its memory. Once the memory has been
suitably modified (i.e., the new parser has been created at
run-time) the EC sends the commands corresponding to
the evolved syntax (whose parser has just been created).
EC
ES
Uses Current
Syntax
Parser 1
processing
[CHANGEPARSER
received from EC]
Send CHANGE
PARSER to ES
Uses Evolved
Syntax
Parser 2
processing
Figure 15. Statechart Diagrams for ES and EC for A4,
Selection Method (here N = 2).
EC
ES
Normal
processing
Uses Current
Syntax
[MODIFY received
Send MODIFY
from EC]
to ES
Modifying
Uses Evolved
parser
Syntax
The ES used for implementing the architectures was a
test and measuring instrument running on a Motorola 68K
processor; the EC was a PC and the communication link
was an IEEE488 cable.
The architecture used for the implementations is shown
in Figure 17. The Parser Block of Figure 17 is a generic
term. For the implementation of each of the architectures
A1 through A5, this block had a different structure. In the
implementations N = 2. The processing done by the
system was to display the input string on the LCD
display. There was no output expected of the system
hence the Output Manager component was completely
absent. The test input strings were taken from an
extension of Table 1 and had about 10 strings in each
generation.
In A1 each build had only one parser. For a new
vocabulary the parser was changed, the code re-compiled
and loaded into the system and the system was restarted.
After this the system was responsive to the new
vocabulary. In fact, if architectures had not been
adaptable, A1 is the only architecture that could have
been used to respond to vocabulary evolution.
A2 was implemented using two parsers – one for each of
the vocabulary generation: parser1() and parser2(). For
the Sequential method, the PM first called parser1() and
in case parser1() returned error code, the PM then called
parser2(). For the Intelligent method, the ‘:’
character was used to distinguish between the
two
generations: if the input string had a ‘:’ then parser2() was
called, else parser1() was called. The entire code was
compiled at one time and loaded in
the ES. Once
the system started running it parsed commands received
LCD Display Controller
Figure 16. Statechart Diagrams for ES and EC for A4,
Modification Method.
Parser Block
4.4.5. Architecture 5 (A5):
Dynamic/Manual/Proactive Adaptable Architecture.
4.4.5.1. Architecture Description. Briefly, A5 uses an
external PC to parse the commands. This PC could be the
same as the EC or a different one. The PC that parses
the commands sends only the codes to the ES that are
interpreted by the Input Manager and sent to the higher
layers in the ES. Other layers in the ES perform the same
functions as before. Hence the architecture of the ES is
different from those in the previous cases (no parser is
present in the ES – only a code interpreter).
Here
adaptation is dynamic, manual and proactive. Also E
detection and S recognition are manual; however, there
is no system change for ES (only the PC changes).
IEEE488 Driver
5. Implementation
Figure 17. Architecture Used for Implementing ES.
from the PC, irrespective of the generation of the
command.
A3 was implemented similar to A1 and functioned
similarly.
For A4, both methods of dynamic modification were
implemented. In the first method, the system booted up
with parser 1 as the default. Once the ES received
CHANGEPARSER command from EC the PM toggled
the parser to which it sent the subsequently received
commands. Both the parsers implemented the
CHANGEPARSER command. As before the entire code
was compiled at one time and loaded in the ES.
In the second method of dynamic modification for A4,
greater binary-level knowledge of the embedded system
was required. The parser was implemented as a switch
case using numbers (which corresponded to the input
strings based on a hashing scheme). It was known where
in the memory the hash-table corresponding to this switch
statement was stored. So when the strings evolved, the
numbers corresponding to the new strings were directly
entered into the hash-table at the addresses known before
by sending an address modification command from the
PC. Once the hash-table contents were changed the
system parsed the evolved strings correctly.
In A5, no parser was implemented for the embedded
system. The Input Manager interpreted character codes
received from the PC and sent it to the LCD controller for
display. The parser was implemented on the PC and after
each change in the parser the PC application was restarted
and the new set of commands was sent to the ES. Here
once the ES’s code was loaded and started up, the system
was not disturbed again.
Each of the strategies mentioned in the Introduction
have been used: A1 uses the standard method,
A2(Intelligent) uses the algorithm selection strategy,
A4(Selection) uses the conditional expression strategy,
A4(Modification) uses the run-time binary code
modification strategy while A5 ports the component
outside the system.
Thanks to the clear architectural definitions,
implementations were straightforward – otherwise,
adapting to the newer vocabulary would have been more
difficult. From these implementations it was found that
the architectures A1 through A5 were all adaptable
towards vocabulary change. However, the relative speeds
of adaptation were different – the grading was A3 > A2
(Intelligent) > A2 (Sequential) > A4 (Selection) = A4
(Modification) > A5 > A1 (A5 > A1 as it was faster to
modify and restart the PC application than modifying,
loading and restarting the ES). Also the manual effort
involved in adapting the implementations was inversely
proportional to their relative speeds.
6. Conclusion
This paper has developed strategies for architecturedriven adaptation for embedded systems for the problem
of vocabulary evolution. More specifically, this paper has
presented:

techniques for evolution in embedded systems.
 architectures for an embedded system using the
proposed techniques for a
practical problem in
embedded
systems
–
that of vocabulary
evolution.
 the implementations, that ensue from the
architectures, that are
found to validate the
adaptability requirements.
While these techniques can be applied to solve other
problems as well for embedded systems, they are by no
means exhaustive. For example, if the protocol used for
remote communication were to be adaptable, maybe the
only way to enforce this adaptability is to have a library
of device drivers for the different protocols (and this may
or may not be feasible for embedded systems). However,
the techniques presented here give a glimpse of the
complexity involved in evolution for embedded systems.
We have not considered semantic or contextual issues in
this paper and this is an area for further exploration. Also
work is underway to more fully use the qualitative
analysis of the NFR framework [11] which will help
strengthen the comparison of the architectures (the
comparison of architectures in this paper is based on time
factor alone).
7. References
[1] P. Oreizy, M. M. Gorlick, R. N. Taylor, D.Heimbigner,
G. Johnson, N. Medvidovic, A. Quilici, D. S. Rosenblum and
A. L. Wolf, “An Architecture-Based Approach to Self-Adaptive
Software”, IEEE Intelligent Systems, May/June 1999, pp. 54 –
62.
[2] D. Notkin and W. G. Griswold, “Extension and Software
Development”, Proc. 10th Int.Conference on Software
Engineering, April 1988, pp. 274-283.
[3] S. Jarzabek and M. Hitz, “Business-Oriented ComponentBased Software Development and Evolution”, Int. Workshop on
Large-Scale Software Composition, August 1998, Vienna,
Austria, pp. 784-788.
[4] P. Oreizy, N. Medvidovic and R. N. Taylor, “ArchitectureBased Runtime Software Evolution”, Proc. Int. Conference on
Software Engineering , Kyoto Japan, April 1998, pp. 177 – 186.
[5] M. Shaw and D. Garlan, Software Architecture:
Perspectives on an Emerging Discipline, Prentice Hall, 1996.
[6] L. Bass, P. Clements and R. Kazman, Software
Architecture in Practice, SEI Series in Software Engineering,
Addison-Wesley, 1998.
[7] P. B. Worrell, “Design of Mainframe Firmware in an Open
Architecture Environment”, Hewlett-Packard Journal, April
1992, pp. 24-28.
[8] Standard Commands for Programmable Instruments
(SCPI), Version 1999, May 1999.
[9] P. A. Laplante, Real-Time Systems Design and Analysis –
An Engineer’s Handbook, IEEE Press, 1993.
[10] G. Booch, J. Rumbaugh and I. Jacobson, The Unified
Modeling Language User Guide, Addison-Wesley,1999.
[11] L. Chung, B. A. Nixon, E. Yu, J. Mylopoulos,
Non-Functional Requirements in Software Engineering,
Kluwer Academic Publishing, Boston, MA, 1999.