Time and Space Partitioning in Spacecraft Avionics

Time and Space Partitioning in Spacecraft Avionics

 

European Space Agency

James Windsor, Kjeld Hjortnaes

On-board Software Systems Section, 

Third IEEE International Conference on Space Mission Challenges for Information Technology

Abstract

 논문은 spacecraft에서 IMA concept을 기반으로 하는 Time and Space Partitioning(TSP)의 on-board software의 이점에 대하여 설명한다. 본 논문은 어떻게 TSP가 서로 다른 중요도와 보안 분류를 가진 어플리케이션들을 통합할 수 있는지 그리고 어떻게 시스템의 검증을 향상시키는지에 대하여 말한다. 

I. INTRODUCTION

 지난 십년간 항공분야에서는 fully federated architecture 에서 조금 더 integrated architecture 으로 중대한 수정이 이루어 지고 있다.  order to save on mass, volume and power, and also to increase efficiency, time-to-market, and long term maintainability / upgrade-ability. 동시에 소프트웨어를 부속하는 수는 급격하게 증하가 하였다. // 항공분야에 소프트웨어적 요소가 증가하였다.

IMA의 주된 목적은 integrated architecture을 정의 하는것이다. 이것은 federated architecture 주된 장점을 보존해야 한다. 즉 fault containment and ‘separation of concerns’이가. 

우주분야에서도 higher level of integration가 필요하다, saving on mass, volume and power while managing the increasing amount of functionality embedded in the on-board software (OBSW). 우주 분야와 항공분야가 비슷하기때문에 항공기 분야에서 사용되었던 IMA 전략을 일부 혹은 전부 우주분야에도 해당이 된다. 

IMA for space(IMA-SP)의 이득의 평가에 중점을 둔다. 그리고 주로 인공위성의 잠제적으로 발생할 이점에 대하여 확인한다. 

II. THE SPACECRAFT AVIONICS– CURRENT STATE 

최근 그림 1과 같이 spacecraft의 컴퓨터 플램폼에서는 파티셔닝 없이 integrating Data Management functional  하는 경향이 있다

이렇게 되면 시스템의 전체 시스템의 검증에 대하여 책임질 수 있는 시스템 통합자가 필요하게 된다. 

다음과 같은 밑에 깔려있는 작업의 복잡성 때문이다. 

- 하나의 환경에서 여러개의 에플리케이션을 통합하여 관리 하는 것은 어렵다. 

- 모든 에플리케이션들이 결과적으로 같은 critical class를 같는다.

- fault containment는 소프트웨어 함수로만 제공된다.

- 완벽하게 통합된 시스템은 하위 기능 체인이 테스트 되는 경우에도 활성화되어야 한다. //하나의 APP이 전체 시스템의 영향X

앞으로 spacecraft의 기능으 증가할 것으로 예상이되고 또한 그 결과로 소프트웨어의 복잡석이 증가하여 조합과정에서 테스트 케이스의 숫자가 폭팔적으로 증가할 것이라고 보인다. 따라서 통합과 검증과정이 악화될것이다.

on-board architecture에서 통합의 복장성을 줄이기 위해 서로 상관업는 기능들 간을 분리하는 isolated manageable software component 가 필요하고 이것은 신뢰된 독립적인 통합시스템을 가능하게 할 것이다. 

III. TIME AND SPACE PARTITIONING

우주 항공 분야에서 federated system의 특성은 유지하면서 높은 수준의 통합을 할 수 있는 방법을 소개 한다.

Time and Space Partitioning (TSP) 는 함수기능간의 소프트웨어적으로 독립적인 컴포넌트로 고려한다 to and/or isolate fault 를 가지고 그리고 소프트웨어 통합에 검증과 확인 과정에 대한  노력을 줄여야 한다. 

A. Basic Properties

An IMA for Space architecture is composed of a shared computing core, a System Executive and a number independent application programs. The computing core share its resource between the application program via a time and space partitioning 

architecture.

system executive(SE:운영체제)와 APP의 분리는 컴퓨터의 Supervisor / User mode를 사용하여 분리한다. 

APP들 간의 분리는 Memory Management Unit (MMU) or a Block Protection Unit(BPU) 둘 중 하나를 사용하여 해결한다. 

이러한 하드웨어적인 전제 조건은 강력하게 기능(파티션)들을 독립되게 해준다.(안정성과 보안성)

소프트웨어적으로 IMA-SP를 따르는 TSP시스템은 다음 그림2와 같이 두개의 레이어로 구성되어 있다. 

System Executive layer: 

각각의 APP이 실행할 수 있는 방법의 기능을 제공여야 한다. 그리고 서로 다른 APP간의 강력한 파티셔닝을 제공하여야 한다. 

SE에는 파티션의 스케줄링과 커뮤니케이션 그리고 하드웨어 시그널을 핸드링 해야하는 책이밍 필요하다. 

