Requirements to Reality: Systems Engineering for Electromagnetic Spectrum Operations

Good afternoon, and welcome to this session titled Requirements to Reality Systems Engineering for Electromagnetic Spectrum Operations. In this session, we will show you how you can link your electromagnetic spectrum operations system requirements to system-level architecture and also to the simulation of the models.

We will use a radar warning receiver as an example in which we will demonstrate the workflow you can use to improve communications across the different engineering disciplines within your team. We will also discuss ways that this type of workflow can improve, thanks to the model-based design way of working with the goal of eliminating rework and strengthening the engineering reviews you conduct with your end customers and subcontractors.

In our example, we will show a specific case where we close the loop all the way through requirements verification. And once the system is verified, we will show also how changing requirements can be managed in the same process framework. We will demonstrate how changes in the requirements ripple back through the architecture in system-level design.

The same example conveys similar tasks when the model of the system is improved, changed, or developed with another tool. Currently in the industry, there is a global trend which is digitalization and model-based design. Being concise, digitalization means less paper produced during the project and exploit more digital resources.

While model-based design specifies that it's much more efficient to duplicate your design system in a digital control environment and simulate it as much as possible. Gaining insights and knowledge from it as you can obtain during this process, you can learn a lot about your system performance, how can it be changed and improved, and moreover, if it fulfills yours or your customer's needs.

In this way, let's assume that we are manufacturers of a radar warning receiver intended to be mounted in a flight platform which is located in an environment where a ground-based radar surveillance is also working. The characteristics of this radar are waveform transmitted is an LFM pulse signal with a pulse width of 3 microseconds. And the period between the pulses is just 15 microseconds.

The sweeping bandwidth is 30 milliseconds, so resolution of 5 meters and a current frequency of 1.8. gigahertz L-band. As the same time for the radar warning receiver, it is flying at a speed of 200 meters per second in the x-axis direction. And its initial position is 3,000 meters in the x dimension, 1,000 meters in altitude and in the Z direction, and 0 meters in the y-axis from the radar, which we assume that is located at the origin-- so 000.

The architecture of the overall example we want to develop can be divided in these three parts-- the RF emitters, the environment, and the radar warning receiver itself. Let's have a look in detail at the environment. As mentioned before, the radar warning receiver is located in the flight platform at an altitude of 1,000 meters located 3,000-- sorry-- 3,000 meters away in the x direction, 1,000 meters in altitude, and 0 in the y direction.

Therefore, the relative azimuth elevation angles in the initial position between the radar and the receiver are minus 18.5 and minus 17.5 respectively for azimuth and elevation. And the distance is approximately 3,317 meters. In the other hand, for the radar warning receiver, it just conform or it's just made up on a receiver array formed by a uniform rectangular array of 10 by 10 isotropic antennas separated by half of lambda.

The RF front edge in our design just specifies that the noise level of this receiver is 2.5 microwatts. The motion of the radar warning receiver, which moves only in the x direction, has a velocity of 200 meters per second. And again, the initial position is a formation of 3,000 meters in the elevation, 1,000 meters in the x dimension, and 1,000 meters in the y. dimension.

The signal processor, which is in charge of two functions-- first, detect if there is any signal in the spectrum recorded by the system. And it's just done it by making some buzz. And then the system detects if there are signals and also in which sub-band.

And at the same time, the signal processor calculates or estimates the direction of arrival, meaning that estimates where the radar is located or in which direction the radar is located. It has to be also explained that the system estimates the radar distance to the radar warning receiver, thanks to assuming that the radar is located at the ground and assuming that the altitude of the radar receiver platform is known.

Therefore, it's important to mention that the radar warning receiver radar distance is measured by intercepting signal characteristics but only from direction of arrival estimated with a music algorithm and then by own platform altitude, which can just be calculated because the same platform has an altimeter radar or another kind of system like, for example, GPS.

The data processor in of hand first steers the receiving antenna towards the music door result obtained by the signal processor. In this way, we express or we obtain a gain, which increases the SNR. And therefore, it will ease extracting the signal characteristics by also applying a pseudo Wigner-Ville transform together with a Hough transform.

This technique is very well adapted to linear frequency modulations. The reason is that the result of the Wigner-Ville transform is a 2D image with type 1 axis, frequency in the other, and power for the vertical axis or the color, meaning that LF modulations can be seen as lines when plotting the results. And this is what you can just see here in this slide.

