Embed Size (px)
Citation preview
Predictable Interactive Control of Experiments in aService-Based Remote Laboratory
Andreas RascheHasso-Plattner-InstituteUniversity of PotsdamPotsdam, Germany
Frank FeinbubeHasso-Plattner-InstituteUniversity of PotsdamPotsdam, Germany
Peter TrögerBlekinge Institute of
TechnologyRonneby, Sweden
Bernhard RabeHasso-Plattner-InstituteUniversity of PotsdamPotsdam, Germany
Andreas PolzeHasso-Plattner-InstituteUniversity of PotsdamPotsdam, Germany
ABSTRACTRemote and virtual laboratories are commonly used in elec-tronic engineering and computer science to provide hands-onexperience for students. Web services have lately emerged asa standardized interfaces to remote laboratory experimentsand simulators. One drawback of direct Web service inter-faces to experiments is that the connected hardware could bedamaged due to missed deadlines of the remotely executedcontrol applications.
Within this paper, we suggest an architecture for predictableand interactive control of remote laboratory experiments ac-cessed over Web service protocols. We present this con-cept as an extension of our existing Distributed Control Labinfrastructure. Using our architecture, students can con-duct complex control experiments on physical experimentsremotely without harming hardware installations.
1. INTRODUCTIONThe Distributed Control Lab (DCL) is a virtual laboratoryat the Hasso-Plattner-Institute in Potsdam, which enablesthe remote usage of experiments for teaching purposes. Itcomprised an infrastructure that provides access to remotereal-time control experiments via the Internet. Authenti-cated users can submit control programs for an experimentby the help of different front-ends, such as the Web interface,a development environment plugin or a command-line inter-face. Each control program by a particular user is calleda job, which is executed by a matching experiment con-troller that steers the according physical experiment hard-
Preprint of the ACM version
ware. Students usually implement control algorithms, whichprocess data from physical hardware installations and gen-erate according control signals.
The DCL infrastructure is responsible of distributing incom-ing jobs to available experiments. Multiple experiments ofthe same type, being able to handle the same kind of job, arecalled experiment types. The infrastructure supports bothphysical experiments and simulations for the same experi-ment type. Simulations are intended to help out in case ofhigh load on experiments, e.g. before a student assignmentdeadline. Simulations can act as full replacement for thereal experiment in most cases, since students submit mostof their jobs for checking the correctness of their control ap-plication. This only demands mainly a compiler run for thecontrol program in the particular runtime environment, butnot a real execution of physical activities [10, 14].
Beside the support for teaching activities, research in theDCL project covers the question of protecting the infrastruc-ture against malicious code, which can potentially harm ex-periment hardware or execution nodes. It utilizes techniquessuch as automated source code analysis, run-time monitor-ing and dynamic adaptation for protecting the experimentinfrastructure [12].
Within the DCL several experiments have already made ac-cessible. Among others, there are the control of Lego Mind-storm NXT robots, the control of a Foucault-style pendu-lum, a model railway track and an industrial control sce-nario. Further details on the existing DCL experiments canbe found in [13, 14].
The DCL provides a batch mode experiment interactionstyle. The user implements a control algorithms and submitsthe source code to the lab infrastructure. The DCL thanidentifies a free experiment instance, compiles the providedsource code and runs the control program on the particularexperiment. After successful execution, the user can viewresults in the form of diagrams, text or videos. Each ex-
Experiment A
Execution Host Institut A
Experiment B
Execution HostInstitut B
Foucault’sPendulum
Execution Host(HPI Potsdam)
Adaptive Execution Platform
(HPI Potsdam)
Industrial ControlScenario
Higher Striker
Student
Student
Student
Figure 1: The Distributed Control Lab
periment run comprises only one direct interaction with theexperiment. In case of multiple users, the lab infrastructureserializes access to the experiments, potentially queuing upjobs. The extensible architecture of the lab also supportsmultiple experiment instances of one type, allowing for theload balancing of jobs and the toleration of experiment out-ages.
In order to be able to integrate experiment installations fromdifferent organizations, the latest version of the DCL re-lies on commonly accepted Web service standards to inter-connect different experiment installations. Each experimenttherefore implements a Web service interface providing thenecessary methods for job execution and monitoring. Werely our architecture on the explicit notion of logical serviceinstances, an abstraction concept for the stateful interactionof DCL users with the infrastructure. A logical service in-stance combines the relevant methods for uploading the jobcontrol logic, checking the experiment run properties andfor fetching the experiment run results. Each client there-fore can operate its own logical instance (or session) for anexperiment. We give a short introduction of the underlyingconcepts in the following paragraphs, details can be foundin [16].
In our service-oriented version of a remotely accessible vir-tual laboratory, each control program for one experimentrun is represented as logical service instance. Calls to logicalinstances from a DCL user are dynamically mapped on phys-ical service instances, representing the end point for eitherphysical or simulated experiment hardware. A logical serviceinstance therefore represents a stateful entity to the client,but does not necessarily need to be realized by only onephysical service instance on a particular server. All clientscommunicate with a coordination layer that routes SOAPrequests to a matching execution host, a computer runningthe physical service instances. Matching logical and physicalinstances relate to the same service implementation, whichis realized as typical binary Web service component (e.g.Java Servlet, .NET Assembly) with its according WSDL in-formation.
In order to create a new experiment run based on some pro-vided control logic, the DCL user contacts a factory serviceto get the reference to a new logical service instance. The
logical instance is represented as SOAP endpoint, describedby a WS-Addressing [5] XML document. A logical serviceinstance has query-able state properties, which can be readand written through standardized SOAP operations [4].
The set of existing logical service instances is managed bythe coordination layer in the DCL, which schedules andmanages the incoming requests on the matching physicalservice instances. These physical instances share a commonstate storage, which allows to route requests to the samelogical instance to different physical instances of the sameimplementation.
If the client queries its logical instance for some current at-tribute value, the coordination layer can provide the latestdata made available by the experiment service out of thecentral database. The data is written during the experimentrun by the particular physical instance.
Figure 1 gives an overview of the service-based DCL ar-chitecture. Students already can use laptops, PCs or evenmobile devices with Windows CE for accessing the lab ex-periments. The coordination layer routes service requestfrom clients to the execution host containing the physicalservices. The physical services then runs the provided con-trol program on the experiment hardware.
2. INTERACTIVE EXPERIMENT USAGEBoth the classical and the service-oriented version of ourDCL infrastructure assume a batch processing mode, whereeach experiment run is performed independent from the client.In a single step conducted before the experiment run, controllogic is transmitted to the experiment and/or experiment-specific parameters are configured. Because of this basic ar-chitectural style, it is not possible to interact with the exper-iment while a control algorithm is executed. This preventsthe interactive access to measurement values and experi-ment results while the experiment is running. Even thoughthis strict decoupling enabled straight-forward fault toler-ance and scalability features, it also prevents typical interac-tive usage patterns, especially the debugging or fine-tuningof experiment-parameters during the execution of a job bya lab user.
Our primary objective for supporting an interactive modewas the usage of standard development tools such as Lab-VIEW, Eclipse or Visual Studio in the existing DCL in-frastructure. One example is an experiment setup [7] atTechnical University of Darmstadt, where FPGA boards canbe programmed remotely. After burning a new FPGA im-age, test sequences are sent to the board and output datais sampled and transferred to the lab user. This trans-fer of test samples also requires support of an interactivemode. Within the Leonardo Da Vinci Project Vet-TREND,we needed to integrate this experiment in the DCL infras-tructure.
Another example of an experiment is the control of mov-ing robots, as already provided in our lab. In the so farapplied batch mode processing of requests, a control pro-gram can be uploaded to the experiment and controls therobot from there on autonomously. For an updated exper-iment scenario, it might be interesting to process controlcommands from the user while the robot is already moving.This would allow students to implement a control algorithmfor the robot and steer it afterwards remotely.
In order to support an interactive mode, the original servicearchitecture had to be extended slightly. We introduced aspecial class of interactive logical instances, where the in-frastructure binds the particular logical instance to a phys-ical one, avoiding the dynamic routing of requests. We alsoadded support for asynchronous logical instance invocations,in order to allow the parallel execution of an experiment run– represented by a call – and querying of values – also rep-resented by a call.
In the classical batch mode operation, experiment jobs arequeued if no free physical instance (meaning experiment) isavailable. This represented a feasible approach, since theduration of single jobs is typically limited and result areanalysed after the finished execution of a job. In the inter-active mode, end users are directly involved in the executionof jobs. This prolongs the execution time of jobs and makesqueuing and the calculation of queuing times more difficult.We therefore changed to an external time-slot-based reser-vation system, as already suggested by related work in thearea of virtual laboratories [17, 2]. The user registers fora time-slot through a separate interface. The reservationis persisted, and every time a logical instance operation isinvoked, the infrastructure checks if the authenticated useris allowed to use the bound physical service instance. Thereservation and accounting is handled externally and can beconfigured e.g. by a teacher.
Figure 2 illustrates the steps happening when an interactivejob is executed. After the experiment service implementa-tion has been deployed and configured (step 1), the userregisters for a time-slot for that experiment. In the thirdstep, the user creates a logical service instance for an inter-active experiment, opening his own session with the physicalexperiment in an indirect manner. Afterwards, in step 4,the client sends an experiment-related request to the logicalservice instance. The coordination layer checks (4.1) if theuser is authorized to perform that action. In the case of anunauthorized request, the coordination layer responds with aSOAP fault reply message. If a user has a valid reservation
Coordination Layer
User
Scheduling
Execution Host
Experiment Service
deploy/configure
experiments
Experiment Provider
Teacher
Usercreate
experiment
service
instance
1
logical
service
reference
3
3.1 deploy
service
create
send
request
4
register timeslot manage
users
check
time
schedule
request
2
4.1
4.2
response
receive
data
4.3
Figure 2: Interactive mode: usage scenario
for the interactive experiment, it might still be needed todeploy the service implementation to the execution host inorder to get a physical instance. This shows that even withinteractive logical instances, our basic concepts of dynamicresource usage still hold. During the reserved time slot, theparticular physical instance is exclusively reserved for oneuser. Requests for the same experiment type by other usersare handled by other physical instances for the same type,if available.
The described interactive mode of our infrastructure can beused for Web-service-based interactions, but also custom in-teraction protocols might be used. During the reserved timeslot, no other user can interact with the physical serviceinstance for the experiment, since all requests are routedthrough the coordination layer. Alternative protocols thencan perform some kind of ’out-of-band’ connection to the ex-periment, like with a native debugging session. Since theremay be multiple execution hosts available for the experimenttype, the target addresses for the custom protocol must beconfigured dynamically. The host address of the used exper-iment host can be acquired by a dedicated logical instanceoperation. In order to prevent other users from connectingto the experiment computer via the custom protocol, a smallproxy could be implemented on the infrastructure manage-ment hosts that simply forwards the request to the experi-ment computer and additionally checks again the reservationdatabase.
Beside our realization of proprietary protocol access, there isalso support for a flexible SOAP-based interaction betweenuser and experiment. Two possibilities for the service inter-faces exists: On the one hand a generic interaction interface,illustrated in listing 1 can be used. The generic methodsSendData and ReceiveData allow to to transmit experimentspecific data, such as proprietary monitoring values.
i n t e r f a c e I I n t e r a c t i v e {void SendData ( Byte [ ] data ) ;Byte [ ] ReceiveData ( ) ;
}
Listing 1: Generic interface
On the other hand, experiment-specific SOAP operationscan be used. One example is shown in listing 2. This inter-face is used to control one of the robots in our laboratoryenvironment interactively. Depending on the invoked opera-tion, the submitted control logic must make the robot movein a correct way.
i n t e r f a c e IRobot{void Move( i n t speed ) ;void Turn ( Angle degree ) ;void Stop ( ) ;
}
Listing 2: Special interface
With an interactive mode in place, users are now able to in-fluence a running experiment. This introduces a new prob-lem class regarding the timing behaviour of experiment runs,which is discussed and solved for our infrastructure in thefollowing section.
3. REAL-TIME WEB SERVICESWhen steering real-time experiments through remote inter-face technologies such as SOAP, the problem of timelininessmust be solved. The miss of deadlines in hard real-time ex-periment could potentially damage expensive hardware in-stallations. One example is the control of a moving robot -a missing command to stop the robot in front of an obstaclecould lead to a sub-optimal experiment result. Another ex-ample is the higher-striker experiment operated in the DCL,where students have to enable magnetic coils connected toa car battery to accelerate an iron cylinder. Enabling thecoils for more than 200 milliseconds can burn the wires andtherefore render the whole experiment unusable.
!"#!$%&!'(
)*&#+(!$
,-./0%1$2$3
)*'($*4/2##4%)2(%*'
)*'($*4/2##4%)2(%*'
)*'($*4/245*$%(6&
4*784!9!4/)*'($*4
!"#!$%&!'(/
62$:72$!
4*784!9!4/)*'($*4
!"#!$%&!'(
62$:72$!
;2<!(3/)*'($*44!$
)*'($*4/245*$%(6&7!1/;!$9%)!
!"#!$%&!'(/)*&#+(!$)4%!'(/)*&#+(!$
7!1/;!$9%)!=>/8 ?2':4!$
$!248(%&!'*'8$!248(%&!
!"#!$%&!'(/62$:72$!
6%56/#$%*$%(3/
(6$!2:
Figure 3: Typical experiment control
Figure 3 shows the typical control setup for a remotely ac-cessible experiment in a batch-processing approach. Thecontrol application is executed on the experiment controlcomputer (called execution host in our infrastructure). Thehardware can be accessed directly by executing the accord-ing I/O instructions in the control program. The execu-tion behaviour of the control application can be determinedin advance, since all relevant parameters are known. Theexperiment execution is decoupled from external influences,which allows to keep all relevant deadlines given by the phys-ical circumstances of an experiment. As already argued, adrawback of this decoupled approach are restrictions for de-bugging and monitoring.
In order to use the features offered by modern development
tools as presented before, at least some parts of the exper-iment control logic have to be executed on the user’s com-puter. This leads to the notion of a distributed application,where the control flow is partitioned between the users com-puter and the experiment computer. The part running onthe user’s computer interacts with the application part re-siding on the experiment computer. When analysing timingrequirements, a new factor has to be considered now: thecommunication within the distributed control application.
The problem turns out to be even worse with the usageof Web service technologies and wide-area Internet connec-tions, due to their unpredictable timing behaviour. In theInternet different load situations can be found, making a pre-calculation of transmission times difficult. Also the process-ing of XML messages in the Web service stacks can lead tounpredictable timing behaviour within the distributed con-trol application. The usual approach is the introductionof an according fault tolerance mechanism, which reacts ontiming faults caused by the usage of unpredictable commu-nication protocols. The experiment defines the maximumtime between two Web service invocations to ensure a safecontrol of the experiment. In case the timing requirementsare not hold - a deadline is missed - a fault handling mech-anism must be activated.
We propose a new approach for preventing missed dead-lines in such a scenario, by applying the composite objectpattern first introduced by Polze et al. [9, 8]. The com-posite object pattern decouples unreliable communicationmechanisms from hard real-time applications. By separat-ing real-time and non-real-time activities within an object,all timing requirements of the real-time activities can behold due to prioritization. In addition non-real-time activ-ities are observed and in the case of a missed deadline, adefault handler residing in the real-time part can toleratetiming faults. The composite object pattern has been origi-nally developed for the CORBA middleware, and is appliedon interactive experiment Web service in the context of ourDCL infrastructure.
!"#!$%&!'(
)*&#+(!$
,-./0%1$2$3
)*'($*4/2##4%)2(%*'
)*'($*4/2##4%)2(%*'
)*'($*4/245*$%(6&
4*784!9!4/)*'($*4
!"#!$%&!'(/
62$:72$!
4*784!9!4/)*'($*4
!"#!$%&!'(
62$:72$!
;2<!(3/)*'($*44!$
)*'($*4/245*$%(6&Web service
!"#!$%&!'(/)*&#+(!$)4%!'(/)*&#+(!$
7!1/;!$9%)!=>/8 ?2':4!$
$!248(%&!'*'8$!248(%&!
!"#!$%&!'(/62$:72$!
6%56/#$%*$%(3/
(6$!2:
Figure 4: Distributed control infrastructure
Figure 4 shows the architecture of a distributed control ap-plication when applying the pattern. The application partrunning on the user’s computer controls the experiment byinvoking Web service operations on the experiment com-puter. On the experiment computer, a safety controller isexecuted in parallel to the low-level control application part.The safety controller observes the fulfilment of the givenreal-time requirements for the Web service invocations. In
case a deadline is missed, the safety controller reacts usingdefault actions to stabilize the experiment. The importantaspect here is the decoupling of the non-real-time Web ser-vice interface from the real-time low-level I/O control andthe safety controller process.
!"#!$%&!'(
)*&#+(!$
,-./0%1$2$3
)*'($*4/2##4%)2(%*'
)*'($*4/2##4%)2(%*'
)*'($*4/245*$%(6&
4*784!9!4/)*'($*4
!"#!$%&!'(/
62$:72$!
4*784!9!4/)*'($*4
!"#!$%&!'(
62$:72$!
;2<!(3/)*'($*44!$
)*'($*4/245*$%(6&7!1/;!$9%)!
!"#!$%&!'(/)*&#+(!$)4%!'(/)*&#+(!$
Web service=>/8 ?2':4!$
$!248(%&!'*'8$!248(%&!
!"#!$%&!'(/62$:72$!
6%56/#$%*$%(3/
(6$!2:
Figure 5: Composite objects and safety control
Figure 5 shows the resulting architecture of a timing-fault re-silient Web service implementation. A Web service handlerprocesses the incoming service operation request. Instead ofdirectly interacting with the hardware, control commandsare then written into a shared memory buffer by the handlerimplementation. A second real-time priority thread cycli-cally reads the commands from the buffer and interacts ac-cordingly with the physical experiment installation. It alsoreads sensor data from the hardware and writes them intothe read buffer of the Web service implementation, whichenables the retrieval of sensor values for the client withoutdisturbing the timing behaviour of the overall experiment.
The important issue in our approach is to isolate the deter-ministic real-time (rt) part from the non-deterministic non-real-time (non-rt) part in the activities triggered by a clientrequest. A technique proposed by one the original authors[8] is the usage of a horizontal timing firewall. The techniquerelies on the usage of a real-time operating system and usestwo classes of thread priorities for non-rt and rt-tasks. Byusing higher priorities for the real-time threads the isolationcan be realized. Another approach is to use a multiprocessorsystem (SMP) and use a dedicated CPU for real-time activ-ities. This technique has already been implemented in theform of CPU-Shielding [3] in a real-time version of a Linuxoperation system.
For our remote laboratory environment, we use the the real-time extension for Linux (rt-Linux) [1]. Non-RT activitiesare executed as normal Linux processes being allowed toaccess all functionality available in the operating system.Real-time activities are executed in a real-time kernel mod-ule with restricted functionality. The synchronization be-tween both parts is implemented via a shared memory re-gion. In a second future scenario, we will use the WindowsCE real-time operating system and implement a horizon-tal timing firewall. We are therefore porting parts of theDCL infrastructure to the Windows Mobile 6.0 R2 operat-ing system, in order to run execution hosts on RT-enabledoperating systems.
Depending on the requirements of the lab experiments dif-ferent consistency protocols for buffer synchronization canbe used in the implementation. In the real-time Web ser-vice scenario three types of variables are used. There arenon-shared real-time variables only used by rt-tasks. Thesevariables must be pinned in memory and ensured to notbeing swapped out to secondary storage by the operatingsystem. Non-shared non-real-time variables are only usedby the Web service handler and may be swapped out. Themost important type are shared variables, which are used byreal-time and non-real-time tasks.
Shared variables can be synchronized following a strong con-sistency protocol. This requires the synchronization of real-time and non-real-time tasks via common synchronizationprimitives. To avoid the priority inversion problem, a prior-ity ceiling protocol is typically used. Since the access timeto data by non-real-time threads is restricted, time spendin such a critical section must be calculated when analyzingthe feasibility of the real-time system.
Among others, we are using .NET- and Java-based web ser-vice implementations. This leads to a problem when calcu-lating worst case execution times of non-rt critical sections,since the garbage collection could stop the whole applicationany time - causing unpredictable delays. For this reason,we rely on weak consistency protocols instead to implementshared variables, where they are handled as real-time vari-ables with a shadow copy accessed by non-real-time tasks.The values of the real-time variables are copied with config-urable interval timings to the non-real-time shadow buffer.This also means that the copy temporarily diverges. Thisis no problem, since the copy interval can be configured asbeing much smaller than the arrival rate of Web service re-quests. In many configurations, the usage of old data is alsono problem. On example is the control of a moving robot,where a late move right command does not automaticallyexpose damage to the robot. In a dangerous situation, thesafety controller can still take over control.
One advantage of the proposed solution is that it can alsobe used to tolerate incorrect computation and even byzan-tine and omission faults. One example are erroneous or evenmalicious control algorithms implemented by students. Thesafety controller component is not implemented by a labuser, but by the operating authority. In this case, the safetycontroller is denoted to be analytically redundant to the usercontrol component. The safety controller therefore solves acommon control problem with restricted, but proven func-tionality. More details on the efficient dynamic reconfigura-tion of control applications can be found in [14, 11].
4. APPLICATION SCENARIOFigure 6 shows an example application of the proposed con-cept on one of our DCL experiments. The Fischertechnik as-sembly line shown on the picture is a model of a ball sortingassembly line, consisting of rotating conveyor belts, pneu-matic actuators and proximity sensors. The assembly linecan be controlled by a Beckhoff programmable logic con-troller (PLC) running on top of the Windows CE operatingsystem.
Within the existing DCL experiment, students can imple-
Figure 6: DCL experiment: Fischertechnik assem-bly line
ment .NET-based control applications for accessing the PLC’sI/O-modules. The .NET code is executed directly on thePLC using Microsoft’s .NET Compact Framework.
For a new version of the experiment, we want students to useTwinCAT, a PLC standard development tool, to implementcontrol applications using a typical IEC-61131 programminglanguage. TwinCAT (figure 7) requires multiple interactionswith the experiment controlling PLC during the execution ofa control application. This is due to debugging, but also forthe configuration of the hardware mapping. The experimenthas both hard real-time requirements and the demand for aninteractive control. If the conveyor belts are not stopped ina correct timely manner, the balls could be pushed from thetable by the pneumatic ram.
We applied the described concept for the interactive modeby running a PLC-based safety controller in a high prioritytask. It observes missed deadlines by the users’ control ap-plication, as well as faulty behaviour by observing externalexperiment parameters such as the position of the balls andthe speed of the conveyor belt. First experiments show thatthe extended experiment controller architecture fits into ourservice-oriented remote laboratory infrastructure, while en-suring that the real-time experiment hardware is not harmedby incoming control programs.
Figure 7: Standard PLC development tool
Another experiment we plan to implement is the control ofLego NXT robots. The user can upload a control applica-tion, which reacts on steering signals generated through callson an interactive logical instance. If the robot leaves thepre-defined operation area the safety controller takes overcontrol and moves the robot to its charging station. Theuploaded control application must implement the interac-tive commands for the Lego, using a Bluetooth connectionfrom the experiment host to the Lego robot.
5. RELATED WORKThe management of timing properties for real-time exper-iments is based on the composite object pattern first usedin the RemoteLab [15], which was a cooperation betweenHumboldt Universitat zu Berlin and the University of Illi-nois Urbana-Champaign. Within the lab a Khepera robotwas controlled using the CORBA middleware. Real-timebehaviour of the robot was ensured by using the compositeobject pattern.
An interactive mode for virtual/remote laboratory experi-ments has also been implemented in other remote lab envi-ronments, such as the MIT iLab project [6]. Within iLaban open source framework was created, providing commonfunctionality for the operation of a virtual/remote labora-tory. iLab relies on a three-tier Web architecture includ-ing client applications, intermediate service brokers and labservers. iLab also used Web services for communication be-tween the tiers, but in contrast to our work there is no inte-grated session concept for accessing and checking an exper-iment run. iLab’s interactive mode gives the frame for com-mon services such as distributed logging and access control,but leaves the protocol used for interaction as experiment-specific. This paper suggests an interaction protocol basedon Web services or tool-specific protocols, but concentrateson the assurance of real-time requirements.
6. CONCLUSIONSThe contribution of this paper is a new architecture for pro-viding interactive and real-time control of experiments fornon-deterministic communication middleware such as Webservices. The usage of analytic redundancy allows to toler-ate timing faults raised by the communication layers. Thisallows users of remote laboratories to execute control ap-plications interactively, for example with debug and moni-toring features, while still getting the advantages of modernservice-based access mechanisms. The proposed architec-ture also enables the usage of standard development toolssuch as LabView directly for the remote laboratory users.
The proposed extension of the Distributed Control Lab,operated at Hasso-Plattner-Institute, are currently in usefor different teaching and research demonstration activities.Future work will concentrate on the further investigationof real-time experiment integration in a dynamic service-oriented remote laboratory.
7. ACKNOWLEDGMENTSThis work has been sponsored by the Leonardo Da VinciProgramme of the European Union within the VET-TREND-project (RO/06/B/F/NT175014).
8. REFERENCES[1] M. Barabanov. A Linux-based Real-Time Operating
System. Master’s thesis, New Mexico Institute ofMining and Technology, 1997.
[2] M. Basso and G. Bagni. ARTIST: A Real-TimeInteractive Simulink-based Telelab. In Proceedings ofIEEE CCA/ISIC/CACSD Conference, Taipei,Taiwan, September 2004.
[3] S. Brosky. Shielded CPUs: Real-Time Performance inStandard Linux. Linux Journal, May 2004.
[4] S. Graham and J. Treadwell. Web Services ResourceProperties 1.2 (WS-ResourceProperties). OASISOpen, April 2006.
[5] M. Gudgin, M. Hadley, and T. Rogers. Web ServicesAddressing 1.0 - Core. World Wide Web Consortium(W3C), May 2006.
[6] J. Harward, T. T. Mao, and I. Jabbour. iLabInteractive Services – Overview.http://icampus.mit.edu/iLabs/Architecture, 2006.
[7] L. S. Indrusiak, M. Glesner, and R. A. da Luz Reis.Lookup-based Remote Laboratory for FPGA DigitalDesign Prototyping. In Intl. Workshop on e-learningand Virtual and Remote Laboratories(VIRTUAL-LAB 2004). INSTICC Press, August 2004.
[8] A. Polze and L. Sha. Composite Objects: Real-TimeProgramming with CORBA. In Proceedings of 24thEuromicro Conference, Network ComputingWorkshop, volume II, pages 997–1004. IEEEComputer Society, 1998.
[9] A. Polze, K. Wallnau, and D. Plakosh. A Study in theUse of CORBA in Real-Time Settings: ModelProblems for the Manufacturing Domain. TechnicalReport CMU/SEI-97-TR-011, Software EngineeringInstitute, Carnegie Mellon University, Pittsburgh,USA, 1997.
[10] A. Rasche and A. Polze. Configuration and DynamicReconfiguration of Component-based Applicationswith Microsoft .NET. In Proceedings of theInternational Symposium on Object-oriented Real-timedistributed Computing (ISORC), pages 164–171. IEEEComputer Society, May 2003.
[11] A. Rasche and A. Polze. Redac - dynamic
reconfiguration of distributed component-basedapplications with cyclic dependencies. In Proceedingsof the 11th IEEE International Symposium on Objectand Component-Oriented Real-Time DistributedComputing (ISORC), to appear. IEEE ComputerSociety, May 2008.
[12] A. Rasche, M. Puhlmann, and A. Polze.Heterogeneous Adaptive Component-BasedApplications with Adaptive.Net. In Proceedings of theInternational Symposium on Object-oriented Real-timedistributed Computing (ISORC), pages 418–425. IEEEComputer Society, May 2005.
[13] A. Rasche, B. Rabe, M. von Lowis, J. Moller, andA. Polze. Real-Time Robotics and Process ControlExperiments in the Distributed Control Lab. In IEESoftware, Special Edition on Microsoft ResearchEmbedded Systems RFP, pages 229– 235. IEEProceedings Software, October 2005.
[14] A. Rasche, P. Troger, M. Dirska, and A. Polze.Foucault’s Pendulum in the Distributed Control Lab.In Procceedings of IEEE Workshop on Object-OrientedReal-time Dependable Systems, pages 299–306. IEEEComputer Society, October 2003.
[15] J. Schwarz, A. Polze, K. Wehner, and L. Sha. RemoteLab: A Reliable Tele-Laboratory Environment. InProceedings of the International Conference onInternet Computing, pages 55–62. CSREA Press, June2000.
[16] P. Troger, A. Rasche, F. Feinbube, and R. Wierschke.SOA Meets Robots - A Service-Based SoftwareInfrastructure For Remote Laboratories. InProceedings of the 2nd International Workshop onelearning and Virtual and Remote Laboratories, pages57–62. Hasso-Plattner-Institut, UniversitatsverlagPotsdam, Germany, February 2008.
[17] M. Wulff, P. Lauer, and T. Braun. Contentmanagement and architectural issues of a remotelearning laboratory. In Proceedings of the 2ndInternational Workshop on elearning and Virtual andRemote Laboratories, pages 13–19.Hasso-Plattner-Institut, Universitatsverlag Potsdam,Germany, February 2008.
