50+ Top DO178C Interview Questions

50+ Top DO178C Interview Questions

If you are looking for the DO178C interview questions / DO-178B interview questions for an upcoming job interview, you have landed at the right place.

In this article, I have tried to compile the top DO178C interview questions / DO-178B interview questions that are constantly being asked in most of the aerospace companies for entry-level and experienced level software engineer positions. I have spent many hours compiling these Top DO178C interview questions / Top DO-178B interview questions.

So, I hope you will enjoy these DO178C interview questions or DO-178B interview questions and maybe learn something new. This list could be helpful for both fresher and experienced professionals.

After reading the complete article if you think that I have missed any commonly asked DO178C interview questions/ DO-178B interview Questions, please write in the comment box. It will be definitely helpful for others.

Also, if you think this article helped you in preparing the DO178C interview / DO-178B interview and you got your dream job, please share your story in the comment box below. Your story could inspire others.

All the best for your DO178C or DO178B interview.

Q1) What is DO-178C?  What is DO-178B?  What is DO178B? What is DO178C? What is DO/178? What is DO178?

DO178B/C is a guideline document for the aviation community, especially for software development and verification. The actual title for the DO178C is: Software Considerations in Airborne Systems and Equipment Certification. The “DO” stands for “Document” and 178 is the serial number of the document and “B or C” represents the revision of the document.

This main focus of this document is to establish a set of guidelines in the commercial aviation industry for building the safety-critical software. The aviation industry and certification authorities – such as Federal Aviation Administration (FAA), European Aviation Safety Agency (EASA), Transport Canada, Japan Civil Aviation Bureau (JCAB), Civil Aviation Authority (CAA) etc) have been using this document since 1992 to approve the software for airborne systems.

It was prepared by RTCA Inc. (Radio Technical Commission for Aeronautics) to support the complete software lifecycle process for the airborne systems and equipment.

FAA (Federal Aviation Administration) and EASA (European Union Aviation Safety Agency) mandates to meet the DO178 objectives before installing the software on any commercial aircraft.

Similarly, there is DO-254 for certifying complex electronic hardware.

Pro Tip: Another DO178C Interview Questions. This is considered to be a ice-breaking question.

Q2) DO-178C is a standard or guideline?

DO-178C/ED-12C is a guideline document for the civil aviation software community. Technically, it’s not a standard. 

However, even though the DO-178*/ED-12* was written as a guideline document focused on software development of aviation software, it became the informal standard within the aviation industry.

Q3) What is the Software Life Cycle Process?

The software Life Cycle Process consists of the following elements:

  1. Software Planning Process
  2. Software Development Process
    1. Software Requirements Process
    2. Software Design Process
    3. Software Coding Process
    4. Integration Process
  3. Integral Process
    1. Software Verification Process
    2. Software Configuration Management Process
    3. Software Quality Assurance Process
    4. Certification Liaison Process 

Software development process is responsible for producing the software product and the Integral process is responsible for correctness and other aspects of the software product.

Each process will have certain objectives and a set of activities to perform to satisfy those objectives. The process will also have entry criteria or transition criteria.

Q4) What are the objectives of the Software Planning Process?

The software planning process is having the following Objectives:

  1. Software Process Activities should be defined.
  2. Software Development Standards should be defined. 
  3. Software Life Cycle, Environment, Methods, Tools should be finalized.
  4. Software Life Cycle Process transition criteria and feedback mechanism should be established.
  5. All the objectives mentioned in DO-178C Guidelines, Table A-1 should be satisfied for the particular software level.

Q5) What are the outputs of the Software Planning Process?

The Software Planning Process shall have the following Outputs/Deliverables:

  1. Plan for Software Aspects of Certification [PSAC]
  2. Software Development Plan [SDP]
  3. Software Verification Plan [SVP]
  4. Software Quality Assurance Plan [SQAP]
  5. Software Configuration Management Plan [SCMP]
  6. Software Requirements Standard [SRS]
  7. Software Design Standard [SDS]
  8. Software Coding Standard [SCS]

Q6) What are the objectives of the software Development Process?

