The elevator simulator for 18-649: Distributed Embedded Systems. The
packages
jSimPack
, simulator.framework
,
simulator.elevatormodules
, and simulator.payloads
form the core of the simulator itself. They provide the infrastructure
that
allow other modules to send messages to each other on a simulated CAN
network,
and it provides a centralized time keeping system in the form of a
discrete
event simulation. The package simulator.elevatorcontrol
is where
students will write the controllers that
- Control the lights on the buttons inside the car and in the
hallways
- Open and close the doors
- Move the car up and down the hoistway
Students are not expected to modify classes in the other packages,
unless
course staff tells them otherwise.
Interacting with the Simulation
Controllers must extend {@link simulator.framework.Controller} in
order to
send and receive physical and CAN network messages.
See the documentation for this class for more
information.
The Harness
The {@link simulator.framework.Harness} is the backbone that provides
all the CAN and physical networks and event scheduling. It is also the
master time keeper
for
the simulation. The only methods you will need to use are {@link
simulator.framework.Harness#getTime()} and (indirectly) {@link
simulator.framework.Harness#log(String,Object...)}.
Interacting with Other Simulation Modules
Networks
There are two networks provided by the Harness:
A "physical" network object {@link simulator.framework.PhysicalNetwork}
(interactions with system objects are implemented using a message
passing architecture)
and a
A CAN network object {@link simulator.framework.CANNetwork}. You do not
access
these object directly, but rather through {@link
simulator.framework.NetworkConnection}
objects. The connection objects you need are already provided in the
{@link simulator.framework.Controller} object. These connection objects
enforce
the input and output interface requirements, namely: only one object
may send a CAN message
with a given message ID, and each controller may have only one Physical
input and
one physical output.
Physical Messages
Physical messages are represented by {@link
simulator.payloads.PhysicalPayload} objects.
Each message type is a distinct subclass of the abstract class
PhysicalPayload
. The concrete classes defined in {@link
simulator.payloads} are the only message types available to you this
semester.
Each PhysicalPayload defines the fields that carry the information your
controllers will need so they can perform their functions. These
correspond to physical information about the system and physical and
outputs
(button state, light state, etc).
See the documentation in specific Payload objects for details.
Network Messages
There is a special payload object called {@link
simulator.payloads.CanMailbox}
that represents CAN messages sent on the CAN network. In contrast to
the
physical messages, there is only one message type that is sent on the
CAN network.
CAN messages payloads are distinguished by their IDs. They contain a
bit set
which represents the raw message payload. In order to obtain a get/set
interface
for specific can message types, you must use a {@link
simulator.payloads.translators.CanPayloadTranslator}.
The CanPayloadTranslator abstract class contains helper methods to
assist you
in packing values into the CanMailbox bit set.
Two generic translators are defined in the {@link
simulator.payloads.translators} package:
{@link simulator.payloads.translators.CanPayloadTranslator}.
You will eventually define additional PayloadTranslators when you do a
network
schedule analysis.
Note that, while it is theoretcially possible to interact directly with
the CanMailbox object,
you must use a CanPayloadTranslator object when inserting and asserting
messages
in the {@link simulator.framework.MessageInjector}.
Readable and Writeable
Message payload objects (physical and network) cannot be instantiated
directly. Instead, each provides a Readable and Writeable wrapper
class which enforce the correct read/write semantics on the network
interfaces.
Have fun!
Explore the rest of the documentation for more information. You might
not use
all of the classes throughout the course, and for the first several
weeks you
will be designing your elevator without writing any code. So, if
something
doesn't make sense right away, don't worry. Wait a few weeks until the
coding
begins and try again.
Have fun!