Comments on: Robust Embedded Software Architecture in 5 Easy Steps

By: Thomas Honold

Thomas Honold — Thu, 08 Oct 2009 13:58:04 +0000

I have read your post and want to give some feedback. First I have enjoyed reading it. The best part for me was Step 2: "Distinguish architecture from design" showing the different levels of HOW.For the test aspect I think you haven't yet shown the complete picture. Since testing is about 60 % of the whole project time, I think it should be a little bit more detailed. Here is what I suggest:In Step 4: "Design for test" from my point of view it is missing that the tests should all be requirements driven. This means, that the requirements which were defined in Step 1 are the base of all tests. This formal approach has the big advantage that you do not test what the code does (like white box Unit Tests in the past), it is tested what the code is supposed to do.It should also be stated that it is not required to test each requirement by a single test. To reduce the overall test time, you can run the OK-case tests first by using the Release Build of the product. Then you check what requirements where already covered. Then the Error-Cases should be tested by an instrumented Debug Build (by injecting errors), to see what happens in error cases. It is a Debug Build, since the final code should not contain any test features, since they are unused code in normal operation.What we do in our SW development process for avionics equipment (DO-178B) is1. Run test procedures with all requirements based OK-cases (Release Build of SW)2. Run test procedures with all requirements based Error-cases (instrumented Debug Build)3. Do dedicated Unit Tests for modules which were not coverable by the first 2 steps4. If Unit Tests do no cover 100% of the code, manual code inspection fills this gapWe use PERL scripts on a Personal Computer commanding the embedded system to execute the dedicated tests. The test results then are sent back to the PC for a final report. All tests have to run automatically without any user interaction.This test approach is quite a lot of work for the first time. But for all further SW releases it pays off.I have once read that the most SW bugs are introduced by SW changes. I think this is absolutely the truth.I'm looking forward to you next articles for this matter.kind regards,Thomas

By: Rob Williams

Rob Williams — Sun, 20 Sep 2009 20:06:53 +0000

A recommendation that has several plus points in its favour is to clearly divide the requirements into "Positives" and "Negatives". The positives state what the system should be able to do, while the negatives identify the behaviours which are to be avoided at all costs.There are at least three advantages for establishing the distinction at an early stage in the development:1. Separate the development team into two parts, one to deal with the core functional behaviour, while the second deals with error management aspects. This eliminates, or at least mitigates, the worst case errors which arise from misunderstanding the original requirements spec. The two teams carry out separate analysis, design and implementation, with less chance of propagating the fundamental mistake throughout the final system.2. It reduces the likelihood of a conflict with clients around some "implied" behaviour. Having documentation that states what the system will NOT do is a powerful argument in any dispute.3. The separation of functional core code from the associated error management routines, as far as possible, improves testability and eventual reusability.

By: K1200LT Rider

K1200LT Rider — Fri, 18 Sep 2009 17:47:35 +0000

One basic problem with requirements that I've seen a handful of times goes something like this:"The event shall occur at 30 Hz" – with no tolerance specified. As written, a measured frequency of 29.9999999 Hz is a failure. In this case, repeated requests for a tolerance went unanswered, so we picked what we thought was suitable, and the requirement has never been edited. Amazing.

By: Nigel Jones

Nigel Jones — Fri, 18 Sep 2009 13:05:33 +0000

Very nice article Mike. I could probably write an essay on all my thoughts, but I'll restrain myself to the first step that you outlined – namely the 'what'. In my experience this is amazingly difficult to obtain. Particular problems I often see are:1. An incomplete list of 'whats'2. A 'what' that is incomplete. For example "The oven must be up to temperature with 5 minutes". Seems clear enough – until you realize that getting it up to temperature is one thing, but ensuring it doesn't overshoot by too much is another!3. Over specification at times. (I see this a lot on government type requirements)Anyway, given that it's the first step (and in my opinion the toughest to get right), it's hardly surprising that a lot of products have architectural problems.

By: Sundar Srinivasan

Sundar Srinivasan — Thu, 17 Sep 2009 17:52:29 +0000

That's simple and neat, Michael. But I think this would work only if performance is the single design objective. We crack under pressure when we have to guarantee performance under the constraints of power, area, and of course time to market. That's when we have to start looking at application-specific hardware. That part is not addressed.