Design and Implementation of Hierarchical RTI (HRTI)

Transcription

1 Design and Implementation of Hierarchical RTI (HRTI) Jung Hyun Ahn Tag Gon Kim Systems Modeling Simulation Laboratory, Korea Advanced Institute of Science and Technology (KAIST) Kuseong-dong, Yuseong-gu, Daejoen, Korea Keywords: HRTI, HLA, Selective Information Control, Hierarchical Federations ABSTRACT: High Level Architecture (HLA) is a standard architecture for interoperation between heterogeneous simulations, and Runtime Infrastructure (RTI) is the implementation of the HLA interface specification. A limitation of the current HLA is that it allows only single federation and the federation has one Federation Object Model (FOM) which is merged with different organizations. In addition, the information hiding problem which opens all data within their federation is raised. To overcome such limitations, we propose an architecture of Hierarchical Runtime Infrastructure (HRTI). The objectives of HRTI are 1) being compliance with HLA interface and 2) supporting multiple federations with hierarchical structure in any depth. This paper deals with the design and implementation of HRTI and the selective information control which is the solution of the information hiding problem. Furthermore, as HRTI makes a federation to be a joined federate at the higher federation level without any modifications of federate code, it promotes HLA interoperability and reusability at the federation level. The proposed HRTI is implemented by applying the Dynamic Link Compatible (DLC) APIs with C++. The design and the experimental results show that the HRTI may facilitate the practical usage of simulation interoperations by ensuring the selective information hiding while the HRTI complies the existing HLA standards 1. Introduction The High Level Architecture (HLA) is an IEEE 1516 standard for interoperation between heterogeneous simulators which are developed with different languages and platforms [1]. HLA provides a common framework within which simulation developers can structure and describe their simulation applications. Under HLA, a composable set of interacting simulations is called a federation, and a component of whole simulation system is called a federate which executes together into the federation. Since HLA is an architecture, not software, using Runtime Infrastructure (RTI) software is required to support operations of a federation execution. RTI is a software which implements the IEEE Federate Interface Specification which defines Application Program Interface (API) for HLA services. RTI provides commonly required services to its federates for cooperating in their execution [2]. The aim of HLA is promoting the interoperability between simulations and aiding the reuse of models in different contexts. The interoperability of HLA can be achieved by conforming to the Federate Interface Specification. Federates in the same federation communicate through the RTI via the standard interface provided by HLA. The reusability of HLA can be achieved by the Object Model Template (OMT), which forms a documentation standard describing the data for a particular model. OMT is used to describe Simulation Object Model (SOM) and Federation Object Model (FOM). Each federate shall have a SOM specifying the information that the federate uses. A federation shall have a FOM specifying the union of data handled by multiple federates in the federation. With its capability well defined in the SOM, a federate then could be also reused in another federation. The current HLA allows a single federation, one level of hierarchy. HLA does not support hierarchical federations which are constructed multiple federations interoperated each others. There is no specification about relations among federations in HLA. More specifically, a joined federate in a federation cannot interact with other joined federates in another federation through RTI although two federations are running at the same time. To do so, all federates should belong to the same federation. Federates are limited within context of a single federation. HLA considers that a federation has only one FOM. Since HLA allows a single federation, if different 111

