Keywords

1 Introduction

A complex product development involves design and selection of several components that make up the product. It also involves several domain experts who use their domain specific tools to perform various analyses. Several combinations of the components are available to assemble the product. Individual component choices cannot be made in isolation but traditionally the criteria for selection of components are based on evaluation in independent domain specific tools. Evaluation of such attributes employs different methods and requires different details about the component and the parent product or system. Models are often created in different tools to evaluate specific attributes. However, such an approach may be susceptible to errors due to inconsistencies in the models and different assumptions used for different evaluations. Moreover, additional steps are needed to further collate the results from different models in order to perform the trade-off analysis and choose the right combination of components.

Poor decisions during early phase of design lead to extended project schedule and add cost to the project as changes are difficult to make later in the product development cycle. Design catalogues for material selection and standard parts such as bearings, o-rings, etc. are used by designers. Exploring the design space having several options of components and evaluating their combinations against system attributes helps mitigate the risks of schedule delays and added cost. Commercially available options, such as iSIGHTTM [1] and modeFrontier® [2], are popularly used as multi-objective and multi-disciplinary optimization software which integrate with third party design tools to explore the design space. However this approach requires configurations to be setup as well as has the need to have a specialized tool to enable this analysis. Researchers at MIT developed a framework for tradespace exploration called MATE (Multi-Attribute Tradespace Exploration) [3] towards the development of space systems which does not recommend any specific software tools or formula. Using Systems Modeling Language (SysML) and General Algebraic Modeling System (GAMS) [4] component sizing problem is researched to evaluate multiple scenarios for a given configuration. This method requires model transformation and specialized GAMS stereotyped blocks in SysML.

Due to increasing complexity of products the design task of selecting components or sub-systems, is becoming more and more a decision that needs to be taken keeping system level performance/attributes in focus, rather than component specifications. Model Based Systems Engineering (MBSE) provides a formal framework to model the complexity in the system in terms of requirements, structure, and behavior, including parametric inter-dependencies. MBSE is an evolving approach that lets you consider system level attributes. In this paper a framework for component selection is presented to perform multi-attribute evaluations using SysML applying MBSE approach. SysML is used to create a master model of the products and their components which includes information such as system requirements, system structure and behaviour. A mathematical solver and parametric models defined in domain specific tools are internally used to perform specific attribute calculations, while providing the input information from the master model. This ensures that the input information used is consistent across the evaluations.

2 Master Model Development Using SysML

SysML is a general purpose graphical modeling language with a semantic foundation for system requirements, behaviour, structure and parametrics and can be further integrated with other engineering analysis models. It is a subset of UML 2 with extensions and leverages the OMG XML Metadata Interchange (XMI®) to exchange modeling data between tools, and is intended to be compatible with the evolving ISO 10303-233 systems engineering data interchange standard.

SysML supports the specification, analysis, design, verification and validation of a broad range of complex systems via various diagram types as seen in Fig. 1. SysML’s graphical constructs enable defining hierarchy, internal connections of a system and constraints on system properties, system behaviour such as functionality, data/control flow sequence, state transitions and activity and the system requirements.

Fig. 1
figure 1

SysML diagram taxonomy [5]

The system hierarchy and information on system architecture, at a logical or physical level, can be represented using the SysML block definition diagram (BDD). The BDD also has the capability to describe quantitative values and relationship within or between systems and sub-systems. Connectors are used to define the relationships where every connector has a specific meaning.

A vehicle wiper system is used as a case study for the purpose of this paper. A BDD is used to represent the context of wiper system. The context describes the entities that interact with or influence the system operation and in this case consists of the wiper system itself along with the user who will operate the wiper, the windshield over which the wiper will operate and the external conditions under which the wiper will be operated as shown in Fig. 2. The connector used between the block “Wiper_System” and the block “Wiper” states that there exists a ‘part-of’ relationship between the two blocks. The connector used between the block “ExternalConditions” and the blocks “Rain”, “Dust” and “Snow” states that there exists a ‘type-of’ relationship between them. Other considerations in a context such as government regulations, customer, etc. are kept out of scope in this study. Properties of entities in the context form essential inputs to physics modeling and analysis of the system.

Fig. 2
figure 2

Wiper system context using SysML block definition diagram

Figure 3 describes the hierarchy in wiper system for the given context. The components are defined as blocks thus the wiper system under study consists of two main sub-assemblies, the motor assembly and the linkage assembly.

Fig. 3
figure 3

Hierarchy of components in wiper system using SysML block definition diagram

In SysML using ‘type-of’ relationship possible variants of a block can be defined. In this case, three options of motor are being considered and are represented with the ‘type-of’ relationship as shown in Fig. 4. Similarly there can be variants described for controller and sensor as well as for various parts in the linkage assembly.

Fig. 4
figure 4

Showing variants of motors in motor assembly

Each block in the wiper system hierarchy has parameters also known as value properties that define the characteristics of the block. For example, each block has a characteristic Price to specify the price of the component. Other characteristics such as Voltage and Current rating of the motor block, initial_position and max_position of linkage assembly, etc. are defined along with their respective units. Mathematical constraint equations are defined to evaluate system attributes of interest. In this case study there is an interest to understand multiple attributes, such as overall price and performance of the wiper system, for every combination of the components. Number of cycles completed by the wiper in given unit time and the power consumed by the operation in that given time, under different “ExternalConditions”, are the performance attributes of interest. The relationship between the parameter Price of the motor assembly and the parameters Price of the assembly components are captured using a parametric diagram as shown in Fig. 5.

Fig. 5
figure 5

Parametric diagram relating price of components in wiper motor assembly

SysML is a graphical representation language and the diagrams created as described in the previous sections form a generic definition of the system. One or many instances can be created with specific information of the system and its assembly elements. To enable evaluation of parameters for specific instances it requires a mathematical solver.

SysML models created in MagicDraw and SysML plugin, use solvers such as MATLAB/OpenModelica, and a plugin to interface between the two. Some attributes need domain specific models for evaluation. SysML can be used as a master model to provide that input information. The plugin converts the SysML model to a format readable by the solver. In this case a Simulink® model is needed to estimate the power consumption for a wiper cycle. We create a parameter and a parametric diagram that specifies that relation between the PowerConsumption parameter, parameters of components.

The behaviour model of wiper system is created in Simulink® and thereby performance attributes of interest are evaluated by leveraging the existing behaviour model. A specialized syntax [6] is used to provide inputs from SysML environment to MATLAB® solver and get the output values after solving. The cost is a simpler constraint equation summing up the cost of various components in each sub-assembly and is evaluated using the default solver which is OpenModelica.

3 Results and Conclusion

Figure 6 shows a format of the output screen. As seen in the screenshot, there are three target values, of which Price is an output from OpenModelica and NoOfCycles and PowerConsumption are outputs from Simulink®. Table 1 and Fig. 7 summarize the results and demonstrate the component options in the design space. The results suggest that if Motor 1 is employed then the total Price of the wiper system will be INR 17,340 with PowerConsumption of 384 Watts and 4, 2 and 1 NoOfCycles under the “ExternalConditions” of “Rain”, “Dust” and “Snow” respectively. As per the results Motor 1 option is the most expensive option however a designer can refer wiper system requirements to make a decision if the results from performance analysis are more important than the Price and accordingly choose the Motor. The SysML model developed is a formal representation of the system.

Fig. 6
figure 6

Paramagic® solver user interface

Table 1 Results of multi-attribute analysis
Fig. 7
figure 7

Results of multi-attribute analysis, performance versus price of the system

4 Future Perspective

MBSE application and SysML as its enabler helps develop a master model that documents requirements, architecture, behaviour and design decisions, and will allow common, consistent and complete analysis of a system. In the same model system level attributes to further characterize the elements as well as those originating from the system context can be added. This approach is quick and allows trade studies in initial stage of design to study families of design alternatives and make valid design choices. SysML allows systems thinking by enabling efficient communication of concepts and description of different aspects of system of interest and their inter-relationships. Co-analysis with solvers and simulation tools helps evaluation of system level properties and emergent behaviours. This approach allows help with documentation and reuse of the documentation for future analysis.