Resource Aware Modeling & Simulation

RAMS is a methodology for performance analysis and system optimization that uses simulatable models to leverage the distinction between behavior and platform.  The first step of a RAMS process is using a Modeling Language to create models of both the behavior and platform.  Next, the behavioral model is mapped to the platform model.  Finally, we simulate the resulting composite model to evaluate the performance and behavior of the system.  We'll explore this process in more detail below.  We also have a whitepaper (PDF) that fully covers RAMS and provides additional examples.

Modeling the Behavior

We model the behavior of the system using traditional functional modeling techniques.  This aspect of the system usually consists of an interconnected network of functional components that combine to provide the complete behavior of the system.  This network can generally be decomposed hierarchically in order to manage complexity.  The behavior of the system includes data flow, control flow and functional component behavior (i.e. state machine, data transformation, hand-shaking, etc.).

A complete behavioral model can be simulated without a platform model in order to functionally verify the model and system.  This confirms that the behavior will produce the correct output, given the necessary inputs, and has been the primary value of traditional functional modeling and simulation.

Modeling the Platform

The platform is modeled by assembling representations for the resources required to implement the behavior.  Resources can include people, electronic components, networks, software services, power, space and etc.  Two fundamental types of resources are considered:

Process Resources perform work of some nature.  The rate at which they accomplish work is a primary characteristic.  When a request is made of a Process Resource, that request will take time to fulfill.  The rate may be variable and a Process Resource may have interdependent relationships with other resources.  For instance, when you order a sandwich at the deli counter, some waiting is often involved.  The person who makes the sandwiches must become available and then construct the sandwich.  The sandwich maker is an example of a Process Resource.

Quantity Resources represent a quantity of something.  They are characterized by a quantity, which indicates their capacity.  When a request is made of a Quantity Resource, that request will either succeed, thereby reducing the current quantity of the resource by the requested amount, or fail, leaving the quantity unchanged.  If the request succeeds, the requestor can continue and, if appropriate, return the requested amount when finished.  If the request fails, the requestor can choose to wait until the necessary resource becomes available, request a lesser amount, or continue without.  Computer memory is a common example of a Quantity Resource.  Programs make requests for memory, which either succeed or fail, and return memory to the pool when it is no longer needed.

Platform models are made up of a combination of Process and Quantity resources.  They are often layered, as are the real world architectures that they represent.  The resources in platform models can communicate, supporting cases where the response of one resource depends on the state of another resource.  The modeling environment also provides for the creation of custom resources that are capable of manifesting very complex interactions.

The Composite Model

Mapping the Behavioral Model to the Platform Model creates the composite model.  Resource requests from the functions in the behavioral model to named resources in the platform model establish this correspondence.  The ease of making changes to the mapping within the Foresight environment enables trade studies and portability of the behavioral model across platform models.

Simulation of the composite model exposes a number of system characteristics for analysis, including temporal behavior (resource requests implicitly insert delays into the model), resource utilization and costs.  The ability to fully understand each of these dimensions of the system makes it possible to optimize against the original requirements.  Bottlenecks, heavy users, and other problem areas are easily identified allowing the design team to precisely target the most important areas for improvement.  Trade studies can be used to evaluate alternative architectures (in the behavioral design, the platform design, or both) in order to identify the best solution to any deviations from the requirements.

Introducing RAMS Page:  1 - 2 - 3 Foresight's Approach to RAMS