%% --------------------------------------------------------------------
%% HybridSAL
%% Copyright (C) 2006, SRI International.  All Rights Reserved.
%% 
%% This program is free software; you can redistribute it and/or
%% modify it under the terms of the GNU General Public License
%% as published by the Free Software Foundation; either version 2
%% of the License, or (at your option) any later version.
%% 
%% This program is distributed in the hope that it will be useful,
%% but WITHOUT ANY WARRANTY; without even the implied warranty of
%% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
%% GNU General Public License for more details.
%% 
%% You should have received a copy of the GNU General Public License
%% along with this program; if not, write to the Free Software
%% Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
%% --------------------------------------------------------------------


Running these examples will help you understand the
working of the hybrid abstractor.

1. SimpleThermo3.sal
   This is a simple example of a thermostat.
   In the hybridsal-light root directory:
  (load "load.lisp")
  (in-package :sal)
  (abstract "examples/SimpleThermo3" 'control)
   will create an abstraction of the hybrid model in
   SimpleThermo3.sal
   The output is stored in SimpleThermo3ABS.sal
   
   There will be no properties in this file, so to
   model-check you will need to write a property
   (using the new abstract variables in SimpleThermo3ABS.sal).
   
   Alternatively,
  (abstract "examples/SimpleThermo3" 'control :property 'correct)
  will also abstract the property named 'correct in SimpleThermo3.sal
  Now, you can run the sal-model-checker :
  sal-smc -v 3 SimpleThermo3ABS correct

  (abstract "examples/SimpleThermo3" 'control :property 'all)
   will abstract ALL properties in the file SimpleThermo3.sal

2. Aircraft.sal
  (load "load.lisp")
  (in-package :sal)
  (abstract "examples/SimpleThermo3" 'control :property 'all)
   Model-checking either of the two propertoes, noconflict and
   noconflict1, will give counter-examples.

   However, property noconflict1 is actually true.  The reason
   for the counter-example is that the start state itself is
   infeasible.
  
   To avoid this behavior, we add a precondition to the formula.
   THat is, we replace the original property:

  noconflict1: THEOREM
    twoaircraft |- G(state = TRUE OR NOT(g2603 = neg AND g2616 = neg));

  by the new property:

  noconflict1: THEOREM
    twoaircraft |- 
      INV87069(g2915, g2876, g2838, g2804, g2771, g2741, g2710, g2686, g2665, g2646, g2630, g2616, g2603, g2589, g2585) =>
	G(state = TRUE OR NOT(g2603 = neg AND g2616 = neg));
   
   Here INV87069(...) is a function which requires that the initial
   state be feasible.  The exact name of this function and its
   arguments can be found from the AircraftABS.sal file.

3. The abstractor also works on lacv4.sal
   (abstract "examples/lacv4" 'cell)

   Note that the specification lacv4.sal uses an
   "inside-out" representation of a hybrid automaton.