2 federations are executed together, they should be merged into federates in one federation which has one FOM. All data types should be opened in the FOM in order to construct the federation. Even if there are some data types that are used only in some federates, those types should be included in the FOM. All federates in a single federation are able to access FOM data (e.g., objects, interactions and dimensions). This single federation does not suffice for applications with multiple security levels. This is called Information hiding problem [3-5]. Information hiding problem is about security problem. During the process of merging two or more federations together, unnecessary information for interoperation which is secure FOM data only for internal use must be exposed to build a merged FOM. Some federates may require that certain information only be shared among related federates, not all federates in a federation. If any federates decided to subscribe information defined in the FOM, there is no way to prohibit them from receiving it. This is a quite critical problem when two or more nations are involved in military applications or different competitive companies are included in distributed supply simulations. However, in the current HLA, the solution of information hiding problem is not existed. Considering that the HLA is often used in the defense simulations, protecting critical information and ensuring interoperations are two critical problems that should be pursued at the same time. This paper aims to address the two problems by suggesting a hierarchical interoperation architecture. Besides such limitations, a single flat federation is not adequate to model complex systems with hierarchical components [6, 7]. Hierarchical structure of models or simulators is essential to simulate complex and large systems. If the hierarchical structure of models is applied to RTI, it is needed to map into federates in one federation. This mapping probably ruins the original hierarchy and raises several issues related to security and reusability [8-10]. In this paper, we will propose an architecture of Hierarchical RTI (HRTI) to overcome limitations of the current HLA. HRTI provides a general approach to support interoperability and reusability at the federation level. This paper deals with the design and implementation of HRTI and the selective information control which is the solution of information hiding problem. In the remainder of this paper is organized as follows. Section 2 briefly presents related background information and some selected related work. Section 3 introduces our proposal for HRTI. Section 4 focuses on selective information control. This section explains how security information is managed by HRTI while consistently constructing of hierarchical federations. Section 5 deals with issues in the implementation of HRTI. In the Section 6, a queuing system is exemplified as a case study for hierarchical federation. The example shows that not only HRTI complies to HLA specification, but it can also be practically used in hierarchical federation. Finally, our conclusions are presented in Section Related Work There have been many researches that bring hierarchy among federations or enable inter-federation communication by introducing additional federates [11]. The efforts to overcome previous limitations and to support hierarchical structure of federations without modifying current RTI software or HLA specification have been made. The most common approaches, HLA bridging and the hierarchical federations, suggest many possibilities of API-level bridging, but the restriction to security FOM data access makes it almost impossible to build bridges without modification of HLA specification. Figure 1: Bridge federate and Hierarchical federation. Bridge federates are used to provide a link between federation executions [12]. The bridge federate is able to join any number of federation executions simultaneously, but must create separate RTI ambassadors and federate ambassadors for each federation execution it is joined. The federation can be linked using configuration of many bridge federates. The bridge federate consists of three parts: surrogate s F, surrogate s G which is a federate that interacts with the a connected federation and transformation manager that communicates with the surrogates and translates between the two FOMs between the linked federations, shown in Figure 1 (a). The bridge federate might be implemented various filtering and transformation function on events, 112

3 translating information from one federation to the other federations. Several bridge federates manage asymmetric data flows and are applied to bi-directional transformation functions as necessary. These federates have been dependent on the Federation Interface Specification, as well as relevant FOM data. HLA specification does not provide enough time management information for bridge federates to adequately ascertain the synchronization requirements of federates. Bridge federates must be able to find the next event times of component federates to synchronize correctly with other federation execution. all federates to call the services in order to initiate callback functions in all federates. It is unavailable for RTI or federates to know when all federates have done the consensus services. 3. Proposed HRTI 3.1 Objectives of HRTI However, it is almost impossible to achieve information hiding, because the bridge federate may be joined two or more federations and it can acquire to all of the information within each of these federations. Each bridge federate must build a unique set of transformation operations between two representative FOMs/federations. And it should be clear that a universal bridging capable of joining federations will not be possible, in general. On the other hand, hierarchical federations are a generic architecture which is extended by bridge federates to link federations at different levels and supports hierarchical composition [5, 13]. Hierarchical federations arrange those federations in a tree-like architecture and are connected by gateway federates. The gateway federate performs as the bridge federate s activities and enables connectivity between different level of federations to make a gateway federation. In Figure 1 (b), the gateway federation is at a higher level of federations and is combined individual federation (e.g., user federation) is at the leaf level of federations. Unlike the bridge federate, the gateway federate connects the gateway federation and only one of federations which can be a user federation. In hierarchical federations, multiple level of hierarchy of federations would be possible. As the gateway federate can filter out information that a federation does not open to all federates, information hiding problem is solved through the gateway federation. These previous approaches are suggesting special federates or architecture that manages information flow among two or more federations interoperating. However, they are only temporary solutions since the interconnecting federates have limited accessibility on internal RTI states. These approaches cause some problems such as a consensus problem unless the HLA specification itself is revised [12]. The consensus problem happens by using consensus services (e.g., Federation Save or Federation Restore) which require Figure 2: Support of hierarchical federations in HRTI To overcome limitations of a conventional HLA/RTI, we propose an architecture of HRTI which provides a general approach to support interoperability and reusability at the federation level. The objectives of HRTI are based on the following issues: 1) Compliance with HLA specifications: HRTI should have compliance with the conventional HLA specifications, especially in terms of backward compatibility. HRTI guarantees that there is no modification required in the HLA compliant legacy simulators. 2) Multiple federations with hierarchical structure in any depth: HRTI should provide a general framework for support of hierarchical federations to interoperate with federations. A set of more than one concurrently executing federations can interoperate with one another. HRTI internally establishes the hierarchical structure of federations. The components in HRTI are constructed with two types, federation execution process and federate. All leaf nodes are federates and others are federation execution processes. The hierarchy of federations helps managing information flow control in 113

