Overture Sample Clauses

Overture. ‌ Years 1 and 2 of the INTO-CPS project saw the development of FMI support for Overture, including a tool-wrapper FMU exporter, as detailed in the Year 2 version of this document, Deliverable D4.2b [PBLG16]. Year 3 focused on FMI support in Overture toward deployment to hardware and toward HIL- simulation. This is achieved through standalone FMU export. Unlike tool-wrapper FMUs, which contain a combination of simulation tool and model, standalone FMUs contain code generated from the model with Overture's C code generator, VDM2C [BHPG16]. The code is compiled for Windows, Mac and Linux platforms as static libraries. The generated code is generic, in the sense that it is intended for deployment outside an FMI setting, but it is specialized by Overture's FMU exporter using wrapper code that provides the FMI interface. The FMI wrapper code contains two main features. First, communication between the ▇▇▇ and the generated code is achieved via bu er variables. When the ▇▇▇ needs to write updated inputs to the FMU, it does so by writing directly into the bu er variables. Internally, the FMU reads these bu ers and forwards the values to the model code. After an invocation of doStep, the wrapper code synchronizes the recalculated model variables back with the bu er variables, which are then read by the ▇▇▇. Second, the wrapper code implements both xed and variable step-size co-simulation. For a given step size requested by the ▇▇▇, the thread execution mechanism determines how many times each of the threads of the FMU can be executed, based on their declared period values. Those threads which t an integral number of times in the step duration are executed the corresponding number of times, and the output of their execution is made visible to the ▇▇▇. Those threads whose period is such that it either does not t inside one step, or does not t inside a step an integral number of times, are executed, but their outputs are only made available to the ▇▇▇ once an execution duration nishes inside a given step. For instance, a thread with a period of 3 will execute when doStep is called with a step size of 2, but its outputs will be made available to the ▇▇▇ only at the end of the second call to doStep. This can be viewed as a form of hysteresis in the output values in such cases. In order to make the generated code compatible with many embedded hard- ▇▇▇▇ platforms, the generated C code is compliant with the C89 standard.
Overture. In Overture, traceability is implemented as an additional package (as a .jar file), that can be downloaded from the GitHub page 3. This package extracts traceability information from the Git repository, where the current Overture project is stored in. It can be either triggered manually, or simply added to a Git post-commit hook, to send new traces to the daemon after the user commits the changes to the model to the repository. Similar to Modelio, this way of extracting traceability messages from the Git repository is useful if traceability has not been used since the start of the project.
Overture. ‌ This section describes the VDM platform Overture from the point of view of its role in co-simulation scenarios.