Systems and methods for hardware specification modeling

Abstract

A system and method for determining hardware configurations of energy production assets using machine learning and swarm optimization are disclosed. Historical energy production data and corresponding weather data are input to a machine learning model that simulates performance under various candidate hardware models. A swarm algorithm iteratively selects the candidate models to minimize a quantile-based cost function. Upon convergence, the system identifies a best-fit hardware model for the asset and generates a digital twin configured with that model.

Description

SYSTEMS AND METHODS FOR HARDWARE SPECIFICATION MODELINGCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of U.S. Provisional Patent App. No.63 / 750,232, filed January 27, 2025, which is hereby incorporated by reference herein. TECHNICAL FIELD

[0002] This invention relates generally to hardware modeling, and particularly modeling of energy product assets,BACKGROUND

[0003] Energy production assets, for example solar photovoltaic (PV) systems, have performance that can vary significantly based on hardware configuration, component conditions, and environmental factors. Digital twin models of such assets are used to predict performance and monitor operation, but they rely on accurate hardware specifications. In practice, the detailed hardware information for an installed solar asset is not always available or may be outdated. Missing or inaccurate hardware specifications lead to digital twin models producing low-quality output, which hampers effective asset performance monitoring and maintenance.BRIEF DESCRIPTION OF DRAWINGS

[0004] Various needs are at least partially met through provisions of the systems and methods for hardware modeling of energy production assets described in the following detailed description, particularly when studied in conjunction with the drawings. A full and enabling disclosure of the aspects of the present description, including the best mode thereof, directed to one of ordinary skill in the art, is set forth in the specification, which refers to the appended figures, in which:

[0005] FIG. 1 is a flow diagram illustrating an exemplary method for hardware modeling of an energy production asset in accordance with embodiments of the present disclosure.Attorney Docket No. 21830-160617-US

[0006] FIG. 2A is a graph of daily energy production, comparing actual measured production to predicted production generated by a conventional gray-box modeling method.

[0007] FIG. 2B is a graph of daily energy production, comparing actual measured production to predicted production generated in accordance with an embodiment of the present disclosure.

[0008] FIG. 3 is a block diagram of an example computing system that can be utilized to implement the hardware modeling system and method in various embodiments.

[0009] Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and / or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to help improve understanding of various embodiments of the present teachings. Also, common but well-understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present teachings. Certain actions and / or steps may be described or depicted in a particular order of occurrence, while those skilled in the art will understand that such specificity with respect to sequence is not actually required.DETAILED DESCRIPTION

[0010] Embodiments of the invention will now be described in detail, with reference to the accompanying drawings. It is to be understood that the described embodiments are illustrative and not limiting; various modifications and substitutions will be apparent to those skilled in the art without departing from the scope of the invention as defined by the claims.

[0011] Gray-box modeling generally refers to deriving parameters associated with a device (such as physical characteristics and configuration) based on its output behavior. For energy production assets, for example, solar photovoltaic (PV) systems, gray-box modeling may use the asset's performance data (energy output over time) and knownAttorney Docket No. 21830-160617-USexternal inputs like location and weather to infer the asset's hardware specifications. Many existing gray-box solutions do not provide the actual hardware configuration to the userand can suffer from accuracy issues for certain assets. In particular, conventional gray-box models tend to overfit or misinterpret anomalous periods (such as those caused by hardware outages, shading, soiling, or other irregular events) as normal behavior, leading to biased or inconsistent predictions. For example, a model that minimizes mean error may consistently under- or over-estimate energy production if the training data includes extended downtime or irregular shading events. There is a need for improved hardware modeling techniques that can robustly infer asset hardware parameters from limited data, handle anomalies without overfitting, and yield more accurate and stable energy production predictions.

[0012] Generally speaking, various embodiments described herein provide systems and methods for modeling hardware configurations of energy production assets from operational data. In some embodiments, a machine-learning-based simulation combined with a swarm optimization algorithm that minimizes a quantile-based error metric is used to determine the hardware model of a solar energy asset, thereby improving the accuracy of energy production estimations. In this description, technical terms are used consistently with their ordinary meanings in the field, except where explicitly defined otherwise. As used herein, "or" is intended to be inclusive, meaning "and / or," unless the context clearly dictates otherwise. Thus, a condition of "A or B" is satisfied by A alone, B alone, or both A and B. The singular forms "a," "an," and "the" include plural references unless the context clearly dictates otherwise. Additionally, terms like "coupled" or "attached" encompass both direct and indirect connections (through intermediate elements) unless otherwise specified. Approximating language such as "about" or "approximately," when used to modify a quantitative value, means that minor variations (e.g., within 10%) of the stated value are within the intended scope.Attorney Docket No. 21830-160617-US

