Tag: DO-178C

The Top 3 Types of Information Typically Missing from DO-178C Plans

Posted on by

As a certification expert and auditor, I see my fair share of DO-178C plans. No matter where in the world, no matter the project DAL or team experience, I consistently see teams struggle with including the right kind of information in their plans. 

First, if you’ve never worked on a DO-178C program before, starting with a good set of templates (with lots of examples and explanatory text) is a very helpful thing. They will provide you the layout of the document with all the pertinent objectives you need to meet. But templates are just that – templates for you to fill in all your pertinent project and process data. Most teams focus on how they are going to meet an objective, which is good, but insufficient.

So what are the most common things missing from these plans? It’s simple really. Just remember the 3 W’s – Who, What and Where – on every objective you need to meet. To be clear, you must answer:

  • Who is going to do the work
  • How they are going to do it
  • What will be produced
  • Where this evidence will be located

Let’s look at these a little more closely and consider an example.

To answer the “Who” question, you need to identify the team member, not necessarily by name, but by role and/or function within the organization, who will perform the task. To answer the “How” question, this is really where you describe through what means you’ll perform the activities required to meet the objectives. Most folks focus on the “how” in their plans, since this ties to the activities they will perform, but forget about the three W’s. To answer the “What” question, this is the output or evidence from the activities. DO-178C is all about demonstrating compliance, so this output of the activity is the proof that an auditor will require to ensure you did what you were supposed to. So where will they find it? That’s the “Where” question.

So for example, consider the objective of capturing requirements. If your plan states that you will have requirements, this is insufficient. It’s a given your project will have requirements that someone will document that will exist somewhere.  You need to state who in the organization (i.e., what role) is the responsible party for documenting the requirements. This list of roles and responsibilities should be clearly documented in your plans. In terms of how, you may say that you will be using DOORs (or some other tool) to capture the requirements. This is fine, but insufficient without stating the final form of the data that will provide evidence of the requirements capture. You need to answer what the team and auditors will be reviewing, and where this data will be located. For example, you may export the requirements from DOORS into a Word document or Excel Spreadsheet, which will be located in a certain directory and controlled via a version management system. While it seems like a given, you’d be surprised at how many times I go into an audit and the project leads says “I know we did this, but I can’t find the data.” By clearly planning both the form of the data and where it will exist is sure to make your audits (and whole project) go a lot more smoothly.

As an auditor, this is how I evaluate plans and the teams themselves, to ensure they have done a good job of thinking through everything they need to do in their project. If you can keep these basic questions in mind and answer them (in your plans) for every objective you must meet, your project will be off to a great start.

If you need help talking through a project to determine what you need to do, reach out to us here at Patmos for a free consultation.   Or if you’d like to start with planning templates, contact our sister company, Airworthiness Certification Services, which offers aids such as documentation templates and review checklists for both DO-178C and DO-254 projects.

Sincerely,

Tammy Reeve
CEO and FAA DER

How AMC/AC 20-189 Stops “Un-Accomplishment Summaries” in DO-178C or DO-254 programs

Posted on by

How Can the New AMC/AC 20-189 Help Manage Problem Reports in DO-178C and DO-254 Projects?

Your DO-178C or DO-254 Accomplishment Summary becomes a “un” accomplishment summary when too many open Problem Reports (PRs) remain unresolved at the end of a certification or TSO project. Both DO-178C (airborne software) or DO-254 (airborne electronic hardware) standards allow for a listing of open PRs in the accomplishment summary document.  However, many applicants have abused this and create long lists of unresolved and uncategorized PRs in the Software/Hardware Accomplishment Summary documents. This makes it difficult for applicants to show compliance and regulators to find compliance. The result, as one would guess, is equipment and aircraft level functional issues and airworthiness directives. 

The New AMC/AC 20-189 provides guidance on a means of compliance when applicants have unresolved (i.e., open) PRs at the end of a TC, STC or TSO project.  The reason for this is to provide a consistent expectation related to the communication, review and assessment of open PRs (OPRs) by all possible stakeholders who are integrating the software or AEH into their aircraft programs.  

