Function Specification: Integration with OML
To isolate/encapsulate all OML-related functions, a class OrbitApp is designed. All other design components/objects shall not care about measurements reporting mechanism and the interaction with OML. This class derived three child classes for respective applications.
Figure 1. Class Hierarchy for OrbitApp
All functions to call OML are put as pure virtual functions in this base class. OTG/OTR/OTFApp can select to implement a subset of those functions. This design has some advantages:
- to make OTF to reuse the Stream/Port/Gate structure of as a combination of OTG/OTR
- to share some common functions for all OTG/OTR/OTFApp, such as close()
The class has a Boolean variable to indicate if OML will be used or not. If it is false, all measurement reports will be redirected to a local log file. This is a special debugging mode. And it could also be served as a means to use OTG outside of ORBIT testbed.
OML calls are actually implemented externally by OML-client libraries. So, special header files are fetched dynamically in compilation. Those header files have to be included here. For example:
- #include "oml_orbit_winlab_otg.h" in otg_application.h
- #include "oml_orbit_winlab_otr.h" in otr_application.h