Not Just Physics

To develop cyber-physical system behaviour is to program the whole bipartite system—both the software machine and the physical world whose behaviour it governs. To ensure desired behaviour of the machine, programmers must know its given properties—the hardware architecture and instruction set and the programming language semantics. This knowledge amounts to an axiomatic model of the machine: the axioms state those properties that determine the machine's behaviour in executing its software.

What axioms ensure desired behaviour in the governed world in its interaction with the machine? At first sight, they must be sought in the laws of physics. The natural laws discovered by scientists—from particle physics to chemistry, mechanics, and thermodynamics—describe what is physically possible in the world. But in fact physics is not nearly enough to provide the necessary axioms. Why not?

A cyber-physical system is what the physicist and chemist Michael Polanyi [1,2] calls a contrivance; its components—the machine and the physical domains of the governed world—work together to serve human purposes. Possible behaviour is restricted at two levels. The lower level reflects the physical laws that restrict possible behaviour by equations relating natural phenomena at many granularities—from particle interactions to conservation laws. The upper level reflects the system's purposes and the designed operational principles by which those purposes are achieved. At this upper level the shapes and combinations and interactions of the system's physical domains further restrict behaviour by determining temporal and spatial configurations within which the effects of distinct natural laws are combined, and by setting boundary conditions for applying their equations.

Nature's laws are not flouted: the upper level does not introduce anarchy, and the laws of physics continue to hold. But what happens within those laws is constrained by the implemented operational principles of the contrivance expressed in terms of the upper level. Those principles must be devised—and reasoned about—in terms of concepts that are foreign to the discourse of the laws of physics. First, because the operational principles of physical contrivances rest on the concept of causality. Newton expressly rejected causal explanation of his gravitational law: he insisted that he was describing only what happens, not why or how it happens [3].

Second, because reasoning about operational principles in terms of the laws of physics and of the boundary conditions for each local and each combined application of each law would be impossibly complex and voluminous. The physical domains of the governed world—whether natural, or engineered, or evolved by chance processes—are typically heterogeneous, mutable, very irregularly shaped, deeply structured, and richly interconnected both horizontally and vertically. For devising, exploring, and reasoning about these domains it is necessary to adopt informal abstractions at the scale and granularity of the operational principles. Certainly, natural laws limit what the operational principles can hope to achieve; and they may often be invoked to explain particular failures. But the necessary axiomatic models of the governed world must be sought elsewhere, in more than physics.

[1] Michael Polanyi; The Tacit Dimension, pp39-40; U Chicago Press, 2009.
[2] Michael Polanyi; Personal Knowledge, pp331-332; U Chicago Press, 1974.
[3] Richard Feynman; The Character of Physical Law, pp55-6; Penguin Books, 1992.

Links to other posts:
 ↑ Cyber-Physical Systems: The essential character of a cyber-physical system
 → More than Physics: Finding and structuring axioms for the governed world behaviour
 → Axiomatic Models: Capturing basic assumptions for a behaviour

Landscape At a Distance

The landscape is what we choose to see when we look out at the physical universe from our particular point of view. We structure and interpret our view of the landscape according to our needs and purposes. For software engineers working on a cyber-physical system the landscape can look like this:

The bipartite system is the central landscape feature: its two parts are the machine and the governed world, interacting at the interface labelled a.

The machine is the computing equipment we introduce into the world. It may be all or part of several computers, but in earlier development stages we see it as one computing machine, in which we structure software to reflect behaviour system behaviour structure. Software deployment on physical computers must wait to a later stage.

The governed world contains parts of the physical world whose behaviour is governed by the machine executing the software we develop. In a critical system, the governed behaviour is the critical dependable behaviour for which the software engineers take full professional responsibility.

The requirements world is those parts of the world in which stakeholders' requirements stipulate effects and consequences that the desired system behaviour must produce. It does not include the machine, which is instrumental in satisfying the requirements but is not itself directly subject to stakeholder requirements. It includes the governed world, but it also includes behaviours to satisfy requirements that resist formal treatment—for example, ecological, social and economic concerns—and whose satisfaction is therefore not guaranteed.

The environment is the universe beyond the machine and the requirements world, extended both in space and time. Inescapably, any system is designed only for an environment niche, where enough of its design models and assumptions are valid to allow continued operation. For example, an automotive system cannot operate underwater or in an earthquake. A critical system may demand the largest possible niche, to allow survival—albeit with reduced functionality—even in extremely adverse conditions. The niche for the Fukushima nuclear plant allowed for both earthquake and tsunami, but in 2011 both occurred together, leading to a nuclear disaster.

The very terse summary in this post gives only a distant view of the environment, raising many questions but answering none of them. Some answers are given in another post that looks a little closer and a little deeper.

Links to other posts:
 →  Landscape Close-Up:  A closer view of the universe as seen by a software engineer

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