27. 소프트웨어 설계 특성

 

항공전자 설계는 1990년대 초에 DO-178B가 작성된 이후 현저하게 발전했다. 하드웨어와 소프트웨어는 더 복잡해지고 강력해졌다. 동시에 항공전자 컴포넌트와 툴 판매자들은 그들의 공급을 엄청나게 확장해왔지만 반면에 경쟁압력과 줄어든 시장 적기 출시의 시간은 개발적인 도전을 야기하게 만들었다. 이 책이 쓰여지는 때에 DO-178C가 개발되고 있고 DO-254 인증에 대해서 새로운 설명이 제공되고 있다. 항공전자 개발자들에 의해서 언급될 필요가 있는 최고의 이슈들은 무엇인가?

현대 항공전자 설계 특성   단일 CPU내에 여러 개의 위험 레벨 시간 파티션 공간 파티션 리소스 I/O 보호 ARINC 653 준용

 

최근 몇 년 내에 나타난 주요 이슈들은 위에서 보여지는 것과 같다. 여러 개의 위험 시스템들이 오랜 기간동안 존재해 왔다. 전통적으로 서로 다른 위험레벨을 가진 세그먼트들은 메모리를 공유했고, 서로 다른 위험레벨에서 동작하는 태스크들간에 운영체제에 대한 고려나 보장된 분리가 없었다. 여러 개의 위험 시스템으로 우리는 동시에 여러 개의 프로세스를 실행하려고 노력하고 있었다. 만약 그들이 서로 다른 CPU상에 있고 당신이 물리적으로 구분되고 완전히 다른 소프트웨어 패키지를 보여줄 수 있다면 유일한 걱정은 통신이다. 둘 사이의 공유된 메모리 공간에 대한 문제는 없으며 더 낮은 위험레벨을 가진 태스크(엄격하게 개발되거나 검증된 적이 없는)는 더 높은 위험레벨을 가진 태스크의 동작을 교란시킬 능력을 가지고 있지 않다. 당신은 다른 것에 의해서 어떤 하나가 직접적인 손상을 입는 것에 대비해서 그들 간에 주고받는 데이터에 대해서 걱정한다.

역주) Windriver사에서 만든 VxWorks653 RTOS는 시간과 공간에 대한 파티션을 완벽하게 지원한다. DO-178 인증까지 받았다고 하니 그야말로 최신 항공전자 장비에는 필수에 가깝다고 할 것이다. 이런 강력한 소프트웨어를 사용하게 되면 물리적으로 분리된 여러 대의 장비를 하나의 장비로 통합해서 만드는 것이 가능하게 된다. 여기에서 저자는 이런 최신 기술이 없었던 구형 항공기에서 안전성을 위해 물리적으로 분리해서 구현했던 부분과 그에 따른 고려사항 등을 설명하고 있다. 이 모든 것이 결국은 항공기의 안전성을 확보하기 위한 개념이라는 점을 기억하자.

 

그러나 현대의 항공전자에서는 무게와 전력 감소에 대한 경향이 분명하게 나타나고 있다. 이것은 이전에는 서로 다른 LRU로 할당되었던, 혹은 적어도 동일한 LRU 내에서 서로 다른 카드로 할당되었던 기능의 통합을 의미한다. 이것은 서로 다른 위험레벨을 가진 서로 다른 태스크들이 동일한 프로세서를 통해서 실행될 필요성에 대한 요구가 더 강화되었다는 것을 의미한다. 이런 케이스에는 또한 하나의 태스크가 다른 태스크의 메모리나 리소스를 침범함으로써 못쓰게 만들 가능성이 있다. 일반적으로 개발 및 검증의 엄격함이 떨어지는 더 낮은 위험레벨의 태스크가 그 범인이라고 할 수 있다.

 

그래서 시스템 위험레벨은 시스템을 구성하는 서브시스템 내의 가장 높은 위험레벨과 같다. 만약 하나의 기능이 치명적인 영향을 가져올 수 있다면 비록 다른 기능들이 더 낮은 레벨로 인증받게 되더라도 그 하나의 기능 때문에 레벨 A가 될 것이다. 왜 그냥 모든 서브시스템과 컴포넌트를 레벨 A로 개발하지 않는가? 순전히 비용 때문이다. 때때로 당신은 만약 그럴 가치가 있다면 모든 레벨 B 기능들로부터 하나의 레벨 A 기능을 파티션으로 나누기를 원하게 된다. 하지만 그만한 가치가 있을까? 레벨 B와 레벨 A 사이의 비용 절감은 적기 때문에 근본적인 이유와 잠재적인 절감 비용을 조사해볼 필요가 있다. 기억하자. 파티션을 위한 노력 또한 어렵고 그것에 대한 안전성을 증명하는 것도 상당히 어렵다. 만약 더 낮은 위험레벨의 기능이 더 높은 소프트웨어 위험레벨에 영향을 주지 않는다는 것을 보여줄 수 있다면 문제가 없다. 하지만 설계, 시험 그리고 아키텍처를 통해서 그것을 보장해야 하며 그런 다음에는 그것을 FAA에 증명해야 한다. 그것을 하기 위한 두 가지 가장 중요한 것은 시간과 공간에 대한 파티션이다. 동적 메모리 할당은 허용되지 않을 것이다.

