   =========================================================================
   ==       N O T I C E  f i l e      --        TIMING-1.0-SNAPSHOT       ==
   =========================================================================

   =====================================
   =  Modular Verification Approach:  =
   =====================================

	Common Library (comlibrary)
	    Contains common imports used by both the SRS and SDD
	    Leverages time models from Jason's thesis

	SRS Library (srslibrary)
	    Common imports relevant to the SRS domain, 
	     e.g. types, common functions within the SRS type domain, etc.

	SDD Library (sddlibrary)
	    Common imports relevant to the SDD domain, 
	     e.g. types, common function blocks, etc.
	    TON function block was redefined to make use of the pre-verified 
	     Timer_I component. Usage of this needs to be validated.

	SRS Functions (srsfunctions)
	    Modelled functions from the TCDD.
	    Partioning was required in order to correctly map the topology 
	     between the SRS and SDD.
	    An equivalence proof is provided to show that the partition maps 
	     with the original requirements. Method needs validation.
	    The tabular expression was modified to correct for PVS errors. 
	     The firs tcondition was commented and an additional Held For 
	     with the Stuck delay was added. See 3.a. and 3.b. below.

	SDD Functions (sddfunctions)
	    Modelled functions from the SDD, created manually from the pdf 
	     files in the attachment.
	    Has modifications NOT consistent with actual implementation required
	     to produce a functioning model. An AND with NOT inputs had to
	     replace the NOT in the original design to allow for verification 
	     with the Not Held For with the Stuck delay. 
	     See 3.a. and 3.b. below.
	    Contains a functional and predicate model accompanied with an 
	     inline equivalence proof using a prooflite script.

	Abstractions (abstractions)
	    Abstraction functions used to map types between the SRS and 
	     SDD domain.

	Obligations (obligations)
	    Design verification between the SRS and SDD domains.
	    Contains a consistency check using the composite functional model,
	     and a correctness check using the predicate model.
	    Proofs are inline using prooflite scripts.
            Generically imports the tolerance sub-models using arbitrary 
	     parameters.
	    Proofs make use of pre-verified component in contained in the 
	     comlibrary.
 
   =====================================
   =         Important Points:         =
   =====================================

1.       Used arbitrary durations and tolerances to be consistent with the 
	  pre-verified components; necessary to get a functioning evaluation.

	 How should durations and tolerances be instantiated?
 
2.       TimerGeneral contains a theorem used as the basis of this evaluation.

	 Is this base model sufficient to ensure compliance between the 
	  SDD and SRS? 

	 If not, an alternative base theory could be created and verified, 
	  and then integrated with the higher level modules without 
	  impacting the topology of this approach.
 
3.       Modelled requirements and design do not reflect the current state 
	  due to problems encountered in the TCDD. Subsequently the SRS and 
	  SDD models were changed to create a functioning evaluation. 
	  Changes are summarized below:
 
	 a.       TCDD tabular expression was not disjoint and TE was modified. 
	 	  Added component required a change in the model for the 
		  implementation.
	 b.       i( t ) component of the TCDD tabular expression is redundant 
	 	  as Held For  function handles cases when i( t ) = false, 
		  e.g. ( i( t ) = false ) <=> ( ( i( t ) = false ) Held For … )
 
4.       Topology between SRS and SDD does not match. The approach used was to 
	  partition the requirements and verify the partitions against the SDD 
	  using Linna's verification methodology.
5.       This model ignores initialization, how may that be implemented?
6.       Only modeled -delta_L with duration, do we need an additional case 
	  for +delta_R? How should we treat grey regions 
	  (e.g. within the +/- delta_L/delta_R regions)?  Could function be in	
	  multiples, for example Debounce and/or Stuck?  Should we model all 
	  possible cases?  Is this necessary?
7.       Is it ok to prove the consistency test using the individual functions 
	  instead the overall function?  What are the implications of this 
	  instead of proving the overall functions?  Is this similar to the 
	  correctness check?  Is it ok to prove the correctness check with 
	  the overall predicate function of the SDD with the 3 individual SRS 
	  functions?

   =====================================
   =             Summary:              =
   =====================================

Modular approach integrates pre-verified components from both Jason and Linna 
 and minimizes change impact from core modules.

Requires validation, feedback, and areas of improvement.