소개

스마터 시티 솔루션의 데이터 모델링 관련 표준에 관한 시리즈의 첫 번째 기사인 이 기사에서는 공중의 안전, 교통 및 수도와 같은 여러 가지 스마터 시티 도메인 전체에서 공통적으로 적용되는 핵심 개념을 집중적으로 살펴본다. 또한, 이 시리즈 기사의 다음 회에서는 다른 도메인의 표준에 대해서도 다룰 것이다.

Part 1의 기본적인 목표는 스마터 시티 솔루션의 데이터 모델링 관련 표준을 참조할 수 있게 하는 데 있다. 또한, 아직 표준이 정의되어 있지 않은 경우에는 갭을 확인한다. 이 기사에서는 기존의 표준을 사용하는 방법과 표준 갭을 처리하는 방법을 제시한다.

IBM 스마터 시티의 비전은 세상이 서로 더 많이 연결되고 인스트루먼트화되고 지능화되고 있으며 이로 인해 절약, 효율성 및 발전 가능성이 새롭게 부각될 수 있는 기회가 생기고 있다는 전제를 기반으로 한다. 이러한 전제는 표준이라는 기초적인 요소를 기반으로 한다.

표준이 필요한 대상

• 상호 운용성
• 데이터 표현 및 교환
• 수집
• 가상화
• 유연성

임시 솔루션을 개발할 수도 있지만, 이러한 임시 솔루션은 장기적으로 영향을 주는 데 한계가 있다.

도시는 본질적으로 이질적이고 이로 인해 다양한 벤더 솔루션이 기관과, 부서의 경계에 배치되는 경우가 자주 있다. 따라서 기관 간에 협업을 하거나 정보를 교환하기 어려워진다. 스마터 시티 솔루션은 전체 기관에서 구조화된 방식으로 사용하는 데 적절한 정보를 용이하게 분류하고 선택할 수 있어야 한다. 따라서 표준을 기반으로 하는 데이터 모델을 확립하는 것이 필수적이다.

데이터 모델은 정보를 구조화하는 방법과 시맨틱 레벨에서 정보가 표현하는 것을 정의한다. 다시 말해서 사고 보고서에서는 다음과 같은 작업을 수행하게 된다.

• 컨텐츠 정의
• 컨텐츠 구조 설정
• 기타 정보에 관계 설정

예를 들면, 사고 보고서는 사고 위치를 식별하는 데 도움이 되며 우편 주소나 지리적 좌표 또는 기타 위치 시스템을 사용하는 표시 데이터를 제공한다.

다른 기관에서 제공한 정보를 올바르게 해석하고 처리하기 위해서는 기본적인 데이터 모델을 이해해야 한다. 일반적으로 각 기관에서는 레거시 시스템(legacy system)으로 인한 제한조건 내에서 각 기관의 특정 요구사항을 처리하도록 설계된 자체 데이터 모델을 사용한다.

데이터 모델의 불일치를 일치시키는 작업이 매우 중요하다. 공통 스마터 시티 데이터 모델을 정의하면 기관에 특정된 모델에 맵핑하는 작업과 이 모델로부터 맵핑하는 작업이 공통 모델로 한정되므로 변환 프로세스가 단순해진다. 스마터 시티 솔루션에서는 공통 데이터 모델을 정의하고 활용하는 데 도움이 되도록 다양한 표준을 고려하고 사용해야 한다.

위로

시나리오: 계획된 도로작업

일반적인 도시 시나리오의 엔드투엔드 플로우(end-to-end flow)를 살펴보면 스마터 시티 정보 모델의 핵심 개념을 효과적으로 파악할 수 있다. 여기에서는 기존 표준의 컨텍스트를 정하고 표준 갭을 식별한다. 아래에 있는 계획된 도로작업 시나리오에서는 대부분의 스마터 시티 솔루션에 공통적으로 적용되는 핵심 개념을 강조한다. 이 섹션에서는 철저하게 분석하는 대신 실례를 보여줄 것이다.

간단한 설명

계획된 도로작업 시나리오는 앞으로 일어나게 될 이벤트로, 여기에는 번잡한 도시의 교차로에서 주요 도로를 수리하는 작업이 포함되어 있다. 도로 수리는 특정 날짜에 특정 위치에서 지정된 기간 동안 수행되도록 예정되어 있는 계획된 활동으로서 교통부에서 시행한다.

