[HN Gopher] I Compiled NASA's Workmanship Standards into a Singl...
___________________________________________________________________
I Compiled NASA's Workmanship Standards into a Single PDF
Author : muunbo
Score : 165 points
Date : 2020-08-28 11:13 UTC (1 days ago)
(HTM) web link (archive.org)
(TXT) w3m dump (archive.org)
| [deleted]
| nosmokewhereiam wrote:
| This goes well with https://llis.nasa.gov/
|
| "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."
| fallingmeat wrote:
| How do these compare to the IPC standards? Redundant?
| muunbo wrote:
| Hmm I have no idea! Are the IPC standards publicly available
| for me to check out?
| m0zg wrote:
| TIL that most of my electronics work is well represented in the
| "bad" sections of the NASA manual. Then again, I'm not launching
| it to Mars, so it's OK.
| muunbo wrote:
| Haha! It's helpful regardless for non-space projects. For e.g.
| I made "rave skates" (colour shifting LEDs on ice skates) and
| the connections on it have to be robust to abrupt movements and
| forces.
| vladTheInhaler wrote:
| Wow this gives me flashbacks. I interned there one summer,
| working on a project that was in absolute crunch mode with no
| budget left for the fiscal year.
|
| 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.
| Commodore_64 wrote:
| Quite impressive. Good job dude!
| supernova87a wrote:
| If only these existed for blocks of code.
| pjc50 wrote:
| MISRA C may be the nearest thing.
| ishcheklein wrote:
| They have this famous one -
| http://spinroot.com/gerard/pdf/P10.pdf
| (https://dev.to/xowap/10-rules-to-code-like-nasa-applied-
| to-i...)
| jedimastert wrote:
| Rule number one includes no recursion, which I get but is
| also really interesting to me. I feel like I could turn any
| recursive algorithm I'd use in production into a loop, but I
| feel like it would trip me up
| jkaptur wrote:
| I was nodding along to this, but this gave me pause:
|
| > 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?
| richard_todd wrote:
| If your code is swinging a multi-million-dollar robot arm
| near a multi-million-dollar mirror assembly, for example,
| it's probably not seen as excessive to add recovery code
| even if some of those assertions will only be active during
| testing phases.
| tester756 wrote:
| I think keyword here is
|
| >performance-critical code.
| throwaway_pdp09 wrote:
| Seems odd also. My understanding of assertions is if they
| fail, there really can be no recovery because you've
| reached an impossible state (impossible = this should not
| ever have happened).
| jacobwilliamroy wrote:
| Not exactly. For example during an automated download, if
| an http status code is not 200, it's perfectly fine to
| yield, delete the incomplete data from the failed
| download, and try the download again. Same thing with
| checking data integrity. If such fails, one can simply
| delete, redownload, rehash, and set a variable upper
| bound on the number of retries.
|
| Of course nothing in space, keeping astronauts alive,
| should be using the web.
| colechristensen wrote:
| You might be misled by the use of the word "recovery",
| returning an error condition in many areas of performance
| critical code while running in production just results in a
| loss of vehicle, there's no coasting in a rocket launch,
| bugs usually mean explosions.
|
| 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.
| jedimastert wrote:
| > 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.
|
| 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
| Jugurtha wrote:
| You'll like this:
| https://www.usenix.org/conference/hotdep12/workshop-program/...
___________________________________________________________________
(page generated 2020-08-29 23:00 UTC)