In the upper-right corner, we see the result of the Wigner-Ville transform of some echoes received by the simulation of the system. And there, how with the naked eye, you can see the lines formed by the LF pulses. Problem is that is too low to extract automatically the parameters of the cylon.

And therefore to increase it, we have to apply a threshold to the image. Convert it to a binary image, which is the bottom middle image, and apply the Hough transform, which is bottom right, to obtain, finally, the signal parameters by applying simply a peak detector to the matrix. The position of the peaks and its relative location just give the signal parameters.

And you can see also in the upper left what are the estimation results of one simulation of the system. We have just obtained that the pulse repetition interval is 50 microseconds, which is absolutely correct. The pulse duration is 2.87-- well, we have established 3 microseconds-- the pulse bandwidth 28.31 megahertz where it is 30, and the central frequency of 1.85ghz. gigahertz, while the transmitted signal, the current frequency in reality was 1.8.

But now that we have seen the architecture of the sample and how it works, let's just go a little bit where we are here. Now let's have a part about the second part of the model, which is called the RF emitters, what a name. It is important to emphasize that the radar warning receiver commonly is passive. It's not emitting any kind of electromagnetic signal that could interfere or hamper the detection of the radar warning receiver.

Therefore, the RF emitters mean all the active systems which could be working in our environment. In our example is the pulse RFM radar, which location is fixed at 000 and that we are trying just to detect.

It is convenient to emphasize that similar to the radar warning receiver, the radar that we are modeling has just also a transmitter, which by definition is a simple game block of 5 dBs and the transmitting array, which is supposed to be a uniform rectangular array of 8 by 8 isotropic elements separated by half lambda between them.

Till this moment, all that we have seen is the model of our radar warning receiver system together with the environment and our radar system trying to detect the flying platform. Everything is inside of our tool called Simulink, which I like to tell-- or I would like just to explain to all my customers that is the glue that allows all the others to be simulated and to be together, sharing info and making simulations of the end-to-end system.

It is in this environment in Simulink that you can simulate your system before moving to hardware, optimizing the design of resources even before having to buy a simple cable. My advice is to explore and implement a lot in this environment-- even try designs that you wouldn't otherwise consider, all without having to buy anything to write any single line of C or C++ code or HDL code and just gain all the insights that you can from your system.

On top of the Simulink environment, what we have used to model the architecture is the System Composer tool. You can describe how is your system built up by components and their interconnections through ports, interfaces, and connectors. Moreover, you can also avail advanced functionalities like advanced views or filter components by defining stereotypes.

We have seen now the architecture and the design. But commonly, what is the first step of any project is the requirements. What happens with the requirements? Here, we do have the requirements in our structure. Requirements typically come from tools like Word, Excel, or more specialized requirements management environments like DOORS or Palladium, for example.

Implementing these requirements in the model-based design could be tiring using different environments for each part of the project. To work with the requirements directly in Simulink, there is an import operation from Word, Excel, DOORS, and also for the standard ReqIF which is the Requirements Interchange Format which are the XML files. And this one is supported by most of the requirements management tools.

If the requirements change at source, an update operation synchronizes the changes. Usually, the default is to treat the external requirements as read-only. But we can also modify the requirements or add more details, for example, custom attributes, and then re-export. In addition to requirements imported from outside, you can also create requirements in Simulink.

And finally, as I said before, export the requirements via ReqIF standard. Let's have a look at the video demonstration about how this is done. So here, the first thing is that we will just open the System Composer up. When we open the System Composer, first is just to make or just to deploy the windows in the way that we want and we feel comfortable.

It's absolutely selective and it's personal. What are the windows that you would like to see and how? You could just put the way that you like. Once you have just the display just developed, then just create or start creating the blocks. To create the blocks, put the names and therefore, just fooling or creating all the ones that you would like for our system.

In this case here, we are seeing a video of a possible radar system that could be the one that is used in our environment. There are different parts right now created like Power, Radar, Targets and Environment, and also Comms Link and also Command Center. Each of them, it has its own functionality. And for example, they will have its own properties, its own connectors, inputs, and outputs.

Here also, we are just creating areas in which we could engulf parts. And then, what we are going to do is just to adjust or to link the requirements to specific blocks of this System Composer creation. We have just selected the Word document in which the requirements are specified. Here, we are just right now linking also to that one.

And therefore, we have here the list of the requirements. We will just go, for example, one by one. Or in our case specifically, we will select some of them to be just joined directly to specific blocks. For example, for the power we have the 3.2 requirement.