AMC 20-189 was released on July 29, 2020 by EASA (and soon the FAA will release the harmonized AC 20-189). This document provides guidance on management and classification of OPRs for airborne electronic hardware, software and system development, at the time of product approval or ETSO authorization.

Background

The compliance of system, software and electronic hardware domains relies on managing PRs to ensure the product is safe at the time of approval. The problem is the existing guidance was inconsistent and unclear, especially across and between each of these domains. This new AMC provides consistent guidance on managing OPRs that works alongside existing guidance for each domain, and is harmonized between EASA and the FAA.

What AMC 20-189 Covers

This AMC provides consistent terminology to use to define Problem Report “states,” type classifications for PRs, and guidance on how to manage them to enable the consistent and timely management of PRs across domains to ensure visibility of critical issues remaining at the time of approval.

What Will this Mean for YOUR Project?

First and foremost, if you are starting or working on any airborne systems, software or hardware programs, you will need to review your configuration management procedures to see what gaps exist between those procedures and this AC/AMC.   You will then need to update your Configuration Management Plan document to ensure it aligns with this new guidance. (Don’t forget to have your certification liaison sign off on any significant changes).

The key things to keep in mind are:

  1. PR management plans and processes should span systems, software and hardware domains and be used throughout development and for continued airworthiness aspects.
  2. PRs that occur after a certification or authorization approval should be reported in a manner that is understandable to all affected stakeholders.  For example, an equipment level PR after certification authority approval (via TC, STC or TSO) may affect aircraft level functions and create a hazard if not reported and addressed. 
  3. Companies with distributed geographical organizations, especially across countries, should ensure that the tools and procedures for problem reporting are accessible (including viewing and resolution) by all affected stakeholders.
  4. Companies should strive to actively work to close problem reports throughout the development process to reduce the number of OPRs presented at the time of certification (or authorization in the case of a TSO/ETSO piece of equipment). 
  5. The PR process and configuration management plan should describe classification systems and ensure the OPR content aligns with AC/AMC20-189. This will ensure that all affected parties understand the types and seriousness of the OPRs.
  6. The PR process should review documentation of the assessment of each OPR to ensure it clearly captures functional limitations and/or operation restrictions at the equipment level or product level.
  7. Stakeholders at each level should manage OPRs (TSO, System and final product — aircraft, engine propeller).

What are Streamlining Processes?

Posted on by

This blog is a little different from my past ones. I was invited to participate in the “Streamlining Assurance Processes Workshop” (which internally we called the “Meta Objectives working group”). The idea behind this was to provide an “alternative means of compliance” to DO-254, DO-178C, and ARP 4754A, such that at all levels of development, any team on any project at any level of design could demonstrate compliance to a consistent set of development assurance objectives. (Of course, the activities associated with meeting those objectives would vary depending on the program and level of design).

After three meetings, several web meetings, online commenting and much heated discussion, the committee came up with three Overarching Properties that should be met at any/all levels of design. Each Overarching Property contains the following:

  • statement capturing the property
  • definition
  • pre-requisites
  • constraints
  • assumptions.

That’s about all I can say about it in this forum as its being officially rolled out at the upcoming FAA Streamlining Assurance Workshop (being held September 13 -15, 2016).

FAA Streamlining Assurance Processes Workshop

What follows is a recap of what was presented to introduce this topic at this workshop. For further information, please contact the author himself or the FAA.

Streamlining Framework

Peter Skaves, Chief Scientist AEH, Security FAA
Peter covered a variety of topics at a high level, foreshadowing the contents of the conference. He mentioned that “streamlining” has been a goal and theme for 20-25 years, but has a newfound focus. The FAA, working with other authorities, is trying to 1) Reduce duplicate approvals across the authorities, 2) Reduce number of audits and stages of involvement, 3) Allow meeting of “Meta Objectives” (uniting objectives for 178C, 254 and ARP 4754A), 4) Use a risk-based approach when creating new policy for SW/HW/Systems.

