Under this amazingly explicit name is hiding the formal methods supplement for DO-178C. Or, said otherwise, the document that allows you, as a developer of avionics software, to replace tests/reviews/analyses by formal methods. Or you, as a provider of techniques and tools for formal methods, to find customers in the avionics market. Ah yes, because the new version of the certification standard for avionics software, DO-178C, has been also issued at the same time. So that starts today!

Here is what the abstract of this doc says:

This supplement identifies the additions, modifications and substitutions to DO-178C and DO-278A objectives when formal methods are used as part of a software life cycle, and the additional guidance required. It discusses those aspects of airworthiness certification that pertain to the production of software, using formal methods for systems approved using DO-178C.

Formal methods are mathematically-based techniques for the specification, development and verification of software aspects of digital systems. The mathematical basis of formal methods consists of formal logic, discrete mathematics and computer-readable languages. The use of formal methods is motivated by the expectation that, as in other engineering disciplines, performing appropriate mathematical analyses can contribute to establishing the correctness and robustness of a design.

As far as I know, this is the first attempt at defining a common annotation language for tests and static analysis / proof for C. The annotation languages for C that I know of cannot be executed: Microsoft’s widely used Standard Annotation Language, the annotation language used by the Escher C Verifier or the one from Microsoft’s VCC.

Note that an important difference between this annotation language and others is that it uses mathematical semantics for operations in annotations. So an addition in annotations cannot overflow. In practice, they are using the GMP library for mathematical integers. Try it for yourself by downloading/installing Frama-C and this plug-in!

More information can be found at:

http://open.nasa.gov/blog/2012/01/04/the-plan-for-code/

I particularly like the call for participation – “Will your code someday escape our solar system or land on an alien planet? We’re working to make it happen, and with your help, it will.”

First let me recall that one goal of the Hi-Lite project is to bring formal verification to the Ada language. An intermediate verification language (IVL) can help here because it deals with the most common features that exist in most programming languages: integers, arrays, sequential programming, loops, function calls. There was no need for us in Hi-Lite to reinvent the wheel, we simply picked a suitable IVL.

There are two main IVLs in the research community, namely Boogie[1] (hence the name of the workshop) and Why[2]. In the Hi-Lite project, the natural choice was Why, as the Why developers are also part of the project.

Besides talks discussing various improvements in these two main tools, there was also a talk about a new IVL called jStar, mainly targeted at complex programs with shared mutable state, and the very interesting invited talk by Viktor Kuncak[5] showed some ways of using IVLs to develop new programming techniques.

The workshop website[3] contains a list of all the talks. It is also worth mentioning that it is part of the CADE 23 conference[4] which takes part in Wroclaw all week.

[1] http://boogie.codeplex.com/
[2] http://why.lri.fr
[3] http://research.microsoft.com/en-us/um/people/moskal/boogie2011/
[4] http://cade23.ii.uni.wroc.pl/
[5] http://lara.epfl.ch/~kuncak/

The current release of Riposte is at an alpha stage and is intended to be a technology demonstration. Suggestions and feature requests are most welcome. To download the tool, please visit the Riposte project page on the Open-DO Forge.

The full article can be found at:

http://electronicdesign.com/article/embedded/Safety-in-Medical-Device-Software-Questions-and-Answers.aspx

We expect this document to evolve over time, so we kindly ask readers to provide as much feedback as possible to AdaCore at info@open-do.org with the name of the document mentioned on the subject line.