Skip to main content

Full text: 28: Functional scope and model of integrated navigation systems

159 
1 Introduction 
The purpose of this part is to derive requirements for the testing of integrated navigation systems from 
the generic model of integrated navigation outlined in part B. The analysis of the model has shown that 
the explicit allocation of requirements to certain processes is difficult since it cannot be clearly estab 
lished in which system component the data-supplying process is located. One example is the treatment 
of set values and limits for executing course changing manoeuvres. These may be defined in a spe 
cialised functional component “Drafting the voyage plan (1)”. Such set values and limits may how 
ever also be set in the component “Monitoring and executing the voyage (2)”. Several possibilities 
thereby arise: 
a) Set values and limits are fixed in “Drafting the voyage plan (1)”. 
I Their values are transferred to “Monitoring and executing the voyage (2)”. 
II The manoeuvres are carried out with the transmitted values in “Monitoring and executing the 
voyage (2)”. 
III Limits set locally in “Monitoring and executing the voyage (2)” may not act in delimiting 
manner on the transferred planning data. 
IV If limits set in “Monitoring and executing the voyage (2)” are not modifiable, signalling occurs 
in the event of conflict situations between the values from “Drafting the voyage plan (1)” and 
from “Monitoring and executing the voyage (2)” before execution of the manoeuvre. 
or 
b) The definition of set values and limits is dispensed with during the planning phase in “Drafting the 
voyage plan (1)”. 
I No transfer of these values to “Monitoring and executing the voyage (2)” takes place. 
II In the functional components for “Monitoring and executing the voyage (2)”, focal input options 
and administration arrangements are retained for these values. 
All conceivable solutions may lead to a consistent system philosophy. The formulation of requirements 
permitting only a certain implementation would therefore constitute an undue restriction. 
In this report, therefore, the formulation of test requirements is concentrated on the data flows, i.e. re 
quirements on the exchanged data flows are essentially formulated. In this instance, the starting point in 
each case is the information sinks. This means that the logic chain, which is produced from the gen 
eration of primary information in the sources, further processing and derivation of information up to the 
point of usage of information in information sinks, is followed back when specifying requirements. From 
the functionality of the information sinks are produced requirements on the received data (e.g. with re 
gard to quality or consistency); from these requirements can in turn be derived necessary properties of 
information sources. 
In order to make the catalogue of test requirements for creation, application and maintenance manage 
able, an appropriate structuring of the requirements is absolutely necessary. In this report, the test re 
quirements are first of all structured according to the particular processing procedure and the data type 
considered. As a further classification criterion, a process of categorisation of the requirements on input 
information was undertaken. In the following, the categories used here are explained in detail.
	        
Waiting...

Note to user

Dear user,

In response to current developments in the web technology used by the Goobi viewer, the software no longer supports your browser.

Please use one of the following browsers to display this page correctly.

Thank you.