Hello everyone, and thanks for joining this webinar !
My name is Yves Gerster and I’m the Aerospace Industry manager at Speedgoat.
Today we are going to talk about Hardware in the loop and automated testing applications for Aerospace.
For those of you unfamiliar with the concept of Hardware in the Loop or short (HIL), I am going to give you a quick introduction to this topic.
Also, you will see workflows and solutions, which may be relevant for you.
I am excited to show you applications for the most relevant use cases across the Aerospace Industry.
My goal is to make three things happen in this webinar.
First, I want to show you, how Speedgoat real-time testing systems enable you to test your aerospace control designs and control systems.
Second, you can experience how Speedgoat systems provide you a most seamless workflow for both, desktop and real-time simulation and testing from Simulink.
Last but not least, you will understand how hardware-in-the-loop simulation and bypassing enables you to meet testing requirements for certification.
Where do you need HIL and how is this linked to Real-Time Simulation and Testing?
A development workflow has several stages. In aerospace a development starts with a defined set of requirements. In order to save time, you want to do a desktop simulation of your product or your plant that you're developing. In order to see, how your early design behaves in the actual environment, you can leverage controls prototyping.
After the successful implementation, you want to test your controller. This can be done using Hardware in the Loop testing. Since you are working partly on the actual hardware, and partly on a modelled or simulated component, this part of the development process is called Model-Based Design. You will hear more details about this in a minute.
So let's zoom in and have a look on what Hardware in the loop actually means.
During HIL testing, you have a hardware under test like an electronic control Unit ECU or a flight controller.
You can simulate the environment of this controller using a plant model.
The Hardware under test and the plant Model emulated by a real time target machine form a closed loop.
Using test automation, you can run many tests in a sequence and verify that all requirements are met.
The difference from HIL to rapid control prototyping is that in rapid control, prototyping the hardware under test could be your aircraft or iron bird. The development task is focused on the design of the controller. This means that the real time target machine is emulating the controller and executing the code of your embedded control design.
What are the benefits of Hill testing?
Using Hill testing you can test before all components of your project are available. You can fix bugs earlier, and corner cases and exceedances can be simulated without damaging the actual hardware.
Further components can gradually be integrated.
Virtual integration and testing solution can be leveraged such as deterministic emulation of plant sensors and actuators. You can use plug and play interfacing and leverage the benefits of test automation.
To Summarize, you can deliver better and faster using embedded software. While reducing costs and risks.
So, why is this reducing costs?
If you have a look of where errors typically are introduced and where they are detected, you can see that most of them are introduced at the beginning of a product development.
However, most of them are only detected at the end in the testing phase. And obviously, if an error is not detected in the testing phase, it gets really expensive. However, if you can start testing your specification on the very left side, fixing errors is much cheaper.
Having seen all this, you may wonder, how such an aerospace development workflow may look like.
To answer this, let’s ask Wess Gates. He is the principal Industry Marketing Engineer for Aerospace at MathWorks. Wess has a broad background in the aerospace industry and worked for leading aerospace companies such as Boeing.
Wess, could you describe the general design workflow for aerospace vehicles?
Thanks for having me. Yves that's a great question.
Aerospace systems are fairly complex, operating in rigorous and very harsh environments that increase the design challenges on engineers as well as the business challenges to meet the cost and schedule of the customer. The environments range from undersea to land to air all the way into deep space and the variety of vehicles and technologies that span the spectrum is limitless. It's not just the vehicles themselves that compose the system, but it's also the subsystems involved that could be treated as systems in their own right that come together to make these complex systems practical, possible and cost feasible. Technologies ranging from transducers to communication technologies, complex structures with integrated sensors all the way through propulsion and of course each of the multi disciplines required to make these subsystems. And of course the finally integrated technology possible.
In an ideal world a system development life cycle would start with the systems engineering process, but often that's not the case. Systems engineering and detailed design happen simultaneously as both ends of the engineering disciplines strive to meet the cost and schedule and technological challenges. And of course, this has to happen in a multi domain design environment so that all these complex technologies can come together and form a functional, reliable, robust system that meets cost and schedule.
I hope to convince you by the end of this webinar that the role of hardware in the loop and rapid control prototyping can support what we call a shift left paradigm. In other words, we'd like to shift testing and development sooner into the early stages of the design.
Let's look at a very simple example of this requirement, which is suggesting that the airplane shall demonstrate trim stability control install characteristics are not impaired below a level needed to permit continued safe flight and landing.
We might look at this requirement and determined that it's going to decompose into transducer software in flight dynamic functionalities that need to be addressed. Within these decompositions, the functions that will be impacted would be something like the hydraulic actuators. The embedded software which will require the involvement of the stability and Controls Group, which may later involve aerodynamics. At the detailed design level of the requirement design space.
That's classic systems engineering and model based systems engineering. We'd like to be able to determine, establish, or develop simulations and models that bring these disciplines together with a link to the data and the artifacts that are generated so that we can continually verify and validate that the requirements are being met and continually synthesize as changes to the system are required. And of course, we'd like to be able to test and trac and have these data artifacts linked in a closed loop fashion.
So that we always know and understand how and why decisions were made, and so that we could be able to. Justify our decisions and choices to the customer. By modeling in the early phases of the design we're talking about behavioral models, kind of like black boxes on off things that don't necessarily describe the math or physics of the system. But as the development cycle marches along in time, the maturity of the models increased by the addition of mathematics or physics. And then we use these higher Fidelity models to drive the decisions of the prototyping and development phases, whether it's hardware or even complex software systems so that we can realize a fully mature system in the design cycle.
Of course, these activities never happen in a linear fashion, and it's OK, and definitely not uncommon. For sometimes the understanding of the requirements to lack the decomposition or functional allocation. Sometimes you might be further along in the design that you think and then. Figure out that once their requirements are better understood that you're not as far along as you thought in the design cycle.
What we'd like to do is perhaps minimize these variabilities throughout the development of a system. And one great way to do that is using model based design which helps you maintain your digital thread or the linking of your data. Your artifacts, annual reports, and the reasons that were used to drive the test and production of the system.
Hardware in the loop can be seen as a path to a digital twin. Over the system, development lifecycles went proper model based systems engineering and model based design practices. Are utilized to develop models from the component subsystem and even system level. And ultimately integrated into an entire or complete model of the system, which can then be deployed in a real time sense to a real time target, such as those offered by Speedgoat. Keeping in mind here that this is a complete model of the system, so vehicles, sensors, actuators, algorithms, everything, including test data to increase or improve model Fidelity, which can then be integrated with the control system. Of the vehicle or system of interest in a closed loop sense and allowing the real time system model to drive the dynamics in a closed loop fashion for the control system.
And on the flip side, of course, real physical hardware sensors and actuators can be connected to the real time target machine when that makes sense. For example, an inertial measurement unit stand alone on a table doesn't add much value, so the IMU may be simulated or otherwise, and I am you could be placed on a dynamic or shaker like table to simulate motion. It really depends on the level of investments and complexities required to do complete system modeling and hardware in the loop integration test. In the same way, when model based systems engineering and model based design is implemented correctly, models can be generated directly into code automatically without having to port or re code the models.
At that point, the focus will be on integration of the models with the embedded system and the hardware in the loop offers a full system and subsystem workflow.
The path to developing or realizing system is seldom linear and it's important to provide kind of a closed loop or exit or entry point at any point during the design and development phase. So for example, you could be focused on software and hardware integration or algorithm integration, and as you move closer to system, you're more concerned about verification and validation as you move away from the system and into the detailed design, you might be looking at model verification and validation. And of course you're looking at hardware, an subsystem verification and validation, whether that's in software or physical interfaces which are normally examined during the development testing phase, whether it's component or subsystem level testing and system integration. So in a very high level sense, that's what we mean by hardware in the loop. Extending hardware in the loop with a real time connection to a physical assets, in other words, the real system of interest so that data is constantly interchanged between the physical asset and the hardware in the loop setup turns it into a digital twin. The real time data from the physical asset allows real time update of the models for better certainty, and of course Fidelity as the maturity of the effort continues.
Thank you Wess, that was very interesting. Now that we've seen which aerospace workflows precede the hardware in the loop testing, let's have a look at which platforms you can use to do hardware in the loop testing.
The real-time simulation and testing platform using MATLAB and Speedgoat simplifies your workflow and let‘s you design and test better controllers faster.
You can innovate and you are not constrained by embedded testing environments or with hassles of integrating solutions.
The major benefit is a plug-and-play real-time solution that shields you from interoperability issues.
MATLAb and Simulink provide a unity of simulation and testing with real-time target hardware.
The seamlessly integrated solution is composed of two main components.
The first one, is Simulink Real-Time, the solution for real-time test and simulation from within MATLAB and Simulink.
It comes with several host capabilities that allow you to easily create, control and monitor your real-time applications, and serves as your real-time operating system.
The second component is the scalable Speedgoat real-time target computer equipped with input output modules, short: I/O. The real-time application created from your Simulink model runs on it together with the Simulink real-time operating system.
Let’s now look at the products and services from Speedgoat to understand better what a real-time system is comprised of.
Each system is configured to your individual requirements about performance and I/O.
Changing requirements are not a problem, as you can reconfigure I/O. You can choose from a vast range of I/O connectivity options and exchange them at a later date.
All real-time target machines are expressly designed to work with Simulink and Simulink Real-Time,
We don’t only support the current releases, but we also make the promise to support future releases.
Our hardware quality, our long-term warranty and maintenance services ensure long-term operability of your real time-testing hardware.
Delivery of each real-time system includes the real-time target machine, I/O modules configured to your needs, together with accessories such as terminal boards and cables, and the Speedgoat I/O Blockset for Simulink. The blockset library allows for seamless connectivity to the hardware.
Speedgoat is supporting all key protocols for the Aerospace industry, such as ARINC 429, AFDX or MIL-STD-1553. Overall, we support over 200 I/O modules.
We also have general purpose protocols such SPI, I2C, Ethernet and a vast range of analog and digital protocols. You can leverage all relevant I/O protocols at the requested voltage level and sampling rate and even perform fault insertion.
These I/O interfaces can seamlessly be integrated into the Workflows from MATLAB and Simulink.
Besides those powerful all-round tools, specific commercial-off-the-shelf software functionalities are available, as for example the Aerospace Toolbox and the Aerospace Blockset.
Further commercial-off-the-shelf software functionalities such as the UAV or the Radar toolbox are available. Leveraging this versatile variety of functionalities ensures to provide all the tools required for your specific project and needs.
So, let’s now move to the second part of the webinar, where we discuss the frequent application use cases for HIL testing.
What are the typical applications that you may see around your aircraft?
You may see flight dynamics modeling and flight controls testing for large commercial aircrafts or even for unmanned aerial vehicles.
You may want to test engine propulsions systems and perform simulations, for example on a full authority digital engine control unit, a FADEC.
Also, energy and power management systems and battery management systems are supported.
Finally, you might find yourself wanting to check out power electronics and electric motor controls to perform certification tests.
In some cases, either in the aircraft or on the ground, you might want to test a radar application.
Additional testing workflows across all use cases are rapid control prototyping or certification.
Let's go through these applications one by one and see, how they can be modelled and tested.
All of these applications mentioned before face similar challenges.
Many Scenarios need to be tested and documented.
Most tests first need to be performed in a virtual development stage due to safety considerations or hardware costs.
Also, the test setup must allow gradual integration and testing of line replacement units.
The benefit of HIL testing using Speedgoat is clearly the test and documentation automation for virtual, hybrid virtual-physical and physical prototyping environments such as an iron bird.
The modular adaptation of HIL systems including I/O interfaces allow you to get your solution tailored to your needs.
The last great benefit I would like to mention is the seamless workflow integration to run plant simulations designed with Simulink.
Let’s look at the first Use case, Flight Dynamics Control Design and Testing
The big challenge is the need for an environment, which allows you to test the behavior of your vehicle, especially during failure cases.
You can overcome this challenge by using the environment emulation using the Aerospace Blocksets within Simulink.
We have a great example of an aileron actuator controller for you.
This Demonstration will be showed by Sam Mirsky, who is an aerospace application engineer at MathWorks. Welcome Sam.
Can you tell us more about this project?
Yes, absolutely. So Hi. Hello everyone, I'd like to share with you some work that I've been doing on a project here for a hardware loop test of a controller for a flight control surface on an aircraft such as an aileron. So it's a hydromechanical system. The mechanics are modeled inside of here and the hydraulics inside here and the controllers inside this block. Let's first just go ahead and run this simulation and see the results, and then we can look at the model a little bit closer.
So if I open up this code block, I'll get a picture now of both the commanded angle and the feedback. So the blue line or the line here that goes between these various angular positions is the commanded angle from this block here and then the yellow is the simulated feedback from our hydromechanical system and it's being Inside of here we're using Simscape multibody to model the mechanical aspects of the system.
It's basically a pushrod type system. As a matter of fact we imported this model from CAD so we get some automatic visualization for simulation. You can see it moving between these various angular positions by that push rod and this these visualizations are kind of come for free because we imported our Simscape multibody model from CAD computer, aided design which is where mechanical design typically originates so we can import that right into Simulink for the mechanical aspects.
Of our system inside of here, we're modeling the hydraulics using Simscape fluids for the hydraulic actuator and hydraulic valves and pumps and so forth and then inside of this subsystem is our controller and here we're using what's called a variant subsystem, so you might notice there's three different subsystems and none of them are connected.
This allows you to very easily switch between various versions of the subsystem. So you can see here, these two are grayed out and this is the active subsystem. So if I look inside of here it's just a simple PID controller block from the Simulink Library, which has some nice features like you can auto tune it and go through your controller design process.
But for this example we're going to say hey look, this looks really good. Our controls meet our requirements and so we're going to want to continue testing this.
So I've done a bunch of testing and simulation. Things look good. Now we want to test the deployed version of this controller on the actual embedded system. But hey, before we go check it, test it with a real system, perhaps it's not available yet, or perhaps that's very expensive way to do testing, so we want to, you know, make sure we've got a kind of all tested as much as we can before we get to that point.
Let's do a hardware in the loop test. So, if I bring up my video here, you can see here in the video I've got to Speedgoat machine. The Speedgoat machine is connected directly to this embedded board, which happens to be this CI2000, which has this connection board here that connects to the IO connectors of the Speedgoat. Typically to have this connected by cables, but to save space I just connected it directly. And that's connected to the Speedgoat I/O, and then the Speedgoat through this blue Ethernet cable is connected back to my laptop. So how do I test this with hardware loop? Well, the first thing I did before I started this demonstration today was I took that PID controller and I deployed it to the embedded that Texas Instruments embedded controller here.
So, we want to test that controller so the PID is in programmed here. It's been flashed on to the embedded system here and now, I want to simulate this system that is normally connected to with a real time simulation of that system of my hydromechanical system. So to do that I'm going to switch this variant and I'm going to switch it from my simulation version or variant to the hardware loop variant, and when I now when I get dig inside of here, I see that the hardware interface or the hardware input output block is now active, and if we look inside there we can see things like these Speedgoat blocks In this case we're using a protocol called SPI to communicate between the controller and the system. As well as digital inputs and outputs. So, these blocks represent the I/O drivers on the Speedgoat, so when I run this simulation, I'm going to run a simulation of the mechanics, the hydraulics, and interfacing to the embedded controller through these IO blocks.
So let me switch to the real time tab, which is available because this model is already been configured for Speedgoat and click the run on Target button. Now when I do that, you'll see several, well you want to actually see it, but several things are happening in the background, and so what's happening is, this model is being turned into C code by cement coder in MATLAB, coder that that C code is being compiled into an executable, compiled and linked along with the drivers for the IO, and then that's transferred over Ethernet to the Speedgoat computer, and then that is actually run on the Speedgoat system.
So, the simulation model in this case will be running in what's called external mode, which means that even a standard Simulink scope will see the data, but the data doesn't come from the model running here in my laptop, it's actually running here in Speedgoat, and then that data is being transferred back over Ethernet, so we can monitor that data with a standard Simulink scope for example.
So, this data streaming back live is the simulation is running here. The embedded controller communicating with what it thinks is the real system, but it's just a real time simulation of the system and it looks really good.
In fact, it looks the same to me, but you might notice in this model we got the feedback signal badge for logging little icon there indicates visualized signal or data logging. You click on a signal in Simulink and you can enable data logging to do that. So, that's the way to log data in Simulink. It also works with Simulink real time, no changes required.
So, if I go to the simulation data Inspector by clicking that button, we can see from our first run which was our desktop simulation. No hardware involved. The commanded versus the feedback. Now in the last one we just did where the controller embedded controller had the PID control and we were simulating the plant on the Speedgoat. We just add the feedback signal there it basically overlays right on top of it. We have to zoom in quite a bit to see any differences or we can use this compare to compare the signals. But this actually matches so well that I wanted to do a test to prove to myself and to you that this is actually running on the hardware.
So, what I'm going to do is I'm going to run this again. And I'm going to inject a manual fault. And by injecting a manual fault really, what I mean is if you notice here, there is a switch here, and so this is the power switch for the embedded board.
So, once it starts running, I'm going to actually turn them better controller off, emulating like a power failure, and we should see a divergent between the commanded angle and the simulated feedback from the Speedgoat, so they're connected. I'll flip it off now and will see that diverge, and then I'll turn it back on and it does its best to kind of catch back up.
So, if we look at that in the data inspector. We can look at all three runs and so this line here is the last one we just did where I flipped off the embedded controller somewhere around here and just kind of kept going at that at that same speed. Kept driving at the same speed and then till it reaches saturation and then it did its best to catch up. And so, like I said, I like to do this mainly just to kind of prove to myself in and tell you that I am actually running the controller here in the plant on Speedgoat but also this this is actually sometimes the test that you would do these kind of fault tests might not be manually flipping switches, but you could use like a fault insertion board from Speedgoat for example, to do open circuit or short to ground or whatever.
So that's the basic idea. When you run a hardware new test, you're taking the actual deployed version of your controller, and instead of testing it with a real machine before, do you know which may not be available may be very expensive to test with or have limited availability, or you know, maybe you want to test edge cases and you know, let's do lots of iterations in the lab before we start getting more real hardware involved, and so the hardware in loop allows you to test the embedded controller with a real time simulation of the of the machine or the environment that normally in normally be in. So this is connected the same physical electrical connections as it would be connected to the real machine, and so it's the closest thing to the real thing as you can get, so it's very valuable as far as risk reduction and testing earlier in the process.
Alright thanks. I'll hand it back to you.
Thanks Sam. That’s an impressive example. So, let’s look at another Application.
Aerospace Engineers working on engines and propulsion system face the challenge to test and verify engine control system such as a FADEC or to perform a development test of a power-train system.
Also, the continuous improvement of technologies including fuel cells and combusting technologies require an agile testing capability.
You can address this challenge by leveraging the seamless workflow integration with Simulink to design, test and run physical engine and powertrain simulations.
If you are working on new concepts such as Hydrogen Fuel Cells system or a Hydrogen combustion system, you may face the challenge you may face is having to perform simulation and testing in multiple domains, such as the physical domain as well as the modelled and simulated domain.
Real-Time Testing in Simscape will allow you to perform such tests in multidomain systems.
Let's have a look at the example. The FVA30 is a hybrid electric aircraft, which is under development from the Scientific Association in Aachen. The goal of this aircraft is to electrically fly the distance between Aachen and Berlin, which is over 500 km long.
In order to set up an iron bird, the association needed a testbench to test the powertrain for the hybrid aircraft. The solution was to use a Speedgoat target machine. They were able to rapidly set up their test bench and start testing. This Iron Bird setup is also an essential part of the compliance demonstration in order to fully certify the aircraft.
Let’s have a look on how they used the real-time target machine within their test bench.
The Baseline target machine acts as the controller and heart-peace for the iron bird. From the Pilot side, input commands such as throttle and elevator angle are read into the target machine. Inside the target machine, the actual motor control takes place. On the test bench, the target machine is controlling the motors through the inverters as well as the batteries.
We remain in this More Electric Aircraft domain. I would like to show you the Application of Energy and power management. This becomes more and more relevant as the electrification of aircraft is progressing.
So more electric aircraft means that not only the propulsion system can be electrified, but other components as control surface actuators we saw earlier can be electrified too. Those components depend on a battery and are fed of the onboard electric grid. Therefore, the Challenge is to design and test energy and power management systems such as onboard microgrids and battery management systems.
For new concepts, the electrification of the aircraft or the integration and testing of a new fuel cell is a challenge.
Also, the interfacing with power electronics components and inverters is a demanding task.
As mentioned earlier the seamless workflow integration with Simulink to build, test and run power systems and power electronics simulations enables you to test power management systems.
Using Speedgoat you can perform battery emulation for up to 320 cells and state of charge and state of health estimations.
The HIL setups allow you to do signal conditioning. For example, you can rise your voltage level to 28V, which is usually required in Civil Aviation. Also, the low latency interface to power amplifiers allow you to have a realistic representation of your on board microgrid.
A great example of an application that you could use for energy and power management on your aircraft is this reference application of the hybrid electric aircraft.
As you can see, the onboard electric grid is modelled. You have two generators and two electric Motors, so the aircraft is flying electrically and the power is generated on board, where the generators are feeding the batteries.
Obviously the electric motors need constant power.
This electric system is modeled in Simulink. The power is generated by two gas turbines.
The whole Brighton-Cycle gas turbine is modelled using Simscape in the physical domain. This allows you to simulate an accurate control of the gas turbine. The controller is also modelled here using this control block.
Which right now consists of a speed regulator a temperature regulator and the surge margin regulator. The tasks of this controller can also be executed on an actual embedded controller.
This controller can be an external hardware. The inputs such as N1, temperature etc. can be generated by the Speedgoat real time target system.
This would allow you to perform real time hardware in the loop testing of the whole gas turbine as well as for the whole aircraft.
So, for example, once the battery voltage is going too low, the gas turbine is going to kick in and the controller is going to control the gas turbine as well as the amount of power it has to generate. Since you may only have the controller available and not the whole aircraft or micro grid to test it, hardware in the loop allows you to develop and test the controller of this aircraft. Obviously also controllers for the electric motor, and the other buses can be simulated and tested using the hardware in the loop approach.
Speaking of Power Electronics and Electric Motor Controls, let’s have a look at the challenges here.
One of them is the design and testing of high-fidelity low latency power electronics control systems.
Another more specific one is the need for powerful HIL simulation hardware, allowing for sample steps below 1 microsecond and a pulse-width modulation resolution below 10 nano seconds.
By using the Speedgoat system with an FPGA, you can achieve time steps below this 1 microsecond and a PWM resolution below 10 nano seconds even for applications with many I/O channels.
The control of electric Motors and generators are typical application for power electronics.
For example, the generator requires power converters to provide aircraft compliant voltage and power.
Or electric vehicles require power converters to adjust the DC power from battery packs into three phase power for the powertrain. Those applications can be simulated using Simulink and then also tested before being applied in the actual hardware.
Our last application is the typical radar simulator. Weather in in the air or on the ground you want to perform situational space analysis and analytics for radars. You need a high sampling rate in order to build your disturbance modeling and to simulate it.
Using the dedicated radar toolbox from MathWorks, and the Speedgoat High Fidelity FPGA, you can perform those demanding tasks.
Sample rates up to one giga samples per second allow you to fully test your radar and perform data analysis on your environment.
This is a snippet from the interface of the powerful Radar Toolbox, which you can use in combination with your FPGA to simulate and test your radar application. Many more of those examples can be found on the MathWorks or the Speedgoat homepage.
As you saw earlier. Hardware in the loop is usually preceded by rapid control prototyping.
Your workflow may deviate slightly, but I am pretty sure that you agree on the following three main motivation for real time based controller prototyping.
By testing early, you can prove that your algorithms work in real-world dynamics, you might find better tradeoffs and tweak performances.
The Unified Workflow provides a path from desktop simulation to automated testing with flexible and powerful hardware. This unique combination allows you to worry less while testing.
Ultimately, you can be more innovative, expose design flaws earlier and shorten time to market.
A very interesting application of this controls prototyping is bypassing. If you want to work on one specific function for a new software build on your flight controller, which is already certified, this may come in handy.
Let's say you have your flight controller here, with your flight control software, which is represented by this blocks which runs in a continuous loop. Your goal now is to certify just one function or test and tune one function.
Using your rapid control prototyping system, which is obviously a Speedgoat target machine,
you can input the variables from the flight controllers or from the flight control software into your Speedgoat target machine, perform one specific operation and then output the variable again. This allows you to tune only specific details of the algorithm.
This approach is used to certify flight controllers across the fleet of a major airliner manufacturer.
Talking of certification, this is a big topic for the aerospace industry.
In order to learn more about HIL in the certification process, we have Doctor Juan Valverde with us now.
Juan used to work for the research center for United Technologies, now part of Collins Aerospace focus on Model-based Certification activities for Hardware and Software.
Now, Juan is an aerospace and defense industry manager at MathWorks in Germany. So, Welcome Juan. How can we use hardware in the loop for certification?
Hello everyone, yes this is a great question indeed, so I will try to answer it in the following slides.
As a brief summary, hardware in the loop will allow us performing very advanced testing procedures without the need of having the complete real system under test. This is effectively having our flight control algorithms, for instance believe they are actually flying while we see every possible behavior by exciting the system in ways very difficult to achieve in real circumstances.
As you will know most aerospace systems need to go through certification. This includes systems for commercial aviation and space and in some cases even defense projects. If we mentioned, for instance, the most used standards for commercial aviation, we can see they cover the whole design cycle from the systems level definition within the ARP4754A, including all the safety concerns within the ARP4761 and all the way down to hardware and software specific standards.
To illustrate with an example, imagine that we are designing some actuator control for the secondary flight control surfaces. I would start at system level, specifying functions derived from my functional requirements and allocating them to physical components.
Then, assuming some parts of my control laws will be implemented in hardware, for example on an FPGA and some others in software, for example a DSP processor, I will have to follow the guidelines provided by the DO 254 and the DO 178C standards. These guidelines will include all the design stages from requirements capture to implementation and transition.
But certification requires a process and it is an expensive and time-consuming process. However, with the right processes in place and automating key parts of the workflows, timing costs can be dramatically reduced.
At MathWorks and Speedgoat, we propose a model based design approach mapped to the typical V model for design and verification. This process matches perfectly the design stages specified by the certification standards. Starting with the design part of the V. Defining requirements and system architecture, adding then models of the behavior of the algorithms and plant. To build component models. That can be used to automatically generate code for the different targets, and following different design products. And then going to the verification part of the V where all the verification and activities are performed with their special emphasis in testing.
Now this verification in the second part of the V model could also be seen as a smaller piece happening at the different design stages. This is possible thanks to all the X in the loop testing possibilities.
Remember, verification is a fundamental part of the design for certification process, and most of these verification is done through testing.
Testing is done at different levels and following different configurations always linked to requirements to satisfy certification needs. It is very important to enable full traceability between requirements and tests, then being able to reduce tests through different stages and configuration saves a lot of time.
For this it will be possible to start testing the algorithm under design in simulation using a model in the loop approach where both the plant and the algorithm are part of the model.
Then it is possible to move to a software in the loop setup where the controller code is simulated together with the model of the plant and continue with the processor in the loop approach where the code from the algorithm is generated and implemented in the target embedded device and then connect it to a model of the plan still in simulation.
We can see how these model based design approach maps to one of the certification standards in this case the DO-254. If we take for instance, the example of a design that targets an FPGA implementation, the DO-254 standard will specify the following stages. Remember the ARP4754?
We will capture the system concerns and then the DO-254 will go from the requirements to implementation and transition. Now, I would like to show how these workflows can be covered with our tools and where a hardware in the loop testing will be crucial.
The process will start with the requirements capture. These requirements can then be specified using similar requirements. This requirements can also be linked to other requirement management tools. Then the conceptual design will be mapped to a simulated model. Of course Simulink can be mixed with other toolboxes, stateflow, etc and it will be especially interesting in this case to play with the automatic conversion to fixed point. Then the detailed design will be. In our case, the HDL code. VHDL and Verilog code can be automatically generated using ACL folder. Then the implementation part, meaning all the way to the bitstream and netlist will be done by third party tools. Very often FPGA vendors.
Now, for the second part of the V-cycle, as introduced, this will take place across all the different design stages. Starting with Simulink Check to see model compliance with the standards, continuing with Simulink test that we will be able to capture test cases linked to our requirements that the test cases can be exercised at model level, code level etc. We will see how important this is for the hardware in the loop part. And then the Simulink coverage to analyze how much our requirements are covered by this test.
Simulink Design verifier as well will not only help finding automatically some test cases for missing coverage but also performing formal property proving at model level to increase verification capabilities. HDL verifier will allow reducing these test cases at different levels including cost simulation with third party tools and through the generation of test benches following different industry formats.
Then, as certification is documented verification, Simulink Report generator will generate automatically reports that will be used as artifacts for our certification process. It is at this stage, where hardware in the loop will be crucial to increment testing capabilities including code in the real time models of the plant.
Having this certification aspect in mind, the question is how aerospace companies can use more hardware in the loop and automated testing workflows?
That's a very good question. Thank you, Juan, for diving with us in this topic of certifications
So, yes. How can companies adopt model based design and HIL testing?
It is important to know that implementing this new approach may not be straightforward at first.
Creating models will take some time and also requires new skills.
So, there is an initial investment for every company planning to implement that. Many aerospace companies work under a lot of time pressure to achieve certification and sometimes don't take the time for the implementation of better workflows. They are often punished later on.
So, it's a good idea to start this early. This example from Airbus showed, how they overcame the initial fear of the new approach by pointing out the benefits.
Alonso Pardo presented this graph at a MATLAB symposium. I find it quite interesting because it shows how you can increase the flexibility and increase re-usability using model based design. Finally, the engineers can detect design failures earlier and also simply be engineers again so they can spend time understanding the systems and don't have to spend time building up the models and worrying about interfaces or documentation.
To conclude, I hope that you learned, how Speedgoat real-time testing systems enable you to test your aerospace control designs and control systems.
Furthermore, you experienced how Speedgoat systems provide you a most seamless workflow for both, desktop and real-time simulation and testing from Simulink.
And finally, you saw how hardware-in-the-loop simulation and bypassing enables you to reliably and efficiently meet testing requirements for certification.
Thank you very much for your attention. I will now hand back to our host, and we will be ready to answer your questions.