22. DO-178 인증을 위한 멀티코어 프로세서에 대한 Objective Table (해설) – CAST-32A (3)

cast-32A.pdf

사실 지금까지 앞 절에서 설명한 내용들은 다음에 제시되는 MCP에 대한 인증 목표(Objective)를 설명하기 위한 배경 설명이라고 할 수 있다. 앞서 설명한 부분들의 이해가 없이는 CAST-32A에서 제시하는 인증 목표(Objective)들을 이해하기가 쉽지 않기 때문이다. 이런 점을 상기하면서 우선 CAST-32A에서 제시하는 인증 목표(Objective) 전체를 정리한 표를 보자.

 

CAST-32A에서 제시하는 MCP에 대한 목표 (MCP Paper Objectives)
ID	내용
Objective 1 - MCP_Planning_1	The applicant’s software plans or other deliverable documents: 1)     Identify the specific MCP processor, including the unique identifier from the manufacturer, 2)     Identify the number of active cores, 3)     Identify the MCP software architecture to be used and all the software components that will be hosted on the MCP, 4)     Identify any dynamic features provided in software hosted on the MCP that will be activated and provide a high-level description of how they will be used, 5)     Identify whether or not the MCP device will be used in an IMA platform to host software applications from more than one system, 6)     Identify whether or not the MCP Platform will provide Robust Resource and / or Time Partitioning as defined in this document, 7)     Identify the methods and tools to be used to develop and verify all the individual software components hosted on the MCP so as to meet the objectives of this document and comply with the Applicable Software Guidance, including any methods or tools needed due to the use of an MCP or the selected MCP architecture.   NOTES: a)     The MCP software architecture includes AMP, SMP or any other architecture used by the applicant. b)    The software components identified should include any operating systems, hypervisors, software applications, and all functions that are provided in software. In the case of MCP used an IMA Platform, the software components that are identified do not have to include the hosted software applications. c)     The dynamic features provided in software should include such aspects as the dynamic allocation of applications to cores and any other software dynamic features that can affect the execution of the software while it is executing.
Objective 2 - MCP_Resource_Usage_1	The applicant has determined and documented the MCP configuration settings that will enable the hardware and the software hosted on the MCP to satisfy the functional, performance and timing requirements of the system.
Objective 3 - MCP_Resource_Usage_2	The applicant has planned, developed, documented, and verified a means that ensures that in the event of any of the critical configuration settings of the MCP being inadvertently altered, an appropriate means of mitigation is specified.
Objective 4 - MCP_Planning_2	The applicant’s software / AEH plans or other deliverable documents 1)     provide a high-level description of how MCP shared resources will be used and how the applicant intends to allocate and verify the use of shared resources (*) so as to avoid or mitigate the effects of contention for MCP resources and to prevent the resource capabilities of the MCP from being exceeded by the demands from the software applications and/or the hardware components of the MCP. 2)     Identify any Hardware dynamic features of the MCP device that will be active and how they will be used.   NOTES: a)     (*) The description of the use of shared resources should include any use of shared cache (taking into account the time interference it may cause) or shared memory (taking into account the time interference and the software execution problems it may cause such as lockouts, race conditions, data starvation, deadlocks or live-locks, excessive data latency). b)    Dynamic features of the MCP device include any features that can alter the behavior of the MCP or the hosted software during execution, for example, energy-saving features (clock enable/ gating, frequency adaptations, deactivating one or more cores, dynamic control of peripheral access).
Objective 5 - MCP_Resource_Usage_3	The applicant has identified the interference channels that could permit interference to affect the software applications hosted on the MCP cores, and has verified the applicant’s chosen means of mitigation of the interference.   NOTES: a)     This objective includes the identification of any interference caused by the use of shared memory, shared cache, an interconnect, or the use of any other shared resources, including shared I/O, and the verification of the means of mitigation chosen by the applicant. b)    If the applicant identifies interference channels that cannot affect the software applications in the intended final configuration , then those interference channels do not need to be mitigated and no verification of mitigation is needed. c)     The applicant should handle any interference channel discovered at any time during the project in the same manner as in this objective and these explanatory notes. d)    If the highest IDAL of the MCP hardware and of all the software applications hosted on the MCP is IDAL C and the hosted software applications are not required by the safety analysis to be robustly partitioned, then the applicant has the option to not conduct an interference analysis and therefore to not meet this objective. However, applicants should note that opting to not meet this objective affects the manner in which they are permitted to conduct their software verification. (See objective MCP_Software_1 and Note c of that objective.)
Objective 6 - MCP_Resource_Usage_4	The applicant has identified the available resources of the MCP and of its interconnect in the intended final configuration, has allocated the resources of the MCP to the software applications hosted on the MCP and has verified that the demands for the resources of the MCP and of the interconnect do not exceed the available resources when all the hosted software is executing on the target processor.   NOTES: The need to use Worst Case scenarios is implicit in this objective.
Objective 7 - MCP_Software_1	The applicant has verified that all the software components hosted by the MCP comply with the Applicable Software Guidance. In particular, the applicant has verified that all the hosted software components function correctly and have sufficient time to complete their execution when all the hosted software is executing in the intended final configuration.   The way in which the applicant should demonstrate compliance with this objective depends on the type of the MCP platform:   l  MCP Platforms With Robust Partitioning: Applicants who have verified that their MCP Platform provides both Robust Resource and Time Partitioning (as defined in this document) may verify applications separately on the MCP and determine their WCETs separately.   l  All Other MCP Platforms: Applicants may verify separately on the MCP any software component or set of requirements for which the interference identified in the interference analysis is mitigated or is precluded by design.   Software components or sets of software requirements for which interference is not avoided or mitigated should be tested on the target MCP with all software components executing in the intended final configuration, including robustness testing of the interfaces of the MCP.   The WCET of a software component may be determined separately on the MCP if the applicant shows that time interference is mitigated for that software component, otherwise, the WCET should be determined by analysis and confirmed by test on the target MCP with all software components executing in the intended final configuration.   NOTES: a)     All the interfaces between the hosted software and the hardware of the MCP should be included in this testing. b)    The robustness testing mentioned above is intended to cover the specific aspects of an MCP that are not specifically covered by standard DO-178C verification activities. c)     If the highest IDAL of the MCP hardware and of all the software applications hosted on the MCP is IDAL C and the hosted software applications are not required by the safety analysis to be robustly partitioned, then the applicant has the option to not conduct an interference analysis and therefore to not meet objective MCP_Resource_Usage_3. In such a case where no interference analysis has been performed, the hosted software components should be verified according to this objective as components for which interference is not mitigated and for which separate verification is therefore not permitted. d)    To “verify separately” and “determine the WCET separately” mean to conduct these activities without all software executing at the same time on other cores of the MCP.
Objective 8 - MCP_Software_2	The applicant has verified that the data and control coupling between all the individual software components hosted on the same core or on different cores of the MCP has been exercised during software requirement-based testing, including exercising any interfaces between the applications via shared memory and any mechanisms to control the access to shared memory, and that the data and control coupling is correct.   NOTES: When this objective cannot be completely met during the Software verification, applicants may propose to use System level testing to exercise the data and control coupling between components hosted on different cores.
Objective 9 - MCP_Error_Handling_1	The applicant has identified the effects of failures that may occur within the MCP and has planned, designed, implemented and verified means (which may include a ‘safety net’ external to the MCP) commensurate with the safety objectives, by which to detect and handle those failures in a fail-safe manner that contains the effects of any failures within the equipment in which the MCP is installed.
Objective 10 - MCP_Accomplishment_Summary_1	In addition to providing in their SAS and HAS the information requested by the existing guidance, the applicant has summarized in their SAS, HAS or other deliverable documentation how they have met each of the objectives of this document.

 

