Static code analysis for airborne softare at armadillo?

I recently read John's blog entry regarding his use of
static code analysis in his work at id. Great stuff.

I work on safety-critical software - mostly aerospace stuff -
where we use _lots_ of supposedly "high end" static verification
tools, so this topic is really interesting for me.

So...based on your experience at id, what are you doing
with static analysis for your airborne software? Does your
approach differ from that reported on the blog?

If you think this topic is inappropriate for this forum,
then I apologise - I've no idea how to get in touch
any other way...

All the best,
Rod Chapman

Hi, welcome! This is the perfect place to ask this question, but Mr. Carmack hasn't been posting much lately (or really since he started a family, can't blame him at all...). Maybe Ben knows or can ask though?

I'd be surprised if he used much static verification at AA, or at all. He's always taken a build-test-build again kind of approach to building rockets, without relying much on simulations or computing things. I remember a remark in the early days of AA where he'd accidentally put a matrix in backwards, making the rocket steer with an attitude deviation, rather than against it. They found the bug when the rocket, hanging from the fork lift, turned out to be rather unstable . He quickly corrected the code, they tried again later that day, and it flew fine.

Also, for what they're currently trying to do, the code is probably not that complex, compared to a modern 3D engine. I imagine someone of Mr. Carmack's calibre getting by just fine with some regression and unit tests. Of course, that doesn't mean that static analysis is useless. I'd be very interested in his opinion too...

Here is his post about static code analysis:
http://altdevblogaday.com/2011/12/24/st ... -analysis/

Armadillo's code receives mostly the same treatment.

I looked into this a bit more yesterday, and also read Tim Sweeney's presentation on the topic. It seems to me that quite a few of those errors stem from C being such a primitive language, and its type system not being strong enough. For example, Java doesn't have the string processing problems that C has, or the printf type errors. Conversely, I could do quite a few of Sweeney's wishlist items in C++ today.

So, getting back on topic, what language is the AA code written in? Why?

Primitive = fast C
Advanced = slow Java.

Swings and roundabouts really. I'd guess AA code is either in C or C++.

FWIW, for the most critical embedded software that we do, we use SPARK - a contract-based Ada subset. I bet most readers have never hear of it though - it is something of a niche technology...

From my experience, turning up at the FAA and saying "well..it's all written in C, but don't worry becuase John's really really good..." won't get you very far...

Will FAA flight software guidance apply to Armadillo? Have you seen the forthcoming DO-178C guidelines?
- Rod Chapman