Between the machine and the governed world the sensors and actuators provide an Application Programming Interface—an API. Where is the API manual? You have to write your own, piecing it together from information about the infrastructure of the world—the physical domains and their properties and interactions. This manual will be an axiomatic model. It's axiomatic because it records the assumptions that you have decided not to question. It doesn't describe the machine or the governed behaviour: that is the role of a behavioural model that will rely on your axiomatic model exactly as a program relies on the programming language manual. The axiomatic model describes the physical domains and—crucially—their causal links in the governed world by which the desired behaviour can be woven together and connected to the API.
What can be assumed? What can be taken as axiomatic? The laws of physics, certainly. But they are far from sufficient. Physical laws say nothing of causality. For most reasoning about governed world behaviour their scale is either too small—particle physics—or too broad—conservation of energy. At the relevant intermediate scales physical domains are irregularly shaped and structured; they are mutable and richly connected, and each is host to the interacting effects of many natural causes. Abstractions of the domains and their causal properties are inescapably informal and imperfect: everything is approximate, and nothing is unconditionally true.
In short, the task in hand is engineering, not science: the scientist's scope is the universe, but the engineer's is a specific system, narrowly bounded in space and time. This narrow bounding gives a vital clue to addressing the difficulty of cyber-physical behaviour design: there must be many axiomatic models, and their scopes must be narrow. First, system behaviour is a structure of constituent behaviours. An approach based on triplets associates a distinct axiomatic model with each distinct behaviour: the assumptions are chosen only to support the associated behaviour, and are assumed to hold only while it is enacted. Second, each causal link is explicitly attributed to a specific effectuating domain of the governed world, reflecting the operational principle [1,2] of the behaviour design. This attribution focuses the search for threats to validity of the assumed link, and sharpens and enlivens analysis of potential and actual failures. Third, in the development task of combining concurrent constituent behaviours, their axiomatic models highlight the assumptions of each that may cause interference or conflict in combination. Fourth, a critical system must maintain operation in the face of increasingly adverse conditions. For each new adversity a different behaviour, often with degraded function, may be enacted: such degraded behaviours depend only on their newly reduced axiomatic assumptions. Unlike the universal laws of physics, axioms for engineering must be local.
The fundamental expression of an operational principle—how a designed behaviour works—is in its assumed causal links. Clarity about the assumed domain properties and links depends directly on a clear separation of axiomatic and behavioural models.
[1] Michael Polanyi; The Tacit Dimension, pp39-40, U Chicago Press, 2009.
[2] Michael Polanyi; Personal Knowledge, pp328-329, U Chicago Press, 1974.
Links to other posts:
↑ Not Just Physics: Software Engineering's unique view of the physical world
↑ Physical Bipartite System: The nature of a bipartite system
← Causality: Causality is the explanation of how a system works
← Triplets: Triplets (Machine+World=Behaviour) are system behaviour elements
No comments:
Post a Comment