Adaptable Architecture Generation for Software AgentsUsed for Maintaining Embedded Systems

Lawrence ChungDept. of Computer ScienceUniversity of Texas at DallasRichardson, TXchung@utdallas.edu

Nary SubramanianFirmware Engineer, Anritsu Wireless Business UnitAnritsu CompanyRichardson, TXnarayanan.subramanian@anritsu.com

AbstractDiagnosis of problems in embedded systems by remote means has been an interesting idea for some time. Itpromises to bring virtually the full technical expertise in a company - the customer service engineers, fieldapplication engineers, and the R&D Engineers- directly to the field. This is expected to bring aboutremarkable changes in the quality and speed of service of the equipments in the field, and consequentbenefits to the company in terms of reduced costs and better image. Thus if a microwave oven broke down,it should be much easier to diagnose the problem and perhaps even rectify it if the R&D engineer whodeveloped the microwave oven could test the oven by remote means from her office desk/lab desk instead ofa service technician physically going to the field and checking up on the microwave oven. The softwareagents that let this "magic" happen need to be designed with care so that they help the technician orengineer to diagnose the problems quickly, correctly and remotely. One of the prime requirements for suchsoftware agents is that they should be adaptable. By adaptable, we mean that they should accomodatechanges in the environment. Thus they should be adaptable with respect to new requirements for remotediagnosis - they should let new tests be added easily, let the tests to be run selected dynamically, and theyshould also let the results of the tests be read or displayed easily. All these will help in higher quality ofremote maintenance in terms of speed, correctness and cost-effectiveness. Another dimension toadaptability is added by the fact that if the firmware in the embedded system is also adaptable, then greateradaptability in remote diagnosis is available and all this eases the job of the remote diagnoser to thatextent. An adaptable software agent combined with an adaptable embedded system together comprise whatwe call adaptable remote maintenance system (ARMS). In this paper we develop a tool called theAdaptable Software Architecture Assistant (or ASAA) that helps to develop adaptable architectures semi-automatically. ASAA uses the knowledge base properties of the NFR Framework (NFR standing for Non-Functional Requirements) to develop catalogs of architectural constituents such as components,connectors, patterns, constraints, styles and rationales, and then to search among these catalogs for themost appropriate adaptable architectural constitents. The developer of the ARMS can then use theseconstituents to generate adaptable architectures for ARMS - this includes an adaptable software agent onthe engineer's side and/or adaptable firmware on the embedded system's side. The architectures developedby ASAA are validated by implementing a real ARMS that uses a cell phone test equipment for the remoteembedded system. The experience from this implementation helps us conclude the effectiveness of the ASAAin developing adaptable architectures.

1. IntroductionDiagnosis of problems in embedded systems by remote means has been an interesting idea for some time[1,2,3]. It promises to bring virtually the full technical expertise in a company - the customer serviceengineers, field application engineers, and the R&D Engineers- directly to the field. This is expected tobring about remarkable changes in the quality and speed of service of the equipments in the field, andconsequent benefits to the company in terms of reduced costs and better image. Thus if a microwave ovenbroke down, it should be much easier to diagnose the problem and perhaps even rectify it if the R&Dengineer who developed the microwave oven could test the oven by remote means from her office desk/labdesk instead of a service technician physically going to the field and checking up on the microwave oven.One of the easiest ways to accomplish remote maintenance of embedded systems is to have a web-based

access to field equipments. This will let technical people use easy to available browsers to maintain theremote systems and learning curve on tools is considerably reduced. The necessity of such systems hasbeen argued in [7, 8, 9]. Examples of such systems can be seen from practical examples [7, 9, 10, 11, 12].

Software agents [4, 5, 6] help in the remote maintenance of embedded systems in the field. Softwareagents, for the purposes of this paper, are pieces of software that execute a task on behalf of the user [5].For remote maintenance purposes, the software agents are programs that execute specific tests whenspecified by the user. The software agents need to be designed with care so that they help the technician orengineer to diagnose the problems quickly, correctly and remotely. One of the characteristics required ofsoftware agents is adaptability [5, 13, 14]. By adaptable we mean that the software agents shouldaccommodate changes in the environment. Thus they should be adaptable with respect to new requirementsfor remote diagnosis – they should let new tests be added easily, let the tests be selected dynamically, andthey should also let the results of the tests be read or displayed easily. All these will help in higher qualityof remote maintenance in terms of speed, correctness and cost-effectiveness. There is an additional way inwhich such systems can be adaptable – if the firmware in the embedded system that is being remotelycontrolled is also adaptable then greater adaptability in remote diagnosis is available and all this eases thejob of the remote diagnoser to a greater extent. An adaptable software agent combined with an adaptableembedded system together comprise an Adaptable Remote Maintenance System (ARMS). Figure 1 showsthe general configuration of ARMS.

