Human Error Blamed For European Vega Rocket Failure (spacenews.com) 139
"A quick analysis of Monday night's Arianespace Vega rocket failure has been root caused to 'a series of human errors,'" writes an anonymous Slashdot reader. STAT reports: In a call with reporters, Roland Lagier, chief technical officer of Arianespace, said the first three stages of the Vega rocket performed normally after liftoff from Kourou, French Guiana, at 8:52 p.m. Eastern Nov. 16. The Avum upper stage then separated and ignited its engine. However, "straightaway after ignition" of the upper stage, he said, the vehicle started to tumble out of control. "This loss of control was permanent, inducing significant tumbling behavior, and then the trajectory started to deviate rapidly from the nominal one, leading to the loss of the mission."
Analysis of the telemetry from the mission, along with data from the production of the vehicle, led them to conclude that cables to two thrust vector control actuators were inverted. Commands intended to go to one actuator went instead to the other, triggering the loss of control. "This was clearly a production and quality issue, a series of human errors, and not a design one," Lagier said.
Analysis of the telemetry from the mission, along with data from the production of the vehicle, led them to conclude that cables to two thrust vector control actuators were inverted. Commands intended to go to one actuator went instead to the other, triggering the loss of control. "This was clearly a production and quality issue, a series of human errors, and not a design one," Lagier said.
A little like (Score:4, Interesting)
Re:A little like (Score:4, Interesting)
Re: (Score:2)
Re: (Score:3)
File to fit, pound to insert, paint to match..
Not upside down this time (Score:2)
Commands intended to go to one actuator went instead to the other, triggering the loss of control.
I think there was a translation error: the cables were swapped, not inverted.
Re: (Score:2)
Why would this be a cause of failure? Aren't the cables just pass through, from this part to this part? Why should it matter if the cables were swapped?
Re: (Score:2)
Swap the cables running from your steering wheel and see what happens when you try to turn left...
They may be "pass through", but it's important that they pass through to the correct part!
It *WAS* a Design Issue! (Score:5, Insightful)
If it is possible to hook up cables the wrong way, and doing so can lead to a catastrophic failure of thousands or millions of dollars, then said cables should have been designed in such a manner where they *CAN'T* be hooked up backwards!
Different connector shapes or whatnot, that can only be hooked up in one particular manner. Some technician is doing the hookup, not paying attention, tries to do it backwards... *AND IT FLAT-OUT WON'T CONNECT*.
Don't rely on humans. We get bored. We've done the same thing over and over, and we stop paying attention.
Re:It *WAS* a Design Issue! (Score:5, Insightful)
Don't rely on humans. We get bored.
I just wonder who you think makes cables. Sure having different connectors sorts out the assembly but it does not in any way solve the underlying issue which is that a human is responsible for assembly. You just moved the potential issue from connection to cable manufacture.
That's also before you consider that many such systems are not connected point to point but rather point to multi-point (single large mating connectors carrying lots of signals which fan out to different areas) and all you didn't achieve anything because someone still needs to put the cables into the connectors at the end.
If you try to make something foolproof you're only fooling yourself.
The thing missing here was function testing, QC and verification. In any case human error may have lead to the cables being swapped, but human error was not what lead to the loss of the mission. That was procedural.
Re: (Score:3, Informative)
Re: (Score:2)
More likely, the actuators are all identical, a good design decision. And manufactured identically, a good practice.
It gets complicated, but at the least, labels... Not that hard, eh?
Re: (Score:3)
Eh, I'm with OP. You're never going to engineer out all human error, but at least make it a little harder to screw up. If you have two devices next to each other and it's critical that you don't hook them up to the wrong cable, you make it at least difficult to hook them up to the wrong cable. I agree that having two identical actuators makes sense from a cost perspective, minimize BOM creep on your expensive parts. Having two different pigtails on the same expensive part is a cheap way to prevent a mul
Re: It *WAS* a Design Issue! (Score:2)
Well, extra anything on a rocket is usually a bad idea. Perhaps labeling so that, on installation, each actuator cable was labeled 'correctly'.
But, lest we jump ahead of the obvious, why weren't these all tested for function before flight?
Oh, that's too obvious.
Re: (Score:2)
Well, extra anything on a rocket is usually a bad idea.
Apparently, in this particular instance, "extra" safeguards against human error would have proven wise. Maybe I'm missing your argument, what's "extra" here? 2 extra BOM lines for the different male/female connector? Order the actuator with a blank pigtail, apply the connectors in-house then tag/bin the parts accordingly. If you don't want the BOM "complexity" of different connectors, engineer the loom in such a way that connector A won't reach socket B. (And yes, of course everything has a label on it
Re:It *WAS* a Design Issue! (Score:4, Insightful)
Don't rely on humans. We get bored.
I just wonder who you think makes cables. Sure having different connectors sorts out the assembly but it does not in any way solve the underlying issue which is that a human is responsible for assembly. You just moved the potential issue from connection to cable manufacture.
Cables can be tested. Independently. Several times by several different people. Failure gets _very_ unlikely with that.
Re: (Score:2)
Re: (Score:2)
Cables can be tested. Independently
Everything can be tested independently. If they had an independent testing system in place we would be here bitching about Microsoft contributing to the Linux kernel and not discussing a problem with a launch vehicle.
Re: It *WAS* a Design Issue! (Score:2)
Ensuring adjacent connectors cannot swap is an ancient precaution proven in practice. The famous F15 crash due to misconnected flight control linkage is a mechanical example. Shit will happen and good design takes nothing for granted. Humans are unreliable meatbags so wise designers choose accordingly.
Re: (Score:2)
You're making an assumption that these are adjacent connectors. That's all I'm saying, everyone here is so full of assumptions and trying to make something fool proof where the reality is having an actual functioning QA/QC system in place would have prevented this.
The F15 is a good example though where engineering design is essential as airframe maintenance performed during war time is a whole different ball game than putting together a rocket. The former is time sensitive, the latter is time sensitive only
Re: (Score:2)
The thing missing here was function testing, QC and verification.
Bingo.
It's pretty shocking that this wasn't caught before flight; unless they're not doing any sanity, control, function, or QC checks then I'm at a loss to see how the hell this was missed.
Re: (Score:3)
Re: (Score:3)
I rather wonder why this was not tested before. We are testing the lights on a trailer each time we connect it, why not test fire the thrusters after assembly?
I should think the reason they don't do that to be obvious. Thursters often use some pretty dangerous propellants and for the safety of the ground crew you don't want to have this stuff just blowing around.
However, you are on the right track. Somebody needs to VERIFY the assembly is correct and functional after it's assembled. Where I don't think you can do a full functional test, you should be able to verify the wiring at least.
Re: (Score:2)
That was my thought, it should have been possible to dry test the system and verify that the unfueled thruster being actuated is the one the computer thinks it is.
Re: (Score:2)
Different connector shapes or whatnot, that can only be hooked up in one particular manner.
Not a bad idea, but something like this didn't help the last time. [russianspaceweb.com]
Re:It *WAS* a Design Issue! (Score:4, Insightful)
There's only so much stupid you can engineer out of a system. From the article: "The improper installation apparently required some considerable physical effort" and "...simulated the improper installation... on the actual hardware. As it turned out, it would be very difficult to do but not impossible." and "As a result, the plate holding the sensors sustained damage."
These are two wildly different failure modes. Your example wasn't someone absentmindedly switching two identical plugs around, it was a "technician" making a conscious decision to violently and destructively beat a square peg into round hole.
Re: (Score:2)
Re: (Score:2)
And I agree with you, no system is infallible. But my point, echoing the point above, is that there are small things you can do to reduce human error. Your example is almost inexplicable, where the worker took extreme measures to bypass engineering controls. No reasonable experienced worker would do what this person did.
I've worked in a manufacturing environment, as a technician you absolutely do not deviate from written procedure. If something doesn't fit like the instructions say they should you don
Re: (Score:2)
Re: (Score:2)
To prevent that, you have different connectors for different sensors and actuators. Then you cannot plug them in wrongly.
Re:It *WAS* a Design Issue! (Score:4, Interesting)
In a rocket you can create inserts in the sockets with keys and matching slots in the cable to prevent misconnections. Usually not possible in mass produced machines using interchangeable parts.
But the more serious question is, how did this pass QA? Every control surface is tested by technicians after assembly who gives control inputs and verifies correct reaction. They verify full traversal. They verify each step of control input and the correct response. This is the standard process. They have log books and signatures. Now a days with cheap ubiquitous cameras and videos, its possible the testing is recorded and reviewed by additional engineers. I was part of one such testing rig back when I started my career, seen two technicians going through the test protocol, one calling out, "Pin 529 +1 volt" and the other calling back, "Left aeleron up 2 degrees", record it in the ledger. The expected value is not in that register, it is in another log book where the third technician compares the observed values with expected values and signs off. These technicians are usually sergeants or their civilian equivalents.
Re: (Score:3)
The actuators are the same parts, two identical parts one for the left and one for the right. Its like the disc brake in the car. All the four wheels have exactly the same disk brakes. The hydraulic lines are identical, coupling is identical.
The hydraulic lines in automotive brakes are never identical. The couplings may be the same, but the lines are different lengths. Asymmetry is purposely built into the system so the right line won't reach the left brake. The same is typically done for wiring harnesses, and should have been done here.
Re: (Score:2)
Sounds like they still should have been keyed individually and/or there should be some sort of test procedure that verifies this. For that matter, why are the cables able to reach when going from the wrong socket to the wrong socket? For that matter, are these just straight electrical cables? No data bus along with unique id codes for parts with protocols to identify where they're installed?
Re: (Score:2)
No data bus along with unique id codes for parts with protocols to identify where they're installed?
That seems excessive, and extremely over-engineered, when all you need is "on" and "off". You are spot on with the other two main points: The connectors should have been difficult/impossible to connect backwards, and that absolutely should have been caught in a check out.
Re: (Score:2)
Also, defense-in-depth. Even if you think humans should do it right, in critical places you put in more than one control. For example: Well-trained people, connectors that only go in one way, and testing things on the ground before it is too late. When you have two or three things that need to fail, failure gets a lot less likely. Anybody not doing defense-in-depth is not qualified to do safety-critical engineering. And if people like that get to work on expensive or critical hardware that is the fault of m
Re: (Score:2)
It's called the "Swiss Cheese model" https://en.wikipedia.org/wiki/... [wikipedia.org]
Put as many layers of checks as you can between your assembly and disaster, because, stuff happens.
Re: (Score:2)
I would argue it is at lest equally a testing issue. There should be a method of testing that verifies the expected actuation/movement occurs - And not from feedback on the same wire that sent the command - that is not an independent test - but I bet that is how it WAS actually tested. I would expect a test where a series of commands are sent and an observer is verifying that the expected action happens from each.
Re: (Score:2)
Right - you would expect that when this engine was put on the test stand, it would have its thrust vectoring go to a series of set positions, and have the bell have to touch a limit switch at each, or have markings on the bell that allow a pair of cameras to determine its orientation.
Re: (Score:2)
Another good solution - test and map things on the ground. If the parts are identical, it really doesn't matter which one gets hooked up where, as long as the computer can figure out which is which.
This could even be done in depth. Layer 1: have part of the pre-flight checklist include a procedure to identify which device is connected to which IO port. Layer 2: have the software look for unexpected positive feedback loops (or really any control device that produces an unexpected effect) and be willing t
Re: (Score:2)
If it is possible to hook up cables the wrong way, and doing so can lead to a catastrophic failure of thousands or millions of dollars, then said cables should have been designed in such a manner where they *CAN'T* be hooked up backwards!
Different connector shapes or whatnot, that can only be hooked up in one particular manner. Some technician is doing the hookup, not paying attention, tries to do it backwards... *AND IT FLAT-OUT WON'T CONNECT*.
Don't rely on humans. We get bored. We've done the same thing over and over, and we stop paying attention.
That may fix the final assembly errors, but it doesn't eliminate the human error problem.
What you *really* need is VERIFICATION. When there is a possible human error involved, such actions need to be verified correct by another independent process. Where was that? Where was the - "it's hooked up, now verify that it works as expected" step?
This is a process problem, not a design issue. Just changing connectors won't help if you don't verify the correct wires get connected to the different connectors som
Re: (Score:2)
Different connector shapes or whatnot, that can only be hooked up in one particular manner. Some technician is doing the hookup, not paying attention, tries to do it backwards... *AND IT FLAT-OUT WON'T CONNECT*.
A much cheaper solution than connector shape is asymmetric harness layout. That way the devices can still be manufactured identically, but the connector won't reach the incorrect component.
Re: (Score:2)
If it is possible to hook up cables the wrong way, and doing so can lead to a catastrophic failure of thousands or millions of dollars, then said cables should have been designed in such a manner where they *CAN'T* be hooked up backwards!
Or simply color-code / differently-mark the cables *and* connectors so they get connected to their matching color/mark. There are practical benefits to having identical components vs. unique even within a single module.
Re: (Score:2)
It's an engineering decision often complicated by internal company politics.
When a failure mode analysis is done of a system, is incorrect assembly accounted for as a failure? If so, how is it dealt with? Keyed connectors, wire bundle design, etc? Not high on most engineers' priority list. It also complicates procurement as otherwise identical units now have to be spec'd as Left, Right or System 1, 2, 3, etc.
QA procedures? Now engineering is sticking their nose into the manufacturing process. A huge polit
Good 'ol Murphy's law (Score:5, Funny)
The original one. Or at least one of the originals. Long and complicated history, but one I liked:
"If there is a wrong way to do something, then someone will do it". or the longer version:
"If there's more than one way to do a job and one of those ways will end in disaster, then somebody will do it that way."
(Been a fan of 'Sod's law" being the "if something can go wrong, it will" one.)
It Was a Design Error (Score:5, Insightful)
"This was clearly a production and quality issue, a series of human errors, and not a design one."
The actuator cables should have been fitted with slightly different connectors so they could not have been plugged into the wrong place. The designers could have anticipated this potential error. If the actuators are electrically the same, testing can't detect this assembly fault.
Re: (Score:2)
You didn't solve the underlying problem. These companies do not buy off the shelf cables from Walmart, they make their own. Simply using different cables still very much allows the error to come through during cable assembly.
Re: (Score:3)
It is much harder to put the wrong connector or shell on a cable end, or cut the cable to the wrong length, without noticing the error than it is to plug a cable into the wrong (compatible, in-reach) connector without noticing the error. There are also more independent points at which the error might be noticed. Yes, it is possible for all those to fail -- but it is vastly less likely. Do not make perfect the enemy of much better.
Re: (Score:3)
It also gives you one more point where things can be checked, also technologically. The cables can fully be checked with a simple device and once they are checked, they cannot really go the wrong way in anymore.
Re: (Score:2)
Who said wrong connector, it's trivial to get connector pins in the wrong location. Shit man I've found commercial off the shelf cables miswired before.
The fact of the matter is neither process should rely on human error and simply bandaiding one possible error doesn't address the underlying problem: That there are QA QC gaps. Seriously something wired backwards? I don't deal anything near as expensive as rockets, but even our processes have functional tests as a part of them.
Re: (Score:2)
so they could not have been plugged into the wrong place
You underestimate human ingenuity.
Re: (Score:2)
so they could not have been plugged into the wrong place
You underestimate human ingenuity.
Well, you cannot really prevent crass incompetence and intent. Like people drilling holes into space vessels and then covering that up with an unsuitable glue.
Re: (Score:3)
They could have had different connectors and the problem could still have happened.
I'm assuming that the "red+black" cable was connec
Re: (Score:2)
They could have had different connectors and the problem could still have happened.
Not really. How to do this right is well established and there are tons of connectors on the market that are fool-proof, as long as the fool is not very determined or very violent.
Re: (Score:2)
You didn't read my post. I didn't suggest that the connectors were mated incorrectly, I suggested that the cable was _made_ incorrectly. I'm assuming it will have been one of those wiring loom things where one end has a big connector and then at var
Re: (Score:2)
You didn't read my post. I didn't suggest that the connectors were mated incorrectly, I suggested that the cable was _made_ incorrectly. I'm assuming it will have been one of those wiring loom things where one end has a big connector and then at various points wires "break out" to connectors along the body of the rocket.
I did read your posting. Cables can and should be inspected and tested before being installed, especially critical cables. Hence either the actual problem is with those inspections and tests missing or your speculation is baseless.
Re: (Score:2)
You didn't read my post. I didn't suggest that the connectors were mated incorrectly, I suggested that the cable was _made_ incorrectly. I'm assuming it will have been one of those wiring loom things where one end has a big connector and then at various points wires "break out" to connectors along the body of the rocket.
I did read your posting. Cables can and should be inspected and tested before being installed, especially critical cables. Hence either the actual problem is with those inspections and tests missing or your speculation is baseless.
I guess you're in the union or something.
"The brakes you installed failed and everyone on the bus was killed."
"Brian was supposed to test the brakes, so it's nothing to do with me, guv. Now, about that promotion we talked about last time - any word on that?"
Re: (Score:3)
You're adding cost and complexity. I do not think anyone can say with a straight face that added complexity leads to fewer mistakes.
Re: (Score:2)
Every checklist is added complexity. I would say that those absolutely lead to fewer mistakes. Overall, adding complexity absolutely leads to fewer mistakes if the complexity is in the form of well thought out design features that make it impossible to make a mistake without noticing.
Re: (Score:3)
Complexity also leads to problems and costs. Just because a system is built "fool proof" doesn't mean the world won't produce a better fool.
One of the unfortunate truism of the world is that the more complex you make something, the more unforeseen issues that can lurk in your design.
In aircraft automation, human factors engineers have to understand that Automation lowers pilot workload, until something goes wrong, then automation greatly increases it. So automation helps when things are going great, but
Re: (Score:3)
How many different connectors do you think would be required on a rocket if you wanted to make it impossible to plug anything into the wrong spot?
Exactly two: Power and communications signal.
In an ideal world, you have one or more switched buses. Everything communicates over automotive Ethernet (fixed time slicing) on that shared bus. Every data connection is mechanically identical, and the system can learn the topology dynamically if somebody plugs a device into the wrong switch. Each device is unique and has a unique identifier.
This leaves only the problem of someone installing the wrong sensor/engine into the wrong spot, which can be prevented
Re: (Score:2)
Not everything on the rocket needs to have a different connector. Reusing common and proven components is actually a good idea. However, when there are two identical actuators being plugged into with identical looking cables, probably coming out of a tightly anchored cable harness that can't be easily traced back, having some sort of keying to avoid a mix up is a good idea.
Re: (Score:2)
I completely agree. The designers screwed up badly and so did technical risk management and by extension, management. Making it hard to assemble things in the wrong way is a very basic design technique. The people really responsible here are now doing finger-pointing to the person that has the least responsibility for this.
Re: (Score:2)
Also, there's a question of management culture. In order to have fewer mistakes, you need to have a management culture that's tolerant of people making mistakes. If a technician develops a nagging fear that they wired something the wrong way after the fact, you need a culture where they can bring it up without immediate reprimands, firing, etc. Someone else brought up holes being drilled through spacecraft skin and then being filled in in an unapproved fashion. Unless they're a complete moron, someone doesn
Re: (Score:2)
Very true. Although that hole in the Russian space capsule was obviously incompetently drilled on a level that would justify a firing, including the person that hired that person. You could see how the drill wandered... Some level of incompetence is not covered by tolerance to errors anymore.
Re: (Score:2)
Kinda sounds like someone in Design trying to shift blame to Assembly.
KEY your identical connectors or you are inviting Murphy into the room. If Design invites Murphy to the party, you can't blame Execution for what happens as a result.
And this is not the same as the Vega sensor problem. Those sensors were keyed, but the idiots assembling it found it wasn't fitting right so they hammered it into place, breaking the alignment pin off to get it installed upside-down. THAT one you can blame on Assembly.
THIS
Re: (Score:2)
This might be one of those cases where a full functional test is not feasible. A well known example of that is the integrity of the semi-permeable membrane in a Lithium battery. You have to assemble the battery properly, with a tightly controlled procedure. I believe membrane failure is one of the things that makes the difference between a good battery, and a cheap imitation that is liable to burst into flames.
Again? (Score:5, Insightful)
This isn't the first time something like this has happened, and part of the obvious fix is to make it so that it's impossible to assemble the parts incorrectly. But at the very least, you'd think that from a software perspective they could program the computers (thanks to two-way communication with ground control) to look for this kind of situation so that it could be corrected for (ie reassign yaw as pitch, pitch as roll, roll as yaw)
Color-code (Score:5, Informative)
I often help small businesses set up their networks and there's nothing better than having an assortment of cable and electrical tape colors.
The red cable plugs into the red ports (usually switch cross-connects). The yellow cable plugs into the yellow ports (ISP). The purple cable plugs into the two routers (failover management). Blue connects to devices or, if we're really fancy, special VLANs get special colors.
But never green (males) . There's a nice Android app for helping out people with zero color vision. Labels can work for them but are generally unreliable.
Any system requires some level of conscientiousness, but that's how you can avoid wasting $220M on cabling errors.
Not human error - Procedural QC errors (Score:5, Insightful)
Human error may be responsible for incorrect connection of cables, but it is not responsible for the loss of the mission. The odds of a cascade of repeated human errors going through from assembly, checking, testing, and then independent verification are infinitesimal implying these quality control steps were not conducted.
Remember the Genesis mission? (Score:3)
https://en.wikipedia.org/wiki/... [wikipedia.org]
After a complicated deployment in space, years of collecting solar wind particles, and intricate stowage and re-entry sequence, that probe was destroyed at the very last moment by a bonehead human error. Years of work was lost.
Smarter software? (Score:2)
Personally, I’ve always held the mantra that you can’t depend on the human operator and systems have to be designed accordingly.
Re: (Score:3)
Nope. This makes things a lot more complex and hence the software will have a lot more problems itself, usually completely negating any advantages and usually causing more problems.
Robust design (Score:2)
Re: (Score:2)
At this time: Impossible. In the future: Unknown.
Re: (Score:2)
Unless you reversed the input/output of that neural net too. ;)
BTW, the other user is wrong: This is definitely possible today. But the computing power is quite high, and it is a crutch and a bullshit job. Better do it right in the first place.
All errors are human errors. (Score:2)
Re: (Score:2)
I thought about this too, and I guess there could also be something like unexpected weather or space aliens or something else that happens, even if everyone foresaw everything they possibly could and did everything right.
"Human error" is a cop-out (Score:3)
Human error only happens if somebody _else_ has screwed up rather badly before. This may be hiring of unqualified personnel, lack of training, bad corporate culture, insufficient processes and redundancies in processes, botched tech design that makes it far too easy to mess things up, etc. The person that finally makes the mistake that kills the device is typically the one with the least amount of responsibility for what happened.
Happened many times before. (Score:5, Interesting)
Regular technician was on vacation, the vehicle was tested by a new technician. He swore he tested the aelerons and the control inputs. Mystified till the director ordered the designers to watch the testing process. For the designers left aeleron is the left as seen by the pilot. To the technician it was left seen from the front, like the ground crew! Two errors cancelled each other and resulted in the loss of the vehicle.
Designers came up with strong training and testing procedures as the fix. The director said, "Put the technician behind the aircraft testing rig during the testing". Amazing guy, that diro. Eventually became the President of India. BTW he knew FORTRAN. I know. He asked me a FORTRAN question in the campus interview before recruitment.
Re: (Score:2)
This would be easy to verify, if you gave us the name of that director...
Re: (Score:2)
Re: (Score:3)
Anyway nautical terms are not commonly used in aircraft. And even aircraft/ATC terminology is unfamiliar to the missile/rocket workers. My alma mater changed the name of the school from "Department of Aeronautical Engineering" to "Depart
Re: (Score:2)
Anyway nautical terms are not commonly used in aircraft.
Waterline [yahoo.com]
Happened years ago.... (Score:2)
Similar Error on the Second Saturn V Flight (Score:5, Informative)
A similar assembly error was part of a cascade of failures during the flight of the second Saturn V (the uncrewed Apollo 6 mission). During the operation of the second stage (the S-II stage with five engines) engine Number 2 shut down early due to mechanical failure of a fuel (hydrogen) line. The safety system on-board then automatically shut off the oxygen supply to normally operating engine Number 3 because some wiring between engines 2 and 3 was mixed up. The flight had other problems, too, and would have been a mission abort if a crew had been on-board. This was the second Saturn V launched, the first one had flown almost flawlessly.
And now for the real reason (Score:5, Insightful)
When cabling and connector keying becomes an afterthought, this happens.
As opposed to what? (Score:2)
Space weather or ... aliens? ;)
Huh. (Score:3)
I'd been told by several friends in Europe that the "silly" American use of imperial measures was more or less the root human error that caused the destruction of the well-known Martian probe.
So HUMAN ERROR is possible even with complex rockets built entirely in the metric system?
Who'd have imagined it?
This still IS a design error... (Score:4, Insightful)
Disagree about design error (Score:2)
I respectfully disagree that there was no design error. The cables should have been designed such that it is nigh on impossible to plug them in wrong. At the very least, a unique label printed or branded into each male and female connector. Even better, unique form factors that are impossible to mate wrongly.
Static fire tests (Score:2)
There is a reason to why SpaceX is blowing up so much hardware on the testbed. They actually test those engines and rockets before assembling and sending them to space.
Reiteration and fixing stuff on the ground is challenging, but doing that after rocket is far away is impossible.
Should we really be doing this? (Score:2)
Re: (Score:3)
Re: From the no-shit department. (Score:2)
Re: (Score:3)
Yeah, that. I fix RVs and when rodents get into an RV and eat up the pipes and wiring (they love to eat PEX, and vinyl wire insulation) I don't blame the rodents. I blame the jackholes who designed and/or built the RV and failed to keep them out, which is always either a design or execution failure. We live in a world with rodents, and pretending otherwise is a human failure.
Re: (Score:3)
Re: From the no-shit department. (Score:2)
Just using bulkhead connectors instead of making big holes to run stuff through would have prevented the vast majority of rodent intrusions. They are opportunists like everyone else.
Re: (Score:2)
Re:From the no-shit department. (Score:4, Interesting)
A lot of engineering firms use 6 Sigma or some iteration of it. This is a case where you plan for problems up to 6 standard deviations out. This doesn't mean they will be 0 problems, But often when the problems do occur they are really rare out of left field. When they do happen, there is often a lot of finger pointing. Where it sometimes goes back to the engineer and asks them a question with no good answer? "Why didn't you think of that scenario?" They didn't think of it, because they didn't think of it, and because of their experience and what they were taught, it never really came up to be something to think of or consider.
I am often put on the hard project, where there is no clear solution, I like to think that I offer Out of the box solutions to problems that need to be solved, but never had been solved before. Most of the time, my crazy ideas work, but sometimes they don't and rarely they they will bomb spectacularly. I luckily tend to built up enough karma to weather a complete bomb. But it often comes down to the fact I didn't plan for that to happen, because I didn't think it would happen. Now that it did, then I will account for it the next time.
Humans are not perfect, so yes most problems could be pointed at some person, however should we really point blame for a root cause analysis. Often when something goes bad, their may be one person who triggered it. But they were in a system that didn't bother to catch them when they did.
Re: (Score:2)
Re:From the no-shit department. (Score:5, Insightful)
every error in a human endeavor is a human error.
Well, no. Some times things happen that are completely outside the capability of human beings to control. But in this case, the CTO of Arianespace is wrong to characterize this as "not a design error". The connectors on those two harnesses should have been keyed differently to prevent the possibility of connecting them incorrectly.