Archive | Uncategorized RSS feed for this section

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  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 Releases All-New Requirements Whitepaper for DO-178C, DO-254, and ARP4754A Software, Hardware, and Systems

20 Dec


AFuzion Inc. today announces the free availability of its newest technical whitepaper: “Requirements for Safety-Critical & Avionics Software, Hardware, and Systems”.  Previously available only to AFuzion’s 300+ clients, this latest paper is now available for free download from AFuzion’s whitepaper page.   Says Jeff Stevenson, AFuzion’s Business Manager:  “When AFuzion was smaller, we did business with 30-40% of the world’s avionics companies. But now the majority of them are AFuzion’s clients and our  technical papers are so widely distributed it only makes sense to make them fully available to all engineers worldwide.  The key is Safety, combined with efficiency and quality, so we’re adding a little year-end Holiday Cheer and making AFuzion’s latest paper publicly available.”

Adds Vance Hilderman, AFuzion’s Chief Technical Office and the author of this paper: “System, Software, and Hardware requirements are truly the key to safety-critical project success.  As we have taught 20,000 engineers in our AFuzion courses, Requirements development, management, and refinement are the true keys to project success. ARP4754 System requirements, DO-178C software requirements, and DO-254 hardware requirements development is both a science and an art. This paper describes how to build better systems faster and cheaper via Requirements.  Few things in life, or in aviation, are simple. But that truism is.”

This latest AFuzion paper is 14-pages filled with detailed information on creating, managing, refining, and validating requirements. Remember, verification means “does the implementation meet the requirements”, whereas validation asks “and do we have the ‘right’ requirements”.  This AFuzion paper shows why Validation is more important than Verification because without the right requirements, it is largely irrelevant if they are then verified.  Indeed. 

AFuzion has created perhaps the world’s largest library of technical whitepapers for safety-critical and aviation development. AFuzion’s decade’s old papers are still distributed by former employees (with the author’s name accidentally removed and replaced), but all AFuzion’s latest papers are freely available to clients.  Anyone is allowed to download up to two papers for free, so no reason to refer to the decades-old versions passed around elsewhere. 

For a free download, simply click here or go the AFuzion website under Whitepapers: Click Here For Free AFuzion Whitepaper Download

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,



  • 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

Can Multi-Core Processing Be Safe? Maybe … (CAST-32A)

3 Oct



Yes, you are busy and in today’s world you want immediate answers to important questions. “Is Multi-Core Processing safe?” The quick answer: “It can be, but …”. The slightly less quick answer: read the next few paragraphs. The proper answer: review CAST-32A or listen in on the free technical webinar on October 11, 2018 (sign up here: free but limited to the first 500 signups and these always are oversubscribed: Free Multi-Core Technical Webinar Signup: )

For safety-critical systems, a key facet of safety is “determinism”, via apriori planning, development, verification, then safety certification. But Multi-Core Processing (MCP) achieves faster processing by performing multiple activities at the same time, in parallel, by allocating tasks to different processing cores which are all embedded on a single processor. Today, your computer or cellphone likely uses MCP. Why MCP? Simple: we want our devices to do more and to do it more quickly. We’re slowly reaching the point of diminishing returns on silicon density technology where we’ve blissfully followed Moore’s law via improved processor fabrication and faster clock speeds. The answer: put multiple processing cores on a single chip and enable use of shared resources (memory, cache, etc.) to enable faster “parallel” processing (where actual “parallelism” is determined by both the application developer’s architecture and the task allocation model, including operating system).

But just as free lunches are rarely “free”, MCP isn’t fully “free”; certainly not for safety-critical systems where that pesky “Determinism” attribute is important. Just five years ago, MCP was considered to be so dangerous it was indirectly “banned” by worldwide aviation authorities. But those authorities are too smart (clever?) to actually “ban” a technology, so they published a document named CAST-32 which essentially stated “MCP could be used if the developer could prove all cores were disabled except for one”. Wait – if you disable all cores except one, then you don’t really “have” MCP, do you?!? Who knew the advanced certification experts had a great sense of humor. Now, when disabling three out of four engines on a four-engine airplane, you’re essentially flying a heavier single engine airplane with worse performance characteristics than a true single engine aircraft. Same with disabling all the cores on a multi-core processor. Brilliant.

