Last week there was a meeting of The Open Group's Real-Time & Embedded
Systems Forum, which works on software standards. A lot of the work is in
the area of safety-critical software, and is focusing on Java as a
language. The interesting thing from the Ada perspective is that many of
the people at the forum seemed (at least from the comments I listened to)
to be unhappy that they were not able to use Ada. Ada is now banned by
some parts of the DoD.
I talked to a couple of people about this, and was told that companies that
wanted to use Ada were getting rejected by potential employees specifically
because of the use of Ada. I asked if that is still occurring, or if it
was a few years ago when there were many fewer available people, but no one
knew the answer. They basically said it was too late.
There were a couple people who actually did not like Ada, but it was more
that they had had bad experiences with specific compilers.
By the way, Ben Brosgol gave a quite good talk on lessons learned using Ada
for safety-critical applications and did point out that Ada is still alive
and being used on new projects. The point I got out of the talk was "The
Ada community has solved the safety-critical problems. Why waste time
fixing the same problems for Java?" I think others might have gotten a
different point. :(
At 12:45 PM 7/29/2003, Colin Paul Gloster wrote:
>At last month's DAta Systems In Aerospace conference
>Christophe MORENO of Alcatel Space announced in his "Plug &
>Play Architecture for On-Board Software
>Components" presentation that he is using Ada 83. 24 minutes
>later during Astrium's Matthias Wiegand's "Next Generation
>Avionics System for Satellite Application" presentation,
>Matthias Wiegand said "Ada is possible". During the
>"Software Agents 2: A Minimal Real-Time CORBA ORB for
>Space" presentation by what Science Systems (Space) had
>become, it was revealed that the company is working on a
>minimal realtime CORBA ORB for which Ada 95 support is being
>CNES's Francois Bossard spoke about a software architectural
>model in his "Event driven architecture for hard real-time
>embedded systems" presentation which has been implemented in
>Ada. An interface for C in middleware was later added.
>A strange part of the conference ...
>GMV had a presentation on its "CPFPS: Development of a
>Safety Critical Hard Real Time Distributed Application for
>EGNOS". The programmers programmed in C. They coded over
>120000 lines. They were worried about memory leaks. They
>found hundreds of memory leaks which had not already been
>detected in testing. For the project, verification was
>automated whenever possible, including memory leak analysis.
>Hundreds of errors were found at unit level. After fixing
>these, about twenty errors were found at system level.
>MISRA C was not used because of its restrictiveness, but
>'99%' of MISRA C was used. The GMV presenter claimed that a
>lot of erroneous C programs can not be detected by Lint.
>He had spent about seven years with Ada, so it may have
>seemed that he would want to have used Ada for EGNOS's
>CPFPS. However, he complained that Ada compilers he had used
>or an Ada compiler he had used is buggy. Also the abstract
>at the conference reveals "A trade off was performed between
>C and Ada, other languages being discarded very early in the
>process, and finally C selected. The DoD dropped the Ada
>mandate for any kind of software in 1998, but reports from
>the AdaIC state that Ada was not the dominant language for
>Weapon Systems already in 1994, [..]".
>Colin Paul Gloster
>P.S. While I am emailing an Ada advocacy list, an excerpt
>from an email from an email list of the Association of C &
>C++ Users of July 27th, 2003:
>"Your argument seems to boil down to the question of what's 'morally' a const
>or non-const method.
>That's fair enough but I think that C++ has always had a problem here in any
>case. Const methods can so easily modify the logical state of composite
>objects that I don't see how you can rely on const to tell you that the
>logical state is left unaffected - at least not at the level that the
>language can enforce."
Draper Laboratory, MS 31
555 Technology Sq.
Cambridge, MA 02139, USA