웹 사물(Web of Things, WoT) 아키텍처 1.1

WoT 추상 아키텍처를 준수하는 WoT 배포에서는 다양한 서로 다른 장치 유형을 볼 수 있습니다. 이들은 (설치 공간과 기능 순으로 정렬하면) 작은 임베디드 노드 장치에서 게이트웨이 또는 허브, 강력한 에지 장치 및 클라우드 서버에 이르기까지 다양합니다. 이러한 장치 간 상호운용성은 핵심 기능과 기능성이 모든 장치에서 사용 가능함을 의미합니다.

다음 장치 범주는 이러한 클래스의 전형적인 대표에 대한 설치 공간과 특성을 설명합니다. 이는 이러한 장치 클래스에 가능한 기능과 사용 사례를 식별하는 데 사용됩니다.

이러한 범주는 제한된 장치에 대해 IETF [RFC7228]가 정의한 클래스와 정렬되어 있지만, 더 큰 장치로 클래스가 확장되었고 RAM 및 Flash/ROM의 일반적인 크기에 대한 경계가 제공됩니다. 메모리와 저장소 크기는 성능보다 정량화하기 쉽고 더 제한적이므로, 이것이 이 분류의 기준입니다. 이는 엄격한 분류가 아닙니다. 범주는 서로 겹칠 수 있으며 모든 메모리가 사용자 애플리케이션에 사용 가능하지 않을 수 있습니다.

소비자 영역에는 연결됨으로써 이점을 얻는 여러 자산이 있습니다. 조명과 에어컨은 실내 점유 여부에 따라 꺼질 수 있습니다. 창문 블라인드는 날씨 조건과 존재 여부에 따라 자동으로 닫힐 수 있습니다. 에너지와 기타 자원 소비는 사용 패턴과 예측을 기반으로 최적화될 수 있습니다.

이 절의 소비자 시나리오는 스마트 홈 사용 사례를 설명합니다.

그림 1은 스마트 홈의 예를 보여줍니다. 이 경우 게이트웨이는 KNX, ECHONET, ZigBee, DECT ULE 및 Wi-SUN과 같은 해당 로컬 통신 프로토콜을 통해 센서, 카메라 및 가전제품과 같은 에지 장치에 연결됩니다. 하나의 가정에는 여러 게이트웨이가 존재할 수 있으며, 각 게이트웨이는 여러 로컬 프로토콜을 지원할 수 있습니다.

게이트웨이는 인터넷을 통해 클라우드에 연결될 수 있으며, 일부 가전제품은 클라우드에 직접 연결될 수 있습니다. 클라우드에서 실행되는 서비스는 에지 장치에서 데이터를 수집하고 데이터를 분석한 다음, 에지 장치와 기타 UX 장치를 통해 사용자에게 가치를 제공합니다.

스마트 홈은 원격 접근 및 제어, 음성 제어 및 홈 자동화와 같은 소비자 이점을 제공합니다. 또한 스마트 홈은 장치 제조업체가 장치를 원격으로 모니터링하고 유지관리할 수 있게 합니다. 스마트 홈은 에너지 관리 및 보안 감시와 같은 부가가치 서비스를 실현할 수 있습니다.

이 절의 산업 사용 사례는 서로 다른 산업 수직 분야에 적용될 수 있습니다.
애플리케이션 시나리오가 중첩되는 특성 때문에, 서로 다른 수직 분야는 유사한 사용 사례를 가집니다.

4.2.1 예: 스마트 팩토리

그림 2는 스마트 팩토리의 예를 보여줍니다. 이 경우 필드 수준, 셀 및 라인 컨트롤러는 PROFINET, Modbus, OPC UA TSN, EtherCAT 또는 CAN과 같은 산업용 통신 프로토콜을 기반으로 서로 다른 공장 장비를 자동화합니다. 산업용 에지 장치는 다양한 컨트롤러에서 선택된 데이터를 수집하여 클라우드 백엔드 서비스가 사용할 수 있게 합니다. 예를 들어 대시보드를 통한 원격 모니터링이나 예방적 유지관리를 위한 분석에 사용할 수 있습니다.

스마트 팩토리는 연결된 제조 장비뿐 아니라 제조된 제품에 대해서도 고급 모니터링을 필요로 합니다. 기계 고장 예측과 이상 징후의 조기 발견은 비용이 큰 가동 중단과 유지관리 노력을 방지하는 데 도움이 됩니다.

또한 연결된 제조 장비와 생산 시설의 환경을 모니터링하여 유독 가스, 과도한 소음 또는 열의 존재를 확인하면 작업자의 안전이 향상되고 사건이나 사고의 위험이 줄어듭니다.

생산 장비의 실시간 모니터링과 KPI 계산은 생산성 문제를 감지하고 공급망을 최적화하는 데 도움이 됩니다.

차량, 연료 비용, 유지관리 필요성 및 배정을 모니터링하면 차량 집단의 전체 활용도를 최적화하는 데 도움이 됩니다.

운송 중인 상품의 일관된 품질과 상태를 보장하기 위해 배송물을 이동 중에 추적할 수 있습니다. 이는 창고에서 냉장 트럭, 배송에 이르는 콜드 체인의 무결성을 확인하는 데 특히 유용합니다.

창고와 야드의 재고를 중앙에서 모니터링하고 관리하면 재고 부족과 과도한 재고 상황을 방지할 수 있습니다.

주거용 및 C&I(상업 및 산업) 계량기의 자동 검침과 과금은 자원 소비와 잠재적 병목 현상에 대한 지속적인 통찰을 제공합니다.

분산 재생 에너지 발전 장비의 상태와 출력을 모니터링하면 분산 에너지 자원을 최적화할 수 있습니다.

배전 장비의 모니터링과 원격 제어는 배전 과정을 자동화하는 데 도움이 됩니다.

발전 및 배전 인프라의 지속적인 모니터링은 현장의 유틸리티 작업자 안전을 향상하고 있습니다.

해양 플랫폼 모니터링, 파이프라인의 누출 감지와 예측, 탱크와 저장소의 수위 모니터링 및 제어는 작업 인력뿐 아니라 환경을 위한 산업 안전을 향상하는 데 도움이 됩니다.

다양한 저장 탱크와 배송 파이프/트럭을 통한 분산 재고의 자동 계산은 개선된 계획과 자원 최적화를 가능하게 합니다.

연결된 구조물, 차량 집단 등 고가치 자산의 사전 자산 모니터링은 예측과 사건의 조기 감지를 통해 심각한 손상과 높은 비용의 위험을 완화합니다.

사용량 추적과 맞춤형 보험 정책을 통해 사용 기반 보험을 제공할 수 있습니다.

예측적 기상 모니터링과 차량 집단을 지붕이 있는 차고로 재경로 지정하는 것은 우박 피해와 나무 피해로 인한 손실을 제한할 수 있습니다.

산업 안전을 위한 모니터링은 보안 위험의 리스크를 줄입니다. 건설 현장의 자산 모니터링은 손상과 손실을 방지할 수 있습니다.

토양 상태 모니터링과 급수 및 비료 공급을 위한 최적 계획 수립, 그리고 농산물 상태 모니터링은 농산물의 품질과 산출량을 최적화합니다.

임상 시험 데이터의 데이터 수집과 분석은 새로운 영역에 대한 통찰을 얻는 데 도움이 됩니다.

원격 환자 모니터링은 고령자와 입원 후 환자에게 감지되지 않은 위급 상황의 위험을 완화합니다.

환경 모니터링은 일반적으로 측정 데이터를 공통 게이트웨이, 에지 장치 및 클라우드 서비스로 전송하는 많은 분산 센서에 의존합니다.

대기 오염, 수질 오염 및 미세먼지, 오존, 휘발성 유기 화합물, 방사능, 온도, 습도와 같은 기타 환경 위험 요인의 모니터링은 치명적인 환경 조건을 감지하여 회복 불가능한 건강 또는 환경 피해를 방지할 수 있습니다.

교량, 댐, 제방, 운하의 재료 상태, 열화, 진동을 모니터링하면 유지보수 작업을 발견하고 중대한 손상을 방지할 수 있습니다. 고속도로 모니터링과 적절한 표지 제공은 최적화된 교통 흐름을 보장합니다.

스마트 주차는 주차 공간의 사용과 가용성을 최적화하고 추적하며 과금/예약을 자동화합니다.

존재 감지, 날씨 예측 등에 기반한 가로등의 스마트 제어는 비용을 줄입니다.

쓰레기통은 폐기물 관리와 쓰레기 수거 경로를 최적화하기 위해 모니터링될 수 있습니다.

건물 전체의 에너지 사용량을 모니터링하면 자원 소비를 최적화하고 낭비를 줄이는 데 도움이 됩니다.

HVAC, 엘리베이터 등 건물 내 장비를 모니터링하고 문제를 조기에 해결하면 입주자의 만족도가 향상됩니다.

운영 상태 모니터링과 서비스 필요성 예측은 유지관리 필요성과 비용을 최적화합니다. 중요한 도로와 교통 상황에 대한 조기 경보 시스템 알림을 통해 운전자 안전이 향상됩니다.

4.13.1 커넥티드 카 예

