Saulius Pavalkis

Avatar

I'm Global User Support Manager and Analyst in MagicDraw R&D team for over 10 years with increasing responsibilities. My major expertise area is model-based requirements engineering. I'm the owner of a new Cameo Requirements Modeler product, which has been recently introduced in MagicDraw product line. I hold a PhD in model traceability from Kaunas University of Technology (KTU). I also hold multiple professional certificates: OMG-Certified UML Professional, OMG-Certified Expert in BPM, ITIL V3, OMG-Certified Systems Modeling Professional. I have written multiple research and practical articles in model-based software design. I'm the founder and chief editor of modelling community blog (blog.nomagic.com) dedicated for sharing practical model-based engineering experience.

Oct 012019
 

This blog post covers the integration process of the latest versions of Lego Mindstorms EV3 and Cameo Systems Modeler. Next post will cover actual modeling and simulation Lego EV3 in SysML. Flow instructions and video below!

What you will need

  1. Lego EV3 Plugin for Cameo Systems Modeler. Download it here: https://bit.ly/2nAC38m
  2. LejOS EV3 operating system replacement for EV3 brick to communicate with Cameo Systems Modeler. Instructions to download and install it to EV3 are here: http://www.lejos.org/ev3.php
  3. SD Card to install LejOS on EV3 (you will need a blank SD card of at least 2GB and no more than 32GB. SDXC cards are not supported by the EV3 hardware). If you are not sure what card to buy use this card from Kingston.
  4. Laptop with SD card reader or just SD card reader.

 Integration steps

  1. Download and install Lego EV3 Plugin for Cameo Systems Modeler. Check that plugin is loaded when you start Cameo Systems Modeler.
  2. Format SD card, preferable make 4 GB main partition. You can use free “MiniTool Partition Wizard”.
  3. Download and install Java Development Kit (JDK) on your PC (you will need to create Oracle account)
  4. Download and install LejOS (latest version 9.1-beta is good choice) on SD Card.
  5. Add SD card to EV3 and turn it on. Wait till it boots.
  6. Connect PC to EV3 Bluetooth.
  7. Start Cameo Systems Modeler, load project sample. Run simulation.

About Lego EV3 Plugin for Cameo Systems Modeler

