Let me set this up – we use Python, all are remote, all use different machines, different OSes. And there is no IT department, so everything is self-maintained. We use GitHub, but that is only the code. We could use Virtual Environment (virtualenv or venv), but everyone would have to manage it independently on their setup. That can work, but changes to the environment (adding a new python package etc) can become a hassle – where is that IT department when you need it!

Code Development using Docker?

On the face of it – yes. For starters it takes the OS, machine related concerns off the table. Docker provides an independent “container” and isolates the code from everything that’s not in the container. Don’t have to worry about hidden dependencies. But we still have some questions:

• Docker seems like a solution for project release or deployment. Is it convenient to work with during development? Can multiple collaborators work on code development using Docker? How would that work? What does the setup look like?
• How often do I have to build the Docker image – every time I want to run code, do I need to build a new docker image? (That would be a pain)
• How heavy is the image – how much extra memory?
• Execution time – is executing code from within the Docker container slower?
• Is Docker easy to setup on any machine? How much extra stuff, effort is it?

We are going to try to answer these questions. First, what is Docker?

What is Docker?

Docker is the “industry standard” approach for implementing containers.

Containers encapsulate an application as a single executable package of software that bundles application code together with all of the related configuration files, libraries, and dependencies required for it to run.

– ibm.com/cloud/learn/containerization (link)

Here is a great video (by Liz Rice, GOTO 2018) that explains the concept and walks through the basics of building a container (like Docker) from scratch in Go. I like to look under the hood first!

The above video provides a great explanation (please do watch the video). Follow that up with this one from the Docker site that does a walk through on how to use Docker. Both show the deployment scenario – a web service released as a containerized solution. That does not address our needs.

There is this series of blog posts that does address python code development using Docker. I am going to follow this and set up a containerized python development environment. Let’s get going.

Installing Docker

• The first step is to create a Docker hub account – required if we want to save and share Docker images. I will be creating Docker images on a Windows machine (or Linux running on Windows), then linking them and sharing through the hub – more on this later though.
• Install Docker on the desktop (Windows 10 pro, ver. 2004). Here is the link to the relevant Docker documentation. (WSL has replaced Hyper-V, so, a) ignore the instruction about Hyper-V; and, b) here is a page that provides more details about Docker and WSL.)  
• Execute the downloaded file, follow the prompts. Launch Docker and follow the instructions – you will download from a git repo, build a docker image, and finally run the image. This launches the docker tutorial in a container.
• The Docker window should look like (Docker Desktop on a Windows machine)

• Hover over the docker-tutorial and click the browser button. This pulls up a docker tutorial.

Testing the Installation

One option is to follow through the tutorial above (and that’s a good option). A second option, especially if you want to quickly check the installation, is:

• Open a terminal/console window
• Test the installation by running the Hello-World docker image (source)

• Try:  C:\Users\username> docker ps -all

Now that Docker is setup, lets create out first Python image

Getting Started with Docker

Before diving in, lets briefly look at what a Docker Image and a Container actually is. These are the key building blocks and understanding them is a must if we want to be effective in our use of Docker. A Docker Image encapsulates an application and the related configuration files, libraries, and dependencies required for it to run. To illustrate, I will create a python app image that encapsulates Python3.8 (or another version), the python package Numpy, and the application code. A Dockerfile captures these various components, which create an image. To run the application, the image is executed, as a container. A container thus is an instantiation of the image. Multiple containers can have the same image. In general, they are all independent of each other, but dependencies can be created.

In the example above, I downloaded the “hello-world” image (created by someone else) and ran it as a container (docker run hello-world). What did docker do? Docker downloaded the image, created a container and executed the application that was specified in the image, within the container.

Some common Docker commands:

docker --help  -> a big list of all the commands you can use
docker build  -> to build an image from the Dockerfile
docker build --help  -> help on the create command. use with any command
docker run  -> create container from image, run the application specified in the image
docker create  -> creates a container from image
docker start/stop  -> to start/stop a container
docker ps  -> see what is running (containers)
docker rm -> to delete container
docker rmi  -> to delete an image
docker images  -> to see all the images

Check here for detailed explanations and examples.

Python using Docker

Python Shell in a Container

We saw above how to execute a docker image as a container. Let’s now create a docker image. As a first step, I want to run python in a container. A textfile (called Dockerfile by default) defines the image. The Dockerfile to run python in a container looks like (for the code head on over to the github repo):