도로 수리를 조정하려면 영향을 받는 다른 도시 도메인(예: 버스, 기차, 수도, 유틸리티, 건물 및 공중의 안전)에 미치는 영향을 확인해야 한다. 이러한 도메인 간에 협업을 할 수 있으면 교통의 흐름이 전체적으로 중단되는 결과를 효과적으로 줄일 수 있을 뿐만 아니라 수리 기간을 단축시키고 전체 비용을 줄일 수 있다.

계획된 도로작업 시나리오를 조정하는 데 중요한 직원은 다음과 같다.

• 운영자
• 감독자
• 응답자
• 분석가
• 자산 관리자

이외에도 특정 응답의 효과와 이와 연관된 절차를 추적할 수 있는 많은 KPI(Key Performance Indicator)가 작성되고 유지된다. KPI의 예는 다음과 같다.

• 응답 시간
• 마감 시간
• 소요 비용
• 절감 효과
• 도시 서비스에 미치는 영향

기본적인 이벤트 플로우

1. 교통부의 자산 관리자가 번잡한 두 달 안에 도시 교차로의 주요 도로를 수리하는 계획(추정 기간이 1주일)을 세운다.
   1. 자산 관리자는 도로 수리를 관리하는 데 필요한 작업 명령서를 작성한다.
2. 작업 명령서를 받으면, 교통부 운영자가 다른 도시국과 수리 작업을 담당하는 부서에 통보할 공문을 작성한다.
3. 영향을 받은 기관과 부서에 있는 분석가가 초기 영향 분석을 수행하며 이 과정에서 분석가는 비즈니스 규칙과 분석론을 사용하는 것을 최적화하여 표준 운영 절차를 자동화한다.

   분석가가 기관에 특정된 영향을 확인하고 나면 모든 분석가가 공동으로 전체적인 분석을 수행한다(4단계 참조).

1. 버스 담당 부서에서는 버스 노선 중 하나가 영향을 받게 될 것이라고 판단한다.
2. 수도국에서는 도로 수리 작업이 수행되는 곳과 동일한 영역에서 파이프 유지보수 작업이 있을 것으로 판단한다.
3. 전기 유틸리티 담당 부서에서는 지하 인프라 유지보수 작업이 도로 수리 작업이 수행되는 곳과 동일한 영역에서 있을 것으로 판단한다.
4. 공공주택국에서는 여러 개의 건물이 영향을 받을 것으로 판단한다.
5. 경찰서에서는 교통이 혼잡한 시간에 도로 수리가 이루어지는 경우에는 교통을 통제할 경찰관을 현장에 파견해야 한다고 판단한다.
4. 영향을 받는 기관의 감독자는 기관 간 협업과 영향 분석을 시작한다.
   1. 영향을 받는 모든 기관과 부서에 있는 자산 관리자는 실행 계획을 조정하여 마무리한다.
   2. 도로 수리 작업은 여러 기관에 영향을 주게 되므로 도시 레벨에 있는 감독자가 작업 노력을 조정하는 전체적인 권한을 갖는다.
5. 도로, 버스, 수도, 유틸리티, 건물 및 공중의 안전을 담당하는 감독자는 각 자산 관리자가 계획을 짜고 유지보수를 시행하도록 통보한다.
   1. 안전이 보장되고 작업이 원활하게 수행되도록 전체 기관에서 작업이 조정된다.
   2. 적절한 방송을 통해 시민 공동체에 다음과 같은 경보를 발행한다.
      1. 도로 폐쇄 및 대체 노선
      2. 버스 운행시간 조정 및 노선 변경 계획
      3. 공중 식수 제공업체에 대한 급수 서비스 중단
      4. 유틸리티 서비스 중단(정전 계획 표시)
      5. 영향을 받는 건물의 거주자에 대한 건물 관리 서비스 중단
   3. 도시 레벨에 있는 감독자는 진행 사항을 잘 파악하고 목표가 완료되는지 확인한다.
6. 유지보수 작업은 스케줄에 따라 기관의 직원(응답자)이 조정하는 방식으로 완료된다.
   1. 영향을 받는 모든 기관의 작업 명령서는 폐기된다.
   2. 적절한 방송을 통해 시민 공동체에 경보를 발행한다.
7. 도시 레벨에 있는 감독자가 사후 검토 비용과 영향 분석을 실시하여 전체 응답의 효율성을 판별한다.

