DO-178C Transition

Charge code:
Project: 2150-002-602 Deos Product Maintenance
Task: 14 DO-178C Transition

Transition Status

The decision to flip the switch to DO-178c was made on 6/11/14, and the DDC-I team began using the new Plans and Standards (checklists) on 6/16/14.

Nice overview of changes: http://www.adacore.com/uploads/technical-papers/DO178C-ED12C-Changes_and_Improvements-Sep2012.pdf

Plan Document Reviews

Planning documents need to be reviewed and published using the Document Publishing How-To. Also, please consider the feedback we received from Modelo.

Note: When all Plans are published, request an SQA planning document audit, to include recent standards changes.

The table below can be used to coordinate resources and monitor progress.

Document	Assignee	Status	Remarks
PSAC	MD	Done
SDVP	MD	Done
SCMP	MD	Done
SQAP	MD	Done
TQP	MD	Done

Change Impact to Developers

Review Process

Review checklists are maintained in the development tree, then copied to the cert archive. Updates to Requirements and Code review checklists (considered "standards") must be reviewed and accepted before being copied to the cert archive (as described in https://deos.ddci.com/scm/Deos/docs/howto/document-publishing-howto/document-publishing-howto.htm#publish-the-standard). The Review Summary Report provides a "Launch Checklist" button to ensure the correct checklist from the cert archive is being accessed.

• Requirements Review Checklist: no impact
• Code Review Checklist:
  • Updates to fly-over help on several items pertaining to OOT
  • New checklist item "No calls to compiler supplied libraries are used"
  • Additional conditions added to checklist item "Boolean expressions comply with the ABC grammar rule"
• Test Case Review Checklist:
  • New checklist item "If functional software requirements exist for classes or objects, ensure that each class passes all of the tests of all its parent types which the class can replace."
  • Updates to checklist items tracing to DO-178C 6.5a and 6.6
• Test Procedure Review Checklist:
  • ** Updates to checklist items tracing to DO-178C 6.5a and 6.6
• CVT Requirements Review Checklist: new workstep
• CVT Tests Review Checklist: new workstep

Subject Area

Parameter Data Items (PDI)

• TQL4; Parameter Data Files (PDF); need to state what we do
• Parameter Data Items; suggestion to describe them in terms of requirements
• Parameter Data Items; handling of bogus items
• TQL5; not justified in removing run-time checks (If run-time checks are eliminated then the tool must be qualified as TQL-4 tool for DAL A or B software)
• TQL4 common failure due to common tool/verification tool
• SQA impact: New objectives in DO-330 may require additional audit activity; do we need to audit tool development/verification activities independent of other components?
• Other new objectives in DO-330 applying to all qualification levels that require scrutiny: T-O(6), T-10(4).

Object Oriented Technologies (OOT)

• OOT; applies to us as we are using techniques
• Philosophy was to map current plans and checklists to vulnerabilities listed in DO-332 (OOT supplement). The vulnerability list (Appendix D) essentially summarizes the reasons for the differences between DO-178C and the supplement. Note: Many sections in the OOT supplement indicate there are no differences from DO-178C.

DO-178C changes - DO-332 (OOT)

Reference	Type	Description	Plans Affected	Plans Modified	Done	Comments
All	new	Need to show compliance to DO-332	PSAC	PSAC	Yes	Updated to state compliance to DO-332 and reference additional considerations document.

DO-332 (OOT) compliance matrix

Reference	DO-332 Heading	Plans Modified	Done	Comments
OO.4.0	SOFTWARE PLANNING PROCESS		Yes	No impact. We do not have any conflicts between OO and DO-178C. No discussion in PSAC necessary.
OO.4.1	Software Planning Process Objectives	codeChecklist.htm	Yes	No impact
OO.4.2	Software Planning Process Activities		N/A	'm' & 'n' are new. May want to considering updating the PSAC to call out no virtualization (m) and discuss lack of "reuse" (n). Checklist help mouse-over refers to to OO.4.2n. That may be enough. I don't think additional changes are required for this section of DO-332 unless there are SOI comments.
OO.4.3	Software Plans	PSAC	Yes	Added section 9 "CONSIDERATION OF OOT&RT FEATURES" to PSAC.
OO.4.4	Software Life Cycle Environment Planning		Yes	No impact. Only the effects of virtualization and reuse were added to the considerations.
OO.4.4.1	Software Development Environment		Yes	No impact. No additions to what is in DO-178C.
OO.4.4.2	Language and Compiler Considerations		Yes	No impact. Only changes were the addition of absolute section references instead of the document relative ones in DO-178C.
OO.4.4.3	Software Test Environment		Yes	No impact. No additions to what is in DO-178C.
OO.4.5	Software Development Standards		Yes	No impact. Only changes were the addition of absolute section references instead of the document relative ones in DO-178C.
OO.4.6	Review of the Software Planning Process		Yes	No impact. Only changes were the addition of absolute section references instead of the document relative ones in DO-178C.
OO.5.0	SOFTWARE DEVELOPMENT PROCESS		Yes	No impact. Only changes were the addition of absolute section references instead of the document relative ones in DO-178C.
OO.5.1	Software Requirements Process		Yes	No impact. Only the effects of virtualization and reuse were added to the considerations.
OO.5.1.1	Software Requirements Process Objectives		Yes	No impact. No additions to what is in DO-178C.
OO.5.1.2	Software Requirements Process Activities		Yes	No impact. No additions to what is in DO-178C.
OO.5.2	Software Design Process		Yes	No impact. Only the effects of virtualization and reuse were added to the considerations.
OO.5.2.1	Software Design Process Objectives		Yes	No impact. No additions to what is in DO-178C.
OO.5.2.2	Software Design Process Activities		Yes	'h' - 'l' are new, but our checklists don't trace to this section. Instead, section 6 (verification process) is traced and these activities are implied through subsequent verification. However, some help mouse-over was added that refers to applicable OO.5.x sections for further discussion.
OO.5.2.3	Design for User-Modifiable Software		N/A	No additions to what is in DO-178C.
OO.5.2.4	Designing for Deactivated Code		Yes	No compiler supplied libraries are used and we don't have requirements traced to complex classes. In the supplement, there were No additions to what is in DO-178C.
OO.5.3	Software Coding Process		Yes	No impact. Only the effects of virtualization and reuse were added to the considerations.
OO.5.3.1	Software Coding Process Objectives		Yes	No impact. No additions to what is in DO-178C.
OO.5.3.2	Software Coding Process Activities		Yes	No impact. No additions to what is in DO-178C.
OO.5.4	Integration Coding Process		Yes	No impact. Only the effects of virtualization and reuse were added to the considerations.
OO.5.4.1	Integration Process Objectives		Yes	No impact. No additions to what is in DO-178C.
OO.5.4.2	Integration Process Activities		Yes	No impact. No additions to what is in DO-178C.
OO.5.5	Software Development Process Traceability		Yes	'd' (object-oriented design; focus on complex class interactions) is new, but our checklists don't trace to this section. Instead, section 6 (verification process) is traced and these activities are implied through subsequent verification.
OO.6.0	SOFTWARE VERIFICATION PROCESS		Yes	No impact. Only changes were the addition of absolute section references instead of the document relative ones in DO-178C.
OO.6.1	Purpose of Software Verification Process Activities		Yes	No impact. Only the effects of virtualization and reuse were added to the considerations.
OO.6.2	Overview of Purpose of Software Verification Process Activities	codeChecklist.htm	Yes	New: f - consistency between class hierarchy and requirements g - local type consistency h - memory management consistent with architecture strategy i - exception management consistent with architecture strategy All new OO.6.2x sections are traced in checklist.
OO.6.3	Software Reviews and Analyses		Yes	No impact. No additions to what is in DO-178C.
OO.6.3.1	Reviews and Analyses of High-Level Requirements		Yes	No impact. No additions to what is in DO-178C.
OO.6.3.2	Reviews and Analyses of Low-Level Requirements		Yes	No impact. No additions to what is in DO-178C.
OO.6.3.3	Reviews and Analyses of Software Architecture	codeChecklist.htm	Yes	'a' was changed to reference DO-332 sections outlining concerns with complex classes and memory management. Traced checklist items that covered the concerns.
OO.6.3.4	Reviews and Analyses of Software Architecture	codeChecklist.htm	Yes	'f' was changed to address concerns with overloading and type conversion. Added and traced checklist items that covered the concerns.
OO.6.3.5	Reviews and Analyses of the Outputs of the Integration Process		Yes	No impact. No additions to what is in DO-178C.
OO.6.4	Software Testing		Yes	No impact. No additions to what is in DO-178C.
OO.6.4.1	Test Environment		Yes	No impact. No additions to what is in DO-178C.
OO.6.4.2	Requirements-Based Test Selection		Yes	No impact. No additions to what is in DO-178C.
OO.6.4.2.1	Normal Range Test Cases	testCaseChecklist.htm	Yes	'e' was added to ensure requirements-based classes are tested to ensure their constructors initialize objects in a manner that is consistent with the requirements. We do not have requirements-based classes, but the provision to check for it was added to the checklist.
OO.6.4.2.2	Robustness Test Cases		Yes	No impact. No additions to what is in DO-178C.
OO.6.4.3	Requirement-Based Testing Methods		Yes	No impact. No additions to what is in DO-178C.
OO.6.4.4	Test Coverage Analysis		Yes	No impact. No additions to what is in DO-178C.
OO.6.4.4.1	Requirements-Based Test Coverage Analysis		Yes	No impact. No additions to what is in DO-178C.
OO.6.4.4.2	Structural Coverage Analysis		Yes	No impact. No additions to what is in DO-178C.
OO.6.4.4.3	Structural Coverage Analysis Resolution		Yes	No impact. No additions to what is in DO-178C.
OO.6.4.5	Reviews and Analyses of Test Cases, Procedures, and Results		Yes	No impact. No additions to what is in DO-178C.
OO.6.5	Software Verification Process Traceability		Yes	No impact. No additions to what is in DO-178C.
OO.6.6	Verification of Parameter Data Items		Yes	No impact. No additions to what is in DO-178C.
OO.6.7	Local Type Consistency Verification		N/A	No impact. Section is just an information sentence.
OO.6.7.1	Local Type Consistency Verification Objective	codeChecklist.htm	Yes	Concern is about safe type substitutions. Checklist item was added for type conversion, but not traced since this verification section is geared towards testing.
OO.6.7.2	Local Type Consistency Verification Activity	testCaseChecklist.htm	Yes	Identifies testing activities the ensure type consistency. Updated checklist to address concerns. Change is traced.
OO.6.8	Dynamic Memory Management Verification		N/A	No impact. Section is just an information sentence.
OO.6.8.1	Dynamic Memory Management Verification Objective	codeChecklist.htm	Yes	Concern is robustness of dynamic memory management. Trace was added to relevant checklist items and mouse-over help was added.
OO.6.8.2	Dynamic Memory Management Verification Activities	codeChecklist.htm	Yes	Section identifies a list of activities 'a' - 'g' to perform. Added a checklist item for checking the robustness of dynamic memory management. Concerns identified this section were added the associated mouse-over help for clarification.

Misc

• Number/reference changes
• Review of our standards maybe required
• Verify tracing of test case -> test procedures -> test result
• New independence rules relative to SCA ("Test Coverage Analysis")
• Annex A changes, e.g. as relates to PSAC appendix D.
• SCMP was modified to eliminate references to "verification tool" and "development tool"

DO-178C changes

Reference	Type	Description	Plans Affected	Plans Modified	Done	Comments
2	modified	System aspects updated			Yes	No impact
4.2.j	new	Software planning process for PDI		PSAC	Yes	verbiage was added to indicate PDI is the target system responsibility
4.2.k	new	software planning address additional considerations		None	Yes	PSAC always has directed to additional considerations doc
4.2.l	new	software planning address supplier oversight if dev activities performed by supplier		PSAC	Yes
4.4.1.f	new	SW Dev Env; known tool problems assessed		document-review-checklist.htm	Yes	Is a change needed? Already state no assumption of compiler and verify object code. Can any other development environment tools affect certified software, to warrant a note? MWL - Added checklist item to address DO-178C 4.4.1(f). We probably do a good job of this already. It was added to DO-178C for a reason so it doesn't hurt to add one item to make the auditors happy.
4.5.d	new	robustness considered in sw dev standards		document publishing checklist	Yes
5.0	new note	may be required to justify single level of requirements			Yes	SDVP justifies single level
5.1.2.h,i	merged to h	derived high level requirements			Yes	SDVP indicates we don't trace to system requirements, consider derived requirements
5.1.2.j	renamed to i	derived high-level requirements to system process		PSAC	Yes	Target system developer responsibility
5.1.2.j	new	Requirements for PDI (structure, data elements, etc)		PSAC	Yes	verbiage was added to indicate PDI is the target system responsibility
5.2.2.d-f	renamed to e-g	software design process activities			Yes	No direct references to numbering found
5.2.2.d	added	interfaces between components data/control flow consistent		PSAC	Yes	Target system responsibility objective table (Table 7) was updated
5.2.4	added	design for deactivated code (most moved from 5.4.3 integration			Yes	Addtl considerations covers deactivated code
5.3.2.d	new	autocode generators		SDVP	Yes	sdvp states we do not use
5.4.1	updated	exe and PDI file loaded to target hardware			Yes	Target system responsibility objective table (Table 7) was updated
5.4.2.a	updated	generate PDI file			Yes	Target system developer responsibility to generate PDI file
5.4.2.b	new	integration performed on host, emulator, or target			Yes	no action needed
5.4.2b-c	renamed to c-d				Yes	no references to numbering found
5.4.2.e-f	moved from 5.4.3	use of patches			Yes	no references to numbering found
5.4.2	removed	deactivated code and patches moved to other sections			Yes	covered where moved to
6.1e	new	exe is robust with requirements can respond to abnormal inputs			Yes	no direct ref. TC checklist covers robust with requirements
6.1f	renamed from 6.1.e	means to perform verf are correct for DAL			Yes	no direct ref
6.2	updated	trace data is now also an output (see 11.21)		Req Cov Analysis Test Results Review	Yes
6.2	updated	all bullet numbering changed			Yes	no direct refs
6.2	updated	verification independence may be achieved by a tool			Yes	no impact
6.3.4.f	updated	compiler, linker, hardware impact on WCET		codeChecklist	Yes
6.3.5	updated	add bullet for examining compiler warnings		None	Yes	Software Release HowTo already handles
6.3.6	moved to 6.4.5	review of test case, procedure, results		testProcedureChecklist.htm	Yes	See 6.4.5. TP checklist had reference to 6.3.6 that needed to change.
6.4.4	updated	adds 4 objectives test coverage of requirements and structures		testCaseChecklist.htm testProcedureChecklist.htm	Yes
6.4.4.1	updated	updates bullet to use Trace Data, adds 2 bullets for resolve deficiencies and confirm all TC and TP to get struct cov trace to req		testCaseChecklist.htm testProcedureChecklist.htm	Yes
6.4.4.2.b	updated	struct cov can be on src, obj, or exe but if compiler/linker generates code not traceable to source additional verf needed even if used obj/exe		PSAC Additional Considerations	Yes	This objective is explained within the context of the ABC and DO-332 vulnerability discussions. Updated PSAC and additional considerations to reflect that ABC is now and acceptable means of structural coverage and no longer considered to be an alternative means. Renamed heading for PSAC section 7.1 to be "Structural Coverage and MCDC Objectives" instead of "Alternative Means of Compliance".
6.4.4.2.d	new	struct cov analysis resolution			Yes	SDVP already has cycle to resolve. Clarified SCA is based on requirements based tests
6.4.4.3.c	modified	dead code expanded with extraneous code		Additional Considerations codeChecklist.htmtestCaseChecklist.htm testProcedureChecklist.htm	Yes	\"Extraneous\" is largely due to COTS libraries and OOT. The additional considerations document and code review checklist were sufficiently modified for DO-332 support that this issue should be well covered. Further changes to the test case and test procedure checklists and the inclusion of trace data in DO-178C objectives will result in the identification of dead or extraneous code.
6.4.4.3.d	updated	deactivated code now has two categories. Cat 1 unintended, Cat 2 operational in certain configs		Additional Considerations	Yes	Modified verbiage to reflect category one and two definitions.
6.4.5	moved from 6.3.6	review of TC, TP, results		Test Results Review	Yes
6.5.a	new	trace data requirements to test case		Req Cov Analysis testCaseChecklist.htm	Yes	cert archive script creates reference in 11-21-trace-data
6.5.b	new	trace data test case to test procedure		Req Cov Analysis Test Results Review testProcedureChecklist.htm	Yes	cert archive script creates reference to test results review for 11-21-trace-data
6.5.c	new	trace data test procedures to test results		Test Results Review	Yes	cert archive script creates reference to test results review for 11-21-trace-data
6.6	new	verf of PDI files		PSAC	Yes	verbiage was added to indicate PDI is the target system responsibility
7.0	moved from 7.1	scm process		CCB How-to	Yes	updated numbering
7.1	new	scm process objectives bullets a-i summarize table A-8			Yes	no updates needed
7.2.5	reordered	bullets reordered but same content		CCB How-to	Yes	updated numbering
7.4	moved from 7.2.8	software load control		PSAC	Yes	Appendix B ref update
7.5	moved from 7.2.9	software life cycle environment control		PSAC	Yes	Appendix B ref update
8.1.a	moved and modified from 8.2.b	SQA assurance plans and standards are reviewed to DO-178C		doc publishing, planning doc audit	Yes
8.1.b	modified from 8.1.a	Adds including suppliers for processes comply with plans and standards			Yes	References updated in audit checklists, no supplier wording needed.
8.1.b-c	moved to 8.1.c-d	Update referenced sections		backup-audit-checklist.htm media-archive-audit-checklist.htm software-conformity-audit-checklist.htm software-life-cycle-audit-checklist.htm verification-audit-checklist.htm	Yes
8.2.i	new	SQA process assure that supplier processes and outputs comply with plans and standards			Yes	PSAC/SQAP indicate suppliers use Deos plans and included in SQA review
9.0	updated	Adds bullets for the objectives from A-10			Yes	no impact
11.0	updated	layout changes but content is basically the same	None		Yes
11.2.c(3)	updated	split into 3 and 4 (adds comment about autocode generators			Yes	SDVP covers. No direct reference past c so no update needed.
11.5	updated	SQAP suppliers process comply with plans and standards, previously sub-tier suppliers comply with SQAP			Yes	Plans indicate suppliers all use DDC-I plans and SQA verifies all life cycle data
11.14	updated	software verf results Add paras for discrepancies recorded in PCR and evidence provided in support of system process assessment considered software verf results			Yes	Processes already describe PCR for discrepancy whether during development or SQA
11.16.b	updated	bullet b adds PDI files with exe code		PSAC	Yes	verbiage was added to indicate PDI is the target system responsibility
11.16.j	new	procedures, methods, and tools for making modifications to the user-modifiable software			Yes	No impact. User-modifiable software not used.
11.16.k	new	Procedures and methods for loading the software into the target hardware.		PSAC	Yes	Target system responsibility objective table (Table 7) was updated to indicate they are responsible for documenting on-target software loading procedures and methods
11.20.i	renamed from d	software characteristics			Yes	No impact
11.20.g	new	supplier oversight - how supplier processes and outputs comply with plans and standards			Yes	Updated section 6 of the SCMP. The existing discussion on supplier oversight should still be sufficient since it was acceptable in prior certifications. There may be a need to update SQAP for on-site audits of off-shore facilities (for 8110.49 Chg 1, section 13-4 7a), but that won't be necessary unless specifically requested in a SOI. Change made to the SCMP identified that the life cycle data is in English and available on US servers (For 8110.49 Chg 1, section 13-4 7c).
11.20.i,j,k	renamed to j,k,l	change history - no change software status - Added more detailed status requirements to include justification for open PCRs at cert along with details of mitigation activities that have or need to be done compliance statement - clarification that this statement does not need to repeat deviations already covered in the SAS			Yes	Already cover mitigation activities
11.21	new	Trace Data (effectively adds TC <-> TP and TP <-> test results		cert archive script Test Results Review	Yes
11.22	new	Parameter Data Item File		PSAC	Yes	verbiage was added to indicate PDI is the target system responsibility
12.1	updated	Use of Previously Developed Software - Unresolved PCRs must be evaluated for impact		PSAC	Yes	Added a statement regarding PCRs against the existing baseline to section 7.2 of the PSAC.
12.1.3.c	new	Changes to autocode generator or options			Yes	No impact, auto-generated code is not used.
12.1.3.d-e	renamed from c-d				Yes	No impact. No content changes in guidance and no references in plans to these specific items that were re-sequenced.
12.1.3.f	new	hardware other than processor changed		PSAC	Yes
12.1.3.g	renamed from e			PSAC	Yes	Added a statement in the PSAC (section 7.2) to specifically state that an impact analysis will be performed to address reverification needs.
12.2	modified	Determining TQL, then use DO330 for objectives		PSAC	Yes	Identifies CVT as TQL 4, ABC/traceaid as TQL 5
12.3.1	removed	formal methods		PSAC SDVP	Yes	No impact, but a change was previously made to the PSAC to explicitly state that no MBD or Formal Methods are being used. Section 12.3.1 was removed because it is now contained in its own supplement (DO-333). Added same paragraph to SDVP.
A-1(2,3)	modified	Level D removed CC2			Yes	no impact
A-1	modified	no semantic changes, Objectives 1,2,3,7 wording changed		PSAC	Yes	appendices updated
A-2(2, 5)	modified	derived requirements must be provided to system processes		PSAC	Yes	appendices updated
A-2(7)	modified	add PDI to load to target computer, and as output		PSAC	Yes	verbiage was added to indicate PDI is the target system responsibility
A-2(4,5,6)	modified	no requirement for level D	PSAC	PSAC	Yes
A-2(1,4,6)	modified	output is Trace Data		cert archive	Yes	script adds readme to point to requirements coverage analysis
A-2(3,4,5)	modified	Level C CC changed to 1	None		Yes	Already do
A-5(8)	new	PDI File is correct and complete		PSAC	Yes	Target system responsibility objective table (Table 7) was updated
A-5(9)	new	verf of PDI file is achieved		PSAC	Yes	Target system responsibility objective table (Table 7) was updated
A-6(1,2,3,4)	modified	Trace Data is a cc1 output		SCMP	Yes
A-7(9)	new	Verf of addtl code that cannot be traced to Source (DAL A only) DO-332 (OOT) adds two objectives to this table. OO10 is local type consistency. OO11 is the verification of robust dynamic memory allocation. Note: OO supplement objective tables mirror DO-178C		codeChecklist.htm	Yes	OO supplement (table OO.C-7) required changes were made to the code checklist already. See code checklist changes that trace to OO.D.1.4, OO.D.1.5, OO.D.1.6, and OO.2.3.
A-9(1)	new	plans and standards reviewed for compliance with do-178c		Doc Publishing Planning doc audit	Yes	Update document-review-checklist.htm to include software standards.
A-9(2,3)	split from 1	processes comply with (2) plans and (3) standards			Yes	no impact
A-9(4,5)	renamed from 2,3	4 has additional DAL C requirement			Yes	no impact
Glossary	modified	lots of updates, of note to us are deactivated code, MC/DC		PSAC Additional Considerations	Yes	Modified verbiage to reflect the two categories of deactivated code. Modified to reflect that ABC no longer needs to be considered an alternative means of compliance.

Team Sign-up

Subject Area Team

Name	PDI	OOT	Misc	Comments
Aaron Larson	TBD	Yes	TBD
John Riedmann	Yes
Matt Diethelm			Yes
Michael Horgan	Yes
Michael Landreth		Yes	Yes
Richard Frost		Yes	Yes

References

• DO-178C: Learn how to download electronic DO-178C copies at Engineering_Standards_Downloads
• Summary of Changes: https://ddci.zapto.org/scm/Deos/docs/reference-data/cert/DO178C-ED12C-Changes_and_Improvements-Sep2012.pdf

GeekFest 2014 All-hands Presentation and Break-out Session

Here's the presentation that was given during the all-hands session:

Media:Do-178c-all-hands.pdf

Here are the notes from discussion:

• We may need independent reviews of our checklists (if we're not doing that already).
• DO-278A (for ground and space-based systems) may impose different requirements, such as for system up-time.
• The use of preconditions, post-conditions, and/or invariants may be considered a formal method.

DO 178C Conference 2012 Mar 13

Background

Bill Cronk and Matt Diethelm attended a three day "Learn DO-178C" conference held by Worldwide Certification Services in Ontario, California. The conference goal was to summarize the changes between DO-178B, and the recently published DO-178C.

While the conference material was provided electronically, its copyright restricted usage to attendees only. This wiki page provides a presentation and conference summary.

Executive Summary

• No new problem domains were introduced. DO-178C does not, for the most part "raise the bar" to certification. It does clarify and attempt to disambiguate, thus this has resulted in more "bulk," mainly by correcting known errata, and incorporating existing issue papers, advisory circulars, and Certification Review Items (CRI). What results is a core document (DO-178C), and up to four supplements that may or may not apply depending on what tools and techniques are used to develop and verify the software system.
• Depending on project applicability, the supplements may add to, remove, or replace one or more of the core, DO-178C objectives.
• Some new terms have been introduced, and some others dropped.
• Some glossary definitions have been changed, e.g. Deactivated Code, and Modified Condition Decision Coverage.
• For Level A software, there are now five additional objectives (total is now 71), and thirty of them (as opposed to 25 previously) must now be satisfied with independence.
• The FAA had no date when they would require DO-178C. The attending FAA representative threw out a guess landing sometime in 2013.
• While the FAA has no short term goal to mandate DO-178C, industry is free to adopt it at anytime. The FAA representative indicated that anyone would likely be able to get approval to do so as an additional consideration to existing regulations. Thus, while the FAA or EASA may not mandate its use near term, one of our customers might.
• Formal Methods (as described in the DO-333 Supplement) are now an approved means of compliance. This significantly reduces the friction that was preventing their use, and removes the "alternative means" stigma attached to them.

Change Impact Scenarios

Documented below are Bill and Matt's guesses as to what the change impact would be to move to DO-178C compliance.

Best Case

• Some of our documentation (Plans and Procedures) would change for:
  • new terminology, e.g. "Qualifiable Verification Tool" becomes "...developed in accordance with DO-330 Tool Qualification Level 5" or perhaps "DO-178C TQL5 tool" if you're in Marketing.
  • stronger descriptions on how we use certain tools and techniques, e.g. pictures, figures, and drawings are not used to convey requirements.
• Our PSAC's compliance matrix gets a few more rows to account for new objectives, and some of its explanatory text changes to clarify new roles and responsibilities.

Worst Case

• We claim we do not use Object Oriented Design, yet an auditor witnesses our use of Classes/Objects and becomes confused. This might incorrectly lead an auditor to subject us to more of DO-332 (Object Oriented Technology) Supplement's recommended activities, and outputs, and possibly put in jeopardy our claim that code can trace to just architecture.
  • JBR: DO-332 indicates its guidance should be followed when OO language features are used, even if we claim not to be using OO design. [OO.1.2]
• Our verification tools allow us to remove certain error checks from the flight software. An auditor may infer (incorrectly we believe) that our tools thus fall under DO-330 Criteria 2. This would trigger additional TQL4 objectives, activities, and outputs.
  • JBR: DO-330 section 1.5.3.2 discusses this scenario, and suggests we're not justified in relying on the verification of configuration files/registers by qualified tools to go without run-time checks of those files/registries.
• An auditor claims our pictures, figures, and drawings to be Models, and thus subject to any relevant DO-331 Model Based Development development and verification activities.
• We are forced to document the structure and attributes of the kernel registry and other configuration files as requirements. (Reference the new DO-178C objectives and activities regarding Parameter Data Information (PDI) files).
• The Traceability Matrix is forced to include trace information between test cases and procedures.

Notes

This section contains Engineering Notebook-type constructs for consideration and or incorporation once we start updating our Plan and Procedures for DO-178C.

Parameter Data Items (PDI)

The DO-178C text indicates that a PDI is a file that can be verified separately from the Executable Object Code (EOC) that uses it. If the prose intended EOC to mean "all the software components integrated on the target platform", then we can state that the Deos platform registry (for example) is not a PDI as it is not verified separately from the EOC. in short, we will state that the target system developer is responsible for verifying the EOC with the "revenue" registry activated, and that registry can not be modified separately and re-used in that baseline.

If the above will not "fly," then:

• The target system developer is responsible for developing the PDI High Level Requirements. We would suggest they use wordings such as "the PDI shall contain sufficient RAM quota to allow process XYZ to be created, or the PDI shall be set to grant process XYZ access to the frobulator hardware."

• We will continue to supply documents that the target system developer can use to develop the High Level PDI requirements from, e.g. the Deos Integration Tool User's Guide.

• We would assist in meeting some of the PDI verification objectives via our verification tools. For example, ensuring the PDI is compatible with the Executable Object Code.

• The target system developer is responsible for identifying in their Plans how the PDI is developed, verified, and loaded.

• We may need to adjust our Plans to identify the items we consider to be Parameter Data Items (now known as life-cycle data items 11.22).

• We may need to adjust our tool qualification data to indicate which parts of Section 6.6.a and 6.6.b we help satisfy.

Still To Be Resolved

• DO-178C Section 5.1.2.j: High Level requirements should specify the structure and attributes, and possibly the value. Yuk. The kernel registry is not user visible insofar as these low-level details. Called out as a required activity in Table A-2.1.

• If we say we will provide documentation that a target system developer can use to construct PDI High Level Requirements, what audit-able evidence must we provide of this documentation's correctness. For example, must we review and accept the Deos Integration Tool User's Guide?

• DO-248C, section 4.20.7 implies that Executable Object Code (EOC) "should be able to handle all correct PDI Files as well as all corrupted ones." We only agree here if EOC includes *all* software that makes up the baseline, that is, includes the target system developer code as well.

• SQA has new objectives to ensure suppliers' life cycle processes comply with approved plans and standards. This is an incorporation of items in 8110.49 change 1. Since SQA samples artifacts produced off shore there should not be any effects unless an on-site QA audit in off shore locations is required for a program. Since we are technically a supplier to our customers, if they don't already, our cost and schedules may need to account for on-site audits of DDC-I by our customers for DO-178C programs.