And then, voila, technical evolution meets Today: the new update to CAST-32, aptly titled CAST-32A, allows for true MCP usage in airborne safety-critical systems. But the new MCP lunch isn’t free: we now have to prove determinism within the MCP including its innermost secret (intellectual property) workings. This means we must prove predictable memory and cache usage without interference. The burden of proof is on the user and typical users don’t understand (and don’t have access to) the real-time operating system (RTOS and MCP internal design to enable such proofs. Affirming MCP determinism is not trivial and you almost certainly need a certifiable MCP RTOS to enable MCP certifiability.

In the software certification world, there is an interesting relationship between OOT and MCP. Yes, both acronyms have three letters. But the real similarity is in utilizing safe subsets. Example: true C++ was not fully usable 15 years ago until rules for safe object oriented technology via defined language subsets (MISRA C++) were formalized. The result was that full C++ cannot be used without rules limiting its usage (for example, restricting the use of inheritance, polymorphism, overloading, and garbage collection). Similarly, full MCP usage will be difficult to prove deterministic usage so limitations simplify MCP acceptability; those limitations include core/task allocation models which greatly reduce potential interference paths between cores. So, a certifiable MCP use-case is there and becoming clearer. To make it very clear, simply watch the free AFuzion technical webinar at the link provided above. Or watch it anytime later via the AFuzion free technical training webinars posted on YouTube here: AFuzion Free Technical Youtube Webinars.

There you go: quick answers for you busy engineers. But we’re never too busy to be safe so keep your cores deterministic.

Safe Skies,

Cheers, Vance Hilderman (CEO AFuzion Inc.)

To Succeed, We Must Know Failure

26 Aug


Have you noticed that each Fall, many new articles are published supposedly teaching us how to Succeed. But one year later, an all-new set of “How To Succeed” articles is published, meaning the prior books must not have worked. The reason? This author believes the answer is easy: “To succeed, we must first know failure.”

That’s right: success requires a solid foundation and that foundation must be devoid of cracks. To avoid cracks in your success foundation, we must know what causes cracks. Consider a simple building: foundation cracks can be caused by poor design, weak cement, insufficient steel reinforcement, earthquakes, water intrusion, loose underlayment, and here in AFuzion’s Manhattan headquarters as I write this … water intrusion from storms. Any attempt to build a solid foundation without knowing the causes of cracks requires perfect luck along with blissful ignorance. In real life, continuous luck never happens so success requires knowing the causes of failure.


Several years ago while starting AFuzion, I needed firsthand Failure knowledge. Why? Simple – I had lost several friends in airplane crashes and I was working on my own pilot license. My 50+ years had many successes, however there were several instances of failure which I hadn’t fully explored. However, in aviation, there would be no opportunity for self-exploration of failures, so I realized I needed to understand the cause of past failures. Yes, I too had read hundreds of those “Success” articles mentioned above and found them helpful. Helpful at creating the successes but worthless at preventing my Failures. There’s the answer and it was a simple choice: I could either rely upon perfect luck to avoid dying in my airplane, or I needed to really understand Failure. I chose the latter.

For millennia, humans evolved knowledge by improving upon successes while simultaneously learning from failures. The quotation “Those who don’t understand history are bound to repeat it” rang true: early humans quickly learned two fundamental truths: 1) “If it worked the first time there’s no guarantee it will always work the second time”, and 2) “If it didn’t work the first time, it probably won’t work the second time”.

Now wouldn’t it be refreshing to have open discourse about our failures so that others could learn from and prevent repetition? The conundrum: authors mistakenly believe their reputations will be tarnished if others learn how often they failed … so much better to avoid Failure discussions and write only about Success! And that dear readers is why this Fall’s plethora of newly released Success articles will so closely resemble last year’s … until now.

