Internet access to real equipment at computer architecture laboratories using the java/CORBA paradigm

Internet access to real equipment at computer architecturelaboratories using the java/CORBA paradigm$

F.J. GonzaÂ lez-CastanÄ o a,b, L. Anido-RifoÂ n b,*, J. Vales-Alonso b,M.J. FernaÂ ndez-Iglesias b, M. Llamas Nistal b, P. RodrõÂ guez-HernaÂ ndez b,

J.M. Pousada-Carballo b

aVisiting Computer Sciences Department, University of Wisconsin-Madison, USAbDepartamento de TecnologõÂas de las Comunicaciones, Universidad de Vigo, Vigo, Spain

Received 6 June 2000; accepted 2 October 2000

Abstract

Laboratory courses in Engineering and Computer Science are not always easy to implement usingInternet-based distance education. Simulation has its limits, when compared to working with the real thing(like a computer board). The system we present in this paper provides remote access to real equipment usedin a Computer Architecture laboratory. It uses CORBA technology to manage real equipment as justanother set of CORBA objects whose operations can be invoked remotely by students. Apart from acces-sibility advantages for students, there are important bene®ts for academic institutions. Our system allowsdi�erent con®gurations that provide di�erent levels of equipment availability, using fewer resources than aconventional laboratory, and reducing costs. This paper describes our system and its functional archi-tecture, and analyzes economic savings for academic institutions. # 2001 Elsevier Science Ltd. All rightsreserved.

Keywords: Distance education and telelearning; Public spaces and computing; Computer-mediated communications;Distributed learning environments

0360-1315/01/$ - see front matter # 2001 Elsevier Science Ltd. All rights reserved.

PII : S0360-1315(00)00056-7

Computers & Education 36 (2001) 151±170www.elsevier.com/locate/compedu

$ Partially supported by European Commission/CICYT grant TIC 1FD97-0100 and Motorola Inc. throughISTEC.

* Corresponding author. ETSI TelecomunicacioÂ n, Campus, 36200 Vigo, Spain. Tel.: +34-986-812174; fax: +34-986-812116.E-mail address: [email protected] (L. Anido-RifoÂ n).

1. Introduction

Internet/WWW-based educational systems gather the advantages of both distance educationand computer-based training. Therefore, they are a suitable platform where the learning processcan be successfully carried out. Learning involves di�erent phases, from the acquisition of basicand essential concepts to the use of this knowledge in practical situations.In an Internet-based environment, the implementation of the ®rst phases of the learning

process Ð theoretical lectures Ð is currently straightforward, given the help provided by avail-able authoring systems and course tools (see Goldberg & Salari, 1997). It is not so easy to developlaboratory courses. Current approaches to virtual laboratories over the Internet are mainly divi-ded into two groups: (1) the use of educational simulators and (2) remote access to real labora-tory equipment. In the former case, students are provided with simulators of computer systems.They use them to study the (simulated) behavior of the real experiment. In case of remote access,students control real equipment (placed in the academic institution), via the Internet.Although it is possible to use simulation to teach many practical skills to students, there exist

several situations where the use of the real equipment is compulsory: either the development of asimulator from scratch is not feasible or real industry equipment is too complex to simulate. Inthis case, in order to design a distance education environment, we need to manage real instru-ments and equipment remotely. This paper describes a system that is centered in this remoteoperation context: we have to carry out the experiment as if students were in the actual labora-tory, and we need to provide them with the output and results of every action, command ormodi®cation, as the experiment takes place.To achieve this goal, we provide our computer architecture students with a java/CORBA-

based environment where real equipment (used in the conventional laboratory) is encapsulated asCORBA objects that can be controlled remotely via the Internet. Apart from student accessibilityadvantages, this solution generates important savings for the institution responsible for main-taining laboratory facilities, both in equipment and sta�.The rest of this paper is organized as follows: in Section 2 we describe our conventional com-

puter architecture laboratory. In Section 3 we discuss some relevant background in remoteoperation of laboratory equipment. The description in Section 2 is used in Section 4 to char-acterize the requirements of our remote-access laboratory. Section 5 describes an assignmentexample for the resulting laboratory. Sections 6 and 7 cover system architecture and func-tionality. Sections 8 and 9 analyze bene®ts for students and academic institutions. Finally, con-clusions are presented in Section 10.

2. Our conventional computer architecture laboratory

IngenierõÂ a de TelecomunicacioÂ n (Telecommunication Engineering) at Vigo is a 5-year program.The ®rst 3 years are common to all specialties, and are devoted to fundamentals on mathematics,physics, electronics, signal processing and computer science. The last 2 years are oriented towardsspecialization: students can choose among electronics, signal processing/communications, andtelematics. Telematics is a European concept that corresponds to computer communications, in abroad sense.

152 F.J. GonzaÂlez-CastanÄo et al. / Computers & Education 36 (2001) 151±170

Arquitectura de Ordenadores II (Computer Architecture II) is a third year laboratory course. Itis compulsory for all students pursuing a degree in Telecommunication Engineering. It has aworkload of 6 credits (60 h) and is devoted to real microprocessor architectures and (low-level)computer communications. Students must take two previous theoretical courses related to com-puter architecture: Fundamentals of Computing I (machine and assembly programming), andComputer Architecture I (fundamentals of microprocessor architectures and computer commu-nications). Practice in both introductory courses is implemented by means of simulation. Bothcourses are based on pedagogic computer architectures designed speci®cally for them.Initially, students were provided with MS-DOS simulators covering microprogramming,

micro-machine data path organization, assembly programming, communications, etc. Nowadays,we have replaced PC simulators by an integrated simulation-based distance-learning system(Llamas, Anido-RifoÂ n & FernaÂ ndez-Iglesias, 1999). It is a 100% pure java system that deliversjava simulators through the Internet, which can be run on any computer and operating system.The system also includes several communication tools, both synchronous (chat, talk, virtualwhiteboard) and asynchronous (mail, bulletin board, notebooks), and a tutoring and monitoringtool.To cover the technical objectives of Computer Architecture II, laboratory workstations are

composed of an Arnewsh Inc. SBC68K board1 (Appendix C) connected via RS232 to a Linux PC(with all necessary software tools: assembler, linker, editor, etc.). Students interact with the boardusing a PC terminal emulator, and several buttons and switches. We consider that the use of realequipment is compulsory in this learning stage (FernaÂ ndez-Iglesias, GonzaÂ lez-CastanÄ o & Pousada-Carballo, 2000). After acquiring basic computer architecture concepts using simulation, studentsneed to practice with real processors they will face in their professional activities.

3. Background discussion

Enloe, Pakula, Finney and Haarland (1999) and Shen et al. (1999) have recently proposed twosystems for remote operation of laboratory equipment. The ®rst system has been implementedusing LabVIEW (National Instruments Corporation, 2000), a commercial package. The systemof Shen et al. is programmed in java (client side applets) and visual c++ (server side). Bothsystems allow remote control of laboratory instruments via Internet (the second one uses TCP/IPsockets to link clients and server).The system of Enloe et al. (1999) controls a physics experiment performed on a specialized

device. In its current version, it does not support simultaneous accesses of di�erent students. Thesystem of Shen et al. (1999), AIM-Lab, is used to perform experiments on a CMOS chip. It canhandle simultaneous accesses easily, because their particular experiments can be submitted asbatch jobs, whose output is delivered in FIFO order.Unfortunately, this is not our case. Our experiments must be performed interactively and in

real-time. They involve the use of a debugging kernel in the target device, and command outputmust be immediately available. A straightforward (and expensive) solution is a di�erent target

1 The SBC68K board has a Motorola 68000 CPU and diverse peripherals: serial and parallel port controllers, diskcontroller and timer. It runs a debugging kernel that handles I/O via a VT-100 terminal.

F.J. GonzaÂlez-CastanÄo et al. / Computers & Education 36 (2001) 151±170 153

device per potential student. This solution is unnecessary, from a statistical point of view, sincenot all students access the system simultaneously. Therefore, one of the main contributions of oursystem is that it can assign target devices dynamically, from a pool, while there are target devicesavailable. It is quite similar to the way a telephonic central assigns connections to incoming calls.Of course, we have learned from the lesson of previous work: our client is also a platform inde-pendent java application, and our server processes are fast c++ programs.As another research goal, we explore the use of CORBA technology (Siegel, 1996) to embed

real laboratory instruments in a distributed Internet-based, remote control educational environ-ment. As a result (GonzaÂ lez-CastanÄ o, Anido-RifoÂ n, Pousada-Carballo, RodrõÂ guez-Hernandez &LoÂ pez-GoÂ mez, 2001), we combine the advantages of java (platform/OS independence, web-oriented programming) and CORBA (intelligent object technology, network/OS independence).A CORBA design is intrinsically open, since all interfaces are standardized, and admits futureexpansion (new objects inherit the properties of old ones, and coexisting new objects can obtainthe identities of old ones using standard CORBA services).With this system, we have completed the integration of all our computer architecture courses in

distance education tools.

4. Internet-based access to the real equipment used in Computer Architecture II

4.1. Objectives

From an architectural point of view, our design is driven by the following system requirements:

1. Client platform/OS independence, to let a wide range of computers access our laboratory.We use the most popular language to obtain platform independence, java (Gosling, Joy &Steele, 1996).

2. Internally, our system must manage all boards available and assign them on demand tothose students that want to access the system. It must also have an inactivity controlmechanism, to prevent useless occupancy.

3. Clients access authentication by means of a user/password control list.4. The client must be an IDE (Integrated Development Environment).5. System management must be easy for both server and client.6. Server processes must be fast and e�cient. For that reason, we implement them in c++.

Our main goal is providing real equipment used in the conventional Computer Architecture IIlaboratory with remote access. Our system must be a full-featured environment: it must imple-ment all actions students can perform in the real laboratory:

1. Methods for emulating the communication between a SBC68K board and the user PC.Students should work as if they were sitting in front of a PC connected to a SBC68K via anull modem cable.

2. The client must have the capability of launching local applications: an ASCII editor and anassembler.


3. As an alternative to local assembly, and to speed up interaction, the system must alsoinclude remote (server side) S-Record2 assembly. Thus, we support both o�-line work (localassembly) and on-line work (remote assembly). Obviously, students are not required to havea local assembler, in any case. Independently of local or remote assembly mode, all outputmessages are sent to the client screen.

4. Server ®le download. This is needed because assemblers generate listing ®les that are essen-tial for debugging purposes.

5. Local/remote machine-code ®le upload to the SBC68K. This is necessary to transmitassembler output to SBC68K memory.

6. The physical interface at the board (buttons and switches) must be remotely accessible as aset of graphical ``buttons'' at the client.

4.2. Description of the environment

In our system, students access the SBC68K board using a client. The client provides a completeeducational environment, since it handles all applications used in the conventional ComputerArchitecture II laboratory:

1. Communication with the SBC68K board. SEYON3 terminal emulator was used for this pur-pose in the conventional laboratory (Fig. 1). In our system, the client at the student's com-puter performs this task (Fig. 2).

2. Editor. The client invokes the preferred local editor for assembly ®les.3. Assembler. It is invoked automatically by clicking a button. Program assembly and linking is

done transparently, locally or remotely, according to user preferences.4. Uploader. A built-in uploader is provided. By clicking a button, programs are uploaded to

the board, from the remote or the local ®le system.

Users can change system con®guration easily by means of two dialog windows: communicationcon®guration (user name, password and name server location) and con®guration of externalapplications used by the client (text editor and assembler).

4.3. Interaction with the SBC48K board

Once a client is authenticated by the system, it is allowed to interact with a SBC68K board andthe laboratory tools. Fig. 2 shows the client screen. We can clearly distinguish two parts. TheSBC68K board communication area (upper half) is seen by the SBC68K board as vt100 terminal,and displays user interaction. The messages area (lower half) displays system messages, likeinitialization or results of assembler operations.SBC68K buttons are remotely pressed using command bar ``buttons'' (icons resembling the real

counterparts), which increases the feeling that the real board is actually being used. For example,the hexagonal button is linked to RESET in the assigned board.

2 A format used to upload linker output to a SBC68K board.3 SEYON is a common application in Linux distributions.


4.4. The assembly process

It is initiated by clicking the ASM button in the command bar in Fig. 2. The assembly processmay take place either in the student's computer or in the server. If students want local assembly(it is not compulsory), they must install a suitable assembler. Errors or warnings produced by theassembler are shown in the messages area (assembly mode is transparent from the point of viewof user feedback).The assembly operation generates di�erent ®les. Among them, an S-record ®le Ð to be sent to

the board Ð and a listing ®le that contains the symbol table, essential for debugging. In the caseof remote assembly, all these ®les can be downloaded from the server to the student computer.Finally, users need to upload S-record ®les to the SBC68K board. Again, assembly mode (local

or remote) is transparent from the point of view of ®le upload.

4.5. Log Files

The client software o�ers the possibility of creating and managing log ®les. Users are allowedto create, save and open them. Log ®les contain information from the SBC68K boardcommunication area and messages area. They also include a header with speci®c informationrelated to the active session. These ®les are useful for debugging purposes or to monitor studentactivity.

Fig. 1. SEYON terminal emulator (conventional laboratory).


5. An application example

Here we describe an assignment using our system. Students receive the text of the assignmentvia e-mail. They are required to use their own system calls to implement the user interface for asimple arithmetic algorithm (calculating a matrix determinant, for example). All client tools willbe used. Attached to the text, there is an assembly ®le containing a kernel which disables clockinterrupts and contains:

1. Serial port I/O handlers (notice the serial port is virtually connected to the SBC68K boardcommunication area). The input handler ®lls an incoming bu�er. The output handler emptiesan outgoing bu�er.

2. A skeleton for system calls (using traps).

Fig. 2. Remote access to a SBC68K board. Client side.