모델의 핵심 개념

위에서 살펴본 예정된 도로 작업 시나리오에 기초가 되는 모델 개념은 여러 가지가 있다(예: 조직, 경보, 사고, 사람, 자산, 작업 명령서, 프로세스, KPI 위치 및 시간). 이외에도 이러한 여러 가지 개념 간의 강력한 관계가 있다. 기존 표준의 적용성과 표준 갭의 확장성은 개념마다 상당히 다르다.

• 조직

• 정의: 특정 목적에 맞게 체계화된 인적 그룹
• 예: 경찰서, 공공주택국, 버스 담당 부서, 교통국, 수도국, 전기 유틸리티
• 핵심 속성: 이름, 조직 유형, 설명, ID, 웹 사이트
• 핵심 관계: 조직(상위-하위), 자산, 위치
• 표준 평가: National Information Exchange Model(NIEM): NIEM-Core(nc:)OrganizationType, UCore(Universal Core) 조직
• 경보
  • 정의: 절박한 사고가 발생할 때 시행되는 경고나 알람
  • 예: 도로 수리 경보
  • 핵심 속성: 송신자, 설명, 긴급성, 심각도, 확실성, 개시 시간, 위치, 지원 자원
  • 핵심 관계: 송신자(조직이나 사람), 위치, 사고, 작업 명령서
  • 표준 평가: Common Alerting Protocol(CAP)은 경보 개념을 광범위하게 지원한다. UCore Event 개념도 적용 가능하다.
• 사고
  • 정의: 대응이 필요한 사건
  • 예: 도로 수리, 자동차 사고, 수도관 파열, 범죄 활동
  • 핵심 속성: 사건이 발생한 날짜와 시간, 설명, ID
  • 핵심 관계: 위치, 경보, 작업 명령서, 소유자(조직 또는 사람)
  • 표준 평가: NIEM:nc:IncidentType, CAP:alert:incidents, UCore Event, SOA(Service-Oriented Architecture) Ontology Event
• 사람
  • 정의: 인간, 개인
  • 예: James, Bob, Sally
  • 핵심 속성: 전체 이름, 이름, 성, 성별, 생일, 출생지, 시민권, 출생국
  • 핵심 관계: 고용주, 위치, 주소, 조직, 역할(예: 운영자, 감독자, 응답자, 분석가, 자산 관리자)
  • 표준 평가: NIEM:nc:PersonType, UCore Person, SOA Ontology Human Actor
• 자산
  • 정의: 시간의 변화를 추적할 수 있는 유형의 객체
  • 예: 도로, 수도관, 전기 콘덴서, 버스, 건물
  • 핵심 속성: 설명, ID
  • 핵심 관계: 조직, 사람, 제조업체, 위치, 작업 명령서, 사고
  • 표준 평가: NIEM:ip: AssetType, UCore Entity
• 작업 명령서
  • 정의: 특정 작업을 수행하거나 수정, 수리 또는 대체하는 데 필요한 명령서
  • 예: 도로 수리, 기본 밸브의 유틸리티 유지보수, 버스 노선 변경
  • 핵심 속성: 설명, ID, 주석, 우선순위, 상태, 위치, 시작 날짜/시간, 중지 날짜/시간
  • 핵심 관계: 작업 단계, 작업 명령서(상위-하위), 사고, 경보, 조직, 유지보수 기록, 스펙, 사람, 자산
  • 표준 평가: 현재 확인된 관련 표준 없음

• 프로세스 및 절차
  • 정의: 목표를 달성하는 데 필요한 일련의 조치
  • 예: 도로 수리 통지 및 조정
  • 핵심 속성: 프로세스 문서화
  • 핵심 관계: 프로세스 단계: 작업 명령서, 사고, 경보, 조직, 사람, 자산
  • 표준 평가: SOA 온톨로지 프로세스
• KPI(Key Performance Indicator)
  • 정의: 사람, 프로세스 또는 사물의 상태나 성능을 분석하는 데 필요한 측정치나 기준
  • 예: 응답 시간, 마감 시간, 소요 비용, 절감액, 도시 서비스에 미치는 영향
  • 핵심 속성: 설명, 지표, 임계값
  • 핵심 관계: KPI(상위-하위), 조직, 사고, 경보, 프로세스 및 절차, 자산
  • 표준 평가: 현재 확인된 관련 표준 없음
