Technology of Multimedia Educational Documents

OpenModelica Compiler targeting the .NET Framework

Motivation why to target pure .NET managed code

We have recognized the potential of the .NET platform as the next generation of efforts to make programs easily portable to any underlying platform. Programs written for the .NET Framework will run even in their binary form wherever ported to the .NET Framework. The .NET platform, originally developed by Microsoft, is an open standard which can be ported to operating systems other than MS Windows. The Mono .NET Project [1] is an open source implementation of the .NET platform for OS Mac, Linux and Windows platforms. The keyaspect of the .NET platform is its ability to support multi language interoperation and development. This property is showing up its benefits more and more in time as more and more languages are ported to .NET.

We are developing simulators (simulation games) which are multi domain applications in their design and implementation. There can be recognized three main domains, or layers in this kind of application: model, interface and control,for each of them it is very useful to have a domain specific language (DSL) and sometimes even several languages for a layer. These languages have to seamlessly interoperate in one application and the application should be easily portable to other operating systems. This is the reason why we have originally chosen .NET as our target platform.

There are other useful features of the .NET Framework (for ver. 3.5) worth a note. One is the possibility to securely run applications embedded in internet browsers (so called XBAP – XAML Browser Application). We are developing simulation games/e-learning simulators and it improves user experience when the simulators are accessible directly in-browser without installation or annoying questions for trusting the vendor of the application. It just looks like browsing the web but gives the full potential of rich internet applications (the condition is of course to have installed the .NET Framework).

Another very useful part of the 3.5 versions of .NET Framework is the WPF – Windows Presentation Foundation. It is extremely powerful framework for graphical user interface development. It also natively supports animations and interactive documents. We where embedding Flash animations in form of ActiveX components in the past which works fine but leads to issues with Flash Player installations and the need to connect quite disparate technologies. Now, with WPF, we are pushing GUIs of our simulation games to the next level. Drawback of using the WPF is that it is not yet implemented in the Mono Project, so it is available for Win users only, but that is only a matter of time.

Moreover, Microsoft has recently answered the demand for rich internet applications (RIA) with technology called Silverlight [2], originally code named WPF/e – WPF everywhere. It is a plug-in which brings core .NET capabilities with subset of the WPF framework into internet browsers. Microsoft itself deploys this plug-in for most popular browsers on Windows and Mac. For Linux there is subproject in Mono Project called Moonlight, which is claiming 100% compatibility with Silverlight when released. The Silverlight platform is very attractive for our development efforts because it enables us to take advantage of the most useful features of the .NET platform, mainly the portability to operating systems other than Windows, in-browser embedding and WPF graphical capabilities. These days, there is version 2.0 Beta 1 of the Silverlight for Win and Mac and work is in progress in the Moonlight Project [1]. It promises seamless user experience for our broad audience soon as it is more and more penetrating the web.

However, there is a constraint for in-browser .NET applications (XBAP or Silverlight). They must be run in a security sandbox which is kind of a delegation of the user security trust on the underlying .NET runtime. From this reason the applications targeted for in-browser execution must be pure .NET managed applications to be verifiable by the .NET runtime. There must not be any calls to unmanaged native code.This is a reasonable constraint when enabling applications to run in-browser without need of user acceptance or explicit trust to the vendor of the applications.

There can be seen another strong reason why to target .NET managed code only. Once there are only pure .NET managed parts of the application, there is no need to cross boundaries between managed/unmanaged environments and there are no issues with compilation of the unmanaged code for different platforms separately (C/C++ code must be compiled differently for different processors/operating systems). All the porting work is then left to the .NET runtime engine implementation.

Tasks to get Modelica models running as pure .NET managed code

We have given the main points of our motivations fortargeting pure .NET managed code in our applications in the above section. Modelica is a very powerful language in its domain – i.e., physical modeling. It serves us as an almost ideal domain specific language for the model layer for our simulation games/e-learning simulators. It would be very useful to have the possibilityof specifying the physical models in Modelica language while the models are translated into pure .NET managed code.

We have recognized the OpenModelica Project [3] as a good chance to achieve the above benefits with a reasonable amount of time and effort. The OM Project is an open source project and we are becoming a part of the development team. The OpenModelica Compiler (OMC) is by default targeted to C code generation. It would be possible to wrap the C code of a model into a .NET wrapper code to be easily used by the .NET environment. We have used this approach for our Simulink models in the past. However, this approach leads to unmanaged native code to be called. From reasons named in the above section the applications cannot be run as in-browser .NET applications (XBAP or Silverlight). More, they are not easily portable because of the need to be compiled separately for each target platform.

In short description of the translation process of Modelica models, the OMC takes the source code of a model and translates it through several transformations into an internal representation of simulation code. In the last phase, C code is generated, compiled and linked with a simulation runtime into the final executable file. The simulation of the model is done by running the executable.

