LDF 파일 분석하기 (Nodes, Signals, Frames, Schedule Tables 실무 예제)

지금까지는 LDF(LIN Description File)가 무엇인지와 어떤 역할을 하는지 알아봤다.

이번에는 실제 LDF 파일을 예제로 사용하여 각 항목이 어떤 의미를 가지는지 하나씩 분석해 보자.

 

이번 예제는 실제 프로젝트와 동일한 형태로 구성한 예시 LDF이며,

보안을 위해 ECU 이름과 Signal은 이해하기 쉽도록 재구성하였다.

 

LDF를 처음 접하는 사람이라면 전체 구조를 이해하는 것만으로도 프로젝트를 훨씬 쉽게 분석할 수 있다.

 

참고

아래 예제는 실제 차량 프로젝트의 LDF가 아니라, 실무에서 사용하는 문법과 구조를 그대로 반영하여 새롭게 구성한 예제이다.

 

LDF 전체 구조 (예제 LDF 파일)

 

일반적인 LDF는 다음과 같은 구조를 가진다.

LIN_description_file;
LIN_protocol_version = "2.2A";
LIN_language_version = "2.2";
LIN_speed = 19.2 kbps;

Nodes {
    Master : PTG_Master, 10 ms, 0.1 ms;
    Slaves : LatchActuator, HallSensor, LampController;
}

Signals {
    TailgateCmd      : 2, 0, PTG_Master, LatchActuator;
    TailgateState    : 4, 0, LatchActuator, PTG_Master;
    HallPosition     : 8, 0, HallSensor, PTG_Master;
    MotorCurrent     : 8, 0, LatchActuator, PTG_Master;
    LampStatus       : 2, 0, LampController, PTG_Master;
    WakeupRequest    : 2, 0, HallSensor, PTG_Master;
}

Frames {
    PTG_CommandFrame : 0x10, PTG_Master, 8 {
        TailgateCmd, 0;
    }
    PTG_StatusFrame : 0x12, LatchActuator, 8 {
        TailgateState, 0;
        MotorCurrent, 8;
    }
    PTG_PositionFrame : 0x14, HallSensor, 8 {
        HallPosition, 0;
        WakeupRequest, 8;
    }
    PTG_LampFrame : 0x16, LampController, 8 {
        LampStatus, 0;
    }
}

Schedule_tables {
    NormalSchedule {
        PTG_CommandFrame delay 10 ms;
        PTG_StatusFrame delay 10 ms;
        PTG_PositionFrame delay 10 ms;
        PTG_LampFrame delay 10 ms;
    }
}

 

실제 프로젝트에서는 파일 길이가 수백 줄에서 수천 줄에 이르지만, 대부분 위와 같은 구조로 작성되어 있다.

 

이제 하나씩 살펴보자.

 

① LDF Header

가장 위에는 LDF 파일의 기본 정보가 정의된다.

LIN_description_file;
LIN_protocol_version = "2.2A";
LIN_language_version = "2.2";
LIN_speed = 19.2 kbps;

 

여기서는 사용하는 LIN Protocol Version, LDF 문법 버전, 통신 속도(Baud Rate) 등을 정의한다.

실무에서는 가장 먼저 LIN 속도가 ECU 사양과 일치하는지 확인하는 경우가 많다.

 

② Nodes

Nodes 영역에는 LIN 네트워크에 참여하는 ECU가 정의된다.

Nodes {
    Master : PTG_Master, 10 ms, 0.1 ms;
    Slaves : LatchActuator, HallSensor, LampController;
}

 

Master는 Header를 전송하고,

각 Slave는 자신의 PID가 요청될 때만 Response를 전송한다.

 

즉, Nodes는 누가 LIN 통신에 참여하는가를 정의하는 영역이다.

 

③ Signals

Signals는 ECU가 실제로 주고받는 데이터를 정의한다.

