Physical Bipartite System

The essential structure and behaviour of a physical bipartite system are shown in this diagram:

The solid rectangles represent the system S and its parts—the machine M and the governed world W. The stripes on the M rectangle indicate that M is the machine, executing software designed to achieve the system's purposes. The solid line A represents the physical interface at which M and W interact. Behaviours of the machine, the governed world, and the system comprising them are represented by the named dashed ellipses.

Focusing attention on certain aspects of the physical system while purposefully ignoring others, this view helps to structure the work of development, understanding, and analysis. Specifically, it shows that we regard the machine and the governed world—the two parts of the bipartite system—as physically disjoint. The interface A is not itself a distinct physical object. It is a collection of individual ports, channels, variables, sensors and actuators, each belonging physically either to M or to W but not to both. Physical interactions taking place between M and W are mediated by these parts of A.

Internally, the machine and the governed world are structures of interacting entities or domains. The machine may be distributed over all or part of several physical computers, each having physically distinct parts—for example, an ALU (arithmetic and logical unit), registers, and a store. The governed world of a lift system has lift shafts, floors, doors, hoist motors and cables, and sensors and switches—but not only these. To understand a behaviour we must consider all its participant domains: so the lift passengers, engineers and inspectors are also governed world domains.

The domains of the machine and of the governed world provide the infrastructure necessary for enacting their respective behaviours. Behaviours are temporal structures of phenomena—events and state values and changes—occurring within and between domains. For example: a passenger presses a button; a lift car stops rising and halts at a floor; a register value is copied into a store location; a program instruction is fetched for execution by the CPU; and so on. The domains with their occurring phenomena, and relationships among them, are the basic subject matter of system development, and therefore of the models that software engineers must make.

The behaviours represented by the ellipses are enacted by the system in operation. The behaviour B whole behaviour of the bipartite system. P and G are projections of B, restrictions respectively to phenomena of the machine and of the governed world. While insisting on the unity of the bipartite system we recognise the significance of these projections. In general, stakeholder requirements do not concern the machine: they concern the governed world and some of its wider effects and consequences. The complementary supposition—that the proper focus of software engineering concerns is the machine alone—is a crippling mistake.

Links to other posts:
 → Cyber-Physical Systems:  The essential character of a cyber-physical system
 → System Behaviour Complexity:  The component structure of system behaviour
 → Triplets:  Triplets (Machine+World=Behaviour) are system behaviour elements