Educators are tasked to develop innovative and creative educational materials that supplement and further enhance the traditional lecture format. This requires developing and disseminating materials that facilitate active learning, enhance problem-solving skills, and encourage discussion and interaction in small group environments. Computer simulations are one way to fulfill these requirements.

A simulation application, commonly called a simulator, comprises a mathematical model of the simulated object (a physiological system in this case) and a graphical user interface (GUI). The user interface visually represents the simulated object and its state (as computed by the model) and allows students to control the model via various inputs and controls.

Simulators are used globally to motivate students, enhance their understanding of complex topics, and foster critical thinking and problem-solving skills [1,2]. We have been creating and using simulators designed in various technologies [3] in our classrooms for many years with considerable success [4].

Complex simulators can be confusing for students and thus ineffective without additional explanation. New and effective teaching tools include interactive textbooks that integrate texts with simulators (interactive visualizations driven by models). Students can experiment with the systems and concepts under study using a simulator and thus verify and deepen their understanding. The function of the simulator is explained in the accompanying text and supplemented with suitable scenarios so that students gain maximal utility from the experience. As an example, the interactive textbooks on cardiovascular physiology by Burkhoff and Dickstein are among the first works in this field available on the internet [5] or as an iPad app [6].

Our goal was to develop a technology for the creation of similar teaching materials, but in contrast to Burkhoff [5], our innovations are designed to be platform independent and able to work offline. This technology is free and thus available for anyone to create new interactive teaching materials.

Creating books composed of texts and pictures or animations is technically not difficult. There are several suitable software tools available for this purpose. The challenging task is to include model-driven simulators that allow students to change variables, make predictions, and discover how the system works.

Production of teaching simulators is a demanding and multifaceted task requiring an interdisciplinary team of experts from multiple areas including education, graphics, modeling, and software development.

To begin the process, the educator defines the teaching objectives of the simulator, determines its main design to meet the objectives, and proposes scenarios that the simulator should be able to demonstrate. The educator also defines the demands on the model by determining the (physiological) processes that should be modeled, the parameters that are controlled by the user, and the variables that are displayed in the GUI. The educator also conceptually designs the GUI so that the system and its state is presented in a didactic way.

The modeler begins by finding a suitable model in the literature and often combines several models. If a convenient model cannot be found, the modeler derives the model from elementary (eg, physical and physiological) principles. At this point, the modeler implements the model in a programming or modeling language so that its calculation may be run on a computer. If the model is newly developed, it should be verified by comparing its results with credible reference data [7].

The artist designs the visual appearance of the GUI according to the educator’s assignment and decides the complete arrangement, including the colors and fonts. The artist also prepares all the drawings including interactive animations that may be linked to respective model variables and thus controlled by the model.

The software developer composes the GUI using the graphical components, stitches it with the model, and produces the final simulator. User controllable elements are bound with the inputs of the model. Output variables from the model are connected with the interactive graphical elements, plots, and other indicators of the GUI. The final application is then deployed on the target platform that can be a Web page or a classical native binary, and eventually, it is embedded into a broader teaching unit.

Finally, the educator tests the simulator in an educational setting and, based on the feedback from students, may decide to iterate a new version of the simulator (Figure 1). The specific roles of the developers, development phases, and several patterns that are useful through the process are described in CoSMos methodology in more detail [8].

We describe our software engineering efforts toward the development of a lightweight, easy-to-use, platform-independent, open, and standardized framework for creating interactive equation-based simulations for medical education. In this section, we discuss several existing tools related to simulator authoring to explain the reasons why we decided to develop a new toolchain and support our technological decisions.

There are excellent Web technologies available based on JavaScript, including many useful frameworks and libraries that almost equalize the capabilities of browser and native applications. There are also great modeling tools available. The problem is that the models are deployed in native programming languages (C or C++) so that they cannot be run in a browser. Our goal was to fill this gap and allow the use of the dedicated modeling tools and enable running the resulting models in the browser without a server-side back-end. On the basis of our previous experience, we have formulated the following requirements on the tool for simulator production:

There are many tools available, which are useful in the process of the simulator production, and they meet several of the requirements. However, we were unable to find a single tool or toolchain meeting all our requirements. To address this limitation, we developed a toolchain that meets all our specific requirements.

Modelica [59-61] is an equation-based, object-oriented, open standard language for the simulation of complex physical systems.

