Maestro – A model‐based systems engineering environment for complex electronic systems

Abstract

In this paper we present Maestro, a model-based systems engineering (MBSE) environment for design and simulation of complex electronic systems using Orchestra-a simulation tool developed at Sandia National Laboratories. Maestro is deployed as a plugin for MagicDraw and uses Orchestra domain-specific language (DSL) which is based on SysML. Maestro enables a model-based design and analysis approach that replaces the traditional document-based systems engineering process. It provides a unified graphical modeling environment to domain experts who have had to depend on drawing tools for defining system architecture and manual transcription of system topology in creating complex simulation models.

Collaborative Verification-Driven Engineering of Hybrid Systems

“…Model-driven engineering in a collaborative manner has been successfully applied in the embedded systems community. Efforts, for instance, include transforming between different UML models and SysML [26], modeling in SysML and transforming these models to the simulation tool Orchestra [5], integration of modeling and simulation in Cosmic/Cadena [22], or modeling of reactive systems and integration of various verification tools in Syspect [19].…”

“…(4). Decision nodes with tests are either translated into if-statements (5) or if-else-statements (6). Finally, a decision node with a matching merge node (but without a back edge) is transformed into a nondeterministic choice, cf.…”

“…• Unlike [26,5,22], who focus on exchanging models, we also facilitate collaboration on formal verification.…”

“…Besides defining the semantics of the Hybrid UML profile, model transformations can be implemented as model transformation specifications (e. g., using the Atlas transformation language ATL [29]) and executed to transform models back and forth between the Hybrid Program UML profile and their hybrid program counterparts. Since hybrid automata can be encoded in hybrid programs [60, Appendix C], 5 we define both, a hybrid program semantics and a hybrid automaton semantics, for the Hybrid Program UML profile. Note, however, that hybrid automata, when encoded in dL, are often less natural to express and also less efficient to verify than well-structured hybrid programs, because they lack program structure that could be exploited during the proof and require additional variables to identify the states of the automaton.…”

“…Finally, if the robot is stopped, it may choose to remain in its current spot and may or may not change its orientation while doing so, cf. (5). This is expressed again by arbitrary assignment with subsequent test: this time, the test ?o 2 r = 1, however, restricts the orientation value to either forwards or backwards (or ∈ {1, −1}).…”