One of the most important problems associated with the development of ARMS is the generation ofadaptable architectures for ARMS. In this paper we present a tool called the Adaptable SoftwareArchitecture Assistant (ASAA) that helps to develop adaptable architectures semi-automatically.Architectures are composed of various factors: components, connections, patterns, constraints, styles andrationales [15, 16]. ASAA uses the knowledge base properties of the NFR Framework [17, 18, 19] todevelop catalogs of adaptability-related NFRs, catalogs of the architectural constituents, and theinterdependencies between the NFRs and the architectural constituents. The tool then searches theknowledge base for the most appropriate adaptable architectural constituents given the search criteria. Thedeveloper of the ARMS can then use the output of the ASAA to generate adaptable architectures forARMS. Since architectures are the first step in the development of the software solution, the final ARMSimplementation is also assured to be adaptable. The adaptable architectures may be developed for thesoftware agent and/or for the embedded system being controlled.

(Related work …)

Our survey of literature [20] has shown that there is no one accepted definition of adaptability. In this paperwe give our definition of adaptability that is based on a common thread occurring in several definitions ofadaptability.

In this paper we demonstrate the validity of the architectures generated by ASAA by implementing thearchitectures in a real ARMS that uses a cell phone test equipment for the remote embedded system. Thisvalidation helps us to draw conclusions about the effectiveness of the ASAA in developing adaptablearchitectures and identify its drawbacks.

Figure 1. General Configuration of ARMS

Embedded SystemRemote Diagnoser

Internet

ARMSThe ARMS system that we developed for validation of the ASAA had the configuration shown in Figure21. It had the following main components:

1. the expert diagnoser2. the central server3. the software agent4. the embedded system

Figure 2. Actual Configuration of ARMS Used for Validation

The expert diagnoser is the person who will running a series of tests on the embedded system. She will berunning a series of tests on the embedded system to confirm its normal working or to diagnose anyproblems with it. The expert diagnoser will be accessing the central server over the internet. The centralserver houses the software agents that will be running the various diagnostic tests on the embedded system.The software agents are programs that will run the diagnostics on the embedded system and retrieve results.These results are then displayed to the expert diagnoser by the central server. The embedded system is thelast part of ARMS – this is the system being analyzed. The embedded system is connected to the centralserver over a LAN (it could be internet as well, since the embedded system has an assigned IP address).The sequence diagram of the events is shown in Figure 3.

1 We borrowed some ideas from [23] for this implementation.

Embedded SystemRemote Diagnoser

Internet

Central ServerLAN

Figure 3. Sequence Diagram for ARMS Interactions

A basic architecture of ARMS is shown in Figure 4. The user interface is an html page that calls php scriptsto execute the software agents and display the results of the tests.

Central Server Software Agent EmbeddedSystem

Connect to ARMS Server

Serve ARMS Page

Select Test to Run

Kick Off Software Agent for the Test

Send Command

Send Result

Send Command

Send Result

...

Send Command

Send Result

Send Results

Display Results

At this point theDiagnoser decidesfurther course ofaction which mayinclude runningadditional tests

Diagnoser

Figure 4. Architecture for ARMS

The screen of the user interface is shown in Figure 5 and the output upon execution of the Basic Test isshown in Figure 6. The software agent for the basic test issues the same command “*IDN?” to theembedded system 50 times and retrieves the results. The command asks the embedded system to identifyitself. The software agent’s program is listed in Figure 7.

User Interface

Software Agent 1 Software Agent 2 Software Agent 3

Embedded System

Figure 5. Home Page for ARMS

Figure 6. Output after Selecting "Basic Test" in Previous Figure

Figure 7. Listing for the Software Agent that Executes Basic Test

Mechanisms for Adaptability in ARMSThe architecture of Figure 4 reveals one immediate technique for adaptability – adding a new softwareagent for a new diagnostic test. This is possible provided the architecture permits it. Another method foradaptation is to change an existing agent to perform the test in a different way – we mentioned that theBasic Test of Figure 5 does a test 50 times; if this number could be changed by the diagnostic engineer onthe fly then adaptation has been achieved. Both of these examples of adaptation are component-based andthere is no need to restrict adaptation in architecture only to components – any one or more of the