전체를 다 옮겨오기는 했지만 정말 엄청난 양이다. 그런데 우리가 DO-178 가이드라인의 부속물(ANNEX) A의 Table A-1 ~ Table A-10에서 보았던 목표(Objective)를 생각해 본다면, 그리고 SCP에 비교할 수 없을 정도의 복잡함과 안전성에 대한 민감한 부분을 생각해 본다면 위와 같은 정도의 양이 이해 못할 바는 아니라고 생각이 된다.

 

지금부터 하나하나 살펴보면서 각각이 의미하는 바와 대처 방안을 정리해 보고 모든 설명이 완료된 이후에 최종 정리하는 차원에서 위의 표를 한글로 번역해서 다시 한 번 제시할 예정이다.

 

(1)   Objective 1: MCP_Planning_1

 

맨 처음 나오는 Objective는 계획(Plan)에 대한 부분이다. DO-178 인증에 있어서 계획이 차지하는 의미와 비중에 대해서는 지금 이 글을 보는 분들이라면 잘 이해하고 있을 것이라고 생각한다. 그런데 기존의 DO-178 가이드라인에서 제시하는 계획에 대한 내용은 기본적으로 멀티코어가 아닌 싱글코어를 기준으로 한 것이다. 그 말은 기존의 가이드라인으로는 멀티코어에 대한 계획을 충분히 작성할 수 없다는 의미이다. Objective 1은 바로 그 부분을 커버하기 위한 목표이다. 이에 대해서 CAST-32A에서는 다음과 같이 설명하고 있다.

 

해석을 보자.

 

아래의 추가적인 계획 목표는 MCP를 사용한 프로젝트에 대해서 계획 데이터 표준을 달성할 적용가능한 계획에 있어서 필요로 하는 정보를 분명하게 한다.

 

여기서 계획이라고 하는 것은 DO-178 인증에 필요한 계획 문서 전체가 대상이 될 수 있다. 즉, PSAC, SDP, SVP 등의 문서들에 관련된 내용이 작성되는 것이다. 이러한 내용을 배경으로 Objective 1은 아래와 같이 설명하고 있다. (첫 번째 Objective는 내용이 많아서 설명에 대한 원문은 생략하고 해석을 바로 정리했다)

 

1)     제조사로부터의 유일한 구분자를 포함하는 특정한 MCP 프로세서의 구분

2)     활성화되는 코어의 개수

3)     사용되는 MCP 소프트웨어 아키텍처와 MCP에서 운영될 모든 소프트웨어 컴포넌트

4)     MCP상에서 운영되는 소프트웨어에서 제공되는 것들 중에 활성화될 동적 특성들을 구분하고 그것들이 어떻게 사용될 지에 대한 상위레벨 설명을 제공

5)     MCP 장비가 하나 이상의 시스템으로부터 소프트웨어 어플리케이션을 운영할 IMA 플랫폼에서 사용될 것인지를 구분

6)     MCP 플랫폼이 이 문서에 정의된 것처럼 강건한 리소스 파티셔닝 그리고/혹은 강건한 시간 파티셔닝을 제공할 것인지를 구분

7)     MCP 혹은 선택된 MCP 아키텍처의 사용 때문에 필요로 하는 어떤 방법 혹은 툴을 포함해서 이 문서의 목표(Objective)를 만족하기 위해 MCP 상에서 운영되는 모든 개별적인 소프트웨어 컴포넌트들을 개발하고 검증하기위해 사용되는 방법들과 툴을 구분

 

Objective 1에는 위의 내용과 함께 아래와 같은 유의사항(Notes)도 함께 제시하고 있다. 유의사항은 일종의 추가 정보를 제공하는 것인데 사실상 Objective와 같은 수준으로 고려되어야 한다.

 

