ICP Architecture:
Execution and Control
Bostjan Kaluza, Damjan Kuznar, Erik Dovgan, Jernej
Zupancic, and Matjaz Gams
Jozef Stefan Institute, Slovenia
Outline
• I. Introduction
– Principles and argumentation
– Idea
– Relation to TNO architecture
• II. Analysis
– Use cases
– Agent types
– Responsibilities
– Agent deployment
• III. Design – Next steps
Principles and Motivation
• Properties of smart cities
• Smart Cities, I. Celino, S. Kotoulas (eds.), IEEE Internet Computing,
November/December 2013:
– Effectively process networked city information
– Information to authorities, business, citizens, optimizing energy and
water production or consumption, traffic management, public safety,
emergency response
– Multifaceted and cross-domain challenges, inherently interdisciplinary
– Reason on spatial, temporal and contextual aspects of data
– Life-cycle of data, integrating heterogeneous sources
– Ubiquitous, pervasive, AmI, agents, AI
– IBM Smarter Planet initiative, Siemens Sustainable Cities, Oracle IT
platform City services, Microsoft CityNext platform
Principles and Motivation/ Design
• Principles of designing large distributed systems
– Need to balance: simplicity, scalability, performance, reliability,
generality, features
– Before doing anything, consult people having experience with
designing large distributed systems (Belifemine; JSI)
• Software design topics
– Design concepts: abstraction, refinement …
– Design considerations: compatibility, fault-tolerance …
– Modeling language: flowchart, UML, SysML, …
– Design patterns: reuse of patterns, modules …
– Usage: documentation, prototypes
• Practical: choose design methodology, forms, languages …
– Execute: Definition, analysis, design, implementation, test
Motivation / our approach
• Agent technologies best for smart cities /ACCUS
– Agent: autonomous SW component, providing interoperable interface
to an arbitraty system, persuading its agenda for a client
– Autonomous, social, reactive, proactive, mobile, truthful, benevolent
• Our proposal
– Agent design methodology
– Prototype on a smart house / current
– OSGi, JADE, JADEX
– Two parts
• very compact (!) core working every-day tasks fast and reliable
(limited size and functionality; general and flexible)
• complex advanced modules providing „thinking“
(negotiating, optimizing, learning; large, heterogenous, complex,
not fully reliable, scientific and operational challenges)
Idea
Operational and control levels:
• ICP Backbone
– Runtime environment (management, communication, …)
– Focused on execution
– Responsive behavior (via service calls, notifications)
• ICP Mind
– Proactive behavior
– Learning, optimization, control
ACCUS architecture
ACCUS Service Plug-ins
ACCUS Plug-ins
Cross Domain
Application
Smart
Lighting
ACCUS
Applications
Application
Application
Service
Service…
Event
detection
Data
analytics
Traffic
monitor
Location
detection
Calamity
detection
Generic
service …
Service
Presence
detection
Rule
engine
Generic
service …
Subsystems
Subsystem
Subsystem
adaptor
ICP Mind
ACCUS API
ACCUS ICP
Core
Info Broker &
coordination
Control Broker
& coordination
Subsystem
Monitoring
Semantic
mapping
ACCUS
Data Store
ICP Backbone
= case specific software
Service
Repository
Service Bus
Application
Server
Application
Server
Data
management
Service Broker
Java VM
= ACCUS specific software
Policy
DB
Ontology DB
ACCUS Integration and Coordination Platform
OSGi
= Standard software
Work Flow
Engine
OS
Hardware
Policy
management
Identity &
access
management
Management
Security
ACCUS ICP
Extensions
Infrastructure vs. Control View
• Two-dimensional view
Execution and Control
Infrastructure
ICP Backbone
Execution
Responsive behavior
ICP Mind
Planning
Proactive behavior
ACCUS ICP Core
Generic


ACCUS ICP Extensions
Accus specific


ACCUS Plugins
City specific


II. ANALYSIS
•
•
•
•
Use cases
Agent types
Responsibilities
Agent deployment
Sample ICP Backbone Use Case :
Emergency Management
Sample ICP Backbone Use Case :
Emergency Management
Sample ICP Backbone Use Case :
Emergency Management
Sample ICP Mind Use Case:
Multiagent negotiations
Sample ICP Mind Use Case:
Multiagent negotiations
Agent (Service*) Types: ICP Backbone
• Communication
• Service management
– Service life-cycle
• Rule engine
– Executing queries
• Workflow engine
– Executing emergency response
• Security
*service = basic reactive agent
Agent types: ICP Mind
• Subsystem coordinators, city coordinator
– Belief-Desire-Intention agents
– Proactive, follow their goals
– Organizational structure
– (decision making, negotiations)
• Support agents
– Optimization
• Stochastic optimization
• Game theory (Nash equilibriums, multiagent negotiations)
– Learning
• Anomaly detection
• Surrogate modeling (simulator synthesis)
– Data analytics
– Adaptive control schemes
Organizational Structure (partial)
Backbone
Mind
Support
Coordinators
Learning
agent
Data
analytics
agent
Optimization
agent
Adaptive
control
schemes
Service
management
Communicatio
n
City
coordinator
agent
Subsystem 1
coordinator
agent
Subsystem 2
coordinator
agent
Rule engine
Subsystem 2
services
Work flow
engine
Subsystem 1
services
Transducer 2
Security
…
Transducer 1
Subsystem 1
Subsystem 2
Responsibilities: Lighting coordinator
• Receives lighting schedules from authorized agents
• Retrieves information on weather, traffic conditions, pedestrians,
cyclists etc
• Receives new algorithms for computing lamp brightness
• Presents information on lamp conditions, power consumption,
brightness levels etc
• Uses support agents (Nash equilibria agent, stochastic optimization
agent) to compute better – (sub)optimal settings for operation
• Uses support agents to specify workflow in case of emergency or
anomaly detection
• Negotiates with other subsystem coordinator agents
• Listens to the City coordinator agent
Deployment Information
• ICP Backbone: OSGi
• ICP Mind: Jade, Jadex
ICP MIND
ICP BACKBONE
JADE
OSGi
Data
base
JAVA
OS
HARDWARE
ARTEMIS-2013
APP
server
Deployment: Integration with ICP
• Transducer (when modifying code is not possible)
– Separate process that implements API and communicates with
outside system
– Each application specifies input/output in the agent language
• Wrapper (when modifying code is possible)
– API envelope
• Code rewrite (programmed in line with agents paradigm)
– Part of ICP, our components
ACL
ACL
Transducer
Wrapper
Legacy
resource
Legacy code
ACL
Rewrite
Further Work: Architecture Design
•
•
•
•
•
•
Interaction specification
Protocol definition
Message templates
Agent user interaction
Internal agent behavior
Defining ontology