CIM

ETSI ISG CIM 및 NGSI-LD

유럽전기통신표준협회 ETSI(European Telecommunications Standards Institute)는 우리나라의 한국정보통신기술협회 TTA(Telecommunications Technology Association)에 해당하는 통신 산업 분야의 표준화 기구로 스마트시티 관련 표준 개발을 다양한 방면에서 진행하고 있다. 특히, 기술 전문가 그룹을 통해 유럽 내 산업 표준을 개발하는 Industry Specification Group(ISG)를 통해 스마트시티 관련 표준 개발을 지원하고 있다. 그 중에서도 Context Information Management(CIM) 그룹에서는 이기종 데이터들을 상호연동하기 위해서 필요로 되어지는 시맨틱 기술과 컨텍스트 기반의 데이터관리를 제공하는 핵심 API의 집합체인 NGSI-LD 표준 개발을 진행하고 있다.

그림과 같이 ETSI ISG-CIM에서 개발하고 있는 NGSI-LD는 스마트시티에서 생산되는 다양한 상황정보인 컨텍스트 정보 관리를 위한 오픈 API 집합체로, OMA의 NGSI-9 과 NGSI-10의 인터페이스를 기반으로 하여 Linked Data 관련 최신 기술들을 통합하는 것을 목표로 한다. 특히, NGSI-LD는 각종 IoT 플랫폼과 기존 도시의 레거시 시스템에서 수집되는 데이터들을 메타데이터 모델을 포함하는 컨텍스트 기반의 정보로 접근할 수 있게 지원하는 것을 특징으로 한다.

NGSI-LD의 핵심은 모든 데이터들이 속성과 관계성을 가지는 그래프를 기초로 하는 정보모델을 통해서 정의된다는 것에 있다. NGSI-LD 정보모델은 시맨틱 웹 기술을 기반으로 데이터 표현 매커니즘 지정 및 컨텍스트 정보관리 어휘의 구조를 지정함으로써 기존 OMA NGSI 정보모델을 확장시켰다. 또한, NGSI-LD 정보모델은 핵심 메타 모델과 서로 다른 도메인 사이의 상호운용성을 제공하는 크로스 도메인 온톨로지를 기초로 하여 서로 상이한 도메인 사이에서 발생 가능한 클래스 충돌 및 중복 등의 문제를 해결하였다. 이러한 기술을 기반으로 정의된 NGSI-LD API는 RESTful 기반으로 정의되어 기존 사물인터넷 및 웹기반 기술처럼 손쉽게 사용될 수 있으며, Javascript Simple Object NotationLinked Data(JSON-LD)로 표현이 가능하여 특정 도메인에 따라 확장하여 활용되어질수 있다.

NGSI-LD는 스마트시티의 주차관리 시스템, 군중 모니터링 및 비상상황 대응, 대기환경 등을 고려한 교통관리, 스마트 가로등 등 다양한 분야에 적용되어질 수 있다. 특히,NGSI-LD에서는 “@context” 섹션을 사용하여 데이터를 전송할 수 있게 했는데, 이는 데이터의 메타정보를 제공하고, Uniform Resource Indicator(URI)를 사용하여 각각의 도메인에서 공통적으로 적용이 가능한 공통 온톨로지에 연결될 수 있게 하여 상호운용성 기능을 제공한다. 예를 들면, NGSI-LD를 활용한 스마트 주차 애플리케이션의 경우 주차시설 관리자와 주차 공간을 찾는 운전자에게 필요한 정보와 서비스를 제공함으로써 도시의 교통 정체에 따른 시간 손실 문제를 해결할 수 있다. NGSI-LD 적용을 통해 기 사용중인 여러 주차 애플리케이션의 비교를 할 수 있으며, 이는 서비스에 필요한 핵심 데이터 및 상황정보의 추출을 가능하게 한다. 서비스에 연관된 에이전트와 관련된 데이터 자원(센서, 엑추에이터 등)을 통합하여 주차장 관리, 운전자 주차 안내, 교통 관리 등과 같은 여러 시스템들을 컨텍스트 기반 하에 상호작용할 수 있도록 도움을 줄 수 있다.

JSON-LD :
json 으로 Linked Data 를 인코딩하는 방식

  "@context": {
    "name": "http://xmlns.com/foaf/0.1/name",
    "homepage": {
      "@id": "http://xmlns.com/foaf/0.1/workplaceHomepage",
      "@type": "@id"
    },
    "Person": "http://xmlns.com/foaf/0.1/Person"
  },
  "@id": "https://me.example.com",
  "@type": "Person",
  "name": "John Smith",
  "homepage": "https://www.example.com/"
}