[0013] Solar energy production assets (or simply "solar assets") generally refer to hardware for converting sunlight into electricity, such as PV panel arrays, inverters, and related components. A digital twin model of a solar asset uses the asset's hardware specifications and other inputs (like weather data) to predict expected energy output. However, when the hardware specifications are unknown or incorrect, the digital twin's predictions can be inaccurate. The present disclosure addresses this scenario by deriving the hardware configuration of a solar asset using only readily available data, historical energy production measurements and corresponding environmental data, thereby constructing an accurate digital twin. By improving the accuracy of the digital twin, the system enables more reliable performance monitoring and anomaly detection, as described further below.

[0014] To derive a model of the hardware without knowledge of its configuration, the system employs a gray-box modeling approach enhanced with machine learning (ML) and swarm optimization. FIG. 1 illustrates an example process 100 for hardware modeling of a solar asset's specifications for energy production prediction. The steps of process 100 may be performed by a processor-based computing system executing computer-readable instructions (for instance, by the computing system 300 of FIG. 3). FIG. 3, described later, provides an example of such a computing system. In general, the system includes one or more processors coupled to memory and storage devices that store program instructions. When the instructions are executed by the processors, they cause the system to perform the functions described herein (such as data ingestion, simulation, optimization, etc.). These instructions can be stored on a non-transitory computer-readable medium (e.g., the system's memory or storage), such that the system for hardware modeling comprises hardware (the processor) and software (instructions) to carry out the methods described.

[0015] Referring to FIG. 1, at step 102 the system receives and aggregates recorded energy output data from an energy asset 101 over a period of time. For example, the system may collect hourly or daily energy production values for at least about 45 days ofAttorney Docket No. 21830-160617-USoperation. Along with production data, the system obtains corresponding historical weather data (input 120 in FIG. 1) for the asset's location and timeframe, including irradiance (sunlight intensity) and temperature records. These environmental factors influences solar asset production output, and are used as additional inputs to the modeling process. While around 45 days or more of data is a typical window for robust modeling, the approach can be applied to shorter data durations.

[0016] At step 104, a trained machine learning (ML) model simulates the asset's energy production under various hypothetical hardware configurations. The ML model may be a physics-informed simulation or another predictive model trained on data from many a plurality of energy assets (for instance, using historical performance data from a plurality of solar energy production assets). It accepts candidate hardware parameters (such as array tilt angle, orientation / azimuth, and system capacity) along with the historical weather data, and produces a simulated energy output time series for each candidate model. Initially, the system considers a plurality of candidate hardware models 125 (FIG. 1) representing different possible hardware configurations for the asset. These candidates can span a broad search space of possibilities, potentially encompassing thousands of combinations, especially if no prior information is known about the asset's hardware. The ML model iteratively evaluates these candidate configurations to find a configuration whose predicted output best matches the actual recorded output over the period.

[0017] Exhaustively testing every possible hardware combination (e.g., the brute-force approach) would be computationally prohibitive . Therefore, at step 106, an optimization algorithm is employed to guide the navigation in the search space of hardware parameters. In some embodiments, a particle swarm optimization (PSO) algorithm is used as the swarm optimization technique. PSO initializes a "swarm" of particles, where each particle represents a candidate hardware model with specific parameter values. These particles collectively explore the multi-dimensional parameter space, and each particle's position (i.e., the set of hardware parameters it represents) isAttorney Docket No. 21830-160617-USiteratively adjusted based on its own performance history and that of its neighbors. In other words, each particle "learns" from its prior simulations and the best solutions found so far, effectively balancing local exploration with global guidance to home in on better solutions. This swarm-based approach is well-suited for continuous optimization in a multi-dimensional space . In some embodiments, other swarm-based algorithms may be used as alternatives depending on the specific modeling requirements. These include ant colony optimization (ACO), artificial bee colony (ABC), firefly algorithm, cuckoo search, bat algorithm, glowworm swarm optimization (GSO), and grey wolf optimizer (GWO).

[0018] In step 106, the swarm algorithm uses a quantile cost function to measures how well a given candidate hardware model's simulated output matches the actual output. In some embodiments, the cost is computed as a median absolute error (i.e., using a quantile value q = 0.5, the 50th percentile), though other quantiles may be used depending on the desired sensitivity. A quantile cost function evaluates prediction error such that a specified fraction (quantile) of the errors is above or below zero, effectively fitting the model to a particular percentile of the error distribution rather than to the mean. For instance, using the median (50th percentile, q = 0.5) error emphasizes typical performance and reduces the influence of outliers. A higher quantile (e.g., q = 0.9) would make the system overly sensitive to occasional high outlier values (e.g., isolated spikes in production), while a lower quantile (e.g., q = 0.1) would over-emphasize low outliers (e.g., periods of abnormally low production, such as during hardware failures), potentially causing the model to overfit to those anomalies. Thus, the median quantile strikes a balance, focusing on the central trend of the data without being skewed by extreme transient events.

