Technical systems contain mechanical, electrical, and software parts. Consequently, they are developed by engineers of the respective disciplines. However, current industrial practice as well as existing development processes do not account for the required tight integration between the engineers of the different disciplines. Processes become even more complex, when self-adaptive systems are built. In this paper, we present a development process for self-adaptive mechatronic systems which particularly addresses the integration between the disciplines concerned with the development of software, namely control and software engineering. We illustrate the process by presenting examples from the development of autonomous railway vehicles which build convoys to improve energy efficiency.

Mechatronic system development requires a close collaboration of different domains. After the system’s conceptual design is created, the domains work in parallel using domain-specific models. Later changes to a domain-specific model may or may not affect

Much of the innovation in today’s technical systems is only possible by the use of embedded software. This is especially true in the case of system of systems where autonomous systems coordinate using complex message-based communication protocols. Mechatr

In typical model-driven development processes, models on different abstraction levels are used to describe different aspects. When developing a mechatronic system, an abstract system model is used to describe everything that is relevant to more than one of the disciplines involved in the development. The discipline-specific implementation is then carried out using different concrete discipline-specific models. During the development, changes in these discipline-specific models may affect the abstract system model and other disciplines' models. Thus, these changes must be propagated to ensure the overall consistency. Bidirectional model transformation and synchronization techniques aim at automatically resolving such inconsistencies. However, most changes are discipline-specific refinements that do not affect other disciplines. Therefore, vertical model transformations also have to take into account that these refinements must not be propagated. Current model transformation techniques, however, do not provide sufficient means to specify and detect whether a change is just a refinement. In this paper, we propose a way to formally define such refinements. These definitions are then used by the model transformation engine to automatically synchronize models of different abstraction levels.

[Context and Motivation] Subsequent to an exploratory laboratory study on the effects of Software Architecture (SA) on Requirements Engineering (RE), in this paper, we present preliminary results of an extension of this initial study by conducting a case study on a large-scale prototypical rail project. [Question/Problem] Specifically, we ask “What is the role of an SA on Requirements decision-making?”. [Principal Ideas/Results] Specific types of architectural effects on requirements decisions are identified. The impact of the affected requirements decisions on downstream processes and the product itself is also characterized. [Contribution] The understanding gained from this study has implications on such areas as: project planning, risk, RE, and others.

Replication of studies in Software Engineering is considered important, but is largely neglected. Because of the lack of published replicated literature, there are few established guidelines for researchers wanting to conduct replicated studies. Specifically, guidelines for transitioning from laboratory studies to large-scale studies are nonexistent. Previously, we conducted a laboratory study in the banking domain, in Canada, which we replicated by conducting an extended, large-scale case study on an innovative rail project in Germany, investigating the role of an existing systems architecture on requirements decisions. In this short paper, we present a preliminary analysis of our transitioning experiences from conducting these two studies. From our experiences, we derive a set of lessons learnt and recommendations that can be used by other researchers wanting to transition from lab studies to studies in industrial settings.

The role of an existing systems architecture (SA) in requirements engineering (RE) is recognised as important, but under-researched. A recent exploratory study of ours investigated this issue in a laboratory setting involving student participants. While the initial findings are promising, much work still remains to solidify the results. Therefore, we conducted a replication of the study, and its significant extension, on a large-scale prototypical rail project. Specifically, we identify (i) the effects of SA on RE decisions, (ii) the characteristics of the RE decisions and (iii), the impact of such decisions on development activities and the rail system. The findings of this study have implications on tighter RE-SA integration across subsystems, impact analysis of requirements on SA, and planning and risk management. We also propose three emergent hypotheses from this case study as a driver for future empirical work in RE. This case study involved examining the 10-year history of requirements and architecting decisions in several major components of the rail project. The data collected was from numerous project documents and extensive interviews with the developers and planners.

Today’s trend in software and system engineering is to utilize more specialized models. This model-based development approach makes a single engineering task more easy, as the engineer can focus on the particular aspect of the system, when working with one model. Though collaborations get more difficult, because more models have to be kept consistent. Unfortunately, the process support for model-driven development is still rather weak in today’s development environments: static processes are supported, but this is insufficient for collaborations. We present a technique for project planning which utilizes relations between models and which uses a verification method to produce suggestion for the project plan, based on the current situation of the project.