AUTOSAR

2025/03/18

By seabears

AUTOSAR

태스킹 컴파일러 임피니온 그린 뭐시기

소프트웨어 플랫폼의 필요성
- 소프트웨어 플랫폼이란?
  - 응용 SW와 HW를 연결하는 중간 계층
- 왜 필요한가?
  - 차량 내 제어기 수량 증가 -> 제어기 통합 필요
  - SW 복잡성 증가 -> 플랫폼 공용화 및 표준화 필요
  - HW 변경마다 모든 기반 SW, 연결 SW, 응용 SW 전체를 ISO 26262를 적용하며 개발해야 함 -> 응용 SW는 HW에 구애받지 않고 사용/개발 가능
AUTOSAR 정의
- AUTOmotive Open System ARchitecture의 약자
- “Cooperate on standards, compete on implementation”
AUTOSAR 운영 조직
- Core partner
- Premium Partner Plus
- Premium Partner
- Associate Partner
- Attendee
AUTOSAR 종류
- Classic
  - 기본 컨트롤러 제어 SW
  - 운영체제를 가짐
- Adaptive
  - 자율 주행 관련
  - 운영체제 따로 없어서 리눅스 또는 상용 운영체제 사용
AUTOSAR 개발 과정
- 1. Configure System
    - 시스템 설정 단계
    - 컴포넌트의 구성/연결 등을 정의
- 1. Implement Component
    - 구성한 컴포넌트에 대한 코드 구현 등을 진행
- 1. Extract ECU-Specific Information
    - 시스템 구성 정보로부터 특정 제어기 SW 구현을 위한 정보만을 추출
benefit
- OEM 측면
  - 다양한 부품사에서 기능 제공받아 간단한 통합
- Supply(Tier1) 측면
  - 다양한 OEM에 공급 가능
Real Time
- Hard
  - 데드라인 안에 수행 못할 경우 심각한 문제를 일으키는 Time critical system에서 사용
- Soft
  - 영상 시청 등과 같이 성능 저하를 일으키는 시스템

구분	Hard	Soft
정의	시스템이 정해진 시간 내에 반드시 작업을 완료해야 하는 실시간 시스템	기한을 초과해도 실행되지만, 성능 저하가 발생할 수 있는 실시간 시스템
시간 제약	엄격한 시간 제약 (Deadlines Must Be Met)	시간 초과 시 성능 저하 가능하지만 허용됨 (Deadlines Can Be Missed)
예시	자동차 ECU, 항공기 제어 시스템, 방산 무기 시스템	영상 스트리밍, 온라인 게임
지연 허용 여부	절대 허용 불가	일부 지연 허용
우선순위	정해진 기한 내 무조건 완료해야 함	기한 초과 시 가능하면 빠르게 처리
스케줄링	주로 고정 우선순위 방식	일반적인 우선순위 기반 또는 공정성을 고려한 스케줄링
미스(기한 초과) 발생 시	치명적인 결과 발생 (예: 자동차 제어 실패로 사고 발생)	성능 저하 발생 가능하지만 시스템은 계속 동작

AUTOSAR 소프트웨어 개발 순서

1. Configure System
- 시스템 설정 단계로 컴포넌트의 구성/연결 등을 정의
- = Software Component Description을 개발
2. Implement Component
- 위에서 구성한 컴포넌트들에 대한 코드 구현 등을 진행
3. Extract ECU -Specific Information
- 시스템 구성 정보로부터 특정 제어기 소프트웨어를 구현하기 위한 정보만을 추출
4. Configure ECU
- 제어기 관련 설정 진행
- = ECU Configuration Description 개발
5. Generate Executable
- 제어기에서 동작하는 실행 파일(.elf)을 생성

1. Configure System

시스템 구성 단계에서 설계한 애플리케이션은 다음과 같은 과정을 통해 제어기 내에서 동작

1. 애플리케이션 개발
- 서로 연결된 컴포넌트(SW-C)들의 집합을 통해 설계
- 제어기는 고려하지 않음
2. VFB
- 연결된 컴포넌트들이 교류하는 가상의 통신 구조(통로)
3. 제어기 할당
- 컴포넌트를 특정 제어기에 배치(제어기 고려)
- 가상의 컴포넌트 간의 실제 연결
  - 1) 제어기 내에서 연결
  - 2) 통신 수단(CAN, FlexRay 등)을 통한 제어기 간의 연결
4. Run-Time Environment(RTE)
- 컴포넌트끼리 or 컴포넌트와 BSW 간의 실제 인터페이스
- VFB 수준에서 설계한 컴포넌트들 및 컴포넌트 간의 관계를 제어기 상에서 동작할 수 있도록 코드화(VFB 구현)

Software Component Description 개발 단계

1. VFB level
- 컴포넌트의 통신 속성 및 서로의 관계 표현
- 구성요소
  | 1 | 2 | 3 | 4 | 5 | | :——-: | :———: | :—: | :——-: | :—————————: | | Component | Composition | Port | Interface | Assembly/Delegation Connector |
2. RTE level
- 컴포넌트의 행동(Internal Behavior) 기술
- 구성요소
  | 1 | 2 | 3 | | :——: | :—: | :———-: | | Runnable | Event | Access Point |
3. Implementation level
- Runnable 코드 작성
- 구성요소 : Code

VFB level

Component
- VFB 수준 시스템 중심 구성 요소
- Port로 컴포넌트 간 상호작용
Component-type vs Component-prototype
- Component-type : 컴포넌트의 속성 정의 (ex : 특정 기능의 포트 소유)
- Component-prototype : Component-type에 대한 인스턴스 (메모리 할당)
- 하나의 Component-type으로부터 여러 Component-prototype 생성
Composition
- 다른 컴포넌트를 포함하는 컴포넌트
- 내부의 컴포넌트는 Component-prototype으로 존재
- Component-type에 대한 Component-prototype, Port, Connector 소유
- Composition 자체는 Component-type
- Root Composition에서 Root Composition Prototype으로 최종적으로 Prototype화
Port
- 컴포넌트 간의 상호작용(통신)을 위한 입구
- P-port와 R-port
- P-port : Interface에 정의된 요소 제공 provide
- R-port : Interface에 정의된 요소 요청 require
Interface
- Port가 제공하거나 요구하는 타입 정의
Assembly Connector
- P-Port와 R-Port가 통신하기 위해 연결
Delegation Connector
- Composition을 구성할 때 내부 Port를 외부에서 사용하기 위해 연결
- P-Port는 P-Port, R-Port는 R-Port와 연결
Runnable
- 컴포는트의 실제 구현을 구성하는 가장 작은 단위
- RTE를 통해 시작되는 Instruction Sequence
- 하나의 컴포넌트에 여러 Runnable 포함 가능