Thesis - Leigh Moody.pdf - Bad Request - Cranfield University

Appendix I / Utilities
_ _
APPENDIX I
22 SIMULATION UTILITIES
Utility software is rarely afforded the importance it deserves when starting
out to create research simulations on the scale described in this document.
Often a proprietary source is used, or in haste utilities are ignored and
disparate groups will forge software devoid of common facilities. The use
of proprietary software limits portability, and hence a product’s potential, as
different host processors may not support a particular product, or the
Customer may be unwilling to acquire the necessary software licences.
These difficulties have been avoided by creating a software library
containing utilities customised to suite the combined disciplines within this
application. Customised utilities are generally simpler, and often quicker,
than more general utilities that contain facilities that are not applicable but
are non-the-less executed. It also means that the method of data transfer
between the utilities and core models can be controlled. In this respect the
use of the “global” common block (GCB) is severely restricted as this
defeats the principle of transferable modules; augment lists being the
preferred mode of data transfer.
The utility software forms the backbone of this research simulation, and by
inheritance the AMIS. The design ethos for both was such that if the same
function was performed more than once it was classified as generic
requiring a utility. In most cases this has resulted in utilities comprising
single, simple functions. The utility software modules are stored by
functional group. The downside of creating a separate utility library is the
cost of testing. Fortunately, as this software has been used in the
development of MBDA products it has received a considerable amount of
testing.
21.5-1