Students are required to write a put trap, which writes characters to the outgoing bu�er, anda get trap, which takes characters from the incoming bu�er (and echoes them to the screen). Ina ®rst stage, they are allowed to disable I/O interrupts and implement put and get using spin-waiting. For this, they will use the editor, the assembler and the SBC68K debugger. Server-sidelogs of all their actions measure their skill. A very simple script, which counts debuggerprompts, can be used to weight their grade.In a second stage, I/O interrupts must be enabled. This makes step debugging impossible. As a

result, they will have to press command bar RESET or ABORT repeatedly, and check memorycontents using text commands in the SBC68K board communication area.Finally, they must submit, via e-mail, three ®les. Two of them contain the modi®ed kernel and the

arithmetic example. The third one is a client-side log showing operation of the arithmetic program.

6. System Architecture

Recently, traditional client/server distributed systems are being substituted by a more powerfulparadigm based upon object distribution. According to this paradigm, each resource is an objectthat is identi®ed uniformly all over the distributed environment. Objects are able to migrate todi�erent locations without changes in their identity and behavior.Our remote access system is based in this paradigm, and speci®cally in CORBA (see Appendix

A). Using CORBA, we can create object-based distributed applications in a simple and easy way,with all the advantages of distributed object-based programming.The overall system architecture is depicted in Fig. 3. There are several modules that can be

clearly identi®ed:

1. Client. It is the application that wants to establish remote access to a SBC68K board. It mustnegotiate with server-side processes to get a free board, and with board-control processes toactually access the board and use additional features.

2. Name server. It acts as a bridge used by clients and board-control processes to access thesystem. At startup time, the system manager process registers itself in the name server, sothat other processes can obtain manager identity, exchange messages with it and enter thesystem.

3. System manager process. It is responsible for two di�erent tasks. The ®rst one is registeringnew boards in the system. The second is guaranteeing that, in case there is an availableboard, any authenticated client can use it.

4. Board-control processes. Each of them controls a SBC68K board and other resourcesaccessible by the client in the server ®le system (®les, I/O, execution of programs, etc.).

5. HTTP server. It is used as a main door to the system. It is essential, because all modules inthe system need to contact the name server. Since there is no way to ®nd its identity auto-matically, it has to be published somewhere, and obtained somehow. Therefore, we decidedto use an HTTP server to publish name server identity. Clients must be con®gured to knowthe URL of the HTTP server.

The most important interactions that take place in our system are shown in Fig. 3 andexplained below (note: each of the interactions below correspond to the numbered paths in Fig. 3).


1. When the name server is executed, it publishes a ®le with its identity at the HTTP server.2. The manager process obtains name server identity from the HTTP server.3. The manager contacts the name server and registers itself.4. New board-control processes obtain name server identity from the HTTP server.5. New board-control processes look for manager's identity in the name server.6. Board-control processes register themselves in the manager.7. A client obtains name server identity from the HTTP server.8. The client locates the manager using the name server.9. The client deals with the manager to ®nd an empty board.10. The client uses the board and the server ®le system using the board-control objects.

The reader may think that the presence of the name server is unnecessary, since any processcould get manager identity directly if it were published in the HTTP server. However, we decidedto choose this approach (HTTP server+name server) having in mind system generality andscalability. The name server could be used in the future as the kernel of an open communicationsystem based in CORBA, which would include our present objects as a subsystem.

Fig. 3. System architecture.


7. Functional description

As we show in Fig. 4, the previous architecture can be re®ned into several CORBA objects. Inthis section we will describe more accurately the interactions that take place between objects. Wehave divided those interactions into several functional modules to clarify the system behavior. Weuse x::y CORBA IDL syntax, where x is an object in Fig. 4 and y is one of its methods.

7.1. Connection module

This group includes operations to allow client components to ®nd server objects. Four objectsare involved:

1. NameServer connection subsystem. When started, it publishes a reference containing itsidentity, using the standardizedORB::object_to_stringmethod. The reference can be accessedvia HTTP.

2. Manager connection subsystem. Initially, the Manager obtains NameServer identity usingHTTP. Afterwards, it executes the NameServer::bind operation, which associates Manageridentity to a well-known name (we chose ``ManagerSBC68K'').

3. Board-control processes. Each board control process obtains NameServer identity viaHTTP. Next, the process asks NameServer for the identity of the object in entry

Fig. 4. System object-oriented architecture.


``ManagerSBC68K'' using theNameServer::resolvemethod. Then, it executes aManager::registeroperation to register itself in the system.

4. Client connection subsystem. The Client locates the Manager using the HTTP server andNameServer. Afterwards, it invokes Manager::get to obtain an empty board in the system, ifavailable.

7.2. Disconnection module

