Academia.eduAcademia.edu

Figure 3 – uploaded by Alberto Falcone

See full PDFdownloadDownload figure
Figure 3: UML Class diagram of the Model Service. The main Java classes and interfaces of the Model Service are shown in Figure 3 by using a UML Class Diagram.

Figure 3 UML Class diagram of the Model Service. The main Java classes and interfaces of the Model Service are shown in Figure 3 by using a UML Class Diagram.

Related Figures (8)

Figure 1: Architecture of a HLA Federation based on the DKF. Falcone, Garro, Anagnostou, and Taylor
Figure 1: Architecture of a HLA Federation based on the DKF. Falcone, Garro, Anagnostou, and Taylor
Figure 2: UML Class diagram of the Logging Service. The Logging Service provides functionalities useful to both track down any problems and errors that occurred during the DKF use, and understand how the DKF core modules work. Also, this service logs messages and information coming from HLA Federates running in a Federation execution. Each of them uses the logging service API to interact with the logging modules so as to store information messages in the logstream. The Logging Service writes, at regular time intervals, the logstream into the dkftrace.log file. The structure of the Logging Service is shown in Figure 2 by using a UML Class Diagram.
Figure 2: UML Class diagram of the Logging Service. The Logging Service provides functionalities useful to both track down any problems and errors that occurred during the DKF use, and understand how the DKF core modules work. Also, this service logs messages and information coming from HLA Federates running in a Federation execution. Each of them uses the logging service API to interact with the logging modules so as to store information messages in the logstream. The Logging Service writes, at regular time intervals, the logstream into the dkftrace.log file. The structure of the Logging Service is shown in Figure 2 by using a UML Class Diagram.
The Configuration Service offers a set of services that manage the configuration parameters, which ire provided through a * json file, make them consistent and use them to con figure dynamically the other KF services. Two kinds of parameters are managed by the Configuration Service: Federation and ‘ederate parameters. The Federation parameters are used to properly load, configure and execute a HLA listributed simulation (HLA Federation); they include the name of the Federation Execution, the RTI -onnection details (e.g., IP address, listening port, etc.) along with data related to the simulation time (e.g. ILA time regulating, HLA time constrained and simulation ephoc). The Federate parameters represent he information related to the simulation module (HLA Federate) and include information such as, the ype (FederateType) and name (FederateName) of the Federate that are used by the DKF Core Service to -onfigure the Federate and its Federate Ambassador (IEEE Std. 1516-2010). Figure 4 shows the main java classes and interfaces of the Configuration Service through a UML Class Diagram.
The Configuration Service offers a set of services that manage the configuration parameters, which ire provided through a * json file, make them consistent and use them to con figure dynamically the other KF services. Two kinds of parameters are managed by the Configuration Service: Federation and ‘ederate parameters. The Federation parameters are used to properly load, configure and execute a HLA listributed simulation (HLA Federation); they include the name of the Federation Execution, the RTI -onnection details (e.g., IP address, listening port, etc.) along with data related to the simulation time (e.g. ILA time regulating, HLA time constrained and simulation ephoc). The Federate parameters represent he information related to the simulation module (HLA Federate) and include information such as, the ype (FederateType) and name (FederateName) of the Federate that are used by the DKF Core Service to -onfigure the Federate and its Federate Ambassador (IEEE Std. 1516-2010). Figure 4 shows the main java classes and interfaces of the Configuration Service through a UML Class Diagram.
more time to improve its simulation module without worrying about low-level implementation detail since the DKF manages them. The ExecutionThread class handles the execution of a HLA Federate in the simulation environment, whereas the DKF AbstractFederateAmbassador class implements the methods that are called by the RTI for interacting with the Federate (RTI callback methods) along with the NullFederateAmbassador interface, which is used by a Federate to access the RTI services. With reference to the life cycle of a HLA Federate provided by the DKF AbstractFederate, in it is shown through a UML statechart diagram.
more time to improve its simulation module without worrying about low-level implementation detail since the DKF manages them. The ExecutionThread class handles the execution of a HLA Federate in the simulation environment, whereas the DKF AbstractFederateAmbassador class implements the methods that are called by the RTI for interacting with the Federate (RTI callback methods) along with the NullFederateAmbassador interface, which is used by a Federate to access the RTI services. With reference to the life cycle of a HLA Federate provided by the DKF AbstractFederate, in it is shown through a UML statechart diagram.
Figure 6: UML statechart diagram of a HLA Federate’s life cycle.
Figure 6: UML statechart diagram of a HLA Federate’s life cycle.
tity VARY ULIUT Ul UI LH ANUVY UNLIAVIV Vi Liv vpuVitiv SRMULTGALW ULLIITINU Lil UI POUL LEVO Vip Vvaly plat. If unexpected events or exceptions occur during the life cycle, the execution flow of the Federate’ behavior stops running and a transition to the exception handling state is performed. This latter state is responsible for managing the event/exception; if it is correctly handled, the running state is entered at the history state meaning that the execution flow is resumed where it last left off, otherwise a transition to the shutdown state is performed and, during the state transition, the HLA Federate is disconnected from the RTI. Figure 7 shows the structure of the Utility Service through a UML Class Diagram. This service provides support functionalities to the simulation components (HLA Federates) using the framework.
tity VARY ULIUT Ul UI LH ANUVY UNLIAVIV Vi Liv vpuVitiv SRMULTGALW ULLIITINU Lil UI POUL LEVO Vip Vvaly plat. If unexpected events or exceptions occur during the life cycle, the execution flow of the Federate’ behavior stops running and a transition to the exception handling state is performed. This latter state is responsible for managing the event/exception; if it is correctly handled, the running state is entered at the history state meaning that the execution flow is resumed where it last left off, otherwise a transition to the shutdown state is performed and, during the state transition, the HLA Federate is disconnected from the RTI. Figure 7 shows the structure of the Utility Service through a UML Class Diagram. This service provides support functionalities to the simulation components (HLA Federates) using the framework.
Falcone, Garro, Anagnostou, and Taylor For the sake of clarity, t he coder/decoder classes related to a specific HLA data type have been grouped in a single UML Class element. Specifically, the HLAInterger16/32/64BECoder represents the three classes: HLAInterger! 6BECoder, HLAInterger32BECoder and HLAInterger64BECoder that manage the coding and decoding of an HLAIntegerBE attribute (Falcone et al. 2017, IEEE Std. 1516- 2010). In the same way, the HLAInterger32LECoder and HALAInter ger 16/32/64LECoder characterizes the HLAInterger16LECoder, HLAInterger64LECoder classes for handling a HLAIntegerLE attribute (Falcone et al. 2017, IEEE S classes showed in Figure 8. d. 1516-2010). Analogous consideration can be done for the rest of the
Falcone, Garro, Anagnostou, and Taylor For the sake of clarity, t he coder/decoder classes related to a specific HLA data type have been grouped in a single UML Class element. Specifically, the HLAInterger16/32/64BECoder represents the three classes: HLAInterger! 6BECoder, HLAInterger32BECoder and HLAInterger64BECoder that manage the coding and decoding of an HLAIntegerBE attribute (Falcone et al. 2017, IEEE Std. 1516- 2010). In the same way, the HLAInterger32LECoder and HALAInter ger 16/32/64LECoder characterizes the HLAInterger16LECoder, HLAInterger64LECoder classes for handling a HLAIntegerLE attribute (Falcone et al. 2017, IEEE S classes showed in Figure 8. d. 1516-2010). Analogous consideration can be done for the rest of the
Table 1: Comparison in building DKF and no-DKF based Federate. In HLA, each Federate must declare the published/subscribed Objects and their attributes and Interactions and their parameters. These attributes and parameters are then updated during the Federation execution. Without the DKF, these attributes and parameters should be manually declared in the Federate Class one-by-one and then manually update each element during runtime. With the DKF, using the provided Java annotations, these published/subscribed classes are annotated as @ObjectClass ot @InteractionClass accordingly. Also, the elements are annotated as @Attributes or @ Parameters in their respective classes. Another consideration when developing a distributed simulation is the data types and how they are encoded. These should be explicitly stated in the FOM, individually for each published/subscribed element data type. The DKF provides a coder package and the specific coder can be added where the element is annotated (see Section 2.3). Another difference is the time advance management in the Federate. Without the DKF, the REPAST Federate uses the scheduler provided by the simulator to manage TAR and TAG actions, while via the DKF the time advance is managed by the RTI.
Table 1: Comparison in building DKF and no-DKF based Federate. In HLA, each Federate must declare the published/subscribed Objects and their attributes and Interactions and their parameters. These attributes and parameters are then updated during the Federation execution. Without the DKF, these attributes and parameters should be manually declared in the Federate Class one-by-one and then manually update each element during runtime. With the DKF, using the provided Java annotations, these published/subscribed classes are annotated as @ObjectClass ot @InteractionClass accordingly. Also, the elements are annotated as @Attributes or @ Parameters in their respective classes. Another consideration when developing a distributed simulation is the data types and how they are encoded. These should be explicitly stated in the FOM, individually for each published/subscribed element data type. The DKF provides a coder package and the specific coder can be added where the element is annotated (see Section 2.3). Another difference is the time advance management in the Federate. Without the DKF, the REPAST Federate uses the scheduler provided by the simulator to manage TAR and TAG actions, while via the DKF the time advance is managed by the RTI.
Related topics:
Computer Science
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved