1. Meta Data Deep Dive Part 1
Tech Talks – Session 4

2. Jim White Dell Distinguished Engineer & Senior Software Architect
From Dell End User Computing (EUC) CTO
Chief Architect and lead developer of Fuse
I wrote code line #1 
Fuse => EdgeX Foundry

3. Barcelona Release MVP The Technical Committee met last week in London
MVP, tasks and to-do’s were established for the “Barcelona” release
Release to coincide with the IoT Solutions World Congress in Barcelona
Oct 3-5
Our first community release
Please review the MVP and provide comments
Also laid out potential future release roadmap
Want to contribute to the MVP or additionally?
Please get in touch! We have lots of project ideas!

4. Agenda Meta Data's general purpose and background
Meta Data’s makeup – including technologies/libraries/tools used in Meta Data
Meta Data object model
Device, Device Service, Device Profile
Addressables
Device Report, ScheduleEvent, Schedule
Value Descriptors – from Core Data
REST API outline (categorizing the APIs by purpose)
Some important configuration settings
Notification
Persistence via Mongo
Q&A

5. Agenda for Meta Data Part II
Tyler Cox – (aka Dell Fuse super genius) – will cover next week…
Thursday Aug 3, 9am EDT
Meta Data Profile Details
Commands
Resources
Objects
Provisioning from a Meta Data perspective
Provisioning from a Device Service perspective

6. Big Picture and Meta Data

7. Meta Data’s Role
Is the repository of knowledge about the devices and sensors and how to communicate with them that is used by the other services, such as Core Data, Command, analytics, etc.
Specifically, Metadata has the following abilities:
Manages information about the devices and sensors connected to, and operated by, EdgeX Foundry
Knows the type, and organization of data reported by the devices and sensors
Knows how to command the devices and sensors
Meta data does not…
Do any data collection, but it knows what data is collected by which devices and which device services manage those devices
Issue commands, but it knows the commands that can be issued to any device
When Meta Data first comes up, it knows nothing and does nothing
It depends on Device Services to come up, report their existence and report the devices they have discovered and manage
It depends on API calls to identify new device services, devices, device profiles, schedules, etc.
Could provide a degree of security and protection of the data about the devices and how to communicate with them
Provides a warehouse of information to ensure incoming sensor data conforms to expectations

8. Meta Data Makeup
Created with Java/Spring Framework/Spring Boot/Spring MongoDB
Uses Spring MVC for REST communications
MongoDB underneath
Core data and Meta data use same instance of MongoDB, but different collections
Allows for separation if necessary or use of different DB technology if necessary
Dell has created a partial Go Core Data replacement
Working to open source that code later this summer or beyond
Again with no affect to the other service APIs
MongoDB
Core
Data
Collections
Meta
Data
Collections

9. Meta Data Triumvirate EdgeX
A Device represents a physical device or sensor
However, another EdgeX gateway or a system could be a “device”
Each device / sensor that is managed by EdgeX Foundry must be registered with Metadata and have a unique ID and name associated to it
Device services represent other micro services that manage one or more devices
Each device is associated to one and only one device service
Each device service has a unique ID and name
A Device Profile can be thought of as a template of a type or classification of Device.
A device profile provides general characteristics for the types of data a device sends and what types of commands or actions can be sent to the device
A device must be associated to a single device profile
More details about Device Profiles and device services next week
Each profile has a unique ID and name

10. Device Profile High Level Example
A BACNet thermostat device profile would provide general characteristics of thermostats
Specifically those communicating via the BACNet protocol
It would describe the types of data a BACnet thermostat sends
Current temperature (as a float and in Celsius)
Current humidity (as a float and a percentage)
It would describe what commands it responds to and how to send those commands
Get or Set the cooling set point (passing a float as a parameter)
Get or Set the heating set point (passing a float as a parameter)

11. Meta Data Model

12. Addressable
An object that represents some way to address a device or service
Could be an HTTP / REST address / endpoint
Could be an MQTT topic
Could be a 0MQ topic
Could be a …
Managed by Meta Data
Used by many micro services

13. Meta Data Device Service Startup Sequence

14. Meta Data Device Provisioning

15. Additional Meta Data Model Objects

16. Value Descriptor Remember these from Core Data model??
name: temperature
description: ambient temperature in Celsius
min: -25
max: 125
type: I (I = integer)
uomLabel: “C”
defaultValue: 25
formatting:"%s“
labels: [“room",“temp"]}
Remember these from Core Data model??
Provides context and unit of measure to a reading
Has a unique name
Specifies unit of measure for associated Reading value
Dictates special rules around the associated Reading value
Min value
Max value
Default value
These are also referenced in Meta Data
Device Profiles use Value Descriptors to describe the parameters to commands
Device Profiles use Value Descriptors to describe responses received when sending a command
Device Reports use Value Descriptors to describe data to be expected when devices send data

17. Controller Example
Meta Data Controllers look very similar to Core Data (or any micro service controller)
Follow MVC design pattern
Device Profile Controller
metadata/blob/master/src/main/java/org/edgexfoundry/controller/DeviceProfileController.java
Device Service Controller
metadata/blob/master/src/main/java/org/edgexfoundry/controller/DeviceServiceController.java
Device Controller
metadata/blob/master/src/main/java/org/edgexfoundry/controller/DeviceController.java

18. Meta Data REST APIs (categorized)
Device and Device Service APIs
Add (POST), Update (PUT), Remove (Delete)* devices
GET’s galore to query for Device by id, name, label, associated elements, etc.
SET’s (PUT) galore to update
op state and admin state
Last reported
Last connected
Device Profile APIs
Add (POST), Update (PUT), Remove (Delete)* profiles
Post can be done with JSON or YAML
GET’s galore to query for profile by id, name, label, manufacturer, etc.
* - deletes will trigger a check for associations before allowing the delete

19. Meta Data REST APIs (categorized)
Addressable APIs
Add (POST), Update (PUT), Remove (Delete)* addressables
GET’s galore to query for Addressable by id, name, topic, address url, port, etc.
* - deletes will trigger a check for associations before allowing the delete

20. Meta Data REST APIs (categorized)
Schedule APIs
Add (POST), Update (PUT), Remove (Delete)* schedules
GET’s to query for schedules by id, name
Schedule Event APIs
Add (POST), Update (PUT), Remove (Delete)* schedule events
GET’s to query for schedule events by id, name
Device Report APIs
Add (POST), Update (PUT), Remove (Delete)* device reports
GET’s to query for reports by id, name, device association
* - deletes will trigger a check for associations before allowing the delete

21. Meta Data REST APIs (categorized)
Misc APIs
Ping (good debug/checking mechanism)
Associated value descriptors for a device

22. Import / Unique Meta Data Config Options
Per application.properties (or via Consul Config/Registry service)
Notification information (an example of how to use the Alerts & Notification micro service)
Whether to post an alert on any device change (add, update, remove, …)
Information about where to send the notification and what to put in the notification message
Database configuration (location, user, pass, …)
Other standard config options
Service port
Location of associated micro services
Log levels
Read limits

23. EdgeX Tech Talks
Provide this new community with background on the current system
In the future, they may address future architecture or special calls to action
Currently scheduled for every week (Thursdays)
Alternating weekly times: 9am and 6pm ET
Trying to be sensitive to global attendance
Topics TBD – me suggestions

24. Upcoming Tech Talks Core Metadata Part 2 Core Command in-depth
Consul and Config/Registry micro service
Using the SDK to generate a device service
me other suggestions

25. Questions and Answer Time