ITS 노변장치 제어를 위한 SNMP의 메시지 교환절차

 SNMP는 응용수준 프로토콜로서 상이한 제조회사에 의해 만들어지고 물리적으로 상이한 네트워크에 설치된 장치들을 감시할 수 있도록 응용수준에서 설계됨. 즉, SNMP는 관리 대상 장치의 물리적 특성과 하부 네트워크 기술로부터 관리 작업을 분리함. 따라서 상이한 제좃회사들이 만든 장치들에 의해 연결된 서로 다른 네트워크로 구성되는 이질적인 환경에서도 사용될 수 있음.
 SNMP는 관리자와 에이전트의 개념을 사용하며, 보통 호스트인 관리자는 노변장치인 에이전트들의 집단을 제어하고 감시함
  SNMP는 GetRequest, GetNextRequest, SetRequest, GetResponse, Trap의 메시지를 정의함

 GetRequest 메시지는 변수의 값을 읽기 위하여 관리자(클라이언트)가 에이전트(서버)로 보내는 메시지임

 GetNextRequest 메시지는 변수의 값을 읽기 위하여 관리자(클라이언트)가 에이전트(서버)로 보냄. 읽혀진 값은 메시지에 정의된 ObjectID 바로 다음의 객체의 값임. 이는 대부분 테이블에 있는 항목들의 값을 읽기 위해 사용됨. 만일 관리자가 항목들의 식별자를 모른다면, 관리자는 읽을 수가 없음. 하지만, 관리자는 GetNextRequest를 사용하고, 테이블의 ObjectID를 정의 할 수 잇음. 테이블의 첫번째 항목은 테이블의 ObjectID 바로 뒤의 ObjectID를 갖기 때문에, 첫 번째 항목의 값을 반환함. 관리자는 이 ObjectID를 사용하여 다음 항목의 값을 얻을 수 있으며, 이런 절차는 반복될 수 있음

 GetResponse 메시지는 GetRequest와 GetNextRequest에 대한 응답으로 에이전트가 관리자에게 보내는 메시지임. 이는 관리자에 의해 요청된 변수의 값을 포함함. SetRequest 메시지는 관리자가 변수에 값을 설정(저장)하기 위해 전송됨. Trap 메시지는 에이전트가 사건을 관리자에게 보고하기 위해 전송함. 예를 들어, 만일 제이전트가 재 시동되면, 그는 관리자에게 이를 알리고 재시동 시간을 보고함.

 이 다섯가지 형식 중 앞의 네 메시지는 비슷한 형식을 갖는 반면에 Trap 메시지는 상이함. 이 메시지들에 대한 필드는 다음과 같이 구성됨

  - Version : 버전번호를 정의. 이 값은 실제로는 버전 번호보다 하나작음. 비록 버전 2가 제안되어 있지만, 현재 우리는 SNMP의 버전 1을 사용함

  - Community : 비밀번호를 정의. 비밀번호가 없는 경우, 이 값은 public이란 문자열임

  - Request ID : 순서 번호로서, 관리자가 요청 메시지에서 사용하며, 에이전트는 응답에서 반복함. 요청과 응답을 일치시키는 데 사용함

  - Error status : 이것은 응답 메시지에서만 사용되는 정수로서 에이전트에 의해 보고되는 오류의 종류를 나타냄. 요청 메시지에서는 0 값이 사용됨. 

  - Error Index : 오류 식별자는 관리자에게 오류를 일으킨 변수가 어느 것인지를 알려주능 옵셋임

  - VarBindList : 관리자가 읽기나 설정하기를 원하는 값을 갖는 변수들의 조합. 이 값들은 GetRequest와 GetNextRequest 에서는 0 임. Trap 메시지에서 이는 특정 메시지에 관련된 변수와 값을 보여줌

  - Enterprise : Trap을 발생시키는 소프트웨어 패키지의 ObjectID를 정의

  - Agent Address : TRARP을 생성하는 에이전트의 IP주소를 정의함

  - Trap type : 일곱 개의 Trap 종류의 유형

  - Specific code : 만일 Trap 종류의 값이 6이면, 이 필드는 제작회사에 의해 사용되는 특정한 코드를 정의함

  - Time stamp : TRAP을 야기한 사건 이후 경과된 시간을 보여줌

