Keywords

1 Introduction

Product Lifecycle Management (PLM) has become a central management approach for managing product information, engineering processes and applications along the different phases of the product lifecycle [1]. Around 70% of costs for the market launch of new products are defined in the very early phases of the product lifecycle; i.e. product specification and development [2]. The engineering design departments of manufacturing companies are hence under increasing pressure to perform better in terms of low-time, high-quality and high value output that can provide competitive advantage for the organization [3]. Design Automation (DA) has already been identified as a key enabler for addressing these challenges [4] and is defined as the automatic running of a task or a sequence of tasks performed in an engineering design process [5] and can be divided into two types: information handling (acquisition, retrieval, and analysis) and knowledge processing [6]. That is why, on one hand, DA should be considered as a key enabler of a PLM approach increasing design process efficiency and supporting different types of concurrent engineering and Design-for-X approaches (anticipating and integrating downstream activities’ constraints as early as possible in the product development phase). On the other hand, the acquisition, formalization and re-use of the engineering knowledge consumed or generated by DA applications strongly rely on the capabilities and the usage of PLM enabling technologies (CAX and IT systems as well as their interfaces). Therefore, companies developing mechanical products, have to consider the advantages of Engineering DA (EDA), its realization, implementation as well as its applicability and integration in their specific business environment. However, there is a discrepancy between availability of DA methods stemming from academia and their industrial application [7]. Reasons for that are uncertainties with respect to awareness of available opportunities, recognition of potential of applying DA and ability to define the automation task [7]. In order to overcome above mentioned shortcomings and pave the way for more systematic implementation of DA, this paper introduces a methodological and modeling framework supporting the identification of DA potential within the product development lifecycle and the specification of the required DA task building blocks to clearly define the context of a design task and thereby support DA task formalization by practitioners. The framework combines the usage of two standardized and neutral modeling languages to make the captured knowledge computational and platform independent and to enable the re-use of this knowledge across heterogeneous PLM and DA systems. Section 2 evaluates the current state of the art with respect to enterprise architecture (EA) modeling methods and approaches supporting the specification and development of PLM approaches as well as with respect to system engineering (SE) approaches and computational design task definition. Section 3 introduces the proposals for an EA and Model-Based System Engineering (MBSE) methodological framework including a DA task formalization methodology. Section 4 illustrates the application of the methodology on an industrial case study: the formalization of an optimization task for dimensioning box-type booms of maritime cranes designed and manufactured by Liebherr Werk Nenzing GmbH (LWN). Finally, the results and limitations of the proposed framework and methodology are discussed in Sect. 5 before concluding the paper and presenting lines of future work.

2 Background

DA, as part of a PLM strategy, is not only a technical solution for automating design tasks but also a strategic answer that has to consider many aspects of the company such as: the strategic business drivers, the specific business processes and related requirements; the different authoring and IT applications or platforms used for implementing and/or integrating DA methods; the interfaces between interdependent business processes, authoring applications and IT systems enabling all these elements to interoperate together; the IT infrastructures hosting and enabling these applications to be efficiently integrated and used within and outside the company; the complexity of the system to be designed, the formalization of the related engineering knowledge required for performing design tasks and finally the human factor, i.e. the user interaction, usability and user acceptance with respect to DA systems. One way to address and apprehend the complexity of such business digital environments is to use EA considering the different dimensions and elements listed above [8,9,10]. The second way is to evaluate methods and approaches for computational design task definition in order to enable practitioners to specify the required DA task building blocks.

2.1 EA Frameworks, SE Standards and PLM Applications

According to [9], “achieving alignment between business, application, information and technologies (IT) requires an integrated approach to all aspects of the enterprise” and EA is an important instrument to address this company-wide integration. Further, it provides “a coherent whole of principles, methods and models that are used in the design and realization of the enterprise’s organizational structure, business processes, information systems, and infrastructure” [11]. However, as highlighted in [9], these domains are generally not approached in an integrated way; each domain speaks its own language, draws its own models, and uses its own techniques and tools. Therefore, it is important that the EA can be represented with relevant information and at the appropriate level of detail for all involved stakeholders [10]. For this purpose, several EA approaches, frameworks and methods have emerged since the 90’s whether from the literature (e.g. Zachman, CIMOSA) or from standardization initiatives (e.g. IEEE-1471, ISO/IEC/IEEE-42010, TOGAF). In literature, it is possible to distinguish between simple methods of representation (e.g. SADT, IDEFx) and reference architectures (e.g. CIMOSA, Zachmann, TOGAF). As highlighted in [12], most of these framework approaches aimed at representing business user’s concerns with no direct link to IT implementation. Moreover, these frameworks and methods are generally complex to implement [10]. One reason of these difficulties is due to the existence and cohabitation, according to the viewpoints and domains, of different types of interrelated representations and modeling languages. The co-evolution and hence the consistency maintenance of these interrelated models across time as well as the interoperability between these models and the modeling tools implementing these languages represent major open-issues for efficiently implementing EA. The deployment of a PLM approach can only be achieved through the alignment between business processes, applications, information and technologies and should hence rely on EA modeling and monitoring. Nevertheless, few works can be found in the literature proposing and/or demonstrating the crucial role and contribution of EA for modeling, specifying and monitoring the architecture of the complex system of systems (considering simultaneously the system to be designed, its environment, its interfaces as well as the system for designing; i.e. resources such actors, CAx and IT systems) which is beyond a PLM approach. In [12], it is shown that most of the recent works in EA address the development of frameworks for interoperability, e.g. the IMAGINE and SIP projects. The latter focuses on interoperability through the implementation and evaluation of PLM standards, but also proposes to use EA and ArchiMate to model standards-based business collaboration scenarios and to model the test bed environment that will enable the execution/simulation of this scenario [13]. The SIP project also considers standards and practices of both PLM and SE communities, since PLM and SE are closely related. As stated in [13], although the scope of application of PLM is larger than the one covered by SE and a PLM strategy can be efficiently deployed being SE processes independent. Whereas ISO-15288, EIA-632 and IEEE-1220 are standards for SE process formalization, SysML has been established as a product data exchange standard for requirements and system architecture models. One goal of this work is to study and adapt EA frameworks to specify and model DA business scenarios.

2.2 Computational Design Task Definition

Generally, implementing DA requires a deep insight in the design process to be able to capture and formalize the principles in the design domain. This typically requires a set of building blocks (i.e. components/modules), which can be combined in certain ways to result in the product fulfilling the customer’s requirements. Depending on the purpose of the automation task, the assembling procedure can be fixed yielding exactly one solution, or capable of exploring various assembling strategies resulting in a solution space. In [14, 15], building blocks for definition of conceptual design task are presented. However, the context of a task with regards to design process is not considered. With the intention of providing an easy-to-use categorization of DA tasks, in [4], authors introduce a categorization that puts design tasks that are suitable for automation into context with a generic design process, so to close the gap between product states and formalization. With a focus on reusability of task related knowledge, in [16, 17], authors propose a hierarchical decomposition of a design task to the level of granularity that enables re-use of templates that can be adapted and integrated for the given design task. In [18], authors address the formulation of process templates introducing an ontology-based approach including verification of inputs by means of rules. However, neither the usage of a standardized language that enables reuse of knowledge in a broader context, nor the context with EA is considered within these studies. MBSE “is the formalized application of modeling to support system requirements, design, analysis, verification and validation activities […]” [19]. The SysML language supports such a MBSE approach by providing graphical representations and the semantic foundation for modeling system requirements, behavior, structure, and parametric system representations. With a focus on formalization of simulation-based design tasks, [20, 21] show the applicability of SysML for integrating design and analysis models. However, further analysis is needed to streamline and standardize modeling in SysML for the various design tasks and guide the designers for specifying a design task. In this paper it is proposed to use design task specific modeling templates and SysML stereotypes for modeling task specific knowledge according to given DA task categories.

3 The EA-MBSE Methodological Framework for Design Automation Task Formalization

In this section, a modeling framework and methodology based on the open, independent and standardized ArchiMate architectural framework and language [22], is proposed. ArchiMate divides the EA into a business, applicative and technological layer and is partly based on the IEEE-1471. It permits to describe, analyze and visualize architectures within and across business domains with a restrictive number of artifacts and relationships. The easy-to-use implementation of ArchiMate in the free open source tool Archi®, as well as the possibility to define and re-use pre-defined models templates, were also determining. Further, it is proposed to combine the usage of ArchiMate EA models with SysML models for the definition and implementation of DA task specific building blocks.

3.1 The EA Modeling Framework

The methodology on which the proposed framework has been built is illustrated on the sketch of ArchiMate views of Fig. 1.

Fig. 1.
figure 1

