Commercial, Embedded Avionics

Column: Avionics and Rosetta Stone

By Charlotte Adams | December 1, 2012
Send Feedback

Over the last few decades the foundation for on-board software, hardware and overall platform and system design assurance slowly but surely has been laid. DO-178B (now C) revolutionized software design assurance, then DO-254 did the same for complex electronic hardware, and finally — two years ago — the Society of Automotive Engineers (SAE) 4754A added an improved approach for aircraft and system development assurance. So now, at least according to FAA, the standards edifice is in place.

That’s true in a sense. You could say we have a foundation, walls and a roof. But do we have a cohesive structure? According to some observers, the answer is, not yet. While 4754A calls for a two-way information flow between high- and low-level design, it doesn’t nail the pieces together. What’s still missing is a common understanding between the systems, software and hardware engineering parts of a project, a common language between the respective practitioners — the avionics equivalent of the Rosetta Stone. What better time than the eve of NextGen to get it right?

Slotting the standards together is important because of today’s highly integrated, interdependent and increasingly complex avionics systems. Failures aloft today are potentially far more serious because the avionics automate many more of the pilot’s formerly manual tasks. And design assurance is much more difficult.

We can’t afford to have situations where companies develop systems “by the books,” where specialists go about their software and hardware design tasks without an eye to the system as a whole. This challenge is magnified when these specialists use different mechanisms to communicate. Miscommunications can result in major problems in a project, causing expensive delays.

Idealists would like to see a “holistic” standard that brings safety-critical digital designs — whether implemented in software or complex hardware devices — and systems under a single set of guidelines. Pragmatists will settle for less — a common understanding between developers and stricter scrutiny of the interfaces between software and hardware at the systems level — to promote a more cohesive development process.

A recent addition to the assurance standards mix, 4754A expands the concept of development assurance to the aircraft and systems level and “provides a cohesive approach,” according to FAA. Unlike its predecessor, the revised SAE document was mandated by FAA in an advisory circular last year.

But SAE makes it clear that it excludes coverage of detailed software or electronic hardware development. It aims to fill in the systems area above software and hardware rather than to nail down the gap between what you can see from the outside (the system) and what’s going on inside (the software and hardware).

Traditionally, systems engineers write systems requirements in English text. Hardware and software engineers express themselves, respectively, in technical dialects like VHDL and C++. So the three groups aren’t communicating as precisely and clearly with each other as might be desired. Model-based development potentially could help, but systems engineers typically aren’t versed in that discipline. 

Short of another standard, several steps probably would be required to bridge the gap. First would be to perform extra analysis and verification to cover the interdependencies between high-level and low-level design, as well as to receive additional guidance from the authorities about applying DO-178C and DO-254.

In addition to manual methods, developers may want to employ technologies such as System Modeling Language (SysML) or Unified Modeling Language (UML) to express desired behavior in a common medium, and then to employ associated tools to evaluate and verify hardware and software requirements and implementations against system-level requirements. This would also be more precise and readily verifiable than English.

SysML can be automatically converted into software programming languages such as C, C++ and Ada. Conversion of SysML to VHDL is less mature and requires more manual effort. But as this translation capability improves, the possibility of a common language between system, software and hardware engineers emerges.

Industry recognizes the potential of technologies like SysML. In fact SysML in aviation was the topic du jour at a conference held by the French systems engineering group, AFIS, in September. Let’s hope this interest grows into a trend and a common language emerges before NextGen arrives.

Charlotte Adams has covered embedded electronics and software standardization issues for more than a decade.

Receive the latest avionics news right to your inbox