그림 3은 커넥티드 카의 예를 보여줍니다. 이 경우 게이트웨이는 CAN을 통해 자동차 구성 요소에 연결되고, 독점 인터페이스를 통해 자동차 내비게이션 시스템에 연결됩니다. 클라우드에서 실행되는 서비스는 자동차 구성 요소에서 푸시된 데이터를 수집하고 여러 자동차의 데이터를 분석하여 교통 패턴을 결정합니다. 게이트웨이는 또한 이 경우 교통 데이터를 얻어 자동차 내비게이션 시스템을 통해 운전자에게 보여주기 위해 클라우드 서비스를 소비할 수 있습니다.

원격 측정은 원격 장치의 모니터링이며, 이는 측정값과 기타 데이터가 소비자에게 자동으로 전송되고 처리됨을 의미합니다. 데이터는 무선 및 유선 모두의 다양한 통신 채널을 통해 전송될 수 있습니다. 예로는 GSM 네트워크, Bluetooth, WiFi, Ethernet 및 기타 유선 표준이 있습니다.

원격 계량 장치는 하나 이상의 센서를 포함하며, 경우에 따라 액추에이터도 포함합니다. 많은 경우 센서 데이터는 정기적인 간격, 상태 변경 시 또는 소비자의 요청에 대한 응답으로 전송됩니다.

원격 계량 장치는 종종 매우 제한된 자원을 가진 소형 임베디드 시스템, 즉 Class-2 이하입니다. 배터리로 구동될 수 있으며, 예를 들어 절전 모드와 같은 다양한 조치를 통해 전력 소비를 최소화해야 합니다. 이러한 장치는 에너지를 절약하기 위해 대부분의 시간 동안 절전 상태에 있으며 데이터를 전송하지 않습니다. 특정 이벤트(예: 스위치가 토글될 때)에만 깨어납니다. 장치 상태가 변경되면 이벤트가 소비자에게 전송됩니다. 그 후 장치는 다시 절전 모드로 들어갑니다.

일반적인 사용자 시나리오는 다양한 자산의 모니터링이며, 예로는 스마트 시티, 공장, 차량 집단, 환경 모니터링 및 건강 모니터링이 있습니다. 일부 배포에서는 지리적으로 분산된 많은 수의 자산을 모니터링해야 할 수 있으며, 다른 배포는 스마트 홈처럼 몇 개의 장치만 포함할 수 있습니다. 일반적인 패턴은 하나의 소비자와 여러 장치 (사물) 사이의 일대다 관계입니다.

일반적인 배포 패턴은 그림 4에 묘사된 것처럼 사용자가 조작하는 원격 컨트롤러에 의해 제어되는 로컬 장치입니다.

원격 컨트롤러는 로컬 홈 네트워크를 통해 전자 기기에 직접 접근할 수 있습니다. 이 경우 원격 컨트롤러는 브라우저 또는 네이티브 애플리케이션으로 구현될 수 있습니다.

이 패턴에서는 전자 기기와 같은 적어도 하나의 장치가 다른 장치의 요청을 수락하고 이에 응답하며 때로는 기계적 동작을 개시할 수 있는 서버 역할을 가집니다. 원격 컨트롤러와 같은 다른 장치는 센서 값을 읽거나 장치를 켜는 요청과 함께 메시지를 보낼 수 있는 클라이언트 역할을 가집니다. 또한 장치의 현재 상태나 이벤트 알림을 방출하기 위해, 장치는 서버 역할을 가진 다른 장치로 메시지를 보낼 수 있는 클라이언트 역할을 가질 수 있습니다.

그림 5는 직접적인 사물 간 상호작용의 예를 보여줍니다. 시나리오는 다음과 같습니다. 센서는 예를 들어 온도가 임계값을 초과하는 것과 같은 실내 조건의 변화를 감지하고, 전자 기기에 "turn on"과 같은 제어 메시지를 발행합니다. 센서 장치는 다른 장치에 일부 트리거 메시지를 발행할 수 있습니다.

이 경우 서버 역할을 가진 두 장치가 연결되어 있을 때, 적어도 하나의 장치는 다른 장치를 작동시키거나 알리기 위해 메시지를 발행하는 클라이언트 역할도 가져야 합니다.

이 배포 시나리오는 그림 6에 보인 것처럼 모바일 원격 컨트롤러(예: 스마트폰)를 포함합니다. 원격 컨트롤러는 서로 다른 네트워크 연결과 프로토콜, 예를 들어 셀룰러 네트워크와 Wi-Fi 및 Bluetooth 같은 프로토콜을 사용하는 홈 네트워크 사이를 전환할 수 있습니다. 컨트롤러가 홈 네트워크에 있을 때는 신뢰할 수 있는 장치이며 추가 보안 또는 접근 제어가 필요하지 않습니다. 신뢰할 수 있는 네트워크 밖에 있을 때는 신뢰 관계를 보장하기 위해 추가 접근 제어와 보안 메커니즘을 적용해야 합니다. 이 시나리오에서는 서로 다른 네트워크 접근 지점 또는 셀룰러 기지국 사이의 전환 때문에 네트워크 연결성이 변경될 수 있다는 점에 유의하십시오.

이 패턴에서 원격 컨트롤러와 전자 기기는 그림 4의 관련 시나리오와 같이 클라이언트 및 서버 역할을 가집니다.

그림 7은 스마트 홈 게이트웨이의 배포 시나리오를 보여줍니다. 게이트웨이는 홈 네트워크와 인터넷 사이에 배치됩니다. 이는 집 안의 전자 기기를 관리하고, 이전 시나리오의 스마트폰처럼 인터넷을 통해 원격 컨트롤러에서 명령을 받을 수 있습니다. 또한 장치의 가상 표현이기도 합니다. 스마트 홈 게이트웨이는 일반적으로 프록시 및 방화벽 기능을 제공합니다.

이 패턴에서 홈 게이트웨이는 클라이언트와 서버 역할을 모두 가집니다. 원격 컨트롤러가 전자 기기를 작동시킬 때, 게이트웨이는 클라이언트 역할로 전자 기기에 연결하고 서버 역할로 원격 컨트롤러에 연결할 수 있습니다. 전자 기기가 원격 컨트롤러로 메시지를 방출할 때, 게이트웨이는 전자 기기에 대해서는 서버 역할로 동작하고, 원격 컨트롤러에 대해서는 클라이언트 역할로 동작합니다.

에지 장치 또는 에지 게이트웨이는 스마트 홈 게이트웨이와 유사합니다. 우리는 이 용어를 에지 게이트웨이가 수행하는 추가 작업을 나타내기 위해 사용합니다. 그림 8의 홈 게이트웨이가 주로 공용 네트워크와 신뢰할 수 있는 네트워크 사이를 연결하는 데 그치는 반면, 에지 장치는 로컬 컴퓨팅 기능을 가지며 일반적으로 서로 다른 프로토콜 사이를 연결합니다. 에지 장치는 일반적으로 산업 솔루션에서 사용되며, 연결된 장치와 센서가 제공하는 데이터의 전처리, 필터링 및 집계를 제공할 수 있습니다.

디지털 트윈은 클라우드 서버 또는 에지 장치에 존재하는 장치 또는 장치 그룹의 모델, 즉 가상 표현입니다. 이는 지속적으로 온라인 상태가 아닐 수 있는 실제 장치를 표현하거나, 새 애플리케이션과 서비스를 실제 장치에 배포하기 전에 시뮬레이션을 실행하는 데 사용될 수 있습니다.

디지털 트윈은 단일 장치를 모델링할 수 있으며, 여러 장치를 결합한 가상 표현으로 집계할 수도 있습니다.

디지털 트윈은 장치가 이미 클라우드에 연결되어 있는지, 또는 클라우드에 연결된 게이트웨이에 연결되어 있는지에 따라 서로 다른 방식으로 실현될 수 있습니다.

5.7.1 클라우드 연결 장치

그림 11은 전자 기기가 클라우드에 직접 연결된 예를 보여줍니다. 클라우드는 가전제품을 미러링하고 디지털 트윈으로 동작하여 원격 컨트롤러 (예: 스마트폰)로부터 명령을 받을 수 있습니다. 디지털 트윈은 전역적으로 도달 가능하므로, 권한 있는 컨트롤러는 어디에나 위치할 수 있습니다.

5.7.3 레거시 장치

그림 12는 레거시 전자 기기가 클라우드에 직접 연결되어 있지 않은 예를 보여줍니다. 여기서는 연결을 중계하기 위해 게이트웨이가 필요합니다. 게이트웨이는 다음과 같이 동작합니다:

• 물리적 및 논리적 관점에서 다양한 레거시 통신 프로토콜의 통합자
• 인터넷을 향한 방화벽
• 실제 이미지 및/또는 음성을 대체하고 데이터를 로컬에 기록하는 개인정보 보호 필터
• 네트워크 연결이 중단된 경우의 로컬 에이전트
• 화재 경보 및 유사한 이벤트가 발생할 때 로컬에서 실행되는 긴급 서비스

클라우드는 연결된 모든 가전제품과 함께 게이트웨이를 미러링하고, 게이트웨이와 함께 클라우드에서 이들을 관리하는 디지털 트윈으로 동작합니다. 또한 클라우드는 어디에나 위치할 수 있는 원격 컨트롤러(예: 스마트폰)로부터 명령을 받을 수 있습니다.

일반적인 IoT 배포는 여러(수천 개의) 장치로 구성됩니다. 표준화된 메커니즘이 없으면 특정 클라우드를 위한 펌웨어 업데이트 관리에는 많은 노력이 필요하며, 더 넓은 규모의 IoT 채택을 방해합니다.

