KR20230082876A - 차량용 플랫폼을 위한 arinc 기반 운영체제 적용 방법 - Google Patents

차량용 플랫폼을 위한 arinc 기반 운영체제 적용 방법 Download PDF

Info

Publication number
KR20230082876A
KR20230082876A KR1020210170764A KR20210170764A KR20230082876A KR 20230082876 A KR20230082876 A KR 20230082876A KR 1020210170764 A KR1020210170764 A KR 1020210170764A KR 20210170764 A KR20210170764 A KR 20210170764A KR 20230082876 A KR20230082876 A KR 20230082876A
Authority
KR
South Korea
Prior art keywords
execution
management schedule
execution management
type
module
Prior art date
Application number
KR1020210170764A
Other languages
English (en)
Other versions
KR102630359B1 (ko
Inventor
박예슬
Original Assignee
주식회사 알티스트
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 알티스트 filed Critical 주식회사 알티스트
Priority to KR1020210170764A priority Critical patent/KR102630359B1/ko
Priority to PCT/KR2021/019705 priority patent/WO2023101094A1/ko
Publication of KR20230082876A publication Critical patent/KR20230082876A/ko
Application granted granted Critical
Publication of KR102630359B1 publication Critical patent/KR102630359B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Stored Programmes (AREA)

Abstract

차량용 플랫폼을 위한 ARINC 기반 운영체제 적용 방법이 개시된다. 개시되는 일 실시예에 따른 차량용 운영 체제 시스템은, 차량에 탑재되는 ARINC(Avionics Application Standard Software Interface) 653 기반의 운영 체제, 차량에 탑재되는 소프트웨어 아키텍처이고, 제1 형태의 실행 관리 스케줄을 생성하는 실행 관리자(Execution Manager)를 포함하는 AUTOSAR(AUTomotive Open System ARchitecture) 플랫폼, 및 ARINC 653 기반의 운영 체제와 AUTOSAR 플랫폼 간을 결합하고, 제1 형태의 실행 관리 스케줄을 ARINC 653 기반의 운영 체제에서 사용할 수 있는 제2 형태의 실행 관리 스케줄로 변환하는 변환 인터페이스를 포함한다.

Description

차량용 플랫폼을 위한 ARINC 기반 운영체제 적용 방법{METHOD FOR APPLYING ARINC-BASED OPERATING SYSTEM ON VEHICLE PLATFORM}
본 발명의 실시예는 차량용 운영 체제 기술과 관련된다.
ARINC(Avionics Application Standard Software Interface) 653은 항공용 애플리케이션 소프트웨어를 개발하기 위한 규격으로, 실시간 운영 체제와 그 위에서 동작하는 응용 프로그램 간의 인터페이스를 규정한다. ARINC 653은 분리 커널(Separation Kernel)로서, 분리 커널에 대한 보안 요구 사항 사양인 SKPP(Separation Kernel Protection Profile)에 따라 어떤 환경에서도 안전성, 신뢰성, 및 실시간성을 보장하는 것을 최우선 목적으로 설계되었다.
ARINC 653은 구성 테이블에 정의된 프로세스 실행 정보를 바탕으로 파티션(실행 단위)의 동작을 관리한다. ARINC 653은 구성 테이블에 정적인 복수 개의 모듈을 정의해두고, 실행 스케줄에 따라 실행할 모듈을 변경하며 관리하게 된다. ARINC 653에서 이러한 기능을 다중 모듈 스케줄링(Multiple Module Scheduling)이라고 한다.
여기서, 모듈은 ARINC 653을 운영 체제로 하는 항공기에서 특정 기능을 실행하도록 하는 실행 정보들의 집합을 의미할 수 있다. 각 모듈은 하나 이상의 파티션을 포함하며, 파티션 별 실행 시간, 실행 주기, 오프셋(offset), 및 할당 코어 등의 정보를 포함할 수 있다. 각 모듈은 기 설정된 메이저 시간 프레임(Major Time Frame : MTF)마다 반복된다.
도 1은 ARINC 653에서 다중 모듈 스케줄링(Multiple Module Scheduling)의 일 예를 나타낸 도면이다. 도 1을 참조하면, 모듈 1은 파티션 1과 파티션 3으로 이루어지고, 파티션 1 및 파티션 3의 단위가 메이저 시간 프레임(MTF=300000)마다 반복되도록 설정된 것이다. 모듈 2는 파티션 2와 파티션 3으로 이루어지고, 파티션 2 및 파티션 3의 단위가 메이저 시간 프레임(MTF=400000)마다 반복되도록 설정된 것이다. 모듈 3은 파티션 1, 파티션 2, 및 파티션 3으로 이루어지고, 파티션 1, 파티션 2, 및 파티션 3의 단위가 메이저 시간 프레임(MTF=300000)마다 반복되도록 설정된 것이다.
여기서, 각 모듈의 파티션은 시간 및 공간적으로 분리된다. 여기서, 각 파티션이 시간적으로 분리된다는 것은 각 파티션의 실행 시간이 보장되는 것으로 각 파티션이 다른 파티션과 독립적이고 서로 간의 간섭이 최소화되는 것을 의미할 수 있다. 예를 들어, 모듈 1에서 파티션 1은 20000 시간 프레임 동안 실행 시간이 보장되고, 파티션 3은 파티션 1의 실행 시간 이후에 10000 시간 프레임 동안 실행 시간이 보장되는 것을 의미할 수 있다.
각 파티션이 공간적으로 분리된다는 것은 각 파티션에 할당된 리소스가 보장되는 것으로, 어떤 파티션에 할당된 리소스가 다른 파티션에 할당되지 않는 것을 의미할 수 있다. 이러한 시간 및 공간적 분리의 특성으로 인해 ARINC 653 기반의 운영 체제에서 안전성 및 신뢰성 등을 보장할 수 잇게 된다.
그리고, ARINC 653 기반의 운영 체제에서는, 안전성 및 신뢰성 등을 보장하기 위해 1개 이상의 모듈(예를 들어, 모듈 1 ~ 모듈 3)을 미리 구성 테이블에 기록한 다음 운영 체제의 동작을 수행하며, 구성 테이블에 미리 기록된 스케줄 이외에 다른 스케줄링의 변경은 불가능하다.
즉, ARINC 653을 운영 체제로 하는 항공기에서는 운행 중 소프트웨어 오류가 발생하면 갑자기 엔진이 멈추거나 항공기 날개를 조절하지 못하는 등 매우 위험한 상황으로 이어질 수 있기 때문에, 각 모듈의 파티션을 시간 및 공간적으로 분리하여 정해진 시간에 정해진 동작의 수행을 보장하고, 정적 스케줄링을 사용하게 된다.
한편, 차량에는 AUTOSAR(AUTomotive Open System ARchitecture)(개방형 자동차 표준 소프트웨어 구조 개발 파트너쉽)에서 설립한 표준화된 플랫폼을 사용한다. AUTOSAR는 기본 소프트웨어를 설명하고 애플리케이션 인터페이스를 정의하며 표준화된 교환 형식을 기반으로 일반적인 개발 방법론을 구축하는 일련의 사양서(Specification)를 제공한다.
여기서, AUTOSAR 사양을 구현하여 사용하는 대부분의 운영 체제는 PC용 운용 체제(예를 들어, Linux)를 기반으로 하는데, 이런 운영 체제의 경우 사용자를 위한 일반적인 보안 체계를 갖추고는 있지만, 성능을 위해 정확성 및 신뢰성에 대해서는 어느 정도 타협을 하게 된다는 점에서 분리 커널과는 그 기반이 다르다.
또한, AUTOSAR에서는 실행 관리자(Execution Manager : EM)가 응용 프로그램의 시작 및 종료를 관리하는데, 항공 표준과 자동차 표준의 실행 단위(파티션 또는 프로세스) 관리에는 큰 차이가 있다. ARINC 653에서는 앞에서 살펴본 바와 같이, 정적으로 파티션의 실행 관리가 이루어지는 반면, AUTOSAR의 실행 관리자(EM)는 동적으로 프로세스의 실행 관리를 수행한다. 즉, 차량의 경우 여러 세부 기능을 관리하기 위한 실행 단위의 수가 항공기 보다 훨씬 많고 상황에 따라 동적으로 프로그램 일정이 변경된다는 점에서 항공 표준의 실행 단위 관리와는 차이가 있다.
여기서, ARINC 653을 차량의 운영 체제로 사용한다면 ARINC 653의 장점인 안전성 및 신뢰성을 얻을 수 있게 된다. 다만, ARINC 653의 실행 단위 관리는 정적으로 이루어지는 반면, AUTOSAR는 실행 단위 관리가 동적으로 이루어지므로, ARINC 653을 차량의 운영 체제로 적용하기 위해서는 실행 단위 관리를 동적으로 할 수 있는 방안이 요구된다.
한국등록특허공보 제10-1967450호(2019.04.09)
본 발명은 ARINC 653을 차량의 운영 체제로 적용할 수 있는 차량용 운영 체제 시스템 및 이를 구비하는 차량을 제공하기 위한 것이다.
한편, 본 발명에서 이루고자 하는 기술적 과제들은 이상에서 언급한 기술적 과제들로 제한되지 않으며, 언급하지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
개시되는 일 실시예에 따른 차량용 운영 체제 시스템은, 차량에 탑재되는 ARINC(Avionics Application Standard Software Interface) 653 기반의 운영 체제; 상기 차량에 탑재되는 소프트웨어 아키텍처이고, 제1 형태의 실행 관리 스케줄을 생성하는 실행 관리자(Execution Manager)를 포함하는 AUTOSAR(AUTomotive Open System ARchitecture) 플랫폼; 및 상기 ARINC 653 기반의 운영 체제와 상기 AUTOSAR 플랫폼 간을 결합하고, 상기 제1 형태의 실행 관리 스케줄을 상기 ARINC 653 기반의 운영 체제에서 사용할 수 있는 제2 형태의 실행 관리 스케줄로 변환하는 변환 인터페이스를 포함한다.
상기 실행 관리자는, 상기 차량에서 기 설정된 상황 이벤트가 발생하는 경우, 해당 상황에 대응하여 실행할 프로세스들을 선정하고, 선정된 프로세스들 간 의존성을 고려하여 각 프로세스들의 시작과 종료 순서를 지정함으로써 상기 제1 형태의 실행 관리 스케줄을 생성할 수 있다.
상기 변환 인터페이스는, 상기 제1 형태의 실행 관리 스케줄에서 프로세스 간 의존성 및 각 프로세스의 실행 시간에 기반하여 상기 제1 형태의 실행 관리 스케줄을 상기 제2 형태의 실행 관리 스케줄로 변환할 수 있다.
상기 변환 인터페이스는, 상기 프로세스 간 의존성 및 각 프로세스의 실행 시간에 기반하여 복수 개의 모듈을 생성하고, 상기 제2 형태의 실행 관리 스케줄은 상기 복수 개의 모듈을 포함하며, 상기 모듈은, 상기 제1 형태의 실행 관리 스케줄에 포함되는 프로세스들 간 실행 순서, 각 프로세스의 실행 시간, 및 해당 모듈의 반복 주기가 포함될 수 있다.
상기 프로세스 간 의존성은, 실행(Running) 의존성을 포함하고, 상기 변환 인터페이스는, 상기 제1 형태의 실행 관리 스케줄에서 제1 프로세스가 제2 프로세스에 대해 상기 실행 의존성 관계에 있는 경우, 상기 제1 형태의 실행 관리 스케줄 상의 상기 제2 프로세스의 실행 시작 명령에 대응하여 상기 제2 프로세스만을 포함하는 제1 모듈을 생성하고, 상기 제1 형태의 실행 관리 스케줄 상의 상기 제1 프로세스의 실행 시작 명령에 대응하여 상기 제2 프로세스 및 상기 제1 프로세스를 포함하는 제2 모듈을 생성하며, 상기 제1 모듈은, 상기 제2 프로세스의 실행 시간이 할당된 것이고, 상기 제2 모듈은, 상기 제2 프로세스와 상기 제1 프로세스 간의 실행 순서 및 상기 제2 프로세스와 상기 제1 프로세스의 각 실행 시간이 할당된 것이다.
상기 프로세스 간 의존성은, 종료(Terminated) 의존성을 포함하고, 상기 변환 인터페이스는, 상기 제1 형태의 실행 관리 스케줄에서 제1 프로세스가 제2 프로세스에 대해 상기 종료 의존성 관계에 있는 경우, 상기 제1 형태의 실행 관리 스케줄 상의 상기 제2 프로세스의 실행 시작 명령에 대응하여 상기 제2 프로세스만을 포함하는 제1 모듈을 생성하고, 상기 제1 형태의 실행 관리 스케줄 상의 상기 제2 프로세스의 종료 대기 명령에 대응하여 상기 제1 모듈을 유지시키며, 상기 제1 형태의 실행 관리 스케줄 상의 상기 제1 프로세스의 실행 시작 명령에 대응하여 상기 제1 프로세스만을 포함하는 제2 모듈을 생성하고, 상기 제1 모듈은, 상기 제2 프로세스의 실행 시간이 할당된 것이고, 상기 제2 모듈은, 상기 제1 프로세스의 실행 시간이 할당된 것일 수 있다.
상기 차량용 운영 체제 시스템은, 상기 변환 인터페이스에 의해 변환된 상기 제2 형태의 실행 관리 스케줄을 검증하는 검증 유닛을 더 포함할 수 있다.
상기 검증 유닛은, 상기 제2 형태의 실행 관리 스케줄에 포함된 각 모듈에 대해 해시값을 산출하고, 산출한 해시값과 기 저장된 해시값을 비교하여 상기 제2 형태의 실행 관리 스케줄 검증 과정의 오버헤드를 최소화할 수 있다.
상기 기 저장된 해시값은, 이미 검증된 제2 형태의 실행 관리 스케줄에 포함된 모듈의 해시값이고, 상기 검증 유닛은, 상기 기 저장된 해시값들 중 상기 산출한 해시값과 동일한 해시값이 있는지 여부에 따라 검증을 수행할 수 있다.
본 발명의 실시예에 따르면, AUTOSAR플랫폼에서 발생하는 동적 실행 관리 스케줄(의존성 기반의 프로세스에 대한 실행 관리 스케줄)을 ARINC 653 기반의 운영 체제에서 실행 가능한 모듈 형태의 실행 관리 스케줄로 변환하여 줌으로써, 차량에서도 ARINC 653 기반의 운영 체제를 적용하여 그에 따른 안전성 및 신뢰성을 확보하면서도 차량에서 수시로 발생하는 상황 이벤트에 따라 동적 실행 관리를 수행할 수 있게 된다.
한편, 본 발명에서 얻을 수 있는 효과는 이상에서 언급한 효과들로 제한되지 않으며, 언급하지 않은 또 다른 효과들은 아래의 기재로부터 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해될 수 있을 것이다.
도 1은 ARINC 653에서 다중 모듈 스케줄링(Multiple Module Scheduling)의 일 예를 나타낸 도면이고,
도 2는 본 발명의 일 실시예에 따른 ARINC 653 기반의 차량용 운영 체제 시스템을 나타낸 블록도이며,
도 3은 본 발명의 일 실시예에서 기능 그룹(Function Group)의 상태를 나타낸 도면이고,
도 4는 본 발명의 일 실시예에 따른 실행 관리자에 의해 생성된 실행 관리 스케줄에서 프로세스 간 의존성을 설명하기 위한 도면이며,
도 5는 본 발명의 일 실시예에서 제1 형태의 실행 관리 스케줄을 제2 형태의 실행 관리 스케줄로 변환하는 상태를 개략적으로 나타낸 도면이고,
도 6 및 도 7은 본 발명의 일 실시예에 따른 제1 형태의 실행 관리 스케줄에서 프로세스 간 의존성에 따라 제2 형태의 실행 관리 스케줄로 변환하는 과정을 나타낸 도면이고,
도 8은 예시적인 실시예들에서 사용되기에 적합한 컴퓨팅 장치를 포함하는 컴퓨팅 환경을 예시하여 설명하기 위한 블록도이다.
이하, 본 발명의 실시 예를 첨부된 도면들을 참조하여 더욱 상세하게 설명한다. 본 발명의 실시 예는 여러 가지 형태로 변형할 수 있으며, 본 발명의 범위가 아래의 실시 예들로 한정되는 것으로 해석되어서는 안 된다. 본 실시 예는 당업계에서 평균적인 지식을 가진 자에게 본 발명을 더욱 완전하게 설명하기 위해 제공되는 것이다. 따라서 도면에서의 요소의 형상은 보다 명확한 설명을 강조하기 위해 과장되었다.
본 발명이 해결하고자 하는 과제의 해결 방안을 명확하게 하기 위한 발명의 구성을 본 발명의 바람직한 실시 예에 근거하여 첨부 도면을 참조하여 상세히 설명하되, 도면의 구성요소들에 참조번호를 부여함에 있어서 동일 구성요소에 대해서는 비록 다른 도면상에 있더라도 동일 참조번호를 부여하였으며 당해 도면에 대한 설명 시 필요한 경우 다른 도면의 구성요소를 인용할 수 있음을 미리 밝혀둔다.
도 2는 본 발명의 일 실시예에 따른 ARINC 653 기반의 차량용 운영 체제 시스템을 나타낸 블록도이다.
도 2를 참조하면, 차량용 운영 체제 시스템(100)은 AUTOSAR 플랫폼(102), 변환 인터페이스(104), 및 ARINC 653 기반의 운영 체제(106)를 포함한다.
AUTOSAR 플랫폼(102)은 차량에 탑재되는 표준화된 소프트웨어 아키텍쳐이다. AUTOSAR 플랫폼(102)은 어댑티브 플랫폼(Adaptive Platform)일 수 있으나, 이에 한정되는 것은 아니며 클래식 플랫폼(Classic Platform)일 수도 있다.
AUTOSAR 플랫폼(102)은 실행 관리자(Execution Manager : EM)(102a)를 포함한다. 그 이외에 AUTOSAR 플랫폼(102)의 구조는 기 공지된 기술이므로 이에 대한 자세한 설명은 생략하기로 한다.
실행 관리자(102a)는 차량용 운영 체제 시스템(100)이 탑재된 차량의 기 설정된 각 상황에서 실행해야 할 프로세스들을 관리할 수 있다. 이때, 실행 관리자(102a)는 복수 개의 기능 그룹(Function Group)을 관리한다.
여기서, 기능 그룹은 차량의 특정 기능에 관련된 프로세스(즉, 파티션)의 집합을 의미할 수 있다.
프로세스 또는 파티션은 특정 기능과 관련된 실행 단위로서, 본 명세서에서 동일한 의미로 사용될 수 있다. 부연 설명하면, AUTOSAR에서는 실행 단위를 프로세스라 하고, ARINC 653에서는 실행 단위를 파티션이라고 지칭하는 바, 본 명세서에서 이 둘은 동일한 의미(즉, 실행 단위)로 사용될 수 있다.
예를 들어, 기능 그룹 A(FG_A)는 모터를 관리하는 프로세스들의 집합일 수 있고, 기능 그룹 B(FG_B)는 네비게이션을 관리하는 프로세스들의 집합일 수 있으며, 기능 그룹 C(FG_C)는 브레이크를 관리하는 프로세스들의 집합일 수 있다.
그리고, 각 기능 그룹은 여러 상태를 가질 수 있다. 도 3에 도시된 바와 같이, 모터를 관리하는 프로세스들의 집합인 기능 그룹 A(FG_A)는 동작(Startup) 및 멈춤(Off)과 같은 상태를 가질 수 있다. 그리고, 네비게이션을 관리하는 프로세스들의 집합인 기능 그룹 B(FG_B)는 비활성화, 실행, 및 업데이트와 같은 상태를 가질 수 있다. 또한, 각 기능 그룹은 각 상태에서 실행되어야 하는 프로세스들이 기 설정되어 있다.
도 3을 참조하면, 기능 그룹 A(FG_A)는 동작(Startup) 상태에서 프로세스 P2, P3, P4가 실행되도록 설정되어 있고, 멈춤(Off) 상태에서 프로세스 P1이 실행되도록 설정될 수 있다.
실행 관리자(102a)는 차량에서 기 설정된 상황 이벤트가 발생하는 경우, 해당 상황에 대응하여 실행할 프로세스들을 선정하고, 선정된 프로세스들 간 의존성을 고려하여 각 프로세스들의 시작과 종료 순서를 지정함으로써 실행 관리 스케줄을 생성할 수 있다.
즉, AUTOSAR 플랫폼(102)의 실행 관리자(102a)는 차량의 기 설정된 상황 이벤트마다 동적으로 실행 관리 스케줄을 생성할 수 있다. 이때, 실행 관리 스케줄에는 하나 이상의 기능 그룹이 포함될 수 있으며, 각 기능 그룹은 특정 시간에 특정 상태를 가질 수 있다.
이러한 실행 관리 스케줄에서 각 프로세스의 실행 조건은 프로세스 간 의존성에 달려 있다.
여기서, 프로세스 간 의존성은 실행(Running) 및 종료(Terminated)의 2가지 종류가 있다. 실행(Running) 의존성은 해당 프로세스가 의존하는 프로세스가 실행된 후 해당 프로세스가 실행되는 것을 의미할 수 있다.
종료(Terminated) 의존성은 해당 프로세스가 의존하는 프로세스가 종료된 후 해당 프로세스가 실행되는 것을 의미할 수 있다. 프로세스 간 의존성에 대한 정보는 애플리케이션 매니페스트(Application Manifest) 파일에 저장되어 있다.
도 4는 본 발명의 일 실시예에 따른 실행 관리자(102a)에 의해 생성된 실행 관리 스케줄에서 프로세스 간 의존성을 설명하기 위한 도면이다.
도 4에서, 기능 그룹 A(FG_A)의 Startup 상태를 살펴보면, 프로세스 4(P4)는 프로세스 2(P2)와 실행 의존성 관계에 있고, 프로세스 2(P2)는 프로세스 3(P3)과 종료 의존성 관계에 있다. 이 경우, 프로세스 4(P4)는 프로세스 2(P2)가 실행된 후 실행될 수 있다. 그리고, 프로세스 2(P2)는 프로세스 3(P3)이 종료된 후 실행될 수 있다.
변환 인터페이스(104)는 AUTOSAR 플랫폼(102)과 ARINC 653 기반의 운영 체제(106) 간 인터페이스 역할을 수행할 수 있다.
변환 인터페이스(104)는 실행 관리자(102a)로부터 실행 관리자(102a)가 생성한 실행 관리 스케줄을 수신하고, 이를 모듈 형태의 실행 관리 스케줄로 변환하여 ARINC 653 기반의 운영 체제(106)로 전달할 수 있다.
즉, 실행 관리자(102a)가 생성한 실행 관리 스케줄은 AUTOSAR 플랫폼(102)에서 생성된 것으로 의존성 기반의 프로세스 실행 관리이므로, 이를 ARINC 653 기반의 운영 체제(106)에서 사용할 수 있는 모듈 형태의 실행 관리 스케줄로 변환하여야 한다.
이하에서, 실행 관리자(102a)에 의해 생성된 실행 관리 스케줄을 제1 형태의 실행 관리 스케줄이라 지칭할 수 있다. 또한, 모듈 형태의 실행 관리 스케줄을 제2 형태의 실행 관리 스케줄이라 지칭할 수 있다.
이에, 변환 인터페이스(104)는 제1 형태의 실행 관리 스케줄을 제2 형태의 실행 관리 스케줄로 변환한 후 ARINC 653 기반의 운영 체제(106)로 전달할 수 있다. 이에 따라, 차량용 운영 체제 시스템(100)의 실행 중에도 동적으로 실행 관리 스케줄을 업데이트 할 수 있게 된다.
변환 인터페이스(104)는 제1 형태의 실행 관리 스케줄에서 프로세스 간 의존성 및 각 프로세스의 실행 시간에 기반하여 제1 형태의 실행 관리 스케줄을 제2 형태의 실행 관리 스케줄로 변환할 수 있다.
도 5는 본 발명의 일 실시예에서 제1 형태의 실행 관리 스케줄을 제2 형태의 실행 관리 스케줄로 변환하는 상태를 개략적으로 나타낸 도면이다.
여기서, 모듈은 ARINC 653 기반의 운영 체제(106)에서 특정 기능을 실행하도록 하는 실행 정보들의 집합으로, 하나 이상의 파티션을 포함할 수 있다.
또한, 모듈에는 제1 형태의 실행 관리 스케줄에 포함되는 프로세스들 간의 실행 순서, 각 프로세스의 실행 시간, 및 해당 모듈의 반복 주기 등이 포함될 수 있다.
도 6 및 도 7은 본 발명의 일 실시예에 따른 제1 형태의 실행 관리 스케줄에서 프로세스 간 의존성에 따라 제2 형태의 실행 관리 스케줄로 변환하는 과정을 나타낸 도면이다.
도 6을 참조하면, 제1 형태의 실행 관리 스케줄에서 기능 그룹 A(FG_A)의 프로세스 3(P3)이 프로세스 1(P1)과 실행 의존성 관계에 있다고 가정한다. 이 경우, 변환 인터페이스(104)는 제1 형태의 실행 관리 스케줄 상의 프로세스 1(P1)의 실행 시작 명령(start(P1))에 대응하여 제1 모듈(M1)을 생성할 수 있다.
제1 모듈(M1)은 기능 그룹 A(FG_A)의 프로세스 1(P1)(즉, 파티션 1)만을 포함하며, 프로세스 1(P1)에 대한 실행 시간이 할당된 것일 수 있다.
다음으로, 변환 인터페이스(104)는 제1 형태의 실행 관리 스케줄 상의 프로세스 3(P3)의 실행 시작 명령(start(P3))에 대응하여 제2 모듈(M2)을 생성할 수 있다.
제2 모듈(M2)은 기능 그룹 A(FG_A)의 프로세스 1(P1)(즉, 파티션 1) 및 프로세스 3(P3)(즉, 파티션 3)을 포함하며, 프로세스 1(P1)과 프로세스 3(P3)의 실행 순서와 각 프로세스의 실행 시간이 할당된 것일 수 있다. 이때, 변환 인터페이스(104)는 프로세스 1(P1)의 총 실행 시간을 제1 모듈(M1)과 제2 모듈(M2)에 분할하여 할당할 수 있다.
이와 같이, 변환 인터페이스(104)는 제1 형태의 실행 관리 스케줄을 제1 모듈(M1) 및 제2 모듈(M2)을 포함하는 제2 형태의 실행 관리 스케줄로 변환할 수 있다.
ARINC 653 기반의 운영 체제(106)에서 제2 형태의 실행 관리 스케줄이 실행 될 때는, 제1 모듈(M1)이 실행되다가 제2 모듈(M2)로 변경되어 실행되게 된다. 이때, 제1 모듈(M1)이 실행될 때는 기능 그룹 A(FG_A)의 프로세스 1(P1)만 실행되고, 모듈이 제2 모듈(M2)로 변경되면 기능 그룹 A(FG_A)의 프로세스 1(P1)과 프로세스 3(P3)이 반복되며 실행되게 된다.
도 7을 참조하면, 제1 형태의 실행 관리 스케줄에서 기능 그룹 B(FG_B)의 프로세스 3(P3)이 프로세스 2(P2)와 종료 의존성 관계에 있다고 가정한다.
이 경우, 변환 인터페이스(104)는 제1 형태의 실행 관리 스케줄 상의 기능 그룹 B(FG_B)의 프로세스 2(P2)의 실행 시작 명령(start(P2))에 대응하여 제1 모듈(M1)을 생성할 수 있다.
제1 모듈(M1)은 기능 그룹 B(FG_B)의 프로세스 2(P2)만을 포함하며, 프로세스 2(P2)에 대한 실행 시간이 할당된 것일 수 있다.
다음으로, 변환 인터페이스(104)는 기능 그룹 B(FG_B)의 프로세스 2(P2) 종료 대기 명령(wait(P2))에 대응하여 제1 모듈(M1)을 유지시킨다. 즉, 변환 인터페이스(104)는 프로세스 2(P2)의 실행이 종료될 때까지 모듈의 변경 없이 제1 모듈(M1)을 유지시킬 수 있다.
다음으로, 변환 인터페이스(104)는 기능 그룹 B(FG_B)의 프로세스 3(P3)의 실행 시작 명령(start(P3))에 대응하여 제2 모듈(M2)을 생성할 수 있다.
제2 모듈(M2)은 기능 그룹 B(FG_B)의 프로세스 3(P3)만을 포함하며, 프로세스 3(P3)에 대한 실행 시간이 할당된 것일 수 있다.
한편, ARINC 653 기반의 운영 체제(106)에서 제2 형태의 실행 관리 스케줄이 실행될 때, 제1 모듈(M1)이 실행되다가 기능 그룹 B(FG_B)의 프로세스 2(P2)가 종료되면, 제2 모듈(M2)로 모듈이 변경되어 실행되게 된다.
다시 도 2를 참조하면, ARINC 653 기반의 운영 체제(106)는 차량에 탑재되는 각 하드웨어를 제어하고 응용 소프트웨어를 위한 기반 환경을 제공하며, 차량 내 컴퓨팅 자원을 관리할 수 있다.
ARINC 653 기반의 운영 체제(106)는 변환 인터페이스(104)로부터 제2 형태의 실행 관리 스케줄을 수신할 수 있다. ARINC 653 기반의 운영 체제(106)는 제2 형태의 실행 관리 스케줄을 검증하기 위한 검증 유닛(106a)을 포함할 수 있다.
즉, 변환 인터페이스(104)로부터 수신한 제2 형태의 실행 관리 스케줄은 실행 관리자(102a)로부터 생성되는 동적 실행 관리 스케줄이기 때문에, 이를 바로 실행하게 되면 ARINC 653 기반의 운영 체제(106)의 안전성 및 신뢰성을 보장하기 어려워질 수 있다. 이에 개시되는 실시예에서는 검증 유닛(106a)을 통해 변환 인터페이스(104)로부터 수신한 제2 형태의 실행 관리 스케줄을 검증할 수 있다.
구체적으로, 검증 유닛(106a)은 제2 형태의 실행 관리 스케줄에 포함된 각 모듈에 대해 해시(hash)값을 산출할 수 있다.
즉, 검증 유닛(106a)은 제2 형태의 실행 관리 스케줄에 포함된 각 모듈을 해시 함수(hash function)에 입력하여 해시(hash) 값을 산출할 수 있다.
검증 유닛(106a)은 산출한 해시값을 기 저장된 해시값들과 비교할 수 있다. 여기서, 기 저장된 해시값들은 이미 검증된 제2 형태의 실행 관리 스케줄에 포함된 모듈의 해시값들일 수 있다.
검증 유닛(106a)은 기 저장된 해시값들 중에서 상기 산출한 해시값과 동일한 해시값이 있는지 여부를 통해 상기 수신한 제2 형태의 실행 관리 스케줄을 검증할 수 있다.
검증 유닛(106a)은 기 저장된 해시값들 중에서 상기 산출한 해시값과 동일한 해시값이 없는 경우, 상기 수신한 제2 형태의 실행 관리 스케줄이 아직 검증이 완료되지 않은 것으로 판단할 수 있다. 이때, 검증 유닛(106a)은 해당 제2 형태의 실행 관리 스케줄의 안정성 및 신뢰성을 검증하고, 검증이 완료되면 해당 해시값을 저장할 수 있다. 이후, 저장된 해당 해시값이 산출되는 제2 형태의 실행 관리 스케줄의 경우에는 추가적인 검증이 없더라도 검증이 완료된 것으로 볼 수 있다.
즉, 검증 유닛(106a)은 기 저장된 해시값들 중에서 상기 산출한 해시값과 동일한 해시값이 있는 경우, 상기 수신한 제2 형태의 실행 관리 스케줄이 이미 검증이 완료된 것으로 판단할 수 있다. 이 경우, ARINC 653 기반의 운영 체제(106)는 제2 형태의 실행 관리 스케줄을 구성 테이블에 추가하여 실행할 수 있다.
이처럼 개시된 실시예에 의하면 이미 검증된 제2 형태의 실행 관리 스케줄에 대해서는 추가적인 검증을 수행하지 않으므로, 제2 형태의 실행 관리 스케줄이 생성될 때마다 본격적인 검증을 거치지 않아도 된다. 결과적으로, 개시된 실시예에 의하면 제1 형태의 실행 관리 스케줄을 제2 형태의 실행 관리 스케줄로 변환하는 과정에서 검증에 소요되는 시간을 줄여서 변환 속도를 향상할 수 있다.
개시되는 실시예에 의하면, AUATSAR 플랫폼(102)에서 발생하는 동적 실행 관리 스케줄(의존성 기반의 프로세스에 대한 실행 관리 스케줄)을 ARINC 653 기반의 운영 체제(106)에서 실행 가능한 모듈 형태의 실행 관리 스케줄로 변환하여 줌으로써, 차량에서도 ARINC 653 기반의 운영 체제(106)를 적용하여 그에 따른 안전성 및 신뢰성을 확보하면서도 차량에서 수시로 발생하는 상황 이벤트에 따라 동적 실행 관리를 수행할 수 있게 된다.
도 8은 예시적인 실시예들에서 사용되기에 적합한 컴퓨팅 장치를 포함하는 컴퓨팅 환경(10)을 예시하여 설명하기 위한 블록도이다.
도시된 실시예에서, 각 컴포넌트들은 이하에 기술된 것 이외에 상이한 기능 및 능력을 가질 수 있고, 이하에 기술된 것 이외에도 추가적인 컴포넌트를 포함할 수 있다.
도시된 컴퓨팅 환경(10)은 컴퓨팅 장치(12)를 포함한다. 일 실시예에서, 컴퓨팅 장치(12)는 차량용 운용 체제 시스템(100)일 수 있다.
컴퓨팅 장치(12)는 적어도 하나의 프로세서(14), 컴퓨터 판독 가능 저장 매체(16) 및 통신 버스(18)를 포함한다. 프로세서(14)는 컴퓨팅 장치(12)로 하여금 앞서 언급된 예시적인 실시예에 따라 동작하도록 할 수 있다. 예컨대, 프로세서(14)는 컴퓨터 판독 가능 저장 매체(16)에 저장된 하나 이상의 프로그램들을 실행할 수 있다. 상기 하나 이상의 프로그램들은 하나 이상의 컴퓨터 실행 가능 명령어를 포함할 수 있으며, 상기 컴퓨터 실행 가능 명령어는 프로세서(14)에 의해 실행되는 경우 컴퓨팅 장치(12)로 하여금 예시적인 실시예에 따른 동작들을 수행하도록 구성될 수 있다.
컴퓨터 판독 가능 저장 매체(16)는 컴퓨터 실행 가능 명령어 내지 프로그램 코드, 프로그램 데이터 및/또는 다른 적합한 형태의 정보를 저장하도록 구성된다. 컴퓨터 판독 가능 저장 매체(16)에 저장된 프로그램(20)은 프로세서(14)에 의해 실행 가능한 명령어의 집합을 포함한다. 일 실시예에서, 컴퓨터 판독 가능 저장 매체(16)는 메모리(랜덤 액세스 메모리와 같은 휘발성 메모리, 비휘발성 메모리, 또는 이들의 적절한 조합), 하나 이상의 자기 디스크 저장 디바이스들, 광학 디스크 저장 디바이스들, 플래시 메모리 디바이스들, 그 밖에 컴퓨팅 장치(12)에 의해 액세스되고 원하는 정보를 저장할 수 있는 다른 형태의 저장 매체, 또는 이들의 적합한 조합일 수 있다.
통신 버스(18)는 프로세서(14), 컴퓨터 판독 가능 저장 매체(16)를 포함하여 컴퓨팅 장치(12)의 다른 다양한 컴포넌트들을 상호 연결한다.
컴퓨팅 장치(12)는 또한 하나 이상의 입출력 장치(24)를 위한 인터페이스를 제공하는 하나 이상의 입출력 인터페이스(22) 및 하나 이상의 네트워크 통신 인터페이스(26)를 포함할 수 있다. 입출력 인터페이스(22) 및 네트워크 통신 인터페이스(26)는 통신 버스(18)에 연결된다. 입출력 장치(24)는 입출력 인터페이스(22)를 통해 컴퓨팅 장치(12)의 다른 컴포넌트들에 연결될 수 있다. 예시적인 입출력 장치(24)는 포인팅 장치(마우스 또는 트랙패드 등), 키보드, 터치 입력 장치(터치패드 또는 터치스크린 등), 음성 또는 소리 입력 장치, 다양한 종류의 센서 장치 및/또는 촬영 장치와 같은 입력 장치, 및/또는 디스플레이 장치, 프린터, 스피커 및/또는 네트워크 카드와 같은 출력 장치를 포함할 수 있다. 예시적인 입출력 장치(24)는 컴퓨팅 장치(12)를 구성하는 일 컴포넌트로서 컴퓨팅 장치(12)의 내부에 포함될 수도 있고, 컴퓨팅 장치(12)와는 구별되는 별개의 장치로 컴퓨팅 장치(12)와 연결될 수도 있다.
이상의 상세한 설명은 본 발명을 예시하는 것이다. 또한 전술한 내용은 본 발명의 바람직한 실시 형태를 나타내어 설명하는 것이며, 본 발명은 다양한 다른 조합, 변경 및 환경에서 사용할 수 있다. 즉 본 명세서에 개시된 발명의 개념의 범위, 저술한 개시 내용과 균등한 범위 및/또는 당업계의 기술 또는 지식의 범위내에서 변경 또는 수정이 가능하다. 저술한 실시예는 본 발명의 기술적 사상을 구현하기 위한 최선의 상태를 설명하는 것이며, 본 발명의 구체적인 적용 분야 및 용도에서 요구되는 다양한 변경도 가능하다. 따라서 이상의 발명의 상세한 설명은 개시된 실시 상태로 본 발명을 제한하려는 의도가 아니다. 또한 첨부된 청구범위는 다른 실시 상태도 포함하는 것으로 해석되어야 한다.
10 : 컴퓨팅 환경
12 : 컴퓨팅 장치
14 : 프로세서
16 : 컴퓨터 판독 가능 저장 매체
18 : 통신 버스
20 : 프로그램
22 : 입출력 인터페이스
24 : 입출력 장치
26 : 네트워크 통신 인터페이스
100 : 차량용 운영 체제 시스템
102 : AUTOSAR 플랫폼
102a : 실행 관리자
104 : 변환 인터페이스
106 : ARINC 653 기반의 운영체제
106a : 검증 유닛

Claims (10)

  1. 차량에 탑재되는 ARINC(Avionics Application Standard Software Interface) 653 기반의 운영 체제;
    상기 차량에 탑재되는 소프트웨어 아키텍처이고, 제1 형태의 실행 관리 스케줄을 생성하는 실행 관리자(Execution Manager)를 포함하는 AUTOSAR(AUTomotive Open System ARchitecture) 플랫폼; 및
    상기 ARINC 653 기반의 운영 체제와 상기 AUTOSAR 플랫폼 간을 인터페이스하고, 상기 제1 형태의 실행 관리 스케줄을 상기 ARINC 653 기반의 운영 체제에서 사용할 수 있는 제2 형태의 실행 관리 스케줄로 변환하는 변환 인터페이스를 포함하는, 차량용 운영 체제 시스템.
  2. 청구항 1에 있어서,
    상기 실행 관리자는,
    상기 차량에서 기 설정된 상황 이벤트가 발생하는 경우, 해당 상황에 대응하여 실행할 프로세스들을 선정하고, 선정된 프로세스들 간 의존성을 고려하여 각 프로세스들의 시작과 종료 순서를 지정함으로써 상기 제1 형태의 실행 관리 스케줄을 생성하는, 차량용 운영 체제 시스템.
  3. 청구항 2에 있어서,
    상기 변환 인터페이스는,
    상기 제1 형태의 실행 관리 스케줄에서 프로세스 간 의존성 및 각 프로세스의 실행 시간에 기반하여 상기 제1 형태의 실행 관리 스케줄을 상기 제2 형태의 실행 관리 스케줄로 변환하는, 차량용 운영 체제 시스템.
  4. 청구항 3에 있어서,
    상기 변환 인터페이스는,
    상기 프로세스 간 의존성 및 각 프로세스의 실행 시간에 기반하여 복수 개의 모듈을 생성하고, 상기 제2 형태의 실행 관리 스케줄은 상기 복수 개의 모듈을 포함하며,
    상기 모듈은, 상기 제1 형태의 실행 관리 스케줄에 포함되는 프로세스들 간 실행 순서, 각 프로세스의 실행 시간, 및 해당 모듈의 반복 주기가 포함되는, 차량용 운영 체제 시스템.
  5. 청구항 4에 있어서,
    상기 프로세스 간 의존성은, 실행(Running) 의존성을 포함하고,
    상기 변환 인터페이스는,
    상기 제1 형태의 실행 관리 스케줄에서 제1 프로세스가 제2 프로세스에 대해 상기 실행 의존성 관계에 있는 경우,
    상기 제1 형태의 실행 관리 스케줄 상의 상기 제2 프로세스의 실행 시작 명령에 대응하여 상기 제2 프로세스만을 포함하는 제1 모듈을 생성하고,
    상기 제1 형태의 실행 관리 스케줄 상의 상기 제1 프로세스의 실행 시작 명령에 대응하여 상기 제2 프로세스 및 상기 제1 프로세스를 포함하는 제2 모듈을 생성하며,
    상기 제1 모듈은, 상기 제2 프로세스의 실행 시간이 할당된 것이고,
    상기 제2 모듈은, 상기 제2 프로세스와 상기 제1 프로세스 간의 실행 순서 및 상기 제2 프로세스와 상기 제1 프로세스의 각 실행 시간이 할당된 것이며,
    상기 제2 프로세스의 총 실행 시간은 상기 제1 모듈과 상기 제2 모듈에 분할하여 할당하는, 차량용 운영 체제 시스템.
  6. 청구항 4에 있어서,
    상기 프로세스 간 의존성은, 종료(Terminated) 의존성을 포함하고,
    상기 변환 인터페이스는,
    상기 제1 형태의 실행 관리 스케줄에서 제1 프로세스가 제2 프로세스에 대해 상기 종료 의존성 관계에 있는 경우,
    상기 제1 형태의 실행 관리 스케줄 상의 상기 제2 프로세스의 실행 시작 명령에 대응하여 상기 제2 프로세스만을 포함하는 제1 모듈을 생성하고,
    상기 제1 형태의 실행 관리 스케줄 상의 상기 제2 프로세스의 종료 대기 명령에 대응하여 상기 제1 모듈을 유지시키며,
    상기 제1 형태의 실행 관리 스케줄 상의 상기 제1 프로세스의 실행 시작 명령에 대응하여 상기 제1 프로세스만을 포함하는 제2 모듈을 생성하고,
    상기 제1 모듈은, 상기 제2 프로세스의 실행 시간이 할당된 것이고,
    상기 제2 모듈은, 상기 제1 프로세스의 실행 시간이 할당된 것인, 차량용 운영 체제 시스템.
  7. 청구항 1에 있어서,
    상기 차량용 운영 체제 시스템은,
    상기 변환 인터페이스에 의해 변환된 상기 제2 형태의 실행 관리 스케줄을 검증하는 검증 유닛을 더 포함하는, 차량용 운영 체제 시스템.
  8. 청구항 7에 있어서,
    상기 검증 유닛은,
    상기 제2 형태의 실행 관리 스케줄에 포함된 각 모듈에 대해 해시값을 산출하고, 산출한 해시값과 기 저장된 해시값을 비교하여 상기 제2 형태의 실행 관리 스케줄을 검증하는, 차량용 운영 체제 시스템.
  9. 청구항 8에 있어서,
    상기 기 저장된 해시값은, 이미 검증된 제2 형태의 실행 관리 스케줄에 포함된 모듈의 해시값이고,
    상기 검증 유닛은,
    상기 기 저장된 해시값들 중 상기 산출한 해시값과 동일한 해시값이 있는지 여부에 따라 검증을 수행하는, 차량용 운영 체제 시스템.
  10. 청구항 1 내지 청구항 9 중 어느 하나의 항에 기재된 차량용 운영 체제 시스템을 구비하는 차량.
KR1020210170764A 2021-12-02 2021-12-02 차량용 플랫폼을 위한 arinc 기반 운영체제 적용 방법 KR102630359B1 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
KR1020210170764A KR102630359B1 (ko) 2021-12-02 2021-12-02 차량용 플랫폼을 위한 arinc 기반 운영체제 적용 방법
PCT/KR2021/019705 WO2023101094A1 (ko) 2021-12-02 2021-12-23 차량용 플랫폼을 위한 arinc 기반 운영체제 적용 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020210170764A KR102630359B1 (ko) 2021-12-02 2021-12-02 차량용 플랫폼을 위한 arinc 기반 운영체제 적용 방법

Publications (2)

Publication Number Publication Date
KR20230082876A true KR20230082876A (ko) 2023-06-09
KR102630359B1 KR102630359B1 (ko) 2024-01-29

Family

ID=86612513

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020210170764A KR102630359B1 (ko) 2021-12-02 2021-12-02 차량용 플랫폼을 위한 arinc 기반 운영체제 적용 방법

Country Status (2)

Country Link
KR (1) KR102630359B1 (ko)
WO (1) WO2023101094A1 (ko)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20110045722A (ko) * 2009-10-27 2011-05-04 한국전자통신연구원 오토사 플랫폼과 모스트 플랫폼 연동을 위한 통합 게이트웨이 장치 및 방법
JP2011165185A (ja) * 2010-02-04 2011-08-25 Robert Bosch Gmbh タイムトリガ型バスシステムの作動方法
KR20130117049A (ko) * 2012-04-17 2013-10-25 한국전자통신연구원 Ａｒｉｎｃ 653 규격에 따른 항공 시스템 설정 방법 및 장치
KR101967450B1 (ko) 2017-10-30 2019-04-09 현대오트론 주식회사 Autosar 플랫폼 및 게이트웨이 처리 방법
KR20190142841A (ko) * 2018-06-19 2019-12-30 주식회사 한글과컴퓨터 비-개방형 문서 형식으로 정의된 전자 문서와의 호환성을 고려하여 개방형 문서 형식으로 정의된 전자 문서를 생성하는 장치 및 그 동작 방법
KR20210065300A (ko) * 2019-11-27 2021-06-04 주식회사 알티스트 Autosar 기반 응용 소프트웨어의 설정 코드 자동 생성 방법 및 장치

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20110045722A (ko) * 2009-10-27 2011-05-04 한국전자통신연구원 오토사 플랫폼과 모스트 플랫폼 연동을 위한 통합 게이트웨이 장치 및 방법
JP2011165185A (ja) * 2010-02-04 2011-08-25 Robert Bosch Gmbh タイムトリガ型バスシステムの作動方法
KR20130117049A (ko) * 2012-04-17 2013-10-25 한국전자통신연구원 Ａｒｉｎｃ 653 규격에 따른 항공 시스템 설정 방법 및 장치
KR101967450B1 (ko) 2017-10-30 2019-04-09 현대오트론 주식회사 Autosar 플랫폼 및 게이트웨이 처리 방법
KR20190142841A (ko) * 2018-06-19 2019-12-30 주식회사 한글과컴퓨터 비-개방형 문서 형식으로 정의된 전자 문서와의 호환성을 고려하여 개방형 문서 형식으로 정의된 전자 문서를 생성하는 장치 및 그 동작 방법
KR20210065300A (ko) * 2019-11-27 2021-06-04 주식회사 알티스트 Autosar 기반 응용 소프트웨어의 설정 코드 자동 생성 방법 및 장치

Also Published As

Publication number Publication date
KR102630359B1 (ko) 2024-01-29
WO2023101094A1 (ko) 2023-06-08

Similar Documents

Publication Publication Date Title
VanderLeest ARINC 653 hypervisor
EP2591419B1 (en) Simulating and testing avionics
KR102283736B1 (ko) Autosar 기반 응용 소프트웨어의 설정 코드 자동 생성 방법 및 장치
WO2021227971A1 (zh) 沙箱实现方法、装置、设备和存储介质
WO2011094301A1 (en) Method and system for abstracting non-functional requirements based deployment of virtual machines
IL223484A (en) A method for configuring a distributed avionics control system
US10254986B2 (en) Implicit coordination for deployment of computing systems using a data sharing service
CN111201521B (zh) 具有应用控制的早期写确认支持的存储器访问代理系统
US8938712B2 (en) Cross-platform virtual machine and method
EP4261631A1 (en) Control system and control method
KR102630359B1 (ko) 차량용 플랫폼을 위한 arinc 기반 운영체제 적용 방법
Huber et al. Using RTAI/LXRT for partitioning in a prototype implementation of the DECOS architecture
Mundhenk et al. Dynamic platforms for uncertainty management in future automotive E/E architectures
KR101733339B1 (ko) 사이버 물리 시스템을 위한 보안 제약 사항을 포함하는 실시간 스케줄링 장치 및 방법
Perez Tijero et al. Multiprocessor platform for partitioned real‐time systems
US11288104B2 (en) Automatic dynamic operating system provisioning
US10528391B1 (en) Execution manager for binary objects operating across private address spaces
Pérez et al. Towards the integration of data-centric distribution technology into partitioned embedded systems.
Buczyński et al. Resource partitioning in phoenix-RTOS for critical and noncritical software for UAV systems
US20230067658A1 (en) System and operation method of hybrid virtual machine managers
US20240054000A1 (en) Container scheduling and deployment method and apparatus, and domain controller system
US20230195481A1 (en) Hybrid partitioning of virtualization on multiple core systems
KR20240009786A (ko) 차량용 소프트웨어 플랫폼의 시뮬레이션을 위한 os 가상화 장치 및 방법
KR20100073085A (ko) 다중 코어 플랫폼에서의 하드웨어 디바이스 드라이버 추상화 방법 및 장치
Becker et al. The MATERIAL framework: Modeling and AuTomatic code Generation of Edge Real-TIme AppLications under the QNX RTOS

Legal Events

Date Code Title Description
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant