Showing results for 
Search instead for 
Do you mean 

Polarion Customers solve FAA challenges of DO-178B

by Dreamer on ‎07-19-2010 06:23 PM

Introduction

This document offers a high-level description of Federal Aviation Administration (FAA) DO-178B certification standards for aircraft equipment, arguably one of the world’s most stringent manufacturing standards, and explains how Polarion customers manufacturing software and hardware for airborne equipment rely on Polarion solutions to help them comply with FAA regulations and manage the complexities of planning, development, testing, and certification.

Background

The U.S. Federal Aviation Administration (FAA) requires that any software component that will be deployed on an airborne platform must first be certified compliant with requirements set forth in DO-178B, or “Software Considerations in Airborne Systems and Equipment Certification”.   DO-178B provides guidance on designing, specifying, developing, testing, and deploying software in safety-critical avionics systems. It was written to provide a way to determine, in a consistent manner, and with an acceptable level of confidence, that the software aspects of airborne systems and equipment comply with FAA airworthiness requirements. DO-178B compliance is now a strict FAA requirement. At more than 100 pages, DO-178B compliance is extremely involved. Automated requirements management is critical, and guaranteed traceability plus linked test case management are essential for successful compliance. In the beginning, companies chose to solve the challenge with manual processes mixed with legacy tools in a non-integrated manner.  As FAA scrutiny and enforcement of DO-178B increased, manufacturers quickly realized that the lack of an integrated solution for process automation made the certification effort very cumbersome, exposed verification and quality gaps, extended project schedules, and significantly increased costs. As in medical device manufacturing and other highly regulated industries having strict compliance mandates, aircraft equipment manufacturers are increasingly selecting Polarion Application Lifecycle Management (ALM) solutions to meet DO-178B certification challenges.  Aerospace customers of Polarion already include Northrop Grumman, the US Air Force, Goodrich, Thales, Airbus S.A.S, and Bombardier.

Relevant Components of DO-178B

Design Assurance Levels

Based on an FAA-mandated safety assessment process and hazard analysis, a Design Assurance Level (DAL) is assigned to each step of a project, ranging from ‘E’ (“No effect”) to ‘A’ (“Catastrophic”).  Depending on the DAL, different portions of different deliverables outlined in DO-178B become mandatory.  Software does not need to be certified specifically at each designated level.  Certification at any level automatically covers the lower-level requirement.

Process and Deliverables

DO-178B is a requirements driven waterfall development methodology.  You define and document:  i) project software life-cycle processes, ii) activities for achieving project objectives, iii) evidence indicating that the objectives have been satisfied. The project team defines and documents the specifics of how the actual project activities will be performed in the context of a process that must be undeniably linked to support the project’s DAL objectives.  In Polarion, these activities are defined by the project team as Documents and Work Items, authored with Polarion's LiveDoc environment (fully compatible with Microsoft Word®), with different aggregations of artifacts optionally presented in the fully-integrated wiki. These artifacts may be queried and reported at any point of their lifecycle on a 1:1 or 1:X basis for software verification results (SVR).

Polarion "LiveDoc" artifact-aware documents Requirement Artifact in Document

Software Configuration and Change Management (SCCM) is integral to Polarion as a result of the powerful Subversion (SVN) repository included. Issue Tracking and Problem Reports are inherent throughout Polarion and are similarly set up for an activity, project, group, or global basis.

Screenshot: Polarion POP Extensions Portal Polarion and the DO-178B allow a great deal of flexibility in following different styles of software life cycle. Polarion provides comprehensive, pre-fabricated project templates for processes from traditional Waterfall, Spiral, V-Model through CMMI to Agile; each include Software Quality Assurance Reports and all may be customized and reused to satisfy your company’s development style for DO-178B compliance. Once an activity within a process has been defined and documented, the FAA expects the project process to be followed and lifecycle changes maintained.  Polarion’s fully-configurable automated workflow enforces process compliance throughout the lifecycle, and maintains an immutable record of the activity on every artifact throughout the process.

Independence

