These forums have been archived and are now read-only.

The new forums are live and can be found at https://forums.eveonline.com/

Intergalactic Summit

 
  • Topic is locked indefinitely.
12Next page
 

Looking for help from Systems Engineers and Shipwrights.
Author
Previous Topic Next Topic
Pieter Tuulinen
Societas Imperialis Sceptri Coronaeque
Khimi Harar
#1 - 2013-06-21 21:11:23 UTC
A couple of months ago a Caracal Class medium cruiser of mine suffered a massive engineering casualty and was lost in the outer part of the Tasti system. A couple of weeks ago two good friends of mine pulled myself and the surviving crew out of deep space.

Much of the data onboard the ship is a total loss, for reasons that will become very apparent shortly, but part of the disaster response protocol I use called the 'KIZUTUAI PROTOCOL' is to send out the ship's log to date if something like this happens. My recent experience indicates this is a useful step, given that it helped prepare the C-SAR team to recover the ship.

Officially this log is classified, but I'm at such a loss as to what actually occurred that day that I'm going to take the somewhat contraversial step of publishing it in the clear here. Anyone who can shed some light on this matter will earn my gratitude - I'm hoping some of our more techie members will see it in terms of a personal challenge.

My thanks, in advance!

For the first time since I started the conversation, he looks me dead in the eye. In his gaze are steel jackhammers, quiet vengeance, a hundred thousand orbital bombs frozen in still life.
Pieter Tuulinen
Societas Imperialis Sceptri Coronaeque
Khimi Harar
#2 - 2013-06-21 21:15:00 UTC  |  Edited by: Pieter Tuulinen
///---CSC DREAD---\\\
Caldari State Cruiser - Caracal Class - Rapid Light Missile Configuration
CRITICAL ALERT - Power Grid anomaly detected
All times given at Mark plus

0000.00.00 - Warp Initiated
0000.00.10 - Propulsion Expert System (Memory corruption)
0000.13.22 - Navigation Expert system (WarpDurationError.Flag10)
0000.13.22 - Engineering Supervisor System (Flag.Disregard)
0000.15.72 - Navigation Expert System (WaypointReached.Flag10)
0000.15.72 - Engineering Supervisor System (Flag.Disregard)
0000.31.50 - DriveTech_Saan314 (CommandPrompt::QueryStatus)
0000.31.51 - Navigation Expert System (QueryRespond:Status Databurst)
0002.35.81 - DriveSuper_Haaklein112 (CommandPrompt::QueryStatus)
0002.35.83 - Navigation Expert System (QueryRespond:Status Databurst)
0003.41.28 - DriveSuper_Haaklein112 (CommandPrompt::QueryStatus)
0003.41.31 - Navigation Expert System (QueryRespond:Status Databurst)
0007.18.87 - ChiefEng_Moraa (CommandPrompt::QueryStatus)
0007.18.91 - Navigation Expert System (QueryRespond:Status Databurst)
0008.38.15 - ChiefEng_Moraa (CommandPrompt::WarpCore Shutdown)
0008.38.15 - Propulsion Expert System (QueryRespond:Acknowledge)
0008.38.16 - Propulsion Expert System (Initiate: WarpCore Shutdown)
0008.38.16 - Engineering Supervisor System (QueryStatus:Navigation Expert System)
0008.38.17 - Navigation Expert System (QueryRespond:Status Databurst)
0008.38.18 - Engineering Supervisor System (CommandPrompt::Denied)
0008.42.25 - ChiefEng_Moraa (CommandPrompt::WarpCore Shutdown)
0008.42.26 - Engineering Supervisor System (CommandPrompt::Denied)
0009.15.63 - ChiefEng_Moraa (CommandPrompt::WarpCore Shutdown)
0009.15.66 - Engineering Supervisor System (CommandPrompt::Denied)
0009.15.70 - Engineering Supervisor System -> ChiefEng_Moraa (Override CommandPrompt)
0009.15.73 - Engineering Supervisor System (CommandPrompt::Lockout All Systems)

