1
00:00:00,000 --> 00:00:07,760
So now if we step into the StepStone story, StepStone revolves around a patient named Charlie

2
00:00:07,760 --> 00:00:12,980
and how Charlie is leveraging soda and devices in the home to provide a better quality of

3
00:00:12,980 --> 00:00:16,200
life and interaction with his health care provider.

4
00:00:18,160 --> 00:00:23,260
So a common activity whenever you start to introduce devices into the home or to build

5
00:00:23,260 --> 00:00:28,380
on the StepStone story would be to introduce a new device to manage as well as a back-end

6
00:00:28,380 --> 00:00:30,980
application that would process this new set of information.

7
00:00:31,760 --> 00:00:36,320
Right, sort of that provisioning of a new node in the overall network, if you will, or a

8
00:00:36,320 --> 00:00:38,040
new device in the overall system.

9
00:00:39,140 --> 00:00:39,780
Right, right.

10
00:00:39,780 --> 00:00:43,680
And so for the scenario, we're not going to handle the provisioning side of it, but we'll

11
00:00:43,680 --> 00:00:50,160
show how those bundles can be easily started and provide a minimal impact to the application

12
00:00:50,160 --> 00:00:51,120
that's already up and running.

13
00:00:51,660 --> 00:00:58,140
So the applications, as we view them, we'll start a new one up and it'll automatically register

14
00:00:58,140 --> 00:01:02,860
itself with the simulator and it'll automatically register itself with the UI in the back-end.

15
00:01:03,000 --> 00:01:08,340
So what we'll do is we'll start with an edge server that will be in the home configured with

16
00:01:08,340 --> 00:01:09,260
a blood pressure monitor.

17
00:01:09,860 --> 00:01:12,480
And the first step would be to add a new device into that.

18
00:01:12,580 --> 00:01:14,460
Well, so first, we'll show the blood pressure monitor.

19
00:01:14,840 --> 00:01:18,680
We'll start up the back-end and show how messages flow between the blood pressure monitor

20
00:01:18,680 --> 00:01:20,600
and the back-end and how we can view the data.

21
00:01:21,140 --> 00:01:28,140
And the next step would be to actually start that new bundle for a weight scale and see

22
00:01:28,140 --> 00:01:34,360
how that registers itself with the simulator and also starting the back-end application and

23
00:01:34,360 --> 00:01:36,940
registering it with the UI while it's still running.

24
00:01:37,420 --> 00:01:41,860
So for the purposes of the demo, we're going to use a device simulator to generate the messages

25
00:01:41,860 --> 00:01:46,820
that you would typically receive from a physical device.

26
00:01:47,380 --> 00:01:47,560
Okay.

27
00:01:47,880 --> 00:02:02,860
So the first step is we'll go into the workspace for the edge and we have a pre-configured configuration

28
00:02:03,520 --> 00:02:04,780
for a simulated device.

29
00:02:05,880 --> 00:02:08,040
So we'll go ahead and start that up.

30
00:02:12,500 --> 00:02:15,640
If we take a look, so that automatically pops up the device simulator.

31
00:02:16,320 --> 00:02:16,680
Right.

32
00:02:18,100 --> 00:02:24,420
And we can see that there's a blood pressure application available.

33
00:02:25,380 --> 00:02:30,680
So if we click that, we can enter in changes to that and generate a reading that will get

34
00:02:30,680 --> 00:02:35,860
sent to the edge server, which is run on OSCI, and call a web service in the back-end.

35
00:02:35,880 --> 00:02:36,880
Right.

36
00:02:36,880 --> 00:02:39,780
So let's go ahead and start the back-end.

37
00:02:39,960 --> 00:02:43,340
So this is like a little Equinox runtime that you started up here?

38
00:02:44,580 --> 00:02:45,020
Yes.

39
00:02:45,120 --> 00:02:48,420
This is an Equinox runtime in Eclipse, using Eclipse.

40
00:02:49,200 --> 00:02:49,680
Right.

41
00:02:49,800 --> 00:02:50,460
That makes sense.

42
00:02:51,740 --> 00:03:02,700
So in our other workspace, which we have our back-end code, we'll start up the OSCI configuration

43
00:03:02,700 --> 00:03:04,900
for the demo bundle.

44
00:03:05,880 --> 00:03:16,760
Once that's started, we'll go over to the Seppstone page and refresh that.

45
00:03:16,960 --> 00:03:24,580
And we can see that right now, in this web application, there is one blood pressure device that's available.

