자동차 기능안전에서 TSR과 FSR은 무엇일까?

자동차 소프트웨어 개발을 공부하다 보면 어느 순간부터 기능안전(Functional Safety)이라는 단어를 자주 보게 된다.

 

처음에는 CAN, AUTOSAR, DCM, DEM 같은 것들을 공부하는 것만으로도 벅찬데, 프로젝트 문서를 보다 보면 갑자기 HARA, ASIL, Safety Goal, FSR, TSR 같은 용어들이 등장하기 시작한다.

 

특히 FSR과 TSR은 이름도 비슷해서 처음 접하는 사람 입장에서는 거의 같은 의미처럼 느껴지기도 한다.

하지만 실제로는 역할 자체가 다르며, 기능안전 개발 흐름에서 굉장히 중요한 단계에 해당한다.

 

자동차 ECU는 단순히 기능만 정상 동작한다고 끝나는 시스템이 아니다.

오류가 발생했을 때 차량이 위험한 상태로 가지 않도록 만드는 것도 매우 중요하다.

 

예를 들어 모터가 멈춰야 하는 상황에서 계속 동작하거나, 차량 속도를 잘못 판단하거나, 브레이크 관련 신호가 비정상적으로 처리된다면 단순 버그 수준이 아니라 실제 사고로 이어질 수도 있다.

 

이런 위험을 줄이기 위해 사용하는 국제 표준이 바로 ISO 26262 기능안전이다.

 

기능안전 개발은 어떤 흐름으로 진행될까?

 

기능안전 개발은 단순히 “안전하게 만들자” 수준으로 진행되지 않는다.

먼저 시스템에서 어떤 위험이 발생할 수 있는지 분석하는 과정이 필요하다.

이를 HARA(Hazard Analysis and Risk Assessment)라고 부른다.

여기서 차량에 어떤 위험 요소가 존재하는지 분석하고, 그 위험이 얼마나 심각한지 평가하게 된다.

그리고 분석 결과를 기반으로 Safety Goal이라는 안전 목표를 정의한다.

예를 들어 다음과 같은 위험 상황이 있다고 가정해보자.

모터가 의도하지 않게 계속 동작함

 

이 경우 Safety Goal은 보통 다음과 같은 방향으로 정의된다.

의도하지 않은 모터 구동을 방지해야 한다.

 

그리고 바로 여기서부터 FSR과 TSR이 등장하기 시작한다.

 

FSR은 무엇일까?

 

FSR은 Functional Safety Requirement의 약자다.

우리말로는 기능안전 요구사항이라고 부른다.

쉽게 말하면 시스템이 안전을 위해 반드시 수행해야 하는 기능을 정의하는 단계라고 보면 된다.

 

즉 “안전을 위해 무엇을 해야 하는가”를 정의하는 것이다.

 

예를 들어 앞에서 이야기했던 모터 시스템을 계속 생각해보자.

의도하지 않은 모터 구동을 방지해야 한다는 Safety Goal이 존재한다면, 이를 만족시키기 위한 FSR은 다음처럼 정의될 수 있다.

시스템은 비정상 모터 구동을 감지해야 한다.

 

또는

오류 발생 시 시스템은 모터 출력을 차단해야 한다.

이 단계에서는 아직 구현 방법까지 세부적으로 내려오지는 않는다.

어떤 MCU를 사용하는지, 몇 ms마다 검사하는지, 어떤 Fault 로직을 사용하는지 같은 기술적인 내용은 아직 등장하지 않는다.

 

즉, FSR은 비교적 상위 레벨의 요구사항이라고 볼 수 있다.

 

TSR은 무엇일까?

 

TSR은 Technical Safety Requirement의 약자다.

우리말로는 기술 안전 요구사항이라고 부른다.

 

FSR에서 정의했던 내용을 실제 ECU 수준에서 구현 가능하도록 더 구체화한 요구사항이라고 이해하면 된다.

즉, FSR이 “무엇을 해야 하는가”를 정의했다면, TSR은 “그것을 실제로 어떻게 구현할 것인가”에 가까운 개념이다.

 

예를 들어 다음과 같은 FSR이 있다고 해보자.

시스템은 비정상 모터 구동을 감지해야 한다.

 

이 요구사항은 TSR 단계에서 훨씬 구체적인 형태로 변경된다.

• MCU는 10ms 주기로 모터 속도를 모니터링해야 한다.
• 속도 오차가 임계값 이상이면 Fault 처리해야 한다.
• Fault 발생 시 PWM 출력을 Disable 해야 한다.
• CAN Timeout 발생 시 모터 구동을 정지해야 한다.

이제부터는 실제 ECU 코드와 굉장히 가까워진다.

 

AUTOSAR 프로젝트 기준으로 보면 DEM Fault 처리, COM Timeout, Watchdog, Alive Counter, Safe State 전환 같은 것들이 대부분 TSR과 연결되기 시작한다.

 

실제 ECU 코드와는 어떻게 연결될까?

 

기능안전을 처음 공부하면 문서 작업처럼 느껴질 수 있다.

하지만 실제 프로젝트에서는 대부분 코드와 직접 연결된다.

 

예를 들어 TSR에서 다음과 같은 요구사항이 정의되었다고 가정해보자.

500ms 이상 CAN Timeout 발생 시 모터를 정지해야 한다.

 

실제 소프트웨어에서는 결국 이런 형태로 구현된다.

if (CAN_Timeout == TRUE)
{
    Motor_Stop();
}

 

즉, 기능안전은 단순히 문서를 작성하는 작업이 아니라 실제 ECU 내부 로직과 매우 밀접하게 연결된다.

 

그래서 실무에서는 다음과 같은 표현들이 자주 등장한다.

• 이 Fault는 Safety Mechanism인가?
• 이 Timeout은 TSR 요구사항인가?
• 이 DTC는 기능안전 관련인가?
• Safe State 전환 시간이 요구사항 만족 조건인가?

결국 DEM, DTC, Watchdog, Timeout 같은 개념들도 기능안전 흐름 안에서 연결되는 경우가 매우 많다.

 

기능안전을 공부할 때 중요한 부분

처음 기능안전을 공부하면 용어가 너무 많아서 어렵게 느껴질 수 있다.

하지만 흐름 자체는 생각보다 단순하다.

 

먼저 위험 상황을 분석하고,

그 위험을 줄이기 위한 안전 기능을 정의한다.

 

그리고 그 기능을 실제 ECU에서 구현 가능한 수준으로 구체화한다.

이 과정에서 등장하는 대표 개념이 바로 FSR과 TSR이다.

 

정리하면 다음과 같이 이해하면 된다.

FSR은 안전을 위해 무엇을 해야 하는가를 정의한다.

TSR은 그것을 실제 ECU에서 어떻게 구현할 것인가를 정의한다.

 

처음에는 단순 문서 용어처럼 보이지만,

실제 AUTOSAR 기반 ECU 프로젝트에서는 코드와 굉장히 밀접하게 연결되는 핵심 개념이라고 볼 수 있다.