Comments on: Model-Based Design Dilemma https://blogs.mathworks.com/simulink/2011/12/27/model-based-design-dilemma/?s_tid=feedtopost Guy Rouleau is an Application Engineer for MathWorks. He writes here about Simulink and other MathWorks tools used in Model-Based Design. Thu, 28 Nov 2013 13:04:33 +0000 hourly 1 https://wordpress.org/?v=6.2.2 By: Juan Jimenez https://blogs.mathworks.com/simulink/2011/12/27/model-based-design-dilemma/#comment-47077 Thu, 28 Nov 2013 13:04:33 +0000 https://blogs.mathworks.com/seth/?p=235#comment-47077 There is something about the option 1 I don’t understand. In this approach, you have two top models but are there in two different simulink model files (.mdl)? If not, how do you avoid the code generation for the simulated Plant subsystem when it is not neccesary?

Thanks,

]]>
By: MikeT https://blogs.mathworks.com/simulink/2011/12/27/model-based-design-dilemma/#comment-1851 Fri, 08 Jun 2012 01:49:20 +0000 https://blogs.mathworks.com/seth/?p=235#comment-1851 Hi Ratish,

Starting in R2010a, structures are allowed as model arguments.
For hierarchical resolution, you can use the Model Workspace to limit access to the global workspace. But, it doesn’t work hierarchically, so a referenced model won’t resolve in the model workspace of the parent model.

Mike

]]>
By: Ratish Punnoose https://blogs.mathworks.com/simulink/2011/12/27/model-based-design-dilemma/#comment-1846 Tue, 29 May 2012 17:20:26 +0000 https://blogs.mathworks.com/seth/?p=235#comment-1846 I would very much like to use model references, but find that they are limited in the following respects (in addition to those already mentioned by previous posters):

* Prevent hierarchical resolution: This is something can be set on blocks in simulink libraries (it is unfortunate that even in libraries this is not the default). With large models and systems, with multiple developers it is useful to have controlled namespaces. Preventing access to the matlab global workspace is needed for this.

* Using structures as model arguments.

]]>
By: Paul https://blogs.mathworks.com/simulink/2011/12/27/model-based-design-dilemma/#comment-1691 Mon, 23 Jan 2012 07:41:32 +0000 https://blogs.mathworks.com/seth/?p=235#comment-1691 Sorry for spamming this thread, but I after converting a model to referencing, I also found that right clicking on a model block doesn’t allow for code generation such as PLC Coder or Embedded Coder. Please consider expanding support for this as well to improve the usefulness of model referencing in the MBD workflow.

]]>
By: Paul Metcalf https://blogs.mathworks.com/simulink/2011/12/27/model-based-design-dilemma/#comment-1685 Mon, 16 Jan 2012 23:37:08 +0000 https://blogs.mathworks.com/seth/?p=235#comment-1685 @Mike
Sorry for the late reply. I should offer a little bit of background. We are only starting out in Model Based Design (MBD) with no existing microprocessor expertise or procedures to work from. On the plus side, we have no legacy requirements holding us back either! Progress on the workflow has been excellent but very much trial and error. I am still working through the nuts and bolts of workflow design, configuration management, PIL testing and so forth. Any comments, recommendations or ideas by me must be considered in this relatively inexperienced context.
I have yet to use Simulink Project, but am very interested about this. I haven’t yet had the time to figure out how to convert an existing project into Simulink Project, or fully understand the benefits Simulink Project may have to the MBD workflow.
As previously mentioned, expanding support between Configuration Reference and IDE Link would seem to be an obvious improvement. Project Generator support for TICCS v.4/5 would also be highly welcomed. Tabbed browsing in Simulink would also be fantastic to switch between different model views quickly, improving window management.
Getting back to the MBD workflow, the best I can gather so far is the following:
•Various configuration files necessary for each task in workflow.
•Model files kept in base workspace alongside configuration files.
•Simulink/Simulink Project used to manage contexts in workflow by reference including data management: test vector, coverage, code etc.

