[ROS2]OMG Data-Distribution Service: Architectural Overview and OMG Data-Distribution Service: Architectural Update

Jeongkyu(Jun)·2022년 11월 23일

Paper Review

목록 보기

1/2

논문 시리즈는 저작권 문제가 있으므로 온라인에 비공개로 설정되어있습니다.

아래 내용중 개요는 오로카 카페의 표윤석 박사님의 글: ROS 2와 DDS (Data Distribution Service)내용을 일부 인용하였습니다.

다음 포스트의 구성은 프레젠테이션 구성과 같이 하기위해
라인을 통해 화면을 구성하고, 인용라인을 통해 스크립트를 구성합니다.

1. 들어가기(keyword check)

1.1 ROS and ROS2

그림1. ROS 구조
출처: ROS2 docs-foxy

keyword : 노드 메시지 데이터타입 토픽 서비스 액션

자세히

1.2 ROS2 and DDS(Data-Distribution Service)

그림 2. ROS1 and ROS2 비교 다이어그램
출처:Exploring the performance of ROS2(conf. paper)

Publish-Subscribe
OMG가 정의한 표준: DDS
ROS1: TCPROS vs ROS2: DDSI-RTPS(Real Time Publish Subscribe)

1.3 OMG?(Object Management Group)

그림3. OMG(www.omg.org)

분산 객체에 대한 기술 표준을 제정하기 위해 1989년에 설립된 비영리 단체
관리하는 많은 표준 중 13개가 ISO 표준으로 비준됨.(Retified)

	- BPMN
	- CORBA(Common Object Request Broker Architecture)
	- MOF
	- IDL(Interface Definition Language )
	- KDM
	- AFP
	- OCL
	- SysML
	- UML(Unified Modeling Language)
	- UPDM
	- XMI(XML Metadata Interchang)

2. OMG Data-Distribution Service: Architectural Overview

Abstract

OMG Data-Distribution Service(DDS)
- Emerging specification for publish-subscribe Data-Distribution system
- 사양의 목적: DDS를 정의하는 Common Application-level 인터페이스 제공.
- 서비스 구성시 QoS(Quality of Service)설정에 대한 여러 정의를 적용함.
해당 논문은 OMG DDS 사양을 소개, 해당 모델의 QoS설정 설명 그리고 지원하는 통신 시나리오 소개.

2.1 Introduction

Publish-Subscribe(PS) 시스템은 모듈 간의 정보교환(information exchange)로 구성됨.
PS 모델은 익명의 정보 생산자(게시자-publisher)와 정보 소비자(구독자-subscrbier)를 서로 연결함.
전체 분산 응용 프로그램(PS 시스템)은 참가자(Participant)라고 불리는 독립적인 주소공간을 가지는 프로세스로 구성됨.
- 참가자는 정보의 구독 및 게시가 동시에 가능함.
데이터 중심(Data-Centric)통신으로 전송되는 정보의 분류
1. 신호(Signals)
  - 지속적으로 변화하는 데이터(예: 센서값)
2. 스트림(Strams)
  - 이전 스냅샷의 컨텍스트에서 해석되어야 하는 data-object값의 스냅샷을 의미
  - 데이터가 전달되는 플로우에서 이전 시점에 해석된 data-object값에 대한 현재 시점
3. 상태(States)
  - 데이터 속성들의 집합 또는 데이터 구조의 가장 최신(most-current)값으로 코드화된(codified) 오브젝트 또는 시스템의 집합의 상태를 말함.

DDS사양의 목표: 분산시스템에서 데이터를 효율적인 배포하는 것
- 참가자가 인터페이스를 이용하여 read and write를 쉽게 해야함.
- DDS 미들웨어는 읽기 참가자가 가장 최신값을 받을 수 있도록 해줌.
- 해당 서비스는 모든 참가자가 읽고 쓸 수 있도록 글로벌 데이터 공간(global data space)를 생성함.
- 참가자가 object를 찾고 공유할 수 있는 name space를 생성함.
DDS는 실시간 시스템을(real-time system) 대상으로 함.
DDS API및 Qos는 예측 가능한 동작과 구현의 효율성/성능의 균형을 맞춰서 선택이 됨. 해당 논문에서 선택에 대해서 언급될 예정임.
DDS 사양의 두 가지 수준의 인터페이스.
- Optional. Higher level: DLRL(Data-Local Reconstruction Layer)
- lower level: Data-Centric Publish-Subscribe(DCPS)

아래 논문 그림1은 DCPS의 전체적인 모델임.

통신을 돕는 엔티티 리스트
- DomainParticipant, Data Writer, DataReader, Publisher, Subscriber 및 Topic
위 클래스들은 확장된 DCPSEntity를 QoSPlicy를 통해 구성할 수 있는 기능을 나타냄.
Listenr객체를 통해 이벤트를 알리고 애플리케이션에서 대기WaitSet할 수 있는 조건Condition을 지원함.
즉, 정리하면 DCPS layer는 Infrastructure, Topic, Publication, Subscription, and Domain:의 5개 모듈로 구성됨. 자세히

Publisher
- 다양한 유형의 데이터 발행을 담당하는 일종의 퍼사드.
- 참여자는 DataWriter를 사용하여 새로운 데이터 값을 Publisher에게 전달함.
- Publisher는 도착한 데이터를 발행할 시기를 결정하고 수행함.
- 발행 시기는 QoSPolicy 또는 DataWriter의 상태에 따라 다름.
Subscriber
- 게시된 데이터를 수신하고 참여자가 사용할 수 있도록 함.
- 참여자는 DataReader를 통해 수신한 데이터 값을 액세스 가능함.
Topic
- DataWriter(게시를 의미),DataReader(구독을 의미) 두 객체의 연결은 Topic을 통해서 이루어짐.
- Topic은 시스템 내에서 고유한 이름, 데이터 타입, 데이터와 관련된 QoS들로 연관되어있음.

2.2 Identification of data-objects

