What is a rebound effect and how can it be avoided?

A so-called rebound effect is given when, in the case of a complex system, the opposite will be achieved of what has been aspired and expected, even the planning and development has been done in an ostensible qualified and successful way. If even dedicated damage is produced, it is called backfire effects.

For illustration, here are some examples of rebound effects:

  • After the improvement of a traffic light and traffic controls, even more traffic jams occur after a short improvement phase than before. In this case, road users notice that the usual traffic jam is no longer taking place due to the improvement measures. As a result, however, more road users will drive the route, who had previously sought alternative routes or other modes of transport, so that in the end, despite improved traffic regulations, more traffic jams arise. The improved flow induces a significant increase in inflow, which overcompensates the flow improvement.
  • A new vehicle safety system leads to overcompensation by causing drivers to move beyond their own driving limits in the (possibly misunderstood) awareness of the existing safety system and relying on this safety system. This may cause new accidents that would not have occurred without the system due to more defensive driving.
  • Knowing that automated vehicles are braking in front of them, pedestrians are once again becoming more careless when crossing roads, causing new accidents that cannot necessarily be prevented even by the best possible automated vehicles.
  • Automated vehicles take their passengers from A to B so comfortably and (individually) efficiently that no one uses public transport, which would be the more effective mode of transport in the case of large and homogeneous passenger demands.
  • When introducing new alternative, advanced propulsion systems, sometimes only the operation of the vehicle under certain operating conditions is assessed. However, due to more complex manufacturing and disposal processes and/or in more frequent unfavourable operating conditions, the balance sheet becomes worse when assessing the entire life cycle from the "cradle to the grave". In the end even more energy may be needed or more pollutants are produced.
  • The insurance classification of vehicles with collision avoidance systems should actually be made more favourable because of the collisions that have been avoided. However, if collisions occur nevertheless, the repair costs are much higher because of the damaged ambient sensors and electronics instead of simple sheet metal damage. These costs of damage can lead to a higher insurance classification, because the risk estimate (risk equals probability of occurrence times damage costs) reduces the probability of occurrence, but the costs overcompensate for this improvement.
  • Purchasers of engineering and software services are pushing down the hourly rates in such a way that the service provider can only use less qualified employees, which ultimately leads to significantly higher costs and risks in the overall project, because they do not have sufficient experience and/or qualification to effectively execute complex projects and developments. Especially in software development, performance and qualification are not linear and uniformly distributed, so exponential rebound effects can occur depending on the complexity of the task.
  • In general, in certain circumstances, superficial efficiency improvements can lead to losses of effectiveness, which, taken as a whole, lead to a noticeable deterioration.

Reasons for Rebound Effects

The main causes of rebound effects are:

  1. In the case of complex systems, significant influencing factors and/or effects in the development of solution measures are overlooked or misjudged, so that they superimpose and/or overcompensate for the effects of the solution used in real operation.
  2. In the development of a complex system, simplified assumptions are made about boundary conditions or operating loads which have not been validated or which subsequently prove to be incorrect.
  3. The system boundaries have been defined too narrow during development, so that overarching influencing factors are not taken into account in the actual operation of the system(-of-system).

Very often such reasons depend on human factors and interactive behaviours with surrounding objects and/or with the system users, when the reactors of humans in and with respect to the systems are considered inadequately or estimated incorrectly.

Countermeasures

The fear of rebound effects should not hinder to tackle complex problems. There are numerous countermeasures available, which help to avoid or mitigate rebound effects.

  • The first essential measure is interconnected system thinking and a systematic approach in development, in which ideally a sufficiently wide range of multidisciplinary experts and specialists are involved in system development. In addition to engineers, psychologists, empiricists, human machine interface or usability experts and similar know-how carriers should also be involved in the development, depending on the application, in order to identify and take into account all system effects as far as possible.
  • The use of digital twins and simulation models in combination with scenario management allows the investigation and identification of a wide range of influencing factors and system dependencies, so that fewer surprises can be expected in operation. In combination with data-based development approaches, corresponding system know-how can be quickly set up, captured and validated.
  • Normally, "human factors" can only be captured empirically. Data-based development with systematic connection to real test environments or test fields for validation in real operation is a measure to capture changing patterns of interaction and behaviour and to derive realistic models for development.
  • Ideally, the data-based approach is continued not only in real-world testing but also in operation with connected functions. Rebound effects can also begin creepingly and take effect only after longer periods of time.
  • If the test and operational deployment is accompanied by an automated anomaly, fault and change detection, rebound effects can be identified early in order to initiate possible countermeasures in good time.
  • The developments and operations should be accompanied with continuous effectiveness assessments.
  • In order to have the degrees of freedom in systems to react to rebound effects, they should be equipped with adaptation capabilities and sufficient flexibility if possible.
  • Since these measures look partly a-priori after higher development costs (which are, however, far lower than the costs and risks of the rebound effects), a realistic assessment of the complexity of the task and the selection of measures based on it is of high importance. With bottom-up developments (in which existing, simple solutions are constantly being expanded), there is a greater risk that the rebound effects will occur creepingly and eventually lead to a total "complexity lock" than with a top-down approach, in which all conceivable influencing variables and effects are already taken into account in the basic concept and remain deactivated in real operation.

Last update on 2020-11-26 by Andreas Kuhn.

Go back