I suspect that the use of () instead of [] has more to do with 7-bit character sets for European languages. See
-- mac the naïf
As an aside, I disagree with this for two reasons. First, I expect that sensor failure, as indicated by "impossible values," would have been checked for in C code as well as in Ada code. _Something_ had to be done if the Horizontal Bias value went berzerk during a launch. Given the stated bias of the project (untrapped errors were assumed to indicate hardware failure), the code would have been designed to do exactly what the Ada code did, through an explicit range check and switch-to-backup-unit action.
Second, it appears that the "Operand Error" that started the ball rolling (or the rocket dropping) was actually a hardware FPU exception. The Ariane hardware has been reported as Motorola
68020/68881, and Operand Error is the name of the FPU exception that would result from an out-of-range FP to INT conversion. Even if the code were written in C, the exception would have been generated, and presumably the exception handler would have performed the same deliberate and intended actions of shutting down the device so the backup device could take over.Mike
In article , Mike Silva writes
Maybe. Well you would like to thing so.
But I did say in this specific case of putting a large number into a smaller sized int.
No complaint about that. My understanding was that the "error" occurred after the figures from the SW unit were being used as it was past the point in the flight where they were needed.
Ok... thats HW so it makes no difference on the language used.
presumably... It's like the "should" word that keeps cropping up just before things go wrong :-)
But as the back up had the same problem.... the rest is history.
Interesting analysis.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org
Or, as it's know in comp.lang.ada, "not that damned rocket _again_!" :)
I think that makes the points I have been promulgating so often, on this and other groups, very nicely Chris. Thanks.
The only other point is that whatever your process, it should generate the necessary evidence for your audit trail to be able to back-track to where problems were introduced. I know that Def-Std 00-56 was recently being reviewed to see if the evidential position could be improved.
-- ******************************************************************** Paul E. Bennett .................... Forth based HIDECS Consultancy ..... Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE...... Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details. Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
You do, of course, write all your specifications down, have them reviewed and corrected if necessary. For you to be proud to be 44% of the final manifestation of the problem will make me re-consider whether or not I fly again. Of course errors are made in specification. We are, after all, only human. However, I think you will find that the
44% is the number of errors that make it all the way from specification into the final code/equipment. It is really a pointer to innadequate reviw at the specification stage.Except that drug abuse in a "Safety Critical Systems" environment is actually a criminal offence in many countries.
Programming language has never been the issue. A task may be easier in some languages than others but more important than the language is the personnel, the work ethics of those people and the process you employ to keep the project develoment under control. Programming language is certainly less than 1% of the consideration.
[%X]Does that mean you consider programmers and software engineers to be NOT on the engineering team? [%X]
IIRC the report virtually stated that that particular error would not have manifested itself in C. I know that at the time someone posted a lengthy summary from the report. [%X]
As one who does not wander into using Algol-like languages very much I will leave that to others to answer. With the oddball languages I use (D3, S80, Forth and Assemblers) choice of language does not change my software design by very much at all.
-- ******************************************************************** Paul E. Bennett .................... Forth based HIDECS Consultancy ..... Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE...... Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details. Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
The choice of the implementation language should have no bearing on the software design, unless one is using a language specific feature as a design feature.
The choice of language may affect the software development process in so much as coding guidelines and associated work instructions. For instance, the choice of C over Ada may mean that a more rigorous code syntax checking be performed and/or more comprehensive structural unit testing be carried out. The integration and system testing of a system built with either language should pretty much be the same.
Ken.
+====================================+ I hate junk email. Please direct any genuine email to: kenlee at hotpop.com
Don't get me wrong -- you'd think what you stated would be true, but there is no "standard" for professionalism. The fact that one has a piece of paper stating that they are a bona fide engineer doesn't mean that they're any good. However by "natural selection", those engineers that are gainfully still employed and are regarded by their peers as professional, do use acceptable processes (personal or otherwise).
Although I'm not an advocate of quality manuals of biblical proportions, I do believe that the QM is dependant on the type of product one is developing. If one's company is subjected to external regulatory audits, then the scope of the QM should be so appropriate (as a minimum) to the auditor's expectations. Theoretically the QM should be scoped to be appropriate to the level of criticality of the system.
Ken.
+====================================+ I hate junk email. Please direct any genuine email to: kenlee at hotpop.com
IMO the appropriate C phrasing is:
while ( (EXIT_KEY != (key = get_key())) ) { process(key); }
and we should assume that get_key returns EXIT_KEY for EOF.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
USE worldnet address!
In comp.arch.embedded Dave Hansen wrote: : On Wed, 31 Dec 2003 14:27:08 +0000 (UTC), Georg Bauhaus : wrote: : :>In comp.lang.ada Dave Hansen wrote: : : Note: I'm reading from comp.arch.embedded. Just so you know where I'm : coming from...
Sorry. I need to adjust my reader software.
: Is the "'access" tag (or whatever you call it)
It's an attribute, like 'address, 'size, 'range, etc.
: Is the "'access" tag (or whatever you call it) _required_ on the call : if a function is going to modify the parameter? I like it even better : if that's true.
Yes, as Stephen has explained. Let me add that if you want a variable to be modifiably through some pointer you will have to say so. You declare the variable aliased (using the "aliased" keyword in the declaration), and point to it using 'access values.
There is also an 'unchecked_access attribute which allows pointers to aliased local objects to be passed around. The intention is to remind the programmer/maintainer of the pointer validity check that cannot in general be done by the compiler as in the following example:
type Reg16_Ptr is access all Interfaces.Unsigned_16; -- pointer to a 16 bit register
function trig_reg return Reg16_Ptr is v: aliased Interfaces.Unsigned_16; -- 16 bits from the toaster's eject trigger, v is local to function pragma Import(Ada, v); -- do not initialise v for v'address use System.Storage_Elements.To_Address(16#A022#); -- hardware address begin return v'unchecked_access; -- points to local v which is really a register, not a value on the -- stack end trig_reg;
-- Georg
the
I must remember to tell my radar building biddies, who have (various types of) antenna arrays... ;-)
"safety critical C" is an oxymoron if I ever heard one.
Ariane 5! Ariane 5! Nyah nyah! Nyah nyah!
In every group that I participated in that ever discussed issues of code reuse from a systems perspective, the fact that an M1A1 tank was not an M1 tank was discussed. (Substitute F-15 and F-15E for Air Force sponsored groups and so on.) The result, of course is that you may be able to reuse much of the code, but you CANNOT reuse the requirements analysis. And if the requirements change, then the testing has to change. So even if you can reuse 100% of the code, that only saves 15% of the overall software costs. Library reuse works on the other hand, but you have to invest in building the library independent of an particular development project. If a reuse library contains software that matches your requirements, then you have a component that solves part of your problem and does not require a new test plan, test suite, and testing. (You still need to perform system test however.)
Arianne 501 crashed because the bean counters tried to do software reuse without repeating the requirements analysis, and later cut out all system testing. Oops! Incidently the subsequent Arianne 5 failures followed almost identical fault trees, but they did not involve Ada code.
--
Robert I. Eachus
"The war on terror is a different kind of war, waged capture by capture,
cell by cell, and victory by victory. Our security is assured by our
perseverance and by our sure belief in the success of liberty." --
George W. Bush
Yes, I know. But I'm also pretty sure that there's lots of safety-critical code that's written in C. If someone is going to mouth off with ignorant comments about C, I want to make sure that I mouth off with ignorant comments about Ada.
Neither of which is very helpful. You might do well to recognize that Ada has been designed to detect Stupid Human Tricks as far as practicable, while C is designed to allow SHTs anywhere that they are not demonstrably and immediately fatal. At the same time I expect Scott Moore has more experience with strongly typed and relatively safe languages than you do. I may be wrong.
Given a choice of two airline pilots, would you choose the one whose sole experience has been stunt-flying and racing, or the one who has been captaining an airliner without incident for a similar length of time? Would you alter your choice if
a) You want to get there in one piece or b) You have to get there yesterday to prevent disaster or c) Only one is available.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
USE worldnet address!
CBFalconer wrote: > Ada has been designed...
That does not make safety-critical C an "oxymoron".
Yes, of course. There's plenty of hyperbole on usenet -- folks say "X is impossible and Y is perfect" when the truth is, "Y is better than X for certain purposes".
It's interesting that there are actually *very* few disasters caused by the malfunction of safety-critical software (in *any* language). At least, compared to the number of malfunctions in software I use every day on my desk. Language is important, but it is far from the *only* issue in ensuring safety. And airplanes are not dropping out of the sky all the time.
;-)
This vaguely reminds me of the usenet game of "trolling", where one tries to trick one's opponents into thinking oneself is a blithering idiot. I don't get it -- how can anybody get satisfaction out of that?
At least you said "nyah nyah" to let us know you were being sarcastic.
Sorry, this is getting off topic. I'll shut up now.
- Bob
From another point of view, they just opened the system testing process up to the public view :-)
Sorry, no. If the course of Ariane 501 would have been slightly different, the launch would have succeeded. But it would have said nothing about the likelihood that then next Airiane 5 launch would have succeeded. In fact there have been three major failures in less than a dozen launches, with lots of originally needed testing done after each failure, and they still don't have a working system. In the meantime, Ariane 4 (Remember, the one the software requirements were originally for?) has had about 100 launches with a very good record.
So the Ariane 5 is almost the poster child for doing reuse without redoing the systems requirements analysis from the top. I would hope that no one would ever make that mistake again. But the lesson that keeps being taught about the first Ariane 5 launch is about software validation.
Similarly the lessons learned in five Airbus 320 crashes are getting papered over. It is by now clear to those who study such accidents, that all five accidents were probably caused by invalid requirements. For years Airbus has claimed that the software had been proven correct and couldn't have caused the crashes. But finally enough has come out that the accident investigators are pretty sure they know exactly which requirements error caused which crash.
The Airbus 320 should bury the idea that theorem provers can result in safe software. In the case of the Airbus 320 what happened was that the formal logic used for stating the requirements/theorems was relatively opaque to experts in the field (read pilots). So the flaws in the requirements, and later about 500 people, were buried by that opacity.
--
Robert I. Eachus
"The war on terror is a different kind of war, waged capture by capture,
cell by cell, and victory by victory. Our security is assured by our
perseverance and by our sure belief in the success of liberty." --
George W. Bush
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.