Bookmark and Share
Blog powered by Typepad
Member since 03/2007

Become a Fan

« Review Checklists | Main | DO-178B and Aircraft Accidents »

November 20, 2010

Comments

Feed You can follow this conversation by subscribing to the comment feed for this post.

RMH

We thought DO-178B was clear of course; but it is now much more explicit in the new revision.

Amitabh

@RMH, I would agree!
I wonder how your peers would react when they hear at the next DO-178C session your proposal to get rid of the Tables!
Perhaps a better way to get around is to indicate at the beginning of the Annex A, a sort of caution or warning: The Annex is just that: an annex. It is

    not
the body of the document.
Or something to that effect.

RMH

I see an enormous amount of misunderstanding of the document from regulators, DERs and engineers themselves simply because they do not understand the purpose of the tables, and do not read the text properly. And I would cite as a prime example the question that began this thread. Perhaps the tables should have been removed from DO-178C to encourage people to read the document?

Amitabh

@RMH,
You obviously feel very strongly about it!
Frankly, I have always used the Annex as a starting point. It serves to hold your attention up - standards can be somnolent. Or at least it has helped me navigate the standard easily. So, as long as one does not restrict oneself to just the annex to interpret the whole of the DO-178B, I think it should be ok to start off with the tables, like so: http://aerospacesoftware.typepad.com/aerospace_software/2007/03/how_to_read_do1.html

By the way, there is one more reason for a desire to deal with tables first. Look up any DO-178B checklist. What are the checklist points mapped to? Tables in Annex A, of course. I have seen SOI checklists that map tp the tables. And though I understand the reason for the map, since the idea is to see if the objectives are met or not, from an engineers point of view, the tables become all important.

RMH

I need to stress that we never wrote the Annex A tables to do any more than specify the applicability of the objectives, activities and software life cycle data for each software level as well as the variation in the independence and control categories for each software level. If you are trying to do anything else with the tables you have fundamentally misunderstood the entire document.

There seems to be an underlying issue here in that some people are using the tables as the starting point of using this document. This is truly the wrong approach - it is absolutely critical to understanding the subject that the full body of the document is read and understood.

It may be better to tear out Annex A if readers are still having such problems.

Amitabh

1) The objectives in table A-6.3 and .4 are satisfied by executing test cases as described in para 6.4.2.1, 6.4.2.2 and 6.4.3. You have to execute Requirements Based Testing using Normal and Robustness test cases.

2) These have to be done for Levels A to C.

3) It is generally assumed that just because the objective states "low level requirement", a low-level testing (meaning, Unit Testing) is required to be done. True for most cases but not necessary. You may do high-level testing and by analsis show that all low-level requirements are covered. We have executed such V&V projects at AK Aerotek.

4) "Source to object code analysis" is a different ball game. Refer para 6.4.4.2.b of the DO-178B for details.

And finally, RMH is correct. Equal focus, if not more, needs to be given to the body of the DO-178B.

RMH

The problem is that you are reading too much in to the Annex A tables - you need to read the body of the document (Sections 6.4.2 and 6.4.3 in this case) to understand what is required - not the tables.

The purpose of the Annex A tables is simply to specify the applicability of the objectives, activities and software life cycle data for each software level as well as the variation in the independence and control categories for each software level. In order to fully understand the guidance, it is absolutely paramount that the full body of the document is read and understood.

Pradeep

DO-178B table A-6.3 & 6-4 specifies "Executable Object Code complies with low-level requirements " & " Executable Object Code is robust with low-level requirements ".
At which level of testing these objectives can be satisfied ? As low level requirements are mentioned we think that it is Low level testing ? Is our understanding is correct or is there some underlying philosophy behind this? Some are interpreting that these objectives can be satisfied with "source to object code analysis " but it should be through testing right?

The comments to this entry are closed.

My Photo

Life sometimes turns on a dime. Especially when you are actively looking out for a change. I now work at HCL Technologies. And all I am looking for is to make a difference. By the way, the blog contents remain my own. It does not reflect the official position of HCL.

Your email address:


Powered by FeedBlitz