PanelSoft

User Interfaces and Usability for Embedded Systems

Feedback to "What Have The Romans Ever Done for Us?"- Murphy's Law, September 2001

Read the original artilce at What have the Romans Ever Done for Us?

return to Murphy's Law

I think that your article on OO and reliability is at best misleading; your examples on code re-use affecting reliability actually make the case for the benefits of OO. Had the Arianne 5 system used OO programming the code for the Arianne 4 would not have been executed. One of the biggest benefits of OO analysis, design and programming is encapsulation which in turn hides complexity. A simpler system is easier to change (and systems always have to change) and this improves long-term reliability. Also, your example of a system which is easier to test because all variables are global sounds like a disaster waiting to happen. The potential for catastrophe caused by a rogue piece of code is huge. At least in languages that allow data encapsulation the programmer would have to go out of his way to trash everything. I think your view of OO is kewed by the drawbacks of C++ which just happens to be the most (overly) complex OO languages around. Java and Smalltalk give a much better OO experience, although I understand that their use in embedded systems where performance is always an issue is probably not nearly as widespread as C++. It's not OO that makes things complex, just C++.

Charlie Robertson

Niall's response:

Charlie,

While I completely agree with you that Java resolves many of the problems with C++, I would be less convinced in the case of Smalltalk. In Smalltalk the message passing style allows for too many run-time problems that should have been detected statically.

Having reexamined my article, it is true that the points about templates and multiple inheritance do not apply to Java (though they do apply to other OO languages). However templates are likely to appear in Java soon - it seems to me that language designers just do not know when to call a halt.

I would also concede that the point about Exceptions making memory management a nightmare does not apply to Java - but the rest of the piece applies to all OO languages. I used C++ as an example because it is the most widely used.

As for the Ariane, I would not accept the assertion that an OO style would have avoided the problem. It is far too fanciful to assume that if the troublesome code would have been inside of an object that would have been tidily removed from the Ariane code. The fundamental problem was that the designers were not considering, and could not have considered, the needs of Ariane 5, and this problem plays itself out in many projects. Ariane did use Ada, a language touted for its safety features, and also used formal methods for code verification, but still ultimately got caught out by reuse. The reuse may have been an inescapable business decision, but it was still a major contributing factor to the loss of the rocket.

Niall Murphy

To: Niall Murphy

Since you said many things I like to hear, you must know your stuff. The more direct reason for the Ariane 5 crash was a conversion from floating point (FP) to integer that overlowed and raised exception, which shut down the computer and cut in a backup that did exactly the same thing. Ariane program used Ada. Both FP and exception are restricted items in Ada-95 Annex H for Safety and Security. A processor I designed over 25 years ago for digital autopilot used saturation, i.e., max/min integer wheh overflow instead of let a positive number roll over to a negative one. There is nobody in the missile to take care of overflow exception.

The unwarranted complexities of C++ can also be said of Ada, which I tried to apply to a missile in early 80s. I was also teaching some Ada class and touted Ada Tasking as an advance but were chargrined to find out that definitely Tasking was undesirable and unnecessary for this active radar missile. I use the Annex H restricted Ada to describe the design of a core processor based in the earlier autopilot processor chip architecture. With Ada package, I can define and encapsulate various logic cells from single transistors to and/or type basic functions to adder/counter type more complicated cells to the entire processor. They are most certainly objects. Two good friends jumped on me when I called the subset object oriented because I got rid of the inheritance part that were added in Ada-95 along with FP, exception, tasking, etc, etc. One said may be it is OK to call it object based. Computer science has changed the dictionary meaning of object.

The reuse of building block logic cells is an established market for hardware design. For example, you have to pay a hefty price for PCI interface from FPGA vendors. Any hardware type that will reuse a cell design without thoroughly examine its inards or test its logic correctness deserved to be summarily executed.

The use of Ada package to encapsulate a building block cell has advantages over the use of IEEE HDLs of Verilog/VHDL that stops at RTL. The package body can initially be described with Boolean expressions and tested by writing a program for the purpose. After shown to be correct, the body can be replaced by a number of interconnected building block cells. The same test program need only be relinked and retested. Any difference in result puts the error on the improper use of building block cells. The cells were previously tested by themselves. This is different from current EDA practice that depends on "synthesis" tools that generates the connected cells from RTL. It is certainly cheaper to use an Ada compiler than buying EDA tools that costs in the six figures.

You mentioned the first fly-by-wire autopilot. Besides a whole bunch of coordinate transformations of the rate gyros, there is also the need to filter the inertial measurement information for mechanical noise during flight. That brings back the subject of integer number representation which generally considered to be 2's complement. Most HOL allow the extra negative number (integer'min). A-B may or may not overflow if A is negative and B=integer'min, depending on the order of evaluation.

You are so right with "objects can do a lot for use, but be careful not to buy into any more language complexity than you need" because I have been practicing this for nearly 8 years. Alas, I cannot convince SIGAda to form a working group to draft a proposal for ISO for a safety subset of Ada that can also be used to design hardware. CS types are still living in the mainframe & dumb terminal era. C++ class is similar to Ada package but C++ suffers from poor readability inherited from the heavy use of symbols from C.

Finally, you mentioned lines of code, a commonly used term. What do you call a single curly bracket in C code, a line? or the entire statement?

Too bad I cannot interest Michael Barr. He considered hardware design is out of scope with ESP. He may not realize that today's hardware design is really also generating software using HDL.

SY Wong, Tarzana CA

Niall's reply:

I agree with you the lines betwen hardware and software are blurring and soon many hardware designers will require skills that are currently in the software domain (like managing a modular, maintainable design made up of tens of thousands of lines of logic, rather than a diagram).

