<%BANNER%>

An OSGI based infrastructure for smart homes of the future

University of Florida Institutional Repository
xml version 1.0 encoding UTF-8
REPORT xmlns http:www.fcla.edudlsmddaitss xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.fcla.edudlsmddaitssdaitssReport.xsd
INGEST IEID E20110109_AAAAWU INGEST_TIME 2011-01-09T14:32:30Z PACKAGE UFE0000557_00001
AGREEMENT_INFO ACCOUNT UF PROJECT UFDC
FILES
FILE SIZE 66246 DFID F20110109_AABJSM ORIGIN DEPOSITOR PATH kuchibhotla_s_Page_65.QC.jpg GLOBAL false PRESERVATION BIT MESSAGE_DIGEST ALGORITHM MD5
cdaef8eb8f2417e2eec2d8b143d43e96
SHA-1
0ef516a33e38b174472ae932883fdb99bea788bf
8107 F20110109_AABJNP kuchibhotla_s_Page_69.pro
1e164eaa7ff1b080465e6865e8603dd0
0c109d703960476a3748d9003cdefbe8eaa47afa
5510 F20110109_AABJIR kuchibhotla_s_Page_03.jp2
cfa38990fec990c27d32f06c5cb75622
a51ab197b8303fc3217186f5853b2f256c0daaa2
560114 F20110109_AABJDU kuchibhotla_s_Page_56.jp2
05e7c276df854f680c04a486a10c167b
d7b39dcc7478d47a2dc0211a4ccc2fa30e87921f
21932 F20110109_AABJSN kuchibhotla_s_Page_65thm.jpg
4a7599624026631c7e60aadfe66b2e41
b95747723ac7c4ae9e09227132b8c02eb9051c01
454 F20110109_AABJNQ kuchibhotla_s_Page_01.txt
d2e24874ddd5cdbd346dc89c5cdd45ec
de0d7596819dfc4223a39398ab0cccd2df8f35ec
34611 F20110109_AABJIS kuchibhotla_s_Page_04.jp2
05e2d00cd7c62f39ca2576c52f5ecbe8
cdd6a7cbf3948bfc5756c7e63c24beaeb1df7d73
25271604 F20110109_AABJDV kuchibhotla_s_Page_63.tif
297640dd3fde71208a2b563f998fd1bd
732448464d3e31da5cc5938996a3d37d66611adf
70159 F20110109_AABJSO kuchibhotla_s_Page_66.QC.jpg
f249a31e85241117b662e139b99ff2fe
65709efecef8ddfa3c68fdeaaf4e19402b96d763
1051918 F20110109_AABJIT kuchibhotla_s_Page_05.jp2
1773fec4a842c0e533fc6bb819fe7ca1
a19296f5f65ccf8d94ab7f928f055fd691685576
18384 F20110109_AABJDW kuchibhotla_s_Page_09thm.jpg
9569af4bc347c2ecfaef433371030fe3
e16317af499782f0800a05be3e002d5f306cab67
116 F20110109_AABJNR kuchibhotla_s_Page_02.txt
ceab13f274f69cd5186e48586f3ae176
c180f0cebe2552e250793dd0e6f5a86873ff0e07
59734 F20110109_AABJSP kuchibhotla_s_Page_67.QC.jpg
f6238f27c8851bc79144757349e9e645
ea63e75147c3b6a8ab00599e0fef7cbd7c0ea32d
1051985 F20110109_AABJIU kuchibhotla_s_Page_06.jp2
59f6a37ade9fe33066b7b887a3582d93
042a96331ed277c7bbcb55fb9d3f3e6825821e24
34405 F20110109_AABJDX kuchibhotla_s_Page_09.pro
4115171de510f73a5b80889804102430
b22b26d44c5ca067e877b89e5c46fcfaced9d272
82 F20110109_AABJNS kuchibhotla_s_Page_03.txt
f8322a6a29e69d99b4089e2354259859
f53852e26db87b7e28f2eebd969b0732283a8555
19371 F20110109_AABJSQ kuchibhotla_s_Page_67thm.jpg
7572653b75ff54fcc60433d541587406
5b239573838da107ca73921f52fc31e459956813
1051980 F20110109_AABJIV kuchibhotla_s_Page_08.jp2
7cc60e645ed80e23416d1182e5f8ce3c
28e17fff7327f96342b9bfbd869cc0c7e4880ff9
34941 F20110109_AABJBA kuchibhotla_s_Page_37.pro
ca2707de730dce3cf75caf201f30b2a1
ea1cac4ea0a49605c4d01aac27c4a496c821169f
96805 F20110109_AABJDY kuchibhotla_s_Page_65.jp2
621a672c0f690287364904cd47d02f47
59a8796921d88edbb145c1cfa3e319d4f3bb0221
3528 F20110109_AABJNT kuchibhotla_s_Page_05.txt
f655e15c253036b56e5f69958e6441c4
4bbdcae54bf8032585745cf34596c9b3482958c8
76723 F20110109_AABJSR kuchibhotla_s_Page_68.QC.jpg
5b84eed91f35f863580eec27c5bc92a5
3e1ff74b684335b9add58d8d4d12672b026b4b34
73951 F20110109_AABJIW kuchibhotla_s_Page_10.jp2
a0f8ffcc1e6294adcf276f890084f303
64f456f1a3232a27c4185874ef820b46ae837a3c
123408 F20110109_AABJBB kuchibhotla_s_Page_23.jpg
8f305ac59ef72ed49ec40ebb1792f644
ffff0032578edfea8f567cc0a61aa86e3a400e7c
138799 F20110109_AABJDZ kuchibhotla_s_Page_10.jpg
b5c6a5f5142d26443094cdbbfdf96adf
8af553fe37efcc51873a58afcaca56068b25a378
6304 F20110109_AABJSS kuchibhotla_s_Page_69thm.jpg
e21defe283713048e785ab42357a32c2
20cf33e0711a371352857a14c0279785e1257fb3
88769 F20110109_AABJIX kuchibhotla_s_Page_11.jp2
c03ec3b323bde156c01c3f85e3c1102f
5fd1c1a7d4233c24012fa8c50ceb720243fed8ac
25198 F20110109_AABJBC kuchibhotla_s_Page_62.pro
5139ee8d8d26e376ed50f516ca34c29b
2a406e6a20c4d46ae23ce983951dd5d6f51b59ab
4509 F20110109_AABJNU kuchibhotla_s_Page_06.txt
3969c70f049abed66ed4d4fc85809207
967d6a51361a4d1a6cfb776ad65091adb560ef83
85329 F20110109_AABJST UFE0000557_00001.mets FULL
d8e3835e39fa74f800830e0c7a35aa30
29d73c9c79349513ca1c0c5e63e883b99191fd41
81247 F20110109_AABJGA kuchibhotla_s_Page_21.jp2
41bf717519f1a95725c21c0ccca4ce76
7d240d3ac2b3dcacf96a580cef2b96bc7bdc8f4e
100242 F20110109_AABJIY kuchibhotla_s_Page_15.jp2
19b9020430c8408fef3be186c35d05cb
7710dc23f2f325abb386b25d9d702c699b216b2d
182197 F20110109_AABJBD kuchibhotla_s_Page_38.jpg
b9197861a7de8a2d6f5b901f3943ca22
1c3a3907d29d09461176ce9d109f4fb86837277d
598 F20110109_AABJNV kuchibhotla_s_Page_07.txt
eab480be19c52e73b459154ac200d820
bfc28a30a35fe0ecd845a01b674ab01f7a1b4f26
1053954 F20110109_AABJGB kuchibhotla_s_Page_37.tif
645b3f9b54bb7d0588b944ecec65656d
5d8ba4a2200eff63d4b7e902b4ed187d13664d3d
107454 F20110109_AABJIZ kuchibhotla_s_Page_16.jp2
304be13d0c4bdbcdd1bd2018fbc0ec03
fc7c5867ee0ba26792334ba6c25deba5257ae52b
43713 F20110109_AABJBE kuchibhotla_s_Page_62thm.jpg
0a7bed2a255916b5379b62c608e1e581
04117e79f352922affffe6732bef1daab4e6743d
1532 F20110109_AABJNW kuchibhotla_s_Page_09.txt
c26552e306829ac83adf1abce9121257
ff2d709f04675377d7565321e3ab872a1e59c813
43667 F20110109_AABJGC kuchibhotla_s_Page_29.QC.jpg
25457b8a7ca74ca19862403e20ad88fb
37c8f3ba2a67a3266701a3065758a6865d055548
41412 F20110109_AABJBF kuchibhotla_s_Page_26thm.jpg
631fa5f2a51115c8c3c4169947f0422a
cf240bfedd6126a74221abcd7d2e2b4845e9e645
1311 F20110109_AABJNX kuchibhotla_s_Page_10.txt
7cefa5a1e017066d59589a4217c20a8b
4e5b96cfd9cab5c6f26834e8a6e2090cd590f349
59402 F20110109_AABJGD kuchibhotla_s_Page_23.jp2
1623f3847cb72b8017b7615a7eb7e314
50813736236caa4a50ca6d8305b92c4790de6c6a
24874 F20110109_AABJBG kuchibhotla_s_Page_70.pro
c9873a436b1b0f1e970bdf4c3331f65b
88af20d8429b54a82fda067698349372987d93d9
F20110109_AABJLA kuchibhotla_s_Page_28.tif
fad0e87bb8fde4e3fa83551ffb7e959e
bf654bd1d8c29ff3c24667a2718ce1b998a4c69e
1592 F20110109_AABJNY kuchibhotla_s_Page_12.txt
85d8fdee1d998771b5f7e70baffca4c6
8168401f2b85f0313ac57c01171278fed23f2739
43638 F20110109_AABJBH kuchibhotla_s_Page_52.pro
f8a252e69bc3c8ca54f07fc7ce207977
532cb374a427869e9340355cd0913bf626f87f0a
F20110109_AABJLB kuchibhotla_s_Page_29.tif
06673052e50a2414413dfc0f9c603a46
5d3814d45e336559ced0cf8a40db369acf6103f0
267 F20110109_AABJNZ kuchibhotla_s_Page_13.txt
e7f937e89394cc410af523114d83b363
9bf88ea635d226217bfebeb2470f1512176f8eb2
27100 F20110109_AABJGE kuchibhotla_s_Page_71.pro
afe7f27d2f6cc514e8c41a8bc6b0f800
d7544b946dbc082b7b24f7fc9d9d2976e45dfde1
F20110109_AABJLC kuchibhotla_s_Page_30.tif
2a3d1bed50206080315a60bff3a399e7
de0ea1dd7565a4a73d4da3c118cc8e205a0c5da9
20451 F20110109_AABJGF kuchibhotla_s_Page_12thm.jpg
75b1c9d40cb7b44d1bcd3b77d32f3081
233952b7b44b1e652bcf872b9a45df89076cd4f3
20866 F20110109_AABJQA kuchibhotla_s_Page_11thm.jpg
110ea366ff57b6a1bb8d30cdc928beed
db301e6fc6f20775e0a3f223b804764031eea543
67810 F20110109_AABJBI kuchibhotla_s_Page_60.jpg
e5da7ca219e498efd1e39fb23f17d441
cd94c0e4941ce130a7ae6132a9ceb9fe23bff5b4
F20110109_AABJLD kuchibhotla_s_Page_31.tif
8409c662ce10eb742fe39b6362c06f1b
8128e18ded52eb77da03ae8da671fd2b052decbc
43320 F20110109_AABJGG kuchibhotla_s_Page_49thm.jpg
e3e862302860323d639965590c4b5118
93a57816677ee79001f36826a6b6c5ef83b71432
58267 F20110109_AABJQB kuchibhotla_s_Page_12.QC.jpg
e9d4ca9a3cb26fe3e3683926a80844f9
db5f3cbf94a91b97023c60ac91a382b0239e6e35
1116 F20110109_AABJBJ kuchibhotla_s_Page_70.txt
9160d75dcc04c98e7b6c4cfb9cc974b5
f3d5a332ff2c27debb4f41f4a15fc6ba661e7f77
8423998 F20110109_AABJLE kuchibhotla_s_Page_32.tif
86c87d5f5d3bacda5f6b46950c006c91
c9b2bc0a1a6249744a55872644d577d5d37289a2
88087 F20110109_AABJGH kuchibhotla_s_Page_50.jp2
3c4d2ecc4db775620265061663dca0d3
104aafd202ce7a4902dd23ea7955fbab76d40070
14159 F20110109_AABJQC kuchibhotla_s_Page_13.QC.jpg
03576e99ff864e51e09ead2e0ae27e86
f21db4262432329f40472dc4facb15b41e2da5be
38359 F20110109_AABJBK kuchibhotla_s_Page_19.pro
b5ebf84bdc498ffa5d96a05f75f6a94f
c3977a1b0e603b5f1230281d14a54de84562f1fe
F20110109_AABJLF kuchibhotla_s_Page_33.tif
a9e8a26799100133a34054fe99c18abb
547f7422477b0ae3266cc22e0716aa5222a9facc
54813 F20110109_AABJGI kuchibhotla_s_Page_09.QC.jpg
5fbceee3c3906e1d1057e6a7b0bebf26
fdc00e975688a19a435e28f9f9bef770966f181f
5714 F20110109_AABJQD kuchibhotla_s_Page_13thm.jpg
22ff0b44cfacc34e7367ed7d6cba5480
8ee0151d785b9e4c937f4063efb9f476e6fa22a7
2062 F20110109_AABJBL kuchibhotla_s_Page_44.txt
b62910c5ed5aee1b69b6f2c103d3472c
9e5bbf1c016d4afb2f8807dbd2067c9c1f6950f6
F20110109_AABJLG kuchibhotla_s_Page_34.tif
fc53a42641173b5b4f3a3b0b32d38315
07e396510788fada38e72e42dcab1d0ab94f07b4
359 F20110109_AABJGJ kuchibhotla_s_Page_60.txt
c322a7174ce85c3b61303f5582f355d2
bf05846822616aa1416b70f067e48e4eb42bcf81
60087 F20110109_AABJQE kuchibhotla_s_Page_14.QC.jpg
be0960f47e023ef718fafb0110ff506a
ef248eb0282229fea706716f0faa6331008c0491
20242 F20110109_AABIZM kuchibhotla_s_Page_69.jp2
52a3ce8776c2a34d6ee86570e4ab0d11
32a1838972cd2703a2538630ed09b27e290cfb0e
146362 F20110109_AABJBM kuchibhotla_s_Page_47.jpg
44c9b78bbe62192a1a2fec09d2269551
be028779cddacfb120dca0f6a0598773ea1505c3
F20110109_AABJLH kuchibhotla_s_Page_35.tif
db7b5b33504e0efabfcebf78ec187ff9
9d1c4a720c10c83f42c3fc59e35443267d6eee61
78214 F20110109_AABJGK kuchibhotla_s_Page_09.jp2
bd33677e063cf83c9d471b5ac79180b2
613e9069ee4f8fab75afb5a8c1e7ee6f6ca89967
70066 F20110109_AABJQF kuchibhotla_s_Page_15.QC.jpg
2ab9f86c575445c320ce52ca061efe85
1ee8e0c8aa08b54ec52b986c6362f77187768251
33894 F20110109_AABIZN kuchibhotla_s_Page_55.pro
58c8beb82acf56af62e4014a08f13666
5ba3c7e586d6ab14f4670b490f039d1a524ac7c9
17239 F20110109_AABJBN kuchibhotla_s_Page_13.jp2
f8c98f342a5adb5c67252a0cb60c979e
689c2a6dd5ffa7059ae5715aedc537a4e4ffcd6d
F20110109_AABJLI kuchibhotla_s_Page_38.tif
42c62e20be47461edba68ee767126494
bad6afed7620d2d9398c4ad817c9fdb36456e55e
13882 F20110109_AABJGL kuchibhotla_s_Page_64.pro
ece63b51551dfc0d5d48684beae53b91
1d12c4bbc4c6c15d9387e3c384b0753abe15c815
70415 F20110109_AABJQG kuchibhotla_s_Page_16.QC.jpg
6c7235ec23aa8ddf6f2b163eb595935f
c4c9b972ee9869071ed3ebc2299b37a41ac9de72
63684 F20110109_AABIZO kuchibhotla_s_Page_52.QC.jpg
6c560706770119db3caf866962646f4a
8a5d29df2da236cd8f57e5a5de893e7a1b795a3c
159674 F20110109_AABJBO kuchibhotla_s_Page_19.jpg
27ce744a8829e50d1e4d4463d6fcdd70
149ad3de283af45e8b3d2d87b96d04b7ad220b25
F20110109_AABJLJ kuchibhotla_s_Page_39.tif
f535df762a0fdf494ad4e24100fc36a1
d8e552125f52d6625c36895252785ac550fbb74e
19351 F20110109_AABJGM kuchibhotla_s_Page_14thm.jpg
cae4d136cef84e91d5344a250a2f1eb2
4282c2de54b120a0b997c58075e2826b602458e7
17247 F20110109_AABJQH kuchibhotla_s_Page_17thm.jpg
92e6ecf9d464083be2ab814475095716
39ebe3066f2cef5ce05929eb83355bd2202605b6
68359 F20110109_AABIZP kuchibhotla_s_Page_22.QC.jpg
65971f3f84b08e6ba392dab4a1c94c85
aab23075d022675fb57087383261eddee75769a9
994 F20110109_AABJBP kuchibhotla_s_Page_47.txt
497a02b0c9721f790670677108645f2a
bc178ce1150b55bd383e50e5498238dd16e37446
F20110109_AABJLK kuchibhotla_s_Page_40.tif
6e552a59ebfd783bddcd51035897e2aa
3405b5585e706280c81fcb92bef7f346b62f1bdf
46502 F20110109_AABJQI kuchibhotla_s_Page_18.QC.jpg
7642158f60436756dcff82e57903b7a3
5499b6568cde7ca468660aba31f52e80650546e1
94056 F20110109_AABIZQ kuchibhotla_s_Page_38.jp2
a9b3d46eb620d8ee59914e048d22d280
8adb25e1e93edb43a09f5ca36c106fe4a0e3585a
30591 F20110109_AABJBQ kuchibhotla_s_Page_24.QC.jpg
862bbe3bdd6cb1fd95d8ef04fe7918fe
3504c186ac2f6df902a20e035b6d454ff8229a8d
F20110109_AABJLL kuchibhotla_s_Page_42.tif
c56678fb72fb114b0c17f6c283460f54
ab3b497737e7f1fa8209026640e50b0ca1640083
19821 F20110109_AABJGN kuchibhotla_s_Page_61thm.jpg
b4d465c6de0910a079f4c5a28ca4e00d
7110c6ee1e4ef321e31eeb63322daf00ab084a4a
15672 F20110109_AABJQJ kuchibhotla_s_Page_18thm.jpg
e324ff7ccad903affeaebb78e99096f9
1a3dddee2f0ed467850374f5db4206ff9fd92afe
34095 F20110109_AABIZR kuchibhotla_s_Page_13.jpg
57d36aa837b0352e976a68413682ad2b
0ae22fe15f8dffd19909eb7fafcf660052d4c16a
F20110109_AABJBR kuchibhotla_s_Page_49.tif
55adcda95ff70c40b9cbfb2ac9a5de70
2085ec76a91946c67e3f0bd9fd2259b5cc942b48
F20110109_AABJLM kuchibhotla_s_Page_43.tif
8f56fa66e7fb3ea1ca2606f2b0f98936
3a0220f53e063c46a571ecd5d626ee3e84daeff0
69204 F20110109_AABJGO kuchibhotla_s_Page_27.QC.jpg
3e083a23f4bde1bd6c85257c7ee90d19
ad99408305fab4b4143bf93deabceac16dcdeeb4
58594 F20110109_AABJQK kuchibhotla_s_Page_19.QC.jpg
fe909968856f4bbf7732d65bc66f1ab8
dda0e111a76ea0ebef3844eb618ce3204eab25c0
F20110109_AABIZS kuchibhotla_s_Page_23.tif
1d9ddd325f302e8f265de801eef4f5e9
5d28afc96348c9e0021cb24cdc8154576d1fa10b
169345 F20110109_AABJBS kuchibhotla_s_Page_50.jpg
8fdbc9140d06ac07863bfae5ec8ae0c1
0c500fa85d0f1ba096c82658724281f959693196
F20110109_AABJLN kuchibhotla_s_Page_44.tif
9411d79a3120ff5e002cf63c4ca24902
8d2e39b5c35a51e84d0334416744eeceae392b61
69083 F20110109_AABJGP kuchibhotla_s_Page_70.QC.jpg
3b0e02cb65141186642a07d4a13a72d8
9332786b0153ccfdc730d8a9368eec3a2d758ac6
52338 F20110109_AABJQL kuchibhotla_s_Page_20.QC.jpg
acaa7d57d4cf37c4eb3db158a9fb5ef1
cba5e58f0a0eab34de2fda89de2a31b54ee792aa
209524 F20110109_AABIZT kuchibhotla_s_Page_44.jpg
b66028728eb78c5738cc76185f22d2ae
01fc1e7ed6b73a23d3037c484634fcb933f41acb
F20110109_AABJBT kuchibhotla_s_Page_57.tif
b4cbf3d1c485bdfeeaebc69fd421b4ad
fe0e7cebdab114b6e099a2de5fb7c2438f48ba2c
F20110109_AABJLO kuchibhotla_s_Page_45.tif
20ab088ddbb6249d4c238108d6d727fc
62c10f91e2c88505aef1b22cd60d274293ae7d9a
36242 F20110109_AABJGQ kuchibhotla_s_Page_67.pro
7f87915d1d10a01afe633b8f2ae01ff9
758e385a1a50e75a606ad5c2e1fcee92cae911ea
59012 F20110109_AABJQM kuchibhotla_s_Page_21.QC.jpg
3fc03c9cdc5ce6ef933c79a1d795bd5f
2437b3af622684912dd55c2a53defafe6a2ec78b
889 F20110109_AABIZU kuchibhotla_s_Page_03.pro
d912e99ab7715ee4b9ec25034dc47118
d4501d5d2cf3b65811a0d5fbe63bd71812482e98
15840 F20110109_AABJBU kuchibhotla_s_Page_71thm.jpg
b4dd5fd2a2e6a0a903312d202157b814
829c66d393a72904bce3843ad03502ebdb17b693
F20110109_AABJLP kuchibhotla_s_Page_46.tif
b8821c235c6c9a7c27abdb7cb39ae8f3
9b7e6ecae06bb740f1ae93d7983abb7874c31cc6
110590 F20110109_AABJGR UFE0000557_00001.xml
258b0995da537ef52d6ba74c43369548
7cf07b914d3d4c86d8d274782a485ac7fc4bea21
22924 F20110109_AABJQN kuchibhotla_s_Page_22thm.jpg
c849619a17e9277bb9e372081fc6b655
98ce57152b5565de66e2bc5fc5f3085d5989f7b3
632 F20110109_AABIZV kuchibhotla_s_Page_04.txt
4926c4f7c80758d39aee3e853aa4b280
f9d8bdcede13cd9f863b91e9323320f0277073a9
72599 F20110109_AABJBV kuchibhotla_s_Page_08.pro
ae2cabb327ec6404b4ff7abd979aef70
ae29bc92c0f6455e1e337bb69b071b36576c1d44
F20110109_AABJLQ kuchibhotla_s_Page_47.tif
778c200915f95b2be04efa7032399abd
21e59e19f434815b9c7822a3ced0f21671cea45d
45651 F20110109_AABJQO kuchibhotla_s_Page_23.QC.jpg
249f005093927cdffe0245a937da4769
c5c9e34779b7fd46ef14082cfccc1ef1ede77b82
52167 F20110109_AABIZW kuchibhotla_s_Page_17.QC.jpg
36eb9224472e98e7c8fae13ab6352b95
fd3b979329f67a4c2e28208d3cdaa3c7064bb117
F20110109_AABJBW kuchibhotla_s_Page_64.tif
32bbb87f24c368fb1b713d0efcfcbc22
db35b8ba129c51441cd4a87035a111a8311507b4
F20110109_AABJLR kuchibhotla_s_Page_51.tif
0ea28276bcc44bef41ec2c950999a5ea
72920c24e0b0cf6988ddcfb6a2e2a83edc006dfd
15547 F20110109_AABJQP kuchibhotla_s_Page_23thm.jpg
e93e92c7beb146cd5a1538c8858a2c76
eb79e07d756f496a0942f8a41789540d9103696b
F20110109_AABIZX kuchibhotla_s_Page_08.tif
2d8b29b1458517e18075388da7da127d
2a42c4275a2db41dd20b7bb8ab8ad5bf5fc904b8
49684 F20110109_AABJBX kuchibhotla_s_Page_57.QC.jpg
df2e3ddd978b117962524da080d7e757
2550df38c6083f42412375eb0ab90d789330c88c
53444 F20110109_AABJGU kuchibhotla_s_Page_01.jpg
d8301ba88374e62fe3202bd64d1bce9a
70e34cc6e4975507e71e82e453ea27db40186ab1
10574 F20110109_AABJQQ kuchibhotla_s_Page_24thm.jpg
018f04f4187fc86de0ff99eb3047cb26
32fc725612b91fb485cd627fb13f42200a8543f1
71764 F20110109_AABIZY kuchibhotla_s_Page_25.QC.jpg
2c647313b3072df0e8029d1acd592b1f
c3f7ddf6dcc3fea1cff3ee3b2dd2b080e663e380
163646 F20110109_AABJBY kuchibhotla_s_Page_40.jpg
1c97157b18537742d5d6409c28e46a19
1c3279dbd46535eaec345ebe30a3ec901deac566
F20110109_AABJLS kuchibhotla_s_Page_53.tif
07f0ae60e422bbcdf554f7e1977d3a68
348552d96f07185c4c7d0cea3c45f76aeb5761be
15515 F20110109_AABJGV kuchibhotla_s_Page_02.jpg
b4c8e6062154b5bd2b43074046ae2f87
69e7cc8b3b65d7c9a55f96af14d91f1c7a743809
68407 F20110109_AABJQR kuchibhotla_s_Page_26.QC.jpg
d82ebe88f6b4809cfc607d4b3ffce2c8
341a310587e2fca9f95f8c9bb14822d738a16027
24144 F20110109_AABJBZ kuchibhotla_s_Page_68thm.jpg
793c0aa83593831c3a816dbaece7b955
86cd3c2e455696ba6ca218d458dc783fdd64d542
F20110109_AABJLT kuchibhotla_s_Page_54.tif
e71c3ba791e15a17563a962d6fea4c37
6815bc2ce0fd9ae25339dc5612b6934e7032c8f2
14504 F20110109_AABJGW kuchibhotla_s_Page_03.jpg
b408bcadbadd7bb655403408f439defa
aa15b89732fea07e3547ffc96119df5c0ba99ff9
41110 F20110109_AABIZZ kuchibhotla_s_Page_66thm.jpg
0568b7dc2d8aacbd120f3feee048104c
3b23c0000ac6c65b5e21a5c07ed9935bd1b144ce
23528 F20110109_AABJQS kuchibhotla_s_Page_27thm.jpg
2fb57c38e4415abe19a262089e2e7cbd
e30d1e6bc82a90b8d81295f3d067ffdc54e473f9
F20110109_AABJLU kuchibhotla_s_Page_55.tif
de2881d1739c7a6e617e2adee1de72ab
cec05c43271b47391d8dff1d15e149b2f0560a4f
67943 F20110109_AABJGX kuchibhotla_s_Page_04.jpg
6a348deb97183b73febbb6bf6933a7c5
87aaa953e89fbba652dfc9c004763c33e9e42ce6
63617 F20110109_AABJQT kuchibhotla_s_Page_28.QC.jpg
e553f98c58dda6eaa87f4263935900f8
748c2fdb7b9a55026f9ec058312135212cdae913
F20110109_AABJLV kuchibhotla_s_Page_56.tif
b2e996a5ad489502ff18ba05f03e5c2e
79f0a1d4c118ae907e36a1e3c8bff2d1d2bf1bf3
23448 F20110109_AABJEA kuchibhotla_s_Page_20thm.jpg
ea2d07978f8dd495430f59ec625da055
6f0161e965364def6c047d516caad01e07641153
78565 F20110109_AABJGY kuchibhotla_s_Page_07.jpg
7312e3bde587e6d6105ada4768f9fcb2
7c05e9f1d4be987c0a7db72dcb6d44959abadc00
14705 F20110109_AABJQU kuchibhotla_s_Page_29thm.jpg
18efd6c833ccf39738a78ad21f429a71
81b753fb7d61e4e483a4e04ce8ec3c73d094a6af
F20110109_AABJLW kuchibhotla_s_Page_58.tif
0edcedcd0095de33e83371addcb2e0cb
530043c5b0bb209121b3f11069241ae950c4b679
1441 F20110109_AABJEB kuchibhotla_s_Page_37.txt
5c5704f8ee7c25e3f0337d389bc98ad7
19452df2faae74dfebfa89e2af8867ac2c21a9c1
246427 F20110109_AABJGZ kuchibhotla_s_Page_08.jpg
ac23a44130428df2b837af913cc4cfea
496187c0a3e434e0b80810d77399c9a2c5a62b58
11649 F20110109_AABJQV kuchibhotla_s_Page_31thm.jpg
6d6abc3f1aba4f94056ce5019f126eaa
a5977f354307cd2b631e0371c9d4f8c286e4edf7
F20110109_AABJLX kuchibhotla_s_Page_60.tif
5d32b6af4f3f11207b998c109b58765d
899fa4fa98d73ff62be5fd439278211f42930bfa
19853 F20110109_AABJEC kuchibhotla_s_Page_33thm.jpg
4d3549a9bdf09decd8f014e7ea41cd10
222ed33887db20d5281bc20895361672e2775c63
55728 F20110109_AABJQW kuchibhotla_s_Page_32.QC.jpg
5cf919328808b5090c1677c80d3bcb47
dcf5d0998079cba5d55a279c05b71c52b8d5da12
F20110109_AABJLY kuchibhotla_s_Page_62.tif
f8d62e5368f7fb4b254e3be8d4b2fe20
74e1abd6809001cc7ed62b1f7a11aa3d0ec24d5c
60827 F20110109_AABJED kuchibhotla_s_Page_30.QC.jpg
8199222e1c880fc5b43016b0b989cd1d
6f16f3816233950f9c581b1f6e17e6473fd5b650
71082 F20110109_AABJJA kuchibhotla_s_Page_17.jp2
84ddf8dba9a05c59395c9f82d7d3b784
79f9088858cab30ce59aabc45356e6a67cb88852
F20110109_AABJLZ kuchibhotla_s_Page_65.tif
f83ac0b9398a8bae7a8a86705fa78617
28c089e75a37589fcdfe6547f9391b26f859b4c1
15996 F20110109_AABJEE kuchibhotla_s_Page_60thm.jpg
40a83f57cf1958bd4457281375580263
95924dd5a222ea8dbaed4e0b1253dec0cb4a5813
55825 F20110109_AABJJB kuchibhotla_s_Page_18.jp2
ec86c2ef57e53ca8265be01b6592ae99
eea5d8ede64da940a75bfb1534e69b50f6ebaa99
65281 F20110109_AABJQX kuchibhotla_s_Page_33.QC.jpg
4ab75f70c3694266f4b608e786360e99
ace5ec14e1f060037f1498cf25b3f77579a37e29
75109 F20110109_AABJEF kuchibhotla_s_Page_58.jp2
6805975231e8781baeb4b4f6e048ed5a
3a918dcb17094d2b84deec71627b4d19bd3abf50
83136 F20110109_AABJJC kuchibhotla_s_Page_19.jp2
6fb045cdf1173f73d06c78ae36371e65
b41f1e03145c8fa6f512d0ae11668de3de838c02
72732 F20110109_AABJQY kuchibhotla_s_Page_34.QC.jpg
89f56241857e9e903655b2375d2c3e85
101b62bead5f5a96381aeb6532e0ac247ca5fa8b
F20110109_AABJEG kuchibhotla_s_Page_48.tif
eee7c20c55d443dd58181955923b9b23
8d71e11fb0ddbd910cc92b7fd8005f72892d3fcd
1606 F20110109_AABJOA kuchibhotla_s_Page_14.txt
e407c65eaaafc022d2a3200eeec9eb10
8d283e54bb704df168ec7bbe610c26472d38f822
95029 F20110109_AABJJD kuchibhotla_s_Page_22.jp2
7b982fd8628205dfecc2bb03861aeea0
2526c3687d0d05a9f28ea92e6f173bb83f2aec27
23681 F20110109_AABJQZ kuchibhotla_s_Page_34thm.jpg
c010e1e9e4a768761df853033fff4625
32278961dcc7d8272cf41188ade9eb1fe11a1711
2547 F20110109_AABJEH kuchibhotla_s_Page_68.txt
b1f4eb4454d89ea7a6e96d6eece2a665
464574b323b20957555a1c67876b31997e26cc48
2033 F20110109_AABJOB kuchibhotla_s_Page_15.txt
02fc025c4a99d829e1c769aad4ed8e73
fb4c26a71d3c6d882d393849cecbdf9b024213bd
91463 F20110109_AABJJE kuchibhotla_s_Page_28.jp2
2ee071c7dd289c802c2a2406d9f057af
c0041060bbc9d10d7d96dddbf345b1cdb6065993
2891 F20110109_AABJEI kuchibhotla_s_Page_08.txt
d64047853c4f38f4758ff486c66a1c00
256d9c243f41a9fafbc6dd9ae41c5844de2de83a
2270 F20110109_AABJOC kuchibhotla_s_Page_16.txt
43fb7ee383db33306ba747a6791a899e
49e76db116f25919f4612e604ae2777d69506ecb
59530 F20110109_AABJJF kuchibhotla_s_Page_29.jp2
18196e87047fa95baa7de877e1be1706
4ab724da1fabeaa4695b46696863518cb07473c5
F20110109_AABJEJ kuchibhotla_s_Page_68.tif
189fe382f9aa3e82f9842fa44d675163
08667aa7659ecfb5251eb1b40a8b63d86408c268
1627 F20110109_AABJOD kuchibhotla_s_Page_17.txt
37038af42033a09b62745b9680b913c0
ac7c1cab827a80781c5e591a36c957c57fe88947
82800 F20110109_AABJJG kuchibhotla_s_Page_30.jp2
8eb6acf993e41ee66e457a5f5eab65b8
9ce660bc1e3628437b0ad5d4ff95d602470662c8
1016 F20110109_AABJEK kuchibhotla_s_Page_62.txt
c0f31c6421eee9cecfc7ae3ce778f287
9bfe061e81aa63d7fdcf3833f6e9f5fbc60b9181
1435 F20110109_AABJOE kuchibhotla_s_Page_18.txt
625a9daf77383ed371d46fa2a050f964
c79caa953d564393004641c4adda0d500bf8708d
672167 F20110109_AABJJH kuchibhotla_s_Page_32.jp2
120c7f9ae59ab22a223db0e21dd5376c
daa8a14054232c955b2b67d3619c17918cb6eba7
1580 F20110109_AABJOF kuchibhotla_s_Page_19.txt
114250e30595dd4fee1f429cbdf6d37a
b58e622dd12ba319a6b2906a1f73d1f5313047aa
81066 F20110109_AABJJI kuchibhotla_s_Page_33.jp2
11571c55038aafb092edec4967ac26ef
c878b853a16226ce3442642598fca23afd3602d9
47130 F20110109_AABJEL kuchibhotla_s_Page_63thm.jpg
7be2ff57c6ea6f05de86b93a0a4fbc79
4897f8e4acf3a066226afa6fa30e1fc3dff0425b
914 F20110109_AABJOG kuchibhotla_s_Page_20.txt
5f2c7c03a1917fb7e8c17afdc761c110
5a6625b5e972254984627469e7df40031d0e4e3a
99848 F20110109_AABJJJ kuchibhotla_s_Page_34.jp2
371a64487e835ac8c1098f92f5b26ab5
f4101ccda43965fa4032c817e69bc47806035209
19268 F20110109_AABJEM kuchibhotla_s_Page_19thm.jpg
321cddf588d43efa667e42b0721179ce
7c4c3f799efbd766969600ab56cac2a2179180ff
1752 F20110109_AABJOH kuchibhotla_s_Page_22.txt
c7e0dbfc114e0365ce1bb02ce71c89e9
0ffca50a3fea7c49c61ff72ab3964be22396f06e
92866 F20110109_AABJJK kuchibhotla_s_Page_35.jp2
7ea83a7e357ef3c47b084fd72bfc7f26
91439d31fa04335198ae9b0faf7275fc7a50f6cd
44469 F20110109_AABJEN kuchibhotla_s_Page_71.QC.jpg
9f1a0e8673f034a2dc65234d8d118824
ba2f3c9378631478c037a6c4a1a248ab527bcb7b
1158 F20110109_AABJOI kuchibhotla_s_Page_23.txt
a021448dcfee9bb679a284cd5b6948dd
7c093b0c790b323cc765f392e01cc025e9cd61a7
97789 F20110109_AABJJL kuchibhotla_s_Page_36.jp2
755cd4ef0b8ffbd2854f9e7a8b977feb
6050d96b914ab33539e38f5d854befffc7c2c7fe
158651 F20110109_AABJEO kuchibhotla_s_Page_45.jpg
8db09d468fc7bb094ed51287a00f017d
57e0e1a2405103477b6157ff0b18c0d223a04b98
698 F20110109_AABJOJ kuchibhotla_s_Page_24.txt
9d15434a2bdfb7cf4db5b766180716b1
d433b3b3c49db91854368003a14947bb3def86d3
80280 F20110109_AABJJM kuchibhotla_s_Page_37.jp2
e4ceb67f6e14233b667f6ac45baa8387
f40fc760cc606da73eab666b0a2fd93b193bb898
17035 F20110109_AABJEP kuchibhotla_s_Page_10thm.jpg
3621be4f122b6e2252707f4a4c978c77
017a878ab9f4381ce37638e1a9e40c17261bef66
1030 F20110109_AABJOK kuchibhotla_s_Page_26.txt
3ca85d483e67f44e811ac012b393f51c
adfc540bca84ac91dfec149b3c9a023d7a2c3a5e
741947 F20110109_AABJJN kuchibhotla_s_Page_40.jp2
b03a129aac5eed86b88c779a9ca89dfa
8f9d7a464432b9b570f758fa57840536ad5b8f37
69474 F20110109_AABJEQ kuchibhotla_s_Page_35.QC.jpg
92295ccc9779ea18b7a7694d5adb9f92
dfa515c28e186f845f83b53aa8f1bda7f621b472
1288 F20110109_AABJOL kuchibhotla_s_Page_29.txt
d7cc4f7f76d27eac6689f1ebec535dfd
02643b76429e2779c8ef5b7c8ea55af2c9ea7913
533861 F20110109_AABJJO kuchibhotla_s_Page_42.jp2
e1983d2da64cf6a209deb4036f018c81
f3dea38e94d808d72d5f88c9e77ce65225c4978f
40716 F20110109_AABJER kuchibhotla_s_Page_24.jp2
b9ab56ec43cb153943d22f06619dac7d
ebc095a336dcc2c3782a44039ca11d3dc1d3963f
1584 F20110109_AABJOM kuchibhotla_s_Page_30.txt
c56ae8567bf55b7d950883fd4aa3530a
121e17d74d26b580515edfada53dd9c107c1b6c4
68110 F20110109_AABJJP kuchibhotla_s_Page_43.jp2
48d7a41fecc8ee8a25b10c544a113e53
fbd02482087f9537154c22e0e2a6e27f0b3a2e60
186422 F20110109_AABJES kuchibhotla_s_Page_27.jpg
2999fe017ebb2ecf64dabda29ae73376
fd9912a427b142209b006a9366a80a066dce63b7
755 F20110109_AABJON kuchibhotla_s_Page_31.txt
7d39f0c798850cf18017ac7041d77593
e415b252f3945d1e3fec9f9e729d4fb6fcb038dc
123097 F20110109_AABJET kuchibhotla_s_Page_56.jpg
eca2fde8cf0f2fdf57cc92b32eda97df
5b216c91d268d8cff469a39c804f3baa4e7660e0
1384 F20110109_AABJOO kuchibhotla_s_Page_32.txt
b519cda1be5737923b9a345307b52b90
dcc498a7c315ec413ec972d5dd6e9607ce4bff2f
107391 F20110109_AABJJQ kuchibhotla_s_Page_44.jp2
64866ba695c53c2821ae8144c20059cc
c38d6c067d6406dc6e041b3b07ab0eb057bef2e0
159882 F20110109_AABJEU kuchibhotla_s_Page_14.jpg
7ebf23524f0dd116d21ca6265470f2d1
2f053c76274466d3edb47da3b42f8fcea1566bde
1807 F20110109_AABJOP kuchibhotla_s_Page_36.txt
6c2365f2e16364d1c10d4ec8f937732f
459e164447e634c3a2bae2e73122100d78e2a08f
83273 F20110109_AABJJR kuchibhotla_s_Page_45.jp2
43f6b2323d2e7185a621a392d5dcafe3
28a369f5c98dd4cb60b3925742b15b18acdde5f4
F20110109_AABJEV kuchibhotla_s_Page_52.tif
074b3dfa9f84e500b705bb99ceeaf0da
2cb16abcd940c37d1942a2dfc7e9ba158663a80c
1720 F20110109_AABJOQ kuchibhotla_s_Page_38.txt
2baba942b7e04e3bbc90ff71d2508515
cb8bf611ef066b26523d31db23c08678d9c35013
920429 F20110109_AABJJS kuchibhotla_s_Page_46.jp2
cf55988602ae61b8a1b87dd4405dcdf5
c6a9377d4f3d03040e29c2bcfc6567fbf154dff2
283417 F20110109_AABJEW kuchibhotla_s_Page_05.jpg
33a36894943de9a196c27ef5fb884722
c199f99a0cef249ddab69a6a73955b108553a03f
1901 F20110109_AABJOR kuchibhotla_s_Page_39.txt
eebbfb2c8f1e186213d3f753c5c1a03f
0a382401ad0e83d95a73c89c421524df9001cfce
697894 F20110109_AABJJT kuchibhotla_s_Page_47.jp2
3e0862144c368b43e14e1666ced4858d
09e7982943a645067656e289f183fcd9f706a839
28698 F20110109_AABJEX kuchibhotla_s_Page_57.pro
09d864d72889ff0b9a452dd9f5901bd8
b0c48235dba7b7cb934cf9cf3ee8273391e07e71
1374 F20110109_AABJOS kuchibhotla_s_Page_40.txt
ec91f23d6af27c30408e8bfd8be1b9aa
22e02ce9038354b51e6846b105182edf81c2464b
704481 F20110109_AABJJU kuchibhotla_s_Page_49.jp2
e997671b47f5569ad59d60ae665bf58d
89b2ffc71769e546b6e25dca7e498d7e8abdc181
82879 F20110109_AABJEY kuchibhotla_s_Page_48.jp2
77c024cd0d8d81cccbb1d93b27302db4
40342bb84be77ddf93b0c398b039b9616630e51b
1629 F20110109_AABJOT kuchibhotla_s_Page_41.txt
1aca735795bbac0914c421d19e7854f8
ea11c35c2500462cc1f060e7ea8c141d424b35f0
57271 F20110109_AABJJV kuchibhotla_s_Page_51.jp2
10e418bacea3ac73f52da73a3778852f
ddd1d4e515b966aa52f797b3fa16fc99df4ba5b0
2000 F20110109_AABJCA kuchibhotla_s_Page_25.txt
d0f49de42c93bf1f01af315bcd7215b6
477c5ffbfb0a596efd2ad26339862eba449ed8b3
1672 F20110109_AABJEZ kuchibhotla_s_Page_33.txt
e63ed8deb55069bbf660589a2531ae93
cdd57db243513f78a0ae805a530d602785ee083d
989 F20110109_AABJOU kuchibhotla_s_Page_42.txt
804c28cb566522c1a180b6a505eac5e0
1a49625333879a0a21a5660d9dc1e484d601c2fb
596656 F20110109_AABJJW kuchibhotla_s_Page_53.jp2
20a9dd51ef49209b9a4dea80ec0fd312
e5e31b6422571c8804d7bc975fa1dad979e9a201
73248 F20110109_AABJCB kuchibhotla_s_Page_59.jp2
fd73f49cfd39430b4b594fb6ddc7b078
8fed3ddd506c47b7032c655e31257ac1037b2899
746376 F20110109_AABJJX kuchibhotla_s_Page_54.jp2
6146bb6a719d1290eb96c742ff5ac37a
5c0d23bf630ff1ded1305f2b50600c45d13359d9
44357 F20110109_AABJCC kuchibhotla_s_Page_54thm.jpg
57e67c55c52c59d6bedd8fafa1f3f119
50ce484967f608439dc1ff85098203d09039c3e6
1595 F20110109_AABJOV kuchibhotla_s_Page_45.txt
0ec435bb5531b42a718338f9015b19b5
f88581960334316eb4c14099de1bfb49cc625849
154020 F20110109_AABJHA kuchibhotla_s_Page_09.jpg
49323045730768cf83fbd12ce65c8f82
553d8a9ef7585e37a560df61e9896c2cfc3e2500
67444 F20110109_AABJJY kuchibhotla_s_Page_57.jp2
075908cdda83060339113fcc15601e4a
c555749d84b47b3aea1e119df40f0bcf36832630
791 F20110109_AABJCD kuchibhotla_s_Page_63.txt
0832fe854c2a2fb86bd2b0f717ed9484
c3ed1e1266a48cc65ffd00678825b837b8091f6b
2101 F20110109_AABJOW kuchibhotla_s_Page_46.txt
a2ea366df1fd910ca81c99f4a1f88669
b4a22d4dbac1f71d45c5a55eae9dda225bc6d0f9
169919 F20110109_AABJHB kuchibhotla_s_Page_11.jpg
b809ec0fce75908a25bafbe50bea0ebd
5299034a2de3dbf6f9ea7d901156613e01fd79e9
85567 F20110109_AABJJZ kuchibhotla_s_Page_61.jp2
69a23f2bde629f0ea051258eab25c271
9ff35f9df1bf9fd8034ec1e61d698cad6de3da4f
50412 F20110109_AABJCE kuchibhotla_s_Page_42.QC.jpg
ddc28827b2a10a417be138802f98df34
7006d664662ec9715ca57220c07ecacdea3644a8
1576 F20110109_AABJOX kuchibhotla_s_Page_48.txt
da60c931953a24c4bb53b864508627b7
ef78489ab2e47768d780c48b2205452b06d65d9f
159931 F20110109_AABJHC kuchibhotla_s_Page_12.jpg
f396f1de5db13d2a25b398b770f6a05d
4bb6a7a5531f3a52ce875e450e7bd51cf59ef77b
20405 F20110109_AABJCF kuchibhotla_s_Page_28thm.jpg
1ed0f0b02ea39bbcc1f4d60befd32038
a97130b57a2d678b6d1b86ec4f54b4f812c4ccf6
1375 F20110109_AABJOY kuchibhotla_s_Page_49.txt
0b15c9e29fc7b7c009605c6f1ab4d929
0f88254d2e142bd457b6747bf9c6ff26bd2e8b83
194306 F20110109_AABJHD kuchibhotla_s_Page_15.jpg
9a64ca2e480a8bfa58c490ad255f7d3b
99e948651f740bfc061765de653a142da1947f73
28218 F20110109_AABJCG kuchibhotla_s_Page_40.pro
c26ff0c52f27209ebcf64a2391e26078
ed544fce98443b67fc79476a7a7b64b774036e05
F20110109_AABJMA kuchibhotla_s_Page_66.tif
b9b5185e7a7c4571e781a465171086f0
2076dfc0ce5afbb2202e553e46393c0873c14640
1639 F20110109_AABJOZ kuchibhotla_s_Page_50.txt
bfb71d4ed61fbed89713a2a5c0734af5
6335853f8334b52fe3ec52cfb36e2c363a86e254
209305 F20110109_AABJHE kuchibhotla_s_Page_16.jpg
eaa65bf4bf912792e124e40356153bf7
b83b49b96da704801da43f162dc89b9a0cbf8bda
83988 F20110109_AABJCH kuchibhotla_s_Page_14.jp2
2be57b1674874d31a01f5203a1731117
5919e38418ab2cc893315a6ae0e457d1f174d51c
F20110109_AABJMB kuchibhotla_s_Page_67.tif
c11ba0a237878d7ed941514516f36481
2916f10bf4fc9efcf0ac8b6c128b6fcd647ca49d
138266 F20110109_AABJHF kuchibhotla_s_Page_17.jpg
6dc11392f8474fefdaa45f687dfd7233
d272e3421a4578292fc0ea96df835d76df0ed89a
45883 F20110109_AABJCI kuchibhotla_s_Page_08thm.jpg
7a22e0957c93239da4b5d78081edab32
14098ee6388c0cc679cca03986b6c80da4e1ae1c
F20110109_AABJMC kuchibhotla_s_Page_69.tif
1a13e8434ac9043f6286988c47db6a40
0c358101b64e3acd2b3c4b7ae324cef8037227bb
22201 F20110109_AABJRA kuchibhotla_s_Page_35thm.jpg
08b14b1ff544cfeae8c3d3b18fbbdda9
5181decf181620050e53967bc2e9070e473810fe
130691 F20110109_AABJHG kuchibhotla_s_Page_18.jpg
a08b4995567bd6fbe7331cb76c2ec166
6ff6b3a6a3642df37bc279f056d873ab22780b9a
F20110109_AABJMD kuchibhotla_s_Page_70.tif
85bb4ecaf6a2a50688ca935c5fb3738c
90e48afb44fd9a8a1c730302f52afba92de8870d
68991 F20110109_AABJRB kuchibhotla_s_Page_36.QC.jpg
5c4c28b58bb3abd4182ae778eb5dd04e
55e26cd9328d8b06a9fc4d1677676800914d921d
156756 F20110109_AABJHH kuchibhotla_s_Page_21.jpg
46105b8c315aad453ddcd9e53272b3e8
f8dce25b31eb0b3d424593898ab21ebb1dabe001
699024 F20110109_AABJCJ kuchibhotla_s_Page_26.jp2
27fc107569655cacbcabba62219e5d85
9c2e05dead7557766f5a1248a2f648cb5e83b8ec
7618 F20110109_AABJME kuchibhotla_s_Page_01.pro
ccee9039ac43eee28ea627206334c1c8
49e6a1baa3c708a76fecb6a02bb124d64355063a
22875 F20110109_AABJRC kuchibhotla_s_Page_36thm.jpg
2906708d9960ba4946bd3e4de0835ce3
85e744a16a80657cc02a9e124203369ed9f79026
185023 F20110109_AABJHI kuchibhotla_s_Page_22.jpg
5cea703df36e8fa4ccea9f9a7447b2e5
cf9849d7961554f3a84f7b190d04e1229348a36a
18809 F20110109_AABJCK kuchibhotla_s_Page_21thm.jpg
6dd1bf8018ca32129474e23e6d6d4cd4
ae2bec0d4005d5513ff45771d3700ddc339c16a0
1387 F20110109_AABJMF kuchibhotla_s_Page_02.pro
a3112681ae606e1a45bd1a53e8d88ddb
c5c1812d7f607a678d2a58f76cc123431618b77a
54996 F20110109_AABJRD kuchibhotla_s_Page_37.QC.jpg
e7147f69db7e47a170c5c1964039fbb1
0746efea58f73edd8f462c2f6a44cdac7a0c8378
77871 F20110109_AABJHJ kuchibhotla_s_Page_24.jpg
05d124f73b6252f8218aa98d546dc255
1cc48d2816d2d4ccae09ac064ae69991d43df9bf
21019 F20110109_AABJCL kuchibhotla_s_Page_50thm.jpg
a8e2bb22dc15d6c00561ede808b80bd8
de16c719b913ad533a9260ed840fb32227e6b63b
114299 F20110109_AABJMG kuchibhotla_s_Page_06.pro
33cc21a890ab7382683200fa3bc0c785
8c30bc8aa88eda2f4ec12f690b08ac20f1af6373
19080 F20110109_AABJRE kuchibhotla_s_Page_37thm.jpg
074c5c65693a3b4c7a35e0fd5df0449b
96503b690c1f873a3572d43f6a7b27b88f32b13b
147825 F20110109_AABJHK kuchibhotla_s_Page_26.jpg
cfdf03b10d37045b849f4c4a1b3ed939
04a1e26d10d10e8691e8fdfba4fdfa32591fbe5b
1868 F20110109_AABJCM kuchibhotla_s_Page_27.txt
bc1ceb8ae9082d45fa3d06c4d8792f54
90379099aa0ec556d91d89cc2cc5178c24f3c84b
13068 F20110109_AABJMH kuchibhotla_s_Page_07.pro
54f9b170532cbdc4ccb7307c13b2e9a7
5aa58ffdef6a6ed0140003fe395871b15c9252d6
21869 F20110109_AABJRF kuchibhotla_s_Page_38thm.jpg
23008bce1819c6c7731721792dc3f5a5
05dd8402470907cc8cb586531f200f3a4a917841
169899 F20110109_AABJHL kuchibhotla_s_Page_28.jpg
d7c55bb9ef9dd8b0241d85148433bb69
b7ec6043b23a6c1497a39df0e116d9b468227f0f
1141 F20110109_AABJCN kuchibhotla_s_Page_53.txt
f353a42cfeecd4c4a350f18ab8828dbc
4718db1379ee75b7e5bc6feb29a82c5fc826f417
39701 F20110109_AABJMI kuchibhotla_s_Page_11.pro
d54bf41abf17fb14abc8b884e56cd969
d4478d169466a8a0cec0d153776ccd42d7db1452
68863 F20110109_AABJRG kuchibhotla_s_Page_39.QC.jpg
6d5f74081698a5047eac1c17e84af2df
5a14b93e1e9928d0d17939c3f394b95ad8628ad1
119642 F20110109_AABJHM kuchibhotla_s_Page_29.jpg
3f09eca888666b885a1401549666fb7a
c19be6dad7e8596fca96b0decdc31a5a870834d2
1421 F20110109_AABJCO kuchibhotla_s_Page_54.txt
559fb554af134e56dd98a8fee14af27e
46ffe441171b91e559acb5f068fe45a80114ea49
37398 F20110109_AABJMJ kuchibhotla_s_Page_14.pro
76eaf57facc5b0a943b23989048018d8
22b599a8c9895dcd52648b7d096743f3b7eac617
21841 F20110109_AABJRH kuchibhotla_s_Page_39thm.jpg
82cb7c603d37221258318fa40c3a95d4
5a20813a9c5a2d7f9d15649f90ff109df42bb346
160101 F20110109_AABJHN kuchibhotla_s_Page_30.jpg
dd8f00ef54a5f1a46ee652ffcb6020b2
9a7dbc938ae66202d0cde0c1363f6e038dc9b327
6483 F20110109_AABJCP kuchibhotla_s_Page_13.pro
78cac51596e214b5ac23b8f197eaf1e5
c1e3f78d7c2e1b34ab9efb57f660681b202420a8
46215 F20110109_AABJMK kuchibhotla_s_Page_15.pro
e425fe7a81e5cf12cbc8b4dd506f556a
8c96667f2ca1b35f3581dc7dcb0e374b9dc0031d
26288 F20110109_AABJRI kuchibhotla_s_Page_40thm.jpg
2f8bd345ff014b52878c1d9a7f99128c
ecf9dff76201fd26dc4e42e43e44af83268c0f1e
F20110109_AABJCQ kuchibhotla_s_Page_41.tif
a47e6d070b430218ba1a5b9d18a7f5c2
0ef10b579e4e2cca7ab813db3e7795385cfff730
31394 F20110109_AABJML kuchibhotla_s_Page_17.pro
7d968e31084be939acd517418c3bfd45
b41c9afc1335a9eca0ec02891c40f54438a9eaaf
61101 F20110109_AABJRJ kuchibhotla_s_Page_41.QC.jpg
725fbc2be5f5349410236713baf8c2b1
ddd767449101766e8887f34a1d43101aafba218c
91607 F20110109_AABJHO kuchibhotla_s_Page_31.jpg
5d4ccfe6ab8b9261565e6e8c5f9d25fa
6ba0f6de79a9606512c2daa0e37387edbcba2e69
103142 F20110109_AABJCR kuchibhotla_s_Page_05.QC.jpg
61005b8132f3e15aeb30d3cd7700dbac
cc4cef3e8896ed0ec033dcebdbfb18e747490a64
29536 F20110109_AABJMM kuchibhotla_s_Page_18.pro
3045d903df93e08e14b69fd268135e37
bbd21d186ceb17f82cd0b02fdcb122e0dd32a9f5
19321 F20110109_AABJRK kuchibhotla_s_Page_41thm.jpg
42d8c5bbb4d311929ae2ff609bf50104
697e90b99cd8543d454ee6629302d199a3436fca
141772 F20110109_AABJHP kuchibhotla_s_Page_32.jpg
cb46e5b393bb747d04e83c1e574158a6
6999a73a506d8f84b73524dd5bb7f1f1d938267e
38036 F20110109_AABJCS kuchibhotla_s_Page_12.pro
58b2aed48787762e047138ecd593fb29
a5de8c36795cdfec6ddd685ecb25d241ba7b33f0
21803 F20110109_AABJMN kuchibhotla_s_Page_20.pro
35098814d50b8415724f18eb721573db
278450da5281a1a44b736bfdf274dba1345a9e14
23098 F20110109_AABJRL kuchibhotla_s_Page_42thm.jpg
12085becf2714cb83080697d0365e45f
da68261ecec550349c1c58f4c33c4a8b2e82d684
163130 F20110109_AABJHQ kuchibhotla_s_Page_33.jpg
6d1cd6d6638328d7e284a4a95271011a
038271a1267ccbd098ac3b7a0443e0ec8fc63d35
42545 F20110109_AABJCT kuchibhotla_s_Page_38.pro
5a75e32d4b3857cb9955278ad94027af
8a3634de662c0d073150982064187e1852b104a5
35671 F20110109_AABJMO kuchibhotla_s_Page_21.pro
9e0b81b143994d7fe2f7edf4d2b71abe
9c85cfe22da02fe5c40ad1e3df81fda955d2e8ac
51133 F20110109_AABJRM kuchibhotla_s_Page_43.QC.jpg
782a1d9cad96eef1ad7cd79654ff65aa
1f9fcc69a003b657211613f5177bfd43d502e69c
192132 F20110109_AABJHR kuchibhotla_s_Page_34.jpg
af8c02be997862f21dc9c301385dc7f6
f1948e29a2ac6fdacbec2cd998c5506c48bf8a08
99950 F20110109_AABJCU kuchibhotla_s_Page_39.jp2
72f0aaf9d0c44aa834370fb7e90c0b08
bce090589495836e6478d06a169c33bf2db8e911
43699 F20110109_AABJMP kuchibhotla_s_Page_22.pro
570cb60a71845ce5ca3937285942a43c
ce9aeb7a7926443720a4a473d08b9a5726068d8d
75666 F20110109_AABJRN kuchibhotla_s_Page_44.QC.jpg
722f73432d03e44e6520e0c4683e0608
80865c5d3bc7dc20f7fa40d8df9d318375510c1c
179962 F20110109_AABJHS kuchibhotla_s_Page_35.jpg
8fe8b3f3d7b59b04893ce784eee3a69c
653a5191bb51566fbce1c355eb5758109e971e20
F20110109_AABJCV kuchibhotla_s_Page_25.tif
c10e2bc1827f68cceb08ad57425f1cdf
ffee490a2180ce8c2940749234fa82857a976a7d
17192 F20110109_AABJMQ kuchibhotla_s_Page_24.pro
16945b1a0448d67a42da9ef605a4d69b
2c7132f466218b775e5949a69f50539b267675a5
25292 F20110109_AABJRO kuchibhotla_s_Page_44thm.jpg
f63e6764a911bd0522cda39c6dc04077
a4c856809390270504b1373b2a35e70e0f4171e8
183614 F20110109_AABJHT kuchibhotla_s_Page_36.jpg
68ed51393c067ee610fdfc06facc260c
6ca82ff10e261376627193155272af6761162e97
64546 F20110109_AABJCW kuchibhotla_s_Page_40.QC.jpg
75eeaeeef23111d8c11abfa01f85b934
d126f92258b5eb4c9597f834f6a498db67220979
19589 F20110109_AABJMR kuchibhotla_s_Page_26.pro
6717162a961803ab5cc39bd29ba8dcda
1973d7e492f8b5af37fcdc9ae4d3a7979ef94acb
60912 F20110109_AABJRP kuchibhotla_s_Page_45.QC.jpg
1bb241c666ea74f9450054ab327f8225
987d6eb282b8e5358bdcd43366f6ad85a0e1bf0f
187000 F20110109_AABJHU kuchibhotla_s_Page_39.jpg
89f60abf9bdd32ad5e23d14cc897e892
905a1d0d60916a73bd96bfd4783d4d37ec50dc94
96290 F20110109_AABJCX kuchibhotla_s_Page_64.QC.jpg
a2d1325ab1604d8b08447693c4d8c3e6
c5c06ee2bbe3bd73439b6a6c158f64d61a408e3c
45842 F20110109_AABJMS kuchibhotla_s_Page_27.pro
6689a82a129c0700d2395fb9bf3b89ee
500e611a82550aecdff4e0efa196ca24c9b084d0
89459 F20110109_AABJRQ kuchibhotla_s_Page_46.QC.jpg
794da272886072702466b13d9e452aaf
95a847f25ac9254fa433d30fcc79b7b3530fea53
162636 F20110109_AABJHV kuchibhotla_s_Page_41.jpg
c118c2b4d12ff2099d1698dc34638835
3fc003d1ac4588d63e006605aeff11e49244b2fe
21769 F20110109_AABJAA kuchibhotla_s_Page_15thm.jpg
2f59cbf5aecdde77d91decb733eb1a15
e3ef0061c99e9b17e0da8f5e9fe8f69316a75bd9
47107 F20110109_AABJCY kuchibhotla_s_Page_39.pro
f1b17eaea84a778c7d0cba6c0b1e8a2e
f3f25e7bed9efce2fcf57e54018dfcd61b9c3353
47055 F20110109_AABJRR kuchibhotla_s_Page_46thm.jpg
3d2e09007bfef46290d9674ce51e0f9b
15e0f77ba29c74293eb25b0bfb2534ed737f8742
118689 F20110109_AABJHW kuchibhotla_s_Page_42.jpg
0d1e426fa3b7acf31e702e4543a7c2f6
cdfb62967fef41a7d3fe02a70191812fa4d7ca7a
1853 F20110109_AABJAB kuchibhotla_s_Page_34.txt
c78a889193fab3b09b88ac978e76d2c2
063b5c796693d97ae51c6751f2acdf644677dc6a
29006 F20110109_AABJCZ kuchibhotla_s_Page_49.pro
147ce43d99d7cd3bb18365c664f439f5
659f4a1f71a56373d9239e830c839e1c1ce53071
42347 F20110109_AABJMT kuchibhotla_s_Page_28.pro
1abab1180bcc8ea1050f9cb480b21e75
995cf15534a44baca9ecfe5349249d8e12411b59
59497 F20110109_AABJRS kuchibhotla_s_Page_47.QC.jpg
3a8c948905c20320eedb759e98b17991
a1ad573ea7f24e9126bda3e56b1d641d4382e35f
135245 F20110109_AABJHX kuchibhotla_s_Page_43.jpg
5efc1e195678d3323ec901ac2091ee8e
2997af85702c373ce1c23e3e351f2feed335629e
1699 F20110109_AABJAC kuchibhotla_s_Page_28.txt
b0c1dd764f90e30435dbf795fb3aa755
0eb420c3111e5c1fbddfb2e63aa52c0509a72ae9
26745 F20110109_AABJMU kuchibhotla_s_Page_29.pro
f585d928aa3661984f6abe40526146b4
89a9b8f6b5ffbeefd8a5a0755c133f8236320fa6
25659 F20110109_AABJRT kuchibhotla_s_Page_47thm.jpg
cf7d7a96309c01c8f8c8b7d30eb9bac6
fe9ff834fdbc6cbb0dc34f529d7318ad221f1016
58288 F20110109_AABJAD kuchibhotla_s_Page_55.QC.jpg
0be1247d65a01fbec20a8d7c36d7e241
7cab35d2320c03f9404a5e4b7e045b498c209246
37863 F20110109_AABJMV kuchibhotla_s_Page_30.pro
7cb8130e394f635e9e8f4d7346feda66
4a127f67da20c564a319590840e09283d76fdc80
1285 F20110109_AABJFA kuchibhotla_s_Page_57.txt
3cfea3583ed862cc57966fa80dfaa94c
07db7006bdfa20d3133eacab919b500590a00ca6
154399 F20110109_AABJHY kuchibhotla_s_Page_48.jpg
6bd3a9942d9401b3f5053aef880d1509
0e07708338ee50f477ddff1a5f1ae18998f86b25
20281 F20110109_AABJRU kuchibhotla_s_Page_48thm.jpg
d3358d3dea5b9581da930b6e38ca24aa
121c2fdf57c0ac446541d63b548b945d8c4dc6f9
F20110109_AABJAE kuchibhotla_s_Page_59.tif
cbcc3e13866628023190957bb113cfae
6d7c7cf968cf23ffb50fc36c0f15f4f309a81936
16841 F20110109_AABJMW kuchibhotla_s_Page_31.pro
a3706f4ba4ce8e14e8951336df227bfe
33394a7643b52fc37944337e3417efe22428d49b
F20110109_AABJFB kuchibhotla_s_Page_22.tif
ae04e8d1f1470975726ecd1d4f3c26e7
099302eef66e330c20ae5680be9e06f185eb6240
169459 F20110109_AABJHZ kuchibhotla_s_Page_49.jpg
35642107a1716e86f93ebd00ebe913ae
77f713636640dc7045791d221cba5d1221a1b49a
78322 F20110109_AABJRV kuchibhotla_s_Page_49.QC.jpg
0e6ff8ff11b82505af2808639d4d3c0c
8192e9dffab8527432c3ec92d9fa44a87485fc88
21871 F20110109_AABJAF kuchibhotla_s_Page_25thm.jpg
aea78d1cfc53798965454ae1941ea993
5456ee7b1e5cdb5ed6cc2b407a14f7b9a5dccb2a
26113 F20110109_AABJMX kuchibhotla_s_Page_32.pro
df9b60e7d2c306630ca23c618b7d2de7
90eb020e91491bf48acdfe55174f7062e060b6c2
47328 F20110109_AABJFC kuchibhotla_s_Page_25.pro
efc1ea35bcb2eb7c5b6ff547cfc0ccf7
f173d44c25b238d3890c37cf26a1af756503f705
64112 F20110109_AABJRW kuchibhotla_s_Page_50.QC.jpg
ed4774d795aa51d3b207335fb9a1e169
313b61b64e50555e6d871c7ad8cdda4d467175d4
95406 F20110109_AABJAG kuchibhotla_s_Page_52.jp2
c915af1bb2f55fdf5546327aa11ffe54
1abcf87536877ed602382935d89ed6e12ae6213d
724394 F20110109_AABJKA kuchibhotla_s_Page_62.jp2
fea1c376488f6de118dfaaefb3d1165f
143df120560b620047ebaafb0f8a35c3f1b04e27
46323 F20110109_AABJMY kuchibhotla_s_Page_34.pro
67a0b24ef8a7e115cbb67a2ddd0f43ca
4e8d8703f14578d7781981edd034a4df729c7296
23176 F20110109_AABJFD kuchibhotla_s_Page_23.pro
ddde6a8079f6a049233189f2ba358001
8c910fff0f35240a26d788e2a2307f50d338be38
48464 F20110109_AABJRX kuchibhotla_s_Page_51.QC.jpg
aec12d113a346218aabefa58e5432697
5d77b6f0a3c598e8529090189dcd9247a3d64b8c
1051927 F20110109_AABJKB kuchibhotla_s_Page_63.jp2
029ed86be949eab850be2a4ec1a2bbfe
65ee8895a3840b728cd5c430c78496199403e3c2
42682 F20110109_AABJMZ kuchibhotla_s_Page_35.pro
ebb8473da8b83ffd40fc31f6ec177a42
c837959e3a2aa4b84e7b312f55e0a581efe6b977
13773 F20110109_AABJFE kuchibhotla_s_Page_51.pro
48f877473dc313718d0870aa62e8a2a0
bf5b38f5516f1d488caff7d52b058dc8543fd089
79774 F20110109_AABJAH kuchibhotla_s_Page_62.QC.jpg
fcbef44f64373621963c7e6f5a43ba15
40e924e127a3a7fd04f987e497cffc06bd0f6526
787026 F20110109_AABJKC kuchibhotla_s_Page_66.jp2
f4bb26c2c53d91fa58fe7424fdfc2895
f97cc4a77dadc933d9903924d9ab0d955451ef51
36727 F20110109_AABJFF kuchibhotla_s_Page_48.pro
28514f91bdd4755f36d0e67bdcc98e2d
5876945e4191dccc2db750decb6c3600e77f26d7
15632 F20110109_AABJRY kuchibhotla_s_Page_51thm.jpg
7f942051830c9aff80136f9406f983ee
7618f30df0760aa8326cc6e5edfc63e38ee15cca
681 F20110109_AABJPA kuchibhotla_s_Page_51.txt
22b23f1ba505de29545e6bdb481c2909
ab5453ee4384f123ab32ceba3cca343e63b63e76
603719 F20110109_AABJAI kuchibhotla_s_Page_20.jp2
8181a63572440f9d096cfa56b7e9339f
1788b9908f0415bf46e135ec622fdf37bfb0b050
81685 F20110109_AABJKD kuchibhotla_s_Page_67.jp2
b315b004438b45623634ab177f10f464
057b6fd7316cc22526d46999491ddaa7311ef222
99236 F20110109_AABJFG kuchibhotla_s_Page_27.jp2
bf44d7121b02e06ebd797887a2d30bd4
5bed7275474088085a6fc9604120feb457a77578
22282 F20110109_AABJRZ kuchibhotla_s_Page_52thm.jpg
aa9855a2633ebe1ff0cf1484039d1cc6
9b0eb1dab57cb60d5e880279006bf5e5b05326aa
1827 F20110109_AABJPB kuchibhotla_s_Page_52.txt
67461bf63f76e9565349be830628beae
170f933a2c2baa59e14ef5084cb264cec6c4a19c
3041 F20110109_AABJAJ kuchibhotla_s_Page_02thm.jpg
ad262c185c0df098a0cbd3af250a7060
c2c77cbb89cf6bc349a7c70aae21f805d1d67364
118865 F20110109_AABJKE kuchibhotla_s_Page_68.jp2
f3d9de8280f38c272e586de0730524e3
45b4c409ac197bfb1110ce57177a73b175f75662
40624 F20110109_AABJFH kuchibhotla_s_Page_70thm.jpg
d7772bd5652300a802865c21a08a637f
a876f433cd3f58ea80e3ac4fcb681b15e51cef0a
1425 F20110109_AABJPC kuchibhotla_s_Page_55.txt
e93ccf3d9fb27571b026c232e2b894fb
b1e9265a10335318174078a11d7fc247e5a78dd2
19680 F20110109_AABJAK kuchibhotla_s_Page_30thm.jpg
20bd6ea284cb296a33d08b2e9cafb7ea
3ec4793168138235dabeba3888252170ffa08765
748647 F20110109_AABJKF kuchibhotla_s_Page_70.jp2
d4d3accf609707c7a5d452a167a215e1
4e6e0c5f2cb9cda6568ac45c3cbc8e4466eed43b
60517 F20110109_AABJFI kuchibhotla_s_Page_48.QC.jpg
a2ed404a62fbd4b487c5033fbeacd987
be6d1dcd9a3889843e1920cee7caa070f2b47cd7
1263 F20110109_AABJPD kuchibhotla_s_Page_56.txt
23582f582cccc7a4bf7575de74281ff2
b3c4c7426dc0dfc998f4a96f5ed284dd7c367688
63591 F20110109_AABJKG kuchibhotla_s_Page_71.jp2
c5e149a5fc9feed0711eae3f176ccb1d
54f16adb7fefa7fa08c3a4a04bb0eb2b16ddbb0c
45088 F20110109_AABJFJ kuchibhotla_s_Page_31.jp2
c2913d8df9139a0b66710347a5116ad6
540aef499488fe97ff8db33dcaddc353a81fe7bd
36105 F20110109_AABJAL kuchibhotla_s_Page_33.pro
8a85d6a63d56ed0dd1bf9ce88681ef81
0cbded45860ff2b451a23a7edbebca9b8e32f178
1649 F20110109_AABJPE kuchibhotla_s_Page_58.txt
64615708d5b91a826a32e4751fe905bb
506cb2c1de7be64c875a6ec929e80617206662e1
F20110109_AABJKH kuchibhotla_s_Page_02.tif
7c5184bed2a9030ab80c4f089113467c
96c577c64c1ec79e440cec5e53843daf0f919539
1721 F20110109_AABJFK kuchibhotla_s_Page_35.txt
8da15d4f596a67b6286659effc843ea0
9f7ebbfeb9f80b11b1219207cf854782966c81b5
85134 F20110109_AABJAM kuchibhotla_s_Page_12.jp2
0c8b527716b7c3a1b7ab5ce1547b957d
013b1aa9a6e73eb0addd2718b165f2fea525021e
1636 F20110109_AABJPF kuchibhotla_s_Page_61.txt
a9b5b361b91f2f205a958d34c6404f80
5fcc033797c6119647c02148c87f28649a4b09b0
F20110109_AABJKI kuchibhotla_s_Page_03.tif
a02b71d585076265ab74912e7d02d91b
4b3bd17bd0e10198c024a7d550c3b8220034f02c
6153 F20110109_AABJFL kuchibhotla_s_Page_02.QC.jpg
d8fcef12a1a77a9d32adaf68be33bc2b
f344723782daa97f880b1e20d5dae2204f97fcc2
F20110109_AABJAN kuchibhotla_s_Page_61.tif
15250b76968a805630d6a41324c7e5b6
c7cd537041282d219c841263c76ee83d1f3d8cb3
654 F20110109_AABJPG kuchibhotla_s_Page_64.txt
53acd25dd173d81b723366731a1d1827
de1c4c5dd7e5581af6c3db0a03b97c404441cba2
F20110109_AABJKJ kuchibhotla_s_Page_04.tif
2f4185d8361f703975b9671e2b527aac
919812a63f6e122aa96604e02e0beba9ebe5a1c7
F20110109_AABJAO kuchibhotla_s_Page_18.tif
f60126b0566dd4dea3e0a20e78c9c7c5
67499f42f42f0f66ee23072c7dd9d6a3b24f60a1
1919 F20110109_AABJPH kuchibhotla_s_Page_65.txt
4a8e067486c130eb155a9ace0b6cf1b9
e1f72a6e5a5e661b780a9cfe4c936a0ba1ed3ff0
F20110109_AABJKK kuchibhotla_s_Page_05.tif
491cdb7a85b0ebc7aeb08671b34286c7
2465fb43af26ca29e13d993e92c8bcf8d991d8c2
134092 F20110109_AABJFM kuchibhotla_s_Page_59.jpg
af847b95386a6ed7f6cb3b862f59887a
feb390dd12f7abefc296e9ecbe91eec498add4cb
1607 F20110109_AABJAP kuchibhotla_s_Page_21.txt
c3ea2b4a41fb10b718090c6c1f776a2f
32b5c24d09c89f5430782056d58a8aed1ba7d1f6
705 F20110109_AABJPI kuchibhotla_s_Page_66.txt
13a521a1caadc79c9752f01c525a6cab
fb6c615d4f8fa16b752c82cbdcd78ee29784c903
F20110109_AABJKL kuchibhotla_s_Page_06.tif
d2db37171aed875b4e40bcc1b858d8d3
a1583604fe831c512a46077a0a9743b6508e90b3
87767 F20110109_AABJFN kuchibhotla_s_Page_05.pro
c84980357c4962da5cb657069f50f26b
607dde357ab383cba9edd6b7c5f2b21173ae9fdc
15422 F20110109_AABJAQ kuchibhotla_s_Page_69.QC.jpg
a890645fac5ec99ec4ec84de83a34e4a
f1f1a145d2d5752c6f993e3c4aee013cf164e91c
1598 F20110109_AABJPJ kuchibhotla_s_Page_67.txt
088cfa6215ccfe679dd5ee11665477d9
802a5736da7e8d6f190820f3ed2b2eeb59691bb9
F20110109_AABJKM kuchibhotla_s_Page_07.tif
59639df32c5bc6efd5302c2364ac925d
e66f35a7a115f2eb3044b67aecd989c9c451ffd9
24470 F20110109_AABJFO kuchibhotla_s_Page_32thm.jpg
3a796d0297c4a66a17708be7a567ce4e
6f415c7b04eefabb2f60d28d209f62d087a34811
52075 F20110109_AABJAR kuchibhotla_s_Page_16.pro
07b76938c80aa8808309a081a34664a1
2486001a1766852e296facc6326ba9e1bca3d564
409 F20110109_AABJPK kuchibhotla_s_Page_69.txt
c37137fd2561ada5bbcb6d8cbcff0078
ae1742e8650acd9ec61a298f0ea9e6472f499745
F20110109_AABJKN kuchibhotla_s_Page_09.tif
a19ce2f9a6c7b9639969c857da4b4848
cef6a6dc5dcb6f44f56b4e11772ec423b24c3543
67884 F20110109_AABJFP kuchibhotla_s_Page_38.QC.jpg
ba1e65e02b09bb412cacbe3a80df2fc3
954489ace76314983927fb6febcc53da81d477d2
34012 F20110109_AABJAS kuchibhotla_s_Page_31.QC.jpg
31966606dbf0cebe0977f4c573960127
ea9d0b73c06882927b598e7ef882a8fff80f2172
794337 F20110109_AABJPL kuchibhotla_s.pdf
bfe66cd41437b92a52331706269836e2
44900ea865dfe2c8b80c5f90f6a076522e6e97e9
F20110109_AABJKO kuchibhotla_s_Page_11.tif
b480d3834ba3b17402ea7285d4d4788b
61005a4b15e5e9d74f7583749f32c613ee3119e2
1151 F20110109_AABJFQ kuchibhotla_s_Page_71.txt
0834d2ad2775929904014084ee2b8f37
5c16d38ee2da50eb1fd36779c85257cde59567d5
203956 F20110109_AABJAT kuchibhotla_s_Page_46.jpg
5e6eeb71106bb120734499c8cdd27b5d
144e19998a49afe5eae67e410a10f46f660b408c
17267 F20110109_AABJPM kuchibhotla_s_Page_01.QC.jpg
8a64e3c41c59adc7352f08be7b8518e2
617ae9b8704a087b2ba9c26437b8d5f5a4d41e43
F20110109_AABJKP kuchibhotla_s_Page_12.tif
8118b1f7920b4415e7346609307e5ceb
2d43ff2f91e943f41bdb6238a04096948b1d1e97
32445 F20110109_AABJFR kuchibhotla_s_Page_10.pro
5ef621b8e0c64dea5e876fe23ad30fea
32f9e608f17b482419fc03c8c46b34b1a73de9cf
1163 F20110109_AABJAU kuchibhotla_s_Page_43.txt
4b3015f2ae4a7b54639dfdcbd615bad1
942948f7a43f6038161bb18945492ec996534f48
7038 F20110109_AABJPN kuchibhotla_s_Page_01thm.jpg
a307d61844455776bc4bd60f296cffde
dc54f2cf60f2fbefcba95c363b2b4f83459559d0
F20110109_AABJKQ kuchibhotla_s_Page_13.tif
328ff0d8f9d1a14e503ea594fd3be8a2
17ef5ccce363eca12c8b582af69c18635254104e
1051865 F20110109_AABJFS kuchibhotla_s_Page_64.jp2
4b1b1d4c3c51bc4de0ac6c7d5c2ea794
fd2b8634eaed1dc316fb0e37688ff3a4b9259550
85472 F20110109_AABJAV kuchibhotla_s_Page_41.jp2
e1d13b532aa769689c80d5f7c7bdaad6
00b7c85daddb171f44b2c775413884377f7c5bb3
6238 F20110109_AABJPO kuchibhotla_s_Page_03.QC.jpg
9a999d8d1efa03f69427a0566f30a038
639c12673420a5e49a04654959e2f2a04e9deb88
44005 F20110109_AABJFT kuchibhotla_s_Page_36.pro
188ac267ef3578627d9788fac72a9d5e
dfddeaa22d9406ae338317f6e837aff5f990e2f7
360119 F20110109_AABJAW kuchibhotla_s_Page_06.jpg
0de68f9df69bd43bbf6f1d3d56a5ae89
d77f9a897eecd347bd46e5560f18327520b8c595
3207 F20110109_AABJPP kuchibhotla_s_Page_03thm.jpg
3cd7ac6f5c470a00094d9d04cdbe26ce
e456b666d85907201e6cd1f301402eff8d3fb796
F20110109_AABJKR kuchibhotla_s_Page_15.tif
d6b109568a444cb7b9c98dc3d1564f15
27b2ede5d5e5a12c5455acd184c301210fc9cea5
149988 F20110109_AABJFU kuchibhotla_s_Page_55.jpg
b6cf536776fbb2dec57a3392cb1ca3f6
8bb08c762b6ebb61f87f83b3a62dbba20f6b3889
F20110109_AABJAX kuchibhotla_s_Page_71.tif
9bd68402cc8dd4ec98ebd4b79d74a67d
1b43860153c37538a3971c449b75f3186784b4f3
26579 F20110109_AABJPQ kuchibhotla_s_Page_04.QC.jpg
95d7cb05fad5017d3fa6f01cffe2100d
ae980a7a0ec23d5c9f4727140de2d68fbb71f604
F20110109_AABJKS kuchibhotla_s_Page_16.tif
a6c047c575332688f797e100f516a5af
6ebdb520cdf25e5827695dc0d6d5a5af8ef84bf6
24161 F20110109_AABJFV kuchibhotla_s_Page_47.pro
e04a5dc3d9469419ad5dd2f8a417550b
4a8615daa0bf28012bfe29179e02924a9e9eb13c
1698 F20110109_AABJAY kuchibhotla_s_Page_11.txt
ebe918f71b29d65a86f9b3093cd0ea61
655d3016f7be67bda8dfab271aad815b8bb801b2
9420 F20110109_AABJPR kuchibhotla_s_Page_04thm.jpg
3829aa31c388344c853f431166f72487
e3a3c0ea37792d4f9a812a98678dd9edcec9e7a6
F20110109_AABJKT kuchibhotla_s_Page_17.tif
e2b5d16aecacbf4c19fa03ea3ccc558e
1ed660ccb15a810aba85095eeb3e72b7574ed101
360622 F20110109_AABJFW kuchibhotla_s_Page_07.jp2
2e8e54341bdb16501981db87c220951c
448dbb301e91c45ade97d86cf9a7dd738e0c7816
120935 F20110109_AABJAZ kuchibhotla_s_Page_71.jpg
c6b6fd6c3464888f4ddf0afa6bf368cf
f35691c4f0ddf225eef1fa96b5623cd13eec4556
47407 F20110109_AABJPS kuchibhotla_s_Page_05thm.jpg
37df6289f8d5622942d048cba2e3a556
1495ee3b5a7372c39467e50f95b4ac2a6dc4d2f7
16601 F20110109_AABJFX kuchibhotla_s_Page_43thm.jpg
30f9081a49b5aabe257de25439cd25d8
bc6ba33a773f4906383571934cb1bd69789e56f7
F20110109_AABJKU kuchibhotla_s_Page_19.tif
e6f3c25d1b4a04dffd3a9201c12ee84d
73d86d79a000c85d334c43b177037462d7277937
122327 F20110109_AABJPT kuchibhotla_s_Page_06.QC.jpg
b542a85604f46744c3554356c19939f0
b22420a5cf4a9a06eb75a1a9fece3516cb7cd621
86423 F20110109_AABJDA kuchibhotla_s_Page_63.QC.jpg
eea6458b1bd18b4ef765a15f8df83ee3
891108822c0fa2ab9afa996eba2bc0362e8f56ba
F20110109_AABJFY kuchibhotla_s_Page_10.tif
ccfdabdec8eef3ea11bb2d829148fc42
7772f6c4e9e2195c9f9b885e7908d9b3d9e57a2b
F20110109_AABJKV kuchibhotla_s_Page_20.tif
b639222043cf05b30394cb69955ec891
2de8d4fd062b056aa3417bc7f62265f04920996d
54364 F20110109_AABJPU kuchibhotla_s_Page_06thm.jpg
c18e30abd61c3d9339b2368965272f4a
e5eab350461ef197f3e40097a2f409d7700f3a0a
22156 F20110109_AABJDB kuchibhotla_s_Page_16thm.jpg
cafa15a5b1431250f1e7b2df33032113
2d96f605611011d389eaa30a2d9afa0705567b0d
14254 F20110109_AABJFZ kuchibhotla_s_Page_04.pro
9c535a51bfa06e7192d6048fee5e8e9e
f068a99459dcb6535fc4e70f93359c84d8c597fe
F20110109_AABJKW kuchibhotla_s_Page_21.tif
7ec91cc13df5f93c7efbbe8f2295399f
de92cc83d9200622a01971043161932ec52c13bd
43645 F20110109_AABJPV kuchibhotla_s_Page_07.QC.jpg
36ece3d353df95e63aec08a27721d3bb
fed94d8f8c73248630256eb61891b608fc695af3
151121 F20110109_AABJDC kuchibhotla_s_Page_66.jpg
0e985ad81dacbf70d3f1919430692a08
7128f11f7452d30c4a40b8e96637e962727b7ea8
F20110109_AABJKX kuchibhotla_s_Page_24.tif
a6cc69d4e18c2247e7838f641059bb5d
02533045c7e9232fb858950da9dbf0b5f0c446a6
145710 F20110109_AABJDD kuchibhotla_s_Page_37.jpg
f1d6303b3dcf23cd83f69093fd77c833
0b409a5f4a284ed2d6f9fbaf2a45058a30c7b4fc
116979 F20110109_AABJIA kuchibhotla_s_Page_51.jpg
3a78e0131c48afcd9f6712af05b9e769
94ecf73ec9dd33e64bc9b80652cb36e393da390d
F20110109_AABJKY kuchibhotla_s_Page_26.tif
8151c5bb824cccc89c5982c8e3017878
d2aba8a9ba935d2f02544b15359edd53e5706b28
32619 F20110109_AABJPW kuchibhotla_s_Page_07thm.jpg
701eecb2fdee956038c22ab13547ef17
eaec56101ecff7ee834a086fc71bdb40516dfcd9
17309 F20110109_AABJDE kuchibhotla_s_Page_58thm.jpg
302351be7b670ac42b1054f8a78f8182
a80e80b0b3d7087b979aac735e86663496555ef4
180824 F20110109_AABJIB kuchibhotla_s_Page_52.jpg
2e275a244bedf9c4e2f5ebf15a98e29d
489bd64984dab9deda02cbc0f9f1c90363d2f61a
F20110109_AABJKZ kuchibhotla_s_Page_27.tif
bb130631e985c497dfa85ca43d15507b
62de417be9b713780ccbaddfb4b512cd5f9072ef
96276 F20110109_AABJPX kuchibhotla_s_Page_08.QC.jpg
3200579f62df43aa655cdd28d2c7c5c0
c57a1ccc6cdeddd37b94f63b0dd55f93b422108d
78841 F20110109_AABJDF kuchibhotla_s_Page_55.jp2
32be17d6bf2912c4e1a9f7b9bedb6332
3b92f71291fa81eaa33c79d5ab968fc7379d544e
126932 F20110109_AABJIC kuchibhotla_s_Page_53.jpg
05a4209e4eabb6b3cc8235a4d4818b7a
ac00367ddab74d544cc99ca2ef23291d409b43ff
51152 F20110109_AABJPY kuchibhotla_s_Page_10.QC.jpg
3dec1d4832d9f271830a2fbc3025c278
6ae12bb0534b62c2d25b996da1d108d6a245a9d1
101633 F20110109_AABJDG kuchibhotla_s_Page_25.jp2
50fdbd6ea26320bd9f842d24379998cd
003ca3f0495327966af8e52c8bf3717583953265
38701 F20110109_AABJNA kuchibhotla_s_Page_41.pro
9f5b761285c060ecedb3bdedfcc4648a
df158d342c3a60034a8ad0aef22cac8b0dc18bf7
172206 F20110109_AABJID kuchibhotla_s_Page_54.jpg
5b9ed4836b345b797ded62bee4c17afc
70cf8bf9def23b2d872821135e0547fbec288414
64729 F20110109_AABJPZ kuchibhotla_s_Page_11.QC.jpg
4ea224e385fb4d069709ad02d5694ca7
fab4be54478b7c87167729976619aef9352b93e4
F20110109_AABJDH kuchibhotla_s_Page_50.tif
9e5102dc697e9ba5c63c40ebb9724216
1df80bfec957f3ab6103257de195b225169b9041
19086 F20110109_AABJNB kuchibhotla_s_Page_42.pro
fed59fb7e418658bc94662636dc3c7de
c4a525f24a904773110821901eb1826e9f43d4f9
134662 F20110109_AABJIE kuchibhotla_s_Page_57.jpg
4bbbe79568f5ac601f23bc9d7e3d0819
89ce8e7ba5a41c4b572ec6c8d4c068d59232e6c8
28690 F20110109_AABJNC kuchibhotla_s_Page_43.pro
0c5ce6d5a71a4bacb285efa353a85287
9ee467fea718ce4ad98e3fa1706a0b03efb1eac3
140559 F20110109_AABJIF kuchibhotla_s_Page_58.jpg
75480bb5e284d4d01a775746ce87408d
04da0d8e2f61d46bebb05fddffacab394326e8be
F20110109_AABJDI kuchibhotla_s_Page_01.tif
202b6134f2cb8835e0b490ddf0eab9c6
61190f5273278593d7c7384db7897acec7c1100b
51857 F20110109_AABJSA kuchibhotla_s_Page_53.QC.jpg
e39b6d00e28cb22f26a18e37867fe230
166822fd3493a1f7f87595496e5a1e101de0966e
51425 F20110109_AABJND kuchibhotla_s_Page_44.pro
0761b66beda0c299c988f3ff58b96c0b
ba03ec04a8953c8b0cc637066fec088b6c602034
161333 F20110109_AABJIG kuchibhotla_s_Page_61.jpg
ee55de9c4d9da32df01b882336bc3e34
ebfb23c8303f2b86d0eccc05b602be0d498b4dcc
254425 F20110109_AABJDJ kuchibhotla_s_Page_60.jp2
a19339cc62c6278f034c9b901d140572
27a2812008478814853fce7864db09b0b7f145d6
22554 F20110109_AABJSB kuchibhotla_s_Page_53thm.jpg
801f7b66bd3ee42bdf83938dac6f6d64
9697412ee87fc2457c808fe4d818054c1aec2994
42894 F20110109_AABJNE kuchibhotla_s_Page_46.pro
8a4f8538590e69ce32b7e6248661ac74
d811b0dfa8c94cadc5f771ea387fcab260aa4afd
170602 F20110109_AABJIH kuchibhotla_s_Page_62.jpg
21df9813c13dae3eb3de50fc25642a16
c8cbcd69a0b55eb83d630fd4024ccc5b527e67e4
78639 F20110109_AABJSC kuchibhotla_s_Page_54.QC.jpg
97b7f1f7c469f7930175f314a0fbc4fc
664f4ae37cfedee34421ed1d033515f50c5d2c97
40866 F20110109_AABJNF kuchibhotla_s_Page_50.pro
7db4e8ab80167f0a5f767cd85f459214
8e362e506898a88ed9aeebfc3fadf7e7edf8e0df
195935 F20110109_AABJII kuchibhotla_s_Page_63.jpg
1ef511b480e2bff2e6e122d90dc8e577
f6a274db9c5f16a00bf5efd0af416a2458cec44c
129466 F20110109_AABJDK kuchibhotla_s_Page_20.jpg
bf2b9b4ebb7b029e1618e94ef5ae8337
f9afe770d8ea2435f176a46fba0123f6761d75ec
18196 F20110109_AABJSD kuchibhotla_s_Page_55thm.jpg
7189fdce3bcd946df9072855fc52c845
d11cb9f6082fdaa31b2226a760ce8201ac3e41ea
22087 F20110109_AABJNG kuchibhotla_s_Page_53.pro
33b04f447d6c7c9b7a41d79b2fdf8326
31296bfddd29d878e3abbc1e722c4a2bb7b302ec
230252 F20110109_AABJIJ kuchibhotla_s_Page_64.jpg
e87f3d904ae504c7d5817ea12d1c0abc
447b28551b7597b6617097276ffa25960fc46d70
32118 F20110109_AABJDL kuchibhotla_s_Page_54.pro
95b197fa14ede9426df9570f97dee922
05a4d64e4d4c8c50b9d9463fc532eb5b7a18e9d0
50501 F20110109_AABJSE kuchibhotla_s_Page_56.QC.jpg
5031b93549afc953a970c8f41c1f4cf1
15ef4a415bf4084d980dad652752c6cbd6a37524
21574 F20110109_AABJNH kuchibhotla_s_Page_56.pro
8cc1e3658f68b3a534cddc84d0da51e7
832cca4510a638141a5f498cff1d47b8d4e2ba1f
187387 F20110109_AABJIK kuchibhotla_s_Page_65.jpg
2fe8c7da20c92e3a7fc57efb81385c16
28dfeec7a3902c95b43a0da4dba424387a603ed4
1278 F20110109_AABJDM kuchibhotla_s_Page_59.txt
3a88dc967f4703f62e34239ca3ee0bf4
516295bd388792f5114fa7aab1bf4c8555aaba60
21959 F20110109_AABJSF kuchibhotla_s_Page_56thm.jpg
89c9dc1bc532b436a18b059e8b65aef3
fa1f5aaf269268ec8c8684e25715dd731bde4161
37795 F20110109_AABJNI kuchibhotla_s_Page_58.pro
cf7fa81d1350db5c947f5e2cd12f3977
d043cda29f32b0e486e8c7076d8045788ed6dbd7
156598 F20110109_AABJIL kuchibhotla_s_Page_67.jpg
c1c1b3186b374950b8d9fca92f63878d
3de9c05362118b02c76d3ef24f80f81d03946ad2
38752 F20110109_AABJDN kuchibhotla_s_Page_45.pro
cc5df53f392765f799d3fb45fc967e9f
9c7dbf4494ba43abb13badca93a939622d8f1d51
53928 F20110109_AABJSG kuchibhotla_s_Page_58.QC.jpg
a24d1dcf72fbb72170a071a83d42afd5
31237cc436b845333cbe320f000854c6a8416b33
30859 F20110109_AABJNJ kuchibhotla_s_Page_59.pro
207d5b1d8377588102f133bd8f5ae8ad
9694d7ec50b0a4016166ab5c12b08e072a784474
238022 F20110109_AABJIM kuchibhotla_s_Page_68.jpg
9b1cacc63f4363e536a27636bc34d69b
a453ee36fb5226a46fe6b290bbd414b97a07d1ac
17717 F20110109_AABJDO kuchibhotla_s_Page_57thm.jpg
269cf0951bdb6c82ccd31ab0f1be3acb
d2281abc19d3df01e63ae2afcec5bff1da24bd51
50127 F20110109_AABJSH kuchibhotla_s_Page_59.QC.jpg
42bf3095cbef4bfd3c3d0c95cf5c22c8
d2d76d915e4420522d3223fdbbe64bd4ca359a3e
7548 F20110109_AABJNK kuchibhotla_s_Page_60.pro
4e09f610069e2da92a5c6edb23b10ef5
a2a6f4ce8230eea3d594208dd2b67c9c024063f8
41261 F20110109_AABJIN kuchibhotla_s_Page_69.jpg
4b40bd7b62ff013fe53e385d9302325f
603bdf79d34196597692e5efdaea3bc87d3a4af4
F20110109_AABJDP kuchibhotla_s_Page_36.tif
c7893b5ab2ff2d7828cc1c20ea72c1ce
3e44b4c9b2db98f4dbe7b8ea7d1547a8fa86b4b8
16830 F20110109_AABJSI kuchibhotla_s_Page_59thm.jpg
424591e2431750b94e5951ea088440d0
a4f0d49526a8ff35b6bd7f111deb5ff2613915c2
38514 F20110109_AABJNL kuchibhotla_s_Page_61.pro
d108c07471e7fc6fb2f83177df2d9f92
ee558fc28addcf278ad46bdcf12e1ac3480ac4ce
154620 F20110109_AABJIO kuchibhotla_s_Page_70.jpg
51688786ff1f7aad743c14bf4b14789a
e9db6bac3db1eed0860745fc180b123ecc19c6ed
205853 F20110109_AABJDQ kuchibhotla_s_Page_25.jpg
25c21671ed48d5c688212c4522fa5212
949736979741c9e47319c65c75852517d0ec1e24
30004 F20110109_AABJSJ kuchibhotla_s_Page_60.QC.jpg
7e389a3da829e6cdd884b001eb8d0dc7
2322e563419b88e0d7428774d55114654ad89cb3
43765 F20110109_AABJNM kuchibhotla_s_Page_65.pro
2eb9801073bb426b595b5f0120f645c3
14f129a8376d25c901c1a4afd2e0914cd1780559
18525 F20110109_AABJDR kuchibhotla_s_Page_63.pro
0418d09eb466e3025384ff5c2f946bd8
16cc27cc256678c1690168182d17f6b111b36094
62831 F20110109_AABJSK kuchibhotla_s_Page_61.QC.jpg
03ead2afa2c9422edd00e586124e0f5d
e2f395d32cc728c1ecd52842cf4dfff770d4f9de
17183 F20110109_AABJNN kuchibhotla_s_Page_66.pro
75b8b0eb1aa7195cc3705aa7f9607c57
e8c977c96ca46d5607125d0ba73d430a4e33e6db
23492 F20110109_AABJIP kuchibhotla_s_Page_01.jp2
991e2c685f69f7f0345876aebe17bacf
f2dbec02116f596a07e9175a23ba18089c5835fc
20149 F20110109_AABJDS kuchibhotla_s_Page_45thm.jpg
b45694dc7de388817b23c9e6826e9f2b
fd3ace8460004c4e3a7afd358ec7c5526fc16674
47933 F20110109_AABJSL kuchibhotla_s_Page_64thm.jpg
47fc5d8260815a49331f95c30ba09095
c6d433a896c642190a697c1dbdde6f76bd06906c
57231 F20110109_AABJNO kuchibhotla_s_Page_68.pro
dff846e09141e5d09a1683d3378e4a78
84349718dba3c03bffed5990b0d3e59206f2c815
6360 F20110109_AABJIQ kuchibhotla_s_Page_02.jp2
d5f1a37c1f87cc604b8d2ec8f20b2bde
a8246bae140e9df43550fb9c4eea251b487239b0
F20110109_AABJDT kuchibhotla_s_Page_14.tif
98f35f3e6f53099434bd18b78c75bb94
0e82ddc83cfb989e8d695b3f8b1439445a81cb2b



