Self-aware and self-registering software and analytics platform components

Abstract

According to some embodiments, system, apparatus and methods are provided comprising a platform hosting one or more elements; an application programming interface (api) wrapper associated with each of the one or more elements, the api wrapper including input information to the one or more elements, output information to the one or more elements, and at least one instruction defining a function of the element; and wherein the one or more elements and the api wrapper form a self-aware element. Numerous other aspects are provided.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is related to U.S. patent application Ser. No. 15/338,839, filed Oct. 31, 2016, entitled “System Architecture for Secure and Rapid Development, Deployment and Management of Analytics and Software Systems”, U.S. patent application Ser. No. 15/338,922, filed Oct. 31, 2016, entitled “Integrated Development Environment for Analytic Authoring”, and U.S. patent application Ser. No. 15/338,951, filed Oct. 31, 2016, entitled “Scalable and Secure Analytic Model Integration and Deployment Platform,” all of which are hereby incorporated herein by reference in their entirety for all purposes.

BACKGROUND

It is often desirable to make assessment and/or predictions regarding the operation of a real world physical system, such as an electro-mechanical system.

Conventionally, models are used to analyze data and generate results that may be used to make assessments and/or predictions of the physical system. Models may be an important aspect in making industrial systems function efficiently. A model may be built on a local computer and then the model is transmitted to another computer to be executed. However, running the model on a computer different from where it was built may involve re-writing the model program and de-bugging the program, which may be very time consuming and error-prone. This re-writing/de-bugging process may be repeated each time the model is run on another system.

It would therefore be desirable to provide systems and methods to facilitate model construction for a physical system in a more efficient and accurate manner.

BRIEF DESCRIPTION

According to some embodiments, a system includes a platform hosting one or more elements; an application programming interface (API) wrapper associated with each of the one or more elements, the API wrapper including input information to the one or more elements, output information to the one or more elements, and at least one instruction defining a function of the element; and wherein the one or more elements and the API wrapper form a self-aware element.

According to some embodiments, the method includes providing a platform; receiving one or more elements at the platform; defining an API wrapper associated with each of the one or more elements, the definition including input information for the element, output information of the element and at least one instruction defining a function associated with the element; and generating a self-aware element based on the API wrapper.

A technical effect of some embodiments of the invention is an improved technique and system for rapid development and deployment of an analytic and software system. With this and other advantages and features that will become hereinafter apparent, a more complete understanding of the nature of the invention can be obtained by referring to the following detailed description and to the drawings appended hereto.

Other embodiments are associated with systems and/or computer-readable medium storing instructions to perform any of the methods described herein.

DRAWINGS

FIG. 1 illustrates a system according to some embodiments.

FIG. 2 illustrates a system architecture according to some embodiments.

FIG. 3 illustrates a platform according to some embodiments.

FIG. 4 illustrates a flow diagram according to some embodiments.

FIG. 5 illustrates an interface according to some embodiments.

FIG. 6 illustrates an interface according to some embodiments.

FIG. 7 illustrates an interface according to some embodiments.

FIG. 8 illustrates an interface according to some embodiments.

FIG. 9 illustrates an interface according to some embodiments.

FIG. 10 illustrates a block diagram of a system according to some embodiments.

FIG. 11 illustrates a deployment diagram according to some embodiments.

FIG. 12 illustrates a block diagram of the artifact module according to some embodiments.

FIG. 13 illustrates a block diagram of the system according to some embodiments.

DETAILED DESCRIPTION

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of embodiments. However, it will be understood by those of ordinary skill in the art that the embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the embodiments.

It is often desirable to make assessment and/or predictions regarding the operation of a real world physical system, such as an electro-mechanical system.

Conventionally, computational models are used to analyze data and generate results that may be used to make assessments and/or predictions of the physical system. Models may be an important aspect in making industrial systems function efficiently. A model may be built on a local computer and then the model may be transmitted to another computer for execution. However, running the model on a computer different from where it was built may involve re-writing and/or debugging the model program, which may be very time consuming. This re-writing/de-bugging process may be repeated each time the model is run on another system. Additionally, industrial-grade systems may be complex and may involve hundreds of building blocks to work together seamlessly in production environments. Each block may be managed over its lifecycle to preserve the overall product integrity. As the blocks evolve, it may be difficult to manage the dependencies and handoffs between these blocks. Another challenge with conventional systems may be that not all blocks change at the same time, therefore the blocks may need to be managed individually, sometimes keeping different versions of the same blocks running in parallel. Building these conventional systems may involve large teams of developers with multiple technical backgrounds to work together to build the system.

An example of a model may be a Remaining Useful Life (“RUL”) model that may predict a remaining useful life of an electro-mechanical system, such as an aircraft engine, to help plan when the system should be replaced. Likewise, an owner or operator of a system might want to monitor a condition of the system, or a portion of the system to help make maintenance decisions, budget predictions, etc.

Some embodiments relate to digital twin modeling. “Digital twin” state estimation modeling of industrial apparatus and/or other mechanically operational entities may estimate a RUL of a twinned physical system using sensors, communications, modeling, history and computation. It may provide an answer in a time frame that is useful, that is, meaningfully priori to a projected occurrence of a failure event or sub-optimal operation. The information may be provided by a “digital twin” of a twinned physical system. The digital twin may be a computer model that virtually represents the state of an installed product. The digital twin may include a code object with parameters and dimensions of its physical twin's parameters and dimensions that provide measured values, and keeps the values of those parameters and dimensions current by receiving and updating values via outputs from sensors embedded in the physical twin. The digital twin may have respective virtual components that correspond to essentially all physical and operational components of the installed product.

As used herein, references to a “digital twin” should be understood to represent one example of a number of different types of modeling that may be performed in accordance with teachings of this disclosure.

The term “installed product” should be understood to include any sort of mechanically or electronically or chemically or physically operational entity, including, but not limited to, jet engines, locomotives, gas turbines, and wind farms. The term is most usefully applied to large complex systems with many moving parts and numerous sensors installed in the system. The term “installed” includes integration into physical operations such as the use of engines in an aircraft fleet whose operations are dynamically controlled, a locomotive in connection with railroad operations, or apparatus construction in, or as part of, an operating plant building.