On the topic of MDB workflow, this is the university course or textbook I never had, mainly because I haven’t found a good one yet that even exists!
I will be in Boston in June. If you are interested in further discussing these and other topics over a beer, send me an email.
Keep up the good work.
Paul

]]>
By: Gwenolé LE PACHE https://blogs.mathworks.com/simulink/2011/12/27/model-based-design-dilemma/#comment-1684 Thu, 12 Jan 2012 14:00:28 +0000 https://blogs.mathworks.com/seth/?p=235#comment-1684 @Mike Tocci : When trying to use our s-function inside an accelerated model, Simulink raises an exception. It seems to be a Fortran error related to opening a log file. Whatever the root is, our s-function can create, open and write a log just fine outside of an accelerated model. We didn’t investigate the problem too much as my department is not in charge of writing the fortran code.

We’ve had other problematic behaviors with it : the classic “The results from 2 consecutive runs are different” but also some things which can’t be anything but Matlab bugs (it has been submitted to the support)… Thus, we tend not to trust it any longer.

]]>
By: Mike Tocci https://blogs.mathworks.com/simulink/2011/12/27/model-based-design-dilemma/#comment-1683 Wed, 11 Jan 2012 16:10:04 +0000 https://blogs.mathworks.com/seth/?p=235#comment-1683 Hello, I’m a Simulink developer and these comments are very interesting. I do have a few questions,

@Gwenolé LE PACHE: Can you give any more details on this comment,

“We’ve had difficulties transforming the whole model into a referenced model due to some very surprising behaviors coming from our level-2 S-function (fortran + C).”

What was the surprising behavior?

@Paul: I like your comment on “smart Simulink templates”. Would you expect the context to include more than just the configuration set? Should it include data types, sample times, etc?

]]>
By: Ali https://blogs.mathworks.com/simulink/2011/12/27/model-based-design-dilemma/#comment-1682 Wed, 11 Jan 2012 14:23:07 +0000 https://blogs.mathworks.com/seth/?p=235#comment-1682 I am not good in matlab but I want to say good work
good luck

]]>
By: Guy Rouleau https://blogs.mathworks.com/simulink/2011/12/27/model-based-design-dilemma/#comment-1676 Mon, 09 Jan 2012 16:36:11 +0000 https://blogs.mathworks.com/seth/?p=235#comment-1676 Thanks for all the comments, we really appreciate your feedback.

@Bob:

– I agree that 2 top models make it easy to handle initialization and configuration. In my example, the simulation model uses a continuous solver and the hardware model a discrete solver.
– I agree with your comment on using Variant Subsystems instead of Configurable subsystems. Variant Subsystems offer more functionality and the usability is improved significantly.

@Paul:

– I totally agree with you that it should be possible to complete the entire workflow without having to duplicate model files.
– Linking components of a system using model reference is in general a good way to avoid duplication. With this approach, the same model file can be used within different top-level models for verification, system test, simulation, generate code, etc.

Since this topic seems to generate great interest, I will try to follow up with more posts on related topics.

To everybody: If you have dilemmas in your MBD workflow that you would like to share, please feel free to post a comment or contact me directly!

]]>
By: Paul https://blogs.mathworks.com/simulink/2011/12/27/model-based-design-dilemma/#comment-1674 Sun, 08 Jan 2012 11:37:25 +0000 https://blogs.mathworks.com/seth/?p=235#comment-1674 I find this topic of discussion very interesting, and I hope this theme can continue in future posts. This topic could perhaps be summarized as ‘Improvements to the Model Based Design *Workflow*’? The *Workflow* is heavily dependent on the available tools. For example, I just realized that Configuration Reference is currently incompatible with IDE Link targets. Thusly my workflow must be modified as a result and model files duplicated. Ideally, the tool options should be mature enough to complete the entire workflow without having to duplicate model files. I don’t think we’re there yet. Duplicating model files (or any data for that matter) for the purposes of design verification, system test, code generation, PIL etc is never a good idea. A versioning system for model files only really works when that file doesn’t need to be duplicated in the workflow. Using model reference will no doubt be part of the solution, but probably not the whole solution… Perhaps some smart Simulink templates are needed to provide the necessary contexts to the different parts of the Model Based Design Workflow? Users would link via model reference their plant, control, test structures into the higher level structure?

]]>