5. December 2019

SAP Leonardo IoT – Step-by-Step Quide to the First Application

The availability of sensors of many types, as well as of wireless and mobile networks, brings me to think about their practical usage. This blog was inspired by a ride in Tesla Model 3 car, during which the owner informed me, how the regular inspection of his vehicle works. In particular, my interest was attracted by the fact it is actually not so regular.

For common vehicles, the prescribed service interval ranges from 15000 km to 30000 km. That means that after driving this number of kilometers you have to visit the vehicle workshop for replacement of service fluids. But, what to do if after driving those kilometers are the properties of liquids within the standard tolerances and their replacement is not necessary?  Or, vice versa, what if they get worn out much sooner? Tesla has already resolved this question by the practical deployment of various sensors in combination with their attachment to the internet. This means you do not need to go to the workshop at preventive inspection deadlines. When limit values are reached, information is sent to the service center and the customer is proactively contacted by the Tesla company, to be invited to visit the service center.

In this practical demo, I will try to simulate a similar use-case with a fictive vehicle manufacturer „myElectro“, which produces electric vehicles and provides for service for their electric batteries in case they demonstrate symptoms of high wear. The platform used will be SAP Leonardo IoT.

The first step will be setting up one’s own Package, under which individual entities (vehicles) of the „myElectro“ manufacturer are produced.  

Leonardo_01

 

The second step is the creation of groups for individual measured values (Thing Properties Catalogue). From the dropdown list, select the recently created Package and click „+“.

Leonardo_02

 

By doing this, two groups of properties will be set up:

  1. battery_data – Measurable attributes of an electric battery
  2. location_data – terrestrial longitude and latitude, obtained from the GPS data of the sensor

Leonardo_03

By means of the „+“ button in the „Measured values“ section, stepwise add individual attributes.

Leonardo_04

 

For the group „battery_data“

Leonardo_05

 

For the group „location_data“

Leonardo_06

 

By means of the „Thing Modeler“ application (again, via the „+“ button), create a notion „Thing Type“. Under this term, you can imagine a sample (template), on the basis of which individual and specific vehicles will be created. From a technical viewpoint, this is a class, out of which individual entities (instances) will be stepwise created; in the SAP Leonardo IoT terminology this term is called „Things“.

 

Leonardo_07

After creating a new Thing Type, add to the Measured values 2 groups of properties created by you:

 

Leonardo_08

 

The last step is the creation of an instance of a specific vehicle – „New Thing“ button.

 

Leonardo_09

 

As this is a specific model, create its name as the name of a company – what about „myModel 3 “? 🙂

 

Leonardo_10

 

After the creation of an instance of a specific vehicle (myModel 3) with assigned groups of properties (battery + location data), it is the right time to create a rule on the basis of which the system evaluates that the battery is faulty and it needs to be serviced. At battery properties, you surely noticed that the battery data are duplicated – for battery block 1 and battery block 2. To find out whether the battery needs service or not, compare the values of voltage between those batteries. If the difference is higher than 3 Volts, the battery is certainly faulty.

First, create a Rule Context within which, in the following step, a rule for measured values will be created:

Leonardo_11

 

Give the rule the following name: „batteryVoltageDifferenceHigh“:

 

Leonardo_12

In the rule definition, set up the formula for calculation as follows:

 

Leonardo_13

 

Save and activate the rule.

The final step is the creation of an Action, which will react to the rule just created. The Action will send you an e-mail in case the rule is fulfilled.

Action definition:

 

Leonardo_14

 

At this moment, everything is prepared for the simulation of data gathering and evaluation.

Link to simulation: https://YOURINSTANCE.hana.ondemand.com/cp.portal/site#ActionModeler-Actions?sap-ui-app-id-hint=sap.appiot.ui.admin.modeler.actions&/simulator

 

Input data for testing:

 

Leonardo_15

 

After the launch of evaluation of the rule:

 

Leonardo_16

 

Into your mailbox, you will receive a notification regarding the difference of voltages (defined within the Action definition)

 

Leonardo_17

 

The options of utilization are virtually endless across all levels of industry and services. This is the way how automation can reach a totally different level. This is associated also with the satisfaction of the user, for whom those additional services can be decisive for buying a product or service.

This test case may show you, how simply the setting of SAP Leonardo IoT can look like, although it is just a demo. For uploading of data into the system, we used a demo. Real operation is, of course, automated and the values are entered into the system via MQTT API.

At such a quantity of data that can be generated in this way (depending on the frequency of sending and the number of IoT devices), it would not be effective to send them all to Cloud (Leonardo IoT). However, connectivity can still be a problem, which can be possibly not available at all times and in all locations. That is why SAP offers an option of so-called Edge services, where data are stored locally (internal server/RaspberryPi/…) and they are uploaded to Cloud in irregular intervals and only in limited quantities.

A new feature is also a possibility of integration to a Cloud service – SAP Field Service Management (FSM). However, for integration, you will need the product called SAP Cloud Platform  Integration (=cloud substitution of SAP XI/PI) and although the principle remains the same, integration is not such trivial as in our demo example. Anyway, it is not impossible; in the future, we can expand the recent implementation for test purposes also by the creation of a service ticket in SAP FSM.

And what about you? Do you have an idea on how to utilize this technology in your business?

Michal Babinec, Developer