• 위치
  • 정의: 좌표 시스템이나 이름 또는 주소를 기반으로 지구상에서 좌표로 식별되는 지리적 위치, 지점, 위치 또는 영역
  • 예: 도로 수리 위치: 도시 교차로, 수도관 위치
  • 핵심 속성: 지리 좌표, 우편 주소, 시간소인
  • 핵심 속성: 사람, 조직, 자산, 사고, 경보
  • 표준 평가: NIEM:nc:LocationType, UCore 위치, GML(Geography Markup Language) 위치, OpenGIS® OpenLS(Open Location Service) 위치
• 시간
  • 정의: 사건을 차례로 나열하고, 사건의 기간과 사건 간의 간격을 비교하고, 객체의 움직임과 같은 변화율을 정량화하는 데 사용되는 측정 시스템
  • 예: 시작 시간, 종료 시간
  • 핵심 속성: 년, 달, 주, 일, 시간, 분, 초, 밀리초
  • 핵심 관계: 기간
  • 표준 평가: NIEM:nc:DateTime, W3C DateTimeDescription

위로

표준 명세

이 섹션에서는 스마터 시티 모델링과 관련된 기존의 표준을 강조한다. 기존 표준을 간단히 설명하고 관련된 다른 표준과의 관계를 살펴본다. 또한 표준을 사용하는 방법을 제시한다. 이 문서에서는 NIMS(National Incident Management System) 등의 권장 표준 목록을 다룬다. (참고자료를 참조한다.)

NIEM(National Information Exchange Model)

NIEM은 모든 정부 레벨(연방정부, 주정부, 부족 및 지방정부)에 있는 기관 및 조직과 민간 기업의 협업적 파트너십을 나타내는, 미국 정부의 XML 기반 정보 교환 프레임워크이다. (참고자료에 있는 웹 사이트 세부사항을 참조한다.) 이 파트너십은 사법부, 공중안전국, 재난관리 기관, 국가정보국과 같은 다양한 도메인에서 주요 의사결정을 할 때 중요한 정보를 효과적이고 효율적으로 공유하는 데 그 목적이 있다. NIEM은 관할구에서 정보 공유를 자동화할 수 있게 하는 전사적 정보 교환 표준과 프로세스를 개발하여 퍼뜨리고 지원하기 위해 고안되었다.

NIEM 데이터 모델은 핵심 개념과 도메인에 특정된 개념으로 구성된다. 이 데이터 모델은 모든 도메인이나 거의 모든 도메인에서 공통적으로 사용되는 핵심 개념을 공유하고 판독한다. 핵심 엔티티의 예는 다음과 같다.

• 활동
• 주소
• 사례
• 날짜 및 시간
• 문서
• 항목
• 사건
• 위치
• 조직
• 사람

컴포넌트가 범용이 되려면 모든 도메인에서 해당 컴포넌트의 시맨틱과 구조에 동의해야 한다. 일단 확립되면 NIEM 범용 컴포넌트 세트는 안정적이며 비교적 작다.

NIEM을 이용하면 중복되는 시맨틱이 있는 경우에도 외부 표준을 쉽게 포함시킬 수 있다. 예를 들면, 외부 지리 컴포넌트의 어댑터 유형과 대체 그룹이 다음과 같은 용도로 정의된다.

• OSC(Open Geospatial Consortium)
• LIF(Logical Interchange Format)
• LandXML
• IAI(International Association for Interoperability)
• ANSI

NIEM의 도메인에 특정된 개념은 정부의 단일 국이나 구에 고유하다. NIEM 도메인에는 다음과 같은 것들이 포함된다.

• 생물측정학
• CBRN(Chemical, Biological, Radiological, and Nuclear)
• 긴급사태 관리
• 입국 관리
• 인프라 보호
• 인텔리전스
• 국제 무역
• 재판
• 해상 무역
• 차폐
• 아동 및 가족 지원 서비스

NIEM은 많은 연방기관과 주정부 및 지방정부에서 채택되었을 뿐만 아니라 다른 도메인으로도 확장되고 있다. 게다가 다른 국가의 정부기관에서도 NIEM을 고려하고 있다. 예를 들면, Eurojust와 SEMIC-EU는 유럽 정부의 교환 표준을 개발하는 과정에 NIEM을 조사하는 과정을 포함시켰다. 그러나 현재, NIEM은 국제 표준으로 간주되고 있지 않으며 국제적 어휘나 분류를 다루지도 않는다.