# This is a Dockerfile to build and run a python shell in a container
# set base image (host OS)
FROM python:3.8
# set the working directory in the container
WORKDIR /code
# command to run on container start
CMD [ "python"]

The first line of code above defines the base docker image, in this case Python3.8. The next line sets the working directory within the container. Finally, the last line tells docker what command to execute when the container starts.

Now lets build the image from the Dockerfile we created above, using the docker build command:

C:\Users\kar16\Desktop\Docker_testing> docker build -t python_basic:v0 .

I have given the image a name and a tag by using the -t name:tag above. Docker by default looks for the Dockerfile in the current directory so I did not have to specify it. After creating it, you can check the image created by using docker images command.

Once the image is created, I can run it – which creates a container, and executes the specified command (“python”) in the container.

The command (see in the figure above) is docker run <image_name>:<tag> . I have used the -it option which specifies run interactively and allocate a tty (use docker run –help for details).

Python script in a Container

In the previous section, we created a container running python3.8 in isolation from any packages etc installed on the machine. I can now share this image with anyone and they will run python3.8 irrespective of their machine and their current setup.

But this is not really useful – I need a few more things. One, I need to install relevant packages, and two, our code. To do that modify the Dockerfile so it looks like:

# set base image (host OS)
FROM python:3.8

# set the working directory in the container
WORKDIR /code

# copy the dependencies file to the working directory
COPY requirements.txt .

# install dependencies
RUN pip install -r requirements.txt

# copy the content of the local src directory to the working directory
COPY src/ .

# command to run on container start
CMD [ "python", "-i", "./test.py"]

I am doing a few additional things in this Dockerfile. First, copy the requirements.txt file which specifies the packages needed to run the code. Then install the packages (using pip). Lastly copy over the source code. The command to be executed in the container is also changed so it will execute the specified python script.

The application code is trivial and for illustration only (test.py below).

# Testing docker setup

import numpy as np
from pathlib import Path

print('the current folder is {}'.format(Path.cwd()))
data = np.arange(1, 25)
print('the average is {}'.format(np.average(data)))

Once again, build the image, as follows,

C:\Users\kar16\Desktop\Docker_testing> docker build -t python_basic:v1 .

… and run the container. The output looks like:

This runs in the container – notice the current folder is /code. This is also an interactive session, so the python shell and the container does not exit.

Mounting a local directory into the Container

Lets say we need to change test.py, our application (code development, then use the docker container as the execution environment). The current containerized development cycle consists of writing/updating code, building the image, running as a container and debugging it. There is one issue with this. Every time the code changes, the image needs to be rebuilt in order to get the Python code updates into the container.

We can however apply code changes without having to rebuild the image. We can do this simply by bind-mounting the local source directory to its path in the container. Launch the container, as follows:

docker run -it --mount type=bind,source="$(pwd)"/src,target=/code python_basic:v1

The docker run -it python_basic:v1 is the same as before. The –mount type=bind,source=”$(pwd)”/src,target=/code mounts a local folder, specified by source=, to the target folder in the container, specified by target=

For details check out this docker doc.

And that’s it. Now, whenever the code changes, rerun the container, and it will pick up the new code.

Recap

I started this post as I started learning Docker. In the beginning I asked a few questions, and its time to revisit them. But before I do that, a quick recap.

My Docker journey so far:

• Installed Docker Desktop on my Windows PC, and created a hub.docker account
• Understood the terms – what is a docker image, a Dockerfile, a container
• Downloaded my first docker image, ran it in a container
• Wrote a Dockerfile (created an image) to start a python shell in a container
• Created another image to run a python app in a container
• Mounted a local directory into a container for continuing code development of the python app, with execution in a Docker container.

The code I have used above, including the dockerfiles, is all available in github here.

Q and A

Back to the questions at the top of this post:

Is Docker convenient to work with during code development?

I believe the answer is yes it is. With the setup as described here, I can make changes to the application code, and rerun it in a container with a single line shell command. Its almost as easy as running it by typing python app.py in the shell.

How often do I have to build the Docker image – every time I want to run code, do I need to build a new docker image?

No. Map the local source code directory into the container.

How heavy is the image – how much extra memory?

Python images are large. The first basic python3.8 shell image I created in this post – 882MB. The good news is that we should need to create only one image per project. And the image should not need to be re-created very often. When it comes to building an image for deploying the app, there are ways to reduce the image size by including only what is required.

Execution time – is executing code from within the Docker container slower?

I still have to explore this. There is, understandably, a small overhead associated with creating the container, but I have not measured execution times.

