Resource Chooser

This project combines a machine learning component with an IoT demonstration. The scenario is as follows:

A company provides services through its resources to a set of clients. This could be a service provider such as an equpiment repair company or a hospital where the clients are patents and the service providers are the medical staff. Every time there is an interaction between the client and the resource, the client rates the outcome on a three-point scale (-1 for a bad interaction, 0 for neurtral and +1 for a good interaction). The company tracks these interactions along with the circumstances that led to the interaction. For example:

Patient P in room 133 is currently recovering from knee surgery. Their blood pressure drops below a threshold, triggering an alarm. Nurse N responds to the alarm, checking the patient, and fixing the location of the blood pressure sensor, which had slipped. At the end of the interaction, patient P was satisfied with the interaction with nurse N and toched the +1 button on their feedback app.

This collection of interactions, combined with the conditions that triggered the interactions, is used to train a predictor: how will the client rate the next interaction with a particular resource. In order to optimize client satisfaction, resources are deployed following the highest-rated predictions.

Documentation

A PowerPoint presentation of this project is located here. A YouTube presentation of those slides is located [here](TODO: Add presentation).

Generating Historical Interactions

A set of fake interaction data are generated by the Generate Outcome History script. It creates three different sets of underlying factors:

1. The Skills for each resource,
2. The Familiarity between resources and clients,
3. The Chronic conditions for each client.

It then creates a set of 100,000 interactions, recording the clientID, the resourceID, the client conditions (Cond_0 through Cond_19), and the outcome (rating) of the interaction. This training data is saved in a csv flat file. A second set of testing data is generated from the same hidden factors. Five sets of outcomes (for five different resources) are created for each of 10,000 possible client condtions, giving a total of 50,000 points. Each of the five outcomes are given for a different resourceID but with the same clientID and set of conditions. In a random case, the first outcome for each interactionID would be chosen.

Azure Model Training

The train_outcomes.csv data were uploaded to the Azure Machine Learning Studio and were used to train a predictive model. The model uses a Multiclass Neural Network to predict the outcomes for a given set of inputs.

The trained model was converted into a predictive web service. (TODO: Link to tutorial here.)

XGBoost Model Training

Locally, I also trained an XGBoost decision tree model to test how the outcomes of client/resource interactions would change if I used the best prediction instead of a random resource. The Python Notebook loads the training data, trains a model, then predicts the outcomes for each possible event. I then look at each interactionID and find the best prediction and the actual outcome for that interaction.

TensorFlow Model Training

A similar implementation is done using TensorFlow/TensorLayer in this notebook. There are two different models saved by this algorithm: model 1 is trained on a portion of the training data, where the full model was trained on all of the training data. Both models have about an 85% accuracy.

IoT Implementation

The scenario is implemented using an Azure IoT Hub, a set of client and resource devices (created using node-red on a local server), and an Azure Web App to monitor the network and to get predictions from the Azure ML Studio web app endpoint.

The provided node-red flows are JSON files. Open the text file, copy the object to the clipboard, and use the Import\Clipboard option in node-red to import the flow.

There are four node-red flows in this implementation:

1. A simulated client device that reads a random client/resource interaction from the test outcomes data file. It outputs randomized data to the ui dashboard and waits for a button press to send an alert. The device twin is then updated into alert status.

2. A flow that simulates resource devices. This flow sets the resource devices to active that were included in the client/resource interaction.

3. A set of flows for device administration. These flows set up the client and resource device tags, enable manual resetting of the scenario, and monitoring of the IoT Hub.

4. A flow that simulates the server web app. This flow does the following:

   1. Listens for Alerts from the IoT Hub
   2. On alerts, gathers the current available resources and the client condition
   3. Sends those configurations to the Azure ML Studio endpoint for prediction
   4. Determines the best prediction and prints out the best resource to employ.

The server flow autostarts on deployment. The client flow must be initialized in order to activate the ui dashboard and activate the resource devices.

Finally, there is a configuration file that contains that connection keys and last known resource configurations.

Instructions on how to set up node-red on an Andorid device are included here.