Change to In-depth Research Approach

Current Situation

Starting from 23rd March, due to the unforeseen circumstances occuring in New Zealand, my work placement was placed on halt for the moment. This is from the consideration from my supervisor that the tasks for me is more effective to be done on-site. On the time of this post writing, New Zealand is on alert level 3. NPI has the policy to only allow employees which are essential for running the production line. There is no precise time to when I will go back to my work placement, however with thorough discussion with my supervisor, Neil Benson, we agreed on a different approach on the final project as well as report writing.

Report Approach

As I have discussed with Neil, I will be doing a more in-depth research on each tasks which I have done so far. This will include comparing with other approaches and looking for best practices on the activities I have implemented or will implement.

To break it down, I have 3 kinds of tasks which I did so far. These tasks are:

• Visualizing devices connected to the network with the on-site map from the network diagnostic tool (in this case PRTG). This will include security cameras and wireless access points all around the factory
• Visualizing traffic flow to understand the throughput on each switches to detect bottle necks on the network. This was done also in PRTG maps which showed the network diagram in addition to the bandwidth information.
• Documenting an emergency switch recovery procedure. This task was put on halt and not done yet until this point. However, some parts were finished but still unusable as it is not properly tested.

Regarding the network diagnostic tool, I would not suggest that these tasks should be done in different software. A network diagnostic tool is a whole infrastructure which should not be separated for different functions. Thus, some comparation as a whole network diagnostic software could be done and see what are some advantages and disadvantages in this context.

For the second task, a best practice to visualize traffic flow or diagnose bottlenecks in the network might be a possible approach for this report. It is good to understand and explore on different methods to implement on a 24/7 running production line network.

A part of this documentation of the emergency switch recovery procedure would be testing. As currently I am not able to proceed to that, the approach I am taking is to find theoretical solutions to this task. In addition to that, I would prepare some best practices to properly do isolation for the testing of a recovery switch.