In respect to the above architecture of the OMC code generation and compilation, there are two main tasks to make Modelica models run as pure .NET managed code. The first is to retarget the OMC to .NET managed code instead of C code and the second task is to translate/implement (by hand) the simulation runtime into .NET managed code, too. The simulation runtime can be further divided into a hybrid DAE solver (see below) and simulation runtime code which handles the simulation time loop, events and provides a library of functions supporting the simulation.

OpenModelica compiler (OMC) retargeting

The openness of the OpenModelica Project gives us the opportunity to retarget the OMC to a .NET language, e.g. to C# or to the recently developed new generation language F# or even directly to the core .NET IL (Intermediate Language) code.


Architecture and modules of the OMC are described in detail in OpenModelica System Documentation [4]. The OMC itself is written in a special extension of Modelica language developed in the OM Project called MetaModelica [5]. The OMC’s source code is available from the OM Project portal [3].

The simulation C code generation is mainly implemented in SimCodeGen and Codegen modules of the OMC, which are the main candidates for retargeting the OMC into .NET. The SimCodeGen module generates simulation code from equations of a model to be used by the simulation runtime. That is a C code representation of the equation system in ODE explicit or residual form for an ODE or a DAE solver together with code for zero crossings and “when” statements for handling the discrete parts of models, i.e. event handling. The Codegen module generates C code for functions used in the model which are then called from the simulation code.

We have done the first successful prototype of retargeting the OMC into C# for simple models without event handling (zero crossings) and functions. It seems, based on the first results and due to similarities of the C and the C#, that the retargeting the OMC to C# is realizable in a short term. However, code generation for functions (Codegen module) may take some extra time to be retargeted due to complexity of code generation for functions.

Our further architectural proposal is to make more clear separation of the internal representation of the simulation code from the C code specific details inside the OMC implementation at first. Then, each target language will be represented by a separate module for the OMC with all the target language specifics in it. This kind of architecture will enable an easy way for implementation of other useful target languages for the OMC’s backend, i.e. C# / F# / .NET IL, Java, JavaScript / ActionScript, etc.

Nevertheless, the first prototype of retargeted OMC will be made by modifications of modules SimCodeGen and Codegen to generate C# code instead of C code.

Simulation runtime – pure .NET implementation

The next task is the simulation runtime to be implemented in .NET managed code, too. The core of the simulation runtime for Modelica models is a hybrid ODE or DAE solver – solver for continuous system of Ordinary Differential Equations or of Differential and Algebraic Equations combined with discrete state variables with their transitions and events handling. Detailed descriptions of such hybrid systems and their numeric solutions can be found in [6, ch.17, 18].

In the OM implementation there is used DASSL solver, originally written in FORTRAN and automatically translated to C code. It is a continuous DAE solver with root finding, which is suitable for numeric solutions of hybrid DAE systems when accompanied with a small framework for handling the discrete parts of the systems. We have found there is a more recent version of DASSL solver in SUNDIALS solvers called IDA. The IDA solver is implemented in ANSI C and it is a good starting point for translation into a .NET language, e.g. C#. Its source code and detailed documentation is available from [7]. From overall analysis of the IDA solver architecture it will take some time to translate it because of its robustness. Estimated time is 2 months for a mathematically skilled developer.

Our first prototype tests mentioned in the above section are based on a simple fixed step ODE solver of the 3rd order (Bogacki-Shampine) implemented in C# without any event handling due to simplicity of the test models. For more complex models in our simulation games to be run in real-time manner there should be implemented a fixed step or an efficient variable step solver with zero crossing/root finding as well. In respect to this the implemented ODE 3 solver will be augmented with zero crossing capability at first and then some variable step solver, e.g. CVODE from SUNDIALS [7], will be tested, too.

The rest of the simulation runtime consists of controlling code for solver time loop, event handling and a library of supporting functions which are called from the generated simulation code, i.e. Modelica built-in functions, standard library or matrix manipulation functions. These parts of the simulation runtime are also small enough to be translated to C# in reasonable time.

Simulators Architecture and Technology

The simulators are built on the .NET Framework 3.5, mainly on the WPF presentation subsystem. The WPF framework allows using not only the common user controls (buttons, sliders…) but also animations defined as a XAML code. These animations are in fact only regular .NET objects.