constituents of the architecture can help in adapting. The following list gives some of the possibleadaptation mechanisms in ARMS:

1. Component Adaptationa. Add new software agentb. Change existing software agentc. Delete software agent

2. Connection Adaptationa. Change the embedded system being testedb. Add/Delete/Modify connections between software agentsc. Add another embedded system for reference purposesd. Use a new port (such as serial) to connect to the embedded system

3. Pattern Adaptationa. Change the pattern of the architecture of ARMSb. Use a super-software agent that calls a series of software agents to perform series of

diagnostics on the embedded system4. Constraint Adaptation

a. Changing the timeouts on command responsesb. Changing the timeouts on test resultsc. Changing the number of times the tests are performedd. Changing the sequence of tests performed

5. Style Adaptationa. Changing the style of architectureb. Adding another style of architecture – using hybrid styles

6. Rationale Adaptationa. Changing the rationale for the architecture – so that some other NFRs may be compromised or

better satisfied for the sake of enhancing adaptabilityb. Adding new rationales to the architecture – adaptability may need reliability to be satisfied as

wellc. Adopting industry standards may involve rationale adaptation.

7. Combination of one or more of the above

These mechanisms will be revisited after we have introduced the NFR Framework in the next section. Itshould be noted that the mechanisms for adaptability listed above relate to the server side of ARMS only.In fact, several techniques exist for adaptability on the embedded system side [21, 22] as well. If thesetechniques are used in combination, then there are numerous mechanisms for adaptability in ARMS.

Populating the KB

Figure 8. SIG for Adaptable Components

Table 1. Description of Claims in the SIG for Components

Claim DescriptionClaim1 The Changeable Basic Test Software Agent component’s specification states (not given

here) that it facilitates changing repetition count.Claim2 The Changeable Basic Test Software Agent component’s specification states (not given

here) that it facilitates changing repetition count; additionally it reports errors.Claim3 Test Sequence Controller component’s specification states that it is designed for helping

to change test sequences.Claim4 New Software Agent Add Component is designed for adding new software agents.Claim5 The Changeable Basic Test Software Agent component reports errors when multiple

users try executing the Basic Test at the same time – from component specification.

Adaptability[Homepage,Server, ARMS]]

Adaptability [SoftwareAgent, Server, ARMS]

Adaptability[ARMS]

Adaptability[Server, ARMS]

Adaptability[Embedded System, ARMS]]

Changeability[Homepage, Server,ARMS]

Adaptability [Communication, Server, ARMS]

Creatability[New Homepage, Server, ARMS]

Changeability[SoftwareAgent,Server, ARMS]

Creatability[SoftwareAgent,Server, ARMS]

New SoftwareAgent AddComponent

ChangeableBasic TestSoftware

Agent

Claim1Claim2

Deletability[SoftwareAgent,Server, ARMS]

Changeability[Communication Media,Server, ARMS]

Changeability[Communication Speed,Server, ARMS]

Claim3

Claim4

Changeability[Repetition Count,Software Agent,Server, ARMS]

Changeability[Test Sequence,Software Agent,Server, ARMS]

Addability[SoftwareAgent,Server, ARMS]

Creatability[Super Agent,Server, ARMS]

Reliability[ARMS]

ChangeableBasic Test

Software AgentWith ErrorReporting

Reliability[Multiple Users,ARMS]

Reliability[MultipleAgents,ARMS]

TestSequenceController

Claim5

Modifiability[ExistingConnections betweenSoftware Agents,ARMS]

Adaptability[ARMS]

Adaptability[Connections between Software Agents, ARMS]

Adaptability[Connections to Embedded System, ARMS]

ProcedureInvocation

MessagePassing

Creatability[New Connections betweenSoftware Agents,ARMS]

Deletability[Existing Connections betweenSoftware Agents,ARMS]

Modifiability[No. of Parameters, ExistingConnections betweenSoftware Agents,ARMS]

Modifiability[Type of Parameters, ExistingConnections betweenSoftware Agents,ARMS]

Changeability[Connections to Embedded System, ARMS]

Creatability[Connections to Embedded System, ARMS]

Creatability[Links betweenSoftware Agents,ARMS]

