Page Comparison

In order to prevent the plugins from reporting physically wrong results the validity of actual parameter values are checked during the calculations (Figure 317). In case parameter values exceed the valid range, appropriate exceptions, e.g. RuntimeException, stops the plugin from doing further calculations.

...

Image Added

...

The basic principle on that is quite simple: the more extensive the checks the less the risk of running into problems during the simulation.

For this, each type of plugins provides the same method consistencyCheck() to perform the recommended checks: 

...

Image Added

The referenced parameters are detailed as follow:

• Scenario:
  settings of the systems used for the workspace. It holds the settings of the scenario as specified in the UIConsistencyCheckContext: provides information about parameters relevant for the type of plugin.
• List<Object>:
  depending on the type of plugin it contains one or two objects which are either a Radio System or links which can be the system link, the interference link or the sensing link of generic systems. Corresponding details are described in the following sub-sections.
• Input
  the input parameters of the plugin
• Validator:
  provides the interface to the scenario check in returning the consistency check messages generated by the plugin

 Image Added

Concerning the List<Object> ConsistencyCheckContext it is important to be aware of the applicability of plugins to the scenario components:

• an antenna plugin (AP) can be applied only to a radio system, i.e. a generic system or a cellular system, hence the Origin is set to SYSTEM;
• a coverage radius plugin (CRP) can be applied only to a generic system, , hence the Origin is either SYSTEM or in case the system is the interferer INTERFERENCE_LINK;
• a propagation model plugin (PMP) can be applied to the system link, the interference link and the sensing link, , hence the origin can be SYSTEM or INTERFERENCE_LINK, depending on to which link the PMP is applied;
• an event processing plugin (EPP) and its custom post processing user interface (custom UIPPUI) cannot be applied to any of the scenario components

Consequently, the default informations passed to the consistency check as List<Object> of the plugins are as follows:

1. for the antenna plugin (AP)

0: the radio system

1: the component applying the antenna, i.e. either the TX or the RX

2. for the coverage radius plugin (CRP)

0: the generic system   

3. for the propagation model plugin (PMP)

0: the system link or the interference link in case not used for the sensing link

        or in case where the PMP is used for the sensing link

0: the interference link

1: the sensing link

4. for the event processing plugin (EPP) the List<Object> is always empty.

note: the above numbers 0 and 1 are the list indices

• , hence its ConsistencyCheckContext is set to NULL, except the Scenario which is not available for other plugins.

This default information can be replaced or extended if the plugin is nested, i.e. if the plugin is used as an input parameter of another plugin (annotation, see the previous section ‎1414.3.1).

In order to avoid conflicts on the consistency check it is therefore very important that all default instances of the plugin types are checked, for instance like this for a PMP:

Image Removed

Figure 319: Example of a PMP checking for the default instances

...

case you apply nested plugins it is highly recommended to check the validity of these nested plugins inside the consistency check of your 'parent' plugin. The below example of an EPP which uses a nested PMP wants only to show the principle of checking input parameters:

In case you apply nested plugins it is highly recommended to check the validity of these nested plugins inside the consistency check of your 'parent' plugin. The below example of an EPP which uses a nested PMP wants only to show the principle of checking input parameters:

...

Image Added

...