Is Docker easy to setup on any machine? How much extra stuff, effort is it?

Setting up Docker on my machine was straight forward – I had no issues. Took me a couple of days to wrap my head around the concepts, terms etc but that is personal.

Docker or Virtual Environment?

While setting up and using Docker is easy, and its utility is unmatched in certain scenarios (sharing a demo, deploying an app etc). But is Docker the right solution during development? Having gone through the setup above and trying out Docker, I feel it would be remiss of me if I don’t compare with using virtual environments during development.

Jupyter notebooks is one key reason to use virtual environments. It is an easy and convenient way to develop code. So I am going to look at virtual environments using conda.

Create a virtual environment like this (at the Anaconda Powershell Prompt):

conda create -n env_test_docker python=3.8

Activate the virtual environment:

conda activate env_test_docker

You can see the environments by typing conda env list in the Anaconda shell (see below; note the current env has an ‘*’ before the name)

Once in the new environment, the next step is to install the required packages. Do it as follows:

pip install -r requirements.txt

The packages can be installed during the environment creation using an environment.yml file. See here for more details on conda env.

Once the packages are installed, this setup should work across platforms. There is no isolation though, and there might be issues due to underlying platform, and individual management of the virtual environment.

The post Using Docker To Collaborate On Code Development Across Sites appeared first on Kartik Nanda, Engineering AI.

You will find here many of the projects that I have worked on, and, am working on. For any project, I have tried to document it as I have worked on it. I have tried to capture, and link to, what I found to be the most relevant sources – for learning and knowledge, as well as code. In most cases, the code is available on my github page.

If you’d like to know more about me, click here, or just drop me a line. I look forward to hearing from you – so, how are you?

The post Nice to meet you! appeared first on Kartik Nanda, Engineering AI.

As an undergraduate student at the Indian Institute of Technology (IIT), Kanpur, I remember this sinking feeling at the end of every semester – I don’t see myself doing that for the rest of my life! Four years and something like forty courses, and at the end of it, I still had no idea what I wanted to do – every course had been a struggle.

So I did the only logical thing – enrolled for a masters. It wasn’t until the second semester of graduate school at Notre Dame that I found a course that I just “got” – Algorithms. Of course, realization has taken many more happy years to sink in.

That interest in algorithms took me to signal processing early in my career. I designed delta sigma ADCs (or sigma delta, if you must!), digital filters, DSPs. Since these don’t exist in air, what I was actually doing was building mixed signal ICs. I started to think of myself as an IC guy (really! Prof. Kar’s course!!). 

But algorithms wasn’t done with me yet – I moved on to solar, or more specifically, generating electricity from solar. From designing ICs, to coding algorithms for building irrigation pumps that run directly from a solar PV panel. Solar, though, is more than just a product for me. It has enabled me to return to India (where I was born), to rural India – what a learning experience that has been. I am now also more conscious of the environment, and of how we live our lives. 

My focus nowadays is Artificial Intelligence (AI), specifically deep learning using neural nets. Projects include looking for anomalies in audio signals, audio keyword recognition, identifying anomalies in images taken by a drone. All of these are algorithms – AI is but another tool. A powerful tool though, that makes it possible to do things we couldn’t earlier. I believe that AI complements human intelligence, not replace it. In other words, do things that humans cannot do or find too painful (expensive, tedious) to do.

So, what do I do? – I design algorithms and build products around them. That is me, in a nutshell. I call Austin, Texas home, am married and have two wonderful daughters. I like the outdoors – in the pre-Corona days you could find me on Lady Bird Lake at least three evenings every week.

OK, what do you do? Can I help you with your next thing? Do write …

The post Kartik, what do you do? appeared first on Kartik Nanda, Engineering AI.

The main goals:

• Capture images / video using a camera (sensor) connected to the Pi
• AI algo executes on the Pi
• Result is communicated to “Hub” using BT, Wifi etc. Hub could be another computer, IoT Hub, or the Cloud.

Since I have never worked with the Raspberry Pi previously, let’s start at the very beginning.

Hardware:

• Raspberry Pi 4, 4GB version (bought the Canakit Raspberry Pi 4 Starter Kit)

• OV5647 5.0MP Camera Module (bought at dlscorp.com site)
  The OV5647 module is the older version. There is a new official camera module, but I decided to go with the older version for two reasons – cost and 5MP (vs 8MP in V2) is plenty for AI applications. Important details – needs to be a CSI module, and comes with a replaceable lens mount (M12)