0000.29.48 - WARNING PERSONNEL ACCESS TO POWER CONDUIT BUS WHILE DRIVE IN USE
0000.29.48 - EXTREME DANGER. RESCHEDULE MAINTENANCE OR SHUT DOWN DRIVE

0000.31.10 - Class V power fluctuation in Warp Core
0000.31.11 - Power Conduit overload -- section 14, subsection 0ae2
0000.31.11 - Emergency Power Conduit shunt -- section 14, subsections 0ae0 to 0aef
0000.31.11 - Emergency Power Conduit shunt successful

0000.31.15 - EMERGENCY - FIRE DETECTED IN POWER CONDUITS - Section 14. Moving Aft.
0000.31.18 - Pod integration error ~~Data Loss~~
0000.35.31 - Pod integration error ~~Signal Recovered~~
0000.35.32 - Medical Alert (Pilot Lifesigns) (Status:Compromised)
0000.35.45 - Medical Alert (Pilot Lifesigns) (Data Burst)
Implant Integration compromised - Implant Sockets 2 and 5
Implants believed destroyed
Activating Distress Beacon and declaring Medical Emergency

0000.35.78 - Pilot Medical Emergency Declared. Setting Condition 4 throughout the Ship
0000.35.79 - Activating Distress Beacon. Program IV - Pilot Medical Emergency. M'aidez.
0000.35.79 - Medical Emergency. Emergency Shutdown of Warpcore ordered.
0000.36.19 - Engineering Supervisor System (WarpCore Shutdown::Denied)
0000.36.19 - Engineering Supervisor System (Unsafe to Comply)

0000.36.35 - DAMAGE REPORT::EXPLOSION IN ENGINEERING/DRIVE COMPARTMENT

0000.36.41 - DamageControl Expert System (DamageReport::Databurst)
SITUATION:Explosion in Engineering/Drive Compartment / Section 14
Hull Integrity Compromised
Compartment Sealed
PrimaryReactor::Destroyed
PowerControl Systems::Damaged
Propulsion Expert System::Not Responding

SITUATION:Power Conduit Flashover in MAIN POWER CONDUIT / Section 14
MainPower::Down
SecondaryPower::Down
EmergencyPower::Responding

SITUATION:Power Spike in MAIN POWER CONDUIT / Section 14 and Aft
Section 14::Blown Out
Section 13::Blown Out
Section 12::Blown Out
Section 11::Blown Out
Section 10::Blown Out
Section 09::Blown Out
Section 08::Blown Out
Section 07::Blown Out
Section 06::Blown Out
Section 05::Blown Out
Section 04::Blown Out
Section 03:Down
Section 02:Down
Section 01:Down
Section 00:Emergency Power

SITUATION:Power Spike in MAIN SYSTEM Room / Section 12
Hull Integrity Compromised
Compartment Sealed
FireControl Expert System::Not Responding
BridgeControl Expert System::Not Responding
Navigation Expert System::Not Responding
Power Expert System::Not Responding
Reactor Expert System::Damaged
Communications Expert System::Not Responding
Data Expert System::Not Responding
Life Support Expert System::Online
Damage Control Expert System::Online
Medical Expert system::Not Responding
Engineering Supervisory System::Not Responding
Tactical Supervisory System::Not Responding

SUMMARY:
Massive Engineering Casualty
All Major Systems Affected
Casualties Unknown
Pilot Medical Casualty

RECCOMENDATION:
Enact KIZUTUAI PROTOCOL

0000.38.00 - Kizutuai Protocol Declared
0000.38.01 - Purge Classified Files
0000.38.15 - Purge Successful
0000.38.21 - Abandon Ship/All Hands
0000.38.22 - Lifepod Section Disabled - Abandon Ship Rescinded
0000.38.31 - Eject Command Pod
0000.38.32 - Pod Release Damaged - Eject Command Pod Rescinded
0000.38.40 - Activate Command Pod Self Destruct
0000.39.01 - Self Destruct Override/Pilot
0000.38.23 - Send out the Log to Date

~~~~~~~~End of File~~~~~~~~~~

