In 90% of cases, Model-Based Design software there is an integrating with an existing software base. The primary question “who integrates into whom?” With answers of either the MBD integrates into the Existing or the Existing integrates into the MBD(1).
The ability to integrate is dependent on the defined interfaces. There are three interfaces of interest
- Schedule: The calling method (e.g. timing) must be defined.
- Function: The function signature must be well defined.
- Data: Encapsulation of data simplifies the integration
Assuming that the interfaces are well defined then the MBD, or the existing software can easily incorporate the software entities.
A into B or B into A?
The question of what integrates into what can be easy or difficult. When one environment, say the existing code, consists of utility functions then those functions should be integrated into MBD environment. If both environments consist of a large body of functions and modules, then the question becomes more difficult.
The first option is to have both code bodies sit “side by side.” In this case, the interfaces are defined at the top level of the code bases, and the communicate only through this interface. This is a ‘clean’ approach, but it can create a bottleneck for the data.
The second option is to decompose one of the existing code bases and integrate it into the other environment. This option takes more upfront work, but it is more flexible and robust in the long run.
Integration methods within Simulink
Simulink provides multiple methods for integrating C and C++ code into MBD models. The methods for integrating the code assumes that the schedule, function, and data interfaces are well defined as described above.
Final thoughts
This post, by its’ nature, is shorter than most. Information on what “well defined” and “encapsulated data” is covered in other blog posts.
Footnotes
(1)There is, of course, the third case of the “Klein bottle integration”
