Ce diaporama a bien été signalé.

OCF/IoTivity for Healthcare/Fitness/Wearable

17

Partager

Prochain SlideShare
OIC AGL Collaboration
OIC AGL Collaboration
Chargement dans…3
×
1 sur 65
1 sur 65

OCF/IoTivity for Healthcare/Fitness/Wearable

17

Partager

Télécharger pour lire hors ligne

It's an introduction slides about Healthcare / Fitness / Wearable Application development based on OCF standards & IoTivity open source.

It's an introduction slides about Healthcare / Fitness / Wearable Application development based on OCF standards & IoTivity open source.

Plus De Contenu Connexe

Livres associés

Gratuit avec un essai de 14 jours de Scribd

Tout voir

OCF/IoTivity for Healthcare/Fitness/Wearable

  1. 1. OCF & IoTivity for Healthcare/Fitness/Wearable Jonghong Jeon ETRI, PEC Email: hollobit@etri.re.kr http://www.etri.re.kr
  2. 2. OCF & IOTIVITY 2
  3. 3. 3
  4. 4. 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
  5. 5. 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
  6. 6. 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 OCF Develops reference implementation of the OCF specification Coordination Innovative coordination – Specs & Open Source ready simultaneously
  7. 7. 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
  8. 8. 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
  9. 9. OCF Organisational Structure 9 Open Source Work Group Standards Work Group Board of Directors Marketing Communications Work Group Compliance & Conformance Core Security Smart Home Technology Planning Work Group Membership Work Group Industrial New Items PR Branding Liaisons Discovery & Connectivity Primitive Services Project Planning & Requirements Security Health Events Ecosyste m Use Cases oneM2M UPnP Work Group AV IoT Data Modelling Tool UPnP Certification Certification Work Group Remote Access Digital Media
  10. 10. IPR Policy - Royalty Free* Licenses 10 Apache v2.0 Incoming: 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
  11. 11. Code Related Patent License ­ Apache v2.0 11 + + + + License License License License CODE CODE CODE CODE Developer or User Patent license covers company’s code contributions
  12. 12. Spec-Related Patent License ­ RAND-Z 12 Member Product SPEC Certification Program Compliant Portion License Patent license covers everything in specification
  13. 13. OCF IPR Scope 13
  14. 14. TECHNICAL ARCHITECTURE (COMMUNICATIONS) 14
  15. 15. 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
  16. 16. Scope of IoT 16 service #2 domain service #1 domain Local Control Remote Control Server to Server Industrial Smart Home Healthcare SecurityDevice management Group management Protocol Bridge/GW Messaging StreamingDiscovery ID & Addressing CRUDN Common Resource Model … Wi-Fi BT/BLE Thread … Vertical Profiles Baseline Functionality Connectivity Controller Controller Cloud Servers Cloud Servers Things Controller App Cloud Interface Controller
  17. 17. 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)
  18. 18. Example ­ Current Consumer Radio- Based Standards 18 Applications & Services Data & Control Points Comms Protocols Transports Profiles, Data & Resource Models Wi-Fi ZigBee Thread Z-Wave IP 802.15.4 802.15.4 IP Bluetooth®LowEnergy ? ? BLE IP ? IP = 6LoWPAN Extensible
  19. 19. Example ­ Comms Frameworks (Consumer) 19 Wi-Fi BLE OCF Comms Framework (Single Resource & Data Model) IP IP ThreadIP802.15.4 Bluetooth®LowEnergy Applications & Services Data & Control Points Z-Wave ZigBee802.15.4
  20. 20. TECHNICAL ARCHITECTURE (DEFINITION OF THING) 20
  21. 21. 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
  22. 22. 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)
  23. 23. TECHNICAL ARCHITECTURE (STANDARD & INTEROPERABILITY) 23
  24. 24. Interoperability & Certification 24 Prerequisites: Dependency Certification (e.g. Connectivity) Conforman ce Test Interopera bility Test Certificate Issue & Logo Licensing Device under Test CERTIFIED Mandatory (in spec, cert & committed in Open Source Project) Option al Open Source Featur es Tested Option al Open Source Featur es Tested Option al Spec Featur es Option al Spec Featur es SpecificationOpen Source • Conformance test - Each device proves conformance to specifications • Interoperability test - Each device proves interoperability with other devices • Certification Scope
  25. 25. 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
  26. 26. OCF Conceptual Framework 26 Device Profiles Smarthome Enterprise Industrial Automotive Education Health Transports LE Remote Access Cloud Core Framework Security, Identity & Permissions Discovery Data Transmission Data Management Device Management Resource Model Remote Access
  27. 27. OCF Specification 1.0 27 OIC 1.0 세부 표준명 표준 설명 (작업그룹) 1 Core Framework OIC 프로파일이 동작될 수 있도록 하기 위한 핵심 구조, 인터페이스, 프로토콜과 서비스들을 정의 (SWG CFTG) 2 Resource Type 스마트홈 리소스들에 대한 기본 스키마와 이를 기반으로 확장된 다양한 리소스 집합들에 대해 정의 (smarthome TG) 3 Security 상이한 암호화 능력을 갖는 장비들 사이에서 장치 구동과 연결에 필요한 도구와 보안 자원 모델을 정의 (Security TG) 4 Smart Home Device 스마트홈 응용 분야에서 사용되는 OIC 호환 장치 규격을 정의 (smarthome TG) 5 Remote Access XMPP와 같은 산업표준을 기반으로 원격 접속에 필요한 제반 사항들과 기능들을 정의 (SWG RATG) http://openconnectivity.org/resources/specifications
  28. 28. TECHNICAL ARCHITECTURE (CORE FRAMEWORK) 28
  29. 29. 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 Client OIC Client OIC Server OIC Server Model 1 RR
  30. 30. 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/p Resource 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
  31. 31. 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) M oic/d (oic.d.light) M Binary switch (oic.r.switch.binary) M Brightness (oic.r.light.brightness) O Example: Smart light device with 4 resources oic/res oic/d Binary switch Brightness
  32. 32. 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 Industrial Internet Smart Home … OIC Core Framework Security Device management Group management Protocol Bridge/GW Messaging StreamingDiscovery ID & Addressing CRUDN Common Resource Model ① ② ③ ④ ⑤ ⑥ ⑦
  33. 33. 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 for legacy devices) ApplicationApplication Alternatives Project B OIC Stack
  34. 34. 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
  35. 35. OCF HEALTHCARE 35
  36. 36. [참고] 국제표준화 연관도 36 OIC Healthcare (Wearable/Fitnes s/Healthcare) PHR Healthcare (Continua, ISO/IEC, ISO/IEEE, ITU-T, PHA) OIC IoT Medical, Wellness, Personal, Remote, Smarthome Industrial
  37. 37. 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
  38. 38. Specifications 38 • Specifications are split in 2 documents: • Device specification • Resource specification The Device specification uses the resources defined in the resource specification
  39. 39. 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
  40. 40. 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)
  41. 41. 표준화 계획 ­ OCF Healthcare 41
  42. 42. OCF Healthcare Use Cases 42 • Selected key enabling use cases to scope activity Use Case Priority Fitness and Medical Data Collection 1 Health Monitor & Notify 2 Smart watch notification and Data Transmission 7 Wearable device control 8 Quantified Self(Self monitoring) UC3 PERS(personal emergency response system) UC3 Find My Thing UC3 Diabetes management UC3 1 Control proximal OIC Devices On board new Devices Control remotely with an OIC Client 2 3 CloudCloud Gateway 1 2 3 Smart Phone OIC OIC OIC OIC OIC
  43. 43. OCF Healthcare Use Cases • Next Phase 2 - Medical Healthcare – 만성질환관리 – 건강증진 – 응급의료 – PHR(Personal Health Record) – Mobile EMR (Electronic Medical Record) – Mobile EMR (Electronic Medical Record) – 원격의료 43
  44. 44. Healthcare Device Type (24) 44 Device Type Required Resource Activity Tracker Activity steps Airflow Sensor (Breathing) Breath Blood Pressure Monitor bloodpressure Body composition analyzer bodyfat bodyMassIndex bodyMetrics bodywater slm Continuous Glucose Monitoring CGM Cycling computer CyclingComputer Distance Cycling Power Meter CyclingPower Speed Cycling Speed and Cadence CyclingSpeedCadence Electromyography Sensor EMG Galvanic Skin Response Sensor GSR Glucose Meter bloodGlucoseSensor Device Type Required Resource Handheld GPS Devices Geolocation Heart Rate Monitor heartrate Height Scale bodyheight Muscle Oxygen Monitor MuscleOxygenSaturation Patient Position Sensor BodyPosition Peak flow fev1 ffm pef Pulse Oximeter oxygenSaturation Respiration rate monitor respirationRate Scale bodyweight Sleep Monitor sleep Smart Watch Clock Altimeter Strength fitness equipment bodysite repetition Thermometer bodyTemperature
  45. 45. Healthcare Resource Type (35) 45 Resource Types Use Case Activity steps Breath bloodpressure Bodyfat bodyMassIndex bodyMetrics Bodywater Slm CGM CyclingComputer Distance CyclingPower Speed CyclingSpeedCadence EMG GSR bloodGlucoseSensor Resource Types Use Case Geolocation heartrate bodyheight MuscleOxygenSaturation BodyPosition fev1 ffm pef oxygenSaturation respirationRate bodyweight sleep Clock Altimeter bodysite repetition bodyTemperature
  46. 46. OCF HEALTHCARE POC IMPLEMENTATION 46
  47. 47. OIC 표준 기반 PoC 구현 47 링크: https://www.youtube.com/watch?v=O8AWchL0vwg OIC 헬스케어 PoC 구현 동영상 제작 및 배포 세계 최초로 OIC 헬스케어 리소스 및 디바이스 표준을 오픈소스 기반으로 구현
  48. 48. 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
  49. 49. IoTivity PoC 구현결과물 시연 49
  50. 50. IoTivity PoC 구현결과물 시연 • 시연 시나리오 – 아두이노 보드에 장착된 e-health sensor board 에서 사람의 생체신호를 검지해서 IoTivity 플랫폼을 통해 안드로이드 단말에서 구동되고 있는 앱으로 전달받음 50
  51. 51. 시연 동영상 51
  52. 52. OIC 표준 + IoTivity 오픈소스의 장점 원천기술을 빠르게 확보 확장 개발/개작/배포/유통 빠른 개발/적용 도입비용과 TCO 절감 신기술이 반영되는 소스 글로벌 경쟁력 확보 사물인터넷 생태계와 연계 52
  53. 53. 2016년도 PoC 구현 계획 • 개선된 하드웨어 지원 (RP3) • 보다 다양한 기기 지원 (BLE/ANT+) • 보다 손쉬운 프로그래밍 (Node.js) • Legacy BLE 연동 bridge • 스마트홈/자동차/웨어러블 연동 시나리오 구현 53
  54. 54. 2016년도 확장 계획 • 국내 기업들과 협력한 상용화 연동 및 표준 확장 • 2단계 OIC 표준화 – 1단계 표준 제정 및 Wearable/Health/Fitness Device 추가 및 확장 • 표준특허 창출 54
  55. 55. OCF/IoTivity Timeline 55 ‘17 Jan CES ’17 Demo ‘16 May ‘15 November‘15 August ‘15 Jun 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.5 Align with other TGs Ready for IPR Review Ver 0.7 Ver 1.0 Publish OCF Healthcare specifications with OCF Specification 2.0 OCF 2.0 standards Healthcare 표준 기반 구현 1차 Healthcare 표준 기반 구현 2차 Hackathon Hackathon Plugfest #6 Beaverton, OR (Feb 22-26) Plugfest #7 Krakow, Poland (Apr 25-29) Plugfest #8 Seoul, S. Korea (Jul 11-15) Plugfest #9 Fremont, CA (Sep 26-30) Plugfest #10 Taipei, 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)
  56. 56. FUTURE POTENTIAL 56
  57. 57. Health + ICT ?? 57 Source: 스마트의료정보 표준화 framework개발추진계획_20130307(정영복 코디)
  58. 58. Health + ICT ?? 58Source: 스마트의료정보 표준화 framework개발추진계획_20130307(정영복 코디)
  59. 59. Health + ICT ?? 59Source: 스마트의료정보 표준화 framework개발추진계획_20130307(정영복 코디)
  60. 60. 문제는 표준이 아닌 규제!! • 크라우드 펀딩을 받아 체온계를 생산하고자 했던 업체가 직면했던 벽들 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/
  61. 61. 새로운 기회들 ­ IoT Network effect 61
  62. 62. IoT Network effect !! 62
  63. 63. IoT Network effect !! 63
  64. 64. JongHong Jeon (hollobit@etri.re.kr) +82-42-860-5333 https://www.linkedin.com/in/hollobit http://twitter.com/hollobit

×