3 ms·

What I’m really interested is how do you engineer such a software system? I bet they have a simulation system, how do you validate that? What type of tests do t

What I’m really interested is how do you engineer such a software system? I bet they have a simulation system, how do you validate that? What type of tests do they have? How do they iterate when a deficiency is found? How do the team looks like? Is it 10 geniouses keeping the whole system in their heads or 4000 replacable cogs? If the second how do you make sure they all act in coordination?

bob1029 6y ago
In terms of how you would abstractly model this type of engineering problem, I would start with state space representation: https://en.wikipedia.org/wiki/State-space_representation https://en.wikipedia.org/wiki/State-space_representation
bamboozled 6y ago
It's "Geniuses", not sure why, it's just one word I feel strongly about being spelled properly.
richardowright 6y ago
They do have a very comprehensive simulation system with a large part of the work being done at Dobbins Air Force Base just outside of Atlanta. From what I understand, the team is quite small (<10).
icegreentea2 6y ago
Aerospace in general is all about "document document document", and "process process process". There's this classic article about programming for the space shuttle (https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff) that probably has reasonable parallels to how the raptor software was written. These approaches aren't problem free of course. They're definitely slow, and can appear to be inefficient depending on your frame of reference and constraints. My experience is in medtech which has similar ideas (but again obviously isn't the exact same). Ultimately all simulations used to prove that the software is working correctly are supposed to be validated (either in part or in whole) by some sort of real testing. The most expensive/real version of that is when they go off and do real test flights (or in medtech, when we go and do stuff on real people). The type of tests of they have is probably "all types of tests". You pick the right set of tests to test your software components at the scale and detail required, while finding ways to validate the assumptions you made along the way. For example, maybe you have a pure function that takes pitot tube measurements to generate air speed. You could test that function with something like a unit test, and then back it up with another set of test cases (integration or system or whatever) that show that the function is being called correctly in all cases. Every company/project will have their own Change Control process and defect resolution process defined. Typically they consist of someone reporting a defect, some sort of investigation into the defect (determining rate of occurrence, root cause if able, estimating the severity of the defect), which then gets fed into some sort of risk based problem solving algorithm to determine if an immediate fix is needed, or if there's flexibility. Then you go ahead and try to fix the thing, and when you're done, you go ahead and run more analysis to determine the scope of retest you need to do. If you're lucky, everything is self contained within the "pure software" part of your project and the "worst thing" that can happen is you have to re-run the whole software test suite. If you're not lucky, the change interacts with non-software components in ways that cannot be safely mocked out, and you have to add some kind of real world testing. I think most places lean more towards replaceable cogs - that is the whole point of all of this process and documentation. It's to minimize the overall risk of the project (which isn't the same thing as maximizing benefit). It's hard to minimize risk while requiring super top tier talent.
atlgator 6y ago
Every device/sensor communicates through a centralized bus which is essentially a messaging system (e.g. MIL STD 1553, ARINC 429). Furthermore, every device has a set of expected outputs for every internal or external input. You can build a software model that mimics that. Then it's just a matter of connecting your software to the bus. Flight control software aggregates sensory inputs from the bus, reconciles redundancies, and makes flight decisions.

bob1029 6y ago

In terms of how you would abstractly model this type of engineering problem, I would start with state space representation: https://en.wikipedia.org/wiki/State-space_representation https://en.wikipedia.org/wiki/State-space_representation

bamboozled 6y ago

It's "Geniuses", not sure why, it's just one word I feel strongly about being spelled properly.

richardowright 6y ago

They do have a very comprehensive simulation system with a large part of the work being done at Dobbins Air Force Base just outside of Atlanta. From what I understand, the team is quite small (<10).

icegreentea2 6y ago

Aerospace in general is all about "document document document", and "process process process". There's this classic article about programming for the space shuttle (https://www.fastcompany.com/28121/they-write-right-stuff https://www.fastcompany.com/28121/they-write-right-stuff) that probably has reasonable parallels to how the raptor software was written. These approaches aren't problem free of course. They're definitely slow, and can appear to be inefficient depending on your frame of reference and constraints. My experience is in medtech which has similar ideas (but again obviously isn't the exact same). Ultimately all simulations used to prove that the software is working correctly are supposed to be validated (either in part or in whole) by some sort of real testing. The most expensive/real version of that is when they go off and do real test flights (or in medtech, when we go and do stuff on real people). The type of tests of they have is probably "all types of tests". You pick the right set of tests to test your software components at the scale and detail required, while finding ways to validate the assumptions you made along the way. For example, maybe you have a pure function that takes pitot tube measurements to generate air speed. You could test that function with something like a unit test, and then back it up with another set of test cases (integration or system or whatever) that show that the function is being called correctly in all cases. Every company/project will have their own Change Control process and defect resolution process defined. Typically they consist of someone reporting a defect, some sort of investigation into the defect (determining rate of occurrence, root cause if able, estimating the severity of the defect), which then gets fed into some sort of risk based problem solving algorithm to determine if an immediate fix is needed, or if there's flexibility. Then you go ahead and try to fix the thing, and when you're done, you go ahead and run more analysis to determine the scope of retest you need to do. If you're lucky, everything is self contained within the "pure software" part of your project and the "worst thing" that can happen is you have to re-run the whole software test suite. If you're not lucky, the change interacts with non-software components in ways that cannot be safely mocked out, and you have to add some kind of real world testing. I think most places lean more towards replaceable cogs - that is the whole point of all of this process and documentation. It's to minimize the overall risk of the project (which isn't the same thing as maximizing benefit). It's hard to minimize risk while requiring super top tier talent.

atlgator 6y ago

Every device/sensor communicates through a centralized bus which is essentially a messaging system (e.g. MIL STD 1553, ARINC 429). Furthermore, every device has a set of expected outputs for every internal or external input. You can build a software model that mimics that. Then it's just a matter of connecting your software to the bus. Flight control software aggregates sensory inputs from the bus, reconciles redundancies, and makes flight decisions.