• Autos schnell updaten wie ein Smartphone (KIT press release, German), 23 May 2023

Motivation

In this CRC, we will investigate novel methods for developing CPS with views, which are a central mechanism for coping with the ever-increasing complexity of CPS. Such views arise from the need for different models of the physical design, E/E architecture, hardware, and software. Having different views on one system is an established practice today, and is inevitable, as each tool used for design, analysis, and production uses specific models of its own, each of which can be seen as a view on a system. In addition, the specialisation of developer roles (e.g., analysts, quality engineers, and designers for various electrical or mechanical parts and software modules) work on specific models in specialised modelling languages, where each model forms a view on the system under development. These views are, however, too often isolated due to tool boundaries, tool incompatibilities, and isolated developer roles. In fact, dependencies between these views are often not documented or even unclear. These dependencies can be manifold, e.g., the same system element can be represented (potentially differently) in several models. In general, various kinds of dependency relations can exist between different elements of several models. As long as such relationships exist within one model, they are checked by the model editor or associated tools. Once these relations span different models from different modelling languages, maintaining these relationships during development is a tedious, error-prone, and manual task, which is often forgotten or omitted. Missing or insufficient consistency management between views constitutes a risk during development projects. In effect, it limits the complexity of system design and development that can be successfully dealt with. With the increasing role of software-implemented functionality, the number of views and dependencies between views will even increase in future. Therefore, we will research mechanisms for managing consistency between different views. Concretely, we aim to extend and generalise mechanisms investigated in the context of software engineering to cyber-physical systems engineering. Scientifically, we work on the challenge of providing a unified understanding of consistency and inconsistency across different kind of models (structural, behavioural, and quality models, as well as discrete, continuous, hybrid, and data-inferred models), which until now have been addressed in different scientific communities. From a practical perspective, a comprehensive approach to consistency management will enable entirely novel design and quality assurance methods for CPS. In the following, we elaborate this vision more concretely and present a visionary example scenario from the automotive domain which will be used in the first funding period as an overarching case study.

CPS are omnipresent and affect ever more aspects of our lives. Most current visions for addressing general challenges of our modern societies, such as mobility, energy, production and health care, rely on CPS of yet unseen complexity and flexibility. Examples are manifold and range from interconnected, automatically driving cars, mobility systems in general, current and future energy network management systems that utilise locally transformed renewable energy forms or “Industry 4.0” use cases.

Common to all these application areas of CPS is the demand for more functionality, driven by higher expectations on usability, networked functionality, and added-value through additional features. In case of mobility systems, such features are, for example, new safety, comfort, and automation features in cars, as well as the move from single vehicles to interconnected mobility systems in which various forms of transportation interact in an open system. This trend is leading to a dramatic increase of software usage and software complexity in CPS. According to Brooks, essential and accidental complexity can be distinguished. While essential complexity is inherent in the required functionality, accidental complexity is added through inappropriate design methods. The current trend in CPS to demand more functionality adds to the essential complexity, and, as shown below, also to the accidental complexity, as current development approaches reach their limits.This trend for more functionality and increased CPS complexity can be summarised in terms of three demands that need to be addressed simultaneously by any future CPS design method:

Demand for Higher Configurability

More functionality and, accordingly, higher complexity lead to in-creased costs in CPS development and production. This has already forced vendors to utilise global markets, as higher sales can balance these increased costs. However, in global markets, products need to be tailored to various specialised national regulations and customer demands, which leads to a strong demand for flexibly configurable products. Inevitably addressing specific customer wishes through highly configurable products leads to many specialised variants (our highly configurable cars can be seen as a classical example for this trend). The increased use of software can be seen as a consequence of this demand, as software is often used as a means to enable flexible configurability. As an example, the embedded (hardware) platforms on which CPS are built have become increasingly generic, tend to be configured by software (“software-defined-X”), and can communicate with other CPS or backbones using ubiquitous networking capabilities. Genericity and configurability reduce the cost of CPS, because the same platform can be used for different purposes, and this platform can be produced in large quantities. Hence, configurability leads to a high number of variants, also referred to as variability in space.

Demand for Higher Update Frequencies