• Camera lens (bought different lenses from dlscorp)

• Monitor – used an old monitor I had from years ago. The Pi connects to a monitor using a micro-HDMI port. The kit includes a micro-HDMI to HDMI cable, but I needed to buy a micro-HDMI to VGA adapter for my Monitor.

• Keyboard and mouse – used an old keyboard I had laying around

Software:

• Used the standard NOOBS (preloaded on the micro SD card), and the full Raspbian install. Nothing fancy, yet.

Step 1: Connect the System

There are many excellent walk throughs – see here or here. The basics are simple enough – connect the display, keyboard and mouse, and the power, and follow the onscreen prompts. There are a couple of things I would like to point out though. One, setup SSH and VNC access to the Pi, so you can connect to it from a remote computer and don’t need the dedicated mouse, keyboard and monitor. This will be especially useful during deployment of the application. The second thing – update the software. Use “sudo apt-get update” and “sudo apt-get upgrade”.

Once the system is operational, do take the time to explore, browse the web etc. Marvel at a simple yet very complete computer.

Step 2: Python Setup

There are other languages, of course, but Python is the language of choice. Python2 and Python3 come pre-installed, with a bunch of packages. The first thing is the virtual environment setup – extremely important given the stand-alone nature of the intended application. The application should not break because of an update a couple of years out. I used virtualenv – here is a good intro.

I spent some time (a little) trying to research the “best” editor but realize that the Pi is not necessarily where I will develop the code. That can be done on a laptop or in the cloud. So, for now I am using Thonny, which came pre-installed. I have not yet written a lot of python on the Pi, will see how it goes over the next few days/weeks – might yet change my mind.

Try out a simple program, ensure that python is up and running. In the next post, the camera setup.

The post Setting up the Pi is easy appeared first on Kartik Nanda, Engineering AI.

There is not much online that compares these today, partly because its still early days. There was a panel discussion on this topic at the Texas Wireless Summit (link to the YouTube video). The excellent panelists covered some of the aspects I talk about here.

The table below summarizes some key considerations and suggests which is better – the Cloud or the Edge. Below we examine each, and present our rationale. There is not a mathematical proof, but rather intuitive arguments, with some examples. We consider two examples. First is the facial recognition on mobile devices – we can unlock our phone, the laptop just by looking at it. The device uses its camera to “see” us, and uses an AI model running on the device itself to recognize the face, and unlock. Why does this model sit on the Edge?

The second example is a drone searching for forest fires. Consider two possible implementations. Option 1 – the images are streamed into the Cloud, where the AI model looks for the fire. Option 2 – the AI sits on the drone itself, and the drone then only communicates the location of the fire.

Accuracy

Accuracy is a simple one. By “accuracy” we mean the accuracy of the AI model’s output. The Cloud has more resources, and in general, that translates into higher accuracy. What are these Resources? – compute and memory, so a bigger, more complex model. But it could also be access to other data (sensor fusion, or data from other deployments), or historical data, or other information that is not available at the Edge.

A drone with a model in the Cloud is likely better at detecting fires.

Time

Time – how long before we get the output result – is slightly more complicated. For the same computation, the Edge will be faster than the Cloud. Why? – the Edge is the data generation point. If the model sits in the Cloud, the data has to be uploaded, then inferred, and the results downloaded back to the Edge. However, if the results are not going back to the Edge and instead stay in the Cloud, then time might be the same.

For the phone unlock example, the Edge is a better place for the AI. The action – unlock the phone – is at the Edge.

Reliability

Sending data to the Cloud has a “variable” time aspect as well. Communication depends on many factors, like network availability, signal strength, data routing, traffic. Some are controllable, others harder. In a worst scenario, what if the data does not get through – will it be an issue that can be recovered from?

As an example, if the face recognition unlock on the mobile phone ran in the Cloud, it likely wouldn’t be a feature!

Power

There is a simple rule – the farther the data has to travel, the more power it needs. The most power-hungry part of an IoT (Internet of Things) device is the radio (eg, see Modeling Power Consumption for IoT devices). The energy consumed of course depends on the amount of data sent. As an example, assume a drone looking for a fire. Option one is to send a video stream and process it in the Cloud. Another would be for the AI model to sit on the drone, and for the drone to only send the location of the fire. From the power perspective, the later will be far better.

Cost

Closely tied to power is the cost. This is not obvious, because cost can include many things. However, purely from a cost-of-data angle, streaming the video is more costly than processing it at the Edge (on the drone, in the example above).

