본문 바로가기
반응형

전체 글181

AUTOSAR 경력 1~3년차 개발자 면접 예상 질문 및 답변 20선 자동차 전장 SW 개발자로 이직이나 경력 면접을 준비하다 보면 AUTOSAR 관련 기술 질문을 피하기 어렵습니다. 이번 글에서는 AUTOSAR 기반 ECU SW 개발 경험을 기준으로, 경력 1~3년차 개발자가 면접 전에 준비해두면 좋은 질문과 답변을 정리해보겠습니다. 답변은 실제 면접에서 너무 길게 설명하지 않고, 본인의 경험에 맞게 추가 설명을 이어갈 수 있는 정도의 분량으로 작성했습니다. 1. AUTOSAR가 무엇인지 설명해주세요. AUTOSAR는 자동차 ECU 소프트웨어의 표준화와 재사용성을 높이기 위한 소프트웨어 아키텍처입니다. Application Software와 Basic Software를 분리하고, 그 사이를 RTE로 연결하는 구조를 가지고 있습니다. 2. AUTOSAR의 BSW.. 2026. 9. 16.
AUTOSAR에서 LPA(Low Power Application) Mode란? ECU 저전력 모드의 동작 구조와 Wakeup 이해하기 자동차에는 수많은 ECU가 탑재되어 있다. ECU가 차량이 주행 중일 때처럼 항상 모든 기능을 수행한다면 문제가 없지만, 차량이 주차된 상태에서도 동일한 수준으로 Application과 통신 기능을 계속 실행한다면 배터리 전력 소모가 증가하게 된다. 따라서 차량이 장시간 정차해 있는 상황에서는 ECU의 불필요한 동작을 최소화하고, 필요한 기능만 유지하는 저전력(Low Power) 동작 상태가 필요하다. 이번 글에서는 AUTOSAR 기반 ECU에서 사용되는 LPA(Low Power Application) Mode의 개념과 Normal Mode와의 차이, Wakeup 동작, 그리고 실제 ECU SW를 분석할 때 어떤 부분을 확인해야 하는지 정리한다. 1. LPA Mode란? LPA는 Low Powe.. 2026. 9. 16.
자동차 SW 개발자가 알아야 할 ASPICE란? 개발 프로세스부터 SWE.1~SWE.6까지 자동차 소프트웨어 개발을 하다 보면 한 번쯤 다음과 같은 말을 듣게 된다. "이번 프로젝트는 ASPICE Level 2 대응이 필요하다." "SWE.1 Requirement부터 다시 확인해 주세요." "SWE.2 Architecture와 SWE.3 Design의 Traceability가 연결되어 있나요?" "SWE.4 Unit Test 결과가 필요합니다." "ASPICE Assessment에서 Evidence를 준비해야 합니다." 자동차 SW 개발을 처음 접하는 입장에서는 이런 용어들이 상당히 복잡하게 느껴진다. 특히 ASPICE를 처음 접하면 ASPICE를 하나의 개발 방법론이나 인증 규격이라고 생각하기 쉽다.하지만 정확하게는 자동차 시스템 및 소프트웨어 개발 프로세스의 능력을 평가하기 위한 Pr.. 2026. 9. 10.
[NvM] ECU 초기화 NvM_Init()부터 NvM_ReadAll(), NvM_WriteAll()까지 AUTOSAR 기반 ECU 소프트웨어를 개발하다 보면 다음과 같은 함수를 보게 된다. NvM_Init();NvM_ReadAll();NvM_WriteAll();이름만 보면 어렵지 않아 보인다. NvM_Init() → NvM 초기화 NvM_ReadAll() → 전체 데이터 읽기 NvM_WriteAll() → 전체 데이터 쓰기 그런데 실제 프로젝트에서 NvM을 처음 접하면 이런 의문이 생긴다. "도대체 RAM에 있는 데이터와 Flash에 있는 데이터는 어떤 관계인가?" "NvM_ReadAll()은 정확히 언제 호출되지?" "NvM_WriteAll()을 호출하면 바로 Flash에 저장되나?" "데이터가 처음부터 존재하지 않으면 어떻게 되지?" NvM을 이해하려면 API 하나하나를 외우기보다ECU가 켜지고 꺼.. 2026. 9. 9.
자동차 SW 제어기 ECU 빌드 후 생성되는 파일 총정리 — ELF, HEX, SRE, MAP, DLA, DNM, OPT 등등 자동차 ECU 소프트웨어를 개발하다 보면 Build가 끝난 후 여러 종류의 파일이 생성된다. 처음 보면 비슷해 보이지만 각각의 용도가 다르다. 어떤 파일은 ECU에 실제로 다운로드하는 데 사용하고,어떤 파일은 TRACE32 디버깅에 사용하며, 어떤 파일은 메모리 구조나 Link 결과를 확인하는 데 사용한다. 특히 ECU 개발에서는 ELF, HEX, SRE, MAP 정도는 자주 접하게 되므로 각각의 역할을 구분해두는 것이 좋다. 1. 전체적인 흐름 먼저 Build 과정과 생성 파일의 관계를 간단하게 보면 다음과 같다.Source Code (.c / .h) ▼Compiler ▼Object ▼Linker ▼ ELF │ ├─────► MAP ├─────► HEX ├───.. 2026. 9. 8.
Vector XL Driver Library를 이용한 UDS 진단 자동화 Tool 개발 #12 - CSVReader와 DIDParser를 이용한 시험 정보 관리 지난 글에서는 Report 클래스를 구현하여 자동 진단 시험 결과를 CSV 파일로 저장하는 기능을 구현하였다.지금까지 구현한 Application, TestEngine, Report를 통해 ECU와 통신하고 시험 결과를 저장하는 기능은 완성되었다. 하지만 아직 한 가지 중요한 기능이 남아 있다. 자동 진단 프로그램은 ECU 정보와 시험 항목을 코드에 직접 작성하지 않고 CSV 파일에서 읽어와야 하며, ECU 응답에서도 필요한 데이터 영역만 추출하여 해석할 수 있어야 한다. 이번 글에서는 CSVReader 클래스를 구현하여 Target.csv와 DID_LIST.csv를 읽는 방법을 살펴보고, DIDParser 클래스를 이용하여 UDS 응답에서 필요한 데이터 영역을 추출하는 과정을 구현해보겠다. 1. CS.. 2026. 8. 10.
Vector XL Driver Library를 이용한 UDS 진단 자동화 Tool 개발 #11 - Report 클래스 구현 및 시험 결과 CSV 저장 지난 글에서는 TestEngine 클래스를 구현하여 DID_LIST.csv를 기반으로 여러 개의 DID를 자동으로 시험하고, ECU 응답 데이터를 실제 값으로 변환하여 PASS/FAIL을 판정하는 과정을 구현하였다. 각 DID의 시험 결과는 DIDTestCase 객체에 저장되지만, 프로그램이 종료되면 메모리에서 사라지므로 시험 결과를 다시 확인하거나 이력을 관리하기 어렵다. 자동 진단 프로그램에서는 시험 결과를 파일로 저장하여 추후 분석하거나 양산 검사 결과를 관리할 수 있어야 한다. 이번 글에서는 Report 클래스를 구현하여 TestEngine에서 생성한 시험 결과를 CSV 파일로 저장하는 기능을 구현해보겠다. 1. Report 클래스의 역할 이번 프로젝트에서 Report 클래스는 시험이 완.. 2026. 8. 7.
Vector XL Driver Library를 이용한 UDS 진단 자동화 Tool 개발 #10 - TestEngine 구현 및 DID 자동 시험 지난 글에서는 Application Layer를 구현하여 VectorCAN, ISO-TP, UDS, CSVReader, Report 클래스를 하나의 프로그램으로 연결하였다. Application에서는 ECU를 선택하고 Diagnostic Session에 진입한 후 DID 목록을 읽어 자동으로 진단을 수행할 수 있게 되었다. 하지만 아직 실제 시험(PASS/FAIL)을 수행하는 핵심 기능은 구현되지 않았다. DID를 하나씩 읽고 응답 데이터를 해석한 뒤 기대값(Expected Value)과 비교하여 시험 결과를 판정하는 작업이 필요하다. 이번 글에서는 TestEngine 클래스를 구현하여 DID_LIST.csv를 기반으로 여러 개의 DID를 자동으로 시험하고, ECU 응답 데이터를 사람이 읽을 수 있.. 2026. 8. 6.
Vector XL Driver Library를 이용한 UDS 진단 자동화 Tool 개발 #9 - Application Layer 구현 및 ECU 진단 통신 지난 글에서는 UDS 클래스를 구현하여 Diagnostic Session Control(0x10), Tester Present(0x3E), Read Data By Identifier(0x22)와 같은 UDS 서비스를 작성하였다. 이제 UDS Layer까지 구현이 완료되었으므로, Application에서는 CAN Frame이나 ISO-TP Frame을 직접 생성하거나 처리할 필요가 없다. Application은 ECU를 선택하고 진단 서비스를 호출하며, 시험 결과를 저장하는 전체 흐름만 제어하면 된다. 이번 글에서는 지금까지 구현한 VectorCAN, ISO-TP, UDS, CSVReader, TestEngine, Report 클래스를 하나의 프로그램으로 연결하여 실제 ECU와 진단 통신을 수행하는 A.. 2026. 8. 5.
Vector XL Driver Library를 이용한 UDS 진단 자동화 Tool 개발 #8 - UDS 클래스 구현 및 진단 서비스 공통 처리 지난 글에서는 ISO-TP Layer를 구현하여 CAN FD 기반의 진단 데이터를 송수신할 수 있도록 구현하였다. 이제 상위 Layer에서는 CAN Frame이나 ISO-TP Frame을 직접 다룰 필요가 없다. 대신 UDS(ISO 14229)에서 정의한 Diagnostic Service만 생성하면 ISO-TP Layer가 자동으로 CAN Frame을 생성하고 ECU와 통신을 수행하게 된다. 이번 글에서는 UDS 클래스를 구현하여 Diagnostic Session Control(0x10), Tester Present(0x3E), Read Data By Identifier(0x22) 서비스를 작성하고, 모든 UDS Service가 공통으로 사용하는 SendRequest() 함수를 구현해보겠다. 1... 2026. 8. 4.
Vector XL Driver Library를 이용한 UDS 진단 자동화 Tool 개발 #7 - ISO-TP 수신 구현 (Single Frame / Multi Frame 재조립) 지난 글에서는 ISO-TP 송신 기능을 구현하여 Payload 크기에 따라 Single Frame과 First Frame을 생성하는 과정을 살펴보았다.하지만 UDS 통신은 요청(Request)을 전송하는 것만큼 ECU의 응답(Response)을 올바르게 수신하는 과정도 중요하다. 특히 ECU의 응답 데이터가 큰 경우에는 여러 개의 CAN Frame으로 분할되어 전송된 데이터를 하나의 Payload로 다시 조립하는 과정이 필요하다. 이번 글에서는 IsoTp::Receive() 함수를 구현하여 Single Frame과 Multi Frame을 수신하고,여러 개의 CAN Frame을 하나의 Payload로 재조립하는 과정을 구현해보겠다. 1. ISO-TP 수신 과정 ISO-TP 수신 과정은 다음과 같은 순서로.. 2026. 8. 3.
Vector XL Driver Library를 이용한 UDS 진단 자동화 Tool 개발 #6 - ISO-TP 송신 구현 (Single Frame / First Frame) 지난 글에서는 VectorCAN 클래스를 구현하여 CAN FD Frame을 송신하고 수신하는 기능을 구현하였다. 하지만 CAN FD Frame만으로는 실제 UDS 통신을 구현하기에는 한 가지 문제가 있다. CAN FD는 최대 64Byte까지 데이터를 전송할 수 있지만, 진단 데이터의 크기는 이보다 더 큰 경우가 많기 때문이다. 예를 들어 VIN(17Byte)은 하나의 CAN FD Frame으로 전송할 수 있지만, ECU Download나 Firmware Update와 같이 수백 Byte 이상의 데이터는 여러 개의 CAN Frame으로 나누어 전송해야 한다. 이러한 문제를 해결하기 위해 사용하는 프로토콜이 ISO-TP(ISO 15765-2) 이다. 이번 글에서는 IsoTp 클래스를 생성하고 Payl.. 2026. 8. 1.
반응형