Creatability[Links betweenHomepage andSoftware Agents,ARMS]

Changeability[Connected Port, Connections to Embedded System, ARMS]

Changeability[Connected System, Connections to Embedded System, ARMS]

Figure 9. SIG for Connections

Figure 10. SIG for Patterns

Coupling betweenComponents[Between Homepage andSoftware Agents, ARMS]

Modifiability[ARMS]

Addability[New Software Agents, ARMS]

Addability[New Connections, Software Agents,ARMS]

Changeability[Connections,Software Agents,ARMS]

RingSequential

Replaceability[Software Agents,ARMS]

Star

Adaptability[ARMS]

Coupling betweenComponents[Between Software Agents,ARMS]

Coupling[ARMS]

Figure 11. SIG for Constraints

Performance[ARMS] Diagnosability

[ARMS]

ProblemDetectability[ARMS]

ProblemLocateability[ARMS]

Batch Incremental

Time[Testing, ARMS]

ProblemSolvability[ARMS]

Space[Testing, ARMS]

High ErrorSeverity[ARMS]

Adaptability[ARMS]

Error Performance[ARMS]

ErrorDetectability[ARMS]

ErrorRecovery[ARMS]

Figure 12. SIG for Styles

Performance[ARMS]

Modifiability[ARMS]

Creatability[ARMS]

Changeability[ARMS]

Object-Oriented Layered

Space[ARMS]

Reusability[ARMS] Time

[ARMS]

Adaptability[ARMS]

Figure 13. SIG for Rationales

Generating Adaptable Architectures

1. Architecture Permitting Modifiable Repeat CountThe first architecture that we will generate will permit a modifiable repetition count to be associated withtests. We will start with components - the starting NFR softgoal for components is given as:

ChangeabilityRepetitionCountSoftwareAgentServerARMS and the contribution type chosen isMAKE.

Adaptability Reliability

Adaptability[ARMS]

Adaptability[Remote Maintenance,ARMS]

Adaptability[Error Detection,ARMS]

Adaptability[Test Effectiveness,ARMS]

bilitye Maintenance,

Enhanceability[Remote Maintenance,ARMS]

Changeability[Mechanisms,Error Detection,ARMS]

Performance[Mechanisms,Error Detection,ARMS]

Creatability[Tests, Test Effectiveness, ARMS]

Simultaneity[Tests, Test Effectiveness, ARMS]

No Simultaneity[Tests, Test Effectiveness, ARMS]

High Simultaneity[Tests, Test Effectiveness, ARMS]

The output from the tool is:

<<component>>ChangeableBasicTestSoftwareAgent

For connections, MAKE-contributions for the NFR softgoalCreatabilityLinksBetweenHomepageAndSoftwareAgents was chosen as the criteria; for patterns, MAKE-contribution for ChangeabilityConnectionsSoftwareAgentsARMS was chosen as the goal; for constraintsMAKE-contribution for ErrorDetectabilityARMS was chosen as the selection criteria; for styles, MAKE-contribution with the NFR softgoal ChangeabilityARMS was chosen; and for rationales, MAKE-contribution with the NFR softgoal ModifiabilityRemoteMaintenanceARMS was chosen. The output fromthe tool for these inputs are given below.

<<connection>>ProcedureInvocation

<<pattern>>Sequential

<<constraint>>Batch

<<style>>Layered

<<rationale>>Adaptability

Using this information the architectect can generate the architecture given in Figure 14 that will achieve thevariable repetition count.

Figure 14. Generated Architecture for Modifiable Repetition Count

2. Architecture for Adding a New Software Agent

Homepage

Changeable BasicTest Software Agent

Advanced TestSoftware Agent

Measurement TestSoftware Agent

Here we started the search for components that MAKE-satisfice the NFR softgoalAddabilitySoftwareAgentServerARMS. The result was the component:

<<component>>NewSoftwareAgentAdder

With the other constituents of architecture same as before, the architecture for adding new software agentbecomes as shown in Figure 15.

Figure 15. Generated Architecture for Adding New Software Agent

3. Architecture for Changing the Sequence of TestsWe started the search for components with those that MAKE-satisficeChangeabilityTestSequenceSoftwareAgentServerARMS. The result was the component:

<<component>>TestSequenceController

Using this component, and the other constituents same as before, the architecture of Figure 16 can begenerated.

