An application of Answer Set Programming
in Distributed Architectures: ASP Microservices

An important hot topic is, in our opinion, that of defining software engineering principles for Answer Set Programming (ASP). ASP is a successfully logic programming paradigm (cf. [6] and the references therein) stemming from the Answer Set (or “Stable Model”) Semantics of Gelfond and Lifschitz, and based on the programming methodology proposed by Marek, Truszczyński and Lifschitz. ASP is put into practice by means of effective inference engines, called solvers¹¹1Many performant ASP solvers are freely available, a list of them is reported at https://en.wikipedia.org/wiki/Answersetprogramming.. ASP has been widely applied, e.g., to information integration, constraint satisfaction, routing, planning, diagnosis, configuration, computer-aided verification, biology/biomedicine, knowledge management, etc. .

It is important in our view to have the possibility of defining significant subprograms as components to be possibly distributed over different nodes of a network. Both the connections between components and the ways of exchanging information should be clearly defined. Our approach is inspired by the microservices architectural abstraction, which can be described as a particular way of designing distribute software applications as suites of independently deployable interacting services (cf. for instance the survey [27] or see https://martinfowler.com/articles/microservices.html#CharacteristicsOfAMicroserviceArchitecture). A microservice is indeed a component, as it is a unit of software that is independently replaceable and modifiable: in fact, it intended as a self-contained piece of business functionality with clear interfaces that can be accessed by the “external world”. This kind of architectural abstraction enables distribution, as each microservice is meant to be executed as an independent process, and heterogeneity, allowing for different services to be written in different programming languages. Microservices are a suitable architectural abstraction for the Internet of Things (IoT): a microservice may incapsulate a physical objects, where service inputs and/or outputs can possibly be linked to sensors/actuators. Since microservices are by their very nature heterogeneous, open issues are: the way microservices communicate with each other (synchronous, asynchronous, which is the message format, etc.); and, the protocols used for the communication.

Microservices in real distributed software architectures and in cloud computing are usually deployed via lightweight containers. A container in software engineering is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably and can be seamlessly transferred from one computing environment to another. A widely used tool to create containers is Docker, available in the form of an open source Doker Engine (see https://www.doker.com). A Docker container image consists in a lightweight, standalone, executable package of software that includes all elements needed to run an application: code, runtime support, system tools, system libraries and settings.

Along this line, we propose ASP microservices that might be blended into heterogeneous systems, and even into Multi-Agent-System (MAS) since each such component may be seen as a reactive agent. They could in perspective be employed in cloud computing, and in IoT, including robotic applications. In this paper we discuss a first idea about how these components, that we call $\mu$ASP-Services ($\mu$ASPSv’s), can be specified, how their interfaces to the “external world” can be defined, and how they should procedurally behave. In fact, a $\mu$ASPSv is meant to be based upon a ‘core’ ASP program whose activities, however, should be triggered by external stimula/requests coming from some source, and whose results should be returned to the requesters. Therefore, the ‘core’ ASP program should be included into a container, that can be possibly realized via the Docker technology, which should also include: an interface, to provide the $\mu$ASPSv with inputs, and to deliver the outputs; solving capabilities to compute the answer sets. For ASP, standalone versions of the most important solvers are nowadays available. So, a docker deployment for a $\mu$ASPSv should include the source program, its ‘execution shell’, and the solver.

A small specimen of the proposed approach is represented in the following example, which is meant to be (a fragment of) the code of a controller component/agent, acting in the IoT. This piece of code might be in fact the ASP ‘core’ of a $\mu$ASPSv. $test\_ok$ is the input coming from a sensor, with value ‘true’ if the controlled device is working properly, (otherwise the value is set to false).

$\begin{array}[]{l}\mathit{device\_ok}\,\leftarrow\ \mathit{test\_ok}.\\ \mathit{device\_fault}\,\leftarrow\ \hbox{\it not}\ \,\mathit{test\_ok}.\\ \mathit{wait}\leftarrow\,\hbox{\it not}\ \,\mathit{wait},\ \hbox{\it not}\ \,\mathit{sensor\_input}.\end{array}$

In this example, as a programming choice, inconsistency (due to the odd cycle over $wait$) is to be interpreted as a ‘no-operation’ controller state, where the component is waiting for the sensor outcome. It can be assumed that the sensor provides results at a certain frequency. The outcome, i.e., $\mathit{device\_ok}$ or $\mathit{device\_fault}$, is to be delivered to whatever other components would ask for it.

More precisely, in order to work in a standalone way within a distributed system, an interface (or ‘shell’) will manage the ASP program, and in particular will perform the following functions. First, manage the inputs and outputs of the $\mu$ASPSv: i.e., be able to detect input arrival and to dispatch the outputs according to the request coming from the $\mu$ASPSv’s external environment. In the above example, inputs can be: (1) queries over the device state for which an answer has to be delivered, and (2) sensor outcomes, which are to be considered as particular inputs which activate the module. In the general case, upon the arrival of inputs, the shell will: (i) add the inputs to the ASP program as facts; (ii) evaluate the answer sets of the resulting ASP program; (iii) according to previously-received requests, extract (from the answer sets) the answers and and deliver them to the external environment. Notice that the shell, after delivering the outputs, will remove the last-added program facts so as to bring back the controller to the ‘no-operation’ state. In a ‘stateless component’, all inputs will be removed, while some of the inputs can be left if instead the component is meant to have a state.

In this paper we introduce a formal definition of ASP microservices and we outline a possible logic-based semantics of an overall heterogeneous distributed system encompassing such modules. The paper is in fact structured as follows. In Section 2 we introduce basic concepts about microservices. In Section 3 we recall (for the sake of completeness) the Answer Set Programming paradigm, and in Section 4 we briefly survey and discuss existing approaches to modularity in ASP. We introduce our contribution in Sections 5 and 7, i.e.: (1) how to define and implement $\mu$ASPSv’s so as to be able to get inputs and extract answers, and how the inner ASP program might be structured; (2) how to provide a formal semantics to a generic microservice architecture possibly encompassing $\mu$ASPSv’s. In Section 6 we discuss a small case study, developing a specific $\mu$ASPSv which implements an intelligent agent managing a road intersection (i.e., a “virtual traffic light”). Finally, in Section 8 we conclude.

To better understand Microservices, let us introduce before the concept of “Service”. A Service, as a software component, is a mechanism to enable access to one or more software capabilities [2]. It provides other applications with stable, reusable software functionality at an application-oriented, business-related level of granularity using certain standards [30]. Service-Oriented Architecture (SOA) is a software architectural style that uses services as the main building component [2]. Key features of SOA are heterogeneity, standardization and evolvability of services.

Microservices can be seen as a technique for developing software applications that, inheriting all the principles and concepts from the SOA style, permit to structure a service-based application as a collection of very small loosely coupled software services [21].

A MicroServices Architecture (MSA), is an evolution of the SOA architecture, making the communication lighter and the software parts (Microservices) smaller. It can be seen as a new paradigm for programming applications by means of the composition of small services, each running its own processes and communicating via light-weight mechanisms. Key features of MSA are bounded scope, flexibility and modularity [20]. I.e., there is a clear definition of the data a microservice service is responsible for and is “bound to.” So, the service owns this data and is responsible for its integrity and mutability.

The work in [29] shows that a distributed MSA can easily fit into an IoT system. In particular, the set of microservices can be seen as a Multi-Agent-System, cooperating to realize all system functionalities.

At the current day, microservices are still a new and emerging paradigm, having building standards not perfectly defined and communication protocols that are not well specified: in fact, following one of the definitions of microservices [21, 20], they are small loosely coupled software services that communicate, possibly exploiting service discovery to find the route of communication between any two of them. In our work, we are proposing a new approach, that is $\mu$ASP-Services, which are based upon an inner ASP program.

“Answer Set Programming” (ASP) (cf. [6] and the references therein) is a successful programming paradigm based on the Answer Set Semantics. In ASP, one can see an answer set program (for short, just “program”) as a set of statements that specify a problem, where each answer set represents a solution compatible with this specification. Whenever a program has no answer sets (no solution can be found), it is said to be inconsistent, otherwise it is said to be consistent.

Syntactically, an ASP program $\Pi$ is a collection of rules of the form

$H\leftarrow\;A_{\_}{1},\ldots,A_{\_}m,not\,\,A_{\_}{m+1},\ldots,not\,\,A_{\_}{m+n}.$

where $H$ is an atom, $m,n\geqslant 0$, and each $A_{\_}i$, $i\leq m+n$, is an atom. Atoms and their negations are called literals. Symbol $\leftarrow$ is often indicated as :- in practical programming. The left-hand side and the right-hand side of the clause are called head and body, respectively. A rule with empty body is called a fact. A rule with empty head is a constraint, where a constraint of the form ‘$\leftarrow L_{\_}1,...,L_{\_}n.$’ states that literals $L_{\_}1,\ldots,L_{\_}n$ cannot be simultaneously true in any answer set. Constraints are often rephrased as ‘$f\leftarrow not\,f,L_{\_}1,...,L_{\_}n.$’ where $f$ is a fresh atom. To avoid the contradiction over $f$, some of the $L_{\_}i$’s must be false thus forcing $f$ to be false, and this, if achieved, fulfills the constraint. There are other features that for the sake of simplicity we do not consider in this paper.

The answer set (or “stable model”) semantics (AS) can be defined in several ways (cf., e.g., [32], though more recently several other definitions have appeared in the literature). However, answer sets of a program $\Pi$, if any exists, are supported minimal classical models of the program interpreted as a first-order theory in the obvious way.

The ASP approach to problem-solving consists basically in the following: (i) encoding of the given problem via an ASP program; (ii) computing the “answer sets” of the ground program via an ASP solver (as a preliminary step, solvers perform the “grounding” of the program, by substituting all variables with the constants occurring in the program); (iii) extracting the problem solutions by examining such answer sets; in fact, answer set contents can be in general reformulated in order to present the solution in terms of the given problem.

A top-down (prolog-style) query answering device has been defined in [16] for RAS, where RAS is a variation of AS where every program admits answer sets. However, RAS and AS coincide over a wide class of programs (some sufficient conditions that identify classes of programs where the two semantics coincide are reported in [15]). Queries that have been introduced are, first of all, “? $A$” asking whether $A$ is true w.r.t. some answer set of given program $\Pi$. Other queries are the following: query “? not $A$” asks whether $A$ is false w.r.t. some answer set of $\Pi$, and therefore it succeeds if $\hbox{\it not}\ A$ is true in some of them (this implements the operator not introduced in [35]); query “? $\mbox{{not}}\,\hbox{\it not}\ A$” asks whether $\hbox{\it not}\ A$ is false in some answer set, and therefore it succeeds if $A$ is true in some of them, which corresponds to query “? $\mbox{{M}}A$”, M standing for ‘possibility’ in the modal logic sense; query “? not   not $A$” asks whether it is not true that $A$ is false w.r.t. some answer set of $\Pi$, i.e., that $A$ is true in all of them, which corresponds to “? $\mbox{{K}}A$”, K standing for ‘knowledge’ in the modal logic sense; query “? $\hbox{\it not}\ \mbox{{not}}\,\hbox{\it not}\ A$” asks whether $A$ is false in every answer set, meaning $\mbox{{K}}\,\hbox{\it not}\ A$, i.e., $\hbox{\it not}\ \mbox{{M}}A$ (a new operator NOT is a shorthand for $\hbox{\it not}\ \mbox{{not}}\,\hbox{\it not}\ A$).

Existing approaches to modularization of ASP programs have been reviewed in [22], to which the reader may refer for a complete account. Reporting from there, such approaches can be divided into two lines: “programming-in-the-large”, where programs are understood as combinations of separate and independent components, combined by means of compositional operators; “programming-in-the-small”, in which logic programming is enriched with new logical connectives for managing subprograms.

Considering the programming-in-the-small vision: in [23], program modules are viewed as generalized quantifiers; [26] proposes templates for defining subprograms; [36] developed a declarative language for modular ASP, which allows a programmer to declaratively state how one ASP module can import processed answer sets from another ASP module. The work in [14] explores how to divide an ASP program into components according to its structure in terms of cycles.

Lifschitz and Turner’s “splitting set theorem” (cf. [33]), or variants of it, is underlying many programming-in-the-large approaches. The basic idea is that a program can be divided into two parts: a “bottom” part and a “top” part, such that the former does not refer to predicates defined in the latter. Computation of the answer sets of a program can be simplified when the program is split into such parts.

[28] defines the notion of a “DLP-function” which is basically a module for which a well-defined input/output interface is provided; a suitable compositional semantics for modules is introduced. [34] provides a simple and intuitive notion of a logic programming module that interacts through an input/output interface. This is achieved by accommodating modules as proposed by [25] to the context of Answer Set Programming. Full compatibility of the module system with the stable model semantics is achieved by allowing positive recursion to occur inside modules only.

[18] focuses on modular non-monotonic logic programs (MLP) under the answer set semantics, where modules may provide input to other modules. Mutually recursive module calls are allowed.

[4] defines modules in terms of macros that can be called from a program. [3] provides modules specification with information hiding, where modules exchange information with a global state.

In [24] a technique is proposed to allow an answer set program to access the brave or cautious consequences of another answer set program. [31] proposes “modular logic programs” as a modular version of ASP. This work consider programs as modules and define modular programs as sets of modules. The authors introduce “input answer sets”, which is the key semantic object for communication between modules.

[10] proposes to adopt ASP modules in order to simulate (within reasonable complexity) possibility and necessity operators. Such operators (given the underlying modules) are meant to be usable in ASP programs, but possibly also programs written under other programming paradigms.

It can be seen that none of the above approach tackles modularization in view of using ASP modules as standalone components in distributed systems. Therefore, our approach is a novelty in the landscape of the current literature.

In this section we provide an abstract definition of a $\mu$ASPSv, and some more specific indication of how such a component might be enacted and inserted into a distributed system, and how the inner ASP program might be structured.

Whenever the activation signal is specified, if $A$ is not true in $\Pi$, then $\mu$ASPSv($\Pi$) is in a state of no-operation.

Whenever the stop signal is specified, if $S$ becomes true in $\Pi$, then $\mu$ASPSv($\Pi$) will go back into a state of no-operation.

The input set is a set of atoms that, when some of them are added to $\Pi$, contribute to answer sets computation. Each of such atom corresponds to an input/request received from the $\mu$ASPSv’s surrounding environment.

The output set is a set of atoms extracted from the answer sets of $\Pi$ plus the current input set. Each of these atoms corresponds to an output/answer to be delivered into the $\mu$ASPSv’s surrounding environment.

The query result set is a set of truth values elicited from the answer sets of $\Pi$. Each of these values corresponds to result of a query, to be delivered into the $\mu$ASPSv’s surrounding environment.

In order to make it possible for $\mu$ASPSv($\Pi$) to operate dynamically, thus receiving inputs and delivering outputs and answers, a suitable shell program must be defined, in any programming language able to be interfaced with an answer set solver. Below we provide a schematic definition of such a shell program, to be used as a guideline for actual definition and implementation.

This shell program is able to activate and stop a $\mu$ASPSv, and to execute, until possibly a stop signal arrives, a loop where the inputs are received from the external environment and delivered to $\Pi$, and outputs and query results are extracted from the answer sets of $\Pi$ (given the inputs) and delivered to the external environment. Precisely, each input will arrive from some other component, to which the output will have to be delivered. The shell program will rely upon an input-output table, where each input, expected output and related component will be annotated. Notice that at the end of each cycle some or all of the inputs will be removed from $\Pi$ and the relative annotations will be eliminated (removing all inputs determines a stateless component, while omitting to remove some of the inputs, forever of for some time interval, accounts to defining a stateful component). Input detection will occur at a certain frequency, suitable for each particular kind of component, environment, and application domain. Some of the inputs may come from sensors (and therefore they do not require any answer) and some of the outputs may go to actuators. This is also annotated in the input-output table. Notice also that the parts concerning the activation and stopping of the $\mu$ASPSv (first and second line after the begin, and last line before the end) will be omitted if the component is running forever rather being first activated and then stopped.

Many practical aspects remain to be defined in order to obtain an implementation. For instance, if a $\mu$ASPSv is to be situated within a multi-agent system, input-output-query exchange might happen via FIPA (cf. http://www.fipa.org for language specification, syntax and semantics), a widely used ACL (Agent Communication Language). The shell program can be made FIPA-compliant (i.e., able to exchange and understand FIPA messages) for instance by importing the freely available JADE library (cf. https://jade.tilab.com/ where references to several related publications can also be found). The JADE library is an advance middleware that offers many functionalities to “agentify” imperative or object-oriented programs. In fact it provides: the agent abstraction (i.e., a given program, when running, is seen by the external environment as an agent); the ability of peer to peer inter-agent FIPA asynchronous message-passing; a yellow pages service supporting subscription of agents and a discovery mechanism, and many other facilities to support the development of distributed systems.

So for instance, an input can be sent to a $\mu$ASPSv via a FIPA request message with the input as argument, to be interpreted on the $\mu$ASPSv’s side as a request to reply with a confirm message containing the corresponding output. A query can be sent to the $\mu$ASPSv via a query-if message whose answer will be a confirm, conveying the truth value of the query. Notice that, to avoid ambiguities, the FIPA syntax provides the facility to identify each message via a certain arbitrary identifier, so that the answer message can indicate that it is ‘in-reply-to’ to that identifier.

The JADE yellow pages services might be exploited by $\mu$ASPSv’s which would want to register as agents with a name and a role, and then communicate with each other in an asynchronous way. Or, since most MAS offer such a mediator service, $\mu$ASPSv’s might enroll in any known agent community. Finally, they might communicate peer-to-peer with other agents that they are aware of, or that they locate via the mediator.

Let us now consider how to structure ‘core’ program $\Pi$, on which a microservice $\mu$ASPSv($\Pi$) is based. First, activation and stopping of a module can be simply obtained by a couple of constraints, that make the program inconsistent (in no-operation state) if either activation $A$ has not arrived, or stopping signal $S$ has been issued:

Then, when the module has been activated, upon arrival of new inputs, the inner program $\Pi$ will in general ‘produce’ (admit) answer sets. If the answer set is unique then the outputs can be univocally identified. Otherwise the shell, in the ‘elicit outputs’ part, will have to adopt some kind of policy (e.g., preferences, utilities, costs or other) to select which answer set to consider. The queries, being by definition defined upon the whole set of answer sets, will always return an univocal result. In case, given the present input, $\Pi$ should be inconsistent, then the output will consist in a failure signal (e.g., in the FIFA ACL, there is the failure primitive to be used in such cases).

The case study that we propose here is inspired to issues raised by applications related to autonomous vehicles. Presently, machine learning mechanism have been defined to allow autonomous cars to comply with traffic lights by detecting their color, so as to pass with green and stop with red similarly to traditional cars. Such mechanisms must be trained, are prone to errors, and are potentially subject to adversarial machine learning.

In our view, physical traffic lights might in perspective disappear, to be substituted by monitoring agents that would receive requests to pass from cars and consequently issue authorizations. This either in routes dedicated to autonomous vehicles, or in the (very reasonable) hypothesis to equip also ‘traditional’ cars with a device to interact with the monitoring agents.

Below we propose the sample design of the inner program concerning a $\mu$ASPSv which implements the monitoring agent of a road intersection, taking the place of a physical traffic light. In the example, the traffic light agent is called $tl$ and, for the sake of simplicity, behaves like a ‘real’ traffic light but just takes the colors green ($g$ for short) and red ($r$ for short). In fact, the yellow is no longer necessary as we assume that the involved cars (each one equipped with its own driver agent) will obey the directives. We have two lanes, one going north-south ($ns$ for short) and the other one east-west ($ew$ for short), crossing at the traffic light. If the traffic light is green in one direction it must be red in the other one, and vice versa. The traffic light is activated by a signal $active(t1)$, and never stopped unless there is a fault, detected by the module itself by means of a sensor. A fault is supposed to have occurred whenever $fault\_tl$ is true, i.e., it has been returned by the sensor.

Each car, say here $c1$, $c2$, $c3$, $c4$ and $c5$, wants to go, but it is allowed to proceed only if it gets the green traffic light. Otherwise, it remains dummy. We assume that all cars behave in the same way. Each one issues a request of format $car(C),want\_go(C,t1,L,T)$ where $L$ is the lane, with possible values $ns$ for north-south and $ew$ for east-west; $T$ is the time of the request. Requests by various cars may for example give rise to the addition of the following facts to the $\mu$ASPSv’s program.

The following facts and rules define the lanes, and specify that this monitoring agent has a lookahead of five time instants: after that, it will have to be re-run.

Rules below define the color that the traffic light takes in a very standard way as transitions from green to red and vice versa, where the initial color is green. In reality, such a monitoring agent can employ a much more sophisticated protocol such as for instance the Contract Net Protocol (CNP). If adopting CNP, the agent might grant priority to particular kinds of vehicles, e.g., police cars, ambulances, cars transporting a disabled person, etc. More generally, any policy to grant passage according to criteria could be implemented.

In our case the implemented protocol is fair, as cars that cannot go now because it is red on their lane will be deferred to the next time instant (by delaying their request), when the color will be green (output in format $go(Car,t1,Lane,Time)$).

Clearly, this program can be ‘cloned’ (mutatis mutandis) to manage any other traffic lights. For the reader’s convenience, this program is standalone and can be run exactly as it is to check its results.

The semantics of a single$\mu$ASPSv is fully specified by: (i) the answer sets of the inner ASP program; (ii) the policy employed in its shell to select one single answer set; (iii) the set of queries that the shell performs over the entire set of answer sets, whose meaning is formally specified in [17, 15]. We aim however to provide a semantics for the overall distributed system composed of heterogeneous microservices, in order to provide a firm ground and a guideline for implementation.

To do so, we resort to Multi-Context Systems (MCSs), that are a well-established paradigm in Artificial Intelligence and Knowledge Representation, aimed to model information exchange among heterogeneous sources [5, 7, 8]. However, with some abuse of notation (and some slight loss of generality) we adapt and readjust the definitions to fit into our framework. To represent the heterogeneity of sources, each component in a Multi-context system, called ‘context’,is supposed to be based on its own logic, defined in a very general way [7]. In particular, a logic is defined out of the following.

• •

  A set $F$ of possible formulas (or $\mathit{KB}$-elements) under some signature;

• •

  A set $KB$ of knowledge bases built out of elements of $F$. in our framework, $KB$ can also be a program in some programming language;

• •

  A function $\mathit{ACC}$, where $\mathit{ACC}(kb,s)$ means that $s$ is an acceptable set of consequences of knowledge base $kb\in KB$, i.e., $s\subseteq Cn$, where $Cn$ is the set of all possible consequences that can be drawn from $kb$. We assume here that $\mathit{ACC}$ produces a unique set of consequences. In case of a program written in a non-logical programming language, such set can be the set of legal outputs given some input (added to $kb$), that will be a subset of all possible outputs $Cn$; for logical components, it will be (one of) the $kb$ model(s). For instance, as we have seen the shell of a $\mu$ASPSv will produce as consequences the elements occurring in the answer set selected according to some policy, along with query results (where queries deliver conclusions drawn in general from the whole set of answer sets)

A (Managed) multi-context system (MCS) $M=\{C_{\_}1,\ldots,C_{\_}{r}\}$ is a set of $r=|M|$ contexts, each of them of the form $C_{\_}i=\langle c_{\_}i,L_{\_}i,kb_{\_}i,br_{\_}i\rangle$, where:

• •

  $c_{\_}i$ is the context name (unique for each context; if a specific name is omitted, index $i$ can act as a name). In [9] a context’s name, in the definition of a bridge rule, can be a term called context designator denoting the kind of context that should deliver that data item (for instance, mycardiologist(c), customercare(c), helpdesk(h), etc.).

• •

  $L_{\_}i$ is a logic.

• •

  $kb_{\_}i\in KB$ is a knowledge base.

• •

  $br_{\_}i$ is the set of bridge rules this context is equipped with.

Contexts in an MCS are meant to be heterogeneous distributed components, that exchange data. In fact, bridge rules are the key construct of MCSs, as it describes in a uniform way the communication/data exchange patterns between contexts. Each bridge rule $\rho\in br_{\_}i$ has the form

where the left-hand side $s$ is called the head, and the right-hand side is called the body, and the comma stands for conjunction. The meaning is that, each data item $p_{\_}j$ is supposed to come from a context $c_{\_}j$³³3In the original formulation, there are additional literals $\hbox{\it not}\ (c_{\_}1:p_{\_}{j+1}),\ldots,\hbox{\it not}\ (c_{\_}j:p_{\_}n)$ meaning that in order for the bridge rule to be applied, the $p_{\_}{j+1}\ldots p_{\_}n$ must be false in the relative contexts. We disregard this part, as non-logical components cannot use logical negation. There is no loss of generality however, as each of the $p_{\_}1,\ldots,p_{\_}j$ can state a negative fact.. Whenever all the $c_{\_}1,\ldots,c_{\_}j$ have delivered their data item to the destination context $c_{\_}i$, the rule becomes applicable. When the rule is actually applied, its conclusion $s$, once elaborated by operator $Op$, will constitute an input to $c_{\_}i$. Operator $op_{\_}i$ can perform any elaboration on “raw” input $s$, such as format conversion, filtering, elaboration via ontologies, etc. Its operation is specified via a management function $mng_{\_}i$, which is therefore crucial for knowledge incorporation from external sources. For simplicity, here we assume $mng_{\_}i$ to be monotonic (i.e., to produce from $s$ one or more data items) . Therefore, we can extend the previous definition of a context as $C_{\_}i=\langle{c_{\_}i,L_{\_}i,kb_{\_}i,br_{\_}i,mng_{\_}i}\rangle$. A bridge rule is applicable if its body its true, in operational terms if all the data items listed in its body have arrived. In case context designators are employed, prior to checking a bridge rule for applicability, such terms must be substituted by actual context names. For $\mu$ASPSv’s, this task will be performed by the shell, that must then be endowed with a list of contexts of each type.

A data state (or belief state) $\vec{S}$ of an MCS $M$ is a tuple $\vec{S}=(S_{\_}1,\ldots,S_{\_}{r})$ such that for $1\leq i\leq{r}$, $S_{\_}i\subseteq Cn_{\_}{i}$. A data state can be seen as a view of the distributed system by an external “observer”. $\mathit{app}(\vec{S})$ is the set composed of the head of those bridge rules which are applicable in $\vec{S}$. This means, in logical terms, that their body is true w.r.t. $\vec{S}$. In practical terms, we may say that a bridge rule $\rho$ associated to context $c_{\_}i$ is applicable in $\vec{S}$ if all the data mentioned in the body of the bridge rule can be delivered to the destination context. This is the case whenever they are available in the contexts of origin, i.e., they occur in the present respective data state items in $\vec{S}$. In the original formulation of MCS, all applicable bridge rules are automatically applied, and their results, after the elaboration by the management function, are added to the destination context’s knowledge base, that therefore grows via bridge-rule application.

Starting from a certain specific data state, some bridge rules will be applicable and therefore they will be applied. This will enhance the knowledge base in some of the contexts, thus determining (in these contexts) a new set of acceptable consequence, and therefore a new overall data state. In the new state other bridge rules will be applicable, and so on, until a “stable” state, called Equilibrium, will be reached. Technically, $\vec{S}$ is an equilibrium for an mMCS $M$ iff, for $1\leq i\leq|M|$,

which states that each element of the equilibrium is an acceptable set of consequences after the application of every applicable bridge rule, whose result has been incorporated into the context’s knowledge base via the management function. in [9] it is proved that, in the kind of MCS that we have just described, an equilibrium will be reached in a finite number of steps. Notice however that this definition assumes the system to be isolated from any outside influence, and that an equilibrium, one reached, will last forever. Instead, in real systems there will be interactions with an external environment, and so equilibria may change over time. Moreover, each context is not necessarily a passive receiver of data sent by others.

To take these aspects into account, [9] proposes some extensions to the original formulation, among which the following, that are relevant in the present setting.

• •

  It is noticed that contexts knowledge bases can evolve in time, not only due to bridge-rule application. In fact, contexts receive sensor inputs (passively or in consequence to active observation), or can be affected by user’s modification (e.g.,a context encompasses a relational database that can be modified by a user). So, each context $c_{\_}i$ will have an associated Update Operator $\mathit{{\cal U}_{\_}i}$ (that can actually consist in a tuple of operators performing each one a different kind of update). Updates and bridge rules both affect contexts’ knowledge base over time. So (assuming an underlying discrete model of time) we will be able to consider, when necessary, $c_{\_}i[T]$ meaning context $c_{\_}i$ at time $T$, with its knowledge base $kb_{\_}i[T]$; consequently we will have an evolution over time of contexts. Therefore, we will have a definition (not reported here) of Timed Equilibria. Notice only that a timed equilibrium can be reached at time $T+1$ only if the actual elapsed time between $T$ and $T+1$ is sufficient for the system to “stabilize” by means of bridge-rules application on the updated knowledge bases.

• •

  Mandatory bridge-rule application constitutes a limitation: in fact, this forces contexts to accept inputs unconditionally, and this be often inappropriate. Consider for instance a context representing a family doctor: the context may accept non-urgent patient’s requests for appointments or consultation only within a certain time windows. So, [9] introduces conditional bridge-rule application, formalized via a timed triggering function,  $\mathit{tr_{\_}i}$, which specifies which applicable bridge rules are triggered (i.e., they are practically applicable) at time $T$. It does so either based on certain pre-defined conditions, or by performing some reasoning over the present knowledge base contents. Therefore, the implementation of $\mathit{tr_{\_}i[T]}$ my require an auxiliary piece of program, that in a $\mu$ASPSv’s shell will presumably be a logic program.

So, considering contexts which are $\mu$ASPSv’s, in order to fit in the vision of the overall system as an MCS, their shell must be empowered as follows.

• •

  Include the bridge rules associated to a $\mu$ASPSv, and the definition/implementation of the triggering function.

• •

  Include a facility to resolve the context designators, so as to check for applicability a triggered bridge rule after substituting context designators occurring therein with actual contexts’ names.

• •

  Include the definition of the specific management function, so as to be able to apply it on bridge-rules’ results.

In the case study of previous section, each traffic light should be equipped with a bridge rule that, by means of a suitable context designator (say, anycar(c)) collects the cars’ requests. Symmetrically, cars should be equipped with a bridge rule to collect the permission to go by the traffic light (the nearest one, whose identifier should replace a context designator of the form, e.g., a_traffic_light(t). The triggering function may allow cars to enable receiving traffic-light communications only when this is deemed appropriate.

Context designators are therefore useful to write general bridge rules to be then customized to the particular situation at hand. They also allow to devise a system where components do not know or are aware of each other in advance, and where components can possibly join/leave the system at any time. A suitable middleware should be realized to allow component’s shells to instantiate bridge rules. Concerning our case study, that concerns an infrastructure for autonomous vehicles, both cars and traffic lights might for instance broadcast their name and geo-localization. In this way, cars might locate the traffic light of interest, and traffic lights might become aware of nearby cars that might send them a request.

We have proposed a methodology for developing microservices in Answer Set Programming, by means of the creation of a particular kind of components, that can be activated/stopped, can receive external requests and can deliver answers. We have provided a definition of a $\mu$ASPSv and explained how it might be implemented, and we have outlined a programming methodology. We have also outlined a possible uniform semantics to specify an heterogeneous system in which $\mu$ASPSv’s can be situated. This is an absolute novelty for microservices in general, as no attempt has ever been made to provide such a uniform model for an overall system. The proposed semantics can constitute the ground for principled implementations. Overall, this work can be considered as a creative combination of existing technologies, in view of entirely new fields of application of answer set programming and logic programming in general.

Important application fields for $\mu$ASPSv’s are Cloud computing and IoT. We consider particularly important the various kinds of robotic applications and the underlying infrastructural aspects, as shown in the case study related to autonomous vehicles.

Future work includes refining the programming methodology on the one hand, devising a prototype implementation and experimenting the integration in realistic environment: we plan in particular to experiment the integration into DALI Multi-Agent-Systems, where DALI [11, 12, 13, 19] is the agent-oriented programming language defined and implemented by our research group, that has been made compatible with the Docker technology. This will allow us to experiment $\mu$ASPSv’s as components in the various applications where DALI is being applied, including cognitive robotic architectures.