Application layer: 

SE를 통해서 할당된 독립된 자원에서 애플리케이션이 동작한다.

1) 공간 파티셔닝

Memory partitioning은 MMU 나 BPU를 통하여 파티션에 정의된 메모리 영역 이외에 곳을 접근 하는것을 메모리 접근을 제한 함으로써 보장한다.

2) 시간 파티셔닝 

The order of partition activation is defined at configuration time using configuration tables. This provides a deterministic scheduling methodology whereby the partitions are a predetermined amount of computing time. 

// 글로벌 스케줄링에 대한 이야기 

Tasks within the partition can be scheduled statically or dynamically. 

// 로컬 스케줄링은 다른가는 이야기 인데 XtratuM의 사례를 우리도 따라가자면 이부분은 VM이 감당해야 하기 때문에 하이퍼 바이저는 신경 쓰지 않아도 된다.

3) 인터럽트관련 

TSP는 자신의 파티션의 공통 자원에 대한 각각의 파티션의 Uninterrupted 에 대한 보장을 해야 한다. 자신에게 시간이 할당 되지 않은 시간 동안의  

// 인터럽트가 왔다고 고정된 스케줄링을 벋어 나는 행동을 하면 안된다 큐에 인터럽트정보를 저장 하고 다시 전달하는 것이 필요하다. 

B. Inter Partition Communication

ARINC-653 설명서에 IPC에 대한 메커니즘이 정의 되어 있다. port를 사용하여 파티션간의 채널을 유지 하는 구현이다. A “Message Passing” technique is used to communicate through a channel between two partition ports. 포트는 미리 SE에 의해서 메모리 영역에 할당 되어야 하낟. IPC메커니즘는 space 파티셔닝을 보장한다 그리고 실시간 고정된 스케줄링에서의 프로세서 간의 통신을 지원한다. 

C. IO Handling

IO의 일반적인 원칙은 두가지가 있다. 

IO는 deadlock을 발생 하면 안된다. 

그리고 결정적인 파티션의 스케줄링에 영향을 주면 안된다. 

IO는 SE 레이어에서 하드웨어 버퍼를 통하여 관리 해야만 하고 오직 한정된 파티션들 즉 시스템 파티션으로 정의된 파티션 만이 접근이 가능하다. 시스템 파티션은 IO디바이스의 자원을 가지게 되며 반드시 하나의 파티션이 가져야 하며 다른 파티션이 의 서비스에 영향을 주어서는 안된다. 그리고 다른 파티션의 애플리케이션이 IO에 접근을 원한다면 그림 3과 같이 시스템 파티션과 IPC를 통하여 자원을 공유 해야한다. 이 공유 자원을 처리하는 IO는 응용 프로그램 수준에서 인터럽트 구동이 더 이상 없다는 것을 의미합니다.

// 여기서 좀 지금 까지 생각헸던 것과 다르다. IO디바이스는 시스템 파티션만이 가질 수 있고 다른 파티션에 영향을 주어서는 안된다. 도메인 0의 개념이 필요하다. 시스템 파티션이 아닌 애플리케이션에서는 애플리케이션 수준에서의 인터럽트가 없음을 의미 한다. 그리고 더 중요한건 다른 장비들과 자원의 공유가 필요 없는 디바이스 들은 시스템 파티션 없이 바로 해당 파티션이 관리 할 수 있다. 그러니까 공유가 필요한 디바이스는 시스템 파티션이 가지고 공유가 필요없는 파티션은 그냥 일반 파티션이 가져서 빠르게 처리하면된다. 

D. Role Definition 

항공 산업에서 배운 교훈은 그림 4에 도시 된 바와 같이 명확한 역할 정의에 준수의 필요성을 강조하고있다.

In particular the role of the System Integrator is essential to the success of the IMA strategy. Each supplier is responsible for adhering to their assigned TSP allocation (CPU time, IO schedule, FDIR specification), and in particular shall demonstrate the conformance and safety of these properties.

The System Integrator has two roles

1. 은 각각의 파티션에 얼마만큼의 자원을 할당 하는가 

2. 최종 통합이 안전하게 동작이 될것인가 검증 해야 한다. 

The System Integrator has two roles; as a System Architect they are responsible for system design including the detailed on-board resource allocation. System design shall determine the optimal split into hosted applications and the required resources per application. The second role is being formally responsible for the final integration and configuration of the components. As part of the system integration campaign they shall verify that the allocated budget and parameter safety is respected.

//시스템을 통합하는 과정에서 통합자가 파티션을 조합하고 설정하는 과정에 대햐여 룰을 정하고 지켜 가야 한다는 소프트웨어 공학적인 측면의 이야기 

IV. BENEFITS OF TSP

TSP를 통하여생겨날것이라고 예상되는 이익은 다음과 같다. 