As used herein, the term “automatically” may refer to, for example, actions that may be performed with little or no human interaction.

Embodiments provide for minimal set-up time of a development environment for new platform developers.

FIG. 1 is a block diagram of a system 100 provided according to some embodiments. The system 100 may include a plant or “installed product” 102. As noted above, the installed product 102 may be, in various embodiments, a complex mechanical entity such as the production line of a factory, a gas-fired electrical generating plant, a jet engine on an aircraft amongst a fleet, a wind farm, a locomotive, etc. The installed product 102 may include a considerable (or even very large) number of physical elements 104, which for example may include turbine blades, fasteners, rotors, bearings, support members, housings, etc.

The system 100 may include a platform 200 that may host a computer data store 106, a modeling module 108 and other elements 109. The computer data store 106 may provide information to the modeling module 108 and may store results from the modeling module 108. The platform 200 and the modeling module 108 may include one or more processing elements 116. The processor 116 may, for example, be a conventional microprocessor, and may operate to control the overall functioning of the platform 200 and the modeling module 108.

In one or more embodiments, the data store 106 may comprise any combination of one or more of a hard disk drive, RAM (random access memory), ROM (read only memory), flash memory, etc. The data store 106 may store software that programs the processor 116 and the modeling module 108 to perform functionality as described herein. Data in the data store 106 may also include, for example, information about physical elements 104 of the installed product 102, such as historic engine sensor information about a number of different aircraft engines and prior aircraft flights (e.g., external temperatures, exhaust gas temperatures, engine model numbers, takeoff and landing airports, etc.).

The modeling module 108, according to some embodiments, may access the data store 106 and utilize a model creation unit or task module 110 to create an analytic model that may be used to create a prediction and/or result that may be transmitted to at least one of various user platforms 112, back to the installed product 102 or to other systems 114, as appropriate (e.g., for display to a user, operation of the installed product, operation of another system, or input to another system). As used herein, the term “predictive model” and “analytic model” may be used interchangeably.

The modeling module 108 may be programmed with one or more software components that may model individual elements 104 that make up the installed product 102.

A communication channel 118 may be included in the system 100 to supply data from at least one of the installed product 102 and the data store 106 to the modeling module 108.

In some embodiments, the system 100 may also include a communication channel 120 to supply output from one or more models in the modeling module 108 to at least one of user platforms 112, back to the installed product 102, or to other systems 114. In some embodiments, signals received by the user platform 112, installed product 102 and other systems 114 may cause modification in the state or condition or another attribute of one or more physical elements 104 of the installed product 102.

Although not separately shown in the drawing, one or more control units, processors, computers or the like may be included in the installed product 102 to control operation of the installed product 102, with or without input to the control units, etc., from the modeling module 108.

As used herein, devices, including those associated with the system 100 and any other devices described herein, may exchange information via any communication network which may be one or more of a Local Area Network (“LAN”), a Metropolitan Area Network (“MAN”), a Wide Area Network (“WAN”), a proprietary network, a Public Switched Telephone Network (“PSTN”), a Wireless Application Protocol (“WAP”) network, a Bluetooth network, a wireless LAN network, and/or an Internet Protocol (“IP”) network such as the Internet, an intranet, or an extranet. Note that any devices described herein may communicate via one or more such communication networks.

A user may access the system 100 via one of the user platforms 112 (e.g., a personal computer, tablet, or smartphone) to view information about and/or manage an installed product 102 and/or develop models and platforms in accordance with any of the embodiments described herein. According to some embodiments, an interactive graphical display interface may let a platform developer develop a platform and a model developer develop models, define and/or adjust certain parameters and/or provide or receive automatically generated recommendations or results.

Turning to FIG. 2, the high-level architecture (e.g., platform) 200 of the system 100 is provided, in accordance with some embodiments. In some embodiments, the platform 200 may host or include an interface server 202, a core server 204, storage 206, an analytic server 208, and a modeling technique registry 210.

In some embodiments, the interface server 202 may include an authentication/authorization module 212. The authentication/authorization module 212 may be programmed to authenticate at least one of a model developer and platform developer and authorize at least one of the model developer and the platform developer to develop and execute models for the system 100, respectively. In some embodiments, the authentication module 212, in conjunction with application specific access controls, may be used to control both access to the system (authentication) and operations a developer may be allowed to perform within the system (authorization). The interface server 202 may also include an interactive graphical user interface display 214 (e.g., web application) according to some embodiments. The display 214 may include an area 502 (FIG. 5) to develop models, as described herein. In some embodiments, within the platform 200, one or more interface servers 202 may be coupled to, and may provide programmatic or web interfaces 214 to one or more core server(s) 204.

In one or more embodiments, the core server 204 may host one or more applications or modules (e.g., Report Module 216, File Module 218, Task Module 220, and Data Module 222). In some embodiments, the applications or modules may be micro-services. In one or more embodiments, the Report/Record Module 216 may allow specific reports/records to be retrieved from the storage 206.

In one or more embodiments, the Task Module 220 may be a task manager, and may start/stop/get the status of any model-related task. In one or more embodiments, the Task Module 220 may: prepare an input file for analysis; trigger the execution module 232 to run the model; update the task status; parse the model output and register the input and output artifacts with a database.

In one or more embodiments, the Data Module 222 may provide access to various specific persistent storage elements. The core server 204 is, in turn, shown to be coupled to one or more memories/storage 206. In one or more embodiments, the storage 206 may be a persistent storage. In one or more embodiments, the storage 206 may be an external storage element. The storage 206 may include at least one of one or more relational databases (e.g., SQL store) 224, one or more NoSQL or non-relational data stores (e.g., NoSQL stores) 226, and one or more Binary Large OBject (BLOB) Stores 228. In one or more embodiments, the non-relational data store 226 may include one or more data tables that may index model metadata for facilitating searching and accessing via the model. In one or more embodiments, the storage 206 may include an interface 229, which may be used to communicate with an element outside of the platform 200. In some embodiments, the platform 200 may be extended to use storage 206 like Hadoop, Time Series, Triple store, and other suitable storage.

