• 검색 결과가 없습니다.

연구개발 목표의 달성도 및 자체평가

문서에서 R&D연구결과보고서 (페이지 15-35)

가. 연구개발성과 및 평가 방법

1) Transaction Per Second : 초당 트랜잭션 수 2) Mean Time Between Failures : 평균 무 고장 시간

<오픈 소스 테스팅 툴 구조 (Robot Framework, Eclipse Titan, Testerman)>

ü ETSI (ES 201 873 series) 와 ITU-T (Z 140 series) 에 의해 국제적으로 표준화 된 테스트 언어 TTCN-3에 대한 분석을 수행함

ü 테스팅 절차 (procedure) 와 방법을 문자를 이용해 서술함으로서 발생하는 의사소통의 오류를 해결하기 위해 심볼을 이용한 노테이션 (Symbolic Notation) 으로 표현하도록 개발된 TTCN-3의 개별 표준 및 노테이션 분석을 수행함

<TTCN-3 테스트 케이스>

ü 오픈소스 테스팅 툴 및 TTCN-3 테스트 언어에 대한 분석을 토대로 oneM2M Conformance 테 스팅 툴에 대한 요구사항을 개발함

ü 요구사항은 크게 기능적 요구사항 (Functional Requirements)과 비기능적 요구사항 (Non-Functional Requirements)로 구분하여 정리함

ü 각 기능적 요구사항 및 비기능적 요구사항은 아래 표와 같은 종류로 구성되며 총 19가지 기능 및 14가지 비기능 요구사항이 존재함

구분 요구사항 종류

Functional

Protocol message encoding and decoding, HTTP library design, Test case code (TTCN-3 code) compiling, Load file generation, Test execution, Runtime debugging, Test result and log generation, User interface design

Non-Functional Quality, Extensibility, Compliance, Performance, Reliability, Failure management, Legal and License management, Documentation, Efficiency

-

Self testing용oneM2M Conformance 테스팅툴 프레임워크 및 Prototype SW개발

ü 분석된 요구사항을 토대로 TTCN-3 테스트 시스템에 대한 추가 분석을 통해 TTCN-3 테스트 시스템의 아래 그림과 같은 구조 및 기능 블록을 만족하는 테스팅 툴 프레임워크에 대한 설계 를 수행함

<Conformance 테스트 툴 구조 설계 (TTCN-3, Titan mapping, Conformance 테스트 툴)>

ü 기존 분석된 테스팅 툴에서 지원하는 기능을 활용하여 개발 기간을 단축하기 위해 Eclipse Titan을 선택하고 Titan과 TTCN-3 시스템을 매핑하여 활용 가능 기능 및 추가 필요 기능에 대 해 설계함

구분 종류

활용 가능 기능

TM 기능 (Eclipse IDE 활용 Test suite 에디팅 기능, 로그뷰어 활용 테스트 결과 확인 기능), TL 기능 (테스트 케이스 수행 결과 분석 및 로그 분석 기능), CH 기 능 (TTCN-3 Executable 테스트 케이스 수행/중지 등 컨트롤 기능), TTCN-3 Executable 생성 기능 (Titan 제공 TTCN-3 컴파일러 기능)

추가 필요 기능

TM 기능 (oneM2M 전용 Runtime config 파라미터 입력 기능), TL 기능 (oneM2M 테스트 케이스에 대한 분석 기능), CD 기능 (oneM2M core protocol 헤더 파라미터 인코딩/디코딩 기능, oneM2M core protocol 바디스트링 인코딩/디코딩 기능), SA 기능 (oneM2M core protocol 활용 SUT 연동 기능), PA 기능 (oneM2M 시스템 플 랫폼 정보 지원 기능)

ü 설계 구조를 반영하여 Eclipse Titan 프레임워크를 활용하여 oneM2M 기반의 디바이스 및 플랫 폼 개발 시 자체적으로 테스트를 진행할 수 있도록 TTCN-3 Language로 작성된 Test Suite 및 Test case 구동이 가능한 Self 테스팅 용 테스트 툴 프로토타입을 개발함

<Self 테스팅 용 테스트 툴 프로토타입>

- Self testing용oneM2M Conformance 테스팅툴용 Adaptor 라이브러리개발

ü 설계 구조를 지원하는 Self 테스팅 용 테스트 툴 프로토타입을 위한 Adaptor 라이브러리를 개 발함

ü 테스팅 툴용 Adaptor는 TTCN-3 연계 oneM2M System Adaptor로서 Release 1. 버전의 oneM2M core protocol specification 표준 문서 및 XSD를 적용하고 Eclipse Titan Framework와 연동하여 테스팅이 가능하도록 개발함

<oneM2M 테스팅 툴 Adaptor>

- Self testing용oneM2M Conformance 테스팅툴 오픈 프로젝트 개설

