Re: Is an RTOS Required for Ada?

["George Romanski" <romanski@aonix.com>]

Robert Dewar wrote in message <7i1b7p$3nb$1@nnrp1.deja.com>...
>In article <wccogjh80os.fsf@world.std.com>,
>  Robert A Duff <bobduff@world.std.com> wrote:
>> Robert Dewar <dewar@gnat.com> writes:
>>
>> That makes no sense to me.  Why couldn't you just certify
>> those run-time routines that you use?  Isn't it easier to
>> certify the bcopy routine, than to certify many inlined copies
>> of the same algorithm?
>
>Well, certification issues often make no sense to technical
>people not aware of the special requirements :-)
>
>First of all, you cannot in general certify existing code,
>because part of (at least some of the protocols) for
>certification is to document (in exhausting and exhaustive)
>detail, the procedures and protocols used to develop and
>manage the code during the production process.


Yes! most Safety Certification Standards require the process
used to develop and verify the safety critical software to be
recorded.  This forms an auditable trail which is checked by
the certification authorities or their representatives.

It is possible to 're-engineer' the process independently by
performing all of the required steps that were missed.
In general it is extremely hard for anyone to re-engineer
the requirements, design, hazard analysis and so on, for software
developed elsewhere. (e.g. by your compiler vendor)
>
>Certification is a very heavy and expensive process (I heard
>one company quote an average productivity of one machine
>instruction per day per person in this context).
>
>You can get some idea of the expense of certifying a run-time
>by looking at some of the products on the market today. They
>are not inexpensive!

Agreed!  at least 5 lines of test for every line of code.
I've seen 10 lines of test as well.
>
>To reimplement under certification conditions, and to
>actually certify even a small part of the run-time library
>would be an expensive process that would have to be passed
>on to the user. In the case of bcopy, as Tarjei points out,
>the code is inline in most cases anyway. The added
>certification of inlining the few cases that do not get
>inlined in the normal case is negligible compared to the
>cost of generating a special certified library.


Inlined code forms part of the operational software, it must
also be certified with the application.  The degree of rigor
depends on the standard and the criticality level.

At level A for DO-178B (the avionics standard) you have
several choices.

1) Implement your application using two or more different
    computers, different languages and different compilers.

    This allows you to show test coverage at the source code
    level.  An expensive process as the system must be
    developed independently, twice.

2) Show code coverage at the source code level, and
    show traceability between source and object code.

    This means analyzing your generated code to verify the paths
    introduced by the compiler. (a very time consuming and
    tedious process).  Perform coverage at the source code level.

3) Show code coverage at the machine code level.

Code coverage means showing decision, condition and the
"effectiveness" of conditions (MC/DC) - depending on
criticality levels.

If the compiler inserts code for you, then this inserted code
must also be verified at level A.   (you will need requirements
design, source code tests and all appropriate reviews)

At level B coverage need only be shown at the source code
level.   DO-178B is not explicit on this point and you could
use the compiler to hide library code so that you don't have
to produce certification materials for it.

The general feeling in the certification community is that this
would be cheating, and if the certification authorities found
out about this practice then the responsible "DER" (Designated
Engineering Representative) would have his signature
authority revoked.

This ambiguity in interpretation is being fixed.  Guidance
material is being produced to prevent  this source code level
trick to be used to hide any code.   If the compiler inserts
any code with decisions then evidence must be supplied
which shows all decisions being tested with both outcomes
and showing that the requirements for the inserted code are
satisfied.

When complete, the guidance materials will be published by
RTCA and EUROCAE and will be used as a supplement
to DO-178B.

>
>Another issue is that there are several different protocols
>for safety-critical certification. It is not possible to
>provide a pre-certified run-time that adheres 100% too all
>possible protocols, so one has to choose a commonly used
>one. We find that many customers far prefer a model in which
>they have custody over 100% of the code in the application,
>and can make sure that all of the code meets their particular
>certification requirements.

100% custody of the code is a requirement for certification but
so is the requirement for all of the additional materials needed.

>
>This is certainly a very specialized field, and we expect
>the GNORT capability to be relevant only in those situations
>where the 100% code certification issue is critical.
>
>Robert Dewar
>Ada Core Technologies
>
>
>--== Sent via Deja.com http://www.deja.com/ ==--
>---Share what you know. Learn what you don't.---

IT IS a specialized field, it requires a lot of discipline and effort
but must be taken very seriously - lives are at risk.

We have found that if certification evidence is produced under
DO-178B Level A,  then  a mapping document which traces
requirements of other standards into this evidence is acceptable.
e.g. Def-Stan 00-55, RIA-23, IEC-880 etc.

George Romanski
Director Safety critical Software
Aonix