스마터 시티 모델링 노력은 NIEM의 핵심 개념과 도메인에 특정된 개념을 모두 사용하는 것으로 여겨져야 한다. 핵심 개념의 경우에는 사람, 장소, 사건 및 사물에 대한 개념이 특히 관련이 있다. 스마터 시티 모델은 NIEM을 준수하는 메시지를 소비하고 내보낼 수 있어야 한다.

UCore(Universal Core)

UCore(Universal Core)는 National Information Sharing Strategy 및 이와 연관된 모든 부서 및 기관의 전략을 지원하는, 미국 연방정부의 정보 공유 이니셔티브이다. (참고자료를 참조한다.) UCore를 이용하면 구현 가능한 스펙(XML 스키마)을 정의하고, 가장 일반적으로 공유되고 보편적으로 이해되는 네 가지(누가, 언제, 어디서, 무엇) 개념에 대한 표현에 동의하여 정보를 공유할 수 있다. UCore는 비슷하지 않은 시스템 간에 컨텐츠를 공유할 수 있도록 프레임워크, 메타데이터, 확장 규칙, 보안 표시 및 실제 스키마를 지정한다. 그러나 UCore를 작성하는 중요한 목적은 그것을 간단하고 설명하기 쉽고, 구현하기 쉽게 하는 데 있다.

용이하게 채택할 수 있게 하기 위해 UCore는 관심 커뮤니티나 지식 도메인을 설정하여 공통 어휘를 채택하는 것을 장려하고 있다. 많은 기관과 조직에서는 이미 정보 자산을 표현하고 공유하기 위한 형식을 사용하고 있다. 불행히도 이러한 형식은 커뮤니티의 경계에서는 호환되지 않는 경우가 많다. UCore가 고도로 개발된 도메인 내에서 공유하는 복잡한 데이터를 대체할 것으로 예상되지는 않는다. UCore를 이용하면 각 커뮤니티에서 자체적으로 정의한 스키마를 사용하여 계속해서 자신들의 정보 자산을 표현할 수 있다. 일치하는 UCore 메시지를 작성하기 위해 관련된 정보가 NIEM과 같은 기존의 메시지 형식으로부터 추출된다.

UCore Digest는 엔티티, 이벤트, 사람, 조직, 위치, 수집 및 이들을 서로 연결하는 관계에 관한 정보를 전달한다. 또한, UCore Digest는 모든 UCore 생성자와 소비자가 이해하는 공통 XML 요소 세트를 제공한다. UCore는 이벤트와 엔티티를 분류하는 데 필요한 용어 분류법을 OWL(Web Ontology Language) 파일 형식으로 제공한다. 이 파일에는 특정 분류 용어가 정의 및 소스와 함께 표시되어 있다. 분류 용어는 UCore Digest에서 what 요소의 일부로 사용된다.

스마터 시티 모델링 관점에서 보면, UCore는 엔티티와 자산, 이벤트와 경보, 사람, 조직, 위치 및 수집의 핵심 개념을 이들을 서로 연결하는 관계와 함께 정의하고 모델링하는 데 사용되어야 한다. 이외에도 스마터 시티 모델에서는 이벤트와 엔티티를 분류하는 OWL 기반의 UCore 용어 분류법을 활용해야 한다. 마지막으로 스마터 시티 모델은 UCore 메시지를 소비하고 내보낼 수 있어야 한다.

CAP(Common Alerting Protocol)

CAP(Common Alerting Protocol)은 EDXL 이니셔티브 중 하나이다. (참고자료를 참조한다.) EDXL은 데이터의 상호 운용성을 위해 OASIS에서 개발한 사고 및 긴급사태 관련 표준 세트이다. EDXL은 광범위한 긴급사태 데이터 교환 표준을 위한 통합 프레임워크를 구축하여 운영, 자재 조달, 계획 및 재무를 지원하려는 광범위한 이니셔티브이다.

CAP은 법률 집행, 공중의 안전뿐만 아니라 심각한 기후, 화재, 지진 및 쓰나미와 같은 자연 재해를 포함한 모든 위험 상황에서 시행되는 경보 및 알림의 컨텐츠를 표준화한다. CAP은 범주, 상태, 범위, 확실성, 심각도, 긴급성, 개시 시간, 만료 시간, 대응 유형, 지시사항 등을 포함한 경보의 핵심 개념을 정의하고 모델링하는 데 사용될 수 있다.