온톨리지 :
사람들이 세상에 대하여 보고 듣고 느끼고 생각하는 것에 대하여 서로 간의 토론을 통하여 합의를 이룬 바를, 개념적이고 컴퓨터에서 다룰 수 있는 형태로 표현한 모델로, 개념의 타입이나 사용상의 제약조건들을 명시적으로 정의한 기술

“@context” :
NGSI-LD 정보 모델에 의해 정의된 핵심 개념

NGSI-LD Meta Model

NGSI-LD는 Linked Data를 직렬화하기 위한 JSON 기반 형식인 JSON-LD [2]를 기반으로한다. JSON-LD의 내용 @context에는 아래 열거된 매핑과 기타 여러 매핑이 포함됩니다. 실제로 다른 엔터티(연결된 데이터)를 가리키고 있으므로 로 refPointOfInterest레이블이 지정되어 있는 것을 관찰합니다 . @id반면에 항상 암시적이며 덮어쓸 수 없는 핵심 JSON-LD와 관련이 있으므로 에 포함되지 않은 location또는 와 같은 특정 용어가 있습니다 .unitCode@context@context

@context:
JSON-LD의 @context는 문자열로 제공되는 용어를 URI로 지정된 개념에 매핑하는 데 사용됩니다.핵심 NGSI-LD (JSON-LD) @ 컨텍스트는 다음을 포함하는 JSON-LD @ 컨텍스트로 정의된다.

• 핵심 용어는 절 4.2에 의해 위임된 NGSI-LD 정보 모델에 의해 정의된 핵심 개념을 고유하게 나타낼 필요가 있다.

• 조항 5.2 및 조항 5.3에 따라 API 관련 데이터 유형을 정의하는 모든 구성원을 고유하게 나타내는 데 필요한 용어이다.

NGSI-LD 호환 구현은 이러한 핵심 @context를 지원해야하며 컨텍스트 정보를 처리하거나 생성할 때 암묵적으로 존재해야 한다.
NGSI-LD 요소를 렌더링할 때 Core @context는 항상 참조되어야하므로 필요한 경우 JSON-LD 프로세서가 API 구현에서 제공하는 결과 JSON-LD 문서를 올바르게 확장할 수 있다.
핵심 @ 컨텍스트는 구현에 의해 만들어진 NGSI-LD 페이로드를 처리하는 동안 불변하고 불변하다.

NGSI-LD Data Representation(NGSI-LD 데이터 표현)

NGSI-LD 엔티티는 JSON-LD [2]를 사용하여 인코딩된 객체로 표현되어야 한다
Annex D는 알고리즘의 관점에서이 프로세스에 대한 계산 설명을 제공한다.
핵심 NGSI-LD @ 컨텍스트에 의해 정의된 용어 외에도 @ 컨텍스트에는 적어도 다음 용어가 포함되어야 합니다.

• Entity Type과 관련된 하나의 용어로, Entity Type Name을 Type Identifier(URI)와 매핑한다.

• 엔티티 표현에 사용되는 각 속성의 이름과 관련된 하나의 용어(아래 참조)는 속성 이름을 속성 식별자(URI)와 매핑한다.속성의 범위가 기본 JSON 유형과 다른 데이터 유형인 경우 다음 형식으로 중첩된 JSON 객체를 사용하여이 용어로 명시 적으로 전달해야 한다.

• "@type": <Datatype's URI>.
• "@id": <Property's URI>.

NOTE 1: 동일한 속성 식별자를 가진 속성의 여러 인스턴스의 경우를 지원하기 위해 동일한 이름과 인덱스를 가진 여러 요소가 나타날 수 있다

)EXAPLE : 인덱스된 속성 이름을 동일한 속성 식별자에 매핑

• "speed#1": "http://example.org/speed",

• "speed#2": "http://example.org/speed"

엔티티 표현에 사용되는 각 관계의 이름과 관련된 용어 중 하나는 관계 이름을 관계 식별자 (URI)와 형식으로 매핑.

• "@type": "@id".

• "@id": <Relationship's URI>.

NOTE 2: 동일한 관계 식별자를 가진 관계의 여러 인스턴스의 경우를 지원하기 위해 동일한 이름과 색인을 가진 여러 요소가 나타날 수 있습니다.

JSON-LD 객체에는 최소한 다음 구성원이 포함되어야 함

• "id"의 값은 Entity를 식별하는 URI가 됨

• "type"은 Entity Type Name과 같은 값을 가짐

• @context는 나머지 JSON 콘텐츠와 함께 인라인으로 제공 될 수는 없지만 다른 옵션이 있을 수 있습니다.예를 들어, HTTP 바인딩에서 @context는 링크 헤더를 통해 사용할 수 있습니다 (6.3.5 절 참조).