As already seen in the competitive market of web services, one of the most important properties of a service is its ability to provide new or better functionality to customers. Here, the competition leads to higher update frequencies than ever seen before in software engineering. A similar trend is already noticeable for CPS through the increase in software-implemented functionality. For example, software updates over-the-air (OTA) for vehicles during their operational time are already offered by vendors who are changing their business models towards value creation through software updates instead of solely selling the vehicle itself. From a technical and scientific perspective, this leads to the challenge of synchronising the different lifecycle speeds of software with electrical components and mechanical hardware. This flexible evolution of a system can be seen as variability in time.

Demand for High Dependability

As CPS have become ubiquitous in most parts of our lives and in critical infrastructures, our welfare needs dependable CPS. However, since software is becoming the essential innovation driver in modern CPS, software failures create new threats. While the analysis and certification of electro-mechanical systems is well established through standards for methods, authorities, and assurance levels, the certification of software has not been developed to the same level. Given the high manual effort involved in the homologation of CPS such as in the automotive domain or aviation, the variability in time and space even increases the mentioned methodological challenge, requiring a higher degree of automation and a better understanding of which dependability properties still hold after an update.

As discussed, software is a key solution element to these challenges but also adds complexity by increasing the number of specialised developer roles and views as well as by creating more undocumented or even not understood dependencies between views. At present, there are no systematic, integrated ways of adequately dealing with complexity in CPS design arising from many views and their unknown dependencies. As a result, current development methods inevitably require trade-offs in CPS design (e.g. either high dependability but less flexibility and connectivity, or vice versa). In particular, this directly leads to either a limitation of dependability or the realisable functionality, as the latter requires connectivity to other systems and services.

Current Practice

Current approaches and their methods have reached their limits because they do not efficiently distribute the underlying complexity of CPS to the many different developers and stakeholders involved. There are few publicly accessible reports on failures and delays through unmanaged complexity in CPS design. There are, however, numerous reports about the increasing number of tools with specific views and of the delays caused by inconsistencies between them. More generally, in the domain of computer integrated manufacturing (CIM), it is becoming apparent that one significant challenge is understanding semantic dependencies beyond a mere technological network protocol. To cope with this complexity, the development of CPS has to be broken down, recursively, into independently manageable parts or subsystems, each of which may contain hardware and/or software elements. While the traditional “divide- and-conquer” approach to engineering has been tremendously successful in the past, today’s CPS are so complex that even individual subsystems usually cannot be handled by engineers from one specific discipline. Multi-disciplinary teams are therefore needed to write, maintain, and implement the myriad of documents involved in modern CPS development. Today’s methods and tools are, however, highly specialised, and they usually focus on supporting the concerns of just one specific discipline in isolation. Consequently, the impact of the design decisions made by developers of one discipline is often not understood by developers of another discipline. This not only leads to unexplored design options (resulting in lower quality or higher costs), but also increases the risk of inconsistencies, which can remain undetected in many development phases but can hinder the production or release of the system. This ultimately results in high project costs and risks, which limits the complexity and size of CPS that can be developed economically.

An example of a discipline-specific development approach that concentrates on one primary artefact is agile development. A key principle of agile methods is to concentrate on software source code in order to avoid the consistency problem that arises when multiple descriptions of the software are created. Although agile methods achieve tremendously shorter times-to-market, the size and kind of systems that they are able to cope with is limited. Unfortunately, this is not an option in systems engineering, where hardware and software play an equal role, and where several different perspectives, by necessity, have to be considered in combination. Approaches dealing with the physical, design-specific artefacts of systems (such as electronics or mechanical parts) have traditionally focused on one concern, and have given developers little help with questions of integration and consistency. The fast feedback cycles on customer satisfaction and product quality which are enabled by agile processes are, however, clearly desirable for CPS, which are increasingly software-driven.

