Patent Description:
Data creation and consumption has been increasing at prolific rates. In particular, annual data creation increased from <NUM> zettabytes (trillion gigabytes) to an estimated <NUM> zettabytes from <NUM> to <NUM>. Data is expected to proliferate at ever increasing rates due in part to increased accessibility to data and computing applications and the rise of remote work. In <NUM>, an estimated <NUM> zettabytes of data is projected to be created. This Gargantuan increase in data creation, along with a concurrent increase in complexity of data, is a catalyst that has brought about new complexities and requirements in performing computing tasks that involve processing such data. In particular, the rise in the amount and complexities of data has resulted in the practice of running multiple applications or modules concurrently in order to extract, transform, analyze, maintain, store, validate, and/or propagate the data to another source or destination. Frameworks used to support such computing tasks need to be adapted to the status quo of today's data environment in order to address and eliminate bottlenecks in performance of computing tasks.

<CIT> discloses performing computations on data at an intelligent data pipe en route to a data store. A catalog manager (which stores schemas for describing the data that is handled by the processing container) ensures that each pipeline process uses the right metadata and assists a processing controller in identifying appropriate pipelines for given input data. When the data is made available, for example when a notification of new data is received or when incoming data arrives on an open data stream, the processing elements comes to life and process the data. After processing completes the pipeline processes are turned off.

Various embodiments of the present disclosure can include computing systems, methods, and computer programs configured to execute instructions that, when executed by one or more processors, cause a computing system to execute an application framework to provision or configure a set of computing tasks that involve applications or modules. Logic and/or constructs of the application framework may be stored on a server, for example, such as a cloud server. The provisioning includes determining or receiving an indication of the applications to be installed into a pipeline, workspace, or other collaborative framework or setting, and receiving contextual information of each of the applications. The contextual information includes one or more data objects, data types, data formats, and/or other data attributes supported or used by, relied upon, or compatible with each of the applications, and one or more relationships among the applications.

The instructions cause the computing system to provision or configure one or more of the applications based on the indication of the applications to be installed and the contextual information. The instructions cause the computing system to receive an indication of an update at a first application of the applications. In some embodiments, if applicable, the instructions may cause the computing system to cache the update at a cache associated with the computing system. The instructions cause the computing system to propagate the update to any appropriate applications based on the contextual information. This may serve to ensure correct and reliable performance of applications which are updated in addition to the first application of the application, whilst potentially also avoiding updating applications where not necessary based on the contextual information, which would incur additional processing and communication costs.

In some embodiments, the update is indicative of a change in a subset of data in the first application or a completion of a task in the first application.

In some embodiments, the one or more relationships comprise a reliance of a second application upon an output of the first application; and the propagating of the update comprises determining a generation of a data output from the first application; and in response to the determination of the generation of the data output, ingesting the data output into the second application.

In some embodiments, the instructions further cause the system to: in response to receiving the indication of the update at the first application, caching the update at a cache; and the propagation of the update comprises propagating the update directly from the cache.

In some embodiments, the instructions further cause the system to: receive an indication of a second update externally from the applications, the second update comprising a modification in a data format, a data object, or a data type of data that is ingested into the first application or a second application; determine that the second update causes the modified data format, the modified data object, or the modified data type to be incompatible with an accepted input of the first application or the second application; determine one or more updated applications that are compatible with the modified data format, the modified data object, or the modified data type; and replace the incompatible first application or the incompatible second application based on the determined one or more updated applications.

The instructions further cause the system to: adjust running statuses of the applications if an amount of available computing resources on a computing device on which the applications run can maintain the respective running statuses of the applications, the running statuses comprising an operational state, a paused state that consumes less computing resources compared to the operational state, and an inactive state that consumes less computing resources compared to the paused state, the adjusting of the running statuses comprising determining a number of the applications to be in an operational state.

In some embodiments, the adjusting of the running statuses comprises determining particular applications to convert to the operational state based on frequencies at which the applications ingest data.

In some embodiments, the applications within the pipeline or the workspace collaboratively determine an actuation to be performed on a physical component.

In some embodiments, the determination or receiving of the contextual information of each of the applications comprises determining the relationships based on comparisons between second data objects, second data formats, or second data types generated as outputs by the respective applications and the data objects, data types, or data formats supported by the applications. For example, upon receiving an indication of or determining a data type, a data object, or a data format to be ingested, the computing system may determine any applications to which the data type, the data object, or the data format may be ingested and/or are compatible. Such information may be stored within a database associated within the computing system, such as a registry. These applications may also be relevant to a computing task being performed, determined based on respective types of the applications. The computing system may then either determine a particular application or receive a selection of such. The computing system may then determine a second data object, second data format, or a second data type generated as one or more outputs by the particular application, and one or more other applications that are compatible with, or may successfully ingest data of or consistent with the second data object, the second data format, or the second data type. The computing system may then either determine a particular other application or receive a selection of such. The computing system may repeat such a process for all subsequent applications. Additionally, the computing system may determine a final data type, a final data object, or a final data format that is to be generated as an end result by the workspace and pipeline and determine or verify, at each stage, that data outputs generated may be converted or transformed, either directly or indirectly, to the final data type, the final data object, or the final data format.

In some embodiments, the contextual information further comprises ranges of values of data or ranges of times at which data was captured.

These and other features of the computing systems, methods, and non-computer programs disclosed herein, as well as the methods of operation and functions of the related elements of structure and the combination of parts and economies of manufacture, will become more apparent upon consideration of the following description and the appended claims with reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals designate corresponding parts in the various figures. It is to be expressly understood, however, that the drawings are for purposes of illustration and description only and are not intended as a definition of the limits of the invention.

Certain features of various embodiments of the present technology are set forth with particularity in the appended claims. A better understanding of the features and advantages of the technology will be obtained by reference to the following detailed description that sets forth illustrative embodiments, in which the principles of the invention are utilized, and the accompanying drawings of which:.