This module provides operations invoked by objects to disconnect themselves in an orderlyway. Disconnection from the board server is carried out by invoking the manager's operationManager::deactivate. When the Client exits the system, it noti®es it by invoking the Manager::empty method. This noti®cation is not strictly necessary, since the inactivity control moduledeals automatically with all disconnection activities, but we use it to reduce the amount of timeneeded to ®nd an empty board when a new client enters the system.

7.3. Inactivity control module

It is responsible for identifying inactivity in any part of the system. It also detects abrupt dis-connection from the system by clients or board-control processes. Several situations indicate thata process is disconnected, but all of them are always detected as a CORBA communicationexception. There are two cases: those executed explicitly to detect a failure and those where anexception arises, interrupting normal system behavior.When a new client asks the Manager for a board, and none is free, the Manager tries to

determine if any of the previously connected clients have been disconnected from the system. Thisis done by invoking the Echo::echo operation in every client. In order to reduce echo operationsexecution time, the Manager launches in parallel as many threads as required.

7.4. Terminal emulation module

Its operations emulate a pseudo-bidirectional terminal communication cable. Two operationsare provided: SBC68K::write and MsgSBC68K::send. The former is used to send informationfrom the client to the board and the latter to send information from the board to the client.One important problem arises here. If we use these operations each time any entity wants to

send an information item to its peer, we will overload bandwidth. On the other hand, if infor-mation is retained too long, the user will have the feeling that something is wrong in the system.In the client-to-board communication case, the solution to this problem is easy: we send com-mands to the board as soon as the student types them. In short: whenever the student presses``carriage return'' in the SBC68K board communication area. In board-to-client communication,we do not know when the board will stop output. Therefore, we adopted a more complex scheme.We used a time-based solution controlled by two threads. The ®rst one gets characters from theboard and stores them in a bu�er. Periodically, the second thread checks if new information wasadded to this bu�er since the last check. The period has been selected long enough to let usassume that, if no new information has been added to the bu�er, board output is done. If noinformation was added during the last period, or the bu�er is full, the second thread sends bu�er


contents to the client. Otherwise, it will sleep until the next check operation. This scheme needsexclusive access control to the bu�er, which was implemented with a monitor.

7.5. Remote ®les access module

It provides operations to transfer ®les between client and server, making use of the SystemFileobject. Whenever a client needs to download a ®le from the server, it opens it using System-File::open, and reads it using SystemFile::write. If the ®le is going to be uploaded to the server,the client uses the SystemFile::read method. In both cases, the use of SystemFile::close isoptional. The close method is performed automatically whenever a new open method is called.

7.6. Remote button module

This module provides operations that allow students to press physical board buttons remotely.These operations are implemented by SBC68K::reset and SBC68K::abort methods, which corre-spond to RESET and ABORT buttons, respectively. Obviously, we need some physical help topress real buttons (there are no TUTOR traps for this purpose). Therefore, we developed a non-expensive circuit, which is connected to physical buttons. Diverse switching devices can be used insuch circuit. We developed our version (Fig. 5) using NPN bipolar transistors. The device in Fig. 5can control up to four SBC68K boards. Fig. 6 shows the complete layout of a sample operationalserver: it is composed of a SBC68K board, a remote button device and a PC.

Fig. 5. Remote button device.


8. Bene®ts for the student

Our environment, as an Internet-based distance education system, and because of its particularfeatures, provides students with several important advantages:

1. Geographical independence. No matter where students are, they can access the virtuallaboratory from any Internet-enabled computer.

2. Temporal independence. Instead of having laboratory static timetables, our students canschedule their work.

3. Platform independence. The programming language we used Ð java Ð is architecture-independent. It produces software that can be used in any computer.

4. A simple and familiar interface. Our client is an IDE (Integrated Development Environment)that provides a uniform way to perform complex tasks, which must be done using hetero-geneous applications in the conventional laboratory. On the other hand, students may attendguided laboratory classes at our facilities without signi®cant change in individual tool appearance.

5. Cooperative learning environment. Internet provides learners and instructors with a suitableplatform where collaborative and cooperative learning can be carried out.

6. Non-intrusive student monitoring. System logs can be used to measure student activity and skill.

Fig. 6. Sample system layout.


9. Bene®ts for the academic institution

In this section, we analyze savings for academic institutions using the proposed system. Itpresents di�erent con®guration schemes to suit di�erent institutions needs, from a low costscheme where a single computer would support eight boards to a high availability system whereseveral computers would manage a large pool of boards.The selection of the scheme to be used will depend on the particular needs and resources

available. There exists a trade-o� between availability and costs of the virtual laboratory. For thesake of simplicity we will explain three di�erent con®gurations:

1. Low/medium availability virtual laboratory.2. High availability virtual laboratory.3. Conventional laboratory complement.

In the following subsections we will present the con®guration of the conventional laboratory,and then we will analyze the three previous con®gurations for a virtual laboratory.