4 the HRTI. Figure 2 shows the support of hierarchical federation in HRTI. 3.2 Hierarchy Specification and Configuration of HRTI We describe how to specify the hierarchical structure of federations in HRTI. HRTI represents hierarchical relations between federations, which are as organization into a hierarchy structure. Since HRTI is based on the hierarchical composition tree, HRTI hierarchically provides the representation of a structured graph which is defined as follows. More formally, a hierarchy is a tuple H = (F, E), where F is the set of federations and E = { e e i, j = (i, j), i, j F } is the set of joined edges in HRTI. H is the structure which is a directed simple and connected graph. If e i, j is in E, then n i is called the upper federation of n j, and n j is the lower federation of n i at n i, n j F. initializes the hierarchy configuration from specification of hierarchical structure, H. Actually, the hierarchy configuration is achieved by RTI execution process. As the H s establishment is responsible to users, the users make the hierarchy file which contains setting information of hierarchical federations. The hierarchy file format has a rule that the left and right parentheses are used for scoping which is related between upper federation and lower federation and must always be used in matching pairs such as Figure 3. RTI execution process creates federation execution processes at the same location with the RTI execution process. If there is a federate which is scheduled to join a federation, the federate must call the Create Federation Execution service using the federation s FOM, before the Join Federation Execution service is called. And then, the created federation joins the upper federation by the specification of hierarchical structure. When the lower federation joins the upper federation, the lower federation throws own FOM to the upper federation and the upper federation makes internal FOM put together from union of all lower federation s FOMs. 4. Selective Information Control Figure 3: Hierarchy to represent nested parentheses. The hierarchy can be represented an algebraic formula involving nested parentheses, in other words, a hierarchical composition on how the construction of hierarchical architecture is configured. Figure 3 shows the representation of hierarchical structure of federations, a target system of federation A. The hierarchical federation A is composed of three federations B, C and D. The upper federation A has three joined edges (A, B), (A, C) and (A, D), respectively. The federation B and D are divided by E, F and G, H. In this way, we specify hierarchical relationship of federations. To define the hierarchical information of federations is responsible to users who want to simulate the hierarchical federations in HRTI. As one of the objectives of HRTI is committing the compliance with HLA specifications, HRTI should follow HLA definitions, HLA rules and HLA services. When the Create Federation Execution and Join Federation Execution services are conducted, HRTI This section discusses some mechanisms, selective information control, about the solution of information hiding problem. Data dissemination is based on a publish-subscribe model where producers can publish data and consumers can subscribe their interested data in HLA. Each producer or consumer must refine interested data to a FOM. Along with the support of selective information control in hierarchical federations, HRTI will provide the complex processing about the FOM management and renewal. The main design concept is to efficiently partition the complex FOM data and distribute the interested FOM data to a possessive federation which has the control ownership of FOM data and decides whether the FOM data is filtered or not. HRTI allows dynamic data allocation and control for selective information in a distributed way. Before handling the selective information control, there is consideration about internal/external FOM. A federation execution process in the middle of the hierarchy filters out data from/to upper federation. The federation is a representative federate to upper federation. Supporting of the hierarchical structure of federations requires the extension of conventional FOM. The conventional FOM not only contains the shared data inside the federation, but also includes the filtered 114