Conventional approaches of performing computing tasks, such as executing a data pipeline or configuring a workspace, that require multiple applications or modules may be limited due to shortcomings in collaboration and synchronization among the multiple applications. Typically, configuring or provisioning each individual application may entail running a separate system, platform, microservice, service, or product. Each application may run independently, without awareness of context of other applications or changes to relevant data. For example, if data is being updated in a first application, a separate process or a user may detect the update and determine whether the data or a subset thereof is compatible with and ingestible into a second application. Next, a separate process or a user may ingest the update of the data or the subset thereof into the second application. Such a lack of awareness may hinder flexibility or adaptability due to updates, for example, in the data, in protocols or mechanisms in which the applications operate, or in relationships among the applications. Additionally, such a modularized framework may cause delays in setting up separate platforms, ingesting data separately into each application, and individually updating data in each application, all of which hinder performance of the applications and of the computing tasks that rely on the applications. Inefficiencies in these conventional approaches are manifested in consumption of computing power and time. Additionally, these conventional approaches are unreliable and may fail because the applications may not receive updates in data or operations due to lack of synchronization with other applications. This inability of synchronization and collaboration of the multiple applications reduces efficiency and effectiveness, and may result in failure in performance of computing tasks and further hampers convenience. For example, a downstream application of a first application may not be updated in such a way that data for a mission-critical task, e.g. controlling machinery, or implementing database access, is not correctly received.

To address these shortcomings and to improve an efficiency and user convenience of performing computing tasks, as well as to avoid failures, a new approach includes, executing an application framework to configure or provision a computing task or set of computing tasks that involve applications or modules. Each of the applications within the data pipeline or within the workspace collaborates with and is synchronized with the other applications. In this approach, the application framework may be embedded or otherwise provided within a computing system, which may include a server, such as a cloud server.

Logic and/or constructs of the application framework may be stored on the server. The provisioning may include determining or receiving an indication of the applications to be installed into a pipeline or workspace, and receiving contextual information of each of the applications. The indication of the applications may be generated or derived by the logic associated with the application framework. For example, upon receiving an indication of a computing task or a type of computing task from a user or from a computing device, the logic may automatically generate or derive the applications pertaining to or relevant to that computing task or type of computing task. In some embodiments, the user may be an administrator. The logic may receive further feedback from a user regarding a subset (e.g., any or all of) of the generated applications to be selected in this particular task. In other examples, the logic may receive an indication or selection of applications from a user or from a computing device. Subsequently, the logic may receive or derive contextual information of each of the applications. The contextual information may include one or more data objects, data types, data formats, and/or data attributes supported or used by, or compatible with each of the applications, and one or more relationships among each of the applications. For example, the logic may receive such contextual information from a user or a computing device. Additionally or alternatively, the logic may access a storage associated with the computing system, such as a database that stores such contextual information and extract the contextual information. The contextual information may have been previously recorded in the database. The data objects, data types, data formats, and/or data attributes supported by each of the applications may be indicated as acceptable inputs to each of the applications. The relationships among each of the applications may indicate an upstream or downstream relationship among applications. For example, if an output from a first application is intended to be inputted into a second application, a relationship may indicate that the second application receives data immediately or directly from the first application, and that the second application is immediately downstream of the first application. Therefore, any data or procedure updates at the first application would be instantaneously and selectively propagated to the second application, without being propagated to other applications that are incompatible with data objects, data types, data formats, and/or data attributes of the first application, and/or are not immediately downstream of the first application. Such a mechanism would ensure that data received by a second application is indeed relied upon, utilized, supported by, and/or relevant to the second application and will not cause problems, e.g. failures, due to the data received by the second application being erroneous and/or incompatible. This also avoids unnecessary processing tasks to provide data or procedure updates at the one or more other applications that are incompatible and/or not immediately downstream of the first application. This saves on processing and/or communications costs.

The logic may provision or configure one or more of the applications based on the indication of the applications to be installed and the contextual information. For example, based on the relationships, the logic may generate and/or configure an application programming interface (API), a plugin, and/or implement some other functionality so that an immediate upstream application may communicate with a downstream application. In one implementation, the logic may receive an indication that an upstream application has completed its computing task, or has updated a parameter, and transmit the output or the update from the upstream application to a downstream application. As another example, the logic may receive an indication of an ingestion of data or a modification of existing data. The ingested data or the modified data may be received externally, meaning from a source external to the applications, for example. The logic may selectively propagate the ingested data or the modification to any applications that support data objects, data formats, data types, and/or data attributes consistent with the ingested data or the modified data, without propagating the ingested data or the modified data to other applications that fail to support data objects, data formats, data types, and/or data attributes consistent with the ingested data or the modified data. In particular, the logic may receive an indication of an update at an application of the applications. The update may include an update of data or an update of functionality or a protocol associated with the application. For example, an updated protocol of an application may include an additional step of converting or transforming data from a first format to a second format, whereas previously, the application did not include such a transformation step. The logic may redetermine, based on the transformation of the data to the second format, whether the previously indicated or determined downstream applications still support data of the second format, and/or additional applications that previously did not support data of the first format but support data of the second format. The logic may then propagate the transformed data to the additional applications, but terminate the propagation of the transformed data to the previously indicated or determined downstream applications that support the first format but fail to support the second format. As another example, the update may include a modification of data. The modification of data may be cached at a cache associated with the application framework. Every time a cache is updated, the updates may be propagated to relevant applications, such as, applications that support data objects, data formats, data types, and/or data attributes consistent with the modified data.

The provisioning or configuring of the applications may further include setting access control restrictions or policies of each of the applications. In some embodiments, the access control restrictions or policies may indicate which users, such as non-administrative users have privileges to deploy particular applications and/or particular components or capabilities of the applications. For example, certain users may have access control privileges to deploy the applications or a subset thereof, while other users may only have access control privileges to view data generated by the applications or a subset thereof. Yet other users may have access control privileges to view underlying data, and/or protocols, constructs, or code relied upon by the applications or a subset thereof. In some embodiments, access controls may be provided to users via two mechanisms, a link to access a workspace in which the applications reside or particular applications within the workspace, or blanket access, or selective access, to the workspace. In the former mechanism, a particular user that requires a link to access the workspace would be unable to access the workspace or applications within the workspace without having the link, or if the link has been deactivated or expired. Additionally, users that have access control privileges in different workspaces may switch among the different workspaces. Furthermore, users that have access control privileges to read and/or write in different workspaces may initiate requests to transmit data among the different workspaces, subject to approval across different organizations, groups, or categories of users. As a particular illustrative example, a user of a first organization may write in or modify an existing workspace, and/or create a new workspace, that may be accessible to or deployed by users in a second organization. However, the newly written or modified data, and/or the new workspace, may require approval by the second organization, such as an administrator of the second organization, prior to being populated to the second organization.

The logic may further control collaboration among different users within a workspace depending on their respective access control privileges. For example, two users that both have access control privileges to read and/or write to a particular workspace, may simultaneously perform operations and/or deploy applications within that workspace. If two users simultaneously perform operations that conflict, such as, indicating an ingestion of data into an application from two different and/or conflicting sources, the logic may either indicate such a conflict and terminate further downstream operations until the conflict is resolved or determine which operation takes precedence based on respective roles and/or priorities of the two users. For example, if a first user has a higher priority than a second user, then the logic may persist or execute the operation of the first user rather than the second user.

