자동차 소프트웨어
자동차 소프트웨어의 안전성
- 2009년 도요타 리콜 사태
- 브레이크가 작동하지 않아 전복되어 탑승자가 모두 사망한 사건
- 두 번에 거쳐 900만대 리콜이 일어난다.
- 가속페달이 운전석 매트에 끼어 회복되지 않는 문제
- 가속페달 내부 부품이 기계적으로 서로 끼어 회복되지 않는 문제
- cf) Bookout 사망사건
- 도요타의 전자제어 스로틀 시스템에 많은 결함이 있는 것으로 밝혀졌다.
- Signle Bit Flip - Failsafe architecture 결함
- 소프트웨어 결함의 심각성을 보여준 대표적 사례
- 2016년 테슬라 오토파일럿 사망 사건
- 테슬라 오토파일럿: 자율주행이 본격적으로 제품화된 최초의 사례
- 플로리다의 Joshua Brown 사고 조사 결과, 최종 책임은 운전자에게 있다고 결론지었다.
- 테슬라는 안전규칙을 지키지 않으면 오토파일럿이 작동 불가능하도록 시스템을 만들었다.
- 인공지능 기반 인지기술은 기존 자동차 제어시스템과 근본적으로 다르다.
- 기존에는 센서 데이터를 이용하여 프로그래밍을 한다.
- 인공지능 기반 시스템은 프로그래머가 알고리즘을 작성하지 않아 데이터에 의존하게 된다.
자동차 제어 시스템 개발 절차
- 프로세스: 시스템 개발을 위한 절차 가이드라인
- Waterfall Model: 요구사항 분석, 설계, 구현, 검증, 유지보수 순서로 진행된다.
- V-Cycle Model
- 위로 올라갈수록 추상화 수준이 높고 상세화 수준이 낮다.
- 왼쪽에서 설계와 구현, 오른쪽에서 구현 결과에 대한 평가가 이루어진다.
- 같은 추상화 수준에 위치한 단계들은 밀접한 관계가 있다.
- 소프트웨어 공학 관점의 V-Cycle Model
- 요구사항 분석: 해당 시스템이 만족해야 하는 요구사항을 고객의 관점에서 기술한 것
- Architecture 설계: 분석된 요구사항을 기반으로 시스템 전체 구조를 도식화하여 표현하는 단계
- 논리 아키텍처: 단위 기능을 나열하고 기능 간 상호관계를 도식화하는 과정
- 기술 아키텍처: 기능을 구현하는 기술 요소와 소프트웨어 구성요소를 감안하여 시스템을 구조화하는 과정
- 단위설계 및 구현: 아키텍처 설계 바탕으로 모듈을 설계하고 코드로 구현하는 단계
- 단위검증: 구현된 소프트웨어 구성요소를 개별적으로 검증하는 단계
- 통합 및 검증: 개발된 소프트웨어를 서로 연결하고 호출하며 인터페이스를 검증하는 단계
- 시스템 검증: 완전히 통합된 전체 시스템에 대해 검증하는 단계
- 후반부의 검증단계에서 설계 상의 문제가 발견되면 전반부 설계 단계로 돌아와 문제를 해결한다.
- 설계 변경 시 프로젝트 일정이 지연되고 비용이 증가한다.
- 자동차 ECU 개발에 맞춘 V-Cycle Model
- Front Loading이 적용되어 각 단계에서 시뮬레이션 기법을 이용하여 마무리
- Modeling and Design: 제어 알고리즘을 모델링하고 시뮬레이션을 통해 정확성 검증
- Rapid Prototyping: 앞에서 개발된 제어 모델을 실제 자동차에 붙여 빠르게 검증
- PC에서 개발한 모델을 Real-Time Target 머신에 다운로드한 후 실제 제어대상에 연결하여 검증한다.
- Targeting: 일반적으로 소스 코드를 자동 생성한다.
- Hardward-in-the-Loop: 앞에서 구현된 ECU를 처음으로 검증하는 단계
- ECU를 HiL 시뮬레이터에 연결하여 실제 자동차에 연결한 것처럼 검증한다.
- System Testing: ECU가 완성된 자동차에 연동되어 최종적인 테스트를 하는 단계
- Calibration과 Measurement가 중요하다.
- 연비와 성능 같은 정밀한 튜닝이 이루어진다.
자동차 제어 시스템 개발 방법론
- 방법론: 프로세스 각 단계에서 사용하는 툴과 방법
- Model-Based Design: 복잡한 문제를 해결하기 위해 수학적 모델과 가시적 설계도구를 이용하는 것
- MBD의 장점
- 프로그램에 능숙하지 않은 제어개발자도 쉽게 로직 개발 가능
- 생성된 코드 품질 보장 가능
- 전체 개발 기간과 비용 절감
- MBD의 단점
- 메모리 사용량, 코드 실행시간 등 최적화 문제
- MBD의 장점
- Feedback Control System
- 제어 대상(plant)와 제어 컴퓨터(ECU)로 구성된다.
- Plant는 센서를 통해 아날로그 신호로 변형된다.
- ECU에 Alalog-To-Digital 변환을 통해 컴퓨터로 전달된다.
- 컴퓨터 내 제어 소프트웨어는 센서 입력을 기반으로 판단한다.
- 판단 결과를 Digital-To-Analog 변환을 통해 액추에이터에 전달한다.
- 액추에이터는 물리 세계의 변화를 만들어 결국 Feedback Loop가 만들어진다.
- 직접 자동차에 부착하여 테스트하면 비용이 많이 들고 위험 부담이 크다.
- MBD: PC만 가지고 제어 시스템을 개발할 수 있다.
- Plant: 물리 법칙에 따른 수행 모델로, 물리 법칙을 따라 미분방정식으로 표현된다.
- 연속시간 시스템
- Simulink(plant 모델링 기능), ASCET(제어 로직 개발)
- ECU와 소스코드: 다이어그램으로 표현된 제어모델로 물리법칙과 무관하게 비연속적이다.
- 이산시간시스템
- RCP 단계: 제어 로직을 실시간 Target에 다운로드하여 실제 plant와 연동하여 테스트
- Targeting 단계: 제어 로직을 C코드로 자동 생성(Targetlink)
- Tool들은 제어 로직에 시뮬레이션 기능을 지원한다.
- Model-in-the-Loop: 시뮬레이션 툴 자체가 모델을 해석하여 로직 수행, 빠른 모델링
- Software-in-the-Loop: 소스코드 생성 후 PC에서 실행파일을 만들고 PC에서 시뮬레이션
- Processor-in-the-Loop: 실행파일을 임베디드 보드에 다운로드하여 실행, 실제 ECU 환경과 유사
- Plant: 물리 법칙에 따른 수행 모델로, 물리 법칙을 따라 미분방정식으로 표현된다.
자동차 소프트웨어 기능안전
- 안전성에 대한 기본 개념
- Harm (위해): 사람이 다치거나 죽거나 피해를 입는 것
- ex) 자동차와 충돌해 부상을 당하게 되는 상황
- Hazard (위험요인): 물체가 가지고 있는 Harm을 유발하는 특성
- ex) 보행자 입장에서 자동차
- Risk (위험도): Hazard가 Harm을 유발할 가능성
- ex) 무단횡단을 한다면 Risk 증가, 횡단보도를 이용하면 낮은 Risk
- Safe: Risk를 충분히 낮추어 Hazard를 제어함으로써 Harm으로부터 사람이 보호되는 것
- Functional Safety: Safety 관련 시스템이 올바로 동작하는 것을 보장하고 RIsk를 낮추기 위한 방법을 적용해 Safety를 보장하는 것
- Harm (위해): 사람이 다치거나 죽거나 피해를 입는 것
- ISO 26262: 자동차 전장 시스템을 위한 기능안전 표준
- 중량 3.5톤 이하 양산 승용차에 설치되는 안전관련 전자제어 시스템에 적용되는 표준
- Fault: 시스템에 내제된 결함
- Fault가 시스템에 생기는 것을 차단해야 한다.
- Error: 결함이 발현되어 시스템이 비정상적인 상태
- Error를 조기에 파악해서 복구 작업을 실행해야 한다.
- Failure: Error에 대한 조치가 이루어지지 않아 해야할 일을 못하는 것
- Failure가 발생하더라도 safety에는 문제가 없도록 해야한다.
- Systematic failure: 하드웨어 설계, 소프트웨어 코딩을 잘못해 생긴 버그
- Random hardward failure: 하드웨어 부품 생애주기 동안 확률적으로 생기는 failure
- ASIL (Automotive Safety Integrity Level): Hazard Risk에 따라 등급이 결정된다.
- A는 낮은 위험, D는 높은 위험
- 피해 심각성(S0~S3), 발생 가능성(E0~E4), 통제 가능성(C0~C3)을 바탕으로 결정된다.
- 대표적인 표준
- MISRA-C 같은 C언어 subset을 이용하여 안전성을 보장한다.
- 의미가 명확한 가시적 표현방법을 사용해야 한다.
- 함수에는 하나의 입구와 하나의 출구만 존재해야 한다.
- ASIL C, D 등급은 HiL 방법을 따른다.
ECU 소프트웨어 구조
ECU 하드웨어
- Single board에 MCU와 IO 디바이스들이 배치되어 있다.
- ECU의 역할에 따라 MCU 종류와 IO 디바이스 종류가 달라진다.
- ECU 소프트웨어는 저수준에서 하드웨어를 직접 조작하는 구조로 개발된다.
ECU 소프트웨어
- Firmware 구조: 하나의 제어루프로 이루어진 단순한 형태
- MCU가 바뀌거나 IO 디바이스가 변경될 경우 Firmware 재개발 필요
- 소규모 개발자가 단순 제어시스템 개발 시 사용하는 구조
- 실시간 운영체제: Real-Time Operating System
- 일정한 주기로 실행되는 독립적인 함수로 모듈화하고 Task를 서로 다른 개발자가 개발할 수 있다.
- 멀티태스킹을 지원하므로 여러 Task를 통합하여 하나의 CPU에서 사용할 수 있도록 스케줄링한다.
- Scheduling
- 선점형 스케줄링: 더 급한 task가 있으면 밀어내고 급한 것을 먼저 실행
- 비선점형 스케줄링: 한번 CPU에 올라간 task는 끝날 때까지 쫓겨나지 않는 방식
- 비선점형 scheduling은 사용되지 않는다.
- 사용자가 우선순위를 정해야 한다.
- Rate Monotonic Scheduling: Task 주기가 짧다는 것은 빈번하게 실행되는 것이므로 급한 일이라는 의미이다. 급한 task에 더 높은 우선순위를 준다.
- OSEK: 독일에서 개발된 표준 실시간 운영체제
- 소스코드가 공개되어 있으므로 내부 구조를 이해할 수 있다.
- Autosar: 전 세계 많은 기업들이 참여하여 세계 표준으로 사용하고 있다.
- 목적: 하드웨어가 바뀌더라도 응용소프트웨어는 변경하지 않도록 한다.
- 소프트웨어가 특정 ECU 하드웨어에 종속되지 않고 독립된 제품이 될 수 있다.
- 소프트웨어 설계와 구현 단계를 명확히 구분한다.
Hi, there 👋