Inspiration
Understanding fleet maintenance necessities can generally affect business security and benefit. The business issue for this mimicked information is to foresee issues brought about by past disappointments. The business question subsequently is "The thing that is the likelihood that a machine goes down because of disappointment of a segment inside the following 7 days?" This issue is designed as a multi-class order issue (various segments per machine) and an AI calculation is utilized to make the predictive model. The model is prepared on verifiable information gathered from machines. In this situation, the client goes through the different strides of executing a particular model inside the Azure Machine Learning Workbench climate.
An underlying methodology is to depend on remedial maintenance, where parts are supplanted as they come up short. Remedial maintenance guarantees parts are utilized totally (not squandering segment life), however causes cost in both personal time and unscheduled maintenance necessities (off-hours, or awkward areas).
An option is a safeguard maintenance plan. Here a business may track or test part disappointments and decide a protected life expectancy wherein to supplant that segment before disappointment. For wellbeing basic hardware, this methodology can guarantee no calamitous disappointments. The disadvantage is parts are supplanted oftentimes, numerous with outstanding life left. The inspiration to do this project came into my mind after completing my Microsoft Azure training.
What it does
The objective of predictive maintenance is to upgrade the harmony among remedial and safeguard maintenance. This methodology possibly replaces those segments when they are near disappointment. The investment funds come from both broadening part life expectancies (contrasted with preventive maintenance), and decreasing unscheduled maintenance (over remedial maintenance).
The objective of this situation is to control an information researcher through the execution and operationalization of the predictive maintenance arrangement utilizing Azure Machine Learning Workbench.
Prerequisites
An Azure record (free preliminaries are accessible).
An introduced duplicate of Azure Machine Learning Workbench with a workspace made.
For model operationalization: Azure Machine Learning Operationalization with a neighborhood sending climate arrangement and a model administration account
This model can be run on any AML Workbench process setting. Nonetheless, it is prescribed to run it at any rate of 16-GB memory. This situation was constructed and tried on a Windows 10 machine running a distant DS4_V2 standard Data Science Virtual Machine for Linux (Ubuntu).
Login
When you have introduced the AML Workbench application, we need to associate the application with your Azure membership. From the AML Workbench File menu, select either the Open Command Prompt or Open PowerShell CLI. The CLI interface permits you to get to your Azure administrations utilizing the az orders. First login to your Azure record with the order:
az login
This will create a key to be utilized with the https:\aka.ms\devicelogin URL. The CLI will stay hindered until the gadget login activity returns.
Make another task
To make another undertaking, either utilize the + symbol from the PROJECTS sheet, or select New Project... from the File menu. The Project discourse just requires entering a Project name which is utilized for the registry name just as the venture name in the PROJECTS workbench sheet. You can choose an undertaking layout, for example, the Predictive Maintenance model format. This will introduce the model records to investigate the workbench climate.
Interface with a far off DSVM
The predictive maintenance instructional exercise can be run inside a nearby docker climate on a machine with sufficient memory (>=16G smash). We propose utilizing an Azure Linux Data Science Virtual machine (DSVM) to guarantee the base figure assets. The situation was created utilizing the DS4_V2 standard Data Science Virtual Machine for Linux (Ubuntu).
While making the DSVM
Empower the username and secret phrase association alternative.
Empower SSH network.
When the DSVM is provisioned, we associate the AML Project to the Linux DSVM utilizing the CLI (File menu, select either the Open Command Prompt or Open PowerShell CLI).
az ml computetarget join remotedocker - name [Connection_Name] - address [VM_IP_Address] - username [VM_Username] - secret key [VM_UserPassword]
Where:
[Connection_Name] is the name you'd prefer to use to allude to the dsvm. We use LDSVM, however, this name is your decision.
[VM_IP_Address] is either the public IP address or the DNS name doled out to the DSVM in the sky blue entrance.
[VM_Username] the DSVM username utilized during creation.
[VM_UserPassword] the DSVM secret phrase utilized during the creation
When the association data is put away, we set up the Docker run time climate on the DSVM utilizing the accompanying CLI order
How I built it
With the docker images prepared, open the Jupyter notebook worker either within the AML Workbench notebooks tab, or start a program based worker, run:
az ml notebook start
The CLI command starts a local Jupyter notebook worker and opens the default program tab pointing to the undertaking root catalog. The example notebooks are put away in the Code catalog. The predictive maintenance example runs these notebooks sequentially as numbered, starting with the Data Ingestion measure in the Code\1_data_ingestion.ipynb notebook. When you first open a notebook, the worker will incite you to interface with a part. Utilize the part associated with the docker container under [Project_Name]_Template [Connection_Name].
The example notebooks are broken into separate pieces of work:
Code/1_data_ingestion.ipnyb download and prepare raw data
Code/2_feature_engineering.ipnyb create model features and target label
Code/3_model_building.ipnyb build and compare machine learning model
Code/4_operationlization.ipnyb deploy a model for production scenario
Each notebook will store intermediate outcomes in an Azure Blob storage container to facilitate a seamless work process. In a request to do this, we require your storage container access keys to be duplicated into each notebook. You can choose a storage container at https://portal.azure.com. Search for a storage account you'd prefer to utilize. Select the account keys thing, and duplicate the [ACCOUNT_NAME] and one of the [ACCOUNT_KEYS] into the notebook code piece:
Enter your Azure blob storage details here
ACCOUNT_NAME = ""
You can find the account key under the Access Keys link in the
Azure Portal page for your Azure storage container.
ACCOUNT_KEY = ""
Each of the four notebooks will require the same access credentials in request to load the past intermediate outcomes.
Task 1: Prepare your data
The Data Ingestion Jupyter Notebook in the Code/1_data_ingestion.ipnyb loads the five input data sets into PySpark format and does some preliminary data visualization. The data is then put away in an Azure Blob storage container on your membership for use in the feature engineering task.
Whenever you have provided your Azure storage account access keys, you can either run each cell individually or Run All Cells from the Cell menu. This notebook will take approximately 10 minutes to run all cells.
Task 2: Feature Engineering
Feature Engineering Jupyter Notebook in Code/2_feature_engineering.ipnyb, reads PySpark data sets and creates the time arrangement features utilized in the modeling building task. The resulting feature data set is also put away in your Azure Blob storage container.
Whenever you have provided your Azure storage account access keys, you can either run each cell individually or Run All Cells from the Cell menu. This notebook will take approximately 20 minutes to run all cells.
Task 3: Model Building and Evaluation
The Model Building Jupyter Notebook in Code/3_model_building.ipnyb that reads PySpark feature set from blob storage and parts into the train and test data sets based on the date-timestamp. Then two models, a Decision Tree Classifier and a Random Forest Classifier are worked with the training data sets. The model performance measured on the test set is compared to determine a "best" answer for anticipate component failures. The resulting model is serialized and put away in the local compute setting for use in the operationalization task.
Whenever you have provided your Azure storage account access keys, you can either run each cell individually or Run All Cells from the Cell menu. This notebook will take approximately 2 minutes to run all cells.
Task 4: Operationalization
The operationalization Jupyter Notebook in Code/4_operationalization.ipnyb takes the put away model and builds required capacities and schema for calling the model on an Azure facilitated web administration. The notebook tests the capacities and compresses the operationalization assets into a compressed document that is also put away in your Azure Blob storage container.
Whenever you have provided your Azure storage account access keys, you can either run each cell individually or Run All Cells from the Cell menu. This notebook will take approximately 1 minute to run all cells.
The operationalization compressed document (o16n.zip) contains three assets: pdmrfull. model, pdmscore.py, service_schema.json. The notebook then details instructions for how to deploy this model for integration into a full predictive maintenance arrangement work process.
What I learned
This scenario gives the reader an outline of how to build a start to finish predictive maintenance arrangement using PySpark within the Jupyter notebook climate in Azure Machine Learning Workbench. The scenario also controls the reader on how all that model can be easily operationalized and deployed using Azure Machine Learning Model Management climate for use in a production climate for making real-time failure forecasts. Then the reader can alter relevant parts of the scenario to accommodate their business needs.
Log in or sign up for Devpost to join the conversation.