For the first time since I started the conversation, he looks me dead in the eye. In his gaze are steel jackhammers, quiet vengeance, a hundred thousand orbital bombs frozen in still life.
Katrina Oniseki
Oniseki-Raata Internal Watch
Ishuk-Raata Enforcement Directive
#3 - 2013-06-21 21:22:22 UTC  |  Edited by: Katrina Oniseki
0008.38.15 - ChiefEng_Moraa (CommandPrompt::WarpCore Shutdown)
0008.38.15 - Propulsion Expert System (QueryRespond:Acknowledge)
0008.38.16 - Propulsion Expert System (Initiate: WarpCore Shutdown)
0008.38.16 - Engineering Supervisor System (QueryStatus:Navigation Expert System)
0008.38.17 - Navigation Expert System (QueryRespond:Status Databurst)
0008.38.18 - Engineering Supervisor System (CommandPrompt::Denied)
0008.42.25 - ChiefEng_Moraa (CommandPrompt::WarpCore Shutdown)
0008.42.26 - Engineering Supervisor System (CommandPrompt::Denied)
0009.15.63 - ChiefEng_Moraa (CommandPrompt::WarpCore Shutdown)
0009.15.66 - Engineering Supervisor System (CommandPrompt::Denied)
0009.15.70 - Engineering Supervisor System -> ChiefEng_Moraa (Override CommandPrompt)
0009.15.73 - Engineering Supervisor System (CommandPrompt::Lockout All Systems)

Right here, your Chief Engineer's attempts to initiate shut down of the warp core were summarily ignored. I can only assume it was because the warp drive was already in use, which coincides with your discovery along warp route between celestials. Following that, as you already know, your Chief Engineer simply cut the hard lines. This is what caused the catastrophic failure.

It's basic engineering school that teaches you warp cores cannot be shut down that way. Once onlined, they stay that way until a very specific and delicate process of disassembling and powering it down is conducted, usually for the purposes of repackaging a ship. Warp core failure is the cause for nearly every ship destruction you see. It's why when you put enough rounds through even a capital ship it nearly vaporizes instead of just falling apart.

0000.00.00 - Warp Initiated
0000.00.10 - Propulsion Expert System (Memory corruption)
0000.13.22 - Navigation Expert system (WarpDurationError.Flag10)
0000.13.22 - Engineering Supervisor System (Flag.Disregard)
0000.15.72 - Navigation Expert System (WaypointReached.Flag10)
0000.15.72 - Engineering Supervisor System (Flag.Disregard)

As for why she shut it down, I assume it's because your nav computer blatantly ignored the waypoint flag and kept on going. How this is possible, I can't even fathom. Warp bubbles are only charged with just enough energy to remain active for the duration of the calculated warp. It's why we need to spend our capacitor ahead of time based on the distance from our location to the destination. It shouldn't be possible for the ship to simply keep going without automatically shutting down, much less for nearly ten minutes.

This leads even further back to how much charge was shunted into the warp field. Check your capacitor control logs. If possible, I'd look at the physical cap lines and see if something tampered with the energy pumps. Somehow, your warp field was overcharged, which flung you further than the nav computer expected.

Katrina Oniseki
Pieter Tuulinen
Societas Imperialis Sceptri Coronaeque
Khimi Harar
#4 - 2013-06-21 21:23:35 UTC
I appreciate your help, Katrina. To be honest, I've been staring at this and staring at it and it's really not making much more sense then it did initially.

For the first time since I started the conversation, he looks me dead in the eye. In his gaze are steel jackhammers, quiet vengeance, a hundred thousand orbital bombs frozen in still life.
Tatiana Yazria
Dragon Logistics
#5 - 2013-06-22 01:22:54 UTC
Unfortunately, Pieter, it's not likely to make too much sense.. logs only go so far, and what's really needed here is the full memory dump rather than the log dump. I'll try and put it in terms folks without avionics programming expertise can understand. I'm presuming HHMM.SS.ms format since that tends to be standard; I don't know if you've modified from that. (I usually do.)

The troublesome part begins here:
0000.00.00 - Warp Initiated
0000.00.10 - Propulsion Expert System (Memory corruption)
At 10ms in, memory corruption occurred. Any time memory corruption occurs, all further output becomes suspect at best and generally is disregarded as a result. Meaning, the logs are presumed to be bad as an error indicating that the logs are bad was presented. We are paranoid like that.

