Model-based diagnosis (MBD) is a research field that builds theory and tools for the diagnosis of physical systems. As you may guess from the title, the general theory describes how to perform diagnosis based on a model of the physical system. Basically, an engine will use the model to predict the physical system behavior and match its results with the observations from the sensors. If discrepancies exist, well, a fault occured. Model-based programming is the 'science' of writing such models, and more...
I recommend you jump to this webpage at aaai.
Silly human race succeeds, why would smart machines fail?
A hybrid system is an automaton whose discrete modes contain continuous variables and equations. Hybrid systems spread widely in AI community as a useful modeling language for describing certain classes of systems. This becomes especially true when dealing with decisions such as a robot going left or right, abrupt process control to open a valve or shut off a piece of software that are all phenomena whose most natural and useful models contain discrete components. Hybrid systems also became a very convenient abstraction for certain classes of phenomena that may be difficult to model otherwise. It has been used in a wide range of applications including robotics, automotive electronics, manufacturing, automated highway systems, air traffic management systems, and more. Large hybrid models may be assembled from the composition of model fragments. The fragments are reusable and capture the relevant aspects of part of the system dynamics. The plug-and-play nature of such models makes them easier to write and verify, and offers a comprehensive framework to the modeler.
More information about hybrid systems can be found in the following webpages:
In the koala formalism, each component is represented with a hybrid automaton. Each mode of an automaton contains a representation of the continuous behavior of the component in that mode. koala uses an enhanced formalism that allows to choose between two representations of the continuous behavior of each component: a qualitative representation (from the work in the qualitative physic community), and a quantitative representation in the form of differential or static equations. These qualitative/quantitative relations are denoted constraints as they constrain the hybrid state of the automaton. Qualitative constraints are written in propositional logic. Quantitative constraints however are encoded into an original framework that is an oriented graph of causal influences. For now, the graph must be built by the modeler (see 1.5). The alternative of choosing qualitative or quantitative constraints offers more flexibility to the modeling of complex system. For example, we generally use qualitative constraints for modeling software and electronics behavior, and quantitative constraints otherwise. Please see the documentation for more information. For now, it is not possible to mix qualitative and quantitative constraints in the same component model (.def). However, it is recommended to mix them in the assembled system model.
koala has a component oriented langage that models every component as an hybrid automaton. The overall system model is assembled from these model fragments. In this model of the complete system, the fragments are made concurrent. This means the automatons evolve in parallel, while they synchronize to exchange information. Practically, in koala this means that when an automaton A moves from one of its modes to another, only the states of the remaining automatons that share information with A need to be re-evaluated.
Well, first I would not really say it is a modeling 'language'. There exist model-based programming langages out-there however. Compared to them, the koala modeling formalism is declarative. It is however powerful enough to represent and model interactions among complex components. I designed and enhanced the formalism from scratch based on the theoretical framework I built. It has thus no real connection to other existing langages. Any ideas or help to build converters from other more spreaded langages are welcome. Briefly, declaring a component is done in four steps: first, by including other needed component files (i.e. other components descriptions whose variables influence the current component behavior); second, by declaring its internal discrete and continuous variables; third by declaring its behavioral constraints; fourth by declaring the possible moves of the automaton among its modes.
Model-based programming langages include:
For now, yes. I know how this is troubling to modelers to switch to this kind of representation. However, I hope this will be done automatically in a near future, as such a software exists: the causal graph will be built automatically from the set of behavioral equations.
The compiler has been tested extensively. However, it does not take *all* possible mistakes in your koala 'code' into account. Most of the time a compiler crashes at loading time comes from a problem in the model 'code'. The compiler is one of the most complex part of koala, so don't hesitate to ask questions, or to report bugs (see 4.1).
A compiled model has three parts. First, koala generates a C++ class counterpart to each component model (.def) file. These classes are in the 'C' directory from your model repository. Second, koala produces a C++ runtime that instanciates and glues components (classes) together. The code for this runtime is in the 'runtime' directory of your model repository. Third, koala compiles all this code, create a library for the components (named libappliname.a in your model repository), and compiles the supervisor (see 3.1).
Well, yes... C++ compilation and link may take a while. This is due to the generally large size of the C++ generated files. Anyway, you may verify you are not using the code optimization option (code_opti) in your '.koaconf' file.
This a bug I know for a long time. It has to do with cross-reference. Koala models allow cross-reference among component model files, i.e. a component c1 can use variables of a component c2 while c2 is using variables of c1. Strangely enough, such a feature is not fully provided by the C++ langage: there exists a 'forward' class declaration that allows the use of pointers only. Koala thus includes an algorithm that breaks the cross-reference among component models so to write valid C++ code. This algorithm is buggy as it sometimes hangs on an infine loop. I don't know exactly how to fix it, but nevertheless, it *never* happened to me that a few swaps of component declarations in the '.mdl' file can't fix the problem. If you ever experience a permanent deadlock, please report it (see 4.1).
Koala produces a C++ model-based supervisor runtime and compiles it into an application that has a limited interface. When in your model repository, the C++ runtime is located in the runtime directory. By default, koala links it with all required files, and with code (koala-exec.o) that provides a limited interface. The resulting program is put is the 'bin' directory of your model repository. The supervisor may easily be linked to a more developed/different interface. In the futur, I hope a GUI is provided.
With the debug flag, the compiled static code may be huge, up to a dozen megabytes sometimes. It may be reduced to a fourth of that number by optimizing all code, i.e. koala libraries and generated code. I recommend using the gcc's '-O4' flag to this end.
Surprisingly, I do not own any of the modeled systems home ;) It comes that koala reads sensor data from files instead of sensors. To feed it with raw sensor data in real time would only require a few modifications in the current feeding strategy, plus the sensors acquisition code. I may provide the first part if required.
Report the bugs to me. If you have problem with the compiler at loading/compiling time, please include a tar.gz archive of your model files (no binaries please !) so it is possible for me to reproduce the bug.
If you are a programmer and you took a look at the source code, then you know it is research code, nothing more. However, things are clearer in my mind now. My plan is to schedule some cleanings and rewrites depending on the feedback I receive on the first releases. Not a lot of monitoring and diagnosing software seem to be available for free on the network today, but I am still not sure how people need it for their own research or applications...
