297:. As vendors and applicants employ Model-Based Development tools in the development of airborne software, concern arises about automation and elimination of levels of certification evidence. Arguments are made for careful designation of which Model-Based artifacts represent High-Level Requirements and which represent Low-Level Requirements. Finally, the standard DO-331 (Model-Based Development and Verification), supplement to DO-178C has clarified these aspects stating that high level requirements are requirements located prior to the model from which the model has been developed, the low level requirements being those located in the model itself. DO-331 having clarified the issue for model based development, the level-merging concerns of CAST-15 are not applicable to model based development.
556:... For the most part, software system requirements can be traced back to ... system requirements. Software requirements can be further broken down into high level requirements and detailed (low-level) requirements. High level requirements describe functional aspects of the system; i.e., they describe "what" is being designed. Low level requirements describe the actual design of the software; i.e., "how" the software is designed. Traceability ensures that all the requirements have been implemented as software functions (forward traceability) and, conversely, that all implemented functions are linked to a requirement (backward traceability).
24:
703:"DO-178B/C Differences Tool" Revision: 008, page 12, etc., 2013. "If the developer is proposing merging of high level and low level requirements, the ASE will find the justification and determine whether the reasoning supports a smooth transition between abstraction layers of system and the single level of requirements. Some indications where this may not be appropriate would be single system requirements tracing to an inordinately large number of merged high/low level requirements."
150:
interfaces, and details of internal software structures do not necessarily support that focus. On the other hand, those responsible for defining and verifying requirement coverage of all internal code need much finer details of internal software structures. This is the justification for DO-178B/C establishing distinct objectives for high-level and low-level requirements, with consideration for applicants developing additional requirement layering on large projects.
495:
applications. Applicants sometimes misuse this paragraph to justify producing a single level of requirements for complex software applications. This may result in a development process that does not comply with DO-178B. This was the topic of
Certification Authorities Software Team (CAST) positions paper CAST-15 …. A note was added to section 5 that the applicant may be required to justify software development processes that produce a single level of requirements.
775:"Software Considerations in Airborne Systems and Equipment Certification", p. 31. "Low-level requirements are software requirements from which Source Code can be directly implemented without further information." ... "However, if Source Code is generated directly from high-level requirements, then the high-level requirements are also considered low-level requirements and the guidance for low-level requirements also apply."
161:) would not expect any more or fewer requirement layers than necessary. However, the Certification Authorities’ experience was that some applicants misused or abused this intention, and as a result, such applicants discovered late in their projects that they were unable to demonstrate compliance and had to repeat some activities.
874:. In such cases, separate HLRs are just an artificially introduced level leading to "copy-and-paste development". Important to mention is that this workflow does not merge HLRs and LLRs, since the system requirements take over the role of HLRs including all necessary activities and objectives (cf. DO-331 MB.5.0). The concerns of
759:"Supporting Information for DO-178C and DO-278A", FAQ #81, pages 43-44. "When airborne software components are large or complex, the software requirements process produces the HLRs and the software design process produces the LLRs and architecture. Thus, HLRs and LLRs are not the outputs of the same development processes."
671:
and LLR separately, and merging the two may make this impossible. Note that although
Section 5 of DO-178C allows a single level of requirements, it is typically not done because it requires the system level requirements to contain additional detail to allow traceability to the combined HLR/LLR data item."
797:"Supporting Information for DO-178C and DO-278A", FAQ #81, pages 43-44. "There may be some systems where the system level requirements are refined into software requirements suitable for coding in one refinement step. In this case, a single level of software requirements may be feasible; however, ...."
670:
Raymond G. Estrada, Eric
Dillaber, Gen Sasaki, "... . This is because of the different purposes of each level of requirements; HLR state what the system software is to do, while the LLR state how it is done and what components are used to do it. Verification must be performed on the data for both HLR
368:
The DO-178B defines two levels of software requirements. The SW-HLR usually represents "what" is to be designed and SW-LLR represents "how" to carryout the design. .... This formalized design should contain sufficient details of such aspects as code structures and data/control flow for source code to
173:
In general, CAST Position Papers were issued to harmonize review of software projects conducted under DO-178B or DO-254. But, they were also intended to inform the development and eventual release of DO-178C and supporting publications. As much of the discussion and rationale recorded in the CASTs is
284:
provides a shorter list of certification concerns for combining (or merging) these two "what" and "how" levels into a single set of requirements without distinguishing the relevant certification objectives of the two levels. FAQ #81 also recommends against merging High-Level and Low-Levels even in
224:
provides guidance for merging High-Level and Low-Level
Software Requirements. Nominally, in the DO-178C/DO-178B context, the High-Level Requirements for a Certified Software Product are distinct from the Low-Level Software Requirements, the former being outputs of the Software Requirements Process
149:
Various stakeholders for software definition and verification have differing objectives and levels of abstraction. Those stakeholders responsible for defining or verifying high-level software product functionality are generally concerned with the structures and behaviors of the product's external
831:
In safety-related applications these principles usually drive the software requirement decomposition to two distinct levels. High-Level
Requirements (HLR) detail 'what is required' in the design. These are then systematically decomposed into Low-Level Requirements (LLR), which provide coders with
660:
Jamie P. White, Hassan Reza, p. 432. "The end goal is to place requirements in the requirements document that provides the most visibility to the stakeholders while preserving the scope of the document. Hence, there is a fine line between putting too much information in a high-level requirements
335:
DO-178B specifies that the software requirements should be organized into high-level and low-level software requirements. Also, the high-level software requirements should comply with the system requirements (objective 1 of table A-3 in appendix A), and the low-level software requirements should
494:
Another related issue is that DO-178B allowed for the possibility of a single level of requirements, in which case the high-level requirements are also considered low-level requirements. The intent was to avoid forcing the creation of two levels of requirements even for trivially simple software
256:
In some applications, the System/High-Level
Requirements are of sufficient simplicity and detail that the Source Code can be produced and verified directly. In this situation, the System/High-Level Requirements are also considered to be Low-Level Requirements, which means that, in addition to
164:
This is also an issue for any usage of development tools that potentially reduce the resolution of requirements in a project, particularly those that use notations of higher abstraction (e.g., UML or block flow modeling). Applicants using such tools generally are expected to declare if their
272:
making any indication of which requirements are High-Level and which are Low-Level, but also omitting traceability between the Low-Level and High-Level
Requirements and neglecting to identify derived requirements for feedback to System Processes, including System Safety.
276:
This
Position Paper discusses several problems and hazards that Certification Authorities see arising from merging Low-Level Requirements into the collection of High-Level Requirements, recommending that this not be done. The replacement content published in FAQ #81 in
193:
The FAQ was originated by
European Certification Authorities who were concerned with the risk of applicants developing untraceable and unverifiable gaps in their requirements, and it does not recommend merging high and low levels of requirements into a single
693:
Frédéric Pothon, ACG Solutions, "DO-178C/ED-12C versus DO-178B/ED-12B - Changes and
Improvements", 2012. "The main concern is possible gaps in the requirement refinement, which prevent a sufficient traceability analysis and thus compliance with verification
137:
This position paper is concerned with observed misuse of this guidance; some applicants were combining High-Level and Low-Level Requirements for "simple" products, but were not accomplishing all of the related objectives for both levels of requirements.
832:
information on 'how to implement' that design. To minimize ambiguity LLR often include pseudo-code or mathematical formulae. ... Certification Authorities Software Team (CAST). 2003. Merging High-Level and Low-Level Requirements.
869:
Example 4 is reasoned with the higher abstraction of Design Models compared to LLRs. For example, traditional HLRs often contain figures of state diagrams or truth tables. These diagrams are very close to the implementation in
340:
Low-level requirements: Software requirements derived from high-level requirements, derived requirements, and design constraints from which source code can be directly implemented without further information.
713:
141:
This position paper is also an example of Certification Authorities using their "what" versus "how" distinction between high-level and low-level requirements that DO-178B/C does not clearly explain.
130:
DO-17B/C assigned different sets of objectives to these two levels of requirements. To accomplish compliance, the Applicant needs to fulfill both sets of objectives with their requirements. However,
285:
cases where the code can be written and verified in a "single step" of requirements as the original DO-178B/C guidance allows, but does offer suggestions on how to address concerns.
893:
455:... warn against merging software requirements into a single level. There are a few projects where one level of software requirements is needed (...) but they are in the minority.
197:
The note "The applicant may be required to justify software development processes that produce a single level of requirements." was added to DO-178C Section 5.0, page 31.
647:
381:
240:
Low-Level Requirements are the results of decomposition and elaboration of requirements such that the source code may be produced, reviewed, and tested
92:
publication that "does not constitute official policy or guidance from any of the authorities", but is provided to applicants for software and hardware
165:
development processes use such tool's notation the role of describing either high-level requirements or low-level requirements, but usually not both.
338:
High-level requirements: Software requirements developed from analysis of system requirements, safety-related requirements, and system architecture.
134:, that standard's guidance permits combination of these two levels into just one level of requirements, but warns against the practice in general.
85:
53:
616:
257:
accomplishing the objectives for High-Level Requirements, the same requirements must also accomplish the objectives for Low-Level Requirements.
560:... FAA Certification Authorities Software Team (CAST), Merging High-Level and Low-Level Requirements, Position Paper, CAST-15, February 2003
724:
583:
549:
487:
404:
205:
260:
The concern that prompted CAST-15 is that some applicants for software certification interpreted the above guidance as permitting combining
615:
Raymond G. Estrada, Eric Dillaber, Gen Sasaki (2013). "Best practices for developing DO-178 compliant software using Model-Based Design".
509:
Rierson, p. 113, "In order to avoid this slippery slope, I suggest that engineers ... Clearly define the division between requirements (
265:
558:
For an interesting discussion on this topic the reader may look at a short position paper issued by the Federal Aviation Administration
530:
Volponi, Allan J.; Rajamani, Ravi (2012). "12. Hybrid Models for Engine Health Management". In Ashok N. Srivastava, Jiawei Han (ed.).
23:
177:
This CAST-15 Position Paper is no longer provided on the FAA's publications site as the team's concerns were addressed by FAQ #81 in
438:
475:
Advances in Systems Safety: Proceedings of the Nineteenth Safety-Critical Systems Symposium, Southampton, UK, 8-10th February 2011
472:
Daniels, Dewi (January 1, 2001). "Are we there yet? A practitioners View of DO-178C/ED-12C". In Chris Dale, Tom Anderson (ed.).
324:
158:
784:
Raymond G. Estrada, Eric Dillaber, Gen Sasaki, "Merging the HLR and LLR into a single model or data item is not recommended ."
923:
602:
high-level requirements document should describe the "what" and a low-level requirements document should describe the "how".
336:
comply with the high-level software requirements (objective 1 of table A-4 in appendix A). These are defined in DO-178B as
201:
However, neither DO-248C nor DO-178C completely incorporates the "full discussion of this topic" that is recorded CAST-15.
315:
352:
Johnny Cardoso Marques, Sarasuaty Megume Hayashi Yelisetty, Luiz Alberto Vieira Dias, Adilson Marques da Cunha (2012).
933:
229:
High-Level Requirements are essentially those System Requirements that are allocated to the Software Product (an
572:
Jamie P. White, Hassan Reza (2012). "Deriving DO-178C Requirements Within the Appropriate Level of Hierarchy".
294:
736:
The following sections of the guidance of this Certification Memorandum do not correspond to the contents of
354:"Using Model-Based Development as Software Low-Level Requirements to Achieve Airborne Software Certification"
293:
The distinction between, or combination of, High-Level and Low-Level Requirements is a particular issue with
928:
573:
174:
not included in the newer publications, the CASTs remain a source of insight into the updated standards.
375:
124:
737:
369:
be produced directly from it, either manually or by the use of a tool, without any further information.
209:
634:
the HLR generally represent "what" is to be designed and LLR represent "how" to carry out the design.
411:
DO-178B is unique among software "standards" in that it requires two or more levels of requirements.
479:
426:
Developing Safety-Critical Software: A Practical Guide for Aviation Software and DO-178C Compliance
641:
913:
579:
545:
537:
483:
434:
400:
153:
However, DO-178B allowed for the possibility of developing only one level of requirements for
108:
93:
67:
918:
897:
204:
Much of the same content of the original CAST-15 Position Paper is published in the 2012
575:
ICSEA 2012 : The Seventh International Conference on Software Engineering Advances
115:
software. Unique among development standards, DO-178B introduced a distinction between
907:
852:
353:
112:
533:
Machine Learning and Knowledge Discovery for Engineering Systems Health Management
473:
424:
264:
High-Level Software Requirements and Low-Level Software Requirements in a single
632:
According to Position Paper CAST-15 (Certification Authorities Software Team) ,
397:
Avionics Certification, A Complete Guide to DO-178 (Software) DO-254 (Hardware)
531:
871:
661:
document and providing an appropriate amount of visibility to stakeholders."
541:
430:
100:
854:
Modular model-based development of safety-critical flight control software
808:
63:
794:
772:
756:
744:... Section 21, Merging High-Level and Low-Level Requirements (CAST 15)
278:
221:
186:
178:
104:
878:"Merging High-Level and Low-Level Requirements" are not applicable.
600:
position paper provides guidance that for software requirements a
742:
but they do correspond to the contents of existing CAST Papers
225:
and the latter being outputs of the Software Design Process.
89:
317:
DOT/FAA/AR-08/32 Requirements Engineering Management Handbook
212:(Section 23 Merging High-Level and Low-Level Requirements).
451:... Certification Authorities Software Team (CAST)* paper
358:
Conference: Information Technology: New Generations (ITNG)
497:
A full discussion of this topic may be found in CAST-15.
618:
AIAA Guidance, Navigation, and Control (GNC) Conference
680:
Rierson, p. 113, "DO-248C's FAQ #81 ... and the ...
252:
the Software Product shall be implemented to do it).
185:and by changes and clarification in the release of
157:systems. That is, Certification Authorities (e.g.,
59:
49:
41:
33:
900: (archived 2017-08-29). Retrieved 2021-12-03.
525:
523:
96:for educational and informational purposes only.
536:. Data Mining and Knowledge Discovery Series.
399:. Leesburg, VA: Avionics Communications, Inc.
282:Supporting Information for DO-178C and DO-278A
183:Supporting Information for DO-178C and DO-278A
767:
765:
314:David L. Lempia and Steven P. Miller (2009).
81:Merging High-Level and Low-Level Requirements
17:Merging High-Level and Low-Level Requirements
8:
809:"Requirements Assurance in Machine Learning"
646:: CS1 maint: multiple names: authors list (
380:: CS1 maint: multiple names: authors list (
99:As established by the FAA advisory circular
16:
237:the full Software Product shall be and do).
159:FAA-Designated Engineering Representatives
22:
15:
467:
465:
463:
125:software requirements analysis and design
395:Vance Hilderman and Tony Baghai (2007).
860:. Universitätsbibliothek der TU München
306:
86:Certification Authorities Software Team
54:Certification Authorities Software Team
822:(paper 8). CEUR Workshop (CEUR-WS.org)
639:
373:
7:
423:Leanna Rierson (19 December 2017) .
244:from the Low-Level Requirements (an
127:when developing airworthy software.
851:Markus Tobias Hochstrasser (2020).
807:Alec Banks and Rob Ashmore (2019).
714:"Software Aspects of Certification"
14:
88:(CAST) Position Paper. It is an
325:Federal Aviation Administration
107:defines an acceptable means of
266:software requirements document
1:
950:
839:, completed February 2003.
816:CEUR Workshop Proceedings
21:
723:(CM-SWCEH-002 Issue 1).
721:Certification Memorandum
295:Model-based development
289:Model-based development
132:under narrow conditions
117:High-Level Requirements
103:, the RTCA publication
876:Position Paper CAST-15
123:as formal products of
121:Low-Level Requirements
924:Software requirements
480:Springer Publishing
208:Certification Memo
155:particularly simple
18:
934:Computer standards
727:: 12. 9 March 2012
538:Chapman & Hall
268:or other artifact
68:type certification
738:FAA Order 8110.49
596:In addition, the
585:978-1-61208-230-1
551:978-1-4398-4179-2
489:978-0-85729-132-5
406:978-1-885544-25-4
210:EASA CM-SWCEH-002
187:DO-178 Revision C
73:
72:
941:
881:
880:
866:
865:
859:
848:
842:
841:
828:
827:
813:
804:
798:
791:
785:
782:
776:
769:
760:
753:
747:
746:
733:
732:
718:
710:
704:
701:
695:
691:
685:
678:
672:
668:
662:
658:
652:
651:
645:
637:
629:
628:
623:
612:
606:
605:
593:
592:
569:
563:
562:
527:
518:
507:
501:
500:
469:
458:
457:
448:
447:
420:
414:
413:
392:
386:
385:
379:
371:
365:
364:
349:
343:
342:
332:
331:
322:
311:
26:
19:
949:
948:
944:
943:
942:
940:
939:
938:
904:
903:
898:Wayback Machine
890:
885:
884:
863:
861:
857:
850:
849:
845:
834:Position Paper
825:
823:
811:
806:
805:
801:
792:
788:
783:
779:
770:
763:
754:
750:
730:
728:
716:
712:
711:
707:
702:
698:
692:
688:
679:
675:
669:
665:
659:
655:
638:
626:
624:
621:
614:
613:
609:
590:
588:
586:
578:. p. 432.
571:
570:
566:
552:
544:. p. 299.
529:
528:
521:
508:
504:
490:
482:. p. 299.
471:
470:
461:
445:
443:
441:
433:. p. 114.
422:
421:
417:
407:
394:
393:
389:
372:
362:
360:
351:
350:
346:
339:
337:
329:
327:
320:
313:
312:
308:
303:
291:
218:
171:
147:
29:
28:FAA Publication
12:
11:
5:
947:
945:
937:
936:
931:
929:RTCA standards
926:
921:
916:
906:
905:
902:
901:
889:
888:External links
886:
883:
882:
843:
799:
786:
777:
761:
748:
705:
696:
686:
673:
663:
653:
607:
584:
564:
550:
519:
513:) and design (
502:
488:
459:
439:
415:
405:
387:
344:
305:
304:
302:
299:
290:
287:
254:
253:
238:
217:
214:
199:
198:
195:
170:
167:
146:
143:
71:
70:
61:
57:
56:
51:
47:
46:
43:
39:
38:
35:
31:
30:
27:
13:
10:
9:
6:
4:
3:
2:
946:
935:
932:
930:
927:
925:
922:
920:
917:
915:
912:
911:
909:
899:
895:
892:
891:
887:
879:
877:
873:
856:
855:
847:
844:
840:
838:
837:
821:
817:
810:
803:
800:
796:
790:
787:
781:
778:
774:
768:
766:
762:
758:
752:
749:
745:
743:
739:
726:
722:
715:
709:
706:
700:
697:
690:
687:
683:
677:
674:
667:
664:
657:
654:
649:
643:
636:
635:
620:
619:
611:
608:
604:
603:
599:
587:
581:
577:
576:
568:
565:
561:
559:
553:
547:
543:
539:
535:
534:
526:
524:
520:
516:
512:
506:
503:
499:
498:
491:
485:
481:
477:
476:
468:
466:
464:
460:
456:
454:
442:
440:9781351834056
436:
432:
428:
427:
419:
416:
412:
408:
402:
398:
391:
388:
383:
377:
370:
359:
355:
348:
345:
341:
326:
319:
318:
310:
307:
300:
298:
296:
288:
286:
283:
280:
274:
271:
267:
263:
258:
251:
247:
243:
239:
236:
232:
228:
227:
226:
223:
215:
213:
211:
207:
202:
196:
192:
191:
190:
188:
184:
180:
175:
168:
166:
162:
160:
156:
151:
144:
142:
139:
135:
133:
128:
126:
122:
118:
114:
110:
109:certification
106:
102:
97:
95:
94:certification
91:
87:
83:
82:
77:
69:
65:
62:
58:
55:
52:
48:
44:
40:
36:
32:
25:
20:
875:
868:
862:. Retrieved
853:
846:
835:
833:
830:
824:. Retrieved
819:
815:
802:
789:
780:
751:
741:
735:
729:. Retrieved
720:
708:
699:
694:objectives."
689:
681:
676:
666:
656:
633:
631:
625:. Retrieved
617:
610:
601:
597:
595:
589:. Retrieved
574:
567:
557:
555:
532:
514:
510:
505:
496:
493:
474:
452:
450:
444:. Retrieved
425:
418:
410:
396:
390:
376:cite journal
367:
361:. Retrieved
357:
347:
334:
328:. Retrieved
316:
309:
292:
281:
275:
269:
261:
259:
255:
249:
245:
241:
234:
230:
219:
203:
200:
182:
176:
172:
163:
154:
152:
148:
140:
136:
131:
129:
120:
116:
98:
80:
79:
75:
74:
50:Organization
42:Year started
34:Abbreviation
908:Categories
864:2022-07-09
826:2022-07-09
731:2023-04-19
627:2022-02-08
591:2022-02-08
446:2022-02-14
363:2022-07-09
330:2022-07-09
301:References
145:Background
642:cite book
542:CRC Press
431:CRC Press
113:airworthy
105:DO-178B/C
101:AC 20-115
914:Avionics
517:) .... "
248:view of
242:directly
233:view of
220:DO-178C/
216:Contents
64:Avionics
896:at the
894:CAST-15
836:CAST-15
795:DO-248C
773:DO-178C
757:DO-248C
682:CAST-15
598:CAST-15
453:CAST-15
279:DO-248C
270:without
231:outside
222:DO-178B
179:DO-248C
76:CAST-15
37:CAST-15
919:Safety
582:
548:
486:
437:
403:
246:inside
194:level.
169:Status
60:Domain
858:(PDF)
812:(PDF)
793:RTCA/
771:RTCA/
755:RTCA/
717:(PDF)
622:(PDF)
321:(PDF)
84:is a
820:2301
725:EASA
648:link
580:ISBN
546:ISBN
511:what
484:ISBN
435:ISBN
401:ISBN
382:link
262:both
235:what
206:EASA
119:and
45:2003
515:how
250:how
111:of
90:FAA
910::
872:SF
867:.
829:.
818:.
814:.
764:^
740:,
734:.
719:.
644:}}
640:{{
630:.
594:.
554:.
522:^
492:.
478:.
462:^
449:.
429:.
409:.
378:}}
374:{{
366:.
356:.
333:.
323:.
189::
181:,
78:,
66:,
684:"
650:)
540:/
384:)
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.
