Recommendations for moving past the example models

A place for discussing topics that do not fit into the other Simulink/Stateflow categories

Recommendations for moving past the example models

Postby busser » Wed Apr 08, 2009 9:29 am

Here is a common question that we often get with new users/evaluation teams, etc. I have chosen to add this to the Forum so as to make a reply visible to all Forum Users. (Bob)

We have worked through some of the examples that come with the installation package and are able to get the results we expect. Now we would like to continue our evaluation process learning curve by applying Simulink Tester to real development models that are representative of our actual product models. Do you have any recommendations as to how to proceed in this endeavor ?
busser
Site Admin
 
Posts: 52
Joined: Thu Mar 13, 2008 7:42 pm

Re: Recommendations for moving past the example models

Postby busser » Wed Apr 08, 2009 10:31 am

We actually prefer that new customers attend a training class before embarking on such a task. Simlulink Tester and the T-VEC Vector Generation System (VGS) encompass many new concepts and technologies that most new users are unfamiliar with, there being no other tools available that are similar in technology and capability. But in lieu of formal training, though not a replacement for it, I would like to offer some initial guidance.

  • Stepping up from the very very simple examples such as the one that you find in our Simulink Tester's Users Guide to full block existing Simulink models can be rather problematic. Existing models would have been developed without any concern for how compatible they may be with analysis and test generation tools. Just like with hand developed code, graphical code approaches like Simulink models can be created in ways that make analysis and verification easy but they can also be created in ways the make it very difficult. And unfortunately, many of Simulink's default settings lead to models that are very difficult. For example, the default is to create subsystems that are set to
    non_atomic.jpg
    non_atomic.jpg (198.68 KiB) Viewed 3698 times

    The result of this is that the subsystem is actually inlined into the referencing subsystem, in terms of the RTW generated code and thus also in terms of the T-VEC subsystems produced by the Simulink to T-VEC translator. While it is okay to do this for low level utility type subsystems where there is no desire to test them at a unit level, if all subsystems are inlined throughout an entire model, the result is one very very large single entity. And, because it is the goal of the Simulink Tester/T-VEC VGS technologies to identify, isolate, analyze, and generate test vectors for all disjunctive logical paths throughout a model, the inlining of all subsystems can result in an astronomically large set of logical path permutations, which ultimately uses up too much system memory and CPU resources to process. (This is also a problem for manual testing approaches because there are no identifiable program functions/units to blackbox test except for the whole model as a single entity.) Thus, we recommend using a sensible subsystem decomposition approach where most major subsystems are declared as Atomic Function
    atomic_func.jpg
    atomic_func.jpg (125.94 KiB) Viewed 3698 times
  • The Simulink to T-VEC translator does a very through job of collecting Simulink Signal path routes and in many cases providing auto-determination of signal domains. However, in order to do this the model itself must be in a state that is ready for RTW code generation. In other words, it is a consistently built Simulink model. It must be able to return from running Simulink's Update Diagram (Ctrl-D) process
    update_diagram.jpg
    update_diagram.jpg (211.79 KiB) Viewed 3698 times

    without errors.
  • The model must be developed using discrete time domain elements rather than continuous time domain elements and be set to use a discrete fix-step solver.
    discrete_solver.jpg
    discrete_solver.jpg (169 KiB) Viewed 3697 times
  • Conducting analysis and test vector generation on a model depends on having good information about the model and the data that it processes. We collect as much information about the model itself, but there are some types of information that are not generally included anywhere in the model. This is especially true for signal data type information such as the valid domain of values that a signal will carry. Simulink defaults all signal types to "double", a floating point type (IEEE FLOAT64). Left with these defaults, Simulink Tester/T-VEC VGS assumes a default signal domain of +/- 1.0e12. The reason for this is to try to limit floating point round-off errors (loss of precision) in computations so that the result of an arithmetic computation can be compared in a relational operator block, such as a >= block, with another computation and vectors can be produced that will have inputs that will make that relationship true and other vectors that will make that relationship false while taking potential loss of precision into account. However, the default domain is still rather large and roundoff errors can accumulate. It is much better to declare a signal carrying a "temperature" value to have a meaningful domain, such as −273.15C .. 1000.0 C, if that is the range of temperature values that signal will carry. This allows the T-VEC VGS system to have a better understanding of the model and a better ability to manage precision loss and other related attributes that can affect analysis and test vector generation, such as not creating a test vector with a -1.0e12 value for a "temperature" signal. In order to set up a model for translation with proper signal definitions, it is very beneficial to apply the Signal Range editor
    signal_range_editor.jpg
    signal_range_editor.jpg (305.78 KiB) Viewed 3698 times

    and the signal definition propagation abilities of the Simulink Tester translator. This can have a very significant and positive impact on the ability of VGS to provide the modeler with good analysis and test vector information.
  • Models should be configured for RTW code generation rather than simulation. For example, while we do our best to support having output signals that terminate in simulation elements like scopes, graphs, and display elements and input signals that originate in elements like signal generators and workspace blocks by internally replacing them with input and output ports respectively it is far easier and less prone to confusion and translation problems if the mode is set up like this
    code_gen_flow_control.jpg
    code_gen_flow_control.jpg (139.55 KiB) Viewed 3699 times

    rather than this
    simulation_flow_control.jpg
    simulation_flow_control.jpg (133.1 KiB) Viewed 3698 times
  • Please ask lots of questions. They can be posed in the Users Forum or if they are proprietary in nature, they can be email directly to support@t-vec.com or my personal email address - which you will have once an evaluation or permanent license has been provided.
  • Finally, and we can't emphasize the importance of this enough, Please have a Non-Disclosure Agreement (NDA) set up between your company and us (T-VEC Technologies, Inc.) and clear any company hurdles necessary in order to send us copies of models or portions of models along with your questions. It is very difficult to answer detailed questions about issues/information seen in generated artifacts/possible bugs or confusing actions taken, etc. if we can not see the full set of information - i.e. models and T-VEC artifacts that the questions are being asked relative to.

Happy Model Analyzing and Vector Generating !
busser
Site Admin
 
Posts: 52
Joined: Thu Mar 13, 2008 7:42 pm


Return to General Topics

Who is online

Users browsing this forum: No registered users and 1 guest

cron