A true framework that supports almost any modeling and simulation requirement imaginable.

The monolithic architecture of most simulations makes them very time-consuming and expensive to modify as technology and requirements change. Rather than modify an out-of-date simulation, it is often easier and cheaper to build a new one. This explains why there are so many different simulations in use today and why nearly every major new simulation currently under development is not based on a predecessor. Unfortunately, new simulations continue to be based on monolithic designs and will someday also need to be abandoned.

The limited architectures of both old and new simulations have resulted in the waste of literally billions of software development dollars. Even worse, many pressing requirements for more advanced simulations remain unsatisfied.

Unlike fixed, monolithic simulations, all FLAMES®-based simulations make use of the unique and powerful FLAMES simulation framework architecture. This architecture makes simulations much less expensive to develop and maintain, because the vast majority of the software in every simulation is the same. Just as importantly, the architecture of FLAMES greatly simplifies the development of the custom software needed to support almost any modeling and simulation requirement imaginable, now and in the future.

A True Framework Architecture

“Application Independence” and “Stable and Robust Interfaces” are two aspects of the FLAMES architecture that make it a true framework architecture and that distinguish it from the architectures of most other simulations.

The software of any simulation can be divided into two categories: modeling software and infrastructure software. Modeling software represents the state and behavior of things that exist in the real world, such as vehicles, sensors, weapons, humans, etc. Infrastructure software has no real-world equivalent and exists only because the application is a simulation. Infrastructure software creates and/or manages such things as time, memory, databases, execution control, inter-process communication, external interfaces, visualization, and graphical user interfaces.

In most simulations, the infrastructure software and the modeling software are intertwined and inseparable. This is one of the main reasons why most simulations are so difficult and expensive to maintain and modify. Adding new modeling software often necessitates changes to the infrastructure software, and changes to the infrastructure software often ripple through the entire simulation and require changes to all the existing modeling software.

The framework architecture of FLAMES completely isolates the infrastructure software from the modeling software. All of the infrastructure software is resident within the FLAMES framework. All of the modeling software is outside of and separate from FLAMES. This makes FLAMES completely independent of application-specific modeling software. Some of the benefits of this independence include:

  • Flexibility. Time and again, the FLAMES architecture has proven its ability to support almost any type of model you will ever need.
  • Control. You have access to and complete control over the source code to all of the modeling software, because none of it resides in FLAMES.
  • Savings. Simulations are much less expensive to develop and maintain, because the infrastructure software in every simulation is provided by FLAMES. You develop and maintain only the modeling software.

In a true framework, infrastructure and modeling software must be more than isolated and independent. The framework must also clearly define the interfaces between the infrastructure and modeling software so that developers will know how to develop new modeling software that is compatible with the framework. Interfaces are most useful if they are stable and robust. An interface is stable if it does not change, or changes very little, as new capabilities are added to the framework. This keeps models from having to be modified each time a new version of the framework is released. An interface is robust if it has proven over time to support nearly all types of models. This helps keep the framework and existing modeling software from becoming obsolete.

In FLAMES, all modeling software resides in software “components.” Each component is an individual software class that is derived from one of the primary classes defined by FLAMES. These primary classes play a major role in defining and enforcing the interfaces to the FLAMES framework. Over two decades of continuous use have made these interfaces very stable and very robust.

The component interfaces defined by FLAMES have matured to the extent that components can be placed in “plugins” that are automatically recognized and integrated whenever a FLAMES application starts. As a result, the “software integration” step is essentially non-existent. This plugin interface dramatically reduces the amount of time and money required to create a new component for FLAMES. In addition, end-users (non-software developers) can quickly compose the simulations they need by merely copying the desired component plugins to their computer.

There are many simulation products that are described as frameworks. However, few of them are true frameworks in the same sense that FLAMES is a framework. Most products that are described as frameworks are actually monolithic applications that support some measure of customization. Just because an application supports a programming interface that allows you to modify or add some new capability does not mean it is a framework.

As described above, a true framework is completely independent of application-specific modeling software. To test if an application is a true framework, try to separate the framework from the modeling software. Can you do it? Can you completely remove all the modeling software from the application — without making any changes to any source code? If you can remove the modeling software, then try to execute it. Will it still execute? If the application is truly independent of the modeling software, it will still execute after all modeling software has been removed.

FLAMES can pass this test. All modeling software is resident in component plugins that are totally separate from FLAMES. You can remove all component plugins from your computer, and FLAMES will still execute successfully.

The benefits of using a simulation based on the proven, true framework architecture of FLAMES are hard to exaggerate.