In the equation-based (acausal) approach, the model is composed of equations that state the relationship between the variables (eg, x² + y² = 1) as opposed to assignments where 1 output variable (on the left-hand side) is assigned a value of an evaluated expression (right-hand side; eg, y:= sqrt (1 – x²)) [62]. The causality of the evaluation (order in which equations are evaluated and which variables are calculated from which equation) does not have to be known in the modeling phase. It is derived automatically by the solution tool later [62]. We prefer this approach over block-oriented modeling because, in equation-oriented modeling, the modeler saves the labor of the causality derivation. Moreover, because the model components are implemented without any assumption about causality, they may be easily extended or later reused in various models, where the causality differs [62]. This is very useful in creating reusable component libraries. We base our simulators on models that are usually published as equation systems, and thus, their implementation in the equation-based approach is straightforward.

Below, we illustrate the difference between both approaches with example of harmonic oscillator model described in the equation m∙x'' = –k∙x – c∙x', where x is position, m represents mass, k represents spring constant, and c represents damping constant. Implementation of this model using the block-oriented approach in Modelica (as Modelica supports the block-oriented modeling as well) is illustrated in Figure 2. The code of the same model implemented using the equation-based approach in Modelica is listed in Figure 3. The equation-based (acausal) and block-oriented approaches are compared in several reports [27,62,63].

Owing to its object-oriented nature, Modelica scales very well for large complex models [62]. Basic model components (classes) are defined by equations. Components have connectors. More complex components are composed of other components that are connected using their connectors in a visual way. These connections are rendered into additional equations binding the variables of the connected component. Inheritance is also supported and enables significant code reuse. Numerous Modelica libraries of predefined components from many different domains exist. A Modelica library for physiology called Physiolibrary was developed in our laboratory [64,65]. The harmonic oscillator model implemented using Modelica Standard Library is illustrated in Figure 4. The model appearance intuitively explains the modeled system.

Modelica is supported by many different modeling tools, primarily because of the fact that it is an open standard. This is important because it allows the use of multiple tools that broaden and expand the modeling capabilities. We use either OpenModelica [66], which is free, or Dassault Systèmes Dymola [67], which is a more advanced, but a proprietary modeling tool.

Modelica is an open-standard language supported by open-source tools and, as such, is ideal for model sharing [68].

Functional Mock-up Interface (FMI) [69] is a standard for exchanging and cosimulation of dynamic models between different independent tools and applications. Both Dymola and OpenModelica allow for the model to be exported as a Functional Mock-up Unit (FMU). When exported in the mode FMI for Co-Simulation, the unit contains a simulation runtime, which takes care of the model calculation and execution. The data exchange with the outside world is restricted to discrete communication points, and between them, the unit is solved independently by the included solver [70].

The FMU can be exported with source code necessary to compile binaries, which implement the Co-Simulation standard. This ability is very advantageous for our purposes as we can compile the source code into a Web language and have full access to the FMI for Co-Simulation features in the browser, which allows us to interact with the model easily.

The FMI standard ensures compatibility with future versions of both OpenModelica and Dymola. Furthermore, the Bodylight.js system can be easily adapted to support other simulation tools implementing the FMI export option.

JavaScript is a multiplatform, object-oriented, interpreted programming language [71]. It was originally developed by Brendan Eich in 1995. JavaScript is the most notable implementation of the ECMAScript standard. It is supported by all recent important Web browsers [72]. It is widely used today to enable interaction and dynamic behavior on websites.

We use the GrapesJS open-source Web Builder framework [73] as our HyperText Markup Language (HTML) layout engine. GrapesJS allows us to use the drag-and-drop approach for designing how the simulators appear. There is a set of built-in blocks available to build the app, and it allows for easy customization and production of additional blocks as well. Available configuration panels enable the programmer to edit properties and the behavior of the components on the canvas. The modular design of GrapesJS allows us to hook into its user interface and extend it as a base of the main user experience.

EaselJS [74] is a component of the CreateJS toolkit. It allows for easy manipulation of HTML5 Canvas elements and can be used to create games, art, and other graphical experiences. More importantly, for our interests, Adobe Animate natively supports the export of animations to EaselJS. We can either use Adobe Animate to design the animations or EaselJS directly to create original animations.

Finally, Plotly.js [75] is a high-level, declarative charting library implemented in JavaScript. It can be used to display many types of charts and graphs.

WebAssembly [76] defines a binary instruction format to be executed inside a stack-based virtual machine. Its primary use is to be implemented inside Web browsers, aiming to provide code execution at near-native speeds. The binary format is designed to be efficient with respect to size and load time, reducing the time necessary to transmit and load the code.

