Basics & Principles
RODON models – Major features
RODON models are:
- Strictly component oriented. This already indicates a basic difference to conventional simulators which are signal flow oriented.
- Context free and therefore readily reusable. They are independent of the context they were originally modeled for.
- Based on the “no function in structure” paradigm, e.g. the overall functionality of a system is completely defined by the behavior of the components and their connectivity.
- Undirected with respect to behavior (Directional behaviour can be described when needed).
- Describe the nominal behavior primarily. Failure modes of components can be defined locally within the component models. The behavior can be defined either quantitatively with tolerances or qualitatively. Tolerances are described by intervals. By means of this RODON can also cope with uncertain knowledge.
- Described in a declarative, non-procedural modeling language. Therefore RODON is especially well suited for executable specifications. The user only needs to specify what a component has to do, not how.
- Modeled in the object oriented modeling language Rodelica (Rodelica is a dialect of Modelica, the modeling language standardized by the Modelica association).
- Able to have multiple inheritance. This supports the generation of variants of models.
- Well suited for building model libraries with reusable components and assemblies.
- Able to represent various levels of abstraction: This includes very abstract high level models for overall system compatibility analysis, intermediate level models and low level “physical level models” for detailed analyses.
All of this supports the modeling process greatly.
How RODON works - Simple example
A very simple circuit and its modeling and analysis aspects shall help to understand RODON. It consists of a voltage source, switch, lamp and wire:
RODON can perform the following analyses with it:
- Components in “nominal mode”, U = 12V, switch open
 lamp off
- Components in “nominal mode”, U = 12V, lamp on switch closed
As one can see, RODON can evaluate this little electrical net in multiple directions:
| Case 1 |
Cause |
|
Effect |
|
Switch open |
|
Lamp off |
| Case 2 |
Effect |
|
Cause |
|
Lamp on |
|
Switch closed |
In these cases, the system was fully determined in the mathematical sense or, in other words, two quantities are given, the third is the result of the RODON simulation. Please note that in case 2 RODON concludes from the facts that there is the proper voltage and the lamp is lit the switch must be closed. These two cases highlight two important aspects of RODON:
- Possibility to stimulate any set of model variables or parameters
- Full determination of a system.
In addition, RODON finds very often solutions, even in cases where not all data are given or the system is underdetermined, by narrowing down the intervals as far as possible. This can not be shown by the simple example given here.
Moreover, in case the system is over determined, RODON can identify, whether the system behaves “as it should” or whether a problem exists as shown in cases 3 and 4:
| Case 3 |
U=12V, switch closed, lamp lit |
|
All components in “nominal mode”, no conflict system OK |
| Case 4 |
U=12V, switch closed, lamp off |
|
All components in “nominal mode” conflict |
Case 4 represents a malfunction. One can ask RODON to try to find an explanation for this situation. This is done by means of systematically activating definite failure modes of the components and simulation. As soon as it finds a conflict free simulation result it identifies the activated failure mode as a potential “root cause”. This is called Model Based Diagnostics (MBD). RODON’s MBD engine can be controlled to identify single, double faults and higher level multiple faults.
In RODON, hardware components usually have one nominal mode of operation and one or more failure modes. The nominal mode describes how the non-defective component behaves in all kinds of situations or modes of operation. The failure modes, however, describe how the broken component behaves in all such situations. Below a few examples are given for basic electrical components.
Wire
 |
| Mode No. |
Mode Name |
Model |
| 0 (nominal) |
NOMINAL |
U1 = U2, Iin = Iout |
| 1 (failure) |
DISCONNECTED |
U1, U2 undefined, I = 0 |
| 2 (failure) |
SHORT TO GND |
U1 = U2 = 0, I undefined |
| ... (failure) |
... |
... |
|
Battery
 |
| Mode No. |
Mode Name |
Model |
| 0 (nominal) |
NOMINAL |
(U2 - U1) in [Unominal - ε, Unominal + ε] |
| 1 (failure) |
EMPTY |
(U2 - U1) < [Unominal - ε] |
| ... |
... |
... |
|
Switch
 |
| Mode No. |
Mode Name |
Model |
| 0 (nominal) |
NOMINAL |
if (x) (U1 = U2, Iin = Iout else U1, U2 undefined, I = 0 |
| 1 (failure) |
STUCK OPEN |
U1, U2 undefined, I = 0 |
| ... |
... |
... |
|
Light Bulb
 |
| Mode No. |
Mode Name |
Model |
| 0 (nominal) |
NOMINAL |
Ohm’s and Kirchhoff’s law are obeyed simultaneously |
| 1 (failure) |
DISCONNECTED |
U1, U2 undefined, I = 0 |
| ... |
... |
... |
|
Such components are available in model libraries. They can be graphically sticked together to form a model of an assembly or system. Software modules and functions can be considered in a similar way.
|