9.1. Conventional laboratory

9.1.1. Con®gurationIn the current Computer Architecture II laboratory con®guration at our facilities, each

SBC68K board is connected to its own terminal emulator, which runs in a computer next to theboard. There is one computer for each board. The laboratory has 20 workstations (room for 40students, in groups of two) and it takes place during a semester. Each group has a 4-h slot perweek. Since the number of registered students is around 200, we need 20 facility hours per week.Therefore, laboratory boards provide 400 working hours per week.

9.1.2. Costs analysisWe must take into account the cost to set a laboratory of those characteristics: $1000 per PC4

plus the cost of each SBC68K board, around $375. This cost has also a periodic component dueto the renewal of computers and boards (every 4 years). Finally, we must consider instructor time,20 h per week.Total initial cost (20 workstations): $27,500. Total ®xed cost (instructors): 20 h/week. Total

®xed cost (materials): $6,875/year.

9.2. Low/medium availability virtual laboratory

9.2.1. Con®gurationIt would be set with a small number of boards Ð say eight Ð connected to a single computer.

This is the case that replaces the real laboratory with fewest resources.

4 Pentium II, RAM 64 MB, HD 8 GB, at least one serial port.


Like in the conventional laboratory environment, each group should have board access duringa minimum of 4 h per week. Let us assume that maximum access time until disconnection isrestricted to 30 min, with a forced waiting time of 30 min until next try, up to 4 h per week. Ifaccesses take place between 09:00 and 19:00, the system can provide 560 working hours, perweek. This con®guration would support 100 laboratory groups with an excess margin of 40% (todecrease waiting time). We must consider that most editing and grammatical checks would takeplace o�-line, using local resources.This virtual laboratory should have to be supervised by a tutor/manager whose tasks would be:

1. System con®guration and maintenance. This task would require an initial con®guration e�ortbut afterwards, there would be minimal work to maintain it. Let us consider 1 to 2 h/weekfor maintenance tasks. It is possible to consider an automatic e-mail alarm system thatwould request maintenance only when needed.

2. Instruction and tutoring. Would take place via e-mail. Eight hours per week, for a singleinstructor.

9.2.2. Cost analysisFor this scenario we only need a PC, with one serial port per SBC68K board and one parallel

port per every four SBC68K boards. Expansion cost (port cards) is negligible, for eight SBC68Kboards. Let us assume $25 per board, including one remote button device.Total initial cost (one PC+eight boards): $4200. Savings: 84%. Total ®xed cost (instructors):

10 h/week. Savings: 50%. Total ®xed cost (materials): $1050/year. Savings: 84%.

9.3. High availability virtual laboratory

9.3.1. Con®gurationHere, we suppose that all students work independently. Also, we assume a 100% availability

excess to decrease waiting time. Same disconnection constraints apply. Therefore, we need 1600h/week. This means that we need 23 SBC68K boards, 10 h per day. If we keep the board/PCratio, three computers would be necessary. Maintenance hours are roughly the same, butinstructional hours are doubled, since students demand individual attention.

9.3.2. Costs analysisTotal initial cost (three PCs+23 boards): $12,200. Savings: 55%. Total ®xed cost (instructors):

18 h/week. Savings: 10%. Total ®xed cost (materials): $3050/year. Savings: 55%.

9.4. Complement of the conventional laboratory: the new Computer Architecture II laboratory

The reader may have arrived at the conclusion that the conventional laboratory and the virtuallaboratory could coexist. Although we have described the obvious advantages of a virtuallaboratory, it cannot replace direct student±teacher interaction. Therefore, di�erent hybridscenarios could be proposed, depending on the needs of a particular institution. Forexample, students could have 2 h/week at laboratory facilities and 2 h/week of virtual labora-tory time.


In the Computer Architecture II case, we noted that:

1. Preparing a SBC68K board for remote operation does not disable it for local operation (remotebutton devices do not replace real buttons completely, real buttons are still operational).

2. All PCs in the Computer Architecture II laboratory are linked to the departmental network.

Therefore, the hardware of the conventional laboratory can be used for remote access, in freeroom hours. Additional cost is minimal. We only need to consider the price of remote buttondevices, which is negligible. Also, after many considerations, we decided that students and sta�would better accept a smooth transition into the virtual model.Currently, students are given the possibility to choose between virtual or conventional labora-

tory access. It is expected that, in the present situation, around 30% of the students will select thevirtual approach (those who have experience in the ®eld or did not qualify in the previous year).Since we are in the process of installing the system, a compensation system is required to balancestudent grades.Support for virtual students comes from the reallocation of laboratory resources and instruc-