5 information which securely sends or receives. But, in HRTI, the federation has implicitly internal FOM. The internal FOM is the union of all lower federation s FOMs and is used only in inner federation. Explicitly, the federation has external FOM which is same as the conventional FOM which the federation execution is created. The external FOM has shared information. According to the internal FOM, the federation execution process automatically controls the flow of events which is filtered out in hierarchical federations. Figure 4: Class Hierarchy of internal FOM and external FOM. As the FOM has a class hierarchy which specifies defining the information exchanged at runtime in a given domain, relationships among FOM data can be represented as a hierarchy. Figure 4 illustrates the class hierarchy of specific internal FOM which is a triangle of a dotted line and external FOM which is a triangle of a line. As the external FOM is not included the filtering data and the internal FOM is the union of all lower federation s FOMs, the internal FOM may be different from external FOM at an individual federation. Obviously, the external FOM is the subset of the internal FOM because of the security FOM data. HRTI has two processing stages for the selective information control: FOM management/renewal and dynamic data allocation. FOM management and renewal create an efficient administration while consistently meeting a constraint of the hierarchical structure, and dynamic data allocation finds ownership of information control while reflecting by dynamics of federations. FOM Management and Renewal: It is dynamically accomplished as follows. To automatically construct a internal FOM, the federation may update implicitly internal FOM which is the union of all lower federation s FOMs when federation execution is created or the created federations is joined the upper federation by specification of hierarchical structure. If a lower federation execution is destroyed, the FOM of that federation is extracted in the internal FOM. To construct and maintain own internal FOM, federations consistently monitor presence of their lower federations. HRTI manages and renews internal FOM according to the presence of federation execution creation or destruction. For example, the procedure of FOM management and renewal can be fulfilled by constructing the hierarchical structure of federations which is shown in Figure 5. There are five federations and each federation has own FOM. After federation D is created, federation A, C and D s internal FOM are updated by considering the relation of the class hierarchy. Assume that federation E is destroyed like as in Figure 6. After federation E is destroyed, federation A and C s internal FOM are updated. In this manner, internal FOM can be managed and renewed according to creations /destructions of the dynamic federation. HRTI provides the consistent maintenance of runtime FOM management and renewal. Figure 5: The FOM management and renewal when federation D is created. Figure 6: The FOM management and renewal when federation E is destroyed. Dynamic Data Allocation: After FOM management and renewal, HRTI iteratively has next processing stage for selective information control, which is reflected by dynamics of federations. HRTI collects federations which are concerned about the specific FOM data within external FOMs. Aggregated federations result in interested federations which are related with the FOM data and have a possibility of production/consuming of the FOM data. And then, HRTI assigns a unique federation (possessive federation) ID at the individual FOM data according to possessive allocation algorithm. The possessive federation is the highest federation in the interested federations. The selective information control can be succeeded in HRTI because the unique possessive federation can control the FOM data whether 115