Lego EV3 Plugin for Cameo Systems Modeler is a customized plugin provide a model library represent the LEGO® MINDSTORMS® EV3 (https://www.lego.com/en-us/mindstorms/products/mindstorms-ev3-31313) component and the java API to control EV3 hardware.

The plugin consists of:

  1. Java API: The API for directly connect/control the Lego EV3 hardware (Brick, Sensors, and Motors).
  2. Model Library: The SysML model described the Lego EV3 hardware and their behavior, the components behavior will perform the Lego EV3 action through the Java API and Cameo’s simulation capability.

About LejOS Ev3

Originally Lego EV3 hardware come along with the LEGO’s Operating system. To communication Lego Ev3 hardware with the Cameo Simulation Toolkit, we selected to use the third-party software named LejOS. This is a operating system for Ev3 which provides the Java library we can implement the Java source code as a plugin to be a bridge between EV3 and the model. For more details of LejOS please visit: http://www.lejos.org/ev3.php

Oct 222018
 

SysML allow both structural and behavioral modeling of the system. SysML models can be formally interpreted and executed. Ones executed analysis can be performed at system level. Ones we are good with simulation results we can prototype. Using programmable Lego Mindstors NXT for prototyping is an out of the box way to test and demonstrate future system behavior. We can use same system model to control and calibrate prototype.

In the second video [1st reference – 1st part] from the series of three we will demonstrates the SysML transmission model connected to LEGO Mindstorms NXT linear gearbox. We will demonstrate how using API between Cameo Systems Modeler and LEGO executable SysML model controls switching between gears in LEGO model. We will show how model is built to use API.

See video demonstrating working integration and model setup:

Java API of LEGO Mindstorms NXT is accessed by Cameo Systems Modeler plugin [2nd reference], which enables below functions in the model to control motors and read sensors data.

NXTManager.startRunMotor(x,y,z);

x – Motor number starting from 0

Y – Power (with “–“ in front if direction is opposite)

Z – Degrees of rotation

Sample: NXTManager.startRunMotor(1,-100,4000);

NXTManager.getColorBySensor();

Sample: color = NXTManager.getColorBySensor();

NXTManager.getDistanceFromSensor();

Sample: distance = NXTManager.getDistanceFromSensor();

NXTManager.stopRunMotor(x);

X – number of motor

Sample: NXTManager.stopRunMotor(2);

Functions are used in custom created opaque behaviors library associated with state machine states to execute when entering the states, leaving the states, and in transition. Fig. 1 demonstrate setup and use of the opaque behaviors library.

Fig 1. Setup and use of open behavior library with functions to control LEGO

Next

In the third video we will demonstrate how LEGO gearbox (hardware in the loop) is calibrated to get right gears transfer rate and speed eliminating instability of motor speed depending on load introduced by gearbox.

References

  1. Building Executable SysML Model – Automatic Transmission System (Part 1) https://blog.nomagic.com/building-executable-sysml-model-automatic-transmission-system-part-1/
  2. Interface between Cameo Systems Modeler and LEGO Mindstorms https://blog.nomagic.com/collaboration-between-simulated-model-and-external-system-controlling-lego-mindstorms-with-cameo-simulation-toolkit/

About Cameo Simulation Toolkit

The Cameo Simulation Toolkit provides the first in the industry extendable model execution framework and infrastructure based on number of standards:

  • Model debugging and animation environment
  • Pluggable engines, languages and evaluators
  • User Interface prototyping support
  • Model driven configurations and test cases

The standard based model execution of:

  • Activities (OMG fUML standard)
  • Composite structures (OMG PSCS)
  • State Machines (W3C SCXML standard)
  • Actions/scripts (JSR223 standard)
  • Parametrics (OMG SysML standard) including build in and external math solvers: Math solvers: Built-in solver, Matlab, Maple, Mathematica, OpenModelica.
  • Sequence diagrams (OMG UML Testing Profile)
Mar 292018
 

We often get question how Cameo Systems Modeler (or MagicDraw) and SysML/UML integrates with MATLAB/Simulink? Let’s go through integration use case and current implementations.

Integration Use Case and Implementations

1st Case. Run MATLAB/Simulink Analytical Models From MagcDraw with Parameters from UML/SysML Model and Get Results Back

Systems Modeling Language (SysML) is used to capture systems design as descriptive and analytical system models, which relate text requirements to the design and provide a baseline to support analysis and verification.

SysML Parametric models enforce requirements and capture constraints on the performance or physical properties of systems, which can then be evaluated by an appropriate analysis tool (as MATLAB/Simulink) to support wide variety of engineering analysis and simulations.

Integration

Calling of MATLAB/Simulink functions directly in MagicDraw is possible using Cameo Simulation Toolkit. MATLAB is one of the evaluators which is supported. When you call MATLAB function you can pass parameters from the UML/SysML model, execute MATLAB/Simulink model and get results back to UML/SysML model (Fig 1.).

Fig 1. SysML project executing Simulink model and getting results back. Charts from Simulink are on top.

This integration is described in webinar – “SysML model integration with MATLAB/Simulink®”

Integration is demonstrate starting this point:

Find below Matlab “m” file and MagicDraw project file used in this webinar to perform interaction with Simulink steps demonstrated in webinar:

2nd Case. Interchange Structural and Behavioral Model Data Between SysML (IBD, Activity, States) and MATLAB/Simulink and Stateflo

This is possible because Simulink has building blocks to make simulations easier to achieve and have model more readable. This enable interchange, synch, and trace between SysML system model parts to specific analysis models in Simulink, or reuse Simulink models in SysML. Both models can exist at the same time, be in synch or traceable.

Integration

For structure interchange, synch, and traceability Syndeia from InterCAX (No Magic, Inc. partners) can be used.

Syndeia allows:

  • Populate a Simulink model from SysML IBD or Activity diagram
  • Populate a SysML model from Simulink
  • Compare and Synch

Integration is discussed starting this point:

Integration with Stateflow:

Other than 1st use case this integration does not create connection to execute Simulink from SysML model.

OMG standard for SysML Extension for Physical Interaction and Signal Flow Simulation (SysPhS)

Last but perhaps the most important is ability to have standard based interchange covering both above use cases.

SysPhS standard is a platform-independent extension of SysML for physical interaction and flow (also known as lumped parameter, one-dimensional, or network models, appearing in simulation platforms such as those supporting the Modelica language and in MathWorks Simulink and Simscape) (Fig 2.).

Fig 2. SysPhS Based Integration

Cameo Systems Modeler v19.0 SP2 is going to export to both Modelica and Simulink with folowing constraints:

  • Diagrams exported: BDD, IBD, Statemachines, Parametrics
  • One way transformation, no sync or updates
  • No diagram layout for Simulink

More information about SysPhS:

Let us know your thoughts!

Mar 072018
 

If you want to model communication channel which crosses part of the system but does not affect it you can use delegation connector. This would allow to send signal from one system part forward it through intermediate one and receive it at target system part.

Video demonstrating sample

Rocket sample

Let’s take rocket model sample. Our rocket has 3 stages (Fig 1).

Figure 1. Rocket

Stage 3 has flight control computer which shall send engine ignite signal to stage 3 engines. Signal shall go through wire which is crossing stage 2 (Fig 2).

Figure 2. Internal Communication

Note that connector connecting stage 2 ports kind is delegation. Other connectors in this diagrams are assembly.

How to create delegation connector?

Connector kind is derived property. Its value (assembly or delegation) is based on what connector connects. To create delegation connector for stage 2 follow these steps:

  1. Create IBD for Stage 2 block (Fig 3)
  2. Connect ports with connector in created IBD (Fig 3)

Figure 3. Stage 2 IBD

  1. Go to your Rocket IBD select stage 2 part ports and show created connector. Delegation connector will be displayed. (Fig

Figure 4. Display port paths

Next send ignite signal and using model execution with animation verify it passing to stage 1 (Fig 5).

Figure 5. Model execution with animation

Used MagicDraw project file: delegation connector.mdzip

“A delegation connector is a connector that links the external contract of a component (as specified by its ports) to the internal realization of that behavior by the component’s parts. It represents the forwarding of signals (operation requests and events): a signal that arrives at a port that has a delegation connector to a part or to another port will be passed on to that target for handling.” Source: OMG, OMG. “Unified modeling language (omg uml).” Superstructure (2009).

Feb 062018
 

We would like to share a list of generic No Magic’s recommendations for the best practices on model management in Cameo tools suite. How should the model be broken up to optimize from the project architecture perspective and element reuse?

Do not split if you do not need

In general splitting project to many projects shall not be the goal. It is easier and more efficient to work in one project working in Teamwork Could – repository or on single standalone file. In general, Teamwork Cloud perform better with flat models (work is in progress to fine grain the cases when this applies).

So work in one project until you need to decompose it. Below are the reasons why you might consider decomposition. E.g. keeping reusable libraries as read-only separate projects (module(s)) that do not change on daily basis is fine and common case for reusability purposes.

Common factors to split

There are many factors that will influence determination when separate model projects need to be created.  Common factors include:

  • Classification
    • Separate model projects are needed when models exist across multiple security enclaves.
    • Lower classification level models are used by higher classification level models that provide the complete integrated data set.
  • Reuse
    • Separate model projects are often employed for reuse libraries to manage deployment of revised baselines.
    • As separate configuration items, they may be subject to independent CM/CCB lifecycles.
  • Planned levels of Abstraction/Decomposition
    • Typically the Conceptual, Logical and Physical Models are complete model project’s with horizontal traceability within the abstraction layer and vertical traceability between abstraction layers.
    • As with reuse libraries, they may need to be controlled as separate configuration items with their own CM/CCB baselines and status accounting.
  • Contract/Subcontract/WBS Boundaries and Network/Tool Boundaries
    • Depending on access to the shared repository, contract terms and conditions or other “work flow” issues, contract boundaries for model content owned by subcontractors or contractor teams may not be sufficiently managed through package access and privileges.  Separate models may be required to protect information or to provide means to establish contract baselines or exchange data effectively.
  • Manage Releases. When you model multiple different sub-systems, which has different release cycles, you need to model every subsystem in a separate project to be able to baseline them separately. Later you can indicate which version of the sub-system you are using in particular configuration. The same applies for components, etc.
  • Product Line Engineering (PLE). Current best practices in product line engineering is to have separate projects for different variants of the system.
  • Requirements synch. Based on our experience working with Cameo DataHub and IBM DOORS we highly recommend having Requirements in separate project than your architecture. This helps you to version SRS separately from your architecture. It is helps you to revert easier to previous version if the synch fails and it also does not stop you from working while synchronization is in progress (sometimes it takes hours).

All cases are a bit different

From our experience model partitioning depends on the Work Breakdown Structure (WBS) and can be very individual. Though we can describe best practices, it is the expertise we deliver as a consulting service.

Authors:

 

Barry Papke

Director of Professional Services, No Magic, Inc.

Aurelijus Morkevicius

Head of Solutions, No Magic Europe

Tomas Vileiniskis

Teamwork Cloud Product Manager

 

 

Oct 232017
 

Requirements quality is big problem which causes projects to delay and be out of budget. This means a lot of money in case of complex SE projects (Fig 1). Traditional requirement management toolsquality problem address by using natural language analysis with different rules to check for requirements duplication, overlapping, and bad language. Most of those means does not cover logical issues of not understood system functionality. This is perhaps biggest source of mistakes. Poor system requirements push problems to solve in development. How to enforce good quality requirements which would clearly describe the system?

Fig 1. Requirement Issue Cost Source: Defense Acquisition University, 1993. Cost of defects increases disproportionately after the design phase.

SysML provides rich means to address requirements quality issue by formalizing them with system model (Fig 2). Descriptive system model represents system from behavioral, structural, and Parametric viewpoints giving full understanding of requirements at any level.

Fig 2. Refined Requirements with Model

The presentation cover usage of SysML to refine text-based requirements with model, and model execution to automatically verify requirements:

Download (PDF, Unknown)

Presentation PPT: https://goo.gl/UVRB32

Bluetooth Headphones SysML project: https://goo.gl/ZrQ6EA

Conclusions

  • In document based system engineering big problem is disconnection between design and analytical models and in general between different design artifacts.
  • MBSE provides: methods, tools, and languages for requirements formalization and significant quality increase.
  • Presented MBSE with SysML based approach – MagicGrid (Fig 3.) for requirements formalization. It:
    • Using SysML as a language provides rich means to address requirements quality issue by formalizing them with system model. Descriptive system model represents system from behavioral, structural, and parametric viewpoints giving full understanding of requirements at any level.
    • Ensures requirements traceability
    • Supports automated requirements analysis

Fig 3. MagicGrid – Framework and Metod for Model based Requirements Management

More about Method and Framework

Introduction to MagicGrid you can find in webinar: https://lnkd.in/evCpPz9

You can learn more about MagicGrid from tutorial part1: https://lnkd.in/eefDKMc part2: https://lnkd.in/eDnmfdi

 

Oct 082017
 

SysML allow both structural and behavioral modeling of the system. SysML models can be formally interpreted and executed. Ones executed analysis can be performed at system level. Ones we are good with simulation results we can prototype. Using programmable Lego Mindstors NXT for prototyping is an out of the box way to test and demonstrate future system behavior. We can use same system model to control and calibrate prototype.

In the first article from the series of two we will create automatic transmission system model in SysML, describe transmission controller behavior, analytical model, user interface, and execute the model.

See video demonstrating final model:

Final project file: Transmission.mdzip

In the second part we will connect SysML Transmission Model to Lego Mindstorms NXT gearbox. Model will control switching between gears.

Motivation behind Model Execution

The purpose of a simulation is to gain system understanding without manipulating the real system, either because it is not yet defined or available, or because it cannot be exercised directly due to cost, time, resources or risk constraints. Simulation is typically performed on a model of the system.

Executable modeling allows system simulation and enables following engineering analysis:

  • Evaluate design alternatives
  • Select the best set of parameters
  • Verify system constraints
  • Perform requirement compliance analysis
  • Perform what-if analysis
  • Execute SysML and UTP test cases

“This is an important development since it requires minimal configuration, can be used earlier in the lifecycle and can evolve as the design matures.”

NASA Perspective on Recent Trends in Executable Models

“Executable UML is the next logical, and perhaps inevitable, evolutionary step in the ever-rising level of abstraction at which programmers express software solutions. Rather than elaborate an analysis product into a design product and then write code, application developers of the future will use tools to translate abstract application constructs into executable entities. Someday soon, the idea of writing an application in Java or C++ will seem as absurd as writing an application in assembler does today.”

Grady Booch

Transmission System

Modern transmission consist not only from mechanical parts but also from electronics. Transmission control unit (Figure 1) controls gearbox and switch between gears based on many car parameters.

Figure 1. Transmission System

Structure of the Model

To describe transmission controller and demonstrate how gears in the gearbox are changed we will create:

  • Structure diagrams – describes parts of the transmission and interfaces
  • Behavior diagrams – describes behavior of the transmission
  • Parametric Diagram – describes analytical part of the model.

We will combine all the diagrams to have one system behavior description. We will add UI and will execute model.  We will setup automatic requirements verification.

Behavior of the Transmission

For behavior part of the transmission we will use State Machine diagram. State machine describes possible states of a particular block and transitions between states. In Figure 2 we see simple state machine which can be executed by its own without context – structural part of the system.

Figure 2. State Machine

If we want update value properties depending on state, for example active gear (Figure 3), we need context which will hold those properties.

Figure 3. State Machine with entry action to update property value

 

Final State machine diagram (Figure 4) depending on gear: changes differential gear ratio (1), increases RPM (2), on RPM change switches gears (3).

Figure 4. Final State Machine

Structure of the Transmission

We will describe structure of the transmission with block definition diagram (BDD) (Figure 5). BDD is used to define blocks in terms of their features and structural relationships with other blocks. In SysML, systems are built from basic structural elements called blocks. Blocks include features that allow us to describe same real-world attributes in a system model.

Figure 5. Transmission system structure

Note that state machine is owned by block which behavior it’s represents (Figure 6).

Figure 6. State machine shall be in the context of the system which behavior it describes

Project Structure is important. Behavior descriptions need to be contained underneath the element which is executed. Executable element can only have one main behavior. Recommendation for the main behavior which controls other behaviors is to use State Machine Diagram. State Machine diagram can be enriched with other behaviors e.g. start activity on enter to state, or execute code as effect of switch between states.

Vehicle Speed Analysis

We defined behavior description and connected to structure. Now we want to enrich model with more parameters and want to do additional static and dynamic calculations. For these tasks we need to create parametric diagrams.

Parametric diagram connects SysML Constraint blocks as a network of reusable constraints that represent mathematical expressions, which constrain the physical properties of a system. SysML parametric diagrams provide a way to integrate engineering analysis models described in mathematical equations and constraints, with design models describing the structural and behavioral aspects of systems.

Our goal will be to calculate vehicle speed from engine Revolutions per Minute (RPM). We will use following four (Figure 7) mathematical expressions. We will formalize them in SysML constraint blocks.

Figure 7. Expressions formalization with constraint blocks

As an input we will need wheel characteristics (Figure 8).

Figure 8. Wheel characteristics required for vehicle speed calculation

We will create value properties in Transmission Control Unit to hold inputs, intermediate, and result values of analysis (Figure 9).

Figure 9. Transmission Control Unit with value properties

Now in Transmission Control Unit we will create SysML parametric diagram to connect constraints with value properties (Figure 10).

Figure 10. Parametric diagram to calculate vehicle speed based on RPM

We will execute parametric model to get results based on the inputs. Execution of mathematical models expressed as SysML parametric diagrams enables automatic dependent parameter value updates at any time during simulation. Mathematical expressions can be solved using build-inn math engine or well-known math solvers.

Figure 11 shows (1) parametric diagram execution button, (2) Simulation dialog variables tab with executed model and instantly calculated values.

Figure 11. Parametric diagram execution

User Interfaces Mockups

User interface model can be created using User Interface Modeling Diagram. Using drag’n’drop it connects various system parts to GUI components.

  • Classes/Blocks to Frames
  • Signals to Buttons
  • Properties to Labels
  • Images to active element switchers

In User Interface Diagram (Figure 12) we will define mockups (blue color lines) and connect to system model (red color lines).

Figure 12. User Interface mockup

Additionally:

  • Web based UI – enable to run simulation remotely.
  • Open API allows using dedicated third-party tools of choice to create and plug realistic system mockup;

Simulation Configuration

To have user interface mockups in the model we will create simulation configuration diagram (Figure 13). In simulation configuration diagram simulation configuration element (2) define what elements needs to be executed, what UI used, and all execution related properties. One’s configuration is created it appears and can be started from dropdown Executions List (1). To have gear handle switching animation we will use Image Switcher (3) which allows animation by using multiple images representing different system states.

Figure 13. Model execution configuration diagram

Requirements Verification

For automatic requirements verification we will create satisfy relation from Transmission Control Unit block property RPM to requirement which it shall satisfy (Figure 14). With help of model execution and analysis we will check is value of this property (and design) satisfy requirement or not.

But what is success criteria? How to formalize text based requirement to constraint block value property? For this purpose we create constraint block which refines requirement. So property which satisfies requirement is constrained by constraint block constraint which refines requirement (Figure 14).

Figure 14. System characteristics and requirement relation

Note that in simple cases manual requirement refinement with constraint block is not required. Natural language analysis capability available in modern modeling tools recognize text pattern based one predefined and customizable ones and create constraint automatically [1].

Simulation of Coordinated Entities

Simulation Configuration

Is used to define what elements needs to be executed, what UI used, and all execution related properties, charts, results and input location.

Structure and Behavior

Project Structure is important. Behavior descriptions need to be contained underneath the element which is executed. Executable element can only have one main behavior. Main behavior is defined with property “Classifier Behavior”. Recommendation for the main behavior to use State Machine Diagram. State Machine diagram as a governing diagram

State Machine and Other Behavior Diagrams e.g. Activity Relation

As OMG fUML execution model is used as foundation for all kinds of executions, but does not support statemachines, SCXML engine is wrapped to fUML Execution interface to fill this gap and provide complete integrated execution of different UML behaviors. It allows calling Statemachine in CallBehaviorActions, use Activities to define entry/do/exit activities of the State, use SendSignalAction to trigger Transitions in the Statemachines.

Parametric Diagrams

It should be contained in the structural element which needs to be executed.

Reusable Elements

Reusable elements (Interface Blocks, behaviors (if not the main behavior) signals, Constraint Blocks, etc.) can be contained anywhere in the model.

Communication of Subsystems

There are situations where you want to describe how two independent subsystems communicate with each other. Signals send by one block behavior can control another block behavior e.g. trigger sate transition (Figure 15). This task can be performed in the tool but requires to have:

  • Description how these subsystems communicate (IBD);
  • Through which port signal should be sent

    Figure 15. Ports and send signal actions relation

Activities which are used to send signals can be connected to state machine diagram and invoked during execution as effect on transition or as behaviors performed on Entry/do/exit from state (Figure 16).

Figure 16. Part of state machine which user’s activities as effect on transmission to send signal

Instead of simple RPM we could have probability based RPM described in activity diagram (Figure 18).

Figure 18. Activity diagram describing RPM change logic

Running model execution

One’s transmission model is created it can be executed (Figure 17) (1). On execution Simulation window will open (2). It contains four tabs: Sessions, Console, Variables, and Breakpoints. At this point, an instance of the Transmission Control Unit is created, which you can see in the Variables tab. In addition, a simulation session to execute the Transmission Control Unit block is created, which you can see in the Sessions tab of the Simulation window. The classifier behavior (state machine) of the Transmission Control Unit block, starts executing (3). A new session to execute the state machine is created under the simulation session of the Transmission Control Unit (2), and the Transmission Control Unit state machine diagram is open and started from the initial Pseudostate and automatically move to the Parking state because the Transition that connects between the initial Pseudostate to the Parking State does not have a defined trigger. When the ready State is entered, its entry Behavior is executed, which executes property update gear=”P”.

At the same time parametric diagram is evaluated, it takes default values and calculates results based on expressions. On any value change parametric diagram is recalculated. RPM value is marked green or red depending on connected requirement (Figure 14) which it satisfies or not.

Last user interface mockup and gear switch animation is displayed (4).

Figure 17. Transmission Control Unit system execution

Challenge

Perform analysis to find the best switching between gears or gears rate differential and optimize transmission system for fastest acceleration (Figure 19). For this save execution results into instance or file and compare between different configurations.

Figure 19. Transmission optimization to provide more power on exploration. Source: https://www.youtube.com/watch?v=36H9BVeMYMI

SysML Transmission Model Controlling Lego Mindstorms NXT Liner Gearbox

In the second part of the article from the series we will connect SysML Transmission Model to Lego Mindstorms NXT liner gearbox (Figure 20). Model will control switch between gears.

Figure 20. Lego 4 gears linear transmission model used to prototype. Source: https://www.youtube.com/watch?v=0Aw23jQkP2g

For more about Cameo Simulation Toolkit and Lego Mindstorms NXT integration refer to [2].

References

  1. https://docs.nomagic.com/display/CRMP185/Extracting+Constraint+from+Requirement
  2. https://blog.nomagic.com/collaboration-between-simulated-model-and-external-system-controlling-lego-mindstorms-with-cameo-simulation-toolkit/

Download

About Cameo Simulation Toolkit

The Cameo Simulation Toolkit provides the first in the industry extendable model execution framework and infrastructure based on number of standards:

  • Model debugging and animation environment
  • Pluggable engines, languages and evaluators
  • User Interface prototyping support
  • Model driven configurations and test cases

The standard based model execution of:

  • Activities (OMG fUML standard)
  • Composite structures (OMG PSCS)
  • State Machines (W3C SCXML standard)
  • Actions/scripts (JSR223 standard)
  • Parametrics (OMG SysML standard) including build in and external math solvers: Math solvers: Built-in solver, Matlab, Maple, Mathematica, OpenModelica.
  • Sequence diagrams (OMG UML Testing Profile)

Authors: Zilvinas Strolia and Saulius Pavalkis

Zilvinas is a Solution Architect at No Magic Europe. His expertise area is model-based systems engineering (MBSE) with special focus on model execution.

Zilvinas has an engineering degree from Kaunas University of Technology (Lithuania) and almost 10 years of work experience in this field. He also holds the OMG-Certified Systems Modeling Professional (OCSMP) certificate.

Zilvinas is responsible for consulting and delivering the solutions to customers. He occasionally writes papers and produces training material (slides, samples, practical assignments).

 

Jan 092017
 
During this webinar, you will learn how MagicDraw with Cameo Simulation Toolkit can be used to verify how particular system design satisfies time, duration, or performance requirements.

The session demonstrates

  • Timing concepts, different clocks, time steps
  • Time units
  • Time and duration constraints
  • Duration simulation, parallel processes
  • Timelines

Recording

Slides

Download (PDF, Unknown)

The webinar is delivered by Nerijus Jankevicius, MBSE Product Manager at No Magic, Inc.

Nov 152016
 

“Everything new endangers something old… This is the price that must be paid for progress and it is worth it.”

Hyman G. Rickover

Good quality video tutorials and the best tips & tricks from Systems Engineers to Systems Engineers. Welcome to Systems Architecture Guild (www.systemsarchitectureguild.org) and its companion YouTube channel (http://tinyurl.com/showmethewow).

Author says “I’ve started a personal crusade against poorly-executed MBSE. There are a lot of great many misconceptions about the current state of the art (in both tools and techniques). There are also a great many traditionalists chasing phantom problems that are eliminated by the creation of a robust system model.”

You will find here basic topics (introduction is important):

  • Why SysML?
  • Requirements overview
  • Architecture schema
  • Use cases and use cases analysis

As content grows it dives deep fast:

  • Functional Hazard Analysis
  • Derived properties

For example – variants management:

Nov 142016
 

You might already thought about tracking metrics based on model data. However how difficult is to create your own metric?

Using MagicDraw metrics capability and structured expression dialog to setup almost any metric logic and calculate it requires no coding.

If you already using structured expression dialog to query model for derived properties or smart package it is definitely nothing new for you. Even if you do not, simple query is as simple as find results. But how to convert result as list of the elements into number?
It is simple. JavaScript function to convert list of elements into number is:

arg.size()

Here are couple of examples of metric logic specification using structured expression dialog and converting result into number (size). For “How To” check video and download sample project file at the end of this post.

Figure 1. Converting Metachain Navigation query results into number.

Figure 1. Converting Metachain Navigation query results into number.

Figure 2. Calculating percentage requirements covered by satisfy relation.

Figure 2. Calculating percentage requirements covered by satisfy relation.

Resulting metrics look like this:

Figure 3. Metric results.

Figure 3. Metric results.

 

Metric specification:

Figure 4. Metric Specification.

Figure 4. Metric Specification.

Model under analysis:

Figure 5. Model under analysis.

Figure 5. Model under analysis.

Derived Properties

Same method can be used for derived properties also to convert from list of results into number.

Figure 6. Number of Satisfy relations requirement has.

Figure 6. Number of Satisfy relations requirement has.

Download sample project file to find described metric and derived property cases.

Video covering steps how to create derived property, metric, and convert to number:

Nov 012016
 
patternsThe rollup calculations are among the most common use cases in systems engineering. System modelers want to calculate total mass, cost, power, or another system dimension, based on individual values of all the parts in the model. During this webinar, you will learn how to perform different kind of rollup calculations in the MagicDraw model with Cameo Simulation Toolkit.

The session demonstrates

  • Introduction to rollup analysis and rollup patterns
  • Static rollup patterns
  • Rollup patterns with different number of instances of parts
  • Dynamic power rollup pattern
  • Execution of scenario using rollup patterns

Recording

Slides

Download (PDF, Unknown)

The session is hosted by Zilvinas Strolia, Solution Architect at No Magic Europe

Learn more at: http://www.nomagic.com/mbse/

Oct 312016
 

It is quite often we are asked about connection between DoDAF and SysML. They coexist together very well! Both are OMG standards (same comon metamodel behind), so everything is fully reusable and traceable.

Positioning and connection points

DoDAF framework provide tools to describe the enterprise architecture – starting from capabilities, going to operational level and then to the system definition. However, it do not concentrate on system design. DoDAF leads to identification what new systems (which does not exist) shall be designed, or which existing systems shall be improved. For this MBSE methodology is used.

Transition and trace from DoDAF to SysML project(s) (possibly multiple ones) for the systems design

  1. From DoDAF Capability element SysML Requirements can be derived. Capability is what shall be delivered by system, so system requirement shall derive (Abstraction relation) from capability.
  2. DoDAF Operational diagram is highest level behavioral diagram which operational activities will be decomposed during system engineering functional analysis into new SysML Activities.
  3. DoDAF System and other Resources trace to the SysML Block. This is Abstraction (or Generalization) relation which shall be used between DoDAF System and SysML Block.
system-to-logical-2

1. DoDAF Systems Viewpoint. Trace to SysML Logical Model

DoDAF Systems Viewpoint to SysML Logical Model

2. SysML Logical Model. Trace to DoDAF Systems Viewpoint.

capability-to-requirement

3. SysML Text-based Requirements. Mapping to DoDAF Capability Viewpoint.

Jun 222016
 
A modeling culture is the combination of modeling, model usage and model governance that together provide a productive way for applying model-driven development in the context of a particular organization. When we talk about model usage, we talk about impact analysis, coverage analysis, trade studies, behavioral simulations, testing, code generation, etc. Any example of model usage is barely possible without performing visual model analysis.
The session demonstrates
  • Coverage analysis using dependency matrices
  • Impact analysis using dynamic relation maps
  • Model queries
  • Generic tables
  • Model metrics
  • Suspect links

Video

Slides

Download (PDF, Unknown)

The session is hosted by Dr. Aurelijus Morkevicius, Head of Solutions Department at No Magic Europe

Learn more at: http://www.nomagic.com/mbse/

Mar 242016
 

TMTThe Thirty Meter Telescope (TMT) system is currently being developed by the TMT Observatory Corporation. The main objective for the TMT related analysis is to provide state-dependent power roll-ups for different operational scenarios and demonstrate that requirements are satisfied by the design as well as mass roll-ups and duration analysis of the operational use cases.

The core of the system is a wide-field, altitude-azimuth Ritchey-Chretien telescope with a 492 segment, 30 meter diameter primary mirror, a fully active secondary mirror and an articulated tertiary mirror. The Alignment and Phasing System is a Shack-Hartmann (SH) wavefront sensor responsible for the overall pre-adaptive optics wavefront quality of the TMT.

The model is built with an approach to model-based systems analysis with SysML that is both rigorous and automated. The approach supports the kind of system analysis we mentioned earlier, i.e., requirements verification. The approach’s rigor is established with a modeling method that is an extension of INCOSE’s Object Oriented Systems Engineering Method (OOSEM). The extension, dubbed Executable System Engineering Method (ESEM), proposes a set of analysis design patterns that are specified with various SysML structural, behavioral and parametric diagrams. The purpose of the patterns spans the formalization of requirements, traceability between requirements and design artifacts, expression of complex parametric equations, and specification of operational scenarios for testing requirements including design configurations and scenario drivers. Furthermore, the approach is automated in the sense that the analysis models can be executed. The execution of the parametric diagrams is done with a parametric solver, where the execution of the behavioral diagrams is done with a simulation engine based on standard execution semantics.

An overview of system level simulation in general and the purpose of this model in particular you can find in this video:

Source of information including SysML model file and copyright is available at: https://github.com/Open-MBEE/TMT-SysML-Model

More about TMT can be found at: http://www.tmt.org/

 

Mar 112016
 

drivelineThis paper documents the real-world application of model-based systems engineering (MBSE) methodology and principles to an automotive driveline system. A system model developed in the course of this thesis supports the definition and sizing of the driveline system to best communicate and deliver functional specifications tied to customer requirements. Furthermore, this system model documents, organizes, manages and provides traceability for all customer, system, sub-system and component level requirements and is a useful tool supporting the system architecting and specification cascade process.

Team investigated and analyzed existing driveline component sizing tools and developed an exhaustive list of key assumptions and system design requirements which have been linked through a comprehensive SysML model. The key project deliverables are the SysML system model and a list of lessons learned / best practices collected during the development process.

The project was selected based on identified needs in the Ford Transmission and Driveline Engineering product development process.

Thesis based Proof of Concept was successfully completed with verified results recognized by academia and the industry.

Presentation

Download (PDF, Unknown)

Thesis

Download (PDF, Unknown)

Major benefits of applied MBSE:

  • A significant tool for automotive system design that offers many benefits, especially in communication through a common language
  • Requirement traceability is vastly improved
  • Faster delivery time along with more robust results and less cost

Authors indicate:

“Based on the success of a limited model, MBSE will be a significant tool for future automotive system designs. The state of SysML and MBSE appears to be similar to the implementation of CAD applications in the 1980’s, or CAE in the 1990’s. The MBSE market is slowly developing and SysML is beginning to penetrate industry through early adopters. Effectively, MBSE is an emerging market that is likely to grow in the future as its potential benefits are recognized by engineers.

Companies have not yet identified the benefits of model based system engineering, but when they do, the market will explode. Companies are likely to pursue enterprise implementations to reap the benefits in communication and requirement management across their organizations. At Ford, it is likely that SysML or something similar will be integrated into the existing Teamcenter CAD/CAE tools. If history is any guide, early adopters are likely to absorb the costs, but also guide the future development of this new technology.”

Thesis recognition by academia

President and Founder of Sigma Theta Mu, the honour society for systems and system engineering, personally inducted the first three student members ever into their society.  The team that did the transmission thesis was selected by the department head for this honour.  UDM’s chapter was chartered two weeks ago (with Stevens and Old Dominion). ”It was a real honour for me to be able to recognize Bob, Arun, and George for their work.  They are now STM members #7, #8, and #9” said Michael J. Vinarcik a Senior Lead Systems Engineer at Booz Allen Hamilton, adjunct professor at the University of Detroit Mercy, and advisors for thesis. He hopes that in a few years that number will be inducted many times over.

He indicates: “It’s been an interesting road since the first time Ms. Joyce Duncanson issued me a MagicDraw license for teaching…when I graduated from the MPD program myself in 2004 I had no way of knowing that one day I’d be teaching in it.  Yet here I am, signing a thesis as an advisor.  The No Magic team has been with me every step of the way (at least in recent years)… You have built a race car, and it makes me sad to see so many people driving it like a Yugo.  I may always be more Paul Newman than Mario Andretti, but I will promise you that I will continue to push every day to understand the tool better so that I can demonstrate its value to my clients and colleagues.”

No Magic, Inc. expresses sincere thanks and appreciation to Mike’s work. His work has driven bold innovation and brought value to numerous projects.