publish-subscribe system (Data-Centric 시스템과의 차이는?)
- 생산자가 게시된 정보를 식별하는 데 사용하고 가입자가 원하는 정보를 지정하는 데 사용하는 메커니즘에서 확인할 수 있음.
- PS시스템은 간단히 애플리케이션에서 정의된 스트링을 통해서(called topic or subject)접근하는 메커니즘임.
Data-Centric system
- PS와 다르게, Data-centric system에서 정보 교환은 가상의 글로벌 데이터 객체값을 참조함.
- 새로운 값을 이전 값보다 우선하는점을 감안할 때 애플리케이션과 미들웨어 모두 값이 적용되는 "전역 데이터 객체(Global Data Object)"의 실제 인스턴스를 식별해야 함.
- 즉, 데이터 객체의 값을 작성하는 게시자는 작성 중인 데이터 객체를 고유하게 표시할 수 있는 수단이 있어야 함.
- 이러한 방식으로 미들웨어는 작성 중인 인스턴스를 구분하고 최신 값만 유지하도록 결정할 수 있음.

중앙 집중식(centralized) 접근 방식의 한계
- 실시간(real-time) 애플리케이션의 성능(Performance) 및 내결함성(fault-tolerance) 요구 사항으로 인해 중앙 집중식 접근 방식은 비실용적임.
- 따라서 각 데이터 객체의 "진짜 값(true value)"이 단일 컴퓨터에 "존재(live)"할 것이라고 기대해선 안됨.
고려사항 두가지
- (a) 데이터 객체의 인스턴스를 식별하는 전역적 방법이 있어야 하고
- (b) "중앙 집중식" 구현을 강요하지 않도록 소유권 QoS를 신중하게 정의해야 함.
DDS에서의 Topic and key
- 토픽은 이미 네트워크 차원의 주소 지정 체계(network-wide addressing scheme)를 제공하지만, 많은 수의 데이터 객체가 있는 응용 프로그램의 경우 각 데이터 객체 인스턴스에 대해 다른 토픽을 소개하는 것은 오버헤드가 존재함.
- 토픽의 수를 줄이기 위해 OMG DDS는 섹션 1 에서 소개한 Topic 객체와 데이터 객체 인스턴스를 고유하게 식별하는 key의 조합을 사용함.
- key의 표현과 형식은 데이터 타입에 따라 다름.
- 자세히

2.3 Read and write access

PS시스템의 또 다른 특징은 전역 데이터 객체를 읽고 쓰는 데 사용되는 인터페이스임.(아래 논문 그림 2 참조).

2.3.1 Publishing interface

write Operation
- 참가자는 DataWriter 에서 write 작업을 사용하여 데이터를 씀.
- write 작업은 적절한 유형(예: DataWriter 와 연결된 Topic 를 정의할 때 지정된 유형)의 객체를 매개 변수로 사용함.
- write 작업은 데이터 객체에 대한 새 값이 있음을 미들웨어에 알림.
- 반드시 즉각적인 네트워크 통신을 유발하지는 않음.
- 메시지의 실제 생성은 Publisher와 QoS에 의해 따로 제어됨. 실시간 시스템에서 낮은 우선순위 스레드에 의해 write를 수행될 수 도 있기때문임.
dispose Operation
- 데이터 인스턴스를 매개변수로 사용하고 미들웨어에 해당 데이터 인스턴스(키로 식별됨)를 삭제하도록 요청함.
- 삭제의 의미는 이미 해당 데이터 인스턴스에 대한 값을 받은 기존 참여자는 관련 DataReader에 대한 작업을 통해 삭제를 알립니다.
- Data 인스턴스의 존재에 대해 이전에 알리지 않은 참가자는 전혀 볼 수 없습니다.

Publisher Object
- 연결된 하나 이상의 DataWriter 객체를 대신하여 작동함.
- DataWriter 객체 중 하나의 객체중 데이터에 대한 변경 사항을 알리면 데이터 를 보낼 시기를 결정하고 실제로 보낼 책임이 있음. 이 동작은 연결된 QoS에 의해 다뤄짐.
- suspend_publications 및 resume_publications 작업은 Publisher 내의 여러 데이터 객체가 곧 작성될 것이라는 힌트를 미들웨어에 제공하므로 미들웨어가 쓰기 집합의 분배를 일괄 처리하여 대역폭을 보다 효율적으로 사용할 수 있음.
- resume_publications가 호출 될 때까지 메시지 배포를 비활성화하고 변경 사항을 누적할 수 있도록 구현함.
- 미들웨어는 언제든지 메시지를 자유롭게 보낼 수 있으며 예를 들어 LATENCY_BUDGET과 같은 다른 QoS가 위반되는 경우 메시지를 보내야 함.
참가자는 수신자 측에서 일관된 수정 세트로 해석되는 방식으로 변경 세트가 전파되도록 요청할 수도 있습니다.
- begin_coherent_changes :세트를 시작
- end_coherent_changes :세트를 종료
- 이러한 호출은 중첩가능함.

2.3.2 Subscribing interface

읽기 측면에는 리스너 기반 및 대기 기반의( Listener-based and Wait-based ) 두 가지 상호 작용 스타일이 있음.

2.3.2.1 Listener-based data access

참여자가 미들웨어와 함께 설치하는 Listenr 객체를 통해 참가자에게 새로운 데이터 객체의 존재여부 또는 값 변경을 알림.
Listener는 지정된 인터페이스를 구현하는 객체임.
DDS 미들웨어는 Listener에서 적절한 메서드를 호출하여 참가자에게 비동기적으로 알림.
이 접근 방식은 간단하고 효율적임.
데이터 값이 변경되거나 구독과 일치하는 새 데이터 객체가 나타날 때마다 미들웨어는 단순히 참여자에게 알림.
단점으로는 액세스가 미들웨어 스레드의 컨텍스트에서 수행된다는 것임. 동일한 참여자 내부의 다른 동시 스레드가 수행한 작업으로 이 스레드가 읽은 데이터를 구성하는 것이 더 복잡할 수 있음.

