FIWARE Building the Future - 3 June 2020 Corresponding webinar recording: https://youtu.be/REoJA7yxJ_0 An in-depth look at where FIWARE is going next and integrates with blockchain and distributed ledger technologies, Artificial Intelligence or Robotics. Chapter: Cross-Domain Difficulty: 2 Audience: Any Technical Presenter: Juanjo Hierro (CTO, FIWARE Foundation

1. FIWARE Building the Future:
Looking at Major Roadmap Activities
Juanjo Hierro
CTO
FIWARE Foundation
juanjose.hierro@fiware.org, @FIWARE

2. Agenda
 Intro – remainder of some core concepts in FIWARE
 Roadmap topics
• NGSI-LD
• Smart Data Models
• Blockchain
• Robotics
• Data Marketplace
• Marketplace of Plug & Play AI / Big Data Services
 Summary / Conclussions
1

3. Intro
2

4. Modeling Context using Digital Twins
3
Entities
(Digital Twins)
Bus
• Location
• No. passengers
• Driver
• License plate
Citizen
• Birthday
• Preferences
• Location
• ToDo list
Incident / claim
• Date
• Location
• Type
• Issuer
• Description
Shop
• Location
• Business name
• Franchise
• offerings
Attribute
Process / Analyze /
Monitor
Digital Twin
representation
Context
(Real World)
capture actuate
update
notify
/
query

5. Modeling Context using Digital Twins
4
Tractor
• Location
• Speed
• Planed route
Crop
• Humidity
• Leaf area
• Age
Drone
• Location
• Battery level
• Speed
• Planed route
Attribute
Entities
(Digital Twins)
Process / Analyze /
Monitor
Digital Twin
representation
Context
(Real World)
capture actuate
update
notify
/
query

6. Modeling Context using Digital Twins
5
Pallet
• id
• product
• Items quantity
• Layers
• Size
• Weight
Transport robot
• Id
• location
• speed
• transported items
• destination
Operator
• Id
• location
• assigned task
• profile
Shopfloor Door
• Id
• location
• status (open/close)
Entities
(Digital Twins)
Process / Analyze /
Monitor
Digital Twin
representation
Context
(Real World)
capture actuate
update
notify
/
query

7. Modeling Context using Digital Twins
6
Wind Turbine
• location
• power
• wind speed
• pitch angle
Energy Storage
• active power
• reactive power
• SoC
• SoH
Substation
• Hi voltage
• Lo voltage
• nominal power
• power flow
Attribute
Entities
(Digital Twins)
Process / Analyze /
Monitor
Digital Twin
representation
Context
(Real World)
capture actuate
update
notify
/
query

8. Modeling Context using Digital Twins
7
Attribute
Tanker
• Driver
• Location
• Max Volume
• Current Level
• Speed
• Direction
Gas Tank
• Station
• Max Volume
• Current Level
• Min Threshold
• Temperature
Station
• Location
• Owner
• SLA
Entities
(Digital Twins)
Process / Analyze /
Monitor
Digital Twin
representation
Context
(Real World)
capture actuate
update
notify
/
query

9. What is a Digital Twin?
 Digital Twin = Digital representation of an asset
• Characterized by attributes
□ Properties
□ Relationships  Linked Data
• Values of attributes may change over time (or not)
• Typically have a location (but it is not a must requirement)
 (digital representation of) Context = Digital Twins Collection
 NGSI-LD provides a standard API for getting access to info
about Digital Twins:
• Simple and complex queries
• Geo-queries
• Temporal operations (Digital Twins have history!)
• Subscription/Notification support
• Multiple “renderings” of the data in responses/notifications
 Digital Twin = Asset Administrative Shell in RAMI 4.0
8

10. FIWARE Architecture: main concept
9
Process / Analyze /
Monitor
Digital Twin
representation
Context
(Real World)
capture actuate
update
notify
/
query
Application/Service
FIWARE NGSI API
Bus
• Location
• No. passengers
• Driver
• Licence plate
Citizen
• Name-Surname
• Birthday
• Preferences
• Location
• ToDo list
Shop
• Location
• Business name
• Franchise
• offerings
Context Broker

