## 3 A Model of Deployment-Independent, Self-Organizing, Cyber-Physical Systems
### Platform System and Deployment as a Cyber-Physical Mapping  
We represent the platform as a collection of physical _hosts_, connected by a possibly dynamic graph of _physical network links_, representing communication channels connecting a source host with a target host. A host is an entity with a _network identity_ (e.g., a URI resource or an IP address); it can be, e.g., a computer system, a device holding a sensor, an actuator, a virtual machine, or a software container. The actual nature of the communication channel may also vary as well, depending on the network architecture and protocols. The sole relevant property is the availability of a directional channel allowing for application-level communication. Additionally, we distinguish: _thin_ hosts, which are resource-constrained and may host sensors/actuators but not computations; from _thick_ hosts, which instead can compute and may even do so on behalf of multiple logical devices.  
We then define a deployment as an _allocation map_ placing logical components of each device to specific hosts in the platform system, the arranging platform-level connections to support expected logical connections. An example of a deployment is pictorially shown in Figure 3. For simplicity in presentation, we assume that all the sensors and all the actuators of a device are deployed together (into a single \(\sigma\)- and \(\alpha\)-component), though individual sensors and actuators may potentially be placed to different hosts. In Figure 4, we provide examples of _notable deployments_, showing a progression where increasing numbers of responsibilities are centralized (e.g., to a cloud or fog service layer). Of course, depending on the specifics of the actual system being deployed, some cyber-physical mappings may not be actually supported by the platform. For instance, in sensor networks whose sensing devices are designed to operate for a long time using solely battery power, such devices may not be equipped with enough computation power to host a \(\beta\)-component, making the deployment depicted in Figure 4a practically unfeasible.  
Figure 4: Examples of notable deployments. Refer to Figure 3 for a legend of the graphical symbols. (**a**) Peer-to-peer style; (**b**) Broker-based, as found in IoT publish/subscribe protocols (e.g., MQTT); (**c**) Big data in the cloud; (**d**) Thin hosts with only sensors/actuators.  
Figure 3: Example instantiation of the CPS model. Dotted graphical elements denote logical components/connections, while solid-line elements denote platform or physical components/connections. Different subscripts (or colors) map to different logical devices. Intra-device connections (Figure 2) are not shown but they can cross host boundaries by following direct host-level links.  
Details on _how_ to perform the mapping of a dynamic logical system upon a changing network of hosts go beyond the scope of this work. Possible approaches from literature are, e.g., in the context of _virtual network embedding_[65]. A further opportunity enabled by the proposed model is _self-(re)configuration_: i.e., the autonomous process by which the platform system (re)arranges components and connections into new deployment configurations. This is a very interesting and important direction for future work.