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 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.

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” 178 is the serial number of the document and “B or C” represents the revision of the document.

The main focus of this document is to establish a set of guidelines in the commercial aviation industry for building safety-critical software. The aviation industry and certification authorities – such as the 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 airborne systems and equipment.

FAA (Federal Aviation Administration) and EASA (European Union Aviation Safety Agency) mandate 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 an ice-breaking question.

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.

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 

The 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.

What are the objectives of the Software Planning Process?

The software planning process has the following Objectives:

1. Software Process Activities should be defined.
2. Software Development Standards should be defined. 
3. The software Life Cycle, Environment, Methods, and 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.

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]

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.

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 

What is Design Description document?

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

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.

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 detect and report errors injected during the software development process.

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

What is the Software Configuration Management Process?

The Software Configuration Management Process shall have the following Objectives:

1. Configuration Items should be identified.
2. A 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

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]

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]

What are failure condition categories as per DO 178?

There are a total of 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 the 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 Systems (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.

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.

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

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. 

What are the verification strategies mentioned in DO-178C/ED-12C?

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

1. Review: Review ensures 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.

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

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.

2. Level B:  Software whose failure can lead to a Hazardous failure condition for the aircraft.

3. Level C: Software whose failure can lead to a Major failure condition for the aircraft.

4. Level D: Software whose failure can lead to a  Minor failure condition for the aircraft.

5. Level E: Software whose failure can lead to a No-effect failure condition for the aircraft.

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.

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

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

1. 100% MCDC

2. Source to Object code verification

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.

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.

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 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.    

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 available but at times defense may use it.

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 fall into the Control category – 1 (CC1). Meaning that these documents need to have baseline and Change Control Tracking etc. 

2. 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. fall 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.

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

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  

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 

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

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 the System Safety Assessment process.

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]   

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  

What is Dead Code?

Dead code is defined as a section of the executable code that 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 that does not 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.  

Example of Dead Code in Engine Control System Software

Imagine a software engineer working on an engine control system for an aircraft that has redundant systems for added safety. For instance, consider a piece of code in the system responsible for monitoring fuel levels from two independent sensors (primary and backup):

void monitorFuelLevels(int primarySensor, int backupSensor) {
    if (primarySensor > 0) {
        // Use the primary sensor to monitor fuel levels
        processFuelData(primarySensor);
    } else if (backupSensor > 0) {
        // Use the backup sensor if the primary sensor fails
        processFuelData(backupSensor);
    } else {
        // Dead code: this condition will never be true
        // Old logic that was used for an additional, deprecated sensor
        processFuelDataWithOldSensor();
    }
}

In this example, the processFuelDataWithOldSensor() function is dead code:

• The old sensor was physically removed from the aircraft during an upgrade.
• The logic related to this sensor remains in the software but can never be executed because there is no condition where this code would be triggered (the old sensor is not available).

Why Dead Code is a Problem in DO-178C Level A Systems?

• Unverifiable Code: Dead code can never be tested or verified during normal operation or testing, violating the strict coverage requirements (such as MC/DC – Modified Condition/Decision Coverage) required for DO-178C Level A software.
• Unnecessary Complexity: Dead code adds complexity to the system, making it harder to maintain and understand.
• Potential Safety Risks: Although dead code may seem harmless, it could introduce unforeseen behavior if reintroduced unintentionally or if future changes inadvertently affect it.

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

How to deal with Dead Code?

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

How to Remove Dead Code in Engine Control System Software?

1. Static Code Analysis:
   • Use static analysis tools (such as Polyspace, CodeSonar, or Klocwork) that are capable of identifying dead code by analyzing control flow and detecting unreachable code. These tools can detect that the processFuelDataWithOldSensor() function is never executed.
2. Code Review:
   • Conduct a manual code review involving software engineers and domain experts. In the example, they would confirm that the old sensor is no longer in use, and the condition involving processFuelDataWithOldSensor() is obsolete.
3. Test Coverage Analysis:
   • During test coverage analysis, if the tool indicates that certain code blocks (like the processFuelDataWithOldSensor() call) are never executed during testing, it indicates dead code. DO-178C Level A requires 100% coverage, so this would need to be addressed.
4. Remove the Dead Code:
   • Once the dead code is confirmed, it can be safely removed. The updated code would look like this:

void monitorFuelLevels(int primarySensor, int backupSensor) {
    if (primarySensor > 0) {
        // Use the primary sensor to monitor fuel levels
        processFuelData(primarySensor);
    } else if (backupSensor > 0) {
        // Use the backup sensor if the primary sensor fails
        processFuelData(backupSensor);
    } else {
        // Dead code: this condition will never be true
        // Old logic that was used for an additional, deprecated sensor
        // processFuelDataWithOldSensor(); // Removed Dead Code
    }
}

5. Impact Analysis and Retesting:
– Perform **impact analysis** to ensure that removing the dead code does not affect any other parts of the system.
– Conduct **regression testing** to verify that the removal of dead code does not introduce new issues.

6. Documentation Update:
– Update the **software documentation** to reflect the removal of dead code, ensuring that future engineers understand the rationale behind the change.

Importance of Dead Code Removal in DO-178C Level A Systems
For DO-178C Level A software, ensuring that there is no dead code is crucial for several reasons:

1. Compliance with Certification Requirements: Level A requires thorough verification (including achieving structural coverage) and any unreachable or dead code would prevent certification.
2. Software Integrity: Dead code complicates the validation process, making it harder to guarantee that the software behaves predictably in all scenarios.
3. Maintainability and Safety: Eliminating dead code reduces maintenance overhead and potential future risks, ensuring the flight control system is as lean and efficient as possible. By identifying and removing dead code, the software engineer helps ensure the system adheres to the rigorous safety and verification standards required by DO-178C Level A.

What is Deactivated Code?

In the context of DO-178C Level A software, which is used in aerospace systems with the highest safety criticality (where failure can lead to catastrophic consequences), deactivated code is a part of the code that is present in the source but is intentionally excluded from execution in certain configurations or conditions. This code might exist for potential future use or for alternate configurations, but in the current configuration, it is not executed.

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

1. Piece of code that is traceable to the requirement but is not used under 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 that 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 that can be enabled by the hardware pin selection; this could also be considered as Deactivated Code. 

Example of Deactivated Code in an Aerospace System

Let’s consider an example where an aircraft’s flight control system is designed to handle normal mode and emergency mode operations. The emergency mode functionality is only enabled for certain aircraft models equipped with additional sensors or hardware. For other models, this code is present but deactivated.

Here is an example of deactivated code using a preprocessor directive:

void flightControl() {
    controlNormalFlight();

    #ifdef EMERGENCY_MODE_ENABLED
        // Deactivated code: Only included if emergency mode is enabled for this aircraft
        handleEmergencyMode();
    #endif

    monitorFlightStatus();
}

In this example:

• handleEmergencyMode() is only compiled and included in the final software if the EMERGENCY_MODE_ENABLED flag is defined (for aircraft with emergency mode capability).
• If this flag is not defined, the emergency mode code is deactivated and not included in the executable.

However, the following 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

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.

Handling Deactivated Code with Respect to DO-178C

In DO-178C Level A systems, deactivated code must be handled with strict discipline to ensure that it does not introduce any risk to the software, especially given the high safety criticality of the system.

1. Documentation and Traceability

• Document the Deactivation: The existence and rationale for deactivated code must be clearly documented in both the requirements and design documents. The documentation should specify:
  • Why the code is deactivated (e.g., certain features only available on specific hardware configurations).
  • Under what conditions it would be activated (e.g., specific aircraft models or configurations).
  • How the deactivation is controlled (e.g., using a configuration flag like EMERGENCY_MODE_ENABLED).
• Traceability: Ensure traceability of the deactivated code back to system requirements. Even if it’s not active in the current build, it must be traceable to ensure that if it is activated in the future, it can be verified and certified appropriately.

2. Testing and Verification

• Full Testing in Active Configurations: In configurations where the deactivated code is active (e.g., EMERGENCY_MODE_ENABLED is defined), this code must undergo full testing and verification according to DO-178C Level A requirements. This includes:
  • Functional testing to ensure the code behaves as expected.
  • Structural coverage analysis to ensure that all code paths are exercised, including achieving Modified Condition/Decision Coverage (MC/DC).
• Test Deactivation Mechanism: The mechanism used to deactivate the code (such as preprocessor directives or configuration flags) should be verified to ensure that the code is correctly excluded in configurations where it is not needed.
• Exclusion in Inactive Configurations: When the code is deactivated, it should not be tested or included in the structural coverage analysis for that configuration. However, it should be confirmed that the deactivation does not interfere with the rest of the system.

3. Structural Coverage Analysis

• MC/DC Requirements: For Level A software, MC/DC coverage must be achieved for all active code. If the deactivated code is part of a specific configuration, full MC/DC must be achieved in that configuration. In configurations where the code is deactivated, it should not be counted towards the coverage.
• Handle Coverage Gaps: Ensure that the deactivated code does not introduce any gaps in coverage. Coverage analysis must demonstrate that no unintended code (such as the deactivated portions) is executed in the final build.

4. Configuration Management