CAP은 긴급사태 관리 도메인의 특정 요구를 처리하기 위해 EDXL의 컨텍스트에서 개발되었지만, CAP은 산업계에서 범용 경보 프로토콜로 채택되고 있다. 따라서 CAP은 스마터 시티 솔루션의 핵심 표준이 되기에 충분하며 이점이 이 기사에서 CAP을 설명하는 이유이다. 대체로 EDXL은 긴급사태 관리에 특정적이며 긴급사태 관리 도메인에 특정적인 다음 기사에서 EDXL에 관해 논의하게 될 것이다.

지리적 표준

OGC(Open Geospatial Consortium)는 일련의 지리 및 위치 기반 서비스 표준을 제공하는 4백 개가 넘는 조직으로 구성된 국제 조직이다. (참고자료를 참조한다.) 이러한 표준은 무료로 자유롭게 사용할 수 있으며 데이터 모델, 인코딩, 인터페이스 및 우수 사례를 다루고 있다.

OGC 추상 스펙

OGC 추상 스펙은 OGC 표준의 기준이 되는 핵심 OGC 표준이 빌드되는 개념적인 기반을 제공한다. OGC 참조 모델에는 이러한 표준과 이러한 표준들 간의 관계가 기술되어 있다. (참고자료를 참조한다.)

지리 정보에는 위치와 시간이 포함되어 있다. 위치는 우편 주소와 같은 도시적 위치나 좌표 참조 시스템의 숫자적 좌표로 기술된다. OGC 추상 스펙은 지구를 참조하는 좌표 참조 시스템을 정의한다. 이 스펙에는 지구와 연결된 좌표계의 원점, 방향 및 척도를 정의하는 데이터가 포함되어 있다.

OpenGIS GML(Geography Markup Language)

OGC의 가장 우수한 표준인 GML은 인터넷에서 지리 정보를 교환하는 데 필요한 XML 문법을 정의한다. 이 표준은 XML 스키마로서 사용할 수 있으며 산업계에서 지리 정보를 전송하고 저장하는 데 필요한 기준이 되었다. (참고자료를 참조한다.)

GML은 지리적 특징만을 다루기 때문에 GML에서 위치는 지리적 위치만을 기초로 해서 표현된다. 특히, GML은 도시적 위치를 지원하지 않는다. 따라서 GML은 스마터 시티 솔루션의 핵심 참조 데이터 모델 개발을 위한 차선책이라고 할 수 있다. GML OpenLS(OpenGIS Location Services)와 같은 더 우수한 상위 레벨 표준 중 하나를 사용하는 것이 더 좋은 방법으로 보인다.

OpenLS는 위치 기반 애플리케이션을 사용할 목적으로 고안되었으며 GML의 일부가 아닌 여러 가지 데이터 유형(예: 위치)을 정의한다. OpenLS의 위치에는 국제 주소, 레스토랑 이름과 같은 이름으로 정의된 관심 위치 또는 좌표로 정의된 지리적 위치를 수용할 수 있는 방식으로 정의된 주소를 포함한 여러 가지 위치 유형이 포함되어 있다. 이러한 모든 위치 유형은 앞에서 설명한 예정된 도로작업을 포함한 스마터 시티 시나리오에서 사용될 수 있다.

OpenLS는 GML의 XML 스키마를 기반으로 하는 XML 스키마로 정의된다.

이 시리즈에서는 나중에 다른 OGC 표준인 CityGML과 KML을 논의할 것이다.

OWL의 시간 온톨로지(Ontology)

OWL의 시간 온톨로지는 날짜, 시간, 기간 및 시간대에 맞는 어휘와 관계를 기술하고 있는 W3C 작업 초안이다. (참고자료를 참조한다.) 이 온톨로지를 이용하면 사실을 날짜와 시간 컨텐츠에 관해 표현할 수 있다. 예를 들면, 이 온톨로지를 사용하여 스케줄 충돌 판별, 날짜 비교, 특정 시간 간격 기술, 특정 지리적 위치의 시간 계산 또는 웹 페이지에 시간적 정보 기술과 같은 작업을 수행할 수 있다.

이 온톨로지에 정의된 일부 OWL 클래스에는 간격, DurationDescription, DateTimeDescription 및 DayOfWeek가 포함되어 있다.

