Skip to main content

Introduction

In addition to the features shown in the two previous parts of this blog series, Model-Based Engineering (MBE) must meet two more requirements:

  1. Architecture modeling must capture the interconnections between system parts, and
  2. Architecture modeling must support simulation with the appropriate software tools.

In the third part of this series, we will look at how these might be implemented in our washing machine model.

The Washing Machine – Internal Connections

Our washing machine has multiple sets of critical connections: fluid, electrical and mechanical. In SysML, these connections can be represented in Internal Block Diagrams, which show how the parts of the system are connected.

Figure 1 SysML Internal Block Diagram, power connections

Figure 1 shows the main power connections in our simplified washing machine model. The main power input into the system is shown on the lower left, entering the Circuit Breaker subsystem, which redistributes it to Control_Power and Motor_Power outputs and ultimately to the components that require power, such as the tub agitator and spin motors.

Figure 2 SysML Internal Block Diagram, water connections

Figure 2 shows a combination of fluid flows and the electrical signals that monitor and control them. The characteristics of these flows are captured by the port types that are connected.  For example, the ports typed by Water_Flow are characterized by three parameters: flow rate (GPM, gallons-per-minute), temperature (°F) and pressure (psi).

Note that while the system parts have been somewhat arbitrarily categorized into mechanical, hydraulic and electrical subsystems, the connections in these diagrams can cross between subsystems.

Connections to Simulation

While SysML has some capability for quantitative analysis through parametrics, complex simulations will continue to be performed with software tools designed for the purpose, such as Simulink or Modelica. The challenge is maintaining consistency between the modeling and simulation tools as the system evolves.

Syndeia addresses this challenge, providing the ability to generate, compare and synchronize such models across tool boundaries. In this example, Syndeia has taken the multilevel connectivity information represented in the SysML diagrams in Figures 1 and 2 and used them to generate equivalent models in Simulink (The MathWorks, Inc.).

Figure 3 Simulink top-level structure, Washing Machine system

Figure 4 Simulink structure, Electrical Subsystem

Figure 3  shows the top-level Simulink structure, the three main subsystems with the connections between them. Figure 4 shows the internal structure of one of those subsystems. What is carried over from SysML to Simulink are blocks, connectors and ports. The resulting Simulink model is a starting point for the Simulink specialist to build MATLAB code into the blocks that result in an executable model. Because Syndeia maintains a set of persistent connections between the models, changes to the block/connector/port structure on either side can be identified and updated (bidirectionally) as system development proceeds.

Next Steps

In the first three parts of this series, we created connections between SysML, PLM, requirements and simulation models. The resulting network becomes an important asset in its own right, representing a high-level map of system data that can support traceability and navigation across the Total System Model (TSM). In Parts 4 and 5, we will look at visualizing and querying the TSM with Syndeia.

Related posts:

Related Posts

Pipelines Part 3 – Matching Requirements to Parts using Syndeia Digital Pipelines

We’re continuing our blog series on using Syndeia digital pipelines to execute real world use cases in systems engineering. In Part 2, we demonstrated a digital pipeline that ...
Dirk Zwemer and Gregory Seeds

Pipelines Part 2 – Gap Analysis between Requirements and Tests

Demonstrating measurable ROI from digital engineering is just as important in driving enterprise adoption as customer mandates, e.g. DoDI 5000.97. In particular, the concept of ...
Dirk Zwemer and Gregory Seeds

Pipelines Part 1: Quick Introduction and Demo

Syndeia Pipelines automate digital engineering workflows by orchestrating complex, multi-step tasks, such as ETL operations, cross-repository queries, model transformations/syncs, ...
Manas Bajaj

Christmas at the North Pole, Powered by Pipelines🎄

While the rest of the world is busy hanging lights, doing last minute gift shopping, and sipping cocoa, the North Pole is deep in digital engineering mode. Snow is falling, elves ...
Manas Bajaj

What’s New in Syndeia 3.7? - Part 1

We are excited to release Syndeia 3.7, the next generation of our digital thread platform for integrated digital engineering. Check out the latest features in less than 5 minutes ...
Dirk Zwemer

Model-Based Systems Engineering for Autonomous Vehicles, Part 16 – Custom Dashboards

In Parts 1-10 of this blog series, we built a digital thread for an autonomous vehicle system to demonstrate how a federation of models in different software tools can become a ...
Dirk Zwemer

Model-Based Systems Engineering for Autonomous Vehicles, Part 15 – Digital Pipelines

In Part 14 of this series, we developed a custom script to calculate project metrics for our Autonomous Vehicle digital thread project. The value of this information is greatest ...
Dirk Zwemer

Model-Based Systems Engineering for Autonomous Vehicles, Part 14 – Open REST API

Syndeia has been developed as an API-first enterprise application, i.e. the full capabilities of the software are exposed through an open REST API with the understanding that the ...
Dirk Zwemer

Model-Based Systems Engineering for Autonomous Vehicles, Part 13 – Digital Reports

A key function of Digital Threads is to be able to answer questions about project status in real-time without the overhead of data collection, status reports and meetings. In this ...
Dirk Zwemer