by Geoff Coulson, Andreas Mauthe and Markus Tauber
The world’s computing infrastructure is becoming increasingly differentiated into autonomous sub-systems (e.g., IoT installations, clouds, VANETs), and these are often composed to generate value-added functionality (systems of systems). But today, system composition is carried out in an ad-hoc, system-specific, manner, with many associated disadvantages. We need a generalized system-of-systems-oriented programming model that allows systems to be composed by application-domain ex-perts, not just systems programmers. Furthermore, composition should occur in a principled way that generates well-understood compositional semantics and behaviour.
Today’s distributed computing environment is becoming increasingly diverse and differentiated in nature, to the extent that the world’s computing infrastructure is now far removed from the traditional picture of desktop PCs connected via fixed IP networks. The picture today includes: IoT infrastructures such as smart cities and buildings; environmental sensor and actuator networks using non-IP protocols; cloud systems based on clusters; ad-hoc networks such as MANETs and VANETs; and virtualized systems supported by network overlays. Furthermore, these various ‘systems’ increasingly need to interact with and respond to each other, typically in a dynamic on-demand manner. For example, WSNs need back-end clouds to process sense data, VANETs need to interact with smart cities when upon entry to the city, and overlay-based systems need to maintain resilience properties when their underlying IP environment changes.
This is all leading to a world-view in which we need to be increasingly concerned with composing systems to build systems of systems [1]. Although this fact is becoming recognised in many research communities, surprisingly little work has been done on programming environments to facilitate system-of-systems composition. Instead, system composition is carried out using ad-hoc interfaces, and relies on detailed knowledge of the internals of the systems being composed. We argue that a generalised programming and modelling approach is urgently needed to enable the full fruition of the emerging system-of-systems world.
We are currently developing such a system-of-systems-oriented programming model. A key aspect of our approach is to assume that systems are self-contained, and that they interact and compose opportunistically. In this way, we see systems of systems emerging spontaneously as a result of opportunistically-arising, mutually-beneficial, time-bounded alliances between systems that dynamically discover potential partner systems in their environment. Examples of such opportunistic interactions/compositions include: i) exchange of traffic information between passing vehicles; ii) isolated islands of connectivity discovering a delay-tolerant overlay network through which they can interact; iii) opportunistic cross-layer optimization involving layers on different systems that happen to come in range of each other; and iv) a networked team of rescue workers dynamically interfacing with a local hospital’s systems. The general pattern is one of loosely-coupled interaction between autonomous systems triggered by relevant events (e.g., proximity).
Our programming and modelling approach is based on a first-class programmatic abstraction of a ‘system’, which we refer to as a tecton. Essentially, a tecton is a distributed abstraction/representation of a self-contained, potentially-opportunistically-interacting, multi-node distributed system. It is intended that tectons are used uniformly to abstract the full range of ‘systems’, whether wired/wireless, fixed/mobile, large/small, static/ dynamic, low-level/high-level – e.g., user groups, MANETs, clusters, clouds, overlays, VPNs, sensor networks, or even (on a more ‘micro’ scale) devices that can plug-and-play with other devices.
The purpose of the tecton abstraction is to manage opportunistic interaction. This is achieved by providing tectons with programmatic condition-action rules that trigger when the tectons (or, more precisely, some of their nodes) come into contact, and determine under what circumstances and in what manner an interaction or composition should occur. This applies in both a horizontal and a vertical sense, involving (respectively) interactions between peer systems, and cross-layer interactions.
As an example, we might program a MANET tecton by (essentially) saying “IF any of the nodes in this MANET tecton come into contact with an 802.11 network tecton, THEN all its nodes should reconnect to their email servers via this node”. By extrapolating from this example of vertical composition, it can be seen that condition-action rules enable the tecton programmer to specify, in a very general way, what should be done when one system encounters another. In summary, we envisage the whole process of developing, deploying and managing systems of systems as amounting to a process of defining horizontally- and vertically-composable tectons along with their associated condition-action rules.
In supporting the tecton abstraction, we have defined a layered architecture consisting of a Domain Specific Language/ Ontology layer over a distributed tecton runtime layer. The upper layer is motivated by the fact that a single set of programming language concepts is unlikely to be acceptable, given the intended generality of the tecton approach. Instead, we look to support multiple programming tools that capture concepts of relevance to the domain of application. For example, a systems programmer working with network-level tectons might expect a DSL based on library calls embedded in C; whereas a building manager working with tectons that represent things like “all the windows on this floor” or “the group of today’s visitors” may prefer a scripting or graphical approach. Similarly, the extreme variance in domains of application dictate that the basic information concepts of interest to the programmer will vary according to the domain of application. Our approach here is to employ ontologies to structure these concepts.
The distributed tecton runtime offers an API that enables client code to carry out fundamental operations such as creating/destroying tectons, managing their node membership, setting the criteria for inter-tecton “contact”, and coordinating the consequent action (e.g. interaction, composition, etc.). For example, setting the criteria for “contact” is achieved by providing the runtime with a predicate over ontology-derived <name, value> pairs. The runtime monitors these values in its distributed environment and triggers the corresponding action when the predicate “fires”.
We are at the beginning stage of the development of the tecton concept, but are currently applying it in a CHIST-ERA project that investigates interoperable overlay networks and also in an IoT-based en-vironment involving both WSNs and cloud infrastructures.
Link:
CHIST-ERA: http://www.chistera.eu/projects/dionasys
Reference:
[1] M. Maier: “Architecting Principles for System of Systems”, Systems Engineering 1 (4): pp 267–284, 1998.
Please contact:
Geoff Coulson, Andreas Mauthe
Lancaster University, UK
E-mail:
Markus Tauber
AIT Austrian Institute of Technology, Austria
E-mail:
