Browse Source

Initial commit.

master
Pierre Gaufillet 6 years ago
parent
commit
18eb3f6047
  1. 70
      CMakeLists.txt
  2. 1041
      CeCILL-C.txt
  3. 10
      Copyright
  4. 481
      LGPL-v2.txt
  5. 143
      LICENSES.md
  6. 17
      README.md
  7. 3
      TODO
  8. 39
      config/FindGlib.cmake
  9. 38
      config/FindGlibmm.cmake
  10. 41
      config/FindLibXML++.cmake
  11. 90
      config/FindLibXML2.cmake
  12. 75
      config/FindPLplot.cmake
  13. 34
      config/FindSigC++.cmake
  14. 100
      config/FindUMFPACK.cmake
  15. 1086
      config/FindwxWidgetsCustom.cmake
  16. 101
      config/LibFindMacros.cmake
  17. 20
      doc/CMakeLists.txt
  18. 1663
      doc/Doxyfile.cmake
  19. 134
      doc/Rapport post-doc/1-introduction.tex
  20. 400
      doc/Rapport post-doc/2-motivation.tex
  21. 173
      doc/Rapport post-doc/2-sota.tex
  22. 884
      doc/Rapport post-doc/3-imbsa.tex
  23. 300
      doc/Rapport post-doc/4-aocs.tex
  24. 131
      doc/Rapport post-doc/5-conclusions.tex
  25. 64
      doc/Rapport post-doc/IMBSA-paper.tex
  26. 17
      doc/Rapport post-doc/algos/function.fcr
  27. 12
      doc/Rapport post-doc/algos/function2.alt
  28. 1
      doc/Rapport post-doc/algos/function2.fcr
  29. 12
      doc/Rapport post-doc/algos/pre.alt
  30. 8
      doc/Rapport post-doc/algos/pre.fcr
  31. 22
      doc/Rapport post-doc/algos/pre2.fcr
  32. 88
      doc/Rapport post-doc/aliascnt.sty
  33. 32
      doc/Rapport post-doc/altarica-diagrams.tex
  34. 24
      doc/Rapport post-doc/altarica-function.tex
  35. 588
      doc/Rapport post-doc/app.tex
  36. 73
      doc/Rapport post-doc/dirtytalk.sty
  37. 130
      doc/Rapport post-doc/etgts.tex
  38. BIN
      doc/Rapport post-doc/figures/0- AOCS mode Abstract.png
  39. BIN
      doc/Rapport post-doc/figures/2-2 - AOCS mode automaton.png
  40. BIN
      doc/Rapport post-doc/figures/2-3 - ASH mode.png
  41. BIN
      doc/Rapport post-doc/figures/2-4 set ON the equipment for ASM mode.png
  42. BIN
      doc/Rapport post-doc/figures/2-5 ACM automaton.png
  43. BIN
      doc/Rapport post-doc/figures/2-6 set ON the equipment for ACM mode.png
  44. BIN
      doc/Rapport post-doc/figures/2-7 Collision Avoidance Mode.png
  45. BIN
      doc/Rapport post-doc/figures/2-8 OCM automaton.png
  46. BIN
      doc/Rapport post-doc/figures/2-9 Formation Control Mode.png
  47. BIN
      doc/Rapport post-doc/figures/AOCS mode.png
  48. BIN
      doc/Rapport post-doc/figures/AOCSmode_schema.png
  49. BIN
      doc/Rapport post-doc/figures/AirSpeed_Computation.jpg
  50. BIN
      doc/Rapport post-doc/figures/ERTS - AOCS mode.png
  51. BIN
      doc/Rapport post-doc/figures/EUTELSAT-172B-SATELLITE.jpg
  52. BIN
      doc/Rapport post-doc/figures/Equipment Mode.png
  53. BIN
      doc/Rapport post-doc/figures/Function2_1.pdf
  54. BIN
      doc/Rapport post-doc/figures/Function2_1.png
  55. 271
      doc/Rapport post-doc/figures/Function2_1.svg
  56. 306
      doc/Rapport post-doc/figures/Function2_1.tex
  57. BIN
      doc/Rapport post-doc/figures/Function2_2.pdf
  58. BIN
      doc/Rapport post-doc/figures/Function2_2.png
  59. 276
      doc/Rapport post-doc/figures/Function2_2.svg
  60. BIN
      doc/Rapport post-doc/figures/Gnc mode simplifie.png
  61. BIN
      doc/Rapport post-doc/figures/Modele0.png
  62. BIN
      doc/Rapport post-doc/figures/Modele0F4.png
  63. BIN
      doc/Rapport post-doc/figures/Modele1.png
  64. BIN
      doc/Rapport post-doc/figures/Modele2.png
  65. BIN
      doc/Rapport post-doc/figures/passerelle.png
  66. BIN
      doc/Rapport post-doc/figures/satellite_telecom.png
  67. BIN
      doc/Rapport post-doc/figures/space_systems_2.jpg
  68. BIN
      doc/Rapport post-doc/figures/table1.png
  69. 21
      doc/Rapport post-doc/figures/texput.log
  70. 42
      doc/Rapport post-doc/llncsdoc.sty
  71. 25
      doc/Rapport post-doc/longabstract.tex
  72. 1067
      doc/Rapport post-doc/lstlang3.sty
  73. 198
      doc/Rapport post-doc/main.tex
  74. 48
      doc/Rapport post-doc/main.toc
  75. 427
      doc/Rapport post-doc/paper.bib
  76. 30
      doc/Rapport post-doc/readme.txt
  77. 39
      doc/Rapport post-doc/remreset.sty
  78. 1519
      doc/Rapport post-doc/splncs03.bst
  79. 4
      doc/Rapport post-doc/sprmindx.sty
  80. 70
      doc/Rapport post-doc/subjidx.ind
  81. 103
      doc/Rapport post-doc/tina.bib
  82. 1
      doc/TODO
  83. BIN
      doc/altarica-syntax.pdf
  84. BIN
      doc/boundedcont.pdf
  85. BIN
      doc/cont.pdf
  86. 22
      doc/quickstart.aux
  87. 246
      doc/quickstart.log
  88. BIN
      doc/quickstart.pdf
  89. 407
      doc/quickstart.tex
  90. 162
      icons/document-build-model-16.xpm
  91. 343
      icons/document-build-model-24.xpm
  92. 60
      icons/document-switch-mode-16.xpm
  93. 80
      icons/document-switch-mode-24.xpm
  94. 27
      sdk/CMakeLists.txt
  95. 74
      sdk/boost/numeric/bindings/addressing_index.hpp
  96. 71
      sdk/boost/numeric/bindings/at.hpp
  97. 167
      sdk/boost/numeric/bindings/bandwidth.hpp
  98. 145
      sdk/boost/numeric/bindings/begin.hpp
  99. 17
      sdk/boost/numeric/bindings/blas.hpp
  100. 574
      sdk/boost/numeric/bindings/blas/detail/blas.h
  101. Some files were not shown because too many files have changed in this diff Show More

70
CMakeLists.txt

@ -0,0 +1,70 @@
# This file is part of EPOCH.
# File: CMakeLists.txt
# Author: Florent Teichteil-Königsbuch
# Contact: florent.teichteil@onera.fr
#
# EPOCH is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# EPOCH is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with EPOCH. If not, see <http://www.gnu.org/licenses/>.
CMAKE_MINIMUM_REQUIRED (VERSION 2.8)
PROJECT (EPOCH)
ENABLE_LANGUAGE(C CXX Fortran)
SET (CMAKE_MODULE_PATH ${CMAKE_HOME_DIRECTORY}/config)
INCLUDE (CheckIncludeFiles)
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x")
#####################
# FIND DEPENDENCIES #
#####################
FIND_PACKAGE (Boost 1.46.0 COMPONENTS program_options timer chrono filesystem system date_time timer unit_test_framework REQUIRED)
INCLUDE_DIRECTORIES (${Boost_INCLUDE_DIRS} ${SUITESPARSE_PATH})
LINK_DIRECTORIES (${Boost_LIBRARY_DIRS})
MESSAGE (STATUS "Found Boost version: " ${Boost_VERSION})
OPTION (BUILD_GUI "Build EPOCH's Graphical User Interface" OFF)
IF (BUILD_GUI)
FIND_PACKAGE (wxWidgetsCustom COMPONENTS base core aui xml REQUIRED)
SET (CMAKE_REQUIRED_INCLUDES_COPY ${CMAKE_REQUIRED_INCLUDES})
LIST (APPEND CMAKE_REQUIRED_INCLUDES ${wxWidgets_INCLUDE_DIRS})
CHECK_INCLUDE_FILES (wx/aui/tabdocmdi.h HAVE_TABDOCMDI_H)
SET (CMAKE_REQUIRED_INCLUDES ${CMAKE_REQUIRED_INCLUDES_COPY})
FIND_PACKAGE (PLplot REQUIRED)
IF (NOT PLplot_wxwidgets_LIBRARY)
MESSAGE (FATAL_ERROR "PLplot wxwidgets bindings required to build the GUI")
ENDIF(NOT PLplot_wxwidgets_LIBRARY)
ENDIF (BUILD_GUI)
OPTION (BUILD_DOC "Build Doxygen documentation" OFF)
IF (BUILD_DOC)
FIND_PACKAGE (Doxygen REQUIRED)
ENDIF (BUILD_DOC)
##################
# COMPILES FILES #
##################
ADD_SUBDIRECTORY (sdk)
ADD_SUBDIRECTORY (src)
#######################
# BUILD DOCUMENTATION #
#######################
IF (BUILD_DOC)
ADD_SUBDIRECTORY (doc)
ENDIF (BUILD_DOC)

