The code generation techniques

Lublinerman et al. [39, 38] introduces a code generation technique using the modeling lan- guage Synchronous Block Diagram (SBD). In SBD, the relationship between input and out- put is precisely defined at every synchronous round, and its semantic extension is currently being used in the Simulink/Stateflow model. Lublinerman’s work considers the following implementation-specific criteria when generating code from a SBD: (1) internal structures of the generated code need to be sometimes hidden from the outside (e.g., for intellectual- property concerns) and (2) a part of the generated code needs be reused in different contexts. To take into account these criteria, it introduces two quantifiable metrics, (1) modularity and (2) reusability, that can be used to measure how well the generated code from a block diagram can be used along with other code generated from different block diagrams in or- der to form a particular context. Then, several code generation algorithms are introduced, each of which maximize different metrics so that the generated code meets the respective implementation criteria while preserving the SBD semantics.

Lublinerman’s work is similar to our code generation on how to generate a code that can be reused in different contexts (c.f., different platforms in our work), with several differ- ences. One major difference is on the level of abstraction to model implementations and how Lublinerman’s work and ours model them. Lublinerman’s work models an implemen- tation based on the single modeling language (SBD) to abstract the relationship among different components characterized by a set of input and output dependencies. Our work

models more detailed platform-dependent interactions among thread and sensor/actuator components that comprises an implementation using AADL. In addition, our platform- independent modeling intends to capture behavioral aspects that should be implemented independently from such platform-dependent aspects. Therefore, our modeling strategy consequently makes our code generation generate source code that covers more details of the final implementation compared to Lublinerman’s work.

Another difference comes from the metrics that each work wants to characterize in judging the composition. In order to consider the trade-off between reusability and modularity, Lublinerman’s work manipulates the number of false dependencies in a way that each aspect can be maximized. However, Lublinerman’s work does not consider timing aspects as to how the composition of different codes generated from different blocks impact timing requirement conformance; these timing aspects are the major concern in our work.

Henzinger et al. [28, 27] introduces a modeling language called Giotto, that can describe timed behavior of hard real-time applications. Logical Execution Time (LET) is the main abstraction of the Giotto timing semantics in order to implement deterministic timed be- havior of the control application; that is, given a sequence of inputs, the output is produced at a pre-determined timing. When generating code from a Giotto model, Henzinger’s work considers the following implementation-specific criteria: (1) the generated code should be ported on a range of platforms, and (2) the execution of the generated code should preserve the deterministic timing semantics of the Giotto model. However, achieving both code portability and deterministic timing semantics is challenging, since each platform may have different platform-dependent timing semantics (e.g.,different real-time scheduling policies), which will lead to different timed behavior of the generated code on its respective platforms. Henzinger et al. proposed a way to mediate the Giotto timing semantics and the platform- dependent timing semantics by separating the code generation into two processes. In the platform-independent process, E-code is generated in which the timing information is en- coded independently of a particular platform’s timing semantics; the generated E-code is

expected to operate on a virtual machine called the E-machine. In the platform-dependent process, the time-safety property is checked to see if platform-dependent timing semantics can operate the E-code preserving the Giotto semantics. If such a time-safety check is passed, the E-code can be run on a target platform preserving the Giotto timing semantics.

Henzinger’s work is similar to ours in a sense that it mainly focuses on separating the two timing concerns in the code generation process - the platform-independent and the platform- dependent timing aspects. The verification flow to check correctness of the composition is also similar; both works generate the platform-independent code independently from a particular platform; upon integration, Henzinger’s work performs time-safety checking that verifies whether a platform has enough performance to execute E-code according to the Giotto semantics. Similarly, our approach also constructs the platform-specific model (PSM) for the purpose of verifying whether the composition of the two types of code meets the timing requirement.

However, the scope of the code that our work generates is different from theirs. Hen- zinger’s work generates E-code (c.f., the platform-independent code in our work) that is compatible to platforms that run an E-machine, but our work does not require a platform to run a middleware to execute the platform-independent code. This is because, in ad- dition to generating the platform-independent code, our work also aims at generating a platform-dependent code that can support the execution of the platform-independent code by constructing a more refined platform model to explicitly capture the platform-dependent timing aspects. As a result, our platform-independent code can be executed on a platform that runs the platform-dependent code that are characterized in the platform-dependent modeling stage (i.e., no need for our platforms to run a particular middleware to execute the platform-independent code).

Such differences can also be highlighted when comparing our work to the AADL code genera- tion using Ocarina [37] which requires platforms to run PolyORB middleware to execute the generated code. The assumption that any platform will run the same middleware makes the

code generation algorithm more simple, but we believe that designing a platform-dependent code generation algorithm that allows us to explicitly describe only the necessary parts of a platform will result in producing more efficient code, especially in the embedded systems domain.

Functional Mockup Interface (FMI) is a tool independent standard for the exchange of dynamic models and for co-simulation [17]. This standard intends to enable the composi- tion of model components that are designed using distinct modeling tools. The standard is currently evolving and being extended through collaboration between simulation tool vendors and research institutes. One of the extension efforts has been made by Broman et al. [20, 21]. Broman proposed a way to extend the standard to enable deterministic execu- tion for a much broader class of models [20], and defined a suite of requirements for hybrid co-simulation standards [21]. In our work, we utilized multiple modeling languages, such as UPPAAL, Stateflow, and AADL. Thus, if FMI standard supports the model exchange and co-simulation environment for the modeling languages that we have used in this work, we believe that some of the manual process (e.g., the model translation from Stateflow to UPPAAL) would be more efficiently performed.

There are also other works that studied separating concerns between specification and hardware-dependent details in generating source code. In particular, Schirner et al. [46] proposed automatic generation of hardware dependent software for MPSoCs platforms from abstract system specifications. The approach of Schirner’s work is similar to ours in the sense that one can write specifications of embedded systems hiding the details of imple- mentation, and later mapping to an actual platform to generate code separately. However, Schirner’s work uses a modeling language, Transaction Level Models (TLM), as an input to the process as opposed to AADL which we use. In addition, they do not consider dealing with heterogeneous aspects of programming interfaces exposed by different platforms, which are characterized by our parametrized code snippet repositories.