Aerospace (DO-178B) Software

Interpreting Object Code Verification

The best way to interpret paragraph 6.4.4.2.b of the DO-178B is by using an "AND" logic.

Just to be clear what I am talking about, I quote the document: "The structural coverage analysis may be performed on the Source Code, unless the software level is A and the compiler generates object code that is not directly traceable to Source Code statements."

My interpretation:

The following 3 conditions apply:

(A) Structural Coverage analysis has to be performed on Object Code,

(B) The software level is A, and

(C) Object Code cannot be directly traceable to the Source Code

A == B AND C

Meaning,

We have to provide 100% Structural Coverage on the Object Code

If

The Software Level is A

AND

The Object Code does not have a direct correspondence to the Source Code

Thus,

If the Software Level is B, C, D or E, we can do Unit Level using any Qualified Testing Tool available in the market, since the condition (B) is False. Please note that  (i) most OTS tools instrument the source code, and (ii) you have to qualify the tool for the environment you are testing in.

If the Software Level is A, but we can prove that Object Code has a one to one correspondence with the Source Code, then condition (C) is False. This happens when you have an interpreter which trranslates each line of your source code to a set of object code. (Proprietary languages have this feasture). In this case again, go ahead and use OTS tools without any problem.

However, since compiler use is more wide-spread, condition (C) is never False. It is therefore easier to just go ahead and carry out an Object Code Verification whenever the software level is A.

A word of caution: it is fine to take credit from a previous project, as long as the the environment is identical AND the constructs of the language being used is identical.

Object Code Verification is applicable even when someone claims that s/he has set the compiler option to no-optimisation. After all the idea of verification is to doubt every claim. 

Independence = Outsourcing

I have always held the view that in order to achieve high quality software development and verification should be done by two independent companies. This belief is from experience.

In the very early years of our existence we became the sole supplier for verification of a Level A software for a UK based company. The initial verification was carried out internally by our customer. I am sure there must have been misgivings on our taking over the verification work, but our customer quickly realized the value we added. We generated Problem Reports by tons. Some of the PRs were trivial but most added value. Since this was very early in the development such huge PRs did not cause any major slippage in the end date of the project.

Why did this happen? Because we had to deliver quality. And quality to a verification-focused company is: 'no item that passes our hand should have a defect". We did not care if the designer will feel bad if we generate many PRs. All we cared that the customer should not come back to us saying you did a poor job at verification. (by the way, after all these years, I am still terrified that some customer will accuse us of doing a poor job at verification; and so all our outputs are gold-plated).

However, the above view I hold is self-serving. If companies outsource verification, then some of it will definitely come our way! I was therefore pleasantly surprised when I read in CAST-26 discussion that one of three perspectives with regard to what was meant by independence is called "Organizational Verification Independence Perspective". Finally, I have a documented support to my view. According to this perspective, "This perspective proposes that to truly achieve independence, the personnel performing the verification activity (i.e., review) should actually be in a different organization (or company) than the organization which developed the data being reviewed/verified."

The CAST paper does indicate that this perspective is beyond the DO-178B objectives' intent, I do wish this becomes the standard interpretation of independence in DO-178C or D or E.

Now, how is that for wishful thinking?

CAST - Independence of Test Case & Procedures Developer and Executor

In order to meet independence objectives A6-3 (Level A and B), A6-4 (Level A), and A7-1 (Level A), CAST-26 takes the following position:

"Test Execution: The person responsible for executing the tests should not be the same person who developed the requirements or code being verified by the tests, nor the developer of the test cases and procedures being executed."

I can understand that the test executor should not be the person who wrote the requirements or the code, but cannot really understand why the developer of test cases and procedures cannot execute the test cases. There are occassions when the development of cases and procedures is separated from test execution to ensure that the requirements of gate audits or SOI audits. But I have never come across any software plan or DER insisting on having an independent executor. Is this recommendation an overkill or is there a deeper thought that went into this? I wonder.

Free Webinar: How to Efficiently Develop DO-178B Certifiable Software

This is for information only.

Since I do not personally know these people I cannot vouch for the quality of the webinar. But I have interacted (fruitfully, I must add) with High Rely in the past and the Rational Software is good, and the fact that the webinar is free, you might want to give it a shot.

For details click here 

For more details click here

(Funnily, the two links show different topics - one might argue, efficiently = reduce the cost)

1539 Page Views in the last 30 Days

The heading says it all and I cannot stop smiling. Yeah! I know, I should be modest and all, but I just feel so happy about it. This blog is reaching out to many and that makes me real happy. I know there are hugely popular blogs with massive readership, and 1539 is a laughably tiny number, but then the number has jumped up considerably from what it was. That alone gives me a great deal of satisfaction.

But then numbers are just that - numbers. Many of you are obviously visiting my blog. What I am not sure is how useful this blog is.

I will be grateful if the vistors to this blog leave a comment on whether their visit was worth their while, or how this blog could be made better.