1041
CeCILL-C.txt

File diff suppressed because it is too large Load Diff

10
Copyright

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

481
LGPL-v2.txt

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

143
LICENSES.md

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

17
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

3
TODO

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

39
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)

38
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)

41
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++)

90
config/FindLibXML2.cmake

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

75
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)

34
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++)

100
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)

1086
config/FindwxWidgetsCustom.cmake

File diff suppressed because it is too large Load Diff

101
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)

20
doc/CMakeLists.txt

@ -0,0 +1,20 @@
# This file is part of EPOCH.
# File: CMakeLists.txt
# Author: Florent Teichteil-Königsbuch
# Contact: florent.teichteil@onera.fr
#
# EPOCH is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# EPOCH is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with EPOCH. If not, see <http://www.gnu.org/licenses/>.
CONFIGURE_FILE (${CMAKE_SOURCE_DIR}/doc/Doxyfile.cmake ${CMAKE_BINARY_DIR}/doc/Doxyfile @ONLY)
ADD_CUSTOM_TARGET (html ${DOXYGEN_EXECUTABLE} ${CMAKE_BINARY_DIR}/doc/Doxyfile)

1663
doc/Doxyfile.cmake

File diff suppressed because it is too large Load Diff

134
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

400
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

173
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}.

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

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

300
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 470486 & & 16 \\
\hline
2 thrusters & 4 003 939 & 207594548 & & 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:

131
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:

64
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}

17
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

12
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

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

@ -0,0 +1 @@

12
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

8
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

22
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

88
doc/Rapport post-doc/aliascnt.sty

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

32
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:

24
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}

588
doc/Rapport post-doc/app.tex

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

73
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'.

130
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

BIN
doc/Rapport post-doc/figures/0- AOCS mode Abstract.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 52 KiB

BIN
doc/Rapport post-doc/figures/2-2 - AOCS mode automaton.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 175 KiB

BIN
doc/Rapport post-doc/figures/2-3 - ASH mode.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB

BIN
doc/Rapport post-doc/figures/2-4 set ON the equipment for ASM mode.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 13 KiB

BIN
doc/Rapport post-doc/figures/2-5 ACM automaton.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 22 KiB

BIN
doc/Rapport post-doc/figures/2-6 set ON the equipment for ACM mode.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB

BIN
doc/Rapport post-doc/figures/2-7 Collision Avoidance Mode.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

BIN
doc/Rapport post-doc/figures/2-8 OCM automaton.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 18 KiB

BIN
doc/Rapport post-doc/figures/2-9 Formation Control Mode.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 18 KiB

BIN
doc/Rapport post-doc/figures/AOCS mode.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 92 KiB

