What are the current challenges in software engineering for avionics? [closed]

Question

I'm a software engineer working outside the aviation field, but I'm really passionate about avionics and I'd like to do my Master thesis in the area of software engineering for avionics. Unfortunately, I lack the avionics background in order to know which are the key challenges in this field. I would to like to ask if someone can share some insights on it or maybe share some references for this topic.

Thank you!

Answer 1

As others have mentioned there are a lot of aviation specific aspects to the avionics software development process. The majority of these fall into two main categories; functional and certification.

Functionally, it has to perform its intended function reliably and safely. To do that it has to be developed to a Design Assurance Level (DAL) commensurate with the criticality of the software function. Process standards exist that all companies follow when creating their internal processes.

The key standards are:

• DO-178C, Software Considerations in Airborne Systems and Equipment Certification
• ARP4754A, Guidelines For Development Of Civil Aircraft and Systems
• ARP4761, Guidelines and Methods for Conducting the Safety Assessment Process on Civil Airborne Systems and Equipment

And there is the actual function of the software and the realities of the aviation market. Most of the software is real-time embedded code and has unique interfaces to various hardware. And then there's the fact that the average life of an aircraft is 20 years or more and it requires ongoing support.

The second part, certification boils down to demonstrating to the certification authority that your software meets all the requirements and is safe. That boils down to primarily requirements traceability, testing, and documentation.

That's all challenging work, but while it has evolved over the years, the process hasn't really changed that much in the last 25-30 years. Avionics companies know how to do this and new hires learn the process when the come on board. What has changed is the tools and the hardware platforms and the expectations of the aircraft manufacturer's.

One of the biggest challenges is dealing with hardware obsolescence. The lifecycle of many processors is a few years at best. And as they've become more complex, there are resulting questions about the DAL of the hardware which resulted in RTCA DO-254 / EUROCAE ED-80, Design Assurance Guidance for Airborne Electronic Hardware, the hardware equivalent of DO-178C. The issue is that most processor manufacturers have no interest in any of this as aviation is a trivial percentage of their market. So avionics designers resort to multiple dissimilar processors with crosschecking, which adds more overhead and complexity to the software. Some have started designing their own processors to address the DAL, but even that doesn't solve the lifecycle issue as they typically rely on an external chip fab and the technology changes cause the fab to declare the process obsolete.

So what are the real current challenges? The aircraft manufacturers want lower SWaP-C -- Size, Weight, and Power, and Cost. The first three are hardware. That's being addressed by increased integration and Integrated Modular Avionics (IMA). That, in turn, affects the software as now your software has to run hardware that you don't control. You get to develop it on a development platform and then integrate it onto the aircraft. Ref: DO-297, Integrated Modular Avionics (IMA) Development Guidance and Certification Considerations. And if you want to sell it to more than one manufacturer, it may have to run on different hardware. The key to most of these is the IMA platform operating system which allows the functional software to be (mostly) hardware agnostic.

The last 5 years or so, the major challenge to avionics software has been to reduce cost. Not just the cost of development, but the cost of integration and the cost of changing the software in the future. When the manufacturer askes for a new feature and you add it to the software, you have to flow through that process all over again. That can get expensive real quick. To reduce cost it takes a well designed software architecture that allows for modular design and testing capabilities at the module boundaries to limit the impact of change.

Answer 2

I don't have experience with avionics, but I do have some experience with medical and the principles are similar.

In my not very humble opinion, the main challenges are paperwork, paperwork and more paperwork and having to live with technology that is either 30 years old or total usability horror, because it is not objectively safer, but happens to have the paperwork done for it.

For safety critical systems, of any kind, not just software, it is required that risk analysis is done and the system must be designed and implemented so that qualified estimate of mean time between critical failures (= failures that result in an accident) is lower than some value. For systems that can kill multiple people the requirement is usually 10⁹ hours.