In some embodiments, the analytic server 208 may host an artifact module 230, an execution module 232 and a container module 234.

In some embodiments, the tasks or models developed in the task module 220 may be executed by the execution module 232. In one or more embodiments, this execution may be remote. In some embodiments, the execution module 232 may: execute arbitrary shell commands on a host operating system; invoke a Docker-based model (or any other suitable model) when the shell command is a bash script; be secured with HTTPS client certificate authentication; send execution status updates to the task module 220.

In one or more embodiments, the artifact module 230 may be a distributed service for provisioning, collecting, extracting and the persistence of artifacts required or produced by execution of model tasks. An artifact 1200 (FIG. 12) may be any piece of electronic data that is stored in some sort of file (e.g., text, binary, numbers, logs, a compiled executable, etc.). As shown in FIG. 12, data sources 1202 (e.g., MDAP, Data Lake, User CSVs) as well as model files 1204 (e.g., metrics, logs, input information, models, output information) may have data that may be indexed by the artifact module 230. In one or more embodiments, the model 236 may have information indexed by the artifact module 230 because the co-efficients of the model may be stored elsewhere. In one or more embodiments, as shown in FIG. 13, the artifact module 230 may receive artifacts from the BLOBstore 228, the data module 222, the task module 220, the file module 218 and the modeling technique registry 210, and may transport the artifacts 1200 to any of the BLOBstore 228, the data module 222, the task module 220, the file module 218 and the modeling technique registry 210. In one or more embodiments, the artifact module 230 may: fetch input artifacts 1200 and store them as files on temporary file storage, accessible by the model; upload artifacts 1200 output by the model to the artifact module 230; and run from bash shell scripts invoked by the execution module 232. Prior to execution, the artifact module 230 may provision the necessary artifacts 1200 in a temporary locally accessible path to allow the models 236, and other software, to run the same in a local development environment and a production/execution environment. In one or more embodiments, when the model developer develops a model, the model developer may use locally stored data and other files/artifacts. By providing all necessary data files and other artifacts locally, the Artifact Module 230 may allow the model to execute the same way in the production environment as when it was being developed in the development environment. In some embodiments, when the software completes its task, the Artifact module 230 may also be responsible for collecting the produced artifacts from the temporary workspace (not shown) and persisting them in permanent storage 206.

In some embodiments, the execution module 232 may turn any model (e.g. computational operation or shell command) into a Representational State Transfer (REST) web service. REST web services may refer to an architectural style and communication approach that may be easy to consume by other applications via their web Application Programming Interface (API). In one or more embodiments, turning a model into a web service may be described as publishing the model 236 in the form of a REST end point. The REST end point form may make the model 236 easy to use by other services or applications (e.g., in a cloud environment). In one or more embodiments, the platform 200 may include a log module (not shown) that may store log entries into a triple store when invoked via the REST. In some embodiments, the inputs to the model 236 may be transmitted to the task module 220 from the execution module 232 in order for the technique container to be executed. In some embodiments, the transmission may be asynchronously executed. As used herein in this regard, “asynchronous execution” means that the requesting module is not waiting for the task to be completed by the execution model 232. Instead, in some embodiments, the requesting module sends a request, specifying a call-back end point where the requesting module wants to receive information when there is an update about the status of the task. For example, in some embodiments, the requesting module may effectively say to the execution module “do this task (x) and call me back at the following address (y) when you are done.”

In one or more embodiments, as will be further described below, the execution module 232 may execute at least one task. In one or more embodiments, the model 236 is created by executing a collection of tasks. Some examples of tasks that the execution module may execute are building a model, predictions using a model, estimating missing data, generating space filling designs. Other suitable tasks may be used. In one or more embodiments, the execution module 232 may execute the tasks locally and externally. For example, in some instances, tasks may be local to the execution module 232 and the work may happen locally (e.g., a local small model build or a model prediction), however in other instances the task may require the job to be run elsewhere (e.g., a massively parallel Hadoop instance or a High Performance Computing (HPC) environment like CRAY).

The output (e.g., model as a REST web service) of the execution module 232 may be received by the container module 234 in some embodiments. As used herein, in some embodiments, the “output” may refer to one or more outputs. In some embodiments the container module 234 may wrap each analytic model 236 in a complete filesystem that may contain everything needed to run the model (e.g., code, runtime, system tools, system libraries, and anything that may be installed on a server). In one or more embodiments, the complete filesystem may be referred to as an Application Programming Interface (API) wrapper 201. In one or more embodiments, the analytic model 236 may be formed from one or more component- or sub-models, as described further below. Each of the model and component models may have its own API wrapper 201. The inventors note that containerizing the model may allow the model to run the same, regardless of the environment; and may also allow the components of the model, and the model itself, to run independently such that if one component of the model fails, the whole model does not fail. The inventors further note that containerization may also contribute to resilience toward failures of the underlying infrastructure. For example, if the hardware (physical or virtual) that the container is running on fails while the task is being executed, the system may restart the same container on a different computer node to allow the task to complete. While Docker containers may be described herein, any other suitable containers may be used (e.g., springboot, cloud foundry, Kubernetes, etc.).

In one or more embodiments, when the analytic model is executed (e.g., runtime analytic deployment), a containerized model 236 may be registered and stored in the modeling technique registry 210. In response to deployment, in some embodiments, the modeling technique registry 210 may register the new containerized model 236 on the platform 200.

In one or more embodiments, each element in the platform 200 (e.g., interface server 202, core server 204, storage 206, analytic server 208 and modeling technique registry 210), as well as each sub-element (e.g., authentication/authorization module 212, user interface/web application 214, report module 216, file module 218, task module 220, data module 222, relational databases (e.g., SQL store) 224, NoSQL or non-relational data stores (e.g., NoSQL stores) 226, Binary Large OBject (BLOB) Stores 228, interface 229, artifact module 230, execution module 232, container module 234, and analytic model 236), may also be associated with an API wrapper 201. As for the API wrapper associated with the model 236, each API wrapper 201 associated with each element and sub-element of the platform 200 may define the input information (input, source of input) to the element/sub-element, at least one instruction defining a function of the element/sub-element and the output information (output, destination of output) from the element/sub-element. In one or more embodiments, inputs sources may be any file type (e.g., comma separated, tab separated, binary, etc.), relational databases (e.g., Oracle), non-relational databases (e.g., NoSQL), large data stores (e.g., Hadoop) or streaming sources (e.g., twitter). As such, the API wrapper 201 may allow each element and sub-element in the platform 200 to be “self-aware” and “self-registering.” As used herein, in one or more embodiments, “input” may refer to one or more inputs and “output” may refer to one or more outputs.

