Logique de décision réutilisable pour les sources d'énergie renouvelables

Dans le deuxième article de cette série, qui a commencé par analyser les opportunités dans les énergies renouvelables nous verrons comment – sans code – vous pouvez utiliser les règles métier comme couche architecturale pour aider à justifier tout solaire

Dans la première partie de cette série j'ai décrit quelques-unes des considérations pour les institutions financières communautaires et régionales (CRFI) qui envisagent de se lancer sur les marchés du crédit solaire et autres sources d'énergie renouvelables. Ensuite, je vais explorer quelques-unes des façons dont les prêteurs peuvent aider les prospects à justifier économiquement ces projets avec Progress Corticon le logiciel de décision numérique conçu pour gérer des règles et des calculs complexes, s'intégrer avec un nombre incalculable de gros sources de données et implémentez le tout sans écrire de ligne de code.

Pour commencer, disons que je veux connaître l'opportunité de capture d'énergie solaire pour un emplacement donné, afin d'informer mon marketing vers une entreprise locale spécifique – dans ce cas, Progress Software. Je veux d'abord m'assurer d'avoir toutes les données nécessaires sur le siège de Progress Software à Bedford, MA. Je vais le faire en utilisant l'API gratuite Google Maps Places .

Il est remarquablement simple d'accéder directement au point de terminaison REST de Google Maps, ainsi qu'à presque toutes les autres API dont je souhaite obtenir des données, directement à partir de mes règles métier. Je peux le faire sans code directement dans Corticon Studio en utilisant le connecteur DirectDirect autonome REST qui présentera les services REST à Corticon comme s'il s'agissait de bases de données relationnelles. En tant que modélisateur de règles, je n'ai pas besoin de comprendre la complexité de la réponse JSON pour commencer à travailler efficacement avec les données.

Dans cet esprit, j'ai créé un nouveau projet de règle vierge et un blanc correspondant Vocabulaire des règles . Maintenant, je vais ajouter ma source de données Maps et automatiser la création de mon vocabulaire de règles basé sur la structure du point de terminaison JSON.

Je vais copier l'URL de base de mon premier appel REST dans le champ" URL REST ". Cette demande récupérera des informations sur Progress de Google Maps.

 https://maps.googleapis.com/maps/api/place/findplacefromtext/json?input=14%20oak%20park%20drive%20bedford&inputtype=textquery&fields=place_id, name, geometry&key= {YOUR_API_KEY} 

Une fois que je suis prêt, je clique sur le bouton " découvrir" . Cela indique à Corticon d'interroger le service REST à l'aide de l'URL REST et des paramètres de requête définis sur la source de données. Le JSON renvoyé être utilisé pour générer un schéma pour mapper JSON du service REST à une représentation relationnelle. Les métadonnées de ce schéma est ajouté au vocabulaire des entités (tables), des attributs (colonnes) et des associations (expressions de jointure). Voyons si «Progress» suffit pour nous fournir les données dont nous avons besoin.

Le connecteur autonome REST mappe le JSON dans une source REST à un schéma de base de données relationnelle pour l'aligner avec le vocabulaire de la règle, puis traduit les instructions SQL en requêtes d'API REST.

Pour gagner du temps, je vais utiliser l'accélérateur de génération de vocabulaire de Corticon pour créer mon vocabulaire basé sur la représentation relationnelle du point de terminaison. De cette façon, toutes les entités et les attributs de mon vocabulaire seront automatiquement mappés pour remplir avec des données en direct de le point de terminaison REST pour chaque demande de service de décision.

Après avoir sélectionné la commande de menu Vocabulary> Popula te Vocabulaire de la source de données, un assistant s'ouvre pour vous permettre de revoir la source de données avant de créer les éléments de vocabulaire, où vous pouvez sélectionner les tables et les colonnes à créer en tant qu'entités et attributs.

Avant de modéliser les règles, je vais créer un nouveau flux de règles, ajouter une légende de service au canevas de mon flux de règles et sélectionner le point de terminaison REST dans la liste déroulante des propriétés d'exécution.

Ensuite, je vais exécuter un nouveau test de règle par rapport à ce flux de règles, pour m'assurer que les données que je recherche sont renseignées.

Ceci vérifie. Les seules données dont j'avais besoin pour commencer étaient le champ «entrée» pour la demande de l'API Google Maps. Pensez-y comme taper dans la barre de recherche de Google Maps. Même si Progress a des bureaux dans le monde entier, Google n'a pas besoin de plus que ma contribution de Progress Software Bedford.

Voyons maintenant s'il s'agit d'un emplacement intéressant pour un investissement dans un projet d'énergie solaire. J'utiliserai quelques sources pour aider à cette détermination, et je ne présenterai que quelques-uns des innombrables facteurs ayant un impact sur le rendement de l'énergie solaire.

La principale source d'énergie de la Terre est l'énergie rayonnante provenant du soleil, qui est mesurée par l'irradiance solaire. La NASA définit l'irradiance comme «la quantité d'énergie lumineuse d'une chose frappant un mètre carré d'une autre chaque seconde». Ainsi, la variable la plus importante ici est la plus évidente: la quantité d'énergie solaire qui frappe réellement les panneaux solaires.

Il s'agit d'une variable complexe à mesurer, et encore moins à prévoir, car tous les rayons du soleil ne passeront pas directement du soleil à un point donné de la Terre. Il rebondira souvent entre les nuages ​​ou les particules dans l'air avant de finalement se rendre sur Terre où il pourrait être capturé par un panneau solaire. Le total de tout l'irradiance qui se rend à la surface de la Terre est connu comme Global Horizontal Irradiance . Cette mesure englobe à la fois la lumière du soleil qui l'a rendue directement sur Terre et la lumière du soleil qui a rebondi un peu avant de se rendre sur Terre.