시간 파티션   시간 파티션 = 결정론적인 스케줄링과 실행 실행 오버런에 대한 탐지를 제공해야 한다 스케줄러내에 가변성이 없음 모든 시스템 호출에 대해서 일정하게 정해진 컴퓨팅 시간 보장할 수 없는 시스템 호출의 사용을 막음 동적 데이터 구조를 사용하지 않음 시스템 실행 시점에서만 메모리 할당 세마포 사용의 제한 (차단(Blocking)과 동기화 이슈)

 

시간 관점에서의 결정론적인, 휼륭한 스케쥴링은 실행 오버런 방지를 제공해야 한다. 각각의 시스템 호출과 사용에 대한 엄격한 시간 할당이 있다면 이것은 특별히 중요하고 도전적인 것이다. 데이터 구조는 동적으로 할당될 수 없다. 메모리 할당은 시스템 시작시에만 허용된다. 그것이 MMU(Memory Management Unit)를 가진 CPU와 메모리 관리 시스템을 가진 RTOS 그리고 시간과 공간 파티션을 근본적으로 지원하는 능력이 필요한 이유이다. 우리 고객의 대부분은 이런 목적을 위해 Green Hills사의 Integrity-178B를 사용했다.

공간 파티션   공간 파티션 = “메모리 보호” 실행/읽기/쓰기 허용을 강제하기 위한 내장된 하드웨어 메모리 유닛(MMU) 사용 다른 파티션에 의한 접근으로부터 보호되는 파티션 메모리 메모리 위반이 탐지되고 완화됨 파티션내의 시스템 호출은 동작을 수행하기 위해 해당 파티션의 메모리 할당을 사용 재귀호출을 하지 않음으로써 최대 커널 스택 사이즈를 보장 리소스와 I/O 보호

 

차단(Blocking)과 동기화 이슈로 인한 세마포 사용 금지. 당신은 이것을 보장해야 한다. 그렇지 않으면 파티션을 증명할 수 없을 것이다. 공간의 관점에서 메모리 보호(Protection)를 살펴보자. CPU는 보호(Protection)에 대한 하나의 레벨을 제공하며 반면 RTOS는 다른 것을 제공한다. 각각의 파티션이 모든 프로세싱을 위해 자신들만의 할당된 메모리내에서 완전하게 유지할 수 있도록 하기 위해 메모리를 할당할 수 있어야 한다. 유일한 내부 프로세스 상호작용은 공유된 메모리가 아니라 사전 정의된 통신 프로토콜을 통해서이다. 동적 할당은 허용되지 않는다. 재귀호출 코드는 가질 수 없다. 그렇지 않으면 스택 오버플로우가 생길 것이다. 항상 모든 시스템에서 실패를 탐지하고 위반을 완화하기 위한 방법 또한 있어야 한다.

역주) Windriver사에서 만든 VxWorks653 RTOS는 시간과 공간에 대한 파티션을 완벽하게 지원한다고 설명했다. 여기에 나오는 내용들은 사실 역자가 자세히는 알지 못하지만 어느 정도 들어본 내용들이기는 하다. 혹시 자세한 내용, 정확한 내용을 알고 싶은 분은 Windriver사의 사이트로 가서 원문을 제대로 살펴보실 것을 추천드린다.

 

RTOS. 20년 전에 우리는 운영체제를 자주 사용하지 않았다. Poll 루프를 사용하거나 고작 커널을 사용했었다. 오늘날의 중요하고 복잡한 시스템에서는 만약 향후의 발전 가능성을 가진 좀 더 개선된 프로젝트를 개발하기를 원한다면 당신은 레벨 A 혹은 B이자 5천 혹은 1만라인의 코드를 가지게 된다. 대부분의 프로젝트가 그런 구현을 위해서 RTOS를 사용한다. 거기에는 비동기적으로 동작하는 여러 개의 태스크들과, 재사용가능하며, 플랫폼 전반에 걸친 공통성과 방대한 코드 베이스가 있을 수 있다. 만약 단지 수 천라인의 코드만을 가지고 있다면 그것은 당신이 더 높은 위험 레벨을 가지지 않으면 인증가능한 상용 RTOS가 되기가 어려울 것이다. 만약 그러한 모든 것들이 존재한다면 당신은 아마도 운영체제를 고려할 지 모른다. 이제 질문은 당신이 직접 그것을 만드느냐, 어떤 것을 수정하느냐 혹은 COTS를 사용하느냐이다.

 