PAGE 1

AN OSGi BASED SOFTWARE INFRASTRUCTURE FOR SMART HOMES OF THE FUTURE By SREE CHARAN KUCHIBHOTLA A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2002

PAGE 2

Copyright 2002 by Sree Charan Kuchibhotla

PAGE 3

TO MY WONDERFUL PARENTS

PAGE 4

ACKNOWLEDGMENTS I express my gratitude to Dr. Abdelsalam (Sumi) Helal for his encouragement and support, without which this work would not have been possible. I would also like to thank Dr. Michael Frank and Dr. William Mann for agreeing to serve on my committee. I thank my friend Vijay M. Vokkaarne for his contribution to Magic Wand application and for all his support. Finally, I would like to thank my friends Sasidhar and Suchindra for their suggestions and for patiently listening to my endless lectures on this thesis design. iv

PAGE 5

TABLE OF CONTENTS ACKNOWLEDGMENTS................................................................................................iv LIST OF TABLES..........................................................................................................vii LIST OF FIGURES........................................................................................................vii ABSTRACT......................................................................................................................ix CHAPTER 1 INTRODUCTION..........................................................................................................1 1.1 Motivation................................................................................................................1 1.2 Organization of the Thesis.......................................................................................2 2 X10-PROTOCOL...........................................................................................................4 2.1 History of X10.........................................................................................................4 2.2 X10 Architecture......................................................................................................5 2.3 X10 Protocol............................................................................................................7 2.4 X10 Power Line Transmission Theory....................................................................9 2.5 Advantages and Disadvantages.............................................................................11 2.5.1 Advantages......................................................................................................11 2.5.2 Disadvantages.................................................................................................11 2.6 A Scheme for Device Discovery and for Improving Reliability in X10...............11 2.6.1 Device Discovery............................................................................................11 2.6.2 Improving Reliability......................................................................................12 2.7 Conclusion.............................................................................................................13 3 OPEN SERVICES GATEWAY INITIATIVE OSGi................................................15 3.1 OSGi Architecture.................................................................................................16 3.2 Service...................................................................................................................17 3.2.1 Service Properties...........................................................................................18 3.2.1 Service Registration, Un-registration.............................................................19 3.3 Bundles..................................................................................................................20 3.3.1 Bundle Format................................................................................................20 3.3.2 Bundle Life Cycle...........................................................................................21 3.4 OSGi Framework...................................................................................................22 3.4.1 Interdependencies among Bundles: Exporting and Importing Packages........23 3.4.2 APIs to Register, Un-register and Lookup Services.......................................24 3.4.3 Bundle Life Cycle...........................................................................................24 3.4.4 Basic Eventing................................................................................................25 v

