China
Africa
Explore chapters and articles related to this topic
DEVS as a Semantic Domain for Programmed Graph Transformation
Published in Gabriel A. Wainer, Pieter J. Mosterman, Discrete-Event Modeling and Simulation, 2018
Eugene Syriani, Hans Vangheluwe
The DEVS formalism was introduced in the late 1970s by Bernard Zeigler to develop a rigorous basis for the compositional modeling and simulation of discrete-event systems [2]. It has been successfully applied to the design, performance analysis, and implementation of a plethora of complex systems. Figure 1.1 shows the meta-model of a model transformation language based on DEVS. The dashed-line elements in Figure 1.1 (for now ignore the full-lined elements) show a simplified metamodel of DEVS in the UML Class Diagram notation. A DEVS model (the abstract class Block) is either an AtomicBlock or a CoupledBlock. An atomic model describes the behavior of a timed, reactive system. A coupled model is the composition of several DEVS submodels that can be either atomic or coupled. Submodels have ports that are connected by channels (represented by the associations between the different ports). Ports are either Inport or Outport. The abstract classes (In/Out)port can be instantiated in an Atomic(In/Out)port or a Coupled(In/Out)port, respectively. Ports and channels allow a model to receive and send events (any subclass of event) from and to other models. A channel must go from an output port of some model to an input port of a different model, from an input port of a coupled model to an input port of one of its submodels, or from an output port of a submodel to an output port of its parent model, as depicted by the associations of Figure 1.1. Note that the dynamic semantics of DEVS cannot be expressed by the meta-model and will be informally outlined hereafter.
SysML-based compositional verification and safety analysis for safety-critical cyber-physical systems
Published in Connection Science, 2022
Jian Xie, Wenan Tan, Zhibin Yang, Shuming Li, Linquan Xing, Zhiqiu Huang
The OCRA system specification generation for the SysML model is based on model transformation technology. Because SysML semantics is different from the OCRA system specification in terms of expressive power and scope, we only focus on a subset of the SysML model related to refinement, which specifically involves components, features, connections, and contract attribute sets. The global view of the mapping relationship between the SysML and OCRA Model elements is shown in Table 4. The detailed transformation rules are shown in Table 5, and Table 6. Especially, the model transformation language used in this paper is Xtend. Xtend can focus on the definition of model conversion rules without considering the pros and cons of the transformation algorithm and potential vulnerabilities in the design.