EESimulator sub-project handles the transmission and processing of discrete events inside a vehicle. These discrete events mainly have the form of messages between ee-components across communication buses.
EE comes from "Electrical & Electronic Systems"
The following graphic shows how the
EESimulator implements a
EESimulator class handles the dispatching of
EEDiscreteEvents to various EE-Components managed by the
ComponentManager. The main EE-component structure is shown in the next section. The events inside this EE-simulator are mainly Message Events, simulating the communication between the components. These are handled by the
MessageTypeManager, discussed in the section after the next.
EESimulator class is instanced as a component of the
Vehicle class and updated by it.
The following graphic shows the main classes representing the EE-components in the Vehicle. All components are managed by the
ComponentManager for lookup and routing.
EEEventProcessor represents the top-most class of EE-components. It is further differentiated into
Buses that model the transmission of messages across a physical medium and into
BusUsers that are connected to those buses.
Bus implementations are:
BusUsers can be connected to
EEComponent is the super-class to all other component implementations.
Messages & Events
Discrete Events system/Events
EE Setup / Validation
Creating new components
Users of this sub-project can either instance the
EESimulator as part of their vehicle or inherit the
EEComponent class to create new components that work inside the ee-vehicle.
To setup an ee-system, create an
Then create the required
Components and bridges can then be linked to buses (with
connectToBus()) using the bus object, its component-id or its name.
A component or bridge can be connected to multiple buses.
Note: no cyclic bus/bridge structures are allowed.
When all components are connected, call
This will check the routing validity between components and setup the optimized routing data-structures.
Messages used in the different CAN tests:
|m4||3*MP + 5||4|
MP is for "Max Payload", the maximum number of payload bits in one frame.
- fullFrameMsg(): send m1.
- partialFrameMsg(): send m2.
- multiFullFrameMsg(): send m3.
- multiPartialFrameMsg(): send m4.
- multiMsgsInTime(): send m1 to m4, spaced in time (no overlap).
- multiMsgsAtSameTime(): send m1 to m4 at the exact same time (test priorities).
- multiMsgsOverlappingTime(): send m1 to m5 at overlapping time (test partial transmissions and transmission resume, see next section).
The following shows the expected behavior for the
multiMsgsOverlappingTime() test. Note that the inter-frame spaces are not shown in the graph but have an impact on how the expected times have to be computed. (The completion time doesn't include the inter-frame space necessary to start transmitting the next frame.)