4. Considering CorrelationsSo far the rationale for the architectures we developed has been adaptability. Suppose we wanted thearchitecture to be reliable as well. In that case we start the search with the following parameters:MAKE satisfice the NFR softgoal ChangeabilityRepetitionCountSoftwareAgentServerARMSMAKE correlate the NFR softgoal ReliabilityMultipleUsersARMS

Homepage

Basic TestSoftware Agent

Advanced TestSoftware Agent

MeasurementTest Software Agent

New SoftwareAgent Adder

In that case the tool ASAA comes up with the following output:

<<component>>ChangeableBasicTestSoftwareAgentWithErrorReporting

It should be noted that the specification of this component (which is not given here) could be that it permitsonly one user at a time to perform the Basic Test. In that case, if a search is made for architecturalconstituent rationale with the criteria of MAKE-satisfice NoSimultaneity then the rationale selected by thetool is:

<<rationale>>Reliability

The result of using this component is the architecture of Figure 17.

Figure 16. Generated Architecture for Changing Test Sequences

Figure 17. Architecture Considering Correlations

Homepage

Changeable BasicTest Software AgentWith Error Reporting

Advanced TestSoftware Agent

Measurement TestSoftware Agent

Homepage

Basic TestSoftware Agent

Advanced TestSoftware Agent

MeasurementTest Software Agent

Test SequenceController

Validation of Generated Architectures

1. Validation of Architecture Permitting Modifiable Repeat CountThe architecture of Figure 14 was implemented and the result is the homepage shown in Figure 18.

Figure 18. Implementation of Architecture of Figure 14

Now, the user can enter the repeat count and the system will execute the Basic Test only that many numberof times. The upper limit depends on the embedded system being tested and the timeouts associated withthe constituents of the architecture used.

2. Validation of Architecture Permitting Additions of SoftwareAgentsHere we show the validation of the architecture of Figure 15. Implementing this architecture resulted in thehomepage shown in Figure 19. The user can now add new agents and execute them.

Figure 19. Validation of Architecture of Figure 15

3. Validation of Architecture for Changing Test SequenceIn this section we validate the architecture of Figure 16. Figure 20 shows the homepage for theimplementation of this architecture.

Figure 20. Validation of Architecture of Figure 16

As can be seen in Figure 20 the sequence in which the tests have to be run can be given and the tests will berun in the chosen sequence when “Run Test Sequence” button is clicked.

The architecture of Figure 17 was validated similar to the architecture of Figure 14. Two userssimultaneously tried to run the Basic Test and the user who clicked first got to run the test while the seconduser got the message “Remote System Busy”. The second user had to retry after some time to run his test.

4. ObservationsWe have found the ASAA tool to be very helpful to the architect in generating starting points forarchitecture development which the architect can then complete as required. The browsing feature of thetool is useful to browse the contents of the knowledge base – the various NFR softgoals which are neededfor starting the search can be seen in the browser. Also, the definition of the NFR softgoal or any other

element of the NFR Framework can be seen using the “Frame” icon on the icon panel: any element on thebrowser can be viewed in detail on the Editor panel using the Frame icon. These help the architect tochoose a better starting point for search.

In this application domain we have demonstrated simple adaptation architectures – the field of human-computer interaction being vast, especially in the internet domain, there are much more variety inadaptation mechanisms than we have indicated. However, our tool can be easily used in these other areas aswell.

One of the observations made is the effort vs gain factor. The way we have indicated the tool’s usage in thispaper may make this factor look bad. However, the whole purpose of this tool is to store domainknowledge related to architectures. Once stored, it is captured for reuse. Thus, the more the population ofthe knowledge base the better the variety of architectural constituents the tool can generate. Then the gainis much more than the effort involved in populating the knowledge base.

Finally it should be noted that the architectural constituents the searches come up with all satisfy NFRsrelated to adaptability. Hence the architecture developed using these searched constituents will be adaptableas well.

