WIXLIB

Although OOT is intended to promote productivity,increase reusability of software, and improve quality,uncertainty about how to comply with certificationrequirements has been a key obstacle to using OOTin airborne systems.Due to this difficulty in applying ED-12B/DO-178B tothe OOT domain, the FAA co-sponsored the ObjectOriented Technology in Aviation (OOTiA) projectwith the National Aeronautics and SpaceAdministration (NASA) to address OOT challengesin aviation. The FAA, NASA, and other organizationsdeveloped workshops and this workshop committeeproduced a handbook specifically addressing objectoriented technology. [4]Issues with the technology that arose that weredifficult to apply with ED-12B/DO-178B were the useof dynamic memory allocation / deallocation that isused in OOT primarily because it challenges thedeterministic characteristics of airborne systems.Likewise traceability of the design and code, key ive, is difficult to demonstrate with OOTapproaches.4. Model Based DesignModel based design holds the hope of alleviating theburden of the costly development of today’s aviationsystems. Flight test or even tests conducted inspecial test equipment rigs are extremely costly andin many cases permit only ‘black box’ testing of theproduct under development, which typically does notfully test the robustness of the product.If we can build a perfect model of the environmentthat the product will operate in, then we can morerobustly test the product, its modes of operation andhow it will detect and accommodate faults inducedby the environment.The “if” of the previous paragraph is in bold, andjustifiably so, as it is a very big ‘if’. If we can build aperfect model, then we could take credit for testingwith that model and reduce the costly flight or rig testthat are currently performed. And yet although weknow that it is not likely, if we could build a perfectmodel, how would you determine the pedigree of themodel? This is one aspect of product developmentthat ED-12B/DO-178B did not address and as suchclarification in this area is needed.5. Formal MethodsFormal methods have always held the intrigue thatwe would be able to build a system so precise andexact that we know it would be correct. Thefoundations for such a claim are based on thespecification of the system in a mathematical sense.Rushby defines formal methods as mathematicallybased techniques for the specification, developmentand verification of software and hardware systemsthat are based on formal logic, discrete mathematics,and computer-readable languages.[5] Formalmethods allow properties of a system to be predictedfrom a mathematical model of the system.We can think of formal methods in two parts, formalspecification and formal verification. In formalspecification we see the use of mathematics-basedlanguages that provide precise, unambiguousdescriptions of requirements and other developmentobjects. In formal verification, we see deduction orproof that relies on a discipline that requires theexplicit enumeration of all assumptions s model checking, which is the processof automatically checking whether a given finitemodel of an object satisfies a given property.Formal methods generally constitute a specificationlanguage and an accompanying tool or set of toolsthat are consistent, complete, and not ambiguous.The benefits promised by such languages and toolsare the anticipated improvement of requirementquality, the reduction of specification errors and thepermitting of verification techniques, which fullyexplore the behavior of a design.Yet there are acknowledged limitations, such as notbeing able to fully establish the verification evidencefor compatibility with the target hardware. Formalmethods further cannot ensure that a formallyspecified requirement correctly meets its non-formalparent requirement(s) and it cannot verify anythingthat is not explicitly stated as a property. Along withthis is a fear that formalizing requirements or designsmay increase the effort required to specify them,particularly for complex systems. And finallyalthough we would like to think we could preciselyspecify the system, somewhere in the life cycle,there will be at least some bit of informality. Theassumptions made in translating requirements ordesigns from the informal to the formal may not beclear, or may misrepresent to some degree asufficient model of the real system."Traditional software development methods rely onhuman inspection and testing for validation andPage 3/5