a)     MCP 소프트웨어 아키텍처는 AMP, SMP 혹은 지원자에 의해서 사용되는 다른 아키텍처를 포함한다.

b)    구분되는 소프트웨어 컴포넌트에는 운영 시스템, 하이퍼바이저, 소프트웨어 어플리케이션, 그리고 소프트웨어에서 제공되는 모든 기능들이 포함되어야 한다. IMA 플랫폼을 사용하는 MCP의 경우에는 구분되는 소프트웨어 컴포넌트가 운영되는 소프트웨어 어플리케이션을 포함해야 하는 것은 아니다.

c)     소프트웨어에서 제공되는 동적 특성은 코어로의 어플리케이션 동적 할당과 실행하는 동안에 소프트웨어 실행에 영향을 줄 수 있는 소프트웨어의 다른 동적 특성을 포함해야 한다.

 

참고) 위의 설명 중에 여기서의 설명만으로는 잘 이해가 안되는 부분들이 있을 것 같다. 이는 필자의 미력한 번역 실력과 지식의 부족도 영향이 있을 것이다. 하지만 기본적으로 여기에서의 내용이 절대 간단하고 이해하기 쉬운 내용들이 아니다. 또한 CAST-32A에 포함되어 있는 용어 설명과 같은 추가적인 내용들도 함께 봐야 보다 확실한 이해를 할 수 있다. 예를 들면 AMP, SMP에 대해서 CAST-32A에서는 아래와 같이 별도의 용어 설명을 덧붙이고 있다.   -       Asymmetric Multi-processing (AMP): an MCP software architecture in which each individual functional process is permanently allocated to a separate core and each core has its own operating system (however, the operating systems may be multiple copies of the same operating system or be different from core to core). -       Symmetric Multi-processing (SMP): an MCP software architecture in which a single operating system controls the execution of the processes on all the cores and may dynamically allocate sections of processes to run in parallel on separate cores.   필자가 이러한 용어 설명도 포함해서 각각의 항목 자체를 또 다시 추가로 설명할 수도 있겠지만 일단 여기에서는 그런 수준까지는 정리하지 않았다. 필자가 잘 모르는 내용이기도 하려니와 내용이 너무 방대해지는 면도 있고 여기서 추가로 필요한 부분은 독자들의 탐구영역(?)으로 남겨두는 것도 의미가 있을 것 같기 때문이다. 추후 필요하다고 판단이 되면 그런 부분들을 별도의 절로 구분해서 추가할 예정이다.

 

위의 내용을 하나로 요약하자면 결국 실제 사용할 MCP에 대한 정확한 정보를 확인하는 것이라고 할 수 있다. 앞서 MCP의 복잡함과 안전성에 대한 이슈를 많이 언급하긴 했지만 그 모든 것들이 자신이 사용하고자 하는 MCP 혹은 플랫폼에 무조건 해당하는 것이 아니다. 따라서 무엇이 해당하고 무엇이 해당하지 않는지를 정확하게 구분하고 실제로 필요한 활동만을 수행하기 위해서 위의 내용들이 정확하게 파악되어야 한다.

 

위의 설명 하나하나가 어렵고 이해가 잘 안되는 부분이 있겠지만 기본적으로 이런 배경을 염두에 두고 실전에서는 제대로 파악되는 내용부터 하나하나 계획문서를 작성하도록 하자. 그 과정에서 가능하다면 DER의 도움을 받는 것도 추천하는 부분이다.

 

(2)   Objective 2: MCP_Resource_Usage_1

 

Objective 1이 계획에 대한 내용을 일반적인 형태로 작성하는 것을 설명하는 것이라면 Objective 2는 그것을 좀 더 구체적으로 작성하는 것에 대한 내용이다. 특히 MCP에 포함되어 있는 다양한 리소스들의 사용여부에 초점을 맞추어 설명하고 있다. 그러한 항목으로 다음과 같은 것들을 들 수 있다.

 

-       어떤 코어들이 활성화되는지

-       코어의 실행 주기는 어떻게 되는지

-       MCP의 주변 장비 중 어떤 것들이 활성화되는지

-       공유 메모리 혹은 공유 캐쉬가 사용되는지 그리고 어떻게 할당되는지

-       MCP에 내장된 동적 특성들이 코어의 실행 주기를 바꿀 수 있는지 혹은 에너지를 줄이기 위해 코어를 비활성화할 수 있는지 (안전 필수 어플리케이션에는 추천되지 않음)

 

CAST-32A 문서에서는 위와 같은 옵션을 MCP의 “Configuration Settings”라고 칭하고 다음과 같이 핀, 레지스터 설정의 예를 들면서 상당히 구체적으로 설명하고 있기도 하다.

 

해석을 보자.

 

이들 옵션들은 MCP의 “Configuration Settings”으로 알려져 있고 MCP의 특정 핀을 특별한 전압에 연결하거나 수행되는 소프트웨어가 소프트웨어의 시작 시점에 특정 레지스터에 값을 쓰도록 만듦으로써 설정될 수 있다.

 

이러한 셋팅과 관련해서 인증당국(CA)에서 우려하는 부분 중에는 특히 “최악 실행 시간”이라고 하는 “WCET(Worst-Case Execution Times)”가 있다. WCET에 대해서 위키피디아에서는 다음과 같이 정의하고 있다.

 

From Wikipedia, the free encyclopedia   The worst-case execution time (WCET) of a computational task is the maximum length of time the task could take to execute on a specific hardware platform.

 

해석을 보자.

 

계산과 관련된 태스크의 최악 실행 시간(WCET)은 특정 하드웨어 플랫폼상에서 수행하기 위해 태스크가 가질 수 있는 시간의 최대 길이이다.

 

