23. DO-178 인증을 위한 멀티코어 프로세서에 대한 Objective Table (한글) – CAST-32A (4)

cast-32A.pdf

CAST 32-A에 대한 설명에서 맨 처음 제시되었던 영문 테이블을 한글로 그대로 번역하였다. 세부 내용에 대한 해설이 필요한 분들은 이전 절에서 설명한 부분을 참고하시기 바란다.

 

CAST-32A에서 제시하는 MCP에 대한 목표 (MCP Paper Objectives)
ID	내용
Objective 1 - MCP_Planning_1	지원자의 소프트웨어 계획 혹은 다른 전달가능한 문서들이: 1)     제조사로부터의 유일한 구분자를 포함하는 특정한 MCP 프로세서를 구분 2)     활성화되는 코어의 개수를 구분 3)     사용되는 MCP 소프트웨어 아키텍처와 MCP에서 운영될 모든 소프트웨어 컴포넌트를 구분 4)     MCP상에서 운영되는 소프트웨어에서 제공되는 것들 중에 활성화될 동적 특성들을 구분하고 그것들이 어떻게 사용될 지에 대한 상위레벨 설명을 제공 5)     MCP 장비가 하나 이상의 시스템으로부터 소프트웨어 어플리케이션을 주관할 IMA 플랫폼에서 사용될 것인지를 구분 6)     MCP 플랫폼이 이 문서에 정의된 것처럼 강건한 리소스 파티셔닝 그리고/혹은 강건한 시간 파티셔닝을 제공할 것인지를 구분 7)     MCP 혹은 선택된 MCP 아키텍처의 사용 때문에 필요로 하는 어떤 방법 혹은 툴을 포함해서 이 문서의 목표(Objective)를 만족하기 위해 MCP 상에서 운영되는 모든 개별적인 소프트웨어 컴포넌트들을 개발하고 검증하기위해 사용되는 방법들과 툴을 구분   유의사항: a)     MCP 소프트웨어 아키텍처는 AMP, SMP 혹은 지원자에 의해서 사용되는 다른 아키텍처를 포함한다. b)    구분되는 소프트웨어 컴포넌트에는 운영 시스템, 하이퍼바이저, 소프트웨어 어플리케이션, 그리고 소프트웨어에서 제공되는 모든 기능들이 포함되어야 한다. IMA 플랫폼을 사용하는 MCP의 경우에는 구분되는 소프트웨어 컴포넌트가 운영되는 소프트웨어 어플리케이션을 포함해야 하는 것은 아니다. c)     소프트웨어에서 제공되는 동적 특성은 코어로의 어플리케이션 동적 할당과 실행하는 동안에 소프트웨어 실행에 영향을 줄 수 있는 소프트웨어의 다른 동적 특성을 포함해야 한다.
Objective 2 - MCP_Resource_Usage_1	지원자는 시스템의 기능, 성능 그리고 타이밍 요구사항을 만족하기 위해 MCP상에서 운영되는 하드웨어와 소프트웨어를 실행 가능하게 할 MCP Configuration Settings을 정하고 문서화해왔다.
Objective 3 - MCP_Resource_Usage_2	지원자는 MCP의 Critical Configuration Settings의 어떤 부분이 우연히 변경되는 경우 적절한 완화방법이 구체화되는 것을 보장하는 방법을 계획하고 개발하고 문서화하고 검증해왔다.
Objective 4 - MCP_Planning_2	지원자의 소프트웨어 / AEH 계획 혹은 다른 제공가능한 문서들이 1)     MCP 리소스에 대한 경쟁의 영향을 피하거나 감소하고 소프트웨어 어플리케이션 그리고/혹은 MCP의 하드웨어 컴포넌트들로부터의 요구에 의해서 MCP의 리소스 능력을 초과하는 것을 방지하기 위해 MCP 공유 리소스가 어떻게 사용되고 지원자가 공유 리소스의 사용을 어떻게 할당하고 검증하려고 하는지에 대한 상위레벨 수준의 설명을 제공한다. 2)     활성화될 MCP 장비의 어떠한 하드웨어 동적 특성과 그들이 어떻게 사용될 지를 구분한다.   유의사항: a)     공유 리소스의 사용에 대한 설명은 공유 캐쉬 (발생할 수 있는 시간 간섭을 고려하면서) 혹은 공유 메모리(발생할 수 있는 시간 간섭과 Lockouts, Race Conditions, Data Starvation, Deadlocks 혹은 Live-locks, 과도한 데이터 대기시간과 같은 소프트웨어 실행 문제를 고려하면서)의 사용을 포함해야 한다. b)    MCP 장비의 동적 특성은 예를 들면, 절전 특성(Clock Enable/Gating, 주기 조정, 하나 혹은 그 이상의 코어를 비활성화하기, 병렬 접근의 동적 컨트롤)과 같이 실행 중에 MCP 혹은 운영되는 소프트웨어의 동작을 바꿀 수 있는 특성을 포함한다.
Objective 5 - MCP_Resource_Usage_3	지원자는 MCP 코어상에서 운영되는 소프트웨어 어플리케이션에 영향을 주는 간섭을 허용할 수 있는 인터페이스 채널을 구분해왔고 간섭을 완화하는 방안에 대한 지원자의 선택된 방안을 검증해왔다.   유의사항: a)     이 목표는 공유 메모리, 공유 캐쉬, 내부연결, 혹은 공유 I/O를 포함해서 다른 공유 리소스의 사용에 의해서 발생하는 어떠한 간섭의 구분과 지원자에 의해서 선택된 완화 방법의 검증을 포함한다. b)    만약 지원자가 의도된 최종 Configuration에서 소프트웨어 어플리케이션에 영향을 줄 수 없는 간섭 채널을 구분한다면 그러한 간섭 채널은 영향에 대해서 완화될 필요가 없고 완화에 대한 검증도 필요하지 않다. c)     지원자는 이 목표와 이들 유의사항에서와 같은 방식으로 프로젝트 과정의 어느 시점에서든 발견되는 간섭 채널을 다루어야 한다. d)    만약 MCP 하드웨어와 MCP에서 운영되는 모든 소프트웨어 어플리케이션의 가장 높은 IDAL이 IDAL C이고 운영되는 소프트웨어 어플리케이션이 안전성 분석에 의해서 강건하게 파티션될 필요가 없다면 지원자는 간섭 분석을 수행하지 않고 따라서 이 목표를 만족하지 않을 옵션을 가진다.
Objective 6 - MCP_Resource_Usage_4	지원자는 의도된 최종 Configuration에서 MCP의 가용한 리소스와 내부연결을 구분해왔고 MCP상에서 운영되는 소프트웨어 어플리케이션에 MCP의 리소스를 할당해왔으며 모든 운영되는 소프트웨어가 타겟 프로세서상에서 실행되고 있을 때 MCP의 리소스와 그 내부 연결에 대한 요구가 가용한 리소스를 초과하지 않는다는 것을 검증해왔다.   유의사항: 최악의 케이스 시나리오에 대한 필요가 이목표에 함축되어 있다.
Objective 7 - MCP_Software_1	지원자는 MCP에 의해서 운용되는 모든 소프트웨어 컴포넌트가 적용가능한 소프트웨어 지침을 준수한다는 것을 검증해왔다. 특히, 모든 운영되는 소프트웨어 컴포넌트가 올바르게 동작하고 모든 운영되는 소프트웨어가 의도된 최종 Configuration에서 실행되고 있을 때 그들의 실행을 완료할 충분한 시간을 가진다는 것을 지원자가 검증해왔다.   지원자가 이 목표에 대한 준수를 보여주는 방법은 MCP 플랫폼의 유형에 의존한다.   l  강건한 파티션을 가진 MCP 플랫폼: 그들의 MCP 플랫폼이 강건한 리소스와 시간 파티션(이 문서에서 정의한 것처럼) 둘 다를 제공한다는 것을 검증해온 지원자들은 MCP상에서 분리하여 어플리케이션들을 검증할 수 있고 그들의 WCET를 별도로 정할 수 있다.   l  다른 모든 MCP 플랫폼들: 지원자들은 간섭 분석에서 구분된 간섭이 설계에 의해서 완화되거나 배제되는 것에 대해서 소프트웨어 컴포넌트 혹은 요구사항 셋을 MCP상에서 분리해서 검증할 수 있다.   간섭이 회피되거나 완화되지 않는 소프트웨어 컴포넌트 혹은 소프트웨어 요구사항 셋은 MCP의 인터페이스에 대한 강건성 시험을 포함해서 의도된 최종 Configuration에서 실행하는 모든 소프트웨어 컴포넌트와 함께 타겟 MCP상에서 시험되어야 한다.   만약 지원자가 시간 간섭이 그 소프트웨어 컴포넌트에 대해서 완화된다는 것을 보여준다면 소프트웨어 컴포넌트의 WCET는 MCP상에서 분리되어 결정될 수 있지만, 그렇지 않다면 WCET는 분석에 의해서 결정되고 의도된 최종 Configuration에서 실행하는 모든 소프트웨어 컴포넌트와 함께 타겟 MCP에서의 시험에 의해서 확인되어야 한다.   유의사항: a)     MCP의 운영되는 소프트웨어와 하드웨어간의 모든 인터페이스가 이 시험에 포함되어야 한다. b)    위에서 언급된 강건성 시험은 표준 DO-178C 검증 활동에서 특별히 커버되지 않는 MCP상의 특정 특성을 커버하기 위한 것이다. c)     만약 MCP 하드웨어와 MCP에서 운영되는 모든 소프트웨어 어플리케이션의 가장 높은 IDAL이 IDAL C이고 운영되는 소프트웨어 어플리케이션이 안전성 분석에 의해서 강건하게 파티션될 필요가 없다면 지원자는 간섭 분석을 수행하지 않고 따라서 MCP_Resource_usage_3 목표를 만족하지 않을 옵션을 가진다. 간섭 분석이 수행되지 않는 그런 케이스에서는 운영되는 소프트웨어 컴포넌트가 어떤 간섭이 완화되지 않는지 그리고 그에 따라서 어떤 분리된 검증이 허용되지 않는지에 대해서 컴포넌트로써 이 목표에 따라서 검증되어야 한다. d)    “분리해서 검증”하는 것과 “WCET를 분리해서 결정”하는 것은 MCP의 다른 코어상에서 동시에 모든 소프트웨어를 실행하는 것 없이 이들 활동들을 수행하는 것을 의미한다.
Objective 8 - MCP_Software_2	지원자는 공유 메모리와 공유 메모리로의 접근을 컨트롤하는 메커니즘을 통한 어플리케이션간의 인터페이스를 수행하는 것을 포함해서 동일한 코어 혹은 MCP의 서로 다른 코어에서 운영되는 모든 개별적인 소프트웨어 컴포넌트들간의 Data와 Control Coupling이 소프트웨어 요구사항 기반 시험 동안에 수행되어 왔으며 그러한 Data 및 Control Coupling이 정확하다는 것을 증명해 왔다.   유의사항: 이 목표(Objective)가 소프트웨어 검증 동안에 완전하게 만족할 수 없을 때에는 지원자는 서로 다른 코어상에서 운영되는 컴포넌트들간의 Data 및 Control Coupling을 실행하기 위해 시스템 레벨 시험을 사용하는 것을 제안할 수 있다.
Objective 9 - MCP_Error_Handling_1	지원자는 MCP 내에서 일어날 수 있는 실패의 영향을 구분해 왔고, MCP가 설치된 장비내에서 발생하는 실패의 영향을 수용하는 Fail-safe 방식으로 그러한 실패들을 탐지하고 다루기 위해 그것을 사용함으로써 안전 목표에 부합하는 (MCP 외부의 ‘Safety Net’을 포함할 수 있는) 방법들을 계획하고, 설계하고, 구현하고, 검증해왔다.
Objective 1 - MCP_Accomplishment_Summary_1	그들의 SAS와 HAS에 기존 지침서에 의해서 요청된 정보가 제공되는 것에 더해서 지원자는 이 문서의 각각을 어떻게 만족하는지를 그들의 SAS, HAS 혹은 다른 전달가능한 문서에 요약해왔다.

 

이상으로 CAST-32A에 대한 해설을 모두 마친다. 처음 이 주제를 시작할 때는 단순히 CAST-32A의 내용을 해석해서 전달하는 수준으로 진행하려고 했는데 일단 CAST-32A 문서의 내용 자체가 많기도 했고 멀티코어라는 주제 자체가 생소하고 새로운 기술이다 보니 예상보다 설명할 부분이 상당히 늘어난 것 같다.

 

다시 한 번 강조하지만 여기에서 설명된 내용은 절대 정답을 제시하는 것이 아니다. 수 많은 종류의 멀티코어 프로세서와 그 보다 더 많은 수의 시스템과 프로젝트에 대해서 여기에서의 설명만으로 모두 커버할 수 있다는 것 자체가 말도 안되는 것이다. 따라서 이 부분에 대해서는 반드시 DER과의 협의를 거쳐야 하며 그러기 위해서라도 자신이 사용하고자 하는 멀티코어 프로세서에 대해서 최소한 여기서 제시된 Objective에 대해서는 검토를 해 볼 필요가 있을 것이다.