2.3.2.2 Wait-based data access

대기 기반 방식은 참여자 내부의 스레드가 특정 변경 세트를 기다리는 동안 차단하는 데 사용할 수 있는 일련의 조건을 제공함.
관심 있는 변경 사항이 발생하면 스레드가 차단 해제되고 자체 컨텍스트에서 데이터에 직접 액세스할 수 있음.
이 상호 작용 스타일은 UNIX select() 호출 또는 Win32 WaitForMultipleObjects() 호출을 사용하여 얻은 것과 유사함.
이 상호 작용 스타일은 특정 응용 프로그램에서 처리하기가 더 쉬울 수 있지만 조건 및 대기의 지정은 더 복잡함.
참가자가 Listener-based와 Wait-based 접근 방식을 사용하는지 여부에 관계없이 DataReader 에서 read 또는 take 작업을 호출하여 데이터에 액세스함.

2.4 Semantics of state propagation

Data-centric PS 시스템의 중요한 사용 사례는 상태 정보 전파임.
해당 논문에서는 시스템 이론과 상태 기계(state-machines)의 고전적인 의미에서 "state"라는 단어를 사용함.
즉, 시스템의 상태(the state of the system)는 입력 및 출력의 과거 이력을 참조하지 않고 미래 응답을 결정하는 데 필요한 정보임.
시스템의 현재 상태, 현재 입력 및 미래 입력 상호 작용의 시퀀스를 통해 모든 미래 상태 및 출력 상호 작용을 계산할 수 있음.
예를 들어, 예금 계좌의 잔액은 계좌 시스템의 상태입니다. 해당 상태를 초래한 모든 트랜잭션 시퀀스는 향후 동일하게 처리됨.
상태의 바로 그 정의는 로깅 목적 이외의 가장 최근 상태만이 중요하다는 것을 분명히 함.
일반적으로 시스템의 상태는 동적 시스템이 "상태 변수(state variables)"라고 부르는 데이터 객체 집합의 결합된 값으로 설명됨.
상태 전파는 응용 프로그램이 원격 시스템을 모델링하는 간결한 방법을 제공할 뿐만 아니라 나중에 참가하는 참가자가 시스템의 전체 기록을 본 것처럼 동작할 수 있도록 하기 때문에 중요함.

특정 시스템의 "상태 변수"가 A, B 및 C라고 가정함. 또한 이러한 변수가 A1, B1, A2, B2, Cl, A3의 순서로 변경된다고 가정함. 시스템에 대한 해당 상태 시퀀스: S1, S2, S3, S4, S5, S6은 모든 상태 변수의 결합된 값으로 제공됨.

•	S1 = { A1 }
•	S2 = { A1, B1 }
•	S3 = { A2, B1 }
•	S4 = { A2, B2 }
•	S5 = { A2 , B2 , C1 }
•	S6 = { A3 , B2 , C1 }

원격(remote) 참가자가 시스템의 현재 상태를 추적하기 위해 A, B 및 C에 구독했다고 가정함.
A, B, C에 대한 새로운 값을 받으면 상태를 재구성 함.
원격 참가자가 소스에 존재하지 않는 상태를 유추해서는 안됨.
- 예를 들어 원격 참가자가 값 A2를 보기 전에 값 B2를 보고 상태를 재구성한 경우에 발생합니다. 그리고 S ={ A1 , B2 }소스에 존재하지 않음.

이 섹션에서는 원격 참가자가 볼 수 있도록 허용되어야 하는 적절한 상태 시퀀스와 DCPS 미들웨어에서의 특정 제한 사항을 보여줌.

	(a). 구독 참여자가 재구성한 상태는 게시 참여자에 실제로 존재하는 상태로 제한되어야 함
	(b). 구독 참여자에서 상태가 재구성되는 순서는 게시 참여자에서 상태가 발생한 순서를 유지해야 함
	(c). 게시 측의 상태가 안정되면(즉, "잠시" 동안 변경되지 않음) 
    	 구독 참가자가 보는 상태는 게시 참가자의 상태와 일치해야 함.

이러한 제한 사항은 구독 참가자가 다음과 같은 시퀀스는 가능하게함.

•	S1 = { A1 }
•	S2 = { A1, B1 }
•	S3 = { A2, B1 }
•	S4 = { A2, B2 }
•	S5 = { A2 , B2 , C1 }
•	S6 = { A3 , B2 , C1 }

•	S1, S2, S3, S4, S5, S6; 또는
•	S1, S3, S6; 또는
•	S5, S6; 또는
•	S6

그러나 다음과 같은 시퀀스가 나오면 안됨.

•	S3, S1, S6; [violates order]
•	S1, S3 [마지막 상태 S6에 안착하지 않음]

2.4.1 Incoherent states

상태가 다음 일관성 있는(또는 유효한) 상태로 전환되도록 여러 상태 변수를 함께 업데이트해야 하는 경우가 있음.
예를 들어 항공기의 위도, 경도, 속도 벡터 및 고도가 세 개의 개별 상태 변수로 유지된다고 가정해봄.

A = (latitude, longitude), B = (velocity_vector), C = (altitude)

DDS 인터페이스는 참가자에게 A, B, C를 "원자적으로(atomically)" 업데이트할 수 있는 수단을 제공해야 함.
수신(receving) 참가자는 B와 C에 대한 새 값을 동시에 보지 않고는 A의 새 값을 볼 수 없어야 함.
그렇지 않으면 항공기가 충돌 경로에 있다고 잘못 추론할 수 있음.
이 기능은 섹션 3 에 설명된 begin_coherent_changes 및 end_coherent_changes 작업에 의해 제공됨.

2.4.2 Presentation access units