The Software Development Process shall have the following Objectives:

  1. Software High-Level Requirements should be produced.
  2. Software Architecture and Low Level requirements should be developed.
  3. Software Source Code and executable object code should be developed.
  4. All the objectives mentioned in DO-178C Guidelines, Table A-2 should be satisfied for the particular software level.

Q7) What are the outputs of the Software Development Process?

The Software Development Process shall have the following Outputs/Deliverables:

  1. Software Requirements Data
  2. Trace Data
  3. Design Description
  4. Source Code
  5. Parameter Data Item File
  6. Executable Object Code 

Q8) What is Design Description document?

Design Description includes the software architecture and software low-level requirements.

Q9) What is Trace Data?

Trace Data includes the following bi-directional association between:

  1. System Requirements and  Software High Level Requirements
  2. Software High Level requirements and Software Low Level Requirements
  3.  Software Low Level Requirements and Source Code.

Q10) What are the objectives of the software Verification Process? 

The Software Verification Process shall have the following Objectives:

  1. Verification High Level Requirements are correctly developed 
  2. Verification of Software Architecture and Low-Level requirements are correct and compliant to standards.
  3. Verification of Source Code and Integration with target Computer
  4. Verification of Test Cases and Procedures are correct

The Software Verification Process helps to detect and report the errors that were injected during the software development process.

Q11) What are the outputs of the software Verification Process?

The Software Verification Process shall have the following Outputs/Deliverables:

  1. Software Verification Cases and Procedures
  2. Software Verification results
  3. Trace Data

Q12) What is the Software Configuration Management Process?

The Software Configuration Management Process shall have the following Objectives:

  1. Configuration Items should be identified.
  2. Change Control Management System should be established.
  3. All the objectives mentioned in DO-178C Guidelines, Table A-8 should be satisfied for the particular software level.

The Software Configuration Management Process shall have the following Outputs/Deliverables:

  1. SCM Records
  2. Problem Reports
  3. Software Configuration Index
  4. Software Life Cycle Environment Configuration Index

Q13) What is software Quality Assurance Process?

The Software Quality Assurance Process shall have the following Objectives:

  1. Software Life Cycle Compliance with the Plans and standards.
  2. Transition Criteria for Software Life Cycle Processes are achieved.
  3. Software Conformity Review should be conducted and completed.
  4. All the objectives mentioned in DO-178C Guidelines, Table A-9 should be satisfied for the particular software level.

The Software Quality Assurance Process shall have the following Outputs/Deliverables:

  1. Software Quality Assurance records [SQA Records]

Q14) What is the Certification Liaison Process?

The Certification Liaison Process shall have the following Objectives:

  1. Establish a well communicated understanding between the applicant and the certification authority (For example, FAA or EASA).
  2. All the objectives mentioned in DO-178C Guidelines, Table A-10 should be satisfied for the particular software level.

The Certification Liaison Process shall have the following Outputs/Deliverables:

  1. Plan for Software Aspects of certification [PSAC]         
  2. Software Accomplishment Summary [SAS]
  3. Software Configuration Index [SCI]

Q15) What are failure condition categories as per DO 178?

There are a total five failure conditions identified by DO 178B/C document:

  1. Catastrophic: Catastrophic failure condition which indicates the loss of life and aircraft. Example – Engine Control Software, Flight Control Software (FCS) etc.

2. Hazardous: Hazardous condition indicates a small number of fatal injuries and increased workload to flight crew. Example – Cabin Air Pressurization Control Software, Primary Flight Display (PFD) Software etc.

3. Major: Failure condition which would reduce the functional Capabilities of the aircraft and increased workload of the flight crew and comfort level of passengers. Example – Cargo Air Conditioning System (CACS).

4. Minor: A little increase in crew workload but manageable and discomfort to the passengers. Example – Flight Entertainment System (FES), Transponders and Communication System Software etc.

5. No Effect: No effect at all on the operation of the aircraft. Example – Satellite Phones, Vending Machine etc.  

Note: This is One of the common DO178C Interview Questions.

Q16) What are the Software Levels mentioned in DO178?