11. FIWARE Architecture
10
Process / Analyze / Monitor
Context (Real World)
capture actuate
Update
notify /
query
FIWARE Context Broker
Street
• location
• traffic
• pollution
Citizen claim
• location
• citizen id
• description
Waste Bin
• location
• capacity
Truck
• location
• route
• next stop
• time next stop

12. FIWARE Architecture
11
Data/APIManagement
PublicationMonetization
Core Context Management
(Context Broker)
Context
Processing, Analysis, Visualization
Interface to
IoT, Robotics and third party systems
Deploymenttools

13. Data/APIManagement
PublicationMonetization
Core Context Management
(Context Broker)
Context
Processing, Analysis, Visualization
Interface to
IoT, Robotics and third party systems
Deploymenttools
Mapping of FIWARE GEs
12
Core components
(Orion, Scorpio, Stellio
STH-Comet, Cygnus,
Cosmos QuantumLeap,
Draco)
Connection to the
Internet of Things
(IDAS, OpenMTC)
Real-time
processing of
context events
(Perseo)
Handling authorization
and access control to
APIs
(Keyrock, Wilma, APInf,
AuthZForce)
Publication and
Monetization of Context
Information
(CKAN extensions, IDRA
Data/API Biz Framework)
Creation of
Application
Dashboards
(Wirecloud)
Real-time
Processing of media
streams
(Kurento)
Business
Intelligenc
e
(Knowage)
Connection to robots
(Fast RTPS, Micro XRCE-
DDS)
Cloud Edge
(FogFlow)
Documents
exchange
(Domibus)

14. Vertical Smart Solution: Reference Architecture
13

15. Smart City Reference Architecture
14

16. Don’t forget we are on GitHub!
15
https://github.com/FIWARE

17. Support to NGSI-LD
16

18. Support to NGSI-LD
 FIWARE aims at the natural place where open source
implementations of NGSI-LD can be found:
• Orion-LD ( planned to merge with Orion)
• Scorpio
• Stellio
 Needs and feedback from the FIWARE Community are driving
incorporation of new functionalities in the NGSI-LD API specs
• Support to stream notifications in “raw” protocols
(MQTT, DDS, OPC-UA WebSocket, …)
• GeoJSON rendering of responses
• Attributes grouping
• … and more!
 Many components in the FIWARE Release planed for September
2020 will bring already support to NGSI-LD
• IoT Agents
• Context Connectors (Cygnus, Draco, Cosmos, …)
• Visualization/Monitoring (Knowage, Wirecloud)
17

19. Smart Data Models
18

20. Smart Data Models
▪ TM Forum and FIWARE Foundation
have setup the Smart Data Models
initiative aimed at bringing together
organizations towards definition of
common data models for multiple
application domains:
• Smart Cities
• Smart Energy
• Smart Water
• Smart Manufacturing
• …
▪ Data models rely on well-established ”de-
facto” standards
• General-purpose (e.g., schema.org)
• Domain specific (e.g., ISO/IEC CIM)
▪ Examples and validation schemas for
NGSIv2 and NGSI-LD are provided
19
https://github.com/smart-data-models

21. Blockchain / Distributed Ledger Technologies
20

22. FIWARE and DLTs
 Updates on context information are the essential transaction
that “Powered by FIWARE” systems manage
 Part of these transactions may be stored on a Distributed
Ledger, this way generating logs that will be immutable by
design and may provide the basis for enabling transparency
in, and auditing of, processes
 On the other hand, you don’t need to store all information
associated to transactions on context on the blockchain,
therefore relying on FIWARE Context Broker technology as
kind of off-chain storage
 Leveraging on connectors between FIWARE Context Broker
technology and DLTs, your application will not depend on a
specific DLT (and corresponding API) – the NGSI-LD API will
provide an abstraction layer
21