대규모 시스템에서는 단일(single) 모놀리식(monolithic) 상태를 정의하는 것으로 모든 상태 변수를 모델링하는 것이 실용적이지 않을 수 있음.
참가자가 상태 변수에 대한 모든 변경 사항을 지연 없이 순서대로 전파하도록하는 것도 실용적이지 않을 수 있음.
이러한 이유로 애플리케이션은 상태를 각각 여러 변수로 구성된 개별 독립 단위로 분할할 수 있음.
DCPS는 이러한 각 장치를 "액세스 장치(access unit)"라고 함
DCPS는 Publisher(Subscriber) 객체 아래에 DataReader( DataWriter) 객체를 그룹화 하고 PRESENTATION QoS 정책을 사용하여 응용 프로그램이 액세스 단위를 정의하는 여러 가지 방법을 제공함.

2.5 Quality of service policies

DDS, 데이터 배포 서비스는 QoS(Quality of Service)를 사용하여 애플리케이션 요구 사항에 맞게 서비스를 조정함.
QoS는 실제로 서비스의 특정 동작을 구동하는 일련의 특성임.
개별 QoS 정책(QoSPolicy에서 파생된 유형의 객체)으로 구성됨.
DCPS 서비스가 지원하는 모든 QoS 정책에 대한 설명은 이 백서의 범위를 벗어남.
오히려 우리는 일반적인 특성을 설명하고 몇 가지 구체적인 예를 제공할 것임.
QoSPolicy는 모든 DCPSEntity 객체에 설정할 수 있음.
대부분의 경우 통신이 제대로 이루어지려면 게시자 측의 QoSPolicy가 구독자 측의 해당 정책과 호환되어야 함.
예를 들어, Subscriber가 안정적(reliably)으로 데이터 수신을 요청하고 해당 Publisher 가 Best-Effort(not ensure) 정책을 정의하는 경우 요청한 대로 통신이 이루어지지 않음.
이 문제를 해결하고 가능한 발행과 구독의 분리를 유지하기 위해 QoSPolicy 사양 은 구독자-요청(subscriber-requestd), 발행자-제공(publisher-offered) 패턴을 따름.
이 패턴에서 구독자 측은 특정 QoSPolicy 에 대해 "요청된" 값의 정렬된 목록을 지정할 수 있음.
게시자 측은 해당 QoSPolicy 에 대해 "제공된" 값 집합을 지정함.
그런 다음 미들웨어는 게시자 측에서 제공하는 가입자 측에서 요청한 가장 선호하는 값을 선택하거나 요청 및 제공되는 QoS를 조정할 수 없는 경우 두 DCPSEntity 객체 간의 통신 설정을 거부할 수 있음.

다음 표에는 지원되는 일부 QoSPolicy 옵션이 나열되어 있음.

QoSPolicy	discription
DEADLINE Parameters: A duration “deadline_period”	DataReader는 deadline_period마다 적어도 한 번씩 각 인스턴스의 값을 업데이트하는 새 샘플을 기대합니다. DataWriter는 참가자가 delay_period마다 적어도 한 번씩 DataWriter가 관리하는 각 인스턴스에 대해 새 값을 쓰기로 약속했음을 나타냅니다.
LATENCY_BUDGET Parameters: A duration “delay_laxity”	데이터가 기록된 이후 구독 참가자가 데이터를 수신할 때까지의 최대 허용 지연에 대한 힌트를 제공합니다.
TIME_BASED_FILTER Parameters: A duration “minimum_se paration”	DataReader가 데이터 값의 하위 집합에만 관심이 있음을 지정할 수 있는 필터입니다. 필터는 DataReader가 변경 속도에 관계없이 minimum_separation마다 하나 이상의 값을 수신하기를 원하지 않을때 사용합니다.
CONTENT_BASED_FILTER A string “expression” and a sequence of strings “parameters”	[선택사항] DataReader가 데이터 자체의 내용을 기준으로 지정된 항목에서 수신한 데이터를 필터링할 수 있는 필터입니다. 식의 구문은 SQL WHERE 절과 같습니다. 파라미터 부분만 변경할 수 있습니다.
PRESENTATION An “access_scope”: INSTANCE, TOPIC, GROUP And two booleans: “coherent_access” “ordered_access”	"access_scope"는 업데이트 순서와 일관성을 유지할 수 있는 엔티티에 걸쳐 가장 큰 범위를 결정합니다. 두 boolean은 "consistent access" 및 "ordered access"가 "access_scope" 내에서 지원되는지 여부를 제어합니다.
	INSTANCE scope. 범위가 단일 인스턴스에만 적용됩니다. 일관성과 순서는 각 인스턴스에 별도로 적용됩니다.
	TOPIC scope. 범위는 동일한 DataWriter(또는 DataReader) 내의 모든 인스턴스로 확장되지만 다른 DataWriter(또는 DataReader)의 인스턴스 간에는 확장되지 않습니다.

테이블의 값 외에도 DURABILITY, OWNERSHIP, LIVELINESS, PARTITION, RELIABILITY 및 DESTINATION_ORDER와 같은 QoS 정책도 지원됨.

2.6 Relation to other standards

DDS와 가장 밀접하게 관련된 사양은 OMG Notification Service와 HLA(High-Level Architecture)임.
결론적으로 아래 두 스탠다드보다 DDS가 보다 효율적이고 개발자에게 유리함.

2.6.1 The OMG Notification Service