출처 : 나원경 (2007), 「지능형교통시스템의 CCTV 제어용 SNMP 적용」, 광운대학교, 학위논문(석사)

ISO 14817에서 정의하고 있는 Data Concept과 국내 기술기준의 메시지 정의구조 매칭

 ISO 14817 'Transport information and control systems - Requirements for an ITS/TICS central Data Registry and ITS/TICS Data Dictionaries'에서는 ITS분야 데이터 사전을 위한 데이터 개념을 아래와 같이 정의하고 있음

 ITS 시스템간 정보교환은 인터페이스 다이얼로그 또는 인터페이스 다이얼로그 셋의 탑다운 방식으로 특정지어지며, 메시지는 교환되어질 상당량의 데이터를 포함하고 있는 데이터 요소(data element) 또는 데이터 프레임(data frame)의 집합으로 볼 수 있음

 데이터 요소는 3가지의 데이터 개념들인 Object Class, Property, Value domain으로 구성된 하나의 복합물로써 데이터 사전의 기본 내용을 구성함

 이러한 개념을 바탕으로 국내 ITS 기술기준을 ISO 14817의 데이터 개념에 매칭시키면 다음과 같음

• Interface Dialogue : 기본교통정보교환기술기준
• Message : 교통소통정보
• Data element : Object Class + Property + Value domain
•         - Object Class : 링크_교통량_율
•         - Property : 보안등급
•         - Value Domain : 일반

UML (Unified Modeling Language, 통합 모델링 언어)

객체 지향 분석/설계용의 모델링 언어. 기존의 객체 지향 방법론과 함께 제안되어 모델링 언어 표기법의 표준화를 목적으로 한 것이다. 주로 미국의 래셔널 소프트웨어(Rational Software)사에서 방법론의 통일과 표준화 작업에 전념한 결과 1997년 11월에 UML 1.1이 객체 관리 그룹(OMG)에 의해 표준으로 채택되었다. UML은 방법론이 아닌 소프트웨어 개발에 사용되는 다이어그램을 정의하는 것으로, 소프트웨어 개발 시 산출물들을 비주얼하게 제공함으로써 개발자와 고객 또는 개발자 상호 간의 의사 소통을 원활하게 할 수 있으며, 산업계 표준으로 채택되었기 때문에 UML을 적용한 시스템은 신뢰성이 있다

UML (Unified Modeling Language, 통합 모델링 언어) 는 시스템을 시각화하거나 시스템의 사양이나 설계를 문서화하기 위한 표현방법입니다. UML은 주로 객체 지향 프로그램의 구조를 나타내는데 사용되며, 클래스 다이어그램 (Class Diagram), 시퀀스 다이어그램 (Sequence Diagram) 등이 존재합니다.


1. 클래스 다이어그램


클래스 다이어그램은 클래스나 인스턴스, 인터페이스 등의 정적인 관계를 표현합니다.

<클래스 다이어그램의 예>

각각의 클래스는 위 그림과 같이 표현할 수 있으며, 표현하는데 필요한 몇 가지 기호들이 존재합니다.

<클래스의 표현>

클래스는 직사각형으로 표현합니다. 직사각형은 수평선으로 세개의 칸으로 분할됩니다. 첫번째 칸에는 클래스의 이름을 두번째 칸에는 필드의 이름을 쓰고 마지막 세번째 칸에는 메소드의 이름을 적습니다.


각각의 칸에는 이름 뿐 아니라 부가적인 정보를 적기도 합니다.