tors. For the remainder of the conventional laboratory (70%), we need only 14 facility hours perweek (see Section 9.1.2). This liberates 6 h/week of instructor time, which are enough if weassume a high availability virtual laboratory based on the analysis in Section 9.3, during 30% ofthe time. Also, in this case, we need 480 h/week of system time (24 h/week of facility time) to beprovided using available resources of the conventional laboratory, which is consistent withcurrent o�-duty hours.

10. Conclusions

We have presented a distributed educational environment for remote access to real equipmentin our Computer Architecture II laboratory. SBC68K boards are encapsulated as CORBAobjects whose operations are invoked by students using CORBA standards, through the Internet.To deal with hardware constraints, we have developed a simple (and non-expensive) auxiliarycircuit, which is part of the CORBA SBC68K object. As a result, the whole functionality of thereal laboratory is provided in our virtual environment.Additional mechanisms to assign automatically a free board to a new student entering the

system have been implemented, as well as user authentication and inactivity control procedures toavoid retention. These features are implemented as CORBA methods.We have also presented an analysis of di�erent con®gurations for our system, taking into account

the trade-o� between resource costs and laboratory availability (in terms of free boards, availablefor new student requests). We have shown that the virtual laboratory is an excellent complementfor the conventional laboratory, and is competitive both in sta� hours and equipment costs.

Appendix A. CORBA

The Common Object Request Broker Architecture (CORBA) was created by the Object Man-agement Group, OMG (OMG, 2000), a non-pro®t consortium supported by more than 800


institutions, both from academia and industry. Its primary goals are reusability, portability andinter-operability of object-based software in distributed, heterogeneous environments.OMG speci®es the referencemodel of CORBA architecture, which is divided into four components:

1. The Object Request Broker (ORB) is the key of the CORBA architecture. The ORB(Appendix B) enables objects to perform transactions in a distributed environment, trans-parently. It is responsible for ®nding the object requested by the caller and setting it up forthe request. It also sends all object parameters, and returns the response to the caller, inde-pendently of object location, object language or any other feature not re¯ected in the objectinterface.

2. Object Services. They support basic functions for using and implementing objects. Theyinclude the Naming Service (allows other objects to locate components by name), theSecurity Service (provides a complete framework for distributed object security), and thir-teen more. Their aim is providing basic distributed computing support for new applications.A whole description can be found in Orfali, Harkey and Edwards (1997).

3. Common Facilities. They are a collection of services shared by many applications, but not asfundamental as object services. They are also known as domain interfaces, as they arefocused on a particular business domain (®nance, health care, telecommunications, etc.).

4. Application Objects. They are products developed by vendors. According to the CORBAparadigm they make use of the core ORB, basic object services and existing common facilitiesfor their particular purpose. Development of new application objects is faster if commonservices are already available for them.

CORBA is one of the most important frameworks in the middleware ®eld. Among its advantageswe can quote:

1. high abstraction level;2. multi-platform and multi-OS architecture;3. support for both static (compile time) and dynamic (run time) invocation. The former is

speci®ed in a language-independent manner with the Interface De®nition Language (IDL).The latter allows objects to ®nd the interface at runtime;

4. high performance;5. available for use with many languages: c, c++, java, ada, smalltalk, lisp, . . .;6. technical and commercial success; and7. open standard.

Nowadays, there are many CORBA implementations. Most of them o�er an ORB, someObject Services and one or more IDLs for speci®c language compilers. We must compare imple-mentation performances and features to ®nd one that meets our particular needs. Fundamentalaspects are:

1. supported OS;2. supported languages;3. Object Services that are implemented;4. Availability of good documentation; and5. interoperability (GIOP/IIOP) support.


Appendix B. Our ORB choice: ORBacus

We have chosen ORBacus (Object Oriented Concepts, 2000) as the CORBA implementation forour project. ORBacus is an Object Request Broker that is compliant with the CORBA standard, andfree for academic purposes. ORBacus features include:

1. full CORBA IDL support;2. complete IDL to c++ and IDL to java mapping;3. Naming, Event and Property Object Services;4. interoperability protocols with IIOP as the default;5. single and multi-thread support with several concurrency models; and6. nested method invocations.

Appendix C. SBC68K Board Description

The SBC68K board (Arnewsh Inc., 2000) is a single board computer based on a MotorolaMC68000 microprocessor. It may be used for a variety of control applications, such as peripheralI/O controller, programmable device con®guration, microprocessor-based robotics and the like.With the addition of a terminal it serves as a complete microcomputer for training and educa-tional use. The user must only connect an RS-232 compatible terminal and supply power to havea fully functional system.The SBC68K board provides RAM, ROM, timers, disk controller, printer interface, and I/O

controller. Although Motorola MC68000 is a 32-bit CPU, it has a 16-bit data bus. Its program-ming model is composed of eight 32-bit data registers, eight 32-bit address registers, a 32-bit pro-gram counter, and a 16-bit status register. It supports seven interrupt levels that can be con®guredusing SBC68K switches.A Motorola MC68681 DUART (Dual Universal Asynchronous Receiver Transmitter) sup-