• Control via Configuration Flags: The deactivation and activation of the code should be controlled via a well-documented configuration management system. For instance, the EMERGENCY_MODE_ENABLED flag must be part of the configuration files that determine which version of the software is built.
• Ensure Correct Builds: Ensure that only the appropriate version of the software, with or without the deactivated code, is installed on the corresponding aircraft model. For example, aircraft without the emergency mode functionality should never have the emergency mode code enabled.
• Version Control: Each build configuration should be uniquely versioned and clearly distinguishable so that there’s no confusion about whether deactivated code is present in a particular version of the software.

5. Impact Analysis

• Change Impact Analysis: If modifications are made to the deactivated code (e.g., updating the handleEmergencyMode() function), an impact analysis must be conducted to ensure that the changes do not affect other parts of the system. This includes verifying that the deactivated code cannot be accidentally activated in builds where it should not be.
• Safety Assessment: Assess whether the presence of deactivated code might have any unintended effects on the safety-critical functions. Even though the code is not executed, it must be confirmed that its presence does not compromise system integrity.

6. Obsolescence and Code Removal

• Remove Deactivated Code When Obsolete: If the deactivated code is no longer needed (e.g., if the emergency mode feature is phased out entirely), it is advisable to remove the code. Keeping unnecessary deactivated code increases the complexity of the system and introduces risks of inadvertent activation.
• Simplification: Removing deactivated code once it is no longer needed simplifies the codebase and reduces the likelihood of future maintenance errors.

7. Certification Evidence

• Provide Certification Evidence: For DO-178C Level A certification, the software engineer must provide evidence that deactivated code is properly managed. This includes:
  • Documentation showing where and why the code is deactivated.
  • Testing evidence showing that the deactivated code is properly tested in configurations where it is active, and that it is excluded in configurations where it is deactivated.
  • Coverage analysis demonstrating full MC/DC for active code and proper exclusion of deactivated code from the analysis.

Example of Handling Deactivated Code

Let’s say the flight control system initially includes both normal and emergency mode functionality. Over time, the emergency mode feature is phased out in newer aircraft models. Here’s how you would handle this:

1. Initial Phase: Code Deactivation
   • Initially, the emergency mode code is present but deactivated for newer aircraft models.
   • This deactivation is controlled by a configuration flag EMERGENCY_MODE_ENABLED.
2. Code Removal
   • Once all aircraft models using the emergency mode feature are retired, the emergency mode code is no longer needed.
   • The engineer removes the deactivated emergency mode code from the codebase to simplify the software and reduce future maintenance risks.

Before Removal –

void flightControl() {
    controlNormalFlight();

    #ifdef EMERGENCY_MODE_ENABLED
        handleEmergencyMode();
    #endif

    monitorFlightStatus();
}

After Removal –

void flightControl() {
    controlNormalFlight();
    monitorFlightStatus();
}

Summary: Handling Deactivated Code in DO-178C Level A Software

1. Document the Deactivated Code: Clearly document the existence, rationale, and control mechanism for deactivated code.
2. Verify Active and Inactive Configurations: Fully test and verify deactivated code when active, and ensure it is properly excluded when inactive.
3. Perform Structural Coverage Analysis: Ensure full MC/DC for active code and proper exclusion for deactivated code.
4. Use Configuration Management: Control the inclusion and exclusion of deactivated code via robust configuration management.
5. Conduct Impact Analysis: Ensure changes to deactivated code do not impact safety-critical functionality.
6. Remove Obsolete Code: Consider removing deactivated code once it is no longer needed.
7. Provide Certification Evidence: Supply appropriate documentation and testing evidence to demonstrate that deactivated code is managed in accordance with DO-178C guidelines.

By following these guidelines, deactivated code can be properly managed in aerospace systems, ensuring compliance with DO-178C Level A and maintaining the safety and integrity of the software.

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 technology, most of 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 Question for both freshers and experienced professionals.

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.

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.” 

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.

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

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 common errors.

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 are used to decide if a process can be entered. We must satisfy the established transition criteria to enter into a process.

What is the Robustness Test Case?

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

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

What is the Fault Tolerance?

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

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 the 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, the ED-12B/C document is followed. However, both documents are equivalent and serve the same purpose and have the same objectives and process guidelines.

What is Requirement Traceability?

DO-178*/ED-12* suggests having bi-directional traceability. Therefore, requirement traceability should be performed in both the approach – Top-Down approach and the Bottom-Up approach.  Also, requirement traceability could be a 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 the 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.

What are the major certification risks that most organizations 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 produces 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 packages with incomplete plans and insufficient documents

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.

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

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

What is DO178C/ED-12C added cost?

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

What are the Process Outputs data?

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

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

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 one 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, and 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! If you like this article so far, please consider buying me a coffee.

Good luck with your interview.