Just a few words to us about my company. We are a young and small size company from Lebanon Island, which is a French island over Indian Ocean. We develop innovative solutions for energy transition and more on solar energy.

We have a continuous work on research and development, but we also have clients and we provide them solutions through software as a service. We work in two main categories, the forecasting part, which consists of giving information about the production of a nuclear plant or a country on the next hour or the day after.

And the second part, which I will talk about today, is the monitoring part. It consists of giving information about the nuclear plant condition. Here is a map of the instant photovoltaic power capacity last year.

The data comes from International Energy Agency. The green dots represent the PV production of big countries. And the color is related to the production of the area of the country. And this is to show that even if we are in Indian Ocean, our market is everywhere and we have to provide global solutions.

Why do the PV plants need to be monitored? Imagine a PV plant owner who wants to know if its PV plant goes away or not. It will calculate its performance ratio, which is the ratio between real energy output versus the theoretical energy it should have produced.

If this ratio is low, it will have to identify if it comes from a natural program like bad weather because of the protein in the head.

Or if it comes from material damages like aging of the panels and things like this. And this will need an immediate call for action. Most of the PV plants are already instrumented with ground sensors to evaluate the weather impact. But they are fail-able.

There can be material damages, shadowing and drift of the sensor over time. Here you can see a graphic made to visualize time series. You can see on the horizontal axis the evolution of the days and vertical axis the evolution during the day. The color is related to the irradiance on the ground from blue to zero for the low values and red for the high values.

And you can see a wire over the sensor. So there are things like this which can affect ground sensors. So this space monitoring project consists of giving a global solution using satellite imagery to have irradiance estimation on the ground.

Plus autonomous and mobile sensors on the ground to have local phenomena capture. And this will be mixed on a GIS and served as a client through a web service.

So I will talk first about how we can retrieve irradiance from satellite imagery. We use a method called SunSAT. It's based on Elusat-2 method. And it uses raw satellite imagery from geostationary satellites.

And we want at the end GHI, which means global horizontal irradiance maps. And for this we will have to remove the ground effects and also other parameters such as atmospheric turbidity and perspectives. So that's the workflow.

We use geostationary satellite images because obviously it can see the clouds. We use visible and infrared channels. Moreover, this satellite offers regular scans and spacing time consideration. Here you can see on the right a table providing the space-time resolution.

So it's sub-hourly scans and around kilometer at equilateral. And one last interest of geostationary image is that they are very stable over time. As the sensors are not affected by the pollution or things like this.

And here you can see the coverage of each satellite image. So I say that we also need auxiliary data. The first one is the ground albedo to map effects. We use MODIS products. And here you can see the illustration, albedo map.

And you can see that the details in the snow have a higher reflectance than other countries. And to project the data on the ground we will use SRTM data. Just for the illustration you have on the right, the SRTM model for the region items.

And we also need atmospheric turbidity model. We use link turbidity. You can see on the right a curve of GHI which under a clear sky and with different link turbidity factor.

You can see that it can impact the production. So this was a theory. Let's see the technical workflow which uses map server for GIS and GNI. We can find on the top the different satellite image providers. So it's raw data and we cross them into our local data field.

On the other side we have auxiliary database based on GIS. And the data are raster and celled with web coverage service with map server. And our differences at servers which are mainly C programs will mix these two sources of data.

And end with images and geotransform parameters array to georeference data. Just for the illustration you can see on the left an image from MSG IODC which you can see in the other version.

And the up is down. The north is down because the satellites scan from the south to the north. I'll just write some line of course we use to georeference data. You can see that we have different satellites with different geos production. And we wanted to have a unified system so we use the GIS 845.

So for this we need the two functions of GDAG. The first one is to georeference data with a C flag, F flag, C off, L off parameters. And then GDAG well which allow us to have a unified system.

Now we have a geotiff. We store the data into a post-respo G solution because of the rest of the world functions which is very helpful for us.

For now we just store our zone of interest because it's a big challenge to store the full disk data. And it's another project we are working on. But for now we already have a data model which is scalable and easy to maintain. And we take perfect of the inheritance and schemas of our life.

We have master table which has a master definition. And all satellites have inheritance from this table. And we separate real time from historical data. So we can distribute everything these tables on ourselves.

Another point of using post resolution is that we can use procedural functions. We can use it through PLPG SQL language and use filters with map algebra. And we also connect C functions directly into the database.

This is still in research. Here I just provide an example of using procedural functions to retrieve the real time stamp of a PC. So here you can see a row of full disk image from satellites. And it takes approximately 12 minutes for the satellite to scan from the south to the north.

So the time stamp here won't be the same as the beginning. So we use latitude information of a pixel of interest to retrieve the real time stamp. So what can we do with this?

Obviously we can use extra time series. That's what interest us. So time series on our points of interest. We go from some hourly instant power in watt per square meter to correlative energy. Which will be an information useful for the PV plant owner. So you can see on the right bar plots showing in red GHI measured.

Real GHI measured. Versus in blue, the GHI have been produced under a clear sky. And we also are able to make up to date maps of GHI.

Here we use PUBG solutions with maps of web map service in time information. And deflect. So yes, using satellite imagery is a good tool to have an estimation of the region of the ground.

But a local human map can be seen by a satellite. You can see on the left two images. One from MSG IODC and another one from Sentinel. Which is an orbital satellite.