PAGE 6

3.5 DAS: Device Access Specification........................................................................26 3.5.1 Device Service................................................................................................27 3.5.2 Driver Service.................................................................................................28 3.5.3 Driver Locator.................................................................................................29 3.5.4 Device Manager..............................................................................................29 4 SOFTWARE INFRASTRUCTURE.............................................................................31 4.1 Event Broker..........................................................................................................32 4.2 Design of Controller..............................................................................................34 4.2.1 Serial Port Scanner..........................................................................................35 4.2.2 Serial Port Listener.........................................................................................35 4.2.3 Tw523 Software Interface...............................................................................37 4.3 Device Services......................................................................................................38 4.3.1 Device Service Initiator..................................................................................39 4.3.2 Device Services...............................................................................................40 5 IMPLEMENTATION...................................................................................................41 5.1 Event Broker..........................................................................................................42 5.1.1 Package Details...............................................................................................42 5.1.2 Bundle Structure.............................................................................................44 5.2 Controller Component...........................................................................................44 5.2.1 Connecting Tw523 to Computers Serial Port................................................44 5.2.2 Package Details...............................................................................................45 5.2.3 Bundle Structure.............................................................................................45 5.3 Device Services Component..................................................................................46 5.3.1 Standard Device Properties Defined in this Component................................47 5.3.2 X10Mapfile.conf Structure.............................................................................48 5.3.3 Package Details...............................................................................................49 5.3.4 Bundle Structure.............................................................................................49 6 APPLICATIONS USING THE SOFTWARE INFRASTRUCTURE.........................51 6.1. Design of Smart App.........................................................................................51 6.1.1 Server Side Component of Smart App............................................................51 6.1.2 Client Side Component of Smart App............................................................53 6.2. Design of Magic Wand.........................................................................................53 6.2.1 Server Side Component of Magic Wand........................................................54 6.2.2 Client Side Component of Magic Wand.........................................................54 6.3. Events....................................................................................................................55 7 CONCLUSION AND FUTURE WORK.....................................................................57 7.1 Achievements and Contributions of this Thesis....................................................57 7.2 Future Work...........................................................................................................58 7.3 Conclusion.............................................................................................................59 LIST OF REFERENCES.................................................................................................60 BIOGRAPHICAL SKETCH...........................................................................................61 vi