장치와 장치 유형을 설명하기 위한 표준화된 메커니즘의 주요 이점은 장치 소프트웨어/펌웨어 수준에서 사용자 정의, 즉 장치에 클라우드별 코드를 설치할 필요 없이 장치를 서로 다른 클라우드 환경에 배포할 수 있는 능력입니다. 이는 솔루션이 여러 IoT 클라우드 환경에서 장치를 온보딩하고 사용할 수 있게 하는 방식으로 장치를 설명할 만큼 충분히 유연하다는 것을 의미합니다.

이는 기존 배포에서 새 장치를 쉽게 사용할 수 있게 하고, 기존 장치를 한 클라우드에서 다른 클라우드로 마이그레이션할 수 있게 하므로 웹 사물 장치의 채택을 촉진합니다.

가상 사물은 하나 이상의 다른 사물을 위한 자리 표시자로 동작하며 그 소비자에게 인터페이스를 제공하는 서비스입니다.

간단한 경우 이는 인터페이스 추상화로, 소비자를 변경하지 않고도 한 장치 모델을 다른 모델로 대체할 수 있는 장치에 대한 공통 인터페이스를 정의합니다.

더 복잡한 시나리오에서 가상 사물은 여러 장치에 대한 단일 인터페이스를 제공하고 그 소비자에게 더 높은 수준의 작업을 제공합니다. 개별 장치는 대체될 수 있고, 소프트웨어 업그레이드를 통해 새로운 작업이 제공될 수 있습니다.

가상 사물은 종종 중개자로 동작합니다. 예로는 섀도 및 디지털 트윈이 있습니다.

그림 13은 도메인 간 협업의 예를 보여줍니다. 이 경우 각 시스템은 스마트 팩토리와 스마트 시티, 스마트 시티와 스마트 홈과 같이 다른 도메인의 다른 시스템을 포함합니다. 이러한 유형의 시스템은 [IEC-FOTF]에 보인 것처럼 "공생" 생태계라고 부릅니다. 협업 모델에는 직접 협업과 간접 협업 두 가지가 있습니다. 직접 협업 모델에서 시스템은 피어 투 피어 방식으로 서로 직접 정보를 교환합니다. 간접 협업에서는 시스템이 어떤 협업 플랫폼을 통해 정보를 교환합니다. 이러한 협업을 유지하고 지속하기 위해 각 시스템은 자신의 기능과 인터페이스에 대한 메타데이터를 제공하고 다른 시스템에 맞게 스스로를 조정합니다.

이전 절은 다양한 아키텍처 패턴을 설명했습니다. 이러한 패턴에서 레거시 장치를 포함한 장치, 컨트롤러, 게이트웨이 및 클라우드 서버와 같은 일부 기능적 엔터티는 건물 내부, 건물 외부 및 데이터 센터와 같은 물리적 위치에 배치됩니다. 그림 14는 이러한 엔터티의 조합과 통신 경로를 보여주는 개요입니다.

전송 프로토콜 계층에서 각 엔터티는 통신에 적합한 역할을 임의로 선택합니다. 예를 들어 장치가 불특정 다수의 애플리케이션에 서비스를 제공할 때 장치는 서버로 동작할 수 있습니다. 반면 장치의 네트워크 연결성이 제한적이거나 간헐적이라면, 네트워크를 사용할 수 있을 때 클라이언트로 동작하여 애플리케이션에 메시지를 능동적으로 보낼 수 있습니다. 이와 무관하게 애플리케이션 계층에서 애플리케이션은 장치가 상호작용을 위한 추상 인터페이스를 제공한다고 보고, 그 추상 인터페이스를 사용하여 장치와 상호작용할 수 있습니다.

WoT 사물 기술(TD) 명세 [WOT-THING-DESCRIPTION]는 의미 어휘를 기반으로 한 정보 모델과 JSON 기반의 직렬화 표현을 정의합니다. TD는 사람이 읽을 수 있고 기계도 읽을 수 있는 방식으로 사물에 대한 풍부한 메타데이터를 제공합니다. TD의 정보 모델과 표현 형식은 모두 링크드 데이터 [LINKED-DATA]와 정렬되어 있으므로, 원시 JSON 처리 외에도 구현은 JSON-LD [JSON-LD11]와 그래프 데이터베이스를 사용하여 메타데이터의 강력한 의미 처리를 가능하게 할 수 있습니다.

사물 기술은 이름, ID, 설명과 같은 일반 메타데이터로 사물 인스턴스를 설명하며, 관련 사물 또는 다른 문서에 대한 링크를 통해 관계 메타데이터도 제공할 수 있습니다. TD는 또한 6.5 상호작용 모델에서 정의된 상호작용 모델을 기반으로 하는 상호작용 어포던스 메타데이터, 공개 보안 메타데이터, 그리고 프로토콜 바인딩을 정의하는 통신 메타데이터를 포함합니다. TD는 사물을 위한 index.html로 볼 수 있습니다. 이는 하이퍼미디어 제어를 사용하여 설명되는 사물이 제공하는 서비스와 관련 리소스에 대해 알아보기 위한 진입점을 제공하기 때문입니다.

의미 상호운용성을 위해 TD는 명시적 확장 지점이 제공되는 도메인별 어휘를 사용할 수 있습니다. 그러나 특정한 도메인별 어휘의 개발은 현재 W3C WoT 표준화 활동의 범위를 벗어납니다.

잠재적으로 유용한 외부 IoT 어휘의 세 가지 예는 SAREF [SAREF], Schema Extensions for IoT [IOT-SCHEMA-ORG], 그리고 W3C Semantic Sensor Network 온톨로지 [VOCAB-SSN]입니다. 이러한 외부 어휘를 TD에서 사용하는 것은 선택 사항입니다. 향후 추가 도메인별 어휘가 개발되어 TD와 함께 사용될 수 있습니다.

전반적으로 WoT 사물 기술 구성 요소는 두 가지 방식으로 상호운용성을 촉진합니다. 첫째, TD는 웹 사물에서 기계 간 통신을 가능하게 합니다. 둘째, TD는 개발자가 IoT 장치에 접근하고 그 데이터를 사용할 수 있는 애플리케이션을 만들기 위해 필요한 모든 세부사항을 문서화하고 검색할 수 있는 공통의 균일한 형식으로 기능할 수 있습니다.

TD가 다른 시스템과 장치에 유용하려면 알려져 있거나 접근 가능해야 합니다. 아래에서 더 자세히 설명하는 WoT 탐색 구성 요소는 자기 설명 장치와, 별도 서비스가 TD를 제공하는 것이 더 적합한 상황(브라운필드 장치, 제한 장치, 특수 프로토콜을 가진 장치, 절전 장치 등) 모두에 대해 이를 달성할 수 있는 메커니즘을 정의합니다.

사물 모델은 사물 기술 인스턴스를 위한 템플릿 기반 모델을 정의합니다. 사물 모델은 인스턴스별 정보가 없고, 통신 및 보안 기반 정보도 부분적으로만 가집니다. 이러한 종류의 정보는 사물 기술 인스턴스화 생성에 의해 보완됩니다.

사물 모델은 주로 속성, 액션, 및 이벤트와 공통 메타데이터를 설명하며, 이는 이후 인스턴스화된 모든 사물 기술에서 사용할 수 있습니다. 이 패러다임은 객체 지향 프로그래밍에서 객체(~사물 기술)를 만들기 위한 추상 클래스 또는 인터페이스 정의(~사물 모델)와 비교할 수 있습니다. 이러한 사물 모델은 예를 들어 IoT 장치의 대량 생산, 클라우드 서비스에서의 온보딩 시나리오, 또는 아직 개발되지 않은 장치를 시뮬레이션하는 데 관련됩니다.

WoT 프로파일 명세 [WOT-PROFILE]는 사물과 장치 사이의 즉시 사용 가능한 상호운용성을 가능하게 하는 프로파일을 정의합니다. 즉시 사용 가능한 상호운용성은 장치가 깊은 수준의 적응 없이 다양한 애플리케이션 시나리오에 통합될 수 있음을 의미합니다. 일반적으로 특정 시나리오에서 장치를 사용하려면 네트워크 키나 IP 주소 입력과 같은 사소한 구성 작업만 필요합니다. 이러한 작업은 특별한 교육 없이 누구나 수행할 수 있습니다.

7.3.1 프로파일링 방법론

프로파일은 WoT 사물 기술 명세에 적용되는 추가 의미 보장을 제공하는 제약과 규칙의 집합입니다. 이러한 제약은 WoT 사물 기술의 여러 측면에 추가 규칙을 정의함으로써 유효한 WoT 사물 기술의 부분집합을 정의합니다.

제약 대상	근거	예
사물 기술 클래스의 어휘	보장된 메타데이터 필드 집합	특정 어휘 용어를 필수로 만들고, 다른 용어를 제거
클래스 관계	모호하지 않은 구조	제한된 카디널리티, 예: 상호작용 어포던스당 작업당 하나의 폼만 허용.
어휘 용어의 값	단순화된 처리	문자열당 문자 길이를 제한합니다. 명세가 문자열 또는 문자열 배열을 허용하는 경우에도 항상 배열을 사용합니다.
데이터 스키마	단순화된 처리	임의로 중첩된 객체나 배열의 배열을 허용하지 않습니다.
보안	구현 노력 감소	제한된 보안 메커니즘 집합만 허용.
프로토콜 바인딩	보장된 프로토콜 의미	제한된 프로토콜 및 프로토콜 기능, 예: http 동사(GET/PUT)를 작업 동사에 미리 정의된 방식으로 매핑하고, 다른 프로토콜에도 유사한 제약을 적용.

