Safety of Life - made easy
Safety of Life - made easy
Sol is a software suite. At its core, Sol is a format to write down requirements. It automatically generates both the executable, as well as the associated certification evidence.
Sol was designed specifically to create avionics software. It complies with the highest certification levels of FAA and EASA.
In avionics, it is of utmost importance to write the right documents. After having done the planning documents, you will need to write the Software Requirements Document (SRD).
Sol was designed with this process in mind. As a result, Sol is a format designed to write technical documents, in human-language. It has headings, content, markup like bold or italics, bullets and lists, hyperlinks, and more features for writing technical documents.
Avionics is also all about configuration management, and change tracking. For this reason, while the Sol development environment shows you the text with full markup, Sol stores the information in a plain text format. As a result, version control systems can easily track the changes in the documents. Authors can use branch and commit histories, and see who made what change to the document when. Because Sol uses a pure-text format, it does not require special databases or servers. Finally, because Sol is an easy to parse text format, you can integrate Sol with your organization's processes using scripting.
Sol also has some features that make it even easier to specifically write avionics documents. For instance, you can add trace markers and Sol can automatically generate the two-way traceability matrix for you.
The largest task of anybody using Sol is to write a human-language document that explains the requirements. Interleaved with the text, the actual requirements are expressed as formulas, in conditional blocks. These requirements are distinguished from the human-language by indenting the requirements. Sol uses only "simple" formulas, as simple as you would write them in Matlab or Excel. There are no exotic symbols in Sol, and the syntax speaks for itself.
Sol ensures that the requirements are always met at runtime.
While you enter the requirements, Sol will analyze the requirements as you type, and give you code completion on names defined in other requirements. Sol will also warn you if it can determine through its analysis that a certain requirement cannot be met at runtime. This brings entering requirements to a whole new level: requirement are verified as you type for internal consistency.
Some of the hard parts of the design of avionics is done automatically for you. For instance, Sol can automatically calculate the worst-case execution time, and it has a complete view of both the dataflow and the control flow of your application. In fact, it uses this information during the statical analysis of your requirements. It provides this information in a generated document, in the format you need for the certification authorities.
The automation of DO-178 goes back decades. However, even the most advanced package never claimed to go beyond 30% of overall effort reduction, and could only automate a small subset of the DO-178 objectives. Sol on the other hand automates 70% of the DO-178C objectives, corresponding to an effort reduction of up to 80%. Sol is the most advanced DO-178C automation tool by far.
Sol is a DO-178C qualified tool with Tool Qualification Level 1 (TQL-1). This means it is qualified to generate DO-178C level A applications. Sol does not use any external software in the generation process, and in particular Sol does not use an external compiler. This is why Sol is capable of automating 70% of all DO-178C objectives, unique in the industry and a truly remarkable result.
Sol qualification is only important when you want to create DO-178C certified software. It is important to remember that software is only certified to a specific DO-178C level if it runs on DO-254 hardware runtime platform. Sol comes with a DO-178C Certification Kit that is specific for your hardware runtime platform. If you run on a platform not yet supported by Sol, (UN)MANNED will have to port Sol to your hardware platform.
All you really have to do, is know what you want (= write requirements) and check if your requirements are written in a way works as you intended (= integration testing).
Sol has built-in support for a whole host of features you will need when specifying the requirements of systems, including:
All of the above features are available at level A.
At DAL C, more features such as TCP/IP and FTP are available.
Sol is hard real-time, and goes through great lengths to ensure absolute timing precision. If you have a discrete blinking a LED, a screen with a blinking indicator and a sound chiming, we make sure that they are timed to precisely align at the requested update rate. In Sol, most requirements are re-evaluated at a specific refresh rate (typically related to the screen update rate), but Sol also has support for requirements that need to go fast, as well as support for requirements that are just background activities.
The features of Sol expand continuously and are entirely driven by the building an ever growing portofolio of cockpit applications.
Support for ARINC 664 Part 7 is optional and requires a specific additional license.
What Can You Build?
What Can You Build?
You can build any avionics application using Sol. All of the applications developed by (UN)MANNED for customers, including PFD/ND, EICAS, synoptic pages, and much more, as 100% written in Sol.
If there is any feature you are missing to build your cockpit, or your UAV control system, let us know. We'll help you resolve the issue, or we'll add the feature.
So, you can build every instrument inside an aircraft or on the ground, both those with displays and computing systems without displays.
also great for
also great for
Sol comes with a built-in screen designer. The designer will write Sol code for you in your file when you create new widgets. If you drag existing items, it will intelligently update your existing code. This works no matter where you have placed the logic in your document, because your requirements should follow the logic that makes sense for your system. Sol never forces you to change the structure of your document.
It is extremely fast to build avionics systems in Sol. You should expect to have a system working on the first day of the project.
This makes it ideal for simulation, because it makes iterating on designs and concepts very fast. It's only when you run a cockpit that you really feel what is wrong with it.
For training purposes, it is good to know that Sol can run the same application on Windows, Mac and iOS, as it runs on the target hardware. This is extremely convenient when the target hardware is slow to (re)boot, or scarcely available. When (UN)MANNED executes a program internally, we typically delivers the training simulator along with the actual embedded software, because it is so simple to do with Sol.
about automating DO-178C
about automating DO-178C
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: