How to Build a mixed criticality in industry

abstract) 여러 하드웨어들이 공유되는 플랫폼 환경에서 서로 다른 criticality를 고려하는 연구는 실용적인 영역과 학문적인 영역에서 많은 관심을 받아왔다.
학문적인 영역에서 수천의 모델이 연구되었음에도 불구하고 이것이 학문과 산업간의 간극(mismatch)에 의해 실제 환경에서 적용되기 어렵다. 이 연구에서는 이런 간극을 시스템 구조의 관점에서 분석하고 작은 해결책도 제안하려 함.

Introduction
MCS(mixed criticality system)

MCS 에 대한 관심사는 학문적인 영역과 실생활에서 모두 주목ㅂ받고 있으나 MCS를 실제적으로 구축하려 할 때 생기는 딜레마들이 있다. 대표적으로 시스템 모델의 최적화, task allocation 의 효과성, resource management 등등

그리고 이런 MCS의 현실과 연구 영역에서의 간극은 MCS의 발전을 더디게 하고 있다. 특히 몇몇 간극들은 연구자들과 엔지니어 사이에서도 발견된다. 예를 들면 'criticality'를 정의하는 방식도 다르다. 본 연구는 이런 MCS를 발견하여 조기에 이런 간극들로 인해 문제가 생기는 걸 방지하고 해결책을 논의하기 위해 시스템 구조에 대한 관점에서 MCS를 관찰함.

1) system architecture in MCS
실시간 컴퓨팅 세계에서 시스템구조의 중요성에도 불과하고 기존의 MCS (연구)분야에서는 system architecture는 큰 쟁점사항이 아니였다. 그래서 우리의 연구가 보다 의미있을 것이다.

특히 학문적인 영역에서 얼마나 복잡한 모델이 만들어졌는지와 상관없이 일관되게 모든 연구활동을 결국 '실제'세상에도 적용가능한 MCS여야된다는 것이다. 그리고 이 첫번째 단계는 시스템 구조에서 올바르게 구축하는 것이다.

그러므로 시스템 구조는 산업과 학문의 경계에서 간극을 줄여줄 필수적인 interface이다.

contribution)
이 논문에서의 쟁점은 아카데미와 산업에서 다르게 정의내린 MCS의 개념을 명확히 하는것에 초점이 있는 것이 아니다. 무엇보다 학문과 산업 사이의 간극이 가져다 주는 효과를 직시하고 지금까지 외면받아오던 시스템 구조 측면에서의 해결책을 제시하는 것에 의의가 있다.

4) The state of the ART in ACADEMIA
학문의 영역에서는 sporadic 한 tasks 들의 유한한 set과 몇몇 execution 의 모드(L = 1,2,3,4 ...) 들을 가지는 것으로 시스템을 정의한다.
각 task들은 Di(데드라인) , Ti(주기) , li(criticality , assurance level), WCET(C_i,1 , C_i,2 ...) 의 속성을 가지고 있다.

이시스템에서는 실행 모드를 일단 mode1(L=1) 로 맞추고 모든 테스트들을 core에서 실행시키기 위해 스케줄링한다. run-time 동안 시스템이 만일 mode k로 실행되고 있고 , any task ri가 exeuction budget(C_i,k)를 벗어나게 된다면 system은 빠르게 mode (k+1) 로 전환한다. 또한 criticality level (li) 가 k 보다 낮은 경우 , k > l_i 에는 그 테스트들은 잠시 suspend 된다.

처음에는 single core에서 dual mode ( high, low) 만 고려하다가
그 이후로는 연구 모델들은 점차 다중의 시스템 mode와 criticality 레벨로 확장 , dropped task들을 re-activation , multi-core와 many-core 구조에 대한 고려까지 생각하게 됨

4-A. 아카데미 영역에서의 MCS의 시스템 구조
학계에서는 시스템 구조에 대한 논의를 거의 구체적으로 하지 않고 일반적인 임베디드 환경이라고 가정.
HW level) 딱히 정의 X
OS level) 거의 Linux , 일반적으로 그렇게 정의함
Appication level) 서로 다른 criticality를 가진 application 들을 application level에서 실행하는 것으로 정의. 또한 application의 isolatoin이 매우 필수적이다.

5) Industrial concpets regarding MCS

5-1 ) HW 단계에서

B. criticality level assignment
automotive safety Integrity Level (A, B, C,D) 뒤로 갈수록 크리티컬리티가 높다.
criticality를 결정짓을 때 세가지 분석법을 이용하여 결정지음
Hazard Analysis (HA) , Failure Modes and Effects Analysis(FMEA), Fault Tree Analysis(FTA).