Another fundamental way to cope with complexity is to introduce higher abstraction levels, as for example seen in software component diagrams or block definition diagrams, which abstract from implementation details and the behaviour of components. Working at abstraction levels that are “too high”, however, can lead to the problem that the impact of design decisions can no longer be analysed in a meaningful way, as highly abstract models lack the relevant semantic information for analyses. This results in situations in which a system can be modelled but not sufficiently understood through simulations or analyses. This defeats the whole point of an engineering approach which inherently bases on the ability to understand the impact of design decisions on the product quality in advance, i.e., prior to deployment and operation. In practice, it is widely recognised that all relevant descriptions of a system need to be designed in a sufficiently coherent and consistent way, in accordance with their inherent complexity and abstraction level, to facilitate the analysis, simulation, and test activities needed for optimal design decisions and quality assurance. Although it is usually not necessary to enforce consistency in an absolute manner (i.e., all inconsistencies resolved), consistency is required to a certain degree: First, so that implemented and built systems relate to specific input models for analyses to ensure the validity of analyses results, and second, so that the system is “realisable”, i.e., one wants to avoid contradictions on models which hinder realisation. Due to the complexity of CPS, the many quality properties to be ensured, and inevitable specialisation of engineering, CPS are developed using a plethora of specialised models and analysis tools, which each demand specific input models. This plethora of models gives rise to the term view and view types: A view (type) is a subset of the information on a system. One or several views represent design decisions within a design space (which can be discipline-, role-, or model-specific). On a coarse-grained level, there are software, electronics and mechanical design spaces, subdivided for specialised roles, tools and models. Hence, each engineer is working in his or her specific design space(s) and view(s). On the positive side, views and design spaces provide the basic means for coping with complexity of CPS by ensuring that no single person needs to understand the whole system, but can still deal with details needed for design, build, production and quality assurance. In fact, the idea of using views to support the division of labour in the development of software and systems through specialised developer roles has been researched since the 1990s. On the negative side, views and design spaces usually contain information which is also present in other views, leading to inherent dependencies between them: A change in one view often has consequences that need to be reflected in dependent model elements of other views. If these dependencies are violated (e.g., a change in one view is not reflected in dependent elements of other views), the affected views become inconsistent.

In current practice, engineers have to manually keep these different views or design spaces sufficiently consistent. Through periodic meetings, they try to identify relevant inconsistencies between the evolved models. A relevant inconsistency hinders the realisation of the system at a future point in time. Accordingly, an inconsistency might not immediately cause problems. There might even be good reasons to continuously work with existing, known inconsistencies, while unknown inconsistencies form risks for system development. In summary, current processes and tools in current state-of-the-art multi-view development are very costly, error-prone, and risky. In fact, project risks and associated quality problems are increasing so quickly in relation to the system’s complexity that we are rapidly approaching a limit to the scale of systems that can be constructed effectively. Moreover, these problems can only be expected to grow in the future, first, as the numbers of view increase, and second, as models are increasingly “learnt” from data, and are thus only implicitly defined, and change frequently when new data becomes available. The fact that basically all complex modern systems are developed using a deep value-creating chain of suppliers at different levels introduces organisational and legal boundaries which need to be dealt with by any approach for collaborative system design.

Hardware/software co-design methods address the design of software-intensive technical devices at least for software and electronics. Ideal, discipline-spanning design spaces are, however, often subdivided prematurely into software- and hardware-related design spaces so that there is no support for assessing and ensuring the consistency of the various artefacts involved in development as they evolve. In particular, quality analysis approaches are tied to either software or electronics, and do not span both domains. Thus, system-wide reliability statements are impossible at scale, and potential ways of improving the efficiency of production or maintenance through better trade-offs between alternative hardware and software realisations cannot even be identified, let alone analysed and exploited.

In conclusion, today’s development methods are not ready to cope with the complexity of the next generation of large CPS, because they either concentrate on a small number of artefact types (agile methods focus on code artefacts precisely to avoid the problem of consistency handling) or because they take premature design decisions that mitigate consistency problems at the cost of flexibility. In cases where different views need to be integrated, engineers currently have to spend much time manually ensuring consistency, rather than on focusing on the creative process of building better products in shorter development cycles. Analyses of system properties which span several views are not feasible, and thus cannot be used to support design decisions, or even to systematically optimise for quality or cost.

Visions and Goals

The vision of this CRC is a development methodology for CPS across various design spaces of different engineering disciplines which supports short release cycles, high dependability and high configurability.

We need to find and support appropriate approaches for supporting the integration of the different design spaces of engineers from different disciplines backgrounds fulfilling specialised roles. For illustration, consider the following exemplary scenario from the automotive domain: A motor electronics engineer implements the electrical engine’s controller permitting both acceleration and recuperation, a brake system engineer designs the physical brake system including the brake disc and pads, and a software architect organises the software partitioning and interfaces. As described above, these role-specific modelling activities immediately give rise to the concept of a view, which is tailored to support the specific tasks of the mentioned roles.