In terms of the “risk-based” approach, this means doing things that prevent accidents – identifying areas where there have been systematic design escapes and focusing there (potentially relaxing other areas). So they are trying to use this rationale when modifying documents and guidance material. For example, up until five years ago, the focus was on software and hardware, with little policy at the system level. There were escapes in software and hardware, but these sorts of problems would have showed themselves earlier in the systems development process. Thus the need and invocation of ARP 4754A.

He discussed different aircraft types, with potentially different criteria for each type.
One of the more interesting things he discussed was the notion of new “00” advisory circulars. These will be published to provide examples and what was previously considered “prescriptive” guidance. (These were referred to later frequently, as an example of where some info currently in Order 8110.105 may move).

He mentioned streamlining SOI audits for software (which was covered in a later session in more detail).

He also talked about two types of focus for AEH: Programmable (custom microcoded components) and COTS. He talked about the questions and challenges surrounding COTS and how/where to address these concerns.

He then spent time talking about the effort to harmonize with EASA on AC 20-152(A), which has been in the works for a while, while getting rid of Issue Papers and Orders and putting content in ACs where they belong.

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.

What are Streamlining Processes?

Posted on by

This blog is a little different from my past ones. I was invited to participate in the “Streamlining Assurance Processes Workshop” (which internally we called the “Meta Objectives working group”). The idea behind this was to provide an “alternative means of compliance” to DO-254, DO-178C, and ARP 4754A, such that at all levels of development, any team on any project at any level of design could demonstrate compliance to a consistent set of development assurance objectives. (Of course, the activities associated with meeting those objectives would vary depending on the program and level of design).

After three meetings, several web meetings, online commenting and much heated discussion, the committee came up with three Overarching Properties that should be met at any/all levels of design. Each Overarching Property contains the following:

  • statement capturing the property
  • definition
  • pre-requisites
  • constraints
  • assumptions.

That’s about all I can say about it in this forum as its being officially rolled out at the upcoming FAA Streamlining Assurance Workshop (being held September 13 -15, 2016).

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.

NOTE: See below for notes from this event, which were added after this blog was first published.

If you’d like help understanding more about how to adopt streamlining processes in your program, Patmos Engineering Services offers custom consulting to assist you with your program. We can provide a package of training, guidance and/or auditing that can assist you at every step of your program.

FAA Streamlining Assurance Processes Workshop

What follows is a recap of what was presented to introduce this topic at this workshop. For further information, please contact the author himself or the FAA.

Streamlining Framework

Peter Skaves, Chief Scientist AEH, Security FAA
Peter covered a variety of topics at a high level, foreshadowing the contents of the conference. He mentioned that “streamlining” has been a goal and theme for 20-25 years, but has a newfound focus. The FAA, working with other authorities, is trying to 1) Reduce duplicate approvals across the authorities, 2) Reduce number of audits and stages of involvement, 3) Allow meeting of “Meta Objectives” (uniting objectives for 178C, 254 and ARP 4754A), 4) Use a risk-based approach when creating new policy for SW/HW/Systems.

In terms of the “risk-based” approach, this means doing things that prevent accidents – identifying areas where there have been systematic design escapes and focusing there (potentially relaxing other areas). So they are trying to use this rationale when modifying documents and guidance material. For example, up until five years ago, the focus was on software and hardware, with little policy at the system level. There were escapes in software and hardware, but these sorts of problems would have showed themselves earlier in the systems development process. Thus the need and invocation of ARP 4754A.

He discussed different aircraft types, with potentially different criteria for each type.
One of the more interesting things he discussed was the notion of new “00” advisory circulars. These will be published to provide examples and what was previously considered “prescriptive” guidance. (These were referred to later frequently, as an example of where some info currently in Order 8110.105 may move).

He mentioned streamlining SOI audits for software (which was covered in a later session in more detail).

He also talked about two types of focus for AEH: Programmable (custom microcoded components) and COTS. He talked about the questions and challenges surrounding COTS and how/where to address these concerns.

He then spent time talking about the effort to harmonize with EASA on AC 20-152(A), which has been in the works for a while, while getting rid of Issue Papers and Orders and putting content in ACs where they belong.