46
00:03:25,840 --> 00:03:26,260
Right.

47
00:03:26,340 --> 00:03:29,480
And that's the simulated device that we started up at first, right?

48
00:03:30,080 --> 00:03:35,620
Well, so this is the back-end view of data related to that device.

49
00:03:35,940 --> 00:03:40,960
So the device actually connected to the edge, and then the edge forwards these readings to

50
00:03:40,960 --> 00:03:42,200
the back-end.

51
00:03:42,320 --> 00:03:44,820
So there's a database, which we're using Derby on the back-end.

52
00:03:45,160 --> 00:03:45,460
Uh-huh.

53
00:03:46,300 --> 00:03:53,640
And so basically, once that message comes across, the web service stores the data in the Derby database, and then this

54
00:03:53,640 --> 00:03:55,480
provides a presentation of that to you.

55
00:03:56,180 --> 00:03:56,720
Oh, okay.

56
00:03:56,940 --> 00:03:57,200
Right.

57
00:03:57,660 --> 00:04:00,760
So these are several readings that I took earlier today when testing.

58
00:04:01,280 --> 00:04:12,020
So if we toggle back over to the device simulator, we'll bump this up to 120, and share reading.

59
00:04:13,020 --> 00:04:24,520
So then we can toggle to our edge, and see that a reading was received, a message was filled, and the

60
00:04:24,520 --> 00:04:28,000
LA web service agent sent the message to the back-end.

61
00:04:28,780 --> 00:04:29,300
Right.

62
00:04:30,040 --> 00:04:34,500
And we can see that the blood pressure and the parameters were what we entered in.

63
00:04:35,140 --> 00:04:40,800
So if we go over to the console in the back-end, we can see that we received the web service

64
00:04:40,800 --> 00:04:47,540
for this communication, and indeed, it does match the parameters we passed from the edge.

65
00:04:48,340 --> 00:04:48,860
Right, right.

66
00:04:48,860 --> 00:04:56,160
So what we've seen is one of the edge essentially sending to the central database, if you will,

67
00:04:56,560 --> 00:04:57,920
the centralized SOA.

68
00:04:58,680 --> 00:04:59,000
Right.

69
00:04:59,300 --> 00:04:59,720
Absolutely.

70
00:05:00,700 --> 00:05:06,140
So if we click on the blood pressure and restart the page, we'll see that our new reading

71
00:05:06,140 --> 00:05:08,140
was stored.

72
00:05:09,500 --> 00:05:09,940
Great.

73
00:05:11,060 --> 00:05:14,520
So the next thing we would do is now we want to add the new device.

74
00:05:14,680 --> 00:05:18,840
And so to simplify the scenario, there are a number of different ways you can handle provisioning

75
00:05:18,840 --> 00:05:21,740
or installing new bundles into OSGI.

76
00:05:22,380 --> 00:05:24,220
So for this, we just didn't start them.

77
00:05:24,220 --> 00:05:29,100
So they're there, and they've been installed, and the assumption is some provisioning tool was

78
00:05:29,100 --> 00:05:29,820
used to do that.

79
00:05:30,420 --> 00:05:30,560
Right.

80
00:05:31,600 --> 00:05:44,760
So if we go back into the edge, we take a look to see what bundles are out there.

81
00:05:46,040 --> 00:05:57,140
You can see that the wait simulator, and the wait API, and the wait application.

82
00:05:57,860 --> 00:06:01,240
So we'll go ahead and start all four of those up.

83
00:06:01,980 --> 00:06:02,380
Okay.

84
00:06:04,240 --> 00:06:04,600
24.

85
00:06:12,520 --> 00:06:17,080
So you essentially looked up the, I guess, the IDs of the different bundles that were ready

86
00:06:17,080 --> 00:06:20,600
to be used in the runtime there and just started them up, right?

87
00:06:21,700 --> 00:06:27,260
And now I'm guessing we'll be able to see sort of new devices or new things when we go to

88
00:06:27,260 --> 00:06:28,680
the web screen there.

89
00:06:30,480 --> 00:06:32,740
Well, so we'll see new, so we're on the edge right now.

90
00:06:32,820 --> 00:06:35,220
So we'll see new devices in the device simulator.

91
00:06:35,760 --> 00:06:36,140
Okay.

92
00:06:36,220 --> 00:06:36,580
Right, right.

93
00:06:37,260 --> 00:06:40,900
If we go over to the device simulator, we see that we haven't restarted the device simulator,

94
00:06:41,080 --> 00:06:44,860
but we had a new wait application register itself.