verification. Formal methods also uses testing, butthey employ notations and languages that areamenable to rigorous analysis, and they exploitmechanical tools for reasoning about the propertiesof requirements, specifications, designs, and code.Practitioners have been skeptical about thepracticality of formal methods. Increasingly,however, there is evidence that formal methods canyield systems of very high dependability in a costeffective manner, ."[6]ED-12B/DO-178B holds very little guidance in thearea of formal methods. Formal methods are merelyrecognized as alternative methods that admittedlyhave limited applicability to the airborne communityat the time when ED-12B/DO-178B was written.When using formal methods different forms ofevidence may be used to substantiate its suitabilityin order to meet the intent of certain objectives fromED-12B/DO-178B, rather than the actual objectives.If a process is used to satisfy ED-12B/DO-178B thatprovides different evidence and does not directlymeet the objectives, there is a need to demonstrateclearly that the alternate process is equivalent. e with such a ‘meet the intent’approach, and as such have been reticent toembrace formal methods as a recognized practicefor airborne system and equipment development.7. Software Development and Verification ToolsWe have all recognized that developing systemswithout the assistance of computerized tools wouldbe impossible. And the range of sophistication ofthese tools is broad. ED-12B/DO-178B encouragesthe use of such tools, but is cautious when the toolsare used to reduce or eliminate the objectives setforth in ED-12B/DO-178B.ED-12B/DO-178B divides tools that take some formof ‘credit’ for an objective into two categories, that is,those tools (development) that can directly affect thetarget software such as an auto-code generator tool,and those tools (verification) that can affect theverification of the target system. ED-12B/DO 178Bstates that development type tools must be createdto the same rigor as that software criticality level ofthe target system. It is clear that ED-12B/DO-178Bwants to assure that any tool taking credit forobjectives has been qualified, such that its operationis correct and can be relied upon. A similar approachis taken for verification tools, but the rigor issomewhat less.The cost for developing tools to this rigor can berather high and it has made tool developers reluctantto provide their tools as ‘qualified’ to this levelbecause of this cost burden. As such, airbornesystem developers are left with further burdensomeand costly development practices because theycannot take credit for using the tool. The industryhas recognized that further guidance in the use ofdevelopment and verification tools to reduce systemdevelopment costs is in order to permit a more costeffective development yet still one that would yield asafe system.[4]8. Integrating New Technologies in LegacyGuidanceSince ED-12B/DO-178B’s inception in 1992, it hasbecome the foundation for all aviation-basedsystems that contain software components. Its trackrecord is exceptional as noted before and as suchthe industry has been reluctant to make significantchanges to it. An example of this is the workconducted by joint SC-190/WG-52, which clarifiedsome of the issues with ED-12B/DO-178B, but wasnot permitted to change the core ED-12B/DO-178Bdocument.Even today, joint committee SC-205/WG-71 is tryingto address the new technology needs of tools, formalmethods, model-base design and object orientedtechnology yet in a manner that limits somewhat thescope of change to ED-12B/DO-178B.The question arises is how can we keep the coretenants of successful guidance such as ED-12B/DO178B yet still meet emerging technology needs?Further questions arise with regards to newtechnologies that may not even be recognized asviable approaches for the aviation domain. Thesolution that SC-205/WG-71 has devised is tominimally modify the core of ED-12B/DO-178B andprovide a technology supplement that has a specificinterface specification to the core document andobjectives.The approach taken is to amend the core documentin such a way as to be receptive to the introductionof new technology. This is being accomplished bythe production of a technology interfacespecification, which will define what must beaddressed in a technology supplement to sufficientlyaddress the new guidance a technology supplementmay provide. Figure 2 pictorially shows theapproach. Any issues that were raised with ED12B/DO-178B were recorded in an issue list and thefour aforementioned technologies were included onthis issue list. The four technology supplements arebeing developed by sub-groups internal to SC205/WG-71 that holds specialists in those areas oftechnology with a firm knowledge of the aviationdomain and approval authority process. Each of thePage 4/5

supplements being developed has participation fromthe certification authorities such that the guidancebeing developed will be one that the certificationauthorities can embrace.6. AcknowledgementThe author acknowledges the contribution of ScottBeecher of Pratt & Whitney in the preparation of thiswork and the efforts of joint SC-205/WG-71 thathave been developed to date.7. References[1][2][3][4][5][6]Figure 2: Technology Integration in Core rations in Airborne Systems and EquipmentCertification", RTCA, 1992.SC-190/WG-52 ED-94B/DO-248B "Final Report fortheClarificationofDO-178BSoftwareConsiderations in Airborne Systems and EquipmentCertification", RTCA, 2001.FAA: "Handbook for Object Oriented Technology inAviation (OOTiA)", FAA Software Publication, Vols1-4, FAA, 2004.SC-205/WG-71 SG3: “Draft Tools Supplement",Unpublished, 2007.Rushby: “Formal Methods and the Certification ofCritical Systems", 1993.Unpublished, 2007. [Ref. Software for DependableSystems: Sufficient Evidence? Daniel Jackson,Martyn Thomas, and Lynette I. Millett, Editors,Committee on Certifiably Dependable SoftwareSystems, National Research Council, 2007]5. ConclusionA guidance document for developing software inairborne systems and equipment, namely ED12B/DO-178B has become deeply ingrained in thoseorganizations that develop such products. Thisguidance has become a common ground for theunderstanding of developing, verifying, integratingand approving this software such that there is a highlevel of confidence in the deployed system’s ability toperform its tasks safely.As new approaches and technologies arise in thesoftware development domain of such embeddedsystems an effective means for integrating thesetechnologies to the core tenets of ED-12B/DO-178Bhas occurred. Specific areas being worked entTechnology,ObjectOrientedTechnology and Formal Methods. The approachtaken is to develop technology supplements thatabide to an overall core document interfacespecification such that the core document caneffectively be applied to the new technology.8. GlossaryCCAEASAEUROCAEFAAFHANASAOOTCommon Cause AnalysisEuropean Aviation Safety AgencyEuropean Organization Civil EquipmentFederal Aviation AdministrationFunctional Hazard AnalysisNational Aeronautical Space AgencyObject Oriented TechnologyOOTiAObject-Oriented Tech. in AviationPSACPSSASCMPSDPSQAPSSASVPPlan for Software Aspects of CertificationPreliminary System Safety AssessmentSoftware Configure Management PlanSoftware Development PlanSoftware Quality Assurance PlanSystem Safety AssessmentSoftware Verification PlanThis approach of developing supplemental guidanceto a core guidance document such as ED-12B/DO178B provides a basis for keeping pace with newemergent technologies without the need to rewritethe core document as these new technologiesemerge.Page 5/5

require elaboration of how the ED-12B/DO-178B objectives will be met. 3. Object Oriented Technology Compliance with the objectives of ED-12B/DO-178B is the primary means of obtaining approval of software used in civil aviation products. In 1992, when ED-12B/DO-178B was born, procedure programming was the predominant technique for