| 대 안 |
1. 현재 정의한 메시지 ID정보로는 ACK인지 NACK인지 구분이 되지 않는다. 메시지 ID에 ACK와 NAK 추가를 제안한다.
2. TimeStamp가 년도가 다른 표준안에 비해서 상대적으로 더욱 제한적이다. 일반적인 폼으로 수정되기를 원함.
3. TimeStamp를 사용하는게 Mandatory가 아니라 Optional이 되기를 원함. 즉, 통신개시와 같은데는 시간 정보의 필요성이 느껴지지 않지만, 정보 전송이 될 때, 정상적인 경우는 상관이 없지만, 워스트 케이스에 차량 정보가 누적이 되었다가 올라온다면 이전 정보에 대한 시간은 필요하다고 본다. 그래서 의미있는 차량정보 전송시에는 시간 정보의 필요성은 있어 보임.
4.USECASE ID가 1바이트인데, 16개 이상 확장될 가능성이 없다면 4비트면 적당하고 각 USECASE당, MESSAGE ID도 1바이트인데, 16개 이상 확장될 가능성이 없다면 4비트이면 적당하다. 그러므로 한 바이트를 USECASE ID & MESSAGE ID가 상위 4비트 하위 4비트를 나눠 쓰면 될 것임.
5. 메시지 길이도 가변적인 것 보다는 고정식으로 가는 것이 좋다고 생각함. 주고받아야 하는 메시지 바디의 길이가 255(1바이트)바이트보다 길고 65535(2바이트)바이트보다 작다면 2바이트로 고정을 하는 것이 무방함.
6. 제안된 표준안 성격상 파라메타들이 Optional로 사용되는 것이 많은데, 각 파라메타의 순서에서 정보가 하나 빠지면 메시지 파싱하는데 어려움이 있다. 이런 경우에는 TLV 형식으로 파라메타를 인코딩하고 디코딩하는 것이 좋아서 제안한다. 차량정보의 수가 최소 255개 이상이고 65535보다 작을 것으로 예상되어, 길이는 2바이트를 제안함. 파라메타 타입은 다음과 같이 큰 범주로 나눈다. 예를 들어, 파라메타의 종류도 일반정보(운전자ID, 시간, GPS 등), 가공정보(총누적거리 등), 운행정보(운행거리, 시동시간 등), 안전진단정보(DTC, 타이어 공기압 이상정보, 베터리 전압 등), 상태정보(속도, RPM, 연료소비량, CO2, 탄화수소 등)의 범주로 나누고 해당 범위안에서 순서대로 각각의 파라메타 타입을 정하도록 한다. 즉, 차량정보에서 파라메타로 사용되는 정보에 대해서는 본 표준에서 정의하고자 하는 타입과 길이에 대해 정리한 테이블이 요구된다.
|