Motivations

• MAS lack principled approach to engineer the digital <-> physical frontier
• there are model and methods for environment modeling
• but the focus is mostly on interface exposed to agents
• and the "nuts and bolts" of digital <-> physical connection lack structure
• DTs may fill in the gap!
• uniform and interoperable access to resources
• digital <-> physical synchronisation

Goals

Better MAS environment engineering!

• separation of concerns MAS <-> CPS
• independent evolution MAS <-> CPS

How?

• put DTs between MAS and CPS
• let DTs handle interface towards CPS

Digital Twins

• Virtualisation of real world entities (physical assets)
• Faithful digital replicas
• Deeply intertwined with their physical twin
• Connected in a web of semantic overlays

Ricci, A. et al.: Web of digital twins. Transactions on Internet Technology, ACM. 2021.

Separation of concerns

• DTs operate with full knowledge of the local context of their associated PA
• access to data
• available actions
• knows nothing about other PAs
Agents operate with partial knowledge of the global context of the application
• application goals
• available DTs
• knows nothing about how to operate on PA

Mariani, S. et al.: Agents and Digital Twins for the engineering of cyber-physical systems: opportunities, and challenges.
Annals of Mathematics and Artificial Intelligence, Springer. To appear.

This separation allows for assigning clear responsibilities during system design!

Conceptual architecture I

Artefacts in A&A

• Bring level of abstraction closer to AOP
• by encapsulating env. resources as agents' tools
• thus mapping MAS env. resources to available perceptions and admissible actions

Omicini, A., Ricci, A., Viroli, M.: Artifacts in the A&A meta-model for multi-agent systems. Autonomous Agents and Multi-Agent Systems 17(3), 432–456 (2008)

Conceptual architecture II

• DTs promote development paradigm closer to devices
• Artefacts promote development paradigm closer to agents

Integrating the two enables our goals!

But how, in practice?

Technical architecture

Enabler technologies

• JaCaMo: jacamo.sourceforge.net
• MAS development and execution platform
• embraces the A&A meta-model via CArtAgO
• programmatic management of artefacts
• WLDT: github.com/wldt
• DTs development and execution platform
• discovery service
• web-ready DT descriptor

DTs layer

• DTDescriptor: JSON/XML representation of the DT
• properties (e.g. temperature, location, local time)
• actions (e.g. turn on, turn off, set temperature)
• behaviours (e.g. turn on until temp > 18)
• relations to other DTs (e.g. thermostat linked to A/C system)
• metadata (e.g. connection protocol, URL)
• WLDTDiscoveryService: advertise & discover DTs
• exposes DTDescriptor to known address

Integration layer I

• DTDiscoveryArtefact: automatically creates artefacts connected to DTs
• DT property <-> artefact observable prop.
• DT action <-> artefact operation
• DT behaviour <-> observable prop. + operation
• DT relation <-> artefact link
• exploits JaCaMo and WLDT services to
• programmatically create artefacts in workspace
• do the mapping above
• set-up bi-directional comm. link artefact <-> DT

Developers' point of view

• MAS side
• develop their agents
• configure DTDiscoveryArtefact with well-known URL of WLDTDiscoveryService
• start the automatic "creation & mapping" process (ad-hoc operation)
• CPS side
• develop their DTs
• publish them to the WLDTDiscoveryService

Little agreement is required -> loose coupling
(both at design and run time)

Conclusion & outlook

• The proposed integration promotes separation of concerns and independent evolution
• We expect to open source the integration during summer 😊
• JaCaMo components are already available (workspaces, artefacts, links, programmatic API)
• Some WLDT components are now underway (discovery service)
• Enabling experimentation of the synergies between agents and DTs!