The Functional Mockup Interface (FMI) standard enables hybrid simulation of models from different tools. Such tools can have different underlying behavioral semantics, creating challenges when models are combined. A case in point is the combination of the Rhapsody tool, widely used to describe and implement discrete control behavior, and Modelica, widely used to describe continuous plant behavior. This paper describes a plugin we developed for exporting Functional Mockup Units (FMUs) from Rhapsody, and the results of combining generated FMUs with continuous models. When a Rhapsody FMU is used in a different environment, some basic assumptions on its behavior are challenged. We describe the semantic mismatches between the tools, to what extent they can be overcome, and what modelers need to do in order to preserve the intended semantics of an exported FMU. Keywords: FMI, Rhapsody, SysML, Hybrid simulation Complex cyber-physical systems are composed out of components and subcomponents, often designed and manufactured by different organizations. Each component can come from a wide range of different engineering domains, including mechanical, electrical, control, and software. Each engineering domain uses its own languages and tools; these are often not integrated with each other. This makes it difficult to perform analysis, verification, and design-space exploration at the model level, resulting in errors that are discovered late in the process (typically during integration), and are expensive to fix. In some cases there is ad-hoc integration between a pair of tools; for example, organizations commonly create connections using ad-hoc scripts. However, this is expensive, brittle, and sometimes wrong. Functional Mockup Interface (FMI) 1 is an open international standard for the integration of models between different tools that may use different underlying semantics (e.g., discrete state machines and differential algebraic equations). It specifies an interface that encapsulates a model as a Functional Mockup Unit (FMU), for communicating with hosting tools. The standard defines two types of export: model exchange and co-simulation. The main difference between them is that the former uses a solver of the hosting tool, while the latter includes its own solver and the hosting tool only orchestrates the simulation (transfers variables values, orders FMUs invocation, and selects the next communication step size). SysML 2 and UML 3 are modeling languages standardized by the OMG to describe structure and behavior of systems at various levels of abstraction. Statecharts [6] are a popular formalism for specifying behavior in SysML and UML; they are an extension of finite-state machines, and enable very concise decriptions of finite-state models. They are used to describe reactive systems at a wide range of abstraction, from the details of embedded controllers to high-level manufacturing processes. Some tools, such as IBM Rational Rhapsody®, 4 can execute statechart models, and, in the case of software applications, to synthesize production code from these models. Model execution (sometimes called "simulation") can be used to analyze and verify the design. However, many modern systems are cyber-physical and include physical models whose behavior is modeled in other languages and tools. In the example of Section 2, a statechart is used to model the controller of a heating system; other aspects of the system, such as the thermal plant, sensors, and actua-1 https://www.fmi-standard.org.
REF present a plugin for Rhapsody for generating FMUs from Statechart SysML blocks.
Simulating Rhapsody SysML Blocks in Hybrid Models with FMI
Proceedings of the 10th International Modelica Conference, March 10-12, 2014, Lund, Sweden
Proceedings of the 10th International Modelica Conference, March 10-12, 2014, Lund, Sweden
Computer Science