There are five different software levels mentioned in the DO-178B/C document:

  1. Level-A Software
  2. Level-B Software
  3. Level-C Software
  4. Level-D Software
  5. Level-E Software

The software level is determined by the nature of the aircraft level failure triggered by the software error.

DO178C Failure Conditions and Software Levels
DO178C Failure Conditions and Software Levels

Note: This is One of the common DO178C Interview Questions.

Q17) Does DO-178C/ED-12C assure full safety?

No, It does not assure full safety. In fact, it’s a guideline document and does not really deal with safety. 

Q18) What is the verification strategies mentioned in DO-178C/ED-12C?

Verification is very important part of the DO-178*/ED-12* document. Verification is defined as a combination of the following methods:

  1. Review: Review ensures the qualitative correctness.
  2. Analysis: Analysis ensures evidence of correctness.
  3. Testing: Testing ensures that the software satisfies the High level and low level requirements and also gives us a sense of confidence.

Q19) Can you explain the relationship between the Software Levels and failure conditions?

A software failure can lead to various types of failure conditions at the aircraft level.  

For example, if a particular software (Flight Control System Software or Engine Control System Software) failure leads to a catastrophic failure (or loss of the airplane) at the aircraft level, then we say that the particular software is Level-A software. 

  1. Level A: Software whose failure can lead to a Catastrophic Failure condition for the aircraft.
  1. Level B:  Software whose failure can lead to a Hazardous failure condition for the aircraft.
  1. Level C: Software whose failure can lead to a Major  failure condition for the aircraft.
  1. Level D: Software whose failure can lead to a  Minor  failure condition for the aircraft.
  1. Level E: Software whose failure can lead to a No-effect failure condition for the aircraft.

Q20) Who defines the Software Level?

The software levels are determined by the nature of the aircraft level failure introduced by the software error. 

The System Safety Assessment team in the organization is mainly responsible to determine the software level.

For example, if the System Safety Assessment Process finds that a particular software error could lead to a catastrophic failure condition, then they will declare that particular software as Level-A software. 

Note: This is One of the common DO178C Interview Questions.

Q21) What is the major difference between Level A and Level B software?

Level-A software is required to satisfy the following objectives, where as Level-B softwares do not require to achieve these:

1. 100% MCDC

2. Source to Object code verification

Q22) Can you explain the structural coverage objective for each software level?

There are five different software levels mentioned in DO-178B/C. Each software level is required to cover a certain type of structural coverage.

  1. Level A: Modified Condition Decision Coverage (MC/DC) + Level B.
  2. Level B: Decision Coverage +  Level C.
  3. Level C: Only Statement Coverage is required.
  4. Levels D: Not needed.
  5. Levels E: Not needed.
  6. Levels A-C: Data and Control Coupling is required.

Q23) What is Test Coverage Analysis?

Test Coverage Analysis consists of two different processes:

  1. Requirement-Based Coverage Analysis
  2. Structural Coverage Analysis

Requirement-Based Coverage Analysis ensures that the requirement-based test cases cover all the requirements.

Q24) What is Structural coverage analysis and why is it performed?

Structural Coverage Analysis helps to reveal the code structure that was not exercised by the based on requirement-based test procedure execution.

This is a very important activity since the uncovered code could add additional unintended functionality which could eventually affect the safety margin of the system.

If any gap is found during structural coverage analysis, additional activities need to be performed for a particular software level.

  1. Gap in Requirements-Based Tests: Augment additional test cases.
  2. Inadequate Software Requirements: Modify requirement and Test cases.
  3. Extraneous Code: Fix software code.
  4. Dead code: Remove dead code.
  5. Deactivated code: Perform an analysis/testing to prove that the deactivated code will not execute accidentally and will not affect the normal execution of the software.    

Q25) Is DO-178B/C applicable for both Civil and Military aircraft software?

The DO-178B/C guideline is applicable only for commercial/civil aircraft. There are separate military standards are available but and at times defence may use it.

 Q26) What are CC1 and CC2?

