jackmyers.info

Projects for Section 1

Remember, cc all Project sponsors and Professor Myers on all email correspondence. Add Kim Davis (Kimberly.Davis@asrcfederal.com) as well on all email correspondence to ASRC.

1. Stage and Theatre Automation System - Phase 4
   Teams Sea Pigs and Kangaroos
   Fridays 3:30
Proof Productions in Sewell, NJ is responsible for staging many extravaganza events such as the upcoming Frozen Broadway production, Phantom of the Opera, Mary Poppins, and other events. When stage automation is done correctly the audience should believe that the moving scenery has become animate, and is moving itself exactly where it needs to be. The purpose of this project is to further the design and implementation of a means for two-way communication between two different devices through Ethernet. The first device will be a PC running Windows 10. The second is a Raspberry Pi I/O controller device. The intention is to use the Pi as a control board that can communicate with the Windows server. A controller will receive messages that will result it illuminating LED lights and/or a simple display. The project will build from Phase 3 which built an intial representation of the portable Raspberry Pi controllers.

Main Contact: John DiStefano (pcrxco1@comcast.net)
Supporting Contacts: Joe Loftis (JLoftis@proofproductionsinc.com and ProofOffice2@proofproductionsinc.com)

2. Cyber Data Analytics
   Teams Platypi and Chinchillas
   Mondays 3:30

Concept: Conduct and document a study of the analytics that SPLUNK is providing and develop an API/APIs to extract that data to support Cyber Security use cases (i.e. Automated Defensive Cyber Security, Incident Response, Cyber Resiliency).

Contact: Mike Tornari ( mtornari@asrcfederal.com) and Mike Berenato (mberenato@asrcfederal.com)

3. Desktop Testing Suite Scheduler
   Team Elephants
   Mondays 3:30

The Current System The current system is grossly inefficient causing the desktop suites to be far underutilized. There are many instances where time is requested and never used. Also, the case where testing is completed early in the test shot and the remaining time is not needed and goes unused. The current method for returning scheduled time is to email the scheduler to inform them you can no longer use the requested time. The scheduler then sends a broadcast email stating the returned test time is now available. It then gets rescheduled to the first person to reply, without any regard for need. Also, any updates to the schedule requires another broadcast email containing the reflected changes.

Creating a Web Based Scheduler The website would contain the current/lasted schedule. Therefore, updates would no longer have to be emailed, because the website would reflect any changes in real-time.

There would be and entry to create a request for test time for the following week. It could contain number of test shots along with preferred suites and time. All request would need to be entered by noon Thursday. On Thursday all the request would be reviewed and assigned based on a Fairness Algorithm. For example, each time a user receives a test shot, they are assessed points. The better the test time the higher the points, such that if two users are requesting a prime-time test shot and there is only one available, it would be assigned to user with the least amount of points. Point would be deducted base on time. So, the longer a user goes without requesting time the more points will be deducted from their current value. Also, when a user request prime time and receives off nominal time point would be deducted.

Once the schedule is published to the webpage, if there are still open test slots available, a user could select them on a first come first served basis. If the schedule is completely full, and a user needs test time, they could request to be put into a request queue to be notified of the next test shot that becomes available. The Website could interface with Skype to determine if the person in the request queue is available. If they are, they could be notified via Skype. If they are not available or they have not responded within a recommended time, the next person in the queue would be notified. This would continue until someone in the queue responds or there is no one left in the queue, in which case the test shot would revert to first come first served.

Contact: Brian Trail ( btrail@asrcfederal.com)


Modified: