Distributed Air & Missile Defense with Spatial Grasp Technology ()
1. Introduction
1.1. Air & Missile Defense as Large Distributed Systems
Air and missile defense capabilities are growing globally and at a fast rate [1,2]. They are supported by novel technologies for detection, tracking, interception and destruction of attacking missiles. These systems are usually distributed on large territories, consist of many interacting elements (from sensors to shooters, see some related snapshots in Figure 1), and are expected to work in complex conditions to effectively protect national and international infrastructures and withstand unpredictable events.
1.2. Traditional Path in System Development
Originally a new system or campaign idea (related to air & missile defense incl.) emerges in a very general, integral form, as shown symbolically in Figure 2(a). Then it is mentally decomposed into parts, each subsequently detailed, extended, and clarified, as in Figure 2(b). Next step is materialization of the clarified parts and their distribution in physical or virtual spaces. To make these parts work together as a whole within the original idea, a good deal of their communication, synchronization, and sophisticated command and control are usually required, as shown in Figure 2(c).
For a military area, Figure 2(a) may correspond to the general idea of winning a battle over an adversary or defending a critical infrastructure; Figure 2(b) additionally clarifies technical and human resources needed for this; and Figure 2(c) depicts how these resources should be organized together within a workable system (command and control including) fulfilling the global objectives.
The original idea, Figure 2(a), and even its logically partitioned stage, Figure 2(b), usually remain in the minds of creators and planners only (possibly also being verbally or graphically recorded in an informal manner), whereas actual system formalization and implementation begin from the already partitioned, distributed and interlinked stage, Figure 2(c). So in reality we have mostly bottom up, parts-to-whole strategy in actual system design, in hope that the system developed will be ultimately capable of performing the initially formulated global task, i.e. of Figure 2(a).
1.3. Existing System Design & Implementation Problems
• Within the philosophy mentioned above it may be difficult to put the resultant distributed system with many interacting parts into compliance with the initial
Figure 1. Some snapshots of air & missile defense systems.
Figure 2. Traditional approach in system design and management: (a) original idea; (b) breaking into pieces; (c) system formalization, distribution, and implementation.
idea.
• The resultant system may have side effects, including unwanted ones, like unpredictable behaviors.
• The resultant solution may be predominantly static, i.e. if the initial idea changes, the whole system may have to be partially or even completely redesigned and reassembled.
• Adjusting the already existing multi-component system designed for one idea to an essentially new one may result in a considerable loss of the system’s integrity and performance.
1.4. The Alternative Approach Offered
In this paper, we propose formalization of the initial stage a of Figure 2 (and if needed, stage b) in a way that can be easily updated or even fully changed, with shifting most of stage b and completely stage c to an automated up to fully automatic implementation (incl. effective robotization). This can result in high flexibility, productivity, and self-recoverability from damages in conducting advanced campaigns, military ones including, where local and global goals as well as environments can change at runtime.
The developed (prototyped and tested in different countries) Spatial Grasp Technology (SGT) and its underlying Distributed Scenario Language (DSL) with details of their distributed implementation in networked systems are briefed in this paper along with application examples related to distributed air and missile defense (for existing basic publications on this paradigm see also [3-6]).
2. Grasping Solutions with Spatial Waves
The model described here reflects higher-level, holistic, gestalt-like vision and comprehension of distributed systems by human brain in the form of parallel mental waves covering and grasping the space [7-9] (Figure 3(a)) rather than traditional collection and interaction of parts or agents [10] on which most of existing software systems are based.
The original system idea of Figure 2(a) is represented in an integral non-atomistic but at the same time fully formal way, reflecting how a human commander mentally observes the space where a problem is to be solved. Traditional atomism emerges only during interpretation of this formally represented idea (which may be automatic, and only when really required). This allows us to get flexible and easily changeable formal definition of systems and operations in them while omitting traditional numerous organizational details, such as in Figure 2(c), effectively concentrating on global goals and behaviors instead.
Materialization of this approach is carried out by the network of universal intelligent modules (U) embedded into important system points, which collectively interpret integral mission scenarios expressed in the waves formalism (starting from any point and covering the distributed system at runtime, as in Figure 3(b)). Different scenarios can start from the same or different points, and can cooperate or compete in the networked space as overlapping fields of solutions.
The compact spreading scenarios, which can be created and modified on the fly (being up to a hundred times shorter than, say, in Java) are forming dynamic knowledge infrastructures arbitrarily distributed between system
(a) (b)
Figure 3. The waves paradigm: (a) controlled grasping of distributed worlds with spatial waves; (b) self-evolving highlevel wave-like mission scenarios in distributed networked environment.
components (humans, robots, sensors). Navigated by same or other scenarios, they can effectively support distributed databases, advanced command and control, also provide overall situation awareness and autonomous decisions.
3. Distributed Scenario Language
DSL is quite different from traditional programming languages. Rather than describing data processing in a computer memory, as usual, it allows us to directly move through, observe, and make any actions in fully distributed environments (whether physical or virtual).
3.1. The Worlds DSL Operates with
DSL directly operates with:
• Virtual World (VW), which is finite and discrete, consisting of nodes and semantic links between them.
• Physical World (PW), an infinite and continuous, where each point can be identified with physical coordinates (with a certain precision).
• Virtual-Physical World (VPW), being finite and discrete similar to VW, but associating some or all virtual nodes with PW coordinates.
3.2. Main DSL Features
Other DSL features can be summarized as follows:
• A scenario expressed in it develops as a transition between sets of progress points (or props) in the form of parallel waves.
• Starting from a prop, an action may result in one or more new props.
• Each prop has a resulting value (which can be multiple) and resulting state, being one of the four: thru (full success allowing us to proceed further from this point), done (success with termination of the activity in this point), fail (regular failure with local termination), and abort (emergency failure, terminating the whole distributed process, associated with other points too).
• Different actions may evolve independently or interdependently from the same prop, contributing to (and forming altogether) the resultant set of props.
• Actions may also spatially succeed each other, with new ones applied in parallel from props reached by the preceding actions.
• Elementary operations can directly use local or remote values of props obtained from other actions (the whole scenarios including), resulting in value(s) of prop(s) produced by these operations.
• These resultant values can be used as operands by other operations in an expression or by the next operations in a sequence (the latter can be multiple, if processes split). These values can also be directly assigned to local or remote variables (for the latter case, an access to these variables may invoke scenarios of any complexity).
• Any prop can associate with a node in VW or a position in PW, or both (when dealing with VPW); it can also refer to both worlds separately and independently.
• Any number of props can be simultaneously associated with the same points of the worlds (physical, virtual, or combined).
• Staying with the world points, it is possible to directly access and update local data in them.
• Moving in physical, virtual or combined worlds, with their possible modification or even creation from scratch, are as routine operations as, say, arithmetic, logical, or control flow of traditional programming languages.
• DSL can also be used as a universal programming language (similar to C, Java or FORTRAN).
3.3. DSL Syntax and Main Constructs
DSL has recursive syntax, represented on top level as in Figure 4 (programs are called grasps, reflecting their main semantics as gasping and integrating distributed resources into goal-driven systems).
The basic construct rule can represent any definition, action or decision, for example:
• elementary arithmetic, string or logic operation;
• hop in a physical, virtual, or combined space;
• hierarchical fusion and return of (remote) data;
• distributed control, both sequential and parallel;
• a variety of special contexts for navigation in space, influencing operations and decisions;
• type or sense of a value, or its chosen usage, guiding automatic interpretation.
3.4. DSL Spatial Variables
There are different types of variables in DSL:
• Heritable variables—these are starting in a prop and serving all subsequent props, which can share them in both read & write operations.
Figure 4. DSL recursive syntax and main constructs.
• Frontal variables—are an individual and exclusive prop’s property (not shared with other props), being transferred between the consecutive props, and replicated if from a single prop a number of props emerge.
• Environmental variables—are accessing different elements of physical and virtual words when navigating them, also a variety of parameters of the internal world of DSL interpreter.
• Nodal variables—allow us to attach an individual temporary property to VW and VPW nodes, accessed and shared by props associated with these nodes.
These variables, especially when used together, allow us to create efficient spatial algorithms not associated with particular processing resources, working in between components of distributed systems rather than in them. These algorithms can also freely move in distributed processing environment (partially or as a whole), always preserving integrity and overall control.
DSL also permits the use of traditional operational symbols and delimiters, to simplify and shorten programs, if this proves useful.
4. Distributed DSL Interpreter
4.1. Structure of the Interpreter
The DSL interpreter [4-6] (see Figure 5) has the following key features:
• It consists of a number of specialized modules working in parallel and handling and sharing specific data structures supporting persistent virtual worlds and temporary hierarchical control mechanisms.
• The whole network of the interpreters can be mobile and open, changing at runtime the number of nodes and communication structure between them.
• Copies of the interpreter can be concealed, as for acting in hostile systems, allowing us to impact the latter overwhelmingly (finding & eliminating unwanted infrastructures including).
4.2. Distributed Track System
• The heart of the distributed interpreter is its spatial track system (Figure 6) with its parts kept in the Track Forest memory of local interpreters; these being logically interlinked with such parts in other interpreter copies, forming altogether indivisible space coverage.
• This enables hierarchical command and control and remote data and code access, with high integrity of emerging parallel and distributed solutions, without any centralized resources.
• The dynamically crated track trees spanning the systems in which DSL scenarios evolve are used for supporting spatial variables and echoing and merging different types of control states and remote data, being self-optimized in the echo processes.
• They also route further waves to the positions in physical, virtual or combined spaces reached by the previous waves, uniting them with the frontal variables left there by preceding waves.
4.3. DSL Interpreter as a Universal Spatial Machine
The (dynamically) networked DSL interpreters (Figure 7) are effectively forming parallel spatial machine (“machine” rather than computer as it operates with physical
Figure 5. Organization of DSL interpreter.
(a) (b)
Figure 6. Distributed track system: (a) forward operations; (b) backward operations with tracks optimization.
Figure 7. DSL interpretation network as a universal parallel spatial machine.
matter too, and can move partially or as a whole in physical space) capable of solving any problems in a fully distributed mode, without any special central resources.
5. Elementary Programming Examples
We will show here elementary examples of solution in DSL of some important problems on distributed structures in a parallel and fully distributed way, where each node may reside in (or associate with) a different computer. These tasks may well relate to the general orientation of this paper on air and missile defense (see also [4, 5]).
5.1. Finding Shortest Path in Parallel
The solution for finding shortest path between two nodes (let them be a and e) can be expressed by DSL scenario that follows.
frontal (Far, Path);
sequence (
(hop (‘a’); Distance = 0;
repeat (hop(alllinks); Far += LINK;
or (Distance == nil, Distance > Far);
Distance = Far; Before = BACK)) (hop (‘e’);
repeat (Path = NAME & Path; hop(Before));
output (Path)))
The result obtained in node a for the network in Figure 8 will be (a, b, d, e). It has been found by navigating the network of weighed links in parallel and fully distributed mode, without any central resources.
Many important problems of optimization and control (from battlefields to infrastructure protection) may be expressed as finding shortest paths in distributed spaces. SGT, on the example of this task, can serve as a higher level universal communication protocol [11] capable of organizing any communication, and especially if other means fail during and after indiscriminate damages to infrastructures.
5.2. Analyzing Distributed Structures
Another important problems in distributed systems may be finding weak (or weakest) and strong (strongest) parts in them, whether these are civil or military organizations (say, battlefields in the latter case), and friendly or of adversaries. In the examples below we formulate these two problems on general graphs where any node may be with a different computer (Figure 9).
To find the weakest nodes in a graph, like articulation points, see Figure 9(a), which when removed split it into disjoint parts, the following program suffices (resulting in node d).
hop (allnodes); IDENTITY = NAME; mark;
Figure 8. Finding shortest path in parallel distributed mode.
(a) (b)
Figure 9. Solving topological problems: (a) discovering articulation points; (b) finding cliques.
and ((hop(random, alllinks);
repeat (unmarked; mark; hop(alllinks))),
(hop (alllinks); unmarked),
output (NAME))
Cliques (or maximum fully connected sub-graphs of a graph), on the contrary, may be considered as strongest parts of a system. They all can be found in parallel by the following simple program resulting for Figure 9(b) in: (a, b, c, d), (c, d, e), (d, e, f):
hop (allnodes); Fclique = CONTENT;
repeat (
hop (alllinks); notbelong(CONTENT, Fclique);
and (andparallel(hop(anylink, Fclique)!,
or (BACK > NAME!, Fclique & NAME)));
output (Fclique)
6. Collective Robotics Examples in DSL
Installing DSL interpreter into mobile robots (ground, aerial, surface, underwater, space, etc., as in Figure 10 for the first two) allows us to organize effective group solutions (incl. any swarming) of complex problems in distributed physical spaces in a clear and concise way, shifting traditional management routines to automatic levels.
We will consider two levels: organizing robotic swarms on top semantic level where only global task is formulated (like in Figure 2(a), and all internal system organization is fully delegated to the distributed DSL interpreter), and also expressing some sort of explicit collective behavior (corresponding to Figure 2(b) and partially
Figure 10. Integration of ground and aerial robots in SGT.
Figure 2(c), with the rest of organization of Figure 2(c) delegated to automation).