There are two different Configuration Management Control Categories defined in DO-178B/C document:

  1. CC1: Control Category – 1 (CC1) must satisfy the SCM process activities that are mentioned in the “Table 7-1” in the DO-178B/C document. For example, CC1 must satisfy Baseline, Traceability, Problem Reporting, Change Control Tracking, Change Review, Data Retention etc. For example,  PSAC, SDP, SVP, SQAP, SCMP, SRS, Source Code etc falls into the Control category – 1 (CC1). Meaning that these documents need to have baseline and Change Control Tracking etc. 
  1. CC2: Control Category – 2 (CC2) must satisfy the reduced set of SCM process activities that are mentioned in the “Table 7-1” in the DO-178B/C document. CC2 must satisfy Traceability, Change Control, etc. CC2 does not require to have the capability of Baselines, Problem Reporting etc. For example, Minutes of Meeting, SCM Records, SQA Records etc. falls under the Control Category 2 (CC2).

Following the correct Control Category is very important from the certification standpoint. If you maintain CC2 artefacts as CC1, you are overdoing and burning out the budget unnecessarily. But, if you are considering CC1 artefacts as CC2, then you are not following the process and definitely there would be certification issues at a later point of time.

Q27) Can you explain the Software Requirement process?

Objectives:

  1. Developing High Level requirements.
  2. Defining Derived High Level requirements.

Inputs:

  1. System Requirements
  2. Safety Requirements
  3. System Architecture
  4. Hardware Interface
  5. Software Development Plan [SDP]
  6. Software Requirement Standard

Outputs:

  1. Software Requirements Specifications [SRS]
  2. Establishment of traceability to System Requirements

Q28) What is the Software Design Process?

Objectives:

  1. Developing Software Architecture 
  2. Developing Software Low-Level Requirements
  3. Defining derived low-level requirements

Inputs:

  1. Software Requirement Specification [SRS]
  2. Software Development Plan [SDP]
  3. Software Design Standard [SDS]

Outputs:

  1. Design Description
  2. Trace Data  

Q29) What is the Software Coding Process?

Objective:

  1. Developing Source Code.

Inputs:

  1. Software Development Plan [SDP]
  2. Software Architecture
  3. Software Low-level requirement
  4. Software Coding standards

Outputs:

  1. Source Code 

Q30) What is the Integration Process?

Objective:

  1. Creating executable Object Code

Inputs:

  1. Source Code 
  2. Software Architecture

Outputs:

  1. Object Code
  2. Executable Object Code
  3. Parameter Data Item File
  4. Compiling, Linking, and Loading Data

Q31) What is Derived Requirement?

Normally the high-level requirements are broken down into low-level software requirements. But, sometimes, software engineers need to write low-level requirements which are not traceable to the high-level requirements. These kinds of requirements are called Derived requirements. 

As per Do-178C, the derived requirements are needed to send as feedback to the system process as well as System Safety Assessment process.

Q32) Can you name all the Planning Documents?

  1. Plan for Software Aspects of Certification [PSAC]
  2. Software Development Plan [SDP]
  3. Software Verification Plan [SVP]
  4. Software Configuration Management Plan [SCMP]
  5. Software Quality Assurance Plan [SQAP]   

Q33) What is SOI?

SOI stands for “Stages of Involvement”. There are four steps for an SOI audit:

  1. SOI – 1: Software Planning review
  2. SOI – 2: Software Development review
  3. SOI – 3: Software Verification review
  4. SOI – 4: Final Certification review  

Q34) What is Dead Code?

Dead code is defined as a section of the executable code which cannot be executed at all in any operational condition in the target computer. 

As per DO-178*/ED-12*, we must remove the dead code. Dead code cannot be traced to any software requirements and hence dead code does not contribute to any required functionality. 

Sometimes, there could be a library function definition in the software which does get invoked at all. If the compiler is smart enough and does not include that particular function in the executable code, we cannot say it is dead code.

Therefore, unused library functions cannot be considered as Dead Code.  

Note: This is One of the popular DO178C Interview Questions for both freshers and experienced professionals.

Q35) How to deal with Dead Code?

Dead Code can be discovered as part of the Structural Coverage Analysis. If the dead code is found in the airborne software, it must be removed. 

Q36) What is Deactivated Code?

