433:
test cases meant to verify the correctness of the source code with respect to the requirement, the results of those tests, etc. A traceability analysis is then used to ensure that each requirement is fulfilled by the source code, that each functional requirement is verified by test, that each line of source code has a purpose (is connected to a requirement), and so forth. Traceability analysis accesses the system's completeness. The rigor and detail of the certification artifacts is related to the software level.
467:"Software Tool Qualification Considerations", a new "domain independent, external document", was developed to provide guidance for an acceptable tool qualification process. While DO-178B was used as the basis of the development of this new document, the text was adapted to be directly and separately applicable to tool development and expanded to address all tool aspects. As a domain-independent, stand-alone document, DO-330 is intended for use not only in support of DO-178C/ED-12C, but
420:
179:(Additional information with rationale for each DO-178C objective), DO-330 (Tool Qualification), DO-331 (Modeling), DO-332 (Object Oriented), and DO-333 (Formal Methods) were created to address the issues noted. The SC-205 members worked with the SAE S-18 committee to ensure that ARP4754A and the above noted DO-xxx documents provide a unified and linked process with complementary criteria.
396:. Once an activity within a process has been defined, it is generally expected that the project respect that documented activity within its process. Furthermore, processes (and their concrete activities) must have well defined entry and exit criteria, according to DO-178C, and a project must show that it is respecting those criteria as it performs the activities in the process.
288:
require and DO-178C specifies the correct DAL be established using these comprehensive analyses methods to establish the software level A-E. "The software level establishes the rigor necessary to demonstrate compliance" with DO-178C. Any software that commands, controls, and monitors safety-critical functions should receive the highest DAL - Level A.
427:
tracing between certification artifacts, as required by the RTCA DO-178C standard. Thin blue-colored traces and blue-filled boxes are required only for Level A. Purple-colored traces and purple-filled boxes are required for Levels A, B, and C. Thick green-colored traces and green-filled boxes are for
399:
The flexible nature of DO-178C's processes and entry/exit criteria make it difficult to implement the first time, because these aspects are abstract and there is no "base set" of activities from which to work. The intention of DO-178C was not to be prescriptive. There are many possible and acceptable
291:
The number of objectives to be satisfied (some with independence) is determined by the software level A-E. The phrase "with independence" refers to a separation of responsibilities where the objectivity of the verification and validation processes is ensured by virtue of their "independence" from the
540:
within the text. "Guidance" conveys a slightly stronger sense of obligation than "guidelines". As such, with the DO-178C, the SCWG has settled on the use of "guidance" for all the statements that are considered as "recommendations", replacing the remaining instances of "guidelines" with "supporting
494:
the guidance of the DO-178C document to specific techniques. Rather than expanding the prior text to account for all current and future software development techniques, supplements are made available to explicitly add, delete, or otherwise modify the guidance of the core standard for application to
460:
Parameter Data Item Files - Provides separate information that influences the behavior of an executable object code (without changing it). An example would be a configuration file that sets up the schedule and major time frames of a partitioned operating system. The parameter data item file must be
432:
DO-178 requires documented bidirectional connections (called traces) between the certification artifacts. For example, a Low Level
Requirement (LLR) is traced up to a High Level Requirement (HLR) it is meant to satisfy, while it is also traced to the lines of source code meant to implement it, the
216:
The Model Based
Development and Verification subgroup (SG4) was the largest of the working groups. All work is collected and coordinated via a web-site that is a collaborative work management mechanism. Working artifacts and draft documents were held in a restricted area available to group members
287:
DO-178C alone is not intended to guarantee software safety aspects. Safety attributes in the design and as implemented as functionality must receive additional mandatory system safety tasks to drive and show objective evidence of meeting explicit safety requirements. The certification authorities
950:
DO-178C will contain more details on software modeling and the potential ability to use modeling to supplant some of the verification techniques normally required in DO-178B. DO-178C will also more fully address OO (Object
Oriented) software and the conditions under which it can be used and the
388:
Processes are intended to support the objectives, according to the software level (A through D—Level E was outside the purview of DO-178C). Processes are described as abstract areas of work in DO-178C, and it is up to the planners of a real project to define and document the specifics of how a
163:(DERs) for clarification/refinement of the definitions and boundaries between the key DO-178B concepts of high-level requirements, low-level requirements, and derived requirements and a better definition of the exit/entry criteria between systems requirements and system design (see
501:"Model-Based Development and Verification Supplement to DO-178C and DO-278A" - addressing Model-Based Development (MBD) and verification and the ability to use modeling techniques to improve development and verification while avoiding pitfalls inherent in some modeling methods
1156:
441:
SC-205/WG-12 was responsible for revising DO-178B/ED-12B to bring it up to date with respect to current software development and verification technologies. The structure of the document remains largely the same from B to C. Example changes include:
292:
software development team. For objectives that must be satisfied with independence, the person verifying the item (such as a requirement or source code) may not be the person who authored the item and this separation must be clearly documented.
389:
process will be carried out. On a real project, the actual activities that will be done in the context of a process must be shown to support the objectives. These activities are defined by the project planners as part of the
Planning process.
400:
ways for a real project to define these aspects. This can be difficult the first time a company attempts to develop a civil avionics system under this standard, and has created a niche market for DO-178C training and consulting.
495:
specific techniques or technologies. All guidance in these supplements are written in the context of the affected guidance elements in DO-178C and so should be considered as at the same level of authority as that core document.
265:- Failure has a large negative impact on safety or performance, or reduces the ability of the crew to operate the aircraft due to physical distress or a higher workload, or causes serious or fatal injuries among the passengers.
147:, designating DO-178C a recognized "acceptable means, but not the only means, for showing compliance with the applicable FAR airworthiness regulations for the software aspects of airborne systems and equipment certification."
907:
RTCA/DO-178C "Software
Considerations in Airborne Systems and Equipment Certification", p. 116. "One example is the term “item development assurance level” (IDAL), which for software is synonymous with the term “software
456:
in section 6.4.4.2b but not listed in the Annex A tables. This objective is now explicitly listed in DO-178C, Annex A, Table A-7, Objective 9: "Verification of additional code, that cannot be traced to Source Code, is
428:
Levels A, B, C, and D. Level E does not require any tracing. The references on each trace arrow represent references to the standard for the objective, the activity, and the review/verification, respectively.
663:
487:. Consequently, tool qualification guidance was removed in DO-178C, replaced therein with guidance for deciding when to apply DO-330 tool qualification guidance to tools used in a DO-178C context.
403:
For a generic DO-178C based process, Stages of
Involvements (SOI) are the minimum gates that a Certification Authority gets involved in reviewing a system or sub-system as defined by EASA on the
182:
Overall, DO-178C keeps most of the DO-178B text, which has raised concerns that issues with DO-178B, such as the ambiguity about the concept of low-level requirements, may not be fully resolved.
404:
727:
DO-178B, Software
Considerations in Airborne Systems and Equipment Certification ( in the context of software development for military aircraft, a practitioner's discussion of the
128:. The new document is called DO-178C/ED-12C and was completed in November 2011 and approved by the RTCA in December 2011. It became available for sale and use in January 2012.
277:- Failure slightly reduces the safety margin or slightly increases crew workload. Examples might include causing passenger inconvenience or a routine flight plan change.
171:
and considerations for replacing some or all software testing activities with model simulation or formal methods. The release of DO-178C and the companion documents
564:"The Executable Object Code satisfies the software requirements (that is, intended function), and provides confidence in the absence of unintended functionality."
679:
The industry expects the final package —DO-178C— to be released in the first quarter of 2011 and be mandated six to nine months after ratification.
252:
by examining the effects of a failure condition in the system. The failure conditions are categorized by their effects on the aircraft, crew, and passengers.
271:- Failure significantly reduces the safety margin or significantly increases crew workload. May result in passenger discomfort (or even minor injuries).
757:
160:
71:
167:) and that of software requirements and software design (which is the domain of DO-178B). Other concerns included the meaning of verification in a
648:
579:
The additional
Revision C clarification filled a gap that a software developer could have encountered when interpreting the Revision B document.
567:"The Executable Object Code is robust with respect to the software requirements that it can respond correctly to abnormal inputs and conditions."
484:
880:
560:
Chapter 6.1 defines the purpose for the software verification process. DO-178C adds the following statement about the
Executable Object Code:
220:
The work was focused on bringing DO-178B/ED-12B up to date with respect to current software development practices, tools, and technologies.
805:
Advances in systems safety : proceedings of the
Nineteenth Safety-Critical Systems Symposium, Southampton, UK, 8-10th February 2011
803:
788:
65:
1008:
514:
504:
498:
476:
468:
464:
172:
712:
The release of these long anticipated standards will occur in mid 2011 and be recognized by the Certification Authorities in 2012.
1053:
461:
verified together with the executable object code, or else it must be tested for all possible ranges of the parameter data items.
855:
602:
1131:
691:
132:
1081:
813:
392:
This objective-based nature of DO-178C allows a great deal of flexibility in regard to following different styles of
541:
information" and using that phrase wherever the text is more "information" oriented than "recommendation" oriented.
1111:
1091:
109:
105:
1229:
829:
764:
140:
1176:
1224:
1214:
1204:
735:
508:
136:
408:
725:
507:"Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A" - addressing
1209:
1092:"Safety-critical software for mission-critical applications to get boost with release of DO-178C"
926:
RTCA/DO-178C "Software Considerations in Airborne Systems and Equipment Certification", Annex A
979:
917:
RTCA/DO-178C "Software Considerations in Airborne Systems and Equipment Certification", p. 41
8:
937:"HighRely Synopsis of National FAA Software and Hardware Meeting Includes DO-178C Status"
571:
As a comparison, DO-178B states the following with regard to the Executable Object Code:
393:
1157:"Upgrade to DO-178B certification, DO-178C, to address modern avionics software trends"
1057:
244:(DO-178C only mentions IDAL as synonymous with Software Level), is determined from the
168:
117:
936:
116:
approve all commercial software-based aerospace systems. The document is published by
1219:
809:
782:
642:
965:
RTCA/DO-178C Software Considerations in Airborne Systems and Equipment Certification
143:
do not directly reference software airworthiness. On 19 Jul 2013, the FAA approved
113:
249:
102:
DO-178C, Software Considerations in Airborne Systems and Equipment Certification
1139:
623:
518:
699:
452:
Clarified the "hidden objective", applicable to Level A, which was implied by
1198:
856:"DO-178C brings modern technology to safety-critical software development"
664:"DO-178C nears finish line, with credit for modern tools and technologies"
621:
283:- Failure has no impact on safety, aircraft operation, or crew workload.
190:
The RTCA/EUROCAE joint committee work was divided into seven Subgroups:
419:
104:
is the primary document by which the certification authorities such as
22:
Software Considerations in Airborne Systems and Equipment Certification
1132:"DO-178C: Improved certification for cost-effective avionics systems"
555:
480:
144:
552:, falls into the "supporting information" category, not guidance.
446:
Provide clearer language and terminology, provide more consistency
833:
588:
575:"The Executable Object Code satisfies the software requirements."
453:
245:
241:
176:
164:
156:
125:
121:
85:
1054:"Achieving DO-178C compliance with Parasoft Development Testing"
881:"DO-178C Enhances Safety-Critical Avionics Software Development"
517:"Formal Methods Supplement to DO-178C and DO-278A" - addressing
593:
545:
472:
532:
DO-178B was not completely consistent in the use of the terms
259:- Failure may cause deaths, usually with loss of the aircraft.
1010:
DO-178C/ED-12C versus DO-178B/ED-12B Changes and Improvements
1177:"DO-178C/ED-12C vs DO-178B/ED-12B: Changes and Improvements"
1129:
405:
Certification Memorandum SWCEH – 002: SW Approval Guidelines
853:
731:
of the current practice and application of RTCA/DO-178B)
723:
692:"Summary of Difference Between DO-178B and DO-178C"
479:as well, even for non-aviation applications, e.g.,
556:Sample text difference between DO-178B and DO-178C
1196:
980:"Principles and benefits of using DO-330/ED-215"
1174:
1109:
1089:
661:
622:Timberlake Membership Software, 703-591-4232.
598:Supporting Information for DO-178C and DO-278A
550:Supporting Information for DO-178C and DO-278A
951:certification ramifications of OO in DO-178C.
903:
901:
511:and the conditions under which it may be used
203:SG4: Model Based Development and Verification
854:Bill StClair & Tim King (7 March 2012).
801:
1154:
647:: CS1 maint: numeric names: authors list (
436:
16:International aeronautics software standard
898:
698:. Qualtech Consulting, Inc. Archived from
527:
383:
802:Dale, Chris; Anderson, Tom, eds. (2010).
185:
717:
449:More objectives (for Levels A, B, and C)
418:
795:
521:to complement (but not replace) testing
1197:
1007:Pothon, Frédéric; et al. (2012).
1006:
808:. London: Springer. pp. 298–299.
787:: CS1 maint: archived copy as title (
161:Designated Engineering Representatives
1130:Bill StClair and Nat Hillary (2010).
490:Technology supplements were added to
409:Order 8110.49: SW Approval Guidelines
159:, there had been strong calls by FAA
1110:Charlotte Adams (1 September 2010).
1096:Military & Aerospace Electronics
662:Charlotte Adams (1 September 2010).
603:Modified condition/decision coverage
1090:Charlotte Adams (21 October 2010).
13:
977:
423:Diagram illustrating the required
212:SG7: Safety Related Considerations
14:
1241:
1075:
223:
736:Boeing Commercial Airplane Group
238:Item Development Assurance Level
169:model-based development paradigm
1046:
1037:
1028:
1000:
971:
957:
929:
920:
911:
414:
206:SG5: Object-Oriented Technology
1155:John McHale (8 October 2009).
873:
847:
822:
750:
684:
655:
615:
194:SG1: SCWG Document Integration
1:
608:
150:
141:Federal Aviation Regulations
7:
724:Leslie A. (Schad) Johnson.
582:
234:Development Assurance Level
10:
1246:
860:Military Embedded Systems
246:safety assessment process
197:SG2: Issues and Rationale
120:, in a joint effort with
91:
81:
58:
43:
26:
1175:Frederic Pothon (2012).
1136:VME and Critical Systems
509:object-oriented software
437:Differences with DO-178B
47:5 January 2012
528:Guidelines vs. guidance
384:Processes and documents
200:SG3: Tool Qualification
1112:"DO-178C Core changes"
830:"SC-205/WG-71 Plenary"
429:
186:Committee organization
1230:Software requirements
1161:Avionics Intelligence
1116:Avionics Intelligence
668:Avionics Intelligence
422:
240:(IDAL) as defined in
155:Since the release of
1060:on 11 September 2014
232:, also known as the
770:on 3 September 2014
696:FAA Consultants.com
394:software life cycle
209:SG6: Formal Methods
23:
1225:Safety engineering
1215:Computer standards
1205:2011 introductions
978:Pothon, Frédéric.
967:. RTCA, Inc. 2011.
548:/ED-94C document,
430:
307:With independence
301:Failure condition
175:(Ground Systems),
118:RTCA, Incorporated
21:
1034:Pothon, pp. 43-46
885:Electronic Design
702:on 27 August 2010
381:
380:
371:No Safety Effect
99:
98:
1237:
1191:
1189:
1187:
1171:
1169:
1167:
1151:
1149:
1147:
1138:. Archived from
1126:
1124:
1122:
1106:
1104:
1102:
1083:DO-178C Glossary
1069:
1068:
1066:
1065:
1056:. Archived from
1050:
1044:
1041:
1035:
1032:
1026:
1025:
1023:
1021:
1015:
1004:
998:
997:
995:
993:
984:
975:
969:
968:
961:
955:
954:
946:
944:
933:
927:
924:
918:
915:
909:
905:
896:
895:
893:
891:
877:
871:
870:
868:
866:
851:
845:
844:
842:
841:
832:. Archived from
826:
820:
819:
799:
793:
792:
786:
778:
776:
775:
769:
763:. Archived from
762:
754:
748:
747:
745:
743:
721:
715:
714:
709:
707:
688:
682:
681:
676:
674:
659:
653:
652:
646:
638:
636:
634:
619:
295:
294:
114:Transport Canada
54:
52:
24:
20:
1245:
1244:
1240:
1239:
1238:
1236:
1235:
1234:
1195:
1194:
1185:
1183:
1165:
1163:
1145:
1143:
1142:on 17 July 2011
1120:
1118:
1100:
1098:
1078:
1073:
1072:
1063:
1061:
1052:
1051:
1047:
1042:
1038:
1033:
1029:
1019:
1017:
1013:
1005:
1001:
991:
989:
982:
976:
972:
963:
962:
958:
942:
940:
935:
934:
930:
925:
921:
916:
912:
906:
899:
889:
887:
879:
878:
874:
864:
862:
852:
848:
839:
837:
836:on 19 July 2011
828:
827:
823:
816:
800:
796:
780:
779:
773:
771:
767:
760:
758:"Archived copy"
756:
755:
751:
741:
739:
722:
718:
705:
703:
690:
689:
685:
672:
670:
660:
656:
640:
639:
632:
630:
620:
616:
611:
585:
558:
530:
439:
417:
407:and FAA on the
386:
250:hazard analysis
226:
188:
153:
77:
50:
48:
39:
17:
12:
11:
5:
1243:
1233:
1232:
1227:
1222:
1217:
1212:
1210:RTCA standards
1207:
1193:
1192:
1172:
1152:
1127:
1107:
1087:
1077:
1076:External links
1074:
1071:
1070:
1045:
1036:
1027:
999:
970:
956:
928:
919:
910:
897:
872:
846:
821:
814:
794:
749:
716:
683:
654:
613:
612:
610:
607:
606:
605:
600:
591:
584:
581:
577:
576:
569:
568:
565:
557:
554:
529:
526:
525:
524:
523:
522:
519:formal methods
512:
502:
488:
462:
458:
450:
447:
438:
435:
416:
413:
385:
382:
379:
378:
375:
372:
369:
365:
364:
361:
358:
355:
351:
350:
347:
344:
341:
337:
336:
333:
330:
327:
323:
322:
319:
316:
313:
309:
308:
305:
302:
299:
285:
284:
278:
272:
266:
260:
230:Software Level
225:
224:Software level
222:
214:
213:
210:
207:
204:
201:
198:
195:
187:
184:
152:
149:
97:
96:
93:
89:
88:
83:
79:
78:
76:
75:
69:
62:
60:
56:
55:
45:
44:Latest version
41:
40:
38:
37:
34:
30:
28:
15:
9:
6:
4:
3:
2:
1242:
1231:
1228:
1226:
1223:
1221:
1218:
1216:
1213:
1211:
1208:
1206:
1203:
1202:
1200:
1182:
1178:
1173:
1162:
1158:
1153:
1141:
1137:
1133:
1128:
1117:
1113:
1108:
1097:
1093:
1088:
1085:
1084:
1080:
1079:
1059:
1055:
1049:
1043:Pothon, p. 14
1040:
1031:
1012:
1011:
1003:
988:
981:
974:
966:
960:
953:
952:
938:
932:
923:
914:
904:
902:
886:
882:
876:
861:
857:
850:
835:
831:
825:
817:
815:9780857291325
811:
807:
806:
798:
790:
784:
766:
759:
753:
737:
733:
732:
728:
720:
713:
701:
697:
693:
687:
680:
669:
665:
658:
650:
644:
629:
625:
618:
614:
604:
601:
599:
595:
592:
590:
587:
586:
580:
574:
573:
572:
566:
563:
562:
561:
553:
551:
547:
542:
539:
535:
520:
516:
513:
510:
506:
503:
500:
497:
496:
493:
489:
486:
482:
478:
474:
470:
466:
463:
459:
455:
451:
448:
445:
444:
443:
434:
426:
425:bidirectional
421:
412:
410:
406:
401:
397:
395:
390:
376:
373:
370:
367:
366:
362:
359:
356:
353:
352:
348:
345:
342:
339:
338:
334:
331:
328:
325:
324:
320:
317:
315:Catastrophic
314:
311:
310:
306:
303:
300:
297:
296:
293:
289:
282:
279:
276:
273:
270:
267:
264:
261:
258:
255:
254:
253:
251:
247:
243:
239:
235:
231:
221:
218:
211:
208:
205:
202:
199:
196:
193:
192:
191:
183:
180:
178:
174:
170:
166:
162:
158:
148:
146:
142:
138:
134:
129:
127:
124:and replaces
123:
119:
115:
111:
107:
103:
94:
90:
87:
84:
80:
73:
70:
67:
64:
63:
61:
57:
46:
42:
35:
32:
31:
29:
25:
19:
1184:. Retrieved
1180:
1164:. Retrieved
1160:
1144:. Retrieved
1140:the original
1135:
1119:. Retrieved
1115:
1099:. Retrieved
1095:
1082:
1062:. Retrieved
1058:the original
1048:
1039:
1030:
1018:. Retrieved
1016:. p. 49
1009:
1002:
990:. Retrieved
986:
973:
964:
959:
949:
948:
943:30 September
941:. Retrieved
931:
922:
913:
888:. Retrieved
884:
875:
863:. Retrieved
859:
849:
838:. Retrieved
834:the original
824:
804:
797:
772:. Retrieved
765:the original
752:
740:. Retrieved
738:. p. 11
730:
726:
719:
711:
704:. Retrieved
700:the original
695:
686:
678:
671:. Retrieved
667:
657:
631:. Retrieved
627:
617:
597:
578:
570:
559:
549:
543:
537:
533:
531:
491:
473:DO-254/ED-80
440:
431:
424:
415:Traceability
402:
398:
391:
387:
290:
286:
280:
274:
268:
262:
257:Catastrophic
256:
237:
233:
229:
227:
219:
215:
189:
181:
154:
130:
101:
100:
59:Organization
27:Abbreviation
18:
624:"Rtca, Inc"
544:The entire
304:Objectives
131:Except for
82:Predecessor
1199:Categories
1186:23 October
1166:23 October
1146:23 October
1121:23 October
1101:4 February
1064:2013-03-07
840:2010-09-18
774:2013-08-08
706:23 October
673:23 October
609:References
534:guidelines
457:achieved."
329:Hazardous
151:Background
145:AC 20-115C
51:2012-01-05
1020:5 January
992:3 October
729:evolution
481:ISO 26262
471:/ED-109,
281:No Effect
263:Hazardous
236:(DAL) or
1220:Avionics
890:17 April
865:17 April
783:cite web
643:cite web
633:7 August
628:Rtca.org
583:See also
538:guidance
95:Aviation
1181:Open DO
987:validas
908:level."
742:3 March
594:DO-248C
589:DO-178B
546:DO-248C
454:DO-178B
242:ARP4754
177:DO-248C
173:DO-278A
165:ARP4754
157:DO-178B
139:E, the
126:DO-178B
86:DO-178B
72:EUROCAE
49: (
33:DO-178C
1086:, 2023
939:. 2006
812:
515:DO-333
505:DO-332
499:DO-331
492:extend
477:DO-200
475:, and
469:DO-278
465:DO-330
357:Minor
343:Major
298:Level
217:only.
133:FAR 33
92:Domain
68:SC-205
36:ED-12C
1014:(PDF)
983:(PDF)
768:(PDF)
761:(PDF)
275:Minor
269:Major
122:EUROC
74:WG-12
1188:2010
1168:2010
1148:2010
1123:2010
1103:2014
1022:2015
994:2019
945:2009
892:2012
867:2012
810:ISBN
789:link
744:2022
708:2010
675:2010
649:link
635:2016
536:and
485:ECSS
248:and
228:The
112:and
110:EASA
66:RTCA
483:or
360:26
346:62
335:18
332:69
321:30
318:71
137:JAR
106:FAA
1201::
1179:.
1159:.
1134:.
1114:.
1094:.
985:.
947:.
900:^
883:.
858:.
785:}}
781:{{
734:.
710:.
694:.
677:.
666:.
645:}}
641:{{
626:.
596:,
411:.
377:0
374:0
368:E
363:2
354:D
349:5
340:C
326:B
312:A
108:,
1190:.
1170:.
1150:.
1125:.
1105:.
1067:.
1024:.
996:.
894:.
869:.
843:.
818:.
791:)
777:.
746:.
651:)
637:.
135:/
53:)
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.
