GRIF | Our origins

What were the reasons behind your move to TotalEnergies?

I joined Total (now TotalEnergies) from Elf in 1981, after having spent 10 years working for the French Atomic Energy Commission (CEA), in the Probabilistic Safety Studies office (which became PSS and is now the IRNS - Institute for Radiological Protection and Nuclear Safety).

At that time, the CEA was conducting predictive and preventive studies on nuclear facilities (plants, submarines, etc.). Our main role was to evaluate the probability of accidents in power plants using techniques such as fault trees and event trees. To ensure our calculation assumptions were sufficiently pessimistic, we added constraint upon constraint, to the point of simulating situations that could not physically exist in the real world. I was getting a little fed up with it all. And then, a request to conduct a reliability analysis landed on my desk, on drilling rigs with acid gas (H2S) near Pau (Pyrénées-Atlantiques), subcontracted by Elf.

At that point, reliability analyses were not yet standard practice in the oil industry. I thought it would be a really interesting subject to explore. When the first study was complete, I asked if I could join the company. After a few interviews and tests, I was hired to work in the Reliability department of Elf DGEP. ;

Were reliability studies a new discipline for Elf? 

Not exactly, for example, studies had already been carried out for the northeast sector of the Grondin field (Gabon) in 1975. And when I started at Elf, we had two teams with six or seven reliability specialists, whose work was divided between processes and research. The Safety and Production Departments conducted their own independent reliability analyses, sometimes on the same systems. This type of organization had its limits because different results could be obtained from the same study subjects, but they would not address the same aspects (for example, safety versus availability).

During this period, a series of industrial accidents had left their mark on the public conscious and the industry (in particular, the Piper Alpha explosion in Scotland, the Macondo explosion in the Gulf of Mexico and the sinking of the Prestige in France). Reliability analyses have gradually become a fundamental part of risk management at production facilities.
As time went on and following several restructuring operations where teams were merged and colleagues retired, I found myself managing most of the day-to-day business, before hiring some young recruits who are still working today, after my own retirement in 2009.
 

How did you conduct reliability studies in the 1980s?

Mostly by writing out all our formulas and calculations on paper! Everything was done by hand. I developed the fault trees in the form of a binary structure (outlined by René-Louis Vallée in his treatise on binary analysis), to geometrically extract the possible failure scenarios. It was hard going but it worked!

Qualitative methods relied on the “engineer’s judgment”: using the intuition, skills and experience of individuals, as well as feedback from the field, to establish the different possible scenarios (breakdowns, accidents, maintenance, etc.). As a result, we began using inductive methods such as the HAZOP (Hazard Operability Studies) method taken from the chemical industry, to determine the effect of physical parameter drifts on breakdown eventuality, and deductive methods, such as fault trees, to identify the accident/incident scenarios most likely to occur.

Did Elf not have computers to help you perform more complex operations? 

In the 1980s, Elf had a big IBM 368 mainframe unit to perform calculations, as well as small HP-9830 machines, a predecessor of personal computers. Although these small machines were designed for data acquisition in the Group's laboratories, everyone was using them to perform calculations without the support of central IT services, and we were no different! Although quickly replaced by more powerful machines (HP-9845s), the HP-9830 was used as the basis for developing our first calculation algorithms.

The lengthy calculation times were extremely costly: a simple mistake could blow the budget for the whole year! So it was better not to make any mistakes in our calculations before entering the data. While these machines helped us simulate qualitative and quantitative models, Elf still did not have adequate computing tools to quickly, easily and comprehensively process this data. That’s when I began to invest more heavily in programming to provide my department (and therefore the company) with tools and calculation engines specifically designed for reliability analysis.
 

Is Termites a distant relative of the ALBIZIA calculation engine, which has now been integrated into the GRIF software suite? 

Yes, it is. But it was the discovery of Binary Decision Diagrams (BDD) that resulted in a qualitative leap in the modeling and processing of very large fault trees and achieved the goal for which Termites was designed.