I completed my piloting ground school not studying only successful pilot actions but also studying accidents and what caused them. In most aviation accidents, the ground and onboard fuel are unforgiving so it’s up to the investigators to help us learn from the failure. But my real career has been devoted to thirty years of avionics development – mostly successful but a few failures intertwined. While the successes were numerous (founding and leading three of the world’s largest avionics development/certification companies), failures sometimes occurred. Fortunately the Success spotlight shone brighter than the Failures meaning the latter could be cast aside. Ignored by most. I went on to write many articles and books about achieving avionics development success but never recorded the Failures. Until now. Truly, I learned from those failures. I learned they were more numerous than imagined because we optimistic humans readily gloss over failures. And I learned my failures were preventable as I never repeated a failure; instead I simply found the freedom to incur new failures interspersed with many successes. Did my successes diminish my failures? Only on the grand stage of Visibility which differs from real life. So now, with the help of my fellow avionics development colleague Mr. Joao Esteves, we have recorded for all posterity “How To Fail at Avionics Development”.   Yes, go ahead and read this Fall’s new batch of Success articles. Enjoy them and have good luck with them. But pilots (and avionics developers) who rely upon luck soon find it in short supply. Instead, try something new: study real failures and their causes. Mine. Ours. And hopefully not Yours.

For a free download of “How To Fail at Avionics Development” simply email or download free whitepapers here: Click here for free AFuzion Technical Paper download

Brazil Safety-Critical Training Week, September 10 – 14, 2018 (Both Free & Paid Training)

23 Jul

Brazil’s largest full week of safety-critical development training is just six weeks away – hope to see you there!

Free Safety-Critical Software/Hardware Seminar, Sept 10, 2018: 

Theme: “Electronic complex and embedded software in critical systems”

Location: Technological Park of São José dos Campos, SP – Brazil

Date: September 10, 2018

Ticket price: FREE


  1. Vance Hilderman

CEO of AFuzion and specialist in software and systems development, with a focus on “safety-critical” in the aerospace and automotive sectors;

  1. Gilberto Trivelato

CEO of Seamax Aircraft and specialist in development of safety-critical control systems with aeronautical certification levels;

  1. Two other highly specialized specialists related to the theme.


Formal DO-254 Intermediate Avionics Hardware Development & Certification Training

Date: September 11-12, 2018

Location: Technological Park of São José dos Campos, SP – Brazil



Since DO-254 was released ten years ago, the knowledge of software hardware development processes, techniques, and strategies for safety-critical hardware has vastly changed and in some cases improved.  However, there is a large gap between understanding the real intent of DO-254 certification and the minimalist words in the Book. Just as commercial hardware development techniques have advanced, so has the world of aviation hardware development and certification. This Intermediate DO-254 training will provide important knowledge for attendees to rise to, understand, and apply those advancements and new hardware certification requirements for FAA, EASA and worldwide certification agencies.  This Intermediate DO-254 training is intended for persons with basic familiarity of DO-254, DO-178, or safety-critical standards. If no prior training, just request AFuzion’s training papers to read in advance – freely provided to attending students.  The developer/teacher is the principal founder of two of the world’s largest avionics consulting companies and the principal author of several of the world’s most popular publications on DO-254: Vance Hilderman has taught over 11,000 avionics engineers and managers worldwide, including FAA and EASA officials, and engineers from 95 of the world’s largest 100 aviation companies: more than all the competitor’s current trainers in the world, combined.

AFuzion’s training has been provided to over 17,500 aviation engineers from 1,000 companies in 30 countries; more than all other trainers in the world combined. Brief summary below; contact us for more free information.



  • Quick refresher on basic DO-254 and “how” DO-254 is applied to advanced avionics
  • Understanding CAST-27 and AC 20-152 and related EASA certification requirements
  • Understanding actual hardware DO-254 requirements with actual case study
  • Advanced analysis, element analysis, and structural coverage for hardware logic
  • Actual hardware PHAC review checklist walkthrough
  • Actual hardware HWPA (“quality assurance”) review checklist walkthrough
  • Representative SOI audits for Hardware – what are they for #1, 2, 3, and 4
  • Hardware Requirements Validation – what is involved
  • Applying DO-254 to Military AND Commercial usage; differences between EASA & FAA
  • Understanding advanced DO-254 mistakes and best practices to avoid them element analysis/coverage
  • Controlling engineering cost/risks with DO-254 Requirements, Design, and Logic
  • Understanding and applying AC 20-152, CAST-27, and EASA-CM-SWCEH-001 for avionics hardware development per ED-80 and DO-254

WHO:  Attendees may include engineers, managers, quality assurance or certification personnel with previous knowledge, training, or experience in DO-254.

 For More Info & Registration: Click here for DO-254 Seminar Info


