diff --git a/CMakeLists.txt b/CMakeLists.txt
new file mode 100644
index 0000000..eae8fe3
--- /dev/null
+++ b/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 .
+
+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)
diff --git a/CeCILL-C.txt b/CeCILL-C.txt
new file mode 100644
index 0000000..6569837
--- /dev/null
+++ b/CeCILL-C.txt
@@ -0,0 +1,1041 @@
+
+CONTRAT DE LICENCE DE LOGICIEL LIBRE CeCILL-C
+
+
+ Avertissement
+
+Ce contrat est une licence de logiciel libre issue d'une concertation
+entre ses auteurs afin que le respect de deux grands principes préside à
+sa rédaction:
+
+ * d'une part, le respect des principes de diffusion des logiciels
+ libres: accès au code source, droits étendus conférés aux
+ utilisateurs,
+ * d'autre part, la désignation d'un droit applicable, le droit
+ français, auquel elle est conforme, tant au regard du droit de la
+ responsabilité civile que du droit de la propriété intellectuelle
+ et de la protection qu'il offre aux auteurs et titulaires des
+ droits patrimoniaux sur un logiciel.
+
+Les auteurs de la licence CeCILL-C (pour Ce[a] C[nrs] I[nria] L[ogiciel]
+L[ibre]) sont:
+
+Commissariat à l'Energie Atomique - CEA, établissement public de
+recherche à caractère scientifique, technique et industriel, dont le
+siège est situé 25 rue Leblanc, immeuble Le Ponant D, 75015 Paris.
+
+Centre National de la Recherche Scientifique - CNRS, établissement
+public à caractère scientifique et technologique, dont le siège est
+situé 3 rue Michel-Ange, 75794 Paris cedex 16.
+
+Institut National de Recherche en Informatique et en Automatique -
+INRIA, établissement public à caractère scientifique et technologique,
+dont le siège est situé Domaine de Voluceau, Rocquencourt, BP 105, 78153
+Le Chesnay cedex.
+
+
+ Préambule
+
+Ce contrat est une licence de logiciel libre dont l'objectif est de
+conférer aux utilisateurs la liberté de modifier et de réutiliser le
+logiciel régi par cette licence.
+
+L'exercice de cette liberté est assorti d'une obligation de remettre à
+la disposition de la communauté les modifications apportées au code
+source du logiciel afin de contribuer à son évolution.
+
+L'accessibilité au code source et les droits de copie, de modification
+et de redistribution qui découlent de ce contrat ont pour contrepartie
+de n'offrir aux utilisateurs qu'une garantie limitée et de ne faire
+peser sur l'auteur du logiciel, le titulaire des droits patrimoniaux et
+les concédants successifs qu'une responsabilité restreinte.
+
+A cet égard l'attention de l'utilisateur est attirée sur les risques
+associés au chargement, à l'utilisation, à la modification et/ou au
+développement et à la reproduction du logiciel par l'utilisateur étant
+donné sa spécificité de logiciel libre, qui peut le rendre complexe à
+manipuler et qui le réserve donc à des développeurs ou des
+professionnels avertis possédant des connaissances informatiques
+approfondies. Les utilisateurs sont donc invités à charger et tester
+l'adéquation du logiciel à leurs besoins dans des conditions permettant
+d'assurer la sécurité de leurs systèmes et/ou de leurs données et, plus
+généralement, à l'utiliser et l'exploiter dans les mêmes conditions de
+sécurité. Ce contrat peut être reproduit et diffusé librement, sous
+réserve de le conserver en l'état, sans ajout ni suppression de clauses.
+
+Ce contrat est susceptible de s'appliquer à tout logiciel dont le
+titulaire des droits patrimoniaux décide de soumettre l'exploitation aux
+dispositions qu'il contient.
+
+
+ Article 1 - DEFINITIONS
+
+Dans ce contrat, les termes suivants, lorsqu'ils seront écrits avec une
+lettre capitale, auront la signification suivante:
+
+Contrat: désigne le présent contrat de licence, ses éventuelles versions
+postérieures et annexes.
+
+Logiciel: désigne le logiciel sous sa forme de Code Objet et/ou de Code
+Source et le cas échéant sa documentation, dans leur état au moment de
+l'acceptation du Contrat par le Licencié.
+
+Logiciel Initial: désigne le Logiciel sous sa forme de Code Source et
+éventuellement de Code Objet et le cas échéant sa documentation, dans
+leur état au moment de leur première diffusion sous les termes du Contrat.
+
+Logiciel Modifié: désigne le Logiciel modifié par au moins une
+Contribution Intégrée.
+
+Code Source: désigne l'ensemble des instructions et des lignes de
+programme du Logiciel et auquel l'accès est nécessaire en vue de
+modifier le Logiciel.
+
+Code Objet: désigne les fichiers binaires issus de la compilation du
+Code Source.
+
+Titulaire: désigne le ou les détenteurs des droits patrimoniaux d'auteur
+sur le Logiciel Initial.
+
+Licencié: désigne le ou les utilisateurs du Logiciel ayant accepté le
+Contrat.
+
+Contributeur: désigne le Licencié auteur d'au moins une Contribution
+Intégrée.
+
+Concédant: désigne le Titulaire ou toute personne physique ou morale
+distribuant le Logiciel sous le Contrat.
+
+Contribution Intégrée: désigne l'ensemble des modifications,
+corrections, traductions, adaptations et/ou nouvelles fonctionnalités
+intégrées dans le Code Source par tout Contributeur.
+
+Module Lié: désigne un ensemble de fichiers sources y compris leur
+documentation qui, sans modification du Code Source, permet de réaliser
+des fonctionnalités ou services supplémentaires à ceux fournis par le
+Logiciel.
+
+Logiciel Dérivé: désigne toute combinaison du Logiciel, modifié ou non,
+et d'un Module Lié.
+
+Parties: désigne collectivement le Licencié et le Concédant.
+
+Ces termes s'entendent au singulier comme au pluriel.
+
+
+ Article 2 - OBJET
+
+Le Contrat a pour objet la concession par le Concédant au Licencié d'une
+licence non exclusive, cessible et mondiale du Logiciel telle que
+définie ci-après à l'article 5 pour toute la durée de protection des droits
+portant sur ce Logiciel.
+
+
+ Article 3 - ACCEPTATION
+
+3.1 L'acceptation par le Licencié des termes du Contrat est réputée
+acquise du fait du premier des faits suivants:
+
+ * (i) le chargement du Logiciel par tout moyen notamment par
+ téléchargement à partir d'un serveur distant ou par chargement à
+ partir d'un support physique;
+ * (ii) le premier exercice par le Licencié de l'un quelconque des
+ droits concédés par le Contrat.
+
+3.2 Un exemplaire du Contrat, contenant notamment un avertissement
+relatif aux spécificités du Logiciel, à la restriction de garantie et à
+la limitation à un usage par des utilisateurs expérimentés a été mis à
+disposition du Licencié préalablement à son acceptation telle que
+définie à l'article 3.1 ci dessus et le Licencié reconnaît en avoir pris
+connaissance.
+
+
+ Article 4 - ENTREE EN VIGUEUR ET DUREE
+
+
+ 4.1 ENTREE EN VIGUEUR
+
+Le Contrat entre en vigueur à la date de son acceptation par le Licencié
+telle que définie en 3.1.
+
+
+ 4.2 DUREE
+
+Le Contrat produira ses effets pendant toute la durée légale de
+protection des droits patrimoniaux portant sur le Logiciel.
+
+
+ Article 5 - ETENDUE DES DROITS CONCEDES
+
+Le Concédant concède au Licencié, qui accepte, les droits suivants sur
+le Logiciel pour toutes destinations et pour la durée du Contrat dans
+les conditions ci-après détaillées.
+
+Par ailleurs, si le Concédant détient ou venait à détenir un ou
+plusieurs brevets d'invention protégeant tout ou partie des
+fonctionnalités du Logiciel ou de ses composants, il s'engage à ne pas
+opposer les éventuels droits conférés par ces brevets aux Licenciés
+successifs qui utiliseraient, exploiteraient ou modifieraient le
+Logiciel. En cas de cession de ces brevets, le Concédant s'engage à
+faire reprendre les obligations du présent alinéa aux cessionnaires.
+
+
+ 5.1 DROIT D'UTILISATION
+
+Le Licencié est autorisé à utiliser le Logiciel, sans restriction quant
+aux domaines d'application, étant ci-après précisé que cela comporte:
+
+ 1. la reproduction permanente ou provisoire du Logiciel en tout ou
+ partie par tout moyen et sous toute forme.
+
+ 2. le chargement, l'affichage, l'exécution, ou le stockage du
+ Logiciel sur tout support.
+
+ 3. la possibilité d'en observer, d'en étudier, ou d'en tester le
+ fonctionnement afin de déterminer les idées et principes qui sont
+ à la base de n'importe quel élément de ce Logiciel; et ceci,
+ lorsque le Licencié effectue toute opération de chargement,
+ d'affichage, d'exécution, de transmission ou de stockage du
+ Logiciel qu'il est en droit d'effectuer en vertu du Contrat.
+
+
+ 5.2 DROIT DE MODIFICATION
+
+Le droit de modification comporte le droit de traduire, d'adapter,
+d'arranger ou d'apporter toute autre modification au Logiciel et le
+droit de reproduire le logiciel en résultant. Il comprend en particulier
+le droit de créer un Logiciel Dérivé.
+
+Le Licencié est autorisé à apporter toute modification au Logiciel sous
+réserve de mentionner, de façon explicite, son nom en tant qu'auteur de
+cette modification et la date de création de celle-ci.
+
+
+ 5.3 DROIT DE DISTRIBUTION
+
+Le droit de distribution comporte notamment le droit de diffuser, de
+transmettre et de communiquer le Logiciel au public sur tout support et
+par tout moyen ainsi que le droit de mettre sur le marché à titre
+onéreux ou gratuit, un ou des exemplaires du Logiciel par tout procédé.
+
+Le Licencié est autorisé à distribuer des copies du Logiciel, modifié ou
+non, à des tiers dans les conditions ci-après détaillées.
+
+
+ 5.3.1 DISTRIBUTION DU LOGICIEL SANS MODIFICATION
+
+Le Licencié est autorisé à distribuer des copies conformes du Logiciel,
+sous forme de Code Source ou de Code Objet, à condition que cette
+distribution respecte les dispositions du Contrat dans leur totalité et
+soit accompagnée:
+
+ 1. d'un exemplaire du Contrat,
+
+ 2. d'un avertissement relatif à la restriction de garantie et de
+ responsabilité du Concédant telle que prévue aux articles 8
+ et 9,
+
+et que, dans le cas où seul le Code Objet du Logiciel est redistribué,
+le Licencié permette un accès effectif au Code Source complet du
+Logiciel pendant au moins toute la durée de sa distribution du Logiciel,
+étant entendu que le coût additionnel d'acquisition du Code Source ne
+devra pas excéder le simple coût de transfert des données.
+
+
+ 5.3.2 DISTRIBUTION DU LOGICIEL MODIFIE
+
+Lorsque le Licencié apporte une Contribution Intégrée au Logiciel, les
+conditions de distribution du Logiciel Modifié en résultant sont alors
+soumises à l'intégralité des dispositions du Contrat.
+
+Le Licencié est autorisé à distribuer le Logiciel Modifié sous forme de
+code source ou de code objet, à condition que cette distribution
+respecte les dispositions du Contrat dans leur totalité et soit
+accompagnée:
+
+ 1. d'un exemplaire du Contrat,
+
+ 2. d'un avertissement relatif à la restriction de garantie et de
+ responsabilité du Concédant telle que prévue aux articles 8
+ et 9,
+
+et que, dans le cas où seul le code objet du Logiciel Modifié est
+redistribué, le Licencié permette un accès effectif à son code source
+complet pendant au moins toute la durée de sa distribution du Logiciel
+Modifié, étant entendu que le coût additionnel d'acquisition du code
+source ne devra pas excéder le simple coût de transfert des données.
+
+
+ 5.3.3 DISTRIBUTION DU LOGICIEL DERIVE
+
+Lorsque le Licencié crée un Logiciel Dérivé, ce Logiciel Dérivé peut
+être distribué sous un contrat de licence autre que le présent Contrat à
+condition de respecter les obligations de mention des droits sur le
+Logiciel telles que définies à l'article 6.4. Dans le cas où la création du
+Logiciel Dérivé a nécessité une modification du Code Source le licencié
+s'engage à ce que:
+
+ 1. le Logiciel Modifié correspondant à cette modification soit régi
+ par le présent Contrat,
+ 2. les Contributions Intégrées dont le Logiciel Modifié résulte
+ soient clairement identifiées et documentées,
+ 3. le Licencié permette un accès effectif au code source du Logiciel
+ Modifié, pendant au moins toute la durée de la distribution du
+ Logiciel Dérivé, de telle sorte que ces modifications puissent
+ être reprises dans une version ultérieure du Logiciel, étant
+ entendu que le coût additionnel d'acquisition du code source du
+ Logiciel Modifié ne devra pas excéder le simple coût du transfert
+ des données.
+
+
+ 5.3.4 COMPATIBILITE AVEC LA LICENCE CeCILL
+
+Lorsqu'un Logiciel Modifié contient une Contribution Intégrée soumise au
+contrat de licence CeCILL, ou lorsqu'un Logiciel Dérivé contient un
+Module Lié soumis au contrat de licence CeCILL, les stipulations prévues
+au troisième item de l'article 6.4 sont facultatives.
+
+
+ Article 6 - PROPRIETE INTELLECTUELLE
+
+
+ 6.1 SUR LE LOGICIEL INITIAL
+
+Le Titulaire est détenteur des droits patrimoniaux sur le Logiciel
+Initial. Toute utilisation du Logiciel Initial est soumise au respect
+des conditions dans lesquelles le Titulaire a choisi de diffuser son
+oeuvre et nul autre n'a la faculté de modifier les conditions de
+diffusion de ce Logiciel Initial.
+
+Le Titulaire s'engage à ce que le Logiciel Initial reste au moins régi
+par le Contrat et ce, pour la durée visée à l'article 4.2.
+
+
+ 6.2 SUR LES CONTRIBUTIONS INTEGREES
+
+Le Licencié qui a développé une Contribution Intégrée est titulaire sur
+celle-ci des droits de propriété intellectuelle dans les conditions
+définies par la législation applicable.
+
+
+ 6.3 SUR LES MODULES LIES
+
+Le Licencié qui a développé un Module Lié est titulaire sur celui-ci des
+droits de propriété intellectuelle dans les conditions définies par la
+législation applicable et reste libre du choix du contrat régissant sa
+diffusion dans les conditions définies à l'article 5.3.3.
+
+
+ 6.4 MENTIONS DES DROITS
+
+Le Licencié s'engage expressément:
+
+ 1. à ne pas supprimer ou modifier de quelque manière que ce soit les
+ mentions de propriété intellectuelle apposées sur le Logiciel;
+
+ 2. à reproduire à l'identique lesdites mentions de propriété
+ intellectuelle sur les copies du Logiciel modifié ou non;
+
+ 3. à faire en sorte que l'utilisation du Logiciel, ses mentions de
+ propriété intellectuelle et le fait qu'il est régi par le Contrat
+ soient indiqués dans un texte facilement accessible notamment
+ depuis l'interface de tout Logiciel Dérivé.
+
+Le Licencié s'engage à ne pas porter atteinte, directement ou
+indirectement, aux droits de propriété intellectuelle du Titulaire et/ou
+des Contributeurs sur le Logiciel et à prendre, le cas échéant, à
+l'égard de son personnel toutes les mesures nécessaires pour assurer le
+respect des dits droits de propriété intellectuelle du Titulaire et/ou
+des Contributeurs.
+
+
+ Article 7 - SERVICES ASSOCIES
+
+7.1 Le Contrat n'oblige en aucun cas le Concédant à la réalisation de
+prestations d'assistance technique ou de maintenance du Logiciel.
+
+Cependant le Concédant reste libre de proposer ce type de services. Les
+termes et conditions d'une telle assistance technique et/ou d'une telle
+maintenance seront alors déterminés dans un acte séparé. Ces actes de
+maintenance et/ou assistance technique n'engageront que la seule
+responsabilité du Concédant qui les propose.
+
+7.2 De même, tout Concédant est libre de proposer, sous sa seule
+responsabilité, à ses licenciés une garantie, qui n'engagera que lui,
+lors de la redistribution du Logiciel et/ou du Logiciel Modifié et ce,
+dans les conditions qu'il souhaite. Cette garantie et les modalités
+financières de son application feront l'objet d'un acte séparé entre le
+Concédant et le Licencié.
+
+
+ Article 8 - RESPONSABILITE
+
+8.1 Sous réserve des dispositions de l'article 8.2, le Licencié a la
+faculté, sous réserve de prouver la faute du Concédant concerné, de
+solliciter la réparation du préjudice direct qu'il subirait du fait du
+Logiciel et dont il apportera la preuve.
+
+8.2 La responsabilité du Concédant est limitée aux engagements pris en
+application du Contrat et ne saurait être engagée en raison notamment:
+(i) des dommages dus à l'inexécution, totale ou partielle, de ses
+obligations par le Licencié, (ii) des dommages directs ou indirects
+découlant de l'utilisation ou des performances du Logiciel subis par le
+Licencié et (iii) plus généralement d'un quelconque dommage indirect. En
+particulier, les Parties conviennent expressément que tout préjudice
+financier ou commercial (par exemple perte de données, perte de
+bénéfices, perte d'exploitation, perte de clientèle ou de commandes,
+manque à gagner, trouble commercial quelconque) ou toute action dirigée
+contre le Licencié par un tiers, constitue un dommage indirect et
+n'ouvre pas droit à réparation par le Concédant.
+
+
+ Article 9 - GARANTIE
+
+9.1 Le Licencié reconnaît que l'état actuel des connaissances
+scientifiques et techniques au moment de la mise en circulation du
+Logiciel ne permet pas d'en tester et d'en vérifier toutes les
+utilisations ni de détecter l'existence d'éventuels défauts. L'attention
+du Licencié a été attirée sur ce point sur les risques associés au
+chargement, à l'utilisation, la modification et/ou au développement et à
+la reproduction du Logiciel qui sont réservés à des utilisateurs avertis.
+
+Il relève de la responsabilité du Licencié de contrôler, par tous
+moyens, l'adéquation du produit à ses besoins, son bon fonctionnement et
+de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.
+
+9.2 Le Concédant déclare de bonne foi être en droit de concéder
+l'ensemble des droits attachés au Logiciel (comprenant notamment les
+droits visés à l'article 5).
+
+9.3 Le Licencié reconnaît que le Logiciel est fourni "en l'état" par le
+Concédant sans autre garantie, expresse ou tacite, que celle prévue à
+l'article 9.2 et notamment sans aucune garantie sur sa valeur commerciale,
+son caractère sécurisé, innovant ou pertinent.
+
+En particulier, le Concédant ne garantit pas que le Logiciel est exempt
+d'erreur, qu'il fonctionnera sans interruption, qu'il sera compatible
+avec l'équipement du Licencié et sa configuration logicielle ni qu'il
+remplira les besoins du Licencié.
+
+9.4 Le Concédant ne garantit pas, de manière expresse ou tacite, que le
+Logiciel ne porte pas atteinte à un quelconque droit de propriété
+intellectuelle d'un tiers portant sur un brevet, un logiciel ou sur tout
+autre droit de propriété. Ainsi, le Concédant exclut toute garantie au
+profit du Licencié contre les actions en contrefaçon qui pourraient être
+diligentées au titre de l'utilisation, de la modification, et de la
+redistribution du Logiciel. Néanmoins, si de telles actions sont
+exercées contre le Licencié, le Concédant lui apportera son aide
+technique et juridique pour sa défense. Cette aide technique et
+juridique est déterminée au cas par cas entre le Concédant concerné et
+le Licencié dans le cadre d'un protocole d'accord. Le Concédant dégage
+toute responsabilité quant à l'utilisation de la dénomination du
+Logiciel par le Licencié. Aucune garantie n'est apportée quant à
+l'existence de droits antérieurs sur le nom du Logiciel et sur
+l'existence d'une marque.
+
+
+ Article 10 - RESILIATION
+
+10.1 En cas de manquement par le Licencié aux obligations mises à sa
+charge par le Contrat, le Concédant pourra résilier de plein droit le
+Contrat trente (30) jours après notification adressée au Licencié et
+restée sans effet.
+
+10.2 Le Licencié dont le Contrat est résilié n'est plus autorisé à
+utiliser, modifier ou distribuer le Logiciel. Cependant, toutes les
+licences qu'il aura concédées antérieurement à la résiliation du Contrat
+resteront valides sous réserve qu'elles aient été effectuées en
+conformité avec le Contrat.
+
+
+ Article 11 - DISPOSITIONS DIVERSES
+
+
+ 11.1 CAUSE EXTERIEURE
+
+Aucune des Parties ne sera responsable d'un retard ou d'une défaillance
+d'exécution du Contrat qui serait dû à un cas de force majeure, un cas
+fortuit ou une cause extérieure, telle que, notamment, le mauvais
+fonctionnement ou les interruptions du réseau électrique ou de
+télécommunication, la paralysie du réseau liée à une attaque
+informatique, l'intervention des autorités gouvernementales, les
+catastrophes naturelles, les dégâts des eaux, les tremblements de terre,
+le feu, les explosions, les grèves et les conflits sociaux, l'état de
+guerre...
+
+11.2 Le fait, par l'une ou l'autre des Parties, d'omettre en une ou
+plusieurs occasions de se prévaloir d'une ou plusieurs dispositions du
+Contrat, ne pourra en aucun cas impliquer renonciation par la Partie
+intéressée à s'en prévaloir ultérieurement.
+
+11.3 Le Contrat annule et remplace toute convention antérieure, écrite
+ou orale, entre les Parties sur le même objet et constitue l'accord
+entier entre les Parties sur cet objet. Aucune addition ou modification
+aux termes du Contrat n'aura d'effet à l'égard des Parties à moins
+d'être faite par écrit et signée par leurs représentants dûment habilités.
+
+11.4 Dans l'hypothèse où une ou plusieurs des dispositions du Contrat
+s'avèrerait contraire à une loi ou à un texte applicable, existants ou
+futurs, cette loi ou ce texte prévaudrait, et les Parties feraient les
+amendements nécessaires pour se conformer à cette loi ou à ce texte.
+Toutes les autres dispositions resteront en vigueur. De même, la
+nullité, pour quelque raison que ce soit, d'une des dispositions du
+Contrat ne saurait entraîner la nullité de l'ensemble du Contrat.
+
+
+ 11.5 LANGUE
+
+Le Contrat est rédigé en langue française et en langue anglaise, ces
+deux versions faisant également foi.
+
+
+ Article 12 - NOUVELLES VERSIONS DU CONTRAT
+
+12.1 Toute personne est autorisée à copier et distribuer des copies de
+ce Contrat.
+
+12.2 Afin d'en préserver la cohérence, le texte du Contrat est protégé
+et ne peut être modifié que par les auteurs de la licence, lesquels se
+réservent le droit de publier périodiquement des mises à jour ou de
+nouvelles versions du Contrat, qui posséderont chacune un numéro
+distinct. Ces versions ultérieures seront susceptibles de prendre en
+compte de nouvelles problématiques rencontrées par les logiciels libres.
+
+12.3 Tout Logiciel diffusé sous une version donnée du Contrat ne pourra
+faire l'objet d'une diffusion ultérieure que sous la même version du
+Contrat ou une version postérieure.
+
+
+ Article 13 - LOI APPLICABLE ET COMPETENCE TERRITORIALE
+
+13.1 Le Contrat est régi par la loi française. Les Parties conviennent
+de tenter de régler à l'amiable les différends ou litiges qui
+viendraient à se produire par suite ou à l'occasion du Contrat.
+
+13.2 A défaut d'accord amiable dans un délai de deux (2) mois à compter
+de leur survenance et sauf situation relevant d'une procédure d'urgence,
+les différends ou litiges seront portés par la Partie la plus diligente
+devant les Tribunaux compétents de Paris.
+
+
+Version 1.0 du 2006-09-05.
+
+---
+
+
+CeCILL-C FREE SOFTWARE LICENSE AGREEMENT
+
+
+ Notice
+
+This Agreement is a Free Software license agreement that is the result
+of discussions between its authors in order to ensure compliance with
+the two main principles guiding its drafting:
+
+ * firstly, compliance with the principles governing the distribution
+ of Free Software: access to source code, broad rights granted to
+ users,
+ * secondly, the election of a governing law, French law, with which
+ it is conformant, both as regards the law of torts and
+ intellectual property law, and the protection that it offers to
+ both authors and holders of the economic rights over software.
+
+The authors of the CeCILL-C (for Ce[a] C[nrs] I[nria] L[ogiciel] L[ibre])
+license are:
+
+Commissariat à l'Energie Atomique - CEA, a public scientific, technical
+and industrial research establishment, having its principal place of
+business at 25 rue Leblanc, immeuble Le Ponant D, 75015 Paris, France.
+
+Centre National de la Recherche Scientifique - CNRS, a public scientific
+and technological establishment, having its principal place of business
+at 3 rue Michel-Ange, 75794 Paris cedex 16, France.
+
+Institut National de Recherche en Informatique et en Automatique -
+INRIA, a public scientific and technological establishment, having its
+principal place of business at Domaine de Voluceau, Rocquencourt, BP
+105, 78153 Le Chesnay cedex, France.
+
+
+ Preamble
+
+The purpose of this Free Software license agreement is to grant users
+the right to modify and re-use the software governed by this license.
+
+The exercising of this right is conditional upon the obligation to make
+available to the community the modifications made to the source code of
+the software so as to contribute to its evolution.
+
+In consideration of access to the source code and the rights to copy,
+modify and redistribute granted by the license, users are provided only
+with a limited warranty and the software's author, the holder of the
+economic rights, and the successive licensors only have limited liability.
+
+In this respect, the risks associated with loading, using, modifying
+and/or developing or reproducing the software by the user are brought to
+the user's attention, given its Free Software status, which may make it
+complicated to use, with the result that its use is reserved for
+developers and experienced professionals having in-depth computer
+knowledge. Users are therefore encouraged to load and test the
+suitability of the software as regards their requirements in conditions
+enabling the security of their systems and/or data to be ensured and,
+more generally, to use and operate it in the same conditions of
+security. This Agreement may be freely reproduced and published,
+provided it is not altered, and that no provisions are either added or
+removed herefrom.
+
+This Agreement may apply to any or all software for which the holder of
+the economic rights decides to submit the use thereof to its provisions.
+
+
+ Article 1 - DEFINITIONS
+
+For the purpose of this Agreement, when the following expressions
+commence with a capital letter, they shall have the following meaning:
+
+Agreement: means this license agreement, and its possible subsequent
+versions and annexes.
+
+Software: means the software in its Object Code and/or Source Code form
+and, where applicable, its documentation, "as is" when the Licensee
+accepts the Agreement.
+
+Initial Software: means the Software in its Source Code and possibly its
+Object Code form and, where applicable, its documentation, "as is" when
+it is first distributed under the terms and conditions of the Agreement.
+
+Modified Software: means the Software modified by at least one
+Integrated Contribution.
+
+Source Code: means all the Software's instructions and program lines to
+which access is required so as to modify the Software.
+
+Object Code: means the binary files originating from the compilation of
+the Source Code.
+
+Holder: means the holder(s) of the economic rights over the Initial
+Software.
+
+Licensee: means the Software user(s) having accepted the Agreement.
+
+Contributor: means a Licensee having made at least one Integrated
+Contribution.
+
+Licensor: means the Holder, or any other individual or legal entity, who
+distributes the Software under the Agreement.
+
+Integrated Contribution: means any or all modifications, corrections,
+translations, adaptations and/or new functions integrated into the
+Source Code by any or all Contributors.
+
+Related Module: means a set of sources files including their
+documentation that, without modification to the Source Code, enables
+supplementary functions or services in addition to those offered by the
+Software.
+
+Derivative Software: means any combination of the Software, modified or
+not, and of a Related Module.
+
+Parties: mean both the Licensee and the Licensor.
+
+These expressions may be used both in singular and plural form.
+
+
+ Article 2 - PURPOSE
+
+The purpose of the Agreement is the grant by the Licensor to the
+Licensee of a non-exclusive, transferable and worldwide license for the
+Software as set forth in Article 5 hereinafter for the whole term of the
+protection granted by the rights over said Software.
+
+
+ Article 3 - ACCEPTANCE
+
+3.1 The Licensee shall be deemed as having accepted the terms and
+conditions of this Agreement upon the occurrence of the first of the
+following events:
+
+ * (i) loading the Software by any or all means, notably, by
+ downloading from a remote server, or by loading from a physical
+ medium;
+ * (ii) the first time the Licensee exercises any of the rights
+ granted hereunder.
+
+3.2 One copy of the Agreement, containing a notice relating to the
+characteristics of the Software, to the limited warranty, and to the
+fact that its use is restricted to experienced users has been provided
+to the Licensee prior to its acceptance as set forth in Article 3.1
+hereinabove, and the Licensee hereby acknowledges that it has read and
+understood it.
+
+
+ Article 4 - EFFECTIVE DATE AND TERM
+
+
+ 4.1 EFFECTIVE DATE
+
+The Agreement shall become effective on the date when it is accepted by
+the Licensee as set forth in Article 3.1.
+
+
+ 4.2 TERM
+
+The Agreement shall remain in force for the entire legal term of
+protection of the economic rights over the Software.
+
+
+ Article 5 - SCOPE OF RIGHTS GRANTED
+
+The Licensor hereby grants to the Licensee, who accepts, the following
+rights over the Software for any or all use, and for the term of the
+Agreement, on the basis of the terms and conditions set forth hereinafter.
+
+Besides, if the Licensor owns or comes to own one or more patents
+protecting all or part of the functions of the Software or of its
+components, the Licensor undertakes not to enforce the rights granted by
+these patents against successive Licensees using, exploiting or
+modifying the Software. If these patents are transferred, the Licensor
+undertakes to have the transferees subscribe to the obligations set
+forth in this paragraph.
+
+
+ 5.1 RIGHT OF USE
+
+The Licensee is authorized to use the Software, without any limitation
+as to its fields of application, with it being hereinafter specified
+that this comprises:
+
+ 1. permanent or temporary reproduction of all or part of the Software
+ by any or all means and in any or all form.
+
+ 2. loading, displaying, running, or storing the Software on any or
+ all medium.
+
+ 3. entitlement to observe, study or test its operation so as to
+ determine the ideas and principles behind any or all constituent
+ elements of said Software. This shall apply when the Licensee
+ carries out any or all loading, displaying, running, transmission
+ or storage operation as regards the Software, that it is entitled
+ to carry out hereunder.
+
+
+ 5.2 RIGHT OF MODIFICATION
+
+The right of modification includes the right to translate, adapt,
+arrange, or make any or all modifications to the Software, and the right
+to reproduce the resulting software. It includes, in particular, the
+right to create a Derivative Software.
+
+The Licensee is authorized to make any or all modification to the
+Software provided that it includes an explicit notice that it is the
+author of said modification and indicates the date of the creation thereof.
+
+
+ 5.3 RIGHT OF DISTRIBUTION
+
+In particular, the right of distribution includes the right to publish,
+transmit and communicate the Software to the general public on any or
+all medium, and by any or all means, and the right to market, either in
+consideration of a fee, or free of charge, one or more copies of the
+Software by any means.
+
+The Licensee is further authorized to distribute copies of the modified
+or unmodified Software to third parties according to the terms and
+conditions set forth hereinafter.
+
+
+ 5.3.1 DISTRIBUTION OF SOFTWARE WITHOUT MODIFICATION
+
+The Licensee is authorized to distribute true copies of the Software in
+Source Code or Object Code form, provided that said distribution
+complies with all the provisions of the Agreement and is accompanied by:
+
+ 1. a copy of the Agreement,
+
+ 2. a notice relating to the limitation of both the Licensor's
+ warranty and liability as set forth in Articles 8 and 9,
+
+and that, in the event that only the Object Code of the Software is
+redistributed, the Licensee allows effective access to the full Source
+Code of the Software at a minimum during the entire period of its
+distribution of the Software, it being understood that the additional
+cost of acquiring the Source Code shall not exceed the cost of
+transferring the data.
+
+
+ 5.3.2 DISTRIBUTION OF MODIFIED SOFTWARE
+
+When the Licensee makes an Integrated Contribution to the Software, the
+terms and conditions for the distribution of the resulting Modified
+Software become subject to all the provisions of this Agreement.
+
+The Licensee is authorized to distribute the Modified Software, in
+source code or object code form, provided that said distribution
+complies with all the provisions of the Agreement and is accompanied by:
+
+ 1. a copy of the Agreement,
+
+ 2. a notice relating to the limitation of both the Licensor's
+ warranty and liability as set forth in Articles 8 and 9,
+
+and that, in the event that only the object code of the Modified
+Software is redistributed, the Licensee allows effective access to the
+full source code of the Modified Software at a minimum during the entire
+period of its distribution of the Modified Software, it being understood
+that the additional cost of acquiring the source code shall not exceed
+the cost of transferring the data.
+
+
+ 5.3.3 DISTRIBUTION OF DERIVATIVE SOFTWARE
+
+When the Licensee creates Derivative Software, this Derivative Software
+may be distributed under a license agreement other than this Agreement,
+subject to compliance with the requirement to include a notice
+concerning the rights over the Software as defined in Article 6.4.
+In the event the creation of the Derivative Software required modification
+of the Source Code, the Licensee undertakes that:
+
+ 1. the resulting Modified Software will be governed by this Agreement,
+ 2. the Integrated Contributions in the resulting Modified Software
+ will be clearly identified and documented,
+ 3. the Licensee will allow effective access to the source code of the
+ Modified Software, at a minimum during the entire period of
+ distribution of the Derivative Software, such that such
+ modifications may be carried over in a subsequent version of the
+ Software; it being understood that the additional cost of
+ purchasing the source code of the Modified Software shall not
+ exceed the cost of transferring the data.
+
+
+ 5.3.4 COMPATIBILITY WITH THE CeCILL LICENSE
+
+When a Modified Software contains an Integrated Contribution subject to
+the CeCILL license agreement, or when a Derivative Software contains a
+Related Module subject to the CeCILL license agreement, the provisions
+set forth in the third item of Article 6.4 are optional.
+
+
+ Article 6 - INTELLECTUAL PROPERTY
+
+
+ 6.1 OVER THE INITIAL SOFTWARE
+
+The Holder owns the economic rights over the Initial Software. Any or
+all use of the Initial Software is subject to compliance with the terms
+and conditions under which the Holder has elected to distribute its work
+and no one shall be entitled to modify the terms and conditions for the
+distribution of said Initial Software.
+
+The Holder undertakes that the Initial Software will remain ruled at
+least by this Agreement, for the duration set forth in Article 4.2.
+
+
+ 6.2 OVER THE INTEGRATED CONTRIBUTIONS
+
+The Licensee who develops an Integrated Contribution is the owner of the
+intellectual property rights over this Contribution as defined by
+applicable law.
+
+
+ 6.3 OVER THE RELATED MODULES
+
+The Licensee who develops a Related Module is the owner of the
+intellectual property rights over this Related Module as defined by
+applicable law and is free to choose the type of agreement that shall
+govern its distribution under the conditions defined in Article 5.3.3.
+
+
+ 6.4 NOTICE OF RIGHTS
+
+The Licensee expressly undertakes:
+
+ 1. not to remove, or modify, in any manner, the intellectual property
+ notices attached to the Software;
+
+ 2. to reproduce said notices, in an identical manner, in the copies
+ of the Software modified or not;
+
+ 3. to ensure that use of the Software, its intellectual property
+ notices and the fact that it is governed by the Agreement is
+ indicated in a text that is easily accessible, specifically from
+ the interface of any Derivative Software.
+
+The Licensee undertakes not to directly or indirectly infringe the
+intellectual property rights of the Holder and/or Contributors on the
+Software and to take, where applicable, vis-à-vis its staff, any and all
+measures required to ensure respect of said intellectual property rights
+of the Holder and/or Contributors.
+
+
+ Article 7 - RELATED SERVICES
+
+7.1 Under no circumstances shall the Agreement oblige the Licensor to
+provide technical assistance or maintenance services for the Software.
+
+However, the Licensor is entitled to offer this type of services. The
+terms and conditions of such technical assistance, and/or such
+maintenance, shall be set forth in a separate instrument. Only the
+Licensor offering said maintenance and/or technical assistance services
+shall incur liability therefor.
+
+7.2 Similarly, any Licensor is entitled to offer to its licensees, under
+its sole responsibility, a warranty, that shall only be binding upon
+itself, for the redistribution of the Software and/or the Modified
+Software, under terms and conditions that it is free to decide. Said
+warranty, and the financial terms and conditions of its application,
+shall be subject of a separate instrument executed between the Licensor
+and the Licensee.
+
+
+ Article 8 - LIABILITY
+
+8.1 Subject to the provisions of Article 8.2, the Licensee shall be
+entitled to claim compensation for any direct loss it may have suffered
+from the Software as a result of a fault on the part of the relevant
+Licensor, subject to providing evidence thereof.
+
+8.2 The Licensor's liability is limited to the commitments made under
+this Agreement and shall not be incurred as a result of in particular:
+(i) loss due the Licensee's total or partial failure to fulfill its
+obligations, (ii) direct or consequential loss that is suffered by the
+Licensee due to the use or performance of the Software, and (iii) more
+generally, any consequential loss. In particular the Parties expressly
+agree that any or all pecuniary or business loss (i.e. loss of data,
+loss of profits, operating loss, loss of customers or orders,
+opportunity cost, any disturbance to business activities) or any or all
+legal proceedings instituted against the Licensee by a third party,
+shall constitute consequential loss and shall not provide entitlement to
+any or all compensation from the Licensor.
+
+
+ Article 9 - WARRANTY
+
+9.1 The Licensee acknowledges that the scientific and technical
+state-of-the-art when the Software was distributed did not enable all
+possible uses to be tested and verified, nor for the presence of
+possible defects to be detected. In this respect, the Licensee's
+attention has been drawn to the risks associated with loading, using,
+modifying and/or developing and reproducing the Software which are
+reserved for experienced users.
+
+The Licensee shall be responsible for verifying, by any or all means,
+the suitability of the product for its requirements, its good working
+order, and for ensuring that it shall not cause damage to either persons
+or properties.
+
+9.2 The Licensor hereby represents, in good faith, that it is entitled
+to grant all the rights over the Software (including in particular the
+rights set forth in Article 5).
+
+9.3 The Licensee acknowledges that the Software is supplied "as is" by
+the Licensor without any other express or tacit warranty, other than
+that provided for in Article 9.2 and, in particular, without any warranty
+as to its commercial value, its secured, safe, innovative or relevant
+nature.
+
+Specifically, the Licensor does not warrant that the Software is free
+from any error, that it will operate without interruption, that it will
+be compatible with the Licensee's own equipment and software
+configuration, nor that it will meet the Licensee's requirements.
+
+9.4 The Licensor does not either expressly or tacitly warrant that the
+Software does not infringe any third party intellectual property right
+relating to a patent, software or any other property right. Therefore,
+the Licensor disclaims any and all liability towards the Licensee
+arising out of any or all proceedings for infringement that may be
+instituted in respect of the use, modification and redistribution of the
+Software. Nevertheless, should such proceedings be instituted against
+the Licensee, the Licensor shall provide it with technical and legal
+assistance for its defense. Such technical and legal assistance shall be
+decided on a case-by-case basis between the relevant Licensor and the
+Licensee pursuant to a memorandum of understanding. The Licensor
+disclaims any and all liability as regards the Licensee's use of the
+name of the Software. No warranty is given as regards the existence of
+prior rights over the name of the Software or as regards the existence
+of a trademark.
+
+
+ Article 10 - TERMINATION
+
+10.1 In the event of a breach by the Licensee of its obligations
+hereunder, the Licensor may automatically terminate this Agreement
+thirty (30) days after notice has been sent to the Licensee and has
+remained ineffective.
+
+10.2 A Licensee whose Agreement is terminated shall no longer be
+authorized to use, modify or distribute the Software. However, any
+licenses that it may have granted prior to termination of the Agreement
+shall remain valid subject to their having been granted in compliance
+with the terms and conditions hereof.
+
+
+ Article 11 - MISCELLANEOUS
+
+
+ 11.1 EXCUSABLE EVENTS
+
+Neither Party shall be liable for any or all delay, or failure to
+perform the Agreement, that may be attributable to an event of force
+majeure, an act of God or an outside cause, such as defective
+functioning or interruptions of the electricity or telecommunications
+networks, network paralysis following a virus attack, intervention by
+government authorities, natural disasters, water damage, earthquakes,
+fire, explosions, strikes and labor unrest, war, etc.
+
+11.2 Any failure by either Party, on one or more occasions, to invoke
+one or more of the provisions hereof, shall under no circumstances be
+interpreted as being a waiver by the interested Party of its right to
+invoke said provision(s) subsequently.
+
+11.3 The Agreement cancels and replaces any or all previous agreements,
+whether written or oral, between the Parties and having the same
+purpose, and constitutes the entirety of the agreement between said
+Parties concerning said purpose. No supplement or modification to the
+terms and conditions hereof shall be effective as between the Parties
+unless it is made in writing and signed by their duly authorized
+representatives.
+
+11.4 In the event that one or more of the provisions hereof were to
+conflict with a current or future applicable act or legislative text,
+said act or legislative text shall prevail, and the Parties shall make
+the necessary amendments so as to comply with said act or legislative
+text. All other provisions shall remain effective. Similarly, invalidity
+of a provision of the Agreement, for any reason whatsoever, shall not
+cause the Agreement as a whole to be invalid.
+
+
+ 11.5 LANGUAGE
+
+The Agreement is drafted in both French and English and both versions
+are deemed authentic.
+
+
+ Article 12 - NEW VERSIONS OF THE AGREEMENT
+
+12.1 Any person is authorized to duplicate and distribute copies of this
+Agreement.
+
+12.2 So as to ensure coherence, the wording of this Agreement is
+protected and may only be modified by the authors of the License, who
+reserve the right to periodically publish updates or new versions of the
+Agreement, each with a separate number. These subsequent versions may
+address new issues encountered by Free Software.
+
+12.3 Any Software distributed under a given version of the Agreement may
+only be subsequently distributed under the same version of the Agreement
+or a subsequent version.
+
+
+ Article 13 - GOVERNING LAW AND JURISDICTION
+
+13.1 The Agreement is governed by French law. The Parties agree to
+endeavor to seek an amicable solution to any disagreements or disputes
+that may arise during the performance of the Agreement.
+
+13.2 Failing an amicable solution within two (2) months as from their
+occurrence, and unless emergency proceedings are necessary, the
+disagreements or disputes shall be referred to the Paris Courts having
+jurisdiction, by the more diligent Party.
+
+
+Version 1.0 dated 2006-09-05.
diff --git a/Copyright b/Copyright
deleted file mode 100644
index a0fec18..0000000
--- a/Copyright
+++ /dev/null
@@ -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
\ No newline at end of file
diff --git a/LGPL-v2.txt b/LGPL-v2.txt
new file mode 100644
index 0000000..f4fac14
--- /dev/null
+++ b/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.
+
+
+ Copyright (C)
+
+ 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.
+
+ , 1 April 1990
+ Ty Coon, President of Vice
+
+That's all there is to it!
diff --git a/LICENSES.md b/LICENSES.md
new file mode 100644
index 0000000..89f27f1
--- /dev/null
+++ b/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,
+or .
+
+## Third party components
+
+### Boost under the terms of BOOST license :
+
+ 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
+
+ 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.
+
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..d7b1789
--- /dev/null
+++ b/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
+
\ No newline at end of file
diff --git a/TODO b/TODO
new file mode 100644
index 0000000..f346e7e
--- /dev/null
+++ b/TODO
@@ -0,0 +1,3 @@
+- Min/Max in renamings
+- Special handlings of boolean types in PRISM operators creators
+
diff --git a/config/FindGlib.cmake b/config/FindGlib.cmake
new file mode 100644
index 0000000..d3547d5
--- /dev/null
+++ b/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)
+
+
diff --git a/config/FindGlibmm.cmake b/config/FindGlibmm.cmake
new file mode 100644
index 0000000..1615bc2
--- /dev/null
+++ b/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)
+
diff --git a/config/FindLibXML++.cmake b/config/FindLibXML++.cmake
new file mode 100644
index 0000000..7d6c47f
--- /dev/null
+++ b/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++)
diff --git a/config/FindLibXML2.cmake b/config/FindLibXML2.cmake
new file mode 100644
index 0000000..013b278
--- /dev/null
+++ b/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
+# Modified for other libraries by Lasse Kärkkäinen
+#
+# 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)
+
diff --git a/config/FindPLplot.cmake b/config/FindPLplot.cmake
new file mode 100644
index 0000000..006a102
--- /dev/null
+++ b/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)
diff --git a/config/FindSigC++.cmake b/config/FindSigC++.cmake
new file mode 100644
index 0000000..7d34d9e
--- /dev/null
+++ b/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++)
+
diff --git a/config/FindUMFPACK.cmake b/config/FindUMFPACK.cmake
new file mode 100644
index 0000000..238f203
--- /dev/null
+++ b/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)
+
diff --git a/config/FindwxWidgetsCustom.cmake b/config/FindwxWidgetsCustom.cmake
new file mode 100644
index 0000000..b964006
--- /dev/null
+++ b/config/FindwxWidgetsCustom.cmake
@@ -0,0 +1,1086 @@
+#.rst:
+# FindwxWidgets
+# -------------
+#
+# Find a wxWidgets (a.k.a., wxWindows) installation.
+#
+# This module finds if wxWidgets is installed and selects a default
+# configuration to use. wxWidgets is a modular library. To specify the
+# modules that you will use, you need to name them as components to the
+# package:
+#
+# find_package(wxWidgets COMPONENTS core base ...)
+#
+# There are two search branches: a windows style and a unix style. For
+# windows, the following variables are searched for and set to defaults
+# in case of multiple choices. Change them if the defaults are not
+# desired (i.e., these are the only variables you should change to
+# select a configuration):
+#
+# ::
+#
+# wxWidgets_ROOT_DIR - Base wxWidgets directory
+# (e.g., C:/wxWidgets-2.6.3).
+# wxWidgets_LIB_DIR - Path to wxWidgets libraries
+# (e.g., C:/wxWidgets-2.6.3/lib/vc_lib).
+# wxWidgets_CONFIGURATION - Configuration to use
+# (e.g., msw, mswd, mswu, mswunivud, etc.)
+# wxWidgets_EXCLUDE_COMMON_LIBRARIES
+# - Set to TRUE to exclude linking of
+# commonly required libs (e.g., png tiff
+# jpeg zlib regex expat).
+#
+#
+#
+# For unix style it uses the wx-config utility. You can select between
+# debug/release, unicode/ansi, universal/non-universal, and
+# static/shared in the QtDialog or ccmake interfaces by turning ON/OFF
+# the following variables:
+#
+# ::
+#
+# wxWidgets_USE_DEBUG
+# wxWidgets_USE_UNICODE
+# wxWidgets_USE_UNIVERSAL
+# wxWidgets_USE_STATIC
+#
+#
+#
+# There is also a wxWidgets_CONFIG_OPTIONS variable for all other
+# options that need to be passed to the wx-config utility. For example,
+# to use the base toolkit found in the /usr/local path, set the variable
+# (before calling the FIND_PACKAGE command) as such:
+#
+# ::
+#
+# set(wxWidgets_CONFIG_OPTIONS --toolkit=base --prefix=/usr)
+#
+#
+#
+# The following are set after the configuration is done for both windows
+# and unix style:
+#
+# ::
+#
+# wxWidgets_FOUND - Set to TRUE if wxWidgets was found.
+# wxWidgets_INCLUDE_DIRS - Include directories for WIN32
+# i.e., where to find "wx/wx.h" and
+# "wx/setup.h"; possibly empty for unices.
+# wxWidgets_LIBRARIES - Path to the wxWidgets libraries.
+# wxWidgets_LIBRARY_DIRS - compile time link dirs, useful for
+# rpath on UNIX. Typically an empty string
+# in WIN32 environment.
+# wxWidgets_DEFINITIONS - Contains defines required to compile/link
+# against WX, e.g. WXUSINGDLL
+# wxWidgets_DEFINITIONS_DEBUG- Contains defines required to compile/link
+# against WX debug builds, e.g. __WXDEBUG__
+# wxWidgets_CXX_FLAGS - Include dirs and compiler flags for
+# unices, empty on WIN32. Essentially
+# "`wx-config --cxxflags`".
+# wxWidgets_USE_FILE - Convenience include file.
+#
+#
+#
+# Sample usage:
+#
+# ::
+#
+# # Note that for MinGW users the order of libs is important!
+# find_package(wxWidgets COMPONENTS net gl core base)
+# if(wxWidgets_FOUND)
+# include(${wxWidgets_USE_FILE})
+# # and for each of your dependent executable/library targets:
+# target_link_libraries( ${wxWidgets_LIBRARIES})
+# endif()
+#
+#
+#
+# If wxWidgets is required (i.e., not an optional part):
+#
+# ::
+#
+# find_package(wxWidgets REQUIRED net gl core base)
+# include(${wxWidgets_USE_FILE})
+# # and for each of your dependent executable/library targets:
+# target_link_libraries( ${wxWidgets_LIBRARIES})
+
+#=============================================================================
+# Copyright 2004-2009 Kitware, Inc.
+# Copyright 2007-2009 Miguel A. Figueroa-Villanueva
+#
+# Distributed under the OSI-approved BSD License (the "License");
+# see accompanying file Copyright.txt for details.
+#
+# This software is distributed WITHOUT ANY WARRANTY; without even the
+# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+# See the License for more information.
+#=============================================================================
+# (To distribute this file outside of CMake, substitute the full
+# License text for the above reference.)
+
+#
+# FIXME: check this and provide a correct sample usage...
+# Remember to connect back to the upper text.
+# Sample usage with monolithic wx build:
+#
+# find_package(wxWidgets COMPONENTS mono)
+# ...
+
+# NOTES
+#
+# This module has been tested on the WIN32 platform with wxWidgets
+# 2.6.2, 2.6.3, and 2.5.3. However, it has been designed to
+# easily extend support to all possible builds, e.g., static/shared,
+# debug/release, unicode, universal, multilib/monolithic, etc..
+#
+# If you want to use the module and your build type is not supported
+# out-of-the-box, please contact me to exchange information on how
+# your system is setup and I'll try to add support for it.
+#
+# AUTHOR
+#
+# Miguel A. Figueroa-Villanueva (miguelf at ieee dot org).
+# Jan Woetzel (jw at mip.informatik.uni-kiel.de).
+#
+# Based on previous works of:
+# Jan Woetzel (FindwxWindows.cmake),
+# Jorgen Bodde and Jerry Fath (FindwxWin.cmake).
+
+# TODO/ideas
+#
+# (1) Option/Setting to use all available wx libs
+# In contrast to expert developer who lists the
+# minimal set of required libs in wxWidgets_USE_LIBS
+# there is the newbie user:
+# - who just wants to link against WX with more 'magic'
+# - doesn't know the internal structure of WX or how it was built,
+# in particular if it is monolithic or not
+# - want to link against all available WX libs
+# Basically, the intent here is to mimic what wx-config would do by
+# default (i.e., `wx-config --libs`).
+#
+# Possible solution:
+# Add a reserved keyword "std" that initializes to what wx-config
+# would default to. If the user has not set the wxWidgets_USE_LIBS,
+# default to "std" instead of "base core" as it is now. To implement
+# "std" will basically boil down to a FOR_EACH lib-FOUND, but maybe
+# checking whether a minimal set was found.
+
+
+# FIXME: This and all the DBG_MSG calls should be removed after the
+# module stabilizes.
+#
+# Helper macro to control the debugging output globally. There are
+# two versions for controlling how verbose your output should be.
+macro(DBG_MSG _MSG)
+# message(STATUS
+# "${CMAKE_CURRENT_LIST_FILE}(${CMAKE_CURRENT_LIST_LINE}): ${_MSG}")
+endmacro()
+macro(DBG_MSG_V _MSG)
+# message(STATUS
+# "${CMAKE_CURRENT_LIST_FILE}(${CMAKE_CURRENT_LIST_LINE}): ${_MSG}")
+endmacro()
+
+# Clear return values in case the module is loaded more than once.
+set(wxWidgets_FOUND FALSE)
+set(wxWidgets_INCLUDE_DIRS "")
+set(wxWidgets_LIBRARIES "")
+set(wxWidgets_LIBRARY_DIRS "")
+set(wxWidgets_CXX_FLAGS "")
+
+# Using SYSTEM with INCLUDE_DIRECTORIES in conjunction with wxWidgets on
+# the Mac produces compiler errors. Set wxWidgets_INCLUDE_DIRS_NO_SYSTEM
+# to prevent UsewxWidgets.cmake from using SYSTEM.
+#
+# See cmake mailing list discussions for more info:
+# http://www.cmake.org/pipermail/cmake/2008-April/021115.html
+# http://www.cmake.org/pipermail/cmake/2008-April/021146.html
+#
+if(APPLE OR CMAKE_CXX_PLATFORM_ID MATCHES "OpenBSD")
+ set(wxWidgets_INCLUDE_DIRS_NO_SYSTEM 1)
+endif()
+
+# DEPRECATED: This is a patch to support the DEPRECATED use of
+# wxWidgets_USE_LIBS.
+#
+# If wxWidgets_USE_LIBS is set:
+# - if using , then override wxWidgets_USE_LIBS
+# - else set wxWidgets_FIND_COMPONENTS to wxWidgets_USE_LIBS
+if(wxWidgets_USE_LIBS AND NOT wxWidgets_FIND_COMPONENTS)
+ set(wxWidgets_FIND_COMPONENTS ${wxWidgets_USE_LIBS})
+endif()
+DBG_MSG("wxWidgets_FIND_COMPONENTS : ${wxWidgets_FIND_COMPONENTS}")
+
+# Add the convenience use file if available.
+#
+# Get dir of this file which may reside in:
+# - CMAKE_MAKE_ROOT/Modules on CMake installation
+# - CMAKE_MODULE_PATH if user prefers his own specialized version
+set(wxWidgets_USE_FILE "")
+get_filename_component(
+ wxWidgets_CURRENT_LIST_DIR ${CMAKE_CURRENT_LIST_FILE} PATH)
+# Prefer an existing customized version, but the user might override
+# the FindwxWidgets module and not the UsewxWidgets one.
+if(EXISTS "${wxWidgets_CURRENT_LIST_DIR}/UsewxWidgets.cmake")
+ set(wxWidgets_USE_FILE
+ "${wxWidgets_CURRENT_LIST_DIR}/UsewxWidgets.cmake")
+else()
+ set(wxWidgets_USE_FILE UsewxWidgets)
+endif()
+
+#=====================================================================
+# Determine whether unix or win32 paths should be used
+#=====================================================================
+if(WIN32 AND NOT CYGWIN AND NOT MSYS AND NOT CMAKE_CROSSCOMPILING)
+ set(wxWidgets_FIND_STYLE "win32")
+else()
+ set(wxWidgets_FIND_STYLE "unix")
+endif()
+
+#=====================================================================
+# WIN32_FIND_STYLE
+#=====================================================================
+if(wxWidgets_FIND_STYLE STREQUAL "win32")
+ # Useful common wx libs needed by almost all components.
+ set(wxWidgets_COMMON_LIBRARIES png tiff jpeg zlib regex expat)
+
+ # DEPRECATED: Use find_package(wxWidgets COMPONENTS mono) instead.
+ if(NOT wxWidgets_FIND_COMPONENTS)
+ if(wxWidgets_USE_MONOLITHIC)
+ set(wxWidgets_FIND_COMPONENTS mono)
+ else()
+ set(wxWidgets_FIND_COMPONENTS core base) # this is default
+ endif()
+ endif()
+
+ # Add the common (usually required libs) unless
+ # wxWidgets_EXCLUDE_COMMON_LIBRARIES has been set.
+ if(NOT wxWidgets_EXCLUDE_COMMON_LIBRARIES)
+ list(APPEND wxWidgets_FIND_COMPONENTS
+ ${wxWidgets_COMMON_LIBRARIES})
+ endif()
+
+ #-------------------------------------------------------------------
+ # WIN32: Helper MACROS
+ #-------------------------------------------------------------------
+ #
+ # Get filename components for a configuration. For example,
+ # if _CONFIGURATION = mswunivud, then _UNV=univ, _UCD=u _DBG=d
+ # if _CONFIGURATION = mswu, then _UNV="", _UCD=u _DBG=""
+ #
+ macro(WX_GET_NAME_COMPONENTS _CONFIGURATION _UNV _UCD _DBG)
+ string(REGEX MATCH "univ" ${_UNV} "${_CONFIGURATION}")
+ string(REGEX REPLACE "msw.*(u)[d]*$" "u" ${_UCD} "${_CONFIGURATION}")
+ if(${_UCD} STREQUAL ${_CONFIGURATION})
+ set(${_UCD} "")
+ endif()
+ string(REGEX MATCH "d$" ${_DBG} "${_CONFIGURATION}")
+ endmacro()
+
+ #
+ # Find libraries associated to a configuration.
+ #
+ macro(WX_FIND_LIBS _UNV _UCD _DBG)
+ DBG_MSG_V("m_unv = ${_UNV}")
+ DBG_MSG_V("m_ucd = ${_UCD}")
+ DBG_MSG_V("m_dbg = ${_DBG}")
+
+ # FIXME: What if both regex libs are available. regex should be
+ # found outside the loop and only wx${LIB}${_UCD}${_DBG}.
+ # Find wxWidgets common libraries.
+ foreach(LIB ${wxWidgets_COMMON_LIBRARIES} scintilla)
+ find_library(WX_${LIB}${_DBG}
+ NAMES
+ wx${LIB}${_UCD}${_DBG} # for regex
+ wx${LIB}${_DBG}
+ PATHS ${WX_LIB_DIR}
+ NO_DEFAULT_PATH
+ )
+ mark_as_advanced(WX_${LIB}${_DBG})
+ endforeach()
+
+ # Find wxWidgets multilib base libraries.
+ find_library(WX_base${_DBG}
+ NAMES
+ wxbase30${_UCD}${_DBG}
+ wxbase29${_UCD}${_DBG}
+ wxbase28${_UCD}${_DBG}
+ wxbase27${_UCD}${_DBG}
+ wxbase26${_UCD}${_DBG}
+ wxbase25${_UCD}${_DBG}
+ PATHS ${WX_LIB_DIR}
+ NO_DEFAULT_PATH
+ )
+ mark_as_advanced(WX_base${_DBG})
+ foreach(LIB net odbc xml)
+ find_library(WX_${LIB}${_DBG}
+ NAMES
+ wxbase30${_UCD}${_DBG}_${LIB}
+ wxbase29${_UCD}${_DBG}_${LIB}
+ wxbase28${_UCD}${_DBG}_${LIB}
+ wxbase27${_UCD}${_DBG}_${LIB}
+ wxbase26${_UCD}${_DBG}_${LIB}
+ wxbase25${_UCD}${_DBG}_${LIB}
+ PATHS ${WX_LIB_DIR}
+ NO_DEFAULT_PATH
+ )
+ mark_as_advanced(WX_${LIB}${_DBG})
+ endforeach()
+
+ # Find wxWidgets monolithic library.
+ find_library(WX_mono${_DBG}
+ NAMES
+ wxmsw${_UNV}30${_UCD}${_DBG}
+ wxmsw${_UNV}29${_UCD}${_DBG}
+ wxmsw${_UNV}28${_UCD}${_DBG}
+ wxmsw${_UNV}27${_UCD}${_DBG}
+ wxmsw${_UNV}26${_UCD}${_DBG}
+ wxmsw${_UNV}25${_UCD}${_DBG}
+ PATHS ${WX_LIB_DIR}
+ NO_DEFAULT_PATH
+ )
+ mark_as_advanced(WX_mono${_DBG})
+
+ # Find wxWidgets multilib libraries.
+ foreach(LIB core adv aui html media xrc dbgrid gl qa richtext
+ stc ribbon propgrid webview)
+ find_library(WX_${LIB}${_DBG}
+ NAMES
+ wxmsw${_UNV}30${_UCD}${_DBG}_${LIB}
+ wxmsw${_UNV}29${_UCD}${_DBG}_${LIB}
+ wxmsw${_UNV}28${_UCD}${_DBG}_${LIB}
+ wxmsw${_UNV}27${_UCD}${_DBG}_${LIB}
+ wxmsw${_UNV}26${_UCD}${_DBG}_${LIB}
+ wxmsw${_UNV}25${_UCD}${_DBG}_${LIB}
+ PATHS ${WX_LIB_DIR}
+ NO_DEFAULT_PATH
+ )
+ mark_as_advanced(WX_${LIB}${_DBG})
+ endforeach()
+ endmacro()
+
+ #
+ # Clear all library paths, so that FIND_LIBRARY refinds them.
+ #
+ # Clear a lib, reset its found flag, and mark as advanced.
+ macro(WX_CLEAR_LIB _LIB)
+ set(${_LIB} "${_LIB}-NOTFOUND" CACHE FILEPATH "Cleared." FORCE)
+ set(${_LIB}_FOUND FALSE)
+ mark_as_advanced(${_LIB})
+ endmacro()
+ # Clear all debug or release library paths (arguments are "d" or "").
+ macro(WX_CLEAR_ALL_LIBS _DBG)
+ # Clear wxWidgets common libraries.
+ foreach(LIB ${wxWidgets_COMMON_LIBRARIES} scintilla)
+ WX_CLEAR_LIB(WX_${LIB}${_DBG})
+ endforeach()
+
+ # Clear wxWidgets multilib base libraries.
+ WX_CLEAR_LIB(WX_base${_DBG})
+ foreach(LIB net odbc xml)
+ WX_CLEAR_LIB(WX_${LIB}${_DBG})
+ endforeach()
+
+ # Clear wxWidgets monolithic library.
+ WX_CLEAR_LIB(WX_mono${_DBG})
+
+ # Clear wxWidgets multilib libraries.
+ foreach(LIB core adv aui html media xrc dbgrid gl qa richtext
+ stc ribbon propgrid)
+ WX_CLEAR_LIB(WX_${LIB}${_DBG})
+ endforeach()
+ endmacro()
+ # Clear all wxWidgets debug libraries.
+ macro(WX_CLEAR_ALL_DBG_LIBS)
+ WX_CLEAR_ALL_LIBS("d")
+ endmacro()
+ # Clear all wxWidgets release libraries.
+ macro(WX_CLEAR_ALL_REL_LIBS)
+ WX_CLEAR_ALL_LIBS("")
+ endmacro()
+
+ #
+ # Set the wxWidgets_LIBRARIES variable.
+ # Also, Sets output variable wxWidgets_FOUND to FALSE if it fails.
+ #
+ macro(WX_SET_LIBRARIES _LIBS _DBG)
+ DBG_MSG_V("Looking for ${${_LIBS}}")
+ if(WX_USE_REL_AND_DBG)
+ foreach(LIB ${${_LIBS}})
+ DBG_MSG_V("Searching for ${LIB} and ${LIB}d")
+ DBG_MSG_V("WX_${LIB} : ${WX_${LIB}}")
+ DBG_MSG_V("WX_${LIB}d : ${WX_${LIB}d}")
+ if(WX_${LIB} AND WX_${LIB}d)
+ DBG_MSG_V("Found ${LIB} and ${LIB}d")
+ list(APPEND wxWidgets_LIBRARIES
+ debug ${WX_${LIB}d} optimized ${WX_${LIB}}
+ )
+ else()
+ DBG_MSG_V("- not found due to missing WX_${LIB}=${WX_${LIB}} or WX_${LIB}d=${WX_${LIB}d}")
+ set(wxWidgets_FOUND FALSE)
+ endif()
+ endforeach()
+ else()
+ foreach(LIB ${${_LIBS}})
+ DBG_MSG_V("Searching for ${LIB}${_DBG}")
+ DBG_MSG_V("WX_${LIB}${_DBG} : ${WX_${LIB}${_DBG}}")
+ if(WX_${LIB}${_DBG})
+ DBG_MSG_V("Found ${LIB}${_DBG}")
+ list(APPEND wxWidgets_LIBRARIES ${WX_${LIB}${_DBG}})
+ else()
+ DBG_MSG_V(
+ "- not found due to missing WX_${LIB}${_DBG}=${WX_${LIB}${_DBG}}")
+ set(wxWidgets_FOUND FALSE)
+ endif()
+ endforeach()
+ endif()
+
+ DBG_MSG_V("OpenGL")
+ list(FIND ${_LIBS} gl WX_USE_GL)
+ if(NOT WX_USE_GL EQUAL -1)
+ DBG_MSG_V("- is required.")
+ list(APPEND wxWidgets_LIBRARIES opengl32 glu32)
+ endif()
+
+ list(APPEND wxWidgets_LIBRARIES winmm comctl32 rpcrt4 wsock32)
+ endmacro()
+
+ #-------------------------------------------------------------------
+ # WIN32: Start actual work.
+ #-------------------------------------------------------------------
+
+ # Look for an installation tree.
+ find_path(wxWidgets_ROOT_DIR
+ NAMES include/wx/wx.h
+ PATHS
+ ENV wxWidgets_ROOT_DIR
+ ENV WXWIN
+ "[HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\wxWidgets_is1;Inno Setup: App Path]" # WX 2.6.x
+ C:/
+ D:/
+ ENV ProgramFiles
+ PATH_SUFFIXES
+ wxWidgets-3.0.0
+ wxWidgets-2.9.5
+ wxWidgets-2.9.4
+ wxWidgets-2.9.3
+ wxWidgets-2.9.2
+ wxWidgets-2.9.1
+ wxWidgets-2.9.0
+ wxWidgets-2.8.9
+ wxWidgets-2.8.8
+ wxWidgets-2.8.7
+ wxWidgets-2.8.6
+ wxWidgets-2.8.5
+ wxWidgets-2.8.4
+ wxWidgets-2.8.3
+ wxWidgets-2.8.2
+ wxWidgets-2.8.1
+ wxWidgets-2.8.0
+ wxWidgets-2.7.4
+ wxWidgets-2.7.3
+ wxWidgets-2.7.2
+ wxWidgets-2.7.1
+ wxWidgets-2.7.0
+ wxWidgets-2.7.0-1
+ wxWidgets-2.6.4
+ wxWidgets-2.6.3
+ wxWidgets-2.6.2
+ wxWidgets-2.6.1
+ wxWidgets-2.5.4
+ wxWidgets-2.5.3
+ wxWidgets-2.5.2
+ wxWidgets-2.5.1
+ wxWidgets
+ DOC "wxWidgets base/installation directory"
+ )
+
+ # If wxWidgets_ROOT_DIR changed, clear lib dir.
+ if(NOT WX_ROOT_DIR STREQUAL wxWidgets_ROOT_DIR)
+ set(WX_ROOT_DIR ${wxWidgets_ROOT_DIR}
+ CACHE INTERNAL "wxWidgets_ROOT_DIR")
+ set(wxWidgets_LIB_DIR "wxWidgets_LIB_DIR-NOTFOUND"
+ CACHE PATH "Cleared." FORCE)
+ endif()
+
+ if(WX_ROOT_DIR)
+ # Select one default tree inside the already determined wx tree.
+ # Prefer static/shared order usually consistent with build
+ # settings.
+ if(MINGW)
+ set(WX_LIB_DIR_PREFIX gcc)
+ elseif(CMAKE_CL_64)
+ set(WX_LIB_DIR_PREFIX vc_x64)
+ else()
+ set(WX_LIB_DIR_PREFIX vc)
+ endif()
+ if(BUILD_SHARED_LIBS)
+ find_path(wxWidgets_LIB_DIR
+ NAMES
+ msw/wx/setup.h
+ mswd/wx/setup.h
+ mswu/wx/setup.h
+ mswud/wx/setup.h
+ mswuniv/wx/setup.h
+ mswunivd/wx/setup.h
+ mswunivu/wx/setup.h
+ mswunivud/wx/setup.h
+ PATHS
+ ${WX_ROOT_DIR}/lib/${WX_LIB_DIR_PREFIX}_dll # prefer shared
+ ${WX_ROOT_DIR}/lib/${WX_LIB_DIR_PREFIX}_lib
+ DOC "Path to wxWidgets libraries"
+ NO_DEFAULT_PATH
+ )
+ else()
+ find_path(wxWidgets_LIB_DIR
+ NAMES
+ msw/wx/setup.h
+ mswd/wx/setup.h
+ mswu/wx/setup.h
+ mswud/wx/setup.h
+ mswuniv/wx/setup.h
+ mswunivd/wx/setup.h
+ mswunivu/wx/setup.h
+ mswunivud/wx/setup.h
+ PATHS
+ ${WX_ROOT_DIR}/lib/${WX_LIB_DIR_PREFIX}_lib # prefer static
+ ${WX_ROOT_DIR}/lib/${WX_LIB_DIR_PREFIX}_dll
+ DOC "Path to wxWidgets libraries"
+ NO_DEFAULT_PATH
+ )
+ endif()
+
+ # If wxWidgets_LIB_DIR changed, clear all libraries.
+ if(NOT WX_LIB_DIR STREQUAL wxWidgets_LIB_DIR)
+ set(WX_LIB_DIR ${wxWidgets_LIB_DIR} CACHE INTERNAL "wxWidgets_LIB_DIR")
+ WX_CLEAR_ALL_DBG_LIBS()
+ WX_CLEAR_ALL_REL_LIBS()
+ endif()
+
+ if(WX_LIB_DIR)
+ # If building shared libs, define WXUSINGDLL to use dllimport.
+ if(WX_LIB_DIR MATCHES "[dD][lL][lL]")
+ set(wxWidgets_DEFINITIONS WXUSINGDLL)
+ DBG_MSG_V("detected SHARED/DLL tree WX_LIB_DIR=${WX_LIB_DIR}")
+ endif()
+
+ # Search for available configuration types.
+ foreach(CFG mswunivud mswunivd mswud mswd mswunivu mswuniv mswu msw)
+ set(WX_${CFG}_FOUND FALSE)
+ if(EXISTS ${WX_LIB_DIR}/${CFG})
+ list(APPEND WX_CONFIGURATION_LIST ${CFG})
+ set(WX_${CFG}_FOUND TRUE)
+ set(WX_CONFIGURATION ${CFG})
+ endif()
+ endforeach()
+ DBG_MSG_V("WX_CONFIGURATION_LIST=${WX_CONFIGURATION_LIST}")
+
+ if(WX_CONFIGURATION)
+ set(wxWidgets_FOUND TRUE)
+
+ # If the selected configuration wasn't found force the default
+ # one. Otherwise, use it but still force a refresh for
+ # updating the doc string with the current list of available
+ # configurations.
+ if(NOT WX_${wxWidgets_CONFIGURATION}_FOUND)
+ set(wxWidgets_CONFIGURATION ${WX_CONFIGURATION} CACHE STRING
+ "Set wxWidgets configuration (${WX_CONFIGURATION_LIST})" FORCE)
+ else()
+ set(wxWidgets_CONFIGURATION ${wxWidgets_CONFIGURATION} CACHE STRING
+ "Set wxWidgets configuration (${WX_CONFIGURATION_LIST})" FORCE)
+ endif()
+
+ # If release config selected, and both release/debug exist.
+ if(WX_${wxWidgets_CONFIGURATION}d_FOUND)
+ option(wxWidgets_USE_REL_AND_DBG
+ "Use release and debug configurations?" TRUE)
+ set(WX_USE_REL_AND_DBG ${wxWidgets_USE_REL_AND_DBG})
+ else()
+ # If the option exists (already in cache), force it false.
+ if(wxWidgets_USE_REL_AND_DBG)
+ set(wxWidgets_USE_REL_AND_DBG FALSE CACHE BOOL
+ "No ${wxWidgets_CONFIGURATION}d found." FORCE)
+ endif()
+ set(WX_USE_REL_AND_DBG FALSE)
+ endif()
+
+ # Get configuration parameters from the name.
+ WX_GET_NAME_COMPONENTS(${wxWidgets_CONFIGURATION} UNV UCD DBG)
+
+ # Set wxWidgets lib setup include directory.
+ if(EXISTS ${WX_LIB_DIR}/${wxWidgets_CONFIGURATION}/wx/setup.h)
+ set(wxWidgets_INCLUDE_DIRS
+ ${WX_LIB_DIR}/${wxWidgets_CONFIGURATION})
+ else()
+ DBG_MSG("wxWidgets_FOUND FALSE because ${WX_LIB_DIR}/${wxWidgets_CONFIGURATION}/wx/setup.h does not exists.")
+ set(wxWidgets_FOUND FALSE)
+ endif()
+
+ # Set wxWidgets main include directory.
+ if(EXISTS ${WX_ROOT_DIR}/include/wx/wx.h)
+ list(APPEND wxWidgets_INCLUDE_DIRS ${WX_ROOT_DIR}/include)
+ else()
+ DBG_MSG("wxWidgets_FOUND FALSE because WX_ROOT_DIR=${WX_ROOT_DIR} has no ${WX_ROOT_DIR}/include/wx/wx.h")
+ set(wxWidgets_FOUND FALSE)
+ endif()
+
+ # Find wxWidgets libraries.
+ WX_FIND_LIBS("${UNV}" "${UCD}" "${DBG}")
+ if(WX_USE_REL_AND_DBG)
+ WX_FIND_LIBS("${UNV}" "${UCD}" "d")
+ endif()
+
+ # Settings for requested libs (i.e., include dir, libraries, etc.).
+ WX_SET_LIBRARIES(wxWidgets_FIND_COMPONENTS "${DBG}")
+
+ # Add necessary definitions for unicode builds
+ if("${UCD}" STREQUAL "u")
+ list(APPEND wxWidgets_DEFINITIONS UNICODE _UNICODE)
+ endif()
+
+ # Add necessary definitions for debug builds
+ set(wxWidgets_DEFINITIONS_DEBUG _DEBUG __WXDEBUG__)
+
+ endif()
+ endif()
+ endif()
+
+#=====================================================================
+# UNIX_FIND_STYLE
+#=====================================================================
+else()
+ if(wxWidgets_FIND_STYLE STREQUAL "unix")
+ #-----------------------------------------------------------------
+ # UNIX: Helper MACROS
+ #-----------------------------------------------------------------
+ #
+ # Set the default values based on "wx-config --selected-config".
+ #
+ macro(WX_CONFIG_SELECT_GET_DEFAULT)
+ execute_process(
+ COMMAND sh "${wxWidgets_CONFIG_EXECUTABLE}"
+ ${wxWidgets_CONFIG_OPTIONS} --selected-config
+ OUTPUT_VARIABLE _wx_selected_config
+ RESULT_VARIABLE _wx_result
+ ERROR_QUIET
+ )
+ if(_wx_result EQUAL 0)
+ foreach(_opt_name debug static unicode universal)
+ string(TOUPPER ${_opt_name} _upper_opt_name)
+ if(_wx_selected_config MATCHES "${_opt_name}")
+ set(wxWidgets_DEFAULT_${_upper_opt_name} ON)
+ else()
+ set(wxWidgets_DEFAULT_${_upper_opt_name} OFF)
+ endif()
+ endforeach()
+ else()
+ foreach(_upper_opt_name DEBUG STATIC UNICODE UNIVERSAL)
+ set(wxWidgets_DEFAULT_${_upper_opt_name} OFF)
+ endforeach()
+ endif()
+ endmacro()
+
+ #
+ # Query a boolean configuration option to determine if the system
+ # has both builds available. If so, provide the selection option
+ # to the user.
+ #
+ macro(WX_CONFIG_SELECT_QUERY_BOOL _OPT_NAME _OPT_HELP)
+ execute_process(
+ COMMAND sh "${wxWidgets_CONFIG_EXECUTABLE}"
+ ${wxWidgets_CONFIG_OPTIONS} --${_OPT_NAME}=yes
+ RESULT_VARIABLE _wx_result_yes
+ OUTPUT_QUIET
+ ERROR_QUIET
+ )
+ execute_process(
+ COMMAND sh "${wxWidgets_CONFIG_EXECUTABLE}"
+ ${wxWidgets_CONFIG_OPTIONS} --${_OPT_NAME}=no
+ RESULT_VARIABLE _wx_result_no
+ OUTPUT_QUIET
+ ERROR_QUIET
+ )
+ string(TOUPPER ${_OPT_NAME} _UPPER_OPT_NAME)
+ if(_wx_result_yes EQUAL 0 AND _wx_result_no EQUAL 0)
+ option(wxWidgets_USE_${_UPPER_OPT_NAME}
+ ${_OPT_HELP} ${wxWidgets_DEFAULT_${_UPPER_OPT_NAME}})
+ else()
+ # If option exists (already in cache), force to available one.
+ if(DEFINED wxWidgets_USE_${_UPPER_OPT_NAME})
+ if(_wx_result_yes EQUAL 0)
+ set(wxWidgets_USE_${_UPPER_OPT_NAME} ON CACHE BOOL ${_OPT_HELP} FORCE)
+ else()
+ set(wxWidgets_USE_${_UPPER_OPT_NAME} OFF CACHE BOOL ${_OPT_HELP} FORCE)
+ endif()
+ endif()
+ endif()
+ endmacro()
+
+ #
+ # Set wxWidgets_SELECT_OPTIONS to wx-config options for selecting
+ # among multiple builds.
+ #
+ macro(WX_CONFIG_SELECT_SET_OPTIONS)
+ set(wxWidgets_SELECT_OPTIONS ${wxWidgets_CONFIG_OPTIONS})
+ foreach(_opt_name debug static unicode universal)
+ string(TOUPPER ${_opt_name} _upper_opt_name)
+ if(DEFINED wxWidgets_USE_${_upper_opt_name})
+ if(wxWidgets_USE_${_upper_opt_name})
+ list(APPEND wxWidgets_SELECT_OPTIONS --${_opt_name}=yes)
+ else()
+ list(APPEND wxWidgets_SELECT_OPTIONS --${_opt_name}=no)
+ endif()
+ endif()
+ endforeach()
+ endmacro()
+
+ #-----------------------------------------------------------------
+ # UNIX: Start actual work.
+ #-----------------------------------------------------------------
+ # Support cross-compiling, only search in the target platform.
+ find_program(wxWidgets_CONFIG_EXECUTABLE wx-config
+ DOC "Location of wxWidgets library configuration provider binary (wx-config)."
+ ONLY_CMAKE_FIND_ROOT_PATH
+ )
+
+ if(wxWidgets_CONFIG_EXECUTABLE)
+ set(wxWidgets_FOUND TRUE)
+
+ # get defaults based on "wx-config --selected-config"
+ WX_CONFIG_SELECT_GET_DEFAULT()
+
+ # for each option: if both builds are available, provide option
+ WX_CONFIG_SELECT_QUERY_BOOL(debug "Use debug build?")
+ WX_CONFIG_SELECT_QUERY_BOOL(unicode "Use unicode build?")
+ WX_CONFIG_SELECT_QUERY_BOOL(universal "Use universal build?")
+ WX_CONFIG_SELECT_QUERY_BOOL(static "Link libraries statically?")
+
+ # process selection to set wxWidgets_SELECT_OPTIONS
+ WX_CONFIG_SELECT_SET_OPTIONS()
+ DBG_MSG("wxWidgets_SELECT_OPTIONS=${wxWidgets_SELECT_OPTIONS}")
+
+ # run the wx-config program to get cxxflags
+ execute_process(
+ COMMAND sh "${wxWidgets_CONFIG_EXECUTABLE}"
+ ${wxWidgets_SELECT_OPTIONS} --cxxflags
+ OUTPUT_VARIABLE wxWidgets_CXX_FLAGS
+ RESULT_VARIABLE RET
+ ERROR_QUIET
+ )
+ if(RET EQUAL 0)
+ string(STRIP "${wxWidgets_CXX_FLAGS}" wxWidgets_CXX_FLAGS)
+ separate_arguments(wxWidgets_CXX_FLAGS)
+
+ DBG_MSG_V("wxWidgets_CXX_FLAGS=${wxWidgets_CXX_FLAGS}")
+
+ # parse definitions from cxxflags;
+ # drop -D* from CXXFLAGS and the -D prefix
+ string(REGEX MATCHALL "-D[^;]+"
+ wxWidgets_DEFINITIONS "${wxWidgets_CXX_FLAGS}")
+ string(REGEX REPLACE "-D[^;]+(;|$)" ""
+ wxWidgets_CXX_FLAGS "${wxWidgets_CXX_FLAGS}")
+ string(REGEX REPLACE ";$" ""
+ wxWidgets_CXX_FLAGS "${wxWidgets_CXX_FLAGS}")
+ string(REPLACE "-D" ""
+ wxWidgets_DEFINITIONS "${wxWidgets_DEFINITIONS}")
+
+ # parse include dirs from cxxflags; drop -I prefix
+ string(REGEX MATCHALL "-I[^;]+"
+ wxWidgets_INCLUDE_DIRS "${wxWidgets_CXX_FLAGS}")
+ string(REGEX REPLACE "-I[^;]+;" ""
+ wxWidgets_CXX_FLAGS "${wxWidgets_CXX_FLAGS}")
+ string(REPLACE "-I" ""
+ wxWidgets_INCLUDE_DIRS "${wxWidgets_INCLUDE_DIRS}")
+
+ DBG_MSG_V("wxWidgets_DEFINITIONS=${wxWidgets_DEFINITIONS}")
+ DBG_MSG_V("wxWidgets_INCLUDE_DIRS=${wxWidgets_INCLUDE_DIRS}")
+ DBG_MSG_V("wxWidgets_CXX_FLAGS=${wxWidgets_CXX_FLAGS}")
+
+ else()
+ set(wxWidgets_FOUND FALSE)
+ DBG_MSG_V(
+ "${wxWidgets_CONFIG_EXECUTABLE} --cxxflags FAILED with RET=${RET}")
+ endif()
+
+ # run the wx-config program to get the libs
+ # - NOTE: wx-config doesn't verify that the libs requested exist
+ # it just produces the names. Maybe a TRY_COMPILE would
+ # be useful here...
+ string(REPLACE ";" ","
+ wxWidgets_FIND_COMPONENTS "${wxWidgets_FIND_COMPONENTS}")
+ execute_process(
+ COMMAND sh "${wxWidgets_CONFIG_EXECUTABLE}"
+ ${wxWidgets_SELECT_OPTIONS} --libs ${wxWidgets_FIND_COMPONENTS}
+ OUTPUT_VARIABLE wxWidgets_LIBRARIES
+ RESULT_VARIABLE RET
+ ERROR_QUIET
+ )
+ if(RET EQUAL 0)
+ string(STRIP "${wxWidgets_LIBRARIES}" wxWidgets_LIBRARIES)
+ separate_arguments(wxWidgets_LIBRARIES)
+ string(REPLACE "-framework;" "-framework "
+ wxWidgets_LIBRARIES "${wxWidgets_LIBRARIES}")
+ string(REPLACE "-arch;" "-arch "
+ wxWidgets_LIBRARIES "${wxWidgets_LIBRARIES}")
+ string(REPLACE "-isysroot;" "-isysroot "
+ wxWidgets_LIBRARIES "${wxWidgets_LIBRARIES}")
+
+ # extract linkdirs (-L) for rpath (i.e., LINK_DIRECTORIES)
+ string(REGEX MATCHALL "-L[^;]+"
+ wxWidgets_LIBRARY_DIRS "${wxWidgets_LIBRARIES}")
+ string(REPLACE "-L" ""
+ wxWidgets_LIBRARY_DIRS "${wxWidgets_LIBRARY_DIRS}")
+
+ DBG_MSG_V("wxWidgets_LIBRARIES=${wxWidgets_LIBRARIES}")
+ DBG_MSG_V("wxWidgets_LIBRARY_DIRS=${wxWidgets_LIBRARY_DIRS}")
+
+ else()
+ set(wxWidgets_FOUND FALSE)
+ DBG_MSG("${wxWidgets_CONFIG_EXECUTABLE} --libs ${wxWidgets_FIND_COMPONENTS} FAILED with RET=${RET}")
+ endif()
+ endif()
+
+#=====================================================================
+# Neither UNIX_FIND_STYLE, nor WIN32_FIND_STYLE
+#=====================================================================
+ else()
+ if(NOT wxWidgets_FIND_QUIETLY)
+ message(STATUS
+ "${CMAKE_CURRENT_LIST_FILE}(${CMAKE_CURRENT_LIST_LINE}): \n"
+ " Platform unknown/unsupported. It's neither WIN32 nor UNIX "
+ "find style."
+ )
+ endif()
+ endif()
+endif()
+
+SET(wxWidgets_LIBRARIES_GUI ${wxWidgets_LIBRARIES})
+STRING(REPLACE "-Wl,--subsystem,windows" "-Wl,--subsystem,console" wxWidgets_LIBRARIES_CONSOLE "${wxWidgets_LIBRARIES}")
+STRING(REPLACE "-mwindows" "-mconsole" wxWidgets_LIBRARIES_CONSOLE "${wxWidgets_LIBRARIES_CONSOLE}")
+
+# Debug output:
+DBG_MSG("wxWidgets_FOUND : ${wxWidgets_FOUND}")
+DBG_MSG("wxWidgets_INCLUDE_DIRS : ${wxWidgets_INCLUDE_DIRS}")
+DBG_MSG("wxWidgets_LIBRARY_DIRS : ${wxWidgets_LIBRARY_DIRS}")
+DBG_MSG("wxWidgets_LIBRARIES : ${wxWidgets_LIBRARIES}")
+DBG_MSG("wxWidgets_CXX_FLAGS : ${wxWidgets_CXX_FLAGS}")
+DBG_MSG("wxWidgets_USE_FILE : ${wxWidgets_USE_FILE}")
+
+#=====================================================================
+#=====================================================================
+include(FindPackageHandleStandardArgs)
+FIND_PACKAGE_HANDLE_STANDARD_ARGS(wxWidgets DEFAULT_MSG wxWidgets_FOUND)
+# Maintain consistency with all other variables.
+set(wxWidgets_FOUND ${WXWIDGETS_FOUND})
+
+#=====================================================================
+# Macros for use in wxWidgets apps.
+# - This module will not fail to find wxWidgets based on the code
+# below. Hence, it's required to check for validity of:
+#
+# wxWidgets_wxrc_EXECUTABLE
+#=====================================================================
+
+# Resource file compiler.
+find_program(wxWidgets_wxrc_EXECUTABLE wxrc
+ ${wxWidgets_ROOT_DIR}/utils/wxrc/vc_msw
+ DOC "Location of wxWidgets resource file compiler binary (wxrc)"
+ )
+
+#
+# WX_SPLIT_ARGUMENTS_ON( ...)
+#
+# Sets and to contain arguments to the left and right,
+# respectively, of .
+#
+# Example usage:
+# function(WXWIDGETS_ADD_RESOURCES outfiles)
+# WX_SPLIT_ARGUMENTS_ON(OPTIONS wxrc_files wxrc_options ${ARGN})
+# ...
+# endfunction()
+#
+# WXWIDGETS_ADD_RESOURCES(sources ${xrc_files} OPTIONS -e -o file.C)
+#
+# NOTE: This is a generic piece of code that should be renamed to
+# SPLIT_ARGUMENTS_ON and put in a file serving the same purpose as
+# FindPackageStandardArgs.cmake. At the time of this writing
+# FindQt4.cmake has a QT4_EXTRACT_OPTIONS, which I basically copied
+# here a bit more generalized. So, there are already two find modules
+# using this approach.
+#
+function(WX_SPLIT_ARGUMENTS_ON _keyword _leftvar _rightvar)
+ # FIXME: Document that the input variables will be cleared.
+ #list(APPEND ${_leftvar} "")
+ #list(APPEND ${_rightvar} "")
+ set(${_leftvar} "")
+ set(${_rightvar} "")
+
+ set(_doing_right FALSE)
+ foreach(element ${ARGN})
+ if("${element}" STREQUAL "${_keyword}")
+ set(_doing_right TRUE)
+ else()
+ if(_doing_right)
+ list(APPEND ${_rightvar} "${element}")
+ else()
+ list(APPEND ${_leftvar} "${element}")
+ endif()
+ endif()
+ endforeach()
+
+ set(${_leftvar} ${${_leftvar}} PARENT_SCOPE)
+ set(${_rightvar} ${${_rightvar}} PARENT_SCOPE)
+endfunction()
+
+#
+# WX_GET_DEPENDENCIES_FROM_XML(
+#
+#
+#
+#
+#
+# )
+#
+# FIXME: Add documentation here...
+#
+function(WX_GET_DEPENDENCIES_FROM_XML
+ _depends
+ _match_patt
+ _clean_patt
+ _xml_contents
+ _depends_path
+ )
+
+ string(REGEX MATCHALL
+ ${_match_patt}
+ dep_file_list
+ "${${_xml_contents}}"
+ )
+ foreach(dep_file ${dep_file_list})
+ string(REGEX REPLACE ${_clean_patt} "" dep_file "${dep_file}")
+
+ # make the file have an absolute path
+ if(NOT IS_ABSOLUTE "${dep_file}")
+ set(dep_file "${${_depends_path}}/${dep_file}")
+ endif()
+
+ # append file to dependency list
+ list(APPEND ${_depends} "${dep_file}")
+ endforeach()
+
+ set(${_depends} ${${_depends}} PARENT_SCOPE)
+endfunction()
+
+#
+# WXWIDGETS_ADD_RESOURCES(
+# OPTIONS [NO_CPP_CODE])
+#
+# Adds a custom command for resource file compilation of the
+# and appends the output files to .
+#
+# Example usages:
+# WXWIDGETS_ADD_RESOURCES(sources xrc/main_frame.xrc)
+# WXWIDGETS_ADD_RESOURCES(sources ${xrc_files} OPTIONS -e -o altname.cxx)
+#
+function(WXWIDGETS_ADD_RESOURCES _outfiles)
+ WX_SPLIT_ARGUMENTS_ON(OPTIONS rc_file_list rc_options ${ARGN})
+
+ # Parse files for dependencies.
+ set(rc_file_list_abs "")
+ set(rc_depends "")
+ foreach(rc_file ${rc_file_list})
+ get_filename_component(depends_path ${rc_file} PATH)
+
+ get_filename_component(rc_file_abs ${rc_file} ABSOLUTE)
+ list(APPEND rc_file_list_abs "${rc_file_abs}")
+
+ # All files have absolute paths or paths relative to the location
+ # of the rc file.
+ file(READ "${rc_file_abs}" rc_file_contents)
+
+ # get bitmap/bitmap2 files
+ WX_GET_DEPENDENCIES_FROM_XML(
+ rc_depends
+ "]*>"
+ rc_file_contents
+ depends_path
+ )
+
+ # get url files
+ WX_GET_DEPENDENCIES_FROM_XML(
+ rc_depends
+ "]*>"
+ rc_file_contents
+ depends_path
+ )
+
+ # get wxIcon files
+ WX_GET_DEPENDENCIES_FROM_XML(
+ rc_depends
+ "]*class=\"wxIcon\"[^<]+"
+ "^]*>"
+ rc_file_contents
+ depends_path
+ )
+ endforeach()
+
+ #
+ # Parse options.
+ #
+ # If NO_CPP_CODE option specified, then produce .xrs file rather
+ # than a .cpp file (i.e., don't add the default --cpp-code option).
+ list(FIND rc_options NO_CPP_CODE index)
+ if(index EQUAL -1)
+ list(APPEND rc_options --cpp-code)
+ # wxrc's default output filename for cpp code.
+ set(outfile resource.cpp)
+ else()
+ list(REMOVE_AT rc_options ${index})
+ # wxrc's default output filename for xrs file.
+ set(outfile resource.xrs)
+ endif()
+
+ # Get output name for use in ADD_CUSTOM_COMMAND.
+ # - short option scanning
+ list(FIND rc_options -o index)
+ if(NOT index EQUAL -1)
+ math(EXPR filename_index "${index} + 1")
+ list(GET rc_options ${filename_index} outfile)
+ #list(REMOVE_AT rc_options ${index} ${filename_index})
+ endif()
+ # - long option scanning
+ string(REGEX MATCH "--output=[^;]*" outfile_opt "${rc_options}")
+ if(outfile_opt)
+ string(REPLACE "--output=" "" outfile "${outfile_opt}")
+ endif()
+ #string(REGEX REPLACE "--output=[^;]*;?" "" rc_options "${rc_options}")
+ #string(REGEX REPLACE ";$" "" rc_options "${rc_options}")
+
+ if(NOT IS_ABSOLUTE "${outfile}")
+ set(outfile "${CMAKE_CURRENT_BINARY_DIR}/${outfile}")
+ endif()
+ add_custom_command(
+ OUTPUT "${outfile}"
+ COMMAND ${wxWidgets_wxrc_EXECUTABLE} ${rc_options} ${rc_file_list_abs}
+ DEPENDS ${rc_file_list_abs} ${rc_depends}
+ )
+
+ # Add generated header to output file list.
+ list(FIND rc_options -e short_index)
+ list(FIND rc_options --extra-cpp-code long_index)
+ if(NOT short_index EQUAL -1 OR NOT long_index EQUAL -1)
+ get_filename_component(outfile_ext ${outfile} EXT)
+ string(REPLACE "${outfile_ext}" ".h" outfile_header "${outfile}")
+ list(APPEND ${_outfiles} "${outfile_header}")
+ set_source_files_properties(
+ "${outfile_header}" PROPERTIES GENERATED TRUE
+ )
+ endif()
+
+ # Add generated file to output file list.
+ list(APPEND ${_outfiles} "${outfile}")
+
+ set(${_outfiles} ${${_outfiles}} PARENT_SCOPE)
+endfunction()
diff --git a/config/LibFindMacros.cmake b/config/LibFindMacros.cmake
new file mode 100644
index 0000000..49899a8
--- /dev/null
+++ b/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)
+
diff --git a/doc/CMakeLists.txt b/doc/CMakeLists.txt
new file mode 100644
index 0000000..fc8552a
--- /dev/null
+++ b/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 .
+
+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)
diff --git a/doc/Doxyfile.cmake b/doc/Doxyfile.cmake
new file mode 100644
index 0000000..37be3b6
--- /dev/null
+++ b/doc/Doxyfile.cmake
@@ -0,0 +1,1663 @@
+# Doxyfile 1.7.1
+
+# This file describes the settings to be used by the documentation system
+# doxygen (www.doxygen.org) for a project
+#
+# All text after a hash (#) is considered a comment and will be ignored
+# The format is:
+# TAG = value [value, ...]
+# For lists items can also be appended using:
+# TAG += value [value, ...]
+# Values that contain spaces should be placed between quotes (" ")
+
+#---------------------------------------------------------------------------
+# Project related configuration options
+#---------------------------------------------------------------------------
+
+# This tag specifies the encoding used for all characters in the config file
+# that follow. The default is UTF-8 which is also the encoding used for all
+# text before the first occurrence of this tag. Doxygen uses libiconv (or the
+# iconv built into libc) for the transcoding. See
+# http://www.gnu.org/software/libiconv for the list of possible encodings.
+
+DOXYFILE_ENCODING = UTF-8
+
+# The PROJECT_NAME tag is a single word (or a sequence of words surrounded
+# by quotes) that should identify the project.
+
+PROJECT_NAME = EPOCH
+
+# The PROJECT_NUMBER tag can be used to enter a project or revision number.
+# This could be handy for archiving the generated documentation or
+# if some version control system is used.
+
+PROJECT_NUMBER = 9999
+
+# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
+# base path where the generated documentation will be put.
+# If a relative path is entered, it will be relative to the location
+# where doxygen was started. If left blank the current directory will be used.
+
+OUTPUT_DIRECTORY = @CMAKE_BINARY_DIR@/doc
+
+# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create
+# 4096 sub-directories (in 2 levels) under the output directory of each output
+# format and will distribute the generated files over these directories.
+# Enabling this option can be useful when feeding doxygen a huge amount of
+# source files, where putting all generated files in the same directory would
+# otherwise cause performance problems for the file system.
+
+CREATE_SUBDIRS = NO
+
+# The OUTPUT_LANGUAGE tag is used to specify the language in which all
+# documentation generated by doxygen is written. Doxygen will use this
+# information to generate all constant output in the proper language.
+# The default language is English, other supported languages are:
+# Afrikaans, Arabic, Brazilian, Catalan, Chinese, Chinese-Traditional,
+# Croatian, Czech, Danish, Dutch, Esperanto, Farsi, Finnish, French, German,
+# Greek, Hungarian, Italian, Japanese, Japanese-en (Japanese with English
+# messages), Korean, Korean-en, Lithuanian, Norwegian, Macedonian, Persian,
+# Polish, Portuguese, Romanian, Russian, Serbian, Serbian-Cyrilic, Slovak,
+# Slovene, Spanish, Swedish, Ukrainian, and Vietnamese.
+
+OUTPUT_LANGUAGE = English
+
+# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will
+# include brief member descriptions after the members that are listed in
+# the file and class documentation (similar to JavaDoc).
+# Set to NO to disable this.
+
+BRIEF_MEMBER_DESC = YES
+
+# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend
+# the brief description of a member or function before the detailed description.
+# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the
+# brief descriptions will be completely suppressed.
+
+REPEAT_BRIEF = YES
+
+# This tag implements a quasi-intelligent brief description abbreviator
+# that is used to form the text in various listings. Each string
+# in this list, if found as the leading text of the brief description, will be
+# stripped from the text and the result after processing the whole list, is
+# used as the annotated text. Otherwise, the brief description is used as-is.
+# If left blank, the following values are used ("$name" is automatically
+# replaced with the name of the entity): "The $name class" "The $name widget"
+# "The $name file" "is" "provides" "specifies" "contains"
+# "represents" "a" "an" "the"
+
+ABBREVIATE_BRIEF = "The $name class" \
+ "The $name widget" \
+ "The $name file" \
+ is \
+ provides \
+ specifies \
+ contains \
+ represents \
+ a \
+ an \
+ the
+
+# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then
+# Doxygen will generate a detailed section even if there is only a brief
+# description.
+
+ALWAYS_DETAILED_SEC = NO
+
+# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all
+# inherited members of a class in the documentation of that class as if those
+# members were ordinary class members. Constructors, destructors and assignment
+# operators of the base classes will not be shown.
+
+INLINE_INHERITED_MEMB = NO
+
+# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full
+# path before files name in the file list and in the header files. If set
+# to NO the shortest path that makes the file name unique will be used.
+
+FULL_PATH_NAMES = YES
+
+# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag
+# can be used to strip a user-defined part of the path. Stripping is
+# only done if one of the specified strings matches the left-hand part of
+# the path. The tag can be used to show relative paths in the file list.
+# If left blank the directory from which doxygen is run is used as the
+# path to strip.
+
+STRIP_FROM_PATH = @CMAKE_BINARY_DIR@/doc/
+
+# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of
+# the path mentioned in the documentation of a class, which tells
+# the reader which header file to include in order to use a class.
+# If left blank only the name of the header file containing the class
+# definition is used. Otherwise one should specify the include paths that
+# are normally passed to the compiler using the -I flag.
+
+STRIP_FROM_INC_PATH =
+
+# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter
+# (but less readable) file names. This can be useful is your file systems
+# doesn't support long names like on DOS, Mac, or CD-ROM.
+
+SHORT_NAMES = NO
+
+# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen
+# will interpret the first line (until the first dot) of a JavaDoc-style
+# comment as the brief description. If set to NO, the JavaDoc
+# comments will behave just like regular Qt-style comments
+# (thus requiring an explicit @brief command for a brief description.)
+
+JAVADOC_AUTOBRIEF = NO
+
+# If the QT_AUTOBRIEF tag is set to YES then Doxygen will
+# interpret the first line (until the first dot) of a Qt-style
+# comment as the brief description. If set to NO, the comments
+# will behave just like regular Qt-style comments (thus requiring
+# an explicit \brief command for a brief description.)
+
+QT_AUTOBRIEF = NO
+
+# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen
+# treat a multi-line C++ special comment block (i.e. a block of //! or ///
+# comments) as a brief description. This used to be the default behaviour.
+# The new default is to treat a multi-line C++ comment block as a detailed
+# description. Set this tag to YES if you prefer the old behaviour instead.
+
+MULTILINE_CPP_IS_BRIEF = NO
+
+# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented
+# member inherits the documentation from any documented member that it
+# re-implements.
+
+INHERIT_DOCS = YES
+
+# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce
+# a new page for each member. If set to NO, the documentation of a member will
+# be part of the file/class/namespace that contains it.
+
+SEPARATE_MEMBER_PAGES = NO
+
+# The TAB_SIZE tag can be used to set the number of spaces in a tab.
+# Doxygen uses this value to replace tabs by spaces in code fragments.
+
+TAB_SIZE = 8
+
+# This tag can be used to specify a number of aliases that acts
+# as commands in the documentation. An alias has the form "name=value".
+# For example adding "sideeffect=\par Side Effects:\n" will allow you to
+# put the command \sideeffect (or @sideeffect) in the documentation, which
+# will result in a user-defined paragraph with heading "Side Effects:".
+# You can put \n's in the value part of an alias to insert newlines.
+
+ALIASES =
+
+# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C
+# sources only. Doxygen will then generate output that is more tailored for C.
+# For instance, some of the names that are used will be different. The list
+# of all members will be omitted, etc.
+
+OPTIMIZE_OUTPUT_FOR_C = NO
+
+# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java
+# sources only. Doxygen will then generate output that is more tailored for
+# Java. For instance, namespaces will be presented as packages, qualified
+# scopes will look different, etc.
+
+OPTIMIZE_OUTPUT_JAVA = NO
+
+# Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran
+# sources only. Doxygen will then generate output that is more tailored for
+# Fortran.
+
+OPTIMIZE_FOR_FORTRAN = NO
+
+# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL
+# sources. Doxygen will then generate output that is tailored for
+# VHDL.
+
+OPTIMIZE_OUTPUT_VHDL = NO
+
+# Doxygen selects the parser to use depending on the extension of the files it
+# parses. With this tag you can assign which parser to use for a given extension.
+# Doxygen has a built-in mapping, but you can override or extend it using this
+# tag. The format is ext=language, where ext is a file extension, and language
+# is one of the parsers supported by doxygen: IDL, Java, Javascript, CSharp, C,
+# C++, D, PHP, Objective-C, Python, Fortran, VHDL, C, C++. For instance to make
+# doxygen treat .inc files as Fortran files (default is PHP), and .f files as C
+# (default is Fortran), use: inc=Fortran f=C. Note that for custom extensions
+# you also need to set FILE_PATTERNS otherwise the files are not read by doxygen.
+
+EXTENSION_MAPPING =
+
+# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want
+# to include (a tag file for) the STL sources as input, then you should
+# set this tag to YES in order to let doxygen match functions declarations and
+# definitions whose arguments contain STL classes (e.g. func(std::string); v.s.
+# func(std::string) {}). This also make the inheritance and collaboration
+# diagrams that involve STL classes more complete and accurate.
+
+BUILTIN_STL_SUPPORT = YES
+
+# If you use Microsoft's C++/CLI language, you should set this option to YES to
+# enable parsing support.
+
+CPP_CLI_SUPPORT = NO
+
+# Set the SIP_SUPPORT tag to YES if your project consists of sip sources only.
+# Doxygen will parse them like normal C++ but will assume all classes use public
+# instead of private inheritance when no explicit protection keyword is present.
+
+SIP_SUPPORT = NO
+
+# For Microsoft's IDL there are propget and propput attributes to indicate getter
+# and setter methods for a property. Setting this option to YES (the default)
+# will make doxygen to replace the get and set methods by a property in the
+# documentation. This will only work if the methods are indeed getting or
+# setting a simple type. If this is not the case, or you want to show the
+# methods anyway, you should set this option to NO.
+
+IDL_PROPERTY_SUPPORT = YES
+
+# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC
+# tag is set to YES, then doxygen will reuse the documentation of the first
+# member in the group (if any) for the other members of the group. By default
+# all members of a group must be documented explicitly.
+
+DISTRIBUTE_GROUP_DOC = NO
+
+# Set the SUBGROUPING tag to YES (the default) to allow class member groups of
+# the same type (for instance a group of public functions) to be put as a
+# subgroup of that type (e.g. under the Public Functions section). Set it to
+# NO to prevent subgrouping. Alternatively, this can be done per class using
+# the \nosubgrouping command.
+
+SUBGROUPING = YES
+
+# When TYPEDEF_HIDES_STRUCT is enabled, a typedef of a struct, union, or enum
+# is documented as struct, union, or enum with the name of the typedef. So
+# typedef struct TypeS {} TypeT, will appear in the documentation as a struct
+# with name TypeT. When disabled the typedef will appear as a member of a file,
+# namespace, or class. And the struct will be named TypeS. This can typically
+# be useful for C code in case the coding convention dictates that all compound
+# types are typedef'ed and only the typedef is referenced, never the tag name.
+
+TYPEDEF_HIDES_STRUCT = NO
+
+# The SYMBOL_CACHE_SIZE determines the size of the internal cache use to
+# determine which symbols to keep in memory and which to flush to disk.
+# When the cache is full, less often used symbols will be written to disk.
+# For small to medium size projects (<1000 input files) the default value is
+# probably good enough. For larger projects a too small cache size can cause
+# doxygen to be busy swapping symbols to and from disk most of the time
+# causing a significant performance penality.
+# If the system has enough physical memory increasing the cache will improve the
+# performance by keeping more symbols in memory. Note that the value works on
+# a logarithmic scale so increasing the size by one will rougly double the
+# memory usage. The cache size is given by this formula:
+# 2^(16+SYMBOL_CACHE_SIZE). The valid range is 0..9, the default is 0,
+# corresponding to a cache size of 2^16 = 65536 symbols
+
+SYMBOL_CACHE_SIZE = 0
+
+#---------------------------------------------------------------------------
+# Build related configuration options
+#---------------------------------------------------------------------------
+
+# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in
+# documentation are documented, even if no documentation was available.
+# Private class members and static file members will be hidden unless
+# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES
+
+EXTRACT_ALL = YES
+
+# If the EXTRACT_PRIVATE tag is set to YES all private members of a class
+# will be included in the documentation.
+
+EXTRACT_PRIVATE = YES
+
+# If the EXTRACT_STATIC tag is set to YES all static members of a file
+# will be included in the documentation.
+
+EXTRACT_STATIC = YES
+
+# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs)
+# defined locally in source files will be included in the documentation.
+# If set to NO only classes defined in header files are included.
+
+EXTRACT_LOCAL_CLASSES = YES
+
+# This flag is only useful for Objective-C code. When set to YES local
+# methods, which are defined in the implementation section but not in
+# the interface are included in the documentation.
+# If set to NO (the default) only methods in the interface are included.
+
+EXTRACT_LOCAL_METHODS = NO
+
+# If this flag is set to YES, the members of anonymous namespaces will be
+# extracted and appear in the documentation as a namespace called
+# 'anonymous_namespace{file}', where file will be replaced with the base
+# name of the file that contains the anonymous namespace. By default
+# anonymous namespace are hidden.
+
+EXTRACT_ANON_NSPACES = NO
+
+# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all
+# undocumented members of documented classes, files or namespaces.
+# If set to NO (the default) these members will be included in the
+# various overviews, but no documentation section is generated.
+# This option has no effect if EXTRACT_ALL is enabled.
+
+HIDE_UNDOC_MEMBERS = NO
+
+# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all
+# undocumented classes that are normally visible in the class hierarchy.
+# If set to NO (the default) these classes will be included in the various
+# overviews. This option has no effect if EXTRACT_ALL is enabled.
+
+HIDE_UNDOC_CLASSES = NO
+
+# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all
+# friend (class|struct|union) declarations.
+# If set to NO (the default) these declarations will be included in the
+# documentation.
+
+HIDE_FRIEND_COMPOUNDS = NO
+
+# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any
+# documentation blocks found inside the body of a function.
+# If set to NO (the default) these blocks will be appended to the
+# function's detailed documentation block.
+
+HIDE_IN_BODY_DOCS = NO
+
+# The INTERNAL_DOCS tag determines if documentation
+# that is typed after a \internal command is included. If the tag is set
+# to NO (the default) then the documentation will be excluded.
+# Set it to YES to include the internal documentation.
+
+INTERNAL_DOCS = NO
+
+# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate
+# file names in lower-case letters. If set to YES upper-case letters are also
+# allowed. This is useful if you have classes or files whose names only differ
+# in case and if your file system supports case sensitive file names. Windows
+# and Mac users are advised to set this option to NO.
+
+CASE_SENSE_NAMES = NO
+
+# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen
+# will show members with their full class and namespace scopes in the
+# documentation. If set to YES the scope will be hidden.
+
+HIDE_SCOPE_NAMES = NO
+
+# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen
+# will put a list of the files that are included by a file in the documentation
+# of that file.
+
+SHOW_INCLUDE_FILES = YES
+
+# If the FORCE_LOCAL_INCLUDES tag is set to YES then Doxygen
+# will list include files with double quotes in the documentation
+# rather than with sharp brackets.
+
+FORCE_LOCAL_INCLUDES = NO
+
+# If the INLINE_INFO tag is set to YES (the default) then a tag [inline]
+# is inserted in the documentation for inline members.
+
+INLINE_INFO = YES
+
+# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen
+# will sort the (detailed) documentation of file and class members
+# alphabetically by member name. If set to NO the members will appear in
+# declaration order.
+
+SORT_MEMBER_DOCS = YES
+
+# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the
+# brief documentation of file, namespace and class members alphabetically
+# by member name. If set to NO (the default) the members will appear in
+# declaration order.
+
+SORT_BRIEF_DOCS = NO
+
+# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen
+# will sort the (brief and detailed) documentation of class members so that
+# constructors and destructors are listed first. If set to NO (the default)
+# the constructors will appear in the respective orders defined by
+# SORT_MEMBER_DOCS and SORT_BRIEF_DOCS.
+# This tag will be ignored for brief docs if SORT_BRIEF_DOCS is set to NO
+# and ignored for detailed docs if SORT_MEMBER_DOCS is set to NO.
+
+SORT_MEMBERS_CTORS_1ST = NO
+
+# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the
+# hierarchy of group names into alphabetical order. If set to NO (the default)
+# the group names will appear in their defined order.
+
+SORT_GROUP_NAMES = NO
+
+# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be
+# sorted by fully-qualified names, including namespaces. If set to
+# NO (the default), the class list will be sorted only by class name,
+# not including the namespace part.
+# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES.
+# Note: This option applies only to the class list, not to the
+# alphabetical list.
+
+SORT_BY_SCOPE_NAME = NO
+
+# The GENERATE_TODOLIST tag can be used to enable (YES) or
+# disable (NO) the todo list. This list is created by putting \todo
+# commands in the documentation.
+
+GENERATE_TODOLIST = YES
+
+# The GENERATE_TESTLIST tag can be used to enable (YES) or
+# disable (NO) the test list. This list is created by putting \test
+# commands in the documentation.
+
+GENERATE_TESTLIST = YES
+
+# The GENERATE_BUGLIST tag can be used to enable (YES) or
+# disable (NO) the bug list. This list is created by putting \bug
+# commands in the documentation.
+
+GENERATE_BUGLIST = YES
+
+# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or
+# disable (NO) the deprecated list. This list is created by putting
+# \deprecated commands in the documentation.
+
+GENERATE_DEPRECATEDLIST= YES
+
+# The ENABLED_SECTIONS tag can be used to enable conditional
+# documentation sections, marked by \if sectionname ... \endif.
+
+ENABLED_SECTIONS =
+
+# The MAX_INITIALIZER_LINES tag determines the maximum number of lines
+# the initial value of a variable or define consists of for it to appear in
+# the documentation. If the initializer consists of more lines than specified
+# here it will be hidden. Use a value of 0 to hide initializers completely.
+# The appearance of the initializer of individual variables and defines in the
+# documentation can be controlled using \showinitializer or \hideinitializer
+# command in the documentation regardless of this setting.
+
+MAX_INITIALIZER_LINES = 30
+
+# Set the SHOW_USED_FILES tag to NO to disable the list of files generated
+# at the bottom of the documentation of classes and structs. If set to YES the
+# list will mention the files that were used to generate the documentation.
+
+SHOW_USED_FILES = YES
+
+# If the sources in your project are distributed over multiple directories
+# then setting the SHOW_DIRECTORIES tag to YES will show the directory hierarchy
+# in the documentation. The default is NO.
+
+SHOW_DIRECTORIES = YES
+
+# Set the SHOW_FILES tag to NO to disable the generation of the Files page.
+# This will remove the Files entry from the Quick Index and from the
+# Folder Tree View (if specified). The default is YES.
+
+SHOW_FILES = YES
+
+# Set the SHOW_NAMESPACES tag to NO to disable the generation of the
+# Namespaces page. This will remove the Namespaces entry from the Quick Index
+# and from the Folder Tree View (if specified). The default is YES.
+
+SHOW_NAMESPACES = YES
+
+# The FILE_VERSION_FILTER tag can be used to specify a program or script that
+# doxygen should invoke to get the current version for each file (typically from
+# the version control system). Doxygen will invoke the program by executing (via
+# popen()) the command , where is the value of
+# the FILE_VERSION_FILTER tag, and is the name of an input file
+# provided by doxygen. Whatever the program writes to standard output
+# is used as the file version. See the manual for examples.
+
+FILE_VERSION_FILTER =
+
+# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed
+# by doxygen. The layout file controls the global structure of the generated
+# output files in an output format independent way. The create the layout file
+# that represents doxygen's defaults, run doxygen with the -l option.
+# You can optionally specify a file name after the option, if omitted
+# DoxygenLayout.xml will be used as the name of the layout file.
+
+LAYOUT_FILE =
+
+#---------------------------------------------------------------------------
+# configuration options related to warning and progress messages
+#---------------------------------------------------------------------------
+
+# The QUIET tag can be used to turn on/off the messages that are generated
+# by doxygen. Possible values are YES and NO. If left blank NO is used.
+
+QUIET = NO
+
+# The WARNINGS tag can be used to turn on/off the warning messages that are
+# generated by doxygen. Possible values are YES and NO. If left blank
+# NO is used.
+
+WARNINGS = YES
+
+# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings
+# for undocumented members. If EXTRACT_ALL is set to YES then this flag will
+# automatically be disabled.
+
+WARN_IF_UNDOCUMENTED = YES
+
+# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for
+# potential errors in the documentation, such as not documenting some
+# parameters in a documented function, or documenting parameters that
+# don't exist or using markup commands wrongly.
+
+WARN_IF_DOC_ERROR = YES
+
+# This WARN_NO_PARAMDOC option can be abled to get warnings for
+# functions that are documented, but have no documentation for their parameters
+# or return value. If set to NO (the default) doxygen will only warn about
+# wrong or incomplete parameter documentation, but not about the absence of
+# documentation.
+
+WARN_NO_PARAMDOC = NO
+
+# The WARN_FORMAT tag determines the format of the warning messages that
+# doxygen can produce. The string should contain the $file, $line, and $text
+# tags, which will be replaced by the file and line number from which the
+# warning originated and the warning text. Optionally the format may contain
+# $version, which will be replaced by the version of the file (if it could
+# be obtained via FILE_VERSION_FILTER)
+
+WARN_FORMAT = "$file:$line: $text"
+
+# The WARN_LOGFILE tag can be used to specify a file to which warning
+# and error messages should be written. If left blank the output is written
+# to stderr.
+
+WARN_LOGFILE =
+
+#---------------------------------------------------------------------------
+# configuration options related to the input files
+#---------------------------------------------------------------------------
+
+# The INPUT tag can be used to specify the files and/or directories that contain
+# documented source files. You may enter file names like "myfile.cpp" or
+# directories like "/usr/src/myproject". Separate the files or directories
+# with spaces.
+
+INPUT = @CMAKE_SOURCE_DIR@
+
+# This tag can be used to specify the character encoding of the source files
+# that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is
+# also the default input encoding. Doxygen uses libiconv (or the iconv built
+# into libc) for the transcoding. See http://www.gnu.org/software/libiconv for
+# the list of possible encodings.
+
+INPUT_ENCODING = UTF-8
+
+# If the value of the INPUT tag contains directories, you can use the
+# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
+# and *.h) to filter out the source-files in the directories. If left
+# blank the following patterns are tested:
+# *.c *.cc *.cxx *.cpp *.c++ *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh *.hxx
+# *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.py *.f90
+
+FILE_PATTERNS = *.c \
+ *.cc \
+ *.cxx \
+ *.cpp \
+ *.c++ \
+ *.d \
+ *.java \
+ *.ii \
+ *.ixx \
+ *.ipp \
+ *.i++ \
+ *.inl \
+ *.h \
+ *.hh \
+ *.hxx \
+ *.hpp \
+ *.h++ \
+ *.idl \
+ *.odl \
+ *.cs \
+ *.php \
+ *.php3 \
+ *.inc \
+ *.m \
+ *.mm \
+ *.dox \
+ *.py \
+ *.f90 \
+ *.f \
+ *.vhd \
+ *.vhdl \
+ *.ipp \
+ *.tpp
+
+# The RECURSIVE tag can be used to turn specify whether or not subdirectories
+# should be searched for input files as well. Possible values are YES and NO.
+# If left blank NO is used.
+
+RECURSIVE = YES
+
+# The EXCLUDE tag can be used to specify files and/or directories that should
+# excluded from the INPUT source files. This way you can easily exclude a
+# subdirectory from a directory tree whose root is specified with the INPUT tag.
+
+EXCLUDE =
+
+# The EXCLUDE_SYMLINKS tag can be used select whether or not files or
+# directories that are symbolic links (a Unix filesystem feature) are excluded
+# from the input.
+
+EXCLUDE_SYMLINKS = NO
+
+# If the value of the INPUT tag contains directories, you can use the
+# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude
+# certain files from those directories. Note that the wildcards are matched
+# against the file with absolute path, so to exclude all test directories
+# for example use the pattern */test/*
+
+EXCLUDE_PATTERNS =
+
+# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names
+# (namespaces, classes, functions, etc.) that should be excluded from the
+# output. The symbol name can be a fully qualified name, a word, or if the
+# wildcard * is used, a substring. Examples: ANamespace, AClass,
+# AClass::ANamespace, ANamespace::*Test
+
+EXCLUDE_SYMBOLS =
+
+# The EXAMPLE_PATH tag can be used to specify one or more files or
+# directories that contain example code fragments that are included (see
+# the \include command).
+
+EXAMPLE_PATH =
+
+# If the value of the EXAMPLE_PATH tag contains directories, you can use the
+# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp
+# and *.h) to filter out the source-files in the directories. If left
+# blank all files are included.
+
+EXAMPLE_PATTERNS = *
+
+# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be
+# searched for input files to be used with the \include or \dontinclude
+# commands irrespective of the value of the RECURSIVE tag.
+# Possible values are YES and NO. If left blank NO is used.
+
+EXAMPLE_RECURSIVE = NO
+
+# The IMAGE_PATH tag can be used to specify one or more files or
+# directories that contain image that are included in the documentation (see
+# the \image command).
+
+IMAGE_PATH =
+
+# The INPUT_FILTER tag can be used to specify a program that doxygen should
+# invoke to filter for each input file. Doxygen will invoke the filter program
+# by executing (via popen()) the command , where
+# is the value of the INPUT_FILTER tag, and is the name of an
+# input file. Doxygen will then use the output that the filter program writes
+# to standard output. If FILTER_PATTERNS is specified, this tag will be
+# ignored.
+
+INPUT_FILTER =
+
+# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern
+# basis. Doxygen will compare the file name with each pattern and apply the
+# filter if there is a match. The filters are a list of the form:
+# pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further
+# info on how filters are used. If FILTER_PATTERNS is empty, INPUT_FILTER
+# is applied to all files.
+
+FILTER_PATTERNS =
+
+# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using
+# INPUT_FILTER) will be used to filter the input files when producing source
+# files to browse (i.e. when SOURCE_BROWSER is set to YES).
+
+FILTER_SOURCE_FILES = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to source browsing
+#---------------------------------------------------------------------------
+
+# If the SOURCE_BROWSER tag is set to YES then a list of source files will
+# be generated. Documented entities will be cross-referenced with these sources.
+# Note: To get rid of all source code in the generated output, make sure also
+# VERBATIM_HEADERS is set to NO.
+
+SOURCE_BROWSER = YES
+
+# Setting the INLINE_SOURCES tag to YES will include the body
+# of functions and classes directly in the documentation.
+
+INLINE_SOURCES = NO
+
+# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct
+# doxygen to hide any special comment blocks from generated source code
+# fragments. Normal C and C++ comments will always remain visible.
+
+STRIP_CODE_COMMENTS = YES
+
+# If the REFERENCED_BY_RELATION tag is set to YES
+# then for each documented function all documented
+# functions referencing it will be listed.
+
+REFERENCED_BY_RELATION = NO
+
+# If the REFERENCES_RELATION tag is set to YES
+# then for each documented function all documented entities
+# called/used by that function will be listed.
+
+REFERENCES_RELATION = NO
+
+# If the REFERENCES_LINK_SOURCE tag is set to YES (the default)
+# and SOURCE_BROWSER tag is set to YES, then the hyperlinks from
+# functions in REFERENCES_RELATION and REFERENCED_BY_RELATION lists will
+# link to the source code. Otherwise they will link to the documentation.
+
+REFERENCES_LINK_SOURCE = YES
+
+# If the USE_HTAGS tag is set to YES then the references to source code
+# will point to the HTML generated by the htags(1) tool instead of doxygen
+# built-in source browser. The htags tool is part of GNU's global source
+# tagging system (see http://www.gnu.org/software/global/global.html). You
+# will need version 4.8.6 or higher.
+
+USE_HTAGS = NO
+
+# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen
+# will generate a verbatim copy of the header file for each class for
+# which an include is specified. Set to NO to disable this.
+
+VERBATIM_HEADERS = YES
+
+#---------------------------------------------------------------------------
+# configuration options related to the alphabetical class index
+#---------------------------------------------------------------------------
+
+# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index
+# of all compounds will be generated. Enable this if the project
+# contains a lot of classes, structs, unions or interfaces.
+
+ALPHABETICAL_INDEX = YES
+
+# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then
+# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns
+# in which this list will be split (can be a number in the range [1..20])
+
+COLS_IN_ALPHA_INDEX = 5
+
+# In case all classes in a project start with a common prefix, all
+# classes will be put under the same header in the alphabetical index.
+# The IGNORE_PREFIX tag can be used to specify one or more prefixes that
+# should be ignored while generating the index headers.
+
+IGNORE_PREFIX =
+
+#---------------------------------------------------------------------------
+# configuration options related to the HTML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_HTML tag is set to YES (the default) Doxygen will
+# generate HTML output.
+
+GENERATE_HTML = YES
+
+# The HTML_OUTPUT tag is used to specify where the HTML docs will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `html' will be used as the default path.
+
+HTML_OUTPUT = html
+
+# The HTML_FILE_EXTENSION tag can be used to specify the file extension for
+# each generated HTML page (for example: .htm,.php,.asp). If it is left blank
+# doxygen will generate files with .html extension.
+
+HTML_FILE_EXTENSION = .html
+
+# The HTML_HEADER tag can be used to specify a personal HTML header for
+# each generated HTML page. If it is left blank doxygen will generate a
+# standard header.
+
+HTML_HEADER =
+
+# The HTML_FOOTER tag can be used to specify a personal HTML footer for
+# each generated HTML page. If it is left blank doxygen will generate a
+# standard footer.
+
+HTML_FOOTER =
+
+# The HTML_STYLESHEET tag can be used to specify a user-defined cascading
+# style sheet that is used by each HTML page. It can be used to
+# fine-tune the look of the HTML output. If the tag is left blank doxygen
+# will generate a default style sheet. Note that doxygen will try to copy
+# the style sheet file to the HTML output directory, so don't put your own
+# stylesheet in the HTML output directory as well, or it will be erased!
+
+HTML_STYLESHEET =
+
+# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output.
+# Doxygen will adjust the colors in the stylesheet and background images
+# according to this color. Hue is specified as an angle on a colorwheel,
+# see http://en.wikipedia.org/wiki/Hue for more information.
+# For instance the value 0 represents red, 60 is yellow, 120 is green,
+# 180 is cyan, 240 is blue, 300 purple, and 360 is red again.
+# The allowed range is 0 to 359.
+
+HTML_COLORSTYLE_HUE = 220
+
+# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of
+# the colors in the HTML output. For a value of 0 the output will use
+# grayscales only. A value of 255 will produce the most vivid colors.
+
+HTML_COLORSTYLE_SAT = 100
+
+# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to
+# the luminance component of the colors in the HTML output. Values below
+# 100 gradually make the output lighter, whereas values above 100 make
+# the output darker. The value divided by 100 is the actual gamma applied,
+# so 80 represents a gamma of 0.8, The value 220 represents a gamma of 2.2,
+# and 100 does not change the gamma.
+
+HTML_COLORSTYLE_GAMMA = 80
+
+# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML
+# page will contain the date and time when the page was generated. Setting
+# this to NO can help when comparing the output of multiple runs.
+
+HTML_TIMESTAMP = YES
+
+# If the HTML_ALIGN_MEMBERS tag is set to YES, the members of classes,
+# files or namespaces will be aligned in HTML using tables. If set to
+# NO a bullet list will be used.
+
+HTML_ALIGN_MEMBERS = YES
+
+# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML
+# documentation will contain sections that can be hidden and shown after the
+# page has loaded. For this to work a browser that supports
+# JavaScript and DHTML is required (for instance Mozilla 1.0+, Firefox
+# Netscape 6.0+, Internet explorer 5.0+, Konqueror, or Safari).
+
+HTML_DYNAMIC_SECTIONS = YES
+
+# If the GENERATE_DOCSET tag is set to YES, additional index files
+# will be generated that can be used as input for Apple's Xcode 3
+# integrated development environment, introduced with OSX 10.5 (Leopard).
+# To create a documentation set, doxygen will generate a Makefile in the
+# HTML output directory. Running make will produce the docset in that
+# directory and running "make install" will install the docset in
+# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find
+# it at startup.
+# See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html
+# for more information.
+
+GENERATE_DOCSET = NO
+
+# When GENERATE_DOCSET tag is set to YES, this tag determines the name of the
+# feed. A documentation feed provides an umbrella under which multiple
+# documentation sets from a single provider (such as a company or product suite)
+# can be grouped.
+
+DOCSET_FEEDNAME = "Doxygen generated docs"
+
+# When GENERATE_DOCSET tag is set to YES, this tag specifies a string that
+# should uniquely identify the documentation set bundle. This should be a
+# reverse domain-name style string, e.g. com.mycompany.MyDocSet. Doxygen
+# will append .docset to the name.
+
+DOCSET_BUNDLE_ID = org.doxygen.Project
+
+# When GENERATE_PUBLISHER_ID tag specifies a string that should uniquely identify
+# the documentation publisher. This should be a reverse domain-name style
+# string, e.g. com.mycompany.MyDocSet.documentation.
+
+DOCSET_PUBLISHER_ID = org.doxygen.Publisher
+
+# The GENERATE_PUBLISHER_NAME tag identifies the documentation publisher.
+
+DOCSET_PUBLISHER_NAME = Publisher
+
+# If the GENERATE_HTMLHELP tag is set to YES, additional index files
+# will be generated that can be used as input for tools like the
+# Microsoft HTML help workshop to generate a compiled HTML help file (.chm)
+# of the generated HTML documentation.
+
+GENERATE_HTMLHELP = NO
+
+# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can
+# be used to specify the file name of the resulting .chm file. You
+# can add a path in front of the file if the result should not be
+# written to the html output directory.
+
+CHM_FILE =
+
+# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can
+# be used to specify the location (absolute path including file name) of
+# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run
+# the HTML help compiler on the generated index.hhp.
+
+HHC_LOCATION =
+
+# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag
+# controls if a separate .chi index file is generated (YES) or that
+# it should be included in the master .chm file (NO).
+
+GENERATE_CHI = NO
+
+# If the GENERATE_HTMLHELP tag is set to YES, the CHM_INDEX_ENCODING
+# is used to encode HtmlHelp index (hhk), content (hhc) and project file
+# content.
+
+CHM_INDEX_ENCODING =
+
+# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag
+# controls whether a binary table of contents is generated (YES) or a
+# normal table of contents (NO) in the .chm file.
+
+BINARY_TOC = NO
+
+# The TOC_EXPAND flag can be set to YES to add extra items for group members
+# to the contents of the HTML help documentation and to the tree view.
+
+TOC_EXPAND = NO
+
+# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and
+# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated
+# that can be used as input for Qt's qhelpgenerator to generate a
+# Qt Compressed Help (.qch) of the generated HTML documentation.
+
+GENERATE_QHP = NO
+
+# If the QHG_LOCATION tag is specified, the QCH_FILE tag can
+# be used to specify the file name of the resulting .qch file.
+# The path specified is relative to the HTML output folder.
+
+QCH_FILE =
+
+# The QHP_NAMESPACE tag specifies the namespace to use when generating
+# Qt Help Project output. For more information please see
+# http://doc.trolltech.com/qthelpproject.html#namespace
+
+QHP_NAMESPACE = org.doxygen.Project
+
+# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating
+# Qt Help Project output. For more information please see
+# http://doc.trolltech.com/qthelpproject.html#virtual-folders
+
+QHP_VIRTUAL_FOLDER = doc
+
+# If QHP_CUST_FILTER_NAME is set, it specifies the name of a custom filter to
+# add. For more information please see
+# http://doc.trolltech.com/qthelpproject.html#custom-filters
+
+QHP_CUST_FILTER_NAME =
+
+# The QHP_CUST_FILT_ATTRS tag specifies the list of the attributes of the
+# custom filter to add. For more information please see
+#
+# Qt Help Project / Custom Filters .
+
+QHP_CUST_FILTER_ATTRS =
+
+# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this
+# project's
+# filter section matches.
+#
+# Qt Help Project / Filter Attributes .
+
+QHP_SECT_FILTER_ATTRS =
+
+# If the GENERATE_QHP tag is set to YES, the QHG_LOCATION tag can
+# be used to specify the location of Qt's qhelpgenerator.
+# If non-empty doxygen will try to run qhelpgenerator on the generated
+# .qhp file.
+
+QHG_LOCATION =
+
+# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files
+# will be generated, which together with the HTML files, form an Eclipse help
+# plugin. To install this plugin and make it available under the help contents
+# menu in Eclipse, the contents of the directory containing the HTML and XML
+# files needs to be copied into the plugins directory of eclipse. The name of
+# the directory within the plugins directory should be the same as
+# the ECLIPSE_DOC_ID value. After copying Eclipse needs to be restarted before
+# the help appears.
+
+GENERATE_ECLIPSEHELP = NO
+
+# A unique identifier for the eclipse help plugin. When installing the plugin
+# the directory name containing the HTML and XML files should also have
+# this name.
+
+ECLIPSE_DOC_ID = org.doxygen.Project
+
+# The DISABLE_INDEX tag can be used to turn on/off the condensed index at
+# top of each HTML page. The value NO (the default) enables the index and
+# the value YES disables it.
+
+DISABLE_INDEX = NO
+
+# This tag can be used to set the number of enum values (range [1..20])
+# that doxygen will group on one line in the generated HTML documentation.
+
+ENUM_VALUES_PER_LINE = 4
+
+# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index
+# structure should be generated to display hierarchical information.
+# If the tag value is set to YES, a side panel will be generated
+# containing a tree-like index structure (just like the one that
+# is generated for HTML Help). For this to work a browser that supports
+# JavaScript, DHTML, CSS and frames is required (i.e. any modern browser).
+# Windows users are probably better off using the HTML help feature.
+
+GENERATE_TREEVIEW = YES
+
+# By enabling USE_INLINE_TREES, doxygen will generate the Groups, Directories,
+# and Class Hierarchy pages using a tree view instead of an ordered list.
+
+USE_INLINE_TREES = YES
+
+# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be
+# used to set the initial width (in pixels) of the frame in which the tree
+# is shown.
+
+TREEVIEW_WIDTH = 250
+
+# When the EXT_LINKS_IN_WINDOW option is set to YES doxygen will open
+# links to external symbols imported via tag files in a separate window.
+
+EXT_LINKS_IN_WINDOW = NO
+
+# Use this tag to change the font size of Latex formulas included
+# as images in the HTML documentation. The default is 10. Note that
+# when you change the font size after a successful doxygen run you need
+# to manually remove any form_*.png images from the HTML output directory
+# to force them to be regenerated.
+
+FORMULA_FONTSIZE = 10
+
+# Use the FORMULA_TRANPARENT tag to determine whether or not the images
+# generated for formulas are transparent PNGs. Transparent PNGs are
+# not supported properly for IE 6.0, but are supported on all modern browsers.
+# Note that when changing this option you need to delete any form_*.png files
+# in the HTML output before the changes have effect.
+
+FORMULA_TRANSPARENT = YES
+
+# When the SEARCHENGINE tag is enabled doxygen will generate a search box
+# for the HTML output. The underlying search engine uses javascript
+# and DHTML and should work on any modern browser. Note that when using
+# HTML help (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets
+# (GENERATE_DOCSET) there is already a search function so this one should
+# typically be disabled. For large projects the javascript based search engine
+# can be slow, then enabling SERVER_BASED_SEARCH may provide a better solution.
+
+SEARCHENGINE = YES
+
+# When the SERVER_BASED_SEARCH tag is enabled the search engine will be
+# implemented using a PHP enabled web server instead of at the web client
+# using Javascript. Doxygen will generate the search PHP script and index
+# file to put on the web server. The advantage of the server
+# based approach is that it scales better to large projects and allows
+# full text search. The disadvances is that it is more difficult to setup
+# and does not have live searching capabilities.
+
+SERVER_BASED_SEARCH = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the LaTeX output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will
+# generate Latex output.
+
+GENERATE_LATEX = NO
+
+# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `latex' will be used as the default path.
+
+LATEX_OUTPUT = latex
+
+# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be
+# invoked. If left blank `latex' will be used as the default command name.
+# Note that when enabling USE_PDFLATEX this option is only used for
+# generating bitmaps for formulas in the HTML output, but not in the
+# Makefile that is written to the output directory.
+
+LATEX_CMD_NAME = latex
+
+# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to
+# generate index for LaTeX. If left blank `makeindex' will be used as the
+# default command name.
+
+MAKEINDEX_CMD_NAME = makeindex
+
+# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact
+# LaTeX documents. This may be useful for small projects and may help to
+# save some trees in general.
+
+COMPACT_LATEX = NO
+
+# The PAPER_TYPE tag can be used to set the paper type that is used
+# by the printer. Possible values are: a4, a4wide, letter, legal and
+# executive. If left blank a4wide will be used.
+
+PAPER_TYPE = a4wide
+
+# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX
+# packages that should be included in the LaTeX output.
+
+EXTRA_PACKAGES =
+
+# The LATEX_HEADER tag can be used to specify a personal LaTeX header for
+# the generated latex document. The header should contain everything until
+# the first chapter. If it is left blank doxygen will generate a
+# standard header. Notice: only use this tag if you know what you are doing!
+
+LATEX_HEADER =
+
+# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated
+# is prepared for conversion to pdf (using ps2pdf). The pdf file will
+# contain links (just like the HTML output) instead of page references
+# This makes the output suitable for online browsing using a pdf viewer.
+
+PDF_HYPERLINKS = YES
+
+# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of
+# plain latex in the generated Makefile. Set this option to YES to get a
+# higher quality PDF documentation.
+
+USE_PDFLATEX = YES
+
+# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode.
+# command to the generated LaTeX files. This will instruct LaTeX to keep
+# running if errors occur, instead of asking the user for help.
+# This option is also used when generating formulas in HTML.
+
+LATEX_BATCHMODE = NO
+
+# If LATEX_HIDE_INDICES is set to YES then doxygen will not
+# include the index chapters (such as File Index, Compound Index, etc.)
+# in the output.
+
+LATEX_HIDE_INDICES = NO
+
+# If LATEX_SOURCE_CODE is set to YES then doxygen will include
+# source code with syntax highlighting in the LaTeX output.
+# Note that which sources are shown also depends on other settings
+# such as SOURCE_BROWSER.
+
+LATEX_SOURCE_CODE = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the RTF output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output
+# The RTF output is optimized for Word 97 and may not look very pretty with
+# other RTF readers or editors.
+
+GENERATE_RTF = NO
+
+# The RTF_OUTPUT tag is used to specify where the RTF docs will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `rtf' will be used as the default path.
+
+RTF_OUTPUT = rtf
+
+# If the COMPACT_RTF tag is set to YES Doxygen generates more compact
+# RTF documents. This may be useful for small projects and may help to
+# save some trees in general.
+
+COMPACT_RTF = NO
+
+# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated
+# will contain hyperlink fields. The RTF file will
+# contain links (just like the HTML output) instead of page references.
+# This makes the output suitable for online browsing using WORD or other
+# programs which support those fields.
+# Note: wordpad (write) and others do not support links.
+
+RTF_HYPERLINKS = NO
+
+# Load stylesheet definitions from file. Syntax is similar to doxygen's
+# config file, i.e. a series of assignments. You only have to provide
+# replacements, missing definitions are set to their default value.
+
+RTF_STYLESHEET_FILE =
+
+# Set optional variables used in the generation of an rtf document.
+# Syntax is similar to doxygen's config file.
+
+RTF_EXTENSIONS_FILE =
+
+#---------------------------------------------------------------------------
+# configuration options related to the man page output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_MAN tag is set to YES (the default) Doxygen will
+# generate man pages
+
+GENERATE_MAN = NO
+
+# The MAN_OUTPUT tag is used to specify where the man pages will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `man' will be used as the default path.
+
+MAN_OUTPUT = man
+
+# The MAN_EXTENSION tag determines the extension that is added to
+# the generated man pages (default is the subroutine's section .3)
+
+MAN_EXTENSION = .3
+
+# If the MAN_LINKS tag is set to YES and Doxygen generates man output,
+# then it will generate one additional man file for each entity
+# documented in the real man page(s). These additional files
+# only source the real man page, but without them the man command
+# would be unable to find the correct page. The default is NO.
+
+MAN_LINKS = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the XML output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_XML tag is set to YES Doxygen will
+# generate an XML file that captures the structure of
+# the code including all documentation.
+
+GENERATE_XML = NO
+
+# The XML_OUTPUT tag is used to specify where the XML pages will be put.
+# If a relative path is entered the value of OUTPUT_DIRECTORY will be
+# put in front of it. If left blank `xml' will be used as the default path.
+
+XML_OUTPUT = xml
+
+# The XML_SCHEMA tag can be used to specify an XML schema,
+# which can be used by a validating XML parser to check the
+# syntax of the XML files.
+
+XML_SCHEMA =
+
+# The XML_DTD tag can be used to specify an XML DTD,
+# which can be used by a validating XML parser to check the
+# syntax of the XML files.
+
+XML_DTD =
+
+# If the XML_PROGRAMLISTING tag is set to YES Doxygen will
+# dump the program listings (including syntax highlighting
+# and cross-referencing information) to the XML output. Note that
+# enabling this will significantly increase the size of the XML output.
+
+XML_PROGRAMLISTING = YES
+
+#---------------------------------------------------------------------------
+# configuration options for the AutoGen Definitions output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will
+# generate an AutoGen Definitions (see autogen.sf.net) file
+# that captures the structure of the code including all
+# documentation. Note that this feature is still experimental
+# and incomplete at the moment.
+
+GENERATE_AUTOGEN_DEF = NO
+
+#---------------------------------------------------------------------------
+# configuration options related to the Perl module output
+#---------------------------------------------------------------------------
+
+# If the GENERATE_PERLMOD tag is set to YES Doxygen will
+# generate a Perl module file that captures the structure of
+# the code including all documentation. Note that this
+# feature is still experimental and incomplete at the
+# moment.
+
+GENERATE_PERLMOD = NO
+
+# If the PERLMOD_LATEX tag is set to YES Doxygen will generate
+# the necessary Makefile rules, Perl scripts and LaTeX code to be able
+# to generate PDF and DVI output from the Perl module output.
+
+PERLMOD_LATEX = NO
+
+# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be
+# nicely formatted so it can be parsed by a human reader. This is useful
+# if you want to understand what is going on. On the other hand, if this
+# tag is set to NO the size of the Perl module output will be much smaller
+# and Perl will parse it just the same.
+
+PERLMOD_PRETTY = YES
+
+# The names of the make variables in the generated doxyrules.make file
+# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX.
+# This is useful so different doxyrules.make files included by the same
+# Makefile don't overwrite each other's variables.
+
+PERLMOD_MAKEVAR_PREFIX =
+
+#---------------------------------------------------------------------------
+# Configuration options related to the preprocessor
+#---------------------------------------------------------------------------
+
+# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will
+# evaluate all C-preprocessor directives found in the sources and include
+# files.
+
+ENABLE_PREPROCESSING = YES
+
+# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro
+# names in the source code. If set to NO (the default) only conditional
+# compilation will be performed. Macro expansion can be done in a controlled
+# way by setting EXPAND_ONLY_PREDEF to YES.
+
+MACRO_EXPANSION = NO
+
+# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES
+# then the macro expansion is limited to the macros specified with the
+# PREDEFINED and EXPAND_AS_DEFINED tags.
+
+EXPAND_ONLY_PREDEF = NO
+
+# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files
+# in the INCLUDE_PATH (see below) will be search if a #include is found.
+
+SEARCH_INCLUDES = YES
+
+# The INCLUDE_PATH tag can be used to specify one or more directories that
+# contain include files that are not input files but should be processed by
+# the preprocessor.
+
+INCLUDE_PATH =
+
+# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard
+# patterns (like *.h and *.hpp) to filter out the header-files in the
+# directories. If left blank, the patterns specified with FILE_PATTERNS will
+# be used.
+
+INCLUDE_FILE_PATTERNS =
+
+# The PREDEFINED tag can be used to specify one or more macro names that
+# are defined before the preprocessor is started (similar to the -D option of
+# gcc). The argument of the tag is a list of macros of the form: name
+# or name=definition (no spaces). If the definition and the = are
+# omitted =1 is assumed. To prevent a macro definition from being
+# undefined via #undef or recursively expanded use the := operator
+# instead of the = operator.
+
+PREDEFINED =
+
+# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then
+# this tag can be used to specify a list of macro names that should be expanded.
+# The macro definition that is found in the sources will be used.
+# Use the PREDEFINED tag if you want to use a different macro definition.
+
+EXPAND_AS_DEFINED =
+
+# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then
+# doxygen's preprocessor will remove all function-like macros that are alone
+# on a line, have an all uppercase name, and do not end with a semicolon. Such
+# function macros are typically used for boiler-plate code, and will confuse
+# the parser if not removed.
+
+SKIP_FUNCTION_MACROS = YES
+
+#---------------------------------------------------------------------------
+# Configuration::additions related to external references
+#---------------------------------------------------------------------------
+
+# The TAGFILES option can be used to specify one or more tagfiles.
+# Optionally an initial location of the external documentation
+# can be added for each tagfile. The format of a tag file without
+# this location is as follows:
+# TAGFILES = file1 file2 ...
+# Adding location for the tag files is done as follows:
+# TAGFILES = file1=loc1 "file2 = loc2" ...
+# where "loc1" and "loc2" can be relative or absolute paths or
+# URLs. If a location is present for each tag, the installdox tool
+# does not have to be run to correct the links.
+# Note that each tag file must have a unique name
+# (where the name does NOT include the path)
+# If a tag file is not located in the directory in which doxygen
+# is run, you must also specify the path to the tagfile here.
+
+TAGFILES =
+
+# When a file name is specified after GENERATE_TAGFILE, doxygen will create
+# a tag file that is based on the input files it reads.
+
+GENERATE_TAGFILE =
+
+# If the ALLEXTERNALS tag is set to YES all external classes will be listed
+# in the class index. If set to NO only the inherited external classes
+# will be listed.
+
+ALLEXTERNALS = NO
+
+# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed
+# in the modules index. If set to NO, only the current project's groups will
+# be listed.
+
+EXTERNAL_GROUPS = YES
+
+# The PERL_PATH should be the absolute path and name of the perl script
+# interpreter (i.e. the result of `which perl').
+
+PERL_PATH = /usr/bin/perl
+
+#---------------------------------------------------------------------------
+# Configuration options related to the dot tool
+#---------------------------------------------------------------------------
+
+# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will
+# generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base
+# or super classes. Setting the tag to NO turns the diagrams off. Note that
+# this option is superseded by the HAVE_DOT option below. This is only a
+# fallback. It is recommended to install and use dot, since it yields more
+# powerful graphs.
+
+CLASS_DIAGRAMS = NO
+
+# You can define message sequence charts within doxygen comments using the \msc
+# command. Doxygen will then run the mscgen tool (see
+# http://www.mcternan.me.uk/mscgen/) to produce the chart and insert it in the
+# documentation. The MSCGEN_PATH tag allows you to specify the directory where
+# the mscgen tool resides. If left empty the tool is assumed to be found in the
+# default search path.
+
+MSCGEN_PATH =
+
+# If set to YES, the inheritance and collaboration graphs will hide
+# inheritance and usage relations if the target is undocumented
+# or is not a class.
+
+HIDE_UNDOC_RELATIONS = YES
+
+# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is
+# available from the path. This tool is part of Graphviz, a graph visualization
+# toolkit from AT&T and Lucent Bell Labs. The other options in this section
+# have no effect if this option is set to NO (the default)
+
+HAVE_DOT = YES
+
+# The DOT_NUM_THREADS specifies the number of dot invocations doxygen is
+# allowed to run in parallel. When set to 0 (the default) doxygen will
+# base this on the number of processors available in the system. You can set it
+# explicitly to a value larger than 0 to get control over the balance
+# between CPU load and processing speed.
+
+DOT_NUM_THREADS = 0
+
+# By default doxygen will write a font called FreeSans.ttf to the output
+# directory and reference it in all dot files that doxygen generates. This
+# font does not include all possible unicode characters however, so when you need
+# these (or just want a differently looking font) you can specify the font name
+# using DOT_FONTNAME. You need need to make sure dot is able to find the font,
+# which can be done by putting it in a standard location or by setting the
+# DOTFONTPATH environment variable or by setting DOT_FONTPATH to the directory
+# containing the font.
+
+DOT_FONTNAME = FreeSans.ttf
+
+# The DOT_FONTSIZE tag can be used to set the size of the font of dot graphs.
+# The default size is 10pt.
+
+DOT_FONTSIZE = 10
+
+# By default doxygen will tell dot to use the output directory to look for the
+# FreeSans.ttf font (which doxygen will put there itself). If you specify a
+# different font using DOT_FONTNAME you can set the path where dot
+# can find it using this tag.
+
+DOT_FONTPATH =
+
+# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen
+# will generate a graph for each documented class showing the direct and
+# indirect inheritance relations. Setting this tag to YES will force the
+# the CLASS_DIAGRAMS tag to NO.
+
+CLASS_GRAPH = YES
+
+# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen
+# will generate a graph for each documented class showing the direct and
+# indirect implementation dependencies (inheritance, containment, and
+# class references variables) of the class with other documented classes.
+
+COLLABORATION_GRAPH = YES
+
+# If the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen
+# will generate a graph for groups, showing the direct groups dependencies
+
+GROUP_GRAPHS = YES
+
+# If the UML_LOOK tag is set to YES doxygen will generate inheritance and
+# collaboration diagrams in a style similar to the OMG's Unified Modeling
+# Language.
+
+UML_LOOK = YES
+
+# If set to YES, the inheritance and collaboration graphs will show the
+# relations between templates and their instances.
+
+TEMPLATE_RELATIONS = YES
+
+# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT
+# tags are set to YES then doxygen will generate a graph for each documented
+# file showing the direct and indirect include dependencies of the file with
+# other documented files.
+
+INCLUDE_GRAPH = YES
+
+# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and
+# HAVE_DOT tags are set to YES then doxygen will generate a graph for each
+# documented header file showing the documented files that directly or
+# indirectly include this file.
+
+INCLUDED_BY_GRAPH = YES
+
+# If the CALL_GRAPH and HAVE_DOT options are set to YES then
+# doxygen will generate a call dependency graph for every global function
+# or class method. Note that enabling this option will significantly increase
+# the time of a run. So in most cases it will be better to enable call graphs
+# for selected functions only using the \callgraph command.
+
+CALL_GRAPH = YES
+
+# If the CALLER_GRAPH and HAVE_DOT tags are set to YES then
+# doxygen will generate a caller dependency graph for every global function
+# or class method. Note that enabling this option will significantly increase
+# the time of a run. So in most cases it will be better to enable caller
+# graphs for selected functions only using the \callergraph command.
+
+CALLER_GRAPH = YES
+
+# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen
+# will graphical hierarchy of all classes instead of a textual one.
+
+GRAPHICAL_HIERARCHY = YES
+
+# If the DIRECTORY_GRAPH, SHOW_DIRECTORIES and HAVE_DOT tags are set to YES
+# then doxygen will show the dependencies a directory has on other directories
+# in a graphical way. The dependency relations are determined by the #include
+# relations between the files in the directories.
+
+DIRECTORY_GRAPH = YES
+
+# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images
+# generated by dot. Possible values are png, jpg, or gif
+# If left blank png will be used.
+
+DOT_IMAGE_FORMAT = png
+
+# The tag DOT_PATH can be used to specify the path where the dot tool can be
+# found. If left blank, it is assumed the dot tool can be found in the path.
+
+DOT_PATH =
+
+# The DOTFILE_DIRS tag can be used to specify one or more directories that
+# contain dot files that are included in the documentation (see the
+# \dotfile command).
+
+DOTFILE_DIRS =
+
+# The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of
+# nodes that will be shown in the graph. If the number of nodes in a graph
+# becomes larger than this value, doxygen will truncate the graph, which is
+# visualized by representing a node as a red box. Note that doxygen if the
+# number of direct children of the root node in a graph is already larger than
+# DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note
+# that the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH.
+
+DOT_GRAPH_MAX_NODES = 50
+
+# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the
+# graphs generated by dot. A depth value of 3 means that only nodes reachable
+# from the root by following a path via at most 3 edges will be shown. Nodes
+# that lay further from the root node will be omitted. Note that setting this
+# option to 1 or 2 may greatly reduce the computation time needed for large
+# code bases. Also note that the size of a graph can be further restricted by
+# DOT_GRAPH_MAX_NODES. Using a depth of 0 means no depth restriction.
+
+MAX_DOT_GRAPH_DEPTH = 0
+
+# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent
+# background. This is disabled by default, because dot on Windows does not
+# seem to support this out of the box. Warning: Depending on the platform used,
+# enabling this option may lead to badly anti-aliased labels on the edges of
+# a graph (i.e. they become hard to read).
+
+DOT_TRANSPARENT = NO
+
+# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output
+# files in one run (i.e. multiple -o and -T options on the command line). This
+# makes dot run faster, but since only newer versions of dot (>1.8.10)
+# support this, this feature is disabled by default.
+
+DOT_MULTI_TARGETS = YES
+
+# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will
+# generate a legend page explaining the meaning of the various boxes and
+# arrows in the dot generated graphs.
+
+GENERATE_LEGEND = YES
+
+# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will
+# remove the intermediate dot files that are used to generate
+# the various graphs.
+
+DOT_CLEANUP = YES
diff --git a/doc/Rapport post-doc/1-introduction.tex b/doc/Rapport post-doc/1-introduction.tex
new file mode 100644
index 0000000..e3c17c6
--- /dev/null
+++ b/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
diff --git a/doc/Rapport post-doc/2-motivation.tex b/doc/Rapport post-doc/2-motivation.tex
new file mode 100644
index 0000000..4076a40
--- /dev/null
+++ b/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
diff --git a/doc/Rapport post-doc/2-sota.tex b/doc/Rapport post-doc/2-sota.tex
new file mode 100644
index 0000000..ce31331
--- /dev/null
+++ b/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}.
diff --git a/doc/Rapport post-doc/3-imbsa.tex b/doc/Rapport post-doc/3-imbsa.tex
new file mode 100644
index 0000000..505368a
--- /dev/null
+++ b/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 ()="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
diff --git a/doc/Rapport post-doc/4-aocs.tex b/doc/Rapport post-doc/4-aocs.tex
new file mode 100644
index 0000000..f3c0b3b
--- /dev/null
+++ b/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:
diff --git a/doc/Rapport post-doc/5-conclusions.tex b/doc/Rapport post-doc/5-conclusions.tex
new file mode 100644
index 0000000..37a00ed
--- /dev/null
+++ b/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:
diff --git a/doc/Rapport post-doc/IMBSA-paper.tex b/doc/Rapport post-doc/IMBSA-paper.tex
new file mode 100644
index 0000000..3d625ee
--- /dev/null
+++ b/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}
+
+
diff --git a/doc/Rapport post-doc/algos/function.fcr b/doc/Rapport post-doc/algos/function.fcr
new file mode 100644
index 0000000..46e78ec
--- /dev/null
+++ b/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
\ No newline at end of file
diff --git a/doc/Rapport post-doc/algos/function2.alt b/doc/Rapport post-doc/algos/function2.alt
new file mode 100644
index 0000000..6cf43fb
--- /dev/null
+++ b/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
\ No newline at end of file
diff --git a/doc/Rapport post-doc/algos/function2.fcr b/doc/Rapport post-doc/algos/function2.fcr
new file mode 100644
index 0000000..d3f5a12
--- /dev/null
+++ b/doc/Rapport post-doc/algos/function2.fcr
@@ -0,0 +1 @@
+
diff --git a/doc/Rapport post-doc/algos/pre.alt b/doc/Rapport post-doc/algos/pre.alt
new file mode 100644
index 0000000..f326cb1
--- /dev/null
+++ b/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
diff --git a/doc/Rapport post-doc/algos/pre.fcr b/doc/Rapport post-doc/algos/pre.fcr
new file mode 100644
index 0000000..7f9c38a
--- /dev/null
+++ b/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
\ No newline at end of file
diff --git a/doc/Rapport post-doc/algos/pre2.fcr b/doc/Rapport post-doc/algos/pre2.fcr
new file mode 100644
index 0000000..5a9a072
--- /dev/null
+++ b/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
\ No newline at end of file
diff --git a/doc/Rapport post-doc/aliascnt.sty b/doc/Rapport post-doc/aliascnt.sty
new file mode 100644
index 0000000..452aa0e
--- /dev/null
+++ b/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
+%%
+%% 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'.
diff --git a/doc/Rapport post-doc/altarica-diagrams.tex b/doc/Rapport post-doc/altarica-diagrams.tex
new file mode 100644
index 0000000..093dd5b
--- /dev/null
+++ b/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:
diff --git a/doc/Rapport post-doc/altarica-function.tex b/doc/Rapport post-doc/altarica-function.tex
new file mode 100644
index 0000000..fa38db7
--- /dev/null
+++ b/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}
diff --git a/doc/Rapport post-doc/app.tex b/doc/Rapport post-doc/app.tex
new file mode 100644
index 0000000..8e496c8
--- /dev/null
+++ b/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 $$ a new state $$, whith $t = (s, e, s')$
+ \item timed transitions $s \xrightarrow{\theta} s'$, associating to a state $$ a new state $$, 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 $$, 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 $$ other pairs $$. % 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 $$)
+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 >
+
+%% LocalWords: TGTS Fiacre Dataflow OCAS ETGTS
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "main"
+%%% End:
diff --git a/doc/Rapport post-doc/dirtytalk.sty b/doc/Rapport post-doc/dirtytalk.sty
new file mode 100644
index 0000000..228c5bd
--- /dev/null
+++ b/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'.
diff --git a/doc/Rapport post-doc/etgts.tex b/doc/Rapport post-doc/etgts.tex
new file mode 100644
index 0000000..8d1a6b6
--- /dev/null
+++ b/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
diff --git a/doc/Rapport post-doc/figures/0- AOCS mode Abstract.png b/doc/Rapport post-doc/figures/0- AOCS mode Abstract.png
new file mode 100644
index 0000000..8e4716d
Binary files /dev/null and b/doc/Rapport post-doc/figures/0- AOCS mode Abstract.png differ
diff --git a/doc/Rapport post-doc/figures/2-2 - AOCS mode automaton.png b/doc/Rapport post-doc/figures/2-2 - AOCS mode automaton.png
new file mode 100644
index 0000000..564e4e8
Binary files /dev/null and b/doc/Rapport post-doc/figures/2-2 - AOCS mode automaton.png differ
diff --git a/doc/Rapport post-doc/figures/2-3 - ASH mode.png b/doc/Rapport post-doc/figures/2-3 - ASH mode.png
new file mode 100644
index 0000000..cf9b35d
Binary files /dev/null and b/doc/Rapport post-doc/figures/2-3 - ASH mode.png differ
diff --git a/doc/Rapport post-doc/figures/2-4 set ON the equipment for ASM mode.png b/doc/Rapport post-doc/figures/2-4 set ON the equipment for ASM mode.png
new file mode 100644
index 0000000..ddc5200
Binary files /dev/null and b/doc/Rapport post-doc/figures/2-4 set ON the equipment for ASM mode.png differ
diff --git a/doc/Rapport post-doc/figures/2-5 ACM automaton.png b/doc/Rapport post-doc/figures/2-5 ACM automaton.png
new file mode 100644
index 0000000..fd62c3b
Binary files /dev/null and b/doc/Rapport post-doc/figures/2-5 ACM automaton.png differ
diff --git a/doc/Rapport post-doc/figures/2-6 set ON the equipment for ACM mode.png b/doc/Rapport post-doc/figures/2-6 set ON the equipment for ACM mode.png
new file mode 100644
index 0000000..106b2e6
Binary files /dev/null and b/doc/Rapport post-doc/figures/2-6 set ON the equipment for ACM mode.png differ
diff --git a/doc/Rapport post-doc/figures/2-7 Collision Avoidance Mode.png b/doc/Rapport post-doc/figures/2-7 Collision Avoidance Mode.png
new file mode 100644
index 0000000..2b6e06d
Binary files /dev/null and b/doc/Rapport post-doc/figures/2-7 Collision Avoidance Mode.png differ
diff --git a/doc/Rapport post-doc/figures/2-8 OCM automaton.png b/doc/Rapport post-doc/figures/2-8 OCM automaton.png
new file mode 100644
index 0000000..d240c1b
Binary files /dev/null and b/doc/Rapport post-doc/figures/2-8 OCM automaton.png differ
diff --git a/doc/Rapport post-doc/figures/2-9 Formation Control Mode.png b/doc/Rapport post-doc/figures/2-9 Formation Control Mode.png
new file mode 100644
index 0000000..d3eb445
Binary files /dev/null and b/doc/Rapport post-doc/figures/2-9 Formation Control Mode.png differ
diff --git a/doc/Rapport post-doc/figures/AOCS mode.png b/doc/Rapport post-doc/figures/AOCS mode.png
new file mode 100644
index 0000000..a5cf782
Binary files /dev/null and b/doc/Rapport post-doc/figures/AOCS mode.png differ
diff --git a/doc/Rapport post-doc/figures/AOCSmode_schema.png b/doc/Rapport post-doc/figures/AOCSmode_schema.png
new file mode 100644
index 0000000..9a5276b
Binary files /dev/null and b/doc/Rapport post-doc/figures/AOCSmode_schema.png differ
diff --git a/doc/Rapport post-doc/figures/AirSpeed_Computation.jpg b/doc/Rapport post-doc/figures/AirSpeed_Computation.jpg
new file mode 100644
index 0000000..5756bbc
Binary files /dev/null and b/doc/Rapport post-doc/figures/AirSpeed_Computation.jpg differ
diff --git a/doc/Rapport post-doc/figures/ERTS - AOCS mode.png b/doc/Rapport post-doc/figures/ERTS - AOCS mode.png
new file mode 100644
index 0000000..a5cf782
Binary files /dev/null and b/doc/Rapport post-doc/figures/ERTS - AOCS mode.png differ
diff --git a/doc/Rapport post-doc/figures/EUTELSAT-172B-SATELLITE.jpg b/doc/Rapport post-doc/figures/EUTELSAT-172B-SATELLITE.jpg
new file mode 100644
index 0000000..e364300
Binary files /dev/null and b/doc/Rapport post-doc/figures/EUTELSAT-172B-SATELLITE.jpg differ
diff --git a/doc/Rapport post-doc/figures/Equipment Mode.png b/doc/Rapport post-doc/figures/Equipment Mode.png
new file mode 100644
index 0000000..99f4c8f
Binary files /dev/null and b/doc/Rapport post-doc/figures/Equipment Mode.png differ
diff --git a/doc/Rapport post-doc/figures/Function2_1.pdf b/doc/Rapport post-doc/figures/Function2_1.pdf
new file mode 100644
index 0000000..12d13bf
Binary files /dev/null and b/doc/Rapport post-doc/figures/Function2_1.pdf differ
diff --git a/doc/Rapport post-doc/figures/Function2_1.png b/doc/Rapport post-doc/figures/Function2_1.png
new file mode 100644
index 0000000..bc9e975
Binary files /dev/null and b/doc/Rapport post-doc/figures/Function2_1.png differ
diff --git a/doc/Rapport post-doc/figures/Function2_1.svg b/doc/Rapport post-doc/figures/Function2_1.svg
new file mode 100644
index 0000000..d11ed01
--- /dev/null
+++ b/doc/Rapport post-doc/figures/Function2_1.svg
@@ -0,0 +1,271 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ image/svg+xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ I1
+ I2
+ O
+
+
+
+
+
diff --git a/doc/Rapport post-doc/figures/Function2_1.tex b/doc/Rapport post-doc/figures/Function2_1.tex
new file mode 100644
index 0000000..f61c39a
--- /dev/null
+++ b/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}
diff --git a/doc/Rapport post-doc/figures/Function2_2.pdf b/doc/Rapport post-doc/figures/Function2_2.pdf
new file mode 100644
index 0000000..38888d3
Binary files /dev/null and b/doc/Rapport post-doc/figures/Function2_2.pdf differ
diff --git a/doc/Rapport post-doc/figures/Function2_2.png b/doc/Rapport post-doc/figures/Function2_2.png
new file mode 100644
index 0000000..3513174
Binary files /dev/null and b/doc/Rapport post-doc/figures/Function2_2.png differ
diff --git a/doc/Rapport post-doc/figures/Function2_2.svg b/doc/Rapport post-doc/figures/Function2_2.svg
new file mode 100644
index 0000000..9241d32
--- /dev/null
+++ b/doc/Rapport post-doc/figures/Function2_2.svg
@@ -0,0 +1,276 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ image/svg+xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ nominal
+ lost
+ erroneous
+
+
+
+
+
diff --git a/doc/Rapport post-doc/figures/Gnc mode simplifie.png b/doc/Rapport post-doc/figures/Gnc mode simplifie.png
new file mode 100644
index 0000000..e936bfd
Binary files /dev/null and b/doc/Rapport post-doc/figures/Gnc mode simplifie.png differ
diff --git a/doc/Rapport post-doc/figures/Modele0.png b/doc/Rapport post-doc/figures/Modele0.png
new file mode 100644
index 0000000..a6f09f5
Binary files /dev/null and b/doc/Rapport post-doc/figures/Modele0.png differ
diff --git a/doc/Rapport post-doc/figures/Modele0F4.png b/doc/Rapport post-doc/figures/Modele0F4.png
new file mode 100644
index 0000000..3940f2a
Binary files /dev/null and b/doc/Rapport post-doc/figures/Modele0F4.png differ
diff --git a/doc/Rapport post-doc/figures/Modele1.png b/doc/Rapport post-doc/figures/Modele1.png
new file mode 100644
index 0000000..aedcab4
Binary files /dev/null and b/doc/Rapport post-doc/figures/Modele1.png differ
diff --git a/doc/Rapport post-doc/figures/Modele2.png b/doc/Rapport post-doc/figures/Modele2.png
new file mode 100644
index 0000000..480e219
Binary files /dev/null and b/doc/Rapport post-doc/figures/Modele2.png differ
diff --git a/doc/Rapport post-doc/figures/passerelle.png b/doc/Rapport post-doc/figures/passerelle.png
new file mode 100644
index 0000000..36088d9
Binary files /dev/null and b/doc/Rapport post-doc/figures/passerelle.png differ
diff --git a/doc/Rapport post-doc/figures/satellite_telecom.png b/doc/Rapport post-doc/figures/satellite_telecom.png
new file mode 100644
index 0000000..87cc13d
Binary files /dev/null and b/doc/Rapport post-doc/figures/satellite_telecom.png differ
diff --git a/doc/Rapport post-doc/figures/space_systems_2.jpg b/doc/Rapport post-doc/figures/space_systems_2.jpg
new file mode 100644
index 0000000..9d449dc
Binary files /dev/null and b/doc/Rapport post-doc/figures/space_systems_2.jpg differ
diff --git a/doc/Rapport post-doc/figures/table1.png b/doc/Rapport post-doc/figures/table1.png
new file mode 100644
index 0000000..464a901
Binary files /dev/null and b/doc/Rapport post-doc/figures/table1.png differ
diff --git a/doc/Rapport post-doc/figures/texput.log b/doc/Rapport post-doc/figures/texput.log
new file mode 100644
index 0000000..a6f2950
--- /dev/null
+++ b/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!
diff --git a/doc/Rapport post-doc/llncsdoc.sty b/doc/Rapport post-doc/llncsdoc.sty
new file mode 100644
index 0000000..5843cba
--- /dev/null
+++ b/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}
diff --git a/doc/Rapport post-doc/longabstract.tex b/doc/Rapport post-doc/longabstract.tex
new file mode 100644
index 0000000..1c90873
--- /dev/null
+++ b/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:
diff --git a/doc/Rapport post-doc/lstlang3.sty b/doc/Rapport post-doc/lstlang3.sty
new file mode 100644
index 0000000..e415893
--- /dev/null
+++ b/doc/Rapport post-doc/lstlang3.sty
@@ -0,0 +1,1067 @@
+%%
+%% This is file `lstlang3.sty',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% lstdrvrs.dtx (with options: `lang3')
+%%
+%% (w)(c) 1996/1997/1998/1999/2000/2001/2002/2003/2004 Carsten Heinz
+%% and/or any other author listed elsewhere in this file.
+%%
+%% This file is distributed under the terms of the LaTeX Project Public
+%% License from CTAN archives in directory macros/latex/base/lppl.txt.
+%% Either version 1.0 or, at your option, any later version.
+%%
+%% This file is completely free and comes without any warranty.
+%%
+%% Send comments and ideas on the package, error reports and additional
+%% programming languages to .
+%%
+\ProvidesFile{lstlang3.sty}
+ [2004/02/13 1.2 listings language file]
+
+
+% Lignes vides moins espacées
+\lst@AddToHook{OnEmptyLine}{\vskip -0.5ex}
+%\lst@AddToHook{OnNewLine}{\vskip -0.5ex}
+
+
+
+\lst@definelanguage[68]{Algol}%
+ {morekeywords={abs,and,arg,begin,bin,bits,bool,by,bytes,case,channel,%
+ char,co,comment,compl,conj,divab,do,down,elem,elif,else,empty,%
+ end,entier,eq,esac,exit,false,fi,file,flex,for,format,from,ge,%
+ goto,gt,heap,if,im,in,int,is,isnt,le,leng,level,loc,long,lt,lwb,%
+ minusab,mod,modab,mode,ne,nil,not,od,odd,of,op,or,ouse,out,over,%
+ overab,par,plusab,plusto,pr,pragmat,prio,proc,re,real,ref,repr,%
+ round,sema,shl,short,shorten,shr,sign,skip,string,struct,then,%
+ timesab,to,true,union,up,upb,void,while},%
+ sensitive=f,% ???
+ morecomment=[s]{\#}{\#},%
+ keywordcomment={co,comment}%
+ }[keywords,comments,keywordcomments]%
+\lst@definelanguage[60]{Algol}%
+ {morekeywords={array,begin,Boolean,code,comment,div,do,else,end,%
+ false,for,goto,if,integer,label,own,power,procedure,real,step,%
+ string,switch,then,true,until,value,while},%
+ sensitive=f,% ???
+ keywordcommentsemicolon={end}{else,end}{comment}%
+ }[keywords,keywordcomments]%
+%%
+%% x86masm definition (c) 2002 Andrew Zabolotny
+%%
+\lst@definelanguage[x86masm]{Assembler}%
+ {morekeywords={al,ah,ax,eax,bl,bh,bx,ebx,cl,ch,cx,ecx,dl,dh,dx,edx,%
+ si,esi,di,edi,bp,ebp,sp,esp,cs,ds,es,ss,fs,gs,cr0,cr1,cr2,cr3,%
+ db0,db1,db2,db3,db4,db5,db6,db7,tr0,tr1,tr2,tr3,tr4,tr5,tr6,tr7,%
+ st,aaa,aad,aam,aas,adc,add,and,arpl,bound,bsf,bsr,bswap,bt,btc,%
+ btr,bts,call,cbw,cdq,clc,cld,cli,clts,cmc,cmp,cmps,cmpsb,cmpsw,%
+ cmpsd,cmpxchg,cwd,cwde,daa,das,dec,div,enter,hlt,idiv,imul,in,%
+ inc,ins,int,into,invd,invlpg,iret,ja,jae,jb,jbe,jc,jcxz,jecxz,%
+ je,jg,jge,jl,jle,jna,jnae,jnb,jnbe,jnc,jne,jng,jnge,jnl,jnle,%
+ jno,jnp,jns,jnz,jo,jp,jpe,jpo,js,jz,jmp,lahf,lar,lea,leave,lgdt,%
+ lidt,lldt,lmsw,lock,lods,lodsb,lodsw,lodsd,loop,loopz,loopnz,%
+ loope,loopne,lds,les,lfs,lgs,lss,lsl,ltr,mov,movs,movsb,movsw,%
+ movsd,movsx,movzx,mul,neg,nop,not,or,out,outs,pop,popa,popad,%
+ popf,popfd,push,pusha,pushad,pushf,pushfd,rcl,rcr,rep,repe,%
+ repne,repz,repnz,ret,retf,rol,ror,sahf,sal,sar,sbb,scas,seta,%
+ setae,setb,setbe,setc,sete,setg,setge,setl,setle,setna,setnae,%
+ setnb,setnbe,setnc,setne,setng,setnge,setnl,setnle,setno,setnp,%
+ setns,setnz,seto,setp,setpe,setpo,sets,setz,sgdt,shl,shld,shr,%
+ shrd,sidt,sldt,smsw,stc,std,sti,stos,stosb,stosw,stosd,str,sub,%
+ test,verr,verw,wait,wbinvd,xadd,xchg,xlatb,xor,fabs,fadd,fbld,%
+ fbstp,fchs,fclex,fcom,fcos,fdecstp,fdiv,fdivr,ffree,fiadd,ficom,%
+ fidiv,fidivr,fild,fimul,fincstp,finit,fist,fisub,fisubr,fld,fld1,%
+ fldl2e,fldl2t,fldlg2,fldln2,fldpi,fldz,fldcw,fldenv,fmul,fnop,%
+ fpatan,fprem,fprem1,fptan,frndint,frstor,fsave,fscale,fsetpm,%
+ fsin,fsincos,fsqrt,fst,fstcw,fstenv,fstsw,fsub,fsubr,ftst,fucom,%
+ fwait,fxam,fxch,fxtract,fyl2x,fyl2xp1,f2xm1},%
+ morekeywords=[2]{.align,.alpha,assume,byte,code,comm,comment,.const,%
+ .cref,.data,.data?,db,dd,df,dosseg,dq,dt,dw,dword,else,end,endif,%
+ endm,endp,ends,eq,equ,.err,.err1,.err2,.errb,.errdef,.errdif,%
+ .erre,.erridn,.errnb,.errndef,.errnz,event,exitm,extrn,far,%
+ .fardata,.fardata?,fword,ge,group,gt,high,if,if1,if2,ifb,ifdef,%
+ ifdif,ife,ifidn,ifnb,ifndef,include,includelib,irp,irpc,label,%
+ .lall,le,length,.lfcond,.list,local,low,lt,macro,mask,mod,.model,%
+ name,ne,near,offset,org,out,page,proc,ptr,public,purge,qword,.%
+ radix,record,rept,.sall,seg,segment,.seq,.sfcond,short,size,%
+ .stack,struc,subttl,tbyte,.tfcond,this,title,type,.type,width,%
+ word,.xall,.xcref,.xlist},%
+ alsoletter=.,alsodigit=?,%
+ sensitive=f,%
+ morestring=[b]",%
+ morestring=[b]',%
+ morecomment=[l];%
+ }[keywords,comments,strings]
+%%
+%% Clean definition (c) 1999 Jos\'e Romildo Malaquias
+%%
+%% Clean 1.3 : some standard functional language: pure, lazy,
+%% polymorphic type system, modules, type classes,
+%% garbage collection, functions as first class citizens
+%%
+\lst@definelanguage{Clean}%
+ {otherkeywords={:,::,=,:==,=:,=>,->,<-,<-:,\{,\},\{|,|\},\#,\#!,|,\&,%
+ [,],!,.,\\\\,;,_},%
+ morekeywords={from,definition,implementation,import,module,system,%
+ case,code,if,in,let,let!,of,where,with,infix,infixl,infixr},%
+ morendkeywords={True,False,Start,Int,Real,Char,Bool,String,World,%
+ File,ProcId},%
+ sensitive,%
+ morecomment=[l]//,% missing comma: Markus Pahlow
+ morecomment=[n]{/*}{*/},%
+ morestring=[b]"%
+ }[keywords,comments,strings]%
+\lst@definelanguage{Comal 80}%
+ {morekeywords={AND,AUTO,CASE,DATA,DEL,DIM,DIV,DO,ELSE,ENDCASE,ENDIF,%
+ ENDPROC,ENDWHILE,EOD,EXEC,FALSE,FOR,GOTO,IF,INPUT,INT,LIST,LOAD,%
+ MOD,NEW,NEXT,NOT,OF,OR,PRINT,PROC,RANDOM,RENUM,REPEAT,RND,RUN,%
+ SAVE,SELECT,STOP,TAB,THEN,TRUE,UNTIL,WHILE,ZONE},%
+ sensitive=f,% ???
+ morecomment=[l]//,%
+ morestring=[d]"%
+ }[keywords,comments,strings]%
+\lst@definelanguage{Elan}%
+ {morekeywords={ABS,AND,BOOL,CAND,CASE,CAT,COLUMNS,CONCR,CONJ,CONST,%
+ COR,DECR,DEFINES,DET,DIV,DOWNTO,ELIF,ELSE,END,ENDIF,ENDOP,%
+ ENDPACKET,ENDPROC,ENDREP,ENDSELECT,FALSE,FI,FILE,FOR,FROM,IF,%
+ INCR,INT,INV,LEAVE,LENGTH,LET,MOD,NOT,OF,OP,OR,OTHERWISE,PACKET,%
+ PROC,REAL,REP,REPEAT,ROW,ROWS,SELECT,SIGN,STRUCT,SUB,TEXT,THEN,%
+ TRANSP,TRUE,TYPE,UNTIL,UPTO,VAR,WHILE,WITH,XOR,%
+ maxint,sign,abs,min,max,random,initializerandom,subtext,code,%
+ replace,text,laenge,pos,compress,change,maxreal,smallreal,floor,%
+ pi,e,ln,log2,log10,sqrt,exp,tan,tand,sin,sind,cos,cosd,arctan,%
+ arctand,int,real,lastconversionok,put,putline,line,page,get,%
+ getline,input,output,sequentialfile,maxlinelaenge,reset,eof,%
+ close,complexzero,complexone,complexi,complex,realpart,imagpart,%
+ dphi,phi,vector,norm,replace,matrix,idn,row,column,sub,%
+ replacerow,replacecolumn,replaceelement,transp,errorsstop,stop},%
+ sensitive,%
+ morestring=[d]"%
+ }[keywords,strings]%
+%%
+%% Erlang definition (c) 2003 Daniel Gazard
+%%
+\lst@definelanguage{erlang}%
+ {morekeywords={abs,after,and,apply,atom,atom_to_list,band,binary,%
+ binary_to_list,binary_to_term,bor,bsl,bsr,bxor,case,catch,%
+ date,div,element,erase,end,exit,export,float,float_to_list,%
+ get,halt,hash,hd,if,info,import,integer,integer_to_list,%
+ length,link,list,list_to_atom,list_to_float,list_to_integer,%
+ list_to_tuple,module,node,nodes,now,of,or,pid,port,ports,%
+ processes,put,receive,reference,register,registered,rem,%
+ round,self,setelement,size,spawn,throw,time,tl,trace,trunc,%
+ tuple,tuple_to_list,unlink,unregister,whereis,error,false,%
+ infinity,nil,ok,true,undefined,when},%
+ otherkeywords={->,!,[,],\{,\},},%
+ morecomment=[l]\%,%
+ morestring=[b]",%
+ morestring=[b]'%
+ }[keywords,comments,strings]%
+\lst@definelanguage{ksh}
+ {morekeywords={alias,awk,cat,echo,else,elif,fi,exec,exit,%
+ for,in,do,done,select,case,esac,while,until,function,%
+ time,export,cd,eval,fc,fg,kill,let,pwd,read,return,rm,%
+ glob,goto,history,if,logout,nice,nohup,onintr,repeat,sed,%
+ set,setenv,shift,source,switch,then,umask,unalias,%
+ unset,wait,@,env,argv,child,home,ignoreeof,noclobber,%
+ noglob,nomatch,path,prompt,shell,status,verbose,print,printf,%
+ sqrt,BEGIN,END},%
+ morecomment=[l]\#,%
+ morestring=[d]",%
+ morestring=[d]',%
+ morestring=[d]`%
+ }[keywords,comments,strings]%
+\lst@definelanguage{Logo}%
+ {morekeywords={and,atan,arctan,both,break,bf,bl,butfirst,butlast,%
+ cbreak, close,co,continue,cos,count,clearscreen,cs,debquit,%
+ describe,diff,difference,ed,edit,either,emptyp,equalp,er,erase,%
+ errpause,errquit,fifp,filefprint,fifty,fileftype,fip,fileprint,%
+ fird,fileread,fity,filetype,fiwd,fileword,f,first,or,fp,fprint,%
+ fput,fty,ftype,full,fullscreen,go,bye,goodbye,gprop,greaterp,%
+ help,if,iff,iffalse,ift,iftrue,nth,item,keyp,llast,lessp,list,%
+ local,lput,make,max,maximum,memberp,memtrace,min,minimum,namep,%
+ not,numberp,oflush,openr,openread,openw,openwrite,op,output,%
+ pause,plist,pots,pow,pprop,pps,pr,print,product,quotient,random,%
+ rc,readchar,rl,readlist,remprop,repcount,repeat,request,rnd,run,%
+ se,sentence,sentencep,setc,setcolor,setipause,setqpause,po,show,%
+ sin,split,splitscreen,sqrt,stop,sum,test,text,textscreen,thing,%
+ to,tone,top,toplevel,type,untrace,wait,word,wordp,yaccdebug,is,%
+ mod,remainder,trace,zerop,back,bk,bto,btouch,fd,forward,fto,%
+ ftouch,getpen,heading,hit,hitoot,ht,hideturtle,loff,lampoff,lon,%
+ lampon,lt,left,lot,lotoot,lto,ltouch,penc,pencolor,pd,pendown,pe,%
+ penerase,penmode,pu,penup,px,penreverse,rt,right,rto,rtouch,%
+ scrunch,seth,setheading,setscrun,setscrunch,setxy,shownp,st,%
+ showturtle,towardsxy,clean,wipeclean,xcor,ycor,tur,turtle,%
+ display,dpy},%
+ sensitive=f% ???
+ }[keywords]%
+%%
+%% MetaPost definition (c) 2003 Uwe Siart
+%%
+\lst@definelanguage{MetaPost}%
+ {morekeywords={abs,addto,ahangle,ahlength,and,angle,arclength,%
+ arctime,background,bbox,bboxmargin,beginfig,begingroup,beveled,%
+ black,blue,bluepart,boolean,bot,boxit,boxjoin,bpath,btex,%
+ buildcycle,butt,cc,ceiling,char,charcode,circleit,circmargin,%
+ clip,cm,color,controls,cosd,curl,currentpen,currentpicture,%
+ cutafter,cutbefore,cutdraw,cuttings,cycle,dashed,dashpattern,%
+ day,dd,decimal,decr,def,defaultdx,defaultdy,defaultfont,%
+ defaultpen,defaultscale,dir,direction,directionpoint,%
+ directiontime,ditto,div,dotlabel,dotlabels,dotprod,down,downto,%
+ draw,drawarrow,drawboxed,drawboxes,drawdblarrow,drawoptions,%
+ drawshadowed,drawunboxed,else,elseif,end,enddef,endfig,endfor,%
+ endgroup,epsilon,etex,evenly,exitif,exitunless,expr,extra,fi,%
+ fill,filldraw,fixpos,fixsize,floor,fontsize,for,forever,%
+ forsuffixes,fullcircle,getmid,green,greenpart,halfcircle,hex,%
+ hide,identity,if,in,incr,infinity,infont,input,interim,%
+ intersectionpoint,intersectiontimes,inverse,joinup,known,label,%
+ labeloffset,labels,left,length,let,lft,linecap,linejoin,llcorner,%
+ llft,loggingall,lrcorner,lrt,makepath,makepen,mark,max,mexp,%
+ mfplain,middlepoint,midpoint,min,mitered,miterlimit,mlog,mod,%
+ month,mp,mpx,mpxbreak,newinternal,normaldeviate,not,nullpicture,%
+ numeric,oct,odd,or,origin,pair,path,pausing,pen,pencircle,%
+ penoffset,pensquare,pic,pickup,picture,point,postcontrol,%
+ precontrol,primarydef,prologues,quartercircle,red,redpart,%
+ reflectedabout,reverse,right,rotated,rotatedaround,round,rounded,%
+ rt,save,scaled,secondarydef,self,setbounds,shifted,shipout,show,%
+ showdependencies,showstopping,showtoken,showvariable,sind,%
+ slanted,special,sqrt,squared,step,str,string,subpath,substring,%
+ tertiarydef,text,thelabel,time,top,tracingall,tracingcapsules,%
+ tracingchoices,tracingcommands,tracingequations,tracinglostchars,%
+ tracingmacros,tracingnone,tracingonline,tracingoutput,%
+ tracingrestores,tracingspecs,tracingstats,tracingtitles,%
+ transform,transformed,true,truecorners,ulcorner,ulft,undraw,%
+ unfill,unfilldraw,uniformdeviate,unitsquare,unitvector,unknown,%
+ until,up,upto,urcorner,urt,vardef,verbatimtex,whatever,white,%
+ withcolor,withdots,withpen,xpart,xscaled,xxpart,xypart,year,%
+ yscaled,yxpart,yypart,zscaled},%
+ sensitive,%
+ alsoother={0123456789$},%
+ morecomment=[l]\%,%
+ morestring=[s]"%
+ }[keywords,comments,strings]%
+%%
+%% Mizar definition (c) 2003 Adam Grabowski
+%%
+%% Mizar is freely available at URL www.mizar.org for the Linux x86,
+%% Solaris x86, and Windows operating systems.
+%%
+\lst@definelanguage{Mizar}%
+ {otherkeywords={->,(\#,\#),.=),\&},%
+ morekeywords={vocabulary,constructors,$1,$1,$2,$3,$4,$5,$6,$7,$8,%
+ @proof,according,aggregate,and,antonym,as,associativity,assume,%
+ asymmetry,attr,be,begin,being,by,canceled,case,cases,cluster,%
+ clusters,coherence,commutativity,compatibility,connectedness,%
+ consider,consistency,constructors,contradiction,correctness,def,%
+ deffunc,define,definition,definitions,defpred,end,environ,equals,%
+ ex,exactly,existence,for,from,func,given,hence,hereby,holds,%
+ idempotence,if,iff,implies,involutiveness,irreflexivity,is,it,%
+ let,means,mode,non,not,notation,now,of,or,otherwise,over,per,%
+ pred,prefix,projectivity,proof,provided,qua,reconsider,redefine,%
+ reflexivity,requirements,reserve,scheme,schemes,section,selector,%
+ set,st,struct,such,suppose,symmetry,synonym,take,that,the,then,%
+ theorem,theorems,thesis,thus,to,transitivity,uniqueness,%
+ vocabulary,where},%
+ sensitive=t,%
+ morecomment=[l]::%
+ }[keywords,comments]%
+\lst@definelanguage{Modula-2}%
+ {morekeywords={AND,ARRAY,BEGIN,BY,CASE,CONST,DIV,DO,ELSE,ELSIF,END,%
+ EXIT,EXPORT,FOR,FROM,IF,IMPLEMENTATION,IMPORT,IN,MOD,MODULE,NOT,%
+ OF,OR,POINTER,PROCEDURE,QUALIFIED,RECORD,REPEAT,RETURN,SET,THEN,%
+ TYPE,UNTIL,VAR,WHILE,WITH,ABS,BITSET,BOOLEAN,CAP,CARDINAL,CHAR,%
+ CHR,DEC,EXCL,FALSE,FLOAT,HALT,HIGH,INC,INCL,INTEGER,LONGCARD,%
+ LONGINT,LONGREAL,MAX,MIN,NIL,ODD,ORD,PROC,REAL,SIZE,TRUE,TRUNC,%
+ VAL,DEFINITION,LOOP},% added keywords due to Peter Bartke 99/07/22
+ sensitive,%
+ morecomment=[n]{(*}{*)},%
+ morestring=[d]',%
+ morestring=[d]"%
+ }[keywords,comments,strings]%
+\lstdefinelanguage{MuPAD}{%
+ morekeywords={end,next,break,if,then,elif,else,end_if,case,end_case,%
+ otherwise,for,from,to,step,downto,in,end_for,while,end_while,%
+ repeat,until,end_repeat,or,and,not,xor,div,mod,union,minus,%
+ intersect,subset,proc,begin,end_proc,domain,end_domain,category,%
+ end_category,axiom,end_axiom,quit,delete,frame},%
+ morekeywords=[2]{NIL,FAIL,TRUE,FALSE,UNKNOWN,I,RD_INF,RD_NINF,%
+ RD_NAN,name,local,option,save,inherits,of,do},%
+ otherkeywords={\%if,?,!,:=,<,>,=,<=,<>,>=,==>,<=>,::,..,...,->,%
+ @,@@,\$},%
+ sensitive=true,%
+ morecomment=[l]{//},%
+ morecomment=[n]{/*}{*/},%
+ morestring=[b]",%
+ morestring=[d]{`}%
+ }[keywords,comments,strings]
+\lst@definelanguage{NASTRAN}
+ {morekeywords={ENDDATA},%
+ morecomment=[l]$,%
+ MoreSelectCharTable=%
+ \lst@CArgX BEGIN\ BULK\relax\lst@CDef{}%
+ {\lst@ifmode\else \ifnum\lst@length=\z@
+ \lst@EnterMode{\lst@GPmode}{\lst@modetrue
+ \let\lst@currstyle\lst@gkeywords@sty}%
+ \fi \fi}%
+ {\ifnum\lst@mode=\lst@GPmode
+ \lst@XPrintToken \lst@LeaveMode
+ \fi}%
+ }[keywords,comments]%
+\lst@definelanguage{Oberon-2}%
+ {morekeywords={ARRAY,BEGIN,BOOLEAN,BY,CASE,CHAR,CONST,DIV,DO,ELSE,%
+ ELSIF,END,EXIT,FALSE,FOR,IF,IMPORT,IN,INTEGER,IS,LONGINT,%
+ LONGREAL,LOOP,MOD,MODULE,NIL,OF,OR,POINTER,PROCEDURE,REAL,RECORD,%
+ REPEAT,RETURN,SET,SHORTINT,THEN,TO,TRUE,TYPE,UNTIL,VAR,WHILE,%
+ WITH,ABS,ASH,CAP,CHR,COPY,DEC,ENTIER,EXCL,HALT,INC,INCL,LEN,LONG,%
+ MAX,MIN,NEW,ODD,ORD,SHORT,SIZE},%
+ sensitive,%
+ morecomment=[n]{(*}{*)},%
+ morestring=[d]',%
+ morestring=[d]"%
+ }[keywords,comments,strings]%
+%%
+%% OCL definition (c) 2000 Achim D. Brucker
+%%
+%% You are allowed to use, modify and distribute this code either under
+%% the terms of the LPPL (version 1.0 or later) or the GPL (version 2.0
+%% or later).
+%%
+\lst@definelanguage[decorative]{OCL}[OMG]{OCL}
+ {otherkeywords={@pre},%
+ morendkeywords={name,attributes,associatoinEnds,operations,%
+ supertypes,allSupertypes,allInstances,oclIsKindOf,oclIsTypeOf,%
+ oclAsType,oclInState,oclIsNew,evaluationType,abs,floor,round,max,%
+ min,div,mod,size,concat,toUpper,toLower,substring,includes,%
+ excludes,count,includesAll,exludesAll,isEmpty,notEmpty,sum,%
+ exists,forAll,isUnique,sortedBy,iterate,union,intersection,%
+ including,excluding,symmetricDifference,select,reject,collect,%
+ asSequence,asBag,asSequence,asSet,append,prepend,subSequence,at,%
+ first,last,true,false,isQuery}%
+ }%
+\lst@definelanguage[OMG]{OCL}%
+ {morekeywords={context,pre,inv,post},%
+ ndkeywords={or,xor,and,not,implies,if,then,else,endif},%
+ morekeywords=[3]{Boolean,Integer,Real,String,Set,Sequence,Bag,%
+ OclType,OclAny,OclExpression,Enumeration,Collection,},%
+ sensitive=t,%
+ morecomment=[l]--,%
+ morestring=[d]'%
+ }[keywords,comments,strings]%
+\lst@definelanguage{PL/I}%
+ {morekeywords={ABS,ATAN,AUTOMATIC,AUTO,ATAND,BEGIN,BINARY,BIN,BIT,%
+ BUILTIN,BY,CALL,CHARACTER,CHAR,CHECK,COLUMN,COL,COMPLEX,CPLX,%
+ COPY,COS,COSD,COSH,DATA,DATE,DECIMAL,DEC,DECLARE,DCL,DO,EDIT,%
+ ELSE,END,ENDFILE,ENDPAGE,ENTRY,EXP,EXTERNAL,EXT,FINISH,FIXED,%
+ FIXEDOVERFLOW,FOFL,FLOAT,FORMAT,GET,GO,GOTO,IF,IMAG,INDEX,%
+ INITIAL,INIT,INTERNAL,INT,LABEL,LENGTH,LIKE,LINE,LIST,LOG,LOG2,%
+ LOG10,MAIN,MAX,MIN,MOD,NOCHECK,NOFIXEDOVERFLOW,NOFOFL,NOOVERFLOW,%
+ NOOFL,NOSIZE,NOUNDERFLOW,NOUFL,NOZERODIVIDE,NOZDIV,ON,OPTIONS,%
+ OVERFLOW,OFL,PAGE,PICTURE,PROCEDURE,PROC,PUT,READ,REPEAT,RETURN,%
+ RETURNS,ROUND,SIN,SIND,SINH,SIZE,SKIP,SQRT,STATIC,STOP,STRING,%
+ SUBSTR,SUM,SYSIN,SYSPRINT,TAN,TAND,TANH,THEN,TO,UNDERFLOW,UFL,%
+ VARYING,WHILE,WRITE,ZERODIVIDE,ZDIV},%
+ sensitive=f,%
+ morecomment=[s]{/*}{*/},%
+ morestring=[d]'%
+ }[keywords,comments,strings]%
+%%
+%% Reduce definition (c) 2002 Geraint Paul Bevan
+%%
+\lst@definelanguage{Reduce}%
+ {morekeywords={%
+%% reserved identifiers
+abs,acos,acosh,acot,acoth,acsc,acsch,%
+adjprec,algebraic,algint,allbranch,allfac,and,%
+antisymmetric,append,arglength,array,asec,asech,%
+asin,asinh,atan,atan2,atanh,begin,bfspace,bye,%
+card_no,ceiling,clear,clearrules,coeff,coeffn,%
+cofactor,combineexpt,combinelogs,comment,comp,%
+complex,conj,cons,cont,cos,cosh,cot,coth,cramer,%
+cref,csc,csch,decompose,define,defn,deg,demo,den,%
+depend,det,df,difference,dilog,display,div,do,e,%
+echo,ed,editdef,ei,end,eps,eq,equal,erf,errcont,%
+evallhseqp,eval_mode,even,evenp,exp,expandlogs,%
+expr,expt,ezgcd,factor,factorial,factorize,fexpr,%
+first,fix,fixp,floor,for,forall,foreach,fort,%
+fort_width,freeof,fullroots,g,gcd,geq,go,goto,%
+greaterp,high_pow,hypot,i,if,ifactor,impart,in,%
+index,infinity,infix,input,int,integer,interpol,%
+intstr,k,korder,lambda,lcm,lcof,length,leq,lessp,%
+let,lhs,linear,linelength,lisp,list,listargp,%
+listargs,ln,load,load_package,log,log10,logb,%
+low_pow,lterm,macro,mainvar,mass,mat,match,%
+mateigen,matrix,max,mcd,member,memq,min,minus,mkid,%
+modular,msg,mshell,multiplicities,nat,neq,nero,%
+nextprime,nil,nodepend,noncom,nonzero,nosplit,%
+nospur,nullspace,num,numberp,odd,off,on,operator,%
+or,order,ordp,out,output,part,pause,period,pf,pi,%
+plus,precedence,precise,precision,pret,pri,primep,%
+print_precision,procedure,product,quit,quotient,%
+random,random_new_seed,rank,rat,ratarg,rational,%
+rationalize,ratpri,real,rederr,reduct,remainder,%
+remfac,remind,repart,repeat,rest,resultant,retry,%
+return,reverse,revpri,rhs,rlisp88,%
+root_multiplicity,round,roundall,roundbf,rounded,%
+saveas,savestructr,scalar,sec,sech,second,set,%
+setmod,setq,share,showrules,showtime,shut,sign,sin,%
+sinh,smacro,solve,solvesingular,spur,sqrt,structr,%
+sub,sum,symbolic,symmetric,t,tan,tanh,third,time,%
+times,tp,tra,trace,trfac,trigform,trint,until,%
+varname,vecdim,vector,weight,when,where,while,%
+write,ws,wtlevel,%
+%% identifiers with spaces
+%% for all,for each,go to,such that,%
+},%
+ sensitive=false,%
+ morecomment=[l]\%,%
+ morecomment=[s]{COMMENT}{;},%
+ morecomment=[s]{COMMENT}{$},%
+ morestring="%
+ }[keywords,comments,strings]%
+\lst@definelanguage[IBM]{Simula}[DEC]{Simula}{}%
+\lst@definelanguage[DEC]{Simula}[67]{Simula}%
+ {morekeywords={and,eq,eqv,ge,gt,hidden,imp,le,long,lt,ne,not,%
+ options,or,protected,short}%
+ }%
+\lst@definelanguage[CII]{Simula}[67]{Simula}%
+ {morekeywords={and,equiv,exit,impl,not,or,stop}}%
+\lst@definelanguage[67]{Simula}%
+ {morekeywords={activate,after,array,at,before,begin,boolean,%
+ character,class,comment,delay,detach,do,else,end,external,false,%
+ for,go,goto,if,in,inner,inspect,integer,is,label,name,new,none,%
+ notext,otherwise,prior,procedure,qua,reactivate,real,ref,resume,%
+ simset,simulation,step,switch,text,then,this,to,true,until,value,%
+ virtual,when,while},%
+ sensitive=f,%
+ keywordcommentsemicolon={end}{else,end,otherwise,when}{comment},%
+ morestring=[d]",%
+ morestring=[d]'%
+ }[keywords,keywordcomments,strings]%
+\lst@definelanguage{S}[]{R}{}
+\lst@definelanguage[PLUS]{S}[]{R}{}
+\lst@definelanguage{R}%
+ {keywords={abbreviate,abline,abs,acos,acosh,action,add1,add,%
+ aggregate,alias,Alias,alist,all,anova,any,aov,aperm,append,apply,%
+ approx,approxfun,apropos,Arg,args,array,arrows,as,asin,asinh,%
+ atan,atan2,atanh,attach,attr,attributes,autoload,autoloader,ave,%
+ axis,backsolve,barplot,basename,besselI,besselJ,besselK,besselY,%
+ beta,binomial,body,box,boxplot,break,browser,bug,builtins,bxp,by,%
+ c,C,call,Call,case,cat,category,cbind,ceiling,character,char,%
+ charmatch,check,chol,chol2inv,choose,chull,class,close,cm,codes,%
+ coef,coefficients,co,col,colnames,colors,colours,commandArgs,%
+ comment,complete,complex,conflicts,Conj,contents,contour,%
+ contrasts,contr,control,helmert,contrib,convolve,cooks,coords,%
+ distance,coplot,cor,cos,cosh,count,fields,cov,covratio,wt,CRAN,%
+ create,crossprod,cummax,cummin,cumprod,cumsum,curve,cut,cycle,D,%
+ data,dataentry,date,dbeta,dbinom,dcauchy,dchisq,de,debug,%
+ debugger,Defunct,default,delay,delete,deltat,demo,de,density,%
+ deparse,dependencies,Deprecated,deriv,description,detach,%
+ dev2bitmap,dev,cur,deviance,off,prev,,dexp,df,dfbetas,dffits,%
+ dgamma,dgeom,dget,dhyper,diag,diff,digamma,dim,dimnames,dir,%
+ dirname,dlnorm,dlogis,dnbinom,dnchisq,dnorm,do,dotplot,double,%
+ download,dpois,dput,drop,drop1,dsignrank,dt,dummy,dump,dunif,%
+ duplicated,dweibull,dwilcox,dyn,edit,eff,effects,eigen,else,%
+ emacs,end,environment,env,erase,eval,equal,evalq,example,exists,%
+ exit,exp,expand,expression,External,extract,extractAIC,factor,%
+ fail,family,fft,file,filled,find,fitted,fivenum,fix,floor,for,%
+ For,formals,format,formatC,formula,Fortran,forwardsolve,frame,%
+ frequency,ftable,ftable2table,function,gamma,Gamma,gammaCody,%
+ gaussian,gc,gcinfo,gctorture,get,getenv,geterrmessage,getOption,%
+ getwd,gl,glm,globalenv,gnome,GNOME,graphics,gray,grep,grey,grid,%
+ gsub,hasTsp,hat,heat,help,hist,home,hsv,httpclient,I,identify,if,%
+ ifelse,Im,image,\%in\%,index,influence,measures,inherits,install,%
+ installed,integer,interaction,interactive,Internal,intersect,%
+ inverse,invisible,IQR,is,jitter,kappa,kronecker,labels,lapply,%
+ layout,lbeta,lchoose,lcm,legend,length,levels,lgamma,library,%
+ licence,license,lines,list,lm,load,local,locator,log,log10,log1p,%
+ log2,logical,loglin,lower,lowess,ls,lsfit,lsf,ls,machine,Machine,%
+ mad,mahalanobis,make,link,margin,match,Math,matlines,mat,matplot,%
+ matpoints,matrix,max,mean,median,memory,menu,merge,methods,min,%
+ missing,Mod,mode,model,response,mosaicplot,mtext,mvfft,na,nan,%
+ names,omit,nargs,nchar,ncol,NCOL,new,next,NextMethod,nextn,%
+ nlevels,nlm,noquote,NotYetImplemented,NotYetUsed,nrow,NROW,null,%
+ numeric,\%o\%,objects,offset,old,on,Ops,optim,optimise,optimize,%
+ options,or,order,ordered,outer,package,packages,page,pairlist,%
+ pairs,palette,panel,par,parent,parse,paste,path,pbeta,pbinom,%
+ pcauchy,pchisq,pentagamma,persp,pexp,pf,pgamma,pgeom,phyper,pico,%
+ pictex,piechart,Platform,plnorm,plogis,plot,pmatch,pmax,pmin,%
+ pnbinom,pnchisq,pnorm,points,poisson,poly,polygon,polyroot,pos,%
+ postscript,power,ppoints,ppois,predict,preplot,pretty,Primitive,%
+ print,prmatrix,proc,prod,profile,proj,prompt,prop,provide,%
+ psignrank,ps,pt,ptukey,punif,pweibull,pwilcox,q,qbeta,qbinom,%
+ qcauchy,qchisq,qexp,qf,qgamma,qgeom,qhyper,qlnorm,qlogis,qnbinom,%
+ qnchisq,qnorm,qpois,qqline,qqnorm,qqplot,qr,Q,qty,qy,qsignrank,%
+ qt,qtukey,quantile,quasi,quit,qunif,quote,qweibull,qwilcox,%
+ rainbow,range,rank,rbeta,rbind,rbinom,rcauchy,rchisq,Re,read,csv,%
+ csv2,fwf,readline,socket,real,Recall,rect,reformulate,regexpr,%
+ relevel,remove,rep,repeat,replace,replications,report,require,%
+ resid,residuals,restart,return,rev,rexp,rf,rgamma,rgb,rgeom,R,%
+ rhyper,rle,rlnorm,rlogis,rm,rnbinom,RNGkind,rnorm,round,row,%
+ rownames,rowsum,rpois,rsignrank,rstandard,rstudent,rt,rug,runif,%
+ rweibull,rwilcox,sample,sapply,save,scale,scan,scan,screen,sd,se,%
+ search,searchpaths,segments,seq,sequence,setdiff,setequal,set,%
+ setwd,show,sign,signif,sin,single,sinh,sink,solve,sort,source,%
+ spline,splinefun,split,sqrt,stars,start,stat,stem,step,stop,%
+ storage,strstrheight,stripplot,strsplit,structure,strwidth,sub,%
+ subset,substitute,substr,substring,sum,summary,sunflowerplot,svd,%
+ sweep,switch,symbol,symbols,symnum,sys,status,system,t,table,%
+ tabulate,tan,tanh,tapply,tempfile,terms,terrain,tetragamma,text,%
+ time,title,topo,trace,traceback,transform,tri,trigamma,trunc,try,%
+ ts,tsp,typeof,unclass,undebug,undoc,union,unique,uniroot,unix,%
+ unlink,unlist,unname,untrace,update,upper,url,UseMethod,var,%
+ variable,vector,Version,vi,warning,warnings,weighted,weights,%
+ which,while,window,write,\%x\%,x11,X11,xedit,xemacs,xinch,xor,%
+ xpdrows,xy,xyinch,yinch,zapsmall,zip},%
+ otherkeywords={!,!=,~,$,*,\&,\%/\%,\%*\%,\%\%,<-,<<-,_,/},%
+ alsoother={._$},%
+ sensitive,%
+ morecomment=[l]\#,%
+ morestring=[d]",%
+ morestring=[d]'% 2001 Robert Denham
+ }%
+\lst@definelanguage{SAS}%
+ {procnamekeys={proc},%
+ morekeywords={DATA,AND,OR,NOT,EQ,GT,LT,GE,LE,NE,INFILE,INPUT,DO,BY,%
+ TO,SIN,COS,OUTPUT,END,PLOT,RUN,LIBNAME,VAR,TITLE,FIRSTOBS,OBS,%
+ DELIMITER,DLM,EOF,ABS,DIM,HBOUND,LBOUND,MAX,MIN,MOD,SIGN,SQRT,%
+ CEIL,FLOOR,FUZZ,INT,ROUND,TRUNC,DIGAMMA,ERF,ERFC,EXP,GAMMA,%
+ LGAMMA,LOG,LOG2,LOG10,ARCOS,ARSIN,ATAN,COSH,SINH,TANH,TAN,%
+ POISSON,PROBBETA,PROBBNML,PROBCHI,PROBF,PROBGAM,PROBHYPR,%
+ PROBNEGB,PROBNORM,PROBT,BETAINV,CINV,FINV,GAMINV,PROBIT,TINV,CSS,%
+ CV,KURTOSIS,MEAN,NMISS,RANGE,SKEWNESS,STD,STDERR,SUM,USS,NORMAL,%
+ RANBIN,RANCAU,RANEXP,RANGAM,RANNOR,RANPOI,RANTBL,RANTRI,RANUNI,%
+ UNIFORM,IF,THEN,ELSE,WHILE,UNTIL,DROP,KEEP,LABEL,DEFAULT,ARRAY,%
+ MERGE,CARDS,CARDS4,PUT,SET,UPDATE,ABORT,DELETE,DISPLAY,LIST,%
+ LOSTCARD,MISSING,STOP,WHERE,ARRAY,DROP,KEEP,WINDOW,LENGTH,RENAME,%
+ RETAIN,MEANS,UNIVARIATE,SUMMARY,TABULATE,CORR,FREQ,FOOTNOTE,NOTE,%
+ SHOW},%
+ otherkeywords={!,!=,~,$,*,\&,_,/,<,>=,=<,>},%
+ morestring=[d]'%
+ }[keywords,comments,strings,procnames]%
+\lst@definelanguage[AlLaTeX]{TeX}[LaTeX]{TeX}%
+ {moretexcs={AtBeginDocument,AtBeginDvi,AtEndDocument,AtEndOfClass,%
+ AtEndOfPackage,ClassError,ClassInfo,ClassWarning,%
+ ClassWarningNoLine,CurrentOption,DeclareErrorFont,%
+ DeclareFixedFont,DeclareFontEncoding,DeclareFontEncodingDefaults,%
+ DeclareFontFamily,DeclareFontShape,DeclareFontSubstitution,%
+ DeclareMathAccent,DeclareMathAlphabet,DeclareMathAlphabet,%
+ DeclareMathDelimiter,DeclareMathRadical,DeclareMathSizes,%
+ DeclareMathSymbol,DeclareMathVersion,DeclareOldFontCommand,%
+ DeclareOption,DeclarePreloadSizes,DeclareRobustCommand,%
+ DeclareSizeFunction,DeclareSymbolFont,DeclareSymbolFontAlphabet,%
+ DeclareTextAccent,DeclareTextAccentDefault,DeclareTextCommand,%
+ DeclareTextCommandDefault,DeclareTextComposite,%
+ DeclareTextCompositeCommand,DeclareTextFontCommand,%
+ DeclareTextSymbol,DeclareTextSymbolDefault,ExecuteOptions,%
+ GenericError,GenericInfo,GenericWarning,IfFileExists,%
+ InputIfFileExists,LoadClass,LoadClassWithOptions,MessageBreak,%
+ OptionNotUsed,PackageError,PackageInfo,PackageWarning,%
+ PackageWarningNoLine,PassOptionsToClass,PassOptionsToPackage,%
+ ProcessOptionsProvidesClass,ProvidesFile,ProvidesFile,%
+ ProvidesPackage,ProvideTextCommand,RequirePackage,%
+ RequirePackageWithOptions,SetMathAlphabet,SetSymbolFont,%
+ TextSymbolUnavailable,UseTextAccent,UseTextSymbol},%
+ morekeywords={array,center,displaymath,document,enumerate,eqnarray,%
+ equation,flushleft,flushright,itemize,list,lrbox,math,minipage,%
+ picture,sloppypar,tabbing,tabular,trivlist,verbatim}%
+ }%
+\lst@definelanguage[LaTeX]{TeX}[common]{TeX}%
+ {moretexcs={a,AA,aa,addcontentsline,addpenalty,addtocontents,%
+ addtocounter,addtolength,addtoversion,addvspace,alph,Alph,and,%
+ arabic,array,arraycolsep,arrayrulewidth,arraystretch,author,%
+ baselinestretch,begin,bezier,bfseries,bibcite,bibdata,bibitem,%
+ bibliography,bibliographystyle,bibstyle,bigskip,boldmath,%
+ botfigrule,bottomfraction,Box,caption,center,CheckCommand,circle,%
+ citation,cite,cleardoublepage,clearpage,cline,columnsep,%
+ columnseprule,columnwidth,contentsline,dashbox,date,dblfigrule,%
+ dblfloatpagefraction,dblfloatsep,dbltextfloatsep,dbltopfraction,%
+ defaultscriptratio,defaultscriptscriptratio,depth,Diamond,%
+ displaymath,document,documentclass,documentstyle,doublerulesep,%
+ em,emph,endarray,endcenter,enddisplaymath,enddocument,%
+ endenumerate,endeqnarray,endequation,endflushleft,endflushright,%
+ enditemize,endlist,endlrbox,endmath,endminipage,endpicture,%
+ endsloppypar,endtabbing,endtabular,endtrivlist,endverbatim,%
+ enlargethispage,ensuremath,enumerate,eqnarray,equation,%
+ evensidemargin,extracolsep,fbox,fboxrule,fboxsep,filecontents,%
+ fill,floatpagefraction,floatsep,flushbottom,flushleft,flushright,%
+ fnsymbol,fontencoding,fontfamily,fontseries,fontshape,fontsize,%
+ fontsubfuzz,footnotemark,footnotesep,footnotetext,footskip,frac,%
+ frame,framebox,fussy,glossary,headheight,headsep,height,hline,%
+ hspace,I,include,includeonly,index,inputlineno,intextsep,%
+ itemindent,itemize,itemsep,iterate,itshape,Join,kill,label,%
+ labelsep,labelwidth,LaTeX,LaTeXe,leadsto,lefteqn,leftmargin,%
+ leftmargini,leftmarginii,leftmarginiii,leftmarginiv,leftmarginv,%
+ leftmarginvi,leftmark,lhd,lim,linebreak,linespread,linethickness,%
+ linewidth,list,listfiles,listfiles,listparindent,lrbox,%
+ makeatletter,makeatother,makebox,makeglossary,makeindex,%
+ makelabel,MakeLowercase,MakeUppercase,marginpar,marginparpush,%
+ marginparsep,marginparwidth,markboth,markright,math,mathbf,%
+ mathellipsis,mathgroup,mathit,mathrm,mathsf,mathsterling,mathtt,%
+ mathunderscore,mathversion,mbox,mdseries,mho,minipage,%
+ multicolumn,multiput,NeedsTeXFormat,newcommand,newcounter,%
+ newenvironment,newfont,newhelp,newlabel,newlength,newline,%
+ newmathalphabet,newpage,newsavebox,newtheorem,nobreakspace,%
+ nobreakspace,nocite,nocorr,nocorrlist,nofiles,nolinebreak,%
+ nonumber,nopagebreak,normalcolor,normalfont,normalmarginpar,%
+ numberline,obeycr,oddsidemargin,oldstylenums,onecolumn,oval,%
+ pagebreak,pagenumbering,pageref,pagestyle,paperheight,paperwidth,%
+ paragraphmark,parbox,parsep,partopsep,picture,poptabs,pounds,%
+ protect,pushtabs,put,qbezier,qbeziermax,r,raggedleft,raisebox,%
+ ref,refstepcounter,renewcommand,renewenvironment,restorecr,%
+ reversemarginpar,rhd,rightmargin,rightmark,rmfamily,roman,Roman,%
+ rootbox,rule,samepage,sbox,scshape,secdef,section,sectionmark,%
+ selectfont,setcounter,settodepth,settoheight,settowidth,sffamily,%
+ shortstack,showoutput,showoverfull,sloppy,sloppypar,slshape,%
+ smallskip,sqsubset,sqsupset,SS,stackrel,stepcounter,stop,stretch,%
+ subparagraphmark,subsectionmark,subsubsectionmark,sum,%
+ suppressfloats,symbol,tabbing,tabbingsep,tabcolsep,tabular,%
+ tabularnewline,textasciicircum,textasciitilde,textbackslash,%
+ textbar,textbf,textbraceleft,textbraceright,textbullet,%
+ textcircled,textcompwordmark,textdagger,textdaggerdbl,textdollar,%
+ textellipsis,textemdash,textendash,textexclamdown,textfloatsep,%
+ textfraction,textgreater,textheight,textit,textless,textmd,%
+ textnormal,textparagraph,textperiodcentered,textquestiondown,%
+ textquotedblleft,textquotedblright,textquoteleft,textquoteright,%
+ textregistered,textrm,textsc,textsection,textsf,textsl,%
+ textsterling,textsuperscript,texttrademark,texttt,textunderscore,%
+ textup,textvisiblespace,textwidth,thanks,thefootnote,thempfn,%
+ thempfn,thempfootnote,thepage,thepage,thicklines,thinlines,%
+ thispagestyle,title,today,topfigrule,topfraction,topmargin,%
+ topsep,totalheight,tracingfonts,trivlist,ttfamily,twocolumn,%
+ typein,typeout,unboldmath,unitlength,unlhd,unrhd,upshape,usebox,%
+ usecounter,usefont,usepackage,value,vector,verb,verbatim,vline,%
+ vspace,width,%
+ normalsize,small,footnotesize,scriptsize,tiny,large,Large,LARGE,%
+ huge,Huge}%
+ }%
+\lst@definelanguage[plain]{TeX}[common]{TeX}%
+ {moretexcs={advancepageno,beginsection,bf,bffam,bye,cal,cleartabs,%
+ columns,dosupereject,endinsert,eqalign,eqalignno,fiverm,fivebf,%
+ fivei,fivesy,folio,footline,hang,headline,it,itemitem,itfam,%
+ leqalignno,magnification,makefootline,makeheadline,midinsert,mit,%
+ mscount,nopagenumbers,normalbottom,of,oldstyle,pagebody,%
+ pagecontents,pageinsert,pageno,plainoutput,preloaded,proclaim,rm,%
+ settabs,sevenbf,seveni,sevensy,sevenrm,sl,slfam,supereject,%
+ tabalign,tabs,tabsdone,tabsyet,tenbf,tenex,teni,tenit,tenrm,%
+ tensl,tensy,tentt,textindent,topglue,topins,topinsert,tt,ttfam,%
+ ttraggedright,vfootnote}%
+ }%
+\lst@definelanguage[common]{TeX}[primitive]{TeX}
+ {moretexcs={active,acute,ae,AE,aleph,allocationnumber,allowbreak,%
+ alpha,amalg,angle,approx,arccos,arcsin,arctan,arg,arrowvert,%
+ Arrowvert,ast,asymp,b,backslash,bar,beta,bgroup,big,Big,bigbreak,%
+ bigcap,bigcirc,bigcup,bigg,Bigg,biggl,Biggl,biggm,Biggm,biggr,%
+ Biggr,bigl,Bigl,bigm,Bigm,bigodot,bigoplus,bigotimes,bigr,Bigr,%
+ bigskip,bigskipamount,bigsqcup,bigtriangledown,bigtriangleup,%
+ biguplus,bigvee,bigwedge,bmod,bordermatrix,bot,bowtie,brace,%
+ braceld,bracelu,bracerd,braceru,bracevert,brack,break,breve,%
+ buildrel,bullet,c,cap,cases,cdot,cdotp,cdots,centering,%
+ centerline,check,chi,choose,circ,clubsuit,colon,cong,coprod,%
+ copyright,cos,cosh,cot,coth,csc,cup,d,dag,dagger,dashv,ddag,%
+ ddagger,ddot,ddots,deg,delta,Delta,det,diamond,diamondsuit,dim,%
+ displaylines,div,do,dospecials,dot,doteq,dotfill,dots,downarrow,%
+ Downarrow,downbracefill,egroup,eject,ell,empty,emptyset,endgraf,%
+ endline,enskip,enspace,epsilon,equiv,eta,exists,exp,filbreak,%
+ flat,fmtname,fmtversion,footins,footnote,footnoterule,forall,%
+ frenchspacing,frown,gamma,Gamma,gcd,ge,geq,gets,gg,goodbreak,%
+ grave,H,hat,hbar,heartsuit,hglue,hideskip,hidewidth,hom,%
+ hookleftarrow,hookrightarrow,hphantom,hrulefill,i,ialign,iff,Im,%
+ imath,in,inf,infty,int,interdisplaylinepenalty,%
+ interfootnotelinepenalty,intop,iota,item,j,jmath,joinrel,jot,%
+ kappa,ker,l,L,lambda,Lambda,land,langle,lbrace,lbrack,lceil,%
+ ldotp,ldots,le,leavevmode,leftarrow,Leftarrow,leftarrowfill,%
+ leftharpoondown,leftharpoonup,leftline,leftrightarrow,%
+ Leftrightarrow,leq,lfloor,lg,lgroup,lhook,lim,liminf,limsup,line,%
+ ll,llap,lmoustache,ln,lnot,log,longleftarrow,Longleftarrow,%
+ longleftrightarrow,Longleftrightarrow,longmapsto,longrightarrow,%
+ Longrightarrow,loop,lor,lq,magstep,magstep,magstephalf,mapsto,%
+ mapstochar,mathhexbox,mathpalette,mathstrut,matrix,max,maxdimen,%
+ medbreak,medskip,medskipamount,mid,min,models,mp,mu,multispan,%
+ nabla,narrower,natural,ne,nearrow,neg,negthinspace,neq,newbox,%
+ newcount,newdimen,newfam,newif,newinsert,newlanguage,newmuskip,%
+ newread,newskip,newtoks,newwrite,next,ni,nobreak,nointerlineskip,%
+ nonfrenchspacing,normalbaselines,normalbaselineskip,%
+ normallineskip,normallineskiplimit,not,notin,nu,null,nwarrow,o,O,%
+ oalign,obeylines,obeyspaces,odot,oe,OE,offinterlineskip,oint,%
+ ointop,omega,Omega,ominus,ooalign,openup,oplus,oslash,otimes,%
+ overbrace,overleftarrow,overrightarrow,owns,P,parallel,partial,%
+ perp,phantom,phi,Phi,pi,Pi,pm,pmatrix,pmod,Pr,prec,preceq,prime,%
+ prod,propto,psi,Psi,qquad,quad,raggedbottom,raggedright,rangle,%
+ rbrace,rbrack,rceil,Re,relbar,Relbar,removelastskip,repeat,%
+ rfloor,rgroup,rho,rhook,rightarrow,Rightarrow,rightarrowfill,%
+ rightharpoondown,rightharpoonup,rightleftharpoons,rightline,rlap,%
+ rmoustache,root,rq,S,sb,searrow,sec,setminus,sharp,showhyphens,%
+ sigma,Sigma,sim,simeq,sin,sinh,skew,slash,smallbreak,smallint,%
+ smallskip,smallskipamount,smash,smile,sp,space,spadesuit,sqcap,%
+ sqcup,sqrt,sqsubseteq,sqsupseteq,ss,star,strut,strutbox,subset,%
+ subseteq,succ,succeq,sum,sup,supset,supseteq,surd,swarrow,t,tan,%
+ tanh,tau,TeX,theta,Theta,thinspace,tilde,times,to,top,tracingall,%
+ triangle,triangleleft,triangleright,u,underbar,underbrace,%
+ uparrow,Uparrow,upbracefill,updownarrow,Updownarrow,uplus,%
+ upsilon,Upsilon,v,varepsilon,varphi,varpi,varrho,varsigma,%
+ vartheta,vdash,vdots,vec,vee,vert,Vert,vglue,vphantom,wedge,%
+ widehat,widetilde,wlog,wp,wr,xi,Xi,zeta}%
+ }%
+\lst@definelanguage[primitive]{TeX}%
+ {moretexcs={above,abovedisplayshortskip,abovedisplayskip,aftergroup,%
+ abovewithdelims,accent,adjdemerits,advance,afterassignment,atop,%
+ atopwithdelims,badness,baselineskip,batchmode,begingroup,%
+ belowdisplayshortskip,belowdisplayskip,binoppenalty,botmark,box,%
+ boxmaxdepth,brokenpenalty,catcode,char,chardef,cleaders,closein,%
+ closeout,clubpenalty,copy,count,countdef,cr,crcr,csname,day,%
+ deadcycles,def,defaulthyphenchar,defaultskewchar,delcode,%
+ delimiter,delimiterfactor,delimitershortfall,dimen,dimendef,%
+ discretionary,displayindent,displaylimits,displaystyle,%
+ displaywidowpenalty,displaywidth,divide,doublehyphendemerits,dp,%
+ edef,else,emergencystretch,end,endcsname,endgroup,endinput,%
+ endlinechar,eqno,errhelp,errmessage,errorcontextlines,%
+ errorstopmode,escapechar,everycr,everydisplay,everyhbox,everyjob,%
+ everymath,everypar,everyvbox,exhyphenpenalty,expandafter,fam,fi,%
+ finalhypendemerits,firstmark,floatingpenalty,font,fontdimen,%
+ fontname,futurelet,gdef,global,globaldefs,halign,hangafter,%
+ hangindent,hbadness,hbox,hfil,hfill,hfilneg,hfuzz,hoffset,%
+ holdinginserts,hrule,hsize,hskip,hss,ht,hyphenation,hyphenchar,%
+ hyphenpenalty,if,ifcase,ifcat,ifdim,ifeof,iffalse,ifhbox,ifhmode,%
+ ifinner,ifmmode,ifnum,ifodd,iftrue,ifvbox,ifvmode,ifvoid,ifx,%
+ ignorespaces,immediate,indent,input,insert,insertpenalties,%
+ interlinepenalty,jobname,kern,language,lastbox,lastkern,%
+ lastpenalty,lastskip,lccode,leaders,left,lefthyphenmin,leftskip,%
+ leqno,let,limits,linepenalty,lineskip,lineskiplimits,long,%
+ looseness,lower,lowercase,mag,mark,mathaccent,mathbin,mathchar,%
+ mathchardef,mathchoice,mathclose,mathcode,mathinner,mathop,%
+ mathopen,mathord,mathpunct,mathrel,mathsurround,maxdeadcycles,%
+ maxdepth,meaning,medmuskip,message,mkern,month,moveleft,%
+ moveright,mskip,multiply,muskip,muskipdef,newlinechar,noalign,%
+ noboundary,noexpand,noindent,nolimits,nonscript,nonstopmode,%
+ nulldelimiterspace,nullfont,number,omit,openin,openout,or,outer,%
+ output,outputpenalty,over,overfullrule,overline,overwithdelims,%
+ pagedepth,pagefilllstretch,pagefillstretch,pagefilstretch,%
+ pagegoal,pageshrink,pagestretch,pagetotal,par,parfillskip,%
+ parindent,parshape,parskip,patterns,pausing,penalty,%
+ postdisplaypenalty,predisplaypenalty,predisplaysize,pretolerance,%
+ prevdepth,prevgraf,radical,raise,read,relax,relpenalty,right,%
+ righthyphenmin,rightskip,romannumeral,scriptfont,%
+ scriptscriptfont,scriptscriptstyle,scriptspace,scriptstyle,%
+ scrollmode,setbox,setlanguage,sfcode,shipout,show,showbox,%
+ showboxbreadth,showboxdepth,showlists,showthe,skewchar,skip,%
+ skipdef,spacefactor,spaceskip,span,special,splitbotmark,%
+ splitfirstmark,splitmaxdepth,splittopskip,string,tabskip,%
+ textfont,textstyle,the,thickmuskip,thinmuskip,time,toks,toksdef,%
+ tolerance,topmark,topskip,tracingcommands,tracinglostchars,%
+ tracingmacros,tracingonline,tracingoutput,tracingpages,%
+ tracingparagraphs,tracingrestores,tracingstats,uccode,uchyph,%
+ underline,unhbox,unhcopy,unkern,unpenalty,unskip,unvbox,unvcopy,%
+ uppercase,vadjust,valign,vbadness,vbox,vcenter,vfil,vfill,%
+ vfilneg,vfuzz,voffset,vrule,vsize,vskip,vsplit,vss,vtop,wd,%
+ widowpenalty,write,xdef,xleaders,xspaceskip,year},%
+ sensitive,%
+ alsoother={0123456789$_},%
+ morecomment=[l]\%%
+ }[keywords,tex,comments]%
+%%
+%% Verilog definition (c) 2003 Cameron H. G. Wright
+%% Based on the IEEE 1364-2001 Verilog HDL standard
+%% Ref: S. Palnitkar, "Verilog HDL: A Guide to Digital Design and Synthesis,"
+%% Prentice Hall, 2003. ISBN: 0-13-044911-3
+%%
+\lst@definelanguage{Verilog}%
+ {morekeywords={% reserved keywords
+ always,and,assign,automatic,begin,buf,bufif0,bufif1,case,casex,%
+ casez,cell,cmos,config,deassign,default,defparam,design,disable,%
+ edge,else,end,endcase,endconfig,endfunction,endgenerate,%
+ endmodule,endprimitive,endspecify,endtable,endtask,event,for,%
+ force,forever,fork,function,generate,genvar,highz0,highz1,if,%
+ ifnone,incdir,include,initial,inout,input,instance,integer,join,%
+ large,liblist,library,localparam,macromodule,medium,module,nand,%
+ negedge,nmos,nor,noshowcancelled,not,notif0,notif1,or,output,%
+ parameter,pmos,posedge,primitive,pull0,pull1,pulldown,pullup,%
+ pulsestyle_onevent,pulsestyle_ondetect,rcmos,real,realtime,reg,%
+ release,repeat,rnmos,rpmos,rtran,rtranif0,rtranif1,scalared,%
+ showcancelled,signed,small,specify,specparam,strong0,strong1,%
+ supply0,supply1,table,task,time,tran,tranif0,tranif1,tri,tri0,%
+ tri1,triand,trior,trireg,unsigned,use,vectored,wait,wand,weak0,%
+ weak1,while,wire,wor,xnor,xor},%
+ morekeywords=[2]{% system tasks and functions
+ $bitstoreal,$countdrivers,$display,$fclose,$fdisplay,$fmonitor,%
+ $fopen,$fstrobe,$fwrite,$finish,$getpattern,$history,$incsave,%
+ $input,$itor,$key,$list,$log,$monitor,$monitoroff,$monitoron,%
+ $nokey},%
+ morekeywords=[3]{% compiler directives
+ `accelerate,`autoexpand_vectornets,`celldefine,`default_nettype,%
+ `define,`else,`elsif,`endcelldefine,`endif,`endprotect,%
+ `endprotected,`expand_vectornets,`ifdef,`ifndef,`include,%
+ `no_accelerate,`noexpand_vectornets,`noremove_gatenames,%
+ `nounconnected_drive,`protect,`protected,`remove_gatenames,%
+ `remove_netnames,`resetall,`timescale,`unconnected_drive},%
+ alsoletter=\`,%
+ sensitive,%
+ morecomment=[s]{/*}{*/},%
+ morecomment=[l]//,% nonstandard
+ morestring=[b]"%
+ }[keywords,comments,strings]%
+%%
+%% AADL definition rolland jean-francois
+%% rolland@irit.fr
+%%
+%%
+%%
+\lst@definelanguage{AADL}%
+ {morekeywords={% reserved keywords
+ aadlboolean,aadlinteger,aadlreal,aadlstring,%
+ access,all,and,annex,%
+ applies,behavior_specification,binding,bus,calls,%
+ classifier,complete,composite,computation,concurrent,%
+ connections,constant,count,data,%
+ delay,delta,device,else,elsif,end,enumeration,%
+ event,extends,false,features,%
+ flow,flows,for,fresh,history,group,if,implementation,%
+ in,inherit,initial,inverse,%
+ is,list,memory,mode,%
+ modes,none,not,of,on,%
+ or,out,package,parameter,%
+ path,port,private,process,%
+ processor,properties,property,provides,%
+ public,range,reference,refined,%
+ refines,requires,return,server,set,%
+ sink,source,state,states,subcomponents,subprogram,%
+ system,thread,timeout,to,transitions,true,%
+ type,units,urgent,value,variables,when%
+ },%
+ morecomment=[l]--,%
+ literate=%
+ {-[}{{\(- \hskip -0.2em[\)}}1%
+ {]->}{{\(]\hskip -0.4em\rightarrow\)}}1%
+ }[keywords,comments]%
+%%
+%% B
+%%
+\lst@definelanguage{AMN}%
+ {morekeywords={MACHINE,REFINEMENT,REFINES,SEES,INCLUDES,%
+ SETS,CONSTANTS,PROPERTIES,VARIABLES,INVARIANT,BEGIN,%
+ INITIALISATION,OPERATIONS,PRE,SELECT,THEN,END,IF,ELSE,WHILE,DO,VARIANT,%
+ CHOICE,OR,ANY,WHERE,VAR,IN},%
+ sensitive=true,
+ literate=%
+ {[]}{{\([\hskip -0.1em]\)}}1%
+ {>}{{\(>\)}}1%
+ {<}{{\(<\)}}1%
+ {->}{{\(\rightarrow\)}}1%
+ {<-}{{\(\leftarrow\)}}1%
+ {<--}{{\(\longleftarrow\)}}2%
+ {-->}{{\(\longrightarrow\)}}2%
+ {=>}{{\(\Rightarrow\)}}1%
+ {>=}{{\(\geq\)}}1%
+ {<=}{{\(\leq\)}}1%
+ {/\\}{{\(\cap\)}}1%
+ {\\/}{{\(\cup\)}}1%
+ {\{\}}{{\(\emptyset\)}}1%
+ {not}{{\(\lnot\)}}1%
+ {:}{{\(\in\)}}1%
+ {:(}{{:(}}1%
+ {::}{{\(:\!\in\)}}1%
+ {:=}{{:=}}1%
+ {<:}{{\(\subseteq\)}}1%
+ {<<:}{{\(\subset\)}}1%
+ {/=}{{\(\neq\)}}1%
+ {/:}{{\(\not\in\)}}1%
+ {\&}{{\(\land\)}}1,%
+ morecomment=[s]{/*}{*/},%
+ morestring=[d]",%
+ commentstyle={\textit},%
+ }[keywords,comments]%
+%%
+%% isabelle
+%%
+\lst@definelanguage{isabelle}%
+ {morekeywords={add,also,and,apply,assm,assume,assumes,axioms,begin,by,case,constdefs,done,end,else,if,fix,from,have,hints,imports,lemma,let,measure,moreover,next,note,obtain,proof,qed,recdef,rule,section,show,shows,subsection,then,theorem,theorems,theory,thesis,this,thus,types,ultimately,unfold,where,with},%
+ sensitive=true,
+ literate=%
+ {~}{\(\neg\)}1%
+ {==}{\(\triangleq\)}1%
+ {\{\}}{\(\emptyset\)}1%
+ {\\}{\(\land\)}1%
+ {\\}{\(\ldots\)}1%
+ {\\}{\(\exists\)}1%
+ {\\}{\(\forall\)}1%
+ {\\}{\(\in\)}1%
+ {\\}{\(\cap\)}1%
+ {\\}{\(\lambda\)}1%
+ {\\}{\(\Rightarrow\)}1%
+ {\\}{\(\not\in\)}1%
+ {\\}{\(\not=\)}1%
+ {\\}{\(\lor\)}1%
+ {\\}{\(\rightarrow\)}1%
+ {\\}{\(\subset\)}1%
+ {\\}{\(\times\)}1
+ {\\}{\(\cup\)}1%
+ {\\}{\(\bigcup\)}1%
+ {\\}{\(\subseteq\)}1,%
+ morecomment=[s]{(*}{(*},%
+ commentstyle={\textit},%
+ }[keywords,comments]%
+%%
+%%
+%% LTL
+%%
+\lst@definelanguage{LTL}%
+{morekeywords={U,V},%
+sensitive=true,
+literate=%
+{[]}{{\(\Box\)}}1%
+{=>}{{\(\Rightarrow\)}}2%
+{<>}{{\(\diamondsuit\)}}1%
+{-}{{\(\neg\)}}1%
+{()}{{\(\circ\)}}1%
+morecomment=[l]{\\*},%
+morestring=[d]",%
+commentstyle={\textit},%
+}[keywords,comments]%
+%%
+%% TLA
+%%
+\lst@definelanguage{TLA}%
+ {morekeywords={ASSUME, ELSE, LOCAL, UNION,
+ ASSUMPTION, ENABLED, MODULE, VARIABLE,
+ AXIOM, EXCEPT, OTHER, VARIABLES,
+ CASE, EXTENDS, SF_, WF_,
+ CHOOSE, IF, SUBSET, WITH,
+ CONSTANT, IN, THEN,
+ CONSTANTS , INSTANCE, THEOREM,
+ DOMAIN, LET, UNCHANGED},%
+ sensitive=true,
+ literate=%
+ {[]}{{\([\Box]\)}}1%
+ {>}{{\(>\)}}1%
+ {<}{{\(<\)}}1%
+ {->}{{\(\rightarrow\)}}1%
+ {|->}{{\(\mapsto\)}}1%
+ {<-}{{\(\leftarrow\)}}1%
+ {<--}{{\(\longleftarrow\)}}2%
+ {-->}{{\(\longrightarrow\)}}2%
+ {=>}{{\(\Rightarrow\)}}1%
+ {>=}{{\(\geq\)}}1%
+ {<=}{{\(\leq\)}}1%
+ {/\\}{{\(\land\)}}1%
+ {\\/}{{\(\lor\)}}1%
+ {\{\}}{{\(\emptyset\)}}1%
+ {not}{{\(\lnot\)}}1%
+ {\\E}{{\(\exists\)}}1%
+ {\\A}{{\(\forall\)}}1%
+ {\\in}{{\(\in\)}}1%
+ {::}{{\(:\!\in\)}}1%
+ {:=}{{:=}}1%
+ {<:}{{\(\subseteq\)}}1%
+ {<<:}{{\(\subset\)}}1%
+ {/=}{{\(\neq\)}}1%
+ {/:}{{\(\not\in\)}}1%
+ {==}{{\(\triangleq\)}}1%
+ {===}{{\(===\)}}1%
+ {\&}{{\(\land\)}}1,%
+ morecomment=[l]{\\*},%
+ morestring=[d]",%
+ commentstyle={\textit},%
+ }[keywords,comments]%
+%%
+%%
+%% FIACRE
+%%
+\lst@definelanguage{FIACRE}%
+ {morekeywords={bool, nat, int, interval, enum, end, record, array,
+ of, queue, type, is, true, false, new, not, full, empty,
+ dequeue, first, and, or, enqueue, none, channel, in, out, read,
+ write, process, states, init, var, priority, from, null, any,
+ where, while, do, if, then, elsif, else, select, unless, on, to, inf,
+ component, shuffle, sync, par, port, property, leadsto, within,
+ after, absent, wait, always, function, begin, loop,
+ return, union},%
+ sensitive=true,
+ literate=%
+ {->}{{\(\rightarrow\)}}1%
+ {-o}{{\(\multimap\,\)}}1%
+ {=>}{{\(\Rightarrow\)}}1%
+ {>=}{{\(\geq\)}}1%
+ {<=}{{\(\leq\)}}1%
+ {||}{{\(\parallel\)}}1%
+ {:=}{{\(:=\)}}1,%
+%% {[]}{{\(\Box\)~}}1,%
+ morecomment=[s]{/*}{*/},%
+ morestring=[d]",%
+ commentstyle={\textit},%
+ }[keywords,comments]%
+%%
+%% ALTARICA
+%%
+\lst@definelanguage{Altarica}%
+ {morekeywords={bool, nat, int, interval, enum, end, record, array,
+ of, queue, type, is, true, false, new, not, full, empty,
+ dequeue, first, and, or, enqueue, none, channel, in, out, read,
+ write, process, states, var, priority, from, null, any, case,
+ where, while, do, if, then, elsif, else, select, unless, on, to, inf,
+ component, sync, par, port, property, leadsto, within,
+ after, absent, always, extern, law,
+ trans, state, flow, domain, event, init, assert, node, edon,
+ case, else, reset},
+ emphstyle=\color{black}\bfseries,
+ sensitive=true,
+ literate=%
+ {->}{{\(\rightarrow\)\,}}1%
+ {-o}{{\(\multimap\,\)}}1%
+ {=>}{{\(\Rightarrow\)}}1%
+ {>=}{{\(\geq\)}}1%
+ {<=}{{\(\leq\)}}1%
+ {|-}{{\raisebox{-1pt}{\(\vdash\)}}}1%
+ {::=}{{\(\ ::=\ \)}}1%
+ {<>}{{\(\Diamond\)}}1,%
+%% {[]}{{\(\Box\)~}}1,%
+ morecomment=[s]{/*}{*/},%
+ morestring=[d]",%
+ commentstyle={\textit},%
+ }[keywords,comments]%
+%%
+%% BNF
+%%
+\lst@definelanguage{BNF}%
+ {morekeywords={bool, nat, int, type, is, union, end, null, if,
+ record, then, function, var, begin, return, process, states,
+ from, loop, on, select, component, par},
+ emphstyle=\color{black}\bfseries,
+ sensitive=true,
+ literate=%
+ {::=}{{\(\ ::=\ \)}}1%
+ {[[}{{\(\llbracket\)}}1%
+ {]]}{{\(\rrbracket\)}}1%
+ {->}{{\(\rightarrow\,\)}}1%
+ {v-}{{\(\vdash\)}}1%
+ {|}{{\(\ \mid\ \)}}1,%
+%% {[]}{{\(\Box\)~}}1,%
+ morecomment=[s]{/*}{*/},%
+ morestring=[d]",%
+ commentstyle={\textit},%
+ }[keywords,comments]%
+%%
+%%
+%%
+%% GenoM
+%%
+\lst@definelanguage{GenoM}%
+ {morekeywords={wcet, in, out, inout, port, codel, task, throw, int,
+ enum, ether, yield, activity, doc, validate, start, stop, ids,
+ interrupts, ms},%
+ sensitive=true,
+ morecomment=[s]{/*}{*/},%
+ morestring=[d]",%
+ commentstyle={\textit},%
+ }[keywords,comments]%
+\endinput
+
+
+
+
+
+
+%% End of file `lstlang3.sty'.
+
+
+
diff --git a/doc/Rapport post-doc/main.tex b/doc/Rapport post-doc/main.tex
new file mode 100644
index 0000000..e65d711
--- /dev/null
+++ b/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:
diff --git a/doc/Rapport post-doc/main.toc b/doc/Rapport post-doc/main.toc
new file mode 100644
index 0000000..63e105a
--- /dev/null
+++ b/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}
diff --git a/doc/Rapport post-doc/paper.bib b/doc/Rapport post-doc/paper.bib
new file mode 100644
index 0000000..0b8f83f
--- /dev/null
+++ b/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}}
+}
\ No newline at end of file
diff --git a/doc/Rapport post-doc/readme.txt b/doc/Rapport post-doc/readme.txt
new file mode 100644
index 0000000..47161bd
--- /dev/null
+++ b/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 )
+
+ 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
diff --git a/doc/Rapport post-doc/remreset.sty b/doc/Rapport post-doc/remreset.sty
new file mode 100644
index 0000000..b53de58
--- /dev/null
+++ b/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}}}
+
+
diff --git a/doc/Rapport post-doc/splncs03.bst b/doc/Rapport post-doc/splncs03.bst
new file mode 100644
index 0000000..3279169
--- /dev/null
+++ b/doc/Rapport post-doc/splncs03.bst
@@ -0,0 +1,1519 @@
+%% BibTeX bibliography style `splncs03'
+%%
+%% BibTeX bibliography style for use with numbered references in
+%% Springer Verlag's "Lecture Notes in Computer Science" series.
+%% (See Springer's documentation for llncs.cls for
+%% more details of the suggested reference format.) Note that this
+%% file will not work for author-year style citations.
+%%
+%% Use \documentclass{llncs} and \bibliographystyle{splncs03}, and cite
+%% a reference with (e.g.) \cite{smith77} to get a "[1]" in the text.
+%%
+%% This file comes to you courtesy of Maurizio "Titto" Patrignani of
+%% Dipartimento di Informatica e Automazione Universita' Roma Tre
+%%
+%% ================================================================================================
+%% This was file `titto-lncs-02.bst' produced on Wed Apr 1, 2009
+%% Edited by hand by titto based on `titto-lncs-01.bst' (see below)
+%%
+%% CHANGES (with respect to titto-lncs-01.bst):
+%% - Removed the call to \urlprefix (thus no "URL" string is added to the output)
+%% ================================================================================================
+%% This was file `titto-lncs-01.bst' produced on Fri Aug 22, 2008
+%% Edited by hand by titto based on `titto.bst' (see below)
+%%
+%% CHANGES (with respect to titto.bst):
+%% - Removed the "capitalize" command for editors string "(eds.)" and "(ed.)"
+%% - Introduced the functions titto.bbl.pages and titto.bbl.page for journal pages (without "pp.")
+%% - Added a new.sentence command to separate with a dot booktitle and series in the inproceedings
+%% - Commented all new.block commands before urls and notes (to separate them with a comma)
+%% - Introduced the functions titto.bbl.volume for handling journal volumes (without "vol." label)
+%% - Used for editors the same name conventions used for authors (see function format.in.ed.booktitle)
+%% - Removed a \newblock to avoid long spaces between title and "In: ..."
+%% - Added function titto.space.prefix to add a space instead of "~" after the (removed) "vol." label
+%% ================================================================================================
+%% This was file `titto.bst',
+%% generated with the docstrip utility.
+%%
+%% The original source files were:
+%%
+%% merlin.mbs (with options: `vonx,nm-rvvc,yr-par,jttl-rm,volp-com,jwdpg,jwdvol,numser,ser-vol,jnm-x,btit-rm,bt-rm,edparxc,bkedcap,au-col,in-col,fin-bare,pp,ed,abr,mth-bare,xedn,jabr,and-com,and-com-ed,xand,url,url-blk,em-x,nfss,')
+%% ----------------------------------------
+%% *** Tentative .bst file for Springer LNCS ***
+%%
+%% Copyright 1994-2007 Patrick W Daly
+ % ===============================================================
+ % IMPORTANT NOTICE:
+ % This bibliographic style (bst) file has been generated from one or
+ % more master bibliographic style (mbs) files, listed above.
+ %
+ % This generated file can be redistributed and/or modified under the terms
+ % of the LaTeX Project Public License Distributed from CTAN
+ % archives in directory macros/latex/base/lppl.txt; either
+ % version 1 of the License, or any later version.
+ % ===============================================================
+ % Name and version information of the main mbs file:
+ % \ProvidesFile{merlin.mbs}[2007/04/24 4.20 (PWD, AO, DPC)]
+ % For use with BibTeX version 0.99a or later
+ %-------------------------------------------------------------------
+ % This bibliography style file is intended for texts in ENGLISH
+ % This is a numerical citation style, and as such is standard LaTeX.
+ % It requires no extra package to interface to the main text.
+ % The form of the \bibitem entries is
+ % \bibitem{key}...
+ % Usage of \cite is as follows:
+ % \cite{key} ==>> [#]
+ % \cite[chap. 2]{key} ==>> [#, chap. 2]
+ % where # is a number determined by the ordering in the reference list.
+ % The order in the reference list is alphabetical by authors.
+ %---------------------------------------------------------------------
+
+ENTRY
+ { address
+ author
+ booktitle
+ chapter
+ edition
+ editor
+ eid
+ howpublished
+ institution
+ journal
+ key
+ month
+ note
+ number
+ organization
+ pages
+ publisher
+ school
+ series
+ title
+ type
+ url
+ volume
+ year
+ }
+ {}
+ { label }
+INTEGERS { output.state before.all mid.sentence after.sentence after.block }
+FUNCTION {init.state.consts}
+{ #0 'before.all :=
+ #1 'mid.sentence :=
+ #2 'after.sentence :=
+ #3 'after.block :=
+}
+STRINGS { s t}
+FUNCTION {output.nonnull}
+{ 's :=
+ output.state mid.sentence =
+ { ", " * write$ }
+ { output.state after.block =
+ { add.period$ write$
+% newline$
+% "\newblock " write$ % removed for titto-lncs-01
+ " " write$ % to avoid long spaces between title and "In: ..."
+ }
+ { output.state before.all =
+ 'write$
+ { add.period$ " " * write$ }
+ if$
+ }
+ if$
+ mid.sentence 'output.state :=
+ }
+ if$
+ s
+}
+FUNCTION {output}
+{ duplicate$ empty$
+ 'pop$
+ 'output.nonnull
+ if$
+}
+FUNCTION {output.check}
+{ 't :=
+ duplicate$ empty$
+ { pop$ "empty " t * " in " * cite$ * warning$ }
+ 'output.nonnull
+ if$
+}
+FUNCTION {fin.entry}
+{ duplicate$ empty$
+ 'pop$
+ 'write$
+ if$
+ newline$
+}
+
+FUNCTION {new.block}
+{ output.state before.all =
+ 'skip$
+ { after.block 'output.state := }
+ if$
+}
+FUNCTION {new.sentence}
+{ output.state after.block =
+ 'skip$
+ { output.state before.all =
+ 'skip$
+ { after.sentence 'output.state := }
+ if$
+ }
+ if$
+}
+FUNCTION {add.blank}
+{ " " * before.all 'output.state :=
+}
+
+
+FUNCTION {add.colon}
+{ duplicate$ empty$
+ 'skip$
+ { ":" * add.blank }
+ if$
+}
+
+FUNCTION {date.block}
+{
+ new.block
+}
+
+FUNCTION {not}
+{ { #0 }
+ { #1 }
+ if$
+}
+FUNCTION {and}
+{ 'skip$
+ { pop$ #0 }
+ if$
+}
+FUNCTION {or}
+{ { pop$ #1 }
+ 'skip$
+ if$
+}
+STRINGS {z}
+FUNCTION {remove.dots}
+{ 'z :=
+ ""
+ { z empty$ not }
+ { z #1 #1 substring$
+ z #2 global.max$ substring$ 'z :=
+ duplicate$ "." = 'pop$
+ { * }
+ if$
+ }
+ while$
+}
+FUNCTION {new.block.checka}
+{ empty$
+ 'skip$
+ 'new.block
+ if$
+}
+FUNCTION {new.block.checkb}
+{ empty$
+ swap$ empty$
+ and
+ 'skip$
+ 'new.block
+ if$
+}
+FUNCTION {new.sentence.checka}
+{ empty$
+ 'skip$
+ 'new.sentence
+ if$
+}
+FUNCTION {new.sentence.checkb}
+{ empty$
+ swap$ empty$
+ and
+ 'skip$
+ 'new.sentence
+ if$
+}
+FUNCTION {field.or.null}
+{ duplicate$ empty$
+ { pop$ "" }
+ 'skip$
+ if$
+}
+FUNCTION {emphasize}
+{ skip$ }
+FUNCTION {tie.or.space.prefix}
+{ duplicate$ text.length$ #3 <
+ { "~" }
+ { " " }
+ if$
+ swap$
+}
+FUNCTION {titto.space.prefix} % always introduce a space
+{ duplicate$ text.length$ #3 <
+ { " " }
+ { " " }
+ if$
+ swap$
+}
+
+
+FUNCTION {capitalize}
+{ "u" change.case$ "t" change.case$ }
+
+FUNCTION {space.word}
+{ " " swap$ * " " * }
+ % Here are the language-specific definitions for explicit words.
+ % Each function has a name bbl.xxx where xxx is the English word.
+ % The language selected here is ENGLISH
+FUNCTION {bbl.and}
+{ "and"}
+
+FUNCTION {bbl.etal}
+{ "et~al." }
+
+FUNCTION {bbl.editors}
+{ "eds." }
+
+FUNCTION {bbl.editor}
+{ "ed." }
+
+FUNCTION {bbl.edby}
+{ "edited by" }
+
+FUNCTION {bbl.edition}
+{ "edn." }
+
+FUNCTION {bbl.volume}
+{ "vol." }
+
+FUNCTION {titto.bbl.volume} % for handling journals
+{ "" }
+
+FUNCTION {bbl.of}
+{ "of" }
+
+FUNCTION {bbl.number}
+{ "no." }
+
+FUNCTION {bbl.nr}
+{ "no." }
+
+FUNCTION {bbl.in}
+{ "in" }
+
+FUNCTION {bbl.pages}
+{ "pp." }
+
+FUNCTION {bbl.page}
+{ "p." }
+
+FUNCTION {titto.bbl.pages} % for journals
+{ "" }
+
+FUNCTION {titto.bbl.page} % for journals
+{ "" }
+
+FUNCTION {bbl.chapter}
+{ "chap." }
+
+FUNCTION {bbl.techrep}
+{ "Tech. Rep." }
+
+FUNCTION {bbl.mthesis}
+{ "Master's thesis" }
+
+FUNCTION {bbl.phdthesis}
+{ "Ph.D. thesis" }
+
+MACRO {jan} {"Jan."}
+
+MACRO {feb} {"Feb."}
+
+MACRO {mar} {"Mar."}
+
+MACRO {apr} {"Apr."}
+
+MACRO {may} {"May"}
+
+MACRO {jun} {"Jun."}
+
+MACRO {jul} {"Jul."}
+
+MACRO {aug} {"Aug."}
+
+MACRO {sep} {"Sep."}
+
+MACRO {oct} {"Oct."}
+
+MACRO {nov} {"Nov."}
+
+MACRO {dec} {"Dec."}
+
+MACRO {acmcs} {"ACM Comput. Surv."}
+
+MACRO {acta} {"Acta Inf."}
+
+MACRO {cacm} {"Commun. ACM"}
+
+MACRO {ibmjrd} {"IBM J. Res. Dev."}
+
+MACRO {ibmsj} {"IBM Syst.~J."}
+
+MACRO {ieeese} {"IEEE Trans. Software Eng."}
+
+MACRO {ieeetc} {"IEEE Trans. Comput."}
+
+MACRO {ieeetcad}
+ {"IEEE Trans. Comput. Aid. Des."}
+
+MACRO {ipl} {"Inf. Process. Lett."}
+
+MACRO {jacm} {"J.~ACM"}
+
+MACRO {jcss} {"J.~Comput. Syst. Sci."}
+
+MACRO {scp} {"Sci. Comput. Program."}
+
+MACRO {sicomp} {"SIAM J. Comput."}
+
+MACRO {tocs} {"ACM Trans. Comput. Syst."}
+
+MACRO {tods} {"ACM Trans. Database Syst."}
+
+MACRO {tog} {"ACM Trans. Graphic."}
+
+MACRO {toms} {"ACM Trans. Math. Software"}
+
+MACRO {toois} {"ACM Trans. Office Inf. Syst."}
+
+MACRO {toplas} {"ACM Trans. Progr. Lang. Syst."}
+
+MACRO {tcs} {"Theor. Comput. Sci."}
+
+FUNCTION {bibinfo.check}
+{ swap$
+ duplicate$ missing$
+ {
+ pop$ pop$
+ ""
+ }
+ { duplicate$ empty$
+ {
+ swap$ pop$
+ }
+ { swap$
+ pop$
+ }
+ if$
+ }
+ if$
+}
+FUNCTION {bibinfo.warn}
+{ swap$
+ duplicate$ missing$
+ {
+ swap$ "missing " swap$ * " in " * cite$ * warning$ pop$
+ ""
+ }
+ { duplicate$ empty$
+ {
+ swap$ "empty " swap$ * " in " * cite$ * warning$
+ }
+ { swap$
+ pop$
+ }
+ if$
+ }
+ if$
+}
+FUNCTION {format.url}
+{ url empty$
+ { "" }
+% { "\urlprefix\url{" url * "}" * }
+ { "\url{" url * "}" * } % changed in titto-lncs-02.bst
+ if$
+}
+
+INTEGERS { nameptr namesleft numnames }
+
+
+STRINGS { bibinfo}
+
+FUNCTION {format.names}
+{ 'bibinfo :=
+ duplicate$ empty$ 'skip$ {
+ 's :=
+ "" 't :=
+ #1 'nameptr :=
+ s num.names$ 'numnames :=
+ numnames 'namesleft :=
+ { namesleft #0 > }
+ { s nameptr
+ "{vv~}{ll}{, jj}{, f{.}.}"
+ format.name$
+ bibinfo bibinfo.check
+ 't :=
+ nameptr #1 >
+ {
+ namesleft #1 >
+ { ", " * t * }
+ {
+ s nameptr "{ll}" format.name$ duplicate$ "others" =
+ { 't := }
+ { pop$ }
+ if$
+ "," *
+ t "others" =
+ {
+ " " * bbl.etal *
+ }
+ { " " * t * }
+ if$
+ }
+ if$
+ }
+ 't
+ if$
+ nameptr #1 + 'nameptr :=
+ namesleft #1 - 'namesleft :=
+ }
+ while$
+ } if$
+}
+FUNCTION {format.names.ed}
+{
+ 'bibinfo :=
+ duplicate$ empty$ 'skip$ {
+ 's :=
+ "" 't :=
+ #1 'nameptr :=
+ s num.names$ 'numnames :=
+ numnames 'namesleft :=
+ { namesleft #0 > }
+ { s nameptr
+ "{f{.}.~}{vv~}{ll}{ jj}"
+ format.name$
+ bibinfo bibinfo.check
+ 't :=
+ nameptr #1 >
+ {
+ namesleft #1 >
+ { ", " * t * }
+ {
+ s nameptr "{ll}" format.name$ duplicate$ "others" =
+ { 't := }
+ { pop$ }
+ if$
+ "," *
+ t "others" =
+ {
+
+ " " * bbl.etal *
+ }
+ { " " * t * }
+ if$
+ }
+ if$
+ }
+ 't
+ if$
+ nameptr #1 + 'nameptr :=
+ namesleft #1 - 'namesleft :=
+ }
+ while$
+ } if$
+}
+FUNCTION {format.authors}
+{ author "author" format.names
+}
+FUNCTION {get.bbl.editor}
+{ editor num.names$ #1 > 'bbl.editors 'bbl.editor if$ }
+
+FUNCTION {format.editors}
+{ editor "editor" format.names duplicate$ empty$ 'skip$
+ {
+ " " *
+ get.bbl.editor
+% capitalize
+ "(" swap$ * ")" *
+ *
+ }
+ if$
+}
+FUNCTION {format.note}
+{
+ note empty$
+ { "" }
+ { note #1 #1 substring$
+ duplicate$ "{" =
+ 'skip$
+ { output.state mid.sentence =
+ { "l" }
+ { "u" }
+ if$
+ change.case$
+ }
+ if$
+ note #2 global.max$ substring$ * "note" bibinfo.check
+ }
+ if$
+}
+
+FUNCTION {format.title}
+{ title
+ duplicate$ empty$ 'skip$
+ { "t" change.case$ }
+ if$
+ "title" bibinfo.check
+}
+FUNCTION {output.bibitem}
+{ newline$
+ "\bibitem{" write$
+ cite$ write$
+ "}" write$
+ newline$
+ ""
+ before.all 'output.state :=
+}
+
+FUNCTION {n.dashify}
+{
+ 't :=
+ ""
+ { t empty$ not }
+ { t #1 #1 substring$ "-" =
+ { t #1 #2 substring$ "--" = not
+ { "--" *
+ t #2 global.max$ substring$ 't :=
+ }
+ { { t #1 #1 substring$ "-" = }
+ { "-" *
+ t #2 global.max$ substring$ 't :=
+ }
+ while$
+ }
+ if$
+ }
+ { t #1 #1 substring$ *
+ t #2 global.max$ substring$ 't :=
+ }
+ if$
+ }
+ while$
+}
+
+FUNCTION {word.in}
+{ bbl.in capitalize
+ ":" *
+ " " * }
+
+FUNCTION {format.date}
+{
+ month "month" bibinfo.check
+ duplicate$ empty$
+ year "year" bibinfo.check duplicate$ empty$
+ { swap$ 'skip$
+ { "there's a month but no year in " cite$ * warning$ }
+ if$
+ *
+ }
+ { swap$ 'skip$
+ {
+ swap$
+ " " * swap$
+ }
+ if$
+ *
+ remove.dots
+ }
+ if$
+ duplicate$ empty$
+ 'skip$
+ {
+ before.all 'output.state :=
+ " (" swap$ * ")" *
+ }
+ if$
+}
+FUNCTION {format.btitle}
+{ title "title" bibinfo.check
+ duplicate$ empty$ 'skip$
+ {
+ }
+ if$
+}
+FUNCTION {either.or.check}
+{ empty$
+ 'pop$
+ { "can't use both " swap$ * " fields in " * cite$ * warning$ }
+ if$
+}
+FUNCTION {format.bvolume}
+{ volume empty$
+ { "" }
+ { bbl.volume volume tie.or.space.prefix
+ "volume" bibinfo.check * *
+ series "series" bibinfo.check
+ duplicate$ empty$ 'pop$
+ { emphasize ", " * swap$ * }
+ if$
+ "volume and number" number either.or.check
+ }
+ if$
+}
+FUNCTION {format.number.series}
+{ volume empty$
+ { number empty$
+ { series field.or.null }
+ { output.state mid.sentence =
+ { bbl.number }
+ { bbl.number capitalize }
+ if$
+ number tie.or.space.prefix "number" bibinfo.check * *
+ series empty$
+ { "there's a number but no series in " cite$ * warning$ }
+ { bbl.in space.word *
+ series "series" bibinfo.check *
+ }
+ if$
+ }
+ if$
+ }
+ { "" }
+ if$
+}
+
+FUNCTION {format.edition}
+{ edition duplicate$ empty$ 'skip$
+ {
+ output.state mid.sentence =
+ { "l" }
+ { "t" }
+ if$ change.case$
+ "edition" bibinfo.check
+ " " * bbl.edition *
+ }
+ if$
+}
+INTEGERS { multiresult }
+FUNCTION {multi.page.check}
+{ 't :=
+ #0 'multiresult :=
+ { multiresult not
+ t empty$ not
+ and
+ }
+ { t #1 #1 substring$
+ duplicate$ "-" =
+ swap$ duplicate$ "," =
+ swap$ "+" =
+ or or
+ { #1 'multiresult := }
+ { t #2 global.max$ substring$ 't := }
+ if$
+ }
+ while$
+ multiresult
+}
+FUNCTION {format.pages}
+{ pages duplicate$ empty$ 'skip$
+ { duplicate$ multi.page.check
+ {
+ bbl.pages swap$
+ n.dashify
+ }
+ {
+ bbl.page swap$
+ }
+ if$
+ tie.or.space.prefix
+ "pages" bibinfo.check
+ * *
+ }
+ if$
+}
+FUNCTION {format.journal.pages}
+{ pages duplicate$ empty$ 'pop$
+ { swap$ duplicate$ empty$
+ { pop$ pop$ format.pages }
+ {
+ ", " *
+ swap$
+ n.dashify
+ pages multi.page.check
+ 'titto.bbl.pages
+ 'titto.bbl.page
+ if$
+ swap$ tie.or.space.prefix
+ "pages" bibinfo.check
+ * *
+ *
+ }
+ if$
+ }
+ if$
+}
+FUNCTION {format.journal.eid}
+{ eid "eid" bibinfo.check
+ duplicate$ empty$ 'pop$
+ { swap$ duplicate$ empty$ 'skip$
+ {
+ ", " *
+ }
+ if$
+ swap$ *
+ }
+ if$
+}
+FUNCTION {format.vol.num.pages} % this function is used only for journal entries
+{ volume field.or.null
+ duplicate$ empty$ 'skip$
+ {
+% bbl.volume swap$ tie.or.space.prefix
+ titto.bbl.volume swap$ titto.space.prefix
+% rationale for the change above: for journals you don't want "vol." label
+% hence it does not make sense to attach the journal number to the label when
+% it is short
+ "volume" bibinfo.check
+ * *
+ }
+ if$
+ number "number" bibinfo.check duplicate$ empty$ 'skip$
+ {
+ swap$ duplicate$ empty$
+ { "there's a number but no volume in " cite$ * warning$ }
+ 'skip$
+ if$
+ swap$
+ "(" swap$ * ")" *
+ }
+ if$ *
+ eid empty$
+ { format.journal.pages }
+ { format.journal.eid }
+ if$
+}
+
+FUNCTION {format.chapter.pages}
+{ chapter empty$
+ 'format.pages
+ { type empty$
+ { bbl.chapter }
+ { type "l" change.case$
+ "type" bibinfo.check
+ }
+ if$
+ chapter tie.or.space.prefix
+ "chapter" bibinfo.check
+ * *
+ pages empty$
+ 'skip$
+ { ", " * format.pages * }
+ if$
+ }
+ if$
+}
+
+FUNCTION {format.booktitle}
+{
+ booktitle "booktitle" bibinfo.check
+}
+FUNCTION {format.in.ed.booktitle}
+{ format.booktitle duplicate$ empty$ 'skip$
+ {
+% editor "editor" format.names.ed duplicate$ empty$ 'pop$ % changed by titto
+ editor "editor" format.names duplicate$ empty$ 'pop$
+ {
+ " " *
+ get.bbl.editor
+% capitalize
+ "(" swap$ * ") " *
+ * swap$
+ * }
+ if$
+ word.in swap$ *
+ }
+ if$
+}
+FUNCTION {empty.misc.check}
+{ author empty$ title empty$ howpublished empty$
+ month empty$ year empty$ note empty$
+ and and and and and
+ key empty$ not and
+ { "all relevant fields are empty in " cite$ * warning$ }
+ 'skip$
+ if$
+}
+FUNCTION {format.thesis.type}
+{ type duplicate$ empty$
+ 'pop$
+ { swap$ pop$
+ "t" change.case$ "type" bibinfo.check
+ }
+ if$
+}
+FUNCTION {format.tr.number}
+{ number "number" bibinfo.check
+ type duplicate$ empty$
+ { pop$ bbl.techrep }
+ 'skip$
+ if$
+ "type" bibinfo.check
+ swap$ duplicate$ empty$
+ { pop$ "t" change.case$ }
+ { tie.or.space.prefix * * }
+ if$
+}
+FUNCTION {format.article.crossref}
+{
+ key duplicate$ empty$
+ { pop$
+ journal duplicate$ empty$
+ { "need key or journal for " cite$ * " to crossref " * crossref * warning$ }
+ { "journal" bibinfo.check emphasize word.in swap$ * }
+ if$
+ }
+ { word.in swap$ * " " *}
+ if$
+ " \cite{" * crossref * "}" *
+}
+FUNCTION {format.crossref.editor}
+{ editor #1 "{vv~}{ll}" format.name$
+ "editor" bibinfo.check
+ editor num.names$ duplicate$
+ #2 >
+ { pop$
+ "editor" bibinfo.check
+ " " * bbl.etal
+ *
+ }
+ { #2 <
+ 'skip$
+ { editor #2 "{ff }{vv }{ll}{ jj}" format.name$ "others" =
+ {
+ "editor" bibinfo.check
+ " " * bbl.etal
+ *
+ }
+ {
+ bbl.and space.word
+ * editor #2 "{vv~}{ll}" format.name$
+ "editor" bibinfo.check
+ *
+ }
+ if$
+ }
+ if$
+ }
+ if$
+}
+FUNCTION {format.book.crossref}
+{ volume duplicate$ empty$
+ { "empty volume in " cite$ * "'s crossref of " * crossref * warning$
+ pop$ word.in
+ }
+ { bbl.volume
+ capitalize
+ swap$ tie.or.space.prefix "volume" bibinfo.check * * bbl.of space.word *
+ }
+ if$
+ editor empty$
+ editor field.or.null author field.or.null =
+ or
+ { key empty$
+ { series empty$
+ { "need editor, key, or series for " cite$ * " to crossref " *
+ crossref * warning$
+ "" *
+ }
+ { series emphasize * }
+ if$
+ }
+ { key * }
+ if$
+ }
+ { format.crossref.editor * }
+ if$
+ " \cite{" * crossref * "}" *
+}
+FUNCTION {format.incoll.inproc.crossref}
+{
+ editor empty$
+ editor field.or.null author field.or.null =
+ or
+ { key empty$
+ { format.booktitle duplicate$ empty$
+ { "need editor, key, or booktitle for " cite$ * " to crossref " *
+ crossref * warning$
+ }
+ { word.in swap$ * }
+ if$
+ }
+ { word.in key * " " *}
+ if$
+ }
+ { word.in format.crossref.editor * " " *}
+ if$
+ " \cite{" * crossref * "}" *
+}
+FUNCTION {format.org.or.pub}
+{ 't :=
+ ""
+ address empty$ t empty$ and
+ 'skip$
+ {
+ t empty$
+ { address "address" bibinfo.check *
+ }
+ { t *
+ address empty$
+ 'skip$
+ { ", " * address "address" bibinfo.check * }
+ if$
+ }
+ if$
+ }
+ if$
+}
+FUNCTION {format.publisher.address}
+{ publisher "publisher" bibinfo.warn format.org.or.pub
+}
+
+FUNCTION {format.organization.address}
+{ organization "organization" bibinfo.check format.org.or.pub
+}
+
+FUNCTION {article}
+{ output.bibitem
+ format.authors "author" output.check
+ add.colon
+ new.block
+ format.title "title" output.check
+ new.block
+ crossref missing$
+ {
+ journal
+ "journal" bibinfo.check
+ "journal" output.check
+ add.blank
+ format.vol.num.pages output
+ format.date "year" output.check
+ }
+ { format.article.crossref output.nonnull
+ format.pages output
+ }
+ if$
+% new.block
+ format.url output
+% new.block
+ format.note output
+ fin.entry
+}
+FUNCTION {book}
+{ output.bibitem
+ author empty$
+ { format.editors "author and editor" output.check
+ add.colon
+ }
+ { format.authors output.nonnull
+ add.colon
+ crossref missing$
+ { "author and editor" editor either.or.check }
+ 'skip$
+ if$
+ }
+ if$
+ new.block
+ format.btitle "title" output.check
+ crossref missing$
+ { format.bvolume output
+ new.block
+ new.sentence
+ format.number.series output
+ format.publisher.address output
+ }
+ {
+ new.block
+ format.book.crossref output.nonnull
+ }
+ if$
+ format.edition output
+ format.date "year" output.check
+% new.block
+ format.url output
+% new.block
+ format.note output
+ fin.entry
+}
+FUNCTION {booklet}
+{ output.bibitem
+ format.authors output
+ add.colon
+ new.block
+ format.title "title" output.check
+ new.block
+ howpublished "howpublished" bibinfo.check output
+ address "address" bibinfo.check output
+ format.date output
+% new.block
+ format.url output
+% new.block
+ format.note output
+ fin.entry
+}
+
+FUNCTION {inbook}
+{ output.bibitem
+ author empty$
+ { format.editors "author and editor" output.check
+ add.colon
+ }
+ { format.authors output.nonnull
+ add.colon
+ crossref missing$
+ { "author and editor" editor either.or.check }
+ 'skip$
+ if$
+ }
+ if$
+ new.block
+ format.btitle "title" output.check
+ crossref missing$
+ {
+ format.bvolume output
+ format.chapter.pages "chapter and pages" output.check
+ new.block
+ new.sentence
+ format.number.series output
+ format.publisher.address output
+ }
+ {
+ format.chapter.pages "chapter and pages" output.check
+ new.block
+ format.book.crossref output.nonnull
+ }
+ if$
+ format.edition output
+ format.date "year" output.check
+% new.block
+ format.url output
+% new.block
+ format.note output
+ fin.entry
+}
+
+FUNCTION {incollection}
+{ output.bibitem
+ format.authors "author" output.check
+ add.colon
+ new.block
+ format.title "title" output.check
+ new.block
+ crossref missing$
+ { format.in.ed.booktitle "booktitle" output.check
+ format.bvolume output
+ format.chapter.pages output
+ new.sentence
+ format.number.series output
+ format.publisher.address output
+ format.edition output
+ format.date "year" output.check
+ }
+ { format.incoll.inproc.crossref output.nonnull
+ format.chapter.pages output
+ }
+ if$
+% new.block
+ format.url output
+% new.block
+ format.note output
+ fin.entry
+}
+FUNCTION {inproceedings}
+{ output.bibitem
+ format.authors "author" output.check
+ add.colon
+ new.block
+ format.title "title" output.check
+ new.block
+ crossref missing$
+ { format.in.ed.booktitle "booktitle" output.check
+ new.sentence % added by titto
+ format.bvolume output
+ format.pages output
+ new.sentence
+ format.number.series output
+ publisher empty$
+ { format.organization.address output }
+ { organization "organization" bibinfo.check output
+ format.publisher.address output
+ }
+ if$
+ format.date "year" output.check
+ }
+ { format.incoll.inproc.crossref output.nonnull
+ format.pages output
+ }
+ if$
+% new.block
+ format.url output
+% new.block
+ format.note output
+ fin.entry
+}
+FUNCTION {conference} { inproceedings }
+FUNCTION {manual}
+{ output.bibitem
+ author empty$
+ { organization "organization" bibinfo.check
+ duplicate$ empty$ 'pop$
+ { output
+ address "address" bibinfo.check output
+ }
+ if$
+ }
+ { format.authors output.nonnull }
+ if$
+ add.colon
+ new.block
+ format.btitle "title" output.check
+ author empty$
+ { organization empty$
+ {
+ address new.block.checka
+ address "address" bibinfo.check output
+ }
+ 'skip$
+ if$
+ }
+ {
+ organization address new.block.checkb
+ organization "organization" bibinfo.check output
+ address "address" bibinfo.check output
+ }
+ if$
+ format.edition output
+ format.date output
+% new.block
+ format.url output
+% new.block
+ format.note output
+ fin.entry
+}
+
+FUNCTION {mastersthesis}
+{ output.bibitem
+ format.authors "author" output.check
+ add.colon
+ new.block
+ format.btitle
+ "title" output.check
+ new.block
+ bbl.mthesis format.thesis.type output.nonnull
+ school "school" bibinfo.warn output
+ address "address" bibinfo.check output
+ format.date "year" output.check
+% new.block
+ format.url output
+% new.block
+ format.note output
+ fin.entry
+}
+
+FUNCTION {misc}
+{ output.bibitem
+ format.authors output
+ add.colon
+ title howpublished new.block.checkb
+ format.title output
+ howpublished new.block.checka
+ howpublished "howpublished" bibinfo.check output
+ format.date output
+% new.block
+ format.url output
+% new.block
+ format.note output
+ fin.entry
+ empty.misc.check
+}
+FUNCTION {phdthesis}
+{ output.bibitem
+ format.authors "author" output.check
+ add.colon
+ new.block
+ format.btitle
+ "title" output.check
+ new.block
+ bbl.phdthesis format.thesis.type output.nonnull
+ school "school" bibinfo.warn output
+ address "address" bibinfo.check output
+ format.date "year" output.check
+% new.block
+ format.url output
+% new.block
+ format.note output
+ fin.entry
+}
+
+FUNCTION {proceedings}
+{ output.bibitem
+ editor empty$
+ { organization "organization" bibinfo.check output
+ }
+ { format.editors output.nonnull }
+ if$
+ add.colon
+ new.block
+ format.btitle "title" output.check
+ format.bvolume output
+ editor empty$
+ { publisher empty$
+ { format.number.series output }
+ {
+ new.sentence
+ format.number.series output
+ format.publisher.address output
+ }
+ if$
+ }
+ { publisher empty$
+ {
+ new.sentence
+ format.number.series output
+ format.organization.address output }
+ {
+ new.sentence
+ format.number.series output
+ organization "organization" bibinfo.check output
+ format.publisher.address output
+ }
+ if$
+ }
+ if$
+ format.date "year" output.check
+% new.block
+ format.url output
+% new.block
+ format.note output
+ fin.entry
+}
+
+FUNCTION {techreport}
+{ output.bibitem
+ format.authors "author" output.check
+ add.colon
+ new.block
+ format.title
+ "title" output.check
+ new.block
+ format.tr.number output.nonnull
+ institution "institution" bibinfo.warn output
+ address "address" bibinfo.check output
+ format.date "year" output.check
+% new.block
+ format.url output
+% new.block
+ format.note output
+ fin.entry
+}
+
+FUNCTION {unpublished}
+{ output.bibitem
+ format.authors "author" output.check
+ add.colon
+ new.block
+ format.title "title" output.check
+ format.date output
+% new.block
+ format.url output
+% new.block
+ format.note "note" output.check
+ fin.entry
+}
+
+FUNCTION {default.type} { misc }
+READ
+FUNCTION {sortify}
+{ purify$
+ "l" change.case$
+}
+INTEGERS { len }
+FUNCTION {chop.word}
+{ 's :=
+ 'len :=
+ s #1 len substring$ =
+ { s len #1 + global.max$ substring$ }
+ 's
+ if$
+}
+FUNCTION {sort.format.names}
+{ 's :=
+ #1 'nameptr :=
+ ""
+ s num.names$ 'numnames :=
+ numnames 'namesleft :=
+ { namesleft #0 > }
+ { s nameptr
+ "{ll{ }}{ ff{ }}{ jj{ }}"
+ format.name$ 't :=
+ nameptr #1 >
+ {
+ " " *
+ namesleft #1 = t "others" = and
+ { "zzzzz" * }
+ { t sortify * }
+ if$
+ }
+ { t sortify * }
+ if$
+ nameptr #1 + 'nameptr :=
+ namesleft #1 - 'namesleft :=
+ }
+ while$
+}
+
+FUNCTION {sort.format.title}
+{ 't :=
+ "A " #2
+ "An " #3
+ "The " #4 t chop.word
+ chop.word
+ chop.word
+ sortify
+ #1 global.max$ substring$
+}
+FUNCTION {author.sort}
+{ author empty$
+ { key empty$
+ { "to sort, need author or key in " cite$ * warning$
+ ""
+ }
+ { key sortify }
+ if$
+ }
+ { author sort.format.names }
+ if$
+}
+FUNCTION {author.editor.sort}
+{ author empty$
+ { editor empty$
+ { key empty$
+ { "to sort, need author, editor, or key in " cite$ * warning$
+ ""
+ }
+ { key sortify }
+ if$
+ }
+ { editor sort.format.names }
+ if$
+ }
+ { author sort.format.names }
+ if$
+}
+FUNCTION {author.organization.sort}
+{ author empty$
+ { organization empty$
+ { key empty$
+ { "to sort, need author, organization, or key in " cite$ * warning$
+ ""
+ }
+ { key sortify }
+ if$
+ }
+ { "The " #4 organization chop.word sortify }
+ if$
+ }
+ { author sort.format.names }
+ if$
+}
+FUNCTION {editor.organization.sort}
+{ editor empty$
+ { organization empty$
+ { key empty$
+ { "to sort, need editor, organization, or key in " cite$ * warning$
+ ""
+ }
+ { key sortify }
+ if$
+ }
+ { "The " #4 organization chop.word sortify }
+ if$
+ }
+ { editor sort.format.names }
+ if$
+}
+FUNCTION {presort}
+{ type$ "book" =
+ type$ "inbook" =
+ or
+ 'author.editor.sort
+ { type$ "proceedings" =
+ 'editor.organization.sort
+ { type$ "manual" =
+ 'author.organization.sort
+ 'author.sort
+ if$
+ }
+ if$
+ }
+ if$
+ " "
+ *
+ year field.or.null sortify
+ *
+ " "
+ *
+ title field.or.null
+ sort.format.title
+ *
+ #1 entry.max$ substring$
+ 'sort.key$ :=
+}
+ITERATE {presort}
+SORT
+STRINGS { longest.label }
+INTEGERS { number.label longest.label.width }
+FUNCTION {initialize.longest.label}
+{ "" 'longest.label :=
+ #1 'number.label :=
+ #0 'longest.label.width :=
+}
+FUNCTION {longest.label.pass}
+{ number.label int.to.str$ 'label :=
+ number.label #1 + 'number.label :=
+ label width$ longest.label.width >
+ { label 'longest.label :=
+ label width$ 'longest.label.width :=
+ }
+ 'skip$
+ if$
+}
+EXECUTE {initialize.longest.label}
+ITERATE {longest.label.pass}
+FUNCTION {begin.bib}
+{ preamble$ empty$
+ 'skip$
+ { preamble$ write$ newline$ }
+ if$
+ "\begin{thebibliography}{" longest.label * "}" *
+ write$ newline$
+ "\providecommand{\url}[1]{\texttt{#1}}"
+ write$ newline$
+ "\providecommand{\urlprefix}{URL }"
+ write$ newline$
+}
+EXECUTE {begin.bib}
+EXECUTE {init.state.consts}
+ITERATE {call.type$}
+FUNCTION {end.bib}
+{ newline$
+ "\end{thebibliography}" write$ newline$
+}
+EXECUTE {end.bib}
+%% End of customized bst file
+%%
+%% End of file `titto.bst'.
+
+
diff --git a/doc/Rapport post-doc/sprmindx.sty b/doc/Rapport post-doc/sprmindx.sty
new file mode 100644
index 0000000..8f17772
--- /dev/null
+++ b/doc/Rapport post-doc/sprmindx.sty
@@ -0,0 +1,4 @@
+delim_0 "\\idxquad "
+delim_1 "\\idxquad "
+delim_2 "\\idxquad "
+delim_n ",\\,"
diff --git a/doc/Rapport post-doc/subjidx.ind b/doc/Rapport post-doc/subjidx.ind
new file mode 100644
index 0000000..cd678e8
--- /dev/null
+++ b/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}
diff --git a/doc/Rapport post-doc/tina.bib b/doc/Rapport post-doc/tina.bib
new file mode 100644
index 0000000..438a6a5
--- /dev/null
+++ b/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}
+}
\ No newline at end of file
diff --git a/doc/TODO b/doc/TODO
new file mode 100644
index 0000000..677a421
--- /dev/null
+++ b/doc/TODO
@@ -0,0 +1 @@
+nettoyer les diracs: on fait des calculs de proba des mev inutiles juste pour bouffer les diracs
\ No newline at end of file
diff --git a/doc/altarica-syntax.pdf b/doc/altarica-syntax.pdf
new file mode 100644
index 0000000..b413d7b
Binary files /dev/null and b/doc/altarica-syntax.pdf differ
diff --git a/doc/boundedcont.pdf b/doc/boundedcont.pdf
new file mode 100644
index 0000000..67b903f
Binary files /dev/null and b/doc/boundedcont.pdf differ
diff --git a/doc/cont.pdf b/doc/cont.pdf
new file mode 100644
index 0000000..8cb9f15
Binary files /dev/null and b/doc/cont.pdf differ
diff --git a/doc/quickstart.aux b/doc/quickstart.aux
new file mode 100644
index 0000000..1a8ce2d
--- /dev/null
+++ b/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}}
diff --git a/doc/quickstart.log b/doc/quickstart.log
new file mode 100644
index 0000000..bca5948
--- /dev/null
+++ b/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]
+File: cont.pdf Graphic file (type pdf)
+
+Package pdftex.def Info: cont.pdf used on input line 323.
+(pdftex.def) Requested size: 172.5pt x 128.6861pt.
+
+
+File: boundedcont.pdf Graphic file (type 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 []
+ []
+
+
+Overfull \hbox (7.75507pt too wide) in paragraph at lines 382--382
+[] \OT1/cmtt/m/n/8 []
+ []
+
+[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/amsfonts/cm/cmr10.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)
+
diff --git a/doc/quickstart.pdf b/doc/quickstart.pdf
new file mode 100644
index 0000000..591f018
Binary files /dev/null and b/doc/quickstart.pdf differ
diff --git a/doc/quickstart.tex b/doc/quickstart.tex
new file mode 100644
index 0000000..caff287
--- /dev/null
+++ b/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}
+
+
+
+ Rudder_BPS_RB
+ class
+
+
+
+
+
+
+
+
+ main.BCM
+
+
+
+
+
+
+
+
+\end{verbatim}
+}
+The user has to specify the nodes where init values has to be set,
+using the \verb?? tag.
+Inside a node, several fields have to be specified:
+\begin{itemize}
+\item \verb?node_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?instance ? is assumed as default)
+ \item a node definition (will affect all its instances). In
+ this case, the \verb?class ? has to be
+ added (\verb?Rudder_BPS_RB? example).
+ \end{itemize}
+\item \verb?? allows to change event law, specified by a list of
+ tags with the syntax \verb? ?; 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?? start a list of initial values stated with the
+ following general syntax:
+ \verb? ?, 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}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+\end{verbatim}
+}
+
+\end{document}
diff --git a/icons/document-build-model-16.xpm b/icons/document-build-model-16.xpm
new file mode 100644
index 0000000..3c722d4
--- /dev/null
+++ b/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. ",
+" "};
diff --git a/icons/document-build-model-24.xpm b/icons/document-build-model-24.xpm
new file mode 100644
index 0000000..014cefb
--- /dev/null
+++ b/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@ ",
+" ",
+" "};
diff --git a/icons/document-switch-mode-16.xpm b/icons/document-switch-mode-16.xpm
new file mode 100644
index 0000000..924a29a
--- /dev/null
+++ b/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 ",
+" ",
+" ",
+" "};
diff --git a/icons/document-switch-mode-24.xpm b/icons/document-switch-mode-24.xpm
new file mode 100644
index 0000000..cb68653
--- /dev/null
+++ 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 ",
+" # ",
+" ",
+" ",
+" ",
+" "};
diff --git a/sdk/CMakeLists.txt b/sdk/CMakeLists.txt
new file mode 100644
index 0000000..4c238e8
--- /dev/null
+++ b/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 .
+
+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)
+
diff --git a/sdk/boost/numeric/bindings/addressing_index.hpp b/sdk/boost/numeric/bindings/addressing_index.hpp
new file mode 100644
index 0000000..5c4256b
--- /dev/null
+++ b/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
+#include
+#include
+#include
+
+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
diff --git a/sdk/boost/numeric/bindings/at.hpp b/sdk/boost/numeric/bindings/at.hpp
new file mode 100644
index 0000000..7b1eda5
--- /dev/null
+++ b/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
+
+namespace boost {
+namespace numeric {
+namespace bindings {
+namespace detail {
+
+template< typename T, typename Enable = void >
+struct at_impl {
+
+ typedef typename bindings::value_type::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 >::type > {
+
+ typedef typename bindings::value_type::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::result_type type;
+};
+
+}
+
+template< typename T >
+typename result_of::at::type at( T& t, const std::ptrdiff_t i1 ) {
+ return detail::at_impl::invoke( t, i1 );
+}
+
+template< typename T >
+typename result_of::at::type at( T& t, const std::ptrdiff_t i1, const std::ptrdiff_t i2 ) {
+ return detail::at_impl::invoke( t, i1, i2 );
+}
+
+} // bindings
+} // numeric
+} // boost
+
+#endif
diff --git a/sdk/boost/numeric/bindings/bandwidth.hpp b/sdk/boost/numeric/bindings/bandwidth.hpp
new file mode 100644
index 0000000..c489c66
--- /dev/null
+++ b/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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+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,
+ typename boost::enable_if< typename mpl::and_<
+ mpl::greater< tag::addressing_index, rank >,
+ 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 >::invoke(t), 1 );
+ }
+
+};
+
+template< typename T, int N >
+struct bandwidth_impl< T, tag::addressing_index,
+ typename boost::enable_if< typename mpl::and_<
+ mpl::greater< tag::addressing_index, rank >,
+ 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::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, 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 )
+
+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::type )
+GENERATE_FUNCTIONS( bandwidth, _minor, typename addressing_index_minor::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
diff --git a/sdk/boost/numeric/bindings/begin.hpp b/sdk/boost/numeric/bindings/begin.hpp
new file mode 100644
index 0000000..8beda8d
--- /dev/null
+++ b/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
+#include
+#include
+#include
+#include
+#include
+#include
+
+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::begin_value( t );
+ }
+};
+
+template< typename T, int Dimension >
+struct begin_impl > {
+
+ typedef tag::addressing_index 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::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::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::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::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::value) );
+ typedef typename detail::begin_impl::result_type type;
+};
+
+} // namespace result_of
+
+//
+// Free Functions
+//
+
+//
+// Overloads like begin( t, tag )
+//
+template< typename T, typename Tag >
+inline typename result_of::begin::type
+begin( T& t, Tag ) {
+ return detail::begin_impl::invoke( t );
+}
+
+template< typename T, typename Tag >
+inline typename result_of::begin::type
+begin( const T& t, Tag ) {
+ return detail::begin_impl::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, 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, 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 )
+
+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
diff --git a/sdk/boost/numeric/bindings/blas.hpp b/sdk/boost/numeric/bindings/blas.hpp
new file mode 100644
index 0000000..71f7eb7
--- /dev/null
+++ b/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
+#include
+#include
+
+#endif
+
diff --git a/sdk/boost/numeric/bindings/blas/detail/blas.h b/sdk/boost/numeric/bindings/blas/detail/blas.h
new file mode 100644
index 0000000..54bd711
--- /dev/null
+++ b/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
+
+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 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 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 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 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
+
diff --git a/sdk/boost/numeric/bindings/blas/detail/blas_names.h b/sdk/boost/numeric/bindings/blas/detail/blas_names.h
new file mode 100644
index 0000000..98de1a5
--- /dev/null
+++ b/sdk/boost/numeric/bindings/blas/detail/blas_names.h
@@ -0,0 +1,275 @@
+//
+// 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_NAMES_H
+#define BOOST_NUMERIC_BINDINGS_BLAS_DETAIL_BLAS_NAMES_H
+
+#include
+
+//
+// BLAS level1 routines
+//
+
+// Value-type variants of asum
+#define BLAS_SASUM FORTRAN_ID2( sasum, SASUM )
+#define BLAS_DASUM FORTRAN_ID2( dasum, DASUM )
+#define BLAS_SCASUM FORTRAN_ID2( scasum, SCASUM )
+#define BLAS_DZASUM FORTRAN_ID2( dzasum, DZASUM )
+
+// Value-type variants of axpy
+#define BLAS_SAXPY FORTRAN_ID2( saxpy, SAXPY )
+#define BLAS_DAXPY FORTRAN_ID2( daxpy, DAXPY )
+#define BLAS_CAXPY FORTRAN_ID2( caxpy, CAXPY )
+#define BLAS_ZAXPY FORTRAN_ID2( zaxpy, ZAXPY )
+
+// Value-type variants of copy
+#define BLAS_SCOPY FORTRAN_ID2( scopy, SCOPY )
+#define BLAS_DCOPY FORTRAN_ID2( dcopy, DCOPY )
+#define BLAS_CCOPY FORTRAN_ID2( ccopy, CCOPY )
+#define BLAS_ZCOPY FORTRAN_ID2( zcopy, ZCOPY )
+
+// Value-type variants of dot
+#define BLAS_SDOT FORTRAN_ID2( sdot, SDOT )
+#define BLAS_DDOT FORTRAN_ID2( ddot, DDOT )
+#define BLAS_CDOTU FORTRAN_ID2( cdotu, CDOTU )
+#define BLAS_ZDOTU FORTRAN_ID2( zdotu, ZDOTU )
+
+// Value-type variants of dotc
+#define BLAS_CDOTC FORTRAN_ID2( cdotc, CDOTC )
+#define BLAS_ZDOTC FORTRAN_ID2( zdotc, ZDOTC )
+
+// Value-type variants of iamax
+#define BLAS_ISAMAX FORTRAN_ID2( isamax, ISAMAX )
+#define BLAS_IDAMAX FORTRAN_ID2( idamax, IDAMAX )
+#define BLAS_ICAMAX FORTRAN_ID2( icamax, ICAMAX )
+#define BLAS_IZAMAX FORTRAN_ID2( izamax, IZAMAX )
+
+// Value-type variants of nrm2
+#define BLAS_SNRM2 FORTRAN_ID2( snrm2, SNRM2 )
+#define BLAS_DNRM2 FORTRAN_ID2( dnrm2, DNRM2 )
+#define BLAS_SCNRM2 FORTRAN_ID2( scnrm2, SCNRM2 )
+#define BLAS_DZNRM2 FORTRAN_ID2( dznrm2, DZNRM2 )
+
+// Value-type variants of prec_dot
+#define BLAS_DSDOT FORTRAN_ID2( dsdot, DSDOT )
+
+// Value-type variants of rot
+#define BLAS_SROT FORTRAN_ID2( srot, SROT )
+#define BLAS_DROT FORTRAN_ID2( drot, DROT )
+#define BLAS_CSROT FORTRAN_ID2( csrot, CSROT )
+#define BLAS_ZDROT FORTRAN_ID2( zdrot, ZDROT )
+
+// Value-type variants of rotg
+#define BLAS_SROTG FORTRAN_ID2( srotg, SROTG )
+#define BLAS_DROTG FORTRAN_ID2( drotg, DROTG )
+#define BLAS_CROTG FORTRAN_ID2( crotg, CROTG )
+#define BLAS_ZROTG FORTRAN_ID2( zrotg, ZROTG )
+
+// Value-type variants of rotm
+#define BLAS_SROTM FORTRAN_ID2( srotm, SROTM )
+#define BLAS_DROTM FORTRAN_ID2( drotm, DROTM )
+
+// Value-type variants of rotmg
+#define BLAS_SROTMG FORTRAN_ID2( srotmg, SROTMG )
+#define BLAS_DROTMG FORTRAN_ID2( drotmg, DROTMG )
+
+// Value-type variants of scal
+#define BLAS_SSCAL FORTRAN_ID2( sscal, SSCAL )
+#define BLAS_DSCAL FORTRAN_ID2( dscal, DSCAL )
+#define BLAS_CSSCAL FORTRAN_ID2( csscal, CSSCAL )
+#define BLAS_ZDSCAL FORTRAN_ID2( zdscal, ZDSCAL )
+#define BLAS_CSCAL FORTRAN_ID2( cscal, CSCAL )
+#define BLAS_ZSCAL FORTRAN_ID2( zscal, ZSCAL )
+
+// Value-type variants of swap
+#define BLAS_SSWAP FORTRAN_ID2( sswap, SSWAP )
+#define BLAS_DSWAP FORTRAN_ID2( dswap, DSWAP )
+#define BLAS_CSWAP FORTRAN_ID2( cswap, CSWAP )
+#define BLAS_ZSWAP FORTRAN_ID2( zswap, ZSWAP )
+
+//
+// BLAS level2 routines
+//
+
+// Value-type variants of gbmv
+#define BLAS_SGBMV FORTRAN_ID2( sgbmv, SGBMV )
+#define BLAS_DGBMV FORTRAN_ID2( dgbmv, DGBMV )
+#define BLAS_CGBMV FORTRAN_ID2( cgbmv, CGBMV )
+#define BLAS_ZGBMV FORTRAN_ID2( zgbmv, ZGBMV )
+
+// Value-type variants of gemv
+#define BLAS_SGEMV FORTRAN_ID2( sgemv, SGEMV )
+#define BLAS_DGEMV FORTRAN_ID2( dgemv, DGEMV )
+#define BLAS_CGEMV FORTRAN_ID2( cgemv, CGEMV )
+#define BLAS_ZGEMV FORTRAN_ID2( zgemv, ZGEMV )
+
+// Value-type variants of ger
+#define BLAS_SGER FORTRAN_ID2( sger, SGER )
+#define BLAS_DGER FORTRAN_ID2( dger, DGER )
+
+// Value-type variants of gerc
+#define BLAS_CGERC FORTRAN_ID2( cgerc, CGERC )
+#define BLAS_ZGERC FORTRAN_ID2( zgerc, ZGERC )
+
+// Value-type variants of geru
+#define BLAS_CGERU FORTRAN_ID2( cgeru, CGERU )
+#define BLAS_ZGERU FORTRAN_ID2( zgeru, ZGERU )
+
+// Value-type variants of hbmv
+#define BLAS_CHBMV FORTRAN_ID2( chbmv, CHBMV )
+#define BLAS_ZHBMV FORTRAN_ID2( zhbmv, ZHBMV )
+
+// Value-type variants of hemv
+#define BLAS_CHEMV FORTRAN_ID2( chemv, CHEMV )
+#define BLAS_ZHEMV FORTRAN_ID2( zhemv, ZHEMV )
+
+// Value-type variants of her
+#define BLAS_CHER FORTRAN_ID2( cher, CHER )
+#define BLAS_ZHER FORTRAN_ID2( zher, ZHER )
+
+// Value-type variants of her2
+#define BLAS_CHER2 FORTRAN_ID2( cher2, CHER2 )
+#define BLAS_ZHER2 FORTRAN_ID2( zher2, ZHER2 )
+
+// Value-type variants of hpmv
+#define BLAS_CHPMV FORTRAN_ID2( chpmv, CHPMV )
+#define BLAS_ZHPMV FORTRAN_ID2( zhpmv, ZHPMV )
+
+// Value-type variants of hpr
+#define BLAS_CHPR FORTRAN_ID2( chpr, CHPR )
+#define BLAS_ZHPR FORTRAN_ID2( zhpr, ZHPR )
+
+// Value-type variants of hpr2
+#define BLAS_CHPR2 FORTRAN_ID2( chpr2, CHPR2 )
+#define BLAS_ZHPR2 FORTRAN_ID2( zhpr2, ZHPR2 )
+
+// Value-type variants of sbmv
+#define BLAS_SSBMV FORTRAN_ID2( ssbmv, SSBMV )
+#define BLAS_DSBMV FORTRAN_ID2( dsbmv, DSBMV )
+
+// Value-type variants of spmv
+#define BLAS_SSPMV FORTRAN_ID2( sspmv, SSPMV )
+#define BLAS_DSPMV FORTRAN_ID2( dspmv, DSPMV )
+
+// Value-type variants of spr
+#define BLAS_SSPR FORTRAN_ID2( sspr, SSPR )
+#define BLAS_DSPR FORTRAN_ID2( dspr, DSPR )
+
+// Value-type variants of spr2
+#define BLAS_SSPR2 FORTRAN_ID2( sspr2, SSPR2 )
+#define BLAS_DSPR2 FORTRAN_ID2( dspr2, DSPR2 )
+
+// Value-type variants of symv
+#define BLAS_SSYMV FORTRAN_ID2( ssymv, SSYMV )
+#define BLAS_DSYMV FORTRAN_ID2( dsymv, DSYMV )
+
+// Value-type variants of syr
+#define BLAS_SSYR FORTRAN_ID2( ssyr, SSYR )
+#define BLAS_DSYR FORTRAN_ID2( dsyr, DSYR )
+
+// Value-type variants of syr2
+#define BLAS_SSYR2 FORTRAN_ID2( ssyr2, SSYR2 )
+#define BLAS_DSYR2 FORTRAN_ID2( dsyr2, DSYR2 )
+
+// Value-type variants of tbmv
+#define BLAS_STBMV FORTRAN_ID2( stbmv, STBMV )
+#define BLAS_DTBMV FORTRAN_ID2( dtbmv, DTBMV )
+#define BLAS_CTBMV FORTRAN_ID2( ctbmv, CTBMV )
+#define BLAS_ZTBMV FORTRAN_ID2( ztbmv, ZTBMV )
+
+// Value-type variants of tbsv
+#define BLAS_STBSV FORTRAN_ID2( stbsv, STBSV )
+#define BLAS_DTBSV FORTRAN_ID2( dtbsv, DTBSV )
+#define BLAS_CTBSV FORTRAN_ID2( ctbsv, CTBSV )
+#define BLAS_ZTBSV FORTRAN_ID2( ztbsv, ZTBSV )
+
+// Value-type variants of tpmv
+#define BLAS_STPMV FORTRAN_ID2( stpmv, STPMV )
+#define BLAS_DTPMV FORTRAN_ID2( dtpmv, DTPMV )
+#define BLAS_CTPMV FORTRAN_ID2( ctpmv, CTPMV )
+#define BLAS_ZTPMV FORTRAN_ID2( ztpmv, ZTPMV )
+
+// Value-type variants of tpsv
+#define BLAS_STPSV FORTRAN_ID2( stpsv, STPSV )
+#define BLAS_DTPSV FORTRAN_ID2( dtpsv, DTPSV )
+#define BLAS_CTPSV FORTRAN_ID2( ctpsv, CTPSV )
+#define BLAS_ZTPSV FORTRAN_ID2( ztpsv, ZTPSV )
+
+// Value-type variants of trmv
+#define BLAS_STRMV FORTRAN_ID2( strmv, STRMV )
+#define BLAS_DTRMV FORTRAN_ID2( dtrmv, DTRMV )
+#define BLAS_CTRMV FORTRAN_ID2( ctrmv, CTRMV )
+#define BLAS_ZTRMV FORTRAN_ID2( ztrmv, ZTRMV )
+
+// Value-type variants of trsv
+#define BLAS_STRSV FORTRAN_ID2( strsv, STRSV )
+#define BLAS_DTRSV FORTRAN_ID2( dtrsv, DTRSV )
+#define BLAS_CTRSV FORTRAN_ID2( ctrsv, CTRSV )
+#define BLAS_ZTRSV FORTRAN_ID2( ztrsv, ZTRSV )
+
+//
+// BLAS level3 routines
+//
+
+// Value-type variants of gemm
+#define BLAS_SGEMM FORTRAN_ID2( sgemm, SGEMM )
+#define BLAS_DGEMM FORTRAN_ID2( dgemm, DGEMM )
+#define BLAS_CGEMM FORTRAN_ID2( cgemm, CGEMM )
+#define BLAS_ZGEMM FORTRAN_ID2( zgemm, ZGEMM )
+
+// Value-type variants of hemm
+#define BLAS_CHEMM FORTRAN_ID2( chemm, CHEMM )
+#define BLAS_ZHEMM FORTRAN_ID2( zhemm, ZHEMM )
+
+// Value-type variants of her2k
+#define BLAS_CHER2K FORTRAN_ID2( cher2k, CHER2K )
+#define BLAS_ZHER2K FORTRAN_ID2( zher2k, ZHER2K )
+
+// Value-type variants of herk
+#define BLAS_CHERK FORTRAN_ID2( cherk, CHERK )
+#define BLAS_ZHERK FORTRAN_ID2( zherk, ZHERK )
+
+// Value-type variants of symm
+#define BLAS_SSYMM FORTRAN_ID2( ssymm, SSYMM )
+#define BLAS_DSYMM FORTRAN_ID2( dsymm, DSYMM )
+#define BLAS_CSYMM FORTRAN_ID2( csymm, CSYMM )
+#define BLAS_ZSYMM FORTRAN_ID2( zsymm, ZSYMM )
+
+// Value-type variants of syr2k
+#define BLAS_SSYR2K FORTRAN_ID2( ssyr2k, SSYR2K )
+#define BLAS_DSYR2K FORTRAN_ID2( dsyr2k, DSYR2K )
+#define BLAS_CSYR2K FORTRAN_ID2( csyr2k, CSYR2K )
+#define BLAS_ZSYR2K FORTRAN_ID2( zsyr2k, ZSYR2K )
+
+// Value-type variants of syrk
+#define BLAS_SSYRK FORTRAN_ID2( ssyrk, SSYRK )
+#define BLAS_DSYRK FORTRAN_ID2( dsyrk, DSYRK )
+#define BLAS_CSYRK FORTRAN_ID2( csyrk, CSYRK )
+#define BLAS_ZSYRK FORTRAN_ID2( zsyrk, ZSYRK )
+
+// Value-type variants of trmm
+#define BLAS_STRMM FORTRAN_ID2( strmm, STRMM )
+#define BLAS_DTRMM FORTRAN_ID2( dtrmm, DTRMM )
+#define BLAS_CTRMM FORTRAN_ID2( ctrmm, CTRMM )
+#define BLAS_ZTRMM FORTRAN_ID2( ztrmm, ZTRMM )
+
+// Value-type variants of trsm
+#define BLAS_STRSM FORTRAN_ID2( strsm, STRSM )
+#define BLAS_DTRSM FORTRAN_ID2( dtrsm, DTRSM )
+#define BLAS_CTRSM FORTRAN_ID2( ctrsm, CTRSM )
+#define BLAS_ZTRSM FORTRAN_ID2( ztrsm, ZTRSM )
+
+
+
+#endif
+
diff --git a/sdk/boost/numeric/bindings/blas/detail/blas_option.hpp b/sdk/boost/numeric/bindings/blas/detail/blas_option.hpp
new file mode 100644
index 0000000..b27440a
--- /dev/null
+++ b/sdk/boost/numeric/bindings/blas/detail/blas_option.hpp
@@ -0,0 +1,57 @@
+//
+// 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_DETAIL_BLAS_OPTION_HPP
+#define BOOST_NUMERIC_BINDINGS_BLAS_DETAIL_BLAS_OPTION_HPP
+
+#include
+#include
+
+namespace boost {
+namespace numeric {
+namespace bindings {
+namespace blas {
+namespace detail {
+
+template< typename Tag >
+struct blas_option {};
+
+template<>
+struct blas_option< tag::transpose >: mpl::char_< 'T' > {};
+
+template<>
+struct blas_option< tag::no_transpose >: mpl::char_< 'N' > {};
+
+template<>
+struct blas_option< tag::conjugate >: mpl::char_< 'C' > {};
+
+template<>
+struct blas_option< tag::upper >: mpl::char_< 'U' > {};
+
+template<>
+struct blas_option< tag::lower >: mpl::char_< 'L' > {};
+
+template<>
+struct blas_option< tag::unit >: mpl::char_< 'U' > {};
+
+template<>
+struct blas_option< tag::non_unit >: mpl::char_< 'N' > {};
+
+template<>
+struct blas_option< tag::left >: mpl::char_< 'L' > {};
+
+template<>
+struct blas_option< tag::right >: mpl::char_< 'R' > {};
+
+} // namespace detail
+} // namespace blas
+} // namespace bindings
+} // namespace numeric
+} // namespace boost
+
+#endif
diff --git a/sdk/boost/numeric/bindings/blas/detail/cblas.h b/sdk/boost/numeric/bindings/blas/detail/cblas.h
new file mode 100644
index 0000000..e4194dc
--- /dev/null
+++ b/sdk/boost/numeric/bindings/blas/detail/cblas.h
@@ -0,0 +1,41 @@
+/*
+ *
+ * Copyright (c) Kresimir Fresl 2002
+ *
+ * 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)
+ *
+ * Author acknowledges the support of the Faculty of Civil Engineering,
+ * University of Zagreb, Croatia.
+ *
+ */
+
+#ifndef BOOST_NUMERIC_BINDINGS_BLAS_DETAIL_CBLAS_H
+#define BOOST_NUMERIC_BINDINGS_BLAS_DETAIL_CBLAS_H
+
+//
+// MKL-specific CBLAS include
+//
+#if defined BOOST_NUMERIC_BINDINGS_BLAS_MKL
+
+extern "C" {
+#include
+#include
+//
+// mkl_types.h defines P4 macro which breaks MPL, undefine it here.
+//
+#undef P4
+}
+
+//
+// Default CBLAS include
+//
+#else
+
+extern "C" {
+#include
+}
+
+#endif
+#endif
diff --git a/sdk/boost/numeric/bindings/blas/detail/cblas_option.hpp b/sdk/boost/numeric/bindings/blas/detail/cblas_option.hpp
new file mode 100644
index 0000000..19420d1
--- /dev/null
+++ b/sdk/boost/numeric/bindings/blas/detail/cblas_option.hpp
@@ -0,0 +1,85 @@
+//
+// 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_DETAIL_CBLAS_OPTION_HPP
+#define BOOST_NUMERIC_BINDINGS_BLAS_DETAIL_CBLAS_OPTION_HPP
+
+#include
+#include
+
+namespace boost {
+namespace numeric {
+namespace bindings {
+namespace blas {
+namespace detail {
+
+template< typename Tag >
+struct cblas_option {};
+
+template<>
+struct cblas_option< tag::row_major > {
+ static const CBLAS_ORDER value = CblasRowMajor;
+};
+
+template<>
+struct cblas_option< tag::column_major > {
+ static const CBLAS_ORDER value = CblasColMajor;
+};
+
+template<>
+struct cblas_option< tag::transpose > {
+ static const CBLAS_TRANSPOSE value = CblasTrans;
+};
+
+template<>
+struct cblas_option< tag::no_transpose > {
+ static const CBLAS_TRANSPOSE value = CblasNoTrans;
+};
+
+template<>
+struct cblas_option< tag::conjugate > {
+ static const CBLAS_TRANSPOSE value = CblasConjTrans;
+};
+
+template<>
+struct cblas_option< tag::upper > {
+ static const CBLAS_UPLO value = CblasUpper;
+};
+
+template<>
+struct cblas_option< tag::lower > {
+ static const CBLAS_UPLO value = CblasLower;
+};
+
+template<>
+struct cblas_option< tag::unit > {
+ static const CBLAS_DIAG value = CblasUnit;
+};
+
+template<>
+struct cblas_option< tag::non_unit > {
+ static const CBLAS_DIAG value = CblasNonUnit;
+};
+
+template<>
+struct cblas_option< tag::left > {
+ static const CBLAS_SIDE value = CblasLeft;
+};
+
+template<>
+struct cblas_option< tag::right > {
+ static const CBLAS_SIDE value = CblasRight;
+};
+
+} // namespace detail
+} // namespace blas
+} // namespace bindings
+} // namespace numeric
+} // namespace boost
+
+#endif
diff --git a/sdk/boost/numeric/bindings/blas/detail/cublas.h b/sdk/boost/numeric/bindings/blas/detail/cublas.h
new file mode 100644
index 0000000..0f46bcb
--- /dev/null
+++ b/sdk/boost/numeric/bindings/blas/detail/cublas.h
@@ -0,0 +1,16 @@
+//
+// 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_DETAIL_CUBLAS_H
+#define BOOST_NUMERIC_BINDINGS_BLAS_DETAIL_CUBLAS_H
+
+extern "C" {
+#include
+}
+
+#endif
diff --git a/sdk/boost/numeric/bindings/blas/detail/default_order.hpp b/sdk/boost/numeric/bindings/blas/detail/default_order.hpp
new file mode 100644
index 0000000..7d3f176
--- /dev/null
+++ b/sdk/boost/numeric/bindings/blas/detail/default_order.hpp
@@ -0,0 +1,38 @@
+//
+// 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_DETAIL_DEFAULT_ORDER_HPP
+#define BOOST_NUMERIC_BINDINGS_BLAS_DETAIL_DEFAULT_ORDER_HPP
+
+#include
+#include
+#include
+#include
+
+namespace boost {
+namespace numeric {
+namespace bindings {
+namespace blas {
+namespace detail {
+
+template< typename T >
+struct default_order {
+ typedef typename mpl::if_<
+ bindings::detail::is_same_at< T, tag::value_transform, tag::conjugate >,
+ typename mpl::if_< is_row_major< T >, tag::column_major, tag::row_major >::type,
+ tag::column_major
+ >::type type;
+};
+
+} // namespace detail
+} // namespace blas
+} // namespace bindings
+} // namespace numeric
+} // namespace boost
+
+#endif
diff --git a/sdk/boost/numeric/bindings/blas/level1.hpp b/sdk/boost/numeric/bindings/blas/level1.hpp
new file mode 100644
index 0000000..54e8bc5
--- /dev/null
+++ b/sdk/boost/numeric/bindings/blas/level1.hpp
@@ -0,0 +1,29 @@
+//
+// 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_LEVEL1_HPP
+#define BOOST_NUMERIC_BINDINGS_BLAS_LEVEL1_HPP
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#endif
diff --git a/sdk/boost/numeric/bindings/blas/level1/asum.hpp b/sdk/boost/numeric/bindings/blas/level1/asum.hpp
new file mode 100644
index 0000000..a7e3ea4
--- /dev/null
+++ b/sdk/boost/numeric/bindings/blas/level1/asum.hpp
@@ -0,0 +1,230 @@
+//
+// Copyright (c) 2002--2010
+// 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_LEVEL1_ASUM_HPP
+#define BOOST_NUMERIC_BINDINGS_BLAS_LEVEL1_ASUM_HPP
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+//
+// The BLAS-backend is selected by defining a pre-processor variable,
+// which can be one of
+// * for CBLAS, define BOOST_NUMERIC_BINDINGS_BLAS_CBLAS
+// * for CUBLAS, define BOOST_NUMERIC_BINDINGS_BLAS_CUBLAS
+// * netlib-compatible BLAS is the default
+//
+#if defined BOOST_NUMERIC_BINDINGS_BLAS_CBLAS
+#include
+#include
+#elif defined BOOST_NUMERIC_BINDINGS_BLAS_CUBLAS
+#include
+#include
+#else
+#include
+#include
+#endif
+
+namespace boost {
+namespace numeric {
+namespace bindings {
+namespace blas {
+
+//
+// The detail namespace contains value-type-overloaded functions that
+// dispatch to the appropriate back-end BLAS-routine.
+//
+namespace detail {
+
+#if defined BOOST_NUMERIC_BINDINGS_BLAS_CBLAS
+//
+// Overloaded function for dispatching to
+// * CBLAS backend, and
+// * float value-type.
+//
+inline float asum( const int n, const float* x, const int incx ) {
+ return cblas_sasum( n, x, incx );
+}
+
+//
+// Overloaded function for dispatching to
+// * CBLAS backend, and
+// * double value-type.
+//
+inline double asum( const int n, const double* x, const int incx ) {
+ return cblas_dasum( n, x, incx );
+}
+
+//
+// Overloaded function for dispatching to
+// * CBLAS backend, and
+// * complex value-type.
+//
+inline float asum( const int n, const std::complex* x,
+ const int incx ) {
+ return cblas_scasum( n, x, incx );
+}
+
+//
+// Overloaded function for dispatching to
+// * CBLAS backend, and
+// * complex value-type.
+//
+inline double asum( const int n, const std::complex* x,
+ const int incx ) {
+ return cblas_dzasum( n, x, incx );
+}
+
+#elif defined BOOST_NUMERIC_BINDINGS_BLAS_CUBLAS
+//
+// Overloaded function for dispatching to
+// * CUBLAS backend, and
+// * float value-type.
+//
+inline float asum( const int n, const float* x, const int incx ) {
+ return cublasSasum( n, x, incx );
+}
+
+//
+// Overloaded function for dispatching to
+// * CUBLAS backend, and
+// * double value-type.
+//
+inline double asum( const int n, const double* x, const int incx ) {
+ return cublasDasum( n, x, incx );
+}
+
+//
+// Overloaded function for dispatching to
+// * CUBLAS backend, and
+// * complex value-type.
+//
+inline float asum( const int n, const std::complex* x,
+ const int incx ) {
+ return cublasScasum( n, x, incx );
+}
+
+//
+// Overloaded function for dispatching to
+// * CUBLAS backend, and
+// * complex value-type.
+//
+inline double asum( const int n, const std::complex* x,
+ const int incx ) {
+ return cublasDzasum( n, x, incx );
+}
+
+#else
+//
+// Overloaded function for dispatching to
+// * netlib-compatible BLAS backend (the default), and
+// * float value-type.
+//
+inline float asum( const fortran_int_t n, const float* x,
+ const fortran_int_t incx ) {
+ return BLAS_SASUM( &n, x, &incx );
+}
+
+//
+// Overloaded function for dispatching to
+// * netlib-compatible BLAS backend (the default), and
+// * double value-type.
+//
+inline double asum( const fortran_int_t n, const double* x,
+ const fortran_int_t incx ) {
+ return BLAS_DASUM( &n, x, &incx );
+}
+
+//
+// Overloaded function for dispatching to
+// * netlib-compatible BLAS backend (the default), and
+// * complex value-type.
+//
+inline float asum( const fortran_int_t n, const std::complex* x,
+ const fortran_int_t incx ) {
+ return BLAS_SCASUM( &n, x, &incx );
+}
+
+//
+// Overloaded function for dispatching to
+// * netlib-compatible BLAS backend (the default), and
+// * complex value-type.
+//
+inline double asum( const fortran_int_t n, const std::complex* x,
+ const fortran_int_t incx ) {
+ return BLAS_DZASUM( &n, x, &incx );
+}
+
+#endif
+
+} // namespace detail
+
+//
+// Value-type based template class. Use this class if you need a type
+// for dispatching to asum.
+//
+template< typename Value >
+struct asum_impl {
+
+ typedef Value value_type;
+ typedef typename remove_imaginary< Value >::type real_type;
+ typedef real_type result_type;
+
+ //
+ // Static member function that
+ // * Deduces the required arguments for dispatching to BLAS, and
+ // * Asserts that most arguments make sense.
+ //
+ template< typename VectorX >
+ static result_type invoke( const VectorX& x ) {
+ namespace bindings = ::boost::numeric::bindings;
+ BOOST_STATIC_ASSERT( (bindings::has_linear_array< VectorX >::value) );
+ return detail::asum( bindings::size(x),
+ bindings::begin_value(x), bindings::stride(x) );
+ }
+};
+
+//
+// Functions for direct use. These functions are overloaded for temporaries,
+// so that wrapped types can still be passed and used for write-access. Calls
+// to these functions are passed to the asum_impl classes. In the
+// documentation, the const-overloads are collapsed to avoid a large number of
+// prototypes which are very similar.
+//
+
+//
+// Overloaded function for asum. Its overload differs for
+//
+template< typename VectorX >
+inline typename asum_impl< typename bindings::value_type<
+ VectorX >::type >::result_type
+asum( const VectorX& x ) {
+ return asum_impl< typename bindings::value_type<
+ VectorX >::type >::invoke( x );
+}
+
+} // namespace blas
+} // namespace bindings
+} // namespace numeric
+} // namespace boost
+
+#endif
diff --git a/sdk/boost/numeric/bindings/blas/level1/axpy.hpp b/sdk/boost/numeric/bindings/blas/level1/axpy.hpp
new file mode 100644
index 0000000..f5c605c
--- /dev/null
+++ b/sdk/boost/numeric/bindings/blas/level1/axpy.hpp
@@ -0,0 +1,249 @@
+//
+// Copyright (c) 2002--2010
+// 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_LEVEL1_AXPY_HPP
+#define BOOST_NUMERIC_BINDINGS_BLAS_LEVEL1_AXPY_HPP
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+//
+// The BLAS-backend is selected by defining a pre-processor variable,
+// which can be one of
+// * for CBLAS, define BOOST_NUMERIC_BINDINGS_BLAS_CBLAS
+// * for CUBLAS, define BOOST_NUMERIC_BINDINGS_BLAS_CUBLAS
+// * netlib-compatible BLAS is the default
+//
+#if defined BOOST_NUMERIC_BINDINGS_BLAS_CBLAS
+#include
+#include
+#elif defined BOOST_NUMERIC_BINDINGS_BLAS_CUBLAS
+#include
+#include
+#else
+#include
+#include
+#endif
+
+namespace boost {
+namespace numeric {
+namespace bindings {
+namespace blas {
+
+//
+// The detail namespace contains value-type-overloaded functions that
+// dispatch to the appropriate back-end BLAS-routine.
+//
+namespace detail {
+
+#if defined BOOST_NUMERIC_BINDINGS_BLAS_CBLAS
+//
+// Overloaded function for dispatching to
+// * CBLAS backend, and
+// * float value-type.
+//
+inline void axpy( const int n, const float a, const float* x, const int incx,
+ float* y, const int incy ) {
+ cblas_saxpy( n, a, x, incx, y, incy );
+}
+
+//
+// Overloaded function for dispatching to
+// * CBLAS backend, and
+// * double value-type.
+//
+inline void axpy( const int n, const double a, const double* x,
+ const int incx, double* y, const int incy ) {
+ cblas_daxpy( n, a, x, incx, y, incy );
+}
+
+//
+// Overloaded function for dispatching to
+// * CBLAS backend, and
+// * complex value-type.
+//
+inline void axpy( const int n, const std::complex a,
+ const std::complex* x, const int incx, std::complex* y,
+ const int incy ) {
+ cblas_caxpy( n, &a, x, incx, y, incy );
+}
+
+//
+// Overloaded function for dispatching to
+// * CBLAS backend, and
+// * complex value-type.
+//
+inline void axpy( const int n, const std::complex a,
+ const std::complex* x, const int incx,
+ std::complex* y, const int incy ) {
+ cblas_zaxpy( n, &a, x, incx, y, incy );
+}
+
+#elif defined BOOST_NUMERIC_BINDINGS_BLAS_CUBLAS
+//
+// Overloaded function for dispatching to
+// * CUBLAS backend, and
+// * float value-type.
+//
+inline void axpy( const int n, const float a, const float* x, const int incx,
+ float* y, const int incy ) {
+ cublasSaxpy( n, a, x, incx, y, incy );
+}
+
+//
+// Overloaded function for dispatching to
+// * CUBLAS backend, and
+// * double value-type.
+//
+inline void axpy( const int n, const double a, const double* x,
+ const int incx, double* y, const int incy ) {
+ cublasDaxpy( n, a, x, incx, y, incy );
+}
+
+//
+// Overloaded function for dispatching to
+// * CUBLAS backend, and
+// * complex value-type.
+//
+inline void axpy( const int n, const std::complex a,
+ const std::complex* x, const int incx, std::complex* y,
+ const int incy ) {
+ cublasCaxpy( n, a, x, incx, y, incy );
+}
+
+//
+// Overloaded function for dispatching to
+// * CUBLAS backend, and
+// * complex value-type.
+//
+inline void axpy( const int n, const std::complex a,
+ const std::complex* x, const int incx,
+ std::complex* y, const int incy ) {
+ cublasZaxpy( n, a, x, incx, y, incy );
+}
+
+#else
+//
+// Overloaded function for dispatching to
+// * netlib-compatible BLAS backend (the default), and
+// * float value-type.
+//
+inline void axpy( const fortran_int_t n, const float a, const float* x,
+ const fortran_int_t incx, float* y, const fortran_int_t incy ) {
+ BLAS_SAXPY( &n, &a, x, &incx, y, &incy );
+}
+
+//
+// Overloaded function for dispatching to
+// * netlib-compatible BLAS backend (the default), and
+// * double value-type.
+//
+inline void axpy( const fortran_int_t n, const double a, const double* x,
+ const fortran_int_t incx, double* y, const fortran_int_t incy ) {
+ BLAS_DAXPY( &n, &a, x, &incx, y, &incy );
+}
+
+//
+// Overloaded function for dispatching to
+// * netlib-compatible BLAS backend (the default), and
+// * complex value-type.
+//
+inline void axpy( const fortran_int_t n, const std::complex a,
+ const std::complex* x, const fortran_int_t incx,
+ std::complex* y, const fortran_int_t incy ) {
+ BLAS_CAXPY( &n, &a, x, &incx, y, &incy );
+}
+
+//
+// Overloaded function for dispatching to
+// * netlib-compatible BLAS backend (the default), and
+// * complex value-type.
+//
+inline void axpy( const fortran_int_t n, const std::complex a,
+ const std::complex* x, const fortran_int_t incx,
+ std::complex* y, const fortran_int_t incy ) {
+ BLAS_ZAXPY( &n, &a, x, &incx, y, &incy );
+}
+
+#endif
+
+} // namespace detail
+
+//
+// Value-type based template class. Use this class if you need a type
+// for dispatching to axpy.
+//
+template< typename Value >
+struct axpy_impl {
+
+ typedef Value value_type;
+ typedef typename remove_imaginary< Value >::type real_type;
+ typedef void result_type;
+
+ //
+ // Static member function that
+ // * Deduces the required arguments for dispatching to BLAS, and
+ // * Asserts that most arguments make sense.
+ //
+ template< typename VectorX, typename VectorY >
+ static result_type invoke( const value_type a, const VectorX& x,
+ VectorY& y ) {
+ namespace bindings = ::boost::numeric::bindings;
+ BOOST_STATIC_ASSERT( (is_same< typename remove_const<
+ typename bindings::value_type< VectorX >::type >::type,
+ typename remove_const< typename bindings::value_type<
+ VectorY >::type >::type >::value) );
+ BOOST_STATIC_ASSERT( (bindings::has_linear_array< VectorX >::value) );
+ BOOST_STATIC_ASSERT( (bindings::has_linear_array< VectorY >::value) );
+ BOOST_STATIC_ASSERT( (bindings::is_mutable< VectorY >::value) );
+ detail::axpy( bindings::size(x), a, bindings::begin_value(x),
+ bindings::stride(x), bindings::begin_value(y),
+ bindings::stride(y) );
+ }
+};
+
+//
+// Functions for direct use. These functions are overloaded for temporaries,
+// so that wrapped types can still be passed and used for write-access. Calls
+// to these functions are passed to the axpy_impl classes. In the
+// documentation, the const-overloads are collapsed to avoid a large number of
+// prototypes which are very similar.
+//
+
+//
+// Overloaded function for axpy. Its overload differs for
+//
+template< typename VectorX, typename VectorY >
+inline typename axpy_impl< typename bindings::value_type<
+ VectorX >::type >::result_type
+axpy( const typename bindings::value_type< VectorX >::type a,
+ const VectorX& x, VectorY& y ) {
+ axpy_impl< typename bindings::value_type<
+ VectorX >::type >::invoke( a, x, y );
+}
+
+} // namespace blas
+} // namespace bindings
+} // namespace numeric
+} // namespace boost
+
+#endif
diff --git a/sdk/boost/numeric/bindings/blas/level1/copy.hpp b/sdk/boost/numeric/bindings/blas/level1/copy.hpp
new file mode 100644
index 0000000..4d9ae20
--- /dev/null
+++ b/sdk/boost/numeric/bindings/blas/level1/copy.hpp
@@ -0,0 +1,243 @@
+//
+// Copyright (c) 2002--2010
+// 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_LEVEL1_COPY_HPP
+#define BOOST_NUMERIC_BINDINGS_BLAS_LEVEL1_COPY_HPP
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include