Here's where things go really south.
0000.13.22 - Navigation Expert system (WarpDurationError.Flag10)
So at 13s, 22ms, we have evidence that the error at 00.10 is not a false positive - there is a systems level failure. After this point, all logs can be discarded as suspect at best. NavEx is considered a flight critical system, so has at minimum a parallel redundant memory bus and usually mirrored storage in a crossbar design. (I favor a star topology, but I am admittedly old fashioned and presume everything will break or catch fire.)

Given this evidence, the best estimate I can give you from an expert perspective is that an unknown externally caused failure resulted in multiple parallel loss of flight critical systems including redundancies, resulting in unpredictable and atypical behavior from affected systems.

As an example, this is a portion of a log from a recovered C33G-2A civilian avionics system as captured by the FDR. This is a matter of public record as part of training materials. The originating incident was the result of improper installation of a module, leading to physical damage that caused loss of primary and secondary data buses in entirety. Literally, it fell out of the aircraft.
Z0403.53.100: ALARM: STORAGE INACCESSIBLE
Z0403.53.101: ALARM: HYDRAULIC PRESSURE SENSOR FAILURE
Z0403.53.101: ALARM: Z0403.53.100: ALARM: STORAGE INACCESSIBLE
Z0403.53.101: ALARM: Z0403.53.101: ALARM: Z0403.53.100: ALARM: STORAGE INACCESSIBLE
Z0403.54.100: Input: FireSuppression(ACTIVE)
Z0403.55.351: Input: BackupAPU(Enable)
Z0403.55.789: Input: BackupAvionics(Enable)
Z0403.56.002: Z0403.55.789: Input: BackupAvionics(Enable)
Z0403.56.002: Z0403.56.002: Z0403.55.789: Input: BackupAvionics(Enable)

As you can see, the FDR itself contains substantially corrupted and incorrect output from flight critical logging systems. What you might also notice is that the pilots manually activated the fire suppression systems despite no indicated fire alarm in the log, activated the APU despite no electrical failure indication, and activated the backup avionics processor. According to their debriefing however, these alarms were indicated in the cockpit.

It's important to note that shipboard systems are nothing more than an evolution of avionic systems on the whole, so there are more similarities than differences with regards to the software - reactors and warp systems included. The principle of flight critical, operational impairment, and non-critical failures are much the same. RCA also follows the same routes.

If I had to field a more specific guess as to root cause in this specific case with your ship, I would be looking at flight-critical data bus trunk lines located against or near a power buses or hull elements with visible damage which is not indicated in any recovered logs. My presumption would be that a primary data bus trunk line was taken out of service either by damage or maintenance and the redundant trunk either failed in operation or had a previously undetectable defect.
Nikilaiki Ashland Karris
Doomheim
#6 - 2013-06-22 03:10:06 UTC
Logs alone cannot tell the story. Without interviewing crew and knowing the circumstances of the events leading up to the incident there is no way to be certain. Having a wreck to analyze, initial response reports, and other vital forensic clues would be invaluable.

Am I correct in assuming that you have access to all of this, and that the only confusing element is this log? Is there more to the story than you are revealing?