95
00:06:45,380 --> 00:06:46,040
Right, right.

96
00:06:46,740 --> 00:06:48,460
So now we can click on the wait device.

97
00:06:49,000 --> 00:06:53,020
So before we send data over, we need to make sure that we have a back-end application to

98
00:06:53,020 --> 00:06:53,520
handle that.

99
00:06:53,980 --> 00:07:04,060
So we'll go back to the back-end, and we can go ahead and take a look here and see that

100
00:07:04,060 --> 00:07:13,560
we have a back-end data wait bundle that receives that data and also stores the web page and table

101
00:07:13,560 --> 00:07:14,960
to present that information.

102
00:07:15,240 --> 00:07:15,600
Right.

103
00:07:16,260 --> 00:07:23,100
So instead of starting it from the console here, there's an admin UI instead of stone.

104
00:07:23,620 --> 00:07:26,420
If you look at the bundles, the device bundles that are available.

105
00:07:26,780 --> 00:07:28,820
So we'll go into that admin server list.

106
00:07:30,320 --> 00:07:36,200
And we can see that the back-end data wait bundle is there, and it's resolved, but it's not started.

107
00:07:37,240 --> 00:07:42,500
So what we'll do, and we verify that in the console.

108
00:07:43,160 --> 00:07:48,520
We'll go ahead and update that guy, and we see that the state has changed to active.

109
00:07:50,300 --> 00:07:56,820
We can also verify that it was started in the OSGI run.

110
00:07:58,760 --> 00:08:00,420
So we see the data wait has started.

111
00:08:00,960 --> 00:08:01,440
Right, right.

112
00:08:02,800 --> 00:08:11,060
Now if we go back to the page, we see that a new device application has been registered in the UI.

113
00:08:11,500 --> 00:08:12,240
Right, for wait.

114
00:08:13,160 --> 00:08:13,640
Yeah.

115
00:08:14,000 --> 00:08:17,880
So there's already some data in the Derby database from testing earlier today.

116
00:08:17,900 --> 00:08:24,440
What we'll do is we'll go ahead and send that, a new reading from this newly started device.

117
00:08:24,520 --> 00:08:25,140
Send our reading.

118
00:08:26,260 --> 00:08:29,860
And similar to before, we can see that the SOAP envelope is created.

119
00:08:30,460 --> 00:08:30,680
Right.

120
00:08:30,800 --> 00:08:36,500
So a web services agent sends the message, and the parameters are sent across.

121
00:08:37,380 --> 00:08:47,920
So if we toggle over, we can see that that message was received through the web services communicator, and the values match.

122
00:08:48,200 --> 00:08:57,120
So if we go look at the back end and refresh the page, we'll see that the new reading was passed in.

123
00:08:57,600 --> 00:08:57,860
Right.

124
00:08:57,860 --> 00:09:01,660
One important thing to note is we didn't stop the runtime or any of the other bundles that were running.

125
00:09:01,800 --> 00:09:06,900
We were able to dynamically deploy a new device to both the edge and the back end server.

126
00:09:07,320 --> 00:09:07,680
Right.

127
00:09:08,400 --> 00:09:20,380
And while this was a pretty simple demonstration, once you start adding in more complex scenarios and remote deployments and provisioning, this becomes a very scalable platform for environments with dynamic applications.

128
00:09:20,560 --> 00:09:20,820
Right.

129
00:09:20,880 --> 00:09:30,420
Yeah, that was one of the impressions I had of the sort of why you guys were interested in OSGI for it was a large part being the sort of dynamic nature of things, right?

130
00:09:30,460 --> 00:09:36,120
That you can't expect people to restart servers or something like that when they deploy something new.

131
00:09:36,460 --> 00:09:45,920
And not to mention that there's a whole bunch of different devices or edges that might be out there, and you need more of a system that can manage hot deploying things, if you will,

132
00:09:46,000 --> 00:09:48,520
and hot undeploying them, to use an older term for it.

133
00:09:49,160 --> 00:09:56,780
But, yeah, I mean, that is a good demonstration of how you can dynamically add things, and, you know, I would hope to, you know, take them away as well.

134
00:09:56,780 --> 00:10:07,600
So it seems like, if I understand correctly, so you have various devices that you might have, and they sort of talk to a centralized edge server, if you will, or device or something.

135
00:10:07,700 --> 00:10:11,300
And that's kind of like the aggregator of a grouping of devices things.

136
00:10:11,400 --> 00:10:17,260
And then that edge server is responsible for talking to the more centralized sort of like SOA server somewhere.