PAGE 7

LIST OF TABLES Table Page 2.1 List of X10 commands...................................................................................................7 2.2 Encoding used for X10 house and unit codes................................................................8 3.1 Properties of an example dictionary service................................................................19 5.1 Standard properties of devices in smart home.............................................................47 vii

PAGE 8

LIST OF FIGURES Figure Page 2.1 X10 command packet formats.......................................................................................8 2.2 Electrical encoding in X10..........................................................................................13 2.3 A reliable X10 module.................................................................................................13 3.1 OSGi Architecture.......................................................................................................16 3.2 Anatomy of a bundle....................................................................................................21 3.3 Bundle state transition diagram...................................................................................22 3.4 Exporting and importing packages using OSGi framework........................................23 3.5 Example of Device manager operation .......................................................................30 4.1 Components and their interaction in the software infrastructure.................................32 4.2 Table entry structure....................................................................................................33 4.3 Serial port listener and Serial port scanner modules...................................................36 4.4 Tw523 software interface module...............................................................................37 4.4 Device services component.........................................................................................39 5.1 Package tree of the software infrastructure..................................................................41 5.2 Structure of osgiEvent.jar............................................................................................43 5.3 Connection details of Tw523.......................................................................................44 5.4 Structure of osgiTw523.jar..........................................................................................46 5.5 X10Mapfile.conf file structure.....................................................................................48 5.6 Structure of osgiDevice.jar..........................................................................................50 6.1 Architecture of Smart App...........................................................................................52 6.2 Smart App GUI............................................................................................................53 6.3 Magic Wand GUI.........................................................................................................54 6.4 Critical events on Smart App and Magic Wand...........................................................56 viii

PAGE 9

Abstract of Thesis Presented to the Graduate School Of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science AN OSGi BASED INFRASTRUCTURE FOR SMART HOMES OF THE FUTURE By Sree Charan Kuchibhotla December 2002 Chair: Dr. Abdelsalam (Sumi) Helal Major Department: Computer and Information Sciences and Engineering. Pervasive computing enables people to accomplish personal and professional activities using intelligent and portable devices. Recent advances in this field have led to the notion of smart spaces, which are ordinary environments equipped with intelligent devices that can perceive and react to people. Smart homes are smart spaces which bring pervasive technology to our homes and their scope is not only to enhance the quality of our lives, but also to enable the elderly and the disabled to lead an independent life. In 1999, OSGi (Open Services Gateway Initiative) was established as an independent non-profit organization working to define and promote delivery of managed services to networks in home and other environments. OSGi specification requires services to be packaged into software bundles. It also provides a framework on which these software bundles from different vendors can execute and interact. ix

PAGE 10

This thesis aims at providing a software infrastructure based on OSGi for developing various services in a smart home environment. A generic event broker to facilitate software events to be passed among different services is also developed. To demonstrate the utility of the infrastructure, two applications, namely Smart App and Magic Wand, have been developed that would allow remotely controlling devices in a smart home. Magic Wand is developed for Motorola iDEN cell phones while Smart App is developed for desktops. Smart App provides features to control the appliances in a smart home and to display the events handled by the event broker. It also provides an interface which the user may use to subscribe to events or create custom events. Magic Wand is targeted for the elderly and it provides features to turn the appliances on and off in a smart home. It also gives notifications when new mail is delivered or when someone rings the doorbell. Both these applications use the infrastructure and operate on the same set of devices. The interaction among these applications is only through software events. A cell phone providing many such services can indeed be a magic wand assisting the elderly into successful aging. x

PAGE 11

CHAPTER 1 INTRODUCTION Computers have evolved from mere number-crunching machines to indispensable smart machines assisting people in almost all walks of life. The emergence of personal computing in the 1980s changed the general perception towards computers and more recently the advent of the Internet and the emergence of portable and handheld devices lead to the notion of ubiquitous and pervasive computing. Pervasive computing is all about making technology an integral part of our lives. It aims at enabling people to accomplish professional and personal activities with ease. The concept of pervasive computing lead to an exponential growth in the number of mobile portable devices like PDAs, laptops, smart phones etc. Pervasive computing is realized by creating smart spaces, which are environments embedded with devices to perceive and respond to users actions and events. Smart spaces not only improve the quality of professional life, but can also help us in making our personal lives more comfortable. A smart home, which is defined as a home with smart spaces, not only makes our life more pleasurable but also has immense potential in promoting independent living and assisting us into successful aging. 1.1 Motivation In the recent years, many applications are being developed for the smart home environment. Each of these applications targets a particular aspect like controlling smart devices, providing security etc. The lack of an organized approach in developing 1

PAGE 12

2 applications for smart home almost made it impossible to compile all these into a single comprehensive package for any smart home. OSGi was started in 1999, to specify a standard that would allow services on the Internet to be delivered to the local networks. This was the first step towards an organized approach for application development. The standard specifies a framework on which applications packaged in the form of software services, can execute. The framework allows for complex services to be built on top of existing services. In this thesis, a software infrastructure has been developed on top of OSGi. The infrastructure contains the following three components: 1. Generic event broker 2. X10 Controller 3. Device services The generic event broker component defines APIs that allows different services on OSGi to communicate by means of software events. The remaining two components are targeted towards the class of applications that control devices in a smart home using the X10 technology. 1.2 Organization of the Thesis Since the software infrastructure developed as a part of this thesis, primarily targets applications to control devices using X10, an introduction to X10 technology is given in chapter 2. In chapter3, a detailed description of OSGi, which is the framework used by the software infrastructure, is given. Chapter 4 and 5 discuss the design and implementation details of the infrastructure.

PAGE 13

3 To demonstrate the use of this infrastructure, two applications are developed. The details of these are given in chapter 6. Chapter 7 discusses the scope for future work and concludes by summarizing the contributions made by this thesis.

PAGE 14

CHAPTER 2 X10-PROTOCOL X10 is a communication language that allows devices to talk with each other via the existing 110V electrical wiring. X10 is by far the most successful and widely used technology for communication over power lines. Use of electrical wiring is one of the strong aspects of the protocol as it saves the cost of rewiring. The success of X10 can be attributed to the protocols simplicity and the low cost of X10 devices. This chapter discusses the history of X10 and provides a detailed explanation of its protocol. The advantages and disadvantages are listed next, followed by a note on the tradeoffs and simple solutions to overcome some of the disadvantages. Finally, a brief overview of CEBUS and Lonworks technologies, which are similar to X10, is presented. 2.1 History of X10 X10 protocol is developed by Pico Electronics Ltd. of Scotland, which was founded in the early 1970s. The company specializes in developing advanced integrated circuits mostly for the calculators. Every time Pico began a new project, it was given an "experiment" number. Experiments from 1 to 9 were mainly in developing integrated circuits for calculators. In the mid seventies, a company named BSR (British Sound Reproduction) signed a project with Pico Electronics to provide an electronic, wireless method of remote control for its equipment. This project was called experiment 10, or simply X10. 4

PAGE 15

5 It was soon realized that X10 has far more potential in many applications in addition to those for which it was originally conceived. Radio Shack, which later became the largest distributor of X10 components, introduced the technology in the American market in 1979 and with in a few years X10 products were widely used in homes across the United States. Lamps and appliances were the most common devices that were controlled by X10 modules. Over the years, more sophisticated X10 modules were developed for a wide range of devices like cameras, motion detectors, thermostats, doorbells etc., but the protocol essentially remained the same. 2.2 X10 Architecture X10 architecture consists of two entities 1. X10 modules: These are attached to the devices to be controlled. X10 modules plug into the electrical sockets and provide a new electrical socket in which the device to be controlled is to be plugged. 2. X10 controller: These are the cardinal components of X10 architecture. An X10 controller sends control signals to X10 modules, over the power line and receives responses. There can be more than one controller to control a set of X10 modules. Depending on the functionality, X10 components are also broadly classified into two categories: X10 transmitters and X10 receivers. 1. X10 transmitters are devices that are capable of sending X10 signals over the power line. 2. X10 receivers are devices that are capable of receiving X10 signals over the power line 3. X10 trans-receivers are devices that are capable of both sending and receiving X10 signals over the power line. In the remainder of the chapter, unless other wise stated, modules, controllers, receivers, transmitters refer to the corresponding X10 components.

PAGE 16

6 It can be noted that modules and controllers fall under one of these three categories. Generally, all modules are receivers and all controllers are transmitters. All X10 components i.e., modules and controllers, have an address called the X10 address. A typical X10 address consists of two parts, house code and the unit code. House code can take any value from A to P and unit code can take any value from to . The address is specified as a combination of house and unit codes. For example, A01, B16, C02, etc. are all valid X10 addresses. It can be observed that the total number of addresses possible is 256, ranging from A01 to P16, which means that 256 is the maximum number of devices that can be controlled using the X10 protocol. Depending on the type of type of user interface, controllers can be broadly classified into three types 1. Mini controllers: These are generally wall-mounted units that are plugged to the power line. These controllers have provision for taking user commands and some of the controllers have LCD displays to show the status of devices. 2. Wireless controllers: These are plugged to the power line and also have an RF interface. They require a remote control through which the user can enter commands, which are transmitted to the controller using RF. The controller parses these commands and performs the appropriate action by communicating with the modules, over the power line. 3. Computer controllers: These controllers are of great practical significance and are used in all computer-controlled X10 projects. They have power line interface and RS-232 interface, which enables them to be plugged to the computers serial port. Some of the controllers have RJ11 interface, in which case a RJ11 to RS-232 converter is required to plug them to the serial port. The controllers enable users to use sophisticated and customized applications to enter commands, which are parsed by the controller.

PAGE 17

7 2.3 X10 Protocol X10 communication comprises of two phases, the selection phase and the command phase. All the communication is done in binary format. In the selection phase, the controller puts the address of the corresponding X10 device to control, on the power line. In the command phase, the controller puts the specific X10 command. Since all X10 communication is broadcasted on the power line, the selection phase provides a way for only the corresponding module to respond to the commands sent during the command phase. Table 2.1 shows the list of X10 commands commonly supported Table 2.1 List of X10 commands X10 Commands All units off All lights off All lights on On Off Dim Bright Status Hail To enable communication in binary format, all the house codes, unit codes and X10 commands are encoded in binary format. Tables 2.2 and 2.3 show the encoding scheme used by X10. The packet formats in the selection phase and the command phase are shown in figure 2.1. It has to be noted that the command phase may contain more than one command packet. After the selection phase, all the packets sent until the next selection phase fall under the command phase.

PAGE 18

8 Table 2.2 Encoding used for X10 house and unit codes House code Encoding Unit code Encoding A 0110 1 01100 B 1110 2 11100 C 0010 3 00100 D 1010 4 10100 E 0001 5 00010 F 1001 6 10010 G 0101 7 01010 H 1101 8 11010 I 0111 9 01110 J 1111 10 11110 K 0011 11 00110 L 1011 12 10110 M 0000 13 00000 N 1000 14 10000 O 0100 15 01000 P 1100 16 11000 (b) Packet format in command phase (a) Packet format in selection h X10commnand code House code Start code Number code House code Start code Figure 2.1 X10 command packet formats For example to turn on a lamp with address A03, the controller first sends a packet having A03 and then sends the packet having the command ON. To turn off the same lamp, the command OFF is sent. However, to turn off a different lamp with address A04, the controller sends the packet A04 followed by the packet OFF.

PAGE 19

9 Every packet starts with a start code, which is a special sequence of electric pulses. Start code helps both the sender and receiver to synchronize. For reliability, every packet is transmitted twice. The details of transmission on power line are explained the next section. One of the fundamental drawbacks of this protocol is that, it provides no means to indicate whether a particular command is successful or not. For example, when a light on command is sent, X10 protocol provides no means of knowing if the light was actually on1. X10 provides a very basic form of device discovery. When a new module is plugged into the power line, it sends a packet containing its address. The protocol provides no means to convey the information about the device that is connected to the module. This is yet another drawback of the protocol, since it greatly hampers the development of any service discovery protocol on X10. A simple work around to this situation is presented in section 2.6.1. 2.4 X10 Power Line Transmission Theory X10 Binary data is encoded in the form of electric pulses and are transmitted over the power line. These transmissions are synchronized to the zero crossing point of the AC power line. Since the AC voltage varies in a sinusoidal form, there are two zero crossings in each cycle. 1 The status command provided by X10 only indicates the internal state of the X10 module. It does not take device failures into account.

PAGE 20

10 1 C y cle 2 C y cles AC volta g e Electric p ulse (a) Binary is represented by the p resence a pulse followed by an absence of the pulse (c) Start code is represented by three pulses as shown in figure. (b) Binary is represented by the p resence a pulse followed by an absence of the pulse Figure 2.2 Electrical encoding in X10 [KIN02] Two zero crossings are required to encode the binary numbers and . A binary is represented by a 1 ms burst of followed by an absence of pulse in the next zero crossing. Similarly is represented by the absence of a pulse followed by the presence of a pulse in the next zero crossing. Start code is represented by 1 ms bursts in three consecutive zero crossings, followed by the absence of pulse in the next zero crossing. Figure 2.2 shows the encoding used for binary , and the start code.