BIN
doc/Rapport post-doc/figures/AOCSmode_schema.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 75 KiB

BIN
doc/Rapport post-doc/figures/AirSpeed_Computation.jpg

Binary file not shown.

After

Width:  |  Height:  |  Size: 167 KiB

BIN
doc/Rapport post-doc/figures/ERTS - AOCS mode.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 92 KiB

BIN
doc/Rapport post-doc/figures/EUTELSAT-172B-SATELLITE.jpg

Binary file not shown.

After

Width:  |  Height:  |  Size: 272 KiB

BIN
doc/Rapport post-doc/figures/Equipment Mode.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 18 KiB

BIN
doc/Rapport post-doc/figures/Function2_1.pdf

Binary file not shown.

BIN
doc/Rapport post-doc/figures/Function2_1.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.8 KiB

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

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

After

Width:  |  Height:  |  Size: 11 KiB

306
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}

BIN
doc/Rapport post-doc/figures/Function2_2.pdf

Binary file not shown.

BIN
doc/Rapport post-doc/figures/Function2_2.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 14 KiB

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

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

After

Width:  |  Height:  |  Size: 12 KiB

BIN
doc/Rapport post-doc/figures/Gnc mode simplifie.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 41 KiB

BIN
doc/Rapport post-doc/figures/Modele0.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.1 KiB

BIN
doc/Rapport post-doc/figures/Modele0F4.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.8 KiB

BIN
doc/Rapport post-doc/figures/Modele1.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 6.3 KiB

BIN
doc/Rapport post-doc/figures/Modele2.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 7.4 KiB

BIN
doc/Rapport post-doc/figures/passerelle.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 93 KiB

BIN
doc/Rapport post-doc/figures/satellite_telecom.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 985 KiB

BIN
doc/Rapport post-doc/figures/space_systems_2.jpg

Binary file not shown.

After

Width:  |  Height:  |  Size: 76 KiB

BIN
doc/Rapport post-doc/figures/table1.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 10 KiB

21
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!

42
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}

25
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:

1067
doc/Rapport post-doc/lstlang3.sty

File diff suppressed because it is too large Load Diff

198
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:

48
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}

427
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}}
}

30
doc/Rapport post-doc/readme.txt

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

39
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}}}

1519
doc/Rapport post-doc/splncs03.bst

File diff suppressed because it is too large Load Diff

4
doc/Rapport post-doc/sprmindx.sty

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

70
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}

103
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}
}

1
doc/TODO

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

BIN
doc/altarica-syntax.pdf

Binary file not shown.

BIN
doc/boundedcont.pdf

Binary file not shown.

BIN
doc/cont.pdf

Binary file not shown.

22
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}}

246
doc/quickstart.log

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

BIN
doc/quickstart.pdf

Binary file not shown.

407
doc/quickstart.tex

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

162
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. ",
" "};

343
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@ ",
" ",
" "};

60
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 ",
" ",
" ",
" "};

80
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 ",
" # ",
" ",
" ",
" ",
" "};

27
sdk/CMakeLists.txt

@ -0,0 +1,27 @@
# This file is part of EPOCH.
# File: CMakeLists.txt
# Author: Florent Teichteil-Königsbuch
# Contact: florent.teichteil@onera.fr
#
# EPOCH is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# EPOCH is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with EPOCH. If not, see <http://www.gnu.org/licenses/>.
MESSAGE (STATUS "COMPILES the Software Development Kit (additional provided dependencies)")
IF (BUILD_GUI)
INCLUDE (${wxWidgets_USE_FILE})
ADD_SUBDIRECTORY (wxscintilla)
ADD_SUBDIRECTORY (wxshapeframework)
ENDIF (BUILD_GUI)
ADD_SUBDIRECTORY(buddy-2.4)

74
sdk/boost/numeric/bindings/addressing_index.hpp

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

71
sdk/boost/numeric/bindings/at.hpp

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

167
sdk/boost/numeric/bindings/bandwidth.hpp

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

145
sdk/boost/numeric/bindings/begin.hpp

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

17
sdk/boost/numeric/bindings/blas.hpp

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

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

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

Some files were not shown because too many files have changed in this diff Show More

Loading…
Cancel
Save