본문 바로가기
IVS/마이크로프로세서

마이크로프로세서의 전장시스템 활용

by 코곰_ 2025. 1. 17.

자동차의 전자제어

  • ACC, ABS, TCS, VDC, TPMS 등 기계식 -> 전자식 제어 장치
  • 자동차에 설치된 여러 센서에서 데이터를 받아 ECU에서 연산을 한 뒤 차량 장치를 제어하는 것
  1. Sensor: 차량 속도, 악셀레이터/ 브레이크 페달 각도, 조향 각도, 대기온도
  2. ECU(Eletronic Control Unit)

통신(Communication)

  • 자동차 내 ECU간, 자동차 간, 자동차와 인프라 간의 데이터 교환
  • Telematics = Telecommunication + informatics
    • goal: 통신 delay 감소, cyber security 문제
  • 자동차 통신 네트워크
    • 종류: CAN, CAN-FD, FlexRay, LIN
    • 응용: 차량 상태 원격 진단, 고장시 점검/ 정비소 안내

자동차 관련 표준과 프로세스

  • 자동차 전자제어장치 S/W 표준 구조: AUTOSAR
  • 자동차 S/W 개발 프로세스: ASPICE, CMMI
  • 자동차 전자제어 시스템 기능 안전 규격: ISO26262
  • 코드 추적성 관리, 안정성 관리 = autosar + aspice

모델기반 설계(Model-based Design, MBD)

  • 복잡성, 다양성에 대응할 수 있는 설계 기법
  • 제품 개발 주기 전체 단계에서 적용
  1. 제어 대상(plant)를 모델링(ex.CARSIM)
  2. 제어기를 설계 및 분석(Controller Design), 자동 코드 생성(auto-code generation) -> autosar 규격에 맞게
  3. 제어대상과 제어기를 모의실험(simulation)
  4. 제어기의 적합성을 판단 후 제품에 적용

MBD의 장점

  1. Modeling & Simulation: 새로운/ 개선된 알고리즘 적용시 성능 검증 용이
  2. Human error & human resource 감소: 테스트, 보고서 작성, 코딩 자동화에 따른 인력 감소
  3. 추적성(Traceability) 확보: 요구사항 - 시스템 설계 - 개발 - 테스트
  4. 비용 절감: 개발 프로세스 기간 단축, 개발 초기단계에서 오류 검출

미래자동차 전자제어장치 개발 프로세스

  • 제품 개발 주기 관리: V-model
  • 하드웨어&소프트웨어 개발 각 단계마다 모델 기반 설계 기법 적용, 산출물 문서화

모델기반 설계의 개발 및 테스트 단계

  1. Software-In-the-Loop(SIL)
  • 모델과 제어기를 블록, 소프트웨어로 구현
  • PC상에서 실행 및 검증
  • 장점: 비용이 저렴하게 다양한 환경에서 테스트 가능
  • Tool: MATLAB/Simulink Simscape, Carsim, Carmaker, Prescan, Carla(-> 인공지능 적용 가능)
  1. Hardware-In-the-Loop(HIL)
  • 모델링하기 어렵거나 불가능한 부품 또는 시스템을 하드웨어로 대체
  • SILS 검증 이후 하드웨어 개발품을 실물로 대체
  • ECU HILS(=EILS)
    • 알고리즘 처리 대상: 컴퓨터 -> ECU
    • 컴퓨터와 CPU, Fixed/floating point, structure, interface 차이 존재
  • ECU & Camera HILS
    • 알고리즘 처리 대상: 컴퓨터(SILS) -> ECU(HILS)
    • 인지 데이터: 사전 취득 데이터(SILS) -> 카메라 실시간 취득 데이터(HILS)
  • Tool: prescan, dSPACE
  • 연구자의 재량에 따라 무궁무진하다.
  • 실차와 유사해질수록 비용이 높아짐
  1. Vehicle-In-the-Loop(VIL)
  • 가상환경 기반 실차의 조향, 제동 성능 검증
  • 환경, 운전자 조작 변화에 대한 차량의 조향/ 제동 성능 평가

자동차 산업 구조

  1. OEM: 완성차
  2. Tier1: System, module suppliers (조향, 브레이크, suspension 등)
  3. Tier2: Component suppliers (커넥터, MCU, 프레스, 기계가공품, 철강 등)
  4. Tier3: Parts suppliers(소재, 원자재, S/W Tool, CPU, OS 등)

요구사항 제시 & 분석

  • 고객이 제시한 요구사항 -> 분석 -> 요구사항서 작성

요구사양서

  • 작성 이유
    • 프로젝트 규모 파악
    • 구현 가능 여부 파악
    • 의사소통 시간, 비용 절약
    • 프로젝트 계획 수립
  • 포함 내용
    • 요구사항 버전
    • ID (식별자)
    • 요구사항 요약명, 내용
    • 중요도
    • 요청한 담당자, 날짜
    • 구현 가능 여부 (수용 여부 – 검토예정, 수락, 거부) ▪ 구분 – 새로운 것인지, 수정인지
    • 유형 – 성능, 데이터, 보안, 시스템 기능

제품 제작 단계별 테스트

  • 개발 과정
    • 결함 예방, 결함 발견
    • 개발 프로세스 점검
    • 논리적, 구조적 설계 구현 검증
  • 유지 보수 과정
    • 부분 기능 변경 시 새로 유입되는 결함 확인
    • 기존 기능 유지에 영향성이 없는지 확인
  • 인수 과정
    • 기능 요구사항 충족 확인
    • 제품의 신뢰성, 안정성 평가

테스트 단계

[개발자]

  • 단위 테스트(Unit Test)
    • 테스트 가능한 작은 단위 테스트 (예:C-function)
    • 소프트웨어 내부 구조, 구현 방법 고려
    • 단위 기능이 예상대로 동작하는지 확인
  • 통합 테스트(Integration Test)
    • 단위가 통합된 모듈 테스트
    • 단위간, 외부 입출력과의 Interface 테스트
    • 환경성 (OS, Single/Dual Core 등) 테스트
  • 시스템 테스트(System Test)
    • 시스템을 고객에게 인계 전 테스트
    • 요구사항 기반 작동 검증
    • 동작성 중시
      [고객]
  • 인수테스트
    • 사용자가 시스템 적절성 확인
    • 계약, 규정, 운영 테스트
    • 알파, 베타 테스트

테스트 관련 용어

  • Test case
    ▪ 요구사항 준수 확인을 위한 확인
    ▪ 입력 값, 실행 조건, 실행 방법, 예상 결과를 포함
  • Test coverage
    ▪ 제품이 얼마나 완벽하게(Completely) 테스트 되었나
    ▪ 테스트의 미비점, 누락된 요구사항, 의도하지 않은 기능 정도 분석
  • Black-box test
    ▪ 제품 내부 구조, 원리를 모르는 상태
    ▪ 사용자 관점의 입력-출력 관계 검증
  • White-box test
    ▪ 제품 내부구조, 원리를 아는 상태
    ▪ 개발자 관점의 단위 테스트 검증