Software Facilities
There is a lot of custom - and very complex - software that is developed under the supervision of the Software Engineering section. In most cases, this software targets the embedded platforms that fly in our missions. The tools and technologies we use therefore, are geared towards the very specific needs that safety-critical embedded software has; and more specifically, software that will execute in space.
Complete software failure - the kind that is experienced in everyday computers and phones - is literally not an option with our software.
Compilers and debuggers
The software that ends up being executed in our embedded platforms, is (mostly) written in low-level programming languages (C and Ada, mostly).
There are two reasons for this:
- Our embedded platforms are optimized for safety, not for speed - so the processors running in them cannot really handle the costly abstractions that high-level languages come with (bytecode interpretation, garbage collection, etc). Real-time reactions to sensor-provided stimuli cannot wait for a VM to interpret bytecode, a garbage collector to do its sweep, etc.
- In addition, resource usage (e.g. both CPU and memory load) are engineered to be minimal. The HW designs are made to withstand the hostile environment of space - not to be in the GHz/Gigabyte ranges.
In addition, there's a strong philosophy towards open-source - we need to be in complete control of what is happening, because we may (and indeed, have on occasion) the need to go low enough to see what a compiler does, and how we can do custom modifications to its code generation policy to cover our needs.
We therefore mostly use cross-compilers based on GCC - that is, compilers that run in normal PCs, but generate code that runs in our specific target CPUs (LEON) and architectures. We are also investing in LLVM, because the much clearer Abstract Syntax Tree representation allows us to develop our own analysis tools (and also re-use the ones that come from the community surrounding LLVM).
As for the GNU toolchain surrounding GCC, it comes with multiple tools - so we frequently debug on-target using GDB, examine what happens in the generated code using objdump, obtain executable- and section-level information via readelf, etc.
Static Analyzers
- Clang Static Analyzer
- Facebook's Infer engine
- Carneggie Melon's CBMC
- Polyspace Bug Finder
- Polyspace Code Prover
Debuggers and monitors
GDB, GRMON, DMON