Model Transformation: Simulink

From UcgnWiki

Jump to: navigation, search
(Constraints)
 
Line 3: Line 3:
= Overview =
= Overview =
-
The Simulink model transformation layer and the UCGN core code-generator were designed because of the dissatisfaction with some of the available COTS code-generators at the time (2005/2006), i.e. MATLAB Realtime Workshop<ref>Especially The Mathworks have done their homework since then with respect to Safety-critical applications and DO-178B</ref>, dSpace TargetLink, IBM Rational Rhapsody etc. It was perceived that all of the COTS generators resulted in source code that would pose some significant problems when attempting certification of the generated source code to the aerospace software standard [http://en.wikipedia.org/wiki/DO-178B DO-178B]. All existing COTS code generators lacked the ability to be fully configured to produce the desired source code.
+
The Simulink model transformation layer and the UCGN core code-generator were initially conceived several years back because of the dissatisfaction with some of the available COTS code-generators at the time (2005/2006), i.e. MATLAB Realtime Workshop<ref>Especially The Mathworks have done their homework since then with respect to Safety-critical applications and DO-178B</ref>, dSpace TargetLink, IBM Rational Rhapsody etc. It was perceived that all of the COTS generators resulted in source code that would pose some significant problems when attempting certification of the generated source code to the aerospace software standard [http://en.wikipedia.org/wiki/DO-178B DO-178B]. All existing COTS code generators lacked the ability to be fully configured to produce the desired source code.
Also, the project at the time required that different model-based development approaches would be used together (i.e. UML modeling and control design using Simulink) and that the resulting auto-code be integrated. This was non-trivial because of the very different "flavors" of source code resulting from the different modeling tools.   
Also, the project at the time required that different model-based development approaches would be used together (i.e. UML modeling and control design using Simulink) and that the resulting auto-code be integrated. This was non-trivial because of the very different "flavors" of source code resulting from the different modeling tools.   
Line 9: Line 9:
These were some of the design requirements for the UCGN output:
These were some of the design requirements for the UCGN output:
* Clearly readable source-code
* Clearly readable source-code
-
* Separation of functionality and parameters ("tunable parameters")
+
* Separation of functionality and parameters ("tunable parameters")<ref>Let's say we want to use the workspace parameters AlphaMax = 12.0 as a tunable parameter. If a Gain block then contains "1.25 * AlphaMax" the resulting code must under no circumstances have the hard-coded value 15 in that place.</ref>
* Robust data storage (compile-time static structures in favor of pointer run-time constructs)  
* Robust data storage (compile-time static structures in favor of pointer run-time constructs)  
* Clear software architecture, direct correspondence to the model architecture
* Clear software architecture, direct correspondence to the model architecture
Line 22: Line 22:
* Simulink user libraries (to enable re-use and collaborative development)
* Simulink user libraries (to enable re-use and collaborative development)
* This set of [[Simulink_Supported_Blocks | Simulink blocks]]
* This set of [[Simulink_Supported_Blocks | Simulink blocks]]
-
* Periodic, condition-driven Stateflow charts
+
* Periodic, condition-driven Stateflow charts (including flowgraph loops)
-
* Structured data types through bus objects  
+
* Structured data types through bus objects
 +
* Simulink native enumerated types
= Constraints =   
= Constraints =   
Line 30: Line 31:
* Continuous systems
* Continuous systems
* S-functions
* S-functions
 +
* Fixed-point design
* Embedded Matlab functions
* Embedded Matlab functions
* Event-driven Stateflow charts
* Event-driven Stateflow charts
Line 39: Line 41:
* For and While Iterators  
* For and While Iterators  
* Nested bus-objects at system boundaries
* Nested bus-objects at system boundaries
 +
* Arrays of bus-objects
* Model referencing
* Model referencing
* Multi-rate models
* Multi-rate models
* Stateflow
* Stateflow
-
** Transition loops
 
** Parallel AND state decomposition
** Parallel AND state decomposition
** Inner transitions
** Inner transitions

Latest revision as of 19:37, 2 September 2011

Personal tools