Getting the requirements right in avionics safety certification, FACE compliance, and certifying UAVs
StoryFebruary 28, 2017
In this Q&A with Jim McElroy, Vice President of Sales and Marketing at LDRA, he discusses how poor requirements can doom avionics certification efforts, common mistakes engineers make in this process, Future Airborne Capability Environment (FACE) compliance, and how certifying commercial-off-the-shelf (COTS) hardware to Design Assurance Level A for avionics safety certification. He also looks at how certifying unmanned aircraft to fly in civilian airspace may require a new mindset for everyone involved. Edited excerpts follow.
MCHALE REPORT: Please provide a brief description of your responsibilities at LDRA and your group’s role within the company?
MCELROY: I manage a sales team here in the U.S. and marketing for the company as a whole. As a relatively small and focused company, we have lots of moving parts and being nimble and responsive to our customers is critical to our success.
MCHALE REPORT: LDRA is heavily involved in enabling safety certification of avionics technology to DO-178B & C and DO-254. What are the most common mistakes engineers/companies make in the certification/requirements process?
MCELROY: Most mistakes occur from having poor requirements, which then affects the cost of software rework. The cost of software rework is a key business driver for our customers and they need to improve how they develop and verify their software. On the verification side of things, people don’t plan well enough for testing, which stems from a lack of commitment to proper requirements definition and functional safety requirements. During their overall software development life cycle they do not put enough time and effort into setting up and using proper software quality and test applications, which makes it hard for them to be competitive.
In the DO-178 world in particular, many of the suppliers frankly don’t understand the requirements of the standard as they pertain to object code verification and data and control coupling, which ultimately leads to problems down the line toward integration testing. They need to leverage automation technology to address these requirements in a cost-effective manner.
Customers also need to view requirements from a behavior and security perspective. For example, if a requirement changes at functional or security level they need to ask what will be affected down stream in the life cycle by that changed design or changed code. Similarly, in the reverse direction, what if that piece of code needs to change? What is the impact of that change? What tests need to be rerun? They need to know where it comes from and where it may go long term in the design. It’s important to get a 3-D picture so that you also look at it from different perspectives such as the viewer standpoint.
I also don’t think a lot of companies to this day understand transparency in the bidirectional process requirement for high-assurance software. This is a fundamental concept, which ties into the above. At any point in the lifecycle, developers and auditors should be able to easily poke in and understand the decision process on why a change was made and where it came from. Has it been properly tested? Where is the proof? Fundamentally, it is important to be able to see into the process at all phases of the development lifecycle. Proof is provided through transparency, and this is important in the software qualification and certification process.
MCHALE REPORT: There has been discussion at various industry events over certifying COTS hardware Design Assurance Level (DAL) A. Do you see this eventually happening or are the requirements to stringent for off-the-shelf equipment to make that leap?
MCELROY: I think at this point it will get to a maturity level where we are there. A big driver that may limit it is the IP issue. For suppliers to maintain a competitive stance they will not want give up their IP.
The reality of the matter is that software has come so far, in particular software rework and it will be the same thing with the hardware side. Not only has the process been well-defined overall, but reuse of components in the process has also become better defined. The next challenge here will be ensuring security in these devices. The reality is that many systems use parts from all over the world and not always with proper traceability so security should be a real concern.
MCHALE REPORT: How do your military avionics customers differ from those of your commercial avionics customers in terms of their requirements? Or are they quite similar?
MCELROY: Over time, they’re getting more similar. Historically, the defense customers have not had the requirement to put the same level of rigor into the software development life cycle because they were not concerned with standards like DO-178C. However, now for example, with both commercial- and defense-related UAVs [unmanned aerial vehicles] entering commercial airspace, there is more demand for high-assurance software, and DO-178C sets the standard. As a result, defense customers are now more interested in following standards like DO-178C. At the same time, they are trying to produce software that can be leveraged on multiple platforms to save time, effort, and money. The Future Airborne Capability Environment [FACE] is the perfect example of this where military branches like the Army and Navy are focused on building high-assurance reusable software for the future.
Security is a very real concern for both our commercial and defense customers from both the hardware and software perspectives. Our customers are looking for assistance in building secure software and hardware, and this needs to be built into systems from the ground up. There are many aspects to security, but the bottom line is that both commercial and defense customers are looking for best practices in developing secure software and hardware.
MCHALE REPORT: What challenges remain for certifying avionics hardware and software for unmanned systems? Are the safety certification rules the same as for manned aircraft or do new regulations need to be developed?
MCELROY: When it comes certification and regulations for UAVs, there needs to be a paradigm shift in terms of mindset to accommodate differences in decision making on the ground versus in the air. It needs a different perspective. The control logic in the UAV needs to adhere to rigorous software development processes, which need to incorporate where the decisions that are being made. The experts in the avionics and regulatory world are working hard to address the very real concerns of mixing UAVs into the commercial airspace. Personally, I believe the regulations for UAVs that fly in these spaces need to adhere to the same levels of assurance.
MCHALE REPORT: How does the U.S. military’s FACE standard enable safety certification?
MCELROY: I think the FACE organization is doing a tremendous job from the standpoint of setting the standard for software interoperability and the verification process for those software components. From the safety-certification perspective, I would say that FACE is implicitly being drawn into the safety certification process. Airworthiness, although not at the head of discussions within FACE, is always present. FACE is about interoperability and as more and more software components become certified, these components will inevitably be driven to higher levels of software quality and reusability. FACE will ultimately lower the cost of developing high-quality software and certified aircraft. It follows that many of the stakeholders involved with FACE are also very interested in addressing safety in the airframes on which they are deploying their software.
MCHALE REPORT: What will be the game changer for safety certification and code analysis over the next five years? Predict the future.
MCELROY: We don’t see any one particular game changer; however, what stands out is the drive to efficiency and transparency in the software development lifecycle. We see the lifecycle becoming increasingly automated. Requirements traceability, application lifecycle management, model-based design, software development, verification, simulation are all becoming bi-directionally linked so impact analysis can be quickly determined, and quick and appropriate decisions can be made.
Personally, I believe security will be a major influencer in safety certification as systems will not be safe unless they are also secure. The requirements for security will demand changes in the software and hardware development processes. Automation and risk analysis will play key roles in how systems will be developed efficiently yet safely and securely.
As a result, we see an evolution of the tool chain. OEMs and suppliers of today’s avionics systems need tool vendors to give them better methods of developing today’s complex systems safer and faster. To be competitive, they must use automation and leverage today’s development and verification technologies to produce high-assurance software faster and at a lower cost. Those who continue to use traditional manual methods will simply not be able to compete.
Jim McElroy, Vice President of Marketing at LDRA Technology, is focused on expanding LDRA business in the embedded software verification market by improving developer productivity and software quality in critical application development. Before joining LDRA, McElroy held executive-level marketing and business development positions with Green Hills Software, Telelogic North America, and I-Logix as well as holding industry-level software development positions at Lockheed Martin and Raytheon. McElroy has a Master of Science in Computer Science from Fitchburg State College and a Bachelor of Science in Computer Science from the University of Massachusetts.