This new approach obviates the need to open or configure separate frameworks for each application utilized during a computing task. Furthermore, by improving the synchronization and collaboration among different applications, this new approach greatly enhances reliability of computing tasks and reduces delays. Additional benefits of running multiple applications that are synchronized within a single framework include reduction in physical infrastructure requirements such as hardware and conservation of computing resources without interference among applications.

<FIG> illustrates an example environment <NUM>, in accordance with various embodiments, of a computing system <NUM>, that implements or executes an application framework <NUM>. The example environment <NUM> of <FIG> may be applicable to subsequent <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, and <FIG>. The application framework <NUM> may include constructs, programs, instructions and/or protocols that configure or provision applications or modules to perform a computing task or computing tasks within a workspace, a platform, or a pipeline. The application framework <NUM> may be embedded or associated with logic <NUM>. Thus, the application framework <NUM> may constitute part of the logic <NUM>. In some embodiments, following execution of the application framework <NUM>, applications or modules that perform a computing task or computing tasks may be generated or populated within a collaborative platform, pipeline, or workspace. In some embodiments, a database <NUM> may store or cache information of, or associated with each of the applications or modules, and/or updates or modifications to, or associated with each of the applications or modules. In some embodiments, the computing system <NUM> may include physical or cloud computing resources or servers. Besides the application framework <NUM> and/or the logic <NUM>, no additional coding may be required to provision the applications or modules.

The example environment <NUM> can include at least the computing system <NUM> and at least one computing device <NUM>. The computing system <NUM> and the computing device <NUM> can each include one or more processors and memory. The processors can be configured to perform various operations by interpreting machine-readable instructions, for example, from a machine-readable storage media <NUM>, which may store the instructions to be transmitted to, interpreted by, and executed by the logic <NUM>. The processors can include one or more hardware processors <NUM> of the computing system <NUM> that include the logic <NUM> which can be configured to implement or execute the application framework <NUM>.

In general, an entity or a user operating the computing device <NUM> can interact with the computing system <NUM> over a network <NUM>, for example, through one or more graphical user interfaces and/or application programming interfaces. In some embodiments, the computing device <NUM>, or a user operating the computing device <NUM>, may provide input or feedback regarding particular applications <NUM>, <NUM>, <NUM>, and <NUM>, which may constitute part of a platform, workspace, or a pipeline (hereinafter "workspace") <NUM>. In some embodiments, workspaces may be switched between based on feedback or input from a user. The applications <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> may perform any of data processing, analysis, monitoring, alerting, generating, extracting, transforming, maintaining, storing, validating, and/or propagating.

The workspace <NUM> may be implemented or operated on the computing device <NUM> and/or a different computing device. The input or feedback may include data objects, data formats, data types, and/or other data attributes supported by each of the particular applications <NUM>, <NUM>, <NUM>, and <NUM>, and/or relationships among the particular applications <NUM>, <NUM>, <NUM>, and <NUM>. The data attributes may include, for example, a range of times at which data was obtained, a range of data values, and/or an amount of data of a particular object, format, or type that may be ingested by an application. Such input or feedback may be stored or cached within the database <NUM>.

The environment <NUM> may also include one or more data stores <NUM> accessible to the computing system <NUM>. The data stores <NUM> may be accessible to the computing system <NUM> either directly or over the network <NUM>. In some embodiments, the data stores <NUM> may store data that may be accessed by the logic <NUM> to provide the various features described herein. For example, the data stores <NUM> may store instructions of, or within, various constructs embodied in the application framework <NUM> and/or are otherwise incorporated within the logic <NUM>. In some instances, the data stores <NUM> may include federated data stores, databases, or any other type of data source from which data may be stored and retrieved, for example.

The computing system <NUM> may further be associated with a cache <NUM>, which caches a subset of objects stored in the first database <NUM>. In some embodiments, the cache <NUM> may cache any data and/or updates, for example, to data, that are to be propagated to selected other applications. In some embodiments, the cache <NUM> may cache data objects on a basis of a frequency of updating and/or a frequency of access. Thus, the cache <NUM> may selectively cache data objects that are most frequently updated and/or accessed.

<FIG> illustrates an example implementation of a resulting execution of an application framework such as the application framework <NUM>. The logic <NUM> may receive an indication of particular applications to be provisioned, or a particular computing task and determine which particular applications to be provisioned. As an example, the logic <NUM> may receive an indication from a user on the computing device <NUM> that a driving or a navigation task is to be performed. The logic <NUM> may determine particular applications that are utilized in, or pertain to, such a task. The logic <NUM> may receive a further input or indication regarding a subset (e.g., any or all) of the particular applications that are to be provisioned. Alternatively, the logic <NUM> may receive an indication of the particular applications that are to be provisioned. Although the examples described below focus on a driving or navigation example, the examples are merely to illustrate the principles of executing an application framework and how the applications are synchronized. The implementation is not construed as being limited to a driving or navigation example, but rather, can be directed to any fields that entail data processing and/or analysis, including mission-critical tasks relating to data security, network security and/or operating machinery or plant or vehicles. In <FIG>, the logic <NUM> may provision applications <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> within a single workspace or platform so they are running in an integrated fashion. Six applications are illustrated for the sake of simplicity, but additional applications may also be provisioned. The logic <NUM> may receive or determine contextual information of each of the applications <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>. The contextual information may include, as previously alluded to, one or more data objects, data types, data formats, and/or data attributes supported or used by, or compatible with each of the applications <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>, and one or more relationships among each of the applications <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>.

In particular, the application <NUM> may process LiDAR data <NUM> which has a timestamp <NUM>. The application <NUM> may process inertial measurement unit (IMU) data <NUM> which has a timestamp <NUM>. The application <NUM> may process Global Positioning System (GPS) data which has a timestamp <NUM>. Outputs from the applications <NUM>, <NUM>, and <NUM> may be ingested into the application <NUM>, which performs localization and/or mapping to determine a current location and map of surroundings. The application <NUM> may generate a map <NUM> having a timestamp <NUM>. Outputs from the application <NUM> may be ingested into the applications <NUM> and <NUM>. The application <NUM> may determine actions to be performed on brake and gas pedals by generating brake and gas pedal data <NUM>, such as an amount of acceleration or braking, converted into a numeric amount of force. Meanwhile, the application <NUM> may determine actions to be performed on a steering wheel by generating steering wheel data <NUM>, as indicated by a numeric angle of rotation and/or an orientation of the steering wheel, which may be represented as a numeric valve from <NUM> to <NUM> degrees in the steering wheel data <NUM>. Thus, in <FIG>, the applications <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> collaboratively determine an actuation to be performed on one or more physical components, in this case mission-critical parts of a vehicle. The determined actuation may be transmitted to a corresponding actuator or another computing resource or system to perform the actuation.