23. Canis-Major Adaptor
22
Canis Major
Adaptor
configuration:
- variables (to be
persist)
- blockchain config
- blockchain account
details (optional)
- contract ABI
Context Broker
subscriptio
n
update entity
with blockchain
details e.g; tx,
address,
contract address
(optional)
Support
● Enterprise Ethereum
● JP Morgan Quorum
● IOTA DAG
● Hyperledger Besu
● Hyperledger Sawtooth
v 0.1 will be releasing in End of
June 2020.
will showcase tutorial as well.
Next Update
● Neo
● Corda
● MultiChain
● etc.

24. Submitting data on the Distributed Ledger: communication Flow
23

25. Smart Cities Reference Architecture
24

26. Other work under way
 FIWARE LedgerSync
• Subscribe to Blockchain Events: Sawtooth (zeromq)
Listeners, Web3-Events, etc.
• FIWARE components can then be integrated to
process blockchain data
• v0.1 will come in september 2020
 DLT as native storage mechanism for the Context
Broker implementation of the NGSI-LD API
25

27. Interface to robotics
26

28. FIWARE Robotics: Key Enabling Technologies (short-medium term)
OPC UA
IoT Agent
Micro XRCE-DDS
SOSS- FIWARE
(Under Development, preliminary version ready)
Fast RTPS
ORION Context Broker
Smart Solutions Other FIWARE Enablers
FIROS
High Level OS
often proprietary
Robotics
Operating
system
layer
Adaptation
layer
Digital Twin
layer
Application
layer
Cyber-Physical Robotic System
(Single, Distributed and or Multi Robot Platform)

29. FIWARE Robotics: Key Enabling Technologies (long term)
OPC UA
IoT
Agent
SOSS-
FIWARE
Fast
RTPS
ORION Context Broker
Smart Solutions Other FIWARE Enablers
FIROS
High Level OS
often proprietary
Robotics
Operating
system
layer
Adaptation
layer
Digital Twin
layer
Application
layer
NGSI API (DDS binding)NGSI API (OPC-UA bindng) NGSI API (RESTful binding)
Micro XRCE-DDS
Cyber-Physical Robotic System
(Single, Distributed and or Multi Robot Platform)

30. Smart Robotics System agents powered by FIWARE
29
FIWARE Context Broker
Pallet builder
robot arm
Conveyor
belt
Package
Pallet
3D Digital Twin
Model and
Simulator
OPC-UA
IoT Agent
SOSS Agent
ROS2
(Fast DDS)
FIROS Agent
ROS
Low-level
protocol data
stream
actions
FIWARE NGSI API

31. Integrating robots and making them context-aware
 Each robotics systems exports a
well-defined NGSI-LD interface
 Sensor data (traditional IoT
devices) also feeding Context /
Digital Twin representation
 Definition of Common Smart
Data Models for Robotics
30

32. Manufacturing Execution Systems (MES) powered by FIWARE
31
Manufacturing Execution System

33. Data Marketplace / Data Economy
32

34. Shared Context / Digital Twin information would boost
innovative services and the development of a Data Economy
 Organizations in different domains could
interchange data based on a common Context /
Digital Twin Information Management layer
 Authorization and Access Control Policies govern
who can access what, when (Sovereign of Data)
 Organizations may monetize the data they offer
(Economy of Data)
33
Smart
Factory
Smart
Bank
Smart
Retail
Smart
Home
Smart
City
Virtual Shared Data Space
Smart
Servicesstandard
API

35. Main architectural elements
 Marketplace service
 Publication/Discovery service
 Clearing House service
 Identity provider (application level)
 PDP (Policy Decision Point)
 (Data) Provider
 (Data) Consumer
34
Loose coupling Principle !

36. Marketplace (1 of 5)
 Supports the definition of offerings around
digital assets (data sets are handled as such)
 Integrated with Identity Management and Data
Usage Policy Management frameworks
 Relying on TM Forum Business Ecosystem
Open APIs
35

37. Marketplace (2 of 5)
 Support for digital asset monetization,
including (but not limited to) data
 Even regarding data, multiple types:
• Files
• Right-time NGSI queries
• Data streams
• Media streams
• …
36

38. Marketplace (3 of 5)
 Multiple Price models:
• One time payments
• Subscriptions
• Pay-per-use
 Advanced models:
• Fees
• Discounts
• Dynamic pricing
37

