DESIGN AND IMPLEMENTATION OF SOFTWARE COMPONENTS FOR A REMOTE LABORATORY

1. DESIGN AND IMPLEMENTATION OF SOFTWARE COMPONENTS FOR A REMOTE LABORATORY J. Fernandez, J. Crespo, R. Barber, J. Carretero University Carlos III of Madrid Computer Science and Engineering Systems Engineering and Automation Department

2. CONTENTS • Introduction • Virtual and Remote Labs • Proposed architecture • Framework components and functionality • Example of remote laboratory • Conclusions

3. CONTENTS • Introduction • Virtual and Remote Labs • Proposed architecture • Framework components and functionality • Example of remote laboratory • Conclusions

4. INTRODUCTION • Goals • Study, develop and compare different technologies for remote labs • Study and test connectivity with hardware in real time • Propose an approach of architecture for development of remote labs • Develop main components • Develop practices for control students

5. CONTENTS • Introduction • Virtual and Remote Labs • Proposed architecture • Framework components and functionality • Example of remote laboratory • Conclusions

6. VIRTUAL & REMTOTE LABS • Real practice difficulties: • Limited number of laboratory resources • Limited time for laboratory resources • Cost of software licenses

7. VIRTUAL & REMTOTE LABS • Solution: Anywhere Web Server Student Lab

8. VIRTUAL & REMTOTE LABS • Possibilities: • Simulation practices • Remote practices with hardware • Advantages: • More time for practices • No schedules

9. VIRTUAL & REMOTE LABS • Remote laboratories • MWS: RECOLAB (UMH) • EJS: (UNED, UM) • WLAB (UC)

10. CONTENTS • Introduction • Virtual and Remote Labs • Proposed architecture • Framework components and functionality • Example of remote laboratory • Conclusions

11. PROPOSED ARCHITETURE • Goals to be fulfilled : • Allow to remotely access physical resources. • Compose teaching projects that require resources physically distributed. • Expand the resulting framework with new resources and new teaching projects

12. PROPOSED ARCHITETURE • Requirements: • The system should allow developing teaching project applications that involve using remote resources physically distributed. • The framework must allow to attach or to detach new resources without stopping the system. • The project application should be able to send control commands to each resource and to read the response and the state of the resource, all of this using a standard interface. • The user should be able to book all the required resources for a project before executing it.

13. PROPOSED ARCHITETURE • Software specifications: • Multiplatform architecture • Distributed architecture • Modular management of the resources • Common interface • Extensible framework

14. PROPOSED ARCHITETURE • Computing systems: • Laboratory server: The laboratory server is the computing system that is directly attached to the hardware resource that is being controlled. • Main server: The main server is the one in charge of managing all the laboratory servers. • Client device: It is where the teaching project is run.

15. PROPOSED ARCHITETURE

16. CONTENTS • Introduction • Virtual and Remote Labs • Proposed architecture • Framework components and functionality • Example of remote laboratory • Conclusions

17. COMPONENTS & FUNCTIONALITY • These computing systems are classified as follows: • Laboratory server: The laboratory server is the computing system that is directly attached to the hardware resource that is being controlled. • Main server: The main server is the one in charge of managing all the laboratory servers. • Client device: It is where the teaching project is run.

18. COMPONENTS & FUNCTIONALITY • Main database: Stores the general information of the system, which is accessed and updated by the framework main components. • The database contains all information of the laboratories and the resources attached to them. • Also information about the authorized users of the systems and which user is currently using (exclusively) which resource.

19. COMPONENTS & FUNCTIONALITY • Application server: Exports the web services required by the framework (provider service and monitor service). The provider service export the management functionality for each resource while the monitor service allows to keep track of the current state of the system and the list of existing resources.

20. COMPONENTS & FUNCTIONALITY • Laboratory manager: Act as a request manager for all the requests that the clients perform to the resources managed by the laboratory using the web services. Each one has its own local database for local configuration but it also uses the main database. • The task of this module is mainly to launch or to stop the module that manages the resource requested by the client. It also manages the registration and deletion of new resources. Furthermore, it establishes the connection between the client and the module of the resource using a socket interface.

21. COMPONENTS & FUNCTIONALITY • Laboratory manager

22. COMPONENTS & FUNCTIONALITY • Resource manager: This module contains the logic that allows the user to control the resource, execute commands on the resource and read the state of the resource. • It can be directly attached to the hardware or it can use external applications. Each manager is designed specifically for each kind of resource.

23. COMPONENTS & FUNCTIONALITY • Client application: This component can be implemented as a stand-alone program or as a web page. The only requirement is that it should use the web services to connect with the application server and sockets to connect with each resource manager.

24. CONTENTS • Introduction • Virtual and Remote Labs • Approach to the problem • Proposed architecture • Framework components and functionality • Example of remote laboratory • Conclusions

25. Example of remote laboratory • Lab equipment: • CC Motor 4000RPM, 24Vcc • Advantech PCI-1711 • PC & camera

26. Example of remote laboratory Interface for the tests:

27. Example of remote laboratory • Remote practical session: • Identification of the experimental servomotor: first order plant

28. CONTENTS • Introduction • Virtual and Remote Labs • Approach to the problem • Proposed architecture • Framework components and functionality • Example of remote laboratory • Conclusions

29. CONCLUSIONS • Nowadays, the use of new technologies for the implementation of remote laboratories is a leading research topic. • In this work a framework for remote labs has been presented. • This framework allows the integration of different resources and platforms for its use in laboratory practice, taking into account the management of them.

30. CONCLUSIONS • The main components that make up the platform have been developed. Allowing to develop a first laboratory practice prototype of an engineering subject. • The student can book the platform, run an experiment and display their results from home, allowing to perform the practice as many times as needed without temporal restrictions and without having to travel to the educational centre or research centre.