The contextual information may indicate that the application <NUM> accepts or ingests (i.e., is compatible with or supports) a data type or data object of a raw point cloud and outputs data of a processed point cloud data type or data object, such as a raster. The contextual information may indicate that the application <NUM> ingests a data type or data object of a time series and outputs a numeric data type or a vector data object. The contextual information may indicate that the application <NUM> ingests a data type or data object of GPS data and outputs a coordinate data type or a matrix data type. The contextual information may indicate that the application <NUM> may ingest data types or data objects of a raster, a numeric type or a vector object, and a coordinate data type or a matrix data object. The application <NUM> may output data types or data objects of a map, and a coordinate data type or a matrix data object indicative of a location. The contextual information may indicate that the applications <NUM> and <NUM> may each ingest data types or data objects of a coordinate or a data object of a matrix, indicative of a location. The applications <NUM> and <NUM> may each output a numeric data type or a scalar data object. Although only the applications <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> are illustrated, the logic <NUM> may obtain such contextual information for any applications, including applications that are unrelated to such a computing task of navigation and driving. Such unrelated applications may be in an inactive status because they are unlikely to be used.

From the contextual information of which data types, data objects, data formats, and/or data attributes are supported by and/or compatible with each of the applications <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>, the logic <NUM> may determine either a sequential relationship among the applications, such as an upstream and downstream relationship among the applications. In particular, the logic <NUM> may determine that the application <NUM> is immediately downstream of the applications <NUM>, <NUM>, and <NUM>, because the application <NUM> is compatible with and supports the data types, data objects, and/or data formats outputted by each of the applications <NUM>, <NUM>, and <NUM>. Likewise, the logic <NUM> may determine that the applications <NUM> and <NUM> are immediately downstream of the application <NUM> because the applications <NUM> and <NUM> are each compatible with and support the data types, data objects, and/or data formats outputted by the application <NUM>. In some alternative embodiments, the logic <NUM> may directly receive information of the sequential relationship from a user operating the computing device <NUM> and validate the sequential relationship by confirming that each immediate downstream application does support or is compatible with the data types, data objects, and/or data formats outputted by an upstream application. In some embodiments, the logic <NUM> may determine, step-by-step, particular applications that are compatible with and support the data types, data objects, and/or data formats outputted by an upstream application, for example, via a lookup of a registry that indicates such information. The registry may be stored within the database <NUM>. The logic <NUM> may then receive a selection of a subset of the particular applications from a user operating the computing device <NUM>. For example, the logic <NUM> may determine all, or multiple, applications that are each compatible with and support the data types, data objects, and/or data formats outputted by each the applications <NUM>, <NUM>, and <NUM>, and receive a selection of one or more applications from the user, such as a selection of the application <NUM>. This process may be repeated at every stage, such as at the output of the application <NUM>, the logic may determine any applications that are compatible with and support the data types, data objects, and/or data formats outputted by the application <NUM>. By determining or resolving sequential relationships between applications, the logic <NUM> efficiently and selectively propagates updates to relevant applications, as will be illustrated in <FIG> and <FIG>. These updates include updates to data and/or modifications to the applications themselves.

<FIG> illustrates an implementation in which the logic <NUM> detects or receives a notification of updated data and propagates the updates to a downstream application. In some embodiments, the updated data may be originated from a source external to the applications <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>. In particular, the updated data may include updated LiDAR data <NUM> having an updated timestamp <NUM>, updated IMU data <NUM> having a timestamp <NUM>, and updated GPS data <NUM> having a timestamp <NUM>. The logic <NUM> may determine which applications are compatible with and support the data objects, data types, and/or data formats consistent with the updated data and/or which particular applications have been selected to receive such updated data. In the implementation of <FIG>, the application <NUM> may be determined to be compatible with and support the data objects, data types, and/or data formats consistent with the updated data, and/or selected to receive such the data objects, data types, and/or data formats. The logic <NUM> may further determine to refrain from, or not propagate the data updates to, other applications that are incompatible with and fail to support the data objects, data types, and/or data formats consistent with the updated data, such as the applications <NUM> and <NUM>, which do not support data types or data objects of a processed point cloud, or a numeric data type or a vector data object. Here, although the applications <NUM> and <NUM> may support an output data type or data format from the application <NUM>, which is of a coordinate data type or a matrix data type, the logic <NUM> may determine that the applications <NUM> and <NUM> are not immediately downstream of the application <NUM> and are not to directly receive data updates from the application <NUM>. Rather, the data updates from the application <NUM> may require additional processing or transformation prior to being ingested into the applications <NUM> and <NUM>. This ensures correct operation of the applications <NUM>, <NUM> and their associated components, namely the brakes and steering. This also avoids unnecessary updates thereby saving computational resources. Therefore, the logic <NUM> may determine which applications data updates should be selectively propagated to not only on the basis of compatibility of data types, data objects, and data formats but also based on the sequential relationships among the applications, such as which applications actually rely upon the data updates. For example, outputs from the application <NUM> may include unprocessed data object types, whereas the applications <NUM> and <NUM> require ingestion of processed data object types. In such a manner, applications that do not support or are incompatible with a particular data format, data object, or data type, would not receive any such data formats, data objects, or data types, and any updates are selectively propagated to relevant applications.

Additionally, the process of propagating data updates may include storing the updated data <NUM>, <NUM>, and <NUM> at the database <NUM> and/or caching the updated data <NUM>, <NUM>, and <NUM> at the cache <NUM>. The logic <NUM> may then transmit the stored updated data or the cached updated data to the appropriate downstream application, here, the application <NUM>. The logic <NUM> may hide a direct source of the updated data from the application <NUM>, that is, the logic <NUM> may not reveal that the computing system <NUM> has stored or cached the updated data prior to propagation to the application <NUM>, so that the application <NUM> is unaware that the propagated data is from the database <NUM> or the cache <NUM>.