In one or more embodiments, the platform element's and sub-element's ability to know the input information 203 (e.g., inputs, the source of the inputs) and the output information 205 (e.g., outputs and the destination of the outputs) via the API wrapper 201 may make the element/sub-element “self-aware.” The inventors note that only the API wrapper 201 in the user interface/web application 214 sub-element and in the model 236 sub-element in FIG. 2 shows the input information 203 and output information 205, to simplify the figures, as all API wrappers 201 may include input information 203 and output information 205.

As used herein, “self-registering” means that the element/sub-element may provide information about its contents, working rules and capabilities via emission of a unique signature (e.g., via the API wrapper 201) to register itself in any system with valid interface and security settings. In one or more embodiments, the API wrapper 201 may define the elements/sub-elements in such a way that they plug themselves into the platform 200 upon completion and may make themselves available for further development activities. A benefit of “self-registering,” is that the element/sub-element may communicate with another element, model, or system, for example, about what information it may need and what information it may provide. In some embodiments, the one or more elements/sub-elements of the platform 200 may communicate with each other via the API wrapper 201, because they include the same API wrapper structure (input, function, output), and the API wrapper structure includes instructions about the destination of the output.

In one or more embodiments, each element and sub-element of the platform 200 may be complete by itself (e.g., may not need to be part of a system). Additionally, in one or more embodiments, each element and sub-element of the platform 200 may not need to be configured to be part of another system. Rather, the API wrapper 201 may allow each element and sub-element to be seamlessly part of another system, as the API wrapper 201 may provide the inputs/outputs for each element/sub-element, thereby providing the structure for a relationship between the elements/sub-elements of different systems.

Turning to FIG. 11, a diagram of an example of the communication between the sub-elements on the platform 308 is provided. Each sub-element 1100 (e.g., authentication/authorization module 212, user interface/web application 214, report module 216, file module 218, task module 220, data module 222, relational databases (e.g., SQL store) 224, NoSQL or non-relational data stores (e.g., NoSQL stores) 226, Binary Large OBject (BLOB) Stores 228, interface 229, artifact module 230, execution module 232, container module 234, and analytic model 236) may be executed independently of each-other, except where they are dependent. For example, the sub-elements 1100 indicated by a dark-dotted link 1102 may be dependent on the fs (file module) sub-element 218. In one or more embodiments, each sub-element 1100 may be configured to run independently or as part of a bigger system. In one or more embodiments, the fact that each sub-element 1100 may be run independently may allow the sub-element to be run on any system or platform with a suitable API interface. For example, the sub-element may seamlessly be run on an execution platform, because the execution platform is written in the same manner as the development platform (e.g., with a same or similar API wrapper structure). In one or more embodiments, the platform 308 may be an execution platform. In one or more embodiments, the sub-elements 1100 may be individual items anchored to the repository 310, and the sub-elements 1100 may be pulled by the artifact module 230, for example, when they are needed in the development of the platform 308. In one or more embodiments, the platform developer may define the development environment variables for orchestrating individual actions.

Turning back to FIG. 3, an integrated development environment 300 is provided. In one or more embodiments the integrated development environment 300 may provide a self-contained complete development system that may provide all the necessary code and components (e.g., databases, message queues, version control, environments, etc.) to platform developers. In some embodiments, the integrated development environment (IDE) 300 may include a system descriptor module 302, an environment profile 304, a run system 306, a platform 308, and a repository 310. In one or more embodiments, the IDE 300 may include the program code for the platform 308, such that there may be no distinction between the IDE 300 and the platform 308.

Conventionally, a development environment is distinct from a platform, whereby the development environment includes modifiable code and the platform includes code for execution but not modification. Conventionally, when a model developer develops a model in the development environment, they have to determine if they are using the latest code that is compatible with a model that will be run on the platform. Then, conventionally, the model developer determines all of the blocks (e.g., compiler, editor, data stores, repositories, linked libraries, static libraries, dependencies), needed to install and run the model in the platform.

In one or more embodiments, some portion or all of the code for the platform (e.g., the code for the platform, components to run the code (e.g., compilers, linkers, packagers), to manage (e.g., editor, timing checks), test and debug the code), as well as the repository 310 may be included in the IDE 300, and may be populated for the model developer when the platform is generated, as described further below. The inventors note that providing all of the elements of the platform in the development environment, development and deployment of models may be much faster because the model developer may just focus on creating the model and may not have to determine the platform specifics and dependencies of platform elements to execute the model. For example, embodiments may provide for a deployment time of models that may be 10 times faster than conventional deployment. The inventors also note that while conventionally it may take 2-6 weeks' time to set up a new model developer with a development environment before they may begin creating or developing the models, embodiments may allow for model developer set-up in about an hour and a half. Embodiments may provide for the seamless and independent integration of developed system elements, as each element is self-aware and self-registering, as described below. Embodiments provide an integrated system for development, testing and deployment. For example, in one or more embodiments, the system may provide all necessary items for the developer to develop the code, test it with standard datasets and test cases and validate their new code and then deploy the code into the platform and test it in the platform. In one or more embodiments, unit testing and regression testing tools may be provided to the developers along with development tools. The inventors also note that including the platform 308 in the IDE 300 may reduce development cost by 2-3 times conventional development/platform costs; may improve productivity by 5-10 times conventional productivity; and may improve software reliability because the developer gets to use standard sets of libraries and compilers and code snippets which are verified and validated by the system rather than each developer using his/her own libraries that may not be compatible with the overall system; and may improve time to delivery and First Time Yield (FTY). As used herein, “FTY” refers to how often the code produced by the developer the first time they write the code turns out to be without any bugs. The inventors note, that it may be desirable to have the FTY as close to 1 as possible to reduce rewrites and bug fixes.