간단하게 말하자면 소프트웨어가 자신이 수행해야 할 동작을 정상적으로 완료하기 위해 가질 수 있는 최대의 시간을 의미한다. 컴퓨터가 하나의 동작을 완료하기 위해서 무한정 기다릴 수 없다는 점에서 소프트웨어의 정상적인 동작과 성능을 결정하는 핵심 요인이 된다.

 

이것을 MCP로 적용해 보면 동시에 여러 개의 소프트웨어(혹은 모듈)가 실행되는 경우 만약 공유리소스의 사용때문에 다른 소프트웨어가 기다려야 하는 상황이라면 기다리는 소프트웨어의 WCET가 반드시 지켜져야 한다는 것이다. 만약 WCET가 지켜지지 않으면 결국 그 소프트웨어는 정상적인 동작을 완료하지 못한다는 의미가 되므로 이는 시스템의 잘못된 동작으로 연결되어 최종적으로는 항공기의 안전에 심각한 영향을 미칠 수도 있게 된다. 인증당국에서는 바로 이 점을 주목하는 것이다. 아래는 그것에 대한 설명이다.

 

해석을 보자.

 

공유 메모리를 사용하는 것은 메모리 접근 시간이 증가할 수 있고 공유 캐쉬를 사용하는 것은 만약 하나의 어플리케이션이 다른 것들의 공유 캐쉬를 접근하는 것을 막게 되면 반복적으로 캐쉬를 놓치게 만들 수 있다. 이러한 영향은 운영되는 어플리케이션의 최악 실행 시간(WCETs)의 증가를 가져올 수 있다. 인증당국은 WCET에서의 그러한 증가가 어떤 어플리케이션이 그들의 안전 필수 기능의 수행을 완료하기에 충분한 시간을 가지는 것을 막을 수 있다는 점을 우려한다.

 

이외에도 여러가지 유사한, 혹은 관련된 문제들이 생길 수 있기 때문에 각각에 대한 대비가 될 수 있어야 하며 그것이 계획 단계에서 충분히 검토되고 준비되어야 한다. 그에 대해서는 아래와 같이 설명하고 있다. 

 

해석을 보자.

 

계획 단계에서 지원자가 위에서 설명한 것처럼 이러한 리소스에 대한 경쟁을 피하거나 결과로 나타날 수 있는 문제를 완화하기 위해 어떤 공유 리소스를 사용하려고 하는지, 그리고 지원자가 그러한 리소스를 어떻게 할당하려고 하는지, 할당된 것에 대한 사용을 어떻게 검증할지를 구분하는 것이 중요하다.

 

이 부분에서 Objective 3개를 한꺼번에 제시하고 있어서 그에 대한 배경설명이 좀 길었다. 이제 이어지는 Objective 3가지를 하나씩 살펴보자. 아래는 Objective 2에 대한 내용이다.

 

해석을 보자.

 

MCP_Resource_Usage_1: 지원자는 시스템의 기능, 성능 그리고 타이밍 요구사항을 만족하기 위해 MCP상에서 운영되는 하드웨어와 소프트웨어를 실행 가능하게 할 MCP Configuration Settings을 정하고 문서화해왔다.

 

앞에서 설명한 “Configuration Settings”가 나오고 기능, 성능에 대한 요구사항과 함께 타이밍에 대한 요구사항도 설명되고 있다. 결국 Objective 2는 이 Configuration Settings를 결정하라는 것이다. 혹시 무슨 말인지 이해가 되지 않는다면 앞에서 설명한 배경 부분을 다시 한 번 확인해 보기 바란다.

 

이어서 Objective 3으로 바로 넘어가 보자.

 

(3)   Objective 3: MCP_Resource_Usage_2

 

해석을 보자.

 

MCP_Resource_Usage_2: 지원자는 MCP의 Critical Configuration Settings의 어떤 부분이 우연히 변경되는 경우 적절한 완화방법이 구체화되는 것을 보장하는 방법을 계획하고 개발하고 문서화하고 검증해왔다.

 

Objective 2가 Configuration Settings를 정의하는 것이라면 Objective 3는 그렇게 정의된 Configuration Settings가 변경되는 경우에 대한 대처 방안이 준비되어 있어야 한다는 의미이다. 구체적인 방법론으로 보자면 상당히 어려운 문제여서 그런 부분까지 여기에 모두 설명하기는 역부족이고 어쨌든 MCP에 대해서는 이런 수준으로까지도 요구한다는 것을 이해하자.

 

(4)   Objective 4: MCP_Planning_2

 

Objective 4는 어떤 면에서 보면 Objective 1과 유사하다고도 생각할 수 있는데 여기서 초점은 “Configuration Settings”이다. 소프트웨어뿐만 아니라 하드웨어까지 고려한 Configuration Settings가 정의되는 것이므로 Configuration Settings에 기반한 계획을 좀 더 구체적으로 작성하는 것이라고 할 수 있다. CAST-32A에서는 이에 대해서 아래와 같이 설명하고 있다.

 

해석을 보자.

 

MCP_Planning_2: 지원자의 소프트웨어 / AEH(참고: Airborne Electronic Hardware)계획 혹은 다른 제공가능한 문서들이 1)     MCP 리소스에 대한 경쟁의 영향을 피하거나 감소하고 소프트웨어 어플리케이션 그리고/혹은 MCP의 하드웨어 컴포넌트들로부터의 요구에 의해서 MCP의 리소스 능력을 초과하는 것을 방지하기 위해 MCP 공유 리소스가 어떻게 사용되고 지원자가 공유 리소스의 사용을 어떻게 할당하고 검증하려고 하는지에 대한 상위레벨 수준의 설명을 제공한다. 2)     활성화될 MCP 장비의 어떠한 하드웨어 동적 특성과 그들이 어떻게 사용될 지를 구분한다.

 

