Integration Scenario(s) - Simulink To Code
- The following sequence diagram identifies a number of integration scenarios (each is further detailed later on on this page) when dealing with the creation of source code from a Simulink model.
- This is based on the Brake-By-Wire Use Case, section 5.1.
- See dropbox space for source model.
Models/Aretfacts dealt with:
- Simulink
- HW model
- SW model
- C code
[TODO: Make a graphical representation of tools, roles & their relationships]
- Simulink - application design (requirements).
- TargetLink - application code generation.
- SystemDesk - architecture design, mapping & complete code generation.
- WindRiver - build.
Integration scenarios
Note: As currently presented, the above sequence has no direct integration needs, since (1) artifacts are saved and dealt with between tools as files on the file system and (2) some tools (TargetLink) are embedded into other tools (Simulink) causing very tight (and point-to-point) integration between them.
If we are to generalize the above sequence to tools that ought to interact the OSLC-way, 2 integration scenarios can be identified:
- Code generation of a Simulink model into C-code (The OSLC-way: (1) TargetLink is not a plug-in of Simulink, and (2) an exchange of Simulink model artifacts is necessary from Simulink to TargetLink before the C-code can be generated by TargetLink. Also, (3) the exchange between TargetLink and Simulink cannot be via the filesystem; it has to be through OSLC-resources.)
- Traceability from architecture model to C-code (The OSLC-way: SystemDesk does not map C-files from the file-system to architectural elements. Instead, SystemDesk interacts with Simulink/TargetLink in order to obtain C-artifact resources to trace to.)
Code generation of a Simulink model into C-code
Alternatives:
- TargetLink requests an an OSLC resource from Simulink that represents a whole Simulink model?
- How can such a resource look like?
- Is there a resource currently that we can build on?
- TargetLink is tightly integrated with Simulink, and it would be an artificial to define OSLC- integration between them.
20130613: We ignore this scenario, and try to find another realistic scenario for code-generation (or model transformations). TargetLink is a well-integrated plug-in of Simulink, which makes the scenario unrealistic.
Traceability from architecture model to C-code
Alternatives:
- SystemDesk interacts with TargetLink/Simulink to obtain C-artifacts resources to trace to. (which in turn needs to interact with SCM system)
- See below for further details.
- SystemDesk interacts with the SCM system into which TargetLink/Simulink commited their c-artifacts. (bypassing TargetLink/Simulink)
- A traceability tool manages the traces between SystemDesk and the C-artifacts.
- This means that this new traceability tool is replacing some of hte core functionality of SystemDesk. Maybe not so desirable alternative for the moment?
The following illustrates the first alternative (See notes in the diagram for issues/questions).
Jad Notes for 20130919 meeting:
- Question: What type of resources are returned from an SCM system now that there is no longer an SCM specs?
- Above, I can identify a resource (here called ApplicationCode) that represents a bit of code (c-file, c header, java file, etc.). I guess minimal properties would be its URI and the code content itself. Can we reuse an existing OSLC resource definition for that?
- More importantly, see http://www.dspace.com/en/ltd/home/products/sw/system_architecture_software/systemdesk/interoperability_of_targetlink.cfm . Systemdesk seems to be also tightly integrated with Targetlink (and Simulink). Is this an argument that makes exploring this scenario less realistic? (We need to discuss in general how we work with this case, given that we don’t have hands-on experience with the tools. Maybe just a report is not enough)
The following illustrates the second alternative (See notes in the diagram for issues/questions).
[TODO: Define this scenario]
Questions/issues:
- How to define resources to share complete models for (1) code generating (2) tracing to/from them (while dealing with model versions)?
- Current scenario assumes a single developer performing all activities on a single machine, and ignores the need for file/model versions.
- How to support the need for models to be developed with no common storage space (by different developers)?
- How to support the tracing to specific element versions?
Even if we can solve this scenario using existing OSLC specs, then we should develop such “guidelines” to answer these questions. Could this still be of value?
Category:Working Documents