WebAssembly is a target of compilation for high-level programming languages such as C or C++, enabling the compilation of existing and new code written in C/C++ to the browser platform. The compiler that facilitates this is the open-source project, Emscripten [77,78], which we use to compile source code inside the FMU. The compiled code can be considered obfuscated to the level similar to those with other binary instruction format representations. The algorithms can be disassembled into a pseudocode and with great effort and investment of time can even be reverse engineered [79]. For most practical purposes, the models can be considered obfuscated when compiled to WebAssembly.

The new Bodylight.js toolchain uses the work of several third-party open-source tools and compilers and other newly written tools. The Web page [80] of this project includes documentation and tutorials. In this section, we describe the complete workflow in more detail and define all the processes involved and the tools used. We focus particular attention on the newly developed Bodylight.js Composer, which enables one to create the final simulator by composing the GUI using animations, plots, and control elements in a drag-and-drop style and bind them to the model variables.

The model workflow is schematically illustrated in Figure 5. The model is written in Modelica, usually inside one of the popular Modelica IDEs such as the open-source OpenModelica or the proprietary and well-established Dymola.

The next step is to export the model into an FMU. Dymola supports the export of source code inside the FMU under their Source code generation license [81], and OpenModelica seems to always export the source code inside the FMU. Unfortunately, OpenModelica, as of the date of publication, only allows the export of a Euler solver, which is insufficient for many models.

The FMU then needs to be compiled into WebAssembly and JavaScript. To complete this step, we have prepared a Docker container, which uses Emscripten to automatically compile FMUs into Composer compatible files [82].

The container accepts FMUs generated by Dymola with the source code generation license and FMUs generated from OpenModelica on a Linux platform. The requirement for Linux is because of FMUs from OpenModelica being generated with makefiles, which are not only platform dependent but also machine dependent. To facilitate easier environment setup for the OpenModelica part of this workflow, we have prepared another Docker container, which uses OpenModelica to export FMUs automatically [83].

We use Adobe Animate [84] in the process of designing the interactive animations. Adobe Animate supports native export to HTML5 and JavaScript using the library EaselJS. This process is fairly painless as all the post processing of the exported JavaScript code is handled by the composer. Furthermore, the user can opt to write all EaselJS directly without the need to use the Adobe product.

Bodylight.js Composer is the main development focus of this project. Composer is a single-page application that can easily bring together models, animations, and control elements.

The core of Composer is built on React, an established and very popular JavaScript library. The HTML layout engine is provided by GrapesJS, around which the rest of the application was shaped. Composer allows the user to easily design an interactive HTML simulator. There are also several input and output widgets available. The range widget handles the control of the model variables. The chart widget uses plotly.js to display an output from the model in interactive charts. Toggle widgets and buttons can control Boolean values, and labels are used to display values.

The Composer is equipped with actions that are user-generated snippets of JavaScript code and can be attached to events of other widgets. For example, one of the prefilled actions is reset model with a model as a parameter. Users can attach actions to an onclick event of the button widget and select the appropriate model to reset. The animate widget is used to import complex animations created in Adobe Animate. These can contain continuously playing animations, whose speed and direction can be controlled by any model variable. Furthermore, it can control positional animations, where the timeline position is directly controlled by a model variable.

Users can also save and open shareable project files. The final export from the Composer is a stand-alone HTML file, containing the JavaScript and WebAssembly code. Composer workflow is depicted in Figure 6 and the composer itself in Figure 7.

We recommend readers to view the video tutorials on the Bodylight.js Web page [80] to get a better understanding of how Bodylight.js Composer works. The simple Bouncing Ball video on the main page demonstrates how to build a simulator comprised a simple interactive animation, a plot, a slider, and a reset button. It is also included in the Multimedia Appendix 1. There are 2 additional video tutorials available in the Documentation section of the Web page. The Simple Project tutorial [85] demonstrates how to build a simulator composed of sliders, plots, and a reset button. It is logically sectioned into different episodes. The steps are also explained below the tutorial videos. The second tutorial available is the more elaborate Physiological Application tutorial [86]. This tutorial demonstrates several advanced features for building a real simulation application of pressure-volume cardiac loops depicted in Figure 8. The additional features explained include creating a parametric plot, adding a start-stop button, controlling model parameters by events, and applying user functions on model variables. For example, descriptions on how to round the values or display string messages and other features are discussed. The translated models and the Composer project files are included in both tutorials.

Several simulators were created using Bodylight.js. In this section, one of the simulators is presented to demonstrate the capabilities of Bodylight.js. First, some basic physiology is introduced, and then the simulator is described, and the features of Bodylight.js are highlighted.

We created the Bodylight.js toolchain to facilitate the development of interactive simulators based on Modelica models. In this report, we focus on describing an important new component of the toolchain (Bodylight.js Composer), which enables the creation of browser-based simulators. More information about the toolchain and its use is available on the Web page [80].

