AI Diagnosis Engine

Starting from this blog on I will switch to English as this makes my writing process much more efficiënt. In this blogpost I will describe one of the most import components of my project, the AI Diagnosis Engine. In the previous post, I wrote a short paragraph about the high level functionality this major component offers and what factor it depends on. Today I will talk about all the sub-components and relations/interactions between them. 

Plant Deficiëntie Dataset

The first sub-component of AIDE that I will cover is also the most critical part. The PDD (Plant deficiency dataset) is a dataset with labelled images representing different disease-plant combinations. The quality of the PDD is heavily reliant on the quality and quantity of labelled pictures it contains. This dataset is eventually used to train the AI model that will be used in the following sub-component to process analysis requests from the end-user.

Actor Model

This sub-component represents the engine behind AIDE. An actor model is a mathematical model used for concurrent computation. This pattern has been used by Microsoft and Twitter for fault tolerant computing and scalability. The way this pattern works, is by having multiple independent computational entities (actors) controlled by a single managing entity. The manager does not control these actors directly but through messaging and task distribution. Each of these actors have their own private state which can be observed by the manager. These actors can create more actors, make local changes, send messages and decide how to answer the following received message. This model is async-, concurrent- and scalable by design. It also has fault tolerant capabilities if implemented correctly. This is because the manager can observe if an entity is taking longer than normal or has crashed while computing. It can then react by restarting the actor or taking other actions. In my project these actors represent my AI analysis functionality, that is trained by the PDD. Whenever an analysis request is found in the database by the manager, it distributes these tasks among the analysis actors.

As you can see in figure 11 on the previous page, this model will run in a web server environment. It is also possible to do this natively, but I found it interesting to do this externally so that it can be offered as a service and on top of that, if I improve the AI functionality by adding a new plant for example, the user doesn’t have to update their app to enjoy these improvements.

Interaction Platform

Coming back to the solution architecture, the next component I will clarify is the “Interaction Platform”. This functional component represents the medium through which the End-user will interact with the system. My architecture is made in a way that any digital medium should be able to interact with the system. In my implementation this medium is a mobile application called “PlantCare”, which is developed during the implementation phase of my thesis. This medium interacts with the rest of the system in the same way as AIDE, through REST API calls to the database. Whenever a user wants to use the system, all they need to do is provide a picture of the plant to the medium and the medium will make an analysis request entry in the database. After which AIDE will read this request and send results back. Following this response, the medium will present these results the user.