PAGE 21

11 2.5 Advantages and Disadvantages The advantages and disadvantages of X10 can be summarized as follows 2.5.1 Advantages X10 technology is simple and inexpensive Require no special wiring Offers wide variety of controllers for simple user interface Has provision for computer control Easily extensible 2.5.2 Disadvantages The maximum number of devices that can be controlled is 256 X10 signals can be degraded, damped or stopped by power conditioning equipment line power supplies, power strips X10 signals might be lost in an electrically noisy environment Has no provision to check if the command was successful X10 does not provide any means by which information about the type of device can be conveyed. For example, using X10, there is no means by which one could find out, if the appliance module is plugged to a radio, television or any other appliance. 2.6 A Scheme for Device Discovery and for Improving Reliability in X10 2.6.1 Device Discovery As mentioned earlier, X10 provides no provision for device discovery. This eliminates the possibility of developing any device discovery and service discovery applications in a computer controlled X10 environment. However Yi-Min Wang, Wilf Russell and Anish Arora who worked on the Microsoft Aladdin project [WAN00] suggested a simple workaround to this situation.

PAGE 22

12 If each power line socket is assigned a unique X10 address and a scheme is prepared before hand, mapping each socket to a particular device, then this information can be stored in a database and can be used by device discovery applications. It has to be noted that all devices need not be present at the time the scheme is prepared. Whenever a new X10 module is plugged, it puts its address on the power line. This can be used as the key to search the database and retrieve information about the devices. This is not at all an impractical assumption considering the fact that in any house, most of the appliances are pretty much fixed to the same location. The scheme has been successfully implemented and tested in Microsofts Aladdin project. 2.6.2 Improving Reliability X10 modules are not reliable, in the sense that they do not provide any mechanism to check if a particular command is successful. For example if an appliance is turned on using an appliance module, X10 provides no means to find out if the appliance is actually turned on. Though a status command provided by X10, it only reflects the internal status of the X10 module and not that of the device. If an appliance is faulty and does not turn on in response to an on command, the X10 module attached to it would still respond to a status command, with status on. This aspect can be easily improved by adding a simple AC current sensor to the X10 module. The sensor detects the current through the device and accordingly prompts the X10 module to respond to the status command. This modification is shown in figure 2.3 and was implemented in Microsoft Aladdin project.

PAGE 23

13 Power line X10 module Simple logic AC Current sensor X10 receiver X10 transmitter Figure 2.3: A reliable X10 module 2.7 Conclusion X10 offers a simple and low cost method of controlling devices. The advantages of X10 come with tradeoffs in reliability. To address these issues, two new technologies namely Consumer Electronic Bus (CEBus) [EVA01][CEB00], and Lonworks were developed recently. CEBus is an open architecture which specifies and define protocols to enable devices to communicate through power line wires, low voltage twisted pairs, coaxial cables, infrared, RF, and fiber optics. All CEBus devices communicate using a Common Application Language (CAL), which is a universal language for home network products. The standard also allows for device discovery as all the CEBus devices follow the Home Plug and Play (HPnP) standard.

PAGE 24

14 Lonworks is networking platform created by Echelon Inc. Lonworks is a networked control system that is significantly more powerful, flexible, and scaleable than a non-networked control system. The devices communicate using a special protocol called LonTalk. Lonworks protocol cannot use the existing power line. Both Lonworks and CEBus based technologies are considerably expensive and more difficult to install when compared to X10. Though CEBus is an open standard, currently there are no CEBus compliant devices available in the retail stores. As a result of these issues, X10 is still the most popular technology used for controlling devices.

PAGE 25

CHAPTER 3 OPEN SERVICES GATEWAY INITIATIVE OSGi The open service gateway initiative (OSGi) is an open reference architecture defined primarily for the delivery of services on the Internet to local networks and devices. The host managing the services in the local network is called as the service gateway. The OSGi platform specification provides an open, common architecture for service providers, developers and equipment vendors to develop, deploy and manage services in an organized and coordinated fashion. The primary targets of OSGi specification are PCs, set top boxes, cable modems, consumer electronics and more. The need for this standardization can be attributed to the following reasons [CHE02]: Platform independence: Different types of devices have their own native platforms and different configurations. It would be impractical for the service providers to port the services to all platforms. OSGi provides a virtual platform on which all services are developed. Vendor independence: Standardized APIs allow for services written by different vendors to cooperate. Future-proof: The lifetime of services that are coupled to a particular underlying technology is just as much as that of the underlying technology. An open standard provides an abstract layer and decouples services from the underlying technology thereby increasing the lifetime. For example, a service written to control devices over power line need not even be recompiled if the underlying technology is changed from X10 to CEBus. The platform independence requirement of OSGi makes JavaTM [SCH01] [HOR00] as the default platform and the specification is not valid for any other platform. Most of the terms used to describe the OSGi architecture are taken from Java TM parlance. 15

PAGE 26

16 The reader of this document is assumed to have knowledge in Java TM programming language. 3.1 OSGi Architecture OSGi has a layered architecture as shown in figure 3.1. The architecture consists of three components: 1. Framework 2. Bundles 3. Services Service Figure 3.1: OSGi Architecture [OSG01] Framework is the heart of this specification as it provides a virtual environment on which services from different vendors can execute. The framework provides clear interfaces for registering new services and a powerful service lookup facility. The framework also provides some basic eventing capabilities, which are described in section 3.4.

PAGE 27

17 Services are java objects that implement a standard interface and execute on the framework. A bundle is a collection of one or more services and is responsible for registering services with the framework. Services are exchanged among bundles through the framework in a secure and controlled manner. Thus, bundles may provide services to other bundles as well as use services from other bundles. Besides providing specification for framework, services and bundles, OSGi also contains Device access specification, which is a mechanism to couple device services to driver services. The terms used in this section are explained in more detail in the subsequent sections. The remainder of this chapter discusses about the services, bundles and framework in detail followed by the device access specification of OSGi. 3.2 Service A service can be defined as a Java TM object implementing a concisely defined interface [OSG01]. In OSGi environment, everything is a service; for example, a web server is a service, so is a library routine that helps in performing a complex calculation or a program to control a particular device. Applications that execute in the OSGi environment are a collection of services; all of which need not necessarily be from the same vendor. As it will be explained later, OSGi provides a mechanism for services to be shared between different applications1. Every service consists of a service interface and a service implementation. Service interface is a Java TM interface, which specifies the functions provided by that service. The purpose of the service interface is to specify the semantics and the behavior 1 In OSGi environment, the term bundle is used instead of the application

PAGE 28

18 of a service. The interface also hides the implementation details of the service. Service implementation, which is also called as service object, is a Java TM object of a class that implements the service interface. It has to be noted that in a typical scenario, there can be many service implementations for a single service interface. Such a scenario exists when different vendors provide the same service or if there are many flavors of the same service. For example, a service to control a particular device, say a camera, has a standardized service interface but depending on the model and make of the camera, the service implementations might vary. 3.2.1 Service Properties According to OSGi specification every service is associated with a Properties object2, which is a collection of (property name, value) pairs. The developer of the service normally defines its properties. Properties provide an information database on top of which, as we shall see in later sections, powerful service lookup mechanisms can be implemented. In addition to the properties defined by the service developer, OSGi specification requires every service to have three mandatory properties, which are objectClass, service.description and service.id. OSGi framework assigns the value for service.id property automatically. As an example, see Table 3.1 to see a list of properties that can be defined for a dictionary service. 2 Properties is a standard class defined in java.util package. It represents a collection of (property name, value) pairs. Please refer to java API documentation for more details.

PAGE 29

19 Table 3.1 Properties of an example dictionary service Property name Value objectClass edu.ufl.icta.Dictionary service.description Dictionary service by UFL service.id XYZ Author ICTA Version 1.1 SourceLanguage English TargetLanguage English 3.2.1 Service Registration, Un-registration When a bundle is started, it registers services with the framework service registry. A registered service is available to other bundles under the control of framework. The framework provides a powerful lookup mechanism by which bundles can query for services and get their references. A registered service can be unregistered at any time by the bundle that registered it. Whenever a bundle is stopped, the framework automatically un-registers all the services registered by that bundle. Details about service registration, un-registration and the interfaces provided by the framework are explained in more detail in section 3.4.

PAGE 30

20 3.3 Bundles A bundle is a collection of services that are packaged in a well-defined fashion. It acts as a means by which services are hooked on to the OSGi framework. This section describes the structure of a bundle and its life cycle. The interaction of bundle with the framework is described in section 3.4. 3.3.1 Bundle Format Bundle is a JAR3 file containing class files corresponding to service interfaces and implementations. Bundles also contain all the resource files like image files, HTML files, data files, configuration files etc. Every bundle should have a special class file that implements the standard interface org.osgi.BundleActivator. The interface specifies two functions start() and stop() which the framework calls when a bundle is installed. Normally, the code to register services and get references to other services is written in the start() function. Code to un-register the service, is written in the stop() function. Details about registering, un-registering and getting reference to other services are explained in section 3.4.2. A file called Manifest specifies the organization of all the files within a bundle. The bundle developer has to create a manifest file before packaging the bundle. The format of manifest file is specified in OSGi Service platform release 2 [OSG01]. Figure 3.2 shows the anatomy of a bundle 3 Java Archive, JAR format is a standard format defined by Sun Microsystems

PAGE 31

21 Classes and Resources Bundle Activator Manifest File Figure 3.2: Anatomy of a bundle 3.3.2 Bundle Life Cycle Unlike other archive files, bundle has different states. A bundle can be in one of the following states: Installed, uninstalled, starting, stopping, resolved and active. Services contained within a bundle can be available only if the bundle is in active state. Figure 3.3 shows the state transition diagram of a bundle. In figure 3.3, the thick arrow lines represent the transitions triggered by the framework and the dotted arrows represent automatic transitions. The bundles life cycle is explained in more detail in section 3.4.3.

PAGE 32

22 Automatic transition Transition by administrative action Uninstalled Active Sto pp in g Startin g Resolved Installed In stall Update Uninstall Start Stop Figure 3.3: Bundle state transition diagram 3.4 OSGi Framework Framework is the heart of OSGi specification. It provides a common ground on which bundles execute. Framework provides the following functionalities: Resolves interdependencies among bundles and makes it possible to share classes and resources among bundles. Maintains a registry of services and provides APIs to register, un-register and lookup services. Manages life-cycle of a bundle Provides a basic eventing mechanism to raise events whenever the state of a bundle, service or the framework changes Implements a device access manager that helps in attaching device services to driver services. This is a part of device access specification which a part of OSGi. Device access specification is explained in detail in section 3.5.

PAGE 33

23 3.4.1 Interdependencies among Bundles: Exporting and Importing Packages As we have seen earlier, a bundle contains all the class files corresponding to the services and the resource files required by those services. However, bundles are not entirely self-sufficient. A service might use some packages that are defined in some other bundle. In such a case, the bundle needs to inform to framework, the list of all packages it wishes to import. Similarly a bundle might choose to export some of its packages so that other bundles might import them. Information about the packages that a bundle wishes to export or import is specified in the bundles Manifest file. When bundles export packages, they are effectively exporting them to the framework. Similarly, when bundles import packages, they are effectively importing them from framework. The scenario is illustrated in figure 3.4. A A A Bundle 2 Bundle 1 (b) Bundle 2 imports Package A from framework (a) Bundle 1 exports Package A to framework Package Package Framework Package A Activator 2 Manifest 1 Framework Package Activator 2 Manifest 1 Export Import Figure 3.4: Exporting and importing packages using OSGi framework

PAGE 34

24 3.4.2 APIs to Register, Un-register and Lookup Services The design philosophy behind OSGi specification is to allow different services to be shared between different applications. For example, a dictionary service may be shared by a word processor service and an English language tutor service. To make such a scenario possible, OSGi requires every bundle to register the services it wishes to share with other bundles4. A service can be unregistered when a bundle no longer wishes to share the service. The framework maintains a service registry having information about all services registered. It is a structure that maps the type and properties of the service (specified in Properties object), to the service object. A reference to the service object is added to the registry when a service is registered. Whenever a service is unregistered, the corresponding entry is removed. As it was mentioned in section 3.2, every service has an associated Properties object that contains the service properties. The framework uses this feature to implement a powerful look up mechanism. To use a service, its reference needs to be obtained from the registry. The look up mechanism provided by the framework helps in searching for services by specifying filters, and obtaining the reference to the service object. 3.4.3 Bundle Life Cycle The framework is responsible for managing the bundles life cycle, which is shown in Figure 3.3. When a bundle is installed, the state of the bundle is INSTALLED. The framework takes the responsibility of loading all the class files and the resource files packaged in the bundle. In the process of loading, it reads the bundles 4 Bundles that do not register any service all called library bundles

PAGE 35

25 manifest file to note the packages exported and imported. This process is called resolution. Upon successful resolution, the state of the bundle is changed to RESOLVED. In case of any errors in resolution, the state of the bundle still remains INSTALLED. Framework provides mechanism to start, stop, update and uninstall a bundle. A bundle can be started only if it is in RESOLVED state and can be stopped only if is in ACTIVE state. When prompted to start a bundle, the framework calls the start() method in the bundles BundleActivator class (Framework gets the information about the BundleActivator class from the Manifest file). Upon successful return form start() function, the bundles state is changed to ACTIVE. When prompted to stop the bundle, the framework calls the stop() function in the bundles activator. Upon successful return, the bundles state is changed to RESOLVED. When the framework is prompted to update a bundle, the entire process is repeated i.e., the bundle is reinstalled and after successful resolution, it is started (by calling the start() function). An important point worth mentioning here is that even after a bundle is uninstalled, the packages that it exported still continue to exist on the framework. Similarly even after a bundle is updated, the older version of the packages it exported exist instead of the newer versions. To reflect the changes in the exported packages, the framework has to be restarted. 3.4.4 Basic Eventing Framework provides basic eventing mechanism to signal the changes in the internal states of the services, bundles and the framework itself.

PAGE 36

26 Bundle events are generated whenever a bundle is installed, started, stopped, updated or uninstalled. Service events are generated whenever a service is registered or un-registered and framework events are generated when the framework is started or if there is an internal error. OSGi clearly defines the interfaces for the listeners of these events [OSG01]. It can be noted that the eventing facility provided by OSGi is very basic and does not provide any generic infrastructure to exchange events between services. A generic eventing model to accomplish this task has been developed as a part of this thesis. 3.5 DAS: Device Access Specification OSGi Device Access Specification, DAS, was developed to address the needs of those applications that involve communication and controlling of devices. Before defining what DAS is, it is essential to clarify some of the common misconceptions about DAS and define what drivers and devices mean in the context of DAS. DAS is not about writing low-level device drivers. Such device drivers are usually a part of the operating system and serve as the bridge between software and hardware. In DAS terminology, they are called base drivers. It should also be clarified that DAS is not about device/service discovery. There are several protocols like UPnP, Jini etc that deal with service/device discovery. DAS is unbiased towards any service discovery protocol. Drivers, in the context of DAS are called driver services and they refer to software services that execute on OSGi platform and communicate with the underlying base drivers to control the devices. Similarly devices, in the context of DAS refer to

PAGE 37

27 device services which are OSGi services providing an abstract view of the actual physical device. With that background, one can define DAS as the specification that supports automatic detection of device services and defines a mechanism to automatically download and install the appropriate driver services. The process of associating a device service with the appropriate driver services is called attaching. DAS consists of the following main components 1. Device service 2. Driver service 3. Driver locator 4. Device manager 3.5.1 Device Service A device service is an abstract view of a device. Device service normally represents a hardware device, but that is not a requirement. There can be a single device service to represent a group of hardware devices, or there can be a device service providing an abstract view of an entire network etc. All device services in OSGi must extend the standard generic device class org.osgi.service.device.Device defined by DAS. When a device service is registered with the framework, the device manager is responsible for finding a suitable driver service and attaching it. The mechanism by which the device manager searches for driver services is explained in section 3.5.4. A device service that is not used by any other bundle is called an idle device service.

PAGE 38

28 3.5.2 Driver Service A driver service is an OSGi service that takes care of communication and controlling of a physical device. Depending on the functionality, driver services are classified into different categories. A detailed taxonomy of driver services is given in OSGi Service platform specification 2 [OSG01]. All driver services in OSGi must implement the org.osgi.service.device.Driver interface, which specifies two methods match() and attach(). These methods are called by the device manager, which is explained in more detail in section 3.5.4. When a device service is registered with the framework, the device manager queries all the driver services by calling their match() method and passing the device services reference as a parameter. In the match() method, a driver service checks if it can be used for the device service passed as an argument. The method returns a value indicating whether or not the driver service can be used. This process is called refining. The implementation details and the return value of the function match() are not specified by the DAS, as they are highly dependent on the type of device and driver. The attach() method of a driver service is called by the device manager if it wants to attach a particular device service to that driver service. The reference to the device service is passed as an argument method. Since the actual method of attaching is highly device specific, the device manager delegates that responsibility to the driver service i.e., by calling its attach() method. Again, DAS does not specify any mechanism for device attachment process.

PAGE 39

29 3.5.3 Driver Locator Driver locators are special services that are called by the device manager to help locate driver services for a particular device service. The function of a driver locator service, as the name itself implies, is to search for suitable drivers and install the drivers5 when asked by the device manager. All driver locator service should implement the standard interface org.osgi.service.device.DriverLocator. The interface specifies two methods findDrivers() and loadDriver(). The method findDrivers() is called by the device manager if it wants the device locator to search for drivers and loadDriver() is called by the device manager, whenever it wants the locator to install a particular driver service. The mechanism used by the driver locator services to search for drivers is not specified by DAS. 3.5.4 Device Manager Device manager is the heart of DAS as it coordinates the actions of device services, driver services and the driver locator services. It is responsible for finding suitable driver services for every device service registered with the framework. The device manager accomplishes this task by following these steps 1. It monitors the framework for new device service registrations 2. If a new device service is registered, it asks all available driver locator services for find drivers by calling their findDrivers() method. It then asks the driver locators to install those driver services by calling their loadDriver() method. 3. The device manager then queries all the driver services (which might also include the newly installed drivers by driver locators) by calling their match() method, to see if they can refine the service. 5 Installing drivers refers to installing the driver bundle and registering the driver service

PAGE 40

30 4. Of the replies, the device manager selects the best driver6 and instructs that driver to attach to the device service. This is done by calling the attach() method. This entire process is illustrated in figure 3.5 Attach DL1 Framework S ( d ) D3 DM D2 D1 DL2 Match Framework S ( c ) D3 DM D2 D1 DL2 DL1 Download driver DL1 Framework S ( b ) D3 DM D2 D1 DL2 N o Yes S DM D2 D1 DL2 DL1 Framework ( a ) (a) New device service S is registered and DM queries all the DLs to find drivers for s1. DL1 does not know about any driver, but DL2 knows about a driver D3. (b) DM asks DL2 to download and install D3. DL2 installs D3 (c) DM queries all the drivers to match the device service. D2 g ives the best res p onse. Legend DM : Device Manager DL : Driver Locator D : Driver Service S : Device service Figure 3.5: Example of Device manager operation [CHE02] 6 To select the best driver service, the device manager consults a special module called Driver Selector. This module is not specified separately as it is considered a part of device manager.

PAGE 41

CHAPTER 4 SOFTWARE INFRASTRUCTURE This chapter discusses the design of event broker, controller and device services, which are the three main components developed as a part of the software infrastructure. These components are developed as software bundles on OSGi. Event broker provides a means for services to cooperate by exchanging software events. This component is generic and is not biased towards any particular class of applications. The remaining two components i.e., controller and the device services, are developed for applications that control X10 devices in a smart home. Controller component takes care of communication with the X10 controller hardware and the device services component is responsible for registering device services1. These device services act as software proxy objects to the actual physical devices and provide software APIs for controlling the devices. In this thesis, two device services are developed: one for lamp and the other for any other electrical appliance. The implementation details of these three components are given in the next chapter. The interaction between them is shown in figure 4.1 To demonstrate the capabilities of this infrastructure, two demo applications are developed. The design and implementation details of these applications are presented in chapter 6. 1 Recall that a device service presents an abstract view of the physical device. See section 3.5.1 for more detailed explanation. 31

PAGE 42

32 Power line Hardware Software Serial port Tw523 Event Broker Controller Device Services User Applications Devices attached to power line Figure 4.1: Components and their interaction in the software infrastructure 4.1 Event Broker This component is developed to allow different services on OSGi platform to communicate using events. As it was seen section 3.4.4, OSGi provides basic event facility and has no infrastructure for customized events. All the applications interested in a particular event must register with the event broker. In order to register, the application must provide the event broker with the event name and a listener function2. This registration process is called subscribing. 2 Listener functions are also called call-back functions

PAGE 43

33 Similarly, when an application is no loner interested in a particular event, it can un-register its listener function from the event broker. This process is called un-subscribing. Whenever a service generates an event, it has to inform the event broker by passing an event object. The process of informing an event occurrence is called signaling. On receiving an event, the event broker invokes the listener functions of all applications that subscribed to that particular event. The process of invoking is called dispatching. The event object is passed to all listener objects while dispatching. Every event object contains the event name, event source, event properties and any other event-specific information. The event broker component defines a standard interface, which every listener function should implement. Similarly the event broker also standardizes the event object that is passed between event source and the destinations. The structure of listener and the event object are explained in more detail in section 5.1. L isteners lis t Listener n Listener 2 Listener 1 E vent Name Figure 4.2: Table entry structure

PAGE 44

34 When a service starts, it has to inform the event broker about all events that it might generate during the course of its execution. This process is called publishing the events. When all services publish their events, it helps the event broker to provide APIs that would list all the events that are currently available for subscription. The event broker maintains all the information in a hash table, which is indexed by the event names. Each entry in the table has two fields, the event name and the list of listeners that subscribed to that event. The structure of the table entry is shown in figure 4.2. When a service publishes its event, an entry with the event name and an empty listeners list is created. When an application subscribes to an event, its listener is added to the list of listeners maintained for that event in the table. When an event is signaled, the event broker gets the list of listeners for that event and invokes each one of them. 4.2 Design of Controller Controller component is designed to interact with the X10 controller device. As mentioned in section 2.2, there are many types of X10 controllers available depending on the type of user interface required. For this software infrastructure, the Tw523 controller is chosen. Tw523 has an interface to connect it to the computers serial port. The connection details are explained in section 5.2.The main goal of the controller component is to provide a software interface to applications that wish to communicate with Tw523 interface. It is designed to automatically detect whenever a Tw523 X10 controller is plugged to the computer serial port and to create and register Tw523 software service with the OSGi framework. The controller component also detects whenever the Tw523 X10 controller is unplugged and it automatically de-registers the Tw523 software service. The design details are explained in more detail in the next three subsections.

PAGE 45

35 The component comprises of the following three software modules 1. Serial port scanner 2. Serial port listener 3. Tw523 software interface Since the controller component is packaged as an OSGi bundle, it is started and stopped through the interface provided by the OSGi framework. 4.2.1 Serial Port Scanner This module is the entry point of the controller component. It begins execution immediately after the controller component is installed and started. The serial port scanner scans for all the available serial ports on the computer. If a serial port is available, it opens the port, sets the serial communication parameters3 and finally creates a serial port listener module for that serial port. There are as many serial port listener modules as the number of serial ports. When the controller component is stopped, the serial port scanner closes all the serial ports that it opened and also stops the serial port listener modules that it created. 4.2.2 Serial Port Listener The serial port listener module is responsible to identify if a Tw523 controller is plugged to (or unplugged from) the serial port. It is also responsible for registering and un-registering the Tw523 software service. It has to be noted that the serial port scanner module does the association between serial port listener and the serial port. When the serial port listener module is created, it listens to all events generated by the serial port to which it is associated.

PAGE 46

36 The serial port raises a CTS true event whenever a device is plugged to it. On listening to this event, the serial port listener checks if the plugged device is a Tw523 controller. If it is Tw523, the serial port listener creates a Tw523 service and registers it with the OSGi framework. Similarly, when a device is unplugged from the serial port, it generates a CTS false event. On listening to this event, the serial port listener un-registers the Tw523 service, if it exists. Note that the serial port listener need not check if the unplugged device is a Tw523. This is because, if Tw523 service exists, then the device plugged to the serial port has to be Tw523. Apart from registering and un-registering Tw523 software service, the serial port listener module also publishes two events namely Tw523 plugged and Tw523 unplugged to the event broker. Serial port listener listens to all events raised by the serial port if is connected to and creates Tw523 driver service if Tw523 controller is plugged to the serial port. Serial port events Serial port scanner Create Scan Serial Port listener N Serial Port listener 2 Serial Port listener 1 Serial port N Serial port 2 Serial port 1 Figure 4.3: Serial port listener and Serial port scanner modules 3 Serial port parameters required for communication with Tw523 are (Baud rate: 1200, Data bits: 8, Parity: None, Stop bits: 1)

PAGE 47

37 Figure 4.3 shows the interaction between serial port scanner, serial port listener and the serial port. 4.2.3 Tw523 Software Interface Tw523 software interface module is the heart of the controller component as it provides a software abstraction to the hardware Tw523 device. The module provides a software interface for all applications that wish to communicate to Tw523 device. The module also senses the power line for any signals generated by X10 devices. If any signal is found, it generates a special event and publishes that event to the eventing broker. This feature is used in the demo applications developed as a part of this thesis. Tw523 Listen to signals on p ower line Communication with Tw523 hardware Signal events to event broke r API to applications Tw523 Listener Tw523 Device Service Tw523 Software interface Figure 4.4: Tw523 software interface module The type of X10 signals and the type of events published by the Tw523 service is explained in more in chapter 6.

PAGE 48

38 Tw523 software module comprises of the following two sub-modules: Tw523 device service Tw523 listener service Tw523 device service provides APIs to send commands to the Tw523 hardware device. Tw523 listener service listens to X10 signals on the power line and publishes events with the event broker, whenever a signal is found. Since event broker is a service outside the scope of the controller component, the Tw523 listener service is robustly designed to publish events only if the event broker service is available. 4.3 Device Services This purpose of device services component is to create device services, which provide software APIs to applications that wish to control devices in a smart home. As it can be seen from figure 4.1, this has a dependency on event broker and controller components. Both device service and controller components are developed for the class of applications that wish to control X10 devices in a smart home. The reason for separating these two is to for scalability and extensibility. The device services component can work with any controller component as long as the interface provided by the latter remains unchanged. This component can be divided into two modules 1. Device service initiator 2. Device services The component is packaged as an OSGi bundle and is started and stopped using the interface provided by the OSGi framework.

PAGE 49

39 4.3.1 Device Service Initiator The purpose of this module is to read a configuration file containing the list of all X10 devices currently present in the smart home and to create device services corresponding to those devices. Since X10 technology provides no mechanism for device discovery, providing a configuration file is the only way of conveying the X10 device information and the smart home layout. Each line in the configuration file conveys information about a particular X10 device and has information about the devices properties. The properties are the devices X10 address, location, device type and other device-specific properties. The format of the configuration file is explained in more detail in section 5.3. Device services component Confi g uration file Device N service Device 2 service Device 1 service Device Service initiator D evice 1 --D evice 2 --. Device N ----To controller com p onent Figure 4.5: Device services component

PAGE 50

40 The device service initiator module reads each line in this configuration file, creates a properties object (see section 3.2.1), creates a device service object corresponding to the device type and finally registers the device service with its properties. It has to be noted that each device service represents a single device. So the number of device services created by the device service initiator is equal to the number of entries in the configuration file i.e., the number of controllable X10 devices in the smart home. Figure 4.4 shows the overall design of device services component. 4.3.2 Device Services As mentioned in section 3.5.1, device services provide an abstract view of a device. In this thesis, device services for two classes of devices have been developed: one for lamp and the other for low power electrical appliances. The device services publish events to the event broker and are designed to publish events only if the event broker service is available. 4.3.2.1 Lamp Device Service This service provides APIs to turn the lamp on, off and to get the lamps status. Apart from these, it also publishes events to the event broker whenever the lamp if turned on or off. 4.3.2.2 Appliance Device Service This service is similar to lamp service and provides APIs to turn the appliance on, off and to get the appliances status. It also publishes appliance on and appliance off to the event broker. The implementation details and the interface definitions of these device services are given in the next chapter.

PAGE 51

CHAPTER 5 IMPLEMENTATION This chapter discusses the implementation details of event broker, controller and device services components. The entire implementation is done in Java programming language and the components are packaged into the following three OSGi bundles: 1. osgiEvent.jar (Event Broker component) 2. osgiDevice.jar (Device services component) 3. osgiTw523.jar (Controller component) Figure 5.1: Package tree of the software infrastructure Controller D evice se r vices Event Broke r genericEventListener edu ufl im p l service impl utils service tw523 constant device utils genericEvent eventBroker os g iX10 osgiEvent osgi 41

PAGE 52

