Ph.D. - geht es zur Homepage der Informatik des Fachbereiches 3 ...

11.3. Simulation Model
11.3.2. CDMI – Driver Model
The model of the driver’s behaviour is defined by several decomposition of different states.
The parent state machine is displayed in Figure 11.8. On the top level, only two states in a
Figure 11.8.: UML state machine diagram of the driver’s behaviour
non-terminating state machine are provided:
Idling
Evaluating_Data
No data is currently available in the DMI. Nothing can be entered by the
(virtual) driver.
The DMI requires data to be entered. The behaviour in this state is
refined by a decomposition to a further sub-state machine, which is
introduced in a separated section.
11.3.2.1. Evaluating_Data State Machine
The corresponding graph of the UML state machine is shown in Figure 11.9. Its states are
explained as follows:
Check_Type_of_Data
Powering_System
This initial state checks the type of the available inputs
in the DMI by the EvaluateDMIInputs() function of
the simulative PSM C-API (see Subsection 11.2.2). The
full documentation and source code for all those C-API
functions is located in the appendix in Section H.2.
Furthermore, it is checked if the system / EVC was
initially powered by the “Powering_System” state or
the DMI has at least one input 3 . Otherwise, the execution
of this state is not meaningful, and the simulation
detects an error, which is is evaluated by @rttAssertstatement
[72]. If the Boolean expression in this statement
evaluates to false, the complete simulation is
stopped and the error is logged.
During an error-free simulation, this state is only executed
once, at the beginning of the simulation. It
3 return value of the DMIHasInput() function
221