Patent Publication Number: US-2019188774-A1

Title: Recommendation engine for micro services

Description:
FIELD 
     Illustrated embodiments generally relate to data processing, and more particularly to recommendation engine for micro services. 
     BACKGROUND 
     An enterprise solution, offering maintenance and service, aims to improve the visibility of health of assets such as hardware assets, and to prevent failures. A user of the enterprise solution is provided proactively with alerts and information of the hardware assets. To identify a specific hardware asset having problems, an in-depth understanding of the state and health of the hardware asset is required. Exploration and analysis of data collected for the individual hardware assets over a period of time is used to enable the user to build this understanding. The volume of data collected for the individual hardware assets appear as information overload when displayed to the user. Since the data collected appears as information overload prior to exploration, various application and software tools may be used for such exploration. However, it is challenging to automatically identify a right combination of application and software tools to drill down to the data collected for a specific hardware asset corresponding to an alert. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The claims set forth the embodiments with particularity. The embodiments are illustrated by way of examples and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. Various embodiments, together with their advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings. 
         FIG. 1  is a block diagram illustrating functional architecture of an enterprise application with recommendation engine for micro services, according to one embodiment. 
         FIG. 2A ,  FIG. 2B  and  FIG. 2C  are block diagrams illustrating user interfaces of an enterprise application showing user behavior, according to one embodiment. 
         FIG. 3  is block diagram illustrating a user interface of an enterprise application showing recommendation of micro services, according to one embodiment. 
         FIG. 4  is a block diagram illustrating architecture of machine learning engine used by recommendation engine, according to one embodiment. 
         FIG. 5  is a flow chart illustrating process for recommendation engine for micro services, according to one embodiment. 
         FIG. 6  is a block diagram of an exemplary computer system, according to one embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     Embodiments of techniques of a recommendation engine for micro services are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of the embodiments. A person of ordinary skill in the relevant art will recognize, however, that the embodiments can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In some instances, well-known structures, materials, or operations are not shown or described in detail. 
     Reference throughout this specification to “one embodiment”, “this embodiment” and similar phrases, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one of the one or more embodiments. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. 
       FIG. 1  is block diagram illustrating functional architecture of an enterprise application with recommendation engine for micro services, according to one embodiment. An asset may be a hardware asset such as devices, machines, sensors, etc. Assets  102  are connected to enterprise application  103  such as predictive maintenance and service application  104 . Predictive maintenance and service application  104  provides a user with a holistic management of asset health and decision support for maintenance schedules and optimization of resources based on health scores, anomaly detection, etc. Various modules in the predictive maintenance and service application  104  provide details of a specific asset and its components, and monitor the health status of the asset while they are in operation. Micro services  106  are a variant of service-oriented architecture that structures an application as a collection of loosely coupled services. An individual micro service provides a specific functionality, and can be implemented using various programming languages, databases, hardware and software environments. The micro services are autonomously developed, independently deployable, and decentralized. Various micro services  106  are micro service A  108 , micro service B  110 , micro service C  112 , etc. Some examples of micro services are 3D charts, telematics data, service notifications, tree map visualization, top diagnostic trouble codes (DTC&#39;s), life span analysis, etc. 
     The individual micro service may provide output in the form of visualization in a graphical user interface. The micro service is also referred to as insight provider, providing various insights to explore information about the health of the asset. Recommendation engine  114  is a part of the micro services  106 . The recommendation engine  114  for the micro services is a machine language based filtering system that predicts the relevant micro services needed for an analysis and proposes them to a user during an exploration. The user behavior is learned over a period of time, and the past explorations of the user are analyzed. If a past exploration of the user was successful, then it is very likely that the usage of the same micro services for data analysis in a current exploration may be suitable again. The recommendation engine  114  for micro services  106  makes use of a machine learning algorithm  116  associated with a predictive maintenance and service application  104 . Various applications/technologies and platforms may coordinate with the micro services  106  to provide various functionalities, for example, application A  118  may be a predictive analysis enterprise application used to uncover trends and patterns from existing data sources. Technology B  120  may be a column based relational database software system used for business intelligence, data warehousing and data marts. 
       FIG. 2A ,  FIG. 2B  and  FIG. 2C  are block diagrams illustrating user interfaces of an enterprise application showing a user behavior, according to one embodiment. A user starts a new exploration by clicking on new exploration  202  (not shown) to analyze assets such as rail transport vehicles, e.g. trains. The request to perform the new exploration is received in a predictive and maintenance service application. For example, the new exploration  202  may be machine exploration  204  with list of asset identifiers, type of asset, alerts, etc., as shown in  206 . The user may add a new micro service to the machine exploration by clicking on ‘add micro service’  208  as shown in  FIG. 2A . When the user clicks on ‘add micro service’  208 , a list of micro services  210  is displayed in a micro service catalog  212  as shown in  FIG. 2B . The list of micro services in the micro service catalog  212  are explained below. The micro service geospatial visualization  214  provides a visual display of geographical location of the assets in a satellite view. The micro service telematics data  216  provides visual monitoring of the exact location of the asset based on global positioning system (GPS). The micro service layout map  218 , provides a map to visualize three-dimensional layout floorplans of production lines and construction sites. Service notification  220  provides service or maintenance notifications in a visual representation. The micro service colorepath  222  analyses data and presents a summary of results in a visual manner. The micro service tree map visualization  224  provides a summary of results in a hierarchical nested format usually in rectangles. The micro service top diagnostic trouble codes (DTC&#39;s)  226  shows the list of top DTCs for a set of defined assets over a specified time period. The sensors record the health status of the assets, and produce DTC&#39;s. The micro service comparison chart  228  provides a summary of results in the form of charts for comparison. The micro service life span analysis  230  provides a summary of results of life span of assets in a visual manner. The user may select micro services such as geospatial visualization  214 , telematics data  216 , service notifications  220  and tree map visualization  224  during the exploration. The sequence of explorations  232  by the user may be added as evidence in an evidence package  234  as shown in  FIG. 2C . 
     The evidence package is a collection of various exploration results ‘saved’ by the user while exploring diverse data sources to identify potential root cause of an issue. Similarly, various filters and selection of assets may be added to the evidence package. In the example above, the user may add a visual display of geospatial visualization  214 , telematics data  216 , service notifications  220  and tree map visualization  224 , a filter: onboarding, and selection of five assets such as trains, and add it to the evidence package. If this exploration was successful, the status of the exploration will be marked as successfully closed. This indicates that the exploration for the train assets was successful, and the series of exploration recorded in the evidence package may be used by a subsequent user to perform a successful exploration. The exploration along with the status successfully closed is stored in a storage. The evidence package includes micro-level metadata corresponding to tracking the exploration performed by the individual users, search terms provided as input for analysis, the list of micro services selected, etc. The evidence package including the micro-level metadata represents the user behavior, and is provided as input to a machine learning algorithm. The machine learning algorithm receives the evidence packages as input, performs analysis and learns the user behavior and predicts a list of recommended micro service as output. In a similar manner, the evidence packages generated in the enterprise application is provided as input to the machine learning algorithm for analysis. Subsequently used when a different user tries to perform the same or similar exploration, the predicted list of recommended micro services is provided as output to the user. 
       FIG. 3  is a block diagram illustrating a user interface of an enterprise application showing recommendation of micro services, according to one embodiment. A request to perform exploration in the enterprise application is received from a user, for example, the user may perform the exploration to analyze assets such as rail transport vehicles, e.g. trains. Based on the received request, a recommendation engine using machine learning algorithms automatically identifies that the requested exploration is similar to a past exploration, and hence analyzes an evidence package associated with the past exploration. Recommendation engine for the micro services is a machine language based filtering system that automatically predicts the relevant micro services needed for an analysis and proposes them to the user during an exploration. Automatically identified or automatically predicted indicates that identification/prediction takes place automatically without human intervention. Based on the analyzed evidence package, a list of micro services  302  used in the past exploration is provided or displayed in the recommendation tab  304 . Over a period of time, successful explorations are analyzed and learned by the recommendation engine, and the evidence packages associated with those successful explorations are analyzed by machine learning algorithms. 
     Based on the analysis by the machine learning algorithms, the list of micro services that lead to successful exploration is identified. The identified list of micro services  302  is displayed in the recommended tab  304  in the micro service catalog  306 . For example, the list of micro services provided as recommendation is geospatial visualization  308 , telematics data  310 , service notifications  312  and top diagnostic trouble codes (DTC&#39;s)  314 . The micro service geospatial visualization  308  provides a map visualization that allows you to plot your objects and analyze them on a geographical distribution. The micro service telematics data  310  analyzes data sets and presents a summary of results is a visual representation. The micro service map provides a display of assets and their health scores by geolocation and issue severity. The micro service, service notification  312  analyzes data sets and presents a summary of results in a visual representation. The top DTC&#39;s  314  shows the list of top DTCs for a set of defined assets over a specified time period. The sensors record the health status of the assets, and produce DTC&#39;s. 
       FIG. 4  is block diagram illustrating architecture of machine learning algorithm used by recommendation engine, according to one embodiment. The recommendation engine for micro services makes use of a machine learning algorithm  402  associated with a predictive maintenance and service application. User behavior or information corresponding to a user such as explorations and evidence packages are provided as input to the machine learning algorithm  402 . Data science services in predictive maintenance and service applications supports data modelling and deployment. In data modelling, data models are created, configured and run. Data science services in predictive maintenance and service applications is a data science and machine learning algorithm that is integrated with internet of things (IoT) application enablement (AE)  404 . IoT AE  404  facilitates digital representation of real-world objects, and micro services become actionable by integrating with IOT AE  404 . The explorations and evidence packages are persisted through a module in the IOT AE  404  in parallel to persisting assets and other metadata. 
     Management service  406  provides API (application programming interface) for model management, job management and dataset configuration. The configuration details are stored in configuration database  408 . The management service  406  enables storing the configuration details corresponding to the explorations and evidence packages. Feature collection  410  micro service is used to retrieve data from a variety of sources, and save it as an analytical record into a location accessible by the execution engine  412 . For example, exploration and evidence package data are stored as time series data in time series stores. Time series data are events collected at periodic or regular intervals of time. The evidence packages are extracted from time series storage and prepared. A model is learned by computing the distance of individual evidence package in the exploration with a past reference evidence package of successful exploration stored in the time series storage. The computed distance is stored in the time series storage. A score is associated with the model, and the model is ranked. The model with the highest rank above a pre-defined threshold for example, rank 4 or rank 6, etc., is considered as the exploration that is relevant to the current exploration. The model with the highest rank corresponds to one or more evidence packages, and the micro services in the evidence packages are automatically provided as recommendation by the recommendation engine. 
     The computed scores are persisted in the score persistence  414  module. A score persistence micro service is used to transfer scores computed for the models to IOT AE  404 -time series store. Object store  416  enables the storage of objects and involves creation, upload, download and deletion of objects such as scores, models, etc. For example, the model learned in the above example may be stored as an object in the object store  416 . Execution engine  412  is a micro service that executes the machine learning algorithm  402 . An execution engine  412  instance processes task(s), and several execution engine instances can be active at the same time. 
     The machine learning algorithm  402  in the execution engine  412 , the scheduler  418  enables users to setup scheduled executions of model scoring jobs. API  420  is used as interface for IOT application  422 . Using various machine learning algorithms for the recommendation engine, the explorations and associated evidence packages are analyzed, and the list of most appropriate micro services are automatically identified. The identified micro services are displayed in a recommended tab in the prediction and maintenance service application. The evidence package corresponding to the model is retrieved, and the micro services in the evidence package are automatically identified as relevant micro services to the current exploration. The identified micro services are displayed in the recommended tab in the predictive maintenance and service application. 
     In one embodiment, data mining algorithm such as association rule mining may be used. User behavior or information corresponding to a user such as successful explorations and evidence packages are provided as input to the data mining algorithm in the machine learning execution engine. Analysis is performed on the list of micro services provided in the successful explorations and evidence packages, for discovering uncovered relationships based on the frequency of occurrence of individual micro services. The uncovered relationships can be represented in the form of rules. To generate rules, various data mining algorithms such as Apriori algorithm, DSM-FI, etc., can be used. In order to find frequent micro services, support and confidence of micro services are determined. The strength of a rule X-&gt;Y can be measured in terms of its support and confidence. Support determines frequency of occurrence of micro services X and Y appearing together in an evidence package, while confidence determines how frequently Y appears in evidence package that contains X. Support could be calculated using a formula: 
     
       
         
           
             
               Support 
                
               
                 ( 
                 
                   X 
                   → 
                   Y 
                 
                 ) 
               
             
             = 
             
               
                 Count 
                  
                 
                   ( 
                   
                     X 
                     ⋃ 
                     Y 
                   
                   ) 
                 
               
               N 
             
           
         
       
     
     where X and Y may represent any micro service, count (X∪Y) represents a count where both micro services X and Y occur in individual context/evidence package, and N represents the total number of micro services in the dataset. Confidence is calculated using a formula: 
     
       
         
           
             
               Confidence 
                
               
                   
               
                
               
                 ( 
                 
                   X 
                   → 
                   Y 
                 
                 ) 
               
             
             = 
             
               
                 Count 
                  
                 
                   ( 
                   
                     X 
                     ⋃ 
                     Y 
                   
                   ) 
                 
               
               
                 Count 
                  
                 
                   ( 
                   X 
                   ) 
                 
               
             
           
         
       
     
     where X and Y may represent any micro service, count (X∪Y) represents a count where both micro services X and Y occur in individual evidence package, and count (X) represents the count where micro service X occurs in individual evidence package. For finding rules, a value of minimum support for example 0.2 or 0.3, and a value of minimum confidence for example 0.3 or 0.5, are fixed to filter rules that have a support value and a confidence value greater than this minimum threshold. The micro services having the minimum support value are determined as frequent micro services. Based on the determined micro services, rules can be generated using Apriori algorithm. Using Apriori algorithm, a rule of the type X-&gt;Y is formed if the confidence of the rule X-&gt;Y is greater than the minimum confidence specified to filter the rules. The rules with a confidence value above the specified threshold value is selected, and the micro services corresponding to those rules are automatically provided as recommendation by the recommendation engine. Both methods explained above can be combined to strengthen the recommendation by using the scores and support/confidence values. 
     In one embodiment, a data mining algorithm such as classification algorithm may be used. User behavior or information corresponding to a user such as successful explorations and evidence packages are provided as input to the data mining algorithm in the machine learning execution engine. Analysis is performed on the list of micro services available in the successful explorations and evidence packages. Using a clustering algorithm such as k-means clustering algorithm, the micro services in the successful evidence packages are clustered. When a new request for exploration is received from a user, the current exploration is checked against the explorations clustered using k-means algorithm. Based on the check, a cluster that is similar to the exploration requested may be identified, and the micro services in the identified cluster are automatically provided as recommendation by the recommendation engine. 
       FIG. 5  is flow chart illustrating process  500  for recommendation engine for micro services, according to one embodiment. At  502 , a request is received to perform an exploration in a predictive and maintenance service application. At  504 , a sequence of explorations is added in an evidence package. The evidence package includes the list of micro services. At  506 , the sequence of explorations in the evidence package are analyzed. At  508 , the evidence package is provided as input to a machine learning algorithm. The evidence package includes micro-level metadata corresponding to the exploration in the predictive and maintenance service application. At  510 , configuration data corresponding to the exploration and the evidence package is stored in a configuration database. At  512 , the machine learning algorithm is executed in an execution engine. The execution engine is a micro service. Based on execution of the machine learning algorithm, at  514 , the list of micro services is automatically identified as recommendations. At  516 , the list of micro services is displayed as recommendations in the predictive and maintenance service application. 
     The above explained embodiments have various advantages for end users, developers of micro services as well as the predictive maintenance and service application itself. For example, when an end user tries to explore and identify a list of assets e.g., trains that require service or are due service maintenance. Typically, a large number, e.g., hundreds, of micro services are available to the user for exploring and analysis. Based on the recommendation engine, the user may be recommended a list of micro services including a few of the multitude of available micro services and their variances. The user&#39;s time is saved since, e.g., the user has to spend few minutes on the recommended micro services instead of hours on the hundreds of available micro services. The user may also find new micro services because of the recommendation engine which otherwise would remain unknown. Therefore, discovery as well as efficiency of the user is improved by using the recommendation engine for micro services. 
     For the developers of micro-services, understanding what kind of micro services are typically used together gives them a better insight of the user requirements and thus improve the development of these micro services. For example, if it is observed that a list of alert micro services is often used with a 2D chart visualization micro service, it might be deduced that the end user wants to always see one or more alert in a time series representation. The developers may then decide to make this functionality easier to use and adapt the existing micro services, perhaps even combine them into a single micro service. For the predictive maintenance and service application, the possibility of learning the typical combination of micro services increases its intelligence of recommendation based on the collective usage of recommendation engine/insight providers across all users. The learning from one analysis can be now be potentially used in other cases which is the basic objective of automation. The recommendation engine provides accurate recommendations and this implies reliable and trust worthy recommendation of micro services. 
     Some embodiments may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components maybe implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers. 
     The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term “computer readable storage medium” should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term “computer readable storage medium” should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform any of the methods or process steps described, represented, or illustrated herein. Examples of computer readable storage media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits (ASICs), programmable logic devices (PLDs) and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment may be implemented using Java, C++, or other object-oriented programming language and development tools. Another embodiment may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions. 
       FIG. 6  is a block diagram of an exemplary computer system  600 . The computer system  600  includes a processor  605  that executes software instructions or code stored on a computer readable storage medium  655  to perform the above-illustrated methods. The computer system  600  includes a media reader  640  to read the instructions from the computer readable storage medium  655  and store the instructions in storage  610  or in random access memory (RAM)  615 . The storage  610  provides a large space for keeping static data where at least some instructions could be stored for later execution. The stored instructions may be further compiled to generate other representations of the instructions and dynamically stored in the RAM  615 . The processor  605  reads instructions from the RAM  615  and performs actions as instructed. According to one embodiment, the computer system  600  further includes an output device  625  (e.g., a display) to provide at least some of the results of the execution as output including, but not limited to, visual information to users and an input device  630  to provide a user or another device with means for entering data and/or otherwise interact with the computer system  600 . Each of these output devices  625  and input devices  630  could be joined by one or more additional peripherals to further expand the capabilities of the computer system  600 . A network communicator  635  may be provided to connect the computer system  600  to a network  650  and in turn to other devices connected to the network  650  including other clients, servers, data stores, and interfaces, for instance. The modules of the computer system  600  are interconnected via a bus  645 . Computer system  600  includes a data source interface  620  to access data source  660 . The data source  660  can be accessed via one or more abstraction layers implemented in hardware or software. For example, the data source  660  may be accessed by network  650 . In some embodiments the data source  660  may be accessed via an abstraction layer, such as a semantic layer. 
     A data source is an information resource. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as Open Data Base Connectivity (ODBC), produced by an underlying software system (e.g., ERP system), and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on. 
     In the above description, numerous specific details are set forth to provide a thorough understanding of embodiments. One skilled in the relevant art will recognize, however that the embodiments can be practiced without one or more of the specific details or with other methods, components, techniques, etc. In other instances, well-known operations or structures are not shown or described in detail. 
     Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the one or more embodiments. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated. 
     The above descriptions and illustrations of embodiments, including what is described in the Abstract, is not intended to be exhaustive or to limit the one or more embodiments to the precise forms disclosed. While specific embodiments of, and examples for, the one or more embodiments are described herein for illustrative purposes, various equivalent modifications are possible within the scope, as those skilled in the relevant art will recognize. These modifications can be made in light of the above detailed description. Rather, the scope is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.