세부 내용의 작성에 있어서는 당연히 기술적인 내용이 많이 포함될 텐데 이러한 배경을 가지고 작성해야 한다. 여기에 다음과 같은 유의사항(Notes)이 추가로 설명되고 있다.

 

공유 캐쉬, 공유 메모리, 절전과 관련된 내용이 보인다. 관련된 계획을 세우는데 있어서 놓치지 않고 확인해야 할 부분들을 설명하고 있다. 전체 해석은 생략한다.

 

(5)   Objective 5: MCP_Resource_Usage_3

 

앞서 보았던 Objective에서는 MCP에서 사용하는 소프트웨어 혹은 하드웨어의 직접적인 기능에 초점이 맞추어 졌다면 Objective 5는 간접적인 대상이라고 할 수 있는 “Interference Channel(간섭 채널)”에 초점을 맞추고 있다.

 

CAST-32A에서는 간섭 채널(Interference Channel)을 다음과 같이 설명하고 있다.

 

해석을 보자.

 

위에서 언급한 것처럼, 멀티 코어 프로세서의 서로 다른 코어상에서 실행하는 어플리케이션들은 MCP 리소스를 공유하고 따라서 이들 어플리케이션들 간에 명백한 데이터 혹은 컨트롤 플로우가 없다고 하더라도 그것이 어플리케이션 간에 간섭을 일으킬 수 있다. 독립된 어플리케이션간에 간섭을 일으킬 수 있는 플랫폼 특성을 간섭채널이라고 부른다.

 

위의 설명만으로 보자면 MCP를 사용하게 되면 필연적으로 “간섭”이 일어난다고 설명하고 있다. 그리고 그 간섭은 MCP상에서 동작하는 소프트웨어의 안전성에 영향을 주게 된다. 따라서 인증당국에서는 그 간섭의 대상이 되는 간섭 채널과 그 영향, 그리고 그 영향에 대한 대처 방법에 대해서도 관심을 가질 것을 요구하는 것이다.

 

이어지는 설명에서는 좀 더 기술적인 상세한 설명이 이어진다. 자세한 내용은 CAST-32A 문서를 직접 참조하자.

 

참고) 필자는 MCP 전문가도 아니고 사실 기술적인 지식이 풍부한 것도 아니어서 여기서 설명하는 내용에 대해서 보다 자세한 설명이나 결론을 제시하지는 못하는 입장이라고 할 수 있다. 하지만 CAST-32A에서 설명하는 내용이나 수준은 기술적인 면으로 깊게 들어가서 설명하는 것이라기 보다는 진행 방향이나 전략을 세우는 데 도움을 주기 위한 일반적인 내용들이라고 판단하고 있다. 그런 점에서 필자의 해석이나 설명이 어느 정도는 도움이 될 것이라고 믿고 있다.   그럼에도 필자의 설명이 부족하다고 생각되는 분들은 다른 전문가의 도움을 받을 필요가 있으며 특히 함께 진행하고 있는 DER이 있다면 ‘반드시’ DER을 통해서 관련 내용을 협의하고 도움을 요청하도록 하자.

 

다음은 이에 대한 Objective이다.

 

해석을 보자.

 

MCP_Resource_Usage_3: 지원자는 MCP 코어상에서 운영되는 소프트웨어 어플리케이션에 영향을 주는 간섭을 허용할 수 있는 인터페이스 채널을 구분해왔고 간섭을 완화하는 방안에 대한 지원자의 선택된 방안을 검증해왔다.

 

여기에도 좀 더 기술적인 내용에 기반한 유의사항(Notes)이 설명되어 있다. 이 부분 역시 실제 진행과정에서 지원자가 꼼꼼히 챙겨야 할 부분이다. 참고로 유의사항에는 이 Objective를 만족하지 않아도 되는 경우에 대해서 설명하는 부분이 있다. 예를 들면 아래와 같다.

 

해석을 보자.

 

b) 만약 지원자가 의도된 최종 Configuration에서 소프트웨어 어플리케이션에 영향을 줄 수 없는 간섭 채널을 구분한다면 그러한 간섭 채널은 영향에 대해서 완화될 필요가 없고 완화에 대한 검증도 필요하지 않다.

 

설명 자체는 충분히 이해가 될 만하지만 현실적으로 영향을 주지 않는다는 것을 증명하는 것이 그렇게 간단한 문제는 아닐 것이다. 어쨌든 이렇게 예외가 될 수 있는 부분이 있다는 점을 알고 있는 것이 중요하다. Objective 하나를 만족하기 위해서 투입해야 할 리소스가 결코 적지 않다는 점을 고려한다면 Objective를 생략할 수 있다는 것은 Objective를 준수하는 것만큼이나 중요한 부분이라고 할 수 있다. 이러한 예외 처리 부분을 포함해서 유의사항을 잘 살펴보도록 하자.

 

(6)   Objective 6: MCP_Resource_Usage_4

 

곧바로 이어서 Objective 6이 나오고 있다.

 

해석을 보자.

 

MCP_Resource_Usage_4: 지원자는 의도된 최종 Configuration에서 MCP의 가용한 리소스와 내부연결을 구분해왔고 MCP상에서 운영되는 소프트웨어 어플리케이션에 MCP의 리소스를 할당해왔으며 모든 운영되는 소프트웨어가 타겟 프로세서상에서 실행되고 있을 때 MCP의 리소스와 그 내부 연결에 대한 요구가 가용한 리소스를 초과하지 않는다는 것을 검증해왔다.   유의사항: 최악의 케이스 시나리오에 대한 필요가 이 목표에 함축되어 있다.

 