6 is filtered or not in distributed environment. The dynamic data allocation is the stage of processing to apply the algorithm of possessive allocation, shown in Figure 7. Possessive allocation algorithm : Determine whether a federation is the possessive federation { Wait for reflection of present federations at the FOM management and renewal stage } if a federation is created (federation id = fed i ) then for each FOM data internal FOM do insert fed i in interested federations end for end if if a federation is destroyed (federation id = fed j ) then for each FOM data internal FOM do remove fed i in interested federations end for end if if interested federations size > 0 then for each FOM data internal FOM do if interested federations!= {} then find the highest federation in interested federations grant the highest federation s id to the possessive federation end if end for end if Figure 7: Possessive Allocation Algorithm. hierarchical fashion. While forming the internal FOM, HRTI precedes the selective information control by fulfilling the possessive allocation algorithm. HRTI internally serves and maintains the FOM structure as well as the hierarchical structure of federations. The resulting structure in Figure 8 consists of federation A, B, C, D and E that are associated with the internal FOM or the external FOM. Table 1 shows the result of fulfilling the possessive allocation algorithm at the hierarchical structure of federations. Using this information, the individual federation can obtain the ownership of the security FOM data and filter the security FOM data to upper federations. The possessive allocation algorithm will configure and renew the interested federations and the possessive federation, which are shown in Table 1. In this example, there are seven FOM data from a to g. In case of the FOM data(a), the FOM data(a) s interested federations are {B, D, E}. After performing the possessive allocation algorithm, given the interested federations, the FOM data(a) s possessive federation is A which is the highest federation in the interested federations. Table 1: Allocation for possessive federation. FOM data interested possessive federations federation a {B, D, E} A b {B} B c {B, D, E} A d {D} D e {E} E f {B, C, E} A g {D} D 5. Implementation of HRTI In order to being compliance to HLA specification, the HRTI follows HLA definitions, HLA rules and HLA services. Figure 8: An example of hierarchical federations, in which each federation has own FOM. To further illustrate the possessive allocation algorithm, we consider the example of Figure 8. It shows hierarchical structure of federations for constructing the internal FOM. Basically, the internal FOM is recursively updated by dynamics of federation in The Implementation of conventional RTI is not required any specification in the HLA standards. However, HRTI implements the SISO DLC HLA API 1516 which is becoming the SISO Standard and supports dynamic link compatibility, which was problematic with the original IEEE 1516 API [14]. HRTI is adopted the DLC APIs which are served as the basis for the C++ API for the HLA Evolved Specification. A user does not need to be recompiled or relinked to switch among dynamic-linkcompatible RTI implementations that have been built using the same compilers. 116

7 federation. The federation execution is almost same functionality at LRC of federate. The manager component of the federation allows grouping of composition of federations and administrates the member of federations. The communication component part supports interacting with federates as well as federations. 5.2 Management Areas In this section, we deal with the main managements in HRTI. Each management is handled by a relatedmanager. HRTI contains three managers, namely federation manager, object manager and time manager. Figure 9: Overall architecture of HRTI In this section, we describe the detail of overall architecture of HRTI which supports the hierarchical structure of federations. We choose the architecture of HRTI with federation execution process of which the functionality and hierarchical relation are clear. According to type of process coordinating, it can be divided two types: federation execution processes and federates. 5.1 The Process Model A federate is an application that is capable of joining a federation execution and is coupled with other federates in the federation execution. The federate has a local RTI component (LRC) as internal maintenance module. The implementation of LRC is almost same in different venders of RTI [2]. LRC communicates with its associated federation execution process, while the federation execution process exchanges data within joined federates as well as its parent federation execution process. The LRC in the federate largely consists of the presentation component mapping the HLA services to inside components, the manager component relating HLA services and communication component supporting reliable and best effort communication in HRTI. The federation execution process is a process which manages and controls the whole federation. The main role of the federation execution process is controlling the events which are related with exchange data or synchronization of the federation s time in the Federation Manager (FM): It provides a federationwide support and configures hierarchical structure of federations by the hierarchy file. FM also dynamically discovers the presence of federation execution creation or destruction. It keeps and handles statuses of joined federates. FM collects and merges the external FOM, and makes them to the internal FOM. It stores and manages some information which are members of federation, save/restore, synchronization point, timesynchronization and routing table for publish/subscribe federates in inner federation. Object Manager (OM): It is related with the data exchange in HRTI. From the internal FOM which is applied the dynamic data allocation, it handles the publication and subscription data and maps between publishers and subscribers. Dynamically, as it reflects the update of the internal FOM, the data consistency is achieved. OM stores and manages some information which is accommodation HLA services (e.g., declaration management, object management, ownership management and data distribution management). Time Manager (TM): It coordinates and updates its logical time when requesting to advance its time. TM calculates the greatest available logical time (GALT) and controls their logical time advance. It is responsible to deliver the Time Stamp Order (TSO) messages, and TM makes OM deliver proper TSO messages, actually. TM stores and manages some information which is time regulation/constrained option setting, lookahead and individual logical time. 6. Example: Single Server Queue Model 117

