Improving SBHS Remote-Triggered Virtual Lab Server and Website Under the guidance of Prof. D. B. Phatak & Prof. Kannan M. Moudgalya Mentors: Rupak Rokade and Inderpreet Arora

Team members Software Interns Hardware Interns Debakanta Kar, NIT Rourkela Deep Bhattacharyya, NIT Trichy Sriya Sainath, NIT Rourkela Hardware Interns Ram Srivathsa, NIT Trichy Rupesh Gupta, NIT Trichy

contents Why SBHS Virtual Lab? Objectives SBHS Virtual Lab Walkthrough Bugs Fixed Features Added Admin Features Health Monitoring Maintenance Scripts Proposed Architecture Hardware Testing Challenges Faced Learning Future Scope Links

objectives Admin features Health Monitoring Bug fixing Proposing another architecture with load- sharing and scalability Testing both architectures Other miscellaneous features

why sbhs virtual lab? Small and Portable Remote-triggered Open-sourced The objective of this lab is to help perform experiments in the Instrumentation and Control System labs virtually, and yet have close to real life experience. Features : Small and Portable Remote-triggered Open-sourced

A brief walkthrough for sbhs virtual lab A Single Board Heater System

BUG FIXES The Problem of Zero Temperature : Cause : Loss of connection to SBHS Opening a new Serial Port in between the experiment. Cannot Connect to Server Message in Client App : Cause : Unhandled Exceptions in Server Code.

BUG FIXES In initial slot allocation Improper Board Allocation : Cause : Foreign key mismatch of accounts and boards tables. IndexOutOfRange Exception : Raised while allocating a board to the first user Occurs when trying to allocate boards when none of them are online Cause : Trying access an element from list of Probable boards which is empty.

BUG FIXES Incorrectly sorted Bookings : Cause : Didn’t take slot orders into account. Deleted slots displayed users : Cause : Undelete App causes delete command to act as soft-delete. Empty Experiment Log Download : Cause : Discrepancy in file created and downloaded. Invalid MIDs Displayed : Cause : False Positives resulted while scanning for SBHS in USB ports due to Arduinos connected.

Features added ADMIN FEATURES Temporarily disable boards for users Unless board is already under use Admin can still access the board. Test any online, unused board Monitor logs of on-going experiments

Features added ADMIN FEATURES Update MID allotted to user MIDs in sorted order Auto-complete usernames Auto-refresh board images every 25 seconds Interface to download users data files based on slot date-time

Features added HEALTH MONITORING An hourly testing to check board connectivity and working condition, and mail the admin if any abnormalities are detected, along with possible causes. Scans all connected USB ports for SBHS Test all detected boards with fixed sequence of system inputs and analyse their responses. Mails the admin a list of defective or detached boards Temporarily disables the defective boards Updates the database accordingly In the load-shared architecture, also aggregates data from slave servers

Features added SCRIPTS TO AUTOMATE SERVER MAINTENANCE Semi-automated script to generate rules for webcam connection Extracts information about the camera and links it to a board-ID Allows existing rules to be modified Automatic script on server start-up to initialize all boards and provide necessary permissions to Apache In load-shared architecture, scripts to synchronize the clocks of master and slave systems, and accumulate data from the latter.

Features added OTHER FEATURES Automated Script to set-up server on a new RPi and make it ready to be added as slave system. Separate local file to store system-specific credentials for security purposes. Update Apache configurations to support Apache 2.4(Latest) Unified client code for both implemented architectures

Proposed architecture Requirements : Load Sharing Reliable Scalable Solution Proposed : Master-slave architecture Inherently, Load shared and scalable Use of Raspberry Pis as slave system increases reliability in comparison to USB hubs .

Proposed architecture

Proposed architecture WORKING: The master keeps a mapping of slaves and its corresponding board. The boards are connected directly to the slaves and hence, all their requests are bypassed to the slaves without the master server’s intervention. At the end of each slot, the health monitoring script is run on the slaves, and the master aggregates the data from them as it finishes executing.

SBHS Grounding Problem Shorted the shield pin of USB with ground pin. Failure to do so would mean noise gets impressed upon data signals, causing communication failure and dropping packets. Arduino based Switching Control Developed code for arduino nano which would turn on/off the SBHS devices connected through relay boards. This was successfully tested by sending commands through remote user using python script. Building further on this, logic could be developed to turn off SBHS devices when not in use.

DESIGN LAYOUT OF ATMEGA16 MICROCONTROLLER

Testing Both the architectures were tested for hours with multiple clients running simultaneously. Every new feature added was tested individually during the experiments. The load-sharing architecture turned out to be more reliable than the former one.

Challenges Faced Version compatibility issues: Upgraded project structure from Django 1.6 to Django 1.11(Latest) Removed old dependencies No proper documentation: For Classes and Methods. To setup the existing server from scratch. To recreate bugs.

LEARNING Web Development in MVC based Frameworks(Ex. – Django) Configuring Apache Bash Scripting especially event-triggered scripts. Team Collaboration through git Testing Server in Production mode.

FUTURE SCOPE Labs with micro-controller based device can be converted to similar virtual labs. The basic framework explained earlier can support it with device specific modifications.

LINKS The project’s codes and ReadMe can be viewed in the links below: Former Architecture Load-Shared Architecture (Master) Load-Shared Architecture (Slave) Project Documentation For Developers

THANK YOU