radar architecture: test automation and requirements traceability (part 2) -凯发k8网页登录

automated testing

prior to setting up the tests, load the model constructed in the part 1 of the example.

open_system('slexradararchitectureexample')

simulink test manager is a tool for creating tests suites for the model. to access test manager click on simulink test in the apps tab, then navigate to tests tab and click simulink test manager. to get started with the tests, create a new test file for the model by clicking on new test file. then add two separate test suites, one for each requirement. further configure the test suites by:

next configure the tests within the test suites. the changes are made only in the system under test, parameter overrides, iterations, and custom criteria sections.

for the maximum range test, specify a single target with 1 m2 radar cross section (rcs) at the range of 6000 m from the radar as stated in r1.

for the range resolution test, specify two targets with different rcs separated in range by 70 m as required by r2.

open this test suite in test manager.

open('slexradararchitecturetests.mldatx')

after adding the tests and linking them to the requirements, the status of the requirements in the requirements editor indicates that the verification has been added but the tests have not yet been executed.

now the tests can be launched. after running both test suites, inspect the results of each individual iteration using the data inspector. the custom criteria helper function also prints the status of each iteration to the command window.

since both tests passed, requirements editor now shows that both requirements have been implemented and verified.

revised requirements

it is common that during a design process the initial requirements are revised and changed. this example assumes that the new maximum range requirement is 8000 m and the new range resolution requirement is 35 m. the updated requirements are:

making changes to requirements in requirements editor will generate change issues and highlight the summary status of the corresponding requirement in red. the links to the components that implement the changed requirement and to the tests that verify it are also highlighted. this way it is easy to identify which components of the design and which tests need to be updated in order to address the changes in the requirement and to test them.

to monitor the changes in the requirements or in the implementations of the system components use the requirements traceability matrix.

updated system parameters

the new maximum range requirement is beyond the current unambiguous range of the system that equals 7494.8 m. to satisfy the new requirement, increase the unambiguous range. this can be accomplished by lowering the prf. setting the prf to 16 khz results in the unambiguous range of 9368.5 m, which is well beyond the required maximum range of 8000 m.

since the current radar design transmits unmodulated rectangular pulses, the resolution limit of the system is determined by the pulse width. the current range resolution limit is 60 m. the new requirement of 35 m is almost two times lower. a rectangular pulse which satisfies this requirement would have to be twice as short, reducing the available power at the same range by half. the requirement analysis using the radar designer app shows that this system cannot reach the required detection performance at the maximum range of 8000 m. to achieve the required maximum range and range resolution, without increasing the peak transmitted power or the antenna gain, adopt a new waveform with the time-bandwidth product that is larger than 1. setting the pulse width to 1 μs and the bandwidth to 5 mhz will provide the desired resolution.

open this design in radar designer app.

radardesigner('radardesigner_lfmwaveform.mat')

the pulse waveform analyzer app can be used to select a radar waveform from several alternatives. this example uses the lfm waveform.

pulsewaveformanalyzer('pulsewaveformanalyzer_lfmwaveform.mat')

revised design

a convenient way to modify the behavior of a component of the system is to add an alternative design by creating a variant. this is done by right clicking on the component and selecting add variant choice. add a variant to waveform generator and add simulink behavior to it to implement the lfm waveform generation.

configure the linear fm block by setting the pulse width to the new value of 1 μs. set the sweep bandwidth to 5 mhz and the prf property to the updated prf value of 16 khz. run the model with the lfm waveform.

% set the model parameters
helperslexradararchitectureparameters;
% update the model parameters to use the lfm waveform
helperslexradararchitectureparameterslfm;
simout = sim('slexradararchitectureexample.slx');
data = simout.logsout{1}.values.data;
figure;
plot(range_gates, data(numel(range_gates) 1:end));
xlabel('range (m)');
ylabel('power (w)');
title('signal processor output');
grid on;

updated tests

before verifying that the radar system with lfm can satisfy the updated requirements, make corresponding modifications to the tests by updating the targets positions.

after updating the tests, clear all change issues in requirements editor. click show links in the requirements tab, then select the links and click on clear all button in change information section of the details panel on the right. launch the test when the issues are cleared. the new design will pass the updated tests and verify that the system satisfies the updated requirements confirming the predictions made by the radar designer app.

summary

this example is the second part of a two-part series on how to design and test a radar system in simulink based on a set of performance requirements. it shows how to use simulink test to test the model developed in part 1, how to link the test to the requirements, and how to verify that the requirements are satisfied by running monte carlo simulations. the example also illustrates how to trace changes in the requirements to the corresponding components and how to create alternative designs by adding variants to the model. part 1 of this example starts with the requirements that must be satisfied by the final design. it uses system composer to develop an architecture model of a radar system that can serve as a virtual test bed. part 1 also shows how to use requirements toolbox to link the requirements to the components and how to implement the individual components of the architecture using simulink.