Signals {
    TailgateCmd      : 2, 0, PTG_Master, LatchActuator;
    TailgateState    : 4, 0, LatchActuator, PTG_Master;
    HallPosition     : 8, 0, HallSensor, PTG_Master;
    MotorCurrent     : 8, 0, LatchActuator, PTG_Master;
    LampStatus       : 2, 0, LampController, PTG_Master;
    WakeupRequest    : 2, 0, HallSensor, PTG_Master;
}

 

위의 예제로는

• TailgateCmd → 트렁크 개방 명령
• TailgateState → 현재 트렁크 상태
• HallPosition → 홀 센서 위치
• MotorCurrent → 모터 전류
• LampStatus → 램프 상태
• WakeupRequest → Wakeup 요청

등이 Signal이다.

 

Signal에는 Bit Length, Initial Value, Publisher, Subscriber 정보도 함께 포함된다.

 

④ Frames

LIN에서는 여러 Signal을 하나의 Frame으로 묶는다.

예를 들어

Frames {
    PTG_StatusFrame : 0x12, LatchActuator, 8 {
        TailgateState, 0;
        MotorCurrent, 8;
    }
}

 

이 Frame에는 TailgateState, MotorCurrent 두 개의 Signal이 포함되어 있다.

Master는 Header에서 PID 0x12를 전송하고,

LatchActuator는 이 Frame의 데이터를 Response로 전송한다.

 

즉, Frame은 여러 Signal을 하나의 LIN 메시지로 묶은 단위라고 이해하면 된다.

 

⑤ Schedule Tables

Schedule Table은 Master가 어떤 순서로 Header를 전송할지를 정의한다.

Schedule_tables {
    NormalSchedule {
        PTG_CommandFrame delay 10 ms;
        PTG_StatusFrame delay 10 ms;
        PTG_PositionFrame delay 10 ms;
        PTG_LampFrame delay 10 ms;
    }
}

 

이를 시간 순서로 표현하면 다음과 같다.

0 ms
PTG_CommandFrame
     ↓
10 ms
PTG_StatusFrame
     ↓
20 ms
PTG_PositionFrame
     ↓
30 ms
PTG_LampFrame
     ↓
40 ms
다시 PTG_CommandFrame

 

즉,

0ms Header(Command)

10ms 후 Header(Status)

10ms 후(누적 20ms) Header(Position)

10ms 후(누적 30ms) Header(Lamp)

10ms 후(누적 40ms) 다시 처음으로 돌아간다.

 

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

 

실제 LIN 통신과 연결해 보기

 

위 LDF를 실제 통신 흐름으로 표현하면 다음과 같다.

이처럼 LDF에 정의된 Frame과 Schedule Table이 실제 LIN Bus의 통신 순서를 결정한다.

 

실무에서 LDF를 분석하는 순서

 

실무에서는 LDF를 처음 열었을 때 대부분 다음 순서로 확인한다.

1. Header (Protocol, Speed)

2. Nodes

3. Signals

4. Frames

5. Schedule Tables

6. Node Attributes

7. Diagnostic Frames

8. Signal Encoding

 

이 순서대로 살펴보면

• 어떤 ECU가 존재하는지
• 어떤 Signal을 사용하는지
• 어떤 Frame으로 송수신하는지
• 몇 ms마다 통신하는지

를 빠르게 파악할 수 있다.

 

정리

 

LDF 파일은 단순한 설정 파일이 아니라 LIN 네트워크 전체를 정의하는 설계 문서이다.

 

Nodes에서는 통신에 참여하는 ECU를 정의하고, Signals에서는 실제 데이터를 정의한다. 또한 Frames에서는 여러 Signal을 하나의 LIN Frame으로 구성하며, Schedule Table에서는 Master가 어떤 순서와 주기로 Header를 전송할지 정의한다.

 

실제 프로젝트에서도 새로운 LIN ECU를 추가하거나 Signal을 변경할 때는 대부분 LDF 수정부터 시작한다.