I Compiled NASA‘s Workmanship Standards into a Single PDF
archive.org
archive.org
I and some other interns got press-ganged into helping assemble a prototype device ahead of a visit from some higher-ups at (I think) JSC, and I ended doing a lot of soldering - something I had only a little experience with before that summer. As I was learning, I spent a lot of time with one of the electrical engineers scrutinizing my practice pieces under microscope for tiny scratches in the conductor and little burn marks. I also distinctly remember burning my fingers over and over using the thermal wire-stripper, since it tended to made the conductor extremely hot.
I ultimately ended up having very little confidence in my workmanship, and when I found out that the thing we were working on might end up flying on the ISS, I became terrified that I would read about a fire on the station someday and not know if it was because of something I had messed up. That was also the summer I got my first gray hair.
if you don't mind me asking how long ago was this?
Yeah, it was incredible - very stressful, but I learned an enormous amount in just a few months. And I was surrounded by a ton of extremely smart, motivated (though sometimes rather dysfunctional) people. I just wish I had the knowledge then that I have now. In retrospect, the project I worked on really touched on almost every single aspect of mechanical engineering, and it was really what steered me in that direction. I wish I could talk more about it. It's not classified or anything, but it's very specific, and I'd rather not dox myself by accident.
"The NASA Lessons Learned system provides access to official, reviewed lessons learned from NASA programs and projects. These lessons have been made available to the public by the NASA Office of the Chief Engineer and the NASA Engineering Network. Each lesson describes the original driving event and provides recommendations that feed into NASA’s continual improvement via training, best practices, policies, and procedures."
On top of that, there’s often so much schedule pressure that project managers may only do a cursory look (if any at all) and unlikely to add anything of their own
How did you create this compilation?
Also, pages seem out of order, with blank pages, but I guess that's to print that to leaflets?
One thing to remember though is often Mil spec or custom builds actually require better quality than IPC or J-std gives. IPC/J-std are "Minimum acceptability requirements"...meaning "How bad can it be before I am required to fix/scrap the part?" Every time you rework a board you damage it (they are actually being damaged every time they are heated) so you only want to rework if absolutely required.
As far as “minimum requirements” I completely agree. As with all specs, they define the lowest level of acceptable characteristics. Especially if done by contractors this will be the aim since they rarely make additional money going above and beyond minimum standards, but can often lose money doing so
I did some poking around and discovered that the problem is that all those drawings are incredibly detailed vector art. The "proper solution" is to open each page with Inkscape and convert those vector art drawings into regular bitmap images, probably encoded in JPEG to save space.
Alternatively, you can get a reasonable quality DJVU file for under 50 MB with:
pdf2djvu --dpi=900 --verbatim-metadata -j4 "NASA Workmanship Standards.pdf" -o "NASA Workmanship Standards.djvu"
300MB is 0.06% of 512GB.
> Assertions must always be side-effect free and should be defined as Boolean tests. When an assertion fails, an explicit recovery action must be taken, e.g., by returning an error condition
> ... Because assertions are side-effect free, they can be selectively disabled after testing in performance-critical code.
Why would you put in recovery logic in if you're just going to disable it?
For example, let's say that I've got a new algorithm for calculating the cosine. Just to be safe, I add an assertion that the return value is in [-1, 1], and return an error if it isn't.
Now the clients of my code (say, the guidance computer) deal with the error somehow: if cos(x) returns an error, show an error to the pilot and maintain course or something.
If that assertion were stripped out in production code, then there was no point in writing the recovery logic. I've never written safety-critical code - am I missing something?
Of course nothing in space, keeping astronauts alive, should be using the web.
In such scenarios you can only kill the process - there’s no way to recover from such an error and handling it in any way but by disabling the subsystem (or killing the process) is impractical.
>performance-critical code.
There are also many time critical code paths where microseconds matter.
Think of assertions in lots of places more like unit tests, important to verify your code but unhelpful in production.
Failure recovery can be whole entire systems for production which are much different than assertions.
I believe the idea here is that, if you've tested your code correctly, the assertions are never triggered and therefore your constraints are met and you don't need the checks anymore.
Somewhat interestingly, the Chromium code base does something similar. There are `DCHECK` macros everywhere that are assertions that crash if the condition is false (for instance if a variable is null or some such) but they're disabled in production builds
These rules are for guaranteed-response-time algorithms that take data from a fixed number of places, do computations on it using fixed-size buffers, and write the data to a fixed number of places. They aren't for writing general Turing-complete computations in all their variety.
If you're in the business of developing ultra-low-defect software, and you aren't committed to C, SPARK Ada is another option.
[0] https://learn.adacore.com/courses/SPARK_for_the_MISRA_C_Deve...
I imagine the compiler situation would need to change before this could become a possibility. I doubt off-the-shelf Rust/LLVM is appropriate for compiling life-and-death code.
I imagine it would also be necessary to strictly control memory management, using pools rather than doing the equivalent of malloc/free. It seems Rust has a crate for that: https://docs.rs/heapless/0.5.5/heapless/
> I've only ever met one engineer who actually liked coding in Ada.
It certainly lacks many luxuries. For that matter, it also lacks basic examples. I tried to dabble with Ada recently, and pretty quickly ran into trouble (I was unable to figure out how to instantiate any of GNAT's 'bounded containers').
with Ada.Text_IO; use Ada.Text_IO;
with Ada.Containers.Bounded_Vectors;
procedure Main is
package BV_Integer is new
Ada.Containers.Bounded_Vectors (Index_Type => Positive,
Element_Type => Integer);
use BV_Integer;
Vec_Max : constant := 10;
Vec : Vector (Vec_Max);
begin
Put_Line ("Appending some numbers...");
for I in 1 .. Vec_Max loop
Vec.Append (Integer (I));
end loop;
Put_Line ("Appending another number...");
Vec.Append (Vec_Max + 1); -- this raises an exception.
end Main;Source: I was IPC trained for QA/technician at one point (as well as soldering and assembly)
Kinda similar to meeting ISO or AS standards. When in doubt, you default to whatever the spec in the drawing states