Preparing for SOI-3

Process assurance is a really important role in a DO-254 program. If done well, it can save companies a lot of time and expense by making SOI audits go smoothly and avoiding unnecessary rework. As an example, I was recently holding a SOI-3a audit, which includes checking the ability to rebuild and regenerate the test environment and results. While the company had the necessary documentation as part of their Hardware Verification Plan (HVP) there was still a lot of confusion about which files to pull and where the evidence resided – which boiled down to versioning and control of the files. So I suggested two things.

  1. Creating a VCI (verification control index) document to control all the test bench files, models, scripts –basically the collection of items used when testing the FPGA. After all, this repository of data is very similar to the design (hardware) repository, which is controlled by an HCI.
  2. Holding a Process Assurance “test readiness review” prior to the formal test for credit audit to run through the process internally prior to the SOI audit. The Job Aid, Section 3-3, provides a really good guide for what to review.

Running tests without proper conformity of the test environment and design could result in a full rerun of tests, which can take weeks! So doing these two fairly simple things can save time and frustration in the long run.

“… the Process Manager referred to these suggestions as one of the most important tips he ever learned from a DER”

In my example above, these small changes made a world of difference the next time around, and the Process Manager referred to these suggestions as one of the most important tips he ever learned from a DER. Try it yourself and see the difference it can make in your processes.

Patmos Engineering services offers both guidance for your program as well as auditing services. If you need help preparing for SOI-3 – or any audit for that matter – contact me to set up a discussion.

Tammy Reeve has been involved in the certification of hardware (DO-254), software (DO-178C), and systems (ARP 4754A and related) for nearly 20 years.

Tammy Reeve
DER/Founder
Patmos Engineering Services, Inc.

Bottom Up vs. Top Down

One of the things I see and hear is that we can “finish that certification stuff later.”  Many people believe that you can add the compliance data items to the project after you “get it working” or you “know you are finished with design and implementation.”   This bottom-up approach to Certification compliance under DO-254 and DO-178 is in direct opposition to why these design assurance documents were drafted. Let me be clear: while there is room for a rapid prototyping flow within the constraints of these design assurance documents, this sort of flow is only used as a way to validate and confirm that you have the right set of requirements.

A bottom-up compliance effort does not equal top-down unless you have relatively simple functionally.  Design assurance processes described by DO-254 and DO-178C are both in place to acknowledge the complexity of avionics systems and the inherent knowledge that if you wait to perform verification and validation on the final image you will be faced with the inability to show you adequately identified potential errors in the design.  This concept is discussed as the Complexity Barrier [Beizer90] principle: Software complexity (and therefore that of bugs) grows to the limits of our ability to manage that complexity. This is why DO-254 design assurance standard was written primarily for “complex” hardware and there is an acknowledgment that for simple systems the majority of DO-254 does not apply.  DO-178C section 12.3.2 allows for “exhaustive input testing” of your software if it is truly simple as an alternate means of compliance.   Top Down design assurance defined in DO-254 and DO-178C hinges on the concepts of integral processes and transition criteria throughout the development with levels of independence and process assurance that will help to identify design errors earlier and throughout development.  In other words, the whole purpose of “design assurance,” be it in software or hardware, is to demonstrate that during the process, you have taken all pertinent steps to ensure you are catching and/or eliminating design errors at every step of the design (i.e., development) process.[Beizer90] Boris Beizer, Software Testing Techniques. Second edition. 1990

If your management or someone on your team is struggling to understand the purpose and/or basic requirements of compliance – whether its at the hardware, software or systems level – Patmos Engineering Services training can help. We offer a class called “Certification Overview” which covers the fundamentals of compliance at all these levels.

Tammy Reeve has been involved in the certification of hardware (DO-254), software (DO-178C), and systems (ARP 4754A and related) for nearly 20 years.

Tammy Reeve
DER/Founder
Patmos Engineering Services, Inc.