## 5 Final Remarks
### Software Architecture  
The interaction between the students and laboratories is crucial for the maximum profiteering of the RT simulation resources in a laboratory course. Most VLS consist of a three-layer architecture. The first layer consists of how the student interacts and sends the information and parameters required for the laboratory interaction through a Graphical User Interface (GUI).  
The second layer consists of a web server. A web server is needed to execute the client requests and to communicate with the RT simulators from a remote location. The web server is usually allocated to a different machine, since an RT simulation system cannot be used as a web server. The machine that links the simulators and the student needs to run a local web server; the most common applications to build a local webserver are python, Java, and LabVIEW Web Service. Lastly, the third layer incorporates RT simulators. This layer has the objective of initializing the simulations according to the user parameters specified in the first layer of communication. Figure 4 shows the framework of a basic communications arrangement for an RT VLS with co-simulation strategies.  
A major challenge in VLS is the incorporation of new hardware into the co-simulation loop. A power electronics laboratory is usually able to facilitate a Power Hardware in the Loop (PHIL) simulation approach. PHIL is the addition of real hardware dynamics involving real power and energy transfer, and it is usually incorporated by employing a PHIL module capable of reading such power signals. The advantages of this include the analysis of the system or controller with real field-oriented hardware, making the gap between a prototype and the actual product even smaller.  
Figure 4: Framework Virtual Laboratory Setup.  
Within a VLS environment, where most students interact with pre-designed material and all modifications to a given system can be carried out through software, a PHIL approach would not be feasible; PHIL mainly operates over the manipulation physical connections, and any change in a given PHIL system requires hands-on manipulation to modify the current setup. This issue can be solved by implementing an automated laboratory capable of modifying physical connections between laboratory components. For example, an arrangement of relays operating using a PLC can be installed to modify any microgrid parameters or power converter configuration in an automated and remote manner. The work presented by [PERSON] et al. [42] describes the design and development of a remote laboratory equipped with PLC for the remote manipulation of equipment; the authors mention how this implementation comes with a high investment cost for the hardware. However, they also remark on the added flexibility in the practical work that can be completed by the students. It is clear that the topic of remote automated laboratories is still an open research field for further VLS development. Despite the increased cost of installation, an automated VLS would promote the students' participation by allowing for the remote manipulation of hardware. In this sense, more students can be part the laboratory courses, since all the available tools would be enclosed in virtual systems. A possible scheme for such automated configuration is illustrated in Figure 5.