Tag Archives: avionics

“263 Registrants” to AFuzion’s Virtual DO-178C Training with SAE April 16, 2020: New World Record.

18 Apr

While the worldwide pandemic negatively impacts many lives, surprising transformations abound. On April 18, 2020, AFuzion and SAE sponsored Virtual DO-178C Training with 263 Registrants. Says D. Chapman, U.S. Army “Our Army colleagues have tried many training companies and trainers: always AFuzion’s training is far the highest rated at 4.93 out of 5. SAE/AFuzion’s new virtual DO-178C Training and DO-254 Training were again the best – no exception.”

AFuzion’s DO-178C and DO-254 training were solely selected by the world’s largest independent aviation safety group, Society of Aerospace Engineers (SAE) for worldwide venues. Now also offered in Virtual Remote format, this week’s 263 registrants to the latest DO-178C virtual training proved the strength of AFuzion: over 25,000 engineers trained worldwide: 3X more than all other trainers in the world, COMBINED.

States Philip J of GE Aviation, UK “The consensus among the attendees I’ve talked with is that you delivered the best technical training we’ve ever received, so I hope you take great pride in hearing the impact you have made is overwhelmingly positive.” AFuzion’s trainers provided the world’s first known DO-178 public training in 1989 and since then have refined the proprietary DO-178C training materials to include the highest quality visual and oral explanations of DO-178C’s optimized application for EVTOL, UAV’s, Civil, and Military aircraft.

Adds AFuzion’s Aharon David: “The post-virus environment will forever change training and services delivery. AFuzion’s 50+ aviation engineers have always worked 60% remotely to simply optimize time and reduce client travel costs. It was a simple matter to evolve our dozen’s of different aviation training courses, auditing, and mentoring to a remote, virtual format: our IT infrastcture and knowledge have been been used for tens of thousands of hours remotely already. Getting 263 registrants to this week’s SAE/AFuzion DO-178C Training course simply proved that.”

For details on AFuzion’s virtual remote training, simply request from AFuzion a list of their 65+ courses, or review the syllabus of the dozen most popular courses here: https://afuzion.com/private-training/ For a free sample of AFuzion’s DO-178C training, DO-326A Cyber-Security Training, DO-254 Training, or ARP4754A Training, watch free videos here: https://www.youtube.com/playlist?list=PL0es63yi1vbw9Tt1GWX8TtiFm4R2qRryu

AFuzion / SAE’s next virtual online DO-178C training will be May 12-15, 2020 (4 hrs/day), Register here: https://www.sae.org/learn/content/c1410/

AFuzion / SAE’s next virtual online DO-254 training will be May 19-22, 2020 (4 hours per day), Register here: https://www.sae.org/learn/content/c1703/

AFuzion /SAE’s next virtual online DO-326A training will be June 1-4, 2020 (4 hours per day), Register here: https://www.sae.org/learn/content/c1949/

In the meanwhile, promote safety and health: just like your aviation projects.

AFuzion Wins Major Asian World-wide Aviation Services Contract (and Other News)

12 Jul

AFuzion is proud to win Asia’s world-wide competition for Avionics Development Services.

One of Asia’s largest aviation development companies  conducted a 2019 worldwide search for the best avionics development services company and chose … AFuzion.   Photo here of a few of their engineers at the first AFuzion meeting. This marks AFuzion’s 7th new Asian client in just the past six months.  AFuzion’s services include mentoring, consulting, DO-178C training and certification, DO-254 training and certification, and ARP4754A Systems/Safety deployment.  Also, AFuzion’s recently updated DO-178C Templates/Checklists and DO-254 Templates/Checklists are now in wide use worldwide, with over 7,000 engineers using them today … and growing.  In the past month, AFuzion has hired four new engineers:  all senior aviation, avionics, and safety veterans with 20+ years applied expertise each.  With all this growth comes additions to the corporate AFuzion office also:  a big welcome to Heather M in Web/Design, Matthew Kendall in Human Resources, and Davis Powell in Internal Operations – keep up all the great attitudes and hard work.

Also, thank you to everyone for requesting  new aviation development terms/explanations be added to our website. We followed your suggestions and added those terms along with AFuzion’s concise explanation for each. The updated AFuzion Tech Terminology for Aviation explanation page is updated and live here:  https://afuzion.com/tech-info/  

Also, AFuzion has added three new technical aviation development training courses on RTOS’s, Multi-Core Computing / CAST-32A, and AS9115A Quality Systems Management.  Each of these courses has been given at least three times in 2019 so far so thanks to all for suggesting we add these courses as well – keep your suggestions coming and AFuzion will do its best to follow-up.  AFuzion Aviation Development Training course information is available here: https://afuzion.com/training/

Finally, the annual IEEE Digital Avionics Systems Conference (DASC)  is coming to USA’s  San Diego September 8-11. North America’s largest avionics development technical conference with 50+ presentations, 15+ Tutorials, and amazing guest speakers/panels covering all the important topics.  Details here: https://2019.dasconline.org/pages/tutorial-schedule

AFuzion In Korea: YB Cho Presents AFuzion’s DO-178C / DO-254 Gap Analysis in Seoul

7 Jul

Mr. YB Cho of SOaR in Korea presented AFuzion’s DO-178C and DO-254 Services at Korea’s largest aerospace conference – July 2019. Say’s Mr. Cho “AFuzion’s world-reknowned DO-178C, DO-254, and ARP4754A services are well received and deployed in Korea. SOaR is pleased to be working with AFuzion bringing even more avionics certification services to Korea.” Additional details are found on the AFuzion homepage: https://afuzion.com/

Mr. YB Cho in Seoul Presenting AFuzion’s Solutions in Seoul’s largest aviation conference

Korea is a strong and growing aviation market, serving both military and civil aviation. Koreans favor DO-178C cost-efficiency and DO-254 fast time to market, so AFuzion’s ready-made DO-178C and DO-254 Templates for Plans, Standards, and Checklists are ideally suited to the Korean market. Korean companies have strong engineering, but appreciate AFuzion’s DO-254 Gap Analysis and DO-178C Gap Analysis to understand and then optimally close those gaps. Additional AFuzion Gap Analysis details are found here: https://afuzion.com/gap-analysis/

Adds AFuzion’s Vance Hilderman “AFuzion travels frequently to Korea, China, Singapore, Japan, and Malaysia to work with our clients there. In Korea, we’re very pleased to have Mr. YB Cho as our colleague. Our old technical whitepapers are widely distributed in Korea from folks who like yesterday’s old technology and don’t have their own, but the new AFuzion avionics development/certification whitepapers are freely downloaded from AFuzion’s site. Koreans (and the rest of the world) prefer the latest DO-178C and DO-254 information which is available freely on AFuzion’s site for download here: https://afuzion.com/avionics-safety-critical-training-whitepapers/

Santa, All We Want For New Year 2019 is … Seven More Avionics Engineers!

4 Jan

OK, time for honesty:  did everyone get what they wanted from Santa Claus ten days ago?!?   Yes, Santa was good for everyone here at AFuzion Inc. with our record-breaking year doubling last year’s $ results.  But one thing (actually seven things) were missing from under the Tree … yes, Engineers.

You see, we’ve been steadily increasing staff here the past five years to keep up with our growing business in 25 countries.  At our December planning meeting, we actually wrote a letter to Santa asking him ” Santa, please bring us 9 more engineers. To start work Jan 7, 2019.”  Really.  Now folks, all of us either have children, know children, or are still children.  My kids even say I’m just a big child during the holidays.  We BELIEVE in Santa Claus. (Santa, are you listening?)  When we were kids, we usually got some of what we wanted.  But this year, Santa only brought us two engineers.  2.  T-W-O.    Santa, can you spell “N I N E”?  As in “9”.  We asked for 9.  We got 2.

Santa, do you not do math at the North Pole?  When Susie or Johnnie ask for a new bike, do you simply bring them one tire?  Yes, the two engineers you brought were great. Really.  Truly.  Top 10% of their field which is our minimum standard.  Thank you Santa.  But again we asked for Nine.  We got TWO …

Santa, if you are listening, we won’t tell anyone if you secretly make another trip to our chimney and bring us seven more engineers.  Yes, these are for the USA so must be USA citizens.  Yes, these are for the western USA so hopefully they want to live in Los Angeles, Phoenix, or Dallas.  Please Santa, if you can’t bring the engineers directly to us, please just send us their contact info or CV to our email at info@afuzion.com.  Otherwise Santa, we’re going to spread the word that you sleep in funny red pajamas and live off cookies, milk, and … reindeer meat.  Santa, really.  Lay off the reindeer – just send us great Engineers please. ASAP!!!

Yours truly,

All the Engineers (Elves) at AFuzion Inc.

AFuzion Launches New CAST-32A Multi-Core Processing Training

18 Nov

AFuzion’s new CAST-32A Multi-Core Processing for Avionics and Safety-Critical developers has launched with strong acclaim. The future of embedded processing is via multi-core processors as the need for added processing power has surpassed the ability of CPU’s to keep up. However, multi-core processors utilize shared cache, shared memory, and shared communications I/O. This sharing between the MCP cores produces potential interference which can violate the very “determinism” requisite for certifiable safety-critical systems. For example, avionics DO-178C and DO-254 require adherence to CAST-32A recently updated by the worldwide Certification Authorities Software Team (CAST).

