Deliverable 2.2

This deliverable addressed a challenge of designing a framework for annotating behaviour of an agent – representative of a resource, with further enactment of the behavior. Thus, basically we faced two challenges: (a) design of a handy user interface for specifying resource behaviour in form of rules and resource mental states, and (b) design of an engine to run these rules and perform corresponding actions. Such framework is anticipated to become a basis for modelling a variety of different processes: business processes, enterprise integration, distributed maintenance, distributed diagnostics and learning, supply chain management, etc.

The architecture of the proactive layer of the SmartResource Platform is presented in Figure above. Its structure comprises four storages: (a) a history for storing facts about events occurred in an external environment of the resource agent; (b) a storage for reasoning (mental) states of the resource agent and rules that determine its behavior; (c) a storage where an ontology and all instances (metadata related to Devices, Services, Human Experts, Agents, etc.) are located; (d) a storage for programmable executable modules. In fact, the storage for the statements of facts about the external environment is presented by two storages: one for operational purposes and another for long-term storing. Operational storage contains relevant and up-to-date data critical for performance. For example, if a statement about assigning the resource agent a new role is asserted to the operational storage, then a statement about previous role of the agent must be removed to the long-term history or otherwise irrelevant alarm statements must be removed. Such filter prevents contradiction in the latest data.

The architecture includes two engines, too: one for rules and another for a behavior. The engines iteratively check the rules, execute them and launch necessary actors (modules). The main role of the rule engine is to generate (to change) a context for the resource behavior.

From the user’s perspective, the information that will be needed from him/her is (a) a starting role or goal for the resource agent and (b) input data/facts. For this purpose, the user interface must provide all available information from the ontology and data, stored on the platform: a list of instances, a list of properties, etc. If semantic profiles of accessible executable modules and web services are available, then this makes a good basis for automated generating behavioural rules by the platform. Otherwise, a semantic profile has to be specified for all executable modules available on the platform and for web services that will be used. If there is no any executable module or a web service, which can achieve the goal, then the goal can be divided into a set of sub-goals based on corresponding information in the ontology or on an iterative process of generating sub-goals automatically (based on required inputs for modules, which can reach the goal but inputs are not provided).