Model Transformation: Simulink

From UcgnWiki

Jump to: navigation, search
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 of the time (2007 timeframe), i.e. MATLAB RealtimeWorkshop, dSpace TargetLink, IBM 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 configured to produce the desired source code.  
+
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 (2007), i.e. MATLAB Realtime Workshop, 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.
-
These were some of the requirements for the code-generation
+
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. 
 +
 
 +
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")
Line 11: Line 13:
* Clear software architecture, direct correspondence to the model architecture
* Clear software architecture, direct correspondence to the model architecture
* Separation of reusable library code  
* Separation of reusable library code  
 +
* Simplicity and uniformity of software interfaces (for testing etc.)
 +
* Uniformity of generated code from different development branches (for integration)
= Features =   
= Features =   
The following features are supported by the Simulink UCGN
The following features are supported by the Simulink UCGN
-
* Discrete Simulink models and libraries
+
* Discrete single-rate Simulink models  
-
*  
+
* Simulink user libraries (to enable re-use and collaborative development)
-
 
+
* This set of [[Simulink_Supported_Blocks | Simulink blocks]]
 +
* Periodic, condition-driven Stateflow charts
 +
* Structured data types through bus objects
= Constraints =   
= Constraints =   
-
The following aspects are not supported right now:
+
The following concepts are not supported right now:
-
Not supported by design
+
'''Not supported by design'''
* Continuous systems
* Continuous systems
* S-functions
* S-functions
* Embedded Matlab functions
* Embedded Matlab functions
 +
* Event-driven Stateflow charts
 +
* Algebraic loop resolution
 +
 +
'''Not currently supported, but under development for a future release'''
 +
* Enabled and Triggered Subsystems
 +
* For and While Iterators
 +
* Nested bus-objects at system boundaries
 +
* Model referencing
 +
* Multi-rate models
 +
* Stateflow
 +
** Transition loops
 +
** Parallel AND state decomposition
-
Not currently supported, but under development for a future relase
 
-
* Nested bus-objects
 
-
* Reference models
 
= Modeling guide =
= Modeling guide =

Revision as of 12:19, 23 June 2010

Personal tools