Source: National Renewable Energy Laboratory (NREL)

The National Renewable Energy Laboratory (NREL), un laboratoire géré par les États-Unis. Department of Energy, propose une API gratuite qui peut nous indiquer l'irradiance horizontale globale moyenne pour une latitude et une longitude données. Les données sont présentées en utilisant l'unité de mesure kilowattheures par mètre carré par jour. Pour obtenir un référence, j'ai interrogé ce point final avec Postman en utilisant la latitude et la longitude de Miami, FL.

 https://developer.nrel.gov/api/solar/solar_resource/v1.json?api_key= {API_KEY} & lat = 25.7617 & lon = -80.1918 

Cette requête sur Miami renvoie quelques mesures différentes, mais celle qui m'intéresse est Irradiance horizontale globale moyenne ou "avg_ghi":

 
 
 " avg_ghi ": 
" annuel ": 5.17, 



  


               




" mensuel ": 
" jan ": 3.87, 
" feb ": 4.5 5, 
 "mar": 5.64, 
 "apr": 6.54, 
 "may": 6.52, 
 "jun": 5.89, 
 "jul": 6.26, 
 "août": 5,87, 
 "sep": 4,99, 
 "oct": 4,54, 
 "nov": 3,89, 
 "déc": 3,39 
 
 

Mon hypothèse est que lorsque je fais de même pour Bedford, MA, j'obtiendrai des valeurs plus basses, car cela a tendance à être beaucoup plus gris ici qu'à Miami. Mais au lieu de simplement faire une autre recherche Google pour la latitude / longitude du siège de Progress, je veux pouvoir utiliser mon précédent appel API au point de terminaison Google Maps pour remplir la latitude / longitude pour moi, de sorte que je n'ai qu'à fournir une entrée, «Progrès».

Je vais le faire en exploitant trois points de terminaison REST, chacun se rattachant à une entité, mon «Project_Site». Mon premier appel d'API sera un Google Place Search qui me renverra un PlaceID que je pourrai ensuite utiliser lors d'appels ultérieurs à d'autres API Google. Mon deuxième appel sera au Google Place Details où je demanderai des données telles que la latitude / longitude pour le PlaceID donné. Enfin, je vais prendre cette sortie de latitude / longitude et l'utiliser comme entrée pour l'API de données solaires NREL.

Je n'ai pas besoin de créer ou de mapper manuellement mon vocabulaire de règles à la structure de données de ces points de terminaison REST, Je peux utiliser l'outil de génération de vocabulaire pour cela. De cette façon, Corticon générera également automatiquement les expressions de «jointure» qui définissent les requêtes au service REST. Même après m'être connecté à et défini les connexions entre mon vocabulaire de règles et trois services REST différents, je n'ai besoin que de deux entités différentes dans mon vocabulaire. Au moment de l'exécution, Corticon sortira et récupérera les données qui correspondent à chacun des attributs sous les entités (Project_Site et NREL_SOURCES) à partir de leurs sources de données respectives. Une fois mon vocabulaire créé et mappé, je vais créer un flux de règles qui organisera mes appels REST et j'ajouterai quelques règles pour documenter les données remplies à partir de ces services externes.

Maintenant, je veux tester pour voir si cela fonctionne réellement comme prévu. un rappel, je veux obtenir des données sur l'énergie solaire potentielle qui pourrait être capturée pour un emplacement donné, afin d'éclairer les calculs de retour sur investissement pour les investissements solaires. De plus, je veux faire tout cela en entrant seulement une requête de recherche pour un emplacement , comme je le ferais dans Google Maps.

Ça a marché! Comme indiqué dans la colonne "Entrée" de gauche, les seules données que j'ai fournies dans mon test de règle étaient mon GooglePlaceSearchInput de "logiciel de progression". Cela suffit à lui seul pour identifier le site avec un placeID, utiliser le placeID pour obtenir les coordonnées du site, puis utiliser ces coordonnées pour récupérer la valeur moyenne de l'irradiance horizontale globale pour ces coordonnées par mois et par an.

Bien qu'il soit décevant de voir la valeur beaucoup plus faible que ce que j'ai vu pour la ville de Miami, cela ne disqualifie certainement pas cela en tant que site. J'ai récupéré et organisé toutes ces données récupérées à partir de diverses API dans une seule entité dans mon vocabulaire de règles, le Project_Site, le tout sans écrire une ligne de code ou définir manuellement des connexions et des mappages. Je pourrais aller dans d'innombrables autres directions à partir d'ici, compte tenu de la facilité avec laquelle je continue à tirer parti de ces services REST dont je n'ai pas besoin pour me maintenir. Je pourrais, par exemple:

Le financement des investissements dans les énergies renouvelables comporte de nombreuses variables complexes, mais les barrières financières à l'entrée sont beaucoup moins lourdes qu'elles ne l'étaient autrefois. À l'instar de la façon dont les États gèrent des marchés complexes pour connecter les prestataires de soins de santé aux membres des régimes de santé subventionnés par le gouvernement aux États-Unis, les marchés pour connecter les consommateurs au financement des énergies renouvelables subventionné par le gouvernement arrivent à maturité à l'échelle nationale. Les nouveaux entrants sur ces places de marché peuvent solidifier leur position sur le marché en adoptant le même principe technologique utilisé par les principaux acteurs des places de marché de la santé: sans code, haute performance, décision numérique.

Pour voir comment Corticon peut vous aider à livrer rapidement des projets comme ceux-ci, contactez-nous pour planifier une démonstration en direct gratuite ou inscrivez-vous pour un essai gratuit aujourd'hui.

Annexe A démo