My usual Google skills aren't getting me anywhere on this one :)
2. The automotive industry has a standard for safety critical C code. It's called MISRA C. A few of the rules are stupid, but others will save you worlds of issues. You have to buy the PDF from the committee's website for about 15 bucks, but it's worth reading and mostly following.
3. If you are actually writing medical or flight control software, you cannot depend on a single proccesor or computer. Perfect software is not enough. Airliners have three separate computers, each containing three different processor architecture processors, each processor running code compiled on a different compiler, and all checking each others work. SpaceX runs at least five separate embedded linux computers for any critical systems. These communicate in such a way that they can tolerate even malicious actions by any two computers. Google "byzantine fault tolarance"
The issue I have with it is that some people seem to be refusing using their brain when following rules. For exampe, MISRA static checkers compain if you do:
x = 250
#define TWO_HUNDRED_FIFTY 250
x = TWO_HUNDRED_FIFTY
But in most cases what I want is not the number, it's the _meaning_ of the number. Be it the Command ID, ram block Address or whatever it is. Generally, having code sprinkled with magic numbers is pretty shitty.
In my view:
a = a<<18;
a |= b<<8;
a |= c;
case(ChoiceID):
switch 1:
/* Do somethin'*/
break;
switch 26:
/* Do somethin' else*/
break;
default:
break;
Even your "switch 26" isn't always bad. If the value only occurs in exactly that one place in your code, it's probably better to use a comment in plain English. A comment is more readable than DO_SOMETHIN_ELSE and, normally, would go right in the place where you actually use the value.
Get all the tools. There are free tools like "sparse", a tool Linus wrote for his kernel. There are expensive tools like Coverity. Get them all. Use them all.
Build your code with all the warnings enabled. Use multiple compilers, even if they don't compile for your target.
Of course a lot of safety critical stuff is still written in C or C++. They may not be perfect, but they're not terrible choices.
I can't help wondering if some of the problems the F-35 is having is because its software development is being done mostly in C++ and C.
Unfortunately, I would be really surprised if there is an Ada toolchain that can produce code for a microcontroller like the ESP8266.
In factory automation I have only ever seen C, and AFAIK automotive is the same (they seem to be more open to C++, though).
Most of safety-critical development (as I know it -- again, no satelites or nuclear stuff) is documentation, testing and FMEAs. Quite a bit of "patterns" or procedures, as well, like memory testing in the background, redundant variables, cross checks between controllers, plausibility checks etc.
But very, very little focus on saner programming languages.
And it looks like some folks have already been using Ada on the ESP8266, here are instructions: https://github.com/RREE/esp8266-ada/wiki/Steps-for-building-...
https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Dev...
The summary would be:
Use vanilla C with some rules about things like memory, testing, and recursion. Testing and static analysis are your friends.
The ESP8266 is a low-cost Wi-Fi chip with full TCP/IP stack and microcontroller capability produced by Shanghai-based Chinese manufacturer, Espressif.
What piqued my curiosity was this project:
It's basically a homebrew controller implementation that uses data from a continuous blood glucose monitor to talk to an insulin pump. They're using Node and JavaScript from what I can tell from the GitHub. They're obviously conservative for safety concerns. The code runs on a Raspberry Pi 3.
This got me wondering - what language WOULD be used in 2016 to code something safety-critical? Is there anything coming from research that's better than C? My initial thoughts were something like Elixir, but really anything strongly type-checked and verifiable. Rust was another thought I had.
Looking at this my immediate thought was also "what's the tiniest micro that could do this job instead of the power-hungry Pi?".
I guess everything is C or assembler in the end anyway :) The impression I get from these responses is that a restricted subset of plain C seems to be the most practical solution today.
EDIT: I'm the OP if it isn't obvious, different account.
I had a look around and I can only guess that the extensive hard limits that they document in their design fulfil the safety requirements on their own.
Unfortunately, I only know their name and never use it.