시스템/소프트웨어 이야기

우리는 왜 사용하지도 않는 엔지니어링 산출물을 만들고 있을까?

KSNC 2026 발표 이후 다시 생각해 본 Engineering Continuity의 실무적 의미지난 11월 12일, KSNC 2026에서 "Building the Engineering Chain for the Evolving Automotive Industry"라는 주제로 발표할 기회가 있었습니다. 자동차 산업이 빠르게 변화하는 상황에서 요구사항, 설계, 소프트웨어 개발, 검증, 증거, 그리고 엔지니어링 의사결정이 어떻게 연결되어야 하는지를 이야기하고자 했습니다. (발표자료는 아래에 첨부해 놓았습니다.) 발표에서 강조했던 것은 자동차의 복잡성이 소프트웨어의 규모나 ECU의 수뿐만 아니라 서로 다른 엔지니어링 활동 사이의 관계에서도 증가하고 있다는 점이었습니다. SDV, OTA, 중앙집중형 아키텍처, ..

1. ISO/PAS 8800은 왜 테스트 기반 안전 분석을 다루는가?자동차 소프트웨어 개발에서는 시스템의 안전성을 확보하기 위해 다양한 안전 분석을 수행합니다. ISO 26262에 따라 HARA를 수행하여 위험을 식별하고, FMEA나 FTA 등을 통해 시스템에서 발생할 수 있는 고장과 그 영향을 분석합니다. 이러한 분석 결과를 바탕으로 안전 요구사항을 정의하고, 개발된 시스템이 해당 요구사항을 충족하는지 테스트를 통해 확인합니다. 그런데 이러한 안전 분석과 테스트 활동을 이미 수행하고 있음에도, ISO/PAS 8800에서는 테스트 결과에 기반한 안전 분석(Safety Analysis Based on the Results of Testing)을 별도로 다루고 있습니다. 그 이유는 무엇일까요? 이를 이해하기..

※ 상세한 OOV 기술문서 및 OOV 가이드 문서는 내부 검토가 완료되는대로 추가 업데이트 하도록 하겠습니다. 소프트웨어 개발에서 검증(Verification)은 매우 당연하면서도 익숙한 활동입니다. 요구사항과 설계 정보를 분석하여 테스트케이스를 작성하고, 정해진 환경에서 테스트를 수행한 뒤, 실제 결과와 기대 결과를 비교합니다. 발견된 결함을 수정하고 재시험을 수행하면서 소프트웨어의 품질을 확보해 나갑니다. 특히 Automotive SPICE와 같은 프로세스 모델을 적용하는 프로젝트에서는 검증 활동을 체계적으로 구분하고 관리합니다. 소프트웨어 Unit의 동작을 검증하고, 구성요소의 인터페이스와 통합 동작을 검증하며, 최종적으로 소프트웨어 요구사항의 충족 여부를 확인합니다. 이러한 프로세스의 구분은 분..

4. 자동차 ECU Penetration Testing 환경 구축자동차 ECU 침투 테스트 환경은 시험 입력을 전달하고, ECU의 운용 조건을 유지하며, 결과를 관측하고, 이상 발생 후 복구할 수 있도록 구성합니다. 침투 테스트 준비는 통신 연결을 비롯한 입력에 대한 반응과 벤치 자체의 문제를 구분할 수 있어야 합니다. 이 장에서는 승인된 시험용 ECU와 격리된 네트워크를 기준으로, 하드웨어 연결부터 Linux 환경 설정, 로그 수집, CAN/UDS 벤치의 동작 확인까지 살펴봅니다.4.1. ECU Bench Testing과 Vehicle-level TestingECU Bench Testing은 제어기를 차량에서 분리하고 전원, 통신, 센서 입력과 부하를 시험 장치로 구성하는 방식입니다. 주변 조건을 통..

1. Penetration Testing이란 무엇인가?자동차 소프트웨어의 복잡성이 증가하면서 사이버보안은 차량 개발 과정에서 중요한 검증 영역으로 자리 잡았습니다. 차량 내부 네트워크뿐 아니라 외부 통신, 원격 진단, OTA 업데이트 등 다양한 인터페이스가 확대되면서 공격자가 시스템에 접근할 수 있는 경로도 다양해지고 있습니다. 이러한 환경에서 Penetration Testing(침투 테스트, 이하 Pen Test)은 실제 공격자의 관점에서 시스템의 취약점을 탐색하고, 보안 대책의 유효성을 검증하는 활동입니다.1.1. Penetration Testing의 정의와 목적Penetration Testing은 사전에 승인된 범위에서 실제 공격자가 사용할 수 있는 기법과 절차를 적용하여 시스템의 보안 취약점과 악..

여러 협력사에서 개발한 ECU의 진단 사양을 하나로 모으다 보면, 분명 동일한 UDS 표준을 기반으로 작성된 진단 정보인데, 협력사마다 데이터를 정의하고 표현하는 방식이 조금씩 다르다는 것을 알 수 있습니다. 어떤 곳은 Excel로, 어떤 곳은 별도의 진단 사양서로 관리하며, 같은 진단 서비스를 설명하더라도 사용하는 용어나 기술 수준이 서로 다르기도 합니다. 실무적으로 볼 때 이러한 차이는 생각보다 많은 문제를 야기합니다. 이와 관련해서 예전에 RCRE(Reder-Centric Requirements Engineering)에 대해 글도 쓰고, 논문도 작성한 바가 있기도 합니다만, 이 문제는 각각의 진단 사양을 이해하고 해석하는 데 시간이 필요하고, 진단 도구에 적용하는 과정에서도 추가적인 변환과 확인 작..

★ 2026.10.18 업데이트제가 소속되어 있는 세온이앤에스에서 관련 서비스를 제공하게 되어 관련 링크를 추가합니다. (https://seonens.com/eu-cra/) 1. 왜 CRA가 필요한가과거에는 제품의 사이버보안을 주로 출시 시점의 상태를 기준으로 판단하는 경향이 있었습니다. 개발 과정에서 보안 요구사항을 정의하고, 취약점 분석과 보안 시험을 수행한 뒤, 제품 출시 전에 충분한 보안성을 확보했다는 것을 확인하는 방식입니다. 하지만 오늘날의 디지털 제품은 대부분 소프트웨어 중심의 제품이 대부분이므로, 출시 이후에도 지속적인 관리를 필요로 하게 됩니다. 먼저 이들 제품들 상당수는 네트워크에 연결되고, 외부 서비스와 데이터를 주고받으며, 소프트웨어 업데이트를 통해 기능이 계속 변경됩니다. 하나의..

2026년 3월, SOVD(Service-Oriented Vehicle Diagnostics)의 API를 정의한 ISO 17978-3이 국제표준으로 발행되었습니다. 2026년 5월에는 SOVD의 기본 원칙과 용어를 정의한 ISO 17978-1이 발행되면서 서비스 지향 차량 진단을 위한 국제표준 체계가 구체화되었습니다. 이는 자동차 진단 분야에 있어 의미 있는 변화라고 봅니다. 기존 자동차 진단이 개별 ECU를 대상으로 진단 서비스를 실행하는 체계를 중심으로 발전해 왔다면, SOVD는 ECU뿐 아니라 HPC(High-Performance Computer), 차량 애플리케이션 등 다양한 진단 대상에 표준화된 API를 통해 접근할 수 있는 기반을 제공합니다. 특히 OEM과 진단 솔루션 개발사 입장에서는 서로..

1. UT를 끝낸 뒤, IT에서 다시 만난 테스트토크 제어 소프트웨어를 개발하는 가상의 프로젝트에서 이야기를 시작해 볼까 합니다. 유닛테스트(Unit Test)를 완료하고, 통합테스트(Integration Test)를 준비하고 있습니다. 그런데 통합테스트 TC(Test Case)를 검토하던 담당자가 하던일을 멈추고 모니터 화면을 뚫어져라 쳐다 봅니다.“이 테스트는 지난번에 이미 수행했습니다.”“그때는 유닛테스트였고, 이번에는 통합테스트입니다.” 두 사람은 기존 테스트 명세와 테스트 수행 로그를 펼쳐 보았지만, TC 식별자는 분명 다릅니다. 하나는 상세설계와 연결된 TC이고, 다른 하나는 아키텍처에 연결된 TC 였습니다. 또한 문서의 제목도 각각 유닛테스트 명세서와 통합테스트 명세서로 구분되어 있습니다. ..

1. 자동차 사이버보안 강화와 퍼징 테스트의 필요성차량의 주요 기능을 소프트웨어로 구현하는 범위가 확대되고 있으며, 외부 통신을 통한 서비스 제공과 소프트웨어 업데이트도 자동차의 중요한 기능으로 자리 잡고 있습니다. 이러한 변화는 차량의 기능과 서비스 확장에 새로운 가능성을 제공하는 동시에, 사이버보안 관점에서 고려해야 할 공격 표면(Attack Surface)도 확대하고 있습니다. 과거에는 차량 내부의 제한된 네트워크와 ECU 간 통신을 중심으로 보안 문제를 살펴보았다면, 이제는 차량 외부의 통신 인터페이스, 진단 시스템, 소프트웨어 업데이트 경로, 외부 서비스와의 연계까지 함께 고려해야 합니다. 특히 차량 내부의 여러 ECU가 네트워크로 연결되어 있다는 점에서 하나의 인터페이스에 존재하는 취약점이 다..