The broader question about cost is harder. One aspect is one-time costs Vs recurring costs. While the Edge device is more a one-time cost, the Cloud presents a recurring cost. That’s only one aspect though, and cost has to be evaluated on a product by product basis.

Security

There are two ways to look at security. One is the security of the data. It is most secure, and most easily secured, if it never leaves the Edge. Once the data is on the internet, or in the Cloud, it is only as secure as the encryption/protocols.

The second is securing the Intellectual Property (IP) – the AI model for instance. This is more secure if its in the Cloud.

Privacy

While “security” looks at the problem from the Provider’s perspective (company building the product), “privacy” looks at it from the Consumer’s perspective (person or entity using the product). It is a major concern, and becoming more important every day. Imagine if every time face recognition AI unlocks my phone, my image is uploaded to the Cloud. Then another AI algorithm uses it to “read” my emotional state, and sends suggestions (ads). That is a possibility (easy) with Cloud-based AI, but not as much with Edge-based AI.

The easiest way to keep our personal data personal is to keep it on our devices, and not send it to the Cloud.

So there’s the short list of considerations to keep in mind while planning your AI deployment, and figuring out where it belongs – the Cloud or the Edge. It is not a comprehensive list, and there are many other considerations like time-to-market, managing deployment, cost of building the solution, technology etc that are not covered. They make more sense though if examined within the scope of the AI project. Feel free to reach out with thoughts or if you need help to get started on your project.

The post Edge or Cloud – Where should AI live? appeared first on Kartik Nanda, Engineering AI.

Two things make this all possible – the Internet-of-Things (IoT) and Artificial Intelligence (AI). IoT is the physical interface, the senses. The internet senses the World through the IoT devices. In simpler terms, they collect the data – a camera that takes pictures or a microphone that listens. Or it could be simpler sensors like a thermometer (measuring temperature).

But merely collecting all this data is not useful. (The quantity of this data is huge and increasing.) Something has to interpret and convert this data into actionable information. Something, that can extract meaningful information from this data. That is where Artificial Intelligence (AI) steps in.

Today the AI lives in the cloud (for the most part). IoT collects and sends data to the Cloud, where the AI interprets it, and decides the outcome. Let’s see how this works with examples.

AI and IoT – a marriage made in the Cloud

In the context of IoT, the goal of AI is:

• to learn a model from the data, and,
• use the model to interpret new data and provide an actionable outcome (a decision).

We’ll consider two examples – a voice assistant, like Alexa or Siri, and a smart front door. The Voice Assistant understands human language. For the smart front door, the goal is that the door should recognize me and unlock itself, without me having to use a key. 

Example: The Voice Assisant

The Voice Assistant (VA) responds to spoken commands. It uses a microphone (the IoT sensor) to listen. The AI makes sense of the sounds – the words, sentences and context. It then provides the information or acts on the command. (For example, playing specific music or provide driving directions).

Figure shows how this works. The IoT gathers the data (1) – in the case of the Voice Assistant, the data is sounds. This data is then sent to the Cloud (2). Here the data trains the AI (3) and build a model. The model is then deployed (4).

The model for the VA is complicated. It needs to understand the entire language, spoken with many different accents. Once trained though, the same model applies to all the VAs in the network.

For the Voice Assistant, the model (AI) learns and is deployed in the cloud itself.
The AI receives and interprets all spoken words in the Cloud (Cloud-AI). Why keep it in the Cloud? Mostly because it is a large model. It is also being constantly updated, and keeping it in the Cloud means only one model needs to be updated. The main issue is the lack of privacy. Anything I say, the VA is listening to and sending to the Cloud where it may be interpreted.

Example: The Smart Front Door

The goal with the smart Front Door is it recognizes me and responds by unlocking the door for me, and only me. It needs to sense my presence, and let’s say it uses a camera (the IoT sensor). AI provides the intelligence. It learns what I look like and then uses that model to recognize me and open the door.

The Front Door system design may follow the same approach as the VA. The camera (IoT) gathers the data, which is sent to the Cloud. There the AI learns to recognize me. But here things become different. The AI has to recognize my face for my door, and my neighbor’s face for their door. That means the AI trains differently for different doors.

This is a critical difference – in the VA case, the same AI (one trained model) could serve all IoT devices in the network. But in the Front Door example, every door has a unique model.