Formal DO-178C Advanced Avionics Software Development & Certification Training

Date: September 13-14, 2018

Location: Technological Park of São José dos Campos, SP – Brazil


DO-178C (ED-12CC) is arguably the world’s most difficult software “standard” and many millions of lives rely on it yearly. But software development has rapidly evolved along with aircraft design:  many new technologies must be considered, and certified: C++, Model-Based Development, Formal Methods, non-CPU based logic, and advanced tools. New techniques for specifying avionics requirements and design must also be understood.  But what are detailed and derived DO-178C requirements?  How can C++ and OOT be safely used and certified per DO-332?   What are DO-178C Model-Based Development best practices in applying DO-331?  What are the answers to applying DO-178C’s Parameter Data Items?  What were the DO-178B weaknesses and how is DO-178C really different from DO-178B?  How can DO-178C cost and schedule be reduced by 20-30%?

This advanced DO-178C training is intended for persons with basic familiarity of DO-178 or safety-critical standards. If no prior training, just request AFuzion’s training papers to read in advance – freely provided to attending students.  The developer/teacher is the principal founder of two of the world’s largest avionics consulting companies and the principal author of the world’s most popular publications on DO-178: Vance Hilderman has taught over 11,000 avionics engineers and managers worldwide, including FAA and EASA officials, and engineers from 95 of the world’s largest 100 aviation companies: more than all the competitor’s current trainers in the world, combined.

AFuzion’s training has been provided to over 17,500 aviation engineers from 1,000 companies in 30 countries; more than all other trainers in the world combined. Brief summary below; contact us for more free information.


  • Quick refresher on basic DO-178C and “how” DO-178C is applied to advanced avionics
  • Grasp key differences between DO-178B and DO-178C for more advanced users
  • Advanced Safety, Derived Requirements, and Detailed DO-178C Requirements
  • Understanding advanced DO-178C mistakes and best practices to avoid them including model based development, OOT, and C++
  • Controlling engineering cost/risks with DO-178C Requirements, Design, and Code
  • Understanding & applying DO-178C’s Supplements for:
    –     DO-330/ED-215 Software Tool Qualification
    –     DO-331/ED-216 Model-Based Development and Verification
    –     DO-332/ED-217 Object-Oriented Technology
    –     DO-333/ED-218 Formal Methods Supplement
  • Who:  Attendees may include engineers, managers, quality assurance or certification personnel with previous knowledge, training, or experience in DO-178.

For More Info & Registration:  Click Here for DO-178C Seminar Info

Object Oriented Technology, Safety Critical, and DO-332: Achieving Success in Software

17 Jul

If you’re involved in modern software development, then you care about OOT, or “Object Oriented Technology”.  If your software is for high-reliability or safety-critical applications, then you really care about OOT, especially “safe” OOT.  Why? Simple:  systems are becoming more complex, software is doing more of that complexity management, and schedules are tightening; while there’s no single magic bullet, OOT provides many answers.  And don’t you wish you had a single book that explained OOT, provided a tutorial, had decent examples, and emphasized the safety critical aspects?  Impossible for a single book to provide such?  We get this question often during AFuzion’s various safety-critical development training courses.  Our trainers have learned to provide a consistent answer: understand “DO-332”, the aviation community’s guideline for safety-critical OOT and you’ll have many of the answers.  Here is a brief synopsis below, and the full 12-page technical whitepaper is available here for a free download: Click here for AFuzion’s Free 12-Page Technical OOT Whitepaper