ü oneM2M Conformance 테스팅 툴 설계 및 개발을 위해 Gitlab을 구축하고 오픈 프로젝트를 개 설함

ü 오픈 프로젝트 참여 기관으로는 KETI, ETSI, EGM, Sensinov, LAAS-CNRS, Ericsson, DT&C, TTA, SJU, Inowireless, etc. 등 각국 기업 및 연구소가 있음

<테스팅 툴 오픈 프로젝트>

- oneM2M Interoperability 및 Conformance 테스팅용 Testing Spec표준개발

ü oneM2M 플랫폼 간의 상호연동 호환성 테스팅을 위한 규격으로 HTTP, CoAP, MQTT 기반의 테 스팅 규격을 개발함

ü oneM2M 엔터티 간의 싱글홉, 멀티홉 케이스를 기반으로 등록, 데이터 생성, 그룹, 위치, 구독-통지, 접근 정책, 검색, 폴링채널, 동기/비동기 요청 등에 대한 Interoperability 스펙을 개발함

소프트웨어 명 기능

HP Load Runner 사용자 관점에서의 응답시간, 시스템 사 용율, 성능 저하 원인 등을 정확히 분 석하여 성능 개선에 효과적인 정보를 제공

HeavyLoad cpu사용율과 메모리 점유율을 실시간으로 보여주는 모니터링 기능 제공 JMeter FTP request / HTTP request 등으로 부하테스트

loadUI REST, AMF, JMS, JDBC뿐만 아니라 웹 사이트와 같은 다양한 프로토콜의 부 하테스트

<Interoperability 테스트 케이스>

ü oneM2M 플랫폼의 적합성 테스팅을 위한 테스팅 지원 기능 명세서 ICS (Implementation Conformance Statements)와 적합성 테스팅 케이스 정의서 TSS&TP (Test Suite Structure and Test Purpose) 규격을 개발 중에 있음

ü TSS&TP는 oneM2M AE, CSE에 대한 테스트를 정의하며 9개의 서브 그룹으로 나뉘어진 각각의 기능들에 대한 테스트 케이스가 수록되며 SUT의 해당 기능에 대한 지원여부는 ICS로 점검함

<Conformance 테스트 케이스>

n

Io

T 환경 고신뢰 소프트웨어 성능 시험 테스트 방안 개발

Ÿ 주요산출물: 기술보고서 3건

Ÿ 상세연구개발 내용:

- IoT 환경 고신뢰 소프트웨어 플랫폼 성능 평가를 위한 툴 분석 및 요구사항 도출

ü 소프트웨어 플랫폼 성능 평가를 위해 QoS Testing tool 현황 조사를 실시한 결과 HP Load Runner, HeavyLoad, JMeter 등 여러 tool의 기능을 도출함

Allmon 실시간 시스템 응답, load, stress soak testing monitoring

Class Characteristic Real-time Class Mission Critical

예) surveillance alarm system, healthcare monitoring, industrial control Assured Services Clas Soft response time requirements

예) tracking applications for logistic Best-effort Class Do not require any guarantee

예) historical data collection

- IoT 환경 고신뢰 소프트웨어 플랫폼 성능 평가를 위한 테스트 프레임워크 구조 설계

Layer QoS Parameter

Perception Sampling parameters, Coverage, Time synchronization, Location and mobility Network Bandwidth, Delay, Packet loss rate, Jitter

Application Service Time, Service Delay, Service Accuracy, Service Load, Service Priority ü IoT 환경에서 메시지 (트래픽특성) 전달과 관련된 QoS 요구사항은 어플리케이션의 특성에 의존적이

야 함

- 인더스트리도메인 응용서비스를 위한 QoS(실시간, 신뢰성) 지원 아키텍쳐 설계

ü Time Series 데이터는 시계열 히스토리 정보를 바탕으로 데이터의 생성시간의 정보를 포함 하며 계속적인 무한 데이터의 취합 특성 가지고, 보통 각각의 데이터는 작은 크기를 갖음 ü Time Series 데이터를 oneM2M 플랫폼 구조로 수용하기 위해서는 기존의 Container,

ContentInstance를 활용할 수 도 있지만, 데이터의 생성 시간을 하나의 속성값으로 취해야 하는 특성 및 타임시리즈 데이터의 손실을 감지하기 위한 방안이 필요하는 점, 기존 ContentInstance의 부가적인 속성값들의 오버헤드를 감소시키기 위한 방안이 필요함

<TimeSeries 지원 리소스 구조>

ü IoT 시스템의 Collaborative system 환경에서 컨트롤 센터에서 전달한 명령들은 일련의 관련 있는 엔터티들에게 올바르게 수신되어야 하고 처리되어야 함, 만약 하나의 엔터티라도 문제 가 발생하면 미션의 목적이 달성되지 못하는 동작과정을 트랜잭션 이라고 하고 이를 신뢰성 있게 지원할 수 있는 방안이 필요함