8 In this section, we discuss how the hierarchical structure of federations is constructed and how to use HRTI environments by using a single server queue (SSQ) model. The SSQ model is commonly used as a component in computer and/or communication systems. Simulation of the SSQ model enables us to prove the usefulness of HRTI and to identify the selective information control to solve the information hiding problems. 6.1 Single Server Queue(SSQ) Model Figure 10 shows the model of SSQ which is a job processing system. Consider the SSQ federation has two federations, after mapping hierarchical federations. Those are the Generator-Transducer (GT) federation and the Buffer-Processor (BP) federation. GT federation is an environment model supplying a job to BP and collecting outputs. BP federation is a server model which is queuing with the job and processing the job. GT federation has two federates, generator and transducer, and BP federation has two federates, buffer and processor, respectively. SSQ federation has two federations, GT federation and BP federation, respectively. GT federation has own FOM, GTFOM, and BP federation has own FOM, BPFOM. Figure 11 shows the interaction class structure of each federation. In order to achieve the selective information control at each individual federation, the federation can manage the ownership of control which selectively enables specific FOM data update. In Figure 11, the interactions flow into or out of each federation in SSQ federation. These interactions, Generator to Buffer Interaction (GB_Int) and Processor to Transducer Interaction (PT_Int), are shared FOM data. On the other hand, the security FOM data, Transducer to Generator Interaction (TG_Int), cannot be opened to other federations except in GT federation. The TG_Int is available inside of GT federation, but BP federation is not able to receive the TG_Int. Therefore, it is possible to keep internal data secured for the selective information control. Figure 10: the SSQ example to mapping hierarchical federations The generator federate produces jobs at a predefined rate and sends them to the buffer federate. Once receiving the job, the buffer federate controls the flow of incoming jobs. The buffer federate forwards it to the processor federate, if the processor federate is free, otherwise the buffer federate saves it until the processor is available. After finishing the job, the processor federate reports a result to the transducer federate and sends an acknowledge message to the buffer federate so that another job can be sent. The transducer collects the job s interval statistics between incoming time of the buffer federate and output time of the buffer federate. When a termination condition meets, the transducer federate sends a stop message to the generator so that no more jobs are generated in generator federate. 6.2 Selective Information Control in SSQ Federation Figure 11: FOM of the SSQ Components The SSQ s federations, GT federation and BP federation, are component modules which can be developed independently in the large scale. By adopting the component technology to the HRTI, reusing of existing federations can reduce the whole simulation system developing time. As HRTI makes the federation to be a joined federate in a higher-level federation, it promotes and extends interoperability and reusability of HLA at the federation level. 6.3 Experimental Results This section describes some experimental results on the selective information control and the performance of the hierarchical federations. In order to achieve the selective information control in the proposed HRTI, we extend SSQ federation with more hierarchy depths. The middle federation in SSQ federation are Higher SSQ(HSSQ) federation, Lower 118