137
00:10:17,440 --> 00:10:22,900
And the other thing is it provides a way to distribute some of that logic down to the edge.

138
00:10:22,900 --> 00:10:33,100
So if you combine events between devices, so if you only want to know perhaps something when a temperature reading is above a certain value,

139
00:10:33,820 --> 00:10:40,280
you can push that down to the edge, and you're not always talking to the enterprise to pass that information.

140
00:10:40,520 --> 00:10:49,040
Right, right, you can sort of add filters down there, if you will, or other things like that, so you don't waste precious resources in the centralized area.

141
00:10:49,960 --> 00:10:50,420
Right, right.

142
00:10:50,500 --> 00:10:52,800
So it provides a way to distribute that logic.

143
00:10:52,980 --> 00:10:53,480
Right, right.

144
00:10:53,580 --> 00:10:54,400
Yeah, that sounds good.

145
00:10:54,860 --> 00:11:00,960
So as far as the sort of generalized use of it, so you have the SOTA framework, right?

146
00:11:01,780 --> 00:11:08,780
And so the SOTA framework is just kind of that idea of the device, the edge server, and the centralized SOA thing, right?

147
00:11:09,320 --> 00:11:17,700
And the application that we were looking at that we were seeing was using it for medical device monitoring for sort of in-home things,

148
00:11:17,700 --> 00:11:20,820
as we saw in that Charlie video, right?

149
00:11:21,900 --> 00:11:22,340
Right.

150
00:11:22,780 --> 00:11:29,300
So it sounds like, you know, you don't have to be necessarily in the medical area to need something like this.

151
00:11:29,420 --> 00:11:37,440
You just, if there's some problem that you have that involves, you know, those three segments of information flow to and forth,

152
00:11:37,560 --> 00:11:39,180
it might be a handy architecture for you.

153
00:11:40,740 --> 00:11:41,180
Right.

154
00:11:41,180 --> 00:11:46,080
So the StepStone initial reference implementation was built around a healthcare scenario,

155
00:11:47,040 --> 00:11:55,800
but the same tooling and the same concepts could cross industry into energy and utilities, home automation, or other areas as well.

156
00:11:56,140 --> 00:11:56,520
Right.

157
00:11:56,680 --> 00:12:03,440
And do the devices, do you think they actually need to be physical devices, or could they be sort of software things as well?

158
00:12:05,520 --> 00:12:08,680
So it depends on the device.

159
00:12:08,680 --> 00:12:17,300
Right. Some devices are more low-level, which require using, you know, tooling such as DeviceKit,

160
00:12:17,420 --> 00:12:25,380
whereas other devices have a, I guess, a higher-level API.

161
00:12:25,800 --> 00:12:26,300
Oh, right.

162
00:12:26,920 --> 00:12:32,620
The thermostats that have simple web services available that you can talk to them over web services.

163
00:12:33,300 --> 00:12:34,220
Yeah, yeah.

164
00:12:34,220 --> 00:12:38,480
Those can still apply and be integrated into the SODA.

165
00:12:38,680 --> 00:12:44,560
But in general, the idea of the SODA thing is that you will have these sort of embedded devices out there.

166
00:12:44,700 --> 00:12:48,360
You can just, for example, use it for just computer-to-computer networking.

167
00:12:48,580 --> 00:12:52,720
Or, I mean, I guess maybe you could, but the intention is that it's embedded devices you use it for.

168
00:12:54,140 --> 00:12:58,920
Yeah, so that's typically the problem space we've been trying to address.

169
00:12:58,920 --> 00:13:03,220
So, like, what was the site that people could check the stuff out on?

170
00:13:03,300 --> 00:13:13,720
So, if you go to www.eclipse.org forward slash O-H-F forward slash compliance forward slash SODA.

171
00:13:15,280 --> 00:13:22,160
And that will provide you links to SAT, DeviceKit, SODA, the StepStone Reference Implementation,

172
00:13:22,720 --> 00:13:26,400
and then there are a number of other tooling projects available out there as well.

173
00:13:27,340 --> 00:13:28,440
Well, that sounds great.

174
00:13:28,540 --> 00:13:30,100
Well, thanks for taking the time to show us this.

175
00:13:30,240 --> 00:13:31,160
It was pretty exciting.

176
00:13:32,320 --> 00:13:32,920
Okay, great.

177
00:13:32,980 --> 00:13:33,780
Well, thank you for your time.

178
00:13:34,220 --> 00:13:34,780
Sure thing.