In one or more embodiments, the system descriptor module 302 may define one or more system components (e.g., micro-services) that may be used by a model developer in execution of the model 236 on the platform 308. In one or more embodiments, system components 207 may collectively refer to the modules in the core server 204 and analytic server 208. In one or more embodiments, the system descriptor 302 may define the relations and dependencies between one or more system components 207. In some embodiments, the system descriptor module 302 may also define system component environment variables, a persistent storage mechanism and networking capabilities of the system. In one or more embodiments, the system descriptor module 302 may include the definitions described above prior to a platform developer accessing the IDE 300. The definitions provided in the system descriptor module 302 may define the access a platform developer may have to different aspects of the IDE 300. Conventionally, when developing a platform, a platform developer may need access to the entire IDE 300 to create/view dependencies and relations between system components 207, and determine what information will be tested, etc. Embodiments provide for the system descriptor module 302 to control access to each system component 207, while the IDE 300 may still be running in the background. The inventors note that providing access to changing a software system to any developer comes with inherent security risks for the platform. The ability to limit access to parts of the system with fine-tuned control provided by one or more embodiments is critical to maintain the integrity of the platform and provide enough freedom for the developers to innovate quickly and hence allow the platform to grow.

The environment profile 304 may be completed by the platform developer prior to creation of the platform. In some embodiments, the platform developer may create the environment profile 304 in the particular environment the platform developer wants to develop the platform 308 in. A benefit of this is that platform developers may use their own toolset to develop the platform, without concern for dependency challenges or versioning conflicts. This may allow the developers to use both standard libraries and libraries of their choice inside their containers to speed up, or in some cases enable, their unique applications. Without this, the developers may be dependent on the platform team to provide for all the needs for development, which may not be a sustainable model. In one or more embodiments, the environment profile 304 may concretely specify a profile name, development environment variable values, endpoints/URLs, storage locations, and network proxies. The environment profile 304 may include other suitable information. In one or more embodiments, the environment variable values may include information about a language in which the platform will be written, the number of cores, information about the one or more processors, memory requirements and proxies. In one or more embodiments, the storage locations may be at least one of local locations, cloud locations, databases, data stores, and any other suitable storage location.

In one or more embodiments, the development environment 300 and platform 308 may be written in any computer language preferred by the platform developer. In one or more embodiments, the platform developer may choose to write in the language of their choice but still needs to integrate with the rest of the platform. For example, a developer may choose to write in Python, but then may need to interface with the rest of the platform that is written in JAVA. For example, the development environment 300 and platform 308 may be written in JAVA, Python, C, C++, Matlab, Julia etc. Any other suitable language may be used. In some embodiments, the developer-specification of the language for development environment and platform may also specify the computer language for the model that will be developed by a model developer. In one or more embodiments the platform developer may specify the computer language for the platform 308, as described below with respect to the Run system 306. In one or more embodiments, the system descriptor module 302 may be written in a single language as set by the centralized system owner or product owner.

In one or more embodiments, the repository 310 may contain one or more repository types. In one or more embodiments, the repository may be Git, Subversion, Perforce etc. The inventors note that most developers may generally stick to one type of repository. The repository 310 may include one or more items, as defined by the system descriptor module 302. For example, the one or more items may include compilers, editors and micro-services, executable artifacts, source code to produce executables, and data resources. Other suitable items may be included in the repository 310. In one or more embodiments, the platform developer may not have direct access to the repository, but the platform created by the platform developer may access the elements in the repository during generation thereof.

In one or more embodiments, the run system 306 may be executed via a run command to dynamically generate the platform 308. In one or more embodiments, the platform developer may issue the run command. In one or more embodiments, after the platform developer creates the environment profile 304, the platform developer may execute the run system 306. When executed, the run system 306 may analyze information from the system descriptor module 302 and the environment profile 304 to generate the platform 308; to determine the system components 207 to make available to the developer to develop the model; and to determine the order in which the system components 207 may be made available to the platform developer. In one or more embodiments, the platform developer may set how their components need to be run (specifications) and then the system may use it to run according to the specifications the developer specifies. The inventors note that the platform 308 may be dynamically generated as the platform may be generated based on the data in the system descriptor module 302 and the environment profile 304. For example, different data in the environment profile 304 may result in generation of a different platform 308. In one or more embodiments, the platform 308 may be any platform 308 capable of hosting the system 100. In one or more embodiments, the platform 308 may be one of physical and virtual. In one or more embodiments, the platform 308 may be tested for functionality, for regression testing, automated load balancing or simulated load tests, etc. The platform may be tested for other suitable aspects. The platform 308 may be tested on an Edge device, a host, a cluster, a cloud, and any other suitable device and/or environment.

In one or more embodiments, when executed, the run system 306 may read a structure from the system descriptor module 302 and may populate the structure with values from the environment profile 304. In some embodiments, some examples may include environment variables such as paths, Python modules, NodeJS modules, artifacts from artifact repositories etc.

In one or more embodiments, when executed, the run system 306 may analyze each of the system components 207 to determine if changes have been made to each of the system components 207 since the repository creation and at every step after the developer initiates a build. Every change may be monitored. For example, the analytic developer may require specific libraries to be loaded in a particular sequence or a set of commands to be executed in a specific sequence. In one or more embodiments, the run system 306 may at least one of update or recreate the system component 207 if changes have been made. As used herein “update” means the existing containers are used and they are updated with additional layers, while “recreate” means to build the containers back from scratch. In one or more embodiments, the run system 306 may update the aspect of the system component 207 that changed, without recreating the entire system component 207.

In one or more embodiments, the run system 306 may continue execution after components of the platform 308 are generated on-the-fly as required by the run-time. As such, the run system 306 may start or refresh processes in the platform 308 after the on-the-fly components are generated.

In one or more embodiments, the run system 306 may report the status of the processes and system components 207 being executed in the platform 308. The status may be reported to at least one of the user platform 112 and another system 114.