In some embodiments, if two or more updates occur simultaneously and/or substantially simultaneously in that they have same timestamps or timestamps within a threshold duration of one another, the logic <NUM> may indicate such an occurrence and require or prompt a user to provide feedback regarding which update takes precedence. In other embodiments, the logic <NUM> may automatically persist or select an update that takes precedence based on respective sources of the updates. For example, if a first source provides an update substantially at a same time as a second source, but the first source has a higher priority or trustworthiness compared to the second source, then the logic <NUM> may select the update provided by the first source as taking precedence over the update provided by the second source.

<FIG> illustrates an implementation in which the logic <NUM> detects or receives a notification of updated data and accordingly updates sequential relationships among the applications. For example, if a format of the raw LiDAR data received by the application <NUM> was previously in a first file format such as a LAS file format <NUM>, which is one of the file formats supported by the application <NUM>, but the file format of the raw LiDAR data has changed to a second file format such as an American Standard Code for Information Interchange (ASCII) file format <NUM>. The ASCII file format <NUM> may be unsupported by or incompatible with the application <NUM>. Therefore, the logic <NUM> may detect such incompatibility and determine a new application <NUM> that supports and is compatible with the second file format, the ASCII file format <NUM>, and process the second file format to convert that into a third file format such as a raster file format <NUM>, or any of formats supported by immediate downstream applications (e.g., the application <NUM>). The logic <NUM> may then either disable the application <NUM> or relegate the application <NUM> to a background or paused state (as will be further described with respect to <FIG>) that is not currently operational and provision the new application <NUM>. In some embodiments, the logic <NUM> may determine any or all applications that do support and are compatible with the second file format and receive a selection from the user of a particular application from those determined applications. Similarly, if other data characteristics such as data types, data objects, or other data attributes of input data change, thereby resulting in incompatibility with one or more applications, the logic <NUM> may switch to a new application in a same or similar manner as described above. In such a manner, by having the contextual information of which data types, data objects, or data formats are supported by each application, the logic <NUM> may adapt to changes, for example, in data formats, data types, or data objects, seamlessly while minimizing delay. Additionally, applying the contextual information may avoid triggering an error by one of the applications due to inability to process a particular data format, data type, or data object.

<FIG> illustrates an example implementation of coordinating execution statuses of applications. A running status of an application may be adjusted based on an amount of available computing resources on a computing device on which the applications run and/or based on one or more changes to file formats, attributes or types of data fed into applications. For example, a first subset of applications may be in a running status if they are currently operating, while a second subset of applications may be in a paused status and a third subset of applications may be in an inactive status. In particular, any applications that are currently operating may be in a running state, while other downstream applications such as immediate downstream applications, which are currently not running but will be, or will likely be, subsequently running within a particular threshold duration with some threshold probability, may be in a paused status. For example, such applications in a paused status may include downstream applications that were selected by the user as described in <FIG>. Other applications which were not selected by a user, not determined to be compatible with data types, data formats, and/or data objects, determined to be incompatible with data types, data formats, and/or data objects, and/or unlikely to be running within a particular threshold duration, may be in an inactive status. In the implementation of <FIG>, the applications <NUM>, <NUM>, and <NUM> may be in a running status. The applications <NUM>, <NUM>, and <NUM>, which are downstream, may be in a paused status so that they can be automatically switched to a running status instantaneously once the logic <NUM> determines or receives an indication that data from one or more upstream applications has been outputted or processed. A paused status may entail unmounting a front end of an application. The logic <NUM> may capture a most recent update or snapshot made to an application, to be saved, in a paused status. The most recent snapshot may include analyses in progress, and/or saved settings of such, including filters. In some embodiments, particular aspects or portions of data from the applications may be saved separately, for example, within separate portions or partitions of the database <NUM> or the cache <NUM> representing separate sessions. For example, the applications of <FIG> may process and analyze navigational data from different vehicles concurrently or simultaneously. The data of each vehicle may be saved within separate sessions.

In the context of <FIG>, once the LiDAR data <NUM>, the IMU data <NUM>, and the GPS data <NUM> has been processed or output by the applications <NUM>, <NUM>, and <NUM>, respectively, the application <NUM> may automatically be switched to a running status while the applications <NUM>, <NUM>, and <NUM> may automatically be switched to an inactive status. Similarly, once the application <NUM> has completed processing of or outputted data types or data objects of a map, and a coordinate data type or a matrix data object indicative of a location, the applications <NUM> and <NUM> may automatically be switched to running statuses while the application <NUM> may automatically be switched to an inactive status. In a paused status, an application may consume a reduced amount of computing resources compared to running applications and may be relegated to a background. Other applications which are not illustrated in <FIG>, and are unlikely to be implemented, unselected, and/or determined not to be compatible with data objects, data types, data formats, and/or other data criteria, may be in an inactive status, so that they consume zero to a minimal amount of computing resources.

In some embodiments, the logic <NUM> may determine an amount of computing resources or an available amount of computing resources on a computing device (e.g., the computing device <NUM> or another computing device) that operates the applications <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>. The logic <NUM> may automatically adjust an amount of, and which, applications that are currently in a running or operational status based on the amount of computing resources or the available amount of computing resources. Therefore, the logic <NUM> may streamline efficiency of the running of the applications <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> while preventing overloading of a computing device. For example, if the logic <NUM> determines that the amount of computing resources or the available amount of computing resources is inadequate to maintain all three applications <NUM>, <NUM>, and <NUM> in running statuses, the logic <NUM> may relegate one or more of those applications to a paused status depending on the amount of computing resources or the available amount of computing resources. In other embodiments, if particular applications are constantly receiving or ingesting data outputted by one or more other applications at a high frequency, such as, at a higher than threshold frequency, then, given adequate computing resources or available computing resources, the logic <NUM> may keep those particular applications in a running status even if they are not concurrently running with the other applications. For example, in <FIG>, if the application <NUM> is frequently ingesting data outputted by the applications <NUM>, <NUM>, and <NUM>, even if the application is not running concurrently with or in parallel with the applications <NUM>, <NUM>, and <NUM>, the application <NUM> may also be converted to a running status while the applications <NUM>, <NUM>, and <NUM> are in a running status, given adequate computing resources or available computing resources. Similarly, the logic <NUM> may adaptively transform or convert certain applications between a paused status and an inactive status based on an amount of computing resources or an available amount of computing resources on a computing device. In some embodiments, the amount of computing resources may be indicative of an amount of memory or hard-drive capabilities or capacities.

