How Linux Helped to Salvage the Kursk

Transcription

1 How Linux Helped to Salvage the Kursk Paper 1 for the NLUUG Autumn Conference 2002 by Torsten Finke Ingenieurgemeinschaft IgH Essen, Germany 1 Revision: 1.2, Date: 2002/09/22 12:27:45

2 The Accident On August 12, 2000 aboard the russian nuclear driven submarine Kursk took place an enourmous accident. A torpedo has exploded inside the ship. This disaster caused such heavy damages, that the submarine sank. In this tragedy all 118 saylors have lost their lives. From then the boat lay 108 meters deep in the Barents Sea at east and north. Still in 2000 the russian gouvernment decided, that the Kursk should be salvaged. This project was scheduled til September Under coordination of the dutch consortium Smit Mammoet several companies worked together in this complex and extremely short-timed project. Usually autumn is the deadline for offshore work at that area because of very rough and bad weather conditions. How to lift a Submarine? The lifting concept suggested by Smit Mammoet was in fact quite simple. They planned to use a pontoon, the barge Giant 4 in this case, connect some strands from the pontoon to the wreck and lift it by hydraulic power. This concept is shown in figure 1. Seems easy, but there were some details, that were a little bit difficult. The dimensions of the submarine are gigantic. It s length was 158 meter, height by width was 11 by 16 meters. The weight was about tons plus the water inside of about tons, that would work not as heavy but as inertial mass. The wreck had no mounting points, naturally. So the hull had to be drilled to get 26 holes to fix the strands grippers in. On each mounting point 54 strands of steel have been used, each of 20 mm diameter. The barge was moving up and down driven by the waves, while the wreck lay fixed to the ground. So the strands were stressed by each single movement. Every wave put a hitch on the strands. To avoid such overload, so called heave compensators were used. They are a kind of spring, but not made of steel. Actually they where huge cylinders filled with high pressure nitrogen. There were four of these gas springs on top of each of the 26 mounting points. The cylinders, see figure 2 for an impression, had 4 meters length and 0.5 meter diameter. This bundle was connected to a couple of 128 bottles of 50 litres each. The nitrogen pressure should be up to 160 bar. In whole the volume was about litres, controlled by more than 700 valves, and so the system probably was the biggest high pressure system ever built. It was the question to the author of this little article, how such a system would behave.

3 lifting cylinder heave compensators pontoon Giant 4 strands Kursk Figure 1: The Lifting Concept The combination of heave compensation and hydraulic lifting units needed a control system. Hundreds of sensors measuring stroke, pressure, temperature and many more actuators had to be driven. No one has done such a job ever before. So it seemed to be very useful to train the operators who would do the actual job. Therefore a simulation system was needed. Besides that fundamental problems there were some other: What would be the suction force at the ground? How could one join the wreck to the barge without damage? How to mount the grippers? In which sequence? How to deal with oscillations? What about resonances? How to distribute the mounting points load?

4 Figure 2: Huge Heave Compensator Calculation and Simulation The first time the author and his colleages joined the project they had to calculate the mechanical behaviour of the huge gas springs. It s spring rate unfortunately varies because of the thermodynamical properties of the gas inside nitrogen. Also one had to calculate heat effects, since gases change their temperature by varying pressure. And finally there were several friction effects, for example caused by pipe flow. We had some calculation routines for that purpose, written for GNU-octave by John Eaton, a very powerful numeric calculation system, run best on Unix-like operating systems. So our Linux boxes ran day and night for lots of calculations for many different parameters. Presenting the results, the question came about the mechanical behaviour of barge and wreck, because until then no one knew the actual movements and forces. It was decided to build a full simulation system, describing: the forces and reactions between barge and seawaves,

5 forces and movements of the submarine, movements of each of the 26 heave compensators, the hole system of actuators and sensors. The simulation model should be able to describe most of the effects, that were considered to take place. So it had to be fully threedimensional describing all six degrees of freedom of all moving bodies. Also hundreds of pressures and forces had to calculated. The influence of the waveloads unfortunately is signifacantly not linear. Usually this is calculated by very complex finite element solvers, but those are to slow for real time simulation, so we needed high quality approximation. We had great luck having Professor Sharma form the Mercator University in Duisburg, Germany, as a consultant. He helped us building a fine hydromechanical model and teached us almost all we know now about the mechanics of ships in water. Hard work followed. The simulation system had been built by a set of several hundred differential equations, that had to be solved at least in real time because the simulation system should also be used for training purposes and finally as a lifting monitor. We decided to use Matlab/Simulink by Mathworks as the solver system. It comes with a nice grapical user interface and provides interfaces to procedures coded in C or Fortran. For efficiency reasons the equations themselve have been written in C. The code grew to nearly lines in three months. Have I mentioned, that we used the GNU C Compiler gcc and all his friends as gmake, gdb, gprof and so on? Relieing on such best proven high quality software engineering tools, we succeeded in building a model that described mother natures behaviour with only little mistake. That has been proven by russian engineers, who have come to visit the trainings and to compare our model against their own tests and calculations. Control and Communication During simulation developement colleages of the dutch company Raster built up a control system especially for the heave compensation system. They decided to use ModBus+, a bus driven protocol that is also defined in the TCP/IP domain. So we could easily connect the simulation model to the Raster control system. For this purpose we used a little TCP/IP server written in Perl, which once more demonstrated it s enourmous reliability and efficiency. Since the developement of the simulation system and the control system took place on different locations, we connected the systems by network and even by the internet, that worked fine, but allowed only tests due to it s limited bandwidth.