Then we link directly to the block of power. Then we have there the possibility to show it, to watch what is the requirement, and also we will see later even just to link two tests. In this way, what we can just do is link all the rest of the requirements.

It could be environmental that will be linked to target an environment. It could be also functional, like the radar system in which we just specify what are the maximum unambiguous range. Well, that can be linked to a specific part inside the radar. Or it could be also linked to other blocks like targets or environment.

The most important thing is here we are just linking directly the requirements to the specific blocks or to the specific design. Because as we will see later inside of these blocks, we will have the models that each person of the team will just populate inside. What I mean is just inside the radar block, we will have a transmit array. We will have a receiver chain. And those will be populated by the person or teams in charge of each part.

Moreover, what we have just done the requirements, we have the possibility to check what is the implementation status. What does it mean? Does it mean that we can just check from a visual point of view, as we see in the image in the slide for each of them, if they are implemented, justified, or missing-- meaning that missing means that they are not linked to any of the parts of the System Composer model, justified if they are linked and also simulated, and implemented if they are linked but not being simulated.

Then the second thing that can be very useful is to check another capability of our tools. That is the Traceability Matrix. In the Traceability Matrix we see here on the slide, we can just check what is the link between the artifacts and the requirements. So we do have in each of the axes of the matrix either the blocks or the requirements, and we will have in the crossing if they are linked or not.

Therefore, what we can just do is, for example, highlighting missing links, taking into account that, for example, there are a missing link between requirements and functional models. Directly with this, we can just add links and to address gaps very easily, uninformed to the person that should have just to manage or fulfill those gaps.

At the same time, take into account that these matrices can be enormously big-- can be form of hundreds of requirements or even thousands. At the same time, it can be as big as also hundreds of thousands of models. Therefore, this view-- this matrix can also be filtered to manage large sets of these kind of elements, which you have just to manage many of them.

But now, please-- we have seen before the requirements that we had the functionality, architecture, and the design. But let me right now come back, and I would like just to go a slightly more in detail about how to highlight that there are different and several tools that can be used in our example to do the design process.

Again, I would like just to emphasize that the design phase means that they will populate each of the blocks of the System Composer model. And therefore, that is what we can just do during this design phase with the modeling and simulation-- as you see here, one example of a radar that can be included in the Simulink environment and can populate several of these blocks.

For example, in the upper part, we do have the transmitter. We do have, for example, the environment propagation in the middle. And we do have the receiver in the upper low part of the radar warning receiver. That is one of the steps. Or that is the result.

But again, for doing that, we do have many tools that we are going just to explain right now-- some of them how they can just be interconnect and how just they can be used in order to obtain and just to populate those models in a very simple, straightforward workflow. In that case, what we are going to do right now is just to see a video how to be able to produce those specific models.

So in our case, for example, we will just start using the RF Budget Analyzer. This tool is just one tool intended for simulating cascade of RF chains. The first part of the simulation is we will go to the System Parameters section in the upper left in which you have just to define what is the Input Frequency, what is the Available Input Power, and then also what is the Signal Bandwidth.

Because we are going just to try to replicate the transmitter of the radar, then the input frequency will be 1.8. gigahertz. The available input power, let's assume that we will have the modulated signal with a power of 0 dBms. And the signal bandwidth that we have specified is 30 megahertz.

Then, we can just populate the system by different blocks. The different blocks that we can just insert here, you see are nonlinear elements like amplifiers, mixers, and linear elements like filters, signal transmitters, or antennas. Well, what we are going to do-- or even for the linear elements, that's true as parameter blocks.

But in our case, we are going just to start by a simple filter after the signal generation. Well, what we are going to do better just to also include the mixer in our design, we just put that the input frequency we generate the signal in passband. So instead of 1.8 gigahertz, it's 0, the starting initial modulation.

And then the filter on the left, each of the blocks, one is selected. You have at the left part what are the parameters of the elements. For the filter, we have that the filter type is a Butterworth. It's low pass. It's an LC Tee implementation structure with order 3. Let's assume that the passband frequency is 100 megahertz.

We will just make it an iteration by passband of 3 dBs. And then we have already designed the filter, and it's there already included. The second element is going to be an amplifier. Let's assume that the variable power gain that we do have is 7.5 dBs, and then that's done for the amplifier.

