Copyright © 2020-2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
Web of Things는 스마트 홈, 산업, 스마트 시티, 소매 및 헬스 애플리케이션을 포함한 여러 IoT 도메인에 적용 가능하며, W3C WoT 표준의 사용은 여러 공급업체와 생태계의 장치를 결합하는 IoT 시스템 개발을 단순화할 수 있습니다. WoT Working Group은 이러한 도메인의 요구사항을 처리하기 위해 여러 명세를 개발해 왔으며, 계속 개발하고 있습니다.
이 사용 사례 및 요구사항 문서는 다양한 이해관계자가 기여한 여러 도메인의 새로운 IoT/WoT 사용 사례를 수집하기 위해 작성되었습니다. 그런 다음 사용 사례는 W3C WoT working group의 표준화 작업을 위한 요구사항의 동기를 부여하는 데 사용될 수 있습니다. 또한 일반적인 상위 수준 요구사항은 이 문서에서 사용자 스토리의 형태로 정의되며, 각 사용자 스토리는 동기(종종 하나 이상의 사용 사례), 특정 이해관계자, 그리고 WoT 명세에서 지원되거나 정의될 수 있는 구체적인 기능 또는 속성을 연결합니다.
이 섹션은 이 문서가 발행된 시점의 문서 상태를 설명합니다. 현재 W3C 발행물 목록과 이 기술 보고서의 최신 개정판은 W3C 표준 및 초안 색인에서 확인할 수 있습니다.
이 문서는 Web of Things Interest Group에서 노트 트랙을 사용하여 그룹 노트로 발행했습니다.
이 그룹 노트는 Web of Things Interest Group의 승인을 받았지만, W3C 자체나 그 회원들의 승인을 받은 것은 아닙니다.
W3C 특허 정책은 이 문서에 대해 어떠한 라이선스 요구사항이나 약속도 부과하지 않습니다.
이 문서는 2025년 8월 18일 W3C Process Document의 적용을 받습니다.
World Wide Web Consortium(W3C)은 Web of Things(WoT) Architecture [wot-architecture] 및 Web of Things(WoT) Thing Description(TD) [wot-thing-description]를 공식 W3C 권고안으로 발행했으며, Web of Things(WoT) Discovery [wot-discovery]와 같은 관련 명세도 발행했습니다. 이러한 명세는 Internet of Things 플랫폼과 애플리케이션 전반의 손쉬운 통합을 가능하게 하며, 최근 charter는 그 적용 가능성을 계속 확장해 왔습니다.
그룹이 출범한 이후 WoT IG는 전 세계적인 기반에서 Internet of Things(IoT) 서비스의 상호운용성을 가능하게 하는 데 필요한 기능을 더 잘 이해하기 위해 사용 사례를 수집해 왔습니다. 이러한 사용 사례는 여기에 수집되어 있습니다. 일반 요구사항을 더 명확히 정의하기 위해, 명세의 특정 기능 뒤에 있는 동기를 문서화하려는 사용자 스토리 집합으로 보강되었습니다.
현재 문서는 WoT 표준의 향후 표준화 작업을 위해 새로운 사용 사례와 요구사항(사용자 스토리 형식)을 수집하고 설명합니다. 가능한 경우, 현재 표준이 나열된 사용자 스토리를 이미 충족하는 위치도 문서화했습니다.
이 문서는 여러 저자가 기여한 사용자 스토리와 사용 사례를 설명하는 장으로 구성되어 있습니다. 의도는 필요에 따라 이 문서의 향후 개정판에 추가 사용자 스토리와 사용 사례가 추가되도록 하는 것입니다.
이 문서의 사용 사례 모음은 두 가지 범주로 나눌 수 있습니다:
가능한 경우, 이해관계자는 WoT Security and Privacy Guidelines [wot-security]에 정의된 용어를 사용하여 식별해야 합니다. 편의를 위해 이러한 용어를 여기에 나열하지만, 전체 정의는 해당 문서를 참조하십시오:
다음 추가 이해관계자와 역할은 사용 사례가 수집될 때 식별되었거나 다른 WoT 문서에 정의되어 있습니다:
사용자 스토리는 이해관계자(누가 필요를 가지는지), 기술적 요구사항(무엇이 필요한지; 능력 또는 조건; 기능), 그리고 기능적 요구사항(왜 필요한지; 목적 또는 동기; 사용 사례)을 설명하는 단일 문장 형식으로 요구사항의 상위 수준 요약을 제공합니다. 이는 흔히 다음 형식의 문장으로 표현됩니다: "As a Who I need What so that I can Why." 명확성을 위해 다음 사용자 스토리에서는 각 부분을 목록으로 나눕니다. 각 사용자 스토리는 추가로 식별된 능력에 대한 동기를 설정하는 하나 이상의 사용 사례 (또는 사용 사례 범주)를 식별합니다. 능력은 다른 기술 명세의 기능 집합에 해당합니다.
TD의 재사용 가능한 연결 설명.
MQTT 및 WebSockets와 같은 연결 지향 프로토콜을 더 잘 설명하기 위해.
기본 용어를 사용하지 않는 경우 TD를 단순화하거나 중복을 피하기 위해
이 기능에 동기를 부여하는 하위 문제가 적어도 세 가지 있습니다:
application/json이 아닌 경우, 그렇지 않으면 각 form에서
반복되어야 합니다.
내 장치에서 나오는 데이터의 바이트 순서를 이진 프로토콜(예: Modbus, Profinet 등)에서 표현
TD Consumer가 내 장치와 통신할 수 있도록
이벤트 알림이 없는 장치(예: Modbus, Profinet 등)에서 폴링 속도 제한을 표현
TD Consumer가 적절한 폴링 속도를 사용할 수 있도록
WoT 자산에 대한 무단 접근을 얻으려는 의도로 WoT 프로토콜 바인딩을 사용하는 원격 공격 방법은 완화되어야 합니다.
접근 제어, 인증 및 인가 메커니즘.
WoT 장치 및 서비스의 네트워크 인터페이스는 각 프로토콜에 적합한 보안 메커니즘을 지원해야 합니다.
WoT 자산에 대한 무단 악성 접근을 방지합니다.
WoT 자산에 대한 무단 접근을 얻으려는 의도로 WoT Thing Description에 설명된 노출된 WoT 인터페이스를 사용하는 원격 공격 방법은 완화되어야 합니다.
접근 제어, 인증 및 인가 메커니즘.
WoT 장치 및 서비스의 네트워크 인터페이스는 각 프로토콜에 적합한 보안 메커니즘을 지원해야 합니다.
WoT 자산에 대한 무단 악성 접근을 방지합니다.
무단 공격자의 오용을 방지하기 위해 WoT 자산에 대한 접근을 제어하고 관리합니다.
WoT 자산에 대한 접근을 특정 인증된 사용자로 제한하고, 특정 자산을 사용할 권한을 검증할 수 있는 능력.
디렉터리 서비스 및 자기 설명과 같은 WoT 서비스의 아키텍처는 정보를 공개하기 전에 인증 및 인가 검사를 허용해야 합니다.
WoT 자산의 무단 악성 사용을 방지합니다.
악의적인 공격자가 권한 있는 사용자의 정당한 사용을 방해하는 WoT 서비스에 대한 서비스 거부 공격을 방지합니다.
악성 네트워크 공격을 받더라도 권한 있는 사용자가 WoT 서비스에 접근할 수 있도록 보장하는 능력.
공격자는 예를 들어 장치에 수많은 요청을 보내 다른 권한 있는 사용자에게 응답하지 못할 정도로 바쁘게 만들어 다른 사용자의 WoT 서비스 접근을 차단하려고 시도할 수 있습니다. 장치 구현은 이러한 공격을 완화하기 위한 모범 사례를 구현해야 합니다.
WoT 서비스가 항상 권한 있는 사용자에게 제공될 수 있도록 합니다.
WoT 서비스가 다른 서비스에 대한 분산 서비스 거부 공격에 사용되는 것을 방지합니다.
WoT 서비스가 분산 서비스 거부 공격에 사용되는 것을 방지.
WoT 장치가 다른 서비스에 대한 접근을 방해하는 데 악의적으로 사용되지 않도록 합니다.
예를 들어 TD의 WoT 인터페이스 설명은 정확해야 하며, 스푸핑, 리디렉션 및 기타 공격을 피하기 위해 권한 없는 제3자에 의한 수정이 방지되어야 합니다.
WoT TD가 무단 수정되는 것을 방지할 수 있는 능력.
WoT TD의 수정이 스푸핑 또는 리디렉션 공격에 사용될 수 없도록 합니다.
공격 계획에 사용되거나 사적인 정보를 추론하는 데 사용될 수 있는 정보의 공개를 피하기 위해, 권한 없는 제3자가 기밀 장치 메타데이터를 가로채는 것을 방지합니다.
Thing Description과 같은 메타데이터에 대한 접근을 권한 있는 사용자로만 제한할 수 있는 능력.
무단 사용자가 기밀 메타데이터를 사용하여 공격을 계획하거나 사용자, 장치 소유자 또는 기타 이해관계자에 관한 사적인 정보를 추론할 수 없도록 합니다.
신원 또는 접근 권한과 같은 시스템 사용자와 관련된 데이터는 접근이 허용되기 전에 확인되어야 합니다.
접근 권한 또는 신원과 같은 시스템 사용자 데이터의 정확성(진정성)을 확인할 수 있는 능력.
어떤 경우에는 시스템 서비스에 대한 익명 접근이 필요할 수 있습니다. 이 경우 전달자 토큰과 같이 접근 권한만 인증하고, 사용자 신원은 별도로 확인하는 메커니즘이 있어야 합니다.
권한 있는 시스템 사용자로 가장하는 인증되지 않은 공격자에게 시스템에 대한 무단 접근이 제공되지 않도록 합니다.
시스템 사용자의 신원 및 기타 사적인 정보는, 가능한 경우 그들이 어떤 서비스에 접근하는지도 포함하여, 기밀로 유지되어야 합니다.
시스템 사용자 데이터의 기밀성을 유지할 수 있는 능력.
사용자의 신원은 일반적으로 제3자에게 공개되어서는 안 되며, 어떤 경우에는 장치에도 공개되어서는 안 됩니다(예를 들어 인증/신원과 인가 능력의 분리를 사용). 또한 시스템 사용자가 어떤 서비스에 접근하고 있는지 제3자가 볼 수 없도록 방지하는 메커니즘도 마련되어야 합니다.
시스템 사용자에 대한 사적인 정보가 권한 없는 제3자에게 공개되지 않도록 합니다.
메타데이터(예: TD)의 전송을 포함한 모든 통신에 대해 권한 없는 제3자의 가로채기 및/또는 수정을 방지하기 위한 완화책이 제공되어야 합니다.
권한 없는 제3자가 통신을 가로채거나 수정할 수 없도록 통신을 보호할 수 있는 능력
이는 암호화된 통신 채널로 지원될 수 있으며, 그 전제 조건은 통신에 참여하는 권한 있는 참여자들의 인증입니다. 암호화된 통신은 또한 통신의 무결성을 보장해야 합니다. 일반적으로 권한 없는 당사자가 통신을 읽을 수 없어야 할 뿐만 아니라, 탐지 없이 통신을 수정할 수도 없어야 합니다.
공격자가 기밀 정보에 접근하거나 권한 있는 통신의 조작을 통해 WoT 자산에 접근할 수 없도록 합니다.
피어 투 피어(자기 식별), 로컬(네트워크 세그먼트), 글로벌(인터넷 전체) 탐색 지원
탐색에는 여러 규모에서 장치를 발견하는 능력이 포함되어야 합니다. 규모에는 로컬 네트워크 (예: LAN의 단일 서브넷)와 인터넷 규모 탐색 (예: 도시에서 제공하는 서비스 탐색)이 모두 포함되어야 합니다. 서로 다른 구현 메커니즘이 필요하더라도, 서로 다른 규모에서 발견된 장치와 서비스는 공통 탐색 추상화를 통해 통합되어야 합니다.
IoT 서비스와 장치를 네트워크 위치와 무관하게 찾고 그 설명을 가져올 수 있도록 합니다.
서드 파티 서비스를 통한 탐색 지원
탐색에는 디렉터리 서비스와 같은 서드 파티 서비스를 통해 장치를 발견할 수 있는 능력이 포함되어야 합니다.
절전 장치, 브라운필드 장치 (WoT로 인터페이스를 설명할 수 있지만 설계에 명시적 내장 지원이 포함되지 않은 장치), 소형 장치(능력상의 이유로 자기 설명을 할 수 없는 장치), 교차 네트워크 탐색(확장성과 보안상의 이유로, 소형 장치는 로컬 네트워크 외부에서 직접 발견되기를 원하지 않을 수 있음), 그리고 컬렉션 검색을 지원하기 위해.
WoT Scripting API의 탐색 지원과의 호환성
WoT Discovery 기능에 접근할 수 있도록 WoT Scripting API에 API가 제공되어야 합니다.
WoT Consumer가 사용 가능한 WoT 서비스의 WoT TD를 동적으로 찾고 접근할 수 있도록 합니다.
결과를 필터링하기 위한 키워드, 템플릿 및 시맨틱 쿼리를 포함한 다양한 형태의 쿼리 지원.
특히 인터넷 규모에서 장치와 서비스를 탐색할 때, 접근 가능한 모든 장치의 메타데이터(Thing Description)에 접근하는 것은 실현 가능하지 않습니다. 대신 적절한 기준을 사용하여 적합한 부분 집합을 선택해야 합니다.
탐색이 많은 수의 장치와 서비스로 확장될 수 있도록.
공간 및 서브넷 제한 쿼리 지원.
탐색을 위한 기본적인 필터링 능력 중 하나는 위치별 필터링을 포함해야 하며, 이를 통해 물리적으로 가까운 장치만 발견될 수 있습니다. 어떤 상황에서는 서브넷 제한 탐색이 이에 대한 대리 수단이 될 수 있습니다. 예를 들어 스마트 홈은 일반적으로 모든 장치가 단일 서브넷에 있으며, 이 서브넷으로 검색을 제한하는 것은 해당 특정 가정으로 검색을 제한하는 데 적절합니다. 그러나 더 일반적으로 큰 건물과 기관은 여러 서브넷을 가질 수 있으며, 스마트 시티와 같은 사용 사례에서는 특정 지리적 영역 또는 의미적 영역(예: 이름이 있는 동네, 건물의 특정 층)으로 검색을 명시적으로 제한해야 합니다. 어떤 경우에는 검색이 사용자의 물리적 근접 위치가 아닌 영역으로 제한될 수도 있습니다. 예를 들어 사용자가 여행 전 다른 도시의 날씨를 확인하거나, 도시 대시보드가 동네별 오염 상태를 확인하는 경우입니다.
인터넷 규모 검색을 특정 위치 근처 또는 내부의 집합으로 제한할 수 있도록 합니다(이 위치는 사용자의 위치일 수도 있고 아닐 수도 있습니다).
서브넷 또는 여러 디렉터리 서비스에 걸칠 수 있는 쿼리 지원.
탐색 메커니즘은 여러 서브넷의 탐색 결과를 확장하고 결합할 수 있을 만큼 유연해야 합니다. LAN에서 허용되는 일부 메커니즘, 예를 들어 브로드캐스트는 일반적으로 대규모 인터넷에서 사용하기에 적합하지 않습니다. 디렉터리 서비스는 이 능력을 지원하는 한 가지 방법입니다.
네트워크 분할과 무관하게 장치 탐색이 가능하도록.
대규모 TD 데이터베이스로 확장 가능해야 함.
탐색은 수백, 수천, 심지어 수백만 개의 장치와 서비스를 가진 대규모 시스템에서 작동해야 합니다. 네트워크 세그먼트에 걸칠 수 있는 능력과 출처에서 검색 기준으로 결과를 필터링할 수 있는 능력을 포함하여, 대규모 애플리케이션을 지원하기 위해 여러 다른 능력이 필요합니다. 제한된 또는 과금되는 대역폭을 가진 소형 요청 장치와 같은 많은 경우, 대규모 시스템이 디렉터리의 가능한 모든 장치에 대한 모든 메타데이터를 요청자에게 보내는 것은 허용되지 않습니다.
매우 큰 IoT 장치 및 서비스 시스템에 접근하고 관리할 수 있도록.
동적 및 정적 메타데이터(TD)를 모두 지원.
일부 메타데이터는 고정되어 있고 일부는 "빈번함"의 어떤 값에 대해 자주 변경됩니다. 탐색 메커니즘은 업데이트를 지원하고 요청 시 변경 사항을 구독자에게 알릴 수 있을 만큼 유연해야 합니다. 변경이 매우 빈번한 경우, 메타데이터를 통해서가 아니라 장치 또는 서비스에서 직접 데이터에 접근해야 한다는 것을 사용자에게 표시할 방법이 있어야 합니다. 위치와 같은 일부 데이터는 정적일 수도 있고 동적일 수도 있습니다. 이 특정 형태의 메타데이터는 필터링 기준에도 유용할 것입니다. 탐색 메커니즘은 업데이트 빈도의 다양한 규모와 함께 작동해야 합니다.
자주 변경되지 않는 데이터는 효율적으로 저장될 수 있고, 변경되는 데이터는 적시에 업데이트될 수 있도록.
TD의 명시적 삭제 지원.
메타데이터(TD)가 탐색 시스템에 원격으로 저장되는 경우, 오래되었거나 잘못된 메타데이터를 제거할 수 있어야 합니다. 개인정보 보호 목표를 지원하기 위해 삭제를 지원해야 할 수도 있습니다. 삭제는 요청이 이루어진 후 가능한 한 빨리 수행되어야 하며, 탐색 동작 뒤에 삭제 동작을 이어서 수행할 수 있어야 합니다. 그러나 삭제 동작은 메타데이터의 권한 있는 소유자만 삭제를 요청할 수 있도록 보호되어야 합니다.
오래되었거나 잘못되었거나 사적인 메타데이터를 더 이상 필요하지 않거나 적절하지 않을 때 제거할 수 있도록.
메타데이터에 대한 접근 제어 지원.
장치 또는 서비스의 메타데이터가 서드 파티 디렉터리 서비스에 저장되는 경우, 이를 업데이트, 관리, 수정 또는 삭제해야 할 수 있습니다. 이러한 동작은 디렉터리 서비스에 원래 항목을 만든 엔티티와 같이 인증되고 권한이 있는 엔티티만 수행해야 합니다. 메타데이터가 장치에 저장된 경우, 해당 정보에 대한 업데이트도 펌웨어 업데이트와 유사하게 적절한 접근 제어의 적용을 받아야 합니다.
메타데이터의 무결성을 유지할 수 있도록
더 이상 접근 가능하지 않거나 활성 상태가 아닌 장치의 TD를 자동으로 정리.
서드 파티 디렉터리 서비스에 저장된 메타데이터(TDS)는 제한된 수명을 가져야 하며, 메타데이터 레코드를 원래 생성한 엔티티 또는 위임자와 같은 권한 있는 엔티티가 그 수명을 연장하지 않으면 자동으로 삭제되어야 합니다.
오래된 메타데이터를 제거하여 공간을 절약하고 비활성 장치 및 서비스에 접근하려는 시도를 피할 수 있도록.
IETF CoRE Resource Directory 및 CoRE Link Format과 정렬.
Thing Description 및 Thing Description Directory를 포함한 WoT 리소스를 탐색하기 위해 CoRE Resource Directory와 같이 IETF가 정의한 메커니즘을 사용할 수 있어야 합니다.
IETF CoRE와 WoT 생태계가 공존할 수 있고, IETF CoRE 호환 시스템에서 WoT 리소스를 발견할 수 있도록.
W3C DID 및 DID Document와 정렬.
Thing에 대한 DID가 주어지면, DID Document를 해석하고 그 안에 포함된 링크를 따라가서 해당 Thing의 TD를 발견할 수 있어야 합니다. 반대로, DID를 Thing 식별자로 사용할 수도 있어야 합니다.
Thing의 DID 식별자를 사용하여 DID 메커니즘으로 Thing 메타데이터에 접근할 수 있으므로, DID와 WoT 생태계가 함께 작동할 수 있도록.
WoT TD는 다양한 기존 탐색 메커니즘을 통해 접근 가능해야 합니다.
많은 기존 탐색 메커니즘이 존재하며, WoT는 새로운 탐색 메커니즘으로 확장 가능해야 할 뿐만 아니라 이들과도 함께 작동해야 합니다. 이는 기존 비-WoT 탐색 메커니즘을 URL로 해석되는 "첫 접촉" 또는 "소개" 메커니즘으로 사용하고, 그 URL을 사용하여 WoT 전용 탐색 메커니즘에 접근하는 방식으로 달성할 수 있습니다. 이러한 방식으로 지원되는 기존 탐색 메커니즘에는 DNS-SD, DNS-SRV, DHCP, QR 코드 및 Bluetooth 비콘이 포함되어야 하지만 이에 국한되지는 않습니다. 일반적으로 URL을 반환하는 모든 메커니즘을 "소개" 메커니즘으로 사용할 수 있어야 합니다.
WoT 시스템이 다양한 네트워크 규모에 적합한 메커니즘을 포함하여 기존 및 새로운 탐색 메커니즘과 상호운용될 수 있도록.
기밀성을 위한 가장 잘 알려진 방법 지원.
WoT TD(Thing Description)와 같은 상세한 WoT 메타데이터는 권한 없는 네트워크 참여자에게 보이지 않아야 합니다. 이는 적절한 암호화를 사용하는 HTTP 기반 네트워크 API를 통해서만 WoT TD를 제공함으로써 달성할 수 있으며, 따라서 전송은 기존 웹 API와 적어도 동등한 수준으로 보호될 수 있습니다. 이는 WoT 탐색의 두 번째 단계인 "exploration"에만 적용된다는 점에 유의하십시오. "introduction" 단계는 보호되지 않지만, WoT 메타데이터를 직접 배포하는 것도 금지됩니다.
WoT 메타데이터(TD)를 무단 접근으로부터 보호할 수 있도록.
인증을 위한 가장 잘 알려진 방법 지원.
WoT TD(Thing Description)와 같은 상세한 WoT 메타데이터는 인증되지 않은 요청자에게 제공되어서는 안 됩니다. 이는 적절한 인증과 암호화를 결합한 HTTP 기반 네트워크 API를 통해서만 WoT TD를 제공함으로써 달성할 수 있으며, 따라서 메타데이터에 접근하는 WoT 인터페이스는 기존 웹 API와 적어도 동등한 수준으로 보호될 수 있습니다. 이는 WoT 탐색의 두 번째 단계인 "exploration"에만 적용된다는 점에 유의하십시오. "introduction" 단계는 보호되지 않지만, WoT 메타데이터를 직접 배포하는 것도 금지됩니다.
WoT 메타데이터(TD)가 인증된 요청자에게만 제공되도록.
사용자 신원을 드러내지 않는 인증 및 인가 메커니즘 지원.
요청자의 신원이 중요하지 않은 경우에는 개인정보 보호를 위해 익명 인증 메커니즘이 가능해야 합니다. 전달자 토큰과 같은 잘 알려진 웹 기술을 이를 위해 사용할 수 있습니다. 이는 "introductions"에는 적용되지 않고, WoT Discovery의 두 번째 "exploration" 단계에만 적용된다는 점에 유의하십시오. 일부 introduction 메커니즘은 개인정보 보호를 보존하지 않을 수 있으며, 개인정보 보호가 중요한 경우 이러한 메커니즘은 피해야 합니다. 요청자의 신원을 드러내지 않는 introduction 메커니즘이 적어도 하나는 제공될 것입니다.
개인정보 보호를 보존하면서 WoT 서비스와 메타데이터에 접근할 수 있도록.
장치 및 정보 수명주기, 신뢰 관리, 접근 제어 지원
개인정보 보호와 기밀성을 보존하면서 장치를 시스템에 추가하고 제거하는 프로세스가 가능한 한 단순하도록
TD와 기타 메타데이터를 인증되고 인가된 엔티티에게만 배포하는 것.
개인정보 보호와 기밀성이 유지될 수 있도록
TD, 기타 메타데이터 또는 쿼리를 권한 없는 엔티티에 누출하지 않을 것.
개인정보 보호와 기밀성이 유지될 수 있도록
인간 상호작용을 최소화하거나 전혀 필요로 하지 않는 Thing과 서비스의 단순한 자동 탐색.
자동화된 시스템이 시스템 관리를 위해 탐색을 사용할 수 있고 구현이 가능한 한 직관적이도록
적절한 경우 인간 인증(예: 페어링 버튼 누르기) 지원.
새 장치를 가정 환경에서 쉽고 안전하게 온보딩할 수 있도록
사용자가 감각 또는 운동 제한이 있더라도 장치를 탐색할 수 있어야 합니다.
감각 또는 운동 제한이 있는 사용자가 WoT 시스템을 사용할 수 있도록
다양한 접근성 및 사용 사례 요구를 처리하기 위해 대체 형태의 탐색이 지원되어야 합니다.
시스템이 다양한 사용자의 요구를 수용할 수 있도록
센서:
액추에이터:
추가 장치:
낙농은 가축 축사 안팎의 환경 조건 제어 및 관리뿐 아니라 급이, 착유, 번식 및 분뇨 처리에서 상당한 노동력을 필요로 합니다. 특히 착유는 젖소를 다루는 전체 작업 시간의 40% 이상을 차지합니다.
최근 낙농 산업의 선진국들은 착유 노동을 줄이기 위해 다양한 IoT 장치와 장비를 사용하는 IoT 기반 자동 착유 시스템을 도입했습니다. 센서, 고성능 카메라, 레이저 장비 및 로봇 팔과 같은 IoT 장치와 장비를 갖춘 자동 착유 시스템(AMS)은 착유 박스에 들어오는 소 식별, 유방 세척, 착유, 수집, 살균, 저장 및 우유 성분 분석을 포함한 전체 착유 과정을 수행할 수 있습니다. AMS는 파이프라인, 헤링본, 탠덤 기계 등과 같은 기존 방식과 달리 착유 이외의 작업에 노동력을 배치할 수 있게 하여 낙농장의 노동력 부족 문제를 해결하는 장점이 있습니다. 또한 AMS는 우유의 생산성과 품질을 향상시키는 동시에 소의 질병 발생률을 줄일 수 있습니다.
AMS는 다음 데이터를 생성하며, 낙농장의 종합적인 생산 및 운영 관리 전략을 수립하기 위해 이 데이터는 급이, 분만, 질병 관리 및 성장 관리와 같은 다른 목적의 데이터와 유기적인 관계로 관리되어야 합니다.
소가 착유 박스에 들어오면 착유실에 설치된 객체 식별자가 소에 부착된 RFID 태그, QR 코드 또는 바코드에서 소의 ID를 식별합니다. 이를 통해 AMS가 관리하는 착유 횟수나 우유 생산량과 같은 이력 데이터를 기반으로 착유를 더 체계적으로 수행할 수 있습니다.
그런 다음 3D 카메라, 레이저 장비 및 센서가 유방의 위치를 정확히 식별하고, 로봇 팔이 착유 컵을 유방에 빠르게 부착하여 착유를 수행합니다. 착유 전후에는 오염물질과 세균을 제거하기 위해 세척 및 소독이 수행되어야 합니다. 착유 컵에 설치된 센서는 착유 중 경과 시간과 우유 생산량을 측정합니다.
또한 지방, 단백질, 유당 등 우유의 성분을 분석하고, 분석 결과는 우유의 품질과 소의 질병 및 건강 상태를 관리하기 위해 AMS로 전송됩니다. 착유 후 우유는 우유의 신선도를 유지하기 위해 냉각 기능이 있는 우유 탱크로 전달됩니다. AMS는 전체 착유 과정에서 생성된 데이터를 수집하고, 데이터를 분석하여 낙농장의 우유 생산 전략을 수립합니다. 낙농장의 농부 또는 관리자는 웹 페이지나 모바일 앱을 통해 착유 과정을 모니터링할 수 있습니다.
자동화 시스템은 인간 개입을 최소화하도록 설계되어야 하지만, 긴급 상황에 대응하기 위해 AMS를 직접 제어할 수 있는 능력을 갖는 것이 더 바람직합니다.
RFID 리더/태그, 착유 컵, 로봇 팔, 우유 성분 분석기 및 센서와 같은 장치와 장비는 유선 또는 무선 네트워크를 통해 낙농장에 설치된 컨트롤러인 게이트웨이에 연결됩니다. 다양한 액추에이터를 제어하고 데이터를 전송하는 게이트웨이는 인터넷을 통해 클라우드 시스템에 연결됩니다. 따라서 낙농장의 모든 장치와 장비는 클라우드를 통해 접근하고 제어할 수 있습니다. 클라우드는 AMS에서 전송된 데이터를 분석하기 위해 AI 및 빅데이터와 같은 기술을 활용합니다. 분석 결과는 모든 이해관계자에게 공유 및 배포될 수 있으며, 낙농장의 생산성과 편의성을 향상시키는 다양한 새로운 서비스를 만들기 위한 기본 정보로 활용될 수 있습니다.
이 사용 사례는 보안 문제에 대한 특정 요구사항을 명시하지 않습니다. 잘 정의된 보안 관리 메커니즘은 이 사용 사례에 적용될 수 있습니다.
농부 외에도 농장 노동자, 서비스 제공자, 제조업체, 농산물 소비자, 제3자 회사 및 정부 부처와 같은 다양한 이해관계자가 낙농장 운영에 관여합니다. AMS 운영 중 생성되는 다양한 유형과 특성의 데이터는 하나 이상의 이해관계자에게 공유 및 배포될 수 있습니다.
결과적으로 데이터에 대한 접근 권한은 데이터 활용의 유형, 특성 및 목적에 따라 체계적으로 관리되어야 합니다. 이를 통해 농부의 경험, 노하우 및 고유한 농업 지식 또는 기술을 보호하고, 낙농장의 경쟁력을 확보할 수 있습니다.
AMS 운영으로 생성된 데이터와 IoT 장치 및 장비를 제어하기 위한 명령을 교환하려면 유선 또는 무선 통신 링크가 필요합니다. 소의 자유로운 움직임과 다른 농작업을 방해하지 않기 위해 무선 통신 링크 사용이 권장됩니다.
AMS용 데이터는 장치 유형 및 제조업체와 무관하게 공통 형식으로 전달 및 저장되어야 하며, AI 기반 분석 및 처리를 위해 표준화된 방식으로 표현되어야 합니다.
일반적으로 낙농장에 설치된 컨트롤러인 게이트웨이는 데이터를 수집하고 네트워크를 통해 연결된 외부 클라우드로 데이터를 전송합니다. 게이트웨이는 또한 클라우드에서 받은 제어 명령을 네트워크를 통해 다양한 액추에이터로 전달합니다. 그러나 병목, 게이트웨이와 클라우드 간의 연결 끊김 또는 클라우드의 과도한 내부 처리 시간으로 인해 데이터 손실이나 지연이 발생하면 효율적이고 안정적인 착유 작업을 수행하기 어려울 수 있습니다. 이러한 문제를 해결하기 위해, 착유를 포함한 농작업 수행에 필수적인 기능을 유지하기 위해 엣지 컴퓨팅 기술을 적용하는 것이 권장됩니다.
많은 가축 무리가 사는 좁은 공간에서 병든 가축을 다른 가축과 분리하는 어려움을 극복하기 위해 IoT 및 AI 기반 동물 건강 관리 기술이 도입되고 있습니다. 이는 가축의 행동과 건강 상태를 모니터링하고, 질병이 예상되거나 발생할 경우 빠르고 적절한 대응을 취함으로써 가축을 안전하게 유지하는 데 도움이 됩니다.
IoT 및 AI 기반 동물 건강 관리 기술은 가축 건강을 모니터링하고, 질병을 예방하며, 이를 조기에 감지하는 데 중요한 역할을 합니다. 이 기술을 통해 체온, 심박수, 호흡과 같은 생체 신호를 수집 및 분석하고 정상 범위를 설정하여 가축의 건강 상태를 실시간으로 모니터링할 수 있습니다. 비정상 데이터가 감지되면 농부에게 경고를 보내 적절한 조치를 취하도록 합니다.
또한 AI 기술은 가축의 건강 상태를 예측하는 데 사용될 수 있습니다. AI 모델을 사용하여 가축의 건강 상태와 질병 발생 사이의 관계를 분석함으로써 예방 조치를 취할 수 있도록 건강 상태에 대한 예측 결과를 제공할 수 있습니다.
이 IoT 및 AI 기반 동물 건강 관리 기술은 가축의 건강 상태를 모니터링하고, 예방 조치를 취하며, 조기 대응을 제공함으로써 가축의 건강을 유지하고 생산성을 향상시키며 질병 발생을 최소화하는 데 매우 유용합니다.
전반적으로 가축 건강 관리는 데이터 수집, 전송, 처리, 분석 및 의사결정의 복잡한 시스템을 포함합니다. 이를 사용하면 가축 건강을 개선하고, 질병 확산을 방지하며, 생산성을 높일 수 있습니다. 가축 건강 관리는 데이터 흐름의 관점에서 다음과 같이 설명할 수 있습니다.
(데이터 수집) 가축 건강 관리를 위한 데이터는 모니터링되는 가축과 축사에서 수집됩니다. 이 데이터에는 체온, 심박수, 호흡수 및 배설량과 같은 다양한 유형의 생리학적 데이터뿐 아니라 온도, 습도 및 공기 품질과 같은 환경 데이터도 포함될 수 있습니다.
(데이터 처리) 그런 다음 데이터는 클라우드 서버로 전송되기 전에 엣지 장치에서 전처리됩니다. 전처리 단계에는 전송해야 하는 데이터 양을 줄이기 위해 데이터를 정리하고, 압축하고, 기본 분석을 수행하는 작업이 포함될 수 있습니다.
(데이터 전송) 수집된 데이터는 분석을 위해 클라우드 서버로 전송됩니다. 이는 일반적으로 Bluetooth, Wi-Fi, RFID 또는 셀룰러 네트워크와 같은 무선 통신 기술을 사용하여 수행됩니다.
(데이터 분석) 클라우드 서버는 센서와 웨어러블 장치에서 수집된 데이터를 분석하기 위해 머신러닝 알고리즘과 AI 모델을 사용합니다. 분석에는 패턴 식별, 미래 건강 위험 예측, 질병 또는 질환의 초기 징후 감지가 포함될 수 있습니다.
(의사결정) 데이터 분석 결과를 기반으로, 통찰을 가진 가축 건강 관리 서비스 제공자 또는 수의사는 가축의 관리와 치료에 관한 결정을 내릴 수 있습니다. 여기에는 질병 또는 질환의 위험을 줄이기 위한 예방 조치, 약물 투여, 또는 병든 가축을 나머지 무리에서 격리하는 것이 포함될 수 있습니다. 또한 가축 건강 관리 서비스 제공자 또는 수의사는 분석 결과를 반영한 가축 건강 관리 계획을 수립합니다.
상당히 넓은 면적을 다루는 노지의 스마트 농업은 제한된 공간의 온실과 달리 트랙터, 콤바인, 제초기, 살충제 살포기와 같은 다양한 유형의 농업 기계를 필요로 합니다. 그러나 농업 기계의 비용은 일반적으로 높으므로, 이를 운영하는 데 필요한 비용과 노동력을 절약하기 위해 기계를 효율적으로 운영하고 관리하는 것이 중요합니다.
농업 기계를 효율적으로 관리하기 위해 농부는 먼저 작물의 각 성장 단계에 필요한 농작업 유형, 예상 소요 시간, 각 농작업에 필요한 기계의 유형과 수량을 반영한 농작업 계획을 수립해야 합니다. 수립된 농작업 계획을 구현함으로써, 농부는 필요한 농작업을 가능한 가장 짧은 시간에 완료하기 위해 기계를 사용할 수 있습니다. 또한 IoT에 연결된 기계는 농작업의 실시간 진행 상태를 공유할 수 있으며, 필요하면 아직 사용 중이 아닌 추가 기계를 투입하여 농작업에 필요한 시간을 줄일 수 있습니다.
농업 기계에 설치된 다양한 유형의 센서 장치는 밭의 환경 조건 및 작물 성장 상태와 관련된 데이터를 수집합니다. 수집된 데이터는 AI 기반 분석을 통해 농가의 생산성(편의성, 운영 비용)을 향상시키기 위한 최적의 생산 관리 전략 수립과 농작업 계획의 최적화 (업데이트)에 사용됩니다. 농부는 웹 또는 모바일 장치를 통해 언제 어디서나 농업 기계의 운영 상태와 농작업 진행 상황을 모니터링할 수 있으며, 영농 계획 변경이나 장비 고장 시 적절한 지시를 전송할 수도 있습니다.
농업 기계의 효율적 관리는 최적의 농작업 계획, 기계 운영 상태, 농작업 실행 결과, 오작동 또는 손상 이력과 같은 다양한 데이터의 체계적인 관리를 통해 달성됩니다. 이 데이터는 AI 및 빅데이터 기술을 기반으로 분석되어 최적의 생산 관리 전략을 수립할 수 있습니다. 이러한 일련의 절차를 통해 농장 생산성을 향상시킬 수 있습니다.
농부 또는 농업 기계 관리 서비스 제공자는 농지의 위치, 필요한 농작업 유형, 농작업 수행에 필요한 시간, 필요한 농업 기계의 유형과 가용성, 과거 농작업 실행 이력과 같은 데이터를 기반으로 농작업 계획을 수립합니다. 농작업 계획 수립은 가능한 최저 비용으로 농업 기계를 효율적으로 운영하고 관리하기 위한 기반이 되므로 매우 중요합니다. 농작업 계획을 수립하려면 농부의 요구사항이 반영되어야 하며, 필요에 따라 농업 전문가 그룹 또는 전문가 시스템의 컨설팅 결과가 통합되어야 합니다. 시스템은 누적 강수량과 같은 이력 조건을 포함하여 지역 기상 조건과 예보 같은 요소도 고려할 수 있습니다. 기계 관리는 유지보수 또는 수리가 필요할 가능성과 같은 예측된 이벤트도 고려할 수 있습니다.
수립된 농작업 계획을 기반으로 필요한 농업 기계가 배치되고 해당 농작업을 실행합니다. 농작업 과정에서 농업 기계는 운영 상태, 오작동 또는 손상 발생, 농작업 실행 상태와 그 결과, 그리고 농지 및 작물 성장 상태에 관한 데이터를 수집하고 농장 운영 시스템에 보고합니다. 농장 운영 시스템은 농작업 진행 상황을 실시간으로 모니터링할 수 있으며, 아직 배치되지 않았거나 배정된 농작업을 곧 완료할 수 있는 기계를 즉시 배치하도록 농작업 계획을 수정하여 농장의 농업 기계 운영 효율을 향상시킬 수 있습니다.
농장 운영 시스템은 수집된 데이터를 종합적으로 분석하고 이를 활용하여 기존 농작업 계획을 업데이트하고 농장 생산성 향상을 위한 생산 관리 전략을 최적화합니다. 수집되고 분석된 데이터는 서비스 제공자, 농업 기계 제조업체 및 유지보수 회사와 같은 이해관계자와 공유될 수 있습니다. 공유된 데이터를 기반으로 서비스 제공자는 농업 기계 관리 서비스의 품질을 향상시킬 수 있으며, 농업 기계 제조업체와 유지보수 회사는 농부가 요구하는 농작업에 최적화된 농업 기계를 생산하고 유지관리하기 위해 데이터를 활용할 수 있습니다. 또한 농부는 웹 또는 모바일 장치를 통해 농작업의 진행 상태와 결과를 모니터링할 수 있습니다.
위치를 동적으로 결정해야 하는 수동 이동 센서 팩, 패키지, 차량 및 자율 로봇을 포함하여 모바일 장치와 센서를 관리하는 스마트 시티.
스마트 시티는 많은 수의 모바일 장치와 센서를 추적해야 합니다. 위치 정보는 물류 또는 차량 관리 시스템과 통합될 수 있습니다. 이러한 다양한 애플리케이션에 포함할 수 있도록 공통 네트워크 인터페이스를 가진 재사용 가능한 지리 위치 모듈이 필요합니다. 실외 애플리케이션에는 GPS를 사용할 수 있지만, 실내에서는 WiFi 삼각측량이나 비전 기반 내비게이션(SLAM)과 같은 다른 지리 위치 기술이 사용될 수 있습니다. 따라서 지리 위치 정보는 기술에 구애받지 않아야 합니다.
참고: 언어 현지화와의 혼동을 피하기 위해, 실내에서도 "localization"보다 "geolocation"이라는 용어를 선호합니다.
다음 중 하나:
참고: 시스템은 위치 변경을 소비자에게 알릴 수 있어야 합니다. 이는 다른 시스템이 지오펜싱을 구현하는 데 사용될 수 있습니다. 이를 위해 알림이 전송되기 전에 장치가 이동할 수 있는 최대 거리 또는 업데이트 사이의 최대 시간과 같은 추가 매개변수가 필요할 수 있습니다. 알림은 다양한 수단으로 전송될 수 있으며, 그중 일부는 전통적인 푸시 메커니즘이 아닐 수 있습니다(예를 들어 이메일이 사용될 수 있음). 지오펜싱 애플리케이션의 경우, 장치가 펜스 경계를 알고 있을 필요는 없습니다. 이는 별도의 시스템에서 관리될 수 있습니다.
스마트 시티는 차량 또는 물류 관리 시스템의 맥락에서 사용 중인 많은 수의 모바일 장치의 물리적 위치를 관찰하거나, 대시보드 애플리케이션의 지도 위에 센서 데이터를 배치해야 할 필요가 있습니다. 이러한 시스템은 지오펜싱 알림 및 매핑(시각적 추적) 기능도 포함할 수 있습니다.
고해상도 타임스탬프는 SPECTRE 익스플로잇에서처럼 캐시 조작과 함께 사용되어 메모리의 보호된 영역에 접근하는 데 사용될 수 있습니다. 일부 지리 위치 API와 기술은 잠재적 문제가 될 수 있는 고해상도 타임스탬프를 반환할 수 있습니다. 결국 이러한 문제는 캐시 아키텍처에서 해결되겠지만, 그동안의 우회책은 타임스탬프의 해상도를 인위적으로 제한하는 것입니다.
위치는 전화나 차량처럼 특정 사람과 연결될 수 있는 장치와 함께 사용될 때 일반적으로 사적인 정보로 간주됩니다. 이는 해당 사람을 추적하고 그들의 활동이나 누구와 연관되는지(여러 사람이 동시에 추적되는 경우)를 추론하는 데 사용될 수 있기 때문입니다. 따라서 민감한 맥락에서 지리적 위치에 접근하는 API는 종종 제한되며, 사용자의 권한을 확인한 후에만 접근이 허용됩니다.
위치 데이터를 표현하기 위한 단일 표준화된 의미 어휘는 없습니다. 위치 데이터는 점 데이터, 경로, 영역 또는 체적 객체일 수 있습니다. 위치 정보는 여러 표준을 사용하여 표현될 수 있지만, TD 또는 IoT 장치가 반환한 데이터에서 위치 데이터를 읽는 독자는 위치 정보를 모호하지 않게 설명할 수 있어야 합니다.
지리 위치 데이터에는 동적(모바일 센서가 반환하는 데이터) 애플리케이션과 정적(고정 설치 위치) 애플리케이션이 모두 있습니다. 동적 위치 데이터의 경우, 데이터 스키마에 주석을 달기 위한 권장 어휘가 유용할 것입니다. 정적 위치 데이터의 경우, TD 자체에 포함될 메타데이터를 위한 표준 형식이 유용할 것입니다.
정확도와 시간은 지리 위치뿐 아니라 모든 종류의 센서에 적용되는 문제임에 유의하십시오. 그러나 GPS라는 특정 지리 위치 기술은 정확한 시간의 출처이기도 하므로 특별합니다.
데이터를 시각화하고 맥락 속에서 이해해야 하는 많은 수의 장치를 관리하는 스마트 시티.
이해관계자는 다음을 포함합니다:
스마트 시티 계획 및 의사결정을 촉진하기 위해, 스마트 시티 대시보드 인터페이스는 지리적 출처 위치가 식별된 데이터를 사용하여 도시 전체의 모든 센서 데이터를 실시간으로 보고 시각화할 수 있게 합니다.
액추에이터는 로봇을 포함할 수 있습니다. 이 경우 로봇에 새 위치로 이동하거나, 센서 패키지를 내려놓거나 가져오는 등의 명령이 주어질 수 있습니다. 그러나 홍수문, 교통 신호, 조명, 표지판 등과 같은 다른 종류의 액추에이터도 포함될 수 있습니다. 예를 들어 전자 게시판에 공공 메시지를 게시하는 것이 대시보드를 통해 가능한 작업 중 하나일 수 있습니다.
센서는 환경 및 사람과 교통 관리(밀도 수, 열화상 카메라, 자동차 속도 등)를 위한 센서를 포함할 수 있습니다. 로봇, 기타 액추에이터 및 센서의 상태, 데이터 시각화, 그리고 (선택적으로) 이력 비교.
대시보드는 매핑 기능을 포함할 것입니다. 매핑은 모든 액추에이터와 센서에 대한 위치 데이터가 필요함을 의미하며, 이는 지리 위치 센서(예: GPS)를 통해 획득하거나 설치 중 정적으로 할당될 수 있습니다.
이 사용 사례는 카메라의 이미지와 실시간 이미지 및 데이터 스트리밍도 포함합니다.
많은 수와 다양한 종류의 센서에서 나온 데이터를 단일 데이터베이스로 통합하고 정규화한 다음, 시간과 공간에 배치하고 마지막으로 시각화해야 합니다.
계획 결정을 내릴 책임이 있는 도시 관리 구성원인 사용자는 계획 결정에 적합한 지도 위에 시각화된 데이터를 봅니다.
변형:
샘플 흐름:
서비스 또는 사용자가 알려진 Middle-Node의 탐색 엔드포인트(GUI로 감쌀 수 있음)에 (SPARQL) 쿼리를 보냅니다. Middle-Node는 먼저 해당 Middle-Node에 등록된 IoT 장치의 Thing Description을 확인하여 쿼리에 답하려고 합니다. 그런 다음 쿼리에 추가 탐색이 필요하거나 성공적으로 답하지 못한 경우 Middle-Node는 자신의 *알려진* Middle-Node로 쿼리를 전달합니다. 재귀적으로, Middle-Node는 쿼리에 답하려고 하거나 알려진 Middle-Node로 쿼리를 전달합니다. 한 Middle-Node가 쿼리에 답할 수 있으면, 그 부분 쿼리 답변을 이전 Middle-Node로 되돌려 전달합니다. 마지막으로 탐색 작업이 끝나면, 이전 Middle-Node는 모든 부분 쿼리 답변을 결합하여 통합된 뷰(동기식 또는 비동기식일 수 있음)를 생성합니다.
이 사용 사례는 박물관과 같은 에너지 효율적인 문화 공간에서 신뢰할 수 있는 IoT 엔티티의 의미적 모델링과 관련됩니다.
오늘날 에너지 절약 문제는 점점 증가하는 전 세계 전력 수요로 인해 연구 커뮤니티의 관심을 불러일으켰습니다. 과도한 에너지 사용은 공공 및 산업 건물이 서비스를 제공하는 맥락에서 일상 부하 요구사항을 충족하기 위해 발생하는 것으로 여겨집니다. 따라서 에너지 효율적인 건물 개발의 필요성이 유익하다는 것이 입증될 수 있습니다. 특히 건물 에너지 효율의 개선은 Building Energy Management Systems(BEMS)로 이어집니다.
BEMS 목표는 다음을 포함하지만 이에 국한되지 않습니다:문화 공간, 특히 박물관 공간에서 에너지 절약의 맥락에서 BEMS를 적용하는 것은 최근 발전하고 있는 연구 관심사입니다. 박물관에 격리된 예술작품과 고대 객체의 보호 및 보존은 온도, 습도 및 CO2와 같은 환경 요인과 실내 조건의 지속적인 모니터링 필요성으로 이어집니다. 이 모니터링에는 Internet of Things(IoT) 엔티티가 포함되며, 이는 BEMS의 필수적인 부분으로 간주될 수 있습니다. 이를 통해 a) 인간의 방문 경험과 실내 편안함 수준을 희생하지 않고, b) 예술작품의 보호와 보존을 희생하지 않으면서 에너지 소비를 줄일 수 있습니다.
제시된 사용 사례의 목적은 지식 표현을 위한 다음 요구사항을 스케치하고 강조하는 것입니다:이 지식으로 추론하면, (방문자가 전시물에 근접한 것을 감지하고 전시물의 램프 밝기 수준을 관찰한 것을 기반으로) 흥미로운 전시물과 에너지 관련 관찰을 식별할 수 있습니다.
예를 들어 전시물 램프의 밝기 수준이 "medium"이고 전시물 근처에 방문자가 두 명보다 많으면, 이 관찰은 a) 흥미로운 전시물 관찰 및 b) 높은 수준의 에너지에 대한 관찰로 분류됩니다. 이는 이 관찰의 전시물 램프에 대한 에너지(조명) 수준을 높음으로 올려야 함을 의미합니다. 또한 (다른 예로), 전시물 램프의 밝기 수준이 "medium"이고 근처 방문자가 두 명 미만이면, 이를 낮은 수준의 에너지에 대한 관찰로 분류합니다. 이는 이 관찰의 전시물 램프에 대한 에너지(조명) 수준을 낮음으로 올려야 함을 의미합니다. 이러한 예는 관찰된 전시물의 조명(에너지) 수준에 대한 변경(감소 또는 증가)이 적용되어야 함을 나타냅니다.
Web of Things Thing Description (WoT TD): IoT 엔티티의 신뢰 표현(신뢰할 수 있는 things, 일반적으로 신뢰할 수 있는 IoT 엔티티, 즉 장치, 사람, 프로세스, 데이터). IoT-trust 관련 지식 표현(OWL)은 예시로 Kotis et al.이 제공합니다: https://github.com/KotisK/IoTontos/blob/master/Ontologies/IoT/IoT-trust-onto-v06.owl (또는 https://i-lab.aegean.gr/kotis/Ontologies/IoT/IoT-trust-onto-v06.owl).
관련 논문: Kotis, K., I. Athanasakis, and G. A. Vouros, "Semantically Enabling IoT Trust to Ensure and Secure Deployment of IoT Entities", Int. J. of Internet of Things and Cyber-Assurance, vol. 1, issue 1: Inderscience, pp. 3-21, 2018. (http://www.inderscience.com/storage/f596810317421112.pdf)
properties 속성을 포함합니다(TD의
properties와 혼동하지 말 것. 이는
PropertyAffordance 인스턴스의 Map임)
스마트 빌딩을 운영할 때, 이러한 건물의 이질적인 장치가 제공하는 모든 데이터를 집계하고 관리하는 데에는 여전히 많은 수작업 노력이 필요합니다. 여러 프로토콜에 의존하는 데이터 획득의 장애물 외에도, 획득된 데이터에는 일반적으로 그 위치와 목적에 관한 맥락 정보와 메타데이터가 부족합니다. 보통 건물 things에서 데이터를 소비하는 각 서비스 또는 애플리케이션은 그 내용과 맥락에 관한 정보가 필요합니다. 예:
건물의 전체 수명주기에 걸쳐 모델 기반 데이터 교환이 증가하면서, 흔히 Building Information Modeling(BIM) (Sacks et al., 2018)이라고 불리는 방식으로, 예를 들어 부지, 층 및 공간으로 구조화된 건물의 토폴로지를 비롯하여 건물 자체를 설명하는 데이터의 정제된 출처가 제공됩니다.
건물 안에서 데이터와 관련 things를 자동으로 추적하는 것은 특히 시운전, 운영, 유지관리 및 개보수 중에 Building Automation and Control Systems(BACS)와 Heating Ventilation and Air-Conditioning(HVAC) 서비스의 구성과 운영을 쉽게 할 것입니다. 이러한 과제에 대처하기 위해, 여전히 건물 전문가는 Building Management Systems(BMS) 데이터베이스에 수동으로 구현되는 메타데이터와 명명 규칙을 사용하여 데이터와 things에 주석을 답니다. thing의 중요한 속성은 건물의 토폴로지 안에서의 위치뿐 아니라 관련 데이터가 생성되거나 사용되는 위치입니다. 예를 들어 이는 공간의 온도 센서, 구역의 온도 설정값, HVAC 구성요소의 혼합 댐퍼 플랩 액추에이터 등에 적용됩니다. 또한 비용이나 특정 제조업체 데이터와 같은 things의 다른 속성도 관심 대상입니다. 한 가지 어려움은 특히 이 정보를 자동화된 방식으로 생성, 연결 및 공유하는 표준화된 방법의 부족입니다. 반대로 제조업체, 서비스 제공자 및 사용자는 각자의 목적을 위해 자체 메타데이터를 도입합니다. 해결책으로 Web of Things(WoT) Thing Description(TD)은 things 사이에 정규화되고 구문적인 상호운용성을 제공하는 것을 목표로 합니다.
이러한 노력을 지원하기 위해, 이 사용 사례는 스마트 빌딩의 things 사이의 의미적 상호운용성을 향상시키고 이를 건물 정보에 대한 맥락 링크와 함께 제공할 필요에 의해 동기부여됩니다. 이 건물 정보는 보통 BIM 모델에서 얻습니다. 이 사용 사례는 Web of Data 기술을 기반으로 하며 Linked Building Data 도메인에서 제공되는 스키마를 재사용합니다. 이는 Internet of Building Things(IoBT)의 많은 애플리케이션을 위한 사용 사례 템플릿 역할을 해야 합니다.
이 사용 사례의 목표는 워크플로를 자동화하고 스마트 빌딩 도메인에서 관찰되는 데이터의 이질성을 해결할 잠재력을 보여주는 것입니다. 예시는 WoT TD와 BIM에서 얻은 맥락 데이터를 결합할 때의 잠재적 이점을 보여줍니다.
이 사용 사례는 주거용 아파트의 BIM 모델과 일반적인 스마트 홈 센서가 수행한 관찰을 결합하여 소개하는 Open Smart Home Dataset을 기반으로 합니다. 우리는 일부 항목의 Thing Description으로 데이터셋을 확장합니다. 고려된 아파트의 주방에 있는 온도 센서에 대한 해당 Thing Description은 다음과 같습니다:
{
"id": "https://w3id.org/ibp/osh/OpenSmartHomeDataSet#TemperatureSensor",
"@context": [
"https://www.w3.org/2019/wot/td/v1",
{
"osh": "https://w3id.org/ibp/osh/OpenSmartHomeDataSet#",
"bot": "https://w3c-lbd-cg.github.io/bot/#",
"sosa": "http://www.w3.org/ns/sosa/",
"om": "http://www.ontology-of-units-of-measure.org/resource/om-2/",
"ssns": "https://www.w3.org/TR/vocab-ssn/",
"brick": "https://brickschema.org/schema/Brick#",
"schema": "http://schema.org"
}
],
"title": "TemperatureSensor",
"description": "Kitchen Temperature Sensor",
"@type": ["sosa:Sensor", "brick:Zone_Air_Temperature_Sensor", "bot:element"],
"@reverse": {
"bot:containsElement": {
"@id": "osh:Kitchen"
}
},
"securityDefinitions": {
"basic_sc": {
"scheme": "basic",
"in": "header"
}
},
"security": [
"basic_sc"
],
"properties": {
"Temperature": {
"type": "number",
"unit": "om:degreeCelsius",
"forms": [
{
"href": "https://kitchen.example.com/temp",
"contentType": "application/json",
"op": "readproperty"
}
],
"readOnly": true,
"writeOnly": false
}
},
"sosa:observes": {
"@id": "osh:Temperature",
"@type": "sosa:ObservableProperty"
},
"ssns:hasSystemCapability": {
"@id": "osh:SensorCapability",
"@type": "ssns:SystemCapability",
"ssns:hasSystemProperty": {
"@type": ["ssns:MeasurementRange"],
"schema:minValue": 0.0,
"schema:maxValue": 40.0,
"schema:unitCode": "om:degreeCelsius"
}
}
}
여기서 센서의 측정 범위에 관한 맥락 정보는 SSNS 스키마를 사용하여 지정됩니다. thing TemperatureSensor의 위치 정보는 의미 웹에서 건물 토폴로지를 설명하기 위해 W3C Linked Building Data Community Group (W3C LBD CG)이 개발한 최소 온톨로지인 Building Topology Ontology (BOT)를 기반으로 제공됩니다. 추가로 해당 액추에이터의 thing description은 아래에 제공됩니다.
{
"id": "https://w3id.org/ibp/osh/OpenSmartHomeDataSet#TemperatureActuator",
"@context": [
"https://www.w3.org/2019/wot/td/v1",
{
"osh": "https://w3id.org/ibp/osh/OpenSmartHomeDataSet#",
"bot": "https://w3c-lbd-cg.github.io/bot/#",
"sosa": "http://www.w3.org/ns/sosa/",
"ssn": "http://www.w3.org/ns/ssn/",
"brick": "https://brickschema.org/schema/Brick#"
}
],
"title": "TemperatureActuator",
"description": "Kitchen Temperature Actuator",
"@type": ["sosa:Actuator", "brick:Zone_Air_Temperature_Setpoint", "bot:element"],
"@reverse": {
"bot:containsElement": {
"@id": "osh:Kitchen"
}
},
"securityDefinitions": {
"basic_sc": {
"scheme": "basic",
"in": "header"
}
},
"security": [
"basic_sc"
],
"actions": {
"TemperatureSetpoint": {
"forms": [
{
"href": "https://kitchen.example.com/tempS"
}
]
}
},
"ssn:forProperty": {
"@id": "osh:Temperature",
"@type": "sosa:ActuatableProperty"
}
}
고려된 시나리오는 BACS에서 온도 센서를 교체하는 것과 관련됩니다. things를 위치시키는 토폴로지 정보, 예를 들어 온도 센서는 새로 교체된 센서를 자동으로 시운전하고 기존 제어 알고리즘과 연결하는 데 사용할 수 있습니다. 이를 위해 적합한 센서와 액추에이터의 식별자가 필요하며, 예를 들어 SPARQL을 통해 쿼리될 수 있습니다. 여기서 쿼리는 Brick schema v1.1 [Brick]의 센서에 대한 일부 추가 분류를 사용합니다.
PREFIX bot: <https://w3id.org/bot>
PREFIX brick: <https://brickschema.org/schema/Brick#>
PREFIX osh: <https://w3id.org/ibp/osh/OpenSmartHomeDataSet#>
SELECT ?sensor ?actuator
WHERE{
?space a bot:Space .
?space bot:containsElement ?sensor .
?space bot:containsElement ?actuator .
?sensor a brick:Zone_Air_Temperature_Sensor .
?actuator a brick:Zone_Air_Temperature_Setpoint .
}
유사하게 이 데이터는 HTTP 프로토콜 위에 구축된 REST API를 통해 얻을 수 있습니다. 아래는 특정 공간 이름에 대해 동일한 정보를 가져오기 위해 REST 스타일을 적용하는 예제 엔드포인트입니다:
GET "https://server.example.com/api/locations?space=osh:Kitchen&sensorType=brick:Zone_Air_Temperature_Sensor&actuatorType=brick:Zone_Air_Temperature_Setpoint"
API response:
{
"location": {
"site": {
"id": "https://w3id.org/ibp/osh/OpenSmartHomeDataSet#Site1",
"name": "Site1"
},
"building": {
"id": "https://w3id.org/ibp/osh/OpenSmartHomeDataSet#Building1",
"name": "Building1"
},
"zone": null,
"storey": {
"id": "https://w3id.org/ibp/osh/OpenSmartHomeDataSet#Level2",
"name": "Level2"
},
"space": {
"id": "https://w3id.org/ibp/osh/OpenSmartHomeDataSet#Kitchen",
"name": "Kitchen"
},
"sensors": [
"https://w3id.org/ibp/osh/OpenSmartHomeDataSet#TemperatureSensor"
],
"actuators": [
"https://w3id.org/ibp/osh/OpenSmartHomeDataSet#TemperatureActuator"
]
}
이 예제 쿼리에서 REST 엔드포인트는 OpenAPI specification을 사용하여 정의되었으며 RESTful 서버에서 제공됩니다. 서버와 기반 백엔드 저장소, 여기서는 관련 온톨로지(osh, bot, ssn, brick...)를 포함하는 트리플 저장소 사이에 데이터 바인딩이 필요합니다. 데이터 바인딩은 위에 표시된 것과 유사한 SPARQL 쿼리에 의존합니다. 결과적으로 엔드포인트는 트리플이 아닌 사용자 정의 JSON을 소비하는 대상 애플리케이션에 정보를 전달할 수 있습니다. 유사한 구현은 GraphQL을 사용하여 달성될 수도 있습니다.
스마트 빌딩의 또 다른 관련 사용 사례는 조화된 thing description과 연결된 위치 정보에서 큰 이점을 얻을 수 있으며, 이는 예기치 않은 동작, 오류 및 결함 감지와 관련됩니다. 이러한 결함 감지의 예는 센서 값의 규칙 기반 감시입니다. 센서에 적용 가능한 일반 규칙은 관찰 값이 센서의 측정 범위 안에 유지된다는 것입니다. 다시 위에서 설명한 유지관리의 경우처럼 센서가 교체됩니다.
결함 감지 규칙을 구성하는 어떤 에이전트는 센서의 TD(위 참조)에서 측정 범위를 얻어 언급된 규칙을 구성하기 위한 매개변수를 얻을 수 있습니다. 다시, 이 정보(schema:minValue/ schema:maxValue)를 가져오는 쿼리 또는 API 호출을 사용하여 센서가 제공하는 값의 상한과 하한을 업데이트할 수 있습니다.
스마트 빌딩에서 보안은 중요합니다. 특히 접근 제어는 적절히 보호되어야 합니다. 이는 기존 보안 스킴(API Keys, OAuth2...)을 사용하여 보호할 수 있는 데이터 접근에도 적용됩니다. 또한 전기 소비와 같은 특정 관찰로부터 주거지 내 존재 여부와 같은 단서가 간접적으로 제공될 수 있습니다. 따라서 보안 요구는 정의되고 적절히 다루어져야 합니다.
센서의 관찰이 개인과 연결될 수 있는 경우 개인정보 보호 고려사항이 문제가 될 수 있습니다. 데이터에 대한 자체 개인정보 보호 정책을 정의하고 필요한 경우 필요한 동의를 공유하는 것은 건물 소유자, 관리자 및 사용자의 책임입니다.
접근성은 건물 도메인에서 주요 관심사입니다. 접근성 데이터를 전자 형식으로 제공하려는 노력도 존재합니다. W3C LBD CG는 W3C Linked Data for Accessibility Community Group과 연락하고 있습니다.
건물 산업은 글로벌 산업이므로 국제화는 관심사입니다. 이는 몇몇 노력에 반영되어 있으며, 예를 들어 위의 예에서 사용된 BOT는 영어, 프랑스어 및 중국어를 포함하여 최대 16개의 서로 다른 언어로 다국어 레이블을 제공합니다.
이러한 환경에서 장치는 보통 상용 기성 IoT 장치가 아니라, 더 큰 시스템을 대신하여 물리적 작업을 수행하는 "패키지 유닛" 및 기타 "하위 수준" 장치입니다: 펌프, 팬, 가변 주파수 드라이브, 가변 풍량 박스 및 냉각기가 모두 예입니다. 이러한 장치는 전선, 파이프, 덕트 및 기타 메커니즘을 사용하여 서로 연결됩니다. 센서, 액추에이터 및 기타 데이터 출처와 싱크는 이러한 하위 시스템의 장치와 연결됩니다. 어떤 디지털 제어 시스템을 통해, 이들은 현재 동작, 상태 및 장치 성능, 그리고 건물 하위 시스템이 접촉하는 물질과 매체의 속성에 관한 원격 측정 데이터를 전달합니다.
이러한 시스템의 설명은 건물 하위 시스템의 장비와 기타 장치에 대해 표준화되고 잘 알려진 이름을 기반으로 구축되는 것이 중요합니다. 일반 용어에 의존하는 것만으로는 서로 다른 종류의 시스템과 서로 다른 종류의 장비를 광범위하게 일관되고 해석 가능한 방식으로 구분하기에 충분하지 않습니다. 연구와 실무는 사이버-물리 시스템의 내부를 다루는 데이터 기반 애플리케이션의 개발 및 배포와 관련된 비용을 줄이기 위해 공통 용어가 수립되어야 함을 보여줍니다.
이 사용 사례를 지원하기 위해, WoT description은 건물 하위 시스템에 존재하는 네트워크 장치와 그 데이터 능력을 설명해야 합니다. 이러한 능력은 장치가 작동하는 물질 또는 매체의 속성과 관련되어야 합니다. 예를 들어, 스마트 온도조절기의 API는 "mode"를 읽기 전용 속성으로 제공할 수 있습니다. "Mode"는 보통 온도조절기가 "요구하는" 것, 예를 들어 냉방, 난방, 팬을 의미하며, 이는 일반적으로 숫자 값으로 포착됩니다. mode는 루프탑 유닛과 같은 HVAC 장비가 읽으며, 그 장비는 원하는 조절을 실행합니다. mode 속성의 WoT description은 mode 속성의 값에 의해 건물 안의 다른 장치와 엔티티의 어떤 속성이 영향을 받을 수 있는지 결정할 수 있게 해야 합니다. 이 예에서 mode 속성 표현은 mode 속성이 온도조절기가 제어하는 장비와 연결된 방 안 공기의 온도에 간접적으로 영향을 미친다는 것을 나타내야 합니다.
예제: Rogue Zone Detection
"Rogue zones"는 다른 구역보다 훨씬 더 많이 난방 또는 냉방을 요구하여 수요를 유발하는 건물의 영역입니다. rogue zone을 감지하는 간단한 방법 중 하나는 여러 방으로 구성될 수 있는 구역이 어떤 delta보다 크게 설정값보다 지속적으로 높거나 낮은지를 관찰하는 것입니다. 다음 SPARQL 쿼리는 Brick을 사용하여 terminal unit과 연결된 공기 온도 설정값과 센서를 식별하고, 해당 terminal unit이 공급하는 구역을 식별합니다.
PREFIX brick: <http://brickschema.org/schema/Brick#>
SELECT ?term ?zone ?sat ?sp WHERE {
?term a brick:Terminal_Unit .
?zone a brick:HVAC_Zone .
?sat a brick:Supply_Air_Temperature_Sensor .
?sp a brick:Supply_Air_Temperature_Setpoint .
?term brick:feeds ?zone .
?term brick:hasPoint ?sat, ?sp .
}예제: 냉각 코일 전후의 온도 측정
일반적인 결함 감지 및 진단 작업은 고장 나거나 성능이 저하된 냉각 코일을 감지하는 것입니다. 이는 냉수가 흐르는 속이 빈 루프이며, 공기를 냉각하기 위해 공기 흐름 안에 배치됩니다. 코일을 통과하는 냉수의 흐름은 밸브로 제어됩니다. 코일이 고장 났거나 성능이 저하되었는지 확인하기 위해 코일 전과 후의 공기 온도를 측정합니다. 밸브가 열려 있는 동안 코일 후의 온도가 코일 전의 온도보다 눈에 띄게 낮지 않다면, 코일에 결함이 있을 수 있습니다.
PREFIX brick: <http://brickschema.org/schema/Brick#>
SELECT ?ahu ?mat ?sat ?pos ?room WHERE {
?ahu a brick:AHU .
?sat a brick:Supply_Air_Temperature_Sensor .
?mat a brick:Mixed_Air_Temperature_Sensor .
?ccv a brick:Cooling_Valve .
?pos a brick:Position_Sensor .
?room a brick:Room .
?ahu brick:hasPoint ?mat, ?sat .
?ahu brick:hasPart ?ccv .
?ccv brick:hasPoint ?pos .
?ahu brick:feeds+/brick:hasPart? ?room .
}매우 유용한 기능은 장치 상태, 알람 및 기타 다중 값 속성의 표준 열거형에 대한 의미적 설명일 것입니다. 한 예는 위의 온도조절기 mode의 숫자 인코딩(예: "0 means off", "1 means 1-stage heat" 등)입니다.
많은 의미는 제조업체와 모델 전반에서 표준입니다. 이는 사용자가 접근할 수 있어야 하는 잘 알려진 업계 표준 속성을 설명하지만 서로 다른 방식으로 인코딩되기 때문입니다. 표준화된 오류 코드, 장치 상태 등을 참조할 수 있는 능력은 공급업체에 구애받지 않는 데이터 처리를 가능하게 하는 데 큰 진전이 될 것입니다.
산업 제조를 위한 생산 라인은 여러 기계로 구성되며, 각 기계는 다양한 값에 대한 센서를 포함합니다. 단일 기계의 고장은 결함 제품을 발생시키거나 전체 생산의 중단을 초래할 수 있습니다.
빅데이터 분석은 전체 생산 공장의 여러 생산 라인과 여러 공장에 걸친 행동 패턴을 식별할 수 있게 합니다.
이 분석 결과는 원자재 소비 최적화, 생산 라인과 공장의 상태 확인, 결함 조건의 예측 및 예방에 사용될 수 있습니다.
한 회사가 여러 생산 라인을 포함하는 여러 공장을 소유합니다. 예로는 생산 라인과 환경 센서가 있습니다. 이러한 장치는 여러 센서에서 데이터를 수집하고 이 정보를 클라우드로 전송합니다. 센서 데이터는 클라우드에 저장되며, 머신러닝 / AI를 사용하여 시각화하고 분석할 수 있습니다.
클라우드 서비스는 단일 장치와 장치 그룹을 관리할 수 있습니다. 여러 장치의 데이터 스트림을 결합하면 사용자의 영역 안에 연결된 모든 장치의 상태를 쉽게 개괄할 수 있습니다.
많은 경우 같은 종류의 장치 그룹이 있으므로, 장치 간 데이터 집계는 이상을 식별하거나 임박한 장애를 예측하는 데 사용될 수 있습니다.
클라우드 서비스는 단일 장치와 장치 그룹을 관리할 수 있으며 비정상 조건을 식별하는 데 도움이 될 수 있습니다. 이를 위해 사용자가 규칙 집합을 정의할 수 있으며, 이 규칙을 기반으로 사용자에게 경고를 발생시키거나 장치에서 동작을 트리거합니다.
이는 잠재적 문제의 조기 감지를 가능하게 하고, 기계 장애, 품질 문제 또는 환경이나 인간 생명에 대한 위협의 위험을 줄입니다. 또한 생산 효율을 높이고 원자재 배송과 생산 산출물과 같은 생산 물류를 개선합니다.
여러 장치를 공통 소매 워크플로(즉, 거래 로그)에 통합하고 상호연결하면 여러 수준에서 소매 비즈니스 운영을 크게 개선합니다. 이는 이전에는 의미 있는 방식으로 가능하지 않거나 실현 가능하지 않았던 소비자 행동 및 환경 정보를 포함한 운영 가시성을 제공합니다.
이는 운영 문제의 근본 원인 분석 과정을 크게 가속화하고 소매업체의 업무를 단순화합니다.
참고 1: 시스템은 열 감지를 소비자(예: 보안 담당자)에게 알릴 수 있어야 합니다. 이는 이메일, SMS 또는 MQTT 발행과 같은 다른 메커니즘일 수 있습니다.
참고 2: 이미지가 캡처되는 모든 경우에는 개인정보 보호 고려사항이 적용됩니다.
통계 목적으로 고유 개인을 세는 것도 유용하겠지만, 반드시 특정 사람을 식별하는 것에 기반할 필요는 없습니다. 이는 같은 사람을 여러 번 세는 것을 피하기 위한 것입니다.
Physiological Closed-Loop Control (PCLC) 장치는 생리학적 센서의 피드백을 사용하여, 임상의가 일반적으로 제공하는 치료 전달을 통해 생리학적 변수를 자율적으로 조작하는 새로운 기술군입니다.
PCLC가 없는 임상 시나리오. 말기 신부전을 가진 고령 여성에게 혈당을 관리하기 위한 표준 인슐린 주입 프로토콜이 제공되었지만 포도당은 제공되지 않았습니다. 혈당은 33까지 떨어졌고, 포도당을 제공한 후 200을 넘어 반등했습니다. 이 시나리오는 수십 년 동안 변하지 않았습니다.
ICU에서 PCLC가 구현된 바람직한 상태. 환자는 IV 인슐린 주입을 받고 있으며 혈당은 지속적으로 모니터링됩니다. 측정되는 실시간 혈당 수준에 따라 주입 펌프 속도가 자동으로 조정되어 혈당 값을 목표 범위 안에 유지합니다. 환자의 포도당 수준이 인슐린 투여 변경에 적절히 반응하지 않으면 임상 직원에게 경고가 전달됩니다.
의료 장치는 서로 자율적으로 상호작용하지 않습니다 (모니터, 인공호흡기, IV 펌프 등). 맥락이 풍부한 데이터는 획득하기 어렵습니다. 의료 오류를 줄이고 효율성을 향상시키는 기술과 표준은 현장이나 가정에서 구현되지 않았습니다.
최근 몇 년 동안 연구자들은 기계적 환기, 마취 전달 애플리케이션 등을 위한 PCLC 장치 개발에서 진전을 이루었습니다. 이러한 약속과 잠재적 이점에도 불구하고, PCLC 장치를 bench to bedside로 전환하는 데에는 제한적인 성공만 있었습니다. PCLC 장치를 인간 임상 시험에 필요한 수준으로 가져오는 데 있어 핵심 과제는 장치의 신뢰성과 안전성을 보장하기 위한 위험 관리입니다.
미국 식품의약국(FDA)은 PCLC 장치가 도입할 수 있는 새로운 위험을 세 범주로 분류합니다. 임상적 요인 (예: 센서 유효성 및 신뢰성, 환자 간 및 환자 내 생리학적 변동성)과 사용성/인적 요인(예: 상황 인식 상실, 오류 및 작동 실수) 외에도, 견고성, 가용성 및 통합 문제를 포함한 공학적 과제도 있습니다.
상호연결되고 동적으로 구성 가능한 의료 시스템의 보안 고려사항은 [HIPAA]와 같은 법률이 이를 요구하기 때문만이 아니라, 보안 공격이 환자에게 심각한 안전 결과를 초래할 수 있기 때문에 중요합니다. 시스템은 시스템 구성요소가 임상 맥락에서 의도된 대로 사용되고 있는지, 구성요소가 진정하며 해당 환경에서 사용하도록 인가되었는지, 병원의 생의학 공학 직원에게 승인되었는지, 그리고 규제상 안전성과 유효성 요구사항을 충족하는지를 자동으로 검증할 수 있어야 합니다.
보안 및 안전상의 이유로, ICE F2761-09(2013) 준수 의료 장치는 서로 직접 상호작용하지 않습니다. 모든 상호작용은 애플리케이션을 통해 조정되고 제어됩니다.
TLS와 같은 전송 수준 보안은 외부 공격자에 대해 합리적인 보호를 제공하지만, 같은 보호된 링크 안에서 발생하는 데이터 스트림에 대한 세분화된 접근 제어 메커니즘은 제공하지 않습니다. 전송 수준 보안은 또한 보안과 성능 사이의 균형을 맞추기에 충분히 유연하지 않습니다. 널리 사용되는 전송 수준 보안 솔루션의 또 다른 문제는 멀티캐스트 지원 부족입니다.
MDIRA는 열악한 환경과 전통적인 임상 환경의 외상 및 중환자 치료에 초점을 맞춘 MDIRA 준수 시스템을 위한 요구사항과 구현 지침을 제공합니다. Johns Hopkins University Applied Physics Laboratory (JHU-APL)는 미군과 협력하여 민간 의료 시스템에도 이중 용도로 사용되는 군 의료를 위한 자율/폐쇄 루프 프로토타입 프레임워크를 개발하는 연구 프로젝트를 주도했습니다.
예상 데이터에는 디지털 현미경이 생성한 2D 및 3D 스트림과 그 녹화가 포함됩니다. 이러한 스트림은 데이터의 순간 배율과 시간 척도를 설명하는 메타데이터를 포함할 수 있습니다. 예상 데이터에는 서비스가 생성한 출력 스트림도 포함됩니다. 이러한 스트림은 예를 들어 주석 데이터를 포함할 수 있습니다.
비디오 스트림에 주석을 다는 것과 관련하여, 고유하게 식별된 bounding box 또는 의미적 데이터 (예: 메타데이터나 주석)를 또 다른 보조 트랙을 사용하여 첨부할 공간 영역을 정의하는 더 복잡한 실루엣을 가진 보조 비디오 트랙을 사용할 수 있습니다. 유사한 접근은 포인트 클라우드 기반 및 메시 기반 애니메이션에도 적용될 수 있습니다.
혼합 현실 협업 공간은 사용자가 데이터를 시각화하고 상호작용하며, 여러 위치에서 공유 작업과 프로젝트를 함께 수행할 수 있게 합니다.
디지털 현미경은 WoT 아키텍처와 표준을 통해 혼합 현실 협업 공간에서 접근되고 활용될 수 있습니다. 이렇게 디지털 현미경은 생의학, 과학 및 교육 전반에서 활용될 수 있습니다. 디지털 현미경의 데이터는 서비스에 의해 처리되어 사용자에게 유용한 출력을 생성할 수 있습니다. 사용자는 하나 이상의 이러한 서비스를 선택하고 구성하여 스트리밍 데이터 또는 녹화를 이를 통해 라우팅하고, 결과 데이터를 혼합 현실 협업 공간에서 소비할 수 있습니다. 이러한 서비스의 그래프 또는 네트워크를 사용자가 만들 수 있습니다. 서비스는 또한 디지털 현미경과 다시 통신하여 그 메커니즘과 설정을 제어할 수 있습니다. 디지털 현미경 데이터를 동시에 처리하고 해당 장치를 제어하기 위해 다시 통신하는 서비스는 사용자에게 자동 초점, 배율 및 추적을 제공하는 데 유용할 수 있습니다.
컴퓨터 비전 관련 서비스가 제공하는 출력 데이터를 사용하여 디지털 현미경 콘텐츠를 위한 멀티모달 사용자 인터페이스를 동적으로 생성할 수 있습니다. 이러한 동적 멀티모달 사용자 인터페이스는 사용자가 포인팅과 음성 자연어를 사용하여 초점을 맞추거나 확대하거나 추적하고 싶은 콘텐츠를 정확히 지정할 수 있는 수단을 제공할 수 있습니다.예를 들어 디지털 현미경은 살아 있는 동물 세포의 2D 또는 3D 영상을 확대하고 스트리밍할 수 있습니다. 이 데이터는 컴퓨터 비전 관련 주석을 제공하는 서비스에 의해 처리되어 세포의 일부, 즉 세포핵, 골지체, 리보솜, 소포체, 미토콘드리아 등을 라벨링할 수 있습니다. 알고리즘으로 생성된 주석이 있는 결과 시각 콘텐츠는 이후 사용자와 상호작용할 수 있습니다. 사용자는 포인팅과 음성 자연어를 사용하여 디지털 현미경이 초점을 맞추거나 확대하거나 추적하기를 원하는 살아 있는 동물 세포의 부분을 정확히 지정할 수 있습니다.
현재 WoT 표준 또는 빌딩 블록에서 다루지 않는 요구사항에는 3D 디지털 현미경 데이터와 녹화를 위한 스트리밍 프로토콜 및 형식이 포함됩니다. 디지털 현미경이 다양한 기존 프로토콜과 형식을 사용하여 비디오를 스트리밍할 수는 있지만, 포인트 클라우드와 메시 같은 다른 형태의 3D 데이터 및 애니메이션 스트리밍은 권고안을 통해 촉진될 수 있습니다.
사용자는 하나 이상의 서비스를 선택하고 구성하여 디지털 현미경에서 스트리밍되는 데이터를 이를 통해 라우팅하고, 결과 데이터를 혼합 현실 협업 공간에서 소비할 수 있습니다. 추가로, 서비스는 디지털 현미경의 메커니즘과 설정을 다시 통신하고 제어하도록 설계될 수 있습니다. 현재 WoT 표준 또는 빌딩 블록에서 다루지 않는 요구사항에는 서비스를 상호연결하는 수단이 포함됩니다. 아마도 서비스는 WoT 아키텍처를 활용할 수 있으며, 서비스 사이의 데이터 연결을 설정하는 기능을 포함하여 기능을 제공하는 WoT things 또는 가상 장치로 설명될 수 있습니다.
스마트 시티: 도로, 대중교통 및 통근, 자율 및 인간 운전 차량, 교통 추적 및 제어 시스템, 경로 정보 시스템, 통근 및 대중교통, 차량, 온디맨드 교통, 자율주행 차량군, 차량 정보 및 제어 시스템, 인프라 공유 및 결제 시스템, 스마트 주차, 스마트 차량 정비, 비상 모니터링 등을 관리합니다.
운송 회사: 자동화 시스템을 포함하여 해운, 항공 화물, 철도 화물 및 라스트 마일 배송 운송 시스템을 관리합니다.
통근자: Mobility as a service, 예약 시스템, 경로 계획, 승차 공유, 자율주행, 자가 정비 인프라 등.
여러 이해관계자가 소유한 다양한 시스템 사이의 더 쉬운 상호운용성을 위해, 하위 범주 전반에서 재사용할 수 있는 교통 관련 서비스와 솔루션을 설명하는 공통 어휘를 제공합니다.
Thing model은 여러 시스템 간의 통합 또는 상호작동을 돕기 위해 많은 하위 도메인에서 정의될 수 있습니다.
수직 시스템 사이의 상호운용성을 향상시킴으로써, 상품 운송은 전역 수준에서 최적화될 수 있습니다.
홈 스마트 장치는 TV 프로그램에 따라 동작합니다.
TV의 Hybridcast 애플리케이션은 스마트 홈 장치를 위한 TV 프로그램 정보를 방출합니다. (Hybridcast는 일본의 Integrated Broadcast-Broadband 시스템입니다. Hybridcast 애플리케이션은 Hybridcast TV에서 동작하는 HTML5 애플리케이션입니다.)
Hybridcast Contact 애플리케이션은 정보를 수신하고 스마트 홈 장치를 제어합니다.
장치의 소비자로서, 특정 장치 클래스에 부합하는 어떤 장치에서든 데이터를 처리할 수 있기를 원합니다.
이 장치 클래스에 부합하는 Thing의 모든 affordance와 올바르게 상호작용할 수 있다는 보장을 원합니다. 같은 description의 서로 다른 구현 사이에 동작 모호성이 있어서는 안 됩니다.
즉시 사용할 수 있게, 다시 말해 거의 제로 구성 작업으로 이를 기존 시나리오에 통합하고 싶습니다.
Web of Things의 가장 강력한 기능 중 하나는 Thing Description(TD)이 추상 인터페이스를 제공할 수 있다는 점입니다. 이 추상화는 장치 기능이 변경되거나, 장치 공급자가 변경되거나, 새로운 계산 기능이 사용 가능해질 때도 일정하게 유지될 수 있습니다.
"Virtual Thing"은 TD를 준수하는 장치의 소프트웨어 시뮬레이션을 의미합니다. 해당 TD는 같은 TD가 정의하는 물리적 thing과 유사할 수도 있고 유사하지 않을 수도 있는 입력에서 소프트웨어로 생성된 affordance를 설명합니다.
이러한 입력은 대부분(항상 그런 것은 아니지만) 데이터 스트림을 의미하며, 이를 지능형 소프트웨어(AI)로 검사하면 실제 물리적 장치가 일반적으로 제공하는 properties, actions 및 events를 해당 소프트웨어가 모방할 수 있습니다.
단순한 경우에는 소프트웨어가 새로운 문 센서 제품(아마도 새로운 제조업체의 제품)의 데이터를 해석하고, 더 오래된 장치가 지원하던 actions, properties 및 events를 모방할 수 있습니다. 이 능력은 소비 소프트웨어가 변경되지 않고 생태계에 새 장치를 도입함으로써 발생하는 변동으로부터 격리될 수 있게 합니다. 소비 소프트웨어는 원래 Thing Description을 인터페이스 정의로 계속 사용합니다.
더 복잡한 경우에는 데이터 스트림을 소프트웨어에서 처리하여 물리적 장치를 모방할 수 있습니다. 이러한 "virtual things"는 원래 Thing Description을 소비하도록 구축된 소프트웨어를 완전히 다시 작성하도록 강제하지 않고도 감지 하드웨어를 업그레이드할 수 있게 합니다(이 경우 비디오 카메라 장치로). 또한 데이터 스트림을 사용하여 여러 "virtual things"를 모방하고, 더 오래된 것들과 나란히 새로운 Thing Description도 지원할 수 있습니다.
기존 Thing Description을 "virtual things"를 위한 추상화로 사용할 수 있으면, 장치 자산을 보유한 사람들이 해당 자산의 소프트웨어와 하드웨어를 유지관리하는 데 상당한 시간과 노력을 절약할 수 있습니다.
예상 결과:
소매업체는 새로운 기능을 사용할 수 있게 될 때 소프트웨어를 다시 작성하는 비용을 피하고 싶어하며, 새롭고 더 강력한 TD를 도입하는 동안에도 기존 기능을 유지하고 싶어합니다.
비디오 카메라는 기존 TD로 정의된 다양한 "virtual things"를 모방하도록 처리될 수 있는 데이터 스트림을 생성합니다. 그러한 TD 중 하나가 "door sensor"입니다. 비디오 데이터 스트림은 문이 열렸는지 닫혔는지를 인식하도록 처리될 수 있으며, 처리 소프트웨어는 문이 열렸거나 닫혔을 때 "doorOpen" boolean events를 방출할 수 있고, 문이 너무 오래 열려 있으면 "doorOpenPastLimit" events도 방출할 수 있습니다. 원래 문 센서 TD를 이해하도록 설계된 모든 소비 소프트웨어는 이 더 고급 카메라 하드웨어에서도 계속 작동하여, 소매 관리의 물류적 과제를 제거하고 비용을 줄입니다.
디지털 트윈은 기계, 차량, 로봇, 센서와 같은 물리적 자산의 가상 표현입니다. 디지털 트윈을 사용하면 기업은 물리적 자산을 분석하여 실시간으로 문제를 해결하고, 향후 문제를 예측하며, 다운타임을 최소화하고, 새로운 비즈니스 기회를 만들기 위한 시뮬레이션을 수행할 수 있습니다.
디지털 트윈은 twin 또는 shadow라고도 불릴 수 있습니다. 디지털 트윈 기술은 장치 가상화라고 불릴 수 있습니다.
디지털 트윈은 엣지 또는 클라우드에 위치할 수 있습니다.
센서, 기계, 차량, 생산 라인, 산업용 로봇과 같은 다양한 장치.
엣지 또는 클라우드의 디지털 트윈 플랫폼.
가상 트윈은 물리적 장치 또는 자산의 표현입니다. 가상 트윈은 관찰된 속성 값과 원하는 속성 값을 포함하는 모델을 사용하며, 장치 동작의 의미 모델도 사용합니다.
간헐적 연결: 애플리케이션은 물리적 자산에 연결하지 못할 수 있습니다. 이러한 시나리오에서 애플리케이션은 마지막으로 알려진 상태를 가져오고 다른 자산의 운영 상태를 제어할 수 있어야 합니다.
프로토콜 추상화: 일반적으로 장치는 IoT 네트워크에 연결하기 위해 다양한 프로토콜과 방법을 사용합니다. 사용자 관점에서 이러한 복잡성은 enterprise resource planning(ERP) 애플리케이션과 같은 다른 비즈니스 애플리케이션에 영향을 주어서는 안 됩니다.
비즈니스 규칙: 사용자는 의미 모델에서 property의 정상 작동 범위를 지정할 수 있습니다. 비즈니스 규칙은 선언적으로 정의될 수 있고, actions는 엣지 또는 장치에서 자동으로 호출될 수 있습니다.
예: 연결된 차량군에서 사용자는 연료 수준, 위치, 속도 등과 같은 운영 매개변수 집합을 모니터링합니다. 의미 기반 가상 트윈 모델은 운영 매개변수가 정상 범위에 있는지 사용자가 판단할 수 있게 합니다. 범위를 벗어난 조건에서는 사용자가 적절한 조치를 취할 수 있습니다.
예측 트윈에서 디지털 트윈 구현은 머신러닝 기법을 사용하여 예측을 위한 분석 또는 통계 모델을 구축합니다. 이는 기계의 원래 설계자를 포함할 필요가 없습니다. 이는 정적이고 복잡하며 지속적으로 변화하는 환경에 적응하지 못하고 기계의 원래 설계자만 만들 수 있는 물리 기반 모델과 다릅니다.
데이터 분석가는 기계의 외부 관찰을 기반으로 쉽게 모델을 만들 수 있으며, 사용자의 요구에 기반하여 여러 모델을 개발할 수 있습니다. 모델은 전체 비즈니스 시나리오를 고려하고 분석과 예측을 위한 맥락 데이터를 생성합니다.
모델이 기계의 미래 문제 또는 미래 상태를 감지하면, 사용자는 이를 예방하거나 이에 대비할 수 있습니다. 사용자는 예측 트윈 모델을 사용하여 맥락적 기계 데이터에서 추세와 패턴을 판단할 수 있습니다. 모델은 비즈니스 문제 해결에 도움이 됩니다.
트윈 프로젝션에서는 예측과 통찰이 백엔드 비즈니스 애플리케이션과 통합되어, IoT를 비즈니스 프로세스의 필수적인 부분으로 만듭니다. 프로젝션이 비즈니스 프로세스와 통합되면, remedial business workflow를 트리거할 수 있습니다.
예측 데이터는 기계 운영에 대한 통찰을 제공합니다. 이러한 통찰을 백엔드 애플리케이션 인프라로 투영하면 비즈니스 애플리케이션이 IoT 시스템과 상호작용하고 지능형 시스템으로 변환될 수 있습니다.
이 사용 사례에서 다루는 사용자 시나리오는 여러 개입니다.
스마트 홈 환경의 한 예는 햇빛, 사람의 존재, 달력과 시계 등과 같은 센서 데이터를 기반으로 가정의 램프, 에어컨, 난방, 창문 블라인드를 자동으로 제어하는 것입니다.
산업 환경에서는 개별 액추에이터와 생산 장치가 서로 다른 프로토콜을 사용합니다. 예로는 MQTT [MQTT], OPC UA [OPC UA], Modbus [Modbus], Fieldbus 등이 있습니다. 디지털 트윈이나 빅데이터 사용 사례를 지원하기 위해 이러한 장치에서 데이터를 수집하려면, 이러한 프로토콜을 연결하는 "Agent"가 필요합니다. 상호운용성을 제공하고 이 agent의 구현 복잡성을 줄이기 위해, 상호작동하는 모든 장치가 공통의 (최소 및 최대) 요구사항 집합을 지원해야 합니다.
스마트 시티 환경은 장치 상호운용성 측면에서 산업 시나리오와 유사합니다. 그러나 장치는 다르며, 스마트 신호등, 교통 모니터링, 사람 계수기, 카메라 등을 포함합니다.
오늘날 많은 가정용 IoT 지원 장치는 유사한 기능 (예: 오디오/비디오 재생)을 제공할 수 있으며, 사용자 인터페이스의 특정 측면에서만 차이가 납니다. 이 사용 사례는 사용자가 방에서 방으로 이동할 때 특정 애플리케이션과의 지속적인 상호작용을 가능하게 하며, 사용자 인터페이스는 사용자의 현재 위치에서 사용 가능한 장치 집합으로 자동 전환됩니다.
반면, 일부 장치는 다른 애플리케이션과 장치가 재사용할 수 있는 더 큰 맥락에 정보를 추가하는 데 사용할 수 있는 특정 기능과 사용자 인터페이스를 가질 수 있습니다. 이는 사용 맥락에 따라 더 사용자에게 맞고 의미 있는 상호작용을 달성하기 위해 애플리케이션을 여러 장치에 걸쳐 확장할 필요성을 유도합니다. 두 측면 모두 애플리케이션이 분산 멀티모달 인터페이스를 사용하는 사용 사례를 탐색할 근거를 제공합니다.
지능형 홈에서 제어 가능한 장치 수가 증가하면 사용 가능한 모든 서비스를 일관되고 유용한 방식으로 제어하는 문제가 생깁니다. 센서와 직접 사용자 입력을 통해 수집된 정보로 구축된 공유 맥락을 가지면 사용자 의도 인식이 향상되어 상호작용이 단순화될 것입니다.
또한 사용자는 장치 유형, 신뢰 수준 및 특정 작업에 필요한 상호작용 유형을 기반으로 여러 입력 메커니즘을 선택할 수 있습니다.
스마트 홈 기능(창문 블라인드, 조명, 에어컨 등)은 집 자체에 내장된 모달리티(예: 음성 및 제스처 인식)와 사용자의 개인 장치에서 사용 가능한 모달리티(예: 스마트폰 터치스크린)로 구성된 멀티모달 인터페이스를 통해 제어됩니다. 시스템은 특정 사용자의 선호도에 자동으로 적응하거나, 여러 사람이 존재하는 경우 더 복잡한 상호작용으로 들어갈 수 있습니다.
집 주변의 다양한 장치에 내장된 센서는 홈에 정보를 공급하고 그 동작에 영향을 주는 입력 모달리티로 동작할 수 있습니다. 예를 들어 피트니스 장비가 기록한 운동 강도가 증가함에 따라 gym room의 조명과 온도가 동적으로 조정될 수 있습니다. 같은 데이터는 사용자의 모바일 장치나 홈의 미디어 시스템에서 재생되는 음악 트랙의 볼륨과 템포를 증가시키거나 감소시킬 수도 있습니다.
OAuth 2.0은 여러 웹 서비스 전반에서 사용되는 것으로 널리 알려진 인가 프로토콜입니다. 이는 third-party 애플리케이션이 리소스 소유자 또는 자신을 대신하여 HTTP 서비스에 대한 제한된 접근을 얻을 수 있게 합니다. 이 프로토콜은 다음 행위자를 정의합니다:
scope에 대해
client를 인가하는 중개자.
이러한 행위자는 WoT 엔티티에 매핑될 수 있습니다:
TO DO: OAuth 2.0 명세를 확인하여 Resource Owner가 정확히 어떻게 정의되는지 판단하십시오. resource의 실제 소유자(예: 웹 서버를 실행하는 사람)인가, 아니면 단순히 해당 resource에 접근할 권한을 가진 사람인가?
OAuth 2.0 프로토콜은 client를 resource owner로부터 분리하는 인가 계층을 지정합니다. 이 프로토콜의 기본 단계는 다음 다이어그램에 요약되어 있습니다:
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+단계 A와 B는 authorization grant type 또는 flow로 알려진 것을 정의합니다. 여기서 중요한 점은 이러한 모든 상호작용이 네트워크 프로토콜 위에서 일어나도록 의도된 것은 아니라는 점입니다. 어떤 경우에는 사용자 인터페이스를 통한 인간과의 상호작용이 의도될 수 있습니다. OAuth2.0은 4개의 기본 flow와 확장 메커니즘을 정의합니다. 그중 가장 일반적인 것은 다음과 같습니다:
code
implicit
password (resource owner의 것)
client (client의 credentials)
또한 IoT에 관심 있는 특정 확장은 device
flow입니다. OAuth 2.0 프로토콜에 대한 추가 정보는
IETF
RFC6749에서 찾을 수 있습니다. flow 외에도
OAuth 2.0은 scope도 지원합니다. scope는 token에
첨부할 수 있는 식별자입니다. 이는 API에서 특정 역할
또는 actions로 인가를 제한하는 데 사용할 수 있습니다.
각 token은 scope 집합을 운반하며, 상호작용이 시도될 때
이를 확인할 수 있고, token이 상호작용에 필요한 scope를
포함하지 않으면 접근을 거부할 수 있습니다. 이 문서는
OAuth 2.0 authorization flow 각각에 관련된 사용 사례를
설명합니다.
각 OAuth 2.0 flow에는 대응하는 사용 사례 변형이 있습니다. 실험적인 "device" flow도 고려 대상으로 포함합니다.
code
이 프로토콜의 자연스러운 적용은 end-user가 소비되는 thing과 직접 상호작용하거나 원격 장치에 자신의 인가를 부여하려는 경우입니다. 실제로 RFC6749에 따르면
이는 code flow가 resource owner가 적어도 한 번은 WoT Consumer와 직접 상호작용할 때만 사용될 수 있음을 의미합니다. 일반적인 시나리오는 다음과 같습니다:
다음 다이어그램은 WoT 관용구와 엔티티에 맞게 조정된 프로토콜 단계를 보여줍니다. 이 시나리오에서 WoT Consumer는 Remote Device의 Thing Description을 읽었고, OAuth 2.0 code flow로 보호되는 WoT Affordance 중 하나에 접근하고자 합니다.
+-----------+
+----------+ | |
| Resource | | Remote |
| Owner | | Device +<-------+
| | | | |
+----+-----+ +-----------+ |
^ |
| |
(B) |
+------------+ Client Identifier +---------------+ |
| ------(A)-- & Redirection URI ---->+ | |
| User- | | Authorization | |
| Agent ------(B)-- User authenticates --->+ Server | |
| | | | |
| ------(C)-- Authorization Code ---<+ | |
+---+----+---+ +---+------+----+ |
| | ^ v |
(A) (C) | | |
| | | | |
^ v | | |
+---+----+---+ | | |
| |>-+(D)-- Authorization Code ---------' | |
| WoT | & Redirection URI | |
| Consumer | | |
| |<-+(E)----- Access Token -------------------' |
+-----+------+ (w/ Optional Refresh Token) |
v |
| |
+-----------(F)----- Access WoT --------------------------------+
Affordance단계 (A), (B) 및 (C)는 User-Agent를 통과하면서 두 부분으로 나뉜다는 점에 유의하십시오.
device
device flow(IETF RFC 8628)는
브라우저가 없고 입력이 제한된 장치를 위한 code flow의
변형입니다. 그 상위 flow와 마찬가지로, resource
owner와 WoT consumer 사이의 긴밀한 상호작용이 필요합니다.
따라서 이 flow의 사용 사례는 code authorization grant와
같지만, resource owner와 상호작용할 풍부한 수단이 없는
모든 장치로 제한됩니다. 그러나 code와 달리,
RFC 8628은 프로토콜 행위자 중 하나가 browser와
상호작용하는 end-user라고 명시적으로 말합니다
(section-6.2가
companion app과 BLE를 사용한 인증을 간략히 설명하긴
하지만). 이는 다음 (약간 조정된) 다이어그램에 표시되어
있습니다:
+----------+
| |
| Remote |
| Device |
| |
+----^-----+
|
| (G) Access WoT Affordance
|
+----+-----+ +----------------+
| +>---(A)-- Client Identifier ---v+ |
| | | |
| +<---(B)-- Device Code, ---<+ |
| | User Code, | |
| WoT | & Verification URI | |
| Consumer | | |
| | [polling] | |
| +>---(E)-- Device Code --->+ |
| | & Client Identifier | |
| | | Authorization |
| +<---(F)-- Access Token ---<+ Server |
+-----+----+ (& Optional Refresh Token) | |
v | |
: | |
(C) User Code & Verification URI | |
: | |
^ | |
+-----+----+ | |
| End User | | |
| at +<---(D)-- End user reviews --->+ |
| Browser | authorization request | |
+----------+ +----------------+주목할 만한 언급:
client credential
Client Credentials grant type은 end-user의 맥락 밖에서 access token을 얻기 위해 client가 사용합니다. RFC6749에 따르면:
따라서 client credential grant는 다음과 같이 사용될 수 있습니다:
Client Credentials flow는 다음 다이어그램에 설명되어 있습니다. Resource Owner가 존재하지 않는다는 점에 유의하십시오.
+----------+
| |
| Remote |
| Device |
| |
+----^-----+
|
| (C) Access WoT Affordance
^
+----+-----+ +---------------+
| | | |
| +>--(A)- Client Authentication --->+ Authorization |
| WoT | | Server |
| Consumer +<--(B)---- Access Token ---------<+ |
| | | |
| | +---------------+
+----------+
의견: 보통 client credentials는 인간이 특정
애플리케이션을 등록하는 데 사용하는 외부 서비스를 통해
배포됩니다. 예를 들어 npm cli에는 개발자가
token 생성을 요청하고 그 token이 cli에 전달되는
companion dashboard가 있습니다. 이 token은 registry에
npm 패키지를 게시하는 프로세스를 검증하는 데
사용됩니다. 추가 예로는 Docker cli와 OpenId Connect
Client Credentials가 있습니다.
implicit
폐기됨 OAuth 2.0 Security Best Current Practice에 따르면:
위 RFC는 대신 Proof Key for Code Exchange(PKCE)를
사용하는 code flow를 제안합니다.
implicit flow는 일반적으로 브라우저 안에 구현되는
public client(즉, javascript client)를 위해 설계되었습니다.
code는 redirection-based flow이며 resource의
owner user-agent와 직접 상호작용해야 합니다. 그러나
token을 얻기 위한 단계가 하나 적으며, 아래 다이어그램에서
볼 수 있듯이 authentication request에서 직접 반환됩니다.
WoT 맥락을 고려하면 이 flow는 code grant와
특별히 다르지 않으며 같은 시나리오에서 사용될 수
있습니다.
의견: implicit flow가 폐기되었더라도 기존
서비스가 여전히 이를 사용하고 있을 수 있습니다.
+----------+
| Resource |
| Owner |
| |
+----+-----+
^
|
(B)
+----------+ Client Identifier +---------------+
| ------(A)-- & Redirection URI --->+ |
| User- | | Authorization |
| Agent ------(B)-- User authenticates -->+ Server |
| | | |
| +<---(C)--- Redirection URI ----<+ |
| | with Access Token +---------------+
| | in Fragment
| | +---------------+
| +----(D)--- Redirection URI ---->+ Web-Hosted |
| | without Fragment | Client |
| | | Resource |
| (F) +<---(E)------- Script ---------<+ |
| | +---------------+
+-+----+---+
| |
(A) (G) Access Token
| |
^ v
+-+----+---+ +----------+
| | | Remote |
| WoT +>---------(H)--Access WoT--------->+ Device |
| Consumer | Affordance | |
| | +----------+
+----------+resource owner password
폐기됨 OAuth 2.0 Security Best Current Practice에 따르면:
완전성을 위해 flow 다이어그램을 아래에 보고합니다.
+----------+
| Resource |
| Owner |
| |
+----+-----+
v
| Resource Owner
(A) Password Credentials
|
v
+-----+----+ +---------------+
| +>--(B)---- Resource Owner ------->+ |
| | Password Credentials | Authorization |
| WoT | | Server |
| Consumer +<--(C)---- Access Token ---------<+ |
| | (w/ Optional Refresh Token) | |
+-----+----+ +---------------+
|
| (D) Access WoT Affordance
|
+----v-----+
| Remote |
| Device |
| |
+----------+device flow에 대해서는 RFC 8628
section 5도 참조하십시오.
Actors(물리적 사람 또는 사람들의 그룹(회사)을 나타냄)
Manufacturer 서비스 제공자 Network Provider (WoT 사용 사례에서는 잠재적으로 투명함) 장치 소유자 (User) 기타?Roles:
사용 사례에 따라 actor는 여러 role을 가질 수 있습니다. 예: security maintainer. Role은 위임될 수 있습니다.다음 범주는 공통 속성을 공유하는 사용 사례를 그룹화합니다. User Story의 정의에서, use case 범주는 특정 사용 사례 대신 (또는 추가로) 동기로 인용될 수 있습니다.
공공 서비스를 제공합니다. 오용은 다른 사용자에 대한 지원 부족을 초래할 수 있습니다.
개인 정보 또는 기밀 정보를 처리합니다. 오용은 개인 식별 정보(PII) 또는 민감한 비즈니스 정보를 공개할 수 있습니다.
오용은 개인 상해를 일으킬 가능성이 있습니다.
오용은 재정적 손해 또는 비즈니스 운영이나 평판에 손상을 일으킬 가능성이 있습니다.
TD 구축 과정을 단순화하는 것은 TD 작성자와 생성자의 작업을 쉽게 하는 데 도움이 됩니다.
이 문서의 개선으로 이어진 지원, 기술적 입력 및 제안을 해주신 W3C 직원과 W3C Web of Things Interest Group (WoT IG) 및 Working Group (WoT WG)의 모든 다른 active Participants께 깊이 감사드립니다. Cristiano Aguzzi, Luca Barbato, Ben Francis, Ege Korkan, Daniel Peintner, Jan Romann, Josh Thomas도 User Stories 제출과 User Story process 테스트를 포함하여 문서의 최신 재구성에 기여했습니다.
이 문서에 기여한 모든 use case 설명 작성자(알파벳순)에게 특별히 감사드립니다:
WoT Use Cases Task Force의 작업에 지속적인 도움과 지원을 제공한 W3C의 Dr. Kazuyuki Ashimura께 특별히 감사드립니다.
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
