In 2005, tired of working as an electrician, Daniel Herring went back to school at the University of Texas at Arlington to obtain a software engineering degree. Thirteen years later, he is applying some of the expertise developed under that degree as a senior software engineer at CoreAVI, a company that provides much of the embedded infrastructure required to populate today’s cockpits with primary flight displays and digital moving maps.
Herring first entered the world of avionics as an intern with Elbit Systems of America, where he eventually started working full time as a software engineer from 2008 to 2015. During his time at Elbit, he provided testing and engineering support for Apache helicopter and V-22 mission computer upgrades.
After leaving Elbit in 2015, he began working briefly as a software engineer for a credit card processing machine company before eventually joining CoreAVI. He has worked on avionics upgrades for the F-15, F-35, UH-60 and even a space station computer upgrade.
Herring spoke to Avionics about his role at CoreAVI, and how the company is working with new drivers, standards and software development tools to reduce the cost of manufacturing complex avionics systems and machinery in the future.
What inspired you to become an avionics software engineer? Have you always had a passion for aviation?
Getting the internship at Elbit was what mainly drove me to pursue a career in avionics. I also like writing good software, and it seems to be one of the only industries that cares that the software is right.
I stayed in the industry because it requires technical ability to create software correctly and that’s my passion. Creating software that is right, has no bugs and is useful to a lot of people.
How different is the process of writing software for avionics versus your time with the credit card machine processing company?
We go through a lot of process work and design, and verification efforts to make sure everything works. There’s no branches of the code that’s not covered. Working in the non-safety-critical world, there’s no real requirements phase.
A customer gives you requirements, but never formalizes it. When you send them the code, it’s totally a case-by-case basis as to whether it performs the way they want it to. Avionics is also much more fixed when it comes to software.
At CoreAVI, when we send the software to our end customer and it passes flight test, we can’t change it. Whereas if you’re working on software for Android or iOS systems, you can push out an update almost every week if you wanted to.
With the software that you develop, how much collaboration do you have with the hardware vendors and systems integrators?
We do not have a whole lot of collaboration as far as defining requirements; that’s normally straight-forward. The systems integrator typically says, “Give us an open GL driver,” which is a standard provided by KHRONOS. Because we use that open standard from KHRONOS, the system integrator doesn’t have to do much.
On some programs, the systems integrator will say your functionality is good, you’re meeting all the requirements that KHRONOS lays out, but the way avionics operating systems work doesn’t quite match what’s in the KHRONOS definition.
One of the problems with safety-critical software is you don’t get to delete or free memory and then reallocate it, so you can encounter memory fragmentation. With some efforts we’ve been working through FACE, we’ve come up with an API that allows us to recover that memory, and we do have a couple days worth of discussion as to how right something should be with systems integrators as programs go on, but a lot of times it depends on how big the program is.
At the 2018 Embedded Tech Trends conference, a Mercury Systems engineer gave a presentation about the advantages of using multicore processors in avionics systems. What’s the status of multicore adoption for CoreAVI and its customers? Is it a growing trend?
Multi-core is slow coming into the market because of how FAA certification requirements work — very few people want to be the first ones to do it. However, we’re seeing a lot of multi-core chips being used in different fashions, there’s a small segment of people turning all the cores off except one, and that’s not really multi core.
And a lot of integrators seem to be good with that, there’s other operating systems (OS) that treat all the cores as one and schedule them all and provide one OS for all that and tie the thread of execution to a core so there’s not movement, which is one of the things the FAA paper on multicore says to try to do.
This last year and half, a good 60% of our programs are using the NXP series processors, which are all multicore, and they’re using them in multicore fashions. I was with a customer in April where they were seeing some odd behavior happening with our driver. After a week of investigation into what was going on, we discovered that it was because we had missed a very small sequence of our code that needed a mutex around it. But the only way we found it is because they were using multicore, they were running graphics on cores one, two, three and four, and that’s a production program that is in flight test right now.
Are there any exciting programs you’re working on at the moment?
The most exciting program was over the summer working on creating our newest Vulkan driver, for our AMD E9171, so that is really a great step toward simplifying not only the driver but also the applications. It enables shader programs to run in the GPUs.
The Vulkan driver is going to be a huge step forward for us. Because it gives us full control of shaders, the ability to push compute math into the GPU so we can utilize those big single instruction multiple data engines that are there. One customer is doing has created a really nice 3D terrain map using SC 2, we gave them two types of shaders, in Vulkan we can do five.
Vulkan is a huge game changer for the industry, I’m worried it will take so long for the industry to catch up, by the time they have the HMI tools, like ANSYS or ENSCO or Presagis makes, or by the time those tools catch up to use Vulkan in their back end, we’re going to be so far beyond, they’ll say, “That’s great and we’re running great, but what else can we do to improve?”
How do you see what COREAVI provides evolving into the future?
I think I can see in the future our company putting out a full integrated design package, which includes IP hardware, operating systems already integrated with that hardware and drivers for the GPUs. We’re trying to become more of an IP shop, we don’t want to make boards, but we do want to provide fully certified IP systems.
There will also be more of a shift to using off-the-shelf design of hardware, certifiable to DAL A, plus everything that goes on top of it. Doing this in a way such that you can get up and running without all the hassle of integrating an OS and buying BSPs, and that hassle the industry has to deal with. I think for our small industry, that can be a good thing while it still allows invention for lower assurance levels.
The hardware and systems help communize higher DAL levels into a specific subset of the same three to four processors, the same three to four GPUs, and because of that, we get better quality as an industry against other industries so we can reduce the overall cost of building avionics systems. They’re extremely expensive to build.
And if we as an industry can lower that cost, we can use that extra money for better research and development efforts, finding better things to put in the cockpit, better warnings to pilots, better sensors elsewhere in the aircraft. If we don’t have to spend so much to certify displays in the cockpit and pass that burden onto operators, perhaps we can even give passengers in the back an extra drink?