42 The anatomy of a typical OSGi bundle is explained in section 3.3.1. The software infrastructure package tree is shown in figure 5.1. As it can be seen, both the controller and device services components share the package edu.ufl.osgiX10.constants. The next three sections discuss the implementation details of the three components in detail. Two applications are developed to demonstrate the utility of this infrastructure and these are discussed in chapter 6. 5.1 Event Broker In this section, the package structure of event broker, which is shown in figure 5.1, is explained. As it can be seen from figure 5.1, all the classes in this component are under edu.ufl.osgiEvent package. 5.1.1 Package Details edu.ufl.osgiEvent.genericEventListener As explained in section 4.1, every application interested in a particular event, needs to subscribe to the event broker with the event name and a listener object. This package defines a standard listener interface called GenericEventListener. The event broker accepts only the listener objects that implement this listener interface. The interface defines just one method called handleEvent(). The event broker calls this method while dispatching events. The method handleEvent(), expects the event information in an object of type GenericEvent. While dispatching events, the event broker creates a new thread of execution on each listener object. edu.ufl.osgiEvent.GenericEvent The information about any event is passed in the form of an event object. When an event source generates an event, it signals the event broker by passing the event information in the form of an event object.

PAGE 53

43 The event broker dispatches the event by passing the same event object to all subscribed listeners. All the event objects should be of type GenericEvent or its derived classes. edu.ufl.osgiEvent.eventBroker.service This package has the interface definition of the event broker service. The interface is named EventBroker. edu.ufl.osgiEvent.eventBroker.implementation This package has the implementation of event broker service i.e., it has a class called EventBrokerImpl, which implements the EventBroker interface. edu.ufl.osgiEvent.eventBroker.utils This package has event table data structures used by the event broker implementation class. Class Files Resources EventActivator Manifest File Export-list osgiEvent.eventBroker.service osgiEvent.genericEventListener osgiEvent.genericEvent Figure 5.2: Structure of osgiEvent.jar

PAGE 54

44 5.1.2 Bundle Structure The bundle is named as osgiEvent.jar. The structure of the bundle is shown in figure 5.2. As it can be seen, the bundle exports the event broker interface, generic listener and the object classes. 5.2 Controller Component The classes in this component are packaged in edu.ufl.osgiX10.Tw523 as shown in figure 5.1. This component has the classes that implement a driver service for the Tw523 X10 controller. In this section, the connection details of TW523, the package details and the structure of this components bundle are explained 5.2.1 Connecting Tw523 to Computers Serial Port Tw523 controller comes with two interfaces: RJ11 and a power line socket interface. Since RJ11 interface cannot be directly connected to the computers serial port, the scheme shown in figure 5.3 is used for connections. DB9-RS232 Converter RJ11 cable Serial Port TWO-WAY Tw523 Figure 5.3: Connection details of Tw523 A device, called TWO-WAY, is acts as a RJ11 to DB9 converter. Apart from that, TWO-WAY also accepts inputs from serial port in the form of ASCII text, buffers them and communicates with TW523 taking care of all timing details.

PAGE 55

45 Use of TWO-WAY greatly simplifies the task of developing a driver for Tw523.The DB9 interface of TWO-WAY is connected to the serial port using a DB9/RS232 converter. 5.2.2 Package Details edu.ufl.osgiX10.constants This package defines all the constants that are used by X10 applications. The device properties, device types, event names and event types are defined. edu.ufl.osgiX10.Tw523.service This package defines the standard Tw523 device service interface. The interface is named Tw523. edu.ufl.osgiX10.Tw523.implementation This package has a class Tw523Impl that implements the Tw523 interface. This is the core class implementing the driver service for Tw523 device. This class corresponds to the Tw523 software service component explained in section 4.2.3 edu.ufl.osgiX10.Tw523 This package has two classes Tw523Activator and SerialListener, which, correspond to the serial port scanner and serial port listener components explained in sections 4.2.1 and 4.2.2 respectively. 5.2.3 Bundle Structure The bundle is named as osgiTw523.jar. As it can be seen from figure 5.4, this bundle exports the Tw523 interface and the constants package. Since the classes in this component use the event broker, this bundle imports the event broker packages.

PAGE 56

46 Class Files Resources Tw523Activator Manifest File Export-list osgiX10.tw523.service osgiX10.constants Import-list osgiEvent.eventBroker.service osgiEvent.genericEventListener osgiEvent.genericEvent Figure 5.4: Structure of osgiTw523.jar 5.3 Device Services Component The classes in this component are packaged in edu.ufl.osgiX10.device and edu.ufl.osgiX10.constants packages. The design details are given in section 4.3. This component registers device services for all devices in a smart home environment. The information about the devices is initially obtained from a configuration file named X10Mapfile.conf. Device services for lamp and small electrical appliance are developed as a part of this thesis. In this section, the standard properties defined by this component and the

PAGE 57

47 configuration file is explained in detail followed by a brief description of packages and bundle structure. 5.3.1 Standard Device Properties Defined in this Component In section 3.2.1 it was seen that every OSGi service should have some properties associated with it and that these properties help other applications to search for services based on these properties. Since this component creates device services, it should also associate them with some properties. Device services component defines a standard set of properties for every smart home device. These properties are shown in table 5.1. Table 5.1 Standard properties of devices in smart home Property Name Explanation X10_ADDRESS The device X10 address ROOM_NUMBER The room number in which the device is present1. FLOOR_NUMBER The floor number in which the device is present DEVICE_NUMBER The device number DEVICE_TYPE The type of the device as defined in efu.ufl.osgiX10.contants.DeviceType package For example, the property 5-tuple , conveys the following information:

PAGE 58

48 1. It represents an X10 device with address A10. 2. The device is located in room number 2, first floor. 3. The device is a lamp, since the device type is 1 (device types are defined in edu.ufl.osgiX10.constants package). 4. The device is the second lamp in the room, since the device number is 2. It has to be noted that, in addition to the properties listed in table 5.1, the device services may have other properties defined by the user. 5.3.2 X10Mapfile.conf Structure The configuration file is a text file where each line represents the properties of a particular device. The format of each line is shown in figure 5.5 Legend: X10 : X10 Address RN : Room Number FN : Floor Number DN : Device N umbe r
[ ] N ote: 1. The fields are separated by delimiters which can be one of these <,;: \t> If there is no value for the field a "*" has to be entered 2. First five tokens represent the mandatory properties. Hence the property name is not specified (the property names are implicit) 3. The subsequent tokens should be present in (property name, property value) pairs. 4. Device type is according to the values defined in the package edu.ufl.osgiX10.constants.DeviceTypes Figure 5.5: X10Mapfile.conf file structure 1 All the rooms in a smart home should be logically numbered. Similarly all devices in a room should also be logically numbered.

PAGE 59

49 5.3.3 Package Details edu.ufl.osgiX10.device This package has the class DeviceActivator that corresponds to the device service initiator module described in section 4.3.1. It reads X10Mapfile.conf file and creates the device services. edu.ufl.osgiX10.device.utils This package has a utility class called MapfileLoader that is used to parse the configuration file i.e., X10Mapfile.conf file. MapfileLoader has a method called loadMapfile() that reads the configuration file and returns a hash table containing the device X10 address and properties. edu.ufl.osgiX10.device.service This package defines the interfaces of lamp and general electrical appliance devices. edu.ufl.osgiX10.device.impl This package defines the classes that implement the device interfaces defined in the edu.ufl.osgiX10.device.service package. 5.3.4 Bundle Structure The bundle containing the device services component is named osgiDevice.jar Since the device services component uses both the eventing module and the controller module, it imports those packages. The bundle exports the device service package. The structure of osgiDevice.jar is shown in figure 5.6.

PAGE 60

50 Class Files Resources DeviceActivator Manifest File Export-list osgiX10.device.service osgiX10.device.utils osgiX10.constants Import-list osgiEvent.eventBroker.service osgiEvent.genericEventListener osgiEvent.genericEvent osgiX10.tw523.service Figure 5.6: Structure of osgiDevice.jar

PAGE 61

CHAPTER 6 APPLICATIONS USING THE SOFTWARE INFRASTRUCTURE The advantages of software infrastructure that was explained in chapters 4 and 5 are more evident by considering the applications that are built on the infrastructure. In this chapter, two such applications developed as a part of this thesis are explained. One of these applications, named Magic Wand, is developed for cell phones and the other application, named Smart App is for desktops. Both the applications allow the user to remotely control the devices in a smart home. It has to be noted that these applications are developed for demonstration purposes only. 6.1. Design of Smart App Smart App is designed for desktops and it provides a way to remotely control the devices. Figure 6.1 illustrates the design of the application. 6.1.1 Server Side Component of Smart App The server side component of Smart App is called main proxy and it executes on OSGi framework. Main proxy reads the X10mapfile.conf1 file, creates proxy device services2 for each device, and creates a table indexed by the devices X10 addresses. The proxy device services created by main proxy, search for the corresponding device services and associate with them. The devices that can be controlled using Smart app are lamp and radio. 1 Structure of X10Mapfile.conf is explained in section 5.3.2 2 The design and implementation of device services component was already explained in sections 4.3 and 5.3 51

PAGE 62

52 Requests from client side of Smart App are of the following three types. 1. To get a list of all devices in smart home and their properties (see table 5.1) 2. To control a device 3. To register for events Figure 6.1: Architecture of Smart App Client Server Internet Smart App Client (GUI) Main Proxy OSG i Fr a m ewo r k Device Service n Device Service 2 Device Service 1 Device Proxy n Device Proxy 2 Device Proxy Request to get a list of all devices is received by main proxy just once i.e., when the proxy starts. All other requests to control a device or to register for an event have two fields. The first field has the X10 address of the device to be controlled, second field has the appropriate function code and the third field has the function specific data. When main proxy receives such request packets, it looks at the X10 address field, consults its table to find the corresponding device proxy and forwards the request packet to it. The request is then handled accordingly. Events are discussed in section 6.3.

PAGE 63

53 6.1.2 Client Side Component of Smart App The client side component is designed to execute on any remote computer and it provides a nice graphical user interface (GUI) to control the devices. The screen shot of the GUI is shown in figure 6.2. Devices in smart home Figure 6.2: Smart App GUI 6.2. Design of Magic Wand Magic Wand is an application designed to control devices in a smart home using Motorola iDEN phones. Magic Wand is designed using client-server architecture. The server component executes on the OSGi framework while the client component executes on Motorola iDEN phones. Magic wand application is a simple application and controls only two lamps and a radio.

PAGE 64

54 6.2.1 Server Side Component of Magic Wand When the server side component of Magic Wand is started, it searches the OSGi framework and gets references to device services (two lamps and a radio). The component also registers for new mail and system critical events, which are explained in section 6.3. 6.2.2 Client Side Component of Magic Wand The client component is designed for Motorola iDEN phones and it provides graphical user interface. Figure 6.3 shows screen shots of the interface. Figure 6.3: Magic Wand GUI

PAGE 65

55 6.3. Events Though Magic Wand and Smart App are developed as two independent applications, they control the same set of devices. This is made possible by the software infrastructure. The advantages of software infrastructure become more evident when the events are considered. The event broker, which is a part of the infrastructure, allows different applications to communicate using events. To demonstrate this feature, the following events are defined Lamp On event: Generated by the lamp device service when the lamp is turned on Lamp Off event: Generated by the lamp device service when a lamp is turned off Appliance On event: Generated by the appliance device service when the appliance turned on Appliance Off event: Generated by the appliance device service when the appliance turned off System Critical event: Generated when Tw523 controller is plugged out or plugged into the serial port. This event is generated by the serial port component explained in section 4.2.2 New mail event: Generated when a new mail is kept in the mailbox. This event is generated by the Tw523 software interface component that was explained in section 4.2.3 Someone at door event: Generated when someone rings the door bell. This event is generated by the Tw523 software interface component that was explained in section 4.2.3 By default Magic wand is registered to New mail, Someone at door and System critical events. Smart app provides interface that displays a list of all events available and lets user choose the events to subscribe/unsubscribe to. The screen shot shown in figure 6.2 shows this event browser interface.

PAGE 66

56 It can be seen that when the lamp or appliance is turned on/off using Magic Wand, the events can be seen on Smart App. Similarly when New mail, Someone at door and System critical events are generated, both Smart App and Magic Wand receive the notifications. Figure 6.4 shows the screen shots of the critical event when Tw523 controller is unplugged. (a) Alert message displayed on Smart App GUI when TW523 controller is unplugged on the home gateway (b) Alert message displayed on Magic Wand GUI when TW523 controller is unplugged on the home Figure 6.4: Critical events on Smart App and Magic Wand

PAGE 67

CHAPTER 7 CONCLUSION AND FUTURE WORK The previous chapters explained in detail, the motivation behind this thesis, the proposed software infrastructure and also the applications developed to demonstrate its benefits. This chapter summarizes the achievements of this thesis and concludes with a note on future work that can be done to improve it. 7.1. Achievements and Contributions of this Thesis This thesis is a modest attempt to capture the essence of application development for smart homes. The major achievement is the software infrastructure it proposes. Though all the components (excluding the event broker) in the infrastructure are developed for X10 technology, the infrastructure essentially suggests a component-based model for application development. The event broker model that is developed provides a simple and elegant way for different applications to coexist and co-operate. The choice of OSGi was obvious as the standard was developed with a similar philosophy to provide generic framework for application development. The following are the major contributions made by this thesis 1. Generic event broker component 2. APIs to generate complex events 3. X10 driver to communicate with TW523 interface 4. Device service component to control devices 5. Standardized properties to be associated with every device service (see table 5.1) 57

PAGE 68

58 Other achievements include a detailed study on existing technologies like X10, CEBus, Lonworks etc., and identifying X10 as the appropriate choice under the present circumstances 7.2 Future Work As it was said in the previous section, the main purpose of this thesis was to propose a model that would make application development easy. The software infrastructure developed in this thesis focused primarily on the class of applications to control devices in smart homes. While the components are developed to provide a rich set of APIs, there is still a lot of scope for future work. The following list proposes some enhancements than can be done in future Improving X10 modules: As it was mentioned in section 2.5.2, X10 modules suffer form a lot of reliability issues. X10 provides no means to check if a command was successfully executed or not. This feature can be improved suggested in section 2.6.2. This change was proposed in Microsofts Aladdin project [WAN00]. Device discovery in X10: X10 modules provide no way to convey information about the type of device plugged. This prevents any device and service discovery mechanism to be implemented using X10. However, the work around suggested by Microsofts Aladdin project could be used. This work around is explained in section 2.6.1. Providing a generic Serial port device service: Any Java based application that communicates with the serial port uses the javax.comm. API to communicate with the serial port. To use a serial port, the application has to own the port, which prevents any other application from using the serial port. For example, the Tw523 software interface module developed as a part of this thesis owns all the serial ports and prevents any other applications from using them. Developing a serial port device service on OSGi can solve this. The service would own the port and cater to multiple applications in an OSGi environment. Event broker: The event broker can be made more robust by enabling it to dispatch events even over the network. This requires defining APIs to register remote listeners. RMI technology can be used to implement this feature.

PAGE 69

59 7.3 Conclusion The range of applications that can be developed is infinite as it depends on ones imagination and creativity. This is a first step in this direction and the author envisions that the near future would see a gamut of applications to make our lives more pleasurable and independent.

PAGE 70

LIST OF REFERENCES [CEB00] CEBus, CEBus Industrial Council, http://www.cebus.org 03/2002 [CHE02] Kirk Chen, Li Gong, Programming Open Service Gateways with Java Embedded ServerTM Technology, Addison-Wesley, Boston, 2002 [EVA01] Gray Evans, CEBus Demystified: The ANSI/EIA 600 User Guide, McGraw Hill, Columbus, 2001 [HOR00] Cay S. Horstmann, Gary Cornell, Core Java, Prentice Hall India, New Delhi 2000 [KIN02] Phil Kingery, X10-Technical Series, http://www.hometoys.com/resources.htm 03/2002 [OSG01] OSGi, OSGi Service Platform: Release 2 Specification, October 2001 www.osgi.org 04/2002 [SCH01] Herbert Schildt, JavaTM Complete Reference, Tata McGraw Hill, New Delhi, 2001 [WAN00] Yi-Min Wang, Wilf Russell, Anish Arora, A Toolkit for Building Dependable and Extensible Home Networking Applications, USENIX technical program, Winsys, August 2000, http://www.usenix.org/events/usenix-win2000/wang.html 03/2002 60

PAGE 71

BIOGRAPHICAL SKETCH Sree Charan Kuchibhotla was born on November 20th, 1976, in Visakhapatnam, India. He received his bachelors degree in engineering from Karnataka Regional Engineering College, Surathkal, India, in June 1999. Soon after graduating, he worked for IBM, India as a software developer until December 2000. His area of work in IBM was on network security and network file systems. He joined the University of Florida in January 2001, to pursue a masters degree in computer and information sciences. He served as a teaching assistant for Mr. William B. Noffsinger till May 2002. Sree Charan became a part of Harris Communications laboratory in August 2001 and his major achievements include winning first place in Motorola killer app. competitions in December 2001. He has a passion for new technology and his interests are in the field of pervasive computing. After graduation, Sree Charan will be moving to Madison, Wisconsin, where he will be working as a full time software developer in EPIC systems corp. 61


Permanent Link: http://ufdc.ufl.edu/UFE0000557/00001

Material Information

Title: An OSGI based infrastructure for smart homes of the future
Physical Description: Mixed Material
Language: English
Creator: Kuchibhotla, Sree Charan ( Dissertant )
Helal, Abdelsalam A. ( Thesis advisor )
Frank, Michael ( Reviewer )
Mann, William ( Reviewer )
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2002
Copyright Date: 2002

Subjects

Subjects / Keywords: Computer and Information Science and Engineering thesis, M.S
Home automation   ( lcsh )
Intelligent buildings   ( lcsh )
Dissertations, Academic -- UF -- Computer and Information Science and Engineering

Notes

Abstract: Pervasive computing enables people to accomplish personal and professional activities using intelligent and portable devices. Recent advances in this field have led to the notion of "smart spaces," which are ordinary environments equipped with intelligent devices, that can perceive and react to people. "Smart homes" are smart spaces which bring pervasive technology to our homes and their scope is not only to enhance the quality of our lives, but also to enable the elderly and the disabled to lead an independent life. In 1999, OSGi (Open Services Gateway Initiative) was established as an independent non-profit organization working to define and promote delivery of managed services to networks in home and other environments. OSGi specification requires services to be packaged into software "bundles." It also provides a framework on which these software bundles from different vendors can execute and interact. This thesis aims at providing a software infrastructure based on OSGi for developing various services in a smart home environment. A generic event broker to facilitate software events to be passed among different services is also developed. To demonstrate the utility of the infrastructure, two applications, namely Smart App and Magic Wand, have been developed that would allow remotely controlling devices in a smart home. Magic Wand is developed for Motorola iDEN cell phones while Smart App is developed for desktops. Smart App provides features to control the appliances in a smart home and to display the events handled by the event broker. It also provides an interface which the user may use to subscribe to events or create custom events. Magic Wand is targeted for the elderly and it provides features to turn the appliances on and off in a smart home. It also gives notifications when new mail is delivered or when someone rings the doorbell. Both these applications use the infrastructure and operate on the same set of devices. The interaction among these applications is only through software events. A cell phone providing many such services can indeed be a magic wand assisting the elderly into successful aging.
General Note: Title from title page of source document.
General Note: Includes vita.
Thesis: Thesis (M.S.)--University of Florida, 2002.
Bibliography: Includes bibliographical references.
General Note: Text (Electronic thesis) in PDF format.

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
Resource Identifier: aleph - 002898360
System ID: UFE0000557:00001

Permanent Link: http://ufdc.ufl.edu/UFE0000557/00001

Material Information

Title: An OSGI based infrastructure for smart homes of the future
Physical Description: Mixed Material
Language: English
Creator: Kuchibhotla, Sree Charan ( Dissertant )
Helal, Abdelsalam A. ( Thesis advisor )
Frank, Michael ( Reviewer )
Mann, William ( Reviewer )
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2002
Copyright Date: 2002

Subjects

Subjects / Keywords: Computer and Information Science and Engineering thesis, M.S
Home automation   ( lcsh )
Intelligent buildings   ( lcsh )
Dissertations, Academic -- UF -- Computer and Information Science and Engineering

Notes

Abstract: Pervasive computing enables people to accomplish personal and professional activities using intelligent and portable devices. Recent advances in this field have led to the notion of "smart spaces," which are ordinary environments equipped with intelligent devices, that can perceive and react to people. "Smart homes" are smart spaces which bring pervasive technology to our homes and their scope is not only to enhance the quality of our lives, but also to enable the elderly and the disabled to lead an independent life. In 1999, OSGi (Open Services Gateway Initiative) was established as an independent non-profit organization working to define and promote delivery of managed services to networks in home and other environments. OSGi specification requires services to be packaged into software "bundles." It also provides a framework on which these software bundles from different vendors can execute and interact. This thesis aims at providing a software infrastructure based on OSGi for developing various services in a smart home environment. A generic event broker to facilitate software events to be passed among different services is also developed. To demonstrate the utility of the infrastructure, two applications, namely Smart App and Magic Wand, have been developed that would allow remotely controlling devices in a smart home. Magic Wand is developed for Motorola iDEN cell phones while Smart App is developed for desktops. Smart App provides features to control the appliances in a smart home and to display the events handled by the event broker. It also provides an interface which the user may use to subscribe to events or create custom events. Magic Wand is targeted for the elderly and it provides features to turn the appliances on and off in a smart home. It also gives notifications when new mail is delivered or when someone rings the doorbell. Both these applications use the infrastructure and operate on the same set of devices. The interaction among these applications is only through software events. A cell phone providing many such services can indeed be a magic wand assisting the elderly into successful aging.
General Note: Title from title page of source document.
General Note: Includes vita.
Thesis: Thesis (M.S.)--University of Florida, 2002.
Bibliography: Includes bibliographical references.
General Note: Text (Electronic thesis) in PDF format.

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
Resource Identifier: aleph - 002898360
System ID: UFE0000557:00001


This item has the following downloads:


Full Text











AN OSGi BASED SOFTWARE INFRASTRUCTURE FOR SMART HOMES OF THE
FUTURE













By

SREE CHARAN KUCHIBHOTLA


A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2002




























Copyright 2002

by

Sree Charan Kuchibhotla






























TO MY WONDERFUL PARENTS















ACKNOWLEDGMENTS

I express my gratitude to Dr. Abdelsalam (Sumi) Helal for his encouragement and

support, without which this work would not have been possible. I would also like to

thank Dr. Michael Frank and Dr. William Mann for agreeing to serve on my committee.

I thank my friend Vijay M. Vokkaarne for his contribution to Magic Wand

application and for all his support.

Finally, I would like to thank my friends Sasidhar and Suchindra for their

suggestions and for patiently listening to my endless lectures on this thesis design.
















TABLE OF CONTENTS
A C K N O W L E D G M E N T S ..................................................................... .....................iv

L IST O F T A B L E S ......... .. ...... .... .. ...... .................................................... vii

LIST OF FIGU RE S ......... ..................................... ........... vii

A B S T R A C T ...............................................................................................ix
CHAPTER
1 IN TR OD U CTION ............................................. .. ...... .... ............ .. 1
1.1 M otivation....................................................... ........ ......... 1
1.2 O organization of the T hesis.......................................................................... ...... 2
2 X 10-PROTOCOL .......... .. ........ .......... .. ......... ...... ............. .. .4
2 .1 H history of X 10 ................................................... .......................................... . 4
2 .2 X 10 A rchitecture......... .................................................................. .......... .... 5
2.3 X 10 Protocol ...................................................... 7
2.4 X10 Power Line Transmission Theory .............................. ..............9
2.5 Advantages and Disadvantages ................................ ....................11
2 .5.1 A dv antages.................................................. 11
2.5.2 D disadvantages ...... ........ ............... .. .... ..... ...... ......... ... .. ................. .. 11
2.6 A Scheme for Device Discovery and for Improving Reliability in X10 ..............11
2.6.1 D evice D discovery .................. .............................. ... ..... .. .......... 11
2.6.2 Im proving R eliability......................................................... .............. 12
2.7 Conclusion ...................................... ................................ ......... 13
3 OPEN SERVICES GATEWAY INITIATIVE OSGi ............................................... 15
3.1 O SG i A architecture ............. .... ........ .............. .................... .. .................. 16
3 .2 S e rv ic e .............. ................. ............... ...............................................1 7
3.2.1 Service Properties ............ ...... ..... .... ......... ... ......... 18
3.2.1 Service Registration, Un-registration ........ .......................... ........ 19
3 .3 B u n dles ............................................................................ 2 0
3.3.1 Bundle Form at .................................. ... .... ..... ............ 20
3.3.2 B undle L ife C ycle ...... .. .................................................. .... .... .... .. ....2 1
3.4 O SG i Fram ew ork ................. ... ...... .. .... ...... .. .. ... ............. ...... ..... 22
3.4.1 Interdependencies among Bundles: Exporting and Importing Packages........23
3.4.2 APIs to Register, Un-register and Lookup Services .................................24
3.4.3 B undle L ife C ycle .......... ......................... .... ................. 24
3.4.4 B asic Eventing ...................... .................. ................... ..... .... 25




v









3.5 DAS: Device Access Specification.......................... .......................... 26
3.5.1 D vice Service ...................... .................. ................... ..... .... 27
3.5.2 D river Service .......................................................... ... .... ... 28
3.5.3 D river L ocator............ ........................................................ ...... .... ..... 29
3.5.4 D evice M manager .................................. .............. ....... .. ............ 29
4 SOFTW ARE INFRASTRUCTURE................................... .............................. ...... 31
4 .1 E v ent B rok er .............................................................................. 32
4.2 D design of C controller ........................ .... ............ ................... ......... 34
4 .2 .1 S erial P ort S can n er............................................................... .....................3 5
4 .2 .2 S erial P ort L isten er .............................................................. .....................3 5
4.2.3 Tw 523 Softw are Interface......................................... .......................... 37
4 .3 D evice Services........... ..... ............................................................ ......... .. 38
4.3.1 D evice Service Initiator ............... ...... .. ............. .................................39
4.3.2 Device Services.............. ... ........................ .......40
5 IM PL E M E N T A T IO N .......................................................................... ................... 4 1
5 .1 E v en t B ro k er ............................................................................................4 2
5 .1.1 P ack ag e D etails............ .... .......................................................... .... .... ... 4 2
5.1.2 Bundle Structure .............. ......... .. ... ........... ...... ............ 44
5.2 C controller C om ponent ..................... ........................................ ...............44
5.2.1 Connecting Tw523 to Computer's Serial Port..................... ..................44
5.2.2 Package Details.............. ... ................ ...... ... ....... 45
5.2 .3 B undle Structure .......................... .. ...................... .. ........... 45
5.3 Device Services Component............ .... ....................46
5.3.1 Standard Device Properties Defined in this Component ..............................47
5.3.2 X 10M apfile.conf Structure .................................... ......................... ......... 48
5 .3 .3 P ack ag e D etails............ .... .......................................................... .... .... ... 4 9
5.3.4 B undle Structure .......................... .. ...................... .. ........... 49
6 APPLICATIONS USING THE SOFTWARE INFRASTRUCTURE ........................51
6.1. D design of "Sm art A pp" ............................................................... ..................... 51
6.1.1 Server Side Component of Smart App............... ............................................51
6.1.2 Client Side Component of Sm art App .................................... ............... 53
6 .2 D design of M agic W and ......................................................................................... 53
6.2.1 Server Side Component of Magic Wand .......................................................54
6.2.2 Client Side Component of Magic Wand ............. ........................................54
6 .3 E v e n ts ....................................................................... 5 5
7 CONCLUSION AND FUTURE WORK ........................................ ............... 57
7.1 Achievements and Contributions of this Thesis .............................................. 57
7.2 Future W ork ............................................................... ... .... ........ 58
7 .3 C o n clu sio n ......................................................................... 5 9
L IST O F R EFER EN CE S .......................................................................... ..............60

BIOGRAPHICAL SKETCH ............................................................. ............... 61
















LIST OF TABLES


Table Page

2.1 List of X 10 com m hands ........ .................................... .................... .......... ..

2.2 Encoding used for X 10 house and unit codes..................................... .....................8
3.1 Properties of an example dictionary service..................... .......... .... .......... 19

5.1 Standard properties of devices in smart home................................. ...................47
















LIST OF FIGURES

Figure Page


2.1 X 10 com m and packet form ats ........................................................................... 8
2 .2 E electrical encoding in X 10 ........................................... ......................................... 13
2 .3 A reliab le X 10 m odule ............. .......................................................... .. .... .... .. ... 13
3.1 OSGi Architecture ............................................... ............... 16
3 .2 A natom y of a bundle............ ......................................................................... .. ....... .. 2 1
3.3 Bundle state transition diagram ............................................................................22
3.4 Exporting and importing packages using OSGi framework.................... ........ 23
3.5 Example of Device m manager operation ............................................ ............... 30
4.1 Components and their interaction in the software infrastructure..............................32
4.2 Table entry structure ............................................ .. .... .... .......... .. .... 33
4.3 Serial port listener and Serial port scanner modules ....................................... 36
4.4 Tw 523 softw are interface m odule ........................................ .......................... 37
4 .4 D evice services com ponent .............................................................. .....................39
5.1 Package tree of the software infrastructure................... ......................................41
5.2 Structure of osgiEvent.jar ......... ................................. ................................... 43
5.3 C connection details of Tw 523 ............................................... ............................ 44
5.4 Structure of osgiTw 523.jar ..................................... .............................. ...............46
5.5 X OM apfile. conf file structure ...................................................................... 48
5.6 Structure of osgiD evice.jar ........................................................................... ...... 50
6.1 A architecture of Sm art App .................................... ........... ............. .........................52
6.2 Sm art App GU I ..................................... ............................... .......... .... 53
6 .3 M ag ic W and G U I ............................................................................... ................ .. 54
6.4 Critical events on Smart App and Magic Wand............... ....... .....................56