Our example can also illustrate dependencies between views. Assume that one view of a brake system is a CAD model including a dedicated electronic control unit (ECU), and another view describes the corresponding E/E hardware architecture, where the same ECU is linked to the CAN bus. If the dedicated ECU is no longer sufficient to run the brake control software, changing the type of the ECU in the E/E hardware architecture potentially requires adapting the CAD model as well, to ensure that the new ECU type still fits into the assembly.

Goal: As discussed above, existing approaches provide only rudimentary mechanisms for detecting and ensuring consistency of views. In contrast, we envision a support for consistency management that is either automatic or, in most cases, interactive, making developers aware of areas of inconsistency and suggesting potential resolutions. It is an important subject of research in this CRC to find out when consistency is to be achieved, what needs to be kept consistent, how to establish, preserve or restore consistency, and how to deal with inconsistencies which cannot immediately be resolved, and which kinds of inconsistencies do not need to be resolved at all. At large, we envision design spaces with views across different disciplines, supporting novel engineering roles. Such novel roles could be responsible for, e.g., optimising cross-cutting concerns such as dependability or sustainability, where design decisions affect many different views from different disciplines.

Goal: Our goal is to create concepts for tool-supported, model-based development processes where engin- eers from different disciplines and design spaces with different views on CPS can work together seamlessly. Dependencies between views, versions, variants, and product generations are modelled explicitely in a so-called “virtualised single underlying model” (V-SUM). The use and further development of the V-SUM will form the shared technological core of this CRC. The V-SUM approach allows engineers to develop CPS in different views and different design spaces as independently as possible, and provides assistance in managing view consistency with automation as far as possible and with user interaction where appropriate. The envisaged scientific contribution of this CRC lies in (1) the formalisation and understanding of different notions of consistency and their properties; (2) the elaboration of mechanisms to construct a virtual single underlying meta-model that, among other things, formalises view interdependencies (see below) as well as consistency preservation mechanisms between views (resp. view types) to support the automated, cross-disciplinary synchronisation of views and is capable of dealing with versions and variants; and (3) the development of algorithms that realise the synchronisation process and that either suggest how to “repair” inconsistencies or directly repair the inconsistency themselves. In short, we want to investigate to which extent software engineering approaches for view consistency can be transferred to engineering CPS and how these approaches need to be adopted to include non-software view types. We believe that there are three reasons why this is the right time to realise our goal and vision.

1. There is a clear practitioners’ demand for development methodologies able to cope with the complexity of future CPS.
2. Computer science researchers have developed technologies for the view-based development and evolution of software based on a single underlying meta-model that are ready for transfer to other disciplines (as exemplified, for instance, by the “knowledge carrying software” approach of the DFG priority programme (SPP) 1593). At the same time, view-based development methodologies have long been regarded as necessary, and partly applied, in the engineering field, and are ready for the inclusion of software-related concepts that specifically relate to variants and versions.
3. Results from the database community on transactionally updating and synchronising views have been enhanced by the model-driven software engineering (MDSE) community and are currently being applied to models, in general. These theoretical foundations from the database and MDSE communities and the respective tool box for transactionality and persistence provide a strong foundation for the model-based development process we envisage.

Scientific perspective: From a scientific perspective, the challenge of managing consistency and in- consistencies between multiple design spaces and views is fundamental. Notions such as consistency, version, and variant have to be understood in the context of multiple descriptions, i.e., views of CPS from different disciplines. Conceptually, a set of consistent views forms the basis for a unified design space that transcends the boundaries of disciplines and thus provides the foundation for novel methods and processes to partition the design space, provide new interfaces for distributed collaboration, and analyse CPS in an integrated way. Scientifically, it is still unclear how far the concept of view consistency could act as a uniform frame for activities, like the propagation of structural changes, the verification of behavioural properties, and the analysis of quality properties. As each of these topics is currently discussed in different scientific communities, a unified understanding will have a broader impact within and across the modelling, software, and systems engineering communities, in general.

At the same time, there are fundamental research questions related to model coupling, semantics, consistency, variants, and versions, that need to be tackled to turn such a development process into reality.

Economic perspective: From an economic perspective, such new design methods for CPS will provide faster development and evolution cycles, functionally richer products of higher quality, development pro- cesses with lowered costs and risks, and support for managing versions and variants. We believe that the fundamental need for a new development methodology is strongly related to Germany’s extraordinarily strong export tradition. Serving markets on a world-wide scale directly implies the need to efficiently man- age huge numbers of variants and versions. This implies the need to incorporate technology required by specific national markets, whether driven by customer demand, regulation, or market protection measures. The new development methodology we propose makes it possible to cope with the development of huge, configuration-rich, software-intensive CPS, while keeping high guarantees on dependability, thus laying the foundation for the continued technological leadership of German CPS engineering.