Overview of the methodological modeling EA Framework for integrating DA into a global PLM approach – the blue framed area (steps 2 and 3) matches the focus of the paper. (Color figure online)

Full size image

The first step of the methodology is dedicated to the business process models as well as models supporting the identification of DA potential within these processes. The “business process modeling and analysis” package encompasses a set of business process templates that can be re-used and adapted for modeling industrial business processes and DA business scenarios. The second step of the methodology is the “EDA potential identification” for which the framework provides a taxonomy and a map of DA tasks that have been derived from [4] and positioned according to their domain(s) of application. For each DA task category, the framework also provides a set of DA task templates to be re-used for specifying a DA task within an industrial DA business scenario instantiating and/or combining these templates (third step). Whereas Fig. 2 illustrates the generic design task templates, Fig. 3 illustrates the template of a specific design task category. Another package “Design Knowledge Formalization” comprises a set of meta-models for formalizing the engineering design knowledge required for performing the automated design task, as well as conceptual data models that intend to be implemented into knowledge-based repositories of DA systems. Finally, the instantiated and orchestrated DA task templates should provide all the information for fully specifying the DA solution workflows and architectures in the applicative layer (step 4) as well as the concrete implementation specifications (step 5). The focus of this paper is on steps 2 and 3, i.e. the specification of DA task building blocks through the re-use of identified DA task patterns and related ArchiMate templates.

Fig. 2.
figure 2

Generic DA task definition template - Linking concept for integrating EA models in ArchiMate with product related system models in SysML.

Full size image
Fig. 3.
figure 3

Template for spatial product architecture parameter synthesis task

Full size image

Input and output states as well as corresponding product knowledge are determining criteria for defining a design task. Further, the representations as well as problem solving strategy/reasoning technique, i.e. the reasoning capability, (Fig. 2) are key criteria for specifying the DA solution for a given task. Lastly, in analogy to [23], the goal of a task is investigated in order to account for the requirements, constraints and objectives. For reasons of “genericity” of the approach and for enabling re-use of formalized knowledge, the business and applicative elements of this DA task formalization should remain generic for each task category. In contrary, the reasoning capabilities vary according to the specific DA methods. This is illustrated in Fig. 3 that shows the DA task template defined for the design task category “Spatial Product Architecture Parameter Synthesis”. The possible variations while instantiating such a template are related to the type of solver chosen for automating the task, for instance optimization methods or constraint solvers as well as the related knowledge representations for input and goals.

Further, Fig. 2 introduces the concept for linking the ArchiMate language with the SysML or UML language permitting to establish dependency and traceability relationships between the two. This work focuses on the specification of DA tasks and on modeling the related input and goals with SysML. Block Definition Diagram (BDD), constraint blocks as well as corresponding Parametric Diagrams (PD) are used for modeling the task knowledge, i.e. necessary equations and the corresponding relations to the product and task design parameters, variables and constraints. The following section introduces the generic methodology for formalizing a DA task in SysML and establishing the dependency and traceability relationships between ArchiMate and SysML models.

3.2 MBSE Methodology for Specifying Design Automation Tasks

Figure 4 shows the generic activity diagram relating the actions and inputs that are required for formally defining a DA task as well links to the specific activities that are implemented due to the distinct characteristics of each category. After DA potential has been successfully identified and the corresponding EA models have been defined, the formal definition of a design task is initiated. First, detailed product knowledge is a prerequisite for design task definition in order to be able to comprehensively describe in-/output states, e.g. product architectures, parameters, variables and relations. Next, task specific SysML profiles serve as a means to further guide and support the task modeling. Finally, instantiated EA task templates support the identification of boundary conditions and corresponding formalizations. The action “Define DA Task”, shown in Fig. 4, is modeled using the SysML stereotype “structured action” to indicate the parallel occurrence of the actions “Define Input (Product) Knowledge” and “Define Control Knowledge”. Whereas the first refers to definition of product architectures, parameters and relations, the latter defines the goals and requirements to guide the execution of the design automation task. For representation of both product knowledge and goals, BDDs are used for defining structures whereas PARs are used for definition of corresponding relations.

Fig. 4.
figure 4

SysML DA task formalization activity diagram.

Full size image

After a task has been completely formalized, an appropriate automation mechanism has to be selected and translated from SysML to the corresponding formalization. Consequently, this translation has to be conducted for each DA method specifically.

4 Case Study: Design of Maritime Cranes’ Box-Type Booms