As far as lines of code goes, it does not matter whether curly braces are included or not as long as you are consistent. Metrics like LOC mean nothing as absolute numbers but are only meaningful for comparison, So if one projet has twice as many LOC as another, then that is a useful measure - as long as both were measures the same way. The way I measure it myself is to count semi-colons - fairly easy to do with the grep command, and if ignores comments, blank lines etc.

Niall Murphy

Dear Niall,

Every once in a while, it helps to go back and review the assumptions that lead to our shared conclusions. You did a fine job of reminding your readers why object oriented programming is a good choice. Its benefit, however, is not necessarily universal.

For the past couple of decades, I have been involved in programming microcontrollers for computer peripherals. Most of my work employs 8-bit micros. I have found assembly language to be my tool of choice until recently. It seems the producers of C compilers for 8-bitters have finally improved their languages to the point of acceptability. OOP language support is not there yet, and my colleagues and I won't waste time awaiting it.

A few comments about your article.

About the Ariane 5 rocket failure, you wrote, "the root cause was the failure of an assertion..." It makes me wonder why an assertion was still active in the code.

You wrote, "...reuse...is often not re-tested when it is reused in an environment with different requirements." First, it's tough to imagine that any two environments are going to have requirements that are NOT different. Second, the cost of retesting begins to compare very favorably with developing anew. Barry Boehm's research group at USC rates modifying just 5% of a code module as costing 55% of the effort of a total rewrite. The big factor is understanding how it works. Once you look under the hood, you have to account for how the whole engine works. This, I think, is the big demotivator for retesting. People, particularly project managers, feel comfortable living with the lie that code "working" is a yes/no fact. Actually, there is a continuum of "working" that runs from poorly to perfectly.

"Encapsulating code and data means hiding it from the rest of the program." You really don't need OOP to encapsulate. It's just that the language provides constructs that facilitate encapsulation.

You did a fine job of marshalling some anecdotal rebuttals for some anecdotal advantages attributed to OOP. You might find it amusing to browse the article "An Empirical Investigation of an Object-Oriented Software System" in IEEE Transactions on Software Engineering, August, 2000, volume 26, number 8, pp. 786-796. This is the first attempt I have seen to quantify OOP performance. Unfortunately, the attempt went bust. It turned out that modules that employed inheritance or polymorphism were about 3 times as defect-prone as those that didn't. The reason, in my opinion, is that this was the first OO project undertaken by the programming staff under study. Though they were all accomplished C programmers, their expertise did not carry through to new features of C++.

I can tell you that as a competent embedded C programmer, I find the learning curve for C++ very steep. It seems that texts for structured analysis and structured design with procedural languages are very heavy on analysis and very light on design, particularly implementation. Texts on OOP, though, are just the opposite -- classes seem to just pop out of thin air without rationale. There is almost no concentration on partitioning a problem into classes. Well, that's my gripe anyway.

Thanks again for stirring the pot.
Best regards.

Jeff Sharp principal engineer, electronics Elo TouchSystems, Inc.

Niall's reply:

Jeffrey,

Thanks for your interesting response. You are right about small changes requiring far more test than they generally receive.

On your point on assertions, you suggest that the assertions should not have been in the Ariane code. It is worth noting that while in many projects it is standard practice to take asserts out for the shipped version of the code, many safety critical applications leave them in, and have a well defined recovery path for when an assertion fails (often to reset the system and start over). In the case of the Ariane, that recovery path was 1) too complex and 2) not well tested (because they did not have enough (real or generated) failiures to exercise that code path well).

I discuss assertions in greater detail in one of my earlier articles - see the list at http://www.panelsoft.com/murphyslaw. I will also be publishing your mail at that site.

regards,
Niall Murphy

Ron Stickley writes:

Just wanted to say I read your article in ESP and found it that most unusual of technical articles...it held my interest. Of course, it helps that I too am a Monty Python fanatic and am a convert to Object Oriented Design. Anyway, it's nice to know that there are others who appreciate fine humor (forgive the Yankee spelling...).

I don't consider myself an object oriented programmer, because I don't know C++ very well. My experience has been using Shlaer-Mellor methodology, Project Technology Bridgepoint design tools, with the code being automatically generated by the MC2012 Model Compiler. So, I know how to create objects, relate them, etc. but I don't actually implement them directly in C++. I have developed some programs using C with structures and switch/case statement state machines, but not on anything mission critical. However, the tools we use and object oriented design have, for us, proven to be the most reliable and bug free software this company has yet written (in my humble opinion).

I think the points you bring up are important and I never considered them before. Especially in the fields of transportation, medical, and military systems you can't be too careful. I wonder if it's not so much the programming language but the programmers? I've known people who were brilliant minds who could write rings around me in C or assembly as far as getting something out the door fast and seemingly working, but the code was unmaintainable and, what I call "brittle", in that if there was any change in the order or even timing of i/o contacts, bits, the programs would fail, lock up, crash.

Anyway, I'm not disagreeing with what you wrote, just some thoughts.

It's been a difficult road growing up here in the U.S. (especially rural America) where humor is concerned. Many times the room has fallen silent with blank stares after I've said something "pythonlike" or plagerized from MP. Monty Python was and is the best comedy I've ever seen, and most people I grew up with couldn't fathom it. It's also educational, in that it is steeped in historical and social content. I am still mining nuggets of info from the original series and movies and (thanks to my friends overseas in the mother country) slowly learning rich terms like "knackered" or what "right out on my uppers" implies. Just two years ago I was exposed to the BlackAdder series by a friend and it is hilariously funny as well. I wish I could think of insults like that.

Take care,

Ron Stickley
Marquip LLC Phillips,
WI USA