How often have you experienced the results of a simulation that didn’t align with your expectations? It’s happened to us all at some point, we design something and either handed it over to a “simulation team” or even performed the simulation ourselves, only to see the results that were not at all what we’d hypothesized. When this happens, we are often are left scratching our heads wondering if the error is real, or perhaps an error in our simulation – a perplexing problem to be sure!
The system models we create in GENEYS are inherently a static representation of the descriptive architecture of our system, but, as we all know, systems are not static. Systems are dynamic, and their emergent behavior comes from the interrelationships between their physical and behavioral aspects. Our models specify the system behavior, so why can’t we turn them on and execute that behavior and dynamically verify that our behavior is working as we intended? Good news, GENESYS is built around this very concept! Executable specification – model your system specification and execute it all in one.
What benefits do we get if we build an executable spec? Simply put, if the behavioral model has errors, those errors will manifest themselves in the specification and eventually in the system itself. If they’re not caught and left to your Test and Evaluation team to find, the cost to your system will be exponentially higher. Using good MBSE practices and simulation will allow you to exercise your specification in ways that will find problems early on and allow you to fix them. I’m not promising that it will fix everything, but overall you will be in much better shape than if you just write the specification in document form without modeling. Find integration problems early, don’t wait!
GENESYS provides the ability to perform dynamic analysis, timeline analysis, resource analysis and flow analysis directly on your behavior models (a.k.a. your specifications). Let’s take a look at these four types of analyses. It’s worth pointing out now that, as we go through these different types of analyses, the cost in effort and time increase substantially. It may or may not make sense for you to invest the time and resources needed to do all the analyses possible, so tailor what you do to your needs. Furthermore, the access to the underlying API in GENESYS allows for an unprecedented amount of flexibility within the range of dynamic behavior analyses being discussed here.
Let’s start with dynamic analysis. Dynamic analysis is simply assessing the consistency of your system behavior model. Does the model have any obvious logic problems? Does the model have deadlocks? Does the model have functions that can never be triggered and aren’t taken care of logically (think kill branches in parallel constructs or using timeouts)? Does the model complete consistently? These are all very common issues with behavior models and GENESYS makes it very easy to detect these sorts of problems.
When you build a behavior model in GENESYS you’re building an executable model by default. Dynamic analysis is free, just run the simulator and assess the results. The simulator will tell you if you have any of the aforementioned problems in your behavior model. Finding these errors in your executable specification early helps to keep simple mistakes in the logic from propagating into the product to be discovered later on in test, or even worse, in deployment.
The second analysis in our increasing scale is timeline analysis. This entails adding approximate durations to our behaviors to assess the overall execution timeline of the behavior model. Durations can be added to each behavior by simply specifying a constant value, or you can use a distribution and assign the parameters for that distribution to that behavior. This type of analysis requires the modeler to assess the duration of each behavior and determine the best distribution to use to approximate its execution time. A lot of effort on the part of systems engineers will need to be expended to determine the correct durations and, of course, these durations are only as good as their engineering judgement.
Now that you have a single execution through your model with varying durations, perform a Monte-Carlo analysis with the model. Simply put, Monte-Carlo analysis is running the model through a single execution of the behavior, capturing all the decisions being made, the duration values returned by the distribution then recording the results from that single execution, and then executing it all over again, and again, and again, for a statistically significant number of times. When the simulation completes, analyze the iterative data, determine the average values, and you’ll arrive at the most likely overall durations for your behavior model and the likelihoods of events occurring in your model.
If done properly, timeline analysis can provide extremely useful insight to your systems behavior. Can the system perform the desired functionality within the time constraints required? Imagine building a test behavior model, and being able to vary the durations of the Test Activities – you could start to build predications of the test execution time, and have all the knobs to tweak to assess different impacts to your test program!
The third type of analysis is resource analysis. Resource analysis allows your model to capture, consume or produce resources, and can help you assess the impact of having finite resources on the behavior of your model. Resources can be anything the system consumes, captures or produces. For example, if my model is consuming power, power can be a resource. If there’s not enough available power the execution of the functionality will be delayed until power is freed up by another function, or more power is produced by another function.
With specified resources, you can model the expected resource loading and look for any delays in execution of your behavior when the required resources were not available. The GENESYS simulator shows the resource as red when needed resources are not available. GENESYS will also show you the time that each behavior was waiting for the resource to become available. Alternately, you can run the resources without constraints and see what it will take from a resource perspective to accomplish your desired behavior.
The fourth type of analysis readily available in the GENESYS simulator is flow analysis. This is conceptually a simple concept. Items have a size attribute, and links have a capacity attribute. Items are transferred by links, so during the execution of the simulation if the link doesn’t have enough capacity to transfer all the items, then a delay in transmission of the item is experienced.
As you can imagine, taking the time to understand the item size and the capacity of the carrying link is no easy task. Imagine a digital bus with messages modeled as items, each message has a size in bits, and each bus by which the message is transferred has a capacity. Utilizing flow analysis, you could look for places where the execution of the model is delayed because the bus was saturated, waiting to transfer the message items, and then observe the effects of the delays on triggered behaviors.
These four types of analyses are not all the analyses that GENESYS is capable of performing. Through the use of the built-in scripting language and the API, the sky is really the limit for what you can add to the simulations. You can use the scripting language to add in logic for behavior based on variables. The scripting language allows you to vary the inputs for each run of the simulation as well, allowing flexibility in the each run of the simulation. You can use the scripting language to really expand what’s going on in your model below the surface.
The models developed in GENESYS represent the specification of your system. You model the system architecture, and then GENESYS builds your specification from the model. Executing that exact same model ensures that what you’re simulating is in fact the same model that your specification is built from, they cannot be different. If you make a change to the model to debug the simulation, you’re in fact debugging your specification at the same time. This is a win-win!
The different analyses presented here can help you detect flaws in your system during initial design stages. Finding these flaws early is truly the most powerful impact that MBSE can provide to your system. The fewer escapes that make it to test, or worse, to the fielding of your system, the more value you as a systems engineer can provide to your program.