CAST-32A is the worldwide (America, Europe, Asia) Certification Authorities Software Team (CAST) guidance for ensuring safe implementation of Multi-Core Processing (MCP) within avionics systems. Increasingly MCP’s are used in avionics and understanding what must be done to plan for, implement, and verify deterministic “safe” MCP development via CAST-32A is the focus of this AFuzion 2-day private training course. Attendees will understand how to utilize multiple-cores providing simultaneous operations using deterministically shared resources such as cache, memory, and communications and performing MCP CAST-32A Interference Analysis. Attendees will also learn how to work with RTOS vendors and RTOS’s themselves to comply with CAST-32A and develop safer avionics.  For a free technical whitepaper on CAST-32A, download here: Click Here for Free AFuzion Technical Whitepaper “Understanding CAST-32A


CAST-32A is increasingly relevant to avionics developers but users find it vague and challenging to understand. AFuzion’s 2-day CAST-32A Training teaches attendees how to properly understand, deploy, and verify MCP-based applications. AFuzion’s training was recently provided with our industry partner Lynx Software to 45 senior MCP developers in Huntsville Alabama and it was a resounding success; all the attendees stated it was highly worthwhile and crisply delivered to provide a true practical understanding of CAST-32A deployment for avionics via DO-178C and DO-254. AFuzion’s CAST32A training syllabus is summarized below, with full details at AFuzion’s website, https://afuzion.com/training/cast-32a-multi-core-processing-training/



  • CAST-32A Introduction
  • Summary of DO-178C, for Multi-Core usage
  • RTOS Introduction & Scheduling, Processes, Tasks, and Threads
  • MCP What & Why
  • DO-178C & MCP – Plans, Standards, Activities
  • CAST-32A MCP Robust Partitioning Principles
  • RTOS Specifics – Technical Info
  • DO-254 & MCP
  • MCP Cert, Deadlines, Benchmarks & Reports
  • Overview: IMA, ARP4754A, ARP4761 & MCP
  • IMA & CAST-32A Modules and Partitioning
  • DO-178C’s & MCP Requirements, Design & Verification –
  • MCP & CAST-32A Best Practices for Planning, Testing, & Certification
  • MCP & CAST-32A WCET Mistakes & Best Practices

New Free Tech Webinar Friday, June 8: “Safety, Security, Agile Development: Pick Any 3!”

4 Jun

