![]() |
irafhy
Interval arithmetic based Reachability Analysis Framework for Hybrid Automaton
|
In this section, we will introduce you how to use this library to define your own algorithm and how to write the test cases, at the end of this section, some options about the results plotting were provided.
For convenience, the concept of hybrid systems is referred to in the Thomas A Henzinger's paper. Almost all decouplable modules in the accessibility process are decoupled into separate computing modules. However, at present, we only allow users to build specific accessibility analysis algorithms by customizing three modules as follows:
The analyzer module is mainly used to solve the initial value problem, that is to say, given the specified initial state set and the specified duration, as well as the given continuous dynamic system, the module should return the state set that the continuous dynamic system can reach. Different reach-ability analysis algorithms usually define their own specific calculation methods to get the reachable set in a certain time interval. Therefore, we public the module, so that users can customize their own reach-ability set algorithm by customizing the actual calculation method within the Analyzer module.
e.g. if you just want to get the over approximate state set in a duration, you can simply call the solver which can return the over approximate set as following:
As you can see, there is nothing special within the analyser but an ODE solver calling. all you need to do is to define your own class which inherited from the pre-defined Analyser and overwrite the pure virtual method compute. you can also define a relatively complex analyser class like this which implement the algorithm in Bai Xue's paper
The verifier module is another module you need to customize before testing your own algorithm. this module responsible for the verification of the running procedure. it is used to control whether the procedure should be terminated. the verification method will be called after each step. return TRUE means the algorithm can be run one more step. FALSE means the algorithm should not be running any more. you can customize your own verifier just like what we do in the previous subsection.
for more complex verifier example, you can check the source code of the repository.
It is inevitable to set some parameters related to the algorithm. For this part, we use Settings class to maintain all of them. you can customize your own Settings class to maintain the parameters you need and add some other methods you want. e.g.
:warning: It should be noted that the Analyser, Verifier, Settings should be in the namespace irafhy.
All the configurations related to the test case should be defined in two files, one for Hybrid System, the other for Settings. e.g.
once two files done, the parameter inside shall be parsed by the parser only if you use the right name of the parameter and the set it to the right value.
The results can be plotted once the results generated, you can simply call the show method of class viewer to view them. the viewer current is generally an unpolished tool which supports limited viewing options, it will be improved future.
as you can see, you should provide the geometry objects, points, the time intervals, the dimensions and the style of the plotting. here is a piece of screenshot showing a bunch of 3D interval hulls, some points and time intervals which indicate when these geometry objects generated. even the dimension values set to _{0,1,2}_, the viewer still just show 2D interval hulls cause the time intervals provided.