The third element of our cascade after the amplifier is just to go up in frequency. It's just the modulator up. We just assume that it has losses, is not active. Therefore, we will put minus 6 dBs or 6 dBs or losses. But more important, the LO frequency because we start at 0 and we would like to transmit at 1.8. gigahert, therefore, the local mixer, it will be at 1.8. gigas.

The converter type is up, and then the input and output impedances are 50 ohms. After a mixer, generally speaking, we have just to first put a filter. Why? Try just to filter out all the possible spurious signals that the system could just generate. Therefore, first is that right now our filter is a bandpass filter because we are already at 1.8 gighertz.

And therefore, we specify the passband frequencies at 1 and 3 with an attenuation of 3 dBs. So it's not very selective, but at least it's just the first filter after the mixer We can just put a second amplifier with partial gain or medium gain of 50 dBs. Then after that, another filter arrived that we can just go very selective.

We can just go very selective in frequency. And then, what I commonly do is just to do a bandpass of a higher order and therefore, try just to be more selective. Although here, I have just selected the same passband frequencies, but commonly here, we can just be much narrower.

And then finally, the final power amplifier in which it would be one amplifier that has a very high output power capabilities with a reduced available power gain, but can only write out 7.5 dBs. With that, we have already all our transmitter chain for the radar. And we can just assume that, for example, we have the results there.

The total gain or the total output power right now is at 24. We have 24 dBm of transmitted power calculated by Friis. And therefore, the output frequency is 1.8. That would be our capabilities of our transmitter that we could just specify also for our environment and our system. It's also important to mention is that we can just calculate not only by Friis equations but also by harmonic balance, the results.

And finally, the most important part is that the Export tab-- in the Export tab, we can just select one of the options that is RF Blockset. The RF Blockset when we select that, the system automatically opens Simulink and it will create for us directly from this model, from this cascade design, the Simulink equivalent model of this transmitter given to you directly. That is very, very important because it gives you a lot of things already done.

Here, you can just see that is the block for you. You have all the blocks there with all the info that comes from the arithmetic app but also the configuration of the simulations, the input ports, and the output ports, which is also very important already just to have already configured for you directly. Because if not, it has complexity and difficulty for simulating the models.

But in this bubble, there is something missing. It's the antenna. We can just open an antenna block by selecting or just requesting antenna from the compass. And the only thing that we should have to do to include the antenna is just to put the output of the power amplifier towards the input RF in our antenna block. That is, that would be enough to include the antenna in our simulation environment.

But the antenna, what kind of antenna? Right now by default, it's an isotropic radiator. There are possibilities to make much more complicated antennas not only here, also specifying the gain. Also what is the frequency radiated? Now, there are tools to make the design of antennas much more elaborated

And we're going to see right now is we are going to design one from the Antenna Designer. And directly from the source of the antenna model, we select Antenna Designer. And we press in Create Antenna Model. This will just generate or it will create or open an app in which you will see that is exactly similar to the arithmetic app with very similar appearance in which we can start designing our antenna.

We press on the New button at the upper left corner. And there at the New, when we press, we have the possibility first to select if we have Backing Structure of the antenna, Low Backing or Rectangular. And also at the same time by default, it selected the Dipole. But there are many different antennas possible to select.

It can be a Spiral, RF Resonators. It can be Patches, many, many different ones-- around 180 different possible designs that you can just choose from. Again, just because of simplicity and right now just to show capabilities is enough, we will just select the Dipole, which is a very simple antenna. The desired frequency, as we have just designed, is 1.8. gigas.

And therefore, when we accept those designs, the system directly already gives you the dimensions of the dipole antenna working for that frequency. And also the frequency bandwidth-- although it's fixed right now, it can be changed by the user. But the most important is that directly we can just calculate the 3D pattern of that antenna. Here you see the results.

And also what we can calculate is the S-parameters. In this case of the antenna, it's only one port. It will be the S11. And here for obtaining this, please, it's important to mention that we have just executed a full wave electromagnetic analysis. We obtain the S-parameters, and is just adapted-- or the minimum of these parameters is at the 1.8, gigahertz, exactly the frequency that we would like.

Moreover, all the results that we can just obtain directly from the options is to plot the current distribution of the antenna and also-- although here I've not shown-- azimuth and elevation pattern because we have already seen the 3D characteristics. Once we have seen all of this, then the next is we can just go to Update Block. When we press the Update Block option there, then we can just see that update. block, Untitled Antenna.

That means that this design can be exported directly to the Simulink block of the antenna that we were before. When we accept that, we can just go back to our design. We can just click on the block. And therefore, we can see there our antenna already, our dipole antenna.

