The document discusses Samsung Artificial Intelligence (SAMI), an open platform for connecting devices and building applications using device data. SAMI provides APIs and services for registering device types, connecting devices, and accessing live and historical device data. This allows developers to focus on applications while SAMI handles data storage, processing and APIs. Examples are provided of a home sensor device type manifest and an application accessing SAMI data to monitor and visualize sensor readings.
Welcome to the SAMI talk.
Today we’re going to present SAMI and what it means to developers and users.
Before we start, let’s talk about history a little bit.
!! be more personal
Why are we here?
In just a few years, most of us will have dozens if not hundred of connected devices. Health, SmartHome, Cars, Gadgets, etc.
Number of connected devices will be staggering
So:
-To prepare for this world
-To create REAL value for the users
=> WE the developers need change our approach, we need to understand a fundamental thing
E-V-E-R-Y-T-H-I-N-G
And for that:
-We need to adopt a new mindset
-We need A NEW PARADIGM
We’re INTRODUCING SAMI for this new paradigm
Everything is data = today there’s a lot of data. Tomorrow: orders of magnitude more
Any device: this is critical. Fully device & data agnostic
Break silos = true iot and data-based health will only work if there are no silos.
Open = any device, any data, any application
Any application = UI, data analysis, anything
DDD is an emerging concept
Big things always start with a small step
so let’s imagine a SIMPLE EXAMPLE
Explain the agenda of the prez with regards to that graphic
Time check=6’
A device is any source of data that needs to input it into SAMI or receive messages form the platform. In our example, this would be an instance of the new home sensor we are developing.
A device type is how we define the class of devices that will be used to create multiple instances of our home sensor. It is necessary to define it before any real devices can send data.
This is done using a Manifest, that is an essential part of defining a new Device Type. The Manifest is a contract that the creator of the device will implement.
The manifest defines what the data going into SAMI is, and how to generate that data based on what the device will send (input data format, json, xml, etc)
Normalizes: will be explained in a few slides
So let me quickly show you what our developer web site looks like when you want to create a new device type.
You specify a name (Display name), a unique name (this is akin to a package name, or a group id in maven). It identifies the device type in a human readable way and can be used with our api calls to reference that device type.
And finally the content of the manifest. We will see later what goes in that box.
So - don't click OK yet here... Before we submit our manifest we should actually have developed it locally.
How?
In your preferred IDE, using the tools we provide on our developer portal.
Those include:
- a manifest SDK (that you can use to check your manifest for compilation errors, to build unit tests, or simply try a manifest on the command line)
- A comprehensive documentation, tutorials, examples
The Manifest
Is a contract you implement. It:
- transforms any input data into normalized output data. So you could have csv, json, xml, base 64 encoded binary, etc. as long as it can be expressed as an input string that your manifest can understand.
- the output data are called fields and
- they have a name / identifier (e.g: temp)
- a type, we support the basic types you are used to, and collections of those types
- a unit, most units should be available SI and non SI and you can create new units if needed
Today we offer the full power of a Groovy script. Why Groovy? It’s a very simple and popular, scripting language so anyone can pick it up quickly and it allows you to read and transform any data using the full power of a programming language. The scripts have to be approved before they can run on SAMI, the approval is about making sure that the code is safe.
Tomorrow, we plan to offer a simplified version that require no approval for cases that require very little processing of the incoming data.
Let’s take a more detailed look at a Manifest:
Overview first - 3 main parts:
- Declaration: imports, implement Manifest, field descriptors (coming back to it later)
normalize() method, processes and transforms the data
getFieldDescriptors: describes the data coming out
Then dive in more details in each section.
Explain field descriptor: types, units
Explain getFieldDescriptors returning a list of FD
Explain normalize method, parsing CSV, creating field instances, using the unit the values are expressed in in the input, explain conversion
DAN
Explain that you can build test cases in java with JUnit and run it in your IDE or in a test environment
DAN
DAN
DAN
A quick way to visualize the data that your device is sending and is persisted in SAMI is to use our live and historical visualizer tool. This is available on our user portal, so as a developer having created one more more instances of your sensor you can go there to see what your sensor is sending in real time and check what was sent previously.
Time check=26’
JEROME
Mention permissions, restrictions etc.
JEROME
JEROME
JEROME
JEROME
JEROME
We have a foundation for analytics
Time check=31’
Demo sequence
Turn system on and visualize data on app (pre-recorded data with contraction)
Visualize data in SAMI explain what we’re looking at, explain that we’re integrating data streams from multiple devices (bloom & phone)
Show SAMI next to app screen show that there is almost no delay
Show history page (data retrieval)
Question
- Ok to use AirServer to visualize the app???
Time check=36’
Building applications: it’s you!
Remember, it’s Data Driven Development
You have the expertise, you can create any kind of app, small, big, UI, backend processes, etc.
And we are here to support you.
It’s a PLAYGROUND, there will be a way to monetize
JEROME
Beginning of a journey where Samsung and the developers will create new magical experiences for the user.
This is a playground, so we’re opening it in beta right now.
We will work closely with developers to tune the platform.