Archive | UAV Development Certification DO-178C & DO-254 RSS feed for this section

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

The (un)Lucky 13 Aviation Safety Commandments!

13 Apr

The 13 (un)Lucky Commandments of Aviation Safety

Ethiopian Airlines Flight Remains post-Crash, March 2019

Fellow Aviation Engineers – I was discussing recent aviation headlines with our AFuzion senior engineering staff and it’s unanimous: the past six months are the historic Tipping Point which will be spoken of for the next 100 years. Remember your school Physics class and the video of the failing Tacoma Narrows Bridge emphasizing the need for safety via resonant frequencies? If you don’t know that one, you are either not an engineer or you skipped class that day.  Similarly, most of us have heard of the 10 Commandments received by Moses … Well, did you know there are ‘AFuzion’s Thirteen Commandments of Aviation Safety 2020”? If not, keep reading …

Yes, times were simpler back in Moses’ day – the aviation technology world is far more complex so an (un)lucky 13 Commandments are required. Our aviation great grandchildren will be discussing 2019 one hundred years from now as well. Perhaps we will have actually learned from these Thirteen Commandments of Aviation Safety for 2020. Yes, these are directed at the Boeing 737 MAX disasters, and specifically how we can learn from and apply these Thirteen Commandments; just as bridge design changed after the Tacoma Narrows disaster, aircraft safety, design, and oversight will be forever changed starting today. Hopefully. But only if we all understand and apply these Commandments. So here, I’ve summarized them for all current and future aviation engineers: for the next 100 years …

The (un)Lucky 13 Aviation Safety Commandments:

1.      Follow mandatory ARP4761 for Development Assurance Level (DAL) Assignment. When the safety assessment provided to FAA and EASA states the 737 MAX MCAS will only adjust the Horizontal Stabilizer by 0.6 degrees and then the airframer changes it during flight testing to 2.5 degrees x 2 activations = 5 degrees, that is a fundamentally different design and Major safety impact. Such requires a formal Functional Hazard Assessment (FHA) update and a DAL reassessment, in this case resulting in a DAL of “A” (1 x 10—9) probability instead of DAL B (1 x 10—7) or DAL C (1 x 10—5) as was originally specified and approved. Remember: the United States 14 Code of Federal Regulations (CFR) 25.1309 is not optional and this failure violates the “Update Safety Assessment Continually Commandment”.

2.     Utilize mandatory redundancy for critical systems. When people can die, the Development Assurance Level is A if the failure can cause a plane to crash or Level B if passengers can die. For Level A and B, the required reliability is met via redundancy. Yes, the 737 MAX was equipped with two sensors (redundant), but MCAS only actively used one of the sensors thus violating the “Redundancy Commandment”.

3.      Follow mandatory ARP4754A processes for System Requirements. Software is only as good as the System requirements mandated to precede it. Those System requirements must include Safety and derived requirements from the FHA and Preliminary System Safety Assessment (PSSA) per ARP4754A. This includes power-up testing of the Angle-of-Attack sensor, redundancy requirements, and pilot display/awareness requirements. The 737 MAX system requirements missed this Commandment therefore its software was doomed; subsequent patching (changing) of software to address missing Systems requirements is just another form of broken “System Commandment”.

4.     Implement both Continuous and Power-up Built-In-Test (BIT) on Power-up to test both Angle-of-Attack (AOA) Sensors and mismatches. When the sensor angle outputs differ by more than a nominal calibration amount (1-2 degrees), either both sensors should be deactivated with an accompanying pilot annunciation and MCAS deactivation, or a 3-sensor voting design should instead be deployed as befitting the MCAS system’s true DAL A FHA designation. Failure to consider these is a clear violation of “ARP4754A’s Continuous Safety Update Commandment”.

5.      Follow mandatory System Safety Assessment (SSA) ARP4754A/4761 FMEA and MTBF calculations to determine the AOA sensor reliability was insufficient for DAL B let alone DAL A; use this finding to update the design and apply to an updated PSSA thus requiring active sensor redundancy usage. Failure to do this violates the “ARP4761 FMEA/MTBF Validation Commandment”.

6.      Implement Built-In-Test (BIT) on Power-up to test both Angle-of-Attack (AOA) Sensors and mismatches. Evidence indicates the active LionAir sensor was off by 20-degrees while the plane was still taxiing yet such result was not actively used in MCAS system deactivation or pilot annunciation; this violates the “ARP4754A Derived Safety Requirement Commandment”.

