| Following is an account of the planning for the
demolition of the Cofferdam and the subsequent issues and
actions taken that resulted in the unsuccessful demolition
of Block 15 on the 6th of June 2006.
Planning, Issues and Actions:
Initial planning for the demolition of the Three Gorges
Cofferdam was based on certain assumptions and expectations.
Some were based on the very successful cofferdam simulation
blast earlier in May, others were based on discussions around
how the wires would be drawn up from the dam walls and secured
in order on the dam railings.
Planning was built around the following three options:
◇ Option 1： Full use of Orica's SHOTPlus-i? software and
the SHOTPlus-I logging function in the loggers. This is
the most accurate and fastest method of logging a large
complex blast. SHOTPlus-i also generates logging sheets
that help the operator, record and build a record of the
logging process, this ensures that delay times and detonators
are not missed or logged incorrectly.
The SHOTPlus-i option would require that all the lead wires
are placed in order in their in respective rows and that
each lead wire should be labeled with its i-kon label, as
was done during the simulation blast in early May.
Until the night of the 2nd of June all planning was conducted
believing that this option would be used, a lot of time
was used re-doing the design in SHOTPlus-i, so that SHQTPlus-i
could be used for logging.
SHOTPlus-i would have greatly reduced the need to apply
corrections to the logged delay times, during and after
logging.
◇ Option 2：Use both SHOTPlus-i and Manual logging modes
to log the detonators.
This option would employ the speed and accuracy of SHOTPlus-i
to log the sections of the dam, where the lead wires were
arranged in order according to their rows and location.
And use the flexibility of Manual mode to log detonators
from the chambers, were it was thought, that it would be
difficult to arrange the lead wires in rows since they would
all be bunched in groups of up to 62 lead wires and then
pulled to the surface through the ventilation holes.
This option would still require logging sheets and plans
as with SHOTPlus-i, which would allow us to maintain a high
degree of accuracy during loggingand when checking our loggers.
◇ Option 3: Full use of Manual Mode to log the blast, this
option was always seen as the least desirable method of
logging the Cofferdam.
Though manual mode is very flexible and quite operator
friendly, especially good where you have i-kon operators
of limited i-kon experience. The main draw back is that
the entry of delay times is totally dependent on the operators;
it is quite possible to introduce errors when entering the
delay times.
Even so Orica has i-kon operating procedures to help minimise
the occurrence of data entry errors. So again we would require
logging sheets and plans to Icg manually and minimise errors,
we would also still require lead wires to be placed in some
sort of order, but we would not need i-kon type hole labelling,
we could use the hole labels as they were.
As suggested above, planning was developed around the assumption
that Option 1 would be used to Log the detonators in the
Cofferdam.
This would require that the lead wires would each be drawn
up to the railing (top of the dam) from their individual
hole collars or at least together with other detonator leads
from the same row.
We would then need to label each lead as we did for the
Cofferdam simulation blast, an i-kon type hole label for
each detonator lead.
As the logging date approached and the lead wires were
lifted to the railings, the following observations were
made:
1. The wires were collected together in bunches of many
lead wires, from various levels of the dam wall and were
not in any particular order.
2. It became apparent that it would be difficult and time
consuming to search amongst the connectors of each bunch
to located detonators that would follow each other in order
according to a SHOTPlus-i logging sheet.
3. It also became apparent that the application of i-kon
labels would be very time consuming and difficult and would
still require searching through the bunched connectors when
looking for subsequent detonator labels.
As a result logging Option 1 was dropped as a practical
and time efficient means of logging the detonators in the
Cofferdam. Instead it now seemed Option 3, using full Manual
Mode would be the most practical and efficient means of
logging the Cofferdam.
This method would still require logging plans as a minimum
to record position on harness, logging direction and location
and for use during potential troubleshooting sessions.
Option 3 was first tested on the Cofferdam late on the
3rd of June, what we found resulted in the introduction
of Option 4, as follows:
◇ Option 4: We found that due to the way the detonator
leads had been collected into bunches from multiple levels,
as they were lifted to the dam railing. It was very difficult
and time consuming to log to a pre determined logging path
as established on SHOTPlus-i.
So Option 4, was introduced, this option simply called
for the i-kon operator to log a certain number of detonators
to each logger, he would not follow a predetermined logging
path and he would not be recording position on harness.
Both these changes are normally seen as risky deviations
from normal i-kon logging practice. There was no other option,
which would see us complete the logging within the time
available.
During earlier planning sessions, I had calculated how
many detonators could safely be logged to each logger. The
numbers were limited depending on where the lead wires originated
from and if they were wet or dry. We could tolerate fewer
long lead detonators from below water (eg the horizontal
pre splits) per logger, than we could for detonator leads
from dry holes on top of the dam wall.
The general logging rule for option 4 was, Log up to 140
detonators per logger except for the two dry ends of the
dam were we could log to 160 detonators per logger.
There would be no predetermined logging path that could
be related back to the i-kon plan. The i-kon operators would
log bunches of detonators as they came to them along the
railing, ensuring that they did not exceed 140 detonators
per logger without discussion with myself.
Though this option would see us ignore some of our normal
i-kon logging procedures, we were confident EXPL, who would
have teams of people checking off the detonators that we
had logged, would go some way toward locating any missing
detonators and would provide a final cross check of our
work.
Why did the detonators in Block 15 fail to initiate?
Late on the 3rd of June, 137 detonators were logged to
Master logger #1 and 118 detonators were logged to Master
logger #2.
On the evening of the 3rd of June, I uploaded both loggers
to SHOTPlus-i and to LOGCom-i.
The SHOTPlus-i files I used to generate Microsoft Excel
worksheets containing detonator ID numbers and their assigned
delay times, these sheets were then given to EXPL who would
use them to check our work and ensure that we had not missed
anything.
LOGCom-i is Orica software that allows us to upload the
logger data edit delay times and then download the corrections
back to the logger.
So on the 3rd of June the LOGCom-i file and the Excel file
showed 118 detonators logged to Master Logger#2.
On the morning of the 4th of June Block 15 detonators were
logged to Master logger #2, this was one of two loggers
that would be able to carry at least 160 detonators because
the holes were dry. Master Logger #2 now contained the data
for 160 detonators.
At lunch on the 4th of June, all the loggers were uploaded,
including Master Iogger#2, the data was transferred to an
Excel file, in which the additional 42 detonators logged
to Master logger #2 were highfighted. This up to date file
was submitted after lunch.
No loggers were uploaded to LOGCom-i at this time.
Logging continued throughout the afternoon of the 4th of
June, we finished late with a complete logger to do and
a few additions to be made to four of the other loggers.
These loggers had been left incomplete, to leave access
open for work crews who were still laying sand bags (we
did not want to run harness wires across the dam).
On the morning of the 5th of June, logging continued until
all loggers were complete. During the morning logging the
data from one of the loggers was deleted in error. So during
lunch on the 5th of June I uploaded 17 loggers to LOGCom-i,
so that I would have a complete back up of all the logger
data, which could be used to replace the data in a logger
if the data was deleted by accident.
Master logger #1 and #2 were not uploaded to LOGCom-i at
this time.
During the afternoon and evening of the 5th of June, the
team ran out and arranged the harness extensions, while
I was called to the office to edit the logger data and to
provide updated logger Excel sheets.
Logger data was edited to apply corrections where delay
times had been incorrectly entered into the logger, due
mostly to
＊ errors in determining the delay time written on the label,
or
＊ missing labels, or
＊ to alter delay times from the original design.
In the site office we had a number of corrections and alterations
to work through, Master logger #2 was one of the first few
loggers that needed some corrections. The LOGCom-i for master
logger #2 was opened the delay times were edited to provide
the corrections and then the edited data was downloaded
to the logger.
Unfortunately the LOGCom-i file had been uploaded originally
on the 3rd of June and did not contain the additional 42
detonators from Block 15.
After the corrections all the loggers where uploaded again
to SHOTPlus-i converted to text files and then transferred
to Excel. The Excel files were then given to EXPL, for checking.
Except now Master logger #2 is showing 118 detonators,
which escapes every ones attention until after the Cofferdam
is fired on the 6th of June.
On the morning of the 6th of June:
The two most senior and experienced i-kon users have the
critical task of making the harness extension connections
and doing the final logger checks on each logger at its
location on the Cofferdam.
It is my task to test and check all the Master loggers,
while completing work on Master logger #1, the EXPL/Yipoli
representative approached me and asked as a matter of some
urgency that I leave what I was doing, come to the office
and work through some more corrections and review the logger
counts.
Against my better judgment I agree and instruct other Orica
team members in how I want the harness connections done
and ask them to conduct the logger checks.
I'm absolutely certain that had I run the logger checks
on Master logger #2 in that location (on the dam) I would
have immediately realised that it was short 42 detonators.
I knew that that location on the dam should have accounted
for 160 detonators, not 118.
Of course the guys that tested saw 118 detonators, with
zero errors, they had not logged the detonators originally
and did not know the design as I did, they did not suspect
that anything was wrong.
The next time I saw the loggers they had been placed in
the fina logger position on tables and much of the final
testing had been completed in this position.
At the conclusion of the meeting with EXPL/Yipoli where
logger counts were checked against EXPL/Yipoli's records.
The final figure was reported to us as 2506 by EXPL/Yipoli,
I agreed with the count because it was what I believed to
be the correct detonator count, since Bonifacio Degay and
I had calculated 2505 during our lunch break on the 5thof
June, when Master logger #2 still showed 160 detonators.
Our count mid day on the 5th of June was as follows:
＊ master 1368 +
＊ slave 1100+
＊ extra 36 detonators that were found late and added to
Slave logger #9 +
＊ 1 extra detonator that had shown leakage earlier and had
been left off the logger on purpose, until I asked for it
to be logged back onto the logger.
＊ The-total we calculated was 2505 detonators.
＊ (and since then another single detonator had been found
and added).
I did not question the figure provided by EXPL/Yipoli because
it met my expectations. As a result I did not check or question
the arithmetic, either there or at the final logger position,
where I would normally add the logger count, since I felt
we had just done that with EXPL/Yipoli.
At the final logger position all the loggers were checked
for errors and leakage and the results recorded.
At the end of this process Bonifacio (Bonnie) and I where
just about to go and check a small leakage issue on Master
Logger #2, when we were informed that it was now time to
go to the blasting location, to conduct the Programming
Test.
I decided to leave the leakage issue on Master Logger #2
because if it proved to be an issue I would see it during
the programming test, when the system would be powered up
to full voltage.
Blaster Programming Test:
I think that it would not surprise anyone to hear that
while conducting that test, I felt that I was under a great
deal of pressure. So it would be no surprise to hear that
when the detonators and programming equipment (blasters)
reported no errors and preformed without the slightest issue,
I was very relieved.
At this point I still believed that we had 2505 detonators.
It was after a very relaxing lunch that I finally took another
look at the Blaster Reports from both blasters.
The Master Blaster was showing 1327 detonators and the
Slave Blaster was showing 1137 detonators, the total was
2464. I immediately knew that something was wrong, immediately
travelled to the logger position to check the logger count
once again and the firing line.
The logger count agreed with the blasters, by this time
we had maybe 30 minutes to firing time. Given the pressure
of the occasion and the apparent need to get to the firing
position, we unfortunately left the logger position without
further investigation and reported the discrepancy.
A further visit was made to the logger position, to investigate
Slave logger #8 and #9 to discuss the possibility that the
36 detonators that had been discovered on the 5th of June
had in fact been logged. The assumption was that they had
been counted twice to arrive at the higher detonator count.
The decision was taken to fire with the discrepancy, resulting
in the failure to initiate the blasting chambers in Block
15, during what was otherwise a stunning achievement and
blast.
Conclusion:
In hindsight it is often very easy to see the pit falls,
the exact moments in the overall process when those otherwise
insignificant actions and discussions meant that a critical
mistake was made or a fortunate discovery missed. For me
I have replayed the events over and over (my last thoughts
as I go to sleep and my first as I wake), I can accept how
the 42 detonators were initially deleted from Master logger
#2 as being understandable, even quite likely given that
the;
＊ process at the time was complex, I was running four different
software packages to process the data switching between
and editing files,
＊ it was early evening after a long day, and
＊ we were working as quickly as we could because the battery
in my laptop was about to expire.
What I find harder to explain is how those 42 detonators
remained undetected until the last, had I followed my normal
blast preparation on the 6th of June, I believe that they
would have been discovered.
I would like to extend my personal apology to the Three
Gorges Management Team for any public embarrassment or inconvenience
that my actions may have caused them personally.
I would also like to thank the Three Gorges Management
Team for the very great opportunity, to be involved, in
some small way in the Three Gorges Project. It has been
very rewarding and has provided a number of lessons that
I'm sure will benefit me in the future.
Thank you.
Laurie Simpson
Senior Electronic Blasting Specialist
Western Region Australia and Asia
|
设为首页
加入收藏夹