Low-level bridges - internal interface between VM and data mappers

The high-level ``bridges'' use the following low-level functions to do their work:

In the incoming direction, i.e. when the code needs the ``glue'' layer to decode the message and place its data inside the appropriate modeling-tool generated variables, the bridge function doing the work is:
```
int 
Convert_From_uper_To_MsgType_In_SubPrgName_SbPrgImpl_ParamName(
    void *pBuffer,
    size_t iBufferSize);
```
...where
- SubPrgName is the name of the subprogram (in the previous example. mysimulink)
- SbPrgImpl is the name of the subprogram implementation (Simulink)
- ParamName is the name of the parameter (my_in)
These three entities unmistakeably identify the parameter in question. Their names are taken verbatimly from the AADL file, and if they contain a character not supported by C, '_' is used instead in its place.
For our example above, the following function is generated:
```
int 
Convert_From_uper_To_T_FOR_SIMULINK_IN_In_mysimulink_Simulink_my_in(
    void *pBuffer, size_t iBufferSize);
```
Notice that this kind of bridge functions are called before the call to the actual PI implementation function - since the actual implementation expects its inputs to be set prior to its execution.
The "real work" functionality of the PI is accessible through a function named as...
```
void Execute_SubPrgName_SbPrgImpl();
```
This bridge function knows exactly how to call the appropriate functional code generated by each modeling tool. In the case of SCADE for example, it will issue a call to the AADL2SCADE_PERFORM macro generated by the ESTEREL code generator.
In our example, this function is called...
```
void Execute_mysimulink_Simulink();
```
In the outgoing direction, i.e. after the functional code completes, when the ``glue'' layer needs to read the data from the appropriate modeling-tool generated variables and encode their content as output messages, the corresponding bridge function is called...
```
int 
Convert_From_MsgType_To_uper_In_SubPrgName_SbPrgImpl_ParamName(
    void *pBuffer,
    size_t iMaxBufferSize);
```
The buffer passed-in must be able to hold the maximum configuration of the message. The VM code generator knows this maximum size, since it has parsed the AADL Dataview, which is automatically generated from asn2aadlPlus - and thus, has access to the maximum message sizes. Upon return of this function, the pBuffer is filled with the output message data, and the actual message size (always less than iMaxBufferSize) is returned.
In our example, this function is called...
```
int 
Convert_From_T_FOR_SIMULINK_OUT_To_uper_In_mysimulink_Simulink_my_out(
    void *pBuffer, size_t iMaxBufferSize);
```

These low-level support functions are called by the high-level ones, the ones that VM calls. From the VM's point of view, the process is completely automated: the VM ends up accessing functionality written in any synchronous modeling tool, regardless of parameters, by simply calling two functions... Access to the exchanged message details is not only unnecessary, it would also be hazardous, since it would ``tie'' the VM to message-specific details. Via the Data Modeling Toolchain, the VM can route any message to any interface, handling the message data as simple, opaque, sequences of bytes.