Unlike some simulation products, FLAMES® is not a low-level toolkit or a proprietary programming language that requires months of programming before any useful application can be executed. Unlike other simulation products, FLAMES is not a fixed, non-modifiable set of computer programs that can only be modified or enhanced by Ternion.
FLAMES is a full-featured, commercial-off-the-shelf (COTS) simulation system that comes complete with several, fully implemented, FLAMES-based applications. These applications, called the Standard FLAMES Applications, allow you to define, execute, visualize, and analyze a wide variety of scenarios the instant you finish installing FLAMES on your computer. But more importantly, FLAMES is also an open, customizable simulation system that lets you develop the custom simulation applications that you need to meet your modeling and simulation requirements. This section of Ternion's Web site provides an overview of how FLAMES can be customized to meet your requirements.
FLAMES is licensed in two basic types of system configurations: runtime systems and development systems. Runtime systems allow only the execution of FLAMES-based applications, including the standard applications that are supplied with FLAMES as well as the custom applications that you and others develop. Development systems allow both the development and execution of FLAMES-based applications. Development systems include the FLAMES Kernel in non-modifiable, object library format; object libraries for multiple standard, FLAMES-based applications; and source code to the models that are supplied with FLAMES.
Most often, custom applications are developed simply by adding new models to the standard FLAMES applications. (See the section on FLAMES Models for a description of the many types of models supported by FLAMES.) This approach allows the FLAMES Kernel and the standard applications to do almost everything for you and allows you to concentrate fully on the functionality of your particular model. Another approach is to develop new applications that are built upon the services and classes of the Kernel. This approach is preferred when your simulation task is markedly different than the tasks addressed by the standard applications or when you wish to perform the task in an entirely different way. You might develop a new application to import data into the FLAMES scenario database from some other existing database, or you might want to construct a special-purpose scenario generation application tailored to the requirements of a particular type of user. Whatever the case, FLAMES can usually allow you to develop the simulation you need in the most cost-effective and timely manner possible.
The steps you must take to develop a custom, FLAMES-based application are, at a high level, the same steps that you take to develop most any other type of application. You write the source code, compile it to get object code, and then link the object code with the proper libraries to get an executable program. At a lower level, however, there are some significant and important differences in the steps you must take. Most of these differences come in the way you write the source code.
If you choose to develop a custom, FLAMES-based application by adding a new model to a standard FLAMES application, you must first select the FLAMES primary class to which your new model will belong. Having done this, you can use the FLAMES Code Generator to generate a "shell" of your new model that conforms to the specifications dictated by the primary class which you are inheriting. The Code Generator produces code in both C and C++ (the two modeling languages officially supported by FLAMES) that can be compiled, linked, and used in a FLAMES application without modification. However, the code will not yet contain any of your attributes or specific algorithms. These you must add yourself. Another way to get started is to copy and rename an existing FLAMES model that might be similar to the new model you wish to create.
All FLAMES models conform to well-defined specifications-specifications that are based on strict object-oriented programming principles and that are documented in detail in extensive developer documentation supplied with FLAMES. By conforming to these specifications, you ensure that your model will work properly in a FLAMES application and be able to exploit all of the power of the services of the FLAMES Kernel. You will also ensure that your model will be plug-and-play compatible with the Kernel and most likely with other FLAMES models as well. Ultimately, you will minimize the amount of work required to create and maintain your new model.
Your next major step is to edit the model using the text editor of your choice to add your specific attributes to the definition of the model class, add the model-specific code to the methods required by the FLAMES class you have inherited, and, if necessary, add new methods of your own. As you do this, you might integrate code from a model that exists in another simulation, or you might write the algorithm code from scratch. Whatever the case, new models can usually be developed in a matter of days, and sometimes hours, especially if the models incorporate software already resident in some other simulation. This is because database management, graphical user interfaces, memory management, post-processing, and a host of other important issues are already addressed by the FLAMES Kernel and the applications delivered with FLAMES.
Once the source code to your model has been written, the source code
is compiled using a standard language compiler native to the particular
computer you are using. The compiled code is then linked, again using
the standard linker resident on the host computer, with the compiled code
of other models and the compiled code of the FLAMES Kernel and the operating
system. The result is a new executable program-a custom, FLAMES-based
application.
No changes must be made to the Kernel or to other models to integrate your
new model. The work required to integrate a new model, work that can be
quite extensive in other simulations, is essentially nonexistent with
FLAMES. Through the religious application of object-oriented and other
advanced programming techniques, the Kernel provides a "software
back plane" to which models can be attached in much the same way
as integrated circuit boards plug into a computer. All models developed
according to FLAMES-defined specifications are "plug compatible"
at the object code level. This means that models can be modified or added
without modification (or even recompilation) of the Kernel or other models.
Custom FLAMES applications, hence, are created simply by "plugging
in" various combinations of models.
As is described elsewhere on this Web site, the services of the FLAMES Kernel are designed to provide a host of powerful, fully integrated simulation functionality - functionality that is essential to advanced simulations. Any application that is developed based on FLAMES will immediately become more flexible, powerful, reliable, and easier to use than the same application developed based upon another environment. More importantly, very little effort on the part of the model developer is required to exploit the features of FLAMES. Most features are provided automatically to any model implemented in FLAMES and allow the models to be much smaller than the same models implemented in other simulation environments. The result is software that is much easier to develop, debug, maintain, and enhance, which ultimately leads to tremendous cost savings and significantly enhanced reliability.
Cost savings are increased even more by the way FLAMES makes true software "reuse" possible. Once a model is written to be integrated into the FLAMES framework, it is instantly available for use with other FLAMES models in many different types of FLAMES-based applications. Therefore, the benefit derived from the investment of implementing a model in FLAMES is automatically extended significantly.
The development capability furnished by FLAMES can revolutionize the way simulations are developed, maintained, and used throughout the United States and the rest of the world. Today, hundreds of software development organizations are developing models that satisfy their own modeling requirements but are useless to most other organizations. If these models were developed to be FLAMES compatible, the models could be shared between organizations, thereby greatly reducing redundant model development and significantly enhancing the simulation capability available to each organization. Because FLAMES models are "plug-compatible" at the object code level, models could be exchanged, if desired, without requiring the developing organization to release source code. This would allow the developing organization to maintain configuration control over the model and to protect the organization's "charter." Such model exchange could even take place between the services and between the militaries of different countries. The resulting cost savings and increase in simulation capability would be staggering.