As per DO-178C, there could be two types of deactivated code:

  1. Piece of code which is traceable to the requirement but is not used under the any configuration
  2. Piece of code which is traceable to the requirements and only meant for the execution under a particular configuration

For example, there could be a set of code which is intended to be used in the future version of the software for maintenance and not being used in the current configuration. Then, we can consider such a code as Deactivated Code. Also, there could be software modules which can be enabled by the hardware pin selection; this could also be considered as Deactivated Code. 

However, the followings are mistaken as Deactivated Code, but they are actually not:

  1. Defensive Code Structure inserted for robustness
  2. Compiler inserted code for range and array index checks
  3. Error or exception handling routines
  4. Code for Bound checking

Q37) How to deal with Deactivated Code?

Deactivated Code could be found as part of the Structural Coverage Analysis. An analysis/testing needs to be performed to prove that the deactivated code will not execute accidentally and will not affect the normal execution of the software.

Q38) What is MCDC or MC/DC?

MCDC or MC/DC stands for: Modified Condition and Decision Coverage. As per DO-178C/ED-12C document, the definition of MC/DC is:

Every point of entry and exit in the program has been invoked at least once, every condition in a decision in the program has taken on all possible outcomes at least once, every decision in the program has taken on all possible outcomes at least once, and each condition in a decision has been shown to affect that decision’s outcome. A condition is shown to independently affect a decision’s outcome independently by:

1. Varying just that condition while holding fixed all other possible conditions. Or,

2. Varying just that condition while holding fixed all other possible conditions that could affect the outcome.

With the advancement of the technology, most of the aviation organization uses the MC/DC tool to identify the MC/DC scenarios and provide the report of the coverage. As per DO-178*/ED-12*, the Level-A software must satisfy the 100% MC/DC coverage objective. The 100% MC/DC coverage is only applicable for Level-A software; this is not required for Level-B to Level-E software.

Pro Tip: Another common DO178C Interview Questions for both freshers and experienced professionals.

Q39) Can you explain DO-178 Tool Qualification?

There could be scenarios when we eliminate certain manual processes and automate the process by a particular tool. Such tools need to be qualified to gain confidence in the output of the tool.

There are five different Tool Qualification Levels (TQL) such as TQL-1, TQL-2, TQL-3, TQL-4, and TQL-5, where TQL-1 is the most critical.

Q40) What Is Data Coupling and Control Coupling?

Coupling can be identified as a degree of interdependence among different software components. 

Data Coupling:  As per DO-178C document, the definition of data coupling is: 

“The dependence of a software component on data not exclusively under the control of that software component.”

Control Coupling:  As per DO-178C document, the definition of control coupling is:

“The manner or degree by which one software component influences the execution of another software component.” 

Q41) What is “Independence” in DO-178B or DO-178C?

As per Do-178B/C, Independence is required during the software verification process, meaning that an independent person is required to perform the verification activity. The software developer who has developed the source code cannot perform the verification. 

The tables at the end of the DO-178* document mentions about which activity needs to be done with Independence for a particular software Level. 

The Independence matrix could be maintained manually or by an automated tool.

DO178C Objectives

Pro Tip: This is another common DO178C Interview Questions for both freshers and experienced professionals.

Q42) What is Multiple Version Dissimilar Software? What is the N-version programming technique?

Multiple-Version dissimilar software designing is a popular technique used for safety-critical civil aviation software. This is also called the N-Version programming technique. 

This technique allows two or N number of software instances to provide the same operational output. This helps us to avoid the common errors.

Q43) Can you explain Transition Criteria?

Each software life cycle process performs activities on Inputs and produces Outputs to meet the objective of that particular software level. Transition Criteria is used to decide if a process can be entered. We must satisfy the established transition criteria to enter into a process.

Q44) What is the Robustness Test Case?

Normal range test cases are responsible to exercise the normal operational function of the software based on the requirement. But, Robustness test cases are helpful in showing how the software behaves under the abnormal conditions and extreme/invalid inputs.

For example, test cases which exercise the out-of-range values for a for-loop could be considered as a robustness test case.

Q45) What is the Fault Tolerance?

Fault Tolerance system allows the system to continue its execution and provide correct output even after a limited number of software/hardware failures.

