Management-level Frequently Asked Questions (F.A.Q.)

• How mature is the technology?
  • A complete regression checking suite is run on each update of the tools, verifying extensively the behaviour of the generated code.
  • At least 5 complete and realistic case studies with complex functional blocks mixing C, Ada, Simulink and SDL languages have been developed by independent industrialists using the toolchain.
  • Extensive documentation is still under elaboration, but using the appropriate support scheme, there is no major lack in that respect.
  • Maturity resides also in the fact that tools have been designed to generate code that is compliant with space standards - meaning reduced footprint, high performance and very important, maintainability.
  • Obviously, no tools can claim to be bug-free. However, maturity is not only about bugs, it's also about how quickly they can be identified and fixed. In that respect, engineers that worked with the tools (from space companies) acknowledge that the speed and accuracy of our support is amongst the best they have ever seen.

• How perennial is the technology (longevity):

  All of our tools are open source. More importantly, our tools generate code which is exactly like the code that a human coder would write (which is not typical behavior for code generators). This means that you could still maintain and evolve the *generated* code.

• Is it easy to incorporate this technology in space SW development?

  Yes. Actually, in the chain of software space development, only one link must be adapted: the system engineer link. Currently, the system engineer collects requirements and writes detailed specifications in word/excel formats. With our technology, he will be able to provide to the development teams skeleton projects, with concrete (code) interfaces. Moreover, the system engineer can get feedback and identify inconsistencies in the specifications much faster, since the interfaces are defined formally.

• What is the cost of support?

  It depends on the project and the client. If the project is an R&D, and the client is simply investigating the potential of the technology, then the license fee will be cheap. On the other hand, if it is a real mission, with strong requirements on support and response speed, and/or the number of engineers we are supporting are not just a couple, then the license fee is higher. The upper limit of the cost is reached if you require engineers from Semantix to be dedicated for the support of your specific project, in which case the license fees would correspond to the monthly cost of the dedicated engineers.

• What is the cost of the license?

  The cost of the Commercial Developer License is, in essence, zero. What costs is our support - which you are obligated to obtain in order to use the tools in a commercial/proprietary setting - and the cost of the support depends on the project (see previous question).

• Do your tools eliminate the need for testing?

  No tool can provide you with guarantees that would eliminate testing. However, with our tools, the testing effort is significantly reduced. For two reasons: First, unit testing with our tools can be automated to a large degree. Second, those unit tests which cannot be automatically produced by our tools but are required in order to achieve 100% code coverage (statement/branch/condition coverage), can be written with much easier to use technologies (like Python) instead of the traditional technologies (i.e. writing C/Ada code).

• Why do your tools save me money?

  To answer this question, we need a technical presentation of at least 30 minutes :-) But the executive summary is that we automatically generate large parts of the code that is currently written manually. This means that you lessen the required manpower to build and test the system, and in the same time, you increase a lot the reliability of your system. This is because the generated code has no bugs or errors. Why? Because the code generators have been thoroughly tested in a variety of settings (and projects), and even if they have a bug, it is much more likely (compared to manually written code) for the bug to manifest and be identified very quickly, since the same bug will appear in many places of the generated code. Correspondingly, it will be easy to fix - fixing the code generator will fix the bug in *all* places where it appears in the generated code.

  Moreover you have other gains, like: automated graphical user interfaces for TM/TCs, automated testing, automated ICDs, very early feedback on requirements discrepancies (because the interface specifications are formal, etc.)

License information for the tools is here.