The case study addresses the specification of an optimization task and related solution for the design of a box-type boom crane at Liebherr Werk Nenzing (LWN). Figure 5 provides a 3D illustration of the box-type boom, its components and design parameters. The objective is to minimize the costs of the middle section of the boom with respect to material of stiffeners and sheet metals as well as welding of stiffeners and sheet metals. As shown on Fig. 5, the boom is divided into multiple segments, each of which lies between two bulkheads or a bulkhead and the pivot- or end-section and is split into bottom plate, two (symmetric) side plates as well as a top plate. While the length of the boom, and the number and lengths of segments are given as input parameters, the thickness of each sheet metal as well as the number and type of stiffeners remain variables to be determined for each segment during the optimization procedure. Figure 5 shows the corresponding objective function and the complete formalization of the optimization problem, i.e. all constraints and variables. In order to satisfy the requirements stemming from the load case scenarios, the utilization within each segment has to be smaller than one. The utilization calculations are performed within all the plates of each segment with respect to stress, fatigue and buckling. Towards this end, LWN provides an external structural analysis tool.

Fig. 5.
figure 5

Illustration of a maritime crane box type boom, cost optimization problem and related formalized objective function

Full size image

The idea of this case study is to couple the task of spatial product architecture parameter synthesis (i.e. determining above mentioned variables) with the corresponding analysis. This is illustrated in Fig. 6, showing how two pre-defined DA task templates (“Spatial Product Architecture Parameter Synthesis” and “Spatial Product Analysis”) are re-used, instantiated and combined to specify the automation of the business task “generate optimized design of the box-type boom”.

Fig. 6.
figure 6

Re-use and combination of two DA task templates for specifying the automated generation of optimized design of a box-type boom.

Full size image

Figure 7 shows the BDD of the box-type boom for describing its architecture in terms of sub-components as well as related design parameters and variables. Figure 8 shows the PAR of the cost optimization function as introduced above. The constraint blocks that are illustrated within the PAR of Fig. 8 symbolize the rules for linking the specific parts and parameters of the text and include both the equations as well as parameters needed for relating the elements. Thus, design parameters, variables and constraints required for performing the cost optimization task and for implementing this objective function are interrelated.

Fig. 7.
figure 7

SysML block definition diagram of the box-type boom.

Full size image
Fig. 8.
figure 8

SysML PAR of the cost optimization function and related constraint blocks.

Full size image

This case study has permitted to demonstrate the applicability of the methodology on which the proposed EA and MBSE methodological framework for DA has been developed. The definition of the DA task building blocks has been performed based on predefined templates and is currently implemented for both heuristic and meta-heuristic solvers. Easy comparison of different solving strategies is hence enabled. For the shown case study, the design task has been formalized with respect to product knowledge describing the input (structure, parameters, variables, relations etc.) as well as the desired output state (constraints and objectives). Despite the usage of model libraries as well as corresponding SysML profiles, the expressivity SysML provides remains a challenge to the modeler and the corresponding interpretation for translation to a computable language.

5 Conclusion and Way Forward

In this paper, a federated EA and MBSE methodological framework for integrating DA into a global PLM approach has been introduced. This framework is built upon a systematic methodology for:

  • ensuring the transition of academic methods to industrial practice through a comprehensible and comprehensive DA task categorization that allows practitioners to grasp the opportunities state-of-the-art DA offers;

  • supporting the specification of industrial business cases and scenarios through business process modeling and re-use of business process templates;

  • supporting the specification of the DA solutions to be developed: for each derived design task category, a DA task template is proposed to be re-used and instantiated in order to derive the building blocks required for the implementation of the appropriate DA method.

A case study addressing the specification of an optimization task and related solution for the design of box-type boom cranes at LWN has been used to demonstrate the applicability of the framework’s methodology. Lines of future work comprise the completion of the EA framework with all the DA task templates required for each DA task category, the completion of the MBSE framework with SysML DA task profiles and stereotypes for each of these categories and the development of specific user interfaces to guide the designers for defining the DA task building blocks themselves. Future work should also include the development of interfaces that are restricted to the modeling capabilities needed for a specific DA task, rather than providing the entire expressivity of the SysML language. Further, mechanisms to assess the quality of the task definition need to be developed. Finally, in order to provide maintenance consistency and change propagation mechanisms while linking EA models, SysML models and the various platform-specific DA implementations, standardized linking semantics concepts should be investigated.