viii















Abstract of Thesis Presented to the Graduate School
Of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

AN OSGi BASED INFRASTRUCTURE FOR SMART HOMES OF THE FUTURE

By

Sree Charan Kuchibhotla

December 2002

Chair: Dr. Abdelsalam (Sumi) Helal
Major Department: Computer and Information Sciences and Engineering.

Pervasive computing enables people to accomplish personal and professional

activities using intelligent and portable devices. Recent advances in this field have led to

the notion of "smart spaces," which are ordinary environments equipped with intelligent

devices that can perceive and react to people. "Smart homes" are smart spaces which

bring pervasive technology to our homes and their scope is not only to enhance the

quality of our lives, but also to enable the elderly and the disabled to lead an independent

life.

In 1999, OSGi (Open Services Gateway Initiative) was established as an

independent non-profit organization working to define and promote delivery of managed

services to networks in home and other environments. OSGi specification requires

services to be packaged into software "bundles." It also provides a framework on which

these software bundles from different vendors can execute and interact.









This thesis aims at providing a software infrastructure based on OSGi for

developing various services in a smart home environment. A generic event broker to

facilitate software events to be passed among different services is also developed. To

demonstrate the utility of the infrastructure, two applications, namely Smart App and

Magic Wand, have been developed that would allow remotely controlling devices in a

smart home. Magic Wand is developed for Motorola iDEN cell phones while Smart App

is developed for desktops.

Smart App provides features to control the appliances in a smart home and to

display the events handled by the event broker. It also provides an interface which the

user may use to subscribe to events or create custom events. Magic Wand is targeted for

the elderly and it provides features to turn the appliances on and off in a smart home. It

also gives notifications when new mail is delivered or when someone rings the doorbell.

Both these applications use the infrastructure and operate on the same set of devices. The

interaction among these applications is only through software events.

A cell phone providing many such services can indeed be a magic wand assisting

the elderly into successful aging.














CHAPTER 1
INTRODUCTION

Computers have evolved from mere number-crunching machines to indispensable

smart machines assisting people in almost all walks of life. The emergence of personal

computing in the 1980s changed the general perception towards computers and more

recently the advent of the Internet and the emergence of portable and handheld devices

lead to the notion of ubiquitous and pervasive computing.

Pervasive computing is all about making technology an integral part of our lives.

It aims at enabling people to accomplish professional and personal activities with ease.

The concept of pervasive computing lead to an exponential growth in the number of

mobile portable devices like PDAs, laptops, smart phones etc. Pervasive computing is

realized by creating smart spaces, which are environments embedded with devices to

perceive and respond to users' actions and events.

Smart spaces not only improve the quality of professional life, but can also help

us in making our personal lives more comfortable. A smart home, which is defined as a

home with smart spaces, not only makes our life more pleasurable but also has immense

potential in promoting independent living and assisting us into successful aging.

1.1 Motivation

In the recent years, many applications are being developed for the smart home

environment. Each of these applications targets a particular aspect like controlling smart

devices, providing security etc. The lack of an organized approach in developing









applications for smart home almost made it impossible to compile all these into a single

comprehensive package for any smart home.

OSGi was started in 1999, to specify a standard that would allow services on the

Internet to be delivered to the local networks. This was the first step towards an

organized approach for application development. The standard specifies a framework on

which applications packaged in the form of software services, can execute. The

framework allows for complex services to be built on top of existing services.

In this thesis, a software infrastructure has been developed on top of OSGi. The

infrastructure contains the following three components:

1. Generic event broker

2. X10 Controller

3. Device services

The generic event broker component defines APIs that allows different services

on OSGi to communicate by means of software events. The remaining two components

are targeted towards the class of applications that control devices in a smart home using

the X10 technology.

1.2 Organization of the Thesis

Since the software infrastructure developed as a part of this thesis, primarily

targets applications to control devices using X10, an introduction to X10 technology is

given in chapter 2. In chapter, a detailed description of OSGi, which is the framework

used by the software infrastructure, is given. Chapter 4 and 5 discuss the design and

implementation details of the infrastructure.









To demonstrate the use of this infrastructure, two applications are developed. The

details of these are given in chapter 6. Chapter 7 discusses the scope for future work and

concludes by summarizing the contributions made by this thesis.














CHAPTER 2
X10-PROTOCOL

X10 is a communication language that allows devices to talk with each other via

the existing 110V electrical wiring. X10 is by far the most successful and widely used

technology for communication over power lines. Use of electrical wiring is one of the

strong aspects of the protocol as it saves the cost of rewiring. The success of X10 can be

attributed to the protocol's simplicity and the low cost of X10 devices.

This chapter discusses the history of X10 and provides a detailed explanation of

its protocol. The advantages and disadvantages are listed next, followed by a note on the

tradeoffs and simple solutions to overcome some of the disadvantages. Finally, a brief

overview of CEBUS and Lonworks technologies, which are similar to X10, is presented.

2.1 History of X10

X10 protocol is developed by Pico Electronics Ltd. of Scotland, which was

founded in the early 1970's. The company specializes in developing advanced integrated

circuits mostly for the calculators. Every time Pico began a new project, it was given an

"experiment" number. Experiments from 1 to 9 were mainly in developing integrated

circuits for calculators. In the mid seventies, a company named BSR (British Sound

Reproduction) signed a project with Pico Electronics to provide an electronic, wireless

method of remote control for its equipment. This project was called experiment 10, or

simply X10.









It was soon realized that X10 has far more potential in many applications in

addition to those for which it was originally conceived. Radio Shack, which later became

the largest distributor of X10 components, introduced the technology in the American

market in 1979 and with in a few years X10 products were widely used in homes across

the United States. Lamps and appliances were the most common devices that were

controlled by X10 modules. Over the years, more sophisticated X10 modules were

developed for a wide range of devices like cameras, motion detectors, thermostats,

doorbells etc., but the protocol essentially remained the same.

2.2 X10 Architecture

X10 architecture consists of two entities

1. X10 modules: These are attached to the devices to be controlled. X10
modules plug into the electrical sockets and provide a new electrical
socket in which the device to be controlled is to be plugged.

2. X10 controller: These are the cardinal components of X10 architecture.
An X10 controller sends control signals to X10 modules, over the power
line and receives responses. There can be more than one controller to
control a set of X10 modules.

Depending on the functionality, X10 components are also broadly classified into

two categories: X10 transmitters and X10 receivers.

1. X10 transmitters are devices that are capable of sending X10 signals over
the power line.

2. X10 receivers are devices that are capable of receiving X10 signals over
the power line

3. X10 trans-receivers are devices that are capable of both sending and
receiving X10 signals over the power line.

In the remainder of the chapter, unless other wise stated, modules, controllers,

receivers, transmitters refer to the corresponding X10 components.









It can be noted that modules and controllers fall under one of these three

categories. Generally, all modules are receivers and all controllers are transmitters.

All X10 components i.e., modules and controllers, have an address called the X10

address. A typical X10 address consists of two parts, house code and the unit code.

House code can take any value from "A" to "P" and unit code can take any value from

"1" to "16". The address is specified as a combination of house and unit codes. For

example, "A01," "B 16," "C02," etc. are all valid X10 addresses. It can be observed that

the total number of addresses possible is 256, ranging from "A01" to "P16", which

means that 256 is the maximum number of devices that can be controlled using the X10

protocol.

Depending on the type of type of user interface, controllers can be broadly classified

into three types

1. Mini controllers: These are generally wall-mounted units that are plugged
to the power line. These controllers have provision for taking user
commands and some of the controllers have LCD displays to show the
status of devices.

2. Wireless controllers: These are plugged to the power line and also have an
RF interface. They require a remote control through which the user can
enter commands, which are transmitted to the controller using RF. The
controller parses these commands and performs the appropriate action by
communicating with the modules, over the power line.

3. Computer controllers: These controllers are of great practical significance
and are used in all computer-controlled X10 projects. They have power
line interface and RS-232 interface, which enables them to be plugged to
the computer's serial port. Some of the controllers have RJ11 interface, in
which case a RJ11 to RS-232 converter is required to plug them to the
serial port. The controllers enable users to use sophisticated and
customized applications to enter commands, which are parsed by the
controller.









2.3 X10 Protocol

X10 communication comprises of two phases, the selection phase and the

command phase. All the communication is done in binary format. In the selection phase,

the controller puts the address of the corresponding X10 device to control, on the power

line. In the command phase, the controller puts the specific X10 command. Since all X10

communication is broadcasted on the power line, the selection phase provides a way for

only the corresponding module to respond to the commands sent during the command

phase. Table 2.1 shows the list of X10 commands commonly supported

Table 2.1 List of X10 commands

X10 Commands
All units off
All lights off
All lights on
On
Off
Dim
Bright
Status
Hail


To enable communication in binary format, all the house codes, unit codes and

X10 commands are encoded in binary format. Tables 2.2 and 2.3 show the encoding

scheme used by X10.

The packet formats in the selection phase and the command phase are shown in

figure 2.1. It has to be noted that the command phase may contain more than one

command packet. After the selection phase, all the packets sent until the next selection

phase fall under the command phase.









Table 2.2 Encoding used for X10 house and unit codes

House code Encoding Unit code Encoding
A 0110 1 01100
B 1110 2 11100
C 0010 3 00100
D 1010 4 10100
E 0001 5 00010
F 1001 6 10010
G 0101 7 01010
H 1101 8 11010
I 0111 9 01110
J 1111 10 11110
K 0011 11 00110
L 1011 12 10110
M 0000 13 00000
N 1000 14 10000
0 0100 15 01000
P 1100 16 11000



Start code House code Number code


(a) Packet format in selection


Start code House code XlOcommnand code


(b) Packet format in command phase

Figure 2.1 X10 command packet formats



For example to turn on a lamp with address A03, the controller first sends a

packet having "A03" and then sends the packet having the command "ON". To turn off

the same lamp, the command "OFF" is sent. However, to turn off a different lamp with

address "A04", the controller sends the packet "A04" followed by the packet "OFF".









Every packet starts with a start code, which is a special sequence of electric

pulses. Start code helps both the sender and receiver to synchronize. For reliability, every

packet is transmitted twice. The details of transmission on power line are explained the

next section.

One of the fundamental drawbacks of this protocol is that, it provides no means to

indicate whether a particular command is successful or not. For example, when a "light

on" command is sent, X10 protocol provides no means of knowing if the light was

actually on.

X10 provides a very basic form of device discovery. When a new module is

plugged into the power line, it sends a packet containing its address. The protocol

provides no means to convey the information about the device that is connected to the

module. This is yet another drawback of the protocol, since it greatly hampers the

development of any service discovery protocol on X10. A simple work around to this

situation is presented in section 2.6.1.

2.4 X10 Power Line Transmission Theory

X10 Binary data is encoded in the form of electric pulses and are transmitted over

the power line. These transmissions are synchronized to the zero crossing point of the AC

power line. Since the AC voltage varies in a sinusoidal form, there are two zero crossings

in each cycle.








1 The status command provided by X10 only indicates the internal state of the X10 module. It does not take
device failures into account.





















(a) Binary '1' is represented by the
presence a pulse followed by an
absence of the pulse


(b) Binary '0' is represented by the
presence a pulse followed by an
absence of the pulse


(c) Start code is represented by three pulses as shown in figure.

Figure 2.2 Electrical encoding in X10 [KIN02]



Two zero crossings are required to encode the binary numbers "1" and "0". A

binary "1" is represented by a 1 ms burst of followed by an absence of pulse in the next

zero crossing. Similarly "0" is represented by the absence of a pulse followed by the

presence of a pulse in the next zero crossing. Start code is represented by 1 ms bursts in

three consecutive zero crossings, followed by the absence of pulse in the next zero

crossing. Figure 2.2 shows the encoding used for binary "O", "1" and the start code.









2.5 Advantages and Disadvantages

The advantages and disadvantages of X10 can be summarized as follows

2.5.1 Advantages

> X10 technology is simple and inexpensive

> Require no special wiring

SOffers wide variety of controllers for simple user interface

> Has provision for computer control

> Easily extensible

2.5.2 Disadvantages

SThe maximum number of devices that can be controlled is 256

SX10 signals can be degraded, damped or stopped by power conditioning
equipment line power supplies, power strips

SX10 signals might be lost in an electrically noisy environment

SHas no provision to check if the command was successful

SX10 does not provide any means by which information about the type of
device can be conveyed. For example, using X10, there is no means by
which one could find out, if the appliance module is plugged to a radio,
television or any other appliance.

2.6 A Scheme for Device Discovery and for Improving Reliability in X10

2.6.1 Device Discovery

As mentioned earlier, X10 provides no provision for device discovery. This

eliminates the possibility of developing any device discovery and service discovery

applications in a computer controlled X10 environment. However Yi-Min Wang, Wilf

Russell and Anish Arora who worked on the Microsoft Aladdin project [WANOO]

suggested a simple workaround to this situation.









If each power line socket is assigned a unique X10 address and a scheme is

prepared before hand, mapping each socket to a particular device, then this information

can be stored in a database and can be used by device discovery applications. It has to be

noted that all devices need not be present at the time the scheme is prepared. Whenever a

new X10 module is plugged, it puts its address on the power line. This can be used as the

key to search the database and retrieve information about the devices.

This is not at all an impractical assumption considering the fact that in any house,

most of the appliances are pretty much fixed to the same location. The scheme has been

successfully implemented and tested in Microsoft's Aladdin project.

2.6.2 Improving Reliability

X10 modules are not reliable, in the sense that they do not provide any

mechanism to check if a particular command is successful. For example if an appliance is

turned on using an appliance module, X10 provides no means to find out if the appliance

is actually turned on. Though a "status" command provided by X10, it only reflects the

internal status of the X10 module and not that of the device. If an appliance is faulty and

does not turn on in response to an "on" command, the X10 module attached to it would

still respond to a "status" command, with status "on".

This aspect can be easily improved by adding a simple AC current sensor to the

X10 module. The sensor detects the current through the device and accordingly prompts

the X10 module to respond to the "status" command. This modification is shown in

figure 2.3 and was implemented in Microsoft Aladdin project.












-- X10 transmitter




Simple logic AC Current
sensor


I Power line
X10 receiver



X10 module




Figure 2.3: A reliable X10 module

2.7 Conclusion

X10 offers a simple and low cost method of controlling devices. The advantages

of X10 come with tradeoffs in reliability. To address these issues, two new technologies

namely Consumer Electronic Bus (CEBus) [EVA01][CEBOO], and Lonworks were

developed recently.

CEBus is an open architecture which specifies and define protocols to enable

devices to communicate through power line wires, low voltage twisted pairs, coaxial

cables, infrared, RF, and fiber optics. All CEBus devices communicate using a Common

Application Language (CAL), which is a universal language for home network products.

The standard also allows for device discovery as all the CEBus devices follow the Home

Plug and Play (HPnP) standard.









Lonworks is networking platform created by Echelon Inc. Lonworks is a

networked control system that is significantly more powerful, flexible, and scaleable than

a non-networked control system. The devices communicate using a special protocol

called LonTalk. Lonworks protocol cannot use the existing power line.

Both Lonworks and CEBus based technologies are considerably expensive and

more difficult to install when compared to X10. Though CEBus is an open standard,

currently there are no CEBus compliant devices available in the retail stores. As a result

of these issues, X10 is still the most popular technology used for controlling devices.














CHAPTER 3
OPEN SERVICES GATEWAY INITIATIVE OSGi

The open service gateway initiative (OSGi) is an open reference architecture

defined primarily for the delivery of services on the Internet to local networks and

devices. The host managing the services in the local network is called as the service

gateway. The OSGi platform specification provides an open, common architecture for

service providers, developers and equipment vendors to develop, deploy and manage

services in an organized and coordinated fashion. The primary targets of OSGi

specification are PCs, set top boxes, cable modems, consumer electronics and more.

The need for this standardization can be attributed to the following reasons

[CHE02]:

Platform independence: Different types of devices have their own native
platforms and different configurations. It would be impractical for the service
providers to port the services to all platforms. OSGi provides a virtual platform on
which all services are developed.

Vendor independence: Standardized APIs allow for services written by different
vendors to cooperate.

Future-proof: The lifetime of services that are coupled to a particular underlying
technology is just as much as that of the underlying technology. An open standard
provides an abstract layer and decouples services from the underlying technology
thereby increasing the lifetime. For example, a service written to control devices
over power line need not even be recompiled if the underlying technology is
changed from X10 to CEBus.

The platform independence requirement of OSGi makes JavaTM [SCH01]

[HOROO] as the default platform and the specification is not valid for any other platform.

Most of the terms used to describe the OSGi architecture are taken from Java TM parlance.










The reader of this document is assumed to have knowledge in Java TM programming

language.

3.1 OSGi Architecture

OSGi has a layered architecture as shown in figure 3.1. The architecture consists

of three components:

1. Framework

2. Bundles

3. Services












Java VM

Service Operating Sstem

Driver Driver Driver

Hardware
Figure 3.1: OSGi Architecture [OSG01]

Framework is the heart of this specification as it provides a virtual environment

on which services from different vendors can execute. The framework provides clear

interfaces for registering new services and a powerful service lookup facility. The

framework also provides some basic evening capabilities, which are described in section

3.4.









Services are java objects that implement a standard interface and execute on the

framework. A bundle is a collection of one or more services and is responsible for

registering services with the framework. Services are exchanged among bundles through

the framework in a secure and controlled manner. Thus, bundles may provide services to

other bundles as well as use services from other bundles.

Besides providing specification for framework, services and bundles, OSGi also

contains Device access specification, which is a mechanism to couple device services to

driver services. The terms used in this section are explained in more detail in the

subsequent sections.

The remainder of this chapter discusses about the services, bundles and

framework in detail followed by the device access specification of OSGi.

3.2 Service

A service can be defined as a Java TM object implementing a concisely defined

interface [OSG01]. In OSGi environment, everything is a service; for example, a web

server is a service, so is a library routine that helps in performing a complex calculation

or a program to control a particular device. Applications that execute in the OSGi

environment are a collection of services; all of which need not necessarily be from the

same vendor. As it will be explained later, OSGi provides a mechanism for services to be

shared between different applications1.

Every service consists of a service interface and a service implementation.

Service interface is a Java TM interface, which specifies the functions provided by that

service. The purpose of the service interface is to specify the semantics and the behavior


1 In OSGi environment, the term 'bundle' is used instead of the 'application'









of a service. The interface also hides the implementation details of the service. Service

implementation, which is also called as service object, is a Java TM object of a class that

implements the service interface. It has to be noted that in a typical scenario, there can be

many service implementations for a single service interface. Such a scenario exists when

different vendors provide the same service or if there are many flavors of the same

service. For example, a service to control a particular device, say a camera, has a

standardized service interface but depending on the model and make of the camera, the

service implementations might vary.

3.2.1 Service Properties

According to OSGi specification every service is associated with a Properties

object2, which is a collection of (property name, value) pairs. The developer of the

service normally defines its properties. Properties provide an information database on top

of which, as we shall see in later sections, powerful service lookup mechanisms can be

implemented.

In addition to the properties defined by the service developer, OSGi specification

requires every service to have three mandatory properties, which are objectClass,

service.description and service.id. OSGi framework assigns the value for service.id

property automatically.

As an example, see Table 3.1 to see a list of properties that can be defined for a

dictionary service.






2 'Properties' is a standard class defined injava.util package. It represents a collection of (property name,
value) pairs. Please refer to java API documentation for more details.









Table 3.1 Properties of an example dictionary service


Property name Value

objectClass edu.ufl.icta.Dictionary

service.description "Dictionary service by UFL"

service. id XYZ

Author "ICTA"

Version 1.1

SourceLanguage "English"

TargetLanguage "English"



3.2.1 Service Registration, Un-registration

When a bundle is started, it registers services with the framework service registry.

A registered service is available to other bundles under the control of framework.

The framework provides a powerful lookup mechanism by which bundles can

query for services and get their references. A registered service can be unregistered at

any time by the bundle that registered it. Whenever a bundle is stopped, the framework

automatically un-registers all the services registered by that bundle.

Details about service registration, un-registration and the interfaces provided by

the framework are explained in more detail in section 3.4.









3.3 Bundles

A bundle is a collection of services that are packaged in a well-defined fashion. It

acts as a means by which services are hooked on to the OSGi framework. This section

describes the structure of a bundle and its life cycle. The interaction of bundle with the

framework is described in section 3.4.

3.3.1 Bundle Format

Bundle is a JAR3 file containing class files corresponding to service interfaces

and implementations. Bundles also contain all the resource files like image files, HTML

files, data files, configuration files etc.

Every bundle should have a special class file that implements the standard

interface org.osgi.BundleActivator. The interface specifies two functions start and

stop which the framework calls when a bundle is installed. Normally, the code to

register services and get references to other services is written in the start() function.

Code to un-register the service, is written in the stop() function.

Details about registering, un-registering and getting reference to other services are

explained in section 3.4.2.

A file called Manifest specifies the organization of all the files within a bundle.

The bundle developer has to create a manifest file before packaging the bundle. The

format of manifest file is specified in OSGi Service platform release 2 [OSG01].

Figure 3.2 shows the anatomy of a bundle


3 Java Archive, JAR format is a standard format defined by Sun Microsystems
































Figure 3.2: Anatomy of a bundle


3.3.2 Bundle Life Cycle

Unlike other archive files, bundle has different states. A bundle can be in one of

the following states: Installed, uninstalled, starting, stopping, resolved and active.

Services contained within a bundle can be available only if the bundle is in active

state. Figure 3.3 shows the state transition diagram of a bundle. In figure 3.3, the thick

arrow lines represent the transitions triggered by the framework and the dotted arrows

represent automatic transitions.

The bundles life cycle is explained in more detail in section 3.4.3.


Manifest File





Bundle
Activator










Install


Start

Starting Stopping
Uninstalled tar
Stop


Active





Transition by administrative action
----------- Automatic transition

Figure 3.3: Bundle state transition diagram

3.4 OSGi Framework

Framework is the heart of OSGi specification. It provides a common ground on

which bundles execute. Framework provides the following functionalities:

Resolves interdependencies among bundles and makes it possible to share classes
and resources among bundles.

Maintains a registry of services and provides APIs to register, un-register and
lookup services.

Manages life-cycle of a bundle

Provides a basic evening mechanism to raise events whenever the state of a
bundle, service or the framework changes

Implements a device access manager that helps in attaching device services to
driver services. This is a part of device access specification which a part of OSGi.
Device access specification is explained in detail in section 3.5.









3.4.1 Interdependencies among Bundles: Exporting and Importing Packages

As we have seen earlier, a bundle contains all the class files corresponding to the

services and the resource files required by those services. However, bundles are not

entirely self-sufficient. A service might use some packages that are defined in some other

bundle. In such a case, the bundle needs to inform to framework, the list of all packages it

wishes to import. Similarly a bundle might choose to export some of its packages so that

other bundles might import them.

Information about the packages that a bundle wishes to export or import is

specified in the bundle's Manifest file. When bundles export packages, they are

effectively exporting them to the framework. Similarly, when bundles import packages,

they are effectively importing them from framework. The scenario is illustrated in figure

3.4.


Bundle 1 Bundle 2

Manifest 1 Manifest 1