The goals for the toolchain were addressed. Importantly, both Bodylight.js Composer and the simulators it produces are browser based and client side. The system runs in the browser without the need of any server-side back-end. It is also possible to distribute a standalone platform-independent HTML file and run it in the browser without an internet connection. This is enabled by the use of Web technologies such as JavaScript, WebAssembly, and HTML. We believe it will be future-proof (unlikely to become obsolete), as it is mainly based on open-standard technologies accepted and implemented by every major software vendor. If any of the applications in the toolchain are discontinued, it should be easy to replace them with another tool. We also find it to be user friendly. The models are implemented in the equation-based Modelica language using a modeling environment of the modeler’s choice, for example, OpenModelica or Dymola. Animations are created in a professional industry standard tool, Adobe Animate. The Composer uses the drag-and-drop technique to visually compose the simulator, and it is distributed under the General Public License 3.0 open source license and is freely available. Therefore, it is available for anyone to use and implement within their open-source projects. To our knowledge, no other tool exists, which meets all our requirements.

This approach brings together the domains of modeling, Web technologies, and graphical design, which supports better interdisciplinary cooperation of teachers, modelers, software developers, and graphic designers.

The Bodylight.js Composer is a self-contained client-side application, and anything submitted does not leave the user’s device; thus, there are no particular security or privacy issues.

Several simulators were created in Bodylight.js, and it proved to be a convenient solution fulfilling the needs of the designers. It would be extremely time consuming to implement these applications without this versatile toolchain. The new Nephron, Blood Circulation, and Pressure-Volume Loop simulators were presented in this paper to demonstrate the capabilities of Bodylight.js. The Nephron simulator was recently used in didactic classes of pathological physiology for medical students and was very well received by both the students and the teacher.

The client-side approach has several advantages over the client-server solutions available today. First, the simulator is not bound by the computational limitations of the server. The scaling problem is bypassed by avoiding the necessity of any server-side computations. Instead, we simply serve a Web page, which can be hosted on any Web server. Second, the client-side solution does not require a low-latency connection to the server. Thus, the client-side approach avoids the need for expensive Web hosting services.

E-learning and distance learning are becoming increasingly important in the world and particularly important in developing countries, where teachers are not easily accessible by many potential students [93]. Furthermore, because reliable internet connections may not be available for many people [94] and a round-trip latency is often high [95] in developing countries, the client-side solution could be more suitable here.

The OpenModelica export to FMU for Co-Simulation is currently limited to the Euler solver, without the option to include any of the other solvers available in the OpenModelica compiler. Euler is the simplest solver available, and its numerical performance is generally poor compared with more advanced solvers included in OpenModelica. Thus, the export from OpenModelica is currently not viable for many models. We are often forced to export the FMU from the proprietary Dymola, and this will continue at least until the issue with OpenModelica FMU export has been resolved.

The Adobe Animate, which is used for creation of the animations, is a commercial tool. JavaScript code describing the animations using the EaselJS library may be written by hand as an alternative.

In situations of a computationally complicated model or multiple plots or animations in the simulator, the performance drop becomes noticeable. The slower frame rate or model update rate does not make the simulator useless, but the user experience is reduced.

Bodylight.js relies on relatively new Web technologies; therefore, only browsers after late 2017 are able to run our simulators. However, because running older browsers is a security risk, most browser vendors have already switched to an automatic update system.

We will extend OpenModelica so that it can use advanced solvers in the FMU for Co-Simulation. We plan to optimize the model calculation and graphics rendering to achieve higher frame rates. The composer is modular in design; therefore, we are planning to add support for new libraries, such as different charting libraries or even other animation libraries, and external code contribution is welcomed.

The new toolchain facilitates the production of teaching simulators not only in physiology but also in other fields where the behavior of systems can be described by mathematical equations, including biology, physics, chemistry, engineering, and economics. Furthermore, the technology is not limited to education or academia. Anyone with the ability to model their system, whatever it may be, can use Bodylight.js to visually explain it to any interested party.

New generations of electronic textbooks combining texts with images, animations, multimedia, and interactive model-driven simulators are emerging. These textbooks allow for experimentation with the simulation of the particular systems being taught, which contributes to a deeper understanding of the topics of interest.

We recommend that the teaching materials be developed as platform independent in-browser applications, which do not require installation and can operate without an internet connection. Bodylight.js fulfills all these requirements and is free and available for anyone to use, which can only help to increase its impact. We hope that this project will help people better understand a multitude of diverse systems.