The only thing that we should have just to do is to change the radiated carrier frequency to 1.8 gigas and then also selected what is the direction of departure if it's needed to change. And then we have already included one antenna design in our system. Then the problem about that is that we will like just not only to be able to simulate our data but to be able to simulate an array of data.

And how we can just do that? Well, in that case, it's slightly more complicated because it's not so straightforward directly from the antenna block. And to be able to simulate an array, what we have to do is we have to go to MATLAB and opening the apps section is Antenna Array Designer. When we open that up, we will see that the app is absolutely similar to the one from the antenna.

And therefore, what we have to do first is just to select New design. When we just select New Design, we will check-- we will see that we have also first, if we will like making structure or not, what kind of antenna, but also in the upper left, if our array is linear, rectangular, or there are many other possibilities. In our case, we just said that the radar has just an array of data of 8 by 8.

But because of simplicity, let's assume right now and also for timing of simulation that we assume a 4 by. 4 Then we implement a 4 by 4 one. And now, we could just see the array in the-- so the array geometry, of course, by default by dipoles, because that's the one that we said that we would like just to use. And the desired frequency is 1,800 megahertz.

And then we accept the design. Once we accept the design, again, we have the antenna, the array, the layout 3D in our screen. And then what we would like is just to, again, simulate what is the radiation pattern. The radiation pattern of the antenna in 3D, we can just obtain again by clicking the 3D button. And here, we do have the result.

At the same time, it would be feasible to obtain the S-parameters, but it's just slightly lengthy. And therefore, we would like just not to use too much time. Finally, what we would like is in order just to include this design in our Simulink environment is export this design as a variable in the workspace. We save it as a rectangular array variable.

And then what we have to do to include it in our design is go back to the antenna model and instead of selecting Antenna Designer as the source, we have the Antenna Object. And now at the antenna object, we have to know what is the name of the variable. Remember, it's a rectangular array. So we're just placing the first one numbers here.

We do have the variable in our workspace. Then we apply. We accept. And then we can just press OK. Then when we press Apply and OK, we will see that immediately the antenna block has changed to an array, an array that has as many inputs as the number of elements.

And therefore, the only thing that we have to do to be able to completely design our viable system would have to be to copy and paste as many times as needed, the transmitter unconnected to each of the inputs of the antenna. And therefore, we will have already the simulation of our transmitter from the radar. That is exactly what I wanted just to show you, for example, from these tools.

Because right now, what I would like just to emphasize is that this model is that you can use to populate directly the blocks from the System Composer that I was showing before for the overall system. In the same way, not only the radar but it can be also the radar warning receiver. And then in that sense, you can just by simulation of the System Composer, in the end, you will also simulate these kind of systems.

So following to the next slide, how complex can be these systems? So the complex that can be these systems can be as this one, for example, another design in which you have not only filters, amplifiers, you have phase shifters. You have also switches. You have also capability about deciding where to change the switches.

Also you have power dividers. You have matching networks in order to be able to match the power amplifiers towards the antennas. So therefore, what I would like just to tell you is that those models can be extremely complex, even you can take into account the polarization of the antenna.

Also, you can just manage to transmit and to receive multiple signals at the same time, for example, for simulating jammers or for simulating interferences. In the end, what I would like just to point out is that the more complicated that you make the system, of course, the simulation of the System Composer will take longer. That is something that it has just to manage and to be taken into account.

Well, once that we have already checked in detail what is the design, our next step is just the implementation. Implementation, that means when you like just to deploy some algorithms in a physical hardware. For deployment, we have got a unique code generation framework that allows models developed in MATLAB to be deployed anywhere without having to rewrite the original model.

This gives you the ability to test and deploy the entire system, not just the model itself. MATLAB can generate native optimized code for multiple frameworks. It gives you the flexibility to deploy to lightweight lower power embedded devices such as those using a car, low cost, rapid prototyping boards such as Raspberry Pi, Edge-based IoT applications such as sensor and controller, or the machine in a factory.

It's important to mention that if you like just to about speak about FPGA, please come to ask about what is your interest because we can just help you also with that one. In our example specifically, it would be feasible to deploy the Wigner-Ville and the Hough transforms information to a specific hardware, for example, using also the HDL Coder.

And although it's not a topic of today's webinar, we encourage our attendees that if they are interested in the specific workflow, contact back us or please check the multiple examples that are published in our page, which generate HDL code for radar special silo processing, beamforming, and also, for example, direction of arrival. Then if it's for interest or you need more info, then contact back us.