Depending on the DAL, a certain degree of separation of responsibilities is required. For example: the person writing the code can’t be the one to test the code for the purpose of test-related DO-178B deliverables. The higher the DAL, the more independence   required. Polarion's support of role-based permissions in workflow configuration is particularly useful in enforcing this. In addition, the Polarion construct of version-controlling its configuration makes it auditable for the purpose of verifying compliance with these independence requirements.

Traceability

DO-178B requires traceability from system requirements to all source code or executable code, reviews, approvals, and testing thereof. Perhaps more importantly, everything in source control needs to be traceable to a system requirement. This is an area where Polarion’s solution strength exceeds all other vendors, providing immediate results and benefits for our customers.  Sometimes referred to as top-to-bottom and bottom-to-top, Polarion customers can easily trace back to the origin of each artifact component and forward through every change and derivative, with every attribute managed and maintained as an immutable secure record.

Traceability down to source code

Polarion customers also enjoy the benefit of one-to-one, and one-to-many traceability and reporting.  Each Work Item artifact can trace to multiple lower-level Work Items, while multiple higher-level Work Items can trace to the same lower-level Work Item.  For example, a software requirement often needs several test cases to verify it; each test case is automatically assigned and linked, and traces up to that single software requirement,  thus providing aggregate coverage of that requirement.   A non-functional requirement is often decomposed into multiple lower level requirements. Polarion automatically links, manages, and maintains the traceability to each lower-level requirement.

Tool Certification

Screenshot: History A tool needs to be qualified as a verification tool only if it replaces, automates, or reduces a DO-178B process activity, or if the tool can fail to detect an error in the airborne software. For example, if the tool will be making pass/fail decisions without a human fully reviewing the output of the airborne software, then that tool needs to be qualified as a verification tool. Depending on your organization’s use of Polarion, it is often not necessary to certify or qualify Polarion as verification tool. However, if you are using the unit testing features of Polarion, then certification is required. Because of the immutable history and granular change management records maintained by Polarion throughout the lifecycle of every artifact, certification (if required) is an easy straightforward black box process to prove that reporting data produced by Polarion is identical to the same data created manually.

Configuring Polarion

Polarion’s advanced ALM and Requirements Management technology, efficient reuse and process automation capability, together with expert professional services, enables Polarion Software to provide DO-178B compliant solutions for our customers.
Reusable documents
Existing waterfall development processes are provided out-of-the-box and are edited by the customer for their specific environment. Created once, the project templates with LiveDoc Documents and workflow are reused for derivatives or new DO-178B projects. Actual DO-178B certification has to come from a Designated Engineering Representative (DER) who is most often a FAA designated independent consultant. Due to the relative ambiguity of exactly what DO-178B requires of the various deliverables, it is best if a DER is involved early in the project, so he/she can more or less recommend how various deliverables need to be produced, and influence how to best edit or set up Polarion Modules, templates and workflow.

Polarion – Today's Best Solution for DO-178B Compliance

Polarion's ALM and Requirements Management solutions are designed from the ground up to facilitate compliance with stringent regulatory requirements throughout the full application lifecycle. Look around and compare: there is simply no other solution available today that delivers the same level of comprehensive, customizable coverage via a modern, secure web-based platform, as affordably as Polarion.

Aerospace Manufacturing Customer Testimonial:

“The use of Polarion during the DO-178B audit was, simply stated, incredible. The Designated Engineering Representative (DER), Defense Department representative, and the two representatives from the prime contractor (software quality and software engineering) all remarked that Polarion was "impressive". We were able to easily and quickly show that all changes to our software were tracked and reviewed and that our process was followed. The changes were tracked through the use of Issue Record (type) work items; the reviews were documented in Formal Peer Review work items, and the process compliance was documented in Phase Transition Record work items. All of these work items were linked - Issue Records linked to both the Formal Peer Reviews and Phase Transition Records, and Phase Transition Records linked to the reviews as part of the phase transition evidence. Also, the Issue Records were linked to the source code revisions, and we were able to show the changes to a source file matched the description of changes documented in the Issue Records.” Download the PDF version of this article