DO-332, Object-Oriented Technology and Related Techniques Supplement to DO-178C and DO-278A, is a 150-page guideline governing OOT usage in airborne and ground-based aviation software. However, since true OOT is relatively new to aviation software, (though Ada ’95 has been around since … 1995), the authors of DO-332 faced a large hurdle: how to provide meaningful guidelines to persons generally unfamiliar with object oriented software? The answer was skillfully handled within DO-332 by blending practical “guidelines” with an introduction to OOT which laid a common foundation for OOT terminology, application and certifiability.
There are many ways of approaching software development; hundreds of books are in print with many seemingly preaching their own “methodology”. But as all the many colors in a peacock stem from basic Red-Green-Blue, software development at its most (overly) simplified vantage has two “primary colors”: functional structured design and object-oriented design. Unlike the peacock, with software these “colors” do not blend well; many software design elements are considered to be either “functional” or “object oriented”. Traditional functional software is designed by considering then structuring each sequence of computer actions one at a time. Conversely, object oriented software is designed by first articulating software objects and actions to be performed on those objects, then integrating such objects/actions into meaningful groups and events. Yes, functional design may have some objects. Yes, object oriented design will use some sequential structural behaviors. But as a few drops of oil can float on water, that oil and water are hardly integrated; similarly functional and object oriented design are two distinct approaches which in their pure forms do not integrate easily with each other.

Prior to the publication of DO-332, safety-critical software developers had few rules for applying OOT. Programming standards such as MISRA C++ were available and well; those were used and should still be applied along with a commercial static analysis tool to sanitize and improve C++ source code. However, clear guidance for safety-critical OOT design and verification was lacking; DO-332 attempts to fill that void. In functional software design, the control flow is preordained by the developer thus the sequence of decisions (“control flow” in DO-178C) is considered along with the input and output data function-by-function (“data flow” in DO-178C). A typical structured sequence is depicted below:

In object-oriented software design, the individual data flow and control flow aspects are encapsulated via objects as depicted in this OOT class diagram; note the low level data/control flow elements are less visible than in the structured diagram depicted previously: (see the full diagram in AFuzion’s OOT whitepaper available here: Free Download AFuzion’s DO-332 OOT Whitepaper

Safety-critical domains including aviation are risk-averse; new technologies are considered suspect until their safety is proven. In safety-critical software, determinism and verifiability are paramount. For many years traditionalists held that functional software development was more deterministic than OOT: structured software’s execution sequencing was easily determined and repeatable. And at the unit level (software functions and collections of functions within a file), functional structured software was more readily verified: source code sections could be traced directly to associated software low-level requirements (LLR’s) and tested sequence by sequence. Thus functional software design readily enabled determinism and verifiability, while doing so reliably for decades. With such a successful track record of reliability, why would anyone desire OOT with its radical paradigm shift? Simple: the very essence of evolution …

According to Darwinism, evolution occurs in nature when a genetic change is seen to provide advantages for survival. Similarly for technology, evolution occurs when a change provides economic advantage, which is commercial survival. The software evolution from functional design to OOT occurred for the simple reason that OOT increasingly embodied two economic advantages over functional design: 1) greater ability to manage increasing software complexity, and 2) greater reusability. The seeds of aviation software evolution thus sprouted.

To understand the need for OOT is to understand the need for DO-332: aviation software, like all software, was (and still is today) growing dramatically in size, complexity, and thus cost. Enhanced safety meant increased software functionality which meant increased software size and complexity. Functional structured software is fine, even advantageous, when functionality is simple. Computing power increased exponentially according to Moore’s law allowing aviation developers to harness that increased capability.
OOT Introduction.
In the iron age of computing (fifty to twenty years ago), software was written manually by conceiving the sequential instruction execution necessary to accomplish an objective. When close hardware support was needed, assembly language was favored for more direct CPU-level control; otherwise source languages such as FORTRAN, Ada, or C were typically used for scientific programming. Aviation software grew exponentially in the 70’s and 80’s, meaning Ada and C predominated as the language of choice. Improving both reusability and complexity management was increasingly important so smart developers deployed a variety of techniques toward these goals: encapsulation, hardware abstraction, wrappers, and building libraries of software components with generic and robust interfaces. While these techniques improved reusability and complexity management, the commercial consumer and financial sectors went much further: they rethought the entire premise of programming via writing sequential instructions and instead adopted object oriented (OO) programming via a variety of languages designed especially for OO support. The safety-critical world slowly followed though OO posed challenges to verification, and thus certification. To understand why OO had such challenges, it’s necessary to first understand OO.

Instead of merely conceiving and writing (“coding”) sequential instructions for a computer program, OO developers think in terms of Objects. An object contains encapsulated data and procedures which are combined together and thus represent an entity. An object is a data structure that contains data. Instructions (“code”) are implemented within procedures which are called “methods”. The object has interfaces which describe how it interacts within the program. Instead of thinking in terms of individual sequential instructions, OO developers perform programming at a higher level by defining objects and interactions which consist of groups of instructions instead of single sequential instructions. An object’s methods can access, and possibly update, data within the object. Objects have many forms as shown here (see AFuzion’s whitepaper for actual figures).

