The workflow between the Twin Activate client and engine facilitates the modeling of reactive systems.

OML Command WindowModels and DiagramsScopes and DisplaysInterpreterXML Block LibraryInterfacing FunctionsAdapterSimulatorCompilerC Block LibraryC Code Generator

OML Command Window

The Twin Activate client provides direct access to the Interpreter through a Command Window that lets you enter OML commands and functions.

Twin Activate relies heavily on OML for creating and modifying block definitions; creating, editing and running models; manipulating elements inside of diagrams; customizing the user interface; and defining functions for the pre- and post-processing of data required for simulating models.


The Compiler converts models into a structure of functional blocks, definitions that specify the interconnection of the blocks, and scheduling tables that specify the order in which the blocks are called during the simulation process.

Models and Diagrams

The software provides features for creating, editing, simulating and managing models and their respective diagrams.


The Simulator runs according to the scheduling tables and other information that is provided by the Compiler.

The Simulator is a hybrid, which enables it to accommodate discrete and continuous-time systems and events during the simulation process. The Simulator uses a variety of solvers, which vary depending on the system being analyzed


The Interpreter evaluates block parameters, function statements and scripts written in OML and entered through the OML command window or OML Editor.

OML Integration

The OML scripting and mathematical computing language is packaged with Twin Activate to perform tasks such as defining block parameters and manipulating and simulating models. Several OML APIs are available for pre-and post-processing model data and executing operations such as a batch mode simulation.

OML-Based Operations
  • Creating or modifying block definitions.
  • Authoring scripts to create, edit or run models.
  • Manipulating elements inside of diagrams.
  • Pre- and post-processing data required for model simulation.
OML-Shared UI Components
  • Command window
  • Plot windows
Examples of OML Usage
  • Editing and running OML commands from View > OML Command Window or Tools > OML Editor.
  • Defining a model or block parameter with OML statements as you can see in the ContStateSpace block dialog:

  • Exchanging data in the software via OML.
  • Editing and simulating a model with OML APIs.

Scopes and Displays

The software includes Scope blocks for plotting data, and other display options for visualizing simulation results.

XML Block Library

The software includes a block library which has a variety of pre-defined blocks for creating models.

The blocks are written in an XML format with the .scb file extension. Each .scb file contains a block definition with graphical properties, ports, parameters, and interface functions.

Interfacing Functions

The Evaluation function is a part of the XML definition of a block. For each block in a model, the Evaluation function is evaluated by the OML Interpreter to obtain actual values.


The Adapter is a generic component that interfaces all components of the architecture.

C Block Library

Aside from its XML content, each block comes with a simulation function to implement the block definition. Most of the block simulation functions are written in C language and are available to the Simulator as a DLL library.

C Code Generator

The engine of the software generates C code as required for operations such as the FMI export.


The Twin Activate environment includes an underlying formalism that facilitates the modeling of hybrid reactive systems.

Twin Activate's handling of the specification of events enables the creation of models with both synchronous and asynchronous dynamics. Additionally, Twin Activate's management of activation signals allows control of system dynamics, enabling the construction of models with complex timings.

HML to OML Migration

Twin Activate 2019 introduced the concept of H2O, the migration of the scripting language HyperMath to OpenMatrix.

OML is the official replacement for HML, the scripting language supported in Altair Twin Activate 2016-2017.3.

Role of OML in Altair Twin Activate Version 2019 and Above

OML is the standard scripting language supported in Twin Activate and Compose. Some common applications for OML in Twin Activate models include:

  • Creating variables
  • Writing contexts
  • Writing block definitions
  • Interacting with models through the OML Command Window
  • Loading libraries

What You Need to Know for the H2O Migration

  • Although HML and OML have some syntactic differences, their overall conception and field of application are similar, and the migration from HML to OML is seamless in most cases.
  • Language and reference guides for OML can be found in the Compose and Twin Activate documentation.

What You Need to Do if You are Working with Models Created with Altair Twin Activate 2016-2017.3

  • In most cases, no action is required. Twin Activate version 2019 and above includes an automatic translator which converts legacy models.
  • In cases where models contain contexts with advanced HML scripts, any functions that are converted into OML require review and testing. The same applies to models that are accompanied by HML scripts for preparing data.

What You Need to Change for the H2O Migration

  • For block parameters defined as strings, change the double quotes in HML to single quotes in OML.
  • Replace the HMLCustomBlock in models with the OMLCustomblock.
  • Note that legacy solidThinking Twin Activate block libraries are automatically converted into Altair Twin Activate block libraries when opened in a current version of Altair Twin Activate.

Migrating an HML Script/Context

  • Migration example for the context in the Twin Activate demo model, Hybrid_Extended_Kalman_Filter.scm:

  • Migration example from a script found in the Optimization chapter of the Extended Definitions for Advanced Users (PDF):

API Changes

  • Twin Activate provides APIs to create, edit and manipulate models. These APIs have been migrated from HML to OML but retain very similar names and arguments.
  • More information about the APIs is available in the Extended Definitions for Advanced Users.


  • The migration from the HMLCustomBlock to the OMLCustomBlock involves migrating the HML code that defines the block behavior. With the help of a skeleton generator found in the OMLCustomBlock, migrating each part of the block code is very easy.
  • HMLCustomBlock empty skeleton:
    function HmlBlockFunction(block,flag)
      if flag ==  hwscpEngineBlock.INITIALIZE then
      elseif flag ==  hwscpEngineBlock.REINITIALIZE then
      elseif flag ==  hwscpEngineBlock.TERMINATE then
      elseif flag ==  hwscpEngineBlock.OUTPUT_UPDATE then
  • OMLCustomBlock empty skeleton:
    function OmlBlockFunction(block,flag)
      if flag == vssBlockInitializeFlag
      elseif flag == vssBlockReinitializeFlag
      elseif flag == vssBlockTerminateFlag
      elseif flag == vssBlockOutputUpdateFlag
  • Migration Example of the Twin Activate demo model Fft_anim.scm:

Migrating Libraries

The following commands can be executed in the OML Command Window:


Commands for Migration

  • Although Twin Activate automatically converts most models, some scripts may require individual conversion.
  • OML commands have been added and exposed to facilitate the migration.
  • Migration of an HML file:
    hwscpEngineUtilsAPIs_TranslateHmlFile('file1.hml', 'file1.oml')
  • Migration of an HML expression: