RT-LAB Orchestra is a software application that facilitates integration and interoperability between co-simulation components. Using the RT-LAB Orchestra API, components connect to an RT-LAB framework and exchange data with other co-simulation components, synchronously or asynchronously. Why is co-simulation required?
- Multiple simulation domains might be involved
- Different teams work together
- Various languages and simulation tools are used
- Government agencies may require legacy code to be re-used
As a result, models can be heterogeneous or require data hiding.
How it works
The core of Orchestra′s architecture is a user configurable communication layer, sitting on top of the RT-LAB framework, whose role is to provide a transport layer between distributed simulation nodes, and to act as a real-time scheduler for co-simulation. The communication layer consists of a set of shared-memory segments, one per domain. As a result, co-simulation components are co-located within the same RT-LAB simulation node.
Co-simulation components exchange simulation data via the communication layer by calling functions of the Orchestra RT-API, described below. Orchestra distinguishes two types of co-simulation components, namely the RT-LAB framework itself, and external components. Logically, an external component is a process that is not part of the Simulink-based model that the RT-LAB framework instantiates for real-time execution.
Physically, an external component is a cohesive software entity that embeds calls to the RT-API, and that is compiled and linked to form a stand-alone process. A single domain participant acts as a reader or a writer by using the RT-API to send or receive data respectively.
Orchestra is designed to be extensible; this is accomplished by clearly decoupling the RT-API from its implementation on the RT-LAB framework side. As a result, different domains may rely on separate implementations of the communication layer.