[0019] The quantile cost function may be defined programmatically. For example, pseudo-code for a median (q=0.5) absolute error cost function can be expressed as follows:def quantile_loss(q, y, f):Attorney Docket No. 21830-160617-US# q: Quantile to evaluate (e.g., 0.5 for median)# y: True (observed) value#f: Fitted or predicted valuee = y - freturn sum(max(q * e_i, (q - 1) * e_i) for each error e_i in e)

[0020] Mathematically, for a given quantile q (0 < q < 1), the quantile loss can be expressed as:

[0021] (yj — yj), (q - 1) • (y, - y;) },where yjare the actual measured values and yjare the model's predicted values. For q = 0.5 (the median), this reduces to the sum of absolute errors (each error weighted equally), penalizing positive and negative deviations symmetrically. By using a quantile cost function, periods with anomalously low or high production (due to irregular issues like hardware outages, soiling, or shading) have a reduced impact on the optimization. By focusing on the median trend, the swarm algorithm largely ignores outlier behavior, thereby avoiding skewed parameter estimates caused by temporary issues. In other words, the model is less likely to "bake in" circumstantial poor performance into the inferred hardware settings, a common form of overfitting in prior methods. The quantile-based approach thus yields a more robust fit that represents the asset's normal operating behavior.

[0022] During the swarm optimization iterations, the candidate models (particles) are gradually refined. Each particle evaluates the cost (error) of its current hardware parameter set, and the quantile cost feedback influences its movement in the parameter space. Each particle remembers the best solution (lowest cost) it has found so far (often called the particle's "personal best") and is attracted toward both that position and the swarm's global best solution found by any particle. Some randomness or stochastic perturbation is also introduced in the PSO update to avoid premature convergence to local minima. Over successive iterations, the swarm converges towardAttorney Docket No. 21830-160617-USan optimal region in the parameter space. When the improvement in the best cost value becomes negligible over a number of iterations (or after a predetermined number of iterations), the process stops. At that point, the system identifies the best-fit hardware model - i.e., the candidate with the lowest quantile cost - as the likely hardware configuration of the asset. In summary, the swarm optimization algorithm iteratively refines the candidate hardware models based on feedback from prior simulations (the cost outcomes), culminating in a converged solution that provides the closest match between simulated and actual performance data.

[0023] Optionally, domain constraints can be applied to the search space to improve efficiency and realism of the inferred solution. In one embodiment, particularly suited for a solar PV asset, the system models the asset with only three primary adjustable parameters: tilt angle, azimuth (orientation) angle, and system size (DC capacity). This constitutes a simplified physical model of the solar asset, essentially treating the entire array as a single equivalent module or array characterized by those three parameters. All other model inputs can be fixed to default values or known constants. By reducing the problem to these three key parameters, the swarm optimization only needs to search within a three-dimensional parameter space, which greatly reduces complexity. If absolutely no information is available about the asset, the PSO can operate in an unbounded or very broadly bounded space for these parameters. However, if some rough data or expectations are at hand, those can be used to set reasonable bounds on the search space before or during the iteration. For example, the site's latitude might inform a reasonable tilt range, or a utility interconnection rating might suggest an approximate system size. In an exemplary implementation, the parameter ranges are bounded as follows: the tilt angle is limited between 0° and 45° relative to horizontal, the azimuth angle is limited between 0° and 360° (covering all compass orientations), and the system size is limited to within about 85% to 115% of a nominal or initially estimated system capacity. (These bounds are depicted in FIG. 1 as limits on the search, and are also reflected in FIG. 3's data structures for the model parameters.) ByAttorney Docket No. 21830-160617-USconstraining parameters to physically plausible ranges, the algorithm avoids implausible solutions and converges faster without losing the true solution. In particular, the ±15% system size bound is an important "guard rail": it gives the swarm some slack to account for asset-specific losses, clipping, or other inefficiencies, while still limiting this slack to prevent the algorithm from overfitting to a broken or underperforming asset (for instance, falsely interpreting a sustained 50% power loss as the system simply being half the size). Thus, applying these bounds helps ensure that the selected hardware model remains realistic and avoids extreme parameter values that do not make physical sense for the asset.

[0024] After the swarm converges and the best-fit parameters are selected, at step 108 the system uses the identified hardware model to create or update a digital twin simulation of the asset. The digital twin is essentially a software representation of the asset configured with the inferred hardware settings (e.g., the specific tilt, azimuth, capacity, and any other determined parameters). Then, at step 110, this digital twin model is run to generate predicted energy production for the asset over the period of interest. In an initial validation phase, these predictions can be compared to the historical actual data (the same recorded period used for training) to verify the accuracy of the inference. Because the digital twin now reflects the asset's hardware more accurately, its simulated output is expected to more closely match the measured output for the training period and can be projected forward in time for forecasting future performance under new weather conditions.

[0025] The system may further compute performance metrics to validate the digital twin's accuracy and to monitor ongoing performance. For instance, a performance ratio (PR) - defined in the solar industry as the ratio of actual energy produced to the model's expected energy (under the same weather conditions) - can be calculated for the historical period and beyond. If the PR remains consistently near 1.0 for the new model, it indicates the model is well-calibrated to the asset (i.e., the predicted output closely matches reality). In contrast, a PR that drifts significantly above or below 1 mightAttorney Docket No. 21830-160617-USindicate issues: assuming the model is correct, a PR below 1.0 (actual < expected) could signal ongoing hardware problems or soiling (the asset underperforms relative to the model), whereas if the asset is known to be healthy, a persistent PR deviation could suggest the model isn't perfectly tuned yet. Thus, PR provides a convenient validation of how well the inferred model represents the asset.

[0026] Turning now to FIGS. 2A and 2B, these illustrate the improved accuracy achieved by the disclosed modeling approach compared to a conventional model. FIG. 2A shows a plot of daily energy production for an example asset over a three-month period: the actual measured production 201 (solid line) and the expected production 202 as predicted by a prior-art gray-box model (dashed line). The prior model's predictions consistently underestimate the actual production 201. In this scenario, inclusion of periods of reduced output (due to temporary issues or outages in the training data) likely caused that conventional model to assume a smaller effective system size than the true size, hence the model under-predicted generation on normal days. FIG. 2B, by contrast, depicts the same asset's daily production 201 (solid line) alongside the expected production 203 (dashed line) generated by a model according to the present disclosure (using PSO with a quantile cost function). Here, the predicted values track the actual values very closely with no persistent bias. The model using quantile-based fitting correctly identified the asset's true capacity and characteristics, essentially ignoring the anomalous dips in the historical data. As a result, its predictions neither consistently under- nor over-shoot the actuals. This improved alignment would also be reflected in a stable performance ratio near unity for the period, indicating the asset is performing as expected when modeled correctly.

[0027] The robust hardware modeling described herein provides tangible benefits for asset management and operations. By improving the accuracy of digital twin simulations, the system enables more reliable detection of underperformance in live operations. For example, if during live operations the asset's output falls significantly short of the digital twin's prediction (after accounting for the current weather), anAttorney Docket No. 21830-160617-USoperator can be confident that something is wrong with the asset itself. This is because the model is no longer a significant source of error; the digital twin is accurate, so any large discrepancy between predicted and actual performance is a clearer signal of a true anomaly requiring attention (such as new shading, a component failure, or excessive soiling). In contrast, with prior models, it was difficult to distinguish whether a performance discrepancy was due to a bad model assumption or an actual asset issue. With the present accurate modeling, any substantial deviation triggers an alert with high confidence that the asset needs inspection or maintenance. This leads to faster maintenance responses and improved overall asset uptime. Moreover, by eliminating the need for manual collection of hardware specs or on-site inspections to build a digital twin, the disclosed method lowers the barrier to deploying advanced monitoring on existing fleets of energy assets. Asset owners or operation and maintenance service providers can onboard assets into the system with just performance data and location, and obtain a high-fidelity model of each asset. This has the potential to streamline operations for large portfolios where documentation may be incomplete, leveraging data-driven inference to fill in the gaps.

[0028] While the detailed examples herein focus on solar PV systems , the principles are broadly applicable to other types of energy production assets. Any system where performance is measurable and dependent on configuration could potentially be greybox modeled in this fashion. For instance, wind turbine performance data combined with historical wind speed records could be used to infer characteristics like blade length or generator capacity. Similarly, for a battery storage system, its charge / discharge data might reveal its storage capacity and efficiency parameters. Thus, the systems and methods described provide a general framework for data-driven inference of hardware specifications across various energy domains, not limited to solar.