So for the Front Door, it might make sense to instead deploy the AI in the IoT device itself (IoT-Edge), rather than the Cloud. The Front door only needs to decide Me-Vs-NotMe. So while the model may train in the Cloud (esp. the Not-Me part), it is deployed at the IoT-Edge.

There are other good reasons for the different approaches (Cloud AI Vs Edge AI). Two of the main ones are privacy, and the size of the model. Large, typically complicated models can not fit on the resource-limited IoT devices. But, I also do not want a digital representation of my face stored on the cloud.

Heterogenous IoT Networks

We looked at two examples above – the VA and front door – both using single IoT devices. In general though, IoT networks consist of many devices. They are also not always homogenous, that is, not all the attached systems are identical. They may have some common features, but some unique ones as well. Think of a factory floor or even the car – both have many different types of sensors (IoT sense devices).

This complicates the AI. It is no longer possible to train the AI on one IoT device, and map the model to all the IoT devices in the network.

To illustrate this, imagine if my front door now has a fingerprint sensor in addition to the camera. The AI for the camera cannot map to the finger print sensor. Yet the two have to work together on the same problem, namely to recognize me and unlock the door.

The figure shows a general scenario – it depicts two different IoT sensors. They both have some common features, and some unique ones. One solution is to learn a superset of all possible features in the cloud. The result is a large, complicated model. This needs far more resources in the IoT edge devices, or compromises on privacy by keeping the AI in the Cloud (figure below, left).

A Distributed AI Model (Edge-AI)

Another solution is a Distributed AI model. This implements the AI on the network (above figure, right) – which includes the Cloud and the different IoT devices. Parts of the solution – the common features – are mapped to the Cloud. The unique ones are modeled and learnt locally on the IoT sensor devices.

This provides both benefits – privacy and resource management. Since the model is local to the IoT edge device, private data is not sent or stored in the cloud. This also utilizes the available resources better. The IoT devices store only local models, and not the entire systems’ model. The result – a smaller footprint at each IoT device. Much of the AI now resides on the network devices. This reduces the computations and data requirements in the cloud.

This is a Distributed AI solution (or Edge-AI). As IoT networks become more prevalent, we will start to see more AI move to the Edge. Lets illustrate with an example next.

Example – Solar Monitoring with Distributed AI

The past few years have seen a tremendous growth in rooftop solar plants. Many residences today generate their own electricity from the Sun. Here’s a common question that comes up all too often from owners:

“I have installed a rooftop solar plant for electricity. How do I know if the energy output from my plant is actually correct, as designed?”

Solar Customer

Data there is plenty of – solar plants provide daily energy output data. The problem is this energy output number changes from day to day, based on many factors like the weather. What is lacking (and what the owner is looking for) is information. Is the output correct?

AI and Solar Monitoring 

The goal with AI, is to learn a model of the Plant, and to monitor it by comparing actual output against the predicted output.

One solution is to model the plant in the Cloud (the Cloud-AI solution). The first step is to take all the data into the cloud. The second step is to learn a model of the plant – certain plant specific details such as the shade profile. The third step is to predict the output under the given environmental conditions. The final step is comparing the actual output from the plant and the predicted output. The result is actionable information – is the plant output good or not.

This solution works, but has two issues. The first is privacy – all the data goes to the Cloud. The second is scalability. Imagine learning the models for hundreds of thousands of small residential solar plants in the Cloud. A better solution: if the models could be learnt locally in the IoT device themselves.

Edge-AI solves both of these issues. The AI solution maps on to the entire network (see figure). Certain elements that are common to all the plants – the weather for example – are modeled in the Cloud. The Plant specific modeling however, is local.

The result is better on many fronts. One, the distributed model uses resources more optimally by processing data locally. Data privacy is much better since all plant modeling is local. The network scales easily. Adding a new plant is easy since every plant learns its own model, and only its own model. 

Closing Thoughts

Products and solutions based on a network of IoT sensors are set to become prevalent. Some applications include the electricity smart-Grid, a smart-home, individualized health care. AI will be an integral part of any such product. And while today Cloud-based solutions dominate the AI landscape, such AI-IoT network products will need new distributed topologies.

Edge-AI is a distributed AI topology. It maps the AI on the entire network, not just in the Cloud. This provides two distinct advantages over AI in the Cloud. The first is privacy – with models that are learnt locally. Second is the lean implementation, an optimal use of the available resources.

Distributed AI will drive the next wave of Intelligent Products.

The post AI and IoT – Marriage made in the Cloud appeared first on Kartik Nanda, Engineering AI.