A. Reduced integration effort 

B. Hardware resource savings 

C. Fault containment in an integrated system     +

D. Software Criticality                                     +

E. Security                                                    +

V. USE CASES

우주 분야에서 TSP적용 하였을 경우 이득이 있는 몇몇 사례 다음에 TSP의 개념은 위성 도메인의 일반적인 사용 사례의 수에 대해 검사됩니다.

A. Central Flight Software

Central Flight Software 는 Data Management (DMS) and Attitude & Orbital Control (AOCS)로 주로 구성되는된 integrated solution 적용 하였을때 서로 coupling 된다 따라서 combinatorial increase하게 되어 테스트 비용이 증가 한다 또한 서로 라른 보안 단계를 가지고 있었더 서로 다른 시스템을 결합 하게되어 검증 단계에서 더 많은 노력이 필요하게 된다. 

B. Payload Software 

payload software는 ommand, control and monitor와 같이 분리되어 있어서 서로 다른 보안 단계를 가지기 때문에 파티셔닝 하여 관리 하면 검증 자체가 심플해져서 비용이 절감 되게 된다. 

C. Software Development using Multiple Teams

The expected TSP solution would allocate one or several partitions to each software development team. This will allow each team to develop their software following an independent life cycle which in turn will mean that the system development process is decoupled across the application suppliers.

D. System and Software Maintenance 

구식의 새로운 애플리케이션을 수정하여 새롭게 올리는과정에서 부분 적인 수정이 가능하기 때문에 수정/검증 비용이 감소한다.

The TSP concept would enable the starting, stopping, upload and removal of hosted applications with minimal impact on the partitions and the overall system.

E. Dual-Use Missions: Secure On-board Software

90년 부터 비용 문제로 인하여 dual-use spacecraft 라는 개념이 생겨 났다. 이것보 보안 레벨의 차이 때문에 파티셔닝이 더 우수하다는 것이다. 

VI. TECHNOLOGY GAP

항공분야의 IMA기술과 우주분야에 차이에 대하여 정의 하고 현실적으로 우주용 소프트웨어가 동작이 가능한지 확인한다. 

A. IO Handling and Inter-Partition Communication

Input/Output handling은 TSP를 적용할 때 제약사항으로 인식이 된다.

항공 분야에서는 dedicated IO Module (IOM)사용해 왔다. The IOM contains partitions which host the physical hardware interface and associated software drivers, and provides a port interface for communication to other partitions.Thereby IO handling and IPC is handled the same way giving the equal timing properties.

IPC for the space domain can be implemented through two different approaches: a memory-to-memory transfer mechanism or database mechanism. By transferring an existing spacecraft avionics into a TSP architecture, it is possible to illustrate the two IPC options see Fig 6 and 7.

Memory-to-memory transfers are already implemented in flight software via RTOS message queues therefore the impact of adopting TSP is minimal.

B. Maintenance

이건 극명하게 다르다 항공분야는 오프라인 상태에서 코드 수정을 하지만 인공위성에서는 동작 상태에서 코드 수정을 해야 한다 해결이 필요하다. 

C. System Executive and Support Tools

아직 현존해서 쓰는 건 없고 오픈소스로 AIR-II 와 Xtratum이 있다. 툴이 더 필요한 상황이다. 

D. Application Programming Interface

이건 문제가 되지 않는다 APEX를 통한 커뮤니케이션 구현하는데 아무 문제가 없다 우주 도메인에서 

E. Hardware

이문제는 MMU가 있냐 없냐 인데 현제는 없지만 미래용 레온 같은 모델에 mmu가 존재 하기 때문에 해결 될 것 이다. 

VII. TECHNOLOGY ACTIVITIES

A. Separation Kernel and Tools

AIR-II가 retem 를 수정하여 ARINC를 추가 하는 활동이 있다.

B. Security

PikeOS를 수정한 SysGo와 open-source technology XtraTum이 있다. 

C. IMA for Space Studies 

TSP를 적용한 SE들의 데모는 완벽한 상태이다. 이제 실제 하드웨어에서 데모가 가능해야 한다. 미래에는 다음과 같은 연구가 진행 되어야 할 것이다. 

+ The formal porting and qualification of the SEs (open-source and commercial) and their toolsets.

+ The prototyping of IO management, either as a separate partition or in an independent IO Module.

+ The analysis of the impact of the introduction of partitions within existing platform architecture, and in particular how to make functional chains truly independent.

+ Prototype an existing space application onto a partitioned based software architecture to gain experience on the process, the organizational responsibilities, and on full scale applications.

+ study the implications and strategy of software maintenance on a TSP based running system. 

VIII. CONCLUSION

Therefore, the TSP architecture is expected to reduce the integration complexity by allowing the separation of 

uncorrelated functions into isolated manageable hosted applications that can be incrementally validated independently of the integrated system.