6
$\begingroup$

As per DO-178 C section 6.2 Overview of Software Verification Activity

b. When it is not possible to verify specific software requirements by exercising the software on a realistic test environment, other means should be provided and their justification for satisfying the software process objectives defined in the Software Verification Plan or Software Verification Results.

After reading this every/most of verification engineers would understand it as other verification methods like Analysis, Inspection etc...

As per the discussion and Arguments "The real intent of this objective is how do we verify the software when hardware is unavailable" like, using simulator to verify the software needs to be documented under SVP for this objective satisfaction.

The question is, DO (document Order) as evaluated from version A, B to C now and still have ambiguities and different understandings. Why don't FAA/JAA can come up with examples or layman language explanations for each objective?

$\endgroup$
  • 1
    $\begingroup$ I guess because it would bloat the document. $\endgroup$ – ratchet freak Nov 20 '15 at 10:54
  • 7
    $\begingroup$ The moment you start listing examples, some will take them as normative. This might not be the reason, but it is certainly a reason why adding examples to legislation (or legislation-equivalent documents) is usually a bad idea. $\endgroup$ – a CVn Nov 20 '15 at 12:13
  • 2
    $\begingroup$ @MichaelKjörling has a great point: spend some time on StackOverflow and you'll quickly find out how many 'professional' software developers simply copy and paste code blindly from documentation or other sources without ever understanding it. For critical systems you don't want "layman language", you want precise and unambiguous specifications. In extreme cases the specification can even become a kind of pseudo-code itself but that's the price you have to pay. $\endgroup$ – Pondlife Nov 20 '15 at 14:01
  • 3
    $\begingroup$ The question sounds like a complaint (or a suggestion) for the ambiguity for non-experienced engineers/developers. I believe any thorough elaboration of the topic would result in the correct understanding. Not only DO, but also other guidebooks (even standards) most of the time leave the door open so that "if you can't do sth the proper way, (try to) do something that is good enough, and plan for it"). If they do not leave this door open, it would ask for out-of-this-planet tests (test everything on real hardware!). $\endgroup$ – Gürkan Çetin Nov 20 '15 at 19:36
  • 1
    $\begingroup$ 'As per the discussion ...' Which discussion? $\endgroup$ – DeltaLima Nov 22 '15 at 22:47
7
$\begingroup$

RTCA documents are not FAA documents, although the FAA is usually a member of the Special Committee that creates the documents. If an example is to be added, it is the decision of the SC, not of the FAA.

The reason that no examples are given is that the recommendation is clear by itself. A good V&V engineer will read this recommendation and use his skill, experience and creativity to find an other acceptable means to validate the software requirements that can not be validated in a realistic environment. This alternative means is then documented in the SVP.

Giving an example is not helpful at all, since the solution will depend completely on the software under test and the nature of the requirements.

If the hardware is not available, an emulator may be the solution.

In other cases artificial test inputs have to be generated, because failing a test in a realistic environment may prove to be catastrophic.

$\endgroup$
3
$\begingroup$

The FAA interprets a limitation to its authority (which is derived from FAR 25.1309 for transport aircraft, for example): It is not supposed to say anything is required to demonstrate compliance (for a module of software or a system of hardware) and be approved in the context of a certified aircraft. It can (and does) specify certain steps which constitute acceptable means of compliance.

The documents in the "chain of authority", not only DO-178C and DO-254, but also AC 20-152, are always careful to say that alternative means of compliance may be acceptable.

The practical matter, however, is that if DO-178C is even plausibly appropriate for a software module, and if hardware being developed is at all within the ballpark of DO-254, the DER is likely to insist that those standards be followed. And the FAA is certainly comfortable with that stance. So although these documents are not normative, they are as important as if they were normative.

If the standards did include examples of alternative means of compliance, one of two things would happen. Either these examples would be taken in the same semi-normative light that the rest of the standard is taken, in which case approval (where appropriate) based on some other means of compliance would be that much less likely to be accepted, or the existence of the examples would overly encourage developers to fight for acceptance of their own means of compliance, in cases where DO-178C is perfectly applicable. The latter would surely generate "more heat than light."

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.