7.     Follow rules for mandatory display of aircraft safety conditions including explicit pilot annunciation of MCAS Activation. When flight data recorders yield soon-to-be-dead pilots thumbing through operating manuals to determine what’s going on, it’s clear the 737 MAX pilots were not informed of MCAS system activation whose AOA sensor failure plunged them to the surface. Boeing previously had an enviable record deploying aircraft where the pilot exercised primary control versus a more automated-avionics approach. While either approach is feasible, the pilot-in-command strategy (historic Boeing and 737 MAX training protocols) require the 737MAX pilots to be informed of MCAS activation. They were not and the resultant crashes result from violating the “Promote Pilot Situational Awareness Commandment”.

8.     Follow New Aircraft Cert rules for New Aircraft. When the 737 MAX aircraft revision and heavy new engines so significantly changes the Center of Gravity thus requiring a new system (MCAS) to compensate, this is a Major design change. Adding an all-new system to mitigate the 737 MAX’s higher stall probability is good, but this yields a New design with mandatory higher recertification standards and requisite mandatory pilot retraining with significant procedural and operating manual updates. Sneaking in a Major change via a Minor update violates the “Certification Transparency Commandment”.

9.     Pilot workload and situational awareness are the single leading cause of aviation safety incidents; in my personal pilot ground-school training, pilot procedures and situational awareness were the principal training focus. Mandatory ARP4761 FHA processes require an assessment of pilot workload; both 737 MAX disasters occurred minutes after takeoff during initial climb out and relatively low altitudes: a high-risk area for aviation safety and pilot awareness. ARP4761 requires consideration of flight phase and pilot workload; had this been properly performed during the 737 MAX and MCAS FHA, the MCAS system response should have lessened the automatic horizontal stabilizer deflection angle while simultaneously alerting the pilot. Remember, automatic descent initiation is obviously problematic when the aircraft is still climbing out after takeoff – the ground (water) is just 40 seconds away instead of 5-10 minutes. This failure violated the “Consider Flight Phase and Pilot Workload during FHA Commandment”.

10.  Keep Certification independent: Maintain FAA or 3rd Party (Independent Designated Engineering Representative) oversight and proactive involvement instead of increasing Organization Design Approval (ODA) fraught with incestuous schedule/profit driven motivations.   Yes, this requires more FAA work meaning more funding (the annual FAA funding game is the laughingstock of the aviation world, trust me). Listen to the senior FAA personnel who specifically complained about the lack of oversight else such violates the “Independent Certification Commandment”.

11.   Apply mandatory ARP4761 System Safety Assessment specifying 10—5 (or 10—7 if active DAL B) Mean-Time-Between Failure (MTBF) to AOA sensors. Affirm AOA manufacturer’s MTBF calculations via screening and retest at airframe integrator. The 737 MAX sensors should not have experienced two separate failures on new aircraft. Such poor sensor reliability violates the “Prove Device Failure Rate MTBF Assumptions via Screening and Testing Commandment.”

12.  Keep things simple: aircraft are designed for the Average pilot, not the Best (military-trained) pilot. Forcing a pilot to learn to override a system via control stick updates, motor cutoff and trim adjustments is stupid (the Lion Air routine on the day’s prior flight with a well-trained pilot hitching a ride in the jumpseat). Instead, simply display “MCAS Activated – Continue or Disable?” on Primary Flight Displays with quick access for pilots to disable. Otherwise we violate the “Keep It Simple for Average Pilots Commandment.

13.  When the plane almost crashes on Sunday (Lion Air) it’s not readily cleared for safe flight the next day Monday without fixing the problem. Period. Aviation safety is built upon Root Cause Analysis and if you could not find the root cause you certainly could not then analyze it. This violates the “Don’t Be Stupid. Period. Commandment.”

There: Thirteen Aviation Safety Commandments. Interestingly, these Commandments are Forgiving: Had the 737 MAX events violated only one, or only seven, or only 12 of these Commandments, it’s my opinion the two crashes could have been prevented. But when thirteen of thirteen Commandments are broken, it’s time to seek Forgiveness – but only after going back and learning Prevention. Because after all, requesting Permission really is better than requesting Forgiveness.

Author’s note: AFuzion normally sells its “Applying ARP4754A” whitepaper and “Applying ARP4761” whitepaper for $50 each. But in the interest of world aviation safety, these two papers are free for anyone to download from now through April 30, 2019. Simply go to the Whitepaper page on www.afuzion.com. Download for free here: https://afuzion.com/rp-4761a-introduction-avionics-safety/

Safe Skies, Vance Hilderman, CEO, AFuzion Inc.

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 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, https://afuzion.com/training/cast-32a-multi-core-processing-training/

 

KEY FEATURES:

  • 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