The most frequent question we get at AFuzion the past year from dozens of clients  is “How do I merge Agile Development into my safety-critical development while ensuring my software meets Security standards???”    If you’re into aviation, automotive, or medical devices, this question has Pass/Fail consequences.  If you’re programming a cappuccino machine, it has consequences … (imagine some hacker changing my espresso machine settings remotely to provide less caffeine in my morning routine (and afternoon; and evening).  TRAGIC!!

So we’re doing something about this, to avert more serious tragedies and enable developers worldwide to better merge AGILE development into their safety and security software.  Really.  This free technical webinar is limited to the first 500 registrants – click here for more info or to register:Free Registration June 7 Tech Webinar “Safety, Security, and AGILE Development – Pick Any Three!”



Spending Too Many $$ on UAV Certification? New Free 12-Page AFuzion Paper Explains.

6 May

If you’re reading this, you’re likely involved with UAV / UAS / RPV development. New rules for software/hardware UAV compliance to DO-178C and DO-254 are confusing; and expensive.  AFuzion’s new 12-Page technical paper on Reducing DO-178C Costs for UAV’s explains.  Free download links herein; the following is a short synopsis – full details in the free paper.

In the “Good Old Days”, the avionics guideline DO-178B was only informally applied to unmanned systems. But first, let’s clarify: in technology, the “Good Old Days” means 10-20 years ago. In the world of unmanned systems, “Good Old Days” means 5-10 years ago. However, the Good Old Days were rarely as good as they seemed, so the Good Old Days of Unmanned Systems had disadvantages along with those seeming advantages …

AFuzion recently hired four new engineers whose sole focus is UAV certification/compliance. The full 12-page technical paper is available for free download here:  Click Here to Download Free 12-Page Reducing UAV Cert Costs Whitepaper

DO-178B has been replaced with DO-178C, and is now increasingly applied to (and in a growing number of cases, required for) airborne avionics within Unmanned Systems. DO-178C is never cheap, certainly not on the first project. And in clear cases outlined herein, DO-178C can increase costs above DO-178B, which already increased initial avionics development costs by 20-40% itself. But is DO-178C really “too” expensive? Doesn’t it reduce costs over DO-178B for companies who were doing it “right”? Does DO-178C have favorable benefits versus costs over the lifetime of Unmanned Systems? Does DO-178C reduce long-term unmanned costs at the expense of increased development cost? Will DO-178C improve UAV safety and reliability and if so, to what degree? Exactly what benefits are received from complying with DO-178C? These important questions are answered in the AFuzion paper (available by download). An all-too-brief intro follows.

A popular myth is that DO-178C is expensive when applied to UAV’s. Indeed, DO-178C is not “cheap” as clearly the additional costs can be seen above. Level D certified software still has generally full planning, high and low-level requirements, implementation, reviews, and full functional testing of all high-level requirements with traceability applied. Additionally, configuration management, quality assurance, and DER liaison are applied to Level D. Yet the costs of Level D are just 15% higher than medium-quality consumer/financial software developed per typical CMMI Level 2-3 processes. Why? Because Level D is comprised almost entirely of normal industry-standard software engineering principals. Also, many companies new to DO-178C believe their prior, existing efforts including planning, requirements, designs, test, and reviews must be re-done: not true. In fact, a DO-178 Gap Analysis activity will analyze the existing processes and work to re-use such processes while identifying the “gaps” to fulfill DO-178’s requirements. (The author has performed dozens of successful DO-178 Gap Analysis activities which take 2-4 weeks to perform and form the basis of the data herein.)

DO-178 also requires reviews (generally independent for Level B and mostly independent for Level A) of all software development processes and artifacts. DO-178 reviews must be per approved DO-178 checklists to ensure all required aspects are properly reviewed. To save money and time, many companies use automated project management/review tools.

Another myth is that the most significant software cost escalation occurs when moving from DO-178 Level B criticality to Level A. Untrue, but for an interesting reason. The singular largest difference between a Level A system and the Level B system is the 100x greater reliability required by the Level A system per ARP-4761A. However, that 100x reliability must come primarily from the system/hardware architecture and not the software. How? Added redundancy: the only way to meet DO-178C’s Level A reliability is via increased hardware/system redundancy which of course greatly increases total UAV cost. But the software cost difference, the subject herein, between Level A and Level B software is quite minor as seen in the figures above.

The cost differential within DO-178C is the most significant between Level D and Level C. Why? Level C requires the following key objectives which Level D does not and which results in Level C requiring 35% more effort than Level D:

  • Testing of low-level software requirements
  • Ensuring 100% coverage of all source code statements
  • Assessment of requirements, design, and code to standards
  • Greater rigor placed upon reviews
  • In many cases more rigorous configuration management

Level B requires additional structural coverage (decision-condition, e.g. all branches in the source code), additional independence in reviews, and tighter configuration management. At first glance, it would seem that Level B should be significantly more expensive, e.g. 50% – 70%, than Level C. In theory, it seems to make sense, but as in many areas of life, common sense overcomes theory. In Level B (and C) there must be detailed, low-level software requirements and they must be thoroughly tested. Remember, DO-178C requires detailed low-level requirement verification beginning with Level C and those low level requirements will cover the vast majority of software logic decisions. During requirements-based testing, most (80-90%+) of the branches in the source code are already covered and hence require no additional structural coverage testing if test capture and coverage tools are appropriately used during that functional testing. Therefore, the seemingly significant cost increase associated with Level B versus C structural coverage is already mitigated by DO-178C’s greatly enhanced requirements-based testing. Also, quality software engineering organizations already incorporate a semi-automated and streamlined process which includes independent reviews and tight configuration management; ergo the added cost of those aspects for Level B is largely mollified. The reader is well-advised to undergo upfront DO-178 Training and DO-178 Process Improvement to leverage these cost reduction techniques.

Now, “efficient” followers of DO-178B for UAV’s will find even greater cost impact in adhering to DO-178C for the newer generation UAV’s. Their “efficiency” may have been due to taking liberties with DO-178B’s intended, but less enforced, low-level requirement detail. Such shortcuts enabled less detailed functional testing with many fewer logic branches verified. While acceptable for DO-178B Level C, it’s unacceptable for DO-178C Level C which mandates greater detailed of low level requirements. Because of that greater detail, DO-178C inadvertently reduced the difference between Level C and Level B because the decision-condition structural coverage objective of Level B is largely covered already in Level C due to those more detailed low-level requirements. Also, developers making extensive use of Parameter Data Items (objects or logic external to the main application program) are now required to fully document, review, trace, and test all that data under DO-178C; something they “should” have been doing under the intent of DO-178B. Voilà.

To better understand how to apply reuse to UAV’s for DO-178C and DO-254 compliance, you just need to understand your current DO-178C gaps and DO-254 gaps and perform a UAV Gap Analysis per DO-178C/DO-254. AFuzion shows you how in a 1-minute video and also explains UAV and DO-178C DO-254 Gap Analysis – free info and video hereClick Here for DO-178C & DO-254 Gap Analysis Info and Free 1-Minute Video Explaining


New DO-160 Avionics Testing Technical Whitepaper by AFuzion – Free Download

7 Jan

AFuzion has released its new DO-160 Avionics Testing Whitepaper, available today for free download here: Click Here to download AFuzion’s DO-160 Technical Whitepaper – Free.

Do you know DO-160?  Here’s a quick summary; simply download AFuzion’s free technical DO-160 paper for details.

DO-160, “Environmental Conditions and Test Procedures for Airborne Equipment”, applies to virtually all commercial avionics systems and many other forms of airborne equipment. In the case of DO-160, the title is quite revealing, as DO-160:

  • Pertains to environmental testing, not logic execution or developmental processes
  • Provides explicit, independent test criteria which must be attained to achieve equipment certification
  • Applies to airborne equipment and expected worst-case environmental conditions which could potentially be encountered during aircraft operations


Essentially, DO-160 mandates tests which prove the equipment will continue to operate as desired in worst-case environmental conditions which could potentially occur in an aircraft. The purpose of which is safety, whereas commercial aspects are not important to DO-160 per se. Some people fondly call DO-160 the “Shake And Bake” test regimen, because early DO-160 testing was based upon subjecting the hardware to extreme vibration and temperature conditions. But DO-160 has always been more than “shake and bake” and the most recent versions introduce many additional forms of testing including pressure, salt, water, RF, magnetism, lightning, and many more environmental conditions.

Before proceeding further, please ponder a little quiz …

  • T / F:   DO-160 applies solely to electronic hardware.
  • T / F:   DO-160 can be used to measure service life and MBTF.
  • T / F:   DO-160 testing is typically performed simultaneously to performance and functionality testing of the hardware/software logic
  • T / F:   DO-160 is predominantly concerned with temperature and vibration testing.
  • T / F:   DO-160 is a static document and rarely updated.
  • T / F:   DO-160 testing should all be performed on the same piece of equipment.


Do you know all the answers? A couple of them are tricky, but reading AFuzion’s full and free DO-160 paper will help.



DO-160 has a long pedigree. While the first version was released in 1975, it is derived from DO-138 which dates back to 1958, making it one of the older aviation certification documents still applicable today, albeit in its latest revision. Although many of the other “DO” documents pertain to specific aspects of hardware, software, systems, and processes, DO-160 is often considered the grandfather since almost all these systems must ultimately pass DO-160 testing.


DO-160 is essentially equipment environmental testing to Minimal Operational Performance Standards (MOPS), where testing is to be performed in a certified laboratory environment with certified & calibrated equipment. Such a laboratory environment means the tests are objective, standardized worldwide, and repeatable. Typically these tests are performed at testing centers which are independent of the design, though larger companies may have their own dedicated DO-160 test environments. Non-certified laboratories or equipment are useful ‘engineering tools’ to increase design confidence and decrease actual certified laboratory test time. The successful conclusion of a DO-160 test campaign is an accepted Test Report (desirably, but not necessarily with all ‘pass’). A well-written Test Report is not a trivial task, and in this context would include the certified laboratory(ies) and a list of the test articles, which includes the calibrated test equipment. The DO-160 testing would follow a previously written and customer accepted Test Procedure, being referenced in a Test Plan.

For DO-160 Training or additional information, click here or contact AFuzion: AFuzion’s Avionics Development Training – Info & Contact Click Here.

For a quick 1-minute video to understand how to close your avionics development gaps, click here: Click upper right video link here for AFuzion’s Gap Analysis 1-minute video

“How To Fail at Aviation Software Development” (Then Hopefully Succeed!)

1 Nov

Too often “How to” guides present lofty goals which seem desirable, but at the same time are seemingly unattainable. This paper is different. An unhealthy software development diet is just like a poor nutritional diet: seemingly good tastes can become bad habits and result in real harm to health. But what ingredients go into an unhealthy airborne software diet?  Understanding and addressing airborne software failures is the first step towards better avionics health.  Remember: with knowledge, training, discipline, and practice, software engineers – just like athletes – can become winners.  The following is an excerpt from a new paper just written by Vance Hilderman of AFuzion (with Joao Esteves of CRITICAL Software); to download the entire paper, just visit http://www.afuzion.com and request a free download.  Free Technical Whitepapers, including “How To Fail”



DO-178C describes the integral processes spanning the software development lifecycle. Up to 71 formal objectives are summarized which cover the full range of software engineering activities, beginning with planning and ending with certification.  While some of these objectives are self-evident (for example, ‘develop requirements before design’, ‘develop design before code’), others are more nuanced.  Returning to our metaphor, the parallels between software health and human health abound: everyone knows that reducing fat and sugar intake while engaging in modest exercise yields health benefits.  But how can you identify the most cost-effective and healthy foods? And, when it comes to exercise, what types and frequency provide the greatest return on time while minimizing the risk of injury? DO-178C says nothing about reducing schedule, cost, or risk yet these things are paramount to the success of any avionics project.  95 of the world’s 100 most successful avionics companies have hired the authors of this paper (CRITICAL Software and Afuzion) to prove or improve airborne software health. Drawing on this experience, this paper explores the ingredients that contribute to BAD avionics software health and how to avoid them, in order to better understand the healthy practices that lead to successful airborne software development.


BAD Software Health: The Best (or Worst) Ways to Fail …

DO-178C’s 71 objectives are interspersed across ten categories of avionics software engineering activities. Failures can literally occur within any of these objectives or activities. But which objectives are most frequently misunderstood and which activities yield the greatest risk of failure? This paper summarizes the best (or worst!) ways to fail within each of DO-178C’s ten process categories. That’s right! Each of DO-178C’s ten process categories can be associated with major failures.  The secret is knowing what the potential failures are so that you can formulate advanced strategies to avoid them while maximizing your chances of success.  And, of course, maximizing success means minimizing risk, cost, and schedule times while simultaneously maximizing quality.  You’ve no doubt heard of the saying:  “You can have it fast, or cheap, or with high quality … so pick one.”  However, successful avionics projects truly require all three:  cost-effective and fast development processes, with acceptably high standards of quality.  Here, avoiding the common mistakes within each of DO-178C’s ten software engineering activities is paramount to success.


DO-178C’s Ten Process Categories

So we know that DO-178C covers ten categories of software engineering activities.  These ten categories and the common mistakes associated with each are depicted below:

DO-178C’s Top Ten Failures vs Activities


  1. Planning to Fail

Aviation, like athletic training, is all about preparation and planning. Before an aircraft takes off, a flight plan is conceived of, detailed, and then filed.  Similarly, a competitive athlete makes a training plan and smart, successful athletes use nutritionists and trainers to help them.  Success requires planning, and no one intentionally plans to fail. However DO-178C requires an advance planning activity yielding five detailed plans plus three standards; the planning recipe requires sufficient detail on the required ingredients of “what”, “who”, and “when” without too much detail on “how”.  As mentioned, avionics software health resembles human health in many ways: many factors come together to contribute to the overall state of health and, for avionics, those factors must be summarized in the five plans and three standards.



Some athletes find that despite their seemingly well-prepared exercise plans, their improvement quickly fades along with their dreams of success: and that their exercise plan simply lacks the ability to strengthen muscles.  Why?  Typically, the answer is that they are missing crucial details about diet, intensity and the duration of exercise and, most importantly, how to measure success.  Aviation is the same. It is all too easy with DO-178C to draft high-level plans which do not sufficiently define the key detailed aspects of your avionics system necessary for successful certification. Common aspects missing from DO-178C planning documents include:


  • Use of previously developed software. If used, how will it be certified or brought up to compliance standards?
  • Use of configurable software, where users may “reconfigure” software after certification by modifying off-board configuration data. It is imperative to follow DO-178C’s explicit Parameter Data Item (PDI) criteria for such activities.


  • Application of DO-330 for Tool Qualification, and identifying the full suite of software engineering tools planned for use then defining where the outputs of each will be verified. If verification is insufficient, formal DO-330 Tool Qualification will likely be required.


  • Application of Model-Based Development as per DO-331 and, when used, a brief synopsis of applicable Specification Model standard versus Design Model standard (these cannot be the same standard: like high-level requirements and low-level requirements, the Specification Model and Design Model are distinctly different and require sequential verification, in that order).


  • Description of the means to analyse data and control flow coupling. This coupling analysis is about more than checking a box during a code peer review – it requires proper consideration of software design and the interfacing modules/data. Recent third-party tool improvements will help with coupling analysis but your plans must summarize coupling analysis activities via verification engineers.


  • Regression analysis: all projects have changes and the means to verify those changes depend on regression analysis. The processes used by verification engineers for regression analysis and retesting must be sufficient for the plan reviewer to assess adequacy – experienced verification engineers know how to apply the tools and techniques to semi-automate this process to ensure it’s done right, first time.



By considering the above common mistakes within your “avionics exercise plan”, your project has a chance to win the gold medal at the first attempt.



  1. The Requirements of Failure


The world’s leading software experts agree: most software defects are due to defective requirements.  Yet DO-178C provides scant details for ensuring that you have great requirements.  Yes, you could hire or outsource your development to world-class avionics developers, but what can you learn from them about developing great avionics software requirements?  First, experts know that the successful longevity of DO-178 is due in no small part to its careful balancing of 71 deterministic objectives versus flexibility on how these 71 objectives are met.  Yes, DO-178C could include many more pages of suggestions on how to improve software requirements:  but they would be just that – subjective suggestions. Consider that avionics projects span a vast variety of domains, complexity, criticality, and size. No single “How to” guide would suffice.  Instead, DO-178C uses structural coverage analysis to assess requirements:  for Design Assurance Levels (DALs) where people could be seriously injured or worse (beginning with DAL C), software structural coverage is required.  Simply put, software structural coverage objectives exist for multiple purposes, including assessing the degree of software structural coverage obtained when performing requirements-based functional tests.


In Brooks’ 1975 book Mythical Man Month, it is revealed that a leading cause of software defects is “assumptions”, and that these assumptions are often the result of weak requirements.  The first version of DO-178 was developed soon thereafter, fully cognizant of Brooks’ writings.   When a software developer cannot explicitly understand a desired result (“software output”), that developer is likely to make implementation assumptions.  Of course, the developer should instead strive to achieve an improved requirement. Yet developers are much more likely to simply power on and do what they think best, not necessarily what is right.  How do good avionics managers avoid this?  They employ the following best practices:


  • Utilize detailed software requirements standards which are reviewed at SOI #1, and which include examples of good, and not so good, high-level requirements and low-level requirements.


  • Have software testers review the requirements BEFORE the developers see them. Those testers then try to write deterministic test cases from those requirements without making any assumptions; where that is not obviously clear, feedback their questions to the requirements development process to yield improved requirements.


  • Use software modelling where systems engineers and software engineers use a shared-modelling platform and formal language (SCADE, SysML, UML, etc.). This shared language minimizes the very assumptions endemic to weak requirements.



  1. V = R + T  + A


Yes, engineers love equations!  The above equation is clear, but why is the “A” so small?  Again, it’s about health. Specifically, healthy verification of software requirements.


But is avionics software health really as simple as following an equation?  Almost.  But the equation must be properly understood:


V = R  + T  + A


Verification  =  Reviews  +  Tests  +  A Very Small Analysis


That’s right, in DO-178C, verification is performed via a combination of reviews, tests, and analysis:


  • Reviews: virtually everything is reviewed.  Plans, standards, safety, requirements, design, code, tests.


  • Tests:  requirements and code are tested via ground-based executable tests of flight software.


  • Analysis: when the above combination of reviews and tests does not completely satisfy DO-178C’s verification objective, additional analysis must be performed.


The verification equation is best satisfied when the requirements are sufficiently detailed that two independent verifiers could achieve equivalent assessment results.  Remember:  verification does NOT directly improve software. The goal of verification is to assess the software, specifically if the objectives of the DO-178C compliant plans and standards were fulfilled.  Actual software improvement then comes via the feedback process which then feeds into improving the requirements, design, and software.


It is imperative that requirement granularity be sufficient to devise robustness tests based on those requirements. Robustness should answer the question “does the software behave consistently and deterministically under less benign conditions of error values, boundary values, performance testing, illegal state transitions, off-nominal timing values, etc.?  In other words, the “rainy day” scenarios.   After robustness testing, DAL C, B, and A verification includes “white-box” tests, where actual software attributes and structural coverage are assessed. One objective is to assess the absence of dead code (code which has no reason or requirement to be there and which could and should be removed) and the sufficiency of mechanisms to ensure non-execution of deactivated code.  Experienced systems engineers elicit detailed requirements and expert avionics testers are adept at devising test cases to assess software/requirements robustness and dead/deactivated code.


Voila:  V  =  R  +  T  +  A




  1. Designing Software Failure


Design is like that distant uncle you see only once a year at Christmas or Thanksgiving. If you span across the entire life cycle nothing is as forgotten as design is. People often fail at requirements but plenty has been written and debated in conferences and training sessions about the importance of them. The same is true for V&V and testing.  Code has always been the gravity center – more emotionally than in terms of its actual impact on quality output.    What is left over and abandoned then? Design!  Indeed, design is often treated as a distant uncle and not a very wealthy one. And to some degree, agile processes (which may be helpful when well applied) are kicking design even further from the road. That is why frameworks and standards like AUTOSAR exist. It is not necessarily just to enable modularity, integration and reusability, but also because most people are bad at design and do not realize just how bad they are. Therefore, DO-178C applied properly can provide a useful framework for acceptable design. In the past, V&V was the subject of software developers’ bigotry – a set of activities left to those that were not sufficiently skilled at programming and were therefore relegated to the back seats in IT’s second class – but for a few years now, even non-safety-critical industries, such as banking, have started to view V&V as very important, explicitly procuring such services.


Back to our metaphor. Winning athletes focus on optimizing their capacity for physical movement, knowing that they cannot fundamentally alter their body’s “design”.  In athletics, the design of the human body is the ultimate equalizer: most bodies have fundamentally similar “designs”. Not so in avionics:  each system has an implementation customized to its particular design. Avionics software developers thus depend upon a robust and flexible design to yield the necessary consistency and determinism while affording the possibility of future system evolution. So what are the causes of failure in the design of avionics systems?  Over the past 25 years, the engineers at CRITICAL Software and AFuzion have worked on 300+ avionics systems – here are the most common design techniques observed which can result in failure:


  • Reusing prior designs which are poorly understood or documented. If you are inheriting such a design, first document it, then analyse it to see if it is even worth modifying. Like modifying an old or decrepit building, it may be more cost effective to simply start over, the right way.


  • Failing to have, and verify conformance to, a software design standard that specifies:
    • Details for all external and internal interfaces, including full bit patterns, encoding rules, use of any variant records, and source and destination information for all data items (remember: include internal interfaces).
    • Rules for defensive design/coding
    • Health monitoring details
    • Task prioritization schemes
    • RTOS and BSP usage and limitations plus a reference to allowable API’s (those designated “DO-178C certifiable”).
    • Rules for controlling coupling, which provide sufficient details to perform subsequent coupling analysis.


  • Failing to encapsulate hardware dependencies to yield portability.  Remember, for successful avionics programs, the question is not “Will it ever be modified?” but rather “When will it be modified?”. Most successful avionics systems are eventually updated with newer hardware and increased functionality.  Only by pre-planning future portability can such future upgrades be accommodated.  Plan for common core functionality which should not be changed and partitioned away from hardware-specific functionality which is then encapsulated within its own modules. Minimize the scope of change so that the vast majority of software modules, objects/classes and design elements can remain unchanged and unscathed. 


Bad design is also the key source of V&V difficulties when it comes to incremental testing, data and control flow analysis, effective development of test stubs and many more issues. What is strange is that one will often see people pointing fingers at the requirements or V&V team without realizing that disastrous design is actually the fundamental cause.



  1. Encoded Code


DO-178C requires that the “software language for humans to program avionics computers” is clearly understood by developers, reviewers, testers, and auditors. In other words, that it is absolutely NOT “encoded”.  The software languages used to program avionics computers must be common languages subject to defined compilation rules. Virtually any software language can be used (C, C++, Java, Assembly, Ada, Jovial, etc., none of which ever require compiler qualification or validation). However, for DAL A, B, and C there must be a defined coding standard. That coding standard must restrict unsafe constructs and operations while ensuring determinism, and the resulting source code must be verified against the designated and approved coding standard.  In avionics software development, the assumption is “guilty until proven innocent”.  So what are the best ways to fail at the level of code?


  • Failing to select a software language which has a coding standard that is accepted as safe by the aviation community. C, C++, and Ada are the most commonly used aviation software languages and all of them conform to safe coding standards.    


  • Failing to perform static code analysis prior to exiting the coding stage. While not required by DO-178C, static code analysis is performed via various commercial third-party tools. These tools can be formally qualified (see DO-330 Tool Qualification above), in which case the code peer review may not be required. However, even unqualified tools are usually better (and exceptionally faster) at finding hundreds of types of the most common software coding errors committed by humans.


  • Failing to define complexity metrics within the project’s required software coding standard and failing to enforce them. Complex code (measured via cyclometric complexity) is a harbinger of disaster. However defining in a way that is “too complex” is a subjective judgement and so such a definition is not provided within DO-178C. That does not mean that any project is free to have overly complex code. Quite the opposite:  complexity metrics must be defined and properly enforced.


  • Failing to realize that DO-178C’s coupling analysis is not solely performed by parsing or reviewing source code. Coupling analysis requires the consideration and analysis of software design and interfaces, not merely local source code reviews.


  • Failing to read between the lines of DO-178C to understand that there are six inputs required for software code reviews:
    1. Source code
    2. Source code checklist
    3. Software coding standard
    4. Software design
    5. Software requirements
    6. Trace matrix showing which software requirements are allocated to the source code under review


Each source code review must identify each of the above inputs, along with the artefact version identifier used for that review.

Hope you enjoyed the first half of this free technical whitepaper “How To Fail at Aviation Software Development (and How To Succeed!)”  To download the full paper, just visit AFuzion in the above referenced link and request a free download.

For information on public or private DO-178C training classes, visit AFuzion at: Public and Private DO-178C Training Classes:

For a fun 1-minute video “What is AFuzion” click here: What is AFuzion? Fun 1-Minute Video:


Fall 2016 Important Avionics Development Dates: Conferences, Webinars, & Training

23 Aug


Important Avionics Development Dates – Fall 2016

 Avionics Conferences, Webinars, & Training 


Sept 13-15, 2016:  FAA Bi-Annual Certification Conference, Dallas Texas USA.  (Limited to 350 Attendees)        Info & Register :  www.faa.gov

Sept 14-16, 2016: Software Safety for Airborne Systems Conference, Berlin Germany.                                      Info & Register: http://www.avionics-system-safety.com/

Sept 26-27, 2016: Public DO- 178C Training via SAE, Hartford CT USA:                                                               Info Request: vance.hilderman@afuzion.com

Sept 29, 2016: Free Technical Webinar 10 a.m. EST: “Managing Safety-Critical Requirements” – Jama Software & AFuzion. Register:  http://go.jamasoftware.com/developing-safety-critical-system-requirements-best-practices-registration.html?utm_source=afuzion

Oct 13, 2016: Free Technical Webinar 9 a.m. EST:  “How To Fail (and how NOT to Fail) at Airborne Software Development”   Register: https://attendee.gotowebinar.com/register/6879917310589589249

✔ Oct 25-26, 2016:   Electronic Valley Aviation & Avionics Development Conference, Ankara Turkey.              Info & Registration: http://www.ev-seminars.com/seminar2016

Nov 14-15, 2016: Public DO-178C Training via SAE: London UK.                                                                            Info & Registration: http://sae-europe.org/aerospace-training-week/