In the world of aerospace engineering, safety and reliability are paramount concerns. That is why the Federal Aviation Administration (FAA) developed DO 178C, a set of guidelines for the development of software used in airborne systems. This article will explore the history, purpose, and key differences between DO 178B and DO 178C, as well as the software levels and development process of DO 178C.
DO 178C is the latest version of the software guidelines for airborne systems. It provides a standard set of practices for the development, verification, and validation of software used in airborne systems. It is intended to ensure the safety and reliability of software-based systems used in critical flight operations. Understanding the history, purpose, and software development process of DO 178C is key to creating software that meets these standards.
The first version of DO 178 was published by the FAA in 1985. It was created in response to the growing use of software in airborne systems, primarily in commercial aircraft. The guidelines were established to ensure that software-based systems used in critical flight operations were safe and reliable. In 1992, DO 178B was released, which expanded and more clearly defined the guidelines established in the first version. DO 178C was published in 2011, and it reflects the advancements in software development and testing that have occurred in the intervening years.
Over the years, the aviation industry has seen significant changes in technology, aircraft design, and air traffic control systems. These changes have led to an increased reliance on software-based systems for critical flight operations. As a result, the need for updated software guidelines became apparent. DO 178C was developed to meet this need and provide a more comprehensive set of guidelines for the development, verification, and validation of software used in airborne systems.
The primary purpose of DO 178C is to provide guidelines for the development, verification, and validation of software used in airborne systems. These guidelines were created to ensure that software-based systems used in critical flight operations are safe and reliable. DO 178C applies to all software that is part of an airborne system, including software that is used in flight-critical situations.
The scope of DO 178C is broad and covers all aspects of software development, verification, and validation. It provides guidance on software planning, requirements, design, coding, integration, testing, and configuration management. It also includes guidance on the use of tools and techniques for software development and testing.
DO 178C is an updated and more comprehensive version of DO 178B. One of the key differences between the two versions is the addition of guidance on the use of Model-Based Development (MBD) and Object-Oriented Technology (OOT) in software development. This guidance recognizes the increasing use of these technologies in the aviation industry and provides guidance on how to use them effectively in the development of software for airborne systems.
Another difference between DO 178B and DO 178C is the inclusion of a risk-based approach to the planning and execution of software verification and validation activities. This approach recognizes that not all software functions are equally critical and that the level of testing required should be based on the level of risk associated with each function. This approach allows for a more efficient use of resources and ensures that the most critical functions receive the highest level of testing.
In conclusion, DO 178C is an essential set of guidelines for the development, verification, and validation of software used in airborne systems. Understanding the history, purpose, and software development process of DO 178C is crucial for software developers and engineers working in the aviation industry. By following these guidelines, software-based systems used in critical flight operations can be developed, tested, and validated to ensure their safety and reliability.
The DO 178C software levels are used to determine the level of rigor required for the development and testing of software used in airborne systems. These levels are based on the potential impact of a software failure on the safety of the aircraft and its occupants.
Level A software involves functions that, if they fail, would result in a catastrophic failure of the aircraft. Examples of these functions include flight controls, automatic landing systems, and collision avoidance systems. These systems are critical to the safe operation of the aircraft and any failure could result in loss of life or the complete destruction of the aircraft.
Developing and testing Level A software requires the highest level of rigor and is subject to the most stringent requirements. This includes extensive testing, verification, and validation to ensure that the software is reliable and free from errors that could result in catastrophic failure.
Level B software involves functions that, if they fail, could result in a hazardous or severe failure of the aircraft. Examples of these functions include engine thrust management and fuel management systems. While these failures may not be catastrophic, they could still result in serious injury or damage to the aircraft.
Developing and testing Level B software also requires a high level of rigor, but not as extensive as Level A. This includes testing and verification to ensure that the software is reliable and free from errors that could result in hazardous failure.
Level C software involves functions that, if they fail, could result in a major failure of the aircraft. Examples of these functions include flight planning software and altitude measurement systems. While these failures may not be as severe as Level A or Level B, they could still result in significant damage to the aircraft and potential injury to its occupants.
Developing and testing Level C software requires a moderate level of rigor, including testing and verification to ensure that the software is reliable and free from errors that could result in major failure.
Level D software involves functions that, if they fail, could result in a minor failure of the aircraft. Examples of these functions include entertainment systems and cabin lighting. While these failures may not impact the safety of the aircraft, they could still result in inconvenience to the passengers.
Developing and testing Level D software requires a lower level of rigor, including testing and verification to ensure that the software is reliable and free from errors that could result in minor failure.
Level E software involves functions that, if they fail, would have no effect on the safe operation of the aircraft. Examples of these functions include non-critical annunciators and status displays. While these failures may not impact the safety or operation of the aircraft, they could still result in confusion or inconvenience to the flight crew.
Developing and testing Level E software requires the lowest level of rigor, including testing and verification to ensure that the software is reliable and free from errors that could result in confusion or inconvenience.
The first step in the DO 178C software development process is planning and defining the project's requirements. This is a critical step, as it lays the foundation for the entire software development process. During this phase, the development team identifies the software's functions, its operational environment, and any constraints that may impact its development. The software development plan must be aligned with the guidelines set forth in DO 178C to ensure that the software meets the required standards.
Planning and requirements gathering involve a lot of communication and collaboration between the development team and stakeholders. This is because it's essential to understand the needs of the end-users and the environment in which the software will operate. By gathering all the requirements upfront, it ensures that the software development process is efficient and effective.
Once the requirements have been defined, the software design and implementation process can begin. During this phase, the software architecture is designed, and the code is written. The software must be designed and implemented according to the guidelines set forth in DO 178C. Code must be well-structured, readable, and maintainable. It must also be traceable back to the requirements.
The design and implementation phase is where the software development team brings the requirements to life. The software architecture is designed to ensure that it meets all the requirements, is scalable, and is maintainable. The code is then written according to the design, and it's essential to ensure that the code is well-structured, readable, and maintainable. This is because it will make it easier to maintain the software in the future.
Verification and validation activities are essential to ensuring that DO 178C guidelines have been followed correctly during the software development process. Verification activities include code reviews, static analysis, and module testing, while validation activities include integration testing and system testing. Once testing is complete, the software is ready for certification.
The verification and validation phase is where the software development team ensures that the software meets all the requirements and is free of defects. This is achieved through various testing activities, including code reviews, static analysis, module testing, integration testing, and system testing. It's essential to ensure that all the testing activities are thorough, as any defects found during the testing phase can be costly to fix later.
Configuration management is an important element of DO 178C. It involves managing and controlling changes to software throughout its development life cycle. This includes version control, change control, and revision control, as well as the management of baselines and releases.
Configuration management is essential to ensure that the software development process is efficient and effective. It involves managing and controlling changes to the software throughout its development life cycle, ensuring that all changes are documented and tracked. This is important because it allows the development team to manage changes effectively and ensure that the software remains compliant with DO 178C guidelines.
The final step in the DO 178C software development process is quality assurance. This involves ensuring that all the guidelines set forth in DO 178C have been followed correctly and that the software is safe and reliable. Quality assurance should be an ongoing process to ensure that software remains compliant with the guidelines throughout its operational life cycle.
Quality assurance is essential to ensure that the software is safe and reliable. It involves ensuring that all the guidelines set forth in DO 178C have been followed correctly and that the software meets all the requirements. Quality assurance should be an ongoing process to ensure that the software remains compliant with the guidelines throughout its operational life cycle. This is important because it ensures that the software remains safe and reliable throughout its operational life cycle.
DO 178C is an essential set of guidelines for the development of software used in airborne systems. The history, purpose, and software levels of DO 178C have been discussed, as well as the software development process itself. It is essential to follow these guidelines to ensure that software-based systems used in critical flight operations are safe and reliable.
‍Learn more about how Collimator’s model based development can help you prepare for DO-178C qualification.
.jpg)
.png){kind=small}
.png){kind=small}
.png){kind=small}
.png){kind=small}
.png){kind=small}