FIG. 4 illustrates a process of operation 400 that may be performed by some or all of the elements of the system 100 and platform 200 described with respect to FIGS. 1 and 2. Process 400 and other processes described herein may be performed using any suitable combination of hardware (e.g., circuit(s)), software or manual means. For example, a computer-readable storage medium may store thereon instructions that when executed by a machine result in performance according to any of the embodiments described herein. Software embodying these processes may be stored by any non-transitory tangible medium including a fixed disk, a floppy disk, a CD, a DVD, a Flash drive, or a magnetic tape. Examples of these processes will be described below with respect to embodiments of the system, but embodiments are not limited thereto. In one or more embodiments, the system 100 is conditioned to perform the process 400 such that the system is a special-purpose element configured to perform operations not performable by a general-purpose computer or device. The flow charts described herein do not imply a fixed order to the steps and embodiments of the present invention may be practiced in any order that is practicable.

Initially, at S410, a platform 308 may be provided. As described above, the platform may be generated via execution of the run system 306.

Then at S412, one or more elements may be received at the platform 308. The elements may be at least one of the interface server 202, the core server 204, the storage 206, the analytic server 208 and the modeling technique registry 210. Other suitable elements may be included. In one or more embodiments, an “element” may refer to user authentication and access module, technique module, data layer access module, etc. In one or more embodiments, at least one element may include one or more sub-elements. For example, the interface server element 202 may include the authentication/authorization module sub-element 212 and the user interface/web application sub-element 214; the core server element 204 may include the report module sub-element 216, the file module sub-element 218, the task module sub-element 220 and the data module sub-element 222; the storage element 206 may include the relational databases (e.g., SQL store) 224 sub-element, one or more NoSQL or non-relational data stores (e.g., NoSQL stores) sub-elements 226, and one or more Binary Large OBject (BLOB) Stores sub-element 228; the analytic server element 208 may include the artifact module sub-element 230, the execution module sub-element 232, and the container module sub-element 234; and the modeling technique registry element 210 may include the analytic model sub-element 236. As described above, through execution of the run system 306, a determination is made as to which elements may be included in the platform 308.

Then in S414, an API wrapper 201 associated with each of the one or more elements is defined for each of the elements and sub-elements, according to one or more embodiments by a centralized system owner or product owner. In one or more embodiments, the API wrapper 201 may define the input information 203 to the element/sub-element, the function technique performed by the element/sub-element and the output information 205 resulting from execution of the element/sub-element. In one or more embodiments, the API wrapper 201 may define the function of the element/sub-element but is completed with items outside of it (e.g., Hadoop, HPC CRAY etc.)

Then in S416, a self-aware element may be generated. In one or more embodiments, defining the API wrapper 201 may associate it with the element/sub-element, as the API wrapper 201 may reference the element/sub-element by input information, function technique and output information. In some embodiments, defining the API wrapper 201 may generate a self-aware element/sub-element. In one or more embodiments, the element/sub-element's ability to know the input information 203 and output information 205 via the API wrapper may make the element/sub-element “self-aware.”

As an example, an output of the analytic server 208 may be a containerized model 236, which may serve as the input to the modeling technique registry 210. The API wrapper 201 associated with the analytic server 208 may include as the function: generate a containerized model, with output information: output is the containerized model and destination is the modeling technique registry 210. Similarly, the modeling technique registry 210 may include as input information: the input is the containerized model 236 and the source is the analytic server 208.

In one or more embodiments, in S418 the self-aware element/sub-element may then register itself (“self-registering”) with the platform 308. As used herein, “self-registering” means that the self-aware element/sub-element may provide information about its contents, working rules and capabilities via emission of a unique signature (e.g., via the API wrapper 201) to be part of any platform with valid interface and security settings. In one or more embodiments, the technique developer (typically an advanced user) may develop a technique based on their own expertise and then uses the system's API definitions to “wrap” their technique in a system-provided docker container. This may include providing build scripts for building the container for the new analytic and executing the containers. Then, using the interface shown in 900, they set the input and output pages for the technique along with the command required to run the technique. Once the registration is successfully completed and the technique is approved for use, the technique may come up in list of available techniques for any user to build models.

Turning to FIG. 5, a graphical user interface for development of an analytic model 236 that may be generated on the platform 308 is provided according to some embodiments. The user interface 214 may include an area 502 to develop the models. In one or more embodiments, the model 236 may be made from one or more component models (not shown), that together form the model 236. A component model may be an individual model that may work with one or more other component models to form the model. For example, a first component model may be an ingestion model and a second component model may be a data cleaning model. As used herein, the term “model” may refer to either the model 236 or the component models. The model 236 may include equations 504 inserted (e.g., via drag and drop functionality) from an equation library 506, or developed by the model developer without the use of the equation library 506. In developing the model, the model developer may use other suitable libraries 508 (e.g., Usage Based Lifing library, Scipy library, KDL Sparklgraph library, etc.). In one or more embodiments, the libraries 508 may be stored in the repository 310. After the model developer has included the desired equations in the area 502, and linked 501 them as desired, the model developer may select an integrate tab 510 to integrate the equations together to form the model.

As used herein, the model is the action or task to perform with received inputs. For example, a task of a data ingestion model may be to funnel data to a next model; and a task of a data cleaning model may be to clean the input data (e.g., remove noise, determine if any data is missing, check for anomalies).

In one or more embodiments, an API wrapper 201 may be defined for association with the model 236 via execution of the container module 234. For example, FIG. 6 provides the interface 214 for the model developer to define the API wrapper 201. As described above, the API wrapper 201 may store or encode input information 203 (e.g., the input and source of the input) and output information 205 (e.g., output and destination) that may be associated with the model 236. In one or more embodiments, after the model 236 is created, when the model 236 is compiled, the model 236 knows where to pull the inputs from per the API wrapper 201, even if the model developer does not have access to those inputs. In one or more embodiments, the developer may also define co-efficients 604 and constants 606. In one or more embodiments, the developer may link each variable 602 to a data header (not shown) in the code. For example, the developer may include an instruction in the model to write to database X, and the model will get the information from database X during execution of the model, but the developer may not actually see the contents of the database.

