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  established ­
  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  specialised ­
  functional  component  “Drafting  the  voyage  plan  (1)”.  Such  set  values  and  limits  may  however ­
  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.  requirements ­
  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  generation ­
  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  regard ­
  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  manageable, ­
  an  appropriate  structuring  of  the  requirements  is  absolutely  necessary.  In  this  report,  the  test  requirements ­
  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.