(Activator2 ( Activator 2


Package Package A


Export Import

Framework Package Framework Package
a iewo CPackage a'Package


(a) Bundle 1 exports Package A to (b) Bundle 2 imports Package A
framework from framework
Figure 3.4: Exporting and importing packages using OSGi framework









3.4.2 APIs to Register, Un-register and Lookup Services

The design philosophy behind OSGi specification is to allow different services to

be shared between different applications. For example, a dictionary service may be

shared by a word processor service and an English language tutor service. To make such

a scenario possible, OSGi requires every bundle to register the services it wishes to share

with other bundles4. A service can be unregistered when a bundle no longer wishes to

share the service.

The framework maintains a service registry having information about all services

registered. It is a structure that maps the type and properties of the service (specified in

"Properties" object), to the service object. A reference to the service object is added to

the registry when a service is registered. Whenever a service is unregistered, the

corresponding entry is removed.

As it was mentioned in section 3.2, every service has an associated "Properties"

object that contains the service properties. The framework uses this feature to implement

a powerful look up mechanism. To use a service, its reference needs to be obtained from

the registry. The look up mechanism provided by the framework helps in searching for

services by specifying filters, and obtaining the reference to the service object.

3.4.3 Bundle Life Cycle

The framework is responsible for managing the bundle's life cycle, which is

shown in Figure 3.3. When a bundle is installed, the state of the bundle is INSTALLED.

The framework takes the responsibility of loading all the class files and the

resource files packaged in the bundle. In the process of loading, it reads the bundle's


4 Bundles that do not register any service all called library bundles









manifest file to note the packages exported and imported. This process is called

resolution. Upon successful resolution, the state of the bundle is changed to RESOLVED.

In case of any errors in resolution, the state of the bundle still remains INSTALLED.

Framework provides mechanism to start, stop, update and uninstall a bundle. A

bundle can be started only if it is in RESOLVED state and can be stopped only if is in

ACTIVE state. When prompted to start a bundle, the framework calls the start() method

in the bundle's BundleActivator class (Framework gets the information about the

BundleActivator class from the Manifest file). Upon successful return form start(

function, the bundle's state is changed to ACTIVE.

When prompted to stop the bundle, the framework calls the stop() function in the

bundle's activator. Upon successful return, the bundle's state is changed to RESOLVED.

When the framework is prompted to update a bundle, the entire process is

repeated i.e., the bundle is reinstalled and after successful resolution, it is started (by

calling the start( function).

An important point worth mentioning here is that even after a bundle is

uninstalled, the packages that it exported still continue to exist on the framework.

Similarly even after a bundle is updated, the older version of the packages it exported

exist instead of the newer versions. To reflect the changes in the exported packages, the

framework has to be restarted.

3.4.4 Basic Eventing

Framework provides basic evening mechanism to signal the changes in the

internal states of the services, bundles and the framework itself









Bundle events are generated whenever a bundle is installed, started, stopped,

updated or uninstalled. Service events are generated whenever a service is registered or

un-registered and framework events are generated when the framework is started or if

there is an internal error.

OSGi clearly defines the interfaces for the listeners of these events [OSG01].

It can be noted that the evening facility provided by OSGi is very basic and does

not provide any generic infrastructure to exchange events between services. A generic

evening model to accomplish this task has been developed as a part of this thesis.

3.5 DAS: Device Access Specification

OSGi Device Access Specification, DAS, was developed to address the needs of

those applications that involve communication and controlling of devices.

Before defining what DAS is, it is essential to clarify some of the common

misconceptions about DAS and define what drivers and devices mean in the context of

DAS.

DAS is not about writing low-level device drivers. Such device drivers are

usually a part of the operating system and serve as the bridge between software and

hardware. In DAS terminology, they are called base drivers. It should also be clarified

that DAS is not about device/service discovery. There are several protocols like UPnP,

Jini etc that deal with service/device discovery. DAS is unbiased towards any service

discovery protocol.

Drivers, in the context of DAS are called driver services and they refer to

software services that execute on OSGi platform and communicate with the underlying

base drivers to control the devices. Similarly devices, in the context of DAS refer to









device services which are OSGi services providing an abstract view of the actual physical

device.

With that background, one can define DAS as the specification that supports

automatic detection of device services and defines a mechanism to automatically

download and install the appropriate driver services. The process of associating a device

service with the appropriate driver services is called attaching.

DAS consists of the following main components

1. Device service

2. Driver service

3. Driver locator

4. Device manager

3.5.1 Device Service

A device service is an abstract view of a device. Device service normally

represents a hardware device, but that is not a requirement. There can be a single device

service to represent a group of hardware devices, or there can be a device service

providing an abstract view of an entire network etc.

All device services in OSGi must extend the standard generic device class

org.osgi.service.device.Device defined by DAS. When a device service is registered with

the framework, the device manager is responsible for finding a suitable driver service and

attaching it. The mechanism by which the device manager searches for driver services is

explained in section 3.5.4.

A device service that is not used by any other bundle is called an idle device


service.









3.5.2 Driver Service

A driver service is an OSGi service that takes care of communication and

controlling of a physical device. Depending on the functionality, driver services are

classified into different categories. A detailed taxonomy of driver services is given in

OSGi Service platform specification 2 [OSG01].

All driver services in OSGi must implement the org.osgi.service.device.Driver

interface, which specifies two methods match( and attach(. These methods are called by

the device manager, which is explained in more detail in section 3.5.4.

When a device service is registered with the framework, the device manager

queries all the driver services by calling their match( method and passing the device

service's reference as a parameter. In the match( method, a driver service checks if it can

be used for the device service passed as an argument. The method returns a value

indicating whether or not the driver service can be used. This process is called refining.

The implementation details and the return value of the function match( are not

specified by the DAS, as they are highly dependent on the type of device and driver.

The attach( method of a driver service is called by the device manager if it wants

to attach a particular device service to that driver service. The reference to the device

service is passed as an argument method.

Since the actual method of attaching is highly device specific, the device manager

delegates that responsibility to the driver service i.e., by calling its attach() method.

Again, DAS does not specify any mechanism for device attachment process.









3.5.3 Driver Locator

Driver locators are special services that are called by the device manager to help

locate driver services for a particular device service. The function of a driver locator

service, as the name itself implies, is to search for suitable drivers and install the drivers5

when asked by the device manager. All driver locator service should implement the

standard interface org.osgi.service.device.DriverLocator. The interface specifies two

methods findDrivers( and loadDriver(. The method findDriverso is called by the device

manager if it wants the device locator to search for drivers and loadDrivero is called by

the device manager, whenever it wants the locator to install a particular driver service.

The mechanism used by the driver locator services to search for drivers is not

specified by DAS.

3.5.4 Device Manager

Device manager is the heart of DAS as it coordinates the actions of device services,

driver services and the driver locator services. It is responsible for finding suitable driver

services for every device service registered with the framework. The device manager

accomplishes this task by following these steps

1. It monitors the framework for new device service registrations

2. If a new device service is registered, it asks all available driver locator services
for find drivers by calling their findDriverso method. It then asks the driver
locators to install those driver services by calling their loadDrivero method.

3. The device manager then queries all the driver services (which might also include
the newly installed drivers by driver locators) by calling their match( method, to
see if they can refine the service.


5 Installing drivers refers to installing the driver bundle and registering the driver service









4. Of the replies, the device manager selects the best driver6 and instructs that driver
to attach to the device service. This is done by calling the attach( method.

This entire process is illustrated in figure 3.5


(b)


Framework DL 1 DL2


S S

DVSH


(d)


Legend (a) New device service S is registered and DM
DM : Device Manager queries all the DLs to find drivers for sl. DL1
DL : Driver Locator does not know about any driver, but DL2 knows
D : Driver Service about a driver D3.
S : Device service (b) DM asks DL2 to download and install D3. DL2
installs D3
(c) DM queries all the drivers to match the device
service. D2 gives the best response.
Figure 3.5: Example of Device manager operation [CHE02]


6 To select the best driver service, the device manager consults a special module called Driver Selector.
This module is not specified separately as it is considered a part of device manager.


Framework DL1 DL2


O D3
MatchD
DM D2
DM ~-' ~ D


(a)


(c)















CHAPTER 4
SOFTWARE INFRASTRUCTURE

This chapter discusses the design of event broker, controller and device services,

which are the three main components developed as a part of the software infrastructure.

These components are developed as software bundles on OSGi.

Event broker provides a means for services to cooperate by exchanging software

events. This component is generic and is not biased towards any particular class of

applications. The remaining two components i.e., controller and the device services, are

developed for applications that control X10 devices in a smart home.

Controller component takes care of communication with the X10 controller

hardware and the device services component is responsible for registering device

services1. These device services act as software proxy objects to the actual physical

devices and provide software APIs for controlling the devices. In this thesis, two device

services are developed: one for lamp and the other for any other electrical appliance. The

implementation details of these three components are given in the next chapter. The

interaction between them is shown in figure 4.1

To demonstrate the capabilities of this infrastructure, two demo applications are

developed. The design and implementation details of these applications are presented in

chapter 6.




1 Recall that a device service presents an abstract view of the physical device. See section 3.5.1 for more
detailed explanation.




















Software
A

Hardware Serial port



Power line






Devices attached to power line

Figure 4.1: Components and their interaction in the software infrastructure

4.1 Event Broker

This component is developed to allow different services on OSGi platform to

communicate using events. As it was seen section 3.4.4, OSGi provides basic event

facility and has no infrastructure for customized events. All the applications interested in

a particular event must register with the event broker. In order to register, the application

must provide the event broker with the event name and a listener function2. This

registration process is called subscribing.


2 Listener functions are also called call-back functions









Similarly, when an application is no loner interested in a particular event, it can

un-register its listener function from the event broker. This process is called un-

subscribing.

Whenever a service generates an event, it has to inform the event broker by

passing an event object. The process of informing an event occurrence is called signaling.

On receiving an event, the event broker invokes the listener functions of all applications

that subscribed to that particular event. The process of invoking is called dispatching.

The event object is passed to all listener objects while dispatching. Every event object

contains the event name, event source, event properties and any other event-specific

information.

The event broker component defines a standard interface, which every listener

function should implement. Similarly the event broker also standardizes the event object

that is passed between event source and the destinations. The structure of listener and the

event object are explained in more detail in section 5.1.


Listener n


Figure 4.2: Table entry structure









When a service starts, it has to inform the event broker about all events that it

might generate during the course of its execution. This process is called publishing the

events. When all services publish their events, it helps the event broker to provide APIs

that would list all the events that are currently available for subscription.

The event broker maintains all the information in a hash table, which is indexed

by the event names. Each entry in the table has two fields, the event name and the list of

listeners that subscribed to that event. The structure of the table entry is shown in figure

4.2. When a service publishes its event, an entry with the event name and an empty

listeners list is created. When an application subscribes to an event, its listener is added to

the list of listeners maintained for that event in the table. When an event is signaled, the

event broker gets the list of listeners for that event and invokes each one of them.

4.2 Design of Controller

Controller component is designed to interact with the X10 controller device. As

mentioned in section 2.2, there are many types of X10 controllers available depending on

the type of user interface required. For this software infrastructure, the Tw523 controller

is chosen. Tw523 has an interface to connect it to the computer's serial port. The

connection details are explained in section 5.2.The main goal of the controller component

is to provide a software interface to applications that wish to communicate with Tw523

interface. It is designed to automatically detect whenever a Tw523 X10 controller is

plugged to the computer serial port and to create and register Tw523 software service

with the OSGi framework. The controller component also detects whenever the Tw523

X10 controller is unplugged and it automatically de-registers the Tw523 software service.

The design details are explained in more detail in the next three subsections.









The component comprises of the following three software modules

1. Serial port scanner

2. Serial port listener

3. Tw523 software interface

Since the controller component is packaged as an OSGi bundle, it is started and

stopped through the interface provided by the OSGi framework.

4.2.1 Serial Port Scanner

This module is the entry point of the controller component. It begins execution

immediately after the controller component is installed and started. The serial port

scanner scans for all the available serial ports on the computer. If a serial port is

available, it opens the port, sets the serial communication parameters3 and finally creates

a serial port listener module for that serial port. There are as many serial port listener

modules as the number of serial ports. When the controller component is stopped, the

serial port scanner closes all the serial ports that it opened and also stops the serial port

listener modules that it created.

4.2.2 Serial Port Listener

The serial port listener module is responsible to identify if a Tw523 controller is

plugged to (or unplugged from) the serial port. It is also responsible for registering and

un-registering the Tw523 software service. It has to be noted that the serial port scanner

module does the association between serial port listener and the serial port.

When the serial port listener module is created, it listens to all events generated

by the serial port to which it is associated.










The serial port raises a "CTS true" event whenever a device is plugged to it. On

listening to this event, the serial port listener checks if the plugged device is a Tw523

controller. If it is Tw523, the serial port listener creates a Tw523 service and registers it

with the OSGi framework. Similarly, when a device is unplugged from the serial port, it

generates a "CTS false" event. On listening to this event, the serial port listener un-

registers the Tw523 service, if it exists. Note that the serial port listener need not check if

the unplugged device is a Tw523. This is because, if Tw523 service exists, then the

device plugged to the serial port has to be Tw523. Apart from registering and un-

registering Tw523 software service, the serial port listener module also publishes two

events namely Tw523 plugged and Tw523 inphlugged to the event broker.



Serial port listener listens to all events raised by the serial port if is connected to and creates "Tw523 driver
service" if Tw523 controller is plugged to the serial port.


Serial Serial Serial
Port Port Port
listener 1 listener 2 listener N ,--
S Serial port scanner\
---- --------
-- ---------- ---
S.-----.. Create

Serial port I
events A Scan
----

Ia ..

Serial port 1 Serial port 2 Serial port N



Figure 4.3: Serial port listener and Serial port scanner modules




3 Serial port parameters required for communication with Tw523 are (Baud rate: 1200, Data bits: 8, Parity:
None, Stop bits: 1)









Figure 4.3 shows the interaction between serial port scanner, serial port listener and the

serial port.

4.2.3 Tw523 Software Interface

Tw523 software interface module is the heart of the controller component as it

provides a software abstraction to the hardware Tw523 device. The module provides a

software interface for all applications that wish to communicate to Tw523 device.

The module also senses the power line for any signals generated by X10 devices.

If any signal is found, it generates a special event and publishes that event to the evening

broker. This feature is used in the demo applications developed as a part of this thesis.


API to applications


Communication wi-th
Tw523 hardware


Listen to signals on.
power line


Figure 4.4: Tw523 software interface module



The type of X10 signals and the type of events published by the Tw523 service is

explained in more in chapter 6.









Tw523 software module comprises of the following two sub-modules:

Tw523 device service

Tw523 listener service

Tw523 device service provides APIs to send commands to the Tw523 hardware

device. Tw523 listener service listens to X10 signals on the power line and publishes

events with the event broker, whenever a signal is found. Since event broker is a service

outside the scope of the controller component, the Tw523 listener service is robustly

designed to publish events only if the event broker service is available.

4.3 Device Services

This purpose of device services component is to create device services, which

provide software APIs to applications that wish to control devices in a smart home. As it

can be seen from figure 4.1, this has a dependency on event broker and controller

components.

Both device service and controller components are developed for the class of

applications that wish to control X10 devices in a smart home. The reason for separating

these two is to for scalability and extensibility. The device services component can work

with any controller component as long as the interface provided by the latter remains

unchanged.

This component can be divided into two modules

1. Device service initiator

2. Device services

The component is packaged as an OSGi bundle and is started and stopped using

the interface provided by the OSGi framework.










4.3.1 Device Service Initiator

The purpose of this module is to read a configuration file containing the list of all

X10 devices currently present in the smart home and to create device services

corresponding to those devices.

Since X10 technology provides no mechanism for device discovery, providing a

configuration file is the only way of conveying the X10 device information and the smart

home layout. Each line in the configuration file conveys information about a particular

X10 device and has information about the device's properties. The properties are the

device's X10 address, location, device type and other device-specific properties. The

format of the configuration file is explained in more detail in section 5.3.


Confirmation file Device services component
Configuration file
Device 1 -- --
Device 2 -- --
Device Service
initiator
Device N -- ---






Device 1 Device 2 Device N
service service service

- - - - - - - - - -


To controller component

Figure 4.5: Device services component









The device service initiator module reads each line in this configuration file,

creates properties object (see section 3.2.1), creates a device service object

corresponding to the device type and finally registers the device service with its

properties. It has to be noted that each device service represents a single device. So the

number of device services created by the device service initiator is equal to the number of

entries in the configuration file i.e., the number of controllable X10 devices in the smart

home. Figure 4.4 shows the overall design of device services component.

4.3.2 Device Services

As mentioned in section 3.5.1, device services provide an abstract view of a device. In

this thesis, device services for two classes of devices have been developed: one for lamp

and the other for low power electrical appliances.

The device services publish events to the event broker and are designed to publish

events only if the event broker service is available.

4.3.2.1 Lamp Device Service

This service provides APIs to turn the lamp on, off and to get the lamp's status.

Apart from these, it also publishes events to the event broker whenever the lamp if turned

on or off.

4.3.2.2 Appliance Device Service

This service is similar to lamp service and provides APIs to turn the appliance on,

off and to get the appliance's status. It also publishes "appliance on" and "appliance off'

to the event broker. The implementation details and the interface definitions of these

device services are given in the next chapter.













CHAPTER 5
IMPLEMENTATION

This chapter discusses the implementation details of event broker, controller and

device services components. The entire implementation is done in JavaTM programming

language and the components are packaged into the following three OSGi bundles:

1. osgiEvent.jar (Event Broker component)

2. osgiDevice.jar (Device services component)

3. osgiTw523.jar (Controller component)


eri



osgi


tw523

service
impl


Controller


Figure 5.1: Package tree of the software infrastructure






42

The anatomy of a typical OSGi bundle is explained in section 3.3.1. The software

infrastructure package tree is shown in figure 5.1. As it can be seen, both the controller

and device services components share the package edu.ufl.osgiX]O.constants.

The next three sections discuss the implementation details of the three

components in detail. Two applications are developed to demonstrate the utility of this

infrastructure and these are discussed in chapter 6.

5.1 Event Broker

In this section, the package structure of event broker, which is shown in figure

5.1, is explained. As it can be seen from figure 5.1, all the classes in this component are

under edu.ufl.osgiEvent package.

5.1.1 Package Details

edu. ufl. osiEvent.genericEventListener

As explained in section 4.1, every application interested in a particular event,

needs to subscribe to the event broker with the event name and a listener object. This

package defines a standard listener interface called GenericEventListener. The event

broker accepts only the listener objects that implement this listener interface. The

interface defines just one method called handleEventO. The event broker calls this

method while dispatching events. The method handleEventO, expects the event

information in an object of type GenericEvent. While dispatching events, the event

broker creates a new thread of execution on each listener object.

edu. ufl. osiEvent. GenericEvent

The information about any event is passed in the form of an event object. When

an event source generates an event, it signals the event broker by passing the event

information in the form of an event object.






43

The event broker dispatches the event by passing the same event object to all

subscribed listeners. All the event objects should be of type GenericEvent or its derived

classes.

edu. ufl. osgiEvent. eventBroker. service

This package has the interface definition of the event broker service. The

interface is named EventBroker.

edu. ufl. osgiEvent. eventBroker. implementation

This package has the implementation of event broker service i.e., it has a class

called EventBrokerlmpl, which implements the EventBroker interface.

edu. ufl. osiEvent. eventBroker. utils

This package has event table data structures used by the event broker

implementation class.



Manifest File

Export-list
osgiEvent.eventBroker. service
osgiEvent.genericEventListener
osgiEvent.genericEvent




EventActivator


Figure 5.2: Structure of osgiEvent.jar








5.1.2 Bundle Structure

The bundle is named as osgiEvent.jar. The structure of the bundle is shown in

figure 5.2. As it can be seen, the bundle exports the event broker interface, generic

listener and the object classes.

5.2 Controller Component

The classes in this component are packaged in edu.ufl.osgiX10. Tw523 as shown

in figure 5.1. This component has the classes that implement a driver service for the

Tw523 X10 controller. In this section, the connection details of TW523, the package

details and the structure of this component's bundle are explained

5.2.1 Connecting Tw523 to Computer's Serial Port

Tw523 controller comes with two interfaces: RJ11 and a power line socket

interface. Since RJ11 interface cannot be directly connected to the computer's serial port,

the scheme shown in figure 5.3 is used for connections.




ST\\ 0-\ A T 523




Serial Pot DB9-RS232 Converter
Serial Port
----- RJ11 cable



Figure 5.3: Connection details of Tw523



A device, called TWO-WAY, is acts as a RJ11 to DB9 converter. Apart from that,

TWO-WAY also accepts inputs from serial port in the form of ASCII text, buffers them

and communicates with TW523 taking care of all timing details.






45

Use of TWO-WAY greatly simplifies the task of developing a driver for

Tw523.The DB9 interface of TWO-WAY is connected to the serial port using a

DB9/RS232 converter.

5.2.2 Package Details

edu. ufl. osg iX 0. constants

This package defines all the constants that are used by X10 applications. The

device properties, device types, event names and event types are defined.

edu. ufl. osgiX 0. Tw523. service

This package defines the standard Tw523 device service interface. The interface

is named Tw523.

edu. ufl. osgiX 0. Tw523. implementation

This package has a class Tw523Impl that implements the Tw523 interface. This is

the core class implementing the driver service for Tw523 device. This class corresponds

to the Tw523 software service component explained in section 4.2.3

edu. ufl.osgiX10. Tw523

This package has two classes Tw523Activator and SerialListener, which,

correspond to the serial port scanner and serial port listener components explained in

sections 4.2.1 and 4.2.2 respectively.

5.2.3 Bundle Structure

The bundle is named as osgiTw523.jar. As it can be seen from figure 5.4, this

bundle exports the Tw523 interface and the constants package. Since the classes in this

component use the event broker, this bundle imports the event broker packages.












Manifest File

Export-list
osgiX10.tw523.service
osgiX10.constants

Import-list
osgiEvent.eventBroker.service
osgiEvent.genericEventListener
osgiEvent.genericEvent





Tw523Activator





Resources

Class Files






Figure 5.4: Structure of osgiTw523.jar

5.3 Device Services Component

The classes in this component are packaged in edu.ufl.osgiX0O.device and

edu.ufl.osgiX1O.constants packages. The design details are given in section 4.3.

This component registers device services for all devices in a smart home

environment. The information about the devices is initially obtained from a configuration

file named XlOMapfile.conf.

Device services for lamp and small electrical appliance are developed as a part of

this thesis. In this section, the standard properties defined by this component and the






47

configuration file is explained in detail followed by a brief description of packages and

bundle structure.

5.3.1 Standard Device Properties Defined in this Component

In section 3.2.1 it was seen that every OSGi service should have some properties

associated with it and that these properties help other applications to search for services

based on these properties. Since this component creates device services, it should also

associate them with some properties. Device services component defines a standard set of

properties for every smart home device. These properties are shown in table 5.1.




Table 5.1 Standard properties of devices in smart home


Property Name Explanation

X10 ADDRESS The device X10 address

ROOM_NUMBER The room number in which the device is present.

FLOOR_NUMBER The floor number in which the device is present

DEVICE NUMBER The device number

DEVICETYPE The type of the device as defined in

efu.ufl.osgiX 10.contants.DeviceType package


For example, the property 5-tuple , conveys the following

information:







48

1. It represents an X10 device with address "A10".

2. The device is located in room number 2, first floor.

3. The device is a lamp, since the device type is 1 (device types are defined in
edu.ufl.osgiXl0.constants package).

4. The device is the second lamp in the room, since the device number is 2.

It has to be noted that, in addition to the properties listed in table 5.1, the device

services may have other properties defined by the user.

5.3.2 X1OMapfile.conf Structure

The configuration file is a text file where each line represents the properties of a

particular device. The format of each line is shown in figure 5.5




[ ... ]


Note:


: X10 Address
: Room Number
: Floor Number
:Device


1. The fields are separated by delimiters which can be one of these
<,;: \t> If there is no value for the field a "*" has to be entered

2. First five tokens represent the mandatory properties. Hence the
property name is not specified (the property names are implicit)

3. The subsequent tokens should be present in (property name,
property value) pairs.

4. Device type is according to the values defined in the package
S. i, l .. .. !0.constants.DeviceTypes


Figure 5.5: X10Mapfile. conf file structure










1 All the rooms in a smart home should be logically numbered. Similarly all devices in a room should also
be logically numbered.


Legend:

X10
RN
FN
DN
Number








5.3.3 Package Details

edu. ufl. osgiX 0. device

This package has the class DeviceActivator that corresponds to the device service

initiator module described in section 4.3.1. It reads XO1Mapfile.conf file and creates the

device services.

edu. ufl. osgiX 0. device. utils

This package has a utility class called MapfileLoader that is used to parse the

configuration file i.e., XlOMapfile.conf file. MapfileLoader has a method called

loadMapfileO that reads the configuration file and returns a hash table containing the

device X10 address and properties.

edu. ufl. osgiX 0. device, service

This package defines the interfaces of lamp and general electrical appliance

devices.

edu. uf. osgiX] 0. device, imply

This package defines the classes that implement the device interfaces defined in

the edu. ufl. osgiX 0. device.service package.

5.3.4 Bundle Structure

The bundle containing the device services component is named osgiDevice.jar

Since the device services component uses both the evening module and the

controller module, it imports those packages. The bundle exports the device service

package.


The structure of osgiDevice.jar is shown in figure 5.6.







50






Manifest File


Export-list
osgiX10.device.service
osgiXI0.device.utils
osgiXl0.constants
Import-list
osgiEvent.eventBroker. service
osgiEvent.genericEventListener
osgiEvent.genericEvent
osgiX10.tw523.service






S DeviceActivator


Figure 5.6: Structure of osgiDevice.jar















CHAPTER 6
APPLICATIONS USING THE SOFTWARE INFRASTRUCTURE

The advantages of software infrastructure that was explained in chapters 4 and 5

are more evident by considering the applications that are built on the infrastructure.

In this chapter, two such applications developed as a part of this thesis are

explained. One of these applications, named Magic Wand, is developed for cell phones

and the other application, named Smart App is for desktops. Both the applications allow

the user to remotely control the devices in a smart home. It has to be noted that these

applications are developed for demonstration purposes only.

6.1. Design of "Smart App"

Smart App is designed for desktops and it provides a way to remotely control the

devices. Figure 6.1 illustrates the design of the application.

6.1.1 Server Side Component of SmartApp

The server side component of Smart App is called main proxy and it executes on

OSGi framework. Main proxy reads the X1Omapfile.conf1 file, creates proxy device

services2 for each device, and creates a table indexed by the devices' X10 addresses. The

proxy device services created by main proxy, search for the corresponding device

services and associate with them.

The devices that can be controlled using Smart app are lamp and radio.



1 Structure of XO1Mapfile.conf is explained in section 5.3.2
2 The design and implementation of device services component was already explained in sections 4.3 and
5.3









Requests from client side of Smart App are of the following three types.

1. To get a list of all devices in smart home and their properties (see table 5.1)

2. To control a device

3. To register for events


OSGi Framework
OSGi Framework


Client Server


Internet


Figure 6.1: Architecture of Smart App


Request to get a list of all devices is received by main proxy just once i.e., when

the proxy starts. All other requests to control a device or to register for an event have two

fields. The first field has the X10 address of the device to be controlled, second field has

the appropriate function code and the third field has the function specific data.

When main proxy receives such request packets, it looks at the X10 address field,

consults its table to find the corresponding device proxy and forwards the request packet

to it. The request is then handled accordingly. Events are discussed in section 6.3.










6.1.2 Client Side Component of SmartApp

The client side component is designed to execute on any remote computer and it

provides a nice graphical user interface (GUI) to control the devices. The screen shot of

the GUI is shown in figure 6.2.


(~nnl ml Fwl 'il


Figure 6.2: Smart App GUI

6.2. Design of Magic Wand

Magic Wand is an application designed to control devices in a smart home using

Motorola iDEN phones. Magic Wand is designed using client-server architecture. The

server component executes on the OSGi framework while the client component executes

on Motorola iDEN phones. Magic wand application is a simple application and controls

only two lamps and a radio.









6.2.1 Server Side Component of Magic Wand

When the server side component of Magic Wand is started, it searches the OSGi

framework and gets references to device services (two lamps and a radio). The

component also registers for new mail and system critical events, which are explained in

section 6.3.

6.2.2 Client Side Component of Magic Wand

The client component is designed for Motorola iDEN phones and it provides

graphical user interface. Figure 6.3 shows screen shots of the interface.






























Figure 6.3: Magic Wand GUI









6.3. Events

Though Magic Wand and Smart App are developed as two independent

applications, they control the same set of devices. This is made possible by the software

infrastructure.

The advantages of software infrastructure become more evident when the events

are considered. The event broker, which is a part of the infrastructure, allows different

applications to communicate using events. To demonstrate this feature, the following

events are defined

Lamp On event: Generated by the lamp device service when the lamp is
turned on

Lamp Off event: Generated by the lamp device service when a lamp is turned
off

Appliance On event: Generated by the appliance device service when the
appliance turned on

Appliance Off event: Generated by the appliance device service when the
appliance turned off

System Critical event: Generated when Tw523 controller is plugged out or
plugged into the serial port. This event is generated by the serial port
component explained in section 4.2.2

New mail event: Generated when a new mail is kept in the mailbox. This
event is generated by the Tw523 software interface component that was
explained in section 4.2.3

Someone at door event: Generated when someone rings the door bell. This
event is generated by the Tw523 software interface component that was
explained in section 4.2.3

By default Magic wand is registered to New mail, Someone at door and System

critical events. Smart app provides interface that displays a list of all events available and

lets user choose the events to subscribe/unsubscribe to. The screen shot shown in figure

6.2 shows this event browser interface.









It can be seen that when the lamp or appliance is turned on/off using Magic

Wand, the events can be seen on Smart App. Similarly when New mail, Someone at door

and System critical events are generated, both Smart App and Magic Wand receive the

notifications. Figure 6.4 shows the screen shots of the critical event when Tw523

controller is unplugged.



Tw532 is UiilllhilTjeil!



(a) Alert message displayed on Smart App GUI when TW523 controller is unplugged on the home gateway


(b) Alert message displayed on Magic Wand GUI when TW523 controller is unplugged on the home


Figure 6.4: Critical events on Smart App and Magic Wand














CHAPTER 7
CONCLUSION AND FUTURE WORK

The previous chapters explained in detail, the motivation behind this thesis, the

proposed software infrastructure and also the applications developed to demonstrate its

benefits. This chapter summarizes the achievements of this thesis and concludes with a

note on future work that can be done to improve it.

7.1. Achievements and Contributions of this Thesis

This thesis is a modest attempt to capture the essence of application development

for smart homes. The major achievement is the software infrastructure it proposes.

Though all the components (excluding the event broker) in the infrastructure are

developed for X10 technology, the infrastructure essentially suggests a component-based

model for application development. The event broker model that is developed provides a

simple and elegant way for different applications to coexist and co-operate. The choice of

OSGi was obvious as the standard was developed with a similar philosophy to provide

generic framework for application development.

The following are the major contributions made by this thesis

1. Generic event broker component

2. APIs to generate complex events

3. X10 driver to communicate with TW523 interface

4. Device service component to control devices

5. Standardized properties to be associated with every device service (see
table 5.1)









Other achievements include a detailed study on existing technologies like X10,

CEBus, Lonworks etc., and identifying X10 as the appropriate choice under the present

circumstances

7.2 Future Work

As it was said in the previous section, the main purpose of this thesis was to

propose a model that would make application development easy. The software

infrastructure developed in this thesis focused primarily on the class of applications to

control devices in smart homes. While the components are developed to provide a rich set

of APIs, there is still a lot of scope for future work. The following list proposes some

enhancements than can be done in future

Improving X10 modules: As it was mentioned in section 2.5.2, X10 modules
suffer form a lot of reliability issues. X10 provides no means to check if a
command was successfully executed or not. This feature can be improved
suggested in section 2.6.2. This change was proposed in Microsoft's
Aladdin project [WANOO].

Device discovery in X10: X10 modules provide no way to convey information
about the type of device plugged. This prevents any device and service
discovery mechanism to be implemented using X10. However, the work
around suggested by Microsoft's Aladdin project could be used. This
work around is explained in section 2.6.1.

Providing a generic "Serial port" device service: Any JavaTM based application
that communicates with the serial port uses the javax.comm. API to
communicate with the serial port. To use a serial port, the application has
to own the port, which prevents any other application from using the serial
port. For example, the Tw523 software interface module developed as a
part of this thesis owns all the serial ports and prevents any other
applications from using them. Developing a "serial port" device service
on OSGi can solve this. The service would own the port and cater to
multiple applications in an OSGi environment.

Event broker: The event broker can be made more robust by enabling it to
dispatch events even over the network. This requires defining APIs to
register remote listeners. RMI technology can be used to implement this
feature.






59


7.3 Conclusion

The range of applications that can be developed is infinite as it depends on ones

imagination and creativity. This is a first step in this direction and the author envisions

that the near future would see a gamut of applications to make our lives more pleasurable

and independent.













LIST OF REFERENCES


[CEBOO] CEBus, CEBus Industrial Council, http://www.cebus.org, 03/2002

[CHE02] Kirk Chen, Li Gong, Programming Open Service Gateways in ih Java
Embedded S.et vi Technology, Addison-Wesley, Boston, 2002

[EVA0 1] Gray Evans, CEBus Demystified: The ANSI/EIA 600 User Guide, McGraw
Hill, Columbus, 2001

[HOROO] Cay S. Horstmann, Gary Cornell, Core Java, Prentice Hall India, New
Delhi 2000

[KIN02] Phil Kingery, X1O-Technical Series,
http://www.hometoys.com/resources.htm, 03/2002

[OSGO1] OSGi, OSGi Service Platform: Release 2 Specification, October 2001
www.osgi.org, 04/2002

[SCH01] Herbert Schildt, JavaT Complete Reference, Tata McGraw Hill, New
Delhi, 2001

[WANOO] Yi-Min Wang, Wilf Russell, Anish Arora, A Toolkit for Building
Dependable and Extensible Home Networking Applications, USENIX
technical program, Winsys, August 2000,
http://www.usenix.ora/events/usenix-win2000/wan. html, 03/2002
















BIOGRAPHICAL SKETCH

Sree Charan Kuchibhotla was born on November 20th, 1976, in Visakhapatnam,

India. He received his bachelor's degree in engineering from Karnataka Regional

Engineering College, Surathkal, India, in June 1999. Soon after graduating, he worked

for IBM, India as a software developer until December 2000. His area of work in IBM

was on network security and network file systems.

He joined the University of Florida in January 2001, to pursue a master's degree

in computer and information sciences. He served as a teaching assistant for Mr. William

B. Noffsinger till May 2002.

Sree Charan became a part of Harris Communications laboratory in August 2001

and his major achievements include winning first place in Motorola killer app.

competitions in December 2001. He has a passion for new technology and his interests

are in the field of pervasive computing.

After graduation, Sree Charan will be moving to Madison, Wisconsin, where he

will be working as a full time software developer in EPIC systems corp.