In some embodiments, the API wrapper 201 may include standard elements (e.g., input information, modeling technique, output information). In one or more embodiments, the API wrapper 201 may include the modeling technique/the process to create a model. In one or more embodiments, the API wrapper 201 may define the model, but the model may be completed with its elements that are outside the API wrapper 201 (e.g., coefficients and terms). In one or more embodiments, the API wrapper 201 may include other suitable standard elements.

In one or more embodiments, the input and output may be in a JSON format or any other suitable format. The inventors note that while standardized inputs and outputs in any form that may be applicable to programming languages may be used, the use of a JSON format may be beneficial as it is a standard that may be supported by many programming languages and it may allow representation of all required and optional information needed for the running of any model. JSON format may also be flexible by allowing new information to be added without having to change the underlying software. In one or more embodiments, there may be more than one output. In some embodiments, at least one output may be a JSON file, while the other outputs may be other file types. In one or more embodiments, the one JSON output is what the system may expect in order to collect information regarding the outcome of the task. Again due to the generality of the JSON format, different models may include model-specific information in the JSON document. Any markup language may also be used. Many types of outputs (which may be used as inputs in some aspects) may also be generated such as binary formats such as Matlab .mat files, Python pickle files etc. Other suitable formats may be used.

In one or more embodiments, the model's 236 ability to know the input information 203 (inputs, the source of the inputs) and the output information 205 (outputs, the destination of the outputs) via the API wrapper 201 may make the model 236 “self-aware.” In one or more embodiments, metadata 207 for the model 236 may be stored in the model 236 when the model 236 is running. In some embodiments, for the model 236 to be self-aware, the model may also pull metadata 207 from the storage element 206 (e.g., non-relational data stores 226). In some embodiments, since the model 236 knows what its inputs should be and their source, the model 326 may pull the inputs from the sources, as needed.

Conventionally, models may not know what data they will receive or the source of the data, and the models also may not know where the output of the model is going. Rather, conventionally, each time the model is executed, the input, source, and output destination may be specified, which may be time-consuming and error-prone, as a user may not be sure what information to specify. The inventors note that in embodiments, the API wrapper 201 associated with the model 236 defines the input information and output information, facilitating deployment and management of the model 236. In some embodiments, for a model developer to make use of the model 236, the input information 203 and output information 205 may be defined prior to use.

In one or more embodiments, the self-aware model 236 may also be “self-registering”. As used herein, “self-registering” means that the self-aware model 236 may provide information about its contents, working rules and capabilities via emission of a unique signature (e.g., via the API wrapper 201) to register itself in any system with valid interface and security settings. A benefit of “self-registering,” is that the model 236 may communicate with another component, model, or system, for example, about what information it may need and what information it may provide. In some embodiments, the one or more models 236 may communicate with each other via the API wrapper 201, because they include the same API wrapper structure (input, model technique, output), and the API wrapper structure includes instructions about the destination of the output.

In one or more embodiments, the modeling module 108 may, via the analytic server 208, associate the model 236 with the API wrapper 201, as defined by the API wrapper.

In one or more embodiments, an interactive visualization 700 (FIG. 7) of the model 236 may be provided in a user interface. In one or more embodiments, the interactive visualization 700 may be generated after providing the equations 504 and defining the input information 203 and output information 205 (e.g., variables 602), as well as the coefficients 604, and constants 606 (FIG. 6). In one or more embodiments all of the information entered in the equation 504 may be included in the interactive visualization. In one or more embodiments, the model developer may dynamically change the plot 702 to see how the changes affect the results. For example, in one or more embodiments, the model developer may change the co-efficient and constants by dragging them from the variables 602 or entering values. In one or more embodiments, each co-efficient 604 may have an upper and lower bound as text inputs. In one or more embodiment, each constant 606 may have at least one text input. In one or more embodiments, after the model developer is satisfied with the model, per the interactive visualization 700, the model developer may select a “train model” indicator 704. While a button indicator is used to select “train model,” any other suitable indicator may be used. After selection of the “train model” indicator, the system 100 may then train the model (e.g., compute the value of each co-efficient 604).

Turning to FIGS. 8 and 9, a user interface for registering the model/technique 800 and results 900 is provided, respectively. In one or more embodiments, registration of the technique may occur before the model is created so that a model developer may then go choose the technique to build the model. In one or more embodiments, registering the technique may enable any code to be added by a developer (typically an advanced user) may develop a technique based on their own expertise and then may use the system's API definitions to “wrap” their technique in a provided docker container. In one or more embodiments, this may include providing build scripts for building the container for the new analytic and executing the containers. Then, using the interface shown in 900, the technique developer may set the input and output pages for the technique along with the command required to run the technique. Once the registration is successfully completed and the technique is approved for use, the technique may come up in list of available techniques for any user to build models.

After the technique 800 is registered, the model developer may also register a results template 902 to provide a structure for the results of execution of the model technique. For example, the template 902 may include one or more fields 904 that may be populated with information. As shown in FIG. 9, for example, the fields 904 may include a label for the results, a description, a plot title, a chart type, a mode, a data source, an indication if the data source an array, an indication if an array item is an object, an X value accessor a y-value accessor, and a display width. In one or more embodiments the information to populate the fields may be selected from at least one of drop-down menus (e.g., chart type, mode, data source, display width), user-entry fields (e.g., label, description, plot title), selection of boxes or radio buttons (data source is array, array item is object), and selectable from another source (e.g., X value accessor, y value accessor). In one or more embodiments, the results template 902 may include a preview of the output 906 of the model technique.

Note the embodiments described herein may be implemented using any number of different hardware configurations. For example, FIG. 10 illustrates an analytic development and processing platform 1000 that may be, for example, associated with the systems 100, 200 of FIGS. 1 and 2, respectively. The analytic development and processing platform 1000 comprises an analytic and development processor 1010 (“processor”), such as one or more commercially available Central Processing Units (CPUs) in the form of one-chip microprocessors, coupled to a communication device 1020 configured to communicate via a communication network (not shown in FIG. 10). The communication device 1020 may be used to communicate, for example, with one or more users. The analytic development and processing platform 1000 further includes an input device 1040 (e.g., a mouse and/or keyboard to enter information about the installed product or the model) and an output device 1050 (e.g., to output and display the data and/or recommendations).