Overall, the logic <NUM> may perform adjusting running statuses of the applications based on an amount of available computing resources (e.g., memory and/or other processing resources such as processing power dissipation, which may be measured in Watts or Watt-hours) and/or a predicted amount of available computing resources on a computing device on which the applications run and based on one or more changes to file formats of files fed into the respective applications, the running statuses including or indicating an operational state, a paused state that consumes less computing resources compared to the operational state, and an inactive state that consumes less computing resources compared to the paused state, the adjusting of the running statuses comprising determining a number of the applications to be in an operational state, for example, based at least in part on the amount of the available computing resources or the predicted amount of the available computing resources. For example, the predicted amount of the available computing resources may be based on or dependent upon which applications, and/or a number of applications scheduled or predicted to be run and/or operational (e.g., in the operational status) at a future time, such as a particular range or point of time in a future (e.g., in a subsequent one hour span). In particular, at a specific future point of time, the logic <NUM> may limit a number of applications scheduled to run, and/or an amount of computing resources scheduled to be run. Additionally, which file format is fed into an application may also affect an amount of computing resources consumed by the application. Therefore, if a change in a file format causes an amount of computing resources to increase for a particular application, then the logic <NUM> may increase a number of applications that are running on a paused state and/or an inactive state. However, if a change in a file format causes an amount of computing resources to decrease for a particular application, then the logic <NUM> may decrease a number of applications that are running on a paused state and/or an inactive state. The determination of which applications are to be run in an operation state may depend, for example, on a frequency of utilization of the applications and/or a time and/or resources consumed as a result of starting up the application, and/or to transition from the inactive state to the paused state, and/or from the paused state to the operational state. For example, if an application takes a comparatively long time and/or consumes a high amount of computing resources to transition from an inactive or paused state to the operational state, the logic <NUM> may prioritize that application to be in an operational state over other applications. Therefore, adjusting running statuses of the applications based on an amount of available computing resources may entail relegating a subset of any applications of lower priority to be in an operational state before relegating any applications of higher priority.

<FIG> illustrates an example implementation in which an output is sequentially modified at each application. Therefore, whereas in <FIG>, <FIG>, <FIG>, and <FIG>, outputs of at least some of the applications <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> may have different data objects, data formats, and/or data types, in <FIG>, outputs at the applications may have at least a common data object, data format, and/or data type. Specifically illustrated in <FIG> is a sequential training process, for example, as applied to a machine learning model. Although <FIG> illustrates a training process, implementations are not to be construed as limited to a training process, but rather may apply to any process that sequentially modifies an entity or data such as a data object.

The application framework <NUM> may be executed to provision applications including <NUM>, <NUM>, <NUM>, and <NUM>. A machine learning model <NUM>, or a representation thereof, may be ingested into the application <NUM>. Additionally, attributes or characteristics of the machine learning model <NUM>, including a type of and tasks to be performed or capable of being performed by the machine learning model, may be ingested into the application <NUM>. Other attributes of the machine learning model <NUM> may include a current training status indicating how the machine learning model <NUM> has already been trained. The application <NUM> may generate first training data <NUM> for the machine learning model <NUM>. A type of the first training data <NUM> may be determined based on a type and/or tasks to be performed by the machine learning model <NUM>. For example, if the machine learning model <NUM> performs image processing, then the first training data <NUM> may include images. As another example, if the machine learning model <NUM> performs object recognition, then the first training data <NUM> may include objects of a to-be-recognized type or category and/or objects that may be commonly mistaken for objects of the to-be-recognized type or category. The application <NUM> may further train the machine learning model and generate an updated or trained machine learning model (hereinafter "updated machine learning model") <NUM>. In some embodiments, the updated machine learning model <NUM> may be stored in the database <NUM> and/or cached in the cache <NUM>. Next, the logic <NUM> may feed the updated machine learning model <NUM>, or a representation thereof, into the application <NUM>. In some embodiments, the logic <NUM> may feed the updated machine learning model <NUM> via the database <NUM> or the cache <NUM>. The application <NUM> may perform evaluation and/or analysis of the updated machine learning model <NUM>, such as, shortcomings of the updated machine learning model <NUM>. For example, the application <NUM> may run simulations of the updated machine learning model <NUM>. In some embodiments, results of the evaluation and/or analysis of the updated machine learning model <NUM> may be stored in the database <NUM> or the cache <NUM>. Next, the logic <NUM> may feed the updated machine learning model <NUM>, or a representation thereof, into the application, along with the results from the application <NUM>, into the application <NUM>. The application <NUM> may generate second training data <NUM> based on the updated machine learning model <NUM> and the results from the application <NUM>. The application <NUM> may further train the updated machine learning model <NUM> using the second training data <NUM> and generate a second updated machine learning model <NUM>. In some embodiments, the second updated machine learning model <NUM> may be stored in the database <NUM> and/or cached in the cache <NUM>. Next, the logic <NUM> may feed the second updated machine learning model <NUM>, or a representation thereof, into the application <NUM>. The application <NUM> may perform evaluation and/or analysis of the second updated machine learning model <NUM>, such as, shortcomings of the second updated machine learning model <NUM>. The applications <NUM> and <NUM> may be implemented in a same or similar manner as the applications <NUM> and <NUM>, respectively.

In some embodiments, instead of feeding one or more outputs of the application <NUM> to the application <NUM>, the outputs of the application <NUM> may instead be fed back to the application <NUM>. The application <NUM>, instead of the application <NUM>, may then generate the updated training data <NUM> and train the updated machine learning model <NUM> without incurring processing resources of the application <NUM>, which may be paused. The application <NUM> may then generate the second updated machine learning model <NUM>, which may be fed into the application <NUM>. Therefore, data may be processed and/or transformed, and transmitted to different applications, in a cyclical process in <FIG>.

<FIG> illustrates an exemplary flowchart, according to various embodiments of the present disclosure. A method described in the flowchart may be implemented in various environments including, for example, the environment <NUM> of <FIG>. <FIG> illustrates a computing component <NUM> that includes one or more hardware processors <NUM> and machine-readable storage media <NUM> storing a set of machine-readable/machine-executable instructions that, when executed, cause the hardware processor(s) <NUM> to execute an application framework to provision a workspace or a pipeline comprising applications. It should be appreciated that there can be additional, fewer, or alternative steps performed in similar or alternative orders, or in parallel, within the scope of the various embodiments discussed herein unless otherwise stated. The computing component <NUM> may be implemented as the computing system <NUM> of <FIG>, <FIG>, <FIG>, <FIG>, <FIG>, and <FIG>. The computing component <NUM> may include a server. The machine-readable storage media <NUM> may include suitable machine-readable storage media described in <FIG>, and/or the machine-readable storage media <NUM> of <FIG>. The hardware processor(s) <NUM> may be implemented as the hardware processors <NUM> of <FIG>.