If you wish, we can discuss this matter confidentially.
Xindi Kraid
Itsukame-Zainou Hyperspatial Inquiries Ltd.
Arataka Research Consortium
#7 - 2013-06-22 04:07:08 UTC
Judging by what your expert systems were doing, I'd suspect the onset of the problem was a systematic failure of your computer systems. There's a couple of reasons for an unexpectedly long warp, the first is an error causes more power to be initially fed into the drive when the warp tunnel is formed; this isn't all that unsafe, though any time you suffer a drive malfunction caution demands you not try to use it till you've troubleshooted and fixed the problem. The second reason a warp might last longer than expected is that a control or power systems error caused power to keep getting fed into the warp drive. This is a very dangerous situation since it can sometimes cause warp tunnel fluctuations. (this is why the ship usually injects all it's power into the drive at the onset.)

I say there's a systematic computer systems failure, because if the propulsion system encountered an error before power injection, the nav system should have ordered a warp cancel . If the error was after injection as the log claims, then the engineering of power control systems should have noticed aberrant power conditions in the drive, or the nav system should have picked up on the warp tunnel fluctuations. Also if the warp went on longer than it was supposed to, I would expect the waypoint reached message to precede the unexpected duration message since you usually expect to be in warp before reaching the waypoint.

I would definitely agree you should look at your data trunks like Yazria suggests.. With what your logs show, and more importantly, what they DON'T show (Usually even minor failures will output several lines of error codes from various systems, both for redundancy and because they often cascade [for instance a locked RCS thruster will be flagged then the nav systems will inform you of unexpected drift o adverse maneuvering conditions]), I'd say the only real way to find out what happened is through physical examination.

Do your dumps include system specific logs or just the master log? it's usually good practice to have critical systems monitored by at least 3 computers (if one is monitoring you can't tell if it's correct, if 2 are monitoring and they don't agree then you don't know which is wrong, if three are monitoring and one disagrees that one's probably wrong, if all three disagree, abandon ship). The computing scheme I use for my ships has propulsion monitored by the propulsion expert system, a propulsion monitor and the nav expert system (though the engineering expert can server the role as well)
Streya Jormagdnir
Alexylva Paradox
#8 - 2013-06-22 04:12:14 UTC
Interesting. Katrina is correct in saying that the warp core is given only enough charge to warp the ship a pre-determined distance...usually. I am unfortunately unfamiliar with how Caldari ships' graviton reactors and scalar capacitors work, but were it an electrolytic capacitor I would guess that something impacted the capacitance of the capacitor. Even if your ship's reactor itself did not encounter any fatal errors, a mechanical fault in the capacitor might result in a huge amount of current passing through it and on to other subsystems, such as your warp core and central computer. Since the first critical error of note involves the ship's powergrid, such an explanation wouldn't be unlikely.

I am also a human, straggling between the present world... and our future. I am a regulator, a coordinator, one who is meant to guide the way.

Destination Unreachable: the worst Wspace blog ever
Xindi Kraid
Itsukame-Zainou Hyperspatial Inquiries Ltd.
Arataka Research Consortium
#9 - 2013-06-22 04:23:26 UTC
The problem which makes me suspect power continued to be fed to the core is the fact that even if the entire capacitor were fed to the warp core, that class of ship should not be able to sustain warp for more than a couple minutes.
Katrina Oniseki
Oniseki-Raata Internal Watch
Ishuk-Raata Enforcement Directive
#10 - 2013-06-22 05:06:09 UTC
Xindi Kraid wrote:
The problem which makes me suspect power continued to be fed to the core is the fact that even if the entire capacitor were fed to the warp core, that class of ship should not be able to sustain warp for more than a couple minutes.


This is true.

Katrina Oniseki
Pieter Tuulinen
Societas Imperialis Sceptri Coronaeque
Khimi Harar
#11 - 2013-06-22 05:18:31 UTC  |  Edited by: Pieter Tuulinen
Nikilaiki Ashland Karris wrote:
Logs alone cannot tell the story. Without interviewing crew and knowing the circumstances of the events leading up to the incident there is no way to be certain. Having a wreck to analyze, initial response reports, and other vital forensic clues would be invaluable.

Am I correct in assuming that you have access to all of this, and that the only confusing element is this log? Is there more to the story than you are revealing?

If you wish, we can discuss this matter confidentially.


As you can see, several minutes after the initial software event my Chief Engineer, for reasons she didn't share with me at the time, sheared physically through the main power conduit whilst the warp core was charged. This precipitated first a dump of current to an ancilliary power bus and then, that failing, a flashover that caused such a large power surge that it effectively turned the entire engineering compartment inside out. Following that a fire spread rapidly through the ship, causing significant damage.

I've retained the physical shell of the cruiser, but none of the systems or the backup storage areas survived. Some of the redundant storage cores may have survived intact but, alas, did not remain attached to the remaining structure of the vessel. Sadly none of the crew in the Engineering department or the Flight Systems department or even in the computing department survived much longer than a minute or two past the initial explosion.

