Model Transformation: Simulink
From UcgnWiki
(Created page with 'Home: Main Page ---- = Overview = = Features = = Constraints = = Modeling guide =') |
(→Constraints) |
||
| Line 2: | Line 2: | ||
---- | ---- | ||
= Overview = | = Overview = | ||
| + | |||
| + | 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. | ||
| + | |||
| + | These were some of the design requirements for the UCGN output: | ||
| + | * Clearly readable source-code | ||
| + | * 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) | ||
| + | * Clear software architecture, direct correspondence to the model architecture | ||
| + | * 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 | ||
| + | * 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 (including flowgraph loops) | ||
| + | * Structured data types through bus objects | ||
| + | * Simulink native enumerated types | ||
= Constraints = | = Constraints = | ||
| + | |||
| + | '''Not supported by design''' | ||
| + | * Continuous systems | ||
| + | * S-functions | ||
| + | * Fixed-point design | ||
| + | * Embedded Matlab functions | ||
| + | * Event-driven Stateflow charts | ||
| + | * Algebraic loop resolution | ||
| + | * Use of "Late-binding" (i.e. variable size or type) on user library interfaces | ||
| + | |||
| + | '''Not currently supported, but under development for a future release''' | ||
| + | * Enabled and Triggered Subsystems | ||
| + | * For and While Iterators | ||
| + | * Nested bus-objects at system boundaries | ||
| + | * Arrays of bus-objects | ||
| + | * Model referencing | ||
| + | * Multi-rate models | ||
| + | * Stateflow | ||
| + | ** Parallel AND state decomposition | ||
| + | ** Inner transitions | ||
| + | ** History Junction | ||
| + | ** Truth Tables | ||
= Modeling guide = | = Modeling guide = | ||
| + | |||
| + | TBD | ||
| + | |||
| + | <references /> | ||
