LIN Schedule Table이란? Master는 어떻게 통신 순서를 관리할까?

이전 글에서는 LIN이 Single Master / Multiple Slave 구조를 사용하며, 모든 통신은 Master가 시작한다는 것을 알아봤다.

 

그렇다면 또 하나의 궁금증이 생긴다.

Master는 어떤 데이터를 먼저 전송해야 하는지 어떻게 알까?

 

예를 들어 Charging Door ECU가

• Door Lock 상태
• Door Position
• Motor Current
• Error Status

를 모두 확인해야 한다면 어떤 순서로 요청해야 할까?

그 해답이 바로 LIN Schedule Table이다.

 

이번 글에서는 Schedule Table이 무엇이며, Master가 어떻게 통신 순서를 관리하는지 쉽게 알아보자.

 

Schedule Table이란?

 

Schedule Table은 Master가 어떤 PID를 언제 전송할지를 미리 정의한 시간표이다.

쉽게 말하면 학교 시간표처럼 몇 ms마다 어떤 Frame을 전송할지 미리 정해 놓은 것이다.

Master는 이 순서를 반복하면서 LIN Bus를 관리한다.

 

왜 Schedule Table이 필요할까?

 

LIN에서는 Slave가 먼저 데이터를 보낼 수 없다.

따라서 Master가 "Door Lock 상태 보내" → "Door Position 보내"  → "Motor Current 보내"처럼 하나씩 요청해야 한다.

만약 요청 순서가 없다면 어떤 데이터를 언제 읽어야 하는지 알 수 없게 된다.

그래서 Schedule Table이 필요하다.

 

Event 기반 통신과의 차이

 

CAN은 Event 기반 통신을 많이 사용한다.

예를 들어 Door가 열리면 바로 CAN Message를 송신한다.

 

반면 LIN은 다르다.

Door가 이미 열렸더라도 Master가 해당 PID를 요청할 때까지 기다린다.

 

즉, CAN은 "변화가 생기면 바로 알림"

LIN은 "주기적으로 상태를 확인"이라는 차이가 있다.

 

Schedule Table은 하나만 있을까?

 

아니다.

실제 차량에서는 여러 개의 Schedule Table을 사용한다.

 

Schedule Table은 어디에 저장될까?

실무에서는 대부분 LDF(LIN Description File) 안에 정의되어 있다.

 

예를 들어 LDF에는 다음과 같은 형태로 작성된다.

• Schedule Table
• Normal Schedule
• DoorLock Frame
• DoorPosition Frame
• MotorCurrent Frame
• ErrorStatus Frame

실제로 LIN Stack은 이 정보를 이용하여 Header를 자동으로 전송한다.

 

실무에서는 왜 Schedule Table이 중요할까?

 

LIN 통신이 정상적으로 동작하지 않을 때 가장 먼저 확인하는 것 중 하나가 Schedule Table이다.

예를 들어

• Door Position이 갱신되지 않는다.
• 정 PID가 송신되지 않는다.
• Slave가 응답하지 않는다.

이런 문제는 Schedule Table에 Frame이 등록되지 않았거나, 주기가 잘못 설정된 경우가 많다.

따라서 실무에서는 CAN Trace보다 먼저 Schedule Table과 LDF를 확인하는 경우도 많다.

 

정리

 

LIN Schedule Table은 Master가 어떤 Frame을 언제 전송할지를 정의한 시간표이다.

 

Master는 Schedule Table을 기준으로 Header를 순서대로 전송하고, 해당 PID를 담당하는 Slave는 Response를 반환한다.

덕분에 LIN은 Arbitration 없이도 예측 가능한 통신을 수행할 수 있으며, 저렴한 비용으로 안정적인 네트워크를 구성할 수 있다.

다음 글에서는 LDF(LIN Description File)란? 실무에서 가장 많이 사용하는 LIN 설정 파일 이해하기를 통해 Schedule Table을 포함한 LDF 파일 구조를 자세히 살펴보겠다.