F-35 Joint Strike Fighter Coding Standard Documentation(www2.research.att.com)
www2.research.att.com
F-35 Joint Strike Fighter Coding Standard Documentation
http://www2.research.att.com/~bs/JSF-AV-rules.pdf
11 comments
OH: "Any sufficiently complex DoD coding standard is indistinguishable from Ada"
Maybe that's true in general, but so far this seems like a perfectly sensible C++ coding standard, especially for a stealth fighter.
Seems like it would have been much easier to just use Ada, than deal with all the potential pitfalls of C++.
IIRC, C++ is used for some specialized jobs like signal processing. Ada is used for the avionics and systems management.
Really? I could be wrong, but I thought the F35 was officially not using Ada for anything.
According to this (2003) it's 4% of the flyable software: http://sstc-online.org/2003/PDFFiles/pres1478.pdf
The linked paper also gives a summary of the issues with using Ada -- tl;dr: We like the language, but no one's learning it and no one's supporting it.
Which is kind of sad, because the very thing that makes Ada useful -- stability and maturity -- is the thing that's killing it.
The linked paper also gives a summary of the issues with using Ada -- tl;dr: We like the language, but no one's learning it and no one's supporting it.
Which is kind of sad, because the very thing that makes Ada useful -- stability and maturity -- is the thing that's killing it.
Interesting. Thanks.
Seems like there is pretty good support now from AdaCore.
The main thrust of this appears to be that "fresh college graduates are not putting Ada on their resumes."
I suppose these guys from Lockheed know what they're talking about... but to me, the idea that you pick a language based on whether it's being taught in universities is just asinine. If your engineers are not smart enough to learn a new language, they're not smart enough to go near any kind of software that has anything to do with an airplane.
Even more troubling, this suggests that engineers are treated as "cogs" that can't be re-trained and just become obsolete as soon as the "main language they learned in school" (the top places don't focus down on one language too much IMO) becomes obsolete.
Seems like there is pretty good support now from AdaCore.
The main thrust of this appears to be that "fresh college graduates are not putting Ada on their resumes."
I suppose these guys from Lockheed know what they're talking about... but to me, the idea that you pick a language based on whether it's being taught in universities is just asinine. If your engineers are not smart enough to learn a new language, they're not smart enough to go near any kind of software that has anything to do with an airplane.
Even more troubling, this suggests that engineers are treated as "cogs" that can't be re-trained and just become obsolete as soon as the "main language they learned in school" (the top places don't focus down on one language too much IMO) becomes obsolete.
Agreed, it's troubling. Ada is easier to learn than C++.
I'm wondering if the whole thing was orchestrated by C++ static analysis tool vendors. Or some set of byzantine keyword-centric recruiting requirements make it difficult to hire someone who is capable of learning Ada.
I'm wondering if the whole thing was orchestrated by C++ static analysis tool vendors. Or some set of byzantine keyword-centric recruiting requirements make it difficult to hire someone who is capable of learning Ada.
Have you ever actually used Ada? The standards document is incredibly clear and well-organized, to the extent that most Ada programmers use it for reference.
I have -- and I'm not busting on Ada, quite the contrary -- I'm pointing out that many of the rules in the C++ document would not be necessary were they coding in Ada.
(I'm sure they use static analysis tools for C++ that enforce some of these rules, so I'll defer to someone who is more current in that world)
(I'm sure they use static analysis tools for C++ that enforce some of these rules, so I'll defer to someone who is more current in that world)
"Any sufficiently complicated DoD standard contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Ada."
This made me laugh:
AV Rule 6 Each deviation from a “shall” rule shall be documented in the file that contains the deviation. Deviations from this rule shall not be allowed, AV Rule 5 [specifying the process to deviate from a "shall" rule] notwithstanding.
AV Rule 6 Each deviation from a “shall” rule shall be documented in the file that contains the deviation. Deviations from this rule shall not be allowed, AV Rule 5 [specifying the process to deviate from a "shall" rule] notwithstanding.
Definitely reads like stereotypical government-associated-anything, then.
Yes, such needless bureaucracy.
Let's fly a crazy fast jet plane that has it's software written by some throw-caution-in-the-wind Node.js hackers instead.
If it's agile enough, and has some test coverage, we should be fine.
Let's fly a crazy fast jet plane that has it's software written by some throw-caution-in-the-wind Node.js hackers instead.
If it's agile enough, and has some test coverage, we should be fine.
>Let's fly a crazy fast jet plane that has it's software written by some throw-caution-in-the-wind Node.js hackers instead.
Because that's exactly what I said, or even hinted at.
I said the document reads like overly verbose government copy. Nothing more.
Because that's exactly what I said, or even hinted at.
I said the document reads like overly verbose government copy. Nothing more.
Even if the original comment were advocating that, which it's not, it remains to be demonstrated that the number and seriousness of the bugs would actually get worse if the software were developed using a different kind of language.
And I'd never suggest JavaScript for that.
And I'd never suggest JavaScript for that.
>Even if the original comment were advocating that, which it's not, it remains to be demonstrated that the number and seriousness of the bugs would actually get worse if the software were developed using a different kind of language.
No, it has _already_ been demonstrated, not only for the language, but for the process.
What remains to be done is for people saying that it remains to be demonstrated to educate themselves with the relevant papers.
No, it has _already_ been demonstrated, not only for the language, but for the process.
What remains to be done is for people saying that it remains to be demonstrated to educate themselves with the relevant papers.
Hell yes,
Although seriously, I wonder what the end difference in bugs and software related (hardware) crashes would be? And also the cost of development and speed with which updates could be released. (No i'm not really advocating it, but it would be fun).
Check this article if you are interested in the topic, it's quite illuminating (although a little journalistic):
http://www.fastcompany.com/magazine/06/writestuff.html
http://www.fastcompany.com/magazine/06/writestuff.html
AV Rule 25
(MISRA Rule 127)
The time handling functions of library <time.h> shall not be used.
Yes everyone reinventing their own broken flat tire date routines is the way go. If they used the same silly rule on the F22 that explains http://blog.utest.com/international-date-line-bug-caused-fig...
Time related code is really hard to write.
Yes everyone reinventing their own broken flat tire date routines is the way go. If they used the same silly rule on the F22 that explains http://blog.utest.com/international-date-line-bug-caused-fig...
Time related code is really hard to write.
It says this in the article:
The problem arose not from the time change, but from the change in longitude
I don't think you can blame the time handling for that one! Although you are right in the broader sense that is really difficult to write code that handles times and dates correctly, and you generally shouldn't write you're own. I'd imagine the guys writing this stuff are pretty good though and can probably handle it.
The problem arose not from the time change, but from the change in longitude
I don't think you can blame the time handling for that one! Although you are right in the broader sense that is really difficult to write code that handles times and dates correctly, and you generally shouldn't write you're own. I'd imagine the guys writing this stuff are pretty good though and can probably handle it.
You mean nobody told you about the time.h backdoor? It's a classic.
The rules seem quite reasonable and less strict than what I had expected. The libraries section mentions "Only DO-178B Level A certifiable" libraries. Are any common open source libraries among those and is there a list available somewhere? Another HN thread mentioned that there are certified C++ standard libraries but I couldn't find any vendor of such.
I suspect not, but I'd be happy to hear otherwise. Certification is as much about process and traceability as it is about the code itself. Open source naturally tends to give visibility into the development process, but there's usually no business driver to spend the money on certification. Think multiple thousands of dollars per line of code.
You cannot certify libraries.[1] The best you can do is to provide a certification kit which consists of tests to be run in the target environment and appropriate documentation/traceability.
However, as the GP notes the libraries must merely be "certifiable": You can do all the certification work yourself as long as it is possible with the libraries in question. Having access to the source code and the lack of non-determinism are two big requirements that come to mind.
[1] In fact you cannot even certify software only entire systems.
However, as the GP notes the libraries must merely be "certifiable": You can do all the certification work yourself as long as it is possible with the libraries in question. Having access to the source code and the lack of non-determinism are two big requirements that come to mind.
[1] In fact you cannot even certify software only entire systems.
Referring to [1]: So, if I would try to sell libraries targeted at avionics there is no way for me to get certification for that specific library? Is there a way to guarantee "certifiability"?
Sorry for the late reply.
Sorry for the late reply.
That's why the DoD loves RedHat so much, they let you pay them money for their distribution, and then you can use all the libraries that come with it.
I don't believe they are just sitting out there like open source. I believe you will have to purchase this libraries. Just like you. However, the problem boils down to the fact that you will be developing on custom hardware, thus the libraries will probably not be reusable. Basically you have to prove that all lines of code are part of the requirements, no dead code. You will also have to prove that all code fails in a fail safe manner. I.e. the plane won't crash
Level A cert is for flight critical systems, I.e. flight controls.
This is your best bet. http://www.open-do.org/about/
Very interesting site. Thanks for sharing.
Unfortunately, it looks like it's been static since 2010.
Unfortunately, it looks like it's been static since 2010.
I don't know why you say that; the blog is receiving updates and at least some of the sub-projects are logging commits.
Well, I'll tell you why, in case you are the person in charge and can do something about it.
If I click through the links at the top of the page, there is no real indication of "staleness or non-staleness," until you get to Open-DO Conference, which has material from 2010 presented as if it's new. Then, the next link ("Forge") has "Latest News" from 2010.
Update: I did not even realize there was a blog, because you linked me to open-do.org/about/ instead of just open-do.org. There is no evident link to see a blog, so the assumption of the website designers must be (perhaps unfortunately) that you always enter directly through open-do.org. It turns out that clicking the title graphic will take you there as well, but someone who is initially linked to the "about" page would never think to click on that.
If I click through the links at the top of the page, there is no real indication of "staleness or non-staleness," until you get to Open-DO Conference, which has material from 2010 presented as if it's new. Then, the next link ("Forge") has "Latest News" from 2010.
Update: I did not even realize there was a blog, because you linked me to open-do.org/about/ instead of just open-do.org. There is no evident link to see a blog, so the assumption of the website designers must be (perhaps unfortunately) that you always enter directly through open-do.org. It turns out that clicking the title graphic will take you there as well, but someone who is initially linked to the "about" page would never think to click on that.
By the way, thanks again. I'm not interested in the details of the sub-projects right now, but now that I have found the blog, my personal valuation of the site has gone from "encouraging" to "actually quite useful." I've already found interesting/relevant reading on the blog.
The buses used on aircraft are interesting. ARINC 429 is used for commercial aircraft. MIL-STD-1553 is used for military aircraft. STANAG3838 is the EU equivalent.
(http://en.wikipedia.org/wiki/ARINC_429)
(http://en.wikipedia.org/wiki/MIL-STD-1553)
Wikipedia suggests a logic analyser for development. That's handy, but you'd be best starting with good continuity buzzing; I've seen some of the cables being made and it's a bit of a bodge.
(http://en.wikipedia.org/wiki/ARINC_429)
(http://en.wikipedia.org/wiki/MIL-STD-1553)
Wikipedia suggests a logic analyser for development. That's handy, but you'd be best starting with good continuity buzzing; I've seen some of the cables being made and it's a bit of a bodge.
Apparently the F-35 is a bit of a departure from traditional aircraft systems in that it uses Firewire as the bus and Fibre Channel for mass storage: http://www.ttcdas.com/products/rec_mux/pdf/_tech_papers/tp_f...
Most likely using 1553. Since its a military aircraft and most DoD equipment for aircraft use 1553. AIRNC 429 is typically isninly user when trying to integrate a COTS equipment. However 1553 wouldn't be ideal for exchanging large amoints of data.... more like "status" and switching. Its highly deterministic regarding timing of messages.
Interesting that this document is stored on Bjarne Stroustrup's (creator of C++) web site at AT&T Labs. I wonder whether he had any part in writing it?
He did. From http://www2.research.att.com/~bs/bs_faq2.html:
> ...I consider it a pretty good set of rules for safety critical and performance critical code. If you do embedded systems programming, you should consider it. Caveat: I had a hand in the formulation of these rules, so you could consider me biased...
> ...I consider it a pretty good set of rules for safety critical and performance critical code. If you do embedded systems programming, you should consider it. Caveat: I had a hand in the formulation of these rules, so you could consider me biased...
I remember reading this some years ago (unless this is a new version)
Dear C++ programmers: follow this! (with exceptions accordingly)
Dear C++ programmers: follow this! (with exceptions accordingly)
> Dear C++ programmers: follow this! (with exceptions accordingly)
These strict C++ programming guidelines apply only to embedded and safety critical programming and the programs that are being written work under a very restricted runtime environment and with a less than state of the art compiler.
So if you're a regular application programmer working with C++, feel free to ignore most of these rules. Modern compilers and runtimes will work nicely with most of the stuff forbidden in these guidelines.
These strict C++ programming guidelines apply only to embedded and safety critical programming and the programs that are being written work under a very restricted runtime environment and with a less than state of the art compiler.
So if you're a regular application programmer working with C++, feel free to ignore most of these rules. Modern compilers and runtimes will work nicely with most of the stuff forbidden in these guidelines.
True, but not most rules
There are some limitations there relating to embedded systems (for example, they explicitly forbid the use of atoi because obviously you want to be sure of no undefined behavior while flying at Mach 2 at 20kft)
For example, section 3 are very general good rules
Av Rule 84/85 are very relevant as well (just an example)
It's very easy to exaggerate when using C++ and hence some limits are needed.
There are some limitations there relating to embedded systems (for example, they explicitly forbid the use of atoi because obviously you want to be sure of no undefined behavior while flying at Mach 2 at 20kft)
For example, section 3 are very general good rules
Av Rule 84/85 are very relevant as well (just an example)
It's very easy to exaggerate when using C++ and hence some limits are needed.
My brother works for Lockheed writing technical manuals. He is the guy who writes those things. I mean, I can't even read them without runing away screaming.
He studied IT, but never got a job in it. I keep bugging him to get a job coding, but he thinks he can't.
Anyone got a job coding for someone who writes those amazingly complex manuals?
He studied IT, but never got a job in it. I keep bugging him to get a job coding, but he thinks he can't.
Anyone got a job coding for someone who writes those amazingly complex manuals?
There's an error in Rule 52. They specifically say variables shouldnt have any capital letters but their example does.
if you're talking about this example:
const uint16 max_pressure = 100;
enum Switch_position {up, down};
Just to add to what was already said, the doc said for enumerator values - which are indeed lower case in the example. Not a blanket statement for all variables.
No it isn't, it's an enum type.
Perhaps I found an error.
AV Rule 69 says to use `const` by default on member functions. Yet in some examples (e.g. AV Rule 122 in Appendix A) they don't use the `const` keyword when they can.
AV Rule 69 says to use `const` by default on member functions. Yet in some examples (e.g. AV Rule 122 in Appendix A) they don't use the `const` keyword when they can.
Nevermind. :-)
With rules like that, this plane is going to be vapourware for a long time!
No. That's complete nonsense.