39. Marketplace (4 of 5)
 Support for usage terms and conditions
and data-specific licenses
 Support for specifiying SLAs
38

40. Marketplace (5 of 5)
 Support for revenue sharing models
39

41. Publication and Discovery
 Several alternatives:
• Development of extensions to most popular
open data platforms
• Implementation of service supporting
NGSI-9 standard interface for registration
and discovery of data resources
 Extensions to most popular open data
platforms:
• CKAN (available and widely tested)
• OpenDataSoft (conversations)
 Integration with other FIWARE GEs:
• Idra (generic data publication platform)
• Wirecloud (mini-dashboards for
visualization of datasets)
40

42. Smart City Reference Architecture
41

43. Smart Farm Management Reference Architecture
42

44. Architecture - Layers
 Business Layer (TMF + FIWARE)
• Offering publication, discovery and
acquisition
• Payment management
• Revenue Sharing
 Data Layer (FIWARE)
• NGSI-LD API (offchain data)
• Access Control: API Proxy (PEP) +
PDP/PAP/PMP
 IdM
 IOTA Tangle
• Distributed catalog (TBD)
• PRP for policies, terms, agreements
• Storage of Charging Data Records
(CDRs): acquisition and usage
43
Data Layer Business Layer (BAE)
IOTA Tangle (PRP and CDR storage functionalities)
API Proxy (Auth + PEP + Log)
NGSI LD
PDP/
PAP/PM
P
GUI
TMF APIs
IdM
RSS

45. XACML principles
 A user sends a request which is intercepted by the Policy Enforcement Point (PEP)
 The PEP converts the request into a XACML authorization request
 The PEP forwards the authorization request to the Policy Decision Point (PDP)
 The PDP evaluates the authorization request against the policies it is configured with. The policies are acquired via
the Policy Retrieval Point (PRP) and managed by the Policy Administration Point (PAP)
 The PDP reaches a decision (Permit / Deny / NotApplicable / Indeterminate) and returns it to the PEP
44
Abbr. Term Description
PAP Policy Administration Point Point which manages access authorization policies
PDP Policy Decision Point Point which evaluates access requests against authorization policies before issuing access decisions
PEP Policy Enforcement Point
Point which intercepts user's access request to a resource, makes a decision request to the PDP to
obtain the access decisión (i.e. access to the resource is approved or rejected), and acts on the
received decision
PIP Policy Information Point The system entity that acts as a source of attribute values (i.e. a resource, subject, environment)
PRP Policy Retrieval Point
Point where the XACML access authorization policies are stored, typically a database or the
filesystem.

46. Auth CDRPEP
API Proxy
Architecture: interaction among components
PDP
PMP
PEP
PRP
deploy/revok
e
usage
policy
Context
Broker
PAP
policy rules
CDRs database
Business App
Ecosystem
Identity
Management
create offering
(terms)
set policy
(terms)

47. Auth CDRPEP
API Proxy
Architecture: interaction among components
PDP
PMP
PEP
PRP
deploy/revok
e
usage
policy
Context
Broker
PAP
policy rules
CDRs database
Business App
Ecosystem
Identity
Management
acquire (role,
dataset)
generate (acquisition
CDR)
generate
(agreement)

48. Auth LogPEP
API Proxy
request
Architecture: interaction among components
PDP
PMP
PEP
PRP
deploy/revok
e
usage
policy
(req +
user info)
decision
token
OK +
user info
Context
Broker
request
PAP
policy rules
CDRs database
Business App
Ecosystem
Identity
Management
access to CDRs
store (usage CDR)

49. Auth LogPEP
API Proxy
request
Architecture: interaction among components
PDP
PMP
PEP
PRP
deploy/revok
e
usage
policy
(req +
user info)
decision
token
OK +
user info
Context
Broker
request
PAP
policy rules
CDRs database
Business App
Ecosystem
Identity
Management
create offering
(terms)
acquire (role,
dataset)
set policy
(terms)
access to CDRs
generate (acquisition
CDR)
store (usage CDR)
generate
(agreement)

50. Marketplace of Plug&Play AI/BigData Services
49

51. How can we make BigData / AI services “plug & play” ?
50
Consumer Application
Big Data / AI
Service-1
Big Data / AI
Service-i
Big Data / AI
Service-n

52. The essence of the interface to an AI service
51
Big Data / AI
Service
Consumer
Application
data injection
results generation

53. … and make it as simple as building a LEGO construction?
52

54. What make LEGO successful?
53
Shape
Width
Height
Standards !!

55. The essence of the interface to an AI service (1/4)
54
Big Data / AI
Service
Consumer
Application

56. The essence of the interface to an AI service (2/4)
55
Big Data / AI
Service
Consumer
Application
Data Model
Data Integration API
=
(protocol + message format)
(REST = http + headers + payload)
Security Framework
Container 1 Container 2

57. The essence of the interface to an AI service (3/4)
56
Consumer Application
Big Data / AI
Service-1
Big Data / AI
Service-i
Big Data / AI
Service-n
Container 1 Container i Container n
Container X

58. The essence of the interface to an AI service (4/4)
57
Consumer Application
Big Data / AI
Service-1
Big Data / AI
Service-i
Big Data / AI
Service-n
Container 1 Container i Container n
Container X

59. KI MarktPlatz: Standards enabling plug&play integration
of AI Services
58
AI Service
Consumer
Application
Data Model
Common Data ModelsData Integration API
ETSI NGSI-LD
Security Framework
(Oauth/XACML - IDS)
Container 1 Container 2

60. A marketplace for plug & play AI services
59
Consumer Application
AI
Service-j
AI
Service-nAI
Service-1
Container 1
Container i Container n
Container X
AI
Service-i
Cloud Y
Cloud X
Offering description
• Data Model
• Terms and Conditions
(Security Framework ready)
• (NGSI-LD ready)
AI Marketplace Portal and Biz platform

61. A marketplace for plug & play AI services
60
Consumer Application
AI
Service-j
AI
Service-nAI
Service-1
Container 1
Container i Container n
Container X
AI
Service-i
Cloud Y
Cloud X
AI Marketplace Portal and Biz platform
Standards
?
activation
on premise
activation
on the
Cloud
Offering description
• Data Model
• Terms and Conditions
(Security Framework ready)
• (NGSI-LD ready)

62. Summary / Conclusions
61

63. Summary / Conclusions (1 of 2)
▪ How to materialize the concept of Digital Twin?
• Digital Twins match entities representing real and digital world
objects characterized by properties, describing the context
• We can leverage on a standard API to get access to info of a
Digital Twin (ETSI NGSI-LD) supported by multiple open source
implementations (FIWARE)
 A Digital Twin representation of Context brings the basis
for architectures integrating multiple technologies:
• Integration of data from IoT devices / Robotic systems as well as
information systems
• Distributed Ledger / Blockchain technologies as mechanisms to
register transactions on Digital Twins – trustworthy accounting,
transparency, forensics
• Digital Twin info as “coin of exchange” for Data Sharing, Brokering
and Trading (Data Marketplace)
• Digital Twin info as “raw material” over which processing (e.g., AI),
analysis (BigData) applies but also as mean for sharing results –
basis for a Marketplace of “Plug & Play” BigData/AI services
• Digital Twin Data Access and Usage Control required
62

64. Summary / Conclusions (2 of 2)
▪ Architectures gravitating around Digital Twin / Context
Information Management are applicable to:
▪ Vertical Smart Solutions solving specific challenges
▪ Whole Organizations, turning them into smart organizattons
following a “System of Systems” approach
▪ Properties in a System of Systems architecture:
• Extensibility (new systems can be added easily)
• Replaceability (systems can be replaced)
• Loose coupling (systems can evolve independently)
• Low intrusiveness (systems do not need to change)
• Recursiveness (systems of systems at different levels)
▪ Ingredients for trusted exchange of data among
organizations:
▪ Security Framework
▪ NGSI-LD API
▪ standard-based data models
63

65. Thank you!
http://fiware.org
Follow @FIWARE on Twitter
Juanjo Hierro
FIWARE Foundation CTO
juanjose.hierro@fiware.org
www.slideshare.net/JuanjoHierro