In addition to using the factory design pattern, each particular simulator must be configured to specify the hardware model to create. In addition, the hardware model may need parameters for configuring how the hardware acts. Also, hardware has connections for communication such as discrete I/O, I2C, or UART, and so in the simulation the hardware model will need to create software versions of these connections and these connections may also need configuration data such as bus type, bus name, and bus address. In addition, some hardware models (such as a GPS or magnetometer simulator) may need environmental data, and so the hardware model will need to create a data provider which will provide environmental data. The data provider may need configuration data such as the type of data provider and a filename or host and port.
The configuration for a specific simulation executable will be specified in a file via XML (eXtensible Markup Language), which will provide a list of simulators that are to be instantiated within that executable. Each simulator will specify a hardware model, which might have additional configuration parameters. The hardware model might specify reliance on an optional data provider with data provider configuration parameters. The hardware model might also specify one or more software communication connections with connection configuration parameters.
Writing your own simulator continued...
Here are the steps to configuring and the XML.
- Add XML like the following inside the <simulators></simulators> tags in the standard configuration file (the standard configuration file name is nos3-simulator.xml)
- Customizing the XML:
- The simulator.name should be the same as in your main function in #1.
- The simulator.active tag should be true unless you do not want your simulator to run in which case it should be false.
- The simulator.library tag should contain the name of the example simulator shared object library file (normally lib<project>.so where <project> is the project name given the project in the CMakeLists.txt file; see below)
- The simulator.hardware-model.type should be the same as the string you used in the REGISTER_HARDWARE_MODEL line above.
- The simulator hardware-model data-provider type should be the same as the string you used in the REGISTER_DATA_PROVIDER line above.
- All other tags are up to you… create your own names and then use the information above for accessing the data. Note that there are examples in the source code for using several common connection types such as UART, I2C and the command connection (used for out of band control of the simulator with the simulator terminal). Also note that the command connection is automatically configured for you in the SimIHardwareModel base class. To have your simulator respond to commands to it on the command bus, all you need to do is override the SimIHardwareModel::command_callback method in your hardware model class (the default implementation does nothing).
<simulator> <name>foosim</name> <active>true</active> <library>libexample_sim.so</library> <hardware-model> <type>FOOHARDWARE</type> <connections> <connection> <connection-param1>cp1</connection-param1> <!-- ... --> <connection-paramN>cpN</connection-paramN> </connection> </connections> <data-provider> <type>FOOPROVIDER</type> <provider-param1>fpp1</provider-param1> <!-- ... --> <provider-paramN>fppN</provider-paramN> </data-provide> <other-hardware-parameter1>OTHER-FOO</other-hardware-parameter1> <!-- ... --> <other-hardware-parameterN>OTHER-FOO</other-hardware-parameterN> </hardware-model> </simulator>