Template Driven Code Generator for HLA Middleware
conference paper
HLA is the accepted standard for simulation interoperability. However, the HLA services and the API that is provided for these services are relatively complex from the user point of view. Since the early days of HLA, federate developers have attempted to simplify their task by using middleware that shields of the intricate details of HLA from the simulation application code. TNO Defence, Security and Safety is convinced of the advantages of HLA middleware and supporting code generation tools. The middleware layer that we use to develop federates is called the TNO Run-time Communication Infrastructure (RCI). The RCI provides the federate developer with an abstraction layer to shield of the underlying interoperability standards, such as HLA 1.3 and IEEE 1516. The RCI middleware and code generation support reuse of federate components and allow a federate developer to focus on the actual functionality of the federate, because the federate's interface code is (re)generated very easily. The RCI library provides all kind of services that are independent from the Federation Object Model (FOM), while the RCI code generator takes care of all the federate's FOM dependent interface functionality. The code generator provides the federate developer with object classes for all Object Model Template (OMT) object and interaction classes and OMT datatypes in the FOM. The generated object classes have methods that correspond with the HLA object attributes, interaction parameters, and datatype fields. The code generator is able to generate source code in the desired target programming language, e.g. C++ or Java, and for the desired HLA API, e.g. HLA 1.3 or IEEE 1516. This paper discusses the results of our research into code generation based on the HLA OMT. The new generic code generator that was recently developed by TNO is template driven and consists of a front-end and a back-end. The front-end is the parser that reads the OMT file and converts it into an in-memory model. The back-end is the template engine that uses template files to generate the code. The template engine replaces all generic instructions in the template file with real data as defined by the actual FOM. By defining a template for each combination of target programming language and target HLA API, the code generator is very well maintainable and very flexible. Object model development and configuration management are difficult parts of the FEDEP. Incompatible FOMs and also incompatible usage of the same FOM often prevent re-use of federates in other federations. We need a better way to develop and maintain our FOMs, including their semantics and usage. The Base Object Model (BOM) concept presents such a solution. The BOM describes the conceptual model of a component's behaviour and the mapping of this conceptual model to the FOM. This approach fits very well in TNO's component architecture. In our view, the BOM concept supports reuse of 'models' rather than reuse of 'code'. A model driven federate development provides more flexibility and more opportunities for reuse. This paper presents how TNO intends to incorporate the BOM concept in the code generator tool. In future, the input of the code generation process should shift from the SOM or FOM to the BOM. This paper will also discuss some of our proposed BOM extensions that could be useful in a code generation process, e.g. directives for secured attributes and for bandwidth control.
TNO Identifier
222470
Source title
Fall Simulation Interoperability Workshop (SIW), 16-21 September 2007, Orlando, FL, USA, paper 38
Files
To receive the publication files, please send an e-mail request to TNO Repository.