Criticality of the topic: The criticality of the topic of this CRC can be illustrated by the shift towards electrically powered cars in the automotive industries. This shift involves the optimisation of electric power consumption in cars and requires many more types of consistently integrated models in their design and operation than before. The next shift to the autonomous operation of cars, envisaged in the near future, will drastically aggravate this situation, because the required software certification will be impeded if there are inconsistencies between the models. Software updates over-the-air, which are already driven through vendor competition, introduce the additional technical challenge of certifying critical system properties while at the same time allowing changes after delivery. Therefore, the consistent integration of multiple coupled models is a key element in the future design of cars, airplanes, and other autonomous systems, and we believe that manufacturers who use the technologies and methods developed by this CRC will have a much better chance of prospering in future markets.

Finally, the development of CPS requires engineers educated in both the computer science and engineering disciplines. The CRC’s structural impact on the involved universities, described in Section 1.3, provides a basis for developing new forms of engineering education for the 21st century, in which software engineering and classical engineering disciplines are strongly interwoven.

Long-term vision and scientific impact: The long-term vision and scientific impact will be no less than a new role of future software engineering within systems engineering. It will be the role of an exporter of software engineering methods to systems engineering, as elaborated below.

As the research described in this proposal is focusing on foundations for methods for CPS design and evolution, the impact will be on our methods of CPS engineering and, due to the foundational work we plan, on the role of software engineering within systems engineering. Accordingly, the effect on the resulting CPS themselves is indirect: through methodological advances, one will be able to develop CPS which are flexibly updatable, highly dependable, and configurable at the same time. The state of the art is that at least one of these attributes needs to be sacrificed to advance another one. Our vision is that this CRC has a large impact on the discipline of software engineering. This is based on the following reflection of the nature of software: Software is immaterial; it can be seen as a special case of computable, constructive mathematical formulae. This immateriality is relevant for methods to create artefacts. The separation of planning and production, as propagated by Henry Ford and Frederick Winslow Taylor at the beginning of the 20th century, proved to be very beneficial in mechanical engineering, enabling the mass production of complex physical artefacts. In software engineering, however, this analogy often leads to estimating the early development phases (such as requirements specification, formalisation and analysis) as the intellectually demanding part (such as the design of mechanical artefacts), while programming is often neglected, since it is compared to physical production. This way of thinking influenced the heavy-height software development processes of the 70s and 80s. With the advent of agile methods in software engineering (themselves, interestingly, being inspired by lean production approaches from mechanical engineering), the goal was to overcome this false understanding of programming as production. In fact, production in mechanical engineering is the creation of multiple physical entities. Software engineering itself is not concerned with the creation of physical entities. However, valid analogies to production can either be the deployment of the software or the execution of the software. Hence, we see that there are no fundamental differences between requirements engineering, design of software and physical entities. In fact, they all relate analogously to activities as done during the development of physical entities, which effectively means the development of plans for production. This “correction” of the analogy between mechanical engineering’s development and production for software engineering has the benefit that it makes clear that there is also no fundamental difference between software (as plans for execution) and mechanical engineering models (as plans for production).

This directly leads to the underlying question of this CRC: if software as a model does not fundamentally differ from models of electrical or mechanical engineering (although the term production means different things), to what extent can we transfer methods from software engineering to mechanical and electrical engineering where we also deal with models? In this transfer (which also includes researching the need for extensions, specialisation or generalisations), we see a great opportunity for the future of software engineering and systems engineering alike. As systems engineers who create CPS inevitably have to deal with a multitude of models, in this CRC we focus on mechanisms for keeping models consistent, and for managing their inconsistencies. We strongly believe that our techniques for consistency management developed in the context of software engineering will provide their full capabilities in systems engineering, as the use of many different abstract models and views is already established in systems engineering.

Our long-term vision is the advancement of software engineering, so that it becomes more central in systems engineering. For software engineering, this means that we need to better understand how specifics of the application domain will influence methods. For systems engineering, it means to understand how to integrate the very different life-cycle models of software, hardware, and mechanical parts. This CRC lays the foundation for this.