For the first time since I started the conversation, he looks me dead in the eye. In his gaze are steel jackhammers, quiet vengeance, a hundred thousand orbital bombs frozen in still life.
Pieter Tuulinen
Societas Imperialis Sceptri Coronaeque
Khimi Harar
#12 - 2013-06-22 05:24:34 UTC
Several of you have mentioned that, given the odd behaviour of the flight computer and the timeline corruption within the emergency log itself, nothing in it can be taken for granted or relied upon.

The Flight Recorder was recovered from the wreck after the crew and myself were taken off. This can be made available to those wishing to find an answer. The wreckage is also available in the Tasti system to be viewed although, I warn you, most systems were burned out and few logs or data dumps remain available.

The surviving crew are no longer under either my nor anybody elses orders and are undergoing their transition to wealthy private citizens.

For the first time since I started the conversation, he looks me dead in the eye. In his gaze are steel jackhammers, quiet vengeance, a hundred thousand orbital bombs frozen in still life.
Saya Ishikari
Ishukone-Raata Technological Research Institute
Ishuk-Raata Enforcement Directive
#13 - 2013-06-22 08:46:46 UTC  |  Edited by: Saya Ishikari
Having finished my current project to an acceptable stage, which you know the one I'm referring to Tuulinen-suuolo, I'm available to conduct a physical dismantling and component by component inspection of the remnants of the cruiser, if such has not already been done. Simply tell me when you need me, and my time is yours for as long as you need to satisfy the aftermath of this ordeal. I'm also of the opinion that the power management systems are suspect, based on the data available... Perhaps more thorough, hands on inspections will reveal more. If you have others you would rather conduct the work, I understand, but this is an open offer, and will remain as such, kirjuun.

"At the end of it all, we have only what we've left in our wake to be remembered by." -Kyoko Ishikari, YC 95 - YC 117
Kalanaja
Sebiestor Tribe
Minmatar Republic
#14 - 2013-06-22 16:20:53 UTC
That is a mess. I'm definitely in agreement with the others. Computer failure straight and simple. It's to be expected though. No system can be 100% perfect even when robotics and nanomachines are involved in the process. Also it does look like more power was being fed into the drive while you were already in warp. I'd let Saya look and then scrap the remainder after she's done. No way that thing is fixable after that.
Lucas Raholan
Societas Imperialis Sceptri Coronaeque
#15 - 2013-06-22 17:19:04 UTC
Given you're Chief Engineer should have known what cutting the Main Power line would do to a vessel while in warp my gut instinct would suggest that this was the outcome she intended, if you can prove this it means any deaths which took place plus you're own personal injures are on her head.


I would at this point suggest execution

Shitposts so bad CONCORD gave me a 50 billion ISK bounty
Makoto Priano
Kirkinen-Arataka Transhuman Zenith Consulting Ltd.
Arataka Research Consortium
#16 - 2013-06-22 17:25:21 UTC  |  Edited by: Makoto Priano
One cannot execute the dead.

Tuulinen-haan, my condolences for the loss of crewmembers, and my regards for your generous treatment of those who survived the ordeal.

As regards the events aboard your ship, I can't offer much beyond what has already been indicated here. I would wonder, though, given the rapidity with which all this occurred, whether shock or stress caused a poorly thought-out reaction by the chief engineer. Never attribute to malice what may be adequately explained by stupidity.

This isn't to say that the chief engineer was stupid, but rather that sometimes mistakes -- terrible, lethal mistakes -- are made.

Itsukame-Zainou Hyperspatial Inquiries: exploring the edge of the known, advancing the state of the art. Would you like to know more?
Makkal Hanaya
Revenent Defence Corperation
#17 - 2013-06-22 17:33:35 UTC  |  Edited by: Makkal Hanaya
Lucas Raholan wrote:
Given you're Chief Engineer should have known what cutting the Main Power line would do to a vessel while in warp my gut instinct would suggest that this was the outcome she intended, if you can prove this it means any deaths which took place plus you're own personal injures are on her head.


I would at this point suggest execution

She's dead. I doubt there's enough of her left to fit in a shoe box.

There's no way the Chief Engineer would expect to survive such a thing though. She must have realized she was signing a death sentence for herself and much of her crew.

A good question would be: What could possibly be happening that flash frying most of the people on board was a better outcome in her mind than letting the ship continue?

Makoto Priano wrote:
I would wonder, though, given the rapidity with which all this occurred, whether shock or stress caused a poorly thought-out reaction by the chief engineer.

As I understand it, over warping isn't life threatening or particularly dangerous. The ship uses too much power and you overshoot your destination, but all you have to do is wait a bit for the cap to recharge and you can hop back to the nearest location.

The only danger is if the end destination of your warp is too close to a celestial body. Warping into the middle of the sun? Not good.

But less than 2% of any given system is matter.

Render unto Khanid the things which are Khanid's; and unto God the things that are God's.
Tatiana Yazria
Dragon Logistics
#18 - 2013-06-22 19:56:14 UTC
Pieter Tuulinen wrote:

As you can see, several minutes after the initial software event my Chief Engineer, for reasons she didn't share with me at the time, sheared physically through the main power conduit whilst the warp core was charged. This precipitated first a dump of current to an ancilliary power bus and then, that failing, a flashover that caused such a large power surge that it effectively turned the entire engineering compartment inside out. Following that a fire spread rapidly through the ship, causing significant damage.

I've retained the physical shell of the cruiser, but none of the systems or the backup storage areas survived. Some of the redundant storage cores may have survived intact but, alas, did not remain attached to the remaining structure of the vessel. Sadly none of the crew in the Engineering department or the Flight Systems department or even in the computing department survived much longer than a minute or two past the initial explosion.


Ah, now this matters a great deal, actually. Especially the part where she actually had to manually shear through it. Any situation like that, you are going to have a great deal of unpredictable and uncontrollable feedback. Systemic failure is an inevitable and immediate result. I had presumed that the cut was an automated response with hydraulic shear, in which case the cascading failures are usually pre-contained.

Any logs after this point can simply be discarded as a result, which narrows the dataset substantially. The question therefore can be narrowed down to one of: what failure precipitated and gave reason to your Chief Engineer to take an axe to a main power bus?

The flip side of this, is that it is a much harder question to answer. Especially without those responsible being unavailable to debrief. Since I doubt very much that Pieter has inadequate security, I would classify deliberate sabotage as unlikely - which is different from ruling it out. Likely, the cut was performed on the basis of available data in an effort to preserve the ship.

Unfortunately, the primary cause I'm aware of for effecting such a cut is a bus excursion as indicated by instrumentation. Well, we've already determined instrumentation and control systems were substantially compromised. So I would say that there's a high chance the Chief Engineer took the correct action based on incorrect data. The other possibility I would assign high probability to is that the correct action was taken despite incorrect data.
Remember that we are highly to entirely dependent on shipboard systems and sensors to indicate the state of many systems, as they are unsafe or impossible to access in-flight. When these sensors fail or present false data, it is virtually impossible to avoid error - one can only work with the data immediately available. If the system says that primary engines are on fire, all you can do is send damage control in.

I will most certainly vouch for Miss Ishikari's expertise. She is far more qualified than I to perform a physical investigation of a Caldari hull. Of course, I will also make myself available to advise to the best of my ability.
Pieter Tuulinen
Societas Imperialis Sceptri Coronaeque
Khimi Harar
#19 - 2013-06-22 21:02:49 UTC
Thank you all for your input. I'm still somewhat confused as to how it would have happened, but I think I have a better idea of what was involved.

I'll be following up with some of you who offered additional help.

For the first time since I started the conversation, he looks me dead in the eye. In his gaze are steel jackhammers, quiet vengeance, a hundred thousand orbital bombs frozen in still life.
Andrea Okazon
Laurentson INC
#20 - 2013-06-23 01:10:03 UTC
From what I can tell, something odd was happening in your Engineering Supervisor System. It not only disregarded the initial command to stop, it also consulted with Navigation before deciding to deny the order to shut down the warp core. I suppose the data that Navigation gave it was lost or is classified, but if the latter I would take a long close look at it.

To me, it seems like the ESS had an incommensurable idea of what was happening to the ship, relative to the crew.
12Next page