Then the next point I would like also to touch to explain is testing. What happens if we would like just to check what our system is capable of? We have right now, all our functional model. We have just populate all our blocks with our models. And then in the System Composer, the user can simulate the complete thing.

And we have seen also that we can link the requirements and check if they are fulfilled or not. But the testing means to do that automatically. In that sense, we do have the possibility to use similar tests, which provides three main capabilities for testing models-- a Test Manager for organizing, executing and reporting tests and test results-- sorry-- Test Harnesses for isolating a component under test and to separate your test artifacts from your design artifacts, multiple Test Authoring options-- oops sorry again.

And in the functional testing process, test cases are authorized by reviewing the requirements documents. You can use Test Sequence and Test Assessment blocks to create complex test scenarios as well as pass/fail conditions. And for more flexibility in creating tests, you can capture test input in an Excel template and define baseline results using Excel.

In this way with our tools, requirements that change over project are easier to manage because they are linked together. And when you, for example, change the document, the Word document automatically will appear in the requirements and also in the System Composer. At the same time, not only will the requirements have changed, but also if the test fails.

For example, we have here a video in which we will see how if the requirements change, how to handle that. First, we go to the Word document of the requirements and change. what are some of the requirements for the radar. So maximum ambiguous range, it can change to 8 kilometers. And then the target fluctuation targets that before were no fluctuation, now it changes to Swerling Case 2 targets.

Then in this case, when we save that, it goes directly to the Simulink requirements. And then we just press Update. Then we import the new Word document. And the system just realized that there are changes. Those changes will be highlighted in order just to be able that the user can very easily be aware of that.

When we open all the requirements, we will see that there are two highlighted there, which have just changed. And then there, we can also check by the links what is exactly what has just changed-- not only the properties but also the change information-- and check that right now, the requirement has changed and also why. There you have, which is the actual case of changing of the requirements.

Therefore, from this point of view, it is also pointed out which are the blocks affected by this change-- but not only the blocks, but also the test cases. If the test cases are just linked correctly to the blocks therefore, also the ones that the test cases that need to be redone or re-executed are also highlighted.

That means that here, we do have finished-- but only the last, but not the last point, which is operations and sustainment. It is not the topic of today, but I would like also to tell to our attendees that we do have tools for being able to optimize the working period and also the life of the system. How is that possible? Mainly by developing digital twins, which can be used for analysis of failures and counteract them before they even happen.

Use those tools to create a lot of development on these features. Especially is remarkable the nice tools developed for digital twins are predictive maintenance. If you're interested, please contact us. We will be delighted to share more info about we can just do for you in those fields. Now just to finalize our presentation as a summary, what is that we have seen here today?

We have started with a set of requirements for developing a radar warning system in a certain environment with also a radar. We have gathered those requirements in a document, a link with a certain architecture developed by the System Composer. Each block of that architecture has been populated with the specific design done by a specialist of the team using different tools but converging all in the similar environment and developing models and specific files.

That altogether can be simulated and check the performance. Therefore, the modeling can be done even before purchasing anything and without the need of a lab. And the simulations can be done by big numbers to analyze different design possibilities, even those who could be out of the scope at the initial stages of the project.

And finally, also testing-- we can just do those simulations and the test in an automatic mode where the performance can be checked and immediately knowing, as we have just seen, which part of the system or the design should be modified or improved in case of nonfulfillment.

But the most important is that also we include the way forward, which means if we just encounter any problem in any of the stages, we can just go backwards and change what is needed in the design or in the architecture or check if there is also a change in the requirements. Because all of this can be done-- but because of having a digital thread.

All our tools with our environment just produces or generates a digital thread that generates a bond between all the parts of our project. Use it as a glue, a barometer, as I have mentioned, the Simulink. But in the end, also using many other tools for designing the other parts or the antennas or, for example, if it would be more things like specific algorithms or even to deploy.

What I would like also to mention that our attendees should have just to take with themselves after this presentation is that we do have a very flexible workflow to collaborate with many other tools. So if you are interested in the general case, but collaboration with other tools and to fulfillments of the overall workflow, please come back to us.

Because also we are prepared to collaborate with third party tools. For example, specifically it could be with Python. That is all from my side. Thank you very much for staying till the end of the presentation. And I really hope that you have just enjoyed as much as I have done presenting this content to you. Thank you very much. And now, it is time for questions and answers.