ports serial communication. This chip handles two independent full-duplex serial communicationchannels designated as A and B. Using channel A (``terminal'') it is possible to interact with aterminal (usually a PC). For this purpose, the SBC68K has an interactive debugging kernel calledTUTOR.Finally, the SBC68K has two buttons:

1. RESET button. By pushing this button all board devices (including the MC68000 CPU) arereset and TUTOR ®rmware is restarted.

2. ABORT button. It raises a level 7 interrupt and gives control to TUTOR ®rmware. It ismainly used to debug software.

Appendix D. System installation

Appendix D1: Server side

The server installation process comprises a set of operations, from the installation of an HTTPserver to the con®guration of each board to be accessed remotely by students:


1. HTTP server installation.2. NameServer process launch.3. Manager process launch.4. Con®guration of each board:� Power supply and connection of ``terminal'' port to the computer at selected baud rate.� Identi®cation and con®guration of a PC serial device. In a UNIX environment, this is

normally some /dev/cua device.� PC SBC68K communication test (using SEYON, for example).� Remote button device connection to an empty PC parallel port.� Identi®cation and con®guration of a PC parallel device. In a UNIX environment, this is

usually some /dev/lp device.� SBC68K virtual button device communication test. This can performed by sending char-

acters to the parallel device.� Installation of an assembler with S-record output5.

5. Board-control process launch.

Appendix D2: Client side

In case of a standalone client, users need to install and con®gure a java Virtual Machine,compliant with java Development Kit 1.1.6 (or higher). Once JDK is installed, users mustdownload client JAR ®les and include them in their environment variable CLASSPATH. Finally,client is executed as:

java sbc68k:Cliente

The use of an applet-based client is the simplest execution method, since users only need toload the server web page using a Java-enabled web browser. All required ®les would be down-loaded automatically and execution would start immediately. The current version of the clientcan be retrieved from http://.delta.ait.uvigo.es

References

Arnewsh Inc. SBC68K page. WWW document: (http://www.arnewsh.com) (2000).Enloe, C. L., Pakula, W. A., Finney, G. A., & Haarland, R. K. (1999). Teleoperation in the undergraduate physicslaboratory-teaching an old dog new tricks. IEEE Transactions on Education, 42(3), 174±179.

FernaÂ ndez-Iglesias, M. J., GonzaÂ lez-CastanÄ o, F. J., & Pousada-Carballo, J. M. (2000). An undergraduate low-levelcomputer communications laboratory oriented towards industry. International Journal of Electrical EngineeringEducation, 37(2), 146±156.

Goldberg, M. W., & Salari, S. (1997). An update on WebCT (World-Wide-Web Course Tools) Ð a tool for the crea-tion of sophisticated Web-based learning environment. In Proceedings of NAUWeb'97 Ð current practices in Web-based course development. Flagsta�, USA.

5 Microtek Research ASM68K, for example.


GonzaÂ lez-CastanÄ o, F. J., Anido-RifoÂ n, L., Pousada-Carballo, J. M., RodrõÂ guez-HernaÂ ndez, P. S., & LoÂ pez-GoÂ mez, R.

(2001). A Java/CORBA Virtual Machine Architecture for Remote Execution of Optimization Solvers in Hetero-geneous Networks. Sofware-Practice & Experience, (in press).

Gosling, J. Joy, B., & Steele, G. (1996). The Java language speci®cation. Addison-Wesley

Llamas-Nistal, M., Anido-RifoÂ n, L., & FernaÂ ndez-Iglesias, M. J. (1999). A simulation-based platform for interactivelaboratories on the internet. In Proceedings of the international conference on engineering and computer education. RõÂ ode Janeiro: Unicamp.

National Instruments Corporation page (2000). WWW document: (http://www.natinst.com).Object Oriented Concepts (2000). ORBacus page. WWW document: (http://www.ORBacus.com).OMG. CORBA page (2000). WWW document: (http://www.omg.org).Orfali, R., Harkey, D., & Edwards, J. (1997). Instant CORBA. New York: John Wiley & Sons, Inc.

Shen, H., Xu, Z., Dalager, B., Kristiansen, V., Strùm, é., Shur, M. S., Fjeldly, T. A., LuÈ , J.-Q., & Ytterdal, T. (1999).Conducting Laboratory Experiments over the Internet. IEEE Transactions on Education, 42(3), 180±185.

Siegel, J. (1996). CORBA fundamentals and programming. New York: John Wiley & Sons, Inc.


Documents

Internet access to real equipment at computer architecture laboratories using the java/CORBA paradigm