Leonardo Accelerates Development and Compliance of Radar Navigation Software to DO-178C
Challenge
Develop radar navigation software for use on search and rescue helicopters and certify it to DO-178
Solution
Use Model-Based Design to trace requirements to design elements; generate certifiable code; run automated simulation-based, SIL, and PIL tests; and generate reports and documentation
Results
- Recertification cycle times reduced by more than 90%
- Rate of testing quadrupled
- 250,000 pages of interactively linked documentation generated
A fleet of AW101 long-range helicopters developed by Leonardo enables the Royal Norwegian Air Force service to perform all-weather, day-and-night search and rescue missions in High Arctic areas. Each aircraft is equipped with a Leonardo Osprey 30 active electronically scanned array (AESA) radar system that provides the crew with 360 degrees of coverage for surveillance and ground mapping.
Leonardo engineers used Model-Based Design with MATLAB® and Simulink® to accelerate the development of embedded navigation software for the Osprey 30 radar system and satisfy DO-178C design assurance Level C certification requirements.
“Even though we had limited experience with certifying software developed using Model-Based Design with MATLAB, Simulink and DO Qualification Kit, we were able to achieve the DO-178C objectives and satisfy the certification authority,” says Andrew Tortolano, principal systems engineer at Leonardo. “This is a testament to the documentation, test cases, and procedures outlined in DO Qualification Kit; the automation enabled by Model-Based Design; and the support we received from MathWorks engineers.”
Challenge
During an early-stage systems engineering review, the safety case highlighted that, because the Osprey radar system would provide incidental navigation cues to the helicopter’s crew, its software was subject to DO-178 safety guidelines. The radar systems engineering team had not previously developed software in accordance with DO-178 guidelines, and so needed to extend their existing development process to allow them to deliver certifiable source code into the software process. This involved identifying activities or steps that were required to support certification.
The team also had to identify additional tools they would need to complete these activities and then qualify the tools for DO-178 work. They wanted to integrate the qualified tools into their augmented development process so that they could trace requirements, generate code, increase test automation, and reuse models and code across projects.
Solution
Leonardo engineers developed the Osprey radar system navigation software using Model-Based Design with MATLAB and Simulink products that they qualified for DO-178.
Working with MathWorks consultants, the team reviewed their existing system design and developed a road map for restructuring both the design and their workflow to adhere to DO-178 guidelines.
Following documentation and procedures detailed in DO Qualification Kit, the team qualified the following products for DO-178: Polyspace Bug Finder™, Polyspace Code Prover™, Simulink Check™, Simulink Coverage™, Simulink Report Generator™, and Requirements Toolbox™.
Using the Requirements Management Interface in Requirements Toolbox, they linked system and high-level requirements in IBM® Rational® DOORS® to corresponding elements of a Simulink model that captured the system’s low-level requirements.
With Simulink Test™, the engineers authored and conducted simulation-based tests, using Simulink Coverage to measure and analyze model coverage and identify untested model elements. They also identified standard and guideline violations in their models, using Simulink Check to perform checks specific to DO-178.
The team generated almost 10,000 lines of readable, MISRA®-compliant C code from their model with Embedded Coder®. They verified this code via software-in-the-loop (SIL) and processor-in-the-loop (PIL) tests, comparing the output of the simulation with the output of the tests. They also performed static analysis of the code with Polyspace Code Prover and Polyspace Bug Finder to ensure that the code was free of overflow, divide-by-zero, and other runtime errors.
Using Simulink Report Generator, the team generated documentation, including coverage metrics and test results, which they provided to the certification authority’s designated engineering representative (DER).
The Osprey 30 radar navigation solution function was assessed to DO-178 Level C and is now in service on Royal Norwegian Air Force search and rescue aircraft. Leonardo is reusing models and test cases from the Osprey 30 on other projects, including land-based navigation systems, and expects a 60–80% reduction in nonrecurring engineering (NRE) costs for similar projects.
Results
- Recertification cycle times reduced by more than 90%. “Following an early flight test, the requirements for our software were updated,” says Tortolano. “In the past, such a change would have taken a team comprising one systems engineer and two software engineers three months. With Model-Based Design we didn’t need regression testing. We simply reran the whole process with automated code generation, testing, and documentation, making it possible for a single engineer to complete the work in three weeks.”
- Rate of testing quadrupled. “In the past, we could perform a maximum of about 50 witnessed tests per day, and that required two engineers,” says Dr. Calum Brown, lead systems engineer at Leonardo UK. “Due to the automation enabled by Simulink Test and other MathWorks tools, we can now run 1500 tests a week—and passed tests do not need to be witnessed by an SQA engineer because we’ve qualified the tools for DO-178.”
- 250,000 pages of interactively linked documentation generated. “Altogether, we generated the equivalent of around 250,000 pages of interactively linked test reports and other documentation using Simulink Test and Simulink Report Generator,” notes Brown. “As the certification authority has carte blanche to review whatever they want, we felt it was easier to be able to provide evidence for everything we had done. If the DER wanted to see any particular result, it was available for them and fully linked to our model, which really built their trust.”