'NvM', 'NvM에 저장', 'NvM에서 읽어서' 등등 NvM에 대해 언급은 하루에도 몇번씩 하고 있죠?
하지만 NvM이 무슨 뜻인지 정확히 알고계신가요?
"Flash 같은거 아닌가요?" "ROM 같은거 아닌가요?" "장기기억장치요"라고 말하고 있진 않은가요?
위처럼 간접적인 정답을 외쳤다면, 오늘 저와 함께 다시 제대로 정립해 봅시다
NvM이란?:
- 자동차의 시동을 껐다 켜도 엔진 맵은 유지돼야 함
- 고장이 났을 때 DTC가 저장되어 있어야 함
- 설정값들이 영구 보존되어야 함
이 모든 게 가능한 이유?
NvM이 있기 때문이죠.
이 글에서는 NvM이 정확히 뭔지, 왜 필요한지, 어떻게 작동하는지 상세히 설명해볼거예요
면접에서도 되게 자주 묻고 자주 나오는 모듈이니까 완벽히 이해해봅시다!
레츠고~
📚 NvM이란?
NvM의 정의
NvM = Non-Volatile Memory Manager
자동차 ECU의 플래시 메모리(Flash)와 EEPROM에 데이터를 안전하게 저장하고 읽는 매니저예요.
매니저의 개념이라는 것을 잘 기억해두셔야해요. BSW와 관련된 부분은 M이 대문자로 뒤에 붙게되는데 이럴경우엔 모두 Manager의 개념으로 구체화 하셔야해요 아까 도입부에 질문에 대한 대답을 예시와 같이 생각했다면 여기에 BreakPoint를 두고 다시 재정립하는 시간을 잠시!
Flash와 EEPROM을 알고 있다는 가정하에 그보다 한단계 깊이 들어왔어요 모르고 있다고요 ? 밑에 내용을 보면 어느정도 감이 잡히실거예요. 지금이에요 기억합시다
왜 "Non-Volatile"이 중요한가?
Volatile Memory (휘발성):
- RAM (일반적인 메모리)
- 전원이 꺼지면 → 데이터 모두 사라짐!
- 자동차 시동 끔 → 데이터 사라짐
Non-Volatile Memory (비휘발성):
- Flash (플래시 메모리)
- EEPROM (영속적 메모리)
- 전원이 꺼져도 → 데이터 유지됨!
- 자동차 시동 다시 켜면 → 데이터 그대로!
그래서 NvM이 필요한 거죠
시트 모듈에 자신의 시트 위치 정보를 저장해뒀는데
시동을 껐다켰더니 초기화 됐다면.. 난감하겠죠
자동차에 탈때마다 의자가 저장위치로 이동하는건 NvM 덕분입니다
엔진 제어를 위한 다차원 데이터:
온도 → RPM → 분사량
┌──────────────────────┐
│ -40℃ (추운 아침) │
│ RPM: 1000 → 분사: 8.5mg
│ RPM: 2000 → 분사: 9.2mg
│ RPM: 3000 → 분사: 10.1mg
│ │
│ 20℃ (일반 온도) │
│ RPM: 1000 → 분사: 8.0mg
│ RPM: 2000 → 분사: 8.8mg
│ RPM: 3000 → 분사: 9.5mg
│ │
│ 50℃ (더운 여름) │
│ RPM: 1000 → 분사: 7.5mg
│ RPM: 2000 → 분사: 8.2mg
│ RPM: 3000 → 분사: 8.8mg
└──────────────────────┘
크기: 약 50KB ~ 200KB
저장 위치: 플래시 메모리 특정 영역
용도: 엔진 제어 SWC에서 주기적으로 읽음
2️⃣ 설정값 (Configuration)
사용자 및 제조사 설정:
- 최대 RPM 제한: 6500
- 최대 토크: 380 Nm
- 연료 옥탄가: 95
- 배출가스 기준: Euro 6
- 언어 설정: 한국어
- 주행 모드: ECO / NORMAL / SPORT
크기: 약 1KB ~ 10KB
용도: 시동 시 한 번 읽고, 사용자 설정 변경 시 갱신
3️⃣ 오류 로그 (DTC - Diagnostic Trouble Code)
고장 이력:
P0117: 엔진 냉각수 온도 센서 저전압
├─ 첫 발생: 2025-01-15 14:32
├─ 발생 횟수: 3회
├─ 마지막 발생: 2025-01-20 09:15
└─ 관련 파라미터:
├─ 온도 센서 전압: 0.1V (정상: 0.5V)
└─ 엔진 RPM: 2000
P0500: 차량 속도 센서 오류
├─ 첫 발생: 2025-01-10 16:45
├─ 발생 횟수: 1회
└─ 상태: 해결됨 (센서 재부팅)
크기: 약 5KB ~ 20KB
저장 방식: 순환 버퍼 (최대 50개 오류 로그)
중요성: 매우 높음 (정비소 진단의 핵심)
4️⃣ 학습 데이터 (Learning Data)
자동차 사용 패턴에 따른 최적화:
- 가속 페달 응답성 학습
- 변속 시점 최적화
- 연비 최적화 파라미터
- 브레이크 마모도 추정
- 배터리 건강도 변화 추적
예시: 연비 학습
초기 분사량: 10.0 mg/cycle
User1 첫 주행: 연비 10.2 km/L
→ NvM: 분사량 9.8 mg/cycle로 학습 저장
→ 다음 주행: 연비 10.5 km/L (개선!)
크기: 약 2KB ~ 5KB
업데이트: 매 주행 후 또는 운행 중 지속적으로
목적: 연비 개선, 성능 최적화
일반 데이터 저장:
플래시 주소 0x1000 ~ 0x1100: 엔진 맵
Critical 데이터 저장 (DTC, 설정):
플래시 주소 0x2000 ~ 0x2100: DTC 원본 + CRC
플래시 주소 0x3000 ~ 0x3100: DTC 백업 + CRC
플래시 주소 0x4000 ~ 0x4100: DTC 백업2 + CRC
읽기 과정:
1. 원본 읽음 + CRC 확인
2. 만약 CRC 실패:
→ 백업1 읽음 + CRC 확인
→ 여전히 실패: 백업2 읽음 + CRC 확인
3. 하나라도 정상 → 그 데이터 사용!
장점:
- 데이터 손상해도 복구 가능
- 신뢰성 극대화
3️⃣ Journal (저널) 관리
쓰기 중 전원이 꺼져도 안전하게 처리
일반적 쓰기 문제:
시간 ──────────────────────→
[쓰기 시작] → [쓰기 중...] → [쓰기 완료]
↑
전원 꺼짐! (데이터 반절만 저장됨)
→ 데이터 손상!
NvM의 Journal 방식:
1단계: 새 데이터를 Journal 영역에 씀
"새 엔진맵 0x5000 ~ 0x5100에 쓰기 시작"
2단계: Journal 완료 플래그 설정
"Journal 쓰기 완료 ✓"
3단계: 실제 데이터 영역에 씀
"플래시 0x1000 ~ 0x1100 쓰기"
4단계: 완료 플래그 설정
"실제 쓰기 완료 ✓"
전원 꺼지면:
- 중간에 꺼짐 → Journal 있으니 복구 가능
- 안전한 이전 데이터 유지!
4️⃣ Wear Leveling (수명 연장)
플래시는 쓰기 횟수 제한이 있음
플래시 수명:
- 일반 플래시: 10,000 ~ 100,000 쓰기
- 고급 플래시: 1,000,000 쓰기
문제:
같은 주소에만 계속 쓰면 빨리 망가짐!
예: DTC를 매번 0x2000에 쓰면?
- 주행 1일: 100회 쓰기 → 10,000회 / 100 = 100일 수명!
- 너무 짧음!
Wear Leveling 솔루션:
DTC를 여러 주소에 돌아가며 씀:
주행 1: 0x2000에 쓰기
주행 2: 0x2100에 쓰기
주행 3: 0x2200에 쓰기
...
주행 100: 0x2000에 다시 쓰기 (1차 부위가 이미 복구됨)
결과:
- 플래시 수명 100배 연장!
- 자동차 전체 수명 동안 안심!
📡 NvM API (Application Programming Interface)
주요 API들
1️⃣ NvM_ReadBlock
─────────────────────────
목적: 플래시에서 데이터 읽기
선언:
Std_ReturnType NvM_ReadBlock(
NvM_BlockIdType BlockId,
void* NvM_DestPtr
);
사용 예:
uint8 engineMap[200];
NvM_ReadBlock(NvMBlock_EngineMap, engineMap);
반환값:
E_OK → 읽기 성공
E_NOT_OK → 읽기 실패 (CRC 오류 등)
시간: 약 10~50ms (플래시 크기에 따라)
2️⃣ NvM_WriteBlock
─────────────────────────
목적: 플래시에 데이터 쓰기
선언:
Std_ReturnType NvM_WriteBlock(
NvM_BlockIdType BlockId,
const void* NvM_SrcPtr
);
사용 예:
uint8 newSettings[10] = {...};
NvM_WriteBlock(NvMBlock_Settings, newSettings);
반환값:
E_OK → 쓰기 성공
E_NOT_OK → 쓰기 실패
특징:
- 비동기 호출 (즉시 반환하고 백그라운드에서 처리)
- 쓰기 완료까지 약 20~100ms
3️⃣ NvM_EraseNvBlock
─────────────────────────
목적: 특정 블록 삭제 (초기화)
사용 예:
NvM_EraseNvBlock(NvMBlock_DTC_Log);
// DTC 로그 전부 삭제
용도:
- 정비소에서 고장 코드 삭제
- 공장 초기화
- 개인정보 보호 (판매 전)
4️⃣ NvM_InvalidateNvBlock
─────────────────────────
목적: 블록 무효화 (읽기 불가)
사용 예:
NvM_InvalidateNvBlock(NvMBlock_LearningData);
// 학습 데이터 무효화
특징:
- 데이터는 지우지 않지만 읽을 수 없게 함
- CRC 갱신으로 구현
5️⃣ NvM_GetErrorStatus
─────────────────────────
목적: 작업 상태 확인
사용 예:
uint8 status;
NvM_GetErrorStatus(NvMBlock_EngineMap, &status);
반환 상태:
NVM_REQ_PENDING → 작업 진행 중
NVM_REQ_OK → 완료 (성공)
NVM_REQ_FAILED → 완료 (실패)
NVM_REQ_CANCELLED → 작업 취소됨
🔄 NvM의 실제 작동 흐름
시나리오 1: 엔진 맵 저장 (첫 시동)
시간: 0ms (시동 직후)
┌────────────────────────────────┐
│ EngineControlSWC │
│ "엔진 맵 필요해!" │
└────────────────┬───────────────┘
│
▼
┌────────────────────────────────┐
│ NvM_ReadBlock(EngineMap_Block) │
│ (RTE를 통한 호출) │
└────────────────┬───────────────┘
│
▼
┌────────────────────────────────┐
│ NvM 내부 처리 │
│ 1. Fee에서 플래시 영역 할당 │
│ 2. 0x1000 ~ 0x1100 읽기 │
│ 3. CRC 계산 │
│ 4. 저장된 CRC와 비교 │
│ → 일치! ✓ │
│ 5. 데이터 준비 │
└────────────────┬───────────────┘
│
▼
┌────────────────────────────────┐
│ EngineControlSWC │
│ engineMap[] = {...} 수신 │
│ "완벽해! 시작합니다!" │
└────────────────────────────────┘
시간: 50ms (엔진 제어 시작)
이후 매 10ms마다 엔진맵 참조!
BLOCK-ID: 블록의 고유 ID (API에서 사용)
BLOCK-SIZE: 블록 크기 (바이트)
BLOCK-MANAGEMENT-TYPE:
- STANDARD: 기본 관리
- REDUNDANT: 중복 저장 (중요한 데이터)
CRC-MECHANISM: CRC32 (오류 검증)
NvM: "20KB 블록을 저장해줄래?"
Fee: "그래! 내가 플래시 영역 관리할게"
Fee의 역할:
- 플래시 주소 할당 (0x1000 ~ 0x1100)
- Wear Leveling 구현
- 플래시 지우기/쓰기 처리
NvM과 Fee의 관계:
NvM: "높은 수준의 논리 (데이터 관리)"
Fee: "낮은 수준의 물리 (플래시 제어)"
🎯 면접 예상 질문 10가지
Q1: NvM이 뭔지 알고 있나요?, 알고있다면 왜 필요해요?
A: "NvM은 플래시/EEPROM에 데이터를 안전하게
저장하는 매니저입니다. 시동을 껐다 켜도
엔진맵, DTC, 설정값이 유지되어야 하기 때문입니다."
Q2: CRC 검증이 뭐예요?
A: "데이터가 손상되지 않았는지 확인하는 방법입니다.
쓸 때 CRC를 계산해 저장하고, 읽을 때 다시
계산해서 비교합니다. 플래시 열화로 인한
손상을 감지할 수 있습니다.(결정타)"
Q3: Redundancy가 뭐고, 어디에 쓰나요?
A: "중요한 데이터를 여러 번 저장하는 방식입니다.
DTC나 설정값처럼 절대 잃으면 안 되는 데이터를
3군데 저장해서, 하나가 손상되면 다른 곳에서 복구합니다."
Q4: Journal은 어떻게 작동하나요?
A: "쓰기 중 전원이 꺼져도 데이터 안전성을 보장합니다.
Journal에 먼저 쓰고, 완료 플래그 설정한 후,
실제 영역에 쓰는 3단계 방식입니다."
Q5: Wear Leveling이 필요한 이유는?
A: "플래시는 쓰기 횟수 제한이 있습니다. 같은 주소에만
계속 쓰면 빨리 망가지니까, 여러 주소에 돌아가며
씁니다. 플래시 수명을 100배 이상(킥 : 상세한 숫자) 연장할 수 있습니다."
Q6: NvM_ReadBlock과 NvM_WriteBlock의 차이는?
A: "ReadBlock은 플래시에서 RAM으로 읽기,
WriteBlock은 RAM에서 플래시로 쓰기입니다.
둘 다 비동기로 작동하고, NvM_GetErrorStatus로
완료를 확인합니다."
Q7: DTC는 언제, 누가 저장하나요?
A: "Dem (Diagnostic Event Manager)이 고장을 감지하면
DTC를 생성합니다. Dem이 NvM_WriteBlock을 호출해
플래시에 저장합니다."
Q8: 엔진맵은 얼마나 자주 읽나요?
A: "시동 직후 한 번 읽어서 RAM에 복사하고,
이후 10ms마다 실행되는 EngineControl_Runnable이
RAM의 엔진맵을 참조합니다. 매번 플래시를 읽지 않습니다."
(엔진맵과 관련됐을경우 물어볼 질문)
Q9: NvM_EraseNvBlock은 언제 호출되나요?
A: "정비소에서 고장 코드를 삭제할 때 호출됩니다.
Dcm (진단 통신)이 정비기 명령을 받으면
NvM_EraseNvBlock을 호출해 DTC를 초기화합니다."
Q10: NvM이 없으면 어떻게 되나요?
A: "엔진맵이 매번 RAM에 갱신되어야 하고, DTC가
다음 시동에 사라지고, 학습 데이터도 유지 안 됩니다.
자동차 성능과 신뢰성이 크게 떨어집니다."
정리: NvM의 핵심
항목
설명
정의
플래시/EEPROM 메모리 관리자
저장 데이터
엔진맵, DTC, 설정값, 학습 데이터
CRC 검증
데이터 손상 감지
Redundancy
중요 데이터 중복 저장
Journal
쓰기 중 전원 차단 대비
Wear Leveling
플래시 수명 연장
주요 API
ReadBlock, WriteBlock, EraseNvBlock
특징
비동기 작동, 신뢰성 극대화
마치며
이제 NvM이 어떻게 데이터를 안전하게 저장하는지 명확해졌나요?
코드 상으로만 바라본다면 어어 이거지 이거지 하고 다 알았겠죠
하지만 직접 개념을 글로 정의하고 설명하는 것은 또다른 개념입니다.
알고 있는 것을 표현하기엔 어렵죠
NvM도 그럴 거예요
실무자라 하더라도 막상 뭐냐고 물으면 "어.. 아는건데 맨날 쓰는 건데..
코드로는 설명할 수 있는데" 라고 대답하게 되죠
이 기회에 다시 한번 복습하는 기회를 갖게 됐다면 좋겠습니다.
다음 포스팅에서는 이번 게시물에 계속 등장한 DTC에 관해 설명해보려고합니다.
센서 고장을 어떻게 알지? DTC는 누가 만들지?
"AUTOSAR Dem 완벽 이해: 오류 감지와 DTC 관리의 모든 것"을 주제로 포스팅해보겠습니다.