Q46) What is ED-12B?  What is ED-12B?  What is ED12B? What is ED12C? What is ED/12? What is ED12?

ED-12B is equivalent to DO178B for European aviation industry. ED-12B was published by EUROCAE back in 1992. Similarly, ED-12C is equivalent to the DO178C document.

Normally, the aviation project in the USA follows the Do178B/C whereas in Europe, ED-12B/C document is followed. However, both the documents are equivalent and serve the same purpose and have the same objectives and process guidelines.

Q47) What is Requirement Traceability?

DO-178*/ED-12* suggests to have the bi-directional traceability. Therefore, requirement traceability should be performed in both the approach – Top-Down approach and Bottom-Up approach.  Also, requirement traceability could be one-to-many or many-to-one relationship.

The Top-Down requirement traceability ensures that the requirements are traced to design and then to code and also requirement to test. This ensures that all the requirements have the corresponding design, code and test cases and procedures.

On the other hand, the Bottom-Up requirement traceability (code to Design, Design to Requirements, Test to Requirements) ensures that the code, design, and tests are important and necessary to have in place to implement and verify the requirements. 

Pro Tip: Many companies ask this question in the DO178C Interview Questions for both freshers and experienced professionals.

Q48) What are the major certification risks that most of the organization could face?

There are several certification risks that any aviation organization could face:

  1. Missing Traceability or Incomplete Traceability or Incorrect Trace Data
  2. Incorrect Traceability
  3. Missing Independence during verification
  4. Not following the Transition Criteria for Inter-Process transition
  5. Low-quality RBT which produce a very low level of initial structural coverage
  6. Inadequate review checklist
  7. Missing Tool Qualification
  8. Delaying SOI audits could add further cost 
  9. Outsourcing work package with incomplete plans and insufficient documents

Q49) Can you apply DO-178C reverse engineering?

Well, in most cases, aviation organizations apply DO-178C/ED-12C for newly developed software and follow the prescribed guidelines and meet the objectives. However, there are cases when companies get the COTS (Commercial-Off-The-Self) software or previously developed software and apply DO-178C/ED-12C reverse engineering to certify the product.

Q50) Does DO-178*/ED-12C prescribe any particular software language?

Well, DO-178*/ED-12* do talk about the code consistency, robustness, defensive coding, determinism, safe execution. However, most of the avionics software is developed in C, C++, and ADA. The ADA language is mostly used in the defence project. For the civil aviation projects, C and C++ programming languages are mostly used due to their wider recognition and the well-developed tools.

Q51) What is DO178C/ED-12C added cost?

Following the DO-178C/ED-12C definitely adds up extra cost to the project. Based on the industry survey, by and large, there could be 50-350% of additional cost to follow the DO-178C guidelines and meet the DO-178C objectives. 

Q52) What are the Process Outputs data?

DO178C Process Output Data - 1
DO178C Process Output Data – 1
DO178C Process Output Data - 2
DO178C Process Output Data – 2

Q53) Can you explain the complete Software Life Cycle in DO 178C?

Here is the software life cycle mentioned in DO 178C:

DO 178C Software Life Cycle
DO 178C Software Life Cycle

Pro Tip: Many companies ask this question in the DO178C Interview Questions for both freshers and experienced professionals.

Conclusion:

DO178B or DO178C is a very important guideline document for any software that is being developed for civil aircraft. I have tried to cover most of the DO-178B or DO178C interview questions / DO-178B interview questions that you can face during the interview.

However, there could be areas that I have missed to cover. Please feel free to comment below, if you think anything else could be added here in the context of DO178C interview questions / DO-178B interview questions.

I have also compiled all the DO178C tables in once document along with the explanation and created a pdf copy of it.

If you want to get the FREE pdf copy, please comment your email ID in the below comment box, I will send you the copy. This document would definitely give you a far better understanding of the DO178C objectives.

Hopefully, this article could help you!

Good luck with your interview.

Cheers!

50+ DO178C Interview Questions | DO178C Standards

14 thoughts on “50+ DO178C Interview Questions | DO178C Standards

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top
error: