SDV 시대, 차량 진단 - ODX와 OTX에서 SOVD까지, 무엇이 달라지고 무엇을 준비해야 하는가?

차량 진단을 처음 접했을 때 가장 처음 접했던 단어가 UDS였습니다. 진단기로 특정 ECU에 접속하고, Diagnostic Session을 변경하고, DID를 읽거나 DTC를 확인하고, Routine을 실행하는 식입니다. 그리고 조금 더 살펴보다 보면 Security Access와 ECU Programming까지도 접하게 됩니다. 그래서 "차량 진단 = UDS"와 같이 둘을 같은 개념으로 생각하기도 했습니다. 하지만 실제 차량의 진단 환경을 조금 더 넓게 들여다보면 UDS만으로는 설명되지 않는 부분이 많습니다. 예를 들어 진단기는 ECU가 어떤 DID를 제공하는지 알아야 합니다. 해당 DID의 데이터가 2 Byte인지 4 Byte인지, 물리값으로 변환하기 위해 어떤 Scaling을 적용해야 하는지도 알..

시스템 요구사항 개발 절차 (1부) - 무엇을 요구사항으로 작성해야 하는가? #3

이전 포스팅에서 이어집니다. [관련글]- 시스템 요구사항 개발 절차 (1부) - 무엇을 요구사항으로 작성해야 하는가? #1 시스템 요구사항 개발 절차 (1부) - 무엇을 요구사항으로 작성해야 하는가? #1시스템 요구사항을 작성해야 한다고 하면 보통 시스템이 해야 할 기능부터 떠올립니다. 가령 VCU라면 차량의 주행 가능 상태를 판단하고, 운전자의 요구를 해석하여 구동 토크를 결정하고, BMS나habana4.tistory.com 1. 요구사항을 잘 쓰기 전에, 무엇을 써야하는지를 찾아야 한다. 2. 시작은 다이어그램이 아니라 시스템의 목적이다 - System Concept 3. 누가 무엇을 기대하는가 - Stakeholder Analysis 4. Operational Domain Analy..

이전 포스팅에서 이어집니다...[관련글]- 시스템 요구사항 개발 절차 (1부) - 무엇을 요구사항으로 작성해야 하는가? #1 시스템 요구사항 개발 절차 (1부) - 무엇을 요구사항으로 작성해야 하는가? #1시스템 요구사항을 작성해야 한다고 하면 보통 시스템이 해야 할 기능부터 떠올립니다. 가령 VCU라면 차량의 주행 가능 상태를 판단하고, 운전자의 요구를 해석하여 구동 토크를 결정하고, BMS나habana4.tistory.com 1. 요구사항을 잘 쓰기 전에, 무엇을 써야하는지를 찾아야 한다. 2. 시작은 다이어그램이 아니라 시스템의 목적이다 - System Concept 3. 누가 무엇을 기대하는가 - Stakeholder Analysis 4. Operational Domain Anal..

최근 프로젝트에서 요구사항을 변경을 추적하고 관리하는 업무를 수행하고 있는데요. 거기에선 수시로 많은 요구사항 변경들이 공유됩니다. 그런데 어떤 변경은 처음에는 큰 변경이라 생각지 않았지만, 요구사항 관리 시스템에서 해당 항목을 찾아보니 관련 시스템 요구사항과 소프트웨어 요구사항이 연결되어 있었고, 설계와 시험 항목까지 연결되어 있었습니다.그리고 문서상으로는 별다른 문제도 없어 보였습니다.그런데 변경 영향을 확인하기 위해 관련 담당자들이 모이면 상황이 달라집니다. 이 요구사항이 바뀌면 어느 소프트웨어까지 수정해야 하는지, 연결된 인터페이스에도 영향이 있는지, 기존 시험을 다시 수행해야 하는지 하나씩 확인하기 시작했는데 누구도 전체 범위를 명확하게 설명하지 못했습니다. 결국 각 담당자가 자신의 영역으로 돌..

[관련글]- 시스템 요구사항 개발 절차 (1부) - 무엇을 요구사항으로 작성해야 하는가? #1 (현재글) 1. 요구사항을 잘 쓰기 전에, 무엇을 써야하는지를 찾아야 한다. 2. 시작은 다이어그램이 아니라 시스템의 목적이다 - System Concept 3. 누가 무엇을 기대하는가 - Stakeholder Analysis 4. Operational Domain Analysis- 시스템 요구사항 개발 절차 (1부) - 무엇을 요구사항으로 작성해야 하는가? #2 5. 시스템의 경계를 정한다 - Context Diagram + Initial BDD (Block Definition Diagram) 6. 시스템이 해야 할 일을 찾는다 - Use Case Analysis 7. 같은 기능을 서..

요즘 업무에서 LLM을 사용하는 것은 더 이상 특별한 일이 아닙니다. 궁금한 내용을 찾거나 문서를 정리하는 것은 기본이고, 조금 더 적극적으로 활용하면 RAG를 구축해 필요한 정보를 빠르게 검색할 수도 있습니다. 최근에는 바이브 코딩을 이용해 반복적인 업무를 자동화하거나, 데이터를 분석하고 가시화하는 일도 이전보다 훨씬 쉽게 할 수 있게 되었습니다. 물론 모든 결과를 그대로 믿을 수 있는 것은 아닙니다. 그럴듯하지만 사실과 다른 답을 만들어내는 Hallucination은 여전히 신경 써야 할 문제이고, 전문적인 내용일수록 원문이나 근거를 다시 확인하는 과정이 필요합니다. 때로는 LLM이 만들어준 결과를 검토하는 데 적지 않은 시간을 쓰기도 합니다. 그럼에도 LLM이 유용하다는 사실 자체를 부정하기는 어렵..