I then developed Mark-EXD for performing probabilistic calculations using the Markov model and based on the exponential of matrices. Considered at the time by the CEA as one of the worst possible approaches, this calculation method actually turned out to be the most efficient and effective solution for performing probabilistic calculations on production and safety systems.

Today, Termites and Mark-EXD represent the DNA of the ALBIZIA calculation engine. At present, it is doubtlessly one of the most powerful engines for meeting static modeling needs (Boolean calculations). It is used in many GRIF modules. 

Which of the modules that you developed are you proudest of?

I think they’re all great because they each meet a specific need for which I had to find a solution on my own to successfully carry out my work as a reliability engineer. And I know that by doing this, almost everything I’ve learned during my studies (math and nuclear physics) has helped me to solve a difficult problem at one time or another. Mathematics is like a living language: with its (rich!) syntax and its calculation methods that can constantly be adapted to help us understand and model the environment around us. It seems to me that this field is too often overlooked at the moment.

What is your view on the additional modules developed after your retirement (ETree, Bool, Petro, Risk, Flex and SIL)?  

Before leaving Total, I chose not to develop a SIL module to assess the integrity level of Safety Instrumented Systems (SIS). I thought that it was better to see a system’s problems on paper, using the classic fault tree module, rather than through a model that had already been distorted. But demand was such that Stéphane Collas (who had taken over GRIF) developed an automated computerized solution for this purpose, which was incredibly successful as soon as it was launched. /p>

All these modules have been designed to meet needs regularly identified by professionals in the field, who are increasingly required to conduct rapid reliability analyses integrating new parameters (standards, cost control, reduced carbon footprint, etc.). Meeting users’ needs is an integral part of the philosophy we adopted when carrying out the first work in 1982.

Damien EHRET, IT engineer at TotalEnergies,explains how he developed the interface for the GRIF software suite in collaboration with Jean-Pierre Signoret.

How did your work with Jean-Pierre Signoret on the GRIF software suite come about?

After training to become a general engineer, I was hired by Elf in 1987. I was 25 years old at the time and working in the Artificial Intelligence department of the Jean Féger Scientific and Technical Center (CSTJF) in Pau. 
I spent a lot of time designing rule-based engines. It was while involved in this activity that I had my first contact with Jean-Pierre Signoret’s team. He was looking for someone to help him create a system that could generate Markov graphs based on his descriptions and the idea really appealed to me. After a few conversations, he gave me free rein to work on the project.
 

Asking a fellow employee working in an industrial setting for help designing software with a graphic interface is an unconventional approach. Did you have any external expertise to support you on this project, or did you have existing software to use as inspiration for the design of your interface?  

You mustn’t forget what the working environment was like in the 1990s. PCs were in their infancy. Computers and workstations were not as widely used or ergonomic as they are today. To my knowledge, no equivalent software had been developed in FORTRAN before. That meant we had to do everything ourselves. At Elf, many innovations were being developed internally, providing IT and technical solutions to facilitate our activities, much more so than at Total, which had an already well-established culture of outsourcing when taking us over in 1999. Our engineers were more focused on the technical side. My work with Jean-Pierre Signoret was unique, precisely because we designed a range of turnkey tools that could effectively be used to conduct high-quality reliability analyses.

What was the situation when you arrived?

At first, all the calculations were done by hand. Then, with a text file detailing the nodes and links, Jean-Pierre entered all the calculation method descriptions into the HP-9845 and IBM servers, enabling the MOCA-RP and Mark-EXD engines to display the results.
The graphic part of the modeling and the calculation generation were kept as independent processes. We needed to design a graphical interface that would combine all the required functionalities and run on both UNIX and PCs with DOS.
 

How did you move the project forward?

We weren’t aiming to create something revolutionary but to digitize the existing work environment. Jean-Pierre had designed a few models which we discussed, and from which we aimed to develop a graphic interface that was as simple as possible, with a large area for viewing the system models, and configuration options at the sides. The most important thing was to maintain the symbolism of reliability expertise jargon. For example, there was a symbol to define a node, another to explain the link with a node, etc. After some development and testing to link the calculation programs to the interface, we created an operational tool.