That estimate involves all kinds of failures, both software and hardware, and across all parts of the system. The components (both software and hardware) are tested to get some basic reliability for them, and then checks and backups have to be provided so that any particular type of fault, which is almost always more likely than once per 10⁹ hours, won't result in an accident, and the combined probability of enough faults to cause one at once is below the desired threshold.

Now for software that means that it has to be comprehensively tested, which is fine. But it is also required that the tools involved in building it are “validated”. The stated purpose is that you know what is the risk of fault in the tool creating an undetected fault in the product, which is needed for the overall risk analysis. However:

• The way I've seen it done in practice usually missed the point completely. Some requirements were created and then the tool tested to show it satisfies them. This was a lot of work, but the requirements defining what the tool is supposed to do—e.g. for a compile the specification of the language—didn't really tell anything about either risk of the tool introducing a bug—e.g. compiler producing functionally different code in debug and release mode—nor the risk of it becoming critical—if you test what you fly and fly what you test, you don't create any different builds that could have a difference.

• Due to the amount of work involved it means you are often stuck with a special compiler that only supports old standard (like C89), has a lot of known limitations and comes with its own terrible, ugly IDE, only because the vendor did the validation for it while the general tools like gcc or clang don't have it. Now take into account that the validation only really makes sense in context of the specific project, so all that paperwork may not really improve the reliability of the product, just serves as an important liability shield for the company.

Fortunately the code itself tends to be fairly simple. Anything that should be real-time, i.e. have guaranteed response time, which is case of most avionics, can't be too complex, because you couldn't verify it does not have any slow worst cases.

So specifically for software engineering I'd say the current challenge is that the surrounding processes provide diminishing returns on reliability while ever increasing the barrier for innovation.

Answer 3

Developing software for avionics is considered a specialized field with respect to requiring knowledge of embedded systems skills, handling communications protocols between avionics systems, and adhering to the appropriate industry standards. None of these things are particularly difficult, but the skills and knowledge are generally built up over a period of time in one's career.

Understanding embedded systems development is critical because, which a device might be using an operating system, some avionics hardware is programmed as a "bare machine." In this regard, you get no help from device drivers, file systems, or other OS-type services. On the other hand, there are likely code libraries that may be used to access certain parts of the embedded system, so you just need to understand the API.

Understanding inter-device communications is important because different devices exchange information using various types of protocols. The military in particular uses MIL-STD-1553 or ARINC 429 as standards. Some of these are translated into commercial equipment.

Finally, if you're developing software for the commercial industry, ALL software must adhere to and be compliant with the DO-178B standard. When the FAA certifies a piece of equipment, the testing is very comprehensive and includes reviews of the DO-178B certifications for the organization.

Answer 4

The key elements that differentiate flight system software from other less-specialized types of software are: Functional Safety, real-time, determinism, SOTIF (Safety of the Intended Function). Derived from these are: functional safety architectures, concurrent programming, analysis and design methodologies, development methodologies, coding standards, testing methodologies, etc. And the broad umbrella of "avionics software" covers everything from boot-loaders, hypervisors, OS abstraction, Operating systems, drivers, middleware, System Services, and flight programs, User interfaces etc. Each of which one could spend their entire career in. Also, as one progresses up the software chain from, in some cases, tester, coder, developer, designer, architect, systems engineer, systems architect, functional safety manager, chief architect... the considerations change drastically. A programmer follows a prescribed process, prescribed coding standards, prescribed testing methodologies etc, and may be unaware of the reasoning behind some of the design decisions being made by the architects and systems engineers.
As I see it, the area where innovation could make the biggest impact is in the approaches taken to satisfy functional safety and SOTIF. This is largest cost driver as it leads to the need for certifying hardware and OS's, as well as a significant increase in the cost per line of code, costs for FMEA, FMEDA, or program cost multipliers like triple redundant architectures with N-version programming.

I'd highly recommend a degree in Functional Safety. This can take you far in not just aviation, but in automotive, industrial robotics, etc.
And the pay is not bad either!