해당 Notification Service(NS)는 정보 교환을 채널사이를 흐르는(flow) 이벤트로 모델링함.
애플리케이션은 채널(네임 서버에서 이름을 지정하고 액세스할 수 있음)에 연결한 다음, 공급자(Supplier) 및 소비자(Consumer) 객체를 사용하여 이벤트를 생성하고 소비해야 함.
이벤트는 응용 프로그램이 관심 있는 이벤트를 필터링할 수 있도록 하는 선택적 필드를 가질 수 있는 독립 엔터티임.
채널 및 각 이벤트에 대한 QoS 설정을 통해 Notification Service는 기본 통신(예: 대역폭 절약을 위한 이벤트 일괄 처리)을 예약하고 이벤트가 전달되는 순서(예: 우선 순위에 따라)를 다시 정렬할 수 있음.
응용 프로그램 개발자는 NS를 사용하여 변경 사항을 전파하고 이러한 방식으로 DDS의 기능을 제공할 수 있음.
그러나 Notification Service에는 데이터 객체 또는 데이터 객체 인스턴스 개념이 없고 상태 일관성 개념(state coherence)도 없기 때문에 이렇게 하면 상당히 복잡함.
응용 프로그램 설계자는 이러한 서비스를 맨 위에서 개발해야 하므로 NS에 상당한 복잡성이 추가됨.
이 계층화된 접근 방식은 각 변경 사항을 이벤트로 직렬화하지 않고 DDS API를 구현 미들웨어에 직접 매핑하는 구현만큼 효율적이지 않음.

2.6.2 The High-Level Architecture (HLA)

OMG Distributed Simulation Facility이라고도 하는 HLA는 IEEE와 OMG의 표준임.
DCPS facility과 데이터 모델을 설명함.
OMG 사양은 IDL 전용 사양(IDL-only specification)이며 여러 전송 위에 매핑될 수 있음.
이 사양은 DCPS의 여러 요구 사항을 해결함.
- 애플리케이션은 게시-구독 인터페이스를 사용하여 미들웨어와 상호 작용하고 데이터 모델을 포함하며 콘텐츠 기반 구독을 지원함.
- 또한 HLA는 일반적인 QoS 기능을 제공하지 않음.

2.7 Conclusion

많은 실시간 응용 프로그램은 통신 패턴 중 다음과 같은 요구사항과 특징이 있음.
- 일부를 응용 프로그램이 "데이터"를 게시(공급 또는 스트리밍)한 다음, 관심 있는 원격 응용 프로그램에서 사용할 수 있는 데이터 중심 교환으로 모델링해야 함.
- 이러한 유형의 실시간 애플리케이션은 C4I(군용) 시스템, 산업 자동화, 분산 제어 및 시뮬레이션, 통신 장비 제어 및 네트워크 관리에서 찾을 수 있음.
- 실시간 애플리케이션의 주요 관심사는 최소한의 오버헤드로 데이터를 효율적으로 배포하고 예측 가능성, 오버헤드 및 사용 리소스에 영향을 미치는 QoS 속성을 제어하는 기능임.
- 분산 공유 메모리(Distributed shared memory)는 데이터 중심 교환을 제공하는 고전적인 모델임. 그러나 이 모델은 인터넷을 통해 효율적으로 구현하기 어려움.
따라서 이러한 요구사항을 해결하기 위해 DCPS(Data-Centric Publish-Subscribe) 모델이 많은 실시간 애플리케이션에서 널리 사용되었음.
이러한 타입의 기능을 제공하는 여러 상업 및 사내 개발이 있지만 현재까지 범용 데이터 배포 표준은 없었음.
OMG 데이터 배포 서비스(DDS)는 DomainParticipant, DataWriter, Publisher, DataReader, Subscriber 및 Topic 과 같은 객체 측면에서 DSCP 시스템의 모델을 정의함.
이를 통해 위와 같은 문제를 해결하고 규격화하여 배포함

3. OMG Data-Distribution Service (DDS): Architectural Update

Abstract

위의 #2 논문내용과 중복되는 부분은 요약하고 생략함.
이 논문에서는?
- 분산 응용 프로그램의 개요를 제시.
- DDS 사양 및 해당 구성 요소를 설명.
- DDS를 이용한 분산 응용 프로그램을 설계시 장점.

3.1 Typical Distributed Applicatiols

모든 분산 응용 프로그램에 공통적인 요구 사항 중 하나는 서로 다른 실행 스레드 간에 데이터를 전달해야함.
- 스레드는 동일한 프로세서에 있거나 다른 노드에 분산.
- 이더넷, 공유 메모리등으로 연결.
- TCP/IP 또는 HTTP와 같은 표준 프로토콜이용.

3.2 Communications for Distributed Applications

첫번째 방법은 TCP/IP 소켓 인터페이스가 있는 이더넷 연결을 주로 사용.
- 확장성 문제 : 새 노드가 분산 응용 프로그램에 도입될 때마다 통신 소프트웨어는 새 연결을 설정해야함.
TCP/IP의 장점
- 대부분의 플랫폼에서 사용 가능한 범용 연결 패러다임
- 오늘날 인터넷에서 가장 널리 사용되는 프로토콜
- 파일 전송에 적합
TCP/IP의 단점
- 모든 끝점 노드 주소에 대한 사전 지식 필요.
- 프로그래밍하기 어려움
- 일대일 통신만 지원
- 사용되는 신뢰도를 구성할 수 없음.

두번째 방법은 "클라이언트-서버" 통신 패러다임.
클라이언트-서버의 장점
- 분산 객체
- 동기화 트랜잭션
- 파일 기반 전송
- 원격 메서드 호출
- 원격 명령 처리
클라이언트-서버의 단점
- 두 개의 메시지 전송 필요: 하나는 요청용, 다른 하나는 데이터용
- 일반적으로 서버 노드에 단일 장애 지점존재.
세 번째 방법은 publish-subscribe.
- SBC가 알려진 프로토콜을 사용하여 특정 속도로 데이터를 전송하도록 하는 것
- 이러한 유형의 "푸시" 방법은 "게시-구독"이라고도 함.

3.3 What is DDS?

DDS 사양(specification)의 정의

