Simulator - old version

The Structure of the Simulator

The simulator is is based on three components working together: the Simulator class, the ModuleInterface and the StorageFileReader class.

The Simulator Class

The Simulator class is an SDP client node that handles connection to the SDP network as well as status changes to subscription, sending messages over the SDP network and receiving messages over the SDP network.

The Simulator class as stated is in charge of sending messages which is done by calling the public send method on the Simulator class. The data is wrapped in a data types derived from the AbstractSCSData class which is used to convert the data into a byte array and back.

The ModuleInterface

By creating new classes that implements the ModuleInterface it is guaranteed that those classes will be able to run as its own thread and be able to both start and stop with the simulation. This means that it is easy to create new simulations and add these to the simulator. Any new addition to the simulator must implement the features startSimulator stopSimulator and run. These methods should be used when setting up the running conditions for the simulator and should allow the module to either restart or resume the simulation. The module is also in charge of telling the simulator what signal ids it is providing since the SDP node requires these for notifying those nodes affected by the id.

The StorageFileReader Class

The StorageFileReader implements the ModuleInterface and is created by passing an instance of a Simulator class that has used the setupNode() method call as the constructor parameter.

By using the readFile(File file) method the class will try to read the file and extract data from it. The StorageFileReader class also tells the SDP node what data it provides after it has extracted this data from the file. The data inside the document must follow this pattern: {"timestamp":long,"name":1, 150, 151"value":int}. The timestamp is a long value so it can support UNIX timestamps. The name is an integer value and must be an valid VIL signal id. So far only the ids are:

  • 1 : 8 bits, unsigned int
  • 150 : 32 bits, unsigned int
  • 151 : 32 bits, unsigned int

The document containing the signal must give exactly 1 signal on every line and they need to be in chronological order sorted by their timestamp values.