17 The concept of cooperative simulators Václav Přenosil Masaryk University, Brno 17.1 Introduction To explore the characteristics and capabilities of the motor vehicle drivers as the optimal solution is to use interactive (full mission) simulators, which allow induction of both normal and abnormal situations arising on public roads. Needs to increase the credibility of environment simulation is necessary in addition to the model and the image of real environment to simulate a conventional car drivers and road users behavior as well. Mathematical models of the road user behaviors are far from the actual behavior of the current driver in real road traffic. Based on the experience, consultations and the conclusions of the ITEC and the I/ITSEC international conferences, appears as optimal design the external environment model with a number of cooperating entities produce situations like the actual traffic on public roads. Cooperating objects in the model of the external environment may be model of behaving according to a deterministic algorithm with implemented semi-automatic or heuristic behavior. The behavior of these models is design formerly and their responses can be expected in many cases over a longer practice. For maximum similarity to the normal traffic on public roads should be a cooperative objects set up another simulator (or group of simulators) operated by another driver - operator. This simulator is not necessarily full mission simulator. Regarding the situation of examining the behavior of one driver, simplest handlers known from computer games are sufficient. The fundamental problem with this solution is to create a realistic model of the external environment, the development of mechanisms for using this environment by cooperative objects and, ultimately, build a credible model of the test vehicle. Plenty of studies, proposed and concrete solutions of simulators were executed. Also, in modeling the external environment was made a number of realizations. Need for cooperation of multiple types of simulators have been implemented in a number of international technology and standards efforts, which resulted in the definition of group of protocols. For the cooperation of independent objects are very often use the Distributed Interactive Simulation protocol (DIS) and more actual High Level Architecture protocol (HLA). For modeling the external environment are arising SEDRIS standards. The competitor of the DIS is the ALSP protocol, which is not so widespread. Advantages of both ones were taken over and the HLA protocol was achieved as a standard. The development of HLA protocol is very closely follows, but the most widespread protocol is currently DIS. In its favor, unlike HLA, also speaks that it is accepted as standard (standardization process of the HLA proceeds - its notation should bear shortcut IEEE 1516). DIS protocol is aimed at data exchanging and its focus is on working with data (as it organized, how it to send, how it to decode). DIS places no requirements on the internal architecture of simulation software. In development of the simulator the working is focused at lower levels of communication than in HLA. HLA, unlike DIS, disposes of a communication subsystem that is part of its RTI (Runtime Infrastructure). Simulation does not have to worry about how and where to send information. HLA provides the ability to use the services described in the HLA specification and application communicates only with RTI. Both forms of distributed simulation have their advantages and disadvantages. HLA is comfortable (even if the obligations to be met is a great amount), but DIS operates much more quickly again (no overhead communication between RTI simulators). In the present situation is such that even though there is a more modern version for distributed simulation, DIS is not dead protocol. Twice a year in Orlando, Florida on University of Central Florida held meeting of experts who have continuously improved the DIS protocol and expanding it. See the completion of the IEEE 1278.1a in August 1998. Nevertheless, the DIS protocol options are limited. But there are a number of practical applications and therefore is clear that in the foreseeable future will not be abandoned. Standardization of the external environment models and its characteristics with regard to the weather is not quite finished yet. Many unsolved problems of compatibility of data sources and database of terrain and weather greatly complicate the development of mutually compatible simulation systems. 17.1.1 Introduction to HLA The HLA is a technical architecture developed to facilitate the reuse and interoperation of simulation systems. The HLA allows distributed simulation systems to be developed and executed for a range of diverse applications in a standardized manner. These applications can be applies to a wide variety of tasks including analysis, experimentation, acquisition, testing, training, or education. HLA allows combining existing simulation systems with new systems, mixing different programming languages and/or operating systems. HLA does not prescribe any specific implementation, nor use of any particular set of software or programming language. HLA was inspired by several earlier simulation protocols such as Distributed Interactive Simulation (DIS) and Aggregate Level Simulation Protocol (ALSP). These individual technologies played an important role in various simulation domains but were not totally capable of meeting the demands of the M&S community such as interconnecting simulations with different time management schemes (the relationship between simulated time and wall clock time and the methods for controlling simulated time). The HLA was initially developed by the US DoD, under the leadership of the former Defense Modeling and Simulation Office (DMSO), in response to the clear recognition of the value of M&S to support a wide variety of military applications, as well as the need to manage M&S systems as a cost effective tool. The aim of the HLA was to provide a structure to support the potential for the reuse of capabilities available in different simulations, resulting in a reduction in the cost and time required to develop distributed simulation systems in accordance with new requirements. The selected definition of an architecture as intended in HLA - major functional elements, interfaces, and design rules, pertaining as feasible to all simulation applications, and providing a common framework within which specific system architectures can be defined - is one that is commonly accepted and is consistent with the architecture definition provided by Institute of Electrical and Electronics Engineers (IEEE). Two major versions of the HLA were published: first the US DoD HLA 1.3 standard (1998) and second the IEEE 1516-2000 standard (developed by the Simulation Interoperability Standards Organization (SISO)). The HLA IEEE Std 1516-series was published in 2000 as an open standard. An update to the HLA standards known colloquially as”HLA Evolved” was published in 2010. HLA 1.3 was superseded by IEEE Std 1516 series. The basics of the HLA paradigm have not changed since the first US DoD 1.3 version, but the subsequent IEEE versions have provided significant improvements and additional capabilities. Software to support the HLA is available from government, academia, and commercial organizations. In addition a recommended practice for the use of HLA, the Federation Development and Execution Process (FEDEP), has been published by IEEE as IEEE 1516.3-2003, issued in 2003 (see reference [6]). 17.1.2 Functional Overview of the HLA Next figure illustrates how a HLA federation is decomposed into its major functional components, i.e. · A set of “Federates”, · A middleware named “Runtime Infrastructure” (RTI) with standardized Application Program Interfaces (API). According to IEEE Std 1516, a federate application is an application that supports the HLA interface to a runtime infrastructure (RTI) and that is capable of joining a federation execution. Typically a federate is a simulation application but may be an interface to a live system, or a support utility such as an event logger or performance monitor. A federation is a named set of federate applications and a common Federation Object Model (a specification defining the information exchanged at runtime) that are used as a whole to achieve some specific objective.” Figure: Functional View of a HLA Federation All application object representations are in federates. Application objects represent entities, processes etc., within the federation domain of interest. The HLA imposes no constraints on what is represented in the federates or how it is represented, but it does require that all federates incorporate specified capabilities to allow the application objects in a simulation to interact with application objects in other federated simulations. This is achieved through the exchange of data values supported by services implemented in a common federation communication infrastructure (the RTI). The set of federates is the first functional component of HLA. The second one is a Runtime Infrastructure (RTI), middleware that provides the common communications infrastructure for the federation. An RTI provides a set of general services that support federate-to-federate information exchange, time synchronization and coordination, and federation management support functions. All exchanges between federates have to be performed through an RTI. The third functional component of the HLA is the “federate interface specification” that provides a set of standard APIs for federates: · to request services from an RTI, · to invoke RTI services to support runtime exchanges among federates, · and to respond to requests from an RTI. 17.1.2.1 IEEE Std 1516, HLA Framework and Rules The HLA rules summarize the key principles behind the HLA. The rules are divided into two groups: 5 federation rules and 5 federate rules that together ensure the proper interaction of federates in a federation. The federation rules settle the basic rules for creating a federation including requirements for documentation, object representation, data interchange, interface requirements and attribute ownership. The federate rules apply to individual federates and refer to documentation requirements, control and transfer of relevant object attributes and time-management. 17.1.2.2 IEEE Std 1516.1, HLA Federate Interface Specification The HLA federate interface specification describes the runtime services provided by an RTI. There are seven classes of services as defined in IEEE Std 1516.1: · “Federation management. These services allow federates to establish communications, establish a federation execution, and manage its overall conduct. · Declaration management. These are services that allow federates to declare the types of information that they will supply to the federation execution, and the types of information they will receive from the federation execution. The RTI is responsible for delivering data between producers and consumers per these declarations. · Object management. These are services that federates use to include specific modeled objects […] in the federation execution, and to exchange information between these objects and the federation execution. · Ownership management. These are services that can be used across the federation execution to delegate to a specific federate the responsibility for supplying information about a modeled object. The responsibilities may be reassigned dynamically during execution. · Time management. These services allow simulations to operate with a logical concept of time and to jointly maintain a distributed virtual clock. These services support discrete event simulations and assurance of causal ordering among simulated actions. · Data distribution management. These services provide information delivery tailored beyond declaration management. · Support services. These are miscellaneous services utilized by joined federates for performing such actions as name-to-handle and handle-to-name transformations, setting advisory switches, manipulating regions, and RTI start-up and shutdown.” The HLA federate interface specification defines the way these services are accessed, both functionally and via different APIs. 17.1.2.3 IEEE Std 1516.2, HLA Object Model Template HLA “object models” are descriptions of the essential sharable elements of a simulation or federation in 'object' terms. The HLA requires that each federate and the federation document their HLA “object models” using a HLA-specific standard Object Model Template (OMT). This template is intended to be the means for open information interchange across the community to facilitate reuse of simulations. The HLA specifies two types of “object models”: the HLA Federation Object Model (FOM) and the HLA Simulation Object Model (SOM). · The HLA FOM describes the set of information, which is shared across a federation. · The HLA SOM provides information on the capabilities of a federate to exchange information as part of a federation. The SOM is essentially a federate ‘contract’ defining the types of information it can make available in federations and also the kind of information it can receive from the other federates. The availability of the SOM facilitates the assessment of the relevance and value of the federate for participation in a federation. The SOM is required for HLA compliance testing. While the HLA does not define the data contents of a SOM or FOM, those must be documented in accordance with the HLA OMT format. 17.2 HLA training program audience and delivery decisions One of the objectives of the Task Group was to identify the need for HLA education and provide high level education via an appropriate mechanism such as lecture series, seminars, tutorials, or workshops. The MSG-050 membership agreed that there was a continued need for HLA education and training, and that this need went beyond the technical level to include management aspects and the identification of benefits to the operational community. The focus of the proposed education package was discussed in terms of the objectives it was to fulfill, the intended audience for delivery, and the appropriate mechanism to be used for delivery. The MSG-050 membership determined that there were sufficient sources of HLA technically oriented courses available, either within nations or from commercial sources. Thus development of another technical course did not seem to be the most productive path. As well, there already existed a NATO M&S lecture series on M&S integration, covering many of the technical aspects of M&S. Based on this, and considering the available resources of the Task Group, it was decided to focus on the management aspects of implementing HLA and its supporting processes. The decisions was made direct the education package to an audience of senior decision makers, procurement personnel, and project managers; as this appeared to be an area given little attention to date. A key recognition was that this audience may have little M&S background, thus the material presented would need to include some fundamental information on the M&S and its value to various applications. The Task Group decided that this education package should not exceed one day in length, as it was considered that this audience probably could not take any lengthy period of time for training. It was also suggested the course be developed with a modular structure to enable it to be sub divided for delivery if required. The various delivery mechanisms were examined. The lecture series format requires a significant lead time for approval and formal preparation of the arrangements with the host nation. In general lecture series usually extend over two to three days. While the costs of a lecture series are paid by NATO, it was thought that a lecture series format was not appropriate for this particular management focus due to the proposed duration of the education package, the availability of lecturers, and due to the fact that the target audience was not necessarily connected to the M&S community. A more effective approach was thought to be delivery at a venue where our target audience might be in attendance for other reasons as well. It was decided that this education package needed to be concise and well structured in order to deliver the maximum information within a short period; thus the tutorial format was favoured over the symposia approach in order to ensure a cohesive presentation. In summary the MSG-050 Task Group decided to produce an education package in tutorial format not exceeding a day in length aimed at management issues of HLA directed to a non M&S audience of decision makers, procurement professionals, and project managers. The final product, “Manager’s Guide to HLA,” resulted in a tutorial presentation of four hours duration. To date, this tutorial has only been presented once, at the ITEC 09 conference in Brussels, Belgium. Approximately 20 individuals attended the presentation, and from all indications, the tutorial was well received. 17.2.1 Training program syllabus The objective of the training package is to provide non-M&S oriented individuals with knowledge and insight into the management issues required to develop and implement M&S and HLA. There was no intent to deliver detailed technical information with the expectation of audience participants being able to build a simulation. As the target audience was not expected to have background knowledge of M&S or HLA, a certain amount of background material was included to ensure sufficient understanding of the objectives and content. A modular structure was maintained within the tutorial syllabus. The specific objectives of the tutorial included: · Benefits of using M&S; · Issues to be considered to implementing M&S and HLA; · Benefits of using HLA; · Systems engineering process for HLA; and · Resources required to effectively employing HLA. The syllabus was structured under the following headings; · Objectives · M&S Introduction · HLA Overview · Resource Considerations · Federation Development Process · Use Cases · Summary 17.2.2 Training Program Recommendations During the final meeting of MSG-050, the Task Group developed the following recommendations relative to the HLA Training package. · NATO MSCO should place the “Manager’s Guide to HLA” training materials (in editable PPT format) on the RTO Collaborative Workspace so that anyone with an NMSG account can access the material. · NATO MSCO, NMSG, and NMSG member nations should utilize the training materials to conduct HLA Manager’s training to meet their needs, and through this process, improve the content · NMSG members who utilize and update the training materials should post the updates to the same RTO Collaborative Workspace environment area from which they were obtained. · When training is conducted, only an non-editable version of the training materials (e.g., PDF file) should be distributed to participants. · When the training is conducted, the trainers should obtain feedback from the audience and archive that information so that it can be used to improve the course. · NATO MSCO should monitor downloads and uploads of updates, and if a high volume of changes appear, should recommend to the NMSG that an activity be established to manage the training materials. · Consideration should be given by translating the training materials into a SCORM-compliant Advanced Distributed Learning course. 17.3 Conclusion With the growing requirements for simulation and development of technology is its HLA protocol, which for modeling and simulation provides a powerful and flexible framework. Regarding the transition simulator compatible with the DIS protocol, as the best approach appears to be using the Protocol Interface Unit (PIU), providing maximum flexibility while ensuring minimal risk and cost of transition. References [1]... MSG-025 TG-018, The Implementation of HLA compliance certification within NATO and NATO/PfP nations. RTO NATO, 2008. [2]... Steel, J: The Use of DIS and HLA for Real-Time, Virtual Simulation – A Discussion. http://ftp.rta.nato.int/Public/PubFullText/RTO/MP/RTO-MP-071/MP-071-10.pdf [3]... Final Report for NATO MSG-050, HLA Working Group, RTO NATO, 2011.