The processor 1010 also communicates with a memory/storage device 1030. The storage device 1030 may comprise any appropriate information storage device, including combinations of magnetic storage devices (e.g., a hard disk drive), optical storage devices, mobile telephones, and/or semiconductor memory devices. The storage device 1030 may store a program 1012 and/or analytic development and processing logic 1014 for controlling the processor 1010. The processor 1010 performs instructions of the programs 1012, 1014, and thereby operates in accordance with any of the embodiments described herein. For example, the processor 1010 may receive a component model and then may apply the modeling module 108 via the instructions of the programs 1012, 1014 to generate an analytic model 236.

The programs 1012, 1014 may be stored in a compressed, compiled and/or encrypted format. The programs 1012, 1014 may furthermore include other program elements, such as an operating system, a database management system, and/or device drivers used by the processor 1010 to interface with peripheral devices.

As used herein, information may be “received” by or “transmitted” to, for example: (i) the platform 1000 from another device; or (ii) a software application or module within the platform 1000 from another software application, module, or any other source.

As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

It should be noted that any of the methods described herein can include an additional step of providing a system comprising distinct software modules embodied on a computer readable storage medium; the modules can include, for example, any or all of the elements depicted in the block diagrams and/or described herein; by way of example and not limitation, a modeling module. The method steps can then be carried out using the distinct software modules and/or sub-modules of the system, as described above, executing on one or more hardware processors 1010 (FIG. 10). Further, a computer program product can include a computer-readable storage medium with code adapted to be implemented to carry out one or more method steps described herein, including the provision of the system with the distinct software modules.

This written description uses examples to disclose the invention, including the preferred embodiments, and also to enable any person skilled in the art to practice the invention, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the invention is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements with insubstantial differences from the literal languages of the claims. Aspects from the various embodiments described, as well as other known equivalents for each such aspects, can be mixed and matched by one of ordinary skill in the art to construct additional embodiments and techniques in accordance with principles of this application.

Those in the art will appreciate that various adaptations and modifications of the above-described embodiments can be configured without departing from the scope and spirit of the claims. Therefore, it is to be understood that the claims may be practiced other than as specifically described herein.

Claims

1. A system for creating an application programming interface (api) wrapper which allows each element and sub-element of a platform to be part of another system without specifically configuring each element and sub-element for the another system comprising:

the platform hosting one or more elements;

an application programming interface (api) wrapper associated with each of the one or more elements of the platform, the api wrapper including input information to the one or more elements, output information to the one or more elements, and at least one instruction defining a function of the element;

wherein the one or more elements and the api wrapper form a self-aware element wherein the self-aware element knows the input information and the output information per the api wrapper; wherein at least one element includes one or more sub-elements;

wherein the one or more elements are self-registering via the api wrapper to register itself in the another system of the platform;

wherein the one or more sub-elements include an analytic model for an installed product;

wherein the analytic model makes predictions of the installed product; and

wherein the api wrapper includes a modeling technique to create the analytic model;

the api wrapper allows the self-aware and self-registering elements of the analytic model to be part of the another system on the platform.

2. The system of claim 1, wherein the one or more elements include at least one of an interface server, a core server, a storage, an analytic server and a modeling technique registry.

3. The system of claim 1, wherein the one or more sub-elements include an authentication/authorization module, a user interface/web application, a report module, a file module, a task module, a data module, an artifact module, an execution module, and a container module.

4. The system of claim 1, wherein information about the one or more inputs to the one or more elements further comprises:

at least one source of the one or more inputs.

5. The system of claim 1, wherein information about the one or more inputs to the component model includes a definition of the input.

6. The system of claim 1, wherein each of the one or more elements is self-registering.

7. The system of claim 6, wherein the self-registering element provides information about its contents, working rules and capabilities via emission of a unique signature to register itself in a system with valid interface and security settings.

8. The system of claim 1, wherein a first element of the platform communicates with a second element of the platform via the api wrapper.

9. The system of claim 8, wherein the communication between the first element and the second element further comprises:

receiving at the first element the output from execution of the function of the second element.

10. The system of claim 1, wherein each element is operative to: receive the one or more inputs from one or more sources; execute a function associated with the element to generate one or more outputs; and transmit the one or more outputs to at least one destination.

11. The system of claim 1, wherein metadata for the component is stored in the component when the component is running.

12. The system of claim 1, wherein the input information includes a relational databases, non-relational databases, and large data stores.

13. A method for creating an application programming interface (api) wrapper which allows each element and sub-element of a platform to be part of another system without specifically configuring the another system comprising:

providing the platform;

receiving one or more elements at the platform;

defining an api wrapper associated with each of the one or more elements of the platform, the definition including input information for the element, output information of the element and at least one instruction defining a function associated with the element;

generating a self-aware element based on the api wrapper, wherein the self-aware element knows the input information and the output information per the api wrapper; wherein the at least one element includes one or more sub-elements;

wherein the one or more elements are self-registering via the api wrapper to register itself in the another system of the platform;

wherein the one or more sub-elements include an analytic model for an installed product;

wherein the analytic model makes predictions of the installed product; and

wherein the api wrapper includes a modeling technique to create the analytic model, wherein the api wrapper allows the self-aware and self-registering elements of the analytic model to be part of the another system on the platform.

14. The method of claim 13, further comprising:

executing, via a computer processor, the function of the self-aware element; and

generating an output of the function.

15. The method of claim 14, further comprising:

receiving at the first self-registered element the output from execution of the function of the second self-registered element.

16. The method of claim 15, wherein the output is defined by the api wrapper.

17. The method of claim 13, wherein each element is self-registering.

18. The method of claim 17, wherein a first self-registered element is operative to communicate with one or more second self-registered elements via the api wrapper.

19. The method of claim 13, further comprising: registering each element with the platform.

20. The method of claim 13, further comprising: defining the input.

21. The method of claim 13, wherein the one or more elements include at least one of an interface server, a core server, a storage, an analytic server and a modeling technique registry.

22. The method of claim 13, wherein the one or more sub-elements include an authentication/authorization module, a user interface/web application, a report module, a file module, a task module, a data module, an artifact module, an execution module, and a container module.