In step <NUM>, the hardware processor(s) <NUM> executes machine-readable/machine-executable instructions stored in the machine-readable storage media <NUM> to determining or receiving an indication of the applications to be installed into the pipeline, workspace or other collaborative framework. The hardware processors <NUM> determine the applications to be installed based on a computing task to be performed, and/or based on a user input or feedback. In step <NUM>, the hardware processors <NUM> determine or receive contextual information of each of the applications. The contextual information may be provided by a user and/or retrieved from a storage associated with or within the computing component <NUM>, such as the database <NUM>. The database <NUM> may include or be implemented as a registry in some embodiments. The contextual information includes one or more data objects, data types, data formats, and/or other data attributes supported by, compatible with, ingestible into, and/or recognizable by each of the applications; and one or more relationships among the applications. The data attributes may include particular ranges of values of data, and/or particular ranges of times at which the data was obtained. The relationships may indicate a sequential relationship, for example, whether an application is immediately downstream or upstream of another application.

In step <NUM>, the hardware processors <NUM> provisions one or more of the applications based on the indication of the applications to be installed and the contextual information. The provisioning of the applications may include configuring applications to receive data from immediately upstream applications. For example, the application <NUM> in <FIG> may be configured to receive data from the applications <NUM>, <NUM>, and <NUM>. The provisioning may also include setting access control policies of the applications across different users, groups, categories, and/or organizations. For example, a particular user in a first organization may require permission to create a new workspace or modify an existing workspace to be visible to users in a second organization, even if users in the second organization have access to the existing workspace. Such a scenario may arise when users in the first organization and users in the second organization share a common project which may include workspaces.

In step <NUM>, the hardware processors <NUM> receive an indication of an update at an application of the applications. In some embodiments, the hardware processors <NUM> may store the update at a database such as the database <NUM> or cache the update at a cache such as the cache <NUM>. In step <NUM>, the hardware processors <NUM> selectively propagate the update to a subset of the applications based on the contextual information. For example, if a particular data object has been updated, the updated data object may be propagated only to particular applications that perform operations on the particular data object and/or are compatible with the data object.

The techniques described herein are implemented by one or more special-purpose computing devices. The special-purpose computing devices may be hard-wired to perform the techniques, or may include circuitry or digital electronic devices such as one or more application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) that are persistently programmed to perform the techniques, or may include one or more hardware processors programmed to perform the techniques pursuant to program instructions in firmware, memory, other storage, or a combination. The special-purpose computing devices may be desktop computer systems, server computer systems, portable computer systems, handheld devices, networking devices or any other device or combination of devices that incorporate hard-wired and/or program logic to implement the techniques.

Computing device(s) are generally controlled and coordinated by operating system software. Operating systems control and schedule computer processes for execution, perform memory management, provide file system, networking, I/O services, and provide a user interface functionality, such as a graphical user interface ("GUI"), among other things.

<FIG> is a block diagram that illustrates a computer system <NUM> upon which any of the embodiments described herein may be implemented. The computer system <NUM> includes a bus <NUM> or other communication mechanism for communicating information, one or more hardware processors <NUM> coupled with bus <NUM> for processing information. Hardware processor(s) <NUM> may be, for example, one or more general purpose microprocessors.

The computer system <NUM> also includes a main memory <NUM>, such as a random access memory (RAM), cache and/or other dynamic storage devices, coupled to bus <NUM> for storing information and instructions to be executed by processor <NUM>. Such instructions, when stored in storage media accessible to processor <NUM>, render computer system <NUM> into a special-purpose machine that is customized to perform the operations specified in the instructions.

The computer system <NUM> further includes a read only memory (ROM) <NUM> or other static storage device coupled to bus <NUM> for storing static information and instructions for processor <NUM>. A storage device <NUM>, such as a magnetic disk, optical disk, or USB thumb drive (Flash drive), etc., is provided and coupled to bus <NUM> for storing information and instructions.

The computer system <NUM> may be coupled via bus <NUM> to a display <NUM>, such as a cathode ray tube (CRT) or LCD display (or touch screen), for displaying information to a computer user. In some embodiments, the same direction information and command selections as cursor control may be implemented via receiving touches on a touch screen without a cursor.

The computing system <NUM> may include a user interface module to implement a GUI that may be stored in a mass storage device as executable software codes that are executed by the computing device(s). This and other modules may include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables.

In general, the word "module," as used herein, refers to logic embodied in hardware or firmware, or to a collection of software instructions, possibly having entry and exit points, written in a programming language, such as, for example, Java, C or C++. A software module may be compiled and linked into an executable program, installed in a dynamic link library, or may be written in an interpreted programming language such as, for example, BASIC, Perl, or Python. It will be appreciated that software modules may be callable from other modules or from themselves, and/or may be invoked in response to detected events or interrupts. Software modules configured for execution on computing devices may be provided on a computer readable medium, such as a compact disc, digital video disc, flash drive, magnetic disc, or any other tangible medium, or as a digital download (and may be originally stored in a compressed or installable format that requires installation, decompression or decryption prior to execution). Such software code may be stored, partially or fully, on a memory device of the executing computing device, for execution by the computing device. Software instructions may be embedded in firmware, such as an EPROM. It will be further appreciated that hardware modules may be comprised of connected logic units, such as gates and flip-flops, and/or may be comprised of programmable units, such as programmable gate arrays or processors. The modules or computing device functionality described herein are preferably implemented as software modules, but may be represented in hardware or firmware. Generally, the modules described herein refer to logical modules that may be combined with other modules or divided into sub-modules despite their physical organization or storage.

The computer system <NUM> may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computer system causes or programs computer system <NUM> to be a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system <NUM> in response to processor(s) <NUM> executing one or more sequences of one or more instructions contained in main memory <NUM>. Execution of the sequences of instructions contained in main memory <NUM> causes processor(s) <NUM> to perform the process steps described herein.

The term "non-transitory media," and similar terms, as used herein refers to any media that store data and/or instructions that cause a machine to operate in a specific fashion. Such non-transitory media may comprise non-volatile media and/or volatile media. Common forms of non-transitory media include, for example, a floppy disk, a flexible disk, hard disk, solid state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge, and networked versions of the same.

Non-transitory media is distinct from but may be used in conjunction with transmission media. Transmission media participates in transferring information between non-transitory media.

