Initial commit.

CMakeLists.txt

@@ -0,0 +1,70 @@
+# This file is part of EPOCH.
+# File: CMakeLists.txt
+# Author: Florent Teichteil-Königsbuch
+# Contact: florent.teichteil@onera.fr
+#
+#    EPOCH 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 3 of the License, or
+#    (at your option) any later version.
+#
+#    EPOCH 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 EPOCH.  If not, see <http://www.gnu.org/licenses/>.
+
+CMAKE_MINIMUM_REQUIRED (VERSION 2.8)
+
+PROJECT (EPOCH)
+ENABLE_LANGUAGE(C CXX Fortran)
+
+SET (CMAKE_MODULE_PATH ${CMAKE_HOME_DIRECTORY}/config)
+
+INCLUDE (CheckIncludeFiles)
+
+SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x")
+
+#####################
+# FIND DEPENDENCIES #
+#####################
+
+FIND_PACKAGE (Boost 1.46.0 COMPONENTS program_options timer chrono filesystem system date_time timer unit_test_framework REQUIRED)
+INCLUDE_DIRECTORIES (${Boost_INCLUDE_DIRS} ${SUITESPARSE_PATH})
+LINK_DIRECTORIES (${Boost_LIBRARY_DIRS})
+MESSAGE (STATUS "Found Boost version: " ${Boost_VERSION})
+
+OPTION (BUILD_GUI "Build EPOCH's Graphical User Interface" OFF)
+IF (BUILD_GUI)
+	FIND_PACKAGE (wxWidgetsCustom COMPONENTS base core aui xml REQUIRED)
+	SET (CMAKE_REQUIRED_INCLUDES_COPY ${CMAKE_REQUIRED_INCLUDES})
+	LIST (APPEND CMAKE_REQUIRED_INCLUDES ${wxWidgets_INCLUDE_DIRS})
+	CHECK_INCLUDE_FILES (wx/aui/tabdocmdi.h HAVE_TABDOCMDI_H)
+	SET (CMAKE_REQUIRED_INCLUDES ${CMAKE_REQUIRED_INCLUDES_COPY})
+	FIND_PACKAGE (PLplot REQUIRED)
+	IF (NOT PLplot_wxwidgets_LIBRARY)
+		MESSAGE (FATAL_ERROR "PLplot wxwidgets bindings required to build the GUI")
+	ENDIF(NOT PLplot_wxwidgets_LIBRARY)
+ENDIF (BUILD_GUI)
+
+OPTION (BUILD_DOC "Build Doxygen documentation" OFF)
+IF (BUILD_DOC)
+	FIND_PACKAGE (Doxygen REQUIRED)
+ENDIF (BUILD_DOC)
+
+##################
+# COMPILES FILES #
+##################
+
+ADD_SUBDIRECTORY (sdk)
+ADD_SUBDIRECTORY (src)
+
+#######################
+# BUILD DOCUMENTATION #
+#######################
+
+IF (BUILD_DOC)
+	ADD_SUBDIRECTORY (doc)
+ENDIF (BUILD_DOC)

Copyright

@@ -1,10 +0,0 @@
-Copyright (c) 2017-2018 IRT AESE (IRT Saint Exupéry).
-All rights reserved. This program and the accompanying materials
-are made available under the terms of the
-CeCILL-C V1
-
-which accompanies this distribution, and is available at
-http://www.cecill.info/licences/Licence_CeCILL-C_V1-fr.html
-
-Contributors:
-Alexandre Albore – Initial contribution

LGPL-v2.txt

@@ -0,0 +1,481 @@
+                  GNU LIBRARY GENERAL PUBLIC LICENSE
+                       Version 2, June 1991
+
+ Copyright (C) 1991 Free Software Foundation, Inc.
+ 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+[This is the first released version of the library GPL.  It is
+ numbered 2 because it goes with version 2 of the ordinary GPL.]
+
+                            Preamble
+
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+Licenses are intended to guarantee your freedom to share and change
+free software--to make sure the software is free for all its users.
+
+  This license, the Library General Public License, applies to some
+specially designated Free Software Foundation software, and to any
+other libraries whose authors decide to use it.  You can use it for
+your libraries, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+  To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if
+you distribute copies of the library, or if you modify it.
+
+  For example, if you distribute copies of the library, whether gratis
+or for a fee, you must give the recipients all the rights that we gave
+you.  You must make sure that they, too, receive or can get the source
+code.  If you link a program with the library, you must provide
+complete object files to the recipients so that they can relink them
+with the library, after making changes to the library and recompiling
+it.  And you must show them these terms so they know their rights.
+
+  Our method of protecting your rights has two steps: (1) copyright
+the library, and (2) offer you this license which gives you legal
+permission to copy, distribute and/or modify the library.
+
+  Also, for each distributor's protection, we want to make certain
+that everyone understands that there is no warranty for this free
+library.  If the library is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original
+version, so that any problems introduced by others will not reflect on
+the original authors' reputations.
+
+  Finally, any free program is threatened constantly by software
+patents.  We wish to avoid the danger that companies distributing free
+software will individually obtain patent licenses, thus in effect
+transforming the program into proprietary software.  To prevent this,
+we have made it clear that any patent must be licensed for everyone's
+free use or not licensed at all.
+
+  Most GNU software, including some libraries, is covered by the ordinary
+GNU General Public License, which was designed for utility programs.  This
+license, the GNU Library General Public License, applies to certain
+designated libraries.  This license is quite different from the ordinary
+one; be sure to read it in full, and don't assume that anything in it is
+the same as in the ordinary license.
+
+  The reason we have a separate public license for some libraries is that
+they blur the distinction we usually make between modifying or adding to a
+program and simply using it.  Linking a program with a library, without
+changing the library, is in some sense simply using the library, and is
+analogous to running a utility program or application program.  However, in
+a textual and legal sense, the linked executable is a combined work, a
+derivative of the original library, and the ordinary General Public License
+treats it as such.
+
+  Because of this blurred distinction, using the ordinary General
+Public License for libraries did not effectively promote software
+sharing, because most developers did not use the libraries.  We
+concluded that weaker conditions might promote sharing better.
+
+  However, unrestricted linking of non-free programs would deprive the
+users of those programs of all benefit from the free status of the
+libraries themselves.  This Library General Public License is intended to
+permit developers of non-free programs to use free libraries, while
+preserving your freedom as a user of such programs to change the free
+libraries that are incorporated in them.  (We have not seen how to achieve
+this as regards changes in header files, but we have achieved it as regards
+changes in the actual functions of the Library.)  The hope is that this
+will lead to faster development of free libraries.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.  Pay close attention to the difference between a
+"work based on the library" and a "work that uses the library".  The
+former contains code derived from the library, while the latter only
+works together with the library.
+
+  Note that it is possible for a library to be covered by the ordinary
+General Public License rather than by this special one.
+
+                  GNU LIBRARY GENERAL PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License Agreement applies to any software library which
+contains a notice placed by the copyright holder or other authorized
+party saying it may be distributed under the terms of this Library
+General Public License (also called "this License").  Each licensee is
+addressed as "you".
+
+  A "library" means a collection of software functions and/or data
+prepared so as to be conveniently linked with application programs
+(which use some of those functions and data) to form executables.
+
+  The "Library", below, refers to any such software library or work
+which has been distributed under these terms.  A "work based on the
+Library" means either the Library or any derivative work under
+copyright law: that is to say, a work containing the Library or a
+portion of it, either verbatim or with modifications and/or translated
+straightforwardly into another language.  (Hereinafter, translation is
+included without limitation in the term "modification".)
+
+  "Source code" for a work means the preferred form of the work for
+making modifications to it.  For a library, complete source code means
+all the source code for all modules it contains, plus any associated
+interface definition files, plus the scripts used to control compilation
+and installation of the library.
+
+  Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope.  The act of
+running a program using the Library is not restricted, and output from
+such a program is covered only if its contents constitute a work based
+on the Library (independent of the use of the Library in a tool for
+writing it).  Whether that is true depends on what the Library does
+and what the program that uses the Library does.
+  
+  1. You may copy and distribute verbatim copies of the Library's
+complete source code as you receive it, in any medium, provided that
+you conspicuously and appropriately publish on each copy an
+appropriate copyright notice and disclaimer of warranty; keep intact
+all the notices that refer to this License and to the absence of any
+warranty; and distribute a copy of this License along with the
+Library.
+
+  You may charge a fee for the physical act of transferring a copy,
+and you may at your option offer warranty protection in exchange for a
+fee.
+
+  2. You may modify your copy or copies of the Library or any portion
+of it, thus forming a work based on the Library, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+
+    a) The modified work must itself be a software library.
+
+    b) You must cause the files modified to carry prominent notices
+    stating that you changed the files and the date of any change.
+
+    c) You must cause the whole of the work to be licensed at no
+    charge to all third parties under the terms of this License.
+
+    d) If a facility in the modified Library refers to a function or a
+    table of data to be supplied by an application program that uses
+    the facility, other than as an argument passed when the facility
+    is invoked, then you must make a good faith effort to ensure that,
+    in the event an application does not supply such function or
+    table, the facility still operates, and performs whatever part of
+    its purpose remains meaningful.
+
+    (For example, a function in a library to compute square roots has
+    a purpose that is entirely well-defined independent of the
+    application.  Therefore, Subsection 2d requires that any
+    application-supplied function or table used by this function must
+    be optional: if the application does not supply it, the square
+    root function must still compute square roots.)
+
+These requirements apply to the modified work as a whole.  If
+identifiable sections of that work are not derived from the Library,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works.  But when you
+distribute the same sections as part of a whole which is a work based
+on the Library, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote
+it.
+
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Library.
+
+In addition, mere aggregation of another work not based on the Library
+with the Library (or with a work based on the Library) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+  3. You may opt to apply the terms of the ordinary GNU General Public
+License instead of this License to a given copy of the Library.  To do
+this, you must alter all the notices that refer to this License, so
+that they refer to the ordinary GNU General Public License, version 2,
+instead of to this License.  (If a newer version than version 2 of the
+ordinary GNU General Public License has appeared, then you can specify
+that version instead if you wish.)  Do not make any other change in
+these notices.
+
+  Once this change is made in a given copy, it is irreversible for
+that copy, so the ordinary GNU General Public License applies to all
+subsequent copies and derivative works made from that copy.
+
+  This option is useful when you wish to copy part of the code of
+the Library into a program that is not a library.
+
+  4. You may copy and distribute the Library (or a portion or
+derivative of it, under Section 2) in object code or executable form
+under the terms of Sections 1 and 2 above provided that you accompany
+it with the complete corresponding machine-readable source code, which
+must be distributed under the terms of Sections 1 and 2 above on a
+medium customarily used for software interchange.
+
+  If distribution of object code is made by offering access to copy
+from a designated place, then offering equivalent access to copy the
+source code from the same place satisfies the requirement to
+distribute the source code, even though third parties are not
+compelled to copy the source along with the object code.
+
+  5. A program that contains no derivative of any portion of the
+Library, but is designed to work with the Library by being compiled or
+linked with it, is called a "work that uses the Library".  Such a
+work, in isolation, is not a derivative work of the Library, and
+therefore falls outside the scope of this License.
+
+  However, linking a "work that uses the Library" with the Library
+creates an executable that is a derivative of the Library (because it
+contains portions of the Library), rather than a "work that uses the
+library".  The executable is therefore covered by this License.
+Section 6 states terms for distribution of such executables.
+
+  When a "work that uses the Library" uses material from a header file
+that is part of the Library, the object code for the work may be a
+derivative work of the Library even though the source code is not.
+Whether this is true is especially significant if the work can be
+linked without the Library, or if the work is itself a library.  The
+threshold for this to be true is not precisely defined by law.
+
+  If such an object file uses only numerical parameters, data
+structure layouts and accessors, and small macros and small inline
+functions (ten lines or less in length), then the use of the object
+file is unrestricted, regardless of whether it is legally a derivative
+work.  (Executables containing this object code plus portions of the
+Library will still fall under Section 6.)
+
+  Otherwise, if the work is a derivative of the Library, you may
+distribute the object code for the work under the terms of Section 6.
+Any executables containing that work also fall under Section 6,
+whether or not they are linked directly with the Library itself.
+
+  6. As an exception to the Sections above, you may also compile or
+link a "work that uses the Library" with the Library to produce a
+work containing portions of the Library, and distribute that work
+under terms of your choice, provided that the terms permit
+modification of the work for the customer's own use and reverse
+engineering for debugging such modifications.
+
+  You must give prominent notice with each copy of the work that the
+Library is used in it and that the Library and its use are covered by
+this License.  You must supply a copy of this License.  If the work
+during execution displays copyright notices, you must include the
+copyright notice for the Library among them, as well as a reference
+directing the user to the copy of this License.  Also, you must do one
+of these things:
+
+    a) Accompany the work with the complete corresponding
+    machine-readable source code for the Library including whatever
+    changes were used in the work (which must be distributed under
+    Sections 1 and 2 above); and, if the work is an executable linked
+    with the Library, with the complete machine-readable "work that
+    uses the Library", as object code and/or source code, so that the
+    user can modify the Library and then relink to produce a modified
+    executable containing the modified Library.  (It is understood
+    that the user who changes the contents of definitions files in the
+    Library will not necessarily be able to recompile the application
+    to use the modified definitions.)
+
+    b) Accompany the work with a written offer, valid for at
+    least three years, to give the same user the materials
+    specified in Subsection 6a, above, for a charge no more
+    than the cost of performing this distribution.
+
+    c) If distribution of the work is made by offering access to copy
+    from a designated place, offer equivalent access to copy the above
+    specified materials from the same place.
+
+    d) Verify that the user has already received a copy of these
+    materials or that you have already sent this user a copy.
+
+  For an executable, the required form of the "work that uses the
+Library" must include any data and utility programs needed for
+reproducing the executable from it.  However, as a special exception,
+the source code distributed need not include anything that is normally
+distributed (in either source or binary form) with the major
+components (compiler, kernel, and so on) of the operating system on
+which the executable runs, unless that component itself accompanies
+the executable.
+
+  It may happen that this requirement contradicts the license
+restrictions of other proprietary libraries that do not normally
+accompany the operating system.  Such a contradiction means you cannot
+use both them and the Library together in an executable that you
+distribute.
+
+  7. You may place library facilities that are a work based on the
+Library side-by-side in a single library together with other library
+facilities not covered by this License, and distribute such a combined
+library, provided that the separate distribution of the work based on
+the Library and of the other library facilities is otherwise
+permitted, and provided that you do these two things:
+
+    a) Accompany the combined library with a copy of the same work
+    based on the Library, uncombined with any other library
+    facilities.  This must be distributed under the terms of the
+    Sections above.
+
+    b) Give prominent notice with the combined library of the fact
+    that part of it is a work based on the Library, and explaining
+    where to find the accompanying uncombined form of the same work.
+
+  8. You may not copy, modify, sublicense, link with, or distribute
+the Library except as expressly provided under this License.  Any
+attempt otherwise to copy, modify, sublicense, link with, or
+distribute the Library is void, and will automatically terminate your
+rights under this License.  However, parties who have received copies,
+or rights, from you under this License will not have their licenses
+terminated so long as such parties remain in full compliance.
+
+  9. You are not required to accept this License, since you have not
+signed it.  However, nothing else grants you permission to modify or
+distribute the Library or its derivative works.  These actions are
+prohibited by law if you do not accept this License.  Therefore, by
+modifying or distributing the Library (or any work based on the
+Library), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Library or works based on it.
+
+  10. Each time you redistribute the Library (or any work based on the
+Library), the recipient automatically receives a license from the
+original licensor to copy, distribute, link with or modify the Library
+subject to these terms and conditions.  You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties to
+this License.
+
+  11. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Library at all.  For example, if a patent
+license would not permit royalty-free redistribution of the Library by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Library.
+
+If any portion of this section is held invalid or unenforceable under any
+particular circumstance, the balance of the section is intended to apply,
+and the section as a whole is intended to apply in other circumstances.
+
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system which is
+implemented by public license practices.  Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+
+  12. If the distribution and/or use of the Library is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Library under this License may add
+an explicit geographical distribution limitation excluding those countries,
+so that distribution is permitted only in or among countries not thus
+excluded.  In such case, this License incorporates the limitation as if
+written in the body of this License.
+
+  13. The Free Software Foundation may publish revised and/or new
+versions of the Library General Public License from time to time.
+Such new versions will be similar in spirit to the present version,
+but may differ in detail to address new problems or concerns.
+
+Each version is given a distinguishing version number.  If the Library
+specifies a version number of this License which applies to it and
+"any later version", you have the option of following the terms and
+conditions either of that version or of any later version published by
+the Free Software Foundation.  If the Library does not specify a
+license version number, you may choose any version ever published by
+the Free Software Foundation.
+
+  14. If you wish to incorporate parts of the Library into other free
+programs whose distribution conditions are incompatible with these,
+write to the author to ask for permission.  For software which is
+copyrighted by the Free Software Foundation, write to the Free
+Software Foundation; we sometimes make exceptions for this.  Our
+decision will be guided by the two goals of preserving the free status
+of all derivatives of our free software and of promoting the sharing
+and reuse of software generally.
+
+                            NO WARRANTY
+
+  15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
+WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
+EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
+OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY
+KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
+LIBRARY IS WITH YOU.  SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME
+THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+  16. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
+WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY
+AND/OR REDISTRIBUTE THE LIBRARY AS PERMITTED ABOVE, BE LIABLE TO YOU
+FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
+CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE
+LIBRARY (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING
+RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A
+FAILURE OF THE LIBRARY TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF
+SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
+DAMAGES.
+
+                     END OF TERMS AND CONDITIONS
+
+           How to Apply These Terms to Your New Libraries
+
+  If you develop a new library, and you want it to be of the greatest
+possible use to the public, we recommend making it free software that
+everyone can redistribute and change.  You can do so by permitting
+redistribution under these terms (or, alternatively, under the terms of the
+ordinary General Public License).
+
+  To apply these terms, attach the following notices to the library.  It is
+safest to attach them to the start of each source file to most effectively
+convey the exclusion of warranty; and each file should have at least the
+"copyright" line and a pointer to where the full notice is found.
+
+    <one line to give the library's name and a brief idea of what it does.>
+    Copyright (C) <year>  <name of author>
+
+    This library is free software; you can redistribute it and/or
+    modify it under the terms of the GNU Library General Public
+    License as published by the Free Software Foundation; either
+    version 2 of the License, or (at your option) any later version.
+
+    This library 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
+    Library General Public License for more details.
+
+    You should have received a copy of the GNU Library General Public
+    License along with this library; if not, write to the Free Software
+    Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+
+Also add information on how to contact you by electronic and paper mail.
+
+You should also get your employer (if you work as a programmer) or your
+school, if any, to sign a "copyright disclaimer" for the library, if
+necessary.  Here is a sample; alter the names:
+
+  Yoyodyne, Inc., hereby disclaims all copyright interest in the
+  library `Frob' (a library for tweaking knobs) written by James Random Hacker.
+
+  <signature of Ty Coon>, 1 April 1990
+  Ty Coon, President of Vice
+
+That's all there is to it!

LICENSES.md

@@ -0,0 +1,143 @@
+# Copyrights and licensing
+
+## Altarica / Fiacre translator 
+The Altarica / Fiacre translator is copyright 2015-2017 ONERA (the French Aerospace Lab) and IRT Saint Exupéry.
+All rights reserved. It is distributed under the terms of the CeCILL-C license.
+See the accompanying file CeCILL-C.txt, <http://www.cecill.info/licences/Licence_CeCILL-C_V1-en.html>
+or <http://www.cecill.info/licences/Licence_CeCILL-C_V1-fr.html>.
+
+## Third party components
+
+### Boost under the terms of BOOST license <http://www.boost.org/LICENSE_1_0.txt>:
+					
+	Boost Software License - Version 1.0 - August 17th, 2003
+	
+	Permission is hereby granted, free of charge, to any person or organization
+	obtaining a copy of the software and accompanying documentation covered by
+	this license (the "Software") to use, reproduce, display, distribute,
+	execute, and transmit the Software, and to prepare derivative works of the
+	Software, and to permit third-parties to whom the Software is furnished to
+	do so, all subject to the following:
+	
+	The copyright notices in the Software and this entire statement, including
+	the above license grant, this restriction and the following disclaimer,
+	must be included in all copies of the Software, in whole or in part, and
+	all derivative works of the Software, unless such copies or derivative
+	works are solely in the form of machine-executable object code generated by
+	a source language processor.
+	
+	THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+	IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+	FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT. IN NO EVENT
+	SHALL THE COPYRIGHT HOLDERS OR ANYONE DISTRIBUTING THE SOFTWARE BE LIABLE
+	FOR ANY DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR OTHERWISE,
+	ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+	DEALINGS IN THE SOFTWARE.
+
+### Buddy 2.4
+
+               Copyright (C) 1996-2002 by Jorn Lind-Nielsen
+                            All rights reserved
+
+    Permission is hereby granted, without written agreement and without
+    license or royalty fees, to use, reproduce, prepare derivative
+    works, distribute, and display this software and its documentation
+    for any purpose, provided that (1) the above copyright notice and
+    the following two paragraphs appear in all copies of the source code
+    and (2) redistributions, including without limitation binaries,
+    reproduce these notices in the supporting documentation. Substantial
+    modifications to this software may be copyrighted by their authors
+    and need not follow the licensing terms described here, provided
+    that the new terms are clearly indicated in all files where they apply.
+
+    IN NO EVENT SHALL JORN LIND-NIELSEN, OR DISTRIBUTORS OF THIS
+    SOFTWARE BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL,
+    INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OF THIS
+    SOFTWARE AND ITS DOCUMENTATION, EVEN IF THE AUTHORS OR ANY OF THE
+    ABOVE PARTIES HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+    JORN LIND-NIELSEN SPECIFICALLY DISCLAIM ANY WARRANTIES, INCLUDING,
+    BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
+    FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS
+    ON AN "AS IS" BASIS, AND THE AUTHORS AND DISTRIBUTORS HAVE NO
+    OBLIGATION TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR
+    MODIFICATIONS.
+
+### WxScintilla-1.69.2 from codelite-2.7.0.4375 and Wxshapeframework 1.9.2
+
+				https://opensource.org/licenses/WXwindows
+				
+					 wxWindows Library Licence, Version 3.1
+				     ======================================
+	
+	Copyright (c) 1998-2005 Julian Smart, Robert Roebling et al
+	
+	Everyone is permitted to copy and distribute verbatim copies
+	of this licence document, but changing it is not allowed.
+	
+	                     WXWINDOWS LIBRARY LICENCE
+	   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+	
+	This library is free software; you can redistribute it and/or modify it
+	under the terms of the GNU Library General Public Licence as published by
+	the Free Software Foundation; either version 2 of the Licence, or (at your
+	option) any later version.
+	
+	This library 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 Library General Public
+	Licence for more details.
+	
+	You should have received a copy of the GNU Library General Public Licence
+	along with this software, usually in a file named COPYING.LIB.  If not,
+	write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth
+	Floor, Boston, MA 02110-1301 USA.
+	
+	EXCEPTION NOTICE
+	
+	1. As a special exception, the copyright holders of this library give
+	permission for additional uses of the text contained in this release of the
+	library as licenced under the wxWindows Library Licence, applying either
+	version 3.1 of the Licence, or (at your option) any later version of the
+	Licence as published by the copyright holders of version 3.1 of the Licence
+	document.
+	
+	2. The exception is that you may use, copy, link, modify and distribute
+	under your own terms, binary object code versions of works based on the
+	Library.
+	
+	3. If you copy code from files distributed under the terms of the GNU
+	General Public Licence or the GNU Library General Public Licence into a
+	copy of this library, as this licence permits, the exception does not apply
+	to the code that you add in this way.  To avoid misleading anyone as to the
+	status of such modified files, you must delete this exception notice from
+	such code and/or adjust the licensing conditions notice accordingly.
+	
+	4. If you write modifications of your own for this library, it is your
+	choice whether to permit this exception to apply to your modifications.  If
+	you do not wish that, you must delete the exception notice from such code
+	and/or adjust the licensing conditions notice accordingly.	
+
+### Scintilla 1.62
+
+	License for Scintilla and SciTE
+	
+	Copyright 1998-2003 by Neil Hodgson <neilh@scintilla.org>
+	
+	All Rights Reserved 
+	
+	Permission to use, copy, modify, and distribute this software and its 
+	documentation for any purpose and without fee is hereby granted, 
+	provided that the above copyright notice appear in all copies and that 
+	both that copyright notice and this permission notice appear in 
+	supporting documentation. 
+	
+	NEIL HODGSON DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS 
+	SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY 
+	AND FITNESS, IN NO EVENT SHALL NEIL HODGSON BE LIABLE FOR ANY 
+	SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES 
+	WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, 
+	WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER 
+	TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE 
+	OR PERFORMANCE OF THIS SOFTWARE.
+	 

README.md

@@ -0,0 +1,17 @@
+# What are the prerequisites to build altarica_epoch?
+On Linux Ubuntu 16.04.1 LTS, the following packages are required to build altarica_epoch: build-essential, flex, bison, cmake, gcc/g++/gfortran 5.4.0, libsuitesparse-dev, libxml-dev, libglib2.0-dev, libsigc++-2.0-dev, libglibmm-2.4-dev, libxml++2.6-dev and pkg-config.
+	
+	sudo apt install build-essential flex bison cmake gcc-5 g++-5 gfortran-5 libsuitesparse-dev libxml-dev libglib2.0-dev libsigc++-2.0-dev libglibmm-2.4-dev libxml++2.6-dev pkg-config
+
+# How to build altarica_epoch?
+altarica_epoch uses CMake build system. It can be built with the following commands:
+
+	cd altarica_epoch
+	cmake ./CMakeList.txt
+	make
+	
+# How to launch altarica_epoch?
+You can get the inline help with: 
+
+	src/console/epochnogui --help
+	

TODO

@@ -0,0 +1,3 @@
+- Min/Max in renamings
+- Special handlings of boolean types in PRISM operators creators
+

config/FindGlib.cmake

@@ -0,0 +1,39 @@
+# - Try to find Glib-2.0 (with gobject)
+# Once done, this will define
+#
+#  Glib_FOUND - system has Glib
+#  Glib_INCLUDE_DIRS - the Glib include directories
+#  Glib_LIBRARIES - link these to use Glib
+
+include(LibFindMacros)
+
+# Use pkg-config to get hints about paths
+libfind_pkg_check_modules(Glib_PKGCONF glib-2.0)
+
+# Main include dir
+find_path(Glib_INCLUDE_DIR
+  NAMES glib.h
+  PATHS ${Glib_PKGCONF_INCLUDE_DIRS}
+  PATH_SUFFIXES glib-2.0
+)
+
+# Glib-related libraries also use a separate config header, which is in lib dir
+find_path(GlibConfig_INCLUDE_DIR
+  NAMES glibconfig.h
+  PATHS ${Glib_PKGCONF_INCLUDE_DIRS} /usr
+  PATH_SUFFIXES lib/glib-2.0/include
+)
+
+# Finally the library itself
+find_library(Glib_LIBRARY
+  NAMES glib-2.0
+  PATHS ${Glib_PKGCONF_LIBRARY_DIRS}
+)
+
+# Set the include dir variables and the libraries and let libfind_process do the rest.
+# NOTE: Singular variables for this library, plural for libraries this this lib depends on.
+set(Glib_PROCESS_INCLUDES Glib_INCLUDE_DIR GlibConfig_INCLUDE_DIR)
+set(Glib_PROCESS_LIBS Glib_LIBRARY)
+libfind_process(Glib)
+
+

config/FindGlibmm.cmake

@@ -0,0 +1,38 @@
+# - Try to find Glibmm-2.4
+# Once done, this will define
+#
+#  Glibmm_FOUND - system has Glibmm
+#  Glibmm_INCLUDE_DIRS - the Glibmm include directories
+#  Glibmm_LIBRARIES - link these to use Glibmm
+
+include(LibFindMacros)
+
+# Dependencies
+libfind_package(Glibmm Glib)
+libfind_package(Glibmm SigC++)
+
+# Use pkg-config to get hints about paths
+libfind_pkg_check_modules(Glibmm_PKGCONF glibmm-2.4)
+
+# Main include dir
+find_path(Glibmm_INCLUDE_DIR
+  NAMES glibmm/main.h
+  PATHS ${Glibmm_PKGCONF_INCLUDE_DIRS}
+  PATH_SUFFIXES glibmm-2.4
+)
+
+# Glib-related libraries also use a separate config header, which is in lib dir
+find_path(GlibmmConfig_INCLUDE_DIR
+  NAMES glibmmconfig.h
+  PATHS ${Glibmm_PKGCONF_INCLUDE_DIRS} /usr
+  PATH_SUFFIXES lib/glibmm-2.4/include
+)
+
+libfind_library(Glibmm glibmm 2.4)
+
+# Set the include dir variables and the libraries and let libfind_process do the rest.
+# NOTE: Singular variables for this library, plural for libraries this this lib depends on.
+set(Glibmm_PROCESS_INCLUDES Glibmm_INCLUDE_DIR GlibmmConfig_INCLUDE_DIR Glib_INCLUDE_DIRS SigC++_INCLUDE_DIRS)
+set(Glibmm_PROCESS_LIBS Glibmm_LIBRARY Glib_LIBRARIES SigC++_LIBRARIES)
+libfind_process(Glibmm)
+

config/FindLibXML++.cmake

@@ -0,0 +1,41 @@
+# - Try to find LibXML++ 2.6
+# Once done, this will define
+#
+# LibXML++_FOUND - system has LibXML++
+# LibXML++_INCLUDE_DIRS - the LibXML++ include directories
+# LibXML++_LIBRARIES - link these to use LibXML++
+
+include(LibFindMacros)
+
+# Dependencies
+libfind_package(LibXML++ LibXML2)
+libfind_package(LibXML++ Glibmm)
+
+# Use pkg-config to get hints about paths
+libfind_pkg_check_modules(LibXML++_PKGCONF libxml++-2.6)
+
+# Main include dir
+find_path(LibXML++_INCLUDE_DIR
+  NAMES libxml++/libxml++.h
+  PATHS ${LibXML++_PKGCONF_INCLUDE_DIRS}
+  PATH_SUFFIXES libxml++-2.6
+  )
+
+# Glib-related libraries also use a separate config header, which is in lib dir
+find_path(LibXML++Config_INCLUDE_DIR
+  NAMES libxml++config.h
+  PATHS ${LibXML++_PKGCONF_INCLUDE_DIRS} /usr
+  PATH_SUFFIXES lib/libxml++-2.6/include
+  )
+
+# Finally the library itself
+find_library(LibXML++_LIBRARY
+  NAMES xml++-2.6
+  PATHS ${LibXML++_PKGCONF_LIBRARY_DIRS}
+  )
+
+# Set the include dir variables and the libraries and let libfind_process do the rest.
+# NOTE: Singular variables for this library, plural for libraries this this lib depends on.
+set(LibXML++_PROCESS_INCLUDES LibXML++_INCLUDE_DIR LibXML++Config_INCLUDE_DIR LibXML2_INCLUDE_DIRS Glibmm_INCLUDE_DIRS)
+set(LibXML++_PROCESS_LIBS LibXML++_LIBRARY LibXML2_LIBRARIES Glibmm_LIBRARIES)
+libfind_process(LibXML++)

config/FindLibXML2.cmake

@@ -0,0 +1,90 @@
+# - Try to find libxml2
+# Once done this will define
+#
+#  LibXML2_FOUND - system has xml2
+#  LibXML2_INCLUDE_DIRS - the xml2 include directory
+#  LibXML2_LIBRARIES - Link these to use xml2
+#  LibXML2_DEFINITIONS - Compiler switches required for using xml2
+#
+#  Copyright (c) 2008 Andreas Schneider <mail@cynapses.org>
+#  Modified for other libraries by Lasse Kärkkäinen <tronic>
+#
+#  Redistribution and use is allowed according to the terms of the New
+#  BSD license.
+#  For details see the accompanying COPYING-CMAKE-SCRIPTS file.
+#
+
+
+if (LibXML2_LIBRARIES AND LibXML2_INCLUDE_DIRS)
+  # in cache already
+  set(LibXML2_FOUND TRUE)
+else (LibXML2_LIBRARIES AND LibXML2_INCLUDE_DIRS)
+  # use pkg-config to get the directories and then use these values
+  # in the FIND_PATH() and FIND_LIBRARY() calls
+  if (${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} EQUAL 4)
+    include(UsePkgConfig)
+    pkgconfig(libxml-2.0 _LibXML2_INCLUDEDIR _LibXML2_LIBDIR _LibXML2_LDFLAGS _LibXML2_CFLAGS)
+  else (${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} EQUAL 4)
+    find_package(PkgConfig)
+    if (PKG_CONFIG_FOUND)
+      pkg_check_modules(_LIBXML2 libxml-2.0)
+    endif (PKG_CONFIG_FOUND)
+  endif (${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} EQUAL 4)
+  find_path(LibXML2_INCLUDE_DIR
+    NAMES
+      libxml/xpath.h
+    PATHS
+      ${_LibXML2_INCLUDEDIR}
+      /usr/include
+      /usr/local/include
+      /opt/local/include
+      /sw/include
+    PATH_SUFFIXES
+      libxml2
+  )
+  
+  find_library(LibXML2_LIBRARY
+    NAMES
+      xml2
+    PATHS
+      ${_LibXML2_LIBDIR}
+      /usr/lib
+      /usr/local/lib
+      /opt/local/lib
+      /sw/lib
+  )
+
+  if (LibXML2_LIBRARY)
+    set(LibXML2_FOUND TRUE)
+  endif (LibXML2_LIBRARY)
+
+  set(LibXML2_INCLUDE_DIRS
+    ${LibXML2_INCLUDE_DIR}
+  )
+
+  if (LibXML2_FOUND)
+    set(LibXML2_LIBRARIES
+      ${LibXML2_LIBRARIES}
+      ${LibXML2_LIBRARY}
+    )
+  endif (LibXML2_FOUND)
+
+  if (LibXML2_INCLUDE_DIRS AND LibXML2_LIBRARIES)
+     set(LibXML2_FOUND TRUE)
+  endif (LibXML2_INCLUDE_DIRS AND LibXML2_LIBRARIES)
+
+  if (LibXML2_FOUND)
+    if (NOT LibXML2_FIND_QUIETLY)
+      message(STATUS "Found libxml2: ${LibXML2_LIBRARY}")
+    endif (NOT LibXML2_FIND_QUIETLY)
+  else (LibXML2_FOUND)
+    if (LibXML2_FIND_REQUIRED)
+      message(FATAL_ERROR "Could not find libxml2")
+    endif (LibXML2_FIND_REQUIRED)
+  endif (LibXML2_FOUND)
+
+  # show the LibXML2_INCLUDE_DIRS and LibXML2_LIBRARIES variables only in the advanced view
+  mark_as_advanced(LibXML2_INCLUDE_DIRS LibXML2_LIBRARIES)
+
+endif (LibXML2_LIBRARIES AND LibXML2_INCLUDE_DIRS)
+

config/FindPLplot.cmake

@@ -0,0 +1,75 @@
+# Find PLplot header and library.
+
+# This module defines the following uncached variables:
+#  PLplot_FOUND, if false, do not try to use PLplot.
+#  PLplot_INCLUDE_DIRS, where to find plplot.h.
+#  PLplot_LIBRARIES, the libraries to link against to use PLplot
+#  PLplot_LIBRARY_DIRS, the directory where the PLplot library is found.
+
+FIND_PATH(
+  PLplot_INCLUDE_DIR
+  NAMES plplot.h 
+  PATHS /usr/local/include /usr/include
+  PATH_SUFFIXES plplot
+)
+
+IF( PLplot_INCLUDE_DIR )
+  find_library( PLplot_LIBRARY
+    NAMES plplotd
+    PATHS /usr/local/lib /usr/lib
+  )
+  if(PLplot_LIBRARY)
+    set( PLplot_LIBRARY_DIR "" )
+    get_filename_component(PLplot_LIBRARY_DIRS ${PLplot_LIBRARY} PATH)
+    # Set uncached variables as per standard.
+    set(PLplot_FOUND ON)
+    set(PLplot_INCLUDE_DIRS ${PLplot_INCLUDE_DIR})
+    set(PLplot_LIBRARIES ${PLplot_LIBRARY})
+  endif(PLplot_LIBRARY)
+  
+  # find cxx bindings
+  find_library( PLplot_cxx_LIBRARY
+    NAMES plplotcxxd
+    PATHS /usr/local/lib /usr/lib
+  )
+  if( PLplot_cxx_LIBRARY )
+    set( PLplot_LIBRARIES ${PLplot_LIBRARIES} ${PLplot_cxx_LIBRARY} )
+  endif( PLplot_cxx_LIBRARY )
+  
+  # find f77 bindings
+  find_library( PLplot_f77_LIBRARY
+    NAMES plplotf77d
+    PATHS /usr/local/lib /usr/lib
+  )
+  if( PLplot_f77_LIBRARY )
+    set( PLplot_LIBRARIES ${PLplot_LIBRARIES} ${PLplot_f77_LIBRARY} )
+  endif( PLplot_f77_LIBRARY )
+
+  # find f90 bindings
+  find_library( PLplot_f90_LIBRARY
+    NAMES plplotf90d
+    PATHS /usr/local/lib /usr/lib
+  )
+  if( PLplot_f90_LIBRARY )
+    set( PLplot_LIBRARIES ${PLplot_LIBRARIES} ${PLplot_f90_LIBRARY} )
+  endif( PLplot_f90_LIBRARY )
+
+  # find wxwidgets bindings
+  find_library( PLplot_wxwidgets_LIBRARY
+    NAMES plplotwxwidgetsd
+    PATHS /usr/local/lib /usr/lib
+  )
+  if( PLplot_wxwidgets_LIBRARY )
+    set( PLplot_LIBRARIES ${PLplot_LIBRARIES} ${PLplot_wxwidgets_LIBRARY} )
+  endif( PLplot_wxwidgets_LIBRARY )
+endif(PLplot_INCLUDE_DIR)
+	    
+if(PLplot_FOUND)
+  if(NOT PLplot_FIND_QUIETLY)
+    message(STATUS "FindPLplot: Found both PLplot headers and library")
+  endif(NOT PLplot_FIND_QUIETLY)
+else(PLplot_FOUND)
+  if(PLplot_FIND_REQUIRED)
+    message(FATAL_ERROR "FindPLplot: Could not find PLplot headers or library")
+  endif(PLplot_FIND_REQUIRED)
+endif(PLplot_FOUND)

config/FindSigC++.cmake

@@ -0,0 +1,34 @@
+# - Try to find SigC++-2.0
+# Once done, this will define
+#
+#  SigC++_FOUND - system has SigC++
+#  SigC++_INCLUDE_DIRS - the SigC++ include directories
+#  SigC++_LIBRARIES - link these to use SigC++
+
+include(LibFindMacros)
+
+# Use pkg-config to get hints about paths
+libfind_pkg_check_modules(SigC++_PKGCONF sigc++-2.0)
+
+# Main include dir
+find_path(SigC++_INCLUDE_DIR
+  NAMES sigc++/sigc++.h
+  PATHS ${SigC++_PKGCONF_INCLUDE_DIRS}
+  PATH_SUFFIXES sigc++-2.0
+)
+
+# Glib-related libraries also use a separate config header, which is in lib dir
+find_path(SigC++Config_INCLUDE_DIR
+  NAMES sigc++config.h
+  PATHS ${SigC++_PKGCONF_INCLUDE_DIRS} /usr
+  PATH_SUFFIXES lib/sigc++-2.0/include
+)
+
+libfind_library(SigC++ sigc 2.0)
+
+# Set the include dir variables and the libraries and let libfind_process do the rest.
+# NOTE: Singular variables for this library, plural for libraries this this lib depends on.
+set(SigC++_PROCESS_INCLUDES SigC++_INCLUDE_DIR SigC++Config_INCLUDE_DIR)
+set(SigC++_PROCESS_LIBS SigC++_LIBRARY)
+libfind_process(SigC++)
+

config/FindUMFPACK.cmake

@@ -0,0 +1,100 @@
+SET( UMFPACK_FOUND "NO" )
+
+if (UMFPACK_INCLUDES AND UMFPACK_LIBRARIES)
+  set(UMFPACK_FIND_QUIETLY TRUE)
+endif (UMFPACK_INCLUDES AND UMFPACK_LIBRARIES)
+
+find_package(BLAS REQUIRED)
+
+if(BLAS_FOUND)
+
+  find_path(UMFPACK_INCLUDES
+    NAMES
+    umfpack.h
+    PATHS
+    $ENV{UMFPACKDIR}
+    ${INCLUDE_INSTALL_DIR}
+    PATH_SUFFIXES
+    suitesparse
+  )
+
+  find_library(UMFPACK_LIBRARIES umfpack PATHS $ENV{UMFPACKDIR} ${LIB_INSTALL_DIR})
+
+  if(UMFPACK_LIBRARIES)
+
+    get_filename_component(UMFPACK_LIBDIR ${UMFPACK_LIBRARIES} PATH)
+
+    find_library(AMD_LIBRARY amd PATHS ${UMFPACK_LIBDIR} $ENV{UMFPACKDIR} ${LIB_INSTALL_DIR})
+    if (AMD_LIBRARY)
+      set(UMFPACK_LIBRARIES ${UMFPACK_LIBRARIES} ${AMD_LIBRARY})
+    else (AMD_LIBRARY)
+      MESSAGE ( FATAL_ERROR "AMD library not found!" )
+      set(UMFPACK_LIBRARIES)
+    endif (AMD_LIBRARY)
+    
+    find_library(CHOLMOD_LIBRARY cholmod PATHS ${UMFPACK_LIBDIR} $ENV{UMFPACKDIR} ${LIB_INSTALL_DIR})
+    if (CHOLMOD_LIBRARY)
+      set(UMFPACK_LIBRARIES ${UMFPACK_LIBRARIES} ${CHOLMOD_LIBRARY})
+    else (CHOLMOD_LIBRARY)
+      MESSAGE ( FATAL_ERROR "CHOLAMD library not found!" )
+      set(UMFPACK_LIBRARIES)
+    endif (CHOLMOD_LIBRARY)
+    
+    find_library(COLAMD_LIBRARY colamd PATHS ${UMFPACK_LIBDIR} $ENV{UMFPACKDIR} ${LIB_INSTALL_DIR})
+    if (COLAMD_LIBRARY)
+      set(UMFPACK_LIBRARIES ${UMFPACK_LIBRARIES} ${COLAMD_LIBRARY})
+    else (COLAMD_LIBRARY)
+      MESSAGE ( FATAL_ERROR "COLAMD library not found!" )
+      set(UMFPACK_LIBRARIES)
+    endif (COLAMD_LIBRARY)
+    
+    find_library(CAMD_LIBRARY camd PATHS ${UMFPACK_LIBDIR} $ENV{UMFPACKDIR} ${LIB_INSTALL_DIR})
+    if (CAMD_LIBRARY)
+      set(UMFPACK_LIBRARIES ${UMFPACK_LIBRARIES} ${CAMD_LIBRARY})
+    else (CAMD_LIBRARY)
+      MESSAGE ( FATAL_ERROR "CAMD library not found!" )
+      set(UMFPACK_LIBRARIES)
+    endif (CAMD_LIBRARY)
+    
+    find_library(CCOLAMD_LIBRARY ccolamd PATHS ${UMFPACK_LIBDIR} $ENV{UMFPACKDIR} ${LIB_INSTALL_DIR})
+    if (CCOLAMD_LIBRARY)
+      set(UMFPACK_LIBRARIES ${UMFPACK_LIBRARIES} ${CCOLAMD_LIBRARY})
+    else (CCOLAMD_LIBRARY)
+      MESSAGE ( FATAL_ERROR "CCOLAMD library not found!" )
+      set(UMFPACK_LIBRARIES)
+    endif (CCOLAMD_LIBRARY)
+    
+    find_library(METIS_LIBRARY metis PATHS ${UMFPACK_LIBDIR} $ENV{UMFPACKDIR} ${LIB_INSTALL_DIR})
+    if (METIS_LIBRARY)
+      set(UMFPACK_LIBRARIES ${UMFPACK_LIBRARIES} ${METIS_LIBRARY})
+    else (METIS_LIBRARY)
+      MESSAGE ( STATUS "METIS library not found!" )
+#      set(UMFPACK_LIBRARIES)
+    endif (METIS_LIBRARY)
+
+    find_library(SPARSECONFIG_LIBRARY suitesparseconfig PATHS ${UMFPACK_LIBDIR} $ENV{UMFPACKDIR} ${LIB_INSTALL_DIR})
+    if (SPARSECONFIG_LIBRARY)
+      set(UMFPACK_LIBRARIES ${UMFPACK_LIBRARIES} ${SPARSECONFIG_LIBRARY})
+    else (SPARSECONFIG_LIBRARY)
+      message ("paths : " ${PATHS})
+      MESSAGE ( FATAL_ERROR "SPARSECONFIG library not found!" )
+      set(UMFPACK_LIBRARIES)
+    endif (SPARSECONFIG_LIBRARY)
+
+
+  endif(UMFPACK_LIBRARIES)
+
+  if(UMFPACK_LIBRARIES)
+    set(UMFPACK_LIBRARIES ${UMFPACK_LIBRARIES} ${BLAS_LIBRARIES} gfortran)
+    SET( UMFPACK_FOUND "YES" )
+  endif(UMFPACK_LIBRARIES)
+
+endif(BLAS_FOUND)
+
+
+include(FindPackageHandleStandardArgs)
+find_package_handle_standard_args(UMFPACK DEFAULT_MSG
+                                  UMFPACK_INCLUDES UMFPACK_LIBRARIES)
+
+mark_as_advanced(UMFPACK_INCLUDES UMFPACK_LIBRARIES AMD_LIBRARY COLAMD_LIBRARY)
+

config/LibFindMacros.cmake

@@ -0,0 +1,101 @@
+# Works the same as find_package, but forwards the "REQUIRED" and "QUIET" arguments
+# used for the current package. For this to work, the first parameter must be the
+# prefix of the current package, then the prefix of the new package etc, which are
+# passed to find_package.
+macro (libfind_package PREFIX)
+  set (LIBFIND_PACKAGE_ARGS ${ARGN})
+  if (${PREFIX}_FIND_QUIETLY)
+    set (LIBFIND_PACKAGE_ARGS ${LIBFIND_PACKAGE_ARGS} QUIET)
+  endif (${PREFIX}_FIND_QUIETLY)
+  if (${PREFIX}_FIND_REQUIRED)
+    set (LIBFIND_PACKAGE_ARGS ${LIBFIND_PACKAGE_ARGS} REQUIRED)
+  endif (${PREFIX}_FIND_REQUIRED)
+  find_package(${LIBFIND_PACKAGE_ARGS})
+endmacro (libfind_package)
+
+# CMake developers made the UsePkgConfig system deprecated in the same release (2.6)
+# where they added pkg_check_modules. Consequently I need to support both in my scripts
+# to avoid those deprecated warnings. Here's a helper that does just that.
+# Works identically to pkg_check_modules, except that no checks are needed prior to use.
+macro (libfind_pkg_check_modules PREFIX PKGNAME)
+  if (${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} EQUAL 4)
+    include(UsePkgConfig)
+    pkgconfig(${PKGNAME} ${PREFIX}_INCLUDE_DIRS ${PREFIX}_LIBRARY_DIRS ${PREFIX}_LDFLAGS ${PREFIX}_CFLAGS)
+  else (${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} EQUAL 4)
+    find_package(PkgConfig)
+    if (PKG_CONFIG_FOUND)
+      pkg_check_modules(${PREFIX} ${PKGNAME})
+    endif (PKG_CONFIG_FOUND)
+  endif (${CMAKE_MAJOR_VERSION} EQUAL 2 AND ${CMAKE_MINOR_VERSION} EQUAL 4)
+endmacro (libfind_pkg_check_modules)
+
+# Do the final processing once the paths have been detected.
+# If include dirs are needed, ${PREFIX}_PROCESS_INCLUDES should be set to contain
+# all the variables, each of which contain one include directory.
+# Ditto for ${PREFIX}_PROCESS_LIBS and library files.
+# Will set ${PREFIX}_FOUND, ${PREFIX}_INCLUDE_DIRS and ${PREFIX}_LIBRARIES.
+# Also handles errors in case library detection was required, etc.
+macro (libfind_process PREFIX)
+  # Skip processing if already processed during this run
+  if (NOT ${PREFIX}_FOUND)
+    # Start with the assumption that the library was found
+    set (${PREFIX}_FOUND TRUE)
+
+    # Process all includes and set _FOUND to false if any are missing
+    foreach (i ${${PREFIX}_PROCESS_INCLUDES})
+      if (${i})
+        set (${PREFIX}_INCLUDE_DIRS ${${PREFIX}_INCLUDE_DIRS} ${${i}})
+        mark_as_advanced(${i})
+      else (${i})
+        message(STATUS "Missing ${i}")
+        set (${PREFIX}_FOUND FALSE)
+      endif (${i})
+    endforeach (i)
+
+    # Process all libraries and set _FOUND to false if any are missing
+    foreach (i ${${PREFIX}_PROCESS_LIBS})
+      if (${i})
+        set (${PREFIX}_LIBRARIES ${${PREFIX}_LIBRARIES} ${${i}})
+        mark_as_advanced(${i})
+      else (${i})
+        message(STATUS "Missing ${i}")
+        set (${PREFIX}_FOUND FALSE)
+      endif (${i})
+    endforeach (i)
+
+    # Print message and/or exit on fatal error
+    if (${PREFIX}_FOUND)
+      if (NOT ${PREFIX}_FIND_QUIETLY)
+        message (STATUS "Found ${PREFIX} ${${PREFIX}_VERSION}")
+      endif (NOT ${PREFIX}_FIND_QUIETLY)
+    else (${PREFIX}_FOUND)
+      if (${PREFIX}_FIND_REQUIRED)
+        foreach (i ${${PREFIX}_PROCESS_INCLUDES} ${${PREFIX}_PROCESS_LIBS})
+          message("${i}=${${i}}")
+        endforeach (i)
+        message (FATAL_ERROR "Required library ${PREFIX} NOT FOUND.\nInstall the library (dev version) and try again. If the library is already installed, use ccmake to set the missing variables manually.")
+      endif (${PREFIX}_FIND_REQUIRED)
+    endif (${PREFIX}_FOUND)
+  endif (NOT ${PREFIX}_FOUND)
+endmacro (libfind_process)
+
+macro(libfind_library PREFIX basename)
+  set(TMP "")
+  if(MSVC80)
+    set(TMP -vc80)
+  endif(MSVC80)
+  if(MSVC90)
+    set(TMP -vc90)
+  endif(MSVC90)
+  set(${PREFIX}_LIBNAMES ${basename}${TMP})
+  if(${ARGC} GREATER 2)
+    set(${PREFIX}_LIBNAMES ${basename}${TMP}-${ARGV2})
+    string(REGEX REPLACE "\\." "_" TMP ${${PREFIX}_LIBNAMES})
+    set(${PREFIX}_LIBNAMES ${${PREFIX}_LIBNAMES} ${TMP})
+  endif(${ARGC} GREATER 2)
+  find_library(${PREFIX}_LIBRARY
+    NAMES ${${PREFIX}_LIBNAMES}
+    PATHS ${${PREFIX}_PKGCONF_LIBRARY_DIRS}
+  )
+endmacro(libfind_library)
+

doc/CMakeLists.txt

@@ -0,0 +1,20 @@
+# This file is part of EPOCH.
+# File: CMakeLists.txt
+# Author: Florent Teichteil-Königsbuch
+# Contact: florent.teichteil@onera.fr
+#
+#    EPOCH 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 3 of the License, or
+#    (at your option) any later version.
+#
+#    EPOCH 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 EPOCH.  If not, see <http://www.gnu.org/licenses/>.
+
+CONFIGURE_FILE (${CMAKE_SOURCE_DIR}/doc/Doxyfile.cmake ${CMAKE_BINARY_DIR}/doc/Doxyfile @ONLY)
+ADD_CUSTOM_TARGET (html ${DOXYGEN_EXECUTABLE} ${CMAKE_BINARY_DIR}/doc/Doxyfile)

doc/Rapport post-doc/1-introduction.tex

@@ -0,0 +1,134 @@
+\section{Toward an automated model-based approach to system validation}
+\label{sec:intro}
+
+
+The increasing complexity of interactions between functions and other equipment in modern
+industrial systems poses new technical challenges. 
+In fact, developing complex systems often raise integration problems during the product
+final testing and verification phase. Besides, correcting these issues
+often generates a heavy rework and is a well-known cause for cost
+overruns and project delays.
+
+We have to say that operation of complex systems is traditionally informally expressed in design documents as a set of modes representing functions, equipments and monitoring mechanisms, which are validated by review, i.e. exhaustive manual (opposed to automatic) consistence checks and cross-reading. 
+Human validation activities soon became practically impossible due to the high number of combinations to be checked. 
+  Therefore, finding and applying powerful computer-aided analysis techniques  that
+ contribute to anticipate and resolve integration problems as early
+ as possible in the design process has become a prior concern for  the industry. 
+ 
+
+We believe that formalizing and validating the specifications through animation/simulation and model-checking has several strong advantages
+wrt  ``traditional approaches''. On the one hand, modelling during the specification phase forces the designer to formalise and clarify the specifications. Animation/simulation is useful for validating the model against the specifications and for identifying behaviour inconsistencies based on relevant user-defined scenarios. Such inconsistencies are difficult to identify in a classical purely paper-based specification process. Last, formal verification proves that none of the possible execution scenarios violates the system properties. Such approaches are useful not only for validating an architecture or failure detection, isolation and reconfiguration strategies once defined, but also for tuning its parameters during the definition phase.
+
+It is worth noting that the approach and tools described in these pages, while embracing the automated validation of properties over model-described complex systems via model checking, also extends the existing tools to permit the analysis of temporal properties. In fact, 
+in order to have a complete vision and control over a system, it is necessary to be able to grasp transient states, and system dynamics.
+
+
+\subsection{Classical safety analysis techniques: FTA and FMEA}
+Fault Tree Analysis (FTA)~\cite{stamatelatos2002fault} and Failure Mode Effects Analysis (FMEA)~\cite{FMEA} are well-known and widely used system analysis techniques used in reliability
+engineering. Both are long established -- FMEA was formally introduced in the late 1940s, and FTA has been around since the
+1960s -- and both have been employed in a number of different areas, including the aerospace, nuclear power, and automotive industries. 
+They are methods that we can use to identify potential faults in a system, so that we can then use that information to correct or prevent those faults.
+
+Fault Tree Analysis is equally applicable to quantitative and qualitative analyses, and easy to
+use and understand. Fault trees themselves are graphical representations of logical combinations of failures, and show the
+relationship between a failure or fault and the events that cause them: they normally consist of a top event, which is
+typically a system failure, connected to one or more basic events via a system of logical gates, such as AND and OR. Basic
+events are usually either component failures or events expected to happen as part of the normal operation of the system.
+Analysis of the fault tree consists of two parts: qualitative (logical) analysis, and quantitative (probabilistic) analysis. 
+Qualitative analysis is performed by reducing the logical expression represented by the fault tree into a set of minimal cut sets,
+which are the smallest possible combinations of failures required to cause the top event. Quantitative analysis is performed
+by calculating the probability of the top event given the probability of each of the basic events occurring.
+
+In an FMEA, the basic process consists of compiling lists of possible component failure modes (all the ways in which an
+entity may fail), gathered from descriptions of each part of the system, and then trying to infer the effects of those failures
+on the rest of the system. Usually, these effects are evaluated according to a number of criteria, such as severity, probability,
+and detectability, and often these criteria are then combined into an overall estimate of risk. All of this data is then presented
+in the form of a table which allows the analyst see what the effects of each failure mode are.
+
+Even if useful, the usage of those manual techniques is hindered by the increasing complexity of systems: it is becoming more and more difficult to 
+incorporate  FTA or FMEA in the design cycle of systems that are more than relatively simple and manageable.
+In complex systems, however, manual analysis is laborious and error prone, and a thorough assessment and interpretation of the results becomes increasingly
+difficult to achieve within the constraints of most projects. Furthermore, the results of the analyses are separated from the
+design being analysed, meaning that the effects of any changes in the system design may only become apparent after another
+long and costly analysis~\cite{papadopoulos2011HH}.
+
+Complex systems yield a need for specific supporting measures and tools to
+assist in the application of analysis techniques. One obvious approach would be to automate at least part of the process. This
+would mean that the analyses could be carried out more quickly and efficiently, leaving more time for the results to be studied and allowing more useful conclusions to be drawn.
+
+\subsection{Modern safety analysis techniques: MBSE and MBSA}
+
+
+New modelling techniques, such as MBSE or MBSA, propose to master the
+combinatorial complexity at early concept phases by using abstract
+high level representations of a system~\cite{Stamatis}. These views constitute a
+promising ground to implement early validation techniques of the
+architectures. But, in order to be profitable and implemented by the
+industry, those validation techniques must remain lightweight and well
+integrated in the system design process. That is to say, the modelling
+workload must be limited, and the analysis results (even preliminary)
+must be available at the same time as designers evaluate the
+possible architecture choices. These requirements have driven our research and the toolchain described in those pages.
+
+As written above, modern safety analysis techniques permit a wealth of information about the safety and reliability of a
+system to be gathered much more quickly and easily than ever before. This information gives to the designers the means to use safety and
+reliability as a major factor in the decisions they make during the evolution of a system design: by evaluating the effects of
+one or more potential design choices, e.g. increased reliability at the expense of greater cost or increased weight, etc., designers are able to make informed choices.
+However, just as classical manual safety analyses restrict the rate that information can be obtained about a system, manually evaluating different design choices is time-consuming and restricts the number of design candidates that can be investigated. If this process could be automated, it would be possible to examine hundreds or thousands of potential design
+candidates -- a much greater portion of the total design space -- and thus hopefully provide a better foundation for the next
+iteration of the system design.
+
+
+ 
+ 
+\section{Automated Evaluation of Safety Temporal Conditions}
+In this report, we describe an approach that allows us to extend models
+developed for safety analysis in order to reason about the correctness
+of temporal conditions. 
+We intend to offer the capability to study a
+new range of system requirements that can be of main interest for
+functions such as failure detection, isolation and recovery.  We
+advocate that timing properties are critical when assessing the safety
+of embedded and real-time systems. Indeed, temporal aspects---like
+network delays or computation times---can be the cause of missed
+failure detections or undesired reactions to (delayed) failure
+propagation. It is therefore necessary to be able to analyse the
+temporal properties of a model in order to build systems that will
+operate as intended in a real-world environment.
+
+
+
+We define a model-based process to check simultaneously safety and temporal
+conditions on systems. Our approach is based on an extension of the
+AltaRica language~\cite{arn00} where timing constraints can be
+associated with events. This extension can then be translated into the
+intermediate language Fiacre~\cite{berthomieu2008fiacre}, a formal
+specification language that can be used to represent both the
+behavioural and timing aspects of systems. This Fiacre model can be
+analysed with the realtime model-checker Tina~\cite{BRV04}. The
+results of model-checking shed light on the dysfunctional behaviour of
+the original model, including how the cascading effects due to failure
+propagation delay reveal transitory failure modes~\cite{albore2017IMBSA}.
+The approach scales up on models of industrial scale, like in the validation
+of formation flying satellite systems where complex equipment and instruments are distributed over several spacecrafts~\cite{albore2018ERTS}.
+  
+The translation developed takes the functional part of the system model and the dysfunctional viewpoint modelled by  safety engineers to generate an AltaRica model of the system. The generated AltaRica model is formal and allows, one from another, the dysfunctional simulation of the system and the generation of sequences of events leading to accidents.\\
+
+
+
+%%%%
+
+This report is organised as follows. We start by giving a wider vision about the subject
+by revising the state of the art~\ref{soa}. We then define the AltaRica and the Fiacre
+language and the time model in Chap.~\ref{altarica}, providing examples of the encoding of  AltaRica in Fiacre,
+and giving some experimental results about time failure propagation
+in Sect.~\ref{sec:sect4}.
+In Chap.~\ref{aocs} we apply the described approach to an industrial case of (automated) verification
+on AOCS modes in satellites, and discuss scalability issues and empirical results.
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "main"
+%%% End:
+
+%%  LocalWords:  Fiacre

doc/Rapport post-doc/2-motivation.tex

@@ -0,0 +1,400 @@
+\section{Example of a Failure Detection and Isolation System}
+\label{sec:example-fail-detect-1}
+
+We study the example of a safety critical function that illustrates
+standard failure propagation problems. We use this example to show the
+adverse effects of temporal failure propagation even in the presence
+of % system safety improvements. In our case the addition of
+Failure Detection and Isolation (FDI) safety capabilities.
+
+This example is inspired by the avionic functions that provide
+parameters for Primary Flight Display (PFD), which is located in the
+aircraft cockpit. The system of interest is the computer that acquires
+sensors measurements and computes the aircraft \emph{calibrated airspeed
+ } (CAS)  parameter. Airspeed is crucial for pilots: it is taken into
+account to adjust aircraft engines thrust and it plays a main role in
+the prevention of over speed and stall.
+
+%%
+\begin{figure}[tb]
+  \centering
+\includegraphics[width=0.99\textwidth]{figures/AirSpeed_Computation.jpg}
+  \caption{Functional and physical views of the airspeed computation function.\label{fig:cockpit}}
+\end{figure}
+%%
+
+CAS is not directly measured by a dedicated sensor, but is computed as
+a function of two auxiliary pressure measurements, the static pressure
+(Ps) and total pressure (Pt); that is
+$\mathrm{CAS} = f(\mathrm{Pt}, \mathrm{Ps})$.
+% \begin{equation*}
+% CAS = C_{SO}\sqrt{5 \cdot \left( \left(\frac{Pt - Ps}{P_0} + 1\right)^{2/7} - 1\right)}
+%   \end{equation*}
+%   with $C_{SO}$ and $P_0$ two
+%   constants. % the speed of sound under standard day sea level conditions
+These two measurements come from sensors located on the aircraft nose,
+a pressure probe and a pitot tube.
+% Our proposed functional view shows:
+% \begin{itemize}
+% \item 	Two external functions \I{1} and \I{2} that measure static and total pressure. They represent the functions allocated to the sensors.
+% \item	Three inner functions of the system: \F{1} and \F{2} for sensor measurements acquisition by the onboard computer and \F{3} for airspeed computation.
+% \item	The PFD functions have not been modelled in the sole purpose of simplification.
+% \end{itemize}
+%
+%%
+
+Our proposed functional view is given in Fig.~\ref{fig:cockpit}. It
+consists in two external functions \I{1} and \I{2} that measure static
+and total pressure; and three inner functions of the system, \F{1} and
+\F{2} for sensor measurements acquisition by the onboard computer and
+\F{3} for airspeed computation. For simplification purposes, the
+PFD functions have not been modelled.
+
+Next, we propose a first failure propagation view aiming at
+identifying the scenarios leading to an erroneous airspeed computation
+and display to the pilot (denoted \ERR).  Such failure can only be
+detected if a failure detector is implemented, for instance by
+comparing the outputs of different functions. Undetected, it could
+mislead the pilot and, consequently, lead to an inappropriate engine
+thrust setting.  We also want to identify the scenarios leading to
+% (clearly) erroneous transmitted values, for instance a variable out of bounds or
+the loss of the measure (denoted \LOSS). In such a case, the pilot can
+easily assess that the measure is missing or false and consequently
+rely upon another measure to control the aircraft (note that such
+redundancy is not modelled). For example, airspeed out of
+bound---indicating that an airliner has crossed the sonic barrier---is
+considered to be of kind \LOSS. It can be unserstood that scenarios leading to the
+loss of the airspeed are less critical than the ones leading erroneous
+values.
+
+% We consider two possible kinds of fail status: the ``silent'' failure of
+%an element (denoted \ERR); or a communication problem with one of the
+% functions (denoted \LOSS). 
+
+% A failure is typically a loss of connectivity or the
+% detection of (clearly) erroneous transmitted values, for instance a
+% variable out of bounds. A \LOSS fail is less critical than an \ERR
+% since it can be detected immediately and isolated. On the other hand,
+% an \ERR fail can only be detected if a failure detector is
+% implemented, for instance by comparing the outputs of different
+% functions. In the remainder of this paper, we consider that the status
+% are ordered by their level of severity, that is \ERR $<$ \LOSS $<$\OK. 
+
+
+\subsubsection*{Safety model of the architecture without FDI.}
+%%\label{sec:error-prop-simple}
+%For the sake of brevity, we choose to study a simplified version of
+%FDI system. While simple, this system is representative of failure
+%propagation mechanisms found in actual onboard systems. To simplify
+%the presentation, we start by describing the system without any
+%safety-related elements, see Fig.~\ref{fig:example0}.
+%%
+%
+We provide an AltaRica model corresponding to the functional structure
+of the CAS function in Fig.~\ref{fig:example0}. This model, tailored
+to study failure propagation, is comprised of:
+% ( All the functions are modelled according to the node function
+% introduced in the Sect.~\ref{sec:sect2}.
+%
+two external functions, \I{1} and \I{2}, that have no input (so, in
+their nominal state, the output is set to \OK); two inner functions,
+\F{1} and \F{2}, which are instances of the node \FUNC described in
+Sect.~\ref{sec:sect2}; and a function, \F{3}, that is the composition
+of two basic elements: a multiplexer, \MIN, representing the
+dependence of the output of \F{3} from its two inputs; and a computing
+element \F{3Processing} that represents the computation of the
+airspeed. \F{3Processing} is also an instance of node \FUNC.
+
+\begin{figure}[t]
+  \centering
+  \begin{tikzpicture}
+  \node[anchor=south west,inner sep=0] at (0,0)   { \includegraphics[width=0.7\textwidth]{figures/Modele0}};
+  \draw[red!50,ultra thick, dashed] (6.7,2.6) rectangle (2.6,0.5);
+  \node[red] at (6.3,2.3) {\texttt{\large F3}};
+\end{tikzpicture}
+  \caption{A simple example of failure  propagation.\label{fig:example0}}
+\end{figure}
+%
+In case of single failure scenario, \MIN propagates the failure coming
+either from one input or the other. In case of multiple failures, when
+both inputs have identical failure, this one propagates. For instance,
+both inputs to \LOSS lead to an output of \LOSS.
+% But when it receives an erroneous fail then the multiplexer will
+% propagate an \ERR.  The remaining failure combination drew our
+% attention during \F{3} modelling.
+On the other hand, when different failures propagate, one being \LOSS
+and the other being \ERR,---and without appropriate FDI---the system
+outcome is uncertain.
+%
+Solving this uncertainty would require a detailed behavioural model of
+the onboard computer and a model for all the possible failure modes,
+which is rarely feasible with a sufficient level of confidence, except
+for time-tested technology.  Given this uncertainty, it is usual to
+retain the state with the most critical effect, that is to say:
+% in this case, \MIN can be thought of as a simple logic operator that
+% computes the minimum of its two inputs, and
+the output of \F{3} is \ERR.
+
+
+% Since a \LOSS can be ``easily'' detected, we want to avoid a situation
+% where the whole system propagates \ERR while one of its
+%internal element propagates a \LOSS. The rationale is that we should be
+% able to isolate (or quarantine) the system when we know for sure that
+% one of its element does not reliably respond to commands. This can be
+% expressed by the following safety property.
+%%
+
+% In the next section, we study the system with the addition of FDI
+% capabilities.
+
+Our goal is to prevent the computation of an erroneous airspeed while
+one of \F{3} input signals is lost.  The rationale is that the system
+should be able to passivate automatically the airspeed when it detects
+that one of its input signals is not reliable. This behavior can be
+expressed with the following property.
+
+
+%The goal of the safety engineer is to avoid a situation where \F{3}
+%propagates an erroneous value while one of its input propagates a
+%\LOSS. The rationale is that we should be able to isolate (or
+% quarantine) the function when we can detect that one of its element is
+% not reliable. This can be expressed by the following safety property.
+%%
+\begin{prop}[Loss Detection and Instantaneous Propagation]\label{prop:1}
+  A function is \emph{loss detection safe} if, when in nominal mode, it
+  propagates a \LOSS whenever one of its input nodes propagates a
+  \LOSS.
+\end{prop}
+
+% This is a simple system used to detect non-nominal behaviours
+% and to trigger observables in order to isolate the failure mode.
+% ({The figures are actual screen capture of models edited with Cecilia
+%   OCAS.})
+% \subsubsection{Analysis}
+
+
+We can show that our example of Fig.~\ref{fig:example0} does not meet
+this property using the \emph{Sequence Generation} tool available in
+Cecilia OCAS.
+%%
+% This system has several sources of unreliability. Both its sources and
+% the computing elements (\F{1}, \F{2} and \F{3Processing}) can
+% experience spontaneous failures, meaning that their outputs can
+% transition instantaneously to \LOSS or \ERR. Errors are irrecoverable;
+% once a function becomes faulty, its output will always stay equal to
+% \LOSS or \ERR.  Likewise, if both inputs are ``nominal'' then the
+% output of \MIN is \OK. We assume that the multiplexer cannot undergo
+% spontaneous failures.
+%%
+% This can be tested using a perfect detectors, \FF{3}{Loss}, placed at
+% the output of the system. 
+%%
+To this end, we compute the minimal cuts for the target equation
+$((\text{\F{1.O.Loss}} \vee \text{\F{2.O.Loss}}) \wedge \neg
+\text{\F{3.O.Loss}})$, meaning the scenario where \F{3} does not
+propagates \LOSS when one of \F{1} or \F{2} does. Hence function \F{3}
+is {loss detection safe} if and only if the set is empty.
+% \footnote{To check the safety of \F{3}, we need to perform the same
+% analysis for all the elements that can propagate a loss fail, not
+% only \F{1}.}.
+
+In our example, once we eliminate the cases where \F{3} is not nominal
+(that is when \F{3Processing} is in an error state), we find eight
+minimal cuts, all of order $2$. In the following section, we correct
+the behaviour of \F{3} by considering a new architecture based on
+detectors and a switch to isolate the output of \F{3} when faulty.
+
+%%
+% {%\centering
+%   \begin{small}
+% \begin{tabular}{c@{\quad\quad}c}
+%     \begin{minipage}[t]{0.42\linewidth}
+% \begin{verbatim}
+% {'F1.fail_err', 'F2.fail_loss'}
+% {'F1.fail_err', 'I2.fail_loss'}
+% {'F1.fail_loss', 'F2.fail_err'}
+% {'F1.fail_loss', 'I2.fail_err'}
+% \end{verbatim}
+%     \end{minipage}
+%     &
+%     \begin{minipage}[t]{0.42\linewidth}
+% \begin{verbatim}
+% {'F2.fail_err', 'I1.fail_loss'}
+% {'F2.fail_loss', 'I1.fail_err'}
+% {'I1.fail_err', 'I2.fail_loss'}
+% {'I1.fail_loss', 'I2.fail_err'}
+% \end{verbatim}
+%     \end{minipage}\\
+%   \end{tabular}\\
+%     \end{small}
+% }
+%%
+% Each of these cuts lead to trivial violations of our safety
+% property. For instance, we obtain the cut \code{\{'F1.fail\_err',
+%   'F2.fail\_loss'\}} that corresponds to the case where \F{1}
+% propagates \ERR and \F{2} propagates \LOSS, in which case \F{3}
+% propagates \ERR. This is exactly the situation that we want to
+% avoid. 
+
+
+\begin{figure}[bt]
+  \centering
+  \begin{tikzpicture}
+  \node[anchor=south west,inner sep=0] at (0,0)   { \includegraphics[width=\textwidth]{figures/Modele2.png}};
+  \draw[red!50,ultra thick, dashed] (10.8,3.4) rectangle (2,0);
+  \node[red] at (10.4,3.1) {\texttt{\large F3}};
+\end{tikzpicture}
+  \caption{Model of a FDI function with a switch and an  alarm.\label{fig:example1}}
+\end{figure}%\vspace*{-1cm}
+
+%\enlargethispage{\baselineskip}
+
+\subsubsection*{Safety model of the architecture with FDI.}
+%%\label{sec:simple-fail-detect}
+%%
+%In order to satisfy the Prop.~\ref{prop:1},
+We update our implementation of \F{3} (see Fig.~\ref{fig:example1})
+using two perfect detectors, \F{1Loss} and \F{2Loss}, that can detect
+a loss fail on the inputs of the function. The (Boolean) outputs of
+these detectors are linked to an OR gate ({\ttfamily AtLeastOneLoss})
+which triggers an \ALARM when at least one of the detectors outputs
+true. The alarm commands a \SWITCH; the output of \SWITCH is the same
+as \MIN, unless \ALARM is activated, in which case it propagates a
+\LOSS fail status. The alarm can fail in two modes, either
+continuously triggering the switch or never being activated. The
+schema also includes two delays operators, \D{1} and \D{2}, that can
+be used to model delay propagations at the input of the detectors. We
+will come back to these timing constraints at the end of this section.
+
+% \TODO{why do we need Alarm ! why does the alarm can fail ! we could
+%   plug directly the or gate to the switch}- Permanent failure of the alarm.
+
+The FDI function---with a switch and an alarm---is a stable scheme for
+failure propagation: when in nominal mode, it detects all the failures
+of the system and it is able to disambiguate the case where its inputs
+contains both \ERR and \LOSS. Once again, this can be confirmed using
+the Sequence Generation tool. If we repeat the same analysis than
+before---and if we abstract away the delays nodes---we find $56$
+minimal cuts, all involving a failure of either \ALARM or
+\F{3Processing}. This means that, in an untimed model, our new
+implementation of \F{3} satisifies the loss detection property, as
+desired.
+% \begin{figure}[hbt]
+%   \centering
+% \begin{tikzpicture}
+%   \node[anchor=south west,inner sep=0] at (0,0)   { \includegraphics[width=\textwidth]{figures/Modele2.png}};
+%   \draw[red,ultra thick, dashed] (10.6,3.6) rectangle (2.2,0);
+%   \node[red] at (10,3) {\texttt{\huge F3}};
+% \end{tikzpicture}
+% %  \includegraphics[width=0.95\textwidth]{figures/Modele2}
+%   \caption{Taking into consideration propagation delays in the FDI
+%     system.\label{fig:example2}}
+% \end{figure}
+% Unfortunately, this model makes unrealistic assumptions about the
+% instantaneous failure propagation of detection. Indeed, it may be the
+% case that the outputs of \F{1} and \F{2} are delayed as they are
+% propagated to the observers \F{1Loss} and \F{2Loss}.  Next, we study
+% new failure modes that may arise from this situation and how we can
+% detect them.
+%%
+% \subsection{Timed Safety model of the architecture with FDI}
+% \label{sec:timed-safety-model}
+%%
+% In this section, we consider a new AltaRica model that takes into
+% account propagation delays. To this end, we may insert two instances
+% of the delay node (the element \PRE defined in Sect.~\ref{sec:sect2})
+% before the detectors \F{1Loss} and \F{2Loss}.
+Even so, it is easy to find a timed scenario where the safety property
+is violated. 
+
+Assume now that \F{1} and \F{2} propagate respectively the status \LOSS and \ERR,
+ at the same date. In such a case, the output of \F{1}
+might reach \F{1Loss} at successive date of the output of \F{2}
+reaching \F{2Loss}, while \ERR reaches \MIN instantaneously. This
+leads to a transient state where the alarm is not activated whereas
+the output of \MIN is set to \ERR. This brings us back to the same
+dreaded scenario than in our initial model.  
+%%
+% In particular, this scenario corresponds to the cut
+% \code{\{'F1.fail\_loss', 'F2.fail\_err'\}}, that is not admissible in
+% an untimed semantics. 
+%%
+
+This example suggests that we need a more powerful method to compute
+the set of cuts in the presence of temporal constraints. On the other
+hand, we may also advocate that our safety property is too strong in
+this context, where perfect synchronicity of events is rare. Actually,
+we can prove that the output of \F{3} will eventually converge to a
+loss detection and isolation (assuming that \F{3} stays nominal and
+that its inputs stay stable). Therefore, if we can bound the latency
+needed to detect the loss failure, and if this bound is sufficiently
+small safety-wise, we could still deem our system as safe. To reflect
+this situation, we propose an improved safety property that takes into
+account temporal conditions.
+%%
+\begin{prop}[Loss Detection Convergent]\label{prop:2} A function is
+  \emph{loss detection convergent} if (when in nominal mode) there
+  exists a duration $\Delta$ such that it continuously outputs a \LOSS
+  after the date $\delta_0 + \Delta$ if at least one of its input
+  nodes continuously propagates a \LOSS starting from $\delta_0$
+  onward. The smallest possible value for $\Delta$ is called the
+  \emph{convergence latency} of the function.
+\end{prop}
+
+
+
+In the next section, we use our approach to generate a list ``timed
+cuts'' (as model-checking counterexamples) that would have exposed the
+problems that we just described. We also use model-checking to compute
+the {convergence latency} for the node \F{3}. In this simple example,
+we can show that the latency is equal to the maximal propagation delay
+at the input of the detectors. The value of the latency could be much
+harder to compute in a more sophisticated scenario, where delays can
+be chained and/or depends on the internal state of a component.
+
+% The failure to detect a lost element in the system strongly affects
+% the safety assessment process, and motivates our approach to take
+% directly into account temporal constraints when analysing AltaRica
+% models. Unfortunately, while it is possible to define some timing
+% constraints on AltaRica synchronizations using ``Dirac events'', this
+% information is not taken into account during analysis. In particular,
+% we cannot use the Sequence Generation tool to find the ``timed''
+% minimal cuts that would expose the problems that we just described. In
+% the next section, we propose a way to check our timed extension of
+% AltaRica using a translation into the Fiacre specification
+% language. After translation into this new format, the model can be
+% used by a realtime model-checker Tina.
+
+% \TODO{Limitations of OCAS are described above as well: to integrate the two parts}
+% \TODO{talk about Dirac(2) in AltaRica as a way to do some crude
+%   temporal constraints. It works in simulation mode in Cecilia OCAS but
+%   no tooling !? actually I am not sure.}
+
+% \subsubsection{Dialects of AltaRica}
+% AltaRica is a high level modelling language dedicated to Safety Analysis.
+% The semantics of AltaRica is formally defined in terms of Guarded Transitions Systems, and the state of the system is described by means of variables~\cite{poi99}. The system changes of state are dictate by events, i.e. the transitions between states happen only when an event occurs as it is the only mechanism updates the value of variables.
+
+% Few versions of AltaRica exist; we consider here AltaRica 2.0 Dataflow, a version where variables are updated by propagating values in a fixed order, and this order is determined at compilation time.
+
+% The model we realised used CECILIA as a tool, then brought to a more
+% standard AltaRica 2.0 version (the one of Epoch).
+
+% \subsection{Cecilia OCAS graphical interactive simulator}
+% %% Pris de l'article de Christel
+% The system architecture we modelled can be realised using Cecilia OCAS graphical interactive simulator, which has the capacity of exporting AltaRica code, in a dialect that can easily be translated in AltaRica DataFlow.
+
+% Each  system  component  is  modelled  by  an  AltaRica  node  
+% that  can  be  regarded  as  a  mode  automaton~\cite{rauzy02}.  In  Cecilia  
+% OCAS, each node is associated to an icon and belongs to a library. 
+% Components are dragged and dropped from the library to the system 
+% architecture  sheet  and  then  linked  graphically.
+
+% As failures are events in the AltaRica model, the safety engineer can use the graphical capacities of the tool to communicate more easily the model characteristics to other project members, as graphical representations are possibly the easiest way to communicate models, not only for the safety engineers.
+% This tool permits to  inject  in  the  model  a  number  of  failure  events  in  order  to  observe  whether a failure condition is reached (such as loss of one or several elements).
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "main"
+%%% End:
+
+%%  LocalWords:  PFD OCAS CAS Ps Fiacre

doc/Rapport post-doc/2-sota.tex

@@ -0,0 +1,173 @@
+% State of the Art
+
+\section{Modelling languages for Safety Analysis}
+% modelling languages
+
+
+In AltaRica, a system is expressed in terms of variables constrained
+by formulas and transitions. Several versions of the language have
+been defined (see for instance~\cite{arn00,prosvirnova2013altarica}). 
+Underlying mathematical model......
+
+AltaRica will be described more deeply in Sec.~\ref{sec:altarica}.
+% Tempora lproperties for safety
+
+OpenAltarica~\citep{prosvirnova2013altarica} relies on propagation based variable update, but the order in which this propagation
+takes place in determined at execution time. Technically, a fixpoint is computed. This new update
+scheme does not increase much computation times but extends significantly the expressiveness of the
+language. It makes it possible to handle looped systems, i.e. systems in which variables depend of each
+other in a circular way. Another new feature of AltaRica 3.0 is the notion of guarded synchronization
+that both increases the expressiveness and unifies transitions and synchronizations
+
+
+Several model-based approaches have been proposed, each with their associated tooling, in order to cope with the complexity of analyzing sophisticated safety architectures and scenarios. However, rare are the languages that come equipped with tools that can perform formal analysis of timed models.
+
+Figaro language~\citep{bouissou05} is an alternative language for failure propagation model which introduces time via stochastic events, while we express temporal constraints on the triggering of events. Figaro models can be analyzed with stochastic simulators which are relevant to assess performance of the system (e.g. an estimation of the false detection rate). As far as we know, there is no translation from Figaro to timed model checking tools in order to verify whether a software logic satisfies applicable deterministic timed requirements. 
+Several works have combined model-checking and AltaRica. The archetypal example is the MEC tool~\citep{mec5} that was developed at the same time as the language. More recently, Bozzano et al.~\citep{bozzano2012} have defined a transformation from AltaRica Dataflow to the symbolic model-checker NuSMV. While this tool does not support complex timing constraints, it offers some support for Dirac laws (and implicit priorities) by encoding an ad-hoc scheduler.
+
+COMPASS uses the SLIM language, a subset of AADL, for modelling safety architectures. It can automatically generate fault trees, which can be evaluated to determine the probabilities of failures. The FDIR design process and analysis relies, for describing temporal events on fault propagation, on the so-called TFPM (Timed Failure Propagation Models)~\citep{bittner2014}. 
+
+AADL (Architecture Analysis and Design Language) is a multi-concerns modelling language dedicated to distributed real-time embedded systems~\cite{aadl}.
+AADL has been enriched with several annexes to describe embedded system behvior; for instance, the Error Model V2 (EMV2) is an error annex that focuses on Safety analyses. 
+EMV2 offers a terminology and an ontology to capture key features of failure propagations, like permanent and transient errors events. EM2V supports AADL to PRISM export into a PRISM model, in order to process model-checking method using the Markov-Chain formalism~\cite{PRISM}; i.e. probabilistic model analysys. The PRISM input language is a simple, state-based language. We discuss furter the PRISM model-checker in sec.~\ref{modelsota}.
+
+UPPAAL is a non-deterministic guarded command language with data types description language. It serves as a modeling or  design language to describe system behavior as networks of
+timed automata extended with data variables. A simulator and a model-checker are designed for interactive and automated analysis of system behavior by manipulating and solving constraints that represent the state-space of a system description.
+Validating a FDIR approach in satellite architecture has been done in project AGATA~\citep{rugina09} by coupling simulation with model-checking, focusing significant part of the system and abstracted away the rest of it using UPPAAL~\cite{uppaal1997}.
+
+\section{Safety Assessment on Temporal Properties}
+
+% Who does that
+
+
+Our approach provides a solution to
+model safety timing constraints within AltaRica, also providing an
+automatic transformation from Time AltaRica models in one of the
+input formats of Tina, showing how two interesting
+problems---computing ``timed cuts'' and bounding the convergence
+latency of a node---can be reduced to a decidable model-checking
+problem. %% TODO: Complete with FDIR results, and underline the needs filled.
+
+Several works have combined model-checking and AltaRica, the
+archetypal example being the MEC tool~\cite{mec5,griffault2004mec} that was
+developed at the same time as the language. More recently, Bozzano
+et al~\cite{bozzano2012} have defined a transformation from AltaRica
+Dataflow to the symbolic model-checker NuSMV. While this tool does not
+support complex timing constraints, it offers some support for Dirac
+laws (and implicit priorities) by encoding an ad-hoc scheduler. The
+use of symbolic model-checking techniques is interesting in the case
+of models with a strong combinatorial blow up, like for instance model
+HYDRAU of Sect.~\ref{sec:sect4}. Nonetheless, even though Tina also
+includes BDD-based tools, no approaches allow to combine the advantages
+of both realtime and symbolic model-checking techniques.
+
+
+Other model-based approaches aim at assessing the dependability of safety-critical dynamic systems.
+HiP-HOPS~\cite{papadopoulos2011engineering} is a tool for safety analysis that can generate automatically fault-trees and FMEA tables from extended system models, as well as perform quantitative analysis on fault trees and multi-objective optimisation of the system model.
+
+In Pandora~\cite{walker2009pandora}, Temporal Fault Trees allow to model dynamic behaviours with temporal gates, while temporal laws are used for qualitative analysis. 
+This approach specifies directly the dynamic failure behaviour of components through a formalism for dynamic dependability, on the other side, using a model-based approach (e.g. modelling with AltaRica), the failure propagation mechanism is directly inferred by the analysis tool from the undelying model.
+
+
+
+Realtime techniques are central to our approach. As we will see in Sect.\ref{sec:sect2}, we define an
+extension of AltaRica, Time AltaRica, where timing constraints can be declared using {temporal laws} of the form \code{law (evt) = "[a,b]"}, with a
+semantics inspired by Time Petri nets. As a result, we can apply on
+Time AltaRica several state space abstractions techniques that have been
+developed for ``timed models'', such as the use of DBM and state
+classes~\cite{BRV04}. In a different way, Cassez et
+al.~\cite{pagetti2004} have proposed an extension of AltaRica with
+explicit ``clock variables'', inspired by Timed Automata, where clocks
+are real-valued flow variables that can be used inside the guards of
+events.
+%%
+% (Which means that there are restrictions on the type of equations
+% one can use in the \code{assert} declaration of a node.)
+%%
+% They also define an algorithm to compile this extension into
+% Uppaal~\cite{larsen1997uppaal}. 
+Their work is mainly focused on the verification of behavioural
+properties and focuses on the encoding of urgency and priorities
+between events, two notions that are naturally offered in
+Fiacre. Also, our extension is less invasive. If we ignore the
+\code{extern} declaration then we obtain valid AltaRica code. More
+research is still needed to further the comparison between these two
+approaches in the context of safety assessments.
+
+Aside from these works on AltaRica,  recent works
+centred on combining failure propagation analysis and timing constraints, 
+define an automatic method for
+synthesising \emph{Timed Failure Propagation Graphs} (TFPG), that is
+an extension of the notion of cut-sets including information on the
+date of events~\cite{bittner2016}. TFPG provide a condensed representation that is easier
+to use than sets of timed cuts. Therefore, it would be interesting to
+use this format in our case.
+
+
+\section{Model-checking approach to safety assessment}
+\label{modelsota}
+Several model-checkers have been used in industrial or academic
+projects to perform safety analysis. Besides Tina from LAAS, that we discuss further in Sect.~\ref{sec:tina},
+UPPAAL, MEC, ARC, PRISM, and  NuSMV  are the model-checkers more widely used in this domain.
+
+UPPAAL~\cite{uppaal1997} provides a model-checker. It is designed to check for invariant
+and reachability properties. Other properties, such as bounded liveness
+properties, can be checked by reasoning about the system
+in the context of testing automata or simply decorating
+the system description with debugging information and
+then checking reachability properties. Model-checking is
+performed by a module which takes as input
+a network of automata in the textual UPPAAL format 
+and a formula. 
+
+Mec 5~\cite{mec5} is a model-checker for finite AltaRica models. 
+Properties are verified by testing that the set of states which violate the property is
+empty. These properties are expressed in a specification language that allows the definition
+of complex relations between different models, e.g. bisimulation.
+
+The AltaRica Checker  (ARC)\cite{arc} is a toolbox for the AltaRica language. ARC is aimed at model-checking  systems described with AltaRica.
+It also gathers several tools for the analysis or compilation of AltaRica models, like the support for Mec 5 specifications, translators for the LUSTRE language~\cite{Griffault06},
+and a simulator for models decorated with stochastic informations. 
+
+PRISM~\cite{PRISM} is a probabilistic model checker used for formal modelling and analysis of systems that exhibit random or probabilistic behaviour. 
+ It  incorporates symbolic data structures and algorithms, based on BDDs (Binary Decision Diagrams) and MTBDDs (Multi-Terminal Binary Decision Diagrams)~\cite{KNP04b}. It also includes a discrete-event simulation engine, providing support for approximate/statistical model checking, and implementations of various different analysis techniques, such as quantitative abstraction refinement and symmetry reduction. 
+ a model-checking tool for processing Markov-Chain. It supports different models such as Discrete Time Markov-Chain (DTMC) or Continuous Time Markov-Chain (CTMC).
+ It has been used to analyse systems from many different application domains. 
+ 
+NuSMV~\cite{nusmv} (New Symbolic Model Verifier) is a symbolic model checker, supporting verification techniques such as BDD-based and SAT-based  techniques. It allows to check finite state systems against specifications in the temporal logic  for CTL and LTL. The input language of NuSMV is designed to allow the description of finite state systems that range from completely synchronous to completely asynchronous. The NuSMV language (like the language of SMV) provides for modular hierarchical descriptions and for the definition of reusable components. 
+ 
+ Besides, translators between these languages exist, in certain cases.
+Even if generally the translation concerns subsets of the languages expressivity, it makes possible testing 
+tools and compare modelling techniques. Notable examples, are the AADL EMV2 to AltaRica translation~\cite{brunel2017performing}, or the pioneer work from 
+an AADL subset (System-Level Integrated Modelling (SLIM) language) to NuSMV, aimed at achieving formal analysis via model-checking in the framework of the COMPASS project~\cite{bozzano2010safety}.
+ 
+ 
+\subsection{Tina model-checker}\label{sec:tina}
+Tina (TIme Petri Net Analyzer, \url{http://www.laas.fr/tina}) is a
+software environment to edit and analyze Petri Nets and Time
+Petri Nets~\cite{BRV04}.
+Time Petri nets~\cite{merlin1976} are one of the most widely used model
+for the specification and verification of real-time systems:
+they extend Petri nets with temporal intervals associated with
+transitions, specifying firing delay ranges for the transitions.
+In addition to the usual editing and analysis facilities of
+similar environments, Tina offers various abstract state space
+constructions that preserve specific classes of properties of
+the state spaces of nets, like absence of deadlocks, linear
+time temporal properties, or bisimilarity. For untimed systems,
+abstract state spaces helps to prevent combinatorial explosion.
+For timed systems, abstractions are mandatory as their state
+spaces are typically infinite, Tina implements various abstractions based on state classes.
+
+We used Tina as mode-checker (via the tool \emph{selt}) for the toolchain described in these pages
+for its capacities with Temporal Petri Nets, and its performances as model-checker.
+In addition, several model-checkers are being developed specifically for Tina.
+The first available, \emph{selt}, is a model-checker for an enriched version
+of State/Event -- LTL checking ~\cite{chaki2004}, a linear time temporal logic
+supporting both state and transition properties.  For the properties found false, a timed counter example is
+computed and can be replayed by the simulator \emph{play}, also present in Tina's software suite.
+
+Then, Tina can present its results in a variety of formats,
+understood by model checkers like MEC~\cite{mec5}, a $\mu$-calculus
+formula checker, or behavior equivalence checkers like Bcg,
+part of the CADP toolset~\cite{cadp}. 

doc/Rapport post-doc/3-imbsa.tex

@@ -0,0 +1,884 @@
+
+
+Failure propagation models are defined by safety engineers and are
+usually obtained through manual assessment of the safety of the
+system. This is a complicated task since failures can depend on more
+than one element of the system; be the result of the interaction
+between many faults; be the consequence of the missed detection of
+another fault (e.g. a fault inside an element tasked with detecting
+faults); etc. To cope with the complexity of the systems and the
+scenarios that need to be analysed, several model-based approaches
+have been proposed such as AltaRica~\cite{Altarica2.3,arnold1999altarica}, Figaro~\cite{bouissou05}, etc. each with their
+associated tooling.
+
+
+Our work is concerned with the modelling and analysis of failures
+propagation in the presence of time constraints. We concentrate on a
+particular safety property, called \emph{loss detection convergence},
+meaning that the system applies an appropriate and timely response
+to the occurrence of a fault before the failure is
+propagated and produces unwanted system behaviours. 
+%
+Similar problems
+were addressed in~\cite{thomas2013}, where the authors describe a
+process to model Failure Detection Isolation and Reconfiguration architecture (for use on-board satellites) that
+requires to take into account failure propagation,
+detection, and recovery times. However, these needs are not matched by 
+an effective way to express or check the safety constraints of the system.
+
+
+Our contribution is as follows. We define a lightweight extension of
+AltaRica, meaning that timing constraints are declared separately from
+the behaviour of a system (Sect.~\ref{sec:sect2}). Therefore it is easy to reuse a prior
+safety model and to define its temporal behaviour afterwards. We
+illustrate our method with an example inspired by safety architectures
+found in avionic systems.  This example illustrate the impact of time
+when reasoning about failure propagation, and we use it to
+show that taking into accounts timing constraints---in particular
+propagation delays---can help finding new failure modes that cannot be
+detected in the untimed models currently in use. In the process, we
+define two safety properties: \emph{loss detection}; and its temporal
+version, \emph{loss detection convergence}, meaning that a system
+applies an appropriate and timely response to the occurrence of a
+fault before the failure is propagated and produces unwanted system
+behaviours. We show that these two properties, which are of interest
+in a much broader context, can be reduced to effective model-checking
+problems.
+
+In the next chapter we extend this approach, by applying it to an industrial 
+satellite study case, and analysing the scalability of the methodology to more
+complex system models.
+
+
+\section{Model-Based Safety Analysis with AltaRica}\label{sec:sect2}
+
+
+\subsection{AltaRica language and versions}
+
+
+AltaRica is a high level modelling language dedicated to Safety
+Analysis. It has been defined to ease the modelling and analysis of
+failure propagation in systems.  The goal is to identify the
+possible failure modes of the system and, for each mode, the chain of
+events that lead to an unwanted situation. 
+
+
+In AltaRica, a system is expressed in terms of variables constrained
+by formulas and transitions. Several versions of the language have
+been defined (see for
+instance~\cite{arn00,prosvirnova2013altarica}).
+
+
+
+Three main versions of AltaRica have been designed so far. These three versions differ essentially with
+two respects: the way variables are updated after each transition firing and the way hierarchies of
+components are managed. In the first version, designed at the Computer Science Laboratory of
+University of Bordeaux (LaBRI), variables were updated by solving constraint systems. This model,
+although very powerful, was too resource consuming for industrial scale applications. A radical turn
+was therefore taken with the design of a data-flow version of the language. In AltaRica 2.0 Dataflow,
+variables are updated by propagating values in a fixed order. This order is determined at compile time.
+At the time this document is written, most of AltaRica tools rely on this Dataflow version. Ongoing investigation aim
+at improving AltaRica Dataflow in several ways, like propagating variable values by determining a fixpoint at execution time, 
+hence justifying the third version of
+the language currently being developped: AltaRica 3.0 or OpenAltaRica\cite{prosvirnova2013altarica}.
+
+\subsection{AltaRica modelling}
+In this work, we use the AltaRica 2.0 Dataflow language which is a fragment of other
+versions and which is sufficient to analyse the behaviour of computer
+based systems. (The approach discussed here could be applied to other
+AltaRica dialects.)  The models used in this work have been edited and
+analysed using Cecilia OCAS, a graphical interactive simulator
+developed by Dassault Aviation~\cite{bieber2004safety}.
+
+An AltaRica model is made of interconnected \emph{nodes}. A node can
+be essentially viewed as a mode automaton~\cite{rauzy02} extended with
+guards and actions on data variables. A node comprises three parts: a
+declaration of variables and events, the definition of transitions,
+and the definition of assertions.  We illustrate these concepts with
+the example of a simple node called \FUNC.  We give the code (textual
+definition) of \FUNC in Listing~\ref{ls:altarica} and a schematic
+representation in Fig.~\ref{fig:funct2}. The node \FUNC has one input,
+\code{I}, and one output, \code{O}.
+
+\lstinputlisting[language=Altarica,float=bht,captionpos=b,caption=\protect{Example
+	of AltaRica code for the node \FUNC.},frame=single,label=ls:altarica]{algos/function2.alt}
+
+\begin{figure}[thb]
+	\centering
+	\begin{minipage}{0.25\textwidth}
+		\centering
+		\includegraphics[width=\textwidth]{altarica-function.pdf}
+	\end{minipage}
+	\begin{minipage}{0.7\textwidth}
+		\centering
+		\vspace{1em}
+		\includegraphics[width=0.8\textwidth]{altarica-diagrams.pdf}
+	\end{minipage}
+	\caption{Graphical representation of node \FUNC (left) and its
+		associated failure mode automaton (right).\label{fig:funct2}}\vspace{1em}
+\end{figure}
+
+\enlargethispage{\baselineskip}
+%
+Nodes can have an internal state stored in a set of \emph{state
+	variables}, declared in a heading called \texttt{state}. In its
+nominal state (when \code{S = NOMINAL}), the \FUNC node acts as a
+perfect relay: it copies on its output the value provided by its input
+(we have \code{O = I}); this is expressed in the \code{assert}
+block.  On the opposite, its output is set to \LOSS or \ERR when
+\code{S} equals \code{LOST} or \code{ERROR}, respectively.
+%
+The assert directive is used to express constraints on the values of
+the input and output variables of a node, also called \emph{flow
+	variables}, establishing a link between the node and its
+environment, i.e. the other interconnected nodes.  It distinguishes
+between input (\texttt{in}) and output (\texttt{out}) variables. An
+assertion defines a rule to update the value of output flows according
+to the state of the component and the value of input flows. 
+
+The state variables of a node can only change when an 
+event is triggered. The code of \FUNC declares two events: \code{fail\_err}, that
+changes the state from \code{NOMINAL} to \code{ERROR}, and
+\code{fail\_loss}, that can transition from any state to
+\code{LOST}. This behaviour is the one displayed on the mode
+automaton of Fig.~\ref{fig:funct2}. Transitions are listed in the
+\texttt{trans} block of the node. Each transition has an (event)
+name and a definition of the form
+\lstinline[language=Altarica]{g |-evt-> e}, where the guard \code{g}
+is a Boolean condition that can refer to state  and flow
+variables. The event \code{evt} can be triggered when the guard is
+satisfied. In this case we apply the effect, \code{e}, that is an
+expression that modifies the values of state variables.
+
+Events are useful to model the occurrence of failures or the reaction
+to conditions on the flow variables.
+% It is possible to indicate
+% whether an event is triggered internally by a node---as in the case of
+% a reconfiguration---or externally by its environment---as in the case
+% of the occurrence of a failure. In the latter case,
+We can assign a
+law of probability on the occurrence of the failure using the heading
+\code{extern}. For instance we could assert that event
+\code{fail\_loss} follows an exponential distribution with the
+declaration:
+%%
+{\lstinline[language=Altarica]{extern law (<event fail_loss>)="exp 1e-4";}}
+%%
+In the next section, we propose a way to enrich this syntax to express
+timing constraints on events instead of probability distributions. At
+the moment, it is not possible to use stochastic events in addition to
+time events.
+
+\enlargethispage{\baselineskip}
+
+In the general case, an AltaRica model is composed of several
+interconnected node instances, following a component-based
+approach. Global assertions relate the input flows of a component to
+the output flows of other components. For the sake of brevity, we do
+not describe component synchronisation here and we refer the reader to
+\cite{Altarica2.3} for further details. More importantly, a
+hierarchical AltaRica model can always be ``flattened'', i.e.
+represented by a single node containing all the variables, events,
+assertions, and transitions from the composite system. We use this
+property in our interpretation of AltaRica in Fiacre.
+
+%%
+\subsection{Time AltaRica: Adding Timing Constraints to Events}%%\label{sec:adding-timing-constr}
+%%
+There already is a limited mechanism for declaring timing constraints
+in AltaRica. It relies on the use of external law associated with a
+\emph{Dirac distribution}. An event with Dirac$(0)$ law denotes an
+instantaneous transition, that should be triggered with the highest
+priority. Likewise, an event with Dirac($d$) (where $d$ is a
+positive constant) models a transition that should be triggered with a
+delay of $d$ units of time.
+%
+In practice, Dirac laws are rather a way to encode priorities between
+events than an actual mean to express duration. Moreover, while Dirac
+laws are used during simulation, they are not taken into account by
+the other analysis tools. Finally, the use of Dirac laws is not
+expressive enough to capture non-deterministic transitions that can
+occur within time intervals of the form $[a, b]$, where $a \neq
+b$. These constraints are useful to reason about failure propagation
+delays with different best and worst case traversal time. For this
+reason, we propose to extend event properties with \emph{temporal
+	laws} of the form:
+%%
+{\lstinline[language=Altarica]{extern law (evt) = "[a,b]";}}
+%%
+It is also possible to use open and/or unbounded time intervals, such
+as \code{]a,}$\infty$\code{[}.%%\scriptstyle
+
+With such a  declaration, the transition
+\lstinline[language=Altarica]{g |-evt-> e} can be triggered only if
+the guard \code{g} is satisfied for a duration (or \emph{waiting
+	time}) $\delta$, with $\delta \in [a, b]$.  A main difference with
+the original semantics of AltaRica is that the timing constraint of an event is
+not reinitialised unless its guard is set to false. 
+%%
+% Hence the waiting time of an event decreases when time elapse whereas,
+% while with a Dirac($d$) law the waiting time is reset to $d$ each time
+% the event fires. Finally, 
+Moreover, our semantics naturally entails a notion of \emph{urgency},
+meaning that it is not possible to miss a deadline: when $\delta$
+equals $b$, then either \code{evt} is triggered or another transition
+should (instantaneously) change the value of the guard \code{g} to
+false.
+
+We can illustrate the use of temporal laws with the following example of a new
+node, \PRE; see Listing.~\ref{ls:pre}. This node encodes a buffer that
+delays the propagation of its input. When the input changes, event
+\code{pre\_read} has to be triggered instantaneously. Then, only after
+a duration $\delta \in [a, b]$, the value stored by \PRE (in the state
+variable \code{Stored}) is propagated to its output.
+%
+\lstinputlisting[language=Altarica,float=t,captionpos=b,caption=\protect{Example
+	of Time AltaRica code: the basic delay.},frame=single,label=ls:pre]{algos/pre.alt}
+
+
+\section{A Definition of Fiacre Using Examples}\label{sec:sect3}
+
+Fiacre~\cite{berthomieu2008fiacre} is a high-level, formal
+specification language designed to represent both the behavioural and
+timing aspects of reactive systems. Fiacre programs are stratified in
+two main notions: \emph{processes}, which are well-suited for modelling
+structured activities (like for example simple state machines), and
+\emph{components}, which describes a system as a composition of
+processes. In the following, we base our presentation of Fiacre on
+code examples used in our interpretation of Time AltaRica.
+% \subsection{A Definition of Fiacre by Examples}
+% \label{sec:defin-fiacre-exampl}
+We give a simple example of Fiacre specification in
+Listing~\ref{lst:fiacre}. This code defines a process,
+\code{Function}, that simulates the behaviour of the AltaRica node
+given in Listing~\ref{ls:altarica}.
+
+\lstinputlisting[language=Fiacre,float=hbt,captionpos=b,caption=\protect{Example
+  of Fiacre code: type, functions and processes},label=lst:fiacre,frame=single]{algos/function.fcr}
+
+Fiacre is a strongly typed language, meaning that type annotations are
+exploited in order to avoid unchecked run-time errors. Our example
+defines two enumeration types, \code{FState} and \code{FailureType},
+that are the equivalent of the namesake AltaRica domains. We also
+define a record type, \code{Flows}, that models the environment of the
+node \code{Function}, that is an association from flow variables to
+values. Fiacre provides more complex data types, such as arrays,
+tagged union or FIFO queues. Fiacre also supports native
+\emph{functions} that provide a simple way to compute on values. In
+our example, function \code{update} is used to compute the state of
+the environment after an event is triggered; that is to model the
+effect of assertions in AltaRica. It uses two ternary (conditional)
+operators to mimic the \code{case}-expression found in the
+\code{assert} heading of Listing~\ref{ls:altarica}.
+
+% Functions are evaluated applicatively (there are no side effects) and
+% can be recursively defined.
+
+A Fiacre \emph{process} is defined by a set of parameters and {control
+  states}, each associated with a set of \emph{complex transitions}
+(introduced by the keyword \code{from}). Our example defines a process
+with two {shared variables}---symbol \code{\&} denotes variables
+passed by reference---that can be updated concurrently by other
+processes. In our case, variable \code{S} models the (unique) state
+variable of node \FUNC.
+
+Complex transitions are expressions that declares how variables are
+updated and which transitions may fire. They are built from constructs
+available in imperative programming languages (assignments,
+conditionals, sequential composition, \dots); non-deterministic
+constructs (such as external choice, with the \code{select} operator);
+communication on ports; and jump to a state (with the \code{to} or
+\code{loop} operators). In Listing~\ref{lst:fiacre}, the \code{select}
+statement defines two possible transitions, separated by the symbol
+\code{[]}, that loop back to \code{s0}. Each transition maps exactly
+to one of the AltaRica events, \code{fail\_loss} and \code{fail\_err},
+that we want to translate. Transitions are triggered
+non-deterministically and their effects are atomic (they have an ``all
+or nothing'' semantics). A transition can also be guarded by a Boolean
+condition, using the operator \code{on} or another conditional
+construct.
+
+It is possible to associate a time constraint to a transition using
+the operator \code{wait}. Actually, the ability to express directly
+timing constraints in programs is a distinguishing feature of
+Fiacre. We illustrate this mechanism in the code below, that
+corresponds to the interpretation of the node \PRE of
+Listing~\ref{ls:pre}. Basically, a transition constrained by a (time)
+interval $I$ can be triggered after a time $\delta$, with
+$\delta \in I$, only if its guard stayed continuously valid during
+this time. It is this behaviour that inspired our choice of semantics
+for the temporal law.
+
+The last notion that we need to introduce is \emph{components}.
+ Components allow the hierarchical composition of processes, in the
+ same way than AltaRica nodes can be composed into classes in order to
+ build more complex behaviors. 
+Thus, a Fiacre component defines a parallel composition of components and/or
+processes using statements of the form \code{par} \vars{P}$_0$
+$\parallel \dots \parallel$ \vars{P}$_n$ \code{end}. It can also be
+used to restrict the visibility of variables and ports and to define
+priorities between communication events. 
+% Priorities are explicitly declared as constraints between
+% communication ports, as in \code{go1 > go2}.  
+We give an example of Fiacre component in Listing~\ref{lst:pre2},
+where we define an upgraded version of the delay operator \PRE.
+%
+\lstinputlisting[language=Fiacre,float=bt,captionpos=b,caption=\protect{Wait statement, components and synchronisation on ports.},label=lst:pre2,frame=single]{algos/pre2.fcr}
+
+% %
+% \lstinputlisting[language=Fiacre,float=bt,captionpos=b,caption=\protect{Example
+%   of Fiacre code: declaring timing
+%   constraints},label=lst:pre1,frame=single]{algos/pre.fcr}
+% %
+
+
+A problem with the implementation of \PRE is that at most one failure
+mode can be delayed at a time. Indeed, if the input of \PRE changes
+while the state is \code{Full}, then the updated value is not taken
+into account until after event \code{pre\_wait} triggers.
+%
+It is not possible to implement a version that can delay an unbounded
+number of events in a bounded time; this would require an unbounded
+amount of memory to store the intermediate values. More fundamentally,
+this would give rise to undecidable verification problems (see
+e.g.~\cite{bouyer2004updatable}). To fix this problem, we can define a
+family of operators, \PRE\code{\_k}, that can delay up-to $k$
+simultaneous different inputs. Our implementation relies on a
+component that uses three process instances: one instance of
+\code{front}, that reads messages from the input (variable \code{I}),
+and two instances of \code{delay}, that act as buffers for the values
+that need to be delayed. Process \code{front} uses the local ports
+\code{go1} and \code{go2} to dispatch values to the buffers.
+Component \PRE\code{\_2} is enough to model the use case defined in
+Sect.~\ref{sec:example-fail-detect-1}. Indeed, any element in the FDI
+system may propagate at most two different status, one from \OK to
+\LOSS and then from \LOSS to \ERR.
+
+
+
+\section{Example of a Failure Detection and Isolation System}
+\label{sec:example-fail-detect-1}
+
+We study the example of a safety critical function that illustrates
+standard failure propagation problems. We use this example to show the
+adverse effects of temporal failure propagation even in the presence
+of % system safety improvements. In our case the addition of
+Failure Detection and Isolation (FDI)  capabilities.
+%
+This example is inspired by the avionic functions that provide
+parameters for Primary Flight Display (PFD), which is located in the
+aircraft cockpit. The system of interest is the computer that acquires
+sensors measurements and computes the aircraft \emph{calibrated airspeed} (CAS)  parameter. 
+Airspeed is crucial for pilots: it is taken into
+account to adjust aircraft engines thrust and it plays a main role in
+the prevention of over speed and stall.
+
+%%
+\begin{figure}[thb]
+	\centering
+	\includegraphics[width=1\textwidth]{figures/AirSpeed_Computation.jpg}
+	\caption{Functional and physical views of the airspeed computation function.\label{fig:cockpit}}
+\end{figure}
+%%
+
+CAS is not directly measured by a dedicated sensor, but is computed as
+a function of two auxiliary pressure measurements, the static pressure
+(Ps) and total pressure (Pt); that is
+$\mathrm{CAS} = f(\mathrm{Pt}, \mathrm{Ps})$.
+% \begin{equation*}
+% CAS = C_{SO}\sqrt{5 \cdot \left( \left(\frac{Pt - Ps}{P_0} + 1\right)^{2/7} - 1\right)}
+%   \end{equation*}
+%   with $C_{SO}$ and $P_0$ two
+%   constants. % the speed of sound under standard day sea level conditions
+These two measurements come from sensors located on the aircraft nose,
+a pressure probe and a pitot tube.
+% Our proposed functional view shows:
+% \begin{itemize}
+% \item 	Two external functions \I{1} and \I{2} that measure static and total pressure. They represent the functions allocated to the sensors.
+% \item	Three inner functions of the system: \F{1} and \F{2} for sensor measurements acquisition by the onboard computer and \F{3} for airspeed computation.
+% \item	The PFD functions have not been modelled in the sole purpose of simplification.
+% \end{itemize}
+%
+%%
+
+Our proposed functional view is given in Fig.~\ref{fig:cockpit}. It
+consists in two external input functions \I{1} and \I{2} that measure static
+and total pressure; and three inner functions of the system, \F{1} and
+\F{2} for sensor measurements acquisition by the on-board computer and
+\F{3} for airspeed computation. For simplification purposes, the
+PFD functions have not been modelled.
+
+Next, we propose a first failure propagation view aiming at
+identifying the scenarios leading to an erroneous airspeed computation
+and display to the pilot (denoted \ERR).  Such failure can only be
+detected if a failure detector is implemented, for instance by
+comparing the outputs of different functions. Undetected, it could
+mislead the pilot and, consequently, lead to an inappropriate engine
+thrust setting.  We also want to identify the scenarios leading to
+the loss of the measure (denoted \LOSS). In such a case, the pilot can
+easily assess that the measure is missing or false and consequently
+rely upon another measure to control the aircraft (note that such
+redundancy is not modelled). For example, airspeed out of
+bound---indicating that an airliner has crossed the sonic barrier---is
+considered to be of kind \LOSS. It can be understood that scenarios leading to the
+loss of the airspeed are less critical than the ones leading erroneous
+values.
+
+% We consider two possible kinds of fail status: the ``silent'' failure of
+%an element (denoted \ERR); or a communication problem with one of the
+% functions (denoted \LOSS). 
+
+ A failure is typically a loss of connectivity or the
+ detection of (clearly) erroneous transmitted values, for instance a
+ variable out of bounds. A \LOSS fail is less critical than an \ERR
+ since it can be detected immediately and isolated. On the other hand,
+ an \ERR fail can only be detected if a failure detector is
+ implemented, for instance by comparing the outputs of different
+ functions. In the following, we consider that the status
+ are ordered by their level of severity, that is \ERR $<$ \LOSS $<$\OK. 
+
+
+\subsubsection{Safety model of the architecture without FDI}
+%%\label{sec:error-prop-simple}
+For the sake of understandability, we choose to study a simplified version of
+FDI system. While simple, this system is representative of failure
+propagation mechanisms found in actual onboard systems. 
+%%
+
+We provide an AltaRica model corresponding to the functional view 
+of the CAS function in Fig.~\ref{fig:example0}. This model, tailored
+to study failure propagation, is comprised of:
+% ( All the functions are modelled according to the node function
+% introduced in the Sect.~\ref{sec:sect2}.
+%
+two external functions, \I{1} and \I{2}, that have no input (so, in
+their nominal state, the output is set to \OK); two inner functions,
+\F{1} and \F{2}, which are instances of the node \FUNC described in
+Sect.~\ref{sec:sect2}; and a function, \F{3}, that is the composition
+of two basic elements: a multiplexer, \MIN, representing the
+dependence of the output of \F{3} from its two inputs, and a computing
+element \F{3Processing} that represents the computation of the
+airspeed. \F{3Processing} is also an instance of node \FUNC.
+
+\begin{figure}[t]
+	\centering
+	\begin{tikzpicture}
+	\node[anchor=south west,inner sep=0] at (0,0)   { \includegraphics[width=0.75\textwidth]{figures/Modele0}};
+	\draw[red!50,ultra thick, dashed] (7,2.85) rectangle (2.6,0.5);
+	\node[red] at (6.5,2.5) {\texttt{\large F3}};
+	\end{tikzpicture}
+	\caption{A simple example of failure  propagation.\label{fig:example0}}
+\end{figure}
+%
+In case of single failure scenario, \MIN propagates the failure coming
+either from one input or the other. In case of multiple failures,
+%when both inputs have identical failure, the faillure propagates;
+%For instance,
+% both inputs to \LOSS lead to an output of \LOSS.
+% But when it receives an erroneous fail then the multiplexer will
+% propagate an \ERR.  The remaining failure combination drew our
+% attention during \F{3} modelling.
+%on the other hand,
+when different failures propagate, one being \LOSS
+and the other being \ERR,---and without appropriate FDI---the system
+outcome is uncertain.
+%
+Solving this uncertainty would require a detailed behavioural model of
+the on-board computer and a model for all the possible failure modes,
+which is rarely feasible with a sufficient level of confidence, except
+for time-tested technology.  Given this uncertainty, it is usual to
+retain the state with the most critical effect, that is to say:
+% in this case, \MIN can be thought of as a simple logic operator that
+% computes the minimum of its two inputs, and
+the output of \F{3} is \ERR.
+
+
+% Since a \LOSS can be ``easily'' detected, we want to avoid a situation
+% where the whole system propagates \ERR while one of its
+%internal element propagates a \LOSS. The rationale is that we should be
+% able to isolate (or quarantine) the system when we know for sure that
+% one of its element does not reliably respond to commands. This can be
+% expressed by the following safety property.
+%%
+
+% In the next section, we study the system with the addition of FDI
+% capabilities.
+
+Our goal is to prevent the computation of an erroneous airspeed while
+one of \F{3} input signals is lost.  The rationale is that the system
+should be able to passivate automatically the airspeed when it detects
+that one of its input signals is not reliable. This behaviour can be
+expressed with the following property:
+
+%%
+\begin{prop}[Loss Detection and Instantaneous Propagation]\label{prop:1}
+	A function is \emph{loss detection safe} if, when in nominal mode, it
+	propagates a \LOSS whenever one of its input nodes propagates a
+	\LOSS.
+\end{prop}
+
+% This is a simple system used to detect non-nominal behaviours
+% and to trigger observables in order to isolate the failure mode.
+% ({The figures are actual screen capture of models edited with Cecilia
+%   OCAS.})
+% \subsubsection{Analysis}
+
+
+We can show that our example of Fig.~\ref{fig:example0} does not meet
+this property using the \emph{Sequence Generation} tool available in
+Cecilia OCAS.
+%%
+% This system has several sources of unreliability. Both its sources and
+% the computing elements (\F{1}, \F{2} and \F{3Processing}) can
+% experience spontaneous failures, meaning that their outputs can
+% transition instantaneously to \LOSS or \ERR. Errors are irrecoverable;
+% once a function becomes faulty, its output will always stay equal to
+% \LOSS or \ERR.  Likewise, if both inputs are ``nominal'' then the
+% output of \MIN is \OK. We assume that the multiplexer cannot undergo
+% spontaneous failures.
+%%
+% This can be tested using a perfect detectors, \FF{3}{Loss}, placed at
+% the output of the system. 
+%%
+To this end, we compute the minimal cuts for the target equation
+$((\text{\F{1.O.Loss}} \vee \text{\F{2.O.Loss}}) \wedge \neg
+\text{\F{3.O.Loss}})$, meaning the scenario where \F{3} does not
+propagates \LOSS when one of \F{1} or \F{2} does. Hence function \F{3}
+is {loss detection safe} if and only if the set is empty.
+ \footnote{To check the safety of \F{3}, we need to perform the same
+ analysis for all the elements that can propagate a loss fail, not
+ only \F{1}.}.
+
+In our example, once we eliminate the cases where \F{3} is not nominal
+(that is when \F{3Processing} is in an error state), we find eight
+minimal cuts, all of order $2$. In the following section, we correct
+the behaviour of \F{3} by considering a new architecture based on
+detectors and a switch to isolate the output of \F{3} when faulty:
+
+%%
+ {%\centering
+   \begin{small}
+ \begin{tabular}{c@{\quad\quad}c}
+     \begin{minipage}[t]{0.42\linewidth}
+ \begin{verbatim}
+ {'F1.fail_err', 'F2.fail_loss'}
+ {'F1.fail_err', 'I2.fail_loss'}
+ {'F1.fail_loss', 'F2.fail_err'}
+ {'F1.fail_loss', 'I2.fail_err'}
+ \end{verbatim}
+     \end{minipage}
+     &
+     \begin{minipage}[t]{0.42\linewidth}
+ \begin{verbatim}
+ {'F2.fail_err', 'I1.fail_loss'}
+ {'F2.fail_loss', 'I1.fail_err'}
+ {'I1.fail_err', 'I2.fail_loss'}
+ {'I1.fail_loss', 'I2.fail_err'}
+ \end{verbatim}
+     \end{minipage}\\
+   \end{tabular}\\
+     \end{small}
+ }
+%
+ Each of these cuts lead to trivial violations of our safety
+ property. For instance, we obtain the cut \code{\{'F1.fail\_err',
+   'F2.fail\_loss'\}} that corresponds to the case where \F{1}
+ propagates \ERR and \F{2} propagates \LOSS, in which case \F{3}
+ propagates \ERR. This is exactly the situation that we want to
+ avoid. 
+
+
+\begin{figure}[bt]
+	\centering
+	\begin{tikzpicture}
+	\node[anchor=south west,inner sep=0] at (0,0)   { \includegraphics[width=\textwidth]{figures/Modele2.png}};
+	\draw[red!50,ultra thick, dashed] (10.8,3.4) rectangle (2,0);
+	\node[red] at (10.4,3.1) {\texttt{\large F3}};
+	\end{tikzpicture}
+	\caption{Model of a FDI function with a switch and an  alarm.\label{fig:example1}}
+\end{figure}%\vspace*{-1cm}
+%\enlargethispage{\baselineskip}
+
+\subsubsection{Safety model of the architecture with FDI}
+%%\label{sec:simple-fail-detect}
+%%
+%In order to satisfy the Prop.~\ref{prop:1},
+The updated implementation of \F{3} (see Fig.~\ref{fig:example1})
+uses two perfect detectors, \F{1Loss} and \F{2Loss}, that can detect
+a loss failure event on the inputs of the function. The (Boolean) outputs of
+these detectors are linked to an OR gate ({\ttfamily AtLeastOneLoss})
+which triggers an \ALARM when at least one of the detectors outputs
+true. The alarm commands a \SWITCH; the output of \SWITCH is the same
+as \MIN, unless \ALARM is activated, in which case it propagates a
+\LOSS failure. The alarm can fail in two modes, either
+continuously signaling a \LOSS or never being activated. The
+schema in Fig.~\ref{fig:example1} also includes two delays operators, \D{1} and \D{2}, 
+that model delay propagation at the input of the detectors;
+we will not consider them in the following lines, but come back to these timing constraints at the end of the section.
+
+% \TODO{why do we need Alarm ! why does the alarm can fail ! we could
+%   plug directly the or gate to the switch}- Permanent failure of the alarm.
+
+The FDI function---with a switch and an alarm---is a stable scheme for
+failure propagation: when in nominal mode, it detects all the failures
+of the system and it is able to disambiguate the case where its inputs
+contains both \ERR and \LOSS. Once again, this can be confirmed using
+the Sequence Generation tool. If we repeat the same analysis than
+before---and if we abstract away the delay nodes---we find $56$
+minimal cuts, all involving a failure of either \ALARM or
+\F{3Processing}, i.e. a non-nominal mode. This means that, in an untimed model, our new
+implementation of \F{3} satisfies the loss detection property, as
+desired.
+% \begin{figure}[hbt]
+%   \centering
+% \begin{tikzpicture}
+%   \node[anchor=south west,inner sep=0] at (0,0)   { \includegraphics[width=\textwidth]{figures/Modele2.png}};
+%   \draw[red,ultra thick, dashed] (10.6,3.6) rectangle (2.2,0);
+%   \node[red] at (10,3) {\texttt{\huge F3}};
+% \end{tikzpicture}
+% %  \includegraphics[width=0.95\textwidth]{figures/Modele2}
+%   \caption{Taking into consideration propagation delays in the FDI
+%     system.\label{fig:example2}}
+% \end{figure}
+% Unfortunately, this model makes unrealistic assumptions about the
+% instantaneous failure propagation of detection. Indeed, it may be the
+% case that the outputs of \F{1} and \F{2} are delayed as they are
+% propagated to the observers \F{1Loss} and \F{2Loss}.  Next, we study
+% new failure modes that may arise from this situation and how we can
+% detect them.
+%%
+% \subsection{Timed Safety model of the architecture with FDI}
+% \label{sec:timed-safety-model}
+%%
+% In this section, we consider a new AltaRica model that takes into
+% account propagation delays. To this end, we may insert two instances
+% of the delay node (the element \PRE defined in Sect.~\ref{sec:sect2})
+% before the detectors \F{1Loss} and \F{2Loss}.
+Even so, it is easy to find a timed scenario where the safety property
+is violated. 
+
+Assume now that \F{1} and \F{2} propagate respectively the status \LOSS and \ERR,
+at the same date. In such a case and considering possible latencies,
+while \ERR reaches \MIN instantaneously,
+the output of \F{1} might reach \F{1Loss} at successive date.
+% of the output of \F{2} reaching \F{2Loss},.
+This leads to a transient state where the alarm is not activated whereas
+the output of \MIN is set to \ERR. This brings us back to the same
+dreaded scenario than in our initial model.  
+%%
+ In particular, this scenario corresponds to the cut
+ \code{\{'F1.fail\_loss', 'F2.fail\_err'\}}, that is not admissible in
+ an untimed semantics. 
+%%
+
+This example suggests that we need a more powerful method to compute
+the set of cuts in the presence of temporal constraints. On the other
+hand, we may also advocate that our safety property is too limiting in
+this context, where perfect synchronicity of events is rare. Actually,
+it  can be proven that the output of \F{3} will eventually converge to a
+loss detection and isolation mode (assuming that \F{3} stays nominal and
+that its inputs stay stable).
+%
+To reflect
+this si\-tua\-tion, we pro\-pose an improved safety property that takes into
+account temporal properties of the system:
+%%
+\begin{prop}[Loss Detection Convergent]\label{prop:2} A function is
+	\emph{loss detection convergent} if (when in nominal mode) there
+	exists a duration $\Delta$ such that it continuously outputs a \LOSS
+	after the date $\delta_0 + \Delta$ if at least one of its input
+	nodes continuously propagates a \LOSS starting from $\delta_0$
+	onward. The smallest possible value for $\Delta$ is called the
+	\emph{convergence latency} of the function.
+\end{prop}
+Hence, if  the latency
+needed to detect the loss failure can be bound, and if the bound is sufficiently
+small safety-wise, we can still deem our system as safe.
+In the example in Fig.~\ref{fig:cockpit}, this property can indicate for how long an erroneous airspeed is shown on the PFD to the pilot,
+before the failure is isolated.
+
+In the next section, we use our approach to generate a list of ``timed
+cuts'' (as model-checking counterexamples) that would have exposed the
+aforedescribed problems. We also use model-checking to compute
+the {convergence latency} for the node \F{3}. In this simple example,
+we can show that the latency is equal to the maximal propagation delay
+at the input of the detectors. The value of the latency could be much
+harder to compute in a more sophisticated scenario, where delays can
+be chained and/or depends on the internal state of a component.
+
+
+\section{Compilation of AltaRica and Experimental evaluation}\label{sec:sect4}
+
+We have implemented the transformation outlined in
+Sect.~\ref{sec:sect3}; the result is a compiler that automatically
+generates Fiacre code from an AltaRica model. The compilation process
+relies on the fact that it is possible to ``flatten'' a composition of
+interconnected nodes into an intermediate representation, called a
+\emph{Guarded Transition System} (GTS)~\cite{rau08}. A GTS is very
+similar to a (single) AltaRica node and can therefore be encoded in a
+similar way. Our tool is built using the codebase of the model-checker
+EPOCH~\cite{epoch}, which provides the functionalities for the
+syntactic analysis and the linking of AltaRica code. After
+compilation, the Fiacre code can be checked using
+Tina~\cite{BRV04}. As seen in Sect.~\ref{sec:tina}, the core of the Tina toolset is an
+exploration engine that can be exploited by dedicated model-checking
+and transition analyser tools. Tina offers several abstract state
+space constructions that preserve specific classes of properties like
+absence of deadlocks, reachability of markings, or linear and
+branching time temporal properties. These state space abstractions are
+vital when dealing with timed systems that generally have an infinite
+state space (due to the use of a dense time model). In our
+experiments, most of the requirements can be reduced to reachability
+properties, so we can use on-the-fly model-checking techniques.
+% and very ``aggressive'' abstractions.
+
+\begin{figure}[thb]
+	\centering
+		\includegraphics[width=\textwidth]{figures/passerelle.png}
+	\caption{Graphical representation of the AltaRica/Fiacre toolchain.\label{fig:toolchain}}
+\end{figure}
+
+We interpret a GTS by a Fiacre process whose parameters consist of all
+its state and flow variables. Each transition
+\lstinline[language=Altarica]{g |-evt-> e} in the GTS is (bijectively)
+encoded by a transition that matches the guard \code{g} and updates
+the variables to reflect the effect of \code{e}  plus the assertions. Each transition can
+be labelled with  time and priorities constraints to take
+into account the \code{extern} declarations of the node. This
+translation is straightforward since all the operators available in
+AltaRica have a direct equivalent in Fiacre. Hence every
+state/transition in the GTS corresponds to a unique state/transition
+in Fiacre. This means that the state (reachability) graph of a GTS and
+its associated Fiacre model are isomorphic. This is a very strong and
+useful property for formal verification, since we can very easily
+transfer verification artefacts (such as counterexamples) from one
+model back to the other.
+
+The close proximity between AltaRica and Fiacre is not really
+surprising. First of all, both languages have similar roots in process
+algebra theory and share very similar synchronisation mechanisms. More
+deeply, they share formal models that are very close: AltaRica
+semantics is based on the product of ``communicating automata'',
+whereas the semantics of Fiacre can be expressed using (a time
+extension of) one-safe Petri nets. The main difference is that
+AltaRica provide support for defining probabilities on events, whereas
+Fiacre is targeted towards the definition of timing aspects. This
+proximity in both syntax and semantics is an advantage for the
+validation of our tool, because it means that our translation should
+preserve the semantics of AltaRica on models that do not use extern
+laws to define probabilities and time. We have used this property to
+validate our translation by comparing the behaviours of the models
+obtained using Cecilia OCAS simulation tool and their translation. For
+instance, in the case of the CAS system of
+Sect.~\ref{sec:example-fail-detect-1}, we can compute the set of cuts
+corresponding to Safety Property~\ref{prop:1} (loss detection) by
+checking an invariant of the form
+$((\text{\F{1.O}} = \text{\code{Loss}}) \vee (\text{\F{2.O}} =
+\text{\code{Loss}}) \Rightarrow (\text{\F{3.O}} =
+\text{\code{Loss}}))$.
+%
+%%\TODO{Check if it is necessary to mention the tool, as opposed to counterexamples}
+In both cases---with and without FDI---we are able to compute the
+exact same set of cuts than Cecilia OCAS. This is done using the
+model-checker for modal mu-calculus provided with Tina, which can list
+all the counterexamples for a (reachability) formula as a graph.  More
+importantly, we can use our approach to compute the timed
+counterexample described at the end of
+Sect.~\ref{sec:example-fail-detect-1}. All these computations can be
+done in less than a second on our test machine.
+
+\subsection{Empirical evaluation}
+We have used our toolchain to generate the reachable state space of
+several AltaRica models~\footnote{All the benchmarks tested in this paper are available at
+	https://w3.onera.fr/ifa-esa/content/model-checking-temporal-failure-propagation-altarica}:
+RUDDER describes a control system for the
+rudder of an A340 aircraft~\cite{bernard2007experiments}; ELEC refers
+to three simplified electrical generation and power distribution
+systems for a hypothetical twin jet aircraft; the HYDRAU model
+describes a hydraulic system similar to the one of the A320
+aircraft~\cite{bieber2002combination}. The results are reported in
+Table~\ref{table:2}. In each case, we indicate the time needed to
+generate the whole state space (in seconds) and the number of states
+and transitions explored. For information, we also give the number of
+state variables as reported by Cecilia OCAS. All tests were run on an
+Intel 2.50GHz CPU with 8GB of RAM running Linux. In the case of model
+HYDRAU we stopped the exploration after $30$ minutes and more than
+$9.10^{9}$ generated states.
+The state space is large in this benchmark because it models the physical a-causal propagation of a leak, so a leak can impact both upward and backward components and trigger a reconfiguration,  multiplying the number of reachable states.
+Moreover, the topology of the system shall be reconfigurated after the detection of some failures and this dynamic reconfiguration combined with a-causal propagation increases again more the size of the state space.
+In all cases, the time needed to generate
+the Fiacre code is negligible, in the order of 10~ms.
+
+\begin{table}[tb]
+	\centering
+	\begin{tabular}{|l|c|c|c|c|c|}
+		\hline
+		\textbf{Model} & \textbf{time} (s) & \textbf{\# states} &
+		\textbf{\#
+			trans.}
+		& \textbf{\# state vars}\\ \hline
+		RUDDER~~~ & 0.85 & $3.3\,10^4$  & $2.5\,10^5$ & 15    \\ \hline
+		ELEC 01         & 0.40 & 512               & $2.3\,10^3$   & 9                          \\ \hline
+		ELEC 02         & 0.40 & 512               & $2.3\,10^3$   & 9                          \\ \hline
+		ELEC 03         & 101 & $4.2\,10^6$        & $4.6\,10^7$   & 22                   \\ \hline
+		HYDRAU           & 1800 & ---     &  ---       & 59               \\ \hline
+		CAS~                   & 0.40                          & 729                & $2.9\,10^3$   & 6                \\ \hline
+		CAS with \PRE~~~        &  46  & $9.7\, 10^5$ & $4.3\, 10^6$   &   10                \\ \hline
+	\end{tabular}
+	\vspace*{1em}
+	\caption{State space size and generation time for several use cases.\label{table:2}}
+\end{table}
+
+Our models also include two versions of the complete CAS system
+(including the detectors, the alarm and the switch); both with and
+without the delay functions \D{1} and \D{2}. The ``CAS with \PRE'' model
+is our only example that contains timing constraints. In this case, we
+give the size of the state class graph generated by Tina, that is an
+abstract version of the state space that preserves LTL properties. We
+can use Tina to check  temporal properties on this
+example. More precisely, we can check that \F{3} has the \emph{loss
+	detection convergence} property. To this end, a solution is to add a
+Time Observer to check the maximal duration between two events:  first,  a \code{obs\_start} event is triggered when the output of \F{1} or \F{2} changes to \LOSS;
+then an \code{obs\_end} event is triggered when the output of \F{3} changes to \LOSS. The
+observer has also a third transition (\code{obs\_err}) that acts as a
+timeout and is associated with a time interval $I$ and is enabled
+concurrently with \code{obs\_end}. Hence,
+Time Observer ends up in the state yield by \code{obs\_err}
+when  the output of \F{3} deviates from its
+expected value for more than $d$ units of time, with $d \in I$. We
+have used this observer to check that the \emph{convergence latency}
+of the CAS system equals $3$, when
+we assume that the
+delays are in the time interval $[1, 3]$. 
+The result is that 
+\code{obs\_err} is fireable for any value of $d$ in the interval
+$[0,3]$, while  \code{obs\_err} is not fireable if $I = ]3, \infty[$.
+% It is enough to indicate to choose $I = [0,3]$.
+These two safety properties can be checked on the system (plus the
+observer) in less than $0.6$~s.
+
+
+% \begin{wraptable}{r}{0.35\textwidth}
+% %\begin{table}[bth]
+%   \centering
+%  \vspace*{-7mm}
+% \begin{tabular}{|c|c|l}
+% \cline{1-2}
+% \textbf{delay}$\mathbf\tau$  & \textbf{safety property} &   \\ \cline{1-2}
+% % {$\quad[4,4]\quad$}       & ok                       &   \\ \cline{1-2}
+% {$]3, \infty[$} & holds                 &   \\ \cline{1-2}
+% {[}3,3{]}       & not holds              &   \\ \cline{1-2}
+% {[}0,3{]}       & not holds             &   \\ \cline{1-2}
+% \end{tabular}
+% \caption{Latencies check on  Eq.~\eqref{eq:mc1}
+%   with $\delta = [1,3]$.\label{table:1}}
+% %\end{table}
+% \end{wraptable}
+
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "main"
+%%% End:
+
+%%  LocalWords:  Fiacre

doc/Rapport post-doc/4-aocs.tex

@@ -0,0 +1,300 @@
+
+In order to assess the timed formal model approach, we apply it to an industrial case study, namely the validation of the automatic mode management model of an AOCS (Attitude and Orbit Control System) of a satellite. The full description is available in this report; the synthesis is published at ERTS 2018 conference.
+\subsection*{Acronyms}
+\begin{center}
+\begin{table}[h!]
+	\begin{small}
+		\centering
+		\begin{tabular}{|c|c|}
+			\hline 
+			\textbf{Term} & \textbf{Description} \\ 
+			\hline 
+			ACM & Attitude Control Mode \\ 
+			\hline 
+			ARO & Automatic Recondifiguration Order \\ 
+			\hline 
+			ASM & Acquisition and Safe Mode \\ 
+			\hline 
+			CAM & Collision Avoidance Manoeuvre \\ 
+			\hline 
+			FCM & Formation Control Mode \\ 
+			\hline 
+			GNC &  Guidance, Navigation and Control \\ % Guidance and Navignatio Mode
+			\hline 
+			IMU & Inertial Measurement Unit \\ 
+			\hline 
+			ISL & Inter-Satellite Link \\ 
+			\hline 
+			OCM& Orbit Control Mode \\
+			\hline
+			OFF&OFF Mode \\
+			\hline 
+			PFailed&Permanent Failure\\
+			\hline
+			STR&Star Tracker  \\
+			\hline
+			TC&Telecommand\\
+			\hline
+			TFailed&Temporary Failure\\
+			\hline
+			TM&Telemetry\\
+			\hline
+		\end{tabular} 
+	\end{small}
+%	\caption{Acronyms used}
+\end{table}
+\end{center}
+
+
+\section{An Expression of Industrial Needs and Requirements}\label{sec:aocsintro}
+
+Failure Detection, Isolation and Recovery (FDIR) functions are implemented aboard satellites in order to detect the occurrence of failures and to prevent the failure from propagating in the whole system, which could cause critical events and thus jeopardize the mission. 
+The complexity of the FDIR verification and validation (V\&V) increases with the system complexity. As systems include more and more interacting functions and functional modes, it becomes harder to evaluate at the overall system level the effects of local failures. That is even truer when we consider the effects of time. Indeed, unexpected behavior can arise from a bad timing of events. Timing constraints allow to represent the impact of computation times, delays on the propagation of failures, and the reaction time of the reconfigurations steps triggered in reaction to failure detection.
+Thus, new models and tools are needed to assist early V\&V of the on-board processes and FDIR design. Thomas and Blanquart~\cite{thomas2013} describe a process to model FDIR satellite functions. This process requires to model failure propagation, detection, and recovery times, which requires modelling languages expressive enough to support complex system modelling. Associated tools should provide automatic verification that on-board FDIR functions are correct despite latency in failure propagation or management. For instance, one should be able to verify whether failures are recovered before they are propagated further in the system. 
+
+\begin{figure}[tb]
+	\centering
+	\includegraphics[width=\textwidth]{figures/satellite_telecom.png}
+	\caption{A satellite and its equipment}
+\end{figure}
+
+
+
+\section{AOCS Case Study}\label{sec:aocs}
+
+The validation of the approach on the automatic mode management model of an AOCS (Attitude and Orbit Control System) of a satellite considers
+control and command specifications of a satellite constellation mission. The example discussed in these pages is a simplification of this industrial specification which 
+takes into account a single function and 3 equipment per satellite. Each equipment is necessary to the execution of its function in any of its operational modes.
+The real specification includes 3 functions, several equipment, surveillance elements and automata. 
+Validation can be done by simulation or property verification; the way we take here is the latter.
+
+\subsection{Architecture description}
+
+In space missions, the control of the attitude and the orbit of the aircraft is delegated to the AOCS. In the case study, the system relies on 
+\begin{itemize}
+	\item AOCS sensors:
+	\begin{itemize}
+	\item Inertial Measurement Unit (IMU) implements accelerometers which provide the acceleration and gyros which give the estimated angular speed; 
+	\item Star-TRackers (STR) gives the estimated attitude quaternion; 
+	\end{itemize}
+	\item AOCS actuators: Thrusters (ColdGasProp) permit the control of the spacecraft;
+	\item 	The On-Board Computer unit, which manages all the spacecraft’s activity and therefore the AOCS application software that acquires the information from the sensors and commands the actuators.
+\end{itemize}
+
+\subsection{AOCS mode automaton}
+The space industries and agencies contribute in the initiative Space AVionics Open Interface Architecture (SAVOIR) to define a single, agreed and common solution for the definition of the architecture of avionics system. The assess of our approach is validate with an industrial case study based on these Ground-Board Interface specifications\cite{ASRA}, the ECSS standard for the Space Segment Operability\cite{ECSS‐E‐ST‐70‐11C} and the AOCS mode management\cite{ECSS-E-ST-60-30C}. Generally, the specification of the satellite mode management is specified in early phases at system level with a co-engineering approach. The focus is on:
+\begin{itemize}
+	\item The AOCS capabilities to control the attitude and the orbit of the satellite;
+	\item The Operations capabilities to operate the satellite by telecommand (TC) from the ground segment;
+	\item The FDIR capabilities to continue the mission operations and to survive critical situations without relying on ground intervention.
+\end{itemize}
+
+In our approach, an early validation is experimented to increase the confidence on these system specifications and later to reduce the consolidation with the subsystems engineering. 
+The use-case focuses on the initial satellite mode management shown in  Figure~\ref{fig:1}; the current representation of AOCS mode.
+
+\begin{figure}[thb]
+	\centering
+	\includegraphics[width=\textwidth]{figures/AOCSmode_schema.png}\vspace*{-5em}
+	\caption{Representation of the AOCS modes.\label{fig:1}}
+\end{figure}
+
+
+Several AOCS modes are designed for the different mission phases.
+Switching between a mode and another depends on three possible reasons: 
+\begin{itemize}
+\item either the satellite receives a telecommand (TC) from Earth to trigger a mode change (Acquisition \& Safe Mode, Attitude Control Mode, Orbit Control Mode, Formation Control Mode); 
+\item	or there is an automatic on-board transition (A) when the separation from the launcher is detected or when the collision avoidance manoeuvre is finished; 
+\item or an automatic FDIR reconfiguration order (ARO) can be triggered by the ground (TC) or by the on-board FDIR to recover a failure. The ARO triggers the AOCS into the OFF mode and it is available from all AOCS mode except CAM. 
+\end{itemize}
+
+Transition between modes is possible only when the involved equipment is available. In fact, some devices can take tenths of minutes to be ready for a mode switch. This is why it is very important to take into account timing constraints.
+
+It is easy to understand that the planning and the reactivity to messages triggering a transition between modes is crucial, as failing to detect a message or reconfiguring in time would yield an unwanted mode. For instance, it could result in a transition into Safe Mode, which entails a heavy reboot and loss of scientific acquisition time. Many tasks of the mission depend on different inputs and are time-dependent; the temporal bounds of those tasks are the ones that we will analyse through formal V\&V in order to detect possible unwanted situations, or undetected failures through the system, in order to maintain the safety and mission autonomy objectives.
+
+Figure~\ref{fig:aocs} displays the AOCS mode automaton considered in the case study. This is a more precise version of the automaton of Fig.~\ref{fig:1} based on a SysML activity diagram that represents the transitions between mode and, for each AOCS mode, its associated state-machine. Each AOCS mode has essentially three states: an initial; a nominal; and a ``degraded'' state. 
+When the request of change mode is received, the AOCS triggers the initialization of equipment used by the mode in the Initial state and then it switches into the \emph{Nominal state}  when all involved equipment are operational. The degraded state is triggered when the failure of used equipment is detected. All AOCS mode are described in the next subsections.
+
+
+\begin{figure}[thb]
+	\centering
+	\includegraphics[width=1.1\textwidth]{{"figures/2-2 - AOCS mode automaton"}.png}
+	\caption{AOCS mode automaton.\label{fig:aocs}}
+\end{figure}
+
+\begin{figure}[thb]
+	\centering
+	\includegraphics[width=.9\textwidth]{{"figures/2-3 - ASH mode"}.png}
+	\caption{Acquisition \& Safe mode automaton.\label{fig:asm}}
+\end{figure}
+
+\begin{figure}[hbt]
+	\centering
+	\includegraphics[width=.6\textwidth]{{"figures/2-4 set ON the equipment for ASM mode"}.png}
+	\caption{Set ON equipment for ASM mode.\label{fig:asm-ON}}
+\end{figure}
+
+\subsubsection{OFF mode}
+In this mode, any equipment of use-case can be started. This mode is used when the satellite is in the launcher; and after an ARO to reestablish the satellite in safe conditions.
+\subsubsection{Acquisition \& Safe mode (ASM)}
+In this mode, the first acquisition in safe configuration is realized. The ASM automaton with the 3 states is shown in Figure \ref{fig:asm} When the TC to switch on ASM mode is received, the initialization of equipment used by ASM is started by the \texttt{EquipASM\_ON} activity (Figure~\ref{fig:asm-ON}).
+
+\begin{figure}[htb]
+	\centering
+	\includegraphics[width=\textwidth]{{"figures/2-5 ACM automaton"}.png}
+	\caption{Attitude Control Mode automaton.\label{fig:acm}}
+\end{figure}
+
+\begin{figure}[bht]
+	\centering
+	\includegraphics[width=.6\textwidth]{{"figures/2-6 set ON the equipment for ACM mode"}.png}
+	\caption{Set ON equipment for ACM mode.\label{fig:acm-ON}}
+\end{figure}
+
+\subsubsection{Attitude Control Mode (ACM)}
+In this mode, the attitude is coarse controlled by the AOCS. The ASM automaton with the 3 states is shown in Figure~\ref{fig:acm}. When the TC to switch on ACM mode is received, the 
+initialization of equipment used by ACM mode is started by the  \texttt{EquipASM\_ON} activity (Figure~\ref{fig:acm-ON}).
+
+
+\subsubsection{Collision Avoidance Manœuvre (CAM)}
+This case is used when the ground or FDIR triggers a manoeuvre to avoidance a collision with debris or other satellite. These specific TC are called CAM and they are only available 
+from the Attitude Control Mode, Orbit Control Mode and Formation Control Mode. So, the request of CAM is not possible from the Acquisition \& Safe Mode.
+
+The CAM automaton is described in Figure~\ref{fig:cam}. The exit of CAM is autonomous into ACM mode when the manoeuvre or predefined-timing is finished. 
+
+\begin{figure}[htb]
+	\centering
+	\includegraphics[width=.6\textwidth]{figures/{"2-7 Collision Avoidance Mode"}.png}
+	\caption{Collision Avoidance Mode.\label{fig:cam}}
+\end{figure}
+
+\subsubsection{Orbit Control Mode (OCM)}
+In this mode, the orbit is controlled and the mission is suspended. The OCM automaton is shown in Figure~\ref{fig:ocm}.
+
+\begin{figure}[p]
+	\centering
+	\includegraphics[width=.8\textwidth]{figures/{"2-8 OCM automaton"}.png}
+	\caption{Orbit Control Mode.\label{fig:ocm}}
+\end{figure}
+
+\subsubsection{Formation Control Mode (FCM)}
+FCM is the nominal mode where the formation flying is operational. The FCM automaton with the 3 states is shown in Figure~\ref{fig:fcm}.
+
+\begin{figure}[p]
+	\centering
+	\includegraphics[width=.9\textwidth]{figures/{"2-9 Formation Control Mode"}.png}
+	\caption{Formation Control Mode.\label{fig:fcm}}
+\end{figure}
+
+
+\subsubsection{Equipment}
+
+The model is based on the following assumption:
+\begin{itemize}
+	\item An equipment can be on, off, or faulty.
+	\item An equipment is started by the function that needs it. The reboot has a duration.
+	\item An equipment that is not useful in the current modes, is switched off.
+	\item The number of redundancies is a parameter defined for each equipment.
+	\item Temporary or permanent failures can affect an equipment\footnote{Those failures can be injected by the user.} only when it's running.
+	\begin{itemize}
+		\item After a temporary failure, the equipment is rebooted automatically.
+		\item After a permanent failure, the equipment moves over one of its available redundancies. If no redundancy is available, the state remains faulty.
+		\item When an ARO event is triggered, the equipment switches off. It can be switched on without moving to a redundancy by the functions. 
+	\end{itemize}
+\end{itemize}
+
+\begin{figure}[h]
+	\centering
+	\includegraphics[width=.5\textwidth]{figures/table1.png}
+	\caption{Allocation of the equipment on the modes.\label{tab:equip}}
+\end{figure}
+
+\begin{figure}[bt]
+	\centering
+	\includegraphics[width=\textwidth]{figures/{"Equipment mode"}.png}
+	\caption{Equipment state machine.\label{fig:equip}}
+\end{figure}
+
+Figure~\ref{fig:equip} also displays the state machine of an equipment. The IMU, ColdGasProp, and STR equipment have similar state machines. Equipment which is started from an ``OFF'' state, can only reach an ``ON'' state by passing through a ``Starting'' state. When a failure happens, the equipment makes a transition to state ``Failed''. If the failure is permanent, the equipment goes over the redundant equipment. If failure is temporary, state ``Starting'' can be restored with no further consequences. The allocation of equipment on modes is given by Table in Fig.~\ref{tab:equip}. For example, in our study case, the STR is used in four modes. 
+
+
+The AOCS, as all satellite systems, presents an increasing complexity of interactions between functions and other equipment, often raising design and integration issues during the product final testing and verification phases. Correcting these issues often generates a heavy rework and is a well-known cause for cost overruns and project delays. Moreover, the operation of space systems is traditionally informally expressed in design documents as a set of modes representing functions, equipments and monitoring mechanisms. Usually the mode dynamics of all the satellite systems and their interaction with the FDIR functions are validated by review, i.e. exhaustive manual (opposed to automatic) consistence checks and cross-reading. In case of formation flying, complex equipment and instruments are distributed over several spacecrafts. The human validation activities become practically impossible due to the high number of combinations to be analyzed. Powerful computer-aided analysis techniques are expected to help overcoming this issue.
+
+FDIR functions validation is particularly difficult, especially with ``traditional approaches'' because of the large number of interactions and not nominal situations, which increases the difficulty in analysing them. A large variety of points of view is necessary to fully analyse the behaviour of FDIR and its impact on dependability properties, including to be complete an explicit representation of the entities handled by FDIR: architecture, faults, time, etc.
+
+We believe that formalizing and validating the specifications through animation/simulation and model-checking has several strong advantages. On the one hand, modelling during the specification phase forces the designer to formalise and clarify the specifications. Animation/simulation is useful for validating the model against the specifications and for identifying behaviour inconsistencies based on relevant user-defined scenarios. Such inconsistencies are difficult to identify in a classical purely paper-based specification process. Last, formal verification proves that none of the possible execution scenarios violates the system properties. Such approaches are useful not only for validating an architecture or FDIR strategy once defined, but also for tuning its parameters during the definition phase.
+
+\section{Case study modelling}
+
+The original model of the AOCS case study comes from the validation of the FDIR of formation flying satellites. Formation flying requires specific techniques to ensure flight coordination and the safety of the spacecraft in case of anomaly. This requires giving more autonomy and complex decision-making mechanisms to the On-Board Computer unit. The SPaCIFY project~\cite{synoptic} described a similar architecture using the Synoptic language, in order to identify the needs in terms of guaranteeing traceability, validation, and general analysis---possibly using formal techniques---of the V-cycle of development~\cite{sutre09}. From this architecture, an AltaRica 1.0 version of the Synoptic model was generated automatically. We have used this initial AltaRica model and adapted it first to the AltaRica Dataflow syntax~\cite{Altarica2.3}. Then we can automatically translate this new model into Fiacre using our toolchain.
+
+
+Validating a FDIR approach in satellite architecture has been done in project AGATA~\citep{rugina09} by coupling simulation with model-checking, the latter to prove that some given logical or timing properties hold in all states of a scenario generated by simulation. In AGATA the choice went in the same direction as us: focusing significant part of the system and abstracted away the rest of it using UPPAAL~\cite{uppaal1997}.
+However, the model they performed model-checking was un-timed, with several variables used as clocks to track time, with the drawback that the size of the graph is exponential in the number of clocks~\cite{daws}, when Fiacre/Tina relies on a single clock.
+
+
+\subsection{AltaRica modelling process}
+In order to validate the FDIR software, the AltaRica model shall represent both the FDIR logic and the failure propagation in the hardware platform that is monitored and reconfigured according to the FDIR logic. During earlier design phase, AltaRica models without timing constraints can be used to abstract the details of the failure propagation paths and to support a preliminary safety and dependability analysis. Then the model details can be refined and timing information can be introduced in Time Altarica (see Chap.~\ref{altarica}). This will help system designers to verify critical properties when time-bounded reactions are required. On the application side, focusing on the interaction of FDIR mechanisms and AOCS modes is of an utmost importance when designing a space system.
+
+In this case study, we considered a quite detailed view of the FDIR logic related to the management of the AOCS and a simplified view of the satellite hardware. Next study will consider more detailed view of the satellite hardware architecture.
+
+\subsection{Details of the model}
+Regarding the modelling activity, we focused first on the methodology applied to timed failure propagation described for a multi-phase system. In the starting architecture, described in Sect.~\ref{sec:aocs}, each satellite has three separate kinds of equipment: the STR (with a redundancy of 3), the ColdGasProp (with a redundancy of 3), and the IMU (with a redundancy of 2). We assume that mode transitions are initiated instantaneously (with a transition associated to a Dirac law), while events related to equipment “switching on” or rebooting are associated with a time law as follows: 
+\begin{itemize}
+\item STR takes 30~mn, it is associated with the interval $[30,30]$
+\item IMU takes less than 10~s, it is associated with the interval $[0,0.1]$
+\item ColdGasProp takes between 5 and 10~mn, it is associated with $[5,10]$
+\end{itemize}
+
+We consider that these durations include all physical delays. The notification of a detected failure from Surveillance is a timed event, ranging between 0 and 10~ms.
+
+It is worth noting that the Synoptic (and later, the AltaRica 1.0) models that we have had access to, make practically no use of flow variables, which are variables that represent the ports’ input/output of components. This modelling style enforces that either communication are simultaneously performed both by sender and receiver either communication cannot occur at all. Moreover, This has a great influence on the empirical evaluation we performed, as undesired states are avoided by the modeller, while one of the interests of our approach resides in speeding-up the early design evaluation phase by outlining design errors and allowing an automated assessment of the model. As the design of the AOCS mode has no such flaws,  we aimed at checking the invariants, in order to validate the model, and to evaluate the scalability of the approach on the former properties plus a temporal one.
+
+\subsection{Empirical evaluation}
+
+In general, real-time model-checking does not scale well on very detailed and large systems, especially when the system uses events that work on very different timescales. Nevertheless, failure propagation models can be large but not very detailed in early design phase. In this particular use case, we are able to check the smallest instances of the problem in less than 3 minutes on a typical laptop; while the most difficult problem can be checked in half an hour.
+
+We propose different versions of the AOCS architecture in order to appraise the complexity of the case, and the scalability of our toolchain. We apply a series of simplifications to the model, generating different benchmarks of growing complexity. The main parameters in our experiments will be the number of replicas of each equipment; and the possibility, or not, to have transient failures.
+A first simplification of the model is to consider permanent failures only. Benchmarks done in this condition are denoted ``Pfail only'' (see Table~\ref{tab:results1}). This choice simplifies the model-checking problem since it discards loops in the behavior of the system that originate from the system rebooting through its ``Starting'' state. On the other hand, we can build instances that are more complex by increasing the number of equipment. For example, we can add a second kind of thruster. In Table~\ref{tab:results1}, we label each experiment with the number of different kind of thrusters used. 
+
+For each configuration, we investigate two different kinds of properties. 
+
+A first set of properties contains invariants on the set of states reachable by the system, like the absence of deadlocks or the property that \emph{equipment STR is always OFF when the AOCS is in Acquisition \& Safe Mode}. These are typically referred to as \emph{logical safety properties}. Both examples of properties, when true, require enumerating all the possible states of the system. Therefore, they give a good estimate of the complexity and size of the problem. Since reachability properties do not require to compute the possible transitions between two states (to compute the \emph{state graph}), it is possible to use very efficient on-the-fly techniques that are both space and time-efficient.  
+
+Then we check an example of timing property, namely we prove a bound on the maximal time it takes for the system to reach a safe mode after a particular event. More precisely, given a duration δ, we check whether the AOCS can reach its ``Collision Avoidance'' mode in less than δ minutes after activating surveillance. We can check this kind of properties by adding an ``observer'' component that monitors the time elapsed since an event occurred and that can raise an error after a timeout. The observer adds extra behaviors to the analysis of the initial system and can therefore significantly increase its state space, especially when there is a lot of non-determinism in the system or when there are long-running activities. We observed that our use case exhibit partially these two causes of state space explosion, limiting the verification of timed properties to the one thruster benchmarks (in 640s for the ``\emph{Pfail only}'', and 44mn54s for the ``\emph{Pfail and Tfail}''), within the time-cut we set at 45mn. This can be explained by the fact that satellite systems are usually very deterministic. Indeed, operators need to plan the behavior of a satellite very precisely when they compute TCs. This is an encouraging observation for the tractability of our approach in the aerospace domain.
+
+\begin{table}
+	\centering
+\begin{tabular}{|l|c|c|c|c|}
+	\hline 
+	Model & states & transitions & time (s) & size (MB) \\ 
+	\hline 
+	1 thruster Pfail only & 224 374 & 8345295  & 225 & 8 \\ 
+	\hline 
+	1 thruster & 448 335 & 20 470 486  &  & 16 \\ 
+	\hline 
+	2 thrusters & 4 003 939 & 207 594 548 &  & 189 \\ 
+	\hline 
+	3 thrusters & - & - & - & - \\ 
+	\hline 
+\end{tabular} 
+\caption{Empirical evaluation of state space generation, Intel Xeon @ 2.33GHz}
+\label{tab:results1}
+\end{table}
+
+Table~\ref{tab:results1} gives the results obtained with our experiments on four different configurations. We record the size of the model (in number of states and number of transitions) as well as the execution time and the memory consumed. All these results where obtained on a typical laptop with 8 GB of memory and an Intel processor. We observe that the Tina model checker scales up well on these models, failing at the biggest instance, not producing results after 45mn of run-time. These numbers give a good estimate of the complexity of checking safety properties.
+
+A little less than 10 years ago, a similar study~\cite{sutre09} was performed using models expressed in AltaRica 1.0 and two different model-checkers,  ARC~\cite{arc} and MEC 5~\cite{mec5}. These are two tools developped specifically for the AltaRica language. Like with the experiments reported in Table~\ref{tab:results1}, ARC and MEC were used to compute the set of reachable states from an initial configuration of the system. These tools are based on symbolic methods for representing the sets of states and transitions of an AltaRica model. This is usually more efficient than enumerative techniques, such as those used by Tina. On the other hand, neither ARC or MEC take inherently into account timing constraints; whereas Tina relies on a ``symbolic'' representation of time constraints. Therefore they need to model time using an explicit clock (an integer variable) that should be updated in the model. ARC and MEC both bumped into serious limitations when scaling-up the models, even when simple invariants were checked~\cite{sutre09}.
+
+It is worth noting that, in our experiments, the addition of timed transitions did not increased the number of reachable states and only increased the execution time by a factor of 4. 
+Even if in our case study no counterexamples were generated because of the correctness of the proposed models, our toolsuite permits, in an untimed model, to compute cutsets and countreexamples showing a timed scenario where the safety property checked is violated~\cite{albore2017IMBSA}. Such couterexamples are generally not easily readable and difficult to debug. In the case of an implementation with FIACRE, it is possible to exploit relations between models representing the information required by the user on the one hand, and information produced by the tools, on the other hand to visualize in a compact view both the outcome of the model-checker and the FIACRE model, which facilitates greatly the interpretation of the analysis process~\cite{Zalila}. A possible future work would be of applying a similar approach to allow the representation of the analysis directly in the AltaRica initial model.
+
+
+\newpage
+
+
+%%  LocalWords:  ELEC Fiacre Dataflow Altarica evt Xeon
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "main"
+%%% End:

doc/Rapport post-doc/5-conclusions.tex

@@ -0,0 +1,131 @@
+%%%\section{Conclusion and Related Work}
+\label{sec:Conclusion}
+
+Our work is concerned with the modelling and analysis of safety properties 
+in the presence of time constraints. 
+
+
+We concentrate on a
+particular safety property, called \emph{loss detection convergence},
+for failures
+propagation, meaning that the system applies an appropriate and timely response
+(e.g. isolation) to the occurrence of a fault before the failure is
+propagated and produces unwanted system behaviours. Similar problems
+were addressed in~\cite{thomas2013}, where the authors describe a
+process to model FDIR architecture (for use on-board satellites) that
+requires to take into account failure propagation time, failure
+detection time, and failure recovery time. However, these needs are not matched by 
+an effective way to check for safety. Our approach provides a solution to
+model these timing constraints within AltaRica. We also provide an
+automatic transformation from Time AltaRica models into one of the
+input formats of Tina. We show that two interesting
+problems---computing ``timed cuts'' and bounding the convergence
+latency of a node---can be reduced to a decidable model-checking
+problem.
+
+Several works have combined model-checking and AltaRica, the
+archetypal example being the MEC tool~\cite{griffault2004mec} that was
+developed at the same time than the language. More recently, Bozzano
+et al~\cite{bozzano2012} have defined a transformation from AltaRica
+Dataflow to the symbolic model-checker NuSMV. While this tool does not
+support complex timing constraints, it offers some support for Dirac
+laws (and implicit priorities) by encoding an ad-hoc scheduler. The
+use of symbolic model-checking techniques is interesting in the case
+of models with a strong combinatorial blow up, like for instance model
+HYDRO of Sect.~\ref{sec:sect4}. Nonetheless, even though Tina also
+includes BDD-based tools, no approaches allow to combine the advantages
+of both realtime and symbolic model-checking techniques.
+
+Realtime techniques are central to our approach. We define an
+extension of AltaRica where timing constraints can be declared using
+{temporal laws} of the form \code{law (evt) = "[a,b]"}, with a
+semantics inspired by Time Petri nets. As a result, we can apply on
+AltaRica several state space abstractions techniques that have been
+developped for ``timed models'', such as the use of DBM and state
+classes~\cite{berthomieu2004tool}. In a different way, Cassez et
+al.~\cite{pagetti2004} have proposed an extension of AltaRica with
+explicit ``clock variables'', inspired by Timed Automata, where clocks
+are real-valued flow variables that can be used inside the guards of
+events.
+%%
+% (Which means that there are restrictions on the type of equations
+% one can use in the \code{assert} declaration of a node.)
+%%
+% They also define an algorithm to compile this extension into
+% Uppaal~\cite{larsen1997uppaal}. 
+Their work is mainly focused on the verification of behavioural
+properties and centers on the encoding of urgency and priorities
+between events, two notions that are naturally offered in
+Fiacre. Also, our extension is less invasive. If we ignore the
+\code{extern} declaration then we obtain valid AltaRica code. More
+research is still needed to further the comparison between these two
+approaches in the context of safety assessments.
+
+Aside from these works on AltaRica, we can also cite recent works that
+combine failure propagation analysis and timing constraints, such
+as~\cite{bittner2016}. This work defines an automatic method for
+synthesising \emph{Timed Failure Propagation Graphs} (TFPG), that is
+an extension of the notion of cut-sets including information on the
+date of events. TFPG provide a condensed representation that is easier
+to use than sets of timed cuts.Therefore, it would be interesting to
+use this format in our case.
+
+For future work, we plan to adapt our translation to a new version of
+the AltaRica language---called AltaRica 3.0, or OpenAltaRica---that
+imposes less restrictions on the computation of flow variables. We
+also want to apply our approach to more complex industrial use cases,
+involving reconfiguration time besides failure detection and
+isolation; or even systems with humans and reaction time in the
+loop.
+
+%  More generally, the main purpose of our project is to build on
+% the results of use cases in order to propose a set of modelling
+% guidelines for taking into account time in failure propagation
+% analysis.
+
+
+
+% AltaRica 3.0 still relies on propagation based variable update, but
+% the order in which this
+% propagation takes place in determined at execution time, in other
+% words, a fix-point is computed. This update scheme extends
+% significantly the expressivity of the language, making possible to
+% handle looped systems, i.e. systems in which variables depend of
+% each other in a circular way, as the order of the updates is left
+% free to the modeller. }
+
+
+% Actual industrial systems embed several elements of complexity, that
+% affects the design phase, caused by the diversity of technical issues
+% and evaluation criteria coming from different viewpoints.  
+
+% %
+% Nevertheless, defining and verifying these properties is critical for
+% embedded and real-time systems.  In particular, time information, as
+% delays or durations, are the properties that are central in real-time
+% systems design and verification: in fact, temporal aspects can be the
+% cause of missed failure detections or undesired reactions to (delayed)
+% failure propagation. To be able to perform a safety analysis on the
+% temporal properties allows to create systems that will operate as
+% intended in a real-world environment.
+% % Additional benefits from timed and temporal models are the ability
+% % to perform formal verification in early development stages, using
+% % automated techniques as model-checking.
+
+
+
+The use of timed Altarica will help system designers to verify critical properties when time-bounded reactions are required. On the application side, it is central to use formal methods, e.g. model-checking, to validate properly formalized  specifications. Forcing the designer to produce early well formed models during the specification phase yields to have the specifications formalised and pinned down for the next development phases. Then, the validation of those specifications in the model allows to identify behavioral inconsistencies. Espacially, such inconsistencies are difficult to identify in a classical, purely paper-based, specification process. Last, formal verification proves that none of the possible execution scenarios violates the system properties. Such approaches are useful not only for validating an architecture or FDIR strategy once defined, but also for tuning its parameters during the conception phase. Results from the early V\&V of the on-board processes and FDIR design can be fed back into the requirements analysis phase. The contribution of proper (formal) analysis tools to the complex system designs helps in reducing the specification phase, and the early validation of requirements and models. Such extended V\&V toolbox will eventually consent to reduce the time cost of large projects, helping the development of new spacecraft technologies. 
+
+
+\section{Future Work}
+
+
+
+
+
+%%  LocalWords:  Dataflow OpenAltaRica
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "main"
+%%% End:

doc/Rapport post-doc/IMBSA-paper.tex

@@ -0,0 +1,64 @@
+\documentclass{llncs}
+
+%\usepackage{graphicx}
+%
+\begin{document}
+
+
+\title{Formal Safety Verification of Temporal Model Properties via Model-Checking  Mots clés  Titre à trouver 
+
+\author{Alexandre Albore, Silvano Dal Zillo, Guillaume Infantes, Christel Seguin, Pierre Virelizier}
+
+\institute{alexandre.albore@irt-saintexupery.com , IRT Saint Exupéry,
+118, route de Narbonne - CS 44248 
+31432 Toulouse cedex 4 (France) }
+\maketitle
+
+\begin{abstract}
+
+Abstract is here.
+
+\end{abstract}
+
+\section{Introduction}\label{sec:Introduction}
+
+Ce qu’on présente : méthode et chaine outillée pour la vérification formelle à travers model-checking de propriétés temporelles dans des modèles avec des retards dans la transmission des messages d’erreur. Par exemple, s’assurer de la fiabilité d’une fonction d’alarme quand des délais affectent les temps de la propagation des pannes. Traiter des modèles temporisés et en valider les propriétés temporelles de façon formelle est un enjeu fondamental dans le domaine de la safety.
+. : cf. PV
+Mo
+
+\section{Study case}\label{sec:Others}
+
+	Élément de retard avec Dirac
+	Propriétés qu’on veut vérifier (temporisation et délai sur les messages. Hypothèses sur les délais pour les pertes dans la chaîne précédente, c-à-d s’assurer de la fiabilité de la fonction d’alarme) ; on sait que si on a un retard différent sur les lignes, l’alarme n’est pas garanti, e.g. r1 + r2 <> r2 + r3.                                        
+
+        \section{Altarica and Fiacre}
+        	Tina / Fiacre et Petri temporisé et les propriétés que ça rajoute\\
+	Altarica vu à travers l’exemple\\
+	Traduction Altarica -> Fiacre
+
+        \section{Empirical evaluation - Fiacre}
+	Example sans délais (delta 0) : loss -> alarme et $F4_{loss}$\\
+	Example avec délais (delta N) : loss -> !alarme et $!F4_{loss}$\\
+	Example avec délais non-déterministe (pourrait identifier le temps minimum)
+        
+\section{Conclusion}\label{sec:Conclusion}
+
+État de l’art (model-checking temporisé, model-checking temporisé paramétrique, …)
+Conclusion : plus-value (une suite outillée, fournir un cadre unifié d’outils)
+
+
+
+\section*{Acknowledgments}\label{sec:Acknowledgments}
+
+Authors would like to thank YYYYY.
+
+\begin{thebibliography}{1}
+
+\bibitem{Einstein}
+A. Einstein, On the movement of small particles suspended in stationary liquids required by the molecular-kinetic theory of heat, Annalen der Physik 17, pp. 549-560, 1905.
+
+\end{thebibliography}
+
+\end{document}
+
+	

doc/Rapport post-doc/algos/function.fcr

@@ -0,0 +1,17 @@
+type FState      is union NOMINAL | LOST | ERROR end
+type FailureType is union Err | Loss | Ok end
+type Flows       is record I:FailureType, O:FailureType end
+   
+function update(S : FState, env : Flows) : Flows is
+   var  f : Flows := {I=env.I, O=env.O}
+   begin
+      f.O := (S = NOMINAL ? f.I : (S = LOST ? Loss : Err));
+      return f
+   end
+
+process Function(&S : FState, &env : Flows) is
+   states s0
+   from s0 select
+      on (S != LOST); S := LOST; env := update(S, env); loop
+   [] on (S = NOMINAL); S := ERROR; env := update(S, env); loop
+   end

doc/Rapport post-doc/algos/function2.alt

@@ -0,0 +1,12 @@
+domain FState = {NOMINAL, LOST, ERROR} ;
+domain FailureType = {Err, Loss, Ok} ;
+
+node Function
+   flow   I : FailureType : in ; O : FailureType : out ;
+   state  S : FState ;
+   event  fail_loss, fail_err ;
+   init   S := NOMINAL ;
+   trans  S != LOST    |- fail_loss -> S := LOST ;
+          S =  NOMINAL |- fail_err  -> S := ERROR ;
+   assert O = case { S = NOMINAL : I, S = LOST : Loss, else Err } ;
+edon

doc/Rapport post-doc/algos/function2.fcr

@@ -0,0 +1 @@
+

doc/Rapport post-doc/algos/pre.alt

@@ -0,0 +1,12 @@
+domain BType = {Empty, Full} ;
+node Pre
+   flow  I : FailureType : in; O: FailureType : out;
+   state Stored, Delayed : FailureType, S : BType;
+   event pre_read, pre_wait;
+   init  Stored := Ok, Delayed := Ok, S := Empty;
+   trans
+     (Stored != I) & (S = Empty) |- pre_read -> Stored := I, S = Full;
+     (S = Full) |- pre_wait -> Delayed := Stored, S = Empty;
+   assert  O = Delayed;
+   extern law (pre_read) = "[0,0]"; law (pre_wait) = "[a,b]";
+edon

doc/Rapport post-doc/algos/pre.fcr

@@ -0,0 +1,8 @@
+type BType      is union Empty | Full end
+
+process Pre(&Stored, &Delayed : FailureType, S : BType, &env : Flows) is
+   states s0
+   from s0 select
+      on (Stored != env.I and S = Empty); wait [0,0]; Stored := I; ...
+   [] on (S = Full); wait [a,b]; Delayed := Stored; S := Empty; ...
+   end

doc/Rapport post-doc/algos/pre2.fcr

@@ -0,0 +1,22 @@
+process Pre(&Stored, &Delayed : FailureType, S : BType, &env : Flows) is
+   states s0
+   from s0 select
+      on (Stored != env.I and S = Empty); wait [0,0]; Stored := env.I; $\ldots$
+   [] on (S = Full); wait [a,b]; Delayed := Stored; S := Empty; $\ldots$
+   end
+   
+process delay[go : in FailureType](&O : FailureType) is
+   states sEmpty, sFull
+   var delayed : FailureType := Ok
+   from sEmpty go?delayed; to sFull
+   from sFull  wait [a,b]; O := delayed; to sEmpty
+
+process front[p,q : out FailureType](&I : FailureType) is
+   states s
+   var stored : FailureType := Ok
+   from s on (I != stored); stored := I; select p!I [] q!I end; loop
+   
+component Pre_2(&I, &O: FailureType) is
+   port go1, go2 : FailureType in [0,0]
+   priority go1 > go2
+   par * in front[go1,go2](&I) || delay[go1](&O) || delay[go2](&O) end

doc/Rapport post-doc/aliascnt.sty

@@ -0,0 +1,88 @@
+%%
+%% This is file `aliascnt.sty',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% aliascnt.dtx  (with options: `package')
+%% 
+%% This is a generated file.
+%% 
+%% Project: aliascnt
+%% Version: 2009/09/08 v1.3
+%% 
+%% Copyright (C) 2006, 2009 by
+%%    Heiko Oberdiek <heiko.oberdiek at googlemail.com>
+%% 
+%% This work may be distributed and/or modified under the
+%% conditions of the LaTeX Project Public License, either
+%% version 1.3c of this license or (at your option) any later
+%% version. This version of this license is in
+%%    http://www.latex-project.org/lppl/lppl-1-3c.txt
+%% and the latest version of this license is in
+%%    http://www.latex-project.org/lppl.txt
+%% and version 1.3 or later is part of all distributions of
+%% LaTeX version 2005/12/01 or later.
+%% 
+%% This work has the LPPL maintenance status "maintained".
+%% 
+%% This Current Maintainer of this work is Heiko Oberdiek.
+%% 
+%% This work consists of the main source file aliascnt.dtx
+%% and the derived files
+%%    aliascnt.sty, aliascnt.pdf, aliascnt.ins, aliascnt.drv.
+%% 
+\NeedsTeXFormat{LaTeX2e}
+\ProvidesPackage{aliascnt}%
+  [2009/09/08 v1.3 Alias counter (HO)]%
+\newcommand*{\newaliascnt}[2]{%
+  \begingroup
+    \def\AC@glet##1{%
+      \global\expandafter\let\csname##1#1\expandafter\endcsname
+        \csname##1#2\endcsname
+    }%
+    \@ifundefined{c@#2}{%
+      \@nocounterr{#2}%
+    }{%
+      \expandafter\@ifdefinable\csname c@#1\endcsname{%
+        \AC@glet{c@}%
+        \AC@glet{the}%
+        \AC@glet{theH}%
+        \AC@glet{p@}%
+        \expandafter\gdef\csname AC@cnt@#1\endcsname{#2}%
+        \expandafter\gdef\csname cl@#1\expandafter\endcsname
+        \expandafter{\csname cl@#2\endcsname}%
+      }%
+    }%
+  \endgroup
+}
+\newcommand*{\aliascntresetthe}[1]{%
+  \@ifundefined{AC@cnt@#1}{%
+    \PackageError{aliascnt}{%
+      `#1' is not an alias counter%
+    }\@ehc
+  }{%
+    \expandafter\let\csname the#1\expandafter\endcsname
+      \csname the\csname AC@cnt@#1\endcsname\endcsname
+  }%
+}
+\newcommand*{\AC@findrootcnt}[1]{%
+  \@ifundefined{AC@cnt@#1}{%
+    #1%
+  }{%
+    \expandafter\AC@findrootcnt\csname AC@cnt@#1\endcsname
+  }%
+}
+\def\AC@patch#1{%
+  \expandafter\let\csname AC@org@#1reset\expandafter\endcsname
+    \csname @#1reset\endcsname
+  \expandafter\def\csname @#1reset\endcsname##1##2{%
+    \csname AC@org@#1reset\endcsname{##1}{\AC@findrootcnt{##2}}%
+  }%
+}
+\RequirePackage{remreset}
+\AC@patch{addto}
+\AC@patch{removefrom}
+\endinput
+%%
+%% End of file `aliascnt.sty'.

doc/Rapport post-doc/altarica-diagrams.tex

@@ -0,0 +1,32 @@
+\documentclass[tikz]{standalone}
+
+\usepackage{tikz}
+\usetikzlibrary{arrows,shapes,shapes.geometric,decorations,automata,shadows}
+
+\tikzstyle{edge}=[draw,thick,->] \tikzset{state/.style={draw, text
+    centered, thick, rectangle split, rectangle split parts=2, rounded
+    corners,fill=blue!10}}
+
+\newcommand{\STATE}[2]{\makebox[5em]{\vphantom{I}{\ttfamily #1}}\nodepart{second} \makebox[4em]{\vphantom{I}{\ttfamily #2}}}
+
+
+\begin{document}
+\begin{tikzpicture}[scale=1.25,
+  initial text={},
+  initial distance=2em,
+  every initial by arrow/.style={thick,*->}]
+  \node [state,initial] (s0) at (0,-1) {\STATE{NOMINAL}{O = I}};
+  \node [state] (s1) at (4,0) {\STATE{LOST}{O = Loss}};
+  \node [state] (s2) at (4,-2) {\STATE{ERROR}{O = Err}};
+
+  \path[edge] (s0) edge[bend left] node[below, yshift=-10pt]
+  {{\ttfamily fail\_loss}} (s1);
+  \path[edge] (s0) edge[bend right] node[right, yshift=5pt] {{\ttfamily fail\_err}} (s2);
+  \path[edge] (s2) edge node[right] {{\ttfamily fail\_loss}} (s1);
+\end{tikzpicture}
+\end{document}
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: t
+%%% End:

doc/Rapport post-doc/altarica-function.tex

@@ -0,0 +1,24 @@
+\documentclass[tikz]{standalone}
+
+\usepackage{tikz}
+\usetikzlibrary{arrows,shapes,positioning,decorations,decorations.markings,shadows}
+
+\tikzstyle{block} = [rectangle, draw, fill=white, text centered, 
+text width = 3em, minimum height = 1.5em]
+\tikzstyle{point} = [circle, fill=green!80, minimum height=0.5em]
+\tikzstyle{line} = [draw, -latex']
+
+\begin{document}
+\begin{tikzpicture}[]
+  \node [block] (F) at (1.5, 0) {};
+  \node [point] at (1.5, 0) {};
+
+  \node [] (L) at (0,0) {{\ttfamily I}};
+  \node [] (R) at (3,0) {{\ttfamily O}};
+
+  \node [above of=F, node distance=1.5em] {{\ttfamily Function}};
+
+  \path[line] (F) -- (R);
+  \path[line] (L) -- (F);
+\end{tikzpicture}
+\end{document}

doc/Rapport post-doc/app.tex

@@ -0,0 +1,588 @@
+\section{Interpretation of AltaRica in Fiacre}
+\lstset{  keywordstyle=\bfseries,
+  % keywordstyle={[2]\itshape},
+  keywordstyle=\color{bluekeywords},
+  basewidth=0.94ex,
+  showstringspaces=false,
+  emptylines=1,
+  aboveskip=4pt,belowskip=4pt,
+  mathescape=true, 
+  texcl=true, 
+  escapechar=@,
+  numberblanklines=false}
+ \newcommand{\sem}[1]{\llbracket{#1}\rrbracket}
+
+This appendix can be safely ignored and is not necessary to understand
+the approach described in the report. Its main purpose is to give a
+precise definition of the encoding from AltaRica to Fiacre that is
+only roughly described in Sect.~\ref{sec:sect3}.
+
+We give a more precise definition of our encoding from AltaRica
+Dataflow to Fiacre. We base our definition on a simplified grammar for
+AltaRica Dataflow, using the Cecilia OCAS syntax, and a ``semantics
+function'' (denoted $\sem{\,}$) to translate an AltaRica expression
+into Fiacre. The encoding uses an environment, $\sigma$, to map event
+identifiers (\code{evt}) to their timing constraints (defined in the
+\code{extern} heading). We omit this environment when it is obvious
+from the context.
+
+We describe the grammar of the AltaRica language using a variant of
+Extended Bachus Naur Form (EBNF). The EBNF describes a set of
+production rules of the form ``\code{symb ::= expr}'', meaning that
+the nonterminal symbol \code{symb} represents anything that can be
+generated by the EBNF expression \code{expr}. An expression
+\code{expr} may be one of the following: a terminal symbol or keyword,
+between quotes (e.g., \code{'event'}); a nonterminal symbol; an
+optional expression, written ``\code{[ expr0 ]}''; a choice between
+two expressions, written ``\code{expr1} $\,\mid\,$ \code{expr2}''; the
+iterative concatenation of one or more expressions, with successive
+occurrences being separated by a given symbol \code{s}, written
+``\code{(expr s)*}''.
+
+
+\subsection*{Types}
+\label{sec:types}
+
+AltaRica base types include ``Boolean'' and Integers. We do not
+consider floating point number in our translation; even though real
+numbers are useful to declare probabilities, floating point variables
+do not fit well with an enumerative model-checking approach. The
+language also provides enumeration types, called \emph{domains}, that
+defines sets of symbolic constants that can be used with state
+variables.
+
+\begin{lstlisting}[language=BNF]
+Type   ::= 'Boolean' | 'Integer' | Ident
+Domain ::= 'domain' Ident '{' (Ident ',')* '}'
+\end{lstlisting}
+
+Fiacre supports a boolean type \code{bool}, with the same primitive
+operators than AltaRica, equality (\code{=}) and inequality
+(\code{<>}), and a ternary conditional operator. The numeric types of
+Fiacre include the type \code{int} of all integers and the the type
+\code{nat} of non negative integers. As we stated in
+Sect.~\ref{sec:sect3}, domains can be directly encoded using union
+types in Fiacre.
+
+\begin{lstlisting}[language=BNF]
+[[Boolean]] = bool       [[Integer]] = int       [[Ident]] = Ident
+[[domain IType {I1 , ..., In}]] = type IType is union I1 | ... | In end ;
+\end{lstlisting}
+
+The fact that we can directly reuse the same type identifier in the
+two languages means that we can directly reuse AltaRica type
+declarations in Fiacre. Indeed, a type declaration of the form
+\code{V1 : T1, ..., Vn : Tn} is encoded in Fiacre  as follows:
+%
+\lstinline[language=BNF]{V1 : [[T1]], ..., Vn : [[Tn]]}
+
+Note that a limitation of Fiacre type declarations is that all type
+constructors must be different, therefore we assume that the constants
+used in different domains are always distinct. (This restriction
+could be lifted by renaming constants using some information from the
+type checker, but this has no effects on the expressiveness of our
+approach.)
+
+\subsection*{Instructions}
+\label{sec:instructions}
+
+Instructions are used to described the actions (postcondition) of
+transitions and assertions. There are fundamentally four instructions:
+skip, assignments, if-then instructions and composition. All the
+possible instructions in AltaRica can be rewritten using only these
+four fundamental instructions. A notable example of instruction
+missing in this short list is the switch statement (that can be
+encoded using nested conditionals). Fiacre provides an equivalent
+\code{case}-statement that can be used to do traditional
+pattern-matching.
+
+\begin{lstlisting}[language=BNF]
+Instr ::= 'skip' | V ':=' Expr | 'if' Expr 'then' Instr | '{' (Instr)* '}
+\end{lstlisting}
+
+Expressions, \code{Expr}, are built using the variables, constants and
+the usual arithmetic operators. The syntax of expressions is exactly
+the same as in Fiacre, so we have
+%
+\lstinline[language=BNF]{[[Expr]] = Expr}.
+
+The equivalent of instructions in Fiacre is called statement.  The
+\code{skip} instruction is a ``neutral element''; it describes the
+instruction that does nothing. Fiacre has an equivalent notion with
+the statement \code{null}. Assignments and conditionals are also
+present in Fiacre, with the same semantics. The main difference is
+that we do not enforce any differences between flow and state
+variables.
+
+\begin{lstlisting}[language=BNF]
+[[skip]]               = null 
+[[V := Expr]]          = V := [[Expr]]
+[[if Expr then Instr]] = if [[Expr]] then [[Instr]] end
+[[{I1 ... In}]]        = [[I1]] ; ... ; [[In]]
+\end{lstlisting}
+
+The interpretation of AltaRica instructions is straightforward. The
+main discrepancy is with composition. For most practical purposes,
+composition in AltaRica can be encoded using sequential
+composition. In the case where different statements in a composition
+update the same variable, it could be necessary to introduce temporary
+variables, but this can be already enforced in the original AltaRica
+instruction. For example, the composition \code{\{(X := Y) (Y :=
+  X)\}}, that can be used to swap the values of two variables in
+AltaRica, should be replaced by the instruction \code{\{(TEMP := X) (X
+  := Y) (Y := TEMP)\}}.
+
+\subsection*{Nodes}
+
+An AltaRica model is essentially a collection of node declarations. A
+node is made of three parts: declaration of state variables, flow
+variables and events; declaration of transitions; and finally
+assertions.
+
+\begin{lstlisting}[language=BNF]
+Node   ::= 'node' Ident Flow State Event Init Trans Assert [Extern]
+Flow   ::= 'flow' (Ident ':' Expr ':' ('in' | 'out') ',')* ';'
+State  ::= 'state' (Ident ':' TypIdent ',')* ';'
+Event  ::= (Ident ',')* ';'
+Init   ::= 'init' Expr ';'
+Trans  ::= 'trans' (Expr v- Ident -> Expr ';')* 
+Assert ::= 'assert' Expr ';'
+\end{lstlisting}
+
+In the following, we assume that we want to encode a node \F{} with
+flow variables declaration \code{flow V1 : T1, ..., Vk : Tk;} and
+state variables declaration \code{state S1 : I1, ..., Sn : In;}.  Our
+encoding makes use of a Fiacre record type, \code{Flows}, defined as
+follows.
+
+\begin{lstlisting}[language=BNF,mathescape=true]
+type Flows is record V1 : [[T1]], ..., Vk : [[Tk]] end
+\end{lstlisting}
+
+The type \code{Flows} is used to define a function computing the
+effect of assertions on the flow variables. The behaviour of
+assertions is one of the main differences between dialects of
+AltaRica. The case of AltaRica Dataflow is the simplest since, by
+definition, there should be a fixed order (computable at compile time)
+in which to evaluate the assignments defined in the \code{assert}
+heading. In this case, if the node declares an assert expressions
+\code{assert exp;} then we assume that the Fiacre function
+\code{update} is declared as follows, where \code{((exp))} is the
+Fiacre expression $\llbracket$\code{exp}$\rrbracket$ in which every
+occurrence of flow variables, \code{Vi}, are replaced with a record
+field access, \code{f.Vi}.
+
+\begin{lstlisting}[language=BNF,mathescape=true]
+function update(S1 : I1, ..., Sn : In, env : Flows) : Flows is
+   var f : Flows := env
+   begin
+      ((exp))
+      return f
+   end
+\end{lstlisting}
+
+Other dialects of AltaRica may require a fixpoint computation, or at
+least a recursive evaluation of the \code{assert} expression. This
+different semantics could be encoded in Fiacre as well. Indeed Fiacre
+functions can be recursively defined. For better performances, it is
+also possible to implement the computation of assertions in an
+external library and to import it in Fiacre using Foreign Function
+Interfaces.
+
+The definition of the node may also contain timing constraints
+declared using an \code{extern} clause. A timing constraint is a
+(time) interval of the form \code{[a, b]}, \code{]a, b]}, \code{[a,
+  b[}, or \code{]a, b[}. An interval of the form \code{[a, ...[} is
+used to denote an unbounded interval (that is a $\infty$-bound).
+
+\begin{lstlisting}[language=BNF]
+Extern ::= 'extern'  ('law' '(' Ident ')' '=' '"' Time '"' ';')*
+Time   ::= Left ',' Right
+Left   ::= '[' Int | '[' Int
+Right  ::= Int ']' | Int '[' |  '...' '['
+\end{lstlisting}
+
+When there is a declaration \code{extern law(evt) = "Time";} in the
+definition of the node \F{}, we assume that the environment $\sigma$
+is such that $\sigma$(\code{evt}) = \code{Time}. If an event is not
+declared in the \code{extern} heading then we can safely assume that it
+is associated with the time constraint \code{[0, ...[}.
+
+Equipped with all these additional definitions, it is possible to
+encode every transition declared in \F{} into a Fiacre statement. In
+particular, each transition of the form
+%%
+\lstinline[language=Altarica]{g |-evt-> Exp ;}.
+%%
+in the AltaRica code can be encoded into Fiacre as a sequence of a
+conditional (a test on the guard \code{g}); followed by an action
+(evaluation of the expression $\llbracket$\code{exp}$\rrbracket$);
+finished by the evaluation of assertions. In this example we assume
+that the transition \code{evt} is associated with the time interval
+$I$, that is $\sigma(\text{\code{env}}) = \text{I}$.
+%%
+\begin{lstlisting}[language=BNF,mathescape=true]
+[[evt]] = #evt; wait $\text{I}$; on(g); [[Exp]]; env := update(S1, ..., Sn, env); loop
+\end{lstlisting}
+
+Our encoding makes use of some assumptions that were not introduced
+previously. Like in the example of Sect.~\ref{sec:sect3}, we encode a
+node as a Fiacre process with a unique state. The statement
+\code{loop} is used in Fiacre to declare that the target (the
+destination state) of the transition is the same as its source. The
+expression \verb+#+\code{evt} is a way to associate a ``tag'' with a
+Fiacre transition. Tags give an alternative way to name transitions in
+a temporal logic formula (for model-checking) and when we print or
+simulate a counterexample. In a nutshell, we use tags as a simple
+mechanism for traceability between the AltaRica and Fiacre code.  
+
+With all the definitions introduced in this section, the encoding of
+node \F{}, with transitions \code{evt1, ..., evtk}, boils down to a
+single Fiacre process. To conclude, we simply need to create a
+top-level component that creates an instance of this process and
+initializes the state and flow variables. In the following listing, we
+assume that \code{Expi} corresponds to the (AltaRica) expression
+associated with the state variables \code{Si} in the \code{init}
+heading of \F{}. In this code, we use the \code{init} declaration of
+Fiacre that allows us to initialize the value of the flow variables in
+the initial state.
+
+%,float=hbt,frame=single,captionpos=b,caption=\protect{Code
+%skeleton for the interpreation of the Node \F{} in  Fiacre}]
+\begin{lstlisting}[language=BNF]
+type Flows is record V1 : [[T1]], ..., Vk : [[Tk]] end
+
+function update(S1 : I1, ..., Sn : In, env : Flows) : Flows is
+   var f : Flows := env
+   begin
+      ((exp))
+      return f
+   end
+
+process F(&S1 : I1, ..., &Sn : In, &env : Flows) is
+   states s0
+
+   init 
+      env := update(S1, ..., Sn, env);
+      to s0
+ 
+   from s0 select
+      [[evt1]] [] ... [] [[evtk]]
+   end
+
+component Main is
+   var env : Flows,
+       S1  : I1 := [[Exp1]],
+       ...,
+       Sn  : In := [[Expn]]
+
+   par F(S1, ..., Sn, env) end
+\end{lstlisting}
+
+
+
+
+\section{Method and translation}\label{sec:sectB}
+
+\subsection{Time Petri Nets}
+Petri Nets are bi-partite graphs with two classes of nodes: places and transitions.
+Time Petri Nets are en extension to classical Petri nets that include time features, % TODO Cite Merlin
+namely two real numbers, $a$ and $b$, with $a < b$, that label each transition and indicate the time interval a transition is active, being \emph{de facto} a temporal guard.
+
+	\begin{definition}[Time Petri Nets]\label{def:TPN}
+	A time Petri net (TPN) is a tuple  $\langle P, T, B, F, M_0, \tau \rangle $ where:
+	\begin{itemize}
+		\item $P$ is a finite nonempty set of places $p_i$;
+		\item $T$ is a finite nonempty set of transitions $t_i$;
+		\item $F$ is the flow relation 
+		$ F : P \times T \to P$
+		\item $M_0$ is the initial marking function
+		$ 	M_0 :P \to \mathbb{N} $
+		\item $\tau$ is a mapping called static (firing) interval for transitions
+		$ 	\tau : T \to \mathbb{R}^+_0 \times (\mathbb{R}^+_0 \cup \infty) $
+	\end{itemize}
+
+
+%	\item $B$ is the backward incidence function
+%$ B:T\times P \to  \mathbb{N}$
+%\item $F$ is the forward incidence function
+%$ F:T\times P \to P\times T $
+%% However, as new markings via a transition t_i are given by 
+%% M'(p) = M(p) - B(t_i,p) + F(t_i,p) for all p
+% The function F resumes and simplifies this transition, associating to a set of places and enabled transitions (i.e. a state), a set of places and enabled transitions.
+% The current marking $M$ of a TPN is obtained from the transitions history $t_1, \ldots t_n$, s.t. $ M = t_n \circ t_1(M_0)$,
+% with the new marking $M'$, calculated from a transition $t$ and a marking $M$ is given by
+% M' = M - prec(p) + post(p)
+	\end{definition}
+For reference, the tuple  $\langle P, T, F, M_0\rangle $ identifies a Petri net.
+
+A transition $t \in T$ is \emph{fireable} when all its input places have at least one token; for sake of simplicity, we do not consider here weights on transitions, as the result is similar, with just a change in the marking calculation.
+The flow relation then associates to the number of tokens in a place (which we call $w: P \to \mathbb{N}$ a function of the place) and a fireable transition, the tokens in the target place.
+
+
+\subsubsection{States in a TPN}
+
+The dynamic aspects of Petri net model are denoted by
+markings which are assignments of tokens 
+to the places of a Petri net. The execution  is then derived  from the number and emplacements of tokens. 
+
+Given the definition above, a state in a TPN is given by the pair $(M,I)$, where 
+the marking $ M = \{m = w(p)\,|\, p \in P\}$ can be seen as a vector of markings,
+and
+% the temporal constraints on each active transition $TC= (\theta_{min}, \theta_{max})$
+the firing interval set is $I = \{\tau(t)\:|\:t\in T\}$, which can be seen as a vector of firing intervals for the fireable transitions~\cite{berthomieu1991TPN}.
+
+
+
+Over TPN states and transitions between them, it is possible to define an \emph{extended state graph}\cite{yao},
+which root corresponds to the state coming from the initial marking and fireable transitions
+%
+The new markings are computed as usual, by applying $F$ on the marking of the current state, and,
+similarly, the new firing interval is computed consequently, for a more detailed description refer to \cite{berthomieu1991TPN}.
+Thus, the transition rules permit to compute states and state reachability.
+
+% The reachable states from a state $S = (M,I)$
+% are the states $S'$ such that, $\forall t \in I$ (the transitions fireable) at time $\theta$ leading to state $S'$.
+
+\subsection{From AltaRica to Tina}
+The underlying mathematical model of the AltaRica language is a Guarded Transition System (GTS), an automaton that generalises Reliability Block Diagrams, Markov chains and Stochastic Petri nets~\cite{rau08}. In GTS, states are represented by value assignment to variables, while the states transitions are triggered by events, that change the variables value. Synchronisation between events (habitually asynchronous) is produced by introducing a new event.
+
+Given that it is always possible to obtain a flattened model from a
+composition of interconnected AltaRica nodes, it is then possible to
+interpret a (general) AltaRica model by using the GTS model encoding.
+Our translation approach relies on Extended Timed Guarded Transition System (ETGTS), an extension of the GTS of AltaRica opportunely enriched to include timed guards.
+
+Expressing durations over event and non-deterministic transitions triggered by temporal guards, fall out of the AltaRica Dataflow expressiveness and thus cannot be captured nor analysed by its associated tool. %which can treat time as a set of delay assignment, i.e. with a fixed delay associated to each transition.
+So, we enriching the syntax of AltaRica Dataflow to model temporal guarded transitions by adding a new event law, as defined in Def.~\ref{def:ETGTS}.
+
+
+\begin{comment}
+%%%%start comment
+\begin{definition}[ETGTS]\label{def:ETGTS}
+  An Extended  Timed Guarded Transition System is a tuple $\langle S, s_0, E, T, \tau \rangle $ where:
+  \begin{itemize}
+  \item $S$ is a set of states;
+    \item $s_0 \in S$ is the initial state;
+  \item $E$ is a set of event symbols;
+    \item $T$ is  a set of transitions s.t. $T \subseteq S \times E \times S$. 
+    \item $\tau$ is the delay relation, $\tau: E \to \mathbb{R}^+ \times (\mathbb{R}^+  \cup \infty)$, assigning a minimal and a maximal delay to the transitions bound to event $e$.
+  \end{itemize}
+  A transition $t \in T: (s, e, s')$ associates a state $s'$, to a state $s$ by executing the event $e$ in $s$, after a delay in the interval $[\delta_{min}, \delta_{max}]$ given by $\tau(e)$.
+      
+    A \emph{run}  $\rho$ of a timed Transition System is a sequence of pairs event-time from the initial state $s_0$:
+    \begin{align*}
+      \rho &= \{ (e_1,\delta_1), \ldots, (e_n,\delta_n)  \} \; 
+      \text{s.t. } \forall i \;\delta_i \in \tau(e_i), \text{ and }\\
+      &s_0 \xrightarrow{t_1} s_1 \xrightarrow{t_2}\cdots \xrightarrow{t_n} s_n, \text{ with }  \forall i \;t_i = (s_{i-1}, e_i, s_i) \in T
+      \end{align*}
+\end{definition}
+
+
+\TODO{TGTS for us, as delta can be used, but not necessary}
+
+\begin{definition}[GTS]\label{def:GTS}
+  A GTS is a tuple $\langle V,E,T, A, \nu \rangle $ where:
+  \begin{itemize}
+  \item $V$ is a set of variables, divided in two sets of variables: the set $S$ of \emph{state variables}, and $F$ of \emph{flow variables} s.t. $V = S \cup F.$
+  \item $E$ is a set of event symbols
+    \item $T$ is  a set of transitions, s.t. $t \equiv (\gamma, e, \varphi) \in T$ with $e \in E$, $\gamma$ and $\varphi$ are Boolean  expressions built over $V$ called \emph{guard} and \emph{post-condition} resp. A transition $t$ applies in a state $s \in 2^{|V|}$ s.t. $s \models \gamma$, resulting in a state $s' \models \varphi$.
+    \item $A$ is the set of \emph{assertions}, i.e.  Boolean expressions built over $V$. Assertions are concatenated to each transition, in order to update flow variables, \TODO{modelling the failure propagation. }
+    \item $\nu$ is the initial assignment of variables of $V$.
+  \end{itemize}
+  \end{definition}
+
+\TODO{1) define the semantics of a transition, i.e. how to pass from a state $\sigma$ to a state $\rho$. 2) define a trace in the timed graph, with events labelled by the firing time, i.e. a plan for Tina}
+
+A GTS is a (possibly infinite) graph $\Gamma = (\Sigma, \Theta)$, where $\Sigma$ is a set of nodes given by all the possible variable assignments in $V$, and $\Theta$ is a set of guarded transitions $(\sigma, e, \rho)$, where $\sigma, \rho \in \Sigma$ and $e \in E$.
+
+blocks and processes, from the GTS to the Petri Net (states, places, tokens).
+
+\begin{definition}[Temporal GTS]\label{TTGTS}
+\TODO{Timed GTS already exist, we can use another name to avoid confusion}
+A Temporal Guarded Transition System is a tuple $\langle V,E,T, A,\nu, \Delta \rangle$ where
+  \begin{itemize}
+  \item $\langle V,E,T, A, \nu \rangle $ is a GTS defined as in Def.~\ref{def:GTS}
+  \item $\Delta$ is a delay function s.t. $\Delta: E \to \mathbb{R}^+ \times \mathbb{R}^+$, assigning an initial and a final firing time to the transitions bound to event $e$.
+  \end{itemize}
+\end{definition}
+
+
+\TODO{Next paragraph is possibly untrue, as TGTS can be modified such to include delay \emph{functions} as we did with Fiacre and Petri Nets. We can say that these delays are instantaneous, when we aim at timed guards}
+However, the limitation of the GTS formalism resides in the lack of expressivity wrt the delays in failure propagation.
+In timed Guarded Transition Systems -- an extension of GTSs -- a delay function is associated to each event, indicating the date when the event occurs. However,  the propagation of messages, as failures, dealt by assertions, are not included in the (state) transitions that are delayed.
+
+in the case of flow variables, they are updated in AltaRica simultaneously, as they represent the instantaneous propagation of a message in a system. Here, adding delays in such transitions, cannot be directly done within the AltaRica models, so we had to hack it.
+We introduced \say{delay buffers}, which, in the AltaRica modelling, have a flow variable as input, a delayed state transition, and an output, which value depends on the state variable, which has been updated only after a delay. See Fig.~\ref{fig:delay-buffer}
+
+
+
+The extension to temporal guards on the transitions expressed by the ETGTS falls out of the AltaRica expressiveness, so cannot be captured nor analysed by its associated tool, which can treat time as a set of delay assignment, i.e. with a fixed delay associated to each transition.
+% Thus, the aforedefined Extended Temporal GTS is obtained from the AltaRica DataFlow model, by enriching it the syntax for temporal guarded transitions, i.e. by adding delays as defined in Def.~\ref{def:ETGTS} to the transitions in a new event law.
+\end{comment}
+
+\subsection{Factored model of ETGTS}
+Representing the whole state space can be costly. For this reason, instead of describing the ETGTS as a state space, it is preferable to define a factored version of
+the ETGTS, and describing the associated semantics.
+
+AltaRica separates flow variables and state variables.
+% State variables are modified by transitions, i.e. explicit changes of system configuration.
+%
+Delayed transitions affecting state variables are trivially extended to include a temporal interval in the guard matching the non-deterministic delay we plan to add. Flow variables are updated by assertions in AltaRica models, but this distinction between variables  does not appear in the associated  GTS; thus, in order to assign delays assertions, a auxiliary state variables and transitions are used to create a (delayed) state transition.
+
+Let be $V$ a finite set of variable, possible multi-valued, and let be $\sigma$ the function that associates to each variable its finite domain.  
+Thus, a variable assignment is here a function $f: V \to \sigma(v)$ for $v \in V$, associating to each $v \in V$ its value $f(v)$.
+A state in $S$ is then a  assignment of all variables $v \in V$. As syntactic sugar, we can express the evaluation of an expression $\epsilon$ over $V$
+in a state $s$ by considering $s(\epsilon)$.
+
+\begin{definition}[Factored ETGTS]\label{def:factored-ETGTS}
+  A GTS is a tuple $\langle V, O, I, \Delta\rangle $ where:
+  \begin{itemize}
+  \item $V$ is a set of variables, possibly multivalued, divided in two sets of variables: the set $St$ of \emph{state variables}, and $Fl$ of \emph{flow variables} s.t. $V = St \cup Fl.$
+  \item $O$ is  a finite set of operators, where each operator consists in
+    \begin{itemize}
+    \item a Boolean  expressions $\Gamma$ built over $V$ called \emph{guard};
+    \item a  \emph{post-condition} instruction,  a partial variable assignments $\P$. Post-conditions where the left members of the assignment are only state variables are referred as \emph{transitions}. Post-conditions where the left members of the assignment are only flow variables are referred as \emph{assertions}. 
+      \end{itemize}
+  \item $I$ is the initial assignment of variables of $V$.
+  \item $\Delta$ is a delay function s.t. $\Delta: O \to \mathbb{R}^+ \times \mathbb{R}^+$, assigning an initial and a final firing time to the operators. We consider that, when not defined, the effects of the operators are instantaneous.
+
+  \end{itemize}
+  \end{definition}
+
+We say that an operator $<\Gamma, P>$ is fireable in a state $s$ when the guard holds in $s$, i.e.
+the variable assignment in $s$ is such that $s \models \Gamma$.
+Assertions are concatenated to each transition, in order to update flow variables.
+Thus, applying an operator in a state $s$ leads to a new state $s'$, obtained by applying first $P$ then the assertions to the variables in $s$ . % P(s)
+
+\subsubsection{Semantics of a ETGTS}
+
+
+The semantics of a Temporal Extended GTS, associated to the above definition  is a Kripke structure $\langle S, S_0, \to \rangle$ defining an oriented graph,  where edges are labelled by the events, and their associated delays.
+
+\begin{definition}[Semantics of ETGTS]\label{def:ETGTS}
+  An Extended  Timed Guarded Transition System is a tuple $\langle S, s_0, E, T, \tau \rangle $ where:
+  \begin{itemize}
+  \item $\mathcal{S} = S \cup \mathbb{R}_0^+$ is a set of states;
+  \item $\mathcal{S} _0 = s_0 \cup \{0\} \in S$ is the initial state;
+  \item $E$ is a set of event symbols;
+  \item $\tau$ is the delay relation, $\tau: E \to \mathbb{R}^+_0 \times \mathbb{R}^+_0$, assigning a minimal and a maximal delay to the transitions bound to event $e$.
+  \item $\mathcal{T}$ is  a set of transitions s.t. $\mathcal{T} \subseteq \mathcal{S} \times E \times \mathcal{S}$. For sake of simplicity, we consider two different kinds of transitions that can be associated to an event $e$:
+    \begin{itemize}
+    \item  transitions $s \xrightarrow{t} s'$, associating to a state $<s,  \theta>$ a new state $<s', \theta>$, whith $t = (s, e, s')$
+    \item timed transitions $s \xrightarrow{\theta} s'$, associating to a state $<s,  \theta>$ a new state $<s, \theta + \delta>$, whith $\delta \in \tau(e)$
+    \end{itemize}
+  \end{itemize}
+%  A transition $t \in T: (s, e, s')$ associates a state $s'$, to a state $s$ by executing the event $e$ in $s$, after a delay in the interval $[\delta_{min}, \delta_{max}]$ given by $\tau(e)$,
+%  such that $t = (s, e, s')$ and $$
+      
+    A \emph{firing schedule}  $\rho$ of a timed Transition System is a sequence of pairs event-time from the initial state $s_0$:
+    \begin{align*}
+      \rho &= \{ (e_1,\delta_1), \ldots, (e_n,\delta_n)  \} \; 
+      \text{s.t. } \forall i \;\delta_i \in \tau(e_i), \text{ and }\\
+      &s_0 \xrightarrow{t_1} s_1 \xrightarrow{t_2}\cdots \xrightarrow{t_n} s_n, \text{ with }  \forall i \;t_i = (s_{i-1}, e_i, s_i) \in T
+      \end{align*}
+\end{definition}
+\subsubsection{Translation}
+
+The states are of the form of $<s, \theta>$, where $s \in S$ is a total assignment and $s_0$ is the initial assignment of variables in $V$;
+$\theta$ is a real positive number.
+Thus, transitions associate to pair $<s, \theta>$ other pairs  $<s', \theta'>$. % a transition $t in T$ 
+
+
+The translation from the ETGTS to an TPN is straightforward.
+
+A state in the  ETGTS represents the marking of the TPN, so
+we can associate to each variable assignment in a state of the ETGTS, tokens in a state of the TPN,
+with the initial state $\mathcal{S} _0$ defining the initial markup $M_0$.
+The set of events $\{e | e \in E\}$ are mapped in the set of transitions $\{t_e \in T| e \in E\}$ in the TPN,
+with an arc $(s, e, s')$ corresponding to % $\{p' | v_p \in s \text{ and } F(p, t_e) \neq 0\}$,
+the marking $M'$ resulting from the set of markings obtained by applying  the transition $t_e$ to the set all the places with a not null token that activate the transition (i.e. $M$).
+Wrt to the timed transitions
+the firing interval $I'$ after a transition $t_e$ is obtained from the set of transitions in ETGTS that are fireable at $\theta'$ ( the timing obtained in the ETGTS after applying $e$ in  $<s, \theta>$)
+such that $I' = \{\tau(t_e)\: | \: \theta' \in \tau(t_e) \}$.
+
+Such transitions affect state variables only, while flow variables are updated simultaneously only if are kept, possibly adding them a delay.\TODO{ (dessin de la fleur)}
+
+It is easy to see that the translated ETGTS is made of a single place and $n$ transitions, where $n$ corresponds to the number of state transitions in the initial model. We can ask ourselves if there is a more compact alternative to such a ``monolithic'' Petri Net. By enumerating the states in the model, we could create a ``stateful'' Petri net with a place for each reachable state, with the relative transitions. Another alternative for our translated model, would be to use a ``concurrent'' model, using different blocks for the different AltaRica nodes.
+
+In the worst case scenario, the number of transitions of the monolithic Petri net would be equal to the possible variable assignment;
+when considering Boolean variables only, the possible truth values assignment to $k$ variables would be $2^k$.
+On the other side, if we consider the stateful model, we would end up, in the worst case, with $2^k$ places and the same amount of transitions.
+Using the concurrent Petri net, we could obtain $n2k$ places (with $n$ the number of AltaRica nodes) which, in the worst case, would end up with $n2^k$ transitions and states. This worst case analysis yields to the fact that the simple monolithic Petri net is the more compact way to represent the original AltaRica model.
+
+
+%%%% Comment on how do we create a buffered block to transmit faults
+\begin{comment}
+
+% It is easy to see from Def.~\ref{def:ETGTS} and Def.~\ref{def:PN} that any Petri Net can be modelled as a GTS~\cite{rau08}. % Any GTS in Petri Net?
+
+
+
+While transitions affecting the state variables updates support a direct expression of the delay in AltaRica (and hence in ETGTS as well), flow variables are updated by assertions, that natively do not support delays. To express a delayed failure affecting an input/output variable (a flow variable) auxiliary state variables and transitions have to be used to model the delay and the failure buffer. Thus, a delay element will depend on three parameters $(k, \delta_1, \delta_2)$, where $\delta_1$ and $\delta_2$ are indicate the minimal and the maximal delay (resp.), and $k$ indicates the maximal buffer for the element.
+
+\TODO{Following example is useless, as it has been explained clearly in the former sentence}
+\subsubsection{Example}
+Given a failure propagation represented by a flow variable $v$ as input $v_i$ of an element, the assertion $a$ updating these values would be such that $v_i = v$. To introduce a  delay between $d_e$ and $d_e'$, we add to the AltaRica model two auxiliary state variables $w, w'$, and two new events $e$ and $e'$.
+The event $e$ is instantaneous s.t. $\Delta(e_d) = (d_e, d_e')$, and the resulting transition assigns $w = v$.
+The event $e_d$ is delayed s.t. $\Delta(e_d) = (d_e, d_e')$, and the resulting transition assigns $w' = w$.
+The following assignments are added as assertions: $a': w' = w$, $a'': v_i = w'$. The result is delay of a value comprised in the interval $[d_e, d_e']$ between the assignment $w = v$, and the propagation to change the value of $v_i$.
+
+In OCAS, to produce such a model, N delay elements has to be created, with N the size of the buffer. This is automatised in our tool-chain, as the code corresponding to the delay element for $(k, \delta_1, \delta_2)$ is generated in Fiacre from the AltaRica code (where only the delay is indicated, while the buffer size $k$ is calculated from the elements uphill.
+% NB: We can say that if the value v is new, THEN we update w. but can be more confusing.
+
+\subsection{From Timed GTS to Timed Petri Nets}
+\TODO{1) Get definition of timed Petri Nets, 2) define the translation\\}
+We build a state $s_0$, s.t. for each transition $t \in T$ in the TGTS, a transition $t \circ a$ from $s_0$ to $s_0$ is added in the TPN. Eventual delays are maintained.
+It is easy to see that such transitions affect state variables only, while flow variables are updated simultaneously only if are kept, possibly adding them a delay. (dessin de la fleur)
+
+
+For each delayed transition affecting a flow variable, e.g. a delay in the failure propagation in our example, we add a new element working as a buffer delaying the input messages.
+
+
+Introducing the delay, synchronisation, and new states
+1) first in OCAS;
+2) AltaRica code generated with timed transitions;
+3) Fiacre code, with temporal guards (from the timed transitions expressed before).
+
+Equivalence between the AltaRica models with no stochastic information, i.e. in Fiacre probabilities are abstracted away. Trivial to see that, when guards on transitions are conserved. Then, the time information is not part of the AltaRica models, and has there been artificially introduced for our purpose of taking trace of it during the translation. (taking trace of the transition names, for traceability purpose).
+
+
+\end{comment}
+%%% end comment
+
+
+\section{Command line}
+
+Sources du projet disponibles sur (C++):
+
+\url{http://git-ingequip.pf.irt-aese.local/diffusion/TALTARICA/}
+
+Benchmarks (utilisés entre autre pour l'article IMBSA 2017):
+
+\url{http://git-ingequip.pf.irt-aese.local/diffusion/TALTARICA/browse/master/altarica\_epoch/benchmarks/models/}
+
+
+In the IRT repository, we have:
+
+v.1.0-erts18  The version used for ERTS.
+ 
+v.1.1  Current version. Some bugs corrected
+
+Known bugs of v.1.0-erts18 
+
+Error in printing the guards of synchronized transitions: adds and 'and' at the end of the line when there are empty guards)
+Duplicated syncronizations events
+
+
+to compile :
+/usr/bin/make KCFLAGS=-ggdb3 -Wdeprecated-declarations epochnogui
+
+to execute:
+
+ ./src/console/epochnogui --ds 0 --ps 0 --file <filename.alt> > <filename.fcr>
+
+%%  LocalWords:  TGTS Fiacre Dataflow OCAS ETGTS
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "main"
+%%% End:

doc/Rapport post-doc/dirtytalk.sty

@@ -0,0 +1,73 @@
+%%
+%% This is file `dirtytalk.sty',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% dirtytalk.dtx  (with options: `package')
+%% 
+%% M. Klammler, 2010
+%% 
+%% I, the copyright holder of this work, release the source code of the dirtytalk
+%% package as well as the accompaining documentation into the public domain. This
+%% applies worldwide.
+%% 
+%% In some countries this may not be legally possible; if so: I grant anyone the
+%% right to use this work for any purpose, without any conditions, unless such
+%% conditions are required by law.
+%% 
+
+\NeedsTeXFormat{LaTeX2e}
+\ProvidesPackage{dirtytalk}[2010/11/21 A package making "quoting" easier]
+\RequirePackage{kvoptions}
+\newcommand{\dirtytalk@lqq}{``}
+\newcommand{\dirtytalk@rqq}{''}
+\newcommand{\dirtytalk@lq}{`}
+\newcommand{\dirtytalk@rq}{'}
+\DeclareStringOption{left}
+\DeclareStringOption{right}
+\DeclareStringOption{leftsub}
+\DeclareStringOption{rightsub}
+\ProcessKeyvalOptions*
+\RequirePackage{ifthen}
+\ifthenelse%
+  {\equal{\dirtytalk@left}{}}%
+  {}%
+  {\renewcommand{\dirtytalk@lqq}{\dirtytalk@left}}
+\ifthenelse%
+  {\equal{\dirtytalk@right}{}}%
+  {}%
+  {\renewcommand{\dirtytalk@rqq}{\dirtytalk@right}}
+\ifthenelse%
+  {\equal{\dirtytalk@leftsub}{}}%
+  {}%
+  {\renewcommand{\dirtytalk@lq}{\dirtytalk@leftsub}}
+\ifthenelse%
+  {\equal{\dirtytalk@rightsub}{}}%
+  {}%
+  {\renewcommand{\dirtytalk@rq}{\dirtytalk@rightsub}}
+\newcounter{dirtytalk@qdepth}
+\newcommand%
+  {\dirtytalk@lsymb}%
+  {\ifthenelse%
+    {\value{dirtytalk@qdepth}>1}%
+    {\dirtytalk@lq}%
+    {\dirtytalk@lqq}%
+  }%
+\newcommand{\dirtytalk@rsymb}%
+  {\ifthenelse%
+    {\value{dirtytalk@qdepth}>1}%
+    {\dirtytalk@rq}%
+    {\dirtytalk@rqq}%
+  }
+\providecommand{\say}[1]%
+  {%
+    \addtocounter{dirtytalk@qdepth}{1}%
+    \dirtytalk@lsymb%
+    #1%
+    \dirtytalk@rsymb%
+    \addtocounter{dirtytalk@qdepth}{-1}%
+  }
+\endinput
+%%
+%% End of file `dirtytalk.sty'.

doc/Rapport post-doc/etgts.tex

@@ -0,0 +1,130 @@
+\section{Method and translation}\label{sec:sect3}
+
+\subsection{Temporal Petri Nets}
+
+
+\subsection{From AltaRica to Tina}
+The underlying mathematical model of the AltaRica language is a Guarded Transition System (GTS), an automaton that generalises Reliability Block Diagrams, Markov chains and Stochastic Petri nets~\cite{rau08}. In GTS, states are represented by value assignment to variables, while the states transitions are triggered by events, that change the variables value. Synchronisation between events (habitually asynchronous) is produced by introducing a new event.
+
+Given that it is always possible to obtain a flattened model from a
+composition of interconnected AltaRica nodes, it is then possible to
+interpret a (general) AltaRica model by using the GTS model encoding.
+Our translation approach relies on Extended Timed Guarded Transition system, an extension of the GTS of AltaRica opportunely enriched to include timed guards.
+
+
+\begin{definition}[ETGTS]\label{def:ETGTS}
+  An Extended  Timed Guarded Transition System is a tuple $\langle S, s_0, E, T, \tau \rangle $ where:
+  \begin{itemize}
+  \item $S$ is a set of states;
+    \item $s_0 \in S$ is the initial state;
+  \item $E$ is a set of event symbols;
+    \item $T$ is  a set of transitions s.t. $T \subseteq S \times E \times S$. 
+    \item $\tau$ is the delay relation, $\tau: E \to \mathbb{R}^+ \times \mathbb{R}^+$, assigning a minimal and a maximal delay to the transitions bound to event $e$.
+  \end{itemize}
+  A transition $t \in T: (s, e, s')$ associates a state $s'$, to a state $s$ by executing the event $e$ in $s$, after a delay in the interval $[\delta_{min}, \delta_{max}]$ given by $\tau(e)$.
+    An ETGTS defines an oriented graph, where delays can be seen as labels attached to the edges.
+    
+    A \emph{run}  $\rho$ of a timed Transition System is a sequence of pairs event-time from the initial state $s_0$:
+    \begin{align*}
+      \rho &= \{ (e_1,\delta_1), \ldots, (e_n,\delta_n)  \} \; 
+      \text{s.t. } \forall i \;\delta_i \in \tau(e_i), \text{ and }\\
+      &s_0 \xrightarrow{t_1} s_1 \xrightarrow{t_2}\cdots \xrightarrow{t_n} s_n, \text{ with }  \forall i \;t_i = (s_{i-1}, e_i, s_i) \in T
+      \end{align*}
+  \end{definition}
+
+
+\begin{comment}
+  %%%%start comment
+\TODO{TGTS for us, as delta can be used, but not necessary}
+
+\begin{definition}[GTS]\label{def:GTS}
+  A GTS is a tuple $\langle V,E,T, A, \nu \rangle $ where:
+  \begin{itemize}
+  \item $V$ is a set of variables, divided in two sets of variables: the set $S$ of \emph{state variables}, and $F$ of \emph{flow variables} s.t. $V = S \cup F.$
+  \item $E$ is a set of event symbols
+    \item $T$ is  a set of transitions, s.t. $t \equiv (\gamma, e, \varphi) \in T$ with $e \in E$, $\gamma$ and $\varphi$ are Boolean  expressions built over $V$ called \emph{guard} and \emph{post-condition} resp. A transition $t$ applies in a state $s \in 2^{|V|}$ s.t. $s \models \gamma$, resulting in a state $s' \models \varphi$.
+    \item $A$ is the set of \emph{assertions}, i.e.  Boolean expressions built over $V$. Assertions are concatenated to each transition, in order to update flow variables, \TODO{modelling the failure propagation. }
+    \item $\nu$ is the initial assignment of variables of $V$.
+  \end{itemize}
+  \end{definition}
+
+\TODO{1) define the semantics of a transition, i.e. how to pass from a state $\sigma$ to a state $\rho$. 2) define a trace in the timed graph, with events labelled by the firing time, i.e. a plan for Tina}
+
+A GTS is a (possibly infinite) graph $\Gamma = (\Sigma, \Theta)$, where $\Sigma$ is a set of nodes given by all the possible variable assignments in $V$, and $\Theta$ is a set of guarded transitions $(\sigma, e, \rho)$, where $\sigma, \rho \in \Sigma$ and $e \in E$.
+
+blocks and processes, from the GTS to the Petri Net (states, places, tokens).
+
+\begin{definition}[Temporal GTS]\label{TTGTS}
+\TODO{Timed GTS already exist, we can use another name to avoid confusion}
+A Temporal Guarded Transition System is a tuple $\langle V,E,T, A,\nu, \Delta \rangle$ where
+  \begin{itemize}
+  \item $\langle V,E,T, A, \nu \rangle $ is a GTS defined as in Def.~\ref{def:GTS}
+  \item $\Delta$ is a delay function s.t. $\Delta: E \to \mathbb{R}^+ \times \mathbb{R}^+$, assigning an initial and a final firing time to the transitions bound to event $e$.
+  \end{itemize}
+\end{definition}
+
+
+\TODO{Next paragraph is possibly untrue, as TGTS can be modified such to include delay \emph{functions} as we did with Fiacre and Petri Nets. We can say that these delays are instantaneous, when we aim at timed guards}
+However, the limitation of the GTS formalism resides in the lack of expressivity wrt the delays in failure propagation.
+In timed Guarded Transition Systems -- an extension of GTSs -- a delay function is associated to each event, indicating the date when the event occurs. However,  the propagation of messages, as failures, dealt by assertions, are not included in the (state) transitions that are delayed.
+
+in the case of flow variables, they are updated in AltaRica simultaneously, as they represent the instantaneous propagation of a message in a system. Here, adding delays in such transitions, cannot be directly done within the AltaRica models, so we had to hack it.
+We introduced \say{delay buffers}, which, in the AltaRica modelling, have a flow variable as input, a delayed state transition, and an output, which value depends on the state variable, which has been updated only after a delay. See Fig.~\ref{fig:delay-buffer}
+
+
+\end{comment}
+%%%%%% end comment}
+Thus, a Temporal Extended GTS models a graph with transitions labelled by events and by time.
+
+
+
+It is easy to see from Def.~\ref{def:ETGTS} and Def.~\ref{def:PN} that any Petri Net can be modelled as a GTS~\cite{rau08}. % Any GTS in Petri Net?
+
+The extension to temporal guards on the transitions expressed by the ETGTS falls out of the AltaRica expressiveness, so cannot be captured nor analysed by its associated tool, which can treat time as a set of delay assignment, i.e. with a fixed delay associated to each transition.
+Thus, the aforedefined Extended Temporal GTS is obtained from the AltaRica DataFlow model, by enriching it the syntax for temporal guarded transitions, i.e. by adding delays as defined in Def.~\ref{def:ETGTS} to the transitions in a new event law.
+
+AltaRica separates flow variables and state variables.
+% State variables are modified by transitions, i.e. explicit changes of system configuration.
+%
+Delayed transitions affecting state variables are trivially extended to include a temporal interval in the guard matching the non-deterministic delay we plan to add. Flow variables are updated by assertions in AltaRica models, but this distinction between variables  does not appear in the associated  GTS; thus, in order to assign delays assertions, a auxiliary state variables and transitions are used to create a (delayed) state transition.
+
+
+%%%% Comment on how do we create a buffered block to transmit faults
+\begin{comment}
+While transitions affecting the state variables updates support a direct expression of the delay in AltaRica (and hence in ETGTS as well), flow variables are updated by assertions, that natively do not support delays. To express a delayed failure affecting an input/output variable (a flow variable) auxiliary state variables and transitions have to be used to model the delay and the failure buffer. Thus, a delay element will depend on three parameters $(k, \delta_1, \delta_2)$, where $\delta_1$ and $\delta_2$ are indicate the minimal and the maximal delay (resp.), and $k$ indicates the maximal buffer for the element.
+
+\TODO{Following example is useless, as it has been explained clearly in the former sentence}
+\subsubsection{Example}
+Given a failure propagation represented by a flow variable $v$ as input $v_i$ of an element, the assertion $a$ updating these values would be such that $v_i = v$. To introduce a  delay between $d_e$ and $d_e'$, we add to the AltaRica model two auxiliary state variables $w, w'$, and two new events $e$ and $e'$.
+The event $e$ is instantaneous s.t. $\Delta(e_d) = (d_e, d_e')$, and the resulting transition assigns $w = v$.
+The event $e_d$ is delayed s.t. $\Delta(e_d) = (d_e, d_e')$, and the resulting transition assigns $w' = w$.
+The following assignments are added as assertions: $a': w' = w$, $a'': v_i = w'$. The result is delay of a value comprised in the interval $[d_e, d_e']$ between the assignment $w = v$, and the propagation to change the value of $v_i$.
+
+In OCAS, to produce such a model, N delay elements has to be created, with N the size of the buffer. This is automatised in our tool-chain, as the code corresponding to the delay element for $(k, \delta_1, \delta_2)$ is generated in Fiacre from the AltaRica code (where only the delay is indicated, while the buffer size $k$ is calculated from the elements uphill.
+% NB: We can say that if the value v is new, THEN we update w. but can be more confusing.
+\end{comment}
+%%% end comment
+
+
+
+\subsection{From Timed GTS to Timed Petri Nets}
+\TODO{1) Get definition of timed Petri Nets, 2) define the translation\\}
+We build a state $s_0$, s.t. for each transition $t \in T$ in the TGTS, a transition $t \circ a$ from $s_0$ to $s_0$ is added in the TPN. Eventual delays are maintained.
+It is easy to see that such transitions affect state variables only, while flow variables are updated simultaneously only if are kept, possibly adding them a delay. (dessin de la fleur)
+
+
+For each delayed transition affecting a flow variable, e.g. a delay in the failure propagation in our example, we add a new element working as a buffer delaying the input messages.
+
+
+Introducing the delay, synchronisation, and new states
+1) first in OCAS;
+2) AltaRica code generated with timed transitions;
+3) Fiacre code, with temporal guards (from the timed transitions expressed before).
+
+Equivalence between the AltaRica models with no stochastic information, i.e. in Fiacre probabilities are abstracted away. Trivial to see that, when guards on transitions are conserved. Then, the time information is not part of the AltaRica models, and has there been artificially introduced for our purpose of taking trace of it during the translation. (taking trace of the transition names, for traceability purpose).
+
+
+
+
+
+%%  LocalWords:  TGTS Fiacre DataFlow OCAS ETGTS

doc/Rapport post-doc/figures/Function2_1.svg

@@ -0,0 +1,271 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   width="78.256187mm"
+   height="41.567307mm"
+   viewBox="0 0 277.2857 147.28573"
+   id="svg2"
+   version="1.1"
+   inkscape:version="0.91 r13725"
+   sodipodi:docname="Function2_1.svg">
+  <defs
+     id="defs4">
+    <marker
+       inkscape:stockid="Arrow2Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="marker4597"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         id="path4599"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker4561"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Lend">
+      <path
+         transform="matrix(-0.8,0,0,-0.8,-10,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
+         id="path4563"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker4501"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Lend"
+       inkscape:collect="always">
+      <path
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path4503"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker4441"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow1Lend">
+      <path
+         transform="matrix(-0.8,0,0,-0.8,-10,0)"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
+         id="path4443"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker4501-0"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Lend"
+       inkscape:collect="always">
+      <path
+         inkscape:connector-curvature="0"
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path4503-9" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker4501-6"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Lend"
+       inkscape:collect="always">
+      <path
+         inkscape:connector-curvature="0"
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path4503-2" />
+    </marker>
+  </defs>
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="0.7"
+     inkscape:cx="-579.41219"
+     inkscape:cy="355.43353"
+     inkscape:document-units="px"
+     inkscape:current-layer="layer2"
+     showgrid="true"
+     showborder="false"
+     fit-margin-top="0"
+     fit-margin-left="0"
+     fit-margin-right="0"
+     fit-margin-bottom="0"
+     inkscape:window-width="1920"
+     inkscape:window-height="1018"
+     inkscape:window-x="1713"
+     inkscape:window-y="72"
+     inkscape:window-maximized="0">
+    <inkscape:grid
+       type="xygrid"
+       id="grid4155"
+       originx="-111.35713"
+       originy="-691.3572" />
+  </sodipodi:namedview>
+  <metadata
+     id="metadata7">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+        <dc:title></dc:title>
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     inkscape:label="Calque 1"
+     inkscape:groupmode="layer"
+     id="layer1"
+     transform="translate(-111.35714,-213.71933)"
+     style="display:inline">
+    <rect
+       style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:2.24441051;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+       id="rect4136"
+       width="125.66988"
+       height="89.241302"
+       x="190.0222"
+       y="242.3844" />
+    <circle
+       style="fill:#00a02b;fill-opacity:1;stroke:none;stroke-width:2.20000005;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+       id="path4159"
+       cx="253.9137"
+       cy="287.48911"
+       r="12.5" />
+    <g
+       id="g5678">
+      <path
+         sodipodi:nodetypes="ccc"
+         inkscape:connector-curvature="0"
+         id="path4138"
+         d="m 127.99999,261.93363 48.29193,0 10.99379,0"
+         style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1.29999995;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:3.4000001;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker4501)" />
+      <path
+         inkscape:connector-curvature="0"
+         id="path5533"
+         d="m 125.15944,261.79585 60,0 0,0"
+         style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4.4000001;stroke-dasharray:none;stroke-opacity:1" />
+    </g>
+    <g
+       transform="translate(0,50.000003)"
+       id="g5678-3">
+      <path
+         sodipodi:nodetypes="ccc"
+         inkscape:connector-curvature="0"
+         id="path4138-6"
+         d="m 127.99999,261.93363 48.29193,0 10.99379,0"
+         style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1.29999995;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:3.4000001;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker4501-0)" />
+      <path
+         inkscape:connector-curvature="0"
+         id="path5533-0"
+         d="m 125.15944,261.79585 60,0 0,0"
+         style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4.4000001;stroke-dasharray:none;stroke-opacity:1" />
+    </g>
+    <g
+       transform="translate(190.71429,25.000003)"
+       id="g5678-6">
+      <path
+         sodipodi:nodetypes="ccc"
+         inkscape:connector-curvature="0"
+         id="path4138-1"
+         d="m 127.99999,261.93363 48.29193,0 10.99379,0"
+         style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1.29999995;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:3.4000001;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker4501-6)" />
+      <path
+         inkscape:connector-curvature="0"
+         id="path5533-8"
+         d="m 125.15944,261.79585 60,0 0,0"
+         style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4.4000001;stroke-dasharray:none;stroke-opacity:1" />
+    </g>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-weight:normal;font-size:40px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="122.85715"
+       y="253.07648"
+       id="text5843"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan5845"
+         x="122.85715"
+         y="253.07648"
+         style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:40px;line-height:125%;font-family:'Liberation Serif';-inkscape-font-specification:'Liberation Serif, Normal';text-align:start;writing-mode:lr-tb;text-anchor:start">I1</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-weight:normal;font-size:40px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="122.75949"
+       y="352.36218"
+       id="text5843-5"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan5845-0"
+         x="122.75949"
+         y="352.36218"
+         style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:40px;line-height:125%;font-family:'Liberation Serif';-inkscape-font-specification:'Liberation Serif, Normal';text-align:start;writing-mode:lr-tb;text-anchor:start">I2</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-weight:normal;font-size:40px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="337.85715"
+       y="277.36218"
+       id="text5843-2"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan5845-9"
+         x="337.85715"
+         y="277.36218"
+         style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:40px;line-height:125%;font-family:'Liberation Serif';-inkscape-font-specification:'Liberation Serif, Normal';text-align:start;writing-mode:lr-tb;text-anchor:start">O</tspan></text>
+  </g>
+  <g
+     inkscape:groupmode="layer"
+     id="layer2"
+     inkscape:label="contour"
+     style="display:none"
+     transform="translate(3.5120392e-6,3.2654572e-6)">
+    <rect
+       transform="translate(-111.35714,-213.71933)"
+       style="display:inline;fill:none;fill-opacity:1;stroke:#00e100;stroke-width:1.90964365;stroke-miterlimit:4.4000001;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+       id="rect5873"
+       width="275.37607"
+       height="145.37608"
+       x="112.31196"
+       y="214.67415" />
+  </g>
+</svg>

doc/Rapport post-doc/figures/Function2_1.tex

@@ -0,0 +1,306 @@
+%LaTeX with PSTricks extensions
+%%Creator: inkscape 0.91
+%%Please note this file requires PSTricks extensions
+\psset{xunit=.5pt,yunit=.5pt,runit=.5pt}
+\begin{pspicture}(277.28570352,147.28573176)
+{
+\newrgbcolor{curcolor}{0 0 0}
+\pscustom[linewidth=2.24441051,linecolor=curcolor]
+{
+\newpath
+\moveto(78.66506154,118.62066234)
+\lineto(204.33494527,118.62066234)
+\lineto(204.33494527,29.37935985)
+\lineto(78.66506154,29.37935985)
+\closepath
+}
+}
+{
+\newrgbcolor{curcolor}{0 0.627451 0.16862746}
+\pscustom[linestyle=none,fillstyle=solid,fillcolor=curcolor]
+{
+\newpath
+\moveto(155.05655629,73.51595653)
+\curveto(155.05655629,66.61239716)(149.46011566,61.01595653)(142.55655629,61.01595653)
+\curveto(135.65299692,61.01595653)(130.05655629,66.61239716)(130.05655629,73.51595653)
+\curveto(130.05655629,80.4195159)(135.65299692,86.01595653)(142.55655629,86.01595653)
+\curveto(149.46011566,86.01595653)(155.05655629,80.4195159)(155.05655629,73.51595653)
+\closepath
+}
+}
+{
+\newrgbcolor{curcolor}{0 0 0}
+\pscustom[linewidth=1.29999995,linecolor=curcolor]
+{
+\newpath
+\moveto(16.64285,99.07143176)
+\lineto(64.93478,99.07143176)
+\lineto(75.92857,99.07143176)
+}
+}
+{
+\newrgbcolor{curcolor}{0 0 0}
+\pscustom[linestyle=none,fillstyle=solid,fillcolor=curcolor]
+{
+\newpath
+\moveto(62.03098996,104.83967288)
+\lineto(77.65499392,99.09433072)
+\lineto(62.0309891,93.34898981)
+\curveto(64.52705172,96.74103678)(64.51266935,101.38194574)(62.03098996,104.83967288)
+\closepath
+}
+}
+{
+\newrgbcolor{curcolor}{0 0 0}
+\pscustom[linewidth=0.89374997,linecolor=curcolor]
+{
+\newpath
+\moveto(62.03098996,104.83967288)
+\lineto(77.65499392,99.09433072)
+\lineto(62.0309891,93.34898981)
+\curveto(64.52705172,96.74103678)(64.51266935,101.38194574)(62.03098996,104.83967288)
+\closepath
+}
+}
+{
+\newrgbcolor{curcolor}{0 0 0}
+\pscustom[linewidth=3,linecolor=curcolor]
+{
+\newpath
+\moveto(13.8023,99.20921176)
+\lineto(73.8023,99.20921176)
+\lineto(73.8023,99.20921176)
+}
+}
+{
+\newrgbcolor{curcolor}{0 0 0}
+\pscustom[linewidth=1.29999995,linecolor=curcolor]
+{
+\newpath
+\moveto(16.64285,49.07142876)
+\lineto(64.93478,49.07142876)
+\lineto(75.92857,49.07142876)
+}
+}
+{
+\newrgbcolor{curcolor}{0 0 0}
+\pscustom[linestyle=none,fillstyle=solid,fillcolor=curcolor]
+{
+\newpath
+\moveto(62.03098996,54.83966988)
+\lineto(77.65499392,49.09432772)
+\lineto(62.0309891,43.34898681)
+\curveto(64.52705172,46.74103378)(64.51266935,51.38194274)(62.03098996,54.83966988)
+\closepath
+}
+}
+{
+\newrgbcolor{curcolor}{0 0 0}
+\pscustom[linewidth=0.89374997,linecolor=curcolor]
+{
+\newpath
+\moveto(62.03098996,54.83966988)
+\lineto(77.65499392,49.09432772)
+\lineto(62.0309891,43.34898681)
+\curveto(64.52705172,46.74103378)(64.51266935,51.38194274)(62.03098996,54.83966988)
+\closepath
+}
+}
+{
+\newrgbcolor{curcolor}{0 0 0}
+\pscustom[linewidth=3,linecolor=curcolor]
+{
+\newpath
+\moveto(13.8023,49.20920876)
+\lineto(73.8023,49.20920876)
+\lineto(73.8023,49.20920876)
+}
+}
+{
+\newrgbcolor{curcolor}{0 0 0}
+\pscustom[linewidth=1.29999995,linecolor=curcolor]
+{
+\newpath
+\moveto(207.35714,74.07142876)
+\lineto(255.64907,74.07142876)
+\lineto(266.64286,74.07142876)
+}
+}
+{
+\newrgbcolor{curcolor}{0 0 0}
+\pscustom[linestyle=none,fillstyle=solid,fillcolor=curcolor]
+{
+\newpath
+\moveto(252.74527996,79.83966988)
+\lineto(268.36928392,74.09432772)
+\lineto(252.7452791,68.34898681)
+\curveto(255.24134172,71.74103378)(255.22695935,76.38194274)(252.74527996,79.83966988)
+\closepath
+}
+}
+{
+\newrgbcolor{curcolor}{0 0 0}
+\pscustom[linewidth=0.89374997,linecolor=curcolor]
+{
+\newpath
+\moveto(252.74527996,79.83966988)
+\lineto(268.36928392,74.09432772)
+\lineto(252.7452791,68.34898681)
+\curveto(255.24134172,71.74103378)(255.22695935,76.38194274)(252.74527996,79.83966988)
+\closepath
+}
+}
+{
+\newrgbcolor{curcolor}{0 0 0}
+\pscustom[linewidth=3,linecolor=curcolor]
+{
+\newpath
+\moveto(204.51659,74.20920876)
+\lineto(264.51659,74.20920876)
+\lineto(264.51659,74.20920876)
+}
+}
+{
+\newrgbcolor{curcolor}{0 0 0}
+\pscustom[linestyle=none,fillstyle=solid,fillcolor=curcolor]
+{
+\newpath
+\moveto(20.05469472,109.49108471)
+\lineto(23.41406972,108.96374096)
+\lineto(23.41406972,107.92858471)
+\lineto(12.94531972,107.92858471)
+\lineto(12.94531972,108.96374096)
+\lineto(16.30469472,109.49108471)
+\lineto(16.30469472,132.57702221)
+\lineto(12.94531972,133.08483471)
+\lineto(12.94531972,134.11999096)
+\lineto(23.41406972,134.11999096)
+\lineto(23.41406972,133.08483471)
+\lineto(20.05469472,132.57702221)
+\lineto(20.05469472,109.49108471)
+\closepath
+}
+}
+{
+\newrgbcolor{curcolor}{0 0 0}
+\pscustom[linestyle=none,fillstyle=solid,fillcolor=curcolor]
+{
+\newpath
+\moveto(37.10547597,109.49108471)
+\lineto(42.45703847,108.96374096)
+\lineto(42.45703847,107.92858471)
+\lineto(28.37500722,107.92858471)
+\lineto(28.37500722,108.96374096)
+\lineto(33.74610097,109.49108471)
+\lineto(33.74610097,130.85827221)
+\lineto(28.45313222,128.96374096)
+\lineto(28.45313222,129.99889721)
+\lineto(36.08985097,134.33483471)
+\lineto(37.10547597,134.33483471)
+\lineto(37.10547597,109.49108471)
+\closepath
+}
+}
+{
+\newrgbcolor{curcolor}{0 0 0}
+\pscustom[linestyle=none,fillstyle=solid,fillcolor=curcolor]
+{
+\newpath
+\moveto(19.95703847,10.20537914)
+\lineto(23.31641347,9.67803539)
+\lineto(23.31641347,8.64287914)
+\lineto(12.84766347,8.64287914)
+\lineto(12.84766347,9.67803539)
+\lineto(16.20703847,10.20537914)
+\lineto(16.20703847,33.29131664)
+\lineto(12.84766347,33.79912914)
+\lineto(12.84766347,34.83428539)
+\lineto(23.31641347,34.83428539)
+\lineto(23.31641347,33.79912914)
+\lineto(19.95703847,33.29131664)
+\lineto(19.95703847,10.20537914)
+\closepath
+}
+}
+{
+\newrgbcolor{curcolor}{0 0 0}
+\pscustom[linestyle=none,fillstyle=solid,fillcolor=curcolor]
+{
+\newpath
+\moveto(42.55469472,8.64287914)
+\lineto(26.51953847,8.64287914)
+\lineto(26.51953847,11.51397289)
+\curveto(27.83464263,12.73793122)(29.03906972,13.83168122)(30.13281972,14.79522289)
+\curveto(31.23959055,15.77178539)(32.22917388,16.67673331)(33.10156972,17.51006664)
+\curveto(33.98698638,18.35642081)(34.75521555,19.16371247)(35.40625722,19.93194164)
+\curveto(36.07031972,20.70017081)(36.61719472,21.50095206)(37.04688222,22.33428539)
+\curveto(37.48959055,23.16761872)(37.81511138,24.06605622)(38.02344472,25.02959789)
+\curveto(38.24479888,25.99313956)(38.35547597,27.08037914)(38.35547597,28.29131664)
+\curveto(38.35547597,29.98402497)(37.97136138,31.27308747)(37.20313222,32.15850414)
+\curveto(36.43490305,33.04392081)(35.17839263,33.48662914)(33.43360097,33.48662914)
+\curveto(33.04297597,33.48662914)(32.65235097,33.45407706)(32.26172597,33.38897289)
+\curveto(31.8841218,33.33688956)(31.51953847,33.25876456)(31.16797597,33.15459789)
+\curveto(30.81641347,33.06345206)(30.48438222,32.95277497)(30.17188222,32.82256664)
+\curveto(29.87240305,32.70537914)(29.60547597,32.58168122)(29.37110097,32.45147289)
+\lineto(28.68750722,29.24834789)
+\lineto(27.39844472,29.24834789)
+\lineto(27.39844472,34.28741039)
+\curveto(28.38802805,34.52178539)(29.35808013,34.71709789)(30.30860097,34.87334789)
+\curveto(31.27214263,35.04261872)(32.3138093,35.12725414)(33.43360097,35.12725414)
+\curveto(36.2981843,35.12725414)(38.4466218,34.52829581)(39.87891347,33.33037914)
+\curveto(41.32422597,32.14548331)(42.04688222,30.46579581)(42.04688222,28.29131664)
+\curveto(42.04688222,27.22360831)(41.90365305,26.23402497)(41.61719472,25.32256664)
+\curveto(41.34375722,24.41110831)(40.9466218,23.53220206)(40.42578847,22.68584789)
+\curveto(39.90495513,21.85251456)(39.2669343,21.02569164)(38.51172597,20.20537914)
+\curveto(37.75651763,19.39808747)(36.89714263,18.55824372)(35.93360097,17.68584789)
+\curveto(34.9700593,16.81345206)(33.90886138,15.88246247)(32.75000722,14.89287914)
+\curveto(31.60417388,13.91631664)(30.38021555,12.83558747)(29.07813222,11.65069164)
+\lineto(42.55469472,11.65069164)
+\lineto(42.55469472,8.64287914)
+\closepath
+}
+}
+{
+\newrgbcolor{curcolor}{0 0 0}
+\pscustom[linestyle=none,fillstyle=solid,fillcolor=curcolor]
+{
+\newpath
+\moveto(232.22266347,96.76787914)
+\curveto(232.22266347,94.94496247)(232.35938222,93.29782706)(232.63281972,91.82647289)
+\curveto(232.90625722,90.35511872)(233.37500722,89.09860831)(234.03906972,88.05694164)
+\curveto(234.70313222,87.01527497)(235.5950593,86.20798331)(236.71485097,85.63506664)
+\curveto(237.83464263,85.07517081)(239.24089263,84.79522289)(240.93360097,84.79522289)
+\curveto(242.6263093,84.79522289)(244.0325593,85.07517081)(245.15235097,85.63506664)
+\curveto(246.27214263,86.20798331)(247.16406972,87.01527497)(247.82813222,88.05694164)
+\curveto(248.50521555,89.09860831)(248.98047597,90.35511872)(249.25391347,91.82647289)
+\curveto(249.52735097,93.29782706)(249.66406972,94.94496247)(249.66406972,96.76787914)
+\curveto(249.66406972,98.57777497)(249.52735097,100.21188956)(249.25391347,101.67022289)
+\curveto(248.98047597,103.12855622)(248.50521555,104.36553539)(247.82813222,105.38116039)
+\curveto(247.16406972,106.40980622)(246.27214263,107.19756664)(245.15235097,107.74444164)
+\curveto(244.0325593,108.29131664)(242.6263093,108.56475414)(240.93360097,108.56475414)
+\curveto(239.24089263,108.56475414)(237.83464263,108.29131664)(236.71485097,107.74444164)
+\curveto(235.5950593,107.19756664)(234.70313222,106.40980622)(234.03906972,105.38116039)
+\curveto(233.37500722,104.36553539)(232.90625722,103.12855622)(232.63281972,101.67022289)
+\curveto(232.35938222,100.21188956)(232.22266347,98.57777497)(232.22266347,96.76787914)
+\closepath
+\moveto(228.14063222,96.76787914)
+\curveto(228.14063222,99.08558747)(228.42058013,101.08428539)(228.98047597,102.76397289)
+\curveto(229.55339263,104.44366039)(230.38021555,105.83037914)(231.46094472,106.92412914)
+\curveto(232.54167388,108.01787914)(233.8763093,108.82517081)(235.46485097,109.34600414)
+\curveto(237.05339263,109.86683747)(238.8763093,110.12725414)(240.93360097,110.12725414)
+\curveto(242.92578847,110.12725414)(244.70964263,109.86683747)(246.28516347,109.34600414)
+\curveto(247.87370513,108.82517081)(249.22136138,108.01787914)(250.32813222,106.92412914)
+\curveto(251.43490305,105.83037914)(252.28125722,104.44366039)(252.86719472,102.76397289)
+\curveto(253.45313222,101.08428539)(253.74610097,99.08558747)(253.74610097,96.76787914)
+\curveto(253.74610097,94.45017081)(253.45313222,92.43845206)(252.86719472,90.73272289)
+\curveto(252.28125722,89.04001456)(251.43490305,87.64027497)(250.32813222,86.53350414)
+\curveto(249.22136138,85.42673331)(247.87370513,84.59991039)(246.28516347,84.05303539)
+\curveto(244.70964263,83.51918122)(242.92578847,83.25225414)(240.93360097,83.25225414)
+\curveto(238.94141347,83.25225414)(237.1575593,83.51918122)(235.58203847,84.05303539)
+\curveto(234.00651763,84.59991039)(232.6653718,85.42673331)(231.55860097,86.53350414)
+\curveto(230.45183013,87.64027497)(229.60547597,89.04001456)(229.01953847,90.73272289)
+\curveto(228.43360097,92.43845206)(228.14063222,94.45017081)(228.14063222,96.76787914)
+\closepath
+}
+}
+\end{pspicture}

doc/Rapport post-doc/figures/Function2_2.svg

@@ -0,0 +1,276 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   width="176.10666mm"
+   height="91.036827mm"
+   viewBox="0 0 623.99997 322.57143"
+   id="svg4267"
+   version="1.1"
+   inkscape:version="0.91 r13725"
+   sodipodi:docname="Function2_2.svg">
+  <defs
+     id="defs4269">
+    <marker
+       inkscape:stockid="Arrow1Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow1Lend"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         id="path5474"
+         d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         transform="matrix(-0.8,0,0,-0.8,-10,0)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker4501-3"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Lend"
+       inkscape:collect="always">
+      <path
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path4503-6"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker4501-3-2"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Lend"
+       inkscape:collect="always">
+      <path
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path4503-6-6"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker4501-3-2-8"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Lend"
+       inkscape:collect="always">
+      <path
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path4503-6-6-7"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:isstock="true"
+       style="overflow:visible"
+       id="marker4501-3-2-2"
+       refX="0"
+       refY="0"
+       orient="auto"
+       inkscape:stockid="Arrow2Lend"
+       inkscape:collect="always">
+      <path
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         id="path4503-6-6-0"
+         inkscape:connector-curvature="0" />
+    </marker>
+  </defs>
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="0.7"
+     inkscape:cx="242.03107"
+     inkscape:cy="8.0838619"
+     inkscape:document-units="px"
+     inkscape:current-layer="layer3"
+     showgrid="true"
+     fit-margin-top="0"
+     fit-margin-left="0"
+     fit-margin-right="0"
+     fit-margin-bottom="0"
+     inkscape:window-width="1271"
+     inkscape:window-height="715"
+     inkscape:window-x="1813"
+     inkscape:window-y="172"
+     inkscape:window-maximized="0">
+    <inkscape:grid
+       type="xygrid"
+       id="grid4815"
+       originx="10.571428"
+       originy="-583.71426" />
+  </sodipodi:namedview>
+  <metadata
+     id="metadata4272">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+        <dc:title></dc:title>
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     inkscape:label="Calque 1"
+     inkscape:groupmode="layer"
+     id="layer1"
+     transform="translate(10.571429,-146.07647)">
+    <rect
+       style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:4.4000001;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+       id="rect4817"
+       width="200"
+       height="80"
+       x="80"
+       y="232.3622" />
+    <ellipse
+       style="fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:3.47510362;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+       id="path5787"
+       cx="12.142852"
+       cy="167.22244"
+       rx="13.705303"
+       ry="12.13697" />
+    <rect
+       style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:4.4000001;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+       id="rect4817-5"
+       width="200"
+       height="80"
+       x="401.42856"
+       y="230.93362" />
+    <rect
+       style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:3;stroke-linejoin:round;stroke-miterlimit:4.4000001;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1"
+       id="rect4817-6"
+       width="200"
+       height="80"
+       x="400"
+       y="378.7193" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:4;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       d="m 20,172.3622 c 60,60 60,60 60,60"
+       id="path6043"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:4;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       d="m 280,272.3622 115.64372,-0.25254"
+       id="path6045"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:4;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       d="m 499.16317,377.23966 0.47969,-52.55603"
+       id="path6047"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:4;stroke-linecap:butt;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       d="m 281.42857,272.3622 c 0,0 19.10499,0.0429 23.98878,14.25396 8.95709,26.06364 14.58265,70.74604 22.17048,86.35494 12.10522,24.90162 67.94788,23.67681 67.94788,23.67681"
+       id="path6049"
+       inkscape:connector-curvature="0"
+       inkscape:transform-center-x="-7.1428571"
+       inkscape:transform-center-y="-28.571429"
+       sodipodi:nodetypes="cssc" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2.13773298;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:3.4000001;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker4501-3)"
+       d="m 66.912762,219.37924 12.310717,12.07092"
+       id="path4138-5"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2.13773298;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:3.4000001;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker4501-3-2)"
+       d="m 381.63992,272.65885 17.24073,-0.13505"
+       id="path4138-5-1"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2.13773298;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:3.4000001;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker4501-3-2-8)"
+       d="m 379.22921,396.58742 17.24073,-0.13505"
+       id="path4138-5-1-9"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2.13773298;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:3.4000001;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker4501-3-2-2)"
+       d="m 499.73482,330.21872 -0.24887,-17.23946"
+       id="path4138-5-1-2"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-weight:normal;font-size:40px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="111.14286"
+       y="280.93365"
+       id="text8261"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan8263"
+         x="111.14286"
+         y="280.93365"
+         style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:40px;line-height:125%;font-family:'Liberation Serif';-inkscape-font-specification:'Liberation Serif, Normal';text-align:start;writing-mode:lr-tb;text-anchor:start">nominal</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-weight:normal;font-size:40px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="447.14285"
+       y="280.93365"
+       id="text8261-4"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan8263-2"
+         x="447.14285"
+         y="280.93365"
+         style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:40px;line-height:125%;font-family:'Liberation Serif';-inkscape-font-specification:'Liberation Serif, Normal';text-align:start;writing-mode:lr-tb;text-anchor:start">lost</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-weight:normal;font-size:40px;line-height:125%;font-family:sans-serif;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="423.14285"
+       y="428.07651"
+       id="text8261-9"
+       sodipodi:linespacing="125%"
+       inkscape:transform-center-x="-8.5714289"
+       inkscape:transform-center-y="-4.285714"><tspan
+         sodipodi:role="line"
+         id="tspan8263-6"
+         x="423.14285"
+         y="428.07651"
+         style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:40px;line-height:125%;font-family:'Liberation Serif';-inkscape-font-specification:'Liberation Serif, Normal';text-align:start;writing-mode:lr-tb;text-anchor:start">erroneous</tspan></text>
+  </g>
+  <g
+     inkscape:groupmode="layer"
+     id="layer3"
+     inkscape:label="contour"
+     transform="translate(10.571429,-146.07647)"
+     style="display:none">
+    <rect
+       style="fill:none;fill-opacity:1;stroke:#000000;stroke-width:3.75491953;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:3.7549195, 7.509839;stroke-dashoffset:0;stroke-opacity:1"
+       id="rect8292"
+       width="620.24506"
+       height="318.81653"
+       x="-8.6939688"
+       y="147.95393" />
+  </g>
+</svg>

doc/Rapport post-doc/figures/texput.log

@@ -0,0 +1,21 @@
+This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian) (preloaded format=pdflatex 2016.4.22)  7 FEB 2017 14:20
+entering extended mode
+ restricted \write18 enabled.
+ %&-line parsing enabled.
+**main.tex
+
+! Emergency stop.
+<*> main.tex
+            
+End of file on the terminal!
+
+ 
+Here is how much of TeX's memory you used:
+ 3 strings out of 494924
+ 106 string characters out of 6179708
+ 45773 words of memory out of 5000000
+ 3399 multiletter control sequences out of 15000+600000
+ 3640 words of font info for 14 fonts, out of 8000000 for 9000
+ 14 hyphenation exceptions out of 8191
+ 0i,0n,0p,1b,6s stack positions out of 5000i,500n,10000p,200000b,80000s
+!  ==> Fatal error occurred, no output PDF file produced!

doc/Rapport post-doc/llncsdoc.sty

@@ -0,0 +1,42 @@
+% This is LLNCSDOC.STY the modification of the
+% LLNCS class file for the documentation of
+% the class itself.
+%
+\def\AmS{{\protect\usefont{OMS}{cmsy}{m}{n}%
+  A\kern-.1667em\lower.5ex\hbox{M}\kern-.125emS}}
+\def\AmSTeX{{\protect\AmS-\protect\TeX}}
+%
+\def\ps@myheadings{\let\@mkboth\@gobbletwo
+\def\@oddhead{\hbox{}\hfil\small\rm\rightmark
+\qquad\thepage}%
+\def\@oddfoot{}\def\@evenhead{\small\rm\thepage\qquad
+\leftmark\hfil}%
+\def\@evenfoot{}\def\sectionmark##1{}\def\subsectionmark##1{}}
+\ps@myheadings
+%
+\setcounter{tocdepth}{2}
+%
+\renewcommand{\labelitemi}{--}
+\newenvironment{alpherate}%
+{\renewcommand{\labelenumi}{\alph{enumi})}\begin{enumerate}}%
+{\end{enumerate}\renewcommand{\labelenumi}{enumi}}
+%
+\def\bibauthoryear{\begingroup
+\def\thebibliography##1{\section*{References}%
+    \small\list{}{\settowidth\labelwidth{}\leftmargin\parindent
+    \itemindent=-\parindent
+    \labelsep=\z@
+    \usecounter{enumi}}%
+    \def\newblock{\hskip .11em plus .33em minus -.07em}%
+    \sloppy
+    \sfcode`\.=1000\relax}%
+    \def\@cite##1{##1}%
+    \def\@lbibitem[##1]##2{\item[]\if@filesw
+      {\def\protect####1{\string ####1\space}\immediate
+    \write\@auxout{\string\bibcite{##2}{##1}}}\fi\ignorespaces}%
+\begin{thebibliography}{}
+\bibitem[1982]{clar:eke3} Clarke, F., Ekeland, I.: Nonlinear
+oscillations and boundary-value problems for Hamiltonian systems.
+Arch. Rat. Mech. Anal. 78, 315--333 (1982)
+\end{thebibliography}
+\endgroup}

doc/Rapport post-doc/longabstract.tex

@@ -0,0 +1,25 @@
+\section{Introduction}
+\label{sec:intro}
+
+
+
+
+% In the following, we first focus on the industrial needs of temporal
+% properties that motivate our research. We then describe the
+% representation languages to represent time as an intrinsic information
+% of the system modelled, and their expressivity.  On a simple study
+% case, using constant-delays as the simplest timed interactions between
+% elements of a system, we show how temporal properties are verified via
+% the Tina model-checked, and how such analysis helps engineering design
+% in its early-development phases.  We conclude with a discussion on the
+% state of the art, and comment on the future work and extensions of
+% this approach.
+% in AltaRica modelling language, and how an extended version of it
+% allow us to express time intervals, where events occur
+% non-deterministically.
+
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "main"
+%%% End:

doc/Rapport post-doc/main.tex

@@ -0,0 +1,198 @@
+ \documentclass[oribibl]{report}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\usepackage{natbib} 
+\usepackage{hyperref,verbatim}
+\usepackage{listings,dirtytalk}
+\usepackage{lstlang3}
+\usepackage{amsmath,amsfonts,amssymb,stmaryrd}
+\usepackage{graphicx, wrapfig}
+\usepackage{latexsym}
+\usepackage{units}
+\usepackage{xspace}%
+% \usepackage{wrapfig}
+
+\usepackage{xcolor}
+\hypersetup{
+    colorlinks,
+    linkcolor={red!50!black},
+    citecolor={blue!50!black},
+    urlcolor={blue!80!black}
+}
+\definecolor{bluekeywords}{rgb}{0.13,0.13,1}
+\definecolor{greencomments}{rgb}{0,0.5,0}
+\definecolor{redstrings}{rgb}{0.9,0,0}
+\definecolor{codegreen}{rgb}{0,0.6,0}
+\definecolor{codepurple}{rgb}{0.58,0,0.82}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%   LISTINGS
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\font\bigttfont = cmtt12 scaled 1120
+\newcommand*{\ttfamilywithbold}{\fontfamily{lmtt}\selectfont}
+
+\def\code#1{{\ttfamilywithbold #1}}%{{\small\ttfamilywithbold #1}}
+\def\vars#1{{\small\ttfamilywithbold #1}}
+
+\sbox0{\small\ttfamily A}
+\edef\mybasewidth{\the\wd0 }
+\lstset{inputencoding=latin1,
+  basicstyle=\footnotesize\ttfamilywithbold,
+  columns=fixed,
+  basewidth=\mybasewidth,
+  commentstyle=\commentaires,
+  keywordstyle=\bfseries,
+  % keywordstyle={[2]\itshape},
+  keywordstyle=\color{bluekeywords},
+  % basewidth=0.94ex,
+  showstringspaces=false,
+  % emptylines=1,
+  % aboveskip=-2pt,belowskip=-4pt,
+  mathescape=true, 
+  texcl=true, 
+  escapechar=@,
+  numberblanklines=false,
+  belowskip=-0.5em,
+  aboveskip=-0.5em,
+  commentstyle=\color{green},%{bluekeywords},
+  belowcaptionskip=-1em
+}
+
+% \usepackage{fancybox}
+% \makeatletter
+% \newenvironment{CenteredBox}{% 
+% \begin{Sbox}}{% Save the content in a box
+% \end{Sbox}\centerline{\parbox{\wd\@Sbox}{\TheSbox}}}% And output it centered
+% \makeatother
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\usepackage{tikz}
+\usetikzlibrary{arrows,shapes,decorations,automata,backgrounds,petri,patterns,spy,decorations.markings,shadows}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\newtheorem{prop}{Safety Property}{\bfseries}{\rmfamily}
+\newcommand{\PRE}[0]{\code{Pre}\xspace}%
+\newcommand{\FUNC}[0]{\code{Function}\xspace}%
+\newcommand{\ERR}[0]{\code{Err}\xspace}%
+\newcommand{\LOSS}[0]{\code{Loss}\xspace}
+\newcommand{\OK}[0]{\code{Ok}\xspace}
+\newcommand{\MIN}[0]{\code{F3Mux}\xspace}
+\newcommand{\ALARM}[0]{\code{Alarm}\xspace}
+\newcommand{\SWITCH}[0]{\code{Switch}\xspace}
+\newcommand{\FF}[2]{\code{F{#1}\_{#2}}\xspace}
+\newcommand{\F}[1]{\code{F{#1}}\xspace}
+\newcommand{\I}[1]{\code{I{#1}}\xspace}
+\newcommand{\D}[1]{\code{D{#1}}\xspace}
+\newtheorem{definition}{Definition}
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\newcommand{\TODO}[1]{{\color{red}#1}}
+
+\setlength{\belowcaptionskip}{-1em}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+
+\makeatletter
+%\renewcommand\bibsection%
+%{\chapter*{\refname\@mkboth{\MakeUppercase{\refname}}{\MakeUppercase{\refname}}}}
+\makeatother
+
+\begin{document}
+%%
+\title{Model-Checking Approach to Analyse\\
+  Temporal Model Properties with AltaRica}
+%%
+\author{Alexandre Albore}
+%%\institute{Institute of Research and Technology (IRT) Saint Exup\'ery, Toulouse, France  \and
+%%LAAS-CNRS, Universit\'e de Toulouse, CNRS, Toulouse,  France \and
+%%ONERA, 2 Avenue Edouard Belin, 31055 Toulouse, France 
+%%  }
+%%
+
+
+%%\frontmatter
+
+\maketitle
+\setcounter{footnote}{0}
+%%
+% \noindent\textbf{keywords:} Verification of Safety Requirements; System
+% Architecture Specification; Realtime Model-Checking.\\
+%%
+\begin{abstract}
+  The design of complex safety critical systems raises new technical
+  challenges for industrials. As systems become more complex---and
+  include more and more interacting functions---it becomes harder to
+  evaluate the safety implications of local failures and their
+  possible propagations through a whole system. That is all the more
+  true when we add time to the problem, that is when we consider the
+  impact of computation times and delays on the propagation of
+  failures.
+
+  We describe an approach that extends models developed for Safety
+  Analysis with timing information and provide tools to reason on the
+  correctness of temporal safety conditions. Our approach is based on
+  an extension of the AltaRica language where we can associate timing
+  constraints with events and relies on a translation into a realtime
+  model-checking toolset. We illustrate our method with an example
+  that is representative of safety architectures found in critical
+  systems. This example shows that considering propagation delays
+  early during the validation of a system can help us uncover failure
+  modes that cannot be detected with the untimed models currently
+  used.
+\end{abstract}
+
+\tableofcontents
+% \section*{Acknowledgments}\label{sec:Acknowledgments}
+
+% Authors would like to thank YYYYY.
+
+% and could have a beneficial impact on the early validation of system
+% behaviour
+\chapter{Introduction}
+\input{1-introduction}
+
+\chapter{State of the art}
+\label{soa}\input{2-sota}
+
+\chapter{A Model-Checking Approach to Analyse Temporal Failure Propagation with AltaRica}
+\label{altarica}\input{3-imbsa}
+
+\chapter{A Case Study: FDIR in a Satellite AOCS}
+\label{aocs}
+\input{4-aocs}
+
+\chapter{Conclusions}
+\input{5-conclusions}
+
+\bibliographystyle{abbrv}
+
+\bibliography{paper,tina}
+
+\newpage
+\appendix
+\chapter*{Appendix A}
+\setcounter{chapter}{1}
+	\input{app.tex}
+
+%\chapter*{Appendix}
+%%\input{commandlines}
+%% Good results and proving that a mathematical model underlying model representation allows to use properties and tools for automatic safety assessment.
+
+\end{document}
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: t
+%%% End:

doc/Rapport post-doc/main.toc

@@ -0,0 +1,48 @@
+\contentsline {chapter}{\numberline {1}Introduction}{3}{chapter.1}
+\contentsline {section}{\numberline {1.1}Toward an automated model-based approach to system validation}{3}{section.1.1}
+\contentsline {subsection}{\numberline {1.1.1}Classical safety analysis techniques: FTA and FMEA}{4}{subsection.1.1.1}
+\contentsline {subsection}{\numberline {1.1.2}Modern safety analysis techniques: MBSE and MBSA}{5}{subsection.1.1.2}
+\contentsline {section}{\numberline {1.2}Automated Evaluation of Safety Temporal Conditions}{5}{section.1.2}
+\contentsline {chapter}{\numberline {2}State of the art}{7}{chapter.2}
+\contentsline {section}{\numberline {2.1}Modelling languages for Safety Analysis}{7}{section.2.1}
+\contentsline {section}{\numberline {2.2}Safety Assessment on Temporal Properties}{8}{section.2.2}
+\contentsline {section}{\numberline {2.3}Model-checking approach to safety assessment}{9}{section.2.3}
+\contentsline {subsection}{\numberline {2.3.1}Tina model-checker}{10}{subsection.2.3.1}
+\contentsline {chapter}{\numberline {3}A Model-Checking Approach to Analyse Temporal Failure Propagation with AltaRica}{12}{chapter.3}
+\contentsline {section}{\numberline {3.1}Model-Based Safety Analysis with AltaRica}{13}{section.3.1}
+\contentsline {subsection}{\numberline {3.1.1}AltaRica language and versions}{13}{subsection.3.1.1}
+\contentsline {subsection}{\numberline {3.1.2}AltaRica modelling}{13}{subsection.3.1.2}
+\contentsline {subsection}{\numberline {3.1.3}Time AltaRica: Adding Timing Constraints to Events}{15}{subsection.3.1.3}
+\contentsline {section}{\numberline {3.2}A Definition of Fiacre Using Examples}{16}{section.3.2}
+\contentsline {section}{\numberline {3.3}Example of a Failure Detection and Isolation System}{18}{section.3.3}
+\contentsline {subsubsection}{Safety model of the architecture without FDI}{19}{section*.2}
+\contentsline {subsubsection}{Safety model of the architecture with FDI}{21}{section*.3}
+\contentsline {section}{\numberline {3.4}Compilation of AltaRica and Experimental evaluation}{22}{section.3.4}
+\contentsline {subsection}{\numberline {3.4.1}Empirical evaluation}{24}{subsection.3.4.1}
+\contentsline {chapter}{\numberline {4}A Case Study: FDIR in a Satellite AOCS}{26}{chapter.4}
+\contentsline {section}{\numberline {4.1}An Expression of Industrial Needs and Requirements}{27}{section.4.1}
+\contentsline {section}{\numberline {4.2}AOCS Case Study}{27}{section.4.2}
+\contentsline {subsection}{\numberline {4.2.1}Architecture description}{28}{subsection.4.2.1}
+\contentsline {subsection}{\numberline {4.2.2}AOCS mode automaton}{28}{subsection.4.2.2}
+\contentsline {subsubsection}{OFF mode}{31}{section*.5}
+\contentsline {subsubsection}{Acquisition \& Safe mode (ASM)}{31}{section*.6}
+\contentsline {subsubsection}{Attitude Control Mode (ACM)}{31}{section*.7}
+\contentsline {subsubsection}{Collision Avoidance Manœuvre (CAM)}{32}{section*.8}
+\contentsline {subsubsection}{Orbit Control Mode (OCM)}{32}{section*.9}
+\contentsline {subsubsection}{Formation Control Mode (FCM)}{33}{section*.10}
+\contentsline {subsubsection}{Equipment}{33}{section*.11}
+\contentsline {section}{\numberline {4.3}Case study modelling}{36}{section.4.3}
+\contentsline {subsection}{\numberline {4.3.1}AltaRica modelling process}{37}{subsection.4.3.1}
+\contentsline {subsection}{\numberline {4.3.2}Details of the model}{37}{subsection.4.3.2}
+\contentsline {subsection}{\numberline {4.3.3}Empirical evaluation}{38}{subsection.4.3.3}
+\contentsline {chapter}{\numberline {5}Conclusions}{41}{chapter.5}
+\contentsline {section}{\numberline {5.1}Future Work}{42}{section.5.1}
+\contentsline {section}{\numberline {A.1}Interpretation of AltaRica in Fiacre}{47}{section.A.1}
+\contentsline {section}{\numberline {A.2}Method and translation}{51}{section.A.2}
+\contentsline {subsection}{\numberline {A.2.1}Time Petri Nets}{51}{subsection.A.2.1}
+\contentsline {subsubsection}{States in a TPN}{51}{section*.17}
+\contentsline {subsection}{\numberline {A.2.2}From AltaRica to Tina}{52}{subsection.A.2.2}
+\contentsline {subsection}{\numberline {A.2.3}Factored model of ETGTS}{52}{subsection.A.2.3}
+\contentsline {subsubsection}{Semantics of a ETGTS}{53}{section*.18}
+\contentsline {subsubsection}{Translation}{54}{section*.19}
+\contentsline {section}{\numberline {A.3}Command line}{54}{section.A.3}

doc/Rapport post-doc/paper.bib

@@ -0,0 +1,427 @@
+@inproceedings{albore2017IMBSA,
+	title={A Model-Checking Approach to Analyse Temporal Failure Propagation with {A}lta{R}ica},
+	author={Albore, Alexandre and Dal Zilio, Silvano and Infantes, Guillaume and Seguin, Christel and Virelizier, Pierre},
+	booktitle={International Symposium on Model-Based Safety and Assessment -- LNCS},
+	pages={147--162},
+	year={2017},
+	volume={10437},
+	organization={Springer}
+}
+
+@inproceedings{albore2018ERTS,
+	title={Timed Formal Model and Verification of Satellite {FDIR} in Early Design Phase},
+	author={Albore, Alexandre and Dal Zilio, Silvano and de Roquemaurel, Marie and Seguin, Christel and Virelizier, Pierre},
+	booktitle={9th European Congress on Embedded Real Time Software and Systems},
+	OPTpages={147--162},
+	year={2018},
+	address={Toulouse, France}
+}
+
+
+@article{nusmv,
+	title={{NuSMV}: a new symbolic model checker},
+	author={Cimatti, Alessandro and Clarke, Edmund and Giunchiglia, Fausto and Roveri, Marco},
+	journal={International Journal on Software Tools for Technology Transfer},
+	volume={2},
+	number={4},
+	pages={410--425},
+	year={2000},
+	publisher={Springer}
+}
+
+@article{bozzano2010safety,
+	title={Safety, dependability and performance analysis of extended AADL models},
+	author={Bozzano, Marco and Cimatti, Alessandro and Katoen, Joost-Pieter and Nguyen, Viet Yen and Noll, Thomas and Roveri, Marco},
+	journal={The Computer Journal},
+	volume={54},
+	number={5},
+	pages={754--775},
+	year={2010},
+	publisher={Oxford University Press}
+}
+
+@inproceedings{PRISM,
+	title={PRISM 4.0: Verification of Probabilistic Real-time Systems},
+	author={Kwiatkowska, Marta and Gethin, Norman and Parker, David},
+	booktitle={International Conference on Computer Aided Verification (CAV’11) -- LNCS},
+	pages={585-591},
+	year={2011},
+	volume={6806},
+	organization={Springer}
+}
+
+@inproceedings{brunel2017performing,
+	title={Performing Safety Analyses with AADL and AltaRica},
+	author={Brunel, Julien and Feiler, Peter and Hugues, J{\'e}r{\^o}me and Lewis, Bruce and Prosvirnova, Tatiana and Seguin, Christel and Wrage, Lutz},
+	booktitle={International Symposium on Model-Based Safety and Assessment -- LNCS},
+	pages={67--81},
+	year={2017},
+		volume={10437},
+	organization={Springer}
+}
+
+@article{KNP04b,
+	author={M. Kwiatkowska and G. Norman and D. Parker},
+	title={Probabilistic Symbolic Model Checking with {PRISM}: A Hybrid Approach},
+	journal={International Journal on Software Tools for Technology Transfer (STTT)},
+	year={2004},
+	volume={6},
+	number={2},
+	pages={128--142}
+}
+
+@Article{arn00,
+  author = 	 {Arnold, A. and Griffault, A. and Point, G. and Rauzy, A.},
+  title = 	 {The {AltaRica} formalism for describing concurrent systems },
+  journal = 	 {Fundamenta Informatic{\ae}},
+  year = 	 {2000},
+  volume = 	 {40},
+  number={2, 3},
+  publisher={IOS Press},
+  pages = 	 {109-124}
+}
+
+@book{Stamatis,
+	author = {Stamatis, D. H.},
+	title = {Failure {M}ode and {E}ffect Analysis: {FMEA} from Theory to Execution},
+	date = {2003},
+	publisher = {ASQ Quality Press}
+}
+
+@article{papadopoulos2011engineering,
+	title={Engineering failure analysis and design optimisation with {H}i{P}-{HOPS}},
+	author={Papadopoulos, Yiannis and Walker, Martin and Parker, David and R{\"u}de, Erich and Hamann, Rainer and Uhlig, Andreas and Gr{\"a}tz, Uwe and Lien, Rune},
+	journal={Engineering Failure Analysis},
+	volume={18},
+	number={2},
+	pages={590--608},
+	year={2011},
+	publisher={Elsevier}
+}
+
+@phdthesis{walker2009pandora,
+	title={Pandora: a logic for the qualitative analysis of temporal fault trees},
+	author={Walker, Martin David},
+	year={2009},
+	school={The University of Hull}
+}
+@article{pagetti2004,
+  title={A timed extension for {A}lta{R}ica},
+  author={Cassez, Franck and Pagetti, Claire and Roux, Olivier},
+  journal={Fundamenta Informatic{\ae}},
+  volume={62},
+  number={3-4},
+  pages={291--332},
+  year={2004},
+  publisher={IOS Press}
+}
+
+@article{stamatelatos2002fault,
+	title={Fault tree handbook with aerospace applications},
+	author={Stamatelatos, Michael and Vesely, William and Dugan, Joanne and Fragola, Joseph and Minarick, Joseph and Railsback, Jan},
+	year={2002},
+	publisher={{NASA}, Washington, DC}
+}
+
+@book{FMEA,
+	author = {United States military procedure MIL-P-1629},
+	title = {Procedure for performing a failure mode effect and criticality analysis},
+	date = {1949}
+}
+
+
+@inproceedings{figaro,
+	author = {Bouissou, M},
+	title = {Automated dependability analysis of complex systems with the KB3 workbench: the experience of EDF R\&D},
+	booktitle = {Proceedings of CIEM},
+	date = {2005},
+	OPTeventtitle = {eventtitle},
+	eventdate = {22–25 October 2005},
+	venue = {Bucharest, Romania}
+}
+
+@inproceedings{daws,
+	author = { Daws, C. and Yovine, S.},
+	editor = {IEEE},
+	title = {Reducing the Number of Clock Variables of Timed Automata},
+	booktitle = {17th IEEE Real-Time Systems Symposium},
+	date = {1996},
+	venue = {Washington, DC}
+
+}
+
+@article{uppaal1997,
+	author = {K. G. Larsen and P. Pettersson and W. Yi},
+	title = {UPPAAL in a nutshell},
+	journaltitle = {International Journal on Software Tools for Technology Transfer (STTT)},
+	date = {1997},
+	volume = {1},
+	number = {1},
+	pages = {134-152}
+}
+
+@inproceedings{uppaal2006,
+  title={{UPPAAL} 4.0},
+  author={Behrmann, Gerd and David, Alexandre and Larsen, Kim Guldstrand and Hakansson, John and Petterson, Paul and Yi, Wang and Hendriks, Martijn},
+  booktitle={Quantitative Evaluation of Systems, 2006 (QEST 2006)},
+  pages={125--126},
+  year={2006},
+  organization={IEEE}
+}
+
+@article{bernard2007experiments,
+  title={Experiments in model based safety analysis: {F}light controls},
+  author={Bernard, Romain and Aubert, Jean-Jacques and Bieber, Pierre and Merlini, Christophe and Metge, Sylvain},
+  journal={IFAC Proceedings Volumes},
+  volume={40},
+  number={6},
+  pages={43--48},
+  year={2007},
+  publisher={Elsevier}
+}
+@inproceedings{bieber2002combination,
+  title={Combination of fault tree analysis and model checking for safety assessment of complex system},
+  author={Bieber, Pierre and Castel, Charles and Seguin, Christel},
+  booktitle={European Dependable Computing Conference},
+  pages={19--31},
+  year={2002},
+  organization={Springer}
+}
+@InProceedings{poi99,
+  author = 	 {Point, G. and Rauzy, A.},
+  title = 	 {{AltaRica} - Langage de mod{\'e}lisation par automates \`a contraintes},
+  booktitle = {Actes du Congr\'es Mod\'elisation des Syst\`emes R\'eactifs},
+  year = 	 {1999},
+  publisher = 	 {Herm\`es ed.}
+}
+
+@InProceedings{rauzy02,
+  author = 	 {Rauzy, A.},
+  title = 	 {Mode automata and their compilation into fault trees},
+  booktitle = {Reliability Engineering and 
+System Safety},
+  year = 	 {2002}
+}
+
+@incollection{bieber2004safety,
+  title={Safety assessment with {A}ltarica},
+  author={Bieber, Pierre and Bougnol, Christian and Castel, Charles and Kehren, Jean-Pierre Heckmann Christophe and Metge, Sylvain and Seguin, Christel},
+  booktitle={Building the Information Society},
+  pages={505--510},
+  year={2004},
+  publisher={Springer}
+}
+
+@Article{rau08,
+  author = 	 {Rauzy A.},
+  title = 	 {Guarded {T}ransition {S}ystems: a new States/Events Formalism for Reliability Studies},
+  journal =  {Journal of Risk and Reliability},
+  year = 	 {2008},
+  volume = 	 {222},
+  number = 	 {4}
+}
+
+@article{prosvirnova2013altarica,
+  title={The {A}lta{R}ica 3.0 project for {M}odel-{B}ased {S}afety {A}ssessment},
+  author={Prosvirnova, Tatiana and Batteux, Michel and Brameret, Pierre-Antoine and Cherfi, Abraham and Friedlhuber, Thomas and Roussel, Jean-Marc and Rauzy, Antoine},
+  journal={IFAC Proceedings Volumes},
+  volume={46},
+  number={22},
+  pages={127--132},
+  year={2013},
+  publisher={Elsevier}
+}
+
+@inproceedings{thomas2013,
+  title={Model-Based {RAMS} \& {FDIR} Co-Engineering at {A}strium Satellites},
+  author={Thomas, Dave and Blanquart, Jean-Paul},
+  booktitle={Data System In Aerospace (DASIA 2013)},
+  publisher ={ESA Special Publication},
+  volume={720},
+  pages={33},
+  year={2013}
+}
+
+@article{arnold1999altarica,
+  title={The {AltaRica} formalism for describing concurrent systems},
+  author={Arnold, Andr{\'e} and Point, G{\'e}rald and Griffault, Alain and Rauzy, Antoine},
+  journal={Fundamenta Informaticae},
+  volume={40},
+  number={2, 3},
+  pages={109--124},
+  year={1999},
+  publisher={IOS Press}
+}
+
+@inproceedings{bouissou05,
+	author = { Bouissou, M.},
+	title = {Automated dependability analysis of complex systems with the KB3 workbench: the experience of EDF R\&D},
+	booktitle = {International Conference on ENERGY and ENVIRONMENT (CIEM)},
+	year = {2005}
+}
+
+@inproceedings{bittner2014,
+	author = {Bittner, B. and  Bozzano, M. and Cimatti,  A. and De Ferluc, R. and Gario, M. and Guiotto, A. and Yushtein, Y.},
+	title = {An Integrated Process for {FDIR} Design in Aerospace},
+	booktitle = {International Symposium on Model Based Safety and Assessment (IMBSA)},
+	year = {2014},
+	venue = {Trento}
+}
+
+@booklet{arc,
+	author = {Point, G. and Griffault, A. and  Vincent, A.},
+	title = {AltaRica Checker Handbook - A user-guide to ARC version 1},
+	year = {2010},
+	location = {Talence: LaBRI - CNRS UMR 5800 - Univ. de Bordeaux}
+}
+
+@report{Griffault06,
+	author = {Griffault, A. and Point, G.},
+	title = {On the partial translation of {L}ustre programs into the {A}lta{R}ica language and vice versa},
+	type = {Research Report},
+	institution = {LaBRI - CNRS UMR 5800},
+	year = {2006},
+    number = {1415-06},
+	location = {Bordeaux}
+}
+
+
+@inproceedings{mec5,
+	author = {A. Griffault and A. Vincent},
+	title = {The {MEC} 5 model-checker},
+	booktitle = {International Conference on Computer Aided Verification},
+	year = {2004}
+}
+
+@inproceedings{rugina09,
+	author = {A.-E. Rugina and J.-P. Blanquart and R. Soumagne},
+	title = {Validating {F}ailure {D}etection {I}solation and {R}ecovery {S}trategies using {T}imed {A}utomata},
+	booktitle = {12th European Workshop on Dependable Computing (EWDC 2009)},
+	year = {2009},
+	venue = {Toulouse}
+}
+
+@inproceedings{chaki2004,
+	title={State/event-based Software Model Checking},
+	author={Chaki, Sagar and Clarke, Edmund M. and Ouaknine, Jo{\"e}l and Sharygina, Natasha and Sinha, Nishant},
+	booktitle={International Conference on Integrated Formal Methods},
+	pages={128--147},
+	year={2004},
+	organization={Springer}
+}
+
+@inproceedings{cadp,
+	title={CADP a protocol validation and verification toolbox},
+	author={Fernandez, Jean-Claude and Garavel, Hubert and Kerbrat, Alain and Mounier, Laurent and Mateescu, Radu and Sighireanu, Mihaela},
+	booktitle={International Conference on Computer Aided Verification},
+	pages={437--440},
+	year={1996},
+	organization={Springer}
+}
+@TechReport{Altarica2.3,
+  author = 	 {Antoine B. Rauzy},
+  title = 	 {Alta{R}ica {D}ataflow Language Specification  Version 2.3},
+  institution =  {Ecole Centrale de Paris},
+  year = 	 {2013},
+ month = 	 {June}
+}
+
+@InProceedings{epoch,
+  author = 	 {Teichteil-K{\"o}nigbuch, Florent and Infantes, Guillaume and Seguin, Christel },
+  title = 	 {{EPOCH} Probabilistic {M}odel-{C}hecking},
+ booktitle = {{M}odel {B}ased {S}afety {A}ssessment workshop},
+  year = 	 {2011},
+  address = 	 {Toulouse, France}
+}
+
+@inproceedings{bittner2016,
+  title={Automated synthesis of timed failure propagation graphs},
+  author={Bittner, Benjamin and Bozzano, Marco and Cimatti, Alessandro},
+  booktitle={Proc. Int. Joint Conf. of Artificial Intelligence (IJCAI-16)},
+  pages={972--978},
+  year={2016}
+}
+
+@article{bozzano2012,
+  title={Symbolic {M}odel {C}hecking and safety assessment of {AltaRica} models},
+  author={Bozzano, Marco and Cimatti, Alessandro and Lisagor, Oleg and Mattarei, Cristian and Mover, Sergio and Roveri, Marco and Tonetta, Stefano},
+  journal={Electronic Communications of the EASST},
+  volume={46},
+  year={2012}
+}
+
+@article{berthomieu1991TPN,
+	title={Modeling and verification of time dependent systems using time {P}etri nets},
+	author={Berthomieu, Bernard and Diaz, Michel},
+	journal={IEEE transactions on software engineering},
+	volume={17},
+	number={3},
+	pages={259--273},
+	year={1991},
+	publisher={IEEE}
+}
+
+@inproceedings{Zalila,
+	author = {Zalila, F. and  Jenn, É. and Pantel, M. },
+	title = {Model Execution and Debugging - A Process to Leverage Existing Tools},
+	booktitle = { 5th International Conference on Model-Driven Engineering and Software Development},
+	year = {2017}
+}
+
+
+@incollection{synoptic,
+	author = {A. Cortier and L. Besnard and J. P. Bodeveix and J. Buisson and F. Dagnat and M. Filali and G. Garcia and J. Ouy and M. Pantel and A.-E. Rugina and M. Strecker and J.P. Talpin},
+	title = {Synoptic: A Domain-Specific Modeling Language for Space On-board Application Software},
+	booktitle = {Synthesis of Embedded Software},
+	date = {2010}
+}
+
+@manual{sutre09,
+	author = { Sutre , G. and Herbreteau, F. and  Fleury, F.},
+	title = {Traduction de Synoptic en {AltaRica}},
+	year = {2009},
+	organization = {LaBRI}
+}
+
+@article{merlin1976,
+	title={Recoverability of communication protocols--implications of a theoretical study},
+	author={Merlin, Philip and Farber, David},
+	journal={IEEE transactions on Communications},
+	volume={24},
+	number={9},
+	pages={1036--1043},
+	year={1976},
+	publisher={IEEE}
+}
+
+@article{yao,
+	title={A {P}etri net model for temporal knowledge representation and reasoning},
+	author={Yao, Yulin},
+	journal={IEEE Transactions on Systems, Man, and Cybernetics},
+	volume={24},
+	number={9},
+	pages={1374--1382},
+	year={1994},
+	publisher={IEEE}
+}
+
+
+@book{ECSS‐E‐ST‐70‐11C,
+	title = {Space segment operability},
+	month = {31 July },
+	year={2008},
+	number = {ECSS-E-ST-70-11C}
+}
+
+
+@book{ECSS-E-ST-60-30C,
+	title = {Satellite attitude and orbit control system ({AOCS}) requirements},
+	month ={30 August },
+	year={2013},
+	number = {ECSS-E-ST-60-30C}
+}
+
+@book{ASRA,
+title={Avionics {S}ystem {R}eference {A}rchitecture ({ASRA})},
+publisher={ESA contract {4 000 102 927}}
+}

doc/Rapport post-doc/readme.txt

@@ -0,0 +1,30 @@
+Dear LLNCS user,
+
+The files in this directory belong to the LaTeX2e package for
+Lecture Notes in Computer Science (LNCS) of Springer-Verlag.
+
+It consists of the following files:
+
+  readme.txt         this file
+
+  history.txt        the version history of the package
+
+  llncs.cls          the LaTeX2e document class
+
+  llncs.dem          the sample input file
+
+  llncs.doc          the documentation of the class (LaTeX source)
+  llncsdoc.pdf       the documentation of the class (PDF version)
+  llncsdoc.sty       the modification of the class for the documentation
+  llncs.ind          an external (faked) author index file
+  subjidx.ind        subject index demo from the Springer book package
+  llncs.dvi          the resultig DVI file (remember to use binary transfer!)
+
+  sprmindx.sty       supplementary style file for MakeIndex
+                     (usage: makeindex -s sprmindx.sty <yourfile.idx>)
+
+  splncs03.bst       current LNCS BibTeX style with alphabetic sorting
+
+  aliascnt.sty       part of the Oberdiek bundle; allows more control over
+                     the counters associated to any numbered item
+  remreset.sty       by David Carlisle

doc/Rapport post-doc/remreset.sty

@@ -0,0 +1,39 @@
+
+% remreset package
+%%%%%%%%%%%%%%%%%%
+
+% Copyright 1997 David carlisle
+% This file may be distributed under the terms of the LPPL.
+% See 00readme.txt for details.
+
+% 1997/09/28  David Carlisle
+
+% LaTeX includes a command \@addtoreset that is used to declare that
+% a counter should be reset every time a second counter is incremented.
+
+% For example the book class has a line
+% \@addtoreset{footnote}{chapter}
+% So that the footnote counter is reset each chapter.
+
+% If you wish to bas a new class on book, but without this counter
+% being reset, then standard LaTeX gives no simple mechanism to do
+% this.
+
+% This package defines |\@removefromreset| which just undoes the effect
+% of \@addtorest. So for example a class file may be defined by
+
+% \LoadClass{book}
+% \@removefromreset{footnote}{chapter}
+
+
+\def\@removefromreset#1#2{{%
+  \expandafter\let\csname c@#1\endcsname\@removefromreset
+  \def\@elt##1{%
+    \expandafter\ifx\csname c@##1\endcsname\@removefromreset
+    \else
+      \noexpand\@elt{##1}%
+    \fi}%
+  \expandafter\xdef\csname cl@#2\endcsname{%
+    \csname cl@#2\endcsname}}}
+
+

doc/Rapport post-doc/sprmindx.sty

@@ -0,0 +1,4 @@
+delim_0 "\\idxquad "
+delim_1 "\\idxquad "
+delim_2 "\\idxquad "
+delim_n ",\\,"

doc/Rapport post-doc/subjidx.ind

@@ -0,0 +1,70 @@
+%                                                           clmomu01.ind
+%-----------------------------------------------------------------------
+% CLMoMu01 1.0: LaTeX style files for books
+% Sample index file for User's guide
+% (c) Springer-Verlag HD
+%-----------------------------------------------------------------------
+\begin{theindex}
+\item Absorption\idxquad 327
+\item Absorption of radiation \idxquad 289--292,\, 299,\,300
+\item Actinides \idxquad 244
+\item Aharonov-Bohm effect\idxquad 142--146
+\item Angular momentum\idxquad 101--112
+\subitem algebraic treatment\idxquad 391--396
+\item Angular momentum addition\idxquad 185--193
+\item Angular momentum commutation relations\idxquad 101
+\item Angular momentum quantization\idxquad 9--10,\,104--106
+\item Angular momentum states\idxquad 107,\,321,\,391--396
+\item Antiquark\idxquad 83
+\item $\alpha$-rays\idxquad 101--103
+\item Atomic theory\idxquad 8--10,\,219--249,\,327
+\item Average value\newline ({\it see also\/} Expectation value)
+15--16,\,25,\,34,\,37,\,357
+\indexspace
+\item Baker-Hausdorff formula\idxquad 23
+\item Balmer formula\idxquad 8
+\item Balmer series\idxquad 125
+\item Baryon\idxquad 220,\,224
+\item Basis\idxquad 98
+\item Basis system\idxquad 164,\,376
+\item Bell inequality\idxquad 379--381,\,382
+\item Bessel functions\idxquad 201,\,313,\,337
+\subitem spherical\idxquad 304--306,\, 309,\, 313--314,\,322
+\item Bound state\idxquad 73--74,\,78--79,\,116--118,\,202,\, 267,\,
+273,\,306,\,348,\,351
+\item Boundary conditions\idxquad 59,\, 70
+\item Bra\idxquad 159
+\item Breit-Wigner formula\idxquad 80,\,84,\,332
+\item Brillouin-Wigner perturbation theory\idxquad 203
+\indexspace
+\item Cathode rays\idxquad 8
+\item Causality\idxquad 357--359
+\item Center-of-mass frame\idxquad 232,\,274,\,338
+\item Central potential\idxquad 113--135,\,303--314
+\item Centrifugal potential\idxquad 115--116,\,323
+\item Characteristic function\idxquad 33
+\item Clebsch-Gordan coefficients\idxquad 191--193
+\item Cold emission\idxquad 88
+\item Combination principle, Ritz's\idxquad 124
+\item Commutation relations\idxquad 27,\,44,\,353,\,391
+\item Commutator\idxquad 21--22,\,27,\,44,\,344
+\item Compatibility of measurements\idxquad 99
+\item Complete orthonormal set\idxquad 31,\,40,\,160,\,360
+\item Complete orthonormal system, {\it see}\newline
+Complete orthonormal set
+\item Complete set of observables, {\it see\/} Complete
+set of operators
+\indexspace
+\item Eigenfunction\idxquad 34,\,46,\,344--346
+\subitem radial\idxquad 321
+\subsubitem calculation\idxquad 322--324
+\item EPR argument\idxquad 377--378
+\item Exchange term\idxquad 228,\,231,\,237,\,241,\,268,\,272
+\indexspace
+\item $f$-sum rule\idxquad 302
+\item Fermi energy\idxquad 223
+\indexspace
+\item H$^+_2$ molecule\idxquad 26
+\item Half-life\idxquad 65
+\item Holzwarth energies\idxquad 68
+\end{theindex}

doc/Rapport post-doc/tina.bib

@@ -0,0 +1,103 @@
+@article{berthomieu2004tool,
+  title={The tool {TINA}--Construction of Abstract State Spaces for Petri nets and Time Petri nets},
+  author={Berthomieu, Bernard and Ribet, P-O and Vernadat, Fran{\c{c}}ois},
+  journal={International Journal of Production Research},
+  volume={42},
+  number={14},
+  year={2004}
+}
+
+@inproceedings{berthomieu2008fiacre,
+  title={Fiacre: an intermediate language for model verification in the topcased environment},
+  author={Berthomieu, Bernard and Bodeveix, Jean-Paul and Farail, Patrick and Filali, Mamoun and Garavel, Hubert and Gaufillet, Pierre and Lang, Frederic and Vernadat, Fran{\c{c}}ois},
+  booktitle={ERTS 2008},
+  year={2008}
+}
+
+@inproceedings{berthomieu2010formal,
+  title={Formal Verification of AADL models with Fiacre and Tina},
+  author={Berthomieu, Bernard and Bodeveix, Jean-Paul and Dal Zilio, Silvano and Dissaux, Pierre and Filali, Mamoun and Gaufillet, Pierre and Heim, Sebastien and Vernadat, Fran{\c{c}}ois},
+  booktitle={ERTSS 2010-Embedded Real-Time Software and Systems},
+  pages={1--9},
+  year={2010}
+}
+
+@Article{BM83,
+  author =       "B. Berthomieu and M. Menasche",
+  title =        "An Enumerative Approach for Analyzing Time {P}etri Nets.",
+  journal =      "IFIP Congress Series",
+  volume =       "9",
+  pages =        "41--46",
+  publisher =    "Elsevier Science Publ. Comp. (North Holland)",
+  year =         "1983",
+}
+
+@Article{BRV04,
+ author = {Berthomieu, B. and Ribet, P.O.  and Vernadat, F.},
+ title = {The tool {T}INA -- Construction of Abstract State Spaces for {P}etri
+  {N}ets and Time Petri Nets},
+ journal = {International Journal of Production Research}, 
+ volume = 42,
+ number = 14, 
+ year = 2004}
+
+@incollection{berthomieu2014model,
+  title={Model-Checking Real-Time Properties of an Aircraft Landing Gear System Using Fiacre},
+  author={Berthomieu, B. and Dal Zilio, S. and Fronc, {\L}.},
+  booktitle={ABZ 2014: The Landing Gear Case Study},
+  pages={110--125},
+  year={2014},
+  publisher={Springer}
+}
+
+@article{zilio2015latency,
+  title={Latency Analysis of an Aerial Video Tracking System Using Fiacre and Tina},
+  author={Dal Zilio, S. and Berthomieu, B. and Le Botlan, D.},
+  journal={arXiv preprint arXiv:1509.06506},
+  year={2015}
+}
+
+@inproceedings{bourdil2014model,
+  title={Model-Checking Real-Time Properties of an Auto Flight Control System Function},
+  author={Bourdil, P.-A. and Berthomieu, B. and Jenn, E.},
+  booktitle={IEEE ISSREW},
+  year={2014}
+}
+
+@article{rangra2014sdl,
+  title={{SDL} to {Fiacre} translation},
+  author={Rangra, S. and Gaudin, E.},
+  journal={Embedded Real-Time Software and Systems, Toulouse},
+  year={2014}
+}
+
+@article{bouyer2004updatable,
+  title={Updatable timed automata},
+  author={Bouyer, Patricia and Dufourd, Catherine and Fleury, Emmanuel and Petit, Antoine},
+  journal={Theoretical Computer Science},
+  volume={321},
+  number={2-3},
+  pages={291--345},
+  year={2004},
+  publisher={Elsevier}
+}
+
+@article{larsen1997uppaal,
+  title={UPPAAL in a nutshell},
+  author={Larsen, Kim G and Pettersson, Paul and Yi, Wang},
+  journal={International journal on software tools for technology transfer},
+  volume={1},
+  number={1-2},
+  pages={134--152},
+  year={1997},
+  publisher={Springer}
+}
+
+@inproceedings{griffault2004mec,
+  title={The mec 5 model-checker},
+  author={Griffault, Alain and Vincent, Aymeric},
+  booktitle={International Conference on Computer Aided Verification},
+  pages={488--491},
+  year={2004},
+  organization={Springer}
+}

doc/TODO

@@ -0,0 +1 @@
+nettoyer les diracs: on fait des calculs de proba des mev inutiles juste pour bouffer les diracs

doc/quickstart.aux

@@ -0,0 +1,22 @@
+\relax 
+\@writefile{toc}{\contentsline {section}{\numberline {1}Preliminaries}{1}}
+\@writefile{toc}{\contentsline {section}{\numberline {2}Use}{2}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.1}Model file}{2}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.2}Init file}{2}}
+\newlabel{init}{{2.2}{3}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.3}Query specification}{3}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {2.4}Algorithm selection}{4}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.4.1}Discrete time}{4}}
+\@writefile{toc}{\contentsline {subsubsection}{\numberline {2.4.2}Continuous time}{4}}
+\@writefile{toc}{\contentsline {section}{\numberline {3}Output}{5}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.1}Textual output}{5}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.2}Graphical output for continuous time algorithms}{6}}
+\newlabel{nobounds}{{1(a)}{6}}
+\newlabel{sub@nobounds}{{(a)}{6}}
+\newlabel{bounds}{{1(b)}{6}}
+\newlabel{sub@bounds}{{(b)}{6}}
+\@writefile{lof}{\contentsline {figure}{\numberline {1}{\ignorespaces Output examples for continuous time algorithms}}{6}}
+\@writefile{lof}{\contentsline {subfigure}{\numberline{(a)}{\ignorespaces {no bounds}}}{6}}
+\@writefile{lof}{\contentsline {subfigure}{\numberline{(b)}{\ignorespaces {bounds}}}{6}}
+\newlabel{output}{{1}{6}}
+\@writefile{toc}{\contentsline {section}{\numberline {4}Note on queries}{6}}

doc/quickstart.log

@@ -0,0 +1,246 @@
+This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian) (preloaded format=pdflatex 2016.4.22)  5 OCT 2016 17:43
+entering extended mode
+ restricted \write18 enabled.
+ %&-line parsing enabled.
+**quickstart.tex
+(./quickstart.tex
+LaTeX2e <2016/02/01>
+Babel <3.9q> and hyphenation patterns for 5 language(s) loaded.
+(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
+Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
+(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
+File: size10.clo 2014/09/29 v1.4h Standard LaTeX file (size option)
+)
+\c@part=\count79
+\c@section=\count80
+\c@subsection=\count81
+\c@subsubsection=\count82
+\c@paragraph=\count83
+\c@subparagraph=\count84
+\c@figure=\count85
+\c@table=\count86
+\abovecaptionskip=\skip41
+\belowcaptionskip=\skip42
+\bibindent=\dimen102
+)
+(/usr/share/texlive/texmf-dist/tex/latex/tools/verbatim.sty
+Package: verbatim 2014/10/28 v1.5q LaTeX2e package for verbatim enhancements
+\every@verbatim=\toks14
+\verbatim@line=\toks15
+\verbatim@in@stream=\read1
+)
+(/usr/share/texlive/texmf-dist/tex/latex/subfigure/subfigure.sty
+Package: subfigure 2002/03/15 v2.1.5 subfigure package
+\subfigtopskip=\skip43
+\subfigcapskip=\skip44
+\subfigcaptopadj=\dimen103
+\subfigbottomskip=\skip45
+\subfigcapmargin=\dimen104
+\subfiglabelskip=\skip46
+\c@subfigure=\count87
+\c@lofdepth=\count88
+\c@subtable=\count89
+\c@lotdepth=\count90
+
+****************************************
+* Local config file subfigure.cfg used *
+****************************************
+(/usr/share/texlive/texmf-dist/tex/latex/subfigure/subfigure.cfg)
+\subfig@top=\skip47
+\subfig@bottom=\skip48
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphicx.sty
+Package: graphicx 2014/10/28 v1.0g Enhanced LaTeX Graphics (DPC,SPQR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/keyval.sty
+Package: keyval 2014/10/28 v1.15 key=value parser (DPC)
+\KV@toks@=\toks16
+)
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/graphics.sty
+Package: graphics 2016/01/03 v1.0q Standard LaTeX Graphics (DPC,SPQR)
+
+(/usr/share/texlive/texmf-dist/tex/latex/graphics/trig.sty
+Package: trig 2016/01/03 v1.10 sin cos tan (DPC)
+)
+(/usr/share/texlive/texmf-dist/tex/latex/latexconfig/graphics.cfg
+File: graphics.cfg 2010/04/23 v1.9 graphics configuration of TeX Live
+)
+Package graphics Info: Driver file: pdftex.def on input line 95.
+
+(/usr/share/texlive/texmf-dist/tex/latex/pdftex-def/pdftex.def
+File: pdftex.def 2011/05/27 v0.06d Graphics/color for pdfTeX
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/infwarerr.sty
+Package: infwarerr 2010/04/08 v1.3 Providing info/warning/error messages (HO)
+)
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ltxcmds.sty
+Package: ltxcmds 2011/11/09 v1.22 LaTeX kernel commands for general use (HO)
+)
+\Gread@gobject=\count91
+))
+\Gin@req@height=\dimen105
+\Gin@req@width=\dimen106
+)
+(./quickstart.aux)
+\openout1 = `quickstart.aux'.
+
+LaTeX Font Info:    Checking defaults for OML/cmm/m/it on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for T1/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OT1/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OMS/cmsy/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for OMX/cmex/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+LaTeX Font Info:    Checking defaults for U/cmr/m/n on input line 12.
+LaTeX Font Info:    ... okay on input line 12.
+
+(/usr/share/texlive/texmf-dist/tex/context/base/supp-pdf.mkii
+[Loading MPS to PDF converter (version 2006.09.02).]
+\scratchcounter=\count92
+\scratchdimen=\dimen107
+\scratchbox=\box26
+\nofMPsegments=\count93
+\nofMParguments=\count94
+\everyMPshowfont=\toks17
+\MPscratchCnt=\count95
+\MPscratchDim=\dimen108
+\MPnumerator=\count96
+\makeMPintoPDFobject=\count97
+\everyMPtoPDFconversion=\toks18
+) (/usr/share/texlive/texmf-dist/tex/generic/oberdiek/pdftexcmds.sty
+Package: pdftexcmds 2011/11/29 v0.20 Utility functions of pdfTeX for LuaTeX (HO
+)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifluatex.sty
+Package: ifluatex 2010/03/01 v1.3 Provides the ifluatex switch (HO)
+Package ifluatex Info: LuaTeX not detected.
+)
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/ifpdf.sty
+Package: ifpdf 2011/01/30 v2.3 Provides the ifpdf switch (HO)
+Package ifpdf Info: pdfTeX in PDF mode is detected.
+)
+Package pdftexcmds Info: LuaTeX not detected.
+Package pdftexcmds Info: \pdf@primitive is available.
+Package pdftexcmds Info: \pdf@ifprimitive is available.
+Package pdftexcmds Info: \pdfdraftmode found.
+)
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/epstopdf-base.sty
+Package: epstopdf-base 2010/02/09 v2.5 Base part for package epstopdf
+
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/grfext.sty
+Package: grfext 2010/08/19 v1.1 Manage graphics extensions (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/kvdefinekeys.sty
+Package: kvdefinekeys 2011/04/07 v1.3 Define keys (HO)
+))
+(/usr/share/texlive/texmf-dist/tex/latex/oberdiek/kvoptions.sty
+Package: kvoptions 2011/06/30 v3.11 Key value format for package options (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/kvsetkeys.sty
+Package: kvsetkeys 2012/04/25 v1.16 Key value parser (HO)
+
+(/usr/share/texlive/texmf-dist/tex/generic/oberdiek/etexcmds.sty
+Package: etexcmds 2011/02/16 v1.5 Avoid name clashes with e-TeX commands (HO)
+Package etexcmds Info: Could not find \expanded.
+(etexcmds)             That can mean that you are not using pdfTeX 1.50 or
+(etexcmds)             that some package has redefined \expanded.
+(etexcmds)             In the latter case, load this package earlier.
+)))
+Package grfext Info: Graphics extension search list:
+(grfext)             [.png,.pdf,.jpg,.mps,.jpeg,.jbig2,.jb2,.PNG,.PDF,.JPG,.JPE
+G,.JBIG2,.JB2,.eps]
+(grfext)             \AppendGraphicsExtensions on input line 452.
+
+(/usr/share/texlive/texmf-dist/tex/latex/latexconfig/epstopdf-sys.cfg
+File: epstopdf-sys.cfg 2010/07/13 v1.3 Configuration of (r)epstopdf for TeX Liv
+e
+))
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <12> on input line 14.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <8> on input line 14.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <6> on input line 14.
+LaTeX Font Info:    Try loading font information for OMS+cmr on input line 26.
+
+(/usr/share/texlive/texmf-dist/tex/latex/base/omscmr.fd
+File: omscmr.fd 2014/09/29 v2.5h Standard LaTeX font definitions
+)
+LaTeX Font Info:    Font shape `OMS/cmr/m/n' in size <10> not available
+(Font)              Font shape `OMS/cmsy/m/n' tried instead on input line 26.
+ [1
+
+{/var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map}]
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <7> on input line 77.
+LaTeX Font Info:    External font `cmex10' loaded for size
+(Font)              <5> on input line 77.
+ [2] [3] [4]
+Overfull \hbox (15.9971pt too wide) in paragraph at lines 270--270
+ []\OT1/cmtt/m/n/10 Check [recall of user selected algorithm] (Pr[f1Uf2](0,h) >
+= t):[] 
+ []
+
+
+Overfull \hbox (15.9971pt too wide) in paragraph at lines 287--287
+ []\OT1/cmtt/m/n/10 probability: [either a value for unbounded versions or some
+thing[] 
+ []
+
+[5] <cont.pdf, id=31, 1150.2975pt x 858.20625pt>
+File: cont.pdf Graphic file (type pdf)
+ <use cont.pdf>
+Package pdftex.def Info: cont.pdf used on input line 323.
+(pdftex.def)             Requested size: 172.5pt x 128.6861pt.
+
+<boundedcont.pdf, id=32, 1000.73875pt x 828.09375pt>
+File: boundedcont.pdf Graphic file (type pdf)
+ <use boundedcont.pdf>
+Package pdftex.def Info: boundedcont.pdf used on input line 327.
+(pdftex.def)             Requested size: 155.24895pt x 128.45428pt.
+
+[6 <./cont.pdf> <./boundedcont.pdf>]
+Overfull \hbox (16.25519pt too wide) in paragraph at lines 376--376
+[]      \OT1/cmtt/m/n/8 <xs:element name="value" type="initvalue" minOccurs="0"
+ maxOccurs="unbounded"/>[] 
+ []
+
+
+Overfull \hbox (7.75507pt too wide) in paragraph at lines 382--382
+[]      \OT1/cmtt/m/n/8 <xs:element name="event" type="initlaw" minOccurs="0" m
+axOccurs="unbounded"/>[] 
+ []
+
+[7] (./quickstart.aux) ) 
+Here is how much of TeX's memory you used:
+ 1717 strings out of 494924
+ 24547 string characters out of 6179708
+ 81319 words of memory out of 5000000
+ 5004 multiletter control sequences out of 15000+600000
+ 8577 words of font info for 31 fonts, out of 8000000 for 9000
+ 14 hyphenation exceptions out of 8191
+ 37i,6n,24p,236b,297s stack positions out of 5000i,500n,10000p,200000b,80000s
+</usr/share/texlive/texmf-dist/fonts/type1/public/amsfo
+nts/cm/cmbx10.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm
+/cmbx12.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi1
+0.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi7.pfb><
+/usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb></usr/sh
+are/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr12.pfb></usr/share/tex
+live/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb></usr/share/texlive/te
+xmf-dist/fonts/type1/public/amsfonts/cm/cmr7.pfb></usr/share/texlive/texmf-dist
+/fonts/type1/public/amsfonts/cm/cmr8.pfb></usr/share/texlive/texmf-dist/fonts/t
+ype1/public/amsfonts/cm/cmsy10.pfb></usr/share/texlive/texmf-dist/fonts/type1/p
+ublic/amsfonts/cm/cmsy7.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/a
+msfonts/cm/cmti10.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfont
+s/cm/cmtt10.pfb></usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/c
+mtt8.pfb>
+Output written on quickstart.pdf (7 pages, 254520 bytes).
+PDF statistics:
+ 92 PDF objects out of 1000 (max. 8388607)
+ 64 compressed objects within 1 object stream
+ 0 named destinations out of 1000 (max. 500000)
+ 11 words of extra memory for PDF output out of 10000 (max. 10000000)
+

doc/quickstart.tex

@@ -0,0 +1,407 @@
+\documentclass[a4paper]{article}
+
+%\usepackage{a4wide}
+\usepackage{verbatim}
+\usepackage{subfigure}
+\usepackage{graphicx}
+
+\title{Epoch QuickStart guide}
+\author{Guillaume Infantes}
+\date{January 21, 2013}
+
+\begin{document}
+
+\maketitle
+
+This guide describes usage of EPOCH temporal probabilistic assessment
+tool  as of version 20130121.
+
+\section{Preliminaries}
+
+Epoch aims at ensuring the \emph{validity} of \emph{temporal
+  properties} from an \emph{initial state} of a given
+\emph{dynamic model}.
+
+\begin{itemize}
+\item The \emph{validity} is simply a true/false value output as a 1
+  or 0.  
+\item The \emph{temporal property} is for now only a small subset of
+  PTCL* (more on this below).
+\item The \emph{dynamic model} of the system is given as an AltaRica
+  file, that can be directly exported from modelling/assessment tools
+  like OCAS or others. 
+\item The \emph{initial state} may be specified directly in the
+  dynamic model itself (``init'' keyword of AltaRica  
+  files, can be given from  the tool used to build the model itself);
+  or it can be specified as a separate file (see section \ref{init}). 
+\end{itemize}
+
+For version 20130121, time can have two very different semantics: 
+\begin{itemize}
+\item First is an ``abstract'' notion meaning a timestep, that is
+any change in the system. It is denoted \emph{discrete} time. 
+\item Second is the natural time, meaning a real time in
+  seconds/hours. It is denoted \emph{continuous} time.  
+\end{itemize}
+
+\subsection*{Temporal properties}
+
+A temporal property is generally a property on possible execution
+paths of the dynamic model (see technical report DCSD-T/R-120/11 for a
+general presentation). Epoch currently handles only simples
+constructs that should be sufficient for DIANA needs. We call a \emph{query} the
+asking for a check of a temporal property. 
+
+An example of  query is: ``is the probability that variable FC\_x takes the
+value true whithin 3 time units greater than 10e-9 ?''. 
+
+\begin{itemize}
+\item For discrete version the time unit is a timestep,
+i.e. a (non-immediate) change in the system. This means  
+that if  the model is a failure propagation model, then 3 timesteps
+means 3 failure events. Immediate  events are denoted
+``dirac(0)'' and are not taken into account for the horizon, as they
+are used for ease of modelling in order to make the tool compute the
+state of the system for non-trivial updates. For instance, in the
+Bleed model, many dirac(0) updates are necessary to compute the
+resulting pressures after any event, while these intermediate states do
+not have any physical reality. 
+\item For continuous time, the semantic of time is the intuitive one. The
+unit is not specified, it just has to be consistent over the model and
+the queries. 
+\end{itemize}
+
+
+
+Formally, the previous queries can be written as:
+\begin{displaymath}
+ ?    P_{\le{3}}(true~Until~FC\_x=true) \ge 10^{-9} 
+\end{displaymath}
+
+We will see in next section how to specify such query within EPOCH.
+
+
+\section{Use}
+
+
+\verb?--help? gives description of command-line options.\\
+\verb?--verbosity? changes text output information level.
+
+\subsection{Model file}
+
+\verb?--file? gives the name of the dynamic model
+(including initial state) to check. As files are not searched in any
+particular directory (except current directory), we strongly encourage
+to give full qualified names.\\ Example: \verb?--file $HOME/model.alt?
+
+\subsection{Init file}
+\verb?--init? allows to give path to a xml file specifying initial
+values. If initial values are specified both in model and init file,
+init file values are used. 
+An example is show below:
+{\footnotesize
+\begin{verbatim}
+<?xml version="1.0" encoding="ISO-8859-1"?>
+<init 
+xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
+xsi:noNamespaceSchemaLocation="./init.xsd">
+<node>
+  <name>Rudder_BPS_RB</name>
+  <type>class</type>
+  <laws>
+    <event name="loss" law="exp" param="1E-5"/>
+  </laws>
+  <values>
+    <value var="Status" val="hs"/>
+  </values>
+</node>
+<node>
+  <name>main.BCM</name>
+  <laws>
+    <event name="loss" law="exp" param="2E-5"/>
+  </laws>
+  <values>
+    <value var="Status" val="hs"/>
+  </values>
+</node>
+</init>
+\end{verbatim}
+}
+The user has to specify the nodes where init values has to be set,
+using the \verb?<node>? tag. 
+Inside a node, several fields have to be specified:
+\begin{itemize}
+\item \verb?<name>node_name</name>?: specifies the name of the
+  node. It can be:
+  \begin{itemize}
+  \item an instance, and so the full
+    name has to be given, as for \verb?main.BCM? (in this case
+    \verb?<type>instance</type>? is assumed as default)
+  \item a node definition (will affect all its instances). In
+    this case, the \verb?<type>class</type>? has to be   
+    added (\verb?Rudder_BPS_RB? example).
+  \end{itemize}
+\item \verb?<laws>? allows to change event law, specified by a list of
+  tags with the syntax   \verb?<event name="ename" law="elaw" param="val"/>?; where
+\verb?ename? is the event name inside the node, \verb?law? can be \verb?dirac? or \verb?exp?,
+and \verb?val? can be \verb?0? (for diracs) or any double (for
+exponential law rates). Doubles can be stated as \verb?1.5E-5? for example.
+\item \verb?<values>? start a list of initial values stated with the
+  following general syntax:
+  \verb?<value var="varName" val="varValue"/>?, where \verb?varName?
+  is the name of the variable (a string) and \verb?varValue? its
+  initial value (also a string). 
+\end{itemize}
+\label{init}
+
+The complete XSD definition is given at the end of the document.
+
+\subsection{Query specification}
+
+As the query is quite complicated, several switches are mandatory for
+query specification.  In the following , we will use $?
+P_{\le{3}}(true~Until~FC\_x=true) \ge 10^{-9}$ as an example.
+
+
+\subsubsection*{Variable}
+\verb?--var? gives the name of the variable to check. The variable name has to be the full qualified
+\emph{case-senstive} AltaRica name of the variable instance. \\Example:
+\verb? --var main.LGERS.SAFETY.fc_safety^FC15? (from A380 LGERS model)
+
+\subsubsection*{Value}
+\verb?--value? value of the variable. For string/enum values, the
+argument is \emph{case-sensitive}.\\ Examples: ``\verb?--value true?''  ``\verb?--value OK?''
+
+\subsubsection*{Time horizon}
+\verb?--dhor? specify time horizon for discrete time property checking. \\Example:
+\verb?--dhor 3?\\
+\verb?--chor? specify time horizon for continuous time property checking. \\Example:
+\verb?--chor 3?
+
+
+\subsubsection*{Probability threshold}
+\verb?--thres? threshold for probability. \\Example:
+\verb?--thres 10e-9?
+
+\subsubsection*{Negation of the property}
+\verb?--neg? specifies $\neq$  instead of $=$ for the inner property. For example, if
+FC\_x can be ``false'', ``true'' or ``dont\_know'', and both ``true'' and ``dont\_know''
+are problematic, then the property to check is FC\_x $\neq$ false and
+one has to call EPOCH with:\\ \verb?--var FC_x --value false --neg?
+
+\subsection{Algorithm selection}
+
+Several algorithms can be used by EPOCH. They are selected with the 
+
+\verb?--algo? switch. 
+
+\verb?-1? runs all algorithms one after the other (usefull
+  only for testing purposes).
+\subsubsection{Discrete time}
+\begin{itemize}
+\item \verb?0? runs exact computation over infinite time (do not
+  honor \verb?--dhor? switch). Not usefull for DIANA.
+\item \verb?1? runs iterative computation over infinite time (do not
+  honor \verb?--dhor? switch). Not usefull for DIANA.
+\item \verb?2? runs exact computation over infinite time using
+  bound mechanism (do not  honor \verb?--dhor? switch). Not usefull
+  for DIANA.
+\item \verb?3? runs iterative computation over infinite time using
+  bound mechanism (do not  honor \verb?--dhor? switch). Not usefull
+  for DIANA.
+\item \verb?4? runs exact computation over finite time specified
+  by \verb?--dhor? switch.
+\item \verb?5? (default) runs exact computation over finite time specified
+  by \verb?--dhor? switch, using the bound mechanism.
+\end{itemize}
+
+Algorithm 5 is designed to be the most efficient and should be used
+for DIANA for discrete time computations.
+
+\subsubsection{Continuous time}
+\begin{itemize}
+\item \verb?6? runs exact computation without bounding mechanism. 
+\item \verb?7? runs exact computation with bounding mechanism.
+\end{itemize}
+
+These algorithms comes with different implementations for internal
+Hessenberg matrices, that can be changed using the \verb?--hess?
+switch.
+
+\begin{itemize}
+\item \verb?0? triangular Hessenberg matrices
+\item \verb?1? banded Hessenberg matrices
+\item \verb?2? dense Hessenberg matrices
+\end{itemize}
+
+Default value is \verb?0?, this aims to be the most efficient version.
+
+\section{Output}
+
+\subsection{Textual output}
+
+Currently, default output gives the following informations:
+
+\begin{itemize}
+\item 
+\begin{verbatim}
+f1: true
+\end{verbatim}
+Generally, we check $f1~Until~f2$ formulas, but for now f1 is always true;
+\item 
+\begin{verbatim}
+f2: P
+\end{verbatim}
+ where P is the property to check (defined with \verb?--var?, \verb?--value?, \verb?--neg?);
+\item then some data about the model are given:
+\begin{verbatim}
+MODEL STATS:
+number of state vars: s
+number of _different_ flow vars: f
+number of atomic events: e
+\end{verbatim}
+s is the total number of states variables in the fully instanciated model; f
+is the number of different flow variables (for assertions of type
+$v1=v2$, only one instance is considered); e is the number of events
+(generally failures), including dirac(0) but not taking into account
+synchronizations. 
+\item 
+\begin{verbatim}
+Check [recall of user selected algorithm] (Pr[f1Uf2](0,h) >= t):
+\end{verbatim}
+where h is the horizon given by \verb?--hor? and t is the probability
+threshold given by \verb?--thres?. \\
+For continuous time algorithms, the probability at specified time is
+given once here: \verb?PROB: xx.xxx?
+\\The following 0 or 1 is the
+result for the query; 0 for false, 1 for true. \emph{For 
+  scripting purposes, this value is also given to the shell as an
+  exit value} \verb!$?!.
+\item 
+\begin{verbatim}
+time taken: n seconds
+\end{verbatim}
+n is the time taken by the  execution (if alone);
+\item 
+\begin{verbatim}
+probability: [either a value for unbounded versions or something
+like:] [ {([0,10]->0)} ; {([0,10]->0)} ]
+\end{verbatim}
+ gives the  probabilities as intervals. The format for  bounded
+ version is
+  [l,u], where l is the lower bound, u the upper, and l,u are given as
+  interval/value sequences, $\{(i_1)  (i_2) \ldots\}$, whith $i_i$ of the form
+  \verb![a,b] -> p!, meaning that from timestep $a$ to timestep $b$, the
+  probability of the property is $p$. 
+\item 
+\begin{verbatim}
+explored states: n
+\end{verbatim}
+ here n is the total number of states
+  that EPOCH had to instanciate in order to answer the query.
+\end{itemize}
+
+
+\subsection{Graphical output for continuous time algorithms}
+For continuous time algorithms, a graphical view of the analytical
+solution is displayed, as shown on figure \ref{output}.
+
+In these figures, x-axis is time, y-axis is probability, vertical bold
+yellow line shows time horizon specified by the query. 
+
+In unbounded version (figure \ref{nobounds}), the red line show the
+evolution of the probability of the specified property with time. 
+In bounded version, as in example of figure \ref{bounds}, the red and
+blue curves show the  enveloppe of the 
+true probability which is sufficient to answer the query. 
+
+\begin{figure}[ht]
+\begin{center}
+  \subfigure[no bounds]{
+  \includegraphics[width=.5\textwidth]{cont}
+  \label{nobounds}
+  }
+  \subfigure[bounds]{
+    \includegraphics[width=.45\textwidth]{boundedcont}
+  \label{bounds}
+  }
+  \end{center}
+\caption{Output examples for continuous time algorithms}
+\label{output}
+\end{figure}
+
+
+\section{Note on queries}
+Due to the bound mechanism used by the ``bounded'' algorithms, it can
+be interesting to ask for the complementary query, depending on the
+model. For instance,  $?P_{\le{3}}(true~Until~FC\_x\neq true) \le
+1-10^{-9}$ gives the same information as $?P_{\le{3}}(true~Until~
+FC\_x=true) \le 10^{-9}$. Depending on the model, these
+two queries may need very different  computation times.
+
+\newpage
+\section*{XSD definition of init files}
+\footnotesize{
+\begin{verbatim}
+<?xml version="1.0" encoding="UTF-8"?>
+<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
+
+  <xs:complexType name="initvalue">
+    <xs:attribute name="var" type="xs:string" use="required"/>
+    <xs:attribute name="val" type="xs:string" use="required"/>      
+  </xs:complexType>
+
+  <xs:simpleType name="lawType">
+    <xs:restriction base="xs:string">
+      <xs:enumeration value="dirac"/>
+      <xs:enumeration value="exp"/>
+    </xs:restriction>
+  </xs:simpleType>
+
+  <xs:complexType name="initlaw">
+      <xs:attribute name="name" type="xs:string" use="required"/>
+      <xs:attribute name="law" type="lawType"/>
+      <xs:attribute name="param" type="xs:double" default="0"/>
+  </xs:complexType>
+
+  <xs:simpleType name="nodeType">
+    <xs:restriction base="xs:string">
+      <xs:enumeration value="instance"/>
+      <xs:enumeration value="class"/>
+    </xs:restriction>
+  </xs:simpleType>
+
+  <xs:complexType name="initvalues">
+    <xs:sequence>
+      <xs:element name="value" type="initvalue" minOccurs="0" maxOccurs="unbounded"/>
+    </xs:sequence>
+  </xs:complexType>
+
+  <xs:complexType name="initlaws">
+    <xs:sequence>
+      <xs:element name="event" type="initlaw" minOccurs="0" maxOccurs="unbounded"/>
+    </xs:sequence>
+  </xs:complexType>
+
+<xs:complexType name="initnode">
+  <xs:all>
+    <xs:element  name="type" type="nodeType" default="instance" minOccurs="0"/> 
+    <xs:element name="name" type="xs:string"/>
+    <xs:element name="values" type="initvalues" minOccurs="0"/>
+    <xs:element name="laws" type="initlaws" minOccurs="0"/>
+  </xs:all>
+</xs:complexType>
+
+<xs:element name="init">
+  <xs:complexType>
+    <xs:sequence>
+      <xs:element name="node" type="initnode" maxOccurs="unbounded"/>
+    </xs:sequence>
+  </xs:complexType>
+</xs:element>
+
+</xs:schema>
+\end{verbatim}
+}
+
+\end{document}

icons/document-build-model-16.xpm

@@ -0,0 +1,162 @@
+/* XPM */
+static const char * document_build_model_16_xpm[] = {
+"16 16 143 2",
+"  	c None",
+". 	c #5EBF25",
+"+ 	c #88D159",
+"@ 	c #B4E493",
+"# 	c #7BC65C",
+"$ 	c #53BA1A",
+"% 	c #92E23E",
+"& 	c #A3F239",
+"* 	c #A1F039",
+"= 	c #88DB3B",
+"- 	c #61BD36",
+"; 	c #128809",
+"> 	c #41B100",
+", 	c #92E23F",
+"' 	c #A1F724",
+") 	c #BBFF4D",
+"! 	c #B6FF40",
+"~ 	c #99EF26",
+"{ 	c #64C61F",
+"] 	c #168E01",
+"^ 	c #36A700",
+"/ 	c #7DD72B",
+"( 	c #B8FA59",
+"_ 	c #E2FFB3",
+": 	c #C8FD77",
+"< 	c #9AE840",
+"[ 	c #4CB80D",
+"} 	c #0E8700",
+"| 	c #1D9100",
+"1 	c #41B400",
+"2 	c #7ED72D",
+"3 	c #AAE869",
+"4 	c #9ADF60",
+"5 	c #61C224",
+"6 	c #269D00",
+"7 	c #017D00",
+"8 	c #48820A",
+"9 	c #3FA429",
+"0 	c #73C549",
+"a 	c #9EDB76",
+"b 	c #8CD361",
+"c 	c #5CB838",
+"d 	c #239118",
+"e 	c #007B00",
+"f 	c #6DA8F7",
+"g 	c #5691E1",
+"h 	c #FEC33B",
+"i 	c #FFC45B",
+"j 	c #FFCD77",
+"k 	c #7AA63A",
+"l 	c #79C26E",
+"m 	c #A7D796",
+"n 	c #98D185",
+"o 	c #66B54D",
+"p 	c #3DA970",
+"q 	c #74D2EF",
+"r 	c #7DD8FE",
+"s 	c #7CD4FF",
+"t 	c #59ACF2",
+"u 	c #F9CB30",
+"v 	c #FEE64B",
+"w 	c #FFE23B",
+"x 	c #FEDD3C",
+"y 	c #FFD93C",
+"z 	c #C0BF29",
+"A 	c #85C383",
+"B 	c #80B757",
+"C 	c #31CAC9",
+"D 	c #45D9FF",
+"E 	c #44E6FE",
+"F 	c #46E7FF",
+"G 	c #3EDAFF",
+"H 	c #43C8FF",
+"I 	c #34B1F8",
+"J 	c #F7C424",
+"K 	c #FFE769",
+"L 	c #FFF96F",
+"M 	c #FFFE5C",
+"N 	c #FFFC6A",
+"O 	c #FFF36A",
+"P 	c #EDDD30",
+"Q 	c #C7BF34",
+"R 	c #45DEC3",
+"S 	c #75F6FF",
+"T 	c #7AFCFF",
+"U 	c #7DFDFF",
+"V 	c #6BF4FF",
+"W 	c #56E3FF",
+"X 	c #27BEFF",
+"Y 	c #F7BA22",
+"Z 	c #FFD534",
+"` 	c #FFED71",
+" .	c #FFF292",
+"..	c #FFE876",
+"+.	c #FFE45A",
+"@.	c #E4CD21",
+"#.	c #C1B232",
+"$.	c #1DBFC4",
+"%.	c #5EE0FF",
+"&.	c #84EFFE",
+"*.	c #88E7FB",
+"=.	c #76DCFA",
+"-.	c #31C8FF",
+";.	c #1FA6FB",
+">.	c #F7A81B",
+",.	c #FEC32D",
+"'.	c #FFD553",
+").	c #FFE082",
+"!.	c #FFDD78",
+"~.	c #FFC944",
+"{.	c #E2B51F",
+"].	c #BD9A2B",
+"^.	c #1398BE",
+"/.	c #3DBFFF",
+"(.	c #73D3FE",
+"_.	c #81D8FE",
+":.	c #58C4FD",
+"<.	c #299EF4",
+"[.	c #136ADB",
+"}.	c #FEC04E",
+"|.	c #FED979",
+"1.	c #FFE293",
+"2.	c #FFDB80",
+"3.	c #FFD067",
+"4.	c #E0AE2D",
+"5.	c #946611",
+"6.	c #1E6199",
+"7.	c #6DB8F7",
+"8.	c #84CAF9",
+"9.	c #8ACEF9",
+"0.	c #69B6F2",
+"a.	c #468BE3",
+"b.	c #0B2DA6",
+"c.	c #EDAF57",
+"d.	c #FFEAB7",
+"e.	c #FFD78E",
+"f.	c #C88D38",
+"g.	c #2946A2",
+"h.	c #9AB6E7",
+"i.	c #ABC7ED",
+"j.	c #506CBE",
+"k.	c #BA6F2B",
+"l.	c #1C1F6B",
+"                                ",
+"          . + @ #               ",
+"        $ % & * = - ;           ",
+"      > , ' ) ! ~ { ]           ",
+"      ^ / ( _ : < [ }           ",
+"      | 1 2 3 4 5 6 7           ",
+"      8 9 0 a b c d e f g       ",
+"  h i j k l m n o p q r s t     ",
+"u v w x y z A B C D E F G H I   ",
+"J K L M N O P Q R S T U V W X   ",
+"Y Z `  ...+.@.#.$.%.&.*.=.-.;.  ",
+">.,.'.).!.~.{.].^./.(._.:.<.[.  ",
+"  }.|.1.2.3.4.5.6.7.8.9.0.a.b.  ",
+"    c.d.e.f.      g.h.i.j.      ",
+"      k.              l.        ",
+"                                "};

icons/document-build-model-24.xpm

@@ -0,0 +1,343 @@
+/* XPM */
+static const char * document_build_model_24_xpm[] = {
+"24 24 316 2",
+"  	c None",
+". 	c #76C454",
+"+ 	c #80C66B",
+"@ 	c #55B03B",
+"# 	c #74CA3D",
+"$ 	c #9EDD70",
+"% 	c #A6E178",
+"& 	c #A8E07E",
+"* 	c #98D675",
+"= 	c #64B945",
+"- 	c #178E00",
+"; 	c #41AE12",
+"> 	c #7DD040",
+", 	c #97E24B",
+"' 	c #A0EB48",
+") 	c #A4EE48",
+"! 	c #9EE848",
+"~ 	c #8FDD48",
+"{ 	c #7FCE4C",
+"] 	c #57B439",
+"^ 	c #128907",
+"/ 	c #44B309",
+"( 	c #68C820",
+"_ 	c #7BDA1B",
+": 	c #91F10E",
+"< 	c #A7FC23",
+"[ 	c #ADFE2E",
+"} 	c #A2FA1B",
+"| 	c #88E90F",
+"1 	c #72D31C",
+"2 	c #58BB23",
+"3 	c #27990E",
+"4 	c #047200",
+"5 	c #45B700",
+"6 	c #96E14C",
+"7 	c #A1F038",
+"8 	c #B4FD41",
+"9 	c #BDFF54",
+"0 	c #C8FF72",
+"a 	c #BAFF4B",
+"b 	c #AFF941",
+"c 	c #85DD2E",
+"d 	c #55BD15",
+"e 	c #209701",
+"f 	c #046C00",
+"g 	c #3DB000",
+"h 	c #79D42A",
+"i 	c #AAF052",
+"j 	c #BBFD54",
+"k 	c #DFFFAB",
+"l 	c #E9FFC7",
+"m 	c #CCFD80",
+"n 	c #9EEF36",
+"o 	c #7FD730",
+"p 	c #43B308",
+"q 	c #199200",
+"r 	c #016A00",
+"s 	c #2FA400",
+"t 	c #50BE05",
+"u 	c #80DB28",
+"v 	c #ADF158",
+"w 	c #B6F758",
+"x 	c #BFF47A",
+"y 	c #ABEC61",
+"z 	c #92DD4D",
+"A 	c #5AC311",
+"B 	c #30A400",
+"C 	c #0D8800",
+"D 	c #006800",
+"E 	c #1A9200",
+"F 	c #35A900",
+"G 	c #51BE04",
+"H 	c #80D538",
+"I 	c #9ADF5A",
+"J 	c #A6E36D",
+"K 	c #9ADD66",
+"L 	c #6AC431",
+"M 	c #38A909",
+"N 	c #017E00",
+"O 	c #078100",
+"P 	c #2A9A13",
+"Q 	c #5AB733",
+"R 	c #76C946",
+"S 	c #92D863",
+"T 	c #A1DD75",
+"U 	c #8CD35F",
+"V 	c #62BD37",
+"W 	c #3EA523",
+"X 	c #12880B",
+"Y 	c #007D00",
+"Z 	c #0D753E",
+"` 	c #3F82DF",
+" .	c #3573D6",
+"..	c #FFB458",
+"+.	c #8CA545",
+"@.	c #329829",
+"#.	c #65B853",
+"$.	c #81C864",
+"%.	c #96D476",
+"&.	c #A0D883",
+"*.	c #87CC67",
+"=.	c #6EBE53",
+"-.	c #4EAA3A",
+";.	c #1D8D12",
+">.	c #2B994F",
+",.	c #6BC0D0",
+"'.	c #9CD9FE",
+").	c #96D0FA",
+"!.	c #5AA2EC",
+"~.	c #2377DB",
+"{.	c #FEC729",
+"].	c #FECB50",
+"^.	c #FFCD63",
+"/.	c #FFCD68",
+"(.	c #FECB67",
+"_.	c #D5BC55",
+":.	c #54A237",
+"<.	c #91CD81",
+"[.	c #A6D698",
+"}.	c #A9D79E",
+"|.	c #9BD28B",
+"1.	c #78BF60",
+"2.	c #35A04D",
+"3.	c #59C3CD",
+"4.	c #6DD4F6",
+"5.	c #73DAFF",
+"6.	c #71D7FF",
+"7.	c #70D4FF",
+"8.	c #6CCCFE",
+"9.	c #5FB4F6",
+"0.	c #2B7BDD",
+"a.	c #FFDB3F",
+"b.	c #FEDF3F",
+"c.	c #FFDD44",
+"d.	c #FFDA45",
+"e.	c #FED644",
+"f.	c #FFD443",
+"g.	c #F2CA3B",
+"h.	c #68A52A",
+"i.	c #A6D49E",
+"j.	c #B4D9AC",
+"k.	c #67B35C",
+"l.	c #25B190",
+"m.	c #3ECBFF",
+"n.	c #49D8FF",
+"o.	c #4DE0FE",
+"p.	c #4FE4FF",
+"q.	c #4FE1FF",
+"r.	c #4ADAFF",
+"s.	c #47CEFE",
+"t.	c #43C2FF",
+"u.	c #37A8F6",
+"v.	c #208CE3",
+"w.	c #FFD946",
+"x.	c #FFEE61",
+"y.	c #FFF554",
+"z.	c #FFF43C",
+"A.	c #FFF030",
+"B.	c #FEED30",
+"C.	c #FFEA4A",
+"D.	c #FFE74F",
+"E.	c #9FC22F",
+"F.	c #A2B727",
+"G.	c #9CBC4B",
+"H.	c #3DE2CD",
+"I.	c #5DE9E5",
+"J.	c #57ECFF",
+"K.	c #45F3FF",
+"L.	c #40F6FF",
+"M.	c #3BF4FF",
+"N.	c #49ECFF",
+"O.	c #51E1FF",
+"P.	c #4AD8FE",
+"Q.	c #39CDFF",
+"R.	c #21ACEF",
+"S.	c #FFD43D",
+"T.	c #FFE96D",
+"U.	c #FFF472",
+"V.	c #FFFC76",
+"W.	c #FFFE72",
+"X.	c #FFFE8C",
+"Y.	c #FEF668",
+"Z.	c #FFEF64",
+"`.	c #EBDF3B",
+" +	c #E5C91A",
+".+	c #A7BA4B",
+"++	c #31D3C7",
+"@+	c #6DEAE0",
+"#+	c #71F6FF",
+"$+	c #8CFCFF",
+"%+	c #9BFDFE",
+"&+	c #A4FDFF",
+"*+	c #71F7FF",
+"=+	c #61EBFE",
+"-+	c #4BDAFF",
+";+	c #28C0FF",
+">+	c #1D9FEB",
+",+	c #FFCA29",
+"'+	c #FFDD45",
+")+	c #FFED71",
+"!+	c #FFF37B",
+"~+	c #FFF9BC",
+"{+	c #FFF065",
+"]+	c #FFEE81",
+"^+	c #FFE857",
+"/+	c #E9D426",
+"(+	c #E3C119",
+"_+	c #A5B14A",
+":+	c #1EC0C7",
+"<+	c #43D6E0",
+"[+	c #75EAFF",
+"}+	c #83F2FF",
+"|+	c #ABF5FE",
+"1+	c #76EEFD",
+"2+	c #82E8FD",
+"3+	c #5EDEFE",
+"4+	c #2FC6FF",
+"5+	c #24B2FE",
+"6+	c #1989E1",
+"7+	c #FFBF23",
+"8+	c #FFCE28",
+"9+	c #FFDC47",
+"0+	c #FFE469",
+"a+	c #FFE586",
+"b+	c #FFDD7A",
+"c+	c #FFD86B",
+"d+	c #FFCE38",
+"e+	c #E7C620",
+"f+	c #E2B716",
+"g+	c #A3A347",
+"h+	c #16ACC7",
+"i+	c #26BDE0",
+"j+	c #45CFFF",
+"k+	c #73DDFE",
+"l+	c #6FD9FC",
+"m+	c #8CDAFA",
+"n+	c #6ECCF8",
+"o+	c #39B9F8",
+"p+	c #23B1FD",
+"q+	c #1C98F5",
+"r+	c #1266CD",
+"s+	c #FFB322",
+"t+	c #FEC73D",
+"u+	c #FFD255",
+"v+	c #FFD96B",
+"w+	c #FFE38D",
+"x+	c #FFD463",
+"y+	c #FFC843",
+"z+	c #E6B526",
+"A+	c #E0A713",
+"B+	c #9E8C3F",
+"C+	c #1086B9",
+"D+	c #31ABDE",
+"E+	c #4EC1FF",
+"F+	c #69CFFE",
+"G+	c #80D7FE",
+"H+	c #84D8FE",
+"I+	c #63CAFE",
+"J+	c #3FB1FB",
+"K+	c #2890EC",
+"L+	c #1369D8",
+"M+	c #0A3EB6",
+"N+	c #F9AE33",
+"O+	c #FFCB5B",
+"P+	c #FED56F",
+"Q+	c #FFDB7C",
+"R+	c #FFE396",
+"S+	c #FFDD82",
+"T+	c #FED56E",
+"U+	c #E5B736",
+"V+	c #D99E17",
+"W+	c #936E2A",
+"X+	c #1A65A3",
+"Y+	c #4C9ED1",
+"Z+	c #69BDF8",
+"`+	c #77C9FB",
+" @	c #8CD4FD",
+".@	c #85D0FC",
+"+@	c #69BEF7",
+"@@	c #54A8EF",
+"#@	c #3983E1",
+"$@	c #174AC3",
+"%@	c #031894",
+"&@	c #E4A13A",
+"*@	c #FFD275",
+"=@	c #FFE29A",
+"-@	c #FEE4A3",
+";@	c #FFDF94",
+">@	c #FFDB86",
+",@	c #FFC056",
+"'@	c #BC8C24",
+")@	c #76520A",
+"!@	c #2D5CAA",
+"~@	c #71A4E6",
+"{@	c #92C5F0",
+"]@	c #9CCAF1",
+"^@	c #90C3EF",
+"/@	c #82B8EC",
+"(@	c #5586D9",
+"_@	c #254AAB",
+":@	c #06166C",
+"<@	c #B77523",
+"[@	c #FFCA80",
+"}@	c #FFEABD",
+"|@	c #FFDB9C",
+"1@	c #DE993D",
+"2@	c #112489",
+"3@	c #758AD5",
+"4@	c #C0D4F0",
+"5@	c #A4BAE8",
+"6@	c #3D51B4",
+"7@	c #0A1658",
+"8@	c #EC9B50",
+"9@	c #8E4500",
+"0@	c #454CAF",
+"a@	c #070A69",
+"                                                ",
+"                    . + @                       ",
+"                # $ % & * = -                   ",
+"            ; > , ' ) ! ~ { ] ^                 ",
+"          / ( _ : < [ } | 1 2 3 4               ",
+"          5 6 7 8 9 0 a b c d e f               ",
+"          g h i j k l m n o p q r               ",
+"          s t u v w x y z A B C D               ",
+"          E F G H I J K L M q N D               ",
+"          O P Q R S T U V W X Y Z `  .          ",
+"        ..+.@.#.$.%.&.*.=.-.;.>.,.'.).!.~.      ",
+"  {.].^./.(._.:.<.[.}.|.1.2.3.4.5.6.7.8.9.0.    ",
+"  a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.  ",
+"  w.x.y.z.A.B.C.D.E.F.G.H.I.J.K.L.M.N.O.P.Q.R.  ",
+"  S.T.U.V.W.X.Y.Z.`. +.+++@+#+$+%+&+*+=+-+;+>+  ",
+"  ,+'+)+!+~+{+]+^+/+(+_+:+<+[+}+|+1+2+3+4+5+6+  ",
+"  7+8+9+0+a+b+c+d+e+f+g+h+i+j+k+l+m+n+o+p+q+r+  ",
+"  s+t+u+v+w+b+x+y+z+A+B+C+D+E+F+G+H+I+J+K+L+M+  ",
+"  N+O+P+Q+R+S+T+O+U+V+W+X+Y+Z+`+ @.@+@@@#@$@%@  ",
+"    &@*@=@-@;@>@,@'@)@    !@~@{@]@^@/@(@_@:@    ",
+"      <@[@}@|@1@            2@3@4@5@6@7@        ",
+"          8@9@                  0@a@            ",
+"                                                ",
+"                                                "};

icons/document-switch-mode-16.xpm

@@ -0,0 +1,60 @@
+/* XPM */
+static const char * document_switch_mode_16_xpm[] = {
+"16 16 41 1",
+" 	c None",
+".	c #909090",
+"+	c #8D8D8D",
+"@	c #9B9B9B",
+"#	c #9A9A9A",
+"$	c #999999",
+"%	c #989898",
+"&	c #979797",
+"*	c #969696",
+"=	c #A2A2A2",
+"-	c #9F9F9F",
+";	c #8F8F8F",
+">	c #A3A3A3",
+",	c #A9A9A9",
+"'	c #A8A8A8",
+")	c #A6A6A6",
+"!	c #9C9C9C",
+"~	c #929292",
+"{	c #7B7B7B",
+"]	c #A4A4A4",
+"^	c #AAAAAA",
+"/	c #9D9D9D",
+"(	c #8A8A8A",
+"_	c #888888",
+":	c #898989",
+"<	c #8C8C8C",
+"[	c #848484",
+"}	c #828282",
+"|	c #A0A0A0",
+"1	c #808080",
+"2	c #727272",
+"3	c #747474",
+"4	c #757575",
+"5	c #7C7C7C",
+"6	c #7A7A7A",
+"7	c #939393",
+"8	c #838383",
+"9	c #858585",
+"0	c #878787",
+"a	c #818181",
+"b	c #737373",
+"                ",
+"                ",
+"                ",
+"            .+  ",
+"      @#$%&*=-; ",
+"     >,,'')-!@~{",
+"     ]^,/~(_:<: ",
+"   @        [_  ",
+" })|1 2234  5   ",
+"6>=7_:(+;.+     ",
+"}$;}}890::0     ",
+" 35ab           ",
+"   b            ",
+"                ",
+"                ",
+"                "};

icons/document-switch-mode-24.xpm

@@ -0,0 +1,80 @@
+/* XPM */
+static const char * document_switch_mode_24_xpm[] = {
+"24 24 53 1",
+" 	c None",
+".	c #9A9A9A",
+"+	c #A2A2A2",
+"@	c #A1A1A1",
+"#	c #767676",
+"$	c #A6A6A6",
+"%	c #797979",
+"&	c #A9A9A9",
+"*	c #A8A8A8",
+"=	c #A7A7A7",
+"-	c #A5A5A5",
+";	c #A4A4A4",
+">	c #A3A3A3",
+",	c #7D7D7D",
+"'	c #AFAFAF",
+")	c #AEAEAE",
+"!	c #ADADAD",
+"~	c #ACACAC",
+"{	c #ABABAB",
+"]	c #AAAAAA",
+"^	c #A0A0A0",
+"/	c #9C9C9C",
+"(	c #999999",
+"_	c #969696",
+":	c #919191",
+"<	c #6E6E6E",
+"[	c #9D9D9D",
+"}	c #929292",
+"|	c #898989",
+"1	c #858585",
+"2	c #878787",
+"3	c #888888",
+"4	c #8A8A8A",
+"5	c #8B8B8B",
+"6	c #5C5C5C",
+"7	c #909090",
+"8	c #8D8D8D",
+"9	c #7E7E7E",
+"0	c #747474",
+"a	c #757575",
+"b	c #8E8E8E",
+"c	c #828282",
+"d	c #7A7A7A",
+"e	c #868686",
+"f	c #8C8C8C",
+"g	c #787878",
+"h	c #7B7B7B",
+"i	c #8F8F8F",
+"j	c #686868",
+"k	c #9E9E9E",
+"l	c #848484",
+"m	c #777777",
+"n	c #7C7C7C",
+"                        ",
+"                        ",
+"                        ",
+"                        ",
+"                  .     ",
+"                  +@#   ",
+"                  +$@%  ",
+"        +&*=$--;>>=$-@, ",
+"        =')!~{{]&;^/(_:<",
+"        =')!~*[}|12345|6",
+"     +  47789000a#3582  ",
+"   #=*            |b1   ",
+"  %$];            5c    ",
+" d;$$+41e23|4f84  g     ",
+"h+>>(2e3|458bi7b        ",
+"jk>}le23|5f8b7:b        ",
+"  fl11#mg%dhnn9h        ",
+"   ,el                  ",
+"    nl                  ",
+"     #                  ",
+"                        ",
+"                        ",
+"                        ",
+"                        "};

sdk/CMakeLists.txt

@@ -0,0 +1,27 @@
+# This file is part of EPOCH.
+# File: CMakeLists.txt
+# Author: Florent Teichteil-Königsbuch
+# Contact: florent.teichteil@onera.fr
+#
+#    EPOCH 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 3 of the License, or
+#    (at your option) any later version.
+#
+#    EPOCH 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 EPOCH.  If not, see <http://www.gnu.org/licenses/>.
+
+MESSAGE (STATUS "COMPILES the Software Development Kit (additional provided dependencies)")
+IF (BUILD_GUI)
+	INCLUDE (${wxWidgets_USE_FILE})
+	ADD_SUBDIRECTORY (wxscintilla)
+	ADD_SUBDIRECTORY (wxshapeframework)
+ENDIF (BUILD_GUI)
+
+ADD_SUBDIRECTORY(buddy-2.4)
+

sdk/boost/numeric/bindings/addressing_index.hpp

@@ -0,0 +1,74 @@
+//
+// Copyright (c) 2009 by Rutger ter Borg
+//
+// Distributed under the Boost Software License, Version 1.0.
+// (See accompanying file LICENSE_1_0.txt or copy at
+// http://www.boost.org/LICENSE_1_0.txt)
+//
+
+#ifndef BOOST_NUMERIC_BINDINGS_INDEX_HPP
+#define BOOST_NUMERIC_BINDINGS_INDEX_HPP
+
+#include <boost/mpl/if.hpp>
+#include <boost/mpl/max.hpp>
+#include <boost/numeric/bindings/rank.hpp>
+#include <boost/numeric/bindings/is_column_major.hpp>
+
+namespace boost {
+namespace numeric {
+namespace bindings {
+
+template< typename T >
+struct addressing_index_minor {
+    typedef typename mpl::if_<
+        is_column_major< T >,
+        tag::addressing_index<1>,
+        tag::addressing_index<
+            mpl::max< tag::matrix, rank< T > >::type::value
+        >
+    >::type type;
+};
+
+template< typename T >
+struct addressing_index_major {
+    typedef typename mpl::if_<
+        is_column_major< T >,
+        tag::addressing_index<
+            mpl::max< tag::matrix, rank< T > >::type::value
+        >,
+        tag::addressing_index<1>
+    >::type type;
+};
+
+
+template< typename AddressingIndex, typename TransTag >
+struct addressing_index_trans {
+    typedef AddressingIndex type;
+};
+
+template<>
+struct addressing_index_trans< tag::addressing_index<1>, tag::transpose > {
+    typedef tag::addressing_index<2> type;
+};
+
+template<>
+struct addressing_index_trans< tag::addressing_index<1>, tag::conjugate > {
+    typedef tag::addressing_index<2> type;
+};
+
+template<>
+struct addressing_index_trans< tag::addressing_index<2>, tag::transpose > {
+    typedef tag::addressing_index<1> type;
+};
+
+template<>
+struct addressing_index_trans< tag::addressing_index<2>, tag::conjugate > {
+    typedef tag::addressing_index<1> type;
+};
+
+
+} // namespace bindings
+} // namespace numeric
+} // namespace boost
+
+#endif

sdk/boost/numeric/bindings/at.hpp

@@ -0,0 +1,71 @@
+//
+// Copyright (c) 2009 Rutger ter Borg
+//
+// Distributed under the Boost Software License, Version 1.0.
+// (See accompanying file LICENSE_1_0.txt or copy at
+// http://www.boost.org/LICENSE_1_0.txt)
+//
+
+#ifndef BOOST_NUMERIC_BINDINGS_AT_HPP
+#define BOOST_NUMERIC_BINDINGS_AT_HPP
+
+#include <boost/numeric/bindings/detail/offset.hpp>
+
+namespace boost {
+namespace numeric {
+namespace bindings {
+namespace detail {
+
+template< typename T, typename Enable = void >
+struct at_impl {
+
+    typedef typename bindings::value_type<T>::type& result_type;
+
+    // TODO implement other array structures such as triangular, band, etc.
+    static result_type invoke( T& t, const std::ptrdiff_t i1, std::ptrdiff_t i2 ) {
+        return t( i1, i2 );
+    }
+
+};
+
+template< typename T >
+struct at_impl< T, typename boost::enable_if< bindings::has_linear_array<T> >::type > {
+
+    typedef typename bindings::value_type<T>::type& result_type;
+
+    static result_type invoke( T& t, const std::ptrdiff_t i1 ) {
+        return *( bindings::begin_value(t) + offset(t,i1) );
+    }
+
+    static result_type invoke( T& t, const std::ptrdiff_t i1, std::ptrdiff_t i2 ) {
+        return *( bindings::begin_value(t) + offset(t,i1,i2) );
+    }
+
+};
+
+}
+
+namespace result_of {
+
+template< typename T >
+struct at {
+    typedef typename detail::at_impl<T>::result_type type;
+};
+
+}
+
+template< typename T >
+typename result_of::at<T>::type at( T& t, const std::ptrdiff_t i1 ) {
+    return detail::at_impl<T>::invoke( t, i1 );
+}
+
+template< typename T >
+typename result_of::at<T>::type at( T& t, const std::ptrdiff_t i1, const std::ptrdiff_t i2 ) {
+    return detail::at_impl<T>::invoke( t, i1, i2 );
+}
+
+} // bindings
+} // numeric
+} // boost
+
+#endif

sdk/boost/numeric/bindings/bandwidth.hpp

@@ -0,0 +1,167 @@
+//
+// Copyright (c) 2009 Rutger ter Borg
+//
+// Distributed under the Boost Software License, Version 1.0.
+// (See accompanying file LICENSE_1_0.txt or copy at
+// http://www.boost.org/LICENSE_1_0.txt)
+//
+
+#ifndef BOOST_NUMERIC_BINDINGS_BANDWIDTH_HPP
+#define BOOST_NUMERIC_BINDINGS_BANDWIDTH_HPP
+
+#include <boost/numeric/bindings/detail/generate_functions.hpp>
+#include <boost/numeric/bindings/detail/get.hpp>
+#include <boost/numeric/bindings/rank.hpp>
+#include <boost/numeric/bindings/addressing_index.hpp>
+#include <boost/mpl/and.hpp>
+#include <boost/mpl/min.hpp>
+#include <boost/mpl/greater.hpp>
+#include <boost/mpl/less_equal.hpp>
+#include <boost/static_assert.hpp>
+
+namespace boost {
+namespace numeric {
+namespace bindings {
+namespace detail {
+
+template< typename T, typename AddressingIndex, typename Enable = void >
+struct bandwidth_impl {
+
+    typedef typename tag::bandwidth_type< AddressingIndex::value > key_type;
+    typedef typename result_of_get< T, key_type >::type result_type;
+
+    static result_type invoke( const T& t ) {
+        return get< key_type >( t );
+    }
+
+};
+
+template< typename T >
+struct bandwidth_impl< T, tag::lower >:
+    bandwidth_impl< T, tag::addressing_index<1> > {};
+
+
+template< typename T >
+struct bandwidth_impl< T, tag::upper >:
+    bandwidth_impl< T, tag::addressing_index<2> > {};
+
+
+template< typename T, int N >
+struct bandwidth_impl< T, tag::addressing_index<N>,
+        typename boost::enable_if< typename mpl::and_<
+            mpl::greater< tag::addressing_index<N>, rank<T> >,
+            is_same_at< T, tag::bandwidth_type<1>, std::ptrdiff_t >
+        >::type >::type > {
+
+    typedef std::ptrdiff_t result_type;
+
+    static result_type invoke( const T& t ) {
+        return std::min< std::ptrdiff_t >( bandwidth_impl<T, tag::addressing_index<1> >::invoke(t), 1 );
+    }
+
+};
+
+template< typename T, int N >
+struct bandwidth_impl< T, tag::addressing_index<N>,
+        typename boost::enable_if< typename mpl::and_<
+            mpl::greater< tag::addressing_index<N>, rank<T> >,
+            mpl::not_< is_same_at< T, tag::bandwidth_type<1>, std::ptrdiff_t > >
+        >::type >::type > {
+
+    typedef typename mpl::min<
+        typename detail::property_at< T, tag::bandwidth_type<1> >::type,
+        mpl::int_<1>
+    >::type result_type;
+
+    static result_type invoke( const T& t ) {
+        return result_type();
+    }
+
+};
+
+} // namespace detail
+
+
+namespace result_of {
+
+template< typename T, typename Tag = tag::addressing_index<1> >
+struct bandwidth {
+    BOOST_STATIC_ASSERT( (is_tag<Tag>::value) );
+    typedef typename detail::bandwidth_impl< T, Tag >::result_type type;
+};
+
+} // namespace result_of
+
+//
+// Overloads for free template functions bandwidth( x, tag ), 
+//
+template< typename T, typename Tag >
+inline typename result_of::bandwidth< const T, Tag >::type
+bandwidth( const T& t, Tag ) {
+    return detail::bandwidth_impl< const T, Tag >::invoke( t );
+}
+
+// Overloads for free template function bandwidth( x )
+// Valid for types with rank <= 1 (scalars, vectors)
+// In theory, we could provide overloads for matrices here, too, 
+// if their minimal_rank is at most 1.
+
+// template< typename T >
+// typename boost::enable_if< mpl::less< rank<T>, mpl::int_<2> >,
+//     typename result_of::bandwidth< const T >::type >::type
+// bandwidth( const T& t ) {
+//     return detail::bandwidth_impl< const T, tag::addressing_index<1> >::invoke( t );
+// }
+
+#define GENERATE_BANDWIDTH_INDEX( z, which, unused ) \
+GENERATE_FUNCTIONS( bandwidth, which, tag::addressing_index<which> )
+
+BOOST_PP_REPEAT_FROM_TO(1,3,GENERATE_BANDWIDTH_INDEX,~)
+
+GENERATE_FUNCTIONS( bandwidth, _left, tag::addressing_index<1> )
+GENERATE_FUNCTIONS( bandwidth, _right, tag::addressing_index<2> )
+GENERATE_FUNCTIONS( bandwidth, _lower, tag::addressing_index<1> )
+GENERATE_FUNCTIONS( bandwidth, _upper, tag::addressing_index<2> )
+GENERATE_FUNCTIONS( bandwidth, _major, typename addressing_index_major<T>::type )
+GENERATE_FUNCTIONS( bandwidth, _minor, typename addressing_index_minor<T>::type )
+
+//
+// Overloads for free template functions bandwidth_row( x, tag ), 
+// Here, tag is assumed to be either one of
+// tag::transpose, tag::no_transpose, or tag::conjugate
+//
+namespace result_of {
+
+template< typename T, typename TransTag >
+struct bandwidth_lower_op {
+    typedef typename bandwidth<
+        T,
+        typename addressing_index_trans< tag::addressing_index<1>, TransTag >::type
+    >::type type;
+};
+
+template< typename T, typename TransTag >
+struct bandwidth_upper_op {
+    typedef typename bandwidth< T, 
+        typename addressing_index_trans< tag::addressing_index<2>, TransTag >::type >::type type;
+};
+
+} // namespace result_of
+
+template< typename T, typename Tag >
+inline typename result_of::bandwidth_lower_op< const T, Tag >::type
+bandwidth_lower_op( const T& t, Tag ) {
+    return bindings::bandwidth( t, typename addressing_index_trans< tag::addressing_index<1>, Tag >::type() );
+}
+
+template< typename T, typename Tag >
+inline typename result_of::bandwidth_upper_op< const T, Tag >::type
+bandwidth_upper_op( const T& t, Tag ) {
+    return bindings::bandwidth( t, typename addressing_index_trans< tag::addressing_index<2>, Tag >::type() );
+}
+
+} // namespace bindings
+} // namespace numeric
+} // namespace boost
+
+#endif

sdk/boost/numeric/bindings/begin.hpp

@@ -0,0 +1,145 @@
+//
+// Copyright (c) 2009 Rutger ter Borg
+//
+// Distributed under the Boost Software License, Version 1.0.
+// (See accompanying file LICENSE_1_0.txt or copy at
+// http://www.boost.org/LICENSE_1_0.txt)
+//
+
+#ifndef BOOST_NUMERIC_BINDINGS_BEGIN_HPP
+#define BOOST_NUMERIC_BINDINGS_BEGIN_HPP
+
+#include <boost/numeric/bindings/detail/adaptor.hpp>
+#include <boost/numeric/bindings/detail/linear_iterator.hpp>
+#include <boost/numeric/bindings/detail/generate_functions.hpp>
+#include <boost/numeric/bindings/rank.hpp>
+#include <boost/numeric/bindings/stride.hpp>
+#include <boost/numeric/bindings/value_type.hpp>
+#include <iostream>
+
+namespace boost {
+namespace numeric {
+namespace bindings {
+
+namespace detail {
+
+template< typename T, typename Tag >
+struct begin_impl {};
+
+template< typename T >
+struct begin_impl< T, tag::value > {
+    typedef typename bindings::value_type< T>::type* result_type;
+
+    static result_type invoke( T& t ) {
+        return adaptor_access<T>::begin_value( t );
+    }
+};
+
+template< typename T, int Dimension >
+struct begin_impl<T, tag::addressing_index<Dimension> > {
+
+    typedef tag::addressing_index<Dimension> tag_type;
+
+    typedef linear_iterator<
+        typename bindings::value_type< T>::type,
+        typename result_of::stride< T, tag_type >::type
+    > result_type;
+
+    static result_type invoke( T& t ) {
+        return result_type( adaptor_access<T>::begin_value( t ), bindings::stride(t, tag_type() ) );
+    }
+};
+
+template< typename T >
+struct begin_impl< T, tag::index_major > {
+    typedef typename detail::property_at< T, tag::index_type >::type* result_type;
+
+    static result_type invoke( T& t ) {
+        return adaptor_access<T>::begin_index_major( t );
+    }
+};
+
+template< typename T >
+struct begin_impl< T, tag::compressed_index_major > {
+    typedef typename detail::property_at< T, tag::index_type >::type* result_type;
+
+    static result_type invoke( T& t ) {
+        return adaptor_access<T>::begin_compressed_index_major( t );
+    }
+};
+
+template< typename T >
+struct begin_impl< T, tag::index_minor > {
+    typedef typename detail::property_at< T, tag::index_type >::type* result_type;
+
+    static result_type invoke( T& t ) {
+        return adaptor_access<T>::begin_index_minor( t );
+    }
+};
+
+} // namespace detail
+
+namespace result_of {
+
+template< typename T, typename Tag = tag::addressing_index<1> >
+struct begin {
+    BOOST_STATIC_ASSERT( (is_tag<Tag>::value) );
+    typedef typename detail::begin_impl<T,Tag>::result_type type;
+};
+
+} // namespace result_of
+
+//
+// Free Functions
+//
+
+//
+// Overloads like begin( t, tag )
+//
+template< typename T, typename Tag >
+inline typename result_of::begin<T,Tag>::type
+begin( T& t, Tag ) {
+    return detail::begin_impl<T,Tag>::invoke( t );
+}
+
+template< typename T, typename Tag >
+inline typename result_of::begin<const T,Tag>::type
+begin( const T& t, Tag ) {
+    return detail::begin_impl<const T,Tag>::invoke( t );
+}
+
+// Overloads for types with rank <= 1 (scalars, vectors)
+// In theory, we could provide overloads for matrices here, too, 
+// if their minimal_rank is at most 1.
+
+template< typename T >
+typename boost::enable_if< mpl::less< rank<T>, mpl::int_<2> >,
+    typename result_of::begin< T >::type >::type
+begin( T& t ) {
+    return detail::begin_impl< T, tag::addressing_index<1> >::invoke( t );
+}
+
+template< typename T >
+typename boost::enable_if< mpl::less< rank<T>, mpl::int_<2> >,
+    typename result_of::begin< const T >::type >::type
+begin( const T& t ) {
+    return detail::begin_impl< const T, tag::addressing_index<1> >::invoke( t );
+}
+
+#define GENERATE_BEGIN_INDEX( z, which, unused ) \
+GENERATE_FUNCTIONS( begin, which, tag::addressing_index<which> )
+
+BOOST_PP_REPEAT_FROM_TO(1,3,GENERATE_BEGIN_INDEX,~)
+GENERATE_FUNCTIONS( begin, _value, tag::value )
+GENERATE_FUNCTIONS( begin, _row, tag::addressing_index<1> )
+GENERATE_FUNCTIONS( begin, _column, tag::addressing_index<2> )
+
+GENERATE_FUNCTIONS( begin, _index_major, tag::index_major )
+GENERATE_FUNCTIONS( begin, _compressed_index_major, tag::compressed_index_major )
+GENERATE_FUNCTIONS( begin, _index_minor, tag::index_minor )
+
+} // namespace bindings
+} // namespace numeric
+} // namespace boost
+
+#endif

sdk/boost/numeric/bindings/blas.hpp

@@ -0,0 +1,17 @@
+//
+// Copyright (c) 2009 Rutger ter Borg
+//
+// Distributed under the Boost Software License, Version 1.0.
+// (See accompanying file LICENSE_1_0.txt or copy at
+// http://www.boost.org/LICENSE_1_0.txt)
+//
+
+#ifndef BOOST_NUMERIC_BINDINGS_BLAS_HPP
+#define BOOST_NUMERIC_BINDINGS_BLAS_HPP
+
+#include <boost/numeric/bindings/blas/level1.hpp>
+#include <boost/numeric/bindings/blas/level2.hpp>
+#include <boost/numeric/bindings/blas/level3.hpp>
+
+#endif
+

sdk/boost/numeric/bindings/blas/detail/blas.h

@@ -0,0 +1,574 @@
+//
+// Copyright (c) 2003--2009
+// Toon Knapen, Karl Meerbergen, Kresimir Fresl,
+// Thomas Klimpel and Rutger ter Borg
+//
+// Distributed under the Boost Software License, Version 1.0.
+// (See accompanying file LICENSE_1_0.txt or copy at
+// http://www.boost.org/LICENSE_1_0.txt)
+//
+// THIS FILE IS AUTOMATICALLY GENERATED
+// PLEASE DO NOT EDIT!
+//
+
+#ifndef BOOST_NUMERIC_BINDINGS_BLAS_DETAIL_BLAS_H
+#define BOOST_NUMERIC_BINDINGS_BLAS_DETAIL_BLAS_H
+
+#include <boost/numeric/bindings/blas/detail/blas_names.h>
+
+extern "C" {
+
+//
+// BLAS level1 routines
+//
+
+// Value-type variants of asum
+float BLAS_SASUM( const fortran_int_t* n, const float* x,
+        const fortran_int_t* incx );
+double BLAS_DASUM( const fortran_int_t* n, const double* x,
+        const fortran_int_t* incx );
+float BLAS_SCASUM( const fortran_int_t* n, const void* x,
+        const fortran_int_t* incx );
+double BLAS_DZASUM( const fortran_int_t* n, const void* x,
+        const fortran_int_t* incx );
+
+// Value-type variants of axpy
+void BLAS_SAXPY( const fortran_int_t* n, const float* a, const float* x,
+        const fortran_int_t* incx, float* y, const fortran_int_t* incy );
+void BLAS_DAXPY( const fortran_int_t* n, const double* a, const double* x,
+        const fortran_int_t* incx, double* y, const fortran_int_t* incy );
+void BLAS_CAXPY( const fortran_int_t* n, const void* a, const void* x,
+        const fortran_int_t* incx, void* y, const fortran_int_t* incy );
+void BLAS_ZAXPY( const fortran_int_t* n, const void* a, const void* x,
+        const fortran_int_t* incx, void* y, const fortran_int_t* incy );
+
+// Value-type variants of copy
+void BLAS_SCOPY( const fortran_int_t* n, const float* x,
+        const fortran_int_t* incx, float* y, const fortran_int_t* incy );
+void BLAS_DCOPY( const fortran_int_t* n, const double* x,
+        const fortran_int_t* incx, double* y, const fortran_int_t* incy );
+void BLAS_CCOPY( const fortran_int_t* n, const void* x,
+        const fortran_int_t* incx, void* y, const fortran_int_t* incy );
+void BLAS_ZCOPY( const fortran_int_t* n, const void* x,
+        const fortran_int_t* incx, void* y, const fortran_int_t* incy );
+
+// Value-type variants of dot
+float BLAS_SDOT( const fortran_int_t* n, const float* x,
+        const fortran_int_t* incx, const float* y, const fortran_int_t* incy );
+double BLAS_DDOT( const fortran_int_t* n, const double* x,
+        const fortran_int_t* incx, const double* y,
+        const fortran_int_t* incy );
+std::complex<float> BLAS_CDOTU( const fortran_int_t* n, const void* x,
+        const fortran_int_t* incx, const void* y, const fortran_int_t* incy );
+std::complex<double> BLAS_ZDOTU( const fortran_int_t* n, const void* x,
+        const fortran_int_t* incx, const void* y, const fortran_int_t* incy );
+
+// Value-type variants of dotc
+std::complex<float> BLAS_CDOTC( const fortran_int_t* n, const void* x,
+        const fortran_int_t* incx, const void* y, const fortran_int_t* incy );
+std::complex<double> BLAS_ZDOTC( const fortran_int_t* n, const void* x,
+        const fortran_int_t* incx, const void* y, const fortran_int_t* incy );
+
+// Value-type variants of iamax
+fortran_int_t BLAS_ISAMAX( const fortran_int_t* n, const float* x,
+        const fortran_int_t* incx );
+fortran_int_t BLAS_IDAMAX( const fortran_int_t* n, const double* x,
+        const fortran_int_t* incx );
+fortran_int_t BLAS_ICAMAX( const fortran_int_t* n, const void* x,
+        const fortran_int_t* incx );
+fortran_int_t BLAS_IZAMAX( const fortran_int_t* n, const void* x,
+        const fortran_int_t* incx );
+
+// Value-type variants of nrm2
+float BLAS_SNRM2( const fortran_int_t* n, const float* x,
+        const fortran_int_t* incx );
+double BLAS_DNRM2( const fortran_int_t* n, const double* x,
+        const fortran_int_t* incx );
+float BLAS_SCNRM2( const fortran_int_t* n, const void* x,
+        const fortran_int_t* incx );
+double BLAS_DZNRM2( const fortran_int_t* n, const void* x,
+        const fortran_int_t* incx );
+
+// Value-type variants of prec_dot
+double BLAS_DSDOT( const fortran_int_t* n, const float* x,
+        const fortran_int_t* incx, const float* y, const fortran_int_t* incy );
+
+// Value-type variants of rot
+void BLAS_SROT( const fortran_int_t* n, float* x, const fortran_int_t* incx,
+        float* y, const fortran_int_t* incy, const float* c, const float* s );
+void BLAS_DROT( const fortran_int_t* n, double* x, const fortran_int_t* incx,
+        double* y, const fortran_int_t* incy, const double* c,
+        const double* s );
+void BLAS_CSROT( const fortran_int_t* n, void* x, const fortran_int_t* incx,
+        void* y, const fortran_int_t* incy, const float* c, const float* s );
+void BLAS_ZDROT( const fortran_int_t* n, void* x, const fortran_int_t* incx,
+        void* y, const fortran_int_t* incy, const double* c, const double* s );
+
+// Value-type variants of rotg
+void BLAS_SROTG( float* a, float* b, float* c, float* s );
+void BLAS_DROTG( double* a, double* b, double* c, double* s );
+void BLAS_CROTG( void* a, void* b, float* c, void* s );
+void BLAS_ZROTG( void* a, void* b, double* c, void* s );
+
+// Value-type variants of rotm
+void BLAS_SROTM( const fortran_int_t* n, float* x, const fortran_int_t* incx,
+        float* y, const fortran_int_t* incy, float* param );
+void BLAS_DROTM( const fortran_int_t* n, double* x, const fortran_int_t* incx,
+        double* y, const fortran_int_t* incy, double* param );
+
+// Value-type variants of rotmg
+void BLAS_SROTMG( float* d1, float* d2, float* x1, const float* y1,
+        float* sparam );
+void BLAS_DROTMG( double* d1, double* d2, double* x1, const double* y1,
+        double* dparam );
+
+// Value-type variants of scal
+void BLAS_SSCAL( const fortran_int_t* n, const float* a, float* x,
+        const fortran_int_t* incx );
+void BLAS_DSCAL( const fortran_int_t* n, const double* a, double* x,
+        const fortran_int_t* incx );
+void BLAS_CSSCAL( const fortran_int_t* n, const float* a, void* x,
+        const fortran_int_t* incx );
+void BLAS_ZDSCAL( const fortran_int_t* n, const double* a, void* x,
+        const fortran_int_t* incx );
+void BLAS_CSCAL( const fortran_int_t* n, const void* a, void* x,
+        const fortran_int_t* incx );
+void BLAS_ZSCAL( const fortran_int_t* n, const void* a, void* x,
+        const fortran_int_t* incx );
+
+// Value-type variants of swap
+void BLAS_SSWAP( const fortran_int_t* n, float* x, const fortran_int_t* incx,
+        float* y, const fortran_int_t* incy );
+void BLAS_DSWAP( const fortran_int_t* n, double* x, const fortran_int_t* incx,
+        double* y, const fortran_int_t* incy );
+void BLAS_CSWAP( const fortran_int_t* n, void* x, const fortran_int_t* incx,
+        void* y, const fortran_int_t* incy );
+void BLAS_ZSWAP( const fortran_int_t* n, void* x, const fortran_int_t* incx,
+        void* y, const fortran_int_t* incy );
+
+//
+// BLAS level2 routines
+//
+
+// Value-type variants of gbmv
+void BLAS_SGBMV( const char* trans, const fortran_int_t* m,
+        const fortran_int_t* n, const fortran_int_t* kl,
+        const fortran_int_t* ku, const float* alpha, const float* a,
+        const fortran_int_t* lda, const float* x, const fortran_int_t* incx,
+        const float* beta, float* y, const fortran_int_t* incy );
+void BLAS_DGBMV( const char* trans, const fortran_int_t* m,
+        const fortran_int_t* n, const fortran_int_t* kl,
+        const fortran_int_t* ku, const double* alpha, const double* a,
+        const fortran_int_t* lda, const double* x, const fortran_int_t* incx,
+        const double* beta, double* y, const fortran_int_t* incy );
+void BLAS_CGBMV( const char* trans, const fortran_int_t* m,
+        const fortran_int_t* n, const fortran_int_t* kl,
+        const fortran_int_t* ku, const void* alpha, const void* a,
+        const fortran_int_t* lda, const void* x, const fortran_int_t* incx,
+        const void* beta, void* y, const fortran_int_t* incy );
+void BLAS_ZGBMV( const char* trans, const fortran_int_t* m,
+        const fortran_int_t* n, const fortran_int_t* kl,
+        const fortran_int_t* ku, const void* alpha, const void* a,
+        const fortran_int_t* lda, const void* x, const fortran_int_t* incx,
+        const void* beta, void* y, const fortran_int_t* incy );
+
+// Value-type variants of gemv
+void BLAS_SGEMV( const char* trans, const fortran_int_t* m,
+        const fortran_int_t* n, const float* alpha, const float* a,
+        const fortran_int_t* lda, const float* x, const fortran_int_t* incx,
+        const float* beta, float* y, const fortran_int_t* incy );
+void BLAS_DGEMV( const char* trans, const fortran_int_t* m,
+        const fortran_int_t* n, const double* alpha, const double* a,
+        const fortran_int_t* lda, const double* x, const fortran_int_t* incx,
+        const double* beta, double* y, const fortran_int_t* incy );
+void BLAS_CGEMV( const char* trans, const fortran_int_t* m,
+        const fortran_int_t* n, const void* alpha, const void* a,
+        const fortran_int_t* lda, const void* x, const fortran_int_t* incx,
+        const void* beta, void* y, const fortran_int_t* incy );
+void BLAS_ZGEMV( const char* trans, const fortran_int_t* m,
+        const fortran_int_t* n, const void* alpha, const void* a,
+        const fortran_int_t* lda, const void* x, const fortran_int_t* incx,
+        const void* beta, void* y, const fortran_int_t* incy );
+
+// Value-type variants of ger
+void BLAS_SGER( const fortran_int_t* m, const fortran_int_t* n,
+        const float* alpha, const float* x, const fortran_int_t* incx,
+        const float* y, const fortran_int_t* incy, float* a,
+        const fortran_int_t* lda );
+void BLAS_DGER( const fortran_int_t* m, const fortran_int_t* n,
+        const double* alpha, const double* x, const fortran_int_t* incx,
+        const double* y, const fortran_int_t* incy, double* a,
+        const fortran_int_t* lda );
+
+// Value-type variants of gerc
+void BLAS_CGERC( const fortran_int_t* m, const fortran_int_t* n,
+        const void* alpha, const void* x, const fortran_int_t* incx,
+        const void* y, const fortran_int_t* incy, void* a,
+        const fortran_int_t* lda );
+void BLAS_ZGERC( const fortran_int_t* m, const fortran_int_t* n,
+        const void* alpha, const void* x, const fortran_int_t* incx,
+        const void* y, const fortran_int_t* incy, void* a,
+        const fortran_int_t* lda );
+
+// Value-type variants of geru
+void BLAS_CGERU( const fortran_int_t* m, const fortran_int_t* n,
+        const void* alpha, const void* x, const fortran_int_t* incx,
+        const void* y, const fortran_int_t* incy, void* a,
+        const fortran_int_t* lda );
+void BLAS_ZGERU( const fortran_int_t* m, const fortran_int_t* n,
+        const void* alpha, const void* x, const fortran_int_t* incx,
+        const void* y, const fortran_int_t* incy, void* a,
+        const fortran_int_t* lda );
+
+// Value-type variants of hbmv
+void BLAS_CHBMV( const char* uplo, const fortran_int_t* n,
+        const fortran_int_t* k, const void* alpha, const void* a,
+        const fortran_int_t* lda, const void* x, const fortran_int_t* incx,
+        const void* beta, void* y, const fortran_int_t* incy );
+void BLAS_ZHBMV( const char* uplo, const fortran_int_t* n,
+        const fortran_int_t* k, const void* alpha, const void* a,
+        const fortran_int_t* lda, const void* x, const fortran_int_t* incx,
+        const void* beta, void* y, const fortran_int_t* incy );
+
+// Value-type variants of hemv
+void BLAS_CHEMV( const char* uplo, const fortran_int_t* n, const void* alpha,
+        const void* a, const fortran_int_t* lda, const void* x,
+        const fortran_int_t* incx, const void* beta, void* y,
+        const fortran_int_t* incy );
+void BLAS_ZHEMV( const char* uplo, const fortran_int_t* n, const void* alpha,
+        const void* a, const fortran_int_t* lda, const void* x,
+        const fortran_int_t* incx, const void* beta, void* y,
+        const fortran_int_t* incy );
+
+// Value-type variants of her
+void BLAS_CHER( const char* uplo, const fortran_int_t* n, const float* alpha,
+        const void* x, const fortran_int_t* incx, void* a,
+        const fortran_int_t* lda );
+void BLAS_ZHER( const char* uplo, const fortran_int_t* n, const double* alpha,
+        const void* x, const fortran_int_t* incx, void* a,
+        const fortran_int_t* lda );
+
+// Value-type variants of her2
+void BLAS_CHER2( const char* uplo, const fortran_int_t* n, const void* alpha,
+        const void* x, const fortran_int_t* incx, const void* y,
+        const fortran_int_t* incy, void* a, const fortran_int_t* lda );
+void BLAS_ZHER2( const char* uplo, const fortran_int_t* n, const void* alpha,
+        const void* x, const fortran_int_t* incx, const void* y,
+        const fortran_int_t* incy, void* a, const fortran_int_t* lda );
+
+// Value-type variants of hpmv
+void BLAS_CHPMV( const char* uplo, const fortran_int_t* n, const void* alpha,
+        const void* ap, const void* x, const fortran_int_t* incx,
+        const void* beta, void* y, const fortran_int_t* incy );
+void BLAS_ZHPMV( const char* uplo, const fortran_int_t* n, const void* alpha,
+        const void* ap, const void* x, const fortran_int_t* incx,
+        const void* beta, void* y, const fortran_int_t* incy );
+
+// Value-type variants of hpr
+void BLAS_CHPR( const char* uplo, const fortran_int_t* n, const float* alpha,
+        const void* x, const fortran_int_t* incx, void* ap );
+void BLAS_ZHPR( const char* uplo, const fortran_int_t* n, const double* alpha,
+        const void* x, const fortran_int_t* incx, void* ap );
+
+// Value-type variants of hpr2
+void BLAS_CHPR2( const char* uplo, const fortran_int_t* n, const void* alpha,
+        const void* x, const fortran_int_t* incx, const void* y,
+        const fortran_int_t* incy, void* ap );
+void BLAS_ZHPR2( const char* uplo, const fortran_int_t* n, const void* alpha,
+        const void* x, const fortran_int_t* incx, const void* y,
+        const fortran_int_t* incy, void* ap );
+
+// Value-type variants of sbmv
+void BLAS_SSBMV( const char* uplo, const fortran_int_t* n,
+        const fortran_int_t* k, const float* alpha, const float* a,
+        const fortran_int_t* lda, const float* x, const fortran_int_t* incx,
+        const float* beta, float* y, const fortran_int_t* incy );
+void BLAS_DSBMV( const char* uplo, const fortran_int_t* n,
+        const fortran_int_t* k, const double* alpha, const double* a,
+        const fortran_int_t* lda, const double* x, const fortran_int_t* incx,
+        const double* beta, double* y, const fortran_int_t* incy );
+
+// Value-type variants of spmv
+void BLAS_SSPMV( const char* uplo, const fortran_int_t* n, const float* alpha,
+        const float* ap, const float* x, const fortran_int_t* incx,
+        const float* beta, float* y, const fortran_int_t* incy );
+void BLAS_DSPMV( const char* uplo, const fortran_int_t* n,
+        const double* alpha, const double* ap, const double* x,
+        const fortran_int_t* incx, const double* beta, double* y,
+        const fortran_int_t* incy );
+
+// Value-type variants of spr
+void BLAS_SSPR( const char* uplo, const fortran_int_t* n, const float* alpha,
+        const float* x, const fortran_int_t* incx, float* ap );
+void BLAS_DSPR( const char* uplo, const fortran_int_t* n, const double* alpha,
+        const double* x, const fortran_int_t* incx, double* ap );
+
+// Value-type variants of spr2
+void BLAS_SSPR2( const char* uplo, const fortran_int_t* n, const float* alpha,
+        const float* x, const fortran_int_t* incx, const float* y,
+        const fortran_int_t* incy, float* ap );
+void BLAS_DSPR2( const char* uplo, const fortran_int_t* n,
+        const double* alpha, const double* x, const fortran_int_t* incx,
+        const double* y, const fortran_int_t* incy, double* ap );
+
+// Value-type variants of symv
+void BLAS_SSYMV( const char* uplo, const fortran_int_t* n, const float* alpha,
+        const float* a, const fortran_int_t* lda, const float* x,
+        const fortran_int_t* incx, const float* beta, float* y,
+        const fortran_int_t* incy );
+void BLAS_DSYMV( const char* uplo, const fortran_int_t* n,
+        const double* alpha, const double* a, const fortran_int_t* lda,
+        const double* x, const fortran_int_t* incx, const double* beta,
+        double* y, const fortran_int_t* incy );
+
+// Value-type variants of syr
+void BLAS_SSYR( const char* uplo, const fortran_int_t* n, const float* alpha,
+        const float* x, const fortran_int_t* incx, float* a,
+        const fortran_int_t* lda );
+void BLAS_DSYR( const char* uplo, const fortran_int_t* n, const double* alpha,
+        const double* x, const fortran_int_t* incx, double* a,
+        const fortran_int_t* lda );
+
+// Value-type variants of syr2
+void BLAS_SSYR2( const char* uplo, const fortran_int_t* n, const float* alpha,
+        const float* x, const fortran_int_t* incx, const float* y,
+        const fortran_int_t* incy, float* a, const fortran_int_t* lda );
+void BLAS_DSYR2( const char* uplo, const fortran_int_t* n,
+        const double* alpha, const double* x, const fortran_int_t* incx,
+        const double* y, const fortran_int_t* incy, double* a,
+        const fortran_int_t* lda );
+
+// Value-type variants of tbmv
+void BLAS_STBMV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const fortran_int_t* k, const float* a,
+        const fortran_int_t* lda, float* x, const fortran_int_t* incx );
+void BLAS_DTBMV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const fortran_int_t* k, const double* a,
+        const fortran_int_t* lda, double* x, const fortran_int_t* incx );
+void BLAS_CTBMV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const fortran_int_t* k, const void* a,
+        const fortran_int_t* lda, void* x, const fortran_int_t* incx );
+void BLAS_ZTBMV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const fortran_int_t* k, const void* a,
+        const fortran_int_t* lda, void* x, const fortran_int_t* incx );
+
+// Value-type variants of tbsv
+void BLAS_STBSV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const fortran_int_t* k, const float* a,
+        const fortran_int_t* lda, float* x, const fortran_int_t* incx );
+void BLAS_DTBSV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const fortran_int_t* k, const double* a,
+        const fortran_int_t* lda, double* x, const fortran_int_t* incx );
+void BLAS_CTBSV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const fortran_int_t* k, const void* a,
+        const fortran_int_t* lda, void* x, const fortran_int_t* incx );
+void BLAS_ZTBSV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const fortran_int_t* k, const void* a,
+        const fortran_int_t* lda, void* x, const fortran_int_t* incx );
+
+// Value-type variants of tpmv
+void BLAS_STPMV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const float* ap, float* x,
+        const fortran_int_t* incx );
+void BLAS_DTPMV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const double* ap, double* x,
+        const fortran_int_t* incx );
+void BLAS_CTPMV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const void* ap, void* x,
+        const fortran_int_t* incx );
+void BLAS_ZTPMV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const void* ap, void* x,
+        const fortran_int_t* incx );
+
+// Value-type variants of tpsv
+void BLAS_STPSV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const float* ap, float* x,
+        const fortran_int_t* incx );
+void BLAS_DTPSV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const double* ap, double* x,
+        const fortran_int_t* incx );
+void BLAS_CTPSV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const void* ap, void* x,
+        const fortran_int_t* incx );
+void BLAS_ZTPSV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const void* ap, void* x,
+        const fortran_int_t* incx );
+
+// Value-type variants of trmv
+void BLAS_STRMV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const float* a, const fortran_int_t* lda,
+        float* x, const fortran_int_t* incx );
+void BLAS_DTRMV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const double* a, const fortran_int_t* lda,
+        double* x, const fortran_int_t* incx );
+void BLAS_CTRMV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const void* a, const fortran_int_t* lda,
+        void* x, const fortran_int_t* incx );
+void BLAS_ZTRMV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const void* a, const fortran_int_t* lda,
+        void* x, const fortran_int_t* incx );
+
+// Value-type variants of trsv
+void BLAS_STRSV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const float* a, const fortran_int_t* lda,
+        float* x, const fortran_int_t* incx );
+void BLAS_DTRSV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const double* a, const fortran_int_t* lda,
+        double* x, const fortran_int_t* incx );
+void BLAS_CTRSV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const void* a, const fortran_int_t* lda,
+        void* x, const fortran_int_t* incx );
+void BLAS_ZTRSV( const char* uplo, const char* trans, const char* diag,
+        const fortran_int_t* n, const void* a, const fortran_int_t* lda,
+        void* x, const fortran_int_t* incx );
+
+//
+// BLAS level3 routines
+//
+
+// Value-type variants of gemm
+void BLAS_SGEMM( const char* transa, const char* transb,
+        const fortran_int_t* m, const fortran_int_t* n,
+        const fortran_int_t* k, const float* alpha, const float* a,
+        const fortran_int_t* lda, const float* b, const fortran_int_t* ldb,
+        const float* beta, float* c, const fortran_int_t* ldc );
+void BLAS_DGEMM( const char* transa, const char* transb,
+        const fortran_int_t* m, const fortran_int_t* n,
+        const fortran_int_t* k, const double* alpha, const double* a,
+        const fortran_int_t* lda, const double* b, const fortran_int_t* ldb,
+        const double* beta, double* c, const fortran_int_t* ldc );
+void BLAS_CGEMM( const char* transa, const char* transb,
+        const fortran_int_t* m, const fortran_int_t* n,
+        const fortran_int_t* k, const void* alpha, const void* a,
+        const fortran_int_t* lda, const void* b, const fortran_int_t* ldb,
+        const void* beta, void* c, const fortran_int_t* ldc );
+void BLAS_ZGEMM( const char* transa, const char* transb,
+        const fortran_int_t* m, const fortran_int_t* n,
+        const fortran_int_t* k, const void* alpha, const void* a,
+        const fortran_int_t* lda, const void* b, const fortran_int_t* ldb,
+        const void* beta, void* c, const fortran_int_t* ldc );
+
+// Value-type variants of hemm
+void BLAS_CHEMM( const char* side, const char* uplo, const fortran_int_t* m,
+        const fortran_int_t* n, const void* alpha, const void* a,
+        const fortran_int_t* lda, const void* b, const fortran_int_t* ldb,
+        const void* beta, void* c, const fortran_int_t* ldc );
+void BLAS_ZHEMM( const char* side, const char* uplo, const fortran_int_t* m,
+        const fortran_int_t* n, const void* alpha, const void* a,
+        const fortran_int_t* lda, const void* b, const fortran_int_t* ldb,
+        const void* beta, void* c, const fortran_int_t* ldc );
+
+// Value-type variants of her2k
+void BLAS_CHER2K( const char* uplo, const char* trans, const fortran_int_t* n,
+        const fortran_int_t* k, const void* alpha, const void* a,
+        const fortran_int_t* lda, const void* b, const fortran_int_t* ldb,
+        const float* beta, void* c, const fortran_int_t* ldc );
+void BLAS_ZHER2K( const char* uplo, const char* trans, const fortran_int_t* n,
+        const fortran_int_t* k, const void* alpha, const void* a,
+        const fortran_int_t* lda, const void* b, const fortran_int_t* ldb,
+        const double* beta, void* c, const fortran_int_t* ldc );
+
+// Value-type variants of herk
+void BLAS_CHERK( const char* uplo, const char* trans, const fortran_int_t* n,
+        const fortran_int_t* k, const float* alpha, const void* a,
+        const fortran_int_t* lda, const float* beta, void* c,
+        const fortran_int_t* ldc );
+void BLAS_ZHERK( const char* uplo, const char* trans, const fortran_int_t* n,
+        const fortran_int_t* k, const double* alpha, const void* a,
+        const fortran_int_t* lda, const double* beta, void* c,
+        const fortran_int_t* ldc );
+
+// Value-type variants of symm
+void BLAS_SSYMM( const char* side, const char* uplo, const fortran_int_t* m,
+        const fortran_int_t* n, const float* alpha, const float* a,
+        const fortran_int_t* lda, const float* b, const fortran_int_t* ldb,
+        const float* beta, float* c, const fortran_int_t* ldc );
+void BLAS_DSYMM( const char* side, const char* uplo, const fortran_int_t* m,
+        const fortran_int_t* n, const double* alpha, const double* a,
+        const fortran_int_t* lda, const double* b, const fortran_int_t* ldb,
+        const double* beta, double* c, const fortran_int_t* ldc );
+void BLAS_CSYMM( const char* side, const char* uplo, const fortran_int_t* m,
+        const fortran_int_t* n, const void* alpha, const void* a,
+        const fortran_int_t* lda, const void* b, const fortran_int_t* ldb,
+        const void* beta, void* c, const fortran_int_t* ldc );
+void BLAS_ZSYMM( const char* side, const char* uplo, const fortran_int_t* m,
+        const fortran_int_t* n, const void* alpha, const void* a,
+        const fortran_int_t* lda, const void* b, const fortran_int_t* ldb,
+        const void* beta, void* c, const fortran_int_t* ldc );
+
+// Value-type variants of syr2k
+void BLAS_SSYR2K( const char* uplo, const char* trans, const fortran_int_t* n,
+        const fortran_int_t* k, const float* alpha, const float* a,
+        const fortran_int_t* lda, const float* b, const fortran_int_t* ldb,
+        const float* beta, float* c, const fortran_int_t* ldc );
+void BLAS_DSYR2K( const char* uplo, const char* trans, const fortran_int_t* n,
+        const fortran_int_t* k, const double* alpha, const double* a,
+        const fortran_int_t* lda, const double* b, const fortran_int_t* ldb,
+        const double* beta, double* c, const fortran_int_t* ldc );
+void BLAS_CSYR2K( const char* uplo, const char* trans, const fortran_int_t* n,
+        const fortran_int_t* k, const void* alpha, const void* a,
+        const fortran_int_t* lda, const void* b, const fortran_int_t* ldb,
+        const void* beta, void* c, const fortran_int_t* ldc );
+void BLAS_ZSYR2K( const char* uplo, const char* trans, const fortran_int_t* n,
+        const fortran_int_t* k, const void* alpha, const void* a,
+        const fortran_int_t* lda, const void* b, const fortran_int_t* ldb,
+        const void* beta, void* c, const fortran_int_t* ldc );
+
+// Value-type variants of syrk
+void BLAS_SSYRK( const char* uplo, const char* trans, const fortran_int_t* n,
+        const fortran_int_t* k, const float* alpha, const float* a,
+        const fortran_int_t* lda, const float* beta, float* c,
+        const fortran_int_t* ldc );
+void BLAS_DSYRK( const char* uplo, const char* trans, const fortran_int_t* n,
+        const fortran_int_t* k, const double* alpha, const double* a,
+        const fortran_int_t* lda, const double* beta, double* c,
+        const fortran_int_t* ldc );
+void BLAS_CSYRK( const char* uplo, const char* trans, const fortran_int_t* n,
+        const fortran_int_t* k, const void* alpha, const void* a,
+        const fortran_int_t* lda, const void* beta, void* c,
+        const fortran_int_t* ldc );
+void BLAS_ZSYRK( const char* uplo, const char* trans, const fortran_int_t* n,
+        const fortran_int_t* k, const void* alpha, const void* a,
+        const fortran_int_t* lda, const void* beta, void* c,
+        const fortran_int_t* ldc );
+
+// Value-type variants of trmm
+void BLAS_STRMM( const char* side, const char* uplo, const char* transa,
+        const char* diag, const fortran_int_t* m, const fortran_int_t* n,
+        const float* alpha, const float* a, const fortran_int_t* lda,
+        float* b, const fortran_int_t* ldb );
+void BLAS_DTRMM( const char* side, const char* uplo, const char* transa,
+        const char* diag, const fortran_int_t* m, const fortran_int_t* n,
+        const double* alpha, const double* a, const fortran_int_t* lda,
+        double* b, const fortran_int_t* ldb );
+void BLAS_CTRMM( const char* side, const char* uplo, const char* transa,
+        const char* diag, const fortran_int_t* m, const fortran_int_t* n,
+        const void* alpha, const void* a, const fortran_int_t* lda, void* b,
+        const fortran_int_t* ldb );
+void BLAS_ZTRMM( const char* side, const char* uplo, const char* transa,
+        const char* diag, const fortran_int_t* m, const fortran_int_t* n,
+        const void* alpha, const void* a, const fortran_int_t* lda, void* b,
+        const fortran_int_t* ldb );
+
+// Value-type variants of trsm
+void BLAS_STRSM( const char* side, const char* uplo, const char* transa,
+        const char* diag, const fortran_int_t* m, const fortran_int_t* n,
+        const float* alpha, const float* a, const fortran_int_t* lda,
+        float* b, const fortran_int_t* ldb );
+void BLAS_DTRSM( const char* side, const char* uplo, const char* transa,
+        const char* diag, const fortran_int_t* m, const fortran_int_t* n,
+        const double* alpha, const double* a, const fortran_int_t* lda,
+        double* b, const fortran_int_t* ldb );
+void BLAS_CTRSM( const char* side, const char* uplo, const char* transa,
+        const char* diag, const fortran_int_t* m, const fortran_int_t* n,
+        const void* alpha, const void* a, const fortran_int_t* lda, void* b,
+        const fortran_int_t* ldb );
+void BLAS_ZTRSM( const char* side, const char* uplo, const char* transa,
+        const char* diag, const fortran_int_t* m, const fortran_int_t* n,
+        const void* alpha, const void* a, const fortran_int_t* lda, void* b,
+        const fortran_int_t* ldb );
+
+}
+
+#endif
+