인프런 커뮤니티 질문&답변

흔히라는 표현이 이상하긴 한데요. 물론 Bus Off 상태는 겪지 않는 게 이상적인 것 같긴 하나

이 상태에 대한 처리(리액션)을 언급하신 걸로 보아 엄격하게 절대 있어서는 안 되는 상태인 것처럼 묘사하시지는 않은 것 같아서요.

예를 들어 없는 게 좋지만 간혹 발생되도 그거에 대한 처리만 잘하면 어느정도 용인되는 상태인가 해서요.

그리고 자세히 몰라도 상관 없다고 하시기는 하셨으나 "CAN 에러 처리" 섹션을 수강하면서 몇 가지 궁금한 게 있어서 추가로 질의합니다.

1. 동일 CAN Bus 에 묶여 있는 시스템에서 일부 제어기들만 Error를 감지하는 게 일반적인가요?

   
   그런 상황을 묘사해주셔서 궁금합니다.

   
   Error의 종류 설명해주신 게 Bit Error, Stuff Error, CRC, Acknowledge Error, Form Error 인데요.
   이 중에서 Bit Error, Acknowledge Error 정도를 제외하고
   (송신자가 확인하니까? 그리고 Form Error도 감지 시점이 잘 모르겠으나 일부에서만 감지될 수 있어보이긴 합니다)
   broadcast 되는 CAN 특성상 Error를 묶여 있는 제어기들이 다 같이 감지할 것 같은데 그렇지는 않나요?

2. Acknowledge Error 를 설명해주실 때, 송신 측에서 반드시 Acknowledge Slot Bit 를 1로 세팅하고 수신측에서 잘 받았다면 Ack에 0을 출력한다고 하셨고 Bus 상에 Ack Bit가 0이 된다고 묘사하셨는데요.

   
   a. Bus 상에 CAN Message 가 유지되다는 건 이해되지 않고 수신측에서 수신한 메세지를 그대로 Ack Bit만 0으로 변경해서 응답한다는 걸까요? CAN Protocol이 항상 그런 식인 건가요?

   
   b. 그리고 송신 측이 보낸 메세지에서 Ack Bit를 0으로 업데이트를 할만한 제어기가 없는 상황
   즉, 개발/테스트 환경 같이 제어기가 하나만 있는 상황이라면 송신하는 족족 Error Count가 올라가게 될까요? 최종적으로는 Bus Off?

3. 제어기가 에러를 감지하면 Stuff Error를 유도하는 Error Frame 를 전파한다고 하셨는데요.
   그러면 이 Error Frame을 수신한 제어기도 이 Error Frame에 의해서 Error를 감지하고 또 Error Frame을 전파하는 상태가 순환되는 거 아닌가요?
   당연히 이렇게 에러가 순환되는 상태가 되도록 CAN이 설계되어 있을 것 같진 않지만 설명을 듣는 순간 떠올라서 질문 추가합니다.