Synchronous modeling - how it works

Synchronous interfaces are very simple: they represent standalone functions, with (possibly) a set of input and (possibly) a set of output parameters. They are performing their work and generating their output without depending on any external functionality - that is, they don't call any other interfaces to do their work.

Assuming, for example that ...

• a system is formed from two subsystems (APLCs), A and B
• subsystem A uses a synchronous provided interface (named PI1) which is provided by subsystem B
• the PI1 interface expects one input parameter, described with a specific ASN.1 message (named M1)
• subsystem B is functionally implemented through a MATLAB/Simulink model

The following happen during the VM's code generation stage ...

• the VM code generator knows - by parsing the system description in AADL - that subsystem B is functionally implemented through a Simulink model (Source_Language => "Simulink";).
• the VM code generator also knows that aadl2glueC has been called prior to its own code generation stages. During its invocation, aadl2glueC has generated the required ``bridge'' functions, which allow the VM to communicate with subsystem B's PI1 interface.

The VM code generator is therefore able to create code that performs the appropriate calls (at runtime) to call subsystem B's PI1 provided interface. In fact, based on the work done from aadl2glueC, the VM only has to perform a simple function call, to an appropriately named bridge function for the PI. This call is easy to introduce in the VM code, since the invocation of any PI (and thus, our example PI1 from subsystem A) is ``routed'' via a VM callback function.

The VM therefore, in the context of this callback, can ...

• get hold of the ASN.1 encoded data that describe the input parameter (as it is passed from subsystem A, that is, an encoded stream of ASN.1 type M1).
• the encoded data are accessible through a (pointer, size) pair, or more precisely, a pair of (void *, size_t). This pair provides access to the message data and the data size, respectively.
• The VM then calls the appropriate ``bridge'' function that was created by aadl2glueC for subsystem B's PI1 provided interface, passing in this pair...

This ``bridge'' function then (prepared from aadl2glueC) performs three tasks:

• it decodes the input parameter (of ASN.1 type M1) and places the decoded data inside the appropriate ``bridge'' Simulink variables.
• it invokes the PI1 entry function (the function generated by the Real Time Workshop component of MATLAB/Simulink) ; the functional code of PI1 then reads the M1 data from the bridge variables and operates based on them.
• if PI1 has any output parameters, their contents are read from the respective Real Time Workshop generated variables, and are encoded back into the appropriate output ASN.1 streams.

Notice that during this process, there is no modeling-tool-specific ``agenda''. The exact same steps are taken for all synchronous modeling tools (SCADE, MATLAB/Simulink, etc): the data modeling layer generates the appropriate ``bridge'' functions, and the VM only needs to invoke them, nothing else.

The names of these ``bridge'' functions follow simple naming conventions, and can be broken down in two layers