이러한 제약과 규칙은 두 범주로 나뉩니다:

• 데이터 모델에 대한 제약.
• 프로토콜 바인딩에 대한 제약.

이 두 범주는 서로 직교합니다. 즉, 프로파일을 따르는 정보 모델은 서로 다른 프로토콜에 매핑될 수 있습니다. 각 프로토콜의 프로토콜 바인딩은 추가적인 (프로토콜별) 제약을 포함할 수 있습니다.

프로파일은 배타적이지 않습니다. 즉, 하나의 사물은 여러 프로파일을 따를 수 있습니다. 프로파일은 서로의 위에 구축되거나 중첩될 수 있으며, 확장 프로파일은 기준 프로파일 위에 구축될 수 있습니다.

WoT 탐색 명세 [WOT-DISCOVERY]는 네트워크를 통해 WoT 사물 기술을 배포하고 접근하기 위한 메커니즘을 정의합니다. 이러한 메커니즘은 사물과 서비스에 대한 접근을 단순화하고 그 통합을 지원하기 위한 것입니다. WoT 탐색 메커니즘은 근거리 네트워크의 범위에 제한되지 않으며 원격 탐색도 지원할 수 있습니다. 또한 기존 검색 및 탐색 표준의 확장으로 동작하도록 설계되어 있습니다.

WoT 탐색 구성 요소의 주요 설계 요구사항 중 하나는 WoT 데이터 및 메타데이터의 소비자와 제공자 모두의 보안과 개인정보 보호를 보호하는 것입니다. 특히 WoT 탐색 메커니즘은 WoT 사물 기술에 대한 접근을 보호하고 제어할 뿐 아니라, 그러한 데이터와 메타데이터에 대한 쿼리를 보호하고, 직접적이거나 추론 가능한 메타데이터의 우발적 배포를 피하도록 설계되어 있습니다.

강력한 개인정보 보호와 보안을 제공하면서 기존 탐색 기술을 수용하기 위해 WoT 탐색은 두 단계 과정을 사용합니다. 첫 번째 단계에서는 여러 최초 접촉 메커니즘 중 하나를 사용하여 "도입"이 이루어집니다. 두 번째 단계는 "탐사"라고 부르며, 실제 TD가 제공되지만, 적절한 인증과 권한 부여 후에만 제공됩니다.

단일 TD의 배포와 여러 TD를 위한 디렉터리 서비스를 모두 지원하는 두 가지 탐사 메커니즘이 제공됩니다:

• HTTP 서버가 제공하는 일반 웹 리소스를 사용하여 단일 TD를 배포할 수 있습니다. 이는 사물이 자신의 WoT 사물 기술을 직접 제공할 수 있도록 하는 자기 설명에도 사용할 수 있습니다.
• 디렉터리 서비스는 WoT 사물 기술의 검색 가능한 데이터베이스를 제공합니다. 경량 구문 쿼리 메커니즘과 더 강력한 의미 쿼리 메커니즘이 모두 디렉터리 서비스에서 지원됩니다.

이러한 메커니즘의 사용은 권장되지만 필수는 아닙니다.

[WOT-DISCOVERY]에서 정의된 탐색 메커니즘은 필수는 아니지만, 위 요구사항을 충족하도록 설계되었으며 이를 사용하면 상호운용성과 사용성이 향상됩니다.

단일 프로토콜이 모든 맥락에 적합하지 않기 때문에 IoT는 장치에 접근하기 위해 다양한 프로토콜을 사용합니다. 따라서 웹 사물의 중심 과제는 수많은 서로 다른 IoT 플랫폼(예: OMA LWM2M, OPC UA, oneM2M)과, 특정 표준을 따르지는 않지만 적합한 네트워크 프로토콜을 통해 자격 있는 인터페이스를 제공하는 장치와의 상호작용을 가능하게 하는 것입니다. WoT는 여러 제약을 충족해야 하는 프로토콜 바인딩을 통해 이러한 다양성을 다룹니다(6.7 프로토콜 바인딩 참조).

바인딩 템플릿은 애플리케이션 클라이언트(소비자)가 사물 기술을 사용하여 프로토콜(예: HTTP, MQTT, Modbus 등), 페이로드 형식(바이너리, JSON, CBOR, EXI 등), 그리고 IoT 플랫폼 맥락(예: ECHONET, OPC UA)에서의 사용에 관한 특정 메타데이터를 추출할 수 있다는 측면을 다룹니다. 이 메타데이터는 사물과의 상호작용을 설정하고 페이로드 메시지를 직렬화/역직렬화하기 위해 네트워크 구현 인터페이스에 전달될 수 있습니다. 이 맥락에서 바인딩 템플릿은 세 가지 종류의 바인딩, 즉 프로토콜 바인딩, 페이로드 형식 바인딩, 플랫폼 바인딩을 포함합니다.

비규범적 WoT 바인딩 템플릿 명세 [WOT-BINDING-TEMPLATES]는 서로 다른 전송 프로토콜, 콘텐츠 타입을 사용하거나, 특정 전송 프로토콜과 콘텐츠 타입 조합을 사용하는 서로 다른 IoT 플랫폼 또는 표준 (예: OCF, oneM2M, OMA LWM2M, OPC UA)인 여러 사물과 상호작용하는 방법에 대한 지침을 제공하는 청사진 모음을 제공합니다. 특정 IoT 장치 또는 플랫폼을 설명할 때, 해당 바인딩 템플릿을 사용하여 그 플랫폼을 지원하기 위해 사물 기술에 제공되어야 하는 통신 메타데이터를 조회할 수 있습니다.

그림 31은 바인딩 템플릿이 어떻게 사용되는지를 보여줍니다. 프로토콜, 미디어 타입 또는 플랫폼 바인딩을 기반으로 TD가 생성됩니다. TD를 처리하는 소비자는 해당 프로토콜 스택, 미디어 타입 인코더/디코더 또는 플랫폼 스택을 포함하고, 메시지의 직렬화 형식과 헤더 옵션처럼 TD에 제공된 정보에 따라 스택 (또는 그 메시지)을 구성함으로써 TD에 존재하는 필요한 바인딩 템플릿을 구현합니다.

바인딩 템플릿은 세 가지 차원에 걸쳐 있습니다:

• 프로토콜

  웹 사물은 애플리케이션별 옵션이나 서브프로토콜 메커니즘이 없는 기반 표준화된 애플리케이션 계층 프로토콜을 가리키기 위해 전송 프로토콜 이라는 용어를 사용합니다. 상호작용 어포던스의 폼에서 발견되는 URI 스킴과 관련 프로토콜 엔드포인트 URI는 예를 들어 HTTP, CoAPS 또는 WebSocket을 각각 http, coaps, 또는 ws를 통해 식별하는 데 필요한 정보를 포함합니다.

  • 서브프로토콜

    전송 프로토콜은 성공적으로 상호작용하기 위해 확장 메커니즘이 제공하는 정보를 사용해야 할 수 있습니다. 이러한 서브프로토콜은 URI 스킴만으로는 식별될 수 없으며, 폼 내부의 subprotocol 필드를 사용하여 명시적으로 선언되어야 합니다. HTTP의 예로는 롱 폴링 [RFC6202] (longpoll) 또는 Server-Sent Events [HTML] (sse)가 있습니다.

• 페이로드 표현

  데이터 교환에 사용되는 표현 형식(일명 직렬화)은 프로토콜, IoT 플랫폼 및 표준 사이에서 달라질 수 있습니다. 미디어 타입 [RFC2046]은 이러한 형식을 식별하며, 미디어 타입 매개변수는 이를 더 자세히 지정할 수 있습니다. 폼은 HTTP에서 알려진 콘텐츠 타입 필드와 같은 추가 폼 필드에 미디어 타입과 선택적 매개변수를 포함할 수 있으며, 이는 미디어 타입과 그 잠재적 매개변수(예: text/plain; charset=utf-8)를 결합합니다.

• 플랫폼 및 표준

  IoT 플랫폼과 표준은 플랫폼별 HTTP 헤더 필드나 CoAP 옵션과 같은 애플리케이션 계층의 특정 수정을 종종 도입합니다. 또한 사물과 그 소비자 사이의 각 메시지에 정확하게 통합되어야 하는 미디어 타입 위의 특정 페이로드 구조를 포함할 수도 있습니다. 서로 다른 플랫폼에 특화된 프로토콜 수정과 페이로드 표현은 플랫폼 및 표준을 위한 바인딩 템플릿에 문서화된 모범 사례를 사용하여 TD에 표현될 수 있습니다.

WoT 스크립팅 API는 W3C WoT의 선택적 "편의" 구성 요소로, 웹 브라우저 API와 유사한 ECMAScript 기반 API [ECMAScript]를 제공하여 IoT 애플리케이션 개발을 쉽게 합니다. 스크립팅 런타임 시스템을 WoT 런타임에 통합함으로써, WoT 스크립팅 API는 사물, 소비자 및 중개자의 동작을 정의하는 이식 가능한 애플리케이션 스크립트를 사용할 수 있게 합니다.

전통적으로 IoT 장치 로직은 펌웨어로 구현되며, 이는 비교적 복잡한 업데이트 과정을 포함하여 임베디드 개발과 유사한 생산성 제약을 초래합니다. 반면 WoT 스크립팅 API는 IoT 애플리케이션을 위한 런타임 시스템에서 실행되는 재사용 가능한 스크립트로 장치 로직을 구현할 수 있게 합니다. 이는 웹 브라우저와 유사하며, 생산성을 향상하고 통합 비용을 줄이는 것을 목표로 합니다. 또한 표준화된 API는 애플리케이션 모듈의 이식성을 가능하게 합니다. 예를 들어 계산 집약적 로직을 장치에서 로컬 게이트웨이로 올리거나, 시간에 민감한 로직을 클라우드에서 게이트웨이 또는 에지 노드로 내릴 수 있습니다.

비규범적 WoT 스크립팅 API 명세 [WOT-SCRIPTING-API]는 스크립트가 WoT 사물 기술을 탐색하고, 소비하고, 노출할 수 있게 하는 프로그래밍 인터페이스의 구조와 알고리즘을 정의합니다. WoT 스크립팅 API의 런타임 시스템은 다른 사물과 그 상호작용 어포던스(속성, 액션, 및 이벤트)에 대한 인터페이스로 동작하는 로컬 객체를 인스턴스화합니다. 또한 스크립트가 사물을 노출할 수 있게 합니다. 즉, 상호작용 어포던스를 정의 및 구현하고 사물 기술을 게시할 수 있게 합니다.

보안은 횡단적 관심사이며 시스템 설계의 모든 측면에서 고려되어야 합니다. WoT 아키텍처에서 보안은 TD의 공개 보안 메타데이터 지원과 WoT 스크립팅 API 설계에서의 관심사 분리와 같은 특정한 명시적 기능으로 지원됩니다. 각 구성 요소의 명세에는 해당 구성 요소의 특정 보안 및 개인정보 보호 고려사항에 대한 논의도 포함됩니다. 또 다른 비규범적 명세인 WoT 보안 및 개인정보 보호 지침 [WOT-SECURITY]은 추가적인 횡단적 보안 및 개인정보 보호 지침을 제공합니다.

동작은 사물의 전체 애플리케이션 로직을 정의하며, 여기에는 여러 측면이 있습니다:

여기에는 사물의 자율 동작 (예: 센서 샘플링 또는 액추에이터 제어 루프), 상호작용 어포던스를 위한 핸들러(즉, 어포던스가 활성화될 때 취해지는 구체적 동작), 소비자 동작(예: 사물 제어 또는 매시업 실현), 그리고 중개자 동작 (예: 단순히 사물을 프록시하거나 가상 엔터티를 합성하는 것)이 포함됩니다. 서비언트 내부의 동작 구현은 이 구성 요소에서 어떤 사물, 소비자, 및 중개자가 호스트되는지를 정의합니다.

그림 32는 선택적 WoT 스크립팅 API 구성 요소를 구현하는 서비언트를 묘사하며, 여기서 JavaScript [ECMAScript]로 작성된 이식 가능한 애플리케이션 스크립트가 동작을 정의합니다. 이러한 스크립트는 WoT 런타임의 일부인 스크립팅 런타임 시스템에 의해 실행됩니다(WoT 스크립팅 API 또는 다른 스크립트 기반 API를 제공할 때). 이들은 공통 WoT 스크립팅 API 정의에 맞춰 작성되므로 이식 가능하며, 따라서 이 구성 요소를 갖춘 어떤 서비언트에서도 실행될 수 있습니다. 이는 예를 들어 네트워킹 요구사항을 충족하기 위해 소비자를 클라우드에서 에지 노드로 이동하거나, 증가하는 자원 요구를 충족하기 위해 중개자를 클라우드로 이동하는 등, 시스템 구성 요소 사이에서 애플리케이션 로직을 이동할 수 있게 합니다. 이식 가능한 애플리케이션은 서비언트 배포 이후 추가 동작을 '설치'할 수 있게 합니다.

원칙적으로, 상호작용 어포던스가 외부에 WoT 인터페이스를 통해 제시되는 한, 어떤 프로그래밍 언어와 API도 사물의 동작을 정의하는 데 사용할 수 있습니다. 애플리케이션 대면 API와 프로토콜 스택 사이의 적응은 WoT 런타임이 처리합니다. WoT 스크립팅 API 구성 요소 없이 동작을 구현하는 방법은 8.8.1 네이티브 WoT API를 참조하십시오.

기술적으로, 사물 추상화와 그 상호작용 모델은 런타임 시스템에서 구현됩니다. 이 WoT 런타임은 동작 구현을 위한 실행 환경을 유지하고, 사물을 노출하거나 소비할 수 있으므로, WoT 사물 기술을 가져오고, 처리하고, 직렬화하고, 제공할 수 있어야 합니다.

모든 WoT 런타임은 동작 구현을 위한 애플리케이션 대면 인터페이스(즉, API)를 가집니다. 그림 32에 표시된 선택적 WoT 스크립팅 API 구성 요소는 사물 추상화를 따르고 런타임 중 애플리케이션 스크립트를 통해 동작 구현을 배포할 수 있게 하는 애플리케이션 대면 인터페이스를 정의합니다. 대체 API는 8.8.1 네이티브 WoT API를 참조하십시오. 이 API들은 컴파일 시간에만 사용 가능할 수도 있습니다. 일반적으로 애플리케이션 로직은 애플리케이션 코드가 WoT 런타임의 관리 측면, 특히 비공개 보안 데이터에 무단 접근하지 못하게 하는 샌드박스형 실행 환경에서 실행되어야 합니다. 다중 테넌트 서비언트에서는 서로 다른 테넌트가 권한 없이 서로의 데이터에 접근하지 못하도록 해야 합니다.

WoT 런타임은 사물의 생명주기, 더 정확히는 그 소프트웨어 추상화와 설명을 관리하기 위한 특정 작업을 제공해야 합니다. 생명주기 관리(LCM) 시스템은 이러한 생명주기 작업을 서비언트 내부에 캡슐화하고 내부 인터페이스를 사용하여 생명주기 관리를 실현할 수 있습니다. 이러한 작업의 세부 사항은 구현마다 다릅니다. WoT 스크립팅 API는 LCM 기능을 포함하므로, 이러한 시스템의 가능한 구현 중 하나를 나타냅니다.

WoT 런타임은 서비언트의 프로토콜 스택 구현과 인터페이스해야 합니다. 이는 동작 구현을 프로토콜 바인딩의 세부사항에서 분리하기 때문입니다. WoT 런타임은 보통 기반 시스템과도 인터페이스합니다. 예를 들어 연결된 센서와 액추에이터 같은 로컬 하드웨어에 접근하거나 저장소 같은 시스템 서비스에 접근하기 위해서입니다. 두 인터페이스 모두 구현별로 다르지만, WoT 런타임은 자신이 구현하는 사물 추상화에 필요한 적응을 제공해야 합니다.

WoT 스크립팅 API 구성 요소는 WoT 사물 기술 명세 [WOT-THING-DESCRIPTION]를 밀접하게 따르는 ECMAScript API를 정의합니다. 이는 동작 구현과 스크립팅 기반 WoT 런타임 사이의 인터페이스를 정의합니다. 웹 브라우저 API를 위한 jQuery와 유사하게, 그 위에 다른 더 단순한 API를 구현할 수 있습니다.

자세한 내용은 [WOT-SCRIPTING-API]를 참조하십시오.

WoT 런타임은 TD를 기반으로 사물의 소프트웨어 표현을 인스턴스화합니다. 이러한 소프트웨어 표현은 동작 구현을 향한 인터페이스를 제공합니다.

노출된 사물 추상화는 로컬에서 호스트되고 서비언트의 프로토콜 스택 구현을 통해 외부에서 접근 가능한 사물을 나타냅니다. 동작 구현은 그 메타데이터와 상호작용 어포던스를 정의하고 자율 동작을 제공함으로써 노출된 사물을 완전히 제어할 수 있습니다.

소비된 사물 추상화는 통신 프로토콜을 사용해 접근해야 하는, 소비자를 위한 원격 호스트 사물을 나타냅니다. 소비된 사물은 프록시 객체 또는 스텁입니다. 동작 구현은 그 메타데이터를 읽고 해당 TD에 설명된 대로 상호작용 어포던스를 활성화하는 것으로 제한됩니다. 소비된 사물은 로컬 하드웨어나 독점 또는 레거시 통신 프로토콜 뒤에 있는 장치와 같은 시스템 기능을 나타낼 수도 있습니다. 이 경우 WoT 런타임은 시스템 API와 소비된 사물 사이에 필요한 적응을 제공해야 합니다. 또한 예를 들어 애플리케이션 대면 API(예: WoT 스크립팅 API [WOT-SCRIPTING-API]에 정의된 discover() 메서드)를 통해 WoT 런타임이 제공하는 어떤 탐색 메커니즘이든 확장함으로써 해당 TD를 제공하고 동작 구현에서 사용할 수 있게 해야 합니다.

WoT 스크립팅 API를 사용할 때, 노출된 사물과 소비된 사물은 JavaScript 객체이며, 애플리케이션 스크립트가 이를 생성, 조작, 파괴할 수 있습니다. 그러나 예를 들어 다중 테넌트 서비언트에서는 보안 메커니즘을 통해 접근이 제한될 수 있습니다.