분산 응용 프로그램이 "DCPS(Data-Centric Publish-Subscribe)"를 통신 메커니즘으로 사용할 수 있는 소프트웨어 응용 프로그램 프로그래밍 인터페이스(API)를 표준화가능함. DDS는 "Infrastrucutre" 솔루션으로 구현되기 때문에 모든 소프트웨어 애플리케이션의 통신 인터페이스로 추가가능함.
DDS의 주요 이점
• 신규 또는 안정화된 엔드포인트 애플리케이션의 "자동 검색(auto-discovery)"을 지원하는 유연하고 적응 가능한 아키텍처
• 단순한 "게시-구독" 커뮤니케이션 패러다임 기반
• 개발자가 시스템의 각 메시지를 완벽하게 제어할 수 있는 많은 수의 구성 매개변수
• 전체 시스템 통합시 위험성이 없는 검증된 아키텍처 기반
• 낮은 오버헤드로 고성능 시스템과 함께 사용 가능
• 결정적(deterministic) 데이터 전달
• 동적으로 확장 가능(dynamically scalable)
• 전송 대역폭의 효율적인 사용
• 일-대-일, 일-대-다, 다-대-일 및 다-대-다 통신 패러다임 지원

게시-구독 애플리케이션
- 데이터를 익명으로 전송(게시)하고 데이터를 수신(구독)하여 서로 통신하는 엔드포인트 노드가 있는 분산 애플리케이션을 의미함.
게시자가 구독자와 통신하기 위해 필요한 유일한 속성은 데이터의 이름과 정의.
게시자와 구독자는 서로에 대한 정보가 필요하지 않음.
통신 중인 데이터를 알고 있는 한 게시-구독 인프라는 개별 연결을 설정하지 않고도 해당 데이터를 적절한 노드로 전달함.
게시자는 데이터를 수집하여 등록된 모든 구독자에게 보낼 책임이 있음.
구독자는 적절한 게시자로부터 데이터를 수신하고 관심 있는 사용자 응용 프로그램에 데이터를 제공할 책임이 있음.

여기도 생략가능함.

3.5 What Does “Data-Centric” Mean?

DS (Data-Centric) 통신은 게시 속도, 구독 속도, 데이터 유효 기간 등 다양한 매개 변수를 데이터 타입별로 지정할 수 있는 기능을 제공함.
QoS 매개변수를 통해 시스템 설계자는 각 특정 데이터에 대한 요구 사항 및 가용성을 기반으로 분산 응용 프로그램을 구성가능함.
DS 환경에서는 분산 응용 프로그램의 특정 요구 사항에 맞게 맞춤화된 통신 메커니즘을 가질 수 있음.
DDS(Data Distribution Service)는 표준화된 인터페이스를 제공하여 DSCP통신 패러다임을 사용함.

3.6 How Does DDS Help Developers ?

데이터 배포를 관리하는 사양에 의존함으로써 분산 응용 프로그램 개발자는 환경마다 다른 응용 프로그램과 통신하는 방법에 대해 걱정할 필요 없음.
DDS는 게시자와 구독자 간의 모든 통신을 처리합니다.
- 데이터를 수집하거나 생성하는 애플리케이션(센서, 파일, 온보드 데이터 계산 등과의 인터페이스를 통해)은 DDS 프레임워크를 사용하여 데이터를 전송(게시)할 수 있음.
- 분산 환경에서 다른 애플리케이션의 데이터가 필요한 애플리케이션은 DDS 프레임워크를 사용하여 특정 데이터 항목을 수신(구독)할 수 있음.
DDS는 데이터 게시자와 수신자 간의 추상 통신(abstrcat communication)을 제공함.
- 데이터 게시자는 각 개별 수신자에 대해 알 필요가 없음. (반대도 동일)
- 통신 중인 특정 데이터 유형에 대해서만 알면 됨.

3.7 An Overview of DDS Components

해당 섹션은 ## 2.1 Introduction과 중복됨.

DDS 사양은 두 개의 개별 섹션으로 나뉨.
- DCPS(Data-Centric Publish-Subscribe)
- DLRL(Data Local Reconstruction Layer)
DCPS는 애플리케이션이 다른 DDS 지원 애플리케이션과 통신하는 데 사용할 수 있는 하위 계층 API임.
DLRL은 응용 프로그램이 고유한 객체 지향 프로그래밍 클래스를 통해 DCPS 데이터 필드와 상호 작용할 수 있는 방법을 설명하는 사양의 상위 계층 부분임.
DLRL은 DDS 사양 내의 선택적 계층임.

3.8 Domains and Domain Participants

도메인 엔티티는 통신을 위해 개별 응용 프로그램을 함께 바인딩하는 데 사용되는 기본 구조임.
분산 응용 프로그램은 모든 데이터 중심 통신에 단일 도메인을 사용할 수 있음.
유사한 데이터 유형을 가진 모든 게시자와 구독자는 이 도메인 내에서 통신함.
DDS는 또한 여러 도메인을 지원할 수 있는 기능이 있으므로 개발자에게 시스템 요구 사항에 따라 확장하거나 다양한 데이터 유형에 따라 기반을 분리할 수 있는 시스템을 제공함.
특정 데이터 인스턴스가 한 도메인에 게시되면 다른 도메인에 거주하는 구독자는 이를 수신하지 않음.

그림 6 에서는 기존 애플리케이션에 새 도메인이 B, C가 추가됨.
도메인 C의 새 메시지는 이전 도메인의 기존 메시지에 영향을 주지 않음.
새 도메인은 새 기능을 테스트하기 위한 격리된 컨테이너를 제공함.
테스트 후 App7과 App8이 사용하는 도메인을 변경하기만 하면 새로운 기능을 원래 시스템으로 돌릴 수 있음.

3.9 Data Writers and Publishers

Data Writers는 애플리케이션이 데이터를 DDS 데이터 도메인에 게시하기 위한 기본 액세스 지점임.
올바른 Quality of Service가 생성 및 구성되면 애플리케이션은 다음과 같은 간단한 쓰기 호출만 수행하면 됨.

retcode = writer->write(data, instancehandle);

추가적으로 서로 다른 시간 기반 필터 QoS를 지정하여 서로 다른 구독자에게 데이터가 게시되는 최대 속도를 다르게 제어할 수 있음.
쓰기가 실행되면 DDS 소프트웨어는 데이터를 현재 컨테이너인 Data Writer에서 Publisher로 이동하여 DDS 도메인으로 보냄.
그림 7 은 데이터를 게시하는 데 필요한 엔티티가 연결되는 방식을 보여줌.