필자가 판단하기로는 Objective 6은 지금까지 제시된 내용들을 종합적으로 취합한 것으로 이해가 된다. 그런 의미에서 본다면 앞에서 제시된 Objective 1 ~ 5를 모두 만족하게 되면 Objective 6도 자연스럽게 만족하는 것이라고 할 수 있다. 마지막에 제시된 유의사항(Note)에서 이 목표에 대한 검증에는 최악의 상황을 가정한 시나리오가 고려된다는 점도 기억할 부분이다.

 

(7)   Objective 7: MCP_Software_1

 

지금까지 제시된 Objective들이 일종의 기준을 제시하는 것이라면 Objective 7은 그 기준에 따른 검증을 어떻게 하느냐에 초점을 맞추고 있다.

 

DO-178 가이드라인이 싱글코어 프로세서에서 운영되는 소프트웨어를 기준으로 작성되었다는 점은 이미 언급한 바가 있다. 이것은 DO-178에서 가이드하는 검증에 대한 부분 역시 같은 상황이라는 것을 의미한다. 따라서 DO-178 가이드라인 기준으로는 멀티코어 프로세서에 대한 검증을 커버할 수 없다. 이러한 이유로 CAST-32A에서는 MCP에 대한 검증 방법에 대해서 다음과 같이 설명하고 있다.

 

해석을 보자.

 

따라서 기존의 소프트웨어 지침에서의 소프트웨어 검증 프로세스는 운영되는 어플리케이션이 올바르게 기능을 수행하고 모든 운영되는 소프트웨어가 MCP상에서 실행될 때 발생하는 간섭이 존재하는 가운데에서도 실행하기 위한 충분한 시간을 가지는 것을 증명하기 위해 MCP 상에서의 사용에 대해서 적절하게 변경할 필요가 있다.

 

결국 현재 DO-178 가이드라인이 제시하는 검증방법을 MCP에 맞도록 수정해서 사용하라는 말이다.

 

참고) 위의 설명은 어떻게 보면 당연한 말을 하는 것일 수도 있다. 하지만 여기서 중요한 점은 그 당연한 말을 공식적으로 확인받는다는 점이다. 만약 이러한 공식적인 언급이 없다면 누군가는 MCP에 대해서도 기존의 DO-178 가이드라인에서 제시하는 검증방법을 그대로 따라야 한다고 주장할 수도 있는 것이다.   이렇게 ‘수정해서 사용’하라고 공식적으로 언급해 주는 것은 반대로 보면 MCP의 검증에 대해서는 소위 검증 방법에 대한 ‘커스터마이징’이 반드시 필요하다는 것을 명확하게 하고 있는 것이라고 할 수 있다.

 

그렇다면 어떤 방법이 있을까? CAST-32A에서는 이에 대해서 길게 설명하고 있는데 요약하자면 각각의 코어를 완벽하게 분리해서 시험하는 것이다. 아래는 그것을 설명하는 부분이다.

 

해석을 보자.

 

어플리케이션의 독립된 검증은 (즉, 동시에 실행하는 다른 코어상에서의 다른 어떤 어플리케이션도 없이) MCP상에서 운영되는 어플리케이션과 다른 모든 어플리케이션간의 간섭이 감소된다는 것을 지원자가 증명할 수 있다면 특정 조건하에서 유효할 수 있다.

 

그리고 아래의 설명에서는 보다 구체적으로 파티션에 대한 내용이 나온다.

 

전체 해석은 생략하고 위에서 붉은색으로 표시된 부분만 보자면 한마디로 “강력한 파티션을 보유한 MCP 플랫폼”정도로 해석할 수 있다. MCP가 이런 강력한 파티션을 보유한 플랫폼이라는 것을 보여줄 수 있는 경우에만 (혹은 간섭을 피하거나 완화한다는 것을 증명할 수 있을 경우) 독립된 검증을 수행할 수 있다는 것을 설명하고 있다.

 

독립된 검증과 함께 검증과 관련해서 추가로 설명하는 부분은 바로 Data Coupling과 Control Coupling이다. 사실 이 두 가지는 MCP라고 하더라도 기존 DO-178 가이드라인에서 요구하는 Data Coupling과 Control Coupling에 대한 다음과 같은 Objective 자체만 본다면 동일하게 적용할 수 있는 부분이다.

 

 

즉, 싱글코어가 되었든 멀티코어가 되었든 그 안에서 실행되는 소프트웨어가 DO-178 인증을 받기 위해서는 Data Coupling과 Control Coupling에 대한 커버리지를 만족해야 하는 것이다. 다만 멀티코어인 경우에는 싱글코어인 경우에 수행하는 것과 비교해서 고려해야 할 부분에서 차이점이 있다. CAST-32A에서는 다음과 같이 설명한다.

 

해석을 보자.

 

적용가능한 소프트웨어 지침이 싱글코어 프로세서를 기술하도록 작성되었기 때문에 그 지침에서 Data와 Control Coupling 목표는 싱글 코어 프로세서상에서 운영되는 소프트웨어 컴포넌트간에만 적용한다. MCP의 사용으로 MCP의 서로 다른 코어상에서 운영되는 소프트웨어 컴포넌트간에 Data와 Control 흐름이 있을 수 있어서 Data 및 Control Coupling 분석은 그러한 코어를 교차하는 Data와 Control 흐름을 커버하도록 확장되어야 한다.

 

Data Coupling과 Control Coupling을 지원하는 툴이 몇 가지 있다. 하지만 이러한 형태로 MCP를 지원하는 커버리지 분석도구가 있는지는 필자가 아직까지는 알지 못한다. 추후 확인되는 부분이 있으면 이곳에 업데이트해서 공유하도록 하겠다.

 

이제 Objective 7을 직접 확인하기 전에 마지막으로 위에서 설명한 “MCP 플랫폼”에 대한 부분을 알아보자. CAST-32A에서는 다음과 같은 두 가지 종류를 들고 있다.

 