사물과 상호작용하기 위한 비밀 키와 같은 비공개 보안 데이터도 개념적으로 WoT 런타임이 관리하지만, 의도적으로 애플리케이션에 직접 접근 가능하게 만들지 않습니다. 실제로 가장 안전한 하드웨어 구현에서는 이러한 비공개 보안 데이터가 별도의 격리된 메모리(예: 보안 처리 요소 또는 TPM)에 저장되며, 공격 표면을 제한하고 이 데이터의 외부 공개를 방지하는 추상 작업 집합(격리된 프로세서와 소프트웨어 스택으로 구현될 수도 있음)만 제공됩니다. 비공개 보안 데이터는 상호작용을 승인하고 무결성과 기밀성을 보호하기 위해 프로토콜 바인딩이 투명하게 사용합니다.

서비언트의 프로토콜 스택은 노출된 사물의 WoT 인터페이스를 구현하고, 소비자가 (소비된 사물을 통해) 원격 사물의 WoT 인터페이스에 접근하는 데 사용됩니다. 이는 네트워크를 통해 상호작용하기 위한 구체적 프로토콜 메시지를 생성합니다. 서비언트는 여러 프로토콜을 구현할 수 있으며, 따라서 서로 다른 IoT 플랫폼과의 상호작용을 가능하게 하기 위해 여러 프로토콜 바인딩을 지원할 수 있습니다.

표준 프로토콜이 사용되는 많은 경우, 일반 프로토콜 스택을 사용하여 플랫폼별 메시지를 생성할 수 있습니다 (예: HTTP(S) 방언용 하나, CoAP(S) 방언용 하나, MQTT 솔루션용 하나 등). 이 경우 사물 기술의 통신 메타데이터는 올바른 스택을 선택하고 구성하는 데 사용됩니다(예: 올바른 헤더 필드를 가진 HTTP 또는 올바른 옵션을 가진 CoAP). 미디어 타입 [RFC2046]으로 식별되는 예상 페이로드 표현 형식(JSON, CBOR, XML 등)을 위한 파서와 직렬화기도 이러한 일반 프로토콜 스택 전반에서 공유될 수 있습니다.

자세한 내용은 [WOT-BINDING-TEMPLATES]를 참조하십시오.

WoT 런타임 구현은 통신 프로토콜을 통해 접근 가능한 것처럼 사물 추상화를 통해 동작 구현에 로컬 하드웨어 또는 시스템 서비스를 제공할 수 있습니다. 이 경우 WoT 런타임은 동작 구현이 프로토콜 스택 대신 내부적으로 시스템과 인터페이스하는 소비된 사물을 인스턴스화할 수 있게 해야 합니다. 이는 애플리케이션 대면 WoT 런타임 API가 제공하는 탐색 메커니즘의 결과에, 로컬 WoT 런타임에서만 사용할 수 있는 이러한 시스템 사물을 나열함으로써 수행될 수 있습니다.

장치는 서비언트 외부에 물리적으로 존재하지만, 독점 프로토콜이나 WoT 인터페이스로 적합하지 않은 프로토콜을 통해 연결될 수도 있습니다 (6.7 프로토콜 바인딩 참조). 이 경우 WoT 런타임은 독점 API를 통해 이러한 프로토콜 (예: ECHONET Lite, BACnet, X10, I2C, SPI 등)을 사용하는 레거시 장치에 접근할 수 있지만, 다시 사물 추상화를 통해 이를 동작 구현에 노출하도록 선택할 수 있습니다. 그러면 서비언트는 레거시 장치로 가는 게이트웨이 역할을 할 수 있습니다. 이는 레거시 장치를 WoT 사물 기술을 사용하여 직접 설명할 수 없는 경우에만 수행해야 합니다.

동작 구현은 독점 API나 다른 수단을 통해 로컬 하드웨어 또는 시스템 서비스(예: 저장소)에 접근할 수도 있습니다. 그러나 이는 이식성을 저해하므로 W3C WoT 표준화의 범위를 벗어납니다.

WoT 스크립팅 API 구성 요소는 선택 사항입니다. WoT 런타임이 어떤 프로그래밍 언어로든 작성될 수 있는 애플리케이션 로직을 위한 대체 API를 제공하는 대체 서비언트 구현도 가능합니다.

또한 W3C WoT를 알지 못하는 장치나 서비스도, 잘 구성된 WoT 사물 기술을 제공할 수 있다면 여전히 소비될 수 있습니다. 이 경우 TD는 블랙박스 구현을 가진 사물의 WoT 인터페이스를 설명합니다.

8.8.1 네이티브 WoT API

개발자가 WoT 스크립팅 API를 사용하지 않고 서비언트를 구현하기로 선택할 수 있는 이유는 여러 가지가 있습니다. 메모리나 계산 자원이 부족하여 필요한 소프트웨어 스택이나 완전한 기능을 갖춘 스크립팅 엔진을 사용할 수 없기 때문일 수 있습니다. 또는 사용 사례(예: 독점 통신 프로토콜)를 지원하기 위해 특정 프로그래밍 환경이나 언어를 통해서만 사용할 수 있는 특정 함수나 라이브러리를 사용해야 할 수도 있습니다.

이 경우에도 WoT 런타임을 사용할 수 있지만, WoT 스크립팅 API 대신 대체 애플리케이션 대면 인터페이스를 사용하여 동등한 추상화와 기능을 노출합니다. 후자를 제외하면, 8. 추상 서비언트 아키텍처의 모든 블록 설명은 그림 33에도 유효합니다.

8.8.2 기존 장치를 위한 사물 기술

기존 IoT 장치나 서비스를 W3C 웹 사물에 통합하고, 이러한 장치나 서비스를 위한 사물 기술을 생성하여 사물로 사용할 수도 있습니다. 이러한 TD는 수동으로 만들거나 도구 또는 서비스를 통해 만들 수 있습니다. 예를 들어 다른 생태계 의존적 기계 판독 가능 형식이 제공하는 메타데이터를 자동 변환하는 서비스가 TD를 생성할 수 있습니다. 그러나 이는 대상 장치가 프로토콜 바인딩을 사용해 설명될 수 있는 프로토콜을 사용하는 경우에만 가능합니다. 이에 대한 요구사항은 6.7 프로토콜 바인딩에 제시되어 있습니다. 앞선 논의의 상당 부분은 또한 사물이 자체 사물 기술을 제공한다는 점을 암시합니다. 이는 유용한 패턴이지만 필수는 아닙니다. 특히 기존 장치를 수정하여 자체 사물 기술을 직접 제공하게 하는 것이 불가능할 수 있습니다. 이 경우 사물 기술은 디렉터리와 같은 서비스 또는 다른 외부의 별도 배포 메커니즘을 사용하여 별도로 제공되어야 합니다.

사물 역할의 서비언트는 사물 기술 (TD)을 기반으로 노출된 사물을 생성합니다. TD는 게시되어 소비자 또는 중개자 역할에 있는 다른 서비언트가 사용할 수 있게 됩니다. TD는 여러 다른 방식으로 게시될 수 있습니다: TD는 사물 기술 디렉터리 서비스와 같은 관리 시스템에 등록될 수 있고, 또는 사물이 TD에 대한 요청을 수신하면 요청자에게 TD를 제공할 수 있습니다. 특정 애플리케이션 시나리오에서는 TD를 사물과 정적으로 연결하는 것도 가능합니다.

소비자 역할의 서비언트는 탐색 메커니즘을 사용하여 사물의 TD를 얻고, 얻은 TD를 기반으로 소비된 사물을 생성합니다. 구체적인 탐색 메커니즘은 개별 배포 시나리오에 따라 달라집니다. 예를 들어 사물 기술 디렉터리와 같은 관리 시스템, 탐색 프로토콜, 정적 할당 등을 통해 제공될 수 있습니다. 다른 곳에서 논의한 것처럼, 가능할 때마다 [WOT-DISCOVERY]에 정의된 탐색 메커니즘을 사용하는 것이 권장됩니다.

그러나 식별 가능한 개인과 연결된 장치를 설명하는 TD는 개인정보에 민감한 정보를 추론하는 데 사용될 가능성이 있다는 점에 유의해야 합니다. 따라서 이러한 TD의 배포에 대한 제약은 구체적인 TD 탐색 메커니즘에 포함되어야 합니다. 가능하다면 특정 사용 사례에 엄격히 필요하지 않은 경우 ID나 사람이 읽을 수 있는 정보를 필터링하는 등 TD에 노출되는 정보를 제한하기 위한 조치도 취해야 할 수 있습니다. 개인정보 보호 문제는 11. 개인정보 보호 고려사항에서 높은 수준으로 논의되며, 더 자세한 논의는 [WOT-THING-DESCRIPTION] 명세에 제시되어 있고 [WOT-DISCOVERY] 명세에서 다루어집니다.

연결된 센서 및 액추에이터와 상호작용하는 것과 같은 장치의 내부 시스템 기능도 선택적으로 소비된 사물 추상화로 표현될 수 있습니다.

소비된 사물이 지원하는 기능은 프로그래밍 언어 인터페이스를 통해 소비자의 동작 구현에 제공됩니다. WoT 스크립팅 API에서, 소비된 사물은 객체로 표현됩니다. 사물에서 실행되는 동작 구현 (즉, 애플리케이션 로직)은 노출된 사물이 제공하는 프로그래밍 언어 인터페이스를 사용하여 소비자와 상호작용 어포던스를 통해 관여할 수 있습니다.