RTOS 사례 연구   현대의 항공전자장비들은 다음 중 하나라도 요구될 때 실시간 운영체제를 사용해야 함   비동기적으로 동작하는 여러 개의 태스크 재사용성 플랫폼 전체에 걸친 공통성 방대한 양(5천 LOC 이상)의 소스 베이스를 포함 더 상위의 위험레벨이 필요   만약 위의 항목 중 하나라도 필요하다면 RTOS를 추천한다. 만약 전체가 필요하다면 RTOS는 필수이다.

 

10년전에 우리는 모든 것을 자체적으로 수행했다. 비록 전형적인 운영체제가 천 라인이상의 코드를 가지고 있었지만 모든 라인의 코드의 MCDC에 대한 구조적 커버리지를 포함해서 우리가 논의했던 것들을 수행해야 했기 때문에 인증에 수 백만 달러가 사용되었다. 중요한 특성은 시간과 공간에 대한 파티션인데 그것은 시간 경계를 넘어서게 되면 무엇인가 발생한다는 것을 의미한다. 같은 방식이 공간에 대한 경계에도 적용되며 경계를 넘어서게 되면 덮어쓰게 된다. C 프로그래머들은 때때로 잘못된 포인터를 사용하는 경우가 있을 텐데 공간 파티션은 그것을 완화시킨다.

 

와치독 타이머는 대단하지만 시스템 레벨에서의 타이밍 오버런 혹은 정지된 태스크와 같은 것들에 제한된다. 현대의 프로세스들, 예를 들면 power PC 계열에서는 메모리 제약을 벗어나기 위해 RTOS와 연동하여 메모리 관리 시스템을 사용하는 내장된 파티션을 가지고 있다. ARINC 653은 운영체제와 이식성에 대한 표준이고 따라서 이론적으로는 당신은 이식성을 가지고 있다. 하지만 조심해야 한다. 이론적으로는 운영체제간의 이식성을 가지고 있지만 실제로는 적정한 비용으로 그것을 달성하는 것을 본 적이 거의 없다.

 

운영체제는 거기에서 돌아가는 어떤 소프트웨어 레벨보다도 가장 높은 레벨로 인증받아야 한다. 당신이 반드시 그렇게 해야하는 것이 아니라면 자신만의 BSP를 개발하기를 원하지 않는다. 일반적으로 당신은 판매자로부터 구매할 수 있고 거기에서는 약 30,000달러 ~ 50,000달러 정도로 그것을 수정해 줄 것이다. 그것은 직접 개발하는데 몇 년을 소비하는 것보다 더 적은 비용을 사용하게 될 것이다.

 

운영체제 판매자에게 물어볼 질문은 다음과 같다. 완전한 인증 패키지를 구매할 수 있는지 혹은 더 나아가서는 직접 수행할 수 있는 세트형태로 제공되는가이다. 당신(구매자)은 스스로 문서를 생성해야 할 것이다. 만약 그렇다면 어떤 것들을 생성해야 하는가? 인증을 포함한 통합된 BSP를 구매할 수 있는가? 그리고 가격은 얼마인가? FAA 인증이 RTOS의 그 버전에 대해서 그리고 요구되는 위험레벨에 따라서 이미 공식적으로 승인되었는가? 그리고 그 운영체제 회사는 얼마나 많은 인증을 완료했는가?

 

이러한 것들이 핵심 질문들이다. 많은 회사들이 자신들의 운영체제가 인증되었다고 말하지만 운영체제는 사실상 시스템을 기반으로 해서 인증받는 것이다. 그 자체로 얻을 수 있는 최선은 시스템 내의 하나의 컴포넌트로써 인증가능성(Certifiable)을 얻는 것이다. 기억하자. 인증받는(Certified) 것은 시스템이지 컴포넌트가 아니다. 따라서 공격적인 주장에 유의하라.

현대의 항공전자에서 필요한 RTOS 특성은 무엇인가?   시간과 공간 파티션 ARINC 653 여러 위험레벨의 지원 I/O 보호(Protection)의 보장 시중에 많이 사용되는 BSP와의 통합     상용 RTOS 판매자들에게 물어볼 질문들   안전한 인증 패키지, 모든 문서들을 구매할 수 있는가? 통합된 BSP를 구매할 수 있는가? FAA 인증이 공식적으로 승인되었는가? 얼마나 많은 인증이 성공적으로 완수되었는가?