6 The control and communication concept is shown in figure 3. Each mount point has got it s own local control station. They were connected to their main computer, located in the control center, by a redundant ModBus+ network. In the control center there were five computers, that had been installed identically with a dual boot option to run Linux or Windows 2k respectively. Each of them could work as main control computer or as simulation system. Usually two or three of them were used as control stations and the one or two other ones ran as simulators. The connection between local control units on deck or simulation system to the control computer could be switched by software. So it was possible to do some simulations during the lifting process in a nearly identical environment. main computer visualisation, control (Delphi) 26 local controllers on deck software switch data and commands TCP/IP network ModBus+ redundant network fieldbus driver data... buffer ethernet nic ModBus+ redundant network TCP/IP network (ethernet) simulation computer (Linux) dual boot SIMULINK simulation Perl server... data buffer IPC (shared memory) Figure 3: Control Concept The situation during training and aboard the barge saw a standard ethernet local area network combining a heterogenous system of operating systems. The simulation system was still running under Linux, while the graphical user interfaces of the heave control and the lifting systems have been run under Windows 2k. The simulation system had a communication interface, that worked via System V inter process communication. This interface can be seen as an array of input and

7 output channels from or to the control system. So this array was just represented by a linear structure in memory space. This simple approach for a communication interface allowed the straight developement of the simulation without any influences from other applications. The communication process was kept apart to a TCP/IP server, that was responsible for all networking communication to the ModBus+ domain. During accelerated simulations the net load could grow to reasonable values. The server written in Perl connected itself to the IPC segment owned by the simulation process. On the other hand it served the requests from the control system. We observed up to requests per second. Some say, that IPC is heavily outdated. It has some unpleasant properties concerning timing and security. Also it s portability is problematic. Fortunately our network was declared secure, since there was no further connection to the world outside. It s functionality is great, if run under Linux. But mainly the developement time is short. And time was the most rare ressource! Reality versus Simulation Using the simulation system one may define a complete salvage situation: weather: given by temperature, wave period time, wave height and direction; submarine: given weight, water mass inside, ground suction force; accident: broken strands, deflated or crashed cylinder, etc. The operators display allowed to define all those relevant parameters as can be seen from the snapshot in figure 4. During simulation the simulation operator may change weather conditions or let an accident take place. The control system operators had to decide about several items: pressure inside each cylinder group; filling or bleeding cylinders; balancing the mount points loads. For example at the start of the lifting phase a force greater than the suction force must be used, but after detaching from ground the submarine may not flip up thus damaging the cylinders! So the gas pressure and the strand forces had to be adjusted very precisely.

8 Figure 4: Snapshot from the Simulation Display The control operators on their displays always saw the main important informations: loads, pressures, strokes, pitch and so on. A snapshot from this can be seen in figure 5. The design of those displays was built due to security and ergonomics. For example it was impossible to change a dangerous setting (for instance some pressure) by erroneously input decimal points. On the other hand the operators should be able to work lots of hours on the system having the most realistic idea of whats going on. Training After the simulation has been proven by russian engineers, the operators started the training phase. For two weeks they learned to handle the enormously complex instrumentary keeping in mind, that they would only have one chance to do the job. First there was little success: the wreck flipped around, it got unbalanced, cylinders

9 Figure 5: Snapshot from the Simulation Display crashed and so on. But by more and more exercises they got a feeling about the behaviour of the systems parts. They became quite optimistic and went towads the Giant 4 on September 12, 2001, a remarkable date to all of us. The trainings were continued aboard while divers did great work in preparing the wreck. They drilled not only 26 holes of 800 mm diameter into the hull of best steel, but also they cut off the totally damaged bow. The training became realistic, when the team began to fix the grippers in the submarines mount points. This took quite a long time and the weather conditions became bad. Some storms disturbed the work that became more and more dangerous. Finally all grippers were mounted, all cylinders working, each eight seconds moving up and down for nearly three meters. Now the team had to wait for calmer weather.

10 Lift and Success Much time had gone and the probability of good weather decreased day by day. Then on October 8, 2001, the abating storm and only low waves gave a last chance. During the night the team started the lifting process. Fortunately the suction forces were much lower than expected. The lifting system worked under full power without any problems. After nearly six hours the lifting was stopped at half the way. The team checked all the instruments and apparatus. They proved all the processes parameters and found it quite fine. Then they continued the lifting until the submarine joined the barge without any problems, that had been seriously discussed before. Still in calm weather the barge with the submarine connected under it s keel was towed to Rosljakovo near Murmansk. Several days later the Giant and the Kursk could be arranged to a dry dock after some difficulties and the Kursk finally appeared from the dark waters, see figure 6. Figure 6: Kursk emerging

11 Resume The salvage of the Kursk has become a story with happy end, because all the people involved did great work and finally had much luck. Doing a big job one has to have best tools. And one one of them was Linux, an operating system designed not to cause problems but to solve them reliably. Once more it s ingenious Unx-style concept combined with the well known high quality GNU components convinced definitely. Remembrance Despite of the success of the Kursk salvage we remember the 118 sailors who died in that tragedy at the Barents Sea on August 12, Our sympathy is dedicated to their relatives.