Objects then can take many different forms, but in each of these forms an object maintains the following attributes:
 Is an abstraction of a real-world concept or thing
 Has a clear boundary
 Has a unique identity
 Knows things about itself
 May perform actions on itself
 May interact with other objects

Like people, professions, and even aircraft, objects can vary dramatically in their functionality, ability, and complexity. At their most simplistic, there are three basic types of objects as depicted below:

As can be seen in AFuzion’s whitepaper on OOT, objects themselves are capable and interesting. But by themselves they are not that useful. Consider an aircraft engine: by itself it too is capable and interesting. However the engine becomes powerful and useful when combined with an aircraft structure, wings, and control systems. Similarly, an object becomes powerful and useful when used within the context of Object Oriented Programming (OOP). The basic concepts of OOP are the software design capabilities incorporated within the programming language, typically C++ for aviation and many of today’s safety-critical systems. These aspects are summarized in the figure below (download AFuzion’s whitepaper for the complete details).

For information on advanced DO-178C training and  software development for safety-critical applications, click here:

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


Free 1-Hr Tech Webinar: Closing DO-178C Avionics Gaps – Thursday May 3, 2018

27 Apr

If you are aware of professional software in today’s world, you know that reliability is increasingly important. Some software such as avionics, medical devices, and automotive increasingly require formal proof of reliability, e.g. “Certification”. The bible of certification is “DO-178C” which is the guideline for avionics software worldwide. But what are the common DO-178C Gaps? How can you re-use most of what you already have?  What are the real costs and ways to reduce schedule and cost impact? Ultimately, what are the top DO-178C Gaps and the Best Practices to close them?

This one hour technical training webinar from AFuzion on Thursday May 3, 2018 will teach you all the above.   Registration is free, but you must register to attend. If you cannot attend, you must register in advance to view the free one-hour recording made available on May 4. Registration is limited to 500 attendees. Free registration here: Click Here To Register for Free DO-178C Gaps Webinar   (AFuzion has performed over 120 Gap Analysis for 80 clients in 30 countries – more than all other competitors in the world, COMBINED.  Here AFuzion shares secrets of closing DO-178C gaps for the first time.)  If you want additional training, next week’s Los Angeles training is sold out but there are four seats available for June 19-20 at Aviation Electronics Europe who has selected AFuzion to provide its technical training – free info here: Click here for Munich AEE June 19, 2018 DO-178C Training Info


May 3, 2018 Free DO-178C Gaps Webinar Agenda:

  • Tool Qualification
  • PSAC
  • Robustness Test Cases
  • Formal Methods
  • Unwarranted Changes
  • Coding Errors
  • RTOS
  • Automated Testing
  • Path Coverage Capture
  • Code Alterations
  • Traceability
  • Modeling Tools
  • Model Requirements
  • Requirement Detail
  • Formal Planning & Gap Analysis
  • Quality Assurance
  • Tool Selection
  • Independence
  • DO-178C as an “Integrated Eco-System”

Vance Hilderman is CEO of Afuzion Inc, a safety-critical consultancy providing advanced consulting services in software and systems development including Training, Mentoring, and Outsourcing. Primary focus is safety-critical aviation and automotive (DO-178C, ISO 26262, DO-254, DO-278A, DO-200B, DO-330, DO-331, DO-332, DO-297, and ARP4754A and ARP4761A) software and hardware development & certification. UAV and TSO C199 experience. He holds a BSEE and MBA from Gonzaga, and a Masters in Computer Engineering from USC (Hughes Fellow). Vance Hilderman is the primary  author of “Avionics Certification – Complete Guide to DO-178, DO-178C, DO-254” the world’s best-selling avionics software book, plus over 30 whitepapers available for free download (max two per person except for AFuzion clients) here: Click Here for AFuzion Avionics Whitepaper Downloads

Ingo Nickles is a Senior Field Application Engineer at Vector and responsible for customer and project support for training and lectures on software development, system design, software testing and agile development methods.