서비스 지향 아키텍처 (Service-Oriented Architecture, SoA)
✅ 개념
각 기능을 서비스로 정의하고, 명시적 요청-응답 형태로 작동하는 아키텍처
ROS2의 Service/Client, DDS 기반 통신 구조에 가장 가까운 개념
✅ 구조 개요
[Client Node] → 요청 → [Service Node] → 응답 반환
예:
[Navigation Client] → /plan_path → [Planner Service]
- 각 기능이 서비스 단위로 설계되며, 요청에 따라 응답을 제공
- 서비스는 네트워크상 또는 내부에서 실행 가능 (로컬/분산 시스템 모두 지원)
✅ 장점
| 항목 |
설명 |
| ✅ 모듈 분리 명확 |
모든 기능이 서비스 단위로 격리 |
| ✅ 유지보수 용이 |
서비스 교체/확장이 간단함 |
| ✅ 네트워크 통합 쉬움 |
IoT/서버와도 통합 가능 |
| ✅ 서비스 재사용성 |
동일 서비스 여러 로봇에서 호출 가능 |
❌ 단점
| 항목 |
설명 |
| ❌ 실시간 제어 어려움 |
서비스 호출/응답은 느릴 수 있음 |
| ❌ 통신 실패 시 처리 필요 |
안정적 Fallback 로직 필수 |
| ❌ 복잡한 상태 공유 |
상태는 외부 저장소(Context 등)로 분리해야 함 |
✅ ROS2 기반 예시
# Client
ros2 service call /start_mission my_pkg/srv/Start
# Service
/start_mission (Start.srv)
request: mission_id
response: success, message
예: UWB 정밀 추종 시작 → /start_follow 서비스 요청 → UWB 모듈에서 응답
🧠 SoA와 Modular 아키텍처 차이
| 항목 |
Modular Architecture |
Service-Oriented Architecture (SoA) |
| 호출 방식 |
내부 함수 호출 / Queue 등 |
명시적 요청/응답 (RPC 방식) |
| 동기/비동기 |
주로 비동기 (Pub/Sub, Callback) |
동기 요청이 많음 (단발성 처리) |
| 상태 공유 |
공유된 구조체, Context로 관리 |
상태는 별도 저장소 또는 다시 서비스 요청 필요 |
| 실시간성 |
중간 이상 |
낮음 (서비스 호출 지연 존재) |
| 확장성 |
높음 |
매우 높음 (서비스만 추가 등록하면 됨) |
✅ STM32 / 임베디드에서의 간접적 적용
- RTOS Task 또는 인터럽트 기반 Command Queue 시스템으로 비슷한 구조 구현 가능
struct ServiceRequest {
enum Type { BUZZER_ON, LED_SET, MOTOR_STOP } type;
int value;
};
QueueHandle_t commandQueue;
void ControlServiceTask(void*) {
while (1) {
ServiceRequest req;
if (xQueueReceive(commandQueue, &req, portMAX_DELAY)) {
switch (req.type) {
case BUZZER_ON: buzzer.on(req.value); break;
...
}
}
}
}
📦 사용 추천 예
| 시스템 유형 |
적합 여부 |
설명 |
| ROS2 기반 로봇 |
✅ 매우 적합 |
기본 구조가 SoA 기반 |
| Jetson 서버 + STM32 |
✅ 적합 |
STM32를 Service Provider로 사용 |
| 실시간 PID 제어 |
❌ 부적합 |
빠른 응답 요구 시 부적합 |
📌 결론
- ROS2, DDS 기반 로봇 시스템에서 강력한 아키텍처
- 명확한 인터페이스 정의, 모듈화, 원격 호출이 필요한 시스템에 적합
- 실시간성이 중요하지 않은 관리용 기능 (예: LED 설정, 상태 요청)에 이상적
댓글