<Colloaborative System 예>

ü REST 아키텍처 구조에서 명령은 CRUD 오퍼레이션 요청으로 표현되고 해당 오퍼레이션에 대한 타겟 시스템들은 응답을 한다. 트랜잭션 처리를 지원하기 위해서 해당 요청메시지에 Transaction Type, Transaction ID를 추가한다.

- oneM2M 아키텍쳐 및 프로토콜 QoS지원 기술 표준 개발

ü <TimeSeries> 리소스 구조: Time Series 인스턴스를 위한 데이터 컨테이너의 역하릉ㄹ 하는 가상화 리소스로서 Time Series의 손실되는 데이터의 모니터링, 보고 기능을 지원

ü <TimeSeriesInstance> 리소스 구조: Time Series 데이터를 위한 리소스로서 데이터 생성 시간 및 시퀀스 번호를 속성값으로 포함한다. 추가 속성값은 오버헤드 감소를 위해 지원않음 ü <Transaction> 리소스 구조:트랜잭션 고정 지원을 위해서 Transaction Type 이 포함된 요청

메시지에 대해서 타겟 리소스 하위에 트랜잭션 리소스를 생성하고 해당 처리를 지원함

<Transaction 지원 리소스 구조>

- 인더스트리 응용을 위한 QoS 지원 기반 기술 개발

ü Mobius Yellow Turtle 개발 및 QoS 기능을 위한 <TimeSeries> 지원 및 <Transaction> 지원을 통해서 인더스트리 도메인을 위한 프로토타입 플랫폼 SW 개발을 진행함

ü 인더스트 도메인 적용 (삼성 디스플레이 수원 사업장, SK(주) 폭스콘 충칭 공장 스마트 팩토 리 구축)을 통해서 Mobius Yellow Turtle 기반 IoT 플랫폼 시험 구축을 적용함

<인더스트리 도메인 적용 예>

n 고신뢰 전송 프로토콜과 oneM2M Core 프로토콜 바인딩 기반 기술 개발

Ÿ 주요산출물: 기술보고서 2건, 프로토타입 SW 1건, 표준 기고 1건

Ÿ 상세연구개발 및 평가내용:

- 고신뢰 전송 프로토콜 분석 및 oneM2M 프로토콜 바인딩 기술 분석

ü oneM2M의 프로토콜 바인딩 기술을 개발하기 위해 현존하는 바인딩 프로토콜을 분석하여 기본 적인 바인딩 개념을 해석함, HTTP, MQTT, COAP 세 프로토콜의 바인딩 기법을 분석하여 각각 의 바인딩 기법과 전략을 이해하고 프로토콜의 특징과 전략을 도출함

ü oneM2M에 적용할 수 있는 다양한 프로토콜을 분석하여 추가적으로 바인딩할 수 있는 프로토 콜이 있는지를 조사하고 oneM2M 프로토콜 분석 TR을 기반으로 다양한 프로토콜의 패킷 구조, 바인딩 가능성 등을 도출함

- 고신뢰 전송 프로토콜 기반 oneM2M 프로토콜 바인딩 설계

ü DDS는 대규모, 실시간 지원의 강점이 있는 프로토콜로서 DDS 자체가 일반적인 통신 프로토콜

의 역할을 하며, 정해진 패킷 규격이 없이 다양한 형식을 지원하기 때문에 oneM2M의 Primitive 메시지와의 연동이 자유로우며, oneM2M의 현재 지원범위가 경량화 환경에 초점이 맞춰져 있기 때문에, DDS를 통해서 oneM2M의 서비스의 신뢰성을 높일 수 있음

<DDS 프로토콜 구조>

ü DDS는 크게 DCPS와 RTPS로 두 개의 레이어로 나뉠 수 있음, RTPS는 CORBA와 같은 다른 통 신 프로토콜과 대체가 가능한 구조로서, 바인딩은 DCPS 레이어에서 수행해야 함, DDS 자체의 메시지 구조는 동적으로 편성이 가능하므로, oneM2M Primitive 메시지 형식을 구조체로 만들고 이 구조를 송수신 측에 공유하여 메시지를 전달할 수 있음

- 고신뢰 전송 프로토콜 기반 oneM2M 프로토콜 바인딩 프로토타입 개발

ü 실제 바인딩을 수행하기 위해서 oneM2M 과 DDS를 동시에 수행이 가능한 환경을 구축하고 오 픈소스 기반으로 각 프로토콜에 대한 환경을 구성함

ü oneM2M 플랫폼으로서는 OCEAN에서 제공하는 오픈소스 Mobius와 &Cube를 설치하여 구성하

ü oneM2M 플랫폼으로서는 OCEAN에서 제공하는 오픈소스 Mobius와 &Cube를 설치하여 구성하

문서에서 R&D연구결과보고서 (페이지 15-35)

관련 문서