References[1] T. White and N. Ross, “Fault Diagnosis and Network Entities in a Next Generation NetworkManagement System”, Proceedings of EXPERSYS-96, Paris, France, pp. 517-522.[2] A. Bieszczad, “Advanced Network Management in the Network Management Perpetuum MobileProcura Project”, Carleton University, Department of Systems and Computer Engineering, TechnicalReport No. SCE-97-07, March 1997.[3] F. Hapgood, “Look, Ma – No People!”, Darwin Magazine, July 2001,http://www.darwinmag.com/read/070101/ma.html[4] http://www.davidreilly.com/topics/software_agents[5] H. S. Nwana and D. T. Ndumu, “An Introduction to Agent Technology”, Lecture Notes in ArtificialIntelligence No. 1198, “Software Agents and Soft Computing: Towards Enhancing Machine Intelligence”,Edited by H. S. Nwana and N. Azarmi, Springer-Verlag, Berlin, 1997, pp. 3-26.[6] M. Tokoro, “Agents: Towards a Society in Which Humans and Computers Cohabitate”, Lecture Notesin Artificial Intelligence No. 1069, “Distributed Software Agents and Applications”, Edited by J. W.Perram and J. P. Muller, Springer-Verlag, Berlin, 1996, pp. 1 – 10.[7] R. M. Smith, “A Real-Time Weather Station”, Dr. Dobb’s Journal, October 1998, pp. 40-46.[8] B. Cole, “Remote Embedded Debugging In a Connected World”, Embedded.com, August, 2001,http://www.embedded.com/story/OEG20010822S0042[9] A. Laugier, N. Allahwerdi, J. Baudin, P. Gaffney, W. Grimson, T. Groth and L. Schilders, “RemoteInstrument Telemaintenance”, Journal of Computer Methods and Programs in Biomedicine, Volume 50,Issue 2, 1996, pp. 187-194.[10] Note on DCB Access Switch available from http://www.statmux.com/notes/9606as.html[11] G. Fermani, and M. Zarfino, “A Software Environment to Execute Automatic Operational Sequenceson the ITER-FEAT DTP Facility”, Fusion Engineering and Design, Volume 58-59, November 2001, pp.499-505.[12] C. Iaccarino, M. A. Sigel, R. E. Taylor Jr., D. Perozzi, A. Staikos and P. A. Morreale, “HoneyWEB:Embedded Web-based Control Applications”, Proceedings of the 20th IEEE Real-Time SystemsSymposium, 1999, pp. 214-127.[13] I. A. Ferguson, “Toward an Architecture for Adaptive, Rational, Mobile Agents”, Lecture Notes in AINo. 1198, Proceedings of 3rd European Workshop on Modelling Autonomous Agents and Multi-AgentWorlds (MAAMAW-91), 1992, pp. 249-262.[14] R. Rejaie, “An End-to-End Architecture for Quality Adaptive Streaming Applications in the Internet”,Ph.D. Thesis, University of Southern California, USC/CS-Tech Report-99-718, December, 1999.

[15] Shaw, M., and Garlan, D., Software Architecture: Perspectives on an Emerging Discipline, PrenticeHall, 1996.[16] Bass, L., Clements, P., and Kazman, R., Software Architecture in Practice, SEI Series in SoftwareEngineering, Addison-Wesley, 1998.[17] Chung, L., Nixon, B.A., Yu, E. and Mylopoulos, J. Non-Functional Requirements in SoftwareEngineering, Kluwer Academic Publishers, Boston, 2000.[18] Mylopoulos, J., Chung, L., Liao, S.S.Y., Wang, H., Yu, E. “Exploring Alternatives DuringRequirements Analysis”, IEEE Software, Jan/Feb. 2001, pp. 2 – 6.[19] Mylopoulos, J., Chung, L., Nixon, B. “Representing and Using Nonfunctional Requirements: AProcess-Oriented Approach”, IEEE Transactions on Software Engineering, Vol. 18, No. 6, June 1992, pp.483-497.[20] Subramanian, N., and Chung, L. “Software Architecture Adaptability – An NFR Approach”, to appearin the Proceedings of International Workshop on Principles of Software Evolution, Vienna, September2001.[21] Subramanian, N., and Chung, L. “Architecture-Driven Embedded Systems Adaptation for SupportingVocabulary Evolution”, Proceedings of the International Symposium on Principles of SoftwareEvolution, IEEE Computer Press, Nov. 2000, pp. 144 – 153.[22] Chung, L., and Subramanian, N., “Architecture-Based Semantic Evolution: A Study of RemotelyControlled Embedded Systems”, Proceedings of the International Conference of Software Maintenance,IEEE Computer Press, Florence, Italy, November, 2001, pp. 663-666.[23] J. Humphrey, V. Malhotra and V. Trujillo, “Developing Distributed GPIB Test Systems Using GPIB-ENET/100 and Existing Ethernet Networks”, National Instruments Application Note No. 103, June 2000.