The simulators architecture is a modification of well-known MVC pattern called M-V-VM (Model-View-ViewModel) that is more established in the world of the .NET/WPF. Detailed description of this architecture can be found on the internet [8]. The Model (now meaning the model of the application) holds any data, data access services and logic of the application. In this case a Modelica model compiled for .NET is a part of this layer as well as the state handling code (statechart). The Modelica model comes along with the differential equation solver (simulation runtime), both in managed .NET code. The Model layer is responsible for providing all information and data presented to the user and driving the application. The View is the pure XAML code that defines the look-and-feel of the application including the animations. The ViewModel is an intermediate layer that facades the data from the Model to be easily accessible from the XAML code using Data binding and provides an interface for communication using Commands and Events. The M-V-VM pattern allows the application programmer and the artist that creates simulator interface (animations) to work simultaneously and minimizes the risk of conflicts, because it strictly separates coding from the UI design. Using XAML and managed .NET code gives us the opportunity to create XBAP applications (XAML Browser Application, applications capable of running inside a browser in a security sandbox) or Silverlight 2.0 applications (applications embedded in websites; Silverlight 2.0 works with a subset of the WPF framework).

Here is a short comparison of WPF and Adobe Flash (which we were using in the past)

  • Animations created in WPF are based on the same platform as the whole application and thus directly controllable through the animations API.Similarly the interaction of the user is reflected in the code in the form of program events.
  • Communication with Flash movies is realized through the ActiveX interface by sending FSCommands and FSCommandEvents that are not strongly typed and type safe.
  • Flash clips are played only if the Flash Player ActiveX component is installed on the target computer. The WPF animations are displayed by the .NET Framework 3.5 itself.
  • Flash clips are proprietary binary format while the XAML animations are plain text files.

Multimedia Educational Documents

By Multimedia Educational Documents(M.E.D.) we mean rich content documents that can serve as an electronic textbook with enhanced capabilities of presenting educational text that contains illustrations, animations, audio and video content and especially simulators that are tightly integrated with the enclosing document. As a part of the educational process the M.E.D. provide an ability to test the students using a special test module.

The M.E.D. are based on the WPF technology. They are XBAP/Silverlight applications that are capable of running in web browser. Using the same technology enables tight interaction between the simulators and the documents. Individual components of the simulator may be spread around the document for better readability and/or from pedagogical reasons. The plain text of the document may reflect the results of the simulation and may contain controlsfor controlling the simulation (e.g. resetting the simulator to different initial values to illustrate different situations by placing appropriate icons to the explaining paragraphs).

The WPF framework offers rich possibilities of text formatting and layoutwiththe Flow Document infrastructure. The content of the M.E.D. is defined in XAML[1] in very similar way as in HTML. The WPF engine then wraps the text with a browser component that automatically wraps the document into columns and supports zooming, paging, switching between reading modes and provides searching in the text. For more information about Flow Document and FlowDocumentPageViewer see [9].

Since the M.E.D. is in fact a .NET application it can fully use its abilities to connect to databases or communicate with web services. This allows us to create a subsystem or a component for examination (tests) that would be a part of the M.E.D. itself. The student’s answers can be immediately evaluated or tracked in a database or exported them using one of the e-learning data exchange standards for connecting to Learning Management Systems. Teachers then would be able to browse and verify the results. Very attractive is the possibility of using simulators themselves to test students’ understanding of the explained principles. Because the simulators are just components inserted in compatible enclosing environment, the student can be given a task to fulfill an objective of the simulator. This can be for example a resuscitation of a dying patient in given time. The M.E.D. (or the test component) can then watch the simulator and decide whether the student achieved the goal or not.


The advantage of XBAP in comparison to HTML:

  • Seamless integration with the simulators.
  • Easy embedding of custom components like collapsible paragraphs and hidden text with hints.
  • Much improved user comfort of reading the document – the WPF easily allows zooming of the documents, paging etc.
  • WPF provides rich means of text formatting and typography (multiple columns, improved fonts handling, ClearType technology).
  • Easy rendering of mathematical equations (in HTML they must be converted to images first).
  • Independence of server side technologies. The HTML solution would hardly work without server side code.
  • M.E.D. can be easily distributed as standalone applications.

On the other hand the HTML based content would be:

  • Easier to modify the text because the files are just plain text files. The WPF application is a binary code that needs to be recompiled after any change.
  • Independent on the presence of the .NET runtime on the target machine. The .NET Runtime is a standard part of new Windows versions.
  • Faster download time since the XBAP is a binary application. On the other hand the XBAP applications are cached and they are downloaded only once.

Summary

We have recognized the .NET platform as emerging in the field of rich internet applications and especially when it is used to mix several different domains into one application as it is in the case of the Multimedia Educational Documents with simulation games. Modelica language is one exampleof how a domain specific language can dramatically improve complex software development. The OpenModelica Project gives us the opportunity to use this kind of language oriented approach. There are several tasks to get Modelica models running in .NET managed code. The most complex one is retargeting of the OpenModelica compiler to C#. The next one is translation of the simulation runtime where the IDA solver from SUNDIALS will be the biggest portion. Our time estimate for all the tasks is three months for two developers to get an alpha quality implementation and another three months of testing and debugging to get a production quality implementation of the proposal.