우리는 오직 이 세가지 (severity , exposure and controllability)를 이용해서 산업용 criticality 구분을 여기서 진행한다.

the severity defines the estimation of the
extent of harm to one or more individuals that can occur in a
potentially hazardous situation, the associated exposure is the
likelihood of the occurrence of harm, and the controllability
is the ability to avoid a specified harm or damage through the
timely reactions of the agents involved (e.g. the driver of the
vehicle) possibly with support from external measures.

Criticality level Assignment
MCS context 들을 직접 supporting 하는 것보다 기존의 safety related 방법들과 비교하여 high criticality level 의 taks들의 완벽성을 유지하면서 규모를 확장, 복잡성 감소, power consumption을 감소시키는 부과적인 요소에 산업 분야에선 중요하다.

criticality 수준이 다른 요소 사이의 상호간 간섭으로부터 자유로울 수 있는 충분한 분리/격리가 부족하기 때문에 MCS를 달성하기위해 사용되는 전체 하드웨어 플랫폼은 소프트웨어에서 가장 높은 중요도 수준을 상속받을 필요가 있습니다.

산업에서는 MCS만을 목적을 하지 않고 편의성이나 사업성을 고려하는 경우가 종종 발생하여 MCS의 criticality 역행을 발생시키기도 한다.

또한
예를 들어, 시스템이 고임계 모드에서 실행되는 동안 저임계 작업은 고임계 작업의 실행을 보장하기 위해 종료된다. 그러나 중요도가 낮은 작업에는 하드웨어 수준에서 진행 중인 미결 요청/지시가 있을 수 있습니다. CPU의 파이프라인에 래치된 명령/요구는 특정 명령을 통해 쉽게 제거할 수 있습니다. 그러나 하드웨어 버퍼에 래치된 이미 요청된 I/O 작업은 적시에 지울 수 없습니다. 이 경우 이미 전송된 중요도가 낮은 작업의 요청은 여전히 중요도가 높은 작업의 I/O 요청 액세스(즉, 중요도 수준 반전)를 차단합니다. 프로세서의 수와 I/O 요청의 빈도가 증가하면 중요도 반전이 시스템 모드 스위치의 효과를 현저히 감소시키고 전체 시스템의 손상을 초래할 수 있습니다. 따라서 MCS의 중요도 역전을 방지하기 위해 산업용 플랫폼은 '이미 요청되어 있는 입출력 명령 제거' 기능을 지원해야 합니다.

5-2) OS level
운영체제에서는 criticality level 할당 , system monitor and system mode switch, response time analysis 이 세가지 측면이 중점이다.

1) criticality 할당
사용되는 시니리오는 크게 두가지다.
(1) 서로 다른 치명도의 application이 os 와 공유된 드라이버 접근할경우 , 높은 단계의 실행 mode(L)을 유지한다.
(2) 서로 다른 치명도의 어플리케이션이 서로 구별된(isolated) os 와 driver로 접근할 경우 ,각자의 치명도 level 을 상속 받는 요구사항이 있다. Form example, virtualization and kernel seperation

2) system monitor and system mode switch
시스템은 저임계 모드에서 시작하여 사전 정의된 조건(예: 작업의 오버 실행)에서 고임계 모드로 변경될 수 있으며, 이는 저임계 작업의 종료를 초래한다. 이 절차는 학술적 모델의 맥락에서 대부분의 실제 작업에 의해 OS 수준에서 구현되는 특권 시스템 모니터(예: 하이퍼바이저)를 통해 달성되어야 한다. 그러나 시스템 모드 스위치는 학계와 산업계 사이의 MCS의 주요 불일치이다. 즉, 시스템 모드 스위치는 safety related 표준에 의해 정의되지 않는다.

학계에서는 오직 severity만 고려하는 반면 산업에서는 severity , exposure and controllability 세가지를 고려하기 때문에 학계에서 정의내리는 저치명도 작업을 종료시키는 사안이 오히려 고치명도 작업을 종료시키는 것보다 실제 상황에서는 큰 문제를 야기할 수 도 있다.

이거 말고도 다른 문제들을 고민해볼수 있다.
특히
1) dependency저치명도 작업에서 만들어지는 데이터를 input으로는 두는 High criticality의 경우 저치명도의 작업이 종료되는 것이 고치명도 작업을 종료시키는 것만큼 최악의 결과를 가져옴

