Bostjan Kaluza, Damjan Kuznar, Erik Dovgan, Jernej
Zupancic, and Matjaz Gams
Jozef Stefan Institute, Slovenia

• I. Introduction
– Principles and argumentation
– Idea
– Relation to TNO architecture
• II. Analysis
– Use cases
– Agent types
– Responsibilities
– Agent deployment
• III. Design – Next steps

• 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 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

• 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)

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
Applications
ACCUS ICP
Extensions
ACCUS ICP
Core
= Standard software
= ACCUS specific software
= case specific software
Cross Domain
Application
Smart
Lighting
Application
Application
ACCUS Service Plug-ins
Event detection
Location detection
Presence detection
ACCUS Plug-ins
Data analytics
Calamity detection
Rule engine
Traffic monitor
Generic service …
Generic service …
Subsystem
Service
Subsystems
Subsystem adaptor
Info Broker & coordination
ACCUS API
Control Broker
& coordination
Work Flow
Engine
ACCUS
Data Store
Subsystem
Monitoring
Semantic mapping
Ontology DB
ACCUS Integration and Coordination Platform
Service Bus
Application
Server
OSGi
Application
Server
Data management
Service Broker
Policy management
Java VM
OS
Hardware
Policy
DB
Service
Repository
Identity & access management

• Two-dimensional view
Infrastructure
ACCUS ICP Core
Generic
ACCUS ICP Extensions
Accus specific
ACCUS Plugins
City specific
Execution and Control
ICP Backbone
Execution
Responsive behavior
ICP Mind
Planning
Proactive behavior
 





• 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

• Communication
• Service management
– Service life-cycle
• Rule engine
– Executing queries
• Workflow engine
– Executing emergency response
• Security
*service = basic reactive agent

• 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

Support
Learning agent
Optimization agent
Data analytics agent
Adaptive control schemes
Coordinators
City coordinator agent
Subsystem 1 coordinator agent
Subsystem 2 coordinator agent
Service management
Communicatio n
Security
Rule engine
Work flow engine
…
Subsystem 2 services
Subsystem 1 services
Transducer 1
Transducer 2
Subsystem 1 Subsystem 2

• 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

• ICP Backbone: OSGi
• ICP Mind: Jade, Jadex
ICP MIND
ICP BACKBONE
JADE
OSGi
JAVA
OS
HARDWARE
ARTEMIS-2013
Data base
APP server

• 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 ACL
Transducer
Legacy resource
Wrapper
Legacy code
Rewrite

• Interaction specification
• Protocol definition
• Message templates
• Agent user interaction
• Internal agent behavior
• Defining ontology