Asserts for Embedded Systems
in [OOP]
|
From: John Carter on 9 Jan 2008 23:23 I've been brewing a doc on asserts in embedded systems for awhile and finally updated it and slapped it on a wiki somewhen. http://software.wikia.com/wiki/Asserts_for_Embedded_Systems It's delibrately bold and opinionated to move the state of the art forward a bit. It's on a wiki, so don't whinge about it, if you don't agree or don't like or have a quibble with the grammar. Edit it and correct it. Have fun.
From: S Perryman on 10 Jan 2008 04:29 John Carter wrote: > I've been brewing a doc on asserts in embedded systems for awhile and > finally updated it and slapped it on a wiki somewhen. > http://software.wikia.com/wiki/Asserts_for_Embedded_Systems > It's delibrately bold and opinionated to move the state of the art > forward a bit. > It's on a wiki, so don't whinge about it, if you don't agree or don't > like or have a quibble with the grammar. > Edit it and correct it. 1. No. This is akin to someone doing poor homework and then asking others to make it correct by saying "if you don't like it, change it." . 2. State of the art (a necessity IMHO for anyone attempting serious works) What do other places (Wikipedia etc) have to say about the topics you are discussing ?? Are you re-inventing the wheel ?? Because of 1, I am only going to "red ink" your Wiki ... I would suggest the following structure /summary topics/info : - Assertions (only briefly what they are) - Correctness artifacts Pre/post/invariant conditions (specific forms of assertion, only briefly what they are intended for). Uses (component documentation, correctness proving etc, the Design by Contract concept in Eiffel) . - Assertion failure What is done when one occurs ?? Examples such as : DbC : assertion failure = defect, defect = immediate program termination Defensive programming : assertion failure = defect *or* problem. Attempt to set system/components into a state where defined behaviour can continue to execute correctly. Regards, Steven Perryman
From: John Carter on 13 Jan 2008 17:33 On Thu, 10 Jan 2008 09:29:55 +0000, S Perryman wrote: > John Carter wrote: > >> I've been brewing a doc on asserts in embedded systems for awhile and >> finally updated it and slapped it on a wiki somewhen. > >> http://software.wikia.com/wiki/Asserts_for_Embedded_Systems > 1. No. > > This is akin to someone doing poor homework and then asking others to > make it correct by saying "if you don't like it, change it." . Nope. If you'd done your homework and read the link properly you would realize.. - I've done lots of homework, - done it properly, - integrated many sources, - contributed large chunks of my own two decades experience, and then been humble enough to realize that... * I, like all humans, still make mistakes. * and there are still folk out there who know more than me... * and still folk who have had different experiences, hence view things differently from me. and I'd deeply welcome their contributions. > Because of 1, I am only going to "red ink" your Wiki ... Sigh. > I would suggest the following structure /summary topics/info : > > - Assertions (only briefly what they are) Watching programmers in practice, what they mostly don't get, is what assertions aren't. > Uses (component documentation, correctness proving etc, the Design by > Contract concept in Eiffel) . I'll admit I haven't seen a convincing practical example of correctness proving in industrial code yet, so I can't personally describe its use in embedded systems. Used splint to do a bit of incorrectness proving, never correctness. Perhaps you have something to add to the wiki? > What is done when one occurs ?? > Examples such as : > > DbC : assertion failure = defect, defect = immediate program termination If you read the link, I argue that immediate program termination is a Bad Policy in embedded systems. Assert expressions are code too. They also have bugs. Embedded systems in the field usually can't be reprogrammed instantly, they suffer with what they've got, potentially forever. There are better policies to handle the problem. > Defensive programming : > > assertion failure = defect *or* problem. Attempt to set > system/components into a state where defined behaviour can continue to > execute correctly. You may have an idea by the tail here. I'm not sure I quite understand it, perhaps you could expand on it in the appropriate place in the wiki. John Carter
From: S Perryman on 14 Jan 2008 04:28 John Carter wrote: > On Thu, 10 Jan 2008 09:29:55 +0000, S Perryman wrote: >>I would suggest the following structure /summary topics/info : >>- Assertions (only briefly what they are) > Watching programmers in practice, what they mostly don't get, is what > assertions aren't. If you are briefly telling them what they are and are not for, nothing more to be done IMHO. >>Uses (component documentation, correctness proving etc, the Design by >>Contract concept in Eiffel) . > I'll admit I haven't seen a convincing practical example of correctness > proving in industrial code yet, so I can't personally describe its use in > embedded systems. > Used splint to do a bit of incorrectness proving, never correctness. > Perhaps you have something to add to the wiki? No need. In mere seconds I typed "wiki correctness proving" into a search engine and got : http://en.wikipedia.org/wiki/Formal_verification >>What is done when one occurs ?? >>Examples such as : >>DbC : assertion failure = defect, defect = immediate program termination > If you read the link, I argue that immediate program termination is a Bad > Policy in embedded systems. DbC is a *correctness* method, not a *defensive programming* or *fault tolerance* method. Program termination occurs because *no assumptions about what the system can or will subsequently do can be confidently made* . >>Defensive programming : >>assertion failure = defect *or* problem. Attempt to set >>system/components into a state where defined behaviour can continue to >>execute correctly. > You may have an idea by the tail here. I'm not sure I quite understand > it, perhaps you could expand on it in the appropriate place in the wiki. http://en.wikipedia.org/wiki/Defensive_programming Tis a well-known approach in s/w development. Anyway, as I stated, there appears to be enough out there already in Wiki world covering the topics that you are attempting (or are yet) to discuss. Some of these (the original Wiki etc) will allow you to put your own comments in (present/contribute to a wider/larger audience than you may otherwise get etc) , and get some useful feedback. Or perhaps your musings would be better in blog form. Regards, Steven Perryman
From: John Carter on 14 Jan 2008 20:07 On Mon, 14 Jan 2008 09:28:30 +0000, S Perryman wrote: > John Carter wrote: > >> On Thu, 10 Jan 2008 09:29:55 +0000, S Perryman wrote: > >>>Uses (component documentation, correctness proving etc, the Design by >>>Contract concept in Eiffel) . > >> I'll admit I haven't seen a convincing practical example of correctness >> proving in industrial code yet, so I can't personally describe its use >> in embedded systems. >> Perhaps you have something to add to the wiki? > > No need. In mere seconds I typed "wiki correctness proving" into a > search engine and got : > > http://en.wikipedia.org/wiki/Formal_verification Which doesn't (in the current version of 07:14, 10 January 2008) even have the word "assert" in it. Very useful. >>>What is done when one occurs ?? >>>Examples such as : > >>>DbC : assertion failure = defect, defect = immediate program >>>termination > >> If you read the link, I argue that immediate program termination is a >> Bad Policy in embedded systems. > > DbC is a *correctness* method, not a *defensive programming* or *fault > tolerance* method. Program termination occurs because *no assumptions > about what the system can or will subsequently do can be confidently > made* . Yip. One assumption can be made. If you immediately terminate, you can definitely assume the current operation will fail, instead of probably fail. Since the reason it is failing is because your software is buggy, how can you assume your assert expression is less buggy than the rest of your software? (Exercise for the Reader: Assert expressions are probably more buggy. Why?) Why should you assume a bug == customer impacting problem? Most are not! The Coverity group has (had?) a wonderful Too Much Truth in Advertising thing on their web site recently.... A rave review from a Big Customer that claimed coverity had found thousands of bugs in their product that had been shipping for years to hundreds of customers. Clearly after a few years of "test&fix into a shape of a product" 99% of the remaining bugs never impact the customer. Given that the only fix for an assert failure is.. * to recall the embedded device to a service center, * wait for a new release of software to come out, * and reprogram it. (Assuming it's recallable, assuming there is a service center, assuming you can bear the cost of a recall, assuming there will be a new release in time to be useful, all _very_ big assumptions.) Perhaps, after all, the correct thing is to just record the program counter in persistent store and quietly carry on. >>>Defensive programming : > >>>assertion failure = defect *or* problem. Attempt to set >>>system/components into a state where defined behaviour can continue to >>>execute correctly. > >> You may have an idea by the tail here. I'm not sure I quite understand >> it, perhaps you could expand on it in the appropriate place in the >> wiki. > > http://en.wikipedia.org/wiki/Defensive_programming Hmm. The wikipedia isn't quite saying the same thing as you are, (nor what I have been saying about Defensive Programming.) There definite differences. > Anyway, as I stated, there appears to be enough out there already in > Wiki world covering the topics that you are attempting (or are yet) to > discuss. Nope, not quite. Besides with the Wikitrogs, the only way to make anything stick on the Wikipedia is to place it on another website and reference that. :-) Dumb policy if you ask me, but then nobody did... > Or perhaps your musings would be better in blog form. Nah. Blogs are for wimps who can't handle acerbic trolls on usenet.
|
Next
|
Last
Pages: 1 2 Prev: Software Engineering Training in Memphis, Tennessee Next: Two Active Interface |