Model

August 11, 2023 · View on GitHub

A node encompasses one or more models, where each model essentially replicates a specific functionality or behavior of the node. For instance, a model can simulate the orbital movement of a satellite, while another model can represent solar panel power generation. In our code implementation, we utilize a class to encapsulate the properties and functionalities of each model.

Model interface

A model class must inherit the IModel interface that abstracts the core properties and functionalities of any model. For more details about IModel, please refer to the imodel module.We discuss some important properties and methods related to models below.

`iName`

The implementation name (iName) is the model class name.

`modelTag`

It represents the category or type of a model, such as power, memory, orbit, radio, and others. It plays a crucial role in querying a specific type of model within a node. For example, we can inquire whether a node includes a "POWER" model. The various model tags are enumerated in EModelTag.

`owneNode`

Each model instance must belong to a node instance. ownerNode provides the owner node instance of a model instance.

`supportedNodeClasses`

A model may not support all the node implementation. For example, the orbit model does not support the ground station node. supportedNodeClasses gives the list of names of the node implementation classes that it supports. For example, if a model supports only the SatBasic and SatAdvanced node implementations, the list should be ['SatBasic', 'SatAdvanced']. If the model supports all the node implementations out there, just keep the list EMPTY. For example, a data storage model can be used in any node implementation.

`dependencyModelClasses`

dependencyModelClasses gives the nested list of name of the model implementations that this model has dependency on. For example, if a model has dependency on the ModelPower and ModelOrbitalBasic, the list should be [['ModelPower'], ['ModelOrbitalBasic']]. Now, if the model can work with EITHER of the ModelOrbitalBasic OR ModelOrbitalAdvanced, the these two should come under one sublist looking like [['ModelPower'], ['ModelOrbitalBasic', 'ModelOrbitalAdvanced']]. So each exclusively dependent model should be in a separate sublist and all the models that can work with either of the dependent models should be in the same sublist. If your model does not have any dependency, just keep the list EMPTY.

`call_APIs()`

The call_APIs() method serves as the API interface of a model. It is utilized to access the APIs provided by the model. The method takes two arguments: the API name and arbitrary keyworded arguments passed as input to the corresponding API. Typically, this method is invoked to interact with the model in real-time. For instance, the power model provides an API to retrieve the available battery power. The computation model within the same parent node can access this API, offered by the power model, by using the call_APIs() method of the power model.

`Execute()`

The simulator operates in a discrete time manner. During each epoch, a model executes its operations. To facilitate this, each model within the simulator should possess an Execute() method, responsible for executing the model's specific operations. The Execute() method is called by the node when it needs to execute the model.

In cases where we are implementing a helper model designed to assist other models, the Execute() method may remain empty. For instance, a field of view (FoV) helper model, responsible for generating the FoV for a node upon request by other models (e.g., communication), can have its Execute() method empty.

Creating a model class

In the models directory, we have already developed several model classes catering to orbital dynamics, power, communication functionalities, and more. However, users retain the flexibility to introduce additional model classes to expand the system's capabilities.

As previously mentioned, to create a new model class, it must inherit the IModel interface. Alternatively, users can inherit from an existing model class, especially when substantial portions of the new model class have already been implemented within the existing one. If there is no suitable base class, the factory method can be adopted to create a new model class inheriting the IModel interface.

In addition to implementing a new model class, users need to create an instance initialization method for the class. This step allows users to receive custom configuration inputs for their model instances. For reference, the init_ModelOrbit(...) method within the modelorbit module provides an example. Utilizing the _modelArgs parameter allows direct retrieval of configuration inputs from the simulation config file, and the method returns an instance of the newly implemented model class.

To enable users to use the new model implementation in the simulation, it is necessary to add a reference to the initialization method in modelinits. By including the model class name as a key and the corresponding initialization method as the value in the modelInitDictionary dictionary, users can easily utilize the new model by simply adding its name in the config file. With this, the process is complete!

Existing models

Find a list of implemented models below along with brief description.