Re: Books / Articles on Embedded SW Architecture

Steve at fivetrees wrote:
"Usenet Groups" <myusenetaccount@xxxxxxxxx> wrote in message news:449adee7$0$11067$9b4e6d93@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Steve at fivetrees wrote:
"Usenet Groups" <myusenetaccount@xxxxxxxxx> wrote in message news:449acfdb$0$11066$9b4e6d93@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I'm looking for information (good articles, books, websites) concentrating on SW architecture themes related to Embedded platforms.

Primarily SW architecture discussion seem almost solely devoted to the PC world and object orientated languages. I do find some of these topics also apply to the embedded world however I'm missing topics on issues like the list below.

:Multi-processor communication
:Multi-processor System Partitioning
:Protocol Handling
:POST (Power On Self Test)
:Distributing System events (i.e. power up)
:ISO Network Model
:Debug/Trace Strategies
:Error Handling
:How to benchmark sufficiently
:Event-Driven Systems
: ...

Which books do you use when tackling problems such as those mentioned? Which issues should be added to the list?
You missed the most important one:
- Designing demonstrably bug-free software and systems

Steve interesting but I think we should accept that with the tools/languages we use 'bug-free' isn't going to happen, except on trivial projects.

No. Absolutely, categorically, emphatically not. The "complex software must be buggy" myth is one I absolutely, categorically, emphatically refuse to accept.

I deliver products, of any level of complexity, when they're bug-free. Not before.

Super. Can you describe in a few words the complexity of these systems? How many Engineers are in the project team, when in the development process you receive final complete requirements, is the time frame of the project realistic? Do customers not mind you finding all the bugs before delivering?


"Trivial projects" only? No. That's an example of the Wrong Attitude. Sorry, but you failed ;).

Yea OK. Trivial wasn't the right wording.


The thing I find weird is that designing reliable systems (with "thou shalt not crash" in mind) takes less time, mainly because it cuts out the whole asymptotic "reducing bugs to nearly but not quite zero - until we run out of time" phase. This seems to be a well-kept secret. I find this weird. All branches of engineering I've been involved in have been driven by economics, except this one. (I think I know the reason, and it ain't pretty.)

To add just a little: robustness is always the key attribute. *Design* for zero errors; debugging is something that you do when you fail, so aim not to. The hack/debug approach must be seen for what it is: amateurish tinkering.

I don't accept that. We should build mechanisms into our systems in order to 'see' our systems in work. If you or someone in your team does happen to 'fail' then do you have the right tools/procedures for fixing that error? Logging tools, printing debug lines to stdout etc all have their usefulness and should be designed in from the ground up.

What you're describing is debugging, which has its use during development (mostly against typos). But again - a properly designed system won't need debugging (other than the typos). Period. "Proper design", however, is rare - and rather beautiful.

I think we need to be careful what is the environment these projects are being completed under. There are many external factors which conspire to frustrate a development team but this sounds like something which you don't suffer from.


Achieving this is not always easy, but *should* be what we all aspire to. Acceptance of failure is far too common in s/w design, and simply unacceptable in embedded work.

No one should set out with the mind-set that they will deliver a buggy product, of course not. However the products which i work on can not be 100% adequately tested due to external events (user or external components) and differing state machines in the product.
What if one of your products was returned because it was suspected as being faulty. How would you debug the device in this case? What hooks do you build in from the ground up in order to help you investigate? Lets be clear here, I'm not suggesting for a second that you don't have any bugs. You've made it clear that you don't deliver bugs, however you still have this device you have to investigate.


Of course you can always over design a system. The more non-functional modules you include, the more complex the system the more chances you have to fail. Like everything it's a balancing act.

Bollocks. To be blunt.

Ho hum!

A complex system is a collection of simple parts, or or complex parts consisting of simple elements. It's the interactions between these parts that confuse us. Which is dumb. We should be designing in terms of interactions and simple things. Complexity doesn't exist - unless you don't understand the problem, or the solution offered.

As for over-designing - no, again. Equating "it shall not crash" with "overdesigning" is precisely the kind of attitude I'm up against on a regular basis, and one I frankly despair of. Paraphrasing what I said earlier, acceptance of failure is a malignancy.

Hang on a second. I was not suggesting that one must over-design in order to have a 'it shall not crash' type of product. I only mentioned that in order to offer more and more debug/trace features more SW is required and thus the complexity might/will go up. I forget which book it is but it states that you should always be careful in the 2nd system you design in order not to over-design to compensate for the problems which arose in the 1st system.


I would be interested in techniques people use to debug their systems. Printing to a serial port is OK if you have a spare port but it also can be CPU intensive if the developers over do it with the debug lines.

I mostly use a single LED. Otherwise, I endeavour to ensure that the effects of a simple failure are catastrophic - which means I won't miss it. Seriously - I try hard to ensure things don't get overlooked.

Of course and I agree but a single LED does not scale up well to systems with a task scheduler and time-dependent protocols. More sophisticated tools are required.

Steve
http://www.fivetrees.com


.

Relevant Pages

  • Re: Commenting the source code.
    ... > Do you comment your source code while coding or after coding. ... break down the design to be more specific ... write, document, compile and debug debug fuctions. ... Whereas successfull means dedect bugs, ...
    (comp.lang.c)
  • Re: does VS C++ 2005 actually work????
    ... Anything that deals with teh actual IDE and is broken is ... probably due to either design flaws or bugs (testing apparently wasn't high on the list of ... Microsoft or have anything to do with the design of this product. ... I'm just trying debug the application using ...
    (microsoft.public.vc.mfc)
  • Re: Evolution Theory Collapsed, Quick Put Back Up
    ... Engineers strive for simplicity, not complexity. ... not a good indicator of design. ... AND natural selection. ... Yes of course natural selection acts on the random mutations. ...
    (talk.origins)
  • Re: How to disprove Intelligent Design
    ... > complexity or irreducible complexity. ... > an intelligence by using one or more of the various techniques of ID. ... For the purposes of the science of intelligent design, ... If you can disprove one of these assertions mathematically, ...
    (talk.origins)
  • Re: Pitmans Miller Time
    ... this evidence could equally be explained by common ... design and common descent. ... The real absence in the pattern is more than ... You have presented no metric of "level of functional complexity". ...
    (talk.origins)