막상 구분해 놓은 것을 보면 좀 당황스럽게 느껴지는 것이 일단 앞서 언급한 “강력한 파티션을 보유한 MCP 플랫폼”은 구체적으로 제시하면서 다른 종류의 플랫폼에 대해서는 “그 외” 정도로 뭉뚱그려서 설명하고 있기 때문이다. 기술적인 부분을 잘 몰라서 원래 이렇게 밖에 표현할 수 없나 싶기도 한데 어쨌든 MCP 플랫폼에 대해서는 위와 같이 구분을 하고 Objective에 대한 설명에서는 각각의 플랫폼에 따라서 구분해서 설명하고 있다.

 

배경설명이 길었다. 이제 Objective 7을 확인해 보자.

 

해석을 보자.

 

MCP_Software_1: 지원자는 MCP에 의해서 운용되는 모든 소프트웨어 컴포넌트가 적용가능한 소프트웨어 지침을 준수한다는 것을 검증해왔다. 특히, 모든 운영되는 소프트웨어 컴포넌트가 올바르게 동작하고 모든 운영되는 소프트웨어가 의도된 최종 Configuration에서 실행되고 있을 때 그들의 실행을 완료할 충분한 시간을 가진다는 것을 지원자가 검증해왔다.

 

위의 설명은 결국 멀티코어상에서 실행되는 모든 소프트웨어가 주어진 시간 내에 정상적으로 동작한다는 것을 검증하라는 말이다. 그리고 그 증명은 앞서 설명한 독립된 검증, Data 및 Control Coupling (Flow) 그리고 MCP 플랫폼을 고려하여 수행하게 되는 것이다.

 

CAST-32A에서는 기본적으로 “강력한 파티션”을 지원하는 MCP 플랫폼이라면 독립된 시험이 가능하다고 설명하고 있다. 아래는 그에 대한 설명이다.

 

해석을 보자.

 

•           강건한 파티션을 가진 MCP 플랫폼: 그들의 MCP 플랫폼이 강건한 리소스와 시간 파티션 (이 문서에서 정의한 것처럼) 둘 다를 제공한다는 것을 검증해온 지원자들은 MCP 상에서 분리하여 어플리케이션들을 검증할 수 있고 그들의 WCET를 별도로 정할 수 있다.

 

이는 앞서 예를 들었던 VxWorks 653 OS와 같이 파티션을 제공하는 환경에서는 각각의 분리된 공간에서 각각의 어플리케이션들을 독립적으로 검증할 수 있다는 것을 알 수 있다. 이와는 달리 “그 외”의 MCP 플랫폼에 대해서는 어려운 설명들이 나온다. 내용이 많아서 원문을 가져오는 대신 필자가 이해한 수준으로 간략하게 정리해 보면 다음과 같다.

 

①    설계를 통해서 분리된 검증이 가능하다는 것을 보여주기

②    간섭을 피하거나 감소시킬 수 없다면 무식하게(?) 타겟에서 모든 시험을 다 수행하기

 

어렵고 복잡하게 설명되어 있지만 필자가 판단하기에는 결국 위의 두 가지 방안을 제시하고 있다. 만약 위와 같은 방법을 사용한다면, 그리고 그것이 가능하다면 결국은 어떠한 MCP 플랫폼에 대해서도 시험이 가능할 것이다. 물론 절대 쉽지 않으며 현실적으로 가능한 방법인지 의문이 드는 것이 사실이다.

 

보다 자세한, 정확한 내용과 추가로 제시되고 있는 유의사항(Notes)은 CAST-32A 문서를 직접 참고하도록 하고 다음 Objective로 넘어가자.

 

(8)   Objective 8: MCP_Software_2

 

Objective 8은 Data Coupling과 Control Coupling에 대한 내용이다.

 

해석을 보자.

 

MCP_Software_2: 지원자는 공유 메모리와 공유 메모리로의 접근을 컨트롤하는 메커니즘을 통한 어플리케이션간의 인터페이스를 수행하는 것을 포함해서 동일한 코어 혹은 MCP의 서로 다른 코어에서 운영되는 모든 개별적인 소프트웨어 컴포넌트들간의 Data와 Control Coupling이 소프트웨어 요구사항 기반 시험 동안에 수행되어 왔으며 그러한 Data 및 Control Coupling이 정확하다는 것을 증명해 왔다.   유의사항: 이 목표(Objective)가 소프트웨어 검증 동안에 완전하게 만족할 수 없을 때에는 지원자는 서로 다른 코어상에서 운영되는 컴포넌트들간의 Data 및 Control Coupling을 실행하기 위해 시스템 레벨 시험을 사용하는 것을 제안할 수 있다.

 

여기서 중요한 점은 “요구사항 기반 시험”을 통해서 Data Coupling과 Control Coupling을 수행한다는 부분이다. 이 부분은 DO-178 가이드라인에서 설명하는 검증에 있어서 가장 기본이 되는 시험방법이다. MCP 역시 동일하게 적용된다는 것을 알 수 있다. 앞에서 잠시 언급한 것처럼 멀티코어를 기반으로 한 Data Coupling과 Control Coupling을 지원하는 툴이나 관련된 정보가 추가로 확인되면 이곳에 업데이트 할 예정이다.

 

(9)   Objective 9: MCP_Error_Handling_1

 

Objective 9는 한마디로 MCP에 대한 에러를 어떻게 탐지하고 처리할 것이냐에 대한 내용이다. 지금까지 우리가 살펴본 MCP의 특성들을 고려한다면 MCP에서 발생하는 문제점이 훨씬 더 심각하고 난해하다는 것은 충분히 짐작할 수 있을 것이다. CAST-32A에서는 이에 대한 처리를 위해서 “Safety Net”이라는 개념을 제시하고 있다.

 

