1. DO-178C the future of Avionics Certification
Martin Beeby, European Manager, Atego HighRely

2. What is DO-178
RTCA DO-178: “Software Considerations in Airborne Systems and Equipment Certification”
Developed by Industry and Government committees
Many compromises to satisfy different goals: “Consensus”:
Collective opinion or concord; general agreement or accord [Latin, from consentire, to agree]
Not a recipe book or “How To” guide
Guidance not prescription
Lawyers versus Software Engineers; who wins?

3. DO-178: Evolution History
Doc
Year
Basis
Themes
DO-178
498 & 2167A
Artefacts, documents, traceability, testing
DO-178A
1985
Processes, testing, components, four criticality levels, reviews, waterfall methodology
DO-178B
1992
Integration, transition criteria, diverse development methods, data (not documents), tools
DO-178C +Supplements.
2012
Reducing subjectivity; Address MBD,OO, tools, Formal methods, etc.

4. Avionics Safety History: 1946 - 2008

5. Safety: the precursor to DO-178

6. Safety, System, Software & Hardware
Safety Assessment
ARP 4761
System Development
ARP 4754
Architecture
Criticality Level
SW Rqmts
HW Rqmts
Tests
Tests
Software
DO-178
Hardware
DO-254

7. Functional Safety
The Functional Safety framework surrounding DO-178 similar to:
IEC – Industrial systems development
ISO – Automotive systems development
EN – Railway systems
IEE – Nuclear Power Systems
Objective based guidance gives development freedom with compromising the use of new technology.

8. Why change DO-178B Almost 20 years since DO-178B released
Software Development landscape has changed ...
Advancements in:
Tools & automation
Modelling & Simulation
Object Oriented Technology
Formal Methodologies
Commercial world has embraced the above; Avionics has slowly followed
Alternate Means of Compliance does not provide a consistent mechanism for certification

9. DO-178C
Since 2005, committees have met to discuss, and update, DO-178B
Like 178B, included Industry & Agencies
Unlike 178B, more Tool Vendors
Obvious focus on “acceptability” of certain types of tools, particularly “theirs”
Predominantly America & Europe, nearly equal; quarterly meetings

10. DO-178C : Seven “Sub-Groups” (SG’s)
SG1: Document Integration
SG2: Issues & Rationale
SG3: Tool Qualification
SG4: Model Based Design (MBD) & Verification
SG5: Object Oriented (OO) Technology
SG6: Formal Methods (FM)
SG7: Safety Related Considerations (and ground-based systems)

11. DO-178C
Unlike the DO-178A to DO-178B update, the “core” update to 178C is modest
Instead, changes are handled via four “Supplements”, which “clarify”:
Tools Supplement
MBD Supplement
OO Supplement
FM Supplement

12. Deliverables
DO-178C/ED-12C Software Considerations in Airborne Systems and Equipment Certification
DO-248C/ED-94C Supporting Information for DO-178C and DO-278A
DO-278A/ED-109A Software Integrity Assurance Considerations for Communication, Navigation, Surveillance and Air Traffic Management (CNS/ATM) Systems
DO-330/ED-215 Software Tool Qualification Considerations
DO-331/ED-216 Model-Based Development & Verification
DO-332/ED-217 Object-Oriented Technology Supplement
DO-333/ED-218 Formal Methods Supplement

13. Software Tool Qualification Considerations (D-330)
Tool Qualification Considerations is a stand alone document that is consistent with and follows the structure of DO-178C
It recognizes that tools occupy their own domain
They are not airborne software
Tool qualification can apply to hardware and ground-based systems also
DO-330 is a stand-alone approach to tool qualification that could be called out by any standard
Domain Specific Guidance in the calling document
Tool qualification guidance from DO-330 based on crteria defined in the domain specific guidance

14. Same Basic Tool Qualification Principles
The tool qualification is unchanged from DO-178B:
The purpose of the tool qualification process is to ensure that the tool provides confidence equivalent to that of the process(es) eliminated, reduced, or automated
The higher the risk of a tool error adversely affecting system safety, the higher the rigor required for tool qualification
Determining if tool qualification is needed, or unchanged from DO-178B:
“…when processes of this document are eliminated, reduced, or automated by the use of a software tool without its output being verified as specified…”

15. DO-178C Tool Qualification Levels
DO-178B Development and Verification Tools terminology is no longer used. DO-178B Definitions:
Development Tools: whose output is part of airborne software and thus can introduce errors
Verification Tools: that cannot introduce errors but may fail to detect them
DO-178C identifies 5 Tool Qualification Levels (TQL1-5) based on 3 criteria (see next slide):
For criteria 1 and 3, the basic concept and required objectives are similar to that applied under DO-178B
New criterion 2 introduced to provide increased objectives for certain tool usage scenarios

16. Advantages of Model-Based Development (DO-331)
Early animation of requirements
Shared language between systems and software engineers
Increased responsiveness to requirements changes
Ability to use autocode and simulation as a means of verification

17. Model Based Development Supplement (DO-332)
Provides additional guidance for Model Based Development Technology and Related Techniques
The MBD Supplement provides a set of approaches that can encompass most organisations uses of MBD
A Framework for using MBD is established
Guidance on where certification credit for model simulation is provided
Core techniques of DO-178C are maintained in MBD
Requirement Levels
Requirement Based Testing
Traceability
Structural Coverage

18. Object-Oriented Supplement (DO-332)
Provides additional guidance for Object-Oriented Technology and Related Techniques
Much of the DO-178C OOT Supplement is devoted to establishing core terminology, background and interpretation
Few additional objectives or activities are identified
Additional OOT objectives:
Verify local type consistency
Verify the use of dynamic memory management is robust

19. Criteria for choosing whether to use OOT
Project technical criteria:
Potential benefit from increased expressive power in design/code – encapsulations, class hierarchies and polymorphism
Nothing new here… these were original drivers behind OOT
Environmental criteria:
Guidance, Human Resources, Tools
In industry these are all currently available…
Summary:
OOT is a viable technique if the software design would benefit from its expressiveness

20. Formal Methods Supplement (DO-333)
DO-178B allowed for consideration of formal methods as an alternate method “to improve the specification and verification of software”
Included a set criteria to determine the requirements to which formal methods could be applied
Safety related
Definable by discrete mathematics
Involved complex behavior
Concurrency
Distributed processing
Redundancy management
Synchronization

21. Formal Methods Supplement
The formal methods supplement applies where formal methods analysis is replacing testing evidence in the submission
There is no intent to suggest that formal methods adoption is an “all in” decision
Can be a selective adoption/migration for subsets of the system
The supplement mimics the core DO-178 document structure
Does not preclude traditional software testing even when comprehensive formal methods are applied

22. DO-178C Supplements Summary: Changing the Level of Abstraction
There is an underlying synergy between the new DO-178C documents and supplements:
Object Oriented Technology (OOT), Model Based Design and Verification (MBDV), Tools, Formal Methods
All are moving in a common direction:
Still enforce the objectives of DO-178C
Enable systematic verification and/or increased level of abstraction
Enabling more powerful development techniques to tackle the issues of increased complexity and limited resources
Fundamental approach of DO-178 remains intact

23. DO-178C: The Future
DO-178C will be mandated by EASA, FAA, and others at some time in the future.
When?
But it will be mandated!
The model of providing Technology Supplements will be applied to future standards
Maintain a core approach
Enable approaches for new technologies to be added
Be able to react more quickly by just adding supplements

24. Good Engineering Practice
DO-178C: The Future
How will DO-178C affect systems development?
How did DO-178B affect systems development?
No specific life-cycle model required
Say what you are going to do
Do it
Show the evidence you did it
Analogous to ISO 9001, or CMMI
Good Engineering Practice

25. SEI CMMI Maturity Levels
SEI CMMI’s 5 Levels:
Initial
Repeatable (disciplined)
Defined (consistent))
Managed (predictable)
Optimizing (continuous improvement)
Each level is a perfect superset of the preceding level

26. DO-178 Quality/Cost 100 % Perfection Perfection CO$T Plans & Processes
Detailed Rqmts
Unit Testing
Functional Testing
Robust. Testing
Code Reviews

27. DO-178C: The Future
By Enabling new technologies it is possible to reduce the cost of development
Reduced Time of Development
Ability to increase system capabilities
Reduce Obsolescence
Fundamental Safety approach is not compromised
Functional Safety Framework remains
Core approaches of DO-178 remain
New technologies have to fit within this framework