Workmanship standard for crimping, interconnecting cables, harnesses, and wiring
standards.nasa.gov
standards.nasa.gov
I am lucky to have built a large amount of harness has/is/will fly on many spacecraft for many customers. There are a lot of unique challenges to crimping for spacecraft harnessing, but in almost all circumstances the main issue has be schedule. Very few project managers that I have worked with, even those who have a lot of experience, plan for enough time to complete the harnessing side of a project.
Depending on the number of crimping configurations that are present in a system, it can take days to calibrate all of the crimp tools before starting. Every crimp needs to be inspected before the heatshrink can be shrunk, and often before the next crimp can be performed if the routing is critical. Routing involves labeling, gluing of tie-bases, bundling of harnessing, and the shielding.... jesus christ the shielding can be a nightmare...
Man I love making harness, honestly one of my favourite things to make. Not sure if anyone cares enough to have questions, but happy to answer them if they exist.
I spent a few years working in IT Support before deciding to go back to University to study Spacecraft Engineering at Surrey University. Which was a wonderful course, that gave an incredible overview of how one builds a spacecraft. More than most of the Master programs I have seen in the field since, the guys at Surrey had very real experience building quite a few spacecraft, which shone through in the projects and courses.
After that I started a PhD in Southampton that had an industrial sponsor, who eventually ended up offering me a job to build spacecraft before I finished the PhD itself (which was a little complicated in itself), which I took.
After I started with them, I basically apprenticed under an experienced AIT engineer who was coming up to retirement. This is where I really learned a lot. If you ever get the chance to work under someone in the later stages of their career, you really can learn a lot from them.
That was at OHB Sweden, which was an excellent place to see a broad range of things in the industry. I go to work on multiple spacecraft and various stages of development, from proposal, to qualification, to final assembly and test, and to launch as an operations engineer. Really a super experience I am not sure I could have been luckier ending up there.
After that I joined a very small team building the ispace lunar lander, which I am fairly certain will remain the pinnacle of my career. Never have I worked with such a great team on a great project. Everything just worked between us, and a small team really achieved something spectacular (even if it ended up in a crater on the moon).
Now I am working in Ireland for a data acquisition system developed for flight and launch vehicles. Learning the ins-and-outs of ethernet communication and analog circuitry. So far my complete lack of understanding of electronics hasn't been a problem, somehow.
I hear you on scheduling too. I've given best estimates and they then get chopped up and halved (or worse) by management types, then things start to slip and we end up being closer to what was originally estimated, but somehow everyone then gets surprised.
Secretly I love the power that can give us. You can shout at me all you like in the meetings Mr. ESA engineer, but if the holes don't line up, I cant put a bolt through them. Nothing quite like drilling holes in spacecraft on the launch pad.
But then those are mostly the cheap ones with the plastic rings so you can't really see what's going on inside them.
For under/over crimping, thats mostly taken care of with the tool calibration. And every shift (work day or X crimps) samples are taken to check the tool is still performing well.
One job was to look for outliers in the network, and they spent time studying areas with an unusually large number of issues and ones with an unusually low number of issues.
There was a part of the phone network that was decades overdue for an overhaul but had no issues, so they inspected it. (This was decades ago, so the replacements for this antique could be modern day museum pieces).
When they took a look, everything was corroded beyond reason, as expected. However, the connections were still low noise / low resistance.
The old boxes used some sort of post connector and a crimp. It had something like two or four points of contact for redundancy (all contact points would need to corrode before it failed).
In the boxes with no failures, the (long gone) technician simply stuck the end of the wire into the post crimp hole, then wrapped slack wire around it a dozen times.
This gave it 100’s of contact points, and (after reverse engineering the technique) it took something like 1/10th as long per connection.
Sadly, we’ll never know if the installer was a genius, lazy or both.
Anyway, the crimp connectors in fig 19-25 and 19-28 of the nasa article look like the same concept but turned inside out.
Fuck punchdowns and everyone who said “good enough for me” when deciding to adopt them.
On a brand new install? Sure it works great!
In a box that has been sitting in the rain for a little over a decade? No.
I'm only coming from shade tree car AV installation though. Nobody (probably) dies when it fails.
I cannot speak to the newer systems on the market like Starlink, their economies of scale are closer to car manufacture, so for harnessing, they likely do it similar to that industry. Form boards and very repeatable methods for producing a harness that has been well designed into the chassis of the spacecraft to be installed at a specific point. But much of those techniques are relatively unchanged from what I do, just the timing and overall design is more optimised.
Most of the harnessing I have done is very bespoke, and happens at many stages throughout the integration as things are installing, finalised, and what-not.
Honestly, as things are looking, I am likely to be leaving the space sector in the near future, so I am not too worried about protecting my job or future on that front. The more accessible space is the better, even if that means people like me become less common.
I have used other manufactures with their own propriety connectors, like Harwin, which are a bit awkward.
The various styles of connectors do matter a bit. Micro-DSUB and Nano-DSUB are a bit of a pain, as you generally get the connector with flying leads, so have to inline (butt) splice.
38999 Circular connectors are great to work with the hardware, but order the right parts is a nightmare as they all have phone number part names.
Recently the Peregrine Lander had wiring issues that led to using the NASA payload to perform the landing. The Vega-C launcher was lost not long ago as two connectors were swapped, connecting two engines in reverse order.
Wiring issues cause a lot of failures that are found on-ground for the most part. But plenty have made it through to fail on orbit.
In particular
>Lockwashers
>The typical helical spring washer shown in figure 14 is made of slightly trapezoidal wire formed into a helix of one coil so that the free height is approximately twice the thickness of the washer cross section. They are usually made of hardened carbon steel, but they are also available in aluminum, silicon, brome, phosphor-bronze, stainless steel, and K-Monel. The lockwasher serves as a spring while the bolt is being tightened. However, the washer is normally flat by the time the bolt is fully torqued. At this time it is equivalent to a solid flat washer, and its locking ability is nonexistent. In summary, a lockwasher of this type is useless for locking.
Of course, this is not all the source of cost but it is a good chunk. But, if you're building spaceflight hardware that can't be repaired once launched, it is necessary.
I was proud of not only of how effective yet non-encumbering the practices, and how smart our external assurances, but the lightweight way of implementing traceability between the two. A single, short internal document tracked not only practices, but sections were annotated with all the external documents/instances that made assurances wrt to those practices. So when we did need to change something, we knew what was easy and hard to change. (Interface vs. implementation.)
Of course, the very first externally-shareable document side of this, I explained to our enterprise salesperson that it would convince the partner's savvy IT people that we were fully competent and diligent, and said a bit about how everything in there was carefully designed and traceable... Well, maybe you can guess how that went.
Not everyone is familiar with building things that really have to work correctly, nor with how a little bit of judicious process can actually make things dramatically more efficient, nor with any kind of traceability rigor. If you're not familiar with that, or aren't aligned with that, then the most efficient thing in your mind might be to quietly change a copy of engineering document, to say whatever is most expedient in the moment. And don't tell anyone that you changed a copy of an engineering document, since that would not be a happy vibe when everyone likes what you're saying, and so not a good use of your time. :)
(I default to confidentiality about such things, even in absence of NDA. But I can mention this anecdote, in this professional practice discussion within the field, since the company is no longer in business, and there are no unresolved liabilities.)
There are different contract types with award fee and/or incentive fees each with its own peculiarities.
The Federal Acquisition Regulations (FAR) make for interesting reading:
https://www.acquisition.gov/far/part-16
" Part 16 - Types of Contracts"
The business is:
If profit is % of X Then maximum X
You might be joking here but in case you're not, there is serious configuration control and change management at play. Documents go into a controlled repository, are watermarked, and have other protections applied to them. Anyone trying this especially on a government contract is risking a lot.
Right after being told that things are written as they are for good reasons, and there's traceability, and how this is good for our credibility, and the exact way things were done is a big win for our engineering agility.
I brought small bits of inspiration from aerospace engineering there, but sometimes an organization has surprise pockets of more remedial learning that are needed. Like the lesson of, "You can't just say whatever you think will have a good vibe with the partner/customer in the moment, when it's about engineering, contracts, etc."