Agile software development, with its short development cycles and focus on results, has made a triumphal march through IT departments. Start-ups and established companies alike appreciate the benefits of early and continuous delivery of software and close collaboration between subject matter experts and developers and are increasingly adopting this software development model, with fundamental implications for the organization and the way their teams work.

Decision-makers are faced with the challenge of implementing agility in such a way that it fits in with the company's typical requirements for predictability and budget security. Agility must work in the corporate context. Companies also face this challenge when it comes to the development of cyber-physical systems (CPS). This is because agile software development only fits the challenges that CPS pose to companies to a limited extent.

CPS are software-intensive systems whose architecture and functionality are much more complex and directly interwoven with the processes of the real world than is the case with traditional software systems. This is because, depending on their structure and purpose, CPS not only have to record large volumes of data accurately, but also evaluate them independently and then initiate the right measures. A fact that is also reflected in their development processes. Understanding the processes in your own company and the specifics of your own industry, which is already important for project success and system quality in conventional information systems, is even more important for CPS. This is because there is no 'undo button' for reality. Possible errors in a CPS have a direct impact on the physical world, where they may be irreversible.

The challenge of collaboration

Another special feature is the interdisciplinary nature of system development. In contrast to traditional software development, in which the specialist side often only takes on the role of client for the IT side and is therefore often only sporadically involved in development and decision-making processes, CPS require continuous collaboration with the specialist and technology experts from the operational application areas. Engineers are not only clients, but are also responsible as designers for the physical components of the CPS. As part of the development team, they therefore bear the same responsibility for the success of the project as the software experts.

Due to the requirements that Cyber-Physical Systems entail, it is advisable - in comparison to classic software systems - to set an adapted focus with regard to the software development paradigm pursued. The high degree of coordination required between the specialist and technology sides described above is actually a clear indicator for the choice of an agile process model. This is because agile means intensive communication between all those involved in the process, regardless of departmental affiliation.

At the same time, agile teams develop prototypes early on in the process that users or customers can test. This early availability plays a major role in the successful development of CPS: testing the interaction of all components, checking their behavior under unusual conditions and, in particular, calibrating automatisms in semi-autonomous systems helps everyone involved to develop functional solutions that prove themselves in day-to-day business.

However, agility has its limits when it comes to planning and implementing cyber-physical systems. Detailed models and specifications are not completely unknown or insignificant in agile development. However, they take a back seat to more traditional development methods, such as the waterfall model. The Agile Manifesto, the foundation document of the agile movement from 2001, states: "Functioning software is above comprehensive documentation." A point that can lead to problems in CPS development.

This is because, and this is where the proximity of cyber-physical systems to embedded systems becomes apparent, the precise modeling of the behaviour of individual components also plays an important role. Particularly at the interfaces between the physical and digital worlds, the details are crucial, especially when high reliability requirements apply to the control of actuators or when the correctness of sensor data is critical. The same applies to the framework conditions and decision-making mechanisms in the control systems of semi-autonomous systems. The development team must understand all aspects of the complexity of cyber-physical systems and the variety of situations in which they are expected to make independent decisions and, if necessary, verify them in order to rule out intolerable states. For these aspects of development, it is advisable for those responsible to rely on a detailed, possibly even formally verifiable specification.

The interdisciplinary team of software developers, users and engineers is now faced with the task of identifying the parts of the CPS project that are suitable for the agile approach or for which the classic approach is recommended. This is because both development approaches can advance the development of a cyber-physical system when properly combined. As with the development of classic information systems, the choice of the appropriate degree of agility plays a decisive role.

The 'Interaction Room'

One tool that helps project participants to make this distinction and at the same time ensures that communication within the interdisciplinary team functions efficiently is the so-called 'Interaction Room' (IR). This is a 'real' project room in which the team members meet regularly. The four walls of this room, the 'maps', play a key role. The participants use them to document business models, processes, interfaces or open points in a clearly visible and easily understandable way. In the room, the project members recognize what is otherwise difficult to grasp: the dependencies between processes, data and application landscapes.

An overview of some of the annotations that can be entered in the models

© Adessso

The aim of the work in IR is to identify potential value, risk and complexity drivers of a project as early as possible based on the shared understanding of all those involved - regardless of the specialist department and expertise. To do this, the IR uses an intuitive visualization method known as annotations (see Figure 1). Annotations are symbols that have a specific meaning and are used by project participants to enter additional information into models. Some aspects are subject to special safety requirements, others are algorithmically complex or may not be sufficiently understood. Simply locating the symbols in the models by simply sticking the annotations on helps to identify critical points. However, the actual gain in knowledge through the use of the interaction space arises when the reasoning of the expert who used the annotation is discussed. Discussing different assessments is therefore an essential part of achieving a common understanding. This evaluation process is also suitable for working on CPS: How critical is an interface? What impact would the failure of a system component have? The overall picture determined in this way can be the basis for the experts to decide which components of a CPS should be developed agilely and which classically.

In order to investigate the potential effects of the failure (or partial failure) of a sensor or actuator and to explicitly clarify the extent to which a failure would be critical, the team should apply familiar reliability techniques such as 'Failure Mode and Effects Analysis' (FMEA) or 'Failure Mode and Effects and Criticality Analysis' (FMECA) from the field of embedded software. In order to build a CPS that meets the relevant requirements, the project participants may be able to develop in an agile manner if the reliability requirements are low. For example, those responsible could decide to use an agile model when developing the user interface for displaying the data recorded in the CPS. This has the advantage that IT and users can quickly arrive at functioning design approaches and solutions. Although this user interface is an important element of the system, it is not critical to the system. In the case of strict requirements whose non-fulfilment is associated with high risks, it may be necessary to verify the system properties. In this case, purely agile development is not enough; system updates can become expensive simply because of the necessary verification.

Consequently, the cyber-physicality of a system does not necessarily lead to less agile development, but on the whole makes it the sole means of choice to a lesser extent. It is difficult to make sweeping statements here, but trends can be identified: The closer a CPS component is to the real world, the more likely experts are to consider traditional development methods. This "adherence to physics" has an impact on software development and requires precise specifications. Conversely, the further away from physics, the more agile development is possible. In between, there is a grey area of components that the experts have to analyze in detail in the 'interaction room'.

Agile and classic software development

The aim of agile software development is to develop lean software using a lean development process. The concept relies on the rapid development of executable software, the regular publication of small releases and the self-organization of teams. More plan-oriented concepts rely on specifications being fully recorded at the start of the project. These are worked through and a release with all new functions is published at the end of development.

Both concepts have advantages for the development of applications: it is simply unrealistic for the project team to fully record all requirements at the start of software development. Adjustments that only arise during the course of the project cannot simply be left out. On the other hand, complete flexibility cannot be reconciled with specified delivery dates or predictable budgets. Fundamental requirements for the plannability of projects must be met so that they can be set up and implemented in the corporate environment at all. In order to benefit from the advantages of both approaches, IT managers need to combine the flexibility of agile software development with planning security; they need to tame agility.

Example from the insurance industry

An example from the insurance industry

© Adesso

This map from the 'Interaction Room' illustrates the purpose of the annotations. Highlighted are the annotations for mobility (importance: In cooperation with its brokers, the insurance company should pay particular attention to mobile access to data), framework conditions (importance: When transferring statistical data to the German Insurance Association, the insurance company must ensure that it complies with the legal requirements regarding data protection) and security (importance: There is still room for improvement regarding data security in the internal processing of policyholder data).

Author:
Prof. Dr. Volker Gruhn is Chairman of the Supervisory Board at Adesso.