추상 클래스와 추상 메소드의 경우에는 이탤릭체를 사용합니다. static 필드와 static 메소드의 경우에는 밑줄을 사용합니다.

<상속 표현>

클래스간의 상속은 실선 화살표를 이용해 표시합니다. 화살표의 방향은 자식 클래스에서 부모 클래스로 향합니다.

<인터페이스, 집약의 표현>

점선 화살표는 인터페이스의 구현을 의미합니다. 화살표의 방향은 구현 클래스에서 인터페이스 방향으로 향합니다. 인터페이스를 표현하는 경우 <>와 같이 표현합니다.


마름모가 붙은 선은 집약 (aggregation) 을 의미합니다. 인스턴스를 갖고 있는 경우에는 두 클래스간의 관계는 집약입니다.


클래스 다이어그램에서 엑세스를 표현할 수도 있습니다.

• +가 붙은 경우 : public
• -가 붙은 경우 : private
• #이 붙은 경우 : protect
• ~이 붙은 경우 : 동일한 패키지 내에서만 사용할 수 있습니다.

2. 시퀀스 다이어그램

<시퀀스 다이어그램>

시퀀스 다이어그램은 프로그램이 작동될 때 어떤 순서로 실행되는지를 나타냅니다.


시퀀스 다이어그램의 가장 위에 있는 직사각형 안에는 인스턴스의 이름이 들어갑니다. 콜론 (:) 뒤에는 클래스의 이름을 표기하고 그 앞에는 인스턴스의 이름을 표기합니다. 만약 인스턴스의 이름을 따로 표기할 필요가 없을 경우에는 표기하지 않아도 상관없습니다.


인스턴스에서 아래로 뻗어있는 점선은 라이프 라인 (Life Line) 입니다. 시퀀스 다이어그램에서 시간은 위에서 아래 방향으로 흐릅니다. 라이프 라인 중간의 직사각형은 객체가 활동중임을 의미합니다.


각 객체 사이의 실선 화살표는 메소드의 호출을 점선 화살표는 메소드에서 리턴되었음을 의미합니다.




출처 - http://mutablearray.tistory.com/222

ITS data object 분류를 위한 클래스 명칭(class name)

현재는 폐지되었지만, 기 제정되어 있는 ITS 데이터 사전의 대표 리퍼런스인 TTAS-1489 'ITS 데이터 사전 형식 표준'에 따르면 데이터 요소들의 분류를 위한 클래스 명칭의 적합한 값들을 아래와 같이 정의하고 있음.

 이러한 ITS 분류체계를 어딘가 국제표준에서 따온거 같긴 한데, 정확히 어떤 표준에서 가져온건지는 잘 나오지는 않고, 이런 분류체계가 우리나라 아키텍쳐랑 잘 맞는지도 모르겠고. 일단 저 표의 출처를 찾아보고 우리날 적용성에 대해서 먼저 검토가 필요할 듯

ITS 분야 OID 활용 필요성

 OID(Object IDentifier)는 국제표준화 기구인 ISO와 ITU가 공동으로 정보보안 암호코드, 속성, 알고리즘 등 모든 사물(object)에 대하여 전 세계적으로 하나의 고유번호로 구별하기 위한 국제표준식별 체계로, 2010년 OID 해석시스템(ORS)의 국제 관기기관으로 국내 한국인터넷진흥원이 세계 최초로 선정되기도 하였음 (ISO 29168-2)

 OID는 Global Naming Tree를 통해 구조화 되며, Tree의 각 노드에는 고유번호가 할당되어, 상위노드에서 연결된 하위노드의 각 고유번호를 OID라 함

 Tree는 3개의 최상위 노드로 구성되며, 각 최상위 노드는 수많은 하위 서브 노드로 연결되어 있고, 각 서브 노드는 다시 하위 서브 노드로 연결되어 있음

 미국 NTCIP에서는 1200 시리즈에서 정의하고 있는 모든 object에 대해 OID를 정의하여, 서로다른 제조업체의 시스템 간에도 정보교환의 호환성을 확보하고 있음

 1991년 이전까지 미국 표준협회(ASNI)는 {ISO(1) member-body(2) us(840)}으로 등록해 왔지만, 1992년 ISO/IEC 9834에서 정의한 등록절차의 변화에 따라 1991년 이후 {joint-iso-itu-t(2) country(16) us(840)}으로 변경하여 등록하고 있음

 하지만, NTCIP의 개발을 주도하고 있는 NEMA는 IAB로 부터 노드를 할당받는 것이 용이한 점을 고려하여 NEMA노드를 internet 하위노드의 하위노드로 할당받아, 현재 NTCIP object는 아래와 같은 OID 체계를 따르고 있음

