Architecture and Design Methodology of Self-Optimizing Mechatronic Systems

Gausemeier, J.; Kahl, Sascha

doi:10.5772/9121

Cited by 11 publications

(16 citation statements)

References 6 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…These days, even some of the authors of the VDI guideline 2206 consider the proposed procedure model only "as first step on the way to a holistic design methodology for mechatronic systems" (Gausemeier and Kahl 2010). Therefore, the parts of the disciplinary design likely to change have to be clarified upfront.…”

Section: Approach For Establishing a Process View Based On Common Promentioning

confidence: 99%

“…Deviating from the procedure model described in the VDI guideline 2206, Bellalouna (2009) follows the specific methodology of automotive engineering and consequently adopts the logical and technical system architecture as described in section 2.6.3. Gausemeier and Kahl (2010) introduce a new design methodology for mechatronic and self-optimizing systems. Follmer, Hehenberger, et al (2011) propose a procedure model for model-based mechatronic design that uses the V-model of VDI guideline 2206 as base for integration.…”

Section: Identification Of Relevant Procedures Models Of Mpdmentioning

confidence: 99%

“…Gausemeier and Kahl (2010) use the term "principle solution" to describe the result of the system design phase comprising the overall structure and the modes of operation of the mechatronic system. The analysis of the process elements proposed by the various considered procedure models revealed large differences in (a) the applied terminology and (b) the proposed process elements.…”

Section: Clarification Of Terminology and Alignment Of Process Elementsmentioning

confidence: 99%

“…(b) The specifics of the approach proposed by Gausemeier and Kahl (2010) regarding the handling of multiple specific application scenarios were not considered, as they significantly differ from the other approaches. Accordingly, the process elements of task clarification and requirements design precedent to system design will not be considered.…”

Section: Compilation Of Common Process Elements and Rolesmentioning

confidence: 99%

See 3 more Smart Citations

Analyzing and Modeling Interdisciplinary Product Development

Neumann¹

2015

View full text Add to dashboard Cite

Section: Approach For Establishing a Process View Based On Common Promentioning

confidence: 99%

Section: Identification Of Relevant Procedures Models Of Mpdmentioning

confidence: 99%

Section: Clarification Of Terminology and Alignment Of Process Elementsmentioning

confidence: 99%

Section: Compilation Of Common Process Elements and Rolesmentioning

confidence: 99%

See 2 more Smart Citations

Analyzing and Modeling Interdisciplinary Product Development

Neumann¹

2015

View full text Add to dashboard Cite

“…Design Methodology for Mechatronic Systems [Gausemeier, 2007]; develops a tool and framework to specify a product model. From this model, product instances can then be instantiated.…”

Section: System Architectingmentioning

confidence: 99%

Consistency, integration, and reuse in multi-disciplinary design processes: through an architecture modeling framework

Woestenenk¹

View full text Add to dashboard Cite

This work has been published using L A T E X 2 ε and the Twentethesis documentclass.Duurt even, maar dan heb je ook wat... SummaryThe development of modern (mechatronic) systems demands close cooperation between experts from multiple engineering disciplines. These disciplines each speak their own engineering language and can even have conflicting views of what the system is. This leads to a complex situation that impedes the communication between these experts, as well as the integration of design and analysis tools.The main 'pressures' in improving multi disciplinary design are the improvement of system performance, time-to-market and cost. This can be improved by facilitating communication between stakeholders, modeling architectural concerns and other important design information, and facilitating capturing and reusing design knowledge across disciplines. These pressures, however, cannot be subject to direct scientific research, as experiments cannot be easily realized: We cannot let multiple companies perform multiple design processes to compare methods that aim to improve the pressures. Instead, the pressures are 'transformed' in the issues of consistency, integration and reuse, which can be evaluated through case studies. As such, the hypothesis for this thesis is: The consistency, integration and reusability of multi-disciplinary design processes can be improved by facilitating communication between stakeholders, modeling architectural concerns and other important design information, and facilitating capturing and reusing design knowledge across disciplines.To help this communication, multiple stakeholders need to have a shared model to: share design decisions, create common understanding of the design process, share deliverables (workflow), and keep this shared information consistent. In such a model, stakeholders can make their own views to create models for their aspects of the system. The information in these views can be connected to other views, and even reused by copying or referencing. This facilitates the stakeholder gathering the information from multiple sources to do his job, or allow exposing his concerns so he can influence activities performed by experts of other disciplines.The argument of this thesis is: there is a lack of a common language that can describe both the system architecture and information flows in the design process. Such a language should enable us to model the shared information between the designers and their models and the tools that they use. There is no unifying modeling language to exchange information across disciplines, across design process phases and across levels of granularity. This means we lack the means to make a model of all design aspects, especially the ones that cut across the design disciplines. We lack the means to model how information from the mono disciplinary design tasks is handed over to subsequent design tasks. And we lack the means VIII to provide a big picture of how mono disciplinary design information is connected to the abstract system wide ...

show abstract