• 명시된 규칙에 따라 각 속성에 대해 하나 이상의 (인덱스된 속성의 경우) 구성원.

• 명시된 규칙에 따라 각 관계에 대해 하나 이상의 (인덱스 된 관계의 경우) 회원.

NGSI-LD Property Representation(NGSI-LD 속성 표현)

Cross Domain Ontology

온라인 리뷰에는 종종 제품의 다양한 측면에 대한 자세한 감정이 포함되며 이러한 의견은 소비자가 제품에 익숙해지는 데 도움이 된다. 온라인 리뷰에서 도메인 온톨로지를 도입하면 소비자가 제품에 대한 관련 정보를 빠르게 얻을 수 있다. 그럼에도 불구하고 구매 결정을 위해 여러 도메인의 제품을 비교할 수 있다. 이를 기반으로 서로 다른 도메인의 제품을 비교하는 것은 온톨로지 정렬이 크로스 도메인 온톨로지를 형성하는 기본 작업임.

NGSI-LD Architectural considerations(NGSI-LD 아키텍처 고려사항)

NGSI-LD API는 주로 API로 설계되었으며 특정 아키텍처를 정의하지 않는다. 라고 생각되고 있다.
NGSI-LD API는 다른 아키텍처 설정에서 사용될 수 있으며 API의 아키텍처 가정은 다음과 같이 유지된다.

• NGSI-LD API를 사용할 수 있는 모든 가능한 아키텍처를 상세히 설명할 수 없기 때문에 세 가지 프로토타입이 있다
• NGSI-LD API는 이들 모두에 대한 효율적인 지원을 가능하게 해야 한다.
• NGSI-LD API는 하나로 매핑하거나 여러 개의 요소를 가져오거나 모든 프로토타입 아키텍처를 결합할 수 있다

Centralized architecture(중앙 집중식 아키텍처)

Central Broker: 중앙에서 모든 컨텍스트 정보를 저장한다.
Context Producer: 업데이트 작업을 사용하여 Central Broker의 컨텍스트 정보를 업데이트
Context Consumer: 동기화 기능을 사용하여 Central Broker에 컨텍스트 정보를 요청
Central Broker는 일회성 쿼리 또는 비동기 구독/비동기 작업이고 저장소의 모든 요청에 응답한다.
4.3.2-1은 Context Producer와 Context Consumer의 역할을 모두 하는 하나의 구성요소를 보여준다

Distributed architecture(분산 아키텍처)

4.3.3-1은 분산형 아키텍처를 보여준다, 여기서 기본 아이디어는 모든 정보가 컨텍스트에 의해 저장된다.

Context Sources는 Context Broker가 구현하는 것처럼 NGSI-LD API의 쿼리 및 구독 부분을 구현한다.
Context Registry에 자신을 등록하여 가능한 컨텍스트 정보에 대한 정보를 제공한다.
그들은 Context Registry에 등록하여 제공할 수 있는 컨텍스트 정보에 대한 정보를 제공하지만 컨텍스트 정보 자체는 제공하지 않습니다.특정 Context Source는 건물 A 및 건물 B의 실내 온도를 제공할 수 있거나 도시의 중심을 덮고 있는 지리적 영역에서 자동차의 속도를 제공할 수 있다고 등록합니다.

Federated architecture(연합 아키텍처)

4.3.4-1에 표시된 연합 아키텍처는 기존 도메인을 연합해야하는 경우에 사용된다.
예를 들어, 도시의 여러 부서는 Context Broker 기반 NGSI-LD 인프라를 운영하지만 응용 프로그램은 단한 지점의 액세스를 사용하여 사용 가능한 모든 정보에 쉽게 액세스할 수 있어야 한다.
아키텍처는 4.3.3 절에 설명된 분산 아키텍처와 동일한 방식으로 작동하지만 단순한 Context Source대신 전체 도메인이 액세스 지점으로 각 Context Broker에 등록된다.
일반적으로 도메인은 보다 거친 수준의 연합 Context Registry에 등록되어 요청에 제공된 범위와 일치할 수 있는 범위, 특히 지리적 범위를 제공한다. 예를 들어, 건물과 같은 개별 엔티티를 등록하는 대신 도메인은 지리적 영역 내의 건물 유형에 대한 엔티티 정보를 가지고 등록된다.
그런 다음 응용 프로그램은 지리적 범위 내에서 엔티티를 쿼라하거나 구독한다. Federation Server는 도시의 특정 지역에 있는 건물들에 대한 정보를 제공하고 이런 Broker 요청을 전달하고 결과를 집계할 수 있는 Domain Context Broker를 검색하므로 응용 프로그램은 중앙 집중식 및 분산된 경우와 동일한 방식으로 결과를 얻는다.