3.10 Data Readers and Subscribers

Data Readers는 구독자가 받은 데이터에 액세스하기 위한 응용 프로그램의 기본 액세스 지점임.
그림 8 은 구독과 관련된 엔터티를 보여줌.
올바른 Quality of Service가 생성 및 구성되면 다음 세 가지 방법 중 하나로 데이터를 사용할 수 있음을 애플리케이션에 알림.
- Listener Callback Routine
  - DDS가 데이터 수신 즉시 실행하는 콜백 루틴
- Polling the Data Reader
  - Data Reader를 폴링 or 쿼리하여 데이터 사용 가능여부 확인.
- Conditions and WaitSets
  - "WaitSet"조건을 설정하여 대기 후 Data Reader에서 데이터 접근.
데이터 액세스는 take() 또는 read()를 호출하여 수행함.

3.11 Topics

토픽은 게시자와 구독자 간의 기본 연결 지점을 제공함.
한 노드에 있는 지정된 게시자의 토픽은 다른 노드에 있는 연결된 구독자의 토픽과 일치해야 함.
토픽은 인터페이스 정의 언어(IDL) 파일에 정의됨.
IDL은 객체/데이터 인터페이스 정의를 위한 OMG 표준 언어.

char
octet
short
unsigned short
long
unsigned long
long long
unsigned long long
float
double
long double
boolean
enum
array and bounded sequence of the above
types
string

예를 들어 다음은 randomNumber.idl이라는 파일에 있는 샘플 토픽의 정의임.

struct RandomNumber {
	float data;
	short processed;
	unsigned long seqNumber; //key
}

이 예에서 randomNumber(.idl 파일의 이름에서 가져옴)는 실제 토픽 이름이고 구조의 정의인 RandomNumber는 토픽의 타입임.

3.12 Topic Keys

토픽 타입의 정의 내에서 하나의 데이터 요소를 토픽의 "키"로 선택할 수 있음.
DDS 미들웨어는 키를 사용하여 들어오는 데이터를 정렬함.
하나의 데이터 요소를 키로 지정하면 애플리케이션은 특정 키와 관련된 데이터를 DDS에서 검색하거나 다음 키 값의 데이터만 검색할 수 있음.
키는 확장성을 제공함.
예) 그림 2 에 여러 SBC가 존재한다하 하자. 키가 없으면 서로 다른 SBC/온도 센서 쌍 각각에 대해 개별 토픽을 생성해야 함.

- TemperatureSensor1
- TemperatureSensor2
- TemperatureSensor3
- And so on ...

다른 센서를 환경에 추가하려면 새로운 주제인 TemperatureSensorN을 만들어야 함. (ROS1의 구성)
그러나 키를 사용하면 다음 타입 정의와 함께 온도라는 하나의 토픽만 필요함.

struct Temperature {
	float data;
	unsigned long sensorId; //key
}

구독자가 "temperature"의 모든 게시자로부터 데이터를 수신하면 데이터를 정렬하고 키 값(이 경우 sensorld)과 관련하여 애플리케이션에 제공함.
새로운 센서는 새 토픽을 생성하지 않고도 추가할 수 있음.
게시 애플리케이션은 해당 데이터를 게시할 준비가 되었을 때 새 sensorId를 입력함.

3.13 MultiTopics & ContentFilteredTopics

표준 토픽(standard Topics) 외에도 MultiTopics 및 ContentFilteredTopics에 대한 구성도 존재함.
MultiTopic은 기본적으로 여러 토픽을 논리적으로 그룹화한 것임.
ContentFilteredTopic을 사용하면 지정된 토픽의 개별 데이터 샘플만 수신되어 애플리케이션에 제공되는 필터 표현식을 선언 간함.
- 예) 특정 구독자가 특정 온도을 초과할 때만 데이터를 수신하고 처리 가능함.

3.14 Quality of Service in DDS

각 데이터 또는 엔티티 기준의 Quality of Service은 DDS의 주요 기능임.
각각의 개별 토픽, Reader or Writer에 대해 서로 다른 QoS 매개변수를 지정할 수 있으므로 개발자는 시스템을 유연하게 설계할 수 있음.
DDS QoS 매개변수는 다음과 같음.

- UserData
- Latency Budget
- Ownership
- Ownership Strength
- Durability
- Presentation
- Deadine
- Time Based Filter
- Liveliness
- Destination Order
- Reliability
- Partition
- History
- Resource Limits

3.15 Summary

DDS는 매우 복잡한 데이터 패턴을 지원하면서 데이터 통신을 위한 매우 간단한 아키텍처를 생성하는 새로운 OMG 사양임. (2000년 기준)
DDS는 데이터 송수신을 위한 API를 제공하므로 개발자가 네트워크 프로그래밍에 대해 걱정할 필요 없음.
간단히 말해, DDS는 "원하는 곳에서 원할 때" 데이터를 배포가능 함.
(게시-구독을 사용하면 "위치"를 쉽게 지정할 수 있음. 데이터 중심은 "언제"를 가능하게함.)

4. Appendix

4.1

ROS에서는 프로그램의 재사용성을 극대화하기 위하여 최소 단위의 실행 가능한 프로세서라고 정의하는 노드(node, [1], [2]) 단위의 프로그램을 작성하게 됨.
하나 이상의 노드 또는 노드 실행을 위한 정보 등을 묶어 놓은 것을 패키지(package)라고 하며, 패키지의 묶음을 메타패키지(metapackage)라 하여 따로 분리함.
수많은 노드들이 연동되는 ROS 시스템을 위해서는 노드와 노드 사이에 입력과 출력 데이터를 서로 주고받게 설계해야함.
여기서 주고받는 데이터를 ROS에서는 메시지(message, [3]~[8])라고 하고 주고받는 방식을 메시지 통신이라고 함.
여기서 데이터에 해당되는 메시지(message)는 integer, floating point, boolean, string 와 같은 변수 형태이며 메시지 안에 메시지를 품고 있는 간단한 데이터 구조 및 메시지들의 배열과 같은 구조도 사용할 수 있음.
그리고 메시지를 주고받는 통신 방법에 따라 토픽(topic, [9]), 서비스(service, [10]), 액션(action, [11]), 파라미터(prameter, [12])로 구분됨.