[0029] In some embodiments, the system includes additional features for data preprocessing and model validation to ensure robust performance. For example, recorded energy production data can be preprocessed using a time-series "non-Attorney Docket No. 21830-160617-UScommunication" detection algorithm to handle missing or incomplete data records. In particular, the system automatically identifies days or intervals where data is missing due to data acquisition / communication outages and fills those gaps appropriately, while distinguishing them from periods of zero generation. The preprocessing may operate as follows: The historical data is segmented by day (daily "buckets"). The algorithm iterates through every day in the expected time span of the input dataset. If an entire day's data is completely missing (no readings at all for that day), the algorithm labels that day as a communication downtime (NonComm) day and may insert null values for that day to indicate no data was recorded. Essentially, the day is marked as a missing-data day rather than assuming zero production.

[0030] If there is data for a given day but no energy production during daylight hours, this suggests the asset was not reporting during the day (since normally some production would occur if the asset was active). In this case, any missing data points on that day are filled with null values (NonComm) to indicate a communication gap, rather than treating them as zero production. (A day with only nighttime values or incomplete data around daylight is treated as a special case of communication loss during the day.)

[0031] If a day has some recorded energy generation during daylight hours (indicating the asset was reporting and producing at least part of the day), then any missing data points during daylight hours on that day are filled with zero values (ZeroGen) to indicate periods when the asset was monitored but showed no production. Missing points at night on such days can be left as null or treated as inconsequential, since zero production at night is expected and a missing reading at night does not affect the modeling (nighttime data is typically not used for solar performance fitting).

[0032] By preprocessing in this manner, the integrity of the dataset is preserved: the algorithm differentiates true zero-generation events from data dropouts. This prevents the training process from confusing missing data with legitimate zero-output periods, thereby contributing to a more accurate model fit. The approach ensures that periods ofAttorney Docket No. 21830-160617-USno sun (night) or downtime are correctly handled so that they do not skew the optimization or simulation steps.

