Post on 17-Jan-2017
OCF & IoTivity for Healthcare/Fitness/Wearable
Jonghong JeonETRI, PEC
Email: hollobit@etri.re.kr
http://www.etri.re.kr
OCF�&�IOTIVITY
2
3
OCF�Basics• The�Open�Interconnect�Consortium�(OCF)�defines�a�
common�communication�framework�that�connects�and�intelligently�manages�the�flow�of�information�among�devices�to�address�the�emerging�needs�of�the�Internet�of�Things– Regardless�of�form�factor,�operating�system,�vertical�
market,�manufacturer�or�service�provider�
– Based�on�industry�standard�technologies
• OCF�certifies�products�for�interoperability�and�compliance�with�the�OCF�specifications
• OCF�sponsors�the IoTivity Project, an�open�source�reference�implementation�of�the�OCF�framework.
• OCF�promotes�the�goal�of�broad�interoperability�via�collaboration�with�other�organisations�and�standards
4
OCF�Goals• Make�it�easy�for�developers�to�deal�with�the�complexity�of�IoT comms– Provide�a�common�data�model�that�developers�can�use�to�interface�with�all�IoT devices�and�data
• Deliver�as�much�interoperability as�possible�in�the�short�term
• Provide�a�path�towards�future�consolidation• Supports�the�needs�of�multiple�vertical�markets�(since�many�use�cases�span�multiple�vertical�markets)
• Establish�an�architectural�foundation�that�can�achieve�the�necessary�scalability
5
OCF�&�IoTivity Structure
6
Board of Directors
Standards Work Group
Open Source Work Group
Planning / Marketing / Etc…
Specifications Certification
IoTivity Steering Group
Projects
Functions
Sponsored (funded) by OCFDevelops reference implementation
of the OCF specification
Coordination
Innovative coordination – Specs & Open Source ready simultaneously
Best�of�Both
7
•Necessary for some vertical markets• Simplest path to international standardisation•Allows liaisons with organisations that operate under NDA• Proven process to gain broad agreement on direction of new technology
• Fastest way to enable developers•Can contain more than just the specification (optional features, development tools, etc…)• Proven process to deliver innovation
Standards Open Source
OCF�&�IoTivity Governance• OCF�is�a�non-profit�entity�governed�by�its�own�bylaws– Board�of�Directors�has�fiduciary�responsibility�(financial,�legal,�etc…)
– Sets�up�Working�Groups�to�accomplish�OCF�goals
• IoTivity.org�is�a�project�hosted�by�the�Linux�Foundation– Independent�governance�and�infrastructure,�sponsored�(funded)�by�OCF
– Charter�to�provide�reference�implementation�of�OCF�standard�(but�not�limited�to�only�a�reference�implementation)
8
OCF�Organisational�Structure
9
Open SourceWork Group
StandardsWork Group
Board of Directors
Marketing Communications Work Group
Compliance & Conformance
Core
Security
Smart Home
Technology PlanningWork Group
MembershipWork Group
Industrial
New Items
PR
Branding
Liaisons
Discovery & Connectivity
Primitive Services
Project Planning & Requirements
Security
Health
Events
Ecosystem
Use Cases
oneM2M
UPnPWork Group
AV
IoT Data Modelling Tool
UPnP Certification
CertificationWork Group
RemoteAccess
DigitalMedia
IPR�Policy�- Royalty�Free*�Licenses
10
Apache v2.0Incoming:
Companies license their patent claims covering their code
Outgoing:All users (unless they sue another user for
patent infringement via IoTivity code)
RAND-Z(By default – RAND under some circumstances*)
Incoming:All members license their claims to IP
essential to implementing the specification
Outgoing:Compliant portion of certified products
Code�Related�Patent�License� Apache�v2.0
11
+
+
+
+
License
License
License
License
CODE
CODE
CODE
CODE
Developeror User
Patent license covers company’s code contributions
Spec-Related�Patent�License� RAND-Z
12
Member
Product
SPEC CertificationProgram
Compliant Portion
License
Patent license covers everything in specification
OCF�IPR�Scope
13
TECHNICAL�ARCHITECTURE
(COMMUNICATIONS)
14
The�challenge�of�IoT Communications
• Value�will�be�delivered�by�apps�&�services,�and…• Apps�&�services�need�access�to�data�&�control�points�to�deliver�that�value,�but…
• Developers�find�it�difficult�to�access�all�the�data�and�control�points
• Use�cases�are�more�complicated• The�system�and�therefore�comms needs�to�achieve�massive�scale
• The�solution�must�work�across�form�factors,�OSs,�platforms,�manufacturers,�service�providers�and�vertical�markets.
• The�solution�must�also�scale�from�constrained�devices�to�smart�devices�to�the�Cloud.
15
Scope of IoT
16
service #2domain
service #1domain
Local Control Remote Control Server to Server
IndustrialSmart Home Healthcare
SecurityDevice management
Group management
ProtocolBridge/GW
Messaging StreamingDiscovery
ID & Addressing
CRUDNCommonResource
Model
…
Wi-Fi BT/BLE Thread …
VerticalProfiles
Baseline Functionality
Connectivity
Controller
Controller
Cloud Servers Cloud Servers
Things
Controller AppCloud Interface
Controller
Comms Framework�- Simple�IoT Layers�Model
17
Transports Transports
Applications & Services
Comms Protocols
Profiles, Data &Resource Models
Data & Control Points
Comms Protocols
Profiles, Data &Resource Models
What to talk about and how to
describe it (which words in
what order –grammar &
spelling)Language
(French, Chinese, English)
Method of Communication(Letter, Phone, E-
Mail)
Example� Current�Consumer�Radio-Based�Standards
18
Applications & Services
Data & Control Points
Comms Protocols
Transports
Profiles, Data &Resource Models
Wi-F
i
ZigB
ee
Thre
ad
Z-W
ave
IP
802.
15.4
802.
15.4
IP
Blue
toot
h® L
ow E
nerg
y
??
BLE
IP
?
IP = 6LoWPAN
Exte
nsib
le
Example� Comms Frameworks�(Consumer)
19
Wi-F
i
BLE
OCF Comms Framework(Single Resource & Data
Model)
IP IPTh
rea
dIP
802.
15.4
Blue
toot
h® L
ow E
nerg
y
Applications & Services
Data & Control Points
Z-W
ave
ZigB
ee80
2.15
.4
TECHNICAL�ARCHITECTURE
(DEFINITION�OF�THING)
20
Definition�of�various�Things
21
e.g., Light bulb
BinarySwitch
Dimming
Brightness
- true(on), false(off)
- dimmingSetting (int)- step (int)- range [0-100]
- brightness (int)
Resources- properties
SetSwitch
SetDimmingLevel
SetBrightness
- Power(in)
- brightness (in)
- step(in), range(in)Functions
- Input & Output Parameters
• By defining resources of things and its properties
• By defining functions/operations of things
- (no Verbs) + Objects*Fixed set of verbs (CRUDN) from
transport layer will be used- Resource model in RESTful Architecture(e.g., W3C, CSEP, etc.)
- (Verbs + Objects)- RPC model
Support�of�Constrained�Things
• Less�overhead/�Less�Traffic– Minimize�CPU�Load,�Memory�impacts,�Traffic�and�Bandwidth
- Compact�header- Binary�protocol- Compressed�encoding�of�payload
• Low�Complexity
- Simple�Resource�Model�>�Short�URI�(Late�Binding�w/�resource�type�defined)>�Broad�and�Shallow�Hierarchy�
22
*RAM <10KB, Flash <100KB (RFC 7228)
TECHNICAL�ARCHITECTURE
(STANDARD�&�INTEROPERABILITY)
23
Interoperability�&�Certification
24
Prerequisites: Dependency Certification
(e.g. Connectivity)
Conformance Test
Interoperability Test
Certificate Issue& Logo LicensingDevice under Test
CERTIFIED
Mandatory(in spec, cert &
committed in Open Source Project)
Optional
OpenSourceFeatur
es
TestedOption
alOpen
SourceFeatur
es
TestedOption
alSpec
Features
Optional
SpecFeatur
es
SpecificationOpen Source
• Conformance test - Each device proves conformance to specifications• Interoperability test - Each device proves interoperability with other devices
• Certification Scope
OCF�Specification�Structure
25
Infrastructure• Core Framework• Security• Remote Access• Certification Test Plans and Test Cases
Resource Model• Resource Specification (Domain agnostic)
Per Vertical Domain• Device Specification• Domain Specific Resource Specification
OCF�Conceptual�Framework
26
DeviceProfiles
Smarthome Enterprise Industrial Automotive Education Health
TransportsLE
RemoteAccess Cloud
Core Framework
Security, Identity & Permissions
Discovery DataTransmission
DataManagement
DeviceManagement
Resource Model
Remote Access
OCF�Specification�1.0
27
OIC 1.0 세부 표준명 표준 설명 (작업그룹)
1 Core FrameworkOIC 프로파일이 동작될 수 있도록 하기 위한 핵심 구조, 인터페이스, 프로토콜과 서비스들을 정의 (SWG CFTG)
2 Resource Type스마트홈 리소스들에 대한 기본 스키마와 이를 기반으로확장된 다양한 리소스 집합들에 대해 정의 (smarthome TG)
3 Security상이한 암호화 능력을 갖는 장비들 사이에서 장치 구동과연결에 필요한 도구와 보안 자원 모델을 정의 (Security TG)
4 Smart Home Device스마트홈 응용 분야에서 사용되는 OIC 호환 장치 규격을 정의(smarthome TG)
5 Remote AccessXMPP와 같은 산업표준을 기반으로 원격 접속에 필요한 제반사항들과 기능들을 정의 (SWG RATG)
http://openconnectivity.org/resources/specifications
TECHNICAL�ARCHITECTURE
(CORE�FRAMEWORK)
28
OIC�Architecture
29
•OIC adopted RESTful Architecture•Current OIC Architecture defines 2 logical roles that devices can take
- OIC Server : A logical entity that exposes hosted resources- OIC Client : A logical entity that accesses resources on an OIC Server
OIC ClientOIC
ClientOIC
ServerOIC
Server
Model 1
RR
Organization�of�an�OIC�Device
30
•OIC Device concept
Physical Device e.g. light bulb
OIC Device 2OIC Device 1
/oic/p
/oic/res/oic/res
/oic/d/oic/d
/oic/prs/oic/mnt
Resource URI: /oic/pResource URI: /oic/prt: oic.wk.prt: oic.wk.p
if: oic.if.rif: oic.if.r
n: homePlatformn: homePlatform
policy: bm:11policy: bm:11
pi: at1908pi: at1908
mnmn: Samsungmnmn: Samsung
Mandatory
Optional
Device�example:�light�device�(oic.d.light)
31
• Example overview - Smart light device with i) binary switch & ii) brightness resource
• Device type: Light device (oic.d.light) [Defined by the domain]
• Associated resources - Core resources: ① oic/res, ② oic/d- Device specific resources: ③ Binary switch (oic.r.switch.binary), - Other optional resources can be exposed, in this example ④
Brightness resource (oic.r.light.brightness)
Device Title
Device Type Associated Resource Type M/O
Light oic.d.light
oic/res (oic.wk.core) Moic/d (oic.d.light) M
Binary switch (oic.r.switch.binary) MBrightness (oic.r.light.brightness) O
Example: Smart light device with 4 resources
oic/res oic/d Binary
switch Brightness
OIC�Spec�Features� Core�Framework�Spec
32
① Discovery: Common method for device discovery (IETF CoRE)
② Messaging: Constrained device support as default (IETF CoAP) as well as protocol translation via intermediaries
③ Common Resource Model: Real world entities defined as data models (resources)\
④ CRUDN: Simple Request/Response mechanism with Create, Retrieve, Update, Delete and Notify commands
⑤ Device Management: Network connection settings and remote monitoring/reset/reboot functions
⑥ ID & Addressing: OIC IDs and addressing for OIC entities (Devices, Clients, Servers, Resources)
⑦ Security: Basic security for network, access control based on resources, key management etcTransportNetworkingL2 Connectivity
Vertical Profiles
IndustrialInternetSmart Home …
OIC Core Framework
SecurityDevice management
Group management
ProtocolBridge/GW
Messaging StreamingDiscovery
ID & Addressing
CRUDNCommonResource
Model
① ②
③ ④ ⑤
⑥
⑦
Protocol�Stack
33
UDPUDP TCPTCP
IPv6IPv6
Resource ModelResource Model
DTLSDTLS TLSTLS
L2 Connectivity (Wi-Fi)L2 Connectivity (Wi-Fi)
Encoding (CBOR)Encoding (CBOR)
CoAPCoAP
Encoding JSON or XML/EXI can be negotiated
IP Version v6 (v4 supported forlegacy devices)
ApplicationApplication Alternatives
Project B OIC Stack
Encoding�Schemes� JSON,�XML/EXI,�CBOR
34
• OIC resource is represented as sequence of bits by encoding schemes when to transfer it over the network• OIC supports several encoding schemes and it will be negotiated
and accepted by OIC Server when OIC Client requests• OIC has mandated CBOR as the default encoding scheme
* JSON: JavaScript Object Notation, EXI: Efficient XML Interchange, CBOR: Concise Binary Object Representation
JSON XML/EXI CBOR
Description - Lightweight, text-based, language-independent data interchange format
- Binary compression standard for XML
- Concise binary object representation based on JSON data model
Standard IETF RFC 7159 W3C Efficient XML Interchange Format 1.0
IETF RFC 7049
Content Type /application/json /application/exi /application/cbor
OIC M/O Optional Optional Mandatory
OCF�HEALTHCARE
35
[참고]�국제표준화연관도
36
OICHealthcare
(Wearable/Fitness/Healthcare)
PHR
Healthcare(Continua,�ISO/IEC,�ISO/IEEE,�ITU-T,�PHA)
OIC�IoT
Medical,Wellness,Personal,Remote,
Smarthome
Industrial
Defining�OIC�Components�(on�top�of�CORE)
37
•OIC Servers• Defined by device identifier: standardized name of the
device• List of mandatory OIC resources per device • Note that OIC Clients are implicitly specified as
“opposite” side of an OIC Server. • Currently OIC does not impose interaction sequences.• All Resources are allowed to talk to/from any OIC Client at any
point in time
•OIC Resource• Defined by resource identifier: standardized name of the
resource• List of mandatory properties per resource• List of allowed actions (read/readwrite/..) per resource
Specifications
38
• Specifications are split in 2 documents:• Device specification• Resource specification
The Device specification uses the resources definedin the resource specification
Device�Specification
39
•Contains profiles of• Core specification• security specification
•Contains list of healthcare/fitness/wearable devices • Each Healthcare device definition contains:• unique identifier (rt)• a list of mandatory resources
Resource�Specification
40
• List of reusable resources that are used in an Healthcare Device• Contains generic list of error codes• Uses core definitions
• Each Healthcare resource definition contains:• unique identifier (rt)• Indication if the resource is an sensor or actuator• List supported methods• List per method the JSON schema for input and
output
• Resources are specified in RESTful API Modelling Language (RAML)
표준화계획 OCF�Healthcare
41
OCF�Healthcare�Use�Cases
42
• Selected key enabling use cases to scope activityUse Case Priority
Fitness and Medical Data Collection 1
Health Monitor & Notify 2Smart watch notification and Data Transmission 7
Wearable device control 8Quantified Self(Self monitoring) UC3PERS(personal emergency response system) UC3
Find My Thing UC3Diabetes management UC3
1 Control proximal OIC Devices On board new DevicesControl remotely with an OIC Client
2
3
CloudCloud
Gateway1
2
3
SmartPhone
OIC OICOIC
OIC OIC
OCF�Healthcare�Use�Cases��
• Next�Phase�2�- Medical�Healthcare�
– 만성질환관리
– 건강증진
– 응급의료
– PHR(Personal�Health�Record)– Mobile�EMR�(Electronic�Medical�Record)
– Mobile�EMR�(Electronic�Medical�Record)
– 원격의료
43
Healthcare�Device�Type�(24)
44
Device Type Required Resource
Activity Tracker Activitysteps
Airflow Sensor (Breathing) BreathBlood Pressure Monitor bloodpressure
Body composition analyzer
bodyfatbodyMassIndexbodyMetricsbodywaterslm
Continuous Glucose Monitoring CGM
Cycling computer CyclingComputerDistance
Cycling Power Meter CyclingPowerSpeed
Cycling Speed and Cadence CyclingSpeedCadence
Electromyography Sensor EMG
Galvanic Skin Response Sensor GSR
Glucose Meter bloodGlucoseSensor
Device Type Required ResourceHandheld GPS Devices GeolocationHeart Rate Monitor heartrateHeight Scale bodyheight
Muscle Oxygen Monitor MuscleOxygenSaturation
Patient Position Sensor BodyPosition
Peak flowfev1ffmpef
Pulse Oximeter oxygenSaturationRespiration rate monitor respirationRateScale bodyweightSleep Monitor sleep
Smart WatchClockAltimeter
Strength fitness equipmentbodysiterepetition
Thermometer bodyTemperature
Healthcare�Resource�Type�(35)
45
Resource Types Use CaseActivity
stepsBreath
bloodpressureBodyfat
bodyMassIndexbodyMetricsBodywater
SlmCGM
CyclingComputerDistance
CyclingPowerSpeed
CyclingSpeedCadenceEMGGSR
bloodGlucoseSensor
Resource Types Use CaseGeolocation
heartratebodyheight
MuscleOxygenSaturationBodyPosition
fev1ffmpef
oxygenSaturationrespirationRate
bodyweightsleepClock
Altimeterbodysite
repetitionbodyTemperature
OCF�HEALTHCAREPOC IMPLEMENTATION
46
OIC�표준 기반 PoC 구현
47
링크: https://www.youtube.com/watch?v=O8AWchL0vwg
OIC 헬스케어 PoC 구현 동영상 제작 및 배포세계 최초로 OIC 헬스케어 리소스 및 디바이스 표준을 오픈소스 기반으로 구현
IoTivity PoC 구현결과물시연• 소프트웨어구현플랫폼
– IoTivity�1.0.1 적용
– Client:�안드로이드단말의앱으로구현
– Server:�아두이노 응용으로구현
• 하드웨어플랫폼– Client:�안드로이드 5.1.x�이상이 탑재된단말
– Server:�아두이노 due�+�BLE�shield�+�e-health�sensor�platform
48
Arduino due BLE shield E-health sensor platform
IoTivity�PoC�구현결과물시연
49
IoTivity�PoC�구현결과물시연• 시연 시나리오
– 아두이노보드에장착된 e-health�sensor�board�에서사람의생체신호를검지해서 IoTivity 플랫폼을통해안드로이드단말에서구동되고있는앱으로전달받음
50
시연동영상
51
OIC�표준 +�IoTivity 오픈소스의 장점
원천기술을 빠르게 확보
확장 개발/개작/배포/유통빠른 개발/적용
도입비용과 TCO 절감신기술이 반영되는 소스
글로벌 경쟁력 확보사물인터넷 생태계와 연계
52
2016년도 PoC 구현 계획
• 개선된 하드웨어지원 (RP3)
• 보다 다양한 기기 지원 (BLE/ANT+)
• 보다 손쉬운 프로그래밍 (Node.js)
• Legacy�BLE�연동 bridge
• 스마트홈/자동차/웨어러블연동시나리오 구현
53
2016년도 확장계획• 국내기업들과협력한상용화연동및 표준확장
• 2단계 OIC�표준화– 1단계 표준제정 및Wearable/Health/Fitness�Device�추가 및 확장
• 표준특허창출
54
OCF/IoTivity Timeline
55
‘17 Jan
CES ’17Demo
‘16 May‘15 November‘15 August
‘15Jun
Healthcare TG Launched
Draft of first Healthcare spec.
We are here.
Done!Ver 0.3
‘16 Aug
Two Healthcare Specs.
‘16 Jan
Identify Healthcare resource and devices in relation to ISO/IEEE 11073, Bluetooth GATT, ANT+
‘16 Feb
Define Healthcare-specific and OCF-generic resources and devices, and share with SHTG for comments
Ver 0.5
‘16 April
Ver 0.5Align with other TGs
Ready for IPR Review
Ver 0.7
Ver 1.0Publish OCF Healthcare specifications with OCF Specification 2.0
OCF 2.0standards
Healthcare 표준기반구현 1차 Healthcare 표준기반구현 2차
Hackathon Hackathon
Plugfest #6Beaverton, OR
(Feb 22-26)
Plugfest #7Krakow, Poland
(Apr 25-29)
Plugfest #8Seoul, S. Korea
(Jul 11-15)
Plugfest #9Fremont, CA(Sep 26-30)
Plugfest #10Taipei, Taiwan
(Dec 5-9)
Ver 1.01(12/18/2015)
Ver 1.1.0(03/29/2016)
Ver 2.0.(07/29/2016)
Ver 2.1.(10/31/2016)
Ver 1.0(10/28/2015)
FUTURE�POTENTIAL
56
Health�+�ICT�??
57
Source: 스마트의료정보 표준화 framework개발추진계획_20130307(정영복 코디)
Health�+�ICT�??
58Source: 스마트의료정보 표준화 framework개발추진계획_20130307(정영복 코디)
Health�+�ICT�??
59Source: 스마트의료정보 표준화 framework개발추진계획_20130307(정영복 코디)
문제는표준이아닌규제!!• 크라우드펀딩을받아체온계를생산하고자했던업체가직면했던벽들
1. 의료기기법(시행령,�시행규칙)
2. 의료기기인허가(동등,�개량,�임상)
3. 모바일 의료용 앱안전관리지침
4. 전기,�기계적 안정성(IEC�60601-1�3.X판)
5. 전자파 안정성(IEC�606011-2)
6. 생물학적안전규격(ISO�10993)
7. 의료기기별 안정성시험기준
8. 의료기기소프트웨어 벨리데이션가이드라인
9. 개인의료정보 보안의요구사항(개인정보보호법,�의료법,�생명윤리법,�정보통신망법)
10. 의료기기데이터 국제표준(ISO/IEEE,�IHE,�HL7)�상호운용성 평가기준(유헬스케어)
11. KC�전파 인증
12. SIG�블루투스인증
13. GMP�품질 인증
14. 신의료기기 평가(보험수가)
15. 의료기기포장 공정벨리데이션
16. 의료기기판매업 허가/신고(체온계는 면제)
17. 의료기기광고 사전심의규정
60
https://www.facebook.com/groups/koreamobilehealthcare/permalink/1711243019151465/
새로운 기회들 IoT Network�effect�
61
IoT Network�effect�!!
62
IoT Network�effect�!!
63
JongHong Jeon (hollobit@etri.re.kr) +82-42-860-5333
https://www.linkedin.com/in/hollobithttp://twitter.com/hollobit