Re: [taste-users] TASTE Simulink Bus structure

Hi Michael.

As in all things technical, there is a balancing act that relates to your question.

On the one hand, the various modeling languages supported by TASTE have their own ways of expressing things - and in some cases, you can express the same thing (semantically) using more than one ways.

On the other hand, the end result that TASTE pursues is to be able to map the semantic content of the data (at runtime) using ASN.1 encodings, so that everyone can speak to everyone else, using optimal ASN.1 message encodings ( in both the required message space and the required CPU processing). To that end, the TASTE A mappers (tool-src/DMT/asn2dataModel/ ) contain inside them specific ways to map ASN.1 constructs to whatever target modelling languages TASTE supports.

To see this in action, have a look at simulink_A_mapper.py (under tool-src/DMT/asn2dataModel/ - Python is very easy to grasp, even if you have never seen it before). You will see there (start from the function "CreateDeclarationForType" ) how we map ASN.1 types to Simulink constructs. The important thing to understand here, is that this mapping you see in simulink_A_mapper, is also "reflected" in the simulink_B_mapper (under tool-src/DMT/aadl2glueC/) - where the data structures generated by RTW are mapped (at runtime) to our ASN.1 data structures. Whatever mapping is chosen in the A mapper, it must be reflected in the B mapper - that is, in the "glue" code that wraps around the code generated by the modelling tool's generator (in this case, RTW).

In plain words, our type mappings are "restricted" in only one sense: when the type definitions are given in the modelling tool's code generator, they must trigger the generation of predictable code patterns - so that the "glue" code itself can be guaranteed to always be able to work with them. That's the reason behind the choice of the Simulink Buses - which, if memory serves, was not the first choice we did. It was years ago, but I remember that we started with different mappings - only to find that when used in nested form (sequences of sequences, etc), the RTW code generator deviated and used different mappings that broke the glue.

This same reasoning applies to all mappers, not just the Simulink one. The end results you see in the A mappers' chosen mappings today, has evolved under this single directive: to find type mapping strategies that trigger deterministic code generation from the modelling tools' code generation engines. Only then could we actually do the automatic integration we do in TASTE.

Hope this helps,
Thanassis.

On 02/09/2013 10:46 πμ, Michael.Dumke@xxxxxx wrote:

Hi Joaquim, thanks for the fast answer. I have not thought about just using the bus selector, I think this solution will suffice. My problem is just for "aesthetic" reasons, and I was wondering if I could change the ASN.1 in such a way that only the vectors are to be seen in Simulink. If I use the bus selector to just get out the vectors, both are (of course) named "<element_data>". Thank you very much, Michael -----Original Message----- From: joaquim.rosa@xxxxxxx [mailto:joaquim.rosa@xxxxxxx] Sent: Monday, September 02, 2013 9:10 AM To: Dumke, Michael Cc: taste-users@xxxxxxxxxxxxxxxxxxx Subject: Re: [taste-users] TASTE Simulink Bus structure Dear Michael, Imagine that you have a ASN.1 definition similar to the following: MyType ::= REAL (-10.0..10.0) MyArrayA ::= SEQUENCE OF (SIZE(1..3)) OF MyType MyArrayB ::= SEQUENCE OF (SIZE(1..3)) OF MyType MyInput ::= SEQUENCE{ MyArrayA, MyArrayB } This will generate a input Bus in Simulink with 2 signals myarraya and myarrayb, each of these signals has two fields: element_data and length. Then you can use the Selector Block to extract the array elements giving the indexes[1 2 3] from Index Vector. I don't know if this addresses your question, but to start it is very important to be sure that your ASN.1 definition is really representing the data types in the way you want. Best regards, Joaquim Rosa ESA - European Space Agency Joaquim Rosa On-Board Computer and Data Handling Section Data Systems Division (TEC-ED) ESTEC Keplerlaan 1, PO Box 299 NL-2200 AG Noordwijk, The Netherlands joaquim.rosa@xxxxxxx <mailto:joaquim.rosa@xxxxxxx> | www.esa.int <http://www.esa.int/> T +31 71 565 3181 From: <Michael.Dumke@xxxxxx> To: <taste-users@xxxxxxxxxxxxxxxxxxx> Date: 02/09/2013 08:39 Subject: [taste-users] TASTE Simulink Bus structure ________________________________ Good Morning, I have a question concerning the interface between TASTE and a Simulink function. I want to generate a Simulink skeleton that consists of vectors within a bus. Let's say Input A is a Bus with two vectors a and b with each 3 elements. At the moment if I build up such a system a and b will be generated as again busses that have each a bus element ("element_data") of size 3. Is it somehow possible to generate a "single bus structure" and not this "double bus structure" where a and b are just vectors? I tried using "sequence of" and "set of" but both result in the same Simulink skeleton. If somebody has an idea I would be very grateful, Michael Dumke -------------------------- Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR) German Aerospace Center Institute of Space Systems | Robert-Hooke-Str. 7 | 28359 Bremen | Germany Michael Dumke Telephone +49 421 24420-1262 | Telefax +49 421 24420-1120 | michael.dumke@xxxxxx www.DLR.de This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender. Please consider the environment before printing this email.