사물은 반드시 물리적 장치를 나타낼 필요는 없습니다. 사물은 장치 모음이나 게이트웨이 또는 클라우드에서 실행되는 가상 서비스를 나타낼 수도 있습니다. 마찬가지로 소비자는 게이트웨이 또는 클라우드에서 실행되는 애플리케이션이나 서비스를 나타낼 수 있습니다. 소비자는 에지 장치에서도 구현될 수 있습니다. 중개자에서는 단일 서비언트가 단일 WoT 런타임을 공유하면서 사물과 소비자 역할을 동시에 수행합니다.

이 절에서는 WoT 시스템의 다양한 토폴로지와 배포 시나리오를 논의합니다. 이는 예시 패턴일 뿐이며 다른 상호연결 토폴로지도 가능합니다. 여기서 설명하는 토폴로지는 웹 사물 사용 사례 및 요구사항 [WOT-USE-CASES-REQUIREMENTS]에서 도출되었습니다.

9.2.1 동일한 네트워크의 소비자와 사물

그림 35에 보인 가장 단순한 상호연결 토폴로지에서는 소비자와 사물이 동일한 네트워크에 있으며, 중개자 없이 서로 직접 통신할 수 있습니다. 이러한 토폴로지가 나타나는 사용 사례 중 하나는 소비자가 게이트웨이에서 실행되는 오케스트레이션 서비스 또는 다른 IoT 애플리케이션이고, 사물이 센서 또는 액추에이터와 인터페이스하는 장치인 경우입니다. 그러나 클라이언트/서버 관계는 쉽게 반대로 될 수도 있습니다. 클라이언트가 소비자 역할의 장치이고, 게이트웨이 또는 클라우드에서 사물로 실행되는 서비스에 접근할 수도 있습니다.

사물이 클라우드에 있고 소비자가 로컬 네트워크에 있는 경우(스마트 홈 사용 사례의 예는 그림 1 참조), 실제 네트워크 토폴로지는 더 복잡할 수 있습니다. 예를 들어 NAT 통과가 필요하고 특정 형태의 탐색이 허용되지 않을 수 있습니다. 이러한 경우에는 뒤에서 논의하는 더 복잡한 토폴로지 중 하나가 더 적절할 수 있습니다.

9.2.2 중개자를 통해 연결된 소비자와 사물

중개자는 네트워크에서 사물 및 소비자 역할을 모두 수행하며, 그 WoT 런타임 내부에서 노출된 사물 및 소비된 사물 소프트웨어 추상화를 모두 지원합니다. 중개자는 장치와 네트워크 사이의 프록시에 사용되거나 디지털 트윈에 사용될 수 있습니다.

9.2.2.1 프록시 역할을 하는 중개자

중개자의 간단한 적용 중 하나는 사물을 위한 프록시입니다. 중개자가 프록시로 동작할 때, 이는 두 개의 별도 네트워크 또는 프로토콜에 대한 인터페이스를 가집니다. 여기에는 TLS 엔드포인트 제공과 같은 추가 보안 메커니즘 구현이 포함될 수 있습니다. 일반적으로 프록시는 상호작용의 집합을 수정하지 않으므로, 중개자가 노출하는 TD는 소비된 TD와 동일한 상호작용을 가지지만 연결 메타데이터는 수정됩니다.

이 프록시 패턴을 구현하기 위해 중개자는 사물의 TD를 얻고 소비된 사물을 생성합니다. 이는 동일한 상호작용 어포던스를 가지는 소프트웨어 구현으로서 사물의 프록시 객체를 생성합니다. 그런 다음 새 식별자와, 가능하다면 새로운 통신 메타데이터(프로토콜 바인딩) 및/또는 새로운 공개 보안 메타데이터를 가진 프록시 객체용 TD를 생성합니다. 마지막으로 이 TD를 기반으로 노출된 사물이 생성되고, 중개자는 적절한 게시 메커니즘을 통해 다른 소비자 또는 중개자에게 TD를 알립니다.

9.2.2.2 디지털 트윈 역할을 하는 중개자

더 복잡한 중개자는 디지털 트윈으로 알려질 수 있습니다. 디지털 트윈은 프로토콜을 수정하거나 네트워크 간 변환을 할 수도 있고 하지 않을 수도 있지만, 상태 캐싱, 지연 업데이트, 또는 대상 장치 동작의 예측 시뮬레이션과 같은 추가 서비스를 제공합니다. 예를 들어 IoT 장치의 전력이 제한되어 있다면, 비교적 드물게 깨어나 디지털 트윈과 동기화한 뒤 즉시 다시 절전 상태로 들어가도록 선택할 수 있습니다. 이 경우 일반적으로 디지털 트윈은 전력 제약이 더 적은 장치(예: 클라우드 또는 게이트웨이)에서 실행되며(c.f. 장치 범주), 제한 장치를 대신하여 상호작용에 응답할 수 있습니다. 속성의 현재 상태에 대한 요청도 캐시된 상태를 사용하여 디지털 트윈이 충족할 수 있습니다. 대상 IoT 장치가 절전 상태일 때 도착하는 요청은 큐에 저장되었다가 장치가 깨어날 때 전송될 수 있습니다. 이 패턴을 구현하려면 중개자, 즉 디지털 트윈이 장치가 언제 깨어 있는지 알아야 합니다. 장치를 사물로 구현할 때는 이를 위한 알림 메커니즘을 포함해야 할 수 있습니다. 이는 별도의 소비자/사물 쌍을 사용하거나, 이를 위해 이벤트 상호작용을 사용하여 구현할 수 있습니다.

9.2.3 클라우드 서비스에서 제어되는 로컬 네트워크의 장치

스마트 홈 사용 사례에서, 홈 네트워크에 연결된 장치(센서 및 가전제품)는 종종 클라우드 서비스에 의해 모니터링되고, 경우에 따라 제어되기도 합니다. 일반적으로 장치가 연결된 홈 네트워크와 클라우드 사이에는 NAT 장치가 있습니다. NAT 장치는 IP 주소를 변환하고, 종종 연결을 선택적으로 차단하는 방화벽 서비스도 제공합니다. 로컬 장치와 클라우드 서비스는 통신이 게이트웨이를 성공적으로 통과할 수 있는 경우에만 서로 통신할 수 있습니다.

ITU-T 권고 Y.4409/Y.2070 [Y.4409-Y.2070] 에서 채택된 전형적인 구조는 그림 37에 보입니다. 이 구조에는 로컬 및 원격 중개자가 모두 있습니다. 로컬 중개자는 여러 사물의 상호작용 어포던스를 하나의(또는 일련의) 노출된 사물로 집계하며, 이는 모두 공통 프로토콜(예: HTTP, 모든 상호작용을 공통 기반 서버와 단일 포트를 사용하는 단일 URL 네임스페이스에 매핑)로 매핑될 수 있습니다. 이는 로컬 중개자가 NAT 장치를 통과할 수 있는 수렴된 프로토콜을 사용했고 이 서비스를 인터넷에 노출할 방법(STUN, TURN, 동적 DNS 등)을 가지고 있다고 가정할 때, 원격 중개자가 NAT 장치 뒤의 모든 사물에 접근하는 간단한 방법을 제공합니다. 또한 로컬 중개자는 사물 프록시로 기능할 수 있으므로, 연결된 사물이 각각 다른 프로토콜(HTTP, MQTT, CoAP 등) 및/또는 서로 다른 생태계 관례 집합을 사용하더라도, 노출된 사물은 이를 단일 프로토콜로 수렴하여 소비자가 사물이 사용하는 다양한 프로토콜을 알 필요가 없도록 할 수 있습니다.

그림 37에는 NAT 경계 뒤에 있는 서비스를 집계하고 추가적인 프로토콜 변환 또는 보안 서비스를 제공할 수 있는 원격 중개자에 연결된 두 클라이언트가 있습니다. 특히 로컬 중개자가 용량이 제한된 네트워크에 있을 수 있으며, 해당 서비스를 모든 사용자에게 직접 제공하는 것은 실현 가능하지 않을 수 있습니다. 이 경우 로컬 중개자에 대한 접근은 원격 중개자에게만 제공됩니다. 그런 다음 원격 중개자는 더 일반적인 접근 제어 메커니즘을 구현하고, 과도한 트래픽으로부터 소비자를 보호하기 위해 캐싱이나 스로틀링도 수행할 수 있습니다. 이러한 소비자도 공개 인터넷에 적합한 단일 프로토콜 (예: HTTPS)을 사용하여 중개자와 통신하므로, 클라이언트 개발이 훨씬 단순해집니다.

이 토폴로지에서는 소비자와 사물 사이에 NAT 및 방화벽 기능이 있지만, 로컬 및 원격 중개자가 함께 작동하여 방화벽을 통해 모든 통신을 터널링하므로, 소비자와 사물은 방화벽에 대해 아무것도 알 필요가 없습니다. 쌍을 이룬 중개자는 접근 제어와 트래픽 관리를 제공함으로써 홈 장치도 보호합니다.