9 SSQ(LSSQ) federation, GT federation and BP federation. The hierarchical structure of SSQ federation is arranged while varying the hierarchical levels. The arrangement of SSQ federation with hierarchy depths is shown in Figure 12. Furthermore the GT federation and BP federation can be reuse at various hierarchy mapping. As HRTI makes GT federation and BP federation without any modifications of federate code, it promotes HLA reusability at the federation level. information hiding at the hierarchical structure of federations in SSQ federation. For example, the TG_Int is available only inside of GT federation. Therefore, the success of information hiding is achieved by selective information control in SSQ federation. Table 2: Success of Information Hiding at SSQ federation hierarchy FOM possessive success of data federation information hiding TG_Int SSQ No h = 1 BP i _Int SSQ No PB i _Int SSQ No TG_Int GT Yes h = 2,3,4 BP i _Int BP i Yes PB i _Int BP i Yes The objective of the performance check is to compare the performance of flat federation and hierarchical federations. The experimental results of SSQ federation are evaluated and compared to study the performance of our proposed HRTI. The SSQ federation was carried out on Intel Core2 Quad 2.66GHz PC ran Microsoft Windows XP with 3GBytes of RAM memory. As mentioned previously, RTI execution process creates federation execution processes at it s the same location. The whole federations are same platform to run. We focus on the whole execution time of SSQ federation and CPU utilization at SSQ federation which is the highest federation, but can be a bottleneck because of many joined federates. Figure 12: Arrangement Hierarchical Mapping with Depths In order to verify the success of information hiding in the proposed HRTI, the extension of SSQ federation is exemplified, and each federation can selectively control the specific FOM data. As mentioned earlier, in the extension of SSQ federation, interactions are security FOM data (e.g., TG_Int, BP i _Int(s) and PB i _Int(s)) which must be not opened to other federations. When the hierarchy of SSQ federation is 1(flat), the whole information is included in FOM of SSQ federation. All of security FOM data are available in SSQ federation. SSQ federation does not have success of information hiding. On the other hand, when the hierarchy of SSQ federation is two or more hierarchical levels, the ownership of information control is distributed at each possessive federation. Table 2 shows the success of The SSQ federation was simulated while varying the following two parameters. The first parameter is the hierarchy of SSQ federation. If it is 1, SSQ federation is treated as a flat federation. If it is 4, SSQ federation has more complex configuration in hierarchical structure of federations. The second parameter is the number of jobs which are generated by the Generator federate. The workload is proportional to the number of jobs increases. A lot of jobs will require more processing time. Figure 13 shows the execution time and CPU utilization at SSQ federation for variable workloads, and shows the tendency characteristic with variable parameters. We experiment while increasing the number of jobs and the hierarchy of SSQ federation. The total number of jobs is 100, 200 and 400. The hierarchical level is 1 - flat, 2, 3 and 4, respectively. The first experiment measures the execution time and second experiment measures the CPU utilization at the highest SSQ federation with hierarchical levels. 119

10 In this paper, we have proposed the architecture of HRTI to develop efficient hierarchical structure of federations. Our system is designed on objectives that HRTI may be compliance with HLA standard and support multiple federations with hierarchical structure in any depth. This paper deals with issues in the design and implementation of HRTI and the selective information control which is achieved by possessive allocation algorithm. The proposed HRTI is implemented by applying the DLC APIs with C++. The example of SSQ federation shows that not only HRTI complies to HLA specification, but it can also be practically used in hierarchical federation. In addition to the advantage of hierarchical federations, the selective information control is succeeded in SSQ federation. The example of SSQ federation describes how to simulate in HRTI and is experimented with variable parameters. We are currently working on development of a prototype HRTI. We have plans to research the effects of the hierarchical structure on the performance of simulation. Acknowledgement Figure 13: Execution Time and Average CPU Utilization in SSQ federation As shown in Figure 13, when the number of jobs increase, the execution time increases as well. As the number of jobs becomes larger, the processing time in each federation increases. If the hierarchical level is increased, the execution time also increases. This means that a little performance decrease happens, because the information is sending and receiving through the hierarchy. On the other hand, the average CPU utilization at the highest SSQ federation is almost consistent, when the number of jobs increases. It is high when the federation execution process has many joined federations (or federates). The performance is affected how many joined federations (or federates) are linked. If the federation execution may directly manage large-size federations (or federates), CPU utilization is high, whereas the federation execution may manage smallsize federations (or federates), CPU utilization is low. Therefore, HRTI can provide a resource distribution among federations at the required hierarchical structure of federations. If the federation execution processes is distributed and indirectly manage small-size federations (or federates), the resource distribution is well and the resource utilization is good. 7. Conclusions and Future works The authors gratefully acknowledge support for hierarchical federations from the Korea Science and Engineering Foundation under grant R (2006). 8. References [1] IEEE Standard for Modeling and Simulation (M&S) High Level Architecture (HLA), IEEE Std , [2] Defense Modeling and Simulation Office, High Level Architecture RTI Interface Specification, Version 1.3, April [3] G. Magee, G. Shanks and P. Hoarea, Hierarchical Federations, Proceedings of the 1999 Spring Simulation Interoperability Workshop, 99F-SIW [4] Myjak, M.D. and Sharp, S.T., Implementations of Hierarchical Federations, Proceedings of the 1999 Fall Simulation Interoperation Workshop, 99F-SIW-180. [5] W. Cai, S.J. Turner and B.P. Gan, Hierarchical Federations: An Architecture for Information Hiding, Proceedings of the 15th Workshop on 120

