안녕하세요. 자율주행 SW 안전 전문가를 목표로 하는 플라잉 준입니다.
오늘은 ISO26262 관련 차량 내 E/E 시스템을 연결해주는 Communication bus (Bus interface) 에 적용할 수 있는 안전 매커니즘 및 진단 커버리지에 대해서 설명하도록 하겠습니다.
Communication bus (Bus interface)
차량 시스템은 다양한 기능을 구현하고자 차량 내 여러개의 E/E 시스템으로 구성이 되어 있으며 이들 E/E 시스템은 communication bus (bus interface) 로 연결되어 있습니다. 즉, Communication bus 는 E/E 시스템 간에 데이터와 정보를 전송하는 통로 (통신 시스템) 인터페이스이며 Communication bus 의 예로는 CAN, Ethernet, FlexRay 등이 있습니다.
이러한 데이터 송수신의 기능을 수행하는 Communication bus 의 Failure Mode 를 생각해보면 아래와 같은 Failure Mode 를 생각해 볼 수 있습니다.
- Loss of communication peer
- Message corruption
- Message unacceptable delay
- Message loss
- Unintended message repetition
- Incorrect sequencing of messages
- Message insertion
- Message masquerading
- Message incorrect addressing
Safety Mechanism & Diagnostic Coverage
아래에서 정리하는 안전 매커니즘에 대한 진단 커버리지는 낮음 (Low), 중간 (Medium), 높음 (Hgih)로 분류되며 수치로는 각각 60%, 90%, 99% 의 Coverage 를 의미합니다.
위에서 정리한 Communication bus 의 Failure mode 를 검출하기 위한 안전 매커니즘은 아래와 같습니다.
- One-bit hardware redundancy
- Multi-bit hardware redundancy
- Read back of sent message
- Complete hardware redundancy
- Inspection using test patterns
- Transmission redundancy
- Information redundancy
- Frame counter
- Timeout monitoring
- Combination of information redundancy, frame counter and timeout monitoring
각 안전 매커니즘에 대한 설명은 아래와 같은 형태로 정리하겠습니다.
Safety Mechanism (Diagnostic Coverage : Coverage)
목적 :
설명 :
예제 :
참고사항 :
그럼 이제 Communication bus 에 적용할 수 있는 안전 매커니즘과 진단 커버리지에 대해 정리해 보겠습니다.
One-bit hardware redunadncy (DC : 낮음 (Low, 60%))
목적 : 데이터 스트림에서 오류를 감지하기 우함 (가능한 모든 비트 오류의 50%를 감지)
설명 : Communication bus 는 한 라인(비트) 확장되며 이 추가 라인(비트)은 패리티 검사를 통해 장애를 감지하는 데 사용됩니다.
예제
- 표준 UART에서 구현된 패리티 비트
Multi-bit hardware redundancy (DC : 중간 (Medium, 90%))
목적 : 버스 및 직렬 전송 링크에서 통신 중 오류를 감지 하기 위함
설명 : 통신 버스는 두 개 이상의 라인으로 확장되며 이러한 추가 라인은 블록 코드를 사용하여 장애를 감지하는 데 사용됩니다.
예제
- Hamming 코드
- Reed Solomon 코드
- CRC
- Low Density Parity Check 코드
Read back of sent message (DC : 중간 (Medium, 90%))
목적 : bus communication 에서의 오류를 감지하기 위함
설명 : 메시지 송신기 (transmitter) 는 버스로 보낸 메시지를 다시 읽어 원본 메시지와 비교합니다.
주의사항
- 해당 safety mechanism 은 CAN 에서 사용
- 해당 safety mechanism 은 message 의 data 및 id 의 손상과 관련된 failure mode 에 대해서는 높은 coverage 를 가질 수 있지만, 해당 mechanism 은 data 의 일관성만 확인하는 것으로 다른 failure mode 에 대해서는 높은 coverage 를 보장할 순 없다.
- 예를들어, unintended message repetition (의도하지 않은 메시지 반복) 과 같은 failure mode 에 대해서는 해당 safety mechanism 으로 커버할 수 없다.
Complete hardware redundancy (DC : 높음 (High, 99%))
목적 : 두 bus 의 신호를 비교하여 통신 중 오류를 감지하기 위함
설명 : 통신을 위한 동일한 버스를 추가로 하나 구현하여 기존 라인과 추가 라인의 신호를 비교하여 오류를 감지하는 데 사용됩니다.
예제
- 이중 채널 FlexRay 구현: 버스가 복제되고 추가 라인(비트)이 오류를 감지하는 데 사용됩니다.
Inspection using test patterns (DC : 높음 (High, 99%))
목적 : 통신에서의 static failure (stuck-at failure) 와 cross-talk (누화) 를 감지하는데 사용
cross-talk
- 회로, 회로의 일부분, 채널등으로부터 원하지 않은 전하 커플링, 유도 커플링, 저항 커플링이 생기는 것
- 선로간 커플링으로 인해 원하지 않는 잡신호가 유입되거나 서로 전달되어서 교란되는 현상
- 하나의 회로나 전송 시스템의 채널에 전송된 신호가 다른 채널에 의도하지 않은 효력을 발생시키는 것
설명 : 해당 safety mechanism 은 데이터 경로에 대한 데이터 흐름에 독립적인 주기적 테스트입니다.
정의된 테스트 패턴을 사용하여 관측치를 해당 예상 값과 비교합니다.
테스트 커버리지는 테스트 패턴 정보, 테스트 패턴 수신 및 테스트 패턴 평가 간의 독립성 정도에 따라 다릅니다.
좋은 설계에서 시스템의 기능적 동작은 테스트 패턴에 의해 허용할 수 없을 정도로 영향을 받지 않습니다.
Transmission redundancy (DC : 중간 (Medium, 90%))
목적 : bus communication 에서 일시적인 결함을 감지하기 위함
설명 : 해당 safety mechanism 은 정보를 순서대로 여러번 전송하여 bus communication 의 일시적인 결함을 감지하는데 사용됩니다.
Information redundancy (DC : 중간 (Medium, 90%))
목적 : bus communication 의 결함을 감지하기 위함
설명 :
데이터는 각 블록에 대해 계산된 체크섬 또는 CRC (cyclic redundancy check)와 함께 블록 단위로 전송됩니다.
그런 다음 수신기는 수신된 데이터의 체크섬을 다시 계산하고 그 결과를 수신된 체크섬과 비교합니다.
- CRC 커버리지의 경우 커버할 데이터의 길이, CRC의 크기(비트 수) 및 다항식에 따라 다릅니다.
- CRC는 기본 하드웨어의 통신 오류 모드(예: 버스트 오류)를 처리하도록 설계할 수 있습니다.
메시지 ID는 체크섬/CRC 계산에 포함되어 메시지의 이 부분에서 손상을 커버할 수 있습니다(masquerading).
해당 mechanism 의 커버리지는 적용된 체크섬/CRC 알고리즘의 Hamming distance 에 따라 정리 할 수 있다.
- Hamming distance 는 블록 부호 이론에서, 해밍 거리(Hamming distance)는 곱집합 위에 정의되는 거리 함수이다. 대략, 같은 길이의 두 문자열에서, 같은 위치에서 서로 다른 기호들이 몇 개인지를 센다.
- 예제
- '1011101'과 '1001001'사이의 해밍 거리는 2이다. (1011101, 1001001)
- '2143896'과 '2233796'사이의 해밍 거리는 3이다. (2143896, 2233796)
- "toned"와 "roses"사이의 해밍 거리는 3이다. (toned, roses)
Hamming distance 거리에 따른 커버리지 는 다음과 같다.
- Hamming distance 2 이하 : 낮은 커버리지
- Hamming distance 3 이상 : 중간 커버리지
CRC 알고리즘 별 Hammind distance 는 다음과 같다.
| CRC 값에 포함된 정보 | CRC size (bits) | 다항식 | Data length (bits) | Hamming distance | Coverage | Remark |
| 메시지 정보 | 5 | 0x12 | <2048 | 2 | 낮음 (Low) | |
| 메시지 정보 | 8 | 0x97 | <119 | 4 | 중간 (Medium) | 주로 LIN bus 에서 사용 |
| 메시지 ID 및 정보 | 10 | 0x319 | <501 | 4 | 중간 (Medium) | |
| 메시지 ID 및 정보 | 15 | 0x4599 | <127 | 5 | 중간 (Medium) | 주로 CAN 에서 사용 (CAN-FD 제외) |
| 메시지 정보 | 24 | 0x5D6DCB | <=248 | 6 | 중간 (Medium) | |
| 메시지 정보 | 24 | 0x5D6DCB | >248 | 4 | 중간 (Medium) | 주로 FlexRay 의 Frame CRC 에 사용 |
| 메시지 헤더 | 11 | 0x385 | <=20 | 6 | 중간 (Medium) | 주로 FlexRay 의 Header CRC 에 사용 |
참고사항
- 알고리즘의 Hamming distance 가 3 미만인 경우에도 적절한 근거가 뒷받침된다면 데이터 및 ID 손상과 관련된 낮은 커버리지가 아닌 중간 또는 높은 커버리지를 주장할 수 있습니다.
Frame counter (DC : 중간 (Medium, 90%))
목적 : 프레임은 한 컨트롤러에서 다른 컨트롤러로 전송되는 일관된 데이터 집합으로 고유 프레임은 메시지 ID로 식별되며 해당 mechanism 은 프레임 손실 (loss) 을 감지합니다.
설명 :
각각의 고유한 안전 관련 Frame 에는 버스에서 전송되는 메시지의 일부로 카운터가 포함됩니다. 카운터는 전송된 각 연속 프레임이 생성되는 동안 롤오버와 함께 증가합니다.
그러면 수신기는 카운터가 1씩 증가하는지 확인하여 프레임 손실 (loss) 또는 새로 고침이 없음을 감지할 수 있습니다.
프레임 카운터의 특별한 버전은 안전 관련 데이터의 새로 고침에 연결된 별도의 신호 카운터를 포함하는 것입니다. 이 상황에서 프레임에 하나 이상의 안전 관련 데이터가 포함된 경우 각 안전 관련 데이터에 대한 개별 카운터가 제공됩니다.
Timeout monitoring (DC : 중간 (Medium, 90%))
목적 : 송신 노드와 수신 노드 간의 데이터 손실 (loss) 을 감지
설명 :
수신기는 이 메시지 ID가 있는 유효한 프레임을 수신하는 사이의 시간 동안 각 예상 안전 관련 메시지 ID를 모니터링합니다.
메시지 사이에 너무 긴 기간이 경과하면 failure 가 발생함을 확인하여 통신 채널의 지속적인 손실 또는 특정 메시지의 지속적인 손실(특정 메시지 ID에 대해 수신된 프레임 없음)을 감지합니다.
정리
위에서 정리한 내용은 특정 도메인에서 프로젝트를 진행할 때 참고할 수 있는 내용 정도로 생각해 주시고 활용해주시면 감사하겠습니다 :)
긴글 읽어 주셔서 감사드립니다.