And you can see, you can guess that some plots which are seen by Sentinel won't really be unseen by MSG. If you go through time, ground sensors would have seen little peaks. But the satellite, just the shape of this.

So there is a reason why we also developed our own ground sensors. So we can have a better knowledge of what happens on our points of interest. There are different sensitivities and prices of sensors. Pure nanometers, pure nanometers and reference cells. And we decided to buy an autonomous one with reference cells.

Because it's a widespread panel. So I took first a measure of irradiance, humidity and temperature. And as it's in real time, we can react in case of a problem on the sensor.

So here is a map of the sensor we get data from. The green dots represent our sensors. So we have real-time access. And the blue one, we receive them with delays. It comes from a global network of sensors.

The data from ground sensors are rated checks before being inserted into a database. We use R routine, we have our own R package to make this data check. And you can see on the right, a graphic I showed just before. But with the technical and impossible values removed,

the same license and calculation is ready so we can remove the night values, which doesn't make sense. And that's it. And now we store them into a basic SQL database, but we are working on other solutions, such as InfuseDB, Work10.

Work10 is a NoSQL database with geolocation interest. And something which was released a few months ago is TimescaleDB, which is very promising because it's an extension of Postgres support, which would allow us to keep using Postgres for this solution, but for better management of time.

Hila just writes some line codes for basic usage of TimescaleDB. So it's very easy to use. And on the bottom you have a screenshot of Grafana, which is a visualization tool that is easily connected to InfluxDB.

So we have satellite estimation, ground estimation, so how can we mix and go? The first solution is to use a simple and empirical method with a polynomial regression, which requires a few months of measurements

on our point of interest, for example, treatment. And then we can apply this regression to our satellite estimation, historically or in the future.

Another way to use both the two sources of data is with Copriging. As you can see on the left, different configuration we can use for Copriging. It's from communication. And in our case we can use the first one. We use this for use case in the Union Island,

where we had different sensors on the ground, satellite images, but we wanted to have information on the point which was not instrumented. So we use a method of Copriging to have better knowledge of what happened to the ground on our points of interest. We use different libraries to do this.

And another point of having two sources of data is that if one source is missing, we have the other one. On the right you can see a graph you can show before,

but with some holes. And this was because the sensor had a network program, so we didn't have ground measurements, but we had satellite estimations to fill this program. And another point is that if there are technically possible values of the sensors,

but obviously ground values, like this was a black line graphic, we can react by comparing ground sensors and satellites and saying that it's not possible. And in this case it was because the ground sensors were still wested, so we had to call the client,

so it could make the sensor more horizontal. So here is a summary of what we say. So on the left you have the different satellite estimations, the range of ground sensors,

and the pros and cons of each solution. A satellite estimation can give a global coverage, which is important to have global solutions. And ground sensors help to refine the satellite estimations. Some of them are away from our point of interest,

so that's the reason why we provide our own sensors to refine the estimation of the zone around our pigments of interest. So we come from a complex back end with different data sources, homogenization, different storage solutions,

and movements, et cetera. And we go to a simple user-friendly front end for the client. You can see a screenshot of the application provided to the client. It's backed with our Shiny server.

And this workflow is just possible thanks to ASGIO solutions, such as Jidar for the homogenization of the data, Mapserver for the distribution, and VAGES for the storage. And that's it. Thank you.

Yeah, sure. So you guys have five minutes Q&A session. If you have something, it was quite a fairly technical presentation, so I'm sure you have a couple of questions to ask from her. You have. You can go ahead. And also you used, like, one of the satellites,

like four satellites or something. Are all satellites data free and available? No, we pay for them. We can have access to historical data, but if you want them in real time, we have to pay. Okay, so historical is free.

Yeah, for the link to humidity, do you use something already existent, or you build up your... Yes, for now we use a product, which is an annual average. So we have one map per month.

It's average of different years. Okay, good. But we are working on a better solution, 12 beta per inch, because it's a range solution, it's around 10 kilometers, which is not accurate. I have one more question. And the sensors that you're using, what spectral range?

Of the satellite media? No, no, no, the stations. What stations? Yeah. It's reference cells, so it shows, it sees what the PV panel sees, and it's visible in the infrared. I don't remember the wavelength,

but it's exactly the same as you can see. Okay. So you're collecting data in a very precise way. Why is it important for your use case, I guess, to have the data be so precise? Because, as you saw just before,

as a bar plot, remember, there's a big impact of weather on the production of the PV panels. So it's very important for us to refine our estimations to have better information for our clients. And I showed you just one use case, but you can imagine that each of these tools we use

are used also for focusing parts, and it's very important to have very precise measurements. So do you always, do the ground stations always remain there, or once you get a feel for how to adjust them, then they don't really have to be there, you get a good enough estimate?

That's a good question. We do this for some clients. We provide them the sensor for a few months, and then we get it back. And we have a reference parameter next to our work, so we are able to put it again and be sure that it didn't drift over time.

That's it? Okay. Well, we have like ten more minutes before the next session, the next opportunity, sorry. So if you want to have a walk or something,

you can. I can ask that question. Do you see, how long does the, when you're feeding real-time data, how long does it take for it to generate the product at the end, in real time? How much is the delay? For the satellite. Yeah. So the satellite starts measuring at zero zero. We have the data at 12. Right. And then the process takes approximately three minutes,

so we have it at 15. And that's already including the ground station data as well, right? No, that's just satellite estimation. Okay. Thanks. Thank you. Good job.