해석을 보자.

 

따라서 지원자는 MCP 내에서의 실패를 탐지하고 다루기 위해, 그리고 MCP가 설치된 장비내에서 그런 실패들을 수용하도록 하기 위해 MCP 외부에 “Safety Net”의 사용을 고려하기를 원할 수 있다.

 

MCP에서의 에러를 탐지하고 컨트롤 하기 위해서 “Safety Net”이라고 부르는 외부 안전장치(혹은 소프트웨어)를 둘 수도 있다는 것으로 이해되는 내용이다. “Safety Net”에 대한 추가적인 설명이 없어서 기술적인 부분을 포함해서 정확한 내용을 알지는 못하지만 무엇을 말하는 것인지는 짐작을 할 수 있을 것이다. 이것을 배경으로 다음과 같은 Objective를 제시하고 있다.

 

해석을 보자.

 

MCP_Error_Handling_1: 지원자는 MCP 내에서 일어날 수 있는 실패의 영향을 구분해 왔고, MCP가 설치된 장비내에서 발생하는 실패의 영향을 수용하는 Fail-safe 방식으로 그러한 실패들을 탐지하고 다루기 위해 그것을 사용함으로써 안전 목표에 부합하는 (MCP 외부의 ‘Safety Net’을 포함할 수 있는) 방법들을 계획하고, 설계하고, 구현하고 검증해왔다.

 

필자가 판단하기로는 위의 설명의 요지는 결국 외부의 모니터링 모듈을 두고 그것을 통해서 MCP에서 발생하는 문제점을 탐지하고 대처할 수 있어야 한다는 것이 아닌가 싶다. 사실 이는 싱글코어에도 동일하게 적용될 수 있는 중요한 목표(Objective)라고 할 수 있다. 실제 이를 구현하는 기술적인 부분에 있어서는 결코 쉽지 않겠지만 그 배경에 대한 부분은 이 정도의 수준으로 이해하고 넘어가자.

 

(10)  Objective 10: MCP_Accomplishment_Summary_1

 

이제 마지막 Objective이다. 마지막 Objective는 DO-178 가이드라인에서 제시하는 SAS(Software Accomplishment Summary)의 작성에 대한 부분이다. HAS(Hardware Accomplishment Summary)도 포함해서 설명하고 있다. 설명자체는 간단하다. 기존 DO-178 혹은 DO-254 가이드라인에서 설명하고 있는 SAS, HAS는 싱글코어를 기준으로 작성되었으므로 멀티코어에 대한 기준으로 작성하는 방법이 새롭게 제시되어야 한다는 뜻이다. 이를 배경으로 다음과 같은 Objective를 제시하고 있다.

 

해석을 보자.

 

MCP_Accomplishment_Summary_1: 그들의 SAS와 HAS에 기존 지침서에 의해서 요청된 정보가 제공되는 것에 더해서 지원자는 이 문서의 목표들 각각을 어떻게 만족하는지를 그들의 SAS, HAS 혹은 다른 전달가능한 문서에 요약해왔다.

 

결국 앞에서 제시되었던 9가지의 Objective를 어떻게 달성하는지를 최종적으로 정리해서 인증당국에 공식적으로 제출할 수 있어야 한다는 것을 알 수 있다.

 

지금까지 MCP에 대해서 인증당국이 요구하는 총 10개의 Objective를 살펴보았다. MCP 자체가 최신 기술이고 어려운 내용인데다가 기존 가이드라인이 커버하지 못하는 내용이다 보니 설명 하나하나가 길어지면서 전체 내용도 상당히 많아지게 되었다. 최대한 필자가 이해하는 선에서 쉽게 이해할 수 있도록 정리하려고 했지만 부족한 부분이 있을 것이다. 다시 한 번 말하지만 이 부분에 대해서는 컨택이 가능한 DER이 있다면 DER에게 현재 상황을 충분히 공유하고 대응 방안에 대해서 심도있는 협의를 하는 것이 중요하다. 그것이 MCP를 사용하면서도 DO-178 인증을 받을 수 있는 가장 빠르고 정확한 방법이 될 것이다. 그 과정에서 여기에 설명된 부분이 조금이라도 도움이 되었으면 하는 바램이다.

 

다음 절에서는 지금까지 설명된 내용을 기반으로 처음에 보았던 영어로 작성된 총 10개의 Objective 테이블을 한글로 번역한 테이블을 보여주는 것으로 CAST-32A에 대한 설명을 마무리하고자 한다. 그 전에 10개의 Objective에 대해서 소프트웨어 레벨(DAL A, B, C)에 따라서 적용여부를 구분하고 있는 테이블을 보면서 이번 절을 마친다.

 

MCP PAPER OBJECTIVES	DAL A Or B	DAL C
MCP_Planning _1	Yes	Yes
MCP_Resource_Usage _1	Yes	Yes
MCP_Resource_Usage _2	Yes	No
MCP_Planning _2	Yes	Yes
MCP_Resource_Usage _3	Yes	No See note d)
MCP_Resource_Usage _4	Yes	No
MCP_Software _1	Yes	Yes
MCP_Software _2	Yes	Yes
MCP_Error_Handling _1	Yes	No
MCP_Accomplishment_Summary_1	Yes	Yes

 

※ 참고로 위의 소프트웨어 레벨은 시스템 관점에서 결정되는 IDAL(Item Design Assurance Level)이 가장 높은 레벨(A)인 경우를 기준으로 하는 것이다. 일단 DAL을 기준으로 판단하고 IDAL에 대한 부분은 추후 DER과 함께 확인해 볼 것을 추천한다.

※ 위의 표에 나오는 note d)의 내용은 다음 절에서 참조하자.