System Behaviour Complexity

Your car is a cyber-physical system. You’re driving on the highway. The engine is powering the wheels through the drive train and the car is responding to the controls: that’s the core automotive behaviour. Cruise control is active; air conditioning is cooling the cabin; the lane departure warning feature is monitoring the car’s position in the lane; anti-skid braking is ready to avoid wheel lock in an emergency stop; active suspension is smoothing out bumps and maintaining safe attitude in acceleration and cornering. These are concurrent constituent behaviours of the complex system behaviour.

Other constituent behaviours are not active right now: the car can park itself automatically; a speed limiting feature can override reckless driving; stop-start can save fuel, turning off the engine when the car halts and restarting automatically when the driver wants to move away; each regular driver’s chosen settings of seat, wheel, and mirror positions can be saved, and restored automatically when the driver’s personal ignition key is used on another occasion. These too are constituent behaviours, available to contribute to the complex behaviour of the whole system.

Your car is just one vivid illustration: complex system behaviour structured from simpler behaviour constituents is characteristic of realistic cyber-physical systems—aircraft, process plants, railway interlocking, even medical infusion pumps. In these complex behaviours dependability is vital—and demands structure.

For any structure two concerns are basic. First: how should we choose and construct the parts? Second: how should we design the connections between them? In a famous 1975 paper [1], Frank DeRemer and Hans Kron argued that for a large program of many modules programming-in-the-small and programming-in-the-large are distinct intellectual activities. For developing complex system behaviour the same argument is compelling. Behaviour-design-in-the-small identifies and develops individual constituent behaviours. Behaviour-design-in-the-large structures their relationships and interactions. These are distinct tasks.

Design-in-the-small should precede design-in-the-large both in exposition and practice. It is by stipulation simpler, allowing earlier discovery of defects of many kinds. Design-in-the-large is about combining parts, and it is folly to address combination before achieving understanding of the parts to be combined (this is why top-down design so often fails). In a constituent behaviour intrinsic and combinational sources of complexity can be carefully separated, giving a substantial benefit both to its developers and to participants in its enactments.

[1] Frank DeRemer and Hans Kron; Programming-in-the-large versus Programming-in-the-small; IEEE Transactions on Software Engineering Volume 2 Number 2, pages 80-87, June 1976.

Links to other posts:
 ↓ Triplets:  Triplets are system behaviour elements: (Machine+World=Behaviour)