 And please welcome Tatiana Kimova, if I'm not mistaken, with the speech about the innovative breakthrough, first use case on OSDU with total energies. Please welcome. Hello. Hello, dear all. Thank you for staying with us. I know that a lot of people have to leave because of the plane constraints, so happy to see you here. And very happy to present you as a topic, the innovative breakthrough first use case in OSDU with total energies. So I'll present this topic today on behalf of Total Energies. I'm the data platform lead of OSDU team in Total Energies and the Baptiste today. He is a technical lead of OSDU team and he will be happy to help me to answer your very technical questions that I'm sure we'll have at the end of the presentation. So we discussed a lot during the conference about the OSDU and I'm sure that you know what is this and let's quickly summarize why OSDU and what are the main pain points we are facing in our current data ecosystem today. So the main point points that the data is loaded in different databases, in different softwares, in different formats according to different data models and it's very complicated to share the data. It's very complicated to collaborate. It's complicated to collaborate inside the same company but also with the third parties, with our partners, with the governments and also this siloed ecosystem today and we are really convinced about this. It is slow down the adoption of the new technologies and new softwares. So we believe that OSDU adoption will help to tackle these pain points and our main purpose of this OSDU use case which I'll present to you today is to show that OSDU may help to improve the collaboration. The collaboration between different MTS across different countries. So also it is the standardization because this is a standard data model which is proposed and which is adopted by the softwares. Also it is the acceleration so we know where the trusted data is stored so this accelerates also the decision-making process and all of these purposes of our use case were successfully achieved at the end of our development. So why we are talking the Suriname use case? So when we wanted to start this very first use case on the OSDU, so on which real use case we may do it. We didn't want to do the production use case in the moment but our purpose was to show what are the advantages of the data platform which total energies may benefit from. So the Suriname use case because it is a very visible project. So the block 58 here, it's a golden block and the Suriname total energy is the operator and this is a transverse project between the exploration and the development. So the team was spread across different locations in Suriname affiliate in Houston. We have the exploration hub there and the France team in Paris and Poe. So multi-softwares and I'll show you exactly which softwares we are talking about. It was a green field so we have very limited legacy data so it's better for the project and the initial scope was really simplified. It was centered on the well data, the most mature data type within OSDU community today and also we wanted to have the use case across different MTS, across the geo science and the drills. So that's why Suriname use case was selected. So we worked on this project during more or less 10 months and we delivered it in the end of September, 2021. So we worked with different companies on this and you can see here the main streams of our work. So first big stream, it was about the deployment and ingestion. So the framework stream and we worked in close collaboration with Microsoft colleagues on the installation and the deployment on OSDU of the Mercury release in a total Azure platform on Inux secure environment. Also we installed the ingestion framework and we worked with Viper colleagues on this at this time. The second big stream, it was about the accessibility, the internal accessibility and also the external accessibility because for us it was very important to show that the data platform adoption may help to accelerate and to improve the data sharing with the partners in government. Also the security aspect to be sure that the data platform it is exactly in line with the in compliant with our cybersecurity and confidentiality rules. The big you can see here in the red on the slide streams it's about the connections. So about what connections we are talking about. The connections with our in-house interpretation software like Csmash, CG, it is about the connections with the software drillings for the well-designed before the drilling phase and the truth of the scenario for the trajectory for the drilling. Also it is we worked in close collaboration with Emerson for the geolog connector for our SDU and we did some custom developments in order to tackle the missing of data management tools on the top of the SDU. So we developed the Dropbox which allowed to ingest the well data directly on the data platform and also to share with the third parties. And finally, on the top of the SDU we installed the Universal Viewer and we worked with is also in close collaboration with the INT, with IVAP which allow to have a view on the data which is ingested in the data platform and also to share the data with the third parties. So concretely what was done. So as you saw before why Surinam use case slide so the scope of the project was really limited on the well data. So here you can see in which square which data types is conserving in each connector. So you can see here that some of the softwares used the upload download principle and some of them were directly plugged on the Azure. So for Csmash, ADAP, geolog, IVAP, Dropbox it was the well data but for example within Csmash and ADAP we used the exchange of the custom data type as well, the scenario which we introduced ourselves in order to fit for our business need as it is aggregation of different data types like the well location, trajectory, well marker targets and the poor pressure fracture gradient profile. So for geolog connector it allows today to consume the well log from the data platform in less format. So to do the interpretation and to send the data back in the last format and also the PDF plot. So for the IVAP we tested the visualization of the well trajectories, of the well markers, of the well logs and sharing with the third parties. As for the Dropbox which allows us to ingest in the data platform the well trajectory and the well logs. So for all of these we used their community, APIs and the overall strategy of the total energies is to be as standard as possible with the OSU community code and the API proposed. So we used the well board DMS, we use the well planning DMS for everything related to the well design before the drilling phase and also as I said before we introduced some, our custom schemas for the scenario now to fit to our business need and this is also the advantage of the OSU open codes that we may customize if it's needed for our business purposes. So for sure also it was a question about the entitlement model which we would like to put on the top of OSU data platform. So it was successfully done. We deployed the OSU entitlement V2 model and here you can see the schema. So with access which is granted to the third parties to our partners, government, to the exploration or the development and the team members. So the owners, the viewers according to the entitlement model proposed. So let's have a look quickly in the IT architecture high level overview. So as we saw in the previous slide, so some of the applications which are connected to the data platform are on premise. Some of them are already plugged directly in the style in Azure. And all the interactions inside the data platform and also interactions with the application is done by the OSU community APIs. And also you can see here that there is a C-smash source which was in the Google Cloud. So also in this time we tested the interoperability between different clouds for this use case. So concretely let's have a look what data business workflow we covered in the Surinam use case. So here you can see in this slide three main phases. So phase one and two, it is the pre-drilling phase. It's the preparation of the scenario for the drilling. It's very important here so this collaboration between the geoscientists and the drillers when they're exchanging the scenarios. So including the location, well targets, well markers, and well trajectory and poor pressure fracture gradient profiles. And this is the exchange between them in order to be sure what scenario is agreed, what is a validated plan trajectory. And this is done during these two phases which we covered. And after the scenario is agreed, the drilling phase begins. During the drilling phase, what's happened? So during the drilling phase we have to recover directly the data from the rig. So what we did, so here we can see the Dropbox application. You remember it's a custom application which we developed for this use case because of the data management need. So the on-site geologist from the rig, he dropped the data. We are talking here about the log data, log well drilling data and directional survey on the platform, let's say on the Dropbox. After the operational geologist, he has a look on the data and he validates the data. Once the data is validated, the ingestion mechanism is triggered and data arrives to the data platform. After the petrophysicist, he has to do the Russian interpretation. So he recovers the data directly from the platform using his geolog software. He's doing this, his interpretation and he's pushing data back to the data platform. And after we have our geoscientist, our geoscientist would like to perform the follow-up of the well, so he will consume the data which was validated by the operational geologist in his interpretation project and also he will recover directly from the platform the data, the Russian interpretation data which was pushed by the petrophysicist. So this allow the real collaboration across different sites and across different MTS. And all in all, it's important to share the data with our third parties according to the contracts. And that's why here, the IVAP and ENT also allow this possibility to share the trajectories, to share the logs with the third parties. So, and now I would like to show you the movie which we performed at the end of the Surinam use case which will summarize why we are doing this use case, the feedback from the users and also we will see all these three phases which I show you here on the slide, really how it's working in the applications. So let's start. It's been three or four years that Total Energy is interested in the OSDU ecosystem as well as all the operators and services companies of our industry. The first operational version, the R3 Mercury, was released in March and we wanted to test it in its globality to show the potential of the OSDU on a very concrete case of collaborative work in the field of geoscience and forage. The use case on Inam and Ansible. After installing the Cloud platform on Microsoft Azure, it tried to show the possibility of improving the collaboration between the different members of the project team during the conceptual and engineering phases and considerably reduce the time of definition of a trajectory since then. For this, we connected Sysmash, ADEP, Geologue and IVAP. On Sysmash, I can prepare the well targets, well locations, well markers and well trajectories directly on OSDU as if I were on my local drive. With ADEPT, I get the well target selected on OSDU and I send the trajectory directly to Puy which allows it to be available for colleagues on Sysmash. So what is fantastic is that we can roll back through previous scenarios to compare all the preliminary well locations and well trajectories that were proposed. The OSDU code is open source which allows us to be able to bring our own modifications to manage concrete cases like the management of scenarios. With this system, the data is finally in their place unique in the center of the activities of science. Our software connects to the platform and can access each of its values without even exchanging the modifier which is accessed directly through the interface. It's a real challenge. We also simplified the fun of having data in a forage phase. Each measure on the rig is validated on the platform and then makes it accessible to the whole project team and to our external partners. Hello sirs, my website sent me the data from the RIBF and I just validated them. You should have them in an instant. So on Geoloc, it's good, it's good, I have them with me. And on Sysmash, it's good for me too. I also have them on ADEPT. Thank you Kené, we'll look at it and we'll come back to you. Okay, you're going to go on to Geoloc, Sysmash, ADEPT. It's a very practical question. Our external partners also benefit from access used to the data that we have to share with them now and which are accessible and visualizable both on the Dropbox and on the Vap. The process of liberation of the rain, whether it's the rain of exploration, appreciation or even development is still a challenge. On the one hand, the most disciplined of the teams in charge, the operational processes in game and the very nature of the data. The data platform has allowed us to reduce these blockage points by allowing us to have valid, centralized, accessible and, above all, unique data. Now it's possible and this new platform contributes to the improvement of a collective operational performance. This first use case on the Suriname was focused on the rain data. We also added Sysmic data by working with our colleagues from the Sysmic acquisition, especially by integrating the pre-stacked application. The potential of the data platform is not there. Today, the OSDU community is more than 200 companies, a few 2,000 engineers and developers who deliver hundreds of lines of code every day to cover as many needs in the energy sector as possible. Surface to surface, this is the case of CO2 and new energy such as wind turbines. You understood it, it's an ambitious project around the cloud technology and a new air for total energy in the management of the two of us. And so you saw that this was the feedback of the users who was involved in the test period, also in the development period. And we received really 100% of positive feedback and we consider that Suriname use case, our MVP was a success. So what next after this first step on the OSDU journey? So now we would like to go in the real production use case. We would like to reuse the bricks which were developed during the Suriname use case and to show the real added value on OSDU in production. So we would like to add and connect more softwares and more data types. So being focused still on the well data. So and one of the possible candidates for the new use case is Uganda where we say there is great challenge to follow up more than 400 wells. And also the another challenge here is as we saw today, OSDU does not provide the data management tools on the top of OSDU. And if you would like the data platform to be manageable by the affiliate, for instance, it's a very important point. So we are also looking how we may simplify the daily life to our data managers who will be embarked on the OSDU journey. So that's all for the presentation. And I would like to thank all the companies which were involved in this big project which we did during the 10 months. And for sure I would like also to warmly thank the whole OSDU team in total energies. So thank you very much and you are welcome for the questions.