The UK engineering population is currently unprepared
for large-scale, complex IT projects, Stuart Jobbins from Rolls
Royce told attendees at a recent BCS Thought Leadership
debate.
Definitions of complex systems have to incorporate the numbers
game. The higher the number of technical parts and people involved,
the more likely a system is to be complex. With complex systems,
one can see the final result, but it is becoming increasingly
difficult to see or understand the inner workings of such a system,
attendees heard.
From a real-time-controls perspective, complexity jumped in the
move from linear (continuous) systems, with their inherent
constraints, to the realisation of these systems by digital
construction, which allowed us arbitrary and discontinuous
relationships. This was the liberating step for flexibility - but
the precipice with regards complexity.
There is complexity in requirements, as well as within the IT
systems themselves. Therefore, there is a need to be able to define
the limits of projects. Civil engineers have developed the role of
architect and IT modelling can be compared with this.
Unfortunately, real life is not simple. For example, attempting
to real-time model a simple fuel injector, across hydraulic,
electro-magnetic and mechanical domains, would involve not only the
complex interaction of the systems in terms of actuation response,
but the environmental factors, (temperature, pressure), along with
the dynamic changes caused to these parameters during actuation, as
well as mechanical wear-out, drift, original manufacturing
tolerance compensation and lots more.
Synthetically trying to replicate the physical world will always
be constrained by the technology available. Even if we could
sufficiently synthesise the behaviour without introducing error, we
would still have to live with the approximation errors, rounding,
and so on, of the underlying machines, speakers at the event
said.
The "capability" growth of electronics, from a reliability
standpoint, but more significantly from a computation standpoint,
has enabled engineers to provide solutions that increasingly
improve the fidelity of the required operation - a direct factor in
increasing system complexity - and allowed us to push the
boundaries of a system's operating efficiency.
Complexity continues to grow. In automotive engine control,
complexity has been doubling every four years since the advent of
electronic control, irrespective of the mitigating actions to
simplify. In aircraft engine control, the doubling takes seven
years.
Most unreliability in software stems from the interaction of
relatively simple components in emergent behaviours, such as the
system that is exercised through contexts that the designer had not
predicted, or foreseen.
Simple solutions are characterised by a small number of
well-defined interfaces and coherent interface policies. Reliable
systems tend to be simple (easy to validate) and the product of a
uniform development philosophy (usually stemming from a single
corporation, team, or even designer).
In terms of a development process for complex systems, there
seems to be clear evidence that the successes are based on
incremental or evolutionary approaches to a solution rather than
revolutionary ones. Even revolutionary systems are often best
achieved by incremental developments, in that we usually phase the
project to first establish a framework, then some elements of a
functioning system and then build towards full functionality.