From: David Crocker (dcrocker(at)eschertech.com)
Date: Tue 31 Dec 2002 - 13:38:38 GMT
Nancy, I appreciate that the safety-critical software development industry has every reason to be conservative. However, as someone who made the transition from procedural software development to object-oriented software development some years ago, and has a background in formal methods (but no actual experience in safety-critical software development), I would like to share some thoughts on the application of O-O technology to safety-critical applications. 1. O-O can be taken too far. I am not of the school that says everything is an object and every design has to consist of interconnected objects. I saw a paper recently criticising the standard implementation of "Hello world" in Java on the basis that it was not an O-O design, proposing a much more complicated version that the author claimed was O-O. I think the real point here is that "Hello world" is not an O-O problem. Similarly, I suspect that many real-time control applications would not benefit from O-O methods because there are no real objects in the system (or only a single instance of each class). 2. On the other hand, in designing many types of complex systems, the use of inheritance and dynamic binding gives a *huge* advantage in clarity and productivity. Where a designer would otherwise have to use variant or united types, the use of inheritance is *much* cleaner and clearer. Think of inheritance and dynamic binding as the ultimate version of discriminated unions. I would hate to build a large software system without having inheritance and dynamic binding available. 3. Software developers working in Ada are already part of the way there, because Ada provides one of the cornerstones of O-O methods, i.e. encapsulation. The rest of the world had to wait for O-O languages to get encapsulation because they ignored the main languages that supported it (i.e. Ada and Modula-2). 4. The trend these days is to use COTS wherever possible, especially at SIL1 & 2. COTS is increasingly likely to be O-O in design, so safety-critical engineers will have to get used to building safety cases for O-O software anyway. 5. Safety-critical developers I have spoken to seem to be terrified of dynamic memory allocation (one even claimed it was nondeterministic!). There are certainly issues to be addressed (especially in systems where failure to allocate the required memory is not an option); however, there are also solutions. Just because safety-critical engineers have been able to get away with avoiding dynamic memory allocation in the past does not mean that it cannot be analysed and used safely. 6. Similarly, dynamic binding does not fit neatly into static control flow analysis. This does not mean that dynamic binding is unsafe, it means that techniques of control flow analysis need to be extended. In reality, dynamic binding is equivalent to (but simpler and less error-prone than) using a 'switch' statement to select a routine to call. 7. Ada 95 tries to be O-O but does it in such a horrible way that I wouldn't advise anyone to write an O-O system in Ada 95 (although I am aware of engineers who claim to do so). Also the 'with-ing' problem gets in the way of OO design. 8. O-O systems do tend to be less efficient in processor and memory use than non-OO systems, so may not be advisable when working to a tight CPU/memory budget. In these days of low hardware costs, I would hope that the hardware cost was not a primary consideration in safety-critical systems (in any case, the cost of developing the software will probably greatly exceed the total cost of all the hardware deployed except perhaps in the motor industry). 9. There is a move towards the use of OO technology in critical systems in the USA. The Aerospace Vehicle Systems Institute has produced a "Guide to the Certification of Systems with Embedded Object-Oriented Software" (see http://avsi-tees.tamu.edu/about.html), which led to the NASA/FAA workshop referred to by another poster. New software for the JSF is, I believe, being developed in C++ rather than Ada. So our American cousins will make the move to O-O design even if we don't. 10. One of the big advantages claimed for O-O technology is that components and classes can be readily reused, saving development time. Although the advantage is often overstated, I believe there is a significant advantage here, with the caveat that the components must be precisely specified and verified if re-use is to be safe (we produce an O-O formal methods tool for doing this!). I think a move to O-O technology is inevitable at least for the larger s/c systems. It's time engineers in Europe started addressing the issues, otherwise Europe will fall behind the USA yet again. Regards David Crocker Escher Technologies Ltd. www.eschertech.com +44(0)1252 336565 -----Original Message----- From: safety-critical-request(at)cs.york.ac.uk [mailto:safety-critical-request(at)cs.york.ac.uk]On Behalf Of Nancy Leveson Sent: 30 December 2002 21:56 To: safety-critical(at)cs.york.ac.uk Cc: Joe Bergmann; Ben Calloni; Dave Emery; Robert Allen; Dave Haverk; Dock Allen Subject: Re: [sc] Selection Criteria for RTOS Dock's message raises a lot of important questions: <stuff omitted about Java, OO, UML, etc.> >It seems that there is a lot of activity in this area right now, which is >good because we were certainly falling way behind the state of the >practice in software.... As we bring the practice of safety critical >systems up to date, I think we should also be looking outside of the >narrow scope of avionics and medical systems for more scalable approaches. For example: Are the design and specification practices used in non-critical systems the same ones that should be used in critical systems? Are the same languages, specification techniques, and architectures and software design techniques the best for all types of applications? Because some practices are used for commercial software in non-critical systems and non-control systems, does that mean they should be used for avionics and medical systems? Should the same software practices be used for hard real-time as for non-hard real-time systems? Is there one programming language, specification method, software architecture, and software design methodology that is demonstrably better than all others for all uses? If so, then how has this been demonstrated beyond current popularity (which follows fad cycles)? Is there hard experimental evidence? If the "state of the practice" techniques make it harder to assure safety (e.g., perform safety analyses, be reviewed by system and safety engineers, be verified as safe), then should they be used anyway because everyone else is using them? or because they have other advantages? Do those advantages (assuming they exist) outweigh the different requirements and goals for safety-critical systems? Think about the fate of lemmings ... Nancy