[0033] Once the digital twin is generated based on the inferred hardware model, the system can utilize it for enhanced asset monitoring and performance validation. In one embodiment, the digital twin's ongoing predicted energy output is continually compared with the actual measured output to compute a performance ratio (PR) or similar metric in real time. This PR time series is used both to validate the accuracy of the selected hardware model's predictions and to monitor the asset's health going forward. For example, the computed PR can be compared against an expected baseline or threshold: if the PR remains within an acceptable range (indicating the digital twin's predictions match reality within tolerance), the hardware model is considered validated and the asset is performing normally. In contrast, if large deviations in PR occur over time, it could signal either that the model has become inaccurate (perhaps due to a significant change in asset behavior outside the training period's scope) or that the asset's performance has changed due to a new issue (warranting further investigation). In practice, once the model is validated, a sudden drop in PR on a certain date would alert the operator to a potential hardware fault or environmental change (like an outage or new shading) occurring at that time, whereas a gradual drift might indicate degradation or fouling.

[0034] The system may present these modeling and validation results through a userfacing monitoring interface. In some implementations, a visual interface is provided to asset operators or engineers to help interpret the gray-box modeling outcome. This interface can display visualizations such as the convergence behavior of the swarm optimization (for instance, a plot of the quantile cost function value vs. iteration count) and the evolution of the swarm's candidate solutions in the parameter space (e.g., showing how particles' tilt / azimuth / size values converge or cluster over iterations). Such visualizations allow the user to confirm that the algorithm has properly converged and provide insight into the confidence or uniqueness of the identified hardwareAttorney Docket No. 21830-160617-USparameters. The interface can also present the predicted vs. actual energy production curves over the training period (similar to FIG. 2B's comparison) and track the performance ratio or error metrics over time. These tools enable easy monitoring of asset performance and quick detection of anomalies. For example, if the interface shows the PR dropping sharply on a certain date, an operator can easily infer that a potential hardware fault or environmental change (e.g., a large new shade or a failed inverter) occurred around that time and take action accordingly. Meanwhile, consistent PR readings near 1.0 give confidence that the asset is operating well and the model remains accurate.

[0035] Turning to FIG. 3, a block diagram of an example computing system 300 is illustrated, which can be utilized to implement the hardware modeling system and method in various embodiments. Computing system 300 may be a server, a cloud-based virtual machine, a personal computer, or any suitable computing device. As shown, the system 300 comprises one or more processor(s) 302, which execute program instructions, and various supporting hardware components. The processor(s) 302 are coupled to memory 304 and storage devices 308, which together can store the software instructions 306 and data needed for operation. The instructions 306 (e.g., code for data collection, the ML model, the PSO algorithm, etc.) are tangibly embodied on a non- transitory computer-readable medium (such as the memory 304 or storage device 308). The system 300 also includes interfaces 312 (which could include network interfaces for data communication), input / output ports 314, and a transceiver or communication module 316 for exchanging data with external systems or sensors. In practice, the recorded energy production data and weather data can be received via these interfaces (from data acquisition systems or databases), and the predicted results or alerts can be output through them (to user interfaces or other systems). These components communicate via an internal bus 310. In some embodiments, the hardware components of system 300 provide the infrastructure for executing the steps of processAttorney Docket No. 21830-160617-US100 under control of the stored instructions, thereby comprising a special-purpose system for hardware modeling.

[0036] Overall, the disclosed system provides a way to generate a reliable digital twin of an energy production asset when the hardware specifications are incomplete or unknown. Various embodiments described here provide more accurate energy production predictions and more stable performance monitoring compared to previous methods. By avoiding reliance on hard-to-obtain hardware documentation, these methods lower the barrier to deploying digital twins for legacy or third-party assets and improve the ability to maintain and optimize such assets' performance over time.

[0037] Those skilled in the art will appreciate that the embodiments described above can be modified or varied without departing from the scope of the invention. For example, specific parameters in the modeling process (such as the chosen quantile for the cost function, the ranges for hardware parameters, or thresholds for detecting data gaps) may be tuned or selected differently for different implementations or asset types. Additional data sources or machine learning techniques could be integrated to enhance the model (for instance, incorporating more sophisticated weather normalization, using a hybrid optimization approach, or modeling assets with multiple sub-arrays if needed). The overall architecture can scale to fleets of many assets, with parallel processing or cloud deployment to handle large volumes of data. All such modifications and extensions are considered within the ambit of these teachings. The invention, therefore, is defined by the following claims rather than by the specific examples provided in the foregoing description.

[0038] Further aspects of the disclosure are provided by the subject matter of the following clauses:

[0039] A system for hardware modeling of an energy production asset, the system comprising a processor and a machine-readable medium storing instructions that, when executed by the processor, cause the processor to receive recorded energy production data of an energy production asset and weather data associated with a period of theAttorney Docket No. 21830-160617-USrecorded energy production data; simulate, using a trained machine learning algorithm, simulated energy production data for a plurality of candidate hardware models using the weather data as input, wherein the plurality of candidate hardware models are selected iteratively with a swarm optimization algorithm configured to minimize a quantile cost function that quantifies a difference between the simulated energy production data and the recorded energy production data; identify a selected hardware model for the energy production asset based on a convergence of the swarm optimization algorithm, the selected hardware model corresponding to simulated energy production data with a minimized cost as determined by the quantile cost function; and generate a digital twin of the energy production asset based on parameters of the selected hardware model, the digital twin being configured to output predicted energy production for the energy production asset.

[0040] The system of any preceding clause, wherein the swarm optimization algorithm comprises a particle swarm optimization (PSO) algorithm configured to iteratively refine candidate hardware models based on feedback from prior simulations.

[0041] The system of any preceding clause, wherein the trained machine learning algorithm is trained using prior energy production data from a plurality of solar energy production assets.

[0042] The system of any preceding clause, wherein the energy production asset is a solar photovoltaic system.

[0043] The system of any preceding clause, wherein the trained machine learning algorithm uses a simplified physical model of the solar photovoltaic system characterized by a single tilt angle and a single azimuth angle, with only an adjusted system size, the tilt angle, and the azimuth angle as parameters to be determined by the swarm optimization algorithm.

[0044] The system of any preceding clause, wherein the swarm optimization algorithm is configured to search for the candidate hardware model within a bounded parameter space defining a tilt angle between 0° and 45°, an azimuth angle between 0° and 360°,Attorney Docket No. 21830-160617-USand a system size between 85% and 115% of a nominal system size of the energy production asset.

[0045] The system of any preceding clause, wherein the plurality of candidate hardware models are generated within an unbounded parameter space, and constraints are applied based on available asset information associated with the energy production asset prior to iteration.

[0046] The system of any preceding clause, wherein the quantile cost function uses a quantile corresponding to a median of the energy production asset data.

[0047] The system of any preceding clause, wherein the recorded energy production data is preprocessed using a time-series non-communication detection algorithm that identifies days with missing energy data and fills in missing values by inserting null values for periods of missing communication and zero values for periods of zero generation during daylight.

[0048] The system of any preceding clause, wherein the instructions further cause the processor to compute a performance ratio (PR) for the energy production asset using the predicted energy production from the digital twin and the recorded energy production data, and to validate the selected hardware model's predictions by comparing the computed PR against a baseline or expected performance ratio.

[0049] The system of any preceding clause, further comprising a monitoring interface configured to display a visualization of the convergence of the swarm optimization algorithm, the visualization including a plot of quantile cost function values over successive iterations and an indication of swarm member positions in a parameter search space.

[0050] The system of any preceding clause, wherein the digital twin is configured to output predicted energy production values for use in asset performance monitoring, anomaly detection, or maintenance planning.

[0051] A method for hardware modeling of an energy production asset, the method comprising receiving recorded energy production data of an energy production assetAttorney Docket No. 21830-160617-USand weather data associated with a period of the recorded energy production data; simulating, with a trained machine learning algorithm, simulated energy production data for a plurality of candidate hardware models using the weather data as input, wherein the plurality of candidate hardware models are selected iteratively with a swarm optimization algorithm configured to minimize a quantile cost function that quantifies a difference between simulated energy production data and the recorded energy production data; identifying a selected hardware model for the energy production asset based on a convergence of the swarm optimization algorithm, the selected hardware model corresponding to simulated energy production data with a minimized cost as determined by the quantile cost function; and generating a digital twin of the energy production asset based on parameters of the selected hardware model, the digital twin being configured to output predicted energy production for the energy production asset.

[0052] The method of any preceding clause, wherein the swarm optimization algorithm comprises a particle swarm optimization (PSO) algorithm configured to iteratively refine candidate hardware models based on feedback from prior simulations.

[0053] The method of any preceding clause, wherein the trained machine learning algorithm is trained using prior energy production data from a plurality of solar energy production assets.

[0054] The method of any preceding clause, wherein the energy production asset is a solar photovoltaic system.

[0055] The method of any preceding clause, wherein the trained machine learning algorithm uses a simplified physical model of the solar photovoltaic system characterized by a single tilt angle and a single azimuth angle, with only an adjusted system size, the tilt angle, and the azimuth angle as parameters to be determined by the swarm optimization algorithm.

[0056] A non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to receive recorded energy productionAttorney Docket No. 21830-160617-USdata of an energy production asset and weather data associated with a period of the recorded energy production data; simulate, with a trained machine learning algorithm, simulated energy production data for a plurality of candidate hardware models using the weather data as input, wherein the plurality of candidate hardware models are selected iteratively with a swarm optimization algorithm configured to minimize a quantile cost function that quantifies a difference between simulated energy production data and the recorded energy production data; identify a selected hardware model for the energy production asset based on a convergence of the swarm optimization algorithm, the selected hardware model corresponding to simulated energy production data with a minimized cost as determined by the quantile cost function; and generate a digital twin of the energy production asset based on parameters of the selected hardware model, the digital twin being configured to output predicted energy production for the energy production asset.

[0057] The non-transitory computer-readable medium of any preceding clause, wherein the swarm optimization algorithm comprises a particle swarm optimization (PSO) algorithm configured to iteratively refine candidate hardware models based on feedback from prior simulations.

[0058] The non-transitory computer-readable medium of any preceding clause, wherein the trained machine learning algorithm is trained using prior energy production data from a plurality of solar energy production assets.

[0059] Those skilled in the art will appreciate that the embodiments described above can be modified or varied without departing from the scope of the invention. The specific thresholds (correlation values, charge ratio percentages, count of zero readings, etc.) can be tuned for different types of installations. Additional statistical tests or machine learning models could be incorporated to enhance detection. The architecture can scale to fleets of thousands of assets, with parallel processing of data. All such modifications are considered within the ambit of these teachings, as the invention isAttorney Docket No. 21830-160617-USdefined by the following claims and their equivalents, rather than the specific examples given in this description.Attorney Docket No. 21830-160617-US

Claims

What is claimed is:

1. A system for hardware modeling comprisinga processor;a machine readable medium storing instructions that, when executed by the processor, cause the processor to:receive recorded energy production data of an energy production asset and weather data associated with a period of the recorded energy production data;simulate, with a trained machine learning algorithm, simulated energy production data for a plurality of candidate hardware models using the weather data as input, wherein the plurality of candidate hardware models are selected iteratively with a swarm optimization algorithm configured to minimize a quantile cost function that quantifies a difference between simulated energy production data and the recorded energy production data;identify a selected hardware model for the energy production asset based on a convergence of the swarm optimization algorithm, the selected hardware model corresponding to simulate energy production data with a minimized cost as determined by the quantile cost function; andgenerate a digital twin of the energy production asset based on parameters of the selected hardware model, the digital twin being configured to output predicted energy production for the energy production asset.

2. The system of claim 1, wherein the swarm optimization algorithm comprises a particle swarm optimization (PSO) algorithm configured to iteratively refine candidate hardware models based on feedback from prior simulations.

3. The system of claim 1, wherein the trained machine learning algorithm is trained using prior energy production data from a plurality of solar energy production assets.Attorney Docket No. 21830-160617-US4. The system of claim 1, wherein the energy production asset is a solar photovoltaic system.

5. The system of claim 4, wherein the trained machine learning algorithm uses a simplified physical model of the solar photovoltaic system characterized by a single tilt angle and a single azimuth angle, with only an adjusted system size, the tilt angle, and the azimuth angle as parameters to be determined by the swarm optimization algorithm.

6. The system of claim 4, wherein the swarm optimization algorithm is configured to search for the candidate hardware model within a bounded parameter space defining a tilt angle between 0° and 45°, an azimuth angle between 0° and 360°, and a system size between 85% and 115% of a nominal system size of the energy production asset.

7. The system of claim 1, wherein the plurality of candidate hardware models are generated within an unbounded parameter space, and constraints are applied based on available asset information associated with the energy production asset prior to iteration.

8. The system of claim 1, wherein the quantile cost function uses a quantile corresponding to a median of the energy production asset data.

9. The system of claim 1, wherein the recorded energy production data is preprocessed using a time-series non-communication detection algorithm that identifies days with missing energy data and fills in missing values by inserting null values for periods of missing communication and zero values for periods of zero generation during daylight.

10. The system of claim 1, wherein the instructions further cause the processor to:Attorney Docket No. 21830-160617-UScompute a performance ratio (PR) for the energy production asset using the predicted energy production from the digital twin and the recorded energy production data; and validate the selected hardware model's predictions by comparing the computed PR against a baseline or expected performance ratio.

11. The system of claim 1, further comprising a monitoring interface configured to display a visualization of the convergence of the swarm optimization algorithm, the visualization includes a plot of quantile cost function values over successive iterations and an indication of swarm member positions in a parameter search space.

12. The system of claim 1, wherein the digital twin is configured to output predicted energy production values for use in asset performance monitoring, anomaly detection, or maintenance planning.

13. A method for hardware modeling of an energy production asset, the method comprising:receiving recorded energy production data of an energy production asset and weather data associated with a period of the recorded energy production data;simulating, with a trained machine learning algorithm, simulated energy production data for a plurality of candidate hardware models using the weather data as input, wherein the plurality of candidate hardware models are selected iteratively with a swarm optimization algorithm configured to minimize a quantile cost function that quantifies a difference between simulated energy production data and the recorded energy production data;identifying a selected hardware model for the energy production asset based on a convergence of the swarm optimization algorithm, the selected hardware model corresponding to simulated energy production data with a minimized cost as determined by the quantile cost function; andAttorney Docket No. 21830-160617-USgenerating a digital twin of the energy production asset based on parameters of the selected hardware model, the digital twin being configured to output predicted energy production for the energy production asset.

14. The method of claim 13, wherein the swarm optimization algorithm comprises a particle swarm optimization (PSO) algorithm configured to iteratively refine candidate hardware models based on feedback from prior simulations.

15. The method of claim 13, wherein the trained machine learning algorithm is trained using prior energy production data from a plurality of solar energy production assets.

16. The method of claim 13, wherein the energy production asset is a solar photovoltaic system.

17. The method of claim 16, wherein the trained machine learning algorithm uses a simplified physical model of the solar photovoltaic system characterized by a single tilt angle and a single azimuth angle, with only an adjusted system size, the tilt angle, and the azimuth angle as parameters to be determined by the swarm optimization algorithm.

18. A non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to:receive recorded energy production data of an energy production asset and weather data associated with a period of the recorded energy production data;simulate, with a trained machine learning algorithm, simulated energy production data for a plurality of candidate hardware models using the weather data as input, wherein the plurality of candidate hardware models are selected iteratively with a swarm optimization algorithm configured to minimize a quantile cost function that quantifies a difference between simulated energy production data and the recorded energy production data;Attorney Docket No. 21830-160617-USidentify a selected hardware model for the energy production asset based on a convergence of the swarm optimization algorithm, the selected hardware model corresponding to simulated energy production data with a minimized cost as determined by the quantile cost function; andgenerate a digital twin of the energy production asset based on parameters of the selected hardware model, the digital twin being configured to output predicted energy production for the energy production asset.

19. The non-transitory computer-readable medium of claim 18, wherein the swarm optimization algorithm comprises a particle swarm optimization (PSO) algorithm configured to iteratively refine candidate hardware models based on feedback from prior simulations.

20. The non-transitory computer-readable medium of claim 18, wherein the trained machine learning algorithm is trained using prior energy production data from a plurality of solar energy production assets.Attorney Docket No. 21830-160617-US

Images