The instructions received by main memory <NUM> may retrieves and executes the instructions.

The computer system <NUM> also includes a communication interface <NUM> coupled to bus <NUM>. Communication interface <NUM> provides a two-way data communication coupling to one or more network links that are connected to one or more local networks. As another example, communication interface <NUM> may be a local area network (LAN) card to provide a data communication connection to a compatible LAN (or WAN component to communicated with a WAN).

A network link typically provides data communication through one or more networks to other data devices. For example, a network link may provide a connection through local network to a host computer or to data equipment operated by an Internet Service Provider (ISP). The ISP in turn provides data communication services through the world wide packet data communication network now commonly referred to as the "Internet". Local network and Internet both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link and through communication interface <NUM>, which carry the digital data to and from computer system <NUM>, are example forms of transmission media.

The computer system <NUM> can send messages and receive data, including program code, through the network(s), network link and communication interface <NUM>. In the Internet example, a server might transmit a requested code for an application program through the Internet, the ISP, the local network and the communication interface <NUM>.

Each of the processes, methods, and algorithms described in the preceding sections may be embodied in, and fully or partially automated by, code modules executed by one or more computer systems or computer processors comprising computer hardware. The processes and algorithms may be implemented partially or wholly in application-specific circuitry.

The various features and processes described above may be used independently of one another, or may be combined in various ways. All possible combinations and sub-combinations are intended to fall within the scope of this disclosure. In addition, certain method or process blocks may be omitted in some implementations. The methods and processes described herein are also not limited to any particular sequence, and the blocks or states relating thereto can be performed in other sequences that are appropriate. For example, described blocks or states may be performed in an order other than that specifically disclosed, or multiple blocks or states may be combined in a single block or state. The example blocks or states may be performed in serial, in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed example embodiments. The example systems and components described herein may be configured differently than described. For example, elements may be added to, removed from, or rearranged compared to the disclosed example embodiments.

Conditional language, such as, among others, "can," "could," "might," or "may," unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or steps. Thus, such conditional language is not generally intended to imply that features, elements and/or steps are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without user input or prompting, whether these features, elements and/or steps are included or are to be performed in any particular embodiment.

Any process descriptions, elements, or blocks in the flow diagrams described herein and/or depicted in the attached figures should be understood as potentially representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process. Alternate implementations are included within the scope of the embodiments described herein in which elements or functions may be removed, executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those skilled in the art.

It should be emphasized that many variations and modifications may be made to the above-described embodiments, the elements of which are to be understood as being among other acceptable examples. It will be appreciated, however, that no matter how detailed the foregoing appears in text, the invention can be practiced in many ways. As is also stated above, it should be noted that the use of particular terminology when describing certain features or aspects of the invention should not be taken to imply that the terminology is being re-defined herein to be restricted to including any specific characteristics of the features or aspects of the invention with which that terminology is associated.

Although an overview of the subject matter has been described with reference to specific example embodiments, various modifications and changes may be made to these embodiments without departing from the scope of the claims. Such embodiments of the subject matter may be referred to herein, individually or collectively, by the term "invention" merely for convenience and without intending to limit the scope of the claims.

Other embodiments may be used and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of the claims. The Detailed Description, therefore, is not to be taken in a limiting sense.

It will be appreciated that an "engine," "system," "data store," and/or "database" may comprise software, hardware, firmware, and/or circuitry. In one example, one or more software programs comprising instructions capable of being executable by a processor may perform one or more of the functions of the engines, data stores, databases, or systems described herein. In another example, circuitry may perform the same or similar functions. Alternative embodiments may comprise more, less, or functionally equivalent engines, systems, data stores, or databases, and still be within the scope of present embodiments. For example, the functionality of the various systems, engines, data stores, and/or databases may be combined or divided differently.

"Open source" software is defined herein to be source code that allows distribution as source code as well as compiled form, with a well-publicized and indexed means of obtaining the source, optionally with a license that allows modifications and derived works.

The data stores described herein may be any suitable structure (e.g., an active database, a relational database, a self-referential database, a table, a matrix, an array, a flat file, a documented-oriented storage system, a non-relational No-SQL system, and the like), and may be cloud-based or otherwise.

As used herein, the term "or" may be construed in either an inclusive or exclusive sense. Moreover, plural instances may be provided for resources, operations, or structures described herein as a single instance. Additionally, boundaries between various resources, operations, engines, engines, and data stores are somewhat arbitrary, and particular operations are illustrated in a context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within a scope of various embodiments of the present disclosure. In general, structures and functionality presented as separate resources in the example configurations may be implemented as a combined structure or resource. Similarly, structures and functionality presented as a single resource may be implemented as separate resources. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Although the invention has been described in detail for the purpose of illustration based on what is currently considered to be the most practical and preferred implementations, it is to be understood that such detail is solely for that purpose and that the invention is not limited to the disclosed implementations, but, on the contrary, is intended to cover modifications and equivalent arrangements that are within the scope of the appended claims. For example, it is to be understood that the present invention contemplates that, to the extent possible, one or more features of any embodiment can be combined with one or more features of any other embodiment. A component being implemented as another component may be construed as the component being operated in a same or similar manner as the another component, and/or comprising same or similar features, characteristics, and parameters as the another component.

The phrases "at least one of," "at least one selected from the group of," or "at least one selected from the group consisting of," and the like are to be interpreted in the disjunctive (e.g., not to be interpreted as at least one of A and at least one of B).

Claim 1:
A computer-implemented method comprising:
executing an application framework (<NUM>) to provision a pipeline or workspace comprising applications, the provisioning comprising:
determining or receiving (<NUM>) an indication of the applications to be installed;
determining or receiving (<NUM>) contextual information of each of the applications, the contextual information comprising:
one or more data objects, data types, or data formats supported by each of the applications; and
one or more relationships among the applications;
provisioning (<NUM>) the indicated applications using the contextual information;
receiving (<NUM>) an indication of an update at a first application of the applications;
propagating (<NUM>) the update to a subset of the applications which, from the contextual information, are determined to be compatible with and support the data objects, data types and/or data formats consistent with the update and which have a downstream relationship to the first application; and
using an amount of available computing resources on a computing device on which the applications run and using one or more changes to data objects, data types, or data formats of data fed into the applications to adjust running statuses of the applications, the running statuses comprising an operational state, a paused state that consumes less computing resources compared to the operational state, and an inactive state that consumes less computing resources compared to the paused state, the adjusting of the running statuses comprising determining a number of the applications to be in an operational state.