2) criticality level decomposition> 산업에서는 고치명도 작업을 다수의 저치명도 작업으로 decompose 시켜서 실행시키는 방법을 많이 사용한다. 즉, 만일 단순히 모든 저치명도 작업을 중단시키는 작업은 시스템을 역시 붕괴시킬수 있다

비록 시스템 mode switching 이 산업계에서 정의되지 않은 개념이지만, 그것은 어떻게든 'graceful degradation'와 연결될 수 있다. 즉, 덜 중요한 시스템 기능을 삭제함으로써 장애에도 불구하고 사용 가능한 더 중요한 시스템 기능을 유지하는 것을 목표로 하는 기술이다. '중요하지 않은 기능'을 종료하는 것은 산업계에서 시스템 모드 스위치를 구현하는 방법론이다.

여기서 두 단계가 걸린다.
1)고장 모드 영향 분석(FMEA)
현재 시스템 모드에서 각 작업을 종료할 때의 영향을 분석해야 한다. 종료로 인해 치명적인 결과를 초래할 수 있는 모든 작업은 다음 시스템 모드, 즉 중요한 작업으로 유지되어야 한다.

2) 종속성 분석: 중요한 작업의 종속성(dependency , 1단계에서 출력값)을 분석해야 한다. 종료로 인해 중요한 작업이 손상될 수 있는 작업은 다음 시스템 모드로 유지되어야 합니다.

3) Response time analysis
앞의 두 단계 분석을 사용한다면 기존의 응답시간 분석도 다시 고민해봐야 한다.
학술모델과 유사하게 산업계에서는 현재시스템 모드 , 다음시스템모드(더 중요성있는 시스템), 시스템 모드 변ㄱ녕으로 분석되어야 한다. 학계와 산업계의 분석의 유일한 차이점은 다음시스템 모드에서는 유지되는 작업들이 다른 유형이라는 것이다.

3) Application level

작업/중요도 수준이 다른 응용 프로그램은 일반적으로 응용 프로그램 수준에서 구현됩니다. 이전 섹션에서 설명한 바와 같이, 거의 모든 연구 작업은 스케줄링 가능성과 작업 간의 공유 리소스 관리에 초점을 맞추고 있습니다. 중요도 수준이 다른 작업을 통합하는 동안 산업 MCS의 필수 요건은 분리/격리입니다

• Temporal Isolation: tasks with different criticality levels shall be temporally separated, in order to avoid malfunction caused by consuming too high processor execution time or by blocking a shared resource by one task.

• Spatial Isolation: tasks with different criticality levels shall not exchange data (including using shared memory).
• Fault Isolation: Fault(s) from one task shall not be propagated to tasks with different criticality levels

데이터 및 장애 격리는 일반적으로 두 가지 접근 방식을 통해 달성된다.
• 물리적 분리는 중요도 수준이 다른 작업에 고유한 하드웨어 리소스를 할당하여 작업을 분리한다. • 가상 분리: 여러 소프트웨어 구성 요소를 동일한 하드웨어 플랫폼에서 실행할 수 있도록 분할된 하드웨어 프로비저닝을 설정하여 구성 요소를 분리합니다.

산업계에서는 MCS를 고려한 HW platform의 부족으로 인해 물리적 분리는 다른 용도를 위해 제작된 다른 application에서 발견.

가상분리의 경우, 가상화 기술이 제일 많이 사용.특히 가상 시스템(VM)은 가상화된 시스템에서 논리적으로 격리됩니다. 즉, 한 VM에서 실행된 애플리케이션이 다른 VM에 영향을 미칠 수는 없습니다. 설령 VM이 중단되더라도 말입니다. 이는 데이터 격리 및 장애와 관련된 요구사항과 매우 관련이 있습니다. 그러나 가상화 기술에는 복잡한 리소스 관리 및 복잡한 명령 경로가 포함되며, 이는 시스템의 성능과 예측 가능성에 상당한 영향을 미치며, 실시간 시스템의 필수 요구사항이기도 합니다.

산업 MCS 모델은 그림 4에 나와 있습니다. 그림 4와 같이 중요도 수준이 다른 작업 간의 공유 구성 요소는 하드웨어 플랫폼, 드라이버, 시스템 모니터 및 OS를 비롯한 실행 작업의 가장 높은 중요도를 상속합니다. 한편, 중요도 수준이 다른 작업과 OS는 독립적 환경에서 분리되어 시간, 공간 및 장애의 간섭을 방지합니다..