4.2 DCPS layer

Infrastructure 모듈에는 DCPSEntity, QosPolicy, Listener, Condition 및 WaitSet 클래스가 포함되어 있습니다. 이러한 abstract 클래스는 알림 기반 및 대기 기반 (notification-based and wait-based)의 두 가지 상호 작용 스타일을 지원합니다.
Topic-Definition Module에는 Topic 및 TopicListener 클래스가 포함되어 있으며 더 일반적으로 데이터 유형을 정의하고 주제를 생성하며 QoS 정책을 첨부하기 위해 애플리케이션에 필요한 모든 것이 포함되어 있습니다.
Publish 모듈에는 Publisher , DataWriter 및 PublisherListener 클래스가 포함되어 있으며 일반적으로 게시 측면에서 필요한 모든 항목이 포함되어 있습니다.
Subscribe 모듈에는 Subscriber , DataReader 및 SubscriberListener 클래스가 포함되며 일반적으로 구독 측면에서 필요한 모든 것이 포함됩니다.
Domain 모듈에는 서비스의 진입점 역할을 하는 DomainParticipantFactory 클래스(그림에는 표시되지 않음) 와 다른 개체의 컨테이너인 DomainParticipant 클래스가 포함되어 있습니다.
돌아가기

4.3 Facade

퍼사드는 어떤 소프트웨어의 다른 커다란 코드 부분에 대한 간략화된 인터페이스를 제공하는 객체.
쉽게말해 A클래스에서 B, C, D모듈를 초기화하고 관리하면, A클래스만 인스턴스화 하면됨. 이때 A클래스가 퍼사드가 될 수 있음.
돌아가기

4.4 Topic and Key

토픽은 고유한 유형에 바인딩되어 있으므로 서비스는 항상 토픽과 데이터 객체의 값이 지정된 키를 적절하게 해석할 수 있어야함.
- fixed-type Topic 과 key의 조합은 데이터 중심 시스템에 적합함.
- Topic은 key가 없는 경우 고유한 데이터 객체(예: 온도 센서)를 나타내거나 집합 또는 관련 데이터 객체를 나타내기 때문임.
- 균일하게 취급되는(예: 레이더 시스템에서 생성된 항공기 추적 정보) 여기서 각 개별 항공기는 키로 구별될 수 있음.
- DDS는 유형에 키 해석을 위임하므로 키가 데이터 객체(예: 일련 번호 필드) 내의 단일 값이거나 필드 조합(예: 항공사 이름 및 항공편 번호)이 될 수 있음.
돌아가기

4.5 selct()
'select'는 '블록/비동기적 입출력'에서의 '다중 입출력모델
A, B, C, D 4개의 파일을 다루는 작업을 하고싶다고 가정해볼때 다음과 같은 시나리오를 생각해볼 수 있습니다.
```
	1. A 파일에 대한 작업을 합니다.
	2. A 파일에 대한 작업을 마칩니다.
 	3. B 파일에 대한 작업을 합니다.
 	4. B 파일에 대한 작업을 하다가 프로그램이 '블록(Block)' 상태에 빠집니다.
```
파일에 대한 작업 중 '블록(Block)' 상태가 되는 이유야 다양하겠지만 대표적으로 read() 함수를 호출했는데 읽을 파일이 없다면 프로그램은 읽을 내용이 생길 때까지 '블록(Block)'됩니다. 그럼 위의 상황에서 '블록' 없이 어떻게 4개의 파일에 대한 작업을 정상적으로 실행할 수 있을까요? 답은 간단합니다. A, B, C, D 파일을 순서대로 작업할게 아니라 작업할 준비가된 파일에 대해서만 작업을 하면됩니다. 이러한 생각이 시초가 되어 최초로 탄생한 함수가 'select' 시스템콜입니다.
출처|https://pangtrue.tistory.com/31|
돌아가기

Jeongkyu(Jun)

안녕하세요

[ROS2]OMG Data-Distribution Service: Architectural Overview and OMG Data-Distribution Service: Architectural Update

Paper Review

1. 들어가기(keyword check)

1.1 ROS and ROS2

1.2 ROS2 and DDS(Data-Distribution Service)

1.3 OMG?(Object Management Group)

2. OMG Data-Distribution Service: Architectural Overview

Abstract

2.1 Introduction

2.2 Identification of data-objects

2.3 Read and write access

2.3.1 Publishing interface

2.3.2 Subscribing interface

2.3.2.1 Listener-based data access

2.3.2.2 Wait-based data access

2.4 Semantics of state propagation

2.4.1 Incoherent states

2.4.2 Presentation access units

2.5 Quality of service policies

2.6 Relation to other standards

2.6.1 The OMG Notification Service

2.6.2 The High-Level Architecture (HLA)

2.7 Conclusion

3. OMG Data-Distribution Service (DDS): Architectural Update

Abstract

3.1 Typical Distributed Applicatiols

3.2 Communications for Distributed Applications

3.3 What is DDS?

3.4 What is “Publish-Subscribe”?

3.5 What Does “Data-Centric” Mean?

3.6 How Does DDS Help Developers ?

3.7 An Overview of DDS Components

3.8 Domains and Domain Participants

3.9 Data Writers and Publishers

3.10 Data Readers and Subscribers

3.11 Topics

3.12 Topic Keys

3.13 MultiTopics & ContentFilteredTopics

3.14 Quality of Service in DDS

3.15 Summary

4. Appendix

4.1

4.2 DCPS layer

4.3 Facade

4.4 Topic and Key

4.5 selct()

0개의 댓글

관련 채용 정보