.png&blockId=55b72549-0ab6-4732-b0f5-618302f692a8&width=256)
배경지식 + 등장하는 단어
FIWARE
EU에서 개발 및 배포하고 있는 오픈소스 IoT 프레임워크이다.
IoT 스마트 솔루션을 제공하며, 표준 형식인 NGSI를 사용하여 Context Data를 수집하고 관리한다.
(이때의 Context Data는 entity의 현재 상태를 의미한다.)
[FIWARE 플랫폼 구조]
Context Data
실제 다루는 데이터는 너무 복잡. 데이터간의 관계를 담고 표현할 수 있어야 함
한 entity의 정보와 다른 entity와의 관계를 담고 있는 데이터이다.
FIWARE는 context data를 NGSI 형식으로 나타냄 (NGSI는 REST API 기반)
NGSI-v1 → NGSI-v2 → NGSI-LD 순서로 발전해왔으며
최근에는 최신버전인 NGSI-LD를 주로 사용한다.
NGSI-LD
NGSI-V2에서 linked data concept을 추가된 것이 NGSI-LD이다.
즉 한 entity에서 다른 entity에 대한 정보를 얻을 수 있다.
데이터 공유 작업을 수행하는 경우 NGSI-LD를 사용하면 된다.
•
JSON-LD 기반인 NGSI-LD는 @context 를 필수적으로 생성해야한다.
•
JSON-LD 형식은 전체 구조가 핵심 컨텍스트로 잘 정의되어 있기 때문에
컴퓨터가 더 쉽게 읽을 수 있다.
LD의 바뀐 점
1.
NGSI-LD request에서는 더이상 metadata가 필요없게 되었다.
2.
type 의 이름은 Property 이거나 Relationship 이다. (혹은 GeoProperty, LanguageProperty)
3.
Relationship에서는
{"type": "Relationship", "object": "urn: XXX~"}이다.
•
GET 요청을 할 경우 payload가 없으므로 링크 헤더에 @context를 써야 한다. 여기에 내 context file이 있다고 알려준다. 이 파일은 공개 서버(public server)에 있어야 한다.
•
mapping the short name to a full URI
잘 정의된 전체 URI를 짧은 이름에 매핑한다.
시스템 외부의 다른 시스템이 이것을 읽고 이해할 수 있다.
@context
•
@context 는 위치값을 보유한다.
•
@id 는 entity를 나타내는 고유한 URI를 갖는 표준 요소이다.
•
Data Model을 정의할 때,
id랑 type라는 entity는 무조건 있어야 한다. 이때 id는 고유해야한다.
Context Broker
Orion Context Broker는 entity의 상태(state)를 유지 관리하며, REST 호출을 사용하여 상태를 변경하거나 클라이언트 라이브러리를 사용하여 변경할 수 있다. FIWARE의 핵심 계층이다.
또는 웹서비스 같은 다른 소스에서 정보를 검색하여 entity의 데이터를 보강하거나 entity의 linked-data로 읽어올 수 있다.
*context broker는 메모리가 없다. 그래서 이전 상태를 기록하지 않고 현재 상태만을 가지고 있다.
그래서 이전상태를 기록하기 위해 데이터베이스를 활용한다. ( 주로 몽고DB를 사용한다.)
“Powered by FIWARE” = device가 컨텍스트 브로커를 사용한다는 뜻
”FIWARE ready” = device가 컨텍스트 브로커에 연결할 수 있다는 뜻
FIWARE에 연결하려는 장치가 있는 경우(즉 FIWARE ready로 만들려고한다면)
1. 기존 IoT Agent 가 있는 경우, FIWARE ready 상태라는 인증만 받으면 된다.
2. 지원되지 않는 프로토콜이 있는 경우, 본인만의 고유한 IoT Agent를 새로 만드는 메커니즘이 있다. 기본적으로 비어있는 end-point 를 제공하는 라이브러리가 있다. 여기에 수신하도록 수신할 프로토콜(HTTP or MQTT)를 설정한 다음 여기에 정보를 전달하면 된다.
IoT Agent
언어가 무엇이든, 어떤 형식이든 southbound interface 에서 API를 사용하여 구성할 수 있는 변환 계층이다. HTTP를 사용하여 직접 통신할 수 있고, MQTT 또한 사용할 수 있다.
IoT Agent는 특정 프로토콜(HTTP나 Ultralight)을 NGSI request로 변환하고 Context broker와 통신한다
south port : 맨 아래에서 오는 IoT device의 데이터를 수신한다.
north port: context broker와 통신한다.
[Northbound traffic (processing a measurement)]
1.
IoT device에서 측정값을 읽어 IoT Agent로 보낸다.
2.
IoT Agent는 Utralight or HTTP etc.. request로 device로 부터 받는다. device를 IoT database에서 검색하고 entity attributes를 Ultrlight syntax로 매핑한 후 Context Broker에게Context를 업데이트할것을 요청한다. (해당 장치의 프로토콜에서 NGSI로 translate 한다는뜻)
3.
Context Broker는 이제 context를 업데이트한다.
[Southbound traffic (processing a Command)]
1.
User는 switch on the lamp같은 요청을 한다.
2.
Context Broker는 context를 요청을 받아 IoT Agent에 context data의 권한을 위임한다.
3.
IoT Agent는 device를 IoT database에서 검색한다. 장치에 요청하기 전에 우선 Context Broker의 명령 상태를 “Pending state”로 바꾼다. 그러고 device에 switch on lamp 하기를 요청한다.
4.
IoT device는 lamp switched ON 상태가 되고 IoT Agent에 결과를 보고한다.
5.
IoT Agent는 Context Broker가 “Pending state”였던 명령 상태를 device가 보고한 result 내용으로 업데이트한다.
IoT Agent를 사용하면 기존 IoT domain에서의 문제점을 다음과 같이 해결할 수 있다.
1.
device로부터 받은 measurements를 common standard(NGSI)로 변환할 수 있다.
2.
user들은 device마다 각기 다른 protocol을 알 필요 없이 device에서 Context broker로 measurement가 전송되는 과정을 이해할 수 있다.
3.
수신된 데이터를 올바른 방식(정확하게)으로 매핑할 수 있다.
AWS 에서 FIWARE