ema OBJECT IDENTIFIER ∷ = 〔iso org dod internet private enterprise 1206〕

(1.3.6.1.4.1.1206)

 현재 국내에는 ITS 분야 표준정보항목에 대해 OID를 부여하고 있지 않은 상황으로, 이는 해외시장 진출 시 큰 걸림돌이 될 수 있음. OID 등록 시 ISO 국제표준을 준수하는 대외적인 명분을 확보할 수 있으며, 실제 국외사업 수행시에도 시스템 구축의 용이성을 확보할 수 있을 것으로 판단됨

국내 ITS 데이터 사전의 이용 한계

ITS 분야 국내 데이터사전 표준은 총 4개로 다음과 같음
 - 첨단교통정보분야 데이터사전 표준
 - 첨단교통관리분야 데이터사전 표준
 - 첨단대중교통분야 데이터사전 표준
 - CVO분야 데이터사전 표준

SNMP MIB형태로 국내 노변-센터간 정보교환 표준 개발을 위해 국내 데이터사전 표준을 검토한 결과 2012년 현재 제정되어 있는 데이터사전을 적용하여 사용하는데 많은 어려움이 있을 것으로 판단됨. 그 이유는

첫째, 기존 데이터사전들이 대부분 2003년에 개발됨에 따라 2009년 개정된 국가 ITS 아키텍쳐의 정보흐름을 따라가지 못하고 있음

둘째, 기존 데이터 사전 개발은 2000년대 이전의 미국 TMDD를 기반으로 하고 있지만, TMDD는 이후 많은 변화가 이루어 졌으며, 국내 데이터 사전은 이에 대한 반영이 이루어지지 않고 있음

셋째, ISO 14817(Transport Information and Control system-Requirements for and ITS/TISC central Data Registry and ITS/TICS Data Dictionary)에 따르면 매우 다양한 메타속성에 대해 정의하고 있으며 국내 데이터 사전에도 이에대한 국제표준을 반영할 필요가 있음

넷째, 국내 데이터사전에서 명시하고 있는 object와 ISO 14817에서 정의하고 있는 Data concept descriptive name format이 상이하기 때문에 국외표준을 반영한 시스템과 호환성에 문제가 발생할 수 있음

예시)  
                   ISO 14817                                       국내 DD
            Object ClassTerm                                ClassName
            value-domain-term                              Value Domain

스키마(Schema)

 스키마는 원래 심리학에서 나온 용어로, 과거의 반응이나 경험에 의해 생성된 생물체의 지식 또는 반응체계로서 환경에 대해 적응하고 대처하도록 하는 역할을 뜻함. 전산학에서는 사용되는 스키마는 데이터베이스에서 자료의 구조, 자료의 표현방법, 자료 간의 관계를 정의한 것을 뜻함. 데이터베이스 관리시스템(DBMS)이 주어진 설정에 따라 데이터베이스 스키마를 만들어 내며, 데이터베이스 사용자가 자료를 저장, 조회, 삭제, 변경할 때 DBMS는 그것이 생성한 데이터베이스 스키마를 참조하여 명령을 수행함