{"id":12110,"date":"2022-04-22T13:14:52","date_gmt":"2022-04-22T17:14:52","guid":{"rendered":"https:\/\/blogs.mathworks.com\/simulink\/?p=12110"},"modified":"2022-06-14T09:29:58","modified_gmt":"2022-06-14T13:29:58","slug":"unifying-matlab-and-simulink-a-user-story-part-1","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/simulink\/2022\/04\/22\/unifying-matlab-and-simulink-a-user-story-part-1\/","title":{"rendered":"Unifying MATLAB and Simulink: A User Story Part 1"},"content":{"rendered":"
I recently had an interesting discussion with a group of users about modeling, simulation, and how the management of simulation data evolved at their company. What they came up with is a framework where the fundamental unit (which they call a \"Part\"), is systematically made of a Simulink <\/span>masked subsystem<\/span><\/a> and a <\/span>MATLAB class<\/span><\/a>. <\/span><\/div>
Why did they come up with that? To answer this question, I will quote a user from this group: \"<\/span>What really drove MATLAB classes for us was the idea of reuse across system scales. From unit test development up to integration model<\/span>.\"<\/span><\/div>
I personally find this framework very convenient to work with, so I thought this would be an interesting story to share on this blog. With their permission, I am sharing the approach I learned from them with all of you. <\/span><\/div>
It's too complex to share in a single post, so I came up with a series of blog posts:<\/span><\/div>
  1. Defining model data: From hardcoded values to MATLAB objects (this post)<\/span><\/li>
  2. A superclass and template subsystem as foundation of the framework<\/span><\/li>
  3. Controlling variants using MATLAB objects<\/span><\/li>
  4. Managing logging using MATLAB objects <\/span><\/li><\/ol>
    Here are links to other posts in this series: <\/span><\/div>