DEM Overview

DEM(Diagnostic event manager)는 진단 기능의 중요한 모듈이다. 

이 포스팅에서 DEM이 어떻게 동작하는지 알아보자.

 

AUTOSAR를 충분히 오래 사용하셨다면 DCM, DEM, DLT, DET란 무엇인지 알 것이다. 그렇지 않다면 이 글이 진단에 대한 좋은 출발점이 될 수 있다. 오늘은 중요한 진단 모듈인 DEM(진단 이벤트 관리자)에 대해 자세히 알아보겠다.

DEM이란 무엇이며 왜 필요한지 생각해보자.

DTC(진단 문제 코드)에 대해 들어봤다면 DEM에 대해 잘 알고 있을 것이다. 이를 통해 진단 이벤트를 정의하고 보고할 수 있으며, 나중에 ECU의 문제를 진단하는 데 사용할 수 있다. DCM(진단 통신 관리자)과 상호 작용하여 결함 정보, 일명 DTC를 제공한다(진단 통신에 대한 자세한 내용은 UDS 개요 문서에서 확인할 수 있다). 예를 들어, 장거리 주행 후 DEM에서 제공하는 결함 메모리를 읽고 ECU에 문제가 있는 모든 것을 파악할 수 있다. 몇 바이트만 읽으면 되기 때문에(적어도 ECU가 감지할 수 있는 것만) 문제를 진단하는 데 골칫거리가 줄어든다.

DEM은 그 기능을 위해 다른 모듈에 크게 의존힌다. 다른 모듈이 어떻게 작동하는지 분석해 보자. 당연한 것부터 시작하겠다:

RTE/소프트웨어 컴포넌트 - 진단은 소스 코드의 어느 곳에서나 가능하다. 따라서 소프트웨어 구성 요소에 대한 포트를 제공하여 구성 요소로부터 이벤트 상태를 수신하고 검색한 모니터링 정보를 전달한다. SW-C가 보고서의 상당 부분을 차지하지만, 다른 모듈(MCAL 드라이버 포함)도 동일한 기능을 수행할 수 있다.

NvM(NvRAM 관리자) - DEM에 보고된 이벤트는 몇 번의 전원 주기 후에도 관련성이 있는 경우가 많기 때문에 이벤트 메모리를 지속적으로 저장해야 한다. 따라서 NvM은 DEM에 필요한 블록을 저장하기 위해 작동한다.

DCM / J1939 DCM - DTC 읽기에 대해 들어봤고 UDS에 대한 기사를 읽어봤다면 이 내용을 잘 알고 있을 것이다. 그렇지 않다면 이렇게 설명하겠다. DCM은 생산 차량의 모든 진단을 위한 백도어이므로 외부에 이벤트를 보고해야 하는 경우 일련의 UDS 명령을 통해 이를 수행할 수 있다. 예를 들어 결함 메모리를 관리하여 지울 수도 있다. 이는 예를 들어 차량의 문제를 해결한 후 유용하다.

EcuM(ECU 상태 관리자) - BSW 모듈 초기화를 담당하는 일반적인 모듈이다. 모드 관리 및 ECU 상태 머신에 대한 자세한 내용은 모드 관리 문서에서 확인할 수 있다.

DLT(진단 로그 및 추적) - DLT는 사용자가 선호하는 통신 버스를 통해 해당 정보를 제공하여 DEM에서 무슨 일이 일어나고 있는지 알 수 있게 해주는 로깅 모듈이다.

FiM(기능 억제 관리자) - 특정 이벤트가 실패로 보고되면 ECU는 일부 기능을 비활성화하여 적절히 대응해야 한다. FiM 모듈은 이러한 상태를 모니터링하고 조건이 더 이상 확인되지 않고 정상 작동이 안전하다고 판단될 때까지 일부 기능을 억제한다.

여기에서 다른 모듈과의 모든 연결을 살펴볼 수 있다:

 

DEM이 의존하는 모듈들

마무리하기 전에 이벤트에 사용할 수 있는 디바운스 메커니즘을 확인하여 DEM에서 이벤트를 보고하는 방법과 이벤트를 올바르게 보고하는 방법을 살펴보자.

디바운스를 사용하는 경우 DEM 이벤트는 통과 또는 실패 상태 또는 중간 상태인 통과 및 사전 실패 상태를 가질 수 있다(나중에 자세히 설명한다). 이벤트는 현재 사용 중인 Autosar 계층에 따라 API 또는 포트를 통해 두 가지 방법으로 보고/읽을 수 있다. 이벤트 가져오기 및 설정 API는 아래와 같이 정의되어 있다:

    Std_ReturnType Dem_SetEventStatus(
        Dem_EventIdType EventId,
        Dem_EventStatusType EventStatus
    )

    Std_ReturnType Dem_GetEventStatus(
        Dem_EventIdType EventId,
        Dem_UdsStatusByteType* EventStatusByte
    )

DEM이 제공하는 API(그리고 소프트웨어 컴포넌트도 RTE를 통해 DEM에 액세스할 수 있으므로 포트)는 훨씬 더 많고 유용하다는 점을 기억하자. 지금은 표면적인 부분만 살펴본 것이지만 앞으로 더 자세히 살펴볼 예정이다.

이제 이벤트 디바운싱에 대해 이야기해 보겠다. 왜 필요한지, 어떤 옵션이 있는지 알아볼까? 가장 간단한 예를 살펴보겠다. 대학에서 마이크로컨트롤러 수업을 들으면서 버튼에 대한 시간 기반 디바운스 메커니즘을 구현해 보셨을 것이다. 하지만 전자제품은 완벽하지 않다. 간섭을 받을 수 있다. 자동차에서도 예외는 아니다. 물론 DEM이 이를 구현해 주면 수동으로 할 필요가 없으니 정말 멋진 일이다. 따라서 디바운싱이 중요하다. 디바운싱에는 세 가지 옵션이 있다:

카운터 기반 디바운싱 - 카운터 기반 디바운싱에서는 이벤트를 통과 또는 실패로 설정할 때마다 카운터가 몇 단계씩 증가/감소한다. 특정 임계값에 도달하면 이벤트가 실패 또는 통과로 디바운스된다. 실패 또는 통과 상태에 있을 때마다 반대 이벤트 보고서가 점프 업 또는 점프 다운 값을 통해 더 큰 점프를 트리거할 수 있다(이 옵션이 구성된 경우).

카운터 기반 디바운싱

시간 기반 디바운싱 - 카운터 기반 디바운싱과 비슷한 방식으로 작동하지만 시간을 기준으로 한다. 이벤트가 통과 또는 실패로 보고된 경우, 일정 시간이 지나도 반대되는 이벤트 상태가 없으면 이벤트는 자동으로 통과 또는 실패로 간주 된다. 한 가지 명심해야 할 점은 아래 그림을 보면 이벤트 상태를 통과 또는 불합격 대신 바로 통과 또는 불합격으로 표시할 수 있다는 것이다.

시간 기반 디바운싱

내부 모니터링 디바운싱 - 이 디바운싱 모드에서는 디바운싱을 직접 관리할 수 있다.

마지막으로 몇 가지 말하자면, 이것은 표면적인 부분일 뿐이라는 점을 말하고 싶다. 다음 글에서는 DEM과 그 주변 모듈에 대해 더 자세히 살펴볼 수 있는 기회가 있을 것이며, 더 많은 내용을 다룰 예정아다.