소프트웨어 아키텍처
소프트웨어 아키텍처는 소프트웨어를 구성하는 컴포넌트와 컴포넌트의 관계를 추상적인 수준에서 정의하는 것을 말한다. 즉, 소프트웨어 전체 구조를 한눈에 볼 수 있다면, 각 컴포넌트와 컴포넌트 사이의 관계에 대한 근거를 판단할 수 있다. 또 소프트웨어 아키텍처는 소프트웨어에 대한 이해를 돕고 시스템 수준의 설계 모델을 재사용할 수 있게 해주며, 품질 요구 사항을 반영할 수 있게 해 주며, 소프트웨어 상세 설계 및 구현 이전 초기 설계 단계에서 소프트웨어가 가질 품질 요구 사항을 예측할 수 있게 해준다.
예를 들면 휴머노이드 로봇 시스템은 여러 개의 액추에이터를 제어해야 하는 액추에이터 제어 관련 소프트웨어, 비전 센서와 같은 센서 입력을 다루는 다양한 형태의 센서 관련 소프트웨어, 휴머노이드 로봇을 움직이기 위하여 여러 개의 액추에이터를 통합 제어해야 하는 모션 컨트롤 관련 소프트웨어, 사람들을 피해서 특정 지점까지 갈 수 있는 경로를 만들어 주는 경로 계획 소프트웨어 등과 같은 다양한 소프트웨어들을 포함하고 있다.
이러한 소프트웨어들을 추상화시켜서 컴포넌트라 부른다. 컴포넌트는 명백한 역할을 가지고 있으며 독립적으로 존재할 수 있는 시스템의 부분으로 정의된다. 예로 휴머노이드 로봇 시스템에서 비전 센서나 모션 컨트롤 등과 같은 소프트웨어는 로봇 시스템의 서브시스 템으로서 컴포넌트로 정의될 수 있다.
이러한 컴포넌트들은 재사용 가능하도록 설계되어야 한다. 즉, 현재 사용되고 있는 모션 컨트롤러를 다른 컨트롤러로 변경할 경우, 변경된 컨트롤러에 관한 소프트웨어만 변경하면 나머지 다른 기능들, 즉 비전 센서 관련 소프트웨어의 변경 없이도 로봇 시스템이 정상적인 동작을 할 수 있다는 의미이다. 이러한 재사용성을 만족하려면, 컴포넌트들 간의 인터페이스와 상호 작용에 대하여 명확히 정의가 되어 있어야 한다.
일반적으로 소프트웨어 아키텍처가 중요한 이유는 다음과 같다.
첫째,
소프트웨어 아키텍처는 이해 관계자와의 커뮤니케이션을 위하여 정의된 형상이자 표현의 수단이다. 소프트웨어 아키텍처를 통해 이해 관계자들(프로젝트 관리자, 품질 담당 자, 개발자, 테스터, 고객 등)은 보다 원활한 커뮤니케이션을 할 수 있다.
둘째,
소프트웨어 아키텍처는 설계 방향의 가이드가 된다. 전체적인 관점에서 품질 속성을 고려하여 목표 시스템의 설계 방향을 조기에 결정할 수 있도록 지원하고, 향후 발생할 수있는 위험 요소를 감소시킬 수 있다.
셋째,
소프트웨어 아키텍처는 재사용 가능한 시스템의 추상화를 제공함으로써 소프트웨어 아키텍처가 시스템을 구성하는 요소와 이들 간의 관계를 간략하고 명확하게 나타낼 수 있다. 따라서 비슷한 기능과 품질 요소를 가지는 다음 시스템에서의 큰 규모의 재사용이 가능하고, 소프트웨어 조직의 자산으로써 재사용 또한 용이해진다.
소프트웨어 아키텍처는 [그림 1]과 같이 요구 사항과 구현 사이에서, 요구 사항을 제대로 구현하기 위해 도움을 줄 수 있는 커뮤니케이션 툴이자 개발 초기의 요구 사항과 실제 솔루션 간의 간극을 좁혀줄 수 있는 훌륭한 도구이기도 하다.
로봇 소프트웨어 아키텍처
- 로봇 소프트웨어 프레임워크
로봇 시스템에서는 로봇 소프트웨어 프레임워크(framework)라는 용어를 사용하기도 한다. 일반적으로 소프트웨어 공학에 있어서 프레임워크(framework)는 API(application programming interface)와 같은 라이브러리로 잘 정의되어서 재사용이 가능한 소프트웨어 이다. 자바의 JDK나 마이크로소프트의 .NET framework가 프레임워크의 좋은 예라고 볼수 있다.
그러나 로봇 시스템에서 프레임워크는 조금 다른 의미로 해석된다. 즉, 로봇 시스템에서는 재사용이 가능한 소프트웨어라는 점에서는 소프트웨어 라이브러리와 유사하나, 전체적인 프로그램의 제어 흐름이 사용자에 의하여 지배되는 것이 아니라 프레임워크에 의하여 결정된다는 점에서 큰 차이를 가지고 있다.
이러한 로봇 시스템 프레임워크, 또는 프레임워크와 개발 환경이 통합되어 있는 로봇 플랫폼(platform)은 로봇 시스템이 여타의 다른 소프트웨어와는 다른 특수성을 가지고 있기 때문이다. 산업 현장에서 로봇 시스템을 제작할 경우 모터나 센서, 모션 컨트롤러 등과 같은 부품들을 기성품으로 구매한 후 이를 통합하는 작업, 즉 로봇 소프트웨어 개발과 상용화 작업을 거친다. 따라서 로봇 소프트웨어 개발자에게 상용화되어 있는 부품들의 소프트 웨어를 쉽게 사용할 수 있다면 시스템 통합 작업이 단순해지고 프로젝트의 개발 시간을 줄여줄 수 있을 것이다.
이에 대한 해결책이 로봇 소프트웨어 플랫폼이다. 로봇 소프트웨어 플랫폼이란 로봇 응용 프로그램을 개발할 때 필요한 하드웨어 추상화, 하위 디바이스 제어, 로보틱스에서 많이 사용되는 센싱, 인식, 자기 위치 추정과 지도 작성(SLAM), 모션 플래닝(motion planning) 등의 기능 구현은 물론이고, 패키지 관리, 개발 환경에 필요한 라이브러리와 다양한 개발/ 디버깅 도구 등을 포함하는 것을 말한다. 소프트웨어 플랫폼에는 대표적으로 로봇 운영체제라 불리는 OPEN SOURCE ROBOTICS FOUNDATION의 ROS(robot operating system), 일본 AIST의 OpenRTM, 유럽의 OROCOS, 한국의 OPRoS, 마이크로소프트의 MSRDS, EVOLUTION ROBOTICS의 ERSP 등이 있다.
- 로봇 소프트웨어 아키텍처의 계층 구조
[그림 2]는 로봇 소프트웨어 아키텍처의 계층 구조를 나타내고 있다.
(1) 하드웨어 계층
최하위 계층은 하드웨어 계층으로서, 액추에이터와 센서를 구동하기 위한 드라이버들이 정의되어 있다.
(2) 로봇 실시간 운영체제 계층
다음 계층은 운영체제(OS, operating system) 계층으로서 하드웨어의 관리와 어플리케이션의 관리, 그리고 어플리케이션이 하드웨어를 활용할 수 있도록 인터페이스를 제공 하는 일련의 소프트웨어의 집합이다. 여기서 관리의 의미는 하드웨어 접근의 권한과 제한된 하드웨어를 어플리케이션들이 어떻게 공유하는지에 대한 방법들을 의미한다.
로봇 시스템에서는 실시간 운영체제(RTOS, real-time operating system)를 주로 사용한 다. 실시간 운영체제는 일반 운영체제에 비하여 시분할의 방법 및 정밀도가 우수하며, 정밀 제어를 위해 폭넓게 사용된다. 즉, 프로그램 내에서의 작업을 나눈 태스크(task)가 다수 존재하는 경우 이들의 우선순위와 실행되는 빈도를 정밀하게 조정할 수 있다. 예로 로봇의 경우 센서를 처리하는 태스트는 10 msec마다 실행해야 되고 모터를 제어하는 태스트는 5 ms마다 실행해야 된다면, 실시간 운영체제는 센서와 모터에 관한 태스 크들이 주기적으로 제 시간에 동작되도록 태스크들을 관리한다.
(3) 로봇 미들웨어 계층
로봇 미들웨어 계층은 로봇의 전체적인 운영은 물론 각종 모듈의 제어를 위한 라이브 러리와 관리 프로그램을 포함하는 것으로 운영체제 위에서 동작하는 응용 계층을 지원하는 플랫폼이라고 할 수 있다. 로봇의 복잡도가 증가함에 따라 산업용 로봇은 물론 서비스용 로봇에 이르기까지 광범위하게 적용되고 있다.
(4) 로봇 응용 프로그램 계층
로봇 응용 프로그램 계층은 미들웨어에서 API로 만들어져 있는 라이브러리를 이용하여 작성되고 운영 체제의 관리 하에서 실행된다.
컴포넌트 다이어그램
- 컴포넌트 다이어그램
컴포넌트 다이어그램에서 컴포넌트는 시스템을 구성하는 임의의 물리적인 요소를 의미한 다. 물리적인 요소란 가상의 모델을 실제로 구현하여 나타내는 것을 의미한다. 컴포넌트는 객체 지향 프로그램의 원리에 따라 업무 기능과 관련 데이터를 하나의 단위로 처리하고 있다. 즉, 컴포넌트란 인터페이스에 의해서 기능이 정의된, 독립적으로 개발·배 포·조립이 가능한 시스템의 구성단위이다. 로봇 소프트웨어 아키텍처에서 경로 계획 등과 같은 모듈들은 컴포넌트의 예가 된다.
- 컴포넌트 다이어그램의 구성 요소
컴포넌트 다이어그램은 시스템을 구성하는 물리적인 컴포넌트와 그들 사이의 의존 관계를 나타내는 다이어그램이다. 컴포넌트 다이어그램은 컴포넌트와 인터페이스로 표현된다.
(1) 컴포넌트
컴포넌트는 탭이 달린 직사각형으로 표현되며, 모든 컴포넌트는 반드시 이름을 가지고 있어야 한다. [그림 3]은 OPRoS 소프트웨어 아키텍처에서 제공하는 컴포넌트를 나타내고 있다. OPRoS에서 컴포넌트는 컴포넌트의 특성을 기술하는 컴포넌트 프로파일(component profile)을 가지고 있다. 컴포넌트들의 조합을 용이하게 하기 위해 컴포넌트의 특성 및외부 인터페이스 등에 대한 정보를 기술하는 컴포넌트 프로파일 정보가 컴포넌트와 함께 제공된다. 컴포넌트는 하나 이상의 포트로 구성되며, 포트는 종류에 따라 서비스 포트, 데이터 포트, 이벤트 포트로 나뉘며 기본 포트(port)를 상속하여 만들어진다. 각 컴포넌트는 컴포넌트의 생명 주기 관리를 위한 제어 서비스 포트(control service port)와 모니터링을 위한 모니터링 서비스 포트(monitoring service port)를 디폴트로 가지고 있다.
제어 서비스 포트를 이용하여 컴포넌트 외부에서 해당 컴포넌트의 초기화, 시작, 중지, 일시 정지, 재시작 등의 생명 주기 관련 API를 호출할 수 있으며, 모니터링 서비스 포트를 통해 해당 컴포넌트의 상태를 모니터링할 수 있다. 디폴트 포트 이외에 사용자가 정의하는 포트는 portinterface의 API를 통해 컴포넌트에 추가할 수 있다. 사용자가 개발하려고 하는 유저 컴포넌트는 OPRoS 컴포넌트에서 제공하는 추상 컴포넌 트인 component를 상속 받아 구현해야 한다. component는 property 관리를 위한 propertyinterface와 생명주기 관리를 위한 lifecycleinterface, 그리고 포트 관리를 위한 portinterface를 상속받은 추상 컴포넌트이다. 컴포넌트의 구현에서는 사용자는 component 를 상속받아 필요한 콜백 함수를 정의하고, 사용자 정의 메소드를 추가하기만 하면 된다.
(2) 인터페이스
인터페이스는 컴포넌트와 컴포넌트 간의 관계를 표현하기 위하여 사용된다. [그림 4]는 OPRoS 소프트웨어 아키텍처에서 외부 컴포넌트와의 인터페이스 방법을 나타내고 있다. OPRoS에서 컴포넌트에서는 외부 컴포넌트와의 인터페이스를 포트 (port)를 통해 수행한다. OPRoS에서 포트 종류에는 서비스 포트(service port), 데이터 포트(data port)와 이벤트 포트(event port)가 있다. 외부에 서비스를 제공하는 서비스 포트를 provided 포트라고 하며, 외부의 서비스를 이용해야하는 경우에는 required 포트라고 한다. 또 데이터 포트 및 이벤트 포트는 외부로부터 데이터(혹은 이벤트)를 수신하는 포트를 input 포트라고 하며, 외부에 데이터(혹은 이벤트)를 송신하는 포트를 output 포트라고 한다.
컴포넌트는 서비스 포트, 데이터 포트, 이벤트 포트 중 적어도 하나의 포트를 갖고 있어서 외부와의 인터페이스를 수행한다. 또 컴포넌트는 용도에 따라 다양하게 포트를 생성하여 사용할 수 있으며, 같은 종류의 포트를 여러 개 생성하여 컴포넌트를 구성할수 있다.
컴포넌트는 서비스 포트를 통해 다른 컴포넌트가 제공하는 메소드를 호출하거나 해당 컴포넌트의 속성에 접근할 수 있으며, 데이터/이벤트 포트를 통해 해당 컴포넌트에 데이터나 이벤트를 전달할 수 있다. 컴포넌트 간의 메소드 호출이나 데이터/이벤트 전달은 모두 포트를 통해 이루어지기 때문에, 다른 컴포넌트에 메소드를 호출하거나 데이터/이벤트를 전달하기 위해서는 해당 컴포넌트의 포트를 알아야 한다. 이를 위해 컴포넌트 개발자는 해당 컴포넌트가 제공하는 포트와 다른 컴포넌트가 사용할 수 있는 포트를 인터페이스 프로파일 (interface profile)에 명시해야 한다.
서비스 포트는 컴포넌트 내부의 메소드들과 바인딩되어 사용되며, 데이터 포트는 데이터 처리기(data processor)와 바인딩되어 주기적인(periodic) 방식이나 비주기적 (non-periodic) 방식으로 컴포넌트의 onExecute( )를 호출하여 데이터를 처리한다. 이벤트 포트는 이벤트가 도착 시에 특정 메소드(onEvent( ))가 즉시 호출되어 상태 관리를 하도록 한다.
'Robotics : 로봇공학 > Certificate : 자격증' 카테고리의 다른 글
| 필기 시험 노트 현황 업데이트 v230810 - 로봇 소프트웨어 기사 (0) | 2023.07.23 |
|---|---|
| 2-3-4 소프트웨어 아키텍처 설계하기 (0) | 2023.07.23 |
| 2-3-2 로봇 작업 요구사항 분석 2/2 (0) | 2023.07.22 |
| 2-3-1 로봇 작업 요구사항 분석 1/2 (0) | 2023.07.22 |
| 필기 시험 노트 현황 업데이트 v230716 - 로봇 소프트웨어 기사 (1) | 2023.07.16 |
