The Systems Modeling Language (SysML) is a standard, general-purpose, modeling language for model-based systems engineering (MBSE). SysML supports the specification, analysis, and design of a broad range of complex systems such as control systems. The authors demonstrate how they can integrate a SysML modeling tool (IBM Rational Rhapsody) with a proprietary simulation tool (MathWorks Simulink) and a Computer Algebra System (CAS) to validate system specification. The integration with Simulink enables users to perform systems engineering process in a SysML model, while designing continuous control algorithms and plant behavior in Simulink, and to validate the behavior by simulating the overall composition in Simulink. The integration with a CAS enables the evaluation of mathematical constraints defined in SysML parametric diagrams. The authors also show the overall approach using a Dual Clutch Transmission (DCT) and a Cruise Control System as examples.
The Systems Modeling Language (SysML) has been under development since 2001 [
SysML extends a subset of the Unified Modeling Language (UML) [
SysML supports the specification, analysis, design, and verification of a broad range of complex systems such as control systems. Part of the control systems specification includes dynamic (time-dependent) continuous behavior of the control algorithms and the physical environment; these systems interact with the plant. In addition, SysML introduces a new kind of diagram called a parametric diagram used to define mathematical relations among attributes of the system using equations and inequalities. It is possible to define dynamic behavior of the system using time derivative function [
One of the most effective methods of verifying a system is simulation. To simulate a system that consists of hardware and software, we have to define both discrete-time behavior and continuous-time behavior. To simulate a combination of discrete-time and continuous-time elements, we have to use a simulation tool such as Simulink or Modelica [
SysML also supports engineering analysis using parametric diagrams [
In this paper, first we describe our tool that integrates a SysML modeling tool (IBM Rational Rhapsody) with a simulation tool (MathWorks Simulink). Second we explain our tool that evaluates constraints defined in parametric diagrams. Then we show systems engineering processes for designing a Dual Clutch Transmission (DCT) [
Rhapsody is a UML/SysML modeling tool that has many capabilities including model execution of SysML models. Before developing our new tool, Rhapsody already had two integration points with Simulink.
The first integration point is importing Simulink components into Rhapsody (Figure
Importing a Simulink component.
The second integration point is creating an S-function using Rhapsody (Figure
Generating an S-Function.
We developed our new integration tool to address the above problems (Figure
New integration.
This new integration tool solves the problems described in Section
Our tool can also help engineers to find a set of appropriate values of system parameters by running multiple simulations automatically. Simulink users often use MATLAB variables in Simulink models to represent system parameters. We enhanced our integration tool to maintain system parameters in SysML and synchronize them with MATLAB variables in Simulink model. Users can modify system parameters’ value and simulate the generated Simulink models using the modified values.
Defining behaviors using SysML diagrams is optional. Users can define all behaviors using Simulink if they want. In that case, no S-function is generated. Although Simulink is a good tool to simulate dynamic systems, it does not have a capability to support systems engineering processes. Users can use Rhapsody as a systems’ engineering process support tool for Simulink.
This new integration tool is shipped as a component of Rhapsody, so several researchers use this tool. Wang and Baras use this tool for designing wireless sensor networks [
We explain the mechanism of our new integration tool in this section. Figure
Block definition diagram of a cruise control system.
Figure
Internal block diagram of CruiseControlSystem block.
Our tool generates an S-Function block SFunctionBlockCruiseControlSystem from CruiseControlSystem block (Figure Remove parts pf and vd, because they refer to Simulink submodels. Add flow ports pf_desiredSpeed and vd_actualSpeed. Add lines between pf_desiredSpeed and desiredSpeed, and between vd_actualSpeed and actualSpeed. Apply ≪S-FunctionBlock≫ stereotype to the generated block.
Internal block diagram of generated S-Function block.
Rhapsody has a capability to generate an S-function from an S-Function block as described in Section
Then our tool generates a Simulink model (Figure
Generated Simulink model.
We developed a tool to evaluate parametric diagrams, Parametric Constraint Evaluator (PCE). This section briefly explains PCE. The details of PCE can be found in [
The main SysML model elements used for parametric analysis are constraint blocks, constraint properties, constraint parameters, and binding connectors. Constraint blocks specify a set of equations and inequalities. The parameters used by the expressions of the constraints are explicitly specified as constraint parameters owned by the constraint block. The constraint parameters are a specialized type of UML/SysML property and as such they have names, types, and multiplicities. A constraint property is an instantiation or usage of a constraint block in a specific context, allowing the same constraint block, defining a set of equations, to be used in different contexts with different values. Constraint properties are connected via the constraint parameters by binding connectors, either to other constraint properties via constraint parameters or to other UML/SysML property uses in the design model. A binding connector between properties means that the values of the properties at each end of the connector are equal.
The language for specifying the constraints expression is not defined by SysML, so tool venders have to define the language. PCE calls CAS to evaluate constraints. PCE supports two kinds of CAS, Maxima and MATLAB Symbolic Math Toolbox. Each CAS uses its own language. We chose a subset of the Modelica language [
PCE is shipped as a component of Rhapsody. Bleakley, Whitfield, and Lapping propose to use this tool to perform trade study [
We developed a model of a Dual Clutch Transmission (DCT) using Rhapsody, calculated a system parameter by evaluating a parametric diagram, and validated the model by simulating it using Simulink. A DCT is a kind of automotive transmission and a recent trend of the powertrain control. A DCT has two independent subgearboxes each connected to the engine via its own clutch. One subgearbox contains the odd gears (1, 3, 5…) and the other the even gears (2, 4, 6…). By dividing the gears through the dual clutch, the DCT becomes fully power shiftable [
We chose a DCT as an example since we have to consider (1) whole automotive system, (2) both hardware and software, and (3) many requirements to differentiate the performance in both the functional aspects and the nonfunctional aspects.
We performed the following steps to design the DCT: requirement analysis, system components definition, simulation context definition, parametrics definition, parametrics evaluation, plant behavior definition, controller behavior definition, connection definition, test cases definition, simulation.
First, we sorted out requirements from upper-level systems or concepts by describing them in a requirement diagram (Figure
Upper level requirements.
Next, we derived functional requirements in a requirement diagram (Figure
Functional requirements.
We expanded the target system into components in a Block Definition Diagram (BDD) (Figure
System components.
We assigned functional requirements defined in the previous subsection to subsystem components in a requirement diagram (Figure
Assign functional requirements to subsystem components.
Based on the subsystem components and their assigned requirements, we described the specific subsystem elements of blocks consisting of the DCT. The configuration of the mechanical parts would be restricted by functional requirements. Some parts may be defined by a specific vendor’s product that has a fixed specification. Other parts may be described by the performance characteristics by mathematical equations in parametric diagrams.
We defined a context for simulation using a BDD (Figure
Simulation context.
We defined relations among attributes using a parametric diagram (Figure
Parametric diagram to define relationships between attributes.
We can evaluate the parametric diagram using Rhapsody Parametric Constraint Evaluator (PCE) [
Constraint view window for evaluating the parametric diagram.
The values of the driver mass, the engine mass, and the body mass are known. When we click the “Evaluate” button, PCE calculates the value of total mass. We can synchronize the attribute values on this window with the SysML model by clicking the “Update Model” button.
We defined behaviors of plant models using Simulink submodels and referred the Simulink submodels from a SysML model.
SysML’s flow ports specify the input and output items that may flow between a block and its environment. Simulink has also concept of ports—Inport and Outport blocks. We have to synchronize interfaces between a SysML block applied ≪SimulinkBlock≫ stereotype and a Simulink submodel referred from the SysML block.
There are two ways to synchronize them. If users want to use an existing Simulink model, our tool generates flow ports and attributes to a SysML model from the existing Simulink model. If users want to create a new Simulink model, our tool generates a template Simulink model that contains Inport blocks, Outport blocks, and MATLAB variables from a SysML model. They can define the behavior of the plant by modifying the generated template Simulink model. Values calculated by PCE are also synchronized with MATLAB variables used in Simulink models.
After describing the blocks related with an environment under the given functional requirements, we considered a control strategy whose behavior would also be described in the ShiftController block as a state machine diagram (Figure
Part of Controller software behavior.
A shift controller receives inputs from various sensors like the throttle position, current vehicle speed, current gear position, and engine speed. Based on these inputs and a command from a driver, the controller makes a decision of an upshift, downshift, or gear position holding. The threshold of each transition is adjusted to make the engine speed stable by trial and error method.
States shown in Figure Neutral: no gear is engaged. FirstGear_SecondGear: the first gear is engaged and the second gear is prepared. SecondGear_FirstGear: the second gear is engaged and the first gear is prepared. SecondGear_ThirdGear: the second gear is engaged and the third gear is prepared. GenerateWarning_1, GenerateWarning_2: an incorrect command is received.
Events shown in Figure chUpcommand: upshift request, chDowncommand: downshift request, tm(100): wait 100 milliseconds.
The following attributes are defined in ShiftController block: odd1, odd2, odd3: flags to represent the first, third, and fifth gear are selected or not; even1, even2, even3: flags to represent the second, fourth, and sixth gear are selected or not; odd: flag to represent the odd subgearbox is engaged or not; even: flag to represent the even subgearbox is engaged or not.
Each attribute has a set method such as setEven.
The initial state is Neutral, and the first and second gears are selected by setEven1(1) and setOdd1(1). When the controller receives chUpcommand, the odd subgearbox is engaged by setOdd(1).
We defined connections among models in the simulation context using an Internal Block Diagram (IBD) (Figure
Internal structure of the simulation context.
First, we define verification items using a requirement diagram (Figure
Verification items.
Then, we defined test cases using state machine diagrams of TestDriver block for verification items. Figure
Test case.
Requirement ID SR13 specifies “When the DCT is in error condition, the gear keeps the current position even if it receives shift operation.” To verify the SR13, we defined Requirement ID AN2 “Verify the case of gear selection when error occurs in shift operation.” It means shift command is ignored because the target gear is not prepared. Figure
After waiting 1000 milliseconds, the state is changed to FirstGear, and upcommand attribute is changed. The value change of upcommand is propagated to shiftController’s upcommand because upcommand flow port of testDriver is connected to upcommand flow port of shiftController (Figure
After waiting 4000 milliseconds, the state is changed to SecondGear, and upcommand attribute is changed.
After waiting 1000 milliseconds, the state is changed to ThirdGear, and upcommand attribute is changed.
First, we generated a Simulink model from the simulation context block (Figure
Generated Simulink model.
Then we performed simulation using Simulink. We could see the simulation result using Simulink’s capability such as a Scope block (Figure
Simulation result.
As defined in Figure
We could see the generated S-Function’s execution using Rhapsody’s animation capability (Figure
Animation of an S-Fucntion’s behavior.
We could also see the interactions during the simulation using generated sequence diagrams (Figures
Part of generated sequence diagram.
Another part of generated sequence diagram.
We could find the GenerateWarning_1 state in ShiftController block. So Requirement ID AN2 was verified.
Lussier explained the first integration point of Rhapsody and Simulink described in Section
A cruise control system is a system to maintain vehicle speed smoothly. It observes the actual speed, reasons the desired speed, and transmits the desired speed to the physical system at the driver’s command.
A driver can maintain speed and set speed (Figure
Use case diagram.
Figure
PFeedback block refers to a Simulink model. It is a PI controller to use to vary the thrust applied to accelerate the vehicle based on the delta between the actual speed and the desired speed. VehicleDynamics block also refers to a Simulink model. It calculates from thrust to actual speed. Controller block is responsible for implementing the cruise control function. Speedometer is a sensor.
Figure reqCruise: a request to start/stop cruise mode reqSet: a request to set the current actual speed as the desired speed reqAccelerate: a request to increase the desired speed reqDecelerate: a request to decrease the desired speed reqBrake: a request to brake reqResume: a request to set the desired speed to the previous value.
A state machine diagram of Controller block.
It is possible to define test cases using SysML diagrams (Figure
A panel diagram.
Figure
Animation of a state machine diagram of Controller block and a panel diagram.
In this paper, we described our tools to integrate SysML with Simulink and to evaluate parametric diagrams. Next we showed systems engineering processes for designing a DCT using our tools. Users can design a control system using SysML and perform systems engineering processes such as requirement analysis on Rhapsody. They can evaluate relationship among system parameters by using PCE. They can define controller’s behavior using SysML state machine diagrams and define plant’s behavior using Simulink. They can generate a Simulink model from a SysML model, so they can simulate the model using Simulink. In addition, users can calculate system parameters by evaluating parametric diagrams and use the calculated parameter values in Simulink models. Finally we showed how to interact with users while simulating using a panel diagram.
IBM, the IBM logo, ibm.com, Rational, and Rhapsody are trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at “Copyright and trademark information” at