DO-178 was published at the end of 1981 to overcome verification of aircraft in the face of "the complexity of software". It is a very logical and rational approach to the development and verification of software. DO-178 can be represented as a V curve, where the left side are the development steps, and the right side are the corresponding verification steps. DO-178 strongly insists on a requirements-based approached (and rightly so). In DO-178, it doesn't matter if the code works or doesn't crash, a piece of software is correct if and only if it corresponds precisely to its requirements.

Since 1981, the complexity of software has risen exponentially, and unfortunately, so has the amount of work needed to comply with DO-178. By 2015, software has delayed all major aircraft launches, and cost for avionics software development and verification have risen to billions of dollars per year.

Over time, and especially in the early nineties, people have tried to come up with tools to reduce the effort. For instance, the academic research on Lustre was converted into a commercial product SCADE, then introduced by Esterel and now owned by ANSYS. The idea was to dramatically reduce the coding effort by automatically generating code from the low-level requirements. Unfortunately, this approach has drawbacks.

The first drawback is that because the low-level requirements as defined in SCADE are relatively close to actual code. The amount of details is such that the gains with SCADE are reduced more than one would expect. 

A second drawback is that this approach does very little to reduce the verification, which is the main work in complying with DO-178. The code generator is qualified, so that the generated code did not have to be reviewed. However, the generated code does need to be compiled. In DO-178C, all testing must be done against requirements and for level A, testing must be done against the compiled result. This leaves you still with the enormous task of writing verification cases for each low-level requirement, and even for each part of code that the compiler injected.

A third drawback is that the models are clearly separated from the rest of the documentation. This means that the model must be documented, and they must be carefully traced to the other documents. This too takes quite a bit of work, which may be redundant if the documentation was already present in the other documents.

Sol has learned from these experiences, and solves this in a number of ways:

  1. Requirements are specified at a high-level. When you specify requirements, you can go to the lowest detail, but you don't need to for the common case;
  2. Sol is not a model that is separate from your other documentation. Sol is embedded right in the text-based SRD, and the explanation of the requirement is plain text. In fact, that is the main text. While visual programming seemed like a good idea in the nineties, it has been largely abandoned since. (UN)MANNED focusses on making the text clear, fast and easy to write and understand. And we focus on making sure that text is an integral part of the documentation. If you press print (or save as PDF), you get what you see, and you are done with the SRD.
  3. In visual programming systems, it is unclear what exactly is a low-level requirement, because typically a group of drawings together form one testable requirement. It is always hard and subject to discussion with authorities where that line is drawn. This is not the case with Sol. Sol was designed from the start to make sure that it is clear what is a requirement. Sol also has the ability to group low-level requirements into a high-level requirement right in the language, where it is abundantly clear how things come together and how they are tested. 
  4. Sol does not generate code, but generates the executing file directly without third party software involved. So you don't have to worry about which compiler to use, which compiler settings to use, how to do unit testing, etcereras. Sol has already solved all that for you, so you can focus on a much higher level of requirements.