진단 통신을 하다 보면 한 번쯤은 이해되지 않는 순간을 마주하게 된다.
세션을 변경했을 뿐인데 통신이 끊기거나, 방금까지 풀려 있던 Security가 다시 잠기고,
정상적으로 동작하던 기능이 갑자기 멈추는 상황이다.
이런 문제들은 대부분 하나의 지점으로 수렴한다.
바로 ISO 14229에서 정의하는 DiagnosticSessionControl (0x10)이다.
이 서비스는 단순히 “세션을 바꾸는 기능”처럼 보이지만, 실제로는 ECU 내부 상태를 크게 뒤흔드는 동작이다.
이걸 단순 상태 전환으로 이해하면, 이후 발생하는 문제들을 설명할 수 없게 된다.
1. Diagnostic Session이란 무엇인가
ISO 14229에서는 ECU가 항상 하나의 진단 세션을 유지하도록 정의하고 있다.
이 세션은 ECU가 어떤 수준의 진단 기능을 허용할지를 결정하는 기준이다.
우리가 흔히 사용하는 Default, Extended, Programming 세션은 단순한 이름이 아니라,
ECU의 동작 범위를 제한하거나 확장하는 역할을 한다.
세션이 바뀌면 가능한 서비스뿐만 아니라 통신 타이밍, 보안 상태, 내부 이벤트 처리 방식까지 영향을 받는다.
결국 세션은 하나의 모드라기보다는 ECU의 동작 환경 전체를 정의하는 기준이다.
2. DiagnosticSessionControl의 역할
DiagnosticSessionControl은 ISO 14229에서 정의된 핵심 서비스 중 하나로, ECU의 진단 세션을 변경하는 역할을 한다.
하지만 이 동작을 단순한 상태 변경으로 이해하면 실제 동작과 어긋난다.
세션이 변경되는 순간 ECU 내부에서는 기존 상태가 유지되는 것이 아니라,
일부는 초기화되고 일부는 유지되는 재구성 과정이 발생한다.
이 때문에 세션 변경 이후에는 이전과 동일한 조건이라고 가정하면 안 된다.
즉, 이 서비스는 “세션 변경”이라기보다 ECU 상태 재구성 트리거라고 보는 것이 더 정확하다.
3. 반드시 알아야 할 기본 규칙
ISO 14229 기준으로 보면 세션 동작에는 몇 가지 중요한 규칙이 있다.
ECU는 항상 하나의 세션만 유지하며, 전원이 켜지면 Default Session으로 시작한다.
다른 세션이 요청되면 기존 세션은 종료되고 새로운 세션으로 전환된다.
또한 같은 세션을 다시 요청하는 경우에도 내부적으로는 해당 세션이 재초기화된다.
이 때문에 이전에 설정했던 값이나 이벤트가 사라지는 현상이 발생한다.
세션 변경 시 응답 순서도 중요하다. ECU는 새로운 세션의 타이밍을 적용하기 전에 먼저 Positive Response를 전송한다.
이 구조는 실제 CANoe 분석 시 타이밍 문제를 이해하는 데 중요한 기준이 된다.
마지막으로 non-default 세션은 default 세션의 기능을 포함하는 확장 구조로 정의되어 있다.
즉, 기능이 교체되는 것이 아니라 추가되는 구조다.
4. 세션 전환 시 내부 동작 (핵심)
세션 전환에서 가장 중요한 부분은 ECU 내부 상태가 어떻게 변화하는지다.
이 내용 역시 ISO 14229에 명확하게 정의되어 있다.
이 내용을 이해하기 가장 좋은 방법은 “세션 천이 흐름”을 기준으로 보는 것이다.
이제 각 전환 상황을 흐름으로 보면 이해가 쉽다.
Default Session에서 다시 Default Session을 요청하면, ECU는 현재 상태를 유지하지 않고 세션을 완전히 재초기화한다.
이전에 설정했던 값이나 이벤트는 사라지고 초기 상태로 돌아간다. 단, 비휘발성 메모리에 저장된 값은 유지된다.
Default Session에서 Extended 같은 다른 세션으로 전환할 경우에는 일부만 초기화된다. 특히 ResponseOnEvent로 설정된 이벤트가 제거되는데, 이로 인해 이벤트 기반 응답이 갑자기 사라지는 경우가 발생한다.
Extended와 같은 non-default 세션 간 전환에서는 더 주의가 필요하다. 세션은 재초기화되면서 보안 상태는 다시 잠기고 이벤트는 삭제되지만, 통신 제어 상태나 DTC 설정, 주기적 스케줄러는 그대로 유지된다. 이 “부분 유지” 특성 때문에 문제 원인을 찾기 어려워진다.
마지막으로 non-default 세션에서 Default로 돌아오면 거의 모든 상태가 초기화된다. 보안은 다시 잠기고, 이벤트와 스케줄러는 제거되며, 통신 상태와 DTC 설정도 기본값으로 돌아간다. 사실상 초기 상태로 복귀하는 과정이다.
4. 세션별 허용 서비스 구조 (ISO 14229 기준)
진단 세션에 따라 사용할 수 있는 서비스는 ISO 14229에서 명확하게 정의되어 있다.
아래 표는 defaultSession과 non-defaultSession에서 허용되는 서비스 범위를 보여준다.
표를 보면 항목이 많아 복잡해 보이지만, 실제 구조는 하나의 기준으로 정리된다.
Default Session은 기본적인 진단만 수행할 수 있는 상태다.
DTC 조회나 일부 데이터 읽기 같은 기능은 가능하지만, ECU의 상태를 변경하거나 시스템에 영향을 주는 작업은 대부분 제한된다. 즉, 차량이 정상 동작 중인 상황에서도 안전하게 수행할 수 있는 수준의 기능만 열려 있는 상태다.
반대로 non-default 세션(Extended, Programming 등)으로 전환되면 제약이 풀리기 시작한다.
CommunicationControl, RoutineControl, Download/Upload와 같은 기능들이 이 구간에서 활성화되며,
ECU의 동작이나 데이터를 직접 변경할 수 있는 작업이 가능해진다.
이 구조를 이해할 때 가장 중요한 기준은 다음과 같다.
“영향도가 큰 기능일수록 non-default 세션에서만 허용된다”
여기서 한 단계 더 중요한 개념이 있다.
많은 서비스는 단순히 세션만 변경했다고 해서 바로 사용할 수 있는 것이 아니다.
ISO 14229에서는 일부 서비스에 대해 SecurityAccess를 함께 요구하도록 정의하고 있다.
예를 들어 특정 데이터 읽기/쓰기, 메모리 접근, Routine 실행과 같은 기능은
세션 변경 이후에도 반드시 보안 해제 과정을 거쳐야 한다.
즉, 실제 동작 구조는 다음과 같이 이해하는 것이 맞다.
- 세션 변경 (DiagnosticSessionControl)
- 보안 해제 (SecurityAccess)
이 두 단계를 모두 통과해야 실제 기능이 정상적으로 동작한다.
마지막으로 non-default 세션은 단순히 기능이 확장되는 상태가 아니라,
ISO 14229에서 정의된 세션 타이머에 의해 관리된다.
즉, 일정 시간 동안 클라이언트의 요청이 없으면 ECU는 자동으로 defaultSession으로 복귀한다.
이 동작을 유지하기 위해 TesterPresent(0x3E)를 주기적으로 전송해야 하며,
이 과정을 놓치면 세션이 유지되지 않는 문제가 발생한다.
5. 실무에서 자주 터지는 문제
실무에서 발생하는 문제들은 대부분 ISO 14229의 이 세션 전환 규칙을 놓쳐서 발생한다.
세션을 변경하면 Security가 유지될 것이라고 생각하기 쉽지만, 실제로는 다시 잠기는 경우가 많다.
이걸 고려하지 않으면 SecurityAccess를 반복 요청하는 상황이 발생한다.
또한 이전 세션에서 통신을 꺼놓은 상태라면, 세션이 바뀌어도 그 상태가 유지될 수 있다.
이 때문에 통신이 안 되는 원인을 세션 문제로 착각하는 경우가 많다.
ResponseOnEvent로 설정한 이벤트가 사라지는 것도 흔한 문제다.
세션 전환 시 이벤트는 초기화되기 때문에 다시 설정하지 않으면 응답이 오지 않는다.
그리고 non-default 세션은 타이머 기반으로 유지되기 때문에
TesterPresent를 보내지 않으면 자동으로 Default Session으로 복귀한다.
이 흐름을 놓치면 세션 유지가 안 되는 문제를 겪게 된다.
정리
ISO 14229에서 정의하는 DiagnosticSessionControl은 단순한 기능이 아니다.
ECU 내부 상태를 초기화하고 재구성하는 중심 역할을 한다.
세션 전환 시 어떤 상태가 초기화되고 어떤 상태가 유지되는지를 정확히 이해해야
실제 통신 문제를 제대로 분석할 수 있다.
"세션 변경은 모드 전환이 아니라 ECU 상태를 다시 구성하는 과정이다."
'AUTOSAR' 카테고리의 다른 글
| AUTOSAR DCM - Diagnostic Request 처리 흐름 완전 이해 (DSL → DSD → DSP + 전체 흐름) (0) | 2026.04.28 |
|---|---|
| AUTOSAR 통신 모듈 관계도 완전 정리: CAN Stack 구조와 계층별 역할 이해 (0) | 2026.04.27 |
| AUTOSAR 통신 제어 구조 완전 정리: ComM, CanSM, CanNm, BswM 역할 이해 (0) | 2026.04.27 |
| AUTOSAR Runnable과 Event 관계 완전 이해 (0) | 2026.04.23 |
| AUTOSAR 초보자를 위한 E2E Protection (통신 보호) 완벽 정리 (0) | 2026.04.22 |