더 어려운 경우에는 NAT 및 방화벽 통과가 그림에 보인 것과 정확히 같이 작동하지 않을 수 있습니다. 특히 ISP가 공개적으로 접근 가능한 주소를 지원하지 않거나, STUN/TURN 및/또는 동적 DNS가 지원되지 않거나 사용 불가능할 수 있습니다. 이 경우 중개자는 초기 연결을 설정하기 위해 그들 사이의 클라이언트/서버 역할을 대신 반대로 할 수 있습니다(로컬 중개자가 먼저 클라우드의 원격 중개자에 연결). 그런 다음 한 쌍의 중개자는 예를 들어 연결을 보호하기 위해 TLS를 사용하는 Secure WebSocket을 사용하여 터널을 설정할 수 있습니다. 그런 다음 이 터널을 사용하여 사용자 정의 프로토콜로 중개자 사이의 모든 통신을 인코딩할 수 있습니다. 이 경우 초기 연결은 여전히 표준 포트를 사용하는 HTTPS를 통해 이루어질 수 있으며, 로컬 중개자에서 원격 중개자로의 연결은 일반 브라우저/웹 서버 상호작용과 동일합니다. 이는 대부분의 홈 방화벽을 통과할 수 있어야 하며, 연결이 나가는 방향이므로 네트워크 주소 변환도 문제가 되지 않습니다. 그러나 사용자 정의 터널링 프로토콜이 필요하더라도, 원격 중개자는 여전히 이 사용자 정의 프로토콜을 표준 외부 프로토콜로 다시 변환할 수 있습니다. 연결된 소비자와 사물은 이에 대해 알 필요가 없습니다. 또한 이 예를 NAT 경계의 양쪽에 사물과 소비자가 모두 연결될 수 있는 사용 사례로 확장하는 것도 가능합니다. 그러나 이 경우도 두 중개자 사이에 양방향 터널이 설정되어야 합니다.

9.2.4 사물 기술 디렉터리를 사용한 탐색

로컬 장치(및 가능하면 서비스)가 클라우드상의 서비스에 의해 모니터링되거나 제어될 수 있게 되면, 그 위에 다양한 추가 서비스를 구축할 수 있습니다. 예를 들어 클라우드 애플리케이션은 수집된 데이터의 분석을 기반으로 장치의 동작 조건을 변경할 수 있습니다.

그러나 원격 중개자가 클라이언트 애플리케이션을 서비스하는 클라우드 플랫폼의 일부인 경우, 클라이언트는 예를 들어 연결된 장치의 디렉터리에 접근함으로써 장치 정보를 찾을 수 있어야 합니다. 아래 그림에서는 단순성을 위해 모든 로컬 장치가 사물로 구현되고, 모든 클라우드 애플리케이션이 소비자로 구현된다고 가정했습니다. 사물로 구현된 로컬 장치의 메타데이터를 클라우드 애플리케이션에서 사용할 수 있게 하기 위해, 그 메타데이터를 사물 기술 디렉터리 서비스에 등록할 수 있습니다. 이 메타데이터는 구체적으로 원격 중개자가 제공하는 공개 보안 메타데이터와 통신 메타데이터(프로토콜 바인딩)를 반영하도록 수정된 로컬 장치의 TD입니다. 그러면 클라이언트 애플리케이션은 사물 기술 디렉터리를 쿼리하여 자신의 기능을 달성하기 위해 로컬 장치와 통신하는 데 필요한 메타데이터를 얻을 수 있습니다.

그림에 표시되지 않은 더 복잡한 상황에서는 사물로 동작하는 클라우드 서비스도 있을 수 있습니다. 이들도 사물 기술 디렉터리에 자신을 등록할 수 있습니다. 사물 기술 디렉터리는 웹 서비스이므로, NAT 또는 방화벽 장치를 통해 로컬 장치에 보여야 하며, 그 인터페이스도 자체 TD와 함께 제공될 수 있습니다. 소비자로 동작하는 로컬 장치는 그런 다음 사물 기술 디렉터리를 통해 클라우드의 사물을 탐색하고, 예를 들어 프로토콜 변환이 필요한 경우 로컬 중개자를 통해 또는 직접 사물에 연결할 수 있습니다.

9.2.5 여러 도메인에 걸친 서비스 간 연결

서로 다른 IoT 플랫폼에 기반한 여러 클라우드 생태계는 함께 동작하여 더 큰 시스템-오브-시스템 생태계를 만들 수 있습니다. 앞서 논의한 클라우드 애플리케이션 생태계 구조를 바탕으로, 아래 그림은 두 생태계가 서로 연결되어 시스템-오브-시스템을 형성하는 모습을 보여줍니다. 한 생태계의 클라이언트 (즉, 아래의 소비자 A)가 다른 생태계의 서버(즉, 아래의 사물 B)를 사용해야 하는 경우를 고려해 보십시오. 이러한 교차 생태계 애플리케이션-장치 통합을 달성하는 메커니즘은 둘 이상입니다. 아래에서는 이를 어떻게 달성할 수 있는지 보여주기 위해 각각 그림을 사용하여 두 가지 메커니즘을 설명합니다.

9.2.5.1 사물 기술 디렉터리 동기화를 통한 연결

그림 39에서 사물 기술 디렉터리의 두 인스턴스는 정보를 동기화하며, 이를 통해 소비자 A가 사물 기술 디렉터리 A를 통해 사물 B의 정보를 얻을 수 있습니다. 이전 절에서 설명한 것처럼, 원격 중개자 B는 사물 B의 섀도 구현을 유지합니다. 이 섀도 장치의 TD를 얻음으로써, 소비자 A는 원격 중개자 B를 통해 사물 B를 사용할 수 있습니다.

9.2.5.2 프록시 동기화를 통한 연결

그림 40에서 두 원격 중개자는 장치 정보를 동기화합니다. 원격 중개자 B에서 사물 B의 섀도가 생성되면, 섀도의 TD가 동시에 원격 중개자 A로 동기화됩니다. 이어서 원격 중개자 A는 사물 B에 대한 자체 섀도를 생성하고, TD를 사물 기술 디렉터리 A에 등록합니다. 이 메커니즘에서는 사물 기술 디렉터리 서비스 사이의 동기화가 필요하지 않습니다.

이상적으로는 모든 그린필드 WoT 시스템에서 구성 요소 개발의 시작부터 접근성을 고려해야 합니다. 구성 요소의 하드웨어가 자체 디스플레이나 다른 형태의 물리적 사용자 인터페이스를 가진 경우, 이는 가능한 한 접근 가능해야 합니다. 접근 가능하게 만들 수 없다면(예: 화면 크기 제한 때문에), 접근 가능한 인터페이스(예: 웹 또는 음성 인터페이스)를 대신 사용할 수 있도록 동등한 기능이 네트워크를 통해 제공되어야 합니다. 구성 요소가 네트워크를 통해 접근될 때는, 장치에 직접 호스팅되든 다른 구성 요소(예: 대시보드)가 제공하든 접근 가능한 웹 인터페이스를 위한 대비가 마련되어야 합니다. 온보딩 중처럼 온보드 하드웨어가 인터페이스의 유일한 선택지인 상황은 가능한 한 접근 가능하도록 신중하게 설계되어야 합니다.

• 웹 기반 사용자 인터페이스의 경우 접근성에 관한 관련 지침은 W3C 웹 콘텐츠 접근성 지침 [WCAG22]에서 찾을 수 있습니다.
• 더 일반적으로 EN 301 549 [etsi-en-301-549]는 하드웨어 및 기타 사용자 인터페이스, 특히 "폐쇄형 기능" 장치에서 실행되는 소프트웨어/펌웨어에 대한 지침을 제공합니다.

일반적으로 사물은 WCAG와 EN 301 549에 따라 완전히 접근 가능한 사용자 인터페이스를 적어도 하나(직접 또는 네트워크 기반) 항상 가져야 합니다. 접근성은 제조업체, 설치자, 장치 소유자, 최종 사용자 등 모든 유형의 사용자에게 제공되는 인터페이스에 적용되어야 합니다.

사물의 사용자 인터페이스에 대한 접근성 상태는 사물의 메타데이터에 선언되어야 하며, 이를 통해 사용자가 자신에게 가장 적합한 사용자 인터페이스를 선택할 수 있어야 합니다. 사물이 웹 인터페이스를 가진 경우, 웹 인터페이스를 설명하는 기존 메커니즘을 사용해야 합니다. 웹과 물리적 인터페이스 사이의 연결을 더 잘 지원하기 위해, WoT 사물 기술에 설명된 어포던스는 장치의 물리적 인터페이스와의 관계를 이해할 수 있는 방식으로 주석 처리되어야 합니다.

직접 사용자 인터페이스를 제공하지 않는 구성 요소도 적절한 데이터와 함수를 제공함으로써 접근성을 지원해야 합니다. 예를 들어 공공 사물(예: 티켓 기계 또는 ATM)의 개발자는 사용자가 청각, 시각 또는 기타 신호를 통해 사물을 물리적으로 식별하고 위치를 찾을 수 있게 하는 위치 확인 기능을 고려해야 합니다.

WoT의 브라운필드 적용은 WoT 메타데이터가 기존 장치를 설명하는 데 사용되지만, 설계 시 WoT가 고려되지 않았던 상황을 다룹니다. 이 경우 위의 많은 대비책이 여전히 적용됩니다. 예를 들어 장치를 모니터링하거나 제어하기 위해 다른 시스템이 제공하는 웹 인터페이스는 WCAG의 지침을 따라야 하며, 사물 기술은 어포던스를 적절히 주석 처리해야 합니다. 장치 자체의 물리적 인터페이스가 접근성 문제를 제공하는 경우, 그 네트워크 어포던스를 기반으로 한 대체 인터페이스로 이를 극복할 가능성이 있습니다.