DO-178B Objective A-1#2

DO-178B Table A-1 objective #2 requires that transition criteria, relationships, and sequencing is defined for the various processes. Simply put, you need to think about not only each of the individual processes (writing requirements, implementing code, verifying, performing CM, etc) but how they relate to each other.

To some extent this is a no-brainer: first you write requirements, then you write code, then you verify, then you CM the whole thing at release time. To some extent these tasks will probably overlap: you’ll probably start coding before all the requirements are written, and you’ll probably start verifying before you’re completely done coding. The important thing with objective #2 is that you define when these processes will happen, with respect to each other.

This is also as good a place as any to start with the reminder that these tasks should be performed roughly in order. You don’t want to be coding the whole application first, then backward-engineering the requirements to match what you coded. It’s just not good practice, and it’ll lead to headaches in the end. The best projects I’ve ever worked on in my avionics career have been the ones where requirements and design were rigorously documented prior to coding. It makes the coding task easy and definable, and it leaves you with a easily-certifiable product when you get done.

Let’s end this with an analogy. I think of process as something akin to the protected areas of my favorite Unix box. In normal user mode, I can’t make changes to those areas or settings, nor should I. At times, though, it becomes necessary to make changes. At those times I make judicious use of the sudo command and perform the changes that I need. Then I go back to working in user mode, and back to working under the rules and permissions that I’ve set up.

Processes work the same way. Yes, there are ways you can go and change them, and times when it is appropriate to do so. But other than those times, work in user mode and follow the processes.

DO-178B Objective A-1#1

The first objective in table A-1 requires that software development processes and activities are defined. This objective applies to all software levels (A – D), and generally compliance is found in a Plan for Software Aspects of Certification (PSAC), a Software Development Plan (SDP), a Software Verification Plan (SVP), a Software Configuration Management Plan (SCMP) and a Software Quality Assurance Plan (SQAP).

While the PSAC usually stands alone as a document, the other plans are, in my experience, usually grouped together in some combination; typically SDP and SVP get released in the same document. As with most of the DO-178B artifacts, where you put the data isn’t quite as critical as just that it all exists somewhere.

Interestingly enough, for Level D software, the plans must be defined though the objective that the plans comply with DO-178B doesn’t apply. Which, in short, means that for Level D, you must have and follow some sort of plan, even if it isn’t compliant to DO-178B.

Hey, nobody said it had to make perfect sense, did they?

Planning Documents and Level D Software

There’s an interesting little conundrum with Table A-1 of DO-178B when it comes to Level D software. The first objective in the table requires that software development process activities are defined. However, given that A-1 #6 isn’t applicable to Level D, there is no requirement that the plans actually comply to DO-178B.

In the case of other Level D objectives, this can mean that the artifact doesn’t need to be created. For instance, none of the table A-4 objectives apply to Level D, save the one about partitioning integrity. This is usually interpreted to mean that low-level software requirements aren’t required for Level D software.

With planning documents, though, the bar is a little bit higher, since Table A-9 requires that independent assurance is obtained that the development and processes complied with the approved plans and standards.

Let’s just summarize it this way: For Level D software, you have to have a plan. And you have to follow the plan. You don’t have to show, however, that your plan complies with DO-178B. Non-intuitive, maybe – but simple enough.

How close to formal release do you fix problem reports?

This is a familiar question that comes up at the end of software release cycles. Software development has been completed. Verification is concluding. The last few tests are being run and a problem shows up. What do you do now?

If it’s a serious functional problem, the answer is obvious: you fix it (and hope that it’s not so serious that it affects your delivery date). But what if it’s a minor failure? Still an error, to be sure, but one that is unlikely to show up in any normal use case?

There is a point at which it becomes counter-productive to continue making changes to the software. If the fix for the bug is isolated and easily identified, sure, fix it. But if there is some uncertainty about the fix, or if there is concern that the fix will impact other functional areas in the software, then it is reasonable to leave it alone. The risk of causing other problems in the software with hasty last-minute fixes becomes greater than the risk of leaving the known problem in place.

Be sure to document the problem with a problem report so that it can be fixed for the next release. And be sure to document the problem report, along with the rationale for why it’s safe to leave in the build, and put that documentation in the Software Accomplishment Summary.

Sometimes it’s just safer to leave the bug there.

Host-based Coverage Analysis

Often times, for various reasons, it seems preferable to collect source coverage analysis data on the host – i.e. on some hardware platform that is not the final hardware platform. As far as this author is concerned, it sounds like a reasonable thing. Here’s what you’ll need to ensure:

1. Make sure your pre-processor settings are the same.

You don’t want to be running source coverage analysis on different sources. Now, there will undoubtedly be code (at the very highest and lowest levels) that will be different – the typical #ifdef WINDOWS and #ifdef TARGET_OS type flags. That stuff may need to be analyzed manually. But otherwise: keep your preproc settings the same.

2. Confirm that the results of the functional tests run for SCA are identical to the results when those tests are run on the target.

To get SCA, you have to run requirements-based functional tests. Those functional tests should run with identical results between the target and the host. If they do, you will have confirmed (by inference) that you have achieved complete coverage on the target, you just haven’t measured it.

If you keep these two goals in mind, host-based SCA should be sufficient to comply with DO-178B objectives and should be much more efficient than doing full measurement and analysis on the target.

Reasonable types of verification for low-level requirements

One question that frequently comes up when discussing verification of safety critical software is exactly how certain requirements will be verified. For instance, you may have a requirement that says

The application shall load the processor’s Control Register with the value 0×12345678 during powerup initialization.

The need for the code in question is obvious. Whether such a requirement should actually be a requirement or design detail is debatable. (In my opinion it should be design detail.)

But if it is a requirement, how do you go about verifying it?

I have had verifiers suggest that the best way is to do white-box testing, to set a breakpoint in the code in a debugger and verify that the line of code is actually hit, and to then examine the contents of the register to verify that the value is present. While this is certainly a valid test, I think it’s overkill.

Assuming that the value you’re writing to the register is important for the software to run correctly, by doing any functional testing you have implicitly verified that the value was written to the register. Additionally, recall that DO-178B requires that each requirement be verified; however, it provides for multiple ways of performing that verification, including code inspection.

In my opinion, if you have a low-level software requirement similar to this one, the combination of a code inspection and an implicit functional test is sufficient verification of the requirement.