11 Parallel and Distributed Simulation, pp , [6] A. Cramp, J. Best, and M. Oudshoorn, Time Management in Hierarchical Federation Communities, Proceedings of 2002 the Fall Simulation Interoperability Workshop, 02F-SIW [7] Aoyama, K., Ninomiya, S., Takeuchi, Y., Miyajima, S. and Tsutai, A, Hierarchical Multi- Federation Structure of the Sensor Data Fusion Simulation in JUSA, Proceedings of the 1998 Fall Simulation Interoperability Workshop, 98F- SIW-045. [8] Jae-Hyun Kim and Tag Gon Kim, Federate-Level Reusability: Joining a Federation with SOM Document Data, Proceedings of the 2004 Spring Simulation Interoperability Workshop, 04S-SIW [9] Jae-Hyun Kim and Tag Gon Kim, Proposal of High Level Architecture Extension, Lecture Notes in Computer Science, Vol. LNAI 3397, pp , [10] Jae-Hyun Kim and Tag Gon Kim, Hierarchical HLA: Mapping Hierarchical Model Structure into Hierarchical Federation, M&S-MTSA'06, Ottawa, Canada, pp , July, [11] Granowetter, L., RTI Interoperability Issues API Standards, Wire Standards, and RTI Bridges, Proceedings of the 2003 European Simulation Interoperability Workshop, 03E-SIW-077. [12] Dingel, J., Garlan, D. and Damon, Bridging the HLA: Problems and Solutions, Proceedings of the 6th IEEE International Workshop on Distributed Simulation and Real-Time Application, pp , JUNG HYUN AHN is currently a Ph D. candidate at the School of Electrical Engineering and Computer Science, Korea Advanced Institute of Science and Technology (KAIST). He received a B.S in Electrical Engineering in 2005 from the Pusan National University and a M.S. in 2007 from KAIST. His research interests include methodology for modeling and simulation of discrete event systems, hierarchical federation and high level architecture/runtime infrastructure. TAG GON KIM received his Ph.D. in computer engineering with specialization in systems modelling and simulation from University of Arizona, Tucson, AZ, He was an Assistant Professor at Electrical and Computer Engineering, University of Kansas, Lawrence, Kansas, U.S.A. from 1989 to He joined at Electrical Engineering Department, KAIST, Tajeon, Korea in Fall, 1991 as has been a Full Professor at EECS Department since Fall, He was the President of The Korea Society for Simulation (KSS). He was the Editor-In-Chief for Simulation: Transactions for Society for Computer Modelling and Simulation International(SCS). He is a co-author of the text book, Theory of Modelling and Simulation, Academic Press, He published about 200 papers in M&S theory and practice in international journals and conference proceedings. He is very active in defence modelling and simulation in Korea. He was/is a consultant for defence M&S technology at various Korea government organizations, including Ministry of Defence, Defence Agency for Technology and Quality(DTAQ), Korea Institute for Defence Analysis(KIDA), and Agency for Defence Development(ADD). He is a Fellow of SCS and a Senior Member of IEEE. He developed a tools set, call DEVSimHLA for HLA-compliant war game models development, which has been used for development of three military war game models for Navy, Air Force and Marine in Korea. [13] K. Briggs, A Required RTI Gateway standard as a solution to RTI interoperability, Proceedings of the 1999 Spring Simulation Interoperability Workshop, 99S-SIW-188. [14] Granowetter, L., The Dynamic-Link-Compatible C++ RTI API for IEEE 1516, Proceedings of the 2004 Fall Simulation Interoperability Workshop, 04F-SIW-086. Author Biographies 121