시간의 개념은 스마터 시티 환경에서 두루 적용되며 예를 들면, 도로를 수리할 작업반의 작업 스케줄 최적화, 작업을 스케줄하고 교통 지연을 피할 수 있는 작업 시간대 결정, 수도나 전기의 중단 스케줄 방송, 도로가 수리 중인 기간 동안 버스 노선 변경과 같은 상황이 해당된다. W3C 시간 온톨로지는 이러한 스마터 시티 시나리오에서 시간적 개념에 맞는 완전한 모델로 역할을 한다.

SOA 온톨로지

TOG(The Open Group) SOA(Service-Oriented Architecture) 온톨로지는 서비스 지향 아키텍처의 핵심 개념, 용어 및 시맨틱에 대한 OWL 및 UML 온톨로지 설명을 제공한다. (참고자료를 참조한다.) 이 공통 어휘를 이용하면 기업과 소프트웨어 엔지니어가 비즈니스와 마케팅 도메인을 기술 용어에 맵핑하여 문제점을 해결하고 기회를 창출할 수 있다. SOA 온톨로지는 도시 서비스의 상호 이용을 가능하게 하고 기업과 기술 인력 간에 서비스 개발에 대한 명확성과 이해를 촉진할 수 있는 기반을 만든다.

SOA 온톨로지는 이러한 개념과 이러한 개념 간의 관계, 즉, 서비스, 프로세스, 태스크, 이벤트, 행위자, 효과, 시스템, 정책, 서비스 계약, 서비스 인터페이스 및 요소를 기술한다.

이 개방형 표준은 앞에서 설명한 예정된 도로작업 시나리오에 포함된 프로세스와 절차 개념에 대한 기초를 제공한다. 또한, 이 개방형 표준은 도시 프로그램과 웹 기반 서비스 제공을 정의하고 계획하는 데 필요한 작업 전제조건을 기술한다.

위로

권장사항

스마터 시티 데이터 모델 구현이 진행됨에 따라 다음과 같은 단계를 수행하여 이 기사에 지정되어 있는 중요한 표준을 따르도록 해야 한다.

• 스마터 시티 핵심 엔티티를 식별하고 모델링하는 작업을 용이하게 하려면 이 문서의 두 번째 섹션에서 지정한 표준을 활용한다.
• 적절한 위치에서 이러한 표준에 그리고 이러한 표준으로부터 적절하게 맵핑하는 데 필요한 정보를 전달할 데이터 모델을 설계한다. (이러한 표준을 활용하는 것이 이러한 표준을 뒤섞어서 스마트 시티 데이터 모델을 설계하는 것을 의미하는 것은 아니다.)
• 다양한 표준에 동일한 엔티티(예: 조직, 사람, 위치 등)가 정의되어 있는 경우에는 지정된 모든 속성과 관계를 고려한다.
• 마찬가지로 이름이 지정된 엔티티가 여러 가지 표준에 존재하지만, 매우 다른 경우에는 해당 엔티티에 별도의 개념을 정의할 것을 고려한다.
• 스마터 시티 모델이 이 문서의 두 번째 섹션에서 정의한 모든 표준의 엔티티와 개념을 소비하고 내보낼 수 있는지 확인한다.
• 스마터 시티 모델이 발전하고 있고 표준 값이 확인되고 있으므로 적절한 표준화 기구에 참여하여 이러한 갭을 처리하는 데 도움을 주는 것을 고려한다.

위로

결론

표준은 스마터 시티 데이터 모델을 개발하는 데 중요한 역할을 한다. 이 기사에서는 이러한 데이터 모델을 개발하는 과정에서 사용해야 하는 핵심 개념에 적용할 수 있는 여러 가지 중요한 표준을 확인했다. 기타 도메인으로 확장되는 다음 기사에서는 스마터 시티 데이터 모델에 포함될 추가 표준을 평가하게 된다.

표준 인덱스

이 테이블에 있는 표준에 관한 정보는 완전한 것이 아니다. 나중에 개정할 수 있도록 작성자에게 추가 정보를 전송하자.

참고자료

교육

• 프로젝트 페이지를 방문하여 IBM Smarter Cities 이니셔티브에 관해 자세히 배우자.
  
  
• FEMA 웹 사이트에서 NIMS(National Incident Management System)의 권장 표준 목록을 확인하자.
  
  
• NIEM(National Information Exchange Model)에 관해 자세히 배우자.
  
  
• UCore의 세부사항을 확인하자.
  
  
• EDXL의 세부사항을 확인하자.
  
  
• EDXL-CAP에 관해 자세히 배우자.
  
  
• OGC(Open Geopspatial Consortium)에 관해 자세히 알아보자.
  
  
• OGC 추상 스펙에 관해 자세히 알아보자.
  
  
• OGC 참조 오브젝트 모델에 관해 자세히 배우자.
  
  
• GML과 OpenLS에 관해 자세히 알아보자.
  
  
• W3C 시간 온톨로지에 관해 자세히 알아보자.
  
  
• 이 표준에 관한 자세한 정보를 확인하려면 "The Open Group SOA Ontology Technical Standard 1.0"(developerWorks 2010년 12월) 기사를 읽자.
  
  
• The Open Group Service Oriented Architecture Ontology를 자세히 알아보자.
  
  
• 특정 산업계에서 이용되는 개발자용 최신 기술 참고자료를 얻자.
  
  
• IBM의 제품과 함께 오픈 소스 기술을 사용하고 이 기술을 사용하여 개발하는 데 도움이 되는 광범위한 사용법 정보, 도구 및 프로젝트 업데이트를 확인하자.
  
  
• developerWorks 기술 행사 및 웹 캐스트를 통해 최신 정보를 얻을 수 있다.
  
  
• Twitter의 developerWorks 트윗을 팔로우하자.
  
  
• 소프트웨어 개발과 관련된 중요한 인터뷰와 토론을 확인하려면 developerWorks 팟캐스트를 청취하자.
  
  

제품 및 기술

• 산업별로 평가 소프트웨어를 확인하자.
  
  

토론

• 개발자 중심의 블로그, 포럼, 그룹 및 위키를 살펴보면서 developerWorks 커뮤니티를 통해 다른 developerWorks 사용자와 의견을 나눌 수 있다.
  
  
• developerWorks 커뮤니티에서 Real world open source 그룹을 빌드하는 데 도움을 주자.
  
  
• developerWorks 블로그를 확인하고 참여하자.
  
  

필자소개

IBM 소프트웨어 표준 그룹의 구성원인 Arnaud Le Hors는 전략 및 기술적 관점에서 IBM의 여러 가지 표준 활동을 조정하는 역할을 담당하고 있다. Arnaud는 X Consortium과 W3C의 직원으로 15년 동안 개방형 표준을 담당해왔다. 그는 IBM과 같은 회사와 SDO의 내부와 외부에서 기술적, 전략적, 정치적 및 법적인 관점을 포함한 모든 견지에서 표준 개발 프로세스에 참여했다. Arnaud는 HTML 및 XML과 같은 표준을 개발하는 데 참여했으며 Apache Software Foundation에서 개발한 XML 구문 분석기인 Xerces의 리더 아키텍트 중 한 사람이다.

John Meegan은 IBM Software Group Strategy and Technology 그룹의 고위직 구성원으로, 여기에서 IBM의 스마터 시티 및 클라우드 이니셔티브를 표준화하는 데 노력을 집중하고 있다. 표준화 작업에 참여하기 전에는 여러 해 동안 IBM Software Group 오픈 소스 전략을 개발하는 데 참여했으며 이러한 전략을 전달하고 다듬기 위해 고객 및 업계 컨설턴트와 함께 작업을 진행했다. 또한, IBM Software Group Strategy 조직에서 초기 IBM 웹 애플리케이션 서버 전략을 공식화하는 데 기여했으며 결국 IBM WebSphere 제품군을 출시하는 데 선도적인 역할을 담당했다. 그는 Columbia University에서 전산학 학사학위를 취득했다

IBM Software Standards 팀의 개발자인 Keith Wells는 지난 10년 동안 여러 가지 표준으로 코드, 데모, 전술 및 전략을 능동적으로 개발할 수 있는 기회를 즐겨왔다. Keith는 기술에 대한 호기심이 많으며 흥미롭고 실용적인 제품을 개발하는 데 열정이 있을 뿐만 아니라 다양한 기술이 있는 사람들과 협력하는 것을 좋아한다.

아티클 순위

